[要約] 要約：RFC 5501は、仮想プライベートLANサービス（VPLS）でのマルチキャストサポートの要件について説明しています。 目的：このRFCの目的は、VPLS環境でのマルチキャストトラフィックの効率的な配信と管理を実現するための要件を定義することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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は、パケットスイッチネットワーク（PSN）バックボーンを介していくつかの顧客LANセグメントを相互接続し、マルチポイントツーマルチポイントイーサネットVPNを作成します。顧客にとって、彼らのリモート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（PSEUDOWIRE）ベースでのMACアドレス学習/老化が必要です。
VPLS is a Layer-2 (L2) service. However, it provides two applications from the customer's point of view:
VPLSはレイヤー2（L2）サービスです。ただし、顧客の観点から2つのアプリケーションを提供します。
- 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.
したがって、場合によっては、MAN/WANの顧客は透明なレイヤー2接続を持っていますが、主な目標は、ルーティングドメイン内でレイヤー3アプリケーションを実行することです。その結果、さまざまなアプリケーションからさまざまな要件が生じます。
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トランスポートブロードキャスト/マルチキャストイーサネットフレームのPES（プロバイダーのエッジ）は、アタッチメント回路（AC）から受信したすべてのマルチキャスト/ブロードキャストフレームを特定の仮想スイッチングインスタンス（VSI）に対応するすべてのPWに対応するすべてのPWに複製します。このような手法には、P（プロバイダールーター）とPEデバイスをIPマルチキャスト固有の問題に完全に気付かないという利点があります。ただし、明らかに、帯域幅の消費に関してはかなりの数のスケーラビリティの欠点があり、大規模な展開のコストが増加します。
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 TVなどのマルチキャストベースのサービスをサポートする必要性が高まっています。この商業的傾向により、ほとんどのVPLS展開が以前よりもマルチキャストをより効率的にサポートする必要があります。また、顧客ルーターがIPマルチキャストプロトコルを実行している可能性が高く、これらのルーターが大量のマルチキャストトラフィックを処理するスイッチに接続されているため、必要です。
Therefore, it is desirable to have more efficient techniques to support IP multicast over VPLS.
したがって、VPLよりも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".
このドキュメントの要件をサポートする技術的なソリューションと対応するサービスは、以下「マルチキャストVPL」と呼ばれます。
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つのマルチキャストサービスモデルの1つ。
- 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にトラフィックを指定します。
- 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つのマルチキャストサービスモデルの1つ。
- 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インスタンスは、PWS（Pseudowires）を使用して相互接続されている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は、複数のACS（アタッチメントサーキット）を複数のPWSにマッピングするPEの論理エンティティです。VSIは、標準の橋が転送テーブルに入力されるのとほぼ同じ方法で入力されています。各PEデバイスには複数のVSIがあり、各VSIは異なるVPLSインスタンスに属します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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サービスプロバイダーは、このようなLayer-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:
VPLSでは、CEが（1）ブロードキャスト、（2）マルチキャスト、または（3）不明な宛先ユニキャストを送信すると、侵入PE（階層VPLS（H-VPLS）の場合）で発生します。このアプローチには2つのよく知られている問題があります。
Issue A: Replication to non-member site:
発行A：非会員サイトへのレプリケーション：
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にフレームを単純にフラッディングし、下流のPESはそれらを直接接続されたCESに転送します。ただし、これらのCEはマルチキャストグループのメンバーではない場合があります。顧客の観点からは、不必要な交通のために自分のリソースに圧力をかけることに苦しむ可能性があります。SPSの観点から見ると、彼らはそのようなトラフィックをカバーするために無駄な過剰なプロビジョニングを望んでいません。
Issue B: Replication of PWs on shared physical path:
問題B：共有された物理的パスでのPWSの複製：
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では、各VPLSインスタンスに関連付けられたVSIは、PWSを使用してPSNバックボーンを介してイーサネットを輸送できる論理的なエミュレートブリッジとして動作します。原則として、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があり、すべてのPWが1つのローカルPEから次のホップPに同じリンクを横切って横断しているとします。ローカル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イーサネットスイッチは、出力インターフェイスごとに最大でブロードキャスト/マルチキャストフローを1回複製しますが、VPLは同じ出力インターフェイスで複製された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.
顧客の観点からは、コアで何が起こるかわからないため、深刻な問題はありません。ただし、SPSの観点から見ると、不必要な複製は、PWSの数が増加すると、リソースの疲労のリスクをもたらします。
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:
VPLを介したIPマルチキャストに関しては、サービスの提供に関して2つの異なる側面があります。それらは、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.
今日、幅広いイーサネットサービスが人気を博しており、VPLを利用して幅広いエリアLANサービスを提供できます。顧客がIPマルチキャスト（またはイーサネット層でマルチキャスト/ブロードキャストにつながる他のプロトコル）を使用するさまざまな種類のコンテンツ配信アプリケーションを使用するようになると、トラフィックの合計量も増加します。さらに、レイヤー-2を考慮して、運用、管理、および管理（OAM）、セキュリティ、およびマルチキャストのその他の関連ポイントの考慮が重要です。
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.
SPSは、VPLSがアクセス/メトロネットワークとして、マルチキャストトラフィック（トリプルプレイ（ビデオ、音声、データ）やマルチキャストIP VPNなど）を効率的な方法で提供することを期待する場合があります。
We assume the basic requirements for VPLS written in [RFC4665] are fulfilled unless otherwise specified in this document.
[RFC4665]に記載されているVPLの基本的な要件は、このドキュメントで特に指定されていない限り、満たされると仮定します。
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の両方を解決しようとする必要があります。ただし、一部のアプリケーションは、1つの問題を他の問題よりも解決することを優先するため、解決策はどの問題（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マルチキャストには理想的ではありません。配信とセキュリティに影響を与えます。一方、ソリューションがMACアドレスではなくIPアドレスを追跡する場合、この懸念を防ぐことができます。ただし、このアプローチの欠点は、ネットワーク管理がわずかに複雑になることです。
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（Bridge Protocol Data Unit）は、マルチキャストの宛先MACアドレス（01-80-C2-00-00-00-00）を使用します。また、IEEE 802.1AG [802.1AG]接続障害管理（CFM）メッセージの一部のメッセージは、メッセージの種類とアプリケーションに依存するマルチキャスト宛先MACアドレスを使用します。ただし、IPマルチキャストの観点から見ると、VPLSでは、メンバーシップコントロールを必要とせずに、参加しているすべてのCESにこのような制御フレームをあふれさせる必要があります。
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ソリューションについては、基本的な要件の厳格な適用を支持する場合にのみ、イーサネット関連の情報を使用できます。これは、レイヤー-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:
したがって、輸送効率を改善するために、マルチキャストVPLを使用することができます。実際、今日のLANスイッチの実装は、このようなアプローチをサポートし、上層層プロトコルをスヌープし、IPマルチキャストメンバーシップ（たとえば、プロトコル独立マルチキャスト（PIM）スヌーピングとIGMP/MLD（マルチキャストリスナー発見）スヌーピング[RFC4541]）を調べることが多いことがよくあります。これは、VPLが同様の手法を採用する可能性があることを暗黙的に示唆しますが、このドキュメントではレイヤー-3スヌーピングが必須ではありません。そのようなアプローチが講じられた場合、レイヤー-3状態のメンテナンスを慎重に検討する必要があります。さらに、スヌーピングアプローチは、システムの透明性に不利な点がある場合があることに注意してください。つまり、1つの特定のプロトコルのスヌーピングソリューションは、他の（特に将来の）プロトコルの動作を妨げる可能性があります（たとえば、IGMPV2-SNoopingスイッチと新しいIGMPV3-SNoopingのスイッチ）。また、スヌーピングには潜在的な選択肢があることに注意してください。
- 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]、Cisco Group Management Protocol [CGMP]、および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.
- 溶液では、一般的なVPLSインスタンスでは、レイヤー2制御フレーム（BPDU、802.1AG CFMなど）をすべての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.
- ソリューションでは、レイヤー-3マルチキャスト制御パケット（例：PIM、IGMP（IPv4）、MLD（IPv6の場合）など）をカプセル化するレイヤー2フレームは、洪水範囲を制限することを目的として、関連するメンバーにのみ浸水する場合があります。ただし、他のレイヤー-3制御パケットをカプセル化するレイヤー2フレーム（例：OSPF、IS-IS）は、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 Learningは、宛先MACアドレスとは無関係に、着信フレームのソースMACアドレスに基づいてPESによって実行されます（つまり、ユニキャスト、マルチキャスト、またはブロードキャストに関係なく）。これは、マルチキャスト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インスタンスがソリューションをサポートするPESとそれをサポートしていない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ソリューションには、すでに単純な洪水能力があることに注意してください。したがって、この後方互換性により、ソリューションが展開されるにつれて、マルチキャスト転送の効率が改善されます。
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.
ソリューションは、顧客が採用したイーサネット制御プロトコル（たとえば、Spanning Tree Protocol [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が変更されると、複数のスパニングツリー[802.1S]などの場合にはレイヤー2プロトコルが壊れる場合があります。また、レイヤー-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（V1 [RFC1112]、V2 [RFC2236]、およびV3 [RFC3376]）（IPv4ソリューションの場合）。
o Multicast Listener Discovery Protocol (MLD) (v1 [RFC2710] and v2 [RFC3810]) (for IPv6 solutions).
o マルチキャストリスナーディスカバリープロトコル（MLD）（V1 [RFC2710]およびV2 [RFC3810]）（IPv6ソリューションの場合）。
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 Join/Prune/HelloおよびIGMPクエリ/レポートパケットなど）については、マルチキャストサービスの観点からそのような部分的な非透明度が許容できる場合、必要な最小に変更される場合があります。同様に、PEは、顧客にとって正当な理由で部分的な非透明性が許容できる場合、そのようなレイヤー-3マルチキャスト制御パケットを消費し、まったく新しいパケットを再生することができます（別名プロキシ）。
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.
ソリューションは、これらのドメインのカバレッジサイズを最適化する必要があります。つまり、ソリューションは、メンバーがないCESに不必要なトラフィックが送信されないようにする必要があります。理想的には、提供されたドメインサイズは、顧客のレイヤー-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の翻訳が提供されている場合（つまり、1つのサイトの顧客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.
顧客がVLANを使用しているが、VLAN IDがサービスデリミターではない場合（つまり、VPNは顧客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アドレスに基づいてマルチキャストドメインを構築する場合があります。つまり、各VPLSインスタンスのPESは、転送動作を制御し、各Mac/IP宛先アドレスに応じて異なるマルチキャストフレームの到達可能性を提供する場合があります。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.
これを達成するために、ソリューションには、帯域幅の予約やフロー入場制御などの高いQOをサポートするための追加機能があります。また、マルチキャストVPLS展開は、IEEE 802.1pクラスオブサービス（COS）テクニック[802.1d]およびDiffserv [RFC2475]メカニズムの恩恵を受けるものとします。
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パラメーターは顧客に販売されるサービスの一部であるため、Parameters 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アドレスは、統計、遅延などでフローを分類するためのエントリの1つになります。）ただし、ソリューションが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内のユニキャストのリソースを使い果たすのを防ぐことを目的としています。これは、QoS分離にも有益かもしれません（セクション5.3を参照）。
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は、CEが多様なアクセスネットワークを介して2つの異なるSPSに二重ホーム化される状況を許可する必要があります。1つはマルチキャストVPLをサポートしていますが、もう1つは既存のVPLまたは802.1Q/QINQであるため通信網）。
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を使用している場合、Hello Holdタイマーは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.
ソリューションは、顧客がマルチキャストイーサネットフレームに十分な最低MTU（すなわち、サービスMTU）を提供して、顧客サイト間のIP断片化が発生しないようにする必要があります。マルチキャストとユニキャストに異なる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を参照）を採用し、最適化された配信のために動的に選択する場合（たとえば、1つの骨材から別のツリーに切り替える）、エンドツーエンドのデータ配信は順不同である傾向があります。この事実は、帯域幅の最適化とネットワークの安定性とのトレードオフと見なすことができます。したがって、このような解決策は、この種の欠点についての認識を促進することが期待されています。
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.
したがって、ユニキャストとマルチキャストの両方の接続性を結合する追加の要件があります。これは、いずれかのいずれかが障害を持っている場合、もう1つが無効になっていることを意味します。サービスの1つ（ユニキャストまたはマルチキャストのいずれか）が動作可能になった場合、もう1つも同時にアクティブ化されます。
- 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スイッチングアプリケーションのユニキャストとマルチキャスト接続の間の運命共有を顧客に提供できるかどうかを特定する必要があります。SPSが顧客に代わってそれを提供するための構成可能なメカニズムがある場合があります。
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側ですぐに障害を検出し、バックアップラインに切り替えることで完全な接続を回復したいと考えています。ユニキャストまたはマルチキャストのいずれかが生き続けていても、両方のタイプのトラフィックを必要とする顧客のアプリケーションプロトコルにとって不利です。運命共有政策は、このような複雑な状況を防ぐことに貢献します。
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.
この問題がどれほど深刻であるかは、イーサネット操作における各顧客の姿勢に依存することに注意してください。すべてのCESがIPルーターである場合、つまり、LANルーティングアプリケーションにVPLSが提供されている場合、Unicastとマルチキャスト接続の両方がIPレイヤーで保証されるため、顧客は気にしない場合があります。CEルーターがIGP（OSPF/ IS-ISなど）とマルチキャストルーティングプロトコル（PIMなど）を実行している場合、Unicastパスとマルチキャストパスの両方のAlivenivesがCESによって検出されます。これは、ユニキャストとマルチキャストのトラフィックが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アーキテクチャには、スケーラビリティに大きな利点があります。たとえば、顧客のトラフィックはPSNトンネルにカプセル化されているため、Pルーターは顧客の情報を維持できません。また、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：共有された物理パスでのPWSの複製。
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ソリューションに保持されていないCESのマルチキャストグループ情報を維持する必要がある場合があります。これにより、州のリソース（メモリ、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.).
問題Bを解決するために、PEおよびPルーターは、Point-to-MultiPoint（P2MP）技術を使用している場合、リモートPEの追加メンバーシップ情報、およびおそらく追加のツリートポロジー情報の知識を必要とする必要がある場合があります（PIM Tree、P2MP--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].)
（注：この部分には、レイヤー-3マルチキャスト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
- PESの数
- 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)
- PWSおよび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.)
- PWS（近隣またはセッションのメンテナンスメッセージ、キープライブ、タイマーなど）の管理にコントロールプレーンが必要とする処理リソース
- 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)
- マルチキャストVPLを管理するために送信されるプロトコル情報の量（例：シグナリングスループット）
- 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.
スケーラビリティのもう1つのメトリックは、動作の複雑さです。管理されたオブジェクトの数（たとえば、マルチキャストグループ）が増加するか、トポロジの変更がより頻繁に発生すると、操作は自然に複雑になります。解決策は、追加の運用上の複雑さにつながる要因に注意する必要があります。
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ツリーを含む）、MPLS（P2MP-LSP [RFC4875]、P2MP/MP2MP-LSP [LDP-P2MP]）など、トンネル用のプロトコルには多くの種類のプロトコルがあります。
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.
SPの観点からは、パケットがmdtunnelを横断している間、断片化/再組み立てを頻繁に使用することは受け入れられません。したがって、ソリューションは、サービス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ソリューションは、セクション3.2で定義されているように、ソリューションがサポートされている場合（a）をサポートする場合、マルチキャストメンバーシップ情報をPESによって動的に検出できるようにする方法を提供する必要があります。つまり、PEは、そのPEに接続されたサイトから動的に制御されるマルチキャストメンバーシップ（例：グループアドレスの参加）を発見する必要があることを意味します。さらに、PEは、バックボーン全体の洪水スコープを制限するために、他のリモートPEから自動的にそのような情報を発見する必要があります。
The activation of multicast enhancement in a solution MUST be possible:
ソリューションでのマルチキャスト強化の活性化は可能でなければなりません。
o with a VPLS instance granularity.
o VPLSインスタンスの粒度を使用します。
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).
o アタッチメント回路の粒度（つまり、PE-CE Ethernetポートの粒度がある場合、またはサービスデリミタである場合のVLAN ID粒度を備えています）。
Also it SHOULD be possible:
また、それは可能なはずです：
o with a CE granularity (when multiple CEs of the same VPN are associated with a common VPLS instance).
o CE粒度（同じVPNの複数のCEが一般的なVPLSインスタンスに関連付けられている場合）。
o with a distinction between multicast reception and emission.
o マルチキャスト受信と排出量の区別があります。
o with a multicast MAC address granularity.
o マルチキャストMACアドレスの粒度。
o with a customer IP multicast group and/or channel granularity (when Layer-3 information is consulted).
o 顧客IPマルチキャストグループおよび/またはチャネルの粒度（レイヤー3情報が相談された場合）。
Also it MAY be possible:
また、それは可能かもしれません：
o with a VLAN ID granularity when it is not a service delimiter.
o VLAN IDがサービスデリミタではない場合の粒度を備えています。
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:
ソリューションは、マルチキャストデータ接続をテストし、関連する情報を検証するためのメカニズムを提供する必要があります。マルチキャストに固有のサポートする必要がある例は次のとおりです。
- 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)
- マルチキャストメンバーシップ関連情報の検証
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.
通常、オペレーターは、アクティベーションの前後にエンドツーエンドのマルチキャストユーザーの接続が問題ないかどうかをテストしたいと考えています。このようなエンドツーエンドのマルチキャスト接続チェックは、その顧客のマルチキャストデータパケットが使用するデータパスのエンドツーエンドのテストを可能にするはずです。具体的には、エンドツーエンドのチェックには、CE-CE-CE-PATHテストとPE-To-PEパステストがあります。ソリューションは、PE-To-PEパステストをサポートする必要があり、CE-CE-CE-CE-CE-PATHテストをサポートする場合があります。
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:
ソリューションは、以下へのアクセスをSPSに提供する必要があります。
- 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ソリューションは、以下のSPSが取った管理手順を考慮する必要があります。
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.
ソリューションは、マルチキャストトランスポートのためのグループメンバーシップ/リーチ可能性の障害とトラフィックループを検出するツールを提供する必要があります。このようなツールは、セクション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).
ソリューションは、障害通知とトラブル追跡メカニズム（SNMP-Trapや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.
マルチキャストの場合、障害の1つのポイントは、通知を上げることができる可能性のある多くのダウンストリームルーター/レシーバーにしばしば影響します。したがって、通知メッセージは、オペレーターの管理の容易さのために要約または圧縮される場合があります。
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.
ソリューションは、マルチキャストにも診断/トラブルシューティングツールを提供する必要があります。また、このようなツールは、セクション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.
ベースVPL（L2VPNSの一部として）に関する一般的なセキュリティの考慮事項は、[RFC4665]で言及されています。以下は、マルチキャストVPLに固有の脅威分析リストです。
(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.
CEがあまりにも多くのマルチキャストグループに参加し、サービス拒否（DOS）を引き起こすという脅威があります。これは、短時間で多数のJoin/Pruneメッセージを送信したり、Join/Pruneメッセージに多種多様なグループアドレスを配置することが原因です。この攻撃は、顧客制御メッセージ（セクション3.2の問題Aを解決するため）を調べるPEの制御リソース（CPU、メモリなど）を無駄にし、他の信頼できる顧客に期待されるサービスを継続することはありません。
(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.
CEがPEを破損する可能性のある無効または奇形のコントロールパケットを送信するという脅威があり、DOS攻撃を引き起こす可能性があります。特に、CEは、そのような制御パケット（PIM、IGMPなど）およびソース/宛先MACアドレスの正当なソース/グループIPマルチキャストアドレスをレイヤー2フレームとしてスプーフィングしている可能性があります。
(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.
悪意のあるCEが非常に短い期間でコントロールパケットを送信してマルチキャスト状態を変更する場合、これはPEの制御リソース（CPU、メモリなど）に影響してそのような状態の変更に従う可能性があります。また、コア内のMDTunnelが顧客のマルチキャストグループと組み合わせて動的に作成されている場合、PE/Pの制御リソースにも影響を与える可能性があります。
(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.
悪意のあるCEは、非常に大量のマルチキャストおよび/またはブロードキャストデータをPEに送信する可能性があります。そのPEがセーフガードを提供しない場合、SPネットワークで過度の複製を引き起こし、他の信頼できる顧客の帯域幅リソースが使い果たされる可能性があります。
(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.
悪意のあるCEは、大量の未知のユニキャストをPEに送ることができます。一般に、VPLSアーキテクチャによれば、PEは同じVPNの対応するすべてのPEにこのような不明なトラフィックを殺さなければなりません。さまざまな未知の目的地とそのようなフレームの膨大な量は、適切な保護手段が提供されない限り、SPネットワークで過剰なトラフィックを引き起こす可能性があります。
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.
さらに、マルチキャスト、ブロードキャスト、未知のUnicastはユニキャストよりも多くのリソースを必要とするため、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)
* 有効/無効な顧客データパケット（ブロードキャスト/マルチキャスト/不明-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を参照）、上記の各項目の重要性について強調すべき関係があります。まず、ソリューションが問題Aの解決をサポートし、PESがCEからの顧客のイーサネット/IPマルチキャスト制御メッセージを処理している場合、（3）および（4）に対する保護が大幅に重要になります。さらに、PIM/IGMPスヌーピングには通常、PEのデータ転送がIPアドレスに基づいている必要があるため、（2）に対する保護も非常に焦点を当てる必要があります。対照的に、ソリューションがAではなく問題Bのみを解決している場合、PESは顧客のマルチキャスト制御メッセージをまったく処理しない可能性があります。彼らは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）から保護するために、ソリューションは、状態の資源の枯渇（つまり、記憶、CPUなど）を防ぐために、VPNが使用する状態の量に課される状態の量にいくつかの境界を課すことをサポートする必要があります。この場合、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）から保護するために、ソリューションは顧客によるグループメンバーシップの頻繁な変更を制限できるはずです。たとえば、PESは、顧客が過度に変化しすぎている場合、マルチキャスト状態の変化をスロットする減衰メカニズムをサポートする可能性があります。また、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の間の認証が必要です。ただし、L2VPN（VPLSを含む）は、通常、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マルチキャストソリューションは、階層VPL（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.
解決策は、あるSPが別のSPにL2VPNサービスを提供している状況を可能にする必要があります。ここでの1つの例は、1つのVPLが他のSPSのVPLまたは802.1Dネットワーク島を相互接続する卸売モデルです。顧客SPSの場合、マルチキャスト転送は、卸売業者sp。
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.
さらに、マルチキャストVPLに固有のセキュリティ上の考慮事項があります。したがって、マルチキャストVPLの設計と展開を検討する際に対処する必要がある一連のセキュリティ問題が特定されています。このような問題は、セクション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.
著者は、貴重なレビューとフィードバックをしてくれたYuichi Ikejiri、Jerry Ash、Bill Fenner、Vach Kompella、Shane Amante、Ben Niven-Jenkins、Venu Hemigeにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006.
[RFC4665] Augustyn、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 STD 802.1D-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.1S] IEEE STD 802.1S -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] Farinacci、D.、Tweedly、A。、およびT. Speakman、「Cisco Group Management Protocol（CGMP）」、1996/1997、<ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txtxt>。
[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] MIGIE、I.、ed。、Kompella、K.、Wijnands、I.、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチパスのラベル分布プロトコル拡張」、2008年5月、進行中の作業。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236] Fenner、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、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] Wu、I。およびT. Eckert、「Cisco Systems Router-Port-Port Group Management Protocol（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.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、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] Adams、A.、Nicholas、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] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、2006年5月。
[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] Fenner、B.、Handley、M.、Holbrook、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] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、2006年8月。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L。およびE. Rosen、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、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、「ラベル分布プロトコル（LDP）シグナル伝達を使用した仮想プライベートLANサービス（VPLS）」、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] Morin、T.、ed。、「レイヤー3プロバイダープロビジョニング仮想プライベートネットワーク（PPVPNS）のマルチキャストの要件」、RFC 4834、2007年4月。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、Papadimitriou、D。、およびS. Yasukawa、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルスイッチパス（LSP）のトラフィックエンジニアリング（RSVP-TE）」、RFC 4875、2007年5月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、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
Yuji Kamite（編集者）NTTコミュニケーションコーポレーショングランパークタワー3-4-1シバウラ、港Ku東京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
Yuichirowada ntt 3-9-11 Midori-Cho Musashino-Shi Tokyo 180-8585日本メール：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 Arboretum Blvd.テキサス州オースティン78759 USAメール：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、アベニューピエールマルジン22307ラニオンセデックスフランスメール：thomas.morin@francetelecom.com
Luyuan Fang Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: lufang@cisco.com
Luyuan Fang Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 USAメール：lufang@cisco.com