draft-ietf-bmwg-dsmterm-13.txt		rfc4689.txt
	Network Working Group Scott Poretsky		Network Working Group S. Poretsky
	INTERNET-DRAFT Reef Point Systems		Request for Comments: 4689 Reef Point Systems
	Expires in: December 2006		Category: Informational J. Perser
	Jerry Perser		Veriwave
	Veriwave		S. Erramilli
			Telcordia
	Shobha Erramilli		S. Khurana
	Telcordia		Motorola
			October 2006
	Sumit Khurana
	Telcordia
	June 2006
	Terminology for Benchmarking Network-layer
	Traffic Control Mechanisms
	<draft-ietf-bmwg-dsmterm-13.txt>
	Intellectual Property Rights (IPR) statement:
	By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Status of this Memo
	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		Terminology for Benchmarking Network-layer Traffic Control Mechanisms
	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		Status of This Memo
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		This memo provides information for the Internet community. It does
	http://www.ietf.org/shadow.html.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document describes terminology for the benchmarking of
	devices that implement traffic control using packet classification
	based on defined criteria. The terminology is to be applied to
	measurements made on the data plane to evaluate IP traffic control
	mechanisms. Rules for packet classification can be based on any
	field in the IP header, such as DSCP, or field in the packet
	payload, such as port number.
	Network-layer Traffic Control Mechanisms		This document describes terminology for the benchmarking of devices
			that implement traffic control using packet classification based on
			defined criteria. The terminology is to be applied to measurements
			made on the data plane to evaluate IP traffic control mechanisms.
			Rules for packet classification can be based on any field in the IP
			header, such as the Differentiated Services Code Point (DSCP), or any
			field in the packet payload, such as port number.
	Table of Contents		Table of Contents
	1. Introduction .............................................. 3
	2. Existing definitions ...................................... 3
	3. Term definitions............................................4
	3.1 Configuration Terms
	3.1.1 Classification.........................................4
	3.1.2 Codepoint Set..........................................4
	3.1.3 Forwarding Congestion..................................5
	3.1.4 Congestion Management..................................6
	3.1.5 Flow...................................................7
	3.2 Measurement Terms
	3.2.1 Forwarding Capacity....................................7
	3.2.2 Conforming Packet......................................8
	3.2.3 Nonconforming Packet...................................9
	3.2.4 Forwarding Delay.......................................9
	3.2.5 Jitter................................................11
	3.2.6 Undifferentiated Response.............................11
	3.3 Sequence Tracking
	3.3.1 In-sequence Packet....................................12
	3.3.2 Out-of-order Packet...................................12
	3.3.3 Duplicate Packet......................................13
	3.3.4 Stream................................................14
	3.3.5 Test Sequence number .................................15
	3.4 Vectors...................................................15
	3.4.1 Intended Vector.......................................15
	3.4.2 Offered Vector........................................16
	3.4.3 Expected Vectors......................................16
	3.4.4 Output Vectors........................................23
	4. IANA Considerations........................................31
	5. Security Considerations....................................31
	6. Acknowledgments............................................31
	7. References.................................................32
	8. Author's Address...........................................33
	9. Full Copyright Statement...................................34
	1. Introduction		1. Introduction ....................................................2
			2. Existing Definitions ............................................3
			3. Term Definitions ................................................4
			3.1. Configuration Terms ........................................4
			3.1.1. Classification ......................................4
			3.1.2. Codepoint Set .......................................4
			3.1.3. Forwarding Congestion ...............................5
			3.1.4. Congestion Management ...............................6
			3.1.5. Flow ................................................7
			3.2. Measurement Terms ..........................................7
			3.2.1. Forwarding Capacity .................................7
			3.2.2. Conforming Packet ...................................8
			3.2.3. Nonconforming Packet ................................9
			3.2.4. Forwarding Delay ....................................9
			3.2.5. Jitter .............................................11
			3.2.6. Undifferentiated Response ..........................11
			3.3. Sequence Tracking .........................................12
			3.3.1. Test Sequence Number ...............................12
			3.3.2. Stream .............................................12
			3.3.3. In-Sequence Packet .................................13
			3.3.4. Out-of-Order Packet ................................14
			3.3.5. Duplicate Packet ...................................14
			3.4. Vectors ...................................................15
			3.4.1. Intended Vector ....................................15
			3.4.2. Offered Vector .....................................16
			3.4.3. Expected Vectors ...................................16
			3.4.4. Output Vectors .....................................23
			4. Security Considerations ........................................30
			5. Acknowledgements ...............................................30
			6. References .....................................................31
			6.1. Normative References ......................................31
			6.2. Informative References ....................................31
	New terminology is needed because most existing measurements		1. Introduction
	assume the absence of congestion and only a single per-hop-
	behavior. This document introduces several new terms that will
	allow measurements to be taken during periods of congestion.
	Another key difference from existing terminology is the definition		New terminology is needed because most existing measurements assume
	of measurements as observed on egress as well as ingress of a		the absence of congestion and only a single per-hop behavior. This
	device/system under test. Again, the existence of congestion		document introduces several new terms that will allow measurements to
	requires the addition of egress measurements as well as those		be taken during periods of congestion.
	taken on ingress; without observing traffic leaving a
	device/system it is not possible to say whether traffic-control
	mechanisms effectively dealt with congestion.
	Network-layer Traffic Control Mechanisms		Another key difference from existing terminology is the definition of
			measurements as observed on egress and ingress of a device/system
			under test. Again, the existence of congestion requires the addition
			of egress measurements, as well as of those taken on ingress; without
			observing traffic leaving a device/system, it is not possible to say
			whether traffic-control mechanisms effectively dealt with congestion.
	The principal measurements introduced in this document are vectors		The principal measurements introduced in this document are vectors
	for rate, delay, and jitter, all of which can be observed with or		for rate, delay, and jitter, all of which can be observed with or
	without congestion of the Device Under Test (DUT)/ System Under		without congestion of the Device Under Test (DUT)/System Under Test
	Test (SUT). This document describes only those terms relevant to		(SUT). This document describes only those terms relevant to
	measuring behavior of a DUT or SUT at the Egress during periods of		measuring behavior of a DUT or SUT at the egress during periods of
	congestion. End-to-end and service-level measurements are beyond		congestion. End-to-end and service-level measurements are beyond the
	the scope of this document.		scope of this document.
	2. Existing definitions		2. Existing Definitions
	RFC 1224 "Techniques for Managing Asynchronously Generated Alerts"
	[St91] is used for 'Time with fine enough units to distinguish
	between two events'
	RFC 1242 "Benchmarking Terminology for Network Interconnect		RFC 1224, "Techniques for Managing Asynchronously Generated Alerts"
	Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching		[St91], is used for 'Time with fine enough units to distinguish
	Devices" should be consulted before attempting to make use of this		between two events'.
	document.
	RFC 2474 "Definition of the Differentiated Services Field (DS		RFC 1242, "Benchmarking Terminology for Network Interconnect
	Field) in the IPv4 and IPv6 Headers" section 2, contains		Devices", and RFC 2285, "Benchmarking Terminology for LAN Switching
	discussions of a number of terms relevant to network-layer traffic		Devices", should be consulted before attempting to make use of this
	control mechanisms and should also be consulted.		document.
	For the sake of clarity and continuity this RFC adopts the		RFC 2474, "Definition of the Differentiated Services Field (DS Field)
	template for definitions set out in Section 2 of RFC 1242.		in the IPv4 and IPv6 Headers", section 2, contains discussions of a
	Definitions are indexed and grouped together in sections for ease		number of terms relevant to network-layer traffic control mechanisms
	of reference.		and should also be consulted.
			For the sake of clarity and continuity, this RFC adopts the template
			for definitions set out in Section 2 of RFC 1242. Definitions are
			indexed and grouped together in sections for ease of reference.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in BCP 14, RFC 2119		document are to be interpreted as described in BCP 14, RFC 2119
	[Br97]. RFC 2119 defines the use of these key words to help make the		[Br97]. RFC 2119 defines the use of these key words to help make the
	intent of standards track documents as clear as possible. While this		intent of standards track documents as clear as possible. While this
	document uses these keywords, this document is not a standards track		document uses these keywords, this document is not a standards track
	document.		document.
	2.1 Frequently Used Acronyms		2.1. Frequently Used Acronyms
	DA Destination Address
	DS DiffServ
	DSCP DiffServ Code Point
	DUT Device Under Test
	IP Internet Protocol
	PHB Per Hop Behavior
	SA Source Address
	SUT System Under Test
	Network-layer Traffic Control Mechanisms
	3. Term definitions		DA Destination Address
			DS DiffServ
			DSCP DiffServ Code Point
			DUT Device Under Test
			IP Internet Protocol
			PHB Per Hop Behavior
			SA Source Address
			SUT System Under Test
	3.1 Configuration Terms		3. Term Definitions
	3.1.1 Classification		3.1. Configuration Terms
	Definition:		3.1.1. Classification
	Selection of packets according to defined rules.
	Discussion:		Definition:
	Classification determines the per-hop behaviors and traffic		Selection of packets according to defined rules.
	conditioning functions such as shaping and dropping that
	are to be applied to the packet.
	Classification of packets can be made based on the DS field		Discussion:
	or IP Precedence in the packet header. Classification can		Classification determines the per-hop behaviors and traffic
	be based on other IP header fields such as IP Source		conditioning functions, such as shaping and dropping, that are to
	Address (SA), Destination Address (DA), and protocol, or		be applied to the packet.
	fields in the packet payload such as port number.
	Classification can also be based on ingress interface.
	It is possible to classify based on Multi-Field (MF)
	criteria such as IP source and destination addresses,
	protocol and port number.
	Measurement units: n/a		Classification of packets can be based on the DS field or IP
			Precedence in the packet header. Classification can be based on
			other IP header fields, such as IP Source Address (SA),
			Destination Address (DA), and protocol, or on fields in the packet
			payload, such as port number. Classification can also be based on
			ingress interface. It is possible to base classification on
			Multi-Field (MF) criteria such as IP source and destination
			addresses, protocol, and port number. For further discussion of
			packet classification and its network applications, see [Bl98].
	See Also: None		Measurement units:
			n/a
	3.1.2 Codepoint Set		See Also:
			None
	Definition:		3.1.2. Codepoint Set
	The set of all DS Code-points or IP precedence values used
	during the test duration.
	Discussion:		Definition:
	Describes all the code-point markings associated with packets		The set of all DS Code-points or IP precedence values used during
	that are input to the DUT/SUT. For each entry in the		the test duration.
	codepoint set, there are associated vectors describing the
	rate of traffic, delay, loss, or jitter containing that
	particular DSCP or IP precedence value.
	The treatment that a packet belonging to a particular code-		Discussion:
	point gets is subject to the DUT classifying packets to map		Describes all the code-point markings associated with packets that
	to the correct PHB. Moreover, the forwarding treatment in		are input to the DUT/SUT. For each entry in the codepoint set,
	general is also dependent on the complete set of offered		there are associated vectors describing the rate of traffic,
	vectors.		delay, loss, or jitter containing that particular DSCP or IP
			precedence value.
	Measurement Units: n/a		The treatment that a packet belonging to a particular code-point
			gets is subject to the DUT classifying packets to map to the
			correct PHB. Moreover, the forwarding treatment in general is
			also dependent on the complete set of offered vectors.
	See Also: None		Measurement Units:
	Network-layer Traffic Control Mechanisms		n/a
	3.1.3 Forwarding Congestion		See Also:
			None
	Definition:		3.1.3. Forwarding Congestion
	A condition in which one or more egress interfaces are
	offered more packets than are forwarded.
	Discussion:		Definition:
	This condition is a superset of the overload definition		A condition in which one or more egress interfaces are offered
	[Ma98]. Overload [Ma98] deals with overloading input and		more packets than are forwarded.
	output interfaces beyond the maximum transmission allowed by
	the medium. Forwarding congestion does not assume ingress
	interface overload as the only source of overload on output
	interfaces.
	Another difference between Forwarding Congestion and overload		Discussion:
	occurs when the SUT comprises multiple elements, in that		This condition is a superset of the overload definition [Ma98].
	Forwarding Congestion may occur at multiple points. Consider		Overload [Ma98] deals with overloading input and output interfaces
	a SUT comprising multiple edge devices exchanging traffic		beyond the maximum transmission allowed by the medium. Forwarding
	with a single core device. Depending on traffic patterns,		congestion does not assume ingress interface overload as the only
	the edge devices may induce Forwarding Congestion on multiple		source of overload on output interfaces.
	egress interfaces on the core device.
	Throughput [Br91] defines the lower boundary of Forwarding		Another difference between Forwarding Congestion and overload
	Congestion. Throughput is the maximum offered rate with no		occurs when the SUT comprises multiple elements, in that
	Forwarding Congestion. At offered rates above throughput,		Forwarding Congestion may occur at multiple points. Consider an
	the DUT/SUT is considered to be in a state of Forwarding		SUT comprising multiple edge devices exchanging traffic with a
	Congestion.		single core device. Depending on traffic patterns, the edge
			devices may induce Forwarding Congestion on multiple egress
			interfaces on the core device.
	Packet Loss, not increased Forwarding Delay, is the		Throughput [Br91] defines the lower boundary of Forwarding
	external observable metric used to indicate the condition		Congestion. Throughput is the maximum offered rate with no
	of Forwarding Congestion. Packet Loss is a deterministic		Forwarding Congestion. At offered rates above throughput, the
	indicator of Forwarding Congestion. The condition of		DUT/SUT is considered to be in a state of Forwarding Congestion.
	increased Forwarding Delay without Packet Loss is an
	indicator of Forwarding Congestion known as Incipient
	Congestion. Incipient Congestion is a non-deterministic
	indicator of Forwarding Congestion [Fl93]. As stated in
	[Ec98], RED [Br98] detects incipient congestion before the
	buffer overflows, but the current Internet environment is
	limited to packet loss as the mechanism for indicating
	congestion to the end-nodes. [Ra99] implies that it is
	impractical to build a black-box test to observe Incipient
	Congestion. [Ra99] instead introduces Explicit Congestion
	Notification (ECN) as a deterministic Black-Box method for
	observing Incipient Congestion. [Ra99] is an Experimental
	RFC with limited deployment, so ECN is not used for this
	particular methodology. For the purpose of "black-box"
	testing a DUT/SUT, this methodology uses Packet Loss as the
	indicator of Forwarding Congestion.
	Network-layer Traffic Control Mechanisms		Packet Loss, not increased Forwarding Delay, is the external
			observable metric used to indicate the condition of Forwarding
			Congestion. Packet Loss is a deterministic indicator of
			Forwarding Congestion. The condition of increased Forwarding
			Delay without Packet Loss is an indicator of Forwarding Congestion
			known as Incipient Congestion. Incipient Congestion is a non-
			deterministic indicator of Forwarding Congestion [Fl93]. As
			stated in [Ec98], RED [Br98] detects incipient congestion before
			the buffer overflows, but the current Internet environment is
			limited to packet loss as the mechanism for indicating congestion
			to the end-nodes. [Ra99] implies that it is impractical to build
			a black-box test to observe Incipient Congestion. [Ra99] instead
			introduces Explicit Congestion Notification (ECN) as a
			deterministic Black-Box method for observing Incipient Congestion.
			[Ra99] is an Experimental RFC with limited deployment, so ECN is
			not used for this particular methodology. For the purpose of
			"black-box" testing a DUT/SUT, this methodology uses Packet Loss
			as the indicator of Forwarding Congestion.
	Ingress observations alone are not sufficient to cover all		Ingress observations alone are not sufficient to cover all cases
	cases in which Forwarding Congestion may occur. A device		in which Forwarding Congestion may occur. A device with an
	with an infinite amount of memory could buffer an infinite		infinite amount of memory could buffer an infinite number of
	number of packets, and eventually forward all of them.		packets and eventually forward all of them. However, these
	However, these packets may or may not be forwarded during		packets may or may not be forwarded during the test duration.
	the test duration. Congestion Collapse [Na84] is defined		Congestion Collapse [Na84] is defined as the state in which
	as the state in which buffers are full and all arriving		buffers are full and all arriving packets MUST be dropped across
	packets MUST be dropped across the network. Even though		the network. Even though ingress interfaces accept all packets
	ingress interfaces accept all packets without loss,		without loss, Forwarding Congestion is present in this
	Forwarding Congestion is present in this hypothetical		hypothetical device.
	device.
	The definition presented here explicitly defines		The definition presented here explicitly defines Forwarding
	Forwarding Congestion as an event observable on egress		Congestion as an event observable on egress interfaces.
	interfaces. Regardless of internal architecture, any		Regardless of internal architecture, any device exhibiting Packet
	device exhibiting Packet Loss on one or more egress		Loss on one or more egress interfaces is experiencing Forwarding
	interfaces is experiencing Forwarding Congestion.		Congestion.
	Measurement units:		Measurement units:
	None		None
	See Also:		See Also:
	Gateway Congestion Control Survey [Ma91]		Gateway Congestion Control Survey [Ma91]
	3.1.4 Congestion Management		3.1.4. Congestion Management
	Definition:		Definition:
	An implementation of one or more per-hop-behaviors to avoid		An implementation of one or more per-hop behaviors to avoid or
	or minimize the condition of congestion.		minimize the condition of congestion.
	Discussion:		Discussion:
	Congestion management may seek either to control congestion		Congestion management may seek either to control congestion or
	or avoid it altogether through Classification.		avoid it altogether through Classification.
	Congestion avoidance mechanisms seek to prevent congestion		Congestion avoidance mechanisms seek to prevent congestion before
	before it actually occurs.		it actually occurs.
	Congestion control mechanisms give one or more flows (with a		Congestion control mechanisms give one or more flows (with a
	discrete IP Precedence or DSCP value) preferential treatment		discrete IP Precedence or DSCP value) preferential treatment over
	over other classes during periods of congestion.		other classes during periods of congestion.
	Measurement units:		Measurement units:
	n/a		n/a
	See Also:		See Also:
	Classification		Classification
	Network-layer Traffic Control Mechanisms
	3.1.5 Flow		3.1.5. Flow
	Definition:		Definition:
	A flow is a one or more of packets sharing a common intended		A flow is one or more packets sharing a common intended pair of
	pair of ingress and egress interfaces.		ingress and egress interfaces.
	Discussion:		Discussion:
	Packets are grouped by the ingress and egress interfaces they		Packets are grouped by the ingress and egress interfaces they use
	use on a given DUT/SUT.		on a given DUT/SUT.
	A flow can contain multiple source IP addresses and/or		A flow can contain multiple source IP addresses and/or destination
	destination IP addresses. All packets in a flow MUST enter		IP addresses. All packets in a flow MUST enter on the same
	on the same ingress interface and exit on the same egress		ingress interface and exit on the same egress interface and have
	interface, and have some common network layer content.		some common network layer content.
	Microflows [Ni98] are a subset of flows. As defined in		Microflows [Ni98] are a subset of flows. As defined in [Ni98],
	[Ni98], microflows require application-to-application		microflows require application-to-application measurement. In
	measurement. In contrast, flows use lower-layer		contrast, flows use lower-layer classification criteria. Since
	classification criteria. Since this document focuses on		this document focuses on network-layer classification criteria, it
	network-layer classification criteria, we concentrate here on		concentrates here on the use of network-layer identifiers in
	the use of network-layer identifiers in describing a flow.		describing a flow. Flow identifiers also may reside at the data-
	Flow identifiers also may reside at the data-link, transport,		link, transport, or application layers of the OSI model. However,
	or application layers of the OSI model. However, identifiers		identifiers other than those at the network layer are out of scope
	other than those at the network layer are out of scope for		for this document.
	this document.
	A flow may contain a single code point/IP precedence value or		A flow may contain a single code point/IP precedence value or may
	may contain multiple values destined for a single egress		contain multiple values destined for a single egress interface.
	interface. This is determined by the test methodology.		This is determined by the test methodology.
	Measurement units:		Measurement units:
	n/a		n/a
	See Also:		See Also:
	Microflow [Ni98]		Microflow [Ni98]
	Streams		Streams
	3.2 Measurement Terms		3.2. Measurement Terms
	3.2.1 Forwarding Capacity		3.2.1. Forwarding Capacity
	Definition:		Definition:
	The number of packets per second that a device can be		The number of packets per second that a device can be observed to
	observed to successfully transmit to the correct destination		transmit successfully to the correct egress interface in response
	interface in response to a specified offered load while the		to a specified offered load while the device drops none of the
	device drops none of the offered packets.		offered packets.
	Discussion:		Discussion:
	Forwarding Capacity measures the packet rate at the egress		Forwarding Capacity measures the packet rate at the egress
	interface(s) of the DUT/SUT. In contrast, throughput as		interface(s) of the DUT/SUT. In contrast, throughput (as defined
	defined in RFC 1242 measures the packet rate at the ingress		in RFC 1242) measures the packet rate at the ingress interface(s)
	interface(s) of the DUT/SUT.		of the DUT/SUT.
	Network-layer Traffic Control Mechanisms		Ingress-based measurements do not account for queuing of the
			DUT/SUT. Throughput rates can be higher than the Forwarding
			Capacity because of queueing. The difference is dependent upon
			test duration, packet rate, and queue size. Forwarding Capacity,
			as an egress measurement, does take queuing into account.
	Ingress-based measurements do not account for queuing of the		Understanding Forwarding Capacity is a necessary precursor to any
	DUT/SUT. Throughput rates can be higher than the Forwarding		measurement involving Traffic Control Mechanisms. The
	Capacity because of queueing. The difference is dependent		accompanying methodology document MUST take into consideration
	upon test duration, packet rate, and queue size. Forwarding		Forwarding Capacity when determining the expected forwarding
	Capacity, as an egress measurement, does take queuing into		vectors. When the sum of the expected forwarding vectors on an
	account.		interface exceeds the Forwarding Capacity, the Forwarding Capacity
			will govern the forwarding rate.
	Understanding Forwarding Capacity is a necessary precursor to		This measurement differs from forwarding rate at maximum offered
	any measurement involving Traffic Control Mechanisms. The		load (FRMOL) [Ma98] in that the Forwarding Capacity requires zero
	accompanying methodology document MUST take into		loss.
	consideration Forwarding Capacity when determining the
	expected forwarding vectors. When the sum of the expected
	forwarding vectors on an interface exceeds the Forwarding
	Capacity, the Forwarding Capacity will govern the forwarding
	rate.
	This measurement differs from forwarding rate at maximum		Measurement units:
	offered load (FRMOL) [Ma98] in that Forwarding Capacity		N-octet packets per second
	requires zero loss.
	Measurement units:		See Also:
	N-octet packets per second		Throughput [Br91]
			Forwarding Rate at Maximum Offered Load [Ma98]
	See Also:		3.2.2. Conforming Packet
	Throughput [Br91]
	Forwarding Rate at Maximum Offered Load [Ma98]
	3.2.2 Conforming Packet		Definition:
			Packets that lie within specific rate, delay, or jitter bounds.
	Definition:		Discussion:
	Packets which lie within specific rate, delay, or jitter		A DUT/SUT may be configured to allow a given traffic class to
	bounds.		consume a given amount of bandwidth, or to fall within predefined
			delay or jitter boundaries. All packets that lie within specified
			bounds are then said to be conforming, whereas those outside the
			bounds are nonconforming.
	Discussion:		Measurement units:
	A DUT/SUT may be configured to allow a given traffic class to		n/a
	consume a given amount of bandwidth, or to fall within
	predefined delay or jitter boundaries. All packets that lie
	within specified bounds are then said to be conforming,
	whereas those outside the bounds are nonconforming.
	Measurement units:		See Also:
	n/a		Expected Vector
			Forwarding Vector
			Offered Vector
			Nonconforming
	See Also:		3.2.3. Nonconforming Packet
	Expected Vector
	Forwarding Vector
	Offered Vector
	Nonconforming
	Network-layer Traffic Control Mechanisms
	3.2.3 Nonconforming Packet		Definition:
			Packets that do not lie within specific rate, delay, or jitter
			bounds.
	Definition:		Discussion:
	Packets that do not lie within specific rate, delay, or		A DUT/SUT may be configured to allow a given traffic class to
	jitter bounds.		consume a given amount of bandwidth, or to fall within predefined
			delay or jitter boundaries. All packets that do not lie within
			these bounds are then said to be nonconforming.
	Discussion:		Measurement units:
	A DUT/SUT may be configured to allow a given traffic class to		n/a
	consume a given amount of bandwidth, or to fall within
	predefined delay or jitter boundaries. All packets that do
	not lie within these bounds are then said to be
	nonconforming.
	Measurement units:		See Also:
	n/a		Expected Vector
			Forwarding Vector
			Offered Vector
			Conforming
	See Also:		3.2.4. Forwarding Delay
	Expected Vector
	Forwarding Vector
	Offered Vector
	Conforming
	3.2.4 Forwarding Delay		Definition:
			The time interval starting when the last bit of the input IP
			packet is offered to the input port of the DUT/SUT and ending when
			the last bit of the output IP packet is received from the output
			port of the DUT/SUT.
	Definition:		Discussion:
	The time interval starting when the last bit of the input IP		The delay time interval MUST be externally observed. The delay
	packet is offered to the input port of the DUT/SUT and ending		measurement MUST NOT include delays added by test bed components
	when the last bit of the output IP packet is received from		other than the DUT/SUT, such as propagation time introduced by
	the output port of the DUT/SUT.		cabling or non-zero delay added by the test instrument.
			Forwarding Delay differs from latency [Br91] and one-way delay
			[Al99] in several key regards:
	Discussion:		1. Latency [Br91] assumes knowledge of whether the DUT/SUT uses
	The delay time interval MUST be externally observed. The		"store and forward" or "bit forwarding" technology. Forwarding
	delay measurement MUST NOT include delays added by test bed		Delay is the same metric, measured the same way, regardless of
	components other than the DUT/SUT, such as propagation time		the architecture of the DUT/SUT.
	introduced by cabling or non-zero delay added by the test
	instrument. Forwarding Delay differs from latency [Br91]
	and one-way delay [Al99] in several key regards:
	1. Latency [Br91] assumes knowledge of whether the DUT/SUT		2. Forwarding Delay is a last-in, last-out (LILO) measurement,
	uses "store and forward" or "bit forwarding" technology.		unlike the last-in, first-out method [Br91] or the first-in,
	Forwarding Delay is the same metric, measured the same way,		last-out method [Al99].
	regardless of the architecture of the DUT/SUT.
	2. Forwarding Delay is a last-in, last-out (LILO)		The LILO method most closely simulates the way a network-layer
	measurement, unlike the last-in, first-out method [Br91] or		device actually processes an IP datagram. IP datagrams are not
	the first-in, last-out method [Al99].		passed up and down the stack unless they are complete, and
			processing begins only once the last bit of the IP datagram has
			been received.
	The LILO method most closely simulates the way a network-		Further, the LILO method has an additive property, where the
	layer device actually processes an IP datagram. IP datagrams		sum of the parts MUST equal the whole. This is a key
	are not passed up and down the stack unless they are		difference from [Br91] and [Al99]. For example, the delay
	complete, and processing begins only once the last bit of the		added by two DUTs MUST equal the sum of the delay of the DUTs.
	IP datagram has been received.		This may or may not be the case with [Br91] and [Al99].
	Network-layer Traffic Control Mechanisms		3. Forwarding Delay measures the IP datagram only, unlike [Br91],
			which also includes link-layer overhead.
	Further, the LILO method has an additive property, where the		A metric focused exclusively on the Internet protocol relieves
	sum of the parts MUST equal the whole. This is a key		the tester from specifying the start/end for every link-layer
	difference from [Br91] and [Al99]. For example, the delay		protocol that IP runs on. This avoids the need to determine
	added by two DUTs MUST equal the sum of the delay of the		whether the start/stop delimiters are included. It also allows
	DUTs. This may or may not be the case with [Br91] and		the use of heterogeneous link-layer protocols in a test.
	[Al99].
	3. Forwarding Delay measures the IP datagram only, unlike		4. Forwarding Delay can be measured at any offered load, whereas
	[Br91], which also includes link layer overhead.		the latency methodology [Br99] recommends measurement at, and
			only at, the throughput level. Comparing the Forwarding Delay
			below the throughput to Forwarding Delay above the Forwarding
			Capacity will give insight to the traffic control mechanisms.
	A metric focused exclusively on the Internet protocol		For example, non-congested delay may be measured with an
	relieves the tester from specifying the start/end for every		offered load that does not exceed the Forwarding Capacity,
	link layer protocol that IP runs on. This avoids the need to		while congested delay may involve an offered load that exceeds
	determine whether the start/stop delimiters are included. It		the Forwarding Capacity.
	also allows the use of heterogeneous link layer protocols in
	a test.
	4. Forwarding Delay can be measured at any offered load,		Note: Forwarding Delay SHOULD NOT be used as an absolute
	whereas the latency methodology [Br99] recommends measurement		indicator of DUT/SUT Forwarding Congestion. While Forwarding
	at, and only at, the throughput level. Comparing the		Delay may rise when offered load nears or exceeds the
	Forwarding Delay below the throughput to Forwarding Delay		Forwarding Capacity, there is no universal point at which
	above the Forwarding Capacity will give insight to the		Forwarding Delay can be said to indicate the presence or
	traffic control mechanisms.		absence of Forwarding Congestion.
	For example, non-congested delay may be measured with an		Measurement units:
	offered load that does not exceed the Forwarding Capacity,		milliseconds
	while congested delay may involve an offered load that
	exceeds Forwarding Capacity.
	Note: Forwarding Delay SHOULD NOT be used as an absolute		See Also:
	indicator of DUT/SUT Forwarding Congestion. While Forwarding		Latency [Br91]
	Delay may rise when offered load nears or exceeds Forwarding		Latency [Al99]
	Capacity, there is no universal point at which Forwarding		One-way Delay [Br99]
	Delay can be said to indicate the presence or absence of
	Forwarding Congestion.
	Measurement units:		3.2.5. Jitter
	milliseconds
	See Also:		Definition:
	Latency [Br91]		The absolute value of the difference between the Forwarding Delay
	Latency [Al99]		of two consecutive received packets belonging to the same stream.
	One-way Delay [Br99]
	Network-layer Traffic Control Mechanisms
	3.2.5 Jitter		Discussion:
			The Forwarding Delay fluctuation between two consecutive received
			packets in a stream is reported as the jitter. Jitter can be
			expressed as |D(i) - D(i-1)|, where D equals the Forwarding Delay
			and i is the order the packets were received.
	Definition:		Under loss, jitter can be measured between non-consecutive test
	The absolute value of the difference between the arrival		sequence numbers. When IP Traffic Control Mechanisms are dropping
	delay of two consecutive received packets belonging to the		packets, fluctuating Forwarding Delay may be observed. Jitter
	same stream.		MUST be able to benchmark the delay variation independently of
			packet loss.
	Discussion:		Jitter is related to the IPDV [De02] (IP Delay Variation) by
	The Forwarding Delay fluctuation between two consecutive		taking the absolute value of the ipdv. The two metrics will
	received packets in a stream is reported as the Jitter.		produce different mean values. Mean Jitter will produce a
	Jitter can be expressed as |D(i) - D(i-1)| where D equals		positive value, where the mean ipdv is typically zero. Also, IPDV
	the Forwarding Delay and i is the order the packets were		is undefined when one packet from a pair is lost.
	received.
	Under loss, jitter can be measured between non-consecutive		Measurement units:
	test sequence numbers. When IP Traffic Control Mechanisms		milliseconds
	are dropping packets, fluctuating Forwarding Delay may be
	observed. Jitter MUST be able to benchmark the delay
	variation independent of packet loss.
	Jitter is related to the IPDV [De02] (IP Delay Variation) by		See Also:
	taking the absolute value of the ipdv. The two metrics will		Forwarding Delay
	produce different mean values. Mean Jitter will produce a		Jitter variation [Ja99]
	positive value, where the mean ipdv is typically zero. Also,		ipdv [De02]
	IPDV is undefined when one packet from a pair is lost.		interarrival jitter [Sc96]
	Measurement units:		3.2.6. Undifferentiated Response
	milliseconds
	See Also:		Definition:
	Forwarding Delay		The vector(s) obtained when mechanisms used to support diff-serv
	Jitter variation [Ja99]		or IP precedence are disabled.
	ipdv [De02]
	interarrival jitter [Sc96]
	3.2.6 Undifferentiated Response		Discussion:
			Enabling diff-serv or IP precedence mechanisms may impose
			additional processing overhead for packets. This overhead may
			degrade performance even when traffic belonging to only one class,
			the best-effort class, is offered to the device. Measurements
			with "undifferentiated response" SHOULD be made to establish a
			baseline.
	Definition:		The vector(s) obtained with DSCP or IP precedence enabled can be
	The vector(s) obtained when mechanisms used to support		compared to the undifferentiated response to determine the effect
	diff-serv or IP precedence are disabled.		of differentiating traffic.
	Discussion:		Measurement units:
	Enabling diff-serv or IP precedence mechanisms may impose		n/a
	additional processing overhead for packets. This overhead
	may degrade performance even when traffic belonging to only
	one class, the best-effort class, is offered to the device.
	Measurements with "undifferentiated response" SHOULD be made
	to establish a baseline.
	Network-layer Traffic Control Mechanisms		3.3. Sequence Tracking
	The vector(s) obtained with DSCP or IP precedence enabled can		3.3.1. Test Sequence Number
	be compared to the undifferentiated response to determine the
	effect of differentiating traffic.
	Measurement units:		Definition:
	n/a		A field in the IP payload portion of the packet that is used to
			verify the order of the packets on the egress of the DUT/SUT.
	3.3 Sequence Tracking		Discussion:
			The traffic generator sets the test sequence number value. Upon
			receipt of the packet, the traffic receiver checks the value.
			The traffic generator changes the value on each packet transmitted
			based on an algorithm agreed to by the traffic receiver.
	3.3.1 In-sequence Packet		The traffic receiver keeps track of the sequence numbers on a
			per-stream basis. In addition to the number of received packets,
			the traffic receiver may also report the number of in-sequence
			packets, the number of out-of-sequence packets, the number of
			duplicate packets, and the number of reordered packets. The
			RECOMMENDED algorithm to change the sequence number on sequential
			packets is an incrementing value.
	Definition:		Measurement units:
	A received packet with the expected Test Sequence number.		n/a
	Discussion:		See Also:
	In-sequence is done on a stream level. As packets are		Stream
	received on a stream, each packets Test Sequence number is
	compared with the previous packet. Only packets that match
	the expected Test Sequence number are considered in-sequence.
	Packets that do not match the expected Test Sequence number		3.3.2. Stream
	are counted as "not in-sequence" or out-of-sequence. Every
	packet that is received is either in-sequence or out-of-
	sequence. Subtracting the in-sequence from the received
	packets (for that stream), the tester can derive the
	out-of-sequence count.
	Two types of events will prevent the in-sequence from		Definition:
	incrementing: packet loss and reordered packets.		A group of packets tracked as a single entity by the traffic
			receiver. A stream MUST share common content, such as type (IP,
			UDP), IP SA/DA, packet size, or payload.
	Measurement units:		Discussion:
	Packet count		Streams are tracked by test sequence number or "unique signature
			field" [Ma00]. Streams define how individual packet statistics
			are grouped together to form an intelligible summary.
	See Also:		Common stream groupings would be by egress interface, destination
	Stream		address, source address, DSCP, or IP precedence. A stream using
	Test Sequence number		test sequence numbers can track the ordering of packets as they
			traverse the DUT/SUT.
	3.3.2 Out-of-order Packet		Streams are not restricted to a pair of source and destination
			interfaces as long as all packets are tracked as a single entity.
			A multicast stream can be forwarded to multiple destination
			interfaces.
	Definition:		Measurement units:
	A received packet with a sequence number less than		n/a
	the sequence number of a previously arriving packet.
	Network-layer Traffic Control Mechanisms		See Also:
			Flow
			Microflow [Ni98]
			Test sequence number
	Discussion:		3.3.3. In-Sequence Packet
	As a stream of packets enters a DUT/SUT, they include a
	Stream Test Sequence number indicating the order the packets
	were sent to the DUT/SUT. On exiting the DUT/SUT, these
	packets may arrive in a different order. Each packet that
	was re-ordered is counted as an Out-of-order Packet.
	Certain streaming protocol (such as TCP) require the packets		Definition:
	to be in a certain order. Packets outside this are dropped		A received packet with the expected Test Sequence number.
	by the streaming protocols even though there were properly
	received by the IP layer. The type of reordering tolerated
	by a streaming protocol varies from protocol to protocol, and
	also by implementation.
	Packet loss does not affect the Out-of-order Packet count.		Discussion:
	Only packets that were not received in the order that they		In-sequence is done on a stream level. As packets are received on
	were transmitted.		a stream, each packet's Test Sequence number is compared with the
			previous packet. Only packets that match the expected Test
			Sequence number are considered in-sequence.
	Measurement units:		Packets that do not match the expected Test Sequence number are
	packets		counted as "not in-sequence" or out-of-sequence. Every packet
			that is received is either in-sequence or out-of-sequence.
			Subtracting the in-sequence from the received packets (for that
			stream), the tester can derive the out-of-sequence count.
	See Also:		Two types of events will prevent the in-sequence from
	Stream		incrementing: packet loss and reordered packets.
	Test Sequence number
	Packet Reordering Metric for IPPM [Mo03]
	3.3.3 Duplicate Packet		Measurement units:
			Packet count
	Definition:		See Also:
	A received packet with a Test Sequence number matching a		Stream
	previously received packet.		Test Sequence number
	Discussion:		3.3.4. Out-of-Order Packet
	A Duplicate Packet is a packet that the DUT/SUT has
	successfully transmitted out an egress interface more than
	once. The egress interface has previously forwarded this
	packet.
	A Duplicate Packet SHOULD be a bit for bit copy of an already		Definition:
	transmitted packet (including Test Sequence number). If the		A received packet with a sequence number less than the sequence
	Duplicate Packet traversed different paths through the		number of any previously arriving packet.
	DUT/SUT, some fields (such as TTL or checksum) may have
	changed.
	A multicast packet is not a Duplicate Packet by definition.		Discussion:
	For a given IP multicast group, a DUT/SUT SHOULD forward a		As a stream of packets enters a DUT/SUT, they include a Stream
	packet once on a given egress interface provided the path to		Test Sequence number indicating the order the packets were sent to
	one or more multicast receivers is through that interface.		the DUT/SUT. On exiting the DUT/SUT, these packets may arrive in
	Several egress interfaces will transmit the same packet, but		a different order. Each packet that was reordered is counted as
	only once per interface.		an Out-of-Order Packet.
	Network-layer Traffic Control Mechanisms		Certain streaming protocols (such as TCP) require the packets to
			be in a certain order. Packets outside this are dropped by the
			streaming protocols even though they were properly received by the
			IP layer. The type of reordering tolerated by a streaming
			protocol varies from protocol to protocol, and also by
			implementation.
	To detect a Duplicate Packet, each offered packet to the		Packet loss does not affect the Out-of-Order Packet count. The
	DUT/SUT MUST contain a unique packet-by-packet identifier.		Out-of-Order Packet count is impacted only by packets that were
			not received in the order that they were transmitted.
	Measurement units:		Measurement units:
	Packet count		packets
	See Also:		See Also:
	Stream		Stream
	Test Sequence number		Test Sequence number
			Packet Reordering Metric for IPPM [Mo03]
	3.3.4 Stream		3.3.5. Duplicate Packet
	Definition:		Definition:
	A group of packets tracked as a single entity by the traffic		A received packet with a Test Sequence number matching a
	receiver. A stream MUST share common content such as type		previously received packet.
	(IP, UDP), IP SA/DA, packet size, or payload.
	Discussion:		Discussion:
	Streams are tracked by test sequence number or "unique		A Duplicate Packet is a packet that the DUT/SUT has successfully
	signature field" [Ma00]. Streams define how individual		transmitted out an egress interface more than once. The egress
	packets statistic are grouped together to form an		interface has previously forwarded this packet.
	intelligible summary.
	Common stream groupings would be by egress interface,		A Duplicate Packet SHOULD be a bit-for-bit copy of an already
	destination address, source address, DSCP, or IP precedence.		transmitted packet (including Test Sequence number). If the
	A stream using test sequence numbers can track the ordering		Duplicate Packet traversed different paths through the DUT/SUT,
	of packets as they traverse the DUT/SUT.		some fields (such as TTL or checksum) may have changed.
	Streams are not restricted to a pair of source and		A multicast packet is not a Duplicate Packet by definition. For a
	destination interfaces as long as all packets are tracked as		given IP multicast group, a DUT/SUT SHOULD forward a packet once
	a single entity. A multicast stream can be forwarded to		on a given egress interface provided the path to one or more
	multiple destination interfaces.		multicast receivers is through that interface. Several egress
			interfaces will transmit the same packet, but only once per
			interface.
	Measurement units:		To detect a Duplicate Packet, each packet offered to the DUT/SUT
	n/a		MUST contain a unique packet-by-packet identifier.
	See Also:		Measurement units:
	Flow		Packet count
	Microflow [Ni98]
	Test sequence number
	Network-layer Traffic Control Mechanisms
	3.3.5 Test Sequence Number		See Also:
	Definition:		Stream
	A field in the IP payload portion of the packet that is used		Test Sequence number
	to verify the order of the packets on the egress of the
	DUT/SUT.
	Discussion:		3.4. Vectors
	The traffic generator sets the test sequence number value and
	the traffic receiver checks the value upon receipt of the
	packet. The traffic generator changes the value on each
	packet transmitted based on an algorithm agreed to by the
	traffic receiver.
	The traffic receiver keeps track of the sequence numbers on a		A vector is a group of packets all matching a specific
	per stream basis. In addition to number of received packets,		classification criteria, such as DSCP. Vectors are
	the traffic receiver may also report the number of		identified by the classification criteria and benchmarking
	in-sequence packets, number of out-of-sequence packets,		metrics, such as a Forwarding Capacity, Forwarding Delay,
	number of duplicate packets, and number of reordered packets.		or Jitter.
	The RECOMMENDED algorithm to use to change the sequence
	number on sequential packets is an incrementing value.
	Measurement units:		3.4.1. Intended Vector
	n/a
	See Also:		Definition:
	Stream		A description of the configuration on an external source
			for the attempted rate of a stream transmitted to a DUT/SUT
			matching specific classification rules.
	3.4 Vectors		Discussion:
	A vector is a group of packets all matching a specific		The Intended Vector of a stream influences the benchmark
	classification criteria, such as DSCP. Vectors are		measurements. The Intended Vector is described by the
	identified by the classification criteria and benchmarking		classification criteria and attempted rate.
	metrics such as a Forwarding Capacity, Forwarding Delay,
	or Jitter.
	3.4.1 Intended Vector		Measurement Units:
	Definition:		N-bytes packets per second
	A description of the configuration on an external source
	for the attempted rate of a stream transmitted to a DUT/SUT
	matching specific classification rules.
	Discussion:		See Also:
	The Intended Vector of a stream influences the benchmark		Stream
	measurements. The Intended Vector is described by the		Offered Vector
	classification criteria and attempted rate.		Forwarding Vector
	Measurement Units:		3.4.2. Offered Vector
	N-bytes packets per second
	See Also:		Definition:
	Stream		A description for the attempted rate of a stream offered to
	Offered Vector		a DUT/SUT matching specific classification rules.
	Forwarding Vector
	Network-layer Traffic Control Mechanisms
	3.4.2 Offered Vector		Discussion:
			The Offered Vector of a stream influences the benchmark
			measurements. The Offered Vector is described by the
			classification criteria and offered rate.
	Definition:		Measurement Units:
	A description for the attempted rate of a stream offered to		N-bytes packets per second
	a DUT/SUT matching specific classification rules.
	Discussion:		See Also:
	The Offered Vector of a stream influences the benchmark		Stream
	measurements. The Offered Vector is described by the		Intended Vector
	classification criteria and offered rate.		Forwarding Vector
	Measurement Units:		3.4.3. Expected Vectors
	N-bytes packets per second
	See Also:		3.4.3.1. Expected Forwarding Vector
	Stream
	Intended Vector
	Forwarding Vector
	3.4.3 Expected Vectors		Definition:
	3.4.3.1 Expected Forwarding Vector		A description of the expected output rate of packets matching a
			specific classification, such as DSCP.
	Definition:		Discussion:
	A description of the expected output rate of packets		The value of the Expected Forwarding Vector is dependent on the
	matching a specific classification, such as DSCP.		set of offered vectors and Classification configuration on the
			DUT/SUT. The DUT is configured in a certain way so that
			classification occurs when a traffic mix consisting of multiple
			streams is applied.
	Discussion:		This term captures the expected forwarding behavior from the DUT
	The value of the Expected Minimum Delay Vector is dependent		receiving multiple Offered Vectors. The actual algorithm or
	on the set of offered vectors and Classification		mechanism the DUT uses to achieve service differentiation is
	configuration on the DUT/SUT. The DUT is configured in a		implementation specific and is not important when describing the
	certain way in order that classification occurs when a		Expected Forwarding Vector.
	traffic mix consisting of multiple streams is applied.
	This term captures the expected forwarding behavior from the		Measurement units:
	DUT receiving multiple Offered Vectors. The actual algorithm		N-octet packets per second
	or mechanism the DUT uses to achieve service differentiation
	is implementation specific and not important when describing
	the Expected Forwarding Vector.
	Measurement units:		See Also:
	N-octet packets per second		Classification
			Stream
			Intended Vector
			Offered Vector
	See Also:		3.4.3.2. Expected Loss Vector
	Classification
	Stream
	Intended Vector
	Offered Vector
	Network-layer Traffic Control Mechanisms
	3.4.3.2 Expected Loss Vector		Definition:
			A description of the percentage of packets having a specific
			classification that should not be forwarded.
	Definition:		Discussion:
	A description of the percentage of packets, having a		The value of the Expected Loss Vector is dependent on the set of
	specific classification that SHOULD NOT be forwarded.		offered vectors and Classification configuration on the DUT/SUT.
			The DUT is configured in a certain way so that classification
			occurs when a traffic mix consisting of multiple streams is
			applied.
	Discussion:		This term captures the expected forwarding behavior from the DUT
	The value of the Expected Minimum Delay Vector is dependent		receiving multiple Offered Vectors. The actual algorithm or
	on the set of offered vectors and Classification		mechanism the DUT uses to achieve service differentiation is
	configuration on the DUT/SUT. The DUT is configured in a		implementation specific and is not important when describing the
	certain way in order that classification occurs when a		Expected Loss Vector.
	traffic mix consisting of multiple streams is applied.
	This term captures the expected forwarding behavior from the		Measurement Units:
	DUT receiving multiple Offered Vectors. The actual algorithm		Percentage of intended packets expected to be dropped.
	or mechanism the DUT uses to achieve service differentiation
	is implementation specific and not important when describing
	the Expected Loss Vector.
	Measurement Units:		See Also:
	Percentage of intended packets that is expected to be		Classification
	dropped.		Stream
			Intended Vector
			Offered Vector
			One-way Packet Loss Metric [Ka99]
	See Also:		3.4.3.3. Expected Sequence Vector
	Classification
	Stream
	Intended Vector
	Offered Vector
	One-way Packet Loss Metric [Ka99]
	3.4.3.3 Expected Sequence Vector		Definition:
			A description of the expected in-sequence packets matching a
			specific classification, such as DSCP.
	Definition:		Discussion:
	A description of the expected in-sequence packets matching		The value of the Expected Sequence Vector is dependent on the set
	a specific classification, such as DSCP.		of offered vectors and Classification configuration on the
			DUT/SUT. The DUT is configured in a certain way so that
			classification occurs when a traffic mix consisting of multiple
			streams is applied.
	Discussion:		This term captures the expected forwarding behavior from the DUT
	The value of the Expected Minimum Delay Vector is dependent		receiving multiple Offered Vectors. The actual algorithm or
	on the set of offered vectors and Classification		mechanism the DUT uses to achieve service differentiation is
	configuration on the DUT/SUT. The DUT is configured in a		implementation specific and is not important when describing the
	certain way in order that classification occurs when a		Expected Sequence Vector.
	traffic mix consisting of multiple streams is applied.
	This term captures the expected forwarding behavior from the		Measurement Units:
	DUT receiving multiple Offered Vectors. The actual algorithm		N-octet packets per second
	or mechanism the DUT uses to achieve service differentiation
	is implementation specific and not important when describing
	the Expected Sequence Vector.
	Network-layer Traffic Control Mechanisms		See Also:
			Classification
			Stream
			In-Sequence Packet
			Intended Vector
			Offered Vector
	Measurement Units:		3.4.3.4. Expected Delay Vector
	N-octet packets per second
	See Also:		Definition:
	Classification		A description of the expected instantaneous Forwarding Delay for
	Stream		packets matching a specific classification, such as DSCP.
	In-Sequence Packet
	Intended Vector
	Offered Vector
	3.4.3.4 Expected Delay Vector		Discussion:
			The value of the Expected Delay Vector is dependent on the set of
			offered vectors and Classification configuration on the DUT/SUT.
			The DUT is configured in a certain way so that classification
			occurs when a traffic mix consisting of multiple streams is
			applied.
	Definition:		This term captures the expected forwarding behavior from the DUT
	A description of the expected instantaneous Forwarding		receiving multiple Offered Vectors. The actual algorithm or
	Delay for packets matching a specific classification, such		mechanism the DUT uses to achieve service differentiation is
	as DSCP.		implementation specific and is not important when describing the
			Expected Delay Vector.
	Discussion:		Measurement units:
	The value of the Expected Minimum Delay Vector is dependent		milliseconds
	on the set of offered vectors and Classification
	configuration on the DUT/SUT. The DUT is configured in a
	certain way in order that classification occurs when a
	traffic mix consisting of multiple streams is applied.
	This term captures the expected forwarding behavior from the		See Also:
	DUT receiving multiple Offered Vectors. The actual algorithm		Classification
	or mechanism the DUT uses to achieve service differentiation		Stream
	is implementation specific and not important when describing		Forwarding Delay
	the Expected Delay Vector.		Intended Vector
			Offered Vector
	Measurement units:		3.4.3.5. Expected Average Delay Vector
	milliseconds
	See Also:		Definition:
	Classification		A description of the expected average Forwarding Delay for packets
	Stream		matching a specific classification, such as DSCP.
	Forwarding Delay
	Intended Vector
	Offered Vector
	3.4.3.5 Expected Average Delay Vector		Discussion:
			The value of the Expected Average Delay Vector is dependent on the
			set of offered vectors and Classification configuration on the
			DUT/SUT. The DUT is configured in a certain way so that
			classification occurs when a traffic mix consisting of multiple
			streams is applied.
	Definition:		This term captures the expected forwarding behavior from the DUT
	A description of the expected average Forwarding Delay		receiving multiple Offered Vectors. The actual algorithm or
	for packets matching a specific classification, such as		mechanism the DUT uses to achieve service differentiation is
	DSCP.		implementation specific and is not important when describing the
			Expected Average Delay Vector.
	Network-layer Traffic Control Mechanisms		Measurement units:
			milliseconds
	Discussion:		See Also:
	The value of the Expected Minimum Delay Vector is dependent		Classification
	on the set of offered vectors and Classification		Stream
	configuration on the DUT/SUT. The DUT is configured in a		Forwarding Delay
	certain way in order that classification occurs when a		Intended Vector
	traffic mix consisting of multiple streams is applied.		Offered Vector
			Expected Delay Vector
	This term captures the expected forwarding behavior from the		3.4.3.6. Expected Maximum Delay Vector
	DUT receiving multiple Offered Vectors. The actual algorithm
	or mechanism the DUT uses to achieve service differentiation
	is implementation specific and not important when describing
	the Expected Average Delay Vector.
	Measurement units:		Definition:
	milliseconds		A description of the expected maximum Forwarding Delay for packets
			matching a specific classification, such as DSCP.
	See Also:		Discussion:
	Classification		The value of the Expected Maximum Delay Vector is dependent on the
	Stream		set of offered vectors and Classification configuration on the
	Forwarding Delay		DUT/SUT. The DUT is configured in a certain way so that
	Intended Vector		classification occurs when a traffic mix consisting of multiple
	Offered Vector		streams is applied.
	Expected Delay Vector
	3.4.3.6 Expected Maximum Delay Vector		This term captures the expected forwarding behavior from the DUT
			receiving multiple Offered Vectors. The actual algorithm or
			mechanism the DUT uses to achieve service differentiation is
			implementation specific and is not important when describing the
			Expected Maximum Delay Vector.
	Definition:		Measurement units:
	A description of the expected maximum Forwarding Delay		milliseconds
	for packets matching a specific classification, such as
	DSCP.
	Discussion:		See Also:
	The value of the Expected Minimum Delay Vector is dependent		Classification
	on the set of offered vectors and Classification		Stream
	configuration on the DUT/SUT. The DUT is configured in a		Forwarding Delay
	certain way in order that classification occurs when a		Intended Vector
	traffic mix consisting of multiple streams is applied.		Offered Vector
			Expected Delay Vector
	This term captures the expected forwarding behavior from the		3.4.3.7. Expected Minimum Delay Vector
	DUT receiving multiple Offered Vectors. The actual algorithm
	or mechanism the DUT uses to achieve service differentiation
	is implementation specific and not important when describing
	the Expected Maximum Delay Vector.
	Measurement units:		Definition:
	milliseconds		A description of the expected minimum Forwarding Delay for packets
	Network-layer Traffic Control Mechanisms		matching a specific classification, such as DSCP.
	See Also:		Discussion:
	Classification		The value of the Expected Minimum Delay Vector is dependent on the
	Stream		set of offered vectors and Classification configuration on the
	Forwarding Delay		DUT/SUT. The DUT is configured in a certain way so that
	Intended Vector		classification occurs when a traffic mix consisting of multiple
	Offered Vector		streams is applied.
	Expected Delay Vector
	3.4.3.7 Expected Minimum Delay Vector		This term captures the expected forwarding behavior from the DUT
			receiving multiple Offered Vectors. The actual algorithm or
			mechanism the DUT uses to achieve service differentiation is
			implementation specific and is not important when describing the
			Expected Minimum Delay Vector.
	Definition:		Measurement units:
	A description of the expected minimum Forwarding Delay		milliseconds
	for packets matching a specific classification, such as
	DSCP.
	Discussion:		See Also:
	The value of the Expected Minimum Delay Vector is dependent		Classification
	on the set of offered vectors and Classification		Stream
	configuration on the DUT/SUT. The DUT is configured in a		Forwarding Delay
	certain way in order that classification occurs when a		Intended Vector
	traffic mix consisting of multiple streams is applied.		Offered Vector
			Expected Delay Vector
	This term captures the expected forwarding behavior from the		3.4.3.8. Expected Instantaneous Jitter Vector
	DUT receiving multiple Offered Vectors. The actual algorithm
	or mechanism the DUT uses to achieve service differentiation
	is implementation specific and not important when describing
	the Expected Minimum Delay Vector.
	Measurement units:		Definition:
	milliseconds		A description of the expected Instantaneous Jitter between two
			consecutive packets arrival times matching a specific
			classification, such as DSCP.
	See Also:		Discussion:
	Classification		Instantaneous Jitter is the absolute value of the difference
	Stream		between the Forwarding Delay measurement of two packets belonging
	Forwarding Delay		to the same stream.
	Intended Vector
	Offered Vector
	Expected Delay Vector
	3.4.3.8 Expected Instantaneous Jitter Vector		The Forwarding Delay fluctuation between two consecutive packets
			in a stream is reported as the "Instantaneous Jitter".
			Instantaneous Jitter can be expressed as |D(i) - D(i-1)|, where D
			equals the Forwarding Delay and i is the test sequence number.
			Packets lost are not counted in the measurement.
	Definition:		The Forwarding Vector may contain several Jitter Vectors. For n
	A description of the expected instantaneous jitter between two		packets received in a Forwarding Vector, there is a total of (n-1)
	consecutive packets arrival times matching a specific		Instantaneous Jitter Vectors.
	classification, such as DSCP.
	Discussion:		Measurement units:
	Instantaneous Jitter is the absolute value of the difference		milliseconds
	between the Forwarding Delay measurement of two packets
	belonging to the same stream.
	Network-layer Traffic Control Mechanisms		See Also:
			Classification
			Stream
			Jitter
			Intended Vector
			Offered Vector
	The Forwarding Delay fluctuation between two consecutive		3.4.3.9. Expected Average Jitter Vector
	packets in a stream is reported as the "Instantaneous
	Jitter". Instantaneous Jitter can be expressed as
	|D(i) - D(i-1)| where D equals the Forwarding Delay and i is
	the test sequence number. Packets lost are not counted in
	the measurement.
	Forwarding Vector may contain several Jitter Vectors. For n		Definition:
	packets received in a Forwarding Vector, there is a total of		A description of the expected average jitter for packets arriving
	(n-1) Instantaneous Jitter Vectors.		in a stream matching a specific classification, such as DSCP.
	Measurement units:		Discussion:
	milliseconds		Average Jitter Vector is the average of all the Instantaneous
			Jitter Vectors measured during the test duration for the same
			stream.
	See Also:		The value of the Expected Average Jitter Vector is dependent on
	Classification		the set of offered vectors and Classification configuration on the
	Stream		DUT/SUT. The DUT is configured in a certain way so that
	Jitter		classification occurs when a traffic mix consisting of multiple
	Intended Vector		streams is applied.
	Offered Vector
	3.4.3.9 Expected Average Jitter Vector		This term captures the expected forwarding behavior from the DUT
			receiving multiple Offered Vectors. The actual algorithm or
			mechanism the DUT uses to achieve service differentiation is
			implementation specific and is not important when describing the
			Expected Average Jitter Vector.
	Definition:		Measurement units:
	A description of the expected average jitter for packets		milliseconds
	arriving in a stream matching a specific classification, such
	as DSCP.
	Discussion:		See Also:
	Average Jitter Vector is the average of all the Instantaneous		Classification
	Jitter Vectors measured during the test duration for the same		Stream
	stream.		Jitter
			Intended Vector
			Offered Vector
			Expected Instantaneous Jitter Vector
	The value of the Expected Average Jitter Vector is dependent		3.4.3.10. Expected Peak-to-peak Jitter Vector
	on the set of offered vectors and Classification
	configuration on the DUT/SUT. The DUT is configured in a
	certain way in order that classification occurs when a
	traffic mix consisting of multiple streams is applied.
	This term captures the expected forwarding behavior from the		Definition:
	DUT receiving multiple Offered Vectors. The actual algorithm		A description of the expected maximum variation in the Forwarding
	or mechanism the DUT uses to achieve service differentiation		Delay of packet arrival times for packets arriving in a stream
	is implementation specific and not important when describing		matching a specific classification, such as DSCP.
	the Expected Average Jitter Vector.
	Measurement units:		Discussion:
	milliseconds		Peak-to-peak Jitter Vector is the maximum Forwarding Delay minus
	Network-layer Traffic Control Mechanisms		the minimum Forwarding Delay of the packets (in a vector)
			forwarded by the DUT/SUT.
	See Also:		Peak-to-peak Jitter is not derived from the Instantaneous Jitter
	Classification		Vector. Peak-to-peak Jitter is based upon all the packets during
	Stream		the test duration, not just two consecutive packets.
	Jitter
	Intended Vector
	Offered Vector
	Expected Instantaneous Jitter Vector
	3.4.3.10 Expected Peak-to-peak Jitter Vector		The value of the Expected Peak-to-peak Jitter Vector is dependent
			on the set of offered vectors and Classification configuration on
			the DUT/SUT. The DUT is configured in a certain way so that
			classification occurs when a traffic mix consisting of multiple
			streams is applied.
	Definition:		This term captures the expected forwarding behavior from the DUT
	A description of the expected maximum variation in the		receiving multiple Offered Vectors. The actual algorithm or
	Forwarding Delay of packet arrival times for packets		mechanism the DUT uses to achieve service differentiation is
	arriving in a stream matching a specific classification,		implementation specific and is not important when describing the
	such as DSCP.		Expected Peak-to-peak Jitter Vector.
	Discussion:		Measurement units:
	Peak-to-peak Jitter Vector is the maximum Forwarding Delay		milliseconds
	minus the minimum Forwarding Delay of the packets (in a
	vector) forwarded by the DUT/SUT.
	Peak-to-peak Jitter is not derived from the Instantaneous		See Also:
	Jitter Vector. Peak-to-peak Jitter is based upon all the		Classification
	packets during the test duration, not just two consecutive		Stream
	packets.		Jitter
			Intended Vector
			Offered Vector
			Expected Instantaneous Jitter Vector
			Expected Average Jitter Vector
	The value of the Expected Peak-to-peak Jitter Vector is		3.4.4. Output Vectors
	dependent on the set of offered vectors and Classification
	configuration on the DUT/SUT. The DUT is configured in a
	certain way in order that classification occurs when a
	traffic mix consisting of multiple streams is applied.
	This term captures the expected forwarding behavior from the		3.4.4.1. Forwarding Vector
	DUT receiving multiple Offered Vectors. The actual algorithm
	or mechanism the DUT uses to achieve service differentiation
	is implementation specific and not important when describing
	the Expected Peak-to-peak Jitter Vector.
	Measurement units:		Definition:
	milliseconds		The number of packets per second for a stream matching a specific
			classification, such as DSCP, that a DUT/SUT is measured to
			forward to the correct destination interface successfully in
			response to an offered vector.
	See Also:		Discussion:
	Classification		Forwarding Vector is expressed as a combination of values: the
	Stream		classification rules AND the measured packets per second for the
	Jitter		stream matching the classification rules. Forwarding Vector is a
	Intended Vector		per-hop measurement. The DUT/SUT MAY remark the specific DSCP (or
	Offered Vector		IP precedence) value for a multi-hop measurement. The stream
	Expected Instantaneous Jitter Vector		remains the same.
	Expected Average Jitter Vector
	Network-layer Traffic Control Mechanisms
	3.4.4 Output Vectors		Measurement units:
	3.4.4.1 Forwarding Vector		N-octet packets per second
	Definition:
	The number of packets per second for a stream matching a
	specific classification, such as DSCP, that a DUT/SUT
	is measured to successfully forward to the correct
	destination interface in response to an offered vector.
	Discussion:		See Also:
	Forwarding Vector is expressed as a combination of values:		Classification
	the classification rules AND the measured packets per		Stream
	second for the stream matching the classification rules.		Forwarding Capacity
	Forwarding Vector is a per-hop measurement. The DUT/SUT		Intended Vector
	MAY remark the specific DSCP (or IP precedence) value for		Offered Vector
	a multi-hop measurement. The stream remains the same.		Expected Vector
	Measurement units:		3.4.4.2. Loss Vector
	N-octet packets per second
	See Also:		Definition:
	Classification		The percentage of packets per second for a stream matching a
	Stream		specific classification, such as DSCP, that a DUT/SUT is measured
	Forwarding Capacity		not to transmit to the correct destination interface in response
	Intended Vector		to an offered vector.
	Offered Vector
	Expected Vector
	3.4.4.2 Loss Vector		Discussion:
	Definition:		Loss Vector is expressed as a combination of values: the
	The percentage of packets per second for a stream		classification rules AND the measured percentage value of packet
	matching a specific classification, such as DSCP, that		loss. Loss Vector is a per-hop measurement. The DUT/SUT MAY
	a DUT/SUT is measured to not transmit to the correct		remark the specific DSCP or IP precedence value for a multi-hop
	destination interface in response to an offered vector.		measurement. The stream remains the same.
	Discussion:		Measurement Units:
	Loss Vector is expressed as a combination of values:		Percentage of packets
	the classification rules AND the measured percentage
	value of packet loss. Loss Vector is a per-hop
	measurement. The DUT/SUT MAY remark the specific DSCP
	or IP precedence value for a multi-hop measurement.
	The stream remains the same.
	Measurement Units:		See Also:
	Percentage of packets		Classification
			Stream
			Intended Vector
			Offered Vector
			Expected Vector
			One-way Packet Loss Metric [Ka99]
	See Also:		3.4.4.3. Sequence Vector
	Classification
	Stream
	Intended Vector
	Offered Vector
	Expected Vector
	One-way Packet Loss Metric [Ka99]
	Network-layer Traffic Control Mechanisms
	3.4.4.3 Sequence Vector		Definition:
	Definition:		The number of packets per second for all packets in a stream
	The number of packets per second for all packets in a		matching a specific classification, such as DSCP, that a DUT/SUT
	stream matching a specific classification, such as DSCP,		is measured to transmit in sequence to the correct destination
	that a DUT/SUT is measured to transmit in sequence to the		interface in response to an offered vector.
	correct destination interface in response to an offered
	vector.
	Discussion:		Discussion:
	Sequence Vector is expressed as a combination of values:		Sequence Vector is expressed as a combination of values: the
	the classification rules AND the number of packets per		classification rules AND the number of packets per second that are
	second that are in-sequence.		in-sequence.
	Sequence Vector is a per-hop measurement. The DUT/SUT		Sequence Vector is a per-hop measurement. The DUT/SUT MAY remark
	MAY remark the specific DSCP or IP precedence value for		the specific DSCP or IP precedence value for a multi-hop
	a multi-hop measurement. The stream remains the same.		measurement. The stream remains the same.
	Measurement Units:		Measurement Units:
	N-octet packets per second		N-octet packets per second
	See Also:		See Also:
	Classification		Classification
	Stream		Stream
	In-sequence Packet		In-sequence Packet
	Intended Vector		Intended Vector
	Offered Vector		Offered Vector
	Expected Vector		Expected Vector
	3.4.4.4 Instantaneous Delay Vector		3.4.4.4. Instantaneous Delay Vector
	Definition:
	The instantaneous Forwarding Delay for a packet in a
	stream matching a specific classification, such as DSCP,
	that a DUT/SUT is measured to successfully transmit to the
	correct destination interface in response to an offered
	vector.
	Discussion:		Definition:
	Instantaneous Delay Vector is expressed as a combination		The instantaneous Forwarding Delay for a packet in a stream
	of values: the classification rules AND Forwarding Delay.		matching a specific classification, such as DSCP, that a DUT/SUT
	For every packet received in a Forwarding Vector, there		is measured to transmit to the correct destination interface
	is a corresponding Instantaneous Delay Vector.		successfully in response to an offered vector.
	Instantaneous Delay Vector is a per-hop measurement. The		Discussion:
	DUT/SUT MAY remark the specific DSCP or IP precedence value		Instantaneous Delay Vector is expressed as a combination of
	for a multi-hop measurement. The stream remains the same.		values: the classification rules AND Forwarding Delay. For every
			packet received in a Forwarding Vector, there is a corresponding
			Instantaneous Delay Vector.
	Instantaneous Delay Vector can be obtained at any offered		Instantaneous Delay Vector is a per-hop measurement. The DUT/SUT
	load. It is RECOMMENDED to obtain this vector at or below		MAY remark the specific DSCP or IP precedence value for a multi-
	the Forwarding Capacity in the absence of Forwarding		hop measurement. The stream remains the same.
	Congestion. For congested Forwarding Delay, run the
	offered load above the Forwarding Capacity.
	Network-layer Traffic Control Mechanisms		Instantaneous Delay Vector can be obtained at any offered load.
			It is RECOMMENDED that this vector be obtained at or below the
			Forwarding Capacity in the absence of Forwarding Congestion. For
			congested Forwarding Delay, run the offered load above the
			Forwarding Capacity.
	Measurement Units:		Measurement Units:
	milliseconds		milliseconds
	See Also:		See Also:
	Classification		Classification
	Stream		Stream
	Forwarding Capacity		Forwarding Capacity
	Forwarding Delay		Forwarding Delay
	Intended Vector		Intended Vector
	Offered Vector		Offered Vector
	Expected Delay Vector		Expected Delay Vector
	3.4.4.5 Average Delay Vector		3.4.4.5. Average Delay Vector
	Definition:		Definition:
	The average Forwarding Delay for packets in a stream		The average Forwarding Delay for packets in a stream matching a
	matching a specific classification, such as DSCP, that		specific classification, such as DSCP, that a DUT/SUT is measured
	a DUT/SUT is measured to successfully transmit to the		to transmit to the correct destination interface successfully in
	correct destination interface in response to an offered		response to an offered vector.
	vector.
	Discussion:		Discussion:
	Average Delay Vector is expressed as combination of values:		Average Delay Vector is expressed as combination of values: the
	the classification rules AND average Forwarding Delay.		classification rules AND average Forwarding Delay.
	The average Forwarding Delay is computed by averaging all		The average Forwarding Delay is computed by averaging all the
	the Instantaneous Delay Vectors for a given stream.		Instantaneous Delay Vectors for a given stream.
	Average Delay Vector is a per-hop measurement. The DUT/SUT		Average Delay Vector is a per-hop measurement. The DUT/SUT MAY
	MAY remark the specific DSCP or IP precedence value for a		remark the specific DSCP or IP precedence value for a multi-hop
	multi-hop measurement. The stream remains the same.		measurement. The stream remains the same.
	Average Delay Vector can be obtained at any offered load.		Average Delay Vector can be obtained at any offered load. It is
	Recommend at or below the Forwarding Capacity in the		recommended that the offered load be at or below the Forwarding
	absence of congestion. For congested Forwarding Delay, run		Capacity in the absence of congestion. For congested Forwarding
	the offered load above the Forwarding Capacity.		Delay, run the offered load above the Forwarding Capacity.
	Measurement Units:		Measurement Units:
	milliseconds		milliseconds
	See Also:		See Also:
	Classification		Classification
	Stream		Stream
	Forwarding Capacity		Forwarding Capacity
	Forwarding Delay		Forwarding Delay
	Intended Vector		Intended Vector
	Offered Vector		Offered Vector
	Expected Delay Vector		Expected Delay Vector
	Instantaneous Delay Vector		Instantaneous Delay Vector
	Network-layer Traffic Control Mechanisms
	3.4.4.6 Maximum Delay Vector		3.4.4.6. Maximum Delay Vector
	Definition:
	The maximum Forwarding Delay for packets in a stream
	matching a specific classification, such as DSCP, that
	a DUT/SUT is measured to successfully transmit to the
	correct destination interface in response to an offered
	vector.
	Discussion:		Definition:
	Maximum Delay Vector is expressed as combination of values:		The maximum Forwarding Delay for packets in a stream matching a
	the classification rules AND maximum Forwarding Delay.		specific classification, such as DSCP, that a DUT/SUT is measured
			to transmit to the correct destination interface successfully in
			response to an offered vector.
	The maximum Forwarding Delay is computed by selecting the		Discussion:
	highest value from the Instantaneous Delay Vectors for a		Maximum Delay Vector is expressed as combination of values: the
	given stream.		classification rules AND maximum Forwarding Delay.
	Maximum Delay Vector is a per-hop measurement. The DUT/SUT		The maximum Forwarding Delay is computed by selecting the highest
	MAY remark the specific DSCP or IP precedence value for a		value from the Instantaneous Delay Vectors for a given stream.
	multi-hop measurement. The stream remains the same.
	Maximum Delay Vector can be obtained at any offered load.		Maximum Delay Vector is a per-hop measurement. The DUT/SUT MAY
	Recommend at or below the Forwarding Capacity in the		remark the specific DSCP or IP precedence value for a multi-hop
	absence of congestion. For congested Forwarding Delay, run		measurement. The stream remains the same.
	the offered load above the Forwarding Capacity.
	Measurement Units:		Maximum Delay Vector can be obtained at any offered load. It is
	milliseconds		recommended that the offered load be at or below the Forwarding
			Capacity in the absence of congestion. For congested Forwarding
			Delay, run the offered load above the Forwarding Capacity.
	See Also:		Measurement Units:
	Classification		milliseconds
	Stream
	Forwarding Capacity
	Forwarding Delay
	Intended Vector
	Offered Vector
	Expected Delay Vector
	Instantaneous Delay Vector
	3.4.4.7 Minimum Delay Vector		See Also:
	Definition:		Classification
	The minimum Forwarding Delay for packets in a stream		Stream
	matching a specific classification, such as DSCP, that		Forwarding Capacity
	a DUT/SUT is measured to successfully transmit to the		Forwarding Delay
	correct destination interface in response to an offered		Intended Vector
	vector.		Offered Vector
			Expected Delay Vector
			Instantaneous Delay Vector
	Discussion:		3.4.4.7. Minimum Delay Vector
	Minimum Delay Vector is expressed as a combination of
	values: the classification rules AND maximum Forwarding
	Delay. The minimum Forwarding Delay is computed by
	selecting the highest value from the Instantaneous Delay
	Vectors for a given stream.
	Network-layer Traffic Control Mechanisms		Definition:
			The minimum Forwarding Delay for packets in a stream matching a
			specific classification, such as DSCP, that a DUT/SUT is measured
			to transmit to the correct destination interface successfully in
			response to an offered vector.
	Minimum Delay Vector is a per-hop measurement. The DUT/SUT		Discussion:
	MAY remark the specific DSCP or IP precedence value for a		Minimum Delay Vector is expressed as a combination of values: the
	multi-hop measurement. The stream remains the same.		classification rules AND minimum Forwarding Delay. The minimum
			Forwarding Delay is computed by selecting the lowest value from
			the Instantaneous Delay Vectors for a given stream.
	Minimum Delay Vector can be obtained at any offered load.		Minimum Delay Vector is a per-hop measurement. The DUT/SUT MAY
	Recommend at or below the Forwarding Capacity in the		remark the specific DSCP or IP precedence value for a multi-hop
	absence of congestion. For congested Forwarding Delay, run		measurement. The stream remains the same.
	the offered load above the Forwarding Capacity.
	Measurement Units:		Minimum Delay Vector can be obtained at any offered load. It is
	milliseconds		recommended that the offered load be at or below the Forwarding
			Capacity in the absence of congestion. For congested Forwarding
			Delay, run the offered load above the Forwarding Capacity.
	See Also:		Measurement Units:
	Classification		milliseconds
	Stream
	Forwarding Capacity
	Forwarding Delay
	Intended Vector
	Offered Vector
	Expected Delay Vector
	3.4.4.8 Instantaneous Jitter Vector		See Also:
	Definition:		Classification
	The jitter for two consecutive packets in a		Stream
	stream matching a specific classification, such as DSCP,		Forwarding Capacity
	that a DUT/SUT is measured to successfully transmit to the		Forwarding Delay
	correct destination interface in response to an offered		Intended Vector
	vector.		Offered Vector
			Expected Delay Vector
	Discussion:		3.4.4.8. Instantaneous Jitter Vector
	Instantaneous Jitter is the absolute value of the difference
	between the Forwarding Delay measurement of two packets
	belonging to the same stream.
	Jitter vector is expressed as pair of numbers. Both the		Definition:
	specific DSCP (or IP precedence) value AND jitter value		The jitter for two consecutive packets in a stream matching a
	combine to make a vector.		specific classification, such as DSCP, that a DUT/SUT is measured
			to transmit to the correct destination interface successfully in
			response to an offered vector.
	The Forwarding Delay fluctuation between two consecutive		Discussion:
	packets in a stream is reported as the "Instantaneous Jitter".		Instantaneous Jitter is the absolute value of the difference
	Instantaneous Jitter Vector can be expressed as		between the Forwarding Delay measurement of two packets belonging
	|D(i) - D(i-1)| where D equals the Forwarding Delay and i is		to the same stream.
	the test sequence number. Packets lost are not counted in
	the measurement.
	Instantaneous Jitter Vector is a per-hop measurement. The		The Instantaneous Jitter vector is expressed as a pair of numbers.
	DUT/SUT MAY remark the specific DSCP or IP precedence value		Both the specific DSCP (or IP precedence) value AND jitter value
	for a multi-hop measurement. The stream remains the same.		combine to make a vector.
	There may be several Instantaneous Jitter Vectors for a		The Forwarding Delay fluctuation between two consecutive packets
	single stream. For n packets measured, there may be (n-1)		in a stream is reported as the "Instantaneous Jitter".
	Instantaneous Jitter Vectors.		Instantaneous Jitter Vector can be expressed as |D(i) - D(i-1)|,
			where D equals the Forwarding Delay and i is the test sequence
			number. Packets lost are not counted in the measurement.
	Network-layer Traffic Control Mechanisms		The Instantaneous Jitter Vector is a per-hop measurement. The
			DUT/SUT MAY remark the specific DSCP or IP precedence value for a
			multi-hop measurement. The stream remains the same.
	Measurement units:		There may be several Instantaneous Jitter Vectors for a single
	milliseconds		stream. For n packets measured, there may be (n-1) Instantaneous
			Jitter Vectors.
	See Also:		Measurement units:
	Classification		milliseconds
	Stream
	Forwarding Delay
	Jitter
	Forwarding Vector
	Expected Vectors
	3.4.4.9 Average Jitter Vector		See Also:
			Classification
			Stream
			Forwarding Delay
			Jitter
			Forwarding Vector
			Expected Vectors
	Definition:		3.4.4.9. Average Jitter Vector
	The average jitter for packets in a stream matching a
	specific classification, such as DSCP, that a DUT/SUT is
	measured to successfully transmit to the correct
	destination interface in response to an offered vector.
	Discussion:		Definition:
	Average jitter is calculated by the average of all the		The average jitter for packets in a stream matching a specific
	Instantaneous Jitter Vectors of the same stream measured		classification, such as DSCP, that a DUT/SUT is measured to
	during the test duration. Average Jitter Vector is		transmit to the correct destination interface successfully in
	expressed as a combination of values: the		response to an offered vector.
	classification rules AND average Jitter.
	Average Jitter vector is a per-hop measurement. The		Discussion:
	DUT/SUT MAY remark the specific DSCP or IP precedence value		Average jitter is calculated by the average of all the
	for a multi-hop measurement. The stream remains the same.		Instantaneous Jitter Vectors of the same stream measured during
			the test duration. Average Jitter Vector is expressed as a
			combination of values: the classification rules AND average
			Jitter.
	Measurement units:		Average Jitter Vector is a per-hop measurement. The DUT/SUT MAY
	milliseconds		remark the specific DSCP or IP precedence value for a multi-hop
			measurement. The stream remains the same.
	See Also:		Measurement units:
	Classification		milliseconds
	Stream
	Jitter
	Forwarding Vector
	Expected Vector
	Instantaneous Jitter Vector
	3.4.4.10 Peak-to-peak Jitter Vector		See Also:
			Classification
			Stream
			Jitter
			Forwarding Vector
			Expected Vector
			Instantaneous Jitter Vector
	Definition:		3.4.4.10. Peak-to-peak Jitter Vector
	The maximum possible variation in the Forwarding Delay for
	packets in a stream matching a specific classification,
	such as DSCP, that a DUT/SUT is measured to successfully
	transmit to the correct destination interface in response
	to an offered vector.
	Network-layer Traffic Control Mechanisms		Definition:
			The maximum possible variation in the Forwarding Delay for packets
			in a stream matching a specific classification, such as DSCP, that
			a DUT/SUT is measured to transmit to the correct destination
			interface successfully in response to an offered vector.
	Discussion:		Discussion:
	Peak-to-peak Jitter Vector is calculated by subtracting		Peak-to-peak Jitter Vector is calculated by subtracting the
	the maximum Forwarding Delay from the minimum Forwarding		maximum Forwarding Delay from the minimum Forwarding Delay of the
	Delay of the packets forwarded by the DUT/SUT. Jitter		packets forwarded by the DUT/SUT. Jitter vector is expressed as a
	vector is expressed as a combination of values: the		combination of values: the classification rules AND peak-to-peak
	classification rules AND peak-to-peak Jitter.		Jitter.
	Peak-to-peak Jitter is not derived from the Instantaneous		Peak-to-peak Jitter is not derived from the Instantaneous Jitter
	Jitter Vector. Peak-to-peak Jitter is based upon all the		Vector. Peak-to-peak Jitter is based upon all the packets during
	packets during the test duration, not just two consecutive		the test duration, not just two consecutive packets.
	packets.
	Measurement units:		Measurement units:
	milliseconds		milliseconds
	See Also:		See Also:
	Jitter		Jitter
	Forwarding Vector		Forwarding Vector
	Stream		Stream
	Expected Vectors		Expected Vectors
	Instantaneous Jitter Vector		Instantaneous Jitter Vector
	Average Jitter Vector		Average Jitter Vector
	4. IANA Considerations		4. Security Considerations
	This document requires no IANA considerations.		Documents of this type do not directly affect the security of the
			Internet or of corporate networks as long as benchmarking is not
			performed on devices or systems connected to production networks.
	5. Security Considerations		Packets with unintended and/or unauthorized DSCP or IP precedence
			values may present security issues. Determining the security
			consequences of such packets is out of scope for this document.
	Documents of this type do not directly affect the security of		5. Acknowledgements
	the Internet or of corporate networks as long as benchmarking
	is not performed on devices or systems connected to
	production networks.
	Packets with unintended and/or unauthorized DSCP or IP		The authors gratefully acknowledge the contributions of the IETF's
	precedence values may present security issues. Determining		Benchmarking Methodology Working Group members in reviewing this
	the security consequences of such packets is out of scope for		document. The authors would like to express our thanks to David
	this document.		Newman for his consistent and valuable assistance throughout the
			development of this document. The authors would also like to thank
			Al Morton and Kevin Dubray for their ideas and support.
	6. Acknowledgments		6. References
	The authors gratefully acknowledge the contributions of the		6.1. Normative References
	IETF's benchmarking working group members in reviewing this
	document. The authors would like to express our thanks to
	David Newman for his consistent and valuable assistance
	throughout the development of this document. The authors
	would also like to thank Al Morton (acmorton@att.com) and
	Kevin Dubray (kdubray@juniper.net) for their ideas and
	support.
	Network-layer Traffic Control Mechanisms		[Br91] Bradner, S., "Benchmarking terminology for network
			interconnection devices", RFC 1242, July 1991.
	7. References		[Br97] Bradner, S., "Key words for use in RFCs to Indicate
	7.1 Normative References		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[Br91] Bradner, S., "Benchmarking Terminology for Network
	Interconnection Devices", RFC 1242, July 1991.
	[Br97] Bradner, S., "Key words for use in RFCs to Indicate		[Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
	Requirement Levels", RFC 2119, March 1997		Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
			C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,
			J., and L. Zhang, "Recommendations on Queue Management and
			Congestion Avoidance in the Internet", RFC 2309, April 1998.
	[Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B.,		[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching
	Deering, S., Estrin, D., Floyd, S., Jacobson, V.,		Devices", RFC 2285, February 1998.
	Minshall, G., Partridge, C., Peterson, L., Ramakrishnan,
	K., Shenker, S., Wroclawski, J. and L. Zhang,
	"Recommendations on Queue Management and Congestion
	Avoidance in the Internet", RFC 2309, April 1998.
	[Ma98] Mandeville, R., "Benchmarking Terminology for LAN		[Ni98] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition
	Switching Devices", RFC 2285, July 1998.		of the Differentiated Services Field (DS Field) in the IPv4
			and IPv6 Headers", RFC 2474, December 1998.
	[Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition		[St91] Steinberg, L., "Techniques for managing asynchronously
	of the Differentiated Services Field (DS Field) in the		generated alerts", RFC 1224, May 1991.
	IPv4 and IPv6 Headers", RFC 2474, December 1998.
	[St91] Steinberg, L., "Techniques for Managing Asynchronously		6.2. Informative References
	Generated Alerts", RC 1224, May 1991.
	7.2 Informative References		[Al99] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay
	[Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay		Metric for IPPM", RFC 2679, September 1999.
	Metric for IPPM", RFC 2679, September 1999
	[Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,		[Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and
	Weiss, W., "An Architecture for Differentiated Services",		W. Weiss, "An Architecture for Differentiated Service", RFC
	RFC 2475, December 1998.		2475, December 1998.
	[Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for		[Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
	Network Interconnect Devices", RFC 2544, March 1999		Network Interconnect Devices", RFC 2544, March 1999.
	[De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation		[De02] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
	Metric for IPPM", RFC 3393, November 2002		Metric for IP Performance Metrics (IPPM)", RFC 3393, November
			2002.
	[Ec98] http://www3.ietf.org/proceedings/98mar/		[Ec98] http://www3.ietf.org/proceedings/98mar/98mar-edited-135.htm
	98mar-edited-135.htm
	[Fl93] Floyd, S., and Jacobson, V., "Random Early Detection		[Fl93] Floyd, S., and Jacobson, V., "Random Early Detection gateways
	gateways for Congestion Avoidance", IEEE/ACM		for Congestion Avoidance", IEEE/ACM Transactions on
	Transactions on Networking, V.1 N.4, August 1993, p.		Networking, V.1 N.4, August 1993, p. 397-413. URL
	397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf".		"ftp://ftp.ee.lbl.gov/papers/early.pdf".
	[Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited		[Ja99] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec,
	Forwarding PHB", RFC 2598, June 1999		J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis,
			"An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
			March 2002.
	[Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way		[Ka99] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet
	Packet Loss Metric for IPPM", RFC 2680, September 1999		Loss Metric for IPPM", RFC 2680, September 1999.
	Network-layer Traffic Control Mechanisms
	[Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control		[Ma91] Mankin, A. and K. Ramakrishnan, "Gateway Congestion Control
	Survey", RFC 1254, August 1991		Survey", RFC 1254, August 1991.
	[Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for		[Ma00] Mandeville, R. and J. Perser, "Benchmarking Methodology for
	LAN Switching Devices", RFC 2889, August 2000		LAN Switching Devices", RFC 2889, August 2000.
	[Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,		[Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.,
	S., Perser, J., "Packet Reordering Metric for IPPM",		Perser, J., "Packet Reordering Metric for IPPM", Work in
	Work in Progress		Progress.
	[Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks",		[Na84] Nagle, J., "Congestion control in IP/TCP internetworks", RFC
	RFC 896, January 1984.		896, January 1984.
	[Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add		[Ra99] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
	Explicit Congestion Notification (ECN) to IP", RFC 2481,		Explicit Congestion Notification (ECN) to IP", RFC 3168,
	January 1999.		September 2001.
	[Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.,		[Sc96] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
	"RTP: A Transport Protocol for Real-Time Applications",		"RTP: A Transport Protocol for Real-Time Applications", STD
	RFC 1889, January 1996		64, RFC 3550, July 2003.
	8. Authors' Addresses		Authors' Addresses
	Jerry Perser		Jerry Perser
	Veriwave		Veriwave
	USA		8770 SW Nimbus Ave.
	EMail: jperser@veriwave.com		Suite B
			Beaverton, OR 97008 USA
			USA
	Scott Poretsky		Phone: + 1 818 338 4112
	Reef Point Systems		EMail: jerry@perser.org
	8 New England Executive Park
	Burlington, MA 01803
	USA
	Phone: + 1 508 439 9008
	EMail: sporetsky@reefpoint.com
	Shobha Erramilli		Scott Poretsky
	Telcordia Technologies		Reef Point Systems
	331 Newman Springs Road		8 New England Executive Park
	Red Bank, New Jersey 07701		Burlington, MA 01803
	USA		USA
	Email: shobha@research.telcordia.com
	Sumit Khurana		Phone: + 1 508 439 9008
	Telcordia Technologies		EMail: sporetsky@reefpoint.com
	445 South Street
	Morristown, NJ 07960		Shobha Erramilli
	USA		Telcordia Technologies
	Phone: + 1 973 829 3170		331 Newman Springs Road
	EMail: sumit@research.telcordia.com		Red Bank, New Jersey 07701
	Network-layer Traffic Control Mechanisms		USA
			EMail: shobha@research.telcordia.com
			Sumit Khurana
			Motorola
			7700 West Parmer Ln.
			Austin, TX 78729
			USA
			Phone: +1 512 996 6604
			Email: skhurana@motorola.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	skipping to change at page 32, line 43		skipping to change at page 34, line 42
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		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		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at
	ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided by the
	Internet Society.		Funding for the RFC Editor function is provided by the IETF
			Administrative Support Activity (IASA).
End of changes. 319 change blocks.
	1260 lines changed or deleted		1167 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/