RFC 8287 - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8287
タイトル : RFC 8287 - MPLSデータプレーンでのセグメントルーティング（SR）IGPプレフィックスおよびIGP隣接セグメント識別子（SID）のラベルスイッチドパス（LSP）Ping / Traceroute
翻訳編集 : 自動生成

[要約] RFC 8287は、セグメントルーティング（SR）IGPプレフィックスおよびIGP隣接セグメント識別子（SIDs）を使用したMPLSデータプレーンにおけるラベルスイッチパス（LSP）のPing/Tracerouteに関する仕様です。このRFCの目的は、SRネットワークにおいてLSPのパスを確認するための効果的な手法を提供することです。

Internet Engineering Task Force (IETF)                     N. Kumar, Ed.
Request for Comments: 8287                             C. Pignataro, Ed.
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                               G. Swallow
                                               Southend Technical Center
                                                                N. Akiya
                                                     Big Switch Networks
                                                                 S. Kini
                                                              Individual
                                                                 M. Chen
                                                                  Huawei
                                                           December 2017

Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes

MPLSデータプレーンでのセグメントルーティング（SR）IGPプレフィックスおよびIGP隣接セグメント識別子（SID）のラベルスイッチドパス（LSP）Ping / Traceroute

Abstract

概要

A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.

セグメントルーティング（SR）アーキテクチャは、ソースルーティングとトンネリングパラダイムを活用し、マルチプロトコルラベルスイッチング（MPLS）データプレーンの使用に直接適用できます。ノードは、パケットの先頭にSRヘッダーを付加することにより、「セグメント」と呼ばれる制御された一連の命令を通じてパケットを操作します。

The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.

SRのセグメント割り当てと転送のセマンティックの性質により、SRアーキテクチャ内のラベルスイッチドパス（LSP）の接続検証と障害分離に関する追加の考慮事項が発生します。このドキュメントは問題を説明し、MPLSデータプレーンでセグメントルーティングIGPプレフィックスとIGP隣接セグメント識別子（SID）のLSP PingとTracerouteを実行するための拡張機能を定義します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8287.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8287で入手できます。

著作権表示

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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Coexistence of SR-Capable and Non-SR-Capable Node
           Scenarios . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Challenges with Existing Mechanisms . . . . . . . . . . . . .   5
     4.1.  Path Validation in Segment Routing Networks . . . . . . .   5
   5.  Segment ID Sub-TLV  . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  IPv4 IGP-Prefix Segment ID  . . . . . . . . . . . . . . .   7
     5.2.  IPv6 IGP-Prefix Segment ID  . . . . . . . . . . . . . . .   8
     5.3.  IGP-Adjacency Segment ID  . . . . . . . . . . . . . . . .   9
   6.  Extension to Downstream Detailed Mapping TLV  . . . . . . . .  11
   7.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  FECs in Target FEC Stack TLV  . . . . . . . . . . . . . .  11
     7.2.  FEC Stack Change Sub-TLV  . . . . . . . . . . . . . . . .  12
     7.3.  Segment ID POP Operation  . . . . . . . . . . . . . . . .  13
     7.4.  Segment ID Check  . . . . . . . . . . . . . . . . . . . .  13
     7.5.  TTL Consideration for Traceroute  . . . . . . . . . . . .  19
   8.  Backward Compatibility with Non-SR Devices  . . . . . . . . .  19
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     9.1.  New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . .  20
     9.2.  Protocol in the Segment ID Sub-TLV  . . . . . . . . . . .  20
     9.3.  Adjacency Type in the IGP-Adjacency Segment ID  . . . . .  20
     9.4.  Protocol in the Label Stack Sub-TLV of the Downstream
           Detailed Mapping TLV  . . . . . . . . . . . . . . . . . .  21
     9.5.  Return Code . . . . . . . . . . . . . . . . . . . . . . .  21
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  21
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     11.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1. Introduction

1. はじめに

"Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" [RFC8029] defines a simple and efficient mechanism to detect data-plane failures in Label Switched Paths (LSPs) by specifying information to be carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation. Mechanisms for reliably sending the echo reply are defined. The functionality defined in [RFC8029] is modeled after the Ping/Traceroute paradigm (ICMP echo request [RFC792]) and is typically referred to as "LSP Ping" and "LSP Traceroute". [RFC8029] supports hierarchical and stitching LSPs.

「マルチプロトコルラベルスイッチド（MPLS）データプレーンの障害の検出」[RFC8029]は、MPLSの「エコー要求」と「で送信される情報を指定することにより、ラベルスイッチドパス（LSP）のデータプレーンの障害を検出するシンプルで効率的なメカニズムを定義します。障害の検出と分離を目的とした「エコー応答」。エコー応答を確実に送信するメカニズムが定義されています。 [RFC8029]で定義されている機能は、Ping / Tracerouteパラダイム（ICMPエコー要求[RFC792]）をモデルにしており、通常「LSP Ping」および「LSP Traceroute」と呼ばれています。 [RFC8029]は、LSPの階層化とステッチをサポートします。

[SR] introduces and describes an SR architecture that leverages the source routing and tunneling paradigms. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header. A detailed definition of the SR architecture is available in [SR].

[SR]は、ソースルーティングとトンネリングパラダイムを活用するSRアーキテクチャを紹介および説明しています。ノードは、パケットの先頭にSRヘッダーを付加することにより、「セグメント」と呼ばれる制御された一連の命令を通じてパケットを操作します。 SRアーキテクチャの詳細な定義は、[SR]にあります。

As described in [SR] and [SR-MPLS], the SR architecture can be directly applied to an MPLS data plane, the SID will be 20 bits, and the SR header is the label stack. Consequently, the mechanics of data-plane validation of [RFC8029] can be directly applied to SR MPLS.

[SR]と[SR-MPLS]で説明されているように、SRアーキテクチャはMPLSデータプレーンに直接適用でき、SIDは20ビットで、SRヘッダーはラベルスタックです。その結果、[RFC8029]のデータプレーン検証のメカニズムをSR MPLSに直接適用できます。

Unlike LDP or RSVP, which are the other well-known MPLS control plane protocols, the basis of Segment ID assignment in SR architecture is not always on a hop-by-hop basis. Depending on the type of Segment ID, the assignment can be unique to the node or within a domain.

他のよく知られたMPLSコントロールプレーンプロトコルであるLDPまたはRSVPとは異なり、SRアーキテクチャでのセグメントID割り当ての基礎は、必ずしもホップバイホップベースではありません。セグメントIDのタイプに応じて、割り当てはノードまたはドメイン内で一意にすることができます。

This nature of SR raises additional considerations for validation of fault detection and isolation in an SR network. This document illustrates the problem and describes a mechanism to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency SIDs within an MPLS data plane.

SRのこの性質により、SRネットワークでの障害検出と分離の検証に関する追加の考慮事項が発生します。このドキュメントでは、問題を説明し、MPLSデータプレーン内でセグメントルーティングIGPプレフィックスとIGP隣接SIDに対してLSP PingとTracerouteを実行するメカニズムについて説明します。

1.1. Coexistence of SR-Capable and Non-SR-Capable Node Scenarios

1.1. SR対応ノードシナリオとSR非対応ノードシナリオの共存

[INTEROP] describes how SR operates in a network where SR-capable and non-SR-capable nodes coexist. In such a network, one or more SR-based LSPs and non-SR-based LSPs are stitched together to achieve an end-to-end LSP. This is similar to a network where LDP and RSVP nodes coexist and the mechanism defined in Section 4.5.2 of [RFC8029] is applicable for LSP Ping and Trace.

[INTEROP]は、SR対応ノードと非SR対応ノードが共存するネットワークでSRがどのように動作するかを説明します。このようなネットワークでは、1つ以上のSRベースのLSPと非SRベースのLSPがつなぎ合わされて、エンドツーエンドのLSPが実現されます。これは、LDPノードとRSVPノードが共存するネットワークに似ており、[RFC8029]のセクション4.5.2で定義されたメカニズムがLSP PingおよびTraceに適用されます。

Section 8 of this document explains one of the potential gaps that is specific to SR-Capable and non-SR-capable node scenarios and explains how the existing mechanism defined in [RFC8029] handles it.

このドキュメントのセクション8では、SR対応およびSR非対応のノードシナリオに固有の潜在的なギャップの1つについて説明し、[RFC8029]で定義されている既存のメカニズムがそれを処理する方法について説明します。

2. Requirements Notation

2. 要件表記

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]で説明されているように解釈されます。

3. Terminology

3. 用語

This document uses the terminology defined in [SR] and [RFC8029]; readers are expected to be familiar with those terms.

このドキュメントでは、[SR]および[RFC8029]で定義されている用語を使用しています。読者はこれらの用語に精通していることが求められます。

4. Challenges with Existing Mechanisms

4. 既存のメカニズムの課題

The following example describes the challenges with using the current MPLS Operations, Administration, and Maintenance (OAM) mechanisms on an SR network.

次の例では、SRネットワークで現在のMPLS運用、管理、および保守（OAM）メカニズムを使用する場合の課題について説明します。

4.1. Path Validation in Segment Routing Networks

4.1. セグメントルーティングネットワークのパス検証

[RFC8029] defines the MPLS OAM mechanisms that help with fault detection and isolation for an MPLS data-plane path by the use of various Target Forwarding Equivalence Class (FEC) Stack sub-TLVs that are carried in MPLS echo request packets and used by the responder for FEC validation. While it is obvious that new sub-TLVs need to be assigned for SR, the unique nature of the SR architecture raises the need for additional operational considerations for path validation. This section discusses the challenges.

[RFC8029]は、MPLSエコー要求パケットで運ばれて使用されるさまざまなターゲット転送等価クラス（FEC）スタックサブTLVを使用することにより、MPLSデータプレーンパスの障害検出と分離に役立つMPLS OAMメカニズムを定義しますFEC検証の応答者。新しいサブTLVをSRに割り当てる必要があることは明らかですが、SRアーキテクチャの固有の性質により、パス検証のための追加の運用上の考慮事項が必要になります。このセクションでは、課題について説明します。

                        L1
                    +--------+
                    |   L2   |
                    R3-------R6
                   /           \
                  /             \
          R1----R2               R7----R8
                  \             /
                   \           /
                    R4-------R5

Figure 1: Segment Routing Network

図1：セグメントルーティングネットワーク

The Node Segment IDs for R1, R2, R3, R4, R5, R6, R7, and R8 are 5001, 5002, 5003, 5004, 5005, 5006, 5007, and 5008, respectively.

R1、R2、R3、R4、R5、R6、R7、およびR8のノードセグメントIDは、それぞれ5001、5002、5003、5004、5005、5006、5007、および5008です。

9136 --> Adjacency Segment ID from R3 to R6 over link L1. 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 9124 --> Adjacency segment ID from R2 to R4. 9123 --> Adjacency Segment ID from R2 to R3.

9136->リンクL1を介したR3からR6への隣接セグメントID。 9236->リンクL2を介したR3からR6への隣接セグメントID。 9124-> R2からR4への隣接セグメントID。 9123-> R2からR3への隣接セグメントID。

The forwarding semantic of the Adjacency Segment ID is to pop the Segment ID and send the packet to a specific neighbor over a specific link. A malfunctioning node may forward packets using the Adjacency Segment ID to an incorrect neighbor or over an incorrect link. The exposed Segment ID (of an incorrectly forwarded Adjacency Segment ID) might still allow such a packet to reach the intended destination, even though the intended strict traversal was broken.

隣接セグメントIDの転送セマンティクスは、セグメントIDをポップし、特定のリンクを介して特定のネイバーにパケットを送信することです。誤動作しているノードは、隣接セグメントIDを使用してパケットを不正なネイバーに、または不正なリンクを介して転送する場合があります。（誤って転送された隣接セグメントIDの）公開されたセグメントIDは、意図された厳密なトラバーサルが破られた場合でも、そのようなパケットが意図された宛先に到達することを許可する可能性があります。

In the topology above, assume that R1 sends traffic with a segment stack as {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If the Adjacency Segment ID 9124 is misprogrammed in R2 to send the packet to R1 or R3, the packet may still be delivered to R8 (if the nodes are configured with the same SR Global Block (SRGB)) [SR] but not via the expected path.

上記のトポロジでは、R1が{9124、5008}のセグメントスタックでトラフィックを送信し、経路がR1-R2-R4-R5-R7-R8になると想定しています。隣接セグメントID 9124がR2で誤ってプログラムされてパケットがR1またはR3に送信される場合、パケットは引き続きR8に配信される可能性があります（ノードが同じSRグローバルブロック（SRGB）で構成されている場合）[SR]予想されるパス。

MPLS traceroute may help with detecting such a deviation in the above-mentioned scenario. However, in a different example, it may not be helpful, for example, if R3 forwards a packet with Adjacency Segment ID 9236 via link L1 (due to misprogramming) when it was expected to be forwarded over link L2.

MPLS tracerouteは、上記のシナリオでこのような逸脱を検出するのに役立ちます。ただし、別の例では、たとえば、リンクL2を介して転送されることが予期されていたときに、R3が隣接セグメントID 9236のパケットをリンクL1を介して（誤プログラミングにより）転送した場合、役に立たない場合があります。

5. Segment ID Sub-TLV

5. セグメントIDサブTLV

The format of the following Segment ID sub-TLVs follows the philosophy of the Target FEC Stack TLV carrying FECs corresponding to each label in the label stack. When operated with the procedures defined in [RFC8029], this allows LSP Ping/Traceroute operations to function when the Target FEC Stack TLV contains more FECs than received label stacks at the responder nodes.

次のセグメントIDサブTLVのフォーマットは、ラベルスタック内の各ラベルに対応するFECを運ぶターゲットFECスタックTLVの哲学に従います。 [RFC8029]で定義された手順で操作すると、ターゲットFECスタックTLVに応答ノードで受信したラベルスタックよりも多くのFECが含まれている場合、LSP Ping / Traceroute操作が機能します。

Three new sub-TLVs are defined for the Target FEC Stack TLV (Type 1), the Reverse-Path Target FEC Stack TLV (Type 16), and the Reply Path TLV (Type 21).

ターゲットFECスタックTLV（タイプ1）、リバースパスターゲットFECスタックTLV（タイプ16）、および応答パスTLV（タイプ21）に対して、3つの新しいサブTLVが定義されています。

           Sub-Type    Sub-TLV Name
           --------  ---------------
             34      IPv4 IGP-Prefix Segment ID
             35      IPv6 IGP-Prefix Segment ID
             36      IGP-Adjacency Segment ID

See Section 9.2 for the registry for the Protocol field specified within these sub-TLVs.

これらのサブTLV内で指定されたプロトコルフィールドのレジストリについては、セクション9.2を参照してください。

5.1. IPv4 IGP-Prefix Segment ID

5.1. IPv4 IGPプレフィックスセグメントID

The IPv4 IGP-Prefix Segment ID is defined in [SR]. The format is as specified below:

IPv4 IGP-PrefixセグメントIDは[SR]で定義されています。形式は次のとおりです。

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         IPv4 Prefix                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Prefix Length  |    Protocol   |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4 Prefix

IPv4プレフィックス

This field carries the IPv4 Prefix to which the Segment ID is assigned. In case of an Anycast Segment ID, this field will carry the IPv4 Anycast address. If the prefix is shorter than 32 bits, trailing bits SHOULD be set to zero.

このフィールドには、セグメントIDが割り当てられているIPv4プレフィックスが含まれます。エニーキャストセグメントIDの場合、このフィールドにはIPv4エニーキャストアドレスが含まれます。プレフィックスが32ビットより短い場合、後続ビットはゼロに設定する必要があります（SHOULD）。

Prefix Length

プレフィックス長

The Prefix Length field is one octet. It gives the length of the prefix in bits (values can be 1-32).

Prefix Lengthフィールドは1オクテットです。プレフィックスの長さをビット単位で示します（値は1〜32にすることができます）。

Protocol

プロトコル

This field is set to 1, if the responder MUST perform FEC validation using OSPF as the IGP protocol. Set to 2, if the responder MUST perform Egress FEC validation using the Intermediate System to Intermediate System (IS-IS) as the IGP protocol. Set to 0, if the responder can use any IGP protocol for Egress FEC validation.

応答側がIGPプロトコルとしてOSPFを使用してFEC検証を実行する必要がある場合、このフィールドは1に設定されます。レスポンダーがIGPプロトコルとして中間システム間（IS-IS）を使用して出力FEC検証を実行する必要がある場合は、2に設定します。レスポンダが出力FEC検証に任意のIGPプロトコルを使用できる場合は、0に設定します。

Reserved

予約済み

The Reserved field MUST be set to 0 when sent and MUST be ignored on receipt.

予約フィールドは送信時に0に設定する必要があり、受信時には無視する必要があります。

5.2. IPv6 IGP-Prefix Segment ID

5.2. IPv6 IGPプレフィックスセグメントID

The IPv6 IGP-Prefix Segment ID is defined in [SR]. The format is as specified below:

IPv6 IGP-PrefixセグメントIDは[SR]で定義されています。形式は次のとおりです。

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         IPv6 Prefix                           |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Prefix Length  |    Protocol   |              Reserved         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 Prefix

IPv6プレフィックス

This field carries the IPv6 prefix to which the Segment ID is assigned. In case of an Anycast Segment ID, this field will carry the IPv4 Anycast address. If the prefix is shorter than 128 bits, trailing bits SHOULD be set to zero.

このフィールドには、セグメントIDが割り当てられているIPv6プレフィックスが含まれます。エニーキャストセグメントIDの場合、このフィールドにはIPv4エニーキャストアドレスが含まれます。プレフィックスが128ビットより短い場合、後続ビットはゼロに設定する必要があります（SHOULD）。

Prefix Length

プレフィックス長

The Prefix Length field is one octet, it gives the length of the prefix in bits (values can be 1-128).

プレフィックス長フィールドは1オクテットで、プレフィックスの長さをビット単位で示します（値は1〜128です）。

Protocol

プロトコル

Set to 1 if the responder MUST perform FEC validation using OSPF as the IGP protocol. Set to 2 if the responder MUST perform Egress FEC validation using IS-IS as the IGP protocol. Set to 0 if the responder can use any IGP protocol for Egress FEC validation.

レスポンダがIGPプロトコルとしてOSPFを使用してFEC検証を実行する必要がある場合は、1に設定します。レスポンダがIGPプロトコルとしてIS-ISを使用して出力FEC検証を実行する必要がある場合は、2に設定します。レスポンダが出力FEC検証に任意のIGPプロトコルを使用できる場合は、0に設定します。

Reserved

予約済み

MUST be set to 0 on send and MUST be ignored on receipt.

送信時には0に設定する必要があり、受信時には無視する必要があります。

5.3. IGP-Adjacency Segment ID

5.3. IGP隣接セグメントID

This sub-TLV is applicable for any IGP-Adjacency defined in [SR]. The format is as specified below:

このサブTLVは、[SR]で定義されているすべてのIGP隣接に適用できます。形式は次のとおりです。

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Adj. Type   |    Protocol   |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     |               Local Interface ID (4 or 16 octets)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     |              Remote Interface ID (4 or 16 octets)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     |          Advertising Node Identifier (4 or 6 octets)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     |           Receiving Node Identifier (4 or 6 octets)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Adj. Type (Adjacency Type)

調整。タイプ（隣接タイプ）

Set to 1 when the Adjacency Segment is a Parallel Adjacency as defined in [SR]. Set to 4 when the Adjacency Segment is IPv4 based and is not a Parallel Adjacency. Set to 6 when the Adjacency Segment is IPv6 based and is not a Parallel Adjacency. Set to 0 when the Adjacency Segment is over an unnumbered interface.

隣接セグメントが[SR]で定義されている並列隣接である場合、1に設定されます。隣接セグメントがIPv4ベースで、並列隣接ではない場合は、4に設定します。隣接セグメントがIPv6ベースであり、並列隣接ではない場合は、6に設定します。隣接セグメントが番号なしインターフェース上にある場合は0に設定します。

Protocol

プロトコル

Reserved

予約済み

MUST be set to 0 on send and MUST be ignored on receipt.

送信時には0に設定する必要があり、受信時には無視する必要があります。

Local Interface ID

ローカルインターフェイスID

An identifier that is assigned by the local Label Switching Router (LSR) for a link to which the Adjacency Segment ID is bound. This field is set to a local link address (IPv4 or IPv6). For IPv4, this field is 4 octets; for IPv6, this field is 16 octets. If unnumbered, this field is 4 octets and includes a 32-bit link identifier as defined in [RFC4203] and [RFC5307]. If the Adjacency Segment ID represents Parallel Adjacencies [SR], this field is 4 octets and MUST be set to 4 octets of zeroes.

隣接セグメントIDがバインドされているリンクのローカルラベルスイッチングルーター（LSR）によって割り当てられる識別子。このフィールドは、ローカルリンクアドレス（IPv4またはIPv6）に設定されます。 IPv4の場合、このフィールドは4オクテットです。 IPv6の場合、このフィールドは16オクテットです。番号なしの場合、このフィールドは4オクテットであり、[RFC4203]および[RFC5307]で定義されている32ビットのリンク識別子が含まれます。隣接セグメントIDが並列隣接[SR]を表す場合、このフィールドは4オクテットであり、ゼロの4オクテットに設定する必要があります。

Remote Interface ID

リモートインターフェイスID

An identifier that is assigned by the remote LSR for a link on which the Adjacency Segment ID is bound. This field is set to the remote (downstream neighbor) link address (IPv4 or IPv6). For IPv4, this field is 4 octets; for IPv6, this field is 16 octets. If unnumbered, this field is 4 octets and includes a 32-bit link identifier as defined in [RFC4203] and [RFC5307]. If the Adjacency Segment ID represents Parallel Adjacencies [SR], this field is 4 octets and MUST be set to 4 octets of zeroes.

隣接セグメントIDがバインドされているリンクに対してリモートLSRによって割り当てられる識別子。このフィールドは、リモート（ダウンストリームネイバー）リンクアドレス（IPv4またはIPv6）に設定されます。 IPv4の場合、このフィールドは4オクテットです。 IPv6の場合、このフィールドは16オクテットです。番号なしの場合、このフィールドは4オクテットであり、[RFC4203]および[RFC5307]で定義されている32ビットのリンク識別子が含まれます。隣接セグメントIDが並列隣接[SR]を表す場合、このフィールドは4オクテットであり、ゼロの4オクテットに設定する必要があります。

Advertising Node Identifier

広告ノード識別子

This specifies the Advertising Node Identifier. When the Protocol field is set to 1, then this field is 4 octets and carries the 32-bit OSPF Router ID. If the Protocol field is set to 2, then this field is 6 octets and carries the 48-bit IS-IS System ID. If the Protocol field is set to 0, then this field is 4 octets and MUST be set to zero.

これは、広告ノード識別子を指定します。 Protocolフィールドが1に設定されている場合、このフィールドは4オクテットであり、32ビットのOSPFルーターIDを伝達します。プロトコルフィールドが2に設定されている場合、このフィールドは6オクテットであり、48ビットのIS-ISシステムIDを伝達します。プロトコルフィールドが0に設定されている場合、このフィールドは4オクテットであり、ゼロに設定する必要があります。

Receiving Node Identifier

受信ノード識別子

This specifies the downstream node identifier. When the Protocol field is set to 1, then this field is 4 octets and carries the 32-bit OSPF Router ID. If the Protocol field is set to 2, then this field is 6 octets and carries the 48-bit IS-IS System ID. If the Protocol field is set to 0, then this field is 4 octets and MUST be set to zero.

ダウンストリームノード識別子を指定します。 Protocolフィールドが1に設定されている場合、このフィールドは4オクテットであり、32ビットのOSPFルーターIDを伝達します。プロトコルフィールドが2に設定されている場合、このフィールドは6オクテットであり、48ビットのIS-ISシステムIDを伝達します。プロトコルフィールドが0に設定されている場合、このフィールドは4オクテットであり、ゼロに設定する必要があります。

6. Extension to Downstream Detailed Mapping TLV

6. ダウンストリーム詳細マッピングTLVの拡張

In an echo reply, the Downstream Detailed Mapping TLV [RFC8029] is used to report for each interface over which a FEC could be forwarded. For a FEC, there are multiple protocols that may be used to distribute label mapping. The Protocol field of the Downstream Detailed Mapping TLV is used to return the protocol that is used to distribute the label carried in the Downstream Label field. The following protocols are defined in [RFC8029]:

エコー応答では、ダウンストリーム詳細マッピングTLV [RFC8029]を使用して、FECを転送できる各インターフェイスについて報告します。 FECの場合、ラベルマッピングの配布に使用できる複数のプロトコルがあります。ダウンストリーム詳細マッピングTLVのプロトコルフィールドは、ダウンストリームラベルフィールドで運ばれるラベルを配布するために使用されるプロトコルを返すために使用されます。以下のプロトコルは[RFC8029]で定義されています：

      Protocol #        Signaling Protocol
      ----------        ------------------
        0               Unknown
        1               Static
        2               BGP
        3               LDP
        4               RSVP-TE

With SR, OSPF or IS-IS can be used for label distribution. This document adds two new protocols as follows:

SRでは、OSPFまたはIS-ISをラベル配布に使用できます。このドキュメントでは、次の2つの新しいプロトコルを追加しています。

      Protocol #        Signaling Protocol
      ----------        ------------------
        5               OSPF
        6               IS-IS

See Section 9.4.

セクション9.4を参照してください。

7. Procedures

7. 手続き

This section describes aspects of LSP Ping and Traceroute operations that require further considerations beyond [RFC8029].

このセクションでは、[RFC8029]を超えてさらに検討する必要があるLSP PingおよびTraceroute操作の側面について説明します。

7.1. FECs in Target FEC Stack TLV

7.1. ターゲットFECスタックTLVのFEC

When LSP echo request packets are generated by an initiator, FECs carried in the Target FEC Stack TLV may need to differ to support an SR architecture. The following defines the Target FEC Stack TLV construction mechanics by an initiator for SR scenarios.

LSPエコー要求パケットがイニシエーターによって生成される場合、ターゲットFECスタックTLVで伝送されるFECは、SRアーキテクチャをサポートするために異なる必要がある場合があります。以下は、SRシナリオのイニシエーターによるターゲットFECスタックTLV構築メカニズムを定義しています。

Ping

ping

The initiator MUST include FEC(s) corresponding to the destination segment.

イニシエーターは、宛先セグメントに対応するFECを含める必要があります。

The initiator MAY include FECs corresponding to some or all of the segments imposed in the label stack by the initiator to communicate the segments traversed.

イニシエーターは、トラバースされたセグメントを通信するために、イニシエーターによってラベルスタックに課されたセグメントの一部またはすべてに対応するFECを含めることができます。

Traceroute

トレースルート

The initiator MUST initially include FECs corresponding to all segments imposed in the label stack.

イニシエーターは、最初にラベルスタックに課されたすべてのセグメントに対応するFECを含める必要があります。

When a received echo reply contains the FEC Stack Change TLV with one or more of the original segments being popped, the initiator MAY remove a corresponding FEC(s) from the Target FEC Stack TLV in the next (TTL+1) traceroute request, as defined in Section 4.6 of [RFC8029].

受信したエコー応答に、1つ以上の元のセグメントがポップされたFECスタック変更TLVが含まれている場合、イニシエーターは、次の（TTL + 1）traceroute要求で、対応するFECをターゲットFECスタックTLVから削除できます（MAY）。 [RFC8029]のセクション4.6で定義されています。

When a received echo reply does not contain the FEC Stack Change TLV, the initiator MUST NOT attempt to remove any FECs from the Target FEC Stack TLV in the next (TTL+1) traceroute request.

受信したエコー応答にFECスタック変更TLVが含まれていない場合、イニシエーターは次の（TTL + 1）traceroute要求でターゲットFECスタックTLVからFECを削除してはなりません（MUST NOT）。

As defined in [SR-OSPF] and [SR-IS-IS], the Prefix SID can be advertised as an absolute value, an index, or as a range. In any of these cases, the initiator MUST derive the Prefix mapped to the Prefix SID and use it in the IGP-Prefix Segment ID defined in Sections 5.1 and 5.2. How the responder uses the details in the SR-FEC sub-TLV to perform the validation is a local implementation matter.

[SR-OSPF]および[SR-IS-IS]で定義されているように、プレフィックスSIDは、絶対値、インデックス、または範囲としてアドバタイズできます。これらのいずれの場合でも、イニシエーターは、プレフィックスSIDにマップされたプレフィックスを導出し、セクション5.1および5.2で定義されたIGPプレフィックスセグメントIDで使用する必要があります。レスポンダがSR-FECサブTLVの詳細を使用して検証を実行する方法は、ローカル実装の問題です。

7.2. FEC Stack Change Sub-TLV

7.2. FECスタック変更サブTLV

[RFC8029] defines a FEC Stack Change sub-TLV that a router must include when the FEC stack changes.

[RFC8029]は、FECスタックが変更されたときにルーターに含める必要があるFECスタック変更サブTLVを定義します。

The network node that advertised the Node Segment ID is responsible for generating a FEC Stack Change sub-TLV with the Post Office Protocol (POP) operation type for the Node Segment ID, regardless of whether or not Penultimate Hop Popping (PHP) is enabled.

ノードセグメントIDをアドバタイズしたネットワークノードは、Penultimate Hop Popping（PHP）が有効かどうかに関係なく、ノードセグメントIDのPOP（Post Office Protocol）オペレーションタイプでFECスタック変更サブTLVを生成します。

The network node that is immediately downstream of the node that advertised the Adjacency Segment ID is responsible for generating the FEC Stack Change sub-TLV for POP operation for the Adjacency Segment ID.

隣接セグメントIDをアドバタイズしたノードのすぐ下流にあるネットワークノードは、隣接セグメントIDのPOP操作用のFECスタック変更サブTLVを生成する責任があります。

7.3. Segment ID POP Operation

7.3. セグメントID POP操作

The forwarding semantic of the Node Segment ID with the PHP flag is equivalent to usage of Implicit Null in MPLS protocols. The Adjacency Segment ID is also similar in a sense that it can be thought of as a locally allocated segment that has PHP enabled when destined for the next-hop IGP Adjacency Node. Procedures described in Section 4.4 of [RFC8029] rely on the Stack-D and Stack-R explicitly having the Implicit Null value. Implementations SHOULD use the Implicit Null for the Node Segment ID PHP and Adjacency Segment ID PHP cases.

PHPフラグを使用したノードセグメントIDの転送セマンティクスは、MPLSプロトコルでの暗黙的ヌルの使用と同等です。隣接セグメントIDも、ネクストホップIGP隣接ノードを宛先とする場合にPHPが有効になっているローカルに割り当てられたセグメントと考えることができるという意味で似ています。 [RFC8029]のセクション4.4で説明されている手順は、Stack-DおよびStack-Rが明示的にImplicit Null値を持つことに依存しています。実装では、ノードセグメントIDのPHPおよび隣接セグメントIDのPHPの場合に暗黙的ヌルを使用する必要があります（SHOULD）。

7.4. Segment ID Check

7.4. セグメントIDチェック

This section modifies the procedure defined in Section 4.4.1 of [RFC8029]. Step 4 defined in Section 4.4.1 of [RFC8029] is modified as below:

このセクションでは、[RFC8029]のセクション4.4.1で定義されている手順を変更します。 [RFC8029]のセクション4.4.1で定義されているステップ4は、次のように変更されています。

4. If the label mapping for FEC is Implicit Null, set the FEC-status to 2 and proceed to step 4a. Otherwise, if the label mapping for FEC is Label-L, proceed to step 4a. Otherwise, set the FEC-return-code to 10 ("Mapping for this FEC is not the given label at stack-depth"), set the FEC-status to 1, and return.

4. FECのラベルマッピングがImplicit Nullの場合、FECステータスを2に設定して、ステップ4aに進みます。それ以外の場合、FECのラベルマッピングがLabel-Lの場合は、ステップ4aに進みます。それ以外の場合は、FEC-return-codeを10に設定し（「このFECのマッピングはスタック深度で指定されたラベルではありません」）、FECステータスを1に設定して戻ります。

4a. Segment Routing IGP-Prefix and IGP-Adjacency SID Validation:

4a。セグメントルーティングIGPプレフィックスとIGP隣接SIDの検証：

If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), {

Label-stack-depthが0で、FEC-stack-depthのターゲットFECスタックサブTLVが34（IPv4 IGP-PrefixセグメントID）の場合、{

Set the Best-return-code to 10, "Mapping for this FEC is not the given label at stack-depth <RSC>" if any below conditions fail:

以下のいずれかの条件が満たされない場合、Best-return-codeを10に設定します。「このFECのマッピングは、スタック深度<RSC>で指定されたラベルではありません」

            /* The responder LSR is to check if it is the egress of the
            IPv4 IGP-Prefix Segment ID described in the Target FEC Stack
            sub-TLV, and if the FEC was advertised with the PHP bit
            set.*/

- Validate that the Node Segment ID is advertised for the IPv4 Prefix by IGP Protocol {

- ノードセグメントIDがIGPプロトコルによってIPv4プレフィックスにアドバタイズされていることを確認します{

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 0, use any locally enabled IGP protocol.

o 受信したIPv4 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが0の場合、ローカルで有効になっているIGPプロトコルを使用します。

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 1, use OSPF as the IGP protocol.

o 受信したIPv4 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが1の場合、IGPプロトコルとしてOSPFを使用します。

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.

o 受信したIPv4 IGP-PrefixセグメントIDサブTLVのプロトコルフィールドが2の場合、IS-ISをIGPプロトコルとして使用します。

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.

o 受信したIPv4 IGP-PrefixセグメントIDサブTLVのプロトコルフィールドが認識されない値である場合、プロトコル値0として扱われる必要があります。

}

｝

- Validate that the Node Segment ID is advertised with the No-PHP flag. {

- ノードセグメントIDがNo-PHPフラグでアドバタイズされていることを確認します。 {

o When the Protocol is OSPF, the NP-Flag defined in Section 5 of [SR-OSPF] MUST be set to 0.

o プロトコルがOSPFの場合、[SR-OSPF]のセクション5で定義されたNP-Flagを0に設定する必要があります。

o When the Protocol is IS-IS, the P-Flag defined in Section 6.1 of [SR-IS-IS] MUST be set to 0.

o プロトコルがIS-ISの場合、[SR-IS-IS]のセクション6.1で定義されているPフラグを0に設定する必要があります。

}

｝

If it can be determined that no protocol associated with the Interface-I would have advertised the FEC-Type at FEC-stack-depth, set the Best-return-code to 12, "Protocol not associated with interface at FEC-stack-depth" and return.

Interface-Iに関連付けられているプロトコルがFEC-stack-depthでFEC-Typeをアドバタイズしていないと判断できる場合は、Best-return-codeを12に設定します。「プロトコルはFEC-stack-depthのインターフェイスに関連付けられていません" そして戻る。

Set FEC-Status to 1 and return.

FEC-Statusを1に設定して戻ります。

}

｝

Else, if the Label-stack-depth is greater than 0 and the Target FEC Stack sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), {

それ以外の場合、Label-stack-depthが0より大きく、FEC-stack-depthでのターゲットFEC Stack sub-TLVが34（IPv4 IGP-Prefix Segment ID）の場合、{

Set the Best-return-code to 10 if any below conditions fail:

以下のいずれかの条件が満たされない場合は、Best-return-codeを10に設定します。

- Validate that the Node Segment ID is advertised for the IPv4 Prefix by the IGP protocol {

- ノードセグメントIDがIGPプロトコルによってIPv4プレフィックスにアドバタイズされていることを検証します{