[要約] RFC 6624は、BGPを使用した自動検出とシグナリングのためのLayer 2仮想プライベートネットワークに関するものです。このRFCの目的は、BGPを使用して効率的かつ自動的にLayer 2 VPNを構築するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 6624 Juniper Networks
Category: Informational B. Kothari
ISSN: 2070-1721 Cisco Systems
R. Cherukuri
Juniper Networks
May 2012
Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling
自動検出とシグナリングにBGPを使用するレイヤー2仮想プライベートネットワーク
Abstract
概要
Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services.
フレームリレーまたはATM回線に基づくレイヤ2バーチャルプライベートネットワーク（L2VPN）は、長い間使用されてきました。最近では、仮想プライベートLANサービスを含むイーサネットVPNが普及しています。従来のL2VPNでは、多くの場合、タイプごとに個別のサービスプロバイダーインフラストラクチャが必要でしたが、インターネットとIP VPNにはもう1つ必要です。さらに、L2VPNプロビジョニングは面倒でした。このドキュメントでは、L2VPNサービスの提供に関する問題への新しいアプローチを紹介します。L2VPNカスタマーのエクスペリエンスは従来のL2VPNによって提供されるものと実質的に同じですが、サービスプロバイダーはL2VPN、IP VPN、およびインターネット用の単一のネットワークを維持できます。すべてのサービスに共通のプロビジョニング方法論も同様です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6624.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6624で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................6
1.1.1. Conventions Used in This Document ...................6
1.2. Advantages of Layer 2 VPNs .................................6
1.2.1. Separation of Administrative Responsibilities .......7
1.2.2. Migrating from Traditional Layer 2 VPNs .............7
1.2.3. Privacy of Routing ..................................7
1.2.4. Layer 3 Independence ................................7
1.2.5. PE Scaling ..........................................8
1.2.6. Ease of Configuration ...............................8
1.3. Advantages of Layer 3 VPNs .................................9
1.3.1. Layer 2 Independence ................................9
1.3.2. SP Routing as Added Value ..........................10
1.3.3. Class of Service ...................................10
1.4. Multicast Routing .........................................10
2. Operation of a Layer 2 VPN .....................................11
2.1. Network Topology ..........................................11
2.2. Configuration .............................................13
2.2.1. CE Configuration ...................................14
2.2.2. PE Configuration ...................................15
2.2.3. Adding a New Site ..................................15
2.2.4. Deleting a Site ....................................16
2.2.5. Managing CE ID Mappings ............................16
2.2.6. Managing Label Blocks ..............................16
2.3. Operations, Administration, and Maintenance (OAM) .........17
3. PE Information Exchange ........................................17
3.1. Circuit Status Vector .....................................19
3.2. Generalizing the VPN Topology .............................20
4. Layer 2 Interworking ...........................................21
5. Packet Transport ...............................................22
5.1. Layer 2 MTU ...............................................22
5.2. Layer 2 Frame Format ......................................22
5.3. IP-Only Layer 2 Interworking ..............................23
6. Security Considerations ........................................23
7. IANA Considerations ............................................23
8. Acknowledgments ................................................24
9. Contributors ...................................................24
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................25
The earliest Virtual Private Networks (VPNs) were based on Layer 2 circuits: X.25, Frame Relay, and ATM (see [Kosiur]). More recently, multipoint VPNs based on Ethernet Virtual Local Area Networks (VLANs) and Virtual Private LAN Service (VPLS) [RFC4761][RFC4762] have become quite popular. In contrast, the VPNs described in this document are point-to-point, and usually called Virtual Private Wire Service (VPWS). All of these come under the classification of Layer 2 VPNs (L2VPNs), as the customer-to-Service-Provider hand-off is at Layer 2.
初期の仮想プライベートネットワーク（VPN）は、レイヤー2回路（X.25、フレームリレー、ATM）に基づいていました（[Kosiur]を参照）。最近では、イーサネット仮想ローカルエリアネットワーク（VLAN）と仮想プライベートLANサービス（VPLS）[RFC4761] [RFC4762]に基づくマルチポイントVPNが非常に一般的になっています。対照的に、このドキュメントで説明するVPNはポイントツーポイントであり、通常はVirtual Private Wire Service（VPWS）と呼ばれます。カスタマーからサービスプロバイダーへのハンドオフはレイヤ2で行われるため、これらすべてがレイヤ2 VPN（L2VPN）の分類に分類されます。
There are at least two factors that adversely affected the cost of offering L2VPNs. The first is that the easiest way to offer an L2VPN of a given type of Layer 2 was over an infrastructure of the same type. This approach required that the Service Provider build a separate infrastructure for each Layer 2 encapsulation, e.g., an ATM infrastructure for ATM VPNs, an Ethernet infrastructure for Ethernet VPNs, etc. In addition, a separate infrastructure was needed for the Internet and IP VPNs [RFC4364], and possibly yet another for voice services. Going down this path meant a proliferation of networks.
L2VPNを提供するコストに悪影響を及ぼす少なくとも2つの要因があります。 1つ目は、特定のタイプのレイヤー2のL2VPNを提供する最も簡単な方法は、同じタイプのインフラストラクチャを経由することでした。このアプローチでは、サービスプロバイダーがレイヤ2カプセル化ごとに個別のインフラストラクチャを構築する必要がありました。たとえば、ATM VPNのATMインフラストラクチャ、イーサネットVPNのイーサネットインフラストラクチャなどです。さらに、インターネットとIP VPNには個別のインフラストラクチャが必要でした。 RFC4364]、そしておそらく音声サービスのためのさらに別のもの。この道を進むことはネットワークの急増を意味しました。
The other is that each of these networks had different provisioning methodologies. Furthermore, the provisioning of an L2VPN was fairly complex. It is important to distinguish between a single Layer 2 circuit, which connects two customer sites, and a Layer 2 VPN, which is a set of circuits that connect sites belonging to the same customer. The fact that two different circuits belonged to the same VPN was typically known only to the provisioning system, not to the switches offering the service; this complicated the setting up, and subsequently, the troubleshooting, of an L2VPN. Also, each switch offering the service had to be provisioned with the address of every other switch in the same VPN, requiring, in the case of full-mesh VPN connectivity, provisioning proportional to the square of the number of sites. This made full-mesh L2VPN connectivity prohibitively expensive for the Service Provider (SP) and thus also for customers. Finally, even setting up an individual circuit often required the provisioning of every switch along the path.
もう1つは、これらのネットワークのそれぞれに異なるプロビジョニング方法があったことです。さらに、L2VPNのプロビジョニングはかなり複雑でした。 2つのカスタマーサイトを接続する単一のレイヤ2回線と、同じカスタマーに属するサイトを接続する一連の回線であるレイヤ2 VPNを区別することが重要です。 2つの異なる回線が同じVPNに属していたという事実は、通常、サービスを提供するスイッチではなく、プロビジョニングシステムにのみ知られていました。これにより、L2VPNの設定、およびその後のトラブルシューティングが複雑になりました。また、サービスを提供する各スイッチには、同じVPN内の他のすべてのスイッチのアドレスをプロビジョニングする必要があり、フルメッシュVPN接続の場合は、サイト数の2乗に比例したプロビジョニングが必要です。これにより、フルメッシュのL2VPN接続は、サービスプロバイダー（SP）にとって、ひいては顧客にとっても非常に高価なものになりました。最後に、個別の回線をセットアップする場合でも、パスに沿ったすべてのスイッチのプロビジョニングが必要になることがよくあります。
Of late, there has been much progress in network "convergence", whereby Layer 2 traffic, Internet traffic, and IP VPN traffic can be carried over a single, consolidated network infrastructure based on IP/MPLS tunnels; this is made possible by techniques such as those described in [RFC4448], [RFC4618], [RFC4619], and [RFC4717] for Layer 2 traffic and in [RFC4364] for IP VPN traffic. This development goes a long way toward addressing the problem of network proliferation. This document goes one step further and shows how a Service Provider can offer Layer 2 VPNs using protocol and provisioning methodologies similar to that used for VPLS [RFC4761] and IP VPNs [RFC4364], thereby achieving a significant degree of operational convergence as well. In particular, all of these methodologies include the notion of a VPN identifier that serves to unify components of a given VPN and the concept of auto-discovery, which simplifies the provisioning of dense VPN topologies (for example, a full mesh). In addition, similar techniques are used in all of the above-mentioned VPN technologies to offer inter-AS and inter-provider VPNs (i.e., VPNs whose sites are connected to multiple Autonomous Systems (ASes) or Service Providers).
最近、ネットワークの「コンバージェンス」が大幅に進歩し、レイヤー2トラフィック、インターネットトラフィック、およびIP VPNトラフィックを、IP / MPLSトンネルに基づく単一の統合ネットワークインフラストラクチャ上で伝送できるようになりました。これは、レイヤー2トラフィックの場合は[RFC4448]、[RFC4618]、[RFC4619]、および[RFC4717]で、IP VPNトラフィックの場合は[RFC4364]で説明されているような手法によって可能になります。この開発は、ネットワークの急増の問題に対処するための長い道のりです。このドキュメントではさらに一歩進んで、サービスプロバイダーがVPLS [RFC4761]とIP VPN [RFC4364]で使用されているのと同様のプロトコルとプロビジョニングの方法論を使用してレイヤ2 VPNを提供し、それによってかなりの程度の運用上のコンバージェンスを実現する方法を示します。特に、これらのすべての方法には、特定のVPNのコンポーネントを統合するVPN識別子の概念と、高密度VPNトポロジ（たとえば、フルメッシュ）のプロビジョニングを簡素化する自動検出の概念が含まれます。さらに、上記のすべてのVPNテクノロジーで同様の手法を使用して、AS間およびプロバイダー間VPN（つまり、サイトが複数の自律システム（AS）またはサービスプロバイダーに接続されているVPN）を提供します。
Technically, the approach proposed here uses the concepts and solution described in [RFC4761], which describes a method for VPLS, a particular form of a Layer 2 VPN. That document, in turn, borrowed much from [RFC4364], including the use of BGP for auto-discovery and "demultiplexor" (see below) exchange and the concepts of Route Distinguishers to make VPN advertisements unique and Route Targets to control VPN topology. In addition, all three documents share the idea that routers not directly connected to VPN customers should carry no VPN state, restricting the provisioning of individual connections to just the edge devices. This is achieved using tunnels to carry the data, with a demultiplexor that identifies individual VPN circuits. These tunnels could be based on MPLS, GRE, or any other tunnel technology that offers a demultiplexing field; the signaling of these tunnels is outside the scope of this document. The specific approach taken here is to use an MPLS label as the demultiplexor.
技術的には、ここで提案されているアプローチは、[RFC4761]で説明されている概念とソリューションを使用しています。これは、レイヤ2 VPNの特定の形式であるVPLSの方法を説明しています。そのドキュメントは、[RFC4364]から多くを借用しました。これには、自動検出および「デマルチプレクサ」交換（以下を参照）のためのBGPの使用、およびVPNアドバタイズを一意にするためのルート識別子およびVPNトポロジを制御するためのルートターゲットの概念が含まれます。さらに、3つすべてのドキュメントは、VPNカスタマーに直接接続されていないルーターはVPN状態を持たず、個々の接続のプロビジョニングをエッジデバイスのみに制限するという考えを共有しています。これは、トンネルを使用してデータを伝送し、個々のVPN回線を識別するデマルチプレクサーで実現されます。これらのトンネルは、MPLS、GRE、または逆多重化フィールドを提供するその他のトンネル技術に基づくことができます。これらのトンネルのシグナリングは、このドキュメントの範囲外です。ここで採用されている具体的なアプローチは、MPLSラベルをデマルチプレクサとして使用することです。
Layer 2 VPNs typically require that all sites in the VPN connect to the SP with the same Layer 2 encapsulation. To ease this restriction, this document proposes a limited form of Layer 2 interworking, by restricting the Layer 3 protocol to IP only (see Section 4).
レイヤー2 VPNでは、通常、VPN内のすべてのサイトが同じレイヤー2カプセル化でSPに接続する必要があります。この制限を緩和するために、このドキュメントでは、レイヤー3プロトコルをIPのみに制限することにより、レイヤー2インターワーキングの制限された形式を提案しています（セクション4を参照）。
It may be instructive to compare the approach described in [RFC4447] and [RFC6074] (these are the IETF-approved technologies for the functions described in this document, albeit using two separate protocols) with the one described here. To comply with IETF standards, it is recommended that devices implementing the solution described in this document also implement the approach in [RFC4447] and [RFC6074].
[RFC4447]と[RFC6074]で説明されているアプローチ（これらは、2つの個別のプロトコルを使用していますが、このドキュメントで説明されている機能についてIETF承認のテクノロジです）と、ここで説明されているものを比較することは有益です。 IETF標準に準拠するには、このドキュメントで説明されているソリューションを実装するデバイスが[RFC4447]と[RFC6074]のアプローチも実装することをお勧めします。
The rest of this section discusses the relative merits of Layer 2 and Layer 3 VPNs. Section 2 describes the operation of a Layer 2 VPN. Section 3 describes PE information exchange. Section 4 describes IP-only Layer 2 interworking. Section 5 describes how the L2 packets are transported across the SP network.
このセクションの残りの部分では、レイヤー2およびレイヤー3 VPNの相対的なメリットについて説明します。セクション2では、レイヤ2 VPNの動作について説明します。セクション3では、PE情報交換について説明します。セクション4では、IPのみのレイヤ2インターワーキングについて説明します。セクション5では、L2パケットがSPネットワークを介して転送される方法について説明します。
The terminology used is from [RFC4761] and [RFC4364]; it is briefly repeated here. A "customer" is a customer of a Service Provider seeking to interconnect their various "sites" (each an independent network) at Layer 2 through the Service Provider's network, while maintaining privacy of communication and address space. The device in a customer site that connects to a Service Provider router is termed the CE (customer edge) device; this device may be a router or a switch. The Service Provider router to which a CE connects is termed a PE (provider edge). A router in the Service Provider's network that doesn't connect directly to any CE is termed P ("provider" device). Every pair of PEs is connected by a "tunnel"; within a tunnel, VPN data is distinguished by a "demultiplexor", which in this document is an MPLS label.
使用されている用語は[RFC4761]と[RFC4364]からのものです。ここで簡単に繰り返します。 「顧客」とは、通信とアドレス空間のプライバシーを維持しながら、サービスプロバイダーのネットワークを通じてレイヤ2でさまざまな「サイト」（それぞれ独立したネットワーク）を相互接続することを求めるサービスプロバイダーの顧客です。サービスプロバイダーのルータに接続するカスタマーサイトのデバイスは、CE（カスタマーエッジ）デバイスと呼ばれます。このデバイスは、ルーターまたはスイッチです。 CEが接続するサービスプロバイダールータは、PE（プロバイダーエッジ）と呼ばれます。 CEに直接接続しないサービスプロバイダーのネットワーク内のルーターは、P（「プロバイダー」デバイス）と呼ばれます。 PEのすべてのペアは「トンネル」によって接続されます。トンネル内では、VPNデータは「デマルチプレクサ」によって区別されます。これは、このドキュメントではMPLSラベルです。
Each CE within a VPN is assigned a CE ID, a number that uniquely identifies a CE within an L2VPN. More accurately, the CE ID identifies a physical connection from the CE device to the PE, since a CE may be connected to multiple PEs (or multiply connected to a PE); in such a case, the CE would have a CE ID for each connection. A CE may also be part of many L2VPNs; it would need one (or more) CE ID(s) for each L2VPN of which it is a member. The number space for CE IDs is scoped to a given VPN.
VPN内の各CEには、L2VPN内のCEを一意に識別する番号であるCE IDが割り当てられています。より正確には、CEは複数のPEに接続できる（またはPEに複数接続できる）ため、CE IDはCEデバイスからPEへの物理接続を識別します。このような場合、CEは接続ごとにCE IDを持っています。 CEは多くのL2VPNの一部であることもあります。メンバーとなっているL2VPNごとに1つ（または複数）のCE IDが必要です。 CE IDの番号スペースは、特定のVPNをスコープとしています。
In the case of inter-provider L2VPNs, there needs to be some coordination of allocation of CE IDs. One solution is to allocate ranges for each SP. Other solutions may be forthcoming.
プロバイダー間L2VPNの場合、CE IDの割り当てを調整する必要があります。 1つの解決策は、各SPに範囲を割り当てることです。他の解決策が近づいているかもしれません。
Within each physical connection from a CE to a PE, there may be multiple virtual circuits. These will be referred to as Attachment Circuits (ACs), following [RFC3985]. Similarly, the entity that connects two attachment circuits across the Service Provider network is called a pseudowire (PW).
CEからPEへの各物理接続内には、複数の仮想回線が存在する場合があります。これらは、[RFC3985]に続き、接続回路（AC）と呼ばれます。同様に、サービスプロバイダーネットワーク全体で2つの接続回線を接続するエンティティは、疑似配線（PW）と呼ばれます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
A Layer 2 VPN is one where a Service Provider provides Layer 2 connectivity to the customer. The Service Provider does not participate in the customer's Layer 3 network, especially in the routing, resulting in several advantages to the SP as a whole and to PE routers in particular.
レイヤー2 VPNは、サービスプロバイダーがカスタマーにレイヤー2接続を提供するVPNです。サービスプロバイダーは顧客のレイヤ3ネットワーク、特にルーティングに参加しないため、SP全体、特にPEルータにとっていくつかの利点があります。
In a Layer 2 VPN, the Service Provider is responsible for Layer 2 connectivity; the customer is responsible for Layer 3 connectivity, which includes routing. If the customer says that host x in site A cannot reach host y in site B, the Service Provider need only demonstrate that site A is connected to site B. The details of how routes for host y reach host x are the customer's responsibility.
レイヤ2 VPNでは、サービスプロバイダーがレイヤ2接続を担当します。お客様は、ルーティングを含むレイヤ3接続を担当します。サイトAのホストxがサイトBのホストyに到達できないと顧客が言った場合、サービスプロバイダーはサイトAがサイトBに接続されていることを示すだけで済みます。ホストyのルートがホストxに到達する方法の詳細は、顧客の責任です。
Another important factor is that once a PE provides Layer 2 connectivity to its connected CE, its job is done. A misbehaving CE can at worst flap its interface, but route flaps in the customer network have little effect on the SP network. On the other hand, a misbehaving CE in a Layer 3 VPN can flap its routes, leading to instability of the PE router or even the entire SP network. Thus, when offering a Layer 3 VPN, an SP should proactively protect itself from Layer 3 instability in the CE network.
別の重要な要素は、PEが接続されたCEへのレイヤー2接続を提供すると、その仕事が完了することです。動作に問題のあるCEは、最悪の場合、そのインターフェイスをフラップできますが、カスタマーネットワークのルートフラップは、SPネットワークにほとんど影響しません。一方、レイヤ3 VPN内の動作が正しくないCEはルートをフラップし、PEルータまたはSPネットワーク全体を不安定にする可能性があります。したがって、レイヤー3 VPNを提供する場合、SPはCEネットワークのレイヤー3の不安定性からプロアクティブに保護する必要があります。
Since "traditional" Layer 2 VPNs (i.e., real Frame Relay circuits connecting sites) are indistinguishable from tunnel-based VPNs from the customer's point of view, migrating from one to the other raises few issues. Layer 3 VPNs, on the other hand, require a considerable redesign of the customer's Layer 3 routing architecture. Furthermore, with Layer 3 VPNs, special care has to be taken that routes within the traditional VPN are not preferred over the Layer 3 VPN routes (the so-called "backdoor routing" problem, whose solution requires protocol changes that are somewhat ad hoc).
「従来の」レイヤー2 VPN（つまり、サイトを接続する実際のフレームリレー回路）は、顧客の観点からはトンネルベースのVPNと区別がつかないため、一方から他方に移行しても問題はほとんど発生しません。一方、レイヤ3 VPNでは、顧客のレイヤ3ルーティングアーキテクチャを大幅に再設計する必要があります。さらに、レイヤー3 VPNでは、従来のVPN内のルートがレイヤー3 VPNルートよりも優先されないように特別な注意を払う必要があります（いわゆる「バックドアルーティング」問題。 。
In an L2VPN, the privacy of customer routing is a natural fallout of the fact that the Service Provider does not participate in routing. The SP routers need not do anything special to keep customer routes separate from other customers or from the Internet; there is no need for per-VPN routing tables and the additional complexity this imposes on PE routers.
L2VPNでは、カスタマールーティングのプライバシーは、サービスプロバイダーがルーティングに参加しないという事実の自然な結果です。 SPルーターは、顧客のルートを他の顧客やインターネットから分離するために特別なことをする必要はありません。 VPNごとのルーティングテーブルは必要ありません。これにより、PEルーターに課せられる複雑さが増します。
Since the Service Provider simply provides Layer 2 connectivity, the customer can run any Layer 3 protocols they choose. If the SP were participating in customer routing, it would be vital that the customer and SP both use the same Layer 3 protocol(s) and routing protocols.
サービスプロバイダーはレイヤ2接続を提供するだけなので、顧客は選択した任意のレイヤ3プロトコルを実行できます。 SPがカスタマールーティングに参加している場合、カスタマーとSPの両方が同じレイヤ3プロトコルとルーティングプロトコルを使用することが重要です。
Note that IP-only Layer 2 interworking doesn't have this benefit as it restricts the Layer 3 to IP only.
IPのみのレイヤー2インターワーキングは、レイヤー3をIPのみに制限するため、この利点がないことに注意してください。
In the Layer 2 VPN scheme described below, each PE transmits a single small chunk of information about every CE that the PE is connected to every other PE. That means that each PE need only maintain a single chunk of information from each CE in each VPN and keep a single "route" to every site in every VPN. This means that both the Forwarding Information Base and the Routing Information Base scale well with the number of sites and number of VPNs. Furthermore, the scaling properties are independent of the customer: the only germane quantity is the total number of VPN sites.
以下で説明するレイヤ2 VPNスキームでは、各PEは、PEが他のすべてのPEに接続されているすべてのCEに関する単一の小さな情報の塊を送信します。つまり、各PEは、各VPNの各CEからの情報の単一のチャンクのみを維持し、すべてのVPNのすべてのサイトへの単一の「ルート」を維持する必要があります。これは、転送情報ベースとルーティング情報ベースの両方が、サイトの数とVPNの数に対応できることを意味します。さらに、スケーリングのプロパティは顧客とは無関係です。唯一の適切な量は、VPNサイトの総数です。
This is to be contrasted with Layer 3 VPNs, where each CE in a VPN may have an arbitrary number of routes that need to be carried by the SP. This leads to two issues. First, both the information stored at each PE and the number of routes installed by the PE for a CE in a VPN can be (in principle) unbounded, which means in practice that a PE must restrict itself to installing routes associated with the VPNs of which it is currently a member. Second, a CE can send a large number of routes to its PE, which means that the PE must protect itself against such a condition. Thus, the SP must enforce limits on the number of routes accepted from a CE; this, in turn, requires the PE router to offer such control.
これは、VPNの各CEが、SPが運ぶ必要のある任意の数のルートを持つことができるレイヤー3 VPNと対照的です。これは2つの問題につながります。まず、各PEに格納されている情報と、PEによってVPNのCEにインストールされたルートの数の両方を（原則として）制限なしにすることができます。つまり、実際には、PEは自身のVPNに関連付けられたルートのインストールに制限する必要があります。現在メンバーです。第2に、CEはそのPEに多数のルートを送信できます。つまり、PEはそのような状況から自分自身を保護する必要があります。したがって、SPはCEから受け入れるルートの数に制限を適用する必要があります。これには、PEルータがそのような制御を提供することが必要です。
The scaling issues of Layer 3 VPNs come into sharp focus at a BGP route reflector (RR). An RR cannot keep all the advertised routes in every VPN since the number of routes will be too large. The following solutions/extensions are needed to address this issue:
レイヤ3 VPNのスケーリングの問題は、BGPルートリフレクタ（RR）に重点を置いています。ルートの数が多すぎるため、RRはすべてのアドバタイズされたルートをすべてのVPNに保持できません。この問題に対処するには、次のソリューション/拡張機能が必要です。
1. RRs could be partitioned so that each RR services a subset of VPNs so that no single RR has to carry all the routes.
1. RRを分割して、各RRがVPNのサブセットにサービスを提供し、単一のRRがすべてのルートを伝送する必要がないようにすることができます。
2. An RR could use a preconfigured list of Route Targets for its inbound route filtering. The RR may choose to perform Route Target Filtering, described in [RFC4684].
2. RRは、インバウンドルートフィルタリングに事前設定されたルートターゲットのリストを使用できます。 RRは、[RFC4684]で説明されているルートターゲットフィルタリングの実行を選択できます。
Configuring traditional Layer 2 VPNs with dense topologies was a burden primarily because of the O(n*n) nature of the task. If there are n CEs in a Frame Relay VPN, say full-mesh connected, n*(n-1)/2 DLCI (Data Link Connection Identifier) Permanent Virtual Circuits (PVCs) must be provisioned across the SP network. At each CE, (n-1) DLCIs must be configured to reach each of the other CEs. Furthermore, when a new CE is added, n new DLCI PVCs must be provisioned; also, each existing CE must be updated with a new DLCI to reach the new CE. Finally, each PVC requires state in every transit switch.
従来のレイヤ2 VPNを高密度トポロジで構成することは、主にタスクのO（n * n）性質のために負担でした。フレームリレーVPNにn個のCEがある場合、たとえばフルメッシュ接続されている場合、n *（n-1）/ 2 DLCI（データリンク接続識別子）の相手固定接続（PVC）をSPネットワーク全体にプロビジョニングする必要があります。各CEで、他の各CEに到達するように（n-1）DLCIを構成する必要があります。さらに、新しいCEが追加されると、n個の新しいDLCI PVCをプロビジョニングする必要があります。また、新しいCEに到達するには、既存の各CEを新しいDLCIで更新する必要があります。最後に、各PVCはすべての中継スイッチで状態を必要とします。
In our proposal, PVCs are tunneled across the SP network. The tunnels used are provisioned independently of the L2VPNs, using signaling protocols (in the case of MPLS, LDP or RSVP - Traffic Engineering (RSVP-TE) can be used), or set up by configuration; the number of tunnels is independent of the number of L2VPNs. This reduces a large part of the provisioning burden.
私たちの提案では、PVCはSPネットワークを介してトンネリングされます。使用されるトンネルは、シグナリングプロトコルを使用して（MPLS、LDPまたはRSVPの場合はトラフィックエンジニアリング（RSVP-TE）を使用できます）、L2VPNとは別にプロビジョニングされるか、構成によってセットアップされます。トンネルの数はL2VPNの数とは無関係です。これにより、プロビジョニングの負担の大部分が軽減されます。
Furthermore, we assume that DLCIs at the CE edge are relatively cheap and that VPN labels in the SP network are cheap. This allows the SP to "overprovision" VPNs, for example, allocate 50 CEs to a VPN when only 20 are needed. With this overprovisioning, adding a new CE to a VPN requires configuring just the new CE and its associated PE; existing CEs and their PEs need not be reconfigured. Note that if DLCIs at the CE edge are expensive, e.g., if these DLCIs are provisioned across a switched network, one could provision them as and when needed, at the expense of extra configuration. This need not still result in extra state in the SP network, i.e., an intelligent implementation can allow overprovisioning of the pool of VPN labels.
さらに、CEエッジのDLCIは比較的安価であり、SPネットワークのVPNラベルは安価であると想定しています。これにより、SPはVPNを「オーバープロビジョニング」することができます。たとえば、20だけが必要な場合は、VPNに50のCEを割り当てることができます。このオーバープロビジョニングにより、新しいCEをVPNに追加するには、新しいCEとそれに関連付けられたPEのみを構成する必要があります。既存のCEとそのPEを再構成する必要はありません。 CEエッジのDLCIが高価な場合、たとえば、これらのDLCIがスイッチドネットワーク全体にプロビジョニングされる場合、追加の構成を犠牲にして、必要に応じてそれらをプロビジョニングできます。これにより、SPネットワークで追加の状態が発生する必要はありません。つまり、インテリジェントな実装により、VPNラベルのプールのオーバープロビジョニングが可能になります。
Layer 3 VPNs ([RFC4364] in particular) offer a good solution when the customer traffic is wholly IP, customer routing is reasonably simple, and the customer sites connect to the SP with a variety of Layer 2 technologies.
レイヤー3 VPN（特に[RFC4364]）は、カスタマートラフィックが完全にIPであり、カスタマールーティングがかなりシンプルで、カスタマーサイトがさまざまなレイヤー2テクノロジーでSPに接続している場合に、優れたソリューションを提供します。
One major restriction in a Layer 2 VPN is that the Layer 2 media with which the various sites of a single VPN connect to the SP must be uniform. On the other hand, the various sites of a Layer 3 VPN can connect to the SP with any supported media; for example, some sites may connect with Frame Relay circuits and others with Ethernet.
レイヤー2 VPNの1つの主要な制限は、単一のVPNのさまざまなサイトがSPに接続するレイヤー2メディアが均一でなければならないことです。一方、レイヤ3 VPNのさまざまなサイトは、サポートされている任意のメディアを使用してSPに接続できます。たとえば、一部のサイトはフレームリレー回路に接続し、他のサイトはイーサネットに接続する場合があります。
This restriction of Layer 2 VPN is alleviated by the IP-only Layer 2 interworking proposed in this document. This comes at the cost of losing the Layer 3 independence.
レイヤ2 VPNのこの制限は、このドキュメントで提案されているIPのみのレイヤ2インターワーキングによって緩和されます。これには、レイヤー3の独立性が失われるという犠牲が伴います。
A corollary to this is that the number of sites that can be in a Layer 2 VPN is determined by the number of Layer 2 circuits that the Layer 2 technology provides. For example, if the Layer 2 technology is Frame Relay with 2-octet DLCIs, a CE can at most connect to about a thousand other CEs in a VPN.
これの当然の結果は、レイヤー2 VPNに含めることができるサイトの数は、レイヤー2テクノロジーが提供するレイヤー2回路の数によって決定されるということです。たとえば、レイヤ2テクノロジーが2オクテットDLCIを使用するフレームリレーである場合、CEは最大でVPN内の他の約1000のCEに接続できます。
Another problem with Layer 2 VPNs is that the CE router in a VPN must be able to deal with having N routing peers, where N is the number of sites in the VPN. This can be alleviated by manipulating the topology of the VPN. For example, a hub-and-spoke VPN architecture means that only one CE router (the hub) need deal with N neighbors. However, in a Layer 3 VPN, a CE router need only deal with one neighbor, the PE router. Thus, the SP can offer Layer 3 VPNs as a value-added service to its customers.
レイヤー2 VPNのもう1つの問題は、VPN内のCEルーターがN個のルーティングピアを処理できる必要があることです。ここで、NはVPN内のサイトの数です。これは、VPNのトポロジを操作することで軽減できます。たとえば、ハブアンドスポークVPNアーキテクチャでは、1つのCEルーター（ハブ）だけがN個のネイバーを処理する必要があります。ただし、レイヤ3 VPNでは、CEルータは1つのネイバーであるPEルータだけを処理する必要があります。したがって、SPはレイヤー3 VPNを付加価値サービスとして顧客に提供できます。
Moreover, with Layer 2 VPNs, it is up to a customer to build and operate the whole network. With Layer 3 VPNs, a customer is just responsible for building and operating routing within each site, which is likely to be much simpler than building and operating routing for the whole VPN. That, in turn, makes Layer 3 VPNs more suitable for customers who don't have sufficient routing expertise, again allowing the SP to provide added value.
さらに、レイヤー2 VPNを使用する場合、ネットワーク全体を構築して運用するかどうかはお客様次第です。レイヤ3 VPNを使用すると、各サイト内でルーティングを構築および運用する責任は顧客にあります。これは、VPN全体のルーティングを構築および運用するよりもはるかに簡単です。これにより、レイヤ3 VPNは、ルーティングの専門知識が不十分な顧客により適しているため、SPは付加価値を提供できます。
As mentioned later, multicast routing and forwarding is another value-added service that an SP can offer.
後述するように、マルチキャストルーティングと転送は、SPが提供できるもう1つの付加価値サービスです。
Class-of-Service (CoS) issues have been addressed for Layer 3 VPNs. Since the PE router has visibility into the network Layer (IP), the PE router can take on the tasks of CoS classification and routing. This restriction on Layer 2 VPNs is again eased in the case of IP-only Layer 2 interworking, as the PE router has visibility into the network Layer (IP).
レイヤー3 VPNのサービスクラス（CoS）の問題が解決されました。 PEルーターはネットワーク層（IP）を可視化するため、PEルーターはCoS分類とルーティングのタスクを引き受けることができます。 PEルーターがネットワークレイヤー（IP）にアクセスできるため、IPのみのレイヤー2インターワーキングの場合、レイヤー2 VPNに対するこの制限が緩和されます。
There are two aspects to multicast routing that we will consider. On the protocol front, supporting IP multicast in a Layer 3 VPN requires PE routers to participate in the multicast routing instance of the customer and thus keep some related state information.
マルチキャストルーティングには2つの側面があります。プロトコルの面では、レイヤー3 VPNでIPマルチキャストをサポートするには、PEルーターが顧客のマルチキャストルーティングインスタンスに参加し、関連する状態情報を保持する必要があります。
In the Layer 2 VPN case, the CE routers run native multicast routing directly. The SP network just provides pipes to connect the CE routers; PEs are unaware whether the CEs run multicast or not and thus do not have to participate in multicast protocols or keep multicast state information.
レイヤー2 VPNの場合、CEルーターはネイティブマルチキャストルーティングを直接実行します。 SPネットワークは、CEルーターを接続するためのパイプを提供するだけです。 PEは、CEがマルチキャストを実行するかどうかを認識しないため、マルチキャストプロトコルに参加したり、マルチキャストの状態情報を保持したりする必要はありません。
On the forwarding front, in a Layer 3 VPN, CE routers do not replicate multicast packets; thus, the CE-PE link carries only one copy of a multicast packet. Whether replication occurs at the ingress PE or somewhere within the SP network depends on the sophistication of the Layer 3 VPN multicast solution. The simple solution where a PE replicates packets for each of its CEs may place considerable burden on the PE. More complex solutions may require VPN multicast state in the SP network but may significantly reduce the traffic in the SP network by delaying packet replication until needed.
フォワーディングフロントのレイヤ3 VPNでは、CEルータはマルチキャストパケットを複製しません。したがって、CE-PEリンクは、マルチキャストパケットのコピーを1つだけ伝送します。レプリケーションが入力PEで行われるか、SPネットワーク内のどこで行われるかは、レイヤ3 VPNマルチキャストソリューションの高度さに依存します。 PEがCEごとにパケットを複製する単純なソリューションは、PEにかなりの負荷をかける可能性があります。より複雑なソリューションでは、SPネットワークでVPNマルチキャストステートが必要になる場合がありますが、必要になるまでパケットの複製を遅らせることにより、SPネットワークのトラフィックを大幅に削減できます。
In a Layer 2 VPN, packet replication occurs at the CE. This has the advantage of distributing the burden of replication among the CEs rather than focusing it on the PE to which they are attached and thus will scale better. However, the CE-PE link will need to carry multiple copies of multicast packets. However, in the case of Virtual Private LAN Service (a specific type of L2VPN; see [RFC4761]), the CE-PE link need transport only one copy of a multicast packet.
レイヤ2 VPNでは、CEでパケット複製が行われます。これには、CEが接続されているPEに重点を置くのではなく、CE間でレプリケーションの負荷を分散させるという利点があり、スケーリングが向上します。ただし、CE-PEリンクは、マルチキャストパケットの複数のコピーを伝送する必要があります。ただし、仮想プライベートLANサービス（特定のタイプのL2VPN。[RFC4761]を参照）の場合、CE-PEリンクは、マルチキャストパケットのコピーを1つだけ転送する必要があります。
Thus, just as in the case of unicast routing, the SP has the choice to offer a value-added service (multicast routing and forwarding) at some cost (multicast state and packet replication) using a Layer 3 VPN or to keep it simple and use a Layer 2 VPN.
したがって、ユニキャストルーティングの場合と同様に、SPには、レイヤー3 VPNを使用して、付加価値サービス（マルチキャストルーティングと転送）をある程度のコスト（マルチキャストステートとパケットレプリケーション）で提供するか、シンプルかつレイヤー2 VPNを使用します。
The following simple example of a customer with four sites connected to three PE routers in a Service Provider network will hopefully illustrate the various aspects of the operation of a Layer 2 VPN. For simplicity, we assume that a full-mesh topology is desired.
サービスプロバイダーネットワーク内の3つのPEルータに接続された4つのサイトを持つ顧客の次の簡単な例は、レイヤ2 VPNの動作のさまざまな側面を説明するものです。簡単にするために、フルメッシュトポロジが望ましいと仮定します。
In what follows, Frame Relay serves as the Layer 2 media, and each CE has multiple DLCIs to its PE, each connecting to another CE in the VPN. If the Layer 2 media were ATM, then each CE would have multiple VPIs/VCIs (Virtual Path Identifiers/Virtual Channel Identifiers) to connect to other CEs. For Point-to-Point Protocol (PPP) and Cisco High-Level Data Link Control (HDLC), each CE would have multiple physical interfaces to connect to other CEs. In the case of IP-only Layer 2 interworking, each CE could have a mix of one or more of the above Layer 2 media to connect to other CEs.
以下では、フレームリレーがレイヤー2メディアとして機能し、各CEはそのPEに複数のDLCIを持ち、それぞれがVPN内の別のCEに接続しています。レイヤ2メディアがATMの場合、各CEには他のCEに接続するための複数のVPI / VCI（仮想パス識別子/仮想チャネル識別子）があります。ポイントツーポイントプロトコル（PPP）およびシスコのハイレベルデータリンクコントロール（HDLC）の場合、各CEには他のCEに接続するための複数の物理インターフェイスがあります。 IPのみのレイヤー2インターワーキングの場合、各CEは、他のCEに接続するために上記のレイヤー2メディアを1つ以上混在させることができます。
Consider a Service Provider network with edge routers PE0, PE1, and PE2. Assume that PE0 and PE1 are IGP neighbors, and PE2 is more than one hop away from PE0.
エッジルータPE0、PE1、およびPE2を備えたサービスプロバイダーネットワークについて考えてみます。 PE0とPE1がIGPネイバーであり、PE2がPE0から1ホップ以上離れていると仮定します。
Suppose that a customer C has four sites S0, S1, S2, and S3, that C wants to connect via the Service Provider's network using Frame Relay. Site S0 has CE0 and CE1 both connected to PE0. Site S1 has CE2 connected to PE0. Site S2 has CE3 connected to PE1 and CE4 connected to PE2. Site S3 has CE5 connected to PE2. (See Figure 1 below.) Suppose further that C wants to "overprovision" each current site, in expectation that the number of sites will grow to at least 10 in the near future. However, CE4 is only provisioned with nine DLCIs. (Note that the signaling mechanism discussed in Section 3.2 of [RFC4761] will allow a site to grow in terms of connectivity to other sites at a later point of time at the cost of additional signaling, i.e., overprovisioning is not a must but a recommendation).
カスタマーCに4つのサイトS0、S1、S2、およびS3があり、Cがフレームリレーを使用してサービスプロバイダーのネットワーク経由で接続したいとします。サイトS0には、CE0とCE1の両方がPE0に接続されています。サイトS1にはCE2がPE0に接続されています。サイトS2には、PE1に接続されたCE3とPE2に接続されたCE4があります。サイトS3には、PE2に接続されたCE5があります。 （下の図1を参照してください。）さらに、サイトの数が近い将来少なくとも10まで増えることを期待して、Cが現在の各サイトを「オーバープロビジョニング」したいとします。ただし、CE4は9つのDLCIでのみプロビジョニングされます。 （[RFC4761]のセクション3.2で説明されているシグナリングメカニズムでは、追加のシグナリングを犠牲にして、後で他のサイトへの接続性の観点からサイトを拡大できます。つまり、オーバープロビジョニングは必須ではなく、推奨事項です。 ）。
Finally, suppose that the CEs have been provisioned with DLCIs as per the following:
最後に、次のようにCEにDLCIがプロビジョニングされているとします。
CE# | Provisioned DLCIs
--------------------------------------------------------
0 | 100 through 109
1 | 200 through 209
2 | 100 through 109
3 | 200 through 209
4 | 107, 209, 265, 301, 414, 555, 654, 777, and 888
5 | 417 through 426
S0 S3
.............. ..............
. . . .
. +-----+ . . .
. | CE0 |-----------+ . +-----+ .
. +-----+ . | . | CE5 | .
. . | . +--+--+ .
. +-----+ . | . | .
. | CE1 |-------+ | .......|......
. +-----+ . | | /
. . | | /
.............. | | /
| | SP Network /
.....|...|.............................../.....
. | | / .
. +-+---+-+ +-------+ / .
. | PE0 |-------| P |-- | .
. +-+---+-+ +-------+ \ | .
. / \ \ +---+---+ .
. | -----+ --| PE2 | .
. | | +---+---+ .
. | +---+---+ / .
. | | PE1 | / .
. | +---+---+ / .
. | \ / .
...|.............|.............../.............
| | /
| | /
| | /
S1 | | S2 /
.............. | ........|........../......
. . | . | | .
. +-----+ . | . +--+--+ +--+--+ .
. | CE2 |-----+ . | CE3 | | CE4 | .
. +-----+ . . +-----+ +-----+ .
. . . .
.............. ..........................
Figure 1: Example Network Topology
図1：ネットワークトポロジの例
The following sub-sections detail the configuration that is needed to provision the above VPN. For the purpose of exposition, we assume that the customer will connect to the SP with Frame Relay circuits.
次のサブセクションでは、上記のVPNをプロビジョニングするために必要な構成について詳しく説明します。説明のために、お客様はフレームリレー回路を使用してSPに接続すると想定しています。
While we focus primarily on the configuration that an SP has to do, we touch upon the configuration requirements of CEs as well. The main point of contact in CE-PE configuration is that both must agree on the DLCIs that will be used on the interface connecting them.
主にSPが実行する必要がある構成に焦点を当てていますが、CEの構成要件についても触れています。 CE-PE構成の主な連絡先は、両者がそれらを接続するインターフェイスで使用されるDLCIについて合意する必要があることです。
If the PE-CE connection is Frame Relay, it is recommended to run Link Management Interface (LMI) between the PE and CE. For the case of ATM VCs, Operations, Administration, and Maintenance (OAM) cells may be used. For PPP and Cisco HDLC, keepalives may be used directly between CEs; however, in this case, PEs would not have visibility as to the liveness of customers circuits.
PE-CE接続がフレームリレーの場合、PEとCEの間でリンク管理インターフェース（LMI）を実行することをお勧めします。 ATM VCの場合、Operations、Administration、and Maintenance（OAM）セルを使用できます。 PPPおよびCisco HDLCの場合、キープアライブはCE間で直接使用できます。ただし、この場合、PEには顧客の回線の活性度に関する可視性がありません。
In the case of IP-only Layer 2 interworking, if CE1, attached to PE0, connects to CE3, attached to PE1, via an L2VPN circuit, the Layer 2 media between CE1 and PE0 is independent of the Layer 2 media between CE3 and PE1. Each side will run its own Layer-2-specific link management protocol, e.g., LMI, Link Control Protocol (LCP), etc. PE0 will inform PE1 about the status of its local circuit to CE1 via the circuit status vector TLV defined in Section 3.1. Similarly, PE1 will inform PE0 about the status of its local circuit to CE3.
IPのみのレイヤー2インターワーキングの場合、CE1に接続されたCE1が、L2VPN回線を介してPE1に接続されたCE3に接続すると、CE1とPE0の間のレイヤー2メディアは、CE3とPE1の間のレイヤー2メディアから独立しています。 。各サイドは、独自のレイヤー2固有のリンク管理プロトコル（LMI、リンク制御プロトコル（LCP）など）を実行します。PE0は、セクションで定義された回線ステータスベクトルTLVを介して、CE1へのローカル回線のステータスについてPE1に通知します3.1。同様に、PE1はPE3にローカル回線のステータスをPE0に通知します。
Each CE that belongs to a VPN is given a "CE ID". CE IDs must be unique in the context of a VPN. For the example, we assume that the CE ID for CE-k is k.
VPNに属する各CEには「CE ID」が付与されます。 CE IDは、VPNのコンテキストで一意である必要があります。この例では、CE-kのCE IDはkであると想定しています。
Each CE is configured to communicate with its corresponding PE with the set of DLCIs given above, for example, CE0 is configured with DLCIs 100 through 109. In general, a CE is configured with a list of circuits, all with the same Layer 2 encapsulation type, e.g., DLCIs, VCIs, physical PPP interface, etc. (IP-only Layer 2 interworking allows a mix of Layer 2 encapsulation types.) The size of this list/ set determines the number of remote CEs with which a given CE can communicate. Denote the size of this list/set as the CE's range. A CE's range must be at least the number of remote CEs that the CE will connect to in a given VPN; if the range exceeds this, then the CE is overprovisioned, in anticipation of growth of the VPN.
各CEは、上記のDLCIのセットを使用して対応するPEと通信するように構成されます。たとえば、CE0はDLCI 100〜109で構成されます。一般に、CEはすべて同じレイヤー2カプセル化された回路のリストで構成されます。タイプ、たとえば、DLCI、VCI、物理PPPインターフェイスなど（IPのみのレイヤー2インターワーキングでは、レイヤー2カプセル化タイプを混在させることができます。）このリスト/セットのサイズによって、特定のCEが使用できるリモートCEの数が決まりますコミュニケーション。このリスト/セットのサイズをCEの範囲として示します。 CEの範囲は、少なくとも特定のVPNでCEが接続するリモートCEの数でなければなりません。範囲がこれを超えると、VPNの拡大を見越してCEが過剰にプロビジョニングされます。
Each CE also "knows" which DLCI connects it to every other CE. The methodology followed in this example is to use the CE ID of the other CE as an index into the DLCI list this CE has (with zero-based indexing, i.e., 0 is the first index). For example, CE0 is connected to CE3 through its fourth DLCI, 103; CE4 is connected to CE2 by the third DLCI in its list, namely 265. This is just the methodology used in the description here; the actual methodology used to pick the DLCI to be used is a local matter. The key factor is that CE-k may communicate with CE-m using a different DLCI from the DLCI that CE-m uses to communicate to CE-k, i.e., the SP network effectively acts as a giant Frame Relay switch. This is very important, as it decouples the DLCIs used at each CE site, making for much simpler provisioning.
各CEは、どのDLCIが他のすべてのCEに接続するかを「認識」しています。この例で使用されている方法は、他のCEのCE IDを、このCEが持つDLCIリストへのインデックスとして使用することです（ゼロベースのインデックス付け、つまり0が最初のインデックスです）。たとえば、CE0は4番目のDLCI 103を介してCE3に接続されています。 CE4は、リストの3番目のDLCI、つまり265によってCE2に接続されています。これは、ここでの説明で使用されている方法論にすぎません。使用するDLCIを選択するために使用される実際の方法論は、ローカルの問題です。重要な要素は、CE-kがCE-kとの通信に使用するDLCIとは異なるDLCIを使用してCE-kがCE-mと通信できることです。つまり、SPネットワークは効果的に巨大なフレームリレースイッチとして機能します。これは、各CEサイトで使用されるDLCIを分離し、プロビジョニングを大幅に簡素化するため、非常に重要です。
Each PE is configured with the VPNs in which it participates. Each VPN is associated with one or more Route Target communities [RFC4360] that serve to define the topology of the VPN. For each VPN, the PE must determine a Route Distinguisher (RD) to use; this may either be configured or chosen by the PE. RDs do not have to be unique across the VPN. For each CE attached to the PE in a given VPN, the PE must know the set of virtual circuits (DLCI, VCI/VPI, or VLAN) connecting it to the CE and a CE ID identifying the CE within the VPN. CE IDs must be unique in the context of a given VPN.
各PEは、それが参加しているVPNで構成されています。各VPNは、VPNのトポロジを定義するために役立つ1つ以上のルートターゲットコミュニティ[RFC4360]に関連付けられています。各VPNについて、PEは使用するRoute Distinguisher（RD）を決定する必要があります。これは、PEによって構成または選択されます。 RDは、VPN全体で一意である必要はありません。特定のVPNのPEに接続されている各CEについて、PEは、CEに接続する一連の仮想回線（DLCI、VCI / VPI、またはVLAN）と、VPN内のCEを識別するCE IDを知っている必要があります。 CE IDは、特定のVPNのコンテキストで一意である必要があります。
The first step in adding a new site to a VPN is to pick a new CE ID. If all current members of the VPN are overprovisioned, i.e., their range includes the new CE ID, adding the new site is a purely local task. Otherwise, the sites whose range doesn't include the new CE ID and that wish to communicate directly with the new CE must have their ranges increased by allocating additional local circuits to incorporate the new CE ID.
VPNに新しいサイトを追加する最初のステップは、新しいCE IDを選択することです。 VPNの現在のすべてのメンバーがオーバープロビジョニングされている場合、つまり、その範囲に新しいCE IDが含まれている場合、新しいサイトの追加は純粋にローカルなタスクです。そうでない場合、範囲に新しいCE IDが含まれておらず、新しいCEと直接通信したいサイトは、新しいCE IDを組み込むために追加のローカル回線を割り当てることにより、範囲を増やす必要があります。
The next step is ensuring that the new site has the required connectivity. This usually requires adding a new virtual circuit between the PE and CE; in most cases, this configuration is limited to the PE in question.
次のステップは、新しいサイトに必要な接続があることを確認することです。これには通常、PEとCEの間に新しい仮想回線を追加する必要があります。ほとんどの場合、この構成は問題のPEに限定されます。
The rest of the configuration is a local matter between the new CE and the PE to which it is attached. At this point, the PE can signal to other PEs that it has a new site in the VPN by advertising a BGP Layer 2 route, and traffic connectivity will be set up.
残りの構成は、新しいCEとそれが接続されているPEの間のローカルな問題です。この時点で、PEはBGPレイヤー2ルートをアドバタイズすることにより、VPNに新しいサイトがあることを他のPEに通知でき、トラフィック接続がセットアップされます。
It bears repeating that the key to making additions easy is overprovisioning and the algorithm for mapping a CE ID to a DLCI that is used for connecting to the corresponding CE. However, what is being overprovisioned is the number of DLCIs/VCIs that connect the CE to the PE. This is a local matter between the PE and CE; it does not affect other PEs or CEs.
追加を容易にするための鍵はオーバープロビジョニングであり、対応するCEへの接続に使用されるDLCIにCE IDをマッピングするアルゴリズムであることは繰り返します。ただし、過剰にプロビジョニングされているのは、CEをPEに接続するDLCI / VCIの数です。これは、PEとCEの間のローカルな問題です。他のPEまたはCEには影響しません。
Deleting a site consists first of removing the CE ID of the site from the configuration of the PE to which the site is attached. The PE will then signal to other PEs that it no longer has access to that site by withdrawing its previously advertised BGP Layer 2 route. Connectivity to the deleted site will cease.
サイトを削除するには、まず、サイトが接続されているPEの構成からサイトのCE IDを削除します。次に、PEは、以前にアドバタイズされたBGPレイヤー2ルートを撤回することにより、そのサイトにアクセスできなくなったことを他のPEに通知します。削除されたサイトへの接続は停止します。
The next steps are bookkeeping: decommissioning the attachment circuit from the PE to the CE that corresponds to the site being removed and noting that the CE ID is now free for future allocation. Note that each PE is now (further) overprovisioned; one may choose to actively "reap" CE IDs if desired.
次のステップは簿記です。削除されるサイトに対応するPEからCEへの接続回線の使用を停止し、CE IDが将来の割り当てのために解放されたことに注意します。各PEが（さらに）オーバープロビジョニングされていることに注意してください。必要に応じて、CE IDを積極的に「取得」することを選択できます。
In the data plane, an attachment circuit, identified say by a DLCI, is mapped to a label via the control plane abstraction of a CE ID. At the egress PE, the label is mapped back to an attachment circuit via the same CE ID. It is up to the VPN administrator
データプレーンでは、DLCIなどによって識別される接続回路が、CE IDのコントロールプレーン抽象化を介してラベルにマッピングされます。出力PEでは、ラベルは同じCE IDを介して接続回線にマッピングされます。 VPN管理者次第です
o to provision attachment circuits (e.g., DLCIs);
o アタッチメント回線（DLCIなど）をプロビジョニングするため。
o to allocate CE IDs; and
o CE IDを割り当てるため。そして
o to keep a clear mapping of CE IDs to attachment circuits (and reflect this in PE configurations).
o 接続IDへのCE IDの明確なマッピングを維持します（これをPE構成に反映します）。
The PEs manage the mappings between attachment circuits and labels, i.e., the data plane mappings.
PEは、接続回線とラベルの間のマッピング、つまりデータプレーンマッピングを管理します。
Note that in the N-to-one modes listed in Table 1, a single attachment circuit may correspond to several Layer 2 virtual circuits. Nevertheless, there is a one-to-one mapping between an attachment circuit and a CE ID (and thus a label).
表1にリストされているN対1モードでは、1つの接続回線が複数のレイヤ2仮想回線に対応する場合があることに注意してください。それにもかかわらず、接続回線とCE ID（およびラベル）の間には1対1のマッピングがあります。
Label blocks and label values are managed by the PEs. As sites get added and removed, labels are allocated and released. The easiest way to manage these is to use fixed-size label blocks rather than variable-size blocks, although the signaling described here supports either. If an implementation uses fixed-size blocks, then allocating a label for a new site may requiring allocating a new block; similarly, freeing a label may require freeing a block.
ラベルブロックとラベル値は、PEによって管理されます。サイトが追加および削除されると、ラベルが割り当てられて解放されます。これらを管理する最も簡単な方法は、可変サイズのブロックではなく固定サイズのラベルブロックを使用することですが、ここで説明するシグナリングはどちらもサポートしています。実装が固定サイズのブロックを使用する場合、新しいサイトにラベルを割り当てるには、新しいブロックを割り当てる必要がある場合があります。同様に、ラベルを解放するには、ブロックを解放する必要がある場合があります。
If the implementation requires fixed-size blocks, there is probably a default block size, but the implementation SHOULD allow the administrator to choose a size. Larger label block sizes mean more potential "wasted" labels but less signaling overhead, a trade-off that the administrator might want to control.
実装が固定サイズのブロックを必要とする場合、おそらくデフォルトのブロックサイズがありますが、実装は管理者がサイズを選択できるようにする必要があります（SHOULD）。ラベルブロックサイズが大きいほど、「無駄な」ラベルの可能性は高くなりますが、シグナリングのオーバーヘッドは少なくなります。これは、管理者が制御する必要のあるトレードオフです。
Also, as sites get added and deleted, a PE may receive packets with a label that reflects a site that has been deleted locally but not yet processed by remote PEs or that reflects a new site added remotely but not processed locally. In either of these cases, the PE SHOULD silently discard the packet; it may choose to log the event once for each such label, but not for every such packet.
また、サイトが追加および削除されると、ローカルで削除されたがリモートPEによってまだ処理されていないサイトを反映するラベル、またはリモートで追加されたがローカルで処理されていない新しいサイトを反映するラベルが付いたパケットをPEが受信する場合があります。これらのいずれの場合でも、PEはパケットを静かに破棄する必要があります（SHOULD）。そのようなラベルごとに1回だけイベントをログに記録することを選択できますが、そのようなすべてのパケットについてはログに記録しません。
Many Layer 2 mediums have OAM mechanisms. For example, the PPP has Echo Request and Echo Reply messages; Frame Relay has the Local Management Interface. Among other things, OAM is used for troubleshooting and as keepalives.
多くのレイヤ2メディアにはOAMメカニズムがあります。たとえば、PPPにはエコー要求メッセージとエコー応答メッセージがあります。フレームリレーにはローカル管理インターフェースがあります。特に、OAMはトラブルシューティングやキープアライブとして使用されます。
There are two ways to carry OAM information across Layer 2 VPNs. The first is to convey OAM packets as any other Layer 2 packets across the VPN. This is the most general method; it maintains full Layer 2 transparency and preserves all OAM information. The other method applies only to the link liveness aspect of OAM; it consists of transmitting the status of each attachment circuit across the control plane using the circuit status vector (Section 3.1). This method is the only one applicable to Layer 2 Interworking VPNs (Section 4), since OAM packets are not IP frames and thus cannot be transmitted across such Layer 2 VPNs.
レイヤ2 VPN間でOAM情報を伝送するには、2つの方法があります。 1つ目は、OAMパケットを他のレイヤ2パケットと同様にVPN経由で伝達することです。これは最も一般的な方法です。レイヤ2の完全な透過性を維持し、すべてのOAM情報を保持します。もう1つの方法は、OAMのリンクの活性化の側面にのみ適用されます。これは、回線ステータスベクトルを使用して、各接続回線のステータスをコントロールプレーン全体に送信することで構成されます（セクション3.1）。この方法は、レイヤー2インターワーキングVPN（セクション4）に適用できる唯一の方法です。OAMパケットはIPフレームではないため、このようなレイヤー2 VPNを介して送信できないためです。
When a PE is configured with all the required information for a CE, it advertises to other PEs the fact that it is participating in a VPN via BGP messages, as per [RFC4761], Section 3. BGP was chosen as the means for exchanging L2VPN information for two reasons: it offers mechanisms for both auto-discovery and signaling, and it allows for operational convergence, as explained in Section 1. A bonus for using BGP is a robust inter-AS solution for L2VPNs.
PEがCEに必要なすべての情報で構成されている場合、[RFC4761]のセクション3に従って、BGPメッセージを介してVPNに参加しているという事実を他のPEにアドバタイズします。L2VPNを交換する手段としてBGPが選択されました2つの理由からの情報：セクション1で説明したように、自動検出とシグナリングの両方のメカニズムを提供し、操作の収束を可能にします。BGPの使用のボーナスは、L2VPNの堅牢なAS間ソリューションです。
There are two modifications to the formatting of messages. The first is that the set of Encaps Types carried in the L2-info extended community has been expanded to include those from Table 1. The value of the Encaps Type field identifies the Layer 2 encapsulation, e.g., ATM, Frame Relay, etc.
メッセージのフォーマットに2つの変更があります。 1つ目は、L2-info拡張コミュニティで運ばれるEncapsタイプのセットが拡張されて、表1のものが含まれるようになったことです。EncapsTypeフィールドの値は、レイヤー2カプセル化を識別します（ATM、フレームリレーなど）。
+-----------+-------------------------------------------+-----------+
| Encaps | Description | Reference |
| Type | | |
+-----------+-------------------------------------------+-----------+
| 0 | Reserved | - |
| | | |
| 1 | Frame Relay | RFC 4446 |
| | | |
| 2 | ATM AAL5 SDU VCC transport | RFC 4446 |
| | | |
| 3 | ATM transparent cell transport | RFC 4816 |
| | | |
| 4 | Ethernet (VLAN) Tagged Mode | RFC 4448 |
| | | |
| 5 | Ethernet Raw Mode | RFC 4448 |
| | | |
| 6 | Cisco HDLC | RFC 4618 |
| | | |
| 7 | PPP | RFC 4618 |
| | | |
| 8 | SONET/SDH Circuit Emulation Service | RFC 4842 |
| | | |
| 9 | ATM n-to-one VCC cell transport | RFC 4717 |
| | | |
| 10 | ATM n-to-one VPC cell transport | RFC 4717 |
| | | |
| 11 | IP Layer 2 Transport | RFC 3032 |
| | | |
| 15 | Frame Relay Port mode | RFC 4619 |
| | | |
| 17 | Structure-agnostic E1 over packet | RFC 4553 |
| | | |
| 18 | Structure-agnostic T1 (DS1) over packet | RFC 4553 |
| | | |
| 19 | VPLS | RFC 4761 |
| | | |
| 20 | Structure-agnostic T3 (DS3) over packet | RFC 4553 |
| | | |
| 21 | Nx64kbit/s Basic Service using | RFC 5086 |
| | Structure-aware | |
| | | |
| 25 | Frame Relay DLCI | RFC 4619 |
| | | |
| 40 | Structure-agnostic E3 over packet | RFC 4553 |
| | | |
| 41 (1) | Octet-aligned payload for | RFC 4553 |
| | Structure-agnostic DS1 circuits | |
| | | |
| 42 (2) | E1 Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
| | | |
| 43 | DS1 (ESF) Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
| | | |
| 44 | DS1 (SF) Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
+-----------+-------------------------------------------+-----------+
Table 1: Encaps Types
表1：カプセル化タイプ
Note (1): Allocation of a separate code point for Encaps Type eliminates the need for Time Division Multiplexer (TDM) payload size.
注（1）：Encaps Typeに個別のコードポイントを割り当てると、時分割多重（TDM）ペイロードサイズが不要になります。
Note (2): Having separate code points for Encaps Types 42-44 allows specifying the trunk framing (i.e., E1, T1 ESF, or T1 SF) with Channel Associated Signaling (CAS).
注（2）：Encaps Type 42-44に個別のコードポイントを設定すると、Channel Associated Signaling（CAS）でトランクフレーミング（E1、T1 ESF、またはT1 SF）を指定できます。
The second is the introduction of TLVs (Type-Length-Value triplets) in the VPLS NLRI (Network Layer Reachability Information). L2VPN TLVs can be added to extend the information carried in the NLRI, using the format shown in Figure 2. In L2VPN TLVs, Type is 1 octet, and Length is 2 octets and represents the size of the Value field in bits. L2VPN TLVs, if present, occur as the last element of a VPLS NLRI. The length of the NLRI includes the total length of the TLVs, including their headers.
2つ目は、VPLS NLRI（ネットワーク層到達可能性情報）でのTLV（Type-Length-Valueトリプレット）の導入です。 L2VPN TLVを追加して、図2に示すフォーマットを使用して、NLRIで伝送される情報を拡張できます。L2VPNTLVでは、タイプは1オクテット、長さは2オクテットで、値フィールドのサイズをビット単位で表します。 L2VPN TLVが存在する場合、VPLS NLRIの最後の要素として発生します。 NLRIの長さには、ヘッダーを含むTLVの全長が含まれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (continued, if needed) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of TLVs
図2：TLVのフォーマット
This sub-TLV carries the status of an L2VPN PVC between a pair of PEs. Note that an L2VPN PVC is bidirectional, composed of two simplex connections going in opposite directions. A simplex connection consists of three segments: 1) the local access circuit between the source CE and the ingress PE, 2) the tunnel Label Switched Path (LSP) between the ingress and egress PEs, and 3) the access circuit between the egress PE and the destination CE.
このサブTLVは、PEのペア間でL2VPN PVCのステータスを伝達します。 L2VPN PVCは双方向であり、反対方向に向かう2つのシンプレックス接続で構成されることに注意してください。シンプレックス接続は、3つのセグメントで構成されています。1）ソースCEと入力PE間のローカルアクセス回線、2）入力と出力PE間のトンネルラベルスイッチパス（LSP）、3）出力PE間のアクセス回線および宛先CE。
To monitor the status of a PVC, a PE needs to monitor the status of both simplex connections. Since it knows the status of its access circuit and the status of the tunnel towards the remote PE, it can inform the remote PE of these two. Similarly, the remote PE can inform the status of its access circuit to its local CE and the status of the tunnel to the first PE. Combining the local and the remote information, a PE can determine the status of a PVC.
PVCのステータスを監視するには、PEは両方のシンプレックス接続のステータスを監視する必要があります。アクセス回線の状態とリモートPEへのトンネルの状態を認識しているため、リモートPEにこれら2つを通知できます。同様に、リモートPEは、ローカルCEへのアクセス回線のステータスと、最初のPEへのトンネルのステータスを通知できます。 PEは、ローカル情報とリモート情報を組み合わせて、PVCのステータスを判別できます。
The basic unit of advertisement in L2VPN for a given CE is a label block. Each label within a label block corresponds to a PVC on the CE. The local status information for all PVCs corresponding to a label block is advertised along with the NLRI for the label block using the status vector TLV. The Type field of this TLV is 1. The Length field of the TLV specifies the length of the value field in bits. The Value field of this TLV is a bit-vector, each bit of which indicates the status of the PVC associated with the corresponding label in the label block. Bit value 0 corresponds to the PVC associated with the first label in the label block and indicates that the local circuit and the tunnel LSP to the remote PE is up, while a value of 1 indicates that either or both of them are down. The Value field is padded to the nearest octet boundary.
特定のCEのL2VPNでのアドバタイズメントの基本単位は、ラベルブロックです。ラベルブロック内の各ラベルは、CEのPVCに対応しています。ラベルブロックに対応するすべてのPVCのローカルステータス情報は、ステータスベクトルTLVを使用して、ラベルブロックのNLRIとともにアドバタイズされます。このTLVのタイプフィールドは1です。TLVの長さフィールドは、値フィールドの長さをビット単位で指定します。このTLVの値フィールドはビットベクトルであり、各ビットはラベルブロック内の対応するラベルに関連付けられたPVCのステータスを示します。ビット値0はラベルブロックの最初のラベルに関連付けられたPVCに対応し、ローカル回線とリモートPEへのトンネルLSPがアップしていることを示し、値1はそれらのいずれかまたは両方がダウンしていることを示します。値フィールドは、最も近いオクテット境界に埋め込まれます。
A PE can determine the status of a PVC from one of its CEs to a remote CE as follows. Say PE A has CE n in VPN X, and PE A gets an advertisement from PE B for remote CE m also in VPN X; this advertisement includes a label block and a circuit status vector. To determine which label to use for CE m, PE A must determine the index corresponding to CE m in the label block that PE B advertised. The status of the PVC between CE n and CE m can be obtained by looking at the bit in the circuit status vector corresponding to this index.
PEは、次のようにして、CEの1つからリモートCEへのPVCのステータスを判別できます。たとえば、PE AがVPN XにCE nを持ち、PE AがVPN XにもリモートCE mのPE Bからアドバタイズメントを取得するとします。このアドバタイズメントには、ラベルブロックと回線ステータスベクトルが含まれています。 CE mに使用するラベルを決定するには、PE Bがアドバタイズしたラベルブロック内のCE mに対応するインデックスをPE Aが決定する必要があります。 CE nとCE mの間のPVCのステータスは、このインデックスに対応する回線ステータスベクトルのビットを調べることで取得できます。
+----------+-----------------------+
| TLV Type | Description |
+----------+-----------------------+
| 1 | Circuit Status Vector |
+----------+-----------------------+
Table 2: TLV Types
表2：TLVタイプ
In the above, we assumed for simplicity that the VPN was a full mesh. To allow for more general VPN topologies, a mechanism based on filtering of BGP extended communities can be used.
上記では、簡単にするために、VPNはフルメッシュであると想定しました。より一般的なVPNトポロジを可能にするために、BGP拡張コミュニティのフィルタリングに基づくメカニズムを使用できます。
As defined so far in this document, all CE-PE connections for a given Layer 2 VPN must use the same Layer 2 encapsulation, e.g., they must all be Frame Relay. This is often a burdensome restriction. One answer is to use an existing Layer 2 interworking mechanism, for example, Frame Relay-ATM interworking.
このドキュメントでこれまでに定義されているように、特定のレイヤー2 VPNのすべてのCE-PE接続は、同じレイヤー2カプセル化を使用する必要があります。たとえば、それらはすべてフレームリレーでなければなりません。これはしばしば厄介な制限です。 1つの答えは、既存のレイヤ2インターワーキングメカニズム、たとえば、フレームリレーATMインターワーキングを使用することです。
In this document, we take a different approach: we postulate that the network Layer is IP and base Layer 2 interworking on that. Thus, one can choose between pure Layer 2 VPNs, with a stringent Layer 2 restriction but with Layer 3 independence, or Layer 2 interworking VPNs, where there is no restriction on Layer 2, but Layer 3 must be IP. Of course, a PE may choose to implement Frame Relay-ATM interworking. For example, an ATM Layer 2 VPN could have some CEs connect via Frame Relay links, if their PE could translate Frame Relay to ATM transparently to the rest of the VPN. This would be private to the CE-PE connection, and such a course is outside the scope of this document.
このドキュメントでは、別のアプローチをとっています。ネットワークレイヤーはIPであり、その上でレイヤー2が相互に作用していると仮定しています。したがって、厳密なレイヤ2の制限はあるがレイヤ3の独立性がある純粋なレイヤ2 VPN、またはレイヤ2に制限がないがレイヤ3はIPでなければならないレイヤ2インターワーキングVPNから選択できます。もちろん、PEはフレームリレーとATMのインターワーキングの実装を選択できます。たとえば、ATMレイヤ2 VPNは、PEがフレームリレーをATMに透過的に残りのVPNに変換できる場合、一部のCEをフレームリレーリンク経由で接続することができます。これはCE-PE接続に対してプライベートであり、そのようなコースはこのドキュメントの範囲外です。
For Layer 2 interworking as defined here, when an IP packet arrives at a PE, its Layer 2 address is noted, then all Layer 2 overhead is stripped, leaving just the IP packet. Next, a VPN label is added, and the packet is encapsulated in the PE-PE tunnel (as required by the tunnel technology). Finally, the packet is forwarded. Note that the forwarding decision is made on the basis of the Layer 2 information, not the IP header. At the egress, the VPN label determines to which CE the packet must be sent and over which virtual circuit; from this, the egress PE can also determine the Layer 2 encapsulation to place on the packet once the VPN label is stripped.
ここで定義されているレイヤ2インターワーキングの場合、IPパケットがPEに到着すると、そのレイヤ2アドレスが記録され、すべてのレイヤ2オーバーヘッドが取り除かれ、IPパケットだけが残ります。次に、VPNラベルが追加され、パケットがPE-PEトンネルでカプセル化されます（トンネルテクノロジーで必要な場合）。最後に、パケットが転送されます。転送の決定は、IPヘッダーではなく、レイヤ2情報に基づいて行われることに注意してください。出口では、VPNラベルによって、パケットを送信する必要のあるCEと、仮想回線を決定します。これから、出力PEは、VPNラベルが削除されたときにパケットに配置するレイヤ2カプセル化も決定できます。
An added benefit of restricting interworking to IP only as the Layer 3 technology is that the provider's network can provide IP Diffserv or any other IP-based QoS mechanism to the L2VPN customer. The ingress PE can set up IP/TCP/UDP-based classifiers to do Diffserv marking and other functions like policing and shaping on the L2 circuits of the VPN customer. Note the division of labor: the CE determines the destination CE and encodes that in the Layer 2 address. The ingress PE thus determines the egress PE and VPN label based on the Layer 2 address supplied by the CE, but the ingress PE can choose the tunnel to reach the egress PE (in the case that there are different tunnels for each CoS/Diffserv code point) or the CoS bits to place in the tunnel (in the case where a single tunnel carries multiple CoS/Diffserv code points) based on its own classification of the packet.
レイヤ3テクノロジーとしてのみインターワーキングをIPに制限することの追加の利点は、プロバイダーのネットワークがL2VPNカスタマーにIP Diffservまたはその他のIPベースのQoSメカニズムを提供できることです。入力PEは、IP / TCP / UDPベースの分類子を設定して、VPNカスタマーのL2回線でDiffservマーキングや、ポリシングやシェーピングなどの他の機能を実行できます。分業に注意してください。CEは宛先CEを決定し、それをレイヤ2アドレスにエンコードします。したがって、入力PEは、CEによって提供されるレイヤ2アドレスに基づいて出力PEおよびVPNラベルを決定しますが、入力PEは、出力PEに到達するためのトンネルを選択できます（CoS / Diffservコードごとに異なるトンネルがある場合）ポイント）、またはパケットの独自の分類に基づいてトンネルに配置するCoSビット（単一のトンネルが複数のCoS / Diffservコードポイントを伝送する場合）。
When a packet arrives at a PE from a CE in a Layer 2 VPN, the Layer 2 address of the packet identifies to which remote attachment circuit (and thus remote CE) the packet is destined. The procedure outlined above installs a route that maps the Layer 2 address to a tunnel (which identifies the PE to which the destination CE is attached) and a VPN label (which identifies the destination AC). If the egress PE is the same as the ingress PE, no tunnel or VPN label is needed.
パケットがレイヤー2 VPNのCEからPEに到着すると、パケットのレイヤー2アドレスは、パケットの宛先となるリモート接続回線（つまりリモートCE）を識別します。上記の手順では、レイヤー2アドレスをトンネル（宛先CEが接続されているPEを識別する）とVPNラベル（宛先ACを識別する）にマップするルートをインストールします。出力PEが入力PEと同じである場合、トンネルまたはVPNラベルは必要ありません。
The packet may then be modified (depending on the Layer 2 encapsulation). In case of IP-only Layer 2 interworking, the Layer 2 header is completely stripped off up to the IP header. Then, a VPN label and tunnel encapsulation are added as specified by the route described above, and the packet is sent to the egress PE.
次に、パケットを変更できます（レイヤー2カプセル化によって異なります）。 IPのみのレイヤー2インターワーキングの場合、レイヤー2ヘッダーはIPヘッダーまで完全に取り除かれます。次に、VPNラベルとトンネルカプセル化が上記のルートで指定されているように追加され、パケットが出力PEに送信されます。
If the egress PE is the same as the ingress, the packet "arrives" with no labels. Otherwise, the packet arrives with the VPN label, which is used to determine which CE is the destination CE. The packet is restored to a fully formed Layer 2 packet and then sent to the CE.
出力PEが入力と同じである場合、パケットはラベルなしで「到着」します。それ以外の場合、パケットはVPNラベルとともに到着します。これは、どのCEが宛先CEであるかを判別するために使用されます。パケットは完全に形成されたレイヤ2パケットに復元され、CEに送信されます。
This document requires that the Layer 2 MTU configured on all the access circuits connecting CEs to PEs in an L2VPN be the same. This can be ensured by passing the configured Layer 2 MTU in the Layer2- info extended community when advertising L2VPN label blocks. On receiving an L2VPN label block from remote PEs in a VPN, the MTU value carried in the Layer2-info extended community should be compared against the configured value for the VPN. If they don't match, then the label block should be ignored.
このドキュメントでは、CEをL2VPNのPEに接続するすべてのアクセス回線に設定されているレイヤ2 MTUが同じである必要があります。これは、L2VPNラベルブロックをアドバタイズするときに、構成済みのレイヤー2 MTUをLayer2- info拡張コミュニティに渡すことで確認できます。 VPN内のリモートPEからL2VPNラベルブロックを受信すると、Layer2-info拡張コミュニティで伝送されるMTU値を、VPNに構成された値と比較する必要があります。それらが一致しない場合、ラベルブロックは無視されます。
The MTU on the Layer 2 access links MUST be chosen such that the size of the L2 frames plus the L2VPN header does not exceed the MTU of the SP network. Layer 2 frames that exceed the MTU after encapsulation MUST be dropped. For the case of IP-only Layer 2 interworking, the IP MTU on the Layer 2 access link must be chosen such that the size of the IP packet and the L2VPN header does not exceed the MTU of the SP network.
レイヤ2アクセスリンクのMTUは、L2フレームとL2VPNヘッダーのサイズがSPネットワークのMTUを超えないように選択する必要があります。カプセル化後にMTUを超えるレイヤ2フレームはドロップする必要があります。 IPのみのレイヤー2インターワーキングの場合、レイヤー2アクセスリンクのIP MTUは、IPパケットとL2VPNヘッダーのサイズがSPネットワークのMTUを超えないように選択する必要があります。
The modification to the Layer 2 frame depends on the Layer 2 type. This document requires that the encapsulation methods used in transporting Layer 2 frames over tunnels be the same as described in [RFC4448], [RFC4618], [RFC4619], and [RFC4717], except in the case of IP-only Layer 2 Interworking, which is described next.
レイヤー2フレームの変更は、レイヤー2のタイプによって異なります。このドキュメントでは、トンネルを介したレイヤ2フレームの転送に使用されるカプセル化方法が、[RFC4448]、[RFC4618]、[RFC4619]、および[RFC4717]で説明されているものと同じである必要があります。ただし、IPのみのレイヤ2インターワーキングの場合は除きます。次に説明します。
+-----------------------------------+
| PSN Transport | VPN | IP | VPN label is the
| Header | Label | Packet | demultiplexing field
+-----------------------------------+
Figure 3: Format of IP-Only Layer 2 Interworking Packet
図3：IPのみのレイヤー2インターワーキングパケットのフォーマット
At the ingress PE, an L2 frame's L2 header is completely stripped off and is carried over as an IP packet within the SP network (Figure 3). The forwarding decision is still based on the L2 address of the incoming L2 frame. At the egress PE, the IP packet is encapsulated back in an L2 frame and transported over to the destination CE. The forwarding decision at the egress PE is based on the VPN label as before. The L2 technology between egress PE and CE is independent of the L2 technology between ingress PE and CE.
入力PEでは、L2フレームのL2ヘッダーが完全に取り除かれ、SPネットワーク内でIPパケットとして引き継がれます（図3）。転送の決定は、引き続き着信L2フレームのL2アドレスに基づいています。出力PEでは、IPパケットはL2フレームにカプセル化されて戻され、宛先CEに転送されます。出力PEでの転送の決定は、以前と同様にVPNラベルに基づいています。出力PEとCE間のL2テクノロジーは、入力PEとCE間のL2テクノロジーから独立しています。
RFC 4761 [RFC4761], on which this document is based, has a detailed discussion of security considerations. As in RFC 4761, the focus here is the privacy of customer VPN data (as opposed to confidentiality, integrity, or authentication of said data); to achieve the latter, one can use the methods suggested in RFC 4761. The techniques described in RFC 4761 for securing the control plane and protecting the forwarding path apply equally to L2VPNs, as do the remarks regarding multi-AS operation. The mitigation strategies and the analogies with RFC 4364 [RFC4364] also apply here.
このドキュメントのベースとなっているRFC 4761 [RFC4761]には、セキュリティの考慮事項に関する詳細な説明があります。 RFC 4761と同様に、ここでの焦点は顧客のVPNデータのプライバシーです（データの機密性、整合性、または認証とは対照的です）。後者を実現するには、RFC 4761で提案されている方法を使用できます。コントロールプレーンを保護し、転送パスを保護するためのRFC 4761で説明されている手法は、マルチAS動作に関する注釈と同様に、L2VPNにも適用されます。緩和戦略とRFC 4364 [RFC4364]との類似点もここに適用されます。
RFC 4761 perhaps should have discussed Denial-of-Service attacks based on the fact that VPLS PEs have to learn Media Access Control (MAC) addresses and replicate packets (for flooding and multicast). However, those considerations don't apply here, as neither of those actions are required of PEs implementing the procedures in this document.
RFC 4761では、VPLS PEがメディアアクセス制御（MAC）アドレスを学習し、パケットを複製（フラッディングとマルチキャストのため）する必要があるという事実に基づいて、サービス拒否攻撃について説明したはずです。ただし、これらの考慮事項はここでは適用されません。これらのアクションのいずれも、このドキュメントの手順を実装するPEには必要ないためです。
IANA has created two new registries: the first is for the one-octet Encaps Type field of the L2-info extended community. The name of the registry is "BGP Layer 2 Encapsulation Types"; the values already allocated are in Table 1 of Section 3. The allocation policy for new entries up to and including value 127 is "Expert Review" [RFC5226]. The allocation policy for values 128 through 251 is "First Come First Served". The values from 252 through 255 are for "Experimental Use".
IANAは2つの新しいレジストリを作成しました。1つ目は、L2-info拡張コミュニティの1オクテットのEncaps Typeフィールド用です。レジストリの名前は「BGPレイヤー2カプセル化タイプ」です。すでに割り当てられている値は、セクション3の表1にあります。値127までの新しいエントリの割り当てポリシーは、「エキスパートレビュー」[RFC5226]です。 128〜251の値の割り当てポリシーは、「先着順」です。 252から255までの値は「実験的使用」用です。
The second registry is for the one-octet Type field of the TLVs of the VPLS NLRI. The name of the registry is "BGP L2 TLV Types"; the sole allocated value is in Table 2 of Section 3. The allocation policy for new entries up to and including value 127 is "Expert Review". The allocation policy for values 128 through 251 is "First Come First Served". The values from 252 through 255 are for "Experimental Use".
2番目のレジストリは、VPLS NLRIのTLVの1オクテットのTypeフィールド用です。レジストリの名前は「BGP L2 TLVタイプ」です。唯一の割り当てられた値は、セクション3の表2にあります。値127までの新しいエントリの割り当てポリシーは、「エキスパートレビュー」です。 128〜251の値の割り当てポリシーは、「先着順」です。 252から255までの値は「実験的使用」用です。
The authors would like to thank Chaitanya Kodeboyina, Dennis Ferguson, Der-Hwa Gan, Dave Katz, Nischal Sheth, John Stewart, and Paul Traina for the enlightening discussions that helped shape the ideas presented here. The authors also thank Ross Callon for his valuable comments.
ここで提示されたアイデアを形作るのに役立つ啓発的な議論をしてくれたChaitanya Kodeboyina、Dennis Ferguson、Der-Hwa Gan、Dave Katz、Nischal Sheth、John Stewart、およびPaul Trainaに感謝します。著者はまた、Ross Callon氏の貴重なコメントにも感謝しています。
The idea of using extended communities for more general connectivity of a Layer 2 VPN was a contribution by Yakov Rekhter, who also gave many useful comments on the text. Many thanks to him.
レイヤー2 VPNのより一般的な接続に拡張コミュニティを使用するという考えは、Yakov Rekhterによる貢献であり、Yakov Rekhterもテキストに多くの有用なコメントを与えました。彼に感謝します。
The following individuals contributed to this document.
以下の個人がこの文書に貢献しました。
Manoj Leelanivas, Juniper Networks Quaizar Vohra, Juniper Networks Javier Achirica, Consultant Ronald Bonica, Juniper Networks Dave Cooper, Global Crossing Chris Liljenstolpe, Telstra Eduard Metz, KPN Dutch Telecom Hamid Ould-Brahim, Nortel Chandramouli Sargor Himanshu Shah, Ciena Vijay Srinivasan Zhaohui Zhang, Juniper Networks
Manoj Leelanivas、ジュニパーネットワークスQuaizar Vohra、ジュニパーネットワークスJavier Achirica、コンサルタントRonald Bonica、ジュニパーネットワークスDave Cooper、Global Crossing Chris Liljenstolpe、Telstra Eduard Metz、KPN Dutch Telecom Hamid Ould-Brahim、Nortel Chandramouli Zarigan Zu 、ジュニパーネットワークス
[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月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP Extended Communities Attribute」、RFC 4360、2006年2月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[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月。
[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.、and G. Heron、 "Encapsulation Methods for Transport of Ethernet over MPLS Networks"、RFC 4448、April 2006。
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[RFC4618] Martini、L.、Rosen、E.、Heron、G。、およびA. Malis、「MPLSネットワーク上のPPP /高レベルデータリンク制御（HDLC）のトランスポートのカプセル化方法」、RFC 4618、2006年9月。
[RFC4619] Martini, L., Kawa, C., and A. Malis, "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[RFC4619]マティーニ、L。、カワ、C。、およびA.マリ、「マルチプロトコルラベルスイッチング（MPLS）ネットワーク上のフレームリレーのトランスポートのカプセル化方法」、RFC 4619、2006年9月。
[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006.
[RFC4717] Martini、L.、Jayakumar、J.、Bocci、M.、El-Aawar、N.、Brayley、J.、and G. Koleyni、 "Encapsulation Methods for Transport of Asynchronous Transfer Mode（ATM）over MPLS Networks "、RFC 4717、2006年12月。
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4761] Kompella、K。およびY. Rekhter、「Auto-Discovery and SignalingにBGPを使用した仮想プライベートLANサービス（VPLS）」、RFC 4761、2007年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[Kosiur] Kosiur, D., "Building and Managing Virtual Private Networks", Wiley Computer Publishing, 1998.
[Kosiur] Kosiur、D。、「仮想プライベートネットワークの構築と管理」、Wiley Computer Publishing、1998年。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S。およびP.パテ、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[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、「Pseudowire Setup and Maintenance Using a Label Distribution Protocol（LDP）」、RFC 4447、2006年4月。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4684] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ. Guichard、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングの制約付きルート配信（BGP / MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPN）」、RFC 4684、2006年11月。
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[RFC4762] Lasserre、M。およびV. Kompella、「Label Distribution Protocol（LDP）Signalingを使用した仮想プライベートLANサービス（VPLS）」、RFC 4762、2007年1月。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.
[RFC6074]ローゼン、E。、デイビー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、2011年1月。
Authors' Addresses
著者のアドレス
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
キリーティコンペラジュニパーネットワークス1194 N.マチルダアベニュー。サニーベール、カリフォルニア州94089米国
EMail: kireeti@juniper.net
Bhupesh Kothari Cisco Systems 3750 Cisco Way San Jose, CA 95134 USA
Bhupesh Kothari Cisco Systems 3750 Cisco Way San Joseの95134
EMail: bhupesh@cisco.com
Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
ラオチェルクリジュニパーネットワークス119いいえ。マチルダが来る。 Sunniwale、または303 Us
EMail: cherukuri@juniper.net