Clarifying frame_length in sFlow packet headers

From: Peter Phaal (peter.phaal@inmon.com)
Date: 06/25/03

  • Next message: Marc Lavine: "Re: Clarifying frame_length in sFlow packet headers"

    There is some potential ambiguity in the current definition of frame_length
    in the sampled_header structure:

    /* Raw Packet Header */
    /* opaque = flow_data; enterprise = 0; format = 1 */

    struct sampled_header {
       header_protocol protocol; /* Format of sampled header */
       unsigned int frame_length; /* Original length of packet before
                                          sampling.
                                          Note: For a layer 2 header_protocol,
                                                length is total number of octets
                                                of data received on the network
                                                (excluding framing bits but
                                                including FCS octets) */
       opaque header<>; /* Header bytes */
    }

    According to this definition, the length is defined for layer 2 protocols as
    the total octets on the wire. This definition fully accounts for the
    bandwidth due to layer 2 traffic. There are a few situations where there can
    be problems with this definition:

    1. In a situation where layer 2 information (such as VLAN tags or FCS
    octets) is stripped by hardware, an sFlow agent either has to reconstruct
    the stripped layers and include them in the header<>, or adjust the
    frame_length to account for the stripped bytes. If no corrective action is
    taken then an sFlow decoder may overestimate the bytes attributed to higher
    layer protocols.

    2. Trailing information, such as the layer 2 FCS octets can cause problems.
    For example, an encapsulated frame may or may not have the FCS bytes on the
    wire. Since a packet decoder would assume that the frame included a FCS, it
    would incorrectly subtract 4 bytes from payload, underestimating the layer 3
    packet size. The agent could add 4 bytes to the packet length. However, this
    would cause the link utilization to be miscalculated.

    3. There may be proprietary or ambiguous lower layer encapsulations
    associated with tunnels that must be stripped if the header<> is to be fully
    decodeable. Stripping these headers causes the same problems as 1.

    The addition of a new "stripped" counter would seem to resolve these
    problems. It allows the frame_length to continue to be defined as the octets
    on the wire, but provides information on any leading and trailing
    information that were stripped before the header<> was extracted. The
    proposed change is as follows:

    /* Raw Packet Header */
    /* opaque = flow_data; enterprise = 0; format = 1 */

    struct sampled_header {
       header_protocol protocol; /* Format of sampled header */
       unsigned int frame_length; /* Original length of packet before
                                          sampling.
                                          Note: For a layer 2 header_protocol,
                                                length is total number of octets
                                                of data received on the network
                                                (excluding framing bits but
                                                including FCS octets) */
       unsigned int stripped; /* The number of octets removed from the
                                          packet before extracting the header<>.
                                          Trailing protocol information, such as
                                          FCS information, must always be
    stripped.
                                          e.g. a non-encapsulated 802.3 packet
    would
                                               always have stripped=4
                                          Any leading encapsulations that are
                                          ambiguous, or not one of the standard
                                          header_protocol values must be
    stripped.
       opaque header<>; /* Header bytes */
    }

    Any comments?

    Peter



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