Internet Engineering Task Force (IETF) E. Rosen
Request for Comments: 6074 B. Davie
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 V. Radoaca
Alcatel-Lucent
W. Luo
January 2011
Provisioning, Auto-Discovery, and Signaling
in Layer 2 Virtual Private Networks (L2VPNs)
Abstract
抽象
Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3).
プロバイダによるレイヤ2個の仮想プライベートネットワーク（のL2VPN）が異なる「プロビジョニングモデル」、すなわち、どのようなエンティティで設定する必要があるものについては、モデルを有することができます。構成後、プロビジョニング情報は、「ディスカバリプロセス」によって分配されます。検出プロセスが完了すると、シグナリングプロトコルを自動的にL2VPNの（仮想）バックボーンを形成する疑似回線（PWの）のメッシュを設定するために呼び出されます。この文書では、L2VPNプロビジョニングモデルの数を指定し、さらに各モデルで必要とされるエンドポイント識別子の意味構造を指定します。それは発見がボーダーゲートウェイプロトコル（BGP）に基づいている場合は特に、検出プロセスによって、これらの識別子の分布を説明します。これは、エンドポイント識別子がPWを、ラベル配布プロトコル（LDP）を設定するために使用される2つのシグナリングプロトコルで運ばれる方法を指定すると、レイヤ2トンネリングプロトコルバージョン3（L2TPv3の）。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6074.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6074で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Signaling Protocol Framework . . . . . . . . . . . . . . . . . 5
2.1. Endpoint Identification . . . . . . . . . . . . . . . . . 5
2.2. Creating a Single Bidirectional Pseudowire . . . . . . . . 7
2.3. Attachment Identifiers and Forwarders . . . . . . . . . . 7
3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Individual Point-to-Point Pseudowires . . . . . . . . . . 9
3.1.1. Provisioning Models . . . . . . . . . . . . . . . . . 9
3.1.1.1. Double-Sided Provisioning . . . . . . . . . . . . 9
3.1.1.2. Single-Sided Provisioning with Discovery . . . . . 9
3.1.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Virtual Private LAN Service . . . . . . . . . . . . . . . 11
3.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 12
3.2.2.1. BGP-Based Auto-Discovery . . . . . . . . . . . . . 12
3.2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 14
3.2.4. Pseudowires as VPLS Attachment Circuits . . . . . . . 15
3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires . . 15
3.3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 15
3.3.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 16
3.3.2.1. BGP-Based Auto-Discovery . . . . . . . . . . . . . 16
3.3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 19
3.5. Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 19
3.5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 21
3.5.2. Provisioning and Discovery . . . . . . . . . . . . . . 23
3.5.3. Non-Distributed VPLS as a Sub-Case . . . . . . . . . . 23
3.5.4. Splicing and the Data Plane . . . . . . . . . . . . . 24
4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Multihop EBGP Redistribution of L2VPN NLRIs . . . . . . . 24
4.2. EBGP Redistribution of L2VPN NLRIs with Multi-Segment
Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 25
4.3. Inter-Provider Application of Distributed VPLS
Signaling . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4. RT and RD Assignment Considerations . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. BGP-AD and VPLS-BGP Interoperability . . . . . . . . . . . . . 29
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 31
[RFC4664] describes a number of different ways in which sets of pseudowires may be combined together into "Provider Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different kinds of L2VPN. Different kinds of L2VPN may have different "provisioning models", i.e., different models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process", and once the information is discovered, the signaling protocol is automatically invoked to set up the required pseudowires. The semantics of the endpoint identifiers that the signaling protocol uses for a particular type of L2VPN are determined by the provisioning model. That is, different kinds of L2VPN, with different provisioning models, require different kinds of endpoint identifiers. This document specifies a number of L2VPN provisioning models and specifies the semantic structure of the endpoint identifiers required for each provisioning model.
[RFC4664]はL2VPNの異なる種類の数で、その結果、「プロバイダプロビジョニングレイヤ2つのVPN」（L2 PPVPNs、またはのL2VPN）に一緒に組み合わせることができる疑似回線を設定する多くの異なる方法を記載しています。 L2VPNの異なる種類の異なる「プロビジョニングモデル」、情報がどのようなエンティティで設定する必要があるもののために、すなわち、異なるモデルを有することができます。一度プロビジョニング情報は、「ディスカバリプロセス」によって分配され、情報が発見されると、シグナリングプロトコルは、自動的に必要な疑似回線を設定するために呼び出され、構成される。シグナリングプロトコルは、L2VPNの特定のタイプに使用するエンドポイント識別子のセマンティクスは、プロビジョニング・モデルによって決定されます。つまり、異なるプロビジョニングモデルとL2VPNの異なる種類であり、エンドポイント識別子の種類を必要とします。この文書では、L2VPNプロビジョニングモデルの数を指定し、各プロビジョニングモデルのために、必要なエンドポイント識別子の意味構造を指定します。
Either LDP (as specified in [RFC5036] and extended in [RFC4447]) or L2TP version 3 (as specified in [RFC3931] and extended in [RFC4667]) can be used as signaling protocols to set up and maintain PWs [RFC3985]. Any protocol that sets up connections must provide a way for each endpoint of the connection to identify the other; each PW signaling protocol thus provides a way to identify the PW endpoints. Since each signaling protocol needs to support all the different kinds of L2VPN and provisioning models, the signaling protocol must have a very general way of representing endpoint identifiers, and it is necessary to specify rules for encoding each particular kind of endpoint identifier into the relevant fields of each signaling protocol. This document specifies how to encode the endpoint identifiers of each provisioning model into the LDP and L2TPv3 signaling protocols.
LDP（[RFC5036]で指定し、[RFC4447]に拡張されるように）、またはL2TPバージョン3（[RFC3931]で指定し、[RFC4667]に拡張されるように）のいずれかを設定およびPW [RFC3985]を維持するためにシグナリングプロトコルとして使用することができます。接続を設定する任意のプロトコルは、他を識別するために、接続の各エンドポイントのための方法を提供しなければなりません。各PWシグナリングプロトコルは、このようにPWエンドポイントを識別するための方法を提供します。各シグナリングプロトコルはL2VPNおよびプロビジョニングモデルのすべての種類をサポートする必要があるため、シグナリングプロトコルは、エンドポイント識別子を表現する非常に一般的な方法を持っている必要があり、関連するフィールドにエンドポイント識別子の各々の特定の種類を符号化するためのルールを指定する必要があります各シグナリングプロトコルの。この文書では、LDPとL2TPv3のシグナリングプロトコルに各プロビジョニング・モデルのエンドポイント識別子を符号化する方法を指定します。
We make free use of terminology from [RFC3985], [RFC4026], [RFC4664], and [RFC5659] -- in particular, the terms "Attachment Circuit", "pseudowire", "PE" (provider edge), "CE" (customer edge), and "multi-segment pseudowire".
我々は、[RFC3985]、[RFC4026]、[RFC4664]及び[RFC5659]から用語を無料で利用 - 特に、用語 "添付回路"、 "疑似回線"、 "PE"（プロバイダエッジ）、 "CE" （カスタマエッジ）、及び「マルチセグメント疑似回線」。
Section 2 provides an overview of the relevant aspects of [RFC4447] and [RFC4667].
セクション2は、[RFC4447]及び[RFC4667]の関連局面の概要を提供します。
Section 3 details various provisioning models and relates them to the signaling process and to the discovery process. The way in which the signaling mechanisms can be integrated with BGP-based auto-discovery is covered in some detail.
セクション3つの詳細様々なプロビジョニングモデルとシグナリング処理及び発見プロセスにそれらに関する。シグナリングメカニズムはBGPベースの自動検出と統合することができる方法は、いくつかの詳細に覆われています。
Section 4 explains how the procedures for discovery and signaling can be applied in a multi-AS environment and outlines several options for the establishment of multi-AS L2VPNs.
第4章では、発見とシグナリングのための手順は、マルチAS環境に適用する方法を説明し、マルチASのL2VPNの確立のためのいくつかのオプションの概要を説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されるべき
Per [RFC4664], a pseudowire can be thought of as a relationship between a pair of "Forwarders". In simple instances of Virtual Private Wire Service (VPWS), a Forwarder binds a pseudowire to a single Attachment Circuit, such that frames received on the one are sent on the other, and vice versa. In Virtual Private LAN Service (VPLS), a Forwarder binds a set of pseudowires to a set of Attachment Circuits; when a frame is received from any member of that set, a MAC (Media Access Control) address table is consulted (and various 802.1d procedures executed) to determine the member or members of that set on which the frame is to be transmitted. In more complex scenarios, Forwarders may bind PWs to PWs, thereby "splicing" two PWs together; this is needed, e.g., to support distributed VPLS and some inter-AS scenarios.
[RFC4664]あたり、疑似回線が「フォワーダ」の対との間の関係と考えることができます。仮想専用線サービス（VPWS）の単純な例では、フォワーダは、その逆他の上で送信され、フレームが1で受信するように、単一のアタッチメント回路に疑似回線に結合します。仮想プライベートLANサービス（VPLS）で、フォワーダは、接続回線のセットに疑似回線のセットを結合します;フレームは、そのセットの任意のメンバーから受信した場合、部材又はフレームが送信されるべきでそのセットのメンバを決定するために、MAC（Media Access Control）アドレステーブルが参照され（および種々の802.1D手順が実行されます）。より複雑なシナリオでは、フォワーダは、それによって「スプライシング」2つのPW一緒のPWへのPWに結合してもよいです。これは、分散VPLSといくつかのAS間のシナリオをサポートするために、例えば、必要とされています。
In simple VPWS, where a Forwarder binds exactly one PW to exactly one Attachment Circuit, a Forwarder can be identified by identifying its Attachment Circuit. In simple VPLS, a Forwarder can be identified by identifying its PE device and its VPN.
フォワーダは正確に一つの接続回線に正確に一つのPWをバインドするシンプルなVPWSでは、フォワーダは、その接続回線を識別することによって識別することができます。簡単VPLSにおいて、フォワーダは、そのPEデバイス及びそのVPNを識別することによって識別することができます。
To set up a PW between a pair of Forwarders, the signaling protocol must allow the Forwarder at one endpoint to identify the Forwarder at the other. In [RFC4447], the term "Attachment Identifier", or "AI", is used to refer to a quantity whose purpose is to identify a Forwarder. In [RFC4667], the term "Forwarder Identifier" is used for the same purpose. In the context of this document, "Attachment Identifier" and "Forwarder Identifier" are used interchangeably.
フォワーダの対の間のPWを設定するために、シグナリングプロトコルは、一方のエンドポイントでフォワーダは、他にフォワーダを識別することができなければなりません。 [RFC4447]において、用語「添付ファイル識別子」、または「AI」は、その目的フォワーダを識別することである量を指すために使用されます。 [RFC4667]において、用語「フォワーダ識別子」は、同じ目的のために使用されます。この文書の文脈では、「添付ファイルの識別子」と「フォワーダ識別子」は互換的に使用されます。
[RFC4447] specifies two Forwarding Equivalence Class (FEC) elements that can be used when setting up pseudowires, the PWid FEC element, and the Generalized ID FEC element. The PWid FEC element carries only one Forwarder identifier; it can be thus be used only when both forwarders have the same identifier, and when that identifier can be coded as a 32-bit quantity. The Generalized ID FEC element carries two Forwarder identifiers, one for each of the two Forwarders being connected. Each identifier is known as an Attachment Identifier, and a signaling message carries both a "Source Attachment Identifier" (SAI) and a "Target Attachment Identifier" (TAI).
[RFC4447]は疑似回線、PWID FEC要素、及び一般ID FEC要素を設定する際に使用できる2つの転送等価クラス（FEC）の要素を指定します。 PWID FEC要素が一つだけフォワーダ識別子を運びます。両方のフォワーダは、同じ識別子を持つ場合にのみ、その識別子は、32ビットの量として符号化することができる場合には、このように使用することがすることができます。一般ID FEC要素は、2つのフォワーダ識別子、接続されている2つのフォワーダのそれぞれに1つずつ搬送します。各識別子は、添付識別子として知られており、シグナリング・メッセージは、「ソース添付識別子」（SAI）および「ターゲット添付識別子」（TAI）の両方を搬送します。
The Generalized ID FEC element also provides some additional structuring of the identifiers. It is assumed that the SAI and TAI will sometimes have a common part, called the "Attachment Group Identifier" (AGI), such that the SAI and TAI can each be thought of as the concatenation of the AGI with an "Attachment Individual Identifier" (AII). So the pair of identifiers is encoded into three fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is the concatenation of the AGI and the SAII, while the TAI is the concatenation of the AGI and the TAII.
一般ID FEC要素は、識別子のいくつかの追加の構造化を提供します。それはSAIとTAIが時々共通部分を有することが想定され、SAIとTAIはそれぞれ、「添付個体識別子」とAGIの連結として考えることができるように、「添付ファイルのグループID」（AGI）と呼ば（AII）。 AGI、ソースAII（SAII）、およびターゲットAII（TAII）：だから識別子のペアは、次の3つのフィールドにエンコードされます。 TAIは、AGIとTAIIの連結であるSAIは、AGIとSAIIの連結です。
Similarly, [RFC4667] allows using one or two Forwarder Identifiers to set up pseudowires. If only the target Forwarder Identifier is used in L2TP signaling messages, both the source and target Forwarders are assumed to have the same value. If both the source and target Forwarder Identifiers are carried in L2TP signaling messages, each Forwarder uses a locally significant identifier value.
同様に、[RFC4667]は疑似回線を設定するために一つまたは二つフォワーダ識別子を使用することを可能にします。ターゲットのみフォワーダ識別子がL2TPで使用される場合、シグナリングメッセージを、ソースとターゲットの両方のフォワーダは、同じ値を有すると仮定されます。ソースとターゲットの両方のフォワーダ識別子がシグナリングメッセージL2TPで運ばれる場合、各フォワーダは、局所的に有意な識別子の値を使用します。
The Forwarder Identifier in [RFC4667] is an equivalent term to Attachment Identifier in [RFC4447]. A Forwarder Identifier also consists of an Attachment Group Identifier and an Attachment Individual Identifier. Unlike the Generalized ID FEC element, the AGI and AII are carried in distinct L2TP Attribute-Value Pairs (AVPs). The AGI is encoded in the AGI AVP, and the SAII and TAII are encoded in the Local End ID AVP and the Remote End ID AVP, respectively. The source Forwarder Identifier is the concatenation of the AGI and SAII, while the target Forwarder Identifier is the concatenation of the AGI and TAII.
[RFC4667]でフォワーダ識別子は、[RFC4447]に添付ファイル識別子に等価な用語です。フォワーダ識別子はまた、添付ファイル、グループ識別子と添付ファイルの個々の識別子で構成されています。一般ID FEC要素とは異なり、AGIとAIIは、別個のL2TP属性値ペア（AVPの）で運ばれます。 AGIはAGI AVPでエンコードされ、そしてSAIIとTAIIはそれぞれ、ローカルエンドID AVPとリモートエンドID AVPでエンコードされています。識別子フォワーダターゲットはAGIとTAIIの連結であるソースフォワーダ識別子は、AGIとSAIIの連結です。
In applications that group sets of PWs into "Layer 2 Virtual Private Networks", the AGI can be thought of as a "VPN Identifier".
PWグループセット「レイヤ2つの仮想プライベートネットワーク」のアプリケーションでは、AGIは、「VPN識別子」と考えることができます。
It should be noted that while different forwarders support different applications, the type of application (e.g., VPLS vs. VPWS) cannot necessarily be inferred from the forwarders' identifiers. A router receiving a signaling message with a particular TAI will have to be able to determine which of its local forwarders is identified by that TAI, and to determine the application provided by that forwarder. But other nodes may not be able to infer the application simply by inspection of the signaling messages.
異なるフォワーダは、異なるアプリケーションをサポートしながら、アプリケーションの種類（VPWS対例えば、VPLS）は必ずしもフォワーダ識別子から推測することができないことに留意すべきです。特定のTAIを有するシグナリングメッセージを受信したルータは、そのTAIによって識別されるローカルフォワーダのかを決定できるようにする必要があります、そしてそのフォワーダによって提供されるアプリケーションを決定します。しかし、他のノードは、シグナリングメッセージの検査によって、単にアプリケーションを推測することができないかもしれません。
In this document, some further structure of the AGI and AII is proposed for certain L2VPN applications. We note that [RFC4447] defines a TLV structure for AGI and AII fields. Thus, an operator who chooses to use the AII structure defined here could also make use of different AGI or AII types if he also wanted to use a different structure for these identifiers for some other application. For example, the long prefix type of [RFC5003] could be used to enable the communication of administrative information, perhaps combined with information learned during auto-discovery.
この文書では、AGIとAIIのいくつかのさらなる構造は、特定のL2VPNアプリケーションのために提案されています。私たちは、[RFC4447]はAGIとAIIのフィールドのTLV構造を定義することに注意してください。彼はまた、いくつかの他のアプリケーションのためにこれらの識別子のために異なる構造を使用したい場合はこのように、ここで定義されたAII構造を使用することを選択したオペレータは、異なるAGIまたはAIIタイプを使用することができます。例えば、[RFC5003]の長いプレフィックスタイプは、おそらく自動検出時に学習した情報と組み合わせて、管理情報の通信を可能にするために使用することができます。
In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. A PW is a pair of such LSPs. In most of the L2VPN provisioning models, the two endpoints of a given PW can simultaneously initiate the signaling for it. They must therefore have some way of determining when a given pair of LSPs are intended to be associated together as a single PW.
LDPベースのシグナリングの任意の形態で、各PWエンドポイントは一方向LSPの作成を開始しなければなりません。 PWは、LSPの組です。 L2VPNプロビジョニングモデルのほとんどでは、与えられたPWの2つのエンドポイントは、同時に、それのためのシグナリングを開始することができます。したがって、それらはLSPの所与の対が単一のPWとして一緒に関連されることが意図されるときを決定するいくつかの方法を有していなければなりません。
The way in which this association is done is different for the various different L2VPN services and provisioning models. The details appear in later sections.
この関連付けが行われている方法は、様々な異なるL2VPNサービスおよびプロビジョニングモデルで異なります。詳細については、後のセクションに表示されます。
L2TP signaling inherently establishes a bidirectional session that carries a PW between two PW endpoints. The two endpoints can also simultaneously initiate the signaling for a given PW. It is possible that two PWs can be established for a pair of Forwarders.
L2TPシグナリングは本質的に2つのPWエンドポイント間PWを運ぶ双方向セッションを確立します。 2つのエンドポイントが同時に与えられたPWのためのシグナリングを開始することができます。 2つのPWSはフォワーダーのペアのために確立され得ることが可能です。
In order to avoid setting up duplicated pseudowires between two Forwarders, each PE must be able to independently detect such a pseudowire tie. The procedures of detecting a pseudowire tie are described in [RFC4667].
2つのフォワーダ間の重複擬似回線を設定しないようにするために、各PEは、独立して、このような疑似回線タイを検出することができなければなりません。疑似回線タイを検出する手順は、[RFC4667]に記載されています。
Every Forwarder in a PE must be associated with an Attachment Identifier (AI), either through configuration or through some algorithm. The Attachment Identifier must be unique in the context of the PE router in which the Forwarder resides. The combination <PE router, AI> must be globally unique.
PE内のすべてのフォワーダは、構成を介して、またはいくつかのアルゴリズムのいずれかを介して、アタッチメント識別子（AI）に関連付けされなければなりません。添付ファイル識別子は、フォワーダが存在するPEルータのコンテキスト内で一意でなければなりません。組み合わせ<PEルータ、AI>はグローバルに一意でなければなりません。
As specified in [RFC4447], the Attachment Identifier may consist of an Attachment Group Identifier (AGI) plus an Attachment Individual Identifier (AII). In the context of this document, an AGI may be thought of as a VPN-ID, or some attribute that is shared by all the Attachment Circuits that are allowed to be connected.
[RFC4447]で指定されるように、添付ファイル識別子は、添付グループ識別子（AGI）プラスアタッチメント個体識別子（AII）から構成されてもよいです。本文書の文脈において、AGIは、VPN-ID、または接続することが許可されているすべての接続回線によって共有されるいくつかの属性と考えることができます。
It is sometimes helpful to consider a set of attachment circuits at a single PE to belong to a common "pool". For example, a set of attachment circuits that connect a single CE to a given PE may be considered a pool. The use of pools is described in detail in Section 3.3.
一般的な「プール」に属するように、単一のPEでの接続回線のセットを考慮することが、時には便利です。例えば、所与のPEへの単一のCEを接続する接続回線のセットは、プールと考えることができます。プールの使用は、3.3節に詳細に記載されています。
The details for how to construct the AGI and AII fields identifying the pseudowire endpoints in particular provisioning models are discussed later in this document.
AGIを構築するために特定のプロビジョニングモデルにおける疑似回線のエンドポイントを識別AIIフィールドは、この文書で後述される方法の詳細。
We can now consider an LSP for one direction of a pseudowire to be identified by:
私たちは、今で識別されるように、擬似回線の一方の方向のためのLSPを検討することができます。
o <PE1, <AGI, AII1>, PE2, <AGI, AII2>>
<PE1 <AGI、AII1> EP2 <AGI、AII2 >>
and the LSP in the opposite direction of the pseudowire will be identified by:
そして疑似回線の反対方向にLSPはによって識別されます。
o <PE2, <AGI, AII2>, PE1, <AGI, AII1>>
<PE2 <AGI、AII2> PE1 <AGI、AII1 >>
A pseudowire is a pair of such LSPs. In the case of using L2TP signaling, these refer to the two directions of an L2TP session.
疑似回線は、LSPの組です。 L2TPシグナリングを用いる場合には、これらは、L2TPセッションの二つの方向を指します。
When a signaling message is sent from PE1 to PE2, and PE1 needs to refer to an Attachment Identifier that has been configured on one of its own Attachment Circuits (or pools), the Attachment Identifier is called a "Source Attachment Identifier". If PE1 needs to refer to an Attachment Identifier that has been configured on one of PE2's Attachment Circuits (or pools), the Attachment Identifier is called a "Target Attachment Identifier". (So an SAI at one endpoint is a TAI at the remote endpoint, and vice versa.)
シグナリングメッセージは、PE1からPE2に送られ、PE1は、独自の接続回線（またはプール）のいずれかに設定されている添付ファイルの識別子を参照する必要がある場合、添付ファイルの識別子が「ソース添付識別子」と呼ばれます。 PE1はPE2の接続回線（またはプール）のいずれかに設定されている添付ファイルの識別子を参照する必要がある場合、添付ファイルの識別子は、「ターゲットの添付ファイル識別子」と呼ばれています。 （SO一方のエンドポイントでSAIは、リモートエンドポイント、およびその逆でTAIです。）
In the signaling protocol, we define encodings for the following three fields:
シグナリングプロトコルでは、我々は次の3つのフィールドのためのエンコーディングを定義します。
o Attachment Group Identifier (AGI)
または添付ファイルのグループ識別子（AGI）
o Source Attachment Individual Identifier (SAII)
Oソースの添付ファイルの個別識別子（SAII）
o Target Attachment Individual Identifier (TAII)
Oターゲットアタッチメント個体識別子（TAII）
If the AGI is non-null, then the SAI consists of the AGI together with the SAII, and the TAI consists of the TAII together with the AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI, respectively.
AGIが非nullの場合、SAIはSAIIと一緒にAGIで構成されており、TAIはAGIと一緒TAIIで構成されています。 AGIがnullの場合、SAIIとTAIIは、それぞれ、SAIとTAIです。
The intention is that the PE that receives an LDP Label Mapping message or an L2TP Incoming Call Request (ICRQ) message containing a TAI will be able to map that TAI uniquely to one of its Attachment Circuits (or pools). The way in which a PE maps a TAI to an Attachment Circuit (or pool) should be a local matter (including the choice of whether to use some or all of the bytes in the TAI for the mapping). So as far as the signaling procedures are concerned, the TAI is really just an arbitrary string of bytes, a "cookie".
意図はLDPラベルマッピングメッセージを受信するか、またはTAIを含むL2TP着信呼要求（ICRQ）メッセージは、その接続回線（またはプール）のいずれかに一意TAIことをマップすることができるであろうPEということです。 PEは、接続回線（またはプール）にTAIをマップする方法は、（マッピングのためにTAI内のバイトの一部またはすべてを使用するかどうかの選択を含む）は、ローカルの問題でなければなりません。だから、限りシグナリング手順を懸念しているとして、TAIは本当に単なるバイトの任意の文字列、「クッキー」です。
In this section, we specify the way in which the pseudowire signaling using the notion of source and target Forwarder is applied for a number of different applications. For some of the applications, we specify the way in which different provisioning models can be used. However, this is not meant to be an exhaustive list of the applications, or an exhaustive list of the provisioning models that can be applied to each application.
このセクションでは、我々は、疑似回線がソースの概念を使用してシグナリングする方法を指定し、フォワーダは、多数の異なる用途に適用されるターゲット。アプリケーションのいくつかのために、私たちはさまざまなプロビジョニングモデルを使用することができる方法を指定します。しかし、これは、アプリケーションの完全なリスト、または各アプリケーションに適用することができ、プロビジョニングモデルの網羅的なリストであることを意味するものではありません。
The signaling specified in this document can be used to set up individually provisioned point-to-point pseudowires. In this application, each Forwarder binds a single PW to a single Attachment Circuit. Each PE must be provisioned with the necessary set of Attachment Circuits, and then certain parameters must be provisioned for each Attachment Circuit.
この文書で指定されたシグナルは、個々にプロビジョニングされ、ポイントツーポイント疑似回線を設定するために使用することができます。このアプリケーションでは、各フォワーダーは、単一の接続回線に単一PWをバインドします。各PEは、接続回線の必要なセットをプロビジョニングする必要があり、その後、特定のパラメータは、それぞれの接続回線用にプロビジョニングされなければなりません。
In this model, the Attachment Circuit must be provisioned with a local name, a remote PE address, and a remote name. During signaling, the local name is sent as the SAII, the remote name as the TAII, and the AGI is null. If two Attachment Circuits are to be connected by a PW, the local name of each must be the remote name of the other.
このモデルでは、接続回線は、ローカル名、リモートPEアドレス、およびリモート名をプロビジョニングする必要があります。シグナリングの中に、ローカル名はSAII、TAIIとしてリモート名として送信され、AGIはNULLです。 2つの接続回線はPWで接続する場合は、それぞれのローカル名は、他のリモート名でなければなりません。
Note that if the local name and the remote name are the same, the PWid FEC element can be used instead of the Generalized ID FEC element in the LDP-based signaling.
ローカル名とリモート名が同じであれば、PWID FEC要素が代わりLDPベースのシグナリングに一般ID FEC要素を用いることもできることに留意されたいです。
With L2TP signaling, the local name is sent in Local End ID AVP, and the remote name in Remote End ID AVP. The AGI AVP is optional. If present, it contains a zero-length AGI value. If the local name and the remote name are the same, Local End ID AVP can be omitted from L2TP signaling messages.
L2TPシグナリングを使用すると、ローカル名は、ローカルエンドID AVPに送信され、リモートエンドID AVPでリモート名。 AGI AVPはオプションです。存在する場合、それはゼロ長AGI値を含みます。ローカル名とリモート名が同じである場合、ローカルエンドID AVPは、シグナリングメッセージL2TPから省略することができます。
In this model, each Attachment Circuit must be provisioned with a local name. The local name consists of a VPN-ID (signaled as the AGI) and an Attachment Individual Identifier that is unique relative to the AGI. If two Attachment Circuits are to be connected by a PW, only one of them needs to be provisioned with a remote name (which of course is the local name of the other Attachment Circuit). Neither needs to be provisioned with the address of the remote PE, but both must have the same VPN-ID.
このモデルでは、各接続回線は、ローカル名を使用してプロビジョニングする必要があります。ローカル名は、VPN-ID（AGIとしてシグナリング）とAGIに固有の相対的アタッチメント個体識別子から成ります。 2つの接続回線はPWで接続する場合は、いずれか一方のみが（もちろん、他の接続回線のローカル名です）リモート名でプロビジョニングする必要があります。いずれもリモートPEのアドレスをプロビジョニングする必要がないが、両方が同じVPN-IDを有していなければなりません。
As part of an auto-discovery procedure, each PE advertises its <VPN-id, local AII> pairs. Each PE compares its local <VPN-id, remote AII> pairs with the <VPN-id, local AII> pairs advertised by the other PEs. If PE1 has a local <VPN-id, remote AII> pair with value <V, fred>, and PE2 has a local <VPN-id, local AII> pair with value <V, fred>, PE1 will thus be able to discover that it needs to connect to PE2. When signaling, it will use "fred" as the TAII, and will use V as the AGI. PE1's local name for the Attachment Circuit is sent as the SAII.
自動発見手順の一部として、各PEは、その<VPN-ID、ローカルAII>ペアをアドバタイズ。各PEは、他のPEによってアドバタイズ<VPN-ID、ローカルAII>ペアとのローカル<VPN-ID、リモートAII>ペアを比較します。 PE1は<V、フレッド>の値を持つローカル<VPN-ID、リモートAII>対を有し、PE2値ローカル<VPN-ID、ローカルAII>ペアを有する<V、フレッド>場合、PE1は、このようにすることができるであろうそれはPE2に接続する必要があることを発見。シグナリングの場合は、TAIIとして「フレッド」を使用し、AGIとしてVを使用します。接続回線のためのPE1のローカル名をSAIIとして送信されます。
The primary benefit of this provisioning model when compared to Double-Sided Provisioning is that it enables one to move an Attachment Circuit from one PE to another without having to reconfigure the remote endpoint. However, compared to the approach described in Section 3.3 below, it imposes a greater burden on the discovery mechanism, because each Attachment Circuit's name must be advertised individually (i.e., there is no aggregation of Attachment Circuit names in this simple scheme).
両面プロビジョニングと比較して、このプロビジョニング・モデルの主な利点は、それがリモートエンドポイントを再構成することなく、別のPEからの接続回線を移動するために1つを可能にすることです。各接続回線の名前（すなわち、この単純な方式で接続回線名の全く凝集が存在しない）個別にアドバタイズされなければならないからである。しかし、第下記3.3に記載の手法に比べて、それは、発見機構に大きな負担を課します
The LDP-based signaling follows the procedures specified in [RFC4447]. That is, one PE (PE1) sends a Label Mapping message to another PE (PE2) to establish an LSP in one direction. If that message is processed successfully, and there is not yet an LSP for the pseudowire in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping message to PE1.
LDPベースのシグナリングは、[RFC4447]で指定された手順に従います。つまり、1つのPE（PE1）が一方向にLSPを確立する別のPE（PE2）にラベルマッピングメッセージを送信します。そのメッセージが正常に処理され、その反対（PE1-> PE2）方向の疑似回線用LSPがまだ存在しない場合、PE2はPE1にLabel Mappingメッセージを送信します。
In addition to the procedures of [RFC4447], when a PE receives a Label Mapping message, and the TAI identifies a particular Attachment Circuit that is configured to be bound to a point-to-point PW, then the following checks must be made.
PEは、ラベルマッピングメッセージを受信し、TAIがポイントツーポイントPWに結合されるように構成されている特定の接続回線を識別する[RFC4447]の手順に加えて、次のチェックが行われなければなりません。
If the Attachment Circuit is already bound to a pseudowire (including the case where only one of the two LSPs currently exists), and the remote endpoint is not PE1, then PE2 sends a Label Release message to PE1, with a Status Code meaning "Attachment Circuit bound to different PE", and the processing of the Mapping message is complete.
接続回線がすでにスードワイヤにバインドされている場合（2つのLSPの一つだけが現在存在している場合を含む）、およびリモートエンドポイントはPE1は、その後、PE2は、ステータスコードは、「添付ファイルを意味し、PE1へのラベル解放メッセージを送信していません回路「は、異なるPEに結合し、およびマッピングメッセージの処理が完了しました。
If the Attachment Circuit is already bound to a pseudowire (including the case where only one of the two LSPs currently exists), but the AI at PE1 is different than that specified in the AGI/SAII fields of the Mapping message then PE2 sends a Label Release message to PE1, with a
接続回線がすでに疑似回線に結合されている場合（二LSPの一方のみが現在存在している場合を含む）が、PE1におけるAIは、マッピングメッセージのAGI / SAIIフィールドに指定されたものとは異なる次いでPE2は、標識を送信しますで、PE1にメッセージをリリース
Status Code meaning "Attachment Circuit bound to different remote Attachment Circuit", and the processing of the Mapping message is complete.
「異なるリモート接続回線にバインドされた接続回線」、およびMappingメッセージの処理が完了したことを意味ステータスコード。
Similarly, with the L2TP-based signaling, when a PE receives an ICRQ message, and the TAI identifies a particular Attachment Circuit that is configured to be bound to a point-to-point PW, it performs the following checks.
PEはICRQメッセージを受信し、TAIがポイントツーポイントPWに結合されるように構成されている特定の接続回線を識別する場合同様、L2TPベースのシグナリングを用いて、それは次のチェックを行います。
If the Attachment Circuit is already bound to a pseudowire, and the remote endpoint is not PE1, then PE2 sends a Call Disconnect Notify (CDN) message to PE1, with a Status Code meaning "Attachment Circuit bound to different PE", and the processing of the ICRQ message is complete.
接続回線がすでに擬似配線に結合され、リモートエンドポイントがPE1でない場合は、PE2は、「接続回線別のPEに結合された」という意味のステータスコード、および処理して、PE1へのコールを切断通知（CDN）メッセージを送信しますICRQメッセージの完了です。
If the Attachment Circuit is already bound to a pseudowire, but the pseudowire is bound to a Forwarder on PE1 with the AI different than that specified in the SAI fields of the ICRQ message, then PE2 sends a CDN message to PE1, with a Status Code meaning "Attachment Circuit bound to different remote Attachment Circuit", and the processing of the ICRQ message is complete.
接続回線がすでにスードワイヤにバインドされていますが、スードワイヤはICRQメッセージのSAIフィールドに指定されたものと異なるAIとPE1上のフォワーダにバインドされている場合は、PE2は、ステータスコードと、PE1にCDNメッセージを送信します「異なるリモート接続回線にバインドされた接続回線」、およびICRQメッセージの処理が完了したことを意味。
These errors could occur as the result of misconfigurations.
これらのエラーは、設定ミスの結果として発生する可能性があります。
In the VPLS application [RFC4762], the Attachment Circuits can be thought of as LAN interfaces that attach to "virtual LAN switches", or, in the terminology of [RFC4664], "Virtual Switching Instances" (VSIs). Each Forwarder is a VSI that attaches to a number of PWs and a number of Attachment Circuits. The VPLS service requires that a single pseudowire be created between each pair of VSIs that are in the same VPLS. Each PE device may have multiple VSIs, where each VSI belongs to a different VPLS.
VPLSアプリケーション[RFC4762]で、接続回線は、[RFC4664]、「仮想スイッチングインスタンス」（のVSI）の用語では、「仮想LANスイッチ」に接続などのLANインタフェースの考え、あるいはすることができます。各フォワーダーは、PW数や接続回線の数に取り付けるVSIです。 VPLSサービスは、単一の疑似回線が同じVPLSにあるのVSIの各対の間に作成されることを必要とします。各PEデバイスは、各VSIは異なるVPLSに属する複数のVSIを有していてもよいです。
Each VPLS must have a globally unique identifier, which in [RFC4762] is referred to as the VPLS identifier (or VPLS-id). Every VSI must be configured with the VPLS-id of the VPLS to which it belongs.
各VPLSは、[RFC4762]にVPLS識別子（またはVPLS-ID）と呼ばれるグローバル一意識別子を有していなければなりません。すべてのVSIは、それが属するVPLSのVPLS-IDを設定する必要があります。
Each VSI must also have a unique identifier, which we call a VSI-ID. This can be formed automatically by concatenating its VPLS-id with an IP address of its PE router. (Note that the PE address here is used only as a form of unique identifier; a service provider could choose to use some other numbering scheme if that was desired, as long as each VSI is assigned an identifier that is unique within the VPLS instance. See Section 4.4 for a discussion of the assignment of identifiers in the case of multiple providers.)
各VSIはまた、我々はVSI-IDを呼び出して一意の識別子を、持っている必要があります。これは、PEルータのIPアドレスとのVPLS-IDを連結することによって自動的に形成することができます。 （ここでPEアドレスのみユニークな識別子の形式として使用されることに注意してください、サービスプロバイダは、それがあれば、各VSIは、VPLSインスタンス内で一意の識別子が割り当てられるように、所望された場合、いくつかの他の番号付けスキームを使用することを選択できます。複数のプロバイダの場合は、識別子の割り当てについての説明は、4.4節を参照してください。）
This section specifies how BGP can be used to discover the information necessary to build VPLS instances.
このセクションでは、BGPは、VPLSインスタンスを構築するために必要な情報を発見するために使用することができるかを指定します。
When BGP-based auto-discovery is used for VPLS, the AFI/SAFI (Address Family Identifier / Subsequent Address Family Identifier) [RFC4760] will be:
BGPベースの自動検出は、VPLS、AFI / SAFIのために使用された場合（アドレスファミリー識別子/次のアドレスファミリー識別子）[RFC4760]は次のようになります。
o An AFI (25) for L2VPN. (This is the same for all L2VPN schemes.)
L2VPNのためのAFI（25）O。 （これは、すべてのL2VPNスキームのと同じです。）
o A SAFI (65) specifically for an L2VPN service whose pseudowires are set up using the procedures described in the current document.
具体的には疑似回線現在の文書に記載された手順を使用して設定されているL2VPNサービスのO SAFI（65）。
See Section 6 for further discussion of AFI/SAFI assignment.
AFI / SAFI割り当てのさらなる議論については、セクション6を参照してください。
In order to use BGP-based auto-discovery, there must be at least one globally unique identifier associated with a VPLS, and each such identifier must be encodable as an 8-byte Route Distinguisher (RD). Any method of assigning one or more unique identifiers to a VPLS and encoding each of them as an RD (using the encoding techniques of [RFC4364]) will do.
BGPベースの自動検出を使用するために、そこVPLSに関連する少なくとも一つのグローバル一意識別子である必要があり、このような各識別子は、8バイトのルート識別子（RD）として符号化可能でなければなりません。 VPLSへの1つ以上の固有の識別子を割り当て、RDとしてそれらのそれぞれをコードする（[RFC4364]の符号化技術を使用して）のいずれかの方法を行います。
Each VSI needs to have a unique identifier that is encodable as a BGP Network Layer Reachability Information (NLRI). This is formed by prepending the RD (from the previous paragraph) to an IP address of the PE containing the VSI. Note that the role of this address is simply as a readily available unique identifier for the VSIs within a VPN; it does not need to be globally routable, but it must be unique within the VPLS instance. An alternate scheme to assign unique identifiers to each VSI within a VPLS instance (e.g., numbering the VSIs of a single VPN from 1 to n) could be used if desired.
各VSIは、BGPネットワーク層到達可能性情報（NLRI）としてエンコード可能である一意の識別子を持っている必要があります。これは、（前段落から）VSIを含むPEのIPアドレスにRDを付加することによって形成されます。このアドレスの役割は、単にVPN内のVSIのために容易に利用可能な一意の識別子としてであることに注意してください。それがグローバルにルーティング可能である必要はありませんが、それはVPLSインスタンス内で一意でなければなりません。所望される場合（例えば、1からnまでの単一VPNのVSIに番号付け）VPLSインスタンス内の各VSIに一意の識別子を割り当てるための代替のスキームを使用することができます。
When using the procedures described in this document, it is necessary to assign a single, globally unique VPLS-id to each VPLS instance [RFC4762]. This VPLS-id must be encodable as a BGP Extended Community [RFC4360]. As described in Section 6, two Extended Community subtypes are defined by this document for this purpose. The Extended Community MUST be transitive.
この文書に記載されている手順を使用する場合は、それぞれに単一のグローバルにユニークなVPLS-IDを割り当てる必要がある場合、[RFC4762]をVPLS。これは、VPLS-idはコミュニティ[RFC4360]拡張BGPのようにコード化可能でなければなりません。第6節で説明したように、2つの拡張共同体サブタイプは、この目的のために、この文書で定義されています。拡張コミュニティは推移でなければなりません。
The first Extended Community subtype is a Two-octet AS Specific Extended Community. The second Extended Community subtype is an IPv4 Address Specific Extended Community. The encoding of such Communities is defined in [RFC4360]. These encodings ensure that a service provider can allocate a VPLS-id without risk of collision with another provider. However, note that coordination of VPLS-ids among providers is necessary for inter-provider L2VPNs, as described in Section 4.4.
最初の拡張コミュニティサブタイプは、2オクテットAS固有の拡張コミュニティです。第二拡張コミュニティサブタイプは、IPv4アドレスの特定拡張コミュニティです。そのようなコミュニティの符号化は[RFC4360]で定義されています。これらのエンコーディングは、サービスプロバイダは、別のプロバイダとの衝突の危険なしにVPLS-IDを割り当てることができますことを確認してください。しかしながら、セクション4.4で説明したようにプロバイダの間でVPLS-IDの調整が、インタープロバイダのL2VPNのために必要であることに注意。
Each VSI also needs to be associated with one or more Route Target (RT) Extended Communities. These control the distribution of the NLRI, and hence will control the formation of the overlay topology of pseudowires that constitutes a particular VPLS.
各VSIはまた、1つまたは複数のルートターゲット（RT）拡張コミュニティに関連付けする必要があります。これらは、NLRIの分布を制御し、ひいては特定のVPLSを構成する疑似回線のオーバーレイ・トポロジの形成を制御します。
Auto-discovery proceeds by having each PE distribute, via BGP, the NLRI for each of its VSIs, with itself as the BGP next hop, and with the appropriate RT for each such NLRI. Typically, each PE would be a client of a small set of BGP route reflectors, which would redistribute this information to the other clients.
各PEは、BGPネクストホップとして、このような各NLRI適しRTでそれ自体と、BGP、そののVSIのそれぞれについてNLRIを介して、配布有することにより自動検出進みます。典型的には、各PEは、他のクライアントにこの情報を再配布することになるBGPルートリフレクタの小さな組のクライアントであろう。
If a PE receives a BGP update from which any of the elements specified above is absent, the update should be ignored.
PEは、上記指定された要素のいずれかが存在しないから、BGPアップデートを受信した場合、更新は無視されるべきです。
If a PE has a VSI with a particular RT, it can then import all the NLRIs that have that same RT, and from the BGP next hop attribute of these NLRI it will learn the IP addresses of the other PE routers which have VSIs with the same RT. The considerations in Section 4.3.3 of [RFC4364] on the use of route reflectors apply.
PEは、特定のRTとVSIを持っている場合、それは、同じRTことを持っているすべてのNLRIをインポートすることができ、これらのNLRIのBGPネクストホップ属性からそれはとのVSIを持ち、他のPEルータのIPアドレスを学習します同じRT。ルートリフレクタの使用に[RFC4364]のセクション4.3.3において考慮事項が当てはまります。
If a particular VPLS is meant to be a single fully connected LAN, all its VSIs will have the same RT, in which case the RT could be (though it need not be) an encoding of the VPN-id. A VSI can be placed in multiple VPLSes by assigning it multiple RTs.
特定のVPLSは、単一の完全に接続されたLANであることを意味する場合、そのすべてのVSIは同じRTを持つことになり、RTは（それがある必要はないが）VPN-IDを符号化することができた場合。 VSIはそれを複数のRTを割り当てることによって、複数のVPLSesに配置することができます。
Note that hierarchical VPLS can be set up by assigning multiple RTs to some of the VSIs; the RT mechanism allows one to have complete control over the pseudowire overlay that constitutes the VPLS topology.
階層VPLSはのVSIの一部に複数のRTを割り当てることによって設定することができることに留意されたいです。 RTメカニズムは、1つのVPLSトポロジを構成する、疑似回線のオーバーレイを完全に制御を持つことができます。
If Distributed VPLS (described in Section 3.5) is deployed, only the Network-facing PEs (N-PEs) participate in BGP-based auto-discovery. This means that an N-PE would need to advertise reachability to each of the VSIs that it supports, including those located in User-facing PEs (U-PEs) to which it is connected. To create a unique identifier for each such VSI, an IP address of each U-PE combined with the RD for the VPLS instance could be used.
（セクション3.5で説明）分散VPLSが展開されている場合は、唯一のネットワーク側のPE（N-PES）BGPベースの自動検出に参加しています。これは、N-PEは、それが接続されているユーザーに面するPES（U-PES）に位置するものを含めて、それがサポートしているのVSIのそれぞれに到達可能性をアドバタイズする必要があることを意味します。このような各VSIの一意の識別子を作成するために、VPLSインスタンスのRDと組み合わせた各U-PEのIPアドレスを使用することができます。
In summary, the BGP advertisement for a particular VSI at a given PE will contain:
要約すると、所与のPEで特定のVSIのBGP広告が含まれます。
o an NLRI of AFI = L2VPN, SAFI = VPLS, encoded as RD:PE_addr
PE_addr：AFI = L2VPNのNLRI、RDとしてエンコードSAFIの=のVPLS、O
o a BGP next hop equal to the loopback address of the PE
PEのループバックアドレスに等しいBGPネクストホップO
o an Extended Community Attribute containing the VPLS-id
VPLS-IDを含む拡張コミュニティアトリビュートO
o an Extended Community Attribute containing one or more RTs.
一回の以上のRTを含む拡張コミュニティアトリビュートO。
See Section 6 for discussion of the AFI and SAFI values. The format for the NLRI encoding is:
AFIとSAFI値の議論については、セクション6を参照してください。 NLRIエンコーディングの形式は次のとおりです。
+------------------------------------+
| Length (2 octets) |
+------------------------------------+
| Route Distinguisher (8 octets) |
+------------------------------------+
| PE_addr (4 octets) |
+------------------------------------+
Note that this advertisement is quite similar to the NLRI format defined in [RFC4761], the main difference being that [RFC4761] also includes a label block in the NLRI. Interoperability between the VPLS scheme defined here and that defined in [RFC4761] is beyond the scope of this document.
主な違いは、[RFC4761]はまた、NLRIのラベルブロックを含むことがある、この広告は、[RFC4761]で定義されたNLRIフォーマットと全く同様であることに留意されたいです。ここで定義されたVPLS方式間と[RFC4761]で定義された相互運用性は、この文書の範囲外です。
It is necessary to create Attachment Identifiers that identify the VSIs. In the preceding section, a VSI-ID was encoded as RD:PE_addr, and the VPLS-id was carried in a BGP Extended Community. For signaling purposes, this information is encoded as follows. We encode the VPLS-id in the AGI field, and place the PE_addr (or, more precisely, the VSI-ID that was contained in the NLRI in BGP, minus the RD) in the TAII field. The combination of AGI and TAII is sufficient to fully specify the VSI to which this pseudowire is to be connected, in both single AS and inter-AS environments. The SAII MUST be set to the PE_addr of the sending PE (or, more precisely, the VSI-ID, without the RD, of the VSI associated with this VPLS in the sending PE) to enable signaling of the reverse half of the PW if needed.
のVSIを特定する添付ファイル識別子を作成する必要があります。 PE_addr、およびVPLS-IDは、コミュニティ拡張BGPに行った：前のセクションでは、VSI-IDは、RDとして符号化されました。次のようにシグナリング目的のために、この情報を符号化します。我々は、AGIフィールドにVPLS-IDを符号化し、TAIIフィールドにPE_addr（または、より正確には、BGPにNLRIに含まれていたVSI-ID、マイナスRD）を置きます。 AGIとTAIIの組み合わせは、完全にこの疑似回線は、単一のASおよびインターAS環境の両方で、接続されるべきVSIを特定するのに十分です。 SAIIはPWの逆半分場合のシグナリングを可能にするために送信PEのPE_addr（または、より正確には、これに関連したVSIのRDせずVSI-IDは、送信PEにVPLS）に設定しなければなりません必要に応じて。
The structure of the AGI and AII fields for the Generalized ID FEC in LDP is defined in [RFC4447]. The AGI field in this case consists of a Type of 1, a length field of value 8, and the 8 bytes of the
LDPに一般ID FECためAGIとAIIフィールドの構造は、[RFC4447]で定義されています。この場合AGIフィールドが1のタイプ、値8の長さフィールド、及び8バイトから成り
VPLS-id. The AIIs consist of a Type of 1, a length field of value 4, followed by the 4-byte PE address (or other 4-byte identifier). See Section 6 for discussion of the AGI and AII Type assignment.
VPLS-ID。 AIIsは、4バイトのPEアドレス（または他の4バイトの識別子）が続く1のタイプ、値4の長さフィールドから成ります。 AGIとAIIタイプの割り当ての議論については、セクション6を参照してください。
The encoding of the AGI and AII in L2TP is specified in [RFC4667].
L2TPにおけるAGIとAIIの符号化は[RFC4667]で指定されています。
Note that it is not possible using this technique to set up more than one PW per pair of VSIs.
それはのVSIのペアごとに複数のPWを設定するには、この技術を使用しては不可能であることに注意してください。
It is also possible using this technique to set up a PW that attaches at one endpoint to a VSI, but at the other endpoint only to an Attachment Circuit. There may be more than one PW terminating on a given VSI, which must somehow be distinguished, so each PW must have an SAII that is unique relative to the VSI-ID.
それはVSIに、他のエンドポイントでのみ接続回線に1つのエンドポイントで、添付PWを設定するには、この技術を使用しても可能です。そこ何とか区別されなければならない所定のVSIに複数のPW終端とすることができるので、各PWは、VSI-IDに固有の相対的SAIIを有していなければなりません。
The "Colored Pools" model of operation provides an automated way to deliver VPWS. In this model, each PE may contain several pools of Attachment Circuits, each pool associated with a particular VPN. A PE may contain multiple pools per VPN, as each pool may correspond to a particular CE device. It may be desired to create one pseudowire between each pair of pools that are in the same VPN; the result would be to create a full mesh of CE-CE Virtual Circuits for each VPN.
操作の「カラードプール」モデルは、VPWSを提供する自動化された方法を提供します。このモデルでは、各PEは、特定のVPNに関連付けられた各プールを接続回線のいくつかのプールを含んでいてもよいです。各プールは、特定のCE機器に対応することができるようにPEは、VPNごとに複数のプールを含有してもよいです。同じVPNにあるプールの各対の間に1つの疑似回線を作成することが望ましいです。結果は、各VPNのためのCE-CE仮想回線のフルメッシュを作成することです。
Each pool is configured, and associated with:
各プールを構成し、関連付けられています。
o a set of Attachment Circuits;
接続回線のセットO;
o a "color", which can be thought of as a VPN-id of some sort;
ある種のVPN-IDと考えることができ、「色」、O。
o a relative pool identifier, which is unique relative to the color.
色に固有相対的な相対プール識別子、O。
[Note: depending on the technology used for Attachment Circuits (ACs), it may or may not be necessary to provision these circuits as well. For example, if the ACs are frame relay circuits, there may be some separate provisioning system to set up such circuits. Alternatively, "provisioning" an AC may be as simple as allocating an unused VLAN ID on an interface and communicating the choice to the customer. These issues are independent of the procedures described in this document.]
[注：接続回線（ACS）のために使用される技術に依存し、それはまたは同様にこれらの回路を設ける必要がなくてもよいです。 ACSは、フレームリレー回路である場合、例えば、このような回路を設定するためにいくつかの別個の供給システムが存在してもよいです。あるいは、「プロビジョニング」ACインターフェイスで使用されていないVLAN IDを割り当て、顧客の選択を通信するように単純であってもよいです。これらの問題は、この文書で説明する手順とは無関係です。]
The pool identifier and color, taken together, constitute a globally unique identifier for the pool. Thus, if there are n pools of a given color, their pool identifiers can be (though they do not need to be) the numbers 1-n.
一緒にプール識別子と色が、プールのグローバル一意識別子を構成しています。番号1-nは（彼らがする必要はありませんが）このように、与えられた色のn個のプールがある場合は、そのプール識別子をすることができます。
The semantics are that a pseudowire will be created between every pair of pools that have the same color, where each such pseudowire will be bound to one Attachment Circuit from each of the two pools.
セマンティクスは、疑似回線がそのような各疑似回線は、2つのプールの各々から1アタッチメント回路に結合される同じ色を有するプールのすべての対の間に作成されることです。
If each pool is a set of Attachment Circuits leading to a single CE device, then the Layer 2 connectivity among the CEs is controlled by the way the colors are assigned to the pools. To create a full mesh, the "color" would just be a VPN-id.
各プールは、単一のCEデバイスに至る接続回線の設定された場合、その後のCE間のレイヤ2接続は、色がプールに割り当てられている方法によって制御されます。フルメッシュを作成するには、「色」だけでVPN-IDになります。
Optionally, a particular Attachment Circuit may be configured with the relative pool identifier of a remote pool. Then, that Attachment Circuit would be bound to a particular pseudowire only if that pseudowire's remote endpoint is the pool with that relative pool identifier. With this option, the same pairs of Attachment Circuits will always be bound via pseudowires.
必要に応じて、特定の接続回線は、リモートプールの相対プール識別子で構成されてもよいです。次に、その接続回線は、そのスードワイヤのリモートエンドポイントは、その相対的なプールの識別子とプールである場合にのみ、特定の疑似回線にバインドされます。このオプションを使用すると、接続回線の同じペアが常に疑似回線を介して結合されます。
This section specifies how BGP can be used to discover the information necessary to build VPWS instances.
このセクションでは、BGPはVPWSインスタンスを構築するために必要な情報を発見するために使用することができるかを指定します。
When BGP-based auto-discovery is used for VPWS, the AFI/SAFI will be:
BGPベースの自動検出がVPWSのために使用されている場合は、AFI / SAFIは次のようになります。
o An AFI specified by IANA for L2VPN. (This is the same for all L2VPN schemes.)
L2VPNのためにIANAによって指定されたAFI O。 （これは、すべてのL2VPNスキームのと同じです。）
o A SAFI specified by IANA specifically for an L2VPN service whose pseudowires are set up using the procedures described in the current document.
具体的には、その疑似現在の文書に記載された手順を使用して設定されているL2VPNサービスにIANAによって指定SAFI O。
See Section 6 for further discussion of AFI/SAFI assignment.
AFI / SAFI割り当てのさらなる議論については、セクション6を参照してください。
In order to use BGP-based auto-discovery, there must be one or more unique identifiers associated with a particular VPWS instance. Each identifier must be encodable as an RD (Route Distinguisher). The globally unique identifier of a pool must be encodable as NLRI; the pool identifier, which we define to be a 4-byte quantity, is appended to the RD to create the NLRI.
BGPベースの自動検出を使用するために、特定のVPWSのインスタンスに関連する1つまたは複数の固有の識別子が存在しなければなりません。各識別子は、RD（ルート識別子）として符号化可能でなければなりません。プールのグローバル一意識別子は、NLRIとしてエンコード可能でなければなりません。我々は、4バイトの量であると定義プール識別子は、NLRIを作成するために、RDに付加されます。
When using the procedures described in this document, it is necessary to assign a single, globally unique identifier to each VPWS instance.
この文書に記載されている手順を使用する場合、各VPWSインスタンスに単一のグローバル一意識別子を割り当てる必要があります。
This identifier must be encodable as a BGP Extended Community [RFC4360]. As described in Section 6, two Extended Community subtypes are defined by this document for this purpose. The Extended Community MUST be transitive.
この識別子は、BGP拡張コミュニティ[RFC4360]のようにコード化可能でなければなりません。第6節で説明したように、2つの拡張共同体サブタイプは、この目的のために、この文書で定義されています。拡張コミュニティは推移でなければなりません。
The first Extended Community subtype is a Two-octet AS Specific Extended Community. The second Extended Community subtype is an IPv4 Address Specific Extended Community. The encoding of such Communities is defined in [RFC4360]. These encodings ensure that a service provider can allocate a VPWS identifier without risk of collision with another provider. However, note that co-ordination of VPWS identifiers among providers is necessary for inter-provider L2VPNs, as described in Section 4.4.
最初の拡張コミュニティサブタイプは、2オクテットAS固有の拡張コミュニティです。第二拡張コミュニティサブタイプは、IPv4アドレスの特定拡張コミュニティです。そのようなコミュニティの符号化は[RFC4360]で定義されています。これらのエンコーディングは、サービスプロバイダは、別のプロバイダとの衝突の危険なしVPWS識別子を割り当てることができますことを確認してください。しかし、4.4節で説明したようにプロバイダの間でVPWS識別子の協調は、インタープロバイダのL2VPNのために必要であることに注意。
Each pool must also be associated with an RT (route target), which may also be an encoding of the color. If the desired topology is a full mesh of pseudowires, all pools may have the same RT. See Section 3.4 for a discussion of other topologies.
各プールはまた、色の符号化であってもよいRT（ルートターゲット）に関連付けされなければなりません。希望のトポロジは、疑似回線のフルメッシュである場合は、すべてのプールには、同じRTを有することができます。他のトポロジの議論については3.4節を参照してください。
Auto-discovery proceeds by having each PE distribute, via BGP, the NLRI for each of its pools, with itself as the BGP next hop, and with the RT that encodes the pool's color. If a given PE has a pool with a particular color (RT), it must receive, via BGP, all NLRI with that same color (RT). Typically, each PE would be a client of a small set of BGP route reflectors, which would redistribute this information to the other clients.
各PEは、BGPネクストホップとして、プールの色をコードRTでそれ自体と、BGP、そのプールのそれぞれに対するNLRIを介して、配布有することにより自動検出進みます。所与のPEは、特定の色（RT）とプールがある場合、その同じ色（RT）で、BGPを介して、すべてのNLRIを受信しなければなりません。典型的には、各PEは、他のクライアントにこの情報を再配布することになるBGPルートリフレクタの小さな組のクライアントであろう。
If a PE receives a BGP update from which any of the elements specified above is absent, the update should be ignored.
PEは、上記指定された要素のいずれかが存在しないから、BGPアップデートを受信した場合、更新は無視されるべきです。
If a PE has a pool with a particular color, it can then receive all the NLRI that have that same color, and from the BGP next hop attribute of these NLRI will learn the IP addresses of the other PE routers that have pools switches with the same color. It also learns the unique identifier of each such remote pool, as this is encoded in the NLRI. The remote pool's relative identifier can be extracted from the NLRI and used in the signaling, as specified below.
PEは、特定の色を持つプールを持っている場合、それはその後、これらのNLRIのBGPネクストホップ属性から同じ色を持つすべてのNLRIを受け取ることができるプールを持っている他のPEルータのIPアドレスを学習しますとスイッチ同じ色。これはNLRIで符号化されたとしても、そのような各リモートプールの一意の識別子を学習します。以下に指定されたリモートプールの相対的な識別子は、NLRIから抽出されシグナリングに使用することができます。
In summary, the BGP advertisement for a particular pool of attachment circuits at a given PE will contain:
要約すると、所与のPEに接続回線の特定のプールのBGP広告が含まれます。
o an NLRI of AFI = L2VPN, SAFI = VPLS, encoded as RD:pool_num;
; pool_num：AFI = L2VPNのNLRI、RDとしてエンコードSAFIの=のVPLS、O
o a BGP next hop equal to the loopback address of the PE;
PEのループバックアドレスに等しいBGPネクストホップO。
o an Extended Community Attribute containing the VPWS identifier;
VPWS識別子を含む拡張コミュニティ属性O。
o an Extended Community Attribute containing one or more RTs.
一回の以上のRTを含む拡張コミュニティアトリビュートO。
See Section 6 for discussion of the AFI and SAFI values.
AFIとSAFI値の議論については、セクション6を参照してください。
The LDP-based signaling follows the procedures specified in [RFC4447]. That is, one PE (PE1) sends a Label Mapping message to another PE (PE2) to establish an LSP in one direction. The address of PE2 is the next-hop address learned via BGP as described above. If the message is processed successfully, and there is not yet an LSP for the pseudowire in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping message to PE1. Similarly, the L2TPv3-based signaling follows the procedures of [RFC4667]. Additional details on the use of these signaling protocols follow.
LDPベースのシグナリングは、[RFC4447]で指定された手順に従います。つまり、1つのPE（PE1）が一方向にLSPを確立する別のPE（PE2）にラベルマッピングメッセージを送信します。 PE2のアドレスは、上述したようにBGPを介して学習されたネクストホップアドレスです。メッセージが正常に処理され、その反対（PE1-> PE2）方向の疑似回線用LSPがまだ存在しない場合、PE2はPE1にLabel Mappingメッセージを送信します。同様に、L2TPv3のベースのシグナリングは、[RFC4667]の手順に従います。これらのシグナリングプロトコルの使用に関する追加の詳細は以下の通り。
When a PE sends a Label Mapping message or an ICRQ message to set up a PW between two pools, it encodes the VPWS identifier (as distributed in the Extended Community Attribute by BGP) as the AGI, the local pool's relative identifier as the SAII, and the remote pool's relative identifier as the TAII.
PEは、2つのプール間PWを設定するLabel MappingメッセージまたはICRQメッセージを送信するとき、それは、AGI、SAIIとしてローカルプールの相対的な識別子として（BGPによって拡張コミュニティ属性に分散されるように）VPWS識別子をコードTAIIとして、リモートプールの相対識別子。
The structure of the AGI and AII fields for the Generalized ID FEC in LDP is defined in [RFC4447]. The AGI field in this case consists of a Type of 1, a length field of value 8, and the 8 bytes of the VPWS identifier. The TAII consists of a Type of 1, a length field of value 4, followed by the 4-byte remote pool number. The SAII consists of a Type of 1, a length field of value 4, followed by the 4-byte local pool number. See Section 6 for discussion of the AGI and AII Type assignment. Note that the VPLS and VPWS procedures defined in this document can make use of the same AGI Type (1) and the same AII Type (1).
LDPに一般ID FECためAGIとAIIフィールドの構造は、[RFC4447]で定義されています。この場合AGIフィールドが1のタイプ、値8の長さフィールド、およびVPWS識別子の8バイトから成ります。 TAIIは、4バイトのリモートプール番号に続く1のタイプ、値4の長さフィールドから成ります。 SAIIは、4バイトのローカルプール番号に続く1のタイプ、値4の長さフィールドから成ります。 AGIとAIIタイプの割り当ての議論については、セクション6を参照してください。この文書で定義されたVPLSとVPWS手順は同じAGI型（1）と同じAIIタイプ（1）を利用できることに留意されたいです。
The encoding of the AGI and AII in L2TP is specified in [RFC4667].
L2TPにおけるAGIとAIIの符号化は[RFC4667]で指定されています。
When PE2 receives a Label Mapping message or an ICRQ message from PE1, and the TAI identifies a pool, and there is already a pseudowire connecting an Attachment Circuit in that pool to an Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is the same as the SAI of the Label Mapping or ICRQ message, then PE2 sends a Label Release or CDN message to PE1, with a Status Code meaning "Attachment Circuit already bound to remote Attachment Circuit". This prevents the creation of multiple pseudowires between a given pair of pools.
PE2は、Label MappingメッセージまたはPE1からICRQメッセージを受信し、TAI、プールを識別し、PE1における接続回線にそのプールに接続回線を接続する疑似回線が既に存在し、その疑似回線のPE1におけるAIである場合ラベルマッピングやICRQメッセージのSAIと同じ、その後、PE2は、ステータスコードは、「すでにリモート接続回線にバインドされた接続回線」を意味し、PE1にラベルリリースやCDNメッセージを送信します。これは、プールの所定の対の間の複数の疑似回線の作成を防止します。
Note that the signaling itself only identifies the remote pool to which the pseudowire is to lead, not the remote Attachment Circuit that is to be bound to the pseudowire. However, the remote PE may examine the SAII field to determine which Attachment Circuit should be bound to the pseudowire.
シグナリング自体のみ疑似回線は、疑似回線に結合されるべきではないリモート接続回線をリードしているためにリモートプールを識別することに留意されたいです。しかし、リモートPEは、疑似回線に結合されるべき接続回線を決定するためにSAIIフィールドを検査することができます。
The procedures for creating a partial mesh of pseudowires among a set of colored pools are substantially the same as those for creating a full mesh, with the following exceptions:
着色されたプールのセットの中疑似回線の部分のメッシュを作成するための手順は、以下の例外を除いて、完全なメッシュを作成するためのものと実質的に同じです。
o Each pool is optionally configured with a set of "import RTs" and "export RTs";
Oの各プールは、必要に応じて、「インポートのRT」及び「輸出のRT」の組で構成されています。
o During BGP-based auto-discovery, the pool color is still encoded in the RD, but if the pool is configured with a set of "export RTs", these are encoded in the RTs of the BGP Update messages INSTEAD of the color;
O BGPベースの自動検出時には、プールの色はまだRDでエンコードされていますが、プールは「輸出のRT」のセットで構成されている場合は、これらのではなく、色のBGP更新メッセージののRTでエンコードされています。
o If a pool has a particular "import RT" value X, it will create a PW to every other pool that has X as one of its "export RTs". The signaling messages and procedures themselves are as in Section 3.3.3.
プールは、特定の「輸入RT」の値Xを持っている場合は、O、それはその「輸出のRT」の一つとして、Xを持っている他のすべてのプールにPWを作成します。シグナリングメッセージと手順自体は、セクション3.3.3のようにしています。
As a simple example, consider the task of building a hub-and-spoke topology with a single hub. One pool, the "hub" pool, is configured with an export RT of RT_hub and an import RT of RT_spoke. All other pools (the spokes) are configured with an export RT of RT_spoke and an import RT of RT_hub. Thus, the hub pool will connect to the spokes, and vice-versa, but the spoke pools will not connect to each other.
簡単な例として、単一のハブとハブアンドスポークトポロジを構築する作業を考えます。 1つのプール、「ハブ」のプールは、RT_hubの輸出RTとRT_spokeの輸入RTで設定されています。他のすべてのプール（スポーク）がRT_spokeの輸出RTとRT_hubの輸入RTで設定されています。このように、ハブ・プールは、スポークに接続する、またはその逆が、スポークプールはお互いに接続しません。
In Distributed VPLS ([RFC4664]), the VPLS functionality of a PE router is divided among two systems: a U-PE and an N-PE. The U-PE sits between the user and the N-PE. VSI functionality (e.g., MAC address learning and bridging) is performed on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS supported by a U-PE, the U-PE maintains a pseudowire to each of the other U-PEs in the same VPLS. However, the U-PEs do not maintain signaling control connections with each other. Rather, each U-PE has only a single signaling connection, to its N-PE. In essence, each U-PE-to-U-PE pseudowire is composed of three pseudowires spliced together: one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to U-PE. In the terminology of [RFC5659], the N-PEs perform the pseudowire switching function to establish multi-segment PWs from U-PE to U-PE.
U-PE及びN-PE：分散VPLS（[RFC4664]）で、PEルータのVPLS機能は、二つのシステム間で分割されます。 U-PEは、ユーザ及びN-PEの間に位置します。 VSI機能（例えば、MACアドレス学習およびブリッジ）U-PE上で実行されます。 U-PEの数は、N-PEに取り付けます。 U-PEによってサポートされる各VPLSのために、U-PEは、同じVPLSの他のU-PEのそれぞれに擬似回線を維持します。しかし、U-PEは互いに制御接続をシグナリングを維持していません。むしろ、各U-PEは、N-PEに単一のシグナリング接続を有します。 UのN-PE、N-PEのN-PEから1、及びN-PEからの1つのU-PEから1：本質的には、各U-PE対U-PE疑似回線を一緒にスプライス3つの疑似回線で構成されています-PE。 [RFC5659]の用語では、N-PEはU-PEへのU-PEからマルチセグメントのPWを確立するための疑似回線交換機能を実行します。
Consider, for example, the following topology:
例えば、次のトポロジを考えてみます。
U-PE A-----| |----U-PE C
| |
| |
N-PE E--------N-PE F
| |
| |
U-PE B-----| |-----U-PE D
where the four U-PEs are in a common VPLS. We now illustrate how PWs get spliced together in the above topology in order to establish the necessary PWs from U-PE A to the other U-PEs.
4 U-PEは、共通のVPLSのどこにいますか。私たちは今、PWのは、他のU-PEにU-PE Aから必要なPWをを確立するために、上記のトポロジで一緒にスプライス取得方法を示しています。
There are three PWs from A to E. Call these A-E/1, A-E/2, and A-E/3. In order to connect A properly to the other U-PEs, there must be two PWs from E to F (call these E-F/1 and E-F/2), one PW from E to B (E-B/1), one from F to C (F-C/1), and one from F to D (F-D/1).
E.にA-E / 2、およびA-E / 3、これらのA-E / 1の呼び出しから3つのPWSがあります。他のU-PEに適切に接続するために、EからFへの2つのPW（これらEF / 1及びEF / 2を呼び出す）、EからBへの1つPW（EB / 1）、Fからの1つに存在しなければなりませんC（FC / 1）、及びFからD（FD / 1）に1。
The N-PEs must then splice these pseudowires together to get the equivalent of what the non-distributed VPLS signaling mechanism would provide:
N-PEは、非分散型VPLSシグナリングメカニズムを提供するものの同等のものを得るために一緒にこれらの疑似回線をスプライスする必要があります。
o PW from A to B: A-E/1 gets spliced to E-B/1.
OからBへのPWは：-E / 1は、E-B / 1にスプライスされます。
o PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F-C/1.
CへのO PW：-E / 2は、E-F / 1はF-C / 1にスプライスされますにスプライスされます。
o PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F-D/1.
O PWからDに：-E / 3は、E-F / 2にスプライスされますがF-D / 1にスプライスされます。
It doesn't matter which PWs get spliced together, as long as the result is one from A to each of B, C, and D.
PWSは限り結果はB、C、およびDのそれぞれに1からであるように、一緒にスプライス取得している問題ではありません。
Similarly, there are additional PWs that must get spliced together to properly interconnect U-PE B with U-PEs C and D, and to interconnect U-PE C with U-PE D.
同様に、そこに適切U-PES C及びDとU-PE Bを相互接続するために一緒にスプライス取得する必要があり、追加のPWであり、そしてU-PE D.でU-PE Cを相互接続します
The following figure illustrates the PWs from A to C and from B to D. For clarity of the figure, the other four PWs are not shown.
次の図は、図を明瞭にするためにC及びBからDにからのPWを示し、他の4つのPWは示されていません。
splicing points
| |
V V
A-C PW <-----><-----------><------>
U-PE A-----| |----U-PE C
| |
| |
N-PE E--------N-PE F
| |
| |
U-PE B-----| |-----U-PE D
B-D PW <-----><-----------><------>
^ ^
| |
splicing points
One can see that distributed VPLS does not reduce the number of pseudowires per U-PE, but it does reduce the number of control connections per U-PE. Whether this is worthwhile depends, of course, on what the bottleneck is.
一つは、VPLSがU-PE当たりの疑似回線の数を減少させないが、それはU-PE当たりの制御接続の数を削減し、分散ことがわかります。これは価値があるかどうかは、ボトルネックが何であるかに、当然のことながら、依存しています。
The signaling to support Distributed VPLS can be done with the mechanisms described in this document. However, the procedures for VPLS (Section 3.2.3) need some additional machinery to ensure that the appropriate number of PWs are established between the various N-PEs and U-PEs, and among the N-PEs.
分散VPLSをサポートするためのシグナリングは、この文書で説明されたメカニズムを用いて行うことができます。しかし、VPLS（セクション3.2.3）のための手順は、のPWの適切な数は、種々のN-PEとU-PE間、及びN-PEの間で確立されることを確実にするためにいくつかの追加の機構を必要とします。
At a given N-PE, the directly attached U-PEs in a given VPLS can be numbered from 1 to n. This number identifies the U-PE relative to a particular VPN-id and a particular N-PE. (That is, to uniquely identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be known.)
与えられたN-PEで、所定のVPLSに直接結合U-PEは1からnまで番号付けすることができます。この数は、特定のVPN-IDと特定のN-PEのU-PEの相対を識別する。 （即ち、一義的にU-PE、N-PE、VPN-IDを識別するために、であり、U-PEの数は知られていなければなりません。）
As a result of configuration/discovery, each U-PE must be given a list of <j, IP address> pairs. Each element in this list tells the U-PE to set up j PWs to the specified IP address. When the U-PE signals to the N-PE, it sets the AGI to the proper-VPN-id, and sets the SAII to the PW number, and sets the TAII to null.
構成/発見の結果として、各U-PEは<J、IPアドレス>ペアのリストを与えられなければなりません。このリストの各要素には、指定したIPアドレスにj個のPWをセットアップするためにU-PEに指示します。 N-PEのU-PE信号は、それが適切-VPN-IDにAGIを設定し、PW番号にSAIIを設定し、nullにTAIIを設定した場合。
In the above example, U-PE A would be told <3, E>, telling it to set up 3 PWs to E. When signaling, A would set the AGI to the proper VPN-id, and would set the SAII to 1, 2, or 3, depending on which of the three PWs it is signaling.
上記の例では、U-PE Aは、Aが、適切なVPN-IDにAGIを設定することになるシグナリング場合E.へ3つのPWを設定するためにそれを伝える、<3、E>と言われるであろうと1 SAIIを設定しますそれは、シグナリングされた3つのPWのかに応じて、2、又は3、。
As a result of configuration/discovery, each N-PE must be given the following information for each VPLS:
構成/発見の結果として、各N-PEは、各VPLSのために以下の情報を与えられなければなりません。
o A "Local" list: {<j, IP address>}, where each element tells it to set up j PWs to the locally attached U-PE at the specified address. The number of elements in this list will be n, the number of locally attached U-PEs in this VPLS. In the above example, E would be given the local list: {<3, A>, <3, B>}, telling it to set up 3 PWs to A and 3 to B.
{<J、IPアドレス>}、各要素が指定されたアドレスにローカルに接続されたU-PEにj個のPWを設定するように指示する「ローカル」リストO。このリスト内の要素の数をnとなり、この中にローカルに接続U-PEの数は、VPLS。上記の例では、Eは、ローカルリストを与えられるであろう：{<3、A>、<3、B>}、Bに3 AへのPWおよび3を設定するように指示します
o A local numbering, relative to the particular VPLS and the particular N-PE, of its U-PEs. In the above example, E could be told that U-PE A is 1, and U-PE B is 2.
そのU-PEの特定のVPLS、特にN-PEに対してローカルナンバリング、O。上記の例では、Eは、U-PE Aが1であり、そしてU-PE Bが2であると言われる可能性があります。
o A "Remote" list: {<IP address, k>}, telling it to set up k PWs, for each U-PE, to the specified IP address. Each of these IP addresses identifies an N-PE, and k specifies the number of U-PEs at the N-PE that are in the VPLS. In the above example, E would be given the remote list: {<2, F>}. Since N-PE E has 2 U-PEs, this tells it to set up 4 PWs to N-PE F, 2 for each of its E's U-PEs.
"リモート" リストO：{<IPアドレス、K>}、指定されたIPアドレスに、各U-PEのために、k個のPWを設定することを伝えます。これらのIPアドレスの各々は、N-PEを識別し、kはVPLSにあるN-PEでのU-PEの数を指定します。 {<2、F>}上記の例では、Eは、リモート・リストが与えられます。 N-PE E 2 U-PESを有しているため、これは、EのU-PEのそれぞれについて、N-PE F、2~4のPWを設定するように指示します。
The signaling of a PW from N-PE to U-PE is based on the local list and the local numbering of U-PEs. When signaling a particular PW from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII is set to null, and the TAII is set to the PW number (relative to that particular VPLS and U-PE). In the above example, when E signals to A, it would set the TAII to be 1, 2, or 3, respectively, for the 3 PWs it must set up to A. It would similarly signal 3 PWs to B.
N-PEからのU-PEへPWのシグナリングがローカルリストとU-PEのローカルナンバリングに基づいています。 U-PEへのN-PEから特定のPWシグナリング場合、AGIは、適切なVPN-IDに設定され、その特定のVPLSに対して（SAIIはヌルに設定され、TAIIがPW番号に設定されているとU-PE）。上記の例では、ときにE信号Aに、それは、それぞれ、1、2、または3であることがTAIIを設定するであろう、それはAに設定する必要があります3つのPWことが同様にBに3つのPWを知らせることになります
The LSP signaled from U-PE to N-PE is associated with an LSP from N-PE to U-PE in the usual manner. A PW between a U-PE and an N-PE is known as a "U-PW".
LSPは、N-PEにU-PEからシグナリング通常の方法でU-PEへのN-PEからのLSPに関連しています。 U-PE及びN-PEの間のPWは、 "U-PW" として知られています。
The signaling of the appropriate set of PWs from N-PE to N-PE is based on the remote list. The PWs between the N-PEs can all be considered equivalent. As long as the correct total number of PWs are established, the N-PEs can splice these PWs to appropriate U-PWs. The signaling of the correct number of PWs from N-PE to N-PE is based on the remote list. The remote list specifies the number of PWs to set up, per local U-PE, to a particular remote N-PE.
N-PEのN-PEからのPWの適切な組のシグナリングは、リモートリストに基づいています。 N-PE間のPWはすべて同等とみなすことができます。限りのPWの正しい総数が確立されるように、N-PEはU-のPWを適切なために、これらのPWをスプライスすることができます。 N-PEからN-PEへのPWの正しい数のシグナリングは、リモートリストに基づいています。リモート・リストは、特定のリモートN-PEに、ローカルU-PEごとに、設定するためのPWの数を指定します。
When signaling a particular PW from an N-PE to an N-PE, the AGI is set to the appropriate VPN-id. The TAII identifies the remote N-PE, as in the non-distributed case, i.e., it contains an IP address of the remote N-PE. If there are n such PWs, they are distinguished by the setting of the SAII. In order to allow multiple different SAII values in a single VPLS, the sending N-PE needs to have as many VSI-IDs as it has U-PEs. As noted above in Section 3.2.2, this may be achieved by using an IP address of each attached U-PE, for example. A PW between two N-PEs is known as an "N-PW".
N-PEのN-PEから特定のPWシグナリング場合、AGIは、適切なVPN-IDに設定されています。 TAIIは非分散場合のように、遠隔N-PEを特定する、すなわち、それはリモートN-PEのIPアドレスを含みます。このようPWをn個ある場合、それらはSAIIの設定によって区別されます。単一のVPLS内の複数の異なるSAII値を可能にするために、送信N-PEは、それがU-PESを有するものとして多くのVSI-IDを有する必要があります。 3.2.2項で上述したように、これは、例えば、各添付のU-PEのIPアドレスを使用することによって達成することができます。 2つのN-PE間のPWは、「N-PW」として知られています。
Each U-PW must be "spliced" to an N-PW. This is based on the remote list. If the remote list contains an element <i, F>, then i U-PWs from each local U-PE must be spliced to i N-PWs from the remote N-PE F. It does not matter which U-PWs are spliced to which N-PWs, as long as this constraint is met.
各U-PWはN-PWに "スプライスさ" する必要があります。これは、リモート・リストに基づいています。リモートリスト要素<I、F>を含む場合、各ローカルU-PEからiは、U-のPWは、U-のPWがスプライシングされている問題ではないリモートN-PE FからI N-のPWにスプライスされなければなりませんこれにN-PWSが、限り、この制約が満たされているとして。
If an N-PE has more than one local U-PE for a given VPLS, it must also ensure that a U-PW from each such U-PE is spliced to a U-PW from each of the other U-PEs.
N-PEは、所与のVPLSのために複数のローカルU-PEを有する場合、それはまた、そのような各U-PEからU-PWは、他のU-PEのそれぞれからU-PWに接合されていることを確認しなければなりません。
Every N-PE must be provisioned with the set of VPLS instances it supports, a VPN-id for each one, and a list of local U-PEs for each such VPLS. As part of the discovery procedure, the N-PE advertises the number of U-PEs for each VPLS. See Section 3.2.2 for details.
すべてのN-PEは、それがサポートしているVPLSインスタンスのセット、それぞれのためのVPN-ID、およびこのような各VPLSのローカルU-PEのリストをプロビジョニングしなければなりません。発見手順の一部として、N-PEは、各VPLSのためにU-PEの数をアドバタイズ。詳細については、3.2.2項を参照してください。
Auto-discovery (e.g., BGP-based) can be used to discover all the other N-PEs in the VPLS, and for each, the number of U-PEs local to that N-PE. From this, one can compute the total number of U-PEs in the VPLS. This information is sufficient to enable one to compute the local list and the remote list for each N-PE.
自動検出は、（例えば、BGPベース）VPLS内の他のすべてのN-PESを発見するために使用することができ、かつそのN-PEのそれぞれについて、U-PEの数は、ローカル。このことから、一方がVPLSにU-PEの総数を計算することができます。この情報は、ローカルリストと各N-PEのためのリモートリストを計算することを可能にするのに十分です。
A PE that is providing "non-distributed VPLS" (i.e., a PE that performs both the U-PE and N-PE functions) can interoperate with N-PE/U-PE pairs that are providing distributed VPLS. The "non-distributed PE" simply advertises, in the discovery procedure, that it has one local U-PE per VPLS. And of course, the non-distributed PE does no PW switching.
「非分散VPLS」を提供しているPE（すなわち、U-PE及びN-PEの両方の機能を実行するPE）分散VPLSを提供しているN-PE / U-PEのペアと相互運用することができます。 「非分散PE」は、単にそれがVPLSごとに一つのローカルU-PEを有していることが、発見手順において、アドバタイズ。そしてもちろん、非分散型PEにはPWスイッチングを行いません。
If every PE in a VPLS is providing non-distributed VPLS, and thus every PE is advertising itself as an N-PE with one local U-PE, the resultant signaling is exactly the same as that specified in Section 3.2.3 above.
VPLS内のすべてのPEは、非分散VPLSを提供しているので、すべてのPEは、一つのローカルU-PEとN-PEとして自身をアドバタイズしている場合、得られたシグナルは、正確に上記のセクション3.2.3で指定されたものと同じです。
Splicing two PWs together is quite straightforward in the MPLS data plane, as moving a packet from one PW directly to another is just a 'label replace' operation on the PW label. When a PW consists of two or more PWs spliced together, it is assumed that the data will go to the node where the splicing is being done, i.e., that the data path will pass through the nodes that participate in PW signaling.
PWラベルに単に「ラベル置き換える」操作がある他に、直接1 PWからのパケットを移動するようスプライシング2つのPWSが一緒に、MPLSデータプレーンで非常に簡単です。 PWは、一緒にスプライス二つ以上のPWで構成されている場合、そのデータは、データパスがPWシグナリングに参加するノードを通過することは、スプライシングが行われているノード、すなわちに行くであろうと仮定されます。
Further details on splicing are discussed in [RFC6073].
スプライシングに関するさらなる詳細は、[RFC6073]に記載されています。
The provisioning, auto-discovery, and signaling mechanisms described above can all be applied in an inter-AS environment. As in [RFC4364], there are a number of options for inter-AS operation.
上述したプロビジョニング、自動検出、およびシグナル伝達機構は、すべてのAS間の環境で適用することができます。 [RFC4364]のように、AS間の動作のための多くのオプションがあります。
This option is most like option (c) in [RFC4364]. That is, we use multihop External BGP (EBGP) redistribution of L2VPN NLRIs between source and destination ASes, with EBGP redistribution of labeled IPv4 or IPv6 routes from AS to neighboring AS.
このオプションは、[RFC4364]の中で最もなどのオプション（C）です。すなわち、我々は、隣接するASにASから標識されたIPv4またはIPv6ルートのEBGP再分配して、ソースと宛先AS間L2VPNたNLRIのマルチホップ外部BGP（EBGP）再配布を使用、です。
An Autonomous System Border Router (ASBR) must maintain labeled IPv4 /32 (or IPv6 /128) routes to the PE routers within its AS. It uses EBGP to distribute these routes to other ASes, and sets itself as the BGP next hop for these routes. ASBRs in any transit ASes will also have to use EBGP to pass along the labeled /32 (or /128) routes. This results in the creation of a set of label switched paths from all ingress PE routers to all egress PE routers. Now, PE routers in different ASes can establish multi-hop EBGP connections to each other and can exchange L2VPN NLRIs over those connections. Following such exchanges, a pair of PEs in different ASes could establish an LDP session to signal PWs between each other.
自律システム境界ルータ（ASBR）は、AS内のPEルータへの経路標識のIPv4 / 32（またはIPv6 / 128）を維持しなければなりません。これは、他のASにこれらのルートを配布するEBGPを使用し、これらのルートのBGPネクストホップとしての地位を設定します。任意の中継のAS内のASBRはまた、標識/ 32（または/ 128）の経路に沿って通過するEBGPを使用する必要があります。ラベルのセットの作成におけるこの結果は、全ての出力PEルータにすべての入力PEルータからの経路を切り替えます。今、別のAS内のPEルータは、互いにマルチホップEBGP接続を確立することができ、これらの接続を介してL2VPNたNLRIを交換することができます。そのような交換に続いて、異なるのAS内のPEの対は、互いの間のPWをシグナリングするLDPセッションを確立することができます。
For VPLS, the BGP advertisement and PW signaling are exactly as described in Section 3.2. As a result of the multihop EBGP session that exists between source and destination AS, the PEs in one AS that have VSIs of a certain VPLS will discover the PEs in another AS that have VSIs of the same VPLS. These PEs will then be able to establish the appropriate PW signaling protocol session and establish the full mesh of VSI-VSI pseudowires to build the VPLS as described in Section 3.2.3.
3.2節で説明したようにVPLSのために、BGP広告とPWシグナリングが正確です。送信元と宛先のASの間に存在するマルチホップEBGPセッションの結果として、特定のVPLSでのVSIを有する1つのAS内のPEは、同じVPLSでのVSIを有する別のAS内のPEを発見するでしょう。 3.2.3項で説明したように、これらのPEは、VPLSを構築するためのVSI-VSIの疑似回線のフルメッシュを適切なPWシグナリングプロトコルセッションを確立し、確立することができるようになります。
For VPWS, the BGP advertisement and PW signaling are exactly as described in Section 3.3. As a result of the multihop EBGP session that exists between source and destination AS, the PEs in one AS that have pools of a certain color (VPN) will discover PEs in another AS that have pools of the same color. These PEs will then be able to establish the appropriate PW signaling protocol session and establish the full mesh of pseudowires as described in Section 3.2.3. A partial mesh can similarly be established using the procedures of Section 3.4.
セクション3.3で説明したようにVPWSため、BGP広告及びPWシグナリングが正確です。送信元と宛先のASの間に存在するマルチホップEBGPセッションの結果として、特定の色（VPN）のプールを有する1つのAS内のPEは、同じ色のプールを持っている別のAS内のPEを発見するでしょう。これらのPEは、適切なPWシグナリングプロトコルセッションを確立し、セクション3.2.3に記載したように疑似回線のフルメッシュを確立することができるであろう。部分的なメッシュは、同様に、セクション3.4の手順を使用して確立することができます。
As in Layer 3 VPNs, building an L2VPN that spans the networks of more than one provider requires some co-ordination in the use of RTs and RDs. This subject is discussed in more detail in Section 4.4.
レイヤ3つのVPNのように、複数のプロバイダのネットワークにまたがるL2VPNを構築するのRTとRDSの使用におけるいくつかの協調が必要です。この主題は、4.4節で詳しく説明されています。
A possible drawback of the approach of the previous section is that it creates PW signaling sessions among all the PEs of a given L2VPN (VPLS or VPWS). This means a potentially large number of LDP or L2TPv3 sessions will cross the AS boundary and that these sessions connect to many devices within an AS. In the case where the ASes belong to different providers, one might imagine that providers would like to have fewer signaling sessions crossing the AS boundary and that the entities that terminate the sessions could be restricted to a smaller set of devices. Furthermore, by forcing the LDP or L2TPv3 signaling sessions to terminate on a small set of ASBRs, a provider could use standard authentication procedures on a small set of inter-provider sessions. These concerns motivate the approach described here.
前のセクションのアプローチの可能な欠点は、それが所定のL2VPN（VPLS又はVPWS）のすべてのPE間PWシグナリングセッションを作成することです。これは、LDPまたはL2TPv3のセッションの潜在的に大きな数はAS境界を越えると、これらのセッションは、AS内の多くのデバイスに接続することを意味します。 ASが異なるプロバイダに属している場合には、一つはプロバイダは、より少ないシグナリングセッションがAS境界を横断してセッションを終了するエンティティは、デバイスの小さなセットに制限することができることがしたいことを想像するかもしれません。さらに、のASBRの小さなセットで終端するLDPまたはL2TPv3のシグナリングセッションを強制することにより、プロバイダは、プロバイダ間のセッションの小さなセットに標準的な認証手順を使用することができます。これらの懸念は、ここで説明したアプローチのやる気を引き出します。
[RFC6073] describes an approach to "switching" packets from one pseudowire to another at a particular node. This approach allows an end-to-end, multi-segment pseudowire to be constructed out of several pseudowire segments, without maintaining an end-to-end control connection. We can use this approach to produce an inter-AS solution that more closely resembles option (b) in [RFC4364].
[RFC6073]は、特定のノードに別の疑似回線からのパケットを「スイッチング」するアプローチを記載しています。このアプローチは、エンドツーエンド制御接続を維持することなく、いくつかの疑似回線セグメントから構成されるエンドツーエンド、マルチセグメント疑似回線を可能にします。私たちは、より密接に、[RFC4364]でオプション（B）に似ている間AS溶液を製造するために、このアプローチを使用することができます。
In this model, we use EBGP redistribution of L2VPN NLRI from AS to neighboring AS. First, the PE routers use Internal BGP (IBGP) to redistribute L2VPN NLRI either to an ASBR, or to a route reflector of which an ASBR is a client. The ASBR then uses EBGP to redistribute those L2VPN NLRI to an ASBR in another AS, which in turn distributes them to the PE routers in that AS, or perhaps to another ASBR which in turn distributes them, and so on.
このモデルでは、我々は、AS近隣にASからL2VPN NLRIのEBGP再分配を使用しています。まず、PEルータは、内部BGP（IBGP）のいずれかASBRに、またはASBRがクライアントとなっているルートリフレクタにL2VPN NLRIを再配布するために使用します。 ASBRは、その後順番にようにそのAS内のPEルータへの、又はおそらく順番にそれらを分配する別のASBRに配布し、別のAS内のASBRにそれらのL2VPN NLRIを再配布するEBGPを使用します。
In this case, a PE can learn the address of an ASBR through which it could reach another PE to which it wishes to establish a PW. That is, a local PE will receive a BGP advertisement containing L2VPN NLRI corresponding to an L2VPN instance in which the local PE has some attached members. The BGP next-hop for that L2VPN NLRI will be an ASBR of the local AS. Then, rather than building a control connection all the way to the remote PE, it builds one only to the ASBR. A pseudowire segment can now be established from the PE to the ASBR. The ASBR in turn can establish a PW to the ASBR of the next AS, and splice that PW to the PW from the PE as described in Section 3.5.4 and [RFC6073]. Repeating the process at each ASBR leads to a sequence of PW segments that, when spliced together, connect the two PEs.
この場合、PEは、それはそれはPWを確立することを希望する他のPEに達する可能性がそこを通ってASBRのアドレスを学ぶことができます。すなわち、ローカルPEは、ローカルPEは、いくつかの取り付け部材を有する、L2VPNインスタンスに対応するL2VPN NLRIを含むBGP広告を受信します。そのL2VPN NLRIのためのBGPネクストホップは、ローカルASのASBRになります。次いで、むしろすべての方法のリモートPEへの制御接続を構築するよりも、それだけASBRに1を構築します。疑似回線セグメントは今ASBRにPEから確立することができます。次にASBRは次ASのASBRにPWを確立し、セクション3.5.4と[RFC6073]で説明されるようにPEからPWにPWことをスプライスすることができます。各ASBRの処理を繰り返すことにより、一緒にスプライス場合、2個のPEを接続し、PWセグメントのシーケンスをもたらします。
Note that in the approach just described, the local PE may never learn the IP address of the remote PE. It learns the L2VPN NLRI advertised by the remote PE, which need not contain the remote PE address, and it learns the IP address of the ASBR that is the BGP next hop for that NLRI.
今説明したアプローチでは、ローカルPEは、リモートPEのIPアドレスを知ることはありません可能性があります。これは、リモートPEアドレスを含む必要はないリモートPEによってアドバタイズL2VPN NLRIを、学習し、そのNLRIのためのBGPネクストホップであるASBRのIPアドレスを学習します。
When this approach is used for VPLS, or for full-mesh VPWS, it leads to a full mesh of pseudowires among the PEs, just as in the previous section, but it does not require a full mesh of control connections (LDP or L2TPv3 sessions). Instead, the control connections within a single AS run among all the PEs of that AS and the ASBRs of the AS. A single control connection between the ASBRs of adjacent ASes can be used to support however many AS-to-AS pseudowire segments are needed.
このアプローチは、VPLSのために、またはフルメッシュVPWS、それだけで前のセクションのように、PEの間の疑似回線のフルメッシュにつながり、それが制御接続のフルメッシュを必要としない（LDPまたはL2TPv3のセッションで使用されている場合）。代わりに、単一内の制御接続はすべてそのASのPEとASのASBRは間に実行AS。隣接のASのASBR間の単一の制御接続は、疑似回線セグメントが必要とされるような対しかし多くをサポートするために使用することができます。
Note that the procedures described here will result in the splicing points (PW Switching PEs (S-PEs) in the terminology of [RFC5659]) being co-located with the ASBRs. It is of course possible to have multiple ASBR-ASBR connections between a given pair of ASes. In this case, a given PE could choose among the available ASBRs based on a range of criteria, such as IGP metric, local configuration, etc., analogous to choosing an exit point in normal IP routing. The use of multiple ASBRs would lead to greater resiliency (at the timescale of BGP routing convergence) since a PE could select a new ASBR in the event of the failure of the one currently in use.
ここで説明する手順は、のASBRと同じ場所に配置される（[RFC5659]の用語でPWスイッチングPES（S-PES））スプライシングポイントをもたらすことに留意されたいです。のASの与えられたペア間の複数のASBR-ASBR接続を持つことはもちろん可能です。この場合、所与のPEは、通常のIPルーティングにおける出口点を選ぶと類似等IGPメトリック、ローカル設定、などの基準、の範囲に基づいて、利用可能なのASBR間で選ぶことができます。 PEは、現在使用中の1つが故障した場合に新たなASBRを選択することができるので、複数のASBRの使用は、（BGPルーティング収束の時間スケールで）より大きな弾力性をもたらします。
As in layer 3 VPNs, building an L2VPN that spans the networks of more than one provider requires some co-ordination in the use of RTs and RDs. This subject is discussed in more detail in Section 4.4.
レイヤ3つのVPNのように、複数のプロバイダのネットワークにまたがるL2VPNを構築するのRTとRDSの使用におけるいくつかの協調が必要です。この主題は、4.4節で詳しく説明されています。
An alternative approach to inter-provider VPLS can be derived from the Distributed VPLS approach described above. Consider the following topology:
インタープロバイダVPLSの別のアプローチは、上述の分散VPLSアプローチに由来することができます。次のトポロジを考えてみます。
PE A --- Network 1 ----- Border ----- Border ----- Network 2 --- PE B
Router 12 Router 21 |
|
PE C
where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are networks of different service providers. Border Router 12 is Network 1's border router to network 2, and Border Router 21 is Network 2's border router to Network 1. We suppose further that the PEs are not "distributed", i.e, that each provides both the U-PE and N-PE functions.
A、B、及びCは、共通のVPLS内のPEであるが、ネットワーク1及び2は、異なるサービスプロバイダのネットワークです。我々は、各々がU-PEおよびN-両方を提供すること、すなわち、のPEを「分散」されていないことをさらに仮定境界ルータ12は、ネットワーク2にネットワーク1の境界ルータであり、境界ルータ21は、ネットワーク1のネットワーク2の境界ルータでありますPE機能します。
In this topology, one needs two inter-provider pseudowires: A-B and A-C.
A-B及びA-C：このトポロジでは、一方が2つの相互プロバイダ疑似回線を必要とします。
Suppose a service provider decides, for whatever reason, that it does not want each of its PEs to have a control connection to any PEs in the other network. Rather, it wants the inter-provider control connections to run only between the two border routers.
サービスプロバイダは、そのPEのそれぞれは、他のネットワーク内の任意のPEへの制御接続を持っている必要はありませんので、何らかの理由で、決定したとします。むしろ、それは2台のだけ境界ルータ間で実行する間、プロバイダの制御接続を望んでいます。
This can be achieved using the techniques of Section 3.5, where the PEs behave like U-PEs, and the BRs behave like N-PEs. In the example topology, PE A would behave like a U-PE that is locally attached to BR12; PEs B and C would be have like U-PEs that are locally attached to BR21; and the two BRs would behave like N-PEs.
これは、PEがU-PEのように振る舞うセクション3.5の技術を用いて達成することができる、とのBRは、N-PEのように振る舞います。例トポロジでは、PE Aは、ローカルBR12に取り付けられているU-PEのように振舞うことになります。 PE B及びCは、ローカルBR21に取り付けられているU-PESのように持っているであろう。そして2つのBRは、N-PEのように振る舞うでしょう。
As a result, the PW from A to B would consist of three segments: A-BR12, BR12-BR21, and BR21-B. The border routers would have to splice the corresponding segments together.
A-BR12、BR12、BR21およびBR21-B：結果として、AからBへのPWは三つのセグメントから成ります。境界ルータは、一緒に対応するセグメントをスプライスする必要があります。
This requires the PEs within a VPLS to be numbered from 1-n (relative to that VPLS) within a given network.
これは、所与のネットワーク内（すなわちVPLSに対して）1-nから番号付けされるVPLS内のPEを必要とします。
We note that, in order for any of the inter-AS procedures described above to work correctly, the two ASes must use RTs and RDs consistently, just as in Layer 3 VPNs [RFC4364]. The structure of RTs and RDs is such that there is not a great risk of accidental collisions. The main challenge is that it is necessary for the operator of one AS to know what RT or RTs have been chosen in another AS for any VPN that has sites in both ASes. As in Layer 3 VPNs, there are many ways to make this work, but all require some co-operation among the providers. For example, provider A may tag all the NLRI for a given VPN with a single RT, say RT_A, and provider B can then configure the PEs that connect to sites of that VPN to import NLRI that contains that RT. Provider B can choose a different RT, RT_B, tag all NLRI for this VPN with that RT, and then provider A can import NLRI with that RT at the appropriate PEs. However, this does require both providers to communicate their choice of RTs for each VPN. Alternatively, both providers could agree to use a common RT for a given VPN. In any case, communication of RTs between the providers is essential. As in Layer 3 VPNs, providers may configure RT filtering to ensure that only coordinated RT values are allowed across the AS boundary.
私達はちょうど3つのVPN [RFC4364]レイヤーのように、正しく動作するために、上記のAS間の手順のいずれかにするために、2つのASが一貫のRTとRDSを使用しなければならない、ということに注意してください。 RTSとのRDの構造は、偶然の衝突の大きなリスクが存在しないようなものです。主な課題は、RTやRTSは、両方のASのサイトを持っているすべてのVPNの場合と同様に、他に選択されているかを知るためにASそれは1のオペレータのために必要であるということです。レイヤ3つのVPNのように、そこにこの作業を行うには多くの方法がありますが、すべてはプロバイダの間でいくつかの協力が必要です。例えば、プロバイダAは、単一のRTで与えられたVPNのすべてのNLRIにタグを付けることがあり、RT_Aを言う、とプロバイダBは、その後、RTという含まれていNLRIをインポートするには、そのVPNのサイトに接続するPEを構成することができます。プロバイダBは、RTで、このVPNのためのすべてのNLRI異なるRT、RT_B、タグを選択することができ、その後、プロバイダAは適切なのPEでそのRTでNLRIをインポートすることができます。しかし、これは、各VPNのためのRTSの彼らの選択を伝えるために両方のプロバイダが必要です。また、両方のプロバイダは、指定されたVPNのための共通のRTを使用することに同意できます。いずれの場合も、プロバイダ間のRTのコミュニケーションが不可欠です。レイヤ3つのVPNのように、プロバイダは、唯一のコーディネートRT値は、AS境界を越えて許可されていることを確認するためにRTフィルタリングを設定することができます。
Note that a single VPN identifier (carried in a BGP Extended Community) is required for each VPLS or VPWS instance. The encoding rules for these identifiers [RFC4360] ensure that collisions do not occur with other providers. However, for a single VPLS or VPWS instance that spans the networks of two or more providers, one provider will need to allocate the identifier and communicate this choice to the other provider(s), who must use the same value for sites in the same VPLS or VPWS instance.
（BGP拡張コミュニティ内で運ば）単一VPN識別子が各VPLS又はVPWSインスタンスのために必要とされることに留意されたいです。これらの識別子[RFC4360]のための符号化規則は、衝突が他のプロバイダで発生していないことを確認してください。しかし、2つ以上のプロバイダのネットワークにまたがる単一VPLSやVPWSインスタンスのために、1つのプロバイダは、識別子を割り当て、同じ内のサイトに同じ値を使用する必要があり、他のプロバイダ（s）は、この選択を通信する必要があります。 VPLSやVPWSインスタンス。
This document describes a number of different L2VPN provisioning models, and specifies the endpoint identifiers that are required to support each of the provisioning models. It also specifies how those endpoint identifiers are mapped into fields of auto-discovery protocols and signaling protocols.
この文書では、さまざまなL2VPNプロビジョニングモデルの数を記述し、プロビジョニングモデルのそれぞれをサポートするために必要なエンドポイントIDを指定します。また、これらのエンドポイント識別子が自動検出プロトコルおよびシグナリングプロトコルのフィールドにマッピングされている方法を指定します。
The security considerations related to the signaling protocols are discussed in the relevant protocol specifications ([RFC5036], [RFC4447], [RFC3931], and [RFC4667]).
シグナリングプロトコルに関連するセキュリティ問題は、（[RFC5036]、[RFC4447]、[RFC3931]及び[RFC4667]）関連するプロトコル仕様に記載されています。
The security considerations related to BGP-based auto-discovery, including inter-AS issues, are discussed in [RFC4364]. L2VPNs that use BGP-based auto-discovery may automate setup of security mechanisms as well. Specification of automated security mechanisms are outside the scope of this document, but are recommended as a future work item.
AS間の問題など、BGPベースの自動検出に関連するセキュリティ上の考慮事項は、[RFC4364]で議論されています。 BGPベースの自動検出を使用するのL2VPNは、同様のセキュリティメカニズムのセットアップを自動化することができます。自動化されたセキュリティ・メカニズムの仕様は、このドキュメントの範囲外ですが、今後の作業項目として推奨されています。
The security considerations related to the particular kind of L2VPN service being supported are discussed in [RFC4664], [RFC4665], and [RFC4762].
L2VPNサービスの特定の種類がサポートされることに関連するセキュリティ問題は[RFC4664]、[RFC4665]及び[RFC4762]に記載されています。
The way in which endpoint identifiers are mapped into protocol fields does not create any additional security issues.
エンドポイント識別子は、プロトコルフィールドにマッピングされる方法は、任意の追加のセキュリティ上の問題を作成しません。
IANA has assigned an AFI and a SAFI for L2VPN NLRI. Both the AFI and SAFI are the same as the values assigned for [RFC4761]. That is, the AFI is 25 (L2VPN) and the SAFI is 65 (already allocated for VPLS). The same AFI and SAFI are used for both VPLS and VPWS auto-discovery as described in this document.
IANAは、AFIとL2VPN NLRIのためのSAFIが割り当てられています。 AFIとSAFIの両方が[RFC4761]に割り当てられた値と同じです。すなわち、AFI 25（L2VPN）とSAFIは、（既にVPLSのために割り当てられた）65です。本書で説明したのと同じAFIとSAFIはVPLSとVPWSの自動検出の両方に使用されています。
[RFC4446] defines registries for "Attachment Group Identifier (AGI) Type" and "Attachment Individual Identifier (AII) Type". Type 1 in each registry has been assigned to the AGI and AII formats defined in this document.
[RFC4446]は、「添付ファイルのグループ識別子（AGI）タイプ」と「添付個体識別子（AII）タイプ」のレジストリを定義します。各レジストリ内のタイプ1は、この文書で定義されたAGIとAIIフォーマットに割り当てられています。
IANA has assigned two new LDP status codes. IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by [RFC5036]. The following values have been assigned:
IANAは、2つの新しいLDPのステータスコードが割り当てられています。 IANAはすでに[RFC5036]で定義された「ステータスコードの名前空間」名のレジストリを維持します。以下の値が割り当てられています：
0x00000030 Attachment Circuit bound to different PE
別のPEに結合している0x00000030接続回線
0x0000002D Attachment Circuit bound to different remote Attachment Circuit
異なるリモート接続回線に結合された0x0000002Dアタッチメント回路
Two new L2TP Result Codes have been registered for the CDN message. IANA already maintains a registry of L2TP Result Code Values for the CDN message, defined by [RFC3438]. The following values have been assigned:
二つの新しいL2TPの結果コードは、CDNメッセージのために登録されています。 IANAはすでに[RFC3438]で定義されたCDNメッセージのためのL2TP結果コード値のレジストリを維持します。以下の値が割り当てられています：
27: Attachment Circuit bound to different PE
27：別のPEに結合している接続回線
28: Attachment Circuit bound to different remote Attachment Circuit
28：別のリモート接続回線にバインドされた接続回線
[RFC4360] defines a registry entitled "Two-octet AS Specific Extended Community". IANA has assigned a value in this registry from the "transitive" range (0x0000-0x00FF). The value is as follows:
[RFC4360]は「2オクテットAS固有の拡張コミュニティ」と題されたレジストリを定義します。 IANAは、「推移」範囲（0x0000-0x00FF）からこのレジストリに値を割り当てました。次のように値は次のとおりです。
o 0x000A Two-octet AS specific Layer 2 VPN Identifier
O 0x000A 2オクテットAS特定のレイヤ2 VPN識別子
[RFC4360] defines a registry entitled "IPv4 Address Specific Extended Community". IANA has assigned a value in this registry from the "transitive" range (0x0100-0x01FF). The value is as follows:
[RFC4360]は、「IPv4のアドレス特定拡張コミュニティ」と題されたレジストリを定義します。 IANAは、「推移」範囲（0x0100-0x01FF）からこのレジストリに値を割り当てました。次のように値は次のとおりです。
o 0x010A Layer 2 VPN Identifier
O 0x010Aレイヤ2 VPN識別子
Both BGP-AD and VPLS-BGP [RFC4761] use the same AFI/SAFI. In order for both BGP-AD and VPLS-BGP to co-exist, the NLRI length must be used as a demultiplexer.
BGP-ADおよびVPLS-BGP [RFC4761]の両方が同じAFI / SAFIを使用します。 BGP-ADと共存にVPLS-BGPの両方のために、NLRIの長さは、デマルチプレクサとして使用しなければなりません。
The BGP-AD NLRI has an NLRI length of 12 bytes, containing only an 8-byte RD and a 4-byte VSI-ID. VPLS-BGP [RFC4761] uses a 17-byte NLRI length. Therefore, implementations of BGP-AD must ignore NLRI that are greater than 12 bytes.
BGP-AD NLRIは、8バイトのRDと4バイトのVSI-IDを含む、12バイトのNLRIの長さを有します。 VPLS-BGP [RFC4761]は17バイトNLRI長を使用します。したがって、BGP-ADの実装では、12バイトより大きいことNLRIを無視しなければなりません。
Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca Martini, Dave McDysan, Francois Le Faucheur, Russ Gardo, Keyur Patel, Sam Henderson, and Matthew Bocci for their comments, criticisms, and helpful suggestions.
彼らのコメント、批判、および有用な提案のためのダンタッパン、テッド銭、アリSajassi、スキップブース、ルカ・マルティーニ、デイブMcDysan、フランソワ・ルFaucheur、ラスGardo、Keyurパテル、サム・ヘンダーソン、そしてマシューボッチに感謝します。
Thanks to Tissa Senevirathne, Hamid Ould-Brahim, and Yakov Rekhter for discussing the auto-discovery issues.
自動検出の問題を議論するためのティッサSenevirathne、ハミドウルド-Brahimの、およびヤコフ・レックターに感謝します。
Thanks to Vach Kompella for a continuing discussion of the proper semantics of the generalized identifiers.
一般識別子の適切な意味論の継続的な議論のためのVACH Kompellaに感謝します。
[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月。
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[RFC3438] Townsley、W.、 "レイヤ2トンネリングプロトコル（L2TP）IANA（Internet Assigned Numbers Authority）の考慮事項更新"、BCP 68、RFC 3438、2002年12月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]ラウ、J.、Townsley、M.、およびI. Goyret、 "レイヤ2トンネリングプロトコル - バージョン3（L2TPv3の）"、RFC 3931、2005年3月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[RFC4360]サングリ、S.、タッパン、D.、およびY. Rekhterは、RFC 4360、2006年2月の "BGP拡張コミュニティ属性"。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]、L.、ローゼン、E.、エル・Aawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して、擬似回線の設定とメンテナンス"、RFC 4447、2006年4月マティーニ。
[RFC4667] Luo, W., "Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)", RFC 4667, September 2006.
[RFC4667]羅、W.、 "レイヤレイヤ2トンネリングプロトコル（L2TP）のための2バーチャルプライベートネットワーク（L2VPN）拡張機能"、RFC 4667、2006年9月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T.、チャンドラ、R.、カッツ、D.、およびY. Rekhter、 "BGP-4のためのマルチプロトコル拡張機能"、RFC 4760、2007年1月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、Minei、I.、およびB.トーマス、 "LDP仕様"、RFC 5036、2007年10月。
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
[RFC6073]マルティーニ、L.、メス、C.、ナドー、T.、ボッチ、M.、およびM. Aissaoui、 "セグメント疑似回線"、RFC 6073、2011年1月。
[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月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーションに擬似回線縁（PWE3）のためのIANAの割り当て"。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]アンデション、L.およびE.ローゼン、 "レイヤのためのフレームワーク2個の仮想プライベートネットワーク（のL2VPN）"、RFC 4664、2006年9月。
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006.
[RFC4665]アウグスティン、W.およびY. Serbest、 "レイヤーのためのサービスの要件2プロバイダ・プロビジョニングされた仮想プライベートネットワーク"、RFC 4665、2006年9月。
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4761] Kompella、K.とY. Rekhter、 "自動検出およびシグナリングのためにBGPを使用した仮想プライベートLANサービス（VPLS）"、RFC 4761、2007年1月。
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[RFC4762] Lasserre、M.およびV. Kompella、 "仮想プライベートLANサービス（VPLS）ラベル配布プロトコル（LDP）シグナリングの使用"、RFC 4762、2007年1月を。
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[RFC5003]メス、C.、マルティーニ、L.、Balus、F.、及びJ.杉本、 "集約のためのアタッチメント個体識別子（AII）タイプ"、RFC 5003、2007年9月。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659]ボッチ、M.とS.ブライアント、「マルチセグメント擬似回線エミュレーションエッジツーエッジのためのアーキテクチャ」、RFC 5659、2009年10月。
Authors' Addresses
著者のアドレス
Eric Rosen Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
エリック・ローゼンシスコ・システムズ・インク1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Bruce Davie Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
ブルース・デイビーシスコシステムズ株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
EMail: bsd@cisco.com
メールアドレス：bsd@cisco.com
Vasile Radoaca Alcatel-Lucent Think Park Tower 6F 2-1-1 Osaki, Tokyo, 141-6006 Japan
バシレRadoacaアルカテル・ルーセントは、パークタワー6F 2-1-1大崎、東京、141から6006日本を考えます
EMail: vasile.radoaca@alcatel-lucent.com
メールアドレス：vasile.radoaca@alcatel-lucent.com
Wei Luo
魏羅
EMail: luo@weiluo.net
メールアドレス：luo@weiluo.net