[要約] RFC 6348は、ラベル配布プロトコルのポイントツーマルチポイント拡張に関する要件を定義しています。このRFCの目的は、ポイントツーマルチポイント通信の効率と信頼性を向上させるためのガイドラインを提供することです。
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.
このドキュメントには、ポイントツーマルチポイントを配信するために、ポイントツーマルチポイント（P2MP）ラベルスイッチパス（LSP）を設定するためのラベル分布プロトコル（LDP）拡張機能の設計への入力として機能する一連の機能要件がリストされています。マルチプロトコルラベルスイッチング（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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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）ラベルスイッチ付きパス（LSP）[MLDP]を設定するためのラベル分布プロトコル（LDP）拡張の設計への入力として機能する一連の機能要件がリストされています。マルチプロトコルラベルスイッチング（MPLS）インフラストラクチャを介したTO-MULTIPOINTアプリケーション。
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].
このドキュメントは、歴史的な要件文書です。要件の声明を明確にするために、キーワードは次のように使用されます。「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
P2P: Point-to-Point
P2P：ポイントツーポイント
MP2P: Multipoint-to-Point
MP2P：マルチポイントツーポイント
P2MP: Point-to-Multipoint
P2MP：ポイントツーマルチポイント
MP2MP: Multipoint-to-Multipoint
MP2MP：Multipoint-to-Multipoint
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
Ingress 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：1つのユニークなイングレスLSRと1つのユニークな出口LSRを備えたLSP
MP2P LSP: An LSP that has one or more Ingress LSRs and one unique Egress LSR
MP2P LSP：1つ以上の侵入LSRと1つのユニークな出力LSRを備えたLSP
P2MP LSP: An LSP that has one unique Ingress LSR and one or more Egress LSRs
P2MP LSP：1つのユニークな侵入LSRと1つ以上の出口LSRを備えたLSP
MP2MP LSP: An LSP that has one or more Leaf LSRs acting indifferently as Ingress or Egress LSR
MP2MP LSP：侵入または出口として無関心に作用する1つまたは複数の葉の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
Transit LSR：1つ以上の下流LSRSを備えたP2MPまたはMP2MP LSPのLSR
Branch LSR: An LSR of a P2MP or MP2MP LSP that has more than one downstream LSR
Branch 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)
BUD LSR：出口であるが、1つ以上の直接接続された下流LSRもあるP2MPまたはMP2MP LSPのLSR
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のグループをセットアップすることで実装できますが、このようなアプローチは、Ingress 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バックボーンで多くの出力LSRに効率的に配信できるようにする新しいメカニズムが必要であり、特定のパケットの重複コピーを回避します。一部のブランチ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).
リソース予約プロトコル - ポイントツーマルチポイントトラフィックエンジニアリングLSP（P2MP TE LSP）を設定するためのトラフィックエンジニアリング（RSVP-TE）拡張は、[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
ただし、交通工学のニーズなしにMPLSバックボーンでのポイントツーマルチポイントトラフィックの配信をサポートしたいオペレーターの場合、P2PトラフィックのLDPをすでに展開している場合、興味深い有用なアプローチは、LDP拡張に依存することです。ポイントツーマルチポイント（P2MP）LSPを設定します。これはもたらされます
consistency with P2P MPLS applications and would ease the delivery of point-to-multipoint services in an MPLS backbone.
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拡張の詳細な要件をLDPにリストします。当初の意図は、LDP拡張機能を指定する際にこれらの要件をガイドラインとして使用する必要があることでした。
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メカニズムは、P2MP LSP、つまり1つの侵入LSRと1つ以上の出力LSRを備えたLSPのセットアップをサポートする必要があり、一部のブランチLSRにトラフィックレプリケーションがあります。
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またはEgress 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は、たとえば、BGP/ MPLS VPNの[MVPN]で定義されているアーキテクチャまたは[VPLS-Mcast]で定義されているものの[MVPN]で定義されているアーキテクチャをフォローしているLDP対応MPLSプロバイダーネットワークを示しています。。
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のセットがプロバイダーエッジ（PE）ルーターの間にセットアップされ、MPLSバックボーン内でユニキャストVPNトラフィックを運ぶ（図1には表されません）。
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のセットが、侵入LSRSとして機能するPEルーターと出口LSRとして機能する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は、Ingress LSR PE1と出力LSRS PE2、PE3、およびPE4の間にセットアップされています。マルチキャストトラフィックをPE1からPE2、PE3、およびPE4に輸送するために使用されます。P1はブランチLSRです。PE1からP2、P3、およびPE2に送信されたMPLSトラフィックを複製します。P2およびP3は非枝型のトランジットLSRです。P1から送信されたMPLSトラフィックをそれぞれPE3とPE4に転送します。
PE1
*| *** P2MP LDP LSP
*|*****
P1-----PE2
*/ \*
*/ \*
*****/ \******
PE3----P2 P3----PE4
| |
| |
| |
PE5 PE6
Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4
図1：PE1からPE2、PE3、PE4へのP2MP LSP
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になり、それぞれP1からPE3およびPE5、およびPE4とPE6に受け取ったトラフィックを複製します（以下の図2を参照）。
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 LSPSイングレスおよび出力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には1つの侵入LSRと1つ以上の出力LSRがあります。Ingress 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ルーティング情報ベース（RIBS）で維持されている情報に依存する必要があります。
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メカニズムは、リブのルートの更新に依存することにより、リンクまたはノード障害の場合に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メカニズムは、Branch 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メカニズムは、特定のP2MP LSPのすべての下流LSRが同じアップストリームLSRを選択する方法を提供する必要があります。さらに、P2MP LDPメカニズムは、LANインターフェイス上の一連の候補の上流LSRSの中でP2MP LSPのセットの効率的なバランスをとることを可能にする必要があります。
The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and P2MP TE tunnels.
P2MP LDPメカニズムは、P2Mと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 LSPのブランチLSR（P2MP TEトンネルのヘッドエンドLSRでもある）の方法を提供し、データのコピーをトンネルに単一のコピーを送信し、P2MP LSPのすべての下流LSRに到達する必要があります。、トンネルのLSRも出口です。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メカニズムは、マルチエリアP2MP LSPの確立をサポートする必要があります。つまり、葉がすべてがイングレスLSRと同じIGP領域に存在するわけではないLSPです。これは、IGPエリア全体のIngress LSRSのアドレスの広告を必要とせずに可能です。
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メカニズムは、P2MP間LSPをAS Inter-AS P2MP LSPの確立、つまり葉がすべてがイングレスLSRと同じに存在するわけではないLSPの確立もサポートする必要があります。これは、ASES全体のIngress LSRSのアドレスの広告を必要とせずに可能です。
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拡張機能をサポートするために強化する必要があります。これにより、新しいMIBモジュールが生成される可能性があります。これは、LDP 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;
o P2MP LSPあたりの葉LSRの数。
o Number of downstream LSRs per Branch LSR; and
o ブランチLSRあたりの下流LSRの数。と
o Number of P2MP LSPs per LSR.
o LSRあたりのP2MP LSPの数。
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状態のサイズは、1つの特定の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のグループ間の交通納品の場合、N P2MP LSPを持つ代わりに、これらすべてのLSRを接続する共有ツリーをセットアップすると便利かもしれません。これにより、特定の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を使用して、LEAF LSRSから特定のルートノードまでの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).
o 特定のLDPメカニズムに依存して、Multipoint-toMultiPoint MPLS LSP（MP2MP LSP）のセットアップを可能にします。
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.
前者のアプローチ（アプリケーションレベルでのMP2PとP2MP LSPの組み合わせ）はこのドキュメントの範囲外であり、後者（MP2MP 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.
Multipoint-to-Multipoint（MP2MP）LSPは、出口および/または侵入LSRSとして機能する葉の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.
LDPを使用して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 1つの特定のMP2MP LSPのLSR上のMP2MP状態のサイズは、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は、root 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 解決策は、葉のペア間のすべてのトラフィックがルート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.
Christian Jacquenet、Hitoshi Fukuda、Ina Minei、Dean Cheng、およびBenjamin Niven-Jenkinsの非常に有用なコメントと提案に感謝します。公開前にこのドキュメントをレビューしてくれたAdrian Farrelに感謝します。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[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. Aggarwal、「ラベル分布プロトコルの優雅な再起動メカニズム」、RFC 3478、2003年2月。
[RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479] Farrel、A。、「ラベル分布プロトコル（LDP）のフォールトトレランス」、RFC 3479、2003年2月。
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[RFC3815] Cucchiara、J.、Sjostrand、H。、およびJ. Luciani、「マルチプロトコルラベルスイッチング（MPLS）の管理オブジェクトの定義、ラベル分布プロトコル（LDP）」、RFC 3815、2004年6月。
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461] Yasukawa、S。、「ポイントツーマルチポイントトラフィックエンジニアリングMPLSラベルスイッチドパス（LSP）のシグナリング要件」、RFC 4461、2006年4月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「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] Mighei、I.、Wijnands、I.、Kompella、K。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルの切り替えパスのラベル分布プロトコル拡張」、進行中の作業、8月、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] Aggarwal、R.、Bandi、S.、Cai、Y.、Morin、T.、Rekhter、Y.、Rosen、E.、Wijnands、I。、およびS. Yasukawa、 "mpls/bgp ipのマルチキャストVPNS」、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026] Andersson、L。およびT. Madsen、「プロバイダープロビジョニング仮想プライベートネットワーク（VPN）用語」、RFC 4026、2005年3月。
[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] Yasukawa、S.、Farrel、A.、King、D。、およびT. Nadeau、「ポイントツーマルチポイント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] Morin、T.、ed。、「レイヤー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] Aggarwal、R.、Papadimitriou、D。、およびS. Yasukawa、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルスイッチドパス（LSP）のトラフィックエンジニアリング（RSVP-TE）」、RFC 4875、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.、Wada、Y.、Serbest、Y.、Morin、T。、およびL. Fang、「仮想プライベートLANサービスにおけるマルチキャストサポートの要件」、RFC 5501、2009年3月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、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] Aggarwal、R.、Kamite、Y.、Fang、L。、およびY. Rekhter、「Multicast in VPLS」、2011年7月の進行中。
Contributing Authors
貢献している著者
Vincent Parfait France Telecom - Orange, Orange Business Services
Vincent Parfait France Telecom -Orange、Orange Business Services
EMail: vincent.parfait@orange-ftgroup.com
Luyuan Fang Cisco Systems, Inc.
Luyuan Fang Cisco Systems、Inc。
EMail: lufang@cisco.com
Lei Wang Telenor
レイ・ワン・テレノール
EMail: lei.wang@telenor.com
Yuji Kamite NTT Communications Corporation
Yuji Kamite NTT Communications Corporation
EMail: y.kamite@ntt.com
Shane Amante Level 3 Communications, LLC
Shane Amanteレベル3 Communications、LLC
EMail: shane@level3.net
Authors' Addresses
著者のアドレス
Jean-Louis Le Roux (editor) France Telecom - Orange
Jean -Louis Le Roux（編集者）フランステレコム - オレンジ
EMail: jeanlouis.leroux@orange-ftgroup.com
Thomas Morin (editor) France Telecom - Orange
トーマス・モリン（編集者）フランステレコム - オレンジ
EMail: thomas.morin@orange-ftgroup.com