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.
この文書では、ポイント・ツー・マルチポイント（P2MP）とマルチポイント・ツー・マルチポイントのセットアップのためのラベル配布プロトコル（LDP）の拡張機能を説明し（MP2MP）ラベルは、MPLSネットワークにスイッチパス（LSP）。これらの拡張機能は、マルチポイントとして、自民党と呼ばれています。マルチLDPは、と相互作用する、または任意の他のマルチキャストツリー構築プロトコルに依存せずにP2MP又はMP2MP LSPを構築します。この溶液のプロトコル要素および手順は、受信機が開始した方法でそのようなLSPを構築するために記載されています。 3個の仮想プライベートネットワーク（L3VPNs）BGP / MPLSレイヤでのIPマルチキャストまたはマルチキャストのサポートたとえば、マルチポイントのLSPのための様々なアプリケーションが存在する場合があります。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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 several MP LSPs rooted at a given ingress node, each with its own identifier.
LDPプロトコルは、[RFC5036]に記載されています。これは、ネットワーク内のポイントツーポイント（P2P）とマルチポイントツーポイント（MP2P）LSPを設定するためのメカニズムを定義します。この文書では、ポイント・ツー・マルチポイント（P2MP）とマルチポイント・ツー・マルチポイント（MP2MP）LSPを設定するためのLDPに拡張機能について説明します。これらを総称してマルチポイントのLSP（MPのLSP）と呼ばれます。 P2MP LSPは、単一のルート（または入力）ノードからのトラフィックは、リーフ（または出力）ノードの数に配信されることを可能にします。 MP2MP LSPは、複数の入力ノードからのトラフィックは、複数の出口ノードに配信されることを可能にします。パケットの唯一の単一のコピーはMP LSPによって横断LDPネイバーに送信されます。これは、ネットワークにおけるマルチキャストプロトコルを使用せずに達成されます。所与の入口ノードをルートとするいくつかの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と一つのユニークな出口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内の任意のノードによって送信されたトラフィックが他のすべてに配信されるようにノードの集合を接続識別ルートノードとLSP。
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
MP LSP：マルチポイントLSP、P2MPまたはMP2MP 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".
入口LSR：特定のLSPのための入口LSRは、LSPに沿ってデータパケットを送信することができるLSRです。 MP2MP LSPは、P2MPのLSPは、1つだけ持っていて、そのノードは、多くの場合、「ルートノード」と呼ばれ、複数の入力のLSRを持つことができます。
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.
トランジットLSR：直接LSRおよび1つ以上の直接接続された下流のLSR上流接続を介してMP LSPのルートへの到達可能性を有しているLSR。
Bud LSR: An LSR that is an egress but also has one or more directly connected downstream LSRs.
芽LSR：出口であるが、一つ以上の直接接続された下流の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]で使用CRC32アルゴリズムに従って計算ネットワークバイト順に及びITU-T勧告V.42のセクション8.1.1.6.2に非圧縮データの巡回冗長検査値を含みます[ 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をサポートするために必要なアウトセグメントの関係に一対多でセグメントを処理する十分可能であり、更なる変更が必要とされません。
[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のための管理オブジェクトを定義します。 [RFC5036]で定義されたMIBモジュールは、プロトコルのための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.
[RFC5561]で定義されているP2MP LSPの設定のサポートは、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.
自民党と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のルートと不透明値のアドレスから成ります。不透明な値は、一つ以上の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の「アドレスファミリー番号」レジストリから値を含むオクテットの量。
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元素を含むメッセージを処理中止し、エラーをシグナリングそのLDPピアに「不明FEC」通知メッセージを送信するべきです。
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不透明値の要素の基本的なタイプが符号化されます。
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不透明な価値要素のタイプ。 IANAは、基本タイプ（セクション11を参照）のレジストリを維持します。
Length: The length of the Value field, in octets.
長さ：Valueフィールドの長さは、オクテットインチ
Value: String of Length octets, to be interpreted as specified by the Type field.
値：Typeフィールドで指定された長さオクテットの文字列は、解釈されます。
The LDP MP opaque value element extended type is encoded as follows:
次のように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 = 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不透明な価値要素の拡張型。 IANA（セクション11を参照）、拡張タイプのレジストリを維持します。
Length: The length of the Value field, in octets.
長さ：Valueフィールドの長さは、オクテットインチ
Value: String of Length octets, to be interpreted as specified by the Type field.
値：Typeフィールドで指定された長さオクテットの文字列は、解釈されます。
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要素
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>：ラベルLをラベルLを有する単一のP2MP FEC要素<X、Y>とラベルTLVとFEC TLVとLabel Mappingメッセージは、プラットフォームごとのラベルから割り当てられなければなりませんスペース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>：ラベルは、ラベルLと単一P2MP FEC要素<X、Y>とラベル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
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.表記L ' - > {<I1、L1> <I2、L2> ... <において、Lnは>} LSR Xには、ラベルLとのパケットを受信することを意味'、XはパケットのN個のコピーを行います。パケットのコピー私の場合、Xは、Liと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 Label Mappingメッセージ（これの下流のリーフノードを有する、すなわち、1）を受信する（ルートノード以外の）任意のノードです。
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.
ここで説明するすべてのラベルは、下流に割り当てられた[RFC5332]セクション6の手順を使用して割り当てられているものを除いています。
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 more than one such LDP peer, only one of them is picked. U is Z's "upstream LSR" for <X, Y>.
MP LSPの葉またはトランジットLSRのいずれかであり、各ノードは、上流LSRを選択するために以下の手順を使用する必要があります。 MP LSP参加したいノードZ <Xは、Y>は一つ以上のそのようなLDPピアが存在する場合ZからルートノードXへの最良の経路上にZの次のホップであるLDPピアUを決定しますそれらを選択されます。 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.
いくつかの候補上流のLSRがある場合、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アドレスの下位から番号付けされています。
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.次のハッシュが実行される：Nは、上流のLSRの数であり、H =（CRC32（不透明値））モジュロNを、。 「不透明な値が」正しい「不透明な長さ」の後にFEC要素で識別されるフィールドです。 「不透明な長さ」は、この計算に使用される不透明値の大きさを示しています。
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ラベルL. UはいくつかのLDP対応インターフェイス上にDに接続された、またはRSVP-TEトンネルインターフェイスされていることをさらに仮定する指定、下流LSR DからMP Label Mappingメッセージを受信すると仮定する。 Uは、Dにその上部ラベルLであるデータパケットを送信する必要がある場合、Uは、それらのインタフェースのいずれかにパケットを送信して自由です。それは特定のそのようなパケットのための特定のインターフェイスおよびネクストホップを選択するために使用するアルゴリズムは、ローカルの問題です。完全を期すために、以下の手順を使用することができます。次ホップインターフェイスはまた、LDPセッションを介してLSR Dによってアドバタイズされている場合LSR Uは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は、<X、Y>セクション2.4.1.1に従って、ラベルLを割り当てるために、その上流のLSR Uを決定し、UにP2MPラベルマッピング<X、Y、L>を送信します。 。
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.
<X、Y>には、それが既に状態を有しているか否かLSR T.のZチェックからトランジットノードZは、P2MPラベルマッピング<X、Y、L>を受信すると仮定する。そうでない場合、Zは、セクション2.4.1.1に従って<X、Y>のためにその上流LSR Uを決定します。ラベル転送テーブルを更新するには、このラベルマッピングを使用している限りLSR UはLSR Tと異なる場合LSR TはLSR Uに等しくなるように行ってはいけません、Zは、ラベルLを割り当てる「及びLを交換する状態をインストール」を有するであろうLSR U.インタフェースIへのインタフェース上L I LSR Tに関連付けられ、P2MPラベルマッピングを送信する<X、Y、L 'は、>セクション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はすでに<Y、X>の状態を持っている場合には、Zは、P2MP LSP <X、Y>のためのラベルマッピングメッセージを送信しません。 LSR T上流<Y、X>のLSRと<I、L>に等しくない場合、すでにとしてフォワーディング状態が存在しない、転送状態が更新されます。 ' - > {<I1、L1> <I2、L2> ... <においては、Lnは>}、新しい転送状態がLになり' - 古い転送状態がLであったと仮定> {<I1、L1> <I2、 L2> ... <において、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).
それは既に<X、Y>のための状態を転送しているか否かLSR T.のZチェックからルートノードZは、P2MPラベルマッピング<X、Y、L>を受信すると仮定する。そうでない場合、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は、既に<Y、X>のための状態を転送した場合、ZはI、セクション2.4.1.2に記載されている手順を介してLSR Tに関連付けられて決定インタフェースである次のホップへ「プッシュラベルLは、Iインターフェースを介して送信」を追加します。
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ラベルは、P2MP LSPに参加するノードに対してメッセージを撤回するための手順を示しています。 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> Lは、それが以前に<X、Y>にはUに通知していたラベルである<X、Y>のためにその上流LSR 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は、ラベルは、ノードWからのメッセージ<X、Y、L>撤退受信した場合、その転送状態からラベルLを削除し、WにラベルLとラベル解放メッセージを送信します。
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>.
<Y、X>の残りのない状態でP2MP LSP <X、Y>結果を得るためにZの転送状態からLを削除する場合、Zは、ラベルがラベル撤回送信することによって、その上流Tに<Y、X>のために撤退伝播します< L1は、Zは、以前<X、Y>のためのTにアドバタイズしたラベルであるX、Y、L1>。
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.
セクション2.4.1.1の通りUからUへの上流のLSR変更」、所与のノードZのためのP2MP LSP <X、Y>に参加していると仮定する。次のようにZは、その転送状態を更新する必要があります。それは<X、Y>のために、新しいラベル、L」を割り当てます。 Lの転送状態が「1つの例外を除いて、Lの転送状態からコピーされる：Uがあれば」Lの転送状態で存在し、それは「Lのフォワーディング状態に設置してはいけません。次いでLの転送状態が削除され、L」の転送状態をインストールされています。また、Zラベルマッピングを送信しなければならない<X、Y、L「> U」へとラベルを送るにインストールされていないUから下流マッピングがあった場合、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 that is not possible, the RECOMMENDED default behavior is to remove L before adding L'.
上流のLSRを変更しながら、以下を考慮に入れなければなりません。 Lが削除される前に、L」が追加されている場合は、パケットの重複および/または一時データプレーンフォワーディングループの作成の潜在的な危険性があります。 Lが追加された「L前に削除された場合、パケットロスが発生することがあります。理想的にはLから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.
それは同等に入力または出力LSR作用単一のルートノード、ゼロまたはそれ以上のトランジットノード、および1つまたは複数のリーフのLSRからなることをMP2MP LSPははるかにP2MP LSPのようなものです。リーフノードは、はるかに根および他のリーフノードに向けてトラフィックを送信するために使用されるルートからP2MP LSP、及び上流のLSP、似ている下流LSPの両方を確立することによりMP2MP LSPの設定に関与します。トランジットノードは、ルートに向かって上流および下流のLSP設定を伝播し、必要なMPLS転送状態をインストールすることで、セットアップをサポートしています。受信機へMP2MP LSPのルートノードからのパケットの送信は、P2MP LSPのためのものと同一です。他のリーフノードに到達するために必要に応じて下流ノードからのトラフィックは下方下流LSPに沿ってルートノードと分岐に向かって上流のLSPに従います。下流ノードから受信されたパケットは、同じノードOUTにバック転送してはなりません。 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に必要な追加のメカニズムもありません。 [RFC5331]の手順が提供されない場合MP2MP LSPを介して転送されるパケットは、（セクション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.
[RFC5561]で定義されているMP2MP LSPの設定のサポートは、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.
自民党と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).
下流MP2MP上流FEC要素に対するハンドリング構造、符号化、及びエラーがP2MP FEC要素は、セクション2.2に記載のものと同じです。違いは、2つの新しいFECタイプが使用されていることである。MP2MP下流タイプ（0×08）と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. LSP <X、Y、D>上流MP2MP（又は単に上流<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>：FEC元素Yは、下流MP2MP LSPに使用されるルート・ノード・アドレスXと不透明値を有します。
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.
FEC要素<X、Y>上流4. MP2MP：FEC元素Yは、上流MP2MP LSPに使用されるルート・ノード・アドレスXと不透明値を有します。
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>：ラベルLをラベルLを有する単一MP2MP下流FEC要素<X、Y>ラベルTLVとFEC TLVとLabel Mappingメッセージあたりから割り当てられなければなりませんラベルマッピングメッセージを送るLSRの-platformラベルスペース（セクション3.14、[RFC3031]を参照）。インターフェイスのラベルスペースの使用は、このドキュメントの範囲外です。
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要素<X、Y>ラベルLUとラベルTLV上流単一MP2MPとFEC TLVとLabel Mappingメッセージ。ラベル呂は、ラベルマッピングメッセージを送る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>：ラベルLとラベルが単一MP2MPとFEC TLVを含むメッセージを撤回下流FEC要素<X、Y>とラベル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の>：ラベルはFEC要素<X、Y>ラベルLUとラベルTLV上流単一MP2MPとFEC TLVのメッセージを撤回します。
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>：ラベルLを有する単一MP2MP下流FEC要素<X、Y>とラベルTLVとFEC 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の>：FEC要素<X、Y>ラベルLUとラベルTLV上流単一MP2MPとFEC 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.
ここで説明するすべてのラベルは、下流に割り当てられた[RFC5332]セクション6の手順を使用して割り当てられているものを除いています。
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下流MP2MPのLSRとしてDを扱います。
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-Uラベルマッピングを受け取ることに基づいて（下流隣接に対して）上流MP2MPパスをインストール。 LSRは、それがすでに上流ネイバーからMP2MP-Uのラベルマッピングを受け取った場合、それはMP2MP LSPのルートである場合、またはMP2MP-Uのラベルマッピングを待つ必要はありません。我々は、この方法orderedモードを呼び出します。このモードの典型的な結果は、MP2MPの下流経路をルートに向かってホップバイホップに構築されていることです。根に到達すると、ルートノードは、下流の隣接（S）に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 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.
MP2MP LSPの上流の経路を設定するために、順序付けモードを使用すべきです。ルートへのパスが完了すると順序付けモードによる、MP2MP LSPの上流の経路がリーフノードにインストールされています。利点は、葉がアップストリームパスがインストールされた直後に送信を開始したときに、パケットが不完全な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は、<X、Y>セクション3.3.1.1に従って、ラベルLを割り当て、MP2MP-Dラベルマッピングを送信する<X、Y、Lのためにその上流LSR Uを決定します> 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が期待MP2MP-Uラベルマッピング<X、Y、Luの>それは既にの状態を転送したか否かU.のZチェックをノードに送信MP2MP-Dラベルマッピングに応じて、ノードUの上流<X、Y> 。そうでない場合、ZはZがMP2MP LSP上で転送したいトラフィックにラベル呂をプッシュする状態を転送し作成します。それはどのようにこの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.
仮定するノードZはMP2MP-Dラベルマッピングを受け取る<X、Y、L>それが下流のための状態を転送しているか否かLSR D.のZチェックから<X、Y>。そうでない場合、Zは、セクション3.3.1.1に従って<X、Y>のためにその上流LSR Uを決定します。限りLSR DはLSR UはLSR Dと異なる場合LSR Uに等しくなるように行ってはいけませんラベル転送テーブルを更新するには、このラベルマッピングを用いて、Zは、ラベルL」を割り当て、ラベルLを交換する下流転送状態をインストールします「インタフェースを介してラベルLとIはLSR Dに関連付けられ、MP2MP-Dラベルマッピングを送信する<X、Y、L」> U.インタフェースIのセクション2.4.1.2の手順を介して決定されます。
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は<Y、X>の上流のLSRに等しくはないことを確認し、その転送状態を更新され、この場合に行う必要があります。 ' - > {<I1、L1> <I2、L2> ... <においては、Lnは>}、新しい転送状態がLになり' - 古い転送状態がLであったと仮定> {<I1、L1> <I2、 L2> ... <において、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>にラベルを割り当てた場合。そうでない場合、それはLSR U（セクション3.3.1.3を参照）からMP2MP-Uラベルマッピング<X、Y、Luの>を受信するまで、トランジットノードZ待ちます。 MP2MP-UラベルマッピングLSR U、それは既に上流の状態を転送したか否かを、ノードZチェック<X、Yを、D>から受信されます。それがない場合は、それ以上のアクションが発生する必要はありません。そうでない場合は、ラベル呂を割り当て「と呂のための新しいラベルスワップ作成」インタフェースのIu以上のラベル陸とを。インタフェースIuが2.4.1.2項の手順を経て決定されます。また、それはまた、ラベルのスワップ（S）からの追加します
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にスワップを省略は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は、D.ノードするセクション3.3.1.2に従って下流MP2MP LSRを決定し、MP2MP-Uラベルマッピングを送信する<X、Y、Luの '>
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はMP2MP-Dラベルマッピングを受け取る<X、Y、L>が既に下流状態を転送したか否かをノードDのZチェックから<X、Y>。そうでない場合、ZはZがMP2MP LSPを下に転送したいトラフィックにラベルLをプッシュする下流のフォワーディングステートを作成します。それはどのようにこのMP2MP LSPに転送するトラフィックを決定することは、この文書の範囲外です。 Zはすでに下流<X、Y>の状態を転送した場合には、Zは、私はそれにインターフェイスを介してLのラベルプッシュを追加します。インターフェイス私は、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は、私はノードDのインターフェイス上のスワップを除いて、標識Luの割り当て「およびLuから交換するアップストリーム転送状態を作成」下流フォワーディング状態からラベルスワップを有する（複数可）<X、Y>これは、アップストリームトラフィックを許可しますトラフィックを受信したノードを除いて、他のノード（複数可）にMP2MPをダウンします。ノードZは、Zは、ツリーのルートであるため、ZはMP2MPを送信しないD.ノードするセクションのセクション3.3.1.2に従って下流MP2MP LSRを決定し、MP2MP-Uラベルマッピングを送信する<X、Y、Luの '> -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はMP2MP-Dラベルマッピングを受信すると仮定<X、Y、L>既に下流<X、Y>のための状態を転送したか否かをノードDのZチェックから。そうでない場合、Zは、下流の転送状態を作成し、I.インタフェースIは、セクション2.4.1.2の手順を介して決定されたインターフェースを介して発信ラベルLをインストールします。 Zはすでに下流<X、Y>の状態を転送した場合には、Zは、私は既存の状態にインターフェイスを介してラベル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 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チェックそれは上流<X、Y、D>のための状態を転送している場合。そうでない場合、Zは、標識Luの割り当て「を及びLuを交換する状態を転送作成」下流フォワーディング状態からラベルスワップ（S）と<X、Y>、ノードDのスワップ以外これは、アップストリームトラフィックがダウンすることを可能にしますそれを受信したノード以外のノード（複数可）にMP2MP。ルートノード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ラベルがMP2MP LSPに参加するノードに対してメッセージを撤回するための手順を示しています。 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であるする必要がないことこと（この文書の範囲外の手段によって）検出された場合それは、Lは、それが以前に<X、Y>にはUに通知していたラベルである<X、Y>のためにその上流LSR Uに<X、Y、L>を撤回MP2MP-Dラベルを送ります。リーフノードZはまた、迷惑ラベル解放<X、Y、Luの> Uには、アップストリームパスがもはや使用され、そのラベルは、LUが除去することができないことを示すために送信されます。
Leaf node Z expects the upstream router U to respond by sending a downstream label release for L.
リーフノード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ラベルがメッセージを撤回<X、Y、L>ノードDからは、それがためにその転送状態下流<X、Y>からそのすべての上流の状態からラベルLを削除<X、Y> 。ノードDは、下流転送状態の一部ではなくなったので、ノードZはDにラベルLとMP2MP-Dラベル解放メッセージを送信し、Zは、上流<X、Y、D>転送状態をクリーンアップ。 Dに<X、Y、呂>はノードDはすでに呂を削除し、Zに呂のラベルのリリースを送信したため撤回MP2MP-Uラベルを送信する必要はありません
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.
<X、Y>のための残りのない状態で下流<X、Y>は結果を得るために、Zの転送状態からLを削除する場合、Zは、<X、Y、L>その上流ノードへUための<X MP2MP-Dラベルが撤退伝播します、Yは>とも上流のパスがもはや使用され、そのラベル呂を削除することができていないことを示すようにUに迷惑MP2MP-Uラベルリリース<X、Y、呂>を送信します。
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.2.3を介してセクション3.3.1に記載した手順を用いて、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は決して上流LDPネイバーが同じFECのラベルフォワーディングテーブル（LFT）に下流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.
自民党MPできるルータは、そのリモートピアにMP LSPのための追加のステータスを示すために、LDP MPステータスTLVを使用するかもしれません。これは、LDP MP対応ルータの上流または下流のいずれかであるピアにシグナリングを含みます。自民党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).
自民党MPのステータスタイプ：LDP MPステータス（0x096F）。
Length: Length of the LDP MP Status Value in octets.
長さ：オクテットで自民党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.
自民党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フィールドの長さは、オクテットインチ
Value: String of Length octets, to be interpreted as specified by the Type field.
値：Typeフィールドで指定された長さオクテットの文字列は、解釈されます。
The LDP MP Status TLV may appear either in a Label Mapping message or an LDP Notification message.
自民党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を伴うされなければなりません。自民党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]で定義されたLabel Mappingメッセージの例は、任意の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上の帯域幅の消費とレプリケーションのオーバーヘッドを最適化することができます。 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は、そのLAN上に、一意に自身を識別するために使用することができるコンテキストラベルを有する上の各LSRにその手順をもたらします。各LSRは、[RFC6389]の手順に従って、上流割り当てられたラベルとして、そのコンテキストラベルをアドバタイズ。 LANは、いくつかのP2MP又はMP2MP LSP上のダウンストリームリンクされている任意のLSRは、LSPを特定上流割り当てられたラベルを割り当てます。 LSRは、これらのLSPのいずれかに下りパケットを転送するとき、パケットのトップラベルは、LSRのコンテキストラベルでなければならず、パケットの第二のラベルがLSPを識別するラベルです。私たちは、「上流のLSRラベル」と第二のラベル「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ラベルが含まれています。 （LSPのラベルに対応する）MP2MP下流経路は、上流LSRのラベルに対応するコンテキスト固有の転送テーブルにインストールされます。上流のルータによって送信されたパケットは、二つのラベルルックアップに基づいて、この転送状態を使用して下流に転送することができます。
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のために、正確に一つのLSRが上流のLSRであると考えられます。 LAN上のLSRは、LSPのためにその下流インターフェースの一つからパケットを受信し、それをLAN上にパケットを転送する必要がある場合、そのパケットのトップラベルが上流のLSRのコンテキスト・ラベルであることを保証し、その場合、その第二の標識は上流の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）ネットワーク内の帯域幅の節約を達成し、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のいずれかにパケットを受信します。 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 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を予め構築する利点は、ユニキャストルーティングプロトコルを通知することができるように、ルートノードの障害からの収束が早く起こることです。ルートノードがアクティブルートであるリーフノードに広告を掲載するための追加のプロトコルのための必要はありません。ルートの選択は、他の葉と調整する必要はありませんローカルの葉のポリシーです。前の建物の複数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は、新たなアップストリームLSRにLSP「再コンバージェンス」までパケット損失が生じる一時的に破壊されてもよいです。 MBBこれが起こるの目標は、できるだけ短いパケット損失の期間を維持することです。また、ルート変更のLSRが、LSPから最適パスがルートの前の次のホップにパケットを転送し続けるシナリオが存在します。リンクが起動したか、ルーティングメトリックが変更されたときにそれが発生することがあります。古いLSPは、パケット損失の期間を制限するために除去される前に、そのような場合には、新しいLSPを確立すべきです。手順はLSRが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.
いくつかのイベントは、FEC-Aのための新しい上流LSR-Uを選択するために、下流LSR-Dの原因と仮定する。新しいLSR-Uは既にFEC-Aのパケットを転送することができます。すなわち、LSR-D以外の下流のLSRに、です。 LSR-Uは、LSR-DからFEC-Aのラベルを受信した後、それはFEC-AのLSP自体に根元から確立されていることを知っている場合には、LSR-Dに通知します。 LSR-Dは、このMBB通知を受信すると、LSR-UへLSPルートのための次のホップを変更します。
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 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.
仮定は、LSR-Uは、FEC-LSPのためにその上流のルータからMBB通知を受信したと転送状態をインストールしている場合、LSRは、LSPでパケットを転送することが可能であるということです。その時点でLSR-Uは、LSPへの切り替えを開始すべきLSR-D FEC-Aによって、その識別されたツリーの一部となっているMBB通知によってLSR-Dを通知すべきです。
At LSR-U, the LSP for FEC-A may be in 1 of 3 states.
LSR-Uでは、FEC-AのLSPは、1〜3の状態であってもよいです。
2. State for FEC-A exists and LSR-U is waiting for MBB notification that the LSP from the root to it exists.
FEC-A 2.状態が存在し、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.
FEC-A 3.状態が存在し、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のラベルマッピングメッセージを受信した後LSPのためにその状態は、上記の状態＃3になるまで、LSR-Uは、LSR-DにMBB通知で応答してはいけません。 LSR-UにおけるLSPの状態は状態＃1又は＃2である場合にLSPのためにその上流のLSRからMBBの通知を待っている間に、LSR-Uは、LSR-Dからラベルマッピングメッセージを受信したことを忘れてはなりません。 LSR-Uは、LSR-UからMBB通知を受信すると、状態＃3をLSPに遷移し、LSR-DにMBB通知を送信します。
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がその上流のLSRにMP LSPのラベルマッピングメッセージを送信するとき、それはMBB手順はLSPに適用されることを示すためにMBB状態コードを運ぶLDP MPステータスTLVを含むかもしれません。この新しいMBBステータスコードも下流LSRにLSP状態＃3に信号を送るために上流のLSRによって使用されるLDP通知メッセージに表示されるかもしれません。すなわち、LSP用の上流のLSR状態が存在すること、であり、それはその上流の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:
セクション5.1で説明したようにMBBステータス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
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を処理することが可能であることを宣伝してもよい（MAY）。自民党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)
自民党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は、それが可能なMBBであることをアドバタイズしていない下流LSR-Dおよびその上流LSR-UからMBBパラメータとLabel Mappingメッセージを受信した場合、LSRはLSR-U（セクション8.4を参照）に直ちにMBB通知を送信しなければなりません。この問題が発生した場合は、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>：P2MP又はMP2MPルートノードアドレスXと不透明値Yと前ブレーク（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.特定MBB LSPのための隣人NにこのLSR割り当てられたラベル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, the corresponding label is not stored in the label forwarding database.
3. IA（N、L）：上流の隣人NとローカルラベルL.特定MBB LSPのための隣人NにこのLSR割り当てられたラベルLから成る不活性な受け入れ要素。非アクティブな要素のために、対応するラベルは、ラベルフォワーディングデータベースに格納されていません。
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）：特定のFECのために近隣NにラベルLをラベル・パケットを送信している下流隣接NとラベルL.このLSRから構成フォワーディング状態。
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.と隣人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>とLDP通知メッセージ、ラベルL、及びMBBステータスコード2。
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>：FEC要素<X、Y>、ラベルL下流P2MPラベルマッピングまたはMP2MPラベルマッピング、及び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つの受け入れ要素を有することができ、それらの一方のみがアクティブでなければなりません。能動素子は、ラベルの値がラベル転送データベースにインストールされた要素です。新しい上流のLSRが選択され、代替ラベル転送、データベース内のアクティブ素子が保留された後、非アクティブ受容性元素が作成されます。新しいアップストリームLSRに切り替えながら不活性な要素は一時的にのみ存在します。スイッチが完了すると、唯一のアクティブな要素が残っています。ネットワーク・コンバージェンスの間に、他の非アクティブな受容性元素が保留されている間、非アクティブ受容性元素が生成することも可能です。その場合は、古い非アクティブ受容性元素は、新しい非アクティブな要素に置き換える必要があります。受容性元素が、削除された場合、ラベルは撤回<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はN2にMBBラベルマッピング<X、Y、L2>を送信し、新たな上流のLSR N2が用MBB通知<X、Y、L2>で応答するのを待ちます。この移行段階中、2つの受け入れる要素、依然としてラベルL1及び新しい非アクティブ素子IA（N2、L2）上N1からのパケットを受け入れる素子A（N1、L1）があります。
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>のための状態を有し、MBBラベルマッピング<X、Y、L2> N2からを受信します。それがまだ存在していなかった場合、新たな転送状態F（N2、L2）がMP LSPに追加されます。このMBB LSPがアクティブ受け入れ要素を有する場合、またはノードZはMBB LSP、MBB通知<X、Y、L2）>のルートである場合はノードN2に送られます。ノードZが非アクティブ受け入れ要素を有する場合、それはのように転送状態を示す<X、Y、F '（N2、L2）>。 <Y、X>のためのLSR上流のルータZがN2であることを起こる場合は、Zは、一度にN2にMBB通知を送ってはいけません。 N2へMBB通知がアップストリームだけZ後に行わなければならない送信<X、Y>は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は、<X、Y、L> NとLと一致するノードZはMBB LSP <X、Y>および不活性受容性元素IA（N、L）の状態を有する場合N.から、我々はアクティブMBB通知を受信しますラベル転送データベースでこの要素を受け入れ、インストールしたラベル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は、活性受け入れ要素の一部である場合、ノードNへのアップストリームパスのみラベルフォワーディングデータベースにインストールされています。ノードNが非アクティブ受け入れ要素の一部である場合、この不活性な受け入れ要素が活性化されると、上流の経路がインストールされています。
The format of the mLDP FEC Typed Wildcard FEC is as follows:
次のようにMLDP FEC型付きワイルドカード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要素または本文書で定義されているFEC TLVで搬送されるものFEC要素用に定義された値を使用してMP2MP FEC要素のいずれか。
Len: Len FEC Type Info, two octets (=0x02).
レン：レンFECタイプの情報、2つのオクテット（= 0×02）。
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つの新しいレジストリを作成しました。
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'.
このスペースの割り当てポリシーは、「早期配分と標準化アクション」です。
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：まず最初に役立った、来
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アップ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は、自民党MPステータスTLVは、通知メッセージに従っていることを示すために、LDPのステータスコードを割り当てました。 LDPレジストリ「LDPステータスコードネームスペース」に割り当てられた値は以下のとおりです。
LDP MP status - requested value 0x00000040
自民党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は、自民党MPステータスTLVのための新しいコードポイントを割り当てました。 LDPレジストリ「LDP TLVタイプ名前空間」に割り当てられた値は以下のとおりです。
LDP MP Status TLV Type - requested value 0x096F
自民党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、ヤコフ・レックター、ラウール・アガーウォール、アリエン・ボーア人、エリック・ローゼン、Nidhi Bhaskar、Toerlessエッカート、ジョージくん、ジンLizhong、バンソン・リム、エードリアンファレル、トーマス・モランそしてベン・ニーヴン・ジェンキンス。
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
シェーンAmanteレベル3コミュニケーションズ、LLC 1025エルドラドブールバードブルームフィールド、CO 80021米国電子メール：Shane.Amante@Level3.com
Luyuan Fang Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 US EMail: lufang@cisco.com
Luyuan牙シスコシステムズ300ビーバーブルック・ロードボックスボロー、MA 01719米国電子メール：lufang@cisco.com
Hitoshi Fukuda NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019, Japan EMail: 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
ゆじ かみて んっｔ こっむにかちおんｓ こｒぽらちおん ときょ おぺら しｔｙ とうぇｒ ３ー２０ー２ にし しんじゅく、 しんじゅくーく、 ときょ １６３ー１４２１、 じゃぱん えまいｌ： ｙ。かみて＠んっｔ。こｍ
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: kireeti@juniper.net
Kireeti Kompellaジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089米国電子メール：kireeti@juniper.net
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin Lannion, Cedex 22307 France EMail: jeanlouis.leroux@francetelecom.com
ジャン=ルイ・ルーフランステレコム2、大通りピエールMarzinラニオン、フランスCedexの22307 Eメール：jeanlouis.leroux@francetelecom.com
Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: ina@juniper.net
伊那Mineiジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089米国電子メール：ina@juniper.net
Bob Thomas Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA, 01719 EMail: bobthomas@alum.mit.edu
ボブトーマスシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA、01719 Eメール：bobthomas@alum.mit.edu
Lei Wang Telenor Snaroyveien 30 Fornebu 1331 Norway EMail: lei.wang@telenor.com
レイ王テレノールSnarøyveien30 Fornebu 1331ノルウェー電子メール：lei.wang@telenor.com
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a 1831 Diegem Belgium EMail: ice@cisco.com
IJsbrand Wijnandsシスコシステムズ株式会社Kleetlaan 6aの1831ディーゲムベルギーEメール：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]国際電気通信連合、ITU-T勧告V.42、1994年http://www.itu.int/rec/T、「非同期ツー同期変換を使用してのDCEのエラー訂正手順」 -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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "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]アガルワル、R.、Rekhter、Y.、およびE.ローゼン、 "MPLS上流ラベルの割り当てとコンテキスト固有のラベルスペース"、RFC 5331、2008年8月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561]トーマス、B.、ラザ、K.、アガルワル、S.、アガルワル、R.、およびJL。ル・ルー、 "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.トーマス、 "ラベル配布プロトコル（LDP） '型付きワイルドカード' フォワード等価クラス（FEC）"、RFC 5918、2010年8月。
[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, September 2011.
[RFC6389]アガルワル、R.およびJL。ル・ルー、 "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、第3版、1984年10月。
[L3VPN-MCAST] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", Work in Progress, January 2010.
[L3VPN-MCAST]ローゼン、E.、エド。、およびR.アガルワル、エド。、 "MPLS / BGP VPNのIPマルチキャストで"、進歩、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]スリニバサン、C.、Viswanathanの、A.、およびT.ナドーは、 "マルチプロトコルラベルスイッチング（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.ルチアーニは、 "マルチプロトコルラベルのための管理オブジェクトの定義は、スイッチング（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]アガルワルは、R.、エド、Papadimitriou、D.、エド、およびS.安川、エド、「リソース予約プロトコルへの拡張 - 。。。は、ポイント・ツー・マルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）は、スイッチパス（LSPを）」、RFC 4875、2007年5月。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332]エッカート、T.、ローゼン、E.、編、アガルワル、R.、およびY. Rekhter、 "MPLSマルチキャストカプセル化"、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]ル・ルー、J.、エド。、およびT.モリン、エド。、RFC 6348、2011年9月、「ラベル配布プロトコルへのポイント・ツー・マルチポイント機能拡張のための要件」。
Authors' Addresses
著者のアドレス
IJsbrand Wijnands (editor) Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium EMail: ice@cisco.com
IJsbrand Wijnands（エディタ）は、シスコシステムズ、株式会社Kleetlaan 6aはディーゲム1831ベルギーEメール：ice@cisco.com
Ina Minei (editor) Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: ina@juniper.net
伊那Minei（編集者）ジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089米国電子メール：ina@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: kireeti@juniper.net
Kireeti Kompellaジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089米国電子メール：kireeti@juniper.net
Bob Thomas 300 Beaver Brook Road Boxborough 01719 US EMail: bobthomas@alum.mit.edu
ボブ・トーマス300ビーバーブルック・ロードボックスボロー01719米国電子メール：bobthomas@alum.mit.edu