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/