From: Peter Phaal (peter.phaal@inmon.com)
Date: 06/26/03
Comments in-line:
> So my understanding of the main issue here, is that an sFlow
> decoder, having
> decoded a sampled packet header up to some "layer 3" header,
> may want to
> determine how many bytes of payload data should be attributed
> to those layer
> 3 and above protocol(s), and due to an unknown number of
> bytes having been
> stripped from the original packet, the decoder can't
> determine where the
> layer 2 payload data ends (which in turn, may indicate where
> the layer 3
> payload data ends).
Correct - the issue is with accurately determining the number of
bytes associated with higher layer protocols. This is important
when performing IP accounting functions for instance.
>One might also note that in some cases (e.g. due to hardware limitations
>with different encapsulations), it might not be possible to report a
>completely accurate frame length, but the agent should try to come as close
>as possible.
Yes.
> The definition of the "stripped" field has some ambiguities.
> The notion of
> "trailing protocol information" should probably be clarified
> a bit. Perhaps
> calling it "trailing encapsulation data" would help slightly?
> As for the
> requirement that it be stripped, one could try to clarify
> this by stating
> that trailing encapsulation data corresponding to any leading
> encapsulations
> that were stripped must also be stripped (to keep things
> symmetrical), and
> trailing encapsulation data for the outermost protocol layer
> included in the
> sampled header must be stripped.
>
> Also, a non-encapsulated 802.3 packet would always have
> stripped>=4 (rather
> than =4), since VLAN tag information might have been stripped off in
> addition to the FCS.
>
> Perhaps it would be better to say "outer encapsulations" rather than
> "leading encapsulations" since an encapsulation might have
> both leading and
> trailing portions?
>
> The stripped field seems like a reasonable solution to the issue of
> accurately counting octets on the wire, while still being
> able to determine
> the payload length for higher-layer protocols.
Good suggestions. I've incorporated them in a draft of the SFLOW-STRUCTS
specification and posted it at:
http://www.sflow.org/drafts/draft11/SFLOW-STRUCTS.txt
> I have some
> issues related
> to the stripping of VLAN tags, however, but I'll send out a
> separate message
> on that topic later.
A separate topic discussing the intricacies of VLANs would be worthwhile.
Peter
This archive was generated by hypermail 2.1.4 : 06/26/03 PDT