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
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6517.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
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で、「C-」および「P-」の表記は、プロバイダの範囲および特定のVPN顧客の範囲の間で明確にするために使用されます。 「P-PIM」は、最終的にPとPEルータ間のコアの両端のプロバイダによって展開PIMのインスタンスを指定するだろうが、例えば、「C-PIM」は、VPNまたはVRFにおいてPIMプロトコルインスタンスを指定します。
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
GRE O：総称ルーティングカプセル化
o mLDP: Multicast LDP o I-PMSI: Inclusive Provider Multiservice Interface
MLDP O：I-PMSI OマルチキャストLDP：込みプロバイダーマルチサービス・インターフェース
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
それはB-PIMです：双方向PIM
o AS: Autonomous System
O AS：自律システム
o ASBR: Autonomous System Border Router
O ASBR：自律システム境界ルータ
o VRF: VPN Routing and Forwarding
VPNルーティングおよびフォワーディング：VRF O
o PE: Provider Edge
PE：プロバイダーエッジ
o CE: Customer Edge
OのCE：カスタマーエッジ
o RPA: Rendezvous Point Address
O RPA：ランデブーポイントアドレス
o RPL: Rendezvous Point Link
ランデブーポイントリンク：RPL O
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].
また、キーワードは "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、および "OPTIONAL" この中文書は、[RFC2119]に記載されているように解釈されるべきです。
The current solution document [RFC6513] proposes two different mechanisms for Multicast VPN (MVPN) auto-discovery:
現在のソリューションドキュメント[RFC6513]はマルチキャストVPN（MVPN）自動検出のための2つの異なるメカニズムが提案されています。
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ごとに共有P-トンネルで実装MI-PMSIを横切るC-PIMインスタンスによってPIMハローズの交換を通じて行わ発見（使用ASMまたはMP2MP LDP）
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".
マルチキャストVPNソリューションの動作が可能なような光、およびマルチキャストVPNソリューションを設計する際の優先順位であるべき自動構成および発見を提供するものでなければならない」と述べている[RFC4834]の両方のソリューションアドレスセクション5.2.10。特に、 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ベースの検出は、MI-PMSIをインスタンス化するために、共有P-トンネルを使用して展開にのみ適用可能であることである（それだけP2P、PIM-SSM、およびP2MP LDP / RSVP-TE P-トンネルがある場合に適用されません自動検出が行われている前にASMとMP2MP LDPに反して、P-トンネルのこれらのタイプを構築することが起こることができないので、使用されます）。対照的に、BGPベースの自動検出を使用しなければならないP-トンネルのタイプの任意の制約を置きません。 BGPベースの自動検出は、従って、「マルチキャストVPNソリューションは、そのコントロールように設計されるべきであり、転送プレーンは相互に依存しない」という[RFC4834]のセクション5.2.4.1に要件を満たす、使用されるP-トンネルのタイプとは無関係です。
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.
さらに、それはサービスプロバイダーの数は、したがって、いくつかのBGPベースの自動発見にすでに頼って、自分の現在の展開内のデフォルトのマルチキャスト配信ツリーのための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-トンネルが使用される場合また、BGPの自動検出の使用は、共有P-トンネルに使用されるアドレス/識別子の不整合を検出することを可能にする（例えば、同じ共有P-トンネル識別子は、異なるVPNに使用されています）異なるBGPルート・ターゲットを持ちます。これは、任意の設定ミスの影響が拡大することができ、ここで、単一のサービスプロバイダは、すべてのASを動作しないことがAS間VPNの文脈において特に魅力的です。いくつかの構成ミスのケースを検出するためのこの技術は共有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.（セクション7.4.2を参照）、具体的にS-PMSIシグナリングのためのUDPベースのTLVプロトコル
2. a BGP-based mechanism for S-PMSI signaling (described in Section 7.4.1)
2.（セクション7.4.1に記載）S-PMSIシグナリングのためのBGPベースのメカニズム
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サービス、彼らの間のバランスに比べて導入されている場合利点と運用の負担は「徹底的に調べるべきです。 （a）は、BGPを自動検出、および（b）の要件として識別されるので、UDPベースのメカニズムは、BGPベースS-PMSIスイッチング信号の場合ではないMVPNスタック内の追加プロトコルであろう手順シグナリング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.
BGPベースのプロトコルがないながらさらに、機構シグナリングUDPベースS-PMSIスイッチングは、MI-PMSIを必要とします。実際には、これはBGPベースS-PMSI切替シグナリングが使用される代わりに、それが遅れる可能性がありながら、UDPベースのプロトコルで、PEは、MVPN内のすべてのPEの全てP-トンネルに参加しなければならないことを意味しますその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ベースのアプローチは、セグメント化および非セグメント間の両方で優れたフィット感を提供する（セクション3.5を参照）に近づきます。対照的に、つつ、S-PMSIスイッチングシグナリングのためのUDPベースのアプローチは、セグメント間ASトンネルと共に使用可能であるように見える、セグメント化されたアプローチの重要な利点が失われます。
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のASは、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のASは、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オプションBのコンテキストでは、のASの単離は、一AS内のPEは、他のASののPEとのルーティング情報の（直接）交換を持っていないとして得られます。 UDPベースのS-PMSIスイッチングシグナリングが使用されている場合、このプロパティは保持されません。対照的に、BGPベースC-マルチキャストスイッチングシグナリングは、このプロパティを保存し。
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シグナリングアプローチの同じ独立される、S-PMSIトンネルシグナリングから生じるPとPEルータに影響を与えるであろう適切なメカニズムをアップ。
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の切り替えも、このプロトコルは、いくつかの時間のために展開されてきたことを考えると、オプションとして、考えることができます。両方のプロトコルをサポートする実装は、共存をサポートするために実装がために、特定のVRFのためのシグナリングS-PMSIスイッチング用UDPベースTLVプロトコルを使用できるように構成VRFごと（VPNルーティングおよび転送）ノブを提供することが期待されます両方のプロトコル（例えば、移行シナリオの間）。別に、このような移行促進のメカニズムから、著者らは、特にP-トンネルの新しい種類に既に提案UDPベースのTLVプロトコルを拡張することはお勧めしません。
The current solution document [RFC6513] proposes multiple mechanisms for PE-PE exchange of customer multicast routing information (C-multicast routing):
現在のソリューションドキュメント[RFC6513]は情報（C-マルチキャストルーティング）ルーティング顧客マルチキャストのPE-PE交換のための複数のメカニズムを提案しています。
1. Full per-MVPN PIM peering across an MI-PMSI (described in Section 3.4.1.1)
（セクション3.4.1.1を参照）MI-PMSIを横切る1フルごとMVPN PIMピアリング
2. Lightweight PIM peering across an MI-PMSI (described in Section 3.4.1.2)
（セクション3.4.1.2を参照）MI-PMSI横切っピアリング2軽量PIM
3. The unicasting of PIM C-Join/Prune messages (described in Section 3.4.1.3)
3. PIM Cは、参加のユニキャスト/プルーンメッセージ（セクション3.4.1.3を参照）
4. The use of BGP for carrying C-multicast routing (described in Section 3.4.2)
4. C-マルチキャストルーティングを実施するための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のコア要件の一つである、それはこのような観点から提案されているC-マルチキャストルーティングメカニズムを比較することが有用である：[RFC4834]のセクション4.2.4は、マルチキャストVPNソリューションは、マルチキャスト当たりのPEの数百をサポートすべきである」ことをお勧めします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数の増加とスケーラビリティも重要ですが、我々はこれらの問題のための様々なアプローチの違いを識別していなかったので、このセクションに焦点を当てされていません。他のすべてのものは、等しい、略直線PEごと及びVPN当たりマルチキャスト状態量とVPNの数に起因するC-マルチキャストルーティング増加するPEの負荷。
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マルチキャストルーティングのスケーラビリティに関する結論を提示します。付録Aは、PIMベースのアプローチとBGPベースのアプローチは、異なるアプローチで定量化状態の量の評価とメッセージとともに、C-マルチキャストルーティング負荷を処理する方法の違いに関するより詳細な説明を提供します。このセクションで作られた多くのポイントは、付録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.
マルチキャスト展開の高いスケールで、第一及び第三のメカニズムは、PEが（互いにPIMハローズの定期的な交換を意味する）同じマルチキャストVPNの他のPEとのPIM隣接関係の多数を維持するために、定期的にリフレッシュする必要がC-増加した処理コストをもたらす/プルーン状態に参加するときのPEの数が増加する（付録A.1に詳述されるように）。第2のアプローチは、このされにくい、および第四のアプローチは、この影響を受けません。
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によって維持されるように、「明示的なトラッキング」状態を必要とするPEの指定されたマルチキャストフローのC-参加/プルーン処理の量を減少させるであろう。また、「抑制への参加」のメカニズムと互換性がありません。このアプローチとシグナリングの量を低減することができる方法は、PIMリフレッシュ減速機構の使用であろう。 TCPに基づいて、このような機構は、PIM IETFワーキンググループ（[PIM-PORT]）で指定されています。マルチキャストVPNコンテキストにおけるその使用は、[RFC6513]に記載されていない、このアプローチがRRをなし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以外毎MVPNのPIMピアリング完全と同様に動作するとPIM Cは、参加/プルーン還元は、リフレッシュそれによって、スケーラビリティを向上させる、使用されるであろうが、このアプローチはまだ完全でなければなりません説明。いずれにせよ、唯一のPEの数が増加するとスケーラビリティに影響を与えるもののうち、一つのことを改善しているようです。
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 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.
第一及び第二のメカニズムは、「抑制に参加」挙動を利用し、従って上流PEの処理負担を改善する、各リモートPEがマルチキャストストリームに参加するための参加リフレッシュメッセージの処理を節約することができます。この改善は、彼らが上流PEであるか否かを同じマルチキャストVPNに参加している他のPEによって送信されたすべてのPIM参加及びプルーンメッセージを処理するためにマルチキャストVPNのすべての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.
第四の機構（C-マルチキャストルーティングを実施するためのBGPの使用）は、特定上流PEの興味深いBGP C-マルチキャストルートを処理するすべてのPEを必要と同等の欠点を有することになります。この理由のために、[RFC6514]のセクション16は、ルートターゲットの使用は、興味の上流PEはBGP C-マルチキャストルートを受信するだけ有することによって、この欠点を解消BGP分布[RFC4684]メカニズム、制約をお勧めします。ルートターゲットは、BGP分布が使用されている拘束場合具体的には、第四の機構が接合されていないどちらも「無関係」のPEに関するルーティング情報を顧客マルチキャストのいずれかの処理を回避することにより、PEの上に置くC-マルチキャストルーティング処理負荷の総量を減少させます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.
また、第四の機構は、さらに、顧客のマルチキャストに関連する処理負担の一部をオフロードするための手段を提供し、定期的なリフレッシュの使用を回避することによって、インスタンスのためのスケーラビリティを（改善することが期待されているBGP機能を継承することによって、メッセージ処理負荷の総量を減少させます一つまたは多数のBGPルートリフレクタ）にルーティングします。 PEの数と状態線形の量を維持するためのコストで来る第四の機構の利点は、ストリームに参加しました。しかし、ルートリフレクタの使用は、すべて、この状態を維持するために、単一のルートリフレクタの必要性を排除し、このコストは、複数のルートリフレクタに分散されることを可能にします。
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:
それは、1つまたは複数のBGPルートリフレクタ（S）上に顧客マルチキャストルーティング処理をオフロードする可能性を提供するという点で、しかし、第四のメカニズムが特異的です。これを使用する場合、ルートリフレクタインフラストラクチャ上に配置された処理負荷を増大させるという欠点があります。より高いスケールのシナリオでは、例えば、使用して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
ユニキャストおよびマルチキャストVPNルーティングのためのリソースの分離O：専用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 according to the need of that service (but doing so is not required and is left as an operator engineering decision).
最も簡単な方法は、（必要とされず、オペレータエンジニアリング決定として残されているが、そうすること）MVPNサービス専用のルートリフレクタの導入を検討し、それらがそのサービスを必要に応じて寸法を記入することです。
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-マルチキャストルーティングのPE-CE交換に関連するオーバーヘッドは、PE-PE C-マルチキャストルーティングに使用される機構の選択とは無関係です。したがって、システム全体のスケーラビリティ上のPE-CEのC-マルチキャストルーティングのオーバーヘッドの影響は、PE-PEシグナリングのために使用されるプロトコルとは無関係であり、したがって、関連しないPE-PE C-マルチキャストルーティングのために提案された別のアプローチを比較した場合。これは、いくつかの動作状況において、PE-CE Cマルチキャストルーティングのオーバーヘッドがシステム全体のオーバーヘッドで重要な要因である場合も同様です。
The first and second mechanisms are restricted to use within multicast VPNs that use an MI-PMSI, thereby necessitating:
第一および第二のメカニズムは、それによって必要、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
共有P-トンネル（例えば、ASMモードでPIM-SMまたはMP2MP LDP）可能P-トンネル技術を用い、O、又は
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.
でもそのVPNのためのそれらの直接結合部位にソースを持っていないのPE用のVPN当たりPEごとに1つのPトンネルの使用、O。
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).
比較により、第四の機構は、これらの制限のいずれかを課さないと、P2MP P-トンネルが使用される場合、唯一のマルチキャストソースまたはランデブーポイント（RPを有する部位に結合PEごとにVPNごとに1つのPトンネルの使用を必要と）（または候補ブートストラップルータ（BSRと）、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]).
PEの総数よりもソースに接続された少数のPEが存在する場合には、第四の機構は、P2MP P-トンネルと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].
ユニキャストAS間VPNオプションとの共存、およびインターASコンテキストで含むマルチキャストおよびユニキャストのセキュリティの等しいレベル、具体的にはセクション5.2.6と[RFC4834]の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オプションBのコンテキストでは、のASの単離は、一AS内のPEは、他のASののPEとのルーティング情報の（直接）交換を持っていないとして得られます。 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-マルチキャストルーティングが使用されます。対照的に、第四のオプション（BGPベースC-マルチキャストルーティング）は、このプロパティを保持し。
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-マルチキャストルーティングのために提案されているBGPベースのアプローチは、両方のセグメント化および非セグメント化AS間アプローチと優れたフィット感を提供することに注意してください。 PIMベースのC-マルチキャストルーティングは、セグメント化されたAS間トンネルで使用可能であるかのようにPEは、他のすべてのPEのC-マルチキャストルーティング活動を見るのでこれに対し、アプローチの間ASスケーラビリティの利点が失われます他のすべてのASの。
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は、イントラASまたはAS間の通信のためのかどうか、それによって、おそらく直接マルチキャストVPNの顧客マルチキャストルーティングの恩恵を受け、追加のセキュリティのためのピアのMD5認証をサポートしています。 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-マルチキャストルーティング機能は、特に荷重下で、ユニキャストルーティングインフラストラクチャと競合します。 PIMベースのアプローチを用いて、ユニキャストおよびマルチキャストVPNルーティング機能のみ、制御プレーン処理資源のために、PEに競合することが予想されます。 BGPベースのアプローチの場合、彼らは（彼らはMVPNのルーティングのために使用されると仮定）処理リソースおよびルートリフレクタでPEに競合します。両方の場合において、機構は、リソース（例えば、処理の優先順位）を調停するために必要とされるであろう。 PIMベースの手順の場合には、この調停は、PEの異なる制御プレーンルーティングインスタンス間で発生します。 BGPベースのアプローチの場合、これは、（例えば、専用MVPN BGPルートリフレクタの使用または既存のルートリフレクタとの別個のセッションを使用することによって）マルチキャストおよびユニキャストのために別個の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]と組み合わせて使用第四のアプローチは、（BGPベースの）独立した操作を残す/参加のためのコストを有する唯一のものですVPN内のPEの数の（内の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ベースのアプローチは、ドロップすることにより、このような負荷に反応します障害回復とのメッセージは、メッセージの更新を経て得られました。 PIMベースのアプローチは、増加した参加/離脱待ち時間をもたらし得るつつ、BGPベースのアプローチは、/参加典型的には、その期間に接合されるすべてのマルチキャストストリームに均等に広がるレイテンシ性能を残すの劣化につながる可能性がいくつかのランダムなストリームの（例えば、数十秒）、そしておそらくいくつかの状態のリフレッシュとの間の時間の倍数で、隣接関係は、マルチキャストストリームの破壊をもたらす、タイムアウトしてもよいです。
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).
実際には、「均等に分散分解」との両方が問題となり、どのような重要と思われるが（A）によって誘発することができるマルチキャストルーティング活動の量を制限するために、VPNバックボーンオペレータの能力であることができ、「不均一大きな劣化を広げます」マルチキャストVPNの顧客および（b）は、別々のVPN間可能な限り最高の独立性を提供します。これらの両方はローカル実装の改善によって対処することができると思わとBGPベースおよびPIMベースのアプローチを提供するように設計することができ、両方は、（a）および（b）。それにもかかわらず、（BGPアプローチはC-マルチキャストルートの引き出し及び/又は広告を減衰させる方法が提案されていることにも注目し、従って既に同等のものはまだPIMベースのアプローチのために記載されていないが、（A）を提供する方法を説明することができますそれは）難しくは表示されません。 PIMベースのアプローチは、MVPN制御プレーンを運ぶために、従って、（B）を解決するために、分離のこの第一レベルから利益を得ることができるあたり-VPNデータプレーンに依存しています。
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 the first packet of the corresponding multicast stream being received by the CE.
[RFC4834]のセクション5.1.3と述べ、「グループの遅延に参加[...]また一つの重要なQoSパラメータと考えられている。したがって、マルチキャストVPNソリューションは、この点で適切に設計することが推奨されます」。マルチキャストVPNコンテキストでは、対象のPIMそのPEと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-マルチキャストルーティング手順は、グループのみに影響を与えることに留意すべきであるマルチキャストソースに接続されたPE（または最初の<N>受信機からプロバイダバックボーンを横切って配置される第1の受信機のための前記マルチキャストストリームの待ち時間を結合します可能特定上流側のマルチキャストホップ選択アルゴリズムが使用される特定の場合には、<n>は別個のPE）が異なる下流の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).
分解条件（パケットロス、輻輳、または高い制御プレーン負荷）PIMベースのアプローチ全か無かの方法で所与のマルチキャスト・ストリームの待ち時間に影響を与える可能性がアンダー（O）C-マルチキャストルーティング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.
BGPベースのアプローチは、BGPおよびTCP実装に応じて、追加の遅延を導入することができるが、典型的には比較的低い増加、劣化条件（例えば、パケットロス、輻輳、または高いコントロールプレーンの負荷）の下で、生じるであろうTCP交換を使用してoをレイテンシーのストリーム間でより均等に分散。
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.
付録Aに示されるように、それは（ストリームに対して上流PEにこの負荷をかけることなく）全てのPEからの荷重を除去することで、O、BGPベースのアプローチは、特定のです。 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 / RR性能の必要性がマルチキャスト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-マルチキャストは、レイテンシが、制御プレーン上に置く全体的な負荷によって影響され、C-マルチキャストルーティングアプローチのスケーラビリティを考慮することであるジョイン。セクション3.3.1および付録Aで説明したように、BGPベースのアプローチは、より高いスケールのシナリオでの待ち時間に参加それによってグループに恩恵をもたらす、VPN当たりのPEの数の増加で最高のスケーラビリティを提供します。
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.
第一及び第四のアプローチは、C-マルチキャストルーティングに関連する候補です。理論的な観点から比較は第四のアプローチにおいていくつかの利点の同定、ならびに可能な欠点につながります。実用的な観点から比較を行うことが困難である。のみ減少展開およびインプリメンテーション情報が第四のアプローチのために利用可能であるので、利点は、複数の展開を通じて適用され、運用生存可能であることが示されている第一のアプローチで見られます。
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.
また、第1機構（MI-PMSI横切っピアリングフルごとMVPN PIM）は[RFC6037]で使用されるメカニズムです。そのため、それが展開され、今日MVPNsで動作しています。第四のアプローチは、又は前記展開のために好適で終わるしてもしなくてもよいが、第一のアプローチは、しばらくの間、展開されているので、このメカニズムのサポートはどのような場合にメカニズムを使用して配置から最終的な移行を容易にするために役立つであろう最初のアプローチがあります。
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.
したがって、現時点では、実装は、（フルごとMVPN PIMピアリング）メカニズム第（BGPベース）と第1の両方をサポートすることが推奨されます。いくつかのベストプラクティスを定義することができます前に、第四のアプローチの展開にさらなる経験が必要とされています。一方で、この勧告は、この選択は、ベンダーの実装の選択に制約されることなく、第一及び第四のメカニズムの間で選択するために、サービスプロバイダを可能にします。サービスプロバイダも考慮に異なる要因の重量を熟考してアカウントに独自の展開コンテキストの特殊性を取ることができます。
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.
現在のユニキャストVPNの展開は、VPNサービスのプロバイダーコアを横切る輸送のための顧客のパケットをカプセル化するためのLDP、RSVP-TE、およびGRE / IP-マルチキャストの様々なを使用しています。同じカプセル化は、ユニキャストおよびマルチキャストVPNトラフィックに使用できるようにするためには、マルチキャストVPN規格が実装は、彼らは、ユニキャストのために、どののサポートマルチキャストVPNおよびカプセル化のすべてのP2MP変異体およびシグナリングプロトコルをサポートすることをお勧めしなければならないことをお勧めしますいくつかのマルチポイント拡張は、MLDP、P2MP RSVP-TE、およびGRE / IPマルチキャストのように、定義されます。
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 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.)
上記のカプセル化技術のすべての3つは、P2MPマルチキャストP-トンネルの構築をサポートしています。また、MLDP及びGRE / IP-ASM-マルチキャスト実装もMP2MPマルチキャストP-トンネルの構築をサポートすることができます。 MP2MP P-トンネルの使用は、サービスプロバイダに、いくつかのスケーリングの利点を提供し得るような単一MP2MP P-トンネルは、このように大きさの順にPルータによって維持される必要があるマルチキャスト状態の量を減少させる、VPNごとに展開することが必要。 PEグループの後ろにソースとマルチキャストストリームのマルチキャストレシーバを持っていないサイトはまだVPNコア間で非最適な帯域幅の使用率につながる、そのようなストリームのパケットを受信しますので、状態のこのゲインは、帯域幅の最適化を犠牲にしています。考慮すべきことの一つは、MP2MPマルチキャストP-トンネルの使用は、いくつかの自動設定がMP2MP Pのために可能かもしれないことが指摘されている（全てのPEで同じP-トンネル識別子またはマルチキャストのASMグループアドレスを定義するために追加の設定が必要になるということです-tunnelsが、これは現時点では）自動検出手順によってサポートされていません。 （C-マルチキャストルーティングスキームは[RFC6513]に記載されていないことが指摘されている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.
入口PEは、ユニキャストトラフィックをサポートするために使用されるP2Pトンネル上の任意のマルチキャストトラフィックを複製することによりMVPNサービスはまた、入口PE複製の使用を介してユニキャストVPNコア上に支持することができます。このオプションは（プロトコルサポートの点で）既存の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に上流割り当てられたラベルのサポートを必要とするであろう。上流割り当てられたラベルのサポートは、PEのデータプレーン処理への変更を必要とするかもしれない、これは、サービスプロバイダが展開している特定のプラットフォームの集約PMSIトンネルの使用を考慮したサービス提供者によって考慮されるべきです。
There are a number of scenarios that lead to the requirement for inter-AS multicast VPNs, including:
相互ASマルチキャストVPNを、含むための要件につながる多くのシナリオがあります。
1. A service provider may have a large network that it has segmented into a number of ASes.
1.サービスプロバイダは、それがのASの数に分割している大規模なネットワークを有していてもよいです。
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は、他のサービスプロバイダーとの買収や合併へのASの数から構成されてもよいです。
3. A service provider may wish to interconnect its multicast VPN platform with that of another service provider.
前記サービスプロバイダは、別のサービスプロバイダのもので、そのマルチキャスト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.
ネットワークが完全に単一の戦略の下で、単一のサービスプロバイダによって管理されるため、各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.
戦略と技術、各ASのために作られた戦略と技術の選択肢が異なっていた可能性があるため、2つ目のシナリオは、その異なる歴史に最初よりも複雑であってもよく、サービスプロバイダは、統一されていない可能性があり（または統一したくないかもしれません）各ASの選択肢。
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.
第2のシナリオの複雑さに加えて、のASは、異なるサービスプロバイダによって管理され、従って、他のシナリオとは異なる信頼モデルを受けることができるので、第3のシナリオは最も複雑です。
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".
ユニキャストAS間VPNオプションA、B、およびCとの共存について[RFC4834]「溶液がインターASマルチキャストVPNをサポートしなければならない、と相互プロバイダマルチキャストVPNをサポートすべきである」と述べ、「考察のセクション5.2.6 （[RFC4364]のセクション10に記載されているように）強く推奨されている「および」マルチキャストVPNソリューションは、プロバイダ間の最小限の調整を必要とAS間のメカニズムを提供し、最小限にプロバイダのネットワークの詳細な知識の必要性を保つべきです - このすべてのユニキャストVPNオプション」対応と比較しています。
Section 8 of [RFC6513] addresses these requirements by proposing two approaches for MVPN inter-AS deployments:
[RFC6513]のセクション8は、MVPN 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).
マルチキャストトンネルが与えられたMVPNに属するPEが異なるのASであってもよいので、にもかかわらず、ASBRは、単にPルータなどの特別な役割と機能を果たしていない、のAS間でエンド・ツー・エンドのある1.非セグメント化されたAS間のトンネル（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).
各ASは、その後のASBRによって一緒に「縫合」され、それ自身の別個のマルチキャストトンネルを構築2.セグメント化インターASトンネル（セクション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.)
いわゆる「バック・トゥ・バック」のVRF - - このオプションは、このセクションでは考慮されていない、それは任意の相互AS-特定することなく使用することができることを考えると（AS間展開が代わりにオプションAに頼ることができることに注意してください機構。）
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も各サービスプロバイダの中で、サービスプロバイダは、（マルチキャスト）を運ぶために最も適切なトンネリングメカニズムを選択する自分自身でできるようにすべきである」、と述べたPE間のトラフィック（ ）」。セグメント化されたアプローチは、この要件を満たすことができる唯一のものです。
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].
セグメント化された相互ASソリューションは、事業者への導入の柔軟性の最大の度合いを提供するように思われます。しかし、非セグメント間ASソリューションは、シナリオの限られた数での展開を簡素化することができます。 [RFC6037]は唯一の非セグメント化されたAS間のソリューションをサポートしています。従って、非セグメント間AS溶液は、下位互換性のために、いくつかの演算子及び[RFC6513]と[RFC6037]から移行中に有用である可能性があります。
The following is a comparison matrix between the "segmented inter-AS P-tunnels" and "non-segmented inter-AS P-tunnels" approaches:
以下はと「非セグメント間AS P-トンネル」「インターAS P-トンネルセグメント化」アプローチの間の比較マトリックスであります
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のスケーラビリティ：アプローチ「インターAS P-トンネルセグメントは、」なぜなら1間に独自のAS内のI-PMSIために使用される複数のイントラAS P-トンネルを集約するASBRの能力を、よりスケーラブルであります-AS P-トンネルは、他のASによって使用されます。セグメント化されたP-トンネルが（以下の項目を参照）などのソースの粒度を有する場合アプローチ「インターAS P-トンネルセグメント化」によってもたらさ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.
S-PMSIs用Oスケーラビリティ：BGPベースC-マルチキャストルーティングアプローチで使用される「セグメント化されたインターAS P-トンネル」アプローチは、スケーラビリティを支援するために、帯域幅/状態のトレードオフの処理方法に柔軟性を提供します。実際、その場合には、下流ASに前記（CS、CG）のために作られたトレードオフは、上流の能力のおかげで、1つを集約するなどの隣接製トレードオフよりもスケーラビリティに有利に製造することができます下流AS内の1つのI-PMSIトンネル内AS上流の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.
ASBRはでO構成：「セグメント化された相互AS P-トンネル」アプローチ「は、非分節間などのASBRで、それぞれ同じまたは追加の設定が必要になり、ASセグメント化P-トンネルはソースASBRまたはソースの細かさを持っているかどうかに応じて、 -AS P-トンネル」のアプローチ。
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.
別のAS 1からトンネリング技術の自立O：「セグメント化された相互AS P-トンネル」のアプローチはこれを提供します。 「非セグメント間AS P-トンネル」のアプローチはしていません。
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との共存を容易にし、そしていくつかのシナリオでは、既存の展開と軽いエンジニアリング、からの移行：「非セグメント間AS P-トンネル」のアプローチはこれを提供します。 「セグメント化間AS P-トンネル」のアプローチはしていません。
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間のトンネルの適用は、各サービスプロバイダに固有の多数の要因に依存するであろう。しかし、上記思い出し異なる要素を考えると、それはすべての実装は、セグメント化された相互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では、パケット転送ルールは、トラフィックがRPAに向けて共有ツリーを渡すことができるように、PIM-SMの上に改善されています。マルチキャストパケットのループを回避するために、BIDIR-PIMはメカニズムがRPAをルートとループフリーツリーを確立し、指定フォワーダ（DF）選挙と呼ばれる使用しています。この方法を使用すると、すべてのパケットのコピーは1つだけRPAに平行等コストパスがあっても、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におけるマルチキャストのVRFがC-するルーティングの一貫したビューを持っていない場合など、同様にパケットのループを回避するこの特性を保持しなければなりませんRPL / C-RPA（双方向顧客PIMインスタンスのカスタマー-RPL /顧客-RPA、すなわち、RPL / RPA）。
Section 11 of the current MVPN specification [RFC6513] defines three methods to support BIDIR-PIM, as RECOMMENDED in [RFC4834]:
[RFC4834]に推奨されているように、現在のMVPN仕様のセクション11 [RFC6513]は、BIDIR-PIMをサポートするために3つのメソッドを定義しています。
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-マルチキャストルーティングのために、「フルごとMVPN PIMはMI-PMSI横切っピアリング」を使用して展開に適用されるが、[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）は、PEの間で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 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.
この方法は、（2）BIDIR-PIMで、RPLに必要とされていないDF選定の手順を実行しているという事実を利用しています。このアプローチは、このように特にBGPベースC-マルチキャストルーティングが使用される文脈において、実装の単純さの利点を有しています。しかし、それは常にMVPNの顧客の要件に一致しない可能性がある、BIDIR-PIMが展開される方法に制約を置くという欠点があります。
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）、マルチキャストのVRFのセットの集合体としてC-RPAが、他のセット内のPEとは別個に向かって同一の到達可能性情報を有するセット内のすべてのPEをMVPNを扱います。従って、この方法では、MVPNにおけるC-双方向パケットループのVRFの互いに素な集合にVPNを分割する能力によって解決され、各々は、統合ネットワークの異なるビューを有します。 BIDIR-PIMに分割アプローチは、上流割り当てられたMPLSラベル（パーティションを意味する）、またはパーティションごとに固有MP2MPのLSPのいずれかを必要とします。前者は自動検出BGPルートを使用して配信されなければならないPE弁別ラベルに基づいて、その取り扱いは、上流割り当てられたラベルとコンテキストラベルルックアップ[RFC5331]のサポートを必要としています。後者は、パーティションごとMP2MP LSPを使用して、これらの制約を持たないが（例えばMLDP [RFC6388]など）MP2MP接続をサポートする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-双方向へのこのアプローチは、PIMベースまたはBGPベースのC-マルチキャストルーティングの手順で作業し、それがBIDIR-PIMサービス提供上の任意の要件を課さないという意味でもジェネリックであることができます。
Given the above considerations, method (3) "Partitioned Sets of PEs" is the RECOMMENDED approach.
上記の考察を考慮すると、方法（3）「PEのパーティションセットは、」推奨されるアプローチです。
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バックボーンは、」中間溶液として推奨されている、（1）利点をオーバー有する（2）BIDIR-PIMが配備されている方法の制約とPIMベースのC-マルチキャストである場合にのみ適用可能であるという欠点を入れません使用され、おそらく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は、RP機能のエンジニアリングは、特定のプロトコルおよび関連する構成の展開を必要とし、ASMモードでPIM-SMの場合は」、述べています。サービスプロバイダーは、上の顧客のマルチキャストプロトコルの動作を管理するために提供することがあります彼らのために。。その結果、VPNソリューションは、「VRまたはVRFでのRP機能のホスティングをサポートするかもしれない（のPE上で、例えば）顧客のRPは外部委託しているケースを考慮する必要があることを意味します。
However, customers who have already deployed multicast within their networks and have therefore already deployed their own internal 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の制御を引き渡すと同じ場所に配置RPモデルを利用するために消極的である、とRP-提供しますPE上のコロケーションには、Multicast Source Discovery Protocol（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は、顧客のネットワークやCEの内に配備されています。
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]「間違ったPEから廃棄パケット」のセクション9.1.1に記載した手順をサポートすることが推奨されます。
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).
これは容易に達成されなくてもよい場合には、推奨されるアプローチは、いくつかの単位のVPN中断と移動を可能にするPEデバイスによって使用される機構の増分ごとのVPNの移行を可能にする毎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 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.
所与のPEと所定のVPNのための複数の代替の同時使用を提供することにより、「ライブ」マイグレーションを可能にするメカニズムは、そのような機構に関連した予想される実装の複雑さを考慮し、優先度と見られていません。彼らは生存可能に比較的簡単に実装できる場合があることが起こる場合は、そのようなメカニズムは、マイグレーション管理の改善に役立つことがあります。
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両方のBGPベースとごとMVPN PIMは、両方のソリューションで得られる更なる運転経験するまで顧客マルチキャストルーティングのPE-PE交換のためのソリューションをピアリングいっぱい。
o that implementations use the "Partitioned Sets of PEs" approach for BIDIR-PIM support;
実装はBIDIR-PIMをサポートするためのアプローチ「PEのパーティションセット」を使用し、O。
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;
実装は、このようなMLDP、P2MP RSVP-TE、およびGRE / IP-マルチキャストとして、彼らはすでに実装P2PプロトコルのP2MPバリアントを実装し、O。
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);
その実装サポートはAS間トンネルをセグメント化（下位互換性を維持し、移行のために）非セグメントAS間のトンネルをサポート検討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
PIMのRP機能（PIM登録処理およびRP-特定PIM手順）またはVRF MSDPインスタンスの活性化は、任意のPEルータで必要とされない場合に実装が展開をサポートしなければならないOであり;そして
o that implementations support the procedures described in Section 9.1.1 of [RFC6513].
実装は[RFC6513]のセクション9.1.1に記載した手順をサポートO。
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.
私たちは、この文書を形作る助けた彼らのフィードバックのためのエードリアンファレル、エリック・ローゼン、ヤコフ・レックター、そしてマリアNapieralaに感謝したいと思います。
Additional credit is due to Maria Napierala for co-authoring Section 3.6 on BIDIR-PIM Support.
追加のクレジットはBIDIR-PIMサポートの共同オーサリングセクション3.6のためのマリアNapieralaによるものです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, February 2012.
[RFC6513]ローゼン、E.、エド。そして、R.アガルワル、エド。、 "MPLSにおけるマルチキャスト/ BGP IP VPN" を、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]アガルワル、R.、ローゼン、E.、モリン、T.、およびY. Rekhter、 "BGPエンコーディング及びMPLS / IP VPNのBGPにおけるマルチキャストのための手順"、RFC 6514、2012年2月。
[MVPN] Aggarwal, R., "Base Specification for Multicast in BGP/ MPLS VPNs", Work in Progress, June 2004.
[MVPN]アガルワル、R.、 "BGP / MPLS VPNの中のマルチキャストのためのベース仕様"、進歩、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]ファリナッチ、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]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、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]マルケス、P.、Bonica、R.、牙、L.、マティーニ、L.、Raszuk、R.、パテル、K.、およびJ.ギシャール、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングのための制約経路配信（BGP / MPLS）インターネット・プロトコル（IP）、仮想プライベートネットワーク（VPN）」、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]モリン、T.、エド。、 "レイヤーでのマルチキャストのための要件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]アガルワル、R.、Rekhter、Y.、およびE.ローゼン、 "MPLS上流ラベルの割り当てとコンテキスト固有のラベルスペース"、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]は、RFC 5796、2010年3月アトウッド、W.、イスラム教、S.、およびM. Siami、 "プロトコル独立マルチキャストスパースモード（PIM-SM）リンクローカルメッセージでの認証と機密性"。
[RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, October 2010.
[RFC6037]ローゼン、E.、カイ、Y.、およびIJ。 Wijnands、 "BGP / MPLS IP VPNのでマルチキャストのためのシスコシステムズのソリューション"、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。、Minei、I.、Kompella、K.、およびB.トーマス、2011年11月、RFC 6388の "ポイントツーマルチポイントのラベル配布プロトコルの拡張機能と多対多ラベルは、パスの交換しました" 。
Appendix A. Scalability of C-Multicast Routing Processing Load
C-マルチキャストルーティング処理負荷の付録A.スケーラビリティ
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のためにそれ自体では十分ではありません：それはまだのための受信機を持っている任意の他の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-マルチキャストルーティング」ビルディングブロックを設計することができ、そして、彼らはそれが他のPEに向けて言ったマルチキャストストリームの転送を停止することができたときに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の手順は、デフォルトでは、デフォルトでは、PIM LANの手順が使用された場合、マルチキャストツリーからLANプルーン自体のPEは、そのLAN上の他のすべてのPEは、知られているに自分の状態を確認するとき、その場合には彼らはプルーンを上書きするために、そのLAN上のPIM Joinメッセージを送信します。このように、各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ルートリフレクタが使用されていない場合、BGPベースC-マルチキャストルーティング「最後受信機は残したのか？」質問は、上流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 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).
BGPルートリフレクタは（推奨されるアプローチであることが期待されている）を使用する場合しかし、前記マルチキャストツリーの一部であるPEの更新されたリストを維持する役割は、ルートリフレクタ（S）での世話をされています。このルートをアドバタイズする顧客のPEの何がもはや存在したときに、このルートを撤回しません前に、他のルートリフレクタに（C-G、C-S）BGPの手順を用いて、C-マルチキャストソースツリーを広告していたルートリフレクタが言ったのルートに参加しましょう。その（他の）クライアントのPEとそのルートリフレクタピアは、もはやこのルートをアドバタイズしている場合も同様に、前にそのクライアントのPEにこのルートをアドバタイズしたルートリフレクタは、このルートを撤回しません。この文脈では、「最後の受信機は残したのか？」質問は、ルートリフレクタ（S）で回答すると言うことができます。
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ルート分布は、複数のルートリフレクタを利用することができる：複数のルートリフレクタは、これらのルートリフレクタ間（クライアントとして）分散されたPEで使用される場合、「最後の受信機は残したのか？」質問は、部分的にこれらのルートリフレクタのそれぞれで答えています。
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-マルチキャストルーティングのビルディングブロックは対処するがある仕事の一部であることを見ることができ、そして異なるアプローチが大きく異なります。 C-マルチキャストルーティングを処理するための異なるアプローチは、実際に処理し、どのようにこの処理は、異なる機能の中で広がっているの異なる量をもたらすことができます。これらの違いは、より良いメッセージ処理と状態維持の量を定量化することによって推定することができます。
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の制御プレーンメモリに保持され、「状態を維持しました」それが存在するプロトコル、例えば、2回存在する場合、両方のPIM状態とBGPルートとして）。ここで私たちが選択したさまざまなオプションの間で変動していないでしょうPEルータ上のデータプレーンの状態を比較していないことに注意してください。
A.1. Scalability with an Increased Number of PEs
A.1。 PEの数が増えるとスケーラビリティ
The following sections evaluate the processing and state maintenance load for an increasingly high number of PEs in a VPN.
以下のセクションでは、VPNにおけるPEのますます高い数の処理および状態メンテナンス負荷を評価します。
A.1.1. SSM Scalability
A.1.1。 SSMのスケーラビリティ
The following subsections do such an estimation for each proposed approach for C-multicast routing, for different phases of the following scenario: o One SSM multicast stream is considered.
一つSSMマルチキャストストリームがあると考えられる（O）次のサブセクションでは、以下のシナリオの異なる相のC-マルチキャストルーティングのための各提案されたアプローチ、このような推定を行います。
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ケースが懸念される（セグメント化されたAS間のトンネルおよびBGPベースC-マルチキャストルーティングと、#mvpn_PEと#R_PEはASでMVPNのPEへ、ない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の数が続く、マルチキャストストリーム（なぜなら、新しい受信機に接続されたサイトは、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.
*すべてのPEは、最後の1葉まで、次々に残します。我々は、各PEの休暇のために必要な処理を評価します。
o The parameters used are:
oを使用するパラメータは以下のとおりです。
* #mvpn_PE: the number of PEs in the MVPN
* #mvpn_PE：MVPNにおけるPEの数
* #R_PE: the number of PEs joining the multicast stream
* #R_PE：マルチキャストストリームに参加するPEの数
* #RR: the number of route reflectors
* #RR：ルートリフレクタの数
* 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」（または「私」）である：一つの「message.equipmentは」an「は、1つの機器処理つのメッセージ」に対応する（10 Me「はそれぞれ一つのメッセージを処理する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).
考えマルチキャストストリームのための上流PE、RR（もしあれば）、及び（上流PEではない）他のPE：我々は、3つの異なる機器の種類を区別する。
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ハローズの負荷を容易に別々に計算され、唯一の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.
BGPのO、C-マルチキャストソースツリーのすべての広告や引き出しは、ルートに参加（出典アクティブ自動検出ルートが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-マルチキャストルーティングのために提供されるすべてのオプションについては、設定およびSSMグループのソースに向かって最短経路ツリーを維持するための手順は、セットアップおよびRPに向かって最短経路ツリーを維持するために使用される手順と同じであることに注意してくださいまたは非SSM源と、このセクションの結果は、このように付録A.1.2に再使用されています）。
A.1.1.1. PIM LAN Procedures, by Default
A.1.1.1。デフォルトでPIM LAN手続き、
+------------+------------+---------------+----------+--------------+
| | 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メッセージの数にバインドされています。
A.1.1.2. BGP-Based C-Multicast Routing
A.1.1.2。 BGPベースのC-マルチキャストルーティング
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）を使用することを前提としない、およびRRのいかなる階層（分析はまた、ルートターゲット制約メカニズムが使用されることを想定しています）。
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-マルチキャストルートを運ぶメッセージは、そのクライアントとしてそのPEを有するのRRによって処理される必要があるであろう。ルートターゲット制約メカニズム[RFC4684]を使用することに起因し、これらのRRは、クライアントとして上流のPEを有する唯一のRRにこのメッセージを送信することになります。他のPEの他のRRのどれとどれもがこのメッセージを受信しません。したがって、所与MVPNに関連付けられたメッセージのために、このメッセージを処理する必要があるRRの総数は、そのMVPNのためのC-マルチキャストルートを維持RRの数に依存し、それは、受信機に接続されたPE又はいずれかを有しますソースに接続された顧客としてPEおよびRRの総数またはPEの総数とは無関係です。
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を典型的に有するであろう）のクライアントであろう。 （下流PEと上流PEの両方が同じRRのクライアントである場合は2つのRRS）したがって、実際にはメッセージは、最大4つのRRによって処理される必要があるであろう。異なるRRクラスタ内のRRは、完全な内部BGP（iBGPの）それらの間でメッシュ、上流PEが受ける含まRRクラスタ内の各RRを持っているのでこのように、与えられたメッセージを処理する必要がRRの数は最大で4です。下流PEを含んRRクラスタ内のRRのそれぞれからのメッセージ。クラスタあたり2つのRR与えられ、すべてのRRが処理したメッセージの総数は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-マルチキャストルートを処理RRの数（RRSにピアリングPEが冗長化されることを考慮して）2に向かって迅速になる傾向があります。
+------------+----------+--------------+-----------+----------------+
| | 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.
回数上流PEのクラスタのRRを再宣伝C-マルチキャスト（C-S、C-G）の経路に必要であるOのような多くの「message.equipment」Sは上流PEです。前記（ルートターゲットに関連するVPN、CS、CG）のための上流PEの挙動以外の（経路によって運ばれる正確な属性に依存しないので、このような再広告は、上流のPEのために有用ではありませんルートターゲットは、もちろん）が、原因BGPはこれらのルートを処理する方法にはいくつかの場合に発生します。属性のセットが変更にも広告を掲載する場合は、現在の最高のパスが言ったNLRIのために変更したときに実際に、BGPピアは、おそらくルートを再アドバタイズします。
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:
C-マルチキャストルートの再広告が起こるとき、彼らが影響を与えることができたときに、Oさんが別の関連する属性を見てみましょうと。
* 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.
*ネクストホップおよび発信者番号：RRはC-マルチキャストを集約と同じNLRIとの経路が（それ自身のクラスタ内のPEから受け取ったため、新しいPE接合は、機械的に再アドバタイズCマルチキャストルーティングする必要性をもたらさないであろう[RFC6514]のセクション11.4）、RRはこれらの属性の値を書き換えます。しかし、上流PEのクラスタ内のRRとのピアリング別のRR製広告は、これらの属性の値の更新をもたらし得ます。
* 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.
*ローカル-県：この属性の値がローカルに決定されます。これは、両方の（すべてが同じ値を使用するように構成することができる）、各PEによってアドバタイズされたルートのために、彼のクラスタのPES（によってアドバタイズ同じNLRIのルートのRRによって凝集に起因する経路についても同様ですRRはまた、彼にアドバタイズされたルート）のLOCAL_PREFの地元県の独立を使用するように構成することができます。したがって、この属性はC-マルチキャストルートを再アドバタイズする必要性をもたらすと考えることができます。
* 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（インターAS、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別のクラスタ広告のRRの場合であろう上流PEに異なる属性を持つルートを再アドバタイズするRRを強制することができるものを前記C-マルチキャストソースツリー（S、G）NLRI参加のため、上記を考えるとそのせいでRR（ネクストホップ、発信元-ID、クラスタリスト）に固有ではなく、その背後にあるRRのPEに固有のもののための属性の値の現在の最良のルートより良いルート、。我々は（#R_PE -1）最初のPEは、接合後、他の後に語った（CS、CG）、1への参加を検討している場合、これらのイベントのいくつかは、このように、上流PEへの再広告につながるかもしれないが、数これが起こることができる時間が悪化に受信機を有するクラスタ内のRRの数（プラスため、ローカルクラスタのPEによって同じ経路の可能性のある広告のうちの1つ）です。
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私たちは、このセクション内のPE数の増加とスケーラビリティを見ていることを考えると、我々はすべてのクラスタが受信機とクライアントのPEを有することができる可能性を検討する必要があります。また、上流PEのクラスタの2つのRRがルートを再アドバタイズする必要があるかもしれないことを考慮する必要があります。これを念頭において、私たちは2倍＃のRRはみなさC-マルチキャストルーティングのために、上流のPEへのRRで行われた更新回数に上限であることを知っています。
A.1.1.3. Side-by-Side Orders of Magnitude Comparison
A.1.1.3。大小比較のサイドバイサイド受注
This section concludes the previous section by considering the orders of magnitude when the number of PEs in a VPN increases.
このセクションでは、大きさのオーダーを考慮して、前のセクションを終了するときVPN増加におけるPEの数。
+------------+--------------------------------+---------------------+
| | 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によって処理されるであろう。 PEの数が増加すると、受信機PEの割合が一定であると考えられる場合、結果として、プロセスへのメッセージの総数はO（#mvpn_PEが#R_PEをX）、すなわち、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（#R_PE）が、再分割が異なります。o州のメンテナンスはすべてのアプローチのために同程度の大きさです。
* The PIM-based approach fully spreads, and minimizes, the amount of state (one state per PE).
* PIMベースのアプローチは、完全に広がり、最小化状態の量（PEごとに一つの状態）。
* The BGP-based procedures spread all the state on the set of route reflectors.
* BGPベースの手順は、ルートリフレクタのセットのすべての状態を広げます。
A.1.2. ASM Scalability
A.1.2。 ASMのスケーラビリティ
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.
PEは、一般に、1つの共有ツリー、プラスGに向けて送信する各ソースに対して1つのソースツリーを維持しなければなりません。 PEの数が多い場合の処理と異なるアプローチの間の大きさの順に同じ違いが、付録A.1.1シナリオに記載されているものと同様の状態の維持の量で得られた各ツリー。
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常に偽）に切り替えないであろう場合に、この例外はある：その場合は、処理状態メンテナンス負荷は共有ツリーのメンテナンスに必要なものです。これは、このシナリオでは、顧客のポリシーに依存していることに留意しなければなりません。 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- *、CG）ASMグループに参加#R_PEs、の順に同じ差で使用することができ大きさは、真のまま。サイト間共有ツリーなしで使用BGPベースのアプローチの場合、我々は考慮にC-PIM共有ツリーを構築するという事実に起因する負荷を取る必要があり、各PEは、それぞれのソースにソースツリーに参加しなければなりません。付録A.1.1の表記法を使用して、これは#R_PEsに比例する負荷の量（すべての機器を横切る総荷重）とソースの数を加算します。 PEの増加数と大きさの順序は、このように変更されず、大きさの程度の違いも同じまま。
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:
加えて、木の維持に、PEは、マルチキャストグループへの送信個々のソースに関連するいくつかの処理及び状態維持を確保しなければなりません。関連する手順および動作は、主にC-マルチキャストルーティングプロトコルは、マルチキャストソース発見機構は、顧客のVPNに使用される方法、それが設定されている方法、使用、およびポリシーが使用さSwitchToSptDesiredれているかに応じて異なってもよいです。しかし、次のように観察することができます。
o When BGP-based C-multicast routing is used:
BGPベースC-マルチキャストルーティングを使用する場合○：
* 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のsource-active自動検出のルートを維持する必要があります。ソースアクティブ自動検出経路の数は、典型的には1つになりますが、次の場合には、上流側のPEの数に関連し得る：サイト間で共有ツリーが使用される場合、同時に複数のPEは、アップストリームPEとして使用されますSPT（CS、CG）木とサイト間で共有ツリーが使用され、この（S、G）のための上流可能である複数のPEが存在している場合。
* 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.
*これは、各ソースのためのメッセージ処理とVPN（#mvpn_PE）におけるPEの数に直線的に依存状態維持（すべての機器を横切って合計）をもたらす、PEの数の独立したグループに参加しました。
* 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:
PIMベースのC-マルチキャストルーティングを使用する場合、O、顧客ルータとの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.
*（S、G）に固有の可能性PIMアサートメッセージ。これは、各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.
上記を考慮すると、ソースと共有ツリーのメンテナンスを超え、グループへの送信の各個々のソースのために起こるかもしれない追加の処理は、上記識別された大きさの順序を変更しません。
A.2. Cost of PEs Leaving and Joining
A.2。 PEが出ると参加のコスト
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は、一度参加し、離脱したユースケースに基づいて行われます。受信機に接続されたPEのセットの変更の他のパターンについてスケーラビリティ関連結論を引き出すことを「新たな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内のPEの数に直線的に依存します。
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を残す」ため、PEの数とは無関係です。それはまた、ルートリフレクタはなく、線形依存で、噛み合っている方法によって異なります。
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 subsequent PEs joining (and non-last PE leaving), there is no processing due to advertisement or withdrawal of Source-Active auto-discovery routes.
処理中に前記SPT、対応するソースアクティブ自動検出ルート結果の処理を* BGPベースC-マルチキャストルーティングは、接合最初PEのために、サイト間共有ツリーで使用され（そして最後のPEは脱離） VPN内のPEの数に直線的に依存コスト。その後の接合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-マルチキャストルーティングがサイト間共有ツリーなしで使用された場合*、（S、G）のソースアクティブ自動検出ルートの処理が独立して、（S、G）のためのSPTを結合及び離脱PEの起こり。
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).
前に説明したように、共有ツリー自体を接合PEによる処理は、SSMツリーを設定するために必要な処理と同様であるO（BGPベースC-マルチキャストルーティングがサイト間なしで使用される場合、これは起こらないことに注意してください共有ツリー）。
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.
前述したようにPEがSPTに参加する各ソースについてoは、得られた処理コストは、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.
* PEは、前記（CS、CG）のためのSPTに参加する条件は、サイト間の共有ツリー手法とPIMベースのアプローチを用いてBGPベースの間で同じであり、内SwitchToSptDesiredポリシーにのみ依存しますPEに及び/またはVRFに接続されているサイトでは、顧客のルータでPIMインスタンス。
* 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.
* PEは、前記（C-S、C-G）のためのSPTに参加する条件は、サイト間共有ツリーアプローチとPIMベースのアプローチなしBGPベースの間で異なります。
* 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
+できるだけ早くのルータ、または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は（S、G）のためのSPTに参加しませんのみの場合は、PEに接続されているVPNのサイト内のすべてのルータ、またはVPN VRF自体は、S（GをSwitchToSptDesiredたことはなかっただろうときです）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に加入するときしたがって、我々は、PEの数に（すべての機器を横切って処理の合計量で）コストの依存性に関して、以下の点に注意してください。
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、またはVRF自体に接続されたVPNのサイト内の任意のルータが、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内のPEの数に直線的に依存し、ソースの数に直線的に依存します。
* 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ベースのアプローチのサブ場合にもPEの数に依存します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さもなければ、PEに接続されたVPNのサイト内のルータ、およびVPN VRF自体は、ポリシー機能を持たないだろうという仮定の下で、次いで、おそらく真である（S、G）をSwitchToSptDesired。
* 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ベースのアプローチの場合、コストはRRの数に直線的に依存し、ソースの数には依存性がありません。
* 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.
BGPベースのアプローチは、コストの独立を有しているため、PIMベースのアプローチを用いて、ASMグループGに参加任意のPEの全ての機器を横切って全体的なコストは、常にPES（葉PEについて同じ）の数に依存しますPEの数の。例外は、サイト間共有ツリーなしで使用BGPベースのアプローチのためのASMグループに参加最初のPEです。その場合には、PEの数との依存関係があります。
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
ソースの数に依存上に、PIMルータとVPNの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は常にすべてのPIMルータおよびVPNのVRFのに偽である場合、PIMベースのアプローチであり、サイト間の共有ツリーを使用するBGPベースのアプローチで、処理されたメッセージの量のコストは数とは無関係になります元の（それはこの条件は、顧客のポリシーに依存することに注意しなければなりません）。
Appendix B. Switching to S-PMSI
S-PMSIへの切り替え付録B.
(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]になった文書の初期のバージョンでは、2つのアプローチがソースPEは、S-PMSIに顧客マルチキャストトラフィックの送信を開始するタイミングを決定することができますどのようにするために提案されました：
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は、受信機のPEを選択させる、I-PMSI P-マルチキャストツリーと時間の事前に設定期間に同時にS-PMSI P-マルチキャストツリーの両方で（CS、CG）のマルチキャストパケットを送信します。唯一の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-マルチキャストツリー上のトラフィックを切り替える前に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）トラフィックがそのストリームのためのマルチキャストツリーが使用する帯域幅を最適化するためにS-PMSIに切り替えるための動機と対立であると思われる時間の一部の期間、のために2回送信されます。
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私-PMSI P-マルチキャストツリーのトランジット遅延やS-PMSI P-マルチキャストツリーが異なる場合、スイッチオーバーは、パケット損失または重複することなく発生する可能性があることはほとんどありません。
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.
これとは対照的に、第二の代替は、これらの欠点を満たすのいずれマルチキャストVPNソリューションは、可能な限りは、そのクライアントのマルチキャストトラフィックパケットが失われたり重複でもないことを確認すべきである」と述べている[RFC4834]のセクション5.1.3で要件を、持っていません変更が邪魔に発生した場合でも、クライアントのマルチキャストデータストリームが「プロバイダ・ネットワーク上で伝送されます。第二の代替は、既存の展開で使用されるものであることを起こります。
Consistent with this analysis, only the second alternative is discussed in [RFC6513].
この分析と一致して、唯一の第二の代替は、[RFC6513]に記載されています。
Authors' Addresses
著者のアドレス
Thomas Morin (editor) France Telecom - Orange 2 rue Pierre Marzin Lannion 22307 France EMail: thomas.morin@orange.com
トーマス・モリン（編集者）フランステレコム - オレンジ2 RUEピエールMarzin 22307ラニオンフランスEメール：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
ベン・ニーヴン・ジェンキンス（エディタ）BT 208カリストハウス、Adastral公園サフォーク州イプスウィッチIP5 3RE英国Eメール：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
ゆじ かみて んっｔ こっむにかちおんｓ こｒぽらちおん Ｇらんぱｒｋ とうぇｒ ３ー４ー１ しばうら、 みなとーく ときょ １０８ー８１１８ じゃぱん えまいｌ： ｙ。かみて＠んっｔ。こｍ
Raymond Zhang Alcatel-Lucent 777 Middlefield Rd. Mountain View, CA 94043 USA EMail: raymond.zhang@alcatel-lucent.com
レイモンド・チャンアルカテル・ルーセント777ミドルRdを。マウンテンビュー、CA 94043 USA電子メール：raymond.zhang@alcatel-lucent.com
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21-27 10781 Berlin Germany EMail: n.leymann@telekom.de
ニコライLeymannドイツテレコムWinterfeldtstrasse 21-27 10781ベルリンドイツEメール：n.leymann@telekom.de
Nabil Bitar Verizon 60 Sylvan Road Waltham, MA 02451 USA EMail: nabil.n.bitar@verizon.com
ナビル・ビタールベライゾン60シルバンロードウォルサム、MA 02451 USA電子メール：nabil.n.bitar@verizon.com