Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 9658 Individual
Updates: 7307 M. Mishra, Ed.
Category: Standards Track K. Raza
ISSN: 2070-1721 Cisco Systems, Inc.
Z. Zhang
Juniper Networks
A. Gulko
Edward Jones
October 2024
Multi-Topology Routing (MTR) is a technology that enables service differentiation within an IP network. The Flexible Algorithm (FA) is another mechanism for creating a sub-topology within a topology using defined topology constraints and computation algorithms. In order to deploy Multipoint LDP (mLDP) in a network that supports MTR, FA, or other methods of signaling non-default IGP Algorithms (IPAs), mLDP is required to become topology and algorithm aware. This document specifies extensions to mLDP to support the use of MTR/IPAs such that, when building multipoint Label Switched Paths (LSPs), the LSPs can follow a particular topology and algorithm. This document updates RFC 7307 by allocating eight bits from a previously reserved field to be used as the "IPA" field.
マルチトポロジールーティング（MTR）は、IPネットワーク内でのサービス差別化を可能にするテクノロジーです。柔軟なアルゴリズム（FA）は、定義されたトポロジの制約と計算アルゴリズムを使用して、トポロジ内にサブトポロジーを作成するためのもう1つのメカニズムです。MTR、FA、またはシグナリング非デフォルトIGPアルゴリズム（IPAS）をサポートするネットワークにマルチポイントLDP（MLDP）を展開するには、MLDPがトポロジとアルゴリズムを認識するために必要です。このドキュメントは、MTR/IPAの使用をサポートするためにMLDPへの拡張機能を指定し、マルチポイントラベルスイッチドパス（LSP）を構築するときに、LSPが特定のトポロジとアルゴリズムに従うことができるようにします。このドキュメントは、「IPA」フィールドとして使用される以前に予約済みのフィールドから8ビットを割り当てることにより、RFC 7307を更新します。
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/rfc9658.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9658で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
2.1. Abbreviations
2.2. Specification of Requirements
3. MT-Scoped mLDP FECs
3.1. MP FEC Extensions for MT
3.1.1. MP FEC Element
3.1.2. MT IP Address Families
3.1.3. MT MP FEC Element
3.2. Topology IDs
4. MT Multipoint Capability
5. MT Applicability on FEC-Based Features
5.1. Typed Wildcard MP FEC Elements
5.2. End-of-LIB
6. Topology-Scoped Signaling and Forwarding
6.1. Upstream LSR Selection
6.2. Downstream Forwarding Interface Selection
7. LSP Ping Extensions
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Contributors
Acknowledgments
Authors' Addresses
Multi-Topology Routing (MTR) is a technology that enables service differentiation within an IP network. IGPs (e.g., OSPF and IS-IS) and LDP have already been extended to support MTR. To support MTR, an IGP maintains distinct IP topologies referred to as "Multi-Topologies" (or "MTs"), and computes and installs routes specific to each topology. OSPF extensions (see [RFC4915]) and IS-IS extensions (see [RFC5120]) specify the MT extensions under respective IGPs. To support IGP MT, similar LDP extensions (see [RFC7307]) have been specified to make LDP be MT aware and to be able to set up unicast Label Switched Paths (LSPs) along IGP MT routing paths.
マルチトポロジールーティング（MTR）は、IPネットワーク内でのサービス差別化を可能にするテクノロジーです。IGPS（例：OSPFおよびIS-IS）およびLDPは、MTRをサポートするためにすでに拡張されています。MTRをサポートするために、IGPは「マルチトポロジー」（または「MTS」）と呼ばれる個別のIPトポロジを維持し、各トポロジに固有のルートを計算およびインストールします。OSPF拡張機能（[RFC4915]を参照）およびIS-IS拡張機能（[RFC5120を参照]を参照）は、それぞれのIGPSの下でMT拡張機能を指定します。IGP MTをサポートするために、同様のLDP拡張機能（[RFC7307]を参照）が指定されており、LDPをMTに認識させ、IGP MTルーティングパスに沿ってユニキャストラベルスイッチ付きパス（LSP）をセットアップできるようにしています。
A more lightweight mechanism to define constraint-based topologies is the Flexible Algorithm (FA) (see [RFC9350]). The FA is another mechanism for creating a sub-topology within a topology using defined topology constraints and computation algorithms. This can be done within an MTR topology or the default topology. An instance of such a sub-topology is identified by a 1-octet value (Flexible Algorithm) as documented in [RFC9350]. At the time of writing, an FA is a mechanism to create a sub-topology; in the future, different algorithms might be defined for this purpose. Therefore, in the remainder of this document, we'll refer to this as the "IGP Algorithm" or "IPA". The "IPA" field (see Sections 3.1.2 and 5.1) is an 8-bit identifier for the algorithm. The permissible values are tracked in the "IGP Algorithm Types" registry [IANA-IGP].
制約ベースのトポロジを定義するためのより軽量のメカニズムは、柔軟なアルゴリズム（FA）です（[RFC9350]を参照）。FAは、定義されたトポロジの制約と計算アルゴリズムを使用して、トポロジ内にサブトポロジーを作成するためのもう1つのメカニズムです。これは、MTRトポロジまたはデフォルトトポロジ内で実行できます。このようなサブトポロジーのインスタンスは、[RFC9350]で文書化されているように、1-OCTET値（フレキシブルアルゴリズム）によって識別されます。執筆時点では、FAはサブトポロジーを作成するメカニズムです。将来的には、この目的のために異なるアルゴリズムが定義される可能性があります。したがって、このドキュメントの残りの部分では、これを「IGPアルゴリズム」または「IPA」と呼びます。「IPA」フィールド（セクション3.1.2および5.1を参照）は、アルゴリズムの8ビット識別子です。許容値は、「IGPアルゴリズムタイプ」レジストリ[IANA-IGP]で追跡されます。
Throughout this document, the term "Flexible Algorithm" (or "FA") shall denote the process of generating a sub-topology and signaling it through the IGP. However, it is essential to note that the procedures outlined in this document are not exclusively applicable to the FA: they are extendable to any non-default algorithm as well.
このドキュメント全体で、「柔軟なアルゴリズム」（または「FA」）という用語は、サブトポロジーを生成し、IGPを介してそれをシグナル化するプロセスを示します。ただし、このドキュメントで概説されている手順はFAにのみ適用されないことに注意することが不可欠です。これらは、非デフォルトアルゴリズムにも拡張可能です。
"Multipoint LDP" (or "mLDP") refers to extensions in LDP to set up multipoint LSPs (i.e., point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) LSPs) by means of a set of extensions and procedures defined in [RFC6388]. In order to deploy mLDP in a network that supports MTR and the FA, mLDP is required to become topology and algorithm aware. This document specifies extensions to mLDP to support the use of MTR/IPAs such that, when building multipoint LSPs, it can follow a particular topology and algorithm. Therefore, the identifier for the particular topology to be used by mLDP has to become a 2-tuple {MTR Topology Id, IPA}.
「Multipoint LDP」（または「MLDP」）は、LDPの拡張機能を指し、マルチポイントLSP（つまり、ポイントツーマルチポイント（P2MP）またはマルチポイントツーマルチポイント（MP2MP）LSP）をセットし、拡張機能を意味し、[RFC6388]で定義されている手順。MTRとFAをサポートするネットワークにMLDPを展開するには、MLDPがトポロジとアルゴリズムの認識になるために必要です。このドキュメントは、MTR/IPAの使用をサポートするためにMLDPへの拡張機能を指定し、マルチポイントLSPを構築するときに特定のトポロジとアルゴリズムに従うことができます。したがって、MLDPが使用する特定のトポロジの識別子は、2タプル{MTRトポロジID、IPA}になる必要があります。
FA:
FA:
Flexible Algorithm
柔軟なアルゴリズム
FEC:
FEC:
Forwarding Equivalence Class
等価クラスを転送します
IGP:
IGP:
Interior Gateway Protocol
インテリアゲートウェイプロトコル
IPA:
IPA:
IGP Algorithm
IGPアルゴリズム
LDP:
LDP:
Label Distribution Protocol
ラベル分布プロトコル
LSP:
LSP:
Label Switched Path
ラベルスイッチ付きパス
mLDP:
MLDP：
Multipoint LDP
マルチポイントLDP
MP:
MP:
Multipoint
マルチポイント
MP2MP:
MP2MP：
Multipoint-to-Multipoint
Multipoint-to-Multipoint
MT:
MT:
Multi-Topology
多国管科
MT-ID:
MT-ID：
Multi-Topology Identifier
マルチトポロジ識別子
MTR:
MTR:
Multi-Topology Routing
マルチトポロジールーティング
MVPN:
MVPN：
Multicast VPN in Section 2.3 of [RFC6513]
[RFC6513]のセクション2.3のマルチキャストVPN
P2MP:
P2MP：
Point-to-Multipoint
ポイントツーマルチポイント
PMSI:
PMSI：
Provider Multicast Service Interfaces [RFC6513]
プロバイダーマルチキャストサービスインターフェイス[RFC6513]
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]で説明されているように解釈されます。
As defined in [RFC7307], an MPLS Multi-Topology Identifier (MT-ID) is used to associate an LSP with a certain MTR topology. In the context of MP LSPs, this identifier is part of the mLDP FEC encoding; this is so that LDP peers are able to set up an MP LSP via their own defined MTR policy. In order to avoid conflicting MTR policies for the same mLDP FEC, the MT-ID needs to be a part of the FEC. This ensures that different MT-ID values will result in unique MP-LSP FEC elements.
[RFC7307]で定義されているように、MPLSマルチトポロジ識別子（MT-ID）を使用して、LSPを特定のMTRトポロジに関連付けます。MP LSPのコンテキストでは、この識別子はMLDP FECエンコーディングの一部です。これは、LDPピアが独自の定義されたMTRポリシーを介してMP LSPを設定できるようにするためです。同じMLDP FECの矛盾するMTRポリシーを避けるために、MT-IDはFECの一部である必要があります。これにより、異なるMT-ID値が一意のMP-LSP FEC要素をもたらすことが保証されます。
The same applies to the IPA. The IPA needs to be encoded as part of the mLDP FEC to create unique MP LSPs. The IPA is also used to signal to the mLDP (hop-by-hop) which algorithm needs to be used to create the MP LSP.
同じことがIPAにも当てはまります。IPAは、一意のMP LSPを作成するために、MLDP FECの一部としてエンコードする必要があります。IPAは、MLDP（ホップバイホップ）に信号を送るためにも使用されます。これは、MP LSPを作成するために使用する必要があります。
Since the MT-ID and IPA are part of the FEC, they apply to all the LDP messages that potentially include an mLDP FEC element.
MT-IDとIPAはFECの一部であるため、MLDP FEC要素を潜在的に含むすべてのLDPメッセージに適用します。
The following subsections define the extensions to bind an mLDP FEC to a topology. These mLDP MT extensions reuse some of the extensions specified in [RFC7307].
次のサブセクションでは、MLDP FECをトポロジに結合するための拡張機能を定義します。これらのMLDP MT拡張は、[RFC7307]で指定された拡張機能の一部を再利用します。
The base mLDP specification ([RFC6388]) defines the MP FEC element as follows:
ベースMLDP仕様（[RFC6388]）は、MP FEC要素を次のように定義します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP FEC type | Address Family | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MP FEC Element Format
図1：MP FEC要素形式
Where the "Root Node Address" field encoding is defined according to the given "Address Family" field with its length (in octets) specified by the "AF Length" field.
「ルートノードアドレス」フィールドエンコーディングは、「AFの長さ」フィールドで指定されたその長さ（オクテット）の指定された「アドレスファミリ」フィールドに従って定義されます。
To extend MP FEC elements for MT, the {MT-ID, IPA} tuple is relevant in the context of the root address of the MP LSP. This tuple determines the (sub-)topology in which the root address needs to be resolved. As the {MT-ID, IPA} tuple should be considered part of the mLDP FEC, it is most naturally encoded as part of the root address.
MTのMP FEC要素を拡張するために、{MT-ID、IPA}タプルは、MP LSPのルートアドレスのコンテキストに関連しています。このタプルは、ルートアドレスを解決する必要がある（サブ）トポロジを決定します。{mt-id、ipa}タプルはMLDP FECの一部と見なされるべきであるため、ルートアドレスの一部として最も自然にエンコードされます。
[RFC7307] specifies new address families, named "MT IP" and "MT IPv6," to allow for the specification of an IP prefix within a topology scope. In addition to using these address families for mLDP, 8 bits of the 16-bit "Reserved" field that was described in RFC 7307 are utilized to encode the IPA. The resulting format of the data associated with these new address families is as follows:
[RFC7307]は、「MT IP」と「MT IPv6」という名前の新しいアドレスファミリを指定して、トポロジ範囲内のIPプレフィックスの仕様を可能にします。これらのアドレスファミリをMLDPに使用することに加えて、RFC 7307で説明された16ビットの「予約済み」フィールドの8ビットがIPAをエンコードするために利用されます。これらの新しいアドレスファミリに関連付けられたデータの結果の形式は次のとおりです。
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 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Modified Format for MT IP Address Families
図2：MT IPアドレスファミリの変更された形式
Where:
ただし：
IPv4 Address and IPv6 Address:
IPv4アドレスとIPv6アドレス：
An IP address corresponding to the "MT IP" and "MT IPv6" address families, respectively.
それぞれ「MT IP」と「MT IPv6」に対応するIPアドレスは、それぞれファミリをアドレス指定します。
IPA:
IPA:
The IGP Algorithm.
IGPアルゴリズム。
Reserved:
予約済み：
This 8-bit field MUST be zero on transmission and MUST be ignored on receipt.
この8ビットフィールドは、送信時にゼロでなければならず、受領時に無視する必要があります。
When using the extended "MT IP" address family, the resulting MT-Scoped MP FEC element should be encoded as follows:
拡張された「MT IP」アドレスファミリを使用する場合、結果のMTスコープMP FEC要素を次のようにエンコードする必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP FEC type | AF (MT IP/ MT IPv6) | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format for an IP MT-Scoped MP FEC Element
図3：IP MTスコープMP FEC要素のフォーマット
In the context of this document, the applicable LDP FECs for MT mLDP ([RFC6388]) include:
このドキュメントのコンテキストでは、MT MLDPに該当するLDP FEC（[RFC6388]）が含まれます。
* MP FEC elements:
* MP FEC要素：
- P2MP (type 0x6)
- P2MP（タイプ0x6）
- MP2MP-up (type 0x7)
- mp2mp-up（タイプ0x7）
- MP2MP-down (type 0x8)
- mp2mp-down（タイプ0x8）
* Typed Wildcard FEC Element (type 0x5 defined in [RFC5918])
* タイプ付きワイルドカードFEC要素（[RFC5918]で定義されたタイプ0x5）
In the case of the Typed Wildcard FEC Element, the FEC element type MUST be one of the MP FECs listed above.
タイプされたワイルドカードFEC要素の場合、FEC要素タイプは上記のMP FECの1つでなければなりません。
This specification allows the use of topology-scoped mLDP FECs in LDP labels and notification messages, as applicable.
この仕様により、LDPラベルでトポロジスコープされたMLDP FECを使用して、該当する場合に通知メッセージを使用できます。
[RFC6514] defines the PMSI tunnel attribute for MVPN and specifies that:
[RFC6514]は、MVPNのPMSIトンネル属性を定義し、次のことを指定します。
* when the Tunnel Type is set to mLDP P2MP LSP, the Tunnel Identifier is a P2MP FEC element, and
* トンネルタイプがMLDP P2MP LSPに設定されている場合、トンネル識別子はP2MP FEC要素であり、
* when the Tunnel Type is set to mLDP MP2MP LSP, the Tunnel Identifier is an MP2MP FEC element.
* トンネルタイプがMLDP MP2MP LSPに設定されている場合、トンネル識別子はMP2MP FEC要素です。
When the extension defined in this specification is in use, the IP MT-Scoped MP FEC element form of the respective FEC elements MUST be used in these two cases.
この仕様で定義されている拡張機能が使用されている場合、これら2つのケースでは、それぞれのFEC要素のIP MTスコープMP FEC要素形式を使用する必要があります。
This document assumes the same definitions and procedures associated with MPLS MT-ID as specified in [RFC7307].
このドキュメントでは、[RFC7307]で指定されているMPLS MT-IDに関連する同じ定義と手順を想定しています。
The "MT Multipoint" capability is a new LDP capability, defined in accordance with the LDP capability definition guidelines outlined in [RFC5561]. An mLDP speaker advertises this capability to its peers to announce its support for MTR and the procedures specified in this document. This capability MAY be sent either in an Initialization message at session establishment or dynamically during the session's lifetime via a Capability message, provided that the "Dynamic Announcement" capability from [RFC5561] has been successfully negotiated with the peer.
「MT Multipoint」機能は、[RFC5561]で概説されているLDP機能定義ガイドラインに従って定義された新しいLDP機能です。MLDPスピーカーは、この機能を仲間に宣伝し、MTRのサポートとこのドキュメントで指定された手順を発表します。この機能は、[RFC5561]からの「ダイナミックアナウンス」機能がピアと正常に交渉されている場合、セッションの確立での初期化メッセージまたはセッションの寿命の間に動的に送信される場合があります。
The format of this capability is as follows:
この機能の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| MT Multipoint Capability | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 4: Format for the MT Multipoint Capability TLV
図4：MTマルチポイント機能TLVのフォーマット
Where:
ただし：
U and F bits:
uとfビット：
MUST be 1 and 0, respectively, as per Section 3 of [RFC5561].
[RFC5561]のセクション3に従って、それぞれ1と0でなければなりません。
MT Multipoint Capability:
MTマルチポイント機能：
The TLV type.
TLVタイプ。
Length:
長さ：
This field specifies the length of the TLV in octets. The value of this field MUST be 1, as there is no capability-specific data [RFC5561] following the TLV.
このフィールドは、オクテットのTLVの長さを指定します。TLVに続く機能固有のデータ[RFC5561]がないため、このフィールドの値は1でなければなりません。
S bit:
sビット：
Set to 1 to announce and 0 to withdraw the capability (as per [RFC5561]).
アナウンスを発表するために1に設定し、機能を撤回します（[RFC5561]に従って）。
An mLDP speaker that has successfully advertised and negotiated the "MT Multipoint" capability MUST support the following:
「MT Multipoint」機能を宣伝および交渉したMLDPスピーカーは、以下をサポートする必要があります。
1. Topology-scoped mLDP FECs in LDP messages (Section 3.1)
1. LDPメッセージのトポロジスコープMLDP FEC（セクション3.1）
2. Topology-scoped mLDP forwarding setup (Section 6)
2. トポロジスコープMLDP転送セットアップ（セクション6）
[RFC5918] extends the base LDP and defines the Typed Wildcard FEC Element framework. A Typed Wildcard FEC Element can be used in any LDP message to specify a wildcard operation for a given type of FEC.
[RFC5918]はベースLDPを拡張し、型付けされたワイルドカードFEC要素フレームワークを定義します。任意のLDPメッセージでタイプされたワイルドカードFEC要素を使用して、特定のタイプのFECのワイルドカード操作を指定できます。
The MT extensions defined in this document do not require any extension to procedures for support of the Typed Wildcard FEC Element [RFC5918], and these procedures apply as is to Multipoint MT FEC wildcarding. Similar to the Typed Wildcard MT Prefix FEC element, as defined in [RFC7307], the MT extensions allow the use of "MT IP" or "MT IPv6" in the "Address Family" field of the Typed Wildcard MP FEC Element. This is done in order to use wildcard operations for MP FECs in the context of a given (sub-)topology as identified by the "MT-ID" and "IPA" fields.
このドキュメントで定義されているMT拡張機能は、型付けされたワイルドカードFEC要素[RFC5918]をサポートするための手順への拡張を必要としません。これらの手順は、マルチポイントMT FECワイルドカードに適用されます。[RFC7307]で定義されているように、タイプされたWildCard MTプレフィックスFEC要素と同様に、MT拡張機能により、タイプ付きWildCard MP FEC要素の「アドレスファミリー」フィールドで「MT IP」または「MT IPv6」を使用できます。これは、「MT-ID」および「IPA」フィールドで識別されるように、特定の（サブ）トポロジのコンテキストでMP FECSのワイルドカード操作を使用するために行われます。
This document defines the following format and encoding for a Typed Wildcard MP FEC Element:
このドキュメントでは、タイプされたワイルドカードMP FEC要素の次の形式とエンコードを定義します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MT-ID (cont.) |
+-+-+-+-+-+-+-+-+
Figure 5: Format for the Typed Wildcard MT MP FEC Element
図5：タイプされたワイルドカードMT MP FEC要素のフォーマット
Where:
ただし：
Type:
タイプ：
One of the MP FEC element types (P2MP, MP2MP-up, or MP2MP-down)
MP FEC要素タイプの1つ（P2MP、MP2MP-Up、またはMP2MP-Down）
MT-ID:
MT-ID：
MPLS MT-ID
MPLS MT-ID
IPA:
IPA:
The IGP Algorithm
IGPアルゴリズム
The defined format allows a Label Switching Router (LSR) to perform wildcard MP FEC operations under the scope of a (sub-)topology.
定義された形式により、ラベルスイッチングルーター（LSR）が（サブ）トポロジの範囲でワイルドカードMP FEC操作を実行できるようになります。
[RFC5919] specifies extensions and procedures that allow an LDP speaker to signal its End-of-LIB (Label Information Base) for a given FEC type to a peer. By leveraging the End-of-LIB message, LDP ensures that label distribution remains consistent and reliable, even during network disruptions or maintenance activities. The MT extensions for MP FEC do not require any modifications to these procedures and apply as they are to MT MP FEC elements. Consequently, an MT mLDP speaker MAY signal its convergence per (sub-)topology using the MT Typed Wildcard MP FEC Element.
[RFC5919]は、LDPスピーカーが特定のFECタイプのLIB（ラベル情報ベース）をピアに合図できるようにする拡張機能と手順を指定します。LDPは、libの終わりのメッセージを活用することにより、ネットワークの破壊やメンテナンス活動中であっても、ラベル分布が一貫性と信頼性を維持することを保証します。MP FECのMT拡張機能は、これらの手順を変更する必要はなく、MT MP FEC要素に適用されます。したがって、MT MLDPスピーカーは、MTと型付けられたWildCard MP FEC要素を使用して、その収束を（サブ）トポロジーに合図する場合があります。
Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need to support the concept of multiple (sub-)topology forwarding tables in mLDP. Each MP LSP will be unique due to the tuple being part of the FEC. There is also no need to have specific label forwarding tables per topology, and each MP LSP will have its own unique local label in the table. However, in order to implement MTR in an mLDP network, the selection procedures for an upstream LSR and a downstream forwarding interface need to be changed.
{MT-ID、IPA} TupleはMLDP FECの一部であるため、MLDPの複数の（サブ）トポロジ転送テーブルの概念をサポートする必要はありません。TupleがFECの一部であるため、各MP LSPはユニークになります。また、トポロジごとに特定のラベル転送テーブルを持つ必要はなく、各MP LSPにはテーブルに独自のローカルラベルがあります。ただし、MLDPネットワークにMTRを実装するには、上流のLSRおよび下流の転送インターフェイスの選択手順を変更する必要があります。
The procedures described in Section 2.4.1.1 of [RFC6388] depend on the best path to reach the root. When the {MT-ID, IPA} tuple is signaled as part of the FEC, the tuple is also used to select the (sub-)topology that must be used to find the best path to the root address. Using the next-hop from this best path, an LDP peer is selected following the procedures defined in [RFC6388].
[RFC6388]のセクション2.4.1.1で説明されている手順は、ルートに到達するための最適なパスに依存します。{mt-id、ipa}タプルがFECの一部として信号を送られると、タプルはルートアドレスへの最適なパスを見つけるために使用する必要がある（サブ）トポロジを選択するためにも使用されます。この最高のパスから次のホップを使用して、[RFC6388]で定義されている手順に従ってLDPピアが選択されます。
Section 2.4.1.2 of [RFC6388] describes the procedures for how a downstream forwarding interface is selected. In these procedures, any interface leading to the downstream LDP neighbor can be considered to be a candidate forwarding interface. When the {MT-ID, IPA} tuple is part of the FEC, this is no longer true. An interface must only be selected if it is part of the same (sub-)topology that was signaled in the mLDP FEC element. Besides this restriction, the other procedures in [RFC6388] apply.
[RFC6388]のセクション2.4.1.2では、ダウンストリーム転送インターフェイスがどのように選択されるかについての手順について説明します。これらの手順では、下流のLDP隣人につながるインターフェイスは、候補者の転送インターフェイスと見なされます。{mt-id、ipa}タプルがFECの一部である場合、これはもはや真ではありません。インターフェイスは、MLDP FEC要素でシグナルとされた同じ（サブ）トポロジの一部である場合にのみ選択する必要があります。この制限に加えて、[RFC6388]の他の手順が適用されます。
[RFC6425] defines procedures to detect data plane failures in multipoint MPLS LSPs. Section 3.1.2 of [RFC6425] defines new sub-types and sub-TLVs for Multipoint LDP FECs to be sent in the "Target FEC Stack" TLV of an MPLS Echo Request message [RFC8029].
[RFC6425]マルチポイントMPLS LSPのデータ平面障害を検出する手順を定義します。[RFC6425]のセクション3.1.2は、MPLSエコーリクエストメッセージ[RFC8029]の「ターゲットFECスタック」TLVで送信されるマルチポイントLDP FECの新しいサブタイプとサブTLVを定義します。
To support LSP ping for MT MP LSPs, this document uses existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" defined in [RFC6425]. The LSP ping extension is to specify "MT IP" or "MT IPv6" in the "Address Family" field, set the "Address Length" field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV with additional {MT-ID, IPA} information as an extension to the "Root LSR Address" field. The resultant format of sub-TLV is as follows:
MT MP LSPのLSP Pingをサポートするために、このドキュメントでは、[RFC6425]で定義された既存のサブタイプ「P2MP LDP FECスタック」および「MP2MP LDP FECスタック」を使用します。LSP Ping拡張は、「アドレスファミリ」フィールドで「MT IP」または「MT IPv6」を指定し、「アドレス長」フィールドを8（MT IPの場合）または20（MT IPv6の場合）に設定し、サブをエンコードすることです。「ルートLSRアドレス」フィールドへの拡張機能として、追加の{mt-id、ipa}情報を備えたtlv。サブTLVの結果の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Address Family (MT IP/MT IPv6) | Address Length| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Root LSR Address (Cont.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT
図6：MT MTのマルチポイントLDP FECスタックサブTLV形式
The rules and procedures of using this new sub-TLV in an MPLS Echo Request message are the same as defined for the P2MP/MP2MP LDP FEC Stack sub-TLV in [RFC6425]. The only difference is that the "Root LSR Address" field is now (sub-)topology scoped.
この新しいサブTLVをMPLSエコーリクエストメッセージで使用するルールと手順は、[RFC6425]のP2MP/MP2MP LDP FECスタックSub-TLVで定義されていると同じです。唯一の違いは、「ルートLSRアドレス」フィールドが現在（サブ）トポロジーがスコープされていることです。
This extension to mLDP does not introduce any new security considerations beyond what is already applied to the base LDP specification [RFC5036], the LDP extensions for Multi-Topology specification [RFC7307], the base mLDP specification [RFC6388], and the MPLS security framework specification [RFC5920].
このMLDPへの拡張は、基本LDP仕様[RFC5036]、マルチトポロジー仕様のLDP拡張[RFC7307]、ベースMLDP仕様[RFC6388]、およびMPLSセキュリティフレームワークに既に適用されているものを超えて、新しいセキュリティ上の考慮事項を導入しません。仕様[RFC5920]。
This document defines a new LDP capability parameter TLV called the "MT Multipoint Capability". IANA has assigned the value 0x0510 from the "TLV Type Name Space" registry in the "Label Distribution Protocol (LDP) Parameters" group as the new code point.
このドキュメントでは、「MTマルチポイント機能」と呼ばれる新しいLDP機能パラメーターTLVを定義します。IANAは、新しいコードポイントとして「ラベル分布プロトコル（LDP）パラメーター」グループに「TLV Type Name Space」レジストリから値0x0510を割り当てました。
+========+===============+===========+=========================+
| Value | Description | Reference | Notes/Registration Date |
+========+===============+===========+=========================+
| 0x0510 | MT Multipoint | RFC 9658 | |
| | Capability | | |
+--------+---------------+-----------+-------------------------+
Table 1: MT Multipoint Capability
表1：MTマルチポイント機能
[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>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<https://www.rfc-editor.org/info/rfc6425>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
King, "LDP Extensions for Multi-Topology", RFC 7307,
DOI 10.17487/RFC7307, July 2014,
<https://www.rfc-editor.org/info/rfc7307>.
[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>.
[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>.
[IANA-IGP] IANA, "IGP Algorithm Types",
<https://www.iana.org/assignments/igp-parameters>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561,
DOI 10.17487/RFC5561, July 2009,
<https://www.rfc-editor.org/info/rfc5561>.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution
Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
(FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010,
<https://www.rfc-editor.org/info/rfc5918>.
[RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
"Signaling LDP Label Advertisement Completion", RFC 5919,
DOI 10.17487/RFC5919, August 2010,
<https://www.rfc-editor.org/info/rfc5919>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
Anuj Budhiraja
Cisco Systems
The authors would like to acknowledge Eric Rosen for his input on this specification.
著者は、この仕様に関する彼の意見について、エリック・ローゼンに認めたいと思います。
IJsbrand Wijnands
Individual
Email: ice@braindump.be
Mankamana Mishra (editor)
Cisco Systems, Inc.
821 Alder Drive
Milpitas, CA 95035
United States of America
Email: mankamis@cisco.com
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive
Kanata ON K2K-3E8
Canada
Email: skraza@cisco.com
Zhaohui Zhang
Juniper Networks
10 Technology Park Dr.
Westford, MA 01886
United States of America
Email: zzhang@juniper.net
Arkadiy Gulko
Edward Jones Wealth Management
United States of America
Email: Arkadiy.gulko@edwardjones.com