[要約] RFC 8169は、MPLSネットワークにおける滞在時間の測定に関する要件を定義しています。このRFCの目的は、MPLSネットワーク内のパケットの滞在時間を正確に測定するための方法を提供することです。
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）用の新しいGeneric Associated Channel（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.
滞留時間は、タイミングおよび同期メッセージの伝播遅延の可変部分です。各メッセージのこの遅延を知ることで、Precision Time Protocolイベントメッセージに含まれる値を適用するときに考慮される遅延のより正確な決定が可能になります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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).
時間同期プロトコル（Network Time Protocolバージョン4（NTPv4）[RFC5905]やPrecision Time Protocolバージョン2（PTPv2）[IEEE.1588]など）は、ネットワークドメイン全体でクロックを同期するために使用できるタイミングメッセージを定義します。これらのタイミングメッセージの1つが入口ノードから出口ノードへのパス上のノードを通過するのに費やす累積時間の測定は、「滞留時間」と呼ばれ、クロック同期の精度を向上させるために使用されます。滞留時間は、入口インターフェイスでの受信時間と、入口ノードから出口ノードへのネットワークパスに沿った各ノードの出口インターフェースからの送信時間との差の合計です。このドキュメントでは、マルチプロトコルラベルスイッチング（MPLS）ネットワークでラベルスイッチドパス（LSP）上の滞留時間を測定するために使用できる新しいGeneric Associated Channel（G-ACh）値と関連する滞留時間測定（RTM）メッセージを定義します。
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
MPLS：マルチプロトコルラベルスイッチング
ACH: Associated Channel Header
ACH：関連付けられたチャネルヘッダー
TTL: Time to Live
TTL：Time to Live
G-ACh: Generic Associated Channel
G-ACh：一般的な関連チャネル
GAL: Generic Associated Channel Label
GAL：一般的な関連チャネルラベル
NTP: Network Time Protocol
NTP：ネットワークタイムプロトコル
ppm: parts per million
ppm：100万分の1
PTP: Precision Time Protocol
PTP：Precision Time Protocol
BC: boundary clock LSP: Label Switched Path
BC：境界クロックLSP：ラベルスイッチドパス
OAM: Operations, Administration, and Maintenance
OAM：運用、管理、およびメンテナンス
RRO: Record Route Object
RRO：ルートオブジェクトの記録
RTM: Residence Time Measurement
RTM：滞留時間測定
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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]では、滞留時間は、[IEEE.1588]で定義され、ワンステップクロックの使用と呼ばれるPTPイベントメッセージのcorrectionFieldまたは関連するフォローアップメッセージに蓄積されます。 （または、Delay_Reqメッセージに関連付けられたDelay_Respメッセージ）。これは、2ステップクロックの使用と呼ばれます（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.
このドキュメントでは、クロック同期プロトコルのパス上サポートの1つのタイプとして使用できるメカニズム、または滞留時間の一方向測定を実行するために使用できるメカニズムを提案しています。提案されたメカニズムは、RTMメッセージのスクラッチパッドフィールドの特定のLSPのパスに沿ってこの拡張をサポートするすべてのノードからの滞留時間を累積します（図1）。次に、この値を出口ノードで使用して、たとえば、RTPメッセージ内で運ばれるPTPイベントパケットのcorrectionFieldを、その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値を更新する動作モードを指します。 2ステップモードとは、この更新が後続のフォローアップメッセージで行われる動作モードを指します。
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:
存在する場合、フォローアップメッセージの処理では、元の（イベント）メッセージと後続の（フォローアップ）メッセージの両方からの修正フィールド値を組み合わせるために、ダウンストリームエンドポイントがフォローアップメッセージの到着を待つ必要があります。同様に、各2ステップノードは、（新しいメッセージを作成するのではなく）フォローアップメッセージを更新するために、関連するフォローアップメッセージがある場合はそれを待つ必要があります。したがって、2ステップモードを使用する最初のノードは2つのことを実行する必要があります。
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
* 後続の2ステップノードに、すでにフォローアップメッセージがあることを知らせます。
* 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. 初期のcorrectionField値として決定された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フィールドは、メッセージがSyncメッセージ、Follow_upメッセージ、Delay_Reqメッセージ、Delay_Respメッセージのいずれであるかを識別します。 10オクテット長のポートIDフィールドには、送信元ポートの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メッセージには、フォローアップメッセージが来るかどうかを示すビットも含まれています。このビットは、2ステップモードの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 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.
PTPとの互換性のために、RTM（PTPパケットに使用される場合）は同様の方法で動作する必要があります。 2ステップRTMノードを通過するSyncイベントメッセージとDelay_Req / Delay_Respイベントメッセージの処理は異なることに注意してください。以下は、2ステップのRTMノードによるPTP同期イベントメッセージの処理の概要です。 2ステップRTMノードによるDelay_Resp / Delay_Req PTPイベントメッセージの処理の詳細については、セクション2.1.1で説明します。要約すると、2ステップのRTM対応の出力インターフェイスは、PTPサブTLV（PTP用であることを示すRTMメッセージの場合）のフラグフィールドのSビットを調べる必要があり、-クリアされている場合（ゼロに設定）-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.
実際には、2ステップモードで動作するRTMノードは、2ステップの透過クロックのように動作します。
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.
1ステップ対応のRTMノードは、1ステップモード（PTPイベントメッセージを含むRTMメッセージのスクラッチパッドフィールドを更新する）または2ステップモード（更新するフォローアップの存在が示されている場合のフォローアップメッセージのスクラッチパッド）。ただし、両方を行うことはできません。
Two main subcases identified for an RTM node operating as a two-step clock are described in the following sub-sections.
次のサブセクションでは、2ステップクロックとして動作するRTMノードで識別される2つの主なサブケースについて説明します。
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）が2ステップクロックであり、ローカルRTM対応ノードも2 Tepクロックで動作している場合、 2番目のPTPパケット（つまり、ダウンストリーム方向のフォローアップメッセージ）を含めるために作成されたRTMパケットに時間が追加されます。このRTMパケットは、関連する累積滞留時間、シーケンスIDおよびポートIDの適切な値（元のパケットで伝送される同じ識別子）、および1に設定された2段階フラグを伝送します。
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.
2ステップモードで動作しているアップストリームRTM対応ノードがフォローアップメッセージを作成したという事実は、RTM対応ノードである限り、後続のRTM対応ノードも2ステップモードで動作する必要がないことに注意してください。対応する以前のメッセージを転送するのと同じ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.
1ステップ対応のRTMノードは、RTMフォローアップメッセージを、2ステップモードで動作しているかのように更新することを選択できます。ただし、両方のメッセージを更新してはなりません。
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.
PTP同期パケットは、RTMノードにRTMを実行する必要があることを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パケットのcorrectionFieldを更新することに加えて、PTPパケットの2ステップフラグにも適切に反応する必要があります。
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ネットワークが1ステップクロックモードで動作し、RTMノードが2ステップモードで動作する場合、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カプセル化を削除し、2ステップクロックモードが示されている場合は、PTPメッセージを生成して、必要に応じてフォローアップ修正を含めます（[IEEE.1588]に従って）。この場合、同期メッセージを運ぶPTPパケットの共通ヘッダーは、現在のメッセージに関連付けられたフォローアップメッセージが存在することを示すtwoStepFlagフィールドを設定することによって変更する必要があります。
[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) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 最初の4つのオクテットは、[RFC5586]でG-AChヘッダーとして定義されています。
o The Version field is set to 0, as defined in [RFC4385].
o [RFC4385]で定義されているように、Versionフィールドは0に設定されています。
o The Reserved field MUST be set to 0 on transmit and ignored on receipt.
o Reservedフィールドは、送信時に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倍された滞留時間の値を示します。タイミング手順が1ステップ操作か2ステップ操作かによって（セクション2.1）、滞留時間は、このRTMメッセージのValueフィールドで運ばれるタイミングパケットか、または別の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は「Generic Associated Channel（G-ACh）Parameters」レジストリに「MPLS RTM TLV Registry」と呼ばれるサブレジストリを作成しました（セクション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 Valueフィールドの長さがゼロであっても、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の場合、伝送されるタイミングパケットに先行するRTMメッセージのValueフィールドに含める必要があるPTPサブ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |PTPType|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Sequence ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PTP Sub-TLV Format
図2：PTPサブTLV形式
where the Flags field has the following format:
Flagsフィールドの形式は次のとおりです。
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 Typeフィールドは、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フィールドは現在、現在のメッセージが2ステップノードによって処理されたかどうかを定義する1ビット、Sビットを定義します。メッセージが1ステップノードによって排他的に処理され、フォローがない場合、フラグはクリアされます。 -upメッセージ。少なくとも1つの2ステップノードがあり、フォローアップメッセージが近づいている場合に設定されます。
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 PTPTypeフィールドは、このPTPサブTLVが適用されるPTPパケットのタイプを示します。 PTPTypeは、[IEEE.1588]の表19で定義された可能な値を持つPTPv2パケットのmessageTypeフィールドです。
o The 10-octet-long Port ID field contains the identity of the source port.
o 10オクテット長のポートIDフィールドには、送信元ポートの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.
PTPType、ポートID、およびシーケンスIDのタプルは、RTMメッセージに含まれるPTPタイミングメッセージを一意に識別し、2ステップ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時間同期プロトコルのパケットを運ぶことができます（MAY）。滞留時間がスクラッチパッドフィールドに累積されている間、タイミングメッセージパケットが認証または暗号化され、この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は、RTPメッセージの値フィールドのPTPサブTLVの後に（おそらく認証/暗号化された）PTPメッセージパケットを含める前に、PTPサブTLV（セクション3.1を参照）の識別タプル情報を入力します。 PTPタイプ（タイプ1、セクション7.3を参照）の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パケットを1つの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.
インターフェイスのペアでサポートされるモード（1ステップまたは2ステップ）は、出力インターフェイスの機能によって決まります。両方のモードで、出力インターフェースの実装は、同じパケットの正確な出発時間を決定し、これと、対応する入力インターフェースからの到着時間情報を決定できなければなりません。差はパケットの滞留時間を表します。
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をサポートする必要がありますが、インターフェイスペアに関してノードが1ステップ対応か2ステップ対応かを決定するのは出力インターフェイスです。
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.
ノードがITMを使用してRTM機能アドバタイズをサポートする場合、IGPサブTLVは、アドバタイズされたインターフェイスに関連付けられたRTM機能（1ステップまたは2ステップ）を反映する必要があります。 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機能をアドバタイズするときに適用する必要があります（SHOULD）。
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をサポートするノードは、2ステップモードで動作できなければならず（MUST）、1ステップRTMモードもサポートできます（MAY）。 1ステップおよび2ステップのRTMモードの詳細については、セクション2.1で説明します。
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 ...
+-+-+-+-+-+-+-+-+-+- ...
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 タイプ値（5）は、IANAによって「OSPFv2拡張リンクTLVサブTLV」レジストリで割り当てられています（セクション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 値には可変数のビットマップフィールドが含まれているため、フィールド内のビットの総数はLength * 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から定義/送信されます。将来的に定義される可能性のある追加のビットマップフィールド定義は、送信する必要のあるビット数を最小限にするために昇順で割り当てる必要があります（SHOULD）。
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-2ステップ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をサポートする機能は、[RFC7684]のセクション3で説明されているように、RTM機能サブTLVを介してOSPFv2拡張リンク不透明LSAでアドバタイズされます。
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と同じ形式を使用する必要があります（SHOULD）。 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 22、23、222、および223）で中間システム（IS）到達可能性をアドバタイズするTLVに含まれる可能性がある新しいサブTLVでアドバタイズされます。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
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 タイプ値（40）は、IS-ISの「TLV 22、23、141、222、および223のサブTLV」レジストリでIANAによって割り当てられています（セクション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（機能）は、セクション4.3.1で定義された値を持つ3ビット長のビットマップフィールドです。
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).
タイプ値（1105）は、「BGP-LSノード記述子、リンク記述子、プレフィックス記述子、および属性TLV」サブレジストリでIANAによって割り当てられています（セクション7.6を参照）。
Definitions, rules of handling, and values for fields Length, Value, and RTM are as defined in Section 4.3.1.
フィールドの長さ、値、およびRTMの定義、処理のルール、および値は、セクション4.3.1で定義されています。
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:
このドキュメントでは、少なくとも1つのインターフェイスがRTM対応である場合、ノードをRTM対応ノードと呼びます。図6は、RTM機能に関してノードが持つ役割の例を示しています。
----- ----- ----- ----- ----- ----- -----
| 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パケットを作成し、それぞれのフィールドで暗号化されたタイミングパケットをValueフィールドに配置し、RTMを使用してScratch Padフィールドを初期化します。
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メッセージの修正フィールドの更新に使用されます。 LERには、発信PTPパケットを作成する前の独自の滞留時間も含める必要があります。このプロセスの詳細は、ノードF自体が1ステップまたは2ステップのクロックとして動作しているかどうかによって異なります。
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をインスタンス化するために使用するPathメッセージでは、セクション7.8で説明されているように、RTM_SET属性フラグセットを使用してLSP_ATTRIBUTESオブジェクト[RFC5420]を配置します。これは、RTMが要求されていることを出力ノードに示します。このLSP。 RTM_SET属性フラグを認識しないノードはRTM_SET属性フラグを認識しないため、RTM_SET属性フラグは、すべてのノードがRTM属性を認識することがわかっている（ただし、必ずしも実装する必要はない）場合を除き、LSP_REQUIRED_ATTRIBUTESオブジェクト[RFC5420]で設定する必要があります（SHOULD NOT）。パスメッセージ。
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_ATTRIBUTESオブジェクトのRTM_SET属性フラグを含むパスメッセージを受信する場合、出力ノードは、RTM_SET属性フラグが設定され、RTM_SET TLV（セクション4.4.1）が設定されている初期化されたRRO [RFC3209]およびLSP_ATTRIBUTESオブジェクトを含める必要があります。初期化されました。入力ノードが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.
IGPのすべてのインターフェイスがRTMをサポートする環境で、[RFC3209]を使用してインスタンス化されたLSPにRTMを使用することもできます。この場合、RTM_SET TLVおよびLSP_ATTRIBUTESオブジェクトは省略される場合があります。
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対応インターフェイスは、RTM_SET TLVを介して記録できます。 RTM_SETサブオブジェクト形式は、図7に示す一般的な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 |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: RTM_SET TLV Format
図7：RTM_SET TLVフォーマット
Type value (5) has been assigned by IANA in the RSVP-TE "Attributes TLV Space" sub-registry (see Section 7.7).
タイプ値（5）は、IANAによってRSVP-TE "Attributes TLV Space"サブレジストリで割り当てられています（セクション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_SET TLVの内容は、一連の可変長サブTLVです。特定のLSP_ATTRIBUTESオブジェクトに存在できるRTM_SETは1つだけです。サブTLVはセクション4.4.1.1で定義されています。
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_SETフラグが設定されている場合、ノードはRTM_SET TLVの存在についてLSP_ATTRIBUTESオブジェクトを検査する必要があります。複数検出された場合、LSPセットアップは、エラーコード "Duplicate TLV"（セクション7.9）および8つの最下位ビットにタイプ値を含むエラー値を含むResvErrメッセージの生成で失敗する必要があります。 RTM_SET TLVが見つからない場合、LSPセットアップはエラーコード "RTM_SET TLV Absent"（セクション7.9）のResvErrメッセージの生成で失敗する必要があります。 1つのRTM_SET TLVが見つかった場合、ノードはRTMと組み合わせてRTM_SETの最初のノードのIDを使用して、到達可能なRTM対応のインターフェースを持つダウンストリームノードへのホップカウントを計算します。ノードがRROで一致するIDを見つけることができない場合、一致が見つかるか、RTM_SET TLVの終わりに到達するまで、RTM_SETで次のノードのIDを使用しようとする必要があります。一致が見つかった場合、計算された値は、LSPの次のRTM対応ノードに到達するための発信ラベルのTTL値としてノードによって使用されます。それ以外の場合、TTL値は255に設定する必要があります。ノードは、上流に転送する前に、関連する発信ResvメッセージのRTM_SET TLVの先頭にあるRROサブオブジェクトで使用したのと同じアドレスのRTM_SETサブTLVを追加する必要があります。上記のように、計算された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 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.
入力ノードは、受信したResvメッセージのLSP_ATTRIBUTESオブジェクトに含まれる各RTM_SET TLVで受信したIビットを検査してもよい（MAY）。 Iビットが1に設定されたRTM_SET TLVの存在は、LSPに沿った一部のRTMノードを滞留時間の計算に含めることができなかったことを示しています。入力ノードは、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_SETサブオブジェクトの内容は、一連の可変長サブ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_SET 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_SET TLVは、RTM対応のLSP上の出力インターフェイスを表すRROサブTLVのサブセットを含めることを目的としています。ノードがRROサブTLVで使用する出力インターフェイスを選択した後、その同じ出力インターフェイスは、RTM対応の場合、IPv4サブTLV、IPv6サブTLV、または番号なしのいずれかを使用してRTM_SET TLVに配置する必要があります（SHOULD）。インターフェイスサブTLV。選択されたアドレスファミリは、RESVメッセージのアドレスファミリおよびRROで使用されるアドレスファミリと一致する必要があります。アンナンバードインターフェイスサブTLVは、出力インターフェイスにIPアドレスが割り当てられていない場合に使用されます。ノードは、そのノードの制御下にあるLSPが通過するRTM対応の出力インターフェイスの数よりも多くのサブTLVをRTM_SET TLVに配置してはなりません（MUST NOT）。指定された値フィールドを持つ単一のRTM_SETサブTLVのみがRTM_SET TLVに存在する必要があります。同じ値（たとえば、重複したアドレス）を持つ複数のサブTLVが見つかった場合、LSPセットアップは、エラーコード "Duplicate sub-TLV"（セクション7.9）およびエラーを含むResvErrメッセージの生成で失敗する必要があります。 （TLVのタイプ、サブTLVのタイプ）で構成される16ビット値を含む値。
Three kinds of sub-TLVs for RTM_SET are currently defined.
RTM_SETの3種類のサブ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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対応ノードは、これら2つの時間の違いを決定します。ワンステップオペレーションの場合、この差はパケットを送信する直前または送信中に決定され、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.
2ステップ操作の場合、（入力インターフェイスでの）パケット到着時間と（出力インターフェイスからの）後続の出発時間との差は、後続のフォローアップメッセージを送信する前に後で決定されるため、この値はフォローアップメッセージのcorrectionFieldを更新するために使用されます。
See Section 2.1 for further details on the difference between one-step and two-step operation.
1ステップ操作と2ステップ操作の違いの詳細については、セクション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対応ノードは、フォローアップメッセージがない場合、スクラッチパッドフィールドの値を使用して時刻を修正できます（MAY）。たとえば、出力ノードはマスタークロックに同期されたPTP境界クロックである場合があり、スクラッチパッドフィールドの値を使用してPTPのcorrectionFieldを更新します。
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イベントパケットのcorrectionFieldを更新してから、通常のPTP処理。
IANA has assigned a new G-ACh as follows:
IANAは次のように新しいG-AChを割り当てました。
+--------+----------------------------+---------------+
| 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は、「MPLS RTM TLVレジストリ」と呼ばれる「Generic Associated Channel（G-ACh）Parameters」レジストリにサブレジストリを作成しました。このレジストリの0〜127の範囲にあるすべてのコードポイントは、[RFC5226]で指定されている「IETFレビュー」手順に従って割り当てられるものとします。このレジストリの128から191の範囲のコードポイントは、[RFC5226]で指定されている「先着順」の手順に従って割り当てられます。このドキュメントでは、次の新しい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 |
+---------+-------------------------------+---------------+
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レジストリ」と呼ばれるサブレジストリを作成しました。このレジストリの0〜127の範囲にあるすべてのコードポイントは、[RFC5226]で指定されている「IETFレビュー」手順に従って割り当てられるものとします。このレジストリの128から191の範囲のコードポイントは、[RFC5226]で指定されている「先着順」の手順に従って割り当てられます。このドキュメントでは、次の新しい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 |
+---------+--------------------------+---------------+
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 |
+-------+----------------+---------------+
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 |
+------+----------------+----+----+-----+-----+-----+---------------+
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は、「Border Gateway Protocol-Link State（BGP-LS）Parameters」レジストリの「BGP-LS Node Descriptor、Link Descriptor、Prefix Descriptor、およびAttribute TLVs」サブレジストリから、RTM機能TLVの新しいコードポイントを割り当てました次のように：
+---------------+----------------+------------------+---------------+
| 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_SETサブオブジェクトに新しいタイプを割り当てました。
+------+------------+-----------+---------------+-----------+----------+
| 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_SETサブオブジェクトタイプ
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_SETオブジェクトサブオブジェクトタイプ」レジストリと呼ばれるRTM_SETサブオブジェクトのサブTLVタイプ用の新しいサブレジストリを作成しました。このレジストリの0から127の範囲のすべてのコードポイントは、[RFC5226]で指定されている「IETFレビュー」手順に従って割り当てられるものとします。このレジストリの128〜191の範囲のコードポイントは、[RFC5226]で指定されている「先着順」の手順に従って割り当てられます。このドキュメントでは、RTM_SETオブジェクトサブオブジェクトタイプの次の新しい値を定義しています。
+---------+--------------------------+---------------+
| 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_SETオブジェクトのサブオブジェクトタイプ
IANA has assigned a new flag in the RSVP-TE "Attribute Flags" registry.
IANAは、RSVP-TE "Attribute Flags"レジストリに新しいフラグを割り当てました。
+-----+---------+-----------+-----------+-----+-----+---------------+
| 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_SET属性フラグ
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 |
+------------+--------------------+---------------+
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 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems」、IEEE Std 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：Extensions for RSVP for LSP Tunnels」、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、「Resource ReSerVation Protocol-Traffic Engineering（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]ブライアント、S。、スワロー、G。、マティーニ、L。、およびD.マクファーソン、「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]ナドー、T。、エド。およびC. Pignataro、編、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：A Control Channel for Pseudowires」、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. Ayyangarps、「Resource Reservation Protocol Traffic Engineering（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。、and S. Bryant、Ed。、 "MPLS Generic Associated Channel"、RFC 5586、DOI 10.17487 / RFC5586、June 2009、<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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年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 Prefix / Link Attribute Advertisement」、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.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、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 Recomendation 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 Extendibility」、Work in Progress、draft-ietf-ospf-ospfv3- lsa-extend-14、2017年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編、「一般化マルチプロトコルラベルスイッチング（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。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<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、「RFCで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]ミズラヒ、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ネットワークを介したタイミングメッセージの転送」、Work in Progress、draft-ietf-tictoc -1588overmpls-07、2015年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.
グレッグ・ミルスキーZTE Corp.
Email: gregimirsky@gmail.com
Stefano Ruffini Ericsson
ステファノ・ルフィニ・エリクソン
Email: stefano.ruffini@ericsson.com
Eric Gray Ericsson
エリック・グレイ・エリクソン
Email: eric.gray@ericsson.com
John Drake Juniper Networks
ジョンドレイクジュニパーネットワークス
Email: jdrake@juniper.net
Stewart Bryant Huawei
スチュワートブライアントファーウェイ
Email: stewart.bryant@gmail.com
Alexander Vainshtein ECI Telecom
Alexander Vainshtein ECI Telecom
Email: Alexander.Vainshtein@ecitele.com
Vainshtein.alex@gmail.com