Internet Engineering Task Force (IETF) S. Hegde
Request for Comments: 9716 Juniper Networks, Inc.
Category: Standards Track K. Arora
ISSN: 2070-1721 Individual Contributor
M. Srivastava
Juniper Networks, Inc.
S. Ninan
Ciena
N. Kumar
Oracle
February 2025
The Segment Routing (SR) architecture leverages source routing and can be directly applied to the use of an MPLS data plane. A Segment Routing over MPLS (SR-MPLS) network may consist of multiple IGP domains or multiple Autonomous Systems (ASes) under the control of the same organization. It is useful to have the Label Switched Path (LSP) ping and traceroute procedures when an SR end-to-end path traverses multiple ASes or IGP domains. This document outlines mechanisms to enable efficient LSP ping and traceroute procedures in inter-AS and inter-domain SR-MPLS networks. This is achieved through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes.
セグメントルーティング（SR）アーキテクチャはソースルーティングを活用し、MPLSデータプレーンの使用に直接適用できます。MPLS（SR-MPLS）ネットワーク上のセグメントルーティングは、同じ組織の制御下にある複数のIGPドメインまたは複数の自律システム（ASE）で構成されている場合があります。SRエンドツーエンドパスが複数のASEまたはIGPドメインを横断する場合、ラベルがスイッチされたパス（LSP）PINGおよびTRACEROUTE手順を使用すると便利です。このドキュメントは、AS間およびドメイン間SR-MPLSネットワークで効率的なLSP Pingおよびトレーサープロシージャを有効にするメカニズムの概要を説明します。これは、トランジットノードのエコー応答の処理のためのデータプレーン転送のみに依存する、運用、管理、およびメンテナンス（OAM）プロトコルへの簡単な拡張を通じて達成されます。
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/rfc9716.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9716で取得できます。
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
1.1. Definition of Domain
1.2. Requirements Language
2. Inter-Domain Networks with Multiple IGPs
3. Reply Path TLV
4. Segment Sub-TLV
4.1. Type-A: SID Only, in the Form of an MPLS Label
4.2. Type-C: IPv4 Node Address with an Optional SID for SR-MPLS
4.3. Type-D: IPv6 Node Address with an Optional SID for SR-MPLS
4.4. Segment Flags
5. Detailed Procedures
5.1. Sending an Echo Request
5.2. Receiving an Echo Request
5.3. Sending an Echo Reply
5.4. Receiving an Echo Reply
5.5. Building a Reply Path TLV Dynamically
5.5.1. Procedures to Build the Return Path
6. Security Considerations
7. IANA Considerations
7.1. Segment Sub-TLV
7.2. New Registry for Segment ID Sub-TLV Flags
7.3. Reply Path Return Codes Registry
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Examples
A.1. Detailed Example
A.1.1. Procedures for Segment Routing LSP Ping
A.1.2. Procedures for SR LSP Traceroute
A.1.3. Procedures for Building Reply Path TLV Dynamically
Acknowledgments
Contributors
Authors' Addresses
Many network deployments have built their networks consisting of multiple ASes either for the ease of operations or as a result of network mergers and acquisitions. SR can be deployed in such scenarios to provide end-to-end paths, traversing multiple Autonomous Systems (ASes).
多くのネットワーク展開は、運用の容易さまたはネットワーク合併と買収の結果として、複数のASで構成されるネットワークを構築しています。SRは、そのようなシナリオに展開して、エンドツーエンドのパスを提供し、複数の自律システム（ASE）を横断することができます。
[RFC8660] specifies SR with an MPLS data plane. [RFC8402] describes BGP peering segments, and [RFC9087] describes centralized BGP Egress Peer Engineering, which will help in steering packets from one AS to another. By utilizing these SR capabilities, it is possible to create paths that span multiple ASes.
[RFC8660]は、MPLSデータプレーンでSRを指定します。[RFC8402]はBGPピアリングセグメントを説明し、[RFC9087]は集中化されたBGP出口ピアエンジニアリングを説明します。これらのSR機能を利用することにより、複数のASEにまたがるパスを作成することができます。
+----------------+
| Controller/PMS |
+----------------+
|---AS1-----| |----AS2----| |----AS3---|
ASBR2----ASBR3 ASBR5------ASBR7
/ \ / \
/ \ / \
PE1----P1---P2 P3---P4---PE4 P5---P6--PE5
\ / \ /
\ / \ /
ASBR1----ASBR4 ASBR6------ASBR8
Figure 1: Inter-AS Segment Routing Topology
図1：AS Inter-ASセグメントルーティングトポロジ
Autonomous System:
自律システム：
AS1, AS2, AS3
AS1、AS2、AS3
Provider Edge:
プロバイダーエッジ：
PE1, PE4, PE5
PE1、PE4、PE5
Provider:
プロバイダー：
P1, P2, P3, P4, P5, P6
P1、P2、P3、P4、P5、P6
Autonomous System Boundary Router:
自律システム境界ルーター：
ASBR1, ASBR2, ASBR3, ASBR4, ASBR5, ASBR6, ASBR7, ASBR8
ASBR1、ASBR2、ASBR3、ASBR4、ASBR5、ASBR6、ASBR7、ASBR8
For example, Figure 1 describes an inter-AS network scenario consisting of ASes AS1, AS2, and AS3. AS1, AS2, and AS3 are SR enabled, and the egress links have the following Segment Identifiers (SIDs) configured and advertised via [RFC9086]: PeerNode SID, PeerAdj SID, and PeerSet SID. The PeerNode SID, PeerAdj SID, and PeerSet SID are referred to as Egress Peer Engineering SIDs (EPE-SIDs) in this document. The controller or the head-end can build an end-to-end traffic-engineered path consisting of Node-SIDs, Adjacency-SIDs, and EPE-SIDs. It is useful for operators to be able to perform LSP ping and traceroute procedures on these inter-AS SR-MPLS paths, to detect and diagnose failed deliveries, and to determine the actual path that traffic takes through the network. LSP ping and traceroute procedures use IP connectivity for echo replies to reach the head-end. In inter-AS networks, IP connectivity may not be there from each router in the path. For example, in Figure 1, P3 and P4 may not have IP connectivity for PE1.
たとえば、図1は、AS1、AS2、およびAS3で構成されるAS Inter-ASネットワークシナリオを説明しています。AS1、AS2、およびAS3はSRを有効にしており、出力リンクには[RFC9086]を介して構成および宣伝された次のセグメント識別子（SIDS）があります：Peernode SID、PeerAdj SID、およびPeeret SID。Peernode SID、PeerAdj SID、およびPeerset SIDは、このドキュメントでは出口ピアエンジニアリングSID（EPE-SID）と呼ばれます。コントローラーまたはヘッドエンドは、ノードSID、隣接SID、およびEPE-SIDで構成されるエンドツーエンドのトラフィックエンジニアリングパスを構築できます。これらのSR-MPLSパスでLSP PingおよびTraceroute手順を実行し、失敗した配信を検出および診断し、ネットワークを介してトラフィックが取る実際のパスを決定するために、オペレーターがLSP PingおよびTraceroute手順を実行できるように役立ちます。LSP PingおよびTraceroute手順エコー応答にIP接続を使用して、ヘッドエンドに到達します。AS Inter-ASネットワークでは、IP接続がパス内の各ルーターから存在しない場合があります。たとえば、図1では、P3とP4にはPE1のIP接続がない場合があります。
It is not always possible to carry out LSP ping and traceroute functionality on these paths to verify basic connectivity and fault isolation using existing LSP ping and traceroute mechanisms (see [RFC8287] and [RFC8029]). That is because there might not always be IP connectivity from a responding node back to the source address of the ping packet when the responding node is in a different AS from the source of the ping.
これらのパスでLSP PingおよびTraceroute機能を実行して、既存のLSP PingおよびTracerouteメカニズムを使用して基本的な接続と障害分離を検証することは常に可能ではありません（[RFC8287]および[RFC8029]を参照）。これは、応答ノードがPingのソースと同様に異なる場合に、応答ノードからPingパケットのソースアドレスに戻るIP接続が常にあるとは限らないためです。
[RFC8403] describes mechanisms to carry out MPLS ping and traceroute from a Path Monitoring System (PMS). It is possible to build GRE tunnels or static routes to each router in the network to get IP connectivity for the reverse path. This mechanism is operationally very heavy and requires the PMS to be capable of building a huge number of GRE tunnels or installing the necessary static routes, which may not be feasible.
[RFC8403]は、パス監視システム（PMS）からMPLS PingとTracerouteを実行するメカニズムを説明しています。ネットワーク内の各ルーターへのGREトンネルまたは静的ルートを構築して、逆パスのIP接続を取得することができます。このメカニズムは操作的に非常に重いため、PMSは膨大な数のGREトンネルを構築したり、必要でない可能性のある必要な静的ルートを設置できる必要があります。
[RFC7743] describes an Echo-relay-based solution that is predicated on advertising a new Relay Node Address Stack TLV containing a stack of Echo-relay IP addresses. These mechanisms can be applied to SR networks as well. The mechanism from [RFC7743] requires the return ping packet to be processed on the slow path or as a bump-in-the-wire on every relay node. The motivation of the current document is to provide an alternate mechanism for ping and traceroute in inter-domain SR networks. The definition of the term "domain" as applicable to this document is defined in Section 1.1.
[RFC7743]は、Echo-relay IPアドレスのスタックを含む新しいリレーノードアドレススタックTLVを広告することを前提としたエコーレレーベースのソリューションを説明しています。これらのメカニズムは、SRネットワークにも適用できます。[RFC7743]のメカニズムでは、リレーノードごとに遅いパスまたはワイヤの衝突として処理する必要があります。現在のドキュメントの動機は、ドメイン間SRネットワークでのpingとトレーサーの代替メカニズムを提供することです。このドキュメントに適用可能な「ドメイン」という用語の定義は、セクション1.1で定義されています。
This document describes a new mechanism that is efficient and simple and can be easily deployed in SR-MPLS networks. This mechanism uses MPLS paths, and no changes are required in the forwarding path. Any MPLS-capable node will be able to forward the echo-reply packet in the fast path. The current document describes a mechanism that uses the Reply Path TLV [RFC7110] to convey the reverse path. Three new sub-TLVs are defined for the Reply Path TLV that facilitate encoding SR label stacks. The return path can either be derived by a smart application or a controller that has a full topology view or end-to-end view of a section of the topology. This document also proposes mechanisms to derive the return path dynamically during traceroute procedures.
このドキュメントでは、効率的でシンプルで、SR-MPLSネットワークに簡単に展開できる新しいメカニズムについて説明します。このメカニズムはMPLSパスを使用しており、転送パスに変更は必要ありません。MPLSに対応できるノードは、エコーリプライパケットを高速パスに転送できます。現在のドキュメントでは、Reply Path TLV [RFC7110]を使用して逆パスを伝えるメカニズムについて説明しています。SRラベルスタックのエンコードを促進するReply Path TLVに対して3つの新しいサブTLVが定義されています。リターンパスは、トポロジーのセクションの完全なトポロジビューまたはエンドツーエンドビューを持つスマートアプリケーションまたはコントローラーによって導出できます。このドキュメントでは、Traceroute手順中にリターンパスを動的に導き出すメカニズムも提案しています。
This document focuses on the inter-domain use case. The protocol extensions described may also indicate the return path for other use cases, which are outside the scope of this document and are not further detailed here. The SRv6 data plane is also not covered in this document.
このドキュメントは、ドメイン間のユースケースに焦点を当てています。The protocol extensions described may also indicate the return path for other use cases, which are outside the scope of this document and are not further detailed here.SRV6データプレーンもこのドキュメントではカバーされていません。
In this document, the term "domain" refers to an IGP domain where every node is visible to every other node for the purpose of shortest path computation, implying an IGP area or level. An Autonomous System (AS) comprises one or more IGP domains. The procedures described herein are applicable to paths constructed across multiple domains, including both inter-area and inter-AS paths. These procedures and deployment scenarios are relevant for inter-AS paths where the participating ASes are under closely coordinating administrations or single ownership. This document pertains to SR-MPLS networks where all nodes within each domain are SR capable. It also applies to SR-MPLS networks where SR functions as an overlay with SR-incapable underlay nodes. In such networks, the traceroute procedure is executed only on the overlay SR nodes.
このドキュメントでは、「ドメイン」という用語は、最短パス計算を目的として、すべてのノードが他のすべてのノードに表示されるIGPドメインを指し、IGP領域またはレベルを意味します。自律システム（AS）は、1つ以上のIGPドメインを含む。本明細書に記載されている手順は、エリア間およびAS間のパスの両方を含む複数のドメインで構築されたパスに適用できます。これらの手順と展開シナリオは、参加しているASEが管理または単一の所有権を綿密に調整しているパス間のパスに関連しています。このドキュメントは、各ドメイン内のすべてのノードがSR能力があるSR-MPLSネットワークに関係しています。また、SR-MPLSネットワークにも適用されます。SRは、SRインコープ可能なアンダーレイノードを備えたオーバーレイとしてSRが機能します。このようなネットワークでは、Traceroute手順はオーバーレイSRノードでのみ実行されます。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
When the network consists of a large number of nodes, the nodes are segregated into multiple IGP domains as shown in Figure 2. The connectivity to the remote PEs can be achieved by BGP advertisements with an MPLS label bound to the prefix as described in [RFC8277] or by building paths using a list of segments as described in [RFC8604].
ネットワークが多数のノードで構成されている場合、ノードは図2に示すように複数のIGPドメインに分離されます。リモートPEへの接続は、[RFC8277777で説明されているようにプレフィックスに結合したMPLSラベルを使用してBGP広告で達成できます。]または[RFC8604]に記載されているセグメントのリストを使用してパスを構築することによって。
|-Domain 1|-------Domain 2-----|--Domain 3-|
PE1------ABR1--------P--------ABR2------PE4
\ / \ /\ /
-------- ----------------- -------
BGP-LU BGP-LU BGP-LU
Figure 2: Inter-Domain Networks with Multiple IGPs
図2：複数のIGPSを備えたドメイン間ネットワーク
It is useful to support MPLS ping and traceroute mechanisms for these networks. The procedures described in this document for constructing the Reply Path TLV and its use in echo replies are equally applicable to networks consisting of multiple IGP domains that use BGP-Labeled Unicast (BGP-LU) or label stacking.
これらのネットワークのMPLS PINGおよびTRACEROUTEメカニズムをサポートすると便利です。このドキュメントで説明されている手順は、Reply Path TLVとエコー応答でのその使用を構築するための手順は、BGP標識ユニキャスト（BGP-LU）またはラベルスタッキングを使用する複数のIGPドメインで構成されるネットワークに等しく適用できます。
The Reply Path (RP) TLV is defined in [RFC7110]. SR networks statically assign the labels to nodes, and a PMS/head-end may know the entire Link State Database (LSDB) along with assigned SIDs. The reverse path can be built from the PMS/head-end by stacking segments for the reverse path. The Reply Path TLV as defined in [RFC7110] is used to carry the return path. Reply Mode 5 (Reply via Specified Path) is defined in Section 4.1 of [RFC7110]. While using the procedures described in this document, the Reply Mode is set to 5 (Reply via Specified Path), and the Reply Path TLV is included in the echo request message as described in [RFC7110]. The Reply Path TLV is constructed as per Section 4.2 of [RFC7110]. This document defines three new sub-TLVs to encode the SR Path.
返信パス（RP）TLVは[RFC7110]で定義されています。SRネットワークはラベルをノードに静的に割り当て、PMS/ヘッドエンドは、割り当てられたSIDとともにリンク状態データベース（LSDB）全体を把握する場合があります。逆パスは、逆パスのセグメントを積み重ねることにより、PMS/ヘッドエンドから構築できます。[RFC7110]で定義されている応答パスTLVは、リターンパスを運ぶために使用されます。返信モード5（指定されたパス経由の返信）は、[RFC7110]のセクション4.1で定義されています。このドキュメントで説明されている手順を使用している間、返信モードは5（指定されたパス経由で応答）に設定され、[RFC7110]で説明されているように、応答パスTLVがエコー要求メッセージに含まれます。Reply Path TLVは、[RFC7110]のセクション4.2に従って構築されます。このドキュメントでは、SRパスをエンコードする3つの新しいサブTLVを定義します。
The type of segment that the head-end chooses to send in the Reply Path TLV is governed by local policy. Implementations may provide Command Line Interface (CLI) input parameters in the form of labels, IPv4 addresses, IPv6 addresses, or a combination of these, which get encoded in the Reply Path TLV. Implementations may also provide mechanisms to acquire the LSDB of remote domains and compute the return path based on the acquired LSDB. For traceroute purposes, the return path will have to consider the reply being sent from every node along the path. The return path changes when the traceroute progresses and crosses each domain. One of the ways this can be implemented on the head-end is to acquire the entire LSDB (of all domains) and build a return path for every node along the SR-MPLS path based on the knowledge of the LSDB. Another mechanism is to use a dynamically computed return path as described in Section 5.5.
ヘッドエンドがTLVを送信することを選択したセグメントのタイプは、ローカルポリシーに準拠しています。実装は、ラベル、IPv4アドレス、IPv6アドレス、またはこれらの組み合わせの形式でコマンドラインインターフェイス（CLI）入力パラメーターを提供する場合があります。また、実装は、リモートドメインのLSDBを取得し、取得したLSDBに基づいてリターンパスを計算するメカニズムを提供する場合があります。Traceroute目的のために、返品パスは、パスに沿ったすべてのノードから送信される返信を検討する必要があります。Tracerouteが進行して各ドメインを横切ると、リターンパスが変更されます。これをヘッドエンドで実装できる方法の1つは、（すべてのドメインの）LSDB全体を取得し、LSDBの知識に基づいてSR-MPLSパスに沿ってすべてのノードのリターンパスを構築することです。別のメカニズムは、セクション5.5で説明されているように、動的に計算されたリターンパスを使用することです。
Some networks may consist of IPv4-only domains and IPv6-only domains. Handling end-to-end MPLS OAM for such networks is out of the scope of this document. It is recommended to use dual-stack in such cases and use end-to-end IPv6 addresses for MPLS ping and traceroute procedures.
一部のネットワークでは、IPv4のみのドメインとIPv6のみのドメインで構成されている場合があります。このようなネットワークのエンドツーエンドMPLS OAMの処理は、このドキュメントの範囲外です。このような場合にデュアルスタックを使用し、MPLS PingおよびTraceroute手順にエンドツーエンドのIPv6アドレスを使用することをお勧めします。
Section 4 of [RFC9256] defines various Segment Types. The types of segments applicable to this document have been defined in this section for the use of MPLS OAM. The intention was to keep the definitions as close to those in [RFC9256] as possible, with modifications only when needed. One or more Segment sub-TLVs can be included in the Reply Path TLV. The Segment sub-TLVs included in a Reply Path TLV MAY be of different types.
[RFC9256]のセクション4では、さまざまなセグメントタイプを定義しています。このドキュメントに適用されるセグメントの種類は、このセクションでMPLS OAMを使用するために定義されています。意図は、[RFC9256]の定義を可能な限り近くに保つことであり、必要な場合にのみ変更を加えることでした。1つ以上のセグメントサブTLVを応答パスTLVに含めることができます。Reply Path TLVに含まれるセグメントサブTLVは、異なるタイプの場合があります。
The below types of Segment sub-TLVs apply to the Reply Path TLV. The code points for the sub-TLVs are taken from the IANA registry common to TLVs 1, 16, and 21. This document defines the usage and processing of the Type-A, Type-C, and Type-D Segment sub-TLVs when they appear in TLV 21 (Reply Path TLV). If these sub-TLVs appear in TLVs 1 or 16, appropriate error codes MUST be returned as defined in [RFC8029].
以下のセグメントサブTLVのタイプは、Reply Path TLVに適用されます。サブTLVのコードポイントは、TLVS 1、16、および21に共通のIANAレジストリから取得されます。このドキュメントでは、Type-A、Type-C、およびType-DセグメントSub-TLVの使用と処理を定義します。それらはTLV 21（Reply Path TLV）に表示されます。これらのサブTLVがTLVS 1または16に表示される場合、[RFC8029]で定義されているように、適切なエラーコードを返す必要があります。
Type-A:
タイプA：
SID only, in the form of an MPLS label
MPLSラベルの形式でのSIDのみ
Type-C:
タイプC：
IPv4 Node Address with an optional SID
オプションのSIDを備えたIPv4ノードアドレス
Type-D:
Type-D：
IPv6 Node Address with an optional SID for SR-MPLS
SR-MPLSのオプションのSIDを備えたIPv6ノードアドレス
The Type-A Segment sub-TLV encodes a single SID in the form of an MPLS label. The format is as follows:
Type-AセグメントSub-TLVは、MPLSラベルの形で単一のSIDをエンコードします。フォーマットは次のとおりです。
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 | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Type-A Segment Sub-TLV
図3：タイプAセグメントサブTLV
Where:
ただし：
Type:
タイプ：
2 octets. Carries value 46 (assigned by IANA from the "Sub-TLVs for TLV Types 1, 16, and 21" registry).
2オクテット。値46（「TLVタイプ1、16、および21」レジストリの「サブTLVS」からIANAによって割り当てられています）。
Length:
長さ：
2 octets. Carries value 8. The length value excludes the length of the Type and Length fields.
2オクテット。値8を保有します。長さの値は、タイプフィールドと長さフィールドの長さを除外します。
Flags:
フラグ：
1 octet of flags as defined in Section 4.4.
セクション4.4で定義されているフラグの1オクテット。
RESERVED:
予約済み：
3 octets of reserved bits. MUST be set to zero when sending; MUST be ignored on receipt.
予約ビットの3オクテット。送信中はゼロに設定する必要があります。受領時に無視する必要があります。
Label:
ラベル：
20 bits of label value.
20ビットのラベル値。
TC:
TC:
3 bits of Traffic Class (TC). If the originator wants the receiver to choose the TC value, it MUST set the TC field to zero.
3ビットのトラフィッククラス（TC）。オリジネーターが受信機にTC値を選択することを望んでいる場合、TCフィールドをゼロに設定する必要があります。
S:
S:
1 bit Reserved. The S bit MUST be zero upon transmission and MUST be ignored upon reception.
1ビット予約。Sビットは送信時にゼロでなければならず、受信時に無視する必要があります。
TTL:
TTL:
1 octet of TTL. If the originator wants the receiver to choose the TTL value, it MUST set the TTL field to 255.
TTLの1オクテット。オリジネーターが受信者にTTL値を選択することを望んでいる場合、TTLフィールドを255に設定する必要があります。
The labels, TC, S, and TTL are collectively referred to as a SID.
ラベル、TC、S、およびTTLは、集合的にSIDと呼ばれます。
The following applies to the Type-A Segment sub-TLV:
以下は、Type-AセグメントサブTLVに適用されます。
The receiver MAY override the originator's values for these fields. This would be determined by local policy at the receiver. One possible policy would be to override the fields only if the fields have the default values specified above.
受信者は、これらのフィールドのオリジネーターの値をオーバーライドする場合があります。これは、レシーバーのローカルポリシーによって決定されます。可能なポリシーの1つは、フィールドに上記のデフォルト値がある場合にのみ、フィールドをオーバーライドすることです。
The Type-C Segment sub-TLV encodes an IPv4 Node Address, SR Algorithm, and an optional SID in the form of an MPLS label. The format is as follows:
Type-CセグメントSub-TLVは、MPLSラベルの形式のIPv4ノードアドレス、SRアルゴリズム、およびオプションのSIDをエンコードします。フォーマットは次のとおりです。
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 | RESERVED (MBZ) | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Type-C Segment Sub-TLV
図4：Type-CセグメントサブTLV
Where:
ただし：
Type:
タイプ：
47 (assigned by IANA from the "Sub-TLVs for TLV Types 1, 16, and 21" registry).
47（「TLVタイプ1、16、および21レジストリの「サブTLV」からIANAによって割り当てられています）。
Length:
長さ：
2 octets. Carries value 8 when no optional SID is included or value 12 when the optional SID is included.
2オクテット。オプションのSIDが含まれていない場合は値8、オプションのSIDが含まれている場合は値12が含まれます。
Flags:
フラグ：
1 octet of flags as defined in Section 4.4.
セクション4.4で定義されているフラグの1オクテット。
RESERVED:
予約済み：
2 octets of reserved bits. MUST be set to zero when sending; MUST be ignored on receipt.
予約ビットの2オクテット。送信中はゼロに設定する必要があります。受領時に無視する必要があります。
SR Algorithm:
SRアルゴリズム：
1 octet. When the A-Flag (as defined in Section 4.4) is present, this specifies the SR Algorithm as described in Section 3.1.1 of [RFC8402] or the Flexible Algorithm as defined in [RFC9350]. The SR Algorithm is used by the receiver to derive the label. When the A-Flag is unset, this field has no meaning and thus MUST be set to zero (MBZ) on transmission and ignored on receipt.
1オクテット。A-Flag（セクション4.4で定義されている）が存在する場合、これは[RFC8402]のセクション3.1.1で説明されているSRアルゴリズムまたは[RFC9350]で定義されている柔軟なアルゴリズムを指定します。SRアルゴリズムは、レシーバーによってラベルを導出するために使用されます。A-Flagが設定されていない場合、このフィールドには意味がないため、送信時にゼロ（MBZ）に設定する必要があり、受領時に無視する必要があります。
IPv4 Node Address:
IPv4ノードアドレス：
4-octet IPv4 address representing a node. The IPv4 Node Address MUST be present. It should be a stable address belonging to the node (e.g., loopback address).
4-OCTET IPv4アドレスを表すノードを表します。IPv4ノードアドレスが存在する必要があります。それは、ノードに属する安定したアドレスである必要があります（例：ループバックアドレス）。
SID:
SID:
Optional 4-octet field containing the labels TC, S, and TTL as defined in Section 4.1. When the SID field is present, it MUST be used for constructing the Reply Path.
セクション4.1で定義されているラベルTC、S、およびTTLを含むオプションの4-OCTETフィールド。SIDフィールドが存在する場合、応答パスの構築に使用する必要があります。
The Type-D Segment sub-TLV encodes an IPv6 Node Address, SR Algorithm, and an optional SID in the form of an MPLS label. The format is as follows:
Type-DセグメントSub-TLVは、MPLSラベルの形式のIPv6ノードアドレス、SRアルゴリズム、およびオプションのSIDをエンコードします。フォーマットは次のとおりです。
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 | RESERVED (MBZ) | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Type-D Segment Sub-TLV
図5：Type-DセグメントサブTLV
Where:
ただし：
Type:
タイプ：
48 (assigned by IANA from the "Sub-TLVs for TLV Types 1, 16, and 21" registry).
48（「TLVタイプ1、16、および21レジストリの「サブTLV」からIANAによって割り当てられています）。
Length:
長さ：
2 octets. Carries value 20 when no optional SID is included or value 24 when the optional SID is included.
2オクテット。オプションのSIDが含まれていない場合は値20またはオプションのSIDが含まれている場合の値24。
Flags:
フラグ：
1 octet of flags as defined in Section 4.4.
セクション4.4で定義されているフラグの1オクテット。
RESERVED:
予約済み：
2 octets of reserved bits. MUST be set to zero when sending; MUST be ignored on receipt.
予約ビットの2オクテット。送信中はゼロに設定する必要があります。受領時に無視する必要があります。
SR Algorithm:
SRアルゴリズム：
1 octet. When the A-Flag (as defined in Section 4.4) is present, this specifies the SR Algorithm as described in Section 3.1.1 of [RFC8402] or the Flexible Algorithm as defined in [RFC9350]. The SR Algorithm is used by the receiver to derive the label. When the A-Flag is unset, this field has no meaning and thus MUST be set to zero (MBZ) on transmission and ignored on receipt.
1オクテット。A-Flag（セクション4.4で定義されている）が存在する場合、これは[RFC8402]のセクション3.1.1で説明されているSRアルゴリズムまたは[RFC9350]で定義されている柔軟なアルゴリズムを指定します。SRアルゴリズムは、レシーバーによってラベルを導出するために使用されます。A-Flagが設定されていない場合、このフィールドには意味がないため、送信時にゼロ（MBZ）に設定する必要があり、受領時に無視する必要があります。
IPv6 Node Address:
IPv6ノードアドレス：
16-octet IPv6 address of one interface of a node. The IPv6 Node Address MUST be present. It should be a stable address belonging to the node (e.g., loopback address).
16-OCTET IPv6ノードの1つのインターフェイスのアドレス。IPv6ノードアドレスが存在する必要があります。それは、ノードに属する安定したアドレスである必要があります（例：ループバックアドレス）。
SID:
SID:
Optional 4-octet field containing the labels TC, S, and TTL as defined in Section 4.1. When the SID field is present, it MUST be used for constructing the Reply Path.
セクション4.1で定義されているラベルTC、S、およびTTLを含むオプションの4-OCTETフィールド。SIDフィールドが存在する場合、応答パスの構築に使用する必要があります。
The Segment Types described above contain the following flags in the Flags field (codes assigned by IANA from the "Segment ID Sub-TLV Flags" registry):
上記のセグメントタイプには、フラグフィールドに次のフラグが含まれています（「セグメントIDサブTLVフラグ」レジストリからIANAによって割り当てられたコード）：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |A| | | | | | |
+-+-+-+-+-+-+-+-+
Figure 6: Flags
図6：フラグ
Where:
ただし：
A-Flag:
a-flag：
This flag indicates the presence of an SR Algorithm ID in the SR Algorithm field applicable to various Segment Types.
このフラグは、さまざまなセグメントタイプに適用されるSRアルゴリズムフィールドにSRアルゴリズムIDが存在することを示しています。
Unused bits in the Flag octet MUST be set to zero upon transmission and MUST be ignored upon receipt.
フラグの未使用のビットは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
The following applies to the Segment Flags:
以下はセグメントフラグに適用されます。
The A-Flag applies to Segment Type-C and Type-D. If the A-Flag appears with the Type-A Segment Type, it MUST be ignored.
A-Flagは、セグメントType-CおよびType-Dに適用されます。A-FlagがType-Aセグメントタイプで表示される場合、無視する必要があります。
This section uses the term "initiator" for the node that initiates the MPLS ping or the MPLS traceroute procedure. The term "responder" is used for the node that receives the echo request and sends the echo reply. The term "egress node" is used to identify the last node where the MPLS ping or traceroute is destined to. In an MPLS network, any node can be an initiator, responder, or egress.
このセクションでは、MPLS pingまたはMPLS Traceroute手順を開始するノードの「イニシエーター」という用語を使用します。「レスポンダー」という用語は、エコー要求を受信してエコー応答を送信するノードに使用されます。「Egressノード」という用語は、MPLS pingまたはTracerouteが運命づけられている最後のノードを識別するために使用されます。MPLSネットワークでは、任意のノードはイニシエーター、レスポンダー、または出口になります。
In the inter-AS scenario, the procedures outlined in this document are employed to specify the return path when IP connectivity to the initiator is unavailable. These procedures may also be utilized regardless of the availability of IP connectivity. The LSP ping initiator MUST set the Reply Mode of the echo request to 5 (Reply via Specified Path), and a Reply Path TLV MUST be carried in the echo request message correspondingly. The Reply Path TLV MUST contain the SR Path in the reverse direction encoded as an ordered list of segments. The first segment MUST correspond to the top segment in the MPLS header that the responder MUST use while sending the echo reply.
AS Inter-ASシナリオでは、このドキュメントで概説されている手順を使用して、イニシエーターへのIP接続が利用できない場合のリターンパスを指定します。これらの手順は、IP接続の可用性に関係なく使用することもできます。LSP Pingイニシエーターは、エコーリクエストの応答モードを5に設定する必要があり（指定されたパス経由で応答）、応答パスTLVをEcho Requestメッセージにそれに対応する必要があります。Reply Path TLVには、セグメントの順序付けられたリストとしてエンコードされた逆方向にSRパスを含める必要があります。最初のセグメントは、エコー応答を送信する際に応答者が使用する必要があるMPLSヘッダーの上部セグメントに対応する必要があります。
As described in [RFC7110], when the Reply Mode is set to 5 (Reply via Specified Path), the echo request must contain the Reply Path TLV. The absence of the Reply Path TLV is treated as a malformed echo request. When an echo request is received, if the responder does not support the Reply Mode 5 defined in [RFC7110], an echo reply with the Return Code set to "Malformed echo request received" and the Subcode set to zero must be sent back to the initiator according to the rules of [RFC8029]. If the echo request message contains a malformed Segment sub-TLV, such as an incorrect length field, an echo reply must be sent back to the initiator with the Return Code set to "Malformed echo request received" and the Subcode set to zero.
[RFC7110]で説明されているように、返信モードが5に設定されている場合（指定されたパス経由で応答）、エコー要求には応答パスTLVを含める必要があります。応答パスTLVの欠如は、奇形のエコー要求として扱われます。エコー要求が受信された場合、応答者が[rfc7110]で定義された返信モード5をサポートしていない場合、「recumededededee echo request」に設定されたreturnコードを使用したエコー返信とゼロにサブコード設定を返信する必要があります。[RFC8029]のルールに従ってイニシエーター。エコー要求メッセージに、誤った長さフィールドなどの不正なセグメントサブTLVが含まれている場合、echoの応答は、returnコードを「malformed echo request」に設定し、サブコードをゼロに設定して、returnコードをゼロに設定してイニシエーターに返信する必要があります。
When a Reply Path TLV is received, the responder that supports processing it MUST use the segments in Reply Path TLV to build the echo reply. The responder MUST follow the normal Forwarding Equivalence Class (FEC) validation procedures as described in [RFC8029] and [RFC8287] and this document does not suggest any change to those procedures. When the echo reply has to be sent out, the Reply Path TLV MUST be used to construct the MPLS packet to send out.
返信パスTLVを受信すると、処理をサポートする応答者は、Reply Path TLVのセグメントを使用してEcho Replyを構築する必要があります。応答者は、[RFC8029]および[RFC8287]で説明されているように、通常の転送等価クラス（FEC）検証手順に従う必要があり、この文書はこれらの手順の変更を示唆していません。エコー応答を送信する必要がある場合、MPLSパケットを構築するためにReply Path TLVを使用する必要があります。
The echo reply message is sent as an MPLS packet with an MPLS label stack. The echo reply message MUST be constructed as described in [RFC8029]. An MPLS packet is constructed with an echo reply in the payload. The top label MUST be constructed from the first segment of the Reply Path TLV. The remaining labels MUST be constructed by following the order of the segments from the Reply Path TLV. The MPLS header of the echo reply MUST be constructed from the segments in the Reply Path TLV and MUST NOT add any other label. The S bit is set for the bottom label as per the MPLS specifications [RFC3032]. The responder MAY check the reachability of the top label in its own Label Forwarding Information Base (LFIB) before sending the echo reply. If the top label is unreachable, the responder SHOULD send the appropriate Return Code and follow the procedures as per Section 5.2 of [RFC7110]. The exception case is when the responder does not have IP reachability to the originator, in which case, it may not be possible to send an echo reply at all. Even if sent (by following a default route present on the responder, for example), the echo reply might not reach the originator. The node MAY provide necessary log information in case of unreachability. In certain scenarios, the head-end MAY choose to send Type-C/Type-D segments consisting of IPv4 addresses or IPv6 addresses when it is unable to derive the SID from available topology information. Optionally, the SID may also be associated with the Type-C/Type-D segment, if such information is available from the controller or via operator input. In such cases, the node sending the echo reply MUST derive the MPLS labels based on the Node-SIDs associated with the IPv4/IPv6 addresses. If an optional MPLS SID is present in the Type-C/Type-D segments, the SID MUST be used to encode the echo reply with MPLS labels. If the MPLS SID does not match with the IPv4 or IPv6 address field in the Type-C or Type-D SID, log information should be generated.
Echo Replyメッセージは、MPLSラベルスタックを備えたMPLSパケットとして送信されます。[RFC8029]に記載されているように、エコー応答メッセージは作成する必要があります。MPLSパケットは、ペイロードにエコー応答で構築されます。トップラベルは、Reply Path TLVの最初のセグメントから構築する必要があります。残りのラベルは、Reply Path TLVからセグメントの順序に従って構築する必要があります。エコー応答のMPLSヘッダーは、Reply Path TLVのセグメントから構築する必要があり、他のラベルを追加してはなりません。Sビットは、MPLS仕様[RFC3032]に従って、ボトムラベルに設定されています。応答者は、エコーの返信を送信する前に、独自のラベル転送情報ベース（LFIB）でトップレーベルの到達可能性をチェックする場合があります。トップラベルが到達できない場合、応答者は適切な返品コードを送信し、[RFC7110]のセクション5.2に従って手順に従う必要があります。例外のケースは、応答者が発信者にIPリーチ性を持たない場合です。その場合、エコー応答をまったく送信できない場合があります。（たとえば、レスポンダーに存在するデフォルトのルートに従って）送信されたとしても、エコー応答はオリジネーターに届かない場合があります。ノードは、到達不能の場合に必要なログ情報を提供する場合があります。特定のシナリオでは、ヘッドエンドは、利用可能なトポロジー情報からSIDを導出できない場合に、IPv4アドレスまたはIPv6アドレスで構成されるType-C/Type-Dセグメントを送信することを選択できます。オプションで、SIDは、そのような情報がコントローラーまたはオペレーター入力を介して利用可能である場合、Type-C/Type-Dセグメントにも関連付けられている場合があります。そのような場合、エコー応答を送信するノードは、IPv4/IPv6アドレスに関連付けられたノードSIDに基づいてMPLSラベルを導出する必要があります。Optional MPLS SIDがType-C/Type-Dセグメントに存在する場合、SIDを使用してMPLSラベルを使用してエコー応答をエンコードする必要があります。MPLS SIDがType-CまたはType-D SIDのIPv4またはIPv6アドレスフィールドと一致しない場合、ログ情報を生成する必要があります。
The Reply Path Return Code is set as described in Section 7.4 of [RFC7110]. According to Section 5.3 of [RFC7110], the Reply Path TLV is included in an echo reply indicating the specified return path that the echo reply message is required to follow.
Reply Path Returnコードは、[RFC7110]のセクション7.4で説明されているように設定されています。[RFC7110]のセクション5.3によると、応答パスTLVは、エコー応答メッセージが従う必要があるという指定されたリターンパスを示すエコー応答に含まれています。
When the node is configured to dynamically create a return path for the next echo request, the procedures described in Section 5.5 MUST be used. The Reply Path Return Code MUST be set to 0x0006, and the same Reply Path TLV or a new Reply Path TLV MUST be included in the echo reply.
ノードが次のエコー要求のリターンパスを動的に作成するように構成されている場合、セクション5.5で説明する手順を使用する必要があります。Reply Path Return Codeを0x0006に設定する必要があり、同じReply Path TLVまたは新しい返信パスTLVをEcho Replyに含める必要があります。
The rules and processes defined in Section 4.6 of [RFC8029] and Section 5.4 of [RFC7110] apply here. In addition, if the Reply Path Return Code is "Use Reply Path TLV from this echo reply for building the next echo request" (as defined in this document), the Reply Path TLV from the echo reply MUST be sent in the next echo request with the TTL incremented by 1. If the initiator node does not support the Return Code "Use Reply Path TLV from this echo reply for building the next echo request", log information should be generated indicating the Return Code, and the operator may choose to specify the return path explicitly or use other mechanisms to verify the SR Policy. If the Return Code is 0x0007 "Local policy does not allow dynamic return path building", it indicates that the intermediate node does not support building the dynamic return path. Log information should be generated on the initiator receiving this Return Code, and the operator may choose to specify the return path explicitly or use other mechanisms to verify the SR Policy. If the TTL is already 255, the traceroute procedure MUST be ended with an appropriate log message.
[RFC8029]のセクション4.6で定義されているルールとプロセスは、[RFC7110]のセクション5.4でここに適用されます。さらに、返信パスを返すコードが「次のエコーリクエストを構築するためにこのエコーから応答パスtlvを使用する」（このドキュメントで定義されている）の場合、エコーからの応答パスtlvを次のエコーリクエストで送信する必要がありますTTLが1で増加した場合。イニシエーターノードがリターンコードをサポートしていない場合、「次のエコーリクエストを作成するためにこのエコー応答から返信パスTLVを使用する」、ログ情報を生成する必要があります。リターンパスを明示的に指定するか、他のメカニズムを使用してSRポリシーを検証します。戻りコードが0x0007「ローカルポリシーでは動的リターンパスビルディングが許可されていない」の場合、中間ノードが動的リターンパスの構築をサポートしていないことを示します。この返品コードを受信するイニシエーターでログ情報を生成する必要があり、オペレーターはリターンパスを明示的に指定するか、他のメカニズムを使用してSRポリシーを検証することを選択できます。TTLがすでに255の場合、Tracerouteプロシージャは適切なログメッセージで終了する必要があります。
In some cases, the head-end may not have complete visibility of inter-AS/inter-domain topology. In such cases, it can rely on routers in the path to build the reverse path for MPLS traceroute procedures. For this purpose, the Reply Path TLV in the echo reply corresponds to the return path to be used in building the next echo request. A new Return Code "Use Reply Path TLV from this echo reply for building the next echo request" is defined in this document.
場合によっては、ヘッドエンドは、AS間/ドメイン間トポロジーの完全な可視性を持たない場合があります。そのような場合、MPLS Tracerouteプロシージャの逆パスを構築するために、パスのルーターに依存します。この目的のために、エコーの応答パスTLVは、次のエコー要求の作成に使用されるリターンパスに対応します。このドキュメントでは、新しい返品コード「次のエコーリクエストを構築するためのこのエコー返信からの返信パスTLVを使用してください」。
+========+=========================================+
| Value | Meaning |
+========+=========================================+
| 0x0006 | Use Reply Path TLV from this echo reply |
| | for building the next echo request |
+--------+-----------------------------------------+
Table 1
To dynamically build the return path for the traceroute procedures, the domain border nodes along the path being traced should support the procedures described in this section. Local policy on the domain border nodes should determine whether the domain border node participates in building the return path dynamically during traceroute.
Traceroute手順のリターンパスを動的に構築するために、トレースされているパスに沿ったドメイン境界ノードは、このセクションで説明されている手順をサポートする必要があります。ドメインの境界ノードに関するローカルポリシーは、Traceroute中にドメイン境界ノードがリターンパスの構築に参加するかどうかを判断する必要があります。
The head-end/PMS node may include its node label while initiating the traceroute procedure. When an Area Border Router (ABR) receives the echo request, if the local policy implies building a dynamic return path, the ABR should include its node label in the Reply Path TLV and send it in the echo reply. If there is a Reply Path TLV included in the received echo request message, the ABR's node label is added before the existing segments. The type of segment added is based on local policy. In cases when the Segment Routing Global Block (SRGB) is not uniform across the network, which can be inferred from the LSDB, it is RECOMMENDED to add a Type-C or a Type-D segment. However, implementations MAY safely use other approaches if they see benefits in doing so. If the existing segment in the Reply Path TLV is a Type-C/Type-D segment, that segment should be converted to a Type-A segment based on the ABR's own SRGB. This is because downstream nodes in the path will not know what SRGB to use to translate the IP address to a label. As the ABR added its own node label, it is guaranteed that this ABR will be in the return path and will be forwarding the traffic based on the next label after its label.
ヘッドエンド/PMSノードには、Tracerouteプロシージャの開始中にノードラベルが含まれる場合があります。エリアボーダールーター（ABR）がエコーリクエストを受信した場合、ローカルポリシーが動的リターンパスの構築を暗示する場合、ABRはそのノードラベルをReply Path TLVに含める必要があります。受信したエコーリクエストメッセージに含まれる返信パスTLVがある場合、ABRのノードラベルは既存のセグメントの前に追加されます。追加されたセグメントのタイプは、ローカルポリシーに基づいています。セグメントルーティンググローバルブロック（SRGB）がネットワーク全体で均一でない場合、これはLSDBから推測できますが、Type-CまたはType-Dセグメントを追加することをお勧めします。ただし、実装が他のアプローチを安全に使用する場合があります。Reply Path TLVの既存のセグメントがType-C/Type-Dセグメントである場合、そのセグメントはABR独自のSRGBに基づいてType-Aセグメントに変換する必要があります。これは、パス内のダウンストリームノードが、IPアドレスをラベルに変換するために使用するSRGBがわからないためです。ABRは独自のノードラベルを追加したため、このABRがリターンパスにあり、ラベルの後に次のラベルに基づいてトラフィックを転送することが保証されています。
When an ASBR receives an echo request from another AS, and the ASBR is configured to build the return path dynamically, the ASBR should build a Reply Path TLV and include it in the echo reply. The Reply Path TLV should consist of its node label and an EPE-SID to the AS from where the traceroute message was received. A Reply Path Return Code of 0x0006 MUST be set in the echo reply to indicate that the next echo request MUST use the return path from the Reply Path TLV in the echo reply. ASBR should locally decide the outgoing interface for the echo reply packet. Generally, remote ASBR will choose the interface on which the incoming OAM packet was received to send the echo reply out. In case the ASBR identifies multiple paths to reach the initiator, it MUST choose to send one such path in the Reply Path TLV. The Reply Path TLV is built by adding two Segment sub-TLVs. The top Segment sub-TLV consists of the ASBR's Node-SID, and the second segment consists of the EPE-SID in the reverse direction to reach the AS from which the OAM packet was received. The type of segment chosen to build the Reply Path TLV is a local policy. It is recommended to use the Type-C/Type-D segment for the top segment when the SRGB is not guaranteed to be uniform in the domain.
ASBRが別のASからエコー要求を受信し、ASBRがリターンパスを動的に構築するように構成されている場合、ASBRは応答パスTLVを構築し、エコー応答に含める必要があります。Reply Path TLVは、ノードラベルと、Tracerouteメッセージが受信された場所からePE-SIDで構成する必要があります。ECHO REPLESでは、ECHOリクエストがECHO応答のReply Path TLVからのリターンパスを使用する必要があることを示すために、Echo Replyで0x0006の返信コードを設定する必要があります。ASBRは、エコー応答パケットの発信インターフェイスをローカルで決定する必要があります。一般に、リモートASBRは、エコーの返信を送信するために、着信OAMパケットが受信されたインターフェイスを選択します。ASBRが複数のパスを識別してイニシエーターに到達する場合は、Reply Path TLVにそのようなパスを1つ送信することを選択する必要があります。Reply Path TLVは、2つのセグメントサブTLVを追加することにより構築されます。上部セグメントサブTLVはASBRのノードSIDで構成され、2番目のセグメントは、OAMパケットが受信されたASに到達するために、逆方向のEPE-SIDで構成されています。Reply Path TLVを構築するために選択されたセグメントのタイプは、ローカルポリシーです。SRGBがドメインで均一であることが保証されていない場合は、上部セグメントにType-C/Type-Dセグメントを使用することをお勧めします。
Irrespective of which type of segment is included in the Reply Path TLV, the responder to the echo requests MUST always translate the Reply Path TLV to a label stack and build an MPLS header for the echo reply packet. This procedure can be applied to an end-to-end path consisting of multiple ASes. Each ASBR that receives an echo request from another AS adds its Node-SID and EPE-SID on top of the existing segments in the Reply Path TLV.
どのタイプのセグメントが応答パスTLVに含まれているかに関係なく、エコーリクエストへの応答者は常にReply Path TLVをラベルスタックに変換し、Echo Replyパケット用のMPLSヘッダーを構築する必要があります。この手順は、複数のASESで構成されるエンドツーエンドパスに適用できます。Reply Path TLVの既存のセグメントの上にノードSIDとEPE-SIDを追加すると、他の人からエコー要求を受信する各ASBR。
An ASBR that receives the echo request from a neighbor belonging to the same AS MUST look at the Reply Path TLV received in the echo request. If the Reply Path TLV consists of a Type-C/Type-D segment, it MUST convert the Type-C/Type-D segment to a Type-A segment by deriving a label from its own SRGB. The ASBR MUST set the Reply Path Return Code to 0x0006 and send the newly constructed Reply Path TLV in the echo reply.
同じものに属する隣人からエコー要求を受信するASBRは、ECHOリクエストでTLVを受信したReply Pathを確認する必要があります。Reply Path TLVがType-C/Type-Dセグメントで構成されている場合、独自のSRGBからラベルを導出することにより、Type-C/Type-DセグメントをType-Aセグメントに変換する必要があります。ASBRは、Reply Path Return Codeを0x0006に設定し、Echo Replyで新しく構築されたReply Path TLVを送信する必要があります。
Internal nodes or non-domain border nodes might not set the Reply Path TLV Return Code to 0x0006 in the echo reply message as there is no change in the return path. In these cases, the head-end node/PMS that initiates the traceroute procedure MUST continue to send the previously sent Reply Path TLV in the echo request message in every subsequent echo request.
内部ノードまたは非ドメインの境界ノードは、返信パスに変更がないため、エコー応答メッセージで応答パスTLVリターンコードを0x0006に設定しない場合があります。これらの場合、Tracerouteプロシージャを開始するヘッドエンドノード/PMSは、その後のエコーリクエストごとに、以前に送信されたReply Path TLVをエコーリクエストメッセージに引き続き送信する必要があります。
Note that an ASBR's local policy may prohibit it from participating in the dynamic traceroute procedures. If such an ASBR is encountered in the forward path, dynamic return path building procedures will fail. In such cases, an ASBR that supports this document MUST set the Return Code to 0x0007 to indicate that local policies do not allow the dynamic return path building.
ASBRのローカルポリシーは、動的なトレーサーアウト手順への参加を禁止する可能性があることに注意してください。そのようなASBRがフォワードパスで遭遇した場合、動的リターンパスの構築手順は失敗します。このような場合、このドキュメントをサポートするASBRは、リターンコードを0x0007に設定して、ローカルポリシーが動的リターンパスの構築を許可しないことを示す必要があります。
+========+==========================================================+
| Value | Meaning |
+========+==========================================================+
| 0x0007 | Local policy does not allow |
| | dynamic return path building |
+--------+----------------------------------------------------------+
Table 2
The procedures described in this document enable LSP ping and traceroute procedures to be executed across multiple IGP domains or multiple ASes that belong to the same administration or closely cooperating administrations. It is assumed that sharing domain internal information across such domains does not pose a security risk. However, the procedures described in this document may be used by an attacker to extract the domain's internal information. An operator MUST deploy appropriate filter policies as described in [RFC8029] to restrict the LSP ping and traceroute packets based on origin. It is also RECOMMENDED that an operator deploy security mechanisms such as Media Access Control Security (MACsec) [IEEE-802.1AE] on inter-domain links or security-vulnerable links to prevent spoofing attacks.
このドキュメントで説明されている手順により、LSP PingおよびTraceroute手順は、同じ管理または密接に協力している管理に属する複数のIGPドメインまたは複数のASEで実行できます。このようなドメイン全体でドメイン内部情報を共有しても、セキュリティリスクが発生しないと想定されています。ただし、このドキュメントで説明されている手順は、攻撃者がドメインの内部情報を抽出するために使用できます。[RFC8029]に記載されている適切なフィルターポリシーを展開して、Originに基づいてLSP PingおよびTracerouteパケットを制限する必要があります。また、オペレーターは、ドメイン間リンクまたはセキュリティ攻撃性リンクにメディアアクセス制御セキュリティ（MACSEC）[IEEE-802.1AE]などのセキュリティメカニズムを展開することをお勧めします。
All the security considerations defined in [RFC8029] will be applicable for this document. Appropriate filter policies SHOULD be applied at the edges to prevent attackers from getting into the network. In the event of such a security breach, the network devices MUST have mechanisms to prevent denial-of-service attacks as described in [RFC8029].
[RFC8029]で定義されているすべてのセキュリティ上の考慮事項は、このドキュメントに適用されます。攻撃者がネットワークに入るのを防ぐために、適切なフィルターポリシーをエッジに適用する必要があります。このようなセキュリティ侵害が発生した場合、ネットワークデバイスには[RFC8029]に記載されているように、サービス拒否攻撃を防ぐためのメカニズムが必要です。
IANA has assigned three new sub-TLVs from the "Sub-TLVs for TLV Types 1, 16, and 21" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group.
IANAは、「TLVタイプ1、16、および21」の「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSPS）Pingパラメーター」Pingパラメーターの「TLVタイプ1、16、および21」のレジストリから3つの新しいサブTLVを割り当てました。
+==========+=====================================+=============+
| Sub-Type | Sub-TLV Name | Reference |
+==========+=====================================+=============+
| 46 | SID only, in the form of MPLS label | Section 4.1 |
| | | of RFC 9716 |
+----------+-------------------------------------+-------------+
| 47 | IPv4 Node Address with an optional | Section 4.2 |
| | SID for SR-MPLS | of RFC 9716 |
+----------+-------------------------------------+-------------+
| 48 | IPv6 Node Address with an optional | Section 4.3 |
| | SID for SR-MPLS | of RFC 9716 |
+----------+-------------------------------------+-------------+
Table 3
The code points for the Segment sub-TLVs have been registered in the Standards Action range (0-16383).
セグメントサブTLVのコードポイントは、標準アクション範囲（0-16383）に登録されています。
IANA has created a new "Segment ID Sub-TLV Flags" registry (see Section 4.4) under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group.
IANAは、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチ付きパス（LSP）Pingパラメーター」レジストリグループの下に、新しい「セグメントIDサブTLVフラグ」レジストリ（セクション4.4を参照）を作成しました。
This registry tracks the assignment of 8 flags in the Segment ID sub-TLV flags field. The flags are numbered from 0 (the most significant bit and transmitted first) to 7.
このレジストリは、セグメントIDサブTLVフラグフィールドに8つのフラグの割り当てを追跡します。フラグには、0（最も重要なビットと最初に送信）から7に番号が付けられます。
New entries are assigned by Standards Action. Initial entries in the registry are as follows:
新しいエントリは、標準アクションによって割り当てられます。レジストリの初期エントリは次のとおりです。
+============+========+=========================+
| Bit Number | Name | Reference |
+============+========+=========================+
| 1 | A-Flag | Section 4.4 of RFC 9716 |
+------------+--------+-------------------------+
Table 4
IANA has assigned new Return Codes in the "Reply Path Return Codes" registry under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group.
IANAは、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチパス（LSP）Pingパラメーター」レジストリグループの下にある「Reply Path Return Codes」レジストリに新しいリターンコードを割り当てました。
+========+=========================================+===========+
| Value | Meaning | Reference |
+========+=========================================+===========+
| 0x0006 | Use Reply Path TLV from this echo reply | RFC 9716 |
| | for building the next echo request | |
+--------+-----------------------------------------+-----------+
| 0x0007 | Local policy does not allow dynamic | RFC 9716 |
| | return path building | |
+--------+-----------------------------------------+-----------+
Table 5
The Return Codes have been registered in the Standards Action range (0x0000-0xFFFB).
返品コードは、標準アクション範囲（0x0000-0xfffb）に登録されています。
[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>.
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, DOI 10.17487/RFC7110, January 2014,
<https://www.rfc-editor.org/info/rfc7110>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[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>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
[IEEE-802.1AE]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security", IEEE Std
8021.AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
2018, <https://ieeexplore.ieee.org/document/8585421>.
[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>.
[RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G.
Swallow, Ed., "Relayed Echo Reply Mechanism for Label
Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743,
January 2016, <https://www.rfc-editor.org/info/rfc7743>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.
[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>.
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
Kumar, "A Scalable and Topology-Aware MPLS Data-Plane
Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July
2018, <https://www.rfc-editor.org/info/rfc8403>.
[RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed.,
Henderickx, W., and D. Cooper, "Interconnecting Millions
of Endpoints with Segment Routing", RFC 8604,
DOI 10.17487/RFC8604, June 2019,
<https://www.rfc-editor.org/info/rfc8604>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K.,
Ray, S., and J. Dong, "Border Gateway Protocol - Link
State (BGP-LS) Extensions for Segment Routing BGP Egress
Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August
2021, <https://www.rfc-editor.org/info/rfc9086>.
[RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,
and D. Afanasiev, "Segment Routing Centralized BGP Egress
Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August
2021, <https://www.rfc-editor.org/info/rfc9087>.
[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>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
This section elaborates examples of the inter-domain ping and traceroute procedures described in this document.
このセクションでは、このドキュメントで説明されているドメイン間のpingおよびtraceroute手順の例を詳しく説明します。
The example topology given in Figure 1 will be used in the below sections to explain LSP ping and traceroute procedures. The PMS/ head-end has a complete view of the topology. PE1, P1, P2, ASBR1, and ASBR2 are in AS1. Similarly, ASBR3, ASBR4, P3, P4, and PE4 are in AS2.
図1に示すトポロジの例は、以下のセクションで使用され、LSP PingおよびTracerouteの手順を説明します。PMS/ヘッドエンドには、トポロジーの完全な見解があります。PE1、P1、P2、ASBR1、およびASBR2はAS1です。同様に、ASBR3、ASBR4、P3、P4、およびPE4はAS2です。
AS1 and AS2 have SR enabled. IGPs like OSPF/IS-IS are used to flood SIDs in each AS. ASBR1, ASBR2, ASBR3, and ASBR4 advertise BGP EPE-SIDs for the inter-AS links. The topologies of AS1 and AS2 are advertised via BGP - Link State (BGP-LS) to the controller, PMS, or head-end node. The EPE-SIDs are also advertised via BGP-LS as described in [RFC9086]. The example uses EPE-SIDs for the inter-AS links, but the same could be achieved using Adjacency-SIDs advertised for a passive IGP link.
AS1とAS2にはSRが有効になっています。OSPF/IS-ISのようなIGPは、それぞれにSIDをflood濫させるために使用されます。ASBR1、ASBR2、ASBR3、およびASBR4は、Inter-ASリンクについてBGP EPE-SIDを宣伝しています。AS1とAS2のトポロジーは、BGP-Link State（BGP-LS）を介してコントローラー、PMS、またはヘッドエンドノードに宣伝されます。EPE-SIDは、[RFC9086]で説明されているように、BGP-LSを介して宣伝されています。この例では、Inter-AsリンクにEPE-SIDSを使用しますが、パッシブIGPリンクに宣伝されている隣接SIDSを使用して同じことを達成できます。
The description in this document uses the notations below for SIDs.
このドキュメントの説明は、SIDSの以下の表記を使用しています。
Node-SIDs: N-PE1, N-P1, N-ASBR1, etc.
ノードSIDS：n-pe1、n-p1、n-asbr1など。
Adjacency-SIDs: Adj-PE1-P1, Adj-P1-P2, etc.
隣接SIDS：adj-pe1-p1、adj-p1-p2など。
EPE-SIDs: EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2, etc.
EPE-SIDS：EPE-ASBR2-ASBR3、EPE-ASBR1-ASBR4、EPE-ASBR3-ASBR2など。
Consider an SR-MPLS path from PE1 to PE4 consisting of a label stack [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] from Figure 1. In order to perform MPLS ping procedures on this path, the remote end (PE4) needs IP connectivity to head-end PE1 for the echo reply to travel back to PE1. In a deployment that uses a controller-computed inter-domain path, there may be no IP connectivity from PE4 to PE1 as they lie in different ASes.
図1からのラベルスタック[n-P1、n-asbr1、epe-asbr1-asbr4、n-pe4]で構成されるPE1からPE4へのSR-MPLSパスを検討してください。リモートエンド（PE4）は、エコーの応答がPE1に戻るためにヘッドエンドPE1にIP接続を必要とします。コントローラーが計算したドメイン間パスを使用する展開では、異なるASEにあるため、PE4からPE1へのIP接続がない場合があります。
PE1 sends an echo request message to the endpoint PE4 along the path that consists of label stacks [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4]. PE1 adds the return path from PE4 to PE1 in the echo request message in the Reply Path TLV. As an example, the Reply Path TLV for PE1 to PE4 for LSP ping is [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. This example path provides the entire return path up to the head-end node PE1. The mechanism used to construct the return path is implementation dependent.
PE1は、ラベルスタック[N-P1、n-ASBR1、EPE-ASBR1-ASBR4、n-PE4]で構成されるパスに沿ってエンドポイントPE4にエコー要求メッセージを送信します。PE1は、Reply Path TLVのEcho要求メッセージにPE4からPE1へのリターンパスを追加します。例として、LSP pingのPE1からPE4への応答パスTLVは[N-ASBR4、EPE-ASBR4-ASBR1、N-PE1]です。この例パスは、ヘッドエンドノードPE1までのリターンパス全体を提供します。リターンパスの構築に使用されるメカニズムは、実装に依存します。
An implementation may also build a return path consisting of labels to reach its own AS. Once the label stack is popped off, the echo reply message will be exposed. The further packet forwarding will be based on IP lookup. An example return path for this case could be [N-ASBR4, EPE-ASBR4-ASBR1].
実装は、独自のASに到達するためのラベルで構成されるリターンパスを構築する場合があります。ラベルスタックがオフになると、エコー応答メッセージが公開されます。さらなるパケット転送は、IPルックアップに基づいています。このケースのリターンパスの例は、[n-asbr4、epe-asbr4-asbr1]である可能性があります。
On receiving an MPLS echo request, PE4 first validates the FEC in the echo request. PE4 then builds a label stack to send the response from PE4 to PE1 by copying the labels from the Reply Path TLV. PE4 builds the echo reply packet with the MPLS label stack constructed, imposes MPLS headers on top of the echo reply packet, and sends out the packet to PE1. This segment list stack can successfully steer the reply back to the head-end node (PE1).
MPLSエコーリクエストを受信すると、PE4は最初にECHOリクエストのFECを検証します。次に、PE4はラベルスタックを構築して、Reply Path TLVからラベルをコピーすることにより、PE4からPE1への応答を送信します。PE4は、MPLSラベルスタックを構築したEcho Replyパケットを構築し、Echo Replyパケットの上にMPLSヘッダーを課し、PE1にパケットを送信します。このセグメントリストスタックは、応答をヘッドエンドノード（PE1）に正常に導くことができます。
Let us consider a case when the P3 node does not have a route to reach N-PE4. On P3, a ping packet would be dropped, and the head-end node (PE1) will not receive an echo reply indicating failure.
P3ノードにN-PE4に到達するルートがない場合を考えてみましょう。P3では、pingパケットがドロップされ、ヘッドエンドノード（PE1）は障害を示すエコー応答を受け取りません。
The traceroute procedure involves visiting every node on the path and obtaining echo replies from every node. In this section, we describe the traceroute mechanisms when the head-end/PMS has complete visibility of the LSDB. The head-end/PMS computes the return path from each node in the entire SR-MPLS path that is being tracerouted. The return path computation is implementation dependent. As the head-end/PMS completely controls the return path, it can use proprietary computations to build the return path.
Traceroute手順では、パス上のすべてのノードにアクセスし、すべてのノードからエコー応答を取得することが含まれます。このセクションでは、ヘッドエンド/PMSがLSDBの完全な可視性を持っている場合のトレーサーアウトメカニズムについて説明します。ヘッドエンド/PMSは、トレーサーが行われているSR-MPLSパス全体の各ノードからのリターンパスを計算します。リターンパス計算は実装依存です。ヘッドエンド/PMSはリターンパスを完全に制御するため、独自の計算を使用してリターンパスを構築できます。
One of the ways the return path can be built is to use the principle of building label stacks by adding each domain border node's Node-SID on the return path label stack as the traceroute progresses. For inter-AS networks, in addition to the border node's Node-SID, the EPE-SID in the reverse direction also needs to be added to the label stack.
リターンパスを構築する方法の1つは、Tracerouteの進行時にリターンパスラベルスタックに各ドメイン境界ノードのノードSIDを追加することにより、ラベルスタックを構築する原理を使用することです。AS Inter-ASネットワークの場合、BorderノードのノードSIDに加えて、逆方向のEPE-SIDもラベルスタックに追加する必要があります。
The inter-domain/inter-AS traceroute procedure uses the TTL expiry mechanism as specified in [RFC8029] and [RFC8287]. Every echo request packet head-end/PMS will include the appropriate return path in the Reply Path TLV. The node that receives the echo request will follow procedures described in Sections 5.1 and 5.2 to send out an echo reply.
Traceroute間手順としてのドメイン間/Inter-inter-inter-inter-inter-inter-inter-inerは、[RFC8029]および[RFC8287]で指定されているTTL有効期限メカニズムを使用します。すべてのエコー要求パケットヘッドエンド/PMSには、応答パスTLVの適切なリターンパスが含まれます。エコー要求を受信するノードは、セクション5.1および5.2で説明されている手順に従って、エコー応答を送信します。
For example:
例えば：
Let us consider the topology from Figure 1. Let us consider an SR-MPLS path [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4]. The traceroute is being executed for this inter-AS path for destination PE4. PE1 sends the first echo request with the TTL set to 1 and includes a Reply Path TLV consisting of a Type-A segment containing a label derived from its own SRGB. Note that the type of segment used in constructing the return path is determined by local policy. If the entire network has the same SRGB configured, Type-A segments can be used. The TTL expires on P1, and P1 sends an echo reply using the return path. Note that implementations may choose to exclude the Reply Path TLV until the traceroute reaches the first domain border as the return IP path to PE1 is expected to be available inside the first domain.
図1のトポロジーを考えてみましょう。SR-MPLSパス[N-P1、N-ASBR1、EPE-ASBR1-ASBR4、N-PE4]を考えてみましょう。Tracerouteは、宛先PE4のこの界面として実行されています。PE1は、TTLセットを1に設定して最初のエコー要求を送信し、独自のSRGBから派生したラベルを含むタイプAセグメントで構成される応答パスTLVを含みます。リターンパスの構築に使用されるセグメントのタイプは、ローカルポリシーによって決定されることに注意してください。ネットワーク全体に同じSRGB構成がある場合、タイプAセグメントを使用できます。TTLはP1で期限切れになり、P1はリターンパスを使用してエコー応答を送信します。TRACERouteが最初のドメイン内で利用可能になると予想されるため、Tracerouteが最初のドメイン境界に到達するまで、実装はReply Path TLVを除外することを選択する場合があることに注意してください。
The TTL is set to 2, and the next echo request is sent out. Until the traceroute procedure reaches the domain border node ASBR1, the same return path TLV consisting of a single label (PE1's node label) is used. When an echo request reaches the border node ASBR1, and an echo reply is received from ASBR1, the next echo request needs to include an additional label as ASBR1 is a border node. The head-end node has complete visibility of the network LSDB learned via BGP-LS (see [RFC9552] and [RFC9086]) and can derive the details of ASBR nodes. The Reply Path TLV is built based on the forward path. As the forward path consists of EPE-ASBR1-ASBR4, an EPE-SID in the reverse direction is included in the Reply Path TLV. The return path now consists of two labels: [EPE-ASBR4-ASBR1, N-PE1]. The echo reply from ASBR4 will use this return path to send the reply.
TTLは2に設定されており、次のエコーリクエストが送信されます。TracerouteプロシージャがドメインボーダーノードASBR1に到達するまで、単一のラベル（PE1のノードラベル）で構成される同じ戻りパスTLVが使用されます。エコー要求が境界ノードASBR1に到達し、ASBR1からエコー応答が受信されると、ASBR1が境界ノードであるため、次のエコーリクエストに追加のラベルを含める必要があります。ヘッドエンドノードは、BGP-LS（[RFC9552]および[RFC9086]を参照）を介して学習したネットワークLSDBの完全な可視性を持ち、ASBRノードの詳細を導き出すことができます。返信パスTLVは、フォワードパスに基づいて構築されます。フォワードパスはEPE-ASBR1-ASBR4で構成されているため、逆方向のEPE-SIDがReply Path TLVに含まれています。リターンパスは、[EPE-ASBR4-ASBR1、N-PE1]の2つのラベルで構成されています。ASBR4からのエコー返信は、このリターンパスを使用して返信を送信します。
After visiting the border node ASBR4, the next echo request will update the return path with the Node-SID label of ASBR4. The return path beyond ASBR4 will be [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. This same return path is used until the traceroute procedure reaches the next set of border nodes. When there are multiple ASes, the traceroute procedure will continue by adding a set of Node-SIDs and EPE-SIDs as the border nodes are visited.
BorderノードASBR4にアクセスした後、次のエコーリクエストはASBR4のノードSIDラベルを使用してリターンパスを更新します。ASBR4を超えるリターンパスは[n-ASBR4、EPE-ASBR4-ASBR1、N-PE1]になります。この同じリターンパスは、Traceroute手順が次のボーダーノードセットに到達するまで使用されます。複数のASEがある場合、境界ノードにアクセスすると、ノードSIDとEPE-SIDのセットを追加することにより、Traceroute手順が継続されます。
Note that the above return path building procedure requires the LSDB of all the domains to be available at the head-end/PMS.
上記の戻りパスビルディング手順では、すべてのドメインのLSDBがヘッドエンド/PMSで利用可能であることに注意してください。
Let us consider a case when the P3 node does not have a route to reach N-PE4. When the TTL of the packet is 5, the packet reaches P3, its TTL becomes zero, and it is sent to the control plane. The FEC validation procedures are executed, and the echo reply is sent using the labels in the Reply Path TLV, which is [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4]. The head-end PE1 increases the TTL to 6 and sends the next echo request. The packet is dropped at P3 as there is no route on P3 to forward to N-PE4. The traceroute identifies that the path [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] is broken at P3.
P3ノードにN-PE4に到達するルートがない場合を考えてみましょう。パケットのTTLが5の場合、パケットがP3に達し、TTLがゼロになり、コントロールプレーンに送信されます。FEC検証手順が実行され、エコー応答は、[n-pe1、epe-asbr4-asbr1、n-asbr4]であるReply Path TLVのラベルを使用して送信されます。ヘッドエンドPE1はTTLを6に増やし、次のエコーリクエストを送信します。P3にN-PE4に転送するルートがないため、パケットはP3でドロップされます。Tracerouteは、パス[n-p1、n-asbr1、epe-asbr1-asbr4、n-pe4]がp3で壊れていることを識別します。
Appendix A.1.2.1 assumes the same SRGB is configured on all nodes along the path. The SRGB may differ from one node to another node, and the SR architecture [RFC8402] allows the nodes to use different SRGBs. In such scenarios, PE1 finds out the difference in the SRGB by looking into the LSDB. Then, it sends the Type-C segment (or the Type-D segment, in the case of IPv6 networks) with the node address of PE1 and with an optional MPLS SID associated with the node address. The receiving node derives the label for the return path based on its own SRGB. When the traceroute procedure crosses the border ASBR1, head-end PE1 should send a Type-A segment for N-PE1 based on the label derived from ASBR1's SRGB. This is required because ASBR4, P3, P4, etc. may not have the topology information to derive SRGB for PE1. After the traceroute procedure reaches ASBR4, the return path will be [N-PE1 (Type-A with the label based on ASBR1's SRGB), EPE-ASBR4-ASBR1, N-ASBR4 (Type-C)].
付録A.1.2.1は、同じSRGBがパスに沿ったすべてのノードで構成されていると仮定しています。SRGBは、ノードから別のノードまで異なる場合があり、SRアーキテクチャ[RFC8402]により、ノードは異なるSRGBを使用できます。このようなシナリオでは、PE1はLSDBを調べてSRGBの違いを見つけます。次に、PE1のノードアドレスと、ノードアドレスに関連付けられたオプションのMPLS SIDとともに、Type-Cセグメント（またはIPv6ネットワークの場合はType-Dセグメント）を送信します。受信ノードは、独自のSRGBに基づいてリターンパスのラベルを導き出します。TracerouteプロシージャがBorder ASBR1を通過すると、ヘッドエンドPE1はASBR1のSRGBから派生したラベルに基づいてN-PE1のタイプAセグメントを送信する必要があります。ASBR4、P3、P4などは、PE1のSRGBを導出するトポロジ情報がない場合があるため、これが必要です。Traceroute手順がASBR4に到達した後、リターンパスは[n-PE1（ASBR1のSRGBに基づくラベルを使用）、EPE-ASBR4-ASBR1、N-ASBR4（Type-C）]になります。
If the packet needs to follow a return path specific to an algorithm (as defined in [RFC9350]), a Type-C Segment sub-TLV with a corresponding algorithm field set should be used. The A-Flag should be set to indicate that the SID corresponding to the algorithm should be used.
パケットがアルゴリズムに固有のリターンパス（[RFC9350]で定義されている）に従う必要がある場合、対応するアルゴリズムフィールドセットを備えたType-CセグメントサブTLVを使用する必要があります。A-Flagは、アルゴリズムに対応するSIDを使用する必要があることを示すように設定する必要があります。
To extend the example to three or more ASes, let us consider a traceroute from PE1 to PE5 in Figure 1. In this example, the PE1 to PE5 path has to cross three domains: AS1, AS2, and AS3. Let us consider a path from PE1 to PE5 that goes through [PE1, ASBR1, ASBR4, ASBR6, ASBR8, PE5]. When the traceroute procedure is visiting the nodes in AS1, the Reply Path TLV sent from the head-end consists of [N-PE1]. When the traceroute procedure reaches the ASBR4, the return path consists of [N-PE1, EPE-ASBR4-ASBR1]. While visiting nodes in AS2, the traceroute procedure consists of the Reply Path TLV [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4]. Similarly, while visiting ASBR8, the EPE-SID from ASBR8 to ASBR6 is added to the Reply Path TLV. While visiting nodes in AS3, the Node-SID of ASBR8 would also be added, which makes the return path [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4, EPE-ASBR8-ASBR6, N-ASBR8].
例を3つ以上のASEに拡張するには、図1のPE1からPE5へのTracerouteを考えてみましょう。この例では、PE1からPE5パスはAS1、AS2、およびAS3の3つのドメインを通過する必要があります。[PE1、ASBR1、ASBR4、ASBR6、ASBR8、PE5]を通過するPE1からPE5へのパスを考えてみましょう。Traceroute手順がAS1のノードにアクセスしている場合、ヘッドエンドから送信されたReply Path TLVは[N-PE1]で構成されます。Traceroute手順がASBR4に到達すると、リターンパスは[n-PE1、EPE-ASBR4-ASBR1]で構成されます。AS2でノードにアクセスしている間、Traceroute手順は、Reply Path TLV [n-PE1、EPE-ASBR4-ASBR1、N-ASBR4]で構成されています。同様に、ASBR8にアクセスしているときに、ASBR8からASBR6へのEPE-SIDがReply Path TLVに追加されます。AS3のノードにアクセスしている間、ASBR8のノードSIDも追加され、リターンパス[N-PE1、EPE-ASBR4-ASBR1、N-ASBR4、EPE-ASBR8-ASBR6、N-ASBR8]が作成されます。
Let us consider another example from the topology in Figure 2. This topology consists of multi-domain IGP with a common border node between the domains. This could be achieved with multi-area or multi-level IGP or with multiple instances of IGP deployed on the same node. The return path computation for this topology is similar to multi-AS computation, except that the return path consists of a single border node label.
図2のトポロジの別の例を考えてみましょう。このトポロジーは、ドメイン間に共通の境界ノードを持つマルチドメインIGPで構成されています。これは、マルチエリアまたはマルチレベルIGPまたは同じノードに展開されたIGPの複数のインスタンスで実現できます。このトポロジのリターンパス計算は、リターンパスが単一の境界ノードラベルで構成されていることを除いて、Multi-AS計算に似ています。
Let us consider the topology from Figure 1. Let us consider an SR Policy path built from PE1 to PE4 with the following label stack: N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4. PE1 begins traceroute procedures with the TTL set to 1 and includes [N-PE1] in the Reply Path TLV. The traceroute packet TTL expires on P1, and P1 processes the traceroute as per the procedures described in [RFC8029] and [RFC8287]. P1 sends an echo reply with the same Reply Path TLV with the Reply Path Return Code set to 6. The Return Code of the echo reply itself is set to the Return Code as per [RFC8029] and [RFC8287]. This traceroute doesn't need any changes to the Reply Path TLV until it leaves AS1. The same Reply Path TLV that is received may be included in the echo reply by P1 and P2, or no Reply Path TLV is included so that the head-end continues to use the same return path in the echo request that it used to send the previous echo request.
図1のトポロジを考えてみましょう。次のラベルスタックでPE1からPE4からPE4に構築されたSRポリシーパスを考えてみましょう：N-P1、N-ASBR1、EPE-ASBR1-ASBR4、N-PE4。PE1は、TTLが1に設定されたTRACEROUTE手順を開始し、Reply Path TLVに[n-Pe1]を含みます。TracerouteパケットTTLはP1で期限切れになり、P1は[RFC8029]および[RFC8287]で説明されている手順に従ってTracerouteを処理します。P1は、同じ応答パスTLVを使用してエコー応答を送信しますReply Path return Codeは6に設定されます。Echo応答自体の戻りコードは、[RFC8029]および[RFC8287]に従って戻りコードに設定されます。このTracerouteは、AS1を離れるまで、Reply Path TLVに変更を変更する必要はありません。受信された同じ応答パスTLVは、P1およびP2によるエコー応答に含まれる場合があります。または、ヘッドエンドがECHOリクエストで同じリターンパスを使用して使用したのと同じリターンパスを使用し続けるように、応答パスTLVが含まれていません。前のエコーリクエスト。
When ASBR1 receives the echo request, in the case it receives the Type-C/Type-D segment in the Reply Path TLV in the echo request, it converts that Type-C/Type-D segment to Type-A based on its own SRGB. When ASBR4 receives the echo request, it should form this Reply Path TLV using its Node-SID (N-ASBR4) and EPE-SID (EPE-ASRB4-ASBR1) labels and set the Reply Path Return Code to 0x0006. Then, PE1 should use this Reply Path TLV in subsequent echo requests. In this example, when the subsequent echo request reaches P3, it should use this Reply Path TLV for sending the echo reply. The same Reply Path TLV is sufficient for any router in AS2 to send the reply. This is because the first label (N-ASBR4) can direct the echo reply to ASBR4 and the second one (EPE-ASBR4-ASBR1) can direct the echo reply to AS1. Once the echo reply reaches AS1, normal IP forwarding or the N-PE1 helps it to reach PE1.
ASBR1がECHO要求を受信すると、ECHOリクエストのReply Path TLVでType-C/Type-Dセグメントを受信した場合、そのType-C/Type-Dセグメントをそれ自体に基づいてType-Aに変換しますSRGB。ASBR4がECHO要求を受信すると、ノード-SID（N-ASBR4）とEPE-SID（EPE-ASRB4-ASBR1）ラベルを使用してこの応答パスTLVを形成し、Reply Path Return Codeを0x0006に設定する必要があります。次に、PE1は後続のエコー要求でこの応答パスTLVを使用する必要があります。この例では、後続のエコー要求がP3に到達すると、この応答パスTLVを使用してエコー応答を送信する必要があります。同じ返信パスTLVでは、AS2のルーターが返信を送信するのに十分です。これは、最初のラベル（N-ASBR4）がASBR4へのエコー応答を指示し、2番目のラベル（EPE-ASBR4-ASBR1）がAS1にエコー応答を指示できるためです。エコー応答がAS1に達すると、通常のIP転送またはn-PE1はPE1に到達するのに役立ちます。
The example described in the above paragraphs can be extended to multiple ASes. This is done by following the same procedure for each ASBR, i.e., adding Node-SIDs and EPE-SIDs on receiving echo requests from neighboring ASes.
上記の段落で説明した例は、複数のASEに拡張できます。これは、各ASBRについて同じ手順に従って、つまり、近隣のASEからエコーリクエストを受信するためにノードSIDとEPE-SIDを追加することによって行われます。
Let us consider the topology from Figure 2. It consists of multiple IGP domains with multiple areas/levels or separate IGP instances. There is a single border node that separates the two domains. In this case, PE1 sends a traceroute packet with the TTL set to 1 and includes N-PE1 in the Reply Path TLV. ABR1 receives the echo request, adds its node label to the Reply Path TLV (while sending the echo reply), and sets the Reply Path Return Code to 0x0006. The Reply Path TLV in the echo reply from ABR1 consists of [N-ABR1, N-PE1]. The next echo request with a TTL of 2 reaches the P node. It is an internal node, so it does not change the return path. The echo request with a TTL of 3 reaches ABR2, and it adds its node label so the Reply Path TLV sent in the echo reply will be [N-ABR2, N-ABR1, N-PE1]. The echo request with a TTL of 4 reaches PE4, and it sends an echo reply Return Code as an egress. PE4 does not include any Reply Path TLVs in the echo reply. The above example assumes a uniform SRGB throughout the domain. In the case of different SRGBs, the top segment will be a Type-C/Type-D segment and all other segments will be Type-A. Each border node converts the Type-C/Type-D segment to Type-A before adding its segment to the Reply Path TLV.
図2のトポロジを考えてみましょう。複数の領域/レベルまたは個別のIGPインスタンスを持つ複数のIGPドメインで構成されています。2つのドメインを分離する単一の境界ノードがあります。この場合、PE1はTTLセットとTTLのパケットを1に送信し、Reply Path TLVにN-PE1を含みます。ABR1はエコー要求を受信し、ノードラベルをReply Path TLVに追加し（Echo Replyの送信中）、Reply Path Return Codeを0x0006に設定します。ABR1からのエコーの応答の応答パスTLVは、[n-abr1、n-pe1]で構成されています。2のTTLを使用した次のエコー要求は、Pノードに到達します。これは内部ノードなので、リターンパスを変更しません。3のTTLを使用したエコー要求はABR2に到達し、ノードラベルを追加して、エコー応答で送信される応答パスTLVが[n-abr2、n-abr1、n-pe1]になります。4のTTLを使用したエコー要求はPE4に到達し、エコー返信コードを出力として送信します。PE4には、エコー応答に返信パスTLVが含まれていません。上記の例は、ドメイン全体に均一なSRGBを想定しています。異なるSRGBの場合、上部セグメントはType-C/Type-Dセグメントになり、他のすべてのセグメントはType-Aになります。各ボーダーノードは、Reply Path TLVにセグメントを追加する前に、Type-C/Type-DセグメントをType-Aに変換します。
Thanks to Bruno Decraene for suggesting the use of the generic Segment sub-TLV. Thanks to Adrian Farrel, Huub van Helvoort, Dhruv Dhody, and Dongjie for their careful reviews and comments. Thanks to Mach Chen for suggesting the use of the Reply Path TLV. Thanks to Gregory Mirsky for the detailed review, which helped improve the readability of the document to a great extent.
ジェネリックセグメントSub-TLVの使用を提案してくれたBruno Decraeneに感謝します。Adrian Farrel、Huub Van Helvoort、Dhruv Dhody、およびDongjieの慎重なレビューとコメントに感謝します。Reply Path TLVの使用を提案してくれたMach Chenに感謝します。詳細なレビューをしてくれたGregory Mirskyに感謝します。これは、文書の読みやすさを大幅に向上させるのに役立ちました。
Carlos Pignataro
NC State University
Email: cpignata@gmail.com
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Shraddha Hegde
Juniper Networks, Inc.
Exora Business Park
Bangalore 560103
KA
India
Email: shraddha@juniper.net
Kapil Arora
Individual Contributor
Email: kapil.it@gmail.com
Mukul Srivastava
Juniper Networks, Inc.
Email: msri@juniper.net
Samson Ninan
Ciena
Email: samson.cse@gmail.com
Nagendra Kumar
Oracle
Email: nagendrakumar.nainar@gmail.com