< draft-ietf-ippm-twamp-04.txt		draft-ietf-ippm-twamp-05.txt >
	K. Hedayat		K. Hedayat
	Internet Draft Brix Networks		Internet Draft Brix Networks
	Expires: November 2007 R. Krzanowski		Expires: May 2008 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
	May 2007		November 2007
	A Two-way Active Measurement Protocol (TWAMP)		A Two-way Active Measurement Protocol (TWAMP)
	draft-ietf-ippm-twamp-04		draft-ietf-ippm-twamp-05
	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 33 ¶		skipping to change at page 2, line 33 ¶
	1.2 Logical Model.............................................3		1.2 Logical Model.............................................3
	2. Protocol Overview.............................................5		2. Protocol Overview.............................................5
	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.............................................9
	3.9 Fetch-Session.............................................8		3.9 Fetch-Session.............................................9
	4. TWAMP Test....................................................9		4. TWAMP Test....................................................9
	4.1 Sender Behavior...........................................9		4.1 Sender Behavior...........................................9
	4.2 Reflector Behavior.......................................10		4.2 Reflector Behavior.......................................10
	5. Implementers Guide...........................................15		5. Implementers Guide...........................................16
	5.1 Complete TWAMP...........................................15		5.1 Complete TWAMP...........................................17
	5.2 TWAMP Light..............................................16		5.2 TWAMP Light..............................................17
	6. Security Considerations......................................17		6. Security Considerations......................................18
	7. Acknowledgements.............................................17		7. Acknowledgements.............................................18
	8. IANA Considerations..........................................17		8. IANA Considerations..........................................19
	9. Internationalization Considerations..........................18		9. Internationalization Considerations..........................20
	10. References..................................................18		10. References..................................................21
	10.1 Normative References....................................18		10.1 Normative References....................................21
	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
	or two-way measurements.		or two-way measurements.
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	Session-Receiver.		Session-Receiver.
	- Define the Session-Reflector behavior in place of the		- Define the Session-Reflector behavior in place of the
	Session-Receiver behavior of OWAMP [RFC4656].		Session-Receiver behavior of OWAMP [RFC4656].
	- Define a new test packet format for packets transmitted from the		- Define a new test packet format for packets transmitted from the
	Session-Reflector to Session-Sender.		Session-Reflector to Session-Sender.
	- Fetch client does not exist in the TWAMP architecture.		- Fetch client does not exist in the TWAMP architecture.
			All multi-octet quantities defined in this document are represented
			as unsigned integers in network byte order unless specified
			otherwise.
	3. TWAMP Control		3. TWAMP Control
	All TWAMP Control messages are similar in format and follow similar		TWAMP-Control is a derivative of the OWAMP-Control for two-way
	guidelines to those defined in section 3 of OWAMP [RFC4656] with		measurements. All TWAMP Control messages are similar in format and
	the exceptions outlined in the following sections. All OWAMP		follow similar guidelines to those defined in section 3 of OWAMP
	[RFC4656] Control messages except for the Fetch-Session command		[RFC4656] with the exceptions outlined in the following sections.
	apply to TWAMP.		All OWAMP [RFC4656] Control messages except for the Fetch-Session
			command apply to TWAMP.
	3.1 Connection Setup		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 [RFC4656]. The host that initiates		defined in section 3.1 of OWAMP [RFC4656]. The mode values are
	the TCP connection takes the roles of Control-Client and (in the		identical to OWAMP. The only exception is the well-known port
	two-host implementation) the Session-Sender. The host that		number for TWAMP-control. A client opens a TCP connection to the
	acknowledges the TCP connection accepts the roles of Server and (in		server on well-known port N (Refer to the IANA Considerations
	the two-host implementation) the Session Reflector.		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.
	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].		section 3.2 of OWAMP [RFC4656].
	3.3 Value of the Accept Fields		3.3 Value of the Accept Fields
	Accept values used in TWAMP are the same as the values defined in		Accept values used in TWAMP are the same as the values defined in
	section 3.3 of OWAMP [RFC4656].		section 3.3 of OWAMP [RFC4656].
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 39 ¶
	3.5 Creating Test Sessions		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.5 of OWAMP [RFC4656].		section 3.5 of OWAMP [RFC4656].
	In order to distinguish the session as a two-way versus a one-way		In order to distinguish the session as a two-way versus a one-way
	measurement session the first octet of the Request-Session command		measurement session the first octet of the Request-Session command
	MUST be set to 5. Value of 5 indicates that this is a		MUST be set to 5. Value of 5 indicates that this is a
	Request-Session for a two-way metrics measurement session.		Request-Session for a two-way metrics measurement session.
			In TWAMP, the first octet is referred to as the Command Number, and
			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 MUST
			respond with the Accept field set to 3 (meaning "Some aspect of
			request is not supported") in the Server-Start message.
	In OWAMP, the Conf-Sender field is set to 1 when the		In OWAMP, the Conf-Sender field is set to 1 when the
	Request-Session message describes a task where the Server will		Request-Session message describes a task where the Server will
	configure a one-way test packet sender. Likewise, the		configure a one-way test packet sender. Likewise, the
	Conf-Receiver field is set to 1 when the message describes the		Conf-Receiver field is set to 1 when the message describes the
	configuration for a Session-Receiver. In TWAMP, both endpoints		configuration for a Session-Receiver. In TWAMP, both endpoints
	perform in these roles, with the Session-Sender first sending and		perform in these roles, with the Session-Sender first sending and
	then receiving test packets. The Session-Reflector first receives		then receiving test packets. The Session-Reflector first receives
	the test packets, and returns each test packet to the		the test packets, and returns each test packet to the
	Session-Sender as fast as possible.		Session-Sender as fast as possible.
	skipping to change at page 12, line 13 ¶		skipping to change at page 13, line 13 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MBZ (12 octets) |		| MBZ (12 octets) |
	| |		| |
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp |		| Timestamp |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Error Estimate | |		| Error Estimate | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| MBZ (6 octets) |		| MBZ (6 octets) |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Receive Timestamp |		| Receive Timestamp |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MBZ (8 octets) |		| MBZ (8 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
	| Sender Sequence Number |		| Sender Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MBZ (12 octets) |		| MBZ (12 octets) |
	| |		| |
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Timestamp |		| Sender Timestamp |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Error Estimate | |		| Sender Error Estimate | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| MBZ (6 octets) |		| MBZ (6 octets) |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender TTL | |		| Sender TTL | |
	+++++++++++++++++ |		+++++++++++++++++ |
	| MBZ (7 octets) |
	| |		| |
			| |
			| MBZ (15 octets) |
	+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++		+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
	| HMAC (16 octets) |		| HMAC (16 octets) |
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
	| |		| |
	. .		. .
	. 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 transmit order.It starts with zero and is incremented by one
	is incremented by one for each subsequent packet. The Sequence		for each subsequent packet. The Sequence Number generated by the
	Number generated by the Session-Reflector is independent from the		Session-Reflector is independent from the sequence number of the
	sequence number of the arriving packets.		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.
	skipping to change at page 13, line 45 ¶		skipping to change at page 14, line 46 ¶
	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.
	Similar to OWAMP [RFC4656] 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-Sender packet follow the same rules of Session-Sender		Session-Sender packet follow the same rules of Session-Sender
	packets as defined in OWAMP [RFC4656].		packets as defined in OWAMP [RFC4656].
	The minimum data segment length is, therefore, 40 octets in		The minimum data segment length is, therefore, 41 octets in
	unauthenticated mode, and 80 octets in both authenticated mode and		unauthenticated mode, and 104 octets in both authenticated mode and
	encrypted modes (with the implication that the later two modes will		encrypted modes (with the implication that the later two modes will
	not fit in a single ATM cell).		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
	skipping to change at page 15, line 7 ¶		skipping to change at page 16, line 10 ¶
	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 an TWAMP-Test session.
	In encrypted mode, the first two blocks (32 octets) 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.
	Implementation note: Naturally, the key schedule for each		Implementation note: Naturally, the key schedule for each
	TWAMP-Test session MAY be set up only once per session, not once		TWAMP-Test session MAY be set up only once per session, not once
	skipping to change at page 16, line 43 ¶		skipping to change at page 17, line 46 ¶
	| 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-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.
	Session-Reflector SHOULD copy the sequence number of the received
	packet to the Sequence Number field of the reflected packet. This		In the case of TWAMP Light, the Session-Reflector does not
	is necessary since in case of TWAMP Light the Session-Reflector		necessarily have knowledge of the session state. IF the
	does not necessarily have knowledge of the session state. The		Session-Reflector does not have knowledge of the session state,
	controller receives the reflected test packets and collects two-way		THEN the Session-Reflector MUST copy the Sequence Number of the
	metrics. This architecture allows for collection of two-way		received packet to the Sequence Number field of the reflected
	metrics.		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		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 4.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.
	skipping to change at page 17, line 42 ¶		skipping to change at page 18, line 47 ¶
	authenticated mode of operation. The responder SHOULD be		authenticated mode of operation. The responder SHOULD be
	configurable to accept only authenticated control sessions.		configurable to accept only authenticated control sessions.
	The non-standard responder control protocol SHOULD have a means to		The non-standard responder control protocol SHOULD have a means to
	activate the authenticated and encrypted modes of the TWAMP-Test		activate the authenticated and encrypted modes of the TWAMP-Test
	protocol.		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,		Stanislav Shalunov, Matt Zekauskas, Walt Steverson and Jeff Boote
	helpful discussion and proof-reading.		for their comments, suggestions, reviews, 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.
	applies to the TWAMP-Control part of the TWAMP 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
			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".
			During final editing, port N in section 3.1 should be replaced with
			the assigned port number.
			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.
			8.1 Registry Specification
			IANA will create an TWAMP-Control Command registry. TWAMP-Control
			commands are specified by the first octet in OWAMP-Control messages
			as shown in section 3.4 of [RFC4656], and modified by this
			document. Thus this registry may contain sixteen possible values.
			8.2 Registry Management
			Because the registry may only contain sixteen values, and because
			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
			[RFC3692] recommends allocating an appropriate number of values for
			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
			TWAMP-Control Command Registry
			Value Description Semantics Definition
			0 Reserved
			1 Forbidden
			2 Start-Sessions RFC4656, Section 3.7
			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		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.
	10. References		10. References
	10.1 Normative References		10.1 Normative References
	skipping to change at page 18, line 34 ¶		skipping to change at page 21, line 25 ¶
	September 1999.		September 1999.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	Definition of the Differentiated Services Field (DS		Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	December 1998.		December 1998.
			[RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing
			an IANA Considerations Section in RFCs, RFC 2474,
			October 1998.
			10.2 Informative References
			[RFC3692] Narten, T., Assigning Experimental and Testing Numbers
			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/
End of changes. 24 change blocks.
	47 lines changed or deleted		142 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/