< draft-ietf-ippm-twamp-06.txt		draft-ietf-ippm-twamp-07.txt >
			Network Working Group K. Hedayat
			Internet Draft Brix Networks
			Expires: Nov 2008 R. Krzanowski
			Intended Status:Standards Track Verizon
			A. Morton
			AT&T Labs
			K. Yum
			Juniper Networks
			J. Babiarz
			Nortel Networks
			May 13, 2008
	K. Hedayat		A Two-way Active Measurement Protocol (TWAMP)
	Internet Draft Brix Networks		draft-ietf-ippm-twamp-07
	Expires: June 2008 R. Krzanowski
	Verizon
	K. Yum
	Juniper Networks
	A. Morton
	AT&T Labs
	J. Babiarz
	Nortel Networks
	December 2007
	A Two-way Active Measurement Protocol (TWAMP)
	draft-ietf-ippm-twamp-06
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The IP Performance Metrics (IPPM) working group's One-way Active		The One-way Active Measurement Protocol [RFC4656] (OWAMP) provides
	Measurement Protocol [RFC4656] (OWAMP) provides a common protocol		a common protocol for measuring one-way metrics between network
	for measuring one-way metrics between network devices. OWAMP can		devices. OWAMP can be used bi-directionally to measure one-way
	be used bi-directionally to measure one-way metrics in both		metrics in both directions between two network elements. However,
	directions between two network elements. However, it does not		it does not accommodate round-trip or two-way measurements. This
	accommodate round-trip or two-way measurements. This memo		memo specifies a Two-way Active Measurement Protocol (TWAMP), based
	specifies a Two-way Active Measurement Protocol (TWAMP), based on		on the OWAMP, that adds two-way or round-trip measurement
	the OWAMP, that adds two-way or round-trip measurement		capabilities. The TWAMP measurement architecture is usually
	capabilities. The TWAMP measurement architecture is usually		comprised of two hosts with specific roles, and this allows for
	comprised of two hosts with specific roles, and this allows for		some protocol simplifications, making it an attractive alternative
	some protocol simplifications, making it an attractive alternative		in some circumstances.
	in some circumstances.
	Table of Contents		Table of Contents
	1. Introduction..................................................3		1. Introduction..................................................3
	1.1 Relationship of Test and Control Protocols................3		1.1 Relationship of Test and Control Protocols................3
	1.2 Logical Model.............................................3		1.2 Logical Model.............................................3
	2. Protocol Overview.............................................5		1.3 Pronunciation Guide.......................................5
	3. TWAMP Control.................................................5		2. Protocol Overview.............................................5
	3.1 Connection Setup..........................................6		3. TWAMP Control.................................................6
	3.2 Integrity Protection......................................6		3.1 Connection Setup..........................................6
	3.3 Value of the Accept Fields................................6		3.2 Integrity Protection......................................7
	3.4 TWAMP Control Commands....................................6		3.3 Value of the Accept Fields................................7
	3.5 Creating Test Sessions....................................6		3.4 TWAMP Control Commands....................................7
	3.6 Send Schedules............................................9		3.5 Creating Test Sessions....................................8
	3.7 Starting Test Sessions....................................9		3.6 Send Schedules...........................................10
	3.8 Stop-Sessions.............................................9		3.7 Starting Test Sessions...................................10
	3.9 Fetch-Session.............................................9		3.8 Stop-Sessions............................................10
	4. TWAMP Test....................................................9		3.9 Fetch-Session............................................11
	4.1 Sender Behavior..........................................10		4. TWAMP Test...................................................11
	4.2 Reflector Behavior.......................................10		4.1 Sender Behavior..........................................12
	5. Implementers Guide...........................................16		4.2 Reflector Behavior.......................................12
	5.1 Complete TWAMP...........................................17		5. Implementers Guide...........................................19
	5.2 TWAMP Light..............................................17		6. Security Considerations......................................19
	6. Security Considerations......................................18		7. Acknowledgements.............................................20
	7. Acknowledgements.............................................18		8. IANA Considerations..........................................20
	8. IANA Considerations..........................................19		8.1 Registry Specification...................................20
	8.1 Registry Specification...................................19		8.2 Registry Management......................................21
	8.2 Registry Management......................................19		8.3 Experimental Numbers.....................................21
	8.3 Experimental Numbers.....................................20		8.4 Initial Registry Contents................................21
	8.4 Initial Registry Contents................................20		9. Internationalization Considerations..........................21
	9. Internationalization Considerations..........................20		10. APPENDIX I - TWAMP Light (Informative)......................22
	10. References..................................................21		11. References..................................................23
	10.1 Normative References....................................21		11.1 Normative References....................................23
	10.2 Informative References..................................21		11.2 Informative References..................................23
	1. Introduction		1. Introduction
	The IETF IP Performance Metrics (IPPM) working group has completed		The Internet Engineering Task Force (IETF) has completed a Proposed
	a draft standard for the round-trip delay [RFC2681] metric. IPPM		standard for the round-trip delay [RFC2681] metric. IETF has also
	has also completed a protocol for the control and collection of		completed a protocol for the control and collection of one-way
	one-way measurements, the One-way Active Measurement Protocol		measurements, the One-way Active Measurement Protocol (OWAMP)
	(OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip		[RFC4656]. However, OWAMP does not accommodate round-trip or two-
	or two-way measurements.		way measurements.
	Two-way measurements are common in IP networks, primarily because		Two-way measurements are common in IP networks, primarily because
	time accuracy is less demanding for round-trip delay, and		synchronization between local and remote clocks is unnecessary for
	measurement support at the remote end may be limited to a simple		round-trip delay, and measurement support at the remote end may be
	echo function. This memo specifies the Two-way Active Measurement		limited to a simple echo function. This memo specifies the Two-way
	Protocol, or TWAMP. TWAMP uses the methodology and architecture of		Active Measurement Protocol, or TWAMP. TWAMP uses the methodology
	OWAMP [RFC4656] to define an open protocol for measurement of		and architecture of OWAMP [RFC4656] to define an open protocol for
	two-way or round-trip metrics (henceforth in this document the term		measurement of two-way or round-trip metrics (henceforth in this
	two-way also signifies round-trip). The TWAMP measurement		document the term two-way also signifies round-trip). The TWAMP
	architecture is usually comprised of only two hosts with specific		measurement architecture is usually comprised of only two hosts
	roles, and this allows for some protocol simplifications, making it		with specific roles, and this allows for some protocol
	an attractive alternative to OWAMP in some circumstances.		simplifications, making it an attractive alternative to OWAMP in
			some circumstances.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	RFC 2119 [RFC2119].		RFC 2119 [RFC2119].
	1.1 Relationship of Test and Control Protocols		1.1 Relationship of Test and Control Protocols
	Similar to OWAMP [RFC4656], TWAMP consists of two inter-related		Similar to OWAMP [RFC4656], TWAMP consists of two inter-related
	protocols: TWAMP-Control and TWAMP-Test. The relationship of these		protocols: TWAMP-Control and TWAMP-Test. The relationship of these
	protocols is as defined in section 1.1 of OWAMP [RFC4656].		protocols is as defined in section 1.1 of OWAMP [RFC4656].
	TWAMP-Control is used to initiate, start, and stop test sessions,		TWAMP-Control is used to initiate, start, and stop test sessions,
	whereas TWAMP-Test is used to exchange test packets between two		whereas TWAMP-Test is used to exchange test packets between two
	TWAMP entities.		TWAMP entities.
	1.2 Logical Model		1.2 Logical Model
	The role and definition of the logical entities are as defined in		The role and definition of the logical entities are as defined in
	section 1.2 of OWAMP [RFC4656] with the following exceptions:		section 1.2 of OWAMP [RFC4656] with the following exceptions:
	- The Session-Receiver is called the Session-Reflector in the		- The Session-Receiver is called the Session-Reflector in the
	TWAMP architecture. The Session-Reflector has the capability		TWAMP architecture. The Session-Reflector has the capability
	to create and send a measurement packet when it receives a		to create and send a measurement packet when it receives a
	measurement packet. Unlike the Session-Receiver, the		measurement packet. Unlike the Session-Receiver, the
	Session-Reflector does not collect any packet information.		Session-Reflector does not collect any packet information.
	- The Server is an end system that manages one or more TWAMP		- The Server is an end system that manages one or more TWAMP
	sessions, and is capable of configuring per-session state in		sessions, and is capable of configuring per-session state in
	the end-points. However, a Server associated with a		the end-points. However, a Server associated with a
	Session-Reflector would not have the capability to return the		Session-Reflector would not have the capability to return the
	results of a test session, and this is a difference from OWAMP.		results of a test session, and this is a difference from OWAMP.
	- The Fetch-Client entity does not exist in the TWAMP		- The Fetch-Client entity does not exist in the TWAMP
	architecture, as the Session-Reflector does not collect any		architecture, as the Session-Reflector does not collect any
	packet information to be fetched. Consequently there is no		packet information to be fetched. Consequently there is no
	need for the Fetch-Client.		need for the Fetch-Client.
	An example of possible relationship scenarios between these roles		An example of possible relationship scenarios between these roles
	are presented below. In this example different logical roles are		are presented below. In this example different logical roles are
	played on different hosts. Unlabeled links in the figure are		played on different hosts. Unlabeled links in the figure are
	unspecified by this document and may be proprietary protocols.		unspecified by this document and may be proprietary protocols.
	+----------------+ +-------------------+		+----------------+ +-------------------+
	| Session-Sender |<-TWAMP-Test-->| Session-Reflector |		| Session-Sender |<-TWAMP-Test-->| Session-Reflector |
	+----------------+ +-------------------+		+----------------+ +-------------------+
	^ ^		^ ^
	| |		| |
	| |		| |
	| |		| |
	| +----------------+<----------------+		| +----------------+<----------------+
	| | Server |		| | Server |
	| +----------------+		| +----------------+
	| ^		| ^
	| |		| |
	| TWAMP-Control		| TWAMP-Control
	| |		| |
	v v		v v
	+----------------+		+----------------+
	| Control-Client |		| Control-Client |
	+----------------+		+----------------+
	As in OWAMP [RFC4656], different logical roles can be played by the		As in OWAMP [RFC4656], different logical roles can be played by the
	same host. For example, in the figure above, there could be		same host. For example, in the figure above, there could be
	actually two hosts: one playing the roles of Control-Client and		actually two hosts: one playing the roles of Control-Client and
	Session-Sender, and the other playing the roles of Server and		Session-Sender, and the other playing the roles of Server and
	Session-Reflector. This example is shown below.		Session-Reflector. This example is shown below.
	+-----------------+ +-------------------+		+-----------------+ +-------------------+
	| Control-Client |<--TWAMP Control-->| Server |		| Control-Client |<--TWAMP Control-->| Server |
	| | | |		| | | |
	| Session-Sender |<--TWAMP-Test----->| Session-Reflector |		| Session-Sender |<--TWAMP-Test----->| Session-Reflector |
	+-----------------+ +-------------------+		+-----------------+ +-------------------+
	Additionally, following the guidelines of OWAMP [RFC4656], TWAMP		Additionally, following the guidelines of OWAMP [RFC4656], TWAMP
	has been defined to allow for small test packets that would fit		has been defined to allow for small test packets that would fit
	inside the payload of a single ATM cell (only in unauthenticated		inside the payload of a single ATM cell (only in unauthenticated
	mode).		mode).
	2. Protocol Overview		1.3 Pronunciation Guide
	The Two-way Active Measurement Protocol is an open protocol for		The acronym OWAMP is usually pronounced in two syllables, Oh-wamp.
	measurement of two-way metrics. It is based on OWAMP [RFC4656] and
	adheres to its overall architecture and design. The protocol
	defined in this document extends and changes OWAMP [RFC4656] as
	follows:
	- Define a new logical entity, Session-Reflector, in place of the		The acronym TWAMP is also pronounced in two syllables, Tee-wamp.
	Session-Receiver.
	- Define the Session-Reflector behavior in place of the		2. Protocol Overview
	Session-Receiver behavior of OWAMP [RFC4656].
	- Define a new test packet format for packets transmitted from the		The Two-way Active Measurement Protocol is an open protocol for
	Session-Reflector to Session-Sender.		measurement of two-way metrics. It is based on OWAMP [RFC4656] and
			adheres to its overall architecture and design. The TWAMP-control
			and TWAMP-Test protocols accomplish their testing tasks as outlined
			below:
	- Fetch client does not exist in the TWAMP architecture.		- The Control-Client initiates a TCP connection on TWAMP's well-
			known port, and the Server (its role now established) responds
			with its greeting message indicating the security/integrity
			mode(s) it is willing to support.
	All multi-octet quantities defined in this document are represented		- The Control-Client responds with the chosen mode of
	as unsigned integers in network byte order unless specified		communication and information supporting integrity protection
	otherwise.		and encryption, if the mode requires them. The Server responds
			to accept the mode and start time. This completes the control
			connection setup.
	3. TWAMP Control		- The Control-Client requests (and describes) a test session with
			a unique TWAMP-Control message. The Server repsponds with its
			acceptance and supporting information. More than one test
			session may be requested with additional messages.
	TWAMP-Control is a derivative of the OWAMP-Control for two-way		- The Control-Client initiates all requested testing with a start
	measurements. All TWAMP Control messages are similar in format and		sessions message, and the Server acknowleges.
	follow similar guidelines to those defined in section 3 of OWAMP
	[RFC4656] with the exceptions outlined in the following sections.
	All OWAMP [RFC4656] Control messages except for the Fetch-Session		- The Session-Sender and the Session-Reflector exchange test
	command apply to TWAMP.		packets according to the TWAMP-Test protocol for each active
			session.
	3.1 Connection Setup		- When appropriate, the Control-Client sends a message to stop all
			test sessions.
	Connection establishment of TWAMP follows the same procedure		There are two recognized extension mechanisms in the TWAMP
	defined in section 3.1 of OWAMP [RFC4656]. The mode values are		Protocol. The Modes field is used to establish the communication
	identical to OWAMP. The only exception is the well-known port		options during TWAMP-Control Connection Setup. The TWAMP-Control
	number for TWAMP-control. A client opens a TCP connection to the		Command Number is another intended extension mechanism, allowing
	server on well-known port N (Refer to the IANA Considerations		additional commands to be defined in the future. TWAMP-Control
	section below for the TWAMP-control port number assignment). The		protocol addresses different levels of support between Control-
	host that initiates the TCP connection takes the roles of		Client and Server.
	Control-Client and (in the two-host implementation) the
	Session-Sender. The host that acknowledges the TCP connection
	accepts the roles of Server and (in the two-host implementation)
	the Session Reflector.
	3.2 Integrity Protection		All multi-octet quantities defined in this document are represented
			as unsigned integers in network byte order unless specified
			otherwise.
	Integrity protection of TWAMP follows the same procedure defined in		3. TWAMP Control
	section 3.2 of OWAMP [RFC4656].
	3.3 Value of the Accept Fields		TWAMP-Control is a derivative of the OWAMP-Control for two-way
			measurements. All TWAMP Control messages are similar in format and
			follow similar guidelines to those defined in section 3 of OWAMP
			[RFC4656] with the exceptions outlined in the following sections.
			One such exception is the Fetch Session command, which is not used
			in TWAMP.
	Accept values used in TWAMP are the same as the values defined in		3.1 Connection Setup
	section 3.3 of OWAMP [RFC4656].
	3.4 TWAMP Control Commands		Connection establishment of TWAMP follows the same procedure
			defined in section 3.1 of OWAMP [RFC4656]. The Modes field is a
			recognized extension mechanism in TWAMP, and the current mode
			values are identical to those used in OWAMP. The only exception is
			the well-known port number for TWAMP-control. A client opens a TCP
			connection to the server on well-known port N (Refer to the IANA
			Considerations section below for the TWAMP-control port number
			assignment). The host that initiates the TCP connection takes the
			roles of Control-Client and (in the two-host implementation) the
			Session-Sender. The host that acknowledges the TCP connection
			accepts the roles of Server and (in the two-host implementation)
			the Session Reflector.
	TWAMP control commands are as defined in section 3.4 of OWAMP		The possibility exists for Control-Client failure after TWAMP-
	[RFC4656] except that the Fetch-Session command does not apply to		Control connection establishment, or the path between the Control-
	TWAMP.		Client and Server may fail while a connection is in-progress. The
			Server MAY discontinue any established control connection when no
			packet associated with that connection, AND no packet associated
			with any test sessions started by that control connection have been
			received for SERVWAIT seconds. The default value of SERVWAIT SHALL
			be 900 seconds, and this waiting time MAY be configurable. This
			time-out allows a Server to free-up resources in case of failure.
	3.5 Creating Test Sessions		3.2 Integrity Protection
	Test sessions creation follows the same procedure as defined in		Integrity protection of TWAMP follows the same procedure defined in
	section 3.5 of OWAMP [RFC4656].		section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC sent covers
			everything sent in a given direction between the previous HMAC (but
			not including it) and up to the beginning of the new HMAC. This
			way, once encryption is set up, each bit of the TWAMP-Control
			connection is authenticated by an HMAC exactly once.
	In order to distinguish the session as a two-way versus a one-way		Note that the Server-Start message (sent by a Server during the
	measurement session the first octet of the Request-Session command		initial control connection exchanges) does not terminate with an
	MUST be set to 5. Value of 5 indicates that this is a		HMAC field. Therefore, the HMAC in the first Accept-Session message
	Request-Session for a two-way metrics measurement session.		also covers the Server-Start message and includes the Start-Time
			field in the HMAC calculation.
	In TWAMP, the first octet is referred to as the Command Number, and		3.3 Value of the Accept Fields
	the Command Number is a recognized extension mechanism. Readers are
	encouraged to consult the TWAMP Command Number Registry to
	determine if there have been additional values assigned.
	If a TWAMP server receives an unexpected command number, it SHOULD		Accept values used in TWAMP are the same as the values defined in
	respond with the Accept field set to 3 (meaning "Some aspect of		section 3.3 of OWAMP [RFC4656].
	request is not supported") in the Server-Start message.
	In OWAMP, the Conf-Sender field is set to 1 when the		3.4 TWAMP Control Commands
	Request-Session message describes a task where the Server will
	configure a one-way test packet sender. Likewise, the
	Conf-Receiver field is set to 1 when the message describes the
	configuration for a Session-Receiver. In TWAMP, both endpoints
	perform in these roles, with the Session-Sender first sending and
	then receiving test packets. The Session-Reflector first receives
	the test packets, and returns each test packet to the
	Session-Sender as fast as possible.
	Both Conf-Sender field and Conf-Receiver field MUST be set to 0		TWAMP control commands conform to the rules defined in section 3.4
	since the Session-Reflector will both receive and send packets, and		of OWAMP [RFC4656]
	the roles are established according to which host initiates the TCP
	connection for control. The server MUST interpret any non-zero
	value as zero.
	The Session-Reflector in TWAMP does not process incoming test		The following commands are available for the Control-client:
	packets for performance metrics and consequently does not need to		Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server
	know the number of incoming packets and their timing schedule.		can send specific messages in response to the commands it receives
	Consequently the Number of Scheduled Slots and Number of Packets		(as described in the sections that follow).
	MUST be set to 0.
	The Sender Port is the UDP port from which TWAMP-Test packets will		Note that the OWAMP Request-Session command is replaced by the
	be sent and the port to which TWAMP-Test packets will be sent by		TWAMP Request-TW-Session command, and the Fetch-Session command
	the Session-Reflector (Session-Sender will use the same UDP port to		does not appear in TWAMP.
	send and receive packets). Receiver Port is the desired UDP port
	to which TWAMP test packets will be sent by the Session-Sender (the
	port where the Session-Reflector is asked to receive test packets).
	Receiver Port is also the UDP port from which TWAMP test packets
	will be sent by the Session-Reflector (Session-Reflector will use
	the same UDP port to send and receive packets).
	The Sender Address and Receiver Address fields contain,		3.5 Creating Test Sessions
	respectively, the sender and receiver addresses of the endpoints of
	the Internet path over which a TWAMP test session is requested.
	They MAY be set to 0, in which case the IP addresses used for the		Test sessions creation follows the same procedure as defined in
	Session-Sender to Session-Reflector Control Message exchange MUST		section 3.5 of OWAMP [RFC4656].
	be used in the test packets.
	The Session Identifier (SID) is as defined in OWAMP [RFC4656].		In TWAMP, the first octet is referred to as the Command Number, and
	Since the SID is always generated by the receiving side, the		the Command Number is a recognized extension mechanism. Readers are
	Session-Reflector determines the SID, and the SID in the		encouraged to consult the TWAMP-Control Command Number Registry to
	Request-Session message MUST be set to 0.		determine if there have been additional values assigned.
	The Start Time is as as defined in OWAMP [RFC4656].		The Command Number value of 5 indicates a Request-TW-Session
			Command, and the Server MUST interpret this command as a request
			for a two-way test session using the TWAMP-Test protocol.
	The Timeout is interpreted differently from the definition in OWAMP		If a TWAMP Server receives an unexpected command number, it MUST
	[RFC4656]. In TWAMP, Timeout is the interval that the		respond with the Accept field set to 3 (meaning "Some aspect of
	Session-Reflector MUST wait after receiving a Stop-Sessions		request is not supported") in the Accept-Session message. Command
	message. In case there are test packets still in transit, the		numbers that are Forbidden (and possibly numbers that are Reserved)
	Session Reflector MUST reflect them if they arrive within the		are unexpected.
	timeout interval following the reception of the Stop-Sessions
	message. The Session-Reflector MUST NOT reflect packets that are
	received beyond the timeout.
	Type-P descriptor is as defined in OWAMP [RFC4656]. The only		In OWAMP, the Conf-Sender field is set to 1 when the
	capability of this field is to set the Differentiated Services Code		Request-Session message describes a task where the Server will
	Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST		configure a one-way test packet sender. Likewise, the
	be used in test packets reflected by the Session-Reflector.		Conf-Receiver field is set to 1 when the message describes the
			configuration for a Session-Receiver. In TWAMP, both endpoints
			perform in these roles, with the Session-Sender first sending and
			then receiving test packets. The Session-Reflector first receives
			the test packets, and returns each test packet to the
			Session-Sender as fast as possible.
	Since there are no Schedule Slot Descriptions, the Request-Session		Both Conf-Sender field and Conf-Receiver field MUST be set to 0
	Message is completed by MBZ (Must Be Zero) and HMAC (Hash Message		since the Session-Reflector will both receive and send packets, and
	Authentication Code) fields. This completes one logical message,		the roles are established according to which host initiates the TCP
	referred to as the Request-Session Command.		connection for control. The server MUST interpret any non-zero
			value as an improperly formatted command, and MUST respond with the
			Accept field set to 3 (meaning "Some aspect of request is not
			supported") in the Accept-Session message.
	The Session-Reflector MUST respond to each Request-Session Command		The Session-Reflector in TWAMP does not process incoming test
	with an Accept-Message as defined in OWAMP [RFC4656]. When the		packets for performance metrics and consequently does not need to
	Accept Field = 0, the Port field confirms (repeats) the port to		know the number of incoming packets and their timing schedule.
	which TWAMP test packets are sent by the Session-Sender toward the		Consequently the Number of Scheduled Slots and Number of Packets
	Session-Reflector. In other words, the Port field indicates the		MUST be set to 0.
	port number where the Session-Reflector expects to receive packets
	from the Session-Sender.
	When the requested Receiver Port is not available (e.g., port in		The Sender Port is the UDP port from which TWAMP-Test packets will
	use), the Server at the Session-Reflector MAY suggest an alternate		be sent and the port to which TWAMP-Test packets will be sent by
	and available port for this session in the Port Field. The		the Session-Reflector (Session-Sender will use the same UDP port to
	Session-Sender either accepts the alternate port, or composes a new		send and receive packets). Receiver Port is the desired UDP port
	Session-Request message with suitable parameters. Otherwise, the		to which TWAMP test packets will be sent by the Session-Sender (the
	Server at the Session-Reflector uses the Accept Field to convey		port where the Session-Reflector is asked to receive test packets).
	other forms of session rejection or failure and MUST NOT suggest an		Receiver Port is also the UDP port from which TWAMP test packets
	alternate port. In this case the Port Field MUST be set to zero.		will be sent by the Session-Reflector (Session-Reflector will use
			the same UDP port to send and receive packets).
	3.6 Send Schedules		The Sender Address and Receiver Address fields contain,
			respectively, the sender and receiver addresses of the endpoints of
			the Internet path over which a TWAMP test session is requested.
			They MAY be set to 0, in which case the IP addresses used for the
			Control-Client to Server TWAMP-Control Message exchange MUST be
			used in the test packets.
	The Send Schedule for test packets defined in section 3.6 of OWAMP		The Session Identifier (SID) is as defined in OWAMP [RFC4656].
	[RFC4656] is not used in TWAMP. The Control-Client and		Since the SID is always generated by the receiving side, the Server
	Session-Sender MAY autonomously decide the Send Schedule. The		determines the SID, and the SID in the Request-TW-Session message
	Session-Reflector SHOULD return each test packet to the		MUST be set to 0.
	Session-Sender as quickly as possible.
	3.7 Starting Test Sessions		The Start Time is as as defined in OWAMP [RFC4656].
	The procedure and guidelines for Starting test sessions is the same		The Timeout is interpreted differently from the definition in OWAMP
	as defined in section 3.7 of OWAMP [RFC4656].		[RFC4656]. In TWAMP, Timeout is the interval that the
			Session-Reflector MUST wait after receiving a Stop-Sessions
			message. In case there are test packets still in transit, the
			Session Reflector MUST reflect them if they arrive within the
			timeout interval following the reception of the Stop-Sessions
			message. The Session-Reflector MUST NOT reflect packets that are
			received beyond the timeout.
	3.8 Stop-Sessions		Type-P descriptor is as defined in OWAMP [RFC4656]. The only
			capability of this field is to set the Differentiated Services Code
			Point (DSCP) as defined in [RFC2474]. The same value of DSCP MUST
			be used in test packets reflected by the Session-Reflector.
	The procedure and guidelines for Stopping test sessions is the same		Since there are no Schedule Slot Descriptions, the Request-TW-
	as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Session		Session Message is completed by MBZ (Must Be Zero) and HMAC (Hash
	command can only be issued by the Session-Sender. The Next SeqNo		Message Authentication Code) fields. This completes one logical
	and Number of Skip Ranges MUST be set to 0 and the message MUST NOT		message, referred to as the Request-TW-Session Command.
	contain any session description records or skip ranges. The
	message is terminated with a single block HMAC, to complete the
	Stop-Sessions Command.
	3.9 Fetch-Session		The Session-Reflector MUST respond to each Request-TW-Session
			Command with an Accept-Message as defined in OWAMP [RFC4656]. When
			the Accept Field = 0, the Port field confirms (repeats) the port to
			which TWAMP test packets are sent by the Session-Sender toward the
			Session-Reflector. In other words, the Port field indicates the
			port number where the Session-Reflector expects to receive packets
			from the Session-Sender.
	The purpose of TWAMP is measurement of two-way metrics. Two-way		When the requested Receiver Port is not available (e.g., port in
	measurements do not rely on packet level data collected by the		use), the Server at the Session-Reflector MAY suggest an alternate
	Session-Reflector such as sequence number, timestamp, and TTL. As		and available port for this session in the Port Field. The
	such the protocol does not require the retrieval of packet level		Session-Sender either accepts the alternate port, or composes a new
	data from the Server and the Fetch-Session command is not defined		Session-Request message with suitable parameters. Otherwise, the
	in TWAMP.		Server at the Session-Reflector uses the Accept Field to convey
			other forms of session rejection or failure and MUST NOT suggest an
			alternate port. In this case the Port Field MUST be set to zero.
	4. TWAMP Test		3.6 Send Schedules
	The TWAMP test protocol is similar to the OWAMP [RFC4656] test		The Send Schedule for test packets defined in section 3.6 of OWAMP
	protocol with the exception that the Session-Reflector transmits		[RFC4656] is not used in TWAMP. The Control-Client and
	test packets to the Session-Sender in response to each test packet		Session-Sender MAY autonomously decide the Send Schedule. The
	it receives. TWAMP defines two different test packet formats, one		Session-Reflector SHOULD return each test packet to the
	for packets transmitted by the Session-Sender and one for packets		Session-Sender as quickly as possible.
	transmitted by the Session-Reflector. As with OWAMP [RFC4656] test
	protocol there are three modes: unauthenticated, authenticated, and
	encrypted.
	4.1 Sender Behavior		3.7 Starting Test Sessions
	The sender behavior is determined by the configuration of the		The procedure and guidelines for Starting test sessions is the same
	Session-Sender and is not defined in this standard. Further, the		as defined in section 3.7 of OWAMP [RFC4656].
	Session-Reflector does not need to know the Session-Sender
	behaviour to the degree of detail as needed in OWAMP [RFC4656].		3.8 Stop-Sessions
	Additionally the Session-Sender collects and records the necessary
	information provided from the packets transmitted by the		The procedure and guidelines for Stopping test sessions is the same
	Session-Reflector for measuring two-way metrics. The information		as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Sessions
	recording based on the received packet by the Session-Sender is		command can only be issued by the Control-Client. The message MUST
	implementation dependent.		NOT contain any session description records or skip ranges. The
			message is terminated with a single block HMAC, to complete the
			Stop-Sessions Command. Since the TWAMP Stop-Sessions command does
			not convey SIDs, it applies to all sessions previously requested
			and started with a Start-Sessions command.
			Thus, the TWAMP Stop-Sessions command is constructed as follows:
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 3 | Accept | MBZ |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Number of Sessions |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MBZ (8 octets) |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			| HMAC (16 octets) |
			| |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			3.9 Fetch-Session
			The purpose of TWAMP is measurement of two-way metrics. Two-way
			measurement methods do not require packet level data to be
			collected by the Session-Reflector (such as sequence number,
			timestamp, and TTL) because this data is communicated in the
			"reflected" test packets. As such the protocol does not require
			the retrieval of packet level data from the Server and the OWAMP
			Fetch-Session command is not used in TWAMP.
			4. TWAMP Test
			The TWAMP test protocol is similar to the OWAMP [RFC4656] test
			protocol with the exception that the Session-Reflector transmits
			test packets to the Session-Sender in response to each test packet
			it receives. TWAMP defines two different test packet formats, one
			for packets transmitted by the Session-Sender and one for packets
			transmitted by the Session-Reflector. As with OWAMP [RFC4656] test
			protocol there are three modes: unauthenticated, authenticated, and
			encrypted.
			4.1 Sender Behavior
			The sender behavior is determined by the configuration of the
			Session-Sender and is not defined in this standard. Further, the
			Session-Reflector does not need to know the Session-Sender
			behaviour to the degree of detail as needed in OWAMP [RFC4656].
			Additionally the Session-Sender collects and records the necessary
			information provided from the packets transmitted by the
			Session-Reflector for measuring two-way metrics. The information
			recording based on the received packet by the Session-Sender is
			implementation dependent.
	4.1.1 Packet Timings		4.1.1 Packet Timings
	Since the Send Schedule is not communicated to the		Since the Send Schedule is not communicated to the
	Session-Reflector, there is no need for a standardized computation		Session-Reflector, there is no need for a standardized computation
	of packet timing.		of packet timing.
	Regardless of any scheduling delays, each packet that is actually		Regardless of any scheduling delays, each packet that is actually
	sent MUST have the best possible approximation of its real time of		sent MUST have the best possible approximation of its real time of
	departure as its timestamp (in the packet).		departure as its timestamp (in the packet).
	4.1.2 Packet Format and Content		4.1.2 Packet Format and Content
	The Session-Sender packet format and content follow the same		The Session-Sender packet format and content follow the same
	procedure and guidelines as defined in section 4.1.2 of OWAMP		procedure and guidelines as defined in section 4.1.2 of OWAMP
	[RFC4656] (with the exception of the reference to the Send		[RFC4656] (with the exception of the reference to the Send
	Schedule).		Schedule).
	4.2 Reflector Behavior		4.2 Reflector Behavior
	TWAMP requires the Session-Reflector to transmit a packet to the		TWAMP requires the Session-Reflector to transmit a packet to the
	Session-Sender in response to each packet it receives.		Session-Sender in response to each packet it receives.
	As packets are received the Session-Reflector will,		As packets are received the Session-Reflector will,
	- Timestamp the received packet. Each packet that is actually
	received MUST have the best possible approximation of its real
	time of arrival entered as its timestamp (in the packet).
	- In authenticated or encrypted mode, decrypt the first block (16		- Timestamp the received packet. Each packet that is actually
	octets) of the packet body.		received MUST have the best possible approximation of its real
			time of arrival entered as its timestamp (in the packet).
	- Copy the packet sequence number into the corresponding reflected		- In authenticated or encrypted mode, decrypt the appropriate
	packet to the Session-Sender.		sections of the packet body (first block (16 octets) for
			authenticated, 96 octets for encrypted), and then check
			integrity of sections covered by the HMAC.
	- Sender TTL value is extracted from the TTL/Hop Limit value of		- Copy the packet sequence number into the corresponding reflected
	received packets. Session-Reflector Implementations SHOULD		packet to the Session-Sender.
	fetch the TTL/Hop Limit value from the IP header of the packet,
	replacing the value of 255 set by the Session-Sender. If an
	implementation does not fetch the actual TTL value (the only
	good reason not to do so is an inability to access the TTL
	field of arriving packets), it MUST set the Sender TTL value as
	255.
	- Transmit a test packet to the Session-Sender in response to		- Sender TTL value is extracted from the TTL/Hop Limit value of
	every received packet. The response MUST be generated as		received packets. Session-Reflector Implementations SHOULD
	immediately as possible. The format and content of the test		fetch the TTL/Hop Limit value from the IP header of the packet,
	packet is defined in section 5.2.1. Prior to the transmission		replacing the value of 255 set by the Session-Sender. If an
	of the test packet, the Session-Reflector MUST enter the best		implementation does not fetch the actual TTL value (the only
	possible approximation of its actual sending time of as its		good reason not to do so is an inability to access the TTL
	Timestamp (in the packet). This permits the determination of		field of arriving packets), it MUST set the Sender TTL value as
	the elapsed time between the reception of the packet and its		255.
	transmission.
	- Packets not received within the Timeout are ignored by the		- In authenticated and encrypted modes, the HMAC MUST be
	Reflector. The Session-Reflector MUST NOT generate a test		calculated first, then the appropriate portion of the packet
	packet to the Session-Sender for packets that are ignored.		body is encrypted.
	4.2.1 TWAMP-Test Packet Format and Content		- Transmit a test packet to the Session-Sender in response to
			every received packet. The response MUST be generated as
			immediately as possible. The format and content of the test
			packet is defined in section 4.2.1. Prior to the transmission
			of the test packet, the Session-Reflector MUST enter the best
			possible approximation of its actual sending time of as its
			Timestamp (in the packet). This permits the determination of
			the elapsed time between the reception of the packet and its
			transmission.
	The Session-Reflector MUST transmit a packet to the Session-Sender		- Packets not received within the Timeout (following the Stop-
	in response to each packet received. The Session-Reflector SHOULD		Session command) MUST be ignored by the
	transmit the packets as immediately as possible. The		Reflector. The Session-Reflector MUST NOT generate a test
	Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6)		packet to the Session-Sender for packets that are ignored.
	in the UDP packet to 255.
	The test packet will have the necessary information for calculating		The possibility exists for Session-Sender failure during a session,
	two-way metrics by the Session-Sender. The format of the test		or the path between the Session-Sender and Session-Reflector may
	packet depends on the mode being used. The various formats of the		fail while a test session is in-progress. The Session-Reflector MAY
	packet are presented below.		discontinue any session which has been Started when no packet
			associated with that session has been received for REFWAIT seconds.
			The default value of REFWAIT SHALL be 900 seconds, and this waiting
			time MAY be configurable. This time-out allows a Session-Reflector
			to free-up resources in case of failure.
	For unauthenticated mode:		4.2.1 TWAMP-Test Packet Format and Content
	0 1 2 3		The Session-Reflector MUST transmit a packet to the Session-Sender
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		in response to each packet received. The Session-Reflector SHOULD
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		transmit the packets as immediately as possible. The
	| Sequence Number |		Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		in the UDP packet to 255.
	| Timestamp |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Error Estimate | MBZ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Receive Timestamp |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Timestamp |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Error Estimate | MBZ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender TTL | |
	+++++++++++++++++ |
	| |
	. .
	. Packet Padding .
	. .
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	For authenticated and encrypted modes:
	0 1 2 3		The test packet will have the necessary information for calculating
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		two-way metrics by the Session-Sender. The format of the test
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		packet depends on the mode being used. The various formats of the
	| Sequence Number |		packet are presented below.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MBZ (12 octets) |
	| |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Error Estimate | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| MBZ (6 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Receive Timestamp |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MBZ (8 octets) |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
	| Sender Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MBZ (12 octets) |
	| |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Timestamp |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Error Estimate | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| MBZ (6 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender TTL | |
	+++++++++++++++++ |
	| |
	| |
	| MBZ (15 octets) |
	+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
	| HMAC (16 octets) |
	| |
	| |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
	| |
	. .
	. Packet Padding .
	. .
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Sequence Number is the sequence number of the test packet according		For unauthenticated mode:
	to its transmit order.It starts with zero and is incremented by one
	for each subsequent packet. The Sequence Number generated by the
	Session-Reflector is independent from the sequence number of the
	arriving packets.
	Timestamp and Error Estimate are the Session-Reflector's transmit		0 1 2 3
	timestamp and error estimate for the reflected test packet,		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	respectively. The format of all timestamp and error estimate		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	fields follow the definition and formats defined by OWAMP[RFC4656].		| Sequence Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Timestamp |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Error Estimate | MBZ |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Receive Timestamp |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sender Sequence Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sender Timestamp |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sender Error Estimate | MBZ |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sender TTL | |
			+-+-+-+-+-+-+-+-+ +
			| |
			. .
			. Packet Padding .
			. .
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			For authenticated and encrypted modes:
	Sender Timestamp and Sender Error Estimate are exact copies of the		0 1 2 3
	timestamp and error estimate from the Session-Sender test packet		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	that corresponds to this test packet.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sequence Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MBZ (12 octets) |
			| |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Timestamp |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Error Estimate | |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
			| MBZ (6 octets) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Receive Timestamp |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MBZ (8 octets) |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sender Sequence Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MBZ (12 octets) |
			| |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sender Timestamp |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sender Error Estimate | |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
			| MBZ (6 octets) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sender TTL | |
			+-+-+-+-+-+-+-+-+ +
			| |
			| |
			| MBZ (15 octets) |
			+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
			| HMAC (16 octets) |
			| |
			| |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
			| |
			. .
			. Packet Padding .
			. .
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Sender TTL is 255 when transmitted by the Session Sender. Sender		Note that all Timestamps have the same format as OWAMP [RFC4656] as
	TTL is set to the Time To Live (or Hop Count) value of the received		follows:
	packet from the IP packet header when transmitted by the Session
	Reflector.
	Receive Timestamp is the time the test packet was received by the		0 1 2 3
	reflector. The difference between Timestamp and Receive Timestamp		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	is the amount of time the packet was in transition in the		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Session-Reflector. The Error Estimate associated with the		| Integer part of seconds |
	Timestamp field also applies to the Receive Timestamp.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Fractional part of seconds |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Sender Sequence Number is a copy of the Sequence Number of the		Sequence Number is the sequence number of the test packet according
	packet transmitted by the Session-Sender that caused the		to its transmit order. It starts with zero and is incremented by
	Session-Reflector to generate and send this test packet.		one for each subsequent packet. The Sequence Number generated by
			the Session-Reflector is independent from the sequence number of
			the arriving packets.
	Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in		Timestamp and Error Estimate are the Session-Reflector's transmit
	authenticated and encrypted modes. The encryption operation of		timestamp and error estimate for the reflected test packet,
	Session-Sender packet follow the same rules of Session-Sender		respectively. The format of all timestamp and error estimate
	packets as defined in OWAMP [RFC4656].		fields follow the definition and formats defined by OWAMP[RFC4656].
	The minimum data segment length is, therefore, 41 octets in		Sender Timestamp and Sender Error Estimate are exact copies of the
	unauthenticated mode, and 104 octets in both authenticated mode and		timestamp and error estimate from the Session-Sender test packet
	encrypted modes (with the implication that the later two modes will		that corresponds to this test packet.
	not fit in a single ATM cell).
	The Session-Reflector TWAMP-Test packet layout is the same in		Sender TTL is 255 when transmitted by the Session Sender. Sender
	authenticated and encrypted modes. The encryption operations are,		TTL is set to the Time To Live (or Hop Count) value of the received
	however, different. The difference is that in encrypted mode both		packet from the IP packet header when transmitted by the Session
	the sequence numbers and timestamps are encrypted to provide		Reflector.
	maximum data integrity protection while in authenticated mode the
	sequence numbers are encrypted and the timestamps are sent in clear
	text. Sending the timestamp in clear text in authenticated mode
	allows one to reduce the time between when a timestamp is obtained
	by a reflector and when the packet is reflected out. In encrypted
	mode, both the sender and reflector have to fetch the timestamp,
	encrypt it, and send it; in authenticated mode, the middle step is
	removed, potentially improving accuracy (the sequence number can be
	encrypted before the timestamp is fetched).
	In authenticated mode, the first block (16 octets) of each packet		Receive Timestamp is the time the test packet was received by the
	is encrypted using AES Electronic Cookbook (ECB) mode.		reflector. The difference between Timestamp and Receive Timestamp
			is the amount of time the packet was in transition in the
			Session-Reflector. The Error Estimate associated with the
			Timestamp field also applies to the Receive Timestamp.
	Obtaining the key, encryption method, and packet padding follows		Sender Sequence Number is a copy of the Sequence Number of the
	the same procedure as OWAMP as described below.		packet transmitted by the Session-Sender that caused the
	Similarly to each TWAMP-Control session, each TWAMP-Test session		Session-Reflector to generate and send this test packet.
	has two keys: an AES Session-key and an HMAC Session-key. However,
	there is a difference in how the keys are obtained: in the case of
	TWAMP-Control, the keys are generated by the client and
	communicated (as part of the Token) during connection setup as part
	of Set-Up-Response message; in the case of TWAMP-Test, described
	here, the keys are derived from the TWAMP-Control keys and the SID.
	The TWAMP-Test AES Session-key is obtained as follows: the		Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in
	TWAMP-Control AES Session-key (the same AES Session-key as is used		authenticated and encrypted modes. The encryption operation of
	for the corresponding TWAMP-Control session, where it is used in a		Session-Sender packet follow the same rules of Session-Sender
	different chaining mode) is encrypted, using AES, with the 16-octet		packets as defined in OWAMP [RFC4656].
	session identifier (SID) as the key; this is a single-block ECB
	encryption; its result is the TWAMP-Test AES Session-key to use in
	encrypting (and decrypting) the packets of the particular
	TWAMP-Test session. Note that all of TWAMP-Test AES Session-key,
	TWAMP-Control AES Session-key, and the SID are comprised of 16
	octets.
	The TWAMP-Test HMAC Session-key is obtained as follows: the		The minimum data segment length is, therefore, 41 octets in
	TWAMP-Control HMAC Session-key (the same HMAC Session-key as is		unauthenticated mode, and 104 octets in both authenticated mode and
	used for the corresponding TWAMP-Control session) is encrypted,		encrypted modes (with the implication that the later two modes will
	using AES, with the 16-octet session identifier (SID) as the key;		not fit in a single ATM cell).
	this is a two-block CBC encryption, always performed with IV=0; its
	result is the TWAMP-Test HMAC Session-key to use in authenticating
	the packets of the particular TWAMP-Test session. Note that all of
	TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are
	comprised of 32 octets, while the SID is 16 octets.
	ECB mode used for encrypting the first block of TWAMP-Test packets		The Session-Reflector TWAMP-Test packet layout is the same in
	in authenticated mode does not involve any actual chaining; this		authenticated and encrypted modes. The encryption operations are,
	way, lost, duplicated, or reordered packets do not cause problems		however, different. The difference is that in encrypted mode both
	with deciphering any packet in an TWAMP-Test session.		the sequence numbers and timestamps are encrypted to provide
			maximum data integrity protection while in authenticated mode the
			sequence numbers are encrypted and the timestamps are sent in clear
			text. Sending the timestamp in clear text in authenticated mode
			allows one to reduce the time between when a timestamp is obtained
			by a reflector and when the packet is reflected out. In encrypted
			mode, both the sender and reflector have to fetch the timestamp,
			encrypt it, and send it; in authenticated mode, the middle step is
			removed, potentially improving accuracy (the sequence number can be
			encrypted before the timestamp is fetched). Authenticated mode
			permits the timestamp to be fetched after a portion of the packet
			is encrypted. Thus, the main differences between authenticated mode
			and encrypted mode are the portions of the test packets that are
			covered by HMAC and encrypted.
	In encrypted mode, the first six blocks (96octets) are encrypted		In authenticated mode, the first block (16 octets) of each packet
	using AES CBC mode. The AES Session-key to use is obtained in the		is encrypted using AES Electronic Cookbook (ECB) mode.
	same way as the key for authenticated mode. Each TWAMP-Test packet
	is encrypted as a separate stream, with just one chaining
	operation; chaining does not span multiple packets so that lost,
	duplicated, or reordered packets do not cause problems. The
	initialization vector for the CBC encryption is a value with all
	bits equal to zero.
	Implementation note: Naturally, the key schedule for each		Obtaining the key, encryption method, and packet padding follows
	TWAMP-Test session MAY be set up only once per session, not once		the same procedure as OWAMP as described below.
	per packet.		Similarly to each TWAMP-Control session, each TWAMP-Test session
			has two keys: an AES Session-key and an HMAC Session-key. However,
			there is a difference in how the keys are obtained: in the case of
			TWAMP-Control, the keys are generated by the client and
			communicated (as part of the Token) during connection setup as part
			of Set-Up-Response message; in the case of TWAMP-Test, described
			here, the keys are derived from the TWAMP-Control keys and the SID.
	HMAC in TWAMP-Test only covers the part of the packet that is also		The TWAMP-Test AES Session-key is obtained as follows: the
	encrypted. So, in authenticated mode, HMAC covers the first block		TWAMP-Control AES Session-key (the same AES Session-key as is used
	(16 octets); in encrypted mode, HMAC covers two first blocks (32		for the corresponding TWAMP-Control session, where it is used in a
	octets). In TWAMP-Test HMAC is not encrypted (note that this is		different chaining mode) is encrypted, using AES, with the 16-octet
	different from TWAMP-Control, where encryption in stream mode is		session identifier (SID) as the key; this is a single-block ECB
	used, so everything including the HMAC blocks ends up being		encryption; its result is the TWAMP-Test AES Session-key to use in
	encrypted).		encrypting (and decrypting) the packets of the particular
			TWAMP-Test session. Note that all of TWAMP-Test AES Session-key,
			TWAMP-Control AES Session-key, and the SID are comprised of 16
			octets.
	In unauthenticated mode, no encryption or authentication is		The TWAMP-Test HMAC Session-key is obtained as follows: the
	applied.		TWAMP-Control HMAC Session-key (the same HMAC Session-key as is
			used for the corresponding TWAMP-Control session) is encrypted,
			using AES, with the 16-octet session identifier (SID) as the key;
			this is a two-block CBC encryption, always performed with IV=0; its
			result is the TWAMP-Test HMAC Session-key to use in authenticating
			the packets of the particular TWAMP-Test session. Note that all of
			TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are
			comprised of 32 octets, while the SID is 16 octets.
	Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be		ECB mode used for encrypting the first block of TWAMP-Test packets
	generated independently of any other pseudo-random numbers		in authenticated mode does not involve any actual chaining; this
	mentioned in this document). However, implementations MUST provide		way, lost, duplicated, or reordered packets do not cause problems
	a configuration parameter, an option, or a different means of		with deciphering any packet in an TWAMP-Test session.
	making Packet Padding consist of all zeros.
	5. Implementers Guide		In encrypted mode, the first six blocks (96octets) are encrypted
			using AES CBC mode. The AES Session-key to use is obtained in the
			same way as the key for authenticated mode. Each TWAMP-Test packet
			is encrypted as a separate stream, with just one chaining
			operation; chaining does not span multiple packets so that lost,
			duplicated, or reordered packets do not cause problems. The
			initialization vector for the CBC encryption is a value with all
			bits equal to zero.
	This section serves as guidance to implementers of TWAMP. Two		Implementation note: Naturally, the key schedule for each
	architectures are presented in this section for implementations		TWAMP-Test session MUST be set up at most once per session, not
	where two hosts play the subsystem roles of TWAMP. Although only		once per packet.
	two architectures are presented here the protocol does not require
	their use. Similar to OWAMP [RFC4656] TWAMP is designed with
	complete flexibility to allow different architectures that suite
	multiple system requirements.
	5.1 Complete TWAMP		HMAC in TWAMP-Test only covers the part of the packet that is also
			encrypted. So, in authenticated mode, HMAC covers the first block
			(16 octets); in encrypted mode, HMAC covers the first six blocks
			(96 octets). In TWAMP-Test HMAC is not encrypted (note that this
			is different from TWAMP-Control, where encryption in stream mode is
			used, so everything including the HMAC blocks ends up being
			encrypted).
	In this example the roles of Control-Client and Session-Sender are		In unauthenticated mode, no encryption or authentication is
	implemented in one host referred to as the controller and the roles		applied.
	of Server and Session-Reflector are implemented in another host
	referred to as the responder.
	controller responder		Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
	+-----------------+ +-------------------+		generated independently of any other pseudo-random numbers
	| Control-Client |<--TWAMP-Control-->| Server |		mentioned in this document). However, implementations MUST provide
	| | | |		a configuration parameter, an option, or a different means of
	| Session-Sender |<--TWAMP-Test----->| Session-Reflector |		making Packet Padding consist of all zeros.
	+-----------------+ +-------------------+
	This example provides an architecture that supports the full TWAMP		5. Implementers Guide
	standard. The controller establishes the test session with the
	responder through the TWAMP-Control protocol. After the session is
	established the controller transmits test packets to the responder.
	The responder follows the Session-Reflctor behavior of TWAMP as
	described in section 4.2.
	5.2 TWAMP Light		This section serves as guidance to implementers of TWAMP. The
			example architecture presented here is not a requirement. Similar
			to OWAMP [RFC4656], TWAMP is designed with enough flexibility to
			allow different architectures that suit multiple system
			requirements.
	In this example the roles of Control-Client, Server, and		In this example the roles of Control-Client and Session-Sender are
	Session-Sender are implemented in one host referred to as the		implemented in one host referred to as the controller and the roles
	controller and the role of Session-Reflector is implemented in		of Server and Session-Reflector are implemented in another host
	another host referred to as the responder.		referred to as the responder.
	controller responder		controller responder
	+-----------------+ +-------------------+		+-----------------+ +-------------------+
	| Server |<----------------->| |		| Control-Client |<--TWAMP-Control-->| Server |
	| Control-Client | | Session-Reflector |		| | | |
	| Session-Sender |<--TWAMP-Test----->| |		| Session-Sender |<--TWAMP-Test----->| Session-Reflector |
	+-----------------+ +-------------------+		+-----------------+ +-------------------+
	This example provides a simple architecture for responders where		This example provides an architecture that supports the full TWAMP
	their role will be to simply act as light test points in the		standard. The controller establishes the test session with the
	network. The controller establishes the test session with the		responder through the TWAMP-Control protocol. After the session is
	Server through non-standard means. After the session is		established the controller transmits test packets to the responder.
	established the controller transmits test packets to the responder.		The responder follows the Session-Reflector behavior of TWAMP as
	The responder follows the Session-Reflector behavior of TWAMP as		described in section 4.2.
	described in section 4.2 with the following exceptions.
	In the case of TWAMP Light, the Session-Reflector does not		Appendix I provides an example for purely informational purposes.
	necessarily have knowledge of the session state. IF the		It suggests an incremental path to adopting TWAMP, by implementing
	Session-Reflector does not have knowledge of the session state,		the TWAMP-Test protocol first.
	THEN the Session-Reflector MUST copy the Sequence Number of the
	received packet to the Sequence Number field of the reflected
	packet. The controller receives the reflected test packets and
	collects two-way metrics. This architecture allows for collection
	of two-way metrics.
	This example eliminates the need for the TWAMP-Control protocol and		6. Security Considerations
	assumes that the Session-Reflector is configured and communicates
	its configuration with the Server through non-standard means. The
	Session-Reflector simply reflects the incoming packets back to the
	controller while copying the necessary information and generating
	sequence number and timestamp values per section 4.2.1.
	6. Security Considerations		Fundamentally TWAMP and OWAMP use the same protocol for
			establishment of Control and Test procedures. The main difference
			between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP
			vs. the Session-Receiver behavior in OWAMP. This difference in
			behavior does not introduce any known security vulnerabilities that
			are not already addressed by the security features of OWAMP. The
			entire security considerations of OWAMP [RFC4656] applies to TWAMP.
	Fundamentally TWAMP and OWAMP use the same protocol for		7. Acknowledgements
	establishment of Control and Test procedures. The main difference
	between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP
	vs. the Session-Receiver behavior in OWAMP. This difference in
	behavior does not introduce any known security vulnerabilities that
	are not already addressed by the security features of OWAMP. The
	entire security considerations of OWAMP [RFC4656] applies to TWAMP.
	The only area where TWAMP may introduce new security considerations		We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,
	is the TWAMP Light version described above. The non-standard means		Stanislav Shalunov, Matt Zekauskas, Walt Steverson, Jeff Boote, and
	to control the responder and establish test sessions SHOULD offer		Murtaza Chiba for their comments, suggestions, reviews, helpful
	the features listed below.		discussion and proof-reading.
	The non-standard responder control protocol SHOULD have an		8. IANA Considerations
	authenticated mode of operation. The responder SHOULD be
	configurable to accept only authenticated control sessions.
	The non-standard responder control protocol SHOULD have a means to		IANA has allocated a well-known TCP port number (861) for the
	activate the authenticated and encrypted modes of the TWAMP-Test		OWAMP-Control part of the OWAMP [RFC4656] protocol.
	protocol.		...
			owamp-control 861/tcp OWAMP-Control
			owamp-control 861/udp OWAMP-Control
			# [RFC4656]
			# 862-872 Unassigned
	7. Acknowledgements		IANA is requested to allocate a well-known TCP/UDP port number for
			the TWAMP-Control protocol. It would be ideal if the port number
			assignment was adjacent to the OWAMP assignment. The recommended
			Keyword for this entry is "twamp-control" and the Description is
			"Two-way Active Measurement Protocol (TWAMP) Control".
	We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,		During final editing, port N in section 3.1 should be replaced with
	Stanislav Shalunov, Matt Zekauskas, Walt Steverson and Jeff Boote		the assigned port number.
	for their comments, suggestions, reviews, helpful discussion and
	proof-reading.
	8. IANA Considerations		Since TWAMP adds an additional Control command to the OWAMP-Control
			specification, and describes behavior when this control command is
			used, this memo requests creation an IANA registry for the TWAMP
			Command Number field. The field is not explicitly named in
			[RFC4656] but is called out for each command. This field is a
			recognized extension mechanism for TWAMP.
	IANA has allocated a well-known TCP port number (861) for the		8.1 Registry Specification
	OWAMP-Control part of the OWAMP [RFC4656] protocol.
	...
	owamp-control 861/tcp OWAMP-Control
	owamp-control 861/udp OWAMP-Control
	# [RFC4656]
	# 862-872 Unassigned
	IANA is requested to allocate a well-known TCP/UDP port number for		IANA will create an TWAMP-Control Command Number registry. TWAMP-
	the TWAMP-Control protocol. It would be ideal if the port number		Control commands are specified by the first octet in OWAMP-Control
	assignment was adjacent to the OWAMP assignment. The recommended		messages as shown in section 3.5 of [RFC4656], and modified by this
	Keyword for this entry is "twamp-control" and the Description is		document. Thus this registry may contain sixteen possible values.
	"Two-way Active Measurement Protocol (TWAMP) Control".
	During final editing, port N in section 3.1 should be replaced with		8.2 Registry Management
	the assigned port number.
	Since TWAMP adds an additional Control command to the OWAMP-Control		Because the registry may only contain sixteen values, and because
	specification, and describes behavior when this control command is		OWAMP and TWAMP are IETF protocols, this registry must only be
	used, this memo requests creation an IANA registry for the TWAMP		updated by "IETF Consensus" as specified in [RFC2434] -- an RFC
	Command Number field. The field is not explicitly named in		documenting the use that is approved by the IESG. We expect that
	[RFC4656] but is called out for each command. This field is a		new values will be assigned as monotonically increasing integers in
	recognized extension mechanism for TWAMP.		the range [0-15], unless there is a good reason to do otherwise.
	8.1 Registry Specification		8.3 Experimental Numbers
	IANA will create an TWAMP-Control Command registry. TWAMP-Control		[RFC3692] recommends allocating an appropriate number of values for
	commands are specified by the first octet in OWAMP-Control messages		experimentation and testing. It is not clear to the authors
	as shown in section 3.4 of [RFC4656], and modified by this		exactly how many numbers might be useful in this space, nor if it
	document. Thus this registry may contain sixteen possible values.		would be useful that they were easily distinguishable or at the
			"high end" of the number range. Two might be useful, say one for
			session control, and one for session fetch. On the other hand, a
			single number would allow for unlimited extension, because the
			format of the rest of the message could be tailored, with
			allocation of other numbers done once usefulness has been proven.
			Thus, this document will allocate one number, the next sequential
			number 6, as designated for experimentation and testing.
	8.2 Registry Management		8.4 Initial Registry Contents
	Because the registry may only contain sixteen values, and because		TWAMP-Control Command Number Registry
	OWAMP and TWAMP are IETF protocols, this registry must only be
	updated by "IETF Consensus" as specified in [RFC2434] -- an RFC
	documenting the use that is approved by the IESG. We expect that
	new values will be assigned as monotonically increasing integers in
	the range [0-15], unless there is a good reason to do otherwise.
	8.3 Experimental Numbers		Value Description Semantics Definition
			0 Reserved
			1 Forbidden
			2 Start-Sessions RFC4656, Section 3.7
			3 Stop-Sessions RFC4656, Section 3.8
			4 Reserved
			5 Request-TW-Session this document, Section 3.5
			6 Experimentation undefined, see Section 8.3.
	[RFC3692] recommends allocating an appropriate number of values for		9. Internationalization Considerations
	experimentation and testing. It is not clear to the authors
	exactly how many might be useful in this space, nor if it would be
	useful that they were easily distinguishable or at the "high end"
	of the number range. Two might be useful, say one for session
	control, and one for session fetch. On the other hand, a single
	number would allow for unlimited extension, because the format of
	the rest of the message could be tailored, with allocation of other
	numbers done once usefulness has been proven. Thus, this document
	will allocate one number, the next sequential number 6, as
	designated for experimentation and testing.
	8.4 Initial Registry Contents		The protocol does not carry any information in a natural language,
			with the possible exception of the KeyID in TWAMP-Control, which is
			encoded in UTF-8.
	TWAMP-Control Command Registry		10. APPENDIX I - TWAMP Light (Informative)
	Value Description Semantics Definition		In this example the roles of Control-Client, Server, and
	0 Reserved		Session-Sender are implemented in one host referred to as the
	1 Forbidden		controller and the role of Session-Reflector is implemented in
	2 Start-Sessions RFC4656, Section 3.7		another host referred to as the responder.
	3 Stop-Sessions RFC4656, Section 3.8
	4 Fetch-Session RFC4656, Section 3.9
	5 Request-TW-Session this document, Section 3.5
	6 Experimentation undefined, see Section 8.3.
	9. Internationalization Considerations		controller responder
			+-----------------+ +-------------------+
			| Server |<----------------->| |
			| Control-Client | | Session-Reflector |
			| Session-Sender |<--TWAMP-Test----->| |
			+-----------------+ +-------------------+
	The protocol does not carry any information in a natural language,		This example provides a simple architecture for responders where
	with the possible exception of the KeyID in TWAMP-Control, which is		their role will be to simply act as light test points in the
	encoded in UTF-8.		network. The controller establishes the test session with the
			Server through non-standard means. After the session is
			established the controller transmits test packets to the responder.
			The responder follows the Session-Reflector behavior of TWAMP as
			described in section 4.2 with the following exceptions.
	10. References		In the case of TWAMP Light, the Session-Reflector does not
			necessarily have knowledge of the session state. IF the
			Session-Reflector does not have knowledge of the session state,
			THEN the Session-Reflector MUST copy the Sequence Number of the
			received packet to the Sequence Number field of the reflected
			packet. The controller receives the reflected test packets and
			collects two-way metrics. This architecture allows for collection
			of two-way metrics.
	10.1 Normative References		This example eliminates the need for the TWAMP-Control protocol and
			assumes that the Session-Reflector is configured and communicates
			its configuration with the Server through non-standard means. The
			Session-Reflector simply reflects the incoming packets back to the
			controller while copying the necessary information and generating
			sequence number and timestamp values per section 4.2.1.
			TWAMP Light introduces some additional security considerations. The
			non-standard means to control the responder and establish test
			sessions SHOULD offer the features listed below.
	[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,		The non-standard responder control protocol SHOULD have an
	Zekauskas, M., "A One-way Active Measurement Protocol		authenticated mode of operation. The responder SHOULD be
	(OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004.		configurable to accept only authenticated control sessions.
	[RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A		The non-standard responder control protocol SHOULD have a means to
	Round-Trip Delay Metric for IPPM". RFC 2681, STD 1,		activate the authenticated and encrypted modes of the TWAMP-Test
	September 1999.		protocol.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		11. References
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		11.1 Normative References
	Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,
	December 1998.
	[RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing		[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
	an IANA Considerations Section in RFCs, RFC 2474,		Zekauskas, M., "A One-way Active Measurement Protocol
	October 1998.		(OWAMP)", RFC 4656, October 2004.
	10.2 Informative References		[RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A
			Round-Trip Delay Metric for IPPM". RFC 2681, STD 1,
			September 1999.
	[RFC3692] Narten, T., Assigning Experimental and Testing Numbers		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Considered Useful, RFC 3692, January 2004.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	Authors' Addresses		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
			Definition of the Differentiated Services Field (DS
			Field) in the IPv4 and IPv6 Headers", RFC 2474,
			December 1998.
	Kaynam Hedayat		[RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing
	Brix Networks		an IANA Considerations Section in RFCs, RFC 2434,
	285 Mill Road		October 1998.
	Chelmsford, MA 01824
	USA
	EMail: khedayat@brixnet.com		11.2 Informative References
	URI: http://www.brixnet.com/
	Roman M. Krzanowski, Ph.D.
	Verizon
	500 Westchester Ave.
	White Plains, NY
	USA
	EMail: roman.krzanowski@verizon.com		[RFC3692] Narten, T., Assigning Experimental and Testing Numbers
	URI: http://www.verizon.com/		Considered Useful, RFC 3692, January 2004.
	Al Morton		Authors' Addresses
	AT&T Labs
	Room D3 - 3C06
	200 Laurel Ave. South
	Middletown, NJ 07748
	USA
	Phone +1 732 420 1571		Kaynam Hedayat
	EMail: acmorton@att.com		Brix Networks
	URI: http://home.comcast.net/~acmacm/		285 Mill Road
			Chelmsford, MA 01824
			USA
			EMail: khedayat@brixnet.com
			URI: http://www.brixnet.com/
	Kiho Yum		Roman M. Krzanowski, Ph.D.
	Juniper Networks		Verizon
	1194 Mathilda Ave.		500 Westchester Ave.
	Sunnyvale, CA		White Plains, NY
	USA		USA
			EMail: roman.krzanowski@verizon.com
			URI: http://www.verizon.com/
	EMail: kyum@juniper.net		Al Morton
	URI: http://www.juniper.com/		AT&T Labs
			Room D3 - 3C06
			200 Laurel Ave. South
			Middletown, NJ 07748
			USA
			Phone +1 732 420 1571
			EMail: acmorton@att.com
			URI: http://home.comcast.net/~acmacm/
	Jozef Z. Babiarz		Kiho Yum
	Nortel Networks		Juniper Networks
	3500 Carling Avenue		1194 Mathilda Ave.
	Ottawa, Ont K2H 8E9		Sunnyvale, CA
	Canada		USA
			EMail: kyum@juniper.net
			URI: http://www.juniper.com/
	Email: babiarz@nortel.com		Jozef Z. Babiarz
	URI: http://www.nortel.com/		Nortel Networks
			3500 Carling Avenue
			Ottawa, Ont K2H 8E9
			Canada
			Email: babiarz@nortel.com
			URI: http://www.nortel.com/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE		WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.		FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology described		to pertain to the implementation or use of the technology described
	in this document or the extent to which any license under such		in this document or the extent to which any license under such
	rights might or might not be available; nor does it represent that		rights might or might not be available; nor does it represent that
	it has made any independent effort to identify any such rights.		it has made any independent effort to identify any such rights.
	Information on the procedures with respect to rights in RFC		Information on the procedures with respect to rights in RFC
	documents can be found in BCP 78 and BCP 79.		documents can be found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use
	of such proprietary rights by implementers or users of this		of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.		at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is provided by the IETF		Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).		Administrative Support Activity (IASA).
End of changes. 170 change blocks.
	795 lines changed or deleted		899 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/