RE: Clarifying frame_length in sFlow packet headers

From: Peter Phaal (
Date: 06/26/03

  • Next message: Peter Phaal: "sFlow IANA assigned port"

    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.


    > 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:

    > 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.


    This archive was generated by hypermail 2.1.4 : 06/26/03 PDT