Network Working Group Y. Kamite, Ed.
Request for Comments: 5501 NTT Communications
Category: Informational Y. Wada
NTT
Y. Serbest
AT&T
T. Morin
France Telecom
L. Fang
Cisco Systems, Inc.
March 2009
Requirements for Multicast Support in Virtual Private LAN Services
仮想プライベートLANサービスにおけるマルチキャストサポートするための要件
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines.
この文書では、仮想プライベートLANサービス（VPLS）上でマルチキャストをサポートするネットワークソリューションのための機能要件を提供します。これは、エンドユーザとサービス提供者の立場からの両方の要件を指定します。潜在的なソリューションがガイドラインとしてこれらの要件を使用することが意図されています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Scope of This Document .....................................4
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Conventions ................................................6
3. Problem Statements ..............................................6
3.1. Motivation .................................................6
3.2. Multicast Scalability ......................................7
3.3. Application Considerations .................................8
3.3.1. Two Perspectives of the Service .....................8
4. General Requirements ............................................9
4.1. Scope of Transport .........................................9
4.1.1. Traffic Types .......................................9
4.1.1.1. Multicast and Broadcast ....................9
4.1.1.2. Unknown Destination Unicast ................9
4.1.2. Multicast Packet Types ..............................9
4.1.3. MAC Learning Consideration .........................11
4.2. Static Solutions ..........................................11
4.3. Backward Compatibility ....................................11
5. Customer Requirements ..........................................12
5.1. CE-PE Protocol ............................................12
5.1.1. Layer-2 Aspect .....................................12
5.1.2. Layer-3 Aspect .....................................12
5.2. Multicast Domain ..........................................13
5.3. Quality of Service (QoS) ..................................14
5.4. SLA Parameters Measurement ................................14
5.5. Security ..................................................15
5.5.1. Isolation from Unicast .............................15
5.5.2. Access Control .....................................15
5.5.3. Policing and Shaping on Multicast ..................15
5.6. Access Connectivity .......................................15
5.7. Multi-Homing ..............................................15
5.8. Protection and Restoration ................................15
5.9. Minimum MTU ...............................................16
5.10. Frame Reordering Prevention ..............................16
5.11. Fate-Sharing between Unicast and Multicast ...............16
6. Service Provider Network Requirements ..........................18
6.1. Scalability ...............................................18
6.1.1. Trade-Off of Optimality and State Resource .........18
6.1.2. Key Metrics for Scalability ........................19
6.2. Tunneling Requirements ....................................20
6.2.1. Tunneling Technologies .............................20
6.2.2. MTU of MDTunnel ....................................20
6.3. Robustness ................................................20
6.4. Discovering Related Information ...........................21
6.5. Operation, Administration, and Maintenance ................21
6.5.1. Activation .........................................21
6.5.2. Testing ............................................22
6.5.3. Performance Management .............................22
6.5.4. Fault Management ...................................23
6.6. Security ..................................................24
6.6.1. Security Threat Analysis ...........................24
6.6.2. Security Requirements ..............................25
6.7. Hierarchical VPLS support .................................28
6.8. L2VPN Wholesale ...........................................28
7. Security Considerations ........................................28
8. Acknowledgments ................................................28
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................29
VPLS (Virtual Private LAN Service) is a provider service that emulates the full functionality of a traditional Local Area Network (LAN). VPLS interconnects several customer LAN segments over a packet switched network (PSN) backbone, creating a multipoint-to-multipoint Ethernet VPN. For customers, their remote LAN segments behave as one single LAN.
VPLS（仮想プライベートLANサービス）は、従来のローカルエリアネットワーク（LAN）のすべての機能をエミュレートするプロバイダサービスです。 VPLSはマルチポイント・ツー・マルチポイントイーサネットVPNを作成し、ネットワーク（PSN）バックボーンをパケット交換に比べていくつかの顧客のLANセグメントを相互接続します。顧客のために、彼らのリモートLANセグメントは、1つのLANとして振る舞います。
In a VPLS, the provider network emulates a learning bridge, and forwarding takes place based on Ethernet MAC (media access control) learning. Hence, a VPLS requires MAC address learning/aging on a per-PW (pseudowire) basis, where forwarding decisions treat the PW as a "bridge port".
VPLSでは、プロバイダのネットワークは、学習ブリッジをエミュレートし、および転送は、イーサネットMAC（メディアアクセス制御）学習に基づいて行われます。したがって、VPLSは、転送決定は、「ブリッジポート」としてPWを扱うあたり-PW（スードワイヤ）ごと、上エイジング/ MACアドレス学習が必要です。
VPLS is a Layer-2 (L2) service. However, it provides two applications from the customer's point of view:
VPLSは、レイヤ2（L2）サービスです。しかし、それは顧客の視点からの二つのアプリケーションを提供しています。
- LAN Routing application: providing connectivity between customer routers
- LANルーティングアプリケーション：顧客のルータ間の接続性を提供
- LAN Switching application: providing connectivity between customer Ethernet switches
- LANスイッチングアプリケーション：顧客のイーサネットスイッチ間の接続性を提供
Thus, in some cases, customers across MAN/WAN have transparent Layer-2 connectivity while their main goal is to run Layer-3 applications within their routing domain. As a result, different requirements arise from their variety of applications.
彼らの主な目標は、自分のルーティングドメイン内のレイヤ3のアプリケーションを実行することですしながら、このように、いくつかのケースでは、MAN / WAN経由の顧客は、透明レイヤ2接続性を持っています。その結果、さまざまな要件は、アプリケーションの彼らの様々なから生じます。
Originally, PEs (Provider Edges) in VPLS transport broadcast/ multicast Ethernet frames by replicating all multicast/broadcast frames received from an Attachment Circuit (AC) to all PW's corresponding to a particular Virtual Switching Instance (VSI). Such a technique has the advantage of keeping the P (Provider Router) and PE devices completely unaware of IP multicast-specific issues. Obviously, however, it has quite a few scalability drawbacks in terms of bandwidth consumption, which will lead to increased cost in large-scale deployment.
もともと、すべてのマルチキャスト/ブロードキャストフレームを複製することにより、VPLS輸送ブロードキャスト/マルチキャストイーサネットフレーム内のPE（プロバイダーエッジ）は、すべてのPWのは、特定の仮想スイッチングインスタンス（VSI）に対応する接続回線（AC）から受け取りました。そのような技術は、P（プロバイダールータ）とIPマルチキャスト固有の問題の完全に気づいていないPEデバイスを維持するという利点を有します。明らかに、しかし、それは大規模な展開でのコスト増加につながる帯域幅の消費の面でかなりの数のスケーラビリティの欠点を有しています。
Meanwhile, there is a growing need for support of multicast-based services such as IP TV. This commercial trend makes it necessary for most VPLS deployments to support multicast more efficiently than before. It is also necessary as customer routers are now likely to be running IP multicast protocols, and those routers are connected to switches that will be handling large amounts of multicast traffic.
一方、こうしたIPテレビなどのマルチキャストベースのサービスをサポートするためのニーズが高まっています。この商用傾向は、それが必要なほとんどのVPLSの展開がより効率的に以前よりもマルチキャストをサポートできるようになります。これは、顧客のルータが今IPマルチキャストプロトコルを実行される可能性があるとしても必要であり、これらのルータは、マルチキャストトラフィックを大量に扱うことになるスイッチに接続されています。
Therefore, it is desirable to have more efficient techniques to support IP multicast over VPLS.
したがって、VPLS上でIPマルチキャストをサポートするために、より効率的な技術を有することが望ましいです。
This document provides functional requirements for network solutions that support IP multicast in VPLS [RFC4761] [RFC4762]. It identifies requirements that MAY apply to the existing base VPLS architecture in order to optimize IP multicast. It also complements the generic L2VPN requirements document [RFC4665], by specifying additional requirements specific to the deployment of IP multicast in VPLS.
この文書では、VPLS [RFC4761] [RFC4762]でIPマルチキャストをサポートするネットワークソリューションのための機能要件を提供します。これは、IPマルチキャストを最適化するために、既存の基本VPLSアーキテクチャに適用される要件を識別します。また、VPLSにおけるIPマルチキャストの展開に特有の追加要件を指定することで、一般的なL2VPN要件ドキュメント[RFC4665]を補完します。
The technical specifications are outside the scope of this document. In this document, there is no intent to specify either solution-specific details or application-specific requirements. Also, this document does NOT aim to express multicast-inferred requirements that are not specific to VPLS. It does NOT aim to express any requirements for native Ethernet specifications, either.
技術仕様は、このドキュメントの範囲外です。この文書では、ソリューション固有の詳細やアプリケーション固有の要件のいずれかを指定する意図はありません。また、この文書は、VPLSに固有のものではありませんマルチキャスト推論要件を表現することを目指しません。それはどちらか、ネイティブイーサネット仕様のいずれかの要件を表現することを目指しません。
This document is proposed as a solution guideline and a checklist of requirements for solutions, by which we will evaluate how each solution satisfies the requirements.
この文書は、我々が各ソリューションが要件を満たしてどのように評価することにより、その解決策の指針とソリューションのための要件のチェックリストとして提案されています。
This document clarifies the needs from both VPLS customer as well as provider standpoints and formulates the problems that should be addressed by technical solutions while staying solution agnostic.
この文書では、顧客のVPLSだけでなく、プロバイダの立場とソリューションはとらわれない滞在しながら、技術的な解決策で対処すべき問題を定式化し、両方からのニーズを明確にしています。
A technical solution and corresponding service that supports this document's requirements are hereinafter called a "multicast VPLS".
このドキュメントの要件をサポートして技術的な解決策と対応するサービスは以下「マルチキャストVPLS」と呼ばれています。
The reader is assumed to be familiar with the terminology, reference models, and taxonomy defined in [RFC4664] and [RFC4665]. For readability purposes, we repeat some of the terms here.
読者は、用語、参照モデル、及び[RFC4664]で定義された分類と[RFC4665]に精通しているものとします。読みやすさのために、我々はここでの用語の一部を繰り返します。
Moreover, we also propose some other terms needed when IP multicast support in VPLS is discussed.
また、我々はまた、VPLSにおけるIPマルチキャストサポートが議論されたときに必要ないくつかの他の用語を提案します。
- ASM: Any Source Multicast. One of the two multicast service models where each corresponding service can have an arbitrary number of senders.
- ASM：任意のソースマルチキャスト。対応する各サービスが送信者の任意の数を有することができ、2つのマルチキャストサービスモデルの一つ。
- G: denotes a multicast group.
- G：マルチキャストグループを表します。
- MDTunnel: Multicast Distribution Tunnel, the means by which the customer's multicast traffic will be conveyed across the Service Provider (SP) network. This is meant in a generic way: such tunnels can be point-to-point, point-to-multipoint, or multipoint-to-multipoint. Although this definition may seem to assume that distribution tunnels are unidirectional, the wording encompasses bidirectional tunnels as well.
- MDTunnel：マルチキャスト配信トンネル、顧客のマルチキャストトラフィックは、サービスプロバイダ（SP）ネットワーク経由で搬送されることになるする手段。そのようなトンネルは、ポイントツーポイント、ポイント・ツー・マルチポイント、またはマルチポイント・ツー・マルチポイントになりますこれは、一般的な方法で意味しています。この定義は配布トンネルが単方向であることを前提としているように見えるかもしれないが、言葉遣いも同様に双方向のトンネルを含みます。
- Multicast Channel: In the multicast SSM (Source Specific Multicast) model [RFC4607], a "multicast channel" designates traffic from a specific source S to a multicast group G. Also denominated as "(S,G)".
- マルチキャストチャネルは、マルチキャストSSM（ソース固有マルチキャスト）モデル[RFC4607]で、「マルチキャストチャネル」はまた、「（S、G）」と命名マルチキャストグループGに特定のソースSからのトラフィックを指定します。
- Multicast domain: An area in which multicast data is transmitted. In this document, this term has a generic meaning that can refer to Layer-2 and Layer-3. Generally, the Layer-3 multicast domain is determined by the Layer-3 multicast protocol used to establish reachability between all potential receivers in the corresponding domain. The Layer-2 multicast domain can be the same as the Layer-2 broadcast domain (i.e., VLAN), but it may be restricted to being smaller than the Layer-2 broadcast domain if an additional control protocol is used.
- マルチキャストドメイン：マルチキャストデータが送信されている領域。この文書では、この用語は、レイヤ2およびレイヤ3を参照することができ、一般的な意味を持ちます。一般に、レイヤ3マルチキャストドメインは、対応するドメイン内のすべての潜在的な受信機との間で到達可能性を確立するために使用されるレイヤ3マルチキャストプロトコルによって決定されます。レイヤ2マルチキャストドメインは、レイヤ2ブロードキャストドメイン（すなわち、VLAN）と同じであることができるが、追加の制御プロトコルが使用される場合には、レイヤ2ブロードキャストドメインよりも小さいことに制限されてもよいです。
- CE: Customer Edge Device.
- CE：カスタマーエッジデバイス。
- PE: Provider Edge.
- PE：プロバイダーエッジ。
- P: Provider Router.
- P：プロバイダールータ。
- S: denotes a multicast source.
- S：マルチキャストソースを意味します。
- SP: Service Provider.
- SP：サービスプロバイダ。
- SSM: Source Specific Multicast. One of the two multicast service models where each corresponding service relies upon the use of a single source.
- SSM：ソース固有マルチキャスト。各対応するサービスは、単一源の使用に依存して2つのマルチキャストサービスモデルの一つ。
- U-PE/N-PE: The device closest to the customer/user is called the User-facing PE (U-PE) and the device closest to the core network is called the Network-facing PE (N-PE).
- U-PE / N-PE：ユーザーに面するPE（U-PE）と呼ばれる顧客/ユーザとネットワーク側PE（N-PE）と呼ばれるコアネットワークに最も近いデバイスに最も近いデバイス。
- VPLS instance: A service entity manageable in VPLS architecture. All CE devices participating in a single VPLS instance appear to be on the same LAN, composing a VPN across the SP's network. A VPLS instance corresponds to a group of VSIs that are interconnected using PWs (pseudowires).
- VPLSインスタンス：VPLSアーキテクチャで管理サービスエンティティ。単一VPLSインスタンスに参加しているすべてのCEデバイスは、SPのネットワークを介してVPNを構成する、同じLAN上にあるように見えます。 VPLSインスタンスがのPW（疑似回線）を使用して相互接続されるのVSIのグループに対応します。
- VSI: Virtual Switching Instance. A VSI is a logical entity in a PE that maps multiple ACs (Attachment Circuits) to multiple PWs. The VSI is populated in much the same way as a standard bridge populates its forwarding table. Each PE device may have multiple VSIs, where each VSI belongs to a different VPLS instance.
- VSI：仮想スイッチングインスタンス。 VSIは、複数のPWに複数のACS（接続回線）をマッピングするPE内の論理エンティティです。 VSIは、標準的なブリッジは、その転送テーブルを移入とほとんど同じ方法で移入されます。各PEデバイスは、各VSIは異なるVPLSインスタンスに属する複数のVSIを有していてもよいです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Today, many kinds of IP multicast services are becoming available. Over their Layer-2 VPN service, particularly over VPLS, customers would often like to operate their multicast applications to remote sites. Also, VPN service providers using an IP-based network expect that such Layer-2 network infrastructure will efficiently support multicast data traffic.
今日では、IPマルチキャストサービスの多くの種類が利用可能になってきています。そのレイヤ2 VPNサービス上で、特にVPLS上で、顧客は多くの場合、リモートサイトへのマルチキャストアプリケーションを運用したいと思います。また、IPベースのネットワークを使用してVPNサービスプロバイダーは、レイヤ2ネットワークインフラストラクチャを効率的にマルチキャストデータトラフィックをサポートすることを期待しています。
However, VPLS has a shortcoming as it relates to multicast scalability as mentioned below because of the replication mechanisms intrinsic to the original architecture. Accordingly, the primary goal for technical solutions is to solve this issue partially or completely, and provide efficient ways to support IP multicast services over VPLS.
なぜなら、元のアーキテクチャに固有のレプリケーション・メカニズムの下記のように、それはマルチキャストスケーラビリティに関するしかし、VPLSは、欠点を有しています。したがって、技術的な解決のための第一の目的は、部分的または完全にこの問題を解決し、VPLS上でIPマルチキャスト・サービスをサポートするための効率的な方法を提供することです。
In VPLS, replication occurs at an ingress PE (in the hierarchical VPLS (H-VPLS) case, at N-PE) when a CE sends (1) Broadcast, (2) Multicast, or (3) Unknown destination unicast. There are two well-known issues with this approach:
CEは、（1）放送、（2）マルチキャスト、または（3）未知の宛先のユニキャストを送信した場合VPLSにおいて、複製は、入口PE（N-PEで階層VPLS（H-VPLSで）場合、）で起こります。このアプローチには2つのよく知られた問題があります。
Issue A: Replication to non-member site:
非会員サイトへのレプリケーション：発行します。
In cases (1) and (3), the upstream PE has to transmit packets to all of the downstream PEs that belong to the common VPLS instance. You cannot decrease the number of members, so this is basically an inevitable situation for most VPLS deployments.
ケース（1）及び（3）において、上流のPEは、共通のVPLSインスタンスに属する下流PEの全てにパケットを送信しなければなりません。あなたはメンバーの数を減らすことができないので、これは基本的にほとんどのVPLSの展開のために避けられない状況です。
In case (2), however, there is an issue that multicast traffic is sent to sites with no members. Usually, this is caused when the upstream PE does not maintain downstream membership information. The upstream PE simply floods frames to all downstream PEs, and the downstream PEs forward them to directly connected CEs; however, those CEs might not be the members of any multicast group. From the perspective of customers, they might suffer from pressure on their own resources due to unnecessary traffic. From the perspective of SPs, they would not like wasteful over-provisioning to cover such traffic.
（2）の場合には、しかし、マルチキャストトラフィックは、メンバーのいないサイトに送信されるという問題がありました。通常、これは上流PEが下流のメンバーシップ情報を保持していない場合に発生します。上流のPEは、単純にすべての下流PEにフレームをフラッディングし、そして下流のPEは、直接接続されたCEにそれらを転送します。しかし、それらのCEは、どのマルチキャストグループのメンバーではないかもしれません。顧客の観点から、彼らは、不要なトラフィックのために、独自の資源に対する圧力に苦しむかもしれません。 SPの観点から、彼らは、このようなトラフィックをカバーするために、オーバープロビジョニング無駄を好きではないだろう。
Issue B: Replication of PWs on shared physical path:
発行B：共有物理パス上のPWレプリケーション：
In VPLS, a VSI associated with each VPLS instance behaves as a logical emulated bridge that can transport Ethernet across the PSN backbone using PWs. In principle, PWs are designed for unicast traffic.
VPLSにおいては、それぞれに関連付けられたVSIはインスタンスのPWを使用してPSNバックボーン上でイーサネットを輸送することができる論理的なエミュレートされたブリッジとして動作VPLS。原則として、PWのは、ユニキャストトラフィックのために設計されています。
In all cases, (1), (2), and (3), Ethernet frames are replicated on one or more PWs that belong to that VSI. This replication is often inefficient in terms of bandwidth usage if those PWs are traversing shared physical links in the backbone.
すべての場合において、（1）、（2）、（3）、イーサネットフレームはそのVSIに属する1つのまたは複数のPW上に複製されます。これらのPWSはバックボーンにおける共有物理リンクを横断している場合は、この複製は、帯域幅の使用量の面で、多くの場合、非効率的です。
For instance, suppose there are 20 remote PEs belonging to a particular VPLS instance, and all PWs happen to be traversing over the same link from one local PE to its next-hop P. In this case, even if a CE sends 50 Mbps to the local PE, the total bandwidth of that link will be to 1000 Mbps.
例えば、特定のVPLSインスタンスに属する20個のリモートPEが存在すると仮定し、すべてのPWSがCEは50 Mbpsのを送信しても、この場合には、その次ホップPに一つのローカルPEから同じリンク上に横断することが起こりますローカルPEは、そのリンクの総帯域幅は1000 Mbpsになります。
Note that while traditional 802.1D Ethernet switches replicate broadcast/multicast flows once at most per output interface, VPLS often needs to transmit one or more flows duplicated over the same output interface.
伝統的な802.1Dイーサネットスイッチは、ブロードキャスト/マルチキャストは、出力インターフェイスごとに、最大で一回流れて複製しながら、VPLSは、多くの場合、同じ出力インターフェース上で重複して1つ以上のフローを送信する必要があることに注意してください。
From the perspective of customers, there is no serious issue because they do not know what happens in the core. However, from the perspective of SPs, unnecessary replication brings the risk of resource exhaustion when the number of PWs increases.
彼らはコアに何が起こるかわからないので、顧客の観点から、重大な問題がありません。しかし、のSPの観点から、不必要な複製はPW数が増加リソースの枯渇の危険性をもたらします。
In both Issues A and B, these undesirable situations will become obvious with the wide-spread use of IP multicast applications by customers. Naturally, the problem will become more serious as the number of sites grows. In other words, there are concerns over the scalability of multicast in VPLS today.
問題AとBの両方で、これらの望ましくない状況では、顧客のIPマルチキャストアプリケーションの広範な使用に明らかになるであろう。サイトの数が増えると当然、問題はより深刻になるだろう。言い換えれば、VPLSにおけるマルチキャスト今日の拡張性が懸念されています。
When it comes to IP multicast over VPLS, there are two different aspects in terms of service provisioning. They are closely related to the functional requirements from two technical standpoints:
それはVPLS上でIPマルチキャストになると、サービス提供の面で二つの異なる側面があります。彼らは密接に2つの技術的な観点からの機能要件に関連しています。
Layer-2 and Layer-3.
レイヤ2およびレイヤ3。
- Native Ethernet service aspect
- ネイティブイーサネットサービス様相
This aspect mainly affects Ethernet network service operators. Their main interest is to solve the issue that existing VPLS deployments cannot always handle multicast/broadcast frames efficiently.
この局面は、主に、イーサネットネットワークサービス事業者に影響を与えます。彼らの主な関心は、既存のVPLSの展開は、常に効率的にマルチキャスト/ブロードキャストフレームを処理できない問題を解決することです。
Today, wide-area Ethernet services are becoming popular, and VPLS can be utilized to provide wide-area LAN services. As customers come to use various kinds of content distribution applications that use IP multicast (or other protocols that lead to multicast/ broadcast in the Ethernet layer), the total amount of traffic will also grow. In addition, considerations of Operations, Administration, and Management (OAM), security and other related points in multicast in view of Layer-2 are important.
今日では、広域イーサネットサービスは、人気が高まっている、とVPLSは、広域LANサービスを提供するために利用することができます。顧客は、IPマルチキャスト（またはイーサネット層で放送マルチキャスト/につながる他のプロトコル）を使用したコンテンツ配信アプリケーションの様々な種類を使用するように来ると、トラフィックの総量も成長します。また、運用、管理、および管理（OAM）の考慮事項は、レイヤ2の観点では、マルチキャストでのセキュリティおよびその他の関連の点が重要です。
In such circumstances, the native VPLS specification would not always be satisfactory if multicast traffic is more dominant in total resource utilization than before. The scalability issues mentioned in the previous section are expected to be solved.
マルチキャストトラフィックが以前よりも総リソース利用がより支配的であれば、このような状況では、ネイティブVPLS仕様は必ずしも十分ではないでしょう。前節で述べたスケーラビリティの問題を解決することが期待されています。
- IP multicast service aspect
- IPマルチキャストサービスの様相
This aspect mainly affects both IP service providers and end users. Their main interest is to provide IP multicast services transparently but effectively by means of VPLS as a network infrastructure.
この局面は、主にIPサービスプロバイダーとエンドユーザーの両方に影響します。彼らの主な関心は、ネットワークインフラストラクチャとしてVPLSによって透過的になく、効果的にIPマルチキャストサービスを提供することです。
SPs might expect VPLS as an access/metro network to deliver multicast traffic (such as Triple-play (Video, Voice, Data) and Multicast IP VPNs) in an efficient way.
SPは効率的な方法で（例えばトリプルプレイ（ビデオ、音声、データ）およびマルチキャストIP VPNなど）マルチキャストトラフィックを配信するためのアクセス/メトロネットワークとしてVPLSを期待するかもしれません。
We assume the basic requirements for VPLS written in [RFC4665] are fulfilled unless otherwise specified in this document.
私たちは、そうでない場合は、この文書で指定されていない限り、[RFC4665]で記述されたVPLSのための基本的な要件が満たされていると仮定します。
As described before, any solution is expected to have mechanisms for efficient transport of IP multicast. Multicast is related to both Issues A and B (see Section 3.2); however, broadcast is related to Issue B only because it does not need membership control.
前に説明したように、任意の溶液は、IPマルチキャストを効率的に輸送するための機構を有することが期待されます。マルチキャストが問題AとBの両方に関連している（セクション3.2を参照）。それはメンバーシップの制御を必要としないのでしかし、放送はBのみを問題に関連しています。
- A multicast VPLS solution SHOULD attempt to solve both Issues A and B, if possible. However, since some applications prioritize solving one issue over the other, the solution MUST identify which Issue (A or B) it is attempting to solve. The solution SHOULD provide a basis for evaluating how well it solves the issue(s) it is targeting, if it is providing an approximate solution.
- マルチキャストVPLS液可能であれば、問題AとBの両方を解決することを試みるべきです。いくつかのアプリケーションは、一方が他方の上の問題を解決する優先順位しかし、解決策は、解決しようとしている問題（AまたはB）を識別しなければなりません。解決策は、近似解を提供している場合、それは、標的にされ、それが問題（複数可）を解くどれだけ評価するための基礎を提供すべきです。
Unknown destination MAC unicast requires flooding, but its characteristics are quite different from multicast/broadcast. When the unicast MAC address is learned, the PE changes its forwarding behavior from flooding over all PWs into sending over one PW. Thereby, it will require different technical studies from multicast/ broadcast, which is out of scope of this document.
未知の宛先MACユニキャストフラッディングを必要としますが、その特性は、マルチキャスト/ブロードキャストとは全く異なっています。ユニキャストMACアドレスを学習するとき、PEはPW 1を介して送信するにすべてのPWを超える洪水からその転送動作を変更します。これにより、この文書の範囲外であるマルチキャスト/ブロードキャスト、異なる技術的検討が必要になります。
Ethernet multicast is used for conveying Layer-3 multicast data. When IP multicast is encapsulated by an Ethernet frame, the IP multicast group address is mapped to the Ethernet destination MAC address. In IPv4, the mapping uses the lower 23 bits of the (32-bit) IPv4 multicast address and places them as the lower 23 bits of a destination MAC address with the fixed header of 01-00-5E in hex. Since this mapping is ambiguous (i.e., there is a multiplicity of 1 Ethernet address to 32 IPv4 addresses), MAC-based forwarding is not ideal for IP multicast because some hosts might possibly receive packets they are not interested in, which is inefficient in traffic delivery and has an impact on security. On the other hand, if the solution tracks IP addresses rather than MAC addresses, this concern can be prevented. The drawback of this approach is, however, that the network administration becomes slightly more complicated.
イーサネットマルチキャストはレイヤ3マルチキャストデータを搬送するために使用されます。 IPマルチキャストは、イーサネットフレームによってカプセル化されたときに、IPマルチキャストグループアドレスは、イーサネット宛先MACアドレスにマッピングされます。 IPv4では、マッピングは、（32ビット）のIPv4マルチキャストアドレスの下位23ビットを使用し、ヘクスに01-00-5Eの固定ヘッダと宛先MACアドレスの下位23ビットとしてそれらを配置します。このマッピングが曖昧であるため（すなわち、32個のIPv4アドレスに1つのイーサネットアドレスの多数がある）は、いくつかのホストは、おそらくトラフィックに非効率的であり、彼らが興味を持っていないパケットを受信する可能性があるため、MACベースの転送は、IPマルチキャストのための理想的ではありません配信とセキュリティに影響を与えます。ソリューションは、IPアドレスではなくMACアドレスを追跡する一方、この懸念を防止することができます。このアプローチの欠点は、ネットワーク管理がやや複雑になっていること、しかし、です。
Ethernet multicast is also used for Layer-2 control frames. For example, BPDU (Bridge Protocol Data Unit) for IEEE 802.1D Spanning Trees uses a multicast destination MAC address (01-80-C2-00-00-00). Also, some of IEEE 802.1ag [802.1ag] Connectivity Fault Management (CFM) messages use a multicast destination MAC address dependent on their message type and application. From the perspective of IP multicast, however, it is necessary in VPLS to flood such control frames to all participating CEs, without requiring any membership controls.
イーサネットマルチキャストも、レイヤ2制御フレームに使用されます。例えば、IEEE 802.1DスパニングツリーのBPDU（ブリッジプロトコルデータユニット）は、マルチキャスト宛先MACアドレス（01-80-C2-00-00-00）を使用しています。また、IEEE 802.1ag [802.1ag]接続障害管理（CFM）メッセージのいくつかは、彼らのメッセージの種類と用途に応じマルチキャスト宛先MACアドレスを使用します。 IPマルチキャストの観点からは、しかし、それはどんなメンバーシップのコントロールを必要とせずに、すべての参加CEに、このような制御フレームをあふれさせるVPLS必要です。
As for a multicast VPLS solution, it can only use Ethernet-related information, if you stand by the strict application of the basic requirement: "a L2VPN service SHOULD be agnostic to customer's Layer 3 traffic" [RFC4665]. This means no Layer-3 information should be checked for transport. However, it is obvious this is an impediment to solve Issue A.
あなたが基本的な要件の厳しいアプリケーションに立つならば、マルチキャストのVPLS液としては、それだけで、イーサネットの関連情報を使用することができます：[RFC4665]「L2VPNサービスは、顧客のレイヤ3トラフィックへの不可知論であるべきです」。これにはレイヤ3情報は、輸送のためにチェックすべきではないことを意味します。しかし、問題のA.を解決するための障害となって明らかです
Consequently, a multicast VPLS can be allowed to make use of some Layer-3-related supplementary information in order to improve transport efficiency. In fact, today's LAN-switch implementations often support such approaches and snoop upper-layer protocols and examine IP multicast memberships (e.g., Protocol Independent Multicast (PIM) snooping and IGMP/MLD (Multicast Listener Discovery) snooping [RFC4541]). This will implicitly suggest that VPLS may adopt similar techniques although this document does NOT state Layer-3 snooping is mandatory. If such an approach is taken, careful consideration of Layer-3 state maintenance is necessary. In addition, note that snooping approaches sometimes have disadvantages in the system's transparency; that is, one particular protocol's snooping solution might hinder other (especially future) protocol's working (e.g., an IGMPv2-snooping switch vs. a new IGMPv3-snooping one). Also, note that there are potential alternatives to snooping:
したがって、マルチキャストVPLSは、輸送効率を向上させるために、いくつかのレイヤ3に関する補足情報を利用させることができます。実際には、今日のLANスイッチの実装は、多くの場合、このようなアプローチをサポートし、上位層プロトコルをスヌープし、IPマルチキャストメンバーシップ（例えば、プロトコル独立マルチキャスト（PIM）スヌーピングおよびIGMP / MLD（マルチキャストリスナ発見）スヌーピング[RFC4541]）を調べます。これは、暗黙的にこの文書はレイヤ3スヌーピングが必須である状態はありませんがVPLSは、同様の技術を採用することができることを示唆しているだろう。このようなアプローチが取られている場合は、レイヤ3の状態の維持を慎重に検討が必要です。また、スヌープアプローチは時々、システムの透明性の欠点を持っていることに注意してください。つまり、ある特定のプロトコルのスヌーピングソリューションは、他の（特に未来）プロトコルの作業を妨げる可能性がある（例えば、対IGMPv2のスヌーピングスイッチに新しいものをIGMPv3のスヌーピング）。また、スヌーピングへの潜在的な代替手段があることに注意してください。
- Static configuration of multicast Ethernet addresses and ports/ interfaces.
- マルチキャストイーサネットアドレスとポート/インターフェースの静的構成。
- Multicast control protocol based on Layer-2 technology that signals mappings of multicast addresses to ports/interfaces, such as Generic Attribute Registration Protocol / GARP Multicast Registration Protocol (GARP/GMRP) [802.1D], Cisco Group Management Protocol [CGMP], and Router-port Group Management Protocol (RGMP) [RFC3488].
- そのような一般的な属性登録プロトコル/ GARPマルチキャスト登録プロトコル（GARP / GMRP）[802.1D]、シスコグループ管理プロトコル[CGMP]としてポート/インターフェースへのマルチキャストアドレスのマッピングを、信号レイヤ2技術に基づくマルチキャスト制御プロトコルそして、ルータポートグループ管理プロトコル（RGMP）[RFC3488]。
On the basis described above, general requirements about packet types are given as follows:
次のように上記に基づき、パケットタイプに関する一般的な要件が与えられています。
- A solution SHOULD support a way to facilitate IP multicast forwarding of the customers. It MAY observe Layer-3 information (i.e., multicast routing protocols and state) to the degree necessary, but any information irrelevant to multicast transport SHOULD NOT be consulted.
- ソリューションは、顧客のIPマルチキャスト転送を容易にするための方法をサポートする必要があります。これは、必要な程度にレイヤ3情報（即ち、マルチキャストルーティングプロトコル及び状態）を観察することができるが、マルチキャストトランスポートとは無関係の情報は相談されるべきではありません。
- In a solution, Layer-2 control frames (e.g., BPDU, 802.1ag CFM) SHOULD be flooded to all PE/CEs in a common VPLS instance. A solution SHOULD NOT change or limit the flooding scope to remote PE/CEs in terms of end-point reachability.
- 溶液中で、レイヤ2制御フレーム（例えば、BPDU、802.1agのCFM）は、共通のVPLSインスタンス内のすべてのPE / CEにフラッディングされるべきです。溶液は、エンドポイントの到達可能性の観点からリモートPE / CEに氾濫範囲を変更したり、制限するものではありません。
- In a solution, Layer-2 frames that encapsulate Layer-3 multicast control packets (e.g., PIM, IGMP (for IPv4), and MLD (for IPv6)) MAY be flooded only to relevant members, with the goal of limiting flooding scope. However, Layer-2 frames that encapsulate other Layer-3 control packets (e.g., OSPF, IS-IS) SHOULD be flooded to all PE/CEs in a VPLS instance.
- 溶液中で、レイヤ2フレームが氾濫範囲を制限する目的で、レイヤ3マルチキャスト制御パケット（例えば、PIM、IGMP（IPv4の場合）、およびIPv6のMLDは、（））のみ関連メンバーにフラッディングされるかもしれカプセル化すること。しかしながら、他のレイヤ3の制御パケット（例えば、OSPFは、IS-IS）カプセル化レイヤ2フレームは、VPLSインスタンス内のすべてのPE / CEにフラッディングされるべきです。
In a common VPLS architecture, MAC learning is carried out by PEs based on the incoming frame's source MAC address, independently of the destination MAC address (i.e., regardless of whether it is unicast, multicast, or broadcast). This is the case with the multicast VPLS solution's environment too. In this document, the improvement of MAC learning scalability is beyond the scope. It will be covered in future work.
一般的なVPLSのアーキテクチャでは、MAC学習は、受信フレームの送信元MACアドレスに基づいのPEによって行われる独立宛先のMACアドレス（すなわち、関係なく、ユニキャスト、マルチキャスト、またはブロードキャストであるかどうか）。これは、あまりにも、マルチキャストVPLSソリューションの環境の場合です。この文書では、MAC学習スケーラビリティの向上が範囲を超えています。これは、将来の仕事にカバーされます。
A solution SHOULD allow static configuration to account for various operator policies, where the logical multicast topology does not change dynamically in conjunction with a customer's multicast routing.
解決策は、静的な構成は、論理マルチキャストトポロジは、顧客のマルチキャストルーティングと組み合わせて動的に変化していない様々なオペレータポリシーを考慮して、許可する必要があります。
A solution SHOULD be backward compatible with the existing VPLS solution. It SHOULD allow a case where a common VPLS instance is composed of both PEs supporting the solution and PEs not supporting it, and the multicast optimization (both forwarding and receiving) is achieved between the compliant PEs.
ソリューションは、既存のVPLS溶液との下位互換性があるべきです。これは、共通のVPLSインスタンスがそれをサポートしていない溶液とのPEをサポート両方のPEから構成され、マルチキャスト最適化（転送および受信の両方）は、対応するPE間で達成される場合を可能にすべきです。
Note again that the existing VPLS solutions already have a simple flooding capability. Thus, this backward compatibility will give customers and SPs the improved efficiency of multicast forwarding incrementally as the solution is deployed.
既存のVPLSソリューションはすでに、単純なフラッディング機能を持っていることを再び注意してください。したがって、この下位互換性は、溶液が展開されている増分として顧客とのSPにマルチキャスト転送の改善された効率を与えます。
A solution SHOULD allow transparent operation of Ethernet control protocols employed by customers (e.g., Spanning Tree Protocol [802.1D]) and their seamless operation with multicast data transport.
溶液は、顧客によって使用されるイーサネット（登録商標）制御プロトコルの透明な操作を可能にすべきである（例えば、スパニングツリープロトコル[802.1D]）とマルチキャストデータ転送とのシームレスな操作。
Solutions MAY examine Ethernet multicast control frames for the purpose of efficient dynamic transport (e.g., GARP/GMRP [802.1D]). However, solutions MUST NOT assume all CEs are always running such protocols (typically in the case where a CE is a router and is not aware of Layer-2 details).
ソリューションは、効率的な動的輸送を目的としたイーサネットマルチキャスト制御フレームを調べることができる（例えば、GARP / GMRP [802.1D]）。しかし、解決策は、すべてのCEは常に（通常CEルータで、レイヤ2の詳細を認識していない場合には）そのようなプロトコルを実行していると仮定してはいけません。
A whole Layer-2 multicast frame (whether for data or control) SHOULD NOT be altered from a CE to CE(s) EXCEPT for the VLAN ID field, ensuring that it is transparently transported. If VLAN IDs are assigned by the SP, they can be altered. Note, however, when VLAN IDs are changed, Layer-2 protocols may be broken in some cases, such as Multiple Spanning Trees [802.1s]. Also, if the Layer-2 frame is encapsulating a Layer-3 multicast control packet (e.g., PIM/IGMP) and customers allow it to be regenerated at the PE (aka proxy: see Section 5.1.2), then the MAC address for that frame MAY be altered to the minimum necessary (e.g., use PE's own MAC address as a source).
全レイヤ2マルチキャストフレームは、（データまたは制御のためかどうか）は、それが透過的に搬送されることを確実に、VLAN IDフィールドを除いCE（複数可）にCEから変更してはなりません。 VLAN IDはSPによって割り当てられている場合、それらを変更することができます。ノートは、しかし、VLAN IDが変更された場合、レイヤ2プロトコルは、[802.1]マルチプルスパニングツリーとして、いくつかのケースでは破壊されてもよいです。また、レイヤ2フレームは、レイヤ3マルチキャスト制御パケット（例えば、PIM / IGMP）を封入している顧客は、それがPE（別名プロキシ：5.1.2項を参照）で再生することを可能にする、場合のために、その後、MACアドレス、そのフレームは、（例えば、光源としてPE自身のMACアドレスを使用する）必要最小限に変更することができます。
Again, a solution MAY examine the customer's Layer-3 multicast protocol packets for the purpose of efficient and dynamic transport. If it does, supported protocols SHOULD include:
ここでも、ソリューションは、効率的かつダイナミックな輸送のために顧客のレイヤ3マルチキャストプロトコルパケットを調べることができます。それがない場合は、サポートされているプロトコルは含まれている必要があります
o PIM-SM (Sparse Mode) [RFC4601], PIM-SSM (Source-Specific Multicast) [RFC4607], bidirectional PIM [RFC5015], and PIM-DM (Dense Mode) [RFC3973].
O PIM-SM（スパースモード）[RFC4601]、PIM-SSM（ソース固有マルチキャスト）[RFC4607]、双方向PIM [RFC5015]、およびPIM-DM（稠密モード）[RFC3973]。
o IGMP (v1 [RFC1112], v2 [RFC2236], and v3 [RFC3376]) (for IPv4 solutions).
O IGMP（IPv4のソリューションのための）（V1 [RFC1112]、V2 [RFC2236]、およびv3 [RFC3376]）。
o Multicast Listener Discovery Protocol (MLD) (v1 [RFC2710] and v2 [RFC3810]) (for IPv6 solutions).
Oマルチキャストリスナー発見プロトコル（IPv6のソリューションのための）（MLD）（V1 [RFC2710]およびv2 [RFC3810]）。
A solution MUST NOT require any special Layer-3 multicast protocol packet processing by the end users. However, it MAY require some configuration changes (e.g., turning explicit tracking on/off in the PIM).
ソリューションは、エンドユーザーが特別なレイヤ3マルチキャストプロトコルパケットの処理を要求することはできません。しかし、それは（例えば、PIMにオン/オフ明示的なトラッキングを旋回）いくつかの構成の変更を必要とする場合があります。
A whole Layer-3 multicast packet (whether for data or control), which is encapsulated inside a Layer-2 frame, SHOULD NOT be altered from a CE to CE(s), ensuring that it is transparently transported. However, as for Layer-3 multicast control (like PIM Join/Prune/Hello and IGMP Query/Report packet), it MAY be altered to the minimum necessary if such partial non-transparency is acceptable from point of view of the multicast service. Similarly, a PE MAY consume such Layer-3 multicast control packets and regenerate an entirely new packet if partial non-transparency is acceptable with legitimate reason for customers (aka proxy).
レイヤ2フレーム内にカプセル化されている全レイヤ3マルチキャストパケット（データまたは制御のためかどうか）、それが透過的に転送されることを保証する、CE（複数可）にCEから変更してはなりません。このような部分の非透明度は、マルチキャストサービスの観点から許容される場合は、レイヤ3マルチキャスト制御（PIMは/プルーン/こんにちは、IGMPクエリ/レポートパケットを参加など）に関しては、それは必要最小限に変更することができます。同様に、PEは、レイヤ3マルチキャスト制御パケットを消費し、部分的非透過性は、顧客のために正当な理由（別名プロキシ）と許容可能である場合、完全に新たなパケットを再生成してもよい（MAY）。
As noted in Section 2.1, the term "multicast domain" is used in a generic context for Layer-2 and Layer-3.
2.1節で述べたように、用語「マルチキャストドメインは、」レイヤ2およびレイヤ3のための一般的な文脈で使用されています。
A solution SHOULD NOT alter the boundaries of customer multicast domains. It MUST ensure that the provided Ethernet multicast domain always encompasses the corresponding customer Layer-3 multicast domain.
ソリューションは、顧客のマルチキャストドメインの境界を変更しないでください。それは提供イーサネットマルチキャストドメインは常に、対応する顧客レイヤ3マルチキャストドメインを包含することを保証しなければなりません。
A solution SHOULD optimize those domains' coverage sizes, i.e., a solution SHOULD ensure that unnecessary traffic is not sent to CEs with no members. Ideally, the provided domain size will be close to that of the customer's Layer-3 multicast membership distribution; however, it is OPTIONAL to achieve such absolute optimality from the perspective of Layer-3.
溶液、すなわち、溶液が不要なトラフィックがないメンバーとCEに送信されないことを確認する必要があり、それらのドメインカバレッジ・サイズを最適化する必要があります。理想的には、提供するドメインサイズは、顧客のレイヤ3マルチキャストメンバーシップの分布のそれに近くなります。しかし、レイヤ3の観点から、このような絶対的な最適性を達成するために任意です。
If a customer uses VLANs and a VLAN ID as a service delimiter (i.e., each VPLS instance is represented by a unique customer VLAN tag carried by a frame through the User Network Interface (UNI) port), a solution MUST provide a separate multicast domain for each VLAN ID. Note that if VLAN ID translation is provided (i.e., if a customer VLAN at one site is mapped into a different customer VLAN at a different site), multicast domains will be created per set of VLAN IDs that are associated with translation.
顧客がサービスデリミタとしてVLANを使用し、VLAN ID場合（すなわち、それぞれのVPLSインスタンスがユーザネットワークインタフェース（UNI）ポートを介してフレームによって運ばれる固有のカスタマVLANタグによって表される）、この溶液を別のマルチキャストドメインを提供しなければなりません各VLAN IDについて。 VLAN ID変換が（一つのサイトで顧客のVLANを異なる部位で異なる顧客VLANにマッピングされ、すなわち、あれば）が設けられている場合に、マルチキャストドメインは、翻訳に関連付けられているVLAN IDの組ごとに作成されることに注意してください。
If a customer uses VLANs but a VLAN ID is not a service delimiter (i.e., the VPN disregards customer VLAN IDs), a solution MAY provide a separate multicast domain for each VLAN ID. An SP is not mandatorily required to provide a separate multicast domain for each VLAN ID, but it may be considered beneficial to do so.
（すなわち、VPN顧客のVLAN IDを無視）顧客がVLANを使用するが、VLAN IDがサービス区切り文字でない場合、解決策は、各VLAN IDに対して別々のマルチキャストドメインを提供することができます。 SPは、強制的に各VLAN IDに個別のマルチキャストドメインを提供する必要はありませんが、それはそうすることは有益であると考えてよいです。
A solution MAY build multicast domains based on Ethernet MAC addresses. It MAY also build multicast domains based on the IP addresses inside Ethernet frames. That is, PEs in each VPLS instance might control forwarding behavior and provide different multicast frame reachability depending on each MAC/IP destination address separately. If IP multicast channels are fully considered in a solution, the provided domain size will be closer to actual channel reachability.
ソリューションは、イーサネットMACアドレスに基づいて、マルチキャストドメインを構築することができます。また、イーサネットフレーム内のIPアドレスに基づいて、マルチキャストドメインを構築することができます。それは、それぞれの転送動作を制御し、個別に各MAC / IP宛先アドレスに応じて異なるマルチキャストフレームの到達可能性を提供するかもしれないVPLSインスタンスでのPEです。 IPマルチキャストチャネルが完全に溶液中で考慮される場合は、提供ドメインサイズは、実際のチャネルの到達可能性に近くなります。
Customers require that multicast quality of service MUST be at least on par with what exists for unicast traffic. Moreover, as multicast is often used to deliver high-quality services such as TV broadcast, delay-, jitter-, and loss-sensitive traffic MUST be supported over multicast VPLS.
お客様は、サービスのマルチキャスト品質は、ユニキャストトラフィックのために存在するものと少なくとも同等でなければならないことを要求します。また、マルチキャストが、多くの場合、テレビ放送、遅延 - 、ジッタの、損失の影響を受けやすいトラフィックなどの高品質なサービスを提供するために使用されているように、マルチキャストVPLS上でサポートしなければなりません。
To accomplish this, the solution MAY have additional features to support high QoS such as bandwidth reservation and flow admission control. Also, multicast VPLS deployment SHALL benefit from IEEE 802.1p Class-of-Service (CoS) techniques [802.1D] and Diffserv [RFC2475] mechanisms.
これを達成するために、解決策は、帯域予約およびフローアドミッション制御など高いQoSをサポートするための追加的な特徴を有していてもよいです。また、マルチキャストVPLSの展開はIEEE 802.1P、サービスクラス（CoS）の技術[802.1D]とDiffserv [RFC2475]メカニズムから恩恵を受けるSHALL。
Moreover, multicast traffic SHOULD NOT affect the QoS that unicast traffic receives and vice versa. That is, separation of multicast and unicast traffic in terms of QoS is necessary.
また、マルチキャストトラフィックはトラフィックを受信し、その逆をユニキャストのQoSに影響を与えるべきではありません。これは、QoSの点では、マルチキャストおよびユニキャストトラフィックの分離が必要である、です。
Since SLA parameters are part of the service sold to customers, they simply want to verify their application performance by measuring the parameters SP(s) provide.
SLAパラメータが顧客に販売するサービスの一部であるため、彼らは単にSP（s）が提供する複数のパラメータを測定することによって、そのアプリケーションのパフォーマンスを検証したいです。
Multicast specific characteristics that may be monitored are, for instance, multicast statistics per stream (e.g., total/incoming/ outgoing/dropped traffic by period of time), one-way delay, jitter and group join/leave delay (time to start receiving traffic from a multicast group across the VPN since the join/leave was issued). An operator may also wish to compare the difference in one-way delay for a solitary multicast group/stream from a single, source PE to multiple receiver PEs.
例えば、監視されてもよいマルチキャスト固有の特性、ストリームあたりのマルチキャスト統計（例えば、合計/着信/発信/時間の周期でトラフィックをドロップ）、一方向遅延、ジッタ及びグループ参加/脱退遅延（時間は、受信を開始します/参加休暇が発行されて以来、VPN間でマルチキャストグループからのトラフィック）。オペレータはまた、複数の受信機のPEへの単一のソースPEから孤立マルチキャストグループ/ストリームに対して一方向遅延の差を比較することを望むかもしれません。
A solution SHOULD provide these parameters with Ethernet multicast group level granularity. (For example, a multicast MAC address will be one of those entries for classifying flows with statistics, delay, and so on.) However, if a solution is aimed at IP multicast transport efficiency, it MAY support IP multicast-level granularity.
溶液は、イーサネットマルチキャストグループ・レベルの粒度で、これらのパラメータを提供しなければなりません。 （例えば、マルチキャストMACアドレスは統計遅れてフローを分類するため、これらのエントリのいずれか、などであろう。）溶液をIPマルチキャスト輸送効率を目的としている場合は、それがIPマルチキャスト・レベルの細分性をサポートするかもしれません。
(For example, multicast IP address/channel will be entries for latency time.)
（例えば、マルチキャストIPアドレス/チャネルが待ち時間のエントリです。）
In order to monitor them, standard interfaces for statistics gathering SHOULD also be provided (e.g., standard Simple Network Management Protocol (SNMP) MIB Modules).
それらを監視するために、統計収集のための標準インターフェースも提供されるべきである（例えば、標準的な簡易ネットワーク管理プロトコル（SNMP）MIBモジュール）。
A solution MUST provide customers with architectures that give the same level of security both for unicast and multicast.
ソリューションは、ユニキャストとマルチキャストの両方のために同じレベルのセキュリティを与えるアーキテクチャをお客様に提供しなければなりません。
Solutions SHOULD NOT affect any forwarding information base, throughput, or resiliency, etc., of unicast frames; that is, they SHOULD provide isolation from unicast.
ソリューションは、ユニキャストフレームの転送情報ベース、スループット、または弾力性、等を及ぼしてはなりません。つまり、彼らは、ユニキャストからのアイソレーションを提供する必要があります。
A solution MAY filter multicast traffic inside a VPLS, upon the request of an individual customer, (for example, MAC/VLAN filtering, IP multicast channel filtering, etc.).
溶液は、個々の顧客の要求に応じて、VPLS内部マルチキャストトラフィックをフィルタリングすることができる（例えば、MAC / VLANフィルタリング、IPマルチキャストチャネルフィルタリング、等）。
A solution SHOULD support policing and shaping multicast traffic on a per-customer basis and on a per-AC (Attachment Circuit) basis. This is intended to prevent multicast traffic from exhausting resources for unicast inside a common customer's VPN. This might also be beneficial for QoS separation (see Section 5.3).
ソリューションはポリシングをサポートし、顧客単位であたり-AC（接続回線）毎にマルチキャストトラフィックを整形するべきです。これは、共通の顧客のVPN内のユニキャストのためのリソースを消耗からのマルチキャストトラフィックを防ぐことを目的としています。また、これは（5.3節を参照）QoSの分離のために有益であるかもしれません。
First and foremost, various physical connectivity types described in [RFC4665] MUST be supported.
まず第一に、[RFC4665]に記載された様々な物理的な接続タイプをサポートしなければなりません。
A multicast VPLS MUST allow a situation in which a CE is dual-homed to two different SPs via diverse access networks -- one is supporting multicast VPLS but the other is not supporting it, (because it is an existing VPLS or 802.1Q/QinQ network).
それは既存のVPLSまたは802.1Q / QinQのあるので、一つのマルチキャストVPLSをサポートしているが、他がそれをサポートしていない、（ - マルチキャストVPLSは、CEは、デュアルホームの多様なアクセスネットワークを介して、二つの異なるSPになっている状況を可能にしなければなりません通信網）。
A multicast VPLS infrastructure SHOULD allow redundant paths to assure high availability.
マルチキャストVPLSインフラは、冗長パスが高い可用性を確保することを可能にするべきです。
Multicast forwarding restoration time MUST NOT be greater than the time it takes a customer's Layer-3 multicast protocols to detect a failure in the VPLS infrastructure. For example, if a customer uses PIM with default configuration, the hello hold timer is 105 seconds, and solutions are required to restore a failure no later than this period. To achieve this, a solution might need to support providing alternative multicast paths.
マルチキャスト転送の復旧時間は、それがVPLSインフラの故障を検出するために、顧客のレイヤ3マルチキャストプロトコルのにかかる時間を超えてはなりません。顧客は、デフォルトの設定でPIMを使用した場合、ハローホールドタイマーは105秒で、解決策が遅くともこの時期よりも、障害を回復しないことが要求されます。これを達成するために、解決策は、代替マルチキャストパスの提供をサポートする必要がある場合があります。
Moreover, if multicast forwarding was not successfully restored (e.g., in case of no redundant paths), a solution MAY raise alarms to provide outage notification to customers before such a hold timer expires.
マルチキャスト転送が正常に（例えば、冗長パスの場合）が復元されなかった場合、保留タイマーが満了する前にさらに、溶液は、顧客に停止通知を提供するためにアラームを上げることができます。
Multicast applications are often sensitive to packet fragmentation and reassembly, so the requirement to avoid fragmentation might be stronger than the existing VPLS solution.
マルチキャストアプリケーションは、多くの場合、パケットの断片化と再組み立てに敏感であるため、断片化を回避するための要件は、既存のVPLSソリューションよりも強いかもしれません。
A solution SHOULD provide customers with enough committed minimum MTU (i.e., service MTU) for multicast Ethernet frames to ensure that IP fragmentation between customer sites never occurs. It MAY give different MTU sizes to multicast and unicast.
ソリューションは、顧客のサイト間のIP断片化が発生しないことを保証するために、マルチキャストイーサネットフレームのための十分なコミット最小MTU（すなわち、サービスMTU）を顧客に提供する必要があります。これは、マルチキャストおよびユニキャストに異なるMTUサイズを与えることができます。
A solution SHOULD attempt to prevent frame reordering when delivering customer multicast traffic. Likewise, for unicast and unknown unicast traffic, it SHOULD attempt not to increase the likelihood of reordering compared with existing VPLS solutions.
ソリューションは、顧客マルチキャストトラフィックを配信するときに、フレームの並べ替えを防ぐためにしようとするべきです。同様に、ユニキャストおよび未知のユニキャストトラフィックのために、それは既存のVPLSソリューションと比較して並べ替えの可能性を増加させない試みるべきです。
It is to be noted that delivery of out-of-order frames is not avoidable in certain cases. Specifically, if a solution adopts some MDTunnels (see Section 6.2) and dynamically selects them for optimized delivery (e.g., switching from one aggregate tree to another), end-to-end data delivery is prone to be out of order. This fact can be considered a trade-off between bandwidth optimization and network stability. Therefore, such a solution is expected to promote awareness about this kind of drawback.
これは、アウトオブオーダーフレームの送達は、特定の場合に避けられないことに留意すべきです。溶液は、（例えば、別の集約ツリーの切替）は、いくつかのMDTunnelsを採用している（セクション6.2を参照）、動的に最適化された送達のためにそれらを選択した場合、具体的に、エンド・ツー・エンドのデータ配信は、順不同である傾向があります。この事実は、帯域幅の最適化とネットワークの安定性とのトレードオフと考えることができます。したがって、このような解決策は欠点のこの種についての意識を促進することが期待されます。
In native Ethernet, multicast and unicast connectivity are often managed together. For instance, an 802.1ag CFM Continuity Check message is forwarded by multicast as a periodic heartbeat, but it is supposed to check the "whole" traffic continuity regardless of unicast or multicast, at the same time. Hence, the aliveness of unicast and multicast is naturally coupled (i.e., fate-shared) in this customer's environment.
ネイティブイーサネットでは、マルチキャストおよびユニキャストの接続性は、多くの場合、一緒に管理されています。例えば、802.1agのCFM連続性チェックメッセージを定期的にハートビートとしてマルチキャストで転送されますが、同時に、関係なく、ユニキャストまたはマルチキャストの「全体」トラフィックの継続性をチェックすることになっています。したがって、ユニキャストおよびマルチキャストの稼働状態が自然にこの顧客の環境で（すなわち、運命共有）結合されています。
A multicast VPLS solution may decouple the path that a customer's unicast and multicast traffic follow through a SP's backbone, in order to provide the most optimal path for multicast data traffic. This may cause concern among some multicast VPLS customers who desire that, during a failure in the SP's network, both unicast and multicast traffic fail concurrently.
マルチキャストVPLSソリューションは、顧客のユニキャストおよびマルチキャストトラフィックは、マルチキャストデータトラフィックのための最適なパスを提供するために、SPのバックボーンフォロースルーパスを切り離すことがあります。これは、SPのネットワークの障害時に、ユニキャストおよびマルチキャストトラフィックの両方が同時に故障し、ことを望むいくつかのマルチキャストVPLSの顧客の間で懸念を引き起こす可能性があります。
Therefore, there will be an additional requirement that makes both unicast and multicast connectivity coupled. This means that if either one of them have a failure, the other is also disabled. If one of the services (either unicast or multicast) becomes operational, the other is also activated simultaneously.
したがって、結合されたユニキャストとマルチキャストの両方の接続を行い、追加の要件が存在するであろう。これは、それらのいずれかが故障している場合は、他にも無効になっていることを意味しています。サービス（ユニキャストまたはマルチキャストのいずれか）のいずれかが動作可能になった場合、他方が同時に活性化されます。
- It SHOULD be identified if the solution can provide customers with fate-sharing between unicast and multicast connectivity for their LAN switching application. It MAY have a configurable mechanism for SPs to provide that on behalf of customers, e.g., aliveness synchronization, but its use is OPTIONAL.
- ソリューションが彼らのLANスイッチングアプリケーション用のユニキャストとマルチキャストの接続性との間に運命共有を顧客に提供できるかどうかは特定されるべきです。それは、例えば、稼働状態の同期を顧客に代わってそれを提供するために、SPのための設定可能な機構を有していてもよいが、その使用は任意です。
This policy will benefit customers. Some customers would like to detect failure soon at CE side and restore full connectivity by switching over to their backup line, rather than to keep poor half connectivity (i.e., either unicast or multicast being in fail). Even if either unicast or multicast is kept alive, it is just disadvantageous to the customer's application protocols that need both types of traffic. Fate-sharing policy contributes to preventing such a complicated situation.
このポリシーは、顧客の利益になります。一部のお客様には、CE側ですぐに障害を検出し、そのバックアップ回線に切り替えることにより、完全な接続を復元するのではなく、（すなわち、ユニキャストまたはFAILにあるマルチキャストのいずれか）が悪いの半分の接続性を維持するためにしたいと思います。ユニキャストまたはマルチキャストのいずれかが生かされていても、それはトラフィックの両方のタイプを必要とする顧客のアプリケーションプロトコルにだけ不利です。運命共有ポリシーでは、このような複雑な事態を防止することに貢献します。
Note that how serious this issue is depends on each customer's stance in Ethernet operation. If all CEs are IP routers, i.e., if VPLS is provided for a LAN routing application, the customer might not care about it because both unicast and multicast connectivity is assured in the IP layer. If the CE routers are running an IGP (e.g., OSPF/ IS-IS) and a multicast routing protocol (e.g., PIM), then aliveness of both the unicast and multicast paths will be detected by the CEs. This does not guarantee that unicast and multicast traffic are to follow the same path in the SP's backbone network, but does mitigate this issue to some degree.
どのように深刻なこの問題があることは、イーサネット操作で各顧客の立場に依存することに注意してください。すべてのCEは、IPルータの場合はVPLSは、LANのルーティングアプリケーションのために提供されている場合、ユニキャストとマルチキャストの両方の接続はIP層で保証されているので、すなわち、顧客がそれを気にしないことがあります。 CEルータはIGP（例えば、OSPF / IS-ISを）およびマルチキャストルーティングプロトコル（例えば、PIM）を実行している場合は、ユニキャストとマルチキャストの両方のパスの稼働状態は、複数のCEによって検出されます。これは、ユニキャストとマルチキャストトラフィックを保証するものではありませんSPのバックボーンネットワークで同じパスに従うことですが、ある程度この問題を緩和ありません。
The existing VPLS architecture has major advantages in scalability. For example, P-routers are free from maintaining customers' information because customer traffic is encapsulated in PSN tunnels. Also, a PW's split-horizon technique can prevent loops, making PE routers free from maintaining complicated spanning trees.
既存のVPLSアーキテクチャは、スケーラビリティの主要な利点があります。例えば、P-ルータは、顧客のトラフィックがPSNトンネルにカプセル化されているため、お客様の情報を維持することから自由です。また、PWのスプリットホライズンの技術は、複雑なスパニングツリーを維持から自由PEルータを作り、ループを防止することができます。
However, a multicast VPLS needs additional scalability considerations related to its expected enhanced mechanisms. [RFC3809] lists common L2VPN sizing and scalability requirements and metrics, which are applicable in multicast VPLS too. Accordingly, this section deals with specific requirements related to scalability.
しかし、マルチキャストVPLSは、その期待強化メカニズムに関連する追加のスケーラビリティの考慮が必要です。 [RFC3809]は、あまりにも、マルチキャストVPLSに適用される一般的なL2VPNのサイジングやスケーラビリティの要件や指標を、一覧表示されます。したがって、このセクションでは、拡張性に関連する特定の要件を扱っています。
A solution needs to improve the scalability of multicast as is shown in Section 3:
第3に示されているように、溶液は、マルチキャストのスケーラビリティを向上させる必要があります。
Issue A: Replication to non-member site.
発行A：非会員サイトへのレプリケーション。
Issue B: Replication of PWs on shared physical path.
発行B：共有物理パス上のPWレプリケーション。
For both issues, the optimization of physical resources (i.e., link bandwidth usage and router duplication performance) will become a major goal. However, there is a trade-off between optimality and state resource consumption.
両方の問題については、物理的なリソース（すなわち、リンク帯域幅の使用量とルータの重複性能）の最適化が大きな目標となります。しかし、最適と状態のリソース消費との間にはトレードオフが存在します。
In order to solve Issue A, a PE might have to maintain multicast group information for CEs that was not kept in the existing VPLS solutions. This will present scalability concerns about state resources (memory, CPU, etc.) and their maintenance complexity.
発行Aを解決するために、PEは、既存のVPLS溶液中に保持されなかったのCEのマルチキャストグループの情報を維持する必要がある場合があります。これは、状態のリソース（メモリ、CPUなど）とそれらのメンテナンスの複雑さに関するスケーラビリティの問題を提示します。
In order to solve Issue B, PE and P routers might have to have knowledge of additional membership information for remote PEs, and possibly additional tree topology information, when they are using point-to-multipoint (P2MP) techniques (PIM tree, P2MP-LSP (Label Switched Path), etc.).
彼らはポイントツーマルチポイント（P2MP）技術（PIMツリー、P2MP-を使用しているときに問題B、PEおよびPルータは、リモートのPEのための追加のメンバーシップ情報の知識、およびおそらく追加のツリートポロジ情報を持たなければならないかもしれない解決するためにLSP（ラベルスイッチパス）、など）。
Consequently, the scalability evaluation of multicast VPLS solutions needs a careful trade-off analysis between bandwidth optimality and state resource consumption.
その結果、マルチキャストVPLSソリューションのスケーラビリティの評価は、帯域幅の最適と状態のリソース消費の間で慎重なトレードオフ分析を必要とします。
(Note: This part has a number of similar characteristics to
requirements for Layer-3 Multicast VPN [RFC4834].)
A multicast VPLS solution MUST be designed to scale well with an increase in the number of any of the following metrics:
マルチキャストVPLS溶液は、以下のメトリックの任意の数の増加に伴ってうまくスケーリングするために設計されなければなりません。
- the number of PEs
- PEの数
- the number of VPLS instances (total and per PE)
- VPLSインスタンスの数（合計およびPEあたり）
- the number of PEs and sites in any VPLS instance
- 任意のVPLSインスタンス内のPEとサイトの数
- the number of client VLAN IDs
- クライアントVLAN IDの数
- the number of client Layer-2 MAC multicast groups
- クライアントレイヤ2 MACマルチキャストグループの数
- the number of client Layer-3 multicast channels (groups or source-groups)
- クライアントのレイヤ3マルチキャストチャネルの数（グループまたはソースグループ）
- the number of PWs and PSN Tunnels (MDTunnels) (total and per PE)
- のPWとPSNトンネル（MDTunnels）の数（合計およびPEあたり）
Each multicast VPLS solution SHALL document its scalability characteristics in quantitative terms. A solution SHOULD quantify the amount of state that a PE and a P device has to support.
各マルチキャストVPLSソリューションは、定量的にそのスケーラビリティ特性を文書化しなければなりません。溶液をPEとPデバイスがサポートする必要がある状態の量を定量化するべきです。
The scalability characteristics SHOULD include:
スケーラビリティの特性が含まれている必要があります
- the processing resources required by the control plane in managing PWs (neighborhood or session maintenance messages, keepalives, timers, etc.)
- のPWを管理する制御プレーンによって必要とされる処理リソース（近隣又はセッション維持メッセージ、キープアライブ、タイマー、等）
- the processing resources required by the control plane in managing PSN tunnels
- PSNトンネルを管理するには、コントロールプレーンで必要とされる処理リソース
- the memory resources needed for the control plane
- コントロールプレーンのために必要なメモリリソース
- the amount of protocol information transmitted to manage a multicast VPLS (e.g., signaling throughput)
- マルチキャストVPLSを管理するために送信プロトコル情報の量（例えば、シグナルスループット）
- the amount of Layer-2/Layer-3 multicast information a P/PE router consumes (e.g., traffic rate of join/leave, keepalives, etc.)
- レイヤ2 /レイヤ3マルチキャスト情報の量はP / PEルータ消費（例えば、等残す/参加のトラフィックレート、キープアライブ）
- the number of multicast IP addresses used (if IP multicast in ASM mode is proposed as a multicast distribution tunnel)
- 使用されるマルチキャストIPアドレスの数（ASMモードでIPマルチキャストをマルチキャスト配信トンネルとして提案されている場合）
- other particular elements inherent to each solution that impact scalability
- 各溶液に固有の他の特定の要素に影響スケーラビリティ
Another metric for scalability is operational complexity. Operations will naturally become more complicated if the number of managed objects (e.g., multicast groups) increases, or the topology changes occur more frequently. A solution SHOULD note the factors that lead to additional operational complexity.
スケーラビリティのためのもう一つの指標は、操作の複雑さです。管理オブジェクト（例えば、マルチキャストグループ）の数が増加、またはトポロジの変更がより頻繁に発生する場合の操作は、当然、より複雑になるであろう。解決策は、追加操作の複雑さにつながる要因を注意してください。
An MDTunnel denotes a multicast distribution tunnel. This is a generic term for tunneling where customer multicast traffic is carried over a provider's network. In the L2VPN service context, it will correspond to a PSN tunnel.
MDTunnelマルチキャスト配信トンネルを表します。これは、顧客のマルチキャストトラフィックはプロバイダのネットワーク上で伝送されるトンネルの総称です。 L2VPNサービスコンテキストには、PSNトンネルに対応することになります。
A solution SHOULD be able to use a range of tunneling technologies, including point-to-point (unicast oriented) and point-to-multipoint/ multipoint-to-multipoint (multicast oriented). For example, today there are many kinds of protocols for tunneling such as L2TP, IP, (including multicast IP trees), MPLS (including P2MP-LSP [RFC4875], and P2MP/MP2MP-LSP [LDP-P2MP]), etc.
溶液は、ポイントツーポイントトンネリングを含む技術の範囲を使用することができる必要があり（ユニキャスト配向）とポイントツーマルチポイント/マルチポイントツーマルチポイント（マルチキャスト指向）。例えば、今日のような、等L2TP、IP、（マルチキャストIPツリーを含む）、（P2MP-LSP [RFC4875]、およびP2MP / MP2MP-LSP [LDP-P2MP]を含む）、MPLSなどのトンネリングのためのプロトコルの多くの種類があります
Note that which variant, point-to-point, point-to-multipoint, or multipoint-to-multipoint, is used depends largely on the trade-offs mentioned above and the targeted network and applications. Therefore, this document does not mandate any specific protocols. A solution, however, SHOULD state reasonable criteria if it adopts a specific kind of tunneling protocol.
その変異体、ポイントツーポイント、ポイントツーマルチポイント、またはマルチポイントツーマルチなお、使用される前述のトレードオフとターゲットネットワークとアプリケーションに大きく依存します。したがって、この文書は、いかなる特定のプロトコルを規定していません。それはトンネリングプロトコルの特定の種類を採用した場合、溶液は、しかし、合理的な条件を明記してください。
From the view of an SP, it is not acceptable to have fragmentation/ reassembly so often while packets are traversing a MDTunnel. Therefore, a solution SHOULD support a method that provides the minimum path MTU of the MDTunnel in order to accommodate the service MTU.
パケットがMDTunnelを横断している間、SPの観点からは、それほど頻繁に断片化/再組み立てを持つことが許されません。したがって、解決策は、サービスMTUを収容するためにMDTunnelの最小パスMTUを提供する方法をサポートする必要があります。
Multicast VPLS solutions SHOULD avoid single points of failures or propose technical solutions that make it possible to implement a failover mechanism.
マルチキャストVPLSソリューションは、単一障害点を回避またはフェールオーバーメカニズムを実装することを可能にする技術的なソリューションを提案すべきです。
The operation of a multicast VPLS solution SHALL be as light as possible, and providing automatic configuration and discovery SHOULD be considered a high priority.
マルチキャストVPLS溶液の操作は、できるだけ軽いものでなければならない、自動コンフィギュレーションおよび発見を提供することは高い優先順位を考慮すべきです。
Therefore, in addition to the L2VPN discovery requirements in [RFC4665], a multicast VPLS solution SHOULD provide a method that dynamically allows multicast membership information to be discovered by PEs if the solution supports (A), as defined in Section 3.2. This means, a PE needs to discover multicast membership (e.g., join group addresses) that is controlled dynamically from the sites connected to that PE. In addition, a PE needs to discover such information automatically from other remote PEs as well in order to limit flooding scope across the backbone.
したがって、[RFC4665]でL2VPN発見の要件に加えて、マルチキャストVPLSソリューションを動的マルチキャストメンバシップ情報は、のPEによって発見されることを可能にする方法を提供する必要がある場合、セクション3.2で定義されるように溶液を支持体（A）。これは、PEがそのPEに接続されたサイトから動的に制御される（例えば、グループアドレスに参加する）マルチキャストメンバーシップを発見する必要がある、ことを意味します。また、PEは、バックボーンを横切る氾濫範囲を制限するために、他の遠隔のPEから自動的にそのような情報を発見する必要があります。
The activation of multicast enhancement in a solution MUST be possible:
溶液中のマルチキャスト増強の活性化が可能でなければなりません。
o with a VPLS instance granularity.
VPLSインスタンスの粒度で、O。
o with an Attachment Circuit granularity (i.e., with a PE-CE Ethernet port granularity, or with a VLAN ID granularity when it is a service delimiter).
（それがサービスデリミタである場合、すなわち、PE-CEイーサネットポートの粒度を有する、またはVLAN IDの粒度で）アタッチメント回路粒度で、O。
Also it SHOULD be possible:
また、それは可能なはずです。
o with a CE granularity (when multiple CEs of the same VPN are associated with a common VPLS instance).
CEの粒度を有するO（同じVPNの複数のCEが共通のVPLSインスタンスに関連付けられている場合）。
o with a distinction between multicast reception and emission.
マルチキャスト受信と発光との間の区別と、O。
o with a multicast MAC address granularity.
マルチキャストMACアドレス粒度で、O。
o with a customer IP multicast group and/or channel granularity (when Layer-3 information is consulted).
顧客IPマルチキャストグループ及び/又は（レイヤ3情報が参照される）チャネル粒度で、O。
Also it MAY be possible:
また、それは可能かもしれません。
o with a VLAN ID granularity when it is not a service delimiter.
VLAN IDの粒度で、O、それがサービス区切り文字でない場合。
A solution MUST provide a mechanism for testing multicast data connectivity and verifying the associated information. Examples that SHOULD be supported that are specific to multicast are:
溶液は、マルチキャストデータの接続性をテストし、関連情報を検証するためのメカニズムを提供しなければなりません。マルチキャストに固有のサポートされるべきである（SHOULD）例は以下のとおりです。
- Testing connectivity per multicast MAC address
- マルチキャストMACアドレスごとのテスト接続
- Testing connectivity per multicast Layer-3 group/channel
- マルチキャストレイヤ3グループ/チャンネルあたりのテスト接続
- Verifying data plane and control plane integrity (e.g., PW, MDTunnel)
- データ・プレーンと制御プレーンの完全性の検証（例えば、PW、MDTunnel）
- Verifying multicast membership-relevant information (e.g., multicast MAC-addresses/PW-ports associations, Layer-3 group associations)
- 検証マルチキャストメンバーシップ関連情報（例えば、マルチキャストMAC-アドレス/ PW-ポートの関連付け、レイヤ3グループの関連付け）
Operators usually want to test if an end-to-end multicast user's connectivity is OK before and after activation. Such end-to-end multicast connectivity checking SHOULD enable the end-to-end testing of the data path used by that customer's multicast data packets. Specifically, end-to-end checking will have a CE-to-CE path test and PE-to-PE path test. A solution MUST support the PE-to-PE path test and MAY support the CE-to-CE path test.
オペレータは通常、エンド・ツー・エンドのマルチキャストユーザの接続が活性化の前と後にOKかどうかをテストします。このようなエンドツーエンドのマルチキャスト接続のチェックは、その顧客のマルチキャストデータパケットが使用するデータパスのエンド・ツー・エンドのテストを有効にする必要があります。具体的には、エンドツーエンドのチェックは、CE-に-CEパス試験及びPE-に-PEパス試験を有することになります。溶液は、PE-に-PEパス試験をサポートしなければならないとCEツーCEパスのテストをサポートするかもしれません。
Also, operators will want to make use of a testing mechanism for diagnosis and troubleshooting. In particular, a solution SHOULD be able to monitor information describing how client multicast traffic is carried over the SP network. Note that if a solution supports frequent dynamic membership changes with optimized transport, troubleshooting within the SP's network will tend to be difficult.
また、オペレータは、診断とトラブルシューティングのためのテストメカニズムを利用することになるでしょう。具体的には、溶液は、クライアントマルチキャストトラフィックは、SPネットワークを介して実施される方法を記述する情報を監視することができるべきです。ソリューションが最適化された輸送と頻繁に動的なメンバシップの変更をサポートしている場合、SPのネットワーク内のトラブルシューティングが困難になる傾向があることに注意してください。
Mechanisms to monitor multicast-specific parameters and statistics MUST be offered to the SP.
マルチキャスト固有のパラメータと統計を監視するためのメカニズムは、SPに提供されなければなりません。
(Note: This part has a number of similar characteristics to requirements for Layer 3 Multicast VPN [RFC4834].)
（注：この部分は、レイヤ3マルチキャストVPN [RFC4834]の要件と同様の特性の数を有します。）
A solution MUST provide SPs with access to:
ソリューションは、へのアクセスでのSPを提供する必要があります。
- Multicast traffic statistics (total traffic forwarded, incoming, outgoing, dropped, etc., by period of time).
- マルチキャストトラフィック統計（総トラフィックは、ある期間により、等、発信、着信、転送滴下しました）。
A solution SHOULD provide access to:
ソリューションは、へのアクセスを提供する必要があります。
- Information about a customer's multicast resource usage (the amount of multicast state and throughput).
- 顧客のマルチキャストリソースの使用状況（マルチキャスト状態とスループットの量）に関する情報。
- Performance information related to multicast traffic usage, e.g., one-way delay, jitter, loss, delay variations (the difference in one-way delay for a solitary multicast group/stream from a single, source PE to multiple receiver PEs), etc.
- マルチキャストトラフィックの使用、例えば、一方向遅延、ジッタ、損失、遅延変動など、（複数の受信PEへ単一のソースPEから孤立マルチキャストグループ/ストリームのための一方向遅延の差）に関する性能情報。
- Alarms when limits are reached on such resources.
- アラーム限度は、このようなリソースに達しています。
- Statistics on decisions related to how client traffic is carried on MDTunnels (e.g., "How much traffic was switched onto a multicast tree dedicated to such groups or channels").
- クライアントトラフィックがMDTunnels（例えば、「トラフィックはそのようなグループまたはチャネル専用のマルチキャストツリーに切り替えたどのくらい」）に担持される方法に関連する意思決定に関する統計。
- Statistics on parameters that could help the provider to evaluate its optimality/state trade-off.
- その最適/状態のトレードオフを評価するために、プロバイダを助けることができるパラメータの統計。
All or part of this information SHOULD be made available through standardized SNMP MIB Modules (Management Information Base).
この情報の全てまたは一部は、標準化されたSNMP MIBモジュール（管理情報ベース）を介して利用できるようにすべきです。
A multicast VPLS solution needs to consider those management steps taken by SPs below:
マルチキャストVPLSソリューションは、以下のSPで撮影したものを管理手順を検討する必要があります。
o Fault detection
Oフォルト検出
A solution MUST provide tools that detect group membership/
reachability failure and traffic looping for multicast
transport. It is anticipated that such tools are coordinated
with the testing mechanisms mentioned in Section 6.5.2.
In particular, such mechanisms SHOULD be able to detect a multicast failure quickly, (on par with unicast cases). It SHOULD also avoid situations where multicast traffic has been in a failure state for a relatively long time while unicast traffic remains operational. If such a situation were to occur, it would end up causing problems with customer applications that depend on a combination of unicast and multicast forwarding.
特に、そのようなメカニズムは、（ユニキャストの場合と同等の）、迅速マルチキャスト故障を検出することができるべきです。また、ユニキャストトラフィックが稼働したままの状態で、マルチキャストトラフィックは、比較的長い時間のために障害状態になっている状況を回避すべきです。このような状況が発生した場合、それはユニキャストとマルチキャスト転送の組み合わせに依存して、顧客のアプリケーションとの問題を引き起こしてしまうでしょう。
With multicast, there may be many receivers associated with a particular multicast stream/group. As the number of receivers increases, the number of places (typically nearest the receivers) required to detect a fault will increase proportionately. This raises concerns over the scalability of fault detection in large multicast deployments. Consequently, a fault detection solution SHOULD scale well; in particular, a solution should consider key metrics for scalability as described in Section 6.1.2.
マルチキャストを用いて、特定のマルチキャストストリーム/グループに関連付けられた多くの受信機が存在してもよいです。受信機の数が増加するように、故障を検出するのに必要な桁数（典型的に最も近い受信機）は比例し増加します。これは、大規模なマルチキャスト展開における障害検出のスケーラビリティに対する懸念を提起します。従って、故障検出溶液は、十分にスケーリングすべきです。 6.1.2項で説明したように、特に、解決策は、スケーラビリティのための主要な指標を検討すべきです。
o Fault notification
O障害通知
A solution MUST also provide fault notification and trouble
tracking mechanisms (e.g., SNMP-trap and syslog).
In case of multicast, one point of failure often affects a number of downstream routers/receivers that might be able to raise a notification. Hence, notification messages MAY be summarized or compressed for operators' ease of management.
マルチキャストの場合は、故障の一点は、多くの場合、通知を上げることができるかもしれない下流のルータ/受信機の数に影響を与えます。したがって、通知メッセージは、管理の事業者容易にするために要約または圧縮することができます。
o Fault isolation
O障害分離
A solution MUST provide diagnostic/troubleshooting tools for
multicast as well. Also, it is anticipated that such tools are
coordinated with the testing mechanisms mentioned in
Section 6.5.2.
In particular, a solution needs to correctly identify the area inside a multicast group impacted by the failure. A solution SHOULD be able to diagnose if an entire multicast group is faulty or if some specific destinations are still alive.
具体的には、溶液が正しく障害によって影響を受けるマルチキャストグループ内の領域を特定する必要があります。いくつかの特定の宛先がまだ生きているならば、全体のマルチキャストグループに障害がある場合、または解決策を診断することができるべきです。
In multicast VPLS, there is a concern that one or more customer nodes (presumably untrusted) might cause multicast-related attacks to the SP network. There is a danger that it might compromise some components that belong to the whole system.
マルチキャストVPLSでは、（おそらく信頼されていない）は、1つのまたは複数の顧客ノードがSPネットワークへのマルチキャスト関連の攻撃を引き起こす可能性が懸念されます。それは、システム全体に属しているいくつかのコンポーネントを危うくするかもしれないという危険性があります。
This subsection states possible security threats relevant to the system and whether or not they are protected against.
このサブセクションでは、システムに関連しているか否か、彼らはから保護されている潜在的なセキュリティ上の脅威を述べています。
General security consideration about a base VPLS (as part of L2VPNs) is referred to in [RFC4665]. The following is the threat analysis list that is inherent to multicast VPLS.
（のL2VPNの一部として）基地VPLSについての一般的なセキュリティ上の配慮は、[RFC4665]で言及されています。以下では、マルチキャストVPLSに固有の脅威解析リストです。
(a) Attack by a huge amount of multicast control packets.
マルチキャスト制御パケットの膨大な量によって（a）の攻撃。
There is a threat that a CE joins too many multicast groups and
causes Denial of Service (DoS). This is caused by sending a
large number of join/prune messages in a short time and/or putting a large variety of group addresses in join/prune
messages. This attack will waste PE's control resources (e.g.,
CPU, memory) that examine customer control messages (for solving
Issue A in Section 3.2), and it will not continue expected
services for other trusted customers.
(b) Attack by invalid/malformed multicast control packets.
無効/不正な形式のマルチキャスト制御パケットによって、（b）にアタック。
There is a threat that a CE sends invalid or malformed control
packets that might corrupt PE, which will cause a DoS attack.
In particular, a CE might be spoofing legitimate source/group IP
multicast addresses in such control packets (in PIM, IGMP, etc.)
and source/destination MAC addresses as Layer-2 frames.
(c) Attack by rapid state change of multicast.
マルチキャストの急激な状態変化によって、（c）にアタック。
If a malicious CE changes multicast state by sending control
packets in an extremely short period, this might affect PE's
control resources (e.g., CPU, memory) to follow such state
changes. Besides, it might also affect PE/P's control resources
if MDTunnel inside the core is dynamically created in
conjunction with customer's multicast group.
(d) Attack by high volume of multicast/broadcast data traffic.
（d）のマルチキャスト/ブロードキャストデータトラフィックの高容量でアタック。
A malicious CE might send a very high volume of multicast and/or
broadcast data to a PE. If that PE does not provide any
safeguards, it will cause excessive replication in the SP
network and the bandwidth resources for other trusted customers
might be exhausted.
(e) Attack by high volume of unknown destination unicast data traffic.
未知の宛先ユニキャストデータトラフィックの高い体積（e）にアタック。
A malicious CE can send a high volume of unknown unicast to a
PE. Generally, according to VPLS architecture, that PE must
flood such unknown traffic to all corresponding PEs in the same
VPN. A variety of unknown destinations and huge amount of such
frames might cause excess traffic in SP network unless there is
an appropriate safeguard provided.
Based on the analysis in the previous subsection, the security requirements from the SP's perspective are shown as follows.
次のように前節での分析に基づき、SPの視点からセキュリティ要件が示されています。
An SP network MUST be invulnerable to malformed or maliciously constructed customer traffic. This applies to both multicast data packets and multicast control packets.
SPのネットワークは、不正な形式または悪意を持って構築された顧客のトラフィックに対して強固でなければなりません。これは、マルチキャストデータパケットおよびマルチキャスト制御パケットの両方に適用されます。
Moreover, because multicast, broadcast, and unknown-unicast need more resources than unicast, an SP network MUST have safeguards against unwanted or malicious multicast traffic. This applies to both multicast data packets and multicast control packets.
マルチキャスト、ブロードキャスト、および未知のユニキャストは、ユニキャストよりも多くのリソースを必要とするので、また、SPネットワークが不要なまたは悪意のあるマルチキャストトラフィックに対するセーフガードを持たなければなりません。これは、マルチキャストデータパケットおよびマルチキャスト制御パケットの両方に適用されます。
Specifically, a multicast VPLS solution SHOULD have mechanisms to protect an SP network from:
具体的には、マルチキャストVPLS溶液からSPネットワークを保護する仕組みが必要です。
(1) invalid multicast MAC addresses
（1）無効マルチキャストMACアドレス
(2) invalid multicast IP addresses
（2）無効マルチキャストIPアドレスを
(3) malformed Ethernet multicast control protocol frames
（3）不正なイーサネットマルチキャスト制御プロトコル・フレーム
(4) malformed IP multicast control protocol packets
（4）不正なIPマルチキャスト制御プロトコル・パケット
(5) high volumes of
（5）大量の
* valid/invalid customer control packets
*有効/無効顧客制御パケット
* valid/invalid customer data packets (broadcast/multicast/ unknown-unicast)
*有効/無効の顧客データ・パケット（ブロードキャスト/マルチキャスト/不明なユニキャスト）
Depending on each solution's actual approach to tackle with Issue A, or B, or both (see Section 3.2.), there are relationships to be highlighted about each item's importance listed above. First off, protection against (3) and (4) becomes significantly important if a solution supports solving Issue A, and PEs are processing customer's Ethernet/IP multicast control messages from CE. Moreover, protection against (2) should also be much focused because PIM/IGMP snooping will usually require that PE's data forwarding be based on IP addresses. By contrast, however, if a solution is solving only Issue B, not A, then PEs might never process the customer's multicast control messages at all; they do not perform IP address-based forwarding, but they do perform native Ethernet forwarding. If so, there is relatively less danger about (2), (3), and (4) compared to the first case.
発行A、またはB、またはその両方と取り組むために、各溶液の実際のアプローチに応じて（セクション3.2を参照。）、上記各項目の重要性について強調表示される関係が存在します。まず第一に、（3）に対する保護およびソリューションが発行Aを解決し、PEがCEから顧客のイーサネット/ IPマルチキャスト制御メッセージを処理しているサポートしている場合（4）非常に重要になります。 PIM / IGMPスヌーピングは通常、PEのデータ転送がIPアドレスに基づいてされている必要がありますので、また、保護は、（2）も非常に集中する必要があります。解決策が唯一の発行B、ない解決された場合はこれとは対照的に、しかし、その後、PEは、すべての顧客のマルチキャスト制御メッセージを処理することはありませんかもしれません。彼らは、IPアドレスベース転送を行いませんが、ネイティブのイーサネット転送を行いません。もしそうであれば、約比較的少ない危険性がある（2）、（3）、（4）第一の場合に比べ。
The following are a few additional guidelines in detail.
以下、詳細にいくつかの追加的なガイドラインです。
For protecting against threat (a), a solution SHOULD support imposing some bounds on the quantity of state used by a VPN to be imposed in order to prevent state resource exhaustion (i.e., lack of memory, CPU etc.). In this case, the bounds MUST be configurable per VPN basis, not the total of various VPNs so that SP can isolate the resource waste that is caused by any malicious customer.
（a）は、溶液がサポートする脅威から保護VPNによって使用される状態量にいくらかの限界を課すための状態資源の枯渇（すなわち、メモリの不足、CPU等）を防止するために課されます。 SPは、任意の悪意のある顧客に起因するリソースの浪費を単離することができるように、この場合には、境界は、VPNの基礎ではなく、種々のVPNの合計ごとに設定していなければなりません。
For protecting against threat (d) and (e), a solution SHOULD support performing traffic policing to limit the unwanted data traffic shown above. In this case, while policing MAY be configurable to the sum of unicast, multicast, broadcast, and unknown unicast traffic, it SHOULD also be configurable to each such type of traffic individually in order to prevent physical resource exhaustion (i.e., lack of bandwidth and degradation of throughput). If the policing limit is configured on total traffic only, there will be a concern that one customer's huge multicast might close other irrelevant unicast traffic. If it can be configured individually, this concern will be avoided. Moreover, such a policing mechanism MUST be configurable per VPN basis, not the total of various VPNs to isolate malicious customer's traffic from others.
脅威（d）及び（e）から保護するために、溶液は、上記の不要なデータトラフィックを制限するために、トラフィックポリシングを行うサポートすべきです。この場合は、ポリシングは、ユニキャスト、マルチキャスト、ブロードキャスト、および未知のユニキャストトラフィックの合計に設定可能であるかもしれないが、それはまた、個別に（すなわち、帯域幅の不足や物理的なリソースの枯渇を防ぐために、トラフィックのような各タイプに設定可能であるべきですスループットの低下）。ポリシング制限が総トラフィック上に構成されている場合のみ、1人の顧客の巨大なマルチキャストは、他の無関係なユニキャストトラフィックを閉じるかもしれないという懸念があるでしょう。それは個別に設定することができた場合は、この懸念は回避されます。また、このようなポリシング機構は、VPNベースごとに設定していなければなりませんていない様々なVPNの合計は、他の悪意のある顧客のトラフィックを分離します。
For protecting against threat (c), a solution SHOULD be able to limit frequent changes of group membership by customers. For example, PEs might support a dampening mechanism that throttles their multicast state changes if the customers are changing too excessively. Also, if MDTunnel is provided being tightly coupled to dynamic changes of customer's multicast domain, it is also effective to delay building the tunnel when customer's state is changed frequently.
脅威（C）から保護するために、溶液は、顧客によってグループメンバーシップの頻繁な変更を制限することができるべきです。例えば、PEは、顧客があまりにも過度に変化している場合は、そのマルチキャスト状態変化を絞るダンパー機構をサポートする場合があります。 MDTunnelがしっかり顧客のマルチキャストドメインの動的な変化に結合されて提供される場合にも、顧客の状態が頻繁に変更されたときにトンネルを構築遅らせることも有効です。
Protecting against threat (b) might not be an easy task. Generally, checking the legitimacy of a customer's IP multicast control packets will eventually require the authentication between PE and CE in Layer-3; however, L2VPN (including VPLS) by its nature does not usually assume Layer-3-based security mechanism supported at PE-CE level.
（b）の脅威から保護することが容易な仕事ではないかもしれません。一般的に、顧客のIPマルチキャスト制御パケットの正当性をチェックすると、最終的にレイヤ3でPEとCE間の認証が必要になります。しかし、その性質によって（VPLSを含む）L2VPNは、通常、PE-CEレベルでサポートされているレイヤ3ベースのセキュリティ・メカニズムを想定していません。
The ramification of this fact is that there remains a possibility that a PE's control plain might be badly affected by corrupted multicast control packets that the PE is examining. Hence, each PE implementation will need to make an effort to minimize this impact from malicious customers and isolate it from other trusted customers as much as possible.
この事実の枝分かれは、PEのコントロールプレーンがひどくPEが検討されて破損したマルチキャスト制御パケットによって影響を受ける可能性があるという可能性が残っていることです。したがって、各PEの実装は、悪意のある顧客から、この影響を最小限に抑え、可能な限り他の信頼できる顧客からそれを分離するために努力をする必要があります。
Nevertheless, it is possible to mitigate this threat to some degree. For example, a PE MAY support a filter mechanism about MAC and IP addresses in a Layer-2/Layer-3 header and a filter mechanism about source/group addresses in the multicast join/prune messages. This will help a PE to validate customers' control messages, to a certain extent.
それにもかかわらず、ある程度、この脅威を軽減することが可能です。例えば、PEは、レイヤ2 /レイヤ3ヘッダ内のMACとIPアドレスに関するフィルタ機構とソース約フィルタ機構をサポートする、および/マルチキャストのグループアドレス/プルーンメッセージに参加します。これは、ある程度、顧客の制御メッセージを検証するためにPEを助けます。
A VPLS multicast solution SHOULD allow a hierarchical VPLS (H-VPLS) [RFC4762] service model. In other words, a solution is expected to operate seamlessly with existing hub and spoke PW connectivity.
VPLSマルチキャストソリューションは、階層VPLS（H-VPLS）[RFC4762]サービス・モデルを可能にすべきです。言い換えれば、解決策は、既存のハブとシームレスに動作することが期待さとPWの接続性を話しています。
Note that it is also important to take into account the case of redundant spoke connections between U-PEs and N-PEs.
冗長の場合は、U-PEとN-PE間の接続を話し考慮することも重要であることに注意してください。
A solution MUST allow a situation where one SP is offering L2VPN services to another SP. One example here is a wholesale model where one VPLS interconnects other SPs' VPLS or 802.1D network islands. For customer SPs, their multicast forwarding can be optimized by making use of multicast VPLS in the wholesaler SP.
解決策は、1つのSPは別のSPへのL2VPNサービスを提供している状況を許容しなければなりません。ここでの一つの例では、1つのVPLS相互接続他のSPのはVPLSまたは802.1Dネットワークの島々卸売モデルです。顧客のSPの場合は、そのマルチキャスト転送は、卸売業者のSPでのマルチキャストVPLSを利用することによって最適化することができます。
Security concerns and requirements for a base VPLS solution are described in [RFC4665].
ベースVPLSソリューションのセキュリティ上の懸念と要件は[RFC4665]で説明されています。
In addition, there are security considerations specific to multicast VPLS. Thus, a set of security issues have been identified that MUST be addressed when considering the design and deployment of multicast VPLS. Such issues have been described in Sections 5.5 and 6.6.
また、マルチキャストVPLSに特定のセキュリティの考慮事項があります。このように、セキュリティ問題のセットは、マルチキャストVPLSの設計と導入を検討する際に対処する必要があることを確認されています。このような問題は、セクション5.5および6.6に記載されています。
In particular, security requirements from the view of customers are shown in Section 5.5. Security requirements from the view of providers are shown in Section 6.6. Section 6.6.1 conducts security threat analysis about the provider's whole system. Section 6.6.2 explains how each threat can be addressed or mitigated.
具体的には、顧客の観点から、セキュリティ要件は、5.5節に示されています。プロバイダの観点から、セキュリティ要件は、6.6節に示されています。 6.6.1項では、プロバイダのシステム全体に関するセキュリティ脅威分析を行っています。 6.6.2項では、それぞれの脅威に対処または緩和することができる方法を説明します。
The authors thank the contributors of [RFC4834] since the structure and content of this document were, for some sections, largely inspired by [RFC4834].
このドキュメントの構造と内容は、いくつかのセクションでは、主に[RFC4834]に触発されたので、著者は、[RFC4834]の貢献に感謝します。
The authors also thank Yuichi Ikejiri, Jerry Ash, Bill Fenner, Vach Kompella, Shane Amante, Ben Niven-Jenkins, and Venu Hemige for their valuable reviews and feedback.
著者はまた、貴重なレビューとフィードバックのため雄一池尻、ジェリー・アッシュ、ビルフェナー、VACH Kompella、シェーンAmante、ベン・ニーヴン・ジェンキンス、およびVENU Hemigeに感謝します。
[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月。
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006.
[RFC4665]アウグスティン、W.およびY. Serbest、 "レイヤーのためのサービスの要件2プロバイダ・プロビジョニングされた仮想プライベートネットワーク"、RFC 4665、2006年9月。
[802.1D] IEEE Std 802.1D-2004, "IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges", 2004.
[802.1D] IEEE 802.1D STD-2004、 "地方とメトロポリタンエリアネットワークのIEEE標準：メディアアクセス制御（MAC）ブリッジ"、2004年。
[802.1ag] IEEE Std 802.1ag-2007, "Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management", 2007.
[802.1ag] IEEE STDの802.1ag-2007、 "仮想ブリッジローカルエリアネットワーク - 修正5：接続障害管理"、2007年。
[802.1s] IEEE Std 802.1s-2002, "Virtual Bridged Local Area Networks - Amendment 3: Multiple Spanning Trees", 2002.
[802.1] IEEE STD 802.1-2002、 "仮想ブリッジローカルエリアネットワーク - 改正3：複数のスパニングツリー"、2002。
[CGMP] Farinacci, D., Tweedly, A., and T. Speakman, "Cisco Group Management Protocol (CGMP)", 1996/1997, <ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt>.
[CGMP]ファリナッチ、D.、Tweedly、A.、およびT.スピークマン、 "シスコグループ管理プロトコル（CGMP）"、1996/1997、<ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt >。
[LDP-P2MP] Minei, I., Ed., Kompella, K., Wijnands, I., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, May 2008.
[LDP-P2MP] Minei、I.、エド。、Kompella、K.、Wijnands、I.、およびB.トーマス、 "ラベル配布プロトコルの拡張ポイント・ツー・マルチポイントおよびマルチポイント・ツー・マルチポイントラベルは、パスの交換"、進歩、2008年5月に働いています。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]フェナー、W.、 "インターネットグループ管理プロトコル、バージョン2"、RFC 2236、1997年11月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "IPv6のためのマルチキャストリスナー発見（MLD）"、RFC 2710、1999年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3488]呉、I.およびT.エッカート、 "シスコシステムズルータポートグループ管理プロトコル（RGMP）"、RFC 3488、2003年2月。
[RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[RFC3809] Nagarajan、A.、 "プロバイダプロビジョニングされた仮想プライベートネットワーク（PPVPN）のための一般的要件"、RFC 3809、2004年6月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、RFC 3810、2004年6月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]アダムス、A.、ニコラス、J.、およびW. Siadak、 "プロトコル独立マルチキャスト - 稠密モード（PIM-DM）：プロトコル仕様（改訂）"、RFC 3973、2005年1月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541]クリステンセン、M.、キンボール、K.、およびF. Solensky、RFC 4541、2006年5月、 "インターネットグループ管理プロトコル（IGMP）とMulticast Listener Discovery（MLD）スヌーピングスイッチの考慮事項"。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]アンデション、L.およびE.ローゼン、 "レイヤのためのフレームワーク2個の仮想プライベートネットワーク（のL2VPN）"、RFC 4664、2006年9月。
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4761] Kompella、K.とY. Rekhter、 "自動検出およびシグナリングのためにBGPを使用した仮想プライベートLANサービス（VPLS）"、RFC 4761、2007年1月。
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[RFC4762] Lasserre、M.およびV. Kompella、 "仮想プライベートLANサービス（VPLS）ラベル配布プロトコル（LDP）シグナリングの使用"、RFC 4762、2007年1月を。
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[RFC4834]モリン、T.、エド。、 "レイヤーでのマルチキャストのための要件3プロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）"、RFC 4834、2007年4月。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]アガルワル、R.、Papadimitriou、D.、およびS.安川は、 - 、、RFC 4875の "機能拡張は、予約プロトコルリソースへのポイントツーマルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）がスイッチパス（LSP）" 2007年5月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]ハンドレー、M.、Kouvelas、I.、スピークマン、T.、およびL. Vicisano、 "双方向プロトコル独立マルチキャスト（BIDIR-PIM）"、RFC 5015、2007年10月。
Authors' Addresses
著者のアドレス
Yuji Kamite (editor) NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: y.kamite@ntt.com
雄二Kamite（編集者）NTTコミュニケーションズ株式会社グランパークタワー芝浦3-4-1、東京都港区108から8118日本電子メール：y.kamite@ntt.com
Yuichiro Wada NTT 3-9-11 Midori-cho Musashino-shi Tokyo 180-8585 Japan EMail: wada.yuichiro@lab.ntt.co.jp
ゆいちろ わだ んっｔ ３ー９ー１１ みどりーちょ むさしのーし ときょ １８０ー８５８５ じゃぱん えまいｌ： わだ。ゆいちろ＠ぁｂ。んっｔ。こ。ｊｐ
Yetik Serbest AT&T Labs 9505 Arboretum Blvd. Austin, TX 78759 USA EMail: yetik_serbest@labs.att.com
Yetik Serbest AT＆T Labsの9505植物園ブルバードオースティン、TX 78759 USA Eメール：yetik_serbest@labs.att.com
Thomas Morin France Telecom R&D 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: thomas.morin@francetelecom.com
トーマス・モリンフランステレコムR＆D 2、大通りピエールMarzin 22307ラニオンCedexのフランス電子メール：thomas.morin@francetelecom.com
Luyuan Fang Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: lufang@cisco.com
Luyuan牙シスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719 USA Eメール：lufang@cisco.com