[要約] RFC 4762は、ラベル配布プロトコル（LDP）シグナリングを使用した仮想プライベートLANサービス（VPLS）に関する規格です。このRFCの目的は、異なる地理的な場所にあるLANセグメントを仮想的に接続するためのプロトコルを提供することです。
Network Working Group M. Lasserre, Ed.
Request for Comments: 4762 V. Kompella, Ed.
Category: Standards Track Alcatel-Lucent
January 2007
Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling
ラベル分布プロトコル（LDP）シグナル伝達を使用した仮想プライベートLANサービス（VPLS）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
IESG Note
IESGノート
The L2VPN Working Group produced two separate documents, RFC 4761 and this document, that perform similar functions using different signaling protocols. Be aware that each method is commonly referred to as "VPLS" even though they are distinct and incompatible with one another.
L2VPNワーキンググループは、異なるシグナル伝達プロトコルを使用して同様の機能を実行する2つの個別のドキュメント、RFC 4761とこのドキュメントを作成しました。それぞれの方法は、互いに明確で互換性がなくても、一般に「VPL」と呼ばれることに注意してください。
Abstract
概要
This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.
このドキュメントでは、Pseudowiresを使用した仮想プライベートLANサービス（VPLS）ソリューションについて説明します。これは、他のトンネル技術を介して以前に実装され、透明なLANサービス（TLS）として知られているサービスです。VPLSは、特定のユーザーセットに対してエミュレートされたLANセグメントを作成します。つまり、イーサネットMACアドレスを学習および転送できるレイヤー2ブロードキャストドメインを作成します。複数のVPLSサービスは、単一のプロバイダーエッジ（PE）ノードからサポートできます。
This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448.
このドキュメントでは、RFC 4447を拡張するラベル分布プロトコル（LDP）を使用して、シグナル伝達擬似動物ラベルのコントロールプレーン機能について説明します。これは、発見プロトコルにとって不可知論です。特にMACアドレスの学習に焦点を当てた、転送のデータプレーン機能も説明されています。VPLSパケットのカプセル化は、RFC 4448で説明されています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Conventions ................................................4
3. Acronyms ........................................................4
4. Topological Model for VPLS ......................................5
4.1. Flooding and Forwarding ....................................6
4.2. Address Learning ...........................................6
4.3. Tunnel Topology ............................................7
4.4. Loop free VPLS .............................................7
5. Discovery .......................................................7
6. Control Plane ...................................................7
6.1. LDP-Based Signaling of Demultiplexers ......................8
6.1.1. Using the Generalized PWid FEC Element ..............8
6.2. MAC Address Withdrawal .....................................9
6.2.1. MAC List TLV ........................................9
6.2.2. Address Withdraw Message Containing MAC List TLV ...11
7. Data Forwarding on an Ethernet PW ..............................11
7.1. VPLS Encapsulation Actions ................................11
7.2. VPLS Learning Actions .....................................12
8. Data Forwarding on an Ethernet VLAN PW .........................13
8.1. VPLS Encapsulation Actions ................................13
9. Operation of a VPLS ............................................14
9.1. MAC Address Aging .........................................15
10. A Hierarchical VPLS Model .....................................16
10.1. Hierarchical Connectivity ................................16
10.1.1. Spoke Connectivity for Bridging-Capable Devices ...17
10.1.2. Advantages of Spoke Connectivity ..................18
10.1.3. Spoke Connectivity for Non-Bridging Devices .......19
10.2. Redundant Spoke Connections ..............................21
10.2.1. Dual-Homed MTU-s ..................................21
10.2.2. Failure Detection and Recovery ....................22
10.3. Multi-domain VPLS Service ................................23
11. Hierarchical VPLS Model Using Ethernet Access Network .........23
11.1. Scalability ..............................................24
11.2. Dual Homing and Failure Recovery .........................24
12. Contributors ..................................................25
13. Acknowledgements ..............................................25
14. Security Considerations .......................................26
15. IANA Considerations ...........................................26
16. References ....................................................27
16.1. Normative References .....................................27
16.2. Informative References ...................................27
Appendix A. VPLS Signaling using the PWid FEC Element .............29
Ethernet has become the predominant technology for Local Area Network (LAN) connectivity and is gaining acceptance as an access technology, specifically in Metropolitan and Wide Area Networks (MAN and WAN, respectively). The primary motivation behind Virtual Private LAN Services (VPLS) is to provide connectivity between geographically dispersed customer sites across MANs and WANs, as if they were connected using a LAN. The intended application for the end-user can be divided into the following two categories:
イーサネットは、ローカルエリアネットワーク（LAN）接続の主要なテクノロジーとなり、特にメトロポリタンおよび広範囲のネットワーク（それぞれMan and Wan）でアクセス技術として受け入れられています。仮想プライベートLANサービス（VPLS）の背後にある主な動機は、まるでLANを使用して接続されているかのように、マンとワン全体の地理的に分散した顧客サイト間の接続を提供することです。エンドユーザーの意図したアプリケーションは、次の2つのカテゴリに分類できます。
- Connectivity between customer routers: LAN routing application
- 顧客ルーター間の接続：LANルーティングアプリケーション
- Connectivity between customer Ethernet switches: LAN switching application
- 顧客イーサネットスイッチ間の接続：LANスイッチングアプリケーション
Broadcast and multicast services are available over traditional LANs. Sites that belong to the same broadcast domain and that are connected via an MPLS network expect broadcast, multicast, and unicast traffic to be forwarded to the proper location(s). This requires MAC address learning/aging on a per-pseudowire basis, and packet replication across pseudowires for multicast/broadcast traffic and for flooding of unknown unicast destination traffic.
ブロードキャストおよびマルチキャストサービスは、従来のLANで利用できます。同じブロードキャストドメインに属し、MPLSネットワークを介して接続されているサイトは、放送、マルチキャスト、ユニキャストトラフィックが適切な場所に転送されることを期待しています。これには、MACのアドレス学習/老化ごとに、マルチキャスト/ブロードキャストトラフィックと不明なユニキャスト宛先トラフィックの洪水のために、擬似動物全体のパケットレプリケーションが必要です。
[RFC4448] defines how to carry Layer 2 (L2) frames over point-to-point pseudowires (PW). This document describes extensions to [RFC4447] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic across multiple sites that belong to the same L2 broadcast domain or VPLS. Note that the same model can be applied to other 802.1 technologies. It describes a simple and scalable way to offer Virtual LAN services, including the appropriate flooding of broadcast, multicast, and unknown unicast destination traffic over MPLS, without the need for address resolution servers or other external servers, as discussed in [L2VPN-REQ].
[RFC4448]は、ポイントツーポイントの擬似動物（PW）でレイヤー2（L2）フレームを運ぶ方法を定義します。このドキュメントでは、同じL2ブロードキャストドメインまたはVPLに属する複数のサイトにわたってイーサネット/802.3およびVLAN [802.1Q]トラフィックを輸送するための[RFC447]の拡張を説明しています。同じモデルを他の802.1テクノロジーに適用できることに注意してください。[L2VPN-REQ]で説明されているように、アドレス解像度サーバーまたはその他の外部サーバーを必要とすることなく、放送、マルチキャスト、および未知のユニキャスト宛先トラフィックの適切な洪水、MPLS上の不明なユニキャスト宛先トラフィックを含む、仮想LANサービスを提供するシンプルでスケーラブルな方法を説明しています。。
The following discussion applies to devices that are VPLS capable and have a means of tunneling labeled packets amongst each other. The resulting set of interconnected devices forms a private MPLS VPN.
以下の議論は、VPLS対応のデバイスに適用され、互いにラベル付けされたパケットとトンネリングの手段があります。結果の相互接続されたデバイスのセットは、プライベートMPLS VPNを形成します。
Q-in-Q 802.1ad Provider Bridge extensions also known as stackable VLANs or Q-in-Q.
Q-in-q 802.1ADプロバイダーブリッジ拡張は、積み重ね可能なVLANまたはQ-in-Qとも呼ばれます。
Qualified learning Learning mode in which each customer VLAN is mapped to its own VPLS instance.
各顧客VLANが独自のVPLSインスタンスにマッピングされる資格のある学習モード。
Service delimiter Information used to identify a specific customer service instance. This is typically encoded in the encapsulation header of customer frames (e.g., VLAN Id).
特定のカスタマーサービスインスタンスを特定するために使用されるサービスデリミター情報。これは通常、顧客フレームのカプセル化ヘッダー（例：VLAN ID）にエンコードされます。
Tagged frame Frame with an 802.1Q VLAN identifier.
802.1Q VLAN識別子を備えたタグ付きフレームフレーム。
Unqualified learning Learning mode where all the VLANs of a single customer are mapped to a single VPLS.
単一の顧客のすべてのVLANが単一のVPLにマッピングされる資格のない学習学習モード。
Untagged frame Frame without an 802.1Q VLAN identifier.
802.1Q VLAN識別子を備えた未編成フレームフレーム。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
AC Attachment Circuit
BPDU Bridge Protocol Data Unit
BPDUブリッジプロトコルデータユニット
CE Customer Edge device
CEカスタマーエッジデバイス
FEC Forwarding Equivalence Class
FEC転送等価クラス
FIB Forwarding Information Base
FIB転送情報ベース
GRE Generic Routing Encapsulation
GREジェネリックルーティングカプセル化
IPsec IP security
IPSEC IPセキュリティ
L2TP Layer Two Tunneling Protocol
L2TPレイヤー2つのトンネルプロトコル
LAN Local Area Network
LANローカルエリアネットワーク
LDP Label Distribution Protocol
MTU-s Multi-Tenant Unit switch
MTU-Sマルチテナントユニットスイッチ
PE Provider Edge device
PEプロバイダーエッジデバイス
PW Pseudowire
PW Pseudowire
STP Spanning Tree Protocol
VLAN Virtual LAN
VLAN tag VLAN Identifier
An interface participating in a VPLS must be able to flood, forward, and filter Ethernet frames. Figure 1, below, shows the topological model of a VPLS. The set of PE devices interconnected via PWs appears as a single emulated LAN to customer X. Each PE will form remote MAC address to PW associations and associate directly attached MAC addresses to local customer facing ports. This is modeled on standard IEEE 802.1 MAC address learning.
VPLSに参加するインターフェイスは、イーサネットフレームを洪水、前進、フィルタリングできる必要があります。以下の図1は、VPLSのトポロジモデルを示しています。PWSを介して相互接続されたPEデバイスのセットは、顧客Xに単一のエミュレートされたLANとして表示されます。各PEは、リモートMACアドレスをPWアソシエーションに形成し、直接接続されたMacアドレスをローカルカスタマーに向けたポートに関連付けます。これは、標準のIEEE 802.1 Macアドレス学習でモデル化されています。
+-----+ +-----+
| CE1 +---+ ........................... +---| CE2 |
+-----+ | . . | +-----+
Site 1 | +----+ +----+ | Site 2
+---| PE | Cloud | PE |---+
+----+ +----+
. .
. +----+ .
..........| PE |...........
+----+ ^
| |
| +-- Emulated LAN
+-----+
| CE3 |
+-----+
Site 3
Figure 1: Topological Model of a VPLS for Customer X with three sites
図1：3つのサイトを持つ顧客XのVPLのトポロジモデル
We note here again that while this document shows specific examples using MPLS transport tunnels, other tunnels that can be used by PWs (as mentioned in [RFC4447]) -- e.g., GRE, L2TP, IPsec -- can also be used, as long as the originating PE can be identified, since this is used in the MAC learning process.
The scope of the VPLS lies within the PEs in the service provider network, highlighting the fact that apart from customer service delineation, the form of access to a customer site is not relevant to the VPLS [L2VPN-REQ]. In other words, the attachment circuit (AC) connected to the customer could be a physical Ethernet port, a logical (tagged) Ethernet port, an ATM PVC carrying Ethernet frames, etc., or even an Ethernet PW.
VPLSの範囲は、サービスプロバイダーネットワークのPES内にあり、顧客サービスの描写とは別に、顧客サイトへのアクセスの形式がVPLS [L2VPN-REQ]には関係がないという事実を強調しています。言い換えれば、顧客に接続されたアタッチメント回路（AC）は、物理イーサネットポート、論理（タグ付き）イーサネットポート、イーサネットフレームなどを運ぶATM PVC、またはイーサネットPWでさえあります。
The PE is typically an edge router capable of running the LDP signaling protocol and/or routing protocols to set up PWs. In addition, it is capable of setting up transport tunnels to other PEs and delivering traffic over PWs.
PEは通常、LDPシグナリングプロトコルおよび/またはルーティングプロトコルを実行してPWSをセットアップできるエッジルーターです。さらに、輸送トンネルを他のPESにセットアップし、PWSを介してトラフィックを配信することができます。
One of attributes of an Ethernet service is that frames sent to broadcast addresses and to unknown destination MAC addresses are flooded to all ports. To achieve flooding within the service provider network, all unknown unicast, broadcast and multicast frames are flooded over the corresponding PWs to all PE nodes participating in the VPLS, as well as to all ACs.
イーサネットサービスの属性の1つは、ブロードキャストアドレスと未知の宛先MACアドレスに送信されたフレームがすべてのポートにあふれていることです。サービスプロバイダーネットワーク内で洪水を達成するために、すべての未知のユニキャスト、放送、マルチキャストフレームが、VPLSに参加するすべてのPEノードとすべてのACSに、対応するPWSに浸水します。
Note that multicast frames are a special case and do not necessarily have to be sent to all VPN members. For simplicity, the default approach of broadcasting multicast frames is used.
マルチキャストフレームは特別なケースであり、必ずしもすべてのVPNメンバーに送信する必要はないことに注意してください。簡単にするために、ブロードキャストマルチキャストフレームのデフォルトアプローチが使用されます。
To forward a frame, a PE MUST be able to associate a destination MAC address with a PW. It is unreasonable and perhaps impossible to require that PEs statically configure an association of every possible destination MAC address with a PW. Therefore, VPLS-capable PEs SHOULD have the capability to dynamically learn MAC addresses on both ACs and PWs and to forward and replicate packets across both ACs and PWs.
Unlike BGP VPNs [RFC4364], reachability information is not advertised and distributed via a control plane. Reachability is obtained by standard learning bridge functions in the data plane.
BGP VPNS [RFC4364]とは異なり、到達可能性情報は宣伝されていません。到達可能性は、データプレーンの標準学習ブリッジ関数によって得られます。
When a packet arrives on a PW, if the source MAC address is unknown, it needs to be associated with the PW, so that outbound packets to that MAC address can be delivered over the associated PW. Likewise, when a packet arrives on an AC, if the source MAC address is unknown, it needs to be associated with the AC, so that outbound packets to that MAC address can be delivered over the associated AC.
パケットがPWに到着すると、ソースMACアドレスが不明な場合は、PWに関連付けられる必要があるため、そのMacアドレスへのアウトバウンドパケットは関連するPWで配信できます。同様に、パケットがACに到着すると、ソースMACアドレスが不明な場合は、ACに関連付けられる必要があるため、そのMACアドレスへのアウトバウンドパケットを関連するACで配信できます。
Standard learning, filtering, and forwarding actions, as defined in [802.1D-ORIG], [802.1D-REV], and [802.1Q], are required when a PW or AC state changes.
[802.1D-Orig]、[802.1D-REV]、および[802.1Q]で定義されている標準学習、フィルタリング、および転送アクションが、PWまたはAC状態が変化するときに必要です。
PE routers are assumed to have the capability to establish transport tunnels. Tunnels are set up between PEs to aggregate traffic. PWs are signaled to demultiplex encapsulated Ethernet frames from multiple VPLS instances that traverse the transport tunnels.
PEルーターは、輸送トンネルを確立する能力があると想定されています。トンネルは、トラフィックを集約するためにPEの間に設置されています。PWは、輸送トンネルを横断する複数のVPLSインスタンスからカプセル化されたイーサネットフレームの反乱に合図されます。
In an Ethernet L2VPN, it becomes the responsibility of the service provider to create the loop-free topology. For the sake of simplicity, we define that the topology of a VPLS is a full mesh of PWs.
If the topology of the VPLS is not restricted to a full mesh, then it may be that for two PEs not directly connected via PWs, they would have to use an intermediary PE to relay packets. This topology would require the use of some loop-breaking protocol, like a spanning tree protocol.
VPLSのトポロジーがフルメッシュに限定されていない場合、PWSを介して直接接続されていない2つのPEの場合、中間PEを使用してパケットを中継する必要がある可能性があります。このトポロジは、スパニングツリープロトコルのように、ループブレイクプロトコルを使用する必要があります。
Instead, a full mesh of PWs is established between PEs. Since every PE is now directly connected to every other PE in the VPLS via a PW, there is no longer any need to relay packets, and we can instantiate a simpler loop-breaking rule: the "split horizon" rule, whereby a PE MUST NOT forward traffic from one PW to another in the same VPLS mesh.
代わりに、PEの間にPWSの完全なメッシュが確立されます。すべてのPEがPWを介してVPLの他のすべてのPEに直接接続されているため、パケットを中継する必要はなくなり、よりシンプルなループブレークルールをインスタンス化できます。同じVPLSメッシュで、あるPWから別のPWにトラフィックを転送しないでください。
Note that customers are allowed to run a Spanning Tree Protocol (STP) (e.g., as defined in [802.1D-REV]), such as when a customer has "back door" links used to provide redundancy in the case of a failure within the VPLS. In such a case, STP Bridge PDUs (BPDUs) are simply tunneled through the provider cloud.
顧客はスパニングツリープロトコル（STP）（例えば、[802.1D-REV]で定義されているように）を実行することが許可されていることに注意してください。VPL。このような場合、STPブリッジPDU（BPDUS）は、プロバイダークラウドに単純にトンネルを貼っています。
The capability to manually configure the addresses of the remote PEs is REQUIRED. However, the use of manual configuration is not necessary if an auto-discovery procedure is used. A number of auto-discovery procedures are compatible with this document ([RADIUS-DISC], [BGP-DISC]).
リモートPEのアドレスを手動で構成する機能が必要です。ただし、自動発見手順を使用する場合、手動構成の使用は必要ありません。多くの自動発見手順は、このドキュメント（[RADIUS-DISC]、[BGP-DISC]）と互換性があります。
This document describes the control plane functions of signaling of PW labels. Some foundational work in the area of support for multi-homing is laid. The extensions to provide multi-homing support should work independently of the basic VPLS operation, and they are not described here.
このドキュメントでは、PWラベルのシグナル伝達の制御プレーン機能について説明します。マルチホーミングのサポートの分野での基本的な研究が提起されています。マルチホームサポートを提供するための拡張機能は、基本的なVPLS操作とは無関係に機能する必要があり、ここでは説明されていません。
A full mesh of LDP sessions is used to establish the mesh of PWs. The requirement for a full mesh of PWs may result in a large number of targeted LDP sessions. Section 10 discusses the option of setting up hierarchical topologies in order to minimize the size of the VPLS full mesh.
LDPセッションの完全なメッシュを使用して、PWSのメッシュを確立します。PWSの完全なメッシュの要件により、多数のターゲットLDPセッションが発生する可能性があります。セクション10では、VPLSフルメッシュのサイズを最小限に抑えるために、階層トポロジをセットアップするオプションについて説明します。
Once an LDP session has been formed between two PEs, all PWs between these two PEs are signaled over this session.
2つのPEの間にLDPセッションが形成されると、これら2つのPEの間のすべてのPWがこのセッションでシグナルが表示されます。
In [RFC4447], two types of FECs are described: the PWid FEC Element (FEC type 128) and the Generalized PWid FEC Element (FEC type 129). The original FEC element used for VPLS was compatible with the PWid FEC Element. The text for signaling using the PWid FEC Element has been moved to Appendix A. What we describe below replaces that with a more generalized L2VPN descriptor, the Generalized PWid FEC Element.
[RFC4447]では、PWID FEC要素（FECタイプ128）と一般化されたPWID FEC要素（FECタイプ129）の2つのタイプのFECが記載されています。VPLSに使用される元のFEC要素は、PWID FEC要素と互換性がありました。PWID FEC要素を使用したシグナリングのテキストは付録Aに移動されました。以下で説明するものは、一般化されたL2VPN記述子である一般化されたPWID FEC要素に置き換えられます。
[RFC4447] describes a generalized FEC structure that is be used for VPLS signaling in the following manner. We describe the assignment of the Generalized PWid FEC Element fields in the context of VPLS signaling.
[RFC4447]は、次の方法でVPLSシグナル伝達に使用される一般化されたFEC構造を説明しています。VPLSシグナル伝達のコンテキストにおける一般化されたPWID FEC要素フィールドの割り当てについて説明します。
Control bit (C): This bit is used to signal the use of the control word as specified in [RFC4447].
コントロールビット（c）：このビットは、[RFC4447]で指定されているように、コントロールワードの使用を知らせるために使用されます。
PW type: The allowed PW types are Ethernet (0x0005) and Ethernet tagged mode (0x004), as specified in [RFC4446].
PWタイプ：許可されたPWタイプは、[RFC4446]で指定されているように、イーサネット（0x0005）とイーサネットタグモード（0x004）です。
PW info length: As specified in [RFC4447].
PW情報の長さ：[RFC4447]で指定されています。
Attachment Group Identifier (AGI), Length, Value: The unique name of this VPLS. The AGI identifies a type of name, and Length denotes the length of Value, which is the name of the VPLS. We use the term AGI interchangeably with VPLS identifier.
アタッチメントグループ識別子（AGI）、長さ、値：このVPLの一意の名前。AGIは名前のタイプを識別し、長さはVPLの名前である値の長さを示します。AGIという用語は、VPLS識別子と交換可能に使用します。
Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null because the mesh of PWs in a VPLS terminates on MAC learning tables, rather than on individual attachment circuits. The use of non-null TAII and SAII is reserved for future enhancements.
ターゲットアタッチメント個体識別子（TAII）、ソースアタッチメント個体識別子（SAII）：これらは、VPLSのPWSのメッシュが個々のアタッチメントサーキットではなく、MAC学習テーブルで終了するため、ヌルです。非ヌルTAIIおよびSAIIの使用は、将来の強化のために予約されています。
Interface Parameters: The relevant interface parameters are:
インターフェイスパラメーター：関連するインターフェイスパラメーターは次のとおりです。
- MTU: The MTU (Maximum Transmission Unit) of the VPLS MUST be the same across all the PWs in the mesh.
- MTU：VPLSのMTU（最大透過ユニット）は、メッシュ内のすべてのPWで同じでなければなりません。
- Optional Description String: Same as [RFC4447].
- オプションの説明文字列：[RFC4447]と同じ。
- Requested VLAN ID: If the PW type is Ethernet tagged mode, this parameter may be used to signal the insertion of the appropriate VLAN ID, as defined in [RFC4448].
- 要求されたVLAN ID：PWタイプがイーサネットタグ付きモードの場合、このパラメーターを使用して[RFC4448]で定義されている適切なVLAN IDの挿入を信号することができます。
It MAY be desirable to remove or unlearn MAC addresses that have been dynamically learned for faster convergence. This is accomplished by sending an LDP Address Withdraw Message with the list of MAC addresses to be removed to all other PEs over the corresponding LDP sessions.
より速い収束のために動的に学習されたMACアドレスを削除または削除または削除することが望ましい場合があります。これは、対応するLDPセッションで他のすべてのPEに削除されるMACアドレスのリストを使用してLDPアドレスの撤回メッセージを送信することによって達成されます。
We introduce an optional MAC List TLV in LDP to specify a list of MAC addresses that can be removed or unlearned using the LDP Address Withdraw Message.
LDPにオプションのMACリストTLVを導入して、LDPアドレスの引き出しメッセージを使用して削除または学習できないMacアドレスのリストを指定します。
The Address Withdraw message with MAC List TLVs MAY be supported in order to expedite removal of MAC addresses as the result of a topology change (e.g., failure of the primary link for a dual-homed VPLS-capable switch).
トポロジの変更の結果としてMACアドレスの削除を促進するために、MACリストTLVを使用したアドレス撤回メッセージがサポートされる場合があります（たとえば、デュアルホームのVPLS対応スイッチのプライマリリンクの障害）。
In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list.
LDP収束時間への影響を最小限に抑えるために、MacリストTLVに多数のMACアドレスが含まれている場合、空のリストでMACアドレスの引き出しメッセージを送信することが望ましい場合があります。
MAC addresses to be unlearned can be signaled using an LDP Address Withdraw Message that contains a new TLV, the MAC List TLV. Its format is described below. The encoding of a MAC List TLV address is the 6-octet MAC address specified by IEEE 802 documents [802.1D-ORIG] [802.1D-REV].
未学習のMACアドレスは、新しいTLV、MACリストTLVを含むLDPアドレス撤回メッセージを使用してシグナルを受けることができます。その形式については、以下に説明します。MACリストTLVアドレスのエンコードは、IEEE 802ドキュメント[802.1D-Orig] [802.1D-REV]で指定された6オクタートMACアドレスです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | MAC Address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit: Unknown bit. This bit MUST be set to 1. If the MAC address format is not understood, then the TLV is not understood and MUST be ignored.
uビット：不明ビット。このビットは1に設定する必要があります。MACアドレス形式が理解されていない場合、TLVは理解されず、無視する必要があります。
F bit: Forward bit. This bit MUST be set to 0. Since the LDP mechanism used here is targeted, the TLV MUST NOT be forwarded.
fビット：フォワードビット。このビットは0に設定する必要があります。ここで使用されるLDPメカニズムはターゲットになるため、TLVを転送してはなりません。
Type: Type field. This field MUST be set to 0x0404. This identifies the TLV type as MAC List TLV.
タイプ：タイプフィールド。このフィールドは0x0404に設定する必要があります。これにより、TLVタイプがMACリストTLVとして識別されます。
Length: Length field. This field specifies the total length in octets of the MAC addresses in the TLV. The length MUST be a multiple of 6.
長さ：長さフィールド。このフィールドは、TLVのMACアドレスのオクテットの全長を指定します。長さは6の倍数でなければなりません。
MAC Address: The MAC address(es) being removed.
Macアドレス：削除されているMacアドレス（es）。
The MAC Address Withdraw Message contains a FEC TLV (to identify the VPLS affected), a MAC Address TLV, and optional parameters. No optional parameters have been defined for the MAC Address Withdraw signaling. Note that if a PE receives a MAC Address Withdraw Message and does not understand it, it MUST ignore the message. In this case, instead of flushing its MAC address table, it will continue to use stale information, unless:
MACアドレスの撤回メッセージには、FEC TLV（影響を受けるVPLSを識別するため）、MACアドレスTLV、およびオプションのパラメーターが含まれています。MACアドレスの撤回シグナリングについては、オプションのパラメーターは定義されていません。PEがMACアドレスを受信してメッセージを削除し、それを理解していない場合、メッセージを無視する必要があることに注意してください。この場合、MACアドレステーブルをフラッシュする代わりに、以下を除いて、古い情報を使用し続けます。
- it receives a packet with a known MAC address association, but from a different PW, in which case it replaces the old association; or
- 既知のMACアドレスアソシエーションを持つパケットを受け取りますが、異なるPWからは、古い関連付けに取って代わります。また
- it ages out the old association.
- それは古い協会を老化させます。
The MAC Address Withdraw message only helps speed up convergence, so PEs that do not understand the message can continue to participate in the VPLS.
MACアドレスの撤回メッセージは、収束をスピードアップするのに役立つため、メッセージがVPLSに参加し続けることができることを理解していないPES。
The processing for MAC List TLV received in an Address Withdraw Message is:
アドレス撤回メッセージで受信したMacリストTLVの処理は次のとおりです。
For each MAC address in the TLV:
TLVの各Macアドレスについて：
- Remove the association between the MAC address and the AC or PW over which this message is received.
- MACアドレスと、このメッセージが受信されるACまたはPWの間の関連性を削除します。
For a MAC Address Withdraw message with empty list:
MACアドレスの場合、空のリストでメッセージを引き出します：
- Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received.
- VPLSインスタンスに関連付けられたすべてのMACアドレス（FEC TLVで指定）を削除します。
The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV.
MACリストTLVの範囲は、MACアドレスの撤回メッセージのFEC TLVで指定されたVPLSです。MACアドレスの数は、TLVの長さフィールドから推定できます。
This section describes the data plane behavior on an Ethernet PW used in a VPLS. While the encapsulation is similar to that described in [RFC4448], the functions of stripping the service-delimiting tag and using a "normalized" Ethernet frame are described.
このセクションでは、VPLSで使用されるイーサネットPWのデータプレーンの動作について説明します。カプセル化は[RFC4448]に記載されているものと似ていますが、サービスを削除するタグを削除し、「正規化された」イーサネットフレームを使用する機能について説明します。
In a VPLS, a customer Ethernet frame without preamble is encapsulated with a header as defined in [RFC4448]. A customer Ethernet frame is defined as follows:
VPLSでは、プリアンブルのない顧客イーサネットフレームは、[RFC4448]で定義されているヘッダーでカプセル化されます。顧客イーサネットフレームは次のように定義されます。
- If the frame, as it arrives at the PE, has an encapsulation that is used by the local PE as a service delimiter, i.e., to identify the customer and/or the particular service of that customer, then that encapsulation may be stripped before the frame is sent into the VPLS. As the frame exits the VPLS, the frame may have a service-delimiting encapsulation inserted.
- フレームは、PEに到達するときに、ローカルPEがサービスデリミタとして使用するカプセル化、つまり顧客および/またはその顧客の特定のサービスを識別する場合、そのカプセル化は前に削除される場合があります。フレームはVPLSに送信されます。フレームがVPLSを終了すると、フレームにはサービスを削除するカプセル化が挿入されている場合があります。
- If the frame, as it arrives at the PE, has an encapsulation that is not service delimiting, then it is a customer frame whose encapsulation should not be modified by the VPLS. This covers, for example, a frame that carries customer-specific VLAN tags that the service provider neither knows about nor wants to modify.
- フレームがPEに到達するときに、サービスの削除ではないカプセル化がある場合、それはVPLによってカプセル化を変更すべきではない顧客フレームです。これは、たとえば、サービスプロバイダーが変更したり変更したりしたくない顧客固有のVLANタグを搭載するフレームをカバーしています。
As an application of these rules, a customer frame may arrive at a customer-facing port with a VLAN tag that identifies the customer's VPLS instance. That tag would be stripped before it is encapsulated in the VPLS. At egress, the frame may be tagged again, if a service-delimiting tag is used, or it may be untagged if none is used.
これらのルールの適用として、顧客フレームは、顧客のVPLSインスタンスを識別するVLANタグを備えた顧客向けポートに到着する場合があります。そのタグは、VPLSにカプセル化される前に剥がされます。出口では、サービスを削除するタグが使用されている場合、フレームに再びタグ付けされる場合があります。または、使用されていない場合は、タグを付けていない場合があります。
Likewise, if a customer frame arrives at a customer-facing port over an ATM or Frame Relay VC that identifies the customer's VPLS instance, then the ATM or FR encapsulation is removed before the frame is passed into the VPLS.
同様に、顧客フレームが顧客のVPLSインスタンスを識別するATMまたはフレームリレーVCを介して顧客向けポートに到着すると、フレームがVPLSに渡される前にATMまたはFRカプセル化が削除されます。
Contrariwise, if a customer frame arrives at a customer-facing port with a VLAN tag that identifies a VLAN domain in the customer L2 network, then the tag is not modified or stripped, as it belongs with the rest of the customer frame.
反対に、顧客フレームが顧客L2ネットワークでVLANドメインを識別するVLANタグを備えた顧客向けポートに到着すると、タグは他の顧客フレームに属するため、変更または剥がされません。
By following the above rules, the Ethernet frame that traverses a VPLS is always a customer Ethernet frame. Note that the two actions, at ingress and egress, of dealing with service delimiters are local actions that neither PE has to signal to the other. They allow, for example, a mix-and-match of VLAN tagged and untagged services at either end, and they do not carry across a VPLS a VLAN tag that has local significance only. The service delimiter may be an MPLS label also, whereby an Ethernet PW given by [RFC4448] can serve as the access side connection into a PE. An RFC1483 Bridged PVC encapsulation could also serve as a service delimiter. By limiting the scope of locally significant encapsulations to the edge, hierarchical VPLS models can be developed that provide the capability to network-engineer scalable VPLS deployments, as described below.
上記のルールに従うことにより、VPLSを通過するイーサネットフレームは常に顧客イーサネットフレームです。Service Delimitersを扱う2つのアクションは、PEも他のPEに通じなければならないローカルアクションであることに注意してください。たとえば、どちらの端にタグ付けされたVLANと未編成のvlanの混合と試合が許可されており、VPLSに局所的な重要性のみを持つVLANタグを運びません。サービス区切り文字もMPLSラベルである場合があります。これにより、[RFC448]によって与えられたイーサネットPWは、PEへのアクセス側の接続として機能します。RFC1483ブリッジされたPVCカプセル化は、サービス区切り文字としても機能する可能性があります。局所的に重要なカプセルの範囲をエッジに制限することにより、以下で説明するように、ネットワークエンジニアのスケーラブルなVPLS展開に機能を提供する階層VPLSモデルを開発できます。
Learning is done based on the customer Ethernet frame as defined above. The Forwarding Information Base (FIB) keeps track of the mapping of customer Ethernet frame addressing and the appropriate PW to use. We define two modes of learning: qualified and unqualified learning. Qualified learning is the default mode and MUST be supported. Support of unqualified learning is OPTIONAL.
学習は、上記で定義されている顧客イーサネットフレームに基づいて行われます。転送情報ベース（FIB）は、顧客イーサネットフレームアドレス指定と使用する適切なPWのマッピングを追跡します。学習の2つのモードを定義します。資格のない資格のない学習です。資格のある学習はデフォルトモードであり、サポートする必要があります。資格のない学習のサポートはオプションです。
In unqualified learning, all the VLANs of a single customer are handled by a single VPLS, which means they all share a single broadcast domain and a single MAC address space. This means that MAC addresses need to be unique and non-overlapping among customer VLANs, or else they cannot be differentiated within the VPLS instance, and this can result in loss of customer frames. An application of unqualified learning is port-based VPLS service for a given customer (e.g., customer with non-multiplexed AC where all the traffic on a physical port, which may include multiple customer VLANs, is mapped to a single VPLS instance).
資格のない学習では、単一の顧客のすべてのVLANが単一のVPLSによって処理されます。つまり、すべてが単一のブロードキャストドメインと単一のMacアドレススペースを共有しています。これは、Macアドレスが顧客VLANの間でユニークで非重複する必要があることを意味します。そうしないと、VPLSインスタンス内で区別することができず、顧客フレームが失われる可能性があります。資格のない学習のアプリケーションは、特定の顧客向けのポートベースのVPLSサービスです（たとえば、複数の顧客VLANを含む可能性のある物理ポート上のすべてのトラフィックが単一のVPLSインスタンスにマッピングされている場合、非総体的なACを持つ顧客）。
In qualified learning, each customer VLAN is assigned to its own VPLS instance, which means each customer VLAN has its own broadcast domain and MAC address space. Therefore, in qualified learning, MAC addresses among customer VLANs may overlap with each other, but they will be handled correctly since each customer VLAN has its own FIB; i.e., each customer VLAN has its own MAC address space. Since VPLS broadcasts multicast frames by default, qualified learning offers the advantage of limiting the broadcast scope to a given customer VLAN. Qualified learning can result in large FIB table sizes, because the logical MAC address is now a VLAN tag + MAC address.
資格のある学習では、各顧客VLANは独自のVPLSインスタンスに割り当てられます。つまり、各顧客VLANには独自のブロードキャストドメインとMacアドレススペースがあります。したがって、資格のある学習では、顧客VLAN間のMACアドレスが互いに重複する場合がありますが、各顧客VLANには独自のFIBがあるため、正しく処理されます。つまり、各顧客VLANには独自のMACアドレススペースがあります。VPLSはデフォルトでマルチキャストフレームをブロードキャストしているため、適格な学習は、特定の顧客VLANにブロードキャスト範囲を制限するという利点を提供します。修飾学習は、論理MACアドレスがVLANタグMACアドレスになるため、大きなFIBテーブルサイズになる可能性があります。
For STP to work in qualified learning mode, a VPLS PE must be able to forward STP BPDUs over the proper VPLS instance. In a hierarchical VPLS case (see details in Section 10), service delimiting tags (Q-in-Q or [RFC4448]) can be added such that PEs can unambiguously identify all customer traffic, including STP BPDUs. In a basic VPLS case, upstream switches must insert such service delimiting tags. When an access port is shared among multiple customers, a reserved VLAN per customer domain must be used to carry STP traffic. The STP frames are encapsulated with a unique provider tag per customer (as the regular customer traffic), and a PEs looks up the provider tag to send such frames across the proper VPLS instance.
STPが資格のある学習モードで動作するには、VPLS PEが適切なVPLSインスタンスでSTP BPDUを転送できる必要があります。階層VPLSケース（セクション10の詳細を参照）では、STP BPDUを含むすべての顧客トラフィックをPESが明確に識別できるように、サービスを区切るタグ（Q-in-qまたは[rfc448]）を追加できます。基本的なVPLSの場合、アップストリームスイッチはタグを区切るようなサービスを挿入する必要があります。アクセスポートが複数の顧客間で共有される場合、STPトラフィックを運ぶために、顧客ごとのドメインごとの予約済みのVLANを使用する必要があります。STPフレームは、顧客ごとに一意のプロバイダータグ（通常の顧客トラフィックとして）でカプセル化されており、PESがプロバイダータグを調べて、適切なVPLSインスタンスにそのようなフレームを送信します。
This section describes the data plane behavior on an Ethernet VLAN PW in a VPLS. While the encapsulation is similar to that described in [RFC4448], the functions of imposing tags and using a "normalized" Ethernet frame are described. The learning behavior is the same as for Ethernet PWs.
このセクションでは、VPLSのイーサネットVLAN PWでのデータプレーンの動作について説明します。カプセル化は[RFC4448]で説明されているカプセルと類似していますが、タグを押し付け、「正規化された」イーサネットフレームを使用する機能が説明されています。学習行動は、イーサネットPWSと同じです。
In a VPLS, a customer Ethernet frame without preamble is encapsulated with a header as defined in [RFC4448]. A customer Ethernet frame is defined as follows:
VPLSでは、プリアンブルのない顧客イーサネットフレームは、[RFC4448]で定義されているヘッダーでカプセル化されます。顧客イーサネットフレームは次のように定義されます。
- If the frame, as it arrives at the PE, has an encapsulation that is part of the customer frame and is also used by the local PE as a service delimiter, i.e., to identify the customer and/or the particular service of that customer, then that encapsulation is preserved as the frame is sent into the VPLS, unless the Requested VLAN ID optional parameter was signaled. In that case, the VLAN tag is overwritten before the frame is sent out on the PW.
- フレームがPEに到達するときに、顧客フレームの一部であり、ローカルPEによってサービスデリミタとしても使用されるカプセル化、つまり、顧客および/またはその顧客の特定のサービスを識別するためにも使用されている場合、要求されたVLAN IDオプションパラメーターが信号が表示されない限り、フレームがVPLに送信されると、そのカプセル化が保存されます。その場合、フレームがPWで送信される前に、VLANタグが上書きされます。
- If the frame, as it arrives at the PE, has an encapsulation that does not have the required VLAN tag, a null tag is imposed if the Requested VLAN ID optional parameter was not signaled.
- フレームがPEに到着すると、必要なVLANタグがないカプセル化がある場合、要求されたVLAN IDオプションパラメーターが信号されていない場合、nullタグが課されます。
As an application of these rules, a customer frame may arrive at a customer-facing port with a VLAN tag that identifies the customer's VPLS instance and also identifies a customer VLAN. That tag would be preserved as it is encapsulated in the VPLS.
これらのルールの適用として、顧客フレームは、顧客のVPLSインスタンスを識別し、顧客VLANを識別するVLANタグを備えた顧客向けポートに到着する場合があります。そのタグは、VPLSにカプセル化されているため、保存されます。
The Ethernet VLAN PW provides a simple way to preserve customer 802.1p bits.
イーサネットVLAN PWは、顧客802.1pビットを保持する簡単な方法を提供します。
A VPLS MAY have both Ethernet and Ethernet VLAN PWs. However, if a PE is not able to support both PWs simultaneously, it SHOULD send a Label Release on the PW messages that it cannot support with a status code "Unknown FEC" as given in [RFC3036].
VPLには、イーサネットとイーサネットVLAN PWの両方がある場合があります。ただし、PEが両方のPWSを同時にサポートできない場合、[RFC3036]に与えられたステータスコード「不明なFEC」でサポートできないPWメッセージにラベルリリースを送信する必要があります。
We show here, in Figure 2, below, an example of how a VPLS works. The following discussion uses the figure below, where a VPLS has been set up between PE1, PE2, and PE3. The VPLS connects a customer with 4 sites labeled A1, A2, A3, and A4 through CE1, CE2, CE3, and CE4, respectively.
以下の図2に、VPLがどのように機能するかの例を示します。次の説明では、以下の図を使用しています。ここでは、PE1、PE2、およびPE3の間にVPLSが設定されています。VPLSは、それぞれCE1、CE2、CE3、およびCE4を介してA1、A2、A3、およびA4というラベルの付いた4つのサイトで顧客を接続します。
Initially, the VPLS is set up so that PE1, PE2, and PE3 have a full mesh of Ethernet PWs. The VPLS instance is assigned an identifier (AGI). For the above example, say PE1 signals PW label 102 to PE2 and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3.
最初に、VPLSがセットアップされているため、PE1、PE2、およびPE3がイーサネットPWの完全なメッシュを持つようになります。VPLSインスタンスには識別子（AGI）が割り当てられます。上記の例では、PE1はPWラベル102からPE2、103からPE3へ、PE2はPWラベル201からPE1および203からPE3を信号します。
-----
/ A1 \
---- ----CE1 |
/ \ -------- ------- / | |
| A2 CE2- / \ / PE1 \ /
\ / \ / \---/ \ -----
---- ---PE2 |
| Service Provider Network |
\ / \ /
----- PE3 / \ /
|Agg|_/ -------- -------
-| |
---- / ----- ----
/ \/ \ / \ CE = Customer Edge Router
| A3 CE3 -CE4 A4 | PE = Provider Edge Router
\ / \ / Agg = Layer 2 Aggregation
---- ----
Figure 2: Example of a VPLS
図2：VPLSの例
Assume a packet from A1 is bound for A2. When it leaves CE1, say it has a source MAC address of M1 and a destination MAC of M2. If PE1 does not know where M2 is, it will flood the packet; i.e., send it to PE2 and PE3. When PE2 receives the packet, it will have a PW label of 201. PE2 can conclude that the source MAC address M1 is behind PE1, since it distributed the label 201 to PE1. It can therefore associate MAC address M1 with PW label 102.
A1からのパケットがA2にバインドされていると仮定します。CE1を離れると、M1のソースMACアドレスとM2の宛先MACがあると言います。PE1がM2がどこにあるのかわからない場合、パケットにあふれます。つまり、PE2とPE3に送信します。PE2がパケットを受信すると、201のPWラベルがあります。PE2は、ソースMACアドレスM1がPE1の背後にあると結論付けることができます。したがって、MACアドレスM1をPWラベル102に関連付けることができます。
PEs that learn remote MAC addresses SHOULD have an aging mechanism to remove unused entries associated with a PW label. This is important both for conservation of memory and for administrative purposes. For example, if a customer site A, is shut down, eventually the other PEs should unlearn A's MAC address.
リモートMACアドレスを学習するPESには、PWラベルに関連付けられている未使用のエントリを削除する老化メカニズムが必要です。これは、記憶の保存と管理目的の両方にとって重要です。たとえば、顧客サイトAがシャットダウンされている場合、最終的に他のPESはAのMACアドレスを獲得する必要があります。
The aging timer for MAC address M SHOULD be reset when a packet with source MAC address M is received.
MACアドレスMの老化タイマーは、ソースMACアドレスMを備えたパケットを受信したときにリセットする必要があります。
The solution described above requires a full mesh of tunnel LSPs between all the PE routers that participate in the VPLS service. For each VPLS service, n*(n-1)/2 PWs must be set up between the PE routers. While this creates signaling overhead, the real detriment to large scale deployment is the packet replication requirements for each provisioned PWs on a PE router. Hierarchical connectivity, described in this document, reduces signaling and replication overhead to allow large-scale deployment.
上記のソリューションでは、VPLSサービスに参加するすべてのPEルーター間のトンネルLSPの完全なメッシュが必要です。各VPLSサービスについて、N*（N-1）/2 PWSをPEルーター間にセットアップする必要があります。これにより、シグナリングオーバーヘッドが作成されますが、大規模な展開に対する真の不利益は、PEルーター上の各プロビジョニングPWSのパケット複製要件です。このドキュメントで説明されている階層的な接続性は、シグナル伝達と複製オーバーヘッドを減らして、大規模な展開を可能にします。
In many cases, service providers place smaller edge devices in multi-tenant buildings and aggregate them into a PE in a large Central Office (CO) facility. In some instances, standard IEEE 802.1q (Dot 1Q) tagging techniques may be used to facilitate mapping CE interfaces to VPLS access circuits at a PE.
多くの場合、サービスプロバイダーはマルチテナントビルに小さなエッジデバイスを配置し、それらを大規模な中央オフィス（CO）施設のPEに集約します。場合によっては、標準のIEEE 802.1Q（DOT 1Q）タグ付け手法を使用して、PEでのVPLSアクセスサーキットへのCEインターフェイスのマッピングを容易にすることができます。
It is often beneficial to extend the VPLS service tunneling techniques into the access switch domain. This can be accomplished by treating the access device as a PE and provisioning PWs between it and every other edge, as a basic VPLS. An alternative is to utilize [RFC4448] PWs or Q-in-Q logical interfaces between the access device and selected VPLS enabled PE routers. Q-in-Q encapsulation is another form of L2 tunneling technique, which can be used in conjunction with MPLS signaling, as will be described later. The following two sections focus on this alternative approach. The VPLS core PWs (hub) are augmented with access PWs (spoke) to form a two-tier hierarchical VPLS (H-VPLS).
多くの場合、VPLSサービスのトンネルテクニックをアクセススイッチドメインに拡張することが有益です。これは、アクセスデバイスをPEとして扱い、基本的なVPLとして他のすべてのエッジとの間にPWSをプロビジョニングすることで実現できます。別の方法は、[RFC4448] PWSまたはQ-in-Qのアクセスデバイスと選択されたVPLS対応のPEルーター間の論理インターフェイスを利用することです。Q-in-Qカプセル化は、後で説明するように、MPLSシグナル伝達と組み合わせて使用できるL2トンネル技術の別の形式です。次の2つのセクションは、この代替アプローチに焦点を当てています。VPLSコアPW（ハブ）は、アクセスPWS（スポーク）で補強され、2層階層VPL（H-VPL）を形成します。
Spoke PWs may be implemented using any L2 tunneling mechanism, and by expanding the scope of the first tier to include non-bridging VPLS PE routers. The non-bridging PE router would extend a spoke PW from a Layer-2 switch that connects to it, through the service core network, to a bridging VPLS PE router supporting hub PWs. We also describe how VPLS-challenged nodes and low-end CEs without MPLS capabilities may participate in a hierarchical VPLS.
For rest of this discussion we refer to a bridging capable access device as MTU-s and a non-bridging capable PE as PE-r. We refer to a routing and bridging capable device as PE-rs.
この議論の残りの部分では、ブリッジング能力のあるアクセスデバイスをMTU-Sと、PE-Rとして非架橋能力PEと呼びます。ルーティングとブリッジング対応デバイスをPE-Rと呼びます。
This section describes the hub and spoke connectivity model and describes the requirements of the bridging capable and non-bridging MTU-s devices for supporting the spoke connections.
このセクションでは、ハブとスポークの接続モデルについて説明し、音声接続をサポートするためのブリッジング能力および非ブリッジングMTU-Sデバイスの要件について説明します。
In Figure 3, below, three customer sites are connected to an MTU-s through CE-1, CE-2, and CE-3. The MTU-s has a single connection (PW-1) to PE1-rs. The PE-rs devices are connected in a basic VPLS full mesh. For each VPLS service, a single spoke PW is set up between the MTU-s and the PE-rs based on [RFC4447]. Unlike traditional PWs that terminate on a physical (or a VLAN-tagged logical) port, a spoke PW terminates on a virtual switch instance (VSI; see [L2FRAME]) on the MTU-s and the PE-rs devices.
以下の図3では、3つの顧客サイトがCE-1、CE-2、およびCE-3を介してMTU-Sに接続されています。MTU-Sには、PE1-RSに対する単一の接続（PW-1）があります。PE-RSデバイスは、基本的なVPLSフルメッシュに接続されています。各VPLSサービスについて、[RFC4447]に基づいて、MTU-SとPE-RSの間に単一のスポークPWが設定されます。物理（またはVLANタグ付き論理）ポートで終了する従来のPWとは異なり、音声PWは、MTU-SおよびPE-RSデバイスの仮想スイッチインスタンス（VSI; [L2Frame]を参照）で終了します。
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ MTU-s PE1-rs / |
+--------+ +--------+ / |
| | | | / |
| -- | PW-1 | -- |---/ |
| / \--|- - - - - - - - - - - | / \ | |
| \S / | | \S / | |
| -- | | -- |---\ |
+--------+ +--------+ \ |
/ \ |
---- +--------+
|Agg | | |
---- | -- |
/ \ | / \ |
CE-2 CE-3 | \S / |
| -- |
+--------+
PE3-rs
Agg = Layer-2 Aggregation
--
/ \
\S / = Virtual Switch Instance
--
Figure 3: An example of a hierarchical VPLS model
図3：階層VPLSモデルの例
The MTU-s and the PE-rs treat each spoke connection like an AC of the VPLS service. The PW label is used to associate the traffic from the spoke to a VPLS instance.
An MTU-s is defined as a device that supports layer-2 switching functionality and does all the normal bridging functions of learning and replication on all its ports, including the spoke, which is treated as a virtual port. Packets to unknown destinations are replicated to all ports in the service including the spoke. Once the MAC address is learned, traffic between CE1 and CE2 will be switched locally by the MTU-s, saving the capacity of the spoke to the PE-rs. Similarly traffic between CE1 or CE2 and any remote destination is switched directly onto the spoke and sent to the PE-rs over the point-to-point PW.
MTU-Sは、レイヤー2スイッチング機能をサポートし、仮想ポートとして扱われるスポークを含むすべてのポートで学習と複製のすべての通常のブリッジング機能を実行するデバイスとして定義されます。未知の宛先へのパケットは、スポークを含むサービス内のすべてのポートに複製されます。MACアドレスが学習されると、CE1とCE2の間のトラフィックはMTU-Sによってローカルに切り替えられ、PE-RSにスポークの容量を節約します。同様に、CE1またはCE2とリモートの宛先間のトラフィックは、スポークに直接切り替えられ、ポイントツーポイントPWを介してPE-RSに送信されます。
Since the MTU-s is bridging capable, only a single PW is required per VPLS instance for any number of access connections in the same VPLS service. This further reduces the signaling overhead between the MTU-s and PE-rs.
MTU-Sはブリッジング機能であるため、同じVPLSサービスの任意の数のアクセス接続に対して、VPLSインスタンスごとに単一のPWのみが必要です。これにより、MTU-SとPE-RSの間のシグナリングオーバーヘッドがさらに減少します。
If the MTU-s is directly connected to the PE-rs, other encapsulation techniques, such as Q-in-Q, can be used for the spoke.
MTU-SがPE-RSに直接接続されている場合、Q-in-Qなどの他のカプセル化技術をスポークに使用できます。
A PE-rs is a device that supports all the bridging functions for VPLS service and supports the routing and MPLS encapsulation; i.e., it supports all the functions described for a basic VPLS, as described above.
PE-RSは、VPLSサービスのすべてのブリッジ機能をサポートし、ルーティングとMPLSのカプセル化をサポートするデバイスです。つまり、上記のように、基本的なVPLについて説明したすべての機能をサポートします。
The operation of PE-rs is independent of the type of device at the other end of the spoke. Thus, the spoke from the MTU-s is treated as a virtual port, and the PE-rs will switch traffic between the spoke PW, hub PWs, and ACs once it has learned the MAC addresses.
PE-RSの動作は、スポークの反対側のデバイスのタイプとは無関係です。したがって、MTU-Sからのスポークは仮想ポートとして扱われ、PE-RSはMACアドレスを学習すると、音声PW、HUB PWS、およびACS間のトラフィックを切り替えます。
Spoke connectivity offers several scaling and operational advantages for creating large-scale VPLS implementations, while retaining the ability to offer all the functionality of the VPLS service.
Skoke Connectivityは、VPLSサービスのすべての機能を提供する機能を保持しながら、大規模なVPLS実装を作成するためのいくつかのスケーリングと運用上の利点を提供します。
- Eliminates the need for a full mesh of tunnels and full mesh of PWs per service between all devices participating in the VPLS service.
- VPLSサービスに参加しているすべてのデバイス間で、サービスごとのトンネルの完全なメッシュと完全なメッシュの必要性を排除します。
- Minimizes signaling overhead, since fewer PWs are required for the VPLS service.
- VPLSサービスに必要なPWが少ないため、シグナリングオーバーヘッドを最小化します。
- Segments VPLS nodal discovery. MTU-s needs to be aware of only the PE-rs node, although it is participating in the VPLS service that spans multiple devices. On the other hand, every VPLS PE-rs must be aware of every other VPLS PE-rs and all of its locally connected MTU-s and PE-r devices.
- セグメントVPLSノーダルディスカバリー。MTU-Sは、複数のデバイスにまたがるVPLSサービスに参加していますが、PE-RSノードのみを認識する必要があります。一方、すべてのVPLS PE-RSは、他のすべてのVPLS PE-RSおよび局所的に接続されたすべてのMTU-SおよびPE-Rデバイスを認識する必要があります。
- Addition of other sites requires configuration of the new MTU-s but does not require any provisioning of the existing MTU-s devices on that service.
- 他のサイトを追加するには、新しいMTU-Sの構成が必要ですが、そのサービス上の既存のMTU-Sデバイスのプロビジョニングは必要ありません。
- Hierarchical connections can be used to create VPLS service that spans multiple service provider domains. This is explained in a later section.
- 階層接続を使用して、複数のサービスプロバイダードメインにまたがるVPLSサービスを作成できます。これについては、後のセクションで説明します。
Note that as more devices participate in the VPLS, there are more devices that require the capability for learning and replication.
より多くのデバイスがVPLに参加するにつれて、学習と複製の機能を必要とするデバイスが増えることに注意してください。
In some cases, a bridging PE-rs may not be deployed, or a PE-r might already have been deployed. In this section, we explain how a PE-r that does not support any of the VPLS bridging functionality can participate in the VPLS service.
場合によっては、ブリッジングPE-Rが展開されないか、PE-Rがすでに展開されている場合があります。このセクションでは、VPLSブリッジング機能のいずれもサポートしていないPE-RがVPLSサービスにどのように参加できるかを説明します。
In Figure 4, three customer sites are connected through CE-1, CE-2, and CE-3 to the VPLS through PE-r. For every attachment circuit that participates in the VPLS service, PE-r creates a point-to-point PW that terminates on the VSI of PE1-rs.
図4では、3つの顧客サイトがCE-1、CE-2、およびCE-3を介してPE-Rを介してVPLSに接続されています。VPLSサービスに参加するすべてのアタッチメント回路について、PE-RはPE1-RSのVSIで終了するポイントツーポイントPWを作成します。
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ PE-r PE1-rs / |
+--------+ +--------+ / |
|\ | | | / |
| \ | PW-1 | -- |---/ |
| ------|- - - - - - - - - - - | / \ | |
| -----|- - - - - - - - - - - | \S / | |
| / | | -- |---\ |
+--------+ +--------+ \ |
/ \ |
---- +--------+
| Agg| | |
---- | -- |
/ \ | / \ |
CE-2 CE-3 | \S / |
| -- |
+--------+
PE3-rs
Figure 4: An example of a hierarchical VPLS with non-bridging spokes
図4：非架橋スポークを備えた階層VPLの例
The PE-r is defined as a device that supports routing but does not support any bridging functions. However, it is capable of setting up PWs between itself and the PE-rs. For every port that is supported in the VPLS service, a PW is set up from the PE-r to the PE-rs. Once the PWs are set up, there is no learning or replication function required on the part of the PE-r. All traffic received on any of the ACs is transmitted on the PW. Similarly, all traffic received on a PW is transmitted to the AC where the PW terminates. Thus, traffic from CE1 destined for CE2 is switched at PE1-rs and not at PE-r.
PE-Rは、ルーティングをサポートするが、ブリッジング機能をサポートしないデバイスとして定義されます。ただし、それ自体とPE-RSの間にPWSをセットアップすることができます。VPLSサービスでサポートされているすべてのポートについて、PE-RからPE-RSにPWがセットアップされます。PWSがセットアップされると、PE-Rの側には学習または複製機能が必要ありません。ACSのいずれかで受け取ったすべてのトラフィックは、PWに送信されます。同様に、PWで受け取ったすべてのトラフィックは、PWが終了するACに送信されます。したがって、CE2に向けたCE1からのトラフィックは、PE-RではなくPE1-RSに切り替えられます。
Note that in the case where PE-r devices use Provider VLANs (P-VLAN) as demultiplexers instead of PWs, PE1-rs can treat them as such and map these "circuits" into a VPLS domain to provide bridging support between them.
PE-RデバイスがPWSの代わりにプロバイダーVLAN（P-VLAN）をDemultiplexersとして使用する場合、PE1-RSはそれらをそのように扱い、これらの「サーキット」をVPLSドメインにマッピングして、それらの間で橋渡しサポートを提供できることに注意してください。
This approach adds more overhead than the bridging-capable (MTU-s) spoke approach, since a PW is required for every AC that participates in the service versus a single PW required per service (regardless of ACs) when an MTU-s is used. However, this approach offers the advantage of offering a VPLS service in conjunction with a routed internet service without requiring the addition of new MTU-s.
このアプローチは、サービスに参加するすべてのACに対してPWが必要であるため、MTU-Sを使用するときにサービスごとに必要な単一のPWにPWが必要であるため、ブリッジング対応（MTU-S）スポークアプローチよりもオーバーヘッドを追加します。。ただし、このアプローチは、新しいMTU-Sを追加することなく、ルーティングされたインターネットサービスと組み合わせてVPLSサービスを提供するという利点を提供します。
An obvious weakness of the hub and spoke approach described thus far is that the MTU-s has a single connection to the PE-rs. In case of failure of the connection or the PE-rs, the MTU-s suffers total loss of connectivity.
これまでに説明されているハブとスポークのアプローチの明らかな弱点は、MTU-SがPE-RSに単一の接続を持っていることです。接続またはPE-RSの障害が発生した場合、MTU-Sは接続の合計損失に苦しんでいます。
In this section, we describe how the redundant connections can be provided to avoid total loss of connectivity from the MTU-s. The mechanism described is identical for both, MTU-s and PE-r devices.
このセクションでは、MTUからの接続の完全な損失を回避するために、冗長接続をどのように提供できるかについて説明します。記載されているメカニズムは、MTU-SデバイスとPE-Rデバイスの両方で同一です。
To protect from connection failure of the PW or the failure of the PE-rs, the MTU-s or the PE-r is dual-homed into two PE-rs devices. The PE-rs devices must be part of the same VPLS service instance.
PWの接続障害またはPE-RSの障害から保護するために、MTU-SまたはPE-Rが2つのPE-RSデバイスにデュアルホームされます。PE-RSデバイスは、同じVPLSサービスインスタンスの一部でなければなりません。
In Figure 5, two customer sites are connected through CE-1 and CE-2 to an MTU-s. The MTU-s sets up two PWs (one each to PE1-rs and PE3-rs) for each VPLS instance. One of the two PWs is designated as primary and is the one that is actively used under normal conditions, whereas the second PW is designated as secondary and is held in a standby state. The MTU-s negotiates the PW labels for both the primary and secondary PWs, but does not use the secondary PW unless the primary PW fails. How a spoke is designated primary or secondary is outside the scope of this document. For example, a spanning tree instance running between only the MTU-s and the two PE-rs nodes is one possible method. Another method could be configuration.
図5では、2つの顧客サイトがCE-1とCE-2を介してMTU-Sに接続されています。MTU-Sは、各VPLSインスタンスに2つのPW（それぞれ1つがPE1-RSとPE3-RS）を設定します。2つのPWSの1つは一次として指定されており、通常の条件下で積極的に使用されるものですが、2番目のPWはセカンダリとして指定され、スタンバイ状態に保持されます。MTU-Sは、プライマリとセカンダリPWの両方のPWラベルを交渉しますが、プライマリPWが失敗しない限り、セカンダリPWを使用しません。スポークがどのように指定されているかは、プライマリまたはセカンダリーがこのドキュメントの範囲外です。たとえば、MTU-Sと2つのPE-RSノードのみで実行されるスパニングツリーインスタンスは、1つの可能な方法です。別の方法は構成です。
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ MTU-s PE1-rs / |
+--------+ +--------+ / |
| | | | / |
| -- | Primary PW | -- |---/ |
| / \ |- - - - - - - - - - - | / \ | |
| \S / | | \S / | |
| -- | | -- |---\ |
+--------+ +--------+ \ |
/ \ \ |
/ \ +--------+
/ \ | |
CE-2 \ | -- |
\ Secondary PW | / \ |
- - - - - - - - - - - - - - - - - | \S / |
| -- |
+--------+
PE3-rs
Figure 5: An example of a dual-homed MTU-s
The MTU-s should control the usage of the spokes to the PE-rs devices. If the spokes are PWs, then LDP signaling is used to negotiate the PW labels, and the hello messages used for the LDP session could be used to detect failure of the primary PW. The use of other mechanisms that could provide faster detection failures is outside the scope of this document.
MTU-Sは、PE-RSデバイスへのスポークの使用を制御する必要があります。スポークがPWSである場合、LDPシグナル伝達を使用してPWラベルをネゴシエートし、LDPセッションに使用されるHelloメッセージを使用してプライマリPWの障害を検出できます。より速い検出障害を提供できる他のメカニズムの使用は、このドキュメントの範囲外です。
Upon failure of the primary PW, MTU-s immediately switches to the secondary PW. At this point, the PE3-rs that terminates the secondary PW starts learning MAC addresses on the spoke PW. All other PE-rs nodes in the network think that CE-1 and CE-2 are behind PE1-rs and may continue to send traffic to PE1-rs until they learn that the devices are now behind PE3-rs. The unlearning process can take a long time and may adversely affect the connectivity of higher-level protocols from CE1 and CE2. To enable faster convergence, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2), using the MAC List TLV, as defined in Section 6, to all PE-rs nodes. Upon receiving the message, PE-rs nodes flush the MAC addresses associated with that VPLS instance.
プライマリPWが失敗すると、MTU-Sはすぐに二次PWに切り替わります。この時点で、セカンダリPWを終了するPE3-RSは、スポークPWでMACアドレスの学習を開始します。ネットワーク内の他のすべてのPE-RSノードは、CE-1とCE-2がPE1-RSの背後にあると考えており、デバイスが現在PE3-Rの背後にあることがわかるまでPE1-RSにトラフィックを送信し続ける可能性があります。未学習プロセスには長い時間がかかる場合があり、CE1およびCE2からの高レベルのプロトコルの接続性に悪影響を与える可能性があります。より速い収束を有効にするために、セカンダリPWがアクティブになったPE3-RSは、セクション6で定義されているように、すべてのPE-RSノードにMACリストTLVを使用して、フラッシュメッセージ（セクション6.2で説明されているように）を送信できます。メッセージを受信すると、PE-RSノードは、そのVPLSインスタンスに関連付けられたMACアドレスをフラッシュします。
Hierarchy can also be used to create a large-scale VPLS service within a single domain or a service that spans multiple domains without requiring full mesh connectivity between all VPLS-capable devices. Two fully meshed VPLS networks are connected together using a single LSP tunnel between the VPLS "border" devices. A single spoke PW per VPLS service is set up to connect the two domains together.
階層を使用して、すべてのVPLS対応デバイス間の完全なメッシュ接続を必要とせずに複数のドメインにまたがる単一ドメインまたはサービスにまたがるサービス内で大規模なVPLSサービスを作成することもできます。2つの完全にメッシュ化されたVPLSネットワークは、VPLSの「境界」デバイス間の単一のLSPトンネルを使用して一緒に接続されています。VPLSサービスごとに1つのスポークPWがセットアップされ、2つのドメインを接続するように設定されています。
When more than two domains need to be connected, a full mesh of inter-domain spokes is created between border PEs. Forwarding rules over this mesh are identical to the rules defined in Section 4.
3つ以上のドメインを接続する必要がある場合、境界PEの間にドメイン間スポークの完全なメッシュが作成されます。このメッシュ上の転送ルールは、セクション4で定義されているルールと同じです。
This creates a three-tier hierarchical model that consists of a hub-and-spoke topology between MTU-s and PE-rs devices, a full-mesh topology between PE-rs, and a full mesh of inter-domain spokes between border PE-rs devices.
これにより、MTU-SとPE-RSデバイスの間のハブアンドスポークトポロジ、PE-R間のフルメッシュトポロジ、およびBorder PE間のドメイン間スポークの完全なメッシュで構成される3層階層モデルが作成されます。-RSデバイス。
This document does not specify how redundant border PEs per domain per VPLS instance can be supported.
このドキュメントでは、VPLSインスタンスごとのドメインごとの冗長境界PESをサポートする方法を指定していません。
In this section, the hierarchical model is expanded to include an Ethernet access network. This model retains the hierarchical architecture discussed previously in that it leverages the full-mesh topology among PE-rs devices; however, no restriction is imposed on the topology of the Ethernet access network (e.g., the topology between MTU-s and PE-rs devices is not restricted to hub and spoke).
このセクションでは、階層モデルが拡張され、イーサネットアクセスネットワークが含まれます。このモデルは、PE-RSデバイス間でフルメッシュトポロジを活用するという点で、前述の階層アーキテクチャを保持しています。ただし、イーサネットアクセスネットワークのトポロジーには制限は課されていません（たとえば、MTU-SとPE-RSデバイスの間のトポロジーはハブに限定されていない）。
The motivation for an Ethernet access network is that Ethernet-based networks are currently deployed by some service providers to offer VPLS services to their customers. Therefore, it is important to provide a mechanism that allows these networks to integrate with an IP or MPLS core to provide scalable VPLS services.
イーサネットアクセスネットワークの動機は、イーサネットベースのネットワークが現在、一部のサービスプロバイダーによって展開されてVPLSサービスを顧客に提供していることです。したがって、これらのネットワークがIPまたはMPLSコアと統合してスケーラブルなVPLSサービスを提供できるメカニズムを提供することが重要です。
One approach of tunneling a customer's Ethernet traffic via an Ethernet access network is to add an additional VLAN tag to the customer's data (which may be either tagged or untagged). The additional tag is referred to as Provider's VLAN (P-VLAN). Inside the provider's network each P-VLAN designates a customer or more specifically a VPLS instance for that customer. Therefore, there is a one-to-one correspondence between a P-VLAN and a VPLS instance. In this model, the MTU-s needs to have the capability of adding the additional P-VLAN tag to non-multiplexed ACs where customer VLANs are not used as service delimiters. This functionality is described in [802.1ad].
イーサネットアクセスネットワークを介して顧客のイーサネットトラフィックをトンネル化する1つのアプローチは、顧客のデータに追加のVLANタグを追加することです（タグ付けまたはタグ付けされていない場合があります）。追加のタグは、プロバイダーのVLAN（P-VLAN）と呼ばれます。プロバイダーのネットワーク内で、各P-VLANは、顧客またはその顧客のVPLSインスタンスを顧客またはより具体的に指定します。したがって、P-VLANとVPLSインスタンスの間には1対1の対応があります。このモデルでは、MTU-Sには、顧客VLANがサービスデリミターとして使用されていない非マルチプレックスACSに追加のP-VLANタグを追加する機能が必要です。この機能は[802.1AD]で説明されています。
If customer VLANs need to be treated as service delimiters (e.g., the AC is a multiplexed port), then the MTU-s needs to have the additional capability of translating a customer VLAN (C-VLAN) to a P-VLAN, or to push an additional P-VLAN tag, in order to resolve overlapping VLAN tags used by different customers. Therefore, the MTU-s in this model can be considered a typical bridge with this additional capability. This functionality is described in [802.1ad].
顧客VLANをサービスデリミターとして扱う必要がある場合（たとえば、ACは多重化ポートです）、MTU-Sには、顧客VLAN（C-VLAN）をP-VLANに翻訳する追加の機能が必要です。さまざまな顧客が使用する重複するVLANタグを解決するために、追加のP-VLANタグを押します。したがって、このモデルのMTU-Sは、この追加機能を備えた典型的なブリッジと見なすことができます。この機能は[802.1AD]で説明されています。
The PE-rs needs to be able to perform bridging functionality over the standard Ethernet ports toward the access network, as well as over the PWs toward the network core. In this model, the PE-rs may need to run STP towards the access network, in addition to split-horizon over the MPLS core. The PE-rs needs to map a P-VLAN to a VPLS-instance and its associated PWs, and vice versa.
PE-RSは、アクセスネットワークに向けた標準イーサネットポート、およびネットワークコアへのPWSを介してブリッジング機能を実行できる必要があります。このモデルでは、PE-RSは、MPLSコア上のスプリットホリゾンに加えて、STPをアクセスネットワークに向けて実行する必要がある場合があります。PE-RSは、P-VLANをVPLSインスタンスとそれに関連するPWSにマッピングする必要があり、その逆も同様です。
The details regarding bridge operation for MTU-s and PE-rs (e.g., encapsulation format for Q-in-Q messages, customer's Ethernet control protocol handling, etc.) are outside the scope of this document and are covered in [802.1ad]. However, the relevant part is the interaction between the bridge module and the MPLS/IP PWs in the PE-rs, which behaves just as in a regular VPLS.
MTU-SおよびPE-RSのブリッジ操作に関する詳細（たとえば、Q-in-Qメッセージ、顧客のイーサネット制御プロトコル処理などのカプセル化形式）は、このドキュメントの範囲外であり、[802.1AD]でカバーされています。。ただし、関連する部分は、通常のVPLSと同様に動作するPE-RSのブリッジモジュールとMPLS/IP PWS間の相互作用です。
Since each P-VLAN corresponds to a VPLS instance, the total number of VPLS instances supported is limited to 4K. The P-VLAN serves as a local service delimiter within the provider's network that is stripped as it gets mapped to a PW in a VPLS instance. Therefore, the 4K limit applies only within an Ethernet access network (Ethernet island) and not to the entire network. The SP network consists of a core MPLS/IP network that connects many Ethernet islands. Therefore, the number of VPLS instances can scale accordingly with the number of Ethernet islands (a metro region can be represented by one or more islands).
各p-VLANはVPLSインスタンスに対応するため、サポートされているVPLSインスタンスの総数は4Kに制限されています。P-VLANは、プロバイダーのネットワーク内のローカルサービスデリミタとして機能し、VPLSインスタンスでPWにマッピングされると剥がされます。したがって、4K制限は、イーサネットアクセスネットワーク（イーサネット島）内でのみ適用され、ネットワーク全体には適用されません。SPネットワークは、多くのイーサネット諸島を接続するコアMPLS/IPネットワークで構成されています。したがって、VPLSインスタンスの数は、イーサネット諸島の数に応じて拡張できます（メトロ地域は1つ以上の島で表すことができます）。
In this model, an MTU-s can be dual homed to different devices (aggregators and/or PE-rs devices). The failure protection for access network nodes and links can be provided through running STP in each island. The STP of each island is independent of other islands and do not interact with others. If an island has more than one PE-rs, then a dedicated full-mesh of PWs is used among these PE-rs devices for carrying the SP BPDU packets for that island. On a per-P-VLAN basis, STP will designate a single PE-rs to be used for carrying the traffic across the core. The loop-free protection through the core is performed using split-horizon, and the failure protection in the core is performed through standard IP/MPLS re-routing.
このモデルでは、MTU-Sをさまざまなデバイス（アグリゲーターおよび/またはPE-RSデバイス）にデュアルホームすることができます。アクセスネットワークノードとリンクの障害保護は、各島でSTPを実行することで提供できます。各島のSTPは他の島とは独立しており、他の島とは相互作用しません。島に複数のPE-RSがある場合、その島のSP BPDUパケットを運ぶために、これらのPE-RSデバイスの中でPWSの専用のフルメッシュが使用されます。P-VLANごとに、STPは、コアを横切るトラフィックを運ぶために使用される単一のPE-Rを指定します。コアを介したループフリーの保護は、スプリットホリゾンを使用して実行され、コアの故障保護は標準のIP/MPLSの再ルーティングを介して実行されます。
Loa Andersson, TLA Ron Haberman, Alcatel-Lucent Juha Heinanen, Independent Giles Heron, Tellabs Sunil Khandekar, Alcatel-Lucent Luca Martini, Cisco Pascal Menezes, Independent Rob Nath, Alcatel-Lucent Eric Puetz, AT&T Vasile Radoaca, Independent Ali Sajassi, Cisco Yetik Serbest, AT&T Nick Slabakov, Juniper Andrew Smith, Consultant Tom Soon, AT&T Nick Tingle, Alcatel-Lucent
Loa Andersson、Tla Ron Haberman、Alcatel-Lucent Juha Heinan、独立したジャイルズ・ヘロン、テラブス・スニル・カンデカル、アルカテル・ルーセント・ルカ・マルティーニ、シスコ・パスカル・メネゼ、独立したロブ・ナス、アルカテル・ルーセント・エリック・プエッツ、atYetik Serbest、AT＆T Nick Slabakov、ジュニパーAndrew Smith、コンサルタントTom Soon、AT＆T Nick Tingle、Alcatel-Lucent
We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel Halpern, Bill Hong, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov Rekhter, Sasha Vainshtein, and Du Wenhua for their valuable feedback.
ジョー・リーガン、キリエト・コンペラ、アヌープ・ガンワニ、ジョエル・ハルパーン、ビル・ホン、リック・ワイルダー、ジム・ギチャード、スティーブ・フィリップス、ノルム・フィン、マット・スクワイア、ムネディ・スズキ、ウォルデマール・オーガスタティン、エリック・ローゼン、ヤコフ・レクター、サシャ・ベインシュテインなど彼らの貴重なフィードバックのためにデュウェンフア。
We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu (Ixia), and Charlie Hundall for identifying issues with the draft in the course of the interoperability tests.
また、相互運用性テストの過程でドラフトの問題を特定してくれたRajiv Papneja（Isocore）、Winston Liu（Ixia）、およびCharlie Hundallにも感謝します。
We would also like to thank Ina Minei, Bob Thomas, Eric Gray and Dimitri Papadimitriou for their thorough technical review of the document.
また、イナ・ミネイ、ボブ・トーマス、エリック・グレイ、ディミトリ・パパジミトリウに、ドキュメントの徹底的な技術レビューに感謝します。
A more comprehensive description of the security issues involved in L2VPNs is covered in [RFC4111]. An unguarded VPLS service is vulnerable to some security issues that pose risks to the customer and provider networks. Most of the security issues can be avoided through implementation of appropriate guards. A couple of them can be prevented through existing protocols.
L2VPNSに関係するセキュリティ問題のより包括的な説明は、[RFC4111]で説明されています。無防備なVPLSサービスは、顧客とプロバイダーのネットワークにリスクをもたらすいくつかのセキュリティ問題に対して脆弱です。セキュリティの問題のほとんどは、適切なガードの実装を通じて回避できます。それらのいくつかは、既存のプロトコルを介して防止できます。
- Data plane aspects
-
- Traffic isolation between VPLS domains is guaranteed by the use of per VPLS L2 FIB table and the use of per VPLS PWs.
- VPLSドメイン間のトラフィック分離は、VPLS L2 FIBテーブルごとに使用され、VPLS PWSごとの使用によって保証されます。
- The customer traffic, which consists of Ethernet frames, is carried unchanged over VPLS. If security is required, the customer traffic SHOULD be encrypted and/or authenticated before entering the service provider network.
- イーサネットフレームで構成される顧客トラフィックは、VPLSに対して変化していません。セキュリティが必要な場合は、サービスプロバイダーネットワークに入る前に、顧客のトラフィックを暗号化および/または認証する必要があります。
- Preventing broadcast storms can be achieved by using routers as CPE devices or by rate policing the amount of broadcast traffic that customers can send.
- RouterをCPEデバイスとして使用するか、顧客が送信できるブロードキャストトラフィックの量をポリシングすることにより、放送の嵐を防ぐことができます。
- Control plane aspects
- コントロールプレーンの側面
- LDP security (authentication) methods as described in [RFC3036] SHOULD be applied. This would prevent unauthenticated messages from disrupting a PE in a VPLS.
- [RFC3036]で説明されているLDPセキュリティ（認証）メソッドを適用する必要があります。これにより、認識されていないメッセージがVPLのPEを破壊することが妨げられます。
- Denial of service attacks
- サービス拒否攻撃
- Some means to limit the number of MAC addresses (per site per VPLS) that a PE can learn SHOULD be implemented.
- PEが学習できるMACアドレスの数（VPLあたりのサイトごと）を制限するためのいくつかの手段を実装する必要があります。
The type field in the MAC List TLV is defined as 0x404 in Section 6.2.1.
MACリストTLVのタイプフィールドは、セクション6.2.1の0x404として定義されます。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、2006年4月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448] Martini、L.、Rosen、E.、El-Aawar、N。、およびG. Heron、「MPLSネットワーク上のイーサネットの輸送のためのカプセル化方法」、RFC 4448、2006年4月。
[802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges".
[802.1D-REV] 802.1D - "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998.
[802.1D -REV] 802.1D-「情報技術 - システム間の電気通信と情報交換 - ローカルと大都市のエリアネットワーク - 共通仕様 - パート3：メディアアクセス制御（MAC）ブリッジ：改訂。これはISO/IECEの改訂です10038：1993、802.1J-1992および802.6K-1992。P802.11C、P802.1PおよびP802.12Eが組み込まれています。ISO/IEC 15802-3：1998。
[802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", July 1998.
[802.1Q] 802.1Q -ANSI/IEEEドラフト標準P802.1Q/D11、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：仮想ブリッジ付きローカルエリアネットワーク」、1998年7月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）へのIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[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月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[RADIUS-DISC] Heinanen, J., Weber, G., Ed., Townsley, W., Booth, S., and W. Luo, "Using Radius for PE-Based VPN Discovery", Work in Progress, October 2005.
[Radius-Disc] Heinanen、J.、Weber、G.、Ed。、Townsley、W.、Booth、S。、およびW. Luo、「PEベースのVPN発見に半径を使用」、2005年10月の作業。
[BGP-DISC] Ould-Brahim, H., Ed., Rosen, E., Ed., and Y. Rekhter, Ed., "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", Work in Progress, September 2006.
[L2FRAME] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[L2Frame] Andersson、L。およびE. Rosen、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、RFC 4664、2006年9月。
[L2VPN-REQ] Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006.
[RFC4111] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4111] Fang、L。、「プロバイダーが提供する仮想プライベートネットワーク（PPVPNS）のセキュリティフレームワーク」、RFC 4111、2005年7月。
[802.1ad] "IEEE standard for Provider Bridges", Work in Progress, December 2002.
[802.1AD]「プロバイダーブリッジのIEEE標準」、2002年12月、進行中の作業。
This section is being retained because live deployments use this version of the signaling for VPLS.
このセクションは、Live DeploymentsがVPLSのシグナリングのこのバージョンを使用しているため、保持されています。
The VPLS signaling information is carried in a Label Mapping message sent in downstream unsolicited mode, which contains the following PWid FEC TLV.
VPLSシグナル情報は、以下のPWID FEC TLVを含む下流の未承諾モードで送信されたラベルマッピングメッセージに掲載されます。
PW, C, PW Info Length, Group ID, and Interface parameters are as defined in [RFC4447].
PW、C、PW情報の長さ、グループID、およびインターフェイスパラメーターは、[RFC4447]で定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW TLV |C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We use the Ethernet PW type to identify PWs that carry Ethernet traffic for multipoint connectivity.
イーサネットPWタイプを使用して、マルチポイント接続のためにイーサネットトラフィックを運ぶPWを識別します。
In a VPLS, we use a VCID (which, when using the PWid FEC, has been substituted with a more general identifier (AGI), to address extending the scope of a VPLS) to identify an emulated LAN segment. Note that the VCID as specified in [RFC4447] is a service identifier, identifying a service emulating a point-to-point virtual circuit. In a VPLS, the VCID is a single service identifier, so it has global significance across all PEs involved in the VPLS instance.
VPLSでは、VCID（PWID FECを使用する場合、より一般的な識別子（AGI）に置き換えられ、VPLSの範囲の拡張に対処する）を使用して、エミュレートされたLANセグメントを識別します。[RFC4447]で指定されているVCIDは、ポイントツーポイント仮想回路をエミュレートするサービスを識別するサービス識別子であることに注意してください。VPLSでは、VCIDは単一のサービス識別子であるため、VPLSインスタンスに関与するすべてのPEにわたってグローバルな重要性があります。
Authors' Addresses
著者のアドレス
Marc Lasserre Alcatel-Lucent EMail: mlasserre@alcatel-lucent.com
Marc Lasserre Alcatel-Lucentメール：mlasserre@alcatel-lucent.com
Vach Kompella Alcatel-Lucent EMail: vach.kompella@alcatel-lucent.com
Vach Kompella Alcatel-Lucentメール：vach.kompella@alcatel-lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。