Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 8186 ZTE Corp.
Category: Standards Track I. Meilik
ISSN: 2070-1721 Broadcom
June 2017
Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 8186 ZTE Corp.
Category: Standards Track I. Meilik
ISSN: 2070-1721 Broadcom
June 2017
Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)
在双向主动测量协议（TWAMP）中支持IEEE 1588时间戳格式
Abstract
摘要
This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to the Network Time Protocol that is currently used.
本文档描述了主动性能测量协议的可选功能，该功能允许使用IEEE 1588v2中定义的精确时间协议时间戳格式，作为当前使用的网络时间协议的替代方案。
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 http://www.rfc-editor.org/info/rfc8186.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8186.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. OWAMP and TWAMP Extensions . . . . . . . . . . . . . . . . . 3
2.1. Timestamp Format Negotiation in OWAMP Connection Setup . 4
2.2. Timestamp Format Negotiation in TWAMP Connection Setup . 5
2.3. OWAMP-Test and TWAMP-Test Updates . . . . . . . . . . . . 5
2.3.1. Consideration for TWAMP Light Mode . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. OWAMP and TWAMP Extensions . . . . . . . . . . . . . . . . . 3
2.1. Timestamp Format Negotiation in OWAMP Connection Setup . 4
2.2. Timestamp Format Negotiation in TWAMP Connection Setup . 5
2.3. OWAMP-Test and TWAMP-Test Updates . . . . . . . . . . . . 5
2.3.1. Consideration for TWAMP Light Mode . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
The One-Way Active Measurement Protocol (OWAMP) [RFC4656] defines that only the NTP format [RFC5905] of a timestamp can be used in the OWAMP-Test protocol. The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] adopted the OWAMP-Test packet format and extended it by adding a format for a reflected test packet. Both the sender's and reflector's packets timestamps are expected to follow the 64-bit-long NTP format [RFC5905]. NTP, when used over the Internet, typically achieves clock accuracy within 5 ms to 100 ms. Surveys conducted recently suggest that 90% of devices achieve accuracy better than 100 ms and 99% of devices achieve accuracy better than 1 sec. It should be noted that NTP synchronizes clocks on the control plane, not on data plane. Distribution of clock within a node may be supported by an independent NTP domain or via interprocess communication in a multiprocessor distributed system. Any of the mentioned solutions will be subject to additional queuing delays that negatively affect data-plane clock accuracy.
单向主动测量协议（OWAMP）[RFC4656]定义在OWAMP测试协议中只能使用时间戳的NTP格式[RFC5905]。双向主动测量协议（TWAMP）[RFC5357]采用了OWAMP测试数据包格式，并通过添加反射测试数据包的格式对其进行了扩展。发送方和反射器的数据包时间戳都应遵循64位长的NTP格式[RFC5905]。通过互联网使用NTP时，时钟精度通常在5 ms到100 ms之间。最近进行的调查表明，90%的设备的精度优于100 ms，99%的设备的精度优于1秒。应该注意的是，NTP在控制平面上同步时钟，而不是在数据平面上同步时钟。节点内的时钟分布可由独立的NTP域或通过多处理器分布式系统中的进程间通信来支持。上述任何解决方案都会受到额外排队延迟的影响，从而对数据平面时钟精度产生负面影响。
The Precision Time Protocol (PTP) [IEEE.1588] has gained wide support since the development of OWAMP and TWAMP. PTP, using on-path support and other mechanisms, allows sub-microsecond clock accuracy. PTP is now supported in multiple implementations of fast-forwarding engines; thus, accuracy achieved by PTP is the accuracy of the clock in the data plane. Having an option to use a more accurate clock as a source of timestamps for IP performance measurements is one of the advantages of this specification. Another advantage is realized by simplification of hardware in the data plane. To support OWAMP or TWAMP, test protocol timestamps must be converted from PTP to NTP. That requires resources, use of microcode or additional processing elements, that are always limited. To address this, this document
自从OWAMP和TWAMP的发展以来，精确时间协议（PTP）[IEEE.1588]得到了广泛的支持。PTP使用路径支持和其他机制，允许亚微秒时钟精度。PTP现在在多个快进引擎实现中得到支持；因此，PTP实现的精度是数据平面中时钟的精度。可以选择使用更精确的时钟作为IP性能测量的时间戳源，这是本规范的优点之一。另一个优点是通过简化数据平面中的硬件来实现。为了支持OWAMP或TWAMP，必须将测试协议时间戳从PTP转换为NTP。这需要资源、微码的使用或额外的处理元素，而这些资源总是有限的。为了解决这个问题，本文件
proposes optional extensions to Control and Test protocols to support use of the IEEE 1588v2 timestamp format as an optional alternative to the NTP timestamp format.
提出控制和测试协议的可选扩展，以支持使用IEEE 1588v2时间戳格式作为NTP时间戳格式的可选替代。
One of the goals of this specification is not only to allow endpoints of a test session to use a timestamp format other than NTP, but to support backwards compatibility with nodes that do not yet support this extension.
本规范的目标之一不仅是允许测试会话的端点使用NTP以外的时间戳格式，而且还支持与不支持此扩展的节点的向后兼容性。
NTP: Network Time Protocol
网络时间协议
PTP: Precision Time Protocol
精确时间协议
TWAMP: Two-Way Active Measurement Protocol
双向主动测量协议
OWAMP: One-Way Active Measurement Protocol
OWAMP：单向主动测量协议
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]所述进行解释。
OWAMP connection establishment follows the procedure defined in Section 3.1 of [RFC4656] and additional steps in TWAMP described in Section 3.1 of [RFC5357]. In these procedures, the Modes field has been used to identify and select specific communication capabilities. At the same time, the Modes field has been recognized and used as an extension mechanism [RFC6038]. The new feature requires one bit position for the Server and Control-Client to negotiate which timestamp format can be used in some or all test sessions invoked with this control connection. The endpoint of the test session, Session-Sender and Session-Receiver (for OWAMP) or Session-Reflector (for TWAMP), that supports this extension MUST be capable of interpreting the NTP and PTPv2 timestamp formats. If the endpoint does not support this extension, then the value of the PTPv2 Timestamp flag MUST be 0 because it is in Must Be Zero field. If the value of the PTPv2 Timestamp flag is 0, then the advertising node can use and interpret only the NTP timestamp format. Implementations of OWAMP and/or TWAMP MAY provide a configuration knob to bypass the
OWAMP连接建立遵循[RFC4656]第3.1节中定义的程序和[RFC5357]第3.1节中描述的TWAMP附加步骤。在这些程序中，模式字段用于识别和选择特定的通信能力。同时，模式字段已被识别并用作扩展机制[RFC6038]。新特性要求服务器和控制客户端在一个位的位置上协商在使用此控制连接调用的某些或所有测试会话中可以使用哪种时间戳格式。支持此扩展的测试会话、会话发送方和会话接收方（对于OWAMP）或会话反射器（对于TWAMP）的端点必须能够解释NTP和PTPv2时间戳格式。如果端点不支持此扩展，则PTPv2时间戳标志的值必须为0，因为它位于“必须为零”字段中。如果PTPv2时间戳标志的值为0，则广告节点只能使用和解释NTP时间戳格式。OWAMP和/或TWAMP的实现可提供一个配置旋钮，以绕过
timestamp format negotiation process and use the locally configured values instead.
时间戳格式协商过程，并改用本地配置的值。
Use of PTPv2 Timestamp flags is discussed in the following subsections. For details on the assigned values and bit positions, see the Section 3.
PTPv2时间戳标志的使用将在以下小节中讨论。有关指定值和位位置的详细信息，请参阅第3节。
In OWAMP-Test [RFC4656], the Session-Receiver and/or Fetch-Client interpret collected timestamps. Thus, the Server uses the Modes field timestamp format to indicate which formats the Session-Receiver is capable of interpreting. The Control-Client inspects values set by the Server for timestamp formats and sets values in the Modes field of the Set-Up-Response message according to the timestamp formats the Session-Sender can use. The rules for setting timestamp flags in the Modes field in Server Greeting and Set-Up-Response messages and interpreting them are as follows:
在OWAMP测试[RFC4656]中，会话接收器和/或获取客户端解释收集的时间戳。因此，服务器使用模式字段时间戳格式来指示会话接收器能够解释的格式。控制客户端检查服务器设置的时间戳格式值，并根据会话发送方可以使用的时间戳格式在设置响应消息的模式字段中设置值。在服务器问候语和设置响应消息的模式字段中设置时间戳标志并对其进行解释的规则如下：
o If the Session-Receiver supports this extension, then the Server that establishes test sessions on its behalf MUST set the PTPv2 Timestamp flag to 1 in the Server Greeting message per the requirement listed in Section 2. Otherwise, the PTPv2 Timestamp flag will be set to 0 to indicate that the Session-Receiver interprets only the NTP format.
o 如果会话接收方支持此扩展，则代表其建立测试会话的服务器必须根据第2节中列出的要求，在服务器问候消息中将PTPv2时间戳标志设置为1。否则，PTPv2时间戳标志将设置为0，以指示会话接收器仅解释NTP格式。
o If the Control-Client receives a greeting message with the PTPv2 Timestamp flag set to 0, then the Session-Sender MUST use the NTP format for the timestamp in the test session, and the Control-Client SHOULD set the PTPv2 Timestamp flag to 0 in accordance with [RFC4656]. If the Session-Sender cannot use NTP timestamps, then the Control-Client SHOULD close the TCP connection associated with the OWAMP-Control session.
o 如果控制客户端接收到PTPv2时间戳标志设置为0的问候消息，则会话发送方必须在测试会话中使用NTP格式的时间戳，并且控制客户端应根据[RFC4656]将PTPv2时间戳标志设置为0。如果会话发送方无法使用NTP时间戳，则控制客户端应关闭与OWAMP控制会话关联的TCP连接。
o If the Control-Client receives a greeting message with the PTPv2 Timestamp flag set to 1 and the Session-Sender can set the timestamp in PTPv2 format, then the Control-Client MUST set the PTPv2 Timestamp flag to 1 in the Modes field in the Set-Up-Response message and the Session-Sender MUST use PTPv2 timestamp format.
o 如果控制客户端接收到PTPv2时间戳标志设置为1的问候消息，并且会话发送方可以将时间戳设置为PTPv2格式，则控制客户端必须在设置响应消息的模式字段中将PTPv2时间戳标志设置为1，并且会话发送方必须使用PTPv2时间戳格式。
o If the Session-Sender doesn't support this extension and can set the timestamp in NTP format only, then the PTPv2 Timestamp flag in the Modes field in the Set-Up-Response message will be set to 0 as part of the Must Be Zero field and the Session-Sender will use the NTP format.
o 如果会话发送方不支持此扩展，并且只能以NTP格式设置时间戳，则设置响应消息中模式字段中的PTPv2时间戳标志将作为必须为零字段的一部分设置为0，并且会话发送方将使用NTP格式。
If OWAMP-Control uses Fetch-Session commands, then selection and use of one timestamp format or another is a local decision for both Session-Sender and Session-Receiver.
如果OWAMP控件使用Fetch会话命令，则选择和使用一种或另一种时间戳格式是会话发送方和会话接收方的本地决定。
In TWAMP-Test [RFC5357], the Session-Sender interprets collected timestamps. Hence, in the Modes field, a Server advertises timestamp formats that the Session-Reflector can use in the TWAMP-Test message. The choice of the timestamp format to be used by the Session-Sender is a local decision. The Control-Client inspects the Modes field and sets timestamp flag values to indicate the format that will be used by the Session-Reflector. The rules of setting and interpreting flag values are as follows:
在TWAMP测试[RFC5357]中，会话发送方解释收集的时间戳。因此，在Modes字段中，服务器播发会话反射器可以在TWAMP测试消息中使用的时间戳格式。会话发送方使用的时间戳格式的选择是本地决定。控制客户端检查模式字段并设置时间戳标志值，以指示会话反射器将使用的格式。设置和解释标志值的规则如下：
o The Server MUST set the PTPv2 Timestamp flag value to 1 in its greeting message if the Session-Reflector can set the timestamp in the PTPv2 format. Otherwise, the PTPv2 Timestamp flag MUST be set to 0.
o 如果会话反射器可以设置PTPv2格式的时间戳，则服务器必须在其问候语中将PTPv2时间戳标志值设置为1。否则，PTPv2时间戳标志必须设置为0。
o If the value of the PTPv2 Timestamp flag in the received Server Greeting message is 0, then the Session-Reflector does not support this extension and will use the NTP timestamp format. The Control-Client SHOULD set the PTPv2 Timestamp flag to 0 in the Set-Up-Response message in accordance with [RFC4656].
o 如果接收到的服务器问候消息中PTPv2时间戳标志的值为0，则会话反射器不支持此扩展，将使用NTP时间戳格式。控制客户端应根据[RFC4656]在设置响应消息中将PTPv2时间戳标志设置为0。
o The Control-Client MUST set the PTPv2 Timestamp flag value to 1 in the Modes field in the Set-Up-Response message if the Server advertised that the Session-Reflector has the ability to use the PTPv2 format for timestamps. Otherwise, the flag MUST be set to 0.
o 如果服务器通告会话反射器能够使用PTPv2格式作为时间戳，则控制客户端必须在设置响应消息的模式字段中将PTPv2时间戳标志值设置为1。否则，该标志必须设置为0。
o If the value of the PTPv2 Timestamp flag in the Set-Up-Response message is 0, then that means that the Session-Sender can only interpret the NTP timestamp format. Therefore, the Session-Reflector MUST use the NTP timestamp format. If the Session-Reflector does not support the NTP format, then the Server MUST close the TCP connection associated with the TWAMP-Control session.
o 如果设置响应消息中PTPv2时间戳标志的值为0，则表示会话发送方只能解释NTP时间戳格式。因此，会话反射器必须使用NTP时间戳格式。如果会话反射器不支持NTP格式，则服务器必须关闭与TWAMP控制会话关联的TCP连接。
Participants of a test session need to indicate which timestamp format is being used. Currently, the Z field in the Error Estimate defined in Section 4.1.2 of [RFC4656] is used for this purpose. However, this document extends the Error Estimate to indicate the format of a collected timestamp, in addition to the estimate of error and synchronization. This specification also changes the semantics
测试会话的参与者需要指出正在使用哪种时间戳格式。目前，[RFC4656]第4.1.2节中定义的误差估计中的Z字段用于此目的。但是，除了错误和同步的估计之外，本文还扩展了错误估计，以指示收集的时间戳的格式。此规范还更改了语义
of the Z bit field (the field between S and Scale fields) to be referred to as the Timestamp format; the value MUST be set as follows:
将被称为时间戳格式的Z位字段（S和缩放字段之间的字段）的长度；必须按如下方式设置该值：
o 0 - NTP 64-bit format of a timestamp.
o 0-时间戳的NTP 64位格式。
o 1 - PTPv2-truncated format of a timestamp.
o 1-PTPv2时间戳的截断格式。
As a result of this value of the Z field from the Error Estimate, the Sender Error Estimate (in TWAMP) or Send Error Estimate (in OWAMP) and Receive Error Estimate SHOULD NOT be ignored and MUST be used when calculating delay and delay-variation metrics based on collected timestamps.
由于错误估计的Z字段值，发送方错误估计（TWAMP）或发送错误估计（OWAMP）和接收错误估计不应被忽略，并且在基于收集的时间戳计算延迟和延迟变化度量时必须使用。
This document does not specify how the Session-Sender and Session-Reflector in TWAMP Light mode are informed of the timestamp format to be used. It is assumed that, for example, configuration could be used to direct the Session-Sender and Session-Reflector to use the timestamp format per their capabilities and rules listed in Section 2.2.
本文档未指定如何将要使用的时间戳格式通知TWAMP灯光模式下的会话发送器和会话反射器。例如，假设可以使用配置来指导会话发送方和会话反射器根据第2.2节中列出的功能和规则使用时间戳格式。
IANA has registered a new PTPv2 Timestamp in the "TWAMP-Modes" registry [RFC5618] as follows:
IANA已在“TWAMP模式”注册表[RFC5618]中注册了一个新的PTPv2时间戳，如下所示：
+------+-----------------------------+-----------+------------------+
| Bit | Description | Semantics | Reference |
| Pos | | | |
+------+-----------------------------+-----------+------------------+
| 9 | PTPv2 Timestamp Capability | Section 2 | RFC 8186 (this |
| | | | document) |
+------+-----------------------------+-----------+------------------+
+------+-----------------------------+-----------+------------------+
| Bit | Description | Semantics | Reference |
| Pos | | | |
+------+-----------------------------+-----------+------------------+
| 9 | PTPv2 Timestamp Capability | Section 2 | RFC 8186 (this |
| | | | document) |
+------+-----------------------------+-----------+------------------+
Table 1: New Timestamp Capability
表1：新的时间戳功能
Use of a particular timestamp format in a test session does not appear to introduce any additional security threat to hosts that communicate with OWAMP and/or TWAMP as defined in [RFC4656] and [RFC5357], respectively. The security considerations that apply to any active measurement of live networks are relevant here as well. See the Security Considerations sections in [RFC4656] and [RFC5357].
在测试会话中使用特定时间戳格式似乎不会对分别与[RFC4656]和[RFC5357]中定义的OWAMP和/或TWAMP通信的主机带来任何额外的安全威胁。适用于实时网络的任何主动测量的安全注意事项也与此相关。请参阅[RFC4656]和[RFC5357]中的安全注意事项部分。
[IEEE.1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760.
[IEEE.1588]IEEE，“网络测量和控制系统精密时钟同步协议的IEEE标准”，IEEE标准1588-2008，DOI 10.1109/IEEESTD.2008.4579760。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://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, <http://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月<http://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, <http://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月<http://www.rfc-editor.org/info/rfc5357>.
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, DOI 10.17487/RFC5618, August 2009, <http://www.rfc-editor.org/info/rfc5618>.
[RFC5618]Morton，A.和K.Hedayat，“双向主动测量协议（TWAMP）的混合安全模式”，RFC 5618，DOI 10.17487/RFC5618，2009年8月<http://www.rfc-editor.org/info/rfc5618>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<http://www.rfc-editor.org/info/rfc5905>.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, <http://www.rfc-editor.org/info/rfc6038>.
[RFC6038]Morton，A.和L.Ciavattone，“双向主动测量协议（TWAMP）反映八位组和对称尺寸特征”，RFC 6038，DOI 10.17487/RFC6038，2010年10月<http://www.rfc-editor.org/info/rfc6038>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
Acknowledgements
致谢
The authors would like to thank Ramanathan Lakshmikanthan and Suchit Bansal for their insightful suggestions. The authors would also like to thank David Allan for his thorough review and thoughtful comments.
作者要感谢Ramanathan Lakshmikanthan和Suchit Bansal提出的富有洞察力的建议。作者还要感谢David Allan的透彻评论和深思熟虑的评论。
Authors' Addresses
作者地址
Greg Mirsky ZTE Corp.
格雷格·米尔斯基中兴通讯公司。
Email: gregimirsky@gmail.com
Email: gregimirsky@gmail.com
Israel Meilik Broadcom
以色列梅利克博通
Email: israel@broadcom.com
Email: israel@broadcom.com