draft-ietf-ippm-port-twamp-test-02.txt		draft-ietf-ippm-port-twamp-test-03.txt
	Network Working Group A. Morton, Ed.		Network Working Group A. Morton, Ed.
	Internet-Draft AT&T Labs		Internet-Draft AT&T Labs
	Updates: 4656 and 5357 (if approved) G. Mirsky, Ed.		Updates: 4656 and 5357 (if approved) G. Mirsky, Ed.
	Intended status: Standards Track ZTE Corp.		Intended status: Standards Track ZTE Corp.
	Expires: April 7, 2019 October 4, 2018		Expires: May 8, 2019 November 4, 2018
	OWAMP and TWAMP Well-Known Port Assignments		OWAMP and TWAMP Well-Known Port Assignments
	draft-ietf-ippm-port-twamp-test-02		draft-ietf-ippm-port-twamp-test-03
	Abstract		Abstract
	This memo explains the motivation and describes the re-assignment of		This memo explains the motivation and describes the re-assignment of
	well-known ports for the OWAMP and TWAMP protocols for control and		well-known ports for the OWAMP and TWAMP protocols for control and
	measurement, and clarifies the meaning and composition of these		measurement, and clarifies the meaning and composition of 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-		The memo updates RFC 4656 and RFC 5357, in terms of the UDP well-
	known port assignments.		known port assignments, and clarifies the complete OWAMP and TWAMP
			protocol composition for the industry.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 7, 2019.		This Internet-Draft will expire on May 8, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3		4. Definitions and Background . . . . . . . . . . . . . . . . . 3
	5. New Well-Known Ports . . . . . . . . . . . . . . . . . . . . 4		5. New Well-Known Ports . . . . . . . . . . . . . . . . . . . . 4
	5.1. Impact on TWAMP-Control Protocol . . . . . . . . . . . . 5		5.1. Impact on TWAMP-Control Protocol . . . . . . . . . . . . 4
	5.2. Impact on OWAMP-Control Protocol . . . . . . . . . . . . 5		5.2. Impact on OWAMP-Control Protocol . . . . . . . . . . . . 5
	5.3. Impact on OWAMP/TWAMP-Test Protocols . . . . . . . . . . 6		5.3. Impact on OWAMP/TWAMP-Test Protocols . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 7
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . 7		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		11.2. Informative References . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	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, 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, 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
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 23 ¶
	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 to re-allocate well-known ports for the UDP
	Test protocols that compose necessary parts of their respective		Test protocols that compose necessary parts of their respective
	standards track protocols, OWAMP and TWAMP, along with clarifications		standards track protocols, OWAMP and TWAMP, along with clarifications
	of the complete protocol composition for the industry.		of the complete protocol composition for the industry.
	The memo updates [RFC4656] and [RFC5357], in terms of the UDP well-		The memo updates [RFC4656] and [RFC5357], in terms of the UDP well-
	known port assignments.		known port assignments.
	4. Definitions		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 a direct quote from Section 1.1 of[RFC4656]:
	"OWAMP actually consists of two inter-related protocols: OWAMP-		"OWAMP actually consists of two inter-related protocols: OWAMP-
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 9 ¶
	implementation of both TWAMP-Control and TWAMP-Test are REQUIRED for		implementation of both TWAMP-Control and TWAMP-Test are REQUIRED for
	standards-track TWAMP specified in [RFC5357].		standards-track TWAMP specified in [RFC5357].
	TWAMP Light is an idea described in Informative Appendix I of		TWAMP Light is an idea described in Informative Appendix I of
	[RFC5357], and includes an un-specified control protocol (possibly		[RFC5357], and includes an un-specified control protocol (possibly
	communicating through non-standard means) combined with the TWAMP-		communicating through non-standard means) combined with the TWAMP-
	Test protocol. The TWAMP Light idea was relegated to the		Test protocol. The TWAMP Light idea was relegated to the
	Appendix because it failed to meet the requirements for IETF		Appendix because it failed to meet the requirements for IETF
	protocols (there are no specifications for negotiating this form of		protocols (there are no specifications for negotiating this form of
	operation, and no specifications for mandatory-to-implement security		operation, and no specifications for mandatory-to-implement security
	features), as described in the references below:		features), as described in Appendix A of this memo, which cites
			[LarsAD] and [TimDISCUSS] .
	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		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 re-allocated assignment
	is requested here). Clearly, the TWAMP Light idea envisions many		is requested here). Clearly, the TWAMP Light idea envisions many
	components and communication capabilities beyond TWAMP-Test		components and communication capabilities beyond TWAMP-Test
	(implementing the security requirements, for example), otherwise the		(implementing the security requirements, for example), otherwise
	Appendix would be one sentence long (equivocating TWAMP Light with		Appendix I of [RFC5357] would be one sentence long (equivocating
	TWAMP-Test only).		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 which 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		This memo requests re-assignment of the UDP well-known port from the
	Control protocol to the Test protocol (see the IANA Considerations		Control protocol to the Test protocol (see the IANA Considerations
	Section 7). Use of this UDP port is OPTIONAL in standards-track		Section 7). Use of this UDP port is OPTIONAL in standards-track
	OWAMP and TWAMP. It may simplify some operations to have a well-		OWAMP and TWAMP. It may simplify some operations to have a well-
	known port available for the Test protocols, or for future		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.		port. For example, [TR-390] is a specification for testing at the
			customer edge of IP networks, and whose implememntations should
			benefit.
	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 [RFC5357] describes the detailed process of negotiating
	the Receiver Port number, on which the TWAMP Session-Reflector will		the Receiver Port number, on which the TWAMP Session-Reflector will
	send and receive TWAMP-Test packets. The Control-Client, acting on		send and receive TWAMP-Test packets. The Control-Client, acting on
	behalf of the Session-Sender, proposes the Receiver port number from		behalf of the Session-Sender, proposes the Receiver port number from
	the Dynamic Port range [RFC6335]:		the Dynamic Port 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
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 22 ¶
	| owamp-test | 861 | udp | OWAMP-Test | [RFCXXXX] |		| owamp-test | 861 | udp | OWAMP-Test | [RFCXXXX] |
	| | | | | |		| | | | | |
	| twamp- | 862 | tcp | TWAMP-Control | [RFC5357] |		| twamp- | 862 | tcp | TWAMP-Control | [RFC5357] |
	| control | | | | |		| control | | | | |
	| twamp-test | 862 | udp | TWAMP-Test Receiver | [RFCXXXX] |		| twamp-test | 862 | udp | TWAMP-Test Receiver | [RFCXXXX] |
	| | | | Port | |		| | | | Port | |
	+------------+-------+---------+----------------------+-------------+		+------------+-------+---------+----------------------+-------------+
	Table 1 Re-allocated OWAMP and TWAMP Ports		Table 1 Re-allocated OWAMP and TWAMP Ports
	where RFCXXXX is this memo when published.		where RFCXXXX is this memo when published. The Assignee and Contact
			should information be updated as follows:
			Assignee: IESG
			Contact: IETF Chair
	8. Contributors		8. Contributors
	Richard Foote and Luis M. Contreras made notable contributions on		Richard Foote and Luis M. Contreras made notable contributions on
	this topic.		this topic.
	9. Acknowledgements		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		The authors thank the IPPM working group for their rapid review; also
	Muthu Arul Mozhi Perumal and Luay Jalil for their participation and		Muthu Arul Mozhi Perumal and Luay Jalil for their participation and
	suggestions.		suggestions.
	10. References		11. References
	10.1. Normative References		11.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 M.
	Zekauskas, "A One-way Active Measurement Protocol		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>.
	skipping to change at page 8, line 32 ¶		skipping to change at page 9, line 15 ¶
	[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 RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	10.2. Informative References		11.2. Informative References
	[LarsAD] "https://mailarchive.ietf.org/arch/msg/ippm/		[LarsAD] "https://mailarchive.ietf.org/arch/msg/ippm/
	LzcTPYhPhWhbb5-ncR046XKpnzo", April 2008.		LzcTPYhPhWhbb5-ncR046XKpnzo", April 2008.
	[TimDISCUSS]		[TimDISCUSS]
	"https://datatracker.ietf.org/doc/rfc5357/history/", July		"https://datatracker.ietf.org/doc/rfc5357/history/", July
	2008.		2008.
			[TR-390] "TR-390 Performance Measurement from IP Edge to Custom er
			Equipment using TWAMP Light, Issue: 1", May 2017,
			<https://www.broadband-forum.org/technical/download/
			TR-390.pdf>.
	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		USA
	Phone: +1 732 420 1571		Phone: +1 732 420 1571
	Fax: +1 732 368 1192		Fax: +1 732 368 1192
End of changes. 20 change blocks.
	42 lines changed or deleted		73 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/