[要約] RFC 4664は、Layer 2 Virtual Private Networks（L2VPNs）のためのフレームワークを提供しています。このRFCの目的は、異なるネットワーク間でL2VPNを実現するための一貫性のあるアーキテクチャとプロトコルを定義することです。
Network Working Group L. Andersson, Ed.
Request for Comments: 4664 Acreo AB
Category: Informational E. Rosen, Ed.
Cisco Systems, Inc.
September 2006
Framework for Layer 2 Virtual Private Networks (L2VPNs)
レイヤー2仮想プライベートネットワークのフレームワーク（L2VPNS）
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs.
このドキュメントは、レイヤー2プロバイダープロビジョニング仮想プライベートネットワーク（L2VPNS）のフレームワークを提供します。このフレームワークは、相互運用可能なL2VPNをサポートするためのプロトコルとメカニズムの標準化を支援することを目的としています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Objectives and Scope of the Document .......................3
1.3. Layer 2 Virtual Private Networks ...........................3
1.4. Terminology ................................................4
2. Models ..........................................................5
2.1. Reference Model for VPWS ...................................5
2.1.1. Entities in the VPWS Reference Model ................5
2.2. Reference Model for VPLS ...................................6
2.2.1. Entities in the VPLS Reference Model ................8
2.3. Reference Model for Distributed VPLS-PE or VPWS-PE .........9
2.3.1. Entities in the Distributed PE Reference Models .....9
2.4. VPWS-PE and VPLS-PE ........................................9
3. Functional Components of L2 VPN .................................9
3.1. Types of L2VPN ............................................10
3.1.1. Virtual Private Wire Service (VPWS) ................10
3.1.2. Virtual Private LAN Service (VPLS) .................10
3.1.3. IP-Only LAN-Like Service (IPLS) ....................11
3.2. Generic L2VPN Transport Functional Components .............11
3.2.1. Attachment Circuits ................................11
3.2.2. Pseudowires ........................................12
3.2.3. Forwarders .........................................14
3.2.4. Tunnels ............................................15
3.2.5. Encapsulation ......................................16
3.2.6. Pseudowire Signaling ...............................16
3.2.6.1. Point-to-Point Signaling ..................18
3.2.6.2. Point-to-Multipoint Signaling .............18
3.2.6.3. Inter-AS Considerations ...................19
3.2.7. Service Quality ....................................20
3.2.7.1. Quality of Service (QoS) ..................20
3.2.7.2. Resiliency ................................21
3.2.8. Management .........................................22
3.3. VPWS ......................................................22
3.3.1. Provisioning and Auto-Discovery ....................23
3.3.1.1. Attachment Circuit Provisioning ...........23
3.3.1.2. PW Provisioning for Arbitrary
Overlay Topologies ........................23
3.3.1.3. Colored Pools PW Provisioning Model .......25
3.3.2. Requirements on Auto-Discovery Procedures ..........27
3.3.3. Heterogeneous Pseudowires ..........................28
3.4. VPLS Emulated LANs ........................................29
3.4.1. VPLS Overlay Topologies and Forwarding .............31
3.4.2. Provisioning and Auto-Discovery ....................33
3.4.3. Distributed PE .....................................33
3.4.4. Scaling Issues in VPLS Deployment ..................36
3.5. IP-Only LAN-Like Service (IPLS) ...........................36
4. Security Considerations ........................................37
4.1. Provider Network Security Issues ..........................37
4.2. Provider-Customer Network Security Issues .................39
4.3. Customer Network Security Issues ..........................39
5. Acknowledgements ...............................................40
6. Normative References ...........................................41
7. Informative References .........................................41
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]で説明されているように解釈されます。
This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs.
このドキュメントは、レイヤー2プロバイダープロビジョニング仮想プライベートネットワーク（L2VPNS）のフレームワークを提供します。このフレームワークは、相互運用可能なL2VPNをサポートするためのプロトコルとメカニズムの標準化を支援することを目的としています。
The term "provider provisioned VPNs" refers to Virtual Private Networks (VPNs) for which the Service Provider (SP) participates in management and provisioning of the VPN.
「プロバイダープロビジョニングVPNS」という用語は、サービスプロバイダー（SP）がVPNの管理とプロビジョニングに参加する仮想プライベートネットワーク（VPN）を指します。
Requirements for L2VPNs can be found in [RFC4665].
L2VPNの要件は[RFC4665]に記載されています。
This document provides reference models for L2VPNs and discusses the functional components of L2VPNs. Specifically, this includes discussion of the technical issues that are important in the design of standards and mechanisms for L2VPNs, including those standards and mechanisms needed for interworking and security.
このドキュメントは、L2VPNの参照モデルを提供し、L2VPNSの機能成分について説明します。具体的には、これには、インターワーキングとセキュリティに必要な標準とメカニズムなど、L2VPNの標準とメカニズムの設計に重要な技術的な問題の議論が含まれます。
This document discusses a number of different technical approaches to L2VPNs. It tries to show how the different approaches are related, and to clarify the issues that may lead one to select one approach instead of another. However, this document does not attempt to select any particular approach.
このドキュメントでは、L2VPNに対するさまざまな技術的アプローチについて説明します。さまざまなアプローチがどのように関連しているかを示し、1つのアプローチを別のアプローチではなく選択する可能性のある問題を明確にしようとします。ただし、このドキュメントでは、特定のアプローチを選択しようとはしていません。
There are two fundamentally different kinds of Layer 2 VPN service that a service provider could offer to a customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS). There is also the possibility of an IP-only LAN-like Service (IPLS).
サービスプロバイダーが顧客に提供できる2つの根本的に異なる種類のレイヤー2 VPNサービスは、仮想プライベートワイヤーサービス（VPWS）と仮想プライベートLANサービス（VPLS）です。IPのみのLANのようなサービス（IPLS）の可能性もあります。
A VPWS is a VPN service that supplies an L2 point-to-point service. As this is a point-to-point service, there are very few scaling issues with the service as such. Scaling issues might arise from the number of end-points that can be supported on a particular PE.
VPWSは、L2ポイントツーポイントサービスを提供するVPNサービスです。これはポイントツーポイントサービスであるため、サービスのスケーリングの問題はほとんどありません。スケーリングの問題は、特定のPEでサポートできるエンドポイントの数から発生する可能性があります。
A VPLS is an L2 service that emulates LAN service across a Wide Area Network (WAN). With regard to the amount of state information that must be kept at the edges in order to support the forwarding function, it has the scaling characteristics of a LAN. Other scaling issues might arise from the number of end-points that can be supported on a particular PE. (See Section 3.4.4.)
VPLSは、幅広いネットワーク（WAN）でLANサービスをエミュレートするL2サービスです。転送機能をサポートするためにエッジに保持しなければならない状態情報の量に関して、LANのスケーリング特性があります。他のスケーリングの問題は、特定のPEでサポートできるエンドポイントの数から発生する可能性があります。（セクション3.4.4を参照してください。）
Note that VPLS uses a service that does not have native multicast capability to emulate a service that does have native multicast capability. As a result, there will be scalability issues with regard to the handling of multicast traffic in VPLS.
VPLSは、ネイティブマルチキャスト機能を備えていないサービスを使用して、ネイティブマルチキャスト機能を持つサービスをエミュレートすることに注意してください。その結果、VPLSでのマルチキャストトラフィックの取り扱いに関して、スケーラビリティの問題が発生します。
A VPLS service may also impose longer delays and provide less reliable transport than would a native LAN service. The standard LAN control protocols may not have been designed for such an environment and may experience scaling problems when run in that environment.
また、VPLSサービスは、より長い遅延を課し、ネイティブLANサービスよりも信頼性の低い輸送を提供する場合があります。標準のLAN制御プロトコルは、そのような環境向けに設計されていない可能性があり、その環境で実行されたときに問題のスケーリングを経験する可能性があります。
The list of the technical terms used when discussing L2VPNs may be found in the companion document [RFC4026].
L2VPNについて議論するときに使用される技術用語のリストは、コンパニオンドキュメント[RFC4026]に記載されている場合があります。
The VPWS reference model is shown in Figure 1.
VPWS参照モデルを図1に示します。
Attachment PSN Attachment
Circuits tunnel Circuits
+
+-----+ pseudo +-----+
| | wire | |
| CE1 |--+ +--| CE2 |
| | | +-----+ +-----+ +-----+ | | |
+-----+ +----|---- | | P | | ----+----+ +-----+
|VPWS\---|-----|-----|/VPWS|
| PE1 |===|=====|=====| PE2 |
| /|---|-----|-----|\\ |
+-----+ +----|---- | | | | ----|----+ +-----+
| | | +-----+ +-----+ +-----+ | | |
| CE3 |--+ +--| CE4 |
| | | |
+-----+ +-----+
Figure 1
図1
The P, PE (VPWS-PE), and CE devices and the PSN tunnel are defined in [RFC4026]. The attachment circuit and pseudowire are discussed in Section 3. The PE does a simple mapping between the PW and attachment circuit based on local information; i.e., the PW demultiplexor and incoming/outgoing logical/physical port.
P、PE（VPWS-PE）、およびCEデバイスとPSNトンネルは[RFC4026]で定義されています。アタッチメント回路と擬似ワイヤーについては、セクション3で説明します。PEは、ローカル情報に基づいてPWとアタッチメント回路の間の単純なマッピングを行います。すなわち、PW Demultiplexorおよび着信/発信論理/物理ポート。
The following diagram shows a VPLS reference model where PE devices that are VPLS-capable provide a logical interconnect such that CE devices belonging to a specific VPLS appear to be on a single bridged Ethernet. A VPLS can contain a single VLAN or multiple tagged VLANs.
次の図は、VPLS対応であるPEデバイスが、特定のVPLに属するCEデバイスが単一のブリッジ付きイーサネット上にあるように見えるように論理的な相互接続を提供するVPLS参照モデルを示しています。VPLには、単一のVLANまたは複数のタグ付きVLANを含めることができます。
The VPLS reference model is shown in Figures 2 and 3.
VPLS参照モデルを図2および3に示します。
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ................... | +-----+
VPLS A | +----+ +----+ | VPLS A
| |VPLS| |VPLS| |
+--| PE |--Routed---| PE |-+
+----+ Backbone +----+
/ . | . \ _ /\_
+-----+ / . | . \ / \ / \ +-----+
+ CE +--+ . | . +--\ Access \----| CE |
+-----+ . +----+ . | Network | +-----+
VPLS B .....|VPLS|........ \ / VPLS B
| PE | ^ -------
+----+ |
| |
| |
+-----+ |
| CE3 | +-- Emulated LAN
+-----+
VPLS A
Figure 2
図2
|-----Routed Backbone-----|
| (P Routers) |PSN Tunnels,
Emulated LAN | |Pseudowires
.......................................................................
. | | .
. |---------------------|----| |--------|-----------------| .
. | --------------------|--- | | -------|---------------- | .
. | VPLS Forwarder | | VPLS Forwarder | .
. | ----------|------------- | | ----------|------------- | .
..|.................................................................|..
| | Emulated LAN | | | Emulated LAN |
| | Interface | VPLS-PEs | | Interface |
| | | <----> | | |
| ----------|------------ | | ----------|------------ |
| | Bridge | | | | Bridge | |
| -|--------|---------|-- | | ---|-------|---------|- |
|--|--------|---------|----| |----|-------|---------|---|
| | | | | |
| | Access | | | Access |
| | Networks| | | Networks|
| | | | | |
| | | | | |
CE devices CE devices
Figure 3
図3
From Figure 3, we see that in VPLS, a CE device attaches, possibly through an access network, to a "bridge" module of a VPLS-PE. Within the VPLS-PE, the bridge module attaches, through an "Emulated LAN Interface", to an Emulated LAN. For each VPLS, there is an Emulated LAN instance. Figure 3 shows some internal structure to the Emulated LAN: it consists of "VPLS Forwarder" modules connected by pseudowires, where the pseudowires may be traveling through PSN tunnels over a routed backbone.
図3から、VPLSでは、CEデバイスがアクセスネットワークを介してVPLS-PEの「ブリッジ」モジュールに取り付けられていることがわかります。VPLS-PE内では、ブリッジモジュールが「エミュレートされたLANインターフェイス」を介してエミュレートされたLANに取り付けられます。各VPLについて、エミュレートされたLANインスタンスがあります。図3は、エミュレートされたLANの内部構造を示しています。これは、擬似動物によって接続された「VPLSフォワーダー」モジュールで構成されています。そこでは、擬似ワイヤがルーティングされたバックボーンを越えてPSNトンネルを通過している可能性があります。
A "VPLS instance" consists of a set of VPLS Forwarders (no more than one per PE) connected by pseudowires.
「VPLSインスタンス」は、Pseudowiresで接続されているVPLSフォワーダーのセット（PEごとに1つ以下）で構成されています。
The functionality that the bridge module must support depends on the service that is being offered by the SP to its customers, as well as on various details of the SP's network. At a minimum, the bridge module must be able to learn MAC addresses, and to "age them out", in the standard manner. However, if the PE devices have backdoor connections with each other via a Layer 2 network, they may need to be full IEEE bridges ([IEEE8021D]), running a spanning tree with each other. Specification of the precise functionality that the bridge modules must have in particular circumstances is, however, out of scope of the current document.
ブリッジモジュールがサポートする必要がある機能は、SPが顧客に提供されているサービスと、SPのネットワークのさまざまな詳細によって異なります。少なくとも、ブリッジモジュールは、標準的な方法でMacアドレスを学習し、「老化」することができる必要があります。ただし、PEデバイスがレイヤー2ネットワークを介してバックドア接続を互いに互いに接続している場合、それらは完全なIEEEブリッジ（[IEEE8021D]）である必要がある場合があり、スパニングツリーを互いに実行します。ただし、ブリッジモジュールが特定の状況で必要とする正確な機能の指定は、現在のドキュメントの範囲外です。
This framework specifies that each "bridge module" have a single "Emulated LAN interface". It does not specify the number of bridge modules that a VPLS-PE may contain, nor does it specify the number of VPLS instances that may attach to a bridge module over a single "Emulated LAN interface".
このフレームワークは、各「ブリッジモジュール」には単一の「エミュレートされたLANインターフェイス」があることを指定しています。VPLS-PEに含まれる可能性のあるブリッジモジュールの数も指定されておらず、単一の「エミュレートLANインターフェイス」を介してブリッジモジュールに付着するVPLSインスタンスの数も指定しません。
Thus the framework is compatible with at least the following three models:
したがって、フレームワークは、少なくとも次の3つのモデルと互換性があります。
- Model 1
- モデル1
A VPLS-PE contains a single bridge module and supports a single VPLS instance. The VPLS instance is an Emulated LAN; if that Emulated LAN contains VLANs, 802.1Q [IEEE8021Q] tagging must be used to indicate which packets are in which VLANs.
VPLS-PEには、単一のブリッジモジュールが含まれており、単一のVPLSインスタンスをサポートします。VPLSインスタンスはエミュレートされたLANです。そのエミュレートされたLANにVLANが含まれている場合、802.1Q [IEEE8021Q]タグ付けを使用して、どのパケットがどのVLANであるかを示す必要があります。
- Model 2
- モデル2
A VPLS-PE contains a single bridge module, but supports multiple VPLS instances. Each VPLS instance is thought of as a VLAN (in effect, an "Emulated VLAN"), and the set of VPLS instances are treated as a set of VLANs on a common LAN. Since each VLAN uses a separate set of PWs, there is no need for 802.1Q tagging.
VPLS-PEには単一のブリッジモジュールが含まれていますが、複数のVPLSインスタンスをサポートしています。各VPLSインスタンスはVLAN（実際には「エミュレートされたVLAN」）と考えられており、VPLSインスタンスのセットは、共通のLAN上のVLANのセットとして扱われます。各VLANは個別のPWSセットを使用するため、802.1Qタグ付けは必要ありません。
- Model 3
- モデル3
A VPLS-PE contains an arbitrary number of bridge modules, each of which attaches to a single VPLS instance.
VPLS-PEには、任意の数のブリッジモジュールが含まれており、それぞれが単一のVPLSインスタンスに取り付けられています。
There may be other models as well, some of which are combinations of the 3 models above. Different models may have different characteristics, and different scopes of applicability.
他のモデルもありますが、その一部は上記の3つのモデルの組み合わせです。異なるモデルには、異なる特性があり、適用可能性の異なる範囲があります。
Each VPLS solution should specify the model or models that it is supporting. Each solution should also specify the necessary bridge functionality that its bridge modules must support.
各VPLSソリューションは、サポートしているモデルまたはモデルを指定する必要があります。各ソリューションでは、ブリッジモジュールがサポートする必要がある必要なブリッジ機能も指定する必要があります。
This framework does not specify the way in which bridge control protocols are used on the Emulated LANs.
このフレームワークでは、エミュレートされたLANでブリッジ制御プロトコルが使用される方法を指定しません。
The PE (VPLS-PE) and CE devices are defined in [RFC4026].
PE（VPLS-PE）およびCEデバイスは[RFC4026]で定義されています。
VPLS-PE/VPWS-PE
Functionality . . . . . . .
. . . . . . . . . . . . .
. . . .
+----+ . +----+ +----+ . . Service .
| CE |--.--|U-PE|----|N-PE|-.---. Provider .
+----+ . +----+ +----+ . . Backbone .
. . . . . . . . . . . . .
A VPLS-PE or a VPWS-PE functionality may be distributed to more than one device. The device closer to the customer/user is called the User-facing PE (U-PE), and the device closer to the core network is called Network-facing PE (N-PE).
VPLS-PEまたはVPWS-PE機能は、複数のデバイスに分散する場合があります。顧客/ユーザーに近いデバイスはユーザー向けPE（U-PE）と呼ばれ、コアネットワークに近いデバイスはネットワーク向けPE（N-PE）と呼ばれます。
For further discussion, see Section 3.4.3.
詳細については、セクション3.4.3を参照してください。
The terms "U-PE" and "N-PE" are defined in [RFC4026].
「u-pe」および「n-pe」という用語は、[RFC4026]で定義されています。
The VPWS-PE and VPLS-PE are functionally very similar, in that they both use forwarders to map attachment circuits to pseudowires. The only difference is that while the forwarder in a VPWS-PE does a one-to-one mapping between the attachment circuit and pseudowire, the forwarder in a VPLS-PE is a Virtual Switching Instance (VSI) that maps multiple attachment circuits to multiple pseudowires (for further discussion, see Section 3).
VPWS-PEおよびVPLS-PEは機能的に非常に類似しています。どちらもフォワーダーを使用してアタッチメントサーキットを擬似動物にマッピングしています。唯一の違いは、VPWS-PEのフォワーダーがアタッチメント回路と擬似ワイヤの間で1対1のマッピングを行うことですが、VPLS-PEのフォワーダーは、複数のアタッチメントサーキットを複数にマッピングする仮想スイッチングインスタンス（VSI）であることです。Pseudowires（詳細については、セクション3を参照）。
This section specifies a functional model for L2VPN, which allows one to break an L2VPN architecture down into its functional components. This exhibits the roles played by the various protocols and mechanisms, and thus makes it easier to understand the differences and similarities between various proposed L2VPN architectures.
このセクションでは、L2VPNの機能モデルを指定します。これにより、L2VPNアーキテクチャを機能コンポーネントに分割することができます。これは、さまざまなプロトコルとメカニズムが果たす役割を示しているため、提案されているさまざまなL2VPNアーキテクチャ間の違いと類似性を理解しやすくなります。
Section 3.1 contains an overview of some different types of L2VPNs. In Section 3.2, functional components that are common to the different types are discussed. Then, there is a section for each of the L2VPN service types being considered. The latter sections discuss functional components, which may be specific to particular L2VPN types, and type-specific features of the generic components.
セクション3.1には、いくつかの異なるタイプのL2VPNの概要が含まれています。セクション3.2では、異なるタイプに共通する機能コンポーネントについて説明します。次に、考慮されるL2VPNサービスの各タイプのセクションがあります。後者のセクションでは、特定のL2VPNタイプに固有の機能コンポーネント、およびジェネリックコンポーネントのタイプ固有の特徴について説明します。
The types of L2VPN are distinguished by the characteristics of the service that they offer to the customers of the Service Provider (SP).
L2VPNのタイプは、サービスプロバイダー（SP）の顧客に提供するサービスの特性によって区別されます。
In a VPWS, each CE device is presented with a set of point-to-point virtual circuits.
VPWSでは、各CEデバイスにはポイントツーポイント仮想回路のセットが表示されます。
The other end of each virtual circuit is another CE device. Frames transmitted by a CE on such a virtual circuit are received by the CE device at the other end-point of the virtual circuit. Forwarding from one CE device to another is not affected by the content of the frame, but is fully determined by the virtual circuit on which the frame is transmitted. The PE thus acts as a virtual circuit switch.
各仮想回路のもう一方の端は、別のCEデバイスです。このような仮想回路でCEによって送信されるフレームは、仮想回路のもう一方のエンドポイントでCEデバイスによって受信されます。あるCEデバイスから別のデバイスへの転送は、フレームのコンテンツの影響を受けませんが、フレームが送信される仮想回路によって完全に決定されます。したがって、PEは仮想回路スイッチとして機能します。
This type of L2VPN has long been available over ATM and Frame Relay backbones. Providing this type of L2VPN over MPLS and/or IP backbones is the current topic.
このタイプのL2VPNは、ATMおよびフレームリレーバックボーンで長い間利用できます。MPLSおよび/またはIPバックボーンを介してこのタイプのL2VPNを提供することは、現在のトピックです。
Requirements for this type of L2VPN are specified in [RFC4665].
このタイプのL2VPNの要件は[RFC4665]で指定されています。
In a VPLS, each CE device has one or more LAN interfaces that lead to a "virtual backbone".
VPLSでは、各CEデバイスには、「仮想バックボーン」につながる1つ以上のLANインターフェイスがあります。
Two CEs are connected to the same virtual backbone if and only if they are members of the same VPLS instance (i.e., same VPN). When a CE transmits a frame, the PE that receives it examines the MAC Destination Address field in order to determine how to forward the frame. Thus, the PE functions as a bridge. As Figure 3 indicates, if a set of PEs support a common VPLS instance, then there is an Emulated LAN, corresponding to that VPLS instance, to which each of those PE bridges attaches (via an emulated interface). From the perspective of a CE device, the virtual backbone is the set of PE bridges and the Emulated LAN on which they reside. Thus to a CE device, the LAN that attaches it to the PE is extended transparently over the routed MPLS and/or IP backbone.
同じVPLSインスタンス（つまり、同じVPN）のメンバーである場合にのみ、2つのCEが同じ仮想バックボーンに接続されます。CEがフレームを送信すると、フレームを転送する方法を決定するために、MAC宛先アドレスフィールドを受信するPEが調べます。したがって、PEはブリッジとして機能します。図3に示すように、PESのセットが一般的なVPLSインスタンスをサポートする場合、そのVPLSインスタンスに対応するエミュレートされたLANがあり、それらの各PEブリッジが（エミュレートされたインターフェイスを介して）付着します。CEデバイスの観点から見ると、仮想バックボーンはPEブリッジのセットとそれらが存在するエミュレートされたLANです。したがって、CEデバイスに対して、それをPEに取り付けるLANは、ルーティングされたMPLSおよび/またはIPバックボーン上で透過的に拡張されます。
The PE bridge function treats the Emulated LAN as it would any other LAN to which it has an interface. Forwarding decisions are made in the manner that is normal for bridges, which is based on MAC Source Address learning.
PEブリッジ関数は、エミュレートされたLANを、インターフェイスを持つ他のLANのように処理します。転送の決定は、MACソースアドレス学習に基づいた橋の場合は正常な方法で行われます。
VPLS is like VPWS in that forwarding is done without any consideration of the Layer3 header. VPLS is unlike VPWS in that:
VPLSは、レイヤー3ヘッダーを考慮せずに転送が行われるという点でVPWに似ています。VPLSはVPWSとは異なります。
- VPLS allows the PE to use addressing information in a frame's L2 header to determine how to forward the frame; and
- VPLを使用すると、PEはフレームのL2ヘッダーでアドレス指定情報を使用して、フレームを転送する方法を決定できます。と
- VPLS allows a single CE/PE connection to be used for transmitting frames to multiple remote CEs; in this particular respect, VPLS resembles L3VPN more than VPWS.
- VPLでは、単一のCE/PE接続を複数のリモートCEに送信するために使用できます。この点で、VPLSはVPWよりもL3VPNに似ています。
Requirements for this type of L2VPN are specified in [RFC4665].
このタイプのL2VPNの要件は[RFC4665]で指定されています。
An IPLS is very like a VPLS, except that:
IPLSは、次のことを除いて、VPLSに非常に似ています。
- it is assumed that the CE devices are hosts or routers, not switches; and
- CEデバイスは、スイッチではなく、ホストまたはルーターであると想定されています。と
- it is assumed that the service will only carry IP packets and supporting packets such as ICMP and ARP (in the case of IPv4) or Neighbor Discovery (in the case of IPv6); Layer 2 packets that do not contain IP are not supported.
- このサービスは、IPパケットとICMPやARP（IPv4の場合）や近隣発見（IPv6の場合）などのサポートパケットのみを搭載すると想定されています。IPを含まないレイヤー2パケットはサポートされていません。
While this service is a functional subset of the VPLS service, it is considered separately because it may be possible to provide it using different mechanisms, which may allow it to run on certain hardware platforms that cannot support the full VPLS functionality.
このサービスはVPLSサービスの機能的なサブセットですが、異なるメカニズムを使用して提供できるため、個別に考慮されます。これにより、完全なVPLS機能をサポートできない特定のハードウェアプラットフォームで実行できます。
All L2VPN types must transport "frames" across the core network connecting the PEs. In all L2VPN types, a PE (PE1) receives a frame from a CE (CE1), and then transports the frame to a PE (PE2), which then transports the frame to a CE (CE2). In this section, we discuss the functional components that are necessary to transport L2 frames in any type of L2VPN service.
すべてのL2VPNタイプは、PESを接続するコアネットワーク全体に「フレーム」を輸送する必要があります。すべてのL2VPNタイプで、PE（PE1）はCE（CE1）からフレームを受信し、フレームをPE（PE2）に輸送し、フレームをCE（CE2）に輸送します。このセクションでは、あらゆるタイプのL2VPNサービスでL2フレームを輸送するために必要な機能コンポーネントについて説明します。
In any type of L2VPN, a CE device attaches to a PE device via some sort of circuit or virtual circuit. We will call this an "Attachment Circuit" (AC). We use this term very generally; an Attachment Circuit may be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a PPP connection on a physical interface, a PPP session from an L2TP tunnel, an MPLS LSP, etc. The CE device may be a router, a switch, a host, or just about anything, which the customer needs hooked up to the VPN. An AC carries a frame between CE and PE, or vice versa.
あらゆるタイプのL2VPNでは、CEデバイスが何らかの種類の回路または仮想回路を介してPEデバイスに取り付けられます。これを「アタッチメント回路」（AC）と呼びます。この用語は非常に一般的に使用しています。アタッチメント回路は、フレームリレーDLCI、ATM VPI/VCI、イーサネットポート、VLAN、物理インターフェイス上のPPP接続、L2TPトンネルからのPPPセッション、MPLS LSPなどです。ルーター、スイッチ、ホスト、または顧客がVPNに接続する必要があるもの。ACは、CEとPEの間にフレームを搭載します。その逆も同様です。
Procedures for setting up and maintaining the ACs are out of scope of this architecture.
ACSをセットアップおよび維持するための手順は、このアーキテクチャの範囲外です。
These procedures are generally specified as part of the specification of the particular Attachment Circuit technology.
これらの手順は、一般に、特定のアタッチメント回路技術の仕様の一部として指定されています。
Any given frame will traverse an AC from a CE to a PE, and then on another AC from a PE to a CE.
特定のフレームは、CEからPEにACを通過し、次にPEからCEまで別のACに通過します。
We refer to the former AC as the frame's "ingress AC" and to the latter AC as the frame's "egress AC". Note that this notion of "ingress AC" and "egress AC" is relative to a specific frame and denotes nothing more than the frame's direction of travel while it is on that AC.
前のACをフレームの「Ingress AC」と呼び、後者のACをフレームの「出口AC」と呼びます。この「Ingress AC」と「Egress AC」のこの概念は、特定のフレームに関連しており、そのACにある間、フレームの移動方向に過ぎないことに注意してください。
A "Pseudowire" (PW) is a relation between two PE devices. Whereas an AC is used to carry a frame from CE to PE, a PW is used to carry a frame between two PEs. We use the term "pseudowire" in the sense of [RFC3985].
「Pseudowire」（PW）は、2つのPEデバイス間の関係です。ACはCEからPEまでフレームを運ぶために使用されますが、PWは2つのPEの間のフレームを運ぶために使用されます。[rfc3985]という意味で「擬似動物」という用語を使用します。
Setting up and maintaining the PWs is the job of the PEs. State information for a particular PW is maintained at the two PEs that are its endpoints, but not at other PEs, and not in the backbone routers (P routers).
PWSのセットアップと維持は、PESの仕事です。特定のPWの状態情報は、そのエンドポイントである2つのPESで維持されますが、バックボーンルーター（Pルーター）ではなく、他のPESではなく維持されます。
Pseudowires may be point-to-point, multipoint-to-point, or point-to-multipoint. In this framework, point-to-point PWs are always considered bidirectional; multipoint-to-point and point-to-multipoint PWs are always considered unidirectional. Multipoint-to-point PWs can be used only when the PE receiving a frame does not need to infer, from the PW on which the frame was received, the identity of the frame's ingress AC. Point-to-multipoint PWs may be useful when frames need to be multicast.
擬似ワイヤは、ポイントツーポイント、マルチポイントツーポイント、またはポイントツーマルチポイントです。このフレームワークでは、ポイントツーポイントPWは常に双方向と見なされます。マルチポイントツーポイントおよびポイントツーマルチポイントPWは、常に単方向と見なされます。マルチポイントツーポイントPWSは、フレームを受信するPEがフレームを受信したPWから、フレームのイングレスACのアイデンティティから推測する必要がない場合にのみ使用できます。ポイントツーマルチポイントPWSは、フレームがマルチキャストである必要がある場合に役立ちます。
Procedures for setting up and maintaining point-to-multipoint PWs are not considered in this version of this framework.
このフレームワークのこのバージョンでは、ポイントツーマルチポイントPWをセットアップおよび維持する手順は考慮されていません。
Any given frame travels first on its ingress AC, then on a PW, and then on its egress AC.
特定のフレームは、最初にその侵入AC、次にPW、次に出口ACで移動します。
Multicast frames may be replicated by a PE, so of course the information carried in multicast frames may travel on more than one PW and more than one egress AC.
マルチキャストフレームはPEで複製される可能性があるため、もちろんマルチキャストフレームで運ばれる情報は、複数のPWと複数の出口ACで移動する場合があります。
Thus with respect to a given frame, a PW may be said to associate a number of ACs. If these ACs are of the same technology (e.g., both ATM, both Ethernet, both Frame Relay), the PW is said to provide "homogeneous transport"; otherwise it is said to provide "heterogeneous transport". Heterogeneous transport requires that some sort of interworking function be applied. There are at least three different approaches to interworking:
したがって、特定のフレームに関しては、PWが多くのACを関連付けると言われる場合があります。これらのACSが同じ技術である場合（たとえば、両方のATM、両方のイーサネット、両方のフレームリレー）、PWは「均一な輸送」を提供すると言われています。それ以外の場合は、「不均一な輸送」を提供すると言われています。不均一な輸送では、何らかの種類のインターワーキング関数を適用する必要があります。インターワーキングには少なくとも3つの異なるアプローチがあります。
1. One of the CEs may perform the interworking locally. For example, if CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via Ethernet, then CE1 may decide to send/receive Ethernet frames over ATM, using the RFC 2684, "LLC Encapsulation for Bridged Protocols". In such a case, PE1 would need to know that it is to terminate the ATM VC locally, and only to send/receive Ethernet frames over the PW.
1. CESの1つは、局所的にインターワーキングを実行できます。たとえば、CE1がATMを介してPE1に付着しているが、CE2がイーサネットを介してPE2に付着する場合、CE1はRFC 2684を使用して、ATMを介してイーサネットフレームを送信/受信することを決定する場合があります。そのような場合、PE1は、ATM VCをローカルで終了することであり、PWを介してイーサネットフレームを送信/受信することであることを知る必要があります。
2. One of the PEs may perform the interworking. For example, if CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via Frame Relay, PE1 may provide the "ATM/FR Service Interworking" function. This would be transparent to the CEs, and the PW would carry only Frame Relay frames.
2. PESの1つがインターワーキングを実行する場合があります。たとえば、CE1がATMを介してPE1に付着するが、CE2がフレームリレーを介してPE2に付着すると、PE1は「ATM/FRサービスインターワーキング」機能を提供する場合があります。これはCESに対して透明であり、PWはフレームリレーフレームのみを運びます。
3. IPLS could be used. In this case, the "frames" carried by the PW are IP datagrams, and the two PEs need to cooperate in order to spoof various L2-specific procedures used by IP (see Section 3.5).
3. IPLSを使用できます。この場合、PWによって運ばれる「フレーム」はIPデータグラムであり、IPで使用されるさまざまなL2固有の手順をスプーフィングするために2つのPESが協力する必要があります（セクション3.5を参照）。
If heterogeneous PWs are used, the setup protocol must ensure that each endpoint knows the MTU of the remote AC. If the two ACs do not have the same MTU, one of the following three procedures must be carried out:
不均一なPWを使用する場合、セットアッププロトコルは、各エンドポイントがリモートACのMTUを知っていることを確認する必要があります。2つのACが同じMTUを持っていない場合、次の3つの手順のうちの1つを実行する必要があります。
- The PW is not allowed to come up.
- PWは登場することは許可されていません。
- The endpoint at the AC with the larger MTU must reduce the AC's MTU so that it is the same as the MTU of the remote AC.
- より大きなMTUを備えたACのエンドポイントは、リモートACのMTUと同じようにACのMTUを減らす必要があります。
- The two endpoints must agree to use a specified fragmentation/reassembly procedure.
- 2つのエンドポイントは、指定された断片化/再組み立て手順を使用することに同意する必要があります。
In all types of L2VPN, a PE (say, PE1) receives a frame over an AC and forwards it over a PW to another PE (say, PE2). PE2 then forwards the frame out on another AC.
あらゆるタイプのL2VPNで、PE（たとえば、PE1）はACの上にフレームを受け取り、PWを介して別のPE（たとえば、PE2）に転送します。その後、PE2は別のACにフレームを転送します。
The case in which PE1 and PE2 are the same device is an important case to handle correctly, in order to provide the L2VPN service properly. However, as this case does not require any protocol, we do not address it further in this document.
L2VPNサービスを適切に提供するために、PE1とPE2が同じデバイスである場合は、正しく処理する重要なケースです。ただし、この場合はプロトコルを必要としないため、このドキュメントではこれ以上対処しません。
When PE1 receives a frame on a particular AC, it must determine the PW on which the frame must be forwarded. In general, this is done by considering:
PE1が特定のACでフレームを受信する場合、フレームを転送する必要があるPWを決定する必要があります。一般に、これは以下を検討することによって行われます。
- the incoming AC;
- 着信AC;
- possibly the contents of the frame's Layer2 header; and
- おそらくフレームのlayer2ヘッダーの内容。と
- possibly some forwarding information that may be statically or dynamically maintained.
- おそらく、静的または動的に維持される可能性のあるいくつかの転送情報。
If dynamic or static forwarding information is considered, the information is specific to a particular L2VPN instance (i.e., to a particular VPN).
動的または静的転送情報が考慮される場合、情報は特定のL2VPNインスタンス（つまり、特定のVPN）に固有です。
Similarly, when PE2 receives a frame on a particular PW, it must determine the AC on which the frame must be forwarded. This is done by considering:
同様に、PE2が特定のPWでフレームを受信する場合、フレームを転送する必要があるACを決定する必要があります。これは、考慮することによって行われます。
- the incoming PW;
- 着信PW;
- possibly the contents of the frame's Layer2 header; and
- おそらくフレームのlayer2ヘッダーの内容。と
- possibly some forwarding information that may be statically or dynamically maintained.
- おそらく、静的または動的に維持される可能性のあるいくつかの転送情報。
If dynamic or static forwarding information is considered, the information is specific to a particular L2VPN instance (i.e., to a particular VPN).
動的または静的転送情報が考慮される場合、情報は特定のL2VPNインスタンス（つまり、特定のVPN）に固有です。
The procedures used to make the forwarding decision are known as a "forwarder". We may think of a PW as being "bound", at each of its endpoints, to a forwarder. The forwarder in turn "binds" the PWs to ACs. Different types of L2VPN have different types of forwarders.
転送決定を行うために使用される手順は、「フォワーダー」として知られています。PWは、そのエンドポイントのそれぞれで、フォワーダーに「バインドされている」と考えるかもしれません。フォワーダーは、PWSをACSに「バインド」します。さまざまなタイプのL2VPNには、さまざまなタイプのフォワーダーがあります。
For instance, a forwarder may bind a single AC to a single PW, ignoring all frame contents and using no other forwarding information. Or a forwarder may bind an AC to a set of PWs and ACs, moving individual frames from AC to PW, from a PW to an AC or from AC to AC by comparing information from the frame's Layer2 header to information in a forwarding database. This is discussed in more detail below, as we consider the different L2VPN types.
たとえば、フォワーダーは、すべてのフレームコンテンツを無視し、他の転送情報を使用しないように、単一のACを単一のPWにバインドする場合があります。または、FrameのLayer2ヘッダーから転送データベース内の情報に情報を比較することにより、ACをPWSおよびACSのセットにバインドして、個々のフレームをACからPWからAC、ACからACからACからACに移動できます。これについては、さまざまなL2VPNタイプを検討するため、以下で詳しく説明します。
A PW is carried in a "tunnel" from PE1 to PE2. We assume that an arbitrary number of PWs may be carried in a single tunnel; the only requirement is that the PWs all terminate at PE2.
PWは、PE1からPE2までの「トンネル」で運ばれます。任意の数のPWが単一のトンネルで運ばれる可能性があると仮定します。唯一の要件は、PWSがすべてPE2で終了することです。
We do not even require that all the PWs in the tunnel originate at PE1; the tunnels may be multipoint-to-point tunnels. Nor do we require that all PWs between the same pair of PEs travel in the same tunnel. All we require is that when a frame traveling through such a tunnel arrives at PE2, PE2 will be able to associate it with a particular PW.
トンネル内のすべてのPWがPE1で発生することさえ要求していません。トンネルは、マルチポイントからポイントのトンネルである場合があります。また、同じトンネル内で同じペアのペア間のすべてのPWSが移動することも必要ありません。必要なのは、そのようなトンネルを走行するフレームがPE2に到着すると、PE2が特定のPWに関連付けることができるということです。
(While one can imagine tunneling techniques that only allow one PW per tunnel, they have evident scalability problems, and we do not consider them further.)
（トンネルごとに1つのPWのみを許可するトンネリングテクニックを想像できますが、スケーラビリティの問題が明らかになっており、さらに考慮していません。）
A variety of different tunneling technologies may be used for the PE-PE tunnels. All that is really required is that the tunneling technologies allow the proper demultiplexing of the contained PWs. The tunnels might be MPLS LSPs, L2TP tunnels, IPsec tunnels, MPLS-in-IP tunnels, etc. Generally the tunneling technology will require the use of an encapsulation that contains a demultiplexor field, where the demultiplexor field is used to identify a particular PW. Procedures for setting up and maintaining the tunnels are not within the scope of this framework. (But see Section 3.2.6, "Pseudowire Signaling".)
PE-PEトンネルには、さまざまな異なるトンネル技術を使用できます。本当に必要なのは、トンネリング技術が含まれているPWSの適切な非複数形成を可能にすることです。トンネルは、MPLS LSP、L2TPトンネル、IPSECトンネル、MPLS-in-IPトンネルなどである可能性があります。一般に、トンネリングテクノロジーは、特定のPWを識別するためにデマルグリプレクサーフィールドを使用するデバルチプレクサーフィールドを含むカプセル化の使用を必要とします。。トンネルをセットアップして維持するための手順は、このフレームワークの範囲内ではありません。（ただし、セクション3.2.6、「Pseudowire Signaling」を参照してください。）
If there are multiple tunnels from PE1 to PE2, it may be desirable to assign a particular PE1-PE2 PW to a particular tunnel based on some particular characteristics of the PW and/or the tunnel. For example, perhaps different tunnels are associated with different QoS characteristics, and different PWs require different QoS. Procedures for specifying how to assign PWs to tunnels are out of scope of the current framework.
PE1からPE2に複数のトンネルがある場合、PWおよび/またはトンネルの特定の特性に基づいて、特定のPE1-PE2 PWを特定のトンネルに割り当てることが望ましい場合があります。たとえば、おそらく異なるトンネルは異なるQoS特性に関連付けられており、異なるPWSには異なるQOが必要です。トンネルにPWSを割り当てる方法を指定するための手順は、現在のフレームワークの範囲外です。
Though point-to-point PWs are bidirectional, the tunnels in which they travel need not be either bidirectional or point-to-point. For example, a point-to-point PW may travel within a unidirectional multipoint-to-point MPLS LSP.
ポイントツーポイントPWは双方向ですが、移動するトンネルは双方向またはポイントツーポイントである必要はありません。たとえば、ポイントツーポイントPWは、単方向のマルチポイントツーポイントMPLS LSP内を移動する場合があります。
As L2VPN packets are carried in pseudowires, standard pseudowire encapsulation formats and techniques (as specified by the IETF's PWE3 WG) should be used wherever applicable.
L2VPNパケットは擬似動物で運ばれるため、標準の擬似ワイヤーカプセル化形式と技術（IETFのPWE3 WGで指定）は、該当する場合は使用する必要があります。
Generally the PW encapsulations will themselves be encapsulated within a tunnel encapsulation, as determined by the specification of the tunneling protocol.
一般に、PWのカプセルは、トンネルプロトコルの仕様によって決定されるように、トンネルカプセル化内でカプセル化されます。
It may be necessary to define additional PW encapsulations to cover areas that are of importance for L2VPN, but that may not be within the scope of PWE3. Heterogeneous transport may be an instance of this.
L2VPNにとって重要な領域をカバーするために追加のPWカプセルを定義する必要があるかもしれませんが、PWE3の範囲内ではないかもしれません。不均一な輸送は、これの例かもしれません。
Procedures for setting up and maintaining the PWs themselves are within the scope of this framework. This includes procedures for distributing demultiplexor field values, even though the demultiplexor field, strictly speaking, belongs to the tunneling protocol and not to the PW.
PWS自体をセットアップおよび維持するための手順は、このフレームワークの範囲内にあります。これには、Demultiplexorフィールドが厳密に言えば、PWではなくトンネルプロトコルに属しているにもかかわらず、Demultiplexorフィールド値を分配するための手順が含まれます。
The signaling for a point-to-point pseudowire must perform the following functions:
ポイントツーポイントの擬似ワイヤーのシグナリングは、次の機能を実行する必要があります。
- Distribution of the demultiplexor.
- Demultiplexorの分布。
Since many PWs may be carried in a single tunnel, the tunneling protocol must assign a demultiplexor value to each PW. These demultiplexors must be unique with respect to a given tunnel (or, with some tunneling technologies, unique at the egress PE). Generally, the PE that is the egress of the tunnel will select the demultiplexor values and will distribute them to the PE(s) which is (are) the ingress(es) of the tunnel. This is the essential part of the PW setup procedure.
多くのPWは単一のトンネルで運ばれる可能性があるため、トンネリングプロトコルは各PWに非gultiplexor値を割り当てる必要があります。これらの非gultip鎖は、特定のトンネルに関してユニークでなければなりません（または、いくつかのトンネル技術を使用して、Egress PEでユニークです）。一般に、トンネルの出口であるPEは、非gultiplexor値を選択し、トンネルの侵入（es）であるPE（s）にそれらを分配します。これは、PWセットアップ手順の重要な部分です。
Note that, as is usually the case in tunneling architectures, the demultiplexor field belongs to the tunneling protocol, not to the protocol being tunneled. For this reason, the PW setup protocols may be extensions of the control protocols for setting up the tunnels.
トンネリングアーキテクチャの通常の場合と同様に、Demultiplexorフィールドは、トンネリングされているプロトコルではなく、トンネルプロトコルに属していることに注意してください。このため、PWセットアッププロトコルは、トンネルをセットアップするための制御プロトコルの拡張である可能性があります。
- Selection of the Forwarder at the remote PE.
- リモートPEでのフォワーダーの選択。
The signaling protocol must contain enough information to enable the remote PE to select the proper forwarder to which the PW is to be bound. We can call this information the "Remote Forwarder Selector". The information that is required will depend on the type of L2VPN being provided and on the provisioning model being used (see Sections 3.3.1 and 3.4.2). The Remote Forwarder Selector may uniquely identify a particular Forwarder, or it may identify an attribute of Forwarders. In the latter case, it would select whichever Forwarder has been provisioned with that attribute.
シグナリングプロトコルには、リモートPEがPWをバインドする適切なフォワーダーを選択できるようにするのに十分な情報を含める必要があります。この情報を「リモートフォワーダーセレクター」と呼ぶことができます。必要な情報は、提供されるL2VPNのタイプと使用されるプロビジョニングモデルに依存します（セクション3.3.1および3.4.2を参照）。リモートフォワーダーセレクターは、特定のフォワーダーを一意に識別するか、フォワーダーの属性を識別する場合があります。後者の場合、その属性でプロビジョニングされたフォワーダーを選択します。
- Supporting pseudowire emulations.
- 擬似具体的なエミュレーションをサポートします。
To the extent that a particular PW must emulate the signaling of a particular Layer2 technology, the PW signaling must provide the necessary functions.
特定のPWが特定のLayer2テクノロジーのシグナル伝達をエミュレートする必要がある限り、PWシグナル伝達は必要な機能を提供する必要があります。
- Distribution of state changes.
- 状態の変化の分布。
Changes in the state of an AC may need to be reflected in changes to the state of the PW to which the AC is bound, and vice versa. The specification as to which changes need to be reflected in what way would generally be within the province of the PWE3 WG.
ACの状態の変化は、ACが拘束されるPWの状態の変化に反映される必要がある場合があり、その逆も同様です。どのように変化をどのように反映する必要があるかについての仕様は、一般的にPWE3 WGの州内にある方法です。
- Establishing pseudowire characteristics.
- 擬似ワイヤの特性を確立します。
To the extent that one or more characteristics of a PW must be known to and/or agreed upon by both endpoints, the signaling must allow for the necessary interaction.
PWの1つまたは複数の特性を両方のエンドポイントに知られ、および/または合意する必要がある限り、シグナルは必要な相互作用を許可する必要があります。
As specified above, signaling for point-to-point PWs must pass enough information to allow a remote PE to properly bind a PW to a Forwarder, and to associate a particular demultiplexor value with that PW. Once the two PEs have done the proper PW/Forwarder bindings, and have agreed on the demultiplexor values, the PW may be considered set up. If it is necessary to negotiate further characteristics or parameters of a particular PW, or to pass status information for a particular PW, the PW may be identified by the demultiplexor value.
上記で指定されたように、ポイントツーポイントPWのシグナリングは、リモートPEがPWをフォワーダーに適切に結合し、特定のDemultiplexorの値をそのPWに関連付けるために十分な情報を渡す必要があります。2つのPEが適切なPW/フォワーダーバインディングを実行し、Demultiplexorの値に合意したら、PWはセットアップと見なされる場合があります。特定のPWのさらなる特性またはパラメーターを交渉する必要がある場合、または特定のPWのステータス情報を渡す必要がある場合、PWはDemultiplexor値によって識別される場合があります。
Signaling procedures for point-to-point pseudowires are most commonly point-to-point procedures that are executed by the two PW endpoints. There are, however, proposals to use point-to-multipoint signaling for setting up point-to-point pseudowires, so this is included in the framework. When PWs are themselves point-to-multipoint, it is also possible to use either point-to-point signaling or point-to-multipoint signaling to set them up. This is discussed in the remainder of this section.
ポイントツーポイントの擬似動物のシグナル伝達手順は、最も一般的には、2つのPWエンドポイントによって実行されるポイントツーポイントプロシージャです。ただし、ポイントツーポイントの擬似ワイヤを設定するためにポイントツーマルチポイントシグナル伝達を使用する提案があるため、これはフレームワークに含まれています。PWがそれ自体がポイントツーマルチポイントである場合、ポイントツーポイントシグナルまたはポイントツーマルチポイントシグナルを使用してそれらを設定することもできます。これについては、このセクションの残りの部分で説明します。
There are several ways to do the necessary point-to-point signaling. Among them are:
必要なポイントツーポイントシグナル伝達を行うには、いくつかの方法があります。その中には：
- LDP
- LDP
LDP [RFC3036] extensions can be defined for pseudowire signaling. This form of signaling can be used for pseudowires that are to be carried in MPLS "tunnels", or in MPLS-in-something-else tunnels.
LDP [RFC3036]拡張機能は、擬似ワイヤシグナル伝達用に定義できます。この形式のシグナル伝達は、MPLS「トンネル」、またはMPLS-in-someth-elseトンネルで運ばれる擬似動物に使用できます。
- L2TP
- L2TP
L2TP [RFC2661] can be used for pseudowire signaling, resulting in pseudowires that are carried as "sessions" within L2TP tunnels. Pseudowire-specific extensions to L2TP may also be needed.
L2TP [RFC2661]は、擬似ワイヤーシグナル伝達に使用でき、L2TPトンネル内で「セッション」として運ばれる擬似ワイヤをもたらします。L2TPへの擬似化固有の拡張も必要になる場合があります。
Other methods may be possible as well.
他の方法も可能です。
It is possible to have one control connection between a pair of PEs, which is used to control many PWs.
多くのPWSを制御するために使用されるPESのペア間に1つの制御接続を持つことができます。
The use of point-to-point signaling for setting up point-to-point PWs is straightforward. Multipoint-to-point PWs can also be set up by point-to-point signaling, as the remote PEs do not necessarily need to know whether the PWs are multipoint-to-point or point-to-point. In some signaling procedures, the same demultiplexor value may be assigned to all the remote PEs.
ポイントツーポイントPWSを設定するためのポイントツーポイントシグナリングの使用は簡単です。マルチポイントからポイントへのPWSは、リモートPEがマルチポイントツーポイントまたはポイントツーポイントであるかどうかを必ずしも知る必要はないため、ポイントツーポイントシグナル伝達によってセットアップすることもできます。一部のシグナル伝達手順では、すべてのリモートPESに同じDemultiplexor値が割り当てられる場合があります。
Consider the following conditions:
次の条件を検討してください。
- It is necessary to set up a set of PWs, all of which have the same characteristics.
- PWSのセットをセットアップする必要があります。これらはすべて同じ特性を持っています。
- It is not necessary to use the PW signaling protocol to pass PW state changes.
- PWの状態の変更に合格するために、PWシグナル伝達プロトコルを使用する必要はありません。
- For each PW in the set, the same value of the Remote Forwarder Selector can be used.
- セット内の各PWについて、リモートフォワーダーセレクターの同じ値を使用できます。
Call these the "Environmental Conditions".
これらを「環境条件」と呼びます。
Suppose also that there is some mechanism by which, given a range of demultiplexor values, each of a set of PEs can make a unique and deterministic selection of a single value from within that range. Call this the "Demultiplexor Condition". Alternatively, suppose that one is trying to set up a multipoint-to-point PW rather than to set up a point-to-point PW. Call this the "Multipoint Condition".
また、一連のデマルグリプレクサー値を考えると、PESの各セットがその範囲内から単一の値のユニークで決定論的な選択を行うことができるメカニズムがあると仮定します。これを「Demultiplexor条件」と呼びます。または、ポイントツーポイントPWをセットアップするのではなく、マルチポイントツーポイントPWをセットアップしようとしているとします。これを「マルチポイント条件」と呼びます。
If:
もしも：
- The Environmental Conditions hold; and
- 環境条件が保持されます。と
- Either
- また
* the Demultiplexor Condition holds, or
* Demultiplexorの状態が保持されます
* the Multipoint Condition holds,
* マルチポイント条件が保持されます、
then for a given set of PWs that terminate at egress PE1, the information that PE1 needs to send to the ingress PE(s) of each pseudowire in the set is exactly the same. All the ingress PE(s) receive the same Forwarder Selector value. They all receive the same set of PW parameters (if any). And either they all receive the same demultiplexor value (if the PW is multipoint-to-point) or they all receive a range of demultiplexor values from which each can choose a unique demultiplexor value for itself.
次に、Gurss PE1で終了する特定のPWSセットについて、PE1がセット内の各擬似ワイヤの侵入PE（s）に送信する必要がある情報はまったく同じです。すべての侵入PEは、同じフォワーダーセレクター値を受け取ります。それらはすべて、同じセットのPWパラメーター（ある場合）を受け取ります。そして、それらはすべて同じDemultiplexor値を受け取っています（PWがマルチポイントツーポイントの場合）またはそれらはすべて、それぞれがそれ自体に対して一意のDemultiplexor値を選択できる範囲のDemultiplexor値を受け取ります。
Rather than connect to each ingress PE and replicate the same information, it may make sense either to multicast the information, or to send the information once to a "reflector", which will then take responsibility for distributing the information to the other PEs.
各侵入PEに接続して同じ情報を再現するのではなく、情報をマルチキャストするか、情報を「リフレクター」に送信することは理にかなっています。
We refer to this sort of technique as "point-to-multipoint" signaling. It would, for example, be possible to use BGP [RFC1771] to do the signaling, with PEs that are BGP peers not of each other, but of one or more BGP route reflectors [RFC2796].
この種の手法を「ポイントツーマルチポイント」シグナル伝達と呼びます。たとえば、BGP [RFC1771]を使用してシグナリングを行うことができます。これは、BGPピアではなく、1つ以上のBGPルートリフレクター[RFC2796]のPESであります。
Pseudowires may need to run from a PE in one Service Provider's network to a PE in another Service Provider's network. This has the following implications:
Pseudowiresは、あるサービスプロバイダーのネットワークのPEから別のサービスプロバイダーのネットワークのPEに実行する必要がある場合があります。これには次の意味があります。
- The signaling protocol that sets up the PWs must be able to cross network boundaries. Of course, all IP-based protocols have this capability.
- PWSをセットアップするシグナリングプロトコルは、ネットワークの境界を越えられる必要があります。もちろん、すべてのIPベースのプロトコルにはこの機能があります。
- The two PEs at the PW endpoints must be addressable and routable from each other.
- PWエンドポイントの2つのPEは、互いにアドレス指定可能でルーティング可能でなければなりません。
- The signaling protocol needs to allow each PW endpoint to authenticate the other. To make use of the authentication capability, there would also need to be some method of key distribution that is acceptable to both administrations.
- シグナリングプロトコルでは、各PWエンドポイントが他方を認証できるようにする必要があります。認証機能を利用するには、両方の管理者に受け入れられる重要な分布の方法も必要です。
Service Quality refers to the ability for the network to deliver a Service level Specification (SLS) for service attributes such as protection, security, and Quality of Service (QoS). The service quality provided depends on the subscriber's requirements and can be characterized by a number of performance metrics.
サービス品質とは、保護、セキュリティ、サービス品質（QO）などのサービス属性に、ネットワークがサービスレベル仕様（SLS）を提供する機能を指します。提供されるサービスの品質は、サブスクライバーの要件に依存し、多くのパフォーマンスメトリックによって特徴付けられます。
The necessary Service Quality must be provided on the ACs, as well as on the PWs. Mechanisms for providing Service Quality on the PWs may be PW-specific or tunnel-specific; in the latter case, the assignment of a PW to a tunnel may depend on the Service Quality.
必要なサービス品質は、ACSおよびPWSで提供する必要があります。PWでサービス品質を提供するためのメカニズムは、PW固有またはトンネル固有のものである場合があります。後者の場合、トンネルへのPWの割り当ては、サービス品質に依存する場合があります。
QoS describes the queuing behavior applied to a particular "flow", in order to achieve particular goals of precedence, throughput, delay, jitter, etc.
QoSは、優先順位、スループット、遅延、ジッターなどの特定の目標を達成するために、特定の「フロー」に適用されるキューイングの動作について説明します。
Based on the customer Service Level Agreement (SLA), traffic from a customer can be prioritized, policed, and shaped for QoS requirements. The queuing and forwarding policies can preserve the packet order and QoS parameters of customer traffic. The class of services can be mapped from information in the customer frames, or it can be independent of the frame content.
カスタマーサービスレベル契約（SLA）に基づいて、顧客からのトラフィックを優先順位付け、ポリシング、およびQoS要件に合わせて形作ることができます。キューイングおよび転送ポリシーは、顧客トラフィックのパケットオーダーとQoSパラメーターを保持できます。サービスのクラスは、顧客フレームの情報からマッピングすることも、フレームコンテンツとは無関係にすることもできます。
QoS functions can be listed as follows:
QoS関数は次のようにリストできます。
- Customer Traffic Prioritization: L2VPN services could be best effort or QoS guaranteed. Traffic from one customer might need to be prioritized over others when sharing same network resources. This requires capabilities within the L2VPN solution to classify and mark priority to QoS guaranteed customer traffic.
- 顧客のトラフィックの優先順位付け：L2VPNサービスが最善の努力またはQOSが保証される可能性があります。同じネットワークリソースを共有するときは、1人の顧客からのトラフィックを他の顧客よりも優先順位付けする必要がある場合があります。これには、L2VPNソリューション内の機能が必要であり、QoS保証された顧客トラフィックの優先度を分類およびマークします。
- Proper queuing behavior would be needed at the egress AC, and possibly within the backbone network as well. If queuing behavior must be controlled within the backbone network, the control might be based on CoS information in the MPLS or IP header, or it might be achieved by nesting particular tunnels within particular traffic engineering tunnels.
- Egress ACでは、おそらくバックボーンネットワーク内でも適切なキューイング動作が必要です。バックボーンネットワーク内でキューイングの動作を制御する必要がある場合、制御はMPLSまたはIPヘッダーのCOS情報に基づいている場合があります。または、特定のトラフィックエンジニアリングトンネル内で特定のトンネルをネストすることで達成される場合があります。
- Policing: This ensures that a user of L2VPN services uses network resources within the limits of the agreed SLA. Any excess L2VPN traffic can be rejected or handled differently based on provider policy.
- ポリシング：これにより、L2VPNサービスのユーザーが合意されたSLAの制限内でネットワークリソースを使用することが保証されます。過剰なL2VPNトラフィックは、プロバイダーポリシーに基づいて拒否または処理される可能性があります。
- Policing would generally be applied at the ingress AC.
- 通常、ポリシングはIngress ACで適用されます。
- Shaping: Under some cases, the random nature of L2VPN traffic might lead to sub-optimal utilization of network resources. Through queuing and forwarding mechanisms, the traffic can be shaped without altering the packet order.
- シェーピング：場合によっては、L2VPNトラフィックのランダムな性質がネットワークリソースの最適な利用につながる可能性があります。キューイングと転送メカニズムを通じて、パケットの順序を変更せずにトラフィックを形作ることができます。
- Shaping would generally be applied at the ingress AC.
- 通常、シェーピングはIngress ACで適用されます。
Resiliency describes the ability of the L2VPN infrastructure to protect a flow from network outage, so that service remains available in the presence of failures.
Resiliencyは、ネットワークの停止からフローを保護するL2VPNインフラストラクチャの能力を説明するため、障害の存在下でサービスが引き続き利用可能です。
L2VPN, like any other service, is subject to failures such as link, trunk, and node failures, both in the SP's core network infrastructure and on the ACs.
L2VPNは、他のサービスと同様に、SPのコアネットワークインフラストラクチャとACSの両方で、リンク、トランク、ノードの障害などの障害の対象となります。
It is desirable that the failure be detected "immediately" and that protection mechanisms allow fast restoration times to make L2VPN service almost transparent to these failures to the extent possible, based on the level of resiliency. Restoration should take place before the CEs can react to the failure. Essential aspects of providing resiliency are:
障害を「直ちに」検出し、保護メカニズムにより、復元力のレベルに基づいて、可能な限りL2VPNサービスを可能な限り透明にするために迅速な回復時間を可能にすることが望ましい。CESが障害に反応する前に、回復が行われる必要があります。回復力を提供することの重要な側面は次のとおりです。
- Link/Node failure detection: Mechanisms within the L2VPN service should allow for link or node failures that impact the service, and that should be detected immediately.
- リンク/ノード障害検出：L2VPNサービス内のメカニズムは、サービスに影響を与えるリンクまたはノードの障害を可能にする必要があり、すぐに検出する必要があります。
- Resiliency policy: The way in which a detected failure is handled will depend on the restoration policy of the SLA associated with the L2VPN service specification. It may need to be handled immediately, or it may need to be handled only if no other critical failure needs protection resources, or it may be completely ignored if it is within the bounds of the "acceptable downtime" allowed by the L2VPN service.
- 回復力のポリシー：検出された障害が処理される方法は、L2VPNサービス仕様に関連するSLAの修復ポリシーに依存します。すぐに処理する必要がある場合があります。または、他の重大な障害が保護リソースを必要としない場合にのみ処理する必要がある場合があります。または、L2VPNサービスで許可されている「許容されるダウンタイム」の範囲内にある場合は完全に無視される場合があります。
- Restoration Mechanisms: The L2VPN solutions could allow for physical level protection, logical level protection, or both. For example, by connecting customers over redundant and physically separate ACs to different provider customer-facing devices, one AC can be maintained as active, and the other could be marked as a backup; upon the failure detection across the primary AC, the backup could become active.
- 修復メカニズム：L2VPNソリューションにより、物理レベルの保護、論理レベル保護、またはその両方が可能になります。たとえば、冗長で物理的に分離したACをさまざまなプロバイダーの顧客向けデバイスに接続することにより、1つのACをアクティブとして維持でき、もう1つはバックアップとしてマークできます。プライマリAC全体で故障検出が行われると、バックアップがアクティブになる可能性があります。
To a great extent, resiliency is a matter of having appropriate failure and recovery mechanisms in the network core, including "ordinary" adaptive routing as well as "fast reroute" capabilities. The ability to support redundant ACs between CEs and PEs also plays a role.
大部分は、弾力性とは、「通常の」適応ルーティングや「高速リルート」機能など、ネットワークコアに適切な障害と回復のメカニズムを持つことの問題です。CESとPES間の冗長ACSをサポートする機能も役割を果たします。
An L2VPN solution can provide mechanisms to manage and monitor different L2VPN components. From a Service Level Agreement (SLA) perspective, L2VPN solutions could allow monitoring of L2VPN service characteristics and offer mechanisms used by Service Providers to report such monitored statistical data. Trouble-shooting and verification of operational and maintenance activities of L2VPN services are essential requirements for Service Providers.
L2VPNソリューションは、さまざまなL2VPNコンポーネントを管理および監視するメカニズムを提供できます。L2VPNソリューションは、サービスレベル契約（SLA）の観点から、L2VPNサービス特性の監視を可能にし、サービスプロバイダーがそのような監視された統計データを報告するメカニズムを提供することができます。L2VPNサービスの運用およびメンテナンス活動のトラブルシューティングと検証は、サービスプロバイダーにとって不可欠な要件です。
A VPWS is an L2VPN service in which each forwarder binds exactly one AC to exactly one PW. Frames received on the AC are transmitted on the PW; frames received on the PW are transmitted on the AC. The content of a frame's Layer2 header plays no role in the forwarding decision, except insofar as the Layer2 header contents are used to associate the frame with a particular AC (e.g., the DLCI field of a Frame Relay frame identifies the AC).
VPWSはL2VPNサービスであり、各フォワーダーは正確に1つのACを1つのPWにバインドします。ACで受信したフレームはPWに送信されます。PWで受信したフレームはACに送信されます。フレームのレイヤー2ヘッダーの内容は、レイヤー2ヘッダーの内容を使用してフレームを特定のACに関連付けるために使用される限り、転送決定に役割を果たしません（たとえば、フレームリレーフレームのDLCIフィールドがACを識別します）。
A particular combination of <AC, PW, AC> forms a "virtual circuit" between two CE devices.
<AC、PW、AC>の特定の組み合わせは、2つのCEデバイス間で「仮想回路」を形成します。
A particular VPN (VPWS instance) may be thought of as a collection of such virtual circuits, or as an "overlay" of PWs on the MPLS or IP backbone. This creates an overlay topology that is in effect the "virtual backbone" of a particular VPN.
特定のVPN（VPWSインスタンス）は、そのような仮想回路のコレクション、またはMPLSまたはIPバックボーン上のPWSの「オーバーレイ」と考えられる場合があります。これにより、特定のVPNの「仮想バックボーン」であるオーバーレイトポロジが作成されます。
Whether two virtual circuits are said to belong to the same VPN or not is an administrative matter based on the agreements between the SPs and their customers. This may impact the provisioning model (discussed below). It may also affect how particular PWs are assigned to tunnels, the way QoS is assigned to particular ACs and PWs, etc.
2つの仮想回路が同じVPNに属していると言われているかどうかは、SPSとその顧客との間の契約に基づく管理上の問題です。これは、プロビジョニングモデルに影響を与える可能性があります（以下で説明します）。また、特定のPWがトンネルにどのように割り当てられるか、QoSが特定のACSおよびPWSに割り当てられる方法に影響を与える可能性があります。
Note that VPWS makes use of point-to-point PWs exclusively.
VPWSは、ポイントツーポイントPWSのみを使用していることに注意してください。
Provisioning a VPWS is a matter of:
VPWSのプロビジョニングは次のとおりです。
1. Provisioning the ACs;
1. ACSのプロビジョニング。
2. Providing the PEs with the necessary information to enable them to set up PWs between ACs to result in the desired overlay topology; and
2. PESに必要な情報を提供して、ACS間でPWSをセットアップして目的のオーバーレイトポロジを提供します。と
3. Configuring the PWs with any necessary characteristics.
3. 必要な特性でPWSを構成します。
In many cases, the ACs must be individually provisioned on the PE and/or CE. This will certainly be the case if the CE/PE attachment technology is a switched network, such as ATM or FR, and the VCs are PVCs rather than SVCs. It is also the case whenever the individual Attachment Circuits need to be given specific parameters (e.g., QoS parameters, guaranteed bandwidth parameters) that differ from circuit to circuit.
多くの場合、ACSはPEおよび/またはCEで個別にプロビジョニングする必要があります。これは、CE/PEアタッチメントテクノロジーがATMやFRなどの切り替え済みネットワークであり、VCSがSVCではなくPVCSである場合、確かに当てはまります。また、回路ごとに異なる特定のパラメーター（QoSパラメーター、保証された帯域幅パラメーターなど）を個別のアタッチメントサーキットに指定する必要がある場合にも当てはまります。
There are also cases in which ACs might not have to be individually provisioned. For example, if an AC is just an MPLS LSP running between a CE and a PE, it could be set up as the RESULT of setting up a PW rather than having to be provisioned BEFORE the PW can be set up. The same may apply whenever the AC is a Switched Virtual Circuit of any sort, though in this case, various policy controls might need to be provisioned; e.g., limiting the number of ACs that can be set up between a given CE and a given PE.
ACSを個別にプロビジョニングする必要がない場合もあります。たとえば、ACがCEとPEの間で実行されるMPLS LSPのみである場合、PWをセットアップする前にプロビジョニングする必要があるのではなく、PWをセットアップした結果としてセットアップできます。ACがあらゆる種類のスイッチされた仮想回路である場合でも同じことが適用される場合がありますが、この場合、さまざまなポリシーコントロールをプロビジョニングする必要がある場合があります。たとえば、特定のCEと特定のPEの間に設定できるACの数を制限します。
Issues such as whether the Attachment Circuits need to be individually provisioned or not, whether they are Switched VCs or Permanent VCs, and what sorts of policy controls may be applied are implementation and deployment issues and are considered to be out of scope of this framework.
アタッチメントサーキットを個別にプロビジョニングする必要があるかどうか、VCSまたは永久VCの切り替え、適用される可能性のある種類のポリシーコントロールが実装および展開の問題であり、このフレームワークの範囲外であると見なされるなどの問題。
In order to support arbitrary overlay topologies, it is necessary to allow the provisioning of individual PWs. In this model, when a PW is provisioned on a PE device, it is locally bound to a specific AC. It is also provisioned with information that identifies a specific AC at a remote PE.
任意のオーバーレイトポロジーをサポートするには、個々のPWのプロビジョニングを許可する必要があります。このモデルでは、PWがPEデバイスにプロビジョニングされると、特定のACに局所的に結合されます。また、リモートPEで特定のACを識別する情報も提供されています。
There are basically two variations of this provisioning model:
基本的に、このプロビジョニングモデルには2つのバリエーションがあります。
- Two-sided provisioning
- 両面プロビジョニング
With two-sided provisioning, each PE that is at the end of a PW is provisioned with the following information:
両面プロビジョニングを使用すると、PWの最後にある各PEには、次の情報がプロビジョニングされます。
* Identifier of the Local AC to which the PW is to be bound
* PWが拘束されるローカルACの識別子
* PW type and parameters
* PWタイプとパラメーター
* IP address of the remote PE (i.e., the PE that is to be at the remote end of the PW)
* リモートPEのIPアドレス（つまり、PWのリモートエンドにあるPE）
* Identifier that is meaningful to the remote PE, and that can be passed in the PW signaling protocol to enable the remote PE to bind the PW to the proper AC. This can be an identifier of the PW or an identifier of the remote AC. If a PW identifier is used, it must be unique at each of the two PEs. If an AC identifier is used, it need only be unique at the remote PE.
* リモートPEにとって意味のある識別子であり、PWシグナリングプロトコルに渡すことができ、リモートPEがPWを適切なACに結合できるようにします。これは、PWの識別子またはリモートACの識別子にすることができます。PW識別子を使用する場合、2つのPEのそれぞれで一意でなければなりません。AC識別子を使用する場合、リモートPEで一意である必要があります。
This identifier is then used as the Remote Forwarder Selector when signaling is done (see 3.2.6.1).
この識別子は、シグナリングが行われたときにリモートフォワーダーセレクターとして使用されます（3.2.6.1を参照）。
- Single-sided provisioning
- 片面プロビジョニング
With single-sided provisioning, a PE at one end of a PW is provisioned with the following information:
片面プロビジョニングでは、PWの一方の端にあるPEに次の情報がプロビジョニングされます。
* Identifier of the Local AC to which the PW is to be bound
* PWが拘束されるローカルACの識別子
* PW type and parameters
* PWタイプとパラメーター
* Globally unique identifier of remote AC
* リモートACのグローバルに一意の識別子
This identifier is then used as the Forwarder Selector when signaling is done (see section 3.2.6.1).
この識別子は、シグナリングが行われたときにフォワーダーセレクターとして使用されます（セクション3.2.6.1を参照）。
In this provisioning model, the IP address of the remote PE is not provisioned. Rather, the assumption is that an auto-discovery scheme will be used to map the globally unique identifier to the IP address of the remote PE, along with an identifier (perhaps unique only at the latter PE) for an AC at that PE. The PW signaling protocol can then make a connection to the remote PE, passing the AC identifier, so that the remote PE binds the PW to the proper AC.
このプロビジョニングモデルでは、リモートPEのIPアドレスはプロビジョニングされていません。むしろ、自動発見スキームを使用して、グローバルに一意の識別子をリモートPEのIPアドレスにマッピングするために使用されるということです。PWシグナル伝達プロトコルは、リモートPEに接続してAC識別子を渡すことができ、リモートPEがPWを適切なACにバインドするようにします。
This scheme requires provisioning of the PW at only one PE, but it does not eliminate the need (if there is a need) to provision the ACs at both PEs.
このスキームでは、PWの1つのPEのみでのプロビジョニングが必要ですが、両方のPEでACSをプロビジョニングする必要性（必要な場合）を排除しません。
These provisioning models fit well with the use of point-to-point signaling. When each PW is individually provisioned, as the conditions necessary for the use of point-to-multipoint signaling do not hold.
これらのプロビジョニングモデルは、ポイントツーポイントシグナル伝達の使用によく適合します。ポイントツーマルチポイントシグナル伝達の使用に必要な条件が保持されないため、各PWが個別にプロビジョニングされている場合。
Suppose that at each PE, sets of ACs are gathered together into "pools", and that each such pool is assigned a "color". (For example, a pool might contain all and only the ACs from this PE to a particular CE.) Now suppose that we impose the following rule: whenever PE1 and PE2 have a pool of the same color, there will be a PW between PE1 and PE2 that is bound at PE1 to an arbitrarily chosen AC from that pool, and at PE2 to an arbitrarily chosen AC from that pool. (We do not rule out the case where a single PE has multiple pools of a given color.)
各PEで、ACのセットが「プール」に集められ、そのような各プールに「色」が割り当てられていると仮定します。（たとえば、プールには、このPEから特定のCEへのACSのみがすべて含まれる場合があります。）次のルールを課すと仮定します。PE1とPE2に同じ色のプールがある場合はいつでも、PE1の間にPWがあります。PE2は、そのプールから任意に選択されたACにPE1に結合し、PE2でそのプールから任意に選択されたACに結合します。（単一のPEに特定の色の複数のプールがある場合を除外しません。）
For example, each pool in a particular PE might represent a particular CE device, for which the ACs in the pool are the ACs connecting that CE to that PE. The color might be a VPN-id. Application of this provisioning model would then lead to a full CE-to-CE mesh within the VPN, where every CE in the VPN has a virtual circuit to every other CE within the VPN.
たとえば、特定のPE内の各プールは、特定のCEデバイスを表す場合があります。このデバイスでは、プール内のACSがそのCEをそのPEに接続するACSです。色はVPN-IDかもしれません。このプロビジョニングモデルを適用すると、VPN内の完全なCE-CE-CEメッシュが発生し、VPN内のすべてのCEがVPN内の他のすべてのCEに仮想回路を備えています。
More specifically, to provision VPWS according to this model, one provisions a set of pools and configures each pool with the following information:
より具体的には、このモデルに従ってVPWSを提供するには、1つのプールを提供し、各プールに次の情報を設定します。
- The set of ACs that belong to the pool (with no AC belonging to more than one pool)
- プールに属するACSのセット（ACが複数のプールに属していない）
- The color
- 色
- A pool identifier that is unique at least relative to the color.
- 少なくとも色と比較して一意のプール識別子。
An auto-discovery procedure is then used to map each color into a list of ordered pairs <IP address of PE, pool id>. The occurrence of a pair <X, Y> on this list means that the PE at IP address X has a pool with pool id Y, which is of the specified color.
次に、自動発見手順を使用して、各色を順序付けられたペアのリスト<PE、プールID>のリストにマッピングします。このリストでのペア<x、y>の発生は、IPアドレスXのPEに、指定された色のプールID yを備えたプールがあることを意味します。
This information can be used to support several different signaling techniques. One possible technique proceeds as follows:
この情報は、いくつかの異なるシグナル伝達手法をサポートするために使用できます。考えられるテクニックの1つは次のように進行します。
- A PE finds that it has a pool of color C.
- PEは、色Cのプールがあることを発見します。
- Using auto-discovery, it obtains the set of ordered pairs <X,Y> for color C.
- 自動発見を使用すると、色Cの順序付きペア<x、y>のセットが取得されます。
- For each such pair <X,Y>, it:
- そのようなペアごとに<x、y>、それ：
* removes an AC from the pool;
* プールからACを削除します。
* binds the AC to a particular PW; and
* ACを特定のPWに結合します。と
* signals PE X via point-to-point signaling that the PW is to be bound to an AC from pool Y.
* PWがプールYからACにバインドされることをポイントツーポイント信号を介してPE Xを信号します。
Another possible signaling technique is the following:
別の可能なシグナル伝達手法は次のとおりです。
- A PE finds that it has a pool of color C, containing n ACs.
- PEは、N ACを含む色Cのプールがあることを発見します。
- It binds each AC to a PW, creating a set of PWs. This set of PWs is then organized into a sequence. (For instance, each PW may be associated with a demultiplexor field value, and the PWs may then be sequenced according to the numerical value of their respective demultiplexors.)
- 各ACをPWに結合し、PWSのセットを作成します。このPWSのセットは、シーケンスに編成されます。（たとえば、各PWは非gultiplexorフィールド値に関連付けられている可能性があり、PWSは、それぞれのDemultiplexorの数値に従って配列決定される場合があります。）
- Using auto-discovery, it obtains the list of PE routers that have one or more pools of color C.
- 自動発見を使用して、1色Cの1つ以上のプールを持つPEルーターのリストを取得します。
- It signals each such PE router, specifying the sequence Q of PWs.
- PWSのシーケンスQを指定して、そのような各PEルーターを指定します。
- If PE X receives such a signal and PE X has a pool Y of the specified color, it:
- PE Xがそのような信号を受け取り、PE Xに指定された色のプールがある場合、それは次のとおりです。
* removes an AC from the pool; and
* プールからACを削除します。と
* binds the AC to the PW that is the "Yth" PW in the sequence Q.
* ACをシーケンスQの「Yth」PWであるPWに結合します。
This presumes, of course, that the pool identifiers are or can be uniquely mapped into small ordinal numbers; assigning the pool identifiers in this way becomes a requirement of the provisioning system.
これは、もちろん、プール識別子が小さな順序数に一意にマッピングされるか、または単独でマッピングできると推定しています。この方法でプール識別子を割り当てることは、プロビジョニングシステムの要件になります。
Note that since this technique signals the same information to all the remote PEs, it can be supported via point-to-multipoint signaling.
この手法はすべてのリモートPEに対して同じ情報を信号するため、ポイントツーマルチポイントシグナルを介してサポートできることに注意してください。
This provisioning model can be applied as long as the following conditions hold:
このプロビジョニングモデルは、次の条件が当てはまる限り適用できます。
- There is no need to provision different characteristics for the different PWs;
- 異なるPWSに対して異なる特性を提供する必要はありません。
- It makes no difference which pairs of ACs are bound together by PWs, as long as both ACs in the pair come from like-colored pools; and
- ペアの両方のACが同様の色のプールから来ている限り、どのACのペアがPWSによって結合されるかは違いはありません。と
- It is possible to construct the desired overlay topology simply by assigning colors to the pools. (This is certainly simple if a full mesh is desired, or if a hub and spoke configuration is desired; creating arbitrary topologies is less simple, and is perhaps not always possible.)
- プールに色を割り当てるだけで、目的のオーバーレイトポロジを構築することが可能です。（これは、完全なメッシュが必要な場合、またはハブとスポークの構成が望ましい場合は確かに簡単です。任意のトポロジを作成することはそれほど簡単ではなく、おそらく常に可能ではありません。）
Some of the requirements for auto-discovery procedures can be deduced from the above.
自動発見手順の要件の一部は、上記から推測できます。
To support the single-sided provisioning model, auto-discovery must be able to map a globally unique identifier (of a PW or of an Attachment Circuit) to an IP address of a PE.
片面プロビジョニングモデルをサポートするには、自動ディスコービリは、グローバルに一意の識別子（PWまたはアタッチメント回路の）をPEのIPアドレスにマッピングできる必要があります。
To support the colored pools provisioning model, auto-discovery must enable a PE to determine the set of other PEs that contain pools of the same color.
Colored Pools Provisioningモデルをサポートするには、Auto-Discoveryを使用すると、PEが同じ色のプールを含む他のPEのセットを決定する必要があります。
These requirements enable the auto-discovery scheme to provide the information, which the PEs need to set up the PWs.
これらの要件により、PESがPWSをセットアップするために必要な情報を自動配置スキームで提供できます。
There are additional requirements on the auto-discovery procedures that cannot simply be deduced from the provisioning model:
プロビジョニングモデルから単純に推測することはできない自動配置手順には、追加の要件があります。
- Particular signaling schemes may require additional information before they can proceed and hence may impose additional requirements on the auto-discovery procedures.
- 特定のシグナリングスキームは、進行する前に追加情報を必要とする場合があるため、自動配置手順に追加の要件を課す可能性があります。
- A given Service Provider may support several different types of signaling procedures, and thus the PEs may need to learn, via auto-discovery, which signaling procedures to use.
- 特定のサービスプロバイダーは、いくつかの異なるタイプのシグナル伝達手順をサポートする可能性があるため、PESは、使用するシグナリング手順を自動配置して学習する必要がある場合があります。
- Changes in the configuration of a PE should be reflected by the auto-discovery procedures, within a timely manner, and without the need to explicitly reconfigure any other PE.
- PEの構成の変更は、タイムリーな方法で、他のPEを明示的に再構成する必要なく、自動発見手順によって反映される必要があります。
- The auto-configuration procedures must work across service provider boundaries. This rules out, e.g., use of schemes that piggyback the auto-discovery information on the backbone's IGP.
- 自動構成手順は、サービスプロバイダーの境界を越えて動作する必要があります。これは、たとえば、バックボーンのIGPで自動発見情報をピギーバックするスキームの使用を排除します。
Under certain circumstances, it may be desirable to have a PW that binds two ACs that use different technologies (e.g., one is ATM, one is Ethernet). There are a number of different ways, depending on the AC types, in which this can be done. For example:
特定の状況では、異なるテクノロジーを使用する2つのACSに結合するPWを持つことが望ましい場合があります（たとえば、1つはATM、1つはイーサネットです）。ACタイプに応じて、これを行うことができるさまざまな方法があります。例えば：
- If one AC is ATM and one is FR, then standard ATM/FR Network Interworking can be used. In this case, the PW might be signaled for ATM, where the Interworking function occurs between the PW and the FR AC.
- 1つのACがATMで、1つがFRの場合、標準のATM/FRネットワークインターワーキングを使用できます。この場合、PWはPWとFR ACの間でインターワーキング関数が発生するATMに対してシグナル伝達される可能性があります。
- A common encapsulation can be used on both ACs, if for example, one AC is Ethernet and one is FR, an "Ethernet over FR" encapsulation can be used on the latter. In this case, the PW could be signaled for Ethernet, with processing of the Ethernet over FR encapsulation local to the PE with the FR AC.
- たとえば、1つのACがイーサネットであり、1つがFRである場合、両方のACSで一般的なカプセル化を使用できます。後者には「イーサネット上のFR」カプセル化を使用できます。この場合、FR ACを使用してPEに局所的に存在するFRカプセル化上のイーサネットの処理により、PWはイーサネットに合図される可能性があります。
- If it is known that the two ACs attach to IP routers or hosts and carry only IP traffic, then one could use a PW that carries the IP packets, and the respective Layer2 encapsulations would be local matters for the two PEs. However, if one of the ACs is a LAN and one is a point-to-point link, care would have to be taken to ensure that procedures such as ARP and Inverse ARP are properly handled; this might require some signaling, and some proxy functions. Further, if the CEs use a routing algorithm that has different procedures for LAN interfaces than those for point-to-point interfaces, additional mechanisms may be required to ensure proper interworking.
- 2つのACSがIPルーターまたはホストに付着してIPトラフィックのみを搭載していることがわかっている場合、1つはIPパケットを運ぶPWを使用でき、それぞれのLayer2カプセルは2つのPEの局所問題です。ただし、ACSの1つがLANであり、1つがポイントツーポイントリンクである場合、ARPや逆ARPなどの手順が適切に処理されるように注意する必要があります。これには、いくつかのシグナル伝達が必要になる場合があり、いくつかのプロキシ関数が必要になる場合があります。さらに、CESがポイントツーポイントインターフェイスの手順とは異なる手順を持つルーティングアルゴリズムを使用している場合、適切なインターワーキングを確保するために追加のメカニズムが必要になる場合があります。
A VPLS is an L2VPN service in which:
VPLSはL2VPNサービスです。
- the ACs attach CE devices to PE bridge modules; and
- ACSは、CEデバイスをPEブリッジモジュールに接続します。と
- each PE bridge module is attached via an "emulated LAN interface" to an "emulated LAN".
- 各PEブリッジモジュールは、「エミュレートされたLANインターフェイス」を介して「エミュレートされたLAN」に接続されています。
This is shown in Figure 3.
これを図3に示します。
In this section, we examine the functional decomposition of the VPLS Emulated LAN. An Emulated LAN's ACs are the "emulated LAN interfaces" attaching PE bridge modules to the "VPLS Forwarder" modules (see Figure 3). The payload on the ACs consists of ethernet frames, with or without VLAN headers.
このセクションでは、VPLSエミュレートされたLANの機能的分解を調べます。エミュレートされたLANのACSは、「VPLSフォワーダー」モジュールにPEブリッジモジュールを取り付ける「エミュレートLANインターフェイス」です（図3を参照）。ACSのペイロードは、VLANヘッダーの有無にかかわらず、イーサネットフレームで構成されています。
A given VPLS Forwarder in a given PE will have multiple ACs only if there are multiple bridge modules in that PE that attach to that Forwarder. This scenario is included in the Framework, though discussion of its utility is out of scope.
指定されたPEの特定のVPLS転送業者は、そのフォワーダーに付着するPEに複数のブリッジモジュールがある場合にのみ、複数のACSを持ちます。このシナリオはフレームワークに含まれていますが、そのユーティリティの議論は範囲外です。
The set of VPLS Forwarders within a single VPLS are connected via PWs. Two VPLS Forwarders will have a PW between them only if those two Forwarders are part of the same VPLS. (There may be a further restriction that two VPLS Forwarders have a PW between them only if those two Forwarders belong to the same VLAN in the same VPN.) A particular set of interconnected VPLS Forwarders is what constitutes a VPLS Emulated LAN.
単一のVPLS内のVPLSフォワーダーのセットは、PWSを介して接続されています。2つのVPLSフォワーダーは、これら2つのフォワーダーが同じVPLの一部である場合にのみ、それらの間にPWを持ちます。（2つのVPLSフォワーダーがそれらの2つのフォワーダーが同じVPNで同じVLANに属している場合にのみ、それらの間にPWを持っているというさらなる制限があるかもしれません。）相互接続されたVPLSフォワーダーの特定のセットは、VPLSエミュレートされたLANを構成するものです。
On a real LAN, any frame transmitted by one entity is received by all the others. A VPLS Emulated LAN, however, behaves somewhat differently. When a VPLS Forwarder receives a unicast frame over one of its Emulated LAN interfaces, the Forwarder does not necessarily send the frame to all the other Forwarders on that Emulated LAN. A unicast frame needs to be sent to only one other Forwarder in order to be properly delivered to its destination MAC address. If the transmitting Forwarder knows which other Forwarder needs to receive a particular unicast frame, it will send the frame to just that one Forwarder. This forwarding optimization is an important part of any attempt to provide a VPLS service over a wide-area or metropolitan area network.
実際のLANでは、1つのエンティティによって送信されたフレームが他のすべてのエンティティによって受信されます。ただし、VPLSエミュレートされたLANは、幾分異なって動作します。VPLSフォワーダーがエミュレートされたLANインターフェイスの1つでユニキャストフレームを受信する場合、フォワーダーは必ずしもそのエミュレートされたLANの他のすべてのフォワーダーにフレームを送信するわけではありません。ユニキャストフレームは、宛先MACアドレスに適切に配信されるために、他の1つのフォワーダーのみに送信する必要があります。送信先の転送者が、他のフォワーダーが特定のユニキャストフレームを受信する必要があるかを知っている場合、その1つのフォワーダーにフレームを送信します。この転送最適化は、広い地域または大都市圏ネットワークを介してVPLSサービスを提供する試みの重要な部分です。
In effect, then, each Forwarder behaves as a "Virtual Switch Instance" (VSI), maintaining a forwarding table that maps MAC addresses to PWs. The VSI is populated in much the same way that a standard bridge populates its forwarding table. The VPLS Forwarders do MAC Source Address (SA) learning on frames received on PWs from other Forwarders and must also do the related set of procedures, such as aging out address entries. Frames with unknown DAs or multicast DAs must be "broadcast" by one Forwarder to all the others (on the same emulated LAN). There are, however, a few important differences between the VPLS Forwarder VSI and the standard bridge forwarding function:
実際には、各フォワーダーは「仮想スイッチインスタンス」（VSI）として動作し、MACがPWSにアドレス指定する転送テーブルを維持します。VSIは、標準的なブリッジが転送テーブルに浸透するのとほぼ同じ方法で入力されています。VPLSフォワーダーは、他のフォワーダーからPWSで受信したフレームでMACソースアドレス（SA）学習を行い、アドレスエントリの老化など、関連する手順セットも実行する必要があります。未知のDASまたはマルチキャストDAを持つフレームは、他のすべてのフォワード（同じエミュレートLAN）に1つのフォワーダーによって「ブロードキャスト」する必要があります。ただし、VPLSフォワーダーVSIと標準ブリッジ転送機能の間には、いくつかの重要な違いがあります。
- A VPLS Forwarder never learns the MAC SAs of frames that it receives on its ACs; it only learns the MAC SAs of frames that are received on PWs from other VPLS Forwarders; and
- VPLSフォワーダーは、ACSで受信するフレームのMac SASを学習することはありません。他のVPLSフォワーダーからPWSで受信されたMac Sas of Framesのみを学習します。と
- The VPLS Forwarders of a particular emulated LAN do not participate in a spanning tree protocol with each other. A "split horizon" technique is used to prevent forwarding loops.
- 特定のエミュレートされたLANのVPLSフォワーダーは、スパニングツリープロトコルに互いに参加しません。転送ループを防ぐために、「スプリットホライズン」手法が使用されます。
These points are discussed further in the next section.
これらのポイントについては、次のセクションでさらに説明します。
Note that the PE bridge modules that are on a given Emulated LAN may or may not run a spanning tree protocol with each other over the Emulated LAN; whether they do so or not is outside the scope of the VPLS specifications. The PE bridge modules will do MAC address learning on the ACs. The PE bridge modules also do MAC address learning on the Emulated LAN interfaces, but do not do MAC address learning on the PWs, as the PWs are "hidden" behind the Emulated LAN interface. Conceptually, the PE bridge module's forwarding table and the VPLS Forwarder's VSI are distinct entities. (Of course, particular implementations might combine these into a single table, but that is beyond the scope of this document.)
特定のエミュレートされたLAN上にあるPEブリッジモジュールは、エミュレートされたLANを介してスパニングツリープロトコルを互いに実行する場合と実行できない場合があることに注意してください。彼らがそうするかどうかは、VPLS仕様の範囲外です。PEブリッジモジュールは、ACSでMACアドレス学習を行います。PEブリッジモジュールは、エミュレートされたLANインターフェイスでMACアドレス学習を行いますが、PWSはエミュレートされたLANインターフェイスの背後に「隠されている」ため、PWSでMACアドレス学習を行いません。概念的には、PEブリッジモジュールの転送テーブルとVPLSフォワーダーのVSIは、明確なエンティティです。（もちろん、特定の実装はこれらを単一のテーブルに結合する可能性がありますが、それはこのドキュメントの範囲を超えています。）
A further issue arises if the PE bridges run bridge control protocols with each other over the Emulated LAN. Bridge control protocols are generally designed to run in over a real LAN and may presume, for their proper functioning, certain characteristics of the LAN, such as low latency and sequential delivery. If the Emulated LAN does not provide these characteristics, the control protocols may not perform as expected unless special mechanisms are provided for carrying the control frames.
PEブリッジがエミュレートされたLANでブリッジ制御プロトコルを互いに実行している場合、さらなる問題が発生します。ブリッジ制御プロトコルは一般に、実際のLANの上で実行されるように設計されており、適切な機能のために、LANの特定の特性（低遅延や順次配信など）が推測される場合があります。エミュレートされたLANがこれらの特性を提供しない場合、コントロールフレームを運ぶために特別なメカニズムが提供されない限り、制御プロトコルは期待どおりに実行されない場合があります。
It should be noted that changes in the spanning tree (if any) of a customer network, or in the spanning tree (if any) of the PE bridges, may cause certain MAC addresses to change their location from one PE to another. These changes may not be visible to the VPLS Forwarders, which means that those MAC addresses might become unreachable until they are aged out of the first PE's VSI. If this is not acceptable, some mechanism for communicating such changes to the VPLS Forwarders must be provided.
顧客ネットワークのスパニングツリー（もしあれば）、またはPEブリッジのスパニングツリー（存在する場合）の変更により、特定のMACアドレスが位置をPEから別のPEに変更する可能性があることに注意する必要があります。これらの変更はVPLSフォワーダーには見えない場合があります。つまり、これらのMacアドレスは、最初のPEのVSIから老化するまで到達できなくなる可能性があります。これが受け入れられない場合、VPLSフォワーダーにそのような変更を伝えるためのいくつかのメカニズムを提供する必要があります。
Within a single VPLS, the VPLS Forwarders are interconnected by PWs. The set of PWs thus forms an "overlay topology".
単一のVPLS内で、VPLSフォワーダーはPWSによって相互接続されています。したがって、PWSのセットは「オーバーレイトポロジ」を形成します。
The VPLS Forwarder VSIs are populated by means of MAC address learning. That is, the VSI keeps track of which MAC SAs have been received over which PWs. The presumption, of course, is that if a particular MAC address appears as the SA of a frame received over a particular PW, then frames that carry that MAC address in the DA field should be sent to the VSI that is at the remote end of the PW. In order for this presumption to be true, there must be a unique VSI at the remote end of the PW, which means that VSIs cannot be interconnected by means of multipoint-to-point PWs. The PWs are necessarily either point-to-point or, possibly, point-to-multipoint.
VPLSフォワーダーVSIには、MACアドレス学習を使用して入力されます。つまり、VSIは、どのPWSでMac SAが受信されたかを追跡します。もちろん、特定のMACアドレスが特定のPWで受信されたフレームのSAとして表示される場合、DAフィールドのMACアドレスを運ぶフレームは、のリモートエンドにあるVSIに送信する必要があるということです。PW。この推定が真実であるためには、PWのリモートエンドに一意のVSIがなければなりません。つまり、VSIはマルチポイント間PWSによって相互接続できません。PWSは、必然的にポイントツーポイントまたは、おそらくポイントツーマルチポイントのいずれかです。
MAC learning over a point-to-point PW is done via the standard techniques as specified by IEEE, where the PW is treated by the VPLS Forwarder as a "bridge port". Of course, if a MAC address is learned from a point-to-multipoint PW, the VSI must indicate that packets to that address are to be sent over a point-to-point PW that leads to the root of that point-to-multipoint PW.
ポイントツーポイントPWでのMAC学習は、IEEEによって指定された標準技術を介して行われます。PWは、VPLSフォワーダーによって「ブリッジポート」として処理されます。もちろん、MACアドレスがポイントツーマルチポイントPWから学習されている場合、VSIは、そのアドレスへのパケットがそのポイントツーポイントのルートにつながるポイントツーポイントPWで送信されることを示す必要があります。マルチポイントPW。
The VSI forwarding decisions must be coordinated so that loop-free forwarding over the overlay topology is ensured.
VSI転送の決定は、オーバーレイトポロジに対するループフリーの転送が確保されるように調整する必要があります。
There are several possible types of overlay topologies:
オーバーレイトポロジにはいくつかのタイプがあります：
- Full mesh
- フルメッシュ
In a full mesh, every VSI in a given VPLS has exactly one point-to-point PW to every other VSI in that same VPLS.
完全なメッシュでは、特定のVPLSのすべてのVSIには、同じVPLの他のすべてのVSIに対して1つのポイントツーポイントPWが1つあります。
In this topology, loop free forwarding of frames is ensured by the following rule: if a VSI receives a frame, over a PW, from another VSI, it MUST NOT forward that frame over ANY other PW to any other VSI. This ensures that once a frame traverses the Emulated LAN, it must be sent off the Emulated LAN.
このトポロジでは、フレームのループフリー転送が次のルールによって保証されます。VSIが別のVSIからPWを超えてフレームを受信した場合、そのフレームを他のVSIに転送してはなりません。これにより、フレームがエミュレートされたLANを通過すると、エミュレートされたLANから送信される必要があります。
If a VSI receives, on one of its Emulated LAN interfaces, a unicast frame with a known DA, the frame is sent on exactly one point-to-point PW.
VSIがエミュレートされたLANインターフェイスの1つで、既知のDAを備えたユニキャストフレームを受信した場合、フレームはちょうど1つのポイントツーポイントPWに送信されます。
If a VSI receives, on one of its Emulated LAN interfaces, a multicast frame or a unicast frame with an unknown DA, it sends a copy of the frame to each other VSI in the same Emulated LAN. This can be done by replicating the frame and sending a copy over each point-to-point PW. Alternatively, the full mesh of point-to-point PWs may be augmented with point-to-multipoint PWs, where each VSI in a VPLS is the transmitter on a single point-to-multipoint PW, and the receivers on that PW are all the other VSIs in that VPLS.
VSIが、エミュレートされたLANインターフェイスの1つで、マルチキャストフレーム、または不明なDAを備えたユニキャストフレームを受信した場合、同じエミュレートされたLANでフレームのコピーを互いにVSIに送信します。これは、フレームを複製し、各ポイントツーポイントPWにコピーを送信することで実行できます。あるいは、ポイントツーポイントPWSの完全なメッシュはポイントツーマルチポイントPWSで補強される場合があります。VPLSの各VSIは単一のポイントツーマルチポイントPWの送信機であり、そのPWの受信機はすべてそのVPLの他のVSI。
- Tree structured
- 構造化された木
In a tree structured topology, every VSI in a particular VPLS is provisioned to be at a particular level in the tree. A given VSI has at most one pseudowire leading to a higher level. The root of the tree is considered the highest level.
ツリー構造のトポロジーでは、特定のVPLのすべてのVSIが、ツリー内の特定のレベルにあるようにプロビジョニングされます。与えられたVSIには、せいぜい1つの擬似ワイヤがあり、より高いレベルにつながります。ツリーの根は最高レベルと見なされます。
In this topology, loop free forwarding of frames is ensured by the following rule: if a frame is received over a pseudowire from a higher level, it may not be sent over a pseudowire that leads to a higher level.
このトポロジでは、フレームのループフリー転送が次のルールによって保証されます。フレームがより高いレベルから擬似著者を受信した場合、より高いレベルにつながる擬似ワイヤーに送信されない場合があります。
- Tree with Meshed Highest Level
- メッシュで最高レベルの木
In this variant of the tree-structured topology, there may be more than one VSI at the highest level, but the set of VSIs that are at the highest level must be fully meshed. To ensure loop free forwarding, we need to impose the rule that a frame can be sent on a pseudowire to the same or higher level only if it arrived over a pseudowire from a lower level, and that frames arriving over PWs from the same level cannot be sent on PWs to the same level.
ツリー構造のトポロジのこのバリアントでは、最高レベルで複数のVSIがある場合がありますが、最高レベルのVSIのセットは完全にメッシュ化する必要があります。ループフリー転送を確保するには、低レベルから擬似ワイヤーに到着した場合にのみ、フレームを同じレベルにフレームに送信できるというルールを課す必要があります。PWSで同じレベルに送られます。
Other overlay topologies are also possible; e.g., an arbitrary partial mesh of PWs among the VSIs of a VPLS. Loop-freedom could then be assured by, for example, running a spanning tree on the overlay. These topologies are not further considered in this framework.
他のオーバーレイトポロジも可能です。たとえば、VPLSのVSIの間のPWSの任意の部分的なメッシュ。たとえば、オーバーレイでスパニングツリーを実行することにより、ループフリードムを保証できます。これらのトポロジは、このフレームワークではさらに考慮されていません。
Note that loop freedom in the overlay topology does not necessarily ensure loop freedom in the overall customer LAN that contains the VPLS. It does not even ensure loop freedom among the PE bridge modules. It ensures only that when a frame is sent on the Emulated LAN, the frame will not loop endlessly before (or instead of) leaving the Emulated LAN.
オーバーレイトポロジのループの自由度は、VPLSを含む顧客全体のLAN全体のループの自由を必ずしも保証しないことに注意してください。PEブリッジモジュール間のループの自由さえ保証していません。エミュレートされたLANにフレームが送信された場合、フレームはエミュレートされたLANを離れる前（またはその代わりに）際限に際限なくループしないことを保証します。
Improper configuration of the customer LAN or PE bridge modules may cause frames to loop, and frames that fall into such loops may transit the overlay topology multiple times. Procedures that enable the PE to detect and/or prevent such loops may be advisable.
顧客LANまたはPEブリッジモジュールの不適切な構成により、フレームがループが発生する可能性があり、そのようなループに該当するフレームはオーバーレイトポロジーを複数回通過する可能性があります。PEがそのようなループを検出および/または防止できるようにする手順が推奨される場合があります。
Each VPLS must be assigned a globally unique identifier. This can be thought of as a VPN-id.
各VPLには、グローバルに一意の識別子を割り当てる必要があります。これはVPN-IDと考えることができます。
The ACs attaching the CEs to the PEs must be provisioned on both the PEs and the CEs. A VSI for that VPLS must be provisioned on the PE, and the local ACs of that VPLS must be associated with that VSI. The VSI must be provisioned with the identifier of the VPLS to which it belongs.
PESにCESを取り付けるACSは、PESとCESの両方にプロビジョニングする必要があります。そのVPLのVSIはPEにプロビジョニングする必要があり、そのVPLのローカルACSはそのVSIに関連付けられている必要があります。VSIは、それが属するVPLの識別子でプロビジョニングする必要があります。
An auto-discovery scheme may be used by a PE to map a VPLS identifier into the set of remote PEs that have VSIs in that VPLS. Once this set is determined, the PE can use pseudowire signaling to set up a PW to each of those VSIs. The VPLS identifier would serve as the signaling protocol's Forwarder Selector. This would result in a full mesh of PWs among the VSIs in a particular VPLS.
PEで自動発見スキームを使用して、VPLS識別子をそのVPLSにVSIを持つリモートPEのセットにマッピングすることができます。このセットが決定されると、PEはPseudowireシグナル伝達を使用して、これらのVSIのそれぞれにPWを設定できます。VPLS識別子は、シグナリングプロトコルのフォワーダーセレクターとして機能します。これにより、特定のVPLSのVSIの間でPWSの完全なメッシュが生じます。
If a single VPLS contains multiple VLANs, then it may be desirable to limit connectivity so that two VSIs are connected only if they have a VLAN in common.
単一のVPLに複数のVLANが含まれている場合、2つのVSIが共通のVLANがある場合にのみ接続されるように、接続を制限することが望ましい場合があります。
In this case, each VSI would need to be provisioned with one or more VLAN ids, and the auto-discovery scheme would need to map a VPLS identifier into pairs of <PE, VLAN id>.
この場合、各VSIは1つ以上のVLAN IDでプロビジョニングする必要があり、自動配置スキームはVPLS識別子を<PE、VLAN ID>のペアにマッピングする必要があります。
If a fully meshed topology of VSIs is not desired, then each VSI needs to be provisioned with additional information specifying its placement in the topology. This information would also need to be provided by the auto-discovery scheme.
VSIの完全にメッシュ化されたトポロジが望まれない場合、各VSIにトポロジに配置された追加情報を提供する必要があります。この情報は、自動発見スキームによっても提供する必要があります。
Alternatively, the single-sided provisioning method discussed in Section 3.3.1.2 could be used. As this is more complicated, it would only be used if it were necessary to associate individual PWs with individual characteristics. For example, if different guaranteed bandwidths were needed between different pairs of sites within a VPLS, the PWs would have to be provisioned individually.
あるいは、セクション3.3.1.2で説明した片面プロビジョニング方法を使用できます。これはより複雑であるため、個々のPWSを個々の特性と関連付ける必要がある場合にのみ使用されます。たとえば、VPLS内の異なるサイトのペア間で異なる保証された帯域幅が必要である場合、PWSを個別にプロビジョニングする必要があります。
Often, when a VPLS type of service is provided, the CE devices attach to a provider-managed CPE device. This provider-managed CPE device may attach to CEs of multiple customers, especially if, for example, there are multiple customers occupying the same building. However, this device is really part of the SP's network, hence may be considered a PE device.
多くの場合、VPLSタイプのサービスが提供されると、CEデバイスがプロバイダー管理CPEデバイスに接続されます。このプロバイダーが管理したCPEデバイスは、特に同じ建物を占める複数の顧客がいる場合、複数の顧客のCESに接続する場合があります。ただし、このデバイスは実際にはSPのネットワークの一部であるため、PEデバイスと見なされる場合があります。
In some scenarios in which a VPLS type of service is provided, the CE devices attach to a provider-managed intermediary device. This provider-managed device may attach to CEs of multiple customers. This may arise if there are multiple customers occupying the same building. This device is really part of the SP's network and may for that reason be considered to be a PE device; however, in the simplest case, it is performing only aggregation and none of the function associated with a VPLS.
VPLSタイプのサービスが提供されるいくつかのシナリオでは、CEデバイスがプロバイダー管理の中間デバイスに接続します。このプロバイダーが管理したデバイスは、複数の顧客のCESに接続する場合があります。同じ建物を占有する複数の顧客がいる場合、これは発生する可能性があります。このデバイスは本当にSPのネットワークの一部であり、そのためにPEデバイスと見なされる可能性があります。ただし、最も単純な場合、それは集約のみを実行し、VPLSに関連付けられた関数はありません。
Relative to the VPLS there are three different possibilities for allocate functions to a device in such a position in the provider network:
VPLと比較して、プロバイダーネットワークのこのような位置にあるデバイスに関数を割り当てるための3つの異なる可能性があります。
- it can perform aggregation and pure Layer2 service only, in which case it does not really play the role of a PE device in a VPLS service. In this case the intermediary system must connect to devices that perform VPLS PE functionality; the intermediary device itself is not part of the VPLS architecture and has hence not been named in this architecture.
- 集約と純粋なlayer2サービスのみを実行できます。その場合、VPLSサービスでPEデバイスの役割を実際には再生しません。この場合、中間システムはVPLS PE機能を実行するデバイスに接続する必要があります。仲介デバイス自体はVPLSアーキテクチャの一部ではないため、このアーキテクチャでは命名されていません。
- it can perform all the PE functions relevant for a VPLS. In such a case, the device is called VPLS-PE, see [RFC4026]. This type of device will be connected to the core (P) routers.
- VPLに関連するすべてのPE関数を実行できます。そのような場合、デバイスはVPLS-PEと呼ばれます。[RFC4026]を参照してください。このタイプのデバイスは、コア（P）ルーターに接続されます。
The PE functionality for a VPLS may be distributed between two devices, one "low-end" closer to the customer that performs, for example, the MAC-address learning and forwarding decisions, and one "high-end" that performs the control functions; e.g., establishing tunnels, PWs, and VCs. We call the low-end device the User-Facing PE (U-PE) and the high-end device the Network-Facing PE (N-PE).
VPLのPE機能は、2つのデバイス、たとえばMac-Addressの学習と転送の決定などを実行する顧客に近い2つのデバイス間で配布できます。;たとえば、トンネル、PWS、およびVCの確立。ローエンドデバイスをユーザー向けPE（U-PE）とハイエンドデバイスをネットワーク向けPE（N-PE）と呼びます。
It is conceivable that the U-PE may be placed very close to the customer; e.g., in a building with more than one customer. The N-PE will presumably be placed on the SP's premises.
U-PEが顧客に非常に近くに配置される可能性があると考えられます。たとえば、複数の顧客がいる建物で。N-PEは、おそらくSPの施設に配置されます。
The distributed case is potentially of interest for a number of possible reasons:
分散型ケースは、いくつかの可能な理由で潜在的に関心があります。
- The N-PE may be a device that cannot easily implement the VSI functionality described above. For example, perhaps the N-PE is a router that cannot perform the high speed MAC learning that is needed in order to implement a VSI forwarder. At the same time, the U-PE may need to be a low-cost device that also cannot implement the full set of VPLS functions.
- N-PEは、上記のVSI機能を簡単に実装できないデバイスである場合があります。たとえば、おそらくN-PEは、VSIフォワーダーを実装するために必要な高速MAC学習を実行できないルーターです。同時に、U-PEは、VPLS関数の完全なセットを実装できない低コストのデバイスである必要がある場合があります。
This leads one to investigate further if there are sensible ways to split the VPLS PE functionality between the U-PE and the N-PE.
これにより、U-PEとN-PEの間にVPLS PE機能を分割する賢明な方法がある場合、さらに調査することができます。
- Generally, in the L2VPN architecture, the PEs are expected to participate as peers in the backbone routing protocol. Since the number of U-PEs is potentially very large relative to the number of N-PEs, this may be undesirable as a matter of scaling the backbone routing protocol.
- 一般に、L2VPNアーキテクチャでは、PESはバックボーンルーティングプロトコルの仲間として参加することが期待されています。U-PEの数は潜在的にN-PEの数に比べて非常に大きいため、これはバックボーンルーティングプロトコルをスケーリングする問題として望ましくない場合があります。
- The U-PE may be a relatively inexpensive device that is unable to participate in the full range of signaling and/or auto-discovery procedures that are needed in order to provide the VPLS service.
- U-PEは、VPLSサービスを提供するために必要な全範囲のシグナリングおよび/または自動発見手順に参加できない比較的安価なデバイスである可能性があります。
The VPLS functionality can be distributed between U-PE and N-PE in a number of different ways, and a number of different proposals have been made. They all presume that the U-PE will maintain a VSI forwarder, connected by PWs to the remote VSIs; the N-PE thus does not need to perform the VSI forwarding function. The proposals tend to differ with respect to the following questions:
VPLS機能は、さまざまな方法でU-PEとN-PEの間に分散でき、さまざまな提案が行われています。彼らは皆、U-PEがPWSによってリモートVSIに接続されたVSIフォワーダーを維持すると推測しています。したがって、N-PEはVSI転送機能を実行する必要はありません。提案は、次の質問に関して異なる傾向があります。
- Should the U-PEs perform full PW signaling to set up the PWs to remote VSIs, or should the N-PEs do this signaling?
- U-PESは、PWSをリモートVSIにセットアップするために完全なPWシグナリングを実行する必要がありますか、それともN-PEはこのシグナリングを行う必要がありますか？
Since the U-PEs need to be able to send packets on PWs to remote VSIs and receive packets on PWs from remote VSIs, if the PW signaling is done by the N-PE, there would have to be some form of "lightweight" (presumably) signaling between N-PE and U-PE that allows the PWs to be extended from N-PE to U-PE.
U-PEはPWSのパケットをリモートVSIに送信し、リモートVSIからPWSのパケットを受信できる必要があるため、PWシグナリングがN-PEによって行われた場合、何らかの形の「軽量」が必要です（おそらく）N-PEとU-PEの間のシグナル伝達は、PWSをN-PEからU-PEに拡張できるようにします。
- Should the U-PEs do their own auto-discovery, or should this be done by the N-PEs?
- U-PEは独自の自動発見を行う必要がありますか、それともN-PESが行う必要がありますか？
In the latter case, the U-PEs may need to have some means of telling the N-PEs which VPLSes they are interested in, and the N-PEs must have some means of passing the results of the auto-discovery process to the U-PE.
後者の場合、U-PEは、関心のあるvplseがN-PEに何らかの手段を伝える必要がある場合があり、n-PEは自動ディスコービリプロセスの結果をuに合格する手段を持たなければなりません。-PE。
Whether it makes sense to split auto-discovery in this manner may depend on the particular auto-discovery protocol used. One would not expect the U-PEs to participate in, if for example, a BGP-based auto-discovery scheme, but perhaps they would be expected to participate in a RADIUS-based auto-discovery scheme.
この方法で自動発見を分割することが理にかなっているかどうかは、使用されている特定の自動ディスコーバリプロトコルに依存する可能性があります。たとえば、BGPベースの自動配置スキームにはU-PEが参加するとは思わないが、おそらく彼らはRADIUSベースの自動ディスコービリスキームに参加することが期待されるだろう。
- If a U-PE does not participate in routing but is redundantly connected to two different N-PEs, can the U-PE still make an intelligent choice of the best N-PE to use as the "next hop" for traffic destined to a particular remote VSI? If not, can this choice be made as the result of some other sort of interaction between N-PE and U-PE, or does this choice need to be established by provisioning?
- U-PEがルーティングに参加していないが、2つの異なるN-PEに冗長に接続されている場合、U-PEは引き続き最適なN-PEのインテリジェントな選択を行うことができます。特定のリモートVSI？そうでない場合、この選択は、N-PEとU-PEの間の他の種類の相互作用の結果として作成できますか、それともこの選択をプロビジョニングによって確立する必要がありますか？
- If a U-PE does not participate in routing but does participate in full PW signaling, and if MPLS is being used, how can an N-PE send a U-PE the labels that the U-PE needs in order to be able to send traffic to its signaling peers? (If the U-PE did participate in routing, this would happen automatically.)
- U-PEはルーティングに参加せず、完全なPWシグナル伝達に参加し、MPLSが使用されている場合、N-PEはU-PEにU-PEが必要とするラベルをどのように送信できますか信号のピアにトラフィックを送信しますか？（U-PEがルーティングに参加した場合、これは自動的に発生します。）
- When a frame must be multicast, should the replication be done by the N-PE or the U-PE?
- フレームがマルチキャストでなければならない場合、N-PEまたはU-PEによって複製を実行する必要がありますか？
These questions are not all independent; the way one answers some of them may influence the way one answers others.
これらの質問はすべて独立しているわけではありません。それらのいくつかに答える方法は、ある人が他の人に答える方法に影響を与える可能性があります。
In general, the PSN supports a VPLS solution with a tunnel from each VPLS-PE to every other VPLS-PE participating in the same VPLS instance. Strictly, VPLS-PEs with more than one VPLS instance in common only need one tunnel, but for resource allocation reasons it might be necessary to establish several tunnels. For each VPLS service on a given VPLS-PE, it needs to establish one pseudowire to every other VPLS-PE participating in that VPLS service. In total n*(n-1) pseudowires must be setup between the VPLS-PE routers. In large scale deployment this obviously creates scaling problems. One way to address the scaling problems is to use hierarchy.
一般に、PSNは、各VPLS-PEから同じVPLSインスタンスに参加する他のすべてのVPLS-PEへのトンネルを備えたVPLSソリューションをサポートします。厳密には、複数のVPLSインスタンスが共通しているVPLS-PEは、1つのトンネルのみを必要としますが、リソースの割り当ての理由から、いくつかのトンネルを確立する必要があるかもしれません。特定のVPLS-PEの各VPLSサービスについて、そのVPLSサービスに参加する他のすべてのVPLS-PEに1つの擬似ワイヤーを確立する必要があります。合計N*（n-1）擬似ワイヤは、VPLS-PEルーター間にセットアップする必要があります。大規模な展開では、これは明らかにスケーリングの問題を引き起こします。スケーリングの問題に対処する1つの方法は、階層を使用することです。
If, instead of providing a general VPLS service, one wishes to provide a VPLS that is used only to connect IP routers or hosts (i.e., the CE devices are all assumed to be IP routers or hosts), then it is possible to make certain simplifications.
一般的なVPLSサービスを提供する代わりに、IPルーターまたはホストを接続するためにのみ使用されるVPLS（つまり、CEデバイスはすべてIPルーターまたはホストであると想定されています）を提供したい場合、確認することができます。単純化。
In this environment, all Ethernet frames sent from a particular CE to a particular PE on a particular Attachment Circuit will have the same MAC Source Address. Thus, rather than use address learning in the data plane to learn the MAC addresses, the PE can use the control plane to learn the MAC address. This allows the PE to be implemented on devices that are not capable of doing MAC address learning in the data plane.
この環境では、特定のCEから特定のアタッチメント回路の特定のPEに送信されるすべてのイーサネットフレームには、同じMACソースアドレスがあります。したがって、データプレーンでアドレス学習を使用してMACアドレスを学習するのではなく、PEはコントロールプレーンを使用してMACアドレスを学習できます。これにより、PEは、データプレーンでMacアドレス学習を行うことができないデバイスに実装できます。
To eliminate the need for MAC address learning on the PWs as well as on the ACs, the pseudowire signaling protocol would have to carry the MAC address from one pseudowire endpoint to the other. In the case of IPv4, Each PE would perform proxy ARP to its directly attached CEs. In the case of IPv6, each PE would send proxy Neighbor and/or Router Advertisements.
PWSおよびACSでのMACアドレス学習の必要性を排除するには、擬似ワイヤーシグナル伝達プロトコルは、一方の擬似ワイヤーエンドポイントから他の擬似ワイヤーのエンドポイントにMACアドレスを運ぶ必要があります。IPv4の場合、各PEは直接接続されたCESに対してプロキシARPを実行します。IPv6の場合、各PEはプロキシネイバーおよび/またはルーターの広告を送信します。
Eliminating the need to do MAC address learning on the PWs eliminates the need for the PWs to be point-to-point. Multipoint-to-point PWs could be used instead.
PWSでMACアドレス学習を行う必要性を排除すると、PWSがポイントツーポイントになる必要性がなくなります。代わりに、マルチポイントからポイントへのPWを使用できます。
Unlike a VPLS, all the ACs in an IPLS would not necessarily have to carry Ethernet frames; only the IP packets would need to be passed across the network, not their Layer 2 wrappers. However, if there are protocols that are specific to the Layer 2, but that provide, for example, address resolution services for Layer 3, it may then be necessary to "translate" (or otherwise interwork) one of these Layer 2 protocols to the other. For example, if an IPLS instance has an ethernet AC and a Frame Relay AC, and IPv4 is running on both, interworking between ARP and Inverse ARP might be required.
VPLとは異なり、IPLSのすべてのACSは必ずしもイーサネットフレームを携帯する必要はありません。レイヤー2ラッパーではなく、ネットワーク全体に渡す必要があります。ただし、レイヤー2に固有のプロトコルがあるが、たとえばレイヤー3の解像度の解像度サービスを提供するプロトコルがある場合、これらのレイヤー2プロトコルのいずれかを「翻訳」（またはインターワーク）する必要がある場合があります。他の。たとえば、IPLSインスタンスにイーサネットACとフレームリレーACがあり、IPv4が両方で実行されている場合、ARPと逆ARPの間のインターワーキングが必要になる場合があります。
The set of routing protocols that could be carried across the IPLS might also be restricted.
IPLSを介して運ばれる可能性のあるルーティングプロトコルのセットも制限される可能性があります。
An IPLS instance must have a particular IPLS-wide MTU; if there are different kinds of AC in an IPLS instance, and those different kinds of AC support different MTUs, all ACS must enforce the IPLS-wide MTU; an AC that cannot do this must not be allowed to join the IPLS instance.
IPLSインスタンスには、特定のIPLS全体のMTUが必要です。IPLSインスタンスに異なる種類のACがあり、それらの異なる種類のACが異なるMTUをサポートする場合、すべてのACSがIPLS全体のMTUを実施する必要があります。これを行うことができないACは、IPLSインスタンスに参加することを許可してはなりません。
The security considerations section of the L2VPN requirements document [RFC4665] addresses a number of areas that are potentially insecure aspects of the L2VPN. These relate to both control plane and data plane security issues that may arise in the following areas:
L2VPN要件ドキュメント[RFC4665]のセキュリティ上の考慮事項セクションは、L2VPNの潜在的に不安定な側面である多くの領域を扱っています。これらは、次の領域で発生する可能性のある制御プレーンとデータプレーンのセキュリティの問題の両方に関連しています。
- issues fully contained in the provider network
- プロバイダーネットワークに完全に含まれる問題
- issues fully contained in the customer network
- 顧客ネットワークに完全に含まれる問題
- issues in the customer-provider interface network
- 顧客プロバイダーインターフェイスネットワークの問題
These three areas are addressed below.
これらの3つの領域を以下に説明します。
This section discusses security issues that only impact the SP's equipment.
このセクションでは、SPの機器のみに影響を与えるセキュリティの問題について説明します。
There are security issues having to do with the control connections that are used on a PE-PE basis for setting up and maintaining the pseudowires.
擬似動物のセットアップと維持のためにPE-PEベースで使用される制御接続に関係するセキュリティの問題があります。
A PE should not engage with another PE in a control connection unless it has some confidence that the peer is really a PE to which it should be setting up PWs. Otherwise, L2PVN traffic may go to the wrong place. If control packets are maliciously and undetectably altered while in flight, denial of service, or alteration of the expected quality of service, may result.
PEは、ピアが実際にPWSをセットアップする必要があるPEであるという自信がない限り、制御接続で別のPEと関与してはなりません。それ以外の場合、L2PVNトラフィックは間違った場所に移動する場合があります。フライト中、サービスの拒否、または予想されるサービス品質の変更中に、制御パケットが悪意を持って検出されない場合に変更された場合。
If peers discover each other dynamically (via some auto-discovery procedure), this presupposes that the auto-discovery procedures are themselves adequately trusted.
ピアが（いくつかの自動発見手順を介して）お互いを動的に発見した場合、これは自動発見手順自体が適切に信頼されていることを前提としています。
PEs should not accept control connections from arbitrary entities; a PE either should be configured with its peers or should learn them from a trusted auto-configuration procedure. If the peer is required to be within the same SP's network, then access control filters at the borders of that network can be used to prevent spoofing of the peer's source address. If the peer is from another SP's network, then setting up such filters may be difficult or even impossible, depending on the way in which the two SPs are connected. Even if the access filters can be set up, the level of assurance that they provide will be lower.
PESは、任意のエンティティからの制御接続を受け入れないでください。PEは、ピアで構成するか、信頼できる自動構成手順からそれらを学習する必要があります。ピアが同じSPのネットワーク内にある必要がある場合は、そのネットワークの境界にあるアクセス制御フィルターを使用して、ピアのソースアドレスのスプーフィングを防ぐことができます。ピアが別のSPのネットワークから来ている場合、2つのSPSが接続されている方法に応じて、そのようなフィルターのセットアップは困難または不可能でさえあります。アクセスフィルターをセットアップできる場合でも、提供する保証のレベルは低くなります。
Thus, for inter-SP control connections, it is advisable to use some sort of cryptographic authentication procedure. Control protocols which used TCP may use the TCP MD5 option to provide a measure of PE-PE authentication; this requires at least one shared secret between SPs. The use of IPsec between PEs is also possible and provides a greater degree of assurance, though at a greater cost.
したがって、SP間制御接続の場合、何らかの暗号化認証手順を使用することをお勧めします。TCPを使用した制御プロトコルは、TCP MD5オプションを使用してPE-PE認証の尺度を提供する場合があります。これには、SPS間に少なくとも1つの共有秘密が必要です。PES間のIPSECの使用も可能であり、より大きなコストではありますが、より大きな保証を提供します。
Any other security considerations that apply to the control protocol in general will also apply when the control protocol is used for setting up PWs. If the control protocol uses UDP messages, it may be advisable to have some protection against spoofed UDP messages that appear to be from a valid peer; this requires further study.
コントロールプロトコルに適用されるその他のセキュリティ上の考慮事項は、PWSのセットアップに制御プロトコルを使用する場合にも適用されます。コントロールプロトコルがUDPメッセージを使用する場合、有効なピアからのように見えるスプーフィングされたUDPメッセージに対してある程度保護することをお勧めします。これにはさらなる研究が必要です。
To limit the effect of Denial of Service attacks on a PE, some means of limiting the rate of processing of control plane traffic may be desirable.
PEに対するサービス拒否攻撃の影響を制限するには、制御プレーントラフィックの処理速度を制限する何らかの手段が望ましい場合があります。
Unlike authentication and integrity, privacy of the signaling messages is not usually considered very important. If it is needed, the signaling messages can be sent through an IPsec connection.
認証や整合性とは異なり、信号メッセージのプライバシーは通常、それほど重要ではありません。必要な場合は、信号メッセージをIPSEC接続を介して送信できます。
If the PE cannot efficiently handle high volumes of multicast traffic for sustained periods, then it may be possible to launch a denial of service attack on a VPLS service by sending a PE a large number of frames that have either a multicast address or an unknown MAC address in their MAC Destination Address fields. A similar denial of service attack can be mounted by sending a PE a large number of frames with bogus MAC Source Address fields. The bogus addresses can fill the MAC address tables in the PEs, with the result that frames destined to the real MAC addresses always get flooded (i.e., multicast). Note that this flooding can remove the (weak) confidentiality property of this or any other bridged network.
PEが持続期間の大量のマルチキャストトラフィックを効率的に処理できない場合、マルチキャストアドレスまたは不明なMacを持つ多数のフレームをPEに送信することにより、VPLSサービスに対するサービス拒否攻撃を開始することが可能かもしれませんMAC宛先アドレスフィールドのアドレス。同様のサービス攻撃を、PEにPEに多数のフレームを偽のMACソースアドレスフィールドに送信することで取り付けることができます。偽のアドレスは、PESのMACアドレステーブルを埋めることができ、その結果、実際のMACアドレスが常に浸水します（つまり、マルチキャスト）。この洪水は、このまたは他の橋渡しネットワークの（弱い）機密性の財産を削除できることに注意してください。
There are a number of security issues related to the access network between the provider and the customer. This is also traditionally a network that is hard to protect physically.
プロバイダーと顧客の間にアクセスネットワークに関連する多くのセキュリティ問題があります。これは、伝統的に物理的に保護するのが難しいネットワークでもあります。
Typical security issues on the provider-customer interface include the following:
プロバイダーカスタマーインターフェイスの典型的なセキュリティの問題には、以下が含まれます。
- Ensuring that the correct customer interface is configured
- 正しい顧客インターフェイスが構成されていることを確認します
- Preventing unauthorized access to the PE
- PEへの不正アクセスを防ぐ
- Preventing unauthorized access to a specific PE port
- 特定のPEポートへの不正アクセスを防ぐ
- Ensuring correct service delimiting fields (VLAN, DLCI, etc.)
- 正しいサービスを確実に削除するフィールド（VLAN、DLCIなど）
As the access network for an L2VPN service is necessarily a Layer 2 network, it is preferable to use authentication mechanisms that do not presuppose any IP capabilities on the CE device.
L2VPNサービスのアクセスネットワークは必然的にレイヤー2ネットワークであるため、CEデバイスのIP機能を前提としない認証メカニズムを使用することが望ましいです。
There are existing Layer 2 protocols and best current practices to guard against these security issues. For example, IEEE 802.1x defines authentication at the link level for access through an ethernet bridge; the Frame Relay Forum defines LMI extensions for authentication (FRF.17).
これらのセキュリティ問題を防ぐための既存のレイヤー2プロトコルと最良の現在のプラクティスがあります。たとえば、IEEE 802.1xは、イーサネットブリッジを介したアクセスのリンクレベルで認証を定義します。フレームリレーフォーラムは、認証用のLMI拡張機能を定義しています（FRF.17）。
Even if all CE devices are properly authorized to attach to their PE devices, misconfiguration of the PE may interconnect CEs that are not supposed to be in the same L2VPN.
すべてのCEデバイスがPEデバイスに接続することを適切に許可されている場合でも、PEの誤った構成は、同じL2VPNにないはずのCESを相互接続する場合があります。
In a VPWS, the CEs may run IPsec to authenticate each other. Other Layer 3 or Layer 4 protocols may have their own authentication methods.
VPWSでは、CESはIPSECを実行して互いに認証する場合があります。他のレイヤー3またはレイヤー4プロトコルには、独自の認証方法がある場合があります。
In a VPLS, CE-to-CE IPsec is even more problematic, as IPsec does not well support the multipoint configuration that is provided by the VPLS service.
VPLSでは、IPSECがVPLSサービスによって提供されるマルチポイント構成をあまりサポートしていないため、CE-to-CE-CEのIPSECはさらに問題があります。
There may be alternative methods for achieving a degree of CE-to-CE authentication, if the L2VPN signaling protocol can carry opaque objects between the CEs, either inband (over the L2VPN) or out-of-band, through the participation of the signaling protocol. This is for further study.
L2VPNシグナル伝達プロトコルがシグナリングの参加を通じてCES（L2VPN上）または帯域外のいずれかの間に不透明なオブジェクトを運ぶことができる場合、ある程度のCE-CE-CE-CE-CEから認証を達成するための代替方法があるかもしれません。プロトコル。これはさらなる研究のためです。
The L2VPN procedures do not provide authentication, integrity, or privacy for the customer's traffic; if this is needed, it becomes the responsibility of the customer. For customers who really need these features or who do not trust their service providers to provide the level of security that they need, the L2VPN framework discussed in this document may not be satisfactory. Such customers may consider alternative L2VPN schemes that are based not on an overlay of PWs, but on an overlay of IPsec tunnels whose endpoints are at the customer sites; however, such alternatives are not discussed in this document.
L2VPN手順は、顧客のトラフィックに認証、整合性、またはプライバシーを提供しません。これが必要な場合、それは顧客の責任になります。これらの機能を本当に必要としている顧客、またはサービスプロバイダーが必要なセキュリティのレベルを提供することを信頼していない顧客にとって、このドキュメントで説明したL2VPNフレームワークは満足のいくものではないかもしれません。このような顧客は、PWSのオーバーレイではなく、エンドポイントが顧客サイトにあるIPSECトンネルのオーバーレイに基づいた代替L2VPNスキームを検討する場合があります。ただし、このような代替案はこのドキュメントでは説明されていません。
If there is CE-to-CE control traffic (e.g., BPDUs) on whose integrity the customer's own Layer 2 network depends, it may be advisable to send the control traffic using some more secure mechanism than is used for the data traffic.
顧客自身のレイヤー2ネットワークが依存する整合性にCE-CE-CONTROLトラフィック（BPDUなど）がある場合、データトラフィックに使用されるよりも多くの安全なメカニズムを使用してコントロールトラフィックを送信することをお勧めします。
In general, any means of mounting a denial of service attack on bridged networks generally can also be used to mount a denial of service attack on the VPLS service for a particular customer. We have discussed here only those attacks that rely on features of the VPLS service that are not shared by bridged networks in general.
一般に、ブリッジ型ネットワークへのサービス拒否攻撃を取り付ける手段は、一般に、特定の顧客のVPLSサービスに対するサービス拒否攻撃を実施するためにも使用できます。ここでは、Bridged Networks全般によって共有されていないVPLSサービスの機能に依存する攻撃のみを議論しました。
This document is the outcome of discussions within a Layer 2 VPN design team, all of whose members could be considered co-authors. Specifically, the co-authors are Loa Andersson, Waldemar Augustyn, Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti Kompella, Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile Radoaca, Eric Rosen, and Tissa Senevirathne.
このドキュメントは、レイヤー2 VPN設計チーム内での議論の結果であり、そのメンバーはすべて共著者と見なすことができます。具体的には、共著者は、ロアアンダーソン、ウォルデマーオーガスティン、マーティボーデン、ハミド・ロールド・ブラヒム、ジュハ・ヘイナネン、キリエト・コンプラ、ヴァッハ・コンペラ、マーク・ラッセル、パスカル・メネーズ、ヴァシル・ラドーアカ、エリック・ローゼン、ティッサ・セネビルスネです。
The authors would like to thank Marco Carugi for cooperation in setting up context, working directions, and taking time for discussions in this space; Tove Madsen and Pekka Savola for valuable input and reviews; and Norm Finn, Matt Squires, and Ali Sajassi for valuable discussion of the VPLS issues.
著者は、コンテキストの設定、作業方向、この分野での議論のための時間をとる際の協力について、Marco Carugiに感謝したいと思います。Tove MadsenとPekka Savolaは、貴重な入力とレビューを求めています。Norm Finn、Matt Squires、およびAli Sajassiは、VPLSの問題について貴重な議論をしてくれました。
[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月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026] Andersson、L。およびT. Madsen、「プロバイダープロビジョニング仮想プライベートネットワーク（VPN）用語」、RFC 4026、2005年3月。
[RFC4665] Augustyn, W., Ed. and Y. Serbest, Ed., "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs)", RFC 4665, September 2006.
[RFC4665] Augustyn、W.、ed。and Y. Serbest ed。、「レイヤー2プロバイダーが提供する仮想プライベートネットワーク（L2VPNS）のサービス要件」、RFC 4665、2006年9月。
[IEEE8021D] IEEE 802.1D-2003, "IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges"
[IEEE8021D] IEEE 802.1D-2003、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：メディアアクセス制御（MAC）ブリッジ」
[IEEE8021Q] IEEE 802.1Q-1998, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks"
[IEEE8021Q] IEEE 802.1Q-1998、「ローカルおよび大都市圏ネットワークのIEEE標準：仮想ブリッジ型ローカルエリアネットワーク」
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "Layer Two Tunneling Protocol" L2TP ""、RFC 2661、1999年8月。
[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC2796] Bates、T.、Chandra、R。、およびE. Chen、「BGPルートリフレクション - フルメッシュIBGPの代替」、RFC 2796、2000年4月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「LDP仕様」、RFC 3036、2001年1月。
Authors' Addresses
著者のアドレス
Loa Andersson Acreo AB
Loa Andersson Acreo AB
EMail: loa@pi.se
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ、1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719
EMail: erosen@cisco.com
Waldemar Augustyn
Waldemar Augustyn
EMail: waldemar@wdmsys.com
Marty Borden
マーティ・ボーデン
EMail: mborden@acm.org
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland
Juha Heinanen Song Networks、Inc。Hallituskatu 16 33200タンペレ、フィンランド
EMail: jh@song.fi
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks、Inc。1194 N. Mathilda Ave Sunnyvale、CA 94089
EMail: kireeti@juniper.net
Vach Kompella TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043
Vach Kompella Timetra Networks 274 Ferguson Dr. Mountain View、CA 94043
EMail: vach.kompella@alcatel.com
Marc Lasserre
Riverstone Networks
5200 Great America Pkwy
Santa Clara, CA 95054
EMail: mlasserre@lucent.com
Pascal Menezies
パスカル・メネジー
EMail: pascalm1@yahoo.com
Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7, Canada
ハミド・オールド・ブラヒム・ノルテルネットワークP Oボックス3511ステーションCオタワ、カナダ、K1Y 4H7
EMail: hbrahim@nortelnetworks.com
Vasile Radoaca Nortel Networks 600 Technology Park Billerica, MA 01821
Vasile Radoaca Nortel Networks 600 Technology Park Billerica、MA 01821
EMail: radoaca@hotmail.com
Tissa Senevirathne 1567 Belleville Way Sunnyvale CA 94087
Tissa Senevirathne 1567 Belleville Way Sunnyvale CA 94087
EMail: tsenevir@hotmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。