<pre>Internet Engineering Task Force (IETF)                    A. Morton, Ed.
Request for Comments: 8545                                     AT&amp;T Labs
Updates: <a href="./rfc4656">4656</a>, <a href="./rfc5357">5357</a>                                       G. Mirsky, Ed.
Category: Standards Track                                      ZTE Corp.
ISSN: 2070-1721                                               March 2019


                    <span class="h1">Well-Known Port Assignments for</span>
          <span class="h1">the One-Way Active Measurement Protocol (OWAMP) and</span>
            <span class="h1">the Two-Way Active Measurement Protocol (TWAMP)</span>

Abstract

   This memo explains the motivation and describes the reassignment of
   well-known ports for the One-Way Active Measurement Protocol (OWAMP)
   and the Two-Way Active Measurement Protocol (TWAMP) for control and
   measurement.  It also clarifies the meaning and composition of these
   Standards Track protocol names for the industry.

   This memo updates RFCs 4656 and 5357, in terms of the UDP well-known
   port assignments, and it clarifies the complete OWAMP and TWAMP
   protocol composition for the industry.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc7841#section-2">Section&nbsp;2 of RFC 7841</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="https://www.rfc-editor.org/info/rfc8545">https://www.rfc-editor.org/info/rfc8545</a>.















<span class="grey">Morton &amp; Mirsky              Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8545">RFC 8545</a>              OWAMP/TWAMP Well-Known Ports            March 2019</span>


Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
   <a href="#section-2">2</a>. Requirements Language ...........................................<a href="#page-3">3</a>
   <a href="#section-3">3</a>. Scope ...........................................................<a href="#page-3">3</a>
   <a href="#section-4">4</a>. Definitions and Background ......................................<a href="#page-3">3</a>
   <a href="#section-5">5</a>. New Well-Known Ports ............................................<a href="#page-5">5</a>
      <a href="#section-5.1">5.1</a>. Impact on TWAMP-Control Protocol ...........................<a href="#page-5">5</a>
      <a href="#section-5.2">5.2</a>. Impact on OWAMP-Control Protocol ...........................<a href="#page-6">6</a>
      <a href="#section-5.3">5.3</a>. Impact on OWAMP-Test/TWAMP-Test Protocols ..................<a href="#page-6">6</a>
   <a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-7">7</a>
   <a href="#section-7">7</a>. IANA Considerations .............................................<a href="#page-8">8</a>
   <a href="#section-8">8</a>. References ......................................................<a href="#page-8">8</a>
      <a href="#section-8.1">8.1</a>. Normative References .......................................<a href="#page-8">8</a>
      <a href="#section-8.2">8.2</a>. Informative References .....................................<a href="#page-9">9</a>
   <a href="#appendix-A">Appendix A</a>. Background on TWAMP Light .............................<a href="#page-10">10</a>
   Acknowledgements ..................................................<a href="#page-11">11</a>
   Contributors ......................................................<a href="#page-11">11</a>
   Authors' Addresses ................................................<a href="#page-11">11</a>

















<span class="grey">Morton &amp; Mirsky              Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8545">RFC 8545</a>              OWAMP/TWAMP Well-Known Ports            March 2019</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The IETF IP Performance Metrics (IPPM) Working Group first developed
   the One-Way Active Measurement Protocol (OWAMP), as specified in
   [<a href="./rfc4656" title="&quot;A One-way Active Measurement Protocol (OWAMP)&quot;">RFC4656</a>].  Further protocol development to support testing resulted
   in the Two-Way Active Measurement Protocol (TWAMP), as specified in
   [<a href="./rfc5357" title="&quot;A Two-Way Active Measurement Protocol (TWAMP)&quot;">RFC5357</a>].

   Both OWAMP and TWAMP require the implementation of a control and mode
   negotiation protocol (OWAMP-Control and TWAMP-Control) that employs
   the reliable transport services of TCP (including security
   configuration and key derivation).  The control protocols arrange for
   the configuration and management of test sessions using the
   associated test protocol (OWAMP-Test or TWAMP-Test) on UDP transport.

   The IETF recognizes the value of assigning a well-known UDP port to
   the OWAMP-Test and TWAMP-Test protocols and also recognizes that this
   goal can be easily arranged through port reassignments.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Requirements Language</span>

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>] [<a href="./rfc8174" title="&quot;Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words&quot;">RFC8174</a>] when, and only when, they appear in all
   capitals, as shown here.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Scope</span>

   The scope of this memo is twofold: (1) to reallocate the well-known
   ports for the UDP test protocols that compose necessary parts of
   their respective Standards Track protocols (OWAMP and TWAMP) and
   (2) to clarify the meaning and composition of these Standards Track
   protocol names for the industry.

   This memo updates [<a href="./rfc4656" title="&quot;A One-way Active Measurement Protocol (OWAMP)&quot;">RFC4656</a>] and [<a href="./rfc5357" title="&quot;A Two-Way Active Measurement Protocol (TWAMP)&quot;">RFC5357</a>], in terms of the UDP
   well-known port assignments.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Definitions and Background</span>

   This section defines key terms and clarifies the required composition
   of the OWAMP and TWAMP Standards Track protocols.

   "OWAMP-Control" is the protocol defined in <a href="./rfc4656#section-3">Section&nbsp;3 of [RFC4656]</a>.

   "OWAMP-Test" is the protocol defined in <a href="./rfc4656#section-4">Section&nbsp;4 of [RFC4656]</a>.





<span class="grey">Morton &amp; Mirsky              Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8545">RFC 8545</a>              OWAMP/TWAMP Well-Known Ports            March 2019</span>


   OWAMP is described in this direct quote from <a href="./rfc4656#section-1.1">Section&nbsp;1.1 of
   [RFC4656]</a>: "OWAMP actually consists of two inter-related protocols:
   OWAMP-Control and OWAMP-Test."  A similar sentence appears in
   <a href="./rfc4656#section-2">Section&nbsp;2 of [RFC4656]</a>.  For avoidance of doubt, the implementation
   of both OWAMP-Control and OWAMP-Test is REQUIRED for Standards Track
   OWAMP as specified in [<a href="./rfc4656" title="&quot;A One-way Active Measurement Protocol (OWAMP)&quot;">RFC4656</a>] (applying the consensus of many
   dictionary definitions of "consist").

   "TWAMP-Control" is the protocol defined in <a href="./rfc5357#section-3">Section&nbsp;3 of [RFC5357]</a>.

   "TWAMP-Test" is the protocol defined in <a href="./rfc5357#section-4">Section&nbsp;4 of [RFC5357]</a>.

   TWAMP is described in this direct quote from <a href="./rfc5357#section-1.1">Section&nbsp;1.1 of
   [RFC5357]</a>: "Similar to OWAMP [<a href="./rfc4656" title="&quot;A One-way Active Measurement Protocol (OWAMP)&quot;">RFC4656</a>], TWAMP consists of two
   inter-related protocols: TWAMP-Control and TWAMP-Test."  For
   avoidance of doubt, the implementation of both TWAMP-Control and
   TWAMP-Test is REQUIRED for Standards Track TWAMP as specified in
   [<a href="./rfc5357" title="&quot;A Two-Way Active Measurement Protocol (TWAMP)&quot;">RFC5357</a>] (applying the consensus of many dictionary definitions of
   "consist").

   "TWAMP Light" is an idea described in <a href="#appendix-I">Appendix I</a> ("TWAMP Light
   (Informative)") of [<a href="./rfc5357" title="&quot;A Two-Way Active Measurement Protocol (TWAMP)&quot;">RFC5357</a>]; TWAMP Light includes an unspecified
   control protocol combined with the TWAMP-Test protocol.  In
   [<a href="./rfc5357" title="&quot;A Two-Way Active Measurement Protocol (TWAMP)&quot;">RFC5357</a>], the TWAMP Light idea was relegated to <a href="#appendix-I">Appendix I</a> because
   TWAMP Light 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 <a href="#appendix-A">Appendix A</a> of this memo.  See also [<a href="#ref-LarsAD" title="&quot;Subject: [ippm] AD review: draft-ietf-ippm-twamp-06.txt&quot;">LarsAD</a>] and
   [<a href="#ref-TimDISCUSS">TimDISCUSS</a>].

   Since the idea of TWAMP Light clearly includes the TWAMP-Test
   component of TWAMP, it is considered reasonable for future systems to
   use the TWAMP-Test well-known UDP port (whose reallocated assignment
   is specified in this document).  Clearly, the TWAMP Light idea
   envisions many components and communication capabilities beyond
   TWAMP-Test (implementing the security requirements, for example);
   otherwise, <a href="./rfc5357#appendix-I">Appendix&nbsp;I of [RFC5357]</a> would be one sentence long
   (equating TWAMP Light with TWAMP-Test only).













<span class="grey">Morton &amp; Mirsky              Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8545">RFC 8545</a>              OWAMP/TWAMP Well-Known Ports            March 2019</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  New Well-Known Ports</span>

   Originally, both TCP and UDP well-known ports were assigned to the
   control protocols that are essential components of Standards Track
   OWAMP and TWAMP.

   Since OWAMP-Control and TWAMP-Control require TCP transport, they
   cannot make use of the UDP ports that were originally assigned.
   However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP
   transport.

   Per this memo, IANA has reassigned the UDP well-known port from the
   control protocol to the test protocol (see <a href="#section-7">Section 7</a> ("IANA
   Considerations")).  The use of this UDP port is OPTIONAL in Standards
   Track OWAMP and TWAMP.  It may simplify some operations to have a
   well-known port available for the test protocols or for future
   specifications involving TWAMP-Test to use this port as a default
   port.  For example, [<a href="#ref-TR-390" title="&quot;TR-390: Performance Measurement from IP Edge to Customer Equipment using TWAMP Light&quot;">TR-390</a>] is a specification for testing at the
   customer edge of IP networks, and conforming implementations will
   benefit from reallocation of the well-known UDP port to the test
   protocol.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Impact on TWAMP-Control Protocol</span>

   <a href="./rfc5357#section-3.5">Section&nbsp;3.5 of [RFC5357]</a> describes the detailed process of
   negotiating the Receiver Port number, on which the TWAMP
   Session-Reflector will send and receive TWAMP-Test packets; see the
   quoted text below.  The Control-Client, acting on behalf of the
   Session-Sender, proposes the Receiver Port number from the Dynamic
   Ports range [<a href="./rfc6335" title="&quot;Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry&quot;">RFC6335</a>]:

      The Receiver Port is the desired UDP port to which TWAMP-Test
      packets will be sent by the Session-Sender (the port where the
      Session-Reflector is asked to receive test packets).  The Receiver
      Port is also the UDP port from which TWAMP-Test packets will be
      sent by the Session-Reflector (the Session-Reflector will use the
      same UDP port to send and receive packets).

   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
   application.  In this case, we update the last paragraph of
   <a href="./rfc5357#section-3.5">Section&nbsp;3.5 of [RFC5357]</a> per Erratum ID 1587 (see
   &lt;<a href="https://www.rfc-editor.org/errata/eid1587">https://www.rfc-editor.org/errata/eid1587</a>&gt;) as follows:

      ... the Server at the Session-Reflector MAY suggest an alternate
      and available port for this session in the Port field.  The
      Control-Client either accepts the alternate port or composes a new
      Session-Request message with suitable parameters.  Otherwise, the



<span class="grey">Morton &amp; Mirsky              Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8545">RFC 8545</a>              OWAMP/TWAMP Well-Known Ports            March 2019</span>


      Server uses the Accept field to convey other forms of session
      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.

   A Control-Client that supports the use of the allocated TWAMP-Test
   Receiver Port (<a href="#section-7">Section 7</a>) MAY request to use that port number in the
   Request-TW-Session command.  If the Server does not support the
   allocated TWAMP-Test Receiver Port, then it sends an alternate port
   number in the Accept-Session message with Accept field = 0.  Thus,
   the deployment of the allocated TWAMP Receiver Port number is
   backward compatible with existing TWAMP-Control solutions that are
   based on [<a href="./rfc5357" title="&quot;A Two-Way Active Measurement Protocol (TWAMP)&quot;">RFC5357</a>].  Of course, using a UDP port number chosen from
   the Dynamic Ports range [<a href="./rfc6335" title="&quot;Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry&quot;">RFC6335</a>] will help avoid the situation where
   the Control-Client or Server finds that the proposed port is already
   in use.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Impact on OWAMP-Control Protocol</span>

   As described above, an OWAMP-Control client that supports the use of
   the allocated OWAMP-Test Receiver Port (<a href="#section-7">Section 7</a>) MAY request to use
   that port number in the Request-Session command.  If the Server does
   not support the allocated OWAMP-Test Receiver Port (or does not have
   the port available), then it sends an alternate port number in the
   Accept-Session message with Accept field = 0.  Further exchanges
   proceed as already specified.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Impact on OWAMP-Test/TWAMP-Test Protocols</span>

   OWAMP-Test/TWAMP-Test may be used to measure IP performance metrics
   in an Equal-Cost Multipath (ECMP) environment.  Though algorithms to
   balance IP flows among available paths have not been standardized,
   the most common is the five-tuple that uses destination IP address,
   source IP address, protocol type, destination port number, and source
   port number.  When attempting to monitor different paths in an ECMP
   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 ability to arrange concurrent OWAMP/TWAMP test sessions between
   the same test points to monitor different paths in the ECMP network
   when using the reallocated UDP port number as the Receiver Port, as
   using the port is optional.











<span class="grey">Morton &amp; Mirsky              Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8545">RFC 8545</a>              OWAMP/TWAMP Well-Known Ports            March 2019</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Security Considerations</span>

   The security considerations that apply to any active measurement of
   live paths are relevant here as well (see [<a href="./rfc4656" title="&quot;A One-way Active Measurement Protocol (OWAMP)&quot;">RFC4656</a>] and [<a href="./rfc5357" title="&quot;A Two-Way Active Measurement Protocol (TWAMP)&quot;">RFC5357</a>]).

   When considering the privacy of those involved in measurement or
   those whose traffic is measured, the sensitive information available
   to potential observers is greatly reduced when using active
   techniques that are within this scope of work.  Passive observations
   of user traffic for measurement purposes raise many privacy issues.
   We refer the reader to the security and privacy considerations
   described in the Large-Scale Measurement of Broadband Performance
   (LMAP) framework [<a href="./rfc7594" title="&quot;A Framework for Large-Scale Measurement of Broadband Performance (LMAP)&quot;">RFC7594</a>], which covers both active and passive
   techniques.

   The registered UDP port as the Receiver Port for OWAMP-Test/
   TWAMP-Test could become a target of denial of service (DoS) or could
   be used to aid man-in-the-middle (MITM) attacks.  To improve
   protection against DoS, the following methods are recommended:

   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
      Session-Reflector address.

   A MITM attacker may try to modify the contents of the OWAMP-Test/
   TWAMP-Test packets in order to alter the measurement results.
   However, an implementation can use authenticated mode to detect
   modification of data.  In addition, an implementation can use
   encrypted mode to prevent eavesdropping and undetected modification
   of the OWAMP-Test/TWAMP-Test packets.

   There is also the risk of a network under test giving special
   treatment to flows involving the well-known UDP port, with or without
   knowing source and destination addresses of measurement systems, and
   thus biasing the results through preferential or detrimental
   processing.













<span class="grey">Morton &amp; Mirsky              Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8545">RFC 8545</a>              OWAMP/TWAMP Well-Known Ports            March 2019</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  IANA Considerations</span>

   IANA has reallocated two UDP port numbers from the System Ports range
   of the "Service Name and Transport Protocol Port Number Registry"
   [<a href="./rfc6335" title="&quot;Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry&quot;">RFC6335</a>].  Specifically, IANA has reallocated UDP ports 861 and 862
   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   | Transport | Description      | Reference |
   | Name          | Number | Protocol  |                  |           |
   +---------------+--------+-----------+------------------+-----------+
   | owamp-control | 861    | tcp       | OWAMP-Control    | <a href="./rfc4656">RFC 4656</a>  |
   | owamp-test    | 861    | udp       | OWAMP-Test       | <a href="./rfc8545">RFC 8545</a>  |
   |               |        |           |    Receiver Port |           |
   |               |        |           |                  |           |
   | twamp-control | 862    | tcp       | TWAMP-Control    | <a href="./rfc5357">RFC 5357</a>  |
   | twamp-test    | 862    | udp       | TWAMP-Test       | <a href="./rfc8545">RFC 8545</a>  |
   |               |        |           |    Receiver Port |           |
   +---------------+--------+-----------+------------------+-----------+

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  References</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
              DOI 10.17487/RFC2119, March 1997,
              &lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;.

   [<a id="ref-RFC4656">RFC4656</a>]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and
              M. Zekauskas, "A One-way Active Measurement Protocol
              (OWAMP)", <a href="./rfc4656">RFC 4656</a>, DOI 10.17487/RFC4656, September 2006,
              &lt;<a href="https://www.rfc-editor.org/info/rfc4656">https://www.rfc-editor.org/info/rfc4656</a>&gt;.

   [<a id="ref-RFC5357">RFC5357</a>]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and
              J. Babiarz, "A Two-Way Active Measurement Protocol
              (TWAMP)", <a href="./rfc5357">RFC 5357</a>, DOI 10.17487/RFC5357, October 2008,
              &lt;<a href="https://www.rfc-editor.org/info/rfc5357">https://www.rfc-editor.org/info/rfc5357</a>&gt;.

   [<a id="ref-RFC6335">RFC6335</a>]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and
              S. Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", <a href="https://www.rfc-editor.org/bcp/bcp165">BCP 165</a>,
              <a href="./rfc6335">RFC 6335</a>, DOI 10.17487/RFC6335, August 2011,
              &lt;<a href="https://www.rfc-editor.org/info/rfc6335">https://www.rfc-editor.org/info/rfc6335</a>&gt;.




<span class="grey">Morton &amp; Mirsky              Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8545">RFC 8545</a>              OWAMP/TWAMP Well-Known Ports            March 2019</span>


   [<a id="ref-RFC7594">RFC7594</a>]  Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
              Aitken, P., and A. Akhter, "A Framework for Large-Scale
              Measurement of Broadband Performance (LMAP)", <a href="./rfc7594">RFC 7594</a>,
              DOI 10.17487/RFC7594, September 2015,
              &lt;<a href="https://www.rfc-editor.org/info/rfc7594">https://www.rfc-editor.org/info/rfc7594</a>&gt;.

   [<a id="ref-RFC8174">RFC8174</a>]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              <a href="./rfc2119">RFC 2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>,
              DOI 10.17487/RFC8174, May 2017,
              &lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Informative References</span>

   [<a id="ref-IPPM-TWAMP-06">IPPM-TWAMP-06</a>]
              Hedayat, K., Krzanowski, R., Yum, K., Morton, A., and
              J. Babiarz, "A Two-way Active Measurement Protocol
              (TWAMP)", Work in Progress, <a href="./draft-ietf-ippm-twamp-06">draft-ietf-ippm-twamp-06</a>,
              December 2007.

   [<a id="ref-LarsAD">LarsAD</a>]   Eggert, L., "Subject: [ippm] AD review:
              <a href="./draft-ietf-ippm-twamp-06.txt">draft-ietf-ippm-twamp-06.txt</a>", message to the ippm mailing
              list, April 2008, &lt;<a href="https://mailarchive.ietf.org/rch/msg/ippm/LzcTPYhPhWhbb5-ncR046XKpnzo">https://mailarchive.ietf.org/</a>
              <a href="https://mailarchive.ietf.org/rch/msg/ippm/LzcTPYhPhWhbb5-ncR046XKpnzo">rch/msg/ippm/LzcTPYhPhWhbb5-ncR046XKpnzo</a>&gt;.

   [<a id="ref-TimDISCUSS">TimDISCUSS</a>]
              "Tim Polk's Ballot discuss", July 2008,
              &lt;<a href="https://datatracker.ietf.org/doc/rfc5357/history">https://datatracker.ietf.org/doc/rfc5357/history</a>&gt;.

   [<a id="ref-TR-390">TR-390</a>]   Broadband Forum, "TR-390: Performance Measurement from IP
              Edge to Customer Equipment using TWAMP Light", Issue: 1,
              May 2017, &lt;<a href="https://www.broadband-forum.org/technical/download/TR-390.pdf">https://www.broadband-forum.org/technical/</a>
              <a href="https://www.broadband-forum.org/technical/download/TR-390.pdf">download/TR-390.pdf</a>&gt;.



















<span class="grey">Morton &amp; Mirsky              Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8545">RFC 8545</a>              OWAMP/TWAMP Well-Known Ports            March 2019</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Background on TWAMP Light</span>

   This informative appendix provides the background on the decision to
   move the TWAMP Light idea to an informative appendix in [<a href="./rfc5357" title="&quot;A Two-Way Active Measurement Protocol (TWAMP)&quot;">RFC5357</a>].

   As also noted in <a href="#section-4">Section 4</a>, the TWAMP Light idea was relegated to
   <a href="./rfc5357#appendix-I">Appendix&nbsp;I of [RFC5357]</a> 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 [<a href="#ref-LarsAD" title="&quot;Subject: [ippm] AD review: draft-ietf-ippm-twamp-06.txt&quot;">LarsAD</a>], 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 "<a href="#section-5.2">Section 5.2</a>, paragraph 0"
      comment on [<a href="#ref-LarsAD" title="&quot;Subject: [ippm] AD review: draft-ietf-ippm-twamp-06.txt&quot;">LarsAD</a>], which refers to a section in [<a href="#ref-IPPM-TWAMP-06">IPPM-TWAMP-06</a>].
      The working group consensus was to place the TWAMP Light
      description in <a href="#appendix-I">Appendix I</a> 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 [<a href="#ref-TimDISCUSS">TimDISCUSS</a>], 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 <a href="#appendix-I">Appendix I</a> to address Tim's Ballot
      discuss (see the last three paragraphs of <a href="./rfc5357#appendix-I">Appendix&nbsp;I in
      [RFC5357]</a>).

   Since the idea of TWAMP Light clearly includes the TWAMP-Test
   protocol and other undefined facilities, <a href="./rfc5357#appendix-I">Appendix&nbsp;I of [RFC5357]</a>
   simply describes ideas for how TWAMP-Test might be used outside of
   the context of Standards Track TWAMP.

















<span class="grey">Morton &amp; Mirsky              Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8545">RFC 8545</a>              OWAMP/TWAMP Well-Known Ports            March 2019</span>


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

   Al Morton (editor)
   AT&amp;T Labs
   200 Laurel Avenue South
   Middletown, NJ  07748
   United States of America

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192
   Email: acmorton@att.com


   Greg Mirsky (editor)
   ZTE Corp.

   Email: gregimirsky@gmail.com























Morton &amp; Mirsky              Standards Track                   [Page 11]
</pre>