< draft-ietf-ippm-twamp-03.txt		draft-ietf-ippm-twamp-04.txt >
	K. Hedayat		K. Hedayat
	Internet Draft Brix Networks		Internet Draft Brix Networks
	Expires: September 2007 R. Krzanowski		Expires: November 2007 R. Krzanowski
	Verizon		Verizon
	K. Yum		K. Yum
	Juniper Networks		Juniper Networks
	A. Morton		A. Morton
	AT&T Labs		AT&T Labs
	J. Babiarz		J. Babiarz
	Nortel Networks		Nortel Networks
	March 2007		May 2007
	A Two-way Active Measurement Protocol (TWAMP)		A Two-way Active Measurement Protocol (TWAMP)
	draft-ietf-ippm-twamp-03		draft-ietf-ippm-twamp-04
	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 35 ¶		skipping to change at page 2, line 35 ¶
	3. TWAMP Control.................................................5		3. TWAMP Control.................................................5
	3.1 Connection Setup..........................................5		3.1 Connection Setup..........................................5
	3.2 Integrity Protection......................................6		3.2 Integrity Protection......................................6
	3.3 Value of the Accept Fields................................6		3.3 Value of the Accept Fields................................6
	3.4 TWAMP Control Commands....................................6		3.4 TWAMP Control Commands....................................6
	3.5 Creating Test Sessions....................................6		3.5 Creating Test Sessions....................................6
	3.6 Send Schedules............................................8		3.6 Send Schedules............................................8
	3.7 Starting Test Sessions....................................8		3.7 Starting Test Sessions....................................8
	3.8 Stop-Sessions.............................................8		3.8 Stop-Sessions.............................................8
	3.9 Fetch-Session.............................................8		3.9 Fetch-Session.............................................8
	4. TWAMP Test....................................................8		4. TWAMP Test....................................................9
	4.1 Sender Behavior...........................................9		4.1 Sender Behavior...........................................9
	4.2 Reflector Behavior........................................9		4.2 Reflector Behavior.......................................10
	5. Implementers Guide...........................................15		5. Implementers Guide...........................................15
	5.1 Complete TWAMP...........................................15		5.1 Complete TWAMP...........................................15
	5.2 TWAMP Light..............................................16		5.2 TWAMP Light..............................................16
	6. Security Considerations......................................17		6. Security Considerations......................................17
	7. Acknowledgements.............................................17		7. Acknowledgements.............................................17
	8. IANA Considerations..........................................17		8. IANA Considerations..........................................17
	9. Internationalization Considerations..........................17		9. Internationalization Considerations..........................18
	10. References..................................................18		10. References..................................................18
	10.1 Normative References....................................18		10.1 Normative References....................................18
	1. Introduction		1. Introduction
	The IETF IP Performance Metrics (IPPM) working group has completed		The IETF IP Performance Metrics (IPPM) working group has completed
	a draft standard for the round-trip delay [RFC2681] metric. IPPM		a draft standard for the round-trip delay [RFC2681] metric. IPPM
	has also completed a protocol for the control and collection of		has also completed a protocol for the control and collection of
	one-way measurements, the One-way Active Measurement Protocol		one-way measurements, the One-way Active Measurement Protocol
	(OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip		(OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 12 ¶
	connection for control. The server MUST interpret any non-zero		connection for control. The server MUST interpret any non-zero
	value as zero.		value as zero.
	The Session-Reflector in TWAMP does not process incoming test		The Session-Reflector in TWAMP does not process incoming test
	packets for performance metrics and consequently does not need to		packets for performance metrics and consequently does not need to
	know the number of incoming packets and their timing schedule.		know the number of incoming packets and their timing schedule.
	Consequently the Number of Scheduled Slots and Number of Packets		Consequently the Number of Scheduled Slots and Number of Packets
	MUST be set to 0.		MUST be set to 0.
	The Sender Port is the UDP port from which TWAMP-Test packets will		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		be sent and the port to which TWAMP-Test packets will be sent by
	are reflected by the Session-Reflector (the port where the		the Session-Reflector (Session-Sender will use the same UDP port to
	Session-Sender wants to receive test packets).		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,		The Sender Address and Receiver Address fields contain,
	respectively, the sender and receiver addresses of the endpoints of		respectively, the sender and receiver addresses of the endpoints of
	the Internet path over which a TWAMP test session is requested.		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		They MAY be set to 0, in which case the IP addresses used for the
	Session-Sender to Session-Reflector Control Message exchange MUST		Session-Sender to Session-Reflector Control Message exchange MUST
	be used in the test packets.		be used in the test packets.
	The SID is as defined in OWAMP [RFC4656]. Since the SID is always		The SID is as defined in OWAMP [RFC4656]. Since the SID is always
	generated by the receiving side, the Session-Reflector determines		generated by the receiving side, the Session-Reflector determines
	skipping to change at page 7, line 49 ¶		skipping to change at page 8, line 6 ¶
	Type-P descriptor is as defined in OWAMP [RFC4656]. The only		Type-P descriptor is as defined in OWAMP [RFC4656]. The only
	capability of this field is to set the Differentiated Services Code		capability of this field is to set the Differentiated Services Code
	Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST		Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST
	be used in test packets reflected by the Session-Reflector.		be used in test packets reflected by the Session-Reflector.
	Since there are no Schedule Slot Descriptions, the Request-Session		Since there are no Schedule Slot Descriptions, the Request-Session
	Message is completed by MBZ and HMAC fields. This completes one		Message is completed by MBZ and HMAC fields. This completes one
	logical message, referred to as the Request-Session Command.		logical message, referred to as the Request-Session Command.
	The Session-Reflector MUST respond to each 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		with an Accept-Message as defined in OWAMP [RFC4656]. When the
	the port to which TWAMP test packets are sent by the Session-Sender		Accept Field = 0, the Port field confirms (repeats) the port to
	toward the Session-Reflector. In other words, the Port field		which TWAMP test packets are sent by the Session-Sender toward the
	indicates the port number where the Session-Reflector expects to		Session-Reflector. In other words, the Port field indicates the
	receive packets from the Session-Sender.		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
			use), the Server at the Session-Reflector MAY suggest an alternate
			and available port for this session in the Port Field. The
			Session-Sender either accepts the alternate port, or composes a new
			Session-Request message with suitable parameters. Otherwise, the
			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.
	3.6 Send Schedules		3.6 Send Schedules
	The Send Schedule for test packets defined in section 3.6 of OWAMP		The Send Schedule for test packets defined in section 3.6 of OWAMP
	[RFC4656] is not used in TWAMP. The Control-Client and		[RFC4656] is not used in TWAMP. The Control-Client and
	Session-Sender MAY autonomously decide the Send Schedule. The		Session-Sender MAY autonomously decide the Send Schedule. The
	Session-Reflector SHOULD return each test packet to the		Session-Reflector SHOULD return each test packet to the
	Session-Sender as quickly as possible.		Session-Sender as quickly as possible.
	3.7 Starting Test Sessions		3.7 Starting Test Sessions
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 29 ¶
	- Timestamp the received packet. Each packet that is actually		- Timestamp the received packet. Each packet that is actually
	received MUST have the best possible approximation of its real		received MUST have the best possible approximation of its real
	time of arrival entered as its timestamp (in the packet).		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.
	- 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 the		field of arriving packets), it MUST set the Sender TTL value as
	elapsed time between the reception of the packet and its		255.
	transmission.
			- 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 5.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.
	- Packets not received within the Timeout are ignored by the		- Packets not received within the Timeout are ignored by the
	Reflector. The Session-Reflector MUST NOT generate a test		Reflector. The Session-Reflector MUST NOT generate a test
	packet to the Session-Sender for packets that are ignored.		packet to the Session-Sender for packets that are ignored.
	4.2.1 TWAMP-Test 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
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 40 ¶
	| Receive Timestamp |		| Receive Timestamp |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Sequence Number |		| Sender Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Timestamp |		| Sender Timestamp |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Error Estimate | MBZ |		| Sender Error Estimate | MBZ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sender TTL | |
			+++++++++++++++++ |
	| |		| |
	. .		. .
	. Packet Padding .		. Packet Padding .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	For authenticated and encrypted modes:		For authenticated and encrypted modes:
	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
	skipping to change at page 12, line 41 ¶		skipping to change at page 12, line 41 ¶
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Timestamp |		| Sender Timestamp |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Error Estimate | |		| Sender Error Estimate | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| MBZ (6 octets) |		| MBZ (6 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sender TTL | |
			+++++++++++++++++ |
			| MBZ (7 octets) |
			| |
			+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
	| HMAC (16 octets) |		| HMAC (16 octets) |
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
	| |		| |
	. .		. .
	. Packet Padding .		. Packet Padding .
	. .		. .
	| |		| |
	skipping to change at page 13, line 4 ¶		skipping to change at page 13, line 9 ¶
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
	| |		| |
	. .		. .
	. Packet Padding .		. Packet Padding .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Sequence Number is the sequence number of the test packet according		Sequence Number is the sequence number of the test packet according
	to its arrival at the Session-Reflector. It starts with zero and		to its arrival at the Session-Reflector. It starts with zero and
	is incremented by one for each subsequent packet. The Sequence		is incremented by one for each subsequent packet. The Sequence
	Number generated by the Session-Reflector is independent from the		Number generated by the Session-Reflector is independent from the
	sequence number of the arriving packets.		sequence number of the arriving packets.
	Timestamp and Error Estimate are the Session-Reflector's transmit		Timestamp and Error Estimate are the Session-Reflector's transmit
	timestamp and error estimate for the reflected test packet,		timestamp and error estimate for the reflected test packet,
	respectively. The format of all timestamp and error estimate		respectively. The format of all timestamp and error estimate
	fields follow the definition and formats defined by OWAMP[RFC4656].		fields follow the definition and formats defined by OWAMP[RFC4656].
	Sender Timestamp and Sender Error Estimate are exact copies of the		Sender Timestamp and Sender Error Estimate are exact copies of the
	timestamp and error estimate from the Session-Sender test packet		timestamp and error estimate from the Session-Sender test packet
	that corresponds to this test packet.		that corresponds to this test packet.
			Sender TTL is 255 when transmitted by the Session Sender. Sender
			TTL is set to the Time To Live (or Hop Count) value of the received
			packet from the IP packet header when transmitted by the Session
			Reflector.
	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 associated with the		Session-Reflector. The Error Estimate associated with the
	Timestamp field also applies to the Receive Timestamp.		Timestamp field also applies to the Receive Timestamp.
	Sender Sequence Number is a copy of the Sequence Number of the		Sender Sequence Number is a copy of the Sequence Number of the
	packet transmitted by the Session-Sender that caused the		packet transmitted by the Session-Sender that caused the
	Session-Reflector to generate and send this test packet.		Session-Reflector to generate and send this test packet.
	skipping to change at page 16, line 39 ¶		skipping to change at page 17, line 4 ¶
	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-Reflector behavior of TWAMP as		The responder follows the Session-Reflector behavior of TWAMP as
	described in section 4.2 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 necessarily have knowledge of the session state. The
	receives the reflected test packets and collects two-way metrics.		controller receives the reflected test packets and collects two-way
	This architecture allows for collection of two-way metrics.		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. The		its configuration with the Server through non-standard means. The
	Session-Reflector simply reflects the incoming packets back to the		Session-Reflector simply reflects the incoming packets back to the
	controller while copying the necessary information and generating		controller while copying the necessary information and generating
	sequence number and timestamp values per section 5.2.1.		sequence number and timestamp values per section 5.2.1.
	6. Security Considerations		6. Security Considerations
	Fundamentally TWAMP and OWAMP use the same protocol for		Fundamentally TWAMP and OWAMP use the same protocol for
	establishment of Control and Test procedures. The main difference		establishment of Control and Test procedures. The main difference
	between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP		between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP
	vs. the Session-Receiver behavior in OWAMP. This difference in		vs. the Session-Receiver behavior in OWAMP. This difference in
	behavior does not introduce any known security vulnerabilities that		behavior does not introduce any known security vulnerabilities that
	are not already addressed by the security features of OWAMP. The		are not already addressed by the security features of OWAMP. The
	entire security considerations of OWAMP [RFC4656] applies to TWAMP.		entire security considerations of OWAMP [RFC4656] applies to TWAMP.
			The only area where TWAMP may introduce new security considerations
			is the TWAMP Light version described above. The non-standard means
			to control the responder and establish test sessions SHOULD offer
			the features listed below.
			The non-standard responder control protocol SHOULD have an
			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
			activate the authenticated and encrypted modes of the TWAMP-Test
			protocol.
	7. Acknowledgements		7. Acknowledgements
	We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,		We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,
	and Stanislav Shalunov for their comments, suggestions, reviews,		and Stanislav Shalunov for their comments, suggestions, reviews,
	helpful discussion and proof-reading.		helpful discussion and proof-reading.
	8. IANA Considerations		8. IANA Considerations
	IANA has allocated a well-known TCP port number (861) for the		IANA has allocated a well-known TCP port number (861) for the
	OWAMP-Control part of the OWAMP [RFC4656] protocol which also		OWAMP-Control part of the OWAMP [RFC4656] protocol which also
	applies to the TWAMP-Control part of the TWAMP protocol.		applies to the TWAMP-Control part of the TWAMP protocol.
	9. Internationalization Considerations		9. Internationalization Considerations
	The protocol does not carry any information in a natural language,		The protocol does not carry any information in a natural language,
	with the possible exception of the KeyID in TWAMP-Control, which is		with the possible exception of the KeyID in TWAMP-Control, which is
	encoded in UTF-8.		encoded in UTF-8.
End of changes. 16 change blocks.
	27 lines changed or deleted		77 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/