Internet Engineering Task Force (IETF) R. Gandhi, Ed.
Request for Comments: 9779 C. Filsfils
Category: Standards Track D. Voyer
ISSN: 2070-1721 Cisco Systems, Inc.
S. Salsano
Universita di Roma "Tor Vergata"
M. Chen
Huawei
May 2025
This document specifies the application of the MPLS loss and delay measurement techniques (originally defined in RFCs 6374, 7876, and 9341) within Segment Routing (SR) networks that utilize the MPLS data plane, also referred to as Segment Routing over MPLS (SR-MPLS). SR enables the forwarding of packets through an ordered list of instructions, known as segments, which are imposed at the ingress node. This document defines the procedures and extensions necessary to perform accurate measurement of packet loss and delay in SR-MPLS environments, ensuring that network operators can effectively measure and maintain the quality of service across their SR-based MPLS networks. This includes coverage of links and end-to-end SR-MPLS paths, as well as SR Policies.
このドキュメントは、MPLSデータプレーンを利用するMPLSデータプレーンを利用するセグメントルーティング（SR）ネットワーク内のMPLS損失および遅延測定技術（元々RFCS 6374、7876、および9341で定義されている）の適用を指定します。SRは、イングレスノードに課されるセグメントとして知られる順序付けられた命令リストを介してパケットを転送できます。このドキュメントでは、SR-MPLS環境でパケット損失と遅延を正確に測定するために必要な手順と拡張機能を定義し、ネットワークオペレーターがSRベースのMPLSネットワーク全体でサービスの品質を効果的に測定および維持できるようにします。これには、リンクとエンドツーエンドのSR-MPLSパス、およびSRポリシーのカバレッジが含まれます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9779.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9779で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions Used in This Document
2.1. Requirements Language
2.2. Abbreviations
2.3. Reference Topology
3. Overview
4. Query and Response Messages
4.1. Query Message for Links and SR-MPLS Policies
4.1.1. Query Message for Links
4.1.2. Query Message for SR-MPLS Policies
4.2. Response Message for Links and SR-MPLS Policies
4.2.1. One-Way Measurement Mode
4.2.2. Two-Way Measurement Mode
4.2.3. Loopback Measurement Mode
5. Delay and Loss Measurement
5.1. Delay Measurement Message
5.2. Loss Measurement Message
5.3. Combined Loss/Delay Measurement Message
5.4. Counters
5.5. Block Number for Counters
6. TLV Extensions
6.1. Return Path TLV Extension
6.1.1. Return Path Sub-TLV Extension
6.2. Block Number TLV Extension
7. ECMP for SR-MPLS Policies
8. Extended TE Link Metrics Advertisement
9. Backwards Compatibility
10. Manageability Considerations
11. Security Considerations
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
Segment Routing (SR), as specified in [RFC8402], leverages the source routing paradigm and applies to both the Multiprotocol Label Switching (MPLS) and Internet Protocol version 6 (IPv6) data planes. These are referred to as Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6), respectively. SR takes advantage of Equal-Cost Multipaths (ECMPs) between source and transit nodes, between transit nodes, and between transit and destination nodes. SR Policies, defined in [RFC9256], are used to steer traffic through specific, user-defined paths using a list of segments.
[RFC8402]で指定されているセグメントルーティング（SR）は、ソースルーティングパラダイムを活用し、マルチプロトコルラベルスイッチング（MPLS）とインターネットプロトコルバージョン6（IPv6）データプレーンの両方に適用されます。これらは、それぞれMPLS（SR-MPLS）およびセグメントルーティングを介したセグメントルーティングと呼ばれます。SRは、ソースとトランジットノードの間、トランジットノード間、および輸送ノードと宛先ノード間の等しいマルチパス（ECMP）を利用します。[RFC9256]で定義されているSRポリシーは、セグメントのリストを使用して特定のユーザー定義のパスを介してトラフィックを操縦するために使用されます。
A comprehensive SR Performance Measurement toolset is one of the essential requirements for measuring network performance to provide Service Level Agreements (SLAs).
包括的なSRパフォーマンス測定ツールセットは、サービスレベル契約（SLA）を提供するためのネットワークパフォーマンスを測定するための重要な要件の1つです。
[RFC6374] specifies protocol mechanisms to enable efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay-variation in MPLS networks.
[RFC6374]は、パケット損失、一方向および双方向の遅延、およびMPLSネットワークの遅延変動などの関連するメトリックの効率的かつ正確な測定を可能にするプロトコルメカニズムを指定します。
[RFC7876] specifies mechanisms for sending and processing out-of-band responses over a UDP return path when receiving query messages defined in [RFC6374]. These mechanisms can be applied to SR-MPLS networks.
[RFC7876]は、[RFC6374]で定義されているクエリメッセージを受信するときに、UDPリターンパス上でバンド外の応答を送信および処理するメカニズムを指定します。これらのメカニズムは、SR-MPLSネットワークに適用できます。
[RFC9341] defines the Alternate-Marking Method using Block Numbers as a data correlation mechanism for packet loss measurement.
[RFC9341]は、ブロック番号を使用してパケット損失測定のデータ相関メカニズムとして使用して、代替マークメソッドを定義します。
This document utilizes the mechanisms from [RFC6374], [RFC7876], and [RFC9341] for delay and loss measurements in SR-MPLS networks. This includes coverage of links and end-to-end SR-MPLS paths, as well as SR Policies.
このドキュメントは、SR-MPLSネットワークの遅延および損失測定に[RFC6374]、[RFC7876]、[RFC9341]のメカニズムを利用しています。これには、リンクとエンドツーエンドのSR-MPLSパス、およびSRポリシーのカバレッジが含まれます。
This document extends [RFC6374] by defining Return Path and Block Number TLVs (see Section 6) for delay and loss measurement in SR-MPLS networks. These TLVs can also be used in MPLS Label Switched Paths (LSPs) [RFC3031]. However, the procedure for delay and loss measurement of MPLS LSPs is outside the scope of this document.
このドキュメントは、SR-MPLSネットワークの遅延および損失測定のために、リターンパスとブロック番号TLV（セクション6を参照）を定義することにより、[RFC6374]を拡張します。これらのTLVは、MPLSラベルスイッチ付きパス（LSP）[RFC3031]でも使用できます。ただし、MPLS LSPの遅延および損失測定の手順は、このドキュメントの範囲外です。
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] で説明されているように解釈されます。
ACH:
ACH:
Associated Channel Header
関連するチャネルヘッダー
DM:
DM:
Delay Measurement
遅延測定
ECMP:
ECMP：
Equal-Cost Multipath
等しいコストマルチパス
G-ACh:
g-ach：
Generic Associated Channel
一般的な関連チャネル
GAL:
GAL:
Generic Associated Channel Label
一般的な関連チャネルラベル
LM:
LM:
Loss Measurement
損失測定
LSE:
LSE:
Label Stack Entry
ラベルスタックエントリ
MPLS:
MPLS：
Multiprotocol Label Switching
マルチプロトコルラベルスイッチング
PSID:
PSID：
Path Segment Identifier
パスセグメント識別子
SID:
SID:
Segment Identifier
セグメント識別子
SL:
SL:
Segment List
セグメントリスト
SR:
SR:
Segment Routing
セグメントルーティング
SR-MPLS:
sr-mpls：
Segment Routing over MPLS
MPLS上のセグメントルーティング
TC:
TC:
Traffic Class
トラフィッククラス
TE:
TE:
Traffic Engineering
交通工学
TTL:
TTL:
Time to Live
生きる時間
URO:
URO:
UDP Return Object
UDP返品オブジェクト
In the reference topology shown in Figure 1, the querier node Q1 initiates a query message, and the responder node R1 transmits a response message for the query message received. The response message may be sent back to the querier node Q1 on the same path (the same set of links and nodes) or on a different path in the reverse direction from the path taken towards the responder R1.
図1に示す参照トポロジでは、QuerierノードQ1がクエリメッセージを開始し、ResponderノードR1は受信したクエリメッセージの応答メッセージを送信します。応答メッセージは、同じパス（同じリンクとノードのセット）で、QuerierノードQ1に送り返されるか、Responder R1に向かって取られたパスから逆方向の別のパスで送信できます。
T1 is a transmit timestamp, and T4 is a receive timestamp; both are added by node Q1. T2 is a receive timestamp, and T3 is a transmit timestamp; both are added by node R1.
T1は送信タイムスタンプで、T4は受信タイムスタンプです。両方ともノードQ1によって追加されます。T2は受信タイムスタンプで、T3は送信タイムスタンプです。両方ともノードR1によって追加されます。
SR is enabled with the MPLS data plane on nodes Q1 and R1. The nodes Q1 and R1 are connected via a channel (Section 2.9.1 of [RFC6374]). The channel may be a directly connected link enabled with MPLS (Section 2.9.1 of [RFC6374]) or an SR-MPLS path [RFC8402]. The link may be a physical interface, a virtual link, a Link Aggregation Group (LAG) [IEEE802.1AX], or a LAG member link. The SR-MPLS path may be an SR-MPLS Policy [RFC9256] on node Q1 (called the "head-end") with the destination to node R1 (called the "tail-end").
SRは、ノードQ1およびR1のMPLSデータプレーンで有効になります。ノードQ1とR1は、チャネルを介して接続されています（[RFC6374]のセクション2.9.1）。チャネルは、MPLS（[RFC6374]のセクション2.9.1）またはSR-MPLSパス[RFC8402]で有効にされる直接接続リンクである場合があります。リンクは、物理インターフェイス、仮想リンク、リンク集約グループ（LAG）[IEEE802.1AX]、またはLAGメンバーリンクです。SR-MPLSパスは、ノードQ1（「ヘッドエンド」と呼ばれる）のSR-MPLSポリシー[RFC9256]である可能性があります。
T1 T2
/ \
+-------+ Query +-------+
| | - - - - - - - - - ->| |
| Q1 |=====================| R1 |
| |<- - - - - - - - - - | |
+-------+ Response +-------+
\ /
T4 T3
Querier Responder
Figure 1: Reference Topology
図1：参照トポロジ
In this document, the procedures defined in [RFC6374], [RFC7876], and [RFC9341] are utilized for delay and loss measurement in SR-MPLS networks. Specifically, the one-way, two-way, and round-trip delay measurements described in Section 2.4 of [RFC6374] are further elaborated for application within SR-MPLS networks. Similarly, the packet loss measurement procedures outlined in Section 2.2 of [RFC6374] are extended for use in SR-MPLS networks.
このドキュメントでは、[RFC6374]、[RFC7876]、および[RFC9341]で定義されている手順は、SR-MPLSネットワークの遅延および損失測定のために利用されます。具体的には、[RFC6374]のセクション2.4で説明されている一元配置、双方向、および往復遅延測定値は、SR-MPLSネットワーク内の適用のためにさらに詳述されています。同様に、[RFC6374]のセクション2.2で概説されているパケット損失測定手順は、SR-MPLSネットワークで使用するために拡張されています。
Packet loss measurement using the Alternate-Marking Method defined in [RFC9341] may employ the Block Number for data correlation. This is achieved by utilizing the Block Number TLV extension defined in this document.
[RFC9341]で定義された代替マーク法を使用したパケット損失測定は、データ相関のためにブロック数を使用する場合があります。これは、このドキュメントで定義されているブロック番号TLV拡張機能を利用することによって達成されます。
In SR-MPLS networks, the query messages defined in [RFC6374] MUST be transmitted along the same path as the data traffic for links and end-to-end SR-MPLS paths. This is to collect both transmit and receive timestamps for delay measurement and to collect both transmit and receive traffic counters for loss measurement.
SR-MPLSネットワークでは、[RFC6374]で定義されているクエリメッセージを、リンクのデータトラフィックとエンドツーエンドSR-MPLSパスと同じパスに沿って送信する必要があります。これは、遅延測定のために送信および受信の両方のタイムスタンプを収集し、測定の両方を収集し、トラフィックカウンターの両方を収集して損失測定の両方を収集することです。
If it is desired in SR-MPLS networks that the same path (i.e., the same set of links and nodes) between the querier and responder be used in both directions of the measurement, then this can be achieved by using the Return Path TLV extension defined in this document.
SR-MPLSネットワークで、クエリエとレスポンダーの間の同じパス（つまり、同じリンクとノードのセット）を測定の両方向に使用することが望まれる場合、これはこのドキュメントで定義されたリターンパスTLV拡張機能を使用して実現できます。
The performance measurement procedures for links can be used to compute extended Traffic Engineering (TE) metrics for delay and loss, as described herein. These metrics are advertised in the network using the routing protocol extensions defined in [RFC7471], [RFC8570], and [RFC8571].
リンクのパフォーマンス測定手順を使用して、本明細書に記載されているように、遅延と損失のための拡張トラフィックエンジニアリング（TE）メトリックを計算できます。これらのメトリックは、[RFC7471]、[RFC8570]、および[RFC8571]で定義されたルーティングプロトコル拡張を使用してネットワークで宣伝されています。
The query message, as defined in [RFC6374], is sent over the links for both delay and loss measurement. In each Label Stack Entry (LSE) [RFC3032] in the MPLS label stack, the TTL value MUST be set to 255 [RFC5082].
[RFC6374]で定義されているクエリメッセージは、遅延測定と損失測定の両方のリンクを介して送信されます。MPLSラベルスタックの各ラベルスタックエントリ（LSE）[RFC3032]で、TTL値は255 [RFC5082]に設定する必要があります。
An SR-MPLS Policy Candidate-Path may contain a number of Segment Lists (SLs) (i.e., a stack of MPLS labels) [RFC9256]. For delay and/ or loss measurement for an end-to-end SR-MPLS Policy, the query messages MUST be transmitted for every SL of the SR-MPLS Policy Candidate-Path. This is done by creating a separate session for each SL. Each query message of a session contains an SR-MPLS label stack of the Candidate-Path, with the G-ACh Label (GAL) at the bottom of the stack (with S=1) as shown in Figure 2. In each LSE in the MPLS label stack, the TTL value MUST be set to 255 [RFC5082].
SR-MPLSポリシー候補パスには、多くのセグメントリスト（SLS）（つまり、MPLSラベルのスタック）[RFC9256]が含まれている場合があります。エンドツーエンドのSR-MPLSポリシーの遅延および/または損失測定のために、SR-MPLSポリシー候補者のすべてのSLに対してクエリメッセージを送信する必要があります。これは、各SLに対して個別のセッションを作成することによって行われます。セッションの各クエリメッセージには、候補者パスのSR-MPLSラベルスタックが含まれており、図2に示すように、g-achラベル（gal）がスタックの下部（s = 1）にあります。MPLSラベルスタックの各LSEで、TTL値は255 [RFC5082]に設定する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (value 13) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example Query Message Header for an End-to-End SR-MPLS Policy
図2：エンドツーエンドのSR-MPLSポリシーのクエリメッセージヘッダーの例
The fields 0001, Version, Reserved, and Channel Type shown in Figure 2 are specified in [RFC5586].
図2に示すフィールド0001、バージョン、予約、およびチャネルタイプは、[RFC5586]で指定されています。
The SR-MPLS label stack can be empty in the case of a one-hop SR-MPLS Policy with an Implicit NULL label.
SR-MPLSラベルスタックは、暗黙のヌルラベルを備えた1ホップのSR-MPLSポリシーの場合、空にすることができます。
For an SR-MPLS Policy, to ensure that the query message is processed by the intended responder, the Destination Address TLV (Type 129) [RFC6374] containing an address of the responder can be sent in the query messages. The responder that supports this TLV MUST return Control Code 0x1 (Success) [RFC6374] if it is the intended destination for the query. Otherwise, it MUST return Error 0x15: Invalid Destination Node Identifier [RFC6374].
SR-MPLSポリシーの場合、クエリメッセージが意図したレスポンダーによって処理されるようにするために、宛先アドレスTLV（タイプ129）[RFC6374]をレスポンダーのアドレスを含むクエリメッセージに送信できます。このTLVをサポートする応答者は、クエリの意図された宛先である場合、コントロールコード0x1（成功）[RFC6374]を返す必要があります。それ以外の場合、エラー0x15を返す必要があります：無効な宛先ノード識別子[RFC6374]。
In one-way measurement mode, as defined in Section 2.4 of [RFC6374], the querier can set the UDP Return Object (URO) TLV in the query message. This enables the querier to receive the out-of-band response message encapsulated in an IP/UDP header sent to the IP address and UDP port specified in the URO TLV. The URO TLV (Type 131) is defined in [RFC7876] and includes the UDP-Destination-Port and IP address. When the querier sets an IP address and a UDP port in the URO TLV, the response message MUST be sent to that IP address, with that IP address as the destination address and the UDP port as the destination port. In addition, the Control Code in the query message MUST be set to Out-of-band Response Requested [RFC6374].
[RFC6374]のセクション2.4で定義されている一方向測定モードでは、クエリエはクエリメッセージにUDPリターンオブジェクト（URO）TLVを設定できます。これにより、Querierは、URO TLVで指定されているIPアドレスとUDPポートに送信されたIP/UDPヘッダーにカプセル化されたバンド外の応答メッセージを受信できます。URO TLV（タイプ131）は[RFC7876]で定義されており、UDP-Destination-PortおよびIPアドレスが含まれています。QuerierがURO TLVにIPアドレスとUDPポートを設定する場合、そのIPアドレスを宛先アドレスとして、UDPポートを宛先ポートとして、そのIPアドレスをそのIPアドレスに送信する必要があります。さらに、クエリメッセージの制御コードは、要求された帯域外の応答に設定する必要があります[RFC6374]。
In the two-way measurement mode defined in Section 2.4 of [RFC6374], the response messages SHOULD be sent back one of two ways: either they are sent back in-band on the same link, or they are sent back on the same end-to-end SR-MPLS path (i.e., the same set of links and nodes) in the reverse direction to the querier. This is done in order to perform accurate two-way delay measurement.
[RFC6374]のセクション2.4で定義されている双方向測定モードでは、応答メッセージは2つの方法のいずれかを返送する必要があります。同じリンクでインバンドを送り返すか、同じエンドツーエンドのSR-MPLSパス（つまり、同じリンクとノードのセット）に逆方向に送信されます。これは、正確な双方向遅延測定を実行するために行われます。
For links, the response message as defined in [RFC6374] is sent back on the same incoming link where the query message is received. In this case, the Control Code in the query message MUST be set to In-band Response Requested [RFC6374].
リンクの場合、[RFC6374]で定義されている応答メッセージは、クエリメッセージが受信される同じ着信リンクに送信されます。この場合、クエリメッセージの制御コードは、要求されたバンドの応答[RFC6374]に設定する必要があります。
For end-to-end SR-MPLS paths, the responder transmits the response message (see the example as shown in Figure 2) on a specific return SR-MPLS path. In the query message, the querier can request that the responder send the response message back on a given return path using the MPLS Label Stack Sub-TLV in the Return Path TLV defined in this document.
エンドツーエンドのSR-MPLSパスの場合、レスポンダーは特定のRETURN SR-MPLSパスで応答メッセージ（図2に示す例を参照）を送信します。クエリメッセージでは、Querierは、このドキュメントで定義されているリターンパスTLVのMPLSラベルスタックSub-TLVを使用して、特定のリターンパスで応答メッセージを送信するように要求できます。
The loopback measurement mode defined in Section 2.8 of [RFC6374] is used to measure round-trip delay for a bidirectional circular path [RFC6374] in SR-MPLS networks. In this mode for SR-MPLS, the received query messages are not punted out of the fast path in forwarding (i.e., to the slow path or control plane) at the responder. In other words, the responder does not process the payload or generate response messages. The loopback function simply returns the received query message to the querier without responder modifications [RFC6374].
[RFC6374]のセクション2.8で定義されているループバック測定モードは、SR-MPLSネットワークの双方向の円形パス[RFC6374]の往復遅延を測定するために使用されます。SR-MPLSのこのモードでは、受信したクエリメッセージは、レスポンダーの転送（つまり、スローパスまたはコントロールプレーン）の高速パスからパントされません。言い換えれば、レスポンダーはペイロードを処理したり、応答メッセージを生成したりしません。ループバック関数は、レスポンダーの変更なしに受信したクエリメッセージをクエリエに返すだけです[RFC6374]。
The loopback mode is done by generating "queries" with the Response flag set to 1 and adding the Loopback Request object (Type 3) [RFC6374]. In query messages, the label stack, as shown in Figure 3, carries both the forward and reverse path labels in the MPLS header. The GAL is still carried at the bottom of the label stack (with S=1).
ループバックモードは、応答フラグを1に設定して「クエリ」を生成し、ループバック要求オブジェクト（タイプ3）[RFC6374]を追加することにより行われます。クエリメッセージでは、図3に示すように、ラベルスタックには、MPLSヘッダーのフォワードパスラベルとリバースパスラベルの両方が含まれています。GALは、ラベルスタックの下部にまだ運ばれています（S = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Path Label(1)| TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Path Label(n)| TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (value 13) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Example Query Message Header for an End-to-End SR-MPLS Policy in the Loopback Measurement Mode
図3：ループバック測定モードのエンドツーエンドSR-MPLSポリシーのクエリメッセージヘッダーの例
As defined in [RFC6374], MPLS Delay Measurement (DM) query and response messages use the Associated Channel Header (ACH) (with value 0x000C for delay measurement). The value identifies the message type and message payload that follow the ACH, as defined in Section 3.2 of [RFC6374]. For delay measurement, the same ACH value is used for both links and end-to-end SR-MPLS Policies.
[RFC6374]で定義されているように、MPLS遅延測定（DM）クエリと応答メッセージは、関連するチャネルヘッダー（ACH）を使用します（遅延測定には値0x000C）。値は、[RFC6374]のセクション3.2で定義されているように、AChに続くメッセージの種類とメッセージペイロードを識別します。遅延測定のために、リンクとエンドツーエンドのSR-MPLSポリシーの両方で同じACh値が使用されます。
The Loss Measurement (LM) protocol can perform two distinct kinds of loss measurement as described in Section 2.9.8 of [RFC6374].
損失測定（LM）プロトコルは、[RFC6374]のセクション2.9.8で説明されているように、2種類の損失測定を実行できます。
* In the inferred mode, LM will measure the loss of specially generated test messages to infer the approximate data plane loss level. Inferred mode LM provides only approximate loss accounting.
* 推定モードでは、LMは特別に生成されたテストメッセージの損失を測定して、近似データプレーンの損失レベルを推測します。推定モードLMは、おおよその損失会計のみを提供します。
* In the direct mode, LM will directly measure data plane packet loss. Direct mode LM provides perfect loss accounting but may require hardware support.
* ダイレクトモードでは、LMはデータプレーンパケットの損失を直接測定します。ダイレクトモードLMは完全な損失会計を提供しますが、ハードウェアサポートが必要になる場合があります。
As defined in [RFC6374], MPLS LM query and response messages use the ACH (with value 0x000A for direct loss measurement or value 0x000B for inferred loss measurement). This value identifies the message type and message payload that follow the ACH, as defined in Section 3.1 of [RFC6374]. For loss measurement, the same ACH value is used for both links and end-to-end SR-MPLS Policies.
[RFC6374]で定義されているように、MPLS LMクエリと応答メッセージはACHを使用します（直接損失測定では値0x000Aまたは推定された損失測定の値0x000B）。この値は、[RFC6374]のセクション3.1で定義されているように、AChに続くメッセージの種類とメッセージペイロードを識別します。損失測定のために、同じACh値がリンクとエンドツーエンドのSR-MPLSポリシーの両方で使用されます。
As defined in [RFC6374], combined LM/DM query and response messages use the ACH (with value 0x000D for direct loss and delay measurement or value 0x000E for inferred loss and delay measurement). The value identifies the message type and the message payload that follows the ACH, as defined in Section 3.3 of [RFC6374]. For combined loss and delay measurement, the same ACH value is used for both links and end-to-end SR-MPLS Policies.
[RFC6374]で定義されているように、LM/DMクエリと応答メッセージを組み合わせてACAを使用します（直接損失および遅延測定または値0x000Eの値0x000Dを使用して、推定された損失と遅延測定に）。値は、[RFC6374]のセクション3.3で定義されているように、ACHに続くメッセージタイプとメッセージのペイロードを識別します。損失と遅延測定の組み合わせの場合、リンクとエンドツーエンドのSR-MPLSポリシーの両方で同じACH値が使用されます。
The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the received data packet for the traffic flow under measurement, in order to account for received traffic on the egress node of the SR-MPLS Policy. In the direct mode, the PSID in the received query message (as shown in Figure 4) can be used to associate the received traffic counter on the responder to detect the transmit packet loss for the end-to-end SR-MPLS Policy.
SR-MPLSポリシーの出力ノードでの受信トラフィックを考慮するために、パスセグメント識別子（PSID）[RFC9545]は、測定中のトラフィックフローのために受信データパケットに携帯する必要があります。ダイレクトモードでは、受信したクエリメッセージのPSID（図4を参照）を使用して、対応者のトラフィックカウンターを関連付けて、エンドツーエンドのSR-MPLSポリシーの送信パケット損失を検出できます。
In the inferred mode, the PSID in the received query messages (as shown in Figure 4) can be used to count the received query messages on the responder to detect the transmit packet loss for an end-to-end SR-MPLS Policy.
推測されたモードでは、受信したクエリメッセージのPSID（図4を参照）を使用して、レスポンダーの受信クエリメッセージをカウントして、エンドツーエンドのSR-MPLSポリシーの送信パケット損失を検出できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSID | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (value 13) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example with the PSID for SR-MPLS Policy
図4：SR-MPLSポリシーのPSIDの例
The fields 0001, Version, Reserved, and Channel Type shown in Figure 4 are specified in [RFC5586].
図4に示すフィールド0001、バージョン、予約、およびチャネルタイプは、[RFC5586]で指定されています。
Different values of the PSID can be used per Candidate-Path to account for received traffic and to measure packet loss at the Candidate-Path level. Similarly, different values of the PSID can be used per Segment List (SL) of the Candidate-Path for accounting received traffic to measure packet loss at the SL level. The same value of the PSID can be used for all SLs of the SR-MPLS Policy to measure packet loss at the SR-MPLS Policy level.
PSIDのさまざまな値を候補者のパスごとに使用して、受け取ったトラフィックを考慮し、候補者パスレベルでパケット損失を測定することができます。同様に、SLレベルでのパケット損失を測定するために、会計を受け取ったトラフィックのために、候補者パスのPSIDの異なる値を使用できます。SR-MPLSポリシーのすべてのSLSにPSIDの同じ値を使用して、SR-MPLSポリシーレベルでパケット損失を測定できます。
The packet loss measurement using the Alternate-Marking Method defined in [RFC9341] may use the block number for data correlation for the traffic flow under measurement. As defined in Section 3.1 of [RFC9341], the block number is used to divide the traffic flow into consecutive blocks and count the number of packets transmitted and received in each block for loss measurement.
[RFC9341]で定義された代替マークメソッドを使用したパケット損失測定では、測定中のトラフィックフローのデータ相関にブロック番号を使用する場合があります。[RFC9341]のセクション3.1で定義されているように、ブロック番号は、トラフィックフローを連続ブロックに分割し、各ブロックで送信および受信したパケットの数を損失測定のためにカウントするために使用されます。
As described in Section 4.3 of [RFC9341], a protocol-based distributed solution can be used to exchange values of counters on the nodes for loss measurement. That solution is further described in this document using the LM messages defined in [RFC6374].
[RFC9341]のセクション4.3で説明したように、プロトコルベースの分散ソリューションを使用して、損失測定のためにノードのカウンターの値を交換できます。このソリューションは、[RFC6374]で定義されたLMメッセージを使用して、このドキュメントでさらに説明します。
The querier node assigns a block number to the block of data packets of the traffic flow under measurement. The querier counts the number of packets transmitted in each block. The mechanism for the assignment of the block number is a local decision on the querier and is outside the scope of this document.
Querierノードは、測定中のトラフィックフローのデータパケットのブロックにブロック番号を割り当てます。Querierは、各ブロックに送信されるパケットの数をカウントします。ブロック番号の割り当てのメカニズムは、クエリエに関するローカル決定であり、このドキュメントの範囲外です。
As an example, the querier can use the procedure defined in [RFC9714] for alternate marking of the data packets of the traffic flow under measurement. The responder counts the number of received packets in each block based on the marking in the received data packets. The querier and responder maintain separate sets of transmit and receive counters for each marking. The marking can be used as a block number, or a separate block number can be incremented when the marking changes. Other methods can be defined for alternate marking of the data packets of the traffic flow under measurement to assign a block number for the counters.
例として、Querierは[RFC9714]で定義された手順を使用して、測定中のトラフィックフローのデータパケットの代替マーキングを使用できます。レスポンダーは、受信したデータパケットのマーキングに基づいて、各ブロック内の受信パケットの数をカウントします。クエリエとレスポンダーは、各マーキングの個別の送信セットと受信カウンターを維持します。マーキングはブロック番号として使用できます。または、マーキングが変更されたときに別のブロック番号をインクリメントすることができます。他のメソッドは、測定下のトラフィックフローのデータパケットの代替マーキングに定義して、カウンターのブロック番号を割り当てることができます。
The LM query and response messages defined in [RFC6374] are used to measure packet loss for the block of data packets transmitted with the previous marking, whereas data packets carry alternate marking. Specifically, LM query and response messages carry the transmit and receive counters (which are currently not incrementing) along with their block number to correlate for loss measurement.
[RFC6374]で定義されているLMクエリと応答メッセージは、以前のマーキングで送信されたデータパケットのブロックのパケット損失を測定するために使用されますが、データパケットは代替マーキングを持ちます。具体的には、LMクエリと応答のメッセージには、送信カウンター（現在は増分していない）とともにブロック番号を受信し、損失測定と相関します。
Section 4.3 of [RFC9341] specifies that: "The assumption of this BN mechanism is that the measurement nodes are time synchronized." However, this is not necessary, as the block number on the responder can be synchronized based on the received LM query messages.
[RFC9341]のセクション4.3は、「このBNメカニズムの仮定は、測定ノードが時間同期されることです」と指定しています。ただし、レスポンダーのブロック番号は受信したLMクエリメッセージに基づいて同期できるため、これは必要ありません。
In the two-way measurement mode, the responder may transmit the response message on a specific return path, for example, in an ECMP environment. The querier can request in the query message for the responder to send a response message back on a given return path (e.g., a co-routed bidirectional path). This allows the responder to avoid creating and maintaining additional states (containing return paths) for the sessions.
双方向測定モードでは、応答者は、たとえばECMP環境など、特定のリターンパスで応答メッセージを送信する場合があります。Querierは、応答者にクエリメッセージで、特定のリターンパス（例えば、共同双方向パス）に応答メッセージを送信するように要求できます。これにより、レスポンダーはセッションの追加状態（リターンパスを含む）の作成と維持を避けることができます。
The querier may not be directly reachable from the responder in a network. In this case, the querier MUST send its reachability path information to the responder using the Return Path TLV.
クエリエは、ネットワーク内のレスポンダーから直接到達できない場合があります。この場合、QuerierはReturn Path TLVを使用してResponderに到達可能性パス情報を送信する必要があります。
[RFC6374] defines query and response messages that can include one or more optional TLVs. This document defines the Return Path TLV (5) to carry return path information in query messages. The Return Path TLV is specific to a measurement session. The format of the Return Path TLV is shown in Figure 5 below:
[RFC6374]は、1つ以上のオプションのTLVを含むクエリおよび応答メッセージを定義します。このドキュメントでは、クエリメッセージに戻りパス情報を伝達するリターンパスTLV（5）を定義します。リターンパスTLVは、測定セッションに固有です。リターンパスTLVの形式を以下の図5に示します。
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 = 5 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path Sub-TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Return Path TLV
図5：パスTLVを返します
The Length is a one-byte field and is equal to the length of the Return Path Sub-TLV and the Reserved field in bytes. The Length MUST NOT be 0 or 1.
長さは1バイトのフィールドであり、リターンパスSub-TLVの長さとバイトの予約フィールドに等しくなります。長さは0または1であってはなりません。
The Return Path TLV is defined in the "Mandatory TLV Type" registry space [RFC6374]. The querier MUST only insert one Return Path TLV in the query message. The responder that supports this TLV MUST only process the first Return Path TLV and ignore the other Return Path TLVs if present. The responder that supports this TLV also MUST send the response message back on the return path specified in the Return Path TLV. The responder also MUST NOT add a Return Path TLV in the response message.
リターンパスTLVは、「必須のTLVタイプ」レジストリスペース[RFC6374]で定義されています。Querierは、クエリメッセージに1つの戻りパスTLVのみを挿入する必要があります。このTLVをサポートするレスポンダーは、最初の戻りパスTLVを処理し、存在する場合は他のリターンパスTLVを無視する必要があります。このTLVをサポートするレスポンダーは、リターンパスTLVで指定されたリターンパスで応答メッセージを送信する必要があります。応答者は、応答メッセージにリターンパスTLVを追加してはなりません。
The Reserved field MUST be set to 0 and MUST be ignored on the receive side.
予約済みフィールドは0に設定する必要があり、受信側では無視する必要があります。
The Return Path TLV contains a Sub-TLV to carry the return path. The format of the MPLS Label Stack Sub-TLV is shown in Figure 6. The label entries in the Sub-TLV MUST be in network order. The MPLS Label Stack Sub-TLV in the Return Path TLV is of the following type:
リターンパスTLVには、リターンパスを運ぶサブTLVが含まれています。MPLSラベルスタックSub-TLVの形式を図6に示します。Sub-TLVのラベルエントリは、ネットワーク順にする必要があります。リターンパスTLVのMPLSラベルスタックSub-TLVは、次のタイプです。
* Type (value 1): MPLS Label Stack of the Return Path
* タイプ（値1）：リターンパスのMPLSラベルスタック
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=1 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: MPLS Label Stack Sub-TLV in the Return Path TLV
図6：MPLSラベルスタックSub-TLVリターンパスTLVで
The MPLS label stack contains a list of 32-bit LSEs that includes a 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit End of Stack (S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels or a Binding SID label [RFC8402] of the Return SR-MPLS Policy.
MPLSラベルスタックには、20ビットラベル値、8ビットTTL値、3ビットTC値、およびスタックフィールドの1ビット端を含む32ビットLSEのリストが含まれています。MPLSラベルスタックSub-TLVは、Return SR-MPLSポリシーのラベルのスタックまたはバインディングSIDラベル[RFC8402]を搭載する場合があります。
The Length is a one-byte field and is equal to the length of the label stack field and the Reserved field in bytes. The Length MUST NOT be 0 or 1.
長さは1バイトのフィールドであり、ラベルスタックフィールドの長さとバイトの予約フィールドに等しくなります。長さは0または1であってはなりません。
The Return Path TLV MUST carry only one Return Path Sub-TLV. The MPLS Label Stack in the Return Path Sub-TLV MUST contain at least one MPLS Label. The responder that supports this Sub-TLV MUST only process the first Return Path Sub-TLV and ignore the other Return Path Sub-TLVs if present. The responder that supports this Sub-TLV MUST send the response message back on the return path specified in the Return Path Sub-TLV.
リターンパスTLVは、1つのリターンパスSub-TLVのみを搭載する必要があります。リターンパスSub-TLVのMPLSラベルスタックには、少なくとも1つのMPLSラベルが含まれている必要があります。このサブTLVをサポートするレスポンダーは、最初のリターンパスsub-tlvを処理し、存在する場合は他のリターンパスサブTLVを無視する必要があります。このサブTLVをサポートするレスポンダーは、リターンパスSub-TLVで指定されたリターンパスで応答メッセージを送信する必要があります。
The Reserved field MUST be set to 0 and MUST be ignored on the receive side.
予約済みフィールドは0に設定する必要があり、受信側では無視する必要があります。
[RFC6374] defines query and response messages that can include one or more optional TLVs. This document defines the Block Number TLV (6) to carry (8-bit) Block Number of the traffic counters in the LM query and response messages. The format of the Block Number TLV is shown in Figure 7:
[RFC6374]は、1つ以上のオプションのTLVを含むクエリおよび応答メッセージを定義します。このドキュメントでは、LMクエリと応答メッセージのトラフィックカウンターのブロック番号を携帯するブロック番号TLV（6）を定義します。ブロック番号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=6 | Length | Reserved |R| Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Block Number TLV
図7：ブロック番号TLV
The Length is a one-byte field and is equal to 2 bytes.
長さは1バイトのフィールドで、2バイトに等しくなります。
The Block Number TLV is defined in the "Mandatory TLV Type" registry space [RFC6374]. The querier MUST only insert one Block Number TLV in the query message to identify the Block Number for the traffic counters in the forward direction. The responder that supports this TLV MUST only insert one Block Number TLV in the response message to identify the Block Number for the traffic counters in the reverse direction. The responder also MUST return the first Block Number TLV from the query message and ignore the other Block Number TLVs if present. The Block Number TLV is specific to a measurement session. The R flag is used to indicate the query and response message direction associated with the Block Number. The R flag MUST be clear in the query message for the Block Number associated with Counter 1 and Counter 2, and set in the response message for the Block Number associated with Counter 3 and Counter 4.
ブロック番号TLVは、「必須のTLVタイプ」レジストリスペース[RFC6374]で定義されています。Querierは、クエリメッセージに1つのブロック番号TLVのみを挿入して、フォワード方向のトラフィックカウンターのブロック番号を識別する必要があります。このTLVをサポートする応答者は、応答メッセージに1つのブロック番号TLVのみを挿入して、トラフィックカウンターのブロック番号を逆方向に識別する必要があります。また、応答者はクエリメッセージから最初のブロック番号TLVを返し、存在する場合は他のブロック番号TLVを無視する必要があります。ブロック番号TLVは、測定セッションに固有です。Rフラグは、ブロック番号に関連付けられたクエリおよび応答メッセージの方向を示すために使用されます。Rフラグは、カウンター1とカウンター2に関連付けられたブロック番号のクエリメッセージでクリアであり、カウンター3とカウンター4に関連付けられたブロック番号の応答メッセージに設定する必要があります。
The Reserved field MUST be set to 0 and MUST be ignored on the receive side.
予約済みフィールドは0に設定する必要があり、受信側では無視する必要があります。
The SLs of an SR-MPLS Policy can have ECMPs between the source and transit nodes, between transit nodes, and between transit and destination nodes. Usage of a node-SID [RFC8402] by the SLs of an SR-MPLS Policy can result in ECMP paths. In addition, usage of an Anycast-SID [RFC8402] by the SLs of an SR-MPLS Policy can result in ECMP paths via transit nodes that are part of that anycast group. The query and response messages are sent to traverse different ECMP paths to measure the delay of each ECMP path of an SL.
SR-MPLSポリシーのSLSは、ソースとトランジットノードの間、トランジットノード間、および輸送ノードと宛先ノード間のECMPを持つことができます。SR-MPLSポリシーのSLSによるノードSID [RFC8402]の使用は、ECMPパスにつながる可能性があります。さらに、SR-MPLSポリシーのSLSによるAnycast-SID [RFC8402]の使用は、その一部であるTransitノードを介してECMPパスをもたらす可能性があります。クエリと応答メッセージは、SLの各ECMPパスの遅延を測定するために、異なるECMPパスをトラバースするために送信されます。
The forwarding plane has various hashing functions available to forward packets on specific ECMP paths. For end-to-end SR-MPLS Policy delay measurement, different entropy label values [RFC6790] can be used in query and response messages to take advantage of the hashing function in the forwarding plane to influence the ECMP path taken by them.
転送面には、特定のECMPパス上の転送パケットが利用できるさまざまなハッシュ機能があります。エンドツーエンドのSR-MPLSポリシー遅延測定の場合、異なるエントロピーラベル値[RFC6790]をクエリおよび応答メッセージで使用して、転送面のハッシュ関数を利用して、それらが取ったECMPパスに影響を与えることができます。
The considerations for loss measurement for different ECMP paths of an SR-MPLS Policy are outside the scope of this document.
SR-MPLSポリシーのさまざまなECMPパスの損失測定に関する考慮事項は、このドキュメントの範囲外です。
The extended TE metrics for link delay (namely, average delay, minimum delay, maximum delay, and delay-variance) and packet loss can be computed using the performance measurement procedures described in this document and can be advertised in the routing domain as follows:
リンク遅延のための拡張されたTEメトリック（つまり、平均遅延、最小遅延、最大遅延、および遅延分散）およびパケット損失は、このドキュメントで説明されているパフォーマンス測定手順を使用して計算でき、次のようにルーティングドメインで宣伝できます。
* For OSPF, IS-IS, and the Border Gateway Protocol - Link State (BGP-LS), the protocol extensions defined in [RFC7471], [RFC8570], and [RFC8571], respectively, are used for advertising the extended TE link delay and loss metrics in the network.
* OSPF、IS-IS、および境界ゲートウェイプロトコル - リンク状態（BGP-LS）の場合、それぞれ[RFC7471]、[RFC8570]、および[RFC8571]で定義されているプロトコル拡張機能は、ネットワークの拡張TEリンクの遅延と損失メトリックを宣伝するために使用されます。
* The extended TE link delay and loss metrics are advertised for Layer-2 LAG bundle member links in OSPF [RFC9356] and IS-IS [RFC8668] using the same protocol extensions defined in [RFC7471] and [RFC8570], respectively.
* [RFC7471]および[RFC8570]で定義された同じプロトコル拡張機能を使用して、OSPF [RFC9356]およびIS-IS [RFC8668]のレイヤー2ラグバンドルメンバーリンクおよびIS-IS [RFC8570]の拡張TEリンクの遅延と損失メトリックは、それぞれ宣伝されています。
* The advertised delay-variance metric is computed as Packet Delay Variation (PDV), as described in Section 4.2 of [RFC5481].
* 広告された遅延分析メトリックは、[RFC5481]のセクション4.2で説明されているように、パケット遅延変動（PDV）として計算されます。
The procedures defined in this document are backwards compatible with the procedures defined in [RFC6374] at both the querier and the responder. If the responder does not support the new Mandatory TLV Types defined in this document, it will return Error 0x17: Unsupported Mandatory TLV Object as per [RFC6374].
このドキュメントで定義されている手順は、QuerierとResponderの両方で[RFC6374]で定義されている手順と互換性があります。レスポンダーがこのドキュメントで定義されている新しい必須のTLVタイプをサポートしていない場合、[RFC6374]に従って、エラー0x17：サポートされていない必須TLVオブジェクトを返します。
The manageability considerations described in Section 7 of [RFC6374] and Section 6 of [RFC7876] are applicable to this specification.
[RFC6374]のセクション7および[RFC7876]のセクション6で説明されている管理可能性の考慮事項は、この仕様に適用できます。
The security considerations specified in [RFC6374], [RFC7471], [RFC8570], [RFC8571], [RFC7876], and [RFC9341] also apply to the procedures described in this document.
[RFC6374]、[RFC7471]、[RFC8570]、[RFC8571]、[RFC7876]、および[RFC9341]で指定されたセキュリティ上の考慮事項も、この文書に記載されている手順にも適用されます。
The procedure defined in this document is intended for deployment in a single operator administrative domain. As such, the querier node, the responder node, the forward path, and the return paths are provisioned by the operator for the probe session. It is assumed that the operator has verified the integrity of the forward and return paths of the probe packets.
このドキュメントで定義されている手順は、単一のオペレーター管理ドメインでの展開を目的としています。そのため、クエリエノード、レスポンダーノード、フォワードパス、およびリターンパスは、プローブセッションのオペレーターによってプロビジョニングされます。オペレーターは、プローブパケットのフォワードパスとリターンパスの整合性を確認したと想定されています。
The Return Path TLV extensions defined in this document may be used for potential address spoofing. For example, a query message may carry a return path that has a destination that is not local at the querier. To prevent such possible attacks, the responder may drop the query messages when it cannot determine whether the return path has the destination local at the querier. The querier may send a proper source address in the Source Address TLV. The responder can use this to make that determination, for example, by checking the access control list provisioned by the operator.
このドキュメントで定義されているリターンパスTLV拡張機能は、潜在的なアドレススプーフィングに使用できます。たとえば、クエリメッセージには、クエリエにローカルではない宛先があるリターンパスが搭載される場合があります。このような可能な攻撃を防ぐために、リターンパスにQuerierの宛先がローカルにあるかどうかを判断できない場合、レスポンダーはクエリメッセージをドロップする場合があります。クエリエは、ソースアドレスTLVに適切なソースアドレスを送信する場合があります。レスポンダーは、これを使用して、たとえばオペレーターがプロビジョニングしたアクセス制御リストをチェックすることにより、その決定を行うことができます。
IANA has allocated values for the following Mandatory TLV Types [RFC6374] from the "MPLS Loss/Delay Measurement TLV Object" registry contained within the "Generic Associated Channel (G-ACh) Parameters" registry group:
IANAは、「MPLS損失/遅延測定TLVオブジェクト」レジストリから「汎用関連チャネル（G-CH）パラメーター」レジストリグループに含まれる「MPLS損失/遅延測定TLVオブジェクト」レジストリから次の必須TLVタイプ[RFC6374]に値を割り当てました。
+======+==============+===========+
| Code | Description | Reference |
+======+==============+===========+
| 5 | Return Path | RFC 9779 |
+------+--------------+-----------+
| 6 | Block Number | RFC 9779 |
+------+--------------+-----------+
Table 1: MPLS Loss/Delay Measurement TLV Types
表1：MPLS損失/遅延測定TLVタイプ
The Block Number TLV is carried in the query and response messages, and the Return Path TLV is carried in the query messages.
ブロック番号TLVはクエリおよび応答メッセージに掲載され、リターンパスTLVはクエリメッセージに掲載されます。
IANA has created the "Return Path Sub-TLV Types" registry. All code points are allocated per the registration policies shown in Table 2 (see [RFC8126]).
IANAは「Return Path Sub-TLV型」レジストリを作成しました。すべてのコードポイントは、表2に示す登録ポリシーに従って割り当てられます（[RFC8126]を参照）。
+===========+=========================+===========+
| Value | Description | Reference |
+===========+=========================+===========+
| 1 - 175 | IETF Review | RFC 9779 |
+-----------+-------------------------+-----------+
| 176 - 239 | First Come First Served | RFC 9779 |
+-----------+-------------------------+-----------+
| 240 - 251 | Experimental Use | RFC 9779 |
+-----------+-------------------------+-----------+
| 252 - 254 | Private Use | RFC 9779 |
+-----------+-------------------------+-----------+
Table 2: Return Path Sub-TLV Types Registry
表2：パスサブTLVタイプのレジストリを返します
This document defines the following values in the "Return Path Sub-TLV Types" registry:
このドキュメントでは、「リターンパスサブTLVタイプ」レジストリで次の値を定義します。
+=======+=====================================+===========+
| Value | Description | Reference |
+=======+=====================================+===========+
| 0 | Reserved | RFC 9779 |
+-------+-------------------------------------+-----------+
| 1 | MPLS Label Stack of the Return Path | RFC 9779 |
+-------+-------------------------------------+-----------+
| 255 | Reserved | RFC 9779 |
+-------+-------------------------------------+-----------+
Table 3: Return Path Sub-TLV Types
表3：パスサブTLVタイプを返します
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<https://www.rfc-editor.org/info/rfc6374>.
[RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path
for Packet Loss and Delay Measurement for MPLS Networks",
RFC 7876, DOI 10.17487/RFC7876, July 2016,
<https://www.rfc-editor.org/info/rfc7876>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
March 2009, <https://www.rfc-editor.org/info/rfc5481>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
M., and E. Aries, "Advertising Layer 2 Bundle Member Link
Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
December 2019, <https://www.rfc-editor.org/info/rfc8668>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9356] Talaulikar, K., Ed. and P. Psenak, "Advertising Layer 2
Bundle Member Link Attributes in OSPF", RFC 9356,
DOI 10.17487/RFC9356, January 2023,
<https://www.rfc-editor.org/info/rfc9356>.
[RFC9545] Cheng, W., Ed., Li, H., Li, C., Ed., Gandhi, R., and R.
Zigler, "Path Segment Identifier in MPLS-Based Segment
Routing Networks", RFC 9545, DOI 10.17487/RFC9545,
February 2024, <https://www.rfc-editor.org/info/rfc9545>.
[RFC9714] Cheng, W., Ed., Min, X., Ed., Zhou, T., Dai, J., and Y.
Peleg, "Encapsulation for MPLS Performance Measurement
with the Alternate-Marking Method", RFC 9714,
DOI 10.17487/RFC9714, February 2025,
<https://www.rfc-editor.org/info/rfc9714>.
[IEEE802.1AX]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Link Aggregation", IEEE Std 802.1AX-2020,
DOI 10.1109/IEEESTD.2020.9105034, May 2020,
<https://doi.org/10.1109/IEEESTD.2020.9105034>.
The authors would like to thank Thierry Couture and Ianik Semco for the discussions on the use cases for performance measurement in segment routing networks. The authors would like to thank Patrick Khordoc, Ruby Lin, and Haowei Shi for implementing the mechanisms defined in this document. The authors would like to thank Greg Mirsky and Xiao Min for providing many useful comments and suggestions. The authors would also like to thank Stewart Bryant, Sam Aldrin, Tarek Saad, and Rajiv Asati for their review comments. Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for the MPLS expert review; Zhaohui Zhang for the RTGDIR early review; Tony Li for shepherd's review; Ned Smith for the SECDIR review; Roni Even for the Gen-ART review; Marcus Ihlar for the TSV-ART review; Dhruv Dhody for the OPSDIR review; and Gunter Van de Velde, Paul Wouters, Éric Vyncke, Murray Kucherawy, John Scudder, and Roman Danyliw for the IESG review.
著者は、セグメントルーティングネットワークでのパフォーマンス測定のためのユースケースに関する議論について、Thierry CoutureとIanik Semcoに感謝したいと思います。著者は、この文書で定義されているメカニズムを実装してくれたPatrick Khordoc、Ruby Lin、およびHaowei Shiに感謝します。著者は、多くの有用なコメントや提案を提供してくれたGreg MirskyとXiao Minに感謝したいと思います。著者はまた、スチュワート・ブライアント、サム・アルドリン、タレク・サード、ラジブ・アサティのレビューコメントに感謝したいと思います。MPLS Expert ReviewのHuaimo Chen、Yimin Shen、およびXufeng Liuに感謝します。rtgdir早期レビューのためのZhaohui Zhang。シェパードのレビューのトニー・リー。Secdirレビューのネッドスミス。Gen-ArtのレビューでもRoni。TSV-ARTレビューのMarcus Ihlar。opsdirレビューのdhruv dhody;IESGレビューのために、Gunter Van de Velde、Paul Wouters、エリック・ヴィンケ、マレー・クチェラウィ、ジョン・スカダー、ローマ・ダニリウ。
Sagar Soni
Cisco Systems, Inc.
Email: sagsoni@cisco.com
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Pier Luigi Ventre
CNIT
Italy
Email: pierluigi.ventre@cnit.it
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Email: cfilsfil@cisco.com
Daniel Voyer
Cisco Systems, Inc.
Canada
Email: davoyer@cisco.com
Stefano Salsano
Universita di Roma "Tor Vergata"
Italy
Email: stefano.salsano@uniroma2.it
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com