[要約] RFC 6517は、Layer 3 Multicast BGP/MPLS VPNソリューションにおける必須機能についての要件を定義しています。このRFCの目的は、マルチキャストトラフィックを効率的に配信するためのBGP/MPLS VPNソリューションの設計と実装を促進することです。
Internet Engineering Task Force (IETF) T. Morin, Ed.
Request for Comments: 6517 France Telecom - Orange
Category: Informational B. Niven-Jenkins, Ed.
ISSN: 2070-1721 BT
Y. Kamite
NTT Communications
R. Zhang
Alcatel-Lucent
N. Leymann
Deutsche Telekom
N. Bitar
Verizon
February 2012
Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution
レイヤー3マルチキャストBGP/MPLS VPNソリューションの必須機能
Abstract
概要
More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks.
レイヤー3 BGP/MPLS VPNのマルチキャストをサポートするメカニズムのセットがさらに定義されています。これらは、オプションのビルディングブロックとして定義するドキュメントに表示されます。
To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option.
実装間で相互運用性を有効にするために、このドキュメントでは、マルチキャストBGP/MPLS VPN実装に必須と見なされる機能のサブセットを定義します。これにより、実装者と展開者が、各オプションでどのL3VPNマルチキャスト要件が最も満たされるかを理解するのに役立ちます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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/rfc6517.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6517で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Examining Alternative Mechanisms for MVPN Functions . . . . . 4
3.1. MVPN Auto-Discovery . . . . . . . . . . . . . . . . . . . 4
3.2. S-PMSI Signaling . . . . . . . . . . . . . . . . . . . . . 5
3.3. PE-PE Exchange of C-Multicast Routing . . . . . . . . . . 7
3.3.1. PE-PE C-Multicast Routing Scalability . . . . . . . . 7
3.3.2. PE-CE Multicast Routing Exchange Scalability . . . . . 10
3.3.3. Scalability of P Routers . . . . . . . . . . . . . . . 10
3.3.4. Impact of C-Multicast Routing on Inter-AS Deployments 10
3.3.5. Security and Robustness . . . . . . . . . . . . . . . 11
3.3.6. C-Multicast VPN Join Latency . . . . . . . . . . . . . 12
3.3.7. Conclusion on C-Multicast Routing . . . . . . . . . . 14
3.4. Encapsulation Techniques for P-Multicast Trees . . . . . . 15
3.5. Inter-AS Deployments Options . . . . . . . . . . . . . . . 16
3.6. BIDIR-PIM Support . . . . . . . . . . . . . . . . . . . . 19
4. Co-Located RPs . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Avoiding Duplicates . . . . . . . . . . . . . . . . . . . . . 21
6. Existing Deployments . . . . . . . . . . . . . . . . . . . . . 21
7. Summary of Recommendations . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Scalability of C-Multicast Routing Processing Load . 25
A.1. Scalability with an Increased Number of PEs . . . . . . . 26
A.1.1. SSM Scalability . . . . . . . . . . . . . . . . . . . 26
A.1.2. ASM Scalability . . . . . . . . . . . . . . . . . . . 35
A.2. Cost of PEs Leaving and Joining . . . . . . . . . . . . . 37
Appendix B. Switching to S-PMSI . . . . . . . . . . . . . . . . . 40
Specifications for multicast in BGP/MPLS [RFC6513] include multiple alternative mechanisms for some of the required building blocks of the solution. However, they do not identify which of these mechanisms are mandatory to implement in order to ensure interoperability. Not defining a set of mandatory-to-implement mechanisms leads to a situation where implementations may support different subsets of the available optional mechanisms that do not interoperate, which is a problem for the numerous operators having multi-vendor backbones.
BGP/MPLS [RFC6513]のマルチキャストの仕様には、ソリューションの必要なビルディングブロックの一部に複数の代替メカニズムが含まれています。ただし、相互運用性を確保するために、これらのメカニズムのどれが実装する必要があるかを特定しません。一連の必須メカニズムを定義しないと、実装が相互運用しない利用可能なオプションメカニズムのさまざまなサブセットをサポートできる状況につながります。
The aim of this document is to leverage the already expressed requirements [RFC4834] and study the properties of each approach to identify mechanisms that are good candidates for being part of a core set of mandatory mechanisms that can be used to provide a base for interoperable solutions.
このドキュメントの目的は、既に表明された要件[RFC4834]を活用し、各アプローチの特性を研究して、相互運用可能なソリューションのベースを提供するために使用できる一連の必須メカニズムの一部であるための優れた候補であるメカニズムを特定することです。。
This document goes through the different building blocks of the solution and concludes which mechanisms an implementation is required to implement. Section 7 summarizes these requirements.
このドキュメントは、ソリューションのさまざまなビルディングブロックを通過し、実装に必要なメカニズムを結論付けます。セクション7では、これらの要件をまとめます。
Considering the history of the multicast VPN proposals and implementations, it is also useful to discuss how existing deployments of early implementations [RFC6037] [MVPN] can be accommodated and provide suggestions in this respect.
マルチキャストVPN提案と実装の履歴を考慮すると、早期実装の既存の展開[RFC6037] [MVPN]にどのように対応し、この点で提案を提供できるかを議論することも役立ちます。
Please refer to [RFC6513] and [RFC4834]. As a reminder, in Section 3.1 of [RFC6513], the "C-" and "P-" notations are used to disambiguate between the provider scope and the scope of a specific VPN customer; for instance, "C-PIM" designates a PIM protocol instance in a VPN or VRF, while "P-PIM" would designate the instance of PIM eventually deployed by the provider across its core between P and PE routers.
[RFC6513]および[RFC4834]を参照してください。リマインダーとして、[RFC6513]のセクション3.1では、プロバイダーの範囲と特定のVPN顧客の範囲との間を明確にするために「C-」および「P-」表記が使用されます。たとえば、「C-PIM」はVPNまたはVRFでPIMプロトコルインスタンスを指定し、「P-PIM」はPIMのインスタンスをPIMとPEルーターの間でコアにプロバイダーによって展開するインスタンスを指定します。
Other acronyms used in this document include the following:
このドキュメントで使用されている他の頭字語には、以下が含まれます。
o LSP: Label Switched Path
o LSP：ラベルスイッチ付きパス
o P2MP: Point to Multipoint
o P2MP：マルチポイントをポイントします
o MP2MP: Multipoint to Multipoint
o MP2MP：マルチポイントからマルチポイント
o GRE: Generic Routing Encapsulation
o GRE：一般的なルーティングカプセル化
o mLDP: Multicast LDP
o MLDP：マルチキャストLDP
o I-PMSI: Inclusive Provider Multiservice Interface
o I-PMSI：包括的プロバイダーマルチサービスインターフェイス
o MI-PMSI: Multidirectional Inclusive Provider Multiservice Interface
o MI-PMSI：多方向包括的プロバイダーマルチサービスインターフェイス
o S-PMSI: Selective Provider Multiservice Interface
o S-PMSI：選択プロバイダーマルチサービスインターフェイス
o SSM: Source-Specific Multicast
o SSM：ソース固有のマルチキャスト
o ASM: Any-Source Multicast
o ASM：任意のソースマルチキャスト
o PIM-SM: PIM Sparse Mode
o PIM-SM：PIMスパースモード
o PIM-SSM: PIM Sparse Mode in SSM Mode
o PIM-SSM：SSMモードのPIMスパースモード
o BIDIR-PIM: Bidirectional PIM
o Bidir-Pim：双方向PIM
o AS: Autonomous System
o AS：自律システム
o ASBR: Autonomous System Border Router
o ASBR：自律システムボーダールーター
o VRF: VPN Routing and Forwarding
o VRF：VPNルーティングと転送
o PE: Provider Edge
o PE：プロバイダーエッジ
o CE: Customer Edge
o CE：顧客のエッジ
o RPA: Rendezvous Point Address
o RPA：ランデブーポイントアドレス
o RPL: Rendezvous Point Link
o RPL：Rendezvous Pointリンク
Additionally, 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].
さらに、キーワードは「必須」、「必要」、「必須」、「「shall」、「shall」、「suld」、 "nove"、 "becommended"、 "may"、および "optional"文書は、[RFC2119]で説明されているように解釈されます。
The current solution document [RFC6513] proposes two different mechanisms for Multicast VPN (MVPN) auto-discovery:
現在のソリューションドキュメント[RFC6513]は、マルチキャストVPN（MVPN）自動指定の2つの異なるメカニズムを提案しています。
1. BGP-based auto-discovery
1. BGPベースの自動ディスコーブリー
2. "PIM/shared P-tunnel": discovery done through the exchange of PIM Hellos by C-PIM instances, across an MI-PMSI implemented with one shared P-tunnel per VPN (using ASM or MP2MP LDP)
2. 「PIM/共有Pトンネル」：VPNごとに1つの共有Pトンネルで実装されたMi-PMSI（ASMまたはMP2MP LDPを使用）で実装されたMi-PMSIを介して、PIM Hellosの交換を通じて行われた発見
Both solutions address Section 5.2.10 of [RFC4834], which states that "the operation of a multicast VPN solution SHALL be as light as possible, and providing automatic configuration and discovery SHOULD be a priority when designing a multicast VPN solution. Particularly, the operational burden of setting up multicast on a PE or for a VR/ VRF SHOULD be as low as possible".
両方のソリューションは[RFC4834]のセクション5.2.10に対応しています。これは、「マルチキャストVPNソリューションの動作は可能な限り軽量であり、自動構成と発見を提供することを優先事項とする必要があります。PEまたはVR/ VRFのマルチキャストをセットアップするという運用上の負担は、可能な限り低くする必要があります。」
The key consideration is that PIM-based discovery is only applicable to deployments using a shared P-tunnel to instantiate an MI-PMSI (it is not applicable if only P2P, PIM-SSM, and P2MP LDP/RSVP-TE P-tunnels are used, because contrary to ASM and MP2MP LDP, building these types of P-tunnels cannot happen before the auto-discovery has been done). In contrast, the BGP-based auto-discovery does not place any constraint on the type of P-tunnel that would have to be used. BGP-based auto-discovery is independent of the type of P-tunnel used, thus satisfying the requirement in Section 5.2.4.1 of [RFC4834] that "a multicast VPN solution SHOULD be designed so that control and forwarding planes are not interdependent".
重要な考慮事項は、PIMベースの発見が共有P-Tunnelを使用してMi-PMSIをインスタンス化するために展開にのみ適用できることです（P2P、PIM-SSM、P2MP LDP/RSVP-TE P-Tunnelsのみが適用できません。ASMおよびMP2MP LDPに反して使用されるため、自動発見が行われる前に、これらのタイプのPタンネルを構築することはできません）。対照的に、BGPベースの自動発見は、使用する必要があるPトンネルのタイプに制約を課しません。BGPベースの自動ディスコービリは、使用されるPトンネルのタイプとは無関係であるため、[RFC4834]のセクション5.2.4.1の要件を満たしています。
Additionally, it is to be noted that a number of service providers have chosen to use SSM-based P-tunnels for the default multicast distribution trees within their current deployments, therefore relying already on some BGP-based auto-discovery.
さらに、多くのサービスプロバイダーが、現在の展開内のデフォルトのマルチキャスト配布ツリーにSSMベースのPタンネルを使用することを選択していることに注意する必要があります。
Moreover, when shared P-tunnels are used, the use of BGP auto-discovery would allow inconsistencies in the addresses/identifiers used for the shared P-tunnel to be detected (e.g., the same shared P-tunnel identifier being used for different VPNs with distinct BGP route targets). This is particularly attractive in the context of inter-AS VPNs where the impact of any misconfiguration could be magnified and where a single service provider may not operate all the ASes. Note that this technique to detect some misconfiguration cases may not be usable during a transition period from a shared-P-tunnel auto-discovery to a BGP-based auto-discovery.
さらに、共有P-Tunnelsを使用すると、BGPの自動ディスコービリを使用すると、共有Pトンネルが検出される住所/識別子の不一致が可能になります（例えば、異なるVPNに使用されている同じ共有Pトンネル識別子が使用されます。異なるBGPルートターゲットを使用）。これは、誤った構成の影響を拡大できるVPNとの間で特に魅力的であり、単一のサービスプロバイダーがすべてのASEを操作しない場合があります。いくつかの誤解性のケースを検出するこの手法は、共有Pトンネルの自動指示からBGPベースの自動配記までの移行期間中は使用できない可能性があることに注意してください。
Thus, the recommendation is that implementation of the BGP-based auto-discovery is mandated and should be supported by all MVPN implementations.
したがって、推奨事項は、BGPベースの自動配信の実装が義務付けられており、すべてのMVPN実装によってサポートされるべきであることです。
The current solution document [RFC6513] proposes two mechanisms for signaling that multicast flows will be switched to a Selective PMSI (S-PMSI):
現在のソリューションドキュメント[RFC6513]は、マルチキャストフローが選択的PMSI（S-PMSI）に切り替えることを示す2つのメカニズムを提案しています。
1. a UDP-based TLV protocol specifically for S-PMSI signaling (described in Section 7.4.2)
1. S-PMSIシグナル伝達専用のUDPベースのTLVプロトコル（セクション7.4.2で説明）
2. a BGP-based mechanism for S-PMSI signaling (described in Section 7.4.1)
2. S-PMSIシグナル伝達のBGPベースのメカニズム（セクション7.4.1で説明）
Section 5.2.10 of [RFC4834] states that "as far as possible, the design of a solution SHOULD carefully consider the number of protocols within the core network: if any additional protocols are introduced compared with the unicast VPN service, the balance between their advantage and operational burden SHOULD be examined thoroughly". The UDP-based mechanism would be an additional protocol in the MVPN stack, which isn't the case for the BGP-based S-PMSI switching signaling, since (a) BGP is identified as a requirement for auto-discovery and (b) the BGP-based S-PMSI switching signaling procedures are very similar to the auto-discovery procedures.
[RFC4834]のセクション5.2.10は、「可能な限り、ソリューションの設計では、コアネットワーク内のプロトコルの数を慎重に考慮する必要があります。ユニキャストVPNサービスと比較して追加のプロトコルが導入されている場合、バランスのバランス利点と運用上の負担は徹底的に検討する必要があります」。UDPベースのメカニズムは、MVPNスタックの追加プロトコルとなります。これは、BGPベースのS-PMSIスイッチングシグナル伝達には当てはまりません。BGPベースのS-PMSIスイッチングシグナル伝達手順は、自動発見手順に非常に似ています。
Furthermore, the UDP-based S-PMSI switching signaling mechanism requires an MI-PMSI, while the BGP-based protocol does not. In practice, this mean that with the UDP-based protocol, a PE will have to join to all P-tunnels of all PEs in an MVPN, while in the alternative where BGP-based S-PMSI switching signaling is used, it could delay joining a P-tunnel rooted at a PE until traffic from that PE is needed, thus reducing the amount of state maintained on P routers.
さらに、UDPベースのS-PMSIスイッチングシグナル伝達メカニズムにはMi-PMSIが必要ですが、BGPベースのプロトコルは必要ありません。実際には、これはUDPベースのプロトコルでは、PEがMVPNのすべてのPEのすべてのp-tunnelに結合する必要があることを意味しますが、BGPベースのS-PMSIスイッチングシグナルを使用する代替案では、遅延する可能性があります。PEに根ざしたPトンネルを結合すると、そのPEからのトラフィックが必要になるまで、Pルーターに維持される状態の量が減少します。
S-PMSI switching signaling approaches can also be compared in an inter-AS context (see Section 3.5). The proposed BGP-based approach for S-PMSI switching signaling provides a good fit with both the segmented and non-segmented inter-AS approaches (see Section 3.5). By contrast, while the UDP-based approach for S-PMSI switching signaling appears to be usable with segmented inter-AS tunnels, key advantages of the segmented approach are lost:
S-PMSIスイッチングシグナル伝達アプローチは、AS間コンテキストでも比較できます（セクション3.5を参照）。S-PMSIスイッチングシグナル伝達のための提案されたBGPベースのアプローチは、セグメント化されたおよび非セグメント化されていないASアプローチの両方に適しています（セクション3.5を参照）。対照的に、S-PMSIスイッチング信号のUDPベースのアプローチは、セグメント化されたトンネルで使用可能であると思われますが、セグメント化されたアプローチの重要な利点は失われます。
o ASes are no longer independent in their ability to choose when S-PMSIs tunnels will be triggered in their AS (and thus control the amount of state created on their P routers).
o ASEは、S-PMSISトンネルがASでトリガーされる時期を選択する能力においてもはや独立していません（したがって、Pルーターで作成された状態の量を制御します）。
o ASes are no longer independent in their ability to choose the tunneling technique for the P-tunnels used for an S-PMSI.
o ASEは、S-PMSIに使用されるPトゥンネルのトンネル技術を選択する能力においてもはや独立していません。
o In an inter-AS option B context, an isolation of ASes is obtained as PEs in one AS don't have (direct) exchange of routing information with PEs of other ASes. This property is not preserved if UDP-based S-PMSI switching signaling is used. By contrast, BGP-based C-multicast switching signaling does preserve this property.
o AS Inter-AS Option Bコンテキストでは、ASEの分離は、他のASEのPEとルーティング情報を（直接）交換しないように、PESとしてPESとして取得されます。UDPベースのS-PMSIスイッチングシグナリングが使用されている場合、このプロパティは保存されません。対照的に、BGPベースのC-Multicastスイッチングシグナルはこのプロパティを保持します。
Given all the above, it is the recommendation of the authors that BGP is the preferred solution for S-PMSI switching signaling and should be supported by all implementations.
上記のすべてを考えると、BGPがS-PMSIスイッチングシグナリングに好ましいソリューションであり、すべての実装によってサポートされるべきであることが著者の推奨です。
If nothing prevents a fast-paced creation of S-PMSI, then S-PMSI switching signaling with BGP would possibly impact the route reflectors (RRs) used for MVPN routes. However, such a fast-paced behavior would have an impact on P and PE routers resulting from S-PMSI tunnels signaling, which will be the same independent of the S-PMSI signaling approach that is used and which is certainly best to avoid by setting up proper mechanisms.
S-PMSIのペースが速い作成を防ぐと、BGPを使用したS-PMSIスイッチングシグナル伝達は、MVPNルートに使用されるルートリフレクター（RRS）に影響を与える可能性があります。ただし、このようなペースの速い動作は、S-PMSIトンネルシグナル伝達に起因するPおよびPEルーターに影響を与えます。これは、使用されているS-PMSIシグナル伝達アプローチとは独立しており、設定して避けるのが最善です。適切なメカニズム。
The UDP-based S-PMSI switching signaling protocol can also be considered, as an option, given that this protocol has been in deployment for some time. Implementations supporting both protocols would be expected to provide a per-VRF (VPN Routing and Forwarding) configuration knob to allow an implementation to use the UDP-based TLV protocol for S-PMSI switching signaling for specific VRFs in order to support the co-existence of both protocols (for example, during migration scenarios). Apart from such migration-facilitating mechanisms, the authors specifically do not recommend extending the already proposed UDP-based TLV protocol to new types of P-tunnels.
UDPベースのS-PMSIスイッチングシグナル伝達プロトコルは、このプロトコルがしばらく展開されていることを考えると、オプションとして考慮することもできます。両方のプロトコルをサポートする実装は、PER-VRF（VPNルーティングと転送）構成ノブを提供して、共存をサポートするために特定のVRFのS-PMSIスイッチングシグナルに実装を使用できるようにすることが期待されます。両方のプロトコルの（たとえば、移行シナリオ中）。このような移動促進メカニズムとは別に、著者は、すでに提案されているUDPベースのTLVプロトコルを新しいタイプのPタンネルに拡張することを特に推奨していません。
The current solution document [RFC6513] proposes multiple mechanisms for PE-PE exchange of customer multicast routing information (C-multicast routing):
現在のソリューションドキュメント[RFC6513]は、顧客マルチキャストルーティング情報のPE-PE交換（C-Multicastルーティング）の複数のメカニズムを提案しています。
1. Full per-MVPN PIM peering across an MI-PMSI (described in Section 3.4.1.1)
1. Mi-PMSIを横切る完全なMVPN PIM PIM（セクション3.4.1.1で説明）
2. Lightweight PIM peering across an MI-PMSI (described in Section 3.4.1.2)
2. Mi-PMSIを横切る軽量ピム（セクション3.4.1.2で説明）
3. The unicasting of PIM C-Join/Prune messages (described in Section 3.4.1.3)
3. PIM C-JOIN/PRUNEメッセージの単キャスト（セクション3.4.1.3で説明）
4. The use of BGP for carrying C-multicast routing (described in Section 3.4.2)
4. C-Multicastルーティングを運ぶためのBGPの使用（セクション3.4.2で説明）
Scalability being one of the core requirements for multicast VPN, it is useful to compare the proposed C-multicast routing mechanisms from this perspective: Section 4.2.4 of [RFC4834] recommends that "a multicast VPN solution SHOULD support several hundreds of PEs per multicast VPN, and MAY usefully scale up to thousands" and Section 4.2.5 states that "a solution SHOULD scale up to thousands of PEs having multicast service enabled".
スケーラビリティはマルチキャストVPNのコア要件の1つであるため、この観点から提案されているCマルチキャストルーティングメカニズムを比較すると便利です。VPN、および数千人までの拡張する可能性があります」とセクション4.2.5は、「ソリューションはマルチキャストサービスを有効にしている数千のPEまでスケールアップする必要がある」と述べています。
Scalability with an increased number of VPNs per PE, or with an increased amount of multicast state per VPN, are also important but are not focused on in this section since we didn't identify differences between the various approaches for these matters: all others things equal, the load on PE due to C-multicast routing increases roughly linearly with the number of VPNs per PE and with the amount of multicast state per VPN.
PEあたりのVPNの数が増加したり、VPNあたりのマルチキャスト状態の量が増加したりすると、スケーラビリティも重要ですが、これらの問題のさまざまなアプローチの違いを特定しなかったため、このセクションでは焦点を当てていません。同等に、C-MulticastルーティングによるPEの負荷は、PEあたりのVPNの数とVPNあたりのマルチキャスト状態の量とほぼ直線的に増加します。
This section presents conclusions related to PE-PE C-multicast routing scalability. Appendix A provides more detailed explanations on the differences in ways PIM-based approaches and the BGP-based approach handle the C-multicast routing load, along with quantified evaluations of the amount of state and messages with the different approaches. Many points made in this section are detailed in Appendix A.1.
このセクションでは、PE-PE C-Multicastルーティングのスケーラビリティに関連する結論を示します。付録Aでは、PIMベースのアプローチとBGPベースのアプローチの違いについて、C-Multicast Routing Loadを処理し、状態の量と異なるアプローチを持つメッセージの定量化された評価について、より詳細な説明を提供します。このセクションで作成された多くのポイントについては、付録A.1で詳しく説明しています。
At high scales of multicast deployment, the first and third mechanisms require the PEs to maintain a large number of PIM adjacencies with other PEs of the same multicast VPN (which implies the regular exchange of PIM Hellos with each other) and to periodically refresh C-Join/Prune states, resulting in an increased processing cost when the number of PEs increases (as detailed in Appendix A.1). The second approach is less subject to this, and the fourth approach is not subject to this.
マルチキャスト展開の高度なスケールでは、最初と3番目のメカニズムでは、同じマルチキャストVPNの他のPEと多数のPIM隣接を維持する必要があります（これは、PIM Hellosの定期的な交換を互いに意味します）。状態に結合/プルン状態になり、PESの数が増加すると処理コストが増加します（付録A.1で詳述されています）。2番目のアプローチはこれの対象ではなく、4番目のアプローチはこれの影響を受けません。
The third mechanism would reduce the amount of C-Join/Prune processing for a given multicast flow for PEs that are not the upstream neighbor for this flow but would require "explicit tracking" state to be maintained by the upstream PE. It also isn't compatible with the "Join suppression" mechanism. A possible way to reduce the amount of signaling with this approach would be the use of a PIM refresh-reduction mechanism. Such a mechanism, based on TCP, is being specified by the PIM IETF Working Group ([PIM-PORT]); its use in a multicast VPN context is not described in [RFC6513], but it is expected that this approach will provide a scalability similar to the BGP-based approach without RRs.
3番目のメカニズムは、このフローの上流隣接ではないが、上流のPEによって「明示的な追跡」状態を維持する必要があるPESの特定のマルチキャストフローのC結合/プルーン処理の量を減らします。また、「抑制」メカニズムと互換性がありません。このアプローチでシグナリングの量を減らす方法は、PIMリフレッシュ削減メカニズムの使用です。TCPに基づくこのようなメカニズムは、PIM IETFワーキンググループ（[PIM-Port]）によって指定されています。マルチキャストVPNコンテキストでの使用は[RFC6513]では説明されていませんが、このアプローチはRRSのないBGPベースのアプローチと同様のスケーラビリティを提供すると予想されます。
The second mechanism would operate in a similar manner to full per-MVPN PIM peering except that PIM Hello messages are not transmitted and PIM C-Join/Prune refresh-reduction would be used, thereby improving scalability, but this approach has yet to be fully described. In any case, it seems that it only improves one thing among the things that will impact scalability when the number of PEs increases.
2番目のメカニズムは、PIM Helloメッセージが送信されず、PIM C-Join/Pruneリフレッシュ削減を使用して、スケーラビリティを改善することを除いて、完全なMVPN PIM Peeringと同様の方法で動作しますが、このアプローチはまだ完全ではありません。説明された。いずれにせよ、PESの数が増加するとスケーラビリティに影響を与えるものの中で、それは1つのことのみを改善するようです。
The first and second mechanisms can leverage the "Join suppression" behavior and thus improve the processing burden of an upstream PE, sparing the processing of a Join refresh message for each remote PE
最初のメカニズムと2番目のメカニズムは、「抑制」動作を活用して、上流のPEの処理負担を改善し、各リモートPEの結合リフレッシュメッセージの処理を節約することができます
joined to a multicast stream. This improvement requires all PEs of a multicast VPN to process all PIM Join and Prune messages sent by any other PE participating in the same multicast VPN whether they are the upstream PE or not.
マルチキャストストリームに参加しました。この改善には、マルチキャストVPNのすべてのPESが必要であり、同じマルチキャストVPNに参加している他のPEから送信されたすべてのPIM結合メッセージを処理し、上流のPEであるかどうかにかかわらず、プルーンメッセージをプルンする必要があります。
The fourth mechanism (the use of BGP for carrying C-multicast routing) would have a comparable drawback of requiring all PEs to process a BGP C-multicast route only interesting a specific upstream PE. For this reason, Section 16 of [RFC6514] recommends the use of the Route Target constrained BGP distribution [RFC4684] mechanisms, which eliminate this drawback by having only the interested upstream PE receive a BGP C-multicast route. Specifically, when Route Target constrained BGP distribution is used, the fourth mechanism reduces the total amount of the C-multicast routing processing load put on the PEs by avoiding any processing of customer multicast routing information on the "unrelated" PEs that are neither the joining PE nor the upstream PE.
4番目のメカニズム（C-Multicastルーティングを運ぶためのBGPの使用）には、すべてのPEがBGP C-Multicastルートの処理に特定のアップストリームPEのみを処理することを要求するという同等の欠点があります。このため、[RFC6514]のセクション16では、Routeターゲット制限BGP分布[RFC4684]メカニズムの使用を推奨しています。具体的には、ルートターゲットが制約されたBGP分布を使用すると、4番目のメカニズムは、顧客のマルチキャストルーティング情報の処理を「結合されていない」PESではなく、接合ではないC-Multicastルーティング処理負荷の総量をPESに削減します。PEも上流のPEも。
Moreover, the fourth mechanism further reduces the total amount of message processing load by avoiding the use of periodic refreshes and by inheriting BGP features that are expected to improve scalability (for instance, providing a means to offload some of the processing burden associated with customer multicast routing onto one or many BGP route reflectors). The advantages of the fourth mechanism come at a cost of maintaining an amount of state linear with the number of PEs joined to a stream. However, the use of route reflectors allows this cost to be spread among multiple route reflectors, thus eliminating the need for a single route reflector to maintain all this state.
さらに、4番目のメカニズムは、定期的な更新の使用を回避し、スケーラビリティを改善すると予想されるBGP機能を継承することにより、メッセージ処理負荷の総量をさらに減らします（たとえば、顧客マルチリキャストに関連する処理負担の一部をオフロードする手段を提供します。1つまたは多くのBGPルートリフレクターへのルーティング）。4番目のメカニズムの利点は、PESの数がストリームに結合された状態の量を維持するためのコストでもたらされます。ただし、ルートリフレクターを使用すると、このコストを複数のルートリフレクターに広めることができ、この状態をすべて維持するための単一のルートリフレクターの必要性が排除されます。
However, the fourth mechanism is specific in that it offers the possibility of offloading customer multicast routing processing onto one or more BGP route reflector(s). When this is used, there is a drawback of increasing the processing load placed on the route reflector infrastructure. In the higher scale scenarios, it may be required to adapt the route reflector infrastructure to the MVPN routing load by using, for example:
ただし、4番目のメカニズムは、顧客マルチキャストルーティング処理を1つ以上のBGPルートリフレクターにオフロードする可能性を提供するという点で特異的です。これを使用すると、ルートリフレクターインフラストラクチャに配置された処理荷重を増やすという欠点があります。高度なシナリオでは、例えば、以下を使用して、ルートリフレクターインフラストラクチャをMVPNルーティング負荷に適応させる必要がある場合があります。
o a separation of resources for unicast and multicast VPN routing: using dedicated MVPN route reflector(s) (or using dedicated MVPN BGP sessions or dedicated MVPN BGP instances), and
o ユニキャストおよびマルチキャストVPNルーティング用のリソースの分離：専用のMVPNルートリフレクターを使用（または専用のMVPN BGPセッションまたは専用のMVPN BGPインスタンスを使用）、および
o the deployment of additional route reflector resources, for example, increasing the processing resources on existing route reflectors or deployment of additional route reflectors.
o たとえば、追加のルートリフレクターリソースの展開により、既存のルートリフレクターの処理リソースが増加したり、追加のルートリフレクターの展開が増加したりします。
The most straightforward approach is to consider the introduction of route reflectors dedicated to the MVPN service and dimension them
最も簡単なアプローチは、MVPNサービスに特化したルートリフレクターの導入を検討し、それらを寸法化することです。
according to the need of that service (but doing so is not required and is left as an operator engineering decision).
そのサービスの必要性に応じて（ただし、そうすることは必須ではなく、オペレーターエンジニアリングの決定として残されています）。
The overhead associated with the PE-CE exchange of C-multicast routing is independent of the choice of the mechanism used for the PE-PE C-multicast routing. Therefore, the impact of the PE-CE C-multicast routing overhead on the overall system scalability is independent of the protocol used for PE-PE signaling and is therefore not relevant when comparing the different approaches proposed for the PE-PE C-multicast routing. This is true even if in some operational contexts, the PE-CE C-multicast routing overhead is a significant factor in the overall system overhead.
C-MulticastルーティングのPE-CE交換に関連するオーバーヘッドは、PE-PE C-Multicastルーティングに使用されるメカニズムの選択とは無関係です。したがって、システム全体のスケーラビリティに対するPE-CE C-Multicastルーティングオーバーヘッドの影響は、PE-PEシグナル伝達に使用されるプロトコルとは無関係であるため、PE-PE C-Multicastルーティングに提案されているさまざまなアプローチを比較すると関連性がありません。。これは、いくつかの運用コンテキストでも、PE-CE-CE-Multicastルーティングオーバーヘッドがシステム全体の重要な要因である場合でも当てはまります。
The first and second mechanisms are restricted to use within multicast VPNs that use an MI-PMSI, thereby necessitating:
最初のメカニズムと2番目のメカニズムは、Mi-PMSIを使用するマルチキャストVPN内での使用が制限されているため、次のことが必要です。
o the use of a P-tunnel technique that allows shared P-tunnels (for example, PIM-SM in ASM mode or MP2MP LDP), or
o 共有P-Tunnels（たとえば、ASMモードまたはMP2MP LDPのPIM-SM）を許可するPトンネル技術の使用、または
o the use of one P-tunnel per PE per VPN, even for PEs that do not have sources in their directly attached sites for that VPN.
o そのVPNの直接接続されたサイトにソースがないPESであっても、VPNあたりのPEごとに1つのPトンネルの使用。
By comparison, the fourth mechanism doesn't impose either of these restrictions and, when P2MP P-tunnels are used, only necessitates the use of one P-tunnel per VPN per PE attached to a site with a multicast source or Rendezvous Point (RP) (or with a candidate Bootstrap Router (BSR), if BSR is used).
比較すると、4番目のメカニズムはこれらの制限のいずれかを課さず、P2MP P-Tunnelsを使用する場合、マルチキャストソースまたはランダブーポイントを備えたサイトに接続されたPEごとに1つのPトンネルを使用する必要があります（rp）（またはBSRを使用する場合は、候補Bootstrapルーター（BSR）を使用）。
In cases where there are fewer PEs connected with sources than the total number of PEs, the fourth mechanism improves the amount of state maintained by P routers compared to the amount required to build an MI-PMSI with P2MP P-tunnels. Such cases are expected to be frequent for multicast VPN deployments (see Section 4.2.4.1 of [RFC4834]).
ソースに関連するPESがPESの総数よりも少ない場合、4番目のメカニズムは、P2MP P-Tunnelを使用してMi-PMSIを構築するために必要な量と比較して、Pルーターによって維持される状態の量を改善します。このようなケースは、マルチキャストVPN展開で頻繁に発生すると予想されます（[RFC4834]のセクション4.2.4.1を参照）。
Co-existence with unicast inter-AS VPN options, and an equal level of security for multicast and unicast including in an inter-AS context, are specifically mentioned in Sections 5.2.6 and 5.2.8 of [RFC4834].
Unicast Inter-AS VPNオプションとの共存と、[RFC4834]のセクション5.2.6および5.2.8で特別に言及されています。
In an inter-AS option B context, an isolation of ASes is obtained as PEs in one AS don't have (direct) exchange of routing information with PEs of other ASes. This property is not preserved if PIM-based
AS Inter-AS Option Bコンテキストでは、ASEの分離は、他のASEのPEとルーティング情報を（直接）交換しないように、PESとしてPESとして取得されます。このプロパティは、PIMベースの場合は保存されません
PE-PE C-multicast routing is used. By contrast, the fourth option (BGP-based C-multicast routing) does preserve this property.
PE-PE C-Multicastルーティングが使用されます。対照的に、4番目のオプション（BGPベースのC-Multicastルーティング）はこのプロパティを保持します。
Additionally, the authors note that the proposed BGP-based approach for C-multicast routing provides a good fit with both the segmented and non-segmented inter-AS approaches. By contrast, though the PIM-based C-multicast routing is usable with segmented inter-AS tunnels, the inter-AS scalability advantage of the approach is lost, since PEs in an AS will see the C-multicast routing activity of all other PEs of all other ASes.
さらに、著者らは、C-Multicastルーティングのための提案されたBGPベースのアプローチは、セグメント化されたおよび非セグメント化されていないASアプローチの両方に適していることを指摘しています。対照的に、PIMベースのC-Multicastルーティングはセグメント化されたトンネルで使用できますが、他のすべてのPESのCマルチキャストルーティングアクティビティが表示されるため、アプローチのスケーラビリティの利点は失われます。他のすべてのASEの。
BGP supports MD5 authentication of its peers for additional security, thereby possibly directly benefiting multicast VPN customer multicast routing, whether for intra-AS or inter-AS communications. By contrast, with a PIM-based approach, no mechanism providing a comparable level of security to authenticate communications between remote PEs has yet been fully described [RFC5796] and, in any case, would require significant additional operations for the provider to be usable in a multicast VPN context.
BGPは、追加のセキュリティのためにピアのMD5認証をサポートしているため、ASINTRA-ASまたはAS Inter-AS Communicationsであろうと、マルチキャストVPN顧客マルチキャストルーティングに直接利益をもたらす可能性があります。対照的に、PIMベースのアプローチでは、リモートPE間で通信を認証するための同等のレベルのセキュリティを提供するメカニズムはまだ完全に記述されていない[RFC5796]、そしていずれにせよ、プロバイダーが使用可能になるためには重要な追加操作が必要になるでしょう。マルチキャストVPNコンテキスト。
The robustness of the infrastructure, especially the existing infrastructure providing unicast VPN connectivity, is key. The C-multicast routing function, especially under load, will compete with the unicast routing infrastructure. With the PIM-based approaches, the unicast and multicast VPN routing functions are expected to only compete in the PE, for control plane processing resources. In the case of the BGP-based approach, they will compete on the PE for processing resources and in the route reflectors (supposing they are used for MVPN routing). In both cases, mechanisms will be required to arbitrate resources (e.g., processing priorities). In the case of PIM-based procedures, this arbitration occurs between the different control plane routing instances in the PE. In the case of the BGP-based approach, this is likely to require using distinct BGP sessions for multicast and unicast (e.g., through the use of dedicated MVPN BGP route reflectors or the use of a distinct session with an existing route reflector).
インフラストラクチャの堅牢性、特にユニキャストVPN接続を提供する既存のインフラストラクチャが重要です。 C-Multicastルーティング関数は、特に負荷がかかっているため、ユニキャストルーティングインフラストラクチャと競合します。 PIMベースのアプローチにより、ユニキャストとマルチキャストのVPNルーティング関数は、制御プレーン処理リソースのためにPEでのみ競合すると予想されます。 BGPベースのアプローチの場合、彼らはPEで処理リソースとルートリフレクター（MVPNルーティングに使用されていると仮定）で競合します。どちらの場合も、リソースを仲裁するためにメカニズムが必要になります（例：処理優先順位）。 PIMベースの手順の場合、この仲裁は、PEの異なる制御プレーンルーティングインスタンス間で発生します。 BGPベースのアプローチの場合、これはマルチキャストとユニキャストに異なるBGPセッションを使用する必要がある可能性があります（たとえば、専用のMVPN BGPルートリフレクターの使用または既存のルートリフレクターとの異なるセッションの使用）。
Multicast routing is dynamic by nature, and multicast VPN routing has to follow the VPN customers' multicast routing events. The different approaches can be compared on how they are expected to behave in scenarios where multicast routing in the VPNs is subject to an intense activity. Scalability of each approach under such a load is detailed in Appendix A.2, and the fourth approach (BGP-based) used in conjunction with the Route Target Constraint mechanisms [RFC4684] is the only one having a cost for join/leave operations independent of the number of PEs in the VPN (with one exception detailed in
マルチキャストルーティングは本質的に動的であり、マルチキャストVPNルーティングはVPN顧客のマルチキャストルーティングイベントに従う必要があります。さまざまなアプローチを、VPNのマルチキャストルーティングが激しいアクティビティの影響を受けるシナリオで動作すると予想される方法について比較できます。このような負荷の下での各アプローチのスケーラビリティについては、付録A.2に詳述されており、ルートターゲット制約メカニズム[RFC4684]と併用して使用される4番目のアプローチ（BGPベース）は、Join/Leave Operationsのコストを持つ唯一のものです。VPN内のPES数の（1つの例外が詳述されています
Appendix A.2) and state maintenance not concentrated on the upstream PE.
付録A.2）および州のメンテナンスは、上流のPEに集中していません。
On the other hand, while the BGP-based approach is likely to suffer a slowdown under a load that is greater than the available processing resources (because of possibly congested TCP sockets), the PIM-based approaches would react to such a load by dropping messages, with failure-recovery obtained through message refreshes. Thus, the BGP-based approach could result in a degradation of join/leave latency performance typically spread evenly across all multicast streams being joined in that period, while the PIM-based approach could result in increased join/leave latency, for some random streams, by a multiple of the time between refreshes (e.g., tens of seconds), and possibly in some states, the adjacency may timeout, resulting in disruption of multicast streams.
一方、BGPベースのアプローチは、利用可能な処理リソースよりも大きい負荷の下で減速に苦しむ可能性がありますが（TCPソケットが混雑している可能性があるため）、PIMベースのアプローチは、ドロップすることでそのような負荷に反応します。メッセージのリフレッシュを介して取得された失敗回復を伴うメッセージ。したがって、BGPベースのアプローチは、その期間に結合されているすべてのマルチキャストストリームに通常、結合/休暇のレイテンシーパフォーマンスの劣化をもたらす可能性がありますが、PIMベースのアプローチは、いくつかのランダムストリームの接合/休暇のレイテンシの増加につながる可能性があります。、更新の間の時間（例：数十秒）、そしておそらく一部の州では、隣接がタイムアウトする可能性があり、マルチキャストストリームが混乱する可能性があります。
The behavior of the PIM-based approach under such a load is also harder to predict, given that the performance of the "Join suppression" mechanism (an important mechanism for this approach to scale) will itself be impeded by delays in Join processing. For these reasons, the BGP-based approach would be able to provide a smoother degradation and more predictable behavior under a highly dynamic load.
このような負荷の下でのPIMベースのアプローチの動作は、「結合抑制」メカニズム（このスケールへのアプローチの重要なメカニズム）のパフォーマンス自体が、結合処理の遅延によって妨げられることを考えると、予測するのも困難です。これらの理由から、BGPベースのアプローチは、非常に動的な負荷の下でよりスムーズな劣化とより予測可能な動作を提供することができます。
In fact, both an "evenly spread degradation" and an "unevenly spread larger degradation" can be problematic, and what seems important is the ability for the VPN backbone operator to (a) limit the amount of multicast routing activity that can be triggered by a multicast VPN customer and (b) provide the best possible independence between distinct VPNs. It seems that both of these can be addressed through local implementation improvements and that both the BGP-based and PIM-based approaches could be engineered to provide (a) and (b). It can be noted though that the BGP approach proposes ways to dampen C-multicast route withdrawals and/or advertisements and thus already describes a way to provide (a), while nothing comparable has yet been described for the PIM-based approaches (even though it doesn't appear difficult). The PIM-based approaches rely on a per-VPN data plane to carry the MVPN control plane and thus may benefit from this first level of separation to solve (b).
実際、「均等に広がる劣化」と「不均一に広がる大きな劣化」の両方が問題になる可能性があります。重要と思われるのは、VPNバックボーン演算子が（a）によって引き起こすことができるマルチキャストルーティングアクティビティの量を制限する能力です。マルチキャストVPN顧客と（b）は、異なるVPN間の可能な限り最高の独立性を提供します。これらは両方ともローカルの実装の改善を通じて対処できるようであり、BGPベースのアプローチとPIMベースのアプローチの両方が（a）および（b）を提供するように設計できるようです。ただし、BGPアプローチはC-Multicastルートの引き出しや広告を減衰させる方法を提案しているため、すでに（A）を提供する方法を説明していますが、PIMベースのアプローチについてはまだ匹敵するものはまだ説明されていません（難しくないようです）。PIMベースのアプローチは、VPNごとのデータプレーンに依存してMVPNコントロールプレーンを運ぶため、この最初のレベルの分離レベルから解決するための恩恵を受ける可能性があります。
Section 5.1.3 of [RFC4834] states that the "group join delay [...] is also considered one important QoS parameter. It is thus RECOMMENDED that a multicast VPN solution be designed appropriately in this regard". In a multicast VPN context, the "group join delay" of interest is the time between a CE sending a PIM Join to its PE and
[RFC4834]のセクション5.1.3は、「グループ結合遅延[...]も1つの重要なQoSパラメーターと見なされると述べています。したがって、この点でマルチキャストVPNソリューションを適切に設計することをお勧めします」。マルチキャストVPNコンテキストでは、関心のある「グループ結合遅延」は、CEがPEにPIM結合を送信するまでの時間と
the first packet of the corresponding multicast stream being received by the CE.
CEが受信する対応するマルチキャストストリームの最初のパケット。
It is to be noted that the C-multicast routing procedures will only impact the group join latency of a said multicast stream for the first receiver that is located across the provider backbone from the multicast source-connected PE (or the first <n> receivers in the specific case where a specific Upstream Multicast Hop selection algorithm is used, which allows <n> distinct PEs to be selected as the Upstream Multicast Hop by distinct downstream PEs).
C-Multicastルーティング手順は、マルチキャストソースに接続されたPE（または最初の<n>レシーバーからプロバイダーバックボーン全体にある最初のレシーバーの上記マルチキャストストリームのグループ結合レイテンシにのみ影響することに注意してください。特定のアップストリームマルチキャストホップ選択アルゴリズムが使用される特定のケースでは、異なる下流のPESによる上流のマルチキャストホップとして<n>異なるPEを選択できます。
The different approaches proposed seem to have different characteristics in how they are expected to impact join latency:
提案されているさまざまなアプローチは、それらが結合レイテンシに影響を与えると予想される方法に異なる特性を持っているようです。
o The PIM-based approaches minimize the number of control plane processing hops between a new receiver-connected PE and the source-connected PE and, being datagram-based, introduce minimal delay, thereby possibly having a join latency as good as possible depending on implementation efficiency.
o PIMベースのアプローチは、新しいレシーバーに接続されたPEとソース接続PEの間のコントロールプレーン処理ホップの数を最小限に抑え、データグラムベースであるため、最小限の遅延を導入し、実装に応じてできるだけ良好な結合レイテンシを持つ可能性があります。効率。
o Under degraded conditions (packet loss, congestion, or high control plane load) the PIM-based approach may impact the latency for a given multicast stream in an all-or-nothing manner: if a C-multicast routing PIM Join packet is lost, latency can reach a high time (a multiple of the periodicity of PIM Join refreshes).
o 劣化した条件（パケット損失、輻輳、または高コントロールプレーンの負荷）では、PIMベースのアプローチは、特定のマルチキャストストリームのレイテンシにオールオアナッシングの方法で影響を与える可能性があります。レイテンシは高い時間に達する可能性があります（PIMの周期性の複数の倍率が再装備）。
o The BGP-based approach uses TCP exchanges, which may introduce an additional delay depending on BGP and TCP implementation but which would typically result, under degraded conditions (such packet loss, congestion, or high control plane load), in a comparably lower increase of latency spread more evenly across the streams.
o BGPベースのアプローチはTCP交換を使用します。これは、BGPとTCPの実装に応じて追加の遅延を導入する可能性がありますが、通常は劣化した条件（パケット損失、輻輳、または高コントロールプレーン負荷）で発生します。レイテンシーは、ストリーム全体により均等に広がります。
o As shown in Appendix A, the BGP-based approach is particular in that it removes load from all the PEs (without putting this load on the upstream PE for a stream); this improvement of background load can bring improved performance when a PE acts as the upstream PE for a stream and thus benefits join latency.
o 付録Aに示すように、BGPベースのアプローチは、すべてのPESから負荷を除去するという点で特別です（この荷重を上流のPEに配置することはありません）。このバックグラウンド負荷の改善は、PEがストリームの上流のPEとして機能すると、パフォーマンスが向上する可能性があり、したがって、利点は遅延になります。
This qualitative comparison of approaches shows that the BGP-based approach is designed for a smoother degradation of latency under degraded conditions such as packet loss, congestion, or high control plane load. On the other hand, the PIM-based approaches seem to structurally be able to reach the shorter "best-case" group join latency (especially compared to deployment of the BGP-based approach where route reflectors are used).
このアプローチの定性的比較は、BGPベースのアプローチが、パケット損失、輻輳、または高コントロールプレーン負荷などの分解条件下での遅延のよりスムーズな分解のために設計されていることを示しています。一方、PIMベースのアプローチは、より短い「ベストケース」グループ結合レイテンシに構造的に到達できるように見えます（特に、ルートリフレクターが使用されるBGPベースのアプローチの展開と比較）。
Doing a quantitative comparison of latencies is not possible without referring to specific implementations and benchmarking procedures and
特定の実装とベンチマーク手順を参照せずに、レイテンシーの定量的な比較を行うことはできません
would possibly expose different conclusions, especially for best-case group join latency for which performance is expected to vary with PIM and BGP implementations. We can also note that improving a BGP implementation for reduced latency of route processing would not only benefit multicast VPN group join latency but the whole BGP-based routing, which means that the need for good BGP/RR performance is not specific to multicast VPN routing.
特に、PIMとBGPの実装によってパフォーマンスが異なると予想されるベストケースグループの結合レイテンシの場合、さまざまな結論を公開する可能性があります。また、ルート処理のレイテンシを減らすためにBGP実装を改善することは、マルチキャストVPNグループがレイテンシを結合するだけでなく、BGPベースのルーティング全体に役立つことに注意することもできます。。
Last, C-multicast join latency will be impacted by the overall load put on the control plane, and the scalability of the C-multicast routing approach is thus to be taken into account. As explained in Section 3.3.1 and Appendix A, the BGP-based approach will provide the best scalability with an increased number of PEs per VPN, thereby benefiting group join latency in such higher-scale scenarios.
最後に、C-Multicastの結合レイテンシは、コントロールプレーンに置かれた全体的な負荷の影響を受け、したがってC-Multicastルーティングアプローチのスケーラビリティを考慮に入れます。セクション3.3.1および付録Aで説明されているように、BGPベースのアプローチは、VPNあたりのPES数が増加して最適なスケーラビリティを提供し、それにより、このような高スケールシナリオでグループに参加するグループに利益をもたらします。
The first and fourth approaches are relevant contenders for C-multicast routing. Comparisons from a theoretical standpoint lead to identification of some advantages as well as possible drawbacks in the fourth approach. Comparisons from a practical standpoint are harder to make: since only reduced deployment and implementation information is available for the fourth approach, advantages would be seen in the first approach that has been applied through multiple deployments and shown to be operationally viable.
最初と4番目のアプローチは、Cマルチキャストルーティングに関連する候補です。理論的観点からの比較は、4番目のアプローチでいくつかの利点と可能な欠点を特定することにつながります。実用的な観点からの比較を行うのは困難です。4番目のアプローチでは、展開と実装情報の削減のみが利用可能であるため、複数の展開を通じて適用され、動作的に実行可能であることが示された最初のアプローチでは利点が見られます。
Moreover, the first mechanism (full per-MVPN PIM peering across an MI-PMSI) is the mechanism used by [RFC6037]; therefore, it is deployed and operating in MVPNs today. The fourth approach may or may not end up being preferred for a said deployment, but because the first approach has been in deployment for some time, the support for this mechanism will in any case be helpful to facilitate an eventual migration from a deployment using mechanism close to the first approach.
さらに、最初のメカニズム（Mi-PMSIを横切る完全なMVPN PIMピム）は[RFC6037]で使用されるメカニズムです。したがって、今日はMVPNSで展開および動作しています。4番目のアプローチは、上記の展開に最終的に優先される場合とそうでない場合がありますが、最初のアプローチはしばらくの間展開中であったため、このメカニズムのサポートは、メカニズムを使用した展開からの最終的な移行を促進するために役立ちます。最初のアプローチに近い。
Consequently, at the present time, implementations are recommended to support both the fourth (BGP-based) and first (full per-MVPN PIM peering) mechanisms. Further experience on deployments of the fourth approach is needed before some best practices can be defined. In the meantime, this recommendation would enable a service provider to choose between the first and the fourth mechanisms, without this choice being constrained by vendor implementation choices. A service provider can also take into account the peculiarities of its own deployment context by pondering the weight of the different factors into account.
したがって、現在、4番目（BGPベース）と最初（完全なMVPN PIMピアリング）メカニズムの両方をサポートするために、実装が推奨されています。いくつかのベストプラクティスを定義する前に、4番目のアプローチの展開に関するさらなる経験が必要です。それまでの間、この推奨事項により、サービスプロバイダーは、ベンダーの実装の選択によって制約されることなく、最初のメカニズムと4番目のメカニズムを選択できます。サービスプロバイダーは、さまざまな要因の重みを考慮することにより、独自の展開コンテキストの特性を考慮することもできます。
In this section, the authors will not make any restricting recommendations since the appropriateness of a specific provider core data plane technology will depend on a large number of factors, for example, the service provider's currently deployed unicast data plane, many of which are service provider specific.
このセクションでは、特定のプロバイダーコアデータプレーンテクノロジーの適切性が多数の要因に依存するため、著者は推奨を制限しません。たとえば、サービスプロバイダーの現在展開されているユニキャストデータプレーンなど、その多くはサービスプロバイダーです。明確な。
However, implementations should not unreasonably restrict the data plane technology that can be used and should not force the use of the same technology for different VPNs attached to a single PE. Initial implementations may only support a reduced set of encapsulation techniques and data plane technologies, but this should not be a limiting factor that hinders future support for other encapsulation techniques, data plane technologies, or interoperability.
ただし、実装は、使用できるデータプレーンテクノロジーを不合理に制限してはならず、単一のPEに接続された異なるVPNに同じテクノロジーの使用を強制すべきではありません。初期実装は、カプセル化技術とデータプレーンテクノロジーの削減されたセットのみをサポートする場合がありますが、これは、他のカプセル化技術、データプレーンテクノロジー、または相互運用性の将来のサポートを妨げる制限要因ではありません。
Section 5.2.4.1 of [RFC4834] states, "In a multicast VPN solution extending a unicast layer 3 PPVPN solution, consistency in the tunneling technology has to be favored: such a solution SHOULD allow the use of the same tunneling technology for multicast as for unicast. Deployment consistency, ease of operation, and potential migrations are the main motivations behind this requirement".
[RFC4834]のセクション5.2.4.1は、「ユニキャスト層3 PPVPNソリューションを拡張するマルチキャストVPNソリューションでは、トンネル技術の一貫性を好む必要があります。ユニキャスト。展開の一貫性、運用の容易さ、および潜在的な移行が、この要件の背後にある主な動機です」。
Current unicast VPN deployments use a variety of LDP, RSVP-TE, and GRE/IP-Multicast for encapsulating customer packets for transport across the provider core of VPN services. In order to allow the same encapsulations to be used for unicast and multicast VPN traffic, it is recommended that multicast VPN standards should recommend that implementations support multicast VPNs and all the P2MP variants of the encapsulations and signaling protocols that they support for unicast and for which some multipoint extension is defined, such as mLDP, P2MP RSVP-TE, and GRE/IP-multicast.
現在のUnicast VPN展開は、VPNサービスのプロバイダーコアを横切るトランスポートのために、顧客パケットをカプセル化するために、さまざまなLDP、RSVP-TE、およびGRE/IP-Multicastを使用しています。ユニキャストおよびマルチキャストVPNトラフィックに同じカプセルを使用できるようにするために、マルチキャストVPN標準は、実装がマルチキャストVPNと、ユニカストをサポートし、ユニカストをサポートするカプセーションおよびシグナルプロトコルのすべてのP2MPバリエーションをサポートすることを推奨することをお勧めします。MLDP、P2MP RSVP-TE、GRE/IP-Multicastなど、いくつかのマルチポイント拡張が定義されています。
All three of the above encapsulation techniques support the building of P2MP multicast P-tunnels. In addition, mLDP and GRE/ IP-ASM-Multicast implementations may also support the building of MP2MP multicast P-tunnels. The use of MP2MP P-tunnels may provide some scaling benefits to the service provider as only a single MP2MP P-tunnel need be deployed per VPN, thus reducing by an order of magnitude the amount of multicast state that needs to be maintained by P routers. This gain in state is at the expense of bandwidth optimization, since sites that do not have multicast receivers for multicast streams sourced behind a said PE group will still receive packets of such streams, leading to non-optimal bandwidth utilization across the VPN core. One thing to consider is that the use of MP2MP multicast P-tunnel will require additional configuration to define the same P-tunnel identifier or multicast ASM group address in all PEs (it has been noted that some auto-configuration could be possible
上記の3つのカプセル化技術はすべて、P2MPマルチキャストPトゥンネルの構築をサポートしています。さらに、MLDPおよびGRE/ IP-ASM-Multicastの実装は、MP2MPマルチキャストPトゥンネルの構築もサポートする場合があります。MP2MP P-Tunnelsを使用すると、VPNごとに単一のMP2MP Pトンネルを展開する必要があるため、サービスプロバイダーにいくつかのスケーリングの利点を提供する可能性があります。。この状態での利益は、帯域幅の最適化を犠牲にします。なぜなら、前述のPEグループの背後にあるマルチキャストストリームのマルチキャストレシーバーを備えていないサイトは、そのようなストリームのパケットを受け取り、VPNコア全体で非最適な帯域幅の利用につながるためです。考慮すべきことの1つは、MP2MPマルチキャストPトンネルを使用すると、すべてのPEで同じPトンネル識別子またはマルチキャストASMグループアドレスを定義するための追加の構成が必要になることです（ある程度の自動構成が可能であることに注意してください。
for MP2MP P-tunnels, but this is not currently supported by the auto-discovery procedures). (It has been noted that C-multicast routing schemes not covered in [RFC6513] could expose different advantages of MP2MP multicast P-tunnels; this is out of the scope of this document.)
MP2MP P-Tunnelsの場合、これは現在、自動発見手順によってサポートされていません）。（[RFC6513]でカバーされていないC-Multicastルーティングスキームは、MP2MPマルチキャストPトゥンネルのさまざまな利点を明らかにする可能性があることに注意しています。これは、このドキュメントの範囲外です。）
MVPN services can also be supported over a unicast VPN core through the use of ingress PE replication whereby the ingress PE replicates any multicast traffic over the P2P tunnels used to support unicast traffic. While this option does not require the service provider to modify their existing P routers (in terms of protocol support) and does not require maintaining multicast-specific state on the P routers in order for the service provider to be able deploy a multicast VPN service, the use of ingress PE replication obviously leads to non-optimal bandwidth utilization, and it is therefore unlikely to be the long-term solution chosen by service providers. However, ingress PE replication may be useful during some migration scenarios or where a service provider considers the level of multicast traffic on their network to be too low to justify deploying multicast-specific support within their VPN core.
MVPNサービスは、イングレスPEレプリケーションを使用することにより、ユニキャストVPNコアでサポートすることもできます。これにより、イングレスPEは、ユニキャストトラフィックをサポートするために使用されるP2Pトンネル上のマルチキャストトラフィックを複製します。このオプションでは、サービスプロバイダーが既存のPルーターを（プロトコルサポートの観点から）変更する必要はありませんが、サービスプロバイダーがマルチキャストVPNサービスを展開できるために、Pルーターにマルチキャスト固有の状態を維持する必要はありません。イングレスPEレプリケーションの使用は、明らかに最適ではない帯域幅の利用につながるため、サービスプロバイダーが選択した長期的なソリューションである可能性は低いです。ただし、イングレスPEレプリケーションは、一部の移行シナリオや、サービスプロバイダーがネットワーク上のマルチキャストトラフィックのレベルを低すぎて、VPNコア内にマルチキャスト固有のサポートを展開することを正当化すると考える場合に役立ちます。
All proposed approaches for control plane and data plane can be used to provide aggregation amongst multicast groups within a VPN and amongst different multicast VPNs, and potentially reduce the amount of state to be maintained by P routers. However, the latter (the aggregation amongst different multicast VPNs) will require support for upstream-assigned labels on the PEs. Support for upstream-assigned labels may require changes to the data plane processing of the PEs, and this should be taken into consideration by service providers considering the use of aggregate PMSI tunnels for the specific platforms that the service provider has deployed.
コントロールプレーンとデータプレーンの提案されたすべてのアプローチを使用して、VPN内およびさまざまなマルチキャストVPN内のマルチキャストグループ間で集約を提供し、Pルーターによって維持される状態の量を潜在的に減らすことができます。ただし、後者（異なるマルチキャストVPNの間の集約）には、PES上の上流で割り当てられたラベルのサポートが必要です。上流で割り当てられたラベルのサポートには、PESのデータプレーン処理の変更が必要になる場合があります。これは、サービスプロバイダーが展開した特定のプラットフォームに合計PMSIトンネルの使用を考慮して、サービスプロバイダーが考慮する必要があります。
There are a number of scenarios that lead to the requirement for inter-AS multicast VPNs, including:
以下を含む、マルチキャスト間VPNをAS Interingの要件につながる多くのシナリオがあります。
1. A service provider may have a large network that it has segmented into a number of ASes.
1. サービスプロバイダーには、多くのASEにセグメント化された大きなネットワークがある場合があります。
2. A service provider's multicast VPN may consist of a number of ASes due to acquisitions and mergers with other service providers.
2. サービスプロバイダーのマルチキャストVPNは、他のサービスプロバイダーとの買収と合併により、多くのASEで構成されている場合があります。
3. A service provider may wish to interconnect its multicast VPN platform with that of another service provider.
3. サービスプロバイダーは、マルチキャストVPNプラットフォームと別のサービスプロバイダーのプラットフォームと相互接続することをお勧めします。
The first scenario can be considered the "simplest" because the network is wholly managed by a single service provider under a single strategy and is therefore likely to use a consistent set of technologies across each AS.
最初のシナリオは、単一の戦略の下で単一のサービスプロバイダーによって完全に管理されているため、それぞれにわたって一貫した一連のテクノロジーを使用する可能性が高いため、「最も単純な」と見なすことができます。
The second scenario may be more complex than the first because the strategy and technology choices made for each AS may have been different due to their differing histories, and the service provider may not have unified (or may be unwilling to unify) the strategy and technology choices for each AS.
2番目のシナリオは、歴史が異なるためにそれぞれに対して行われた戦略とテクノロジーの選択が行われた可能性があり、サービスプロバイダーが戦略とテクノロジーを統合していない（または統合したくない）ため、最初のシナリオよりも複雑な場合があります。それぞれの選択。
The third scenario is the most complex because in addition to the complexity of the second scenario, the ASes are managed by different service providers and therefore may be subject to a different trust model than the other scenarios.
3番目のシナリオは、2番目のシナリオの複雑さに加えて、ASEが異なるサービスプロバイダーによって管理されるため、他のシナリオとは異なる信頼モデルの対象となるため、最も複雑なものです。
Section 5.2.6 of [RFC4834] states that "a solution MUST support inter-AS multicast VPNs, and SHOULD support inter-provider multicast VPNs", "considerations about co-existence with unicast inter-AS VPN Options A, B, and C (as described in Section 10 of [RFC4364]) are strongly encouraged", and "a multicast VPN solution SHOULD provide inter-AS mechanisms requiring the least possible coordination between providers, and keep the need for detailed knowledge of providers' networks to a minimum -- all this being in comparison with corresponding unicast VPN options".
[RFC4834]のセクション5.2.6は、「ソリューションはマルチキャスト間VPNをサポートする必要があり、プロバイダー間マルチキャストVPNSをサポートする必要がある」、「Unicast Inter-AS VPNオプションA、B、およびCとの共存に関する考慮事項」（[RFC4364]のセクション10で説明されているように）が強く奨励されています」。 - これはすべて、対応するユニキャストVPNオプションと比較しています」。
Section 8 of [RFC6513] addresses these requirements by proposing two approaches for MVPN inter-AS deployments:
[RFC6513]のセクション8では、MVPN Inter-AS展開の2つのアプローチを提案することにより、これらの要件に対処します。
1. Non-segmented inter-AS tunnels where the multicast tunnels are end-to-end across ASes, so even though the PEs belonging to a given MVPN may be in different ASes, the ASBRs play no special role and function merely as P routers (described in Section 8.1).
1. マルチキャストトンネルがASE全体でエンドツーエンドであるトンネルの非セグメント化されていないトンネル。したがって、特定のMVPNに属するPESが異なるASEにある可能性がありますが、ASBRは単にPルーターとして特別な役割を果たし、機能を果たしません（説明されていますセクション8.1）。
2. Segmented inter-AS tunnels where each AS constructs its own separate multicast tunnels that are then 'stitched' together by the ASBRs (described in Section 8.2).
2. それぞれが独自の個別のマルチキャストトンネルを構築し、ASBRによって一緒に「ステッチ」される（セクション8.2で説明されている）セグメント化されたトンネル。
(Note that an inter-AS deployment can alternatively rely on Option A -- so-called "back-to-back" VRFs -- that option is not considered in this section given that it can be used without any inter-AS-specific mechanism.)
（AS Inter-ASの展開は、オプションA（いわゆる「連続した」VRFS）に代わりに依存できることに注意してください。このセクションでは、特に特定として使用できないため、このセクションでは考慮されていません。機構。）
Section 5.2.6 of [RFC4834] also states, "Within each service provider, the service provider SHOULD be able on its own to pick the most appropriate tunneling mechanism to carry (multicast) traffic among PEs (just like what is done today for unicast)". The segmented approach is the only one capable of meeting this requirement.
[RFC4834]のセクション5.2.6は、「各サービスプロバイダー内で、サービスプロバイダーはPES間で最も適切なトンネリングメカニズム（マルチキャスト）を運ぶことができる最も適切なトンネリングメカニズムを選択できるようにする必要があります（ユニキャストのために今日行われていることと同じように）」。セグメント化されたアプローチは、この要件を満たすことができる唯一のアプローチです。
The segmented inter-AS solution would appear to offer the largest degree of deployment flexibility to operators. However, the non-segmented inter-AS solution can simplify deployment in a restricted number of scenarios. [RFC6037] only supports the non-segmented inter-AS solution; therefore, the non-segmented inter-AS solution is likely to be useful to some operators for backward compatibility and during migration from [RFC6037] to [RFC6513].
セグメント化されたInter-ASソリューションは、オペレーターに最大の展開の柔軟性を提供すると思われます。ただし、セグメント化されていないASソリューションは、制限された数のシナリオで展開を簡素化できます。[RFC6037]は、セグメント化されていないAS Inter-ASソリューションのみをサポートします。したがって、非セグメント化されたAS Inter-ASソリューションは、後方互換性のために、および[RFC6037]から[RFC6513]への移行のために、一部のオペレーターにとって有用である可能性があります。
The following is a comparison matrix between the "segmented inter-AS P-tunnels" and "non-segmented inter-AS P-tunnels" approaches:
以下は、「P-Tunnelsのセグメント化されたセグメント化されたP-Tunnels」と「非セグメント化されたP-Tunnels」アプローチの比較マトリックスです。
o Scalability for I-PMSIs: The "segmented inter-AS P-tunnels" approach is more scalable, because of the ability of an ASBR to aggregate multiple intra-AS P-tunnels used for I-PMSI within its own AS into one inter-AS P-tunnel to be used by other ASes. Note that the I-PMSI scalability improvement brought by the "segmented inter-AS P-tunnels" approach is higher when segmented P-tunnels have a granularity of source AS (see item below).
o I-PMSISのスケーラビリティ：ASBRが複数のINTRA-AS PMSIに使用されるPMSIに使用されるP-Tunnelを1つの間に集約する能力により、「セグメント化されたP-Tunnels」アプローチはよりスケーラブルです。他のASEによって使用されるPターンネルとして。セグメント化されたPタンネルのソースの粒度がある場合、「セグメント化されたP-Tunnels」アプローチによってもたらされるI-PMSIスケーラビリティの改善は、より高いことに注意してください（以下の項目を参照）。
o Scalability for S-PMSIs: The "segmented inter-AS P-tunnels" approach, when used with the BGP-based C-multicast routing approach, provides flexibility in how the bandwidth/state trade-off is handled, to help with scalability. Indeed, in that case, the trade-off made for a said (C-S,C-G) in a downstream AS can be made more in favor of scalability than the trade-off made by the neighbor upstream AS, thanks to the ability to aggregate one or more S-PMSIs of the upstream AS in one I-PMSI tunnel in a downstream AS.
o S-PMSISのスケーラビリティ：BGPベースのC-Multicastルーティングアプローチで使用される場合、「セグメント化されたP-Tunnels」アプローチは、スケーラビリティを支援するために、帯域幅/状態のトレードオフがどのように処理されるかを柔軟に提供します。実際、その場合、その場合は、上流の上流のトレードオフよりもスケーラビリティを支持して、下流で上記の（C-S、C-G）のトレードオフが行われました。または、下流のASにある1つのI-PMSIトンネルのように、上流のS-PMSIS。
o Configuration at ASBRs: Depending on whether segmented P-tunnels have a granularity of source ASBR or source AS, the "segmented inter-AS P-tunnels" approach would require respectively the same or additional configuration on ASBRs as the "non-segmented inter-AS P-tunnels" approach.
o ASBRSでの構成：セグメント化されたPタンネルにソースASBRまたはソースASの粒度があるかどうかに応じて、「セグメント化されたP-Tunnels」アプローチには、「非セグメント化されたインターインター - と同じまたは追加の構成が必要または追加の構成が必要です。P-Tunnels」アプローチとして。
o Independence of tunneling technology from one AS to another: The "segmented inter-AS P-tunnels" approach provides this; the "non-segmented inter-AS P-tunnels" approach does not.
o トンネリングテクノロジーの独立性は、次のようになります。「セグメント化されたP-tunnels」アプローチはこれを提供します。「非セグメント化されていないP-tunnels」アプローチはそうではありません。
o Facilitated coexistence with, and migration from, existing deployments and lighter engineering in some scenarios: The "non-segmented inter-AS P-tunnels" approach provides this; the "segmented inter-AS P-tunnels" approach does not.
o いくつかのシナリオでの既存の展開とより軽いエンジニアリングとの共存と移行を促進します。「P-Tunnelsのセグメント化されたP-Tunnels」アプローチはそうではありません。
The applicability of segmented or non-segmented inter-AS tunnels to a given deployment or inter-provider interconnect will depend on a number of factors specific to each service provider. However, given the different elements reminded above, it is the recommendation of
特定の展開またはプロバイダー間の相互接続へのセグメント化または非セグメント化されたトンネルの適用性は、各サービスプロバイダーに固有の多くの要因に依存します。ただし、上記のさまざまな要素を考えると、それは
the authors that all implementations should support the segmented inter-AS model. Additionally, the authors recommend that implementations should consider supporting the non-segmented inter-AS model in order to facilitate coexistence with, and migration from, existing deployments, and to provide a lighter engineering in a restricted set of scenarios, although it is recognized that initial implementations may only support one or the other.
すべての実装がセグメント化されたAS Inter-ASモデルをサポートする必要がある著者。さらに、著者は、既存の展開との共存と移行を促進し、制限されたシナリオでより軽量エンジニアリングを提供するために、セグメント化されていないASモデルをサポートすることを実装することを推奨していますが、それは認識されていますが、初期実装は、どちらか一方のみをサポートする場合があります。
In BIDIR-PIM, the packet-forwarding rules have been improved over PIM-SM, allowing traffic to be passed up the shared tree toward the RPA. To avoid multicast packet looping, BIDIR-PIM uses a mechanism called the designated forwarder (DF) election, which establishes a loop-free tree rooted at the RPA. Use of this method ensures that only one copy of every packet will be sent to an RPA, even if there are parallel equal cost paths to the RPA. To avoid loops, the DF election process enforces a consistent view of the DF on all routers on network segment, and during periods of ambiguity or routing convergence, the traffic forwarding is suspended.
Bidir-PIMでは、PIM-SMでパケットフォワードルールが改善されており、RPAに向かって共有ツリーを渡すことができます。マルチキャストパケットループを回避するために、Bidir-PIMは、RPAに根付いたループフリーツリーを確立する指定されたフォワーダー（DF）選挙と呼ばれるメカニズムを使用します。この方法を使用すると、RPAに並列等しいコストパスがある場合でも、すべてのパケットのコピーが1つだけRPAに送信されることが保証されます。ループを回避するために、DFの選挙プロセスは、ネットワークセグメント上のすべてのルーターのDFの一貫したビューを実施し、曖昧さまたはルーティングの収束の期間中、トラフィック転送が中断されます。
In the context of a multicast VPN solution, a solution for BIDIR-PIM support must preserve this property of similarly avoiding packet loops, including in the case where multicast VRFs in a given MVPN don't have a consistent view of the routing to C-RPL/C-RPA (Customer-RPL/Customer-RPA, i.e., RPL/RPA of a Bidir customer PIM instance).
マルチキャストVPNソリューションのコンテキストでは、Bidir-PIMサポートのソリューションは、特定のMVPNのマルチキャストVRFSがC-へのルーティングの一貫したビューを持たない場合を含め、同様にパケットループを避けるこのプロパティを保存する必要があります。RPL/C-RPA（Customer-RPL/Customer-RPA、つまりBidir Customer PIMインスタンスのRPL/RPA）。
Section 11 of the current MVPN specification [RFC6513] defines three methods to support BIDIR-PIM, as RECOMMENDED in [RFC4834]:
現在のMVPN仕様[RFC6513]のセクション11では、[RFC4834]で推奨されるように、Bidir-PIMをサポートする3つの方法を定義します。
1. Standard DF election procedure over an MI-PMSI
1. Mi-PMSIを介した標準的なDF選挙手続き
2. VPN Backbone as the RPL (Section 11.1)
2. RPLとしてのVPNバックボーン（セクション11.1）
3. Partitioned Sets of PEs (Section 11.2)
3. PESの分割セット（セクション11.2）
Method (1) is naturally applied to deployments using "Full per-MVPN PIM peering across an MI-PMSI" for C-multicast routing, but as indicated in [RFC6513], Section 11, the DF election may not work well in an MVPN environment, and an alternative to DF election would be desirable.
方法（1）は、C-Multicastルーティング用の「Mi-PMSI全体の完全なMVPN PIMピムピーム」を使用して展開に自然に適用されますが、[RFC6513]、セクション11で示されているように、DF選挙はMVPNではうまく機能しない場合があります。環境、およびDF選挙に代わるものが望ましいでしょう。
The advantage of methods (2) and (3) is that they do not require running the DF election procedure among PEs.
方法（2）と（3）の利点は、PES間のDF選挙手続きを実行する必要がないことです。
Method (2) leverages the fact that in BIDIR-PIM, running the DF election procedure is not needed on the RPL. This approach thus has the benefit of simplicity of implementation, especially in a context
方法（2）は、Bidir-PIMで、DF選挙手続きを実行していることがRPLで必要ないという事実を活用しています。したがって、このアプローチには、特にコンテキストで実装の単純さの利点があります
where BGP-based C-multicast routing is used. However, it has the drawback of putting constraints on how BIDIR-PIM is deployed, which may not always match the requirements of MVPN customers.
BGPベースのC-Multicastルーティングが使用されます。ただし、Bidir-PIMがどのように展開されるかに制約を付けるという欠点があります。これは、MVPN顧客の要件と常に一致するとは限りません。
Method (3) treats an MVPN as a collection of sets of multicast VRFs, all PEs in a set having the same reachability information towards C-RPA but distinct from PEs in other sets. Hence, with this method, C-Bidir packet loops in MVPN are resolved by the ability to partition a VPN into disjoint sets of VRFs, each having a distinct view of the converged network. The partitioning approach to BIDIR-PIM requires either upstream-assigned MPLS labels (to denote the partition) or a unique MP2MP LSP per partition. The former is based on PE Distinguisher Labels that have to be distributed using auto-discovery BGP routes, and their handling requires the support for upstream assigned labels and context label lookups [RFC5331]. The latter, using MP2MP LSP per partition, does not have these constraints but is restricted to P-tunnel types supporting MP2MP connectivity (such as mLDP [RFC6388]).
方法（3）は、MVPNをマルチキャストVRFのセットのコレクションとして扱います。セット内のすべてのPEは、C-RPAに対して同じ到達可能性情報を持っていますが、他のセットではPEとは異なります。したがって、この方法では、MVPNのC-Bidirパケットループは、VPNをvrfsの分離セットに分割する機能によって解決され、それぞれが収束ネットワークの明確なビューを持っています。Bidir-PIMへのパーティション化アプローチには、上流で割り当てられたMPLSラベル（パーティションを示すため）またはパーティションごとの一意のMP2MP LSPのいずれかが必要です。前者は、自動発見BGPルートを使用して配布する必要があるPE違いラベルに基づいており、その取り扱いには、上流の割り当てられたラベルとコンテキストラベルの検索[RFC5331]のサポートが必要です。後者は、パーティションごとにMP2MP LSPを使用して、これらの制約はありませんが、MP2MP接続（MLDP [RFC6388]など）をサポートするPトンネルタイプに制限されています。
This approach to C-Bidir can work with PIM-based or BGP-based C-multicast routing procedures and is also generic in the sense that it does not impose any requirements on the BIDIR-PIM service offering.
C-Bidirへのこのアプローチは、PIMベースまたはBGPベースのCマルチキャストルーティング手順で動作し、Bidir-PIMサービスの提供に要件を課さないという意味でも一般的です。
Given the above considerations, method (3) "Partitioned Sets of PEs" is the RECOMMENDED approach.
上記の考慮事項を考えると、方法（3）「PESの分割セット」が推奨されるアプローチです。
In the event where method (3) is not applicable (lack of support for upstream assigned labels or for a P-tunnel type providing MP2MP connectivity), then method (1) "Standard DF election procedure over an MI-PMSI" and (2) "VPN Backbone as the RPL" are RECOMMENDED as interim solutions, (1) having the advantage over (2) of not putting constraints on how BIDIR-PIM is deployed and the drawbacks of only being applicable when PIM-based C-multicast is used and of possibly not working well in an MVPN environment.
方法（3）が適用されない場合（上流の割り当てられたラベルまたはMP2MP接続を提供するPトンネルタイプのサポートの欠如）、メソッド（1）「Mi-PMSIを超える標準DF選挙手順」および（2）「RPLとしてのVPNバックボーン」は、暫定ソリューションとして推奨されます。使用され、おそらくMVPN環境でうまく機能しない可能性があります。
Section 5.1.10.1 of [RFC4834] states, "In the case of PIM-SM in ASM mode, engineering of the RP function requires the deployment of specific protocols and associated configurations. A service provider may offer to manage customers' multicast protocol operation on their behalf. This implies that it is necessary to consider cases where a customer's RPs are outsourced (e.g., on PEs). Consequently, a VPN solution MAY support the hosting of the RP function in a VR or VRF".
[RFC4834]のセクション5.1.10.1は、「ASMモードのPIM-SMの場合、RP関数のエンジニアリングが特定のプロトコルと関連する構成の展開が必要です。サービスプロバイダーは、顧客のマルチキャストプロトコル操作を管理することを提供する場合があります。彼らに代わって。これは、顧客のRPが外部委託されている場合（例えば、PES）ケースを検討する必要があることを意味します。その結果、VPNソリューションは、VRまたはVRFでのRP関数のホスティングをサポートする可能性があります。
However, customers who have already deployed multicast within their networks and have therefore already deployed their own internal RPs
ただし、ネットワーク内にマルチキャストを既に展開しているため、独自の内部RPSを既に展開しているお客様
are often reluctant to hand over the control of their RPs to their service provider and make use of a co-located RP model, and providing RP-collocation on a PE will require the activation of Multicast Source Discovery Protocol (MSDP) or the processing of PIM Registers on the PE. Securing the PE routers for such activity requires special care and additional work and will likely rely on specific features to be provided by the routers themselves.
多くの場合、RPの制御をサービスプロバイダーに引き渡し、共同配置されたRPモデルを利用し、PEでRPコロージャを提供するには、マルチキャストソースディスカバリープロトコル（MSDP）または処理のアクティブ化が必要です。PEにPIMが登録されます。このような活動のためにPEルーターを固定するには、特別なケアと追加作業が必要であり、ルーター自体が提供する特定の機能に依存する可能性があります。
The applicability of the co-located RP model to a given MVPN will thus depend on a number of factors specific to each customer and service provider.
したがって、特定のMVPNに共同配置されたRPモデルの適用性は、各顧客とサービスプロバイダーに固有の多くの要因に依存します。
It is therefore the recommendation that implementations should support a co-located RP model but that support for a co-located RP model within an implementation should not restrict deployments to using a co-located RP model: implementations MUST support deployments when activation of a PIM RP function (PIM Register processing and RP-specific PIM procedures) or a VRF MSDP instance is not required on any PE router and where all the RPs are deployed within the customers' networks or CEs.
したがって、実装は共同配列RPモデルをサポートする必要があるが、実装内での共同配置RPモデルのサポートは、共同配置RPモデルの使用に展開を制限するべきではないことを推奨しています。PIMのアクティブ化時に実装は展開をサポートする必要があります。RP関数（PIMレジスタ処理とRP固有のPIM手順）またはVRF MSDPインスタンスは、PEルーターでは必要ありません。すべてのRPが顧客のネットワークまたはCES内に展開されます。
It is recommended that implementations support the procedures described in Section 9.1.1 of [RFC6513] "Discarding Packets from Wrong PE", allowing fully avoiding duplicates.
[RFC6513]のセクション9.1.1 [間違ったPEからパケットを破棄する]で説明されている手順を実装することをお勧めします。
Some suggestions provided in this document can be used to incrementally modify currently deployed implementations without hindering these deployments and without hindering the consistency of the standardized solution by providing optional per-VRF configuration knobs to support modes of operation compatible with currently deployed implementations, while at the same time using the recommended approach on implementations supporting the standard.
このドキュメントで提供されるいくつかの提案は、これらの展開を妨げることなく現在展開されている実装を段階的に変更するために使用でき、オプションのVRF構成ノブを提供することにより、標準化されたソリューションの一貫性を妨げることなく使用できます。標準をサポートする実装で推奨されるアプローチを使用します。
In cases where this may not be easily achieved, a recommended approach would be to provide a per-VRF configuration knob that allows incremental per-VPN migration of the mechanisms used by a PE device, which would allow migration with some per-VPN interruption of service (e.g., during a maintenance window).
これが簡単に達成されない場合には、推奨されるアプローチは、PEデバイスが使用するメカニズムの増分あたりの移行を可能にするVRFあたりの構成ノブを提供することです。サービス（メンテナンスウィンドウなど）。
Mechanisms allowing "live" migration by providing concurrent use of multiple alternatives for a given PE and a given VPN are not seen as a priority considering the expected implementation complexity
特定のPEおよび特定のVPNに複数の選択肢を同時に使用することにより、「ライブ」移行を可能にするメカニズムは、予想される実装の複雑さを考慮して優先事項とは見なされません
associated with such mechanisms. However, if there happen to be cases where they could be viably implemented relatively simply, such mechanisms may help improve migration management.
そのようなメカニズムに関連付けられています。ただし、比較的単純に単純に実装できる場合がある場合、そのようなメカニズムは移行管理の改善に役立つ可能性があります。
The following list summarizes conclusions on the mechanisms that define the set of mandatory-to-implement mechanisms in the context of [RFC6513].
次のリストは、[RFC6513]のコンテキストで、義務的なメカニズムのセットを定義するメカニズムに関する結論をまとめたものです。
Note well that the implementation of the non-mandatory alternative mechanisms is not precluded.
非命令的な代替メカニズムの実装は排除されていないことに注意してください。
Recommendations are:
推奨事項は次のとおりです。
o that BGP-based auto-discovery be the mandated solution for auto-discovery;
o そのBGPベースの自動発見は、自動ディスコベージの義務付けられたソリューションです。
o that BGP be the mandated solution for S-PMSI switching signaling;
o そのBGPは、S-PMSIスイッチングシグナリングの義務付けられたソリューションです。
o that implementations support both the BGP-based and the full per-MVPN PIM peering solutions for PE-PE exchange of customer multicast routing until further operational experience is gained with both solutions;
o この実装は、両方のソリューションでさらなる運用エクスペリエンスが得られるまで、顧客マルチキャストルーティングのPE-PE交換のためのBGPベースと完全なMVPN PIM PIM Peering Solutionsの両方をサポートします。
o that implementations use the "Partitioned Sets of PEs" approach for BIDIR-PIM support;
o その実装は、Bidir-PIMサポートのために「PESの分割セット」アプローチを使用します。
o that implementations implement the P2MP variants of the P2P protocols that they already implement, such as mLDP, P2MP RSVP-TE, and GRE/IP-Multicast;
o その実装は、MLDP、P2MP RSVP-TE、GRE/IP-Multicastなど、すでに実装するP2PプロトコルのP2MPバリアントを実装しています。
o that implementations support segmented inter-AS tunnels and consider supporting non-segmented inter-AS tunnels (in order to maintain backward compatibility and for migration);
o この実装は、セグメント化されたトンネルをサポートし、非セグメント化されたトンネルをサポートすることを検討します（後方互換性を維持し、移行のために）。
o that implementations MUST support deployments when the activation of a PIM RP function (PIM Register processing and RP-specific PIM procedures) or VRF MSDP instance is not required on any PE router; and
o PEルーターでは、PIM RP関数（PIMレジスタ処理とRP固有のPIM手順）またはVRF MSDPインスタンスのアクティブ化が必要な場合、その実装は展開をサポートする必要があります。と
o that implementations support the procedures described in Section 9.1.1 of [RFC6513].
o その実装は、[RFC6513]のセクション9.1.1で説明されている手順をサポートしています。
This document does not by itself raise any particular security considerations.
このドキュメントは、それ自体が特定のセキュリティ上の考慮事項を提起するものではありません。
We would like to thank Adrian Farrel, Eric Rosen, Yakov Rekhter, and Maria Napierala for their feedback that helped shape this document.
エイドリアン・ファレル、エリック・ローゼン、ヤコフ・レクター、マリア・ナピエララに、この文書の形成に役立ったフィードバックに感謝します。
Additional credit is due to Maria Napierala for co-authoring Section 3.6 on BIDIR-PIM Support.
追加のクレジットは、Bidir-PIMサポートに関する共同執筆セクション3.6のMaria Napieralaによるものです。
[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月。
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, February 2012.
[RFC6513]ローゼン、E。、編およびR. Aggarwal編、「MPLS/ BGP IP VPNSのマルチキャスト」、RFC 6513、2012年2月。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS/BGP IP VPNSのマルチキャストのBGPエンコーディングと手順」、RFC 6514、2012年2月。
[MVPN] Aggarwal, R., "Base Specification for Multicast in BGP/ MPLS VPNs", Work in Progress, June 2004.
[MVPN] Aggarwal、R。、「BGP/ MPLS VPNSのマルチキャストの基本仕様」、2004年6月、進行中の作業。
[PIM-PORT] Farinacci, D., Wijnands, I., Venaas, S., and M. Napierala, "A Reliable Transport Mechanism for PIM", Work in Progress, October 2011.
[Pim-Port] Farinacci、D.、Wijnands、I.、Venaas、S。、およびM. Napierala、「PIMの信頼できる輸送メカニズム」、2011年10月の作業。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4684] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ. Guichard、 "境界ゲートウェイプロトコル/マルチプロトコルラベルスイッチングの制約付きルート分布（BGP/MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPNS）」、RFC 4684、2006年11月。
[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月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLS Upstream Labelの割り当てとコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.
[RFC5796] Atwood、W.、Islam、S。、およびM. Siami、「プロトコル独立マルチキャストスパースモード（PIM-SM）リンクローカルメッセージの認証と機密性」、RFC 5796、2010年3月。
[RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, October 2010.
[RFC6037] Rosen、E.、Cai、Y。、およびIJ。Wijnands、「Cisco SystemsのBGP/MPLS IP VPNSのマルチキャストのソリューション」、RFC 6037、2010年10月。
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[RFC6388] Wijnands、IJ。、Mighei、I.、Kompella、K。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチ付きパスのラベル分布プロトコル拡張」、RFC 6388、2011年11月。
The main role of multicast routing is to let routers determine that they should start or stop forwarding a said multicast stream on a said link. In an MVPN context, this has to be done for each MVPN, and the associated function is thus named "customer-multicast routing" or "C-multicast routing", and its role is to let PE routers determine that they should start or stop forwarding the traffic of a said multicast stream toward the remote PEs, on some PMSI tunnel.
マルチキャストルーティングの主な役割は、ルーターが、上記のリンクで上記のマルチキャストストリームの転送を開始または停止する必要があると判断できることです。MVPNコンテキストでは、これは各MVPNに対して実行される必要があります。したがって、関連する関数は「カスタマーマルチキャストルーティング」または「Cマルチキャストルーティング」と呼ばれ、その役割は、PEルーターが開始または停止する必要があると判断できるようにすることです。一部のPMSIトンネルで、上記のマルチキャストストリームのトラフィックをリモートPEに向けて転送します。
When a Join message is received by a PE, this PE knows that it should be sending traffic for the corresponding multicast group of the corresponding MVPN. However, the reception of a Prune message from a remote PE is not enough by itself for a PE to know that it should stop forwarding the corresponding multicast traffic: it has to make sure that there aren't any other PEs that still have receivers for this traffic.
結合メッセージがPEによって受信されると、このPEは、対応するMVPNの対応するマルチキャストグループのトラフィックを送信する必要があることを知っています。ただし、リモートPEからのプルーンメッセージを受信するだけでは、対応するマルチキャストトラフィックの転送を停止する必要があることをPEでは十分ではありません。このトラフィック。
There are many ways that the "C-multicast routing" building block can be designed, and they differ, among other things, in how a PE determines when it can stop forwarding a said multicast stream toward other PEs:
「C-Multicastルーティング」ビルディングブロックを設計できる多くの方法がありますが、とりわけ、PEが他のPESに向けたマルチキャストストリームの転送をいつ停止できるかをPEが決定する方法が異なります。
PIM LAN Procedures, by default By default, when PIM LAN procedures are used when a PE on a LAN Prunes itself from a multicast tree, all other PEs on that LAN check their own state to known if they are on the tree, in which case they send a PIM Join message on that LAN to override the Prune. Thus, for each PIM Prune message, all PE routers on the LAN work to let the upstream PE determine the answer to the "did the last receiver leave?" question.
PIM LAN手順デフォルトでは、デフォルトでは、LAN上のPEがマルチキャストツリーからPEがプルーンを使用したときにPIM LAN手順を使用する場合、そのLAN上の他のすべてのPEが自分の状態をチェックして、ツリーにあるかどうかを知っています。彼らはそのLANにPIM結合メッセージを送信して、プルーンをオーバーライドします。したがって、各PIMプルーンメッセージについて、LAN上のすべてのPEルーターが作業して、上流のPEが「最後の受信者が離れたのか」に対する答えを決定させるようにします。質問。
BGP-based C-multicast routing When BGP-based procedures are used for C-multicast routing, if no BGP route reflector is used, the "did the last receiver leave?" question is answered by having the upstream PE maintain an up-to-date list of the PEs that are joined to the tree, thus making it possible to instantly know the answer to the "did the last receiver leave?" question whenever a PE leaves the said multicast tree.
BGPベースのCマルチキャストルーティングBGPベースの手順がC-Multicastルーティングに使用される場合、BGPルートリフレクターが使用されない場合、「最後の受信者は出発しましたか？」質問は、上流のPEにツリーに結合されたPEの最新リストを維持することで回答され、したがって、「最後の受信者が出発しましたか？」に対する答えを即座に知ることができます。PEが上記のマルチキャストツリーを離れるたびに質問してください。
However, when a BGP route reflector is used (which is expected to be the recommended approach), the role of maintaining an updated list of the PEs that are part of a said multicast tree is taken care of by the route reflector(s). Using BGP procedures, a route reflector that had advertised a C-multicast Source Tree Join route for a said (C-S,C-G) to other route reflectors before will withdraw this route when there is no of its clients PEs
ただし、BGPルートリフレクターを使用する場合（これは推奨されるアプローチになると予想されます）、上記のマルチキャストツリーの一部であるPEの更新リストを維持する役割は、ルートリフレクターによって処理されます。BGP手順を使用して、クライアントのPESがない場合、C-Multicast Source Treeを他のルートリフレクターに結合したルート（C-S、C-G）が他のルートリフレクターへのルート（C-S、C-G）を宣伝したルートリフレクターを使用します。
advertising this route anymore. Similarly, a route reflector that had advertised this route to its client PEs before will withdraw this route when its (other) client PEs and its route reflectors peers are no longer advertising this route. In this context, the "did the last receiver leave?" question can be said to be answered by the route reflector(s).
もうこのルートを宣伝します。同様に、クライアントPESへのこのルートを宣伝したルートリフレクターは、その（他の）クライアントPESとルートリフレクターのピアがこのルートを宣伝しなくなったときにこのルートを引き出します。これに関連して、「最後の受信者は出発しましたか？」質問は、ルートリフレクターによって回答されると言えます。
Furthermore, the BGP route distribution can leverage more than one route reflector: if multiple route reflectors are used with PEs being distributed (as clients) among these route reflectors, the "did the last receiver leave?" question is partly answered by each of these route reflectors.
さらに、BGPルート分布は複数のルートリフレクターを活用できます。複数のルートリフレクターが使用されている場合、これらのルートリフレクターの間に（クライアントとして）PESが分布している場合、「最後のレシーバーは出発しましたか？」質問は、これらのルートリフレクターのそれぞれによって部分的に回答されます。
We can see that the "last receiver leaves" question is a part of the work that the C-multicast routing building block has to address, and the different approaches significantly differ. The different approaches for handling C-multicast routing can indeed result in a different amount of processing and how this processing is spread among the different functions. These differences can be better estimated by quantifying the amount of message processing and state maintenance.
「最後の受信者が去る」という質問は、C-Multicastルーティングビルディングブロックが対処しなければならない作業の一部であり、異なるアプローチが大きく異なることがわかります。C-Multicastルーティングを処理するためのさまざまなアプローチは、実際に異なる量の処理と、この処理が異なる機能の間でどのように広がるかをもたらす可能性があります。これらの違いは、メッセージ処理の量と状態メンテナンスの量を定量化することにより、よりよく推定できます。
Though the type of processing, messages, and states may vary with the different approaches, we propose here a rough estimation of the load of PEs, in terms of number of messages processed and number of control plane states maintained. A "message processed" is a message being parsed, a lookup being done, and some action being taken (such as, for instance, updating a control plane or data plane state or discarding the information in the message). A "state maintained" is a multicast state kept in the control plane memory of a PE, related to an interface or a PE being subscribed to a multicast stream (note that a state will be counted on an equipment as many times as the number of protocols in which it is present, e.g., two times when present both as a PIM state and a BGP route). Note that here we don't compare the data plane states on PE routers, which wouldn't vary between the different options chosen.
処理、メッセージ、および状態の種類はさまざまなアプローチによって異なる場合がありますが、処理されたメッセージの数と維持されるコントロールプレーン状態の数の観点から、PEの負荷の大まかな推定をここで提案します。「メッセージ処理されたメッセージ」とは、解析されているメッセージ、ルックアップが行われ、いくつかのアクションが実行されます（たとえば、コントロールプレーンやデータプレーンの状態を更新したり、メッセージ内の情報を破棄したりするなど）。「状態」は、インターフェイスまたはマルチキャストストリームにサブスクライブされているPEに関連するPEの制御プレーンメモリに保管されているマルチキャスト状態です（状態は、数の数と同じように機器にカウントされることに注意してくださいPIM状態とBGPルートの両方として存在する場合、それが存在するプロトコル。ここでは、PEルーターのデータプレーン状態を比較しないことに注意してください。
The following sections evaluate the processing and state maintenance load for an increasingly high number of PEs in a VPN.
以下のセクションでは、VPNでますます多くのPESの処理と状態のメンテナンス負荷を評価します。
The following subsections do such an estimation for each proposed approach for C-multicast routing, for different phases of the following scenario:
次のサブセクションは、次のシナリオのさまざまなフェーズについて、C-Multicastルーティングの提案されたアプローチごとにこのような推定を行います。
o One SSM multicast stream is considered.
o 1つのSSMマルチキャストストリームが考慮されます。
o Only the intra-AS case is concerned (with the segmented inter-AS tunnels and BGP-based C-multicast routing, #mvpn_PE and #R_PE should refer to the PEs of the MVPN in the AS, not to all PEs of the MVPN).
o AS Intra-ASケースのみが関係しています（セグメント化されたトンネルとBGPベースのCマルチキャストルーティングでは、#MVPN_PEおよび#R_PEは、MVPNのすべてのPEではなく、ASのMVPNのPEを参照する必要があります）。
o The scenario is as follows:
o シナリオは次のとおりです。
* One PE joins the multicast stream (because of a new receiver-connected site has sent a Join on the PE-CE link), followed by a number of additional PEs that also join the same multicast stream, one after the other; we evaluate the processing required for the addition of each PE.
* 1つのPEがマルチキャストストリームに結合します（新しいレシーバーに接続されたサイトがPE-CEリンクに結合を送信したため）。各PEの追加に必要な処理を評価します。
* A period of time T passes, without any PE joining or leaving (baseline).
* PEが参加したり離れたりすることなく、Tが経過します（ベースライン）。
* All PEs leave, one after the other, until the last one leaves; we evaluate the processing required for the leave of each PE.
* すべてのPESは、最後の1つが去るまで、次々と出発します。各PEの休暇に必要な処理を評価します。
o The parameters used are:
o 使用されるパラメーターは次のとおりです。
* #mvpn_PE: the number of PEs in the MVPN
* #R_PE: the number of PEs joining the multicast stream
* #RR: the number of route reflectors
* T_PIM_r: the time between two refreshes of a PIM Join (default is 60s)
* T_PIM_R：PIM結合の2つのリフレッシュの間の時間（デフォルトは60秒）
The estimation unit used is the "message.equipment" (or "m.e"): one "message.equipment" corresponds to "one equipment processing one message" (10 m.e being "10 equipments processing each one message", "5 messages each processed by 2 equipments", or "1 message processed by 10 equipment", etc.). Similarly, for the amount of control plane state, the unit used is "state.equipment" or "s.e". This accounts for the fact that a message (or a state) can be processed (or maintained) by more than one node.
使用される推定単位は、「message.equipment」（または "m.e"）：1つの「message.equipment」は「1つの機器の処理1つのメッセージ」に対応しています（10 m.eは「各1つのメッセージを処理する10機器」、「それぞれ5メッセージ」2つの機器で処理される」、または「10機の機器で処理された1つのメッセージ」など）。同様に、コントロールプレーン状態の量については、使用されるユニットは「state.equipment」または「s.e」です。これは、メッセージ（または状態）を複数のノードで処理（または維持）できるという事実を説明しています。
We distinguish three different types of equipments: the upstream PE for the considered multicast stream, the RR (if any), and the other PEs (which are not the upstream PE).
3つの異なるタイプの機器を区別します。考慮されたマルチキャストストリームのアップストリームPE、RR（ある場合）、および他のPE（上流のPEではありません）。
The numbers or orders of magnitude given in the tables in the following subsections are totals across all equipments of a same type, for each type of equipment, in the "m.e" and "s.e" units defined above.
次のサブセクションのテーブルに記載されている数または数桁は、上記で定義された「M.E」および「S.E」ユニットの各タイプの機器のすべての機器に合計です。
Additionally:
さらに：
o For PIM, only Join and Prune messages are counted:
o PIMの場合、結合メッセージのみがカウントされます。
* The load due to PIM Hellos can be easily computed separately and only depends on the number of PEs in the VPN.
* PIM Hellosによる負荷は、個別に簡単に計算でき、VPNのPEの数のみにのみ依存します。
* Message processing related to the PIM Assert mechanism is also not taken into account, for the sake of simplicity.
* PIMアサートメカニズムに関連するメッセージ処理も、簡単にするために考慮されていません。
o For BGP, all advertisements and withdrawals of C-multicast Source Tree Join routes are considered (Source-Active auto-discovery routes are not used in an SSM context); following the recommendation in Section 16 of [RFC6514], the case where the Route Target Constraint mechanisms [RFC4684] is not used is not covered.
o BGPの場合、C-Multicastソースツリー結合ルートのすべての広告と引き出しが考慮されます（SSMコンテキストではソースアクティブの自動ディスコーブリルートは使用されません）。[RFC6514]のセクション16の推奨に続いて、ルートターゲット制約メカニズム[RFC4684]が使用されない場合はカバーされていません。
(Note that for all options provided for C-multicast routing, the procedures to set up and maintain a shortest path tree toward the source of an SSM group are the same as the procedures used to set up and maintain a shortest path tree toward an RP or a non-SSM source; the results of this section are thus re-used in Appendix A.1.2.)
（C-Multicastルーティングに提供されるすべてのオプションについて、SSMグループのソースに向かって最短のパスツリーをセットアップおよび維持する手順は、RPに向かって最短パスツリーを設定および維持するために使用される手順と同じであることに注意してください。または非SSMソース;このセクションの結果は、付録A.1.2で再利用されます。）
+------------+------------+---------------+----------+--------------+
| | upstream | other PEs | RR | total across |
| | PE (1) | (total across | (none) | all |
| | | (#mvpn_PE-1) | | equipments |
| | | PEs) | | |
+------------+------------+---------------+----------+--------------+
| first PE | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e |
| joins | | m.e | | |
+------------+------------+---------------+----------+--------------+
| for *each* | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e |
| additional | | m.e | | |
| PE joining | | | | |
+------------+------------+---------------+----------+--------------+
| baseline | T/T_PIM_r | (T/T_PIM_r) . | / | (T/T_PIM_r) |
| processing | m.e | (#mvpn_PE-1) | | x #mvpn_PE |
| over a | | m.e | | m.e |
| period T | | | | |
+------------+------------+---------------+----------+--------------+
| for *each* | 2 m.e | 2(#mvpn_PE-1) | / | 2 x #mvpn_PE |
| PE leaving | | m.e | | m.e |
+------------+------------+---------------+----------+--------------+
| the last | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e |
| PE leaves | | m.e | | |
+------------+------------+---------------+----------+--------------+
| total for | #R_PE x 2 | (#mvpn_PE-1) | 0 | #mvpn_PE x ( |
| #R_PE PEs | + | x (#R_PE) x 2 | | 3 x #R_PE + |
| | T/T_PIM_r | + T/T_PIM_r) | | T/T_PIM_r ) |
| | m.e | . | | m.e |
| | | (#mvpn_PE-1) | | |
| | | m.e | | |
+------------+------------+---------------+----------+--------------+
| total | 1 s.e | #R_PE s.e | 0 | #R_PE+1 s.e |
| state | | | | |
| maintained | | | | |
+------------+------------+---------------+----------+--------------+
Messages Processing and State Maintenance - PIM LAN Procedures, by Default
メッセージ処理と状態メンテナンス-PIM LAN手順、デフォルトで
We suppose here that the PIM Join suppression and Prune Override mechanisms are fully effective, i.e., that a Join or Prune message sent by a PE is instantly seen by other PEs. Strictly speaking, this is not true, and depending on network delays and timing, there could be cases where more messages are exchanged, and the number given in this table is a lower bound to the number of PIM messages exchanged.
ここでは、PIMが抑制とプルーンオーバーライドメカニズムが完全に効果的であると考えています。つまり、PEから送信された結合またはプルーンメッセージは他のPEによって即座に見られます。厳密に言えば、これは真実ではなく、ネットワークの遅延とタイミングに応じて、より多くのメッセージが交換される場合があり、この表に記載されている数は交換されるPIMメッセージの数の下限です。
The following analysis assumes that BGP route reflectors (RRs) are used, and no hierarchy of RRs (note that the analysis also assumes that Route Target Constraint mechanisms are used).
以下の分析では、BGPルートリフレクター（RRS）が使用されており、RRSの階層はありません（分析では、ルートターゲット制約メカニズムが使用されることも想定していることに注意してください）。
Given these assumptions, a message carrying a C-multicast route from a downstream PE would need to be processed by the RRs that have that PE as their client. Due to the use of Route Target Constraint mechanisms [RFC4684], these RRs would then send this message to only the RRs that have the upstream PE as a client. None of the other RRs and none of the other PEs will receive this message. Thus, for a message associated with a given MVPN, the total number of RRs that would need to process this message only depends on the number of RRs that maintain C-multicast routes for that MVPN and that have either the receiver-connected PE or the source-connected PE as their clients and is independent of the total number of RRs or the total number of PEs.
これらの仮定を考えると、下流のPEからC-Multicastルートを運ぶメッセージは、そのPEをクライアントとして持っているRRによって処理する必要があります。ルートターゲット制約メカニズム[RFC4684]の使用により、これらのRRSはこのメッセージをクライアントとして上流のPEを持っているRRSのみに送信します。他のRRおよび他のPESのどれもこのメッセージを受け取りません。したがって、特定のMVPNに関連付けられているメッセージの場合、このメッセージを処理する必要があるRRの総数は、そのMVPNのCマルチキャストルートを維持し、受信者に接続されたPEまたは存在するRRの数にのみ依存します。ソースに接続されたPEは、クライアントとしてPEであり、RRの総数またはPESの総数とは無関係です。
In practice, for a given MVPN, a PE would be a client of just 2 RRs (for redundancy, an RR cluster would typically have 2 RRs). Therefore, in practice the message would need to be processed by at most 4 RRs (2 RRs if both the downstream PE and the upstream PE are the clients of the same RRs). Thus, the number of RRs that have to process a given message is at most 4. Since RRs in different RR clusters have a full Internal BGP (iBGP) mesh among themselves, each RR in the RR cluster that contains the upstream PE would receive the message from each of the RRs in the RR cluster that contains the downstream PE. Given 2 RRs per cluster, the total number of messages processed by all the RRs is 6.
実際には、特定のMVPNの場合、PEはわずか2 RRのクライアントになります（冗長性の場合、RRクラスターには通常2つのRRがあります）。したがって、実際には、メッセージを最大4 RR（下流のPEと上流のPEの両方が同じRRのクライアントである場合、2 RR）によって処理する必要があります。したがって、指定されたメッセージを処理する必要があるRRの数は最大4.です。異なるRRクラスターのRRSには完全な内部BGP（IBGP）メッシュがあるため、上流のPEを含むRRクラスターの各RRは、下流のPEを含むRRクラスター内の各RRからのメッセージ。クラスターごとに2 RRが与えられた場合、すべてのRRSで処理されるメッセージの総数は6です。
Additionally, as soon as there is a receiver-connected PE in each RR cluster, the number of RRs processing a C-multicast route tends quickly toward 2 (taking into account that a PE peering to RRs will be made redundant).
さらに、各RRクラスターに受信機に接続されたPEがあるとすぐに、cマルチキャストルートの処理RRSの数は2つにすばやく傾向があります（RRを覗くPEが冗長になることを考慮して）。
+------------+----------+--------------+-----------+----------------+
| | upstream | other PEs | RRs (#RR) | total across |
| | PE (1) | (total | | all equipments |
| | | across | | |
| | | (#mvpn_PE-1) | | |
| | | PEs) | | |
+------------+----------+--------------+-----------+----------------+
| first PE | 2 m.e | 2 m.e | 6 m.e | 10 m.e |
| joins | | | | |
+------------+----------+--------------+-----------+----------------+
| for *each* | between | 2 m.e | (at most) | (at most) 10 |
| additional | 0 and 2 | | 6 m.e | m.e tending |
| PE joining | m.e | | tending | toward 4 m.e |
| | | | toward 2 | |
| | | | m.e | |
+------------+----------+--------------+-----------+----------------+
| baseline | 0 | 0 | 0 | 0 |
| processing | | | | |
| over a | | | | |
| period T | | | | |
+------------+----------+--------------+-----------+----------------+
| for *each* | between | 2 m.e | (at most) | (at most) 10 |
| PE leaving | 0 and 2 | | 6 m.e | m.e tending |
| | m.e | | tending | toward 4 m.e |
| | | | toward 2 | |
+------------+----------+--------------+-----------+----------------+
| the last | 2 m.e | 2 m.e | 6 m.e | 10 m.e |
| PE leaves | | | | |
+------------+----------+--------------+-----------+----------------+
| total for | at most | #R_PE x 4 | (at most) | at most 10 x |
| #R_PE PEs | 2 x #RRs | m.e | 6 x #R_PE | #R_PE + 2 x |
| | m.e (see | | m.e | #RRs m.e |
| | note | | (tending | (tending |
| | below) | | toward 2 | toward 6 x |
| | | | x #R_PE | #R_PE + #RRs |
| | | | m.e) | m.e ) |
+------------+----------+--------------+-----------+----------------+
| total | 4 s.e | 2 x #R_PE | approx. 2 | approx. 4 |
| state | | s.e | #R_PE + | #R_PE + #RRx |
| maintained | | | #RR x | #clusters + 4 |
| | | | #clusters | m.e |
| | | | s.e | |
+------------+----------+--------------+-----------+----------------+
Message Processing and State Maintenance - BGP-Based Procedures
メッセージ処理と状態メンテナンス-BGPベースの手順
Note on the total of m.e on the upstream PE:
上流のPEのM.Eの合計に注意してください：
o There are as many "message.equipment"s on the upstream PE as the number of times the RRs of the cluster of the upstream PE need to re-advertise the C-multicast (C-S,C-G) route; such a re-advertisement is not useful for the upstream PE, because the behavior of the upstream PE for a said (VPN associated to the Route Target, C-S,C-G) will not depend on the precise attributes carried by the route (other than the Route Target, of course) but will happen in some cases due to how BGP processes these routes. Indeed, a BGP peer will possibly re-advertise a route when its current best path changes for the said NLRI if the set of attributes to advertise also changes.
o
o Let's look at the different relevant attributes and when they can influence when a re-advertisement of a C-multicast route will happen:
o さまざまな関連属性を見てみましょう。C-Multicastルートの再承認が発生するときに影響を与えることができる時期：
* next-hop and originator-id: A new PE joining will not mechanically result in a need to re-advertise a C-multicast route because as the RR aggregates C-multicast routes with the same NLRI received from PEs in its own cluster (Section 11.4 of [RFC6514]), the RR rewrites the values of these attributes; however, the advertisements made by different RRs peering with the RRs in the cluster of the upstream PE may lead to updates of the value of these attributes.
* Next-Hop and Originator-ID：新しいPE結合は、RRが独自のクラスターでPESから受信した同じNLRIを凝集させるC-Multicastルートを集約するため、C-Multicastルートを再承認する必要があるため、機械的にはc-multicastルートを再承認する必要はありません。[RFC6514]の11.4）、RRはこれらの属性の値を書き直します。ただし、上流のPEのクラスター内のRRSで異なるRRSがピアリングする広告は、これらの属性の値の更新につながる可能性があります。
* cluster-list: The value of this attribute only varies between clusters, changes of the value of this attributes does not "follow" PE advertisements, and only advertisements made by different RRs may possibly lead to updates of the value of this attribute.
* クラスターリスト：この属性の値はクラスター間でのみ異なり、この属性の値の変更はPE広告に「従う」ことはなく、異なるRRによって作成された広告のみがこの属性の値の更新につながる可能性があります。
* local-pref: The value of this attribute is determined locally; this is true both for the routes advertised by each PE (which could all be configured to use the same value) and for a route that results from the aggregation by an RR of the route with the same NLRI advertised by the PEs of his cluster (the RRs could also be configured to use a local pref independent of the local_pref of the routes advertised to him). Thus, this attribute can be considered to result in a need to re-advertise a C-multicast route.
* Local-Pref：この属性の値はローカルで決定されます。これは、各PEによって宣伝されているルート（すべて同じ値を使用するように構成できます）と、クラスターのPESによって宣伝された同じNLRIを持つルートのRRによる集約から生じるルートの両方に当てはまります（RRSは、彼に宣伝されているルートのlocal_prefから独立したローカルPREFを使用するように構成することもできます）。したがって、この属性は、C-Multicastルートを再承認する必要があると考えることができます。
* Other BGP attributes do not have a particular reason to be set for C-multicast routes in intra-AS, and if they were, an RR (or, for attributes relevant for inter-AS, an ASBR) would also overwrite these values when aggregating these routes.
* 他のBGP属性には、AS内のCマルチキャストルートに設定される特定の理由はありません。もしそうなら、RR（または、ASINTERに関連する属性の場合、ASBR）も集約するときにこれらの値を上書きします。これらのルート。
o Given the above, for a said C-multicast Source Tree Join (S,G) NLRI, what may force an RR to re-advertise the route with different attributes to the upstream PE would be the case of an RR of another cluster advertising a route better than its current best route, because of the values of attributes specific to that RR (next-hop, originator-id, cluster-list) but not because of anything specific to the PEs behind that RR. If we consider our (#R_PE -1) joining a said (C-S,C-G), one after the other after the first PE joining, some of these events may thus lead to a re-advertisement to the upstream PE, but the number of times this can happen is at worse the number of RRs in clusters having receivers (plus one because of the possible advertisement of the same route by a PE of the local cluster).
o 上記を考えると、上記のC-Multicast Source Tree結合（S、G）NLRIの場合、RRが上流のPEに異なる属性を持つルートを再版にすることを強制する可能性があるのは、別のクラスターのRRの場合ですそのRR（Next-Hop、Originator-ID、Cluster-List）に固有の属性の値のために、現在の最良のルートよりも優れたルートは、そのRRの背後にあるPESに固有のものではありません。前述の（c-s、c-g）に参加する（#r_pe -1）が最初のPE参加後に次々と参加することを検討すると、これらのイベントの一部は上流のPEに再承認される可能性がありますが、これが発生する可能性がある場合は、レシーバーを持つクラスターのRRの数が悪化します（さらに、ローカルクラスターのPEによる同じルートの広告の可能性があるため）。
o Given that we look at scalability with an increased number of PEs in this section, we need to consider the possibility that all clusters may have a client PE with a receiver. We also need to consider that the two RRs of the cluster of the upstream PE may need to re-advertise the route. With this in mind, we know that 2x#RRs is an upper bound to the number of updates made by RRs to the upstream PE, for the considered C-multicast route.
o このセクションでは、PESの数が増えたスケーラビリティを調べることを考えると、すべてのクラスターがレシーバーを持つクライアントPEを持つ可能性を考慮する必要があります。また、上流のPEのクラスターの2つのRRがルートを再承認する必要がある場合があることを考慮する必要があります。これを念頭に置いて、2x＃RRSは、考慮されたCマルチキャストルートのRRSが上流のPEに作成した更新の数の上限であることを知っています。
This section concludes the previous section by considering the orders of magnitude when the number of PEs in a VPN increases.
このセクションでは、VPNのPESの数が増加したときに数桁を考慮することにより、前のセクションを締めくくります。
+------------+--------------------------------+---------------------+
| | PIM LAN Procedures | BGP-based |
+------------+--------------------------------+---------------------+
| first PE | O(#mvpn_PE) | O(1) |
| joins (in | | |
| m.e) | | |
+------------+--------------------------------+---------------------+
| for *each* | O(#mvpn_PE) | O(1) |
| additional | | |
| PE joining | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| baseline | (T/T_PIM_r) x O(#mvpn_PE) | 0 |
| processing | | |
| over a | | |
| period T | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| for *each* | O(#mvpn_PE) | O(1) |
| PE leaving | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| the last | O(#mvpn_PE) | O(1) |
| PE leaves | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| total for | O(#mvpn_PE x #R_PE) + | O(#R_PE) |
| #R_PE PEs | O(#mvpn_PE x T/T_PIM_r) | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| states (in | O(#R_PE) | O(#R_PE) |
| s.e) | | |
| notes | (processing and state | (processing and |
| | maintenance are essentially | state maintenance |
| | done by, and spread amongst, | is essentially done |
| | the PEs of the MVPN; | by, and spread |
| | non-upstream PEs have | amongst, the RRs) |
| | processing to do) | |
+------------+--------------------------------+---------------------+
Comparison of Orders of Magnitude for Message Processing and State Maintenance (Totals across All Equipments)
メッセージ処理と状態メンテナンスのための桁違いの比較（すべての機器にわたって合計）
The conclusions that can be drawn from the above are as follows:
上記から引き出すことができる結論は次のとおりです。
o In the PIM-based approach, any message will be processed by all PEs, including those that are neither upstream nor downstream for the message; as a result, the total number of messages to process is in O(#mvpn_PE x #R_PE), i.e., O(#mvpn_PE ^ 2) if the proportion of receiver PEs is considered constant when the number of PEs increases. The refreshes of Join messages introduce a linear factor not changing the order of magnitude, but which can be significant for long-lived streams;
o PIMベースのアプローチでは、メッセージの上流でも下流でもないものを含む、すべてのPEによってメッセージが処理されます。その結果、プロセスへのメッセージの総数はO（#MVPN_PE X＃R_PE）、つまり、PESの数が増加すると受信機PESの割合が一定と見なされる場合、O（#MVPN_PE ^ 2）です。結合メッセージのリフレッシュは、マグニチュードの順序を変更しない線形係数を導入しますが、これは長寿命のストリームで重要になる可能性があります。
o The BGP-based approach requires an amount of message processing in O(#R_PE) lower than the PIM-based approach. The amount is independent of the duration of streams.
o BGPベースのアプローチでは、PIMベースのアプローチよりも低いO（#R_PE）でのメッセージ処理が必要です。金額は、ストリームの期間とは無関係です。
o State maintenance is of the same order of magnitude for all approaches: O(#R_PE), but the repartition is different:
o 状態のメンテナンスは、すべてのアプローチで同じ程度の大きさです。O（#R_PE）ですが、再パーティションは異なります。
* The PIM-based approach fully spreads, and minimizes, the amount of state (one state per PE).
* PIMベースのアプローチは、状態の量（PEごとに1つの状態）を完全に広げ、最小化します。
* The BGP-based procedures spread all the state on the set of route reflectors.
* BGPベースの手順は、ルートリフレクターのセットにすべての状態を広めました。
The conclusions in Appendix A.1.1 are reused in this section, for the parts that are common to the setup and maintenance of states related to a source tree or a shared tree.
付録A.1.1の結論は、このセクションでは、ソースツリーまたは共有ツリーに関連する状態のセットアップとメンテナンスに共通する部分について、再利用されます。
When PIM-SM is used in a VPN and an ASM multicast group is joined by some PEs (#R_PEs) with some sources sending toward this multicast group address, we can note the following:
PIM-SMがVPNで使用され、ASMマルチキャストグループがいくつかのPES（#R_PES）が結合され、いくつかのソースがこのマルチキャストグループアドレスに送信されます。
PEs will generally have to maintain one shared tree, plus one source tree for each source sending toward G; each tree resulting in an amount of processing and state maintenance similar to what is described in the scenario in Appendix A.1.1, with the same differences in order of magnitudes between the different approaches when the number of PEs is high.
PESは通常、1つの共有ツリーに加えて、各ソースの1つのソースツリーをGに送信する必要があります。各ツリーは、付録A.1.1のシナリオで説明されているものと同様の処理と状態のメンテナンスをもたらします。PESの数が高い場合の異なるアプローチの間に大きさの順に同じ違いがあります。
An exception to this is when, for a said group in a VPN among the PIM instances in the customer routers and VRFs, none would switch to the shortest path tree (SPT) (SwitchToSptDesired always false): in that case, the processing and state maintenance load is the one required for maintenance of the shared tree only. It has to be noted that this scenario is dependent on customer policy. To compare the resulting load in that case, between PIM-based approaches and the
これの例外は、顧客ルーターとVRFのPIMインスタンスの間のVPNの上記グループの場合、最短のパスツリー（SPT）に切り替えるものはありません（SwitchToSptdesired Always False）：その場合、処理と状態メンテナンス負荷は、共有ツリーのみのメンテナンスに必要なものです。このシナリオは顧客ポリシーに依存していることに注意する必要があります。その場合、PIMベースのアプローチと
BGP-based approach configured to use inter-site shared trees, the scenario in Appendix A.1.1 can be used with #R_PEs joining a (C-*, C-G) ASM group instead of an SSM group, and the same differences in order of magnitude remain true. In the case of the BGP-based approach used without inter-site shared trees, we must take into account the load resulting from the fact that to build the C-PIM shared tree, each PE has to join the source tree to each source; using the notations of Appendix A.1.1, this adds an amount of load (total load across all equipments) that is proportional to #R_PEs and the number of sources. The order of magnitude with an increasing number of PEs is thus unchanged, and the differences in order of magnitude also remain the same.
敷地間共有ツリーを使用するように構成されたBGPベースのアプローチ、付録A.1.1のシナリオは、SSMグループの代わりに（c-*、c-g）ASMグループを結合する＃r_PESで使用できます。大きさは真実のままです。敷地間共有ツリーなしで使用されるBGPベースのアプローチの場合、C-PIM共有ツリーを構築するために、各PEが各ソースにソースツリーを結合する必要があるという事実に起因する負荷を考慮する必要があります。付録A.1.1の表記法を使用すると、#R_PESおよびソース数に比例する量の負荷（すべての機器に合計負荷）が追加されます。したがって、PESの数が増加する大きさの順序は変更されておらず、大きさの違いも同じままです。
Additionally, to the maintenance of trees, PEs have to ensure some processing and state maintenance related to individual sources sending to a multicast group; the related procedures and behaviors largely may differ depending on which C-multicast routing protocol is used, how it is configured, how the multicast source discovery mechanism is used in the customer VPN, and which SwitchToSptDesired policy is used. However, the following can be observed:
さらに、木のメンテナンスには、PESがマルチキャストグループに送信する個々のソースに関連する処理と状態のメンテナンスを確保する必要があります。関連する手順と動作は、どのc-multicastルーティングプロトコルの使用方法、構成方法、マルチキャストソース発見メカニズムが顧客VPNで使用される方法、およびどのswitchToSptdesiredポリシーが使用されるかによって大きく異なる場合があります。ただし、以下を観察できます。
o When BGP-based C-multicast routing is used:
o BGPベースのC-Multicastルーティングが使用される場合：
* Each PE will possibly have to process and maintain a BGP Source-Active auto-discovery route for (some or all) sources of an ASM group. The number of Source-Active auto-discovery routes will typically be one but may be related to the number of upstream PEs in the following cases: when inter-site shared trees are used and simultaneously more than one PE is used as the upstream PE for SPT (C-S,C-G) trees and when inter-site shared trees are used and there are multiple PEs that are possible upstream for this (S,G).
* 各PEは、ASMグループの（一部またはすべての）ソース用のBGPソースアクティブオートディスコービリルートを処理および維持する必要がある可能性があります。ソースアクティブの自動ディスコービリルートの数は通常1つになりますが、次の場合の上流のPEの数に関連する可能性があります。SPT（C-S、C-G）ツリー、およびサイト間共有ツリーが使用されると、これに上流で可能な複数のPEがあります（S、G）。
* This results in message processing and state maintenance (total across all the equipments) linearly dependent on the number of PEs in the VPN (#mvpn_PE) for each source, independent of the number of PEs joined to the group.
* これにより、グループに結合されたPESの数とは無関係に、各ソースのVPN（#MVPN_PE）のPESの数に直線的に依存するメッセージ処理と状態メンテナンス（すべての機器全体）が直線的に依存します。
* Depending on whether or not inter-site shared trees are used, on the SwitchToSptDesired policy in the PIM instances in the customer routers and VRFs, and on the relative locations of sources and RPs, this will happen for all (S,G) of an ASM group or only for some of them and will be done in parallel to the maintenance of shared and/or source trees or at the first join of a PE on a source tree.
* 敷地間共有ツリーが使用されているかどうか、顧客ルーターとVRFのPIMインスタンスのSwitchToSptDesiredポリシー、およびソースとRPの相対的な場所では、これはすべての（S、G）の場合に発生します。ASMグループまたはそれらの一部のみであり、共有ツリーおよび/またはソースツリーのメンテナンス、またはソースツリーのPEの最初の結合と並行して行われます。
o When PIM-based C-multicast routing is used, depending on the SwitchToSptDesired policy in the PIM instances in the customer routers and VRFs and depending on the relative locations of sources and RPs, there are:
o PIMベースのC-Multicastルーティングが使用されている場合、顧客ルーターとVRFのPIMインスタンスのSwitchToSptDesiredポリシー、およびソースとRPの相対的な場所に応じて、次のことがあります。
* Possible control plane state transitions triggered by the reception of (S,G) packets. Such events would induce processing on all PEs joined to G.
* （s、g）パケットの受信によってトリガーされるコントロールプレーン状態の遷移の可能性。このようなイベントは、Gに結合されたすべてのPEで処理を誘発します。
* Possible PIM Assert messages specific to (S,G). This would induce a message processing on each PE of the VPN for each PIM Assert message.
* 可能なPIMは（S、G）に固有のメッセージをアサートします。これにより、各PIMアサートメッセージに対してVPNの各PEにメッセージ処理が誘導されます。
Given the above, the additional processing that may happen for each individual source sending to the group, beyond the maintenance of source and shared trees, does not change the order of magnitude identified above.
上記を考えると、ソースや共有ツリーのメンテナンスを超えて、グループに送信する個々のソースごとに発生する可能性のある追加の処理は、上記の大きさの順序を変更しません。
The quantification of message processing in Appendix A.1.1 is done based on a use case where each PE with receivers has joined and left once. Drawing scalability-related conclusions for other patterns of changes of the set of receiver-connected PEs can be done by considering the cost of each approach for "a new PE joining" and "a PE leaving".
付録A.1.1のメッセージ処理の定量化は、受信機を持つ各PEが1回参加して出発したユースケースに基づいて行われます。レシーバーに接続されたPESのセットの変更の他のパターンのスケーラビリティ関連結論を描くことは、「新しいPE結合」および「PE去る」の各アプローチのコストを考慮することで実行できます。
For the "PIM LAN Procedure" approach, in the case of a single SSM or SPT tree, the total amount of message processing across all nodes depends linearly on the number of PEs in the VPN when a PE joins such a tree.
「PIM LAN手順」アプローチの場合、単一のSSMまたはSPTツリーの場合、すべてのノードにわたるメッセージ処理の合計量は、PEがそのようなツリーに結合するときのVPNのPESの数に直線的に依存します。
For the "BGP-based" approach:
「BGPベース」アプローチの場合：
o In the case of a single SSM tree, the total amount of message processing across all nodes is independent of the number of PEs, for "a new PE" joining and "a PE leaving"; it also depends on how route reflectors are meshed, but not on linear dependency.
o 単一のSSMツリーの場合、すべてのノードにわたるメッセージ処理の合計量は、「新しいPE」が結合し、「PEが去る」の場合はPESの数とは無関係です。また、ルートリフレクターのメッシュ化方法にも依存しますが、線形依存関係には依存しません。
o In the case of an SPT tree for an ASM group, BGP has additional processing due to possible Source-Active auto-discovery routes:
o ASMグループのSPTツリーの場合、BGPには、ソースアクティブな自動配置ルートの可能性があるため、追加の処理があります。
* When BGP-based C-multicast routing is used with inter-site shared trees, for the first PE joining (and the last PE leaving) a said SPT, the processing of the corresponding Source-Active auto-discovery routes results in a processing cost linearly dependent on the number of PEs in the VPN. For
* BGPベースのC-Multicastルーティングが敷地間共有ツリーで使用される場合、最初のPE結合（および最後のPEが出発する）の場合、SPTには対応するソースアクティブ自動配置ルートの処理が処理コストになりますVPNのPEの数に線形依存しています。為に
subsequent PEs joining (and non-last PE leaving), there is no processing due to advertisement or withdrawal of Source-Active auto-discovery routes.
その後のPESが結合（および非最後のPE出発）で、ソースアクティブの自動発見ルートの広告または引き出しのために処理はありません。
* When BGP-based C-multicast routing is used without inter-site shared trees, the processing of Source-Active auto-discovery routes for an (S,G) happens independently of PEs joining and leaving the SPT for (S,G).
* BGPベースのC-Multicastルーティングが敷地間共有ツリーなしで使用される場合、AN（S、G）のソースアクティブ自動ディスコービリルートの処理は、PESが結合してSPTを（S、G）に残すこととは独立して行われます。
In the case of a new PE having to join a shared tree for an ASM group G, we see the following:
ASMグループGの共有ツリーに参加しなければならない新しいPEの場合、次のことがわかります。
o The processing due to the PE joining the shared tree itself is the same as the processing required to set up an SSM tree, as described before (note that this does not happen when BGP-based C-multicast routing is used without inter-site shared trees).
o 共有ツリー自体に結合するPEによる処理は、以前に説明したように、SSMツリーをセットアップするために必要な処理と同じです（これは、BGPベースのC-Multicastルーティングが敷地間共有なしで使用される場合には発生しないことに注意してください。木）。
o For each source for which the PE joins the SPT, the resulting processing cost is the same as one SPT tree, as described before.
o PEがSPTに結合する各ソースについて、結果の処理コストは、前述のように1つのSPTツリーと同じです。
* The conditions under which a PE will join the SPT for a said (C-S,C-G) are the same between the BGP-based with inter-site shared tree approach and the PIM-based approach, and depend solely on the SwitchToSptDesired policy in the PIM instances in the customer routers in the sites connected to the PE and/or in the VRF.
* 前述の（C-S、C-G）のSPTにPEがSPTに参加する条件は、BGPベースの間でPIMベースのアプローチを備えたBGPベースと同じであり、PIMのSwitchToSptDesiredポリシーのみに依存しますPEおよび/またはVRFに接続されたサイトの顧客ルーターのインスタンス。
* The conditions under which a PE will join the SPT for a said (C-S,C-G) differ between the BGP-based without inter-site shared trees approach and the PIM-based approach.
* SPTのPEがSPTに参加する条件（C-S、C-G）は、敷地間共有ツリーアプローチなしでBGPベースのBATベースのアプローチとPIMベースのアプローチとの間で異なります。
* The SPT for a said (S,G) can be joined by the PE in the following cases:
* 前述の（s、g）のSPTには、次の場合にPEが結合できます。
+ as soon as one router, or the VPN VRF on the PE, has SwitchToSptDesired(S,G) being true
+ 1つのルーター、またはPEのVPN VRFがSwitchToSptDesired（S、G）が真であるとすぐに
+ when BGP-based routing is used and configured to not use inter-site shared trees
+ BGPベースのルーティングが使用され、敷地間共有ツリーを使用しないように構成されている場合
* Said differently, the only case where the PE will not join the SPT for (S,G) is when all routers in the sites of the VPN connected to the PE, or the VPN VRF itself, will never have SwitchToSptDesired(S,G) being true, with the additional condition that inter-site shared trees are used when BGP-based C-multicast routing is used.
* 別の言い方をすれば、PEがSPTの（S、G）のSPTに参加しない唯一のケースは、VPNの部位のすべてのルーター、またはVPN VRF自体がSwitchToSptDesired（S、G）を持たない場合です。真実であるため、BGPベースのCマルチキャストルーティングが使用されるときに、サイト間共有ツリーが使用されるという追加の条件があります。
Thus, when one PE joins a group G to which n sources are sending traffic, we note the following with regards to the dependency of the cost (in total amount of processing across all equipments) to the number of PEs:
したがって、1つのPEがNソースがトラフィックを送信しているグループGに参加すると、PESの数にコスト（すべての機器の合計処理量）の依存度に関して以下に注意してください。
o In the general case (where any router in the site of the VPN connected to the PE, or the VRF itself, may have SwitchToSptDesired(S,G) being true):
o 一般的なケース（PEに接続されているVPNのサイト内のルーター、またはVRF自体がSwitchToSptDesired（S、G）が真実である可能性がある場合）：
* For the "PIM LAN Procedure" approach, the cost is linearly dependent on the number of PEs in the VPN and linearly dependent on the number of sources.
* 「PIM LAN手順」アプローチの場合、コストはVPNのPESの数に直線的に依存し、ソースの数に直線的に依存します。
* For the "BGP-based" approach, the cost is linearly dependent on the number of sources, and, in the sub-case of the BGP-based approach used with inter-site shared trees, is also dependent on the number of PEs in the VPN only if the PE is the first to join the group or the SPT for some source sending to the group.
* 「BGPベースの」アプローチの場合、コストはソースの数に直線的に依存し、サイト間共有ツリーで使用されるBGPベースのアプローチのサブケースでは、PESの数にも依存します。VPNは、PEがグループに最初に参加した場合にのみ、グループに送信するソースのSPTに参加しました。
o Else, under the assumption that routers in the sites of the VPN connected to the PE, and the VPN VRF itself, will never have the policy function SwitchToSptDesired(S,G) being possibly true, then:
o それ以外の場合、VPNのサイト内のルーターがPEに接続されているという仮定と、VPN VRF自体は、ポリシー関数SwitchToSptDesired（S、G）がおそらく真実であることはありません。
* In the case of the PIM-based approach, the cost is linearly dependent on the number of PEs in the VPN, and there is no dependency on the number of sources.
* PIMベースのアプローチの場合、コストはVPNのPEの数に直線的に依存しており、ソースの数に依存しません。
* In the case of the BGP-based approach with inter-site shared trees, the cost is linearly dependent on the number of RRs, and there is no dependency on the number of sources.
* 敷地間共有ツリーを使用したBGPベースのアプローチの場合、コストはRRSの数に直線的に依存しており、ソースの数に依存しません。
* In the case of the BGP-based approach without inter-site shared trees, the cost is linearly dependent on the number of RRs and on the number of sources.
* 敷地間共有ツリーのないBGPベースのアプローチの場合、コストはRRの数とソースの数に直線的に依存します。
Hence, with the PIM-based approach, the overall cost across all equipments of any PE joining an ASM group G is always dependent on the number of PEs (same for a PE that leaves), while the BGP-based approach has a cost independent of the number of PEs. An exception is the first PE joining the ASM group for the BGP-based approach used without inter-site shared trees; in that case, there is a dependency with the number of PEs.
したがって、PIMベースのアプローチにより、ASMグループGに参加するPEのすべての機器の全体的なコストは、常にPEの数に依存します（残るPEの場合も同じ）、BGPベースのアプローチには独立コストがありますPESの数の。例外は、敷地間共有ツリーなしで使用されるBGPベースのアプローチのASMグループに参加する最初のPEです。その場合、PESの数に依存関係があります。
On the dependency with the number of sources, without making any assumption on the SwitchToSptDesired policy on PIM routers and VRFs of a VPN, we see that a PE joining an ASM group may induce a processing cost linearly dependent on the number of sources. Apart from this general case, under the condition where the
ソース数の依存関係については、VPNのPIMルーターとVRFに関するSwitchToSptDesiredポリシーについて仮定することなく、ASMグループに結合するPEがソースの数に直線的に依存する処理コストを誘導する可能性があることがわかります。この一般的なケースとは別に、
SwitchToSptDesired is always false on all PIM routers and VRFs of the VPN, then with the PIM-based approach, and with the BGP-based approach used with inter-site shared trees, the cost in amount of messages processed will be independent of the number of sources (it has to be noted that this condition depends on customer policy).
switchtoSptdesiredは、VPNのすべてのPIMルーターとVRFS、およびPIMベースのアプローチと、サイト間共有ツリーで使用されるBGPベースのアプローチで常に誤っています。ソースの（この条件は顧客ポリシーに依存することに注意する必要があります）。
(The following point was fixed in a draft version of the document that became [RFC6513] and is here for reference only.)
（次のポイントは、[RFC6513]になったドキュメントのドラフトバージョンで修正され、参照のみがここにあります。）
In early versions of the document that became [RFC6513], two approaches were proposed for how a source PE can decide when to start transmitting customer multicast traffic on a S-PMSI:
[RFC6513]になったドキュメントの初期バージョンでは、S-PMSIで顧客マルチキャストトラフィックの送信を開始するタイミングをソースPEがどのように決定するかについて、2つのアプローチが提案されました。
1. The source PE sends multicast packets for the (C-S,C-G) on both the I-PMSI P-multicast tree and the S-PMSI P-multicast tree simultaneously for a pre-configured period of time, letting the receiver PEs select the new tree for reception before switching to only the S-PMSI.
1. ソースPEは、I-PMSI P-MulticastツリーとS-PMSI P-Multicastツリーの両方で（C-S、C-G）のマルチキャストパケットを事前に構成された期間に同時に送信し、受信者PEに新しいツリーを選択できるようにしますS-PMSIのみに切り替える前の受信用。
2. The source PE waits for a pre-configured period of time after advertising the (C-S,C-G) entry bound to the S-PMSI before fully switching the traffic onto the S-PMSI-bound P-multicast tree.
2. ソースPEは、S-PMSIに縛られたP-Multicastツリーにトラフィックを完全に切り替える前に、S-PMSIにバインドされた（C-S、C-G）エントリを宣伝した後、事前に構成された期間を待ちます。
The first alternative had essentially two drawbacks:
最初の選択肢には、本質的に2つの欠点がありました。
o (C-S,C-G) traffic is sent twice for some period of time, which would appear to be at odds with the motivation for switching to an S-PMSI in order to optimize the bandwidth used by the multicast tree for that stream.
o （C-S、C-G）トラフィックは一定期間2回送信されます。これは、マルチキャストツリーが使用する帯域幅をそのストリームに最適化するために、S-PMSIに切り替える動機と対立するように思われます。
o It is unlikely that the switchover can occur without packet loss or duplication if the transit delays of the I-PMSI P-multicast tree and the S-PMSI P-multicast tree differ.
o I-PMSI P-MulticastツリーとS-PMSI P-Multicastツリーの輸送遅延が異なる場合、パケットの損失や複製なしでスイッチオーバーが発生する可能性は低いです。
By contrast, the second alternative has none of these drawbacks and satisfies the requirement in Section 5.1.3 of [RFC4834], which states that "a multicast VPN solution SHOULD as much as possible ensure that client multicast traffic packets are neither lost nor duplicated, even when changes occur in the way a client multicast data stream is carried over the provider network". The second alternative also happens to be the one used in existing deployments.
対照的に、2番目の代替案にはこれらの欠点がなく、[RFC4834]のセクション5.1.3の要件を満たしています。クライアントのマルチキャストデータストリームがプロバイダーネットワーク上に運ばれる方法で変更が発生した場合でも」。2番目の選択肢は、既存の展開で使用されるものでもあります。
Consistent with this analysis, only the second alternative is discussed in [RFC6513].
この分析と一致して、[RFC6513]で2番目の代替案のみが議論されています。
Authors' Addresses
著者のアドレス
Thomas Morin (editor) France Telecom - Orange 2 rue Pierre Marzin Lannion 22307 France EMail: thomas.morin@orange.com
トーマス・モリン（編集者）フランステレコム - オレンジ2 rueピエールマルジンラニオン22307フランスメール：thomas.morin@orange.com
Ben Niven-Jenkins (editor) BT 208 Callisto House, Adastral Park Ipswich, Suffolk IP5 3RE UK EMail: ben@niven-jenkins.co.uk
Ben Niven-Jenkins（編集者）BT 208 Callisto House、Adastral Park Ipswich、Suffolk IP5 3RE UKメール：ben@niven-jenkins.co.uk
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: y.kamite@ntt.com
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura、Minato-Ku Tokyo 108-8118日本メール：y.kamite@ntt.com
Raymond Zhang Alcatel-Lucent 777 Middlefield Rd. Mountain View, CA 94043 USA EMail: raymond.zhang@alcatel-lucent.com
Raymond Zhang Alcatel-Lucent 777 Middlefield Rd。Mountain View、CA 94043 USAメール：raymond.zhang@alcatel-lucent.com
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21-27 10781 Berlin Germany EMail: n.leymann@telekom.de
ニコライ・レイマン・ドイツ・テレコム・ウィンターフェルドストラセス21-27 10781ベルリン・ドイツメール：n.leymann@telekom.de
Nabil Bitar Verizon 60 Sylvan Road Waltham, MA 02451 USA EMail: nabil.n.bitar@verizon.com
Nabil Bitar Verizon 60 Sylvan Road Waltham、MA 02451 USAメール：nabil.n.bitar@verizon.com