From: Peter Phaal (peter.phaal@inmon.com)
Date: 06/25/03
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