Hey Gilbert,
Thanks for the comments.
This facility may be implemented such that there is no
Layer 2 information to put in the capture, or it may be
configured to capture only the upper most MPLS tag in packets
of interest, or just the IP Header. Rather than an
interface type, it may be better to indicate the layer where
the capture was started and indicate the expected protocol?
Much of the protocol identification work has been done in
the RMON WG, so I'll have to see exactly how this could work.
So your comment on interface type, may be "starting protocol
ID".
This value can be different for each captured packet, as
the design is to support differential capture based on some
configuration. The idea is to capture the complete ICMP
packet, but only the IP and Transport headers of all packets
to this machine, and only the IP headers for everything else.
I'm working under the assumption that all byte order at
the IETF is network order, which is big-endian(?). But yes a
statement to the effect is in order!
Sequence number is there to detect captured packet loss
in the packet capture system itself, and to put them back
in order.
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
[EMAIL PROTECTED]
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
> -----Original Message-----
> From: Gilbert Ramirez [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 08, 2001 11:04 PM
> To: Carter Bullard; [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] IETF draft for remote packet capture
>
>
> IETF draft for remote packet captureSomewhere you need to encode the
> link-layer type of the captured data. That is, is the data
> Ethernet, Token-Ring, etc.? Your "ifIndex" description seems to encode
> interface number, say, the 2nd
> interface on the device, but doesn't seem to encode link-layer type. A
> program that uses this
> packet capture may very well know that the nth interface on a
> particular
> host has a particular
> link-layer type, but that information should probably be in
> your PCAP header
> instead of
> being retrieved through some non-standardized method.
>
> And from our experience with libpcap, it is wise to have some central
> authority keep track
> of the list of encodings, as you can't assume that the PPP information
> returned from one type
> of machine is in the same format as that from another type of
> machine.You
> need different
> encodings for every different format that will appear at the
> beginning of
> your captured data.
>
> You'll also want to explicitly define the endianness of the multi-byte
> integers in your headers.
>
> What is the purpose of "Sequence Number" in the Multiple
> Captured Packet
> Encapsulation Header?
> Are these packets ("meta-packets"? :-) expected to arrive out
> of order?
>
> --gilbert
>
>
