[要約] RFC 7307は、LDP（Label Distribution Protocol）の拡張機能であるMulti-Topologyに関するものです。このRFCの目的は、LDPを複数のトポロジで使用するための拡張機能を提供することです。
Internet Engineering Task Force (IETF) Q. Zhao
Request for Comments: 7307 Huawei Technology
Category: Standards Track K. Raza
ISSN: 2070-1721 C. Zhou
Cisco Systems
L. Fang
Microsoft
L. Li
China Mobile
D. King
Old Dog Consulting
July 2014
LDP Extensions for Multi-Topology
マルチトポロジ用のLDP拡張
Abstract
概要
Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks, new extensions are required.
マルチトポロジ（MT）ルーティングは、MT対応のIGPを使用するIPネットワークでサポートされます。マルチプロトコルラベルスイッチング（MPLS）ラベル配布プロトコル（LDP）ネットワーク内でMTルーティングを提供するには、新しい拡張機能が必要です。
This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.
このドキュメントでは、MPLS環境でMTルーティングをサポートするために必要なLDPプロトコル拡張について説明します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7307.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7307で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Signaling Extensions ............................................5
3.1. Topology-Scoped Forwarding Equivalence Class (FEC) .........5
3.2. New Address Families: MT IP ................................5
3.3. LDP FEC Elements with MT IP AF .............................6
3.4. IGP MT-ID Mapping and Translation ..........................7
3.5. LDP MT Capability Advertisement ............................7
3.5.1. Protocol Extension ..................................7
3.5.2. Procedures ..........................................9
3.6. Label Spaces ..............................................10
3.7. Reserved MT-ID Values .....................................10
4. MT Applicability on FEC-Based Features .........................10
4.1. Typed Wildcard FEC Element ................................10
4.2. Signaling LDP Label Advertisement Completion ..............11
4.3. LSP Ping ..................................................11
4.3.1. New FEC Sub-Types ..................................11
4.3.2. MT LDP IPv4 FEC Sub-TLV ............................12
4.3.3. MT LDP IPv6 FEC Sub-TLV ............................13
4.3.4. Operation Considerations ...........................13
5. Error Handling .................................................14
5.1. MT Error Notification for Invalid Topology ID .............14
6. Backwards Compatibility ........................................14
7. MPLS Forwarding in MT ..........................................14
8. Security Considerations ........................................14
9. IANA Considerations ............................................15
10. Manageability Considerations ..................................17
10.1. Control of Function and Policy ...........................17
10.2. Information and Data Models ..............................17
10.3. Liveness Detection and Monitoring ........................17
10.4. Verify Correct Operations ................................17
10.5. Requirements on Other Protocols ..........................17
10.6. Impact on Network Operations .............................17
11. Contributors ..................................................18
12. Acknowledgements ..............................................19
13. References ....................................................19
13.1. Normative References .....................................19
13.2. Informative References ...................................19
Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. It would be advantageous for Communications Service Providers (CSPs) to support an MPLS Multi-Topology (MPLS-MT) environment. The benefits of MPLS-MT technology are features for various network scenarios, including:
マルチトポロジ（MT）ルーティングは、MT対応のIGPを使用するIPネットワークでサポートされます。通信サービスプロバイダー（CSP）がMPLSマルチトポロジ（MPLS-MT）環境をサポートすることは有利です。 MPLS-MTテクノロジーの利点は、次のようなさまざまなネットワークシナリオに対応する機能です。
o A CSP may want to assign varying Quality of Service (QoS) profiles to different traffic classes, based on a specific topology in an MT routing network;
o CSPは、MTルーティングネットワークの特定のトポロジに基づいて、さまざまなサービスクラス（QoS）プロファイルをさまざまなトラフィッククラスに割り当てたい場合があります。
o Separate routing and MPLS domains may be used to isolate multicast and IPv6 islands within the backbone network;
o 個別のルーティングドメインとMPLSドメインを使用して、バックボーンネットワーク内のマルチキャストアイランドとIPv6アイランドを分離できます。
o Specific IP address space could be routed across an MT based on security or operational isolation requirements;
o セキュリティまたは運用上の分離要件に基づいて、特定のIPアドレス空間をMT全体にルーティングできます。
o Low-latency links could be assigned to an MT for delay-sensitive traffic;
o 低遅延リンクは、遅延の影響を受けやすいトラフィックのMTに割り当てることができます。
o Management traffic may be divided from customer traffic using different MTs utilizing separate links, thus ensuring that management traffic is separated from customer traffic.
o 管理トラフィックは、別々のリンクを利用するさまざまなMTを使用して顧客トラフィックから分割されるため、管理トラフィックが顧客トラフィックから確実に分離されます。
This document describes the Label Distribution Protocol (LDP) procedures and protocol extensions required to support MT routing in an MPLS environment.
このドキュメントでは、MPLS環境でMTルーティングをサポートするために必要なラベル配布プロトコル（LDP）の手順とプロトコル拡張について説明します。
This document defines two new Forwarding Equivalence Class (FEC) types for use in Label Switched Path (LSP) ping [RFC4379].
このドキュメントは、ラベルスイッチドパス（LSP）ping [RFC4379]で使用するための2つの新しいForwarding Equivalence Class（FEC）タイプを定義します。
This document uses MPLS terminology defined in [RFC5036]. Additional terms are defined below:
このドキュメントでは、[RFC5036]で定義されているMPLS用語を使用しています。追加の用語を以下に定義します。
o MT-ID: A 16-bit value used to represent the Multi-Topology ID.
o MT-ID：マルチトポロジIDを表すために使用される16ビット値。
o Default MT Topology: A topology that is built using the MT-ID default value of 0.
o デフォルトのMTトポロジ：MT-IDのデフォルト値0を使用して構築されたトポロジ。
o MT Topology: A topology that is built using the corresponding MT-ID.
o MTトポロジ：対応するMT-IDを使用して構築されるトポロジ。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
LDP assigns and binds a label to a FEC, where a FEC is a list of one or more FEC elements. To set up LSPs for unicast IP routing paths, LDP assigns local labels for IP prefixes and advertises these labels to its peers so that an LSP is set up along the routing path. To set up MT LSPs for IP prefixes under a given topology scope, the LDP prefix-related FEC element must be extended to include topology information. This implies that the MT-ID becomes an attribute of the prefix-related FEC element, and all FEC-Label binding operations are performed under the context of a given topology (MT-ID).
LDPはラベルをFECに割り当ててバインドします。FECは1つ以上のFEC要素のリストです。 LSPをユニキャストIPルーティングパスに設定するために、LDPはIPプレフィックスにローカルラベルを割り当て、これらのラベルをピアにアドバタイズして、LSPがルーティングパスに沿って設定されるようにします。特定のトポロジスコープでIPプレフィックスのMT LSPを設定するには、トポロジ情報を含めるようにLDPプレフィックス関連のFEC要素を拡張する必要があります。これは、MT-IDがプレフィックス関連のFEC要素の属性になり、すべてのFEC-Labelバインディング操作が特定のトポロジ（MT-ID）のコンテキストで実行されることを意味します。
The following section ("New Address Families: MT IP") defines the extension required to bind the prefix-related FEC to a topology.
次のセクション（「新しいアドレスファミリ：MT IP」）では、プレフィックス関連のFECをトポロジにバインドするために必要な拡張機能を定義しています。
Section 2.1 of the LDP base specification [RFC5036] defines the Address Prefix FEC element. The Prefix encoding is defined for a given "Address Family" (AF), and has length (in bits) specified by the "PreLen" field.
LDP基本仕様[RFC5036]のセクション2.1は、アドレスプレフィックスFEC要素を定義しています。プレフィックスエンコーディングは、特定の「アドレスファミリ」（AF）に対して定義され、「PreLen」フィールドで指定された長さ（ビット単位）を持っています。
To extend IP address families for MT, two new Address Families named "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes within a topology scope.
MTのIPアドレスファミリを拡張するために、「MT IP」および「MT IPv6」という2つの新しいアドレスファミリを使用して、トポロジスコープ内のIPv4およびIPv6プレフィックスを指定します。
The format of data associated with these new Address Families is described below:
これらの新しい住所ファミリに関連付けられているデータの形式を以下に示します。
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 | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MT IP Address Family Format
図1：MT IPアドレスファミリの形式
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 | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MT IPv6 Address Family Format
図2：MT IPv6アドレスファミリフォーマット
Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and "MT IPv6" AF respectively, and the field "MT-ID" corresponds to the 16-bit Topology ID for a given address.
ここで、「IPアドレス」は「MT IP」および「MT IPv6」AFのIPv4およびIPv6アドレス/プレフィックスであり、フィールド「MT-ID」は特定のアドレスの16ビットトポロジIDに対応します。
The definition and usage for the remaining fields in the FEC elements are as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to the default topology and MUST be ignored on receipt so as to not cause any conflict/confusion with existing non-MT procedures.
FEC要素の残りのフィールドの定義と使用法は、IP / IPv6 AFで定義されているとおりです。 MT-ID 0の値はデフォルトトポロジに対応し、既存の非MTプロシージャとの競合/混乱を引き起こさないように、受信時に無視する必要があります。
The defined FEC elements with "MT IP" Address Family can be used in any LDP message and procedures that currently specify and allow the use of FEC elements with IP/IPv6 Address Family.
「MT IP」アドレスファミリで定義されたFEC要素は、IP / IPv6アドレスファミリでFEC要素の使用を現在指定および許可している任意のLDPメッセージおよび手順で使用できます。
The following section specifies the format extensions of the existing LDP FEC elements to support MT. The "Address Family" of these FEC elements will be set to "MT IP" or "MT IPv6".
次のセクションでは、MTをサポートするための既存のLDP FEC要素のフォーマット拡張を指定します。これらのFEC要素の「アドレスファミリ」は「MT IP」または「MT IPv6」に設定されます。
The MT Prefix FEC element encoding is as follows:
MT Prefix 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MT Prefix FEC Element Format
図3：MTプレフィックスFEC要素の形式
The MT Typed Wildcard FEC element encoding is as follows:
MT Typed Wildcard 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)| FEC Type | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: MT Typed Wildcard FEC Element
図4：MTタイプのワイルドカードFEC要素
The above format can be used for any LDP FEC element that allows use of the IP/IPv6 Address Family. In the scope of this document, the allowed "FEC Type" in a MT Typed Wildcard FEC element is the Prefix FEC element.
上記のフォーマットは、IP / IPv6アドレスファミリの使用を許可する任意のLDP FEC要素に使用できます。このドキュメントの範囲では、MT Typed Wildcard FEC要素で許可される「FEC Type」はPrefix FEC要素です。
The non-reserved non-special IGP MT-ID values can be used and carried in LDP without the need for translation. However, there is a need for translating reserved or special IGP MT-ID values to corresponding LDP MT-IDs. The assigned, unassigned, and special LDP MT-ID values have been assigned as described in Section 9 ("IANA Considerations").
予約されていない特別なIGP MT-ID値は、変換の必要なしにLDPで使用および伝送できます。ただし、予約済みまたは特別なIGP MT-ID値を対応するLDP MT-IDに変換する必要があります。割り当てられた、割り当てられていない、および特別なLDP MT-ID値は、セクション9（「IANAの考慮事項」）の説明に従って割り当てられています。
How future LDP MT-ID values are allocated is outside the scope of this document. Instead, a separate document will be created to detail the allocation policy and process for requesting new MT-ID values.
将来のLDP MT-ID値がどのように割り当てられるかは、このドキュメントの範囲外です。代わりに、新しいMT-ID値を要求するための割り当てポリシーとプロセスの詳細を説明する別のドキュメントが作成されます。
We specify a new LDP capability, named "Multi-Topology (MT)", which is defined in accordance with the LDP capability guidelines [RFC5561]. The LDP "MT" capability can be advertised by an LDP speaker to its peers either during the LDP session initialization or after the LDP session is set up. The advertisement is to announce the capability of the Label Switching Router (LSR) to support MT for the given IP address family. An LDP speaker MUST NOT send messages containing MT FEC elements unless the peer has said it can handle it.
LDP機能ガイドライン[RFC5561]に従って定義された「マルチトポロジ（MT）」という新しいLDP機能を指定します。 LDP "MT"機能は、LDPセッションの初期化中またはLDPセッションのセットアップ後に、LDPスピーカーによってピアにアドバタイズできます。アドバタイズは、指定されたIPアドレスファミリのMTをサポートするラベルスイッチングルータ（LSR）の機能をアナウンスすることです。 LDPスピーカーは、ピアが処理できると言っていない限り、MT FEC要素を含むメッセージを送信してはなりません（MUST NOT）。
The MT capability is specified using the Multi-Topology Capability TLV. The Multi-Topology Capability TLV format is in accordance with the LDP capability guidelines as defined in [RFC5561]. To be able to specify IP address family, the capability-specific data (i.e., the "Capability Data" field of Capability TLV) is populated using the "Typed Wildcard FEC element" as defined in [RFC5918].
MT機能は、マルチトポロジ機能TLVを使用して指定されます。マルチトポロジ機能TLV形式は、[RFC5561]で定義されているLDP機能ガイドラインに準拠しています。 IPアドレスファミリを指定できるようにするために、[RFC5918]で定義されている「型付きワイルドカードFEC要素」を使用して、機能固有のデータ（つまり、機能TLVの「機能データ」フィールド）が入力されます。
The format of the Multi-Topology Capability TLV is as follows:
マルチトポロジ機能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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Multi-Topology Cap.(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ |
~ Typed Wildcard FEC element(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Multi-Topology Capability TLV Format
図5：マルチトポロジ機能TLV形式
Where:
ただし：
o U-bit: MUST be 1 so that the TLV will be silently ignored by a recipient if it is unknown, according to the rules of [RFC5036].
o Uビット：[RFC5036]のルールに従って、不明な場合にTLVが受信者によって黙って無視されるように、1にする必要があります。
o F-bit: MUST be 0 as per Section 3 ("Specifying Capabilities in LDP Messages") of LDP Capabilities [RFC5561].
o Fビット：LDP機能[RFC5561]のセクション3（「LDPメッセージでの機能の指定」）に従って0にする必要があります。
o Multi-Topology Capability: Capability TLV type (IANA assigned)
o マルチトポロジ機能：機能TLVタイプ（IANA割り当て）
o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be set to 0 or 1 in dynamic "Capability" message to advertise or withdraw the capability, respectively.
o Sビット：LDP「初期化」メッセージで使用される場合、1でなければなりません。機能をアドバタイズまたは撤回するために、動的な「機能」メッセージでそれぞれ0または1に設定される場合があります。
o Typed Wildcard FEC element(s): One or more elements specified as the "Capability data".
o 型付きワイルドカードFEC要素：「機能データ」として指定された1つ以上の要素。
o Length: length of Value field, starting from the S-bit, in octets.
o 長さ：オクテット単位の、Sビットから始まる値フィールドの長さ。
o The encoding of the Typed Wildcard FEC element, as defined in [RFC5918], is defined in Section 4.1 ("Typed Wildcard FEC element") of this document. The MT-ID field of the MT Typed Wildcard FEC element MUST be set to "Wildcard Topology" when it is specified in the MT Capability TLV.
o [RFC5918]で定義されている型付きワイルドカードFEC要素のエンコーディングは、このドキュメントのセクション4.1（「型付きワイルドカードFEC要素」）で定義されています。 MT Typed Wildcard FEC要素のMT-IDフィールドは、MT Capability TLVで指定されている場合、「Wildcard Topology」に設定する必要があります。
To announce its MT capability for an IP address family, LDP FEC type, and Multi-Topology, an LDP speaker sends an "MT Capability" including the exact Typed Wildcard FEC element with the corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., set to "Prefix"), and corresponding "MT-ID". To announce its MT capability for both the IPv4 and IPv6 address family, or for multiple FEC types, or for multiple Multi-Topologies, an LDP speaker sends an "MT Capability" with one or more MT Typed FEC elements in it.
LDPスピーカーは、IPアドレスファミリ、LDP FECタイプ、およびマルチトポロジのMT機能を発表するために、対応する「AddressFamily」フィールドを持つ正確なTyped Wildcard FEC要素を含む「MT Capability」を送信します（つまり、「MT IPv4の場合は「IP」、IPv6アドレスファミリの場合は「MT IPv6」に設定）、「FECタイプ」フィールド（「プレフィックス」に設定）、対応する「MT-ID」。 IPv4とIPv6の両方のアドレスファミリ、または複数のFECタイプ、または複数のマルチトポロジのMT機能をアナウンスするために、LDPスピーカーは1つ以上のMTタイプのFEC要素を含む「MT機能」を送信します。
o The capability for supporting multi-topology in LDP can be advertised during LDP session initialization stage by including the LDP MT capability TLV in LDP Initialization message. After an LDP session is established, the MT capability can also be advertised or withdrawn using the Capability message (only if the "Dynamic Capability Announcement" capability [RFC5561] has already been successfully negotiated).
o LDP初期化メッセージにLDP MT機能TLVを含めることにより、LDPセッション初期化段階でLDPのマルチトポロジをサポートする機能をアドバタイズできます。 LDPセッションが確立された後、機能メッセージを使用してMT機能をアドバタイズまたは撤回することもできます（「Dynamic Capability Announcement」機能[RFC5561]がすでに正常にネゴシエートされている場合のみ）。
o If an LSR has not advertised MT capability, its peer MUST NOT send to this LSR any LDP messages with FEC elements that include an MT identifier.
o LSRがMT機能を通知していない場合、そのピアは、MT識別子を含むFEC要素を持つLDPメッセージをこのLSRに送信してはなりません（MUST NOT）。
o If an LSR is changed from non-MT capable to MT capable, it sets the S-bit in the MT capability TLV and advertises via the Capability message (if it supports Dynamic Capability Announcement). The existing LSP is treated as an LSP for default MT (ID 0).
o LSRが非MT対応からMT対応に変更されると、MT機能TLVにSビットが設定され、機能メッセージを介して通知されます（動的機能通知をサポートしている場合）。既存のLSPは、デフォルトMT（ID 0）のLSPとして扱われます。
o If an LSR is changed from LDP-MT capable to non-MT capable, it initiates withdrawal of all label mapping for existing LSPs of all non-default MTs. It also cleans up all the LSPs of all non-default MTs locally. Then, it clears the S-bit in the MT capability TLV and advertises via the Capability message (if it supports Dynamic Capability Announcement). When an LSR knows the peer node is changed from LDP-MT capable to non-MT capable, it cleans up all the LSPs of all non-default MTs locally and initiates withdrawal of all label mapping for existing LSPs of all non-default MTs. Each side of the node sends a label release to its peer once it receives the label release messages even though each side has already cleaned up all the LSPs locally.
o LSRがLDP-MT対応から非MT対応に変更されると、デフォルト以外のすべてのMTの既存のLSPのすべてのラベルマッピングの撤回が開始されます。また、デフォルト以外のすべてのMTのすべてのLSPをローカルにクリーンアップします。次に、MT機能TLVのSビットをクリアし、機能メッセージを介して通知します（動的機能通知をサポートしている場合）。 LSRは、ピアノードがLDP-MT対応から非MT対応に変更されたことを認識すると、すべての非デフォルトMTのすべてのLSPをローカルでクリーンアップし、すべての非デフォルトMTの既存LSPのすべてのラベルマッピングの撤回を開始します。ノードの両側は、すでにすべてのLSPをローカルでクリーンアップしている場合でも、ラベル解放メッセージを受信すると、ピアにラベル解放を送信します。
o If an LSR does not support "Dynamic Capability Announcement", it MUST reset the session with its peer whenever the LSR changes its local capability with regards to supporting LDP MT.
o LSRが「Dynamic Capability Announcement」をサポートしない場合、LSRがLDP MTのサポートに関してローカル機能を変更するときはいつでも、ピアとのセッションをリセットする必要があります。
o If an LSR is changed from IGP-MT capable to non-MT capable, it may wait until the routes update to withdraw the FEC and release the label mapping for existing LSPs of a specific MT.
o LSRがIGP-MT対応から非MT対応に変更されると、ルートが更新されてFECが撤回され、特定のMTの既存のLSPのラベルマッピングが解放されるまで待機する場合があります。
The use of multiple topologies for LDP does not require different label spaces for each topology. An LSR can use the same label space for all MT FECs as for the default topology.
LDPに複数のトポロジを使用する場合、トポロジごとに異なるラベルスペースは必要ありません。 LSRは、デフォルトのトポロジと同じように、すべてのMT FECに同じラベルスペースを使用できます。
Similarly, signaling for different topologies can and should be done within a single LDP session.
同様に、異なるトポロジのシグナリングは、単一のLDPセッション内で実行できます。
Certain MT topologies are assigned to serve predetermined purposes.
特定のMTトポロジは、所定の目的を果たすために割り当てられます。
In Section 9 ("IANA Considerations"), this document defines a new IANA registry "MPLS Multi-Topology Identifiers" to keep LDP MT-ID reserved values.
セクション9（「IANAの考慮事項」）で、このドキュメントは、LDP MT-IDの予約値を維持するために、新しいIANAレジストリ「MPLSマルチトポロジ識別子」を定義しています。
If an LSR receives a FEC element with an "MT-ID" value that is "Unassigned" for future use (and not IANA allocated yet), the LSR MUST abort the processing of the FEC element and SHOULD send a notification message with status code "Invalid Topology ID" to the sender.
LSRが「MT-ID」値を持つFEC要素を受信し、将来の使用のために（まだIANAが割り当てられていない）場合、LSRはFEC要素の処理を中止しなければならず、ステータスコードを含む通知メッセージを送信する必要があります（SHOULD）。送信者への「無効なトポロジID」。
[RFC5918] extends base LDP and defines the Typed Wildcard FEC element framework. The Typed Wildcard FEC element can be used in any LDP message to specify a wildcard operation/action for a given type of FEC.
[RFC5918]はベースLDPを拡張し、型付きワイルドカードFEC要素フレームワークを定義します。 Typed Wildcard FEC要素を任意のLDPメッセージで使用して、特定のタイプのFECのワイルドカード操作/アクションを指定できます。
The MT extensions defined in this document do not require any extension to procedures for the Typed Wildcard FEC element, and these procedures apply as is to MT wildcarding. The MT extensions, though, allow use of "MT IP" or "MT IPv6" in the Address Family field of the Typed Wildcard FEC element in order to use wildcard operations in the context of a given topology. The use of MT-scoped address family also allows us to specify MT-ID in these operations.
このドキュメントで定義されているMT拡張機能では、Typed Wildcard FEC要素の手順を拡張する必要はなく、これらの手順はMTワイルドカードにそのまま適用されます。ただし、MT拡張機能では、特定のトポロジのコンテキストでワイルドカード操作を使用するために、型付きワイルドカードFEC要素のアドレスファミリフィールドで「MT IP」または「MT IPv6」を使用できます。 MTスコープのアドレスファミリを使用すると、これらの操作でMT-IDを指定することもできます。
The defined format in Section 4.1 ("Typed Wildcard FEC element") allows an LSR to perform wildcard FEC operations under the scope of a topology. If an LSR wishes to perform a wildcard operation that applies to all topologies, it can use a "Wildcard Topology" MT-ID.
セクション4.1で定義された形式（「型付きワイルドカードFEC要素」）により、LSRはトポロジーのスコープの下でワイルドカードFEC操作を実行できます。 LSRがすべてのトポロジに適用されるワイルドカード操作を実行したい場合は、「ワイルドカードトポロジ」のMT-IDを使用できます。
For example, upon local de-configuration of a topology "x", an LSR may send a typed wildcard Label Withdraw message with MT-ID "x" to withdraw all its labels from the peer that advertised under the scope of topology "x". Additionally, upon a global configuration change, an LSR may send a typed wildcard Label Withdraw message with the MT-ID set to "Wildcard Topology" to withdraw all its labels under all topologies from the peer.
たとえば、トポロジ「x」のローカル構成解除時に、LSRはMT-ID「x」を含む型付きワイルドカードラベル撤回メッセージを送信して、トポロジ「x」のスコープでアドバタイズされたピアからすべてのラベルを撤回することができます。 。さらに、グローバル構成が変更されると、LSRは、MT-IDを「ワイルドカードトポロジ」に設定して、入力されたワイルドカードラベルウィズドローメッセージを送信して、すべてのトポロジーのすべてのラベルをピアから取り消す場合があります。
[RFC5919] specifies extensions and procedures for an LDP speaker to signal its convergence for a given FEC type towards a peer. The procedures defined in [RFC5919] apply as they are to an MT FEC element. This allows an LDP speaker to signal its IP convergence using Typed Wildcard FEC element, and its MT IP convergence per topology using a MT Typed Wildcard FEC element.
[RFC5919]は、LDPスピーカーが特定のFECタイプの収束をピアに通知するための拡張と手順を指定します。 [RFC5919]で定義されている手順は、MT FEC要素にそのまま適用されます。これにより、LDPスピーカーは、型付きワイルドカードFEC要素を使用してIPコンバージェンスと、MT型付きワイルドカードFEC要素を使用してトポロジごとにMT IPコンバージェンスを通知できます。
[RFC4379] defines procedures to detect data-plane failures in MPLS LSPs via LSP ping. That specification defines a "Target FEC Stack" TLV that describes the FEC stack being tested. This TLV is sent in an MPLS Echo Request message towards the LSP's egress LSR and is forwarded along the same data path as other packets belonging to the FEC.
[RFC4379]は、LSP pingを介してMPLS LSPのデータプレーン障害を検出する手順を定義しています。その仕様は、テストされているFECスタックを記述する「ターゲットFECスタック」TLVを定義しています。このTLVは、MPLSエコー要求メッセージでLSPの出力LSRに向けて送信され、FECに属する他のパケットと同じデータパスに沿って転送されます。
"Target FEC Stack" TLV contains one or more sub-TLVs pertaining to different FEC types. Section 3.2 of [RFC4379] defines the Sub-Types and format of the FEC. To support LSP ping for MT LDP LSPs, this document defines the following extensions to [RFC4379].
「ターゲットFECスタック」TLVには、さまざまなFECタイプに関連する1つ以上のサブTLVが含まれています。 [RFC4379]のセクション3.2は、FECのサブタイプとフォーマットを定義しています。 MT LDP LSPのLSP pingをサポートするために、このドキュメントでは[RFC4379]の次の拡張機能を定義しています。
We define two new FEC types for LSP ping:
LSP pingの2つの新しいFECタイプを定義します。
o MT LDP IPv4 FEC
o MT LDP IPv4 FEC
o MT LDP IPv6 FEC
o MT LDP IPv6 FEC
We also define the following new sub-types for sub-TLVs to specify these FECs in the "Target FEC Stack" TLV of [RFC4379]:
[RFC4379]の「Target FEC Stack」TLVでこれらのFECを指定するために、サブTLVに次の新しいサブタイプも定義します。
Sub-Type Length Value Field
-------- ------ -----------------
31 8 MT LDP IPv4 prefix
32 20 MT LDP IPv6 prefix
Figure 6: New Sub-Types for Sub-TLVs
図6：サブTLVの新しいサブタイプ
The rules and procedures of using these sub-TLVs in an MPLS echo request message are the same as defined for LDP IPv4/IPv6 FEC sub-TLV types in [RFC4379].
MPLSエコー要求メッセージでこれらのサブTLVを使用するルールと手順は、[RFC4379]でLDP IPv4 / IPv6 FECサブTLVタイプに対して定義されているものと同じです。
The format of the "MT LDP IPv4 FEC" sub-TLV to be used in a "Target FEC Stack" [RFC4379] is:
「ターゲットFECスタック」[RFC4379]で使用される「MT LDP IPv4 FEC」サブTLVのフォーマットは、次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 31 (MT LDP IPv4 FEC) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | MBZ | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: MT LDP IPv4 FEC Sub-TLV
図7：MT LDP IPv4 FECサブTLV
The format of this sub-TLV is similar to the LDP IPv4 FEC sub-TLV as defined in [RFC4379]. In addition to "IPv4 prefix" and "Prefix Length" fields, this new sub-TLV also specifies the MT-ID (Multi-Topology ID). The Length for this sub-TLV is 5.
このサブTLVのフォーマットは、[RFC4379]で定義されているLDP IPv4 FECサブTLVに似ています。 「IPv4プレフィックス」および「プレフィックス長」フィールドに加えて、この新しいサブTLVはMT-ID（マルチトポロジID）も指定します。このサブTLVの長さは5です。
The term "Must Be Zero" (MBZ) is used in object descriptions for reserved fields. These fields MUST be set to zero when sent and ignored on receipt.
「ゼロでなければならない」（MBZ）という用語は、予約フィールドのオブジェクトの説明で使用されます。これらのフィールドは送信時にゼロに設定し、受信時に無視する必要があります。
The format of the "MT LDP IPv6 FEC" sub-TLV to be used in a "Target FEC Stack" [RFC4379] is:
「ターゲットFECスタック」[RFC4379]で使用される「MT LDP IPv6 FEC」サブTLVのフォーマットは、次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32 (MT LDP IPv6 FEC) | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | MBZ | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MT LDP IPv6 FEC Sub-TLV
図8：MT LDP IPv6 FECサブTLV
The format of this sub-TLV is similar to the LDP IPv6 FEC sub-TLV as defined in [RFC4379]. In addition to the "IPv6 prefix" and "Prefix Length" fields, this new sub-TLV also specifies the MT-ID (Multi-Topology ID). The Length for this sub-TLV is 17.
このサブTLVのフォーマットは、[RFC4379]で定義されているLDP IPv6 FECサブTLVに似ています。 「IPv6プレフィックス」および「プレフィックス長」フィールドに加えて、この新しいサブTLVはMT-ID（マルチトポロジID）も指定します。このサブTLVの長さは17です。
To detect data-plane failures using LSP ping for a specific topology, the router will initiate an LSP ping request with the target FEC stack TLV containing the LDP MT IP Prefix Sub-TLV in the Echo Request packet. The Echo Request packet is sent with the label bound to the IP Prefix in the topology. Once the Echo Request packet reaches the target router, it will process the packet and perform checks for the LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described in [RFC4379] and respond according to the processing rules in [RFC4379]. For the case that the LSP ping with return path is not specified, the reply packet must go through the default topology instead of the topology where the Echo Request goes through.
特定のトポロジのLSP pingを使用してデータプレーンの障害を検出するために、ルータは、エコー要求パケットにLDP MT IPプレフィックスサブTLVを含むターゲットFECスタックTLVでLSP ping要求を開始します。エコー要求パケットは、トポロジのIPプレフィックスにバインドされたラベルとともに送信されます。エコー要求パケットがターゲットルータに到達すると、パケットを処理し、[RFC4379]で説明されているようにターゲットFECスタックに存在するLDP MT IPプレフィックスサブTLVのチェックを実行し、[RFC4379]の処理ルールに従って応答します。 。リターンパスを使用したLSP pingが指定されていない場合、応答パケットは、エコー要求が通過するトポロジではなく、デフォルトのトポロジを通過する必要があります。
It should be noted that the existing MIB modules for an MPLS LSR [RFC3813] and MPLS LDP managed objects [RFC3815] do not provide the necessary information to support the extensions in this document. For example, the absence of the MT-ID as an index into the MIB modules means that there is no way to disambiguate different topology instances.
MPLS LSR [RFC3813]およびMPLS LDP管理対象オブジェクト[RFC3815]の既存のMIBモジュールは、このドキュメントの拡張をサポートするために必要な情報を提供しないことに注意してください。たとえば、MIBモジュールへのインデックスとしてMT-IDがないことは、さまざまなトポロジインスタンスを明確にする方法がないことを意味します。
The extensions defined in this document utilize the existing LDP error handling defined in [RFC5036]. If an LSR receives an error notification from a peer for a session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all multi-topology label mappings learned via the session.
このドキュメントで定義されている拡張機能は、[RFC5036]で定義されている既存のLDPエラー処理を利用しています。 LSRは、セッションのピアからエラー通知を受信すると、そのセッションのTCPトランスポート接続を閉じ、そのセッションで学習したすべてのマルチトポロジラベルマッピングを破棄して、LDPセッションを終了します。
An LSR should respond with an "Invalid Topology ID" status code in the LDP Notification message when it receives an LDP message with a FEC element specifying an MT-ID that is not locally known or not supported. The LSR MUST also discard the entire message before sending the Notification message.
LSRは、ローカルで認識されていないかサポートされていないMT-IDを指定するFEC要素を含むLDPメッセージを受信すると、LDP通知メッセージ内の「無効なトポロジID」ステータスコードで応答する必要があります。 LSRは、通知メッセージを送信する前にメッセージ全体を破棄する必要もあります。
The MPLS-MT solution is backwards compatible with existing LDP enhancements defined in [RFC5036], including message authenticity, integrity of message, and topology loop detection.
MPLS-MTソリューションは、[RFC5036]で定義されている既存のLDP拡張機能と下位互換性があり、メッセージの信頼性、メッセージの整合性、トポロジーループの検出などがあります。
The legacy node that does not support MT should not receive any MT-related LDP messages. In case bad things happen, according to [RFC5036], processing of such messages should be aborted.
MTをサポートしないレガシーノードは、MT関連のLDPメッセージを受信しないようにする必要があります。悪いことが起こった場合、[RFC5036]によると、そのようなメッセージの処理は中止されるべきです。
Although forwarding is out of the scope of this document, we include some forwarding consideration for informational purposes here.
転送はこのドキュメントの範囲外ですが、ここでは情報目的で転送に関する考慮事項をいくつか含めます。
The specified signaling mechanisms allow all the topologies to share the platform-specific label space. This feature allows the existing data-plane techniques to be used. Also, there is no way for the data plane to associate a received packet with any one topology, meaning that topology-specific label spaces cannot be used.
指定されたシグナリングメカニズムにより、すべてのトポロジでプラットフォーム固有のラベルスペースを共有できます。この機能により、既存のデータプレーン技術を使用できます。また、データプレーンが受信パケットを1つのトポロジに関連付ける方法はありません。つまり、トポロジ固有のラベルスペースは使用できません。
The use of MT over existing MPLS solutions does not offer any specific security benefit.
既存のMPLSソリューションでMTを使用しても、特定のセキュリティ上の利点はありません。
General LDP communication security threats and how these may be mitigated are described in [RFC5036]; these threats include:
一般的なLDP通信セキュリティの脅威と、それらを軽減する方法については、[RFC5036]で説明されています。これらの脅威は次のとおりです。
o spoofing
o なりすまし
o privacy o denial of service
oプライバシーoサービス拒否
For further discussion regarding possible LDP communication threats and mitigation techniques, see [RFC5920].
考えられるLDP通信の脅威と軽減技術に関する詳細については、[RFC5920]を参照してください。
This document introduces the following new protocol elements, which have been assigned by IANA:
このドキュメントでは、IANAによって割り当てられた次の新しいプロトコル要素を紹介します。
o New LDP Capability TLV: "Multi-Topology Capability" TLV (0x050C) from the LDP Parameters registry "TLV Type Name Space".
o 新しいLDP機能TLV：LDPパラメータレジストリ「TLVタイプ名前空間」からの「マルチトポロジ機能」TLV（0x050C）。
o New Status Code: "Invalid Topology ID" (0x00000031) from the LDP Parameters registry "Status Code Name Space").
o 新しいステータスコード：LDPパラメータレジストリ「ステータスコード名前空間」からの「無効なトポロジID」（0x00000031））。
Registry:
Range/Value Description
-------------- ------------------------------
0x00000031 Invalid Topology ID
Figure 9: New Code Point for LDP Multi-Topology Extensions
図9：LDPマルチトポロジ拡張の新しいコードポイント
o New address families under the IANA registry "Address Family Numbers":
o IANAレジストリ「アドレスファミリ番号」の下の新しいアドレスファミリ：
Number Description
-------- ------------------------------------
29 MT IP: Multi-Topology IP version 4
30 MT IPv6: Multi-Topology IP version 6
Figure 10: Address Family Numbers
図10：アドレスファミリ番号
o New registry "MPLS Multi-Topology Identifiers".
o 新しいレジストリ「MPLSマルチトポロジ識別子」。
This is a registry of the "Multiprotocol Label Switching Architecture (MPLS)" category.
これは、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）」カテゴリのレジストリです。
The initial registrations and allocation policies for this registry are:
このレジストリの初期登録と割り当てポリシーは次のとおりです。
Range/Value Purpose Reference
----------- ------------------------------------- ----------
0 Default/standard topology RFC 7307
1 IPv4 in-band management RFC 7307
2 IPv6 routing topology RFC 7307
3 IPv4 multicast topology RFC 7307
4 IPv6 multicast topology RFC 7307
5 IPv6 in-band management RFC 7307
6-3995 Unassigned for future IGP topologies RFC 7307
Assigned by Standards Action RFC 7307
3996-4095 Experimental RFC 7307
4096-65534 Unassigned for MPLS topologies RFC 7307
Assigned by Standards Action
65535 Wildcard Topology RFC 7307
Figure 11: MPLS Multi-Topology Identifier Registry
図11：MPLSマルチトポロジIDレジストリ
o New Sub-TLV Types for LSP ping: The following new sub-type values under TLV type 1 (Target FEC Stack) have been registered from the "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry within the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry.
o LSP pingの新しいサブTLVタイプ：TLVタイプ1（ターゲットFECスタック）の下の次の新しいサブタイプ値は、「内のTLVタイプ1、16、および21のサブTLV」サブレジストリから登録されています。 Multi-Protocol Label Switching（MPLS）Label Switched Paths（LSPs）Ping Parameters "レジストリ。
Sub-Type Value Field
-------- ------------------
31 MT LDP IPv4 prefix
32 MT LDP IPv6 prefix
Figure 12: New Sub-TLV Types for LSP Ping
図12：LSP pingの新しいサブTLVタイプ
As highlighted at the end of Section 3.4 ("IGP MT-ID Mapping and Translation"), a new document will be created to detail the policy and process for allocating new MT-ID values.
セクション3.4（「IGP MT-IDマッピングおよび変換」）の最後で強調されているように、新しいドキュメントは、新しいMT-ID値を割り当てるためのポリシーとプロセスを詳述するために作成されます。
There are capabilities that should be configurable to enable good manageability. One such example is to allow that the LDP Multi-Topology capability be enabled or disabled. It is assumed that the mapping of the LDP MT-ID and IGP MT-ID is manually configured on every router by default. If an automatic mapping between IGP MT-IDs and LDP MT-IDs is needed, there must be explicit configuration to do so.
優れた管理性を実現するために構成可能でなければならない機能があります。そのような例の1つは、LDPマルチトポロジ機能を有効または無効にできるようにすることです。 LDP MT-IDとIGP MT-IDのマッピングは、デフォルトですべてのルーターで手動で構成されていると想定されています。 IGP MT-IDとLDP MT-ID間の自動マッピングが必要な場合は、明示的な構成が必要です。
Any extensions that may be required for existing MIBs are beyond the scope of this document.
既存のMIBに必要な拡張機能は、このドキュメントの範囲を超えています。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements.
このドキュメントで定義されているメカニズムは、新しい活性検出および監視要件を意味するものではありません。
In order to debug an LDP-MT-enabled network, it may be necessary to associate between the LDP label advertisement and the IGP routing advertisement. In this case, the user MUST understand the mapping mechanism to convert the IGP MT-ID to the LDP MT-ID. The method and type of mapping mechanism is out of the scope of this document.
LDP-MT対応ネットワークをデバッグするために、LDPラベルアドバタイズメントとIGPルーティングアドバタイズメントを関連付ける必要がある場合があります。この場合、ユーザーはIGP MT-IDをLDP MT-IDに変換するためのマッピングメカニズムを理解する必要があります。マッピングメカニズムの方法とタイプは、このドキュメントの範囲外です。
If the LDP MT-ID has an implicit dependency on IGP MT-ID, then the corresponding IGP MT features will need to be supported.
LDP MT-IDがIGP MT-IDに暗黙的に依存している場合、対応するIGP MT機能をサポートする必要があります。
Mechanisms defined in this document do not have any impact on network operations.
このドキュメントで定義されているメカニズムは、ネットワーク操作に影響を与えません。
Ning So Tata Communications 2613 Fairbourne Cir. Plano, TX 75082 USA
Ning So Tata Communications 2613フェアボーンサー。プラノ、テキサス州75082米国
EMail: ning.so@tatacommunications.com
Raveendra Torvi Juniper Networks 10 Technology Park Drive Westford, MA 01886-3140 US
Raveendra Torvi Juniper Networks 10 Technology Park Drive Westford、MA 01886-3140 US
EMail: rtorvi@juniper.net
Huaimo Chen Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US
Huaimo Chen Huawei Technology 125 Nagog Technology Park Acton、MA 01719 US
Emily Chen 2717 Seville Blvd, Apt. 1205 Clearwater, FL 33764 US
Emily Chen 2717 Seville Blvd、Apt。 1205 Clearwater、FL 33764 US
EMail: emily.chen220@gmail.com
Chen Li China Mobile 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China
Chen l i China Mobile 53A、ξside door ave。X UN地区なし、北京01719中国
EMail: lichenyj@chinamobile.com
Lu Huang China Mobile 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China
l u Huang China Mobile 53A、ξave inside ave。X UN地区なし、北京01719中国
The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai, Pranjal Dutta, George Swallow, Curtis Villamizar, Adrian Farrel, Alia Atlas, and Loa Anderson for their valuable comments on this document.
著者は、Dan Tappan、Nabil Bitar、Huang Xin、Eric Rosen、IJsbrand Wijnands、Dimitri Papadimitriou、Yiqun Chai、Pranjal Dutta、George Swallow、Curtis Villamizar、Adrian Farrel、Alia Atlas、Loa Andersonの貴重なコメントに感謝します。このドキュメント。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561]トーマス、B。、ラザ、K。、アガーワル、S。、アガーワル、R。、およびJL。 Le Roux、「LDP Capabilities」、RFC 5561、2009年7月。
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010.
[RFC5918] Asati、R.、Minei、I。、およびB. Thomas、「Label Distribution Protocol（LDP） 'Typed Wildcard' Forward Equivalence Class（FEC）」、RFC 5918、2010年8月。
[RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, "Signaling LDP Label Advertisement Completion", RFC 5919, August 2010.
[RFC5919] Asati、R.、Mohapatra、P.、Chen、E。、およびB. Thomas、「Signaling LDP Label Advertisement Completion」、RFC 5919、2010年8月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. Srinivasan, C., Viswanathan, A., and T. Nadeau,
[RFC3813] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「Multiprotocol Label Switching（MPLS）Label Switching Router（LSR）Management Information Base（MIB）」、RFC 3813、2004年6月。Srinivasan、C。、ビスワナサン、A.、T。ナドー、
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[RFC3815] Cucchiara、J.、Sjostrand、H。、およびJ. Luciani、「マルチプロトコルラベルスイッチング（MPLS）、ラベル配布プロトコル（LDP）の管理対象オブジェクトの定義」、RFC 3815、2004年6月。
Authors' Addresses
著者のアドレス
Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US EMail: quintin.zhao@huawei.com
Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton、MA 01719 US Eメール：quintin.zhao@huawei.com
Kamran Raza Cisco Systems 2000 Innovation Drive Kanata, ON K2K-3E8 Canada EMail: skraza@cisco.com
かｍらん らざ しｓこ Ｓｙｓてｍｓ ２０００ いんおゔぁちおん Ｄりゔぇ かなた、 おん Ｋ２Ｋー３え８ かなだ えまいｌ： ｓｋらざ＠しｓこ。こｍ
Chao Zhou Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 US EMail: czhou@cisco.com
Chao Zhou Cisco Systems 300 Beaver Brook Road Boxborough、MA 01719 US Eメール：czhou@cisco.com
Luyuan Fang Microsoft 5600 148th Ave NE Redmond, WA 98052 US EMail: lufang@microsoft.com
ぅゆあん ふぁんｇ みｃろそｆｔ ５６００ １４８ｔｈ あゔぇ ね れｄもんｄ、 わ ９８０５２ うＳ えまいｌ： ぅふぁんｇ＠みｃろそｆｔ。こｍ
Lianyuan Li China Mobile 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China EMail: lilianyuan@chinamobile.com
l Ian yuan l i China Mobile 53A、ξBianmen ave。X UN No District、Beijing 01719 China email：李连源@China Mobile.com
Daniel King Old Dog Consulting EMail: daniel@olddog.co.uk
Daniel King Old Dog Consulting Eメール：daniel@olddog.co.uk