💾 Archived View for gmi.noulin.net › rfc › rfc3176.gmi captured on 2022-04-29 at 00:03:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-05)
-=-=-=-=-=-=-
Keywords: agent, data, MIB, management, information, base
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