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)
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).
著作権（C）インターネット協会（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個のプロバイダプロビジョニングされた仮想プライベートネットワーク（のL2VPN）のためのフレームワークを提供します。このフレームワークは、相互運用の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個のプロバイダプロビジョニングされた仮想プライベートネットワーク（のL2VPN）のためのフレームワークを提供します。このフレームワークは、相互運用の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.
用語「プロバイダーはVPNをプロビジョニングは、」サービスプロバイダ（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のための参照モデルを提供するとのL2VPNの機能コンポーネントを説明します。具体的には、インターワーキングおよびセキュリティのために必要なものを基準とメカニズムを含むの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).
仮想専用線サービス（VPWS）と仮想プライベートLANサービス（VPLS）：サービスプロバイダが顧客に提供することができ、レイヤ2 VPNサービスの根本的に異なる二つの種類があります。 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]で定義されています。接続回線と疑似回線は、PEがローカル情報に基づいて、PWと接続回線との間の単純なマッピングを行い、セクション3に記載されています。即ち、PWのデマルチプレクサと着信/発信論理/物理ポート。
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デバイスが特定のVPLSに属するCEデバイスは、単一のブリッジイーサネット上にあるように見えるように、論理的な相互接続を提供するVPLS参照モデルを示します。 VPLSは、単一の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インタフェース」を介して、付加します。各VPLSのために、エミュレートLANインスタンスが存在します。図3は、エミュレートされたLANの一部の内部構造を示す：それは疑似回線がルーティングバックボーン上PSNトンネルを通って移動することができる疑似回線によって接続された「VPLSフォワーダ」モジュールから構成されています。
A "VPLS instance" consists of a set of VPLS Forwarders (no more than one per PE) connected by pseudowires.
「VPLSインスタンスは、」疑似回線によって接続されたVPLSフォーワーダ（PE当たりないつ以上）のセットからなります。
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:
このようなフレームワークは、少なくとも次の三つのモデルと互換性があります。
- 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インスタンスをサポートします。各インスタンスは、VLAN（実際には、「エミュレートVLAN」）、およびVPLSインスタンスのセットが共通のLAN上のVLANのセットとして扱われるように考えられているVPLS。各VLANは別々のPWのセットを使用するので、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）であることです疑似回線（さらなる議論のために、第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.
このセクションでは、1つのその機能コンポーネントに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機器は、「仮想バックボーン」をもたらす一つ以上の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.
二つのCEは、同じ仮想バックボーンに接続されている場合、それらは同じVPLSインスタンス（すなわち、同じVPN）のメンバーである場合にのみ。場合CEは、フレーム、フレームを転送する方法を決定するために、それはMAC宛先アドレスフィールドを調べ受信PEを送信します。したがって、ブリッジとしてPE機能します。図3が示すようにPEのセットが共通のVPLSインスタンスをサポートしている場合、その後、へものPEブリッジが付着の各々（エミュレートされたインターフェースを介して）エミュレートLANは、それに対応するVPLSインスタンスがあります。 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.
それはインタフェースを有した他のLANと同じようにPEブリッジ機能は、エミュレート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ヘッダのいずれかを考慮せずに行われること転送にVPWSのようなものです。 VPLSは、その中でVPWSとは異なります。
- VPLS allows the PE to use addressing information in a frame's L2 header to determine how to forward the frame; and
- VPLS 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.
- VPLSは、複数のリモートCEにフレームを送信するために使用される単一のCE / PEの接続を可能にします。この特定の点で、VPLSは、L3VPN似VPWSより。
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）からフレームを受信し、次いでCE（CE2）にフレームを搬送するPE（PE2）にフレームを搬送します。このセクションでは、我々は、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であってもよいなど、CE機器であってもよいですルータ、スイッチ、ホスト、または単に顧客のニーズは、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」として、元ACにし、フレームの「出口AC」として後者のACを参照してください。 「進入AC」と「退出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].
「疑似」（PW）は、2つのPEデバイス間の関係です。 ACは、CEからPEへフレームを搬送するために使用される一方、PWは、二つの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).
セットアップおよびPWを維持することはPEの仕事です。特定のPWの状態情報はなく、他のPEではなく、バックボーンルータ（Pルータ）において、そのエンドポイント二つのPEに維持されます。
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は常に単方向とみなされます。マルチポイント・ツー・ポイントのPWは、フレームを受信した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.
もちろん、マルチキャストフレームで運ばれた情報は、複数のPWと複数の出口ACの上を走行することができるように、マルチキャストフレームは、PEによって複製されてもよいです。
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は、ACSの数を関連付けると言うことができます。これら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.
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. PEの一つは、インターワーキングを行うことができます。 CE1がATMを経由してPE1に接続するが、CE2は、フレームリレーを経由してPE2に接続する場合たとえば、PE1は、「ATM / FRサービスインターワーキング」の機能を提供することができます。これは、CEに透明になり、そして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データグラムであり、（セクション3.5を参照）は、2つのPEはIPによって使用される様々なL2固有の手順を偽装するために協力する必要があります。
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つのACSが同じMTUを持っていない場合は、以下の3つの手順のいずれかを行わなければなりません。
- 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.
- それは、リモートACのMTUと同じになるように、より大きなMTUとACのエンドポイントは、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上のフレームを受信し、別のPEにPW（たとえば、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.
PE1とPE2は同じデバイスである場合には、適切にL2VPNサービスを提供するために、正しく処理するための重要なケースです。ただし、この場合は、任意のプロトコルを必要としないよう、私たちは、この文書でさらにそれに対応していません。
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
- フレームのレイヤ2ヘッダの可能性内容物。そして
- 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
- フレームのレイヤ2ヘッダの可能性内容物。そして
- 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と考えることがあります。フォワーダは、順番にACSにPWを「結合します」。 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.
例えば、フォワーダは、すべてのフレームの内容を無視し、他の転送情報を用いない、単一のPWに単一のAC結合することができます。またはフォワーダは、転送データベース内の情報に、フレームのレイヤ2ヘッダからの情報を比較することによってPWに、PWからACまたはACからACへのACから個々のフレームを移動させる、のPWおよびACSの組に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.
私たちも、トンネル内のすべてのPWSはPE1で発信する必要はありません。トンネルはマルチポイントツーポイントトンネルであってもよいです。 NOR我々はPEの同じペア間のすべての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だけトンネルごとに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トンネルのために使用することができます。本当に必要とされるすべては、トンネリング技術が含まれているのPW適切な分離を可能にすることです。トンネルは、一般的にトンネリング技術は、デマルチプレクサフィールドは、特定のPWを識別するために使用されるデマルチプレクサフィールドが含まれているカプセル化の使用が必要になるなどのMPLS LSPを、L2TPトンネル、IPsecトンネル、MPLS-で-IPトンネル、あるかもしれません。トンネルを設定および維持するための手順は、この枠組みの範囲内ではありません。 （しかし、3.2.6項、「擬似回線シグナリング」を参照してください。）
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が異なるQoSを必要とします。トンネルへのPWを割り当てる方法を指定するための手順は、現在の枠組みの範囲外です。
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.
ポイント・ツー・ポイントPWSは双方向であるけれども、彼らが移動したトンネルは双方向またはポイント・ツー・ポイントのいずれかである必要はありません。例えば、ポイントツーポイント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.
PWの自分自身を設定し、維持するための手順は、この枠組みの範囲内です。これは、デマルチプレクサフィールドは、厳密に言えば、PWにトンネリングプロトコルに属していないにも関わらず、デマルチプレクサフィールド値を分配するための手順が含まれています。
The signaling for a point-to-point pseudowire must perform the following functions:
ポイント・ツー・ポイントの疑似回線のためのシグナリングは、次の機能を実行する必要があります。
- Distribution of the 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にデマルチプレクサ値を割り当てる必要があります。これらのデマルチプレクサは、与えられたトンネルに対して一意（または、いくつかのトンネリング技術を用いて、出口PEで一意）でなければなりません。一般に、トンネルの出口であるPEは、デマルチプレクサ値を選択し、トンネルの（ある）入口（ES）であるPE（複数可）に配布されます。これは、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.
通常トンネリングアーキテクチャの場合のように、デマルチプレクサフィールドはトンネリングプロトコルではなく、トンネリングされたプロトコルに属することに留意されたいです。このため、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
シグナリングプロトコルは、PWが結合されるべき適切なフォワーダを選択するために、リモートPEを可能にするために十分な情報を含んでいなければなりません。私たちは、「リモートフォワーダこの情報を呼び出すことができます
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.
セレクタ」。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は、特定のレイヤ2テクノロジーのシグナリングをエミュレートしなければならない程度に、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の状態の変化は、PWの状態に変更ACが結合した、およびその逆に反映する必要があるかもしれません。一般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を結合させるのに十分な情報を渡す必要があり、そのPWと特定のデマルチプレクサ値を関連付けます。 2個のPEが適切なPW /フォワーダバインディングを行っている、とデマルチプレクサ値に同意すると、PWを設定すると考えることができます。それは特定のPWのさらなる特性またはパラメータを交渉するために、または特定のPWのステータス情報を渡す必要がある場合、PWは、デマルチプレクサ値によって識別することができます。
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エンドポイントによって実行されるポイント・ツー・ポイントの手順です。そこのポイントツーポイント疑似回線を設定するためのポイント・ツー・マルチポイントシグナリングを使用するための提案は、しかし、であるため、これは、フレームワークに含まれています。 PWSは自身がポイント・ツー・マルチポイントであれば、それらを設定するには、ポイントツーポイントシグナリングまたはポイントツーマルチポイントシグナリングのいずれかを使用することも可能です。これは、このセクションの残りの部分で説明されています。
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「トンネル」で実施される疑似回線のために使用することができます。
- 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.
多くのPWを制御するために使用されるのPEの対の間に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.
ポイント・ツー・ポイントのPWを設定するためのポイント・ツー・ポイントのシグナリングを使用することは簡単です。リモートPEは必ずしもPWSはマルチポイントツーポイントまたはポイント・ツー・ポイントであるかどうかを知る必要はないとして、マルチポイント・ツー・ポイントPWSがまた、ポイント・ツー・ポイントのシグナリングによって設定することができます。いくつかのシグナリング手順では、同じデマルチプレクサの値がすべてのリモートPEに割り当てられてもよいです。
Consider the following conditions:
以下の条件を考慮してください。
- It is necessary to set up a set of PWs, all of which have the same characteristics.
- 同じ特性を持っているすべてがのPWセットを設定する必要があります。
- 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".
デマルチプレクサ値の範囲が与えられると、PEの組のそれぞれは、その範囲内の単一の値のユニークで決定的選択を行うことができる、ことにより、いくつかのメカニズムがあることも仮定する。この「デマルチプレクサ条件」を呼び出します。また、1はマルチポイントツーポイントPWを設定するのではなく、ポイントツーポイントPWを設定しようとしていることとします。この「マルチポイント条件」を呼び出します。
If:
もし：
- The Environmental Conditions hold; and
- 環境条件が成り立ちます。そして
- Either
- どちらか
* the Demultiplexor Condition holds, or
*デマルチプレクサの条件が成立する、または
* 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.
その後、出口PE1で終了のPWの所与のセットに対して、PE1は、セット内の各スードワイヤの入口PE（複数可）に送信するために必要な情報は全く同じです。すべての入力PE（単数または複数）は、同じフォワーダセレクタ値を受け取ります。彼らはすべてのPWパラメータ（もしあれば）の同じセットを受け取ります。いずれか（PWは、マルチポイントツーポイントである場合）、それらはすべて同じデマルチプレクサ値を受け取るか、または全ては、それぞれがそれ自体の一意のデマルチプレクサ値を選択することができ、そこからデマルチプレクサの値の範囲を受け取ります。
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に接続して、同じ情報を複製するのではなく、それはどちらかの情報をマルチキャストしても意味があり、あるいは、他の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].
私たちは、「ポイント・ツー・マルチポイント」シグナリングのような技術のこの種を参照してください。例えば、互いの、1つのまたはそれ以上のBGPルートリフレクタ[RFC2796]のBGPピアではないのPEと、シグナリングを行うためにBGP [RFC1771]を使用することも可能です。
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:
疑似回線は、別のサービスプロバイダーのネットワークでPEに1つのサービスプロバイダーのネットワーク内の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.
- のPWを設定するシグナリングプロトコルは、ネットワーク境界を横断することができなければなりません。もちろん、すべての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.
サービス品質は、このような保護、セキュリティ、サービス品質（QoS）のようなサービス属性のサービスレベル仕様（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.
必要なサービス品質がPWの上だけでなく、ACS上で提供されなければなりません。 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人の顧客からのトラフィックは、同じネットワークリソースを共有する場合、他よりも優先する必要があるかもしれません。これは、顧客のトラフィックのQoS保証に優先順位を分類し、マークするL2VPNソリューション内の機能が必要です。
- 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.
- 適切なキューイング動作は、同様に出力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.
- ポリシングは、一般的に、入口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.
- シェーピングは、一般的に、入口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.
復元力は、ネットワーク障害からの流れを保護するために、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サービスは、ほぼ透明にすることができていることが望ましいです。 CEが失敗に反応することができます前に、復元が行われるべきです。弾力性を提供する重要な側面は、以下のとおりです。
- 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はアクティブに維持することができ、他方はバックアップとしてマークすることができます。主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.
大幅に、弾力性は「普通の」適応ルーティングだけでなく、「高速リルート」機能など、ネットワークのコア内の適切な障害と回復のメカニズムを、持っていることの問題です。 CEとPE間に冗長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コンポーネントを管理および監視するためのメカニズムを提供することができます。サービスレベル契約（SLA）の観点から、L2VPNソリューションは、監視対象の統計データを報告するためにサービスプロバイダによって使用される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は、各フォワーダは、ちょうど1つのPWに正確に1つのACに結合するL2VPNサービスです。 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>の特定の組み合わせは、二つの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上のPWの「オーバーレイ」またはIPバックボーンと考えることができます。これは実際には特定の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に属していると言われているかどうかは、SPのと顧客の間の合意に基づき、行政の問題です。これは、プロビジョニング・モデル（後述）に影響を与えることができます。また、トンネルに割り当てられているか、特定のPWのQoSは、特定のACおよびPWなどに割り当てられている方法に影響を与える可能性があります
Note that VPWS makes use of point-to-point PWs exclusively.
VPWSが排他的にポイントツーポイントのPWを使用することに注意してください。
Provisioning a VPWS is a matter of:
VPWSをプロビジョニングすることの問題です。
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.所望のオーバレイ・トポロジーをもたらすようにACSとの間のPWを設定することを可能にするために必要な情報とのPEを提供するステップとそして
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として交換網であり、そしてVCがPVCでなく、SVCの場合、これは確か場合であろう。これは、個々の接続回線が特定のパラメータを与えられる必要があるときも同様である（例えば、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
ローカルACの*識別子PWをバインドするに
* 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（PWのリモートエンドにあるように、すなわち、PE）の* IPアドレス
* 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に意味があり、それが適切なACにPWに結合するリモートPEを可能にするために、PWシグナリングプロトコルに渡すことができる識別子。これは、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
ローカルACの*識別子PWをバインドするに
* 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におけるACの識別子（後者のみPEで恐らく一意）と共に、リモートPEのIPアドレスにグローバル一意識別子をマッピングするために使用されることです。リモートPEが適切なACにPWに結合するようにPWシグナリングプロトコルは、次に、AC識別子を渡し、リモートPEへの接続を行うことができます。
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.
この方式は、1つのPEにPWのプロビジョニングを必要とするが、それは、両方のPEでのAC提供に（必要がある場合）の必要性を排除しません。
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へのすべての唯一のACが含まれる可能性があります。）今、私たちは次のルールを課すこととしますPE1とPE2は、同じ色のプールを持っている時はいつでも、PE1間のPWがあるだろうそのプールから任意に選択されたACにそのプールから任意に選択されたACにPE1に結合し、及びPE2にあるPE2。 （我々は、単一の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内の各プールは、プール内のACSがそのPEへのCEを接続ACSがあるれる特定のCE装置を表すかもしれません。色は、VPN-IDであるかもしれません。このプロビジョニングモデルのアプリケーションは、VPN内のすべてのCEは、VPN内の他のすべてのCEへの仮想回路を有しているVPN内のフルCE-に-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)
- （複数のプールに所属なしAC付き）プールに属しているの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のIPアドレス、プール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:
この情報は、いくつかの異なるシグナリング技術をサポートするために使用することができます。次のように一つの可能な技術が進んで：
- 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 ACS、色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.)
- それはPWの各ACは、PWのセットを作成し、バインドします。 PWのこのセットは、シーケンスに編成されます。 （例えば、各PWは、デマルチプレクサフィールド値に関連付けられてもよい、およびPWは、その後、それぞれのデマルチプレクサの数値に応じて配列決定することができます。）
- Using auto-discovery, it obtains the list of PE routers that have one or more pools of color C.
- 自動検出を使用して、色Cの一つ以上のプールを持っているPEルータのリストを取得します
- It signals each such PE router, specifying the sequence Q of PWs.
- それは、のPWのシーケンス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が、指定された色のプールYを有する場合：
* removes an AC from the pool; and
*プールからACを削除します。そして
* binds the AC to the PW that is the "Yth" PW in the sequence Q.
*シーケンスQ.で「Y番目」PWであるPWにACをバインド
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;
- 異なるPWを引当異なる特性を必要はありません。
- 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
- それは、ACSの対があれば、ペアの両方のACSのような色のプールから来るように、のPWによって一緒に結合されている違いはありません。そして
- 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.
片面プロビジョニングモデルをサポートするために、自動検出は、PEのIPアドレスに（PWまたは接続回線のの）グローバル一意識別子をマッピングすることができなければなりません。
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.
モデルのプロビジョニング着色プールをサポートするために、自動検出は、同じ色のプールを含む他のPEのセットを決定するためにPEを有効にする必要があります。
These requirements enable the auto-discovery scheme to provide the information, which the PEs need to set up the PWs.
これらの要件は、PEがPWのを設定するために必要な情報を、提供するために、自動検出スキームを有効にします。
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.
- 指定したサービスプロバイダーは、シグナリング手順のいくつかの異なるタイプをサポートすることができ、したがって、PEは、使用するシグナリング手順を自動検出、を経由して、学習する必要があるかもしれません。
- 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を有することが望ましい場合がある（例えば、一方がATMであり、一方がイーサネットです）。異なるいくつかの方法がこれを行うことが可能な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、「イーサネットFRオーバー」カプセル化後者で使用することができている場合、共通のカプセル化は、両方のACS上で使用することができます。この場合、PWは、FR ACとPEにローカルFRカプセル化オーバーイーサネット（登録商標）の処理と、イーサネット（登録商標）の合図することができます。
- 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トラフィックだけを運ぶことが知られている場合、その一つは、IPパケットを搬送し、それぞれのレイヤ2カプセル化は、2個のPEのローカル事項だろうPWを使用することができます。 ACの一方はLANであり、1つはポイントツーポイントリンクである場合は、注意は、ARPと逆ARPなどの手順が正しく処理されるように注意しなければなりません。これは、いくつかのシグナリング、およびいくつかのプロキシ機能が必要な場合があります。 CEは、ポイントツーポイントインターフェイスのものよりLANインターフェイスの異なる手順を有するルーティング・アルゴリズムを使用する場合、さらに、追加のメカニズムが適切なインターワーキングを確保するために必要とされ得ます。
A VPLS is an L2VPN service in which:
VPLSは、中L2VPNサービスです。
- the ACs attach CE devices to PE bridge modules; and
- ACSは、PEブリッジモジュールにCE機器を取り付けます。そして
- 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フォワーダ」モジュール（図3参照）にPEブリッジモジュールを取り付ける「LANインターフェイスをエミュレート」です。 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フォワーダのセットは、のPWを介して接続されています。二つのVPLSフォワーダは、これら二つのフォワーダが同じVPLSの一部である場合にのみ、それらの間のPWを持つことになります。 （二VPLSのフォワーダは、これら二つのフォワーダは、同じ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上で、一方のエンティティによって送信されたフレームは、他のすべてで受信されます。 VPLSエミュレートLANは、しかし、やや動作が異なります。 VPLSフォワーダは、そのエミュレートされたLANインタフェースの1つの上にユニキャストフレームを受信した場合、フォワーダは、必ずしもそのエミュレートされたLAN上の他のすべてのフォワーダにフレームを送信しません。ユニキャストフレームが正しく送信先MACアドレスに配信するために、唯一つの他のフォワーダに送信する必要があります。送信フォワーダは、他のフォワーダは、特定のユニキャストフレームを受信する必要があるかを知っているならば、それはちょうどその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:
実際には、その後、各フォワーダーは、PWのにMACアドレスをマップする転送テーブルを維持し、「仮想スイッチインスタンス」（VSI）として動作します。 VSIは、標準的なブリッジは、その転送テーブルを移入することをほぼ同じ方法で移入されます。フレーム上のVPLSフォワーダは、MAC送信元アドレスを行う（SA）学習は、他のフォワーダからのPW上で受信し、また、そのようなアドレスエントリを老化などの手順、関連する一連の操作を行う必要があります。未知の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 SAが学習したことがありません。それだけで、他のVPLSフォワーダからのPW上で受信されたフレームのMAC SAを学習します。そして
- 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アドレス学習を行います。 PWSはエミュレートLANインタフェースの背後にある「隠された」あるとしてPEブリッジモジュールはまた、エミュレートLANインターフェイスのMACアドレス学習を行うが、PWの上で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のVSIの期限切れになるまで、それらのMACアドレスが到達不能になる可能性があることを意味し、VPLSフォワーダーには見えないかもしれません。これが許容できない場合、VPLSフォワーダへのそのような変更を通信するためのいくつかのメカニズムが提供されなければなりません。
Within a single VPLS, the VPLS Forwarders are interconnected by PWs. The set of PWs thus forms an "overlay topology".
単一VPLS内では、VPLSフォワーダーはPWをによって相互接続されています。 PWのセットは、このように「オーバーレイトポロジ」を形成します。
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は、MAC SAがどのPWを介して受信されているかを追跡する、です。推定は、当然のことながら、DAフィールドにMACアドレスがの遠隔端にあるVSIに送信されるべきであることを運ぶフレーム次いで、フレームのSAは、特定のPWを介して受信されるよう、特定のMACアドレスが表示された場合ということですPW。この仮定が真であるためには、VSIには、マルチポイント・ツー・ポイントのPWによって相互接続することができないことを意味PWのリモートエンドで一意VSIが存在しなければなりません。 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は、「ブリッジ・ポート」としてVPLSフォワーダによって処理されるIEEE、によって指定されるように、ポイントツーポイントPWは、標準的な技術を介して行われる上MAC学習します。 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は、同じVPLSに他のすべてのVSIに正確に一つのポイントツーポイントPWを持っています。
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に他のPWの上にそのフレームを転送してはなりません。これは、フレームがエミュレート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インターフェースのいずれかを、受信した場合、既知のDAとのユニキャストフレームは、フレームが正確に一つのポイントツーポイント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インターフェースのいずれかを、マルチキャストフレームまたは未知のDAとユニキャストフレームは、同じエミュレートLANに互いにVSIにフレームのコピーを送信します。これは、フレームを複製し、各ポイントツーポイントPWの上にコピーを送信することにより行うことができます。あるいは、ポイント・ツー・ポイントのPWのフルメッシュは、VPLS内の各VSIは、単一ポイント・ツー・マルチポイントPW上の送信機であるポイントツーマルチポイントのPWを用いて増強することができ、そのPW上のレシーバはすべてでありますそのVPLS内の他の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.
ツリー構造のトポロジーでは、特定のVPLS内のすべての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のセットが完全に噛合しなければなりません。ループの無料転送を確保するために、我々は、フレームは、それが低いレベルから、疑似回線を介して到着した場合にのみ、と同じレベルからPWをかけて到着したフレームができないのと同じまたはより高いレベルに、疑似回線上で送ることができるというルールを課す必要があります同じレベルにPWの上で送られます。
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のPWの任意の部分的なメッシュ。ループの自由は、オーバーレイ上でスパニングツリーを実行している、例えば、によって保証することができます。これらのトポロジは、さらに、このフレームワークでは考慮されません。
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.
各VPLSは、グローバル一意識別子を割り当てる必要があります。これは、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.
PEへのCEを取り付けるACSは、PEとCEの両方にプロビジョニングする必要があります。それはVPLSのためのVSIはPEにプロビジョニングされなければならず、そのローカルACSは、そのVSIに関連付けられている必要がありVPLS。 VSIは、それが属するVPLSの識別子をプロビジョニングする必要があります。
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.
自動検出方式は、VPLS内のVSIを有するリモートPEのセットにVPLS識別子をマッピングするPEによって使用されてもよいです。このセットが決定されると、PEは、それらのVSIのそれぞれにPWをセットアップするためにシグナリング疑似回線を使用することができます。 VPLS識別子は、シグナリングプロトコルのフォワーダーセレクタとして役立つであろう。これは、特定のVPLS内のVSI間のPWフルメッシュにつながります。
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.
単一VPLSは、複数のVLANが含まれている場合、彼らが共通してVLANを持っている場合にのみ、2つのVSIが接続されるように接続を制限することが望ましいことがあります。
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は、一つ以上のVLAN IDでプロビジョニングする必要があり、自動検出方式は<PEは、VLAN ID>の対にVPLS識別子をマッピングする必要があります。
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で論じ片面プロビジョニング方法を使用することができます。これはより複雑であるため、それは、個々の特性を持つ個々のPWを関連付けることが必要であったならば、それだけで使用されるでしょう。別の保証帯域が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デバイスは、例えば、同じ建物を占有している複数の顧客がある場合は特に、複数の顧客のCEに添付することがあります。しかしながら、この装置は本当に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デバイスは、プロバイダーが管理する中間デバイスに接続します。このプロバイダーが管理するデバイスは、複数の顧客のCEに添付することがあります。同じ建物を占有している複数の顧客がある場合、これが発生する可能性があります。このデバイスは、本当に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:
VPLSに対してプロバイダーネットワークのような位置にデバイスに機能を割り当てるための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.
- それは本当にVPLSサービスにおけるPEデバイスの役割を果たしていない、その場合には、唯一の集約と、純粋なレイヤ2サービスを実行することができます。この場合、仲介システムは、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.
- それは、VPLSに関連するすべてのPE機能を実行することができます。このような場合、デバイスは、[RFC4026]を参照VPLS-PEと呼ばれます。このタイプの装置は、コア（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).
VPLSのためのPEの機能は、例えば、実行する顧客に一つの「ローエンド」により近い、2つのデバイス間の制御機能を実行するMACアドレス学習および転送決定、および一つの「ハイエンド」を配布することができます;例えば、トンネル、のPW、および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機能を分割するための賢明な方法がある場合はさらに調査するために、1つをもたらします。
- 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アーキテクチャでは、PEがバックボーンルーティングプロトコルにおけるピアとして参加することが期待されます。 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は、リモートのVSIへのPWで接続された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-PEは、リモートのVSIへのPWを設定するには、フル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がリモートのVSIからのPWでパケットを遠隔のVSIへのPWでパケットを送受信できるようにする必要があるので、PWシグナリングがN-PEによって行われる場合、（「軽量」のいくつかの形態であることが持っているであろうおそらく）PWSはU-PEへのN-PEから延長されることを可能にする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は、彼らが興味のあるVPLSes N-PESを伝えるいくつかの手段を有する必要があり、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ベースの自動検出スキームは、おそらく彼らはRADIUSベースの自動検出スキームに参加することが予想される場合にはU-PEが、参加して期待していません。
- 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は、ルーティングに参加しませんが、冗長に二つの異なる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は、U-PEができるようにするために必要なラベルをルーティングに関与しないが、完全なPWシグナリングに関与しない、とMPLSが使用されている場合、どのようにN-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.
これらの質問はすべて独立していません。方法1は、それらのいくつかは1が他の人に答える方法に影響を与える可能性が答えます。
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溶液がVPLS-PEを他のすべてのVPLS-PEに同一のVPLSインスタンスに参加して支持しています。厳密には、VPLS-PEは共通に複数のVPLSインスタンスにのみ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サービスを提供する、一つだけ（すなわち、CEデバイスは、すべてのIPルータ、またはホストであると仮定される）IPルータまたはホストを接続するために使用されるVPLSを提供することを望む場合、特定することが可能です単純化。
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.
この環境では、特定の接続回線上の特定のPEに特定のCEから送信されたすべてのイーサネットフレームが同じ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.
PWの上だけでなく、ACSでのMACアドレス学習の必要性を排除するために、スードワイヤシグナリングプロトコルは、他の1つの疑似回線のエンドポイントからMACアドレスを携帯しなければなりません。 IPv4の場合、各PEは、直接結合CEにプロキシ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.
PWの上でMACアドレス学習を行う必要性を排除すると、PWSは、ポイントツーポイントであることをする必要がなくなります。マルチポイント・ツー・ポイントPWSが代わりに使用することができます。
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.
VPLSとは異なり、IPLSのすべてのACSは、必ずしもイーサネットフレームを運ぶために持っていません。 IPパケットだけでは、ネットワーク経由で渡されていない彼らのレイヤ2のラッパーする必要があろう。これらのレイヤ2つのプロトコルのいずれかが、レイヤ2に固有のプロトコルがあるが、しかし、それは、例えば、レイヤ3のアドレス解決サービスは、次いで「翻訳」する必要があるかもしれない、提供（または連動します）その他。 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]のSecurity Considerations部は、潜在的に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.
これらの三つの領域は、以下のアドレス指定されます。
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.
それは相手が本当にそれはPWのを設定しなければならないためのPEであることを、いくつかの自信を持っていない限り、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.
PEは、任意のエンティティからの制御接続を受け入れるべきではありません。 PEは、どちらかのピアで設定する必要があるか、信頼できる自動設定の手順からそれらを学ぶべきです。ピアが同じSPのネットワーク内にあることが必要とされている場合は、そのネットワークの境界で制御フィルタにアクセスするピアの送信元アドレスのスプーフィングを防止するために用いることができます。ピアが別のSPのネットワークからのものである場合、そのようなフィルタを設定すると、2つのSPが接続される方法に依存して、困難または不可能でさえあってもよいです。アクセスフィルタを設定することができたとしても、それらが提供する保証のレベルが低くなります。
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コントロール接続のために、暗号認証手続きのいくつかの並べ替えを使用することをお勧めします。 PE-PE認証の尺度を提供するためにTCP MD5オプションを使用することができるTCPを使用する制御プロトコル。これはSPの間に少なくとも1つの共有秘密を必要とします。 PE間の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.
制御プロトコルは、PWのを設定するために使用されている場合、一般的に制御プロトコルに適用されるその他のセキュリティに関する考慮事項も適用されます。制御プロトコルは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が効率的に持続期間のためのマルチキャストトラフィックの高いボリュームを処理できない場合、PEマルチキャストアドレスまたは未知のMACのいずれかを持っている多数のフレームを送信することにより、VPLSサービスにサービス拒否攻撃を起動することも可能です自分のMAC宛先アドレスフィールド内のアドレス。サービス攻撃の同様の拒否は、PEに偽のMACソースアドレスフィールドを持つ多数のフレームを送信することによって実装することができます。偽のアドレスは、実際のMAC宛てのフレームは常に（すなわち、マルチキャスト）を浸水取得アドレス、その結果、PEの中に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にあると想定されていないのCEを相互接続することができます。
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では、CEはお互いを認証するために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.
IPsecはよくVPLSサービスによって提供されるマルチポイント構成をサポートしていないようにVPLSにおいて、CE-TO-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シグナリングプロトコルはCEの間に不透明なオブジェクトを運ぶことができる場合（L2VPN以上）インバンドまたはアウトオブバンドシグナリングの関与を介してのいずれかで、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フレームワークは、満足できない場合があります。このような顧客は、PWののオーバーレイにない基づいていますが、エンドポイントの顧客サイトにある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.
CE-に-CE制御トラフィック（例えば、BPDUが）その完全性、顧客自身のレイヤ2ネットワークが依存であった場合、データトラフィックのために使用されているよりも、いくつかのより安全なメカニズムを使用して制御トラフィックを送信することが推奨されます。
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サービスにおけるサービス拒否攻撃を実装するために使用することができます。ここでは、一般的にブリッジネットワークで共有されていない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の設計チーム内での議論の結果です。具体的には、共著者はロア・アンダーソン、ヴァルデマーアウグスティン、マーティ・ボーデン、ハミドウルド - Brahimの、ユハHeinanen、Kireeti Kompella、VACH Kompella、マルク・Lasserre、パスカル・メネゼス、バシレRadoaca、エリック・ローゼン、そしてティッサSenevirathneです。
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.
著者は、コンテキストを設定する方向で作業し、この空間での議論のために時間を割いに協力マルコCarugiに感謝したいと思います。貴重な入力とレビューのためのトーベ・マドセンとペッカSavola。そしてノームフィン、マット・スクワイアーズ、およびVPLSの問題の貴重な議論のためのアリSajassi。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、RFC 3985、2005年3月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]アンデションとL.とT.マドセン、 "プロバイダーのプロビジョニングされた仮想プライベートネットワーク（VPN）用語"、RFC 4026、2005月。
[RFC4665] Augustyn, W., Ed. and Y. Serbest, Ed., "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs)", RFC 4665, September 2006.
[RFC4665]アウグスティン、W.、エド。そして、Y. Serbest、エド。、「レイヤ2プロバイダ・プロビジョニングされた仮想プライベートネットワーク（のL2VPN）のためのサービスの要件」、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.李、 "ボーダーゲートウェイプロトコル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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "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]ベイツ、T.、チャンドラ、R.、およびE.チェン、 "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]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
Authors' Addresses
著者のアドレス
Loa Andersson Acreo AB
ロア・アンダーソンAcreo AB
EMail: loa@pi.se
メールアドレス：loa@pi.se
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Waldemar Augustyn
ヴァルデマーオーガスティン
EMail: waldemar@wdmsys.com
メールアドレス：waldemar@wdmsys.com
Marty Borden
マーティボーデン
EMail: mborden@acm.org
メールアドレス：mborden@acm.org
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland
ユハわらソングネットワークス株式会社Hallituskatu 16 33200タンペレ、フィンランド
EMail: jh@song.fi
メールアドレス：jh@song.fi
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompellaジュニパーネットワークス株式会社1194 N.マチルダアベニューサニーベール、CA 94089
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Vach Kompella TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043
VACH Kompella TiMetraネットワーク274ファーガソン博士はマウンテンビュー、CA 94043
EMail: vach.kompella@alcatel.com
メールアドレス：vach.kompella@alcatel.com
Marc Lasserre Riverstone Networks 5200 Great America Pkwy Santa Clara, CA 95054
マルク・Lasserreリバーストーン・ネットワーク5200グレートアメリカパークウェイサンタクララ、CA 95054
EMail: mlasserre@lucent.com
メールアドレス：mlasserre@lucent.com
Pascal Menezies
パスカルMenezies
EMail: pascalm1@yahoo.com
メールアドレス：pascalm1@yahoo.com
Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7, Canada
K1Y 4H7、カナダONハミドウルド-BrahimのNortel NetworksのP Oボックス3511駅のCオタワ、
EMail: hbrahim@nortelnetworks.com
メールアドレス：hbrahim@nortelnetworks.com
Vasile Radoaca Nortel Networks 600 Technology Park Billerica, MA 01821
バシレRadoaca Nortel Networksの600テクノロジーパークビレリカ、MA 01821
EMail: radoaca@hotmail.com
メールアドレス：radoaca@hotmail.com
Tissa Senevirathne 1567 Belleville Way Sunnyvale CA 94087
ティッサSenevirathne 1567ベルヴィル・ウェイサニーベール、CA 94087
EMail: tsenevir@hotmail.com
メールアドレス：tsenevir@hotmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。