Internet Engineering Task Force (IETF) A. Morton, Ed.
Request for Comments: 8545 AT&T Labs
Updates: 4656, 5357 G. Mirsky, Ed.
Category: Standards Track ZTE Corp.
ISSN: 2070-1721 March 2019
Internet Engineering Task Force (IETF) A. Morton, Ed.
Request for Comments: 8545 AT&T Labs
Updates: 4656, 5357 G. Mirsky, Ed.
Category: Standards Track ZTE Corp.
ISSN: 2070-1721 March 2019
Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)
单向主动测量协议（OWAMP）和双向主动测量协议（TWAMP）的已知端口分配
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.
本备忘录解释了动机，并描述了控制和测量用单向主动测量协议（OWAMP）和双向主动测量协议（TWAMP）的已知端口的重新分配。它还澄清了这些行业标准跟踪协议名称的含义和组成。
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.
本备忘录根据UDP众所周知的端口分配更新了RFCs 4656和5357，并澄清了行业的完整OWAMP和TWAMP协议组成。
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 Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8545.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Scope ...........................................................3
4. Definitions and Background ......................................3
5. New Well-Known Ports ............................................5
5.1. Impact on TWAMP-Control Protocol ...........................5
5.2. Impact on OWAMP-Control Protocol ...........................6
5.3. Impact on OWAMP-Test/TWAMP-Test Protocols ..................6
6. Security Considerations .........................................7
7. IANA Considerations .............................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
Appendix A. Background on TWAMP Light .............................10
Acknowledgements ..................................................11
Contributors ......................................................11
Authors' Addresses ................................................11
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Scope ...........................................................3
4. Definitions and Background ......................................3
5. New Well-Known Ports ............................................5
5.1. Impact on TWAMP-Control Protocol ...........................5
5.2. Impact on OWAMP-Control Protocol ...........................6
5.3. Impact on OWAMP-Test/TWAMP-Test Protocols ..................6
6. Security Considerations .........................................7
7. IANA Considerations .............................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
Appendix A. Background on TWAMP Light .............................10
Acknowledgements ..................................................11
Contributors ......................................................11
Authors' Addresses ................................................11
The IETF IP Performance Metrics (IPPM) Working Group first developed the One-Way Active Measurement Protocol (OWAMP), as specified in [RFC4656]. Further protocol development to support testing resulted in the Two-Way Active Measurement Protocol (TWAMP), as specified in [RFC5357].
IETF IP性能度量（IPPM）工作组首先开发了单向主动测量协议（OWAMP），如[RFC4656]所述。支持测试的进一步协议开发产生了双向主动测量协议（TWAMP），如[RFC5357]所述。
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.
OWAMP和TWAMP都需要实现控制和模式协商协议（OWAMP控制和TWAMP控制），该协议采用TCP的可靠传输服务（包括安全配置和密钥派生）。控制协议使用UDP传输上的相关测试协议（OWAMP测试或TWAMP测试）安排测试会话的配置和管理。
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.
IETF认识到将一个众所周知的UDP端口分配给OWAMP测试和TWAMP测试协议的价值，还认识到可以通过端口重新分配轻松实现这一目标。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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.
本备忘录的范围有两个：（1）重新分配UDP测试协议的知名端口，这些端口构成各自标准跟踪协议（OWAMP和TWAMP）的必要部分；（2）澄清行业标准跟踪协议名称的含义和组成。
This memo updates [RFC4656] and [RFC5357], in terms of the UDP well-known port assignments.
此备忘录根据UDP已知端口分配更新[RFC4656]和[RFC5357]。
This section defines key terms and clarifies the required composition of the OWAMP and TWAMP Standards Track protocols.
本节定义了关键术语，并澄清了OWAMP和TWAMP标准轨道协议所需的组成。
"OWAMP-Control" is the protocol defined in Section 3 of [RFC4656].
“OWAMP控制”是[RFC4656]第3节中定义的协议。
"OWAMP-Test" is the protocol defined in Section 4 of [RFC4656].
“OWAMP测试”是[RFC4656]第4节中定义的协议。
OWAMP is described in this direct quote from Section 1.1 of [RFC4656]: "OWAMP actually consists of two inter-related protocols: OWAMP-Control and OWAMP-Test." A similar sentence appears in Section 2 of [RFC4656]. For avoidance of doubt, the implementation of both OWAMP-Control and OWAMP-Test is REQUIRED for Standards Track OWAMP as specified in [RFC4656] (applying the consensus of many dictionary definitions of "consist").
[RFC4656]第1.1节直接引用了OWAMP的描述：“OWAMP实际上由两个相互关联的协议组成：OWAMP控制和OWAMP测试。”类似的句子出现在[RFC4656]第2节中。为免生疑问，对于[RFC4656]中规定的标准轨道OWAMP，需要执行OWAMP控制和OWAMP测试（应用“组”的许多词典定义的共识）。
"TWAMP-Control" is the protocol defined in Section 3 of [RFC5357].
“TWAMP控制”是[RFC5357]第3节中定义的协议。
"TWAMP-Test" is the protocol defined in Section 4 of [RFC5357].
“TWAMP测试”是[RFC5357]第4节中定义的协议。
TWAMP is described in this direct quote from Section 1.1 of [RFC5357]: "Similar to OWAMP [RFC4656], 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 [RFC5357] (applying the consensus of many dictionary definitions of "consist").
TWAMP在[RFC5357]第1.1节的直接引用中进行了描述：“与OWAMP[RFC4656]类似，TWAMP由两个相互关联的协议组成：TWAMP控制和TWAMP测试。”为避免疑问，对于[RFC5357]中规定的标准轨道TWAMP，需要实施TWAMP控制和TWAMP测试（应用许多词典对“组成”的定义的共识）。
"TWAMP Light" is an idea described in Appendix I ("TWAMP Light (Informative)") of [RFC5357]; TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], the TWAMP Light idea was relegated to Appendix I 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 Appendix A of this memo. See also [LarsAD] and [TimDISCUSS].
“TWAMP灯”是[RFC5357]的附录I（“TWAMP灯（信息）”）中描述的一个概念；TWAMP灯包括与TWAMP测试协议相结合的未指定控制协议。在[RFC5357]中，由于TWAMP Light未能满足IETF协议的要求，TWAMP Light的想法被归入附录I（没有关于协商这种操作形式的规范，也没有关于强制实施安全功能的规范），如本备忘录附录A所述。另见[LarsAD]和[Timmable]。
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, Appendix I of [RFC5357] would be one sentence long (equating TWAMP Light with TWAMP-Test only).
由于TWAMP Light的理念明确包括TWAMP的TWAMP测试组件，因此认为未来系统使用TWAMP测试众所周知的UDP端口（其重新分配的分配在本文档中有详细说明）是合理的。很明显，TWAMP Light设想了许多组件和通信能力，而不仅仅是TWAMP测试（例如，实现安全需求）；否则，[RFC5357]的附录I将是一句话长（仅将TWAMP灯等同于TWAMP测试）。
Originally, both TCP and UDP well-known ports were assigned to the control protocols that are essential components of Standards Track OWAMP and TWAMP.
最初，TCP和UDP两个众所周知的端口都分配给控制协议，控制协议是标准跟踪OWAMP和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.
因为OWAMP控制和TWAMP控制需要TCP传输，所以它们不能使用最初分配的UDP端口。但是，使用OWAMP测试或TWAMP测试的测试会话在UDP传输上运行。
Per this memo, IANA has reassigned the UDP well-known port from the control protocol to the test protocol (see Section 7 ("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, [TR-390] 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.
根据本备忘录，IANA已将UDP知名端口从控制协议重新分配给测试协议（见第7节（“IANA注意事项”）。在标准跟踪OWAMP和TWAMP中，此UDP端口的使用是可选的。它可以简化一些操作，为测试协议或涉及TWAMP测试的未来规范提供一个众所周知的端口，将此端口用作默认端口。例如，[TR-390]是在IP网络的客户边缘进行测试的规范，而一致性实现将受益于将众所周知的UDP端口重新分配到测试协议。
Section 3.5 of [RFC5357] 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 [RFC6335]:
[RFC5357]的第3.5节描述了协商接收器端口号的详细过程，TWAMP会话反射器将在该端口号上发送和接收TWAMP测试数据包；请参阅下面引用的文本。代表会话发送方的控制客户端从动态端口范围[RFC6335]中建议接收方端口号：
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).
接收方端口是会话发送方将TWAMP测试数据包发送到的所需UDP端口（请求会话反射器接收测试数据包的端口）。接收方端口也是UDP端口，会话反射器将从中发送TWAMP测试数据包（会话反射器将使用相同的UDP端口发送和接收数据包）。
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 Section 3.5 of [RFC5357] per Erratum ID 1587 (see <https://www.rfc-editor.org/errata/eid1587>) as follows:
可能提议的接收器端口不可用，例如，该端口正被另一测试会话或另一应用程序使用。在这种情况下，我们根据勘误表ID1587更新了[RFC5357]第3.5节的最后一段（参见<https://www.rfc-editor.org/errata/eid1587>)详情如下:
... 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
... 会话反射器处的服务器可能会在端口字段中建议此会话的备用可用端口。控制客户端要么接受备用端口，要么用合适的参数组成新的会话请求消息。否则
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.
服务器使用Accept字段向控制客户端传递其他形式的会话拒绝或失败，并且不得建议备用端口；在这种情况下，端口字段必须设置为零。
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 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 [RFC5357]. Of course, using a UDP port number chosen from the Dynamic Ports range [RFC6335] will help avoid the situation where the Control-Client or Server finds that the proposed port is already in use.
支持使用分配的TWAMP测试接收器端口（第7节）的控制客户端可在请求TW会话命令中请求使用该端口号。如果服务器不支持分配的TWAMP测试接收器端口，则它会在Accept会话消息中发送一个备用端口号，Accept字段=0。因此，分配的TWAMP接收器端口号的部署与基于[RFC5357]的现有TWAMP控制解决方案向后兼容。当然，使用从动态端口范围[RFC6335]中选择的UDP端口号将有助于避免控制客户端或服务器发现建议的端口已在使用的情况。
As described above, an OWAMP-Control client that supports the use of the allocated OWAMP-Test Receiver Port (Section 7) 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.
如上所述，支持使用分配的OWAMP测试接收器端口（第7节）的OWAMP控制客户端可以在请求会话命令中请求使用该端口号。如果服务器不支持分配的OWAMP测试接收器端口（或该端口不可用），则会在Accept会话消息中发送另一个端口号，且Accept字段=0。进一步的交换按照已经指定的方式进行。
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.
OWAMP测试/TWAMP测试可用于测量等成本多路径（ECMP）环境中的IP性能指标。虽然在可用路径之间平衡IP流的算法尚未标准化，但最常见的是使用目标IP地址、源IP地址、协议类型、目标端口号和源端口号的五元组。当试图监控ECMP网络中的不同路径时，仅改变五个参数中的一个即可，例如源端口号。因此，当使用重新分配的UDP端口号作为接收器端口时，将不会对在相同测试点之间安排并发OWAMP/TWAMP测试会话以监视ECMP网络中的不同路径的能力产生负面影响，因为使用端口是可选的。
The security considerations that apply to any active measurement of live paths are relevant here as well (see [RFC4656] and [RFC5357]).
适用于活动路径的任何主动测量的安全注意事项也与此相关（请参见[RFC4656]和[RFC5357]）。
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 [RFC7594], which covers both active and passive techniques.
当考虑到参与测量的人或其流量被测量的人的隐私时，当使用此工作范围内的主动技术时，潜在观察者可用的敏感信息会大大减少。出于测量目的对用户流量进行被动观测会引起许多隐私问题。我们建议读者参考大规模宽带性能测量（LMAP）框架[RFC7594]中描述的安全和隐私注意事项，该框架涵盖主动和被动技术。
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:
作为OWAMP测试/TWAMP测试接收器端口的已注册UDP端口可能成为拒绝服务（DoS）的目标，或可用于帮助中间人（MITM）攻击。为提高对DoS的保护，建议采用以下方法：
o filtering access to the OWAMP/TWAMP Receiver Port via an access list.
o 通过访问列表筛选对OWAMP/TWAMP接收器端口的访问。
o using a non-globally routable IP address for the OWAMP/TWAMP Session-Reflector address.
o 为OWAMP/TWAMP会话地址使用非全局可路由IP地址。
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.
MITM攻击者可能试图修改OWAMP测试/TWAMP测试数据包的内容，以改变测量结果。然而，实现可以使用认证模式来检测数据的修改。此外，实现可以使用加密模式来防止对OWAMP测试/TWAMP测试数据包的窃听和未被检测到的修改。
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.
还存在被测网络对涉及众所周知的UDP端口的流进行特殊处理的风险，无论是否知道测量系统的源地址和目标地址，从而通过优先或有害处理使结果产生偏差。
IANA has reallocated two UDP port numbers from the System Ports range of the "Service Name and Transport Protocol Port Number Registry" [RFC6335]. 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.
IANA已从“服务名称和传输协议端口号注册表”[RFC6335]的系统端口范围重新分配了两个UDP端口号。具体而言，IANA已重新分配UDP端口861和862，如下所示，保留TCP端口分配不变。IANA还将这些端口（UDP和TCP）的受让人和联系人分别更新为IESG和IETF主席。
+---------------+--------+-----------+------------------+-----------+
| Service | Port | Transport | Description | Reference |
| 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 | |
+---------------+--------+-----------+------------------+-----------+
+---------------+--------+-----------+------------------+-----------+
| Service | Port | Transport | Description | Reference |
| 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 | |
+---------------+--------+-----------+------------------+-----------+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC4656]Shalunov，S.，Teitelbaum，B.，Karp，A.，Boote，J.，和M.Zekauskas，“单向主动测量协议（OWAMP）”，RFC 4656，DOI 10.17487/RFC4656，2006年9月<https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5357]Hedayat，K.，Krzanowski，R.，Morton，A.，Yum，K.，和J.Babiarz，“双向主动测量协议（TWAMP）”，RFC 5357，DOI 10.17487/RFC5357，2008年10月<https://www.rfc-editor.org/info/rfc5357>.
[RFC6335] 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", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<https://www.rfc-editor.org/info/rfc6335>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.
[RFC7594]Eardley，P.，Morton，A.，Bagnulo，M.，Burbridge，T.，Aitken，P.，和A.Akhter，“宽带性能的大规模测量框架（LMAP）”，RFC 7594，DOI 10.17487/RFC7594，2015年9月<https://www.rfc-editor.org/info/rfc7594>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[IPPM-TWAMP-06] 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.
[IPPM-TWAMP-06]Hedayat，K.，Krzanowski，R.，Yum，K.，Morton，A.，和J.Babiarz，“双向主动测量协议（TWAMP）”，正在进行的工作，草案-ietf-IPPM-TWAMP-06，2007年12月。
[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>.
[LarsAD]Eggert，L.，“主题：[ippm]广告评论：草稿-ietf-ippm-twamp-06.txt”，致ippm邮件列表的信息，2008年4月<https://mailarchive.ietf.org/ rch/msg/ippm/LZCTPYHPWHBB5-ncR046XKpnzo>。
[TimDISCUSS] "Tim Polk's Ballot discuss", July 2008, <https://datatracker.ietf.org/doc/rfc5357/history>.
[蒂姆讨论]“蒂姆·波尔克的选票讨论”，2008年7月<https://datatracker.ietf.org/doc/rfc5357/history>.
[TR-390] Broadband Forum, "TR-390: Performance Measurement from IP Edge to Customer Equipment using TWAMP Light", Issue: 1, May 2017, <https://www.broadband-forum.org/technical/ download/TR-390.pdf>.
[TR-390]宽带论坛，“TR-390：使用TWAMP光从IP边缘到客户设备的性能测量”，发行日期：2017年5月1日<https://www.broadband-forum.org/technical/ 下载/TR-390.pdf>。
This informative appendix provides the background on the decision to move the TWAMP Light idea to an informative appendix in [RFC5357].
本资料性附录提供了将TWAMP Light理念转变为[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:
如第4节所述，TWAMP Light idea被归为[RFC5357]的附录I，因为它不符合IETF协议的要求（没有关于协商这种形式的操作的规范，也没有关于强制实施安全功能的规范），如以下引用的参考文献所述：
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 Lars Eggert的区域主管审查[LarsAD]，其中他指出，拥有两种TWAMP变体（TWAMP Light和Complete TWAMP）需要协议机制来协商将使用哪种变体。请注意，“完整TWAMP”在本文档中称为“标准跟踪TWAMP”。参见Lars对[LarsAD]的“第5.2节第0段”评论，该评论引用了[IPPM-TWAMP-06]中的一节。工作组的共识是将TWAMP灯说明放在附录I中，并仅将该附录称为“通过首先实施TWAMP测试协议，采用TWAMP的增量路径”
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]).
o Tim Polk在2008年7月16日的“投票讨论”[TimCongress]中指出，TWAMP Light是一个不完整的规范，因为认证和加密模式所需的密钥取决于TWAMP控制会话密钥。附录I中增加了额外的要求声明，以解决Tim的投票讨论（见[RFC5357]中附录I的最后三段）。
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.
由于TWAMP Light的理念明确包括TWAMP测试协议和其他未定义的设施，[RFC5357]的附录I简单描述了如何在标准轨道TWAMP之外使用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.
作者感谢IPPM工作组的快速审查；还感谢Muthu Arul Mozhi Perumal和Luay Jalil的参与和建议。
Contributors
贡献者
Richard Foote and Luis M. Contreras made notable contributions on this topic.
Richard Foote和Luis M.Contreras在这方面做出了显著贡献。
Authors' Addresses
作者地址
Al Morton (editor) AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America
美国新泽西州劳雷尔大道南米德尔顿200号AT&T实验室Al Morton（编辑）07748
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acmorton@att.com
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acmorton@att.com
Greg Mirsky (editor) ZTE Corp.
格雷格·米尔斯基（编辑）中兴通讯公司。
Email: gregimirsky@gmail.com
Email: gregimirsky@gmail.com