draft-ietf-ippm-owdp-reqs-06.txt		rfc3763.txt
	Network Working Group Stanislav Shalunov		Network Working Group S. Shalunov
	Internet Draft Benjamin Teitelbaum		Request for Comments: 3763 B. Teitelbaum
	Expiration Date: December 2003 Internet2		Category: Informational Internet2
	June 2003		April 2004
	A One-way Active Measurement Protocol Requirements
	<draft-ietf-ippm-owdp-reqs-06.txt>
	1. 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		One-way Active Measurement Protocol (OWAMP) Requirements
	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		Status of this Memo
	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		This memo provides information for the Internet community. It does
	http://www.ietf.org/ietf/1id-abstracts.txt		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	The list of Internet-Draft shadow directories can be accessed at		Copyright Notice
	http://www.ietf.org/shadow.html
	This memo provides information for the Internet community. This memo		Copyright (C) The Internet Society (2004). All Rights Reserved.
	does not specify an Internet standard of any kind. Distribution of
	this memo is unlimited.
	2. Abstract		Abstract
	With growing availability of good time sources to network nodes, it		With growing availability of good time sources to network nodes, it
	becomes increasingly possible to measure one-way IP performance		becomes increasingly possible to measure one-way IP performance
	metrics with high precision. To do so in an interoperable manner, a		metrics with high precision. To do so in an interoperable manner, a
	common protocol for such measurements is required. This document		common protocol for such measurements is required. This document
	specifies requirements for a one-way active measurement protocol		specifies requirements for a one-way active measurement protocol
	(OWAMP) standard. The protocol can measure one-way delay, as well as		(OWAMP) standard. The protocol can measure one-way delay, as well as
	other unidirectional characteristics, such as one-way loss.		other unidirectional characteristics, such as one-way loss.
	3. Motivations and Goals		1. Motivations and Goals
	The IETF IP Performance Metrics (IPPM) working group has proposed		The IETF IP Performance Metrics (IPPM) working group has proposed
	draft standard metrics for one-way packet delay [RFC2679] and loss		standards track metrics for one-way packet delay [RFC2679] and loss
	[RFC 2680] across Internet paths. Although there are now several		[RFC 2680] across Internet paths. Although there are now several
	measurement platforms that implement the collection of these metrics		measurement platforms that implement the collection of these metrics
	([CQOS], [BRIX], [RIPE], [SURVEYOR]), there is not currently a		([CQOS], [BRIX], [RIPE], [SURVEYOR]), there is not currently a
	standard for interoperability. This requirements document is aimed		standard for interoperability. This requirements document is aimed
	at defining a protocol that allows users to do measurements using		at defining a protocol that allows users to do measurements using
	devices from different vendors at both ends and get meaningful		devices from different vendors at both ends and get meaningful
	results.		results.
	With the increasingly wide availability of affordable global		With the increasingly wide availability of affordable global
	positioning system (GPS) and CDMA based time sources, hosts		positioning system (GPS) and CDMA based time sources, hosts
	skipping to change at page 2, line 40		skipping to change at page 2, line 19
	timestamps one can measure characteristics such as loss with quality		timestamps one can measure characteristics such as loss with quality
	acceptable for many practical purposes, e.g., network operations.		acceptable for many practical purposes, e.g., network operations.
	To support interoperability between alternative OWAMP implementations		To support interoperability between alternative OWAMP implementations
	and make possible a world where "one-way ping" could become		and make possible a world where "one-way ping" could become
	commonplace, a standard is required that specifies how test streams		commonplace, a standard is required that specifies how test streams
	are initiated, how test packets are exchanged, and how test results		are initiated, how test packets are exchanged, and how test results
	are retrieved. Detailed functional requirements are given in the		are retrieved. Detailed functional requirements are given in the
	subsequent section.		subsequent section.
	4. Functional Requirements		2. Functional Requirements
	The protocol(s) should provide the ability to measure, record, and		The protocol(s) should provide the ability to measure, record, and
	distribute the results of measurements of one-way singleton network		distribute the results of measurements of one-way singleton network
	characteristics such as characteristics defined in [RFC2679] and		characteristics such as characteristics defined in [RFC2679] and
	[RFC2680]. Result reporting, sampling, and time stamps are to be		[RFC2680]. Result reporting, sampling, and time stamps are to be
	within the framework of [RFC2330].		within the framework of [RFC2330].
	It should be possible to measure arbitrary one-way singleton		It should be possible to measure arbitrary one-way singleton
	characteristics (e.g., loss, median delay, mean delay, jitter, 90th		characteristics (e.g., loss, median delay, mean delay, jitter, 90th
	percentile of delay, etc.); this is achieved by keeping all the raw		percentile of delay, etc.); this is achieved by keeping all the raw
	data for post-processing by the final data consumer, as specified in		data for post-processing by the final data consumer, as specified in
	section 4.1. Since RFC2679 and RFC2680 standardize metrics based on		section 2.1. Since RFC2679 and RFC2680 standardize metrics based on
	Poisson sampling processes, Poisson streams must be supported by the		Poisson sampling processes, Poisson streams must be supported by the
	protocol(s).		protocol(s).
	Non-singleton characteristics (such as those related to trains of		Non-singleton characteristics (such as those related to trains of
	packets, back-to-back tuples, and so forth) and application traffic		packets, back-to-back tuples, and so forth) and application traffic
	simulation need not be addressed. However, they may be addressed if		simulation need not be addressed. However, they may be addressed if
	considered practical and not in contradiction to other design goals.		considered practical and not in contradiction to other design goals.
	4.1. Keeping All Data for Post-processing		2.1. Keeping All Data for Post-processing
	To facilitate the broadest possible use of obtained measurement		To facilitate the broadest possible use of obtained measurement
	results, the protocol(s) should not necessitate any required post-		results, the protocol(s) should not necessitate any required post-
	processing. (This does not apply to implementation details such as		processing. (This does not apply to implementation details such as
	converting timestamps from ticks since midnight into a canonical form		converting timestamps from ticks since midnight into a canonical form
	or applying calibration constants; such details should naturally be		or applying calibration constants; such details should naturally be
	hidden.) All data obtained during a measurement session should be		hidden.) All data obtained during a measurement session should be
	available after the session is finished if desired by the data		available after the session is finished if desired by the data
	consumer so that various characteristics can be computed from the raw		consumer so that various characteristics can be computed from the raw
	data using arbitrary algorithms.		data using arbitrary algorithms.
	4.2. Result Distribution		2.2. Result Distribution
	A means to distribute measurement results (between hosts		A means to distribute measurement results (between hosts
	participating in a measurement session and beyond) should be		participating in a measurement session and beyond) should be
	provided. Since there can exist a wide variety of scenarios as to		provided. Since there can exist a wide variety of scenarios as to
	where the final data destination should be, these should be invoked		where the final data destination should be, these should be invoked
	separately from measurement requests (e.g., receiver should not have		separately from measurement requests (e.g., receiver should not have
	to automatically send measurement results to the sender, since it may		to automatically send measurement results to the sender, since it may
	be the receiver or a third host that are the ultimate data		be the receiver or a third host that are the ultimate data
	destination).		destination).
	At the same time, ability to transfer results directly to their		At the same time, ability to transfer results directly to their
	destination (without need for potentially large intermediate		destination (without need for potentially large intermediate
	transfers) should be provided.		transfers) should be provided.
	4.3. Protocol Separation		2.3. Protocol Separation
	Since measurement session setup and the actual measurement session		Since measurement session setup and the actual measurement session
	(i) are different tasks; (ii) require different levels of		(i) are different tasks; (ii) require different levels of
	functionality, flexibility, and implementation effort; (iii) may need		functionality, flexibility, and implementation effort; (iii) may need
	to run over different transport protocols, there should exist two		to run over different transport protocols, there should exist two
	protocols: one for conducting the actual measurement session and		protocols: one for conducting the actual measurement session and
	another for session setup/teardown/confirmation/retrieval. These		another for session setup/teardown/confirmation/retrieval. These
	protocols are further referred to as OWAMP-Test and OWAMP-Control,		protocols are further referred to as OWAMP-Test and OWAMP-Control,
	respectively.		respectively.
	It should be possible to use devices that only support OWAMP-Test but		It should be possible to use devices that only support OWAMP-Test but
	not OWAMP-Control to conduct measurement sessions (such devices will		not OWAMP-Control to conduct measurement sessions (such devices will
	necessarily need to support one form of session setup protocol or the		necessarily need to support one form of session setup protocol or the
	other, but it doesn't have to be known to external parties).		other, but it doesn't have to be known to external parties).
	OWAMP-Control would thus become a common protocol for different		OWAMP-Control would thus become a common protocol for different
	administrative domains, which may or may not use it for session setup		administrative domains, which may or may not use it for session setup
	internally.		internally.
	4.4. Test Protocol		2.4. Test Protocol
	The test protocol needs to be implemented on all measurement nodes		The test protocol needs to be implemented on all measurement nodes
	and should therefore have the following characteristics:		and should therefore have the following characteristics:
	+ Be lightweight and easy to implement.		+ Be lightweight and easy to implement.
	+ Be suitable for implementation on a wide range of measurement		+ Be suitable for implementation on a wide range of measurement
	nodes.		nodes.
	+ Allow UDP as the transport protocol, since the protocol needs to		+ Allow UDP as the transport protocol, since the protocol needs to
	be able to measure individual packet delivery times and has to run		be able to measure individual packet delivery times and has to run
	on various machines (see the section "Support for Measurements		on various machines (see the section "Support for Measurements
	with Different Packet Types" below for further discussion).		with Different Packet Types" below for further discussion).
	+ Support varying packet sizes and network services (e.g., DSCP		+ Support varying packet sizes and network services (e.g., DSCP
	marking), as negotiated by OWAMP-Control.		marking).
	+ Be as simple as possible, but no simpler than necessary to		+ Be as simple as possible, but no simpler than necessary to
	implement requirements set forth in this document; the OWAMP-Test		implement requirements set forth in this document; the OWAMP-Test
	packet format should include only universally meaningful fields,		packet format should include only universally meaningful fields,
	and minimum number of them.		and minimum number of them.
	+ If practical, it should be possible to generate OWAMP-Test packets		+ If practical, it should be possible to generate OWAMP-Test packets
	small enough, so that when encapsulated, each fits inside a single		small enough, so that when encapsulated, each fits inside a single
	ATM cell.		ATM cell.
	+ Data needed to calculate experimental errors on the final result		+ Data needed to calculate experimental errors on the final result
	should be included in every OWAMP-Test packet.		should be included in every OWAMP-Test packet.
	4.5. Control Protocol		2.5. Control Protocol
	Control protocol needs to provide the capability to:		Control protocol needs to provide the capability to:
	+ authenticate peers to each other using a common authentication		+ authenticate peers to each other using a common authentication
	method that doesn't require building any new authentication		method that doesn't require building any new authentication
	infrastructure, such as user ID and a shared secret;		infrastructure, such as user ID and a shared secret;
	+ schedule zero or more OWAMP-Test sessions (which do not have to be		+ schedule zero or more OWAMP-Test sessions (which do not have to be
	between the peers of OWAMP-Control conversation);		between the peers of OWAMP-Control conversation);
	skipping to change at page 5, line 29		skipping to change at page 5, line 5
	+ retrieve OWAMP-Test session results (of OWAMP-Test sessions		+ retrieve OWAMP-Test session results (of OWAMP-Test sessions
	scheduled in the current and other OWAMP-Control sessions);		scheduled in the current and other OWAMP-Control sessions);
	+ confirm graceful completion of sessions and allow either side to		+ confirm graceful completion of sessions and allow either side to
	abort a session prematurely.		abort a session prematurely.
	The OWAMP-Control design should not preclude the ability to record		The OWAMP-Control design should not preclude the ability to record
	extended periods of losses. It should always provide peers with the		extended periods of losses. It should always provide peers with the
	ability to distinguish between network and peer failures.		ability to distinguish between network and peer failures.
	4.6. Support for Measurements with Different Packet Types		2.6. Support for Measurements with Different Packet Types
	Since the notion of a packet of type P from [RFC2330], section 13		Since the notion of a packet of type P from [RFC2330], section 13
	doesn't always imply precise definition of packet type, some		doesn't always imply precise definition of packet type, some
	decisions narrowing the scope of possible packet types need to be		decisions narrowing the scope of possible packet types need to be
	made at measurement protocol design stage. Further, measurement with		made at measurement protocol design stage. Further, measurement with
	packets of certain types, while feasible in more closed settings than		packets of certain types, while feasible in more closed settings than
	those implied by OWAMP, become very hard to perform in an open inter-		those implied by OWAMP, become very hard to perform in an open
	domain fashion (e.g., measurements with particular packets with		inter-domain fashion (e.g., measurements with particular packets with
	broken IP checksum or particular loose source routing options).		broken IP checksum or particular loose source routing options).
	In addition, very general packet type specification could result in		In addition, very general packet type specification could result in
	several problems:		several problems:
	+ Many OWAMP-Test speakers will be general purpose computers with a		+ Many OWAMP-Test speakers will be general purpose computers with a
	multitasking operating system that includes a socket interface.		multitasking operating system that includes a socket interface.
	These will inevitably have higher losses when listening to raw		These will inevitably have higher losses when listening to raw
	network traffic. Raw sockets will induce higher loss rate than		network traffic. Raw sockets will induce higher loss rate than
	one would have with UDP measurements.		one would have with UDP measurements.
	skipping to change at page 6, line 29		skipping to change at page 5, line 49
	(scrambling is different for different link-layer technologies).		(scrambling is different for different link-layer technologies).
	It appears that allowing one to ask a measurement server to generate		It appears that allowing one to ask a measurement server to generate
	arbitrary packets becomes an unmanageable security hole and a		arbitrary packets becomes an unmanageable security hole and a
	formidable specification and implementation hurdle.		formidable specification and implementation hurdle.
	For these reasons, we only require OWAMP to support a small subspace		For these reasons, we only require OWAMP to support a small subspace
	of the whole packet type space. Namely, it should be possible to		of the whole packet type space. Namely, it should be possible to
	conduct measurements with a given Differentiated Services Codepoint		conduct measurements with a given Differentiated Services Codepoint
	(DSCP) [RFC2474] or a given Per Hop Behavior Identification Code (PHB		(DSCP) [RFC2474] or a given Per Hop Behavior Identification Code (PHB
	ID) [RFC2836].		ID) [RFC3140].
	5. Scalability		3. Scalability
	While some measurement architecture designs have inherent scalability		While some measurement architecture designs have inherent scalability
	problems (e.g., a full mesh of always-on measurements among N		problems (e.g., a full mesh of always-on measurements among N
	measurement nodes requires O(N^2) total resources, such as storage		measurement nodes requires O(N^2) total resources, such as storage
	space and link capacity), OWAMP itself should not exaggerate the		space and link capacity), OWAMP itself should not exaggerate the
	problem or make it impossible (where it is in principle possible) to		problem or make it impossible (where it is in principle possible) to
	design other architectures that are free of scalability deficiencies.		design other architectures that are free of scalability deficiencies.
	It is the protocol user's responsibility to decide how to use the		It is the protocol user's responsibility to decide how to use the
	protocol and which measurements to conduct.		protocol and which measurements to conduct.
	6. Security Considerations		4. Security Considerations
	6.1. Authentication		4.1. Authentication
	It should be possible to authenticate peers to each other using a		It should be possible to authenticate peers to each other using a
	user ID and a shared secret. It should be infeasible for any		user ID and a shared secret. It should be infeasible for any
	external party without knowledge of the shared secret to obtain any		external party without knowledge of the shared secret to obtain any
	information about it by observing, initiating, or modifying protocol		information about it by observing, initiating, or modifying protocol
	transactions.		transactions.
	It should also be infeasible for such party to use any information		It should also be infeasible for such party to use any information
	obtained by observing, modifying or initiating protocol transactions		obtained by observing, modifying or initiating protocol transactions
	to impersonate (other) valid users.		to impersonate (other) valid users.
	6.2. Authorization		4.2. Authorization
	Authorization shall normally be performed on the basis of the		Authorization shall normally be performed on the basis of the
	authenticated identity (such as username) and the specification shall		authenticated identity (such as username) and the specification shall
	require all implementations to support such a mode of authorization.		require all implementations to support such a mode of authorization.
	Different identities (or classes of identities) can have different		Different identities (or classes of identities) can have different
	testing priviliges. The use of authorization for arriving at		testing privileges. The use of authorization for arriving at
	specific policy decisions (such as whether to allow a specific test		specific policy decisions (such as whether to allow a specific test
	with a specific source and destination and with a given test send		with a specific source and destination and with a given test send
	schedule -- which would determine the average network capacity		schedule -- which would determine the average network capacity
	utilization -- at a given time) is up to the users.		utilization -- at a given time) is up to the users.
	6.3. Being Hard to Interfere with by Applying Special Treatment to		4.3. Being Hard to Interfere with by Applying Special Treatment to
	Measurement Packets		Measurement Packets
	The design of the protocol should make it possible to run sessions		The design of the protocol should make it possible to run sessions
	that would make it very difficult for any intermediate party to make		that would make it very difficult for any intermediate party to make
	results appear better than they would be if no interference was		results appear better than they would be if no interference was
	attempted.		attempted.
	This is different from cryptographic assurance of data integrity,		This is different from cryptographic assurance of data integrity,
	because one can manipulate the results without changing any data in		because one can manipulate the results without changing any data in
	the packets. For example, if OWAMP-Test packets are easy to identify		the packets. For example, if OWAMP-Test packets are easy to identify
	(e.g., they all come to a well-known port number), an intermediate		(e.g., they all come to a well-known port number), an intermediate
	party might place OWAMP-Test traffic into a priority queue at a		party might place OWAMP-Test traffic into a priority queue at a
	congested link thus ensuring that the results of the measurement		congested link thus ensuring that the results of the measurement
	appear better than what would be experienced by other traffic. It		appear better than what would be experienced by other traffic. It
	should not be easy for intermediate parties to identify OWAMP-Test		should not be easy for intermediate parties to identify OWAMP-Test
	packets (just as it should not be easy for restaurants to identify		packets (just as it should not be easy for restaurants to identify
	restaurant critics).		restaurant critics).
	6.4. Secrecy/Confidentiality		4.4. Secrecy/Confidentiality
	It should be possible to make it infeasible for any outside party		It should be possible to make it infeasible for any outside party
	without knowledge of the shared secret being used to learn what		without knowledge of the shared secret being used to learn what
	information is exchanged using OWAMP-Control by inspecting an OWAMP-		information is exchanged using OWAMP-Control by inspecting an OWAMP-
	Control stream or actively modifying it.		Control stream or actively modifying it.
	(It is recognized that some information will inevitably leak from the		(It is recognized that some information will inevitably leak from the
	mere fact of communication and from the presence and timing of		mere fact of communication and from the presence and timing of
	concurrent and subsequent OWAMP-Test traffic.)		concurrent and subsequent OWAMP-Test traffic.)
	6.5. Integrity		4.5. Integrity
	So that it is possible to detect any interference during a		So that it is possible to detect any interference during a
	conversation (other than the detention of some messages), facility		conversation (other than the detention of some messages), facility
	must be provided to authenticate each message of the OWAMP-Control		must be provided to authenticate each message of the OWAMP-Control
	protocol, its attribution to a given session, and its exact placement		protocol, its attribution to a given session, and its exact placement
	in the sequence of control protocol exchanges.		in the sequence of control protocol exchanges.
	It must also be possible to authenticate each message of the test		It must also be possible to authenticate each message of the test
	protocol and its attribution to a specific session, so that		protocol and its attribution to a specific session, so that
	modifications of OWAMP-Test messages can be detected. It must be		modifications of OWAMP-Test messages can be detected. It must be
	possible to do this in a fashion that does not require timestamps		possible to do this in a fashion that does not require timestamps
	themselves to be encrypted; in this case, security properties are		themselves to be encrypted; in this case, security properties are
	valid only when an attacker cannot observe valid traffic between the		valid only when an attacker cannot observe valid traffic between the
	OWAMP-Test sender and receiver.		OWAMP-Test sender and receiver.
	6.6. Replay Attacks		4.6. Replay Attacks
	OWAMP-Control must be resistant to any replay attacks.		OWAMP-Control must be resistant to any replay attacks.
	OWAMP-Test, on the other hand, is a protocol for network measurement.		OWAMP-Test, on the other hand, is a protocol for network measurement.
	One of the attributes of networks is packet duplication. OWAMP-Test		One of the attributes of networks is packet duplication. OWAMP-Test
	has to be suitable for measurement of duplication. This would make		has to be suitable for measurement of duplication. This would make
	it vulnerable to attacks that involve replaying a recent packet. For		it vulnerable to attacks that involve replaying a recent packet. For
	the recipient of such a packet it is impossible to determine whether		the recipient of such a packet it is impossible to determine whether
	the duplication is malicious or naturally occurring.		the duplication is malicious or naturally occurring.
	OWAMP-Test should measure all duplication -- malicious or otherwise.		OWAMP-Test should measure all duplication -- malicious or otherwise.
	Note that this is similar to delay attacks: an attacker can hold up a		Note that this is similar to delay attacks: an attacker can hold up a
	packet for some short period of time and then release it to continue		packet for some short period of time and then release it to continue
	on its way to the recipient. There's no way such delay can be		on its way to the recipient. There's no way such delay can be
	reliably distinguished from naturally occuring delay by the		reliably distinguished from naturally occurring delay by the
	recipient.		recipient.
	OWAMP-Test should measure the network as it was. Note, however, that		OWAMP-Test should measure the network as it was. Note, however, that
	this does not prevent the data from being sanitized at a later stage		this does not prevent the data from being sanitized at a later stage
	of processing, analysis, or consumption. Some sanity checks (those		of processing, analysis, or consumption. Some sanity checks (those
	that are deemed reliable and erring on the side of inclusion) should		that are deemed reliable and erring on the side of inclusion) should
	be performed by OWAMP-Test recipient immediately.		be performed by OWAMP-Test recipient immediately.
	6.7. Modes of Operation		4.7. Modes of Operation
	Since the protocol(s) will be used in widely varying circumstances		Since the protocol(s) will be used in widely varying circumstances
	using widely varying equipment, it is necessary be able to support		using widely varying equipment, it is necessary to be able to support
	varying degrees of security modes of operation. The parameters to be		varying degrees of security modes of operation. The parameters to be
	considered include: confidentiality, data origin authentication,		considered include: confidentiality, data origin authentication,
	integrity and replay protection.		integrity and replay protection.
	It should also be possible to operate in a mode where all security		It should also be possible to operate in a mode where all security
	mechanisms are enabled and security objectives are realized to the		mechanisms are enabled and security objectives are realized to the
	fullest extent possible. We call this "encrypted mode".		fullest extent possible. We call this "encrypted mode".
	Since timestamp encryption takes a certain amount of time, which may		Since timestamp encryption takes a certain amount of time, which may
	be hard to predict on some devices (with a time-sharing OS), a mode		be hard to predict on some devices (with a time-sharing OS), a mode
	skipping to change at page 9, line 34		skipping to change at page 8, line 43
	timestamps are not encrypted. In this mode, all security properties		timestamps are not encrypted. In this mode, all security properties
	of the encrypted mode that can be retained without timestamp		of the encrypted mode that can be retained without timestamp
	encryption should be present. We call this "authenticated mode".		encryption should be present. We call this "authenticated mode".
	It should be possible to operate in a completely "open" mode, where		It should be possible to operate in a completely "open" mode, where
	no cryptographic security mechanisms are used. We call this		no cryptographic security mechanisms are used. We call this
	"unauthenticated mode". In this mode, mandatory-to-use mechanisms		"unauthenticated mode". In this mode, mandatory-to-use mechanisms
	must be specified that prevent the use of the protocol for network		must be specified that prevent the use of the protocol for network
	capacity starvation denial-of-service attacks (e.g., only sending		capacity starvation denial-of-service attacks (e.g., only sending
	test data back to the client that requested them to be sent with the		test data back to the client that requested them to be sent with the
	request delivered over a TCP connection).		request delivered over a TCP connection), and that prevent a worm
			from using the protocol to send test data to a very large number of
			hosts in a short time (e.g., ensuring that open mode requests can
			only be made by humans, rate-limiting the acceptance of open mode
			requests).
	To make implementation more manageable, the number of other options		To make implementation more manageable, the number of other options
	and modes should be kept to the absolute practical minimum. Where		and modes should be kept to the absolute practical minimum. Where
	choosing a single mechanism for achieving anything related to		choosing a single mechanism for achieving anything related to
	security is possible, such choice should be made at specification		security is possible, such choice should be made at specification
	phase and be put into the standard.		phase and be put into the standard.
	7. IANA Considerations		5. IANA Considerations
	Relevant IANA considerations will be placed into the protocol		Relevant IANA considerations will be placed into the protocol
	specification document itself, and not into the requirements		specification document itself, and not into the requirements
	document.		document.
	8. Normative References		6. References
	[RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for		6.1. Normative References
	IP Performance Metrics", RFC 2330, May 1998.
	[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of		[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
	the Differentiated Services Field (DS Field) in the IPv4 and		"Framework for IP Performance Metrics", RFC 2330, May
	IPv6 Headers", RFC 2474, December 1998.		1998.
	[RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay		[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
	Metric for IPPM", RFC 2679, September 1999.		"Definition of the Differentiated Services Field (DS
			Field) in the IPv4 and IPv6 Headers", RFC 2474, December
			1998.
	[RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet		[RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way
	Loss Metric for IPPM", RFC 2680, September 1999.		Delay Metric for IPPM", RFC 2679, September 1999.
	[RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior		[RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way
	Identification Codes", RFC 2836, May 2000.		Packet Loss Metric for IPPM", RFC 2680, September 1999.
	9. Informative References		[RFC3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur,
			"Per Hop Behavior Identification Codes", RFC 3140, June
			2001.
	[BRIX] Brix 1000 Verifier,		6.2. Informative References
	http://www.brixnet.com/products/brix1000.html
	[CQOS] CQOS Home Page, http://www.cqos.com/		[BRIX] Brix 1000 Verifier,
			http://www.brixnet.com/products/brix1000.html
	[RIPE] RIPE NCC Test-Traffic Measurements home,		[CQOS] CQOS Home Page, http://www.cqos.com/
	http://www.ripe.net/test-traffic/
			[RIPE] RIPE NCC Test-Traffic Measurements home,
			http://www.ripe.net/test-traffic/
	[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/		[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/
	10. Authors' Addresses		7. Authors' Addresses
	Stanislav Shalunov <shalunov@internet2.edu>		Stanislav Shalunov
	Benjamin Teitelbaum <ben@internet2.edu>		EMail: shalunov@internet2.edu
	Expiration date: December 2003		Benjamin Teitelbaum
			EMail: ben@internet2.edu
			8. Full Copyright Statement
			Copyright (C) The Internet Society (2004). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
			REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
			INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
			Intellectual Property
			The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed
			to pertain to the implementation or use of the technology
			described in this document or the extent to which any license
			under such rights might or might not be available; nor does it
			represent that it has made any independent effort to identify any
			such rights. Information on the procedures with respect to
			rights in RFC documents can be found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use
			of such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository
			at http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention
			any copyrights, patents or patent applications, or other
			proprietary rights that may cover technology that may be required
			to implement this standard. Please address the information to the
			IETF at ietf-ipr@ietf.org.
			Acknowledgement
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 48 change blocks.
	78 lines changed or deleted		71 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/