draft-ietf-ippm-port-twamp-test-04.txt		rfc8545.txt
	Network Working Group A. Morton, Ed.		Internet Engineering Task Force (IETF) A. Morton, Ed.
	Internet-Draft AT&T Labs		Request for Comments: 8545 AT&T Labs
	Updates: 4656 and 5357 (if approved) G. Mirsky, Ed.		Updates: 4656, 5357 G. Mirsky, Ed.
	Intended status: Standards Track ZTE Corp.		Category: Standards Track ZTE Corp.
	Expires: June 12, 2019 December 9, 2018		ISSN: 2070-1721 March 2019
	OWAMP and TWAMP Well-Known Port Assignments		Well-Known Port Assignments for
	draft-ietf-ippm-port-twamp-test-04		the One-Way Active Measurement Protocol (OWAMP) and
			the Two-Way Active Measurement Protocol (TWAMP)
	Abstract		Abstract
	This memo explains the motivation and describes the re-assignment of		This memo explains the motivation and describes the reassignment of
	well-known ports for the One-way Active Measurement Protocol and Two-		well-known ports for the One-Way Active Measurement Protocol (OWAMP)
	way Active Measurement Protocol (OWAMP and TWAMP) protocols for		and the Two-Way Active Measurement Protocol (TWAMP) for control and
	control and measurement, and clarifies the meaning and composition of		measurement. It also clarifies the meaning and composition of these
	these standards track protocol names for the industry.		Standards Track protocol names for the industry.
	The memo updates RFC 4656 and RFC 5357, in terms of the UDP well-		This memo updates RFCs 4656 and 5357, in terms of the UDP well-known
	known port assignments, and clarifies the complete OWAMP and TWAMP		port assignments, and it clarifies the complete OWAMP and TWAMP
	protocol composition for the industry.		protocol composition for the industry.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on June 12, 2019.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8545.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction ....................................................3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language ...........................................3
	3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Scope ...........................................................3
	4. Definitions and Background . . . . . . . . . . . . . . . . . 3		4. Definitions and Background ......................................3
	5. New Well-Known Ports . . . . . . . . . . . . . . . . . . . . 4		5. New Well-Known Ports ............................................5
	5.1. Impact on TWAMP-Control Protocol . . . . . . . . . . . . 4		5.1. Impact on TWAMP-Control Protocol ...........................5
	5.2. Impact on OWAMP-Control Protocol . . . . . . . . . . . . 5		5.2. Impact on OWAMP-Control Protocol ...........................6
	5.3. Impact on OWAMP/TWAMP-Test Protocols . . . . . . . . . . 5		5.3. Impact on OWAMP-Test/TWAMP-Test Protocols ..................6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations .........................................7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations .............................................8
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References ......................................................8
	9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 7		8.1. Normative References .......................................8
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8.2. Informative References .....................................9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. Background on TWAMP Light .............................10
	11.1. Normative References . . . . . . . . . . . . . . . . . . 8		Acknowledgements ..................................................11
	11.2. Informative References . . . . . . . . . . . . . . . . . 9		Contributors ......................................................11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses ................................................11
	1. Introduction		1. Introduction
	The IETF IP Performance Metrics (IPPM) working group first developed		The IETF IP Performance Metrics (IPPM) Working Group first developed
	the One-Way Active Measurement Protocol, OWAMP, specified in		the One-Way Active Measurement Protocol (OWAMP), as specified in
	[RFC4656]. Further protocol development to support testing resulted		[RFC4656]. Further protocol development to support testing resulted
	in the Two-Way Active Measurement Protocol, TWAMP, specified in		in the Two-Way Active Measurement Protocol (TWAMP), as specified in
	[RFC5357].		[RFC5357].
	Both OWAMP and TWAMP require the implementation of a control and mode		Both OWAMP and TWAMP require the implementation of a control and mode
	negotiation protocol (OWAMP-Control and TWAMP-Control) which employs		negotiation protocol (OWAMP-Control and TWAMP-Control) that employs
	the reliable transport services of TCP (including security		the reliable transport services of TCP (including security
	configuration and key derivation). The control protocols arrange for		configuration and key derivation). The control protocols arrange for
	the configuration and management of test sessions using the		the configuration and management of test sessions using the
	associated test protocol (OWAMP-Test or TWAMP-Test) on UDP transport.		associated test protocol (OWAMP-Test or TWAMP-Test) on UDP transport.
	In this memo, IETF recognizes the value of assigning a well-known UDP		The IETF recognizes the value of assigning a well-known UDP port to
	port to the *-Test protocols, and that this goal can easily be		the OWAMP-Test and TWAMP-Test protocols and also recognizes that this
	arranged through port re-assignments.		goal can be easily arranged through port reassignments.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119] [RFC8174] when, and only when, they appear in all capitals,		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	as shown here.		capitals, as shown here.
	3. Scope		3. Scope
	The scope of this memo is to re-allocate well-known ports for the UDP		The scope of this memo is twofold: (1) to reallocate the well-known
	Test protocols that compose necessary parts of their respective		ports for the UDP test protocols that compose necessary parts of
	standards track protocols, OWAMP and TWAMP, along with clarifications		their respective Standards Track protocols (OWAMP and TWAMP) and
	of the complete protocol composition for the industry.		(2) to clarify the meaning and composition of these Standards Track
			protocol names for the industry.
	The memo updates [RFC4656] and [RFC5357], in terms of the UDP well-		This memo updates [RFC4656] and [RFC5357], in terms of the UDP
	known port assignments.		well-known port assignments.
	4. Definitions and Background		4. Definitions and Background
	This section defines key terms and clarifies the required composition		This section defines key terms and clarifies the required composition
	of the OWAMP and TWAMP standards-track protocols.		of the OWAMP and TWAMP Standards Track protocols.
	OWAMP-Control is the protocol defined in Section 3 of [RFC4656].		"OWAMP-Control" is the protocol defined in Section 3 of [RFC4656].
	OWAMP-Test is the protocol defined in Section 4 of [RFC4656].		"OWAMP-Test" is the protocol defined in Section 4 of [RFC4656].
	OWAMP is described in a direct quote from Section 1.1 of[RFC4656]:		OWAMP is described in this direct quote from Section 1.1 of
	"OWAMP actually consists of two inter-related protocols: OWAMP-		[RFC4656]: "OWAMP actually consists of two inter-related protocols:
	Control and OWAMP-Test." A similar sentence appears in Section 2 of		OWAMP-Control and OWAMP-Test." A similar sentence appears in
	[RFC4656]. For avoidance of doubt, implementation of both OWAMP-		Section 2 of [RFC4656]. For avoidance of doubt, the implementation
	Control and OWAMP-Test are REQUIRED for standards-track OWAMP		of both OWAMP-Control and OWAMP-Test is REQUIRED for Standards Track
	specified in [RFC4656] (aplying the consensus of many dictionary		OWAMP as specified in [RFC4656] (applying the consensus of many
	definitions of "consist").		dictionary definitions of "consist").
	TWAMP-Control is the protocol defined in Section 3 of [RFC5357].		"TWAMP-Control" is the protocol defined in Section 3 of [RFC5357].
	TWAMP-Test is the protocol defined in Section 4 of [RFC5357].		"TWAMP-Test" is the protocol defined in Section 4 of [RFC5357].
	TWAMP is described in a direct quote from Section 1.1 of [RFC5357]:		TWAMP is described in this direct quote from Section 1.1 of
	"Similar to OWAMP [RFC4656], TWAMP consists of two inter-related		[RFC5357]: "Similar to OWAMP [RFC4656], TWAMP consists of two
	protocols: TWAMP-Control and TWAMP-Test." For avoidance of doubt,		inter-related protocols: TWAMP-Control and TWAMP-Test." For
	implementation of both TWAMP-Control and TWAMP-Test are REQUIRED for		avoidance of doubt, the implementation of both TWAMP-Control and
	standards-track TWAMP specified in [RFC5357] (aplying the consensus		TWAMP-Test is REQUIRED for Standards Track TWAMP as specified in
	of many dictionary definitions of "consist").		[RFC5357] (applying the consensus of many dictionary definitions of
			"consist").
	TWAMP Light is an idea described in Informative Appendix I of		"TWAMP Light" is an idea described in Appendix I ("TWAMP Light
	[RFC5357], and includes an un-specified control protocol combined		(Informative)") of [RFC5357]; TWAMP Light includes an unspecified
	with the TWAMP-Test protocol. The TWAMP Light idea was relegated to		control protocol combined with the TWAMP-Test protocol. In
	the Appendix because it failed to meet the requirements for IETF		[RFC5357], the TWAMP Light idea was relegated to Appendix I because
	protocols (there are no specifications for negotiating this form of		TWAMP Light failed to meet the requirements for IETF protocols (there
	operation, and no specifications for mandatory-to-implement security		are no specifications for negotiating this form of operation and no
	features), as described in Appendix A of this memo, which cites		specifications for mandatory-to-implement security features), as
	[LarsAD] and [TimDISCUSS] .		described in Appendix A of this memo. See also [LarsAD] and
			[TimDISCUSS].
	Since the idea of TWAMP Light clearly includes the TWAMP-Test		Since the idea of TWAMP Light clearly includes the TWAMP-Test
	component of TWAMP, it is considered reasonable for future systems to		component of TWAMP, it is considered reasonable for future systems to
	use the TWAMP-Test well-known UDP port (whose re-allocated assignment		use the TWAMP-Test well-known UDP port (whose reallocated assignment
	is requested here). Clearly, the TWAMP Light idea envisions many		is specified in this document). Clearly, the TWAMP Light idea
	components and communication capabilities beyond TWAMP-Test		envisions many components and communication capabilities beyond
	(implementing the security requirements, for example), otherwise		TWAMP-Test (implementing the security requirements, for example);
	Appendix I of [RFC5357] would be one sentence long (equivocating		otherwise, Appendix I of [RFC5357] would be one sentence long
	TWAMP Light with TWAMP-Test only).		(equating TWAMP Light with TWAMP-Test only).
	5. New Well-Known Ports		5. New Well-Known Ports
	Originally, both TCP and UDP well-known ports were assigned to the		Originally, both TCP and UDP well-known ports were assigned to the
	control protocols that are essential components of standards track		control protocols that are essential components of Standards Track
	OWAMP and TWAMP.		OWAMP and TWAMP.
	Since OWAMP-Control and TWAMP-Control require TCP transport, they		Since OWAMP-Control and TWAMP-Control require TCP transport, they
	cannot make use of the UDP ports which were originally assigned.		cannot make use of the UDP ports that were originally assigned.
	However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP		However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP
	transport.		transport.
	This memo requests re-assignment of the UDP well-known port from the		Per this memo, IANA has reassigned the UDP well-known port from the
	Control protocol to the Test protocol (see the IANA Considerations		control protocol to the test protocol (see Section 7 ("IANA
	Section 7). Use of this UDP port is OPTIONAL in standards-track		Considerations")). The use of this UDP port is OPTIONAL in Standards
	OWAMP and TWAMP. It may simplify some operations to have a well-		Track OWAMP and TWAMP. It may simplify some operations to have a
	known port available for the Test protocols, or for future		well-known port available for the test protocols or for future
	specifications involving TWAMP-Test to use this port as a default		specifications involving TWAMP-Test to use this port as a default
	port. For example, [TR-390] is a specification for testing at the		port. For example, [TR-390] is a specification for testing at the
	customer edge of IP networks, and whose implememntations should		customer edge of IP networks, and conforming implementations will
	benefit.		benefit from reallocation of the well-known UDP port to the test
			protocol.
	5.1. Impact on TWAMP-Control Protocol		5.1. Impact on TWAMP-Control Protocol
	Section 3.5 [RFC5357] describes the detailed process of negotiating		Section 3.5 of [RFC5357] describes the detailed process of
	the Receiver Port number, on which the TWAMP Session-Reflector will		negotiating the Receiver Port number, on which the TWAMP
	send and receive TWAMP-Test packets. The Control-Client, acting on		Session-Reflector will send and receive TWAMP-Test packets; see the
	behalf of the Session-Sender, proposes the Receiver port number from		quoted text below. The Control-Client, acting on behalf of the
	the Dynamic Port range [RFC6335]:		Session-Sender, proposes the Receiver Port number from the Dynamic
			Ports range [RFC6335]:
	"The Receiver Port is the desired UDP port to which TWAMP-Test		The Receiver Port is the desired UDP port to which TWAMP-Test
	packets will be sent by the Session-Sender (the port where the		packets will be sent by the Session-Sender (the port where the
	Session-Reflector is asked to receive test packets). The Receiver		Session-Reflector is asked to receive test packets). The Receiver
	Port is also the UDP port from which TWAMP-Test packets will be		Port is also the UDP port from which TWAMP-Test packets will be
	sent by the Session-Reflector (the Session-Reflector will use the		sent by the Session-Reflector (the Session-Reflector will use the
	same UDP port to send and receive packets)."		same UDP port to send and receive packets).
	It is possible that the proposed Receiver Port may be not available,		It is possible that the proposed Receiver Port may not be available,
	e.g., the port is in use by another test session or another		e.g., the port is in use by another test session or another
	application. In this case:		application. In this case, we update the last paragraph of
			Section 3.5 of [RFC5357] per Erratum ID 1587 (see
			<https://www.rfc-editor.org/errata/eid1587>) as follows:
	"... the Server at the Session-Reflector MAY suggest an alternate		... the Server at the Session-Reflector MAY suggest an alternate
	and available port for this session in the Port field. The		and available port for this session in the Port field. The
	Control-Client either accepts the alternate port, or composes a		Control-Client either accepts the alternate port or composes a new
	new Session-Request message with suitable parameters. Otherwise,		Session-Request message with suitable parameters. Otherwise, the
	the Server uses the Accept field to convey other forms of session		Server uses the Accept field to convey other forms of session
	rejection or failure to the Control Client and MUST NOT suggest an		rejection or failure to the Control-Client and MUST NOT suggest an
	alternate port; in this case, the Port field MUST be set to zero."		alternate port; in this case, the Port field MUST be set to zero.
	A Control Client that supports use of the allocated TWAMP-Test		A Control-Client that supports the use of the allocated TWAMP-Test
	Receiver Port Section 7 MAY request to use that port number in the		Receiver Port (Section 7) MAY request to use that port number in the
	Request-TW-Session Command. If the Server does not support the		Request-TW-Session command. If the Server does not support the
	allocated TWAMP-Test Receiver Port, then it sends an alternate port		allocated TWAMP-Test Receiver Port, then it sends an alternate port
	number in the Accept-Session message with Accept field = 0. Thus the		number in the Accept-Session message with Accept field = 0. Thus,
	deployment of the allocated TWAMP Receiver Port number is backward		the deployment of the allocated TWAMP Receiver Port number is
	compatible with existing TWAMP-Control solutions that are based on		backward compatible with existing TWAMP-Control solutions that are
	[RFC5357]. Of course, use of a UDP port number chosen from the		based on [RFC5357]. Of course, using a UDP port number chosen from
	Dynamic Port range [RFC6335] will help to avoid the situation when		the Dynamic Ports range [RFC6335] will help avoid the situation where
	the Control-Client or Server finds the proposed port being already in		the Control-Client or Server finds that the proposed port is already
	use.		in use.
	5.2. Impact on OWAMP-Control Protocol		5.2. Impact on OWAMP-Control Protocol
	As described above, an OWAMP Control Client that supports use of the		As described above, an OWAMP-Control client that supports the use of
	allocated OWAMP-Test Receiver Port Section 7 MAY request to use that		the allocated OWAMP-Test Receiver Port (Section 7) MAY request to use
	port number in the Request-Session Command. If the Server does not		that port number in the Request-Session command. If the Server does
	support the allocated OWAMP-Test Receiver Port (or does not have the		not support the allocated OWAMP-Test Receiver Port (or does not have
	port available), then it sends an alternate port number in the		the port available), then it sends an alternate port number in the
	Accept-Session message with Accept field = 0. Further exchanges		Accept-Session message with Accept field = 0. Further exchanges
	proceed as already specified.		proceed as already specified.
	5.3. Impact on OWAMP/TWAMP-Test Protocols		5.3. Impact on OWAMP-Test/TWAMP-Test Protocols
	OWAMP/TWAMP-Test may be used to measure IP performance metrics in an		OWAMP-Test/TWAMP-Test may be used to measure IP performance metrics
	Equal Cost Multipath (ECMP) environment. Though algorithms to		in an Equal-Cost Multipath (ECMP) environment. Though algorithms to
	balance IP flows among available paths have not been standardized,		balance IP flows among available paths have not been standardized,
	the most common is the five-tuple that uses destination IP address,		the most common is the five-tuple that uses destination IP address,
	source IP address, protocol type, destination port number, and source		source IP address, protocol type, destination port number, and source
	port number. When attempting to monitor different paths in ECMP		port number. When attempting to monitor different paths in an ECMP
	network, it is sufficient to vary only one of five parameters, e.g.		network, it is sufficient to vary only one of five parameters, e.g.,
	the source port number. Thus, there will be no negative impact on		the source port number. Thus, there will be no negative impact on
	ability to arrange concurrent OWAMP/TWAMP test sessions between the		the ability to arrange concurrent OWAMP/TWAMP test sessions between
	same test points to monitor different paths in the ECMP network when		the same test points to monitor different paths in the ECMP network
	using the re-allocated UDP port number as the Receiver Port, as use		when using the reallocated UDP port number as the Receiver Port, as
	of the port is optional.		using the port is optional.
	6. Security Considerations		6. Security Considerations
	The security considerations that apply to any active measurement of		The security considerations that apply to any active measurement of
	live paths are relevant here as well (see [RFC4656] and [RFC5357]).		live paths are relevant here as well (see [RFC4656] and [RFC5357]).
	When considering privacy of those involved in measurement or those		When considering the privacy of those involved in measurement or
	whose traffic is measured, the sensitive information available to		those whose traffic is measured, the sensitive information available
	potential observers is greatly reduced when using active techniques		to potential observers is greatly reduced when using active
	which are within this scope of work. Passive observations of user		techniques that are within this scope of work. Passive observations
	traffic for measurement purposes raise many privacy issues. We refer		of user traffic for measurement purposes raise many privacy issues.
	the reader to the security and privacy considerations described in		We refer the reader to the security and privacy considerations
	the Large Scale Measurement of Broadband Performance (LMAP) Framework		described in the Large-Scale Measurement of Broadband Performance
	[RFC7594], which covers both active and passive techniques.		(LMAP) framework [RFC7594], which covers both active and passive
			techniques.
	The registered UDP port as the Receiver Port for OWAMP/TWAMP-Test		The registered UDP port as the Receiver Port for OWAMP-Test/
	could become a target of denial-of-service (DoS), or used to aid man-		TWAMP-Test could become a target of denial of service (DoS) or could
	in-the-middle (MITM) attacks. To improve protection from the DoS		be used to aid man-in-the-middle (MITM) attacks. To improve
	following methods are recommended:		protection against DoS, the following methods are recommended:
	o filtering access to the OWAMP/TWAMP Receiver Port by access list;		o filtering access to the OWAMP/TWAMP Receiver Port via an
			access list.
	o using a non-globally routable IP address for the OWAMP/TWAMP		o using a non-globally routable IP address for the OWAMP/TWAMP
	Session-Reflector address.		Session-Reflector address.
	A MITM attack may try to modify the content of the OWAMP/TWAMP-Test		A MITM attacker may try to modify the contents of the OWAMP-Test/
	packets in order to alter the measurement results. However, an		TWAMP-Test packets in order to alter the measurement results.
	implementation can use authenticated mode to detect modification of		However, an implementation can use authenticated mode to detect
	data. In addition, use encrypted mode to prevent eavesdropping and		modification of data. In addition, an implementation can use
	un-detected modification of the OWAMP/TWAMP-Test packets.		encrypted mode to prevent eavesdropping and undetected modification
			of the OWAMP-Test/TWAMP-Test packets.
	There is also a risk of a network under test giving special treatment		There is also the risk of a network under test giving special
	to flows involving the well-known UDP port, with or without knowing		treatment to flows involving the well-known UDP port, with or without
	source and destination addresses of measurement systems, and thus		knowing source and destination addresses of measurement systems, and
	biasing the results through preferential or detrimental processing.		thus biasing the results through preferential or detrimental
			processing.
	7. IANA Considerations		7. IANA Considerations
	This memo requests re-allocation of two UDP port numbers from the		IANA has reallocated two UDP port numbers from the System Ports range
	System Ports range [RFC6335]. Specifically, this memo requests that		of the "Service Name and Transport Protocol Port Number Registry"
	IANA re-allocate UDP ports 861 and 862 as shown below, leaving the		[RFC6335]. Specifically, IANA has reallocated UDP ports 861 and 862
	TCP port assignments as-is:		as shown below, leaving the TCP port assignments as is. IANA has
			also updated the Assignee and Contact for these ports (both UDP and
	+------------+-------+---------+----------------------+-------------+		TCP) to be the IESG and the IETF Chair, respectively.
	| Service | Port | Transp. | Description | Reference |
	| Name | Num. | Protocol| | |
	| | | | | |
	+------------+-------+---------+----------------------+-------------+
	| owamp- | 861 | tcp | OWAMP-Control | [RFC4656] |
	| control | | | | |
	| owamp-test | 861 | udp | OWAMP-Test | [RFCXXXX] |
	| | | | | |
	| twamp- | 862 | tcp | TWAMP-Control | [RFC5357] |
	| control | | | | |
	| twamp-test | 862 | udp | TWAMP-Test Receiver | [RFCXXXX] |
	| | | | Port | |
	+------------+-------+---------+----------------------+-------------+
	Table 1 Re-allocated OWAMP and TWAMP Ports
	where RFCXXXX is this memo when published. The Assignee and Contact
	should information be updated as follows:
	Assignee: IESG
	Contact: IETF Chair
	8. Contributors
	Richard Foote and Luis M. Contreras made notable contributions on
	this topic.
	9. Appendix A
	This informative Appendix provides the Background on the decision to
	move the TWAMP Light idea to an informative Appendix in [RFC5357].
	The TWAMP Light idea was relegated to the Appendix because it failed
	to meet the requirements for IETF protocols (there are no
	specifications for negotiating this form of operation, and no
	specifications for mandatory-to-implement security features), as
	described in the references below:
	o Lars Eggert's Area Director review [LarsAD], where he pointed out
	that having two variants of TWAMP, Light and Complete (called
	standards track TWAMP here), required a protocol mechanism to
	negotiate which variant will be used. See Lars' comment on Sec
	5.2. The working group consensus was to place the TWAMP Light
	description in Appendix I, and to refer to the Appendix only as an
	"incremental path to adopting TWAMP, by implementing the TWAMP-
	Test protocol first".
	o Tim Polk's DISCUSS Ballot, which points out that TWAMP Light was
	an incomplete specification because the key required for
	authenticated and encrypted modes depended on the TWAMP-Control
	Session key. See Tim's DISCUSS on 2008-07-16 [TimDISCUSS].
	Additional requirement statements were added in the Appendix to
	address Tim's DISCUSS Ballot (see the last three paragraphs of
	Appendix I in [RFC5357]).
	Since the idea of TWAMP Light clearly includes the TWAMP-Test
	protocol and other undefined facilities, Appendix I of [RFC5357]
	simply describes ideas of how TWAMP-Test might be used ouside of the
	context of Standards-Track TWAMP.
	10. Acknowledgements
	The authors thank the IPPM working group for their rapid review; also		+---------------+--------+-----------+------------------+-----------+
	Muthu Arul Mozhi Perumal and Luay Jalil for their participation and		| Service | Port | Transport | Description | Reference |
	suggestions.		| Name | Number | Protocol | | |
			+---------------+--------+-----------+------------------+-----------+
			| owamp-control | 861 | tcp | OWAMP-Control | RFC 4656 |
			| owamp-test | 861 | udp | OWAMP-Test | RFC 8545 |
			| | | | Receiver Port | |
			| | | | | |
			| twamp-control | 862 | tcp | TWAMP-Control | RFC 5357 |
			| twamp-test | 862 | udp | TWAMP-Test | RFC 8545 |
			| | | | Receiver Port | |
			+---------------+--------+-----------+------------------+-----------+
	11. References		8. References
	11.1. Normative References		8.1. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.		[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and
	Zekauskas, "A One-way Active Measurement Protocol		M. Zekauskas, "A One-way Active Measurement Protocol
	(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,		(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
	<https://www.rfc-editor.org/info/rfc4656>.		<https://www.rfc-editor.org/info/rfc4656>.
	[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.		[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and
	Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",		J. Babiarz, "A Two-Way Active Measurement Protocol
	RFC 5357, DOI 10.17487/RFC5357, October 2008,		(TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008,
	<https://www.rfc-editor.org/info/rfc5357>.		<https://www.rfc-editor.org/info/rfc5357>.
	[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.		[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and
	Cheshire, "Internet Assigned Numbers Authority (IANA)		S. Cheshire, "Internet Assigned Numbers Authority (IANA)
	Procedures for the Management of the Service Name and		Procedures for the Management of the Service Name and
	Transport Protocol Port Number Registry", BCP 165,		Transport Protocol Port Number Registry", BCP 165,
	RFC 6335, DOI 10.17487/RFC6335, August 2011,		RFC 6335, DOI 10.17487/RFC6335, August 2011,
	<https://www.rfc-editor.org/info/rfc6335>.		<https://www.rfc-editor.org/info/rfc6335>.
	[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,		[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
	Aitken, P., and A. Akhter, "A Framework for Large-Scale		Aitken, P., and A. Akhter, "A Framework for Large-Scale
	Measurement of Broadband Performance (LMAP)", RFC 7594,		Measurement of Broadband Performance (LMAP)", RFC 7594,
	DOI 10.17487/RFC7594, September 2015,		DOI 10.17487/RFC7594, September 2015,
	<https://www.rfc-editor.org/info/rfc7594>.		<https://www.rfc-editor.org/info/rfc7594>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		RFC 2119 Key Words", BCP 14, RFC 8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		DOI 10.17487/RFC8174, May 2017,
			<https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		8.2. Informative References
	[LarsAD] "https://mailarchive.ietf.org/arch/msg/ippm/		[IPPM-TWAMP-06]
	LzcTPYhPhWhbb5-ncR046XKpnzo", April 2008.		Hedayat, K., Krzanowski, R., Yum, K., Morton, A., and
			J. Babiarz, "A Two-way Active Measurement Protocol
			(TWAMP)", Work in Progress, draft-ietf-ippm-twamp-06,
			December 2007.
			[LarsAD] Eggert, L., "Subject: [ippm] AD review:
			draft-ietf-ippm-twamp-06.txt", message to the ippm mailing
			list, April 2008, <https://mailarchive.ietf.org/
			rch/msg/ippm/LzcTPYhPhWhbb5-ncR046XKpnzo>.
	[TimDISCUSS]		[TimDISCUSS]
	"https://datatracker.ietf.org/doc/rfc5357/history/", July		"Tim Polk's Ballot discuss", July 2008,
	2008.		<https://datatracker.ietf.org/doc/rfc5357/history>.
	[TR-390] "TR-390 Performance Measurement from IP Edge to Custom er		[TR-390] Broadband Forum, "TR-390: Performance Measurement from IP
	Equipment using TWAMP Light, Issue: 1", May 2017,		Edge to Customer Equipment using TWAMP Light", Issue: 1,
	<https://www.broadband-forum.org/technical/download/		May 2017, <https://www.broadband-forum.org/technical/
	TR-390.pdf>.		download/TR-390.pdf>.
			Appendix A. Background on TWAMP Light
			This informative appendix provides the background on the decision to
			move the TWAMP Light idea to an informative appendix in [RFC5357].
			As also noted in Section 4, the TWAMP Light idea was relegated to
			Appendix I of [RFC5357] because it failed to meet the requirements
			for IETF protocols (there are no specifications for negotiating this
			form of operation and no specifications for mandatory-to-implement
			security features), as described in the references cited below:
			o Lars Eggert's Area Director review [LarsAD], where he pointed out
			that having two variants of TWAMP (TWAMP Light and Complete TWAMP)
			requires a protocol mechanism to negotiate which variant will be
			used. Note that "Complete TWAMP" is called "Standards Track
			TWAMP" in this document. See Lars's "Section 5.2, paragraph 0"
			comment on [LarsAD], which refers to a section in [IPPM-TWAMP-06].
			The working group consensus was to place the TWAMP Light
			description in Appendix I and to refer to that appendix only as an
			"incremental path to adopting TWAMP, by implementing the
			TWAMP-Test protocol first."
			o Tim Polk's "Ballot discuss" of 2008-07-16 [TimDISCUSS], which
			points out that TWAMP Light was an incomplete specification
			because the key required for authenticated and encrypted modes
			depended on the TWAMP-Control Session key. Additional requirement
			statements were added in Appendix I to address Tim's Ballot
			discuss (see the last three paragraphs of Appendix I in
			[RFC5357]).
			Since the idea of TWAMP Light clearly includes the TWAMP-Test
			protocol and other undefined facilities, Appendix I of [RFC5357]
			simply describes ideas for how TWAMP-Test might be used outside of
			the context of Standards Track TWAMP.
			Acknowledgements
			The authors thank the IPPM Working Group for their rapid review;
			thanks also to Muthu Arul Mozhi Perumal and Luay Jalil for their
			participation and suggestions.
			Contributors
			Richard Foote and Luis M. Contreras made notable contributions on
			this topic.
	Authors' Addresses		Authors' Addresses
	Al Morton (editor)		Al Morton (editor)
	AT&T Labs		AT&T Labs
	200 Laurel Avenue South		200 Laurel Avenue South
	Middletown, NJ 07748		Middletown, NJ 07748
	USA		United States of America
	Phone: +1 732 420 1571		Phone: +1 732 420 1571
	Fax: +1 732 368 1192		Fax: +1 732 368 1192
	Email: acmorton@att.com		Email: acmorton@att.com
	Greg Mirsky (editor)		Greg Mirsky (editor)
	ZTE Corp.		ZTE Corp.
	Email: gregimirsky@gmail.com		Email: gregimirsky@gmail.com
End of changes. 61 change blocks.
	254 lines changed or deleted		265 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/