[要約] RFC 6074は、レイヤー2仮想プライベートネットワーク（L2VPN）におけるプロビジョニング、自動検出、およびシグナリングに関する標準化された手法を提供します。このRFCの目的は、L2VPNの展開と管理を容易にするためのガイドラインを提供することです。
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)
レイヤー2の仮想プライベートネットワーク（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の（仮想）バックボーンを形成する擬似動物（PWS）のメッシュをセットアップします。このドキュメントは、多数のL2VPNプロビジョニングモデルを指定し、各モデルに必要なエンドポイント識別子のセマンティック構造をさらに指定します。特に発見が境界ゲートウェイプロトコル（BGP）に基づいている場合、発見プロセスごとにこれらの識別子の分布について説明します。次に、PWS、ラベル分布プロトコル（LDP）、およびレイヤー2トンネルプロトコルバージョン3（L2TPV3）のセットアップに使用される2つのシグナル伝達プロトコルでエンドポイント識別子がどのように運ばれるかを指定します。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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]は、擬似動物のセットを「プロバイダープロビジョニングレイヤー2 VPNS」（L2 PPVPNS、またはL2VPNS）に結合し、さまざまな種類の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]で拡張された）のいずれかを、PWS [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]から用語を自由に使用します。（顧客のエッジ）、および「マルチセグメントの擬似ワイヤ」。
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では、さまざまなプロビジョニングモデルを詳しく説明し、シグナル伝達プロセスと発見プロセスに関連付けます。Signalingメカニズムを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環境でどのように適用できるかを説明し、Multi-AS L2VPNSの確立のためのいくつかのオプションを概説しています。
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]
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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）の簡単な場合、フォワーダーは擬似ワイヤを単一のアタッチメント回路に結合し、一方で受信したフレームが他方に送信され、その逆も同様です。仮想プライベートLANサービス（VPLS）では、フォワーダーが一連のアタッチメント回路に一連の擬似動物を結合します。そのセットのメンバーからフレームが受信されると、Mac（メディアアクセス制御）アドレステーブルが相談され（およびさまざまな802.1D手順が実行されます）、フレームを送信するセットのメンバーまたはメンバーを決定します。より複雑なシナリオでは、フォワーダーはPWSをPWSに結合する可能性があり、それにより2つのPWを一緒に「スプライシング」します。これは、たとえば、分散型VPLといくつかのインターアサルシナリオをサポートするために必要です。
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.
フォワーダーが正確に1つのPWを1つのアタッチメント回路に正確にバインドする単純なVPWでは、そのアタッチメント回路を識別することでフォワーダーを識別できます。単純なVPLでは、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]は、PSEUDOWIRES、PWID FEC要素、および一般化されたID FEC要素をセットアップするときに使用できる2つの転送等価クラス（FEC）要素を指定します。PWID FEC要素には、1つの転送識別子のみが搭載されています。したがって、両方のフォワーダーが同じ識別子を持っている場合、およびその識別子を32ビット数量としてコード化できる場合にのみ使用できます。一般化されたID FEC要素には、接続されている2つのフォワーダーのそれぞれに1つのフォワーダー識別子が2つあります。各識別子はアタッチメント識別子として知られており、シグナリングメッセージには「ソースアタッチメント識別子」（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には「アタッチメントグループ識別子」（AGI）と呼ばれる共通の部分があることがあります。そのため、SAIとTAIはそれぞれ「アタッチメント個体識別子」とAGIの連結と考えられると考えることができます。（AII）。したがって、識別子のペアは、AGI、ソースAII（SAII）、およびターゲットAII（TAII）の3つのフィールドにエンコードされます。SAIはAGIとSAIIの連結であり、TAIはAGIとTAIIの連結です。
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]では、1つまたは2つのフォワーダー識別子を使用して擬似動物をセットアップできます。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とSAIIの連結であり、ターゲットフォワーダー識別子はAGIとTAIIの連結です。
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.
さまざまなフォワーダーが異なるアプリケーションをサポートしているが、アプリケーションのタイプ（たとえば、VPLS対VPWS）は必ずしもフォワーダーの識別子から推測することはできないことに注意する必要があります。特定の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.
このドキュメントでは、特定のL2VPNアプリケーションに対してAGIとAIIのさらなる構造が提案されています。[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つのPWを確立できる可能性があります。
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で一連のアタッチメントサーキットを考慮することが時々役立つことがあります。たとえば、単一のCEを特定のPEに接続するアタッチメント回路のセットは、プールと見なされる場合があります。プールの使用については、セクション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>>
and the LSP in the opposite direction of the pseudowire will be identified by:
そして、擬似ワイヤの反対方向にあるLSPは、次のように識別されます。
o <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セッションの2つの方向を指します。
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が独自のアタッチメントサーキット（またはプール）の1つで構成されているアタッチメント識別子を参照する必要がある場合、アタッチメント識別子は「ソースアタッチメント識別子」と呼ばれます。PE1がPE2のアタッチメント回路（またはプール）のいずれかで構成されているアタッチメント識別子を参照する必要がある場合、アタッチメント識別子は「ターゲットアタッチメント識別子」と呼ばれます。（したがって、1つのエンドポイントのSAIはリモートエンドポイントのTAIであり、その逆も同様です。）
In the signaling protocol, we define encodings for the following three fields:
シグナリングプロトコルでは、次の3つのフィールドのエンコーディングを定義します。
o Attachment Group Identifier (AGI)
o アタッチメントグループ識別子（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が非ヌルの場合、SAIはSAIIと一緒にAGIで構成され、TAIはAGIと一緒にTAIIで構成されます。AGIがヌルの場合、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".
意図は、TAIを含むLDPラベルマッピングメッセージまたはL2TP着信要求（ICRQ）メッセージを受信するPEが、そのTAIをアタッチメントサーキット（またはプール）の1つにユニークにマッピングできることです。PEがTAIをアタッチメント回路（またはプール）にマッピングする方法は、ローカルの問題である必要があります（マッピングのためにTAIの一部またはすべてのバイトを使用するかどうかの選択を含む）。したがって、信号手順に関する限り、TAIは実際には単なる任意のバイト、「Cookie」です。
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.
ローカル名とリモート名が同じ場合、LDPベースのシグナリングの一般化されたID FEC要素の代わりにPWID 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値が含まれています。ローカル名とリモート名が同じ場合、L2TPシグナリングメッセージからローカルエンドID AVPを省略できます。
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で接続する場合、そのうちの1つだけがリモート名（もちろん他のアタッチメント回路のローカル名です）でプロビジョニングする必要があります。どちらもリモート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は、ローカル<VPN-ID、リモートAII>ペアを<VPN-ID、他のPESによって宣伝されているローカルAII>ペアを比較します。PE1にローカル<vpn-id、remite aii>ペアがvalue <v、fred>、およびpe2がローカル<vpn-id、local aii>ペアがvalue <v、fred>、pe1を持つ場合、PE2に接続する必要があることを発見してください。シグナリングの場合、「Fred」をTAIIとして使用し、VをAGIとして使用します。アタッチメント回路の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から別のPEにアタッチメント回路を移動できることです。ただし、以下のセクション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）は、ラベルマッピングメッセージを別のPE（PE2）に送信して、LSPを一方向に確立します。そのメッセージが正常に処理されており、反対側（PE1-> PE2）方向に擬似ワイヤのLSPがまだない場合、PE2はPE1にラベルマッピングメッセージを送信します。
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.
[RFC4447]の手順に加えて、PEがラベルマッピングメッセージを受信し、TAIがポイントツーポイントPWに結合するように構成された特定のアタッチメント回路を識別する場合、次のチェックを作成する必要があります。
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のうち1つだけが現在存在する場合を含む）、リモートエンドポイントが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 Status Code meaning "Attachment Circuit bound to different remote Attachment Circuit", and the processing of the Mapping message is complete.
アタッチメント回路が既に擬似ワイヤに結合している場合（2つのLSPのうち1つだけが現在存在する場合を含む）、PE1のAIはマッピングメッセージのAGI/SAIIフィールドで指定されているAIとは異なる場合、PE2はラベルを送信します「異なるリモートアタッチメント回路に結合されたアタッチメント回路」を意味するステータスコードを使用して、PE1へのメッセージをリリースし、マッピングメッセージの処理が完了します。
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.
同様に、L2TPベースのシグナル伝達では、PEがICRQメッセージを受信し、TAIがポイントツーポイントPWにバインドされるように構成された特定のアタッチメント回路を識別すると、次のチェックを実行します。
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と異なるAIを使用してPE1の転送者にバインドされている場合、PE2はPE1にCDNメッセージをPE1に送信し、ステータスコードで送信します「異なるリモートアタッチメント回路に結合したアタッチメント回路」を意味し、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]では、アタッチメント回路は、「仮想LANスイッチ」に接続するLANインターフェイス、または[RFC4664]の用語で「仮想スイッチングインスタンス」（VSIS）に付着するLANインターフェイスと考えることができます。各フォワーダーは、多くのPWSと多くのアタッチメント回路に付着するVSIです。VPLSサービスでは、同じVPLSにあるVSIの各ペアの間に単一の擬似ワイヤを作成する必要があります。各PEデバイスには複数のVSIがあり、各VSIは異なるVPLに属します。
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.
各VPLにはグローバルに一意の識別子が必要で、[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:
VPLSにBGPベースの自動ディスコーブリが使用される場合、AFI / SAFI（住所ファミリ識別子 /後続の住所ファミリ識別子）[RFC4760]は次のとおりです。
o An AFI (25) for L2VPN. (This is the same for all L2VPN schemes.)
o L2VPNのAFI（25）。（これはすべてのL2VPNスキームで同じです。）
o A SAFI (65) specifically for an L2VPN service whose pseudowires are set up using the procedures described in the current document.
o SAFI（65）は、現在の文書で説明されている手順を使用して擬似動物が設定されているL2VPNサービスのために特別に。
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に関連付けられた少なくとも1つのグローバルな一意の識別子が必要であり、各識別子は8バイトルートdistiutinger（RD）としてエンコードできる必要があります。VPLに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）としてエンコードできる一意の識別子が必要です。これは、RD（前の段落から）をVSIを含むPEのIPアドレスに準備することによって形成されます。このアドレスの役割は、VPN内のVSIの容易に利用可能な一意の識別子として単純に使用できることに注意してください。グローバルにルーティング可能である必要はありませんが、VPLSインスタンス内で一意でなければなりません。VPLSインスタンス内の各VSIに一意の識別子を割り当てる代替スキーム（たとえば、単一のVPNのVSIを1からNからNに番号付けする）を使用することが必要な場合に使用できます。
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インスタンス[RFC4762]に単一のグローバルに一意のVPLS-IDを割り当てる必要があります。このVPLS-IDは、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 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オクテットです。2番目の拡張コミュニティサブタイプは、IPv4アドレス固有の拡張コミュニティです。このようなコミュニティのエンコードは、[RFC4360]で定義されています。これらのエンコードにより、サービスプロバイダーは、別のプロバイダーとの衝突のリスクなしにVPLS-IDを割り当てることができます。ただし、セクション4.4で説明されているように、プロバイダー間L2VPNSにはプロバイダー間のVPLS-IDの調整が必要であることに注意してください。
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を介して、それぞれのVSIのNLRIを分布させ、それ自体がBGPの次のホップとして、およびそのようなNLRIごとに適切なRTを分布させることにより進行します。通常、各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.
特定のVPLが完全に接続された単一のLANであることを意図している場合、そのVSIはすべて同じRTを持ちます。その場合、RTは（ただし必要はありませんが）VPN-IDのエンコードになります。VSIは、複数のRTを割り当てることにより、複数のVPLSEに配置できます。
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.
階層VPLは、複数のRTをVSIの一部に割り当てることで設定できることに注意してください。RTメカニズムにより、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.
分散VPL（セクション3.5で説明）が展開されている場合、ネットワーク向けPES（N-PES）のみがBGPベースの自動配置に参加します。これは、N-PEが、接続されているユーザー向けPES（U-PE）にあるものを含む、サポートする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
o afi = l2vpnのnlri、safi = vpls、rdとしてエンコード：pe_addr
o a BGP next hop equal to the loopback address of the PE
o PEのループバックアドレスに等しいBGP次のホップ
o an Extended Community Attribute containing the VPLS-id
o VPLS-IDを含む拡張コミュニティ属性
o an Extended Community Attribute containing one or more RTs.
o 1つ以上のRTを含む拡張コミュニティ属性。
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]で定義されているVPLSスキーム間の相互運用性は、このドキュメントの範囲を超えています。
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を識別するアタッチメント識別子を作成する必要があります。前のセクションでは、VSI-IDがRD：PE_ADDRとしてエンコードされ、VPLS-IDはBGP拡張コミュニティで運ばれました。シグナリングのために、この情報は次のようにエンコードされます。AGIフィールドでVPLS-IDをエンコードし、PE_ADDR（より正確には、BGPのNLRIに含まれていたVSI-ID、RDを差し引いた）をTAIIフィールドに配置します。AGIとTAIIの組み合わせは、この擬似ワイヤーが接続するVSIを完全に指定するのに十分です。SAIIは、送信PEのPE_ADDRに設定する必要があります（または、より正確には、送信PEのこのVPLSに関連付けられたVSIのないVSIIDのないVSIID）を設定する必要があります。必要です。
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 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.
LDPの一般化ID FECのAGIおよびAIIフィールドの構造は、[RFC4447]で定義されています。この場合のAGIフィールドは、タイプ1、値8の長さフィールド、およびVPLS-IDの8バイトで構成されています。AIIは、値4の長さフィールドのタイプ1で構成され、その後4バイトのPEアドレス（または他の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.
また、この手法を使用して、1つのエンドポイントでVSIに接続するPWをセットアップすることも可能ですが、もう1つのエンドポイントではアタッチメント回路のみです。特定の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;
o 「色」は、ある種のVPN-IDと考えることができます。
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.] 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.
[注：アタッチメントサーキット（ACS）に使用されるテクノロジーに応じて、これらの回路も提供する必要がある場合とそうでない場合があります。たとえば、ACSがフレームリレー回路の場合、そのような回路をセットアップするための別のプロビジョニングシステムがある場合があります。または、ACの「プロビジョニング」は、インターフェイスに未使用のVLAN IDを割り当て、顧客に選択を伝えるのと同じくらい簡単な場合があります。これらの問題は、このドキュメントで説明されている手順とは無関係です。]一緒に取られるプール識別子と色は、プールのグローバルにユニークな識別子を構成します。したがって、特定の色のnプールがある場合、それらのプール識別子は（ただし必要ありませんが）1-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デバイスにつながるアタッチメント回路のセットである場合、CES間のレイヤー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:
VPWSにBGPベースの自動ディスコーブリが使用される場合、AFI/SAFIは次のとおりです。
o An AFI specified by IANA for L2VPN. (This is the same for all L2VPN schemes.)
o L2VPN用にIANAによって指定されたAFI。（これはすべての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.
o 現在の文書で説明されている手順を使用して擬似動物が設定されているL2VPNサービス専用にIANAによって指定されたSAFI。
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（Route Distiminger）としてエンコードできる必要があります。プールのグローバルにユニークな識別子は、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オクテットです。2番目の拡張コミュニティサブタイプは、IPv4アドレス固有の拡張コミュニティです。このようなコミュニティのエンコードは、[RFC4360]で定義されています。これらのエンコーディングにより、サービスプロバイダーは、別のプロバイダーとの衝突のリスクなしにVPWS識別子を割り当てることができます。ただし、セクション4.4で説明されているように、プロバイダー間L2VPNSにはプロバイダー間のVPWS識別子の調整が必要であることに注意してください。
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を介して各プールのNLRIを分布させ、それ自体がBGPの次のホップとして、およびプールの色をコードするRTを分配することにより、進行します。特定のPEに特定の色（RT）のプールがある場合、BGPを介して同じ色（RT）のすべての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;
o afi = l2vpnのnlri、safi = vpls、rd：pool_numとしてエンコードされています。
o a BGP next hop equal to the loopback address of the PE;
o BGP次のホップは、PEのループバックアドレスに等しくなります。
o an Extended Community Attribute containing the VPWS identifier;
o VPWS識別子を含む拡張コミュニティ属性。
o an Extended Community Attribute containing one or more RTs.
o 1つ以上のRTを含む拡張コミュニティ属性。
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）は、ラベルマッピングメッセージを別のPE（PE2）に送信して、LSPを一方向に確立します。PE2のアドレスは、上記のようにBGPを介して学習した次のホップのアドレスです。メッセージが正常に処理されており、擬似ワイヤのLSPが反対側（PE1-> PE2）方向にまだLSPがない場合、PE2はPE1にラベルマッピングメッセージを送信します。同様に、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がラベルマッピングメッセージまたはICRQメッセージを送信して2つのプールの間にPWをセットアップすると、VPWS識別子（BGPによって拡張されたコミュニティ属性に分散されているように）を、ローカルプールの相対識別子としてSAIIとしてのAGIとしてエンコードします。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がPE1からラベルマッピングメッセージまたはICRQメッセージを受信し、TAIがプールを識別すると、そのプールのアタッチメント回路をPE1のアタッチメント回路に接続する擬似ワイヤーがすでにあり、そのpe1のPE1のAIはラベルマッピングまたはICRQメッセージのSAIと同じで、PE2はラベルリリースまたはCDNメッセージをPE1に送信します。これにより、特定のプールのペア間で複数の擬似動物の作成が防止されます。
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 各プールは、オプションで「インポートRTS」と「エクスポートRTS」のセットで構成されています。
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でまだエンコードされていますが、プールが「エクスポートRTS」のセットで構成されている場合、これらは色の代わりに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.
o プールに特定の「Import RT」値Xがある場合、「エクスポートRT」の1つとして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.
分散VPLS（[RFC4664]）では、PEルーターのVPLS機能は、U-PEとN-PEの2つのシステムに分割されています。U-PEはユーザーとN-PEの間にあります。VSI機能（MACアドレス学習とブリッジングなど）がU-PEで実行されます。N-PEに付着する多くのU-PEが付着しています。U-PEでサポートされている各VPLについて、U-PEは同じVPLの他の各U-PEに対して擬似ワイヤーを維持します。ただし、U-PEは互いに信号制御接続を維持していません。むしろ、各U-PEには、N-PEへの単一のシグナル接続しかありません。本質的に、各u-pe-to-u-pe pseudowireは、U-PeからN-PeからN-PeからN-Peから1つ、N-PEからUへの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が一般的なVPLにあります。ここで、U-PE Aから他のU-PEに必要なPWを確立するために、上記のトポロジで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).
AからEまで3つのPWがあります。これらのA-E/1、A-E/2、およびA-E/3を呼び出します。Aを他のU-PEに適切に接続するには、EからFまで2つのPW（これらのE-F/1とE-F/2を呼び出します）、1つはEからB（E-B/1）、1つはFからFから1つあります。C（F-C/1）、およびFからD（F-D/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-PESは、これらの擬似動物をつなぎ合わせて、分散していないVPLSシグナル伝達メカニズムが提供するものに相当するものを取得する必要があります。
o PW from A to B: A-E/1 gets spliced to E-B/1.
o AからBからB：A-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.
o AからCへのPW：A-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 AからDへのPW：A-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.
結果がAからB、C、およびDのそれぞれになっている限り、どのPWがスプライスされるかは関係ありません。
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-PE BとU-PE Bを適切に相互接続し、U-PE CとU-PE Dを相互接続するために、スプライスしなければならない追加のPWがあります。
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.
次の図は、AからC、BからDから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）では、さまざまなN-PEとU-PE、およびN-PEの間に適切な数のPWSが確立されるように、追加の機械が必要です。
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アドレス>ペアのリストを指定する必要があります。このリストの各要素は、U-PEに指定されたIPアドレスにJ PWSを設定するように指示します。U-PEがN-PEに信号を送ると、AGIを適切なVPN-IDに設定し、SAIIをPW番号に設定し、TAIIをNULLに設定します。
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は<3、e>に通知され、3 pwsをEにセットアップするように指示します。、2、または3、3つのPWSのどれに応じてシグナル伝達しています。
As a result of configuration/discovery, each N-PE must be given the following information for each VPLS:
構成/発見の結果として、各N-PEには、各VPLについて次の情報を提供する必要があります。
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.
o 「ローカル」リスト：{<j、IPアドレス>}。各要素は、指定されたアドレスでローカルに添付されたU-PEにJ PWSを設定するように指示します。このリストの要素の数は、このVPLSに局所的に接続されたU-PEの数であるnです。上記の例では、eにローカルリストが表示されます：{<3、a>、<3、b>}は、3 pwsをAと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.
o そのU-PEの特定のVPLおよび特定のN-PEに比べて、ローカル番号。上記の例では、eはu-pe aが1で、u-pe bが2であるとeが伝えることができます。
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>}。各U-PEに対して、指定されたIPアドレスにK PWSをセットアップするように指示します。これらの各IPアドレスはN-PEを識別し、KはVPLSにあるN-PEのU-PEの数を指定します。上記の例では、eにリモートリストが与えられます：{<2、f>}。n-Pe Eには2つのU-PEがあるため、これは、それぞれEのU-PEに4つのPWSをN-PE Fにセットアップすることが指示されています。
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のローカル番号に基づいています。N-PEからU-PEに特定のPWをシグナル伝えると、AGIは適切なVPN-IDに設定され、SAIIはNULLに設定され、TAIIはPW番号に設定されます（その特定のVPLと比較して、u-pe）。上記の例では、eがAに信号を送信すると、TAIIをそれぞれ1、2、または3に設定します。3つのPWSに対してAに設定する必要があります。
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".
U-PEからN-PEに示されたLSPは、通常の方法でN-PEからU-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への適切なPWSセットのシグナル伝達は、リモートリストに基づいています。N-PEの間のPWSはすべて同等のものと見なすことができます。PWSの正しい総数が確立されている限り、N-PEはこれらのPWSを適切なU-PWSにスプライスできます。N-PEからN-PEへの正しい数のPWSのシグナル伝達は、リモートリストに基づいています。リモートリストは、特定のリモートN-PEに、ローカルU-PEごとにセットアップするPWSの数を指定します。
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がある場合、それらはSAIIの設定によって区別されます。単一のVPLで複数の異なるSAII値を許可するために、送信N-PEにはU-PEと同じくらい多くのVSIIDが必要です。上記のセクション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のu-pwsはリモートN-PE Fからi n-pwsにスプライスする必要があります。この制約が満たされている限り、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、およびそのような各VPLのローカルU-PEのリストでプロビジョニングする必要があります。発見手順の一環として、N-PEは各VPLの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-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）は、分散VPLを提供しているN-PE/U-PEペアと相互運用できます。「分散していないPE」は、発見手順で、VPLごとに1つのローカル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.
VPLのすべてのPEが分散していないVPLSを提供しているため、すべてのPEが1つのローカル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.
MPLSデータプレーンでは、2つのPWSを一緒にスプライシングすることは非常に簡単です。パケットを1つのPWから別のPWに直接移動することは、PWラベルの「ラベル交換」操作にすぎません。PWが2つ以上の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 Inter-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と宛先ASEの間のL2VPN NLRISのマルチホップ外部BGP（EBGP）の再分布を使用し、ASから隣接するASから標識IPv4またはIPv6ルートの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）ルートを維持する必要があります。EBGPを使用してこれらのルートを他のASEに分配し、これらのルートの次のBGPホップとして自分自身を設定します。任意の輸送ASESのASBRは、EBGPを使用して、ラベル付き /32（または /128）ルートを渡す必要があります。これにより、すべてのイングレスPEルーターからすべての出力PEルーターへのラベルスイッチ付きパスのセットが作成されます。現在、異なるASEのPEルーターは、マルチホップEBGP接続を互いに確立し、それらの接続でL2VPN NLRIを交換できます。このような交換に続いて、異なるASEのペアがLDPセッションを確立して、互いの間でPWSを通知する可能性があります。
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.
VPLSの場合、BGP広告とPWシグナル伝達は、セクション3.2で説明されているとおりです。ソースと宛先の間に存在するマルチホップEBGPセッションの結果として、特定のVPLのVSIを持つPESは、同じVPLのVSISを持つPESを別のPESで発見します。これらのPESは、適切なPWシグナル伝達プロトコルセッションを確立し、VSI-VSI疑似ワイヤの完全なメッシュを確立して、セクション3.2.3で説明したようにVPLSを構築することができます。
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.
VPWSの場合、BGP広告とPWシグナル伝達は、セクション3.3で説明されているとおりです。ソースと宛先の間に存在するマルチホップEBGPセッションの結果として、特定の色のプール（VPN）があるASのPESは、同じ色のプールのように別のPESを発見します。これらのPESは、適切な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 VPNSと同様に、複数のプロバイダーのネットワークにまたがる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内の多くのデバイスに接続することを意味します。ASESが異なるプロバイダーに属する場合、プロバイダーは境界を通過するシグナリングセッションを減らしたいと思うと想像するかもしれません。さらに、LDPまたはL2TPV3シグナル伝達セッションにASBRの小さなセットで終了するように強制することにより、プロバイダーは小さなプロバイダー間セッションのセットで標準認証手順を使用できます。これらの懸念は、ここで説明するアプローチを動機付けています。
[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 Inter-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からのL2VPN NLRIのEBGP再分布を隣接するASから使用します。まず、PEルーターは内部BGP（IBGP）を使用して、ASBRまたはASBRがクライアントであるルートリフレクターにL2VPN NLRIを再分配します。ASBRはEBGPを使用して、それらのL2VPN NLRIを別のASのASBRに再配布します。これにより、ASのPEルーターに分布します。
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にのみ構築します。PEからASBRまでの擬似ワイヤセグメントを確立できるようになりました。ASBRは、次のASBRにPWを確立し、セクション3.5.4および[RFC6073]で説明したように、PWからPWにPWをスプライスできます。各ASBRでプロセスを繰り返すと、PWセグメントのシーケンスにつながり、2つのPEを接続すると、2つのPEを接続します。
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、またはフルメッシュVPWに使用される場合、前のセクションと同様に、PESの間で擬似動物の完全なメッシュにつながりますが、制御接続の完全なメッシュ（LDPまたはL2TPV3セッションは必要ありません。）。代わりに、そのasのすべてのpesとasのasbrsの間で実行されるシングル内の制御接続。隣接するASEの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.
ここで説明する手順は、[RFC5659]の用語でPWスイッチングPES（S-PES））をASBRと共同で配置することになることに注意してください。もちろん、特定のASEのペア間に複数のASBR-ASBR接続を持つことが可能です。この場合、特定のPEは、通常のIPルーティングで終了ポイントを選択することに類似した、IGPメトリック、ローカル構成など、さまざまな基準に基づいて利用可能なASBRの中から選択できます。複数のASBRを使用すると、PEは現在使用されている人が失敗した場合に新しい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 VPNSと同様に、複数のプロバイダーのネットワークにまたがる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:
プロバイダー間VPLへの別のアプローチは、上記の分散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のPESですが、ネットワーク1と2はさまざまなサービスプロバイダーのネットワークです。ボーダールーター12は、ネットワーク1のボーダールーターからネットワーク2、ボーダールーター21はネットワーク2のボーダールーターからネットワーク1です。さらに、PEは「分布」されていないと考えています。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.
これは、PESがU-PESのように振る舞い、BRSがN-PEのように振る舞うセクション3.5の手法を使用して実現できます。トポロジの例では、PE AはBR12に局所的に接続されているU-PEのように振る舞います。PES BとCは、BR21に局所的に接続されているU-PESのようになります。そして、2つのBRSは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からBからBまでのPWは、A-BR12、BR12-BR21、およびBR21-Bの3つのセグメントで構成されます。ボーダールーターは、対応するセグメントを一緒にスプライスする必要があります。
This requires the PEs within a VPLS to be numbered from 1-n (relative to that VPLS) within a given network.
これには、VPL内のPEが特定のネットワーク内の1-N（そのVPLと比較して）から番号を付けられる必要があります。
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.
上記のAS間の手順のいずれかが正しく機能するためには、2つのASEは、レイヤー3 VPN [RFC4364]と同様に、RTとRDSを一貫して使用する必要があることに注意してください。RTSとRDSの構造は、偶発的な衝突の大きなリスクがないようなものです。主な課題は、両方のASEにサイトを持っているVPNのように、RTまたはRTが別のRTまたはRTが選択されたものを知るために、1つのオペレーターに必要であることです。レイヤー3 VPNと同様に、この作業を行うには多くの方法がありますが、すべてプロバイダー間の協力が必要です。たとえば、プロバイダーAは、特定のVPNのすべてのNLRIに単一のRT、たとえばRT_Aを使用してタグ付けすることができます。プロバイダーBは、そのVPNのサイトに接続するPEを構成して、そのRTを含むNLRIをインポートできます。プロバイダーBは、別のRT、RT_Bを選択し、このVPNのすべてのNLRIをそのRTでタグ付けし、プロバイダーAは適切なPESでそのRTでNLRIをインポートできます。ただし、これには両方のプロバイダーが各VPNに対してRTの選択を伝える必要があります。あるいは、両方のプロバイダーが、特定のVPNに共通のRTを使用することに同意することができます。いずれにせよ、プロバイダー間のRTの通信が不可欠です。レイヤー3 VPNSと同様に、プロバイダーはRTフィルタリングを構成して、調整されたRT値のみがAS境界全体で許可されることを確認できます。
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.
各VPLSまたはVPWSインスタンスには、単一のVPN識別子（BGP拡張コミュニティで運ばれる）が必要であることに注意してください。これらの識別子のエンコーディングルール[RFC4360]は、他のプロバイダーとの衝突が発生しないことを保証します。ただし、2つ以上のプロバイダーのネットワークにまたがる単一のVPLSまたはVPWSインスタンスの場合、1つのプロバイダーが識別子を割り当て、この選択を他のプロバイダーに伝える必要があります。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プロビジョニングモデルについて説明し、各プロビジョニングモデルをサポートするために必要なエンドポイント識別子を指定します。また、これらのエンドポイント識別子が自動発見プロトコルとシグナリングプロトコルのフィールドにマッピングされる方法も指定します。
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 Inter-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は、L2VPN NLRIのAFIとSAFIを割り当てました。AFIとSAFIの両方は、[RFC4761]に割り当てられた値と同じです。つまり、AFIは25（L2VPN）で、SAFIは65です（VPLにはすでに割り当てられています）。このドキュメントで説明されているように、同じ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
0x00000030別のPEに結合したアタッチメント回路
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:
CDNメッセージに2つの新しいL2TP結果コードが登録されています。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オクテット」というタイトルのレジストリを定義しています。IANAは、このレジストリに「推移的」範囲（0x0000-0x00FF）から値を割り当てました。値は次のとおりです。
o 0x000A Two-octet AS specific Layer 2 VPN Identifier
o 0x000A特定のレイヤー2 VPN識別子としての2オクテット
[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の長さをDemultiplexerとして使用する必要があります。
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のNLRI長は12バイトのNLRI長で、8バイトRDと4バイトのVSI-IDのみが含まれています。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.
ダン・タッパン、テッド・チアン、アリ・サジャシ、スキップ・ブース、ルカ・マティーニ、デイブ・マクディサン、フランソワ・ル・フォーシュール、ラス・ガルド、キール・パテル、サム・ヘンダーソン、マシュー・ボッチのコメント、批判、有益な提案に感謝します。
Thanks to Tissa Senevirathne, Hamid Ould-Brahim, and Yakov Rekhter for discussing the auto-discovery issues.
Tissa Senevirathne、Hamid Oould-Brahim、およびYakov Rekhterに感謝します。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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）考慮事項更新」、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] Lau、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] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP拡張コミュニティ属性」、RFC 4360、2006年2月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、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] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用したPseudowireのセットアップとメンテナンス」、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] Luo、W。、「レイヤー2仮想プライベートネットワーク（L2VPN）レイヤー2トンネリングプロトコル（L2TP）の拡張機能」、RFC 4667、2006年9月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
[RFC6073] Martini、L.、Metz、C.、Nadeau、T.、Bocci、M。、およびM. Aissaoui、「セグメント化されたPseudowire」、RFC 6073、2011年1月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026] Andersson、L。およびT. Madsen、「プロバイダープロビジョニング仮想プライベートネットワーク（VPN）用語」、RFC 4026、2005年3月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L。およびE. Rosen、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、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] Augustyn、W。and 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、「ラベル分布プロトコル（LDP）シグナル伝達を使用した仮想プライベートLANサービス（VPLS）」、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] Metz、C.、Martini、L.、Balus、F。、およびJ. Sugimoto、「集約のためのアタッチメント個体識別子（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] Bocci、M。およびS. Bryant、「マルチセグメントの擬似ワイヤーエミュレーションエッジツーエッジのアーキテクチャ」、RFC 5659、2009年10月。
Authors' Addresses
著者のアドレス
Eric Rosen Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
Eric Rosen Cisco Systems、Inc。1414Mass。Ave.Boxborough、MA 01719 USA
EMail: erosen@cisco.com
Bruce Davie Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
ブルース・デイビー・シスコ・システムズ、Inc。1414Mass。Ave.Boxborough、MA 01719 USA
EMail: bsd@cisco.com
Vasile Radoaca Alcatel-Lucent Think Park Tower 6F 2-1-1 Osaki, Tokyo, 141-6006 Japan
Vasile Radoaca Alcatel-Lucent Think Park Tower 6f 2-1-1 Osaki、Tokyo、141-6006 Japan
EMail: vasile.radoaca@alcatel-lucent.com
Wei Luo
wei luo
EMail: luo@weiluo.net