< draft-phaal-sflow-montraffic-00.txt		draft-phaal-sflow-montraffic-01.txt >
			A new Request for Comments is now available in online RFC libraries.
	INTERNET-DRAFT Peter Phaal		RFC 3176
	Sonia Panchen
	Neil McKee
	InMon Corp.
	draft-phaal-sflow-montraffic-00.txt June 2001
	sFlow: Method for Monitoring Traffic in Switched and Routed Networks
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026 except that the right to
	produce derivative works is not granted.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html
	Abstract
	This memo defines the 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.
	Copyright Notice
	Copyright (C) The Internet Society (2001). All Rights Reserved.
	Table of Contents
	1. Overview ...................................................... 2
	2. Sampling Mechanisms ........................................... 2
	2.1 Sampling of Switched Flows ................................ 3
	2.1.1 Distributed Switching ............................... 3
	2.1.2 Random Number Generation ............................ 3
	2.2 Sampling of Network Interface Statistics .................. 4
	3. sFlow MIB ..................................................... 4
	3.1 The SNMP Management Framework ............................. 5
	3.2 Definitions ............................................... 5
	4. sFlow Datagram Format ......................................... 14
	5. Security Considerations ....................................... 23
	6. References .................................................... 24
	7. Author's Addresses ............................................ 25
	Intellectual Property Statement ............................... 26
	Full Copyright Statement ...................................... 26
	1. Overview
	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 networks.
	The design specifically addresses issues associated with:
	o Accurately monitoring network traffic at Gigabit speeds.
	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 standalone SPAN/Monitor port probe) and a
	central data collector, or sFlow Analyzer.
	The sFlow Agent uses sampling technology to capture traffic statis-
	tics from the device it is monitoring. Sample datagrams are used to
	immediately forward the sampled traffic statistics to an sFlow Ana-
	lyzer 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 sample 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 inter-
	face statistics.
	2.1 Sampling of Switched Flows
	A flow is defined as all the packets that are received on one inter-
	face, enter the Switching/Routing Module and are sent to another
	interface. In the case of a one-armed router, the source and destina-
	tion interface could be the same. The sampling mechanism must ensure
	that any packet involved in a flow has an equal chance of being sam-
	pled, irrespective of the flow it is belongs to.
	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 desti-
	nation 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 sam-
	pled.
	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 ran-
	dom integers used over time should be such that
	Total_Samples/Total_Packets = Rate
	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 sam-
	pling 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 possi-
	ble; a random number generator only capable of generating even num-
	bers, 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. The sFlow Analyzer assigns a max-
	imum polling interval 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 inte-
	grated system. Both types of samples are combined in sample data-
	grams. Since flow sampling will cause a steady stream of datagrams to
	be sent to the sFlow Analyzer, counter samples are taken opportunis-
	tically in order to fill these datagrams.
	The sFlow Agent keeps 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. Coun-
	ters 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 source's statistics are added to a sample datagram, the asso-
	ciated representation of the time the counter source was last sampled
	must be updated. 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.
	3. sFlow MIB
	The sFlow MIB defines the control interface to 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 compo-
	nents:
	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
	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
	FROM SNMPv2-SMI
	SnmpAdminString
	FROM SNMP-FRAMEWORK-MIB
	enterprises, IpAddress
	FROM RFC1155-SMI
	OwnerString
	FROM RMON-MIB
	InetAddressType, InetAddress
	FROM INET-ADDRESS-MIB
	MODULE-COMPLIANCE, OBJECT-GROUP
	FROM SNMPv2-CONF;
	inmon OBJECT IDENTIFIER ::= { enterprises 4300 }
	sFlowMIB MODULE-IDENTITY
	LAST-UPDATED "200105150000Z" -- May 15, 2001
	ORGANIZATION "InMon Corp."
	CONTACT-INFO
	"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 "20010501000Z" -- May 1, 2001
	DESCRIPTION
	"Version 1.1
	Adds sfDatagramVersion."
	::= { inmon 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.0', 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.0;InMon Corp.;2.1.1' indicates
	that this agent implements version '1.0' 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.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
	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, provided that all
	interfaces are sampled consistently
	(i.e. all interfaces are either output sampled or input
	sampled).
	- smonVlanDataSource.<V>
	A dataSource 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>
	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)."
	::= { 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
	sfTimeout 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
	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
	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.
	A manager can discover the maximum and minimum sampling rates
	by disabling sampling (by setting sFlowCollectorAddress to
	0.0.0.0) and then setting the sampling rate first to 1 and then
	to 2^32-1. By reading back the value after each setting, it
	will be able to obtain the minimum and maximum allowable values
	respectively."
	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
	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 INTEGER
	MAX-ACCESS read-write
	STATUS current
	DESCRIPTION
	"The destination port for sFlow datagrams."
	DEFVAL { 6343 }
	::= { sFlowEntry 10 }
	sFlowDatagramVersion OBJECT-TYPE
	SYNTAX INTEGER
	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.
	A manager can easily determine the highest supported value by
	setting sFlowDatagramVersion to a large value, a subsequent
	request for the value of sFlowDatagramVersion will yield the
	highest supported value."
	DEFVAL { 3 }
	::= { sFlowEntry 11 }
	--
	-- Compliance Statements
	--
	sFlowMIBConformance OBJECT IDENTIFIER ::= { sFlowMIB 2 }
	sFlowMIBGroups OBJECT IDENTIFIER ::= { sFlowMIBConformance 1 }
	sFlowMIBCompliances OBJECT IDENTIFIER ::= { sFlowMIBConformance 2 }
	sFlowCompliance MODULE-COMPLIANCE
	STATUS current
	DESCRIPTION
	"Compliance statements for the sFlow Agent."
	MODULE -- this module
	MANDATORY-GROUPS { sFlowAgentGroup }
	OBJECT sFlowAgentAddressType
	SYNTAX InetAddressType { ipv4(1) }
	DESCRIPTION
	"Agents need only support ipv4."
	OBJECT sFlowCollectorAddressType
	SYNTAX InetAddressType { ipv4(1) }
	"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
	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 much simpler for the sFlow
	Agent to encode and an sFlow Analyzer to decode.
	Samples are sent as UDP packets to the host and port specified in the
	SFLOW MIB.
	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 */
	/* 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 {
	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;
	}
	/* 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 communites<>; /* Communities associated with this route */
	unsigned int localpref; /* LocalPref associated with this route */
	}
	/* 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 */
	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 */
	}
	/* Counter types */
	/* Generic interface counters - see RFC 1573, 2233 */
	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 */
	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;
	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;
	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:
	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.*/
	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;
	}
	While the sample 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 interval 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.
	5. Security Considerations
	The sFlow MIB is used to configure the generation of sFlow samples.
	The security of SNMP, with access control lists, is usually consid-
	ered 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 pro-
	vided. The following arguments are required to configure sFlow sam-
	pling on an interface.
	-sFlowDataSource <source>
	-sFlowPacketSamplingRate <rate>
	-sFlowCounterSamplingInterval <interval>
	-sFlowMaximumDatagramSize <size>
	-sFlowCollectorAddress <address>
	-sFlowCollectorPort <port>
	6. References
	[1] RFC 1014 XDR: External Data Representation standard. Sun Microsys-
	tems. Jun-01-1987.
	[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.
	[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.
	7. Author's Address
	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		Title: InMon Corporation's sFlow: A Method for Monitoring
			Traffic in Switched and Routed Networks
			Author(s): P. Phaal, S. Panchen, N. McKee
			Status: Informational
			Date: September 2001
			Mailbox: peter_phaal@INMON.COM, sonia_panchen@INMON.COM,
			neil_mckee@INMON.COM
			Pages: 31
			Characters: 60171
			Updates/Obsoletes/See Also: None
	Intellectual Property Statement		I-D Tag: draft-phaal-sflow-montraffic-01.txt
	The IETF takes no position regarding the validity or scope of any		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3176.txt
	intellectual property or other rights that might be claimed to per-
	tain 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		This memo defines InMon Corporation's sFlow system. sFlow is a
	copyrights, patents or patent applications, or other proprietary		technology for monitoring traffic in data networks containing switches
	rights which may cover technology that may be required to practice		and routers. In particular, it defines the sampling mechanisms
	this standard. Please address the information to the IETF Executive		implemented in an sFlow Agent for monitoring traffic, the sFlow MIB
	Director.		for controlling the sFlow Agent, and the format of sample data used by
			the sFlow Agent when forwarding data to a central data collector.
	Full Copyright Statement		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 (C) The Internet Society (2001). All Rights Reserved.		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	This document and translations of it may be copied and furnished to		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	others, and derivative works that comment on or otherwise explain it		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	or assist in its implementation may be prepared, copied, published		help: ways_to_get_rfcs. For example:
	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 doc-
	ument 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 develop-
	ing 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		To: rfc-info@RFC-EDITOR.ORG
	revoked by the Internet Society or its successors or assigns.		Subject: getting rfcs
	This document and the information contained herein is provided on an		help: ways_to_get_rfcs
	"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 MER-
	CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	The IETF has been notified of intellectual property rights claimed in		Requests for special distribution should be addressed to either the
	regard to some or all of the specification contained in this docu-		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	ment. For more information consult the online list of claimed		specifically noted otherwise on the RFC itself, all RFCs are for
	rights.		unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 12 change blocks.
	1240 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/