< draft-ietf-ippm-twamp-07.txt		draft-ietf-ippm-twamp-08.txt >
	Network Working Group K. Hedayat		Network Working Group K. Hedayat
	Internet Draft Brix Networks		Internet Draft Brix Networks
	Expires: Nov 2008 R. Krzanowski		Expires: Dec 2008 R. Krzanowski
	Intended Status:Standards Track Verizon		Intended Status:Standards Track Verizon
	A. Morton		A. Morton
	AT&T Labs		AT&T Labs
	K. Yum		K. Yum
	Juniper Networks		Juniper Networks
	J. Babiarz		J. Babiarz
	Nortel Networks		Nortel Networks
	May 13, 2008		June 6, 2008
	A Two-way Active Measurement Protocol (TWAMP)		A Two-way Active Measurement Protocol (TWAMP)
	draft-ietf-ippm-twamp-07		draft-ietf-ippm-twamp-08
	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 5, line 44 ¶		skipping to change at page 5, line 44 ¶
	with its greeting message indicating the security/integrity		with its greeting message indicating the security/integrity
	mode(s) it is willing to support.		mode(s) it is willing to support.
	- The Control-Client responds with the chosen mode of		- The Control-Client responds with the chosen mode of
	communication and information supporting integrity protection		communication and information supporting integrity protection
	and encryption, if the mode requires them. The Server responds		and encryption, if the mode requires them. The Server responds
	to accept the mode and start time. This completes the control		to accept the mode and start time. This completes the control
	connection setup.		connection setup.
	- The Control-Client requests (and describes) a test session with		- The Control-Client requests (and describes) a test session with
	a unique TWAMP-Control message. The Server repsponds with its		a unique TWAMP-Control message. The Server responds with its
	acceptance and supporting information. More than one test		acceptance and supporting information. More than one test
	session may be requested with additional messages.		session may be requested with additional messages.
	- The Control-Client initiates all requested testing with a start		- The Control-Client initiates all requested testing with a start
	sessions message, and the Server acknowleges.		sessions message, and the Server acknowledges.
	- The Session-Sender and the Session-Reflector exchange test		- The Session-Sender and the Session-Reflector exchange test
	packets according to the TWAMP-Test protocol for each active		packets according to the TWAMP-Test protocol for each active
	session.		session.
	- When appropriate, the Control-Client sends a message to stop all		- When appropriate, the Control-Client sends a message to stop all
	test sessions.		test sessions.
	There are two recognized extension mechanisms in the TWAMP		There are two recognized extension mechanisms in the TWAMP
	Protocol. The Modes field is used to establish the communication		Protocol. The Modes field is used to establish the communication
	skipping to change at page 7, line 9 ¶		skipping to change at page 7, line 9 ¶
	assignment). The host that initiates the TCP connection takes the		assignment). The host that initiates the TCP connection takes the
	roles of Control-Client and (in the two-host implementation) the		roles of Control-Client and (in the two-host implementation) the
	Session-Sender. The host that acknowledges the TCP connection		Session-Sender. The host that acknowledges the TCP connection
	accepts the roles of Server and (in the two-host implementation)		accepts the roles of Server and (in the two-host implementation)
	the Session Reflector.		the Session Reflector.
	The possibility exists for Control-Client failure after TWAMP-		The possibility exists for Control-Client failure after TWAMP-
	Control connection establishment, or the path between the Control-		Control connection establishment, or the path between the Control-
	Client and Server may fail while a connection is in-progress. The		Client and Server may fail while a connection is in-progress. The
	Server MAY discontinue any established control connection when no		Server MAY discontinue any established control connection when no
	packet associated with that connection, AND no packet associated		packet associated with that connection has been received within
	with any test sessions started by that control connection have been		SERVWAIT seconds. The Server SHALL suspend monitoring control
	received for SERVWAIT seconds. The default value of SERVWAIT SHALL		connection activity after receiving a Start-Sessions command, and
	be 900 seconds, and this waiting time MAY be configurable. This		SHALL resume after receiving a Stop-Sessions command (IF the
	time-out allows a Server to free-up resources in case of failure.		SERVWAIT option is supported). Note that the REFWAIT time-out
			(described below) covers failures during test sessions. 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.2 Integrity Protection		3.2 Integrity Protection
	Integrity protection of TWAMP follows the same procedure defined in		Integrity protection of TWAMP follows the same procedure defined in
	section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC sent covers		section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC sent covers
	everything sent in a given direction between the previous HMAC (but		everything sent in a given direction between the previous HMAC (but
	not including it) and up to the beginning of the new HMAC. This		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		way, once encryption is set up, each bit of the TWAMP-Control
	connection is authenticated by an HMAC exactly once.		connection is authenticated by an HMAC exactly once.
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 13 ¶
	Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server		Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server
	can send specific messages in response to the commands it receives		can send specific messages in response to the commands it receives
	(as described in the sections that follow).		(as described in the sections that follow).
	Note that the OWAMP Request-Session command is replaced by the		Note that the OWAMP Request-Session command is replaced by the
	TWAMP Request-TW-Session command, and the Fetch-Session command		TWAMP Request-TW-Session command, and the Fetch-Session command
	does not appear in TWAMP.		does not appear in TWAMP.
	3.5 Creating Test Sessions		3.5 Creating Test Sessions
	Test sessions creation follows the same procedure as defined in		Test session creation follows the same procedure as defined in
	section 3.5 of OWAMP [RFC4656].		section 3.5 of OWAMP [RFC4656].
	In TWAMP, the first octet is referred to as the Command Number, and		In TWAMP, the first octet is referred to as the Command Number, and
	the Command Number is a recognized extension mechanism. Readers are		the Command Number is a recognized extension mechanism. Readers are
	encouraged to consult the TWAMP-Control Command Number Registry to		encouraged to consult the TWAMP-Control Command Number Registry to
	determine if there have been additional values assigned.		determine if there have been additional values assigned.
	The Command Number value of 5 indicates a Request-TW-Session		The Command Number value of 5 indicates a Request-TW-Session
	Command, and the Server MUST interpret this command as a request		Command, and the Server MUST interpret this command as a request
	for a two-way test session using the TWAMP-Test protocol.		for a two-way test session using the TWAMP-Test protocol.
	skipping to change at page 9, line 27 ¶		skipping to change at page 9, line 30 ¶
	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
	Control-Client to Server TWAMP-Control Message exchange MUST be		Control-Client to Server TWAMP-Control Message exchange MUST be
	used in the test packets.		used in the test packets.
	The Session Identifier (SID) is as defined in OWAMP [RFC4656].		The Session Identifier (SID) is as defined in OWAMP [RFC4656].
	Since the SID is always generated by the receiving side, the Server		Since the SID is always generated by the receiving side, the Server
	determines the SID, and the SID in the Request-TW-Session message		determines the SID, and the SID in the Request-TW-Session message
	MUST be set to 0.		MUST be set to 0.
	The Start Time is as as defined in OWAMP [RFC4656].		The Start Time is as defined in OWAMP [RFC4656].
	The Timeout is interpreted differently from the definition in OWAMP		The Timeout is interpreted differently from the definition in OWAMP
	[RFC4656]. In TWAMP, Timeout is the interval that the		[RFC4656]. In TWAMP, Timeout is the interval that the
	Session-Reflector MUST wait after receiving a Stop-Sessions		Session-Reflector MUST wait after receiving a Stop-Sessions
	message. In case there are test packets still in transit, the		message. In case there are test packets still in transit, the
	Session Reflector MUST reflect them if they arrive within the		Session Reflector MUST reflect them if they arrive within the
	timeout interval following the reception of the Stop-Sessions		timeout interval following the reception of the Stop-Sessions
	message. The Session-Reflector MUST NOT reflect packets that are		message. The Session-Reflector MUST NOT reflect packets that are
	received beyond the timeout.		received beyond the timeout.
	skipping to change at page 12, line 9 ¶		skipping to change at page 12, line 9 ¶
	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 [RFC4656] 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.
	4.1 Sender Behavior		4.1 Sender Behavior
	The sender behavior is determined by the configuration of the		The sender behavior is determined by the configuration of the
	Session-Sender and is not defined in this standard. Further, the		Session-Sender and is not defined in this standard. Further, the
	Session-Reflector does not need to know the Session-Sender		Session-Reflector does not need to know the Session-Sender behavior
	behaviour to the degree of detail as needed in OWAMP [RFC4656].		to the degree of detail as needed in OWAMP [RFC4656].
	Additionally the Session-Sender collects and records the necessary		Additionally the Session-Sender collects and records the necessary
	information provided from the packets transmitted by the		information provided from the packets transmitted by the
	Session-Reflector for measuring two-way metrics. The information		Session-Reflector for measuring two-way metrics. The information
	recording based on the received packet by the Session-Sender is		recording based on the received packet by the Session-Sender is
	implementation dependent.		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
	skipping to change at page 18, line 20 ¶		skipping to change at page 18, line 20 ¶
	using AES, with the 16-octet session identifier (SID) as the key;		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		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		result is the TWAMP-Test HMAC Session-key to use in authenticating
	the packets of the particular TWAMP-Test session. Note that all of		the packets of the particular TWAMP-Test session. Note that all of
	TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are		TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are
	comprised of 32 octets, while the SID is 16 octets.		comprised of 32 octets, while the SID is 16 octets.
	ECB mode used for encrypting the first block of TWAMP-Test packets		ECB mode used for encrypting the first block of TWAMP-Test packets
	in authenticated mode does not involve any actual chaining; this		in authenticated mode does not involve any actual chaining; this
	way, lost, duplicated, or reordered packets do not cause problems		way, lost, duplicated, or reordered packets do not cause problems
	with deciphering any packet in an TWAMP-Test session.		with deciphering any packet in a TWAMP-Test session.
	In encrypted mode, the first six blocks (96octets) are encrypted		In encrypted mode, the first six blocks (96octets) are encrypted
	using AES CBC mode. The AES Session-key to use is obtained in the		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		same way as the key for authenticated mode. Each TWAMP-Test packet
	is encrypted as a separate stream, with just one chaining		is encrypted as a separate stream, with just one chaining
	operation; chaining does not span multiple packets so that lost,		operation; chaining does not span multiple packets so that lost,
	duplicated, or reordered packets do not cause problems. The		duplicated, or reordered packets do not cause problems. The
	initialization vector for the CBC encryption is a value with all		initialization vector for the CBC encryption is a value with all
	bits equal to zero.		bits equal to zero.
	skipping to change at page 24, line 5 ¶		skipping to change at page 24, line 5 ¶
	[RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing		[RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing
	an IANA Considerations Section in RFCs, RFC 2434,		an IANA Considerations Section in RFCs, RFC 2434,
	October 1998.		October 1998.
	11.2 Informative References		11.2 Informative References
	[RFC3692] Narten, T., Assigning Experimental and Testing Numbers		[RFC3692] Narten, T., Assigning Experimental and Testing Numbers
	Considered Useful, RFC 3692, January 2004.		Considered Useful, RFC 3692, January 2004.
	Authors' Addresses		Authors' Addresses
	Kaynam Hedayat		Kaynam Hedayat
	Brix Networks		Brix Networks
	285 Mill Road		285 Mill Road
	Chelmsford, MA 01824		Chelmsford, MA 01824
	USA		USA
	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.
End of changes. 11 change blocks.
	16 lines changed or deleted		20 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/