Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Request for Comments: 6246 F. Brockners
Category: Informational Cisco Systems
ISSN: 2070-1721 D. Mohan, Ed.
Nortel
Y. Serbest
AT&T
June 2011
Virtual Private LAN Service (VPLS) Interoperability
with Customer Edge (CE) Bridges
Abstract
抽象
One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers.
仮想プライベートLANサービス（VPLS）の背後にある主な動機の一つは、顧客のルータおよびサーバ/ホスト間だけでなく、顧客IEEEブリッジ間だけでなく、接続性を提供する能力です。 VPLSは、現在の企業ユーザーが、自分の企業ブリッジネットワークまたはそのイーサネットサービスプロバイダからに慣れている同じレベルのサービスを提供することが期待されます。
When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module and IETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE.
カスタマーエッジ（CE）デバイスは、IEEEブリッジしている場合は、その後、VPLSネットワークに計上される必要があり、特定の問題や課題があります。これらの問題の大半は、プロバイダブリッジのためのIEEE 802.1ad標準で対処されていると、彼らはVPLSネットワークのために活用することができます。この文書では、IEEE 802.1adブリッジモジュールに基づいて、RFC 4664に記載のプロバイダエッジ（PE）モデルを拡張し、それはIEEEブリッジモジュールとIETF LANエミュレーションモジュールとの間に明確な境界を示しています。これにより、CEブリッジとの相互運用性の問題の大半は、このようにVPLS PE内IETF LANエミュレーションモジュールの負担を取り除く、802.1adブリッジモジュールに委任することができることを示しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6246.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6246で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions ................................................4
2. Ethernet Service Instance .......................................4
3. VPLS-Capable PE Model with Bridge Module ........................5
4. Mandatory Issues ................................................8
4.1. Service Mapping ............................................8
4.2. CE Bridge Protocol Handling ...............................10
4.3. Partial Mesh of Pseudowires ...............................11
4.4. Multicast Traffic .........................................12
5. Optional Issues ................................................13
5.1. Customer Network Topology Changes .........................13
5.2. Redundancy ................................................15
5.3. MAC Address Learning ......................................16
6. Interoperability with 802.1ad Networks .........................17
7. Acknowledgments ................................................17
8. Security Considerations ........................................17
9. Normative References ...........................................18
10. Informative References ........................................19
Virtual Private LAN Service (VPLS) is a LAN emulation service intended for providing connectivity between geographically dispersed customer sites across MANs/WANs (over MPLS/IP), as if they were connected using a LAN. One of the main motivations behind VPLS is its ability to provide connectivity not only among customer routers and servers/hosts but also among IEEE customer bridges. If only connectivity among customer IP routers/hosts is desired, then an IP-only LAN Service [IPLS] solution could be used. The strength of the VPLS solution is that it can provide connectivity to both bridge and non-bridge types of CE devices. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks [802.1D] [802.1Q] today or the same level of service that they receive from their Ethernet Service Providers using IEEE 802.1ad-based networks [802.1ad] (or its predecessor, QinQ-based networks).
仮想プライベートLANサービス（VPLS）は、それらがLANを使って接続しているかのように、（MPLS / IP経由）のMAN / WANの間で地理的に分散し、顧客のサイト間の接続性を提供することを目的LANエミュレーションサービスです。 VPLSの背後にある主な動機の一つは、顧客のルータおよびサーバ/ホスト間だけでなく、IEEE顧客ブリッジ間だけでなく、接続性を提供する能力です。顧客IPルータ/ホスト間でのみ接続が所望される場合には、IP専用LANサービス[IPLS]溶液を使用することができます。 VPLS溶液の強度は、CEデバイスの両方のブリッジと非ブリッジ型への接続を提供できることです。 VPLSは、現在の企業ユーザーが、自分の企業ブリッジネットワークからに慣れている同じレベルのサービスを提供するために期待されている[802.1D] [802.1Q]今日か、彼らはIEEE 802.1adを使用して、イーサネット・サービス・プロバイダーから受け取る同じレベルのサービスベースのネットワーク[802.1ad]（またはその前身、QinQのベースのネットワーク）。
When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the PE model described in [RFC4664] based on the IEEE 802.1ad bridge module and illustrates a clear demarcation between IEEE bridge module and IETF LAN emulation module. By doing so, it describes that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. This document discusses these issues and, wherever possible, suggests areas to be explored in rectifying these issues. The detailed solution specification for these issues is outside of the scope of this document.
CEデバイスはIEEEブリッジしている場合は、その後、VPLSネットワークに計上される必要があり、特定の問題や課題があります。これらの問題の大半は、プロバイダブリッジのためのIEEE 802.1ad標準で対処されていると、彼らはVPLSネットワークのために活用することができます。この文書では、IEEE 802.1adブリッジモジュールに基づいて、[RFC4664]に記載のPEモデルを拡張し、IEEEブリッジモジュールとIETF LANエミュレーションモジュールとの間に明確な境界を示しています。これにより、CEブリッジとの相互運用性の問題の大半は、このようにVPLS PE内のIETF LANエミュレーションモジュールの負担を取り除く、802.1adブリッジモジュールに委任できることが記載されています。この文書では、これらの問題を議論して、可能な限り、これらの問題の是正に探求する領域を示唆しています。これらの問題の詳細なソリューションの仕様は、このドキュメントの範囲外です。
This document also discusses interoperability issues between VPLS and IEEE 802.1ad networks when the end-to-end service spans across both types of networks, as outlined in [RFC4762].
[RFC4762]に概説されるように、エンドツーエンドサービスは、ネットワークの両方のタイプにまたがる場合、この文書はまた、VPLSとIEEE 802.1adネットワーク間の相互運用性の問題を論じています。
This document categorizes the CE-bridge issues into two groups: 1) mandatory and 2) optional. The issues in group (1) need to be addressed in order to ensure the proper operation of CE bridges. The issues in group (2) would provide additional operational improvement and efficiency and may not be required for interoperability with CE bridges. Sections 5 and 6 discuss these mandatory and optional issues, respectively.
この文書は、二つのグループにCE-ブリッジの問題を分類：1）必須および2）オプション。グループ内の問題は、（1）CEブリッジの適切な動作を確実にするために対処する必要があります。グループ内の問題（2）は、追加業務改善及び効率を提供するであろうし、CEブリッジとの相互運用性のために必要とされなくてもよいです。セクション5と6は、それぞれ、これらの必須およびオプションの問題を議論します。
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]に記載されているように解釈されます。
Before starting the discussion of bridging issues, it is important to clarify the Ethernet Service definition. The term VPLS has different meanings in different contexts. In general, VPLS is used in the following contexts [RFC6136]: a) as an end-to-end bridged LAN service over one or more networks (one of which is an MPLS/IP network), b) as an MPLS/IP network supporting these bridged LAN services, and c) as (V)LAN emulation. For better clarity, we differentiate between its usage as network versus service by using the terms VPLS network and VPLS instance, respectively. Furthermore, we confine VPLS (both network and service) to only the portion of the end-to-end network that spans an MPLS/IP network. For an end-to-end service (among different sites of a given customer), we use the term "Ethernet Service Instance" or ESI.
問題の橋渡しの議論を開始する前に、イーサネットサービスの定義を明確にすることが重要です。用語VPLSは異なる文脈で異なる意味を持っています。一般に、VPLSは、次のコンテキスト[RFC6136]で使用した：a）エンドツーエンドのような1つまたは複数のネットワーク（そのうちの一つは、MPLS / IPネットワークである）を介しLANサービスを架橋し、B）MPLS / IPのような（V）LANエミュレーションとしてこれらのブリッジLANサービス、およびc）をサポートするネットワーク。より明確にするために、私たちはそれぞれ、用語のVPLSネットワークおよびVPLSインスタンスを使用して、ネットワークに対するサービスとして、その使用を区別します。さらに、我々は、MPLS / IPネットワークにまたがるエンドツーエンドのネットワークの一部のみにVPLS（ネットワーク及びサービスの両方）を閉じ込めます。 （与えられた顧客の異なるサイト間）エンドツーエンドのサービスのために、我々は、用語「イーサネットサービスインスタンス」またはESIを使用します。
We define the Ethernet Service Instance (ESI) as an association of two or more Attachment Circuits (ACs) over which an Ethernet service is offered to a given customer. An AC can be either a User-Network Interface (UNI) or a Network-Network Interface (NNI); furthermore, it can be an Ethernet interface or a VLAN, it can be an ATM or Frame Relay Virtual Circuit, or it can be a PPP/HDLC (PPP/High-Level Data
私たちは、イーサネットサービスは、特定の顧客に提供され、その上二つ以上の接続回線（ACS）の団体としてのイーサネットサービスインスタンス（ESI）を定義します。 ACは、ユーザネットワークインタフェース（UNI）またはネットワークネットワークインタフェース（NNI）のいずれかとすることができます。さらに、それがリレー仮想回線ATMであるか、またはフレームができ、イーサネットインタフェースまたはVLANにすることも、PPP / HDLC（PPP /ハイレベル・データすることができ
Link Control) interface. If an ESI is associated with more than two ACs, then it is a multipoint ESI. In this document, wherever the keyword ESI is used, it means multipoint ESI unless stated otherwise.
リンク制御）インターフェース。 ESIは、二つ以上のACに関連付けられている場合、それはマルチESIです。キーワードESIが使用されているところはどこでも、この文書では、それは特に明記しない限り、ESIをマルチ意味します。
An ESI can correspond to a VPLS instance if its associated ACs are only connected to a VPLS network, or an ESI can correspond to a Service VLAN if its associated ACs are only connected to a Provider-Bridged network [802.1ad]. Furthermore, an ESI can be associated with both a VPLS instance and a Service VLAN when considering an end-to-end service that spans across both VPLS and Provider-Bridged networks. An ESI can span across different networks (e.g., IEEE 802.1ad and VPLS) belonging to the same or different administrative domains.
その関連ACSがVPLSネットワークにのみ接続されている場合ESIは、VPLSインスタンスに対応することができ、又はその関連のACのみプロバイダ・ブリッジ・ネットワーク[802.1ad]に接続されている場合ESI、サービスVLANに対応することができます。 VPLSおよびプロバイダ架橋ネットワークの両方にまたがるエンドツーエンドのサービスを考慮した場合、さらに、ESIは、VPLSインスタンスとサービスVLANの両方に関連することができます。 ESI（例えば、IEEE 802.1adおよびVPLS）同じまたは異なる管理ドメインに属する異なるネットワークにまたがることができます。
An ESI most often represents a customer or a specific service requested by a customer. Since traffic isolation among different customers (or their associated services) is of paramount importance in service provider networks, its realization shall be done such that it provides a separate Media Access Control (MAC) address domain and broadcast domain per ESI. A separate MAC address domain is provided by using a separate MAC forwarding table (e.g., Forwarding Information Base (FIB), also known as filtering database [802.1D]) per ESI (for both VPLS and IEEE 802.1ad networks). A separate broadcast domain is provided by using a full mesh of pseudowires per ESI over the IP/MPLS core in a VPLS network and/or a dedicated Service VLAN per ESI in an IEEE 802.1ad network.
ESIは、ほとんどの場合、顧客または顧客から要求された特定のサービスを表します。異なる顧客（またはそれに関連するサービス）の間でトラフィックの分離は、サービスプロバイダーのネットワークで最も重要であるので、その実現には、それはESIごとに別々のメディアアクセス制御（MAC）アドレスのドメインとブロードキャストドメインを提供するように行われなければなりません。 （VPLSおよびIEEE 802.1adネットワークの両方のための）ESIごとに個別のMACアドレスドメインが別個のMAC転送テーブルを使用して提供される（また、フィルタリングデータベースとして知られている、例えば、転送情報ベース（FIB）[802.1D]）。別々のブロードキャストドメインは、VPLSネットワークおよび/またはIEEE 802.1adネットワーク内ESI当たり専用サービスVLANにIP / MPLSコア上ESI当たり疑似回線のフルメッシュを使用して提供されます。
[RFC4664] defines three models for VPLS-capable PE (VPLS-PE), based on the bridging functionality that needs to be supported by the PE. If the CE devices can be routers/hosts or IEEE bridges, the second model from [RFC4664] is the most suitable, and it is both adequate to provide the VPLS level of service and consistent with the IEEE standards for Provider Bridges [802.1ad]. We briefly describe the second model and then expand upon this model to show its sub-components based on the [802.1ad] Provider Bridge model.
[RFC4664]はPEによってサポートされる必要があるブリッジ機能に基づいて、VPLS対応PE（VPLS-PE）のための3つのモデルを定義します。 CEデバイスがルータ/ホストまたはIEEEブリッジとすることができる場合は、[RFC4664]から第2のモデルが最も適しており、サービスのVPLSレベルを提供するのに適切でプロバイダブリッジのIEEE規格と一致しての両方である[802.1ad] 。私たちは、簡単に第2のモデルを記述し、[802.1ad]プロバイダー・ブリッジモデルに基づいて、そのサブコンポーネントを表示するには、このモデルに拡張します。
As described in [RFC4664], the second model for VPLS-PE contains a single bridge module supporting all the VPLS instances on that PE , where each VPLS instance is represented by a unique VLAN inside that bridge module (also known as a Service VLAN or S-VLAN). The bridge module has a single "Emulated LAN" interface over which it communicates with all VPLS forwarders, and each VPLS instance is represented by a unique S-VLAN tag. Each VPLS instance can consist of a set of pseudowires, and its associated forwarder can correspond to a single VLAN as depicted in Figure 1 below. Thus, sometimes it is referred to as VLAN emulation.
[RFC4664]に記載されているように、VPLS-PEのための第2のモデルに含まれる各インスタンスをVPLSそのPE、上のすべてのVPLSインスタンスをサポートする単一のブリッジ・モジュールは、サービスVLANとしても知られているブリッジモジュール（内部ユニークVLANによって表されるか、またはS-VLAN）。ブリッジ・モジュールは、すべてのVPLSフォワーダと通信するにわたって単一の「エミュレートLAN」インターフェースを有し、各インスタンスは一意のS-VLANタグによって表されるVPLS。各インスタンスは、疑似回線のセットからなることができるVPLS、および以下の図1に示されるように、その関連するフォワーダは、単一のVLANに対応することができます。したがって、時にはそれは、VLANエミュレーションと呼ばれます。
+----------------------------------------+
| VPLS-Capable PE Model |
| +---------------+ +------+ |
| | | |VPLS-1|------------
| | |=======+ |Fwdr |------------ PWs
| | Bridge --------|--- |------------
| | | SVID-1| +------+ |
| | Module | | o |
| | | | o |
| | (802.1ad | | o |
| | bridge) | | o |
| | | | o |
| | | SVID-n| +------+ |
| | --------|---VPLS-n|-------------
| | |=======+ | Fwdr |------------- PWs
| | | ^ | |-------------
| +---------------+ | +------+ |
| | |
+-----------------------|----------------+
|
LAN emulation (multi-access) interface
Figure 1. VPLS-Capable PE Model
図1 VPLS対応モデル
Customer frames associated with a given ESI carry the S-VLAN ID for that ESI over the LAN emulation interface. The S-VLAN ID is stripped before transmitting the frames over the set of pseudowires (PWs) associated with that VPLS instance (assuming raw mode PWs are used as specified in [RFC4448]).
所与ESI関連付けられた顧客フレームはLANエミュレーション・インターフェースを介してそのESIためのS-VLAN IDを運びます。 S-VLAN IDは、それは（[RFC4448]で指定されるように、生のモードのPWが使用されると仮定して）VPLSインスタンスに関連付けられた疑似回線（PWの）のセット上にフレームを送信する前に剥離されます。
The bridge module can itself consist of one or two sub-components, depending on the functionality that it needs to perform. Figure 2 depicts the model for the bridge module based on [802.1ad].
ブリッジモジュール自体が、それが実行するために必要な機能に応じて1つまたは2つのサブコンポーネントから構成することができます。図2は、[802.1ad]に基づいて、ブリッジモジュールのモデルを示しています。
+-------------------------------+
| 802.1ad Bridge Module Model |
| |
+---+ AC | +------+ +-----------+ |
|CE |---------|C-VLAN|------| | |
+---+ | |bridge|------| | |
| +------+ | | |
| o | S-VLAN | |
| o | | | ---> to VPLS Fwdr
| o | Bridge | |
+---+ AC | +------+ | | |
|CE |---------|C-VLAN|------| | |
+---+ | |bridge|------| | |
| +------+ | | |
+---+ AC | | | |
|CE |-----------------------| | |
+---+ | +-----------+ |
+-------------------------------+
Figure 2. Model of the 802.1ad Bridge Module
802.1adブリッジモジュールの図2.モデル
The S-VLAN bridge component is always required and it is responsible for tagging customer frames with S-VLAN tags in the ingress direction (from customer UNIs) and removing S-VLAN tags in the egress direction (toward customer UNIs). It is also responsible for running the provider's bridge protocol -- such as Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), Generic VLAN Registration Protocol (GVRP), GARP Multicast Registration Protocol (GMRP), etc. -- among provider bridges within a single administrative domain.
S-VLANブリッジコンポーネントが常に必要であり、それは（顧客のUNIから）入力方向にS-VLANタグを顧客フレームをタグ付けし、（顧客のUNIに向かって）出方向にS-VLANタグを除去する責任があります。など高速スパニングツリープロトコル（RSTP）、複数のスパニングツリープロトコル（MSTP）、一般的なVLAN登録プロトコル（GVRP）、GARPマルチキャスト登録プロトコル（GMRP）、など - それはまた、プロバイダのブリッジプロトコルを実行するための責任があります - 単一の管理ドメイン内のプロバイダブリッジ間。
The customer VLAN (C-VLAN) bridge component is required when the customer Attachment Circuits are VLANs (aka C-VLANs). In such cases, the VPLS-capable PE needs to participate in some of the customer's bridging protocol such as RSTP and MSTP. Such participation is required because a C-VLAN at one site can be mapped into a different C-VLAN at a different site or, in case of asymmetric mapping, a customer Ethernet port at one site can be mapped into a C-VLAN (or group of C-VLANs) at a different site.
顧客の接続回線がVLANの（別名C-VLAN）である場合、顧客のVLAN（C-VLAN）ブリッジコンポーネントが必要です。このような場合には、VPLS対応PEは、RSTPおよびMSTPのような顧客のブリッジングプロトコルの一部に参加する必要があります。一つのサイトでのC-VLANは、異なる部位で異なるC-VLANにマッピングすることができ、または、非対称のマッピングの場合には、一つのサイトで顧客のイーサネットポートがC-VLANにマッピングすることができるので、このような参加は、（必要とされる、または別のサイトでのC-のVLAN）のグループ。
The C-VLAN bridge component does service selection and identification based on C-VLAN tags. Each frame from the customer device is assigned to a C-VLAN and presented at one or more internal port-based interfaces, each supporting a single service instance that the customer desires to carry that C-VLAN. Similarly, frames from the provider network are assigned to an internal interface or 'LAN' (e.g, between C-VLAN and S-VLAN components) on the basis of the S-VLAN tag. Since each internal interface supports a single service instance, the
C-VLANブリッジコンポーネントは、C-VLANタグに基づいて、サービスの選択および同定を行います。顧客装置からの各フレームは、各顧客がそのC-VLANを運ぶしたい単一のサービス・インスタンスをサポートする、1つまたは複数の内部ポートベースのインターフェイスでC-VLANに割り当てられて提示されます。同様に、プロバイダ・ネットワークからのフレームは、S-VLANタグに基づいて、内部インターフェースまたは「LAN」（例えば、C-VLANとS-VLANコンポーネント間）に割り当てられています。各内部インターフェイスは、単一のサービス・インスタンスをサポートするため
S-VLAN tag can be, and is, removed at this interface by the S-VLAN bridge component. If multiple C-VLANs are supported by this service instance (e.g., via VLAN bundling or port-based service), then the frames will have already been tagged with C-VLAN tags. If a single C-VLAN is supported by this service instance (e.g., VLAN-based), then the frames will not have been tagged with a C-VLAN tag since C-VLAN can be derived from the S-VLAN (e.g., one-to-one mapping). The C-VLAN-aware bridge component applies a port VLAN ID (PVID) to untagged frames received on each internal 'LAN', allowing full control over the delivery of frames for each C-VLAN through the Customer UNI Port.
S-VLANタグをすることができ、そして、S-VLANブリッジコンポーネントによってこのインターフェイスで除去されます。複数のC-VLANがこのサービスインスタンスによってサポートされている場合（例えば、VLANは結束またはポートベースのサービスを介して）、次いで、フレームは既にC-VLANタグでタグ付けされているであろう。単一のC-VLAN（例えば、VLANベースの）このサービスインスタンスによってサポートされている場合C-VLANは、S-VLAN（例えば、1つに由来することができるので、その後のフレームは、C-VLANタグでタグ付けされていません-to-1マッピング）。 C-VLAN対応ブリッジコンポーネントは、タグなしフレームにポートVLAN ID（PVID）を印加カスタマーUNIポートを介して各C-VLANのフレームの配信を完全に制御できるように、各内部「LAN」上で受信されました。
Different Ethernet AC types can be associated with a single Ethernet Service Instance (ESI). For example, an ESI can be associated with only physical Ethernet ports, VLANs, or a combination of the two (e.g., one end of the service could be associated with physical Ethernet ports and the other end could be associated with VLANs). In [RFC4762], unqualified and qualified learning are used to refer to port-based and VLAN-based operation, respectively. [RFC4762] does not describe the possible mappings between different types of Ethernet ACs (e.g., 802.1D, 802.1Q, or 802.1ad frames). In general, the mapping of a customer port or VLAN to a given service instance is a local function performed by the local PE, and the service provisioning shall accommodate it. In other words, there is no reason to restrict and limit an ESI to have only port-based ACs or to have only VLAN-based ACs. [802.1ad] allows for each customer AC (either a physical port, a VLAN, or a group of VLANs) to be mapped independently to an ESI that provides better service offerings to enterprise customers. For better and more flexible service offerings and for interoperability purposes between VPLS and 802.1ad networks, it is imperative that both networks offer the same capabilities in terms of customer ACs mapping to the customer service instance.
異なるイーサネットACタイプは、単一のイーサネットサービスインスタンス（ESI）に関連付けることができます。例えば、ESIは、物理イーサネットポート、VLAN、または（例えば、サービスの一端は、物理イーサネットポートに関連付けることができ、他端はVLANを関連付けることができた）は、2つの組み合わせに関連付けることができます。 [RFC4762]で、非修飾及び修飾の学習は、それぞれ、ポートベースとVLANベースの動作を参照するために使用されます。 [RFC4762]は、イーサネットのAC（例えば、802.1D、802.1Q、または802.1adフレーム）の異なるタイプ間の可能なマッピングを記載していません。一般に、与えられたサービスインスタンスに対する顧客のポートまたはVLANのマッピングは、ローカルPEによって実行ローカル機能であり、サービスのプロビジョニングは、それに対応しなければなりません。換言すれば、唯一のポートベースのACSを有するか、または唯一のVLANベースのACSを有するようにESIを制限し、制限する理由はありません。 【802.1adは、各顧客AC（いずれかの物理ポート、VLAN、またはVLANのグループ）企業顧客により良いサービス・オファリングを提供ESIに独立してマッピングすることを可能にします。より良く、より柔軟なサービスの提供のためにとVPLSと802.1adネットワーク間の相互運用性の目的のために、両方のネットワークは、顧客サービスインスタンスへの顧客のACSマッピングの面で同じ機能を提供することが不可欠です。
The following table lists possible mappings that can exist between customer ACs and their associated ESIs. As can be seen, there are several possible ways to perform such mappings. In the first scenario, it is assumed that an Ethernet physical port only carries untagged traffic and all traffic is mapped to the corresponding service instance or ESI. This is referred to as "port-based with untagged traffic". In the second scenario, it is assumed that an Ethernet physical port carries both tagged and untagged traffic and all that traffic is mapped to the corresponding service instance or ESI. This is referred to as "port-based with tagged and untagged traffic". In the third scenario, it is assumed that only a single
次の表は、顧客のACとその関連のESIの間に存在することができる可能なマッピングを示しています。図から分かるように、このようなマッピングを実行するには、いくつかの方法があります。最初のシナリオでは、イーサネット物理ポートのみタグなしトラフィックを伝送し、すべてのトラフィックが対応するサービスインスタンス又はESIにマッピングされているものとします。これは、「ポートベースのタグなしトラフィックを持つ」と呼ばれています。第2のシナリオでは、イーサネット物理ポートがタグ付きおよびタグなしの両方のトラフィックを伝送し、すべてのそのトラフィックが対応するサービスインスタンス又はESIにマッピングされているものとします。これは、「ポートベースのタグ付きおよびタグなしトラフィックを」と呼ばれています。第3のシナリオでは、単一のものとします
VLAN is mapped to the corresponding service instance or ESI. This is referred to as "VLAN-based". Finally, in the fourth scenario, it is assumed that a group of VLANs from the Ethernet physical interface is mapped to the corresponding service instance or ESI. This is referred to as "VLAN bundling".
VLANは、対応するサービスインスタンス又はESIにマッピングされます。これは、「VLANベース」と呼ばれています。最後に、第4のシナリオでは、イーサネットの物理インターフェイスからVLANのグループは、対応するサービスインスタンス又はESIにマッピングされているものとします。これは、「VLANバンドリング」と呼ばれています。
===================================================================
Ethernet I/F & Associated Service Instance(s)
-------------------------------------------------------------------
Port-based Port-based VLAN-based VLAN
untagged tagged & bundling
untagged
-------------------------------------------------------------------
Port-based Y N Y(Note-1) N
untagged
Port-based N Y Y(Note-2) Y tagged & untagged
ポートベースN Y Y（注2）Yタグ付けされた＆タグなし
VLAN-based Y(Note-1) Y(Note-2) Y Y(Note-3)
VLANベースと（注1）Y（注2）Y Y（注-3）
VLAN N Y Y(Note-3) Y
Bundling
===================================================================
Note-1: In this asymmetric mapping scenario, it is assumed that the CE device with "VLAN-based" AC is capable of supporting [802.1Q] frame format.
注1：この非対称マッピングシナリオでは、「VLANベースの」ACは[802.1Q]フレームフォーマットをサポートすることができるとCEデバイスと仮定する。
Note-2: In this asymmetric mapping scenario, it is assumed that the CE device with "VLAN-based" AC can support [802.1ad] frame format because it will receive Ethernet frames with two tags, where the outer tag is an S-VLAN and the inner tag is a C-VLAN received from "port-based" AC. One application example for such CE device is in a Broadband Remote Access Server (BRAS) for DSL aggregation over a Metro Ethernet network.
注2：この非対称マッピングシナリオでは、外側のタグがS-である場合、それは、二つのタグとイーサネットフレームを受信することになるので、「VLANベースの」ACは[802.1ad]フレームフォーマットをサポートすることができるとともに、そのCE機器想定されますVLANおよび内側タグがC-VLAN「がポートベースの」ACから受信されます。そのようなCE機器のための一つの応用例は、メトロ・イーサネット・ネットワーク上のDSL集約のためのブロードバンドリモートアクセスサーバ（BRAS）です。
Note-3: In this asymmetric mapping scenario, it is assumed that the CE device with "VLAN-based" AC can support the [802.1ad] frame format because it will receive Ethernet frames with two tags, where the outer tag is an S-VLAN and the inner tag is a C-VLAN received from "VLAN bundling" AC.
注3：この非対称マッピングシナリオでは、「VLANベースの」外側のタグがSである場合、それは、二つのタグとイーサネットフレームを受信するため、ACは、[802.1ad]フレームフォーマットをサポートすることができるとともに、そのCE機器想定されます - VLANおよび内側タグがC-VLANは、ACを「バンドルVLAN」から受信されます。
If a PE uses an S-VLAN tag for a given ESI (either by adding an S-VLAN tag to customer traffic or by replacing a C-VLAN tag with a S-VLAN tag), then the frame format and EtherType for S-VLAN SHALL adhere to [802.1ad].
PEは、S-ためESI（顧客トラフィックにS-VLANタグを追加するか、S-VLANタグとC-VLANタグを置換することによってのいずれかで）与えられ、その後、フレームフォーマットとEtherTypeのためのS-VLANタグを使用する場合VLANは、[802.1ad]に準拠するものとします。
As mentioned before, the mapping function between the customer AC and its associated ESI is a local function; thus, when the AC is a single customer VLAN, it is possible to map different customer VLANs at different sites to a single ESI without coordination among those sites.
前に述べたように、顧客AC及びその関連ESI間のマッピング機能は、ローカル関数です。 ACは、単一の顧客VLANのときので、これらのサイト間の調整なしに、単一のESIに異なる部位に異なる顧客のVLANをマッピングすることが可能です。
When a port-based mapping or a VLAN-bundling mapping is used, then the PE may use an additional S-VLAN tag to mark the customer traffic received over that AC as belonging to a given ESI. If the PE uses the additional S-VLAN tag, then in the opposite direction the PE SHALL strip the S-VLAN tag before sending the customer frames over the same AC. However, when VLAN-mapping mode is used at an AC and if the PE uses the S-VLAN tag locally, then if the Ethernet interface is a UNI, the tagged frames over this interface SHALL have a frame format based on [802.1Q]. In such a case, the PE SHALL translate the customer tag (C-VLAN) into the provider tag (S-VLAN) upon receiving a frame from the customer. In the opposite direction, the PE SHALL translate from provider frame format (802.1ad) back to customer frame format (802.1Q).
ポートベースのマッピングまたはVLAN-結束マッピングが使用される場合、次いで、PEは、顧客トラフィックをマークするために、追加のS-VLANタグを使用することができる所与ESIに属すると交流することを介して受信。 PEは、追加のS-VLANタグを使用する場合、反対方向にPEは、同じACにわたって顧客フレームを送信する前に、S-VLANタグを除去SHALL。しかし、VLANマッピングモードはACで使用される場合とPEがローカルS-VLANタグを使用する場合、イーサネットインターフェイスがUNIである場合、次いで、このインタフェースを介してタグ付けされたフレームは、[802.1Q]に基づいて、フレームフォーマットを有するもの。このような場合には、PEは、顧客からのフレームを受信すると、プロバイダタグ（S-VLAN）に顧客タグ（C-VLAN）を変換SHALL。反対方向では、PEは、バック顧客フレームフォーマット（802.1Q）にプロバイダフレームフォーマット（802.1ad）から翻訳SHALL。
All the above asymmetric services can be supported via the PE model with the bridge module depicted in Figure 2 (based on [802.1ad]).
上記のすべての非対称サービス（[802.1ad]に基づく）は、図2に示されるブリッジモジュールとPEモデルを介して支持することができます。
When a VPLS-capable PE is connected to a CE bridge, then -- depending on the type of Attachment Circuit -- different protocol handling may be required by the bridge module of the PE. [802.1ad] states that when a PE is connected to a CE bridge, then the service offered by the PE may appear to specific customer protocols running on the CE in one of the four ways:
VPLS対応PEがCEブリッジに接続されている場合、その後、 - 接続回線の種類に応じて、 - 異なるプロトコル処理は、PEのブリッジモジュールによって必要とされ得ます。 [802.1ad]はPEがCEブリッジに接続されている場合、次いでPEによって提供されるサービスは、4つのいずれかの方法で、CE上で実行されている特定の顧客プロトコルに表示されることと述べています。
a) Transparent to the operation of the protocol among CEs of different sites using the service provided, appearing as an individual LAN without bridges;
a）は、提供されるサービスを使用して、異なるサイトのCEの間のプロトコルの動作に透明、ブリッジすることなく個々のLANとして現れます。
b) Discarding frames, acting as a non-participating barrier to the operation of the protocol;
B）プロトコルの動作に非参加障壁として作用する、フレームを破棄。
c) Peering, with a local protocol entity at the point of provider ingress and egress, participating in and terminating the operation of the protocol; or
C）に参加し、プロトコルの動作を終了、プロバイダ入口および出口の点で局所プロトコルエンティティと、ピアリング。または
d) Participation in individual instances of customer protocols.
顧客プロトコルの個々のインスタンスにおけるd）に参加。
All the above CE bridge protocol handling can be supported via the PE model with the bridge module depicted in Figure 2 (based on [802.1ad]). For example, when an Attachment Circuit is port-based, then the bridge module of the PE can operate transparently with respect to the CE's RSTPs or MSTPs (and thus no C-VLAN component is required for that customer UNI). However, when an Attachment Circuit is VLAN-based (either VLAN-based or VLAN bundling), then the bridge module of the PE needs to peer with the RSTPs or MSTPs running on the CE (and thus the C-VLAN bridge component is required). In other words, when the AC is VLAN-based, then protocol peering between CE and PE devices may be needed. There are also protocols that require peering but are independent from the type of Attachment Circuit. An example of such protocol is the link aggregation protocol [802.1AX]; however, this is a media-dependent protocol as its name implies.
上記のすべてのCEブリッジプロトコル処理は（[802.1ad]に基づく）は、図2に示されるブリッジモジュールとPEモデルを介して支持することができます。例えば、接続回線がポートベースである場合、次いで、PEのブリッジモジュールは、CEのRSTPs又はMSTPsに対して透過的に動作することができる（したがって、何らC-VLANコンポーネントはその顧客UNIのために必要とされません）。アタッチメント回路（VLANベースまたはVLANバンドルのいずれか）VLANベースである場合しかし、その後PEのブリッジモジュールは、CE上で実行されているRSTPs又はMSTPsでピアする必要がある（したがって、C-VLANブリッジ構成要素が必要とされます）。 ACは、VLANベースである場合つまり、CEおよびPEデバイス間のピアリング、プロトコルが必要とされてもよいです。ピアリングを必要とするが、接続回線の種類から独立しているプロトコルもあります。そのようなプロトコルの例は、リンクアグリゲーションプロトコル[802.1AX]です。その名前が示すようしかし、これはメディア依存のプロトコルです。
[802.1ad] reserves a block of 16 MAC addresses for the operation of C-VLAN and S-VLAN bridge components. Also, it shows which of these reserved MAC addresses are only for C-VLAN bridge components, which are only for S-VLAN bridge components, and which apply to both C-VLAN and S-VLAN components.
[802.1ad]はC-VLANとS-VLANブリッジ構成要素の動作のための16個のMACアドレスのブロックを予約します。また、それだけでのみS-VLANブリッジコンポーネントのためのものであり、C-VLANとS-VLAN構成要素の両方に適用C-VLANブリッジコンポーネントのためのものであるこれらの予約済みMACアドレスのどの示します。
A VPLS service depends on a full mesh of pseudowires, so a pseudowire failure reduces the underlying connectivity to a partial mesh, which can have adverse effects on the VPLS service. If the CE devices belonging to an ESI are routers running link state routing protocols that use LAN procedures over that ESI, then a partial mesh of PWs can result in "black holing" traffic among the selected set of routers. And if the CE devices belonging to an ESI are IEEE bridges, then a partial mesh of PWs can cause broadcast storms in the customer and provider networks. Furthermore, it can cause multiple copies of a single frame to be received by the CE and/or PE devices. Therefore, it is of paramount importance to be able to detect PW failure and to take corrective action to prevent creation of partial mesh of PWs.
VPLSサービスは、疑似回線のフルメッシュに依存するため、スードワイヤ障害がVPLSサービスに悪影響を与えることができ、部分メッシュ、基になる接続性を低減します。 ESIに属するCEデバイスがその上ESI LAN手順を使用してリンク状態ルーティングプロトコルを実行するルータである場合、その後のPWの部分的なメッシュルータの選択されたセットのうちの「ブラックホール」のトラフィックをもたらすことができます。 ESIに属するCEデバイスは、IEEEブリッジしている場合や、その後のPW部分のメッシュは、顧客とプロバイダーのネットワークでブロードキャストストームを引き起こす可能性があります。また、CEおよび/またはPEデバイスによって受信される単一のフレームの複数のコピーを引き起こすことができます。したがって、PWの障害を検出できるようにするおよびPWの部分メッシュの生成を防止するための是正措置をとるために極めて重要です。
When the PE model depicted in Figure 2 is used, then [802.1ag] procedures could be used for detection of partial mesh of PWs. [802.1ag] defines a set of procedures for fault detection, verification, isolation, and notification per ESI.
図2に示すPEモデルを使用した場合、次に[802.1ag]手順は、のPWの部分的なメッシュの検出のために使用することができます。 【802.1agは】ESIあたり障害検出、検証、分離、および通知のための手順のセットを定義します。
The fault detection mechanism of [802.1ag] can be used to perform connectivity check among PEs belonging to a given VPLS instance. It checks the integrity of a service instance end-to-end within an administrative domain, e.g., from one AC at one end of the network to another AC at the other end of the network. Therefore, its path coverage includes the bridge module within a PE and it is not limited to just PWs. Furthermore, [802.1ag] operates transparently over the full mesh of PWs for a given service instance since it operates at the Ethernet level (and not at the PW level). It should be noted that since a PW consists of two unidirectional Label Switched Paths (LSPs), then one direction can fail independently of the other. Even in this case, the procedures of [802.1ag] can provide a consistent view of the full mesh to the participating PEs by relying on remote defect indication (RDI).
【802.1ag]の障害検出メカニズムは、所与のVPLSインスタンスに属するのPE間接続性チェックを実行するために使用することができます。これは、サービスインスタンスエンドツーエンド管理ドメイン内に、例えば、1つのACからのネットワークの他端において別のACへのネットワークの一端での整合性をチェックします。したがって、そのパスカバレッジは、PE内のブリッジ・モジュールを含み、それは単にのPWに限定されるものではありません。それは（PWレベルではなく）イーサネット・レベルで動作するので、[802.1agは、所与のサービスインスタンスのためのPWのフルメッシュ上に透過的に動作します。次いで、一方向は互いに独立して失敗することがPWは、2つの単方向のラベルで構成されているのでパス（LSPを）交換することを留意すべきです。この場合でも、[802.1ag]の手順は、リモート障害表示（RDI）に依存することによって、参加PEにフルメッシュの一貫したビューを提供することができます。
Another, less preferred, option is to define a procedure for detection of partial mesh; in this procedure, each PE keeps track of the status of its PW Endpoint Entities (EEs, e.g., VPLS forwarders) as well as the EEs reported by other PEs. Therefore, upon a PW failure, the PE that detects the failure not only takes notice locally but also notifies other PEs belonging to that service instance so that all the participant PEs have a consistent view of the PW mesh. Such a procedure is for the detection of partial mesh per service instance, and in turn it relies on additional procedure for PW failure detection such as Bidirectional Forward Detection (BFD) or Virtual Circuit Connectivity Verification (VCCV). Given that there can be tens (or even hundreds) of thousands of PWs in a PE, there can be scalability issues with such fault detection/notification procedures.
別の、あまり好ましくない、オプションは、部分メッシュの検出のための手順を定義することです。この手順では、各PEはPWエンドポイントエンティティ（EEの、例えば、VPLSフォワーダ）、ならびに他のPEによって報告のEEのステータスを追跡します。したがって、PWの障害時に、障害を検出するPEは、ローカル通知を要するだけでなく、すべての参加者のPEがPWメッシュの一貫したビューを有するようにそのサービスインスタンスに属する他のPEに通知するだけでなく。このような手順は、サービスインスタンスごとの部分メッシュを検出するためのものである、と順番に、それは、このような双方向フォワード検出（BFD）または仮想回線接続性検証（VCCV）としてPW障害検出のための追加の手順に依存しています。 PEでのPW数万（あるいは数百）が存在し得ることを考えると、そのような障害検出/通知手順とスケーラビリティの問題が存在し得ます。
VPLS follows a centralized model for multicast replication within an ESI. VPLS relies on ingress replication. The ingress PE replicates the multicast packet for each egress PE and sends it to the egress PE using point-to-point PW over a unicast tunnel. VPLS operates on an overlay topology formed by the full mesh of pseudo-wires. Thus, depending on the underlying topology, the same datagram can be sent multiple times down the same physical link. VPLS currently does not offer any mechanisms to restrict the distribution of multicast or broadcast traffic of an ESI throughout the network, which causes an additional burden on the ingress PE through unnecessary packet replication. This in turn causes additional load on the MPLS core network and additional processing at the receiving PE where extraneous multicast packets are discarded.
VPLSは、ESI内のマルチキャスト複製のための集中型モデルに従います。 VPLSは、入力レプリケーションに依存しています。入口PEは、各出口PEのマルチキャストパケットを複製し、ユニキャストトンネル上のポイントツーポイントPWを使用して出口PEに送ります。 VPLSは、擬似ワイヤのフルメッシュにより形成されたオーバーレイ・トポロジーで動作します。このように、基本的なトポロジに応じて、同じデータグラムは、同じ物理リンクダウンを複数回送信することができます。 VPLSは、現在、不要なパケット複製を通じて入力PE上の追加負担が発生するネットワーク、全体ESIのマルチキャストまたはブロードキャストトラフィックの分布を制限するために、任意のメカニズムを提供していません。これは、順番に無関係なマルチキャストパケットが破棄される受信PEでMPLSコアネットワークと追加の処理に余分な負荷を引き起こします。
One possible approach to delivering multicast more efficiently over a VPLS network is to include the use of IGMP snooping in order to send the packet only to the PEs that have receivers for that traffic, rather than to all the PEs in the VPLS instance. If the customer bridge or its network has dual-home connectivity, then -- for proper operation of IGMP snooping -- the PE must generate a "General Query" over that customer's UNIs upon receiving a customer topology change notification as described in [RFC4541]. A "General Query" by the PE results the customer multicast MAC address(es) being properly registered at the PE when there are customer topology changes. It should be noted that IGMP snooping provides a solution for IP multicast packets and is not applicable to general multicast data.
VPLSネットワーク上でより効率的にマルチキャストを実現するための一つの可能なアプローチは、そのトラフィックのための受信機を持っているのPEにはなく、VPLSインスタンス内のすべてのPEにパケットを送信するために、IGMPスヌーピングの使用を含めることです。 IGMPスヌーピングの適切な動作のために - - 顧客ブリッジまたはそのネットワークは、デュアルホーム接続性を持っている場合は、[RFC4541]で説明したようにPEは、顧客のトポロジ変更通知を受信すると、その顧客のUNIを超える「一般クエリ」を生成する必要があります。 PEによる「一般クエリは、」MACアドレス（複数可）が適切に顧客のトポロジの変更があるPEで登録されている顧客のマルチキャストを結果。 IGMPスヌーピングは、IPマルチキャストパケットのためのソリューションを提供し、一般的なマルチキャストデータには適用されないことに留意すべきです。
Using the IGMP snooping as described, the ingress PE can select a subset of PWs for packet replication, thus avoiding sending multicast packets to the egress PEs that don't need them. However, the replication is still performed by the ingress PE. In order to avoid replication at the ingress PE, one may want to use multicast distribution trees (MDTs) in the provider core network; however, this brings some potential pitfalls. If the MDT is used for all multicast traffic of a given customer, then this results in customer multicast and unicast traffic being forwarded on different PWs and even on a different physical topology within the provider network. This is a serious issue for customer bridges because customer Bridge Protocol Data Units (BPDUs), which are multicast data, can take a different path through the network than the unicast data. Situations might arise where either unicast OR multicast connectivity is lost. If unicast connectivity is lost but multicast forwarding continues to work, the customer spanning tree would not take notice which results in loss of its unicast traffic. Similarly, if multicast connectivity is lost, but unicast is working, then the customer spanning tree will activate the blocked port, which may result in a loop within the customer network. Therefore, the MDT cannot be used for both customer multicast control and data traffic. If it is used, it should only be limited to customer data traffic. However, there can be a potential issue even when it is used for customer data traffic since the MDT doesn't fit the PE model described in Figure 1 (it operates independently from the full mesh of PWs that correspond to an S-VLAN). It is also not clear how connectivity fault management (CFM) procedures (802.1ag) used for the ESI integrity check (e.g., per service instance) can be applied to check the integrity of the customer multicast traffic over the provider MDT. Because of these potential issues, the specific applications of the provider MDT to customer multicast traffic shall be documented and its limitations be clearly specified.
説明するように、IGMPスヌーピングを使用して、イングレスPEは、このようにそれらを必要としない出口PEにマルチキャストパケットを送信避け、パケット複製のためのPWサブセットを選択することができます。ただし、レプリケーションはまだ入力PEによって行われます。入口PEに複製を回避するために、一つは、プロバイダコアネットワーク内のマルチキャスト配信ツリー（MDTs）を使用することができます。しかし、これはいくつかの潜在的な落とし穴をもたらします。 MDTは、所与の顧客のすべてのマルチキャストトラフィックのために使用される場合、これは、顧客のマルチキャストと異なるのPW上に、さらに、プロバイダネットワーク内の異なる物理的トポロジに転送されるユニキャストトラフィックをもたらします。マルチキャストデータであり、顧客ブリッジプロトコルデータユニット（BPDUが）、ユニキャストデータより、ネットワークを介して別のパスを取ることができますので、これは、顧客ブリッジのための深刻な問題です。ユニキャストまたはマルチキャストの接続性のいずれかが失われている状況が発生する可能性があります。ユニキャスト接続が失われたが、マルチキャスト転送が動作し続けている場合、顧客スパニングツリーは、そのユニキャストトラフィックの損失をもたらすの通知を取らないでしょう。同様に、マルチキャスト接続が失われるが、ユニキャストが動作して、その後スパニングツリー顧客は、顧客ネットワーク内のループをもたらすことができるブロックされたポートを活性化します。したがって、MDTは、顧客のマルチキャスト制御とデータトラフィックの両方に使用することはできません。それが使用されている場合は、それが唯一の顧客データトラフィックに制限する必要があります。しかしながら、MDTは、図1で説明したPEモデルに適合しないので、それは（それがS-VLANに対応するのPWのフルメッシュとは独立して動作）顧客データトラフィックのために使用されても潜在的な問題が存在することができます。 ESIの整合性チェック（例えば、サービスインスタンスごと）に使用する接続障害管理（CFM）手続き（802.1ag）は、プロバイダMDT上で顧客マルチキャストトラフィックの整合性をチェックするために適用する方法も明確ではありません。そのため、これらの潜在的な問題のため、顧客のマルチキャストトラフィックに、プロバイダMDTの具体的な用途は、文書化しなければならないとその限界を明確に指定すること。
A single CE or a customer network can be connected to a provider network using more than one User-Network Interface (UNI). Furthermore, a single CE or a customer network can be connected to more than one provider network. [RFC4665] provides some examples of such customer network connectivity; they are depicted in Figure 3 below. Such network topologies are designed to protect against the failure or removal of network components from the customer network, and it is assumed that the customer leverages the spanning tree protocol to protect against these cases. Therefore, in such scenarios, it is important to flush customer MAC addresses in the provider network upon the customer topology change in order to avoid black-holing of customer frames.
単一のCEまたは顧客ネットワークは、複数のユーザネットワークインタフェース（UNI）を使用してプロバイダネットワークに接続することができます。さらに、単一のCEまたは顧客ネットワークは、複数のプロバイダ・ネットワークに接続することができます。 [RFC4665]は、顧客ネットワーク接続のいくつかの例を提供します。それらは以下の図3に示されています。そのようなネットワークトポロジーは、顧客ネットワークからネットワーク構成要素の故障または除去から保護するように設計され、顧客がこれらのケースから保護するためにスパニングツリープロトコルを利用しているものとします。したがって、このようなシナリオでは、顧客フレームのブラックホール化を避けるために、顧客のトポロジー変更時にプロバイダーのネットワークで顧客のMACアドレスをフラッシュすることが重要です。
+----------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+\ +------+ +------+\ +------+
| \ | | \ |
|Back \ | |Back \ +---------------
|door \ | SP network |door \ +---------------
|link \ | |link \ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+------------ +---------------
(a) (b)
Figure 3. Combination of Dual-Homing and Backdoor Links for CE Devices
デュアルホーミングおよびCEデバイス用バックドアリンクの図3.組み合わせ
The customer networks use their own instances of the spanning tree protocol to configure and partition their active topology so that the provider connectivity doesn't result in a data loop. Reconfiguration of a customer's active topology can result in the apparent movement of customer end stations from the point of view of the PEs. There are two methods for addressing this issue based on the provider bridge model depicted in Figure 1. In the first method, the Topology Change Notification (TCN) message received from the CE device is translated into one or more out-of-band "MAC Address Withdrawal" messages as specified in [RFC4762]. In the second method, the TCN message received from the CE device is translated into one or more in-band "Flush" messages per [p802.1Qbe]. The second method is recommended because of ease of interoperability between the bridge and LAN emulation modules of the PE.
顧客のネットワークは、プロバイダ接続がデータループが生じないように、彼らのアクティブトポロジを構成し、分割するスパニングツリープロトコルの独自のインスタンスを使用しています。顧客のアクティブトポロジーの再構成は、PEの観点から、顧客のエンドステーションの見かけの動きにつながることができます。第一の方法では、図1に示されているプロバイダ・ブリッジ・モデルに基づいて、この問題に対処するための2つの方法があり、CE機器から受信したトポロジ変更通知（TCN）メッセージは、帯域外一つ以上に翻訳され、「MAC [RFC4762]で指定されているよう撤退」メッセージの宛先を指定。第2の方法では、TCNメッセージは、CEデバイスが帯域内一つ以上[p802.1Qbe]あたりの「フラッシュ」メッセージに変換されるから受け取りました。第二の方法は、PEためのブリッジとLANエミュレーションモジュールとの間の相互運用性を容易にするのが推奨されます。
[RFC4762] talks about dual-homing of a given Multi-Tenant Unit switch (MTU-s) to two PEs over a provider MPLS access network to provide protection against link and node failure. For example, in case the primary PE fails or the connection to it fails, then the MTU-s uses the backup PWs to reroute the traffic to the backup PE. Furthermore, it discusses the provision of redundancy when a provider Ethernet access network is used and how any arbitrary access network topology (not just hub-and-spoke) can be supported using the provider's MSTP protocol. It also discusses how the provider MSTP for a given access network can be confined to that access network and operate independently from MSTP protocols running in other access networks.
[RFC4762]のリンクとノードの障害に対する保護を提供するプロバイダMPLSアクセスネットワーク上の2つのPEに与えられるマルチテナントユニットのスイッチ（MTU-S）のデュアルホーミングについて協議。プライマリPEに障害が発生したかへの接続が失敗した場合には、例えば、次にMTU-sがバックアップPEにトラフィックを再ルーティングするためのPWバックアップを使用します。プロバイダイーサネットアクセスネットワークを使用するとどのように任意のアクセスネットワークトポロジー（ハブアンドスポークだけではなく）は、プロバイダのMSTPプロトコルを使用してサポートすることができたときにまた、冗長性の提供について説明します。また、与えられたアクセスネットワークのプロバイダMSTPは、そのアクセスネットワークに限定し、他のアクセスネットワークで実行されているMSTPプロトコルから独立して動作することができます方法について説明します。
In both types of redundancy mechanism (Ethernet and MPLS access networks), only one PE is active for a given VPLS instance at any time. In case of an Ethernet access network, core-facing PWs (for a VPLS instance) at the PE are blocked by the MSTP; whereas, in case of a MPLS access network, the access-facing PW is blocked at the MTU-s for a given VPLS instance.
冗長機構（イーサネットおよびMPLSアクセスネットワーク）の両方のタイプでは、唯一のPEは、いつでも所与のVPLSインスタンスに対してアクティブです。イーサネット（登録商標）アクセスネットワークの場合には、PEで（VPLSインスタンスの）コア方向のPWがMSTPによって遮断されます。一方、MPLSアクセスネットワークの場合には、アクセスに面しPWは、所与のVPLSインスタンスのMTU-sで遮断されます。
------------------------+ Provider +-----------------------
. Core .
+------+ . . +------+
| PE |======================| PE |
Provider | (P) |---------\ /-------| (P) | Provider
Access +------+ . \ / . +------+ Access
Network . \/ . Network
(1) +------+ . /\ . +------+ (2)
| PE |----------/ \--------| PE |
| (B) |----------------------| (B) |
+------+ . . +------+
. .
------------------------+ +-----------------------
Figure 4. Bridge Module Model
図4.ブリッジモジュールモデル
Figure 4 shows two provider access networks each with two PEs that are connected via a full mesh of PWs for a given VPLS instance. As shown in the figure, only one PE in each access network serves as a Primary PE (P) for that VPLS instance and the other PE serves as the backup PE (B). In this figure, each primary PE has two active PWs originating from it. Therefore, when a multicast, broadcast, and unknown unicast frame arrives at the primary PE from the access network side, the PE replicates the frame over both PWs in the core even though it only needs to send the frame over a single PW (shown with "==" in Figure 4) to the primary PE on the other side. This is an unnecessary replication of the customer frames and consumes core- network bandwidth (half of the frames get discarded at the receiving PE). This issue is aggravated when there are more than two PEs per provider access network -- e.g., if there are three PEs or four PEs per access network, then 67% or 75%, respectively, of core-network bandwidth for multicast, broadcast, and unknown unicast are respectively wasted.
図4は、2つのプロバイダのアクセスネットワーク所定のVPLSインスタンスのためのPWのフルメッシュを介して接続された2個のPEとのそれぞれを示しています。同図に示すように、そのためのプライマリPE（P）は、VPLSインスタンスと他のPEがバックアップPE（B）としての役割を果たすように、各アクセスネットワーク内の唯一のPEが働きます。この図では、各一次PEは、それに由来する二つの活性のPWを有しています。マルチキャスト、ブロードキャスト、および未知のユニキャストフレームは、アクセスネットワーク側からプライマリPEに到達したときしたがって、PEは、それだけ（で示された単一のPW上にフレームを送信する必要があるにもかかわらず、コアの両方のPW上にフレームを複製します反対側のプライマリPEに）図4に「==」。これは、顧客フレームの不必要な複製で、（フレームの半分を受け取るPEで廃棄ます）コア - ネットワーク帯域幅を消費します。マルチキャスト、ブロードキャストのためのコア・ネットワーク帯域幅のそれぞれ3つのPEやアクセスネットワークごとに4つのPE、その後、67％または75％は、存在する場合、例えば、 - プロバイダのアクセスネットワークあたりつ以上のPEがある場合にこの問題が悪化しますそして未知のユニキャストはそれぞれ無駄にしています。
Therefore, it is recommended to have a protocol among PEs that can disseminate the status of PWs (active or blocked) among themselves. Furthermore, it is recommended to have the protocol tied up with the redundancy mechanism such that (per VPLS instance) the status of active/backup PE gets reflected on the corresponding PWs emanating from that PE.
したがって、それらの間のPW（アクティブまたはブロック）の状態を広めることができるのPE間のプロトコルを有することが推奨されます。更に、（VPLSインスタンスごとに）アクティブ/バックアップPEのステータスがそのPEから発する対応のPWに反映されることを、このような冗長機構と提携プロトコルを有することが推奨されます。
The above discussion was centered on the inefficiency regarding packet replication over MPLS core networks for current VPLS redundancy mechanism. Another important issue to consider is the interaction between customer and service provider redundancy mechanisms, especially when customer devices are IEEE bridges. If CEs are IEEE bridges, then they can run RSTPs or MSTPs. RSTP convergence and detection time is much faster than its predecessor (IEEE 802.1D STP, which is obsolete). Therefore, if the provider network offers a VPLS redundancy mechanism, then it should provide transparency to the customer's network during a failure within its network, e.g., the failure detection and recovery time within the service provider network should be less than the one in the customer network. If this is not the case, then a failure within the provider network can result in unnecessary switch-over and temporary flooding/loop within the customer's network that is dual-homed.
上記の議論は、現在のVPLS冗長機構のためのMPLSコアネットワーク上でパケットの複製に関する非効率性を中心としました。考慮すべきもう一つの重要な問題は、顧客のデバイスがIEEEブリッジしている場合は特に、顧客とサービスプロバイダの冗長性メカニズムとの間の相互作用です。 CEはIEEEブリッジしている場合、それらはRSTPsまたはMSTPsを実行することができます。 RSTPの収束と検出時間は、その前身（廃止されたIEEE 802.1D STP）よりもはるかに高速です。プロバイダのネットワークがVPLSの冗長性のメカニズムを提供しています場合したがって、それは、そのネットワーク内の障害時に、お客様のネットワークへの透明性を提供する必要があり、例えば、サービス・プロバイダ・ネットワーク内の障害検出および回復時間は、顧客の1未満でなければなりません通信網。そうでない場合は、プロバイダーネットワーク内の障害が不要なスイッチオーバーおよびデュアルホームである顧客のネットワーク内の一時的な洪水/ループになることができます。
When customer devices are routers, servers, or hosts, then the number of MAC addresses per customer sites is very limited (most often one MAC address per CE). However, when CEs are bridges, then there can be many customer MAC addresses (e.g., hundreds of MAC addresses) associated with each CE.
顧客のデバイスは、ルータ、サーバ、またはホスト、そして顧客サイトごとのMACアドレスの数が非常に限られている（CEごとに、最も多くの場合、1つのMACアドレス）のとき。 CEがブリッジである場合しかし、各CEに関連する多くの顧客MACアドレス（MACアドレスの、例えば、数百）が存在することができます。
[802.1ad] has devised a mechanism to alleviate MAC address learning within provider Ethernet networks that can equally be applied to VPLS networks. This mechanism calls for disabling MAC address learning for an S-VLAN (or a service instance) within a provider bridge (or PE) when there is only one ingress and one egress port associated with that service instance on that PE. In such cases, there is no need to learn customer MAC addresses on that PE since the path through that PE for that service instance is fixed. For example, if a service instance is associated with four CEs at four different sites, then the maximum number of provider bridges (or PEs) that need to participate in that customer MAC address learning is only three, regardless of how many PEs are in the path of that service instance. This mechanism can reduce the number of MAC addresses learned in a hierarchical VPLS (H-VPLS) with QinQ access configuration.
[802.1ad]は等しくVPLSネットワークに適用することができるプロバイダのイーサネットネットワーク内のMACアドレス学習を軽減する仕組みを考案しました。このメカニズムは、PE上のサービスインスタンスに関連付けられている唯一の入口と一つの出口ポートがある場合、プロバイダブリッジ（またはPE）内のS-VLANのMACアドレス学習（またはサービスインスタンス）を無効にするためのコール。このような場合には、そのサービスインスタンスのためにそのPEを通過する経路が固定されているので、そのPE上の顧客MACアドレスを学習する必要はありません。サービスインスタンスは、4つの異なる部位に4つのCEに関連付けされている場合、その顧客MACアドレス学習に参加する必要がプロバイダブリッジ（またはPES）の最大数にかかわらず、であるどのように多くのPEの3つだけですそのサービスインスタンスのパス。この機構はQinQアクセスコンフィギュレーションと階層VPLS（H-VPLS）で学習したMACアドレスの数を減らすことができます。
If the provider access network is of type Ethernet (e.g., IEEE 802.1ad-based network), then the MSTP can be used to partition the access network into several loop-free spanning tree topologies where Ethernet service instances (S-VLANs) are distributed among these tree topologies. Furthermore, GVRP can be used to limit the scope of each service instance to a subset of its associated tree topology (thus limiting the scope of customer MAC address learning to that sub-tree). Finally, the MAC address disabling mechanism (described above) can be applied to that sub-tree to further limit the number of nodes (PEs) on that sub-tree that need to learn customer MAC addresses for that service instance.
プロバイダのアクセスネットワーク（例えば、IEEE 802.1adベースのネットワーク）タイプのイーサネットである場合、MSTPは、イーサネットサービスインスタンス（S-VLANが）分散されているいくつかのループのないスパニングツリートポロジーにアクセスネットワークを分割するために使用することができますこれらのツリー・トポロジーの中で。また、GVRPは、その関連ツリートポロジのサブセットに各サービスインスタンスの範囲を限定するために使用することができる（したがって、そのサブツリーに顧客MACアドレス学習の範囲を限定するもの）。最後に、（上述の）MACアドレス無効化機構は、さらに、そのサービスインスタンスのカスタマーMACアドレスを学習する必要があり、そのサブツリー上のノード（PES）の数を制限するために、そのサブツリーに適用することができます。
Furthermore, [802.1ah] provides the capability of encapsulating customers' MAC addresses within the provider MAC header. A MTU-s capable of this functionality can significantly reduce the number of MAC addresses learned within the provider network for H-VPLS with QinQ access, as well as H-VPLS with MPLS access.
また、[802.1ahのは】プロバイダMACヘッダ内の顧客のMACアドレスをカプセル化する能力を提供します。 MTU-Sこの機能を可能に有意MPLSアクセスのH-VPLSならびに、QinQアクセスを有するH-VPLSのプロバイダネットワーク内で学習されたMACアドレスの数を減らすことができます。
[RFC4762] discusses H-VPLS provider-network topologies with both Ethernet [802.1ad] and MPLS access networks. Therefore, it is important to ensure seamless interoperability between these two types of networks.
[RFC4762]は、イーサネット[802.1ad]とMPLSアクセスネットワークの両方でH-VPLSプロバイダネットワークトポロジについて説明します。そのため、ネットワークのこれらの2つのタイプの間でシームレスな相互運用性を確保することが重要です。
Provider bridges as specified in [802.1ad] are intended to operate seamlessly with customer bridges and provide the required services. Therefore, if a PE is modeled based on Figures 1 and 2, which include a [802.1ad] bridge module, then it should operate seamlessly with Provider Bridges given that the issues discussed in this document have been taken into account.
[802.1ad]で指定されたプロバイダブリッジは、顧客ブリッジとシームレスに動作し、必要なサービスを提供することを意図しています。 PEは、[802.1ad]ブリッジモジュールを含む図1及び図2に基づいてモデル化される場合、したがって、それは本書で議論された問題が考慮されていることを考えるプロバイダブリッジとシームレスに動作しなければなりません。
The authors would like to thank Norm Finn and Samer Salam for their comments and valuable feedback.
作者は彼らのコメントと貴重なフィードバックのためのノーム・フィンとSAMERサラムに感謝したいと思います。
In addition to the security issues described in [RFC4762], the following considerations apply:
[RFC4762]で説明されたセキュリティ上の問題に加えて、次の考慮事項が適用されます。
- When a CE that is a customer bridge is connected to the VPLS network, it may be desirable to secure the end-to-end communication between the customer bridge nodes across the VPLS network. This can be accomplished by running [802.1AE] MAC security between the C-VLAN components of the customer bridges. In this case, the VPLS PEs must ensure transparent delivery of the encryption/security protocol datagrams using the Bridge Group Address [802.1ad].
- 顧客ブリッジであるCEがVPLSネットワークに接続されている場合、VPLSネットワークを介して顧客ブリッジノード間のエンド・ツー・エンドの通信を保護することが望ましい場合があります。これは、顧客ブリッジのC-VLANコンポーネント間[802.1AE] MACセキュリティを実行することによって達成することができます。この場合、VPLS PEはブリッジグループアドレス[802.1ad]を使用して暗号化/セキュリティプロトコルデータグラムの透明配達を確認する必要があります。
- When a CE that is a customer bridge is connected to the VPLS network, it may be desirable to secure the communication between the customer bridge and its directly connected PE. If the PE is modeled to include a [802.1ad] bridge module, then this can be achieved by running MAC security between the customer bridge and the S-VLAN component of the VPLS PE as described in Section 7.7.2 of [802.1AX].
- 顧客ブリッジであるCEがVPLSネットワークに接続されている場合、顧客のブリッジと直接接続されたPE間の通信を保護することが望ましい場合があります。 PEは、[802.1ad]ブリッジモジュールを含むようにモデル化される場合の、セクション7.7.2に記載したように、これは、顧客のブリッジとVPLS PEのS-VLAN成分とMACセキュリティを実行することによって達成することができる[802.1AX] 。
- When an 802.1ad network is connected to a VPLS network, it is possible to secure the NNI between the two networks using the procedures of [802.1AE] and [802.1AX] between the S-VLAN components of the Provider Edge Bridge and the attached VPLS PE, as long as the PE is modeled to include an [802.1ad] bridge module.
- 802.1adネットワークがVPLSネットワークに接続されている場合、[802.1AE]の手順を使用して2つのネットワーク間NNIを確保することが可能であり、[802.1AX]プロバイダエッジ・ブリッジとのS-VLANコンポーネント間VPLS PEであればPEは[802.1ad]ブリッジモジュールを含むようにモデル化されるように、取り付けられています。
[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月。
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "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月を。
[802.1ad] IEEE 802.1ad-2005, "Amendment to IEEE 802.1Q-2005. IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Revision-Amendment 4: Provider Bridges".
[802.1ad] IEEE 802.1ad-2005、 "地方とメトロポリタンエリアネットワークのIEEE 802.1Q-2005 IEEE規格の改正 - 仮想ブリッジローカルエリアネットワークリビジョン-修正4：プロバイダブリッジ"。
[802.1AE] IEEE 802.1AE-2006, "IEEE Standard for Local and Metropolitan Area Networks - Media Access Control (MAC) Security".
[802.1AE] IEEE 802.1AE-2006、 "地方とメトロポリタンエリアネットワークのIEEE標準 - メディアアクセス制御（MAC）セキュリティ"。
[802.1ag] IEEE 802.1ag-2007, "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management".
[802.1ag] IEEE 802.1ag-2007、「地方とメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジローカルエリアネットワーク改正5：接続障害管理」。
[802.1ah] IEEE 802.1ah-2008, "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges".
[802.1ahの] IEEE 802.1ahの-2008、「地方とメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジローカルエリアネットワーク修正7：プロバイダーバックボーンブリッジ」。
[802.1AX] IEEE 802.1AX-2008 "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation".
[802.1AX] IEEE 802.1AX-2008 " - リンクアグリゲーション地方とメトロポリタンエリアネットワークのIEEE規格"。
[IPLS] Shah, H., Rosen, E., Le Faucheur, F., and G. Heron, "IP-Only LAN Service (IPLS)", Work in Progress, February 2010.
[IPLS]シャー、H.、ローゼン、E.、ルFaucheur、F.、およびG.サギ、 "IP-のみのLANサービス（IPLS）"、進歩、2010年2月での作業。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]マティーニ、L.、エド。、ローゼン、E.、エル・Aawar、N.、およびG.サギ、 "MPLSネットワーク上のイーサネットの輸送のためのカプセル化方法"、RFC 4448、2006年4月。
[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）スヌーピングスイッチの考慮事項"。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]アンデション、L.、エド。、およびE.ローゼン、エド。、RFC 4664 "レイヤ2個の仮想プライベートネットワーク（のL2VPN）のためのフレームワーク"、2006年9月。
[RFC4665] Augustyn, W., Ed., and Y. Serbest, Ed., "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006.
[RFC4665]アウグスティン、W.、エド。、およびY. Serbest、エド。、 "レイヤ2プロバイダ・プロビジョニングされた仮想プライベートネットワークのサービスの要件"、RFC 4665、2006年9月。
[RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework", RFC 6136, March 2011.
[RFC6136] Sajassi、A.、エド。、およびD.モハン、エド。、 "レイヤ2バーチャルプライベートネットワーク（L2VPN）運用、管理、および保守（OAM）要件とフレームワーク"、RFC 6136、2011年3月。
[802.1D] IEEE 802.1D-2004, "IEEE Standard for Local and Metropolitan Area Networks - Media access control (MAC) Bridges (Incorporates IEEE 802.1t-2001 and IEEE 802.1w)".
[802.1D] IEEE 802.1D-2004、 "地方とメトロポリタンエリアネットワークのIEEE標準 - メディアアクセス制御（MAC）ブリッジ（IEEE 802.1トン-2001およびIEEE 802.1ワットを内蔵）"。
[802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area Networks".
[802.1Q] IEEE STD。 802.1Q-2003「仮想ブリッジローカルエリアネットワーク」。
[p802.1Qbe] IEEE Draft Standard P802.1Qbe, "IEEE Draft Standard for Local and Metropolitan Area Networks -- Virtual Bridged Local Area Networks Amendment: Multiple I-SID Registration Protocol".
[p802.1Qbe] IEEEドラフト規格P802.1Qbe、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準案 - 仮想ブリッジローカルエリアネットワーク修正：複数のI-SID登録プロトコル」。
Authors' Addresses
著者のアドレス
Ali Sajassi (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 EMail: sajassi@cisco.com
アリSajassi（エディタ）は、シスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 Eメール：sajassi@cisco.com
Frank Brockners Cisco Systems, Inc. Hansaallee 249 40549 Duesseldorf Germany EMail: fbrockne@cisco.com
フランクBrocknersシスコシステムズ、株式会社Hansaallee 249 40549デュッセルドルフドイツEメール：fbrockne@cisco.com
Dinesh Mohan (editor) Nortel Ottawa, ON K2K3E5 EMail: dinmohan@hotmail.com
ディネッシュモハン（エディタ）ノーテルオタワ、K2K3E5メールに：dinmohan@hotmail.com
Yetik Serbest AT&T Labs 9505 Arboretum Blvd. Austin, TX 78759 EMail: yetik_serbest@labs.att.com
Yetik Serbest AT＆T Labsの9505植物園ブルバードオースティン、TX 78759 Eメール：yetik_serbest@labs.att.com