doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc3176.txt b/doc/rfc/rfc3176.txt
new file mode 100644
index 0000000..962858b
--- /dev/null
+++ b/doc/rfc/rfc3176.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                           P. Phaal
+Request for Comments: 3176                                    S. Panchen
+Category: Informational                                         N. McKee
+                                                             InMon Corp.
+                                                          September 2001
+
+
+     InMon Corporation's sFlow: A Method for Monitoring Traffic in
+                      Switched and Routed Networks
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This memo defines InMon Coporation's sFlow system.  sFlow is a
+   technology for monitoring traffic in data networks containing
+   switches and routers.  In particular, it defines the sampling
+   mechanisms implemented in an sFlow Agent for monitoring traffic, the
+   sFlow MIB for controlling the sFlow Agent, and the format of sample
+   data used by the sFlow Agent when forwarding data to a central data
+   collector.
+
+Table of Contents
+
+   1.  Overview .....................................................  2
+   2.  Sampling Mechanisms ..........................................  2
+       2.1 Sampling of Switched Flows ...............................  3
+           2.1.1 Distributed Switching ..............................  4
+           2.1.2 Random Number Generation ...........................  4
+       2.2 Sampling of Network Interface Statistics .................  4
+   3.  sFlow MIB ....................................................  5
+       3.1 The SNMP Management Framework ............................  5
+       3.2 Definitions ..............................................  6
+   4.  sFlow Datagram Format ........................................ 14
+   5.  Security Considerations ...................................... 25
+       5.1 Control .................................................. 26
+       5.2 Transport ................................................ 26
+       5.3 Confidentiality .......................................... 26
+   6.  References ................................................... 27
+   7.  Authors' Addresses ........................................... 29
+
+
+
+Phaal, et al.                Informational                      [Page 1]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+   8.  Intellectual Property Statement .............................. 30
+   9.  Full Copyright Statement ..................................... 31
+
+1. Overview
+
+   sFlow is a technology for monitoring traffic in data networks
+   containing switches and routers.  In particular, it defines the
+   sampling mechanisms implemented in an sFlow Agent for monitoring
+   traffic, the sFlow MIB for controlling the sFlow Agent, and the
+   format of sample data used by the sFlow Agent when forwarding data to
+   a central data collector.
+
+   The architecture and sampling techniques used in the sFlow monitoring
+   system are designed to provide continuous site-wide (and network-
+   wide) traffic monitoring for high speed switched and routed networks.
+
+   The design specifically addresses issues associated with:
+
+   o Accurately monitoring network traffic at Gigabit speeds and higher.
+
+   o Scaling to manage tens of thousands of agents from a single point.
+
+   o Extremely low cost agent implementation.
+
+   The sFlow monitoring system consists of an sFlow Agent (embedded in a
+   switch or router or in a stand alone probe) and a central data
+   collector, or sFlow Analyzer.
+
+   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 Analyzer for analysis.
+
+   This document describes the sampling mechanisms used by the sFlow
+   Agent, the SFLOW MIB used by the sFlow Analyzer to control the sFlow
+   Agent, and the sFlow Datagram Format used by the sFlow Agent to send
+   traffic data to the sFlow Analyzer.
+
+2. Sampling Mechanisms
+
+   The sFlow Agent uses two forms of sampling: statistical packet-based
+   sampling of switched flows, and time-based sampling of network
+   interface statistics.
+
+
+
+
+
+
+
+
+Phaal, et al.                Informational                      [Page 2]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+2.1 Sampling of Switched Flows
+
+   A flow is defined as all the packets that are received on one
+   interface, enter the Switching/Routing Module and are sent to 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.
+   The sampling mechanism must ensure that any packet involved in a flow
+   has an equal chance of being sampled, irrespective of the flow to
+   which it belongs.
+
+   Sampling flows is accomplished as follows: When a packet arrives on
+   an interface, a filtering decision is made that 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 sampling entity to the sFlow Agent for processing.  The sample
+   includes the packet information, and the values of the Total_Packets
+   and Total_Samples counters.
+
+   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 = Rate
+
+   An alternative strategy for packet 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).
+
+
+
+
+
+
+
+Phaal, et al.                Informational                      [Page 3]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+2.1.1 Distributed Switching
+
+   The SFLOW MIB permits separate sampling entities to be associated
+   with different physical or logical elements of the switch (such as
+   interfaces, backplanes or VLANs).  Each sampling engine has its own
+   independent state (i.e., Total_Packets, Total_Samples, Skip and
+   Rate), and forwards its own sample messages to the sFlow Agent.  The
+   sFlow Agent is responsible for packaging the samples into datagrams
+   for transmission to an sFlow Analyzer.
+
+2.1.2 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; variation of +-10% of the mean value is sufficient.
+
+   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.
+
+2.2 Sampling of Network Interface Statistics
+
+   The objective of the counter sampling is to efficiently, periodically
+   poll each data source on the device and extract key statistics.
+
+   For efficiency and scalability reasons, the sFlow System implements
+   counter polling in the sFlow Agent.  A maximum polling interval is
+   assigned to the agent, but the agent is free to schedule polling in
+   order maximize internal efficiency.
+
+   Flow sampling and counter sampling are designed as part of an
+   integrated system.  Both types of samples are combined in sFlow
+   Datagrams.  Since flow sampling will cause a steady, but random,
+   stream of datagrams to be sent to the sFlow Analyzer, 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 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,
+
+
+
+Phaal, et al.                Informational                      [Page 4]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+   of failing to meet the required sampling interval (see
+   sFlowCounterSamplingInterval in SFLOW MIB).  Whenever a counter
+   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.
+
+   Alternatively, if the agent regularly schedules counter sampling,
+   then it should schedule each counter source at a different start time
+   (preferably randomly) so that counter sampling is not synchronized
+   within an agent or between agents.
+
+3. sFlow MIB
+
+   The sFlow MIB defines a control interface for an sFlow Agent.  This
+   interface provides a standard mechanism for remotely controlling and
+   configuring an sFlow Agent.
+
+3.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
+      Management 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
+      protocol, 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].
+
+
+
+
+
+
+
+Phaal, et al.                Informational                      [Page 5]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+   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
+      operations 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
+   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.
+
+3.2 Definitions
+
+SFLOW-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+
+MODULE-IDENTITY, OBJECT-TYPE, Integer32, enterprises
+        FROM SNMPv2-SMI
+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 "200105150000Z"   -- May 15, 2001
+  ORGANIZATION "InMon Corp."
+  CONTACT-INFO
+
+
+
+Phaal, et al.                Informational                      [Page 6]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+         "Peter Phaal
+          InMon Corp.
+          http://www.inmon.com/
+
+          Tel:  +1-415-661-6343
+          Email: peter_phaal@inmon.com"
+  DESCRIPTION
+          "The MIB module for managing the generation and transportation
+           of sFlow data records."
+
+  --
+  -- Revision History
+  --
+  REVISION    "200105150000Z"     -- May 15, 2001
+  DESCRIPTION
+          "Version 1.2
+
+           Brings MIB into SMI v2 compliance."
+
+  REVISION    "200105010000Z"      -- May 1, 2001
+  DESCRIPTION
+           "Version 1.1
+
+            Adds sFlowDatagramVersion."
+  ::= { enterprises 4300 1 }
+
+sFlowAgent OBJECT IDENTIFIER ::= { sFlowMIB 1 }
+
+sFlowVersion OBJECT-TYPE
+     SYNTAX      SnmpAdminString
+     MAX-ACCESS  read-only
+     STATUS      current
+     DESCRIPTION
+       "Uniquely identifies the version and implementation of this MIB.
+        The version string must have the following structure:
+           <MIB Version>;<Organization>;<Software Revision>
+        where:
+           <MIB Version>  must be '1.2', 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.2;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
+
+
+
+Phaal, et al.                Informational                      [Page 7]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+        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.2;;" }
+     ::= { sFlowAgent 1 }
+
+sFlowAgentAddressType OBJECT-TYPE
+     SYNTAX      InetAddressType
+     MAX-ACCESS  read-only
+     STATUS      current
+     DESCRIPTION
+       "The address type of the address associated with this agent.
+        Only ipv4 and ipv6 types are supported."
+     ::= { sFlowAgent 2 }
+
+sFlowAgentAddress OBJECT-TYPE
+     SYNTAX      InetAddress
+     MAX-ACCESS  read-only
+     STATUS      current
+     DESCRIPTION
+       "The IP address associated with this agent.  In the case of a
+        multi-homed agent, this should be the loopback address of the
+        agent.  The sFlowAgent address must provide SNMP connectivity
+        to the agent.  The address should be an invariant that does not
+        change as interfaces are reconfigured, enabled, disabled,
+        added or removed.  A manager should be able to use the
+        sFlowAgentAddress as a unique key that will identify this
+        agent over extended periods of time so that a history can
+        be maintained."
+    ::= { sFlowAgent 3 }
+
+sFlowTable OBJECT-TYPE
+     SYNTAX      SEQUENCE OF SFlowEntry
+     MAX-ACCESS  not-accessible
+     STATUS      current
+     DESCRIPTION
+       "A table of the sFlow samplers within a device."
+     ::= { sFlowAgent 4 }
+
+sFlowEntry OBJECT-TYPE
+     SYNTAX      SFlowEntry
+
+
+
+Phaal, et al.                Informational                      [Page 8]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+     MAX-ACCESS  not-accessible
+     STATUS      current
+     DESCRIPTION
+       "Attributes of an sFlow sampler."
+     INDEX { sFlowDataSource }
+     ::= { sFlowTable 1 }
+
+SFlowEntry ::= SEQUENCE {
+     sFlowDataSource               OBJECT IDENTIFIER,
+     sFlowOwner                    OwnerString,
+     sFlowTimeout                  Integer32,
+     sFlowPacketSamplingRate       Integer32,
+     sFlowCounterSamplingInterval  Integer32,
+     sFlowMaximumHeaderSize        Integer32,
+     sFlowMaximumDatagramSize      Integer32,
+     sFlowCollectorAddressType     InetAddressType,
+     sFlowCollectorAddress         InetAddress,
+     sFlowCollectorPort            Integer32,
+     sFlowDatagramVersion          Integer32
+}
+
+sFlowDataSource OBJECT-TYPE
+     SYNTAX      OBJECT IDENTIFIER
+     MAX-ACCESS  read-only
+     STATUS      current
+     DESCRIPTION
+       "Identifies the source of the data for the sFlow sampler.
+       The following data source types are currently defined:
+
+       - ifIndex.<I>
+       DataSources 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 permits 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.
+             - sFlowPacketSamplingRate applies to all ports on the
+               device capable of packet sampling.
+             - sFlowCounterSamplingInterval applies to all ports.
+
+       - smonVlanDataSource.<V>
+       A dataSource of this form refers to a 'Packet-based VLAN'
+       and is called a 'VLAN-based' dataSource.  <V> is the VLAN
+
+
+
+Phaal, et al.                Informational                      [Page 9]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+       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>
+       A dataSource 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 DataSource operates independently, a packet
+             that crosses multiple DataSources may generate multiple
+             flow records."
+     ::= { sFlowEntry 1 }
+
+sFlowOwner OBJECT-TYPE
+     SYNTAX      OwnerString
+     MAX-ACCESS  read-write
+     STATUS      current
+     DESCRIPTION
+       "The entity making use of this sFlow sampler.  The empty string
+        indicates that the sFlow sampler is currently unclaimed.
+        An entity wishing to claim an sFlow sampler must make sure
+        that the sampler is unclaimed before trying to claim it.
+        The sampler is claimed by setting the owner string to identify
+        the entity claiming the sampler.  The sampler 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
+        sFlowTimeout in the same SNMP set request.
+
+        When a management entity is finished using the sampler,
+        it should set its value back to unclaimed.  The agent
+        must restore all other entities this row to their
+        default values when the owner is set to unclaimed.
+
+        This mechanism provides no enforcement and relies on the
+        cooperation of management entities in order to ensure that
+
+
+
+Phaal, et al.                Informational                     [Page 10]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+        competition for a sampler is fairly resolved."
+     DEFVAL { "" }
+     ::= { sFlowEntry 2 }
+
+sFlowTimeout 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."
+     DEFVAL { 0 }
+     ::= { sFlowEntry 3 }
+
+sFlowPacketSamplingRate 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 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
+
+
+
+Phaal, et al.                Informational                     [Page 11]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+        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 }
+     ::= { sFlowEntry 4 }
+
+sFlowCounterSamplingInterval 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."
+     DEFVAL { 0 }
+     ::= { sFlowEntry 5 }
+
+sFlowMaximumHeaderSize OBJECT-TYPE
+     SYNTAX      Integer32
+     MAX-ACCESS  read-write
+     STATUS      current
+     DESCRIPTION
+       "The maximum number of bytes that should be copied from a
+        sampled packet.  The agent may have an internal maximum and
+        minimum permissible sizes.  If an attempt is made to set this
+        value outside the permissible range then the agent should
+        adjust the value to the closest permissible value."
+     DEFVAL { 128 }
+     ::= { sFlowEntry 6 }
+
+sFlowMaximumDatagramSize OBJECT-TYPE
+     SYNTAX      Integer32
+     MAX-ACCESS  read-write
+     STATUS      current
+     DESCRIPTION
+        "The maximum number of data bytes that can be sent in a single
+         sample datagram.  The manager should set this value to avoid
+         fragmentation of the sFlow datagrams."
+     DEFVAL { 1400 }
+     ::= { sFlowEntry 7 }
+
+sFlowCollectorAddressType OBJECT-TYPE
+     SYNTAX      InetAddressType
+     MAX-ACCESS  read-write
+
+
+
+Phaal, et al.                Informational                     [Page 12]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+     STATUS      current
+     DESCRIPTION
+       "The type of sFlowCollectorAddress."
+     DEFVAL { ipv4 }
+     ::= { sFlowEntry 8 }
+
+sFlowCollectorAddress 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 all sampling is disabled."
+     DEFVAL { "0.0.0.0" }
+     ::= { sFlowEntry 9 }
+
+sFlowCollectorPort OBJECT-TYPE
+     SYNTAX      Integer32
+     MAX-ACCESS  read-write
+     STATUS      current
+     DESCRIPTION
+       "The destination port for sFlow datagrams."
+     DEFVAL { 6343 }
+     ::= { sFlowEntry 10 }
+
+sFlowDatagramVersion 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 error if no such values exist."
+     DEFVAL { 4 }
+     ::= { sFlowEntry 11 }
+
+ --
+ -- Compliance Statements
+ --
+
+sFlowMIBConformance OBJECT IDENTIFIER ::= { sFlowMIB 2 }
+sFlowMIBGroups      OBJECT IDENTIFIER ::= { sFlowMIBConformance 1 }
+sFlowMIBCompliances OBJECT IDENTIFIER ::= { sFlowMIBConformance 2 }
+
+sFlowCompliance MODULE-COMPLIANCE
+     STATUS      current
+
+
+
+Phaal, et al.                Informational                     [Page 13]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+     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 sFlowCollectorAddressType
+         SYNTAX InetAddressType { ipv4(1) }
+         DESCRIPTION
+           "Agents need only support ipv4."
+
+     ::= { sFlowMIBCompliances 1 }
+
+sFlowAgentGroup OBJECT-GROUP
+     OBJECTS { sFlowVersion, sFlowAgentAddressType, sFlowAgentAddress,
+               sFlowDataSource, sFlowOwner, sFlowTimeout,
+               sFlowPacketSamplingRate, sFlowCounterSamplingInterval,
+               sFlowMaximumHeaderSize, sFlowMaximumDatagramSize,
+               sFlowCollectorAddressType, sFlowCollectorAddress,
+               sFlowCollectorPort, sFlowDatagramVersion }
+      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].
+
+4. sFlow Datagram Format
+
+   The sFlow datagram format specifies a standard format for the sFlow
+   Agent to send sampled data to a remote data collector.
+
+   The format of the sFlow datagram is specified using the XDR standard
+   [1].  XDR is more compact than ASN.1 and simpler for the sFlow Agent
+   to encode and the sFlow Analyzer to decode.
+
+   Samples are sent as UDP packets to the host and port specified in the
+   SFLOW MIB.  The lack of reliability in the UDP transport mechanism
+   does not significantly affect the accuracy of the measurements
+   obtained from an sFlow Agent.
+
+
+
+Phaal, et al.                Informational                     [Page 14]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+   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 seconds, 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 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 system.  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 sampling agent must not wait for a
+   buffer to fill with samples before sending the sample datagram.
+   sFlow sampling is intended to provide timely information on traffic.
+   The agent may at most delay a sample by 1 second before it is
+   required to send the datagram.
+
+   The agent should try to piggyback counter samples on the datagram
+   stream resulting from flow sampling.  Before sending out a datagram
+   the remaining space in the buffer can be filled with counter samples.
+   The agent has discretion in the timing of its counter polling, the
+   specified counter sampling intervals sFlowCounterSamplingInterval is
+   a maximum, so the 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 an sFlow Datagram:
+
+/* sFlow Datagram Version 4 */
+
+/* Revision History
+   - version 4 adds support BGP communities
+   - version 3 adds support for extended_url information
+*/
+
+/* sFlow Sample types */
+
+
+
+Phaal, et al.                Informational                     [Page 15]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+/* Address Types */
+
+typedef opaque ip_v4[4];
+typedef opaque ip_v6[16];
+
+enum address_type {
+   IP_V4    = 1,
+   IP_V6    = 2
+}
+
+union address (address_type type) {
+   case IP_V4:
+     ip_v4;
+   case IP_V6:
+     ip_v6;
+}
+
+/* Packet header data */
+
+const MAX_HEADER_SIZE = 256;   /* The maximum sampled header size. */
+
+/* The header protocol describes the format of the sampled header */
+enum header_protocol {
+   ETHERNET-ISO8023     = 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
+}
+
+struct sampled_header {
+   header_protocol protocol;       /* Format of sampled header */
+   unsigned int frame_length;      /* Original length of packet before
+                                      sampling */
+   opaque header<MAX_HEADER_SIZE>; /* Header bytes */
+}
+
+/* Packet IP version 4 data */
+
+struct sampled_ipv4 {
+
+
+
+Phaal, et al.                Informational                     [Page 16]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+   unsigned int length;     /* The length of the IP packet excluding
+                               lower layer encapsulations */
+   unsigned int protocol;   /* IP Protocol type
+                               (for example, TCP = 6, UDP = 17) */
+   ip_v4 src_ip;            /* Source IP Address */
+   ip_v4 dst_ip;            /* Destination IP Address */
+   unsigned int src_port;   /* TCP/UDP source port number or
+                               equivalent */
+   unsigned int dst_port;   /* TCP/UDP destination port number or
+                               equivalent */
+   unsigned int tcp_flags;  /* TCP flags */
+   unsigned int tos;        /* IP type of service */
+}
+/* Packet IP version 6 data */
+
+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 */
+}
+
+
+/* Packet data */
+
+enum packet_information_type {
+   HEADER  = 1,      /* Packet headers are sampled */
+   IPV4    = 2,      /* IP version 4 data */
+   IPV6    = 3       /* IP version 6 data */
+}
+
+union packet_data_type (packet_information_type type) {
+   case HEADER:
+      sampled_header header;
+   case IPV4:
+      sampled_ipv4 ipv4;
+   case IPV6:
+      sampled_ipv6 ipv6;
+}
+
+
+
+
+Phaal, et al.                Informational                     [Page 17]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+/* Extended data types */
+
+/* Extended switch data */
+
+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 */
+}
+
+/* Extended router data */
+
+struct extended_router {
+   address nexthop;         /* IP address of next hop router */
+   unsigned int src_mask;   /* Source address prefix mask bits */
+   unsigned int dst_mask;   /* Destination address prefix mask bits */
+}
+
+/* Extended gateway data */
+
+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<>;
+}
+
+struct extended_gateway {
+   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 */
+}
+
+
+
+
+Phaal, et al.                Informational                     [Page 18]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+/* Extended user data */
+
+struct extended_user {
+   string src_user<>;          /* User ID associated with packet
+                                  source */
+   string dst_user<>;          /* User ID associated with packet
+                                  destination */
+
+}
+
+/* Extended URL data */
+
+enum url_direction {
+   src    = 1,                 /* URL is associated with source
+                                  address */
+   dst    = 2                  /* URL is associated with destination
+                                  address */
+}
+
+struct extended_url {
+   url_direction direction;    /* URL associated with packet source */
+   string url<>;               /* URL associated with the packet flow */
+}
+
+/* Extended data */
+enum extended_information_type {
+   SWITCH    = 1,      /* Extended switch information */
+   ROUTER    = 2,      /* Extended router information */
+   GATEWAY   = 3,      /* Extended gateway router information */
+   USER      = 4,      /* Extended TACACS/RADIUS user information */
+   URL       = 5       /* Extended URL information */
+}
+
+union extended_data_type (extended_information_type type) {
+   case SWITCH:
+      extended_switch switch;
+   case ROUTER:
+      extended_router router;
+   case GATEWAY:
+      extended_gateway gateway;
+   case USER:
+      extended_user user;
+   case URL:
+      extended_url url;
+}
+
+/* Format of a single flow sample */
+
+
+
+
+Phaal, et al.                Informational                     [Page 19]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+struct flow_sample {
+unsigned int sequence_number;    /* Incremented with each flow sample
+                                    generated by this source_id */
+unsigned int source_id;          /* sFlowDataSource encoded as follows:
+                                    The most significant byte of the
+                                    source_id is used to indicate the
+                                    type of sFlowDataSource
+                                    (0 = ifIndex,
+                                    1 = smonVlanDataSource,
+                                    2 = entPhysicalEntry) and the
+                                    lower three bytes contain the
+                                    relevant index value.*/
+
+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 times a packet was dropped
+                                    due to lack of resources */
+
+unsigned int input;               /* SNMP ifIndex of input interface.
+                                     0 if interface is not known.  */
+unsigned int output;              /* SNMP ifIndex of output interface,
+                                     0 if interface is not known.
+                                     Set most significant bit to
+                                     indicate multiple destination
+                                     interfaces (i.e., in case of
+                                     broadcast or multicast)
+                                     and set lower order bits to
+                                     indicate number of destination
+                                     interfaces.
+                                     Examples:
+                                        0x00000002  indicates ifIndex =
+                                                    2
+                                        0x00000000  ifIndex unknown.
+                                        0x80000007  indicates a packet
+                                                    sent to 7
+                                                    interfaces.
+                                        0x80000000  indicates a packet
+                                                    sent to an unknown
+                                                    number of interfaces
+                                                    greater than 1. */
+
+   packet_data_type packet_data;       /* Information about sampled
+                                          packet */
+   extended_data_type extended_data<>; /* Extended flow information */
+}
+
+
+
+Phaal, et al.                Informational                     [Page 20]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+/* Counter types */
+
+/* Generic interface counters - see RFC 2233 */
+
+struct if_counters {
+   unsigned int ifIndex;
+   unsigned int ifType;
+   unsigned hyper ifSpeed;
+   unsigned int ifDirection;    /* derived from MAU MIB (RFC 2668)
+                                   0 = unknown, 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 */
+
+struct ethernet_counters {
+   if_counters generic;
+   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;
+
+
+
+Phaal, et al.                Informational                     [Page 21]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+   unsigned int dot3StatsInternalMacReceiveErrors;
+   unsigned int dot3StatsSymbolErrors;
+}
+
+/* FDDI interface counters - see RFC 1512 */
+struct fddi_counters {
+  if_counters generic;
+}
+
+/* Token ring counters - see RFC 1748 */
+
+struct tokenring_counters {
+  if_counters generic;
+  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 */
+
+struct vg_counters {
+  if_counters generic;
+  unsigned int dot12InHighPriorityFrames;
+  unsigned hyper dot12InHighPriorityOctets;
+  unsigned int dot12InNormPriorityFrames;
+  unsigned hyper dot12InNormPriorityOctets;
+  unsigned int dot12InIPMErrors;
+  unsigned int dot12InOversizeFrameErrors;
+  unsigned int dot12InDataErrors;
+  unsigned int dot12InNullAddressedFrames;
+  unsigned int dot12OutHighPriorityFrames;
+  unsigned hyper dot12OutHighPriorityOctets;
+  unsigned int dot12TransitionIntoTrainings;
+
+
+
+Phaal, et al.                Informational                     [Page 22]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+  unsigned hyper dot12HCInHighPriorityOctets;
+  unsigned hyper dot12HCInNormPriorityOctets;
+  unsigned hyper dot12HCOutHighPriorityOctets;
+}
+
+/* WAN counters */
+
+struct wan_counters {
+  if_counters generic;
+}
+
+/* VLAN counters */
+
+struct vlan_counters {
+  unsigned int vlan_id;
+  unsigned hyper octets;
+  unsigned int ucastPkts;
+  unsigned int multicastPkts;
+  unsigned int broadcastPkts;
+  unsigned int discards;
+}
+
+/* Counter data */
+
+enum counters_version {
+   GENERIC      = 1,
+   ETHERNET     = 2,
+   TOKENRING    = 3,
+   FDDI         = 4,
+   VG           = 5,
+   WAN          = 6,
+   VLAN         = 7
+}
+
+union counters_type (counters_version version) {
+   case GENERIC:
+      if_counters generic;
+   case ETHERNET:
+      ethernet_counters ethernet;
+   case TOKENRING:
+      tokenring_counters tokenring;
+   case FDDI:
+      fddi_counters fddi;
+   case VG:
+      vg_counters vg;
+   case WAN:
+      wan_counters wan;
+   case VLAN:
+
+
+
+Phaal, et al.                Informational                     [Page 23]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+      vlan_counters vlan;
+}
+
+/* Format of a single counter sample */
+
+struct counters_sample {
+   unsigned int sequence_number;   /* Incremented with each counter
+                                      sample generated by this
+                                      source_id */
+   unsigned int source_id;         /* sFlowDataSource encoded as
+                                      follows:
+                                       The most significant byte of the
+                                       source_id is used to indicate the
+                                       type of sFlowDataSource
+                                       (0 = ifIndex,
+                                       1 = smonVlanDataSource,
+                                       2 = entPhysicalEntry) and the
+                                           lower three
+                                       bytes contain the relevant
+                                       index value.*/
+
+   unsigned int sampling_interval; /* sFlowCounterSamplingInterval*/
+   counters_type counters;
+}
+
+/* Format of a sample datagram */
+
+enum sample_types {
+   FLOWSAMPLE  = 1,
+   COUNTERSSAMPLE = 2
+}
+
+union sample_type (sample_types sampletype) {
+   case FLOWSAMPLE:
+      flow_sample flowsample;
+   case COUNTERSSAMPLE:
+      counters_sample counterssample;
+}
+
+struct sample_datagram_v4 {
+   address agent_address           /* IP address of sampling agent,
+                                      sFlowAgentAddress. */
+   unsigned int sequence_number;  /* Incremented with each sample
+                                     datagram generated */
+   unsigned int uptime;           /* Current time (in milliseconds since
+                                     device last booted).  Should be set
+                                     as close to datagram transmission
+                                     time as possible.*/
+
+
+
+Phaal, et al.                Informational                     [Page 24]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+   sample_type samples<>;         /* An array of flow, counter and delay
+                                     samples */
+}
+
+enum datagram_version {
+   VERSION4 = 4
+}
+
+union sample_datagram_type (datagram_version version) {
+   case VERSION4:
+      sample_datagram_v4 datagram;
+}
+
+struct sample_datagram {
+   sample_datagram_type version;
+}
+
+   The sFlow Datagram specification makes use of definitions from a
+   number of existing RFCs [22], [23], [24], [25], [26], [27] and [28].
+
+5. Security Considerations
+
+   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.
+
+5.1 Control
+
+   The sFlow MIB is used to configure the generation of sFlow samples.
+   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
+   a WAN 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.
+
+
+
+
+
+Phaal, et al.                Informational                     [Page 25]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+   -sFlowDataSource               <source>
+   -sFlowPacketSamplingRate       <rate>
+   -sFlowCounterSamplingInterval  <interval>
+   -sFlowMaximumHeaderSize        <header size>
+   -sFlowMaximumDatagramSize      <datagram size>
+   -sFlowCollectorAddress         <address>
+   -sFlowCollectorPort            <port>
+
+5.2 Transport
+
+   Traffic information is sent unencrypted across the network from the
+   sFlow Agent to the sFlow Analyzer and is thus vulnerable to
+   eavesdropping.  This risk can be limited by creating a secure
+   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 or VPN tunnels.
+
+   The sFlow Analyzer is vulnerable to attacks involving spoofed sFlow
+   Datagrams.  To limit this vulnerability the sFlow Analyzer 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.
+
+5.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 discernible by decoding the sFlow Datagrams in
+   the sFlow Analyzer can reveal details of an individual's network
+   related activities and due care should be taken to secure access to
+   the sFlow Analyzer.
+
+6. References
+
+   [1]   Sun Microsystems, Inc., "XDR: External Data Representation
+         Standard", RFC 1014, June 1987.
+
+   [2]   Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
+         for Describing SNMP Management Frameworks", RFC 2571, April
+         1999.
+
+
+
+
+
+Phaal, et al.                Informational                     [Page 26]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+   [3]   Rose, M. and K. McCloghrie, "Structure and Identification of
+         Management 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.
+
+   [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,
+         "Introduction 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
+         Processing 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.
+
+
+
+
+Phaal, et al.                Informational                     [Page 27]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+   [16]  Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
+         Control 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]  Waldbusser, S., "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.
+
+   [20]  Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder,
+         "Textual Conventions for Internet Network Addresses", RFC 2851,
+         June 2000.
+
+   [21]  Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720,
+         October 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
+         using SMIv2", RFC 2233, November 1997.
+
+   [24]  Flick, J. and J. Johnson, "Definition of Managed Objects for
+         the Ethernet-like Interface Types", RFC 2358, June 1998.
+
+   [25]  Case, J., "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]  Flick, J., "Definitions of Managed Objects for IEEE 802.12
+         Interfaces", 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.
+
+
+
+
+
+
+Phaal, et al.                Informational                     [Page 28]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+7. Authors' Addresses
+
+   Peter Phaal
+   InMon Corporation
+   1404 Irving Street
+   San Francisco, CA 94122
+
+   Phone: (415) 661-6343
+   EMail: peter_phaal@INMON.COM
+
+
+   Sonia Panchen
+   InMon Corporation
+   1404 Irving Street
+   San Francisco, CA 94122
+
+   Phone: (415) 661-6343
+   EMail: sonia_panchen@INMON.COM
+
+
+   Neil McKee
+   InMon Corporation
+   1404 Irving Street
+   San Francisco, CA 94122
+
+   Phone: (415) 661-6343
+   EMail: neil_mckee@INMON.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Phaal, et al.                Informational                     [Page 29]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+8.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Phaal, et al.                Informational                     [Page 30]
+
+RFC 3176               InMon Corporation's sFlow          September 2001
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Phaal, et al.                Informational                     [Page 31]
+