Internet Engineering Task Force (IETF) J. Le Roux, Ed.
Request for Comments: 6348 T. Morin, Ed.
Category: Historic France Telecom - Orange
ISSN: 2070-1721 September 2011
Requirements for Point-to-Multipoint Extensions
to the Label Distribution Protocol
Abstract
抽象
This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure.
この文書では、ポイント・ツー・マルチポイントを設定するためのラベル配布プロトコル（LDP）の拡張機能の設計に入力を務め機能要件のセットを示しています（P2MP）ラベルは、ポイント・ツー・マルチポイントを提供するために、パス（LSP）を交換しましたマルチプロトコルラベルスイッチング（MPLS）インフラストラクチャ上のアプリケーション。
This work was overtaken by the protocol solution developed by the MPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work.
この作品は、MPLSワーキンググループによって開発されたプロトコル・ソリューションに抜かれましたが、そのソリューションは密接にここに文書化要件に従っていませんでした。この文書は、プロトコルの仕事を形アイデアや要件の歴史的な記録として公開されています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントはインターネット標準化過程仕様ではありません。それは歴史的な記録のために公開されています。
This document defines a Historic Document for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのための歴史的な文書を定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6348.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6348で取得することができます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Context and Motivations . . . . . . . . . . . . . . . . . 6
1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . . 7
2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 7
3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 8
4. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9
4.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. P2MP LDP Routing . . . . . . . . . . . . . . . . . . . . . 10
4.4. Setting Up, Tearing Down, and Modifying P2MP LSPs . . . . 10
4.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10
4.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 11
4.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 11
4.8. P2MP LSP Rerouting . . . . . . . . . . . . . . . . . . . . 11
4.9. Support for Multi-Access Networks . . . . . . . . . . . . 12
4.10. Support for Encapsulation in P2P and P2MP TE Tunnels . . . 12
4.11. Label Spaces . . . . . . . . . . . . . . . . . . . . . . . 13
4.12. IPv4/IPv6 Support . . . . . . . . . . . . . . . . . . . . 13
4.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 13
4.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 14
4.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 14
4.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
4.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14
5. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15
6. Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . 16
6.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Contributing Authors . . . . . . . . . . . . . . . . . . . . . . . 20
This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP) [MLDP], in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure.
この文書では、ポイント・ツー・マルチポイント（P2MP）ラベルは、ポイント・ツーを提供するために、[MLDP]（LSP）のパスを交換セットアップするためのラベル配布プロトコル（LDP）の拡張機能の設計に入力を務め機能要件のセットを示していますマルチプロトコルラベルスイッチング（MPLS）インフラ上にマルチアプリケーション。
This work was overtaken by the protocol solution developed by the MPLS working group and documented in [MLDP]. That solution did not closely follow the requirements documented here, and it was recognized that this document had served its purpose in driving discussions of how the solution should be designed. At this point, no further action is planned to update this document in line with the protocol solution, and this document is published simply as a historic record of the ideas and requirements that shaped the protocol work.
この作業は、プロトコル溶液MPLSワーキンググループによって開発され[MLDP]に記録に取って代わられました。そのソリューションは、密接にここに文書化要件に従わなかった、そしてそれは、このドキュメントは、ソリューションを設計すべきかの議論を推進する上で、その目的を務めていたことが認められました。この時点で、それ以上のアクションは、プロトコル・ソリューションに合わせてこの文書を更新するために計画されていない、と本書は単にプロトコルの仕事を形アイデアや要件の歴史的な記録として公開されています。
The document is structured as follows:
次のように文書が構成されています。
o Section 2 is an overview of the requirements.
O部2は、要件の概要です。
o Section 3 illustrates an application scenario.
O部3は、アプリケーションシナリオを示します。
o Section 4 addresses detailed requirements for P2MP LSPs.
O 4章アドレスは、P2MP LSPの詳細な要件を。
o Section 5 discusses requirements for shared trees and multipoint-to-multipoint (MP2MP) LSPs.
O部5は、共有ツリーとマルチポイントツーマルチポイント（MP2MP）のLSPのための要件について説明します。
o Section 6 presents criteria against which a solution can be evaluated.
O部6は、ソリューションを評価することができ、これに対して基準を提示しています。
This document is a historic requirements document. To clarify statement of requirements, key words are used as follows. 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 [RFC2119].
この文書では、歴史的な要件文書です。次のような要件のステートメントを明確にするために、キーの単語が使用されています。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
P2P: Point-to-Point
P2P：ポイントツーポイント
MP2P: Multipoint-to-Point
MP2P：マルチポイント・ツー・ポイント
P2MP: Point-to-Multipoint
P2MP：ポイントツーマルチポイント
MP2MP: Multipoint-to-Multipoint
MP2MP：多対多
LSP: Label Switched Path
LSP：ラベルスイッチパス
LSR: Label Switching Router
LSR：ラベルスイッチングルータ
PE: Provider Edge
PE：プロバイダーエッジ
P: Provider
P：プロバイダー
IGP: Interior Gateway Protocol
IGP：インテリアゲートウェイプロトコル
AS: Autonomous System
AS：自律システム
The reader is assumed to be familiar with the terminology in [RFC3031], [RFC5036], and [RFC4026].
読者は、[RFC3031]、[RFC5036]及び[RFC4026]における用語に精通していると仮定されます。
Ingress LSR: Router acting as a sender of an LSP
イングレスLSR：ルータはLSPの送信者として働きます
Egress LSR: Router acting as a receiver of an LSP
出力LSR：ルータは、LSPの受信機として動作します
P2P LSP: An LSP that has one unique Ingress LSR and one unique Egress LSR
P2P LSP：LSP 1つのユニークイングレスのLSRと1つのユニークな出口LSRを持っています
MP2P LSP: An LSP that has one or more Ingress LSRs and one unique Egress LSR
MP2P LSP：1つの以上のイングレスのLSRと一つのユニークな出口LSRを持っているLSP
P2MP LSP: An LSP that has one unique Ingress LSR and one or more Egress LSRs
P2MP LSP：1つのユニークな入口LSRを持つLSPと1つまたは複数の出口のLSR
MP2MP LSP: An LSP that has one or more Leaf LSRs acting indifferently as Ingress or Egress LSR
MP2MP LSP：入力または出力LSRとして淡々と働く一つ以上のリーフのLSRを持っているLSP
Leaf LSR: An Egress LSR of a P2MP LSP or an Ingress/Egress LSR of an MP2MP LSP
リーフLSR：P2MP LSPの出口LSRまたはMP2MP LSPの入口/出口LSR
Transit LSR: An LSR of a P2MP or MP2MP LSP that has one or more downstream LSRs
トランジットLSR：一つ以上の下流のLSRを有するP2MP又はMP2MP LSPのLSR
Branch LSR: An LSR of a P2MP or MP2MP LSP that has more than one downstream LSR
分岐LSR：複数の下流LSRを有するP2MP又はMP2MP LSPのLSR
Bud LSR: An LSR of a P2MP or MP2MP LSP that is an Egress but also has one or more directly connected downstream LSR(s)
芽LSR：出口であるが、一つ以上の直接接続された下流LSR（複数可）を有するP2MPのLSRまたはMP2MP LSP
P2MP tree: The ordered set of LSRs and links that comprise the path of a P2MP LSP from its Ingress LSR to all of its Egress LSRs.
P2MPツリー：そのイングレスLSRからの出口のLSRの全てにP2MP LSPのパスを構成するのLSRとリンクの順序集合。
LDP [RFC5036] has been deployed for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point services in MPLS backbones.
LDP [RFC5036]はMPLSバックボーンにポイントツーポイントサービスを提供するために、ポイントツーポイント（P2P）とマルチポイントツーポイント（MP2P）LSPを設定するために配備されています。
There are emerging requirements for supporting delivery of point-to-multipoint applications in MPLS backbones, such as those defined in [RFC4834] and [RFC5501].
このような[RFC4834]及び[RFC5501]で定義されたもののようなMPLSバックボーンにポイント・ツー・マルチポイントのアプリケーションの配信をサポートするための新たな要件があります。
For various reasons, including consistency with P2P applications, and taking full advantages of MPLS network infrastructure, it would be highly desirable to use MPLS LSPs for the delivery of multicast traffic. This could be implemented by setting up a group of P2P or MP2P LSPs, but such an approach may be inefficient since it would result in data replication at the Ingress LSR and duplicate data traffic within the network.
P2Pアプリケーションとの一貫性、及びMPLSネットワークインフラストラクチャの完全な利点を取ることを含む様々な理由のため、マルチキャストトラフィックの配信のためのMPLS LSPを使用することが非常に望ましいであろう。これは、P2PまたはMP2P LSPのグループを設定することによって実現することができ、それが入口LSRでのデータ複製をもたらし、ネットワーク内のデータトラフィックを複製することになるので、このようなアプローチは、非効率的であってもよいです。
Hence, new mechanisms are required that would allow traffic from an Ingress LSR to be efficiently delivered to a number of Egress LSRs in an MPLS backbone on a point-to-multipoint LSP (P2MP LSP), avoiding duplicate copies of a packet on a given link and relying on MPLS traffic replication at some Branch LSRs.
したがって、新たな機構が進入LSRからのトラフィックを効率的に与えられた上でパケットの重複コピーを回避する、ポイント・ツー・マルチポイントLSP（P2MP LSP）上のMPLSバックボーンに出口LSRsの数に配信することを可能にすることが要求されていますリンクや一部支店のLSRでMPLSトラフィックの複製に依存します。
Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions for setting up point-to-multipoint Traffic Engineered LSPs (P2MP TE LSPs) have been defined in [RFC4875]. They meet requirements expressed in [RFC4461]. This approach is useful in network environments where P2MP Traffic Engineering capabilities are needed (optimization, QoS, fast recovery).
リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）をポイント・ツー・マルチポイントトラフィックエンジニアのLSP（P2MP TE LSPを）設定するための拡張機能は、[RFC4875]で定義されています。彼らは、[RFC4461]で表される要件を満たしています。このアプローチは、P2MPトラフィックエンジニアリング能力は（最適化、QoSの、高速リカバリ）に必要とされるネットワーク環境で有用です。
However, for operators who want to support point-to-multipoint traffic delivery on an MPLS backbone, without Traffic Engineering needs, and who have already deployed LDP for P2P traffic, an interesting and useful approach would be to rely on LDP extensions in order to set up point-to-multipoint (P2MP) LSPs. This would bring consistency with P2P MPLS applications and would ease the delivery of point-to-multipoint services in an MPLS backbone.
しかし、トラフィックエンジニアリングが必要であり、すでにP2PトラフィックにLDPを展開している人なしで、MPLSバックボーン上のポイント・ツー・マルチポイントトラフィックの配信をサポートしたい事業者のために、興味深く、有用なアプローチをするために、LDPの拡張に依存するだろうポイント・ツー・マルチポイント（P2MP）LSPを設定します。これは、P2PのMPLSのアプリケーションとの整合性をもたらすだろうし、MPLSバックボーンにおけるポイント・ツー・マルチポイントサービスの提供を容易にします。
This document focuses on the LDP approach for setting up P2MP LSPs. It lists a detailed set of requirements for P2MP extensions to LDP, so as to deliver P2MP traffic over an LDP-enabled MPLS infrastructure. The original intent was that these requirements should be used as guidelines when specifying LDP extensions.
この文書では、P2MP LSPを設定するためのLDPのアプローチに焦点を当てています。 LDP対応のMPLSインフラストラクチャ上でP2MPトラフィックを配信するようにそれは、自民党へのP2MPの拡張のための要件の詳細なセットを示しています。本来の目的は、自民党の拡張子を指定するときに、これらの要件は、ガイドラインとして使用されるべきであるということでした。
Note that generic requirements for P2MP extensions to MPLS are out of the scope of this document. Rather, this document describes solution-specific requirements related to LDP extensions in order to set up P2MP LSPs.
MPLSへのP2MPの拡張のための一般的な要件は、この文書の範囲外であることに注意してください。むしろ、このドキュメントはP2MP LSPを設定するために、LDPの拡張に関連するソリューション固有の要件について説明します。
Note also that other mechanisms could be used for setting up P2MP LSPs (for instance, PIM extensions), but these are out of the scope of this document. The objective is not to compare these mechanisms but rather to focus on the requirements for an LDP extension approach.
注意はまた、他のメカニズムはP2MPのLSPを（例えば、PIM拡張）を設定するために使用することができ、これらは、この文書の範囲外です。目的は、これらのメカニズムを比較することではなく、LDP拡張アプローチの要件に焦点を当てることではありません。
The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e., LSPs with one Ingress LSR and one or more Egress LSRs, with traffic replication at some Branch LSRs.
P2MP LDPメカニズムは、いくつかの支店のLSRでのトラフィックの複製で、P2MP LSPを、1のIngress LSRと1つまたは複数の出口のLSRと、すなわち、LSPを設定サポートしなければなりません。
The P2MP LDP mechanism MUST allow the addition or removal of leaves associated with a P2MP LSP.
P2MP LDP機構は、P2MP LSPに関連した葉の追加または除去を可能にしなければなりません。
The P2MP LDP mechanism MUST coexist with current LDP mechanisms and inherit its capability sets from [RFC5036]. It is of paramount importance that the P2MP LDP mechanism MUST NOT impede the operation of existing P2P/MP2P LDP LSPs. Also, the P2MP LDP mechanism MUST coexist with P2P and P2MP RSVP-TE mechanisms [RFC3209] [RFC4875]. It is of paramount importance that the P2MP LDP mechanism MUST NOT impede the operation of existing P2P and P2MP RSVP-TE LSPs.
P2MP LDP機構は、現在のLDP機構と共存し、[RFC5036]の能力セットを継承する必要があります。それはP2MP LDPメカニズムは、既存のP2P / MP2P LDP LSPの操作を妨げてはならないことを最も重要です。また、P2MP LDP機構は、P2PとP2MP RSVP-TEメカニズム[RFC3209]、[RFC4875]と共存しなければなりません。それはP2MP LDPメカニズムは、既存のP2PとP2MP RSVP-TEのLSPの操作を妨げてはならないことを最も重要です。
The P2MP LDP mechanism MAY also allow setting up multipoint-to-multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting indifferently as Ingress LSR or Egress LSR. This may allow a reduction in the amount of LDP state that needs to be maintained by an LSR.
P2MP LDP機構はまた、進入LSRまたは出力LSRとして無差別に作用葉のLSRのグループを接続するマルチポイント・ツー・マルチポイント（MP2MP）LSPを設定可能にすることができます。これはLSRによって維持される必要があるLDP状態の量の減少を可能にすることができます。
Figure 1 below illustrates an LDP-enabled MPLS provider network, used to carry both unicast and multicast traffic of VPN customers following, for instance, the architecture defined in [MVPN] for BGP/ MPLS VPNs or the one defined in [VPLS-MCAST].
図1は、以下、例えば、以下のVPN顧客のユニキャストとマルチキャストの両方のトラフィックを運ぶために使用されるLDP対応MPLSプロバイダネットワークを示し、BGP / MPLS VPNのために[MVPN]で定義されたアーキテクチャまたはで定義され、[VPLS-MCAST] 。
In this example, a set of MP2P LDP LSPs is set up between Provider Edge (PE) routers to carry unicast VPN traffic within the MPLS backbone (not represented in Figure 1).
この例では、MP2P LDP LSPのセットは、MPLSバックボーン（しない図1に示される）内にユニキャストVPNトラフィックを運ぶためにプロバイダエッジ（PE）ルータ間で設定されています。
In this example, a set of P2MP LDP LSPs is set up between PE routers acting as Ingress LSRs and PE routers acting as Egress LSRs, so as to support multicast VPN traffic delivery within the MPLS backbone.
MPLSバックボーン内のマルチキャストVPNトラフィックの配信をサポートするように、この例では、P2MP LDP LSPのセットは、入口のLSRとして動作するPEルータと出口LSRsとして機能するPEルータ間で設定されています。
For instance, a P2MP LDP LSP is set up between Ingress LSR PE1 and Egress LSRs PE2, PE3, and PE4. It is used to transport multicast traffic from PE1 to PE2, PE3, and PE4. P1 is a Branch LSR; it replicates MPLS traffic sent by PE1 to P2, P3, and PE2. P2 and P3 are non-Branch Transit LSRs; they forward MPLS traffic sent by P1 to PE3 and PE4, respectively.
例えば、P2MP LDP LSPはイングレスLSR PE1と出口LSRs PE2、PE3、PE4との間に設定されています。 PE1からPE2、PE3、及びPE4にマルチキャストトラフィックを転送するために使用されます。 P1は、分岐LSRです。それは、P2、P3、およびPE2にPE1によって送られたMPLSトラフィックを複製します。 P2とP3は非支店トランジットのLSRです。彼らはそれぞれ、PE3とPE4にP1によって送られたMPLSトラフィックを転送します。
PE1
*| *** P2MP LDP LSP
*|*****
P1-----PE2
*/ \*
*/ \*
*****/ \******
PE3----P2 P3----PE4
| |
| |
| |
PE5 PE6
Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4
図1：P2MP LSP PE1からPE2、PE3、PE4に
If later there are new receivers attached to PE5 and PE6, then PE5 and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and replicate traffic received from P1 to PE3 and PE5 and to PE4 and PE6, respectively (see Figure 2 below).
後でPE5およびPE6に取り付けた新しい受信機がある場合、PE5およびPE6はP2MP LDP LSPに参加します。 P2とP3ブランチのLSRになり、トラフィックを複製する（下記図2参照）は、それぞれ、PE3及びPE5およびPE4及びPE6にP1から受信しました。
PE1
*| *** P2MP LDP LSP
*|*****
P1-----PE2
*/ \*
*/ \*
*****/ \******
PE3----P2 P3----PE4
*| |*
*| |*
*| |*
PE5 PE6
Figure 2: Attachment of PE5 and PE6
図2：PE5とPE6の添付ファイル
The above example is provided for the sake of illustration. Note that P2MP LSPs Ingress and Egress LSRs may not necessarily be PE routers. Also, Branch LSRs may not necessarily be P routers.
上記の例は、例示のために提供されます。 P2MP LSPの入力および出力のLSRは、必ずしもPEルータでなくてもよいことに留意されたいです。また、支店のLSRは、必ずしもPルータではないかもしれません。
The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane aspects related to P2MP LSPs are those already defined in [RFC4461]. That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs. Traffic sent by the Ingress LSR is received by all Egress LSRs. The specific aspect related to P2MP LSPs is the action required at a Branch LSR, where data replication occurs. Incoming labeled data is appropriately replicated to several outgoing interfaces, which may use different labels.
P2MP LDPメカニズムはP2MPのLSPを設定サポートしなければなりません。 P2MPのLSPに関連するデータプレーン態様は既に[RFC4461]で定義されたものです。すなわち、P2MP LSPは、一の入口LSRおよび1つまたは複数の出口LSRsを有しています。イングレスLSRによって送信されたトラフィックは、すべての出口のLSRで受信されます。 P2MPのLSPに関連する特定の態様は、データ複製が発生ブランチLSR、で必要なアクションです。入ってくる標識データを適宜異なるラベルを使用することができるいくつかの発信インターフェイスに複製されます。
An LSR SHOULD NOT send more than one copy of a packet on any given link of a P2MP LSP. Exceptions to this are mentioned in Sections 4.9 and 4.18.
LSRは、P2MP LSPの任意のリンク上でのパケットの複数のコピーを送るべきではありません。これに対する例外は、セクション4.9および4.18に記載されています。
A P2MP LSP MUST be identified by a constant and unique identifier within the whole LDP domain, whatever the number of leaves, which may vary dynamically. This identifier will be used so as to add/remove leaves to/from the P2MP tree.
P2MP LSPは、動的に変化することができる全体LDPドメイン、葉のどのような数、内定数および一意の識別子によって識別されなければなりません。 P2MPツリーへ/から葉を追加/削除するようにこの識別子が使用されます。
As with P2P MPLS technology [RFC5036], traffic MUST be classified into a Forwarding Equivalence Class (FEC) in this P2MP extension. All packets that belong to a particular P2MP FEC and that travel from a particular node MUST use the same P2MP LSP.
P2P MPLS技術[RFC5036]と同様に、トラフィックがこのP2MP拡張に転送等価クラス（FEC）に分類されなければなりません。特定のノードから特定のP2MP FECとその旅行に所属するすべてのパケットが同じP2MP LSPを使用しなければなりません。
If existing FECs cannot be used for this purpose, a new LDP FEC that is suitable for P2MP forwarding MUST be specified.
既存のFECは、この目的のために使用することができない場合は、P2MPの転送に適している新しいLDP FECを指定する必要があります。
As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the information maintained in LSR Routing Information Bases (RIBs).
P2PとMP2P LDPのLSPと同様に、P2MP LDP機構は、ホップバイホップLSPルーティングをサポートしなければなりません。 P2MP LDPベースのルーティングは、LSRルーティング情報ベース（肋骨）に維持される情報に依存すべきです。
It is RECOMMENDED that the P2MP LSP routing rely upon the unicast route to the Ingress LSR to build a reverse path tree.
P2MP LSPルーティングをリバースパスツリーを構築するためにイングレスLSRへのユニキャスト経路に依存することが推奨されます。
The P2MP LDP mechanism MUST support the establishment, maintenance, and teardown of P2MP LSPs in a scalable manner. This MUST include both the existence of a large number of P2MP LSPs within a single network and a large number of Leaf LSRs for a single P2MP LSP (see also Section 4.17 for scalability considerations and figures).
P2MP LDPメカニズムは、スケーラブルな方法で確立、維持、およびP2MP LSPのティアダウンをサポートしなければなりません。これは、単一のネットワーク内のP2MP LSPの多数の存在と単一P2MP LSPのための葉のLSR多数の両方を含まなければなりません（スケーラビリティの考慮事項及び図面にも、セクション4.17を参照します）。
In order to scale well with a large number of leaves, it is RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For that purpose, leaves will have to be aware of the P2MP LSP identifier. The ways a Leaf LSR discovers P2MP LSP identifiers rely on the applications that will use P2MP LSPs and are out of the scope of this document.
葉の数が多いと十分にスケーリングするためには、葉が開始したP2MP LSP設定アプローチに従うことをお勧めします。そのために、葉はP2MP LSP識別子を認識する必要があります。やり方リーフLSRは、P2MP LSP識別子がP2MPのLSPを使用するアプリケーションに依存しており、この文書の範囲外である発見します。
The P2MP LDP mechanism MUST allow the dynamic addition and removal of leaves to and from a P2MP LSP, without any restriction (provided there is network connectivity). It is RECOMMENDED that these operations be leaf-initiated. These operations MUST NOT impact the data transfer (packet loss, duplication, delay) towards other leaves. It is RECOMMENDED that these operations do not cause any additional processing except on the path from the added/removed Leaf LSR to the Branch LSR.
P2MP LDP機構はP2MP LSPへとから葉の動的な追加および除去できるようにしなければならない、特に制限はなく、（ネットワーク接続が提供されます）。これらの操作はリーフ開始することをお勧めします。これらの動作は、他のリーフに向かってデータ転送（パケット損失、複製、遅延）を影響してはいけません。これらの操作は支店のLSRへの追加/削除リーフLSRからパスを除く任意の追加処理を起こさないことをお勧めします。
The P2MP LDP mechanism MUST support downstream unsolicited label advertisement mode. This is well suited to a leaf-initiated approach and is consistent with P2P/MP2P LDP operations.
P2MP LDPメカニズムは、下流の迷惑ラベル広告モードをサポートしなければなりません。これは、葉が開始したアプローチによく適しており、P2P / MP2P LDP操作と一致しています。
Other advertisement modes MAY also be supported.
他の広告モードもサポートされるかもしれません。
Data duplication refers to the receipt of multiple copies of a packet by any leaf. Although this may be a marginal situation, it may also be detrimental for certain applications. Hence, data duplication SHOULD be avoided as much as possible and limited to (hopefully rare) transitory conditions.
データの重複は、任意の葉によるパケットの複数のコピーの領収書を指します。これが限界な状況かもしれないが、それはまた、特定の用途に有害である可能性があります。よって、データの複製は可能な限りと（できればまれな）一時的条件に限定されると回避されるべきです。
Note, in particular, that data duplication might occur if P2MP LSP rerouting is being performed (see also Section 4.8).
P2MP LSPの再ルーティングが行われている場合、特に、そのデータの重複が発生する場合があります（セクション4.8を参照）。
The P2MP LDP extension MUST have a mechanism to detect routing loops. This MAY rely on extensions to the LDP loop detection mechanism defined in [RFC5036]. A loop detection mechanism MAY require recording the set of LSRs traversed on the P2MP tree. The P2MP loop avoidance mechanism MUST NOT impact the scalability of the P2MP LDP solution.
P2MP LDPの拡張は、ルーティングのループを検出するための機構を持たなければなりません。これは、[RFC5036]で定義されたLDPループ検出メカニズムの拡張機能に依存してもよいです。ループ検出メカニズムはP2MPツリー上の横断のLSRのセットを記録する必要になる場合があります。 P2MPループ回避メカニズムはP2MP LDP溶液のスケーラビリティに影響を与えてはいけません。
The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops in the data plane even during transient events.
P2MP LDP機構も過渡事象中のデータプレーンにルーティングループを回避するための機構を有しているべきです。
Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the data plane, which may trigger unexpected non-localized exponential growth of traffic.
また、P2MP LDP機構は、トラフィックの予想外の非局在化指数増殖をトリガすることができるデータプレーンにおけるルーティングのループを回避しなければなりません。
The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in the following cases:
P2MP LDP機構は、以下の場合にP2MP LSPの再ルーティングをサポートしなければなりません。
o Network failure (link or node);
Oネットワーク障害（リンク又はノード）。
o A better path exists (e.g., new link or metric change); and
Oより良い経路が存在する（例えば、新しいリンクまたは指標の変化）。そして
o Planned maintenance.
Oメンテナンスを予定。
Given that P2MP LDP routing should rely on the RIB, the achievement of the following requirements relies on the underlying routing protocols (IGP, etc.).
P2MP LDPルーティングがRIBに頼るべきであることを考えると、次の要件の達成は、基礎となるルーティングプロトコル（IGP、など）に依存しています。
The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case of link or node failure(s) by relying upon update of the routes in the RIB. The rerouting time SHOULD be minimized as much as possible so as to reduce traffic disruption.
P2MP LDP機構はRIB内のルートの更新に依存して、リンクまたはノードの障害（S）の場合にP2MP LSPの再ルーティングを可能にしなければなりません。トラフィックの中断を低減するように経路変更時には、可能な限り最小にしなければなりません。
A mechanism MUST be defined to prevent constant P2MP LSP teardown and rebuild, which may be caused by the instability of a specific link/ node in the network. This can rely on IGP dampening but may be completed by specific dampening at the LDP level.
メカニズムは、ネットワーク内の特定のリンク/ノードの不安定性に起因することができる、一定のP2MP LSPティアダウンを防止し、再構築するために定義されなければなりません。これは、減衰IGPに頼ることができますが、LDPレベルで特定の減衰によって完了することができます。
The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case a better path is created in the network, for instance, as a result of a metric change, a link repair, or the addition of links or nodes. This will rely on update of the routes in the RIB.
P2MP LDP機構は、メトリックの変更、リンクの修復、またはリンクまたはノードの添加の結果として、例えば、より良好なパスがネットワークで作成された場合にP2MP LSPの再ルーティングを可能にしなければなりません。これは、RIB内のルートの更新に依存しています。
The P2MP LDP mechanism MUST support planned maintenance operations. It MUST be possible to reroute a P2MP LSP before a link/node is deactivated for maintenance purposes. Traffic disruption and data duplication SHOULD be minimized as much as possible during such planned maintenance. P2MP LSP rerouting upon planned maintenance MAY rely on a make-before-break procedure.
P2MP LDPメカニズムは、計画的なメンテナンス作業をサポートしなければなりません。リンク/ノードはメンテナンスのために非アクティブ化される前に、P2MP LSPを再ルーティングすることも可能でなければなりません。トラフィックの中断やデータの重複は、そのような計画的なメンテナンス中に可能な限り最小にしなければなりません。計画的なメンテナンス時に再ルーティングP2MP LSPは、メイク・ビフォア・ブレークの手順に依拠することができます。
The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send a single copy of the data onto an interface to a multi-access network (e.g., an Ethernet LAN) and reach multiple adjacent downstream nodes. This requires that the same label be negotiated with all downstream LSRs for the LSP.
P2MP LDP機構は、分岐LSRは、マルチアクセスネットワーク（例えば、イーサネットLAN）へのインタフェースへのデータの単一のコピーを送信し、複数の隣接する下流ノードに到達するための方法を提供すべきです。これは、同じラベルはLSPのためのすべての川下のLSRと交渉されている必要があります。
When there are several candidate upstream LSRs on an interface to a multi-access LAN, the P2MP LDP mechanism SHOULD provide a way for all downstream LSRs of a given P2MP LSP to select the same upstream LSR, so as to avoid traffic replication. In addition, the P2MP LDP mechanism SHOULD allow for an efficient balancing of a set of P2MP LSPs among a set of candidate upstream LSRs on a LAN interface.
マルチアクセスLANへのインタフェース上のいくつかの候補上流のLSRが存在する場合、P2MP LDP機構は、トラフィックの複製を回避するように、同一のアップストリームLSRを選択するための所定のP2MP LSPのすべてのダウンストリームLSRのための方法を提供すべきです。また、P2MP LDP機構は、LANインターフェイス上の候補上流のLSRのセット間P2MP LSPのセットの効率的な分散を可能にするはずです。
The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and P2MP TE tunnels.
P2MP LDPメカニズムはP2PとP2MP TEトンネルの中に入れ子にP2MPのLSPをサポートしなければなりません。
The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a single copy of the data onto the tunnel and reach all downstream LSRs on the P2MP LSP, which are also Egress LSRs of the tunnel. As with LAN interfaces, this requires that the same label be negotiated with all downstream LSRs of the P2MP LDP LSP.
P2MP LDP機構は、トンネルへのデータの単一のコピーを送信するために、また、P2MP TEトンネルのヘッドエンドLSRであるP2MP LSPの分岐LSRのための方法を提供し、P2MP LSP上のすべての下流のLSRに到達しなければなりませんまた、トンネルの出口LSRsです。 LANインターフェイスと同様に、これは、同じラベルがP2MP LDP LSPの全ての下流のLSRと交渉することを必要とします。
Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or dedicated label spaces.
P2MPのLSPをとP2P / MP2PのLSPのためのラベルは、共有または専用のラベルスペースから割り当ててもよいです。
Note that dedicated label spaces will require the establishment of separate P2P and P2MP LDP sessions.
専用のラベルスペースが別々のP2PとP2MP LDPセッションの確立が必要になることに注意してください。
The P2MP LDP mechanism MUST support the establishment of LDP sessions over both IPv4 and IPv6 control planes.
P2MP LDP機構は、IPv4とIPv6の制御プレーンの両方にわたってLDPセッションの確立をサポートしなければなりません。
The P2MP LDP mechanism MUST support the establishment of multi-area P2MP LSPs, i.e., LSPs whose leaves do not all reside in the same IGP area as the Ingress LSR. This SHOULD be possible without requiring the advertisement of Ingress LSRs' addresses across IGP areas.
P2MP LDP機構、すなわち、LSPのその葉すべての入力LSRと同じIGP領域に存在しない、マルチエリアP2MP LSPの確立をサポートしなければなりません。これは、IGPエリア全体でイングレスのLSRアドレスの広告を必要とせずに可能なはずです。
The P2MP LDP mechanism MUST also support the establishment of inter-AS P2MP LSPs, i.e., LSPs whose leaves do not all reside in the same AS as the Ingress LSR. This SHOULD be possible without requiring the advertisement of Ingress LSRs' addresses across ASes.
P2MP LDP機構はまたすなわち、LSPのその葉すべてが入口LSRと同様に存在しない、AS間P2MP LSPの確立をサポートしなければなりません。これは、のAS間のIngress LSRのアドレスの広告を必要とせずに可能なはずです。
LDP management tools ([RFC3815], etc.) will have to be enhanced to support P2MP LDP extensions. This may yield a new MIB module, which may possibly be inherited from the LDP MIB.
LDP管理ツール（[RFC3815]など）はP2MP LDP拡張をサポートするように拡張する必要があります。これはおそらくLDP MIBから継承することができる新たなMIBモジュールを、もたらすことができます。
Built-in diagnostic tools MUST be defined to check the connectivity, trace the path, and ensure fast detection of data plane failures on P2MP LDP LSPs.
内蔵の診断ツールは、接続性を確認し、パスをトレースし、P2MP LDPのLSP上のデータプレーンの障害の迅速な検出を確実にするために定義されなければなりません。
Further and precise requirements and mechanisms for P2MP MPLS Operations, Administration, and Maintenance (OAM) purposes are out of the scope of this document and are addressed in [RFC4687].
更にとP2MP MPLS操作、管理するための正確な要件とメカニズム、および保守（OAM）の目的は、この文書の範囲外であり、[RFC4687]でアドレス指定されます。
LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs.
LDPグレースフルリスタートメカニズム[RFC3478]および障害回復メカニズム[RFC3479]はP2MP LDP LSPをサポートするように拡張されるべきです。
A solution MUST be designed to re-establish connectivity for P2MP and MP2MP LSPs in the event of failures, provided there exists network connectivity between ingress and egress nodes (i.e., designed without introducing single points of failure).
溶液は、障害発生時にP2MPとMP2MPのLSPの接続を再確立するように設計されなければならない（すなわち、単一障害点を導入せずに設計された）入口と出口ノード間のネットワーク接続が存在しました。
Scalability is a key requirement for the P2MP LDP mechanism. It MUST be designed to scale well with an increase in the number of any of the following:
スケーラビリティは、P2MP LDPメカニズムのための重要な要件です。次のいずれかの数の増加とよく拡張できるように設計されなければなりません。
o Number of Leaf LSRs per P2MP LSP;
P2MP LSP当たりの葉のLSRのO番号。
o Number of downstream LSRs per Branch LSR; and
支店LSRあたりの下流のLSRのOの数。そして
o Number of P2MP LSPs per LSR.
LSRあたりのP2MP LSPのOの数。
In order to scale well with an increase in the number of leaves, it is RECOMMENDED that the size of a P2MP LSP state on an LSR, for one particular LSP, depend only on the number of adjacent LSRs on the LSP.
葉数の増加に伴って十分にスケーリングするためには、LSRにP2MP LSPの状態のサイズは、一つの特定のLSPのために、LSP上の隣接のLSRの数にのみ依存することが推奨されます。
Typical orders of magnitude that we expect should be supported are:
私たちが支援されるべき期待の大きさの典型的なオーダーは以下のとおりです。
o Tens of thousands of P2MP trees spread out across core network routers; and
Oコア・ネットワーク・ルータにまたがってP2MP木の数万。そして
o Hundreds, or a few thousands, of leaves per tree.
木あたりの葉のO何百、あるいは数千、。
See also Section 4.2 of [RFC4834].
また、[RFC4834]のセクション4.2を参照してください。
In order to allow for a smooth migration, the P2MP LDP mechanism SHOULD offer as much backward compatibility as possible. In particular, the solution SHOULD allow the setup of a P2MP LSP along non-Branch Transit LSRs that do not support P2MP LDP extensions.
スムーズな移行を可能にするために、P2MP LDP機構はできるだけ後方互換性を提供するべきです。具体的には、解決策は、P2MP LDP拡張をサポートしていない非支店トランジットのLSRに沿ってP2MP LSPの設定を可能にしなければなりません。
Also, the P2MP LDP solution MUST coexist with current LDP mechanisms and inherit its capability sets from [RFC5036]. The P2MP LDP solution MUST NOT impede the operation of P2P/MP2P LSPs. A P2MP LDP solution MUST be designed in such a way that it allows P2P/MP2P and P2MP LSPs to be signaled on the same interface.
また、P2MP LDP溶液は、現在のLDP機構と共存し、[RFC5036]の能力セットを継承する必要があります。 P2MP LDPソリューションは、P2P / MP2PのLSPの操作を妨げてはなりません。 P2MP LDP溶液は、同じインタフェース上でシグナリングされるP2P / MP2PとP2MP LSPを可能にするように設計されなければなりません。
For traffic delivery between a group of N LSRs that act as egress and/or egress nodes on different P2MP flows, it may be useful to set up a shared tree connecting all these LSRs instead of having N P2MP LSPs. This would reduce the amount of control and forwarding state that has to be maintained on a given LSR.
異なるP2MPフロー上の出口及び/又は出口ノードとして機能するN個のLSRのグループ間のトラフィック配信のために、すべてのこれらのLSRを接続する代わりにN P2MPのLSPを有する共有ツリーを設定することが有用であり得ます。これは、与えられたLSRで維持されなければならない制御及び転送状態の量を減少させるであろう。
There are two main options for supporting such shared trees:
そのような共有ツリーを支援するための2つの主要なオプションがあります。
o Relying on the applications' protocols that use LDP LSPs. A shared tree could consist of the combination of an MP2P LDP LSP from Leaf LSRs to a given root node with a P2MP LSP from this root to Leaf LSRs. For instance, with Multicast L3 VPN applications, it would be possible to build a shared tree by combining (see [MVPN]):
O LDP LSPを使用してアプリケーションのプロトコルに依存します。共有ツリーは、リーフのLSRにこのルートからP2MP LSPと所与のルートノードのリーフのLSRからMP2P LDP LSPの組み合わせからなる可能性があります。例えば、マルチキャストL3 VPNアプリケーションでは、（[MVPN]参照）を組み合わせることにより、共有ツリーを構築することも可能です。
* An MP2P unicast LDP LSP, from each PE router of the group to a particular root PE router acting as tree root and
グループの各PEルータからツリーのルートとして機能する特定のルートPEルータに* MP2PユニキャストLDP LSP、および
* A P2MP LDP LSP from this root PE router to each PE router of the group.
*グループの各PEルータにこのルートPEルータからP2MP LDP LSP。
o Relying on a specific LDP mechanism allowing the setup of multipoint-to-multipoint MPLS LSPs (MP2MP LSPs).
マルチポイント・ツー・マルチポイントMPLSのLSP（MP2MPのLSP）の設定を可能にする特定のLDPメカニズムに依拠O。
The former approach (combination of MP2P and P2MP LSPs at the application level) is out of the scope of this document while the latter (MP2MP LSPs) is within the scope of this document. Requirements for the setup of MP2MP LSPs are listed below.
（MP2MPのLSP）後者は、この文書の範囲内である前者のアプローチ（アプリケーションレベルでMP2PとP2MP LSPの組み合わせ）は、この文書の範囲外です。 MP2MP LSPのセットアップのための要件は以下のとおりです。
A multipoint-to-multipoint (MP2MP) LSP is an LSP connecting a group of Leaf LSRs acting as Egress and/or Ingress LSRs. Traffic sent by any Leaf LSR is received by all other Leaf LSRs of the group.
マルチポイント・ツー・マルチポイント（MP2MP）LSPは、出力および/または入力のLSRとして動作葉のLSRのグループを接続LSPです。任意のリーフLSRによって送信されるトラフィックは、グループの他のすべての葉のLSRで受信されます。
Procedures for setting up MP2MP LSPs with LDP SHOULD be specified. An implementation that supports P2MP LDP LSPs MAY also support MP2MP LDP LSPs.
自民党とMP2MP LSPを設定するための手順を指定する必要があります。 P2MP LDP LSPをサポートする実装もMP2MP LDP LSPをサポートするかもしれません。
The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP.
MP2MP LDP手順は、P2MP LSPの動作を妨げてはなりません。
Requirements for P2MP LSPs, set forth in Section 4, apply equally to MP2MP LSPs. Particular attention should be given to the requirements below:
セクション4に記載のP2MP LSPのための要件は、MP2MPのLSPに等しく適用されます。特に注目は、以下の要件に与えられるべきです。
o The solution MUST support recovery upon link and transit node failure and be designed to re-establish connectivity for MP2MP LSPs in the event of failures, provided network connectivity exists between ingress and egress nodes (i.e., designed without introducing single points of failure).
O溶液は、リンクとトランジットノード障害発生時のリカバリをサポートしなければならないし、提供されたネットワーク接続が入口と出口ノードの間に存在し、障害発生時におけるMP2MPのLSPのための再確立接続するように設計される（すなわち、単一障害点を導入せずに設計されました）。
o The size of MP2MP state on an LSR, for one particular MP2MP LSP, SHOULD only depend on the number of adjacent LSRs on the LSP.
O LSRにMP2MP状態のサイズは、特定の一MP2MP LSPのために、唯一のLSP上の隣接のLSRの数に依存すべきです。
o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that may trigger exponential growth of traffic. Note that this requirement is more challenging with MP2MP LSPs as an LSR may need to receive traffic for a given LSP on multiple interfaces.
Oさらに、MP2MP LDP機構は、トラフィックの急激な成長をトリガすることができるルーティングのループを回避しなければなりません。 LSRは、複数のインターフェイス上で与えられたLSPのトラフィックを受信する必要がある場合があり、この要件はMP2MPのLSPでより困難であることに留意されたいです。
There are additional requirements specific to MP2MP LSPs:
MP2MPのLSPに固有の追加要件があります。
o It is RECOMMENDED that an MP2MP MPLS LSP is built based on the unicast route to a specific LSR called root LSR.
O MP2MP MPLS LSPがルートLSRと呼ばれる特定のLSRへのユニキャスト経路に基づいて構築することが推奨されます。
o It is RECOMMENDED to define several root LSRs (e.g., a primary and a backup) to ensure redundancy upon root LSR failure.
OルートLSR障害時の冗長性を確保するために、いくつかのルートのLSR（例えば、プライマリとバックアップ）を定義することをお勧めします。
o The receiver SHOULD NOT receive back a packet it has sent on the MP2MP LSP.
O受信機は、それがMP2MP LSP上で送信されたパケットをバック受け取るべきではありません。
o The solution SHOULD avoid that all traffic between any pair of leaves is traversing a root LSR (similarly to PIM-Bidir trees) and SHOULD provide the operator with means to minimize the delay between two leaves.
O溶液は葉の任意の対の間のすべてのトラフィックは、（同様にPIM-双方向ツリーに）ルートLSRを横断して2枚の葉の間の遅延を最小限にする手段をオペレータに提供すべきであることを避けなければなりません。
o It MUST be possible to check connectivity of an MP2MP LSP in both directions.
O両方向にMP2MP LSPの接続性を確認することが可能でなければなりません。
The solution will be evaluated with respect to the following criteria:
解決策は、以下の基準に関して評価されます。
(1) Efficiency of network resource usage;
（1）ネットワークリソース使用の効率を、
(2) Time to add or remove a Leaf LSR;
（2）葉LSRを追加または削除する時間を、
(3) Time to repair a P2MP LSP in case of link or node failure; and
（3）リンクまたはノードの障害が発生した場合にP2MP LSPを修復するための時間を、そして
(4) Scalability (state size, number of messages, message size).
（4）スケーラビリティ（状態サイズ、メッセージの数、メッセージサイズ）。
Particularly, the P2MP LDP mechanism SHOULD be designed with the key objective of minimizing the additional amount of state and additional processing required in the network.
特に、P2MP LDP機構は、状態およびネットワークに必要な追加の処理の追加の量を最小化するキー目的で設計されるべきです。
Also, the P2MP LDP mechanism SHOULD be designed so that convergence times in case of link or node failure are minimized, in order to limit traffic disruption.
リンクまたはノードの障害の場合には収束時間が最小化されるように、また、P2MP LDP機構は、トラフィックの中断を制限するために、設計されるべきです。
The proposed solution SHOULD NOT introduce complexity to the current LDP operations to such a degree that it would affect the stability and diminish the benefits of deploying such solution.
提案された解決策は、それが安定性に影響し、このようなソリューションを展開する利点を減少させるであろうと、そのような程度に、現在のLDP操作の複雑さを導入すべきではありません。
It is expected that addressing the requirements defined in this document should not introduce any new security issues beyond those inherent to LDP and that a P2MP LDP solution will rely on the security mechanisms defined in [RFC5036] (e.g., TCP MD5 Signature).
この文書で定義された要件に対処することはLDPに固有のものを超えてどんな新しいセキュリティ問題を紹介し、P2MP LDPソリューションは、[RFC5036]（例えば、TCP MD5署名）で定義されたセキュリティ・メカニズムに依存しているということではないはずであることが期待されます。
An evaluation of the security features for MPLS networks may be found in [RFC5920], and where issues or further work is identified by that document, new security features or procedures for the MPLS protocols will need to be developed.
MPLSネットワークのためのセキュリティ機能の評価は、[RFC5920]で見つけられるかもしれ、および問題や、さらに作業がその文書で識別された場合、MPLSプロトコルの新しいセキュリティ機能や手順を開発する必要があります。
We would like to thank Christian Jacquenet, Hitoshi Fukuda, Ina Minei, Dean Cheng, and Benjamin Niven-Jenkins for their highly useful comments and suggestions. We would like to thank Adrian Farrel for reviewing this document before publication.
私たちは、彼らの非常に有用なコメントと提案のためのキリスト教のJacquenet、仁福田、伊那Minei、ディーン・チェン、そしてベンジャミンニーヴン・ジェンキンスに感謝したいと思います。私たちは、出版前に、このドキュメントを再検討するためにエードリアンファレルに感謝したいと思います。
We would also like to thank the authors of [RFC4461], which inspired some of the text in this document.
また、この文書内のテキストの一部に影響を与えた[RFC4461]、の作者に感謝したいと思います。
[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月。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478] Leelanivas、M.、Rekhter、Y.、およびR.アガルワル、 "ラベル配布プロトコルのためのグレースフルリスタートメカニズム"、RFC 3478、2003年2月。
[RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479]、RFC 3479、2003年2月ファレル、A.、 "ラベル配布プロトコル（LDP）のためのフォールトトレランス"。
[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月。
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]安川、S.、RFC 4461、2006年4月「ポイントツーマルチポイントトラフィック・エンジニアMPLSラベルのためのシグナリング要件は、スイッチパス（LSP）」。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、Minei、I.、およびB.トーマス、 "LDP仕様"、RFC 5036、2007年10月。
[MLDP] Minei, I., Wijnands, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, August 2011.
[MLDP] Minei、I.、Wijnands、I.、Kompella、K.、およびB.トーマス、「ラベル配布プロトコルの拡張機能は、ポイント・ツー・マルチポイントおよびマルチポイント・ツー・マルチポイントラベルは、パスの交換」、進歩、8月で仕事を2011。
[MVPN] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP VPNs", Work in Progress, January 2010.
【MVPN]アガルワル、R.、バンディ、S.、カイ、Y.、モリン、T.、Rekhter、Y.、ローゼン、E.、Wijnands、I.、およびS.安川、「MPLS / BGP IPにおけるマルチキャストVPN」を、進歩、2010年1月の作業。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]アンデションとL.とT.マドセン、 "プロバイダーのプロビジョニングされた仮想プライベートネットワーク（VPN）用語"、RFC 4026、2005月。
[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006.
[RFC4687]安川、S.、ファレル、A.、キング、D.、およびT.ナドー、 "操作とポイントツーマルチポイントMPLSネットワークの管理（OAM）要件"、RFC 4687、2006年9月。
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[RFC4834]モリン、T.、エド。、 "レイヤーでのマルチキャストのための要件3プロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）"、RFC 4834、2007年4月。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "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.安川は、 - 、、RFC 4875の "機能拡張は、予約プロトコルリソースへのポイントツーマルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）がスイッチパス（LSP）" 2007年5月。
[RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang, "Requirements for Multicast Support in Virtual Private LAN Services", RFC 5501, March 2009.
[RFC5501] Kamite、Y.、和田、Y.、Serbest、Y.、モリン、T.、およびL.牙、 "仮想プライベートLANサービスにおけるマルチキャストサポートのための要件"、RFC 5501、2009年3月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]牙、L.、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、RFC 5920、2010年7月。
[VPLS-MCAST] Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, "Multicast in VPLS", Work in Progress, July 2011.
[VPLS-MCAST]アガルワル、R.、Kamite、Y.、牙、L.、およびY. Rekhter、 "VPLSでマルチキャスト"、進歩、2011年7月での作業。
Contributing Authors
共著
Vincent Parfait France Telecom - Orange, Orange Business Services
ヴィンセントパーフェクトフランステレコム - オレンジ、オレンジビジネスサービス
EMail: vincent.parfait@orange-ftgroup.com
メールアドレス：vincent.parfait@orange-ftgroup.com
Luyuan Fang Cisco Systems, Inc.
袁オウシスコシステムズ、株式会社FリットルのU
EMail: lufang@cisco.com
メールアドレス：lufang@cisco.com
Lei Wang Telenor
レイ王Telenor社
EMail: lei.wang@telenor.com
メールアドレス：lei.wang@telenor.com
Yuji Kamite NTT Communications Corporation
NT雄二委員コミュニケーションズ株式会社
EMail: y.kamite@ntt.com
メールアドレス：y.kamite@ntt.com
Shane Amante Level 3 Communications, LLC
シェーンAmanteレベル3コミュニケーションズ、LLC
EMail: shane@level3.net
メールアドレス：shane@level3.net
Authors' Addresses
著者のアドレス
Jean-Louis Le Roux (editor) France Telecom - Orange
ジャン=ルイ・ルー（編集者）フランステレコム - オレンジ
EMail: jeanlouis.leroux@orange-ftgroup.com
メールアドレス：jeanlouis.leroux@orange-ftgroup.com
Thomas Morin (editor) France Telecom - Orange
トーマス・モリン（編集者）フランステレコム - オレンジ
EMail: thomas.morin@orange-ftgroup.com
メールアドレス：thomas.morin@orange-ftgroup.com