





sFlow.org                                                    Peter Phaal
http://www.sFlow.org/                                        InMon Corp.
info@sflow.org

                                                             Marc Lavine
                                                        Foundry Networks

                                                               July 2004


                            sFlow Version 5



Copyright Notice

Copyright (C) sFlow.org (2004). All Rights Reserved.

Abstract

This memo defines sFlow.org's sFlow system. sFlow is a technology for
monitoring traffic in data networks containing switches and routers.  In
particular, it defines the traffic sampling mechanisms implemented in
sFlow Agents, the sFlow MIB for configuring sFlow Agents, and the format
of the sFlow Datagram that carries traffic measurement data from sFlow
Agents to an sFlow Collector.

Table of Contents

1. Overview ......................................................  2
2. Terminology and Architecture ..................................  2
   2.1 Terminology ...............................................  2
   2.2 sFlow Reference Model .....................................  4
3. Sampling Mechanisms ...........................................  6
   3.1 Packet Flow Sampling ......................................  6
   3.2 Counter Sampling ..........................................  7
4. sFlow MIB .....................................................  8
   4.1 The SNMP Management Framework .............................  8
   4.2 Structure of the sFlow MIB Module .........................  9
       4.2.1 The Receiver Group ..................................  9
       4.2.2 The Flow Sampling Group .............................  9
       4.2.3 The Counter Polling Group ........................... 10
   4.3 Definitions ............................................... 11
5. sFlow Datagram Format ......................................... 23
6. Security Considerations ....................................... 43
   6.1 Configuration ............................................. 44
   6.2 Transport ................................................. 44
   6.3 Confidentiality ........................................... 44



v1.00                           sFlow.org                       [Page 1]

FINAL                        sFlow Version 5                   July 2004


7. References .................................................... 45
8. Author's Addresses ............................................ 47

   Appendix A: Differences Between sFlow Versions 4 and 5 ........ 49
   Appendix B: Random Number Generation .......................... 50



1. Overview
   sFlow is a technology for monitoring traffic in data networks
   containing switches and routers.

   The sFlow monitoring system consists of an sFlow Agent (embedded in a
   switch or router or in a standalone probe) and a central sFlow
   Collector.  The architecture and sampling techniques used in the
   sFlow monitoring system were designed for providing continuous site-
   wide (and enterprise-wide) traffic monitoring of high speed switched
   and routed networks. This design specifically addresses issues
   associated with:

   o Accurately monitoring network traffic at Gigabit speeds and higher.

   o Scaling to monitor tens of thousands of agents from a single sFlow
     Collector.

   o Extremely low cost sFlow Agent implementation.


   The sFlow Agent uses sampling technology to capture traffic
   statistics from the device it is monitoring. sFlow Datagrams are used
   to immediately forward the sampled traffic statistics to an sFlow
   Collector for analysis.

   This document describes the sampling mechanisms used by the sFlow
   Agent, the SFLOW MIB used by the sFlow Collector to control the sFlow
   Agent, and the sFlow Datagram Format used by the sFlow Agent to send
   traffic data to the sFlow Collector.

   This memo describes sFlow version 5. It replaces sFlow version 4
   described in RFC 3176 [1]. The differences between sFlow versions 4
   and 5 are described in Appendix A.

2. Terminology and Architecture

   This section defines the elements of the sFlow system.

2.1 Terminology




v1.00                           sFlow.org                       [Page 2]

FINAL                        sFlow Version 5                   July 2004


   The terms used to specify the sFlow architecture are defined here for
   reference.

   o Network Device: A piece of network equipment, such as a switch or
     router, that forwards data packets.

   o Data Source: A Data Source refers to a location within a Network
     Device that can make traffic measurements.  Possible Data Sources
     include interfaces, physical entities within the device such as the
     backplane and VLANs. Each Data Source has access to a subset of the
     traffic flowing through the device.

     The type and number of Data Sources needed to completely monitor a
     device will depend on the internal architecture of that device.
     Typically a Data Source is defined for each physical interface on
     the device since this ensures that every packet transiting the
     device to be observed.

   o Packet Flow: A Packet Flow is defined as the path or trajectory
     that a packet takes through a Network Device (i.e. the path that a
     packet takes as it is received on one interface, is subject to a
     switching/routing decision and is then sent on another interface.
     In the case of a one-armed router, the source and destination
     interface could be the same. In the case of a broadcast or
     multicast packet there may be multiple destination interfaces).

   o Packet Flow Sampling: Packet Flow Sampling refers to the random
     selection of a fraction of the Packet Flows observed at a Data
     Source.

   o Sampling Rate: The Sampling Rate specifies the ratio of packets
     observed at the Data Source to the samples generated. For example a
     sampling rate of 100 specifies that, on average, 1 sample will be
     generated for every 100 packets observed.

   o Packet Flow Record: A Packet Flow Record describes the attributes
     of a Packet Flow. There are two types of information in a flow
     record:

      1   Information on the packet itself, typically a packet header,
          packet length and packet encapsulation.

      2   Information about the path the packet took through the device,
          including information relating to the selection of the
          forwarding path.

   o Counter Sampling: Periodic sampling or polling of counters
     associated with a Data Source.



v1.00                           sFlow.org                       [Page 3]

FINAL                        sFlow Version 5                   July 2004


   o Sampling Interval: The time period between successive Counter
     Samples.

   o Counter Record: A record containing counter values associated with
     a Data Source at the end of a Sampling Interval.

   o sFlow Instance: An sFlow Instance refers to a measurement process
     associated with a Data Source.  There may be one or more sFlow
     Instances associated with a single Data Source.

     Each sFlow Instance operates independently of other sFlow
     Instances, for example if Packet Flow Sampling instances each have
     their own Sampling Rates and Counter Sampling instaces have their
     own Sampling Interval.

   o sFlow Agent: The sFlow Agent provides an interface for configuring
     the sFlow Instances within a device. The sFlow Agent may support
     command line and/or SNMP based configuration.

     The agent is also responsible for maintaining measurement sessions
     with sFlow Collectors. It marshals data into sFlow Datagrams to
     send to sFlow Collectors. The sFlow Agent frees resources when a
     session expires.

   o sFlow Sub-Agent: In the case where sFlow is implemented on a
     distributed device architecture it may be desireable to distribute
     the sFlow Agent functionality.  Each sFlow Sub-Agent is responsible
     for a particular subset of Data Sources.

   o sFlow Collector: An sFlow Collector receives sFlow Datagrams from
     one or more sFlow Agents.  The sFlow Collector may also configure
     sFlow Instances using the configuration mechanisms provided by the
     sFlow Agent.

   o sFlow Datagram: The sFlow Datagram is a UDP datagram that contains
     the measurement data, and information about the measurement source
     and process.  The format of the sFlow Datagram is defined in this
     document.

2.2 sFlow Reference Model

   The figure below shows the relationships between the different
   entities within an sFlow system.








v1.00                           sFlow.org                       [Page 4]

FINAL                        sFlow Version 5                   July 2004


   +--------------------------------------+
   |            Network Device            |
   |                                      |
   |  +--------------------------------+  |
   |  |              Agent             |  |
   |  |                                |  |
   |  |  +--------------------------+  |  |             +-------------+
   |  |  |         Sub-agent        |  |  |    SNMP     |             |
   |  |  |                          |  +<-+------------>+             |
   |  |  |  +--------------------+  |  |  |             |  Collector  |
   |  |  |  |     Data Source    |  |  |  |  Datagram   |             |
   |  |  |  |                    |  |  +--+------------>+             |
   |  |  |  |   +-------------+  |  |  |  |             |             |
   |  |  |  |   |  Instance   |  |  |  |  |             +-------------+
   |  |  |  |   +-------------+  |  |  |  |                    .
   |  |  |  |          .         |  |  |  |                    .
   |  |  |  |          .         |  |  |  |             +-------------+
   |  |  |  |   +-------------+  |  |  |  |      SNMP   |             |
   |  |  |  |   |  Instance   |  |  |  +<-+--+--------->+             |
   |  |  |  |   +-------------+  |  |  |  |  |          |  Collector  |
   |  |  |  +--------------------+  |  |  |  | Datagram |             |
   |  |  |             .            |  +--+--+--+------>+             |
   |  |  |             .            |  |  |  |  |       |             |
   |  |  |  +--------------------+  |  |  |  |  |       +-------------+
   |  |  |  |     Data Source    |  |  |  |  |  |
   |  |  |  +--------------------+  |  |  |  |  |
   |  |  +--------------------------+  |  |  |  |
   |  |                .               |  |  |  |
   |  |                .               |  |  |  |
   |  |  +--------------------------+  |  |  |  |
   |  |  |         Sub-agent        |  |  |  |  |
   |  |  +--------------------------+  |  |  |  |
   |  +--------------------------------+  |  |  |
   +--------------------------------------+  |  |
                       .                     |  |
                       .                     |  |
   +--------------------------------------+  |  |
   |             Network Device           |  |  |
   |  +--------------------------------+  |  |  |
   |  |                                +<-+--+  |
   |  |               Agent            |  |     |
   |  |                                +--+-----+
   |  +--------------------------------+  |
   +--------------------------------------+

   An sFlow Collector makes use of SNMP to communicate with an sFlow
   Agent in order to configure sFlow monitoring on a Network Device. The
   sFlow MIB describes the managed objects needed to configure an sFlow



v1.00                           sFlow.org                       [Page 5]

FINAL                        sFlow Version 5                   July 2004


   Agent. Packet Flow Sampling and Counter Sampling is performed by
   sFlow Instances associated with individual Data Sources within the
   sFlow Agent. In order to perform Packet Flow Sampling, an sFlow
   Instance is configured with a Sampling Rate. The Packet Flow sampling
   process results in the generation of Packet Flow Records. In order to
   perform Counter Sampling, an sFlow Instance is configured with a
   Sampling Interval.  The Counter Sampling process results in the
   generation of Counter Records.  The sFlow Agent collects Counter
   Records and Packet Flow Records and sends them in the form of sFlow
   Datagrams to sFlow Collectors.

3. Sampling Mechanisms

   The sFlow Agent uses two forms of sampling: statistical packet-based
   sampling of switched or routed Packet Flows, and time-based sampling
   of counters.

3.1 Packet Flow Sampling

   The Packet Flow Sampling mechanism carried out by 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.

   Packet Flow Sampling is accomplished as follows: When a packet
   arrives on an interface, the Network Device makes a filtering
   decision to determines whether the packet should be dropped. If the
   packet is not filtered a destination interface is assigned by the
   switching/routing function. At this point a decision is made on
   whether or not to sample the packet. The mechanism involves a counter
   that is decremented with each packet. When the counter reaches zero a
   sample is taken. Whether or not a sample is taken, the counter
   Total_Packets is incremented. Total_Packets is a count of all the
   packets that could have been sampled.

   Taking a sample involves either copying the packet's header, or
   extracting features from the packet. See sFlow Datagram Format for a
   description of the different forms of sample.

   Every time a sample is taken, the counter Total_Samples, is
   incremented. Total_Samples is a count of the number of samples
   generated. Samples are sent by the sFlow Instance to the sFlow Agent
   for processing. The sample includes the packet information, and the
   values of the Total_Packets and Total_Samples counters.  The sFlow
   Agent may then use the samples to obtain additional information about
   the packet's trajectory through the device.  Such information depends
   on the forwarding functions of the device.  Examples of trajectory
   information provided are source and destination interface, source and



v1.00                           sFlow.org                       [Page 6]

FINAL                        sFlow Version 5                   July 2004


   destination VLAN, next hop subnet, full AS path. Details of the
   forwarding information are given in the sFlow Datagram Format.

   When a sample is taken, the counter indicating how many packets to
   skip before taking the next sample should be reset. The value of the
   counter should be set to a random integer where the sequence of
   random integers used over time should be such that:

   (1) Total_Packets/Total_Samples = Sampling Rate

   An alternative strategy for Packet Flow Sampling is to generate a
   random number for each packet, compare the random number to a preset
   threshold and take a sample whenever the random number is smaller
   than the threshold value. Calculation of an appropriate threshold
   value depends on the characteristics of the random number generator,
   however, the resulting sample stream must still satisfy (1).

   Appendix B further discusses the requirements for the random number
   generator.

3.2 Counter Sampling

   The primary objective of the Counter Sampling is to efficiently,
   periodically export counters associated with Data Sources.

   Typically a Data Source will be associated with each interface on the
   device that can be an ingress or egress interface for Packet Flows.
   These interface Data Sources will then be used to export counters
   relating to the interfaces.

   A maximum Sampling Interval is assigned to each sFlow Instance
   associated with an interface Data Source, but the sFlow Agent is free
   to schedule polling in order maximize internal efficiency.

   Packet Flow Sampling and Counter Sampling are designed as part of an
   integrated system. Both types of sample are combined in sFlow
   Datagrams. Since Packet Flow Sampling will cause a steady, but
   random, stream of sFlow Datagrams to be sent to the sFlow Collector,
   counter samples may be taken opportunistically in order to fill these
   datagrams.

   One strategy for counter sampling has the sFlow Agent keep a list of
   counter sources being sampled. When a Packet Flow Sample is generated
   the sFlow Agent examines the list and adds counters to the sample
   datagram, least recently sampled first. Counters are only added to
   the datagram if the sources are within a short period, 5 seconds say,
   of failing to meet the required Sampling Interval (see
   sFlowCounterSamplingInterval in SFLOW MIB). Whenever a counter



v1.00                           sFlow.org                       [Page 7]

FINAL                        sFlow Version 5                   July 2004


   source's statistics are added to a sample datagram, the time the
   counter source was last sampled is updated and the counter source is
   placed at the end of the list. Periodically, say every second, the
   sFlow Agent examines the list of counter sources and sends any
   counters that need to be sent to meet the sampling interval
   requirement.

   If the sFlow Agent chooses to regularly schedule counter sampling,
   then it should schedule each counter source at a different start time
   (preferably randomly) so that counter sampling is not synchronised
   within an agent or between agents.

4. sFlow MIB

   The sFlow MIB provides a standard mechanism for remotely controlling
   and configuring an sFlow Agent.

4.1 The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   o An overall architecture, described in RFC 2571 [2].

   o Mechanisms for describing and naming objects and events for the
     purpose of management.  The first version of this Structure of Man-
     agement Information (SMI) is called SMIv1 and described in STD 16,
     RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The second
     version, called SMIv2, is described in STD 58, RFC 2578 [6], STD
     58, RFC 2579 [7] and STD 58, RFC 2580 [8].

   o Message protocols for transferring management information.  The
     first version of the SNMP message protocol is called SNMPv1 and
     described in STD 15, RFC 1157 [9]. A second version of the SNMP
     message protocol, which is not an Internet standards track proto-
     col, is called SNMPv2c and described in RFC 1901 [10] and RFC 1906
     [11]. The third version of the message protocol is called SNMPv3
     and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 [13].

   o Protocol operations for accessing management information.  The
     first set of protocol operations and associated PDU formats is
     described in STD 15, RFC 1157 [9]. A second set of protocol opera-
     tions and associated PDU formats is described in RFC 1905 [14].

   o A set of fundamental applications described in RFC 2573 [15] and
     the view-based access control mechanism described in RFC 2575 [16].

   A more detailed introduction to the current SNMP Management Framework



v1.00                           sFlow.org                       [Page 8]

FINAL                        sFlow Version 5                   July 2004


   can be found in RFC 2570 [17].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

4.2 Structure of the SFLOW MIB Module

   The MIB consists of three groups of objects: the receiver group, the
   flow sampling group and the counter polling group.

4.2.1 The Receiver Group

   The receiver group defines the set of objects used to maintain an
   sFlow session between an sFlow Agent and an sFlow Collector.

   Before making any configuration changes, an sFlow Collector must
   first find a free row in the receiver table and then claim it by
   writing its owner string and a reservation time into a free row in
   the receiver table. A session will automatically time out, and the
   associated resources freed, unless it is periodically refreshed by
   the the collector. By periodically refreshing its receiver table
   entry, an sFlow Collector ensures that its address is learned by any
   bridges on the path to the sFlow Agent, minimizing the chances that
   the sFlow Datagrams will be flooded by a bridge.

   Entries cannot be added to or removed from the receiver group table.
   An sFlow Agent implementor should limit the number of entries to
   ensure that the number of concurrent sFlow sessions is limited to a
   number that will not exceed that capacity of the device.

   Having acquired a row in the receiver table, the sFlow Collector
   specifies an address and port that it will use to receive sFlow
   Datagrams. The maximum size of sFlow Datagrams can be configured in
   order to prevent packet fragmentation.

4.2.2 The Flow Sampling Group




v1.00                           sFlow.org                       [Page 9]

FINAL                        sFlow Version 5                   July 2004


   The flow sampling group defines a set of locations, or Data Sources,
   in the device that are capable of Packet Flow sampling.  Data Sources
   may correspond to interfaces, VLANs or other entities within the
   device. The set of Data Sources advertised by an sFlow Agent depends
   on the device architecture. For example, a device may have packet
   sampling integrated into its interface ASICs, in which case it will
   advertise Data Sources for each interface.  Alternatively, a software
   router may simply have one Data Source associated with the routing
   module.

   Each Data Source may be capable of supporting more than one
   independent sampling process, in which case there will be multiple
   sFlow Instances associated with each Data Source. Each sFlow Instance
   can have its own independent sampling rate.

   Even if the Data Source hardware is only capable of generating a
   single stream of packet samples, it is possible for the sFlow Agent
   to use sub-sampling to create multiple sFlow Instances for the Data
   Source. For example, suppose there are two sFlow Instances, one
   configured with a Sampling Rate of 512 and the other with a rate of
   1024. The hardware can be configured to sample at a rate of 512 and
   then these samples can be sub-sampled in software using a sampling
   rate of 2 to achieve the 1024 rate. Only allowing Sampling Rates that
   are powers of two is attractive since it allows the smallest
   configured Sampling Rate to be set in hardware and all other sampling
   rates can be obtained in software by sub-sampling.

   A Flow Sampling Instance may have a minimum allowable Sampling Rate.
   Setting a conservative value that ensures that the sFlow Agent can
   never become overloaded with Packet Flow Samples under worst case
   traffic loads is not advisable. This yields minimum Sampling Rate
   values that are very high and don't reflect typical traffic levels.
   The Agent may implement an automated one-way backoff of the Sampling
   Rate that triggers whenever an excessive number of samples per second
   is generated.  When the triggered the Agent can double the Sampling
   Rate. If the threshold is exceeded again, the Sampling Rate is
   doubled again. The Sampling Rate will quickly reach a value that is
   sustainable. The sampling rate must stay at its new value and never
   automatically return to the originally configured value. The value
   may be changed back manually through the command line interface or
   via the sFlow MIB. This scheme protects against poorly chosen
   Sampling Rates or unexpected changes in peak traffic rates, but still
   allows low Sampling Rates to be safely selected where appropriate.

4.2.3 The Counter Polling Group

   The counter polling group defines a set of locations, or Data
   Sources, in the device that can provide counter information.



v1.00                           sFlow.org                      [Page 10]

FINAL                        sFlow Version 5                   July 2004


   Typically the Data Sources will be the interfaces on the device. Each
   Data Source may be capable of supporting more than one independent
   polling process, in which case there will be multiple counter polling
   instances associated with each data source.  Each counter polling
   instance can have its own independent polling interval.

4.3 Definitions

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)




v1.00                           sFlow.org                      [Page 11]

FINAL                        sFlow Version 5                   July 2004


                 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:



v1.00                           sFlow.org                      [Page 12]

FINAL                        sFlow Version 5                   July 2004


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



v1.00                           sFlow.org                      [Page 13]

FINAL                        sFlow Version 5                   July 2004


                 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>



v1.00                           sFlow.org                      [Page 14]

FINAL                        sFlow Version 5                   July 2004


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



v1.00                           sFlow.org                      [Page 15]

FINAL                        sFlow Version 5                   July 2004


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



v1.00                           sFlow.org                      [Page 16]

FINAL                        sFlow Version 5                   July 2004


                 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



v1.00                           sFlow.org                      [Page 17]

FINAL                        sFlow Version 5                   July 2004


              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 }



v1.00                           sFlow.org                      [Page 18]

FINAL                        sFlow Version 5                   July 2004


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



v1.00                           sFlow.org                      [Page 19]

FINAL                        sFlow Version 5                   July 2004


              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



v1.00                           sFlow.org                      [Page 20]

FINAL                        sFlow Version 5                   July 2004


                 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



v1.00                           sFlow.org                      [Page 21]

FINAL                        sFlow Version 5                   July 2004


              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 }



v1.00                           sFlow.org                      [Page 22]

FINAL                        sFlow Version 5                   July 2004


      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


   The sFlow MIB references definitions from a number of existing RFCs
   [18], [19], [20] and [21].

5. sFlow Datagram Format

   The sFlow Datagram format specifies a standard format for the sFlow
   Agent to send sampled data to a remote sFlow Collector.




v1.00                           sFlow.org                      [Page 23]

FINAL                        sFlow Version 5                   July 2004


   The format of the sFlow datagram is specified using the XDR standard
   [32].  XDR is more compact than ASN.1 and simpler for the sFlow Agent
   to encode and the sFlow Collector to decode.

   Samples are sent as UDP packets to the host and port specified in the
   SFLOW MIB. The assigned port for sFlow (and the default specified in
   the SFLOW MIB) is port 6343. All sFlow Agents and applications should
   default to using UDP port 6343. A standard sFlow port helps eliminate
   configuration problems between sFlow Agents and sFlow Collectors,
   sFlow traffic will be easier to identify, and it should make it
   easier to configure forwarding through intermediate devices such as
   firewalls.

   The lack of reliability in the UDP transport mechanism does not
   significantly affect the accuracy of the measurements obtained from
   an sFlow Agent.

   o If counter samples are lost then new values will be sent during the
     next polling interval. The chance of an undetected counter wrap is
     negligible.  The sFlow Datagram specifies 64 bit octet counters,
     and with typical counter polling intervals between 20 to 120 sec-
     onds the chance of a long enough sequence of sFlow Datagrams being
     lost to hide a counter wrap is very small.

   o The net effect of lost Packet Flow Samples is a slight reduction in
     the effective sampling rate.

   The use of UDP reduces the amount of memory required to buffer data.
   UDP also provides a robust means of delivering timely traffic
   information during periods of intense traffic (such as a denial of
   service attack). UDP is more robust than a reliable transport
   mechanism because under overload the only effect on overall system
   performance is a slight increase in transmission delay and a greater
   number of lost packets, neither of which has a significant effect on
   an sFlow-based monitoring sytem. If a reliable transport mechanism
   were used then an overload would introduce long transmission delays
   and require large amounts of buffer memory on the agent.

   While the sFlow Datagram structure permits multiple samples to be
   included in each datagram, the sFlow Agent must not wait for a buffer
   to fill with samples before sending the sFlow Datagram. sFlow is
   intended to provide timely information on traffic. The sFlow Agent
   may at most delay a sample by 1 second before it is required to send
   the datagram.

   The sFlow Agent should try to piggyback counter samples on the
   datagram stream resulting from Packet Flow Sampling. Before sending
   out a datagram the remaining space in the buffer can be filled with



v1.00                           sFlow.org                      [Page 24]

FINAL                        sFlow Version 5                   July 2004


   counter samples. The sFlow Agent has discretion in the timing of its
   counter polling, the specified counter sampling interval
   sFlowCounterSamplingInterval is a maximum, so the sFlow Agent is free
   to sample counters early if it has space in a datagram. If counters
   must be sent in order to satisfy the maximum sampling interval then a
   datagram must be sent containing the outstanding counters.

   The following is the XDR description of the sFlow Datagram:

/* Proposed sFlow Datagram Version 5 (draft 10) */

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



v1.00                           sFlow.org                      [Page 25]

FINAL                        sFlow Version 5                   July 2004


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



v1.00                           sFlow.org                      [Page 26]

FINAL                        sFlow Version 5                   July 2004


     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



v1.00                           sFlow.org                      [Page 27]

FINAL                        sFlow Version 5                   July 2004


                          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.



v1.00                           sFlow.org                      [Page 28]

FINAL                        sFlow Version 5                   July 2004


         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 */



v1.00                           sFlow.org                      [Page 29]

FINAL                        sFlow Version 5                   July 2004


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




v1.00                           sFlow.org                      [Page 30]

FINAL                        sFlow Version 5                   July 2004


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 */



v1.00                           sFlow.org                      [Page 31]

FINAL                        sFlow Version 5                   July 2004


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



v1.00                           sFlow.org                      [Page 32]

FINAL                        sFlow Version 5                   July 2004


                                     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;
}


   An sFlow Datagram contains lists of Packet Flow Records and counter
   records.  The format of each Packet Flow Record is identified by a
   data_format value.  The data_format name space is extensible,
   allowing for the addition of standard record types as well as vendor
   specific extensions.

   A number of standard record types have been defined. However, an
   sFlow Agent is not required to support all the different record
   types, only those applicable to its treatment of the particular
   packet being reporting on. For example, a layer 2 switch will not
   report on subnet information since it is not performing a routing
   function. A layer 2/3 switch will report layer 2 information for
   packets it switches, and layer 2 and 3 information for packets it
   routes.

   The following is an XDR description of the standard set of data
   records that can be carried in sFlow Datagrams:

/* Proposed standard sFlow data formats (draft 14) */



v1.00                           sFlow.org                      [Page 33]

FINAL                        sFlow Version 5                   July 2004


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



v1.00                           sFlow.org                      [Page 34]

FINAL                        sFlow Version 5                   July 2004


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



v1.00                           sFlow.org                      [Page 35]

FINAL                        sFlow Version 5                   July 2004


   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 */



v1.00                           sFlow.org                      [Page 36]

FINAL                        sFlow Version 5                   July 2004


   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;




v1.00                           sFlow.org                      [Page 37]

FINAL                        sFlow Version 5                   July 2004


/* 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 {



v1.00                           sFlow.org                      [Page 38]

FINAL                        sFlow Version 5                   July 2004


   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 */
}




v1.00                           sFlow.org                      [Page 39]

FINAL                        sFlow Version 5                   July 2004


/* 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



v1.00                           sFlow.org                      [Page 40]

FINAL                        sFlow Version 5                   July 2004


   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 */



v1.00                           sFlow.org                      [Page 41]

FINAL                        sFlow Version 5                   July 2004


/* 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;



v1.00                           sFlow.org                      [Page 42]

FINAL                        sFlow Version 5                   July 2004


  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) */
}

   The sFlow Datagram and data record specifications make use of
   definitions from a number of existing RFCs [22], [23], [24], [25],
   [26], [27], [28], [29], [30] and [31].

6. Security Considerations



v1.00                           sFlow.org                      [Page 43]

FINAL                        sFlow Version 5                   July 2004


   Deploying a traffic monitoring system raises a number of security
   related issues. sFlow does not provide specific security mechanisms,
   relying instead on proper deployment and configuration to maintain an
   adequate level of security.

   While the deployment of traffic monitoring systems does create some
   risk, it also provides a powerful means of detecting and tracing
   unauthorized network activity.

   This section is intended to provide information that will help
   understand potential risks and configuration options for mitigating
   those risks.

6.1 Configuration

   The sFlow MIB is used to configure the sFlow Agent. The security of
   SNMP, with access control lists, is usually considered adequate in an
   enterprise setting. However, there are situations when these security
   measures are insufficient (for example when configuring a core
   Internet router) and SNMP configuration control will be disabled.

   When SNMP is disabled, a command line interface is typically
   provided. The following arguments are required to configure sFlow
   sampling on an interface.

   -SFlowDataSource               <source>
   -sFlowFsPacketSamplingRate     <rate>
   -sFlowFsMaximumHeaderSize      <header size>
   -sFlowCpInterval               <interval>
   -sFlowRcvrMaximumDatagramSize  <datagram size>
   -sFlowRcvrCollectorAddress     <address>
   -sFlowRcvrCollectorPort        <port>

   If command line and SNMP control of the sFlow Agent coexist then an
   agent developer should either ensure that the two mechanisms operate
   independently or ensure that command line changes are reflected via
   the sFlow MIB. Typically command line changes will have priority over
   changes made via SNMP. Entries made through the command line should
   not be alterable via SNMP. Rows in each of the SNMP tables will then
   either belong to the command line (and not be alterable via SNMP), or
   belong to the SNMP agent, in which case they can be controlled using
   SNMP.

6.2 Transport

   Traffic information is sent unencrypted across the network from the
   sFlow Agent to the sFlow Collector and is thus vulnerable to
   evesdropping. This risk can be limited by creating a secure



v1.00                           sFlow.org                      [Page 44]

FINAL                        sFlow Version 5                   July 2004


   measurement network and routing the sFlow Datagrams over this
   network. The choice of technology for creating the secure measurement
   network is deployment specific, but could include the use of VLANs
   and/or VPN tunnels.

   The sFlow Collector is vulnerable to attacks involving spoofed sFlow
   Datagrams. To limit this vulnerability the sFlow Collector should
   check sequence numbers and verify source addresses. If a secure
   measurement network has been constructed then only sFlow Datagrams
   received from that network should be processed.

6.3 Confidentiality

   Traffic information can reveal confidential information about
   individual network users. The degree of visibility of application
   level data can be controlled by limiting the number of header bytes
   captured by the sFlow Agent. In addition, packet sampling makes it
   virtually impossible to capture sequences of packets from an
   individual transaction.

   The traffic patterns discernable by decoding the sFlow Datagrams in
   the sFlow Collector can reveal details of an individuals network
   related activities and due care should be taken to secure access to
   the sFlow Collector.

7. References

[1]  Phaal, P., Panchen, S., and N. McKee, "InMon Corporation's sFlow: A
     Method for Monitoring Traffic in Switched and Routed Networks", RFC
     3176, September 2001.

[2]  Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
     Describing SNMP Management Frameworks", RFC 2571, April 1999.

[3]  Rose, M., and K. McCloghrie, "Structure and Identification of Man-
     agement Information for TCP/IP-based Internets", STD 16, RFC 1155,
     May 1990.

[4]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC
     1212, March 1991.

[5]  Rose, M., "A Convention for Defining Traps for use with the SNMP",
     RFC 1215, March 1991.

[6]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
     and S. Waldbusser, "Structure of Management Information Version 2
     (SMIv2)", STD 58, RFC 2578, April 1999.




v1.00                           sFlow.org                      [Page 45]

FINAL                        sFlow Version 5                   July 2004


[7]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
     and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC
     2579, April 1999.

[8]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
     and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC
     2580, April 1999.

[9]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
     Management Protocol", STD 15, RFC 1157, May 1990.

[10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduc-
     tion to Community-based SNMPv2", RFC 1901, January 1996.

[11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport
     Mappings for Version 2 of the Simple Network Management Protocol
     (SNMPv2)", RFC 1906, January 1996.

[12] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Pro-
     cessing and Dispatching for the Simple Network Management Protocol
     (SNMP)", RFC 2572, April 1999.

[13] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for
     version 3 of the Simple Network Management Protocol (SNMPv3)", RFC
     2574, April 1999.

[14] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
     Operations for Version 2 of the Simple Network Management Protocol
     (SNMPv2)", RFC 1905, January 1996.

[15] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
     2573, April 1999.

[16] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Con-
     trol Model (VACM) for the Simple Network Management Protocol
     (SNMP)", RFC 2575, April 1999.

[17] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to
     Version 3 of the Internet-standard Network Management Framework",
     RFC 2570, April 1999.

[18] S. Waldbusser, "Remote Network Monitoring Management Information
     Base", RFC 2819, May 2000.

[19] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, "Remote
     Network Monitoring MIB Extensions for Switched Networks Version
     1.0", RFC 2613, June 1999.




v1.00                           sFlow.org                      [Page 46]

FINAL                        sFlow Version 5                   July 2004


[20] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder,
     "Textual Conventions for Internet Network Addresses", RFC 2851,
     June 2000.

[21] N. Brownlee, "Traffic Flow Measurement: Meter MIB", RFC 2720, Octo-
     ber 1999.

[22] Smith, A., Flick, J., de Graaf, K., Romanscanu, D., McMaster, D.,
     McCloghrie, K., and S. Roberts, "Definition of Managed Objects for
     IEEE 802.3 Medium Attachment Units (MAUs)", RFC 2668, August 1999.

[23] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC
     2863, June 2000.

[24] Flick, J., and J. Johnson, "Definition of Managed Objects for the
     Ethernet-like Interface Types", RFC 2358, June 1998.

[25] J. Case, "FDDI Management Information Base", RFC 1512, September
     1993.

[26] McCloghrie, K., and E. Decker, "IEEE 802.5 MIB using SMIv2", RFC
     1748, December 1994.

[27] J. Flick, "Definitions of Managed Objects for IEEE 802.12 Inter-
     faces", RFC 2020, October 1996.

[28] Willis, S., Burruss, J., and J. Chu, "Definitions of Managed
     Objects for the Fourth Version of the Border Gateway Protocol
     (BGP-4) using SMIv2", RFC 1657, July 1994.

[29] Baker, F. (Editor), "Requirements for IP Version 4 Routers", RFC
     1812, June 1995.

[30] F. Baker, "IP Forwarding Table MIB", RFC 2096, January 1997.

[31] D. Haskin and S. Onishi, "Management Information Base for IP Ver-
     sion 6", RFC 2465, December 1998.

[32] R. Srinivasan, "XDR: External Data Representation Standard", RFC
     1832, August 1995.

8. Author's Address

   Peter Phaal
   InMon Corp.
   580 California Street, 5th Floor
   San Francisco, CA 94104




v1.00                           sFlow.org                      [Page 47]

FINAL                        sFlow Version 5                   July 2004


   Phone: (415) 283-3263

   EMail: peter.phaal@inmon.com

   Marc Lavine
   Foundry Networks
   2100 Gold Street
   P.O. Box 649100
   San Jose, CA 95164-9100

   Phone: (408) 586-1700
   EMail: mlavine@foundrynet.com







































v1.00                           sFlow.org                      [Page 48]

FINAL                        sFlow Version 5                   July 2004


Appendix A: Differences Between sFlow Versions 4 and 5

   While the overall sFlow architecture has not changed, there have been
   numerous changes to the sFlow MIB and Datagram formats. These changes
   are described in detail in the revision histories contained in each
   of these specifications.

   The major difference in the sFlow version 5 MIB is the division of
   the sFlowTable into three separate tables:

   o sFlowRcvrTable, for maintaining a session with an sFlow collector.

   o sFlowFsTable, for configuring a packet sampling.

   o sFlowCpTable, for configuring interface counter polling.

   The major changes in the sFlow Datagram specification revolve around
   vendor extensibility. Records within the datagram now have tag,
   length and value information. A global name space is defined for
   record types, allowing implementors to add their own record types.
   Extensibility also permits the addition of new record types without
   requiring changes to the published sFlow protocol.





























v1.00                           sFlow.org                      [Page 49]

FINAL                        sFlow Version 5                   July 2004


Appendix B: Random Number Generation

   The essential property of the random number generator is that the
   mean value of the numbers it generates converges to the required
   sampling rate.

   A uniform distribution random number generator is very effective. The
   range of skip counts (the variance) does not significantly affect
   results; even small random perturbations are sufficient to ensure
   that the sampling process will not synchronize with periodicity
   within the packet stream.

   The random number generator must ensure that all numbers in the range
   between its maximum and minimum values of the distribution are
   possible; a random number generator only capable of generating even
   numbers, or numbers with any common divisor is unsuitable.

   A new skip value is only required every time a sample is taken.

































v1.00                           sFlow.org                      [Page 50]

