< draft-ietf-ippm-twamp-01.txt		draft-ietf-ippm-twamp-02.txt >
	J. Babiarz		K. Hedayat
	Internet Draft Nortel Networks		Internet Draft Brix Networks
	Expires: December 2006 K. Hedayat		Expires: April 2007 R. Krzanowski
	Brix Networks
	R. Krzanowski
	Verizon		Verizon
	Kiho Yum		K. Yum
	Juniper Networks		Juniper Networks
	June 2006		A. Morton
			AT&T Labs
			J. Babiarz
			Nortel Networks
			November 2006
	A Two-way Active Measurement Protocol (TWAMP)		A Two-way Active Measurement Protocol (TWAMP)
	draft-ietf-ippm-twamp-01		draft-ietf-ippm-twamp-02
	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
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 6 ¶
	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 Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The IPPM One-way Active Measurement Protocol [OWAMP] provides a
	common protocol for measuring one-way metrics between network		The IPPM One-way Active Measurement Protocol [RFC4656] (OWAMP)
	devices. OWAMP [OWAMP] can be used in both directions		provides a common protocol for measuring one-way metrics between
	independently to measure one-way metrics in both directions between		network devices. OWAMP can be used bi-directionally to measure
	two network elements. However, it does not accommodate round-trip		one-way metrics in both directions between two network elements.
	or two-way measurements. This draft proposes a Two-way Active		However, it does not accommodate round-trip or two-way
	Measurement Protocol, based on the One-way Active Measurement		measurements. This memo specifies a Two-way Active Measurement
	Protocol [OWAMP], that will accommodate two-way or round-trip		Protocol (TWAMP), based on the OWAMP, that adds two-way or
	measurements.		round-trip measurement capabilities. The TWAMP measurement
			architecture is usually comprised of two hosts with specific roles,
			and this allows for some protocol simplifications, making it an
			attractive alternative in some circumstances.
	Table of Contents		Table of Contents
	1. Introduction..................................................2		1. Introduction..................................................3
	2. Terminology...................................................3		1.1 Relationship of Test and Control Protocols................3
	3. Protocol Overview.............................................3		1.2 Logical Model.............................................3
	3.1 Relationship of Test and Control Protocols................3		2. Protocol Overview.............................................5
	3.2 Logical Model.............................................3		3. TWAMP Control.................................................5
	4. TWAMP Control.................................................5		3.1 Connection Setup..........................................5
	4.1 Connection Setup..........................................6		3.2 Integrity Protection......................................6
	4.2 TWAMP Control Commands....................................6		3.3 Value of the Accept Fields................................6
	4.3 Creating Test Sessions....................................6		3.4 TWAMP Control Commands....................................6
	4.4 Send Schedules............................................6		3.5 Creating Test Sessions....................................6
	4.5 Starting Test Sessions....................................6		3.6 Send Schedules............................................8
	4.6 Stop-Sessions.............................................6		3.7 Starting Test Sessions....................................8
	4.7 Fetch-Session.............................................6		3.8 Stop-Sessions.............................................8
	5. TWAMP Test....................................................7		3.9 Fetch-Session.............................................8
	5.1 Sender Behavior...........................................7		4. TWAMP Test....................................................8
	5.2 Reflector Behavior........................................8		4.1 Sender Behavior...........................................9
	6. Implementers Guide...........................................12		4.2 Reflector Behavior........................................9
	6.1 Complete TWAMP...........................................12		5. Implementers Guide...........................................14
	6.2 TWAMP Light..............................................12		5.1 Complete TWAMP...........................................14
	7. Security Considerations......................................13		5.2 TWAMP Light..............................................14
	8. IANA Considerations..........................................13		6. Security Considerations......................................15
	9. References.................................................1413		7. Acknowledgements.............................................15
	9.1 Normative References.....................................14		8. IANA Considerations..........................................15
			9. Internationalization Considerations..........................16
			10. References..................................................16
			10.1 Normative References....................................16
	1. Introduction		1. Introduction
	The IETF IP Performance Metrics (IPPM) working group has proposed		The IETF IP Performance Metrics (IPPM) working group has completed
	the draft standard for round-trip delay [RFC2681] metric. IPPM has		a draft standard for the round-trip delay [RFC2681] metric. IPPM
	also proposed a new protocol for establishment of sessions for		has also completed a protocol for the control and collection of
	measurement of one-way metrics [OWAMP]. Two-way Active Measurement		one-way measurements, the One-way Active Measurement Protocol
	Protocol uses the methodology and architecture of OWAMP [OWAMP] to		(OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip
	define an open protocol for measurement of two-way or round-trip		or two-way measurements.
	metrics. Henceforth in this document the term two-way also
	signifies round-trip.
	2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119
	[RFC2681] and indicate requirement levels for compliant
	implementations.
	3. Protocol Overview
	The Two-way Active Measurement Protocol is an open protocol for
	measurement of two-way metrics. It is based on OWAMP [OWAMP] and
	adheres to its overall architecture and design. The protocol
	defined in this document defines extensions and changes to OWAMP
	[OWAMP] as follows:
	- Define a new logical entity, Session-Reflector, in place of the
	Session-Receiver.
	- Define the Session-Reflector behavior in place of the
	Session-Receiver behavior of OWAMP [OWAMP].
	- Define a new test packet format for packets transmitted from the		Two-way measurements are common in IP networks, primarily because
	Session-Reflector to Session-Sender.		time accuracy is less demanding for round-trip delay, and
			measurement support at the remote end may be limited to a simple
			echo function. This memo specifies the Two-way Active Measurement
			Protocol, or TWAMP. TWAMP uses the methodology and architecture of
			OWAMP [RFC4656] to define an open protocol for measurement of
			two-way or round-trip metrics (henceforth in this document the term
			two-way also signifies round-trip). The TWAMP measurement
			architecture is usually comprised of only two hosts with specific
			roles, and this allows for some protocol simplifications, making it
			an attractive alternative in some circumstances.
	- Presence of the Fetch client in the system and the support of		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	the Fetch command by the Server are optional.		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			RFC 2119 [RFC2119].
	3.1 Relationship of Test and Control Protocols		1.1 Relationship of Test and Control Protocols
	Similar to OWAMP [OWAMP], 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 [OWAMP].		protocols is as defined in section 1.1 of OWAMP [RFC4656].
			1.2 Logical Model
	3.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 [OWAMP] with the following exceptions:		section 1.2 of OWAMP [RFC4656] with the following exceptions:
	- Session-Receiver is called the Session-Reflector in the TWAMP		- The Session-Receiver is called the Session-Reflector in the
	architecture.		TWAMP architecture. The Session-Reflector has the capability
			to create and send a measurement packet when it receives a
			measurement packet. Unlike the Session-Receiver, the
			Session-Reflector does not collect any packet information.
	- The presence of the Fetch-Client is optional since two-way		- The Server is an end system that manages one or more TWAMP
	measurements do not require data retrieval from the		sessions, and is capable of configuring per-session state in
	Session-Reflector. Consequently the support for the Fetch		the end-points. However, a Server associated with a
	command is optional by the Server. However, the Server may		Session-Reflector would not have the capability to return the
	choose to implement the Fetch-Client and support the		results of a test session, and this is a difference from OWAMP.
	Fetch-Command to enable both one-way and two-way measurements
	in the same session. This is explained in more detail in
	section 4.7.
	Several examples of possible relationship scenarios between these		- The Fetch-Client entity does not exist in the TWAMP
	roles are presented below. In the first example different logical		architecture, as the Session-Reflector does not collect any
	roles are played on different hosts.		packet information to be fetched. Consequently there is no
			need for the Fetch-Client.
			An example of possible relationship scenarios between these roles
			are presented below. In this example different logical roles are
			played on different hosts. Unlabeled links in the figure are
			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
	+----------------+ +-----------------+
	| Control-Client | | Fetch-Client |
	+----------------+ +-----------------+
	Second example is similar to the first example without the
	Fetch-Client. In this example only two-way metrics are collected.
	+----------------+ +-------------------+
	| Session-Sender |<--TWAMP-Test-->| Session-Reflector |
	+----------------+ +-------------------+
	^ ^
	| |
	| |
	| |
	| +----------------+ |
	| | Server |<-----------------+
	| +----------------+		| +----------------+
	| ^		| ^
	| |		| |
	| TWAMP-Control		| TWAMP-Control
	| |		| |
	v V		v v
	+----------------+		+----------------+
	| Control-Client |		| Control-Client |
	+----------------+		+----------------+
	Similar to OWAMP [OWAMP] different logical roles can be played by		As in OWAMP [RFC4656], different logical roles can be played by the
	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 role of Control-Client,		actually two hosts: one playing the roles of Control-Client and
	Fetch-Client, Session-Sender, and Server, and the other playing the		Session-Sender, and the other playing the roles of Server and
	role of Session-Reflector. This is the third example shown below.		Session-Reflector. This example is shown below.
	+-----------------+ +-------------------+		+-----------------+ +-------------------+
	| Server |<------------------| |		| Control-Client |<--TWAMP Control-->| Server |
	| Control-Client | | Session-Reflector |		| | | |
	| Session-Sender |<--TWAMP-Test----->| |		| Session-Sender |<--TWAMP-Test----->| Session-Reflector |
	+-----------------+ +-------------------+		+-----------------+ +-------------------+
	Additionally, following the guidelines of OWAMP [OWAMP], TWAMP has		Additionally, following the guidelines of OWAMP [RFC4656], TWAMP
	been defined to allow for small test packets that would fit inside		has been defined to allow for small test packets that would fit
	the payload of a single ATM cell (only in unauthenticated mode).		inside the payload of a single ATM cell (only in unauthenticated
			mode).
	4. TWAMP Control		2. Protocol Overview
	All TWAMP Control messages are similar in format to and follow the		The Two-way Active Measurement Protocol is an open protocol for
	same guidelines defined in section 3 of OWAMP [OWAMP].		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:
	4.1 Connection Setup		- Define a new logical entity, Session-Reflector, in place of the
			Session-Receiver.
			- Define the Session-Reflector behavior in place of the
			Session-Receiver behavior of OWAMP [RFC4656].
			- Define a new test packet format for packets transmitted from the
			Session-Reflector to Session-Sender.
			- Fetch client does not exist in the TWAMP architecture.
			3. TWAMP Control
			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. All OWAMP
			[RFC4656] Control messages except for the Fetch-Session command
			apply to TWAMP.
			3.1 Connection Setup
	Connection establishment of TWAMP follows the same procedure		Connection establishment of TWAMP follows the same procedure
	defined in section 3.1 of OWAMP [OWAMP].		defined in section 3.1 of OWAMP [RFC4656]. 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.
	4.2 TWAMP Control Commands		3.2 Integrity Protection
	TWAMP control commands are as defined in section 3.3 of OWAMP		Integrity protection of TWAMP follows the same procedure defined in
	[OWAMP] except for the optional requirement of the Fetch-Session		section 3.2 of OWAMP [RFC4656].
	command.
	4.3 Creating Test Sessions		3.3 Value of the Accept Fields
			Accept values used in TWAMP are the same as the values defined in
			section 3.3 of OWAMP [RFC4656].
			3.4 TWAMP Control Commands
			TWAMP control commands are as defined in section 3.4 of OWAMP
			[RFC4656] except that the Fetch-Session command does not apply to
			TWAMP.
			3.5 Creating Test Sessions
	Test sessions creation follows the same procedure as defined in		Test sessions creation follows the same procedure as defined in
	section 3.4 of OWAMP [OWAMP]. In order to distinguish the session		section 3.5 of OWAMP [RFC4656].
	as a two-way versus a one-way measurement session the first octet
	of the Request-Session command MUST be set to 5. Value of 5
	indicates that this is a Request-Session for a two-way metrics
	measurement session.
	4.4 Send Schedules		In order to distinguish the session as a two-way versus a one-way
			measurement session the first octet of the Request-Session command
			MUST be set to 5. Value of 5 indicates that this is a
			Request-Session for a two-way metrics measurement session.
	Send schedule of test packets follow the same procedure and		In OWAMP, the Conf-Sender field is set to 1 when the
	guidelines as defined in section 3.5 of OWAMP [OWAMP].		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.
	4.5 Starting Test Sessions		Both Conf-Sender and Conf-Receiver MUST be set to 0 since the
			Session-Reflector will both receive and send packets, and the roles
			are established according to which host initiates the TCP
			connection for control. The server MUST interpret any non-zero
			value as zero.
	Starting test sessions follow the same procedure and guidelines as		The Session-Reflector in TWAMP does not process incoming test
	defined in section 3.6 of OWAMP [OWAMP].		packets for performance metrics and consequently does not need to
			know the number of incoming packets and their timing schedule.
			Consequently the Number of Scheduled Slots and Number of Packets
			MUST be set to 0.
	4.6 Stop-Sessions		The Sender Port is the UDP port from which TWAMP-Test packets will
			be sent. Receiver Port is the UDP port to which TWAMP test packets
			are reflected by the Session-Reflector (the port where the
			Session-Sender wants to receive test packets).
	Stopping test sessions follow the same procedure and guidelines as		The Sender Address and Receiver Address fields contain,
	defined in section 3.7 of OWAMP [OWAMP].		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
			Session-Sender to Session-Reflector Control Message exchange MUST
			be used in the test packets.
			The SID is as defined in OWAMP [RFC4656]. Since the SID is always
			generated by the receiving side, the Session-Reflector determines
			the SID, and the SID in the Request-Session message MUST be set to
			0.
			The Start Time is as as defined in OWAMP [RFC4656].
			The Timeout is interpreted differently from the definition in OWAMP
			[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.
			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 DCSP MUST
			be used in test packets reflected by the Session-Reflector.
			Since there are no Schedule Slot Descriptions, the Request-Session
			Message is followed by HMAC. This completes one logical message,
			referred to as the Request-Session Command.
			The Session-Reflector MUST respond to each Request-Session Command
			with an Accept-Message as defined in OWAMP [RFC4656]. The Port is
			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.
			3.6 Send Schedules
			The Send Schedule for test packets defined in section 3.6 of OWAMP
			[RFC4656] is not used in TWAMP. The Control-Client and
			Session-Sender MAY autonomously decide the Send Schedule. The
			Session-Reflector SHOULD return each test packet to the
			Session-Sender as quickly as possible.
			3.7 Starting Test Sessions
			The procedure and guidelines for Starting test sessions is the same
			as defined in section 3.7 of OWAMP [RFC4656].
			3.8 Stop-Sessions
			The procedure and guidelines for Stopping test sessions is the same
			as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Session
			command can only be issued by the Session-Sender. The Next SeqNo
			and Number of Skip Ranges MUST be set to 0 and the message MUST NOT
			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
	4.7 Fetch-Session
	The purpose of TWAMP is measurement of two-way metrics. Two-way		The purpose of TWAMP is measurement of two-way metrics. Two-way
	measurements do not rely on packet level data collected by the		measurements do not rely on packet level data collected by the
	Session-Reflector such as sequence number, timestamp, and TTL. As		Session-Reflector such as sequence number, timestamp, and TTL. As
	such the protocol does not require the retrieval of packet level		such the protocol does not require the retrieval of packet level
	data from the Server and the Fetch-Session command is optionally		data from the Server and the Fetch-Session command is not defined
	supported by the Server.		in TWAMP.
	However, TWAMP can be used as an extension to OWAMP [OWAMP] where
	both one-way and two-way measurements are measured in the same
	session. In this case the Server MAY support the Fetch-Session
	command as defined in section 3.8 of OWAMP[OWAMP]. The
	Session-Reflector will reject the Fetch-Session request if either
	it does not support the Fetch-Session command or Session-Reflector
	cannot provide the required data. In this case the server MUST
	respond with a Fetch-Ack message with Accept value of 3.
	5. TWAMP Test		4. TWAMP Test
	The TWAMP test protocol is similar to the OWAMP [OWAMP] test		The TWAMP test protocol is similar to the OWAMP [RFC4656] test
	protocol with the exception that the Session-Reflector transmits		protocol with the exception that the Session-Reflector transmits
	test packets to the Session-Sender in response to each test packet		test packets to the Session-Sender in response to each test packet
	it receives. TWAMP defines two different test packet formats, one		it receives. TWAMP defines two different test packet formats, one
	for packets transmitted by the Session-Sender and one for packets		for packets transmitted by the Session-Sender and one for packets
	transmitted by the Session-Reflector. As with OWAMP [OWAMP] test		transmitted by the Session-Reflector. As with OWAMP [RFC4656] test
	protocol there are three modes: unauthenticated, authenticated, and		protocol there are three modes: unauthenticated, authenticated, and
	encrypted.		encrypted.
	5.1 Sender Behavior		4.1 Sender Behavior
	The sender behavior is as defined in section 4.1 of OWAMP [OWAMP]		The sender behavior is determined by the configuration of the
	for both packet timing and packet format. Additionally the		Session-Sender and is not defined in this standard. Further, the
	Session-Sender records the necessary information provided by the		Session-Reflector does not need to know the Session-Sender
	packets transmitted by the Session-Reflector for measuring two-way		behaviour to the degree of detail as needed in OWAMP [RFC4656].
	metrics. The information recording based on the received packet by		Additionally the Session-Sender collects and records the necessary
	the Session-Sender is implementation dependent.		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.
	5.1.1 Packet Timings		4.1.1 Packet Timings
	Packet timings follow the same procedure and guidelines as defined		Since the Send Schedule is not communicated to the
	in section 4.1.1 of OWAMP [OWAMP].		Session-Reflector, there is no need for a standardized computation
			of packet timing.
	5.1.2 Packet Format and Content		Regardless of any scheduling delays, each packet that is actually
			sent MUST have the best possible approximation of its real time of
			departure as its timestamp (in the packet).
	Session-Sender packet format and content follow the same procedure		4.1.2 Packet Format and Content
	and guidelines as defined in section 4.1.2 of OWAMP [OWAMP].
	5.2 Reflector Behavior		The Session-Sender packet format and content follow the same
			procedure and guidelines as defined in section 4.1.2 of OWAMP
			[RFC4656] (with the exception of the reference to the Send
			Schedule).
	When receiving packets the reflector behavior is same as		4.2 Reflector Behavior
	Session-Receiver behavior defined in section 4.2 of OWAMP [OWAMP]
	with the exception of optional packet information recording. If		TWAMP requires the Session-Reflector to transmit a packet to the
	the Session-Reflector chooses not to collect packet information for		Session-Sender in response to each packet it receives.
	packets received from the Session-Sender, the Server will not
	support the Fetch-Session command. Additionally, TWAMP requires
	the Session-Reflector to transmit a packet to the 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.		- 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		- In authenticated or encrypted mode, decrypt the first block (16
	octets) of the packet body.		octets) of the packet body.
	- Copy the packet sequence number into the corresponding reflected		- Copy the packet sequence number into the corresponding reflected
	packet to the Session-Sender.		packet to the Session-Sender.
	- Optionally store the packet sequence number, send time, receive		- Transmit a test packet to the Session-Sender in response to
	time, and the TTL for IPv4 (or Hop Limit for IPv6) from the		every received packet. The response MUST be generated as
	packet IP header for the results to be transferred.		immediately as possible. The format and content of the test
			packet is defined in section 5.2.1. Prior to the transmission
	- Packets not received within the Timeout are considered lost.		of the test packet, the Session-Reflector MUST enter the best
	They are optionally recorded with their true sequence number,		possible approximation of its actual sending time of as its
	presumed send time, receive time consisting of a string of zero		Timestamp (in the packet). This permits the determination of the
	bits, and TTL (or Hop Limit) of 255. The Session-Reflector		elapsed time between the reception of the packet and its
	will not generate a test packet to the Session-Sender for		transmission.
	packets that are considered lost.
	- Transmit a test packet to the Session-Sender in response to		- Packets not received within the Timeout are ignored by the
	every received packet. The response must be generated as		Reflector. The Session-Reflector MUST NOT generate a test
	immediately as possible. The format and content of the test		packet to the Session-Sender for packets that are ignored.
	packet is defined in section 5.2.1. Prior to the transmission
	of the test packet Session-Reflector MUST determine the elapsed
	time since the reception of the packet for incorporating the
	value in the reflected test packet.
	5.2.1 Packet Format and Content		4.2.1 TWAMP-Test Packet Format and Content
	The Session-Reflector MUST transmit a packet to the Session-Sender		The Session-Reflector MUST transmit a packet to the Session-Sender
	in response to each packet received. The Session-Reflector SHOULD		in response to each packet received. The Session-Reflector SHOULD
	transmit the packets as immediately as possible. The		transmit the packets as immediately as possible. The
	Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6)		Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6)
	in the UDP packet to 255.		in the UDP packet to 255.
	The test packet will have the necessary information for calculating		The test packet will have the necessary information for calculating
	two-way metrics by the Session-Sender. The format of the test		two-way metrics by the Session-Sender. The format of the test
	packet depends on the mode being used. The format of the packet is		packet depends on the mode being used. The various formats of the
	presented below.		packet are presented below.
	For unauthenticated mode:		For unauthenticated mode:
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp |		| Timestamp |
	| |		| |
	skipping to change at page 10, line 48 ¶		skipping to change at page 12, line 48 ¶
	| IZP (6 octets) |		| IZP (6 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Packet Padding .		. Packet Padding .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Sequence Number is the sequence number of the test packet and		Sequence Number is the sequence number of the test packet according
	starts with zero and is incremented by one for each subsequent		to its arrival at the Session-Reflector. It starts with zero and
	packet. The generated sequence number by the Session-Reflector,		is incremented by one for each subsequent packet. The Sequence
	Sequence Number, is independent from the sequence number of the		Number generated by the Session-Reflector is independent from the
	received packets.		sequence number of the arriving packets.
	Timestamp and Error Estimate are the transmit timestamp and error		Timestamp and Error Estimate are the Session-Reflector's transmit
	estimate of the test packet respectively. Sender Timestamp and		timestamp and error estimate for the reflected test packet,
	Sender Error Estimate are exact copies of the timestamp and error		respectively. The format of all timestamp and error estimate
	estimate from the Session-Sender test packet that corresponds to		fields follow the definition and formats defined by OWAMP[RFC4656].
	this test packet. The format of all timestamp and error estimate
	fields follow the definition and formats defined by OWAMP[OWAMP].		Sender Timestamp and Sender Error Estimate are exact copies of the
			timestamp and error estimate from the Session-Sender test packet
			that corresponds to this test packet.
	Receive Timestamp is the time the test packet was received by the		Receive Timestamp is the time the test packet was received by the
	reflector. The difference between Timestamp and Receive Timestamp		reflector. The difference between Timestamp and Receive Timestamp
	is the amount of time the packet was in transition in the		is the amount of time the packet was in transition in the
	Session-Reflector. The Error Estimate of Timestamp also applies to		Session-Reflector. The Error Estimate associated with the
	Receive Timestamp.		Timestamp field also applies to the Receive Timestamp.
	Sender Sequence Number is the Sequence Number of the packet		Sender Sequence Number is a copy of the Sequence Number of the
	transmitted by the Session-Sender that corresponds to this test		packet transmitted by the Session-Sender that caused the
	packet.		Session-Reflector to generate and send this test packet.
	Similar to OWAMP [OWAMP] the TWAMP packet layout is the same in		Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in
	authenticated and encrypted modes. The encryption operation of		authenticated and encrypted modes. The encryption operation of
	Session-Receiver packet follow the same rules of Session-Sender		Session-Sender packet follow the same rules of Session-Sender
	packets as defined in OWAMP [OWAMP].		packets as defined in OWAMP [RFC4656].
	The minimum data segment length is, therefore, 40 octets in		The minimum data segment length is, therefore, 40 octets in
	unauthenticated mode, and 80 octets in both authenticated mode and		unauthenticated mode, and 80 octets in both authenticated mode and
	encrypted modes.		encrypted modes (with the implication that the later two modes will
			not fit in a single ATM cell).
	The Session-Reflector TWAMP-Test packet layout is the same in		The Session-Reflector TWAMP-Test packet layout is the same in
	authenticated and encrypted modes. The encryption operations are,		authenticated and encrypted modes. The encryption operations are,
	however, different. The difference is that in encrypted mode both		however, different. The difference is that in encrypted mode both
	the sequence numbers and timestamps are encrypted to provide		the sequence numbers and timestamps are encrypted to provide
	maximum data integrity protection while in authenticated mode the		maximum data integrity protection while in authenticated mode the
	sequence numbers are encrypted and the timestamps are sent in clear		sequence numbers are encrypted and the timestamps are sent in clear
	text. Sending the timestamp in clear text in authenticated mode		text. Sending the timestamp in clear text in authenticated mode
	allows one to reduce the time between when a timestamp is obtained		allows one to reduce the time between when a timestamp is obtained
	by a reflector and when the packet is reflected out. In encrypted		by a reflector and when the packet is reflected out. In encrypted
	mode, both the sender and reflector have to fetch the timestamp,		mode, both the sender and reflector have to fetch the timestamp,
	encrypt it, and send it; in authenticated mode, the middle step is		encrypt it, and send it; in authenticated mode, the middle step is
	removed, potentially improving accuracy (the sequence number can be		removed, potentially improving accuracy (the sequence number can be
	encrypted before the timestamp is fetched).		encrypted before the timestamp is fetched).
	In authenticated mode, the first block (32 octets) of each packet		In authenticated mode, the first block (32 octets) of each packet
	is encrypted using AES Electronic Cookbook (ECB) mode.		is encrypted using AES Electronic Cookbook (ECB) mode.
	Obtaining the key, encryption method, and packet padding is as		Obtaining the key, encryption method, and packet padding is as
	defined in section 4.1.2 of OWAMP [OWAMP]. In unauthenticated		defined in section 4.1.2 of OWAMP [RFC4656]. In unauthenticated
	mode, no encryption is applied.		mode, no encryption is applied.
	6. Implementers Guide		5. Implementers Guide
	This section serves as guidance to implementers of TWAMP. Two		This section serves as guidance to implementers of TWAMP. Two
	architectures are presented in this section for implementations		architectures are presented in this section for implementations
	where two hosts play the subsystem roles of TWAMP. Although only		where two hosts play the subsystem roles of TWAMP. Although only
	two architectures are presented here the protocol does not require		two architectures are presented here the protocol does not require
	their use. Similar to OWAMP [OWAMP] TWAMP is designed with		their use. Similar to OWAMP [RFC4656] TWAMP is designed with
	complete flexibility to allow different architectures that suite		complete flexibility to allow different architectures that suite
	multiple system requirements.		multiple system requirements.
	6.1 Complete TWAMP		5.1 Complete TWAMP
	In this example the roles of Control-Client, Fetch-Client, 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 roles of Server and Session-Receiver are		of Server and Session-Reflector are implemented in another host
	implemented in another host referred to as the responder.		referred to as the responder.
	controller responder		controller responder
	+-----------------+ +-------------------+		+-----------------+ +-------------------+
	| Control-Client |<--TWAMP-Control-->| Server |		| Control-Client |<--TWAMP-Control-->| Server |
	| Fetch-Client | | |		| | | |
	| Session-Sender |<--TWAMP-Test----->| Session-Reflector |		| Session-Sender |<--TWAMP-Test----->| Session-Reflector |
	+-----------------+ +-------------------+		+-----------------+ +-------------------+
	This example provides an architecture that supports the full TWAMP		This example provides an architecture that supports the full TWAMP
	standard. The controller establishes the test session with the		standard. The controller establishes the test session with the
	responder through the TWAMP-Control protocol. After the session is		responder through the TWAMP-Control protocol. 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-Receiver behavior of both OWAMP		The responder follows the Session-Reflctor behavior of TWAMP as
	[OWAMP] and TWAMP as described in section 5.2. In this		described in section 4.2.
	architecture the responder supports the Fetch-Session command.
	After the transmission of test packets the controller fetches the
	responder's information through its Fetch-Client. This
	architecture allows for collection of both one-way and two-way
	metrics.
	6.2 TWAMP Light		5.2 TWAMP Light
	In this example the roles of Control-Client, Server, and		In this example the roles of Control-Client, Server, and
	Session-Sender are implemented in one host referred to as the		Session-Sender are implemented in one host referred to as the
	controller and the role of Session-Receiver is implemented in		controller and the role of Session-Reflector is implemented in
	another host referred to as the responder.		another host referred to as the responder.
	controller responder		controller responder
	+-----------------+ +-------------------+		+-----------------+ +-------------------+
	| Server |<----------------->| |		| Server |<----------------->| |
	| Control-Client | | Session-Reflector |		| Control-Client | | Session-Reflector |
	| Session-Sender |<--TWAMP-Test----->| |		| Session-Sender |<--TWAMP-Test----->| |
	+-----------------+ +-------------------+		+-----------------+ +-------------------+
	This example provides a simple architecture for responders where		This example provides a simple architecture for responders where
	their role will be to simply act as light test points in the		their role will be to simply act as light test points in the
	network. The controller establishes the test session with the		network. The controller establishes the test session with the
	Server through non-standard means. 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-Receiver behavior of TWAMP as		The responder follows the Session-Reflector behavior of TWAMP as
	described in section 5.2.1 with the following exceptions. The		described in section 4.2 with the following exceptions. The
	Session-Reflector SHOULD copy the sequence number of the received		Session-Reflector SHOULD copy the sequence number of the received
	packet to the Sequence Number field of the reflected packet. This		packet to the Sequence Number field of the reflected packet. This
	is necessary since in case of TWAMP Light the Session-Reflector		is necessary since in case of TWAMP Light the Session-Reflector
	does not have knowledge of the session state. The controller		does not have knowledge of the session state. The controller
	receives the reflected test packets and collects two-way metrics.		receives the reflected test packets and collects two-way metrics.
	This architecture allows for collection of two-way metrics.		This architecture allows for collection of two-way metrics.
	This example eliminates the need for the TWAMP-Control protocol and		This example eliminates the need for the TWAMP-Control protocol and
	assumes that the Session-Reflector is configured and communicates		assumes that the Session-Reflector is configured and communicates
	its configuration with the Server through non-standard means.		its configuration with the Server through non-standard means. The
	Furthermore, the Server does not support the Fetch-Session command		Session-Reflector simply reflects the incoming packets back to the
	and the responder does not collect the received packet information.		controller while copying the necessary information and generating
	The Session-Reflector simply reflects the incoming packets back to		sequence number and timestamp values per section 5.2.1.
	the controller while copying the necessary information and
	generating sequence number and timestamp values per section 5.2.1.
	7. Security Considerations		6. Security Considerations
	The security considerations of OWAMP [OWAMP] apply.		The security considerations of OWAMP [RFC4656] apply.
	8. IANA Considerations		7. Acknowledgements
	There are no IANA considerations associated with this		We would like to thank Nagarjuna Venn, Sharee McNab, Nick Kinraid,
	specification.		and Stanislav Shalunov for their comments, suggestions, reviews,
			helpful discussion and proof-reading.
	9. Acknowledgements		8. IANA Considerations
			IANA has allocated a well-known TCP port number (861) for the
			OWAMP-Control part of the OWAMP [RFC4656] protocol which also
			applies to the TWAMP-Control part of the TWAMP protocol.
	The authors wish to thank Sharee McNab and Nick Kinraid for their		9. Internationalization Considerations
	comments and suggestions.
			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.
	10. References		10. References
	10.1 Normative References		10.1 Normative References
	[OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,		[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
	Zekauskas, M., "A One-way Active Measurement Protocol		Zekauskas, M., "A One-way Active Measurement Protocol
	(OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004.		(OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004.
	[RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A		[RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A
	Round-Trip Delay Metric for IPPM". RFC 2681, STD 1,		Round-Trip Delay Metric for IPPM". RFC 2681, STD 1,
	September 1999.		September 1999.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			[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.
	Authors' Addresses		Authors' Addresses
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks		Brix Networks
	285 Mill Road		285 Mill Road
	Chelmsford, MA 01824		Chelmsford, MA 01824
	US		USA
	Phone: +1 978 367 5611
	EMail: khedayat@brixnet.com		EMail: khedayat@brixnet.com
	URI: http://www.brixnet.com/		URI: http://www.brixnet.com/
	Roman M. Krzanowski, Ph.D.		Roman M. Krzanowski, Ph.D.
	Verizon		Verizon
	500 Westchester Ave.		500 Westchester Ave.
	White Plains, NY		White Plains, NY
	US		USA
	Phone: +1 914 644 2395
	EMail: roman.krzanowski@verizon.com		EMail: roman.krzanowski@verizon.com
	URI: http://www.verizon.com/		URI: http://www.verizon.com/
			Al Morton
			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/
	Kiho Yum		Kiho Yum
	Juniper Networks		Juniper Networks
	1194 Mathilda Ave.		1194 Mathilda Ave.
	Sunnyvale, CA		Sunnyvale, CA
	US		USA
	Phone: +1 408 936 2272
	EMail: kyum@juniper.net		EMail: kyum@juniper.net
	URI: http://www.juniper.com/		URI: http://www.juniper.com/
	IPR Disclosure Acknowledgement		Jozef Z. Babiarz
			Nortel Networks
			3500 Carling Avenue
			Ottawa, Ont K2H 8E9
			Canada
			Email: babiarz@nortel.com
			URI: http://www.nortel.com/
			Full Copyright Statement
			Copyright (C) The Internet Society (2006).
			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		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.
	skipping to change at page 15, line 38 ¶		skipping to change at page 18, line 42 ¶
	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.
	Disclaimer of Validity		Acknowledgement
	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.
	Copyright Notice
	Copyright (C) The Internet Society (2006).
	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.
	Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 92 change blocks.
	299 lines changed or deleted		411 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/