[要約] RFC 6388は、ポイントツーマルチポイントおよびマルチポイントツーマルチポイントのラベルスイッチパスのためのラベル配布プロトコルの拡張に関するものです。このRFCの目的は、マルチキャストトラフィックの効率的な配信を可能にするために、ラベル配布プロトコルを拡張することです。
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 6388 Cisco Systems, Inc.
Category: Standards Track I. Minei, Ed.
ISSN: 2070-1721 K. Kompella
Juniper Networks
B. Thomas
November 2011
Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルの切り替えパスのラベル分布プロトコル拡張
Abstract
概要
This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document.
このドキュメントでは、MPLSネットワークのMultipoint-to-MultiPoint（MP2MP）ラベルスイッチ付きパス（LSP）のセットアップのためのラベル分布プロトコル（LDP）への拡張機能について説明します。これらの拡張機能は、マルチポイントLDPとも呼ばれます。Multipoint LDPは、他のマルチキャストツリー構造プロトコルと相互作用または依存することなく、P2MPまたはMP2MP LSPを構築します。このソリューションのプロトコル要素と手順については、このようなLSPを受信機が開始する方法で構築するために説明されています。マルチポイントLSPにはさまざまなアプリケーションがあります。たとえば、IPマルチキャストやBGP/MPLSレイヤー3仮想プライベートネットワーク（L3VPNS）のマルチキャストのサポートなどです。このようなアプリケーションがLDPシグナル型マルチポイントLSPを使用する方法の仕様は、このドキュメントの範囲外です。
Status of This Memo
本文書の位置付け
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc6388.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6388で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Terminology ................................................4
1.3. Manageability ..............................................5
2. Setting Up P2MP LSPs with LDP ...................................6
2.1. Support for P2MP LSP Setup with LDP ........................6
2.2. The P2MP FEC Element .......................................6
2.3. The LDP MP Opaque Value Element ............................8
2.3.1. The Generic LSP Identifier ..........................9
2.4. Using the P2MP FEC Element .................................9
2.4.1. Label Mapping ......................................10
2.4.2. Label Withdraw .....................................12
2.4.3. Upstream LSR Change ................................13
3. Setting up MP2MP LSPs with LDP .................................14
3.1. Support for MP2MP LSP Setup with LDP ......................14
3.2. The MP2MP Downstream and Upstream FEC Elements ............15
3.3. Using the MP2MP FEC Elements ..............................15
3.3.1. MP2MP Label Mapping ................................17
3.3.2. MP2MP Label Withdraw ...............................20
3.3.3. MP2MP Upstream LSR Change ..........................21
4. Micro-Loops in MP LSPs .........................................21
5. The LDP MP Status TLV ..........................................21
5.1. The LDP MP Status Value Element ...........................22
5.2. LDP Messages Containing LDP MP Status Messages ............22
5.2.1. LDP MP Status Sent in LDP Notification Messages ....23
5.2.2. LDP MP Status TLV in Label Mapping Message .........24
6. Upstream Label Allocation on a LAN .............................24
6.1. LDP Multipoint-to-Multipoint on a LAN .....................24
6.1.1. MP2MP Downstream Forwarding ........................25
6.1.2. MP2MP Upstream Forwarding ..........................25
7. Root Node Redundancy ...........................................25
7.1. Root Node Redundancy - Procedures for P2MP LSPs ...........26
7.2. Root Node Redundancy - Procedures for MP2MP LSPs ..........26
8. Make Before Break (MBB) ........................................27
8.1. MBB Overview .............................................27
8.2. The MBB Status Code .......................................28
8.3. The MBB Capability ........................................29
8.4. The MBB Procedures ........................................29
8.4.1. Terminology ........................................29
8.4.2. Accepting Elements .................................30
8.4.3. Procedures for Upstream LSR Change .................30
8.4.4. Receiving a Label Mapping with MBB Status Code .....31
8.4.5. Receiving a Notification with MBB Status Code ......31
8.4.6. Node Operation for MP2MP LSPs ......................32
9. Typed Wildcard for mLDP FEC Element ............................32
10. Security Considerations .......................................32
11. IANA Considerations ...........................................33
12. Acknowledgments ...............................................34
13. Contributing Authors ..........................................35
14. References ....................................................37
14.1. Normative References .....................................37
14.2. Informative References ...................................37
The LDP protocol is described in [RFC5036]. It defines mechanisms for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs in the network. This document describes extensions to LDP for setting up point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) LSPs. These are collectively referred to as multipoint LSPs (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) node to be delivered to a number of leaf (or egress) nodes. An MP2MP LSP allows traffic from multiple ingress nodes to be delivered to multiple egress nodes. Only a single copy of the packet will be sent to an LDP neighbor traversed by the MP LSP. This is accomplished without the use of a multicast protocol in the network. There can be
LDPプロトコルは[RFC5036]で説明されています。ネットワーク内のポイントツーポイント（P2P）およびマルチポイントツーポイント（MP2P）LSPを設定するメカニズムを定義します。このドキュメントでは、ポイントツーマルチポイント（P2MP）およびマルチポイントツーマルチポイント（MP2MP）LSPを設定するためのLDPへの拡張について説明しています。これらは、マルチポイントLSP（MP LSP）と総称されます。P2MP LSPを使用すると、単一のルート（またはイングレス）ノードからのトラフィックを多数の葉（または出口）ノードに配信できます。MP2MP LSPを使用すると、複数のイングレスノードからのトラフィックを複数の出力ノードに配信できます。Packetのコピーのみが、MP LSPによって横断されるLDP隣人に送信されます。これは、ネットワークでマルチキャストプロトコルを使用せずに達成されます。そういうこともありうる
several MP LSPs rooted at a given ingress node, each with its own identifier.
特定のイングレスノードにルート化されたいくつかのMP LSPは、それぞれ独自の識別子を備えています。
The solution assumes that the leaf nodes of the MP LSP know the root node and identifier of the MP LSP to which they belong. The mechanisms for the distribution of this information are outside the scope of this document. The specification of how an application can use an MP LSP signaled by LDP is also outside the scope of this document.
このソリューションは、MP LSPの葉のノードが、それらが属するMP LSPのルートノードと識別子を知っていることを前提としています。この情報の分布のメカニズムは、このドキュメントの範囲外です。アプリケーションがLDPによって信号を送信するMP LSPを使用する方法の仕様も、このドキュメントの範囲外です。
Related documents that may be of interest include [RFC6348], [L3VPN-MCAST], and [RFC4875].
興味深い可能性のある関連文書には、[RFC6348]、[L3VPN-MCAST]、および[RFC4875]が含まれます。
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]で説明されているように解釈されます。
All new fields shown as "reserved" in this document MUST be set to zero on transmission and MUST be ignored on receipt.
このドキュメントで「予約された」と表示されているすべての新しいフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Some of the following terminology is taken from [RFC6348].
次の用語のいくつかは[RFC6348]から取られています。
mLDP: Multipoint extensions for LDP.
MLDP：LDPのマルチポイント拡張機能。
P2P LSP: An LSP that has one Ingress LSR and one Egress LSR.
P2P LSP：1つの侵入LSRと1つの出力LSRを備えたLSP。
P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs.
P2MP LSP：1つの侵入LSRと1つ以上の出力LSRを備えたLSP。
MP2P LSP: An LSP that has one or more Ingress LSRs and one unique Egress LSR.
MP2P LSP：1つ以上の侵入LSRと1つのユニークな出力LSRを備えたLSP。
MP2MP LSP: An LSP with a distinguished root node that connects a set of nodes, such that traffic sent by any node in the LSP is delivered to all others.
MP2MP LSP：ノードのセットを接続する著名なルートノードを備えたLSP。
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
MP LSP：P2MPまたはMP2MP LSPのマルチポイントLSP。
Ingress LSR: An Ingress LSR for a particular LSP is an LSR that can send a data packet along the LSP. MP2MP LSPs can have multiple Ingress LSRs, P2MP LSPs have just one, and that node is often referred to as the "root node".
Ingress LSR：特定のLSPのIngress LSRは、LSPに沿ってデータパケットを送信できるLSRです。MP2MP LSPには複数のイングレスLSRがあり、P2MP LSPには1つしかなく、そのノードはしばしば「ルートノード」と呼ばれます。
Egress LSR: An Egress LSR for a particular LSP is an LSR that can remove a data packet from that LSP for further processing. P2P and MP2P LSPs have only a single egress node, but P2MP and MP2MP LSPs can have multiple egress nodes.
出力LSR：特定のLSPの出力LSRは、そのLSPからデータパケットを削除してさらに処理できるLSRです。P2PおよびMP2P LSPには単一の出力ノードしかありませんが、P2MPおよびMP2MP LSPは複数の出力ノードを持つことができます。
Transit LSR: An LSR that has reachability to the root of the MP LSP via a directly connected upstream LSR and one or more directly connected downstream LSRs.
Transit LSR：直接接続されたアップストリームLSRと1つ以上の直接接続された下流LSRSを介してMP LSPのルートに到達可能性を持つLSR。
Bud LSR: An LSR that is an egress but also has one or more directly connected downstream LSRs.
BUD LSR：出口であるが、1つ以上の直接接続された下流LSRもあるLSR。
Leaf node: A leaf node can be either an Egress or Bud LSR when referred to in the context of a P2MP LSP. In the context of an MP2MP LSP, a leaf is both Ingress and Egress for the same MP2MP LSP and can also be a Bud LSR.
リーフノード：葉のノードは、P2MP LSPのコンテキストで参照される場合、出口または芽LSRのいずれかにすることができます。MP2MP LSPのコンテキストでは、葉は同じMP2MP LSPの侵入と出口の両方であり、芽LSRにもなります。
CRC32: This contains a Cyclic Redundancy Check value of the uncompressed data in network byte order computed according to CRC-32 algorithm used in the ISO 3309 standard [ISO3309] and in Section 8.1.1.6.2 of ITU-T recommendation V.42 [ITU.V42.1994].
CRC32：これには、ISO 3309標準[ISO3309]およびITU-T推奨v.42のセクション8.1.1.6.2で使用されるCRC-32アルゴリズムに従って計算されたネットワークバイト順序の非圧縮データの環状冗長チェック値が含まれています[itu.v42.1994]。
FEC: Forwarding Equivalence Class
FEC：転送等価クラス
MPLS LSRs can be modeled and managed using the MIB module defined in [RFC3813]. That MIB module is fully capable of handling the one-to-many in-segment to out-segment relationships needed to support P2MP LSPs, and no further changes are required.
MPLS LSRは、[RFC3813]で定義されたMIBモジュールを使用してモデル化および管理できます。そのMIBモジュールは、P2MP LSPをサポートするために必要な1対多くのセグメントからアウトセグメントの関係を完全に処理することができ、それ以上の変更は必要ありません。
[RFC3815] defines managed objects for LDP. The MIB module allows the modeling and management of LDP and LDP speakers for the protocol as defined in [RFC5036]. The protocol extensions defined in this document to support P2MP in LDP may require an additional MIB module or extensions to the modules defined in [RFC3815]. This is for future study, and at the time of this writing, no interest has been expressed in this work.
[RFC3815] LDPの管理されたオブジェクトを定義します。MIBモジュールは、[RFC5036]で定義されているように、プロトコルのLDPおよびLDPスピーカーのモデリングと管理を可能にします。LDPでP2MPをサポートするためにこのドキュメントで定義されているプロトコル拡張機能には、[RFC3815]で定義されたモジュールへの追加のMIBモジュールまたは拡張機能が必要になる場合があります。これは将来の研究のためであり、この執筆時点では、この作業に関心は表明されていません。
Future manageability work should pay attention to the protocol extensions defined in this document, and specifically the configurable and variable elements, along with reporting the new protocol fields that identify individual P2MP LSPs.
将来の管理性作業では、個々のP2MP LSPを識別する新しいプロトコルフィールドを報告するとともに、このドキュメントで定義されているプロトコル拡張、特に構成可能な変数要素に注意を払う必要があります。
A P2MP LSP consists of a single root node, zero or more transit nodes, and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and tear-down. Leaf nodes also install forwarding state to deliver the traffic received on a P2MP LSP to wherever it needs to go; how this is done is outside the scope of this document. Transit nodes install MPLS forwarding state and propagate the P2MP LSP setup (and tear-down) toward the root. The root node installs forwarding state to map traffic into the P2MP LSP; how the root node determines which traffic should go over the P2MP LSP is outside the scope of this document.
P2MP LSPは、単一のルートノード、ゼロ以上のトランジットノード、および1つ以上の葉ノードで構成されています。葉のノードは、P2MP LSPのセットアップと引き裂きを開始します。また、リーフノードは、P2MP LSPで受信したトラフィックをどこにでも必要な場所に配信するために、転送状態を取り付けます。これがどのように行われるかは、このドキュメントの範囲外です。トランジットノードは、MPLSの転送状態をインストールし、P2MP LSPセットアップ（および裂け目）をルートに向けて伝播します。ルートノードは、転送状態をインストールして、トラフィックをP2MP LSPにマッピングします。ルートノードがP2MP LSPを介してどのトラフィックを移動するかをどのように決定するかは、このドキュメントの範囲外です。
Support for the setup of P2MP LSPs is advertised using LDP capabilities as defined in [RFC5561]. An implementation supporting the P2MP procedures specified in this document MUST implement the procedures for Capability Parameters in Initialization messages.
P2MP LSPのセットアップのサポートは、[RFC5561]で定義されているLDP機能を使用して宣伝されます。このドキュメントで指定されたP2MP手順をサポートする実装では、初期化メッセージに機能パラメーターの手順を実装する必要があります。
A new Capability Parameter TLV is defined, the P2MP Capability. Following is the format of the P2MP Capability Parameter.
新しい機能パラメーターTLVが定義されています。P2MP機能。以下は、P2MP機能パラメーターの形式です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| P2MP Capability (0x0508) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
S: As specified in [RFC5561]
S：[RFC5561]で指定されています
The P2MP Capability TLV MUST be advertised in the LDP Initialization message. Advertisement of the P2MP Capability indicates support of the procedures for P2MP LSP setup detailed in this document. If the peer has not advertised the corresponding capability, then label messages using the P2MP FEC Element SHOULD NOT be sent to the peer.
P2MP機能TLVは、LDP初期化メッセージに宣伝する必要があります。P2MP機能の広告は、このドキュメントで詳述されているP2MP LSPセットアップの手順のサポートを示しています。ピアが対応する機能を宣伝していない場合、P2MP FEC要素を使用してメッセージをラベル付けすることをピアに送信しないでください。
For the setup of a P2MP LSP with LDP, we define one new protocol entity, the P2MP FEC Element, to be used as a FEC Element in the FEC TLV. Note that the P2MP FEC Element does not necessarily identify the traffic that must be mapped to the LSP, so from that point of view, the use of the term FEC is a misnomer. The description of the P2MP FEC Element follows.
LDPを備えたP2MP LSPのセットアップでは、FEC TLVのFEC要素として使用する1つの新しいプロトコルエンティティ、P2MP FEC要素を定義します。P2MP FEC要素は、LSPにマッピングする必要があるトラフィックを必ずしも識別しないことに注意してください。そのため、その観点から、FECという用語の使用は誤称であることに注意してください。P2MP FEC要素の説明が続きます。
The P2MP FEC Element consists of the address of the root of the P2MP LSP and an opaque value. The opaque value consists of one or more LDP MP opaque value elements. The opaque value is unique within the context of the root node. The combination of (Root Node Address type, Root Node Address, Opaque Value) uniquely identifies a P2MP LSP within the MPLS network.
P2MP FEC要素は、P2MP LSPのルートのアドレスと不透明な値で構成されています。不透明な値は、1つ以上のLDP MP不透明な値要素で構成されています。不透明な値は、ルートノードのコンテキスト内で一意です。（ルートノードアドレスタイプ、ルートノードアドレス、不透明値）の組み合わせは、MPLSネットワーク内のP2MP LSPを一意に識別します。
The P2MP FEC Element is encoded as follows:
P2MP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2MP Type(0x06)| Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the P2MP FEC Element is 0x06.
タイプ：P2MP FEC要素のタイプは0x06です。
Address Family: Two octet quantity containing a value from IANA's "Address Family Numbers" registry that encodes the address family for the Root LSR Address.
アドレスファミリ：ルートLSRアドレスのアドレスファミリをエンコードするIANAの「アドレスファミリー番号」レジストリからの値を含む2オクテット数量。
Address Length: Length of the Root LSR Address in octets.
アドレスの長さ：オクテットのルートLSRアドレスの長さ。
Root Node Address: A host address encoded according to the Address Family field.
ルートノードアドレス：アドレスファミリフィールドに従ってエンコードされたホストアドレス。
Opaque Length: The length of the opaque value, in octets.
不透明な長さ：オクテットの不透明な値の長さ。
Opaque Value: One or more MP opaque value elements, uniquely identifying the P2MP LSP in the context of the root node. This is described in the next section.
不透明値：1つ以上のMP不透明な値要素は、ルートノードのコンテキストでP2MP LSPを一意に識別します。これについては、次のセクションで説明します。
If the Address Family is IPv4, the Address Length MUST be 4; if the Address Family is IPv6, the Address Length MUST be 16. No other Address Lengths are defined at present.
アドレスファミリがIPv4の場合、アドレスの長さは4でなければなりません。アドレスファミリがIPv6の場合、アドレスの長さは16でなければなりません。現在、他のアドレス長は定義されていません。
If the Address Length doesn't match the defined length for the Address Family, the receiver SHOULD abort processing the message containing the FEC Element, and send an "Unknown FEC" Notification message to its LDP peer signaling an error.
アドレスの長さがアドレスファミリの定義された長さと一致しない場合、受信者はFEC要素を含むメッセージの処理を中止し、「不明なFEC」通知メッセージをLDPピアに送信する必要があります。
If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST be the only FEC Element in the FEC TLV.
FEC TLVにP2MP FEC要素が含まれている場合、P2MP FEC要素はFEC TLVの唯一のFEC要素でなければなりません。
The LDP MP opaque value element is used in the P2MP and MP2MP FEC Elements defined in subsequent sections. It carries information that is meaningful to Ingress LSRs and Leaf LSRs, but need not be interpreted by Transit LSRs.
LDP MP不透明な値要素は、後続のセクションで定義されたP2MPおよびMP2MP FEC要素で使用されます。LSRや葉のLSRを侵入することに意味のある情報を運びますが、輸送LSRによって解釈する必要はありません。
The LDP MP opaque value element basic type is encoded as follows:
LDP MP Opaque Value Element Basic Typeは、次のようにエンコードされています。
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 < 255 | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The Type of the LDP MP opaque value element. IANA maintains a registry of basic types (see Section 11).
タイプ：LDP MP Opaque Value要素のタイプ。IANAは、基本タイプのレジストリを維持しています（セクション11を参照）。
Length: The length of the Value field, in octets.
長さ：オクテット内の値フィールドの長さ。
Value: String of Length octets, to be interpreted as specified by the Type field.
値：型フィールドで指定されていると解釈される長さのオクテットの文字列。
The LDP MP opaque value element extended type is encoded as follows:
LDP MP Opaque Value Element拡張タイプは、次のようにエンコードされます。
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 = 255 | Extended Type | Length (high) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Length (low) | Value |
+-+-+-+-+-+-+-+-+ |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type = 255.
タイプ：タイプ= 255。
Extended Type: The Extended Type of the LDP MP opaque value element. IANA maintains a registry of extended types (see Section 11).
拡張タイプ：LDP MP Opaque値要素の拡張タイプ。IANAは、拡張タイプのレジストリを維持しています（セクション11を参照）。
Length: The length of the Value field, in octets.
長さ：オクテット内の値フィールドの長さ。
Value: String of Length octets, to be interpreted as specified by the Type field.
値：型フィールドで指定されていると解釈される長さのオクテットの文字列。
The generic LSP identifier is a type of opaque value element basic type encoded as follows:
ジェネリックLSP識別子は、次のようにエンコードされた不透明な値要素の一種です。
Type: 1
タイプ：1
Length: 4
長さ：4
Value: A 32-bit integer, unique in the context of the root, as identified by the root's address.
値：ルートのアドレスで識別されるように、ルートのコンテキストで一意の32ビット整数。
This type of opaque value element is recommended when mapping of traffic to LSPs is non-algorithmic and is done by means outside LDP.
このタイプの不透明な値要素は、LSPへのトラフィックのマッピングが非アルゴリズムであり、LDP以外で行われる場合に推奨されます。
This section defines the rules for the processing and propagation of the P2MP FEC Element. The following notation is used in the processing rules:
このセクションでは、P2MP FEC要素の処理と伝播に関するルールを定義します。次の表記は、処理ルールで使用されます。
1. P2MP FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y.
1. P2MP FEC要素<X、Y>：ルートノードアドレスXとオパーク値Yを備えたFEC要素Y。
2. P2MP Label Mapping <X, Y, L>: a Label Mapping message with a FEC TLV with a single P2MP FEC Element <X, Y> and Label TLV with label L. Label L MUST be allocated from the per-platform label space (see [RFC3031], Section 3.14) of the LSR sending the Label Mapping message. The use of the interface label space is outside the scope of this document.
2. P2MPラベルマッピング<X、Y、L>：単一のP2MP FEC要素を備えたFEC TLVを備えたラベルマッピングメッセージ<X、Y>、ラベルLを備えたラベルTLV。ラベルマッピングメッセージを送信するLSRの[RFC3031]、セクション3.14）を参照してください。インターフェイスラベルスペースの使用は、このドキュメントの範囲外です。
3. P2MP Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC TLV with a single P2MP FEC Element <X, Y> and Label TLV with label L.
3. P2MPラベルの引き出し<x、y、l>：単一のp2mp fec要素<x、y>、ラベルLを備えたラベルTLVを備えたFEC TLVを備えたラベル引き出しメッセージ。
4. P2MP LSP <X, Y> (or simply <X, Y>): a P2MP LSP with root node address X and opaque value Y.
4. p2mp lsp <x、y>（または単に<x、y>）：ルートノードアドレスxと不透明な値yを備えたp2mp lsp y。
5. The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on LSR X means that on receiving a packet with label L', X makes n copies of the packet. For copy i of the packet, X swaps L' with Li and sends it out over interface Ii.
5. lsr xの表記l ' - > {<i1、l1> <i2、l2> ...、<in、ln>}は、ラベルl'でパケットを受信すると、パケットのnコピーを作成することを意味します。パケットのコピーIの場合、XはL 'とL'を交換し、インターフェイスIIを介して送信します。
The procedures below are organized by the role that the node plays in the P2MP LSP. Node Z knows that it is a leaf node by a discovery process that is outside the scope of this document. During the course of protocol operation, the root node recognizes its role because it owns the root node address. A transit node is any node (other than the root node) that receives a P2MP Label Mapping message (i.e., one that has leaf nodes downstream of it).
以下の手順は、ノードがP2MP LSPで演じる役割によって編成されています。ノードZは、このドキュメントの範囲外の発見プロセスによるリーフノードであることを知っています。プロトコル操作の過程で、ルートノードがルートノードアドレスを所有しているため、ルートノードはその役割を認識します。トランジットノードは、P2MPラベルマッピングメッセージを受信する任意のノード（ルートノード以外）です（つまり、葉のノードが下流にあるもの）。
Note that a transit node (and indeed the root node) may also be a leaf node.
トランジットノード（および実際にはルートノード）もリーフノードである可能性があることに注意してください。
The remainder of this section specifies the procedures for originating P2MP Label Mapping messages and for processing received P2MP Label Mapping messages for a particular LSP. The procedures for a particular LSR depend upon the role that LSR plays in the LSP (Ingress, Transit, or Egress).
このセクションの残りの部分では、P2MPラベルマッピングメッセージを発信する手順と、特定のLSPの受信P2MPラベルマッピングメッセージを処理する手順を指定します。特定のLSRの手順は、LSRがLSPで果たす役割（イングレス、トランジット、または出口）に依存します。
All labels discussed here are downstream-assigned [RFC5332] except those that are assigned using the procedures of Section 6.
ここで説明するすべてのラベルは、セクション6の手順を使用して割り当てられるものを除き、下流で割り当てられた[RFC5332]です。
Each node that is either an Leaf or Transit LSR of MP LSP needs to use the procedures below to select an upstream LSR. A node Z that wants to join an MP LSP <X, Y> determines the LDP peer U that is Z's next-hop on the best path from Z to the root node X. If there is
MP LSPの葉または通過LSRのいずれかである各ノードは、以下の手順を使用して上流のLSRを選択する必要があります。MP LSP <X、Y>に参加したいノードZは、ZからルートノードXへの最適なパスでZの次のホップであるLDPピアUを決定します。
more than one such LDP peer, only one of them is picked. U is Z's "upstream LSR" for <X, Y>.
そのようなLDPピアが複数あり、そのうちの1つだけが選ばれています。uは<x、y>のzの「上流LSR」です。
When there are several candidate upstream LSRs, the LSR MUST select one upstream LSR. The algorithm used for the LSR selection is a local matter. If the LSR selection is done over a LAN interface and the Section 6 procedures are applied, the following procedure SHOULD be applied to ensure that the same upstream LSR is elected among a set of candidate receivers on that LAN.
上流のLSRSがいくつかある場合、LSRは1つのアップストリームLSRを選択する必要があります。LSR選択に使用されるアルゴリズムは、局所的な問題です。LSR選択がLANインターフェイスで行われ、セクション6の手順が適用されている場合、同じ上流のLSRがそのLANの候補レシーバーのセット間で選出されるように、次の手順を適用する必要があります。
1. The candidate upstream LSRs are numbered from lower to higher IP address.
1. 候補の上流のLSRは、低いIPアドレスから上位のIPアドレスから番号が付けられています。
2. The following hash is performed: H = (CRC32(Opaque Value)) modulo N, where N is the number of upstream LSRs. The 'Opaque Value' is the field identified in the FEC Element right after 'Opaque Length'. The 'Opaque Length' indicates the size of the opaque value used in this calculation.
2. 次のハッシュが実行されます：h =（crc32（opaque value））modulo n。ここで、nは上流のLSRの数です。「不透明値」は、「不透明な長さ」の直後のFEC要素で識別されるフィールドです。「不透明な長さ」は、この計算で使用される不透明な値のサイズを示します。
3. The selected upstream LSR U is the LSR that has the number H.
3. 選択されたアップストリームLSR uは、数hを持つLSRです。
This procedure will ensure that there is a single forwarder over the LAN for a particular LSP.
この手順により、特定のLSPのLAN上に単一のフォワーダーがあることが保証されます。
Suppose LSR U receives an MP Label Mapping message from a downstream LSR D, specifying label L. Suppose further that U is connected to D over several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If U needs to transmit to D a data packet whose top label is L, U is free to transmit the packet on any of those interfaces. The algorithm it uses to choose a particular interface and next-hop for a particular such packet is a local matter. For completeness, the following procedure MAY be used. LSR U may do a lookup in the unicast routing table to find the best interface and next-hop to reach LSR D. If the next-hop and interface are also advertised by LSR D via the LDP session, it can be used to transmit the packet to LSR D.
LSR Uが下流のLSR DからMPラベルマッピングメッセージを受信し、ラベルLを指定したとします。さらに、Uが複数のLDP対応インターフェイスまたはRSVP-TEトンネルインターフェイスでDに接続されていると仮定します。トップラベルがLであるデータパケットをDに送信する必要がある場合、Uはこれらのインターフェイスのいずれかでパケットを自由に送信できます。特定のインターフェイスを選択するために使用するアルゴリズムと、そのようなパケットの次のホップはローカルな問題です。完全性のために、次の手順を使用できます。LSR uは、ユニキャストルーティングテーブルを検索してLSR Dに到達するのに最適なインターフェイスと次のホップを見つけることができます。LDPセッションを介してLSR Dによって次のホップとインターフェイスも宣伝されている場合、使用して使用できます。LSR Dへのパケット
A leaf node Z of P2MP LSP <X, Y> determines its upstream LSR U for <X, Y> as per Section 2.4.1.1, allocates a label L, and sends a P2MP Label Mapping <X, Y, L> to U.
P2MP lsp <x、y>の葉のノードzは、セクション2.4.1.1に従って上流のLSR uを<x、y>の上流LSR uを決定し、ラベルLを割り当て、p2MPラベルマッピング<x、y、l>をuに送信します。。
Suppose a transit node Z receives a P2MP Label Mapping <X, Y, L> from LSR T. Z checks whether it already has state for <X, Y>. If not, Z determines its upstream LSR U for <X, Y> as per Section 2.4.1.1. Using this Label Mapping to update the label forwarding table MUST NOT be done as long as LSR T is equal to LSR U. If LSR U is different from LSR T, Z will allocate a label L', and install state to swap L' with L over interface I associated with LSR T and send a P2MP Label Mapping <X, Y, L'> to LSR U. Interface I is determined via the procedures in Section 2.4.1.2.
トランジットノードZがP2MPラベルマッピング<x、y、l>を受信しているとします。LSRTからZが既に状態があるかどうかをチェックします。そうでない場合、Zはセクション2.4.1.1に従って、<x、y>の上流LSR uを決定します。このラベルマッピングを使用してラベル転送テーブルを更新すると、LSR TがLSR Uに等しい限り、ラベル転送テーブルを更新する必要はありません。LSRUがLSR Tと異なる場合、ZはラベルL 'を割り当て、状態をインストールしてL'を交換します。l lsr tに関連付けられたインターフェイスI上のlsion P2MPラベルマッピング<x、y、l '>をLSR Uに送信します。インターフェイスIは、セクション2.4.1.2の手順を介して決定されます。
If Z already has state for <X, Y>, then Z does not send a Label Mapping message for P2MP LSP <X, Y>. If LSR T is not equal to the upstream LSR of <X, Y> and <I, L> does not already exist as forwarding state, the forwarding state is updated. Assuming its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. If LSR T is equal to the installed upstream LSR, the Label Mapping from LSR T MUST be retained and MUST NOT update the label forwarding table.
zが既に<x、y>の状態を持っている場合、zはp2mp lsp <x、y>のラベルマッピングメッセージを送信しません。LSR Tが<x、y>、<i、l>の上流LSRに等しくない場合、転送状態としてまだ存在していない場合、転送状態が更新されます。その古い転送状態がl ' - > {<i1、l1> <i2、l2> ...、<in、ln>}であると仮定すると、その新しい転送状態はl' - > {<i1、l1> <i2、l2> ...、<in、ln>、<i、l>}。LSR TがインストールされているアップストリームLSRに等しい場合、LSR Tからのラベルマッピングを保持する必要があり、ラベル転送テーブルを更新しないでください。
Suppose the root node Z receives a P2MP Label Mapping <X, Y, L> from LSR T. Z checks whether it already has forwarding state for <X, Y>. If not, Z creates forwarding state to push label L onto the traffic that Z wants to forward over the P2MP LSP (how this traffic is determined is outside the scope of this document).
ルートノードZがP2MPラベルマッピング<x、y、l>を受信しているとします。LSRTからZ Zが既に<x、y>の転送状態を持っているかどうかをチェックします。そうでない場合、Zは転送状態を作成して、ZがP2MP LSPを介して転送したいトラフィックにラベルLを押します（このトラフィックの決定方法は、このドキュメントの範囲外です）。
If Z already has forwarding state for <X, Y>, then Z adds "push label L, send over interface I" to the next hop, where I is the interface associated with LSR T and determined via the procedures in Section 2.4.1.2.
zが既に<x、y>の転送状態を持っている場合、zは「プッシュラベルl、インターフェイスIを送信I」を次のホップに追加します。ここで、私はLSR Tに関連付けられたインターフェイスであり、セクション2.4.1.2の手順で決定されました。。
The following section lists procedures for generating and processing P2MP Label Withdraw messages for nodes that participate in a P2MP LSP. An LSR should apply those procedures that apply to it, based on its role in the P2MP LSP.
次のセクションには、P2MP LSPに参加するノードのP2MPラベル引き出しメッセージを生成および処理する手順を示します。LSRは、P2MP LSPでの役割に基づいて、それに適用される手順を適用する必要があります。
If a leaf node Z discovers that it has no downstream neighbors in that LSP, and that it has no need to be an Egress LSR for that LSP (by means outside the scope of this document), then it SHOULD send a Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is the label it had previously advertised to U for <X, Y>.
葉のノードZが、そのLSPに下流の隣人がいないこと、そしてそのLSPの出口LSRである必要がないことを発見した場合（このドキュメントの範囲外の手段で）、ラベルの撤回を送信する必要があります<x、y、l> <x、y>の上流lsr uに、ここでlは以前に<x、y>のためにuに宣伝されていたラベルです。
If a transit node Z receives a Label Withdraw message <X, Y, L> from a node W, it deletes label L from its forwarding state and sends a Label Release message with label L to W.
トランジットノードZがラベルZを受信した場合、ノードWから<x、y、l>を削除すると、転送状態からラベルLを削除し、ラベルLを使用してラベルリリースメッセージをWに送信します。
If deleting L from Z's forwarding state for P2MP LSP <X, Y> results in no state remaining for <X, Y>, then Z propagates the Label Withdraw for <X, Y> to its upstream T, by sending a Label Withdraw <X, Y, L1> where L1 is the label Z had previously advertised to T for <X, Y>.
p2mp lsp <x、y>のzの転送状態からlを削除すると、<x、y>の状態が残っていない場合、zはラベルの撤回を上流tに<x、y>のラベルの引き出しを伝播します。x、y、l1>ここで、l1はラベルzが以前に<x、y>に対してtに宣伝されていたラベルzでした。
When the root node of a P2MP LSP receives a Label Withdraw message, the procedures are the same as those for transit nodes, except that it would not propagate the Label Withdraw upstream (as it has no upstream).
P2MP LSPのルートノードがラベルの撤回メッセージを受信すると、手順はトランジットノードのものと同じですが、ラベルが上流の引き出しを伝播しないことを除いて（アップストリームがないため）。
Suppose that for a given node Z participating in a P2MP LSP <X, Y>, the upstream LSR changes from U to U' as per Section 2.4.1.1. Z MUST update its forwarding state as follows. It allocates a new label, L', for <X, Y>. The forwarding state for L' is copied from the forwarding state for L, with one exception: if U' was present in the forwarding state of L, it MUST NOT be installed in the forwarding state of L'. Then the forwarding state for L is deleted and the forwarding state for L' is installed. In addition, Z MUST send a Label Mapping <X, Y, L'> to U' and send a Label Withdraw <X, Y, L> to U. Note, if there was a downstream mapping from U that was not installed in the forwarding due to the procedures defined in Section 2.4.1.4, it can now be installed.
P2MP LSP <X、Y>に参加している特定のノードZについて、セクション2.4.1.1に従って上流のLSRがUからUに変化するとします。zは、次のように転送状態を更新する必要があります。<x、y>の新しいラベルl 'を割り当てます。1つの例外を除いて、l 'の転送状態はlの転送状態からコピーされます：u'がlの転送状態に存在する場合、l 'の転送状態にインストールしてはなりません。次に、Lの転送状態が削除され、L 'の転送状態がインストールされます。さらに、zはラベルマッピング<x、y、l '>にu'を送信し、ラベルの引き出し<x、y、l>を送信する必要があります。セクション2.4.1.4で定義されている手順による転送により、インストールできるようになりました。
While changing the upstream LSR, the following must be taken into consideration. If L' is added before L is removed, there is a potential risk of packet duplication and/or the creation of a transient data-plane forwarding loop. If L is removed before L' is added, packet loss may result. Ideally the change from L to L' is done atomically such that no packet loss or duplication occurs. If
上流のLSRを変更している間、以下を考慮する必要があります。Lが削除される前にl 'が追加された場合、パケットの複製および/または一時的なデータ平面転送ループの作成の潜在的なリスクがあります。Lが追加される前にLが除去されると、パケット損失が生じる可能性があります。理想的には、LからLへの変化は原子的に行われ、パケットの損失や複製が発生しないようにします。もしも
that is not possible, the RECOMMENDED default behavior is to remove L before adding L'.
それは不可能です、推奨されるデフォルトの動作は、l 'を追加する前にlを削除することです。
An MP2MP LSP is much like a P2MP LSP in that it consists of a single root node, zero or more transit nodes, and one or more Leaf LSRs acting equally an as Ingress or Egress LSR. A leaf node participates in the setup of an MP2MP LSP by establishing both a downstream LSP, which is much like a P2MP LSP from the root, and an upstream LSP, which is used to send traffic toward the root and other leaf nodes. Transit nodes support the setup by propagating the upstream and downstream LSP setup toward the root and installing the necessary MPLS forwarding state. The transmission of packets from the root node of an MP2MP LSP to the receivers is identical to that for a P2MP LSP. Traffic from a downstream node follows the upstream LSP toward the root node and branches downward along the downstream LSP as required to reach other leaf nodes. A packet that is received from a downstream node MUST never be forwarded back out to that same node. Mapping traffic to the MP2MP LSP may happen at any leaf node. How that mapping is established is outside the scope of this document.
MP2MP LSPは、単一のルートノード、ゼロ以上のトランジットノード、および1つ以上のリーフLSRで構成されているという点で、P2MP LSPによく似ています。葉のノードは、下流LSPの両方を確立することにより、MP2MP LSPのセットアップに参加します。これは、ルートからのP2MP LSPと、ルートと他の葉のノードにトラフィックを送信するために使用される上流LSPの両方に似ています。トランジットノードは、上流および下流のLSPセットアップをルートに向けて伝播し、必要なMPLS転送状態をインストールすることにより、セットアップをサポートします。 MP2MP LSPのルートノードから受信機へのパケットの送信は、P2MP LSPと同一です。下流のノードからのトラフィックは、上流のLSPに従ってルートノードに向かって進み、他のリーフノードに到達するために必要に応じて下流LSPに沿って下向きに分岐します。下流のノードから受信したパケットは、同じノードに戻さないでください。 MP2MP LSPへのトラフィックのマッピングは、任意のリーフノードで発生する場合があります。そのマッピングの確立方法は、このドキュメントの範囲外です。
Due to how an MP2MP LSP is built, a Leaf LSR that is sending packets on the MP2MP LSP does not receive its own packets. There is also no additional mechanism needed on the root or Transit LSR to match upstream traffic to the downstream forwarding state. Packets that are forwarded over an MP2MP LSP will not traverse a link more than once, with the possible exception of LAN links (see Section 3.3.1), if the procedures of [RFC5331] are not provided.
MP2MP LSPの構築方法により、MP2MP LSPにパケットを送信しているリーフLSRは、独自のパケットを受け取りません。また、上流のトラフィックを下流の転送状態に一致させるために、ルートまたはトランジットLSRに追加のメカニズムは必要ありません。MP2MP LSPに転送されるパケットは、[RFC5331]の手順が提供されていない場合（セクション3.3.1を参照）、LANリンクを除き、リンクを複数回トラバースしません。
Support for the setup of MP2MP LSPs is advertised using LDP capabilities as defined in [RFC5561]. An implementation supporting the MP2MP procedures specified in this document MUST implement the procedures for Capability Parameters in Initialization messages.
MP2MP LSPのセットアップのサポートは、[RFC5561]で定義されているLDP機能を使用して宣伝されています。このドキュメントで指定されたMP2MP手順をサポートする実装では、初期化メッセージに機能パラメーターの手順を実装する必要があります。
A new Capability Parameter TLV is defined, the MP2MP Capability. Following is the format of the MP2MP Capability Parameter.
新しい機能パラメーターTLVが定義されています。MP2MP機能。以下は、MP2MP機能パラメーターの形式です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| MP2MP Capability (0x0509) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
S: As specified in [RFC5561]
S：[RFC5561]で指定されています
The MP2MP Capability TLV MUST be advertised in the LDP Initialization message. Advertisement of the MP2MP Capability indicates support of the procedures for MP2MP LSP setup detailed in this document. If the peer has not advertised the corresponding capability, then label messages using the MP2MP upstream and downstream FEC Elements SHOULD NOT be sent to the peer.
MP2MP機能TLVは、LDP初期化メッセージに宣伝する必要があります。MP2MP機能の広告は、このドキュメントで詳述されているMP2MP LSPセットアップの手順のサポートを示しています。ピアが対応する機能を宣伝していない場合、MP2MPの上流および下流のFEC要素を使用してメッセージにラベルを付けて、ピアに送信しないでください。
For the setup of an MP2MP LSP with LDP, we define 2 new protocol entities, the MP2MP downstream FEC and upstream FEC Element. Both elements will be used as FEC Elements in the FEC TLV. Note that the MP2MP FEC Elements do not necessarily identify the traffic that must be mapped to the LSP, so from that point of view, the use of the term FEC is a misnomer. The description of the MP2MP FEC Elements follow.
LDPを搭載したMP2MP LSPのセットアップでは、2つの新しいプロトコルエンティティ、MP2MP下流FECと上流FEC要素を定義します。両方の要素は、FEC TLVのFEC要素として使用されます。MP2MP FEC要素は、LSPにマッピングする必要があるトラフィックを必ずしも識別しないことに注意してください。そのため、その観点から、FECという用語の使用は誤称であることに注意してください。MP2MP FEC要素の説明が続きます。
The structure, encoding, and error handling for the MP2MP downstream and upstream FEC Elements are the same as for the P2MP FEC Element described in Section 2.2. The difference is that two new FEC types are used: MP2MP downstream type (0x08) and MP2MP upstream type (0x07).
下流および上流のFEC要素のMP2MPの構造、エンコード、およびエラー処理は、セクション2.2で説明されているP2MP FEC要素の場合と同じです。違いは、2つの新しいFECタイプが使用されていることです：MP2MPダウンストリームタイプ（0x08）とMP2MPアップストリームタイプ（0x07）。
If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element MUST be the only FEC Element in the FEC TLV.
FEC TLVにMP2MP FEC要素が含まれている場合、MP2MP FEC要素がFEC TLVの唯一のFEC要素でなければなりません。
Note, except when using the procedures of [RFC5331], the MPLS labels used are "downstream-assigned" [RFC5332], even if they are bound to the "upstream FEC Element".
[RFC5331]の手順を使用する場合を除き、使用されるMPLSラベルは、「上流のFEC要素」にバインドされていても、「ダウンストリーム割り当て」[RFC5332]です。
This section defines the rules for the processing and propagation of the MP2MP FEC Elements. The following notation is used in the processing rules:
このセクションでは、MP2MP FEC要素の処理と伝播に関するルールを定義します。次の表記は、処理ルールで使用されます。
1. MP2MP downstream LSP <X, Y> (or simply downstream <X, Y>): an MP2MP LSP downstream path with root node address X and opaque value Y.
1. MP2MP下流LSP <x、y>（または単に下流<x、y>）：ルートノードアドレスxと不透明な値yを備えたmp2mp lsp下流パス
2. MP2MP upstream LSP <X, Y, D> (or simply upstream <X, Y, D>): an MP2MP LSP upstream path for downstream node D with root node address X and opaque value Y.
2. MP2MPアップストリームLSP <X、Y、D>（または単に上流<X、Y、D>）：ルートノードアドレスXおよびオパーク値Yを備えた下流ノードDのMP2MP LSPアップストリームパス。
3. MP2MP downstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y used for a downstream MP2MP LSP.
3. MP2MPダウンストリームFEC要素<X、Y>：下流MP2MP LSPに使用されるルートノードアドレスXおよび不透明な値Yを備えたFEC要素。
4. MP2MP upstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y used for an upstream MP2MP LSP.
4. MP2MPアップストリームFEC要素<X、Y>：ルートノードアドレスXと上流のMP2MP LSPに使用される不透明値Yを備えたFEC要素。
5. MP2MP-D Label Mapping <X, Y, L>: a Label Mapping message with a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and label TLV with label L. Label L MUST be allocated from the per-platform label space (see [RFC3031], Section 3.14) of the LSR sending the Label Mapping message. The use of the interface label space is outside the scope of this document.
5. MP2MP-Dラベルマッピング<X、Y、L>：単一のMP2MP下流FEC要素を備えたFEC TLVを備えたラベルマッピングメッセージ<X、Y>、ラベルLを備えたラベルTLV。ラベルマッピングメッセージを送信するLSRのラベルスペース（[RFC3031]、セクション3.14を参照）。インターフェイスラベルスペースの使用は、このドキュメントの範囲外です。
6. MP2MP-U Label Mapping <X, Y, Lu>: a Label Mapping message with a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and label TLV with label Lu. Label Lu MUST be allocated from the per-platform label space (see [RFC3031], Section 3.14) of the LSR sending the Label Mapping message. The use of the interface label space is outside the scope of this document.
6. MP2MP-Uラベルマッピング<X、Y、Lu>：FEC TLVを備えたラベルマッピングメッセージは、単一のMP2MP上流FEC要素<X、Y>、およびラベルTLVをラベルLUを備えたラベルTLVを備えています。ラベルLUは、LSRのラベルマッピングメッセージを送信するLSRのプラットフォームごとのラベルスペース（[RFC3031]、セクション3.14を参照）から割り当てる必要があります。インターフェイスラベルスペースの使用は、このドキュメントの範囲外です。
7. MP2MP-D Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and label TLV with label L.
7. MP2MP-Dラベル引き出し<x、y、l>：単一のmp2mp下流のFEC要素を備えたFEC TLVを備えたラベル引き出しメッセージ<x、y>、ラベルLを備えたラベルTLV。
8. MP2MP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and label TLV with label Lu.
8. MP2MP-Uラベル引き出し<x、y、lu>：単一のmp2mp上流のFEC要素を備えたFEC TLVを備えたラベル引き出しメッセージ<x、y>、ラベルTLVをラベルLu。
9. MP2MP-D Label Release <X, Y, L>: a Label Release message with a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and Label TLV with label L.
9. MP2MP-Dラベルリリース<X、Y、L>：単一のMP2MP下流FEC要素を備えたFEC TLVを備えたラベルリリースメッセージ<X、Y>、ラベルLを備えたラベルTLV。
10. MP2MP-U Label Release <X, Y, Lu>: a Label Release message with a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and label TLV with label Lu.
10. MP2MP-Uラベルリリース<X、Y、Lu>：単一のMP2MP上流FEC要素を備えたFEC TLVを備えたラベルリリースメッセージ<X、Y>、およびラベルLUを備えたラベルTLV。
The procedures below are organized by the role which the node plays in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery process that is outside the scope of this document. During the course of the protocol operation, the root node recognizes its role because it owns the root node address. A transit node is any node (other then the root node) that receives an MP2MP Label Mapping message (i.e., one that has leaf nodes downstream of it).
以下の手順は、ノードがMP2MP LSPで演じる役割によって整理されています。ノードZは、このドキュメントの範囲外の発見プロセスによるリーフノードであることを知っています。プロトコル操作の過程で、ルートノードがルートノードアドレスを所有しているため、ルートノードはその役割を認識します。トランジットノードは、MP2MPラベルマッピングメッセージ（つまり、葉の下流のノードがあるもの）を受信する任意のノード（ルートノード以外）です。
Note that a transit node (and indeed the root node) may also be a leaf node and the root node does not have to be an Ingress LSR or a leaf of the MP2MP LSP.
トランジットノード（および実際にはルートノード）もリーフノードであり、ルートノードは侵入LSRまたはMP2MP LSPの葉である必要はないことに注意してください。
The remainder of this section specifies the procedures for originating MP2MP Label Mapping messages and for processing received MP2MP Label Mapping messages for a particular LSP. The procedures for a particular LSR depend upon the role that the LSR plays in the LSP (Ingress, Transit, or Egress).
このセクションの残りの部分は、MP2MPラベルマッピングメッセージを発信する手順を指定し、特定のLSPの受信したMP2MPラベルマッピングメッセージを処理します。特定のLSRの手順は、LSRがLSPで果たす役割（イングレス、トランジット、または出口）に依存します。
All labels discussed here are downstream-assigned [RFC5332] except those that are assigned using the procedures of Section 6.
ここで説明するすべてのラベルは、セクション6の手順を使用して割り当てられるものを除き、下流で割り当てられた[RFC5332]です。
Determining the upstream LDP peer U for an MP2MP LSP <X, Y> follows the procedure for a P2MP LSP described in Section 2.4.1.1.
MP2MP LSP <X、Y>の上流LDPピアUを決定すると、セクション2.4.1.1で説明されているP2MP LSPの手順に従います。
An LDP peer U that receives an MP2MP-D Label Mapping from an LDP peer D will treat D as downstream MP2MP LSR.
LDPピアDからMP2MP-Dラベルマッピングを受信するLDPピアUは、Dを下流のMP2MP LSRとして扱います。
There are two methods for installing the upstream path of an MP2MP LSP to a downstream neighbor.
MP2MP LSPの上流パスを下流の隣人に設置する方法は2つあります。
1. We can install the upstream MP2MP path (to a downstream neighbor) based on receiving an MP2MP-D Label Mapping from the downstream neighbor. This will install the upstream path on a hop-by-hop basis.
1. 下流の隣人からMP2MP-Dラベルマッピングの受信に基づいて、上流のMP2MPパス（下流の隣人へ）をインストールできます。これにより、上流のパスがホップバイホップベースでインストールされます。
2. We install the upstream MP2MP path (to a downstream neighbor) based on receiving an MP2MP-U Label Mapping from the upstream neighbor. An LSR does not need to wait for the MP2MP-U Label Mapping if it is the root of the MP2MP LSP or if it already received an MP2MP-U Label Mapping from the upstream neighbor. We call this method ordered mode. The typical result of this mode is that the downstream path of the MP2MP is built hop by hop towards the root. Once the root is reached, the root node will trigger an MP2MP-U Label Mapping to the downstream neighbor(s).
2. 上流のMP2MPパス（下流の隣人へ）をインストールします。LSRは、MP2MP LSPのルートである場合、またはアップストリーム隣接からMP2MP-Uラベルマッピングを既に受け取った場合、MP2MP-Uラベルマッピングを待つ必要はありません。このメソッド順序モードと呼びます。このモードの典型的な結果は、MP2MPの下流パスがルートに向かってホップによってホップを構築することです。ルートに到達すると、ルートノードは、下流の隣人にMP2MP-Uラベルマッピングをトリガーします。
For setting up the upstream path of an MP2MP LSP, ordered mode SHOULD be used. Due to ordered mode, the upstream path of the MP2MP LSP is installed at the leaf node once the path to the root has completed. The advantage is that when a leaf starts sending immediately after the upstream path is installed, packets are able to reach the root
MP2MP LSPのアップストリームパスをセットアップするには、順序付けモードを使用する必要があります。順序付きモードにより、ルートへのパスが完了すると、MP2MP LSPの上流パスがリーフノードに設置されます。利点は、上流のパスがインストールされた直後に葉が送信し始めると、パケットがルートに到達できることです
node without being dropped due to an incomplete LSP. Method 1 is not able to guarantee that the upstream path has completed before the leaf starts sending.
不完全なLSPのためにドロップされることなくノード。方法1は、葉が送信を開始する前に上流のパスが完了したことを保証することができません。
A leaf node Z of an MP2MP LSP <X, Y> determines its upstream LSR U for <X, Y> as per Section 3.3.1.1, allocates a label L, and sends an MP2MP-D Label Mapping <X, Y, L> to U.
mp2mp lsp <x、y>のリーフノードzは、セクション3.3.1.1に従って<x、y>の上流LSR uを決定し、ラベルLを割り当て、mp2mp-dラベルマッピング<x、y、lを送信します> U.へ
Leaf node Z expects an MP2MP-U Label Mapping <X, Y, Lu> from node U in response to the MP2MP-D Label Mapping it sent to node U. Z checks whether it already has forwarding state for upstream <X, Y>. If not, Z creates forwarding state to push label Lu onto the traffic that Z wants to forward over the MP2MP LSP. How it determines what traffic to forward on this MP2MP LSP is outside the scope of this document.
リーフノードZは、ノードUに応答してノードUからNode Uから送信されたMP2MP-Uラベルマッピング<x、y、lu>を予想します。。そうでない場合、Zは転送状態を作成して、ZがMP2MP LSPを介して転送したいトラフィックにラベルLUを押します。このMP2MP LSPで転送するトラフィックがこのドキュメントの範囲外であるかどうかをどのように決定するか。
Suppose node Z receives an MP2MP-D Label Mapping <X, Y, L> from LSR D. Z checks whether it has forwarding state for downstream <X, Y>. If not, Z determines its upstream LSR U for <X, Y> as per Section 3.3.1.1. Using this Label Mapping to update the label forwarding table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U is different from LSR D, Z will allocate a label L' and install downstream forwarding state to swap label L' with label L over interface I associated with LSR D and send an MP2MP-D Label Mapping <X, Y, L'> to U. Interface I is determined via the procedures in Section 2.4.1.2.
Node ZがMP2MP-Dラベルマッピングを受信していると仮定します。LSRDから<X、Y、L> Zが下流<X、Y>の転送状態があるかどうかをチェックします。そうでない場合、zはセクション3.3.1.1に従って、<x、y>の上流LSR uを決定します。このラベルマッピングを使用してラベル転送テーブルを更新することは、LSR DがLSR Uに等しい限り、実行する必要はありません。LSRUがLSR Dと異なる場合、ZはラベルL 'を割り当て、下流の転送状態をラベルLにインストールします。'LSR Dに関連付けられたインターフェイスI上のラベルLを使用し、MP2MP-Dラベルマッピング<x、y、l'>をUに送信します。
If Z already has forwarding state for downstream <X, Y>, all that Z needs to do in this case is check that LSR D is not equal to the upstream LSR of <X, Y> and update its forwarding state. Assuming its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. If the LSR D is equal to the installed upstream LSR, the Label Mapping from LSR D MUST be retained and MUST NOT update the label forwarding table.
Zが既に下流<x、y>の転送状態を持っている場合、この場合に行う必要があるすべてのzは、LSR Dが<x、y>の上流LSRに等しくないことを確認し、その転送状態を更新します。その古い転送状態がl ' - > {<i1、l1> <i2、l2> ...、<in、ln>}であると仮定すると、その新しい転送状態はl' - > {<i1、l1> <i2、l2> ...、<in、ln>、<i、l>}。LSR DがインストールされているアップストリームLSRに等しい場合、LSR Dからのラベルマッピングを保持する必要があり、ラベル転送テーブルを更新しないでください。
Node Z checks if upstream LSR U already assigned a label Lu to <X, Y>. If not, transit node Z waits until it receives an MP2MP-U Label Mapping <X, Y, Lu> from LSR U (see Section 3.3.1.3). Once the MP2MP-U Label Mapping is received from LSR U, node Z checks whether it already has forwarding state upstream <X, Y, D>. If it does, then no further action needs to happen. If it does not, it allocates a label Lu' and creates a new label swap for Lu' with label Lu over interface Iu. Interface Iu is determined via the procedures in Section 2.4.1.2. In addition, it also adds the label swap(s) from
ノードZは、上流のLSR Uがすでに<x、y>にラベルを割り当てているかどうかをチェックします。そうでない場合、TransitノードZは、LSR UからMP2MP-Uラベルマッピング<X、Y、Lu>を受信するまで待機します（セクション3.3.1.3を参照）。MP2MP-UラベルマッピングがLSR uから受信されると、Node Zは既に上流の状態<x、y、d>を転送しているかどうかを確認します。もしそうなら、それ以上のアクションが発生する必要はありません。そうでない場合は、ラベルlu 'を割り当て、インターフェイスIU上のラベルLuを使用してLu'の新しいラベルスワップを作成します。インターフェイスIUは、セクション2.4.1.2の手順を介して決定されます。さらに、それはまた、からのラベルのスワップを追加します
the forwarding state downstream <X, Y>, omitting the swap on interface I for node D. The swap on interface I for node D is omitted to prevent a packet originated by D to be forwarded back to D.
下流の下流状態<x、y>、ノードDのインターフェイスIでスワップを省略します。ノードDのインターフェイスIのスワップIは省略されており、dが起源とするパケットがDに転送されるのを防ぎます。
Node Z determines the downstream MP2MP LSR as per Section 3.3.1.2, and sends an MP2MP-U Label Mapping <X, Y, Lu'> to node D.
ノードZは、セクション3.3.1.2に従ってダウンストリームMP2MP LSRを決定し、MP2MP-Uラベルマッピング<x、y、lu '>をノードDに送信します。
Suppose root/leaf node Z receives an MP2MP-D Label Mapping <X, Y, L> from node D. Z checks whether it already has forwarding state downstream <X, Y>. If not, Z creates downstream forwarding state to push label L on traffic that Z wants to forward down the MP2MP LSP. How it determines what traffic to forward on this MP2MP LSP is outside the scope of this document. If Z already has forwarding state for downstream <X, Y>, then Z will add the label push for L over interface I to it. Interface I is determined via the procedures in Section 2.4.1.2.
ルート/リーフノードZがNode DからMP2MP-Dラベルマッピング<x、y、l>を受信しているとします。Zは、既に下流の状態があるかどうかをチェックします<x、y>。そうでない場合、Zは下流の転送状態を作成して、ZがMP2MP LSPを転送したいトラフィックにラベルLを押します。このMP2MP LSPで転送するトラフィックがこのドキュメントの範囲外であるかどうかをどのように決定するか。Zが既に下流<x、y>の転送状態を持っている場合、zはインターフェイスIにlのラベルプッシュを追加します。インターフェイスIは、セクション2.4.1.2の手順を介して決定されます。
Node Z checks if it has forwarding state for upstream <X, Y, D>. If not, Z allocates a label Lu' and creates upstream forwarding state to swap Lu' with the label swap(s) from the forwarding state downstream <X, Y>, except the swap on interface I for node D. This allows upstream traffic to go down the MP2MP to other node(s), except the node from which the traffic was received. Node Z determines the downstream MP2MP LSR as per section Section 3.3.1.2, and sends an MP2MP-U Label Mapping <X, Y, Lu'> to node D. Since Z is the root of the tree, Z will not send an MP2MP-D Label Mapping and will not receive an MP2MP-U Label Mapping.
ノードZは、上流<x、y、d>の転送状態があるかどうかを確認します。そうでない場合、zはラベルLu 'を割り当て、上流の転送状態を作成してLu'を転送して転送状態の下流のスワップ<x、y>からスワップします<x、y>。トラフィックが受信されたノードを除き、MP2MPを他のノードに下げます。ノードZセクション3.3.3.1.2に従ってダウンストリームMP2MP LSRを決定し、MP2MP-Uラベルマッピング<x、y、lu '>をノードDに送信しますzはツリーのルートであるため、zはmp2mpを送信しません-dラベルマッピングとMP2MP-Uラベルマッピングは受け取りません。
Suppose the root node Z receives an MP2MP-D Label Mapping <X, Y, L> from node D. Z checks whether it already has forwarding state for downstream <X, Y>. If not, Z creates downstream forwarding state and installs a outgoing label L over interface I. Interface I is determined via the procedures in Section 2.4.1.2. If Z already has forwarding state for downstream <X, Y>, then Z will add label L over interface I to the existing state.
ルートノードZがNode DからMP2MP-Dラベルマッピング<x、y、l>を受信しているとします。Zが下流<x、y>の転送状態を既に持っているかどうかをチェックします。そうでない場合、Zは下流の転送状態を作成し、インターフェイスIに発信ラベルLをインストールします。インターフェイスIは、セクション2.4.1.2の手順を介して決定されます。Zが既に下流<x、y>の転送状態を持っている場合、zは既存の状態にインターフェイスIにラベルLを追加します。
Node Z checks if it has forwarding state for upstream <X, Y, D>. If not, Z allocates a label Lu' and creates forwarding state to swap Lu' with the label swap(s) from the forwarding state downstream <X, Y>, except the swap for node D. This allows upstream traffic to go down the MP2MP to other node(s), except the node from which it was
ノードZは、上流<x、y、d>の転送状態があるかどうかを確認します。そうでない場合、zはラベルLu 'を割り当て、転送状態を作成して、下流の転送状態からラベルスワップと交換します<x、y>。他のノードへのmp2mp（s）。
received. Root node Z determines the downstream MP2MP LSR D as per Section 3.3.1.2, and sends an MP2MP-U Label Mapping <X, Y, Lu'> to it. Since Z is the root of the tree, Z will not send an MP2MP-D Label Mapping and will not receive an MP2MP-U Label Mapping.
受け取った。ルートノードZは、セクション3.3.1.2に従って下流のMP2MP LSR Dを決定し、MP2MP-Uラベルマッピング<X、Y、lu '>を送信します。Zはツリーのルートであるため、ZはMP2MP-Dラベルマッピングを送信せず、MP2MP-Uラベルマッピングを受け取りません。
The following section lists procedures for generating and processing MP2MP Label Withdraw messages for nodes that participate in an MP2MP LSP. An LSR should apply those procedures that apply to it, based on its role in the MP2MP LSP.
次のセクションには、MP2MP LSPに参加するノードのMP2MPラベル引き出しメッセージを生成および処理する手順を示します。LSRは、MP2MP LSPでの役割に基づいて、それに適用される手順を適用する必要があります。
If a leaf node Z discovers (by means outside the scope of this document) that it has no downstream neighbors in that LSP and that it has no need to be an Egress LSR for that LSP (by means outside the scope of this document), then it SHOULD send an MP2MP-D Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is the label it had previously advertised to U for <X,Y>. Leaf node Z will also send an unsolicited label release <X, Y, Lu> to U to indicate that the upstream path is no longer used and that label Lu can be removed.
リーフノードZが（このドキュメントの範囲外の手段によって）、そのLSPに下流の隣人がなく、そのLSPの出口LSRである必要がないことを発見した場合（このドキュメントの範囲外）、次に、MP2MP-Dラベルの引き出し<x、y、l>を上流のlsr uに送信します。Leaf Node Zは、上流のパスが使用されなくなり、ラベルLUを削除できることを示すために、未承諾のラベルリリース<x、y、lu>もuに送信します。
Leaf node Z expects the upstream router U to respond by sending a downstream label release for L.
Leaf Node Zは、上流のルーターUがLのダウンストリームラベルリリースを送信することにより応答することを期待しています。
If a transit node Z receives an MP2MP-D Label Withdraw message <X, Y, L> from node D, it deletes label L from its forwarding state downstream <X, Y> and from all its upstream states for <X, Y>. Node Z sends an MP2MP-D Label Release message with label L to D. Since node D is no longer part of the downstream forwarding state, Z cleans up the forwarding state upstream <X, Y, D>. There is no need to send an MP2MP-U Label Withdraw <X, Y, Lu> to D because node D already removed Lu and sent a label release for Lu to Z.
トランジットノードZがMP2MP-Dラベルの引き出しメッセージを受信した場合、ノードDから<x、y、l>を削除します。。ノードZは、ラベルLを使用してMP2MP-DラベルリリースメッセージをDに送信します。NodeDは下流の転送状態の一部ではなくなったため、Zは上流<X、Y、D>をクリーンアップします。ノードDがすでにluを削除し、Luのラベルリリースをzに送信したため、mp2mp-uラベルの引き出し<x、y、lu>をDに送信する必要はありません。
If deleting L from Z's forwarding state for downstream <X, Y> results in no state remaining for <X, Y>, then Z propagates the MP2MP-D Label Withdraw <X, Y, L> to its upstream node U for <X, Y> and will also send an unsolicited MP2MP-U Label Release <X, Y, Lu> to U to indicate that the upstream path is no longer used and that label Lu can be removed.
下流のZの転送状態からlを削除する場合、<x、y>が<x、y>に対して残っている状態はなく、zはmp2mp-dラベルの引き出し<x、y、l>を上流ノードuに伝播します<x、y> and and willは、Untaleatited MP2MP-Uラベルのリリース<x、y、lu>をuに送信して、上流のパスが使用されなくなり、ラベルLuを削除できることを示します。
When the root node of an MP2MP LSP receives an MP2MP-D Label Withdraw message, the procedure is the same as that for transit nodes, except that the root node will not propagate the Label Withdraw upstream (as it has no upstream).
MP2MP LSPのルートノードがMP2MP-Dラベルの引き出しメッセージを受信すると、ルートノードが上流の撤回を伝播しないことを除いて、トランジットノードの手順と同じです（アップストリームがないため）。
The procedure for changing the upstream LSR is the same as documented in Section 2.4.3, except it is applied to MP2MP FECs, using the procedures described in Section 3.3.1 through Section 3.3.2.3.
上流のLSRを変更する手順は、セクション3.3.1からセクション3.3.2.3で説明されている手順を使用して、MP2MP FECに適用されることを除いて、セクション2.4.3で文書化されたものと同じです。
Micro-loops created by the unicast routing protocol during convergence may also effect mLDP MP LSPs. Since the tree building logic in mLDP is based on unicast routing, a unicast routing loop may also result in a micro-loop in the MP LSPs. Micro-loops that involve 2 directly connected routers don't create a loop in mLDP. mLDP is able to prevent this inconsistency by never allowing an upstream LDP neighbor to be added as a downstream LDP neighbor into the Label Forwarding Table (LFT) for the same FEC. Micro-loops that involve more than 2 LSRs are not prevented.
収束中にユニキャストルーティングプロトコルによって作成されたマイクロループは、MLDP MP LSPにも影響を与える可能性があります。MLDPのツリービルディングロジックはユニキャストルーティングに基づいているため、ユニキャストルーティングループはMP LSPにマイクロループをもたらす可能性があります。直接接続された2つのルーターを含むマイクロループは、MLDPでループを作成しません。MLDPは、同じFECのラベル転送テーブル（LFT）に下流のLDP隣人として上流のLDP隣人を追加することを許可することにより、この矛盾を防ぐことができます。2つ以上のLSRを含むマイクロループは防止されません。
Micro-loops that involve more than 2 LSRs may create a micro-loop in the downstream path of either an MP2MP LSP or P2MP LSP and the upstream path of the MP2MP LSP. The loops are transient and will disappear as soon as the unicast routing protocol converges and mLDP has updated the forwarding state accordingly. Micro-loops that occur in the upstream path of an MP2MP LSP may be detected by including LDP path vector in the MP2MP-U Label Mapping messages. These procedures are currently under investigation and are subjected to further study.
2つ以上のLSRを含むマイクロループは、MP2MP LSPまたはP2MP LSPの下流パスとMP2MP LSPの上流経路にマイクロループを作成する可能性があります。ループは一時的であり、ユニキャストルーティングプロトコルが収束し、MLDPがそれに応じて転送状態を更新するとすぐに消えます。MP2MP LSPの上流パスで発生するマイクロループは、MP2MP-UラベルマッピングメッセージにLDPパスベクトルを含めることにより検出できます。これらの手順は現在調査中であり、さらなる研究の対象となっています。
An LDP MP capable router MAY use an LDP MP Status TLV to indicate additional status for an MP LSP to its remote peers. This includes signaling to peers that are either upstream or downstream of the LDP MP capable router. The value of the LDP MP Status TLV will remain opaque to LDP and MAY encode one or more status elements.
LDP MP対応ルーターは、LDP MPステータスTLVを使用して、MP LSPの追加ステータスをリモートピアに示すことができます。これには、LDP MP対応ルーターの上流または下流のピアへのシグナリングが含まれます。LDP MPステータスTLVの値は、LDPに不透明なままであり、1つ以上のステータス要素をエンコードする場合があります。
The LDP MP Status TLV is encoded as follows:
LDP MPステータス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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| LDP MP Status Type(0x096F)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LDP MP Status Type: The LDP MP Status (0x096F).
LDP MPステータスタイプ：LDP MPステータス（0x096F）。
Length: Length of the LDP MP Status Value in octets.
長さ：オクテットのLDP MPステータス値の長さ。
Value: One or more LDP MP Status Value elements.
値：1つ以上のLDP MPステータス値要素。
The LDP MP Status Value Element that is included in the LDP MP Status TLV Value has the following encoding.
LDP MPステータスTLV値に含まれるLDP MPステータス値要素には、次のエンコードがあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the LDP MP Status Value Element. IANA maintains a registry of status value types (see Section 11).
タイプ：LDP MPステータス値要素のタイプ。IANAは、ステータス値タイプのレジストリを維持しています（セクション11を参照）。
Length: The length of the Value field, in octets.
長さ：オクテット内の値フィールドの長さ。
Value: String of Length octets, to be interpreted as specified by the Type field.
値：型フィールドで指定されていると解釈される長さのオクテットの文字列。
The LDP MP Status TLV may appear either in a Label Mapping message or an LDP Notification message.
LDP MPステータスTLVは、ラベルマッピングメッセージまたはLDP通知メッセージのいずれかに表示される場合があります。
An LDP MP Status TLV sent in a notification message must be accompanied with a Status TLV, as described in [RFC5036]. The general format of the Notification message with an LDP MP Status TLV is:
[RFC5036]で説明されているように、通知メッセージで送信されたLDP MPステータスTLVには、ステータスTLVを伴う必要があります。LDP MPステータス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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP MP Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional LDP MP FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV status code is used to indicate that LDP MP Status TLV and any additional information follows in the Notification message's "optional parameter" section. Depending on the actual contents of the LDP MP Status TLV, an LDP P2MP or MP2MP FEC TLV and a Label TLV may also be present to provide context to the LDP MP Status TLV.
ステータスTLVステータスコードは、LDP MPステータスTLVと追加情報が通知メッセージの「オプションパラメーター」セクションに続くことを示すために使用されます。LDP MPステータスTLVの実際の内容に応じて、LDP P2MPまたはMP2MP FEC TLVおよびラベルTLVがLDP MPステータスTLVにコンテキストを提供するために存在する場合があります。
Since the notification does not refer to any particular message, the Message ID and Message Type fields are set to 0.
通知は特定のメッセージを参照していないため、メッセージIDとメッセージタイプフィールドは0に設定されます。
An example of the Label Mapping message defined in [RFC5036] is shown below to illustrate the message with an Optional LDP MP Status TLV present.
[RFC5036]で定義されているラベルマッピングメッセージの例を以下に示し、オプションのLDP MPステータス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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional LDP MP Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
On a LAN, the procedures so far discussed would require the upstream LSR to send a copy of the packet to each receiver individually. If there is more than one receiver on the LAN, we don't take full benefit of the multi-access capability of the network. We may optimize the bandwidth consumption on the LAN and replication overhead on the upstream LSR by using upstream label allocation [RFC5331]. Procedures on how to distribute upstream labels using LDP is documented in [RFC6389].
LANでは、これまでに議論された手順では、上流のLSRが各レシーバーに個別にパケットのコピーを送信する必要があります。LANに複数のレシーバーがある場合、ネットワークのマルチアクセス機能の完全な利益はありません。上流のラベル割り当て[RFC5331]を使用して、上流LSRのLANおよび上流のLSRの帯域幅の消費量を最適化する場合があります。LDPを使用して上流のラベルを配布する方法に関する手順は、[RFC6389]で文書化されています。
The procedure to allocate a context label on a LAN is defined in [RFC5331]. That procedure results in each LSR on a given LAN having a context label which, on that LAN, can be used to identify itself uniquely. Each LSR advertises its context label as an upstream-assigned label, following the procedures of [RFC6389]. Any LSR for which the LAN is a downstream link on some P2MP or MP2MP LSP will allocate an upstream-assigned label identifying that LSP. When the LSR forwards a packet downstream on one of those LSPs, the packet's top label must be the LSR's context label, and the packet's second label is the label identifying the LSP. We will call the top label the "upstream LSR label" and the second label the "LSP label".
LANにコンテキストラベルを割り当てる手順は、[RFC5331]で定義されています。その手順では、特定のLANの各LSRがコンテキストラベルを備えているため、そのLANでは、独自の識別に使用できます。各LSRは、[RFC6389]の手順に従って、コンテキストラベルを上流のラベルとして宣伝しています。LANがいくつかのP2MPまたはMP2MP LSPの下流リンクであるLSRは、そのLSPを識別して上流で割り当てられたラベルを割り当てます。LSRがこれらのLSPの1つで下流のパケットを転送する場合、パケットのトップラベルはLSRのコンテキストラベルでなければならず、パケットの2番目のラベルはLSPを識別するラベルです。トップラベルを「アップストリームLSRラベル」と呼び、2番目のラベルは「LSPラベル」と呼びます。
The downstream path of an MP2MP LSP is much like a normal P2MP LSP, so we will use the same procedures as those defined in [RFC6389]. A label request for an LSP label is sent to the upstream LSR. The Label Mapping that is received from the upstream LSR contains the LSP label for the MP2MP FEC and the upstream LSR context label. The MP2MP downstream path (corresponding to the LSP label) will be installed in the context-specific forwarding table corresponding to the upstream LSR label. Packets sent by the upstream router can be forwarded downstream using this forwarding state based on a two-label lookup.
MP2MP LSPの下流パスは、通常のP2MP LSPによく似ているため、[RFC6389]で定義されている手順と同じ手順を使用します。LSPラベルのラベル要求がアップストリームLSRに送信されます。上流のLSRから受信したラベルマッピングには、MP2MP FECおよび上流LSRコンテキストラベルのLSPラベルが含まれています。MP2MPダウンストリームパス（LSPラベルに対応）は、アップストリームLSRラベルに対応するコンテキスト固有の転送テーブルにインストールされます。上流のルーターから送信されたパケットは、2ラベルの検索に基づいてこの転送状態を使用して下流に転送できます。
An MP2MP LSP also has an upstream forwarding path. Upstream packets need to be forwarded in the direction of the root and downstream on any node on the LAN that has a downstream interface for the LSP. For a given MP2MP LSP on a given LAN, exactly one LSR is considered to be the upstream LSR. If an LSR on the LAN receives a packet from one of its downstream interfaces for the LSP, and if it needs to forward the packet onto the LAN, it ensures that the packet's top label is the context label of the upstream LSR, and that its second label is the LSP label that was assigned by the upstream LSR.
MP2MP LSPには、上流の転送パスもあります。上流のパケットは、LSPの下流インターフェイスを備えたLAN上の任意のノードのルートの方向と下流に転送する必要があります。特定のLAN上の特定のMP2MP LSPの場合、1つのLSRが上流LSRと見なされます。LAN上のLSRがLSPの下流インターフェイスの1つからパケットを受信し、パケットをLANに転送する必要がある場合、パケットのトップラベルがアップストリームLSRのコンテキストラベルであり、2番目のラベルは、上流のLSRによって割り当てられたLSPラベルです。
Other LSRs receiving the packet will not be able to tell whether the packet really came from the upstream router, but that makes no difference in the processing of the packet. The upstream LSR will see its own upstream LSR in the label, and this will enable it to determine that the packet is traveling upstream.
パケットを受け取る他のLSRは、パケットが実際に上流のルーターから来たかどうかを判断できませんが、パケットの処理に違いはありません。上流のLSRは、ラベルに独自のアップストリームLSRが表示され、これによりパケットが上流に移動していることが判断できます。
The root node is a single point of failure for an MP LSP, whether the MP LSP is P2MP or MP2MP. The problem is particularly severe for MP2MP LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same root node to set up the MP2MP LSP, because otherwise the traffic sourced by some leafs is not received by others. Because the root node is the single point of failure for an MP LSP, we need a fast and efficient mechanism to recover from a root node failure.
ルートノードは、MP LSPがP2MPまたはMP2MPであるかどうかにかかわらず、MP LSPの単一の障害点です。この問題は、MP2MP LSPで特に深刻です。MP2MP LSPの場合、すべてのリーフノードは同じルートノードを使用してMP2MP LSPをセットアップする必要があります。ルートノードはMP LSPの単一の障害点であるため、ルートノード障害から回復するために高速で効率的なメカニズムが必要です。
An MP LSP is uniquely identified in the network by the opaque value and the root node address. It is likely that the root node for an MP LSP will be defined statically. The root node address may be configured on each leaf statically or learned using a dynamic protocol. How leafs learn about the root node is out of the scope of this document.
MP LSPは、不透明な値とルートノードアドレスによってネットワークで一意に識別されます。MP LSPのルートノードが静的に定義される可能性があります。ルートノードアドレスは、各リーフで静的に構成するか、動的プロトコルを使用して学習することができます。ルートノードについてリーフがどのように学習するかは、このドキュメントの範囲外です。
Suppose that for the same opaque value we define two (or more) root node addresses, and we build a tree to each root using the same opaque value. Effectively these will be treated as different MP LSPs in the network. Once the trees are built, the procedures differ for P2MP and MP2MP LSPs. The different procedures are explained in the sections below.
同じ不透明な値に対して、2つ（またはそれ以上）のルートノードアドレスを定義し、同じ不透明な値を使用して各ルートにツリーを構築するとします。事実上、これらはネットワーク内の異なるMP LSPとして扱われます。木が建設されると、P2MPとMP2MP LSPの手順は異なります。以下のセクションでは、さまざまな手順について説明します。
Since all leafs have set up P2MP LSPs to all the roots, they are prepared to receive packets on either one of these LSPs. However, only one of the roots should be forwarding traffic at any given time, for the following reasons: 1) to achieve bandwidth savings in the network and 2) to ensure that the receiving leafs don't receive duplicate packets (since one cannot assume that the receiving leafs are able to discard duplicates). How the roots determine which one is the active sender is outside the scope of this document.
すべての葉がすべての根にP2MP LSPをセットアップしているため、これらのLSPのいずれかでパケットを受け取る準備ができています。ただし、次の理由により、根の1つだけが任意の時点でトラフィックを転送する必要があります。1）ネットワークで帯域幅の節約を達成すること、2）受信葉が重複パケットを受け取らないようにするため（1つは想定できないため、受信葉が複製を破棄できること。ルートがどのようにアクティブ送信者がこのドキュメントの範囲外であるかを決定する方法。
Since all leafs have set up an MP2MP LSP to each one of the root nodes for this opaque value, a sending leaf may pick either of the two (or more) MP2MP LSPs to forward a packet on. The leaf nodes receive the packet on one of the MP2MP LSPs. The client of the MP2MP LSP does not care on which MP2MP LSP the packet is received, as long as they are for the same opaque value. The sending leaf MUST only forward a packet on one MP2MP LSP at a given point in time. The receiving leafs are unable to discard duplicate packets because they accept on all LSPs. Using all the available MP2MP LSPs, we can implement redundancy using the following procedures.
すべての葉がこの不透明な値のルートノードのそれぞれにMP2MP LSPを設定しているため、送信葉は2つ（またはそれ以上）のMP2MP LSPのいずれかを選択してパケットを転送することができます。葉のノードは、MP2MP LSPの1つでパケットを受け取ります。MP2MP LSPのクライアントは、同じ不透明な値である限り、どのMP2MP LSPが受信されるかを気にしません。送信葉は、特定の時点で1つのMP2MP LSPにパケットを転送する必要があります。受信葉は、すべてのLSPで受け入れるため、重複したパケットを破棄することができません。利用可能なすべてのMP2MP LSPを使用して、次の手順を使用して冗長性を実装できます。
A sending leaf selects a single root node out of the available roots for a given opaque value. A good strategy MAY be to look at the unicast routing table and select a root that is closest in terms of the unicast metric. As soon as the root address of the active root disappears from the unicast routing table (or becomes less attractive) due to root node or link failure, the leaf can select a new best root address and start forwarding to it directly. If multiple root nodes have the same unicast metric, the highest root node addresses MAY be selected, or per session load balancing MAY be done over the root nodes.
送信葉は、特定の不透明な値に対して使用可能なルートから単一のルートノードを選択します。優れた戦略は、ユニキャストルーティングテーブルを見て、ユニキャストメトリックに関して最も近いルートを選択することです。ルートノードまたはリンク障害により、アクティブルートのルートアドレスがユニキャストルーティングテーブルから消える（または魅力的ではなくなる）とすぐに、葉は新しい最適なルートアドレスを選択し、直接転送を開始できます。複数のルートノードが同じユニキャストメトリックを持っている場合、最も高いルートノードアドレスを選択するか、セッションごとの負荷分散をルートノードで実行できます。
All leafs participating in an MP2MP LSP MUST join all the available root nodes for a given opaque value. Since the sending leaf may pick any MP2MP LSP, it must be prepared to receive on it.
MP2MP LSPに参加しているすべてのリーフは、特定の不透明な値のために利用可能なすべてのルートノードを結合する必要があります。送信葉はMP2MP LSPを選ぶかもしれないので、それを受け取る準備をする必要があります。
The advantage of pre-building multiple MP2MP LSPs for a single opaque value is that convergence from a root node failure happens as fast as
単一の不透明な値に対して複数のMP2MP LSPを事前に構築する利点は、ルートノード障害からの収束が速く発生することです
the unicast routing protocol is able to notify. There is no need for an additional protocol to advertise to the leaf nodes which root node is the active root. The root selection is a local leaf policy that does not need to be coordinated with other leafs. The disadvantage of pre-building multiple MP2MP LSPs is that more label resources are used, depending on how many root nodes are defined.
ユニキャストルーティングプロトコルに通知することができます。ルートノードがアクティブルートであるリーフノードに宣伝する追加のプロトコルは必要ありません。ルート選択は、他の葉と調整する必要のないローカルリーフポリシーです。複数のMP2MP LSPを事前に構築することの欠点は、定義されているルートノードの数に応じて、より多くのラベルリソースが使用されることです。
An LSR selects the LSR that is its next hop to the root of the LSP as its upstream LSR for an MP LSP. When the best path to reach the root changes, the LSR must choose a new upstream LSR. Sections 2.4.3 and 3.3.3 describe these procedures.
LSRは、MP LSPの上流LSRとして、LSPのルートへの次のホップであるLSRを選択します。ルートに到達するための最適なパスが変更された場合、LSRは新しいアップストリームLSRを選択する必要があります。セクション2.4.3および3.3.3は、これらの手順について説明します。
When the best path to the root changes, the LSP may be broken temporarily resulting in packet loss until the LSP "reconverges" to a new upstream LSR. The goal of MBB when this happens is to keep the duration of packet loss as short as possible. In addition, there are scenarios where the best path from the LSR to the root changes but the LSP continues to forward packets to the previous next hop to the root. That may occur when a link comes up or routing metrics change. In such a case, a new LSP should be established before the old LSP is removed to limit the duration of packet loss. The procedures described below deal with both scenarios in a way that an LSR does not need to know which of the events described above caused its upstream router for an MBB LSP to change.
ルートへの最適なパスが変化すると、LSPが一時的に壊れて、LSPが新しいアップストリームLSRに「再溶融」するまでパケット損失をもたらす可能性があります。これが起こるときのMBBの目標は、パケット損失の期間をできるだけ短くすることです。さらに、LSRからルートへの最適なパスが変更されるシナリオがありますが、LSPは前の次のホップにルートにパケットを転送し続けます。これは、リンクが発生したり、メトリックをルーティングしたりすると発生する可能性があります。そのような場合、パケット損失の期間を制限するために、古いLSPが削除される前に、新しいLSPを確立する必要があります。以下に説明する手順は、上記のイベントのどれがMBB LSPの上流ルーターを変更したかを知る必要がないという方法で、両方のシナリオを扱います。
The MBB procedures are an optional extension to the MP LSP building procedures described in this document. The procedures in this section offer a make-before-break behavior, except in cases where the new path is part of a transient routing loop involving more than 2 LSRs (also see Section 4).
MBB手順は、このドキュメントで説明されているMP LSP構築手順のオプションの拡張機能です。このセクションの手順では、新しいパスが2つ以上のLSRを含む一時的なルーティングループの一部である場合を除き、ブレイク前の動作を提供します（セクション4も参照）。
The MBB procedures use additional LDP signaling.
MBB手順では、追加のLDPシグナル伝達が使用されます。
Suppose some event causes a downstream LSR-D to select a new upstream LSR-U for FEC-A. The new LSR-U may already be forwarding packets for FEC-A; that is, to downstream LSRs other than LSR-D. After LSR-U receives a label for FEC-A from LSR-D, it will notify LSR-D when it knows that the LSP for FEC-A has been established from the root to itself. When LSR-D receives this MBB notification, it will change its next hop for the LSP root to LSR-U.
いくつかのイベントが下流のLSR-Dを引き起こし、FEC-Aの新しいアップストリームLSR-Uを選択するとします。新しいLSR-Uは、すでにFEC-Aのパケットを転送している可能性があります。つまり、LSR-D以外の下流のLSRに。LSR-UがLSR-DからFEC-Aのラベルを受け取った後、FEC-AのLSPがルートからそれ自体に確立されていることを知っている場合、LSR-Dに通知します。LSR-DがこのMBB通知を受信すると、LSPルートの次のホップがLSR-Uに変更されます。
The assumption is that if LSR-U has received an MBB notification from its upstream router for the FEC-A LSP and has installed forwarding state, the LSR is capable of forwarding packets on the LSP. At that
仮定は、LSR-UがFEC-A LSPの上流ルーターからMBB通知を受け取り、転送状態をインストールした場合、LSRはLSPでパケットを転送できることです。その時
point LSR-U should signal LSR-D by means of an MBB notification that it has become part of the tree identified by FEC-A and that LSR-D should initiate its switchover to the LSP.
Point LSR-Uは、MBB通知を使用してLSR-Dを信号し、FEC-Aによって識別されたツリーの一部になり、LSR-DがLSPへのスイッチオーバーを開始する必要があります。
At LSR-U, the LSP for FEC-A may be in 1 of 3 states.
LSR-Uでは、FEC-AのLSPは3つの州のうち1つにある可能性があります。
1. There is no state for FEC-A.
1. FEC-Aの状態はありません。
2. State for FEC-A exists and LSR-U is waiting for MBB notification that the LSP from the root to it exists.
2. FEC-Aの状態が存在し、LSR-UはルートからそれまでのLSPが存在することをMBB通知を待っています。
3. State for FEC-A exists and the MBB notification has been received or it is the root node for FEC-A.
3. FEC-Aの状態が存在し、MBB通知が受信されたか、FEC-Aのルートノードです。
After LSR-U receives LSR-D's Label Mapping message for FEC-A, LSR-U MUST NOT reply with an MBB notification to LSR-D until its state for the LSP is state #3 above. If the state of the LSP at LSR-U is state #1 or #2, LSR-U should remember receipt of the Label Mapping message from LSR-D while waiting for an MBB notification from its upstream LSR for the LSP. When LSR-U receives the MBB notification from LSR-U, it transitions to LSP state #3 and sends an MBB notification to LSR-D.
LSR-UがFEC-AのLSR-Dのラベルマッピングメッセージを受信した後、LSR-UはLSPの状態が上記の状態になるまで、LSR-DにMBB通知で返信してはなりません。LSR-UのLSPの状態が状態＃1または＃2の場合、LSR-UはLSPの上流LSRからのMBB通知を待っている間に、LSR-Dからのラベルマッピングメッセージの受信を覚えておく必要があります。LSR-UがLSR-UからMBB通知を受け取ると、LSP状態＃3に移行し、MBB通知をLSR-Dに送信します。
As noted in Section 8.1, the procedures for establishing an MBB MP LSP are different from those for establishing normal MP LSPs.
セクション8.1で述べたように、MBB MP LSPを確立する手順は、通常のMP LSPを確立するものとは異なります。
When a downstream LSR sends a Label Mapping message for MP LSP to its upstream LSR, it MAY include an LDP MP Status TLV that carries an MBB Status Code to indicate that MBB procedures apply to the LSP. This new MBB Status Code MAY also appear in an LDP Notification message used by an upstream LSR to signal LSP state #3 to the downstream LSR; that is, that the upstream LSRs state for the LSP exists and that it has received notification from its upstream LSR that the LSP is in state #3.
下流LSRがMP LSPのラベルマッピングメッセージを上流LSRに送信すると、MBBステータスコードを運ぶLDP MPステータスTLVがLSPに適用されることを示すLDP MPステータスTLVが含まれる場合があります。この新しいMBBステータスコードは、上流のLSRによって使用されるLDP通知メッセージにも表示される場合があります。つまり、LSPの上流LSRS状態が存在し、上流のLSRからLSPが状態＃3にあるという通知を受け取ったことです。
The MBB Status is a type of the LDP MP Status Value Element as described in Section 5.1. It is encoded as follows:
MBBステータスは、セクション5.1で説明されているように、LDP MPステータス値要素の一種です。次のようにエンコードされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBB Type = 1 | Length = 1 | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBB Type: Type 1
MBBタイプ：タイプ1
Length: 1
長さ：1
Status Code: 1 = MBB request
ステータスコード：1 = MBBリクエスト
2 = MBB ack
An LSR MAY advertise that it is capable of handling MBB LSPs using the capability advertisement as defined in [RFC5561]. The LDP MP MBB capability has the following format:
LSRは、[RFC5561]で定義されているように、機能広告を使用してMBB LSPを処理できることを宣伝する場合があります。LDP MP MBB機能には、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| LDP MP MBB Capability | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
LDP MP MBB Capability: The MBB Capability Parameter (0x050A)
LDP MP MBB機能：MBB機能パラメーター（0x050A）
S: As specified in [RFC5561]
S：[RFC5561]で指定されています
If an LSR has not advertised that it is MBB capable, its LDP peers MUST NOT send it messages that include MBB parameters. If an LSR receives a Label Mapping message with an MBB parameter from downstream LSR-D and its upstream LSR-U has not advertised that it is MBB capable, the LSR MUST send an MBB notification immediately to LSR-U (see Section 8.4). If this happens, an MBB MP LSP will not be established, but a normal MP LSP will be the result.
LSRがMBB能力であると宣伝していない場合、そのLDPピアはMBBパラメーターを含むメッセージを送信してはなりません。LSRが下流のLSR-DからMBBパラメーターを使用してラベルマッピングメッセージを受信し、その上流のLSR-UがMBB能力であると宣伝していない場合、LSRはLSR-UにすぐにMBB通知を送信する必要があります（セクション8.4を参照）。これが発生した場合、MBB MP LSPは確立されませんが、通常のMP LSPが結果になります。
1. MBB LSP <X, Y>: A P2MP or MP2MP Make Before Break (MBB) LSP entry with root node address X and opaque value Y.
1. MBB LSP <X、Y>：ルートノードアドレスXおよび不透明な値Yを備えたP2MPまたはMP2MP Make Before Break（MBB）LSPエントリ。
2. A(N, L): An accepting element that consists of an upstream neighbor N and Local label L. This LSR assigned label L to neighbor N for a specific MBB LSP. For an active element, the corresponding label is stored in the label forwarding database.
2. A（n、l）：上流の隣接nとローカルラベルLで構成される受け入れ要素。アクティブな要素の場合、対応するラベルはラベル転送データベースに保存されます。
3. iA(N, L): An inactive accepting element that consists of an upstream neighbor N and local label L. This LSR assigned label L to neighbor N for a specific MBB LSP. For an inactive element,
3. IA（N、L）：上流の隣接NとローカルラベルLで構成される非アクティブな受け入れ要素。非アクティブな要素の場合、
the corresponding label is not stored in the label forwarding database.
対応するラベルは、ラベル転送データベースに保存されていません。
4. F(N, L): A Forwarding state that consists of downstream neighbor N and label L. This LSR is sending label packets with label L to neighbor N for a specific FEC.
4. f（n、l）：下流の隣接NとラベルLで構成される転送状態。
5. F'(N, L): A Forwarding state that has been marked for sending an MBB Notification message to neighbor N with label L.
5. f '（n、l）：ラベルlを使用してneight nにMBB通知メッセージを送信するためにマークされている転送状態。
6. MBB Notification <X, Y, L>: An LDP notification message with an MP LSP <X, Y>, label L, and MBB Status code 2.
6. MBB通知<X、Y、L>：MP LSP <X、Y>、ラベルL、およびMBBステータスコード2を使用したLDP通知メッセージ。
7. MBB Label Mapping <X, Y, L>: A P2MP Label Mapping or MP2MP Label Mapping downstream with a FEC element <X, Y>, label L, and MBB Status code 1.
7. MBBラベルマッピング<X、Y、L>：P2MPラベルマッピングまたはMP2MPラベルマッピング下流のFEC要素<X、Y>、ラベルL、およびMBBステータスコード1。
An accepting element represents a specific label value L that has been advertised to a neighbor N for an MBB LSP <X, Y> and is a candidate for accepting labels switched packets on. An LSR can have two accepting elements for a specific MBB LSP <X, Y> LSP, only one of them MUST be active. An active element is the element for which the label value has been installed in the label forwarding database. An inactive accepting element is created after a new upstream LSR is chosen and replacement the active element in the label forwarding database is pending. Inactive elements only exist temporarily while switching to a new upstream LSR. Once the switch has been completed, only one active element remains. During network convergence, it is possible that an inactive accepting element is created while another inactive accepting element is pending. If that happens, the older inactive accepting element MUST be replaced with a newer inactive element. If an accepting element is removed, a Label Withdraw has to be sent for label L to neighbor N for <X, Y>.
受け入れられる要素は、MBB LSP <X、Y>の近隣Nに宣伝された特定のラベル値Lを表し、スイッチされたパケットをオンにするラベルを受け入れる候補です。 LSRは、特定のMBB LSP <X、Y> LSPの2つの受け入れ要素を持つことができ、そのうちの1つだけがアクティブでなければなりません。アクティブな要素は、ラベル転送データベースにラベル値がインストールされている要素です。新しいアップストリームLSRが選択され、ラベル転送データベースのアクティブな要素が保留されている後に、非アクティブな受け入れ要素が作成されます。非アクティブな要素は、新しいアップストリームLSRに切り替えるときにのみ一時的に存在します。スイッチが完了すると、1つのアクティブな要素のみが残ります。ネットワークの収束中は、非アクティブな受け入れ要素が作成され、別の非アクティブな受け入れ要素が保留されている可能性があります。それが起こった場合、古い非アクティブな受け入れ要素を新しい非アクティブ要素に置き換える必要があります。受け入れた要素が削除された場合、ラベルの撤回を<x、y>の隣接nにラベルlに対して送信する必要があります。
Suppose a node Z has an MBB LSP <X, Y> with an active accepting element A(N1, L1). Due to a routing change, it detects a new best path for root X and selects a new upstream LSR N2. Node Z allocates a new local label L2 and creates an inactive accepting element iA(N2, L2). Node Z sends MBB Label Mapping <X, Y, L2> to N2 and waits for the new upstream LSR N2 to respond with an MBB Notification for <X, Y, L2>. During this transition phase, there are two accepting elements, the element A(N1, L1) still accepting packets from N1 over label L1 and the new inactive element iA(N2, L2).
ノードZには、アクティブな受け入れ要素A（N1、L1）を備えたMBB LSP <X、Y>があるとします。ルーティングの変更により、ルートXの新しい最適なパスを検出し、新しいアップストリームLSR N2を選択します。ノードZは、新しいローカルラベルL2を割り当て、非アクティブな受け入れ要素IA（N2、L2）を作成します。ノードZは、MBBラベルマッピング<x、y、l2>をN2に送信し、新しい上流のLSR N2が<x、y、l2>のMBB通知で応答するのを待ちます。この遷移段階では、2つの受け入れ要素があります。要素A（N1、L1）は、ラベルL1と新しい不活性要素IA（N2、L2）を介してN1からパケットを受け入れています。
While waiting for the MBB Notification from upstream LSR N2, it is possible that another transition occurs due to a routing change. Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) is created and the old inactive element iA(N2, L2) MUST be removed. A Label Withdraw MUST be sent to N2 for <X, Y, L2>. The MBB Notification for <X, Y, L2> from N2 will be ignored because the inactive element is removed.
上流のLSR N2からのMBB通知を待っている間、ルーティングの変更により別の遷移が発生する可能性があります。新しいアップストリームLSRがN3であるとします。非アクティブな要素IA（N3、L3）が作成され、古い非アクティブ要素IA（N2、L2）を除去する必要があります。ラベルの引き出しは、<x、y、l2>のためにn2に送信する必要があります。非アクティブ要素が削除されているため、N2から<x、y、l2>のMBB通知は無視されます。
It is possible that the MBB Notification from upstream LSR is never received due to link or node failure. To prevent waiting indefinitely for the MBB Notification, a timeout SHOULD be applied. As soon as the timer expires, the procedures in Section 8.4.5 are applied as if an MBB Notification was received for the inactive element. If a downstream LSR detects that the old upstream LSR went down while waiting for the MBB Notification from the new upstream LSR, the downstream LSR can immediately proceed without waiting for the timer to expire.
上流のLSRからのMBB通知が、リンクまたはノードの障害により受信されない可能性があります。MBB通知を無期限に待つことを防ぐには、タイムアウトを適用する必要があります。タイマーが期限切れになるとすぐに、セクション8.4.5の手順は、不活性要素に対してMBB通知が受信されたかのように適用されます。下流のLSRが、新しいアップストリームLSRからのMBB通知を待っている間に古いアップストリームLSRがダウンしたことを検出した場合、ダウンストリームLSRはタイマーが期限切れになるのを待たずにすぐに進むことができます。
Suppose node Z has state for an MBB LSP <X, Y> and receives an MBB Label Mapping <X, Y, L2> from N2. A new forwarding state F(N2, L2) will be added to the MP LSP if it did not already exist. If this MBB LSP has an active accepting element or if node Z is the root of the MBB LSP, an MBB notification <X, Y, L2)> is sent to node N2. If node Z has an inactive accepting element, it marks the Forwarding state as <X, Y, F'(N2, L2)>. If the router Z upstream LSR for <X, Y> happens to be N2, then Z MUST NOT send an MBB notification to N2 at once. Sending the MBB notification to N2 must be done only after Z upstream for <X, Y> stops being N2.
ノードZにMBB LSP <X、Y>の状態があり、N2からMBBラベルマッピング<X、Y、L2>を受信しているとします。まだ存在していない場合、新しい転送状態F（N2、L2）がMP LSPに追加されます。このMBB LSPにアクティブな受け入れ要素がある場合、またはノードZがMBB LSPのルートである場合、MBB通知<X、Y、L2）>はノードN2に送信されます。ノードZに非アクティブな受け入れ要素がある場合、転送状態は<x、y、f '（n2、l2）>としてマークされます。<xのルーターz上流LSRの場合、y>はたまたまN2である場合、zはMBB通知を一度にN2に送信してはなりません。MBB通知をN2に送信することは、<x、y>の上流z後にn2の停止の後にのみ実行する必要があります。
Suppose node Z receives an MBB Notification <X, Y, L> from N. If node Z has state for MBB LSP <X, Y> and an inactive accepting element iA(N, L) that matches with N and L, we activate this accepting element and install label L in the label-forwarding database. If another active accepting element was present, it will be removed from the label-forwarding database.
ノードZがNからMBB通知<X、Y、L>を受信したとします。NodeZがMBB LSP <X、Y>の状態、およびNおよびLと一致する非アクティブな受け入れ要素IA（n、L）を持っている場合、アクティブ化しますこの受け入れ要素とラベルlをラベルフォードデータベースにインストールします。別のアクティブな受け入れ要素が存在する場合、ラベルフォーリングデータベースから削除されます。
If this MBB LSP <X, Y> also has Forwarding states marked for sending MBB Notifications, like <X, Y, F'(N2, L2)>, MBB Notifications are sent to these downstream LSRs. If node Z receives an MBB Notification for an accepting element that is not inactive or does not match the label value and neighbor address, the MBB notification is ignored.
このMBB LSP <x、y>には、<x、y、f '（n2、l2）>などのMBB通知を送信するためにマークされた転送状態もある場合、MBB通知はこれらの下流LSRに送信されます。ノードZが、非アクティブではない、またはラベル値と隣接アドレスと一致しない受け入れ要素のMBB通知を受信した場合、MBB通知は無視されます。
The procedures described above apply to the downstream path of an MP2MP LSP. The upstream path of the MP2MP is set up as normal without including an MBB Status code. If the MBB procedures apply to an MP2MP downstream FEC element, the upstream path to a node N is only installed in the label-forwarding database if node N is part of the active accepting element. If node N is part of an inactive accepting element, the upstream path is installed when this inactive accepting element is activated.
上記の手順は、MP2MP LSPの下流パスに適用されます。MP2MPの上流パスは、MBBステータスコードを含めることなく通常どおりに設定されます。MBB手順がMP2MP下流FEC要素に適用される場合、ノードNがNode Nがアクティブな受け入れ要素の一部である場合、ノードNへの上流パスはラベルフォードデータベースにのみインストールされます。ノードnが非アクティブな受け入れ要素の一部である場合、この非アクティブな受け入れ要素がアクティブ化されると、上流パスがインストールされます。
The format of the mLDP FEC Typed Wildcard FEC is as follows:
MLDP FECと入力された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 | Type | Len = 2 | AFI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+
Typed Wcard: As specified in [RFC5918]
タイプ付きWCARD：[RFC5918]で指定されています
Type: The type of FEC Element Type. Either the P2MP FEC Element or the MP2MP FEC Element using the values defined for those FEC Elements when carried in the FEC TLV as defined in this document.
タイプ：FEC要素タイプのタイプ。P2MP FEC要素またはMP2MP FEC要素のいずれかが、このドキュメントで定義されているようにFEC TLVで運ばれたときにそれらのFEC要素に対して定義された値を使用して使用します。
Len: Len FEC Type Info, two octets (=0x02).
LEN：LEN FECタイプ情報、2オクテット（= 0x02）。
AFI: Address Family, two-octet quantity containing a value from IANA's "Address Family Numbers" registry.
AFI：IANAの「アドレスファミリ番号」レジストリからの値を含むファミリー、2オクテット数量をアドレスします。
The same security considerations apply as those for the base LDP specification, as described in [RFC5036].
[RFC5036]に記載されているように、同じセキュリティの考慮事項が基本LDP仕様の考慮事項と同様に適用されます。
The protocol specified in this document does not provide any authorization mechanism for controlling the set of LSRs that may join a given MP LSP. If such authorization is desirable, additional mechanisms, outside the scope of this document, are needed. Note that authorization policies cannot be implemented and/or configured solely at the root node of the LSP, because the root node does not learn the identities of all the leaf nodes.
このドキュメントで指定されたプロトコルは、特定のMP LSPに参加する可能性のあるLSRのセットを制御するための認証メカニズムを提供しません。そのような許可が望ましい場合、このドキュメントの範囲外の追加のメカニズムが必要です。ルートノードはすべての葉ノードのアイデンティティを学習しないため、承認ポリシーはLSPのルートノードでのみ実装したり構成できないことに注意してください。
Per this document, IANA has created 3 new registries.
このドキュメントに従って、IANAは3つの新しいレジストリを作成しました。
1. "LDP MP Opaque Value Element basic type"
1. 「LDP MP Opaque Value Element Basic Type」
The range is 0-255, with the following values allocated in this document:
範囲は0-255で、次の値はこのドキュメントに割り当てられています。
0: Reserved
0：予約済み
1: Generic LSP identifier
1：ジェネリックLSP識別子
255: Extended Type field is present in the following two bytes
255：拡張型フィールドは、次の2つのバイトに存在します
The allocation policy for this space is 'Standards Action with Early Allocation'.
このスペースの割り当てポリシーは、「早期配分を伴う標準アクション」です。
2. "LDP MP Opaque Value Element extended type"
2. 「LDP MP Opaque Value Element Extended Type」
The range is 0-65535, with the following allocation policies:
範囲は0-65535で、次の割り当てポリシーがあります。
0-32767: Standards Action with Early Allocation
0-32767：早期配分を伴う標準訴訟
32768-65535: First Come, First Served
32768-65535：最初に来て、最初に提供されます
3. "LDP MP Status Value Element type"
3. 「LDP MPステータス値要素タイプ」
The range is 0-255, with the following values allocated in this document:
範囲は0-255で、次の値はこのドキュメントに割り当てられています。
0: Reserved
0：予約済み
1: MBB Status
1：MBBステータス
The allocation policy for this space is 'Standards Action with Early Allocation'.
このスペースの割り当てポリシーは、「早期配分を伴う標準アクション」です。
The code point values listed below have been allocated by IANA through early allocation.
以下にリストされているコードポイント値は、早期割り当てを通じてIANAによって割り当てられています。
IANA allocated three new code points from the LDP registry "Forwarding Equivalence Class (FEC) Type Name Space". The values are:
IANAは、LDPレジストリ「等価クラス（FEC）タイプ名スペース」から3つの新しいコードポイントを割り当てました。値は次のとおりです。
P2MP FEC type - requested value 0x06
P2MP FECタイプ - 要求された値0x06
MP2MP-up FEC type - requested value 0x07
MP2MP -UP FECタイプ - 要求された値0x07
MP2MP-down FEC type - requested value 0x08
MP2MPダウンFECタイプ - 要求された値0x08
IANA assigned three new code points for new Capability Parameter TLVs from the LDP registry "TLV Type Name Space", corresponding to the advertisement of the P2MP, MP2MP, and MBB capabilities. The values are:
IANAは、P2MP、MP2MP、およびMBB機能の広告に対応するLDPレジストリ「TLVタイプ名スペース」から新しい機能パラメーターTLVの3つの新しいコードポイントを割り当てました。値は次のとおりです。
P2MP Capability Parameter - 0x0508
P2MP機能パラメーター-0x0508
MP2MP Capability Parameter - 0x0509
MP2MP機能パラメーター-0x0509
MBB Capability Parameter - 0x050A
MBB機能パラメーター-0x050A
IANA assigned an LDP Status Code to indicate that an LDP MP Status TLV is following in the Notification message. The value assigned in the LDP registry "LDP Status Code Name Space" is:
IANAはLDPステータスコードを割り当てて、LDP MPステータスTLVが通知メッセージでフォローしていることを示します。LDPレジストリ「LDPステータスコード名スペース」に割り当てられている値は次のとおりです。
LDP MP status - requested value 0x00000040
LDP MPステータス - 要求された値0x00000040
IANA assigned a new code point for an LDP MP Status TLV. The value assigned in the LDP registry "LDP TLV Type Name Space" is:
IANAは、LDP MPステータスTLVに新しいコードポイントを割り当てました。LDPレジストリ「LDP TLVタイプ名スペース」に割り当てられている値は次のとおりです。
LDP MP Status TLV Type - requested value 0x096F
LDP MPステータスTLVタイプ - 要求された値0x096f
The authors would like to thank the following individuals for their review and contribution: Nischal Sheth, Yakov Rekhter, Rahul Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel, Thomas Morin and Ben Niven-Jenkins.
著者は、Nischal Sheth、Yakov Rekhter、Rahul Aggarwal、Arjen Boers、Eric Rosen、Nidhi Bhaskar、Toerless Eckert、George Swallow、Jin Lizhong、Vanson Lim、Adrian Farrel、Thomas Morinmas Morininそしてベン・ニヴェン・ジェンキンス。
Below is a list of the contributing authors in alphabetical order:
以下は、アルファベット順の貢献著者のリストです。
Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 US EMail: Shane.Amante@Level3.com
Shane Amanteレベル3 Communications、LLC 1025 Eldorado Blvd Broomfield、Co 80021 US Email：shane.amante@level3.com
Luyuan Fang Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 US EMail: lufang@cisco.com
Luyuan Fang Cisco Systems 300 Beaver Brook Road Boxborough、MA 01719 US Email：lufang@cisco.com
Hitoshi Fukuda NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019, Japan EMail: hitoshi.fukuda@ntt.com
Fukuda NTT Communications Corporation 1-1-6、Uchisaiwai-Cho、Chiyoda-Ku Tokyo 100-8019、日本メール：hitoshi.fukuda@ntt.com
Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan EMail: y.kamite@ntt.com
Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku、Shinjuku-Ku、東京163-1421、日本メール：Y.Kamite@ntt.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: kireeti@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 US Email：kireeti@juniper.net
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin Lannion, Cedex 22307 France EMail: jeanlouis.leroux@francetelecom.com
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin Lannion、Cedex 22307 France Email：jeanlouis.leroux@francetelecom.com
Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: ina@juniper.net
ina misei juniperネットワーク1194 N. Mathilda Ave. Sunnyvale、CA 94089 US Email：ina@juniper.net
Bob Thomas Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA, 01719 EMail: bobthomas@alum.mit.edu
Bob Thomas Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA、01719メール：bobthomas@alum.mit.edu
Lei Wang Telenor Snaroyveien 30 Fornebu 1331 Norway EMail: lei.wang@telenor.com
Lei Wang Telenor Snaroyveien 30 Fornebu 1331 Norway Email：lei.wang@telenor.com
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a 1831 Diegem Belgium EMail: ice@cisco.com
IJSBRAND Wijnands Cisco Systems、Inc。de Kleetlaan 6a 1831 Diegem Belgiumメール：ice@cisco.com
[ITU.V42.1994] International Telecommunications Union, "Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion", ITU-T Recommendation V.42, 1994. http://www.itu.int/rec/T-REC-V.42-200203-I
[ITU.V42.1994]国際電気通信連合、「非同期から同期変換を使用したDCEのエラー修正手順」、ITU-T推奨V.42、1994。http：//www.itu.int/rec/t/t-rec-v.42-200203-i
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLS Upstream Labelの割り当てとコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561] Thomas、B.、Raza、K.、Aggarwal、S.、Aggarwal、R。、およびJl。Le Roux、「LDP機能」、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、「ラベル分布プロトコル（LDP） 'タイプされたワイルドカード「フォワード等価クラス（FEC）」、RFC 5918、2010年8月。
[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, September 2011.
[RFC6389] Aggarwal、R。およびJL。Le Roux、「LDPのMPLS上流のラベル割り当て」、RFC 6389、2011年9月。
[ISO3309] International Organization for Standardization, "ISO Information Processing Systems - Data Communication - High-Level Data Link Control Procedure - Frame Structure", ISO 3309, 3rd Edition, October 1984.
[ISO3309]国際標準化機関、「ISO情報処理システム - データ通信 - 高レベルのデータリンク制御手順 - フレーム構造」、ISO 3309、3rd Edition、1984年10月。
[L3VPN-MCAST] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", Work in Progress, January 2010.
[L3VPN-Mcast] Rosen、E.、ed。、およびR. Aggarwal、ed。、「MPLS/BGP IP VPNSのマルチキャスト」、2010年1月の進行中。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[RFC3813] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチングルーター（LSR）管理情報ベース（MIB）」、RFC 3813、2004年6月。
[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月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332] Eckert、T.、Rosen、E.、Ed。、Aggarwal、R.、Y.Rekhter、「MPLS Multicast Capsulations」、RFC 5332、2008年8月。
[RFC6348] Le Roux, J., Ed., and T. Morin, Ed., "Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol", RFC 6348, September 2011.
[RFC6348] Le Roux、J.、ed。、およびT. Morin、ed。、「ラベル分布プロトコルへのポイントツーマルチポイント拡張の要件」、RFC 6348、2011年9月。
Authors' Addresses
著者のアドレス
IJsbrand Wijnands (editor) Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium EMail: ice@cisco.com
IJSBRAND WIJNANDS（編集者）Cisco Systems、Inc。de Kleetlaan 6a Diegem 1831 Belgiumメール：ice@cisco.com
Ina Minei (editor) Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: ina@juniper.net
ina misei（編集者）ジュニパーネットワーク1194 N. Mathilda Ave. Sunnyvale、CA 94089 US Email：ina@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: kireeti@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 US Email：kireeti@juniper.net
Bob Thomas 300 Beaver Brook Road Boxborough 01719 US EMail: bobthomas@alum.mit.edu
ボブ・トーマス300ビーバーブルックロードボックスボロー01719米国メール：bobthomas@alum.mit.edu