added documentation of sflow /doc/sflow

e5cca6ea · bradomyn · 1406bc93 · e5cca6ea · e5cca6ea · e5cca6ea
Commit e5cca6ea authored Feb 22, 2012 by bradomyn
7 changed files
--- a/doc/sflow/how_to_use_sFlow.pdf
+++ b/doc/sflow/how_to_use_sFlow.pdf
--- a/doc/sflow/spec/SFLOW-DATAGRAM5.txt
+++ b/doc/sflow/spec/SFLOW-DATAGRAM5.txt
+/* sFlow Datagram Version 5 */
+
+/* Revision History
+   - version 5 adds support for: 
+         Adds expanded encodings for flow_sample and counter_sample
+         Adds unknown address type;
+         Adds sub-agent support.
+         Adds Packet discard information.
+         Adds support for vendor specific extensions.
+         Adds length information to data fields.
+         Adds length information to sample types. 
+         Define reset semantics for flow_sample,counter_sample sequence no.
+         Splits sFlow datagram definition from flow/counter data definitions.
+            Note: Revision history for sFlow data definitions is now part 
+                  of data definition document. */
+
+/* Address types */
+
+typedef opaque ip_v4[4];
+typedef opaque ip_v6[16];
+    
+enum address_type {
+   UNKNOWN  = 0,
+   IP_V4    = 1,
+   IP_V6    = 2
+}
+
+union address (address_type type) {
+   case UNKNOWN:
+     void;
+   case IP_V4:
+     ip_v4;
+   case IP_V6:
+     ip_v6;
+}
+
+/* Data Format
+     The data_format uniquely identifies the format of an opaque structure in
+     the sFlow specification. A data_format is contructed as follows:
+       - The most significant 20 bits correspond to the SMI Private Enterprise
+         Code of the entity responsible for the structure definition. A value
+         of zero is used to denote standard structures defined by sflow.org.
+       - The least significant 12 bits are a structure format number assigned
+         by the enterprise that should uniquely identify the the format of the 
+         structure.
+
+     There are currently three opaque structures where which data_formats
+      are used:
+       1. sample_data
+       2. counter_data
+       3. flow_data
+
+     Structure format numbers may be re-used within each of these contexts.
+     For example, an (inmon,1) data_format could identify a particular 
+     set of counters when used to describe counter_data, but refer to 
+     a set of flow attributes when used to describe flow_data.
+
+     An sFlow implementor should use the standard structures
+     where possible, even if they can only be partially
+     populated. Vendor specific structures are allowed, but
+     should only be used to supplement the existing
+     structures, or to carry information that hasn't yet
+     been standardized.
+
+     Enterprises are encouraged to publish structure definitions in
+     XDR format to www.sflow.org. A structure description document should
+     contain an XDR structure definition immediately preceded by a comment
+     listing the structure to which it applies, the enterprise number, and
+     the structure number. See the definitions of counter_sample and
+     flow_sample for examples.
+
+     Note: An enterprise which has defined sFlow structures is
+           permitted to extend those structure definitions at the end
+           without changing structure numbers.  Any changes that would
+           alter or invalidate fields in published structure
+           definitions must be implemented using a new structure
+           number.  This policy allows additional data to be added to
+           structures while still maintaining backward compatibility.
+           Applications receiving sFlow data must always use the
+           opaque length information when decoding opaque<> structures
+           so that encountering extended structures will not cause
+           decoding errors. Note that these rules apply to the
+           standard structures as well. */
+
+typedef unsigned int data_format;
+
+/* sFlowDataSource encoded as follows:
+     The most significant byte of the source_id is used to indicate the type
+     of sFlowDataSource:
+        0 = ifIndex
+        1 = smonVlanDataSource
+        2 = entPhysicalEntry
+     The lower three bytes contain the relevant index value. */
+
+typedef unsigned int sflow_data_source;
+
+/* Input/output port information
+     Encoding of interface(s) involved in the packet's path through
+     the device.
+
+     0 if interface is not known.
+     The most significant 2 bits are used to indicate the format of 
+     the 30 bit value.
+
+        - format = 0 single interface
+            value is ifIndex of the interface. The maximum value,
+            0x3FFFFFFF, indicates that there is no input or output
+            interface (according to which field it appears in).
+            This is used in describing traffic which is not
+            bridged, routed, or otherwise sent through the device
+            being monitored by the agent, but which rather
+            originates or terminates in the device itself.  In
+            the input field, this value is used to indicate
+            packets for which the origin was the device itself
+            (e.g. a RIP request packet sent by the device, if it
+            is acting as an IP router).  In the output field,
+            this value is used to indicate packets for which the
+            destination was the device itself (e.g. a RIP
+            response packet (whether unicast or not) received by
+            the device, if it is acting as an IP router).
+            
+        - format = 1 packet discarded
+            value is a reason code. Currently the following codes 
+            are defined:
+                0 - 255 use ICMP Destination Unreachable codes
+                        See www.iana.org for authoritative list.
+                        RFC 1812, section 5.2.7.1 describes the
+                        current codes.  Note that the use of
+                        these codes does not imply that the
+                        packet to which they refer is an IP
+                        packet, or if it is, that an ICMP message
+                        of any kind was generated for it.
+                        Current value are:
+                          0  Net Unreachable
+                          1  Host Unreachable
+                          2  Protocol Unreachable
+                          3  Port Unreachable
+                          4  Fragmentation Needed and 
+                             Don't Fragment was Set
+                          5  Source Route Failed
+                          6  Destination Network Unknown
+                          7  Destination Host Unknown
+                          8  Source Host Isolated
+                          9  Communication with Destination 
+                             Network is Administratively 
+                             Prohibited
+                         10  Communication with Destination Host 
+                             is Administratively Prohibited
+                         11  Destination Network Unreachable for 
+                             Type of Service
+                         12  Destination Host Unreachable for 
+                             Type of Service
+                         13  Communication Administratively 
+                             Prohibited
+                         14  Host Precedence Violation
+                         15  Precedence cutoff in effect
+                256 = unknown
+                257 = ttl exceeded
+                258 = ACL
+                259 = no buffer space
+                260 = RED
+                261 = traffic shaping/rate limiting
+                262 = packet too big (for protocols that don't 
+                      support fragmentation)
+
+             Note: Additional reason codes may be published over
+                   time. An application receiving sFlow must be
+                   prepared to accept additional reason codes.
+                   The authoritative list of reason codes will
+                   be maintained at www.sflow.org
+
+        - format = 2 multiple destination interfaces
+            value is the number of interfaces. A value of 0 
+            indicates an unknown number greater than 1.
+
+      Note: Formats 1 & 2 apply only to an output interface and
+            never to an input interface. A packet is always
+            received on a single (possibly unknown) interface.
+
+      Examples:
+         0x00000002  indicates ifIndex = 2
+         0x00000000  ifIndex unknown.
+         0x40000001  packet discarded because of ACL.
+         0x80000007  indicates a packet sent to 7 interfaces.
+         0x80000000  indicates a packet sent to an unknown number 
+                     of interfaces greater than 1. */
+
+typedef unsigned int interface;
+
+/* Counter and Flow sample formats
+
+   Compact and expand forms of counter and flow samples are defined.
+   An agent must not mix compact/expanded encodings.  If an agent 
+   will never use ifIndex numbers >= 2^24 then it must use compact 
+   encodings for all interfaces.  Otherwise the expanded formats must 
+   be used for all interfaces.
+   
+   While the theoretical range of ifIndex numbers is 2^32,
+   RFC 2863 recommends that ifIndex numbers are allocated using small
+   integer values starting at 1. For most agent implementations the
+   2^24 range of values for ifIndex supported by the compact encoding
+   is more than adequate and its use saves bandwidth. The expanded
+   encodings are provided to support the maximum possible values
+   for ifIndex, even though large ifIndex values are not encouraged. */
+
+struct flow_record {
+   data_format flow_format;         /* The format of sflow_data */       
+   opaque flow_data<>;              /* Flow data uniquely defined
+                                       by the flow_format. */ 
+}
+
+struct counter_record {
+   data_format counter_format;     /* The format of counter_data */           
+   opaque counter_data<>;          /* A block of counters uniquely defined
+                                      by the counter_format. */
+}
+
+/* Compact Format Flow/Counter samples
+      If ifIndex numbers are always < 2^24 then the compact 
+      must be used. */
+
+/* Format of a single flow sample */
+/* opaque = sample_data; enterprise = 0; format = 1 */
+
+struct flow_sample {
+   unsigned int sequence_number;  /* Incremented with each flow sample
+                                     generated by this source_id.
+                                     Note: If the agent resets the
+                                           sample_pool then it must
+                                           also reset the sequence_number.*/
+   sflow_data_source source_id;   /* sFlowDataSource */
+   unsigned int sampling_rate;    /* sFlowPacketSamplingRate */
+   unsigned int sample_pool;      /* Total number of packets that could have
+                                     been sampled (i.e. packets skipped by
+                                     sampling process + total number of
+                                     samples) */
+   unsigned int drops;            /* Number of times that the sFlow agent
+                                     detected that a packet marked to be 
+                                     sampled was dropped due to
+                                     lack of resources. The drops counter
+                                     reports the total number of drops
+                                     detected since the agent was last reset.
+                                     A high drop rate indicates that the 
+                                     management agent is unable to process 
+                                     samples as fast as they are being 
+                                     generated by hardware. Increasing 
+                                     sampling_rate will reduce the drop 
+                                     rate. Note: An agent that cannot 
+                                     detect drops will always report
+                                     zero. */
+
+   interface input;               /* Interface packet was received on. */
+   interface output;              /* Interface packet was sent on. */
+
+   flow_record flow_records<>;    /* Information about a sampled packet */
+}
+
+/* Format of a single counter sample */
+/* opaque = sample_data; enterprise = 0; format = 2 */
+
+struct counters_sample {
+   unsigned int sequence_number;   /* Incremented with each counter sample
+                                      generated by this source_id 
+                                      Note: If the agent resets any of the 
+                                            counters then it must also
+                                            reset the sequence_number.
+                                            In the case of ifIndex-based
+                                            source_id's the sequence
+                                            number must be reset each time
+                                            ifCounterDiscontinuityTime 
+                                            changes. */
+   sflow_data_source source_id;    /* sFlowDataSource */
+   counter_record counters<>;      /* Counters polled for this source */
+}
+
+/* Expanded Format Flow/Counter samples
+      If ifIndex numbers may be >= 2^24 then the expanded 
+      must be used. */
+
+struct sflow_data_source_expanded {
+   unsigned int source_id_type;   /* sFlowDataSource type */
+   unsigned int source_id_index;  /* sFlowDataSource index */
+}
+
+struct interface_expanded {
+  unsigned int format;            /* interface format */
+  unsigned int value;             /* interface value */
+}
+
+/* Format of a single expanded flow sample */
+/* opaque = sample_data; enterprise = 0; format = 3 */
+
+struct flow_sample_expanded {
+   unsigned int sequence_number;  /* Incremented with each flow sample
+                                     generated by this source_id.
+                                     Note: If the agent resets the
+                                           sample_pool then it must
+                                           also reset the sequence_number.*/
+   sflow_data_source_expanded source_id; /* sFlowDataSource */
+   unsigned int sampling_rate;    /* sFlowPacketSamplingRate */
+   unsigned int sample_pool;      /* Total number of packets that could have
+                                     been sampled (i.e. packets skipped by
+                                     sampling process + total number of
+                                     samples) */
+   unsigned int drops;            /* Number of times that the sFlow agent
+                                     detected that a packet marked to be 
+                                     sampled was dropped due to
+                                     lack of resources. The drops counter
+                                     reports the total number of drops
+                                     detected since the agent was last reset.
+                                     A high drop rate indicates that the 
+                                     management agent is unable to process 
+                                     samples as fast as they are being 
+                                     generated by hardware. Increasing 
+                                     sampling_rate will reduce the drop 
+                                     rate. Note: An agent that cannot 
+                                     detect drops will always report
+                                     zero. */
+
+   interface_expanded input;      /* Interface packet was received on. */
+   interface_expanded output;     /* Interface packet was sent on. */
+
+   flow_record flow_records<>;    /* Information about a sampled packet */
+}
+
+/* Format of a single expanded counter sample */
+/* opaque = sample_data; enterprise = 0; format = 4 */
+
+struct counters_sample_expanded {
+   unsigned int sequence_number;   /* Incremented with each counter sample
+                                      generated by this source_id 
+                                      Note: If the agent resets any of the 
+                                            counters then it must also
+                                            reset the sequence_number.
+                                            In the case of ifIndex-based
+                                            source_id's the sequence
+                                            number must be reset each time
+                                            ifCounterDiscontinuityTime 
+                                            changes. */
+   sflow_data_source_expanded source_id; /* sFlowDataSource */
+   counter_record counters<>;      /* Counters polled for this source */
+}
+
+/* Format of a sample datagram */
+
+struct sample_record {
+   data_format sample_type;       /* Specifies the type of sample data */
+   opaque sample_data<>;          /* A structure corresponding to the
+                                     sample_type */
+}
+
+/* Header information for sFlow version 5 datagrams
+
+   The sub-agent field is used when an sFlow agent is implemented on a
+   distributed architecture and where it is impractical to bring the
+   samples to a single point for transmission.
+
+   However, it is strongly recommended that wherever possible the sub-agent
+   mechanism not be used. If multiple processors are available within a device
+   the various tasks associated with creating flow and counter samples can be
+   distributed among the processors. However, the agent should be architected
+   so that all the samples are marshalled into a single datagram stream. The
+   final marshalling task involved very little processing, but has important
+   benefits in making the overall sFlow system scalable. By reducing the
+   number of UDP packets and packet streams, the protocol overheads associated
+   with sFlow are significantly reduced at the receiver.
+
+   Each sFlowDataSource must be associated with only one sub-agent. The
+   association between sFlowDataSource and sub-agent must remain 
+   constant for the entire duration of an sFlow session. */
+
+struct sample_datagram_v5 {
+   address agent_address          /* IP address of sampling agent, 
+                                     sFlowAgentAddress. */
+   unsigned int sub_agent_id;     /* Used to distinguishing between datagram
+                                     streams from separate agent sub entities
+                                     within an device. */
+   unsigned int sequence_number;  /* Incremented with each sample datagram
+                                     generated by a sub-agent within an
+                                     agent. */
+   unsigned int uptime;           /* Current time (in milliseconds since device
+                                     last booted). Should be set as close to
+                                     datagram transmission time as possible.
+                                     Note: While a sub-agents should try and
+                                           track the global sysUptime value
+                                           a receiver of sFlow packets must
+                                           not assume that values are
+                                           synchronised between sub-agents. */
+   sample_record samples<>;        /* An array of sample records */
+}
+
+enum datagram_version {
+   VERSION5 = 5
+}
+
+union sample_datagram_type (datagram_version version) {
+   case VERSION5:
+      sample_datagram_v5 datagram;
+}
+
+struct sample_datagram {
+   sample_datagram_type version;
+}
+
--- a/doc/sflow/spec/SFLOW-MIB5.txt
+++ b/doc/sflow/spec/SFLOW-MIB5.txt
+SFLOW-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+      
+      MODULE-IDENTITY, OBJECT-TYPE, Integer32, enterprises 
+              FROM SNMPv2-SMI
+      TEXTUAL-CONVENTION
+              FROM SNMPv2-TC
+      SnmpAdminString
+              FROM SNMP-FRAMEWORK-MIB
+      OwnerString
+              FROM RMON-MIB
+      InetAddressType, InetAddress
+              FROM INET-ADDRESS-MIB
+      MODULE-COMPLIANCE, OBJECT-GROUP
+              FROM SNMPv2-CONF;
+
+      sFlowMIB  MODULE-IDENTITY 
+        LAST-UPDATED "200309240000Z"   -- September 24, 2003
+        ORGANIZATION "sFlow.org"
+        CONTACT-INFO
+               "Peter Phaal
+                sFlow.org
+                http://www.sflow.org/
+
+                Tel:  +1-415-283-3260
+                Email: peter.phaal@sflow.org"
+
+        DESCRIPTION
+                "The MIB module for managing the generation and transportation
+                 of sFlow data records."
+
+        --
+        -- Revision History
+        --
+
+        REVISION    "200310180000Z"     -- November 18, 2003
+        DESCRIPTION
+                "Version 1.3 (draft 5)
+
+                 Allow set to SFlowReceiver if it doesn't change
+                 value."
+
+        REVISION    "200309240000Z"     --  September 24, 2003
+        DESCRIPTION
+                "Version 1.3 (draft 4)
+
+                 Default value of sFlowRcvrAddress should be '00000000' h.
+                 Default value of sFlowCpReceiver should be 0."
+
+        REVISION    "200304080000Z"     --  April 8, 2003
+        DESCRIPTION
+                "Version 1.3 (draft 3)
+
+                 Clarify semantics of counter polling interval, 
+                 sFlowCpInterval."
+
+        REVISION    "200209170000Z"     -- September 17, 2002
+        DESCRIPTION
+                "Version 1.3 (draft 2)
+
+                 Adds support for multiple sFlow samplers per sFlowDataSource.
+                 Moved to sflow.org enterprise number.
+                 Splits flow sampling, counter polling and receiver 
+                 specification into separate tables."
+
+        REVISION    "200107310000Z"     -- July 31, 2001 
+        DESCRIPTION 
+                "Version 1.2
+
+                 Brings MIB into SMI v2 compliance."
+
+        REVISION    "200105010000Z"      -- May 1, 2001
+        DESCRIPTION
+                 "Version 1.1
+
+                  Adds sfDatagramVersion."
+
+        ::= { enterprises sflow(14706) 1 }
+
+      sFlowAgent OBJECT IDENTIFIER ::= { sFlowMIB 1 }
+
+      SFlowDataSource ::= TEXTUAL-CONVENTION
+              STATUS      current
+              DESCRIPTION
+                "Identifies a source of sFlow data.
+
+                The following data source types are currently defined:
+
+                - ifIndex.<I>
+                SFlowDataSources of this traditional form are called
+                'port-based'. Ideally the sampling entity will perform 
+                sampling on all flows originating from or destined to 
+                the specified interface. However, if the switch architecture 
+                only allows input or output sampling then the sampling agent 
+                is permitted to only sample input flows input or output flows. 
+                Each packet must only be considered once for sampling, 
+                irrespective of the number of ports it will be forwarded to.
+                Note: Port 0 is used to indicate that all ports on the device
+                      are represented by a single data source.
+                      - sFlowFsPacketSamplingRate applies to all ports on the
+                        device capable of packet sampling.
+
+                - smonVlanDataSource.<V>
+                An SFlowDataSource of this form refers to a 'Packet-based VLAN'
+                and is called a 'VLAN-based' dataSource. <V> is the VLAN
+                ID as defined by the IEEE 802.1Q standard. The
+                value is between 1 and 4094 inclusive, and it represents
+                an 802.1Q VLAN-ID with global scope within a given
+                bridged domain.
+                Sampling is performed on all packets received that are part
+                of the specified VLAN (no matter which port they arrived on).
+                Each packet will only be considered once for sampling,
+                irrespective of the number of ports it will be forwarded to.
+                
+                - entPhysicalEntry.<N>
+                An SFlowDataSource of this form refers to a physical entity 
+                within the agent (e.g. entPhysicalClass = backplane(4)) and 
+                is called an 'entity-based' dataSource. Sampling is performed 
+                on all packets entering the resource (e.g. If the backplane 
+                is being sampled, all packets transmitted onto the backplane 
+                will be considered as single candidates for sampling 
+                irrespective of the number of ports they ultimately reach).
+
+                Note: Since each SFlowDataSource operates independently a 
+                      packet that crosses multiple DataSources may generate 
+                      multiple flow records."
+              SYNTAX      OBJECT IDENTIFIER
+
+      SFlowInstance ::= TEXTUAL-CONVENTION
+              STATUS      current
+              DESCRIPTION
+                "If more than one sFlow sampler is available for this
+                 SFlowDataSource then individual samplers are distinguished
+                 using the SFlowInstance variable. The value of 
+                 SFlowInstance ranges from 1..n where n is the number of
+                 samplers associated with this SFlowDataSource.
+
+                 Note: Each sFlow sampler instance must operate
+                       independently of all other instances. Setting
+                       an attribute of one sampler must not alter the
+                       the behavior and settings of other sampler
+                       instances."
+              SYNTAX      Integer32 (1..65535)
+
+      SFlowReceiver ::= TEXTUAL-CONVENTION
+              STATUS       current
+              DESCRIPTION
+                "Identify the sFlow receiver associated with this resource.
+
+                 A value of zero indicates that this resource is available.
+                 If non-zero the value must correspond to a valid, active 
+                 sFlowRcvrIndex.
+
+                 If the value is currently zero it may be set to any
+                 active entry in the sFlowRcvrTable. If the value is
+                 not zero then a set to anything other than zero or
+                 its current value will result in an SNMP error (bad value).
+
+                 Setting to zero frees the resource and returns all the
+                 values in this entry to their default values.
+
+                 If an entry in the sFlowRcvrTable expires, either
+                 because the sFlowRcvrOwner is set to the empty
+                 string or because the sFlowRcvrTimeout reaches zero, then
+                 the agent must mark all associated resources as available
+                 (by setting the associated SFlowReceiver entry to zero)
+                 and all values in these records must be restored to their
+                 default values.
+
+                 This mechanism provides no enforcement and relies on the
+                 cooperation of management entities in order to ensure that
+                 competition for a resource is fairly resolved. A management
+                 entity should not make any changes to a resource
+                 without first aquiring it by successfully writing its
+                 sFlowRcvrIndex value as the SFlowReceiver for the resource."
+              SYNTAX       Integer32
+      
+      sFlowVersion OBJECT-TYPE
+              SYNTAX      SnmpAdminString
+              MAX-ACCESS  read-only
+              STATUS      current
+              DESCRIPTION
+                "Uniquely identifies the version and implementation of this MIB.
+                 The version string must have the following structure:
+                    <MIB Version>;<Organization>;<Software Revision>
+                 where:
+                    <MIB Version>  must be '1.3', the version of this MIB.
+                    <Organization> the name of the organization responsible
+                                     for the agent implementation.
+                    <Revision>     the specific software build of this agent.
+
+                 As an example, the string '1.3;InMon Corp.;2.1.1' indicates
+                 that this agent implements version '1.2' of the SFLOW MIB, that
+                 it was developed by 'InMon Corp.' and that the software build
+                 is '2.1.1'.
+
+                 The MIB Version will change with each revision of the SFLOW
+                 MIB.
+
+                 Management entities must check the MIB Version and not attempt
+                 to manage agents with MIB Versions greater than that for which
+                 they were designed.
+
+                 Note: The sFlow Datagram Format has an independent version
+                       number which may change independently from <MIB Version>.
+                       <MIB Version> applies to the structure and semantics of
+                       the SFLOW MIB only."
+              DEFVAL { "1.3;;" }
+              ::= { sFlowAgent 1 }
+
+      sFlowAgentAddressType OBJECT-TYPE
+              SYNTAX      InetAddressType
+              MAX-ACCESS  read-only
+              STATUS      current
+              DESCRIPTION
+                "The address type of the address associated with this agent.
+                 Only ipv4 and ipv6 types are supported."
+              ::= { sFlowAgent 2 }
+
+      sFlowAgentAddress OBJECT-TYPE
+              SYNTAX      InetAddress
+              MAX-ACCESS  read-only
+              STATUS      current
+              DESCRIPTION
+                "The IP address associated with this agent. In the case of a
+                 multi-homed agent, this should be the loopback address of the
+                 agent. The sFlowAgent address must provide SNMP connectivity
+                 to the agent. The address should be an invariant that does not
+                 change as interfaces are reconfigured, enabled, disabled,
+                 added or removed. A manager should be able to use the 
+                 sFlowAgentAddress as a unique key that will identify this
+                 agent over extended periods of time so that a history can
+                 be maintained."
+             ::= { sFlowAgent 3 }   
+
+      -- 
+      -- Receiver Table
+      --
+
+      sFlowRcvrTable OBJECT-TYPE
+              SYNTAX      SEQUENCE OF SFlowRcvrEntry
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "A table of the receivers of sFlow information."
+              ::= { sFlowAgent 4 }
+
+      sFlowRcvrEntry OBJECT-TYPE
+              SYNTAX      SFlowRcvrEntry
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "Attributes of an sFlow Receiver."
+              INDEX { sFlowRcvrIndex }
+              ::= { sFlowRcvrTable 1 }
+
+      SFlowRcvrEntry ::= SEQUENCE {
+              sFlowRcvrIndex                    Integer32,
+              sFlowRcvrOwner                    OwnerString,
+              sFlowRcvrTimeout                  Integer32,
+              sFlowRcvrMaximumDatagramSize      Integer32,
+              sFlowRcvrAddressType              InetAddressType,
+              sFlowRcvrAddress                  InetAddress,
+              sFlowRcvrPort                     Integer32,
+              sFlowRcvrDatagramVersion          Integer32
+      }
+
+      sFlowRcvrIndex OBJECT-TYPE
+              SYNTAX      Integer32 (1..65535)
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "Index into sFlowReceiverTable."
+              ::= { sFlowRcvrEntry 1 }
+
+      sFlowRcvrOwner OBJECT-TYPE
+              SYNTAX      OwnerString
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The entity making use of this sFlowRcvrTable entry. The empty
+                 string indicates that the entry is currently unclaimed.
+                 An entity wishing to claim an sFlowRcvrTable entry must ensure
+                 that the entry is unclaimed before trying to claim it.
+                 The entry is claimed by setting the owner string. The entry
+                 must be claimed before any changes can be made to other sampler
+                 objects.
+
+                 In order to avoid a race condition, the entity taking control
+                 of the sampler must set both the owner and a value for
+                 sFlowRcvrTimeout in the same SNMP set request.
+
+                 When a management entity is finished using the sampler,
+                 it should set the value of sFlowRcvrOwner back to unclaimed. 
+                 The agent must restore all other entities this row to their
+                 default values when the owner is set to unclaimed. It must
+                 also free all other resources associated with this 
+                 sFlowRcvrTable entry.
+
+                 This mechanism provides no enforcement and relies on the
+                 cooperation of management entities in order to ensure that
+                 competition for a receiver entry is fairly resolved."
+              DEFVAL { "" }
+              ::= { sFlowRcvrEntry 2 }
+
+      sFlowRcvrTimeout OBJECT-TYPE
+              SYNTAX      Integer32
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The time (in seconds) remaining before the sampler is released
+                 and stops sampling. When set, the owner establishes control
+                 for the specified period. When read, the remaining time in the
+                 interval is returned.
+
+                 A management entity wanting to maintain control of the sampler
+                 is responsible for setting a new value before the old one
+                 expires.
+
+                 When the interval expires, the agent is responsible for 
+                 restoring all other entities in this row to their default 
+                 values. It must also free all other resources associated with
+                 this sFlowRcvrTable entry." 
+              DEFVAL { 0 }
+              ::= { sFlowRcvrEntry 3 } 
+
+      sFlowRcvrMaximumDatagramSize OBJECT-TYPE
+              SYNTAX      Integer32
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                 "The maximum number of data bytes that can be sent in a single
+                  sample datagram. The manager should set this value to avoid
+                  fragmentation of the sFlow datagrams."
+              DEFVAL { 1400 }
+              ::= { sFlowRcvrEntry 4 }
+
+      sFlowRcvrAddressType OBJECT-TYPE
+              SYNTAX      InetAddressType
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The type of sFlowRcvrCollectorAddress."
+              DEFVAL { ipv4 }
+              ::= { sFlowRcvrEntry 5 }
+
+      sFlowRcvrAddress OBJECT-TYPE
+              SYNTAX      InetAddress
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The IP address of the sFlow collector.
+                 If set to 0.0.0.0 not sFlow datagrams will be sent."
+              DEFVAL { '00000000'h }  -- 0.0.0.0
+              ::= { sFlowRcvrEntry 6 }
+
+      sFlowRcvrPort OBJECT-TYPE
+              SYNTAX      Integer32
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The destination port for sFlow datagrams."
+              DEFVAL { 6343 }
+              ::= { sFlowRcvrEntry 7 }
+
+      sFlowRcvrDatagramVersion OBJECT-TYPE
+              SYNTAX      Integer32
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The version of sFlow datagrams that should be sent.
+
+                 When set to a value not support by the agent, the agent should
+                 adjust the value to the highest supported value less than the
+                 requested value, or return an SNMP bad value error if no 
+                 such value exists."
+              DEFVAL { 5 }
+              ::= { sFlowRcvrEntry 8 }                
+
+      -- 
+      -- Flow Sampling Table
+      --
+
+      sFlowFsTable OBJECT-TYPE
+              SYNTAX      SEQUENCE OF SFlowFsEntry
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "A table of the flow samplers within a device."
+              ::= { sFlowAgent 5 }
+
+      sFlowFsEntry OBJECT-TYPE
+              SYNTAX      SFlowFsEntry
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "Attributes of a flow sampler."
+              INDEX { sFlowFsDataSource, sFlowFsInstance }
+              ::= { sFlowFsTable 1 }
+
+      SFlowFsEntry ::= SEQUENCE {
+              sFlowFsDataSource               SFlowDataSource,
+              sFlowFsInstance                 SFlowInstance,
+              sFlowFsReceiver                 SFlowReceiver,
+              sFlowFsPacketSamplingRate       Integer32,
+              sFlowFsMaximumHeaderSize        Integer32
+      }
+
+      sFlowFsDataSource OBJECT-TYPE
+              SYNTAX      SFlowDataSource
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "sFlowDataSource for this flow sampler."
+              ::= { sFlowFsEntry 1 }
+
+      sFlowFsInstance OBJECT-TYPE
+              SYNTAX      SFlowInstance
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "The sFlow instance for this flow sampler."
+              ::= { sFlowFsEntry 2 }
+
+      sFlowFsReceiver OBJECT-TYPE
+              SYNTAX      SFlowReceiver
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The SFlowReceiver for this flow sampler."
+              DEFVAL { 0 }
+              ::= { sFlowFsEntry 3 } 
+
+      sFlowFsPacketSamplingRate OBJECT-TYPE
+              SYNTAX      Integer32
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The statistical sampling rate for packet sampling from this
+                 source. 
+
+                 Set to N to sample 1/Nth of the packets in the monitored flows.
+                 An agent should choose its own algorithm to introduce variance
+                 into the sampling so that exactly every Nth packet is not
+                 counted. A sampling rate of 1 counts all packets. A sampling
+                 rate of 0 disables sampling.
+                 
+                 The agent is permitted to have minimum and maximum allowable
+                 values for the sampling rate. A minimum rate lets the agent
+                 designer set an upper bound on the overhead associated with
+                 sampling, and a maximum rate may be the result of hardware
+                 restrictions (such as counter size). In addition not all values
+                 between the maximum and minimum may be realizable as the 
+                 sampling rate (again because of implementation considerations).
+
+                 When the sampling rate is set the agent is free to adjust the
+                 value so that it lies between the maximum and minimum values
+                 and has the closest achievable value.
+
+                 When read, the agent must return the actual sampling rate it
+                 will be using (after the adjustments previously described). The
+                 sampling algorithm must converge so that over time the number
+                 of packets sampled approaches 1/Nth of the total number of
+                 packets in the monitored flows."
+              DEFVAL { 0 }
+              ::= { sFlowFsEntry 4 }
+
+      sFlowFsMaximumHeaderSize OBJECT-TYPE
+              SYNTAX      Integer32
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The maximum number of bytes that should be copied from a
+                 sampled packet. The agent may have an internal maximum and
+                 minimum permissible sizes. If an attempt is made to set this 
+                 value outside the permissible range then the agent should 
+                 adjust the value to the closest permissible value."
+              DEFVAL { 128 }
+              ::= { sFlowFsEntry 5 }
+
+      --
+      -- Counter Polling Table
+      --
+      
+
+      sFlowCpTable OBJECT-TYPE
+              SYNTAX      SEQUENCE OF SFlowCpEntry
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "A table of the counter pollers within a device."
+              ::= { sFlowAgent 6 }
+
+      sFlowCpEntry OBJECT-TYPE
+              SYNTAX      SFlowCpEntry
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "Attributes of a counter poller."
+              INDEX { sFlowCpDataSource, sFlowCpInstance }
+              ::= { sFlowCpTable 1 }
+
+      SFlowCpEntry ::= SEQUENCE {
+              sFlowCpDataSource               SFlowDataSource,
+              sFlowCpInstance                 SFlowInstance,
+              sFlowCpReceiver                 SFlowReceiver,
+              sFlowCpInterval                 Integer32
+      }
+
+      sFlowCpDataSource OBJECT-TYPE
+              SYNTAX      SFlowDataSource
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "Identifies the source of the data for the counter poller."
+              ::= { sFlowCpEntry 1 }
+
+      sFlowCpInstance OBJECT-TYPE
+              SYNTAX      SFlowInstance
+              MAX-ACCESS  not-accessible
+              STATUS      current
+              DESCRIPTION
+                "The sFlowInstance for this counter poller."
+              ::= { sFlowCpEntry 2 }
+
+      sFlowCpReceiver OBJECT-TYPE
+              SYNTAX      SFlowReceiver
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The SFlowReciever associated with this counter poller."
+              DEFVAL { 0 }
+              ::= { sFlowCpEntry 3 }
+
+      sFlowCpInterval OBJECT-TYPE
+              SYNTAX      Integer32
+              MAX-ACCESS  read-write
+              STATUS      current
+              DESCRIPTION
+                "The maximum number of seconds between successive samples of the
+                 counters associated with this data source. A sampling interval 
+                 of 0 disables counter sampling.
+
+                 The agent is permitted to have minimum and maximum allowable
+                 values for the counter polling interval. A minimum interval
+                 lets the agent designer set an upper bound on the overhead
+                 associated with polling, and a maximum interval may be the
+                 result of implementation restrictions (such as counter size).
+                 In addition not all values between the maximum and minimum may
+                 be realizable as the sampling interval (again because of
+                 implementation considerations).
+
+                 When the sampling rate is set the agent is free to adjust the
+                 value so that it lies between the maximum and minimum values
+                 and has the closest achievable value.
+
+                 When read, the agent must return the actual sampling interval
+                 it will be using (after the adjustments previously described).
+                 The sampling algorithm must converge so that over time the
+                 number of packets sampled approaches 1/Nth of the total number
+                 of packets in the monitored flows."
+              DEFVAL { 0 }
+              ::= { sFlowCpEntry 4 }
+
+       --
+       -- Compliance Statements
+       --
+
+      sFlowMIBConformance OBJECT IDENTIFIER ::= { sFlowMIB 2 }
+      sFlowMIBGroups      OBJECT IDENTIFIER ::= { sFlowMIBConformance 1 }
+      sFlowMIBCompliances OBJECT IDENTIFIER ::= { sFlowMIBConformance 2 }
+
+      sFlowCompliance MODULE-COMPLIANCE
+              STATUS      current
+              DESCRIPTION
+                "Compliance statements for the sFlow Agent."
+
+              MODULE -- this module
+                  MANDATORY-GROUPS { sFlowAgentGroup }
+
+                  OBJECT     sFlowAgentAddressType
+                  SYNTAX     InetAddressType { ipv4(1) }
+                  DESCRIPTION
+                    "Agents need only support ipv4."
+
+                  OBJECT sFlowRcvrAddressType
+                  SYNTAX InetAddressType { ipv4(1) }
+                  DESCRIPTION
+                    "Agents need only support ipv4."
+              
+              ::= { sFlowMIBCompliances 1 }
+
+      sFlowAgentGroup OBJECT-GROUP
+              OBJECTS { sFlowVersion, sFlowAgentAddressType, sFlowAgentAddress,
+                        sFlowRcvrOwner, sFlowRcvrTimeout, 
+                        sFlowRcvrMaximumDatagramSize, sFlowRcvrAddressType, 
+                        sFlowRcvrAddress, sFlowRcvrPort, 
+                        sFlowRcvrDatagramVersion, sFlowFsReceiver, 
+                        sFlowFsPacketSamplingRate, sFlowFsMaximumHeaderSize, 
+                        sFlowCpReceiver, sFlowCpInterval }
+               STATUS current
+               DESCRIPTION
+                 "A collection of objects for managing the generation and
+                  transportation of sFlow data records."
+                ::= { sFlowMIBGroups 1 }
+ 
+END
+
--- a/doc/sflow/spec/SFLOW-STRUCTS5.txt
+++ b/doc/sflow/spec/SFLOW-STRUCTS5.txt
+/* Standard sFlow data formats */
+
+/* Revision History
+   - version 5
+         Clarified extended_switch definitions for untagged ports
+         Added CPU, memory utilization information
+         Added mpls tunnel, virtual circuit and fec information
+         Clarified next_hop definitions
+         Added stripped count to sampled_header
+         Added POS header_protocol
+         Added BGP next hop router
+         Clarify definition of packet length
+         Remove limit on packet header size
+         Adds host field to URL extension and clarifies url_direction
+         Define url as http request-line
+         Adds character set information to user data
+         Adds NAT support
+         Adds MPLS information
+   - version 4 adds support for BGP communities
+   - version 3 adds support for extended_url information */
+
+/* Enterprise = 0 refers to standard sFlow structures. An
+   sFlow implementor should use the standard structures
+   where possible, even if they can only be partially
+   populated. Vendor specific structures are allowed, but
+   should only be used to supplement the existing
+   structures, or to carry information that hasn't yet
+   been standardized.
+
+   The following values should be used for fields that are
+   unknown (unless otherwise indicated in the structure
+   definitions).
+      - Unknown integer value. Use a value of 0 to indicate that
+        a value is unknown.
+      - Unknown counter. Use the maximum counter value to indicate
+        that the counter is not available. Within any given sFlow
+        session a particular counter must be always available, or
+        always unavailable. An available counter may temporarily
+        have the max value just before it rolls to zero. This is
+        permitted.
+      - Unknown string. Use the zero length empty string. */
+
+
+/* Flow Data Types 
+
+   A flow_sample must contain packet header information. The
+   prefered format for reporting packet header information is
+   the sampled_header. However, if the packet header is not
+   available to the sampling process then one or more of
+   sampled_ethernet, sampled_ipv4, sampled_ipv6 may be used. */
+    
+
+/* Packet Header Data */
+
+/* The header_protocol enumeration may be expanded over time.
+   Applications receiving sFlow must be prepared to receive
+   sampled_header structures with unknown sampled_header values.
+
+   The authoritative list of protocol numbers will be maintained
+   at www.sflow.org */
+
+enum header_protocol {
+   ETHERNET-ISO88023    = 1,
+   ISO88024-TOKENBUS    = 2,
+   ISO88025-TOKENRING   = 3,
+   FDDI                 = 4,
+   FRAME-RELAY          = 5,
+   X25                  = 6,
+   PPP                  = 7,
+   SMDS                 = 8,                
+   AAL5                 = 9,
+   AAL5-IP              = 10, /* e.g. Cisco AAL5 mux */
+   IPv4                 = 11,
+   IPv6                 = 12,
+   MPLS                 = 13,
+   POS                  = 14  /* RFC 1662, 2615 */
+}   
+
+/* 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).
+                                            Hardware limitations may
+                                            prevent an exact reporting
+                                            of the underlying frame length,
+                                            but an agent should attempt to
+                                            be as accurate as possible. Any
+                                            octets added to the frame_length
+                                            to compensate for encapsulations
+                                            removed by the underlying hardware
+                                            must also be added to the stripped
+                                            count. */
+   unsigned int stripped;          /* The number of octets removed from
+                                      the packet before extracting the
+                                      header<> octets. Trailing encapsulation
+                                      data corresponding to any leading
+                                      encapsulations that were stripped must
+                                      also be stripped. Trailing encapsulation
+                                      data for the outermost protocol layer
+                                      included in the sampled header must be
+                                      stripped.
+
+                                      In the case of a non-encapsulated 802.3
+                                      packet stripped >= 4 since VLAN tag
+                                      information might have been stripped off
+                                      in addition to the FCS.
+
+                                      Outer encapsulations that are ambiguous,
+                                      or not one of the standard header_protocol
+                                      must be stripped. */
+   opaque header<>;                /* Header bytes */
+}
+
+typedef opaque mac[6];
+
+/* Ethernet Frame Data */
+/* opaque = flow_data; enterprise = 0; format = 2 */
+
+struct sampled_ethernet {
+     unsigned int length;   /* The length of the MAC packet received on the
+                               network, excluding lower layer encapsulations
+                               and framing bits but including FCS octets */
+     mac src_mac;           /* Source MAC address */
+     mac dst_mac;           /* Destination MAC address */
+     unsigned int type;     /* Ethernet packet type */
+}
+
+/* Packet IP version 4 data */
+/* opaque = flow_data; enterprise = 0; format = 3 */
+
+struct sampled_ipv4 {
+   unsigned int length;     /* The length of the IP packet excluding 
+                               lower layer encapsulations */
+   unsigned int protocol;   /* IP Protocol type
+                               (for example, TCP = 6, UDP = 17) */
+   ip_v4 src_ip;            /* Source IP Address */
+   ip_v4 dst_ip;            /* Destination IP Address */
+   unsigned int src_port;   /* TCP/UDP source port number or equivalent */
+   unsigned int dst_port;   /* TCP/UDP destination port number or equivalent */
+   unsigned int tcp_flags;  /* TCP flags */
+   unsigned int tos;        /* IP type of service */
+}
+
+/* Packet IP Version 6 Data */
+/* opaque = flow_data; enterprise = 0; format = 4 */
+
+struct sampled_ipv6 {
+   unsigned int length;     /* The length of the IP packet excluding
+                               lower layer encapsulations */
+   unsigned int protocol;   /* IP next header
+                               (for example, TCP = 6, UDP = 17) */
+   ip_v6 src_ip;            /* Source IP Address */
+   ip_v6 dst_ip;            /* Destination IP Address */
+   unsigned int src_port;   /* TCP/UDP source port number or equivalent */
+   unsigned int dst_port;   /* TCP/UDP destination port number or equivalent */
+   unsigned int tcp_flags;  /* TCP flags */
+   unsigned int priority;   /* IP priority */
+}
+
+
+/* Extended Flow Data 
+
+   Extended data types provide supplimentary information about the
+   sampled packet. All applicable extended flow records should be 
+   included with each flow sample. */
+
+/* Extended Switch Data */
+/* opaque = flow_data; enterprise = 0; format = 1001 */
+/* Note: For untagged ingress ports, use the assigned vlan and priority
+         of the port for the src_vlan and src_priority values.
+         For untagged egress ports, use the values for dst_vlan and
+         dst_priority that would have been placed in the 802.Q tag
+         had the egress port been a tagged member of the VLAN instead
+         of an untagged member. */
+
+struct extended_switch {
+   unsigned int src_vlan;     /* The 802.1Q VLAN id of incoming frame */
+   unsigned int src_priority; /* The 802.1p priority of incoming frame */
+   unsigned int dst_vlan;     /* The 802.1Q VLAN id of outgoing frame */
+   unsigned int dst_priority; /* The 802.1p priority of outgoing frame */
+}
+
+/* IP Route Next Hop
+   ipForwardNextHop (RFC 2096) for IPv4 routes.
+   ipv6RouteNextHop (RFC 2465) for IPv6 routes. */
+
+typedef next_hop address;
+
+/* Extended Router Data */
+/* opaque = flow_data; enterprise = 0; format = 1002 */
+
+struct extended_router {
+   next_hop nexthop;            /* IP address of next hop router */
+   unsigned int src_mask_len;   /* Source address prefix mask
+                                   (expressed as number of bits) */
+   unsigned int dst_mask_len;   /* Destination address prefix mask
+                                   (expressed as number of bits) */
+}
+
+enum as_path_segment_type {
+   AS_SET      = 1,            /* Unordered set of ASs */
+   AS_SEQUENCE = 2             /* Ordered set of ASs */
+}
+
+union as_path_type (as_path_segment_type) {
+   case AS_SET:
+      unsigned int as_set<>;
+   case AS_SEQUENCE:
+      unsigned int as_sequence<>;
+}
+
+/* Extended Gateway Data */
+/* opaque = flow_data; enterprise = 0; format = 1003 */
+
+struct extended_gateway {
+   next_hop nexthop;           /* Address of the border router that should
+                                  be used for the destination network */
+   unsigned int as;            /* Autonomous system number of router */
+   unsigned int src_as;        /* Autonomous system number of source */
+   unsigned int src_peer_as;   /* Autonomous system number of source peer */
+   as_path_type dst_as_path<>; /* Autonomous system path to the destination */
+   unsigned int communities<>; /* Communities associated with this route */
+   unsigned int localpref;     /* LocalPref associated with this route */
+}
+
+/* Character Set
+     MIBEnum value of character set used to encode a string - See RFC 2978
+     Where possible UTF-8 encoding (MIBEnum=106) should be used. A value
+     of zero indicates an unknown encoding. */
+
+typedef unsigned int charset;
+
+/* Extended User Data */
+/* opaque = flow_data; enterprise = 0; format = 1004 */
+
+struct extended_user {
+   charset src_charset;        /* Character set for src_user */
+   opaque src_user<>;          /* User ID associated with packet source */
+   charset dst_charset;        /* Character set for dst_user */
+   opaque dst_user<>;          /* User ID associated with packet destination */
+}
+
+enum url_direction {
+   src    = 1,                 /* Source address is server */
+   dst    = 2                  /* Destination address is server */
+}
+
+/* Extended URL Data */
+/* opaque = flow_data; enterprise = 0; format = 1005 */
+
+struct extended_url {
+   url_direction direction;    /* Direction of connection */
+   string url<>;               /* The HTTP request-line (see RFC 2616) */
+   string host<>;              /* The host field from the HTTP header */
+}
+
+/* MPLS label stack
+    - Empty stack may be returned if values unknown
+    - If only innermost label is known then stack may contain single entry
+    - See RFC 3032 for label encoding
+    - Labels in network order */
+typedef int label_stack<>;
+
+/* Extended MPLS Data */
+/* opaque = flow_data; enterprise = 0; format = 1006 */
+
+struct extended_mpls { 
+   next_hop nexthop;           /* Address of the next hop */ 
+   label_stack in_stack;       /* Label stack of received packet */ 
+   label_stack out_stack;      /* Label stack for transmitted packet */ 
+}
+
+/* Extended NAT Data
+   Packet header records report addresses as seen at the sFlowDataSource.
+   The extended_nat structure reports on translated source and/or destination
+   addesses for this packet. If an address was not translated it should 
+   be equal to that reported for the header. */
+/* opaque = flow_data; enterprise = 0; format = 1007 */
+
+struct extended_nat {
+     address src_address;            /* Source address */
+     address dst_address;            /* Destination address */
+}
+
+/* Extended MPLS Tunnel */
+/* opaque = flow_data; enterprise = 0; format = 1008 */
+
+struct extended_mpls_tunnel {
+   string tunnel_lsp_name<>;   /* Tunnel name */
+   unsigned int tunnel_id;     /* Tunnel ID */
+   unsigned int tunnel_cos;    /* Tunnel COS value */
+}
+
+/* Extended MPLS VC */
+/* opaque = flow_data; enterprise = 0; format = 1009 */
+
+struct extended_mpls_vc {
+   string vc_instance_name<>;  /* VC instance name */
+   unsigned int vll_vc_id;     /* VLL/VC instance ID */
+   unsigned int vc_label_cos;  /* VC Label COS value */
+}
+
+/* Extended MPLS FEC
+    - Definitions from MPLS-FTN-STD-MIB mplsFTNTable */
+/* opaque = flow_data; enterprise = 0; format = 1010 */
+
+struct extended_mpls_FTN {
+   string mplsFTNDescr<>;
+   unsigned int mplsFTNMask;
+}
+
+/* Extended MPLS LVP FEC
+    - Definition from MPLS-LDP-STD-MIB mplsFecTable
+    Note: mplsFecAddrType, mplsFecAddr information available
+          from packet header */
+/* opaque = flow_data; enterprise = 0; format = 1011 */
+
+struct extended_mpls_LDP_FEC {
+   unsigned int mplsFecAddrPrefixLength;
+} 
+
+/* Extended VLAN tunnel information 
+   Record outer VLAN encapsulations that have 
+   been stripped. extended_vlantunnel information 
+   should only be reported if all the following conditions are satisfied: 
+     1. The packet has nested vlan tags, AND 
+     2. The reporting device is VLAN aware, AND 
+     3. One or more VLAN tags have been stripped, either 
+        because they represent proprietary encapsulations, or 
+        because switch hardware automatically strips the outer VLAN 
+        encapsulation. 
+   Reporting extended_vlantunnel information is not a substitute for 
+   reporting extended_switch information. extended_switch data must 
+   always be reported to describe the ingress/egress VLAN information 
+   for the packet. The extended_vlantunnel information only applies to 
+   nested VLAN tags, and then only when one or more tags has been 
+   stripped. */ 
+/* opaque = flow_data; enterprise = 0; format = 1012 */ 
+extended_vlantunnel { 
+  unsigned int stack<>;  /* List of stripped 802.1Q TPID/TCI layers. Each 
+                            TPID,TCI pair is represented as a single 32 bit 
+                            integer. Layers listed from outermost to 
+                            innermost. */ 
+} 
+
+/* Counter Data Types 
+
+   Wherever possible, the if_counters block should be included. Media
+   specific counters can be included as well. */
+
+/* Generic Interface Counters - see RFC 2233 */
+/* opaque = counter_data; enterprise = 0; format = 1 */
+
+struct if_counters {
+   unsigned int ifIndex;
+   unsigned int ifType;
+   unsigned hyper ifSpeed;
+   unsigned int ifDirection;    /* derived from MAU MIB (RFC 2668)
+                                   0 = unkown, 1=full-duplex, 2=half-duplex,
+                                   3 = in, 4=out */
+   unsigned int ifStatus;       /* bit field with the following bits assigned
+                                   bit 0 = ifAdminStatus (0 = down, 1 = up)
+                                   bit 1 = ifOperStatus (0 = down, 1 = up) */
+   unsigned hyper ifInOctets;
+   unsigned int ifInUcastPkts;
+   unsigned int ifInMulticastPkts;
+   unsigned int ifInBroadcastPkts;
+   unsigned int ifInDiscards;
+   unsigned int ifInErrors;
+   unsigned int ifInUnknownProtos;
+   unsigned hyper ifOutOctets;
+   unsigned int ifOutUcastPkts;
+   unsigned int ifOutMulticastPkts;
+   unsigned int ifOutBroadcastPkts;
+   unsigned int ifOutDiscards;
+   unsigned int ifOutErrors;
+   unsigned int ifPromiscuousMode;
+}
+
+/* Ethernet Interface Counters - see RFC 2358 */
+/* opaque = counter_data; enterprise = 0; format = 2 */
+
+struct ethernet_counters {
+   unsigned int dot3StatsAlignmentErrors;
+   unsigned int dot3StatsFCSErrors;
+   unsigned int dot3StatsSingleCollisionFrames;
+   unsigned int dot3StatsMultipleCollisionFrames;
+   unsigned int dot3StatsSQETestErrors;
+   unsigned int dot3StatsDeferredTransmissions;
+   unsigned int dot3StatsLateCollisions;
+   unsigned int dot3StatsExcessiveCollisions;
+   unsigned int dot3StatsInternalMacTransmitErrors;
+   unsigned int dot3StatsCarrierSenseErrors;
+   unsigned int dot3StatsFrameTooLongs;
+   unsigned int dot3StatsInternalMacReceiveErrors;
+   unsigned int dot3StatsSymbolErrors;
+}
+
+/* Token Ring Counters - see RFC 1748 */
+/* opaque = counter_data; enterprise = 0; format = 3 */
+
+struct tokenring_counters {
+  unsigned int dot5StatsLineErrors;
+  unsigned int dot5StatsBurstErrors;
+  unsigned int dot5StatsACErrors;
+  unsigned int dot5StatsAbortTransErrors;
+  unsigned int dot5StatsInternalErrors;
+  unsigned int dot5StatsLostFrameErrors;
+  unsigned int dot5StatsReceiveCongestions;
+  unsigned int dot5StatsFrameCopiedErrors;
+  unsigned int dot5StatsTokenErrors;
+  unsigned int dot5StatsSoftErrors;
+  unsigned int dot5StatsHardErrors;
+  unsigned int dot5StatsSignalLoss;
+  unsigned int dot5StatsTransmitBeacons;
+  unsigned int dot5StatsRecoverys;
+  unsigned int dot5StatsLobeWires;
+  unsigned int dot5StatsRemoves;
+  unsigned int dot5StatsSingles;
+  unsigned int dot5StatsFreqErrors;
+}
+
+/* 100 BaseVG interface counters - see RFC 2020 */
+/* opaque = counter_data; enterprise = 0; format = 4 */
+
+struct vg_counters {
+  unsigned int dot12InHighPriorityFrames;
+  unsigned hyper dot12InHighPriorityOctets;
+  unsigned int dot12InNormPriorityFrames;
+  unsigned hyper dot12InNormPriorityOctets;
+  unsigned int dot12InIPMErrors;
+  unsigned int dot12InOversizeFrameErrors;
+  unsigned int dot12InDataErrors;
+  unsigned int dot12InNullAddressedFrames;
+  unsigned int dot12OutHighPriorityFrames;
+  unsigned hyper dot12OutHighPriorityOctets;
+  unsigned int dot12TransitionIntoTrainings;
+  unsigned hyper dot12HCInHighPriorityOctets;
+  unsigned hyper dot12HCInNormPriorityOctets;
+  unsigned hyper dot12HCOutHighPriorityOctets;
+}
+
+/* VLAN Counters */
+/* opaque = counter_data; enterprise = 0; format = 5 */
+
+struct vlan_counters {
+  unsigned int vlan_id;
+  unsigned hyper octets;
+  unsigned int ucastPkts;
+  unsigned int multicastPkts;
+  unsigned int broadcastPkts;
+  unsigned int discards;
+}
+
+/* Percentage expressed in hundredths of a percent
+   (e.g. 100 = 1%). If a percentage value is unknown then
+   use the value -1. */
+
+typedef int percentage;
+
+/* Processor Information */
+/* opaque = counter_data; enterprise = 0; format = 1001 */
+
+struct processor {
+   percentage 5s_cpu;          /* 5 second average CPU utilization */
+   percentage 1m_cpu;          /* 1 minute average CPU utilization */
+   percentage 5m_cpu;          /* 5 minute average CPU utilization */
+   unsigned hyper total_memory /* total memory (in bytes) */
+   unsigned hyper free_memory  /* free memory (in bytes) */
+}
--- a/doc/sflow/spec/sflow_80211_WIRELESS.txt
+++ b/doc/sflow/spec/sflow_80211_WIRELESS.txt
+
+
+
+
+
+
+sFlow.org                                                    Peter Phaal
+http://www.sFlow.org/                                        InMon Corp.
+info@sflow.org
+
+                                                               Jim Wendt
+                                                         Hewlett-Packard
+
+                                                              April 2007
+
+
+                        sFlow 802.11 Structures
+
+
+
+Copyright Notice
+
+Copyright (C) sFlow.org (2007). All Rights Reserved.
+
+Abstract
+
+This memo describes sFlow version 5 structures for exporting 802.11
+related data.
+
+Table of Contents
+
+1. Overview ......................................................  1
+2. Reference Model ...............................................  1
+3. sFlow Datagram Extensions .....................................  3
+4. References ....................................................  7
+5. Author's Addresses ............................................  7
+
+1. Overview
+   This document describes additional structures that allow an sFlow
+   agent to export additional information about the 802.11 traffic.
+   sFlow version 5 is an extensible protocol that allows the addition of
+   new data structures without impacting existing collectors. This
+   document does not change the sFlow version 5 protocol [1], it simply
+   defines additional, optional, data structures that an 802.11 device
+   [2] can use when reporting on 802.11 traffic. An sFlow collector that
+   does not understand a particular structure should simply skip it.
+
+2. Reference Model
+   The figure below shows the basic elements of an 802.11 wireless
+   access point (WAP).  In this abstract model a WAP is simply a device
+   that contains 1 or more radios.
+
+
+
+
+
+
+v1.00                           sFlow.org                       [Page 1]
+
+Version 1                sFlow 802.11 Structures              April 2007
+
+
+   +------------------------------------+
+   |   +-------+            +-------+   |
+   |   | ETH 1 |    ...     | ETH N |   |
+   |   +-------+            +-------+   |
+   |                                    |
+   |       Wireless Access Point        |
+   |                                    |
+   |  +---------+          +---------+  |
+   |  | RADIO 1 |   ...    | RADIO N |  |
+   |  +---------+          +---------+  |
+   +------------------------------------+
+
+   Wired interfaces are indicated as ETH 1 .. ETH N. Wireless interfaces
+   are indicated at RADIO 1 .. RADIO N.
+
+   There are a number of possible packet flows through a WAP:
+
+   o A packet is received on a wired interface and sent on a wireless
+     interface.
+
+   o A packet is received on a wired interface and sent on a wired
+     interface.
+
+   o A packet is received on a wired interface and sent on the same
+     interface (only possible if the WAP is performing a routing func-
+     tion).
+
+   o A packet is received on a wired interface and discarded.
+
+   o A packet for the WAP management entity is received on a wired
+     interface.
+
+   o A packet is received on a wireless interface and send on a wired
+     interface.
+
+   o A packet is received on a wireless interface and sent on another
+     wireless interface.
+
+   o A packet is received on a wireless interface and sent on the same
+     interface.
+
+   o A packet is received on a wireless interface and discarded.
+
+   o A packet for the WAP management entity is received on a wireless
+     interface.
+
+   Packet flows between wired interfaces are switched or routed and can
+   be described using existing sFlow data structures.
+
+
+
+v1.00                           sFlow.org                       [Page 2]
+
+Version 1                sFlow 802.11 Structures              April 2007
+
+
+   Packet flows that pass through one or more radios require additional
+   information in the sFlow structures to fully describe them. In
+   addition there are counters specific to the radios that require
+   additional sFlow structures if they are to be exported.
+
+   Note: The sFlow specification required that "each sFlow Instance must
+   ensure that any packet observed at a Data Source has an equal chance
+   of being sampled, irrespective of the Packet Flow(s) to which it
+   belongs."  When a WAP is performing meshing or repeating functions it
+   is possible that many frames will be received and resent on the same
+   radio. An sFlow instance must ensure that these frames are considered
+   only once as sampling candidates even if ingress and egress sampling
+   is being performed on the radio.
+
+   A radio may be used off-channel to monitor traffic associated with
+   nearby 802.11 devices. It can be useful to monitor this off-channel
+   traffic via sFlow, however, packets received in this manner should be
+   marked as discarded since they are not part of the traffic associated
+   with the WAP. The sFlow Instance associated with a radio must only
+   sample on-channel packets unless it has been explicitly configured to
+   also sample off-channel packets.  The mechanism for configuring
+   channel scanning behavior and sampling is out of scope for this
+   document.
+
+3. sFlow Datagram Extensions
+
+   The sFlow Datagram format describes the basic structure of flow and
+   counter samples. Part of the specification is a list of "reason
+   codes" for discarded packets. It is useful define an additional
+   reason code for WAPs in order to identify packets that may have been
+   received as part of a passive scan.  This same code could be used in
+   situations where any network interface (not just a wireless
+   interface) is operating promiscuously and capturing packets that are
+   not part of communication to or through the capturing device.
+
+   263 = promiscuously received packet not intended for this device
+
+   In addition, the following new structures are defined that allow
+   captured 802.11 frames to be exported (along with extended flow
+   information about the radio interfaces) and additional counters:
+
+/* Additional packet header types for enum header_protocol */
+
+   IEEE80211MAC             = 15  /* 802.11 MAC */
+   IEEE80211-AMPDU          = 16  /* 802.11n Aggregated MPDU (A-MPDU)
+                                     starting with MPDU delimiter */
+   IEEE80211-AMSDU-Subframe = 17  /* MSDU transported in A-MSDU starting
+                                     with A-MSDU subframe header */
+
+
+
+v1.00                           sFlow.org                       [Page 3]
+
+Version 1                sFlow 802.11 Structures              April 2007
+
+
+/* The 4-byte cipher_suite identifier follows the format of the cipher suite
+   selector value from the 802.11i (TKIP/CCMP amendment to 802.11i)
+   The most significant three bytes contain the OUI and the least significant
+   byte contains the Suite Type.
+
+   The currently assigned values are:
+
+   OUI        |Suite type  |Meaning
+   ----------------------------------------------------
+   00-0F-AC   | 0          | Use group cipher suite
+   00-0F-AC   | 1          | WEP-40
+   00-0F-AC   | 2          | TKIP
+   00-0F-AC   | 3          | Reserved
+   00-0F-AC   | 4          | CCMP
+   00-0F-AC   | 5          | WEP-104
+   00-0F-AC   | 6-255      | Reserved
+   Vendor OUI | Other      | Vendor specific
+   Other      | Any        | Reserved
+   ----------------------------------------------------
+*/
+typedef unsigned int cipher_suite;
+
+/* Extended 80211 Payload
+   Used to provide unencrypted version of 802.11 MAC data. If the
+   MAC data is not encrypted then the agent must not include an
+   extended_80211_payload structure.
+   If 802.11 MAC data is encrypted then the sampled_header structure
+   should only contain the MAC header (since encrypted data cannot
+   be decoded by the sFlow receiver). If the sFlow agent has access to
+   the unencrypted payload, it should add an extended_80211_payload
+   structure containing the unencrypted data bytes from the sampled
+   packet header, starting at the beginning of the 802.2 LLC and not
+   including any trailing encryption footers.  */
+/* opaque = flow_data; enterprise = 0; format = 1013 */
+
+struct extended_80211_payload {
+   cipher_suite ciphersuite; /* encryption scheme used for this packet */
+   opaque       data<>;      /* unencrypted bytes from the payload */
+}
+
+/* Extended 802.11 Data
+   Note: in situations where an 802.11 packet is received and resent
+         wirelessly it is possible to have two extended_80211
+         elements associated with the flow sample, one for the
+         receiver and one for the transmitter */
+
+enum ieee80211_version {
+  a = 1,
+
+
+
+v1.00                           sFlow.org                       [Page 4]
+
+Version 1                sFlow 802.11 Structures              April 2007
+
+
+  b = 2,
+  g = 3,
+  n = 4,
+}
+
+typedef unsigned int duration_us; /* Duration measured in microseconds
+                                     0 = unknown */
+
+/* opaque = flow_data; enterprise = 0; format = 1014 */
+
+struct extended_80211_rx {
+   string ssid<32>;            /* SSID string */
+   mac  bssid;                 /* BSSID */
+   ieee80211_version version;  /* version */
+   unsigned int channel;       /* channel number */
+   unsigned hyper speed;
+   unsigned int rsni;          /* received signal to noise ratio,
+                                  see dot11FrameRprtRSNI */
+   unsigned int rcpi;          /* received channel power,
+                                  see dot11FrameRprtLastRCPI */
+   duration_us packet_duration /* amount of time that the successfully
+                                  received packet occupied the RF medium. */
+}
+
+/* opaque = flow_data; enterprise = 0; format = 1015 */
+
+struct extended_80211_tx {
+   string ssid<32>;              /* SSID string */
+   mac  bssid;                   /* BSSID */
+   ieee80211_version version;    /* version */
+   unsigned int transmissions;   /* number of transmissions for sampled
+                                    packet.
+                                    0 = unkown
+                                    1 = packet was successfully transmitted
+                                        on first attempt
+                                    n > 1 = n - 1 retransmissions */
+   duration_us packet_duration;  /* amount of time that the successfully
+                                    transmitted packet occupied the
+                                    RF medium */
+   duration_us retrans_duration; /* amount of time that failed transmission
+                                    attempts occupied the RF medium */
+   unsigned int channel;         /* channel number */
+   unsigned hyper speed;
+   unsigned int power;           /* transmit power in mW. */
+}
+
+/* Extended 802.11 Aggregation Data */
+/* A flow_sample of an aggregated frame would consist of a packet
+
+
+
+v1.00                           sFlow.org                       [Page 5]
+
+Version 1                sFlow 802.11 Structures              April 2007
+
+
+   header for the whole frame + any other extended structures that
+   apply (e.g. 80211_tx/rx etc.) + an extended_80211_aggregation
+   structure which would contain an array of pdu structures (one
+   for each PDU in the aggregate). A pdu is simply an array of
+   flow records, in the simplest case a packet header for each PDU,
+   but extended structures could be included as well. */
+
+struct pdu {
+   flow_record flow_records<>;  /* Flow records for each of the PDUs
+                                   in the aggregation */
+}
+
+/* opaque = flow_data; enterprise = 0; format = 1016 */
+
+struct extended_80211_aggregation {
+   pdu pdus<>;
+}
+
+/* IEEE802.11 interface counters - see IEEE802dot11-MIB */
+/* opaque = counter_data; enterprise = 0; format = 6 */
+
+struct ieee80211_counters {
+   unsigned int dot11TransmittedFragmentCount;
+   unsigned int dot11MulticastTransmittedFrameCount;
+   unsigned int dot11FailedCount;
+   unsigned int dot11RetryCount;
+   unsigned int dot11MultipleRetryCount;
+   unsigned int dot11FrameDuplicateCount;
+   unsigned int dot11RTSSuccessCount;
+   unsigned int dot11RTSFailureCount;
+   unsigned int dot11ACKFailureCount;
+   unsigned int dot11ReceivedFragmentCount;
+   unsigned int dot11MulticastReceivedFrameCount;
+   unsigned int dot11FCSErrorCount;
+   unsigned int dot11TransmittedFrameCount;
+   unsigned int dot11WEPUndecryptableCount;
+   unsigned int dot11QoSDiscardedFragmentCount;
+   unsigned int dot11AssociatedStationCount;
+   unsigned int dot11QoSCFPollsReceivedCount;
+   unsigned int dot11QoSCFPollsUnusedCount;
+   unsigned int dot11QoSCFPollsUnusableCount;
+   unsigned int dot11QoSCFPollsLostCount;
+}
+
+/* 802.11 radio utilization
+   Utilization can be computed based on the three counters: elapsed_time,
+   counts total time, on_channel_time counts the time spent
+   on the radio's assigned channel (this may be less than elapsed_time
+
+
+
+v1.00                           sFlow.org                       [Page 6]
+
+Version 1                sFlow 802.11 Structures              April 2007
+
+
+   if the radio spends time performing off-channel scans), and
+   on_channel_busy_time counts the time spent sending and receiving frames
+   as part of on-channel activity. */
+/* opaque = counter_data; enterprise = 0; format = 1002 */
+
+struct radio_utilization {
+   unsigned int elapsed_time;         /* elapsed time in ms */
+   unsigned int on_channel_time;      /* time in ms spent on channel */
+   unsigned int on_channel_busy_time; /* time in ms spent on channel
+                                         and busy */
+}
+
+4. References
+
+[1]  Phaal, P. and Lavine, M., "sFlow Version 5",
+     http://www.sflow.org/sflow_version_5.txt, July 2006
+
+[2]  IEEE 802.11, "Part 11: Wireless LAN Medium Access Control (MAC) and
+     Phyical Layer (PHY) Specification", 1999
+
+[3]  IEEE 802.11i, "Part 11: Amendment 6: Medium Access Control Security
+     Enhancements", 2004
+
+5. Author's Address
+
+   Peter Phaal
+   InMon Corp.
+   580 California Street, 5th Floor
+   San Francisco, CA 94104
+
+   Phone: (415) 283-3263
+   EMail: peter.phaal@inmon.com
+
+   Jim Wendt
+   Hewlett-Packard
+   8000 Foothills Blvd., MS 5555
+   Roseville, CA 95747
+
+   Phone: (916) 785-5198
+   EMail: jim.wendt@hp.com
+
+
+
+
+
+
+
+
+
+
+
+v1.00                           sFlow.org                       [Page 7]
+
--- a/doc/sflow/spec/sflow_host.txt
+++ b/doc/sflow/spec/sflow_host.txt
+
+
+
+
+
+
+sFlow.org                                                    Peter Phaal
+http://www.sFlow.org/                                        InMon Corp.
+info@sflow.org
+                                                           Robert Jordan
+                                                     ImageMovers Digital
+
+
+
+
+                                                               July 2010
+
+
+                         sFlow Host Structures
+
+
+
+Copyright Notice
+
+Copyright (C) sFlow.org (2010). All Rights Reserved.
+
+Abstract
+
+This memo describes sFlow version 5 structures for exporting host
+related data.
+
+Table of Contents
+
+1. Overview ......................................................  1
+2. Reference Model ...............................................  2
+3. sFlow Datagram Extensions .....................................  3
+4. References .................................................... 12
+5. Author's Addresses ............................................ 13
+
+1. Overview
+   This document describes additional structures that allow an sFlow
+   agent to export information about host resources.
+
+   Current trends toward virtualization and convergence tightly link
+   networking and system performance and blur the line between the
+   network and the servers. For example, virtualization places switching
+   and routing functions on servers. Monitoring the network in this
+   environment requires that the servers are also monitored. Similarly
+   anyone concerned with application and server performance must now
+   also be concerned about network performance since the application
+   features (such as virtual machine migration) can significantly affect
+   and be affected by network performance.
+
+   Currently, performance monitoring of servers and applications is
+
+
+
+FINAL                           sFlow.org                       [Page 1]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+   highly fragmented. Each server vendor, operating system vendor and
+   application developer creates agents and software for performance
+   monitoring, none of which interoperate. Monitoring performance of a
+   server might require the same (or similar but incompatible metrics)
+   be monitored more than once since each management application
+   requires its own agent. In addition, there may be other agents
+   monitoring different hardware and software elements within the
+   server.
+
+   Host sFlow extends sFlow's scalable measurement protocol to include
+   server performance monitoring. An interoperable standard for
+   exporting host performance metrics breaks the linkage between agents
+   and performance analysis applications, providing a standard set of
+   metrics that can be collected once and shared among different
+   performance analysis tools.
+
+   Extending sFlow to monitor servers unifies network and system
+   performance monitoring, delivering the real-time, integrated view of
+   performance needed to manage converged services.
+
+   sFlow version 5 is an extensible protocol that allows the addition of
+   new data structures without impacting existing collectors. This
+   document does not change the sFlow version 5 protocol [1], it simply
+   defines additional, optional, data structures that a host device can
+   use to report on host resources.
+
+2. Reference Model
+   The figure below shows the basic elements of a host.  In this
+   abstract model a host consists of one or more physical machines (PM),
+   each of which may contain zero or more virtual machines (VM) and/or
+   application services (AS).
+
+   +--------------------------------------+
+   |   +------------------------------+   |
+   |   | PM 1  +------+     +------+  |   |
+   |   |       | AS 1 | ... | AS J |  |   |
+   |   |       +------+     +------+  |   |
+   |   |       +------+     +------+  |   |
+   |   |       | VM 1 | ... | VM K |  |   |
+   |   |       +------+     +------+  |   |
+   |   +------------------------------+   |
+   |                     .                |
+   |                     .                |
+   |                     .                |
+   |   +------------------------------+   |
+   |   | PM I                         |   |
+   |   +------------------------------+   |
+   +--------------------------------------+
+
+
+
+FINAL                           sFlow.org                       [Page 2]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+   The term application service is used to refer to applications
+   providing networked services. Examples would include: a web server
+   implementing the HTTP protocol [2], a storage array supporting the
+   NFS protocol [3], a distributed cache implementing the memcached
+   protocol [4], or a distributed computing facility such as Hadoop [5].
+
+   A stand-alone server would just have a single physical machine. A
+   blade server may have a large number of physical machines (one per
+   blade).
+
+   Physical machines are indicated as PM 1 .. PM I. Application services
+   are indicated as AS 1 .. AS J. Virtual machines are indicated as VM 1
+   .. VM K.
+
+   Each physical machine, application service and virtual machine is
+   monitored by at least one sFlow data source. In this model there is a
+   strict containment hierarchy, each physical machine contains
+   application services and/or virtual machines. Each virtual machine
+   may in turn contain application services.
+
+   The objective of Host sFlow is to export statistics relating to the
+   PM, AS and VM entities using a unified data model that permits
+   correlation between the host statistics and network statistics
+   provided by sFlow agents residing in physical and virtual switches.
+
+   The sFlow version 5 standard requires the implementation of Packet
+   Flow Sampling and Counter Sampling within the packet forwarding
+   function of a device. In order to be compliant, a host must implement
+   sFlow within any physical or virtual switching functions implemented
+   within the host.
+
+   However, in the case where no switching function is performed by the
+   host, either because it does not contain virtual machines or because
+   the inter-VM switching function has been offloaded to the adjacent
+   switch (see Edge Virtual Bridging [6]) then the host is not required
+   to perform the sFlow Packet Flow Sampling function. The combination
+   of sFlow from the adjacent switch and sFlow performance metrics from
+   the host provides a complete picture of network and server
+   performance.
+
+3. sFlow Datagram Extensions
+
+   The SNMP Entity-MIB [7] can be used to describe the physical and
+   logical containment hierarchy of host resources. Physical machines
+   (PMs) can be modeled as physical entities, an already supported sFlow
+   data source type.  Application services (ASs) and virtual machines
+   (VMs) can be modeled as logical entities. Extending sFlow support for
+   logical entities provides a means of exporting data related to
+
+
+
+FINAL                           sFlow.org                       [Page 3]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+   application services and virtual machines.
+
+   The sFlow MIB [1] identifies data sources by SNMP OID, so the only
+   change needed is a comment indicating that a logical entity is a
+   valid data source type:
+
+        - entLogicalEntry.<L>
+          An SFlowDataSource of this form refers to a logical entity
+          within the agent and is called a 'logical-entity-based'
+          dataSource.
+
+   In addition, a mapping for logical entity data sources in the sFlow
+   datagram needs to be specified:
+
+        3 = entLogicalEntry
+
+   These changes are backward compatible with existing sFlow agents. An
+   sFlow collector must be able to ignore and skip over the MIB entries
+   and data structures related to the logical data source type.
+
+   However, since there is very little functional overlap between Host
+   sFlow and existing switch based sFlow, sending Host sFlow to a
+   collector that does not support the standard should be avoided. As
+   Host sFlow becomes more common, it is likely that many sFlow
+   analyzers will be extended to support the new structures in order to
+   provide integrated network and system monitoring functionality.
+
+   SNMP[8] is a standard management protocol for network equipment and
+   sFlow monitoring of switches is often augmented by additional
+   information obtained by SNMP (e.g. ifName, ifStack etc.). However,
+   SNMP is much less frequently used in host monitoring. It is important
+   that the Host sFlow structures define an internally consistent model
+   of the host without depending on SNMP for critical information.
+   However, when an SNMP agent is present on the host, the sFlow logical
+   and physical entity data sources and their containment hierarchy must
+   be consistent with data exported via SNMP.
+
+   The host_parent structure is used to describe the containment
+   hierarchy between application services, virtual machines and physical
+   machines.
+
+   The host_adapter structure provides the link between host performance
+   statistics and sFlow implemented in network equipment. Identifying
+   the MAC addresses associated with a physical or virtual network
+   adapter allows traffic generated by that adapter to be identified on
+   the network.
+
+   Physical machine data sources must export counter_sample structures
+
+
+
+FINAL                           sFlow.org                       [Page 4]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+   containing host performance statistics (host_cpu, host_memory,
+   host_disk_io, host_net_io). Each counter_sample must also include
+   host_adapter and host_descr structures.
+
+   If the physical machine is hosting virtual machines then network
+   connectivity to the virtual machines is typically provided by a
+   virtual switching function. The virtual switch function connects one
+   or more of the physical server's physical network adapters with
+   virtual network adapters associated with each virtual machine. The
+   virtual switch must export sFlow counter_sample and flow_sample
+   structures, providing exactly the data that would be available from a
+   physical switch. The data sources defined for a switch are typically
+   ifIndex data sources and in the case of a virtual switch would
+   represent each of the physical and virtual network adapters
+   associated with the switch. Again, if an SNMP agent is running on the
+   server, the ifIndex numbers exported via sFlow must correspond to the
+   ifIndex numbers exported via SNMP.
+
+   A data source associated with each of the virtual machines must
+   export counter_sample structures containing performance metrics for
+   that virtual machine (virt_cpu, virt_memory, virt_disk_io,
+   virt_net_io). Each counter_sample must also include host_adapter,
+   host_parent and host_descr structures.  Installing an sFlow agent on
+   each virtual machine is not required. Implementing sFlow as part of
+   the hypervisor functionality provides access to the virtual switch
+   and performance counters for all the virtual machines.  However, if
+   an sFlow agent is running on a virtual machine, it must export its
+   own "physical server" statistics.
+
+   Application services may export both counter_sample structures and
+   flow_sample structures. When sampling at the application level,
+   transactions do not have a simple correspondence with network
+   packets. A single packet may contain more than one application level
+   transaction, or an application level transaction may span many
+   packets.  Application level sampling operates on the stream of
+   application transactions, sampling a random selection of completed
+   transactions and reporting on their attributes.
+
+   For example, a data source monitoring a web server randomly samples
+   1-in-N HTTP requests, capturing information about each completed
+   request and exports the information as a flow_sample structure.  In
+   addition, the data source maintains counters of request totals, types
+   and errors and export these counters periodically using a
+   counter_sample structure.
+
+   The socket extended_flow structures provide the link between
+   application level flow_sample structures and traffic measurements
+   made using sFlow in network devices. Each application flow_sample
+
+
+
+FINAL                           sFlow.org                       [Page 5]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+   must include a socket structure describing the socket on which the
+   sampled transaction was received.
+
+   This document creates a framework for exporting application service
+   metrics. However, it does not specify application service
+   counter_sample or flow_sample structures. Each application service
+   will have its own metrics and these will be defined in separate
+   documents.
+
+   The goal of sFlow monitoring is to provide a consistent, network wide
+   view of performance. In order to achieve this goal with system
+   performance monitoring a common set of metrics needs to be defined
+   that can be collected in multi-vendor, multi-OS environments.
+
+   The Ganglia Monitoring System [9] has defined a basic set of system
+   performance metrics and developed a portable library, libmetrics,
+   that allows these metrics to be obtained on a wide variety of
+   platforms. Making use of Ganglia's metric definitions to specify the
+   sFlow performance counter structures simplifies the implementation of
+   a Host sFlow agent, building on a mature and widely accepted set of
+   metrics and tools.
+
+   While the sFlow structure definitions are designed to permit an sFlow
+   performance monitoring system to yield results that are compatible
+   with Ganglia measurements, there are significant architectural
+   differences between the two technologies that require some
+   explanation.
+
+   The Ganglia agent periodically polls systems counters and computes
+   rates.  For example packet counters are polled and packet rates are
+   exported (e.g. delta packets / delta time).  In the sFlow
+   architecture the sFlow agent exports raw counter values and the sFlow
+   analyzer computes deltas and rates.
+
+   Just as Ganglia's libmetrics library defines a set of portable
+   metrics for physical server performance monitoring, the libvert
+   library [10] defines a standard set of metrics for virtual server
+   performance monitoring.  Defining sFlow counter structures based on
+   the libvert library simplifies the implementation of a Host sFlow
+   agent, making use of a standard library that has been implemented on
+   a wide variety of host operating systems and hypervisors. Exporting
+   libvert metrics ensures consistency between sFlow performance
+   monitoring and other tools making use of libvert.
+
+   The Host sFlow agent [11] is an open source implementation of the
+   Host sFlow specification that demonstrates the relationship between
+   Host sFlow structures. A single physical entity data source
+   periodically exports an sFlow counters_sample containing a
+
+
+
+FINAL                           sFlow.org                       [Page 6]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+   host_descr, host_adapters, host_cpu, host_memory, host_disk_io and
+   host_net_io structure. If virtual machines are present, the physical
+   entity data source includes a virt_node structure in its set of
+   counters. In addition, a logical entity data source corresponding to
+   each virtual machine periodically exports an sFlow counters_sample
+   containing a host_descr, host_adapters, host_parent, virt_cpu,
+   virt_memory, virt_disk_io and virt_net_io structure.
+
+   The following sFlow structures are defined to export performance and
+   dependency information related to physical machines, virtual machines
+   and applications:
+
+/* Data structures for exporting Host statistics relating to
+   logical and physical entities */
+
+/* The machine_type enumeration may be expanded over time.
+   Applications receiving sFlow must be prepared to receive
+   host_descr structures with unknown machine_type values.
+
+   The authoritative list of machine types will be maintained
+   at www.sflow.org */
+
+enum machine_type {
+   unknown = 0,
+   other   = 1,
+   x86     = 2,
+   x86_64  = 3,
+   ia64    = 4,
+   sparc   = 5,
+   alpha   = 6,
+   powerpc = 7,
+   m68k    = 8,
+   mips    = 9,
+   arm     = 10,
+   hppa    = 11,
+   s390    = 12
+}
+
+/* The os_name enumeration may be expanded over time.
+   Applications receiving sFlow must be prepared to receive
+   host_descr structures with unknown machine_type values.
+
+   The authoritative list of machine types will be maintained
+   at www.sflow.org */
+
+enum os_name {
+   unknown   = 0,
+   other     = 1,
+
+
+
+FINAL                           sFlow.org                       [Page 7]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+   linux     = 2,
+   windows   = 3,
+   darwin    = 4,
+   hpux      = 5,
+   aix       = 6,
+   dragonfly = 7,
+   freebsd   = 8,
+   netbsd    = 9,
+   openbsd   = 10,
+   osf       = 11,
+   solaris   = 12
+}
+
+/* Physical or virtual host description */
+/* opaque = counter_data; enterprise = 0; format = 2000 */
+struct host_descr {
+   string hostname<64>;       /* hostname, empty if unknown */
+   opaque uuid<16>;           /* 16 bytes binary UUID, empty if unknown */
+   machine_type machine_type; /* the processor family */
+   os_name os_name;           /* Operating system */
+   string os_release<32>;     /* e.g. 2.6.9-42.ELsmp,xp-sp3, empty if unknown */
+}
+
+/* Physical or virtual network adapter NIC/vNIC */
+struct host_adapter {
+   unsigned int ifIndex;     /* ifIndex associated with adapter
+                                Must match ifIndex of vSwitch
+                                port if vSwitch is exporting sFlow
+                                0 = unknown */
+   mac mac_address<>;        /* Adapter MAC address(es) */
+}
+
+/* Set of adapters associated with entity.
+   A physical server will identify the physical network adapters
+   associated with it and a virtual server will identify its virtual
+   adapters. */
+/* opaque = counter_data; enterprise = 0; format = 2001 */
+
+struct host_adapters {
+   adapter adapters<>;              /* adapter(s) associated with entity */
+}
+
+/* Define containment hierarchy between logical and physical
+   entities. Only a single, strict containment tree is permitted,
+   each entity must be contained within a single parent, but a parent
+   may contain more than one child. The host_parent record is used
+   by the child to identify its parent. Physical entities form the roots
+   of the tree and do not send host_parent structures. */
+
+
+
+FINAL                           sFlow.org                       [Page 8]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+/* opaque = counter_data; enterprise = 0; format = 2002 */
+
+struct host_parent {
+   unsigned int container_type;     /* sFlowDataSource type */
+   unsigned int container_index;    /* sFlowDataSource index */
+}
+
+/* Extended socket information,
+   Must be filled in for all application transactions associated with a network socket
+   Omit if transaction associated with non-network IPC  */
+
+/* IPv4 Socket */
+/* opaque = flow_data; enterprise = 0; format = 2100 */
+struct extended_socket_ipv4 {
+   unsigned int protocol;     /* IP Protocol type
+                                 (for example, TCP = 6, UDP = 17) */
+   ip_v4 local_ip;            /* local IP address */
+   ip_v4 remote_ip;           /* remote IP address */
+   unsigned int local_port;   /* TCP/UDP local port number or equivalent */
+   unsigned int remote_port;  /* TCP/UDP remote port number of equivalent */
+}
+
+/* IPv6 Socket */
+/* opaque = flow_data; enterprise = 0; format = 2101 */
+struct extended_socket_ipv6 {
+   unsigned int protocol;     /* IP Protocol type
+                                 (for example, TCP = 6, UDP = 17) */
+   ip_v6 local_ip;            /* local IP address */
+   ip_v6 remote_ip;           /* remote IP address */
+   unsigned int local_port;   /* TCP/UDP local port number or equivalent */
+   unsigned int remote_port;  /* TCP/UDP remote port number of equivalent */
+}
+
+/*
+  Physical server performance metrics
+*/
+
+/* Physical Server CPU */
+/* opaque = counter_data; enterprise = 0; format = 2003 */
+
+struct host_cpu {
+   float load_one;              /* 1 minute load avg., -1.0 = unknown */
+   float load_five;             /* 5 minute load avg., -1.0 = unknown */
+   float load_fifteen;          /* 15 minute load avg., -1.0 = unknown */
+   unsigned int proc_run;       /* total number of running processes */
+   unsigned int proc_total;     /* total number of processes */
+   unsigned int cpu_num;        /* number of CPUs */
+   unsigned int cpu_speed;      /* speed in MHz of CPU */
+
+
+
+FINAL                           sFlow.org                       [Page 9]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+   unsigned int uptime;         /* seconds since last reboot */
+   unsigned int cpu_user;       /* user time (ms) */
+   unsigned int cpu_nice;       /* nice time (ms) */
+   unsigned int cpu_system;     /* system time (ms) */
+   unsigned int cpu_idle;       /* idle time (ms) */
+   unsigned int cpu_wio;        /* time waiting for I/O to complete (ms) */
+   unsigned int cpu_intr;       /* time servicing interrupts (ms) */
+   unsigned int cpu_sintr;      /* time servicing soft interrupts (ms) */
+   unsigned int interrupts;     /* interrupt count */
+   unsigned int contexts;       /* context switch count */
+}
+
+/* Physical Server Memory */
+/* opaque = counter_data; enterprise = 0; format = 2004 */
+
+struct host_memory {
+    unsigned hyper mem_total;   /* total bytes */
+    unsigned hyper mem_free;    /* free bytes */
+    unsigned hyper mem_shared;  /* shared bytes */
+    unsigned hyper mem_buffers; /* buffers bytes */
+    unsigned hyper mem_cached;  /* cached bytes */
+    unsigned hyper swap_total;  /* swap total bytes */
+    unsigned hyper swap_free;   /* swap free bytes */
+    unsigned int page_in;       /* page in count */
+    unsigned int page_out;      /* page out count */
+    unsigned int swap_in;       /* swap in count */
+    unsigned int swap_out;      /* swap out count */
+}
+
+/* Physical Server Disk I/O */
+/* opaque = counter_data; enterprise = 0; format = 2005 */
+
+struct host_disk_io {
+   unsigned hyper disk_total;    /* total disk size in bytes */
+   unsigned hyper disk_free;     /* total disk free in bytes */
+   percentage  part_max_used;    /* utilization of most utilized partition */
+   unsigned int reads;           /* reads issued */
+   unsigned hyper bytes_read;    /* bytes read */
+   unsigned int read_time;       /* read time (ms) */
+   unsigned int writes;          /* writes completed */
+   unsigned hyper bytes_written; /* bytes written */
+   unsigned int write_time;      /* write time (ms) */
+}
+
+/* Physical Server Network I/O */
+/* opaque = counter_data; enterprise = 0; format = 2006 */
+
+struct host_net_io {
+
+
+
+FINAL                           sFlow.org                      [Page 10]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+   unsigned hyper bytes_in;  /* total bytes in */
+   unsigned int pkts_in;     /* total packets in */
+   unsigned int errs_in;     /* total errors in */
+   unsigned int drops_in;    /* total drops in */
+   unsigned hyper bytes_out; /* total bytes out */
+   unsigned int packets_out; /* total packets out */
+   unsigned int errs_out;    /* total errors out */
+   unsigned int drops_out;   /* total drops out */
+}
+
+/*
+  Hypervisor and virtual machine performance metrics
+*/
+
+/* Virtual Node Statistics */
+/* See libvirt, struct virtNodeInfo */
+/* opaque = counter_data; enterprise = 0; format = 2100 */
+
+struct virt_node {
+   unsigned int mhz;           /* expected CPU frequency */
+   unsigned int cpus;          /* the number of active CPUs */
+   unsigned hyper memory;      /* memory size in bytes */
+   unsigned hyper memory_free; /* unassigned memory in bytes */
+   unsigned int num_domains;   /* number of active domains */
+}
+
+/* Virtual Domain CPU statistics */
+/* See libvirt, struct virtDomainInfo */
+/* opaque = counter_data; enterprise = 0; format = 2101 */
+
+struct virt_cpu {
+   unsigned int state;         /* virtDomainState */
+   unsigned int cpuTime;       /* the CPU time used (ms) */
+   unsigned int nrVirtCpu;     /* number of virtual CPUs for the domain */
+}
+
+/* Virtual Domain Memory statistics */
+/* See libvirt, struct virtDomainInfo */
+/* opaque = counter_data; enterprise = 0; format = 2102 */
+
+struct virt_memory {
+   unsigned hyper memory;      /* memory in bytes used by domain */
+   unsigned hyper maxMemory;   /* memory in bytes allowed */
+}
+
+/* Virtual Domain Disk statistics */
+/* See libvirt, struct virtDomainBlockInfo */
+/* See libvirt, struct virtDomainBlockStatsStruct */
+
+
+
+FINAL                           sFlow.org                      [Page 11]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+/* opaque = counter_data; enterprise = 0; format = 2103 */
+
+struct virt_disk_io {
+   unsigned hyper capacity;   /* logical size in bytes */
+   unsigned hyper allocation; /* current allocation in bytes */
+   unsigned hyper available;  /* remaining free bytes */
+   unsigned int rd_req;       /* number of read requests */
+   unsigend hyper rd_bytes;   /* number of read bytes */
+   unsigned int wr_req;       /* number of write requests */
+   unsigned hyper wr_bytes;   /* number of  written bytes */
+   unsigned int errs;         /* read/write errors */
+}
+
+/* Virtual Domain Network statistics */
+/* See libvirt, struct virtDomainInterfaceStatsStruct */
+/* opaque = counter_data; enterprise = 0; format = 2104 */
+
+struct virt_net_io {
+   unsigned hyper rx_bytes;  /* total bytes received */
+   unsigned int rx_packets;  /* total packets received */
+   unsigned int rx_errs;     /* total receive errors */
+   unsigned int rx_drop;     /* total receive drops */
+   unsigned hyper tx_bytes;  /* total bytes transmitted */
+   unsigned int tx_packets;  /* total packets transmitted */
+   unsigned int tx_errs;     /* total transmit errors */
+   unsigned int tx_drop;     /* total transmit drops */
+}
+
+
+4. References
+
+[1]  Phaal, P. and Lavine, M., "sFlow Version 5",
+     http://www.sflow.org/sflow_version_5.txt, July 2006
+
+[2]  IETF, "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", June
+     1999
+
+[3]  IETF, "RFC 1813: NFS Version 3 Protocol Specification", June 1995
+
+[4]  "Memcached", http://memcached.org/
+
+[5]  "Hadoop", http://hadoop.apache.org/
+
+[6]  IEEE, "802.1Qbg - Edge Virtual Bridging"
+
+[7]  IETF, "RFC 2737: Entity MIB (Version 2)", December 1999
+
+
+
+
+
+FINAL                           sFlow.org                      [Page 12]
+
+FINAL                     sFlow Host Structures                July 2010
+
+
+[8]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
+     Management Protocol", STD 15, RFC 1157, May 1990.
+
+[9]  "Ganglia Monitoring System", http://ganglia.sourceforge.net/
+
+[10] "libvirt: virtualization API", http://libvirt.org/
+
+[11] "Host sFlow", http://host-sflow.sourceforge.net/
+
+5. Author's Address
+
+   Peter Phaal
+   InMon Corp.
+   580 California Street, 5th Floor
+   San Francisco, CA 94104
+
+   Phone: (415) 283-3263
+   EMail: peter.phaal@inmon.com
+
+   Robert Jordan
+   ImageMovers Digital
+   9 Hamilton Landing
+   Novato, CA 94949
+
+   Phone: (415) 475-5800
+   EMail: rjordan@imagemoversdigital.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+FINAL                           sFlow.org                      [Page 13]
+
--- a/doc/sflow/spec/sflow_version_5.txt
+++ b/doc/sflow/spec/sflow_version_5.txt