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/