draft-ietf-bmwg-dsmterm-08.txt		draft-ietf-bmwg-dsmterm-09.txt
	Network Working Group Jerry Perser		Network Working Group Jerry Perser
	INTERNET-DRAFT Spirent		INTERNET-DRAFT
	Expires in: April 2004 David Newman		Expires in: April 2004 Scott Poretsky
	Network Test		Quarry Technologies
			Shobha Erramilli
			Qnetworx
	Sumit Khurana		Sumit Khurana
	Telcordia		Telcordia
	Shobha Erramilli
	QNetworx
	Scott Poretsky
	Avici Systems
	October 2003		October 2003
	Terminology for Benchmarking Network-layer		Terminology for Benchmarking Network-layer
	Traffic Control Mechanisms		Traffic Control Mechanisms
	<draft-ietf-bmwg-dsmterm-08.txt>		<draft-ietf-bmwg-dsmterm-09.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 2, line 19		skipping to change at page 1, line 65
	1. Introduction .............................................. 3		1. Introduction .............................................. 3
	2. Existing definitions ...................................... 3		2. Existing definitions ...................................... 3
	3. Term definitions............................................4		3. Term definitions............................................4
	3.1 Configuration Terms		3.1 Configuration Terms
	3.1.1 Classification.........................................4		3.1.1 Classification.........................................4
	3.1.2 Codepoint Set..........................................4		3.1.2 Codepoint Set..........................................4
	3.1.3 Forwarding Congestion..................................5		3.1.3 Forwarding Congestion..................................5
	3.1.4 Congestion Management..................................6		3.1.4 Congestion Management..................................6
	3.1.5 Flow...................................................7		3.1.5 Flow...................................................7
	3.2 Measurement Terms		3.2 Measurement Terms
	3.2.1 Channel Capacity.......................................7		3.2.1 Forwarding Capacity....................................7
	3.2.2 Conforming Packet......................................8		3.2.2 Conforming Packet......................................8
	3.2.3 Nonconforming Packet...................................9		3.2.3 Nonconforming Packet...................................9
	3.2.4 Forwarding Delay.......................................9		3.2.4 Forwarding Delay.......................................9
	3.2.5 Jitter................................................11		3.2.5 Jitter................................................11
	3.2.6 Undifferentiated Response.............................11		3.2.6 Undifferentiated Response.............................11
	3.3 Sequence Tracking		3.3 Sequence Tracking
	3.3.1 In-sequence Packet....................................12		3.3.1 In-sequence Packet....................................12
	3.3.2 Out-of-order Packet...................................12		3.3.2 Out-of-order Packet...................................12
	3.3.3 Duplicate Packet......................................13		3.3.3 Duplicate Packet......................................13
	3.3.4 Stream................................................14		3.3.4 Stream................................................14
	skipping to change at page 6, line 44		skipping to change at page 1, line 296
	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 minimize the condition of congestion.		or minimize the condition of congestion.
	Discussion:		Discussion:
	Congestion management may seek either to control congestion		Congestion management may seek either to control congestion
	or avoid it altogether. Such mechanisms classify packets		or avoid it altogether. Such mechanisms classify packets
	based upon IP Precedence or DSCP settings in a packet’s IP		based upon IP Precedence or DSCP settings in a packetÆs IP
	header.		header.
	Congestion avoidance mechanisms seek to prevent congestion		Congestion avoidance mechanisms seek to prevent congestion
	before it actually occurs.		before 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 other classes during periods of congestion.		over other classes during periods of congestion.
	Measurement units:		Measurement units:
	skipping to change at page 7, line 46		skipping to change at page 1, line 352
	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 Channel 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 successfully transmit to the correct destination		observed to successfully transmit to the correct destination
	interface in response to a specified offered load while the		interface in response to a specified offered load while the
	device drops none of the offered packets.		device drops none of the offered packets.
	Network-layer Traffic Control Mechanisms		Network-layer Traffic Control Mechanisms
	Discussion:		Discussion:
	Channel 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 in RFC 1242 measures the frame rate at the ingress		defined in RFC 1242 measures the frame rate at the ingress
	interface(s) of the DUT/SUT.		interface(s) of the DUT/SUT.
	Ingress-based measurements do not account for queuing of the		Ingress-based measurements do not account for queuing of the
	DUT/SUT. Throughput rates can be higher than the Channel		DUT/SUT. Throughput rates can be higher than the Forwarding
	Capacity because of queuing. The difference is dependent		Capacity because of queuing. The difference is dependent
	upon test duration, packet rate, and queue size. Channel		upon test duration, packet rate, and queue size. Forwarding
	Capacity, as an egress measurement, does take queuing into		Capacity, as an egress measurement, does take queuing into
	account.		account.
	Understanding Channel Capacity is a necessary precursor to		Understanding Forwarding Capacity is a necessary precursor to
	any measurement involving Traffic Control Mechanisms. The		any measurement involving Traffic Control Mechanisms. The
	accompanying methodology document MUST take into		accompanying methodology document MUST take into
	consideration Channel Capacity when determining the expected		consideration Forwarding Capacity when determining the
	forwarding vectors. When the sum of the expected forwarding		expected forwarding vectors. When the sum of the expected
	vectors on an interface exceeds the Channel Capacity, the		forwarding vectors on an interface exceeds the Forwarding
	Channel Capacity will govern the forwarding rate.		Capacity, the Forwarding Capacity will govern the forwarding
			rate.
	This measurement differs from forwarding rate at maximum		This measurement differs from forwarding rate at maximum
	offered load (FRMOL) [Ma98] in that Channel Capacity requires		offered load (FRMOL) [Ma98] in that Forwarding Capacity
	zero loss.		requires zero loss.
	Measurement units:		Measurement units:
	N-octet packets per second		N-octet packets per second
	See Also:		See Also:
	Throughput [Br91]		Throughput [Br91]
	Forwarding Rate at Maximum Offered Load [Ma98]		Forwarding Rate at Maximum Offered Load [Ma98]
	Channel Capacity [Sh48]
	3.2.2 Conforming Packet		3.2.2 Conforming Packet
	Definition:		Definition:
	Packets which lie within specific rate, delay, or jitter		Packets which lie within specific rate, delay, or jitter
	bounds.		bounds.
	Discussion:		Discussion:
	A DUT/SUT may be configured to allow a given traffic class to		A DUT/SUT may be configured to allow a given traffic class to
	consume a given amount of bandwidth, or to fall within		consume a given amount of bandwidth, or to fall within
	skipping to change at page 10, line 38		skipping to change at page 1, line 496
	relieves the tester from specifying the start/end for every		relieves the tester from specifying the start/end for every
	link layer protocol that IP runs on. This avoids the need to		link layer protocol that IP runs on. This avoids the need to
	determine whether the start/stop delimiters are included. It		determine whether the start/stop delimiters are included. It
	also allows the use of heterogeneous link layer protocols in		also allows the use of heterogeneous link layer protocols in
	a test.		a test.
	4. Forwarding Delay can be measured at any offered load,		4. Forwarding Delay can be measured at any offered load,
	whereas the latency methodology [Br99] recommends measurement		whereas the latency methodology [Br99] recommends measurement
	at, and only at, the throughput level. Comparing the		at, and only at, the throughput level. Comparing the
	Forwarding Delay below the throughput to Forwarding Delay		Forwarding Delay below the throughput to Forwarding Delay
	above the channel capacity will give insight to the traffic		above the Forwarding Capacity will give insight to the
	control mechanisms.		traffic control mechanisms.
	For example, non-congested delay may be measured with an		For example, non-congested delay may be measured with an
	offered load that does not exceed the channel capacity, while		offered load that does not exceed the Forwarding Capacity,
	congested delay may involve an offered load that exceeds		while congested delay may involve an offered load that
	channel capacity.		exceeds Forwarding Capacity.
	Note: Forwarding Delay SHOULD NOT be used as an absolute		Note: Forwarding Delay SHOULD NOT be used as an absolute
	indicator of DUT/SUT Forwarding Congestion. While Forwarding		indicator of DUT/SUT Forwarding Congestion. While Forwarding
	Delay may rise when offered load nears or exceeds channel		Delay may rise when offered load nears or exceeds Forwarding
	capacity, there is no universal point at which Forwarding		Capacity, there is no universal point at which Forwarding
	Delay can be said to indicate the presence or absence of		Delay can be said to indicate the presence or absence of
	Forwarding Congestion.		Forwarding Congestion.
	Measurement units:		Measurement units:
	Seconds.		Seconds.
	Network-layer Traffic Control Mechanisms		Network-layer Traffic Control Mechanisms
	See Also:		See Also:
	Latency [Br91]		Latency [Br91]
	skipping to change at page 11, line 33		skipping to change at page 1, line 542
	is the order the packets were received.		is the order the packets were received.
	Under loss, jitter can be measured between non-consecutive		Under loss, jitter can be measured between non-consecutive
	test sequence numbers. When Traffic Control Mechanisms are		test sequence numbers. When Traffic Control Mechanisms are
	losing packets, the Forwarding Delay may fluctuate as a		losing packets, the Forwarding Delay may fluctuate as a
	response. Jitter MUST be able to benchmark the delay		response. Jitter MUST be able to benchmark the delay
	variation with or with out loss.		variation with or with out loss.
	Jitter is related to the ipdv [De02] (IP Delay Variation) by		Jitter is related to the ipdv [De02] (IP Delay Variation) by
	taking the absolute value of the ipdv. The two metrics will		taking the absolute value of the ipdv. The two metrics will
	produce different mean values. “Mean Jitter” will produce a		produce different mean values. ôMean Jitterö will produce a
	positive value, where the “mean ipdv” is typically zero.		positive value, where the ômean ipdvö is typically zero.
	Measurement units:		Measurement units:
	Seconds		Seconds
	See Also:		See Also:
	Forwarding Delay		Forwarding Delay
	Jitter variation [Ja99]		Jitter variation [Ja99]
	ipdv [De02]		ipdv [De02]
	interarrival jitter [Sc96]		interarrival jitter [Sc96]
	skipping to change at page 12, line 26		skipping to change at page 1, line 587
	3.3 Sequence Tracking		3.3 Sequence Tracking
	3.3.1 In-sequence Packet		3.3.1 In-sequence Packet
	Definition:		Definition:
	A received packet with the expected Test Sequence number.		A received packet with the expected Test Sequence number.
	Discussion:		Discussion:
	In-sequence is done on a stream level. As packets are		In-sequence is done on a stream level. As packets are
	received on a stream, each packet’s Test Sequence number is		received on a stream, each packetÆs Test Sequence number is
	compared with the previous packet. Only packets that match		compared with the previous packet. Only packets that match
	the expected Test Sequence number are considered in-sequence.		the expected Test Sequence number are considered in-sequence.
	Packets that do not match the expected Test Sequence number		Packets that do not match the expected Test Sequence number
	are counted as "not in-sequence" or out-of-sequence. Every		are counted as "not in-sequence" or out-of-sequence. Every
	packet that is received is either in-sequence or out-of-		packet that is received is either in-sequence or out-of-
	sequence. Subtracting the in-sequence from the received		sequence. Subtracting the in-sequence from the received
	packets (for that stream) can derive the out-of-sequence		packets (for that stream) can derive the out-of-sequence
	count.		count.
	skipping to change at page 14, line 34		skipping to change at page 1, line 692
	3.3.4 Stream		3.3.4 Stream
	Definition:		Definition:
	A group of packets tracked as a single entity by the traffic		A group of packets tracked as a single entity by the traffic
	receiver. A stream may share a common content such as type		receiver. A stream may share a common content such as type
	(IP, UDP), packet size, or payload.		(IP, UDP), packet size, or payload.
	Discussion:		Discussion:
	Streams are tracked by test sequence number or "unique		Streams are tracked by test sequence number or "unique
	signature field" [Ma00]. Streams define how individual		signature field" [Ma00]. Streams define how individual
	packets’ statistic are grouped together to form an		packetsÆ statistic are grouped together to form an
	intelligible summary.		intelligible summary.
	Common stream groupings would be by egress interface,		Common stream groupings would be by egress interface,
	destination address, source address, DSCP, or IP precedence.		destination address, source address, DSCP, or IP precedence.
	A stream using test sequence numbers can track the ordering		A stream using test sequence numbers can track the ordering
	of packets as they transverse the DUT/SUT.		of packets as they transverse the DUT/SUT.
	Streams are not restricted to a pair of source and		Streams are not restricted to a pair of source and
	destination interfaces as long as all packets are tracked as		destination interfaces as long as all packets are tracked as
	a single entity. A mulitcast stream can be forward to		a single entity. A mulitcast stream can be forward to
	skipping to change at page 21, line 35		skipping to change at page 1, line 1040
	Output Vectors		Output Vectors
	Expected Loss Vector		Expected Loss Vector
	Expected Sequence Vector		Expected Sequence Vector
	Expected Forwarding Vector		Expected Forwarding Vector
	Expected Jitter Vector		Expected Jitter Vector
	3.4.3.8 Expected Instantaneous Jitter Vector		3.4.3.8 Expected Instantaneous Jitter Vector
	Definition:		Definition:
	A vector describing the expected jitter between two		A vector describing the expected jitter between two
	consecutive packets’ arrival times having a specific DSCP or		consecutive packetsÆ arrival times having a specific DSCP or
	IP precedence value. The value is dependent on the set of		IP precedence value. The value is dependent on the set of
	offered vectors and configuration of the DUT.		offered vectors and configuration of the DUT.
	Discussion:		Discussion:
	Instantaneous Jitter is the absolute value of the difference		Instantaneous Jitter is the absolute value of the difference
	between the delay measurement of two packets belonging to the		between the delay measurement of two packets belonging to the
	same stream.		same stream.
	The delay fluctuation between two consecutive packets in a		The delay fluctuation between two consecutive packets in a
	stream is reported as the "Instantaneous Jitter".		stream is reported as the "Instantaneous Jitter".
	skipping to change at page 25, line 55		skipping to change at page 1, line 1260
	specific DSCP or IP precedence value. It is not necessarily		specific DSCP or IP precedence value. It is not necessarily
	based on a stream or flow. The Delay vector may be expressed		based on a stream or flow. The Delay vector may be expressed
	as per port of the DUT/SUT. However, it must be consistent		as per port of the DUT/SUT. However, it must be consistent
	with the Expected Delay vectors.		with the Expected Delay vectors.
	Instantaneous Delay Vector is a per-hop measurement. The		Instantaneous Delay Vector is a per-hop measurement. The
	DUT/SUT may change the specific DSCP or IP precedence value		DUT/SUT may change the specific DSCP or IP precedence value
	for a multiple-hop measurement.		for a multiple-hop measurement.
	Instantaneous Delay vector can be obtained at any offered		Instantaneous Delay vector can be obtained at any offered
	load. RECOMMEND at or below the channel capacity in the		load. RECOMMEND at or below the Forwarding Capacity in the
	absence of forwarding congestion. For congested delay, run		absence of forwarding congestion. For congested delay, run
	the offered load above the channel capacity.		the offered load above the Forwarding Capacity.
	Network-layer Traffic Control Mechanisms		Network-layer Traffic Control Mechanisms
	Forwarding Vector may contain several Instantaneous Delay		Forwarding Vector may contain several Instantaneous Delay
	Vectors. For every packet received in a Forwarding Vector,		Vectors. For every packet received in a Forwarding Vector,
	there is a corresponding Instantaneous Delay Vector.		there is a corresponding Instantaneous Delay Vector.
	Measurement Units:		Measurement Units:
	Seconds		Seconds
	skipping to change at page 26, line 50		skipping to change at page 1, line 1309
	Delay vector.		Delay vector.
	The Average Delay Vector is computed by averaging all the		The Average Delay Vector is computed by averaging all the
	Instantaneous Delay Vectors for a given vector.		Instantaneous Delay Vectors for a given vector.
	Average Delay Vector is a per-hop measurement. The DUT/SUT		Average Delay Vector is a per-hop measurement. The DUT/SUT
	may change the specific DSCP or IP precedence value for a		may change the specific DSCP or IP precedence value for a
	multiple-hop measurement.		multiple-hop measurement.
	Average Delay vector can be obtained at any offered load.		Average Delay vector can be obtained at any offered load.
	Recommend at or below the channel capacity in the absence of		Recommend at or below the Forwarding Capacity in the absence
	congestion. For congested delay, run the offered load above		of congestion. For congested delay, run the offered load
	the channel capacity.		above the Forwarding Capacity.
	Measurement Units:		Measurement Units:
	Seconds		Seconds
	Network-layer Traffic Control Mechanisms		Network-layer Traffic Control Mechanisms
	See Also:		See Also:
	Delay		Delay
	Intended Vector		Intended Vector
	Offered Vector		Offered Vector
	Expected Delay Vectors		Expected Delay Vectors
	skipping to change at page 28, line 33		skipping to change at page 1, line 1393
	with the Expected Delay vector.		with the Expected Delay vector.
	Minimum Delay Vector is based upon the minimum Instantaneous		Minimum Delay Vector is based upon the minimum Instantaneous
	Delay Vector of all packets in a Forwarding Vector.		Delay Vector of all packets in a Forwarding Vector.
	Minimum Delay Vector is a per-hop measurement. The DUT/SUT		Minimum Delay Vector is a per-hop measurement. The DUT/SUT
	may change the specific DSCP or IP precedence value for a		may change the specific DSCP or IP precedence value for a
	multiple-hop measurement.		multiple-hop measurement.
	Minimum Delay vector can be obtained at any offered load.		Minimum Delay vector can be obtained at any offered load.
	Recommend at or below the channel capacity in the absence of		Recommend at or below the Forwarding Capacity in the absence
	congestion. For congested delay, run the offered load above		of congestion. For congested delay, run the offered load
	the channel capacity.		above the Forwarding Capacity.
	Measurement Units:		Measurement Units:
	Seconds		Seconds
	See Also:		See Also:
	Delay		Delay
	Intended Vector		Intended Vector
	Offered Vector		Offered Vector
	Expected Delay Vectors		Expected Delay Vectors
	Instantaneous Delay Vector		Instantaneous Delay Vector
	skipping to change at page 31, line 8		skipping to change at page 1, line 1526
	Jitter		Jitter
	Forwarding Vector		Forwarding Vector
	Stream		Stream
	Expected Vectors		Expected Vectors
	Average Jitter Vector		Average Jitter Vector
	Peak-to-peak Jitter Vector		Peak-to-peak Jitter Vector
	Network-layer Traffic Control Mechanisms		Network-layer Traffic Control Mechanisms
	4. Acknowledgments		4. Acknowledgments
	The editors gratefully acknowledge the contributions of the		The authors gratefully acknowledge the contributions of the
	IETF's benchmarking working group members in reviewing this		IETF's benchmarking working group members in reviewing this
	document. The following individuals also made noteworthy		document. The authors would like to express our thanks to
	contributions to the editors' understanding of the subject		David Newman for his consistent and valuable assistance
	matter: John Dawson, Kevin Dubray, and Kathleen Nichols.		throughout the development of this document. The following
			individuals also made noteworthy contributions to the
			editors' understanding of the subject matter: John Dawson,
			Kevin Dubray, and Kathleen Nichols.
	5. Security Considerations		5. Security Considerations
	Documents of this type do not directly affect the security of		Documents of this type do not directly affect the security of
	the Internet or of corporate networks as long as benchmarking		the Internet or of corporate networks as long as benchmarking
	is not performed on devices or systems connected to		is not performed on devices or systems connected to
	production networks.		production networks.
	Packets with unintended and/or unauthorized DSCP or IP		Packets with unintended and/or unauthorized DSCP or IP
	precedence values may present security issues. Determining		precedence values may present security issues. Determining
	skipping to change at page 32, line 48		skipping to change at page 1, line 1605
	[Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks",		[Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks",
	RFC 896, January 1984.		RFC 896, January 1984.
	[Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add		[Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add
	Explicit Congestion Notification (ECN) to IP", RFC 2481,		Explicit Congestion Notification (ECN) to IP", RFC 2481,
	January 1999.		January 1999.
	[Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.,		[Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.,
	"RTP: A Transport Protocol for Real-Time Applications",		"RTP: A Transport Protocol for Real-Time Applications",
	RFC 1889, January 1996		RFC 1889, January 1996
	[Sh48] C. E. Shannon, "A mathematical theory of communication",
	Bell System Technical Journal, vol. 27, pp. 379-423 and
	623-656, July and October 1948
	Network-layer Traffic Control Mechanisms		Network-layer Traffic Control Mechanisms
	8. Authors' Addresses		8. Authors' Addresses
	Jerry Perser		Jerry Perser
	Spirent Communications
	26750 Agoura Road
	Calabasas, CA 91302
	USA		USA
	Phone: + 1 818 676 2300		Phone:
	EMail: jerry.perser@spirentcom.com		EMail: jerry@perser.org
	David Newman		Scott Poretsky
	Network Test		Quarry Technologies
	31324 Via Colinas, Suite 113		New England Executive Park
	Westlake Village, CA 91362		Burlington, MA 01803
	USA		USA
	Phone: + 1 818 889 0011, x10		Phone: + 1 781 359 5090
	EMail: dnewman@networktest.com		EMail: sporetsky@quarrytech.com
			Shobha Erramilli
			QNetworx Inc
			1119 Campus Drive West
			Morganville, NJ 07751
			USA
			Phone:
			EMail: shobha@qnetworx.com
	Sumit Khurana		Sumit Khurana
	Telcordia Technologies		Telcordia Technologies
	445 South Street		445 South Street
	Morristown, NJ 07960		Morristown, NJ 07960
	USA		USA
	Phone: + 1 973 829 3170		Phone: + 1 973 829 3170
	EMail: sumit@research.telcordia.com		EMail: sumit@research.telcordia.com
			Network-layer Traffic Control Mechanisms
			9. Full Copyright Statement
			Copyright (C) The Internet Society (2003). All Rights
			Reserved.
			This document and translations of it may be copied and
			furnished to others, and derivative works that comment on or
			otherwise explain it or assist in its implementation may be
			prepared, copied, published and distributed, in whole or in
			part, without restriction of any kind, provided that the
			above copyright notice and this paragraph are included on all
			such copies and derivative works. However, this document
			itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or
			other Internet organizations, except as needed for the
			purpose of developing Internet standards in which case the
			procedures for copyrights defined in the Internet Standards
			process must be followed, or as required to translate it into
			languages other than English.
			The limited permissions granted above are perpetual and will
			not be revoked by the Internet Society or its successors or
			assigns. This document and the information contained herein
			is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
			THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
			EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
			THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
			RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
			FITNESS FOR A PARTICULAR PURPOSE.
			Network Working Group Jerry Perser
			INTERNET-DRAFT
			Expires in: April 2004 Scott Poretsky
			Quarry Technologies
	Shobha Erramilli		Shobha Erramilli
	QNetworx Inc		Qnetworx
	1119 Campus Drive West		Sumit Khurana
	Morganville, NJ 07751		Telcordia
			October 2003
			Terminology for Benchmarking Network-layer
			Traffic Control Mechanisms
			<draft-ietf-bmwg-dsmterm-09.txt>
			Status of this Memo
			This document is an Internet-Draft and is in full conformance with
			all provisions of Section 10 of RFC2026.
			Internet-Drafts are working documents of the Internet Engineering
			Task Force (IETF), its areas, and its working groups. Note that
			other groups may also distribute working documents as Internet-
			Drafts.
			Internet-Drafts are draft documents valid for a maximum of six
			months and may be updated, replaced, or obsoleted by other
			documents at any time. It is inappropriate to use Internet-
			Drafts as reference material or to cite them other than as "work
			in progress."
			The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
			Copyright Notice
			Copyright (C) The Internet Society (2003). All Rights Reserved.
			Abstract
			This document describes terminology for the benchmarking of
			devices that implement traffic control based on IP precedence or
			diff-serv code point criteria.
			Network-layer Traffic Control Mechanisms
			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
			3.4.3.1 Expected Forwarding Vector........................16
			3.4.3.2 Expected Loss Vector..............................17
			3.4.3.3 Expected Sequence Vector..........................18
			3.4.3.4 Expected Instantaneous Delay Vector...............18
			3.4.3.5 Expected Average Delay Vector.....................19
			3.4.3.6 Expected Maximum Delay Vector.....................10
			3.4.3.7 Expected Minimum Delay Vector.....................20
			3.4.3.8 Expected Instantaneous Jitter Vector..............21
			3.4.3.9 Expected Average Jitter Vector....................22
			3.4.3.10 Expected Peak-to-peak Jitter Vector..............22
			3.4.4 Output Vectors
			3.4.4.1 Forwarding Vector.................................23
			3.4.4.2 Loss Vector.......................................24
			3.4.4.3 Sequence Vector...................................24
			3.4.4.4 Instantaneous Delay Vector........................25
			3.4.4.5 Average Delay Vector..............................26
			3.4.4.6 Maximum Delay Vector..............................27
			3.4.4.7 Minimum Delay Vector..............................28
			3.4.4.8 Instantaneous Jitter Vector.......................28
			3.4.4.9 Average Jitter Vector.............................29
			3.4.4.10 Peak-to-peak Jitter Vector.......................30
			4. Acknowledgments............................................31
			5. Security Considerations....................................31
			6. Normative References.......................................31
			Network-layer Traffic Control Mechanisms
			7. Informative References.....................................32
			8. Author's Address...........................................33
			9. Full Copyright Statement...................................34
			1. Introduction
			New terminology is needed because most existing measurements
			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
			of measurements as observed on egress as well as ingress of a
			device/system under test. Again, the existence of congestion
			requires the addition of egress measurements as well as 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
			for rate, delay, and jitter, all of which can be observed with or
			without congestion of the DUT/SUT.
			This document describes only those terms relevant to measuring
			behavior of a device or a group of devices using one of these two
			mechanisms. End-to-end and service-level measurements are beyond
			the scope of this document.
			2. Existing definitions
			RFC 1242 "Benchmarking Terminology for Network Interconnect
			Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching
			Devices" should be consulted before attempting to make use of this
			document.
			RFC 2474 "Definition of the Differentiated Services Field (DS
			Field) in the IPv4 and IPv6 Headers" section 2, contains
			discussions of a number of terms relevant to network-layer traffic
			control mechanisms 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			RFC 2119 [Br97].
			Network-layer Traffic Control Mechanisms
			3. Term definitions
			3.1 Configuration Terms
			3.1.1 Classification
			Definition:
			Selection of packets based on the contents of packet header
			according to defined rules.
			Discussion:
			Packets can be selected based on the DS field or IP
			Precedence in the packet header. Classification can also be
			based on Multi-Field (MF) criteria such as IP Source and
			destination addresses, protocol and port number.
			Classification determines the per-hop behaviors and traffic
			conditioning functions such as shaping and dropping that are
			to be applied to the packet.
			Measurement units:
			n/a
			See Also:
			3.1.2 Codepoint Set
			Definition:
			The set of all DS Code-points or IP precedence values used
			during the test duration.
			Discussion:
			Describes all the code-point markings associated with packets
			that are input to the DUT/SUT. For each entry in the
			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-
			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.
			Measurement Units:
			n/a
			See Also:
			Network-layer Traffic Control Mechanisms
			3.1.3 Forwarding Congestion
			Definition:
			A condition in which one or more egress interfaces are
			offered more packets than are forwarded.
			Discussion:
			This condition is a superset of the overload definition
			[Ma98]. Overload [Ma98] deals with overloading input and
			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
			occurs when the SUT comprises multiple elements, in that
			Forwarding Congestion may occur at multiple points. Consider
			an SUT comprising multiple edge devices exchanging traffic
			with a 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 Delay, is the metric to indicate
			the condition of Forwarding Congestion. Packet Loss is a
			deterministic indicator of Forwarding Congestion. While
			increased delay may be an indicator of Forwarding Congestion,
			it is a non-deterministic indicator of Forwarding Congestion.
			External observation of increased delay to indicate
			congestion is in effect external observation of Incipient
			Congestion.
			[Ra99] implies that it is impractical to build a black-box
			test to externally observe Incipient Congestion indicated by
			increased delay in a router. [Ra99] introduces Explicit
			Congestion Notification (ECN) as the externally observable,
			deterministic method for indicating Incipient Congestion.
			Because [Ra99] is an Experimental RFC with limited
			deployment, ECN is not used for this particular methodology.
			For the purpose of "black-box" testing a DUT/SUT, Packet Loss
			as the indicator of Forwarding Congestion is used.
			Throughput [Br91] defines the lower boundary of Forwarding
			Congestion. Throughput is the maximum offered rate with no
			Forwarding Congestion. At offered rates above throughput,
			the DUT/SUT is considered to be in a state of Forwarding
			Congestion.
			Network-layer Traffic Control Mechanisms
			Ingress observations alone are not sufficient to cover all
			cases in which Forwarding Congestion may occur. A device
			with an infinite amount of memory could buffer an infinite
			number of packets, and eventually forward all of them.
			However, these packets may or may not be forwarded during the
			test duration. Even though ingress interfaces accept all
			packets without loss, Forwarding Congestion is present in
			this hypothetical device.
			Forwarding Congestion, indicated by occurrence of packet
			loss, is one type of congestion for a DUT/SUT. Congestion
			Collapse [Na84] is defined as the state in which buffers are
			full and all arriving packets must be dropped across the
			network. Incipient Congestion [Ra99] is defined as
			congestion that produces increased delay without packet loss.
			The definition presented here explicitly defines Forwarding
			Congestion as an event observable on egress interfaces.
			Regardless of internal architecture, any device that cannot
			forward packets on one or more egress interfaces is under
			Forwarding Congestion.
			Measurement units:
			none
			See Also:
			Gateway Congestion Control Survey [Ma91]
			3.1.4 Congestion Management
			Definition:
			An implementation of one or more per-hop-behaviors to avoid
			or minimize the condition of congestion.
			Discussion:
			Congestion management may seek either to control congestion
			or avoid it altogether. Such mechanisms classify packets
			based upon IP Precedence or DSCP settings in a packetÆs IP
			header.
			Congestion avoidance mechanisms seek to prevent congestion
			before it actually occurs.
			Congestion control mechanisms give one or more flows (with a
			discrete IP Precedence or DSCP value) preferential treatment
			over other classes during periods of congestion.
			Measurement units:
			n/a
			See Also:
			Network-layer Traffic Control Mechanisms
			3.1.5 Flow
			Definition:
			A flow is a one or more of packets sharing a common intended
			pair of source and destination interfaces.
			Discussion:
			Packets are grouped by the ingress and egress interfaces they
			use on a given DUT/SUT.
			A flow can contain multiple source IP addresses and/or
			destination IP addresses. All packets in a flow must enter
			on the same ingress interface and exit on the same egress
			interface, and have some common network layer content.
			Microflows [Ni98] are a subset of flows. As defined in
			[Ni98], microflows require application-to-application
			measurement. In contrast, flows use lower-layer
			classification criteria. Since this document focuses on
			network-layer classification criteria, we concentrate here on
			the use of network-layer identifiers in describing a flow.
			Flow identifiers also may reside at the data-link, transport,
			or application layers of the OSI model. However, identifiers
			other than those at the network layer are out of scope for
			this document.
			A flow may contain a single code point/IP precedence value or
			may contain multiple values destined for a single egress
			interface. This is determined by the test methodology.
			Measurement units:
			n/a
			See Also:
			Microflow [Ni98]
			Streams
			3.2 Measurement Terms
			3.2.1 Forwarding Capacity
			Definition:
			The number of packets per second that a device can be
			observed to successfully transmit to the correct destination
			interface in response to a specified offered load while the
			device drops none of the offered packets.
			Network-layer Traffic Control Mechanisms
			Discussion:
			Forwarding Capacity measures the packet rate at the egress
			interface(s) of the DUT/SUT. In contrast, throughput as
			defined in RFC 1242 measures the frame rate at the ingress
			interface(s) of the DUT/SUT.
			Ingress-based measurements do not account for queuing of the
			DUT/SUT. Throughput rates can be higher than the Forwarding
			Capacity because of queuing. The difference is dependent
			upon test duration, packet rate, and queue size. Forwarding
			Capacity, as an egress measurement, does take queuing into
			account.
			Understanding Forwarding Capacity is a necessary precursor to
			any measurement involving Traffic Control Mechanisms. The
			accompanying methodology document MUST take into
			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
			offered load (FRMOL) [Ma98] in that Forwarding Capacity
			requires zero loss.
			Measurement units:
			N-octet packets per second
			See Also:
			Throughput [Br91]
			Forwarding Rate at Maximum Offered Load [Ma98]
			3.2.2 Conforming Packet
			Definition:
			Packets which lie within specific rate, delay, or jitter
			bounds.
			Discussion:
			A DUT/SUT may be configured to allow a given traffic class to
			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:
			n/a
			Network-layer Traffic Control Mechanisms
			See Also:
			Expected Vector
			Forwarding Vector
			Offered Vector
			Nonconforming
			3.2.3 Nonconforming Packet
			Definition:
			Packets that do not lie within specific rate, delay, or
			jitter bounds.
			Discussion:
			A DUT/SUT may be configured to allow a given traffic class to
			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:
			n/a
			See Also:
			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.
			Discussion:
			The delay time interval MUST be externally observed. The
			delay measurement MUST NOT include delays added by test bed
			components other than the DUT/SUT, such as propagation time
			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
			uses "store and forward" or "bit forwarding" technology.
			Forwarding Delay is the same metric, measured the same way,
			regardless of the architecture of the DUT/SUT.
			Network-layer Traffic Control Mechanisms
			2. Forwarding Delay is a last-in, last-out (LILO)
			measurement, unlike the last-in, first-out method [Br91] or
			the first-in, last-out method [Al99].
			The LILO method most closely simulates the way a network-
			layer device actually processes an IP datagram. IP datagrams
			are not 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.
			Further, the LILO method has an additive property, where the
			sum of the parts MUST equal the whole. This is a key
			difference from [Br91] and [Al99]. For example, the delay
			added by two DUTs MUST equal the sum of the delay of the
			DUTs. This may or may not be the case with [Br91] and
			[Al99].
			3. Forwarding Delay measures the IP datagram only, unlike
			[Br91], which also includes link layer overhead.
			A metric focused exclusively on the Internet protocol
			relieves the tester from specifying the start/end for every
			link layer protocol that IP runs on. This avoids the need to
			determine whether the start/stop delimiters are included. It
			also allows the use of heterogeneous link layer protocols in
			a test.
			4. Forwarding Delay can be measured at any offered load,
			whereas 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.
			For example, non-congested delay may be measured with an
			offered load that does not exceed the Forwarding Capacity,
			while congested delay may involve an offered load that
			exceeds Forwarding Capacity.
			Note: Forwarding Delay SHOULD NOT be used as an absolute
			indicator of DUT/SUT Forwarding Congestion. While Forwarding
			Delay may rise when offered load nears or exceeds Forwarding
			Capacity, there is no universal point at which Forwarding
			Delay can be said to indicate the presence or absence of
			Forwarding Congestion.
			Measurement units:
			Seconds.
			Network-layer Traffic Control Mechanisms
			See Also:
			Latency [Br91]
			Latency [Al99]
			One-way Delay [Br99]
			3.2.5 Jitter
			Definition:
			The absolute value of the difference between the arrival
			delay of two consecutive received packets belonging to the
			same stream.
			Discussion:
			The 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 delay and i
			is the order the packets were received.
			Under loss, jitter can be measured between non-consecutive
			test sequence numbers. When Traffic Control Mechanisms are
			losing packets, the Forwarding Delay may fluctuate as a
			response. Jitter MUST be able to benchmark the delay
			variation with or with out loss.
			Jitter is related to the ipdv [De02] (IP Delay Variation) by
			taking the absolute value of the ipdv. The two metrics will
			produce different mean values. ôMean Jitterö will produce a
			positive value, where the ômean ipdvö is typically zero.
			Measurement units:
			Seconds
			See Also:
			Forwarding Delay
			Jitter variation [Ja99]
			ipdv [De02]
			interarrival jitter [Sc96]
			3.2.6 Undifferentiated Response
			Definition:
			The vector(s) obtained when mechanisms used to support diff-
			serv or IP precedence are disabled.
			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.
			Network-layer Traffic Control Mechanisms
			Measurements with "undifferentiated response" should be made
			to establish a baseline.
			The vector(s) obtained with DSCP or IP precedence enabled can
			be compared to the undifferentiated response to determine the
			effect of differentiating traffic.
			Measurement units:
			n/a
			3.3 Sequence Tracking
			3.3.1 In-sequence Packet
			Definition:
			A received packet with the expected Test Sequence number.
			Discussion:
			In-sequence is done on a stream level. As packets are
			received on 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.
			Packets that do not match the expected Test Sequence number
			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) can derive the out-of-sequence
			count.
			Two types of events will prevent the in-sequence from
			incrementing: packet loss and reordered packets.
			Measurement units:
			Packet count
			See Also:
			Stream
			Test Sequence number
			3.3.2 Out-of-order Packet
			Definition:
			A received packet with a Test Sequence number less than
			expected.
			Network-layer Traffic Control Mechanisms
			Discussion:
			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
			to be in a certain order. Packets outside this are dropped
			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.
			Out-of-order Packet count is based on the worst case
			streaming protocol. It allows for no reordering.
			Packet loss does not affect the Out-of-order Packet count.
			Only packets that were not received in the order that they
			were transmitted.
			Measurement units:
			Packet count
			See Also:
			Stream
			Test Sequence number
			Packet Reordering Metric for IPPM [Mo03]
			3.3.3 Duplicate Packet
			Definition:
			A received packet with a Test Sequence number matching a
			previously received packet.
			Discussion:
			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
			transmitted packet (including Test Sequence number). If the
			Duplicate Packet traversed different paths through the
			DUT/SUT, some fields (such as TTL or checksum) may have
			changed.
			Network-layer Traffic Control Mechanisms
			A multicast packet is not a Duplicate Packet by definition.
			For a given IP multicast group, a DUT/SUT SHOULD forward a
			packet once on a given egress interface provided the path to
			one or more multicast receivers is through that interface.
			Several egress interfaces will transmit the same packet, but
			only once per interface.
			To detect a Duplicate Packet, each offered packet to the
			DUT/SUT MUST contain a unique packet-by-packet identifier.
			Measurement units:
			Packet count
			See Also:
			Stream
			Test Sequence number
			3.3.4 Stream
			Definition:
			A group of packets tracked as a single entity by the traffic
			receiver. A stream may share a common content such as type
			(IP, UDP), packet size, or payload.
			Discussion:
			Streams are tracked by test sequence number or "unique
			signature field" [Ma00]. Streams define how individual
			packetsÆ statistic are grouped together to form an
			intelligible summary.
			Common stream groupings would be by egress interface,
			destination address, source address, DSCP, or IP precedence.
			A stream using test sequence numbers can track the ordering
			of packets as they transverse the DUT/SUT.
			Streams are not restricted to a pair of source and
			destination interfaces as long as all packets are tracked as
			a single entity. A mulitcast stream can be forward to
			multiple destination interfaces.
			Measurement units:
			n/a
			See Also:
			Flow
			Microflow [Ni98]
			Test sequence number
			Network-layer Traffic Control Mechanisms
			3.3.5 Test Sequence number
			Definition:
			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.
			Discussion:
			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
			per stream basis. In addition to number of received packets,
			the traffic receiver may also report number of in-sequence
			packets, number of out-sequence packets, number of duplicate
			packets, and number of reordered packets.
			The recommended algorithm to use to change the sequence
			number on sequential packets is an incrementing value.
			Measurement units:
			n/a
			See Also:
			Stream
			3.4 Vectors
			A vector is a group of packets all containing a specific DSCP
			or IP precedence value. Vectors are expressed as a pair of
			numbers. The first is being the particular diff-serv value.
			The second is the metric expressed as a rate, loss
			percentage, delay, or jitter.
			3.4.1 Intended Vector
			Definition:
			A vector describing the attempted rate at which packets
			having a specific code-point (or IP precedence) are
			transmitted to a DUT/SUT by an external source.
			Discussion:
			Intended loads across the different code-point classes
			determine the metrics associated with a specific code-point
			traffic class.
			Measurement Units:
			N-octets packets per second
			Network-layer Traffic Control Mechanisms
			See Also:
			Offered Vector
			Expected Forwarding Vector
			Expected Loss Vector
			Expected Sequence Vector
			Expected Delay Vector
			Expected Jitter Vector
			Forwarding Vector
			Loss Vector
			3.4.2 Offered Vector
			Definition:
			A vector describing the measured rate at which packets having
			a specific DSCP or IP precedence value are offered to the
			DUT/SUT.
			Discussion:
			Offered loads across the different code-point classes,
			constituting a code-point set, determine the metrics
			associated with a specific code-point traffic class.
			Measurement Units:
			N-octets packets per second
			See Also:
			Expected Forwarding Vector
			Expected Loss Vector
			Expected Sequence Vector
			Expected Delay Vector
			Expected Jitter Vector
			Forwarding Vector
			Codepoint Set
			3.4.3 Expected Vectors
			3.4.3.1 Expected Forwarding Vector
			Definition:
			A vector describing the expected output rate of packets
			having a specific DSCP or IP precedence value. The value is
			dependent on the set of offered vectors and configuration of
			the DUT.
			Network-layer Traffic Control Mechanisms
			Discussion:
			The DUT is configured in a certain way in order that service
			differentiation occurs for a particular DSCP or IP precedence
			value when a specific traffic mix consisting of multiple
			DSCPs or IP precedence values are applied. This term
			attempts to capture the expected forwarding behavior when
			subjected to a certain offered vectors.
			The actual algorithm or mechanism the DUT uses to achieve
			service differentiation is not important in describing the
			expected forwarding vector.
			Measurement units:
			N-octet packets per second
			See Also:
			Intended Vector
			Offered Vector
			Output Vectors
			Expected Loss Vector
			Expected Sequence Vector
			Expected Delay Vector
			Expected Jitter Vector
			3.4.3.2 Expected Loss Vector
			Definition:
			A vector describing the percentage of packets, having a
			specific DSCP or IP precedence value, that should not be
			forwarded. The value is dependent on the set of offered
			vectors and configuration of the DUT.
			Discussion:
			The DUT is configured in a certain way in order that service
			differentiation occurs for a particular DSCP or IP precedence
			value when a specific traffic mix consisting of multiple
			DSCPs or IP precedence values are applied. This term
			attempts to capture the expected forwarding behavior when
			subjected to a certain offered vector.
			The actual algorithm or mechanism the DUT uses to achieve
			service differentiation is not important in describing the
			expected loss vector.
			Measurement Units:
			Percentage of intended packets that is expected to be
			dropped.
			Network-layer Traffic Control Mechanisms
			See Also:
			Intended Vector
			Offered Vector
			Expected Forwarding Vector
			Expected Sequence Vector
			Expected Delay Vector
			Expected Jitter Vector
			One-way Packet Loss Metric [Ka99]
			3.4.3.3 Expected Sequence Vector
			Definition:
			A vector describing the expected in-sequence packets having a
			specific DSCP or IP precedence value. The value is dependent
			on the set of offered vectors and configuration of the DUT.
			Discussion:
			The DUT is configured in a certain way in order that service
			differentiation occurs for a particular DSCP or IP precedence
			value when a specific traffic mix consisting of multiple
			DSCPs or IP precedence values are applied. This term
			attempts to capture the expected forwarding behavior when
			subjected to a certain offered vectors.
			The actual algorithm or mechanism the DUT uses to achieve
			service differentiation is not important in describing the
			expected sequence vector.
			Measurement Units:
			N-octet packets per second
			See Also:
			Intended Vector
			Offered Vector
			Output Vectors
			Expected Loss Vector
			Expected Forwarding Vector
			Expected Delay Vector
			Expected Jitter Vector
			3.4.3.4 Expected Instantaneous Delay Vector
			Definition:
			A vector describing the expected delay for packets having a
			specific DSCP or IP precedence value. The value is dependent
			on the set of offered vectors and configuration of the DUT.
			Network-layer Traffic Control Mechanisms
			Discussion:
			The DUT is configured in a certain way in order that service
			differentiation occurs for a particular DSCP or IP precedence
			value when a specific traffic mix consisting of multiple
			DSCPs or IP precedence values are applied. This term
			attempts to capture the expected forwarding behavior when
			subjected to a certain offered vectors.
			The actual algorithm or mechanism the DUT uses to achieve
			service differentiation is not important in describing the
			expected delay vector.
			Measurement units:
			Seconds.
			See Also:
			Forwarding Delay
			Intended Vector
			Offered Vector
			Output Vectors
			Expected Loss Vector
			Expected Sequence Vector
			Expected Forwarding Vector
			Expected Jitter Vector
			3.4.3.5 Expected Average Delay Vector
			Definition:
			A vector describing the expected average delay for packets
			having a specific DSCP or IP precedence value. The value is
			dependent on the set of offered vectors and configuration of
			the DUT.
			Discussion:
			The DUT is configured in a certain way in order that service
			differentiation occurs for a particular DSCP or IP precedence
			value when a specific traffic mix consisting of multiple
			DSCPs or IP precedence values are applied. This term
			attempts to capture the expected forwarding behavior when
			subjected to a certain offered vectors.
			The actual algorithm or mechanism the DUT uses to achieve
			service differentiation is not important in describing the
			expected average delay vector.
			Measurement units:
			Seconds.
			Network-layer Traffic Control Mechanisms
			See Also:
			Intended Vector
			Offered Vector
			Output Vectors
			Expected Loss Vector
			Expected Sequence Vector
			Expected Forwarding Vector
			Expected Jitter Vector
			3.4.3.6 Expected Maximum Delay Vector
			Definition:
			A vector describing the expected maximum delay for packets
			having a specific DSCP or IP precedence value. The value is
			dependent on the set of offered vectors and configuration of
			the DUT.
			Discussion:
			The DUT is configured in a certain way in order that service
			differentiation occurs for a particular DSCP or IP precedence
			value when a specific traffic mix consisting of multiple
			DSCPs or IP precedence values are applied. This term
			attempts to capture the expected forwarding behavior when
			subjected to a certain offered vectors.
			The actual algorithm or mechanism the DUT uses to achieve
			service differentiation is not important in describing the
			expected maximum delay vector.
			Measurement units:
			Seconds.
			See Also:
			Intended Vector
			Offered Vector
			Output Vectors
			Expected Loss Vector
			Expected Sequence Vector
			Expected Forwarding Vector
			Expected Jitter Vector
			3.4.3.7 Expected Minimum Delay Vector
			Definition:
			A vector describing the expected minimum delay for packets
			having a specific DSCP or IP precedence value. The value is
			dependent on the set of offered vectors and configuration of
			the DUT.
			Network-layer Traffic Control Mechanisms
			Discussion:
			The DUT is configured in a certain way in order that service
			differentiation occurs for a particular DSCP or IP precedence
			value when a specific traffic mix consisting of multiple
			DSCPs or IP precedence values are applied. This term
			attempts to capture the expected forwarding behavior when
			subjected to a certain offered vectors.
			The actual algorithm or mechanism the DUT uses to achieve
			service differentiation is not important in describing the
			expected minimum delay vector.
			Measurement units:
			Seconds.
			See Also:
			Intended Vector
			Offered Vector
			Output Vectors
			Expected Loss Vector
			Expected Sequence Vector
			Expected Forwarding Vector
			Expected Jitter Vector
			3.4.3.8 Expected Instantaneous Jitter Vector
			Definition:
			A vector describing the expected jitter between two
			consecutive packetsÆ arrival times having a specific DSCP or
			IP precedence value. The value is dependent on the set of
			offered vectors and configuration of the DUT.
			Discussion:
			Instantaneous Jitter is the absolute value of the difference
			between the delay measurement of two packets belonging to the
			same stream.
			The 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 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
			packets received in a Forwarding Vector, there is a total of
			(n-1) Instantaneous Jitter Vectors.
			Measurement units:
			Seconds
			Network-layer Traffic Control Mechanisms
			See Also:
			Delay
			Jitter
			Offered Vector
			Output Vectors
			Expected Average Jitter Vector
			Expected Peak-to-peak Jitter Vector
			Stream
			3.4.3.9 Expected Average Jitter Vector
			Definition:
			A vector describing the expected jitter in packet arrival
			times for packets having a specific DSCP or IP precedence
			value. The value is dependent on the set of offered vectors
			and configuration of the DUT.
			Discussion:
			Average Jitter Vector is the average of all the Instantaneous
			Jitter Vectors measured during the test duration for the same
			DSCP or IP precedence value.
			Measurement units:
			Seconds
			See Also:
			Intended Vector
			Offered Vector
			Output Vectors
			Expected Instantaneous Jitter Vector
			Expected Peak-to-peak Jitter Vector
			3.4.3.10 Expected Peak-to-peak Jitter Vector
			Definition:
			A vector describing the expected maximum variation in the
			delay of packet arrival times for packets having a specific
			DSCP or IP precedence value. The value is dependent on the
			set of offered vectors and configuration of the DUT.
			Discussion:
			Peak-to-peak Jitter Vector is the maximum delay minus the
			minimum delay of the packets (in a vector) forwarded by the
			DUT/SUT.
			Peak-to-peak Jitter is not derived from the Instantaneous
			Jitter Vector. Peak-to-peak Jitter is based upon all the
			packets during the test duration, not just two consecutive
			packets.
			Network-layer Traffic Control Mechanisms
			Measurement units:
			Seconds
			See Also:
			Intended Vector
			Offered Vector
			Output Vectors
			Expected Instantaneous Jitter Vector
			Expected Average Jitter Vector
			3.4.4 Output Vectors
			3.4.4.1 Forwarding Vector
			Definition:
			The number of packets per second for all packets containing a
			specific DSCP or IP precedence value that a device can be
			observed to successfully forward to the correct destination
			interface in response to an offered vector.
			Discussion:
			Forwarding Vector is expressed as pair of numbers. Both the
			specific DSCP (or IP precedence) value AND the packets per
			second value combine to make a vector.
			The Forwarding Vector represents packet rate based on its
			specific DSCP (or IP precedence) value. It is not
			necessarily based on a stream or flow. The Forwarding Vector
			may be expressed as per port of the DUT/SUT. However, it
			must be consistent with the Expected Forwarding Vector.
			Forwarding Vector is a per-hop measurement. The DUT/SUT may
			change the specific DSCP (or IP precedence) value for a
			multiple-hop measurement.
			Measurement units:
			N-octet packets per second
			See Also:
			Intended Vector
			Offered Vector
			Expected Vectors
			Loss Vector
			Sequence Vector
			Delay Vectors
			Network-layer Traffic Control Mechanisms
			3.4.4.2 Loss Vector
			Definition:
			The percentage of packets containing a specific DSCP or IP
			precedence value that a DUT/SUT did not transmit to the
			correct destination interface in response to an offered
			vector.
			Discussion:
			Loss Vector is expressed as pair of numbers. Both the
			specific DSCP (or IP precedence) value AND the percentage
			value combine to make a vector.
			The Loss Vector represents percentage based on a specific
			DSCP or IP precedence value. It is not necessarily based on
			a stream or flow. The Loss Vector may be expressed as per
			port of the DUT/SUT. However, it must be consistent with the
			Expected Loss Vector
			Loss Vector is a per-hop measurement. The DUT/SUT may change
			the specific DSCP or IP precedence value for a multiple-hop
			measurement.
			Measurement Units:
			Percentage of offered packets that is not forwarded.
			See Also:
			Intended Vector
			Offered Vector
			Expected Vectors
			Forwarding Vector
			Sequence Vector
			Delay Vectors
			One-way Packet Loss Metric [Ka99]
			3.4.4.3 Sequence Vector
			Definition:
			The number of packets per second for all packets containing a
			specific DSCP or IP precedence value that a device can be
			observed to transmit in sequence to the correct destination
			interface in response to an offered vector.
			Discussion:
			Sequence Vector is expressed as pair of numbers. Both the
			specific DSCP (or IP precedence) value AND the packets per
			second value combine to make a vector.
			Network-layer Traffic Control Mechanisms
			The Sequence Vector represents packet rate based on its
			specific DSCP or IP precedence value. It is not necessarily
			based on a stream or flow. The Sequence Vector may be
			expressed as per port of the DUT/SUT. However, it must be
			consistent with the Expected Sequence Vector.
			Sequence Vector is a per-hop measurement. The DUT/SUT may
			change the specific DSCP or IP precedence value for a
			multiple-hop measurement.
			Measurement Units:
			N-octet packets per second
			Issues:
			See Also:
			In-sequence Packet
			Intended Vector
			Offered Vector
			Expected Vectors
			Loss Vector
			Forwarding Vector
			Delay Vectors
			3.4.4.4 Instantaneous Delay Vector
			Definition:
			The delay for a packet containing a specific DSCP or IP
			precedence value that a device can be observed to
			successfully transmit to the correct destination interface in
			response to an offered vector.
			Discussion:
			Instantaneous Delay vector is expressed as pair of numbers.
			Both the specific DSCP (or IP precedence) value AND delay
			value combine to make a vector.
			The Instantaneous Delay Vector represents delay on its
			specific DSCP or IP precedence value. It is not necessarily
			based on a stream or flow. The Delay vector may be expressed
			as per port of the DUT/SUT. However, it must be consistent
			with the Expected Delay vectors.
			Instantaneous Delay Vector is a per-hop measurement. The
			DUT/SUT may change the specific DSCP or IP precedence value
			for a multiple-hop measurement.
			Instantaneous Delay vector can be obtained at any offered
			load. RECOMMEND at or below the Forwarding Capacity in the
			absence of forwarding congestion. For congested delay, run
			the offered load above the Forwarding Capacity.
			Network-layer Traffic Control Mechanisms
			Forwarding Vector may contain several Instantaneous Delay
			Vectors. For every packet received in a Forwarding Vector,
			there is a corresponding Instantaneous Delay Vector.
			Measurement Units:
			Seconds
			See Also:
			Delay
			Intended Vector
			Offered Vector
			Expected Delay Vectors
			Average Delay Vector
			Maximum Delay Vector
			Minimum Delay Vector
			3.4.4.5 Average Delay Vector
			Definition:
			The average delay for packets containing a specific DSCP or
			IP precedence value that a device can be observed to
			successfully transmit to the correct destination interface in
			response to an offered vector.
			Discussion:
			Average Delay vector is expressed as pair of numbers. Both
			the specific DSCP (or IP precedence) value AND delay value
			combine to make a vector.
			The Delay Vector represents delay on its specific DSCP or IP
			precedence value. It is not necessarily based on a stream or
			flow. The Delay vector may be expressed as per port of the
			DUT/SUT. However, it MUST be consistent with the Expected
			Delay vector.
			The Average Delay Vector is computed by averaging all the
			Instantaneous Delay Vectors for a given vector.
			Average Delay Vector is a per-hop measurement. The DUT/SUT
			may change the specific DSCP or IP precedence value for a
			multiple-hop measurement.
			Average Delay vector can be obtained at any offered load.
			Recommend at or below the Forwarding Capacity in the absence
			of congestion. For congested delay, run the offered load
			above the Forwarding Capacity.
			Measurement Units:
			Seconds
			Network-layer Traffic Control Mechanisms
			See Also:
			Delay
			Intended Vector
			Offered Vector
			Expected Delay Vectors
			Instantaneous Delay Vector
			Maximum Delay Vector
			Minimum Delay Vector
			3.4.4.6 Maximum Delay Vector
			Definition:
			The maximum delay from all packets containing a specific DSCP
			or IP precedence value that a device can be observed to
			successfully transmit to the correct destination interface in
			response to an offered vector.
			Discussion:
			Maximum Delay vector is expressed as pair of numbers. Both
			the specific DSCP (or IP precedence) value AND delay value
			combine to make a vector.
			The Maximum Delay Vector represents delay on its specific
			DSCP or IP precedence value. It is not necessarily based on
			a stream or flow. The Maximum Delay vector may be expressed
			as per port of the DUT/SUT. However, it must be consistent
			with the Expected Delay vector.
			Maximum Delay Vector is based upon the maximum Instantaneous
			Delay Vector of all packets in a Forwarding Vector.
			Maximum Delay Vector is a per-hop measurement. The DUT/SUT
			may change the specific DSCP or IP precedence value for a
			multiple-hop measurement.
			Measurement Units:
			Seconds
			See Also:
			Delay
			Intended Vector
			Offered Vector
			Expected Delay Vectors
			Instantaneous Delay Vector
			Forwarding Vector
			Average Delay Vector
			Minimum Delay Vector
			Network-layer Traffic Control Mechanisms
			3.4.4.7 Minimum Delay Vector
			Definition:
			The minimum delay from all packets containing a specific DSCP
			or IP precedence value that a device can be observed to
			successfully transmit to the correct destination interface in
			response to an offered vector.
			Discussion:
			Delay vector is expressed as pair of numbers. Both the
			specific DSCP (or IP precedence) value AND delay value
			combine to make a vector.
			The Minimum Delay Vector represents delay on its specific
			DSCP or IP precedence value. It is not necessarily based on
			a stream or flow. The Minimum Delay vector may be expressed
			as per port of the DUT/SUT. However, it must be consistent
			with the Expected Delay vector.
			Minimum Delay Vector is based upon the minimum Instantaneous
			Delay Vector of all packets in a Forwarding Vector.
			Minimum Delay Vector is a per-hop measurement. The DUT/SUT
			may change the specific DSCP or IP precedence value for a
			multiple-hop measurement.
			Minimum Delay vector can be obtained at any offered load.
			Recommend at or below the Forwarding Capacity in the absence
			of congestion. For congested delay, run the offered load
			above the Forwarding Capacity.
			Measurement Units:
			Seconds
			See Also:
			Delay
			Intended Vector
			Offered Vector
			Expected Delay Vectors
			Instantaneous Delay Vector
			Forwarding Vector
			Average Delay Vector
			Maximum Delay Vector
			3.4.4.8 Instantaneous Jitter Vector
			Definition:
			The jitter for two consecutive packets containing a specific
			DSCP or IP precedence value that a device can be observed to
			successfully transmit to the correct destination interface in
			response to an offered vector.
			Network-layer Traffic Control Mechanisms
			Discussion:
			Instantaneous Jitter is the absolute value of the difference
			between the delay measurement of two packets belonging to the
			same stream.
			Jitter vector is expressed as pair of numbers. Both the
			specific DSCP (or IP precedence) value AND jitter value
			combine to make a vector.
			The delay fluctuation between two consecutive packets in a
			stream is reported as the "Instantaneous Jitter".
			Instantaneous Jitter Vector can be expressed as |D(i) - D(i-
			1)| where D equals the delay and i is the test sequence
			number. Packets lost are not counted in the measurement.
			Instantaneous Jitter Vector is a per-hop measurement. The
			DUT/SUT may change the specific DSCP or IP precedence value
			for a multiple-hop measurement.
			Forwarding Vector may contain several Instantaneous Jitter
			Vectors. For n packets received in a Forwarding Vector,
			there are exactly (n-1) Instantaneous Jitter Vectors.
			Measurement units:
			Seconds
			See Also:
			Delay
			Jitter
			Forwarding Vector
			Stream
			Expected Vectors
			Average Jitter Vector
			Peak-to-peak Jitter Vector
			3.4.4.9 Average Jitter Vector
			Definition:
			The average jitter for packets containing a specific DSCP or
			IP precedence value that a device can be observed to
			successfully transmit to the correct destination interface in
			response to an offered vector.
			Discussion:
			Average Jitter Vector is the average of all the Instantaneous
			Jitter Vectors of the same DSCP or IP precedence value,
			measured during the test duration.
			Network-layer Traffic Control Mechanisms
			Average Jitter vector is expressed as pair of numbers. Both
			the specific DSCP (or IP precedence) value AND jitter value
			combine to make a vector.
			Average Jitter vector is a per-hop measurement. The DUT/SUT
			may change the specific DSCP or IP precedence value for a
			multiple-hop measurement.
			Measurement units:
			Seconds
			See Also:
			Jitter
			Forwarding Vector
			Stream
			Expected Vectors
			Instantaneous Jitter Vector
			Peak-to-peak Jitter Vector
			3.4.4.10 Peak-to-peak Jitter Vector
			Definition:
			The maximum possible variation in the delay for packets
			containing a specific DSCP or IP precedence value that a
			device can be observed to successfully transmit to the
			correct destination interface in response to an offered
			vector.
			Discussion:
			Peak-to-peak Jitter Vector is the maximum delay minus the
			minimum delay of the packets (in a vector) forwarded by the
			DUT/SUT.
			Jitter vector is expressed as pair of numbers. Both the
			specific DSCP (or IP precedence) value AND jitter value
			combine to make a vector.
			Peak-to-peak Jitter is not derived from the Instantaneous
			Jitter Vector. Peak-to-peak Jitter is based upon all the
			packets during the test duration, not just two consecutive
			packets.
			Measurement units:
			Seconds
			See Also:
			Jitter
			Forwarding Vector
			Stream
			Expected Vectors
			Average Jitter Vector
			Peak-to-peak Jitter Vector
			Network-layer Traffic Control Mechanisms
			4. Acknowledgments
			The authors gratefully acknowledge the contributions of the
			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 following
			individuals also made noteworthy contributions to the
			editors' understanding of the subject matter: John Dawson,
			Kevin Dubray, and Kathleen Nichols.
			5. Security 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.
			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.
			6. Normative References
			[Br91] Bradner, S., "Benchmarking Terminology for Network
			Interconnection Devices", RFC 1242, July 1991.
			[Br97] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", RFC 2119, March 1997
			[Ma98] Mandeville, R., "Benchmarking Terminology for LAN
			Switching Devices", RFC 2285, February 1998.
			[Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition
			of the Differentiated Services Field (DS Field) in the
			IPv4 and IPv6 Headers", RFC 2474, December 1998.
			Network-layer Traffic Control Mechanisms
			7. Informative References
			[Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay
			Metric for IPPM", RFC 2679, September 1999
			[Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
			Weiss, W., "An Architecture for Differentiated Services",
			RFC 2475, December 1998.
			[Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for
			Network Interconnect Devices", RFC 2544, March 1999
			[De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation
			Metric for IPPM", RFC 3393, November 2002
			[Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited
			Forwarding PHB", RFC 2598, June 1999
			[Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way
			Packet Loss Metric for IPPM", RFC 2680, September 1999
			[Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control
			Survey", RFC 1254, August 1991
			[Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for
			LAN Switching Devices", RFC 2889, August 2000
			[Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
			S., Perser, J., "Packet Reordering Metric for IPPM",
			Work in Progress
			[Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks",
			RFC 896, January 1984.
			[Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add
			Explicit Congestion Notification (ECN) to IP", RFC 2481,
			January 1999.
			[Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.,
			"RTP: A Transport Protocol for Real-Time Applications",
			RFC 1889, January 1996
			Network-layer Traffic Control Mechanisms
			8. Authors' Addresses
			Jerry Perser
	USA		USA
	Phone:		Phone:
	EMail: shobha@qnetworx.com		EMail: jerry@perser.org
	Scott Poretsky		Scott Poretsky
	Quarry Technologies		Quarry Technologies
	New England Executive Park		New England Executive Park
	Burlington, MA 01803		Burlington, MA 01803
	USA		USA
	Phone: + 1 781 395 5090		Phone: + 1 781 359 5090
	EMail: sporetsky@quarrytech.com		EMail: sporetsky@quarrytech.com
			Shobha Erramilli
			QNetworx Inc
			1119 Campus Drive West
			Morganville, NJ 07751
			USA
			Phone:
			EMail: shobha@qnetworx.com
			Sumit Khurana
			Telcordia Technologies
			445 South Street
			Morristown, NJ 07960
			USA
			Phone: + 1 973 829 3170
			EMail: sumit@research.telcordia.com
	Network-layer Traffic Control Mechanisms		Network-layer Traffic Control Mechanisms
	9. Full Copyright Statement		9. Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights		Copyright (C) The Internet Society (2003). All Rights
	Reserved.		Reserved.
	This document and translations of it may be copied and		This document and translations of it may be copied and
	furnished to others, and derivative works that comment on or		furnished to others, and derivative works that comment on or
	otherwise explain it or assist in its implementation may be		otherwise explain it or assist in its implementation may be
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/