[要約] 要約：RFC 6246は、仮想プライベートLANサービス（VPLS）と顧客エッジ（CE）ブリッジの相互運用性に関するガイドラインを提供しています。 目的：このRFCの目的は、VPLSとCEブリッジの間での効果的な通信と相互運用性を確保するための手法とプロトコルを提供することです。
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
仮想プライベートLANサービス（VPLS）顧客エッジ（CE）ブリッジとの相互運用性
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）の背後にある主な動機の1つは、顧客ルーターやサーバー/ホストだけでなく、顧客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ブリッジとの相互運用性の問題の大部分を802.1ADブリッジモジュールに委任できるため、VPLS PE内のIETF LANエミュレーションモジュールの負担を削除できることが示されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6246.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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).
Virtual Private LANサービス（VPLS）は、LANを使用して接続されているかのように、MAN/WAN（MPLS/IPを超えて）にわたって地理的に分散した顧客サイト間の接続性を提供することを目的としたLANエミュレーションサービスです。VPLSの背後にある主な動機の1つは、顧客ルーターやサーバー/ホストだけでなく、IEEEの顧客ブリッジ間で接続性を提供できることです。顧客IPルーター/ホスト間の接続のみが必要な場合は、IPのみのLANサービス[IPLS]ソリューションを使用できます。VPLSソリューションの強度は、ブリッジタイプと非ブリッジタイプのCEデバイスの両方への接続を提供できることです。VPLSは、現在のエンタープライズユーザーが独自のエンタープライズブリッジネットワーク[802.1D] [802.1Q]から慣れているのと同じレベルのサービスを提供することが期待されています。 - ベースのネットワーク[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ブリッジとの相互運用性の問題の大部分を802.1ADブリッジモジュールに委任できるため、VPLS PE内のIETF LANエミュレーションモジュールの負担を削除できることを説明しています。このドキュメントは、これらの問題について説明し、可能な限り、これらの問題を修正する際に調査する領域を提案しています。これらの問題の詳細なソリューション仕様は、このドキュメントの範囲外です。
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-Bridgeの問題を2つのグループに分類します。1）必須および2）オプション。CEブリッジの適切な動作を確保するために、グループ（1）の問題に対処する必要があります。グループ（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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
ブリッジングの問題の議論を開始する前に、イーサネットサービスの定義を明確にすることが重要です。VPLという用語は、さまざまなコンテキストで異なる意味を持っています。一般に、VPLSは次のコンテキスト[RFC6136]で使用されます：a）1つ以上のネットワークを介したエンドツーエンドのブリッジ付きLANサービス（MPLS/IPネットワークの1つ）、b）これらのブリッジ付きLANサービスをサポートするネットワーク、およびc）as（v）LANエミュレーション。明確にするために、VPLSネットワークとVPLSインスタンスという用語をそれぞれ使用して、ネットワークとしての使用としての使用法を区別します。さらに、VPL（ネットワークとサービスの両方）を、MPLS/IPネットワークにまたがるエンドツーエンドネットワークの部分のみに限定します。（特定の顧客のさまざまなサイトの中で）エンドツーエンドサービスの場合、「イーサネットサービスインスタンス」または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 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）を、特定の顧客にイーサネットサービスが提供される2つ以上のアタッチメント回路（ACS）の関連付けとして定義します。ACは、ユーザーネットワークインターフェイス（UNI）またはネットワークネットワークインターフェイス（NNI）のいずれかです。さらに、それはイーサネットインターフェイスまたはVLANである場合があり、ATMまたはフレームリレー仮想回路であるか、PPP/HDLC（PPP/高レベルのデータリンクコントロール）インターフェイスである場合があります。ESIが2つのACSに関連付けられている場合、それはマルチポイント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インスタンスに対応できます。また、関連するACSがプロバイダーブリッジネットワーク[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）アドレスドメインとブロードキャストドメインを提供するように、その実現が行われます。別のMACアドレスドメインは、ESIごとに別のMAC転送テーブル（フォワード情報ベース（FIB）、フィルタリングデータベース[802.1d]とも呼ばれる）を使用して提供されます（VPLSおよびIEEE 802.1ADネットワークの両方）。別のブロードキャストドメインは、VPLSネットワークのIP/MPLSコア上のESIごとの完全なメッシュおよび/またはIEEE 802.1ADネットワークのESIごとに専用のサービスVLANを使用して提供されます。
[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番目のモデルには、そのPE上のすべてのVPLSインスタンスをサポートする単一のブリッジモジュールが含まれています。ここで、各VPLSインスタンスはそのブリッジモジュール内の一意のVLAN（サービスVLANまたは呼ばれます）で表されます。s-vlan）。ブリッジモジュールには、すべてのVPLSフォワーダーと通信する単一の「エミュレートLAN」インターフェイスがあり、各VPLSインスタンスは一意のS-VLANタグで表されます。各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対応PEモデル
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は、そのVPLSインスタンスに関連付けられた擬似動物のセット（PWS）上にフレームを送信する前に剥がされます（[RFC4448]で指定されているようにRAWモード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
図2. 802.1ADブリッジモジュールのモデル
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タグを使用して顧客フレームにタグをタグ付けし、出口方向（顧客UNISに向かって）でS-VLANタグを削除する責任があります。また、Rapid Spanning Tree Protocol（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などの顧客のブリッジングプロトコルの一部に参加する必要があります。1つのサイトのc-vlanを別のサイトで別のc-vlanにマッピングできるか、非対称マッピングの場合、1つのサイトの顧客イーサネットポートをC-vlanにマッピングできるため、このような参加が必要です。別のサイトでc-vlansのグループ）。
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 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.
C-VLANブリッジコンポーネントは、C-VLANタグに基づいてサービスの選択と識別を行います。顧客デバイスの各フレームはC-VLANに割り当てられ、1つ以上の内部ポートベースのインターフェイスで提示され、それぞれが顧客がそのC-VLANを運ぶことを望んでいる単一のサービスインスタンスをサポートしています。同様に、プロバイダーネットワークのフレームは、S-VLANタグに基づいて、内部インターフェイスまたは「LAN」（例：C-VLANコンポーネントとS-VLANコンポーネントの間）に割り当てられます。各内部インターフェイスは単一のサービスインスタンスをサポートするため、S-VLANタグは、S-VLANブリッジコンポーネントによってこのインターフェイスで削除される可能性があります。このサービスインスタンス（たとえば、VLANバンドルまたはポートベースのサービスを介して）で複数のC-VLANがサポートされている場合、フレームはすでにC-VLANタグでタグ付けされています。単一のC-VLANがこのサービスインスタンス（例：VLANベース）でサポートされている場合、C-VLANはS-VLANから導出できるため、フレームはC-VLANタグでタグ付けされていません（例：1つは、 - 1つのマッピング）。C-VLAN-AWAREブリッジコンポーネントは、各内部の「LAN」で受信されたアンテグフレームにポートVLAN ID（PVID）を適用し、各C-VLANのフレームの配信を顧客UNIポートから完全に制御できるようにします。
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、または2つの組み合わせのみに関連付けることができます（たとえば、サービスの一方の端は物理イーサネットポートに関連付けられ、もう一方の端はVLANに関連付けられている可能性があります）。[RFC4762]では、それぞれ資格のない資格のある学習を使用して、それぞれポートベースとVLANベースの操作を参照しています。[RFC4762]は、異なるタイプのイーサネットACS間の可能なマッピング（802.1D、802.1Q、または802.1ADフレームなど）を説明していません。一般に、特定のサービスインスタンスへの顧客ポートまたはVLANのマッピングは、ローカルPEによって実行されるローカル機能であり、サービスプロビジョニングはそれに対応します。言い換えれば、ESIを制限および制限する理由はありません。ESIは、ポートベースのACのみを持つか、VLANベースのACのみを持つことです。[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 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".
次の表には、顧客ACSとそれに関連するESIの間に存在する可能性のあるマッピングを示します。ご覧のとおり、このようなマッピングを実行する方法はいくつかあります。最初のシナリオでは、イーサネットの物理ポートには攻撃されていないトラフィックのみが運ばれ、すべてのトラフィックが対応するサービスインスタンスまたはESIにマッピングされると想定されています。これは、「編集されていないトラフィックを備えたポートベース」と呼ばれます。2番目のシナリオでは、イーサネットの物理ポートにはタグ付きトラフィックとタグ付きトラフィックの両方が搭載されており、すべてのトラフィックが対応するサービスインスタンスまたはESIにマッピングされると想定されています。これは、「タグ付きトラフィックとタグなしトラフィックを備えたポートベース」と呼ばれます。3番目のシナリオでは、単一の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（note-2）yタグ付き＆untagged
VLAN-based Y(Note-1) Y(Note-2) Y Y(Note-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を備えたCEデバイスは[802.1Q]フレーム形式をサポートできると想定されています。
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：この非対称マッピングシナリオでは、「VLANベースの」ACを備えたCEデバイスは、[802.1AD]フレーム形式をサポートできます。VLANとインナータグは、「ポートベース」ACから受け取ったC-VLANです。このようなCEデバイスのアプリケーションの例の1つは、メトロイーサネットネットワーク上のDSL集約用のブロードバンドリモートアクセスサーバー（BRA）にあります。
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ベースの」ACを備えたCEデバイスが[802.1AD]フレーム形式をサポートできると想定されています。-vlanと内側のタグは、「VLANバンドリング」ACから受け取ったC-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が特定のESIにS-VLANタグを使用している場合（顧客トラフィックにS-VLANタグを追加するか、C-VLANタグをS-VLANタグに置き換えることにより）、S-S-SETYPEのS-VLANタグを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である場合、それらのサイト間で調整なしに、異なるサイトで異なる顧客VLANを単一のESIにマッピングすることができます。
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タグを使用して、そのACで受け取った顧客トラフィックを特定のESIに属しているとマークする場合があります。PEが追加のS-VLANタグを使用する場合、反対方向に、PEは同じACに顧客フレームを送信する前にS-VLANタグを剥がします。ただし、ACでVLANマッピングモードが使用され、PEがS-VLANタグをローカルに使用する場合、イーサネットインターフェイスがUNIの場合、このインターフェイスのタグ付きフレームには[802.1Q]に基づいたフレーム形式があります。。そのような場合、PEは、顧客からフレームを受け取ったときに、顧客タグ（C-VLAN）をプロバイダータグ（S-VLAN）に変換するものとします。反対の方向には、PEはプロバイダーフレーム形式（802.1AD）から顧客フレーム形式（802.1Q）に翻訳するものとします。
All the above asymmetric services can be supported via the PE model with the bridge module depicted in Figure 2 (based on [802.1ad]).
上記のすべての非対称サービスは、図2に示されているブリッジモジュールを使用して、PEモデルを介してサポートできます（[802.1AD]に基づく）。
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) 提供されたサービスを使用して、さまざまなサイトのCES間のプロトコルの動作に対して透明で、橋のない個々の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ブリッジプロトコル処理は、図2に示すブリッジモジュールを使用して、PEモデルを介してサポートできます（[802.1AD]に基づいています）。たとえば、アタッチメント回路がポートベースである場合、PEのブリッジモジュールは、CEのRSTPまたはMSTPに関して透過的に動作できます（したがって、その顧客UNIにはC-VLANコンポーネントは必要ありません）。ただし、アタッチメント回路がVLANベース（VLANベースまたはVLANバンドル）の場合、PEのブリッジモジュールは、CEで実行されているRSTPまたはMSTPをピアにする必要があります（したがって、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アドレスのブロックを予約します。また、これらの予約されたMACアドレスのどれがC-VLANブリッジコンポーネント用のみであり、S-VLANブリッジコンポーネント用であり、C-VLANとS-VLANコンポーネントの両方に適用されるものを示しています。
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手順を使用するリンク状態ルーティングプロトコルを実行しているルーターである場合、PWSの部分メッシュは、選択したルーターのセット間で「ブラックホーリング」トラフィックをもたらす可能性があります。また、ESIに属するCEデバイスがIEEEブリッジである場合、PWSの部分的なメッシュは、顧客およびプロバイダーネットワークの放送嵐を引き起こす可能性があります。さらに、CEデバイスおよび/またはPEデバイスによって1つのフレームの複数のコピーが受信される可能性があります。したがって、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]手順を使用して、PWSの部分メッシュの検出に使用できます。[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間の接続チェックを実行できます。それは、たとえば、ネットワークの一方の端のあるACからネットワークのもう一方の端の別のACまで、管理ドメイン内のサービスインスタンスのエンドツーエンドの整合性をチェックします。したがって、そのパスカバレッジには、PE内のブリッジモジュールが含まれており、PWSのみに限定されません。さらに、[802.1AG]は、イーサネットレベルで動作する（PWレベルではなく）ため、特定のサービスインスタンスのPWSの完全なメッシュで透過的に動作します。PWは2つの単方向ラベルスイッチ付きパス（LSP）で構成されているため、1つの方向が他の方向とは独立して故障する可能性があることに注意してください。この場合でも、[802.1AG]の手順は、リモート欠陥の表示（RDI）に依存することにより、参加PESに対して完全なメッシュの一貫したビューを提供できます。
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.
もう1つの好ましくないオプションは、部分メッシュの検出手順を定義することです。この手順では、各PEは、PWエンドポイントエンティティ（EE、VPLSフォワーダーなど）のステータスと、他のPESによって報告されたEEを追跡します。したがって、PWの障害が発生すると、障害を検出するPEは、ローカルに注目するだけでなく、そのサービスインスタンスに属する他のPEに通知するため、すべての参加者PEがPWメッシュの一貫したビューを持っています。このような手順は、サービスインスタンスごとの部分メッシュの検出用であり、次に、双方向順方向検出（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は、イングレスの複製に依存しています。Ingress PEは、各出口PEのマルチキャストパケットを複製し、ユニキャストトンネル上のポイントツーポイントPWを使用して出力PEに送信します。VPLSは、擬似ワイヤの完全なメッシュによって形成されたオーバーレイトポロジで動作します。したがって、基礎となるトポロジに応じて、同じデータグラムを同じ物理リンクから複数回送信できます。現在、VPLSは、ネットワーク全体のESIのマルチキャストまたはブロードキャストトラフィックの分布を制限するメカニズムを提供していません。これにより、MPLSコアネットワークに追加の負荷が発生し、外部のマルチキャストパケットが破棄される受信PEで追加の処理が発生します。
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ネットワークよりもマルチキャストをより効率的に配信するための可能なアプローチの1つは、VPLSインスタンスのすべてのPESではなく、そのトラフィックの受信機を持つPESのみにパケットを送信するために、IGMPスヌーピングの使用を含めることです。顧客ブリッジまたはそのネットワークにデュアルホーム接続がある場合、IGMPスヌーピングの適切な操作のために、PEは[RFC4541]に記載されているように、顧客トポロジの変更通知を受信する際に、その顧客のUNIを「一般的なクエリ」を生成する必要があります。。PEによる「一般的なクエリ」は、顧客トポロジの変更があるときにPEで適切に登録されている顧客マルチキャストMacアドレスが適切に登録されています。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スヌーピングを使用して、Ingress PEはパケットレプリケーションのためにPWSのサブセットを選択できるため、それらを必要としない出口PESにマルチキャストパケットの送信を回避できます。ただし、複製はまだ侵入PEによって実行されます。Ingress PEでの複製を避けるために、プロバイダーコアネットワークでマルチキャスト配布ツリー（MDT）を使用することをお勧めします。ただし、これは潜在的な落とし穴をもたらします。MDTが特定の顧客のすべてのマルチキャストトラフィックに使用されている場合、これにより、顧客のマルチキャストとユニキャストトラフィックが異なるPWSおよびプロバイダーネットワーク内の異なる物理トポロジーでさえ転送されます。これは、マルチキャストデータである顧客ブリッジプロトコルデータユニット（BPDU）がユニキャストデータとは異なるパスをとることができるため、顧客ブリッジにとって深刻な問題です。ユニキャストまたはマルチキャストの接続が失われる状況が発生する可能性があります。ユニキャストの接続性が失われたが、マルチキャスト転送が機能し続けている場合、顧客のスパニングツリーは、ユニキャストトラフィックの損失をもたらすことに気付かないでしょう。同様に、マルチキャスト接続が失われたがユニキャストが機能している場合、顧客スパニングツリーはブロックされたポートをアクティブにし、顧客ネットワーク内のループになる可能性があります。したがって、MDTは、顧客のマルチキャスト制御とデータトラフィックの両方に使用することはできません。使用する場合は、顧客データトラフィックにのみ制限される必要があります。ただし、MDTが図1に説明するPEモデルに適合しないため、顧客データトラフィックに使用されている場合でも潜在的な問題が発生する可能性があります（S-VLANに対応するPWSの完全なメッシュとは独立して動作します）。また、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
図3. CEデバイス用のデュアルホーミングとバックドアリンクの組み合わせ
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.
顧客ネットワークは、スパニングツリープロトコルの独自のインスタンスを使用して、プロバイダーの接続がデータループにならないように、アクティブトポロジを構成および分割します。顧客のアクティブなトポロジの再構成により、PESの観点から顧客エンドステーションが見かけの動きをもたらす可能性があります。図1に示すプロバイダーブリッジモデルに基づいて、この問題に対処するための2つの方法があります。最初の方法では、CEデバイスから受信したトポロジ変更通知（TCN）メッセージが1つ以上のバンド外の「Mac」に変換されます。[RFC4762]で指定されている「撤退」メッセージ。2番目の方法では、CEデバイスから受信したTCNメッセージは、[P802.1QBE]ごとに1つまたは複数のインバンド「フラッシュ」メッセージに変換されます。BridgeとLANエミュレーションモジュールの間の相互運用性が容易であるため、2番目の方法が推奨されます。
[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]は、特定のマルチテナントユニットスイッチ（MTU-S）がプロバイダーMPLSアクセスネットワーク上の2つのPESへのデュアルホーミングについて、リンクとノードの障害に対する保護を提供することについて語っています。たとえば、プライマリPEが失敗したり、接続が失敗した場合、MTU-SはバックアップPWSを使用してバックアップPEへのトラフィックを再ルーティングします。さらに、プロバイダーのイーサネットアクセスネットワークが使用されている場合の冗長性の提供と、プロバイダーの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アクセスネットワーク）で、特定のVPLSインスタンスに対していつでもアクティブであるPEのみが1つのPEのみです。イーサネットアクセスネットワークの場合、PEのコア面でのPWS（VPLSインスタンスの場合）がMSTPによってブロックされます。一方、MPLSアクセスネットワークの場合、特定のVPLSインスタンスのMTU-Sでアクセス向けのPWがブロックされます。
------------------------+ 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は、特定のVPLSインスタンスのPWSの完全なメッシュを介して接続された2つのPESを備えた2つのプロバイダーアクセスネットワークを示しています。図に示すように、各アクセスネットワークの1つのPEのみがそのVPLSインスタンスの主要なPE（P）として機能し、もう1つはバックアップPE（B）として機能します。この図では、各プライマリPEには、そこから発生する2つのアクティブPWがあります。したがって、マルチキャスト、ブロードキャスト、および未知のユニキャストフレームがアクセスネットワーク側からプライマリPEに到着すると、PEは、単一のPWでフレームを送信するだけであっても、コア内の両方のPWのフレームを複製します（"=="の図4）反対側の主要なPEに。これは、顧客フレームの不必要な複製であり、コアネットワーク帯域幅を消費します（受信PEでフレームの半分が破棄されます）。この問題は、プロバイダーアクセスネットワークごとに2つ以上のPESがある場合に悪化します。たとえば、アクセスネットワークごとに3つのPEまたは4つのPEがある場合、それぞれ67％または75％、マルチキャスト、ブロードキャストのコアネットワーク帯域幅の67％または75％があります。および未知のユニキャストはそれぞれ無駄にされています。
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.
したがって、PESの間にPWS（アクティブまたはブロックされた）のステータスを広めることができるPESの間にプロトコルを持つことをお勧めします。さらに、（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コアネットワークを介したパケット複製に関する非効率性に集中していました。考慮すべきもう1つの重要な問題は、特に顧客デバイスがIEEEブリッジである場合、顧客とサービスプロバイダーの冗長性メカニズムの相互作用です。CESがIEEEブリッジである場合、RSTPまたはMSTPを実行できます。RSTPの収束と検出時間は、その前身よりもはるかに高速です（IEEE 802.1d STP、これは時代遅れです）。したがって、プロバイダーネットワークがVPLS冗長メカニズムを提供する場合、ネットワーク内の障害中に顧客のネットワークに透明性を提供する必要があります。通信網。そうでない場合、プロバイダーネットワーク内での障害により、デュアルホームの顧客ネットワーク内の不必要なスイッチオーバーおよび一時的な洪水/ループが生じる可能性があります。
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アドレス）。ただし、CESが橋である場合、各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）内のS-VLAN（またはサービスインスタンス）のMACアドレス学習を無効にする必要があります。そのような場合、そのサービスインスタンスのPEを通るパスが修正されているため、そのPEで顧客Macアドレスを学習する必要はありません。たとえば、サービスインスタンスが4つの異なるサイトで4つのCEに関連付けられている場合、その顧客MACアドレス学習に参加する必要があるプロバイダーブリッジ（またはPE）の最大数は3つしかありません。そのサービスインスタンスのパス。このメカニズムは、QINQアクセス構成を備えた階層VPL（H-VPL）で学習した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アドレスを学習する必要があるサブツリーのノードの数（PE）をさらに制限できます。
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は、QINQアクセスを備えたH-VPLSのプロバイダーネットワーク内で学習したMACアドレスの数と、MPLSアクセスを備えたH-VPLSを大幅に削減できます。
[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]で指定されているプロバイダーブリッジは、顧客ブリッジでシームレスに操作し、必要なサービスを提供することを目的としています。したがって、[802.1AD]ブリッジモジュールを含む図1および2に基づいてPEがモデル化されている場合、このドキュメントで説明した問題が考慮されていることを考えると、プロバイダーブリッジでシームレスに動作するはずです。
The authors would like to thank Norm Finn and Samer Salam for their comments and valuable feedback.
著者は、コメントと貴重なフィードバックについて、Norm FinnとSamer Salamに感謝したいと思います。
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との間の通信を保護することが望ましい場合があります。[802.1AD]ブリッジモジュールを含むようにPEがモデル化されている場合、これは[802.1AX]のセクション7.7.2で説明されているように、顧客ブリッジとVPLS PEのS-VLANコンポーネントの間でMACセキュリティを実行することで実現できます。。
- 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]と[802.1AX]のプロバイダーエッジブリッジのS-VLANコンポーネント間の手順と付着したものの間の2つのネットワーク間でNNIを保護することができます。[802.1AD]ブリッジモジュールを含むようにPEがモデル化されている限り、VPLS PE。
[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月。
[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.、ed。、およびV. Kompella、ed。、「ラベル分布プロトコル（LDP）シグナル伝達を使用した仮想プライベートLANサービス（VPL）、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] Shah、H.、Rosen、E.、Le Faucheur、F。、およびG. Heron、「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] Martini、L.、Ed。、Rosen、E.、El-Aawar、N。、およびG. Heron、「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] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチの考慮事項」、RFC 4541、2006年5月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L.、ed。、およびE. Rosen、ed。、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、RFC 4664、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] Augustyn、W.、ed。、およびY. Serbest、ed。、「レイヤー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.、ed。、およびD. Mohan、ed。、「レイヤー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.1T-2001およびIEEE 802.1Wを組み込んでいます）」。
[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
Ali Sajassi（編集者）Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134メール：sajassi@cisco.com
Frank Brockners Cisco Systems, Inc. Hansaallee 249 40549 Duesseldorf Germany EMail: fbrockne@cisco.com
Frank Brockners Cisco Systems、Inc。Hansaallee 249 40549 Duesseldorfドイツメール：fbrockne@cisco.com
Dinesh Mohan (editor) Nortel Ottawa, ON K2K3E5 EMail: dinmohan@hotmail.com
Dinesh Mohan（編集者）Nortel Ottawa、on 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 Arboretum Blvd.テキサス州オースティン78759メール：YetIK_Serbest@labs.att.com