Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 8169 ZTE Corp.
Category: Standards Track S. Ruffini
ISSN: 2070-1721 E. Gray
Ericsson
J. Drake
Juniper Networks
S. Bryant
Huawei
A. Vainshtein
ECI Telecom
May 2017
Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 8169 ZTE Corp.
Category: Standards Track S. Ruffini
ISSN: 2070-1721 E. Gray
Ericsson
J. Drake
Juniper Networks
S. Bryant
Huawei
A. Vainshtein
ECI Telecom
May 2017
Residence Time Measurement in MPLS Networks
MPLS网络中的驻留时间测量
Abstract
摘要
This document specifies a new Generic Associated Channel (G-ACh) for Residence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain.
本文档指定了用于停留时间测量（RTM）的新通用关联信道（G-ACh），并描述了MPLS域内的时间同步协议如何使用它。
Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a Precision Time Protocol event message.
停留时间是定时和同步消息传播延迟的可变部分；了解每条消息的延迟允许在应用精确时间协议事件消息中包含的值时更准确地确定要考虑的延迟。
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/rfc8169.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8169.
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 5
2. Residence Time Measurement . . . . . . . . . . . . . . . . . 5
2.1. One-Step Clock and Two-Step Clock Modes . . . . . . . . . 6
2.1.1. RTM with Two-Step Upstream PTP Clock . . . . . . . . 7
2.1.2. Two-Step RTM with One-Step Upstream PTP Clock . . . . 8
3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 8
3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 10
3.2. PTP Associated Value Field . . . . . . . . . . . . . . . 11
4. Control-Plane Theory of Operation . . . . . . . . . . . . . . 11
4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 11
4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 12
4.3. RTM Capability Advertisement in Routing Protocols . . . . 13
4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . 13
4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . 14
4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . 14
4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . 14
4.4. RSVP-TE Control-Plane Operation to Support RTM . . . . . 15
4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . 16
5. Data-Plane Theory of Operation . . . . . . . . . . . . . . . 20
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 22
7.2. New MPLS RTM TLV Registry . . . . . . . . . . . . . . . . 22
7.3. New MPLS RTM Sub-TLV Registry . . . . . . . . . . . . . . 23
7.4. RTM Capability Sub-TLV in OSPFv2 . . . . . . . . . . . . 23
7.5. RTM Capability Sub-TLV in IS-IS . . . . . . . . . . . . . 24
7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . . . . 24
7.7. RTM_SET Sub-object RSVP Type and Sub-TLVs . . . . . . . . 25
7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 26
7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 5
2. Residence Time Measurement . . . . . . . . . . . . . . . . . 5
2.1. One-Step Clock and Two-Step Clock Modes . . . . . . . . . 6
2.1.1. RTM with Two-Step Upstream PTP Clock . . . . . . . . 7
2.1.2. Two-Step RTM with One-Step Upstream PTP Clock . . . . 8
3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 8
3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 10
3.2. PTP Associated Value Field . . . . . . . . . . . . . . . 11
4. Control-Plane Theory of Operation . . . . . . . . . . . . . . 11
4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 11
4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 12
4.3. RTM Capability Advertisement in Routing Protocols . . . . 13
4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . 13
4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . 14
4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . 14
4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . 14
4.4. RSVP-TE Control-Plane Operation to Support RTM . . . . . 15
4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . 16
5. Data-Plane Theory of Operation . . . . . . . . . . . . . . . 20
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 22
7.2. New MPLS RTM TLV Registry . . . . . . . . . . . . . . . . 22
7.3. New MPLS RTM Sub-TLV Registry . . . . . . . . . . . . . . 23
7.4. RTM Capability Sub-TLV in OSPFv2 . . . . . . . . . . . . 23
7.5. RTM Capability Sub-TLV in IS-IS . . . . . . . . . . . . . 24
7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . . . . 24
7.7. RTM_SET Sub-object RSVP Type and Sub-TLVs . . . . . . . . 25
7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 26
7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
Time synchronization protocols, e.g., the Network Time Protocol version 4 (NTPv4) [RFC5905] and the Precision Time Protocol version 2 (PTPv2) [IEEE.1588], define timing messages that can be used to synchronize clocks across a network domain. Measurement of the cumulative time that one of these timing messages spends transiting the nodes on the path from ingress node to egress node is termed "residence time" and is used to improve the accuracy of clock synchronization. Residence time is the sum of the difference between the time of receipt at an ingress interface and the time of transmission from an egress interface for each node along the network path from an ingress node to an egress node. This document defines a new Generic Associated Channel (G-ACh) value and an associated Residence Time Measurement (RTM) message that can be used in a Multiprotocol Label Switching (MPLS) network to measure residence time over a Label Switched Path (LSP).
时间同步协议，例如网络时间协议版本4（NTPv4）[RFC5905]和精确时间协议版本2（PTPv2）[IEEE.1588]，定义了可用于在网络域上同步时钟的定时消息。这些定时消息中的一个在从入口节点到出口节点的路径上传递节点所花费的累积时间的测量被称为“停留时间”，并用于提高时钟同步的准确性。停留时间是入口接口处的接收时间与每个节点沿从入口节点到出口节点的网络路径从出口接口传输的时间之差的总和。本文档定义了一个新的通用关联通道（G-ACh）值和关联的停留时间测量（RTM）消息，可在多协议标签交换（MPLS）网络中用于测量标签交换路径（LSP）上的停留时间。
This document describes RTM over an LSP signaled using RSVP-TE [RFC3209]. Using RSVP-TE, the LSP's path can be either explicitly specified or determined during signaling. Although it is possible to use RTM over an LSP instantiated using the Label Distribution Protocol [RFC5036], that is outside the scope of this document.
本文档描述了使用RSVP-TE[RFC3209]发送信号的LSP上的RTM。使用RSVP-TE，可以在信令期间显式指定或确定LSP的路径。尽管可以在使用标签分发协议[RFC5036]实例化的LSP上使用RTM，但这超出了本文档的范围。
Comparison with alternative proposed solutions such as [TIMING-OVER-MPLS] is outside the scope of this document.
与[TIMING-OVER-MPLS]等备选方案的比较不在本文件范围内。
MPLS: Multiprotocol Label Switching
多协议标签交换
ACH: Associated Channel Header
ACH：关联通道头
TTL: Time to Live
TTL：生命的时刻
G-ACh: Generic Associated Channel
G-ACh：通用关联信道
GAL: Generic Associated Channel Label
GAL：通用关联通道标签
NTP: Network Time Protocol
网络时间协议
ppm: parts per million
百万分之一：百万分之一
PTP: Precision Time Protocol
精确时间协议
BC: boundary clock
边界时钟
LSP: Label Switched Path
标签交换路径
OAM: Operations, Administration, and Maintenance
OAM：运营、管理和维护
RRO: Record Route Object
记录路由对象
RTM: Residence Time Measurement
停留时间测量
IGP: Internal Gateway Protocol
IGP：内部网关协议
BGP-LS: Border Gateway Protocol - Link State
BGP-LS：边界网关协议-链路状态
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]所述进行解释。
"Packet Loss and Delay Measurement for MPLS Networks" [RFC6374] can be used to measure one-way or two-way end-to-end propagation delay over an LSP or a pseudowire (PW). But these measurements are insufficient for use in some applications, for example, time synchronization across a network as defined in the PTP. In PTPv2 [IEEE.1588], the residence time is accumulated in the correctionField of the PTP event message, which is defined in [IEEE.1588] and referred to as using a one-step clock, or in the associated follow-up message (or Delay_Resp message associated with the Delay_Req message), which is referred to as using a two-step clock (see the detailed discussion in Section 2.1).
“MPLS网络的数据包丢失和延迟测量”[RFC6374]可用于测量LSP或伪线（PW）上的单向或双向端到端传播延迟。但这些测量不足以用于某些应用，例如PTP中定义的网络时间同步。在PTPv2[IEEE.1588]中，停留时间累积在PTP事件消息的校正字段中，该字段在[IEEE.1588]中定义，称为使用一步时钟，或在相关的后续消息（或与延迟请求消息相关的延迟响应消息）中，称为使用两步时钟（参见第2.1节中的详细讨论）。
IEEE 1588 uses this residence time to correct for the transit times of nodes on an LSP, effectively making the transit nodes transparent.
IEEE 1588使用此停留时间校正LSP上节点的传输时间，有效地使传输节点透明。
This document proposes a mechanism that can be used as one type of on-path support for a clock synchronization protocol or can be used to perform one-way measurement of residence time. The proposed mechanism accumulates residence time from all nodes that support this extension along the path of a particular LSP in the Scratch Pad field of an RTM message (Figure 1). This value can then be used by the egress node to update, for example, the correctionField of the PTP event packet carried within the RTM message prior to performing its PTP processing.
本文件提出了一种机制，该机制可用作时钟同步协议的一种路径上支持，或可用于执行停留时间的单向测量。建议的机制在RTM消息的草稿行字段中沿特定LSP的路径累积来自支持此扩展的所有节点的驻留时间（图1）。然后，该值可由出口节点用于例如在执行其PTP处理之前更新RTM消息内携带的PTP事件分组的校正字段。
One-step mode refers to the mode of operation where an egress interface updates the correctionField value of an original event message. Two-step mode refers to the mode of operation where this update is made in a subsequent follow-up message.
一步模式是指出口接口更新原始事件消息的correctionField值的操作模式。两步模式是指在后续后续消息中进行更新的操作模式。
Processing of the follow-up message, if present, requires the downstream endpoint to wait for the arrival of the follow-up message in order to combine correctionField values from both the original (event) message and the subsequent (follow-up) message. In a similar fashion, each two-step node needs to wait for the related follow-up message, if there is one, in order to update that follow-up message (as opposed to creating a new one). Hence, the first node that uses two-step mode MUST do two things:
后续消息（如果存在）的处理要求下游端点等待后续消息的到达，以便合并原始（事件）消息和后续（后续）消息中的更正字段值。以类似的方式，每个两步节点需要等待相关的后续消息（如果有），以便更新该后续消息（而不是创建新消息）。因此，使用两步模式的第一个节点必须做两件事：
1. Mark the original event message to indicate that a follow-up message will be forthcoming. This is necessary in order to
1. 标记原始事件消息以指示后续消息即将发布。这是必要的，以便
* Let any subsequent two-step node know that there is already a follow-up message, and
* 让任何后续两步节点知道已经有后续消息，并且
* Let the endpoint know to wait for a follow-up message.
* 让端点知道等待后续消息。
2. Create a follow-up message in which to put the RTM determined as an initial correctionField value.
2. 创建后续消息，将确定为初始校正字段值的RTM放入其中。
IEEE 1588v2 [IEEE.1588] defines this behavior for PTP messages.
IEEE 1588v2[IEEE.1588]定义了PTP消息的这种行为。
Thus, for example, with reference to the PTP protocol, the PTPType field identifies whether the message is a Sync message, Follow_up message, Delay_Req message, or Delay_Resp message. The 10-octet-long Port ID field contains the identity of the source port [IEEE.1588], that is, the specific PTP port of the boundary clock (BC) connected to the MPLS network. The Sequence ID is the sequence ID of the PTP message carried in the Value field of the message.
因此，例如，参照PTP协议，PTPType字段标识消息是同步消息、后续消息、延迟请求消息还是延迟响应消息。10个八位字节长的端口ID字段包含源端口[IEEE.1588]的标识，即连接到MPLS网络的边界时钟（BC）的特定PTP端口。序列ID是消息值字段中携带的PTP消息的序列ID。
PTP messages also include a bit that indicates whether or not a follow-up message will be coming. This bit MAY be set by a two-step mode PTP device. The value MUST NOT be unset until the original and follow-up messages are combined by an endpoint (such as a BC).
PTP消息还包括一个位，用于指示是否会出现后续消息。该位可由两步模式PTP设备设置。在端点（如BC）组合原始消息和后续消息之前，不得取消设置该值。
For compatibility with PTP, RTM (when used for PTP packets) must behave in a similar fashion. It should be noted that the handling of Sync event messages and of Delay_Req/Delay_Resp event messages that cross a two-step RTM node is different. The following outlines the handling of a PTP Sync event message by the two-step RTM node. The details of handling Delay_Resp/Delay_Req PTP event messages by the
为了与PTP兼容，RTM（用于PTP数据包时）必须以类似的方式运行。应注意，同步事件消息和跨两步RTM节点的延迟请求/延迟响应事件消息的处理是不同的。以下概述了两步RTM节点对PTP同步事件消息的处理。处理延迟响应/延迟请求PTP事件消息的详细信息
two-step RTM node are discussed in Section 2.1.1. As a summary, a two-step RTM-capable egress interface will need to examine the S bit in the Flags field of the PTP sub-TLV (for RTM messages that indicate they are for PTP), and -- if it is clear (set to zero) -- it MUST set the S bit and create a follow-up PTP Type RTM message. If the S bit is already set, then the RTM-capable node MUST wait for the RTM message with the PTP type of follow-up and matching originator and sequence number to make the corresponding residence time update to the Scratch Pad field. The wait period MUST be reasonably bounded.
第2.1.1节讨论了两步RTM节点。作为总结，支持两步RTM的出口接口需要检查PTP子TLV的标志字段中的S位（对于指示它们用于PTP的RTM消息），并且——如果清除（设置为零）——必须设置S位并创建后续PTP类型RTM消息。如果已经设置了S位，则支持RTM的节点必须等待具有PTP类型的后续和匹配的发起人和序列号的RTM消息，以对草稿行字段进行相应的停留时间更新。等待时间必须合理限定。
Thus, an RTM packet, containing residence time information relating to an earlier packet, also contains information identifying that earlier packet.
因此，包含与较早的分组相关的停留时间信息的RTM分组还包含识别该较早的分组的信息。
In practice, an RTM node operating in two-step mode behaves like a two-step transparent clock.
实际上，以两步模式运行的RTM节点的行为类似于两步透明时钟。
A one-step-capable RTM node MAY elect to operate in either one-step mode (by making an update to the Scratch Pad field of the RTM message containing the PTP event message) or two-step mode (by making an update to the Scratch Pad of a follow-up message when presence of a follow-up is indicated), but it MUST NOT do both.
支持一步的RTM节点可以选择在一步模式（通过更新包含PTP事件消息的RTM消息的暂存区字段）或两步模式（通过在指示存在后续时更新后续消息的暂存区）下操作，但不能同时执行这两种操作。
Two main subcases identified for an RTM node operating as a two-step clock are described in the following sub-sections.
以下小节描述了RTM节点作为两步时钟运行的两个主要子类别。
If any of the previous RTM-capable nodes or the previous PTP clock (e.g., the BC connected to the first node) is a two-step clock and if the local RTM-capable node is also operating a two-tep clock, the residence time is added to the RTM packet that has been created to include the second PTP packet (i.e., the follow-up message in the downstream direction). This RTM packet carries the related accumulated residence time, the appropriate values of the Sequence ID and Port ID (the same identifiers carried in the original packet), and the two-step flag set to 1.
如果先前支持RTM的节点或先前PTP时钟（例如，连接到第一节点的BC）中的任何一个是两步时钟，并且如果本地支持RTM的节点也在操作两步时钟，则将停留时间添加到已创建以包括第二PTP包的RTM包中（即，下游方向的后续消息）。该RTM数据包携带相关的累计停留时间、序列ID和端口ID的适当值（原始数据包中携带的相同标识符）以及设置为1的两步标志。
Note that the fact that an upstream RTM-capable node operating in two-step mode has created a follow-up message does not require any subsequent RTM-capable node to also operate in two-step mode, as long as that RTM-capable node forwards the follow-up message on the same LSP on which it forwards the corresponding previous message.
注意，在两步模式下运行的上游支持RTM的节点创建了后续消息这一事实并不要求任何后续支持RTM的节点也在两步模式下运行，只要该支持RTM的节点在其转发相应的先前消息的同一LSP上转发后续消息。
A one-step-capable RTM node MAY elect to update the RTM follow-up message as if it were operating in two-step mode; however, it MUST NOT update both messages.
具有一步能力的RTM节点可以选择更新RTM后续消息，如同其在两步模式下操作一样；但是，它不能同时更新这两条消息。
A PTP Sync packet is carried in the RTM packet in order to indicate to the RTM node that RTM must be performed on that specific packet.
在RTM分组中携带PTP Sync分组，以便向RTM节点指示必须对该特定分组执行RTM。
To handle the residence time of the Delay_Req message in the upstream direction, an RTM packet must be created to carry the residence time in the associated downstream Delay_Resp message.
为了在上游方向上处理Delay_Req消息的停留时间，必须创建一个RTM数据包，以在相关的下游Delay_Resp消息中携带停留时间。
The last RTM node of the MPLS network, in addition to updating the correctionField of the associated PTP packet, must also react properly to the two-step flag of the PTP packets.
MPLS网络的最后一个RTM节点除了更新相关PTP数据包的校正字段外，还必须对PTP数据包的两步标志做出正确反应。
When the PTP network connected to the MPLS operates in one-step clock mode and an RTM node operates in two-step mode, the follow-up RTM packet must be created by the RTM node itself. The RTM packet carrying the PTP event packet needs now to indicate that a follow-up message will be coming.
当连接到MPLS的PTP网络在一步时钟模式下运行，并且RTM节点在两步模式下运行时，后续RTM数据包必须由RTM节点本身创建。携带PTP事件包的RTM包现在需要指示后续消息即将到来。
The egress RTM-capable node of the LSP will remove RTM encapsulation and, in case of two-step clock mode being indicated, will generate PTP messages to include the follow-up correction as appropriate (according to [IEEE.1588]). In this case, the common header of the PTP packet carrying the synchronization message would have to be modified by setting the twoStepFlag field indicating that there is now a follow-up message associated to the current message.
LSP的支持出口RTM的节点将移除RTM封装，并且在指示两步时钟模式的情况下，将生成PTP消息以包括适当的后续校正（根据[IEEE.1588]）。在这种情况下，必须通过设置twoStepFlag字段来修改携带同步消息的PTP分组的公共报头，该字段指示现在存在与当前消息相关联的后续消息。
[RFC5586] and [RFC6423] define the G-ACh to extend the applicability of the Pseudowire Associated Channel Header (ACH) [RFC5085] to LSPs. G-ACh provides a mechanism to transport OAM and other control messages over an LSP. Processing of these messages by selected transit nodes is controlled by the use of the Time-to-Live (TTL) value in the MPLS header of these messages.
[RFC5586]和[RFC6423]定义了G-ACh，以将伪线相关信道头（ACh）[RFC5085]的适用性扩展到LSP。G-ACh提供了通过LSP传输OAM和其他控制消息的机制。通过使用这些消息的MPLS报头中的生存时间（TTL）值来控制所选传输节点对这些消息的处理。
The message format for RTM is presented in Figure 1.
RTM的消息格式如图1所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | RTM G-ACh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Scratch Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (optional) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | RTM G-ACh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Scratch Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (optional) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTM G-ACh Message Format for Residence Time Measurement
图1：停留时间测量的RTM G-ACh消息格式
o The first four octets are defined as a G-ACh header in [RFC5586].
o 前四个八位字节在[RFC5586]中定义为G-ACh报头。
o The Version field is set to 0, as defined in [RFC4385].
o 版本字段设置为0，如[RFC4385]中所定义。
o The Reserved field MUST be set to 0 on transmit and ignored on receipt.
o 传输时保留字段必须设置为0，接收时忽略。
o The RTM G-ACh field (value 0x000F; see Section 7.1) identifies the packet as such.
o RTM G-ACh字段（值0x000F；参见第7.1节）将数据包标识为该数据包。
o The Scratch Pad field is 8 octets in length. It is used to accumulate the residence time spent in each RTM-capable node transited by the packet on its path from ingress node to egress node. The first RTM-capable node MUST initialize the Scratch Pad field with its RTM. Its format is a 64-bit signed integer, and it indicates the value of the residence time measured in nanoseconds and multiplied by 2^16. Note that depending on whether the timing procedure is a one-step or two-step operation (Section 2.1), the residence time is either for the timing packet carried in the Value field of this RTM message or for an associated timing packet carried in the Value field of another RTM message.
o 便笺簿字段的长度为8个八位字节。它用于累积数据包在其从入口节点到出口节点的路径上传输的每个支持RTM的节点中花费的停留时间。第一个支持RTM的节点必须使用其RTM初始化草稿行字段。其格式为64位有符号整数，表示以纳秒为单位测量的停留时间值，并乘以2^16。注意，根据计时程序是一步操作还是两步操作（第2.1节），停留时间是该RTM消息的值字段中携带的计时数据包或另一RTM消息的值字段中携带的关联计时数据包的停留时间。
o The Type field identifies the type and encapsulation of a timing packet carried in the Value field, e.g., NTP [RFC5905] or PTP [IEEE.1588]. Per this document, IANA has created a sub-registry called the "MPLS RTM TLV Registry" in the "Generic Associated Channel (G-ACh) Parameters" registry (see Section 7.2).
o 类型字段标识值字段中携带的定时数据包的类型和封装，例如NTP[RFC5905]或PTP[IEEE.1588]。根据本文件，IANA在“通用关联通道（G-ACh）参数”注册表中创建了一个称为“MPLS RTM TLV注册表”的子注册表（见第7.2节）。
o The Length field contains the length, in octets, of any Value field defined for the Type given in the Type field.
o 长度字段包含为类型字段中给定的类型定义的任何值字段的长度（以八位字节为单位）。
o The TLV MUST be included in the RTM message, even if the length of the Value field is zero.
o 即使值字段的长度为零，TLV也必须包含在RTM消息中。
Figure 2 presents the format of a PTP sub-TLV that MUST be included in the Value field of an RTM message preceding the carried timing packet when the timing packet is PTP.
图2显示了PTP子TLV的格式，当定时数据包为PTP时，该格式必须包含在所携带的定时数据包之前的RTM消息的值字段中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |PTPType|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Sequence ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |PTPType|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Sequence ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PTP Sub-TLV Format
图2:PTP子TLV格式
where the Flags field has the following format:
其中“标志”字段的格式如下：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flags Field Format of PTP Packet Sub-TLV
图3:PTP数据包子TLV的标志字段格式
o The Type field identifies the PTP packet sub-TLV and is set to 1 according to Section 7.3.
o 类型字段标识PTP数据包子TLV，并根据第7.3节设置为1。
o The Length field of the PTP sub-TLV contains the number of octets of the Value part of the TLV and MUST be 20.
o PTP子TLV的长度字段包含TLV值部分的八位字节数，必须为20。
o The Flags field currently defines one bit, the S bit, that defines whether the current message has been processed by a two-step node, where the flag is cleared if the message has been handled exclusively by one-step nodes and there is no follow-up message and is set if there has been at least one two-step node and a follow-up message is forthcoming.
o Flags字段当前定义一个位，即S位，用于定义当前消息是否已由两步节点处理，其中，如果消息已由一步节点独占处理且没有后续消息，则清除该标志；如果已存在至少一个两步节点且后续消息即将出现，则设置该标志。
o The PTPType field indicates the type of PTP packet to which this PTP sub-TLV applies. PTPType is the messageType field of a PTPv2 packet with possible values defined in Table 19 of [IEEE.1588].
o PTP类型字段指示此PTP子TLV应用的PTP数据包的类型。PTPType是PTPv2数据包的messageType字段，其可能值在[IEEE.1588]的表19中定义。
o The 10-octet-long Port ID field contains the identity of the source port.
o 10个八位字节长的端口ID字段包含源端口的标识。
o The Sequence ID is the sequence ID of the PTP message to which this PTP sub-TLV applies.
o 序列ID是该PTP子TLV适用的PTP消息的序列ID。
A tuple of PTPType, Port ID, and Sequence ID uniquely identifies the PTP timing message included in an RTM message and is used in two-step RTM mode; see Section 2.1.1.
PTP类型、端口ID和序列ID的元组唯一地标识包括在RTM消息中的PTP定时消息，并在两步RTM模式中使用；见第2.1.1节。
The Value field (see Figure 1) -- in addition to the PTP sub-TLV -- MAY carry a packet of the PTP Time synchronization protocol (as was identified by the Type field). It is important to note that the timing message packet may be authenticated or encrypted and carried over this LSP unchanged (and inaccessible to intermediate RTM capable LSRs) while the residence time is accumulated in the Scratch Pad field.
值字段（见图1）——除了PTP子TLV之外——可以携带PTP时间同步协议的数据包（由类型字段标识）。重要的是要注意，当驻留时间累积在暂存区字段中时，定时消息分组可以被认证或加密，并在该LSP上保持不变（并且对于具有RTM能力的中间lsr不可访问）。
The LSP ingress RTM-capable LSR populates the identifying tuple information of the PTP sub-TLV (see section 3.1) prior to including the (possibly authenticated/encrypted) PTP message packet after the PTP sub-TLV in the Value field of the RTM message for an RTM message of the PTP Type (Type 1; see Section 7.3).
支持LSP入口RTM的LSR填充PTP子TLV的标识元组信息（参见第3.1节），然后将PTP子TLV之后的PTP消息包（可能经过身份验证/加密）包含在PTP类型（类型1；参见第7.3节）RTM消息的RTM消息的值字段中。
The operation of RTM depends upon TTL expiry to deliver an RTM packet from one RTM-capable interface to the next along the path from ingress node to egress node. This means that a node with RTM-capable interfaces MUST be able to compute a TTL, which will cause the expiry of an RTM packet at the next node with RTM-capable interfaces.
RTM的操作取决于TTL到期，以沿着从入口节点到出口节点的路径将RTM数据包从一个支持RTM的接口传送到下一个接口。这意味着具有RTM功能接口的节点必须能够计算TTL，这将导致具有RTM功能接口的下一个节点的RTM数据包过期。
Note that the RTM capability of a node is with respect to the pair of interfaces that will be used to forward an RTM packet. In general, the ingress interface of this pair must be able to capture the arrival time of the packet and encode it in some way such that this information will be available to the egress interface of a node.
请注意，节点的RTM功能与将用于转发RTM数据包的一对接口有关。通常，这一对的入口接口必须能够捕获数据包的到达时间，并以某种方式对其进行编码，以便该信息将可用于节点的出口接口。
The supported mode (one-step or two-step) of any pair of interfaces is determined by the capability of the egress interface. For both modes, the egress interface implementation MUST be able to determine the precise departure time of the same packet and determine from this, and the arrival time information from the corresponding ingress interface, the difference representing the residence time for the packet.
任何一对接口的支持模式（一步或两步）由出口接口的能力决定。对于这两种模式，出口接口实现必须能够确定相同分组的精确离开时间，并根据该时间和来自相应入口接口的到达时间信息确定表示分组停留时间的差。
An interface with the ability to do this and update the associated Scratch Pad in real time (i.e., while the packet is being forwarded) is said to be one-step capable.
一个能够做到这一点并实时（即，当数据包被转发时）更新相关便笺簿的接口被称为一步式接口。
Hence, while both ingress and egress interfaces are required to support RTM for the pair to be RTM capable, it is the egress interface that determines whether or not the node is one-step or two-step capable with respect to the interface pair.
因此，尽管入口和出口接口都需要支持RTM以使该对能够RTM，但出口接口确定节点相对于该接口对是一步还是两步。
The RTM capability used in the sub-TLV shown in Figures 4 and 5 is thus a non-routing-related capability associated with the interface being advertised based on its egress capability. The ability of any pair of interfaces on a node that includes this egress interface to support any mode of RTM depends on the ability of the ingress interface of a node to record packet arrival time and convey it to the egress interface on the node.
因此，图4和图5所示的子TLV中使用的RTM能力是与基于其出口能力发布的接口相关联的非路由相关能力。包括该出口接口的节点上的任何接口对支持任何RTM模式的能力取决于节点的入口接口记录分组到达时间并将其传送到节点上的出口接口的能力。
When a node uses an IGP to support the RTM capability advertisement, the IGP sub-TLV MUST reflect the RTM capability (one-step or two-step) associated with the advertised interface. Changes of RTM capability are unlikely to be frequent and would result, for example, from the operator's decision to include or exclude a particular port from RTM processing or switch between RTM modes.
当节点使用IGP支持RTM能力公告时，IGP子TLV必须反映与公告接口相关联的RTM能力（一步或两步）。RTM能力的变化不太可能频繁，例如，由于运营商决定从RTM处理中包括或排除特定端口，或在RTM模式之间切换，可能会导致RTM能力的变化。
[RFC4202] explains that the Interface Switching Capability Descriptor describes the switching capability of an interface. For bidirectional links, the switching capabilities of an interface are defined to be the same in either direction, that is, for data entering the node through that interface and for data leaving the node through that interface. That principle SHOULD be applied when a node advertises RTM capability.
[RFC4202]说明接口交换能力描述符描述接口的交换能力。对于双向链路，接口的交换能力定义为在任一方向上相同，即，对于通过该接口进入节点的数据和通过该接口离开节点的数据。当节点宣传RTM功能时，应应用该原则。
A node that supports RTM MUST be able to act in two-step mode and MAY also support one-step RTM mode. A detailed discussion of one-step and two-step RTM modes is contained in Section 2.1.
支持RTM的节点必须能够以两步模式工作，也可以支持一步RTM模式。第2.1节详细讨论了一步和两步RTM模式。
The format for the RTM Capability sub-TLV in OSPF is presented in Figure 4.
OSPF中RTM能力子TLV的格式如图4所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTM | Value ...
+-+-+-+-+-+-+-+-+-+- ...
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTM | Value ...
+-+-+-+-+-+-+-+-+-+- ...
Figure 4: RTM Capability Sub-TLV in OSPFv2
图4:OSPFv2中RTM能力子TLV
o Type value (5) has been assigned by IANA in the "OSPFv2 Extended Link TLV Sub-TLVs" registry (see Section 7.4).
o IANA在“OSPFv2扩展链路TLV子TLV”注册表中分配了类型值（5）（见第7.4节）。
o Length value equals the number of octets of the Value field.
o 长度值等于值字段的八位字节数。
o Value contains a variable number of bitmap fields so that the overall number of bits in the fields equals Length * 8.
o 值包含可变数量的位图字段，因此字段中的总位数等于长度*8。
o Bits are defined/sent starting with Bit 0. Additional bitmap field definitions that may be defined in the future SHOULD be assigned in ascending bit order so as to minimize the number of bits that will need to be transmitted.
o 从位0开始定义/发送位。将来可能定义的其他位图字段定义应按升序分配，以便将需要传输的位数降至最低。
o Undefined bits MUST be transmitted as 0 and MUST be ignored on receipt.
o 未定义的位必须作为0传输，并且在接收时必须忽略。
o Bits that are NOT transmitted MUST be treated as if they are set to 0 on receipt.
o 未传输的位必须视为在接收时设置为0。
o RTM (capability) is a 3-bit-long bitmap field with values defined as follows:
o RTM（功能）是一个3位长的位图字段，其值定义如下：
* 0b001 - one-step RTM supported
* 0b001-支持一步RTM
* 0b010 - two-step RTM supported
* 0b010-支持两步RTM
* 0b100 - reserved
* 0b100-保留
The capability to support RTM on a particular link (interface) is advertised in the OSPFv2 Extended Link Opaque LSA as described in Section 3 of [RFC7684] via the RTM Capability sub-TLV.
在特定链路（接口）上支持RTM的能力通过RTM能力子TLV在OSPFv2扩展链路不透明LSA中公布，如[RFC7684]第3节所述。
The capability to support RTM on a particular link (interface) can be advertised in OSPFv3 using LSA extensions as described in [OSPFV3-EXTENDED-LSA]. The sub-TLV SHOULD use the same format as in Section 4.3.1. The type allocation and full details of exact use of OSPFv3 LSA extensions is for further study.
在特定链路（接口）上支持RTM的能力可以使用[OSPFv3-EXTENDED-LSA]中所述的LSA扩展在OSPFv3中公布。子TLV应使用与第4.3.1节相同的格式。OSPFv3 LSA扩展的类型分配和确切使用的全部细节有待进一步研究。
The capability to support RTM on a particular link (interface) is advertised in a new sub-TLV that may be included in TLVs advertising Intermediate System (IS) Reachability on a specific link (TLVs 22, 23, 222, and 223).
在特定链路（接口）上支持RTM的能力在新的子TLV中公布，该子TLV可包括在特定链路（TLV 22、23、222和223）上的TLV公布中间系统（is）可达性中。
The format for the RTM Capability sub-TLV is presented in Figure 5.
RTM能力子TLV的格式如图5所示。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Type | Length | RTM | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Type | Length | RTM | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 5: RTM Capability Sub-TLV
图5:RTM能力子TLV
o Type value (40) has been assigned by IANA in the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry for IS-IS (see Section 7.5).
o IANA已在IS-IS的“用于TLV 22、23、141、222和223的子TLV”注册表中指定了类型值（40）（见第7.5节）。
o Definitions, rules of handling, and values for the Length and Value fields are as defined in Section 4.3.1.
o 定义、处理规则以及长度和值字段的值如第4.3.1节所述。
o RTM (capability) is a 3-bit-long bitmap field with values defined in Section 4.3.1.
o RTM（能力）是一个3位长的位图字段，其值在第4.3.1节中定义。
The format for the RTM Capability TLV is presented in Figure 4.
RTM能力TLV的格式如图4所示。
Type value (1105) has been assigned by IANA in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" sub-registry (see Section 7.6).
IANA在“BGP-LS节点描述符、链路描述符、前缀描述符和属性TLV”子注册表中分配了类型值（1105）（见第7.6节）。
Definitions, rules of handling, and values for fields Length, Value, and RTM are as defined in Section 4.3.1.
第4.3.1节定义了字段长度、值和RTM的定义、处理规则和值。
The RTM capability will be advertised in BGP-LS as a Link Attribute TLV associated with the Link NLRI as described in Section 3.3.2 of [RFC7752].
如[RFC7752]第3.3.2节所述，RTM能力将作为与链路NLRI相关联的链路属性TLV在BGP-LS中公布。
Throughout this document, we refer to a node as an RTM-capable node when at least one of its interfaces is RTM capable. Figure 6 provides an example of roles a node may have with respect to RTM capability:
在本文档中，当一个节点的至少一个接口支持RTM时，我们将其称为支持RTM的节点。图6提供了一个节点在RTM能力方面可能具有的角色示例：
----- ----- ----- ----- ----- ----- -----
| A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G |
----- ----- ----- ----- ----- ----- -----
----- ----- ----- ----- ----- ----- -----
| A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G |
----- ----- ----- ----- ----- ----- -----
Figure 6: RTM-Capable Roles
图6：支持RTM的角色
o A is a boundary clock with its egress port in Master state. Node A transmits IP-encapsulated timing packets whose destination IP address is G.
o A是一个边界时钟，其出口端口处于主状态。节点A发送目的地IP地址为G的IP封装的定时分组。
o B is the ingress Label Edge Router (LER) for the MPLS LSP and is the first RTM-capable node. It creates RTM packets, and in each it places a timing packet, possibly encrypted, in the Value field and initializes the Scratch Pad field with its RTM.
o B是MPLS LSP的入口标签边缘路由器（LER），是第一个支持RTM的节点。它创建RTM数据包，并在每个数据包的值字段中放置一个可能已加密的定时数据包，并用其RTM初始化草稿行字段。
o C is a transit node that is not RTM capable. It forwards RTM packets without modification.
o C是不支持RTM的传输节点。它无需修改即可转发RTM数据包。
o D is an RTM-capable transit node. It updates the Scratch Pad field of the RTM packet without updating the timing packet.
o D是支持RTM的传输节点。它更新RTM数据包的草稿行字段，而不更新定时数据包。
o E is a transit node that is not RTM capable. It forwards RTM packets without modification.
o E是不支持RTM的传输节点。它无需修改即可转发RTM数据包。
o F is the egress LER and the last RTM-capable node. It removes the RTM ACH encapsulation and processes the timing packet carried in the Value field using the value in the Scratch Pad field. In particular, the value in the Scratch Pad field of the RTM ACH is used in updating the Correction field of the PTP message(s). The LER should also include its own residence time before creating the outgoing PTP packets. The details of this process depend on whether or not the node F is itself operating as a one-step or two-step clock.
o F是出口LER和最后一个支持RTM的节点。它删除RTM ACH封装，并使用草稿行字段中的值处理值字段中携带的定时数据包。具体地，RTM ACH的暂存区字段中的值用于更新PTP消息的校正字段。在创建传出PTP数据包之前，LER还应包括其自身的停留时间。该过程的细节取决于节点F本身是否作为一步或两步时钟工作。
o G is a boundary clock with its ingress port in Slave state. Node G receives PTP messages.
o G是入口端口处于从属状态的边界时钟。节点G接收PTP消息。
An ingress node that is configured to perform RTM along a path through an MPLS network to an egress node MUST verify that the selected egress node has an interface that supports RTM via the egress node's advertisement of the RTM Capability sub-TLV, as covered in Section 4.3. In the Path message that the ingress node uses to instantiate the LSP to that egress node, it places an LSP_ATTRIBUTES object [RFC5420] with an RTM_SET Attribute Flag set, as described in Section 7.8, which indicates to the egress node that RTM is requested for this LSP. The RTM_SET Attribute Flag SHOULD NOT be set in the LSP_REQUIRED_ATTRIBUTES object [RFC5420], unless it is known that all nodes recognize the RTM attribute (but need not necessarily implement it), because a node that does not recognize the RTM_SET Attribute Flag would reject the Path message.
配置为沿着通过MPLS网络到出口节点的路径执行RTM的入口节点必须验证所选出口节点具有通过出口节点的RTM能力子TLV广告支持RTM的接口，如第4.3节所述。在入口节点用于将LSP实例化到该出口节点的路径消息中，它放置一个设置了RTM_集属性标志的LSP_属性对象[RFC5420]，如第7.8节所述，该属性标志向出口节点指示该LSP请求RTM。不应在LSP_REQUIRED_ATTRIBUTES对象[RFC5420]中设置RTM_集属性标志，除非已知所有节点都识别RTM属性（但不必实现），因为不识别RTM_集属性标志的节点将拒绝路径消息。
If an egress node receives a Path message with the RTM_SET Attribute Flag in an LSP_ATTRIBUTES object, the egress node MUST include an initialized RRO [RFC3209] and LSP_ATTRIBUTES object where the RTM_SET Attribute Flag is set and the RTM_SET TLV (Section 4.4.1) is initialized. When the Resv message is received by the ingress node, the RTM_SET TLV will contain an ordered list, from egress node to ingress node, of the RTM-capable nodes along the LSP's path.
如果出口节点在LSP_属性对象中接收到带有RTM_设置属性标志的路径消息，则出口节点必须包括初始化的RRO[RFC3209]和LSP_属性对象，其中设置RTM_设置属性标志，并初始化RTM_设置TLV（第4.4.1节）。当入口节点接收到Resv消息时，RTM_SET TLV将包含沿LSP路径的具有RTM能力的节点的有序列表，从出口节点到入口节点。
After the ingress node receives the Resv, it MAY begin sending RTM packets on the LSP's path. Each RTM packet has its Scratch Pad field initialized and its TTL set to expire on the closest downstream RTM-capable node.
在入口节点接收到Resv之后，它可以开始在LSP的路径上发送RTM分组。每个RTM数据包的草稿行字段都已初始化，其TTL设置为在最近的下游RTM节点上过期。
It should be noted that RTM can also be used for LSPs instantiated using [RFC3209] in an environment in which all interfaces in an IGP support RTM. In this case, the RTM_SET TLV and LSP_ATTRIBUTES object MAY be omitted.
应该注意的是，RTM还可以用于在IGP中的所有接口都支持RTM的环境中使用[RFC3209]实例化的LSP。在这种情况下，可以省略RTM_SET TLV和LSP_属性对象。
RTM-capable interfaces can be recorded via the RTM_SET TLV. The RTM_SET sub-object format is a generic TLV format, presented in Figure 7.
可通过RTM_SET TLV记录支持RTM的接口。RTM_集子对象格式是一种通用TLV格式，如图7所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: RTM_SET TLV Format
图7:RTM_集TLV格式
Type value (5) has been assigned by IANA in the RSVP-TE "Attributes TLV Space" sub-registry (see Section 7.7).
IANA已在RSVP-TE“属性TLV空间”子注册表中分配类型值（5）（见第7.7节）。
The Length contains the total length of the sub-object in bytes, including the Type and Length fields.
长度包含子对象的总长度（字节），包括类型和长度字段。
The I bit indicates whether the downstream RTM-capable node along the LSP is present in the RRO.
I位指示沿LSP的下游支持RTM的节点是否存在于RRO中。
The Reserved field must be zeroed on initiation and ignored on receipt.
保留字段在启动时必须归零，在接收时必须忽略。
The content of an RTM_SET TLV is a series of variable-length sub-TLVs. Only a single RTM_SET can be present in a given LSP_ATTRIBUTES object. The sub-TLVs are defined in Section 4.4.1.1.
RTM_集TLV的内容是一系列可变长度子TLV。给定的LSP_属性对象中只能存在一个RTM_集。第4.4.1.1节定义了子TLV。
The following processing procedures apply to every RTM-capable node along the LSP. In this paragraph, an RTM-capable node is referred to as a node for sake of brevity. Each node MUST examine the Resv message for whether the RTM_SET Attribute Flag in the LSP_ATTRIBUTES object is set. If the RTM_SET flag is set, the node MUST inspect the LSP_ATTRIBUTES object for presence of an RTM_SET TLV. If more than one is found, then the LSP setup MUST fail with generation of the ResvErr message with Error Code "Duplicate TLV" (Section 7.9) and Error Value that contains the Type value in its 8 least significant bits. If no RTM_SET TLV is found, then the LSP setup MUST fail with generation of the ResvErr message with Error Code "RTM_SET TLV Absent" (Section 7.9). If one RTM_SET TLV has been found, the node will use the ID of the first node in the RTM_SET in conjunction with the RRO to compute the hop count to its downstream node with a reachable RTM-capable interface. If the node cannot find a matching ID in the RRO, then it MUST try to use the ID of the next node in the RTM_SET until it finds the match or reaches the end of the RTM_SET TLV. If a match has been found, the calculated value is used by the node as the TTL value in the outgoing label to reach the next RTM-capable node on the LSP. Otherwise, the TTL value MUST be set to 255. The node MUST add an RTM_SET sub-TLV with the same address it used in the RRO sub-object at the beginning of the RTM_SET TLV in the associated outgoing Resv message before forwarding it upstream. If the calculated TTL value has been set to 255, as described above, then the I flag in the node's RTM_SET TLV MUST be set to 1 before the Resv message is forwarded upstream. Otherwise, the I flag MUST be cleared (0).
以下处理过程适用于LSP沿线的每个支持RTM的节点。在本段中，为了简洁起见，将支持RTM的节点称为节点。每个节点都必须检查Resv消息，以确定是否设置了LSP_ATTRIBUTES对象中的RTM_SET属性标志。如果设置了RTM_集标志，则节点必须检查LSP_属性对象是否存在RTM_集TLV。如果找到多个，则LSP设置必须失败，并生成错误代码为“Duplicate TLV”（第7.9节）且错误值包含8个最低有效位中的类型值的ResvErr消息。如果未找到RTM_设置TLV，则LSP设置必须失败，并生成错误代码为“RTM_设置TLV缺席”的ResvErr消息（第7.9节）。如果已找到一个RTM_集TLV，则节点将使用RTM_集中第一个节点的ID与RRO一起使用可访问的RTM接口计算其下游节点的跃点计数。如果节点在RRO中找不到匹配的ID，则必须尝试使用RTM_集中下一个节点的ID，直到找到匹配项或到达RTM_集TLV的末尾。如果找到匹配项，则节点将计算出的值用作传出标签中的TTL值，以到达LSP上的下一个支持RTM的节点。否则，TTL值必须设置为255。在向上游转发之前，节点必须在关联的传出Resv消息中的RTM_集TLV开头添加一个RTM_集子TLV，其地址与在RRO子对象中使用的地址相同。如上文所述，如果已将计算的TTL值设置为255，则在向上游转发Resv消息之前，必须将节点的RTM_set TLV中的I标志设置为1。否则，必须清除I标志（0）。
The ingress node MAY inspect the I bit received in each RTM_SET TLV contained in the LSP_ATTRIBUTES object of a received Resv message. The presence of the RTM_SET TLV with the I bit set to 1 indicates that some RTM nodes along the LSP could not be included in the
入口节点可以检查在接收到的Resv消息的LSP_属性对象中包含的每个RTM_集TLV中接收到的I比特。I位设置为1的RTM_SET TLV的存在表明LSP上的一些RTM节点不能包括在
calculation of the residence time. An ingress node MAY choose to resignal the LSP to include all RTM nodes or simply notify the user via a management interface.
停留时间的计算。入口节点可以选择重新签名LSP以包括所有RTM节点，或者简单地通过管理接口通知用户。
There are scenarios when some information is removed from an RRO due to policy processing (e.g., as may happen between providers) or the RRO is limited due to size constraints. Such changes affect the core assumption of this method and the processing of RTM packets. RTM SHOULD NOT be used if it is not guaranteed that the RRO contains complete information.
有些情况下，由于策略处理（例如，提供者之间可能发生的情况）而从RRO中删除某些信息，或者由于大小限制而限制RRO。这些变化影响了该方法的核心假设和RTM数据包的处理。如果不能保证RRO包含完整信息，则不应使用RTM。
The RTM Set sub-object contains an ordered list, from egress node to ingress node, of the RTM-capable nodes along the LSP's path.
RTM集合子对象包含沿LSP路径的支持RTM的节点的有序列表，从出口节点到入口节点。
The contents of an RTM_SET sub-object are a series of variable-length sub-TLVs. Each sub-TLV has its own Length field. The Length contains the total length of the sub-TLV in bytes, including the Type and Length fields. The Length MUST always be a multiple of 4, and at least 8 (smallest IPv4 sub-object).
RTM_集子对象的内容是一系列可变长度的子TLV。每个子TLV都有自己的长度字段。长度包含子TLV的总长度（字节），包括类型和长度字段。长度必须始终为4的倍数，且至少为8（最小IPv4子对象）。
Sub-TLVs are organized as a last-in-first-out stack. The first-out sub-TLV relative to the beginning of RTM_SET TLV is considered the top. The last-out sub-TLV is considered the bottom. When a new sub-TLV is added, it is always added to the top.
子TLV被组织为后进先出堆栈。相对于RTM_集TLV开头的先出子TLV被视为顶部。最后一个子TLV被视为底部。添加新的子TLV时，它始终添加到顶部。
The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs that represent those egress interfaces on the LSP that are RTM capable. After a node chooses an egress interface to use in the RRO sub-TLV, that same egress interface, if RTM capable, SHOULD be placed into the RTM_SET TLV using one of the following: IPv4 sub-TLV, IPv6 sub-TLV, or Unnumbered Interface sub-TLV. The address family chosen SHOULD match that of the RESV message and that used in the RRO; the unnumbered interface sub-TLV is used when the egress interface has no assigned IP address. A node MUST NOT place more sub-TLVs in the RTM_SET TLV than the number of RTM-capable egress interfaces the LSP traverses that are under that node's control. Only a single RTM_SET sub-TLV with the given Value field MUST be present in the RTM_SET TLV. If more than one sub-TLV with the same value (e.g., a duplicated address) is found, the LSP setup MUST fail with the generation of a ResvErr message with the Error Code "Duplicate sub-TLV" (Section 7.9) and the Error Value containing a 16-bit value composed of (Type of TLV, Type of sub-TLV).
RTM_集TLV旨在包括代表LSP上支持RTM的出口接口的RRO子TLV的子集。节点选择要在RRO子TLV中使用的出口接口后，如果支持RTM，则该出口接口应使用以下选项之一放置到RTM_集TLV中：IPv4子TLV、IPv6子TLV或无编号接口子TLV。选择的地址族应与RESV消息和RRO中使用的地址族匹配；当出口接口没有分配的IP地址时，使用未编号的接口子TLV。节点在RTM_集TLV中放置的子TLV不得超过LSP在该节点控制下通过的支持RTM的出口接口的数量。RTM_集TLV中只能存在一个带有给定值字段的RTM_集子TLV。如果发现多个具有相同值（例如，重复地址）的子TLV，则LSP设置必须失败，生成错误代码为“Duplicate sub TLV”（第7.9节）且错误值包含由（TLV类型，子TLV类型）组成的16位值的ResvErr消息。
Three kinds of sub-TLVs for RTM_SET are currently defined.
目前定义了RTM_集的三种子TLV。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IPv4 Sub-TLV Format
图8:IPv4子TLV格式
Type 0x01 IPv4 address.
键入0x01 IPv4地址。
Length The Length contains the total length of the sub-TLV in bytes, including the Type and Length fields. The Length is always 8.
长度长度包含子TLV的总长度（字节），包括类型和长度字段。长度始终为8。
IPv4 address A 32-bit unicast host address.
IPv4地址32位单播主机地址。
Reserved Zeroed on initiation and ignored on receipt.
保留在启动时归零，在接收时忽略。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: IPv6 Sub-TLV Format
图9:IPv6子TLV格式
Type 0x02 IPv6 address.
键入0x02 IPv6地址。
Length The Length contains the total length of the sub-TLV in bytes, including the Type and Length fields. The Length is always 20.
长度长度包含子TLV的总长度（字节），包括类型和长度字段。长度始终为20。
IPv6 address A 128-bit unicast host address.
IPv6地址128位单播主机地址。
Reserved Zeroed on initiation and ignored on receipt.
保留在启动时归零，在接收时忽略。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: IPv4 Sub-TLV Format
图10:IPv4子TLV格式
Type 0x03 Unnumbered interface.
键入0x03未编号的接口。
Length The Length contains the total length of the sub-TLV in bytes, including the Type and Length fields. The Length is always 12.
长度长度包含子TLV的总长度（字节），包括类型和长度字段。长度始终为12。
Node ID The Node ID interpreted as the Router ID as discussed in Section 2 of [RFC3477].
节点ID被解释为[RFC3477]第2节中讨论的路由器ID的节点ID。
Interface ID The identifier assigned to the link by the node specified by the Node ID.
接口ID由节点ID指定的节点分配给链接的标识符。
Reserved Zeroed on initiation and ignored on receipt.
保留在启动时归零，在接收时忽略。
After instantiating an LSP for a path using RSVP-TE [RFC3209] as described in Section 4.4, the ingress node MAY begin sending RTM packets to the first downstream RTM-capable node on that path. Each RTM packet has its Scratch Pad field initialized and its TTL set to expire on the next downstream RTM-capable node. Each RTM-capable node on the explicit path receives an RTM packet and records the time at which it receives that packet at its ingress interface as well as the time at which it transmits that packet from its egress interface.
如第4.4节所述，在使用RSVP-TE[RFC3209]为路径实例化LSP之后，入口节点可以开始向该路径上的第一个下游支持RTM的节点发送RTM分组。每个RTM数据包都初始化了其暂存区字段，并将其TTL设置为在下一个下游支持RTM的节点上过期。显式路径上的每个支持RTM的节点接收RTM分组，并记录其在其入口接口接收该分组的时间以及其从其出口接口发送该分组的时间。
These actions should be done as close to the physical layer as possible at the same point of packet processing, striving to avoid introducing the appearance of jitter in propagation delay whereas it should be accounted as residence time. The RTM-capable node determines the difference between those two times; for one-step operation, this difference is determined just prior to or while sending the packet, and the RTM-capable egress interface adds it to the value in the Scratch Pad field of the message in progress. Note, for the purpose of calculating a residence time, a common free running clock synchronizing all the involved interfaces may be sufficient, as, for example, 4.6 ppm accuracy leads to a 4.6 nanosecond error for residence time on the order of 1 millisecond. This may be acceptable for applications where the target accuracy is in the order of hundreds of nanoseconds. As an example, several applications being considered in the area of wireless applications are satisfied with an accuracy of 1.5 microseconds [ITU-T.G.8271].
在数据包处理的同一点上，这些操作应尽可能靠近物理层，尽量避免在传播延迟中出现抖动，而应将其视为停留时间。支持RTM的节点确定这两次之间的差异；对于一步操作，该差异在发送分组之前或发送分组时确定，并且支持RTM的出口接口将其添加到正在进行的消息的草稿行字段中的值中。注意，为了计算停留时间，同步所有相关接口的公共自由运行时钟可能就足够了，例如，4.6 ppm精度导致停留时间的4.6纳秒误差约为1毫秒。对于目标精度在数百纳秒量级的应用，这是可以接受的。例如，在无线应用领域考虑的几个应用满足1.5微秒的精度[ITU-T.G.8271]。
For two-step operation, the difference between packet arrival time (at an ingress interface) and subsequent departure time (from an egress interface) is determined at some later time prior to sending a subsequent follow-up message, so that this value can be used to update the correctionField in the follow-up message.
对于两步操作，分组到达时间（在入口接口处）和随后离开时间（从出口接口处）之间的差值在发送后续后续后续消息之前的某个稍后时间确定，以便该值可用于更新后续消息中的校正字段。
See Section 2.1 for further details on the difference between one-step and two-step operation.
有关一步操作和两步操作之间差异的更多详细信息，请参见第2.1节。
The last RTM-capable node on the LSP MAY then use the value in the Scratch Pad field to perform time correction, if there is no follow-up message. For example, the egress node may be a PTP boundary clock synchronized to a Master Clock and will use the value in the Scratch Pad field to update PTP's correctionField.
如果没有后续消息，则LSP上最后一个支持RTM的节点可以使用草稿行字段中的值来执行时间校正。例如，出口节点可以是与主时钟同步的PTP边界时钟，并且将使用暂存板字段中的值来更新PTP的校正字段。
This approach can be directly integrated in a PTP network based on the IEEE 1588 delay request-response mechanism. The RTM-capable nodes act as end-to-end transparent clocks, and boundary clocks, at the edges of the MPLS network, typically use the value in the Scratch Pad field to update the correctionField of the corresponding PTP event packet prior to performing the usual PTP processing.
这种方法可以直接集成在基于IEEE 1588延迟请求-响应机制的PTP网络中。支持RTM的节点充当端到端透明时钟，并且在MPLS网络的边缘处的边界时钟通常在执行通常的PTP处理之前使用暂存区字段中的值来更新相应PTP事件分组的校正区。
IANA has assigned a new G-ACh as follows:
IANA分配了一个新的G-ACh，如下所示：
+--------+----------------------------+---------------+
| Value | Description | Reference |
+--------+----------------------------+---------------+
| 0x000F | Residence Time Measurement | This document |
+--------+----------------------------+---------------+
+--------+----------------------------+---------------+
| Value | Description | Reference |
+--------+----------------------------+---------------+
| 0x000F | Residence Time Measurement | This document |
+--------+----------------------------+---------------+
Table 1: New Residence Time Measurement
表1：新的停留时间测量
IANA has created a sub-registry in the "Generic Associated Channel (G-ACh) Parameters" registry called the "MPLS RTM TLV Registry". All codepoints in the range 0 through 127 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC5226]. Codepoints in the range 128 through 191 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC5226]. This document defines the following new RTM TLV types:
IANA在“通用关联通道（G-ACh）参数”注册表中创建了一个子注册表，称为“MPLS RTM TLV注册表”。应根据[RFC5226]中规定的“IETF审查”程序分配该注册表中0到127范围内的所有代码点。应根据[RFC5226]中规定的“先到先得”程序分配该注册表中128到191范围内的代码点。本文件定义了以下新的RTM TLV类型：
+---------+-------------------------------+---------------+
| Value | Description | Reference |
+---------+-------------------------------+---------------+
| 0 | Reserved | This document |
| 1 | No payload | This document |
| 2 | PTPv2, Ethernet encapsulation | This document |
| 3 | PTPv2, IPv4 encapsulation | This document |
| 4 | PTPv2, IPv6 encapsulation | This document |
| 5 | NTP | This document |
| 6-191 | Unassigned | |
| 192-254 | Reserved for Private Use | This document |
| 255 | Reserved | This document |
+---------+-------------------------------+---------------+
+---------+-------------------------------+---------------+
| Value | Description | Reference |
+---------+-------------------------------+---------------+
| 0 | Reserved | This document |
| 1 | No payload | This document |
| 2 | PTPv2, Ethernet encapsulation | This document |
| 3 | PTPv2, IPv4 encapsulation | This document |
| 4 | PTPv2, IPv6 encapsulation | This document |
| 5 | NTP | This document |
| 6-191 | Unassigned | |
| 192-254 | Reserved for Private Use | This document |
| 255 | Reserved | This document |
+---------+-------------------------------+---------------+
Table 2: RTM TLV Types
表2:RTM TLV类型
IANA has created a sub-registry in the "MPLS RTM TLV Registry" (see Section 7.2) called the "MPLS RTM Sub-TLV Registry". All codepoints in the range 0 through 127 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC5226]. Codepoints in the range 128 through 191 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC5226]. This document defines the following new RTM sub-TLV types:
IANA在“MPLS RTM TLV注册表”（见第7.2节）中创建了一个子注册表，称为“MPLS RTM子TLV注册表”。应根据[RFC5226]中规定的“IETF审查”程序分配该注册表中0到127范围内的所有代码点。应根据[RFC5226]中规定的“先到先得”程序分配该注册表中128到191范围内的代码点。本文件定义了以下新的RTM子TLV类型：
+---------+--------------------------+---------------+
| Value | Description | Reference |
+---------+--------------------------+---------------+
| 0 | Reserved | This document |
| 1 | PTP | This document |
| 2-191 | Unassigned | |
| 192-254 | Reserved for Private Use | This document |
| 255 | Reserved | This document |
+---------+--------------------------+---------------+
+---------+--------------------------+---------------+
| Value | Description | Reference |
+---------+--------------------------+---------------+
| 0 | Reserved | This document |
| 1 | PTP | This document |
| 2-191 | Unassigned | |
| 192-254 | Reserved for Private Use | This document |
| 255 | Reserved | This document |
+---------+--------------------------+---------------+
Table 3: RTM Sub-TLV Type
表3:RTM子TLV类型
IANA has assigned a new type for the RTM Capability sub-TLV in the "OSPFv2 Extended Link TLV Sub-TLVs" registry as follows:
IANA已在“OSPFv2扩展链路TLV子TLV”注册表中为RTM能力子TLV分配了一种新类型，如下所示：
+-------+----------------+---------------+
| Value | Description | Reference |
+-------+----------------+---------------+
| 5 | RTM Capability | This document |
+-------+----------------+---------------+
+-------+----------------+---------------+
| Value | Description | Reference |
+-------+----------------+---------------+
| 5 | RTM Capability | This document |
+-------+----------------+---------------+
Table 4: RTM Capability Sub-TLV
表4：RTM能力子TLV
IANA has assigned a new type for the RTM Capability sub-TLV from the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry as follows:
IANA已从“TLV 22、23、141、222和223的子TLV”注册表中为RTM能力子TLV分配了一种新类型，如下所示：
+------+----------------+----+----+-----+-----+-----+---------------+
| Type | Description | 22 | 23 | 141 | 222 | 223 | Reference |
+------+----------------+----+----+-----+-----+-----+---------------+
| 40 | RTM Capability | y | y | n | y | y | This document |
+------+----------------+----+----+-----+-----+-----+---------------+
+------+----------------+----+----+-----+-----+-----+---------------+
| Type | Description | 22 | 23 | 141 | 222 | 223 | Reference |
+------+----------------+----+----+-----+-----+-----+---------------+
| 40 | RTM Capability | y | y | n | y | y | This document |
+------+----------------+----+----+-----+-----+-----+---------------+
Table 5: IS-IS RTM Capability Sub-TLV Registry Description
表5:IS-IS RTM能力子TLV注册表描述
IANA has assigned a new codepoint for the RTM Capability TLV from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" sub-registry in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry as follows:
IANA已从“边界网关协议-链路状态（BGP-LS）参数”注册表中的“BGP-LS节点描述符、链路描述符、前缀描述符和属性TLV”子注册表为RTM能力TLV分配了一个新的代码点，如下所示：
+---------------+----------------+------------------+---------------+
| TLV Code | Description | IS-IS TLV/Sub- | Reference |
| Point | | TLV | |
+---------------+----------------+------------------+---------------+
| 1105 | RTM Capability | 22/40 | This document |
+---------------+----------------+------------------+---------------+
+---------------+----------------+------------------+---------------+
| TLV Code | Description | IS-IS TLV/Sub- | Reference |
| Point | | TLV | |
+---------------+----------------+------------------+---------------+
| 1105 | RTM Capability | 22/40 | This document |
+---------------+----------------+------------------+---------------+
Table 6: RTM Capability TLV in BGP-LS
表6:BGP-LS中的RTM能力TLV
IANA has assigned a new type for the RTM_SET sub-object from the RSVP-TE "Attributes TLV Space" sub-registry as follows:
IANA已从RSVP-TE“Attributes TLV Space”子注册表为RTM_集子对象分配了一个新类型，如下所示：
+------+------------+-----------+---------------+-----------+----------+
| Type | Name | Allowed | Allowed on | Allowed | Reference|
| | | on LSP_ | LSP_REQUIRED_ | on LSP | |
| | | ATTRIBUTES| ATTRIBUTES | Hop | |
| | | | | Attributes| |
+------+------------+-----------+---------------+-----------+----------+
| 5 | RTM_SET | Yes | No | No | This |
| | sub-object | | | | document |
+------+------------+-----------+---------------+-----------+----------+
+------+------------+-----------+---------------+-----------+----------+
| Type | Name | Allowed | Allowed on | Allowed | Reference|
| | | on LSP_ | LSP_REQUIRED_ | on LSP | |
| | | ATTRIBUTES| ATTRIBUTES | Hop | |
| | | | | Attributes| |
+------+------------+-----------+---------------+-----------+----------+
| 5 | RTM_SET | Yes | No | No | This |
| | sub-object | | | | document |
+------+------------+-----------+---------------+-----------+----------+
Table 7: RTM_SET Sub-object Type
表7:RTM_集子对象类型
IANA has created a new sub-registry for sub-TLV types of the RTM_SET sub-object called the "RTM_SET Object Sub-Object Types" registry. All codepoints in the range 0 through 127 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC5226]. Codepoints in the range 128 through 191 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC5226]. This document defines the following new values of RTM_SET object sub-object types:
IANA为RTM_集子对象的子TLV类型创建了一个新的子注册表，称为“RTM_集对象子对象类型”注册表。应根据[RFC5226]中规定的“IETF审查”程序分配该注册表中0到127范围内的所有代码点。应根据[RFC5226]中规定的“先到先得”程序分配该注册表中128到191范围内的代码点。本文档定义了RTM_集对象子对象类型的以下新值：
+---------+--------------------------+---------------+
| Value | Description | Reference |
+---------+--------------------------+---------------+
| 0 | Reserved | This document |
| 1 | IPv4 address | This document |
| 2 | IPv6 address | This document |
| 3 | Unnumbered interface | This document |
| 4-191 | Unassigned | |
| 192-254 | Reserved for Private Use | This document |
| 255 | Reserved | This document |
+---------+--------------------------+---------------+
+---------+--------------------------+---------------+
| Value | Description | Reference |
+---------+--------------------------+---------------+
| 0 | Reserved | This document |
| 1 | IPv4 address | This document |
| 2 | IPv6 address | This document |
| 3 | Unnumbered interface | This document |
| 4-191 | Unassigned | |
| 192-254 | Reserved for Private Use | This document |
| 255 | Reserved | This document |
+---------+--------------------------+---------------+
Table 8: RTM_SET Object Sub-object Types
表8:RTM_集对象子对象类型
IANA has assigned a new flag in the RSVP-TE "Attribute Flags" registry.
IANA已在RSVP-TE“属性标志”注册表中分配了一个新标志。
+-----+---------+-----------+-----------+-----+-----+---------------+
| Bit | Name | Attribute | Attribute | RRO | ERO | Reference |
| No | | Flags | Flags | | | |
| | | Path | Resv | | | |
+-----+---------+-----------+-----------+-----+-----+---------------+
| 15 | RTM_SET | Yes | Yes | No | No | This document |
+-----+---------+-----------+-----------+-----+-----+---------------+
+-----+---------+-----------+-----------+-----+-----+---------------+
| Bit | Name | Attribute | Attribute | RRO | ERO | Reference |
| No | | Flags | Flags | | | |
| | | Path | Resv | | | |
+-----+---------+-----------+-----------+-----+-----+---------------+
| 15 | RTM_SET | Yes | Yes | No | No | This document |
+-----+---------+-----------+-----------+-----+-----+---------------+
Table 9: RTM_SET Attribute Flag
表9:RTM_集属性标志
IANA has assigned the following new error codes in the RSVP "Error Codes and Globally-Defined Error Value Sub-Codes" registry.
IANA在RSVP“错误代码和全局定义的错误值子代码”注册表中分配了以下新错误代码。
+------------+--------------------+---------------+
| Error Code | Meaning | Reference |
+------------+--------------------+---------------+
| 41 | Duplicate TLV | This document |
| 42 | Duplicate sub-TLV | This document |
| 43 | RTM_SET TLV Absent | This document |
+------------+--------------------+---------------+
+------------+--------------------+---------------+
| Error Code | Meaning | Reference |
+------------+--------------------+---------------+
| 41 | Duplicate TLV | This document |
| 42 | Duplicate sub-TLV | This document |
| 43 | RTM_SET TLV Absent | This document |
+------------+--------------------+---------------+
Table 10: New Error Codes
表10：新的错误代码
Routers that support RTM are subject to the same security considerations as defined in [RFC4385] and [RFC5085].
支持RTM的路由器遵循[RFC4385]和[RFC5085]中定义的相同安全注意事项。
In addition -- particularly as applied to use related to PTP -- there is a presumed trust model that depends on the existence of a trusted relationship of at least all PTP-aware nodes on the path traversed by PTP messages. This is necessary as these nodes are expected to correctly modify specific content of the data in PTP messages, and proper operation of the protocol depends on this ability. In practice, this means that those portions of messages cannot be covered by either confidentiality or integrity protection. Though there are methods that make it possible in theory to provide either or both such protections and still allow for intermediate nodes to make detectable but authenticated modifications, such methods do not seem practical at present, particularly for timing protocols that are sensitive to latency and/or jitter.
此外——特别是应用于与PTP相关的使用——存在一个假定的信任模型，该模型取决于PTP消息所穿越路径上至少所有感知PTP的节点的信任关系的存在。这是必要的，因为这些节点需要正确修改PTP消息中数据的特定内容，协议的正确操作取决于这种能力。在实践中，这意味着消息的这些部分不能被机密性或完整性保护覆盖。尽管有一些方法在理论上可以提供这两种保护中的一种或两种，并且仍然允许中间节点进行可检测但经过认证的修改，但这些方法目前似乎并不实用，特别是对于对延迟和/或抖动敏感的定时协议。
The ability to potentially authenticate and/or encrypt RTM and PTP data for scenarios both with and without participation of intermediate RTM-/PTP-capable nodes is left for further study.
对于有或没有中间RTM-/PTP能力节点参与的场景，潜在验证和/或加密RTM和PTP数据的能力有待进一步研究。
While it is possible for a supposed compromised node to intercept and modify the G-ACh content, this is an issue that exists for nodes in general -- for any and all data that may be carried over an LSP -- and is therefore the basis for an additional presumed trust model associated with existing LSPs and nodes.
虽然假定的受损节点有可能截获和修改G-ACh内容，但这是节点普遍存在的问题——对于可能通过LSP传输的任何和所有数据而言——因此是与现有LSP和节点关联的附加假定信任模型的基础。
Security requirements of time protocols are provided in RFC 7384 [RFC7384].
RFC 7384[RFC7384]中提供了时间协议的安全要求。
[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>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, <http://www.rfc-editor.org/info/rfc3477>.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，DOI 10.17487/RFC3477，2003年1月<http://www.rfc-editor.org/info/rfc3477>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 4385，DOI 10.17487/RFC4385，2006年2月<http://www.rfc-editor.org/info/rfc4385>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5085]Nadeau，T.，Ed.和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，DOI 10.17487/RFC5085，2007年12月<http://www.rfc-editor.org/info/rfc5085>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayangarps，“使用资源预留协议流量工程（RSVP-TE）对MPLS LSP建立的属性进行编码”，RFC 5420，DOI 10.17487/RFC5420，2009年2月<http://www.rfc-editor.org/info/rfc5420>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <http://www.rfc-editor.org/info/rfc5586>.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 5586，DOI 10.17487/RFC55862009年6月<http://www.rfc-editor.org/info/rfc5586>.
[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>.
[RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, DOI 10.17487/RFC6423, November 2011, <http://www.rfc-editor.org/info/rfc6423>.
[RFC6423]Li，H.，Martini，L.，He，J.，和F.Huang，“在MPLS传输配置文件（MPLS-TP）中使用伪线的通用相关信道标签”，RFC 6423，DOI 10.17487/RFC6423，2011年11月<http://www.rfc-editor.org/info/rfc6423>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <http://www.rfc-editor.org/info/rfc7684>.
[RFC7684]Psenak，P.，Gredler，H.，Shakir，R.，Henderickx，W.，Tantsura，J.，和A.Lindem，“OSPFv2前缀/链接属性广告”，RFC 7684，DOI 10.17487/RFC7684，2015年11月<http://www.rfc-editor.org/info/rfc7684>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>.
[RFC7752]Gredler，H.，Ed.，Medved，J.，Previdi，S.，Farrel，A.，和S.Ray，“使用BGP的链路状态和流量工程（TE）信息的北向分布”，RFC 7752，DOI 10.17487/RFC7752，2016年3月<http://www.rfc-editor.org/info/rfc7752>.
[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>.
[ITU-T.G.8271] ITU-T, "Time and phase synchronization aspects of packet networks", ITU-T Recomendation G.8271/Y.1366, July 2016.
[ITU-T.G.8271]ITU-T，“分组网络的时间和相位同步方面”，ITU-T建议G.8271/Y.1366，2016年7月。
[OSPFV3-EXTENDED-LSA] Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. Baker, "OSPFv3 LSA Extendibility", Work in Progress, draft-ietf-ospf-ospfv3-lsa-extend-14, April 2017.
[OSPFV3-EXTENDED-LSA]Lindem，A.，Roy，A.，Goethals，D.，Vallem，V.，和F.Baker，“OSPFV3-LSA可扩展性”，在建工程，草案-ietf-ospf-OSPFV3-LSA-EXTENDED-142017年4月。
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[RFC4202]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，DOI 10.17487/RFC4202，2005年10月<http://www.rfc-editor.org/info/rfc4202>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.“LDP规范”，RFC 5036，DOI 10.17487/RFC5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <http://www.rfc-editor.org/info/rfc6374>.
[RFC6374]Frost，D.和S.Bryant，“MPLS网络的数据包丢失和延迟测量”，RFC 6374，DOI 10.17487/RFC6374，2011年9月<http://www.rfc-editor.org/info/rfc6374>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <http://www.rfc-editor.org/info/rfc7384>.
[RFC7384]Mizrahi，T.，“分组交换网络中时间协议的安全要求”，RFC 7384，DOI 10.17487/RFC7384，2014年10月<http://www.rfc-editor.org/info/rfc7384>.
[TIMING-OVER-MPLS] Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Montini, "Transporting Timing messages over MPLS Networks", Work in Progress, draft-ietf-tictoc-1588overmpls-07, October 2015.
[TIMING-OVER-MPLS]Davari，S.，Oren，A.，Bhatia，M.，Roberts，P.，和L.Montini，“通过MPLS网络传输定时消息”，正在进行的工作，草案-ietf-tictoc-1588overmpls-072015年10月。
Acknowledgments
致谢
The authors want to thank Loa Andersson, Lou Berger, Acee Lindem, Les Ginsberg, and Uma Chunduri for their thorough reviews, thoughtful comments, and, most of all, patience.
作者要感谢Loa Andersson、Lou Berger、Acee Lindem、Les Ginsberg和Uma Chunduri的透彻评论、深思熟虑的评论，以及最重要的耐心。
Authors' Addresses
作者地址
Greg Mirsky ZTE Corp.
格雷格·米尔斯基中兴通讯公司。
Email: gregimirsky@gmail.com
Email: gregimirsky@gmail.com
Stefano Ruffini Ericsson
斯特凡诺·鲁菲尼·爱立信
Email: stefano.ruffini@ericsson.com
Email: stefano.ruffini@ericsson.com
Eric Gray Ericsson
埃里克·格雷·爱立信
Email: eric.gray@ericsson.com
Email: eric.gray@ericsson.com
John Drake Juniper Networks
约翰·德雷克·杜松网络公司
Email: jdrake@juniper.net
Email: jdrake@juniper.net
Stewart Bryant Huawei
斯图尔特·布莱恩特·华为
Email: stewart.bryant@gmail.com
Email: stewart.bryant@gmail.com
Alexander Vainshtein ECI Telecom
亚历山大·瓦因施泰因ECI电信公司
Email: Alexander.Vainshtein@ecitele.com
Vainshtein.alex@gmail.com
Email: Alexander.Vainshtein@ecitele.com
Vainshtein.alex@gmail.com