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
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）IETFトラスト（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およびこの文書を、作成しました。彼らはお互いにはっきりと互換性があるにもかかわらず、それぞれの方法は一般に「VPLS」と呼ばれていることに注意してください。
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.
この文書では、疑似回線を使用して仮想プライベート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およびWAN、それぞれ）で、アクセス技術として受け入れを集めています。仮想プライベートLANサービス（VPLS）の背後にある主な動機は、彼らがLANを使って接続しているかのように、MANをおよびWAN全体で地理的に分散した顧客サイト間の接続性を提供することです。エンドユーザの意図した用途は、以下の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ブロードキャストドメインまたはVPLSに属している複数のサイト間でのEthernet / 802.3とVLAN [802.1Q]トラフィックを搬送するための[RFC4447]への拡張機能について説明します。同モデルは、他の802.1の技術にも適用できることに注意してください。で説明したようにこれは、アドレス解決サーバや他の外部サーバを必要とせずに、ブロードキャスト、マルチキャスト、およびMPLSを超える未知のユニキャスト先のトラフィックの適切な洪水を含む仮想LANサービスを、提供するためのシンプルかつスケーラブルな方法を説明し、[L2VPN-REQ] 。
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-に-Q 802.1adプロバイダブリッジ拡張はまた、スタッカブルVLANまたはQ-で-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を単一のVPLSにマッピングされている修飾されていない学習学習モード。
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
ACアタッチメント回路
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
LDPラベル配布プロトコル
MTU-s Multi-Tenant Unit switch
MTU-Sマルチテナント単位スイッチ
PE Provider Edge device
PEプロバイダエッジデバイス
PW Pseudowire
PO Psefdoviri
STP Spanning Tree Protocol
STPスパニングツリープロトコル
VLAN Virtual LAN
VLANの仮想LAN
VLAN tag VLAN Identifier
VLANタグVLAN識別子
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のトポロジーモデルを示します。 PWを介して相互接続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
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.
私たちは、このドキュメントはMPLSトランスポートトンネル、（[RFC4447]で述べたように）PWを使用することができ、他のトンネルを使用して具体的な例を示していることを改めてここで注意してください - 例えば、GRE、L2TP、IPsecが - 長いとしても使用することができます発信PEとして、これはMAC学習処理に使用されているので、識別することができます。
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の範囲は、離れて、顧客サービスの描写から、顧客サイトへのアクセスの形がVPLS [L2VPN-REQ]に関連していないという事実を強調し、サービスプロバイダーネットワーク内のPE内にあります。換言すれば、顧客に接続される接続回線（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は、典型的には、のPWを設定するLDPシグナリングプロトコルおよび/またはルーティングプロトコルを実行することが可能なエッジルータです。また、それは他のPEへの輸送トンネルを設定およびPW上のトラフィックを送達することが可能です。
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.
フレームを転送するために、PEはPWと宛先MACアドレスを関連付けることができなければなりません。 PEは、静的PWを持つすべての可能な宛先MACアドレスの関連付けを設定することを要求するのは無理、おそらく不可能です。したがって、VPLS対応のPEは動的のACおよびPWの両方のMACアドレスを学習するとACSおよびPWの両方の間でパケットを転送して複製する能力を有しているべきです。
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のVPN [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アドレスが不明な場合は、そのMACアドレスへの発信パケットは、関連するPWを介して配信することができるように、PWに関連付けする必要があります。送信元MACアドレスが不明な場合は、パケットは、ACに到着したときにそのMACアドレスへのアウトバウンドパケットは、関連するAC経由で配信できるように、同様に、それは、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間で設定されています。 PWSがトランスポートトンネルを横切る複数の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.
イーサネットL2VPNでは、ループのないトポロジを作成するために、サービスプロバイダの責任となります。簡単にするために、我々は、VPLSのトポロジーはのPWフルメッシュであることを定義します。
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のトポロジをフルメッシュに限定されるものではない場合、それは、二つのPEが直接のPWを介して接続されていないため、それらはパケットを中継する中間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.
代わりに、PWをのフルメッシュは、PE間で確立されています。すべてのPEが今直接PWを経由してVPLS内の他のすべてのPEに接続されているので、パケットを中継する必要はもうありません、我々は単純なループブレークルールインスタンス化することができます。これによりPEはMUST、「スプリットホライズン」のルールを同じVPLSメッシュに別の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.
そのような顧客は内部障害が発生した場合に冗長性を提供するために使用する「バックドア」のリンクを持っているときのように、（[802.1D-REV]で定義されているように、例えば）のお客様がスパニングツリープロトコル（STP）を実行することが許可されていることに注意してくださいVPLS。そのような場合には、STPブリッジのPDU（BPDUが）単にプロバイダクラウドを介してトンネリングされています。
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セッションのフルメッシュは、PWをのメッシュを確立するために使用されます。 PWフルメッシュのための要件は、目標とLDPセッションが多数になることがあります。セクション10は、VPLSフルメッシュのサイズを最小化するために、階層的なトポロジを設定するためのオプションについて説明します。
Once an LDP session has been formed between two PEs, all PWs between these two PEs are signaled over this session.
LDPセッションが2個のPEとの間に形成された後、これらの二つのPE間のすべてのPWSがこのセッションで通知されます。
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]でのFECの二つのタイプが記載されている：PWID FEC要素（FECタイプ128）及び一般PWID FEC要素（FECタイプ129）。 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タイプ：[RFC4446]で指定されるように許容PWタイプがイーサネット（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）、長さ、値：このユニークな名前はVPLS。 AGIは、名前のタイプを識別し、長さはVPLSの名前された値の長さを示します。私たちは、VPLS識別子と交換可能用語AGIを使用しています。
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内のPWメッシュがMAC学習テーブルではなく、個々の接続回線で終端するため、これらがnullです。 null以外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アドレスは、MACのリストにメッセージを撤回送信することにより達成され、対応するLDPセッションに対して、他のすべてのPEに削除されるように対処しています。
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アドレスのリストを指定するには、自民党内の任意のMACリストTLVをご紹介します。
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リストTLVを持つメッセージは、トポロジー変化の結果として、MACアドレスの除去を促進するためにサポートされるかもしれ撤回（例えば、デュアルホーム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.
MACリストTLVは、MACアドレスが多数含まれている場合LDPコンバージェンス時間への影響を最小限にするために、空のリストと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は、LDPアドレスが新しいTLV、MACリストTLVを含むメッセージを撤回使用してシグナリングすることができる学習されていないことを対処しています。その形式は以下の通りです。 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ビット：不明なビットを。 MACアドレス形式は、次にTLVが理解されていないが、理解されておらず、無視されなければならない場合、このビットは1に設定しなければなりません。
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ビット：フォワードビット。ここで使用LDP機構がTLVを転送してはならない、目標とされているので、このビットは0に設定しなければなりません。
Type: Type field. This field MUST be set to 0x0404. This identifies the TLV type as MAC List TLV.
タイプ：Typeフィールド。このフィールドは0x0404に設定しなければなりません。これは、MACリストTLVとして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アドレス（複数可）が削除されています。
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.
メッセージを理解していないPEがVPLSに参加し続けることができるようにMACアドレスメッセージを撤回だけで、収束をスピードアップに役立ちます。
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.
- メッセージを受信した上にこのシグナリングセッションに関連付けられたPWにわたって学習されたMACアドレス以外（FEC TLVで指定）VPLSインスタンスに関連付けられたすべてのMACアドレスを削除します。
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:
[RFC4448]で定義されるようにVPLSにおいて、プリアンブルなしで顧客イーサネットフレームは、ヘッダでカプセル化されています。次のように顧客のイーサネットフレームが定義されています。
- 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に到着するように、フレームは、区切りサービスされていないカプセル化されている場合、それは、そのカプセル化VPLSによって修飾されるべきではない顧客のフレームです。これは、例えば、サービスプロバイダはどちらも知っていることも、変更したい顧客固有の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.
顧客フレームはATM上顧客向けポートに到着するや、顧客のVPLSインスタンスを識別するリレー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を横断イーサネットフレームは、常に顧客のイーサネットフレームです。入力と出力の2つのアクションは、サービス区切り文字を扱うのでもないPEが他に合図するために持っているローカルアクションがあることに注意してください。彼らは許可し、例えば、VLANのミックス・アンド・マッチは、タグ付きおよびタグなしのサービス終了のいずれかで、彼らはVPLS渡っのみローカルな意味を持っているVLANタグを運ぶことはありません。サービスデリミタは、[RFC4448]で指定されたイーサネットPWがPEにアクセス側接続として働くことができる、また、MPLSラベルであってもよいです。 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のマッピングを追跡します。資格と資格のない学習：私たちは、学習の二つのモードを定義します。資格の学習はデフォルトのモードであるとサポートしなければなりません。無資格の学習のサポートはオプションです。
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は、それらすべての共有単一のブロードキャストドメインと単一のMACアドレス空間を意味し、単一のVPLS、によって処理されます。これは、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は、各顧客VLANは、独自のブロードキャストドメインとMACアドレス空間を有することを意味する独自のVPLSインスタンスに割り当てられています。そのため、資格の学習では、カスタマー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の場合には、サービス区切りタグ（Q-に-Qまたは[RFC4448]）PEが明確STP BPDUを含めて、すべての顧客のトラフィックを識別することができるように追加することができる（セクション10における詳細を参照されたいです）。基本的なVPLSの場合には、アップストリームスイッチは、タグを区切るようなサービスを挿入する必要があります。アクセスポートは、複数の顧客間で共有されている場合、顧客のドメインごとに予約VLANはSTPトラフィックを運ぶために使用する必要があります。 STPフレームは（通常の顧客のトラフィックなど）は、顧客ごとに固有のプロバイダタグでカプセル化されており、PEが適切な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]に記載されたものと同様であるが、タグを課すと「正規化」イーサネットフレームを使用しての機能について説明します。学習行動は、イーサネットPWのと同じです。
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:
[RFC4448]で定義されるようにVPLSにおいて、プリアンブルなしで顧客イーサネットフレームは、ヘッダでカプセル化されています。次のように顧客のイーサネットフレームが定義されています。
- 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によって使用されるカプセル化されている場合フレームがVPLSに送信されるように要求されたVLAN IDオプションのパラメータをシグナリングしない限り、そのカプセル化は、保存されます。フレームは、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].
VPLSは、イーサネットとイーサネットVLAN PWを両方を持っているかもしれません。 PEは、同時に両方のPWをサポートすることができない場合は、それは[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に、ここでのVPLSがどのように動作するかの例を示しています。以下の議論は、VPLSは、PE1、PE2、PE3との間に設定されている以下の図を使用しています。 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.
PE1、PE2、PE3とは、イーサネットのPWフルメッシュを持っているように、最初は、VPLSが設定されています。 VPLSインスタンス識別子（AGI）が割り当てられます。上記の例では、PE1がPE2にPWラベル102を信号およびPE3 103、及びPE2はPE1とPE3 203にPWラベル201に信号を言います。
-----
/ 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とM2の宛先のMACの送信元MACアドレスを持っていると言います。 M2がどこにあるPE1がわからない場合は、パケットをフラッディングします。すなわち、PE2とPE3に送信します。 PE2がパケットを受信したとき、それはPE1にラベル201を分散するので、それは、送信元MACアドレスM1はPE1の背後にあると結論付けることができる201 PE2のPWラベルを有することになります。したがって、PWラベル102でMACアドレスM1を関連付けることができます。
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アドレスを学習PEはPWラベルに関連付けられている未使用のエントリを削除するには、老化のメカニズムを持っているべきです。これは、メモリの節約のためにと、管理上の目的のために両方が重要です。顧客サイトAは、シャットダウンされた場合、最終的には他のPEは、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のPWがPEルータ間で設定されなければなりません。これは、シグナリングオーバーヘッドを作成しますが、大規模な展開に実際の損害は、PEルータ上の各プロビジョニングPWのためのパケット複製の要件です。この文書に記載された階層の接続は、大規模な展開を可能にするために、シグナリングと複製オーバヘッドを減少させます。
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（ドット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サービストンネリング技術を拡張することはしばしば有益です。これは、基本的なVPLSのように、PEのようにアクセス装置を処理し、すべての他の縁との間のPWをプロビジョニングすることによって達成することができます。代替的には、アクセス装置とPEルータ有効選択VPLSとの間の[RFC4448]のPWまたはQインQ論理インターフェイスを利用することです。 Q-で-Qカプセル化は、後述するように、MPLSシグナリングと組み合わせて使用することができるL2トンネリング技術の別の形態です。次の2つのセクションでは、この代替的なアプローチに焦点を当てています。 VPLSコアのPW（ハブ）は、2つの階層の階層VPLS（H-VPLS）を形成するアクセスのPW（スポーク）で補強されています。
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.
PWSは、任意のL2トンネリングメカニズムを使用して実装され、非架橋VPLS PEルータを含むように第一層の適用範囲を拡大してもよいスポーク。非架橋PEルータは、それに接続するレイヤ2スイッチから、サービスコアネットワークを介して、ハブのPWを支持するブリッジVPLS PEルータにスポークPWを拡張することになります。また、MPLS機能のないVPLSチャレンジノードとローエンドのCEは、階層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-RSなどのルーティングおよびブリッジングできる装置を指します。
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においては、以下三の顧客サイトは、CE-1、CE-2及びCE-3を介してMTU-Sに接続されています。 MTU-sがPE1-RSへの単一の接続（PW-1）を有します。 PE-RSデバイスは、基本的なVPLSフルメッシュで接続されています。各VPLSサービスのために、単一のPWがMTU-Sおよび[RFC4447]に基づいて、PE-RSの間に設定されているスポーク。物理的（またはVLANタグ付き論理）ポートで終端する従来のPWとは異なり、スポークPWは、（VSI; L2FRAME]参照）、仮想スイッチインスタンスで終端MTU-SおよびPE-RSデバイスで。
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.
MTU-SおよびPE-RSは、各VPLSサービスのACのような接続をスポーク扱います。 PWラベルは、VPLSインスタンスへのスポークからのトラフィックを関連付けるために使用されます。
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間のトラフィックは、PE-RSにスポークの容量を節約、MTU-sがローカルにスイッチされます。同様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は可能な架橋されているので、単一のPWは、同じVPLSサービスにアクセス接続の任意の数のVPLSインスタンスごとに必要とされます。これにより、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イン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カプセル化をサポートするデバイスです。上記のように、すなわち、それは、基本的なVPLSのために記載されているすべての機能をサポートします。
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からスポークは、仮想ポートとして扱われ、それがMACアドレスを学習した後PE-RSは、スポークPW、ハブのPW、および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.
スポークの接続には、いくつかのスケーリングおよび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サービスに参加するすべてのデバイス間のサービスごとのPWのフルメッシュのフルメッシュが不要になります。
- Minimizes signaling overhead, since fewer PWs are required for the VPLS service.
- 少数のPWがVPLSサービスのために必要とされるので、シグナリングオーバーヘッドを最小化。
- 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結節発見。それは、複数のデバイスにまたがるVPLSサービスに参加しているがMTU-Sは、唯一のPE-RSノードを認識する必要があります。一方、すべてのPE-RSが他のすべてのVPLS PE-RSとローカルに接続されたMTU-SおよびPE-R装置の全てを知っていなければならないVPLS。
- 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.
より多くのデバイスは、VPLSに参加して、学習と複製のための能力を必要とするより多くのデバイスがあることに注意してください。
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-RSは展開されないことがあり、または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つの顧客サイトは、PE-Rを介してVPLSにCE-1、CE-2及びCE-3を介して接続されています。 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
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間のPWを設定することが可能です。 VPLSサービスでサポートされているすべてのポートに対して、PWは、PE-RSにPE-rから設定されています。 PWのが設定されると、PE-Rの一部に必要な一切の学習やレプリケーション機能はありません。 ACのいずれかで受信したすべてのトラフィックは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.
代わりのPWの、PE1-RSはそのように扱い、それらの間の橋渡し支援を提供するために、VPLSドメインにこれらの「回路」をマッピングすることができるデマルチプレクサとしてPE-RデバイスがプロバイダーのVLAN（P-VLAN）を使用する場合のことに注意してください。
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.
PWは、MTU-Sが使用されている（かかわらずのACS）サービスごとに必要単一PWに対するサービスに参加するすべてのACのために必要とされるので、このアプローチは、架橋可能な（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-sからの接続の全損失を回避するために提供することができる方法を記載しています。説明されたメカニズムは、両方のために同じ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において、二つの顧客サイトは、MTU-SへのCE-1およびCE-2を介して接続されています。それぞれのための2つのPW（1 PE1-RSおよびPE3-RSにそれぞれ）最大MTU-Sセットは、VPLSインスタンス。 2つのPWの一つは、一次として指定され、第二のPWをセカンダリとして指定され、スタンバイ状態に保持されるのに対し、積極的に、通常の条件下で使用されるものです。 MTU-sがプライマリとセカンダリの両方のPWsのためのPWラベルを交渉したが、主なPWに障害が発生しない限り、セカンダリPWを使用していません。スポークは、プライマリまたはセカンダリ指定されているどのようにこの文書の範囲外です。例えば、唯一のMTU-S二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デバイスにスポークの使用を制御すべきです。スポークがPWをしている場合は、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
プライマリPW、MTU-Sの故障時に直ちに二次PWに切り替わります。この時点で、セカンダリPWを終了PE3-RSはスポークPWにMACアドレスを学習開始します。ネットワーク内の他のすべてのPE-RSノードは、CE-1およびCE-2はPE1-RSの背後にいて、彼らはデバイスがPE3-RSの後ろになっていることを学ぶまで、PE1-RSにトラフィックを送信し続ける可能性があると思います。未学習プロセスは時間がかかることがありますし、悪CE1とCE2から高レベルプロトコルの接続性に影響を与える可能性があります。 （セクション6.2で説明したように）より速い収束を可能にするために、二次PWが活性化しまっPE3-RSはMACリストを用いて、フラッシュメッセージを送信することができます
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.
TLV、すべてのPE-RSノードに、セクション6で定義された通りです。メッセージを受信すると、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対応デバイスとの間のフルメッシュ接続性を必要とすることなく、複数のドメインにまたがるサービスを作成するために使用することができます。二つフルメッシュVPLSネットワークがVPLS「境界」デバイスとの間の単一のLSPトンネルを使用して互いに接続されています。 VPLSサービスごとに単一のスポーク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.
以上の2つのドメインが接続する必要がある場合は、ドメイン間のスポークのフルメッシュは境界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-RS間のフルメッシュトポロジ、および国境PE間の相互ドメインスポークのフルメッシュを作成します-rsデバイス。
This document does not specify how redundant border PEs per domain per VPLS instance can be supported.
この文書では、VPLSインスタンスごとにドメインごとのPEがサポートすることができますどのように冗長国境指定されていません。
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サービスを提供するために、いくつかのサービスプロバイダによって展開されていることです。したがって、これらのネットワークは、スケーラブルなVPLSサービスを提供するために、IPまたはMPLSコアと統合することを可能にするメカニズムを提供することが重要です。
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].
イーサネット（登録商標）アクセスネットワークを介して顧客のイーサネットトラフィックをトンネリングの一つのアプローチは、（タグ付き又はタグなしのいずれかであってもよい）、顧客のデータに追加の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-のニーズは、P-VLANに顧客のVLAN（C-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は、アクセスネットワークに向かって、ならびにネットワーク・コアに向かってのPW上標準のイーサネットポートを介してブリッジング機能を実行できるようにする必要があります。このモデルでは、PE-RSは、MPLSコア上で、地平線を分割するだけでなく、アクセスネットワークに向けてSTPを実行する必要があるかもしれません。 PE-RSはVPLSインスタンスおよびその関連のPW、及びその逆にP-VLANをマッピングする必要があります。
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インQメッセージ、顧客のイーサネット制御プロトコル処理などのカプセル化フォーマット）は、この文書の範囲外であり、[802.1ad]で覆われています。しかし、関連する部分は、ブリッジモジュールと普通のVPLSのように振る舞うPE-RSにおけるMPLS / IPのPWとの間の相互作用です。
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を有する場合、その後のPWの専用フルメッシュは、その島のSP BPDUパケットを搬送するため、これらのPE-RSのデバイス間で使用されています。毎P-VLANに基づいて、STPは、コアを横切ってトラフィックを伝送するために使用される単一PE-RSを指定します。コアを介してループフリー保護は、スプリットホライズンを使用して行われ、コアの故障保護は、標準的な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
ロア・アンダーソン、TLAロン・ハーバーマン、アルカテル・ルーセントユハHeinanen、独立ジャイルズヘロン、テラブススニルKhandekar、アルカテル・ルーセントルカ・マルティーニ、シスコパスカルメネゼス、独立したロブ・ナス、アルカテル・ルーセントエリックPuetz、AT＆TバシレRadoaca、独立アリSajassi、シスコYetik Serbest、AT＆TニックSlabakov、ジュニパーアンドリュー・スミス、コンサルタントトムすぐに、AT＆Tニックチンクル、アルカテル・ルーセント
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.
我々はジョー・リーガン、Kireeti Kompella、アヌープGhanwani、ジョエル・ハルパーン、ビル・香港、リック・ワイルダー、ジム・ギシャール、スティーブ・フィリップス、ノーム・フィン、マット・スクワイア、宗悦鈴木、ヴァルデマーアウグスティン、エリック・ローゼン、ヤコフ・レックター、サーシャVainshtein、そして感謝したいです彼らの貴重なフィードバックのための杜Wenhua。
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.
また、相互運用性テストの過程でドラフトの問題を識別するためのラジブPapneja（ISOCORE）、ウィンストン・劉（イクシア）、およびチャーリーHundallに感謝したいと思います。
We would also like to thank Ina Minei, Bob Thomas, Eric Gray and Dimitri Papadimitriou for their thorough technical review of the document.
我々はまた、ドキュメントの彼らの徹底的な技術的検討のために伊那Minei、ボブ・トーマス、エリックグレーとディミトリPapadimitriouに感謝したいと思います。
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.
L2VPNに関連するセキュリティ問題のより包括的な説明は[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.
- 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.
- ブロードキャストストームを防止することは、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.
- 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.
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]、L.、ローゼン、E.、エル・Aawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（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]マティーニ、L.、ローゼン、E.、エル・Aawar、N.、およびG.サギ、 "MPLSネットワーク上のイーサネットの輸送のためのカプセル化方法"、RFC 4448、2006年4月。
[802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges".
[802.1D-ORIG]オリジナル802.1D - ISO / IEC 10038、ANSI / IEEE規格802.1D-1993 "MACブリッジ"。
[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 / IECの改訂版であります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]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーションに擬似回線縁（PWE3）のためのIANAの割り当て"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、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.、 "PEベースのVPN発見のためのRADIUSを使用して、" ウェーバー、G.編、Townsley、W.、ブース、S.、およびW.羅、進行中で働いて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.
[BGP-DISC]ウルド-Brahimの、H.編、ローゼン、E.、編、およびY. Rekhter、エド。、進行中の作業 "ネットワークベースのVPNの自動検出機構としてBGPを使用します" 、2006年9月。
[L2FRAME] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[L2FRAME]アンデション、L.およびE.ローゼン、 "レイヤのためのフレームワーク2個の仮想プライベートネットワーク（のL2VPN）"、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.
[L2VPN-REQ]アウグスティン、W.およびY. Serbest、 "レイヤーのためのサービスの要件2プロバイダ・プロビジョニングされた仮想プライベートネットワーク"、RFC 4665、2006年9月。
[RFC4111] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4111]牙、L.、 "セキュリティフレームワークプロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）について"、RFC 4111、2005年7月。
[802.1ad] "IEEE standard for Provider Bridges", Work in Progress, December 2002.
[802.1ad]「プロバイダブリッジのためのIEEE標準」、進歩、2002年12月に作業。
Appendix A. VPLS Signaling using the PWid FEC Element
PWID FEC要素を使用して付録A. VPLSシグナリング
This section is being retained because live deployments use this version of the signaling for VPLS.
ライブ展開が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が含ま下流迷惑モードで送信Label Mappingメッセージで運ばれます。
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において、我々は、エミュレートされたLANセグメントを識別するために（PWID FECを使用した場合、VPLSの範囲を拡張対処するために、より一般的な識別子（AGI）で置換された、）VCIDを使用します。 [RFC4447]で指定されるようにVCIDがポイントツーポイント仮想回線をエミュレートするサービスを識別するサービス識別子であることに留意されたいです。 VPLSでは、VCIDは、単一のサービス識別子であるので、VPLSインスタンスに関係するすべてのPE間でグローバルな意味を持っています。
Authors' Addresses
著者のアドレス
Marc Lasserre Alcatel-Lucent EMail: mlasserre@alcatel-lucent.com
マルク・Lasserreアルカテル・ルーセントEメール：mlasserre@alcatel-lucent.com
Vach Kompella Alcatel-Lucent EMail: vach.kompella@alcatel-lucent.com
VACH Kompellaアルカテル・ルーセントEメール：vach.kompella@alcatel-lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。