[要約] RFC 4761は、BGPを使用した自動検出とシグナリングのためのVirtual Private LAN Service（VPLS）に関する規格です。このRFCの目的は、VPLSを実装するためのBGPベースのメカニズムを提供することです。
Network Working Group K. Kompella, Ed.
Request for Comments: 4761 Y. Rekhter, Ed.
Category: Standards Track Juniper Networks
January 2007
Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
自動配置とシグナリングにBGPを使用した仮想プライベートLANサービス（VPLS）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
IESG Note
IESGノート
The L2VPN Working Group produced two separate documents, RFC 4762 and this document, that ultimately perform similar functions in different manners. Be aware that each method is commonly referred to as "VPLS" even though they are distinct and incompatible with one another.
L2VPNワーキンググループは、RFC 4762とこのドキュメントの2つの個別のドキュメントを作成しました。これは、最終的に異なるマナーで同様の機能を実行します。それぞれの方法は、互いに明確で互換性がなくても、一般に「VPL」と呼ばれることに注意してください。
Abstract
概要
Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.
透明なLANサービスおよび仮想プライベートスイッチネットワークサービスとしても知られる仮想プライベートLANサービス（VPLS）は、有用なサービスプロバイダーの提供です。このサービスは、レイヤー2仮想プライベートネットワーク（VPN）を提供します。ただし、VPLSの場合、VPNの顧客は、本質的にポイントツーポイントツーポイントである通常のレイヤー2 VPNとは対照的に、マルチポイントイーサネットLANによって接続されています。
This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network.
このドキュメントでは、VPLSを提供するために必要な機能、VPLSをシグナル伝えるためのメカニズム、およびパケットスイッチネットワーク全体にVPLSフレームを転送するためのルールについて説明します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope of This Document .....................................3
1.2. Conventions Used in This Document ..........................4
2. Functional Model ................................................4
2.1. Terminology ................................................5
2.2. Assumptions ................................................5
2.3. Interactions ...............................................6
3. Control Plane ...................................................6
3.1. Auto-Discovery .............................................7
3.1.1. Functions ...........................................7
3.1.2. Protocol Specification ..............................7
3.2. Signaling ..................................................8
3.2.1. Label Blocks ........................................8
3.2.2. VPLS BGP NLRI .......................................9
3.2.3. PW Setup and Teardown ..............................10
3.2.4. Signaling PE Capabilities ..........................10
3.3. BGP VPLS Operation ........................................11
3.4. Multi-AS VPLS .............................................13
3.4.1. Method (a): VPLS-to-VPLS Connections at the ASBRs ..13
3.4.2. Method (b): EBGP Redistribution of VPLS
Information between ASBRs ..........................14
3.4.3. Method (c): Multi-Hop EBGP Redistribution
of VPLS Information ................................15
3.4.4. Allocation of VE IDs across Multiple ASes ..........16
3.5. Multi-homing and Path Selection ...........................16
3.6. Hierarchical BGP VPLS .....................................17
4. Data Plane .....................................................18
4.1. Encapsulation .............................................18
4.2. Forwarding ................................................18
4.2.1. MAC Address Learning ...............................18
4.2.2. Aging ..............................................19
4.2.3. Flooding ...........................................19
4.2.4. Broadcast and Multicast ............................20
4.2.5. "Split Horizon" Forwarding .........................20
4.2.6. Qualified and Unqualified Learning .................21
4.2.7. Class of Service ...................................21
5. Deployment Options .............................................21
6. Security Considerations ........................................22
7. IANA Considerations ............................................23
8. References .....................................................24
8.1. Normative References ......................................24
8.2. Informative References ....................................24
Appendix A. Contributors .........................................26
Appendix B. Acknowledgements .....................................26
Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful service offering. A Virtual Private LAN appears in (almost) all respects as an Ethernet LAN to customers of a Service Provider. However, in a VPLS, the customers are not all connected to a single LAN; the customers may be spread across a metro or wide area. In essence, a VPLS glues together several individual LANs across a packet switched network to appear and function as a single LAN [9]. This is accomplished by incorporating MAC address learning, flooding, and forwarding functions in the context of pseudowires that connect these individual LANs across the packet switched network.
透明なLANサービスおよび仮想プライベートスイッチネットワークサービスとしても知られる仮想プライベートLANサービス（VPLS）は、有用なサービスです。仮想プライベートLANは、（ほぼ）サービスプロバイダーの顧客に対するイーサネットLANとして（ほぼ）すべての点に登場します。ただし、VPLSでは、顧客はすべて単一のLANに接続されているわけではありません。顧客は、地下鉄または広いエリアに広がる場合があります。本質的に、VPLSは、パケットスイッチネットワーク全体にいくつかの個々のLANを接着し、単一のLANとして表示され、機能します[9]。これは、Packet Switchedネットワークを介してこれらの個々のLANを接続する擬似動物のコンテキストで、MACアドレス学習、洪水、および転送機能を組み込むことによって達成されます。
This document details the functions needed to offer VPLS, and then goes on to describe a mechanism for the auto-discovery of the endpoints of a VPLS as well as for signaling a VPLS. It also describes how VPLS frames are transported over tunnels across a packet switched network. The auto-discovery and signaling mechanism uses BGP as the control plane protocol. This document also briefly discusses deployment options, in particular, the notion of decoupling functions across devices.
このドキュメントは、VPLSを提供するために必要な機能の詳細を詳しく説明し、VPLSのエンドポイントの自動発見とVPLSのシグナリングのメカニズムを説明します。また、VPLSフレームがパケットスイッチされたネットワークを介してトンネル上でどのように輸送されるかについても説明しています。自動発見とシグナル伝達メカニズムは、コントロールプレーンプロトコルとしてBGPを使用します。このドキュメントでは、展開オプション、特にデバイス全体のデカップリング機能の概念についても簡単に説明します。
Alternative approaches include: [14], which allows one to build a Layer 2 VPN with Ethernet as the interconnect; and [13], which allows one to set up an Ethernet connection across a packet switched network. Both of these, however, offer point-to-point Ethernet services. What distinguishes VPLS from the above two is that a VPLS offers a multipoint service. A mechanism for setting up pseudowires for VPLS using the Label Distribution Protocol (LDP) is defined in [10].
代替アプローチには以下が含まれます。[14]。これにより、インターコネクトとしてイーサネットを使用してレイヤー2 VPNを構築できます。[13]により、パケットスイッチネットワーク全体にイーサネット接続を設定できます。ただし、これらはどちらもポイントツーポイントイーサネットサービスを提供します。VPLと上記の2つを区別するのは、VPLSがマルチポイントサービスを提供することです。ラベル分布プロトコル（LDP）を使用してVPLSの擬似動物をセットアップするメカニズムは[10]で定義されています。
This document has four major parts: defining a VPLS functional model; defining a control plane for setting up VPLS; defining the data plane for VPLS (encapsulation and forwarding of data); and defining various deployment options.
このドキュメントには4つの主要な部分があります。VPLS機能モデルの定義。VPLSをセットアップするためのコントロールプレーンの定義。VPLSのデータプレーンの定義（データのカプセル化と転送）。さまざまな展開オプションを定義します。
The functional model underlying VPLS is laid out in Section 2. This describes the service being offered, the network components that interact to provide the service, and at a high level their interactions.
VPLの基礎となる機能モデルはセクション2で説明されています。これは、提供されているサービス、サービスを提供するために対話するネットワークコンポーネント、および高レベルでの相互作用について説明します。
The control plane described in this document uses Multiprotocol BGP [4] to establish VPLS service, i.e., for the auto-discovery of VPLS members and for the setup and teardown of the pseudowires that constitute a given VPLS instance. Section 3 focuses on this, and also describes how a VPLS that spans Autonomous System boundaries is set up, as well as how multi-homing is handled. Using BGP as the control plane for VPNs is not new (see [14], [6], and [11]): what is described here is based on the mechanisms proposed in [6].
このドキュメントで説明されているコントロールプレーンは、Multiprotocol BGP [4]を使用してVPLSサービスを確立します。つまり、VPLSメンバーの自動配信、および特定のVPLSインスタンスを構成する擬似動物のセットアップと分解のために。セクション3では、これに焦点を当て、自律システムの境界にまたがるVPLがどのように設定されているか、マルチホミングの処理方法についても説明します。VPNの制御面としてBGPを使用することは新しいものではありません（[14]、[6]、および[11]を参照）：ここで説明されているのは、[6]で提案されているメカニズムに基づいています。
The forwarding plane and the actions that a participating Provider Edge (PE) router offering the VPLS service must take is described in Section 4.
フォワーディングプレーンと参加プロバイダーエッジ（PE）ルーターがVPLSサービスを提供する必要があるアクションについては、セクション4で説明します。
In Section 5, the notion of 'decoupled' operation is defined, and the interaction of decoupled and non-decoupled PEs is described. Decoupling allows for more flexible deployment of VPLS.
セクション5では、「分離された」操作の概念が定義されており、分離されたPEと非分離PEの相互作用が説明されています。デカップリングにより、VPLのより柔軟な展開が可能になります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [1]に記載されているように解釈される。
This will be described with reference to the following figure.
これについては、次の図を参照して説明します。
-----
/ A1 \
---- ____CE1 |
/ \ -------- -------- / | |
| A2 CE2- / \ / PE1 \ /
\ / \ / \___/ | \ -----
---- ---PE2 | \
| | \ -----
| Service Provider Network | \ / \
| | CE5 A5 |
| ___ | / \ /
|----| \ / \ PE4_/ -----
|u-PE|--PE3 / \ /
|----| -------- -------
---- / | ----
/ \/ \ / \ CE = Customer Edge Device
| A3 CE3 --CE4 A4 | PE = Provider Edge Router
\ / \ / u-PE = Layer 2 Aggregation
---- ---- A<n> = Customer site n
Figure 1: Example of a VPLS
図1：VPLSの例
Terminology similar to that in [6] is used: a Service Provider (SP) network with P (Provider-only) and PE (Provider Edge) routers, and customers with CE (Customer Edge) devices. Here, however, there is an additional concept, that of a "u-PE", a Layer 2 PE device used for Layer 2 aggregation. The notion of u-PE is described further in Section 5. PE and u-PE devices are "VPLS-aware", which means that they know that a VPLS service is being offered. The term "VE" refers to a VPLS edge device, which could be either a PE or a u-PE.
[6]と同様の用語が使用されています。P（プロバイダーのみ）およびPE（プロバイダーエッジ）ルーターを備えたサービスプロバイダー（SP）ネットワーク、およびCE（顧客エッジ）デバイスの顧客。ただし、ここには、レイヤー2の凝集に使用される「U-PE」、レイヤー2 PEデバイスの追加の概念があります。U-PEの概念については、セクション5でさらに説明します。PEおよびU-PEデバイスは「VPLS-Aware」です。つまり、VPLSサービスが提供されていることを知っています。「VE」という用語は、PEまたはU-PEのいずれかであるVPLS Edgeデバイスを指します。
In contrast, the CE device (which may be owned and operated by either the SP or the customer) is VPLS-unaware; as far as the CE is concerned, it is connected to the other CEs in the VPLS via a Layer 2 switched network. This means that there should be no changes to a CE device, either to the hardware or the software, in order to offer VPLS.
対照的に、CEデバイス（SPまたは顧客が所有および運用する場合があります）はVPLS-Unawareです。CEに関する限り、レイヤー2スイッチネットワークを介してVPLSの他のCESに接続されています。これは、VPLSを提供するために、ハードウェアまたはソフトウェアのいずれかのCEデバイスに変更がないはずです。
A CE device may be connected to a PE or a u-PE via Layer 2 switches that are VPLS-unaware. From a VPLS point of view, such Layer 2 switches are invisible, and hence will not be discussed further. Furthermore, a u-PE may be connected to a PE via Layer 2 and Layer 3 devices; this will be discussed further in a later section.
CEデバイスは、VPLS-Unawareのレイヤー2スイッチを介してPEまたはU-PEに接続できます。VPLSの観点からは、このようなレイヤー2スイッチは見えないため、これ以上議論されません。さらに、U-PEは、レイヤー2およびレイヤー3デバイスを介してPEに接続できます。これについては、後のセクションでさらに説明します。
The term "demultiplexor" refers to an identifier in a data packet that identifies the VPLS to which the packet belongs as well as the ingress PE. In this document, the demultiplexor is an MPLS label.
「Demultiplexor」という用語は、パケットが属するVPLとIngress PEを識別するデータパケットの識別子を指します。このドキュメントでは、DemultiplexorはMPLSラベルです。
The term "VPLS" will refer to the service as well as a particular instantiation of the service (i.e., an emulated LAN); it should be clear from the context which usage is intended.
「VPLS」という用語は、サービスの特定のインスタンス化（つまり、エミュレートされたLAN）を指します。使用が意図されているコンテキストから明確にする必要があります。
The Service Provider Network is a packet switched network. The PEs are assumed to be (logically) fully meshed with tunnels over which packets that belong to a service (such as VPLS) are encapsulated and forwarded. These tunnels can be IP tunnels, such as Generic Routing Encapsulation (GRE), or MPLS tunnels, established by Resource Reservation Protocol - Traffic Engineering (RSVP-TE) or LDP. These tunnels are established independently of the services offered over them; the signaling and establishment of these tunnels are not discussed in this document.
サービスプロバイダーネットワークは、パケットスイッチネットワークです。PESは、サービス（VPLなど）に属するパケットがカプセル化され、転送されているトンネルと（論理的に）完全にメッシュ化されていると想定されています。これらのトンネルは、リソース予約プロトコル - トラフィックエンジニアリング（RSVP -TE）またはLDPによって確立された、ジェネリックルーティングカプセル化（GRE）またはMPLSトンネルなどのIPトンネルになります。これらのトンネルは、それらに提供されるサービスとは独立して確立されています。これらのトンネルの信号と確立については、この文書では説明されていません。
"Flooding" and MAC address "learning" (see Section 4) are an integral part of VPLS. However, these activities are private to an SP device, i.e., in the VPLS described below, no SP device requests another SP device to flood packets or learn MAC addresses on its behalf.
「洪水」とMacアドレス「学習」（セクション4を参照）は、VPLSの不可欠な部分です。ただし、これらのアクティビティはSPデバイスにとってプライベートです。つまり、以下に説明するVPLSでは、SPデバイスは別のSPデバイスに、その代わりにMacアドレスを洪水にしたり、Macアドレスを学んだりすることを要求していません。
All the PEs participating in a VPLS are assumed to be fully meshed in the data plane, i.e., there is a bidirectional pseudowire between every pair of PEs participating in that VPLS, and thus every (ingress) PE can send a VPLS packet to the egress PE(s) directly, without the need for an intermediate PE (see Section 4.2.5.) This requires that VPLS PEs are logically fully meshed in the control plane so that a PE can send a message to another PE to set up the necessary pseudowires. See Section 3.6 for a discussion on alternatives to achieve a logical full mesh in the control plane.
VPLSに参加するすべてのPEは、データプレーンに完全にメッシュ化されていると想定されています。つまり、そのVPLに参加するすべてのペアのペアの間に双方向の擬似ワイヤがあり、したがって、すべての（侵入）PEはVPLSパケットを出口に送信できます。PE（s）は直接、中間PEを必要とせずに（セクション4.2.5を参照）。擬似ワイヤ。コントロールプレーンで論理的なフルメッシュを達成するための代替案についての議論については、セクション3.6を参照してください。
VPLS is a "LAN Service" in that CE devices that belong to a given VPLS instance V can interact through the SP network as if they were connected by a LAN. VPLS is "private" in that CE devices that belong to different VPLSs cannot interact. VPLS is "virtual" in that multiple VPLSs can be offered over a common packet switched network.
VPLSは、特定のVPLSインスタンスVに属するCEデバイスの「LANサービス」であり、LANで接続されているかのようにSPネットワークを介して相互作用できます。VPLSは、異なるVPLSに属するCEデバイスでは「プライベート」です。VPLSは、複数のVPLSを共通のパケットスイッチネットワークで提供できるという点で「仮想」です。
PE devices interact to "discover" all the other PEs participating in the same VPLS, and to exchange demultiplexors. These interactions are control-driven, not data-driven.
PEデバイスは、同じVPLSに参加している他のすべてのPEを「発見」し、Demultiplexorsを交換するために対話します。これらの相互作用は、データ駆動型ではなく、制御駆動型です。
u-PEs interact with PEs to establish connections with remote PEs or u-PEs in the same VPLS. This interaction is control-driven.
U-PEはPEと相互作用して、同じVPLでリモートPEまたはU-PEとの接続を確立します。この相互作用はコントロール駆動型です。
PE devices can participate simultaneously in both VPLS and IP VPNs [6]. These are independent services, and the information exchanged for each type of service is kept separate as the Network Layer Reachability Information (NLRI) used for this exchange has different Address Family Identifiers (AFIs) and Subsequent Address Family Identifiers (SAFIs). Consequently, an implementation MUST maintain a separate routing storage for each service. However, multiple services can use the same underlying tunnels; the VPLS or VPN label is used to demultiplex the packets belonging to different services.
PEデバイスは、VPLとIP VPNの両方で同時に参加できます[6]。これらは独立したサービスであり、各タイプのサービスに対して交換される情報は、この交換に使用されるネットワークレイヤーリーチビリティ情報（NLRI）が異なるアドレスファミリ識別子（AFI）とその後のアドレスファミリ識別子（SAFIS）を持っているため、分離されています。したがって、実装は各サービスの個別のルーティングストレージを維持する必要があります。ただし、複数のサービスは同じ基礎となるトンネルを使用できます。VPLSまたはVPNラベルは、さまざまなサービスに属するパケットを反転させるために使用されます。
There are two primary functions of the VPLS control plane: auto-discovery, and setup and teardown of the pseudowires that constitute the VPLS, often called signaling. Section 3.1 and Section 3.2 describe these functions. Both of these functions are accomplished with a single BGP Update advertisement; Section 3.3 describes how this is done by detailing BGP protocol operation for VPLS. Section 3.4 describes the setting up of pseudowires that span Autonomous Systems. Section 3.5 describes how multi-homing is handled.
VPLSコントロールプレーンには、自動ディスコービリと、しばしばシグナル伝達と呼ばれるVPLSを構成する偽筋のセットアップと分解という2つの主要な機能があります。セクション3.1およびセクション3.2は、これらの機能について説明します。これらの関数は両方とも、単一のBGP更新広告で達成されます。セクション3.3では、VPLSのBGPプロトコル操作を詳細に詳述することにより、これがどのように行われるかについて説明します。セクション3.4では、自律システムにまたがる擬似動物の設置について説明します。セクション3.5では、マルチホーミングの処理方法について説明します。
Discovery refers to the process of finding all the PEs that participate in a given VPLS instance. A PE either can be configured with the identities of all the other PEs in a given VPLS or can use some protocol to discover the other PEs. The latter is called auto-discovery.
発見とは、特定のVPLSインスタンスに参加するすべてのPEを見つけるプロセスを指します。PEは、特定のVPLSの他のすべてのPEのアイデンティティで構成するか、一部のプロトコルを使用して他のPEを発見することができます。後者は自動配置と呼ばれます。
The former approach is fairly configuration-intensive, especially since it is required that the PEs participating in a given VPLS are fully meshed (i.e., that every PE in a given VPLS establish pseudowires to every other PE in that VPLS). Furthermore, when the topology of a VPLS changes (i.e., a PE is added to, or removed from, the VPLS), the VPLS configuration on all PEs in that VPLS must be changed.
前者のアプローチは、特に特定のVPLに参加するPESが完全にメッシュ化される必要があるため、かなり構成集約的です（つまり、特定のVPLのすべてのPEがそのVPLの他のすべてのPEに擬似動物を確立することです）。さらに、VPLSのトポロジーが変化する場合（つまり、VPLにPEが追加または削除されます）、そのVPLSのすべてのPEのVPLS構成を変更する必要があります。
In the auto-discovery approach, each PE "discovers" which other PEs are part of a given VPLS by means of some protocol, in this case BGP. This allows each PE's configuration to consist only of the identity of the VPLS instance established on this PE, not the identity of every other PE in that VPLS instance -- that is auto-discovered. Moreover, when the topology of a VPLS changes, only the affected PE's configuration changes; other PEs automatically find out about the change and adapt.
自動発見アプローチでは、各PEは、他のPEがあるプロトコル、この場合はBGPによって与えられたVPLの一部であることを「発見」します。これにより、各PEの構成は、このVPLSインスタンスの他のすべてのPEのアイデンティティではなく、このPEに確立されたVPLSインスタンスのIDからのみ構成されます。さらに、VPLSのトポロジーが変化すると、影響を受けるPEの構成のみが変化します。他のPESは、変更について自動的に発見し、適応します。
A PE that participates in a given VPLS instance V must be able to tell all other PEs in VPLS V that it is also a member of V. A PE must also have a means of declaring that it no longer participates in a VPLS. To do both of these, the PE must have a means of identifying a VPLS and a means by which to communicate to all other PEs.
特定のVPLSインスタンスvに参加するPEは、VPLS Vの他のすべてのPESにVのメンバーでもあることを伝えることができなければなりません。PEは、VPLSに参加しなくなったことを宣言する手段を持たなければなりません。これらの両方を行うには、PEにはVPLを識別する手段と、他のすべてのPEと通信する手段が必要です。
U-PE devices also need to know what constitutes a given VPLS; however, they don't need the same level of detail. The PE (or PEs) to which a u-PE is connected gives the u-PE an abstraction of the VPLS; this is described in Section 5.
U-PEデバイスは、特定のVPLを構成するものを知る必要もあります。ただし、同じレベルの詳細は必要ありません。U-PEが接続されているPE（またはPE）は、U-PEにVPLの抽象化を与えます。これはセクション5で説明されています。
The specific mechanism for auto-discovery described here is based on [14] and [6]; it uses BGP extended communities [5] to identify members of a VPLS, in particular, the Route Target community, whose format is described in [5]. The semantics of the use of Route Targets is described in [6]; their use in VPLS is identical.
ここで説明する自動配信の特定のメカニズムは、[14]および[6]に基づいています。BGP拡張コミュニティ[5]を使用して、VPLSのメンバー、特に[5]で説明されているルートターゲットコミュニティを特定します。ルートターゲットの使用のセマンティクスは[6]で説明されています。VPLSでの使用は同一です。
As it has been assumed that VPLSs are fully meshed, a single Route Target RT suffices for a given VPLS V, and in effect that RT is the identifier for VPLS V.
VPLSが完全にメッシュ化されていると想定されているように、特定のVPLS Vには単一のルートターゲットRTで十分であり、RTはVPLS Vの識別子であることを事実上。
A PE announces (typically via I-BGP) that it belongs to VPLS V by annotating its NLRIs for V (see next subsection) with Route Target RT, and acts on this by accepting NLRIs from other PEs that have Route Target RT. A PE announces that it no longer participates in V by withdrawing all NLRIs that it had advertised with Route Target RT.
PEは、v（次のサブセクションを参照）をルートターゲットRTに注釈することにより、VPLS Vに属し、ルートターゲットRTを持つ他のPESからNLRIを受け入れることにより機能することを発表します。PEは、ルートターゲットRTで宣伝したすべてのNLRIを撤回することにより、Vに参加しないことを発表します。
Once discovery is done, each pair of PEs in a VPLS must be able to establish (and tear down) pseudowires to each other, i.e., exchange (and withdraw) demultiplexors. This process is known as signaling. Signaling is also used to transmit certain characteristics of the pseudowires that a PE sets up for a given VPLS.
発見が完了すると、VPLのPEの各ペアは、互いに擬似ワイヤを確立（および解体する）ことができる必要があります。このプロセスはシグナリングとして知られています。シグナル伝達は、特定のVPLに対してPEがセットアップする擬似動物の特定の特性を送信するためにも使用されます。
Recall that a demultiplexor is used to distinguish among several different streams of traffic carried over a tunnel, each stream possibly representing a different service. In the case of VPLS, the demultiplexor not only says to which specific VPLS a packet belongs, but also identifies the ingress PE. The former information is used for forwarding the packet; the latter information is used for learning MAC addresses. The demultiplexor described here is an MPLS label. However, note that the PE-to-PE tunnels need not be MPLS tunnels.
Demultiplexorを使用して、トンネルの上に運ばれたいくつかの異なるトラフィックストリームを区別していることを思い出してください。各ストリームは、異なるサービスを表す可能性があります。VPLSの場合、Demultiplexorは、特定のVPLSがどのパケットが属しているかを示すだけでなく、侵入PEを識別します。前者の情報は、パケットの転送に使用されます。後者の情報は、MACアドレスの学習に使用されます。ここで説明するDemultiplexorはMPLSラベルです。ただし、PE-ToPEトンネルはMPLSトンネルである必要はないことに注意してください。
Using a distinct BGP Update message to send a demultiplexor to each remote PE would require the originating PE to send N such messages for N remote PEs. The solution described in this document allows a PE to send a single (common) Update message that contains demultiplexors for all the remote PEs, instead of N individual messages. Doing this reduces the control plane load both on the originating PE as well as on the BGP Route Reflectors that may be involved in distributing this Update to other PEs.
個別のBGP更新メッセージを使用して、各リモートPEにDemultiplexorを送信するには、NリモートPEに対してそのようなメッセージを送信するために発信されるPEが必要です。このドキュメントで説明されているソリューションにより、PEは、個々のメッセージではなく、すべてのリモートPEのデマルチプレクサーを含む単一の（共通の）更新メッセージを送信できます。これを行うと、コントロールプレーンの負荷は、このアップデートを他のPESに分配することに関与する可能性のあるBGPルートリフレクターの両方でも同様に減少します。
To accomplish this, we introduce the notion of "label blocks". A label block, defined by a label base LB and a VE block size VBS, is a contiguous set of labels {LB, LB+1, ..., LB+VBS-1}. Here's how label blocks work. All PEs within a given VPLS are assigned unique VE IDs as part of their configuration. A PE X wishing to send a VPLS update sends the same label block information to all other PEs. Each receiving PE infers the label intended for PE X by adding its (unique) VE ID to the label base. In this manner, each receiving PE gets a unique demultiplexor for PE X for that VPLS.
これを達成するために、「ラベルブロック」の概念を紹介します。ラベルベースLBとVEブロックサイズVBSで定義されたラベルブロックは、隣接するラベル{lb、lb 1、...、lb vbs-1}です。ラベルブロックが機能する方法は次のとおりです。特定のVPL内のすべてのPEには、構成の一部として一意のVE IDが割り当てられます。VPLSアップデートの送信を希望するPE Xは、同じラベルブロック情報を他のすべてのPEに送信します。PEを受信するそれぞれは、ラベルベースに（一意の）VE IDを追加することにより、PE X専用のラベルを推します。この方法で、PEを受信する各PEは、そのVPLのPE Xのユニークな非脱ult鎖を取得します。
This simple notion is enhanced with the concept of a VE block offset VBO. A label block defined by <LB, VBO, VBS> is the set {LB+VBO, LB+VBO+1, ..., LB+VBO+VBS-1}. Thus, instead of a single large label block to cover all VE IDs in a VPLS, one can have several label blocks, each with a different label base. This makes label block management easier, and also allows PE X to cater gracefully to a PE joining a VPLS with a VE ID that is not covered by the set of label blocks that PE X has already advertised.
この単純な概念は、VEブロックオフセットVBOの概念によって強化されています。<lb、vbo、vbs>で定義されたラベルブロックは、セット{lb vbo、lb vbo 1、...、lb vbo vbs-1}です。したがって、VPLS内のすべてのVE IDをカバーするための単一の大きなラベルブロックの代わりに、それぞれが異なるラベルベースを持ついくつかのラベルブロックを持つことができます。これにより、ラベルブロック管理が容易になり、PE XがPE Xがすでに宣伝しているラベルブロックのセットでカバーされていないVE IDでVPLに参加するPEに優雅に対応できます。
When a PE starts up, or is configured with a new VPLS instance, the BGP process may wish to wait to receive several advertisements for that VPLS instance from other PEs to improve the efficiency of label block allocation.
PEが起動した場合、または新しいVPLSインスタンスで構成されている場合、BGPプロセスは、ラベルブロック割り当ての効率を改善するために、他のPESからそのVPLSインスタンスのいくつかの広告を受信するのを待つことを望む場合があります。
The VPLS BGP NLRI described below, with a new AFI and SAFI (see [4]) is used to exchange VPLS membership and demultiplexors.
以下で説明するVPLS BGP NLRIは、新しいAFIとSAFI（[4]を参照）を使用して、VPLSメンバーシップとDemultiplexorsを交換するために使用されます。
A VPLS BGP NLRI has the following information elements: a VE ID, a VE Block Offset, a VE Block Size, and a label base. The format of the VPLS NLRI is given below. The AFI is the L2VPN AFI (25), and the SAFI is the VPLS SAFI (65). The Length field is in octets.
VPLS BGP NLRIには、VE ID、VEブロックオフセット、VEブロックサイズ、ラベルベースの情報要素があります。VPLS NLRIの形式を以下に示します。AFIはL2VPN AFI（25）であり、SAFIはVPLS Safi（65）です。長さフィールドはオクテットにあります。
+------------------------------------+
| Length (2 octets) |
+------------------------------------+
| Route Distinguisher (8 octets) |
+------------------------------------+
| VE ID (2 octets) |
+------------------------------------+
| VE Block Offset (2 octets) |
+------------------------------------+
| VE Block Size (2 octets) |
+------------------------------------+
| Label Base (3 octets) |
+------------------------------------+
Figure 2: BGP NLRI for VPLS Information
図2：VPLS情報のBGP NLRI
A PE participating in a VPLS must have at least one VE ID. If the PE is the VE, it typically has one VE ID. If the PE is connected to several u-PEs, it has a distinct VE ID for each u-PE. It may additionally have a VE ID for itself, if it itself acts as a VE for that VPLS. In what follows, we will call the PE announcing the VPLS NLRI PE-a, and we will assume that PE-a owns VE ID V (either belonging to PE-a itself or to a u-PE connected to PE-a).
VPLに参加するPEには、少なくとも1つのVE IDが必要です。PEがVEの場合、通常1つのVE IDがあります。PEがいくつかのU-PEに接続されている場合、各U-PEに対して異なるVE IDがあります。さらに、それ自体がそのVPLのVEとして機能する場合、それ自体のVE IDを持っている可能性があります。以下では、VPLS NLRI PE-Aを発表するPEを呼び出します。PE-AがVE ID Vを所有していると仮定します（PE-A自体に属するか、PE-Aに接続されたU-PEに属します）。
VE IDs are typically assigned by the network administrator. Their scope is local to a VPLS. A given VE ID should belong to only one PE, unless a CE is multi-homed (see Section 3.5).
VE IDは通常、ネットワーク管理者によって割り当てられます。それらの範囲はVPLのローカルです。特定のVE IDは、CEがマルチホームされていない限り、1つのPEのみに属する必要があります（セクション3.5を参照）。
A label block is a set of demultiplexor labels used to reach a given VE ID. A VPLS BGP NLRI with VE ID V, VE Block Offset VBO, VE Block Size VBS, and label base LB communicates to its peers the following:
ラベルブロックは、特定のVE IDに到達するために使用されるDemultiplexorラベルのセットです。VE ID V、VEブロックオフセットVBO、VEブロックサイズVBS、およびラベルベースLBを備えたVPLS BGP NLRIは、次の仲間と通信します。
label block for V: labels from LB to (LB + VBS - 1), and
remote VE set for V: from VBO to (VBO + VBS - 1).
V：VBOから（VBO VBS -1）のリモートVEセット。
There is a one-to-one correspondence between the remote VE set and the label block: VE ID (VBO + n) corresponds to label (LB + n).
リモートVEセットとラベルブロック：VE ID（VBO n）の間には、ラベル（LB N）に対応すると、1対1の対応があります。
Suppose PE-a is part of VPLS foo and makes an announcement with VE ID V, VE Block Offset VBO, VE Block Size VBS, and label base LB. If PE-b is also part of VPLS foo and has VE ID W, PE-b does the following:
PE-AがVPLS FOOの一部であり、VE ID V、VEブロックオフセットVBO、VEブロックサイズVBS、およびラベルベースLBで発表するとします。PE-BがVPLS FOOの一部であり、VE ID Wを持っている場合、PE-Bは次のとおりです。
1. checks if W is part of PE-a's 'remote VE set': if VBO <= W < VBO + VBS, then W is part of PE-a's remote VE set. If not, PE-b ignores this message, and skips the rest of this procedure.
1. WがPE-Aの「リモートVEセット」の一部であるかどうかを確認します。VBO<= W <VBO VBSの場合、WはPE-AのリモートVEセットの一部です。そうでない場合、PE-Bはこのメッセージを無視し、この手順の残りをスキップします。
2. sets up a PW to PE-a: the demultiplexor label to send traffic from PE-b to PE-a is computed as (LB + W - VBO).
2. PWをPE-A：PE-BからPE-Aに送信するDemultiplexorラベルを設定します。
3. checks if V is part of any 'remote VE set' that PE-b announced, i.e., PE-b checks if V belongs to some remote VE set that PE-b announced, say with VE Block Offset VBO', VE Block Size VBS', and label base LB'. If not, PE-b MUST make a new announcement as described in Section 3.3.
3. vがPE-Bが発表した「リモートVEセット」の一部であるかどうかをチェックします。つまり、PE-Bがvが発表されたリモートVEセットに属しているかどうかをチェックします。'、およびラベルベースlb'。そうでない場合、PE-Bはセクション3.3で説明されているように、新しい発表を行う必要があります。
4. sets up a PW from PE-a: the demultiplexor label over which PE-b should expect traffic from PE-a is computed as: (LB' + V - VBO').
4. PE-A：PE-BがPE-Aからのトラフィックが予想されることを期待するDemultiplexorラベルからPWを設定します。（lb 'v-vbo'）。
If Y withdraws an NLRI for V that X was using, then X MUST tear down its ends of the pseudowire between X and Y.
yがxが使用していたvのnlriを撤回した場合、xはxとyの間の擬似ワイヤの端を取り壊す必要があります。
The following extended attribute, the "Layer2 Info Extended Community", is used to signal control information about the pseudowires to be setup for a given VPLS. The extended community value is to be allocated by IANA (currently used value is 0x800A). This information includes the Encaps Type (type of encapsulation on the pseudowires), Control Flags (control information regarding the pseudowires), and the Maximum Transmission Unit (MTU) to be used on the pseudowires.
次の拡張属性である「Layer2 Info Extended Community」を使用して、特定のVPLSのセットアップされる擬似動物に関する情報を制御する情報を通知します。拡張されたコミュニティの価値は、IANAによって割り当てられます（現在使用されている値は0x800Aです）。この情報には、Encapsタイプ（擬似動物のカプセル化のタイプ）、コントロールフラグ（擬似動物に関する制御情報）、および擬似動物で使用される最大送信ユニット（MTU）が含まれます。
The Encaps Type for VPLS is 19.
VPLSのEncapsタイプは19です。
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octet) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
Figure 3: Layer2 Info Extended Community
図3：Layer2情報拡張コミュニティ
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
Figure 4: Control Flags Bit Vector
図4：コントロールフラグビットベクトル
With reference to Figure 4, the following bits in the Control Flags are defined; the remaining bits, designated MBZ, MUST be set to zero when sending and MUST be ignored when receiving this community.
図4を参照すると、コントロールフラグの次のビットが定義されています。MBZと指定された残りのビットは、送信時にゼロに設定する必要があり、このコミュニティを受け取るときは無視する必要があります。
Name Meaning
名前の意味
C A Control word [7] MUST or MUST NOT be present when sending VPLS packets to this PE, depending on whether C is 1 or 0, respectively
cコントロールワード[7]は、Cがそれぞれ1または0であるかどうかに応じて、VPLSパケットをこのPEに送信するときに存在する必要があります。
S Sequenced delivery of frames MUST or MUST NOT be used when sending VPLS packets to this PE, depending on whether S is 1 or 0, respectively
SがこのPEにそれぞれ1か0かに応じて、VPLSパケットをこのPEに送信するときに、フレームのシーケンスの配信を使用する必要があります。
To create a new VPLS, say VPLS foo, a network administrator must pick an RT for VPLS foo, say RT-foo. This will be used by all PEs that serve VPLS foo. To configure a given PE, say PE-a, to be part of VPLS foo, the network administrator only has to choose a VE ID V for PE-a. (If PE-a is connected to u-PEs, PE-a may be configured with more than one VE ID; in that case, the following is done for each VE ID). The PE may also be configured with a Route Distinguisher (RD); if not, it generates a unique RD for VPLS foo. Say the RD is RD-foo-a. PE-a then generates an initial label block and a remote VE set for V, defined by VE Block Offset VBO, VE Block Size VBS, and label base LB. These may be empty.
新しいVPLSを作成するには、VPLS FOO、ネットワーク管理者はVPLS FOOのRTを選択する必要があります。これは、VPLS fooを提供するすべてのPESによって使用されます。特定のPE、たとえばPE-AをVPLS FOOの一部に設定するには、ネットワーク管理者はPE-AのVE ID Vを選択するだけです。（PE-AがU-PEに接続されている場合、PE-Aは複数のVE IDで構成される場合があります。その場合、各VE IDに対して以下が実行されます）。PEは、Route distiminguisher（RD）で構成される場合もあります。そうでない場合は、VPLS FOOのユニークなRDを生成します。rdがrd-foo-aだとします。次に、PE-Aは、VEブロックオフセットVBO、VEブロックサイズVBS、およびラベルベースLBで定義された、初期ラベルブロックとVのリモートVEセットを生成します。これらは空かもしれません。
PE-a then creates a VPLS BGP NLRI with RD RD-foo-a, VE ID V, VE Block Offset VBO, VE Block Size VBS and label base LB. To this, it attaches a Layer2 Info Extended Community and an RT, RT-foo. It sets the BGP Next Hop for this NLRI as itself, and announces this NLRI to its peers. The Network Layer protocol associated with the Network Address of the Next Hop for the combination <AFI=L2VPN AFI, SAFI=VPLS SAFI> is IP; this association is required by [4], Section 5. If the value of the Length of the Next Hop field is 4, then the Next Hop contains an IPv4 address. If this value is 16, then the Next Hop contains an IPv6 address.
その後、PE-Aは、RD RD-Foo-A、VE ID V、VEブロックオフセットVBO、VEブロックサイズVBS、ラベルベースLBを備えたVPLS BGP NLRIを作成します。これには、Layer2 Info拡張コミュニティとRT、RT-Fooを添付します。このNLRIの次のホップをそれ自体として設定し、このNLRIを仲間に発表します。次のホップのネットワークアドレスに関連付けられたネットワークレイヤープロトコル<afi = l2vpn afi、safi = vpls safi> is ip;この関連付けは、[4]、セクション5で必要です。次のホップフィールドの長さの値が4の場合、次のホップにはIPv4アドレスが含まれます。この値が16の場合、次のホップにはIPv6アドレスが含まれています。
If PE-a hears from another PE, say PE-b, a VPLS BGP announcement with RT-foo and VE ID W, then PE-a knows that PE-b is a member of the same VPLS (auto-discovery). PE-a then has to set up its part of a VPLS pseudowire between PE-a and PE-b, using the mechanisms in Section 3.2. Similarly, PE-b will have discovered that PE-a is in the same VPLS, and PE-b must set up its part of the VPLS pseudowire. Thus, signaling and pseudowire setup is also achieved with the same Update message.
PE-AがRT-FOOとVE ID Wを使用したVPLS BGPの発表であるPE-B（たとえばPE-B）から聞いた場合、PE-AはPE-Bが同じVPLSのメンバーであることを知っています（自動配置）。その後、PE-Aは、セクション3.2のメカニズムを使用して、PE-AとPE-Bの間にVPLS Pseudowireの一部を設定する必要があります。同様に、PE-BはPE-Aが同じVPLSにあることを発見し、PE-BはVPLS Pseudowireの一部を設定する必要があります。したがって、同じ更新メッセージでシグナリングと擬似ワイヤのセットアップも実現されます。
If W is not in any remote VE set that PE-a announced for VE ID V in VPLS foo, PE-b will not be able to set up its part of the pseudowire to PE-a. To address this, PE-a can choose to withdraw the old announcement(s) it made for VPLS foo, and announce a new Update with a larger remote VE set and corresponding label block that covers all VE IDs that are in VPLS foo. This, however, may cause some service disruption. An alternative for PE-a is to create a new remote VE set and corresponding label block, and announce them in a new Update, without withdrawing previous announcements.
wがVPLS fooでVE ID VのためにPE-Aが発表したリモートVEセットにない場合、PE-BはPE-Aに擬似ワイヤの一部をセットアップできません。これに対処するために、PE-Aは、VPLS FOO用に作成した古い発表を撤回することを選択し、VPLS FOOにあるすべてのVE IDをカバーするより大きなリモートVEセットと対応するラベルブロックを備えた新しいアップデートを発表できます。ただし、これにより、サービスの混乱が生じる可能性があります。PE-Aの代替品は、新しいリモートVEセットと対応するラベルブロックを作成し、以前の発表を撤回することなく、新しいアップデートでそれらを発表することです。
If PE-a's configuration is changed to remove VE ID V from VPLS foo, then PE-a MUST withdraw all its announcements for VPLS foo that contain VE ID V. If all of PE-a's links to its CEs in VPLS foo go down, then PE-a SHOULD either withdraw all its NLRIs for VPLS foo or let other PEs in the VPLS foo know in some way that PE-a is no longer connected to its CEs.
PE-Aの構成がVPLS FOOからVE ID Vを削除するように変更された場合、PE-AはVE ID Vを含むVPLS FOOのすべての発表を撤回する必要があります。その後、PE-Aは、VPLS fooのすべてのNLRIを撤回するか、VPLS FOOの他のPESに、PE-AがCESに接続されなくなったことを何らかの方法で知らせる必要があります。
As in [14] and [6], the above auto-discovery and signaling functions are typically announced via I-BGP. This assumes that all the sites in a VPLS are connected to PEs in a single Autonomous System (AS).
[14]および[6]のように、上記の自動発見およびシグナル伝達機能は通常、I-BGPを介して発表されます。これは、VPLのすべてのサイトが単一の自律システム（AS）のPEに接続されていることを前提としています。
However, sites in a VPLS may connect to PEs in different ASes. This leads to two issues: 1) there would not be an I-BGP connection between those PEs, so some means of signaling across ASes is needed; and 2) there may not be PE-to-PE tunnels between the ASes.
ただし、VPLSのサイトは、異なるASEのPEに接続する場合があります。これは2つの問題につながります。1）それらのPE間にI-BGP接続がないため、ASEを横切る何らかのシグナル伝達が必要です。2）ASEの間にPE-ToPEトンネルはない場合があります。
A similar problem is solved in [6], Section 10. Three methods are suggested to address issue (1); all these methods have analogs in multi-AS VPLS.
同様の問題は、[6]、セクション10で解決されています。問題（1）に対処するために3つの方法が提案されています。これらのすべての方法には、Multi-AS VPLに類似しています。
Here is a diagram for reference:
参照の図は次のとおりです。
__________ ____________ ____________ __________
/ \ / \ / \ / \
\___/ AS 1 \ / AS 2 \___/
\ /
+-----+ +-------+ | +-------+ +-----+
| PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 |
+-----+ +-------+ | +-------+ +-----+
___ / \ ___
/ \ / \ / \
\__________/ \____________/ \____________/ \__________/
Figure 5: Inter-AS VPLS
図5：as inter-as vpls
As in the above reference, three methods for signaling inter-provider VPLS are given; these are presented in order of increasing scalability. Method (a) is the easiest to understand conceptually, and the easiest to deploy; however, it requires an Ethernet interconnect between the ASes, and both VPLS control and data plane state on the AS border routers (ASBRs). Method (b) requires VPLS control plane state on the ASBRs and MPLS on the AS-AS interconnect (which need not be Ethernet). Method (c) requires MPLS on the AS-AS interconnect, but no VPLS state of any kind on the ASBRs.
上記の参照と同様に、プロバイダー間VPLをシグナリングするための3つの方法が示されています。これらは、スケーラビリティを向上させる順に提示されます。方法（a）は、概念的に理解するのが最も簡単で、展開が最も簡単です。ただし、ASESとASボーダールーター（ASBR）のVPLS制御とデータプレーン状態の両方のイーサネットの相互接続が必要です。方法（b）には、AS-ASインターコネクト（イーサネットではない）でASBRSおよびMPLS上のVPLS制御プレーン状態が必要です。方法（c）には、AS-ASインターコネクトでMPLSが必要ですが、ASBRSにはいかなる種類のVPLS状態は必要ありません。
In this method, an AS Border Router (ASBR1) acts as a PE for all VPLSs that span AS1 and an AS to which ASBR1 is connected, such as AS2 here. The ASBR on the neighboring AS (ASBR2) is viewed by ASBR1 as a CE for the VPLSs that span AS1 and AS2; similarly, ASBR2 acts as a PE for this VPLS from AS2's point of view, and views ASBR1 as a CE.
この方法では、AS Border Router（ASBR1）は、AS1およびASBR1が接続されているASに及ぶすべてのVPLSのPEとして機能します。ASBRのASBR（ASBR2）は、ASBR1によってAS1およびAS2に及ぶVPLSSのCEと見なされています。同様に、ASBR2はAS2の観点からこのVPLのPEとして機能し、ASBR1をCEと見なします。
This method does not require MPLS on the ASBR1-ASBR2 link, but does require that this link carry Ethernet traffic and that there be a separate VLAN sub-interface for each VPLS traversing this link. It further requires that ASBR1 does the PE operations (discovery, signaling, MAC address learning, flooding, encapsulation, etc.) for all VPLSs that traverse ASBR1. This imposes a significant burden on ASBR1, both on the control plane and the data plane, which limits the number of multi-AS VPLSs.
この方法では、ASBR1-ASBR2リンクでMPLSを必要としませんが、このリンクがイーサネットトラフィックを運ぶ必要があり、このリンクを通過する各VPLSに個別のVLANサブインターフェイスがあることが必要です。さらに、ASBR1は、ASBR1を横断するすべてのVPLSに対してPE操作（発見、シグナル伝達、MACアドレス学習、洪水、カプセル化など）を行うことが必要です。これにより、ASBR1には、コントロールプレーンとデータプレーンの両方に大きな負担が課され、Multi-AS VPLSの数が制限されます。
Note that in general, there will be multiple connections between a pair of ASes, for redundancy. In this case, the Spanning Tree Protocol (STP) [15], or some other means of loop detection and prevention, must be run on each VPLS that spans these ASes, so that a loop-free topology can be constructed in each VPLS. This imposes a further burden on the ASBRs and PEs participating in those VPLSs, as these devices would need to run a loop detection algorithm for each such VPLS. How this may be achieved is outside the scope of this document.
一般に、冗長性のために、ASEのペア間に複数の接続があることに注意してください。この場合、スパニングツリープロトコル（STP）[15]、またはこれらのASESにまたがる各VPLでループの検出と予防の他の手段を実行する必要があり、各VPLでループフリーのトポロジを構築できるようにする必要があります。これらのデバイスは、これらのVPLSごとにループ検出アルゴリズムを実行する必要があるため、これらのVPLSに参加するASBRとPESにさらなる負担が課されます。これがどのように達成されるかは、このドキュメントの範囲外です。
This method requires I-BGP peerings between the PEs in AS1 and ASBR1 in AS1 (perhaps via route reflectors), an E-BGP peering between ASBR1 and ASBR2 in AS2, and I-BGP peerings between ASBR2 and the PEs in AS2. In the above example, PE1 sends a VPLS NLRI to ASBR1 with a label block and itself as the BGP nexthop; ASBR1 sends the NLRI to ASBR2 with new labels and itself as the BGP nexthop; and ASBR2 sends the NLRI to PE2 with new labels and itself as the nexthop. Correspondingly, there are three tunnels: T1 from PE1 to ASBR1, T2 from ASBR1 to ASBR2, and T3 from ASBR2 to PE2. Within each tunnel, the VPLS label to be used is determined by the receiving device; e.g., the VPLS label within T1 is a label from the label block that ASBR1 sent to PE1. The ASBRs are responsible for receiving VPLS packets encapsulated in a tunnel and performing the appropriate label swap operations described next so that the next receiving device can correctly identify and forward the packet.
この方法では、AS1のPESとAS1のASBR1の間のI-BGPピーリング（おそらくルートリフレクターを介して）、AS2のASBR1とASBR2の間のE-BGPピアリング、ASBR2とAS2のPES間のI-BGPピーリングが必要です。上記の例では、PE1はラベルブロックを持つVPLS NLRIをASBR1にBGP Nexthopとして送信します。ASBR1は、NLRIをASBR2に新しいラベルとBGP Nexthopとして送信します。ASBR2は、NLRIを新しいラベルとそれ自体でNexthopとしてPE2に送信します。それに対応して、3つのトンネルがあります：PE1からASBR1へのT1、ASBR1からASBR2へのT2、ASBR2からPE2へのT3。各トンネル内で、使用するVPLSラベルは受信デバイスによって決定されます。たとえば、T1内のVPLSラベルは、ASBR1がPE1に送信したラベルブロックのラベルです。ASBRは、トンネルにカプセル化されたVPLSパケットを受信し、次に受信デバイスがパケットを正しく識別して転送できるように、次に適切なラベルスワップ操作を実行する責任があります。
The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2 sends to PE2) is identical to the VPLS NLRI that PE1 sends to ASBR1, except for the label block. To be precise, the Length, the Route Distinguisher, the VE ID, the VE Block Offset, and the VE Block Size MUST be the same; the Label Base may be different. Furthermore, ASBR1 must also update its forwarding path as follows: if the Label Base sent by PE1 is L1, the Label-block Size is N, the Label Base sent by ASBR1 is L2, and the tunnel label from ASBR1 to PE1 is T, then ASBR1 must install the following in the forwarding path:
ASBR1がASBR2に送信するVPLS NLRI（およびASBR2がPE2に送信するNLRI）は、ラベルブロックを除き、PE1がASBR1に送信するVPLS NLRIと同一です。正確には、長さ、ルートの区別器、VE ID、VEブロックオフセット、およびVEブロックサイズは同じでなければなりません。ラベルベースは異なる場合があります。さらに、ASBR1も次のように転送パスを更新する必要があります。PE1から送信されたラベルベースがL1、ラベルブロックサイズがN、ASBR1から送信されたラベルベース、ASBR1からPE1までのトンネルラベルはT、次に、ASBR1は転送パスに以下をインストールする必要があります。
swap L2 with L1 and push T,
L2をL1と交換し、tを押します。
swap L2+1 with L1+1 and push T, ...
L2 1をL1 1と交換し、Tを押します...
swap L2+N-1 with L1+N-1 and push T.
L2 N-1をL1 N-1と交換し、Tを押します。
ASBR2 must act similarly, except that it may not need a tunnel label if it is directly connected with ASBR1.
ASBR2は、ASBR1に直接接続されている場合、トンネルラベルを必要としない場合を除き、同様に作用する必要があります。
When PE2 wants to send a VPLS packet to PE1, PE2 uses its VE ID to get the right VPLS label from ASBR2's label block for PE1, and uses a tunnel label to reach ASBR2. ASBR2 swaps the VPLS label with the label from ASBR1; ASBR1 then swaps the VPLS label with the label from PE1, and pushes a tunnel label to reach PE1.
PE2がVPLSパケットをPE1に送信する場合、PE2はVE IDを使用してPE1用のASBR2のラベルブロックから正しいVPLSラベルを取得し、トンネルラベルを使用してASBR2に到達します。ASBR2は、VPLSラベルをASBR1のラベルと交換します。ASBR1は、VPLSラベルをPE1のラベルと交換し、トンネルラベルを押してPE1に到達します。
In this method, one needs MPLS on the ASBR1-ASBR2 interface, but there is no requirement that the link layer be Ethernet. Furthermore, the ASBRs take part in distributing VPLS information. However, the data plane requirements of the ASBRs are much simpler than in method (a), being limited to label operations. Finally, the construction of loop-free VPLS topologies is done by routing decisions, viz. BGP path and nexthop selection, so there is no need to run the Spanning Tree Protocol on a per-VPLS basis. Thus, this method is considerably more scalable than method (a).
この方法では、ASBR1-ASBR2インターフェイスでMPLSが必要ですが、リンクレイヤーがイーサネットであるという要件はありません。さらに、ASBRSはVPLS情報の配布に参加します。ただし、ASBRのデータプレーン要件は、ラベル操作に限定されている方法（a）よりもはるかに単純です。最後に、ループフリーのVPLSトポロジの構築は、ルーティング決定によって行われます。BGPパスとNexthopの選択であるため、SpanningツリープロトコルをVPLSごとに実行する必要はありません。したがって、この方法は、方法（a）よりもかなりスケーラブルです。
In this method, there is a multi-hop E-BGP peering between the PEs (or preferably, a Route Reflector) in AS1 and the PEs (or Route Reflector) in AS2. PE1 sends a VPLS NLRI with labels and nexthop self to PE2; if this is via route reflectors, the BGP nexthop is not changed. This requires that there be a tunnel LSP from PE1 to PE2. This tunnel LSP can be created exactly as in [6], Section 10 (c), for example using E-BGP to exchange labeled IPv4 routes for the PE loopbacks.
この方法では、AS1のPES（またはできればルートリフレクター）とAS2のPES（またはルートリフレクター）の間にマルチホップE-BGPピアリングがあります。PE1は、ラベルを備えたVPLS NLRIを、Nexthop SelfをPE2に送信します。これがルートリフレクターを介している場合、BGP Nexthopは変更されません。これには、PE1からPE2へのトンネルLSPがあることが必要です。このトンネルLSPは、たとえばE-BGPを使用して、PEループバックのラベル付きIPv4ルートを交換するなど、[6]、セクション10（c）とまったく同じように作成できます。
When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS label corresponding to its own VE ID onto the packet. It then pushes the tunnel label(s) to reach PE2.
PE1がVPLSパケットをPE2に送信すると、独自のVE IDに対応するVPLSラベルをパケットにプッシュします。次に、トンネルラベルを押してPE2に到達します。
This method requires no VPLS information (in either the control or the data plane) on the ASBRs. The ASBRs only need to set up PE-to-PE tunnel LSPs in the control plane, and do label operations in the data plane. Again, as in the case of method (b), the construction of loop-free VPLS topologies is done by routing decisions, i.e., BGP path and nexthop selection, so there is no need to run the Spanning Tree Protocol on a per-VPLS basis. This option is likely to be the most scalable of the three methods presented here.
この方法では、ASBRのVPLS情報（コントロールまたはデータプレーン）は必要ありません。ASBRSは、コントロールプレーンにPE-ToPEトンネルLSPをセットアップし、データプレーンでラベル操作を行うだけです。繰り返しますが、方法（b）の場合と同様に、ループフリーのVPLSトポロジの構築は、ルーティング決定、つまりBGPパスとNexthop選択によって行われるため、VPLSごとにスパニングツリープロトコルを実行する必要はありません。基礎。このオプションは、ここに示されている3つの方法の中で最もスケーラブルである可能性があります。
In order to ease the allocation of VE IDs for a VPLS that spans multiple ASes, one can allocate ranges for each AS. For example, AS1 uses VE IDs in the range 1 to 100, AS2 from 101 to 200, etc. If there are 10 sites attached to AS1 and 20 to AS2, the allocated VE IDs could be 1-10 and 101 to 120. This minimizes the number of VPLS NLRIs that are exchanged while ensuring that VE IDs are kept unique.
複数のASESに及ぶVPLのVE IDの割り当てを容易にするために、ASごとに範囲を割り当てることができます。たとえば、AS1は1〜100の範囲でVE IDを使用し、AS2は101〜200までAS2を使用します。10個のサイトがAS1と20個からAS2に接続されている場合、割り当てられたVE IDは1〜10および101から120になる可能性があります。VE IDが一意に保たれるようにしながら、交換されるVPLS NLRIの数を最小化します。
In the above example, if AS1 needed more than 100 sites, then another range can be allocated to AS1. The only caveat is that there be no overlap between VE ID ranges among ASes. The exception to this rule is multi-homing, which is dealt with below.
上記の例では、AS1が100を超えるサイトを必要とする場合、別の範囲をAS1に割り当てることができます。唯一の注意点は、ASEの間のVE ID範囲間に重複がないことです。このルールの例外はマルチホミングで、以下で扱われます。
It is often desired to multi-home a VPLS site, i.e., to connect it to multiple PEs, perhaps even in different ASes. In such a case, the PEs connected to the same site can be configured either with the same VE ID or with different VE IDs. In the latter case, it is mandatory to run STP on the CE device, and possibly on the PEs, to construct a loop-free VPLS topology. How this can be accomplished is outside the scope of this document; however, the rest of this section will describe in some detail the former case. Note that multi-homing by the SP and STP on the CEs can co-exist; thus, it is recommended that the VPLS customer run STP if the CEs are able to.
多くの場合、マルチホームのVPLSサイト、つまり、おそらく異なるASEでも複数のPEに接続することが望まれます。そのような場合、同じサイトに接続されているPESは、同じVE IDまたは異なるVE IDで構成できます。後者の場合、CEデバイス、場合によってはPESでSTPを実行して、ループフリーのVPLSトポロジを構築することが必須です。これをどのように達成できるかは、このドキュメントの範囲外です。ただし、このセクションの残りの部分では、前者のケースについて詳細に説明します。CES上のSPおよびSTPによるマルチホミングが共存できることに注意してください。したがって、CESができる場合は、VPLSの顧客がSTPを実行することをお勧めします。
In the case where the PEs connected to the same site are assigned the same VE ID, a loop-free topology is constructed by routing mechanisms, in particular, by BGP path selection. When a BGP speaker receives two equivalent NLRIs (see below for the definition), it applies standard path selection criteria such as Local Preference and AS Path Length to determine which NLRI to choose; it MUST pick only one. If the chosen NLRI is subsequently withdrawn, the BGP speaker applies path selection to the remaining equivalent VPLS NLRIs to pick another; if none remain, the forwarding information associated with that NLRI is removed.
同じサイトに接続されたPESに同じVE IDが割り当てられている場合、ループフリーのトポロジーは、特にBGPパス選択によってルーティングメカニズムによって構築されます。BGPスピーカーが2つの同等のNLRIを受信すると（定義については以下を参照）、局所選好やパスの長さなどの標準的なパス選択基準を適用して、選択するNLRIを決定します。1つだけを選択する必要があります。選択したNLRIがその後撤回された場合、BGPスピーカーは残りの等価VPLS NLRIにパス選択を適用して別のものを選択します。何も残っていない場合、そのNLRIに関連する転送情報が削除されます。
Two VPLS NLRIs are considered equivalent from a path selection point of view if the Route Distinguisher, the VE ID, and the VE Block Offset are the same. If two PEs are assigned the same VE ID in a given VPLS, they MUST use the same Route Distinguisher, and they SHOULD announce the same VE Block Size for a given VE Offset.
2つのVPLS nlrisは、ルートの区別器、VE ID、およびVEブロックオフセットが同じである場合、パス選択点と同等と見なされます。2つのPEが特定のVPLで同じVE IDを割り当てられている場合、それらは同じルート違いを使用する必要があり、特定のVEオフセットに対して同じVEブロックサイズを発表する必要があります。
This section discusses how one can scale the VPLS control plane when using BGP. There are at least three aspects of scaling the control plane:
このセクションでは、BGPを使用するときにVPLSコントロールプレーンをどのようにスケーリングできるかについて説明します。コントロールプレーンのスケーリングには、少なくとも3つの側面があります。
1. alleviating the full mesh connectivity requirement among VPLS BGP speakers;
1. VPLS BGPスピーカー間の完全なメッシュ接続要件を緩和する。
2. limiting BGP VPLS message passing to just the interested speakers rather than all BGP speakers; and
2. すべてのBGPスピーカーではなく、関心のあるスピーカーのみにBGP VPLSメッセージを制限する。と
3. simplifying the addition and deletion of BGP speakers, whether for VPLS or other applications.
3. VPLSまたはその他のアプリケーションの場合、BGPスピーカーの追加と削除を簡素化します。
Fortunately, the use of BGP for Internet routing as well as for IP VPNs has yielded several good solutions for all these problems. The basic technique is hierarchy, using BGP Route Reflectors (RRs) [8]. The idea is to designate a small set of Route Reflectors that are themselves fully meshed, and then establish a BGP session between each BGP speaker and one or more RRs. In this way, there is no need for direct full mesh connectivity among all the BGP speakers. If the particular scaling needs of a provider require a large number of RRs, then this technique can be applied recursively: the full mesh connectivity among the RRs can be brokered by yet another level of RRs. The use of RRs solves problems 1 and 3 above.
幸いなことに、インターネットルーティングとIP VPNSにBGPを使用すると、これらすべての問題に対していくつかの優れたソリューションが得られました。基本的な手法は、BGPルートリフレクター（RRS）を使用して階層です[8]。アイデアは、それ自体が完全にメッシュ化された小さなルートリフレクターのセットを指定し、各BGPスピーカーと1つ以上のRRの間にBGPセッションを確立することです。このようにして、すべてのBGPスピーカーの間で直接フルメッシュ接続を必要としません。プロバイダーの特定のスケーリングニーズに多数のRRSが必要な場合、この手法は再帰的に適用できます。RRS間の完全なメッシュ接続は、さらに別のレベルのRRSによって仲介される可能性があります。RRSの使用は、上記の問題1と3を解決します。
It is important to note that RRs, as used for VPLS and VPNs, are purely a control plane technique. The use of RRs introduces no data plane state and no data plane forwarding requirements on the RRs, and does not in any way change the forwarding path of VPLS traffic. This is in contrast to the technique of Hierarchical VPLS defined in [10].
VPLSおよびVPNに使用されるRRSは、純粋にコントロールプレーン技術であることに注意することが重要です。RRSを使用すると、RRSにデータプレーン状態が導入されず、データプレーン転送要件がありません。これは、[10]で定義されている階層VPLの手法とは対照的です。
Another consequence of this approach is that it is not required that one set of RRs handles all BGP messages, or that a particular RR handle all messages from a given PE. One can define several sets of RRs, for example, a set to handle VPLS, another to handle IP VPNs, and another for Internet routing. Another partitioning could be to have some subset of VPLSs and IP VPNs handled by one set of RRs, and another subset of VPLSs and IP VPNs handled by another set of RRs; the use of Route Target Filtering (RTF), described in [12], can make this simpler and more effective.
このアプローチのもう1つの結果は、RRSの1つのセットがすべてのBGPメッセージを処理すること、または特定のRRが特定のPEからのすべてのメッセージを処理する必要がないことです。RRのいくつかのセットを定義できます。たとえば、VPLを処理するセット、もう1つはIP VPNを処理するセット、もう1つはインターネットルーティング用です。別のパーティション化は、1つのRRSによって処理されるVPLSSとIP VPNのサブセットと、別のRRSセットによって処理されるVPLSSおよびIP VPNの別のサブセットを処理することです。[12]に記載されているルートターゲットフィルタリング（RTF）の使用は、これをよりシンプルで効果的にすることができます。
Finally, problem 2 (that of limiting BGP VPLS message passing to just the interested BGP speakers) is addressed by the use of RTF. This technique is orthogonal to the use of RRs, but works well in conjunction with RRs. RTF is also very effective in inter-AS VPLS; more details on how RTF works and its benefits are provided in [12].
最後に、問題2（関心のあるBGPスピーカーのみに渡されるBGP VPLSメッセージを制限すること）は、RTFの使用によって対処されます。この手法は、RRSの使用に対して直交していますが、RRSと組み合わせてうまく機能します。RTFは、VPLS間でも非常に効果的です。RTFの仕組みとその利点の詳細は[12]で提供されています。
It is worth mentioning an aspect of the control plane that is often a source of confusion. No MAC addresses are exchanged via BGP. All MAC address learning and aging is done in the data plane individually by each PE. The only task of BGP VPLS message exchange is auto-discovery and label exchange.
多くの場合、混乱の原因であるコントロールプレーンの側面に言及する価値があります。BGPを介してMACアドレスは交換されません。すべてのMACアドレス学習と老化は、各PEによって個別にデータプレーンで行われます。BGP VPLSメッセージ交換の唯一のタスクは、自動発見とラベル交換です。
Thus, BGP processing for VPLS occurs when
したがって、VPLSのBGP処理はいつに発生します
1. a PE joins or leaves a VPLS; or
1. PEがVPLSに参加または出発します。また
2. a failure occurs in the network, bringing down a PE-PE tunnel or a PE-CE link.
2. ネットワークで障害が発生し、PE-PEトンネルまたはPE-CEリンクを倒します。
These events are relatively rare, and typically, each such event causes one BGP update to be generated. Coupled with BGP's messaging efficiency when used for signaling VPLS, these observations lead to the conclusion that BGP as a control plane for VPLS will scale quite well in terms of both processing and memory requirements.
これらのイベントは比較的まれであり、通常、そのようなイベントはそれぞれ1つのBGPアップデートを生成します。VPLSのシグナル伝達に使用される場合のBGPのメッセージング効率と相まって、これらの観察結果は、VPLSのコントロールプレーンとしてのBGPが処理要件とメモリ要件の両方の点で非常によくスケーリングされるという結論につながります。
This section discusses two aspects of the data plane for PEs and u-PEs implementing VPLS: encapsulation and forwarding.
このセクションでは、VPLSを実装するPESおよびU-PESのデータプレーンの2つの側面について説明します：カプセル化と転送。
Ethernet frames received from CE devices are encapsulated for transmission over the packet switched network connecting the PEs. The encapsulation is as in [7].
CEデバイスから受信したイーサネットフレームは、PESを接続するパケットスイッチネットワーク上の送信用にカプセル化されています。カプセル化は[7]のようです。
VPLS packets are classified as belonging to a given service instance and associated forwarding table based on the interface over which the packet is received. Packets are forwarded in the context of the service instance based on the destination MAC address. The former mapping is determined by configuration. The latter is the focus of this section.
VPLSパケットは、パケットが受信されるインターフェイスに基づいて、特定のサービスインスタンスおよび関連する転送テーブルに属するものとして分類されます。パケットは、宛先MACアドレスに基づいてサービスインスタンスのコンテキストで転送されます。前者のマッピングは、構成によって決定されます。後者はこのセクションの焦点です。
As was mentioned earlier, the key distinguishing feature of VPLS is that it is a multipoint service. This means that the entire Service Provider network should appear as a single logical learning bridge for each VPLS that the SP network supports. The logical ports for the SP "bridge" are the customer ports as well as the pseudowires on a VE. Just as a learning bridge learns MAC addresses on its ports, the SP bridge must learn MAC addresses at its VEs.
前述のように、VPLSの重要な際立った特徴は、それがマルチポイントサービスであることです。これは、SPネットワークがサポートする各VPLの単一の論理学習ブリッジとしてサービスプロバイダーネットワーク全体が表示されることを意味します。SP「ブリッジ」の論理ポートは、顧客ポートとVE上の擬似ワイヤです。Learning BridgeがポートでMACアドレスを学習するように、SPブリッジはVESでMACアドレスを学習する必要があります。
Learning consists of associating source MAC addresses of packets with the (logical) ports on which they arrive; this association is the Forwarding Information Base (FIB). The FIB is used for forwarding packets. For example, suppose the bridge receives a packet with source MAC address S on (logical) port P. If subsequently, the bridge receives a packet with destination MAC address S, it knows that it should send the packet out on port P.
学習は、パケットのソースMacアドレスを（論理的な）ポートが到着するポートに関連付けることで構成されています。この関連は、転送情報ベース（FIB）です。FIBは、パケットの転送に使用されます。たとえば、ブリッジが（論理）ポートPのソースMACアドレスsを備えたパケットを受け取るとします。その後、ブリッジが宛先MACアドレスsを備えたパケットを受け取ると、ポートPでパケットを送信することがわかっています。
If a VE learns a source MAC address S on logical port P, then later sees S on a different port P', then the VE MUST update its FIB to reflect the new port P'. A VE MAY implement a mechanism to damp flapping of source ports for a given MAC address.
VEが論理ポートPでソースMACアドレスを学習する場合、その後、別のポートP 'でSがSを確認する場合、VEは新しいポートP'を反映するためにそのFIBを更新する必要があります。VEは、特定のMACアドレスのソースポートの羽ばたきを湿らせるメカニズムを実装する場合があります。
VPLS PEs SHOULD have an aging mechanism to remove a MAC address associated with a logical port, much the same as learning bridges do. This is required so that a MAC address can be relearned if it "moves" from a logical port to another logical port, either because the station to which that MAC address belongs really has moved or because of a topology change in the LAN that causes this MAC address to arrive on a new port. In addition, aging reduces the size of a VPLS MAC table to just the active MAC addresses, rather than all MAC addresses in that VPLS.
VPLS PESには、学習ブリッジが行うのとほぼ同じ論理ポートに関連付けられたMACアドレスを削除する老化メカニズムが必要です。MACアドレスが論理ポートから別の論理ポートに「移動」する場合、MACアドレスを再学習できるようにこれが必要です。新しいポートに到着するMacアドレス。さらに、老化は、VPLSのすべてのMACアドレスではなく、VPLS MacテーブルのサイズをアクティブなMACアドレスのみに縮小します。
The "age" of a source MAC address S on a logical port P is the time since it was last seen as a source MAC on port P. If the age exceeds the aging time T, S MUST be flushed from the FIB. This of course means that every time S is seen as a source MAC address on port P, S's age is reset.
論理ポートPのソースMACアドレスSの「年齢」は、ポートPのソースMACとして最後に見られた時期です。年齢が老化時間tを超えた場合、SはFIBから洗い流されなければなりません。もちろん、SがポートPのソースMACアドレスと見なされるたびに、Sの年齢がリセットされることを意味します。
An implementation SHOULD provide a configurable knob to set the aging time T on a per-VPLS basis. In addition, an implementation MAY accelerate aging of all MAC addresses in a VPLS if it detects certain situations, such as a Spanning Tree topology change in that VPLS.
実装では、老化時間TをVPLSごとに設定するための構成可能なノブを提供する必要があります。さらに、実装は、VPLSのスパニングツリートポロジーの変更など、特定の状況を検出する場合、VPLSのすべてのMACアドレスの老化を加速する場合があります。
When a bridge receives a packet to a destination that is not in its FIB, it floods the packet on all the other ports. Similarly, a VE will flood packets to an unknown destination to all other VEs in the VPLS.
ブリッジがFIBにない宛先へのパケットを受け取ると、他のすべてのポートにパケットがあふれます。同様に、VEはVPLSの他のすべてのVESの未知の目的地にパケットをあふれさせます。
In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the destination MAC address on the frame was not in PE2's FIB (for that VPLS), then PE2 would be responsible for flooding that frame to every other PE in the same VPLS. On receiving that frame, PE1 would be responsible for further flooding the frame to CE1 and CE5 (unless PE1 knew which CE "owned" that MAC address).
上記の図1では、CE2がイーサネットフレームをPE2に送信し、フレームの宛先MACアドレスがPE2のFIB（そのVPLの場合）ではない場合、PE2は同じVPLの他のすべてのPEにそのフレームをフラッディングする責任があります。。そのフレームを受信すると、PE1はフレームをCE1とCE5にさらに浸水させる責任があります（PE1がそのMACアドレスを「所有している」ことを知っていない限り）。
On the other hand, if PE3 received the frame, it could delegate further flooding of the frame to its u-PE. If PE3 was connected to two u-PEs, it would announce that it has two u-PEs. PE3 could either announce that it is incapable of flooding, in which case it would receive two frames, one for each u-PE, or it could announce that it is capable of flooding, in which case it would receive one copy of the frame, which it would then send to both u-PEs.
一方、PE3がフレームを受け取った場合、フレームのさらなる洪水をU-PEに委任する可能性があります。PE3が2つのU-PEに接続されている場合、2つのU-PESがあることを発表します。PE3は、洪水ができないことを発表することができます。その場合、U-PEごとに2つのフレームを受け取るか、洪水が可能であることを発表する可能性があります。その後、両方のU-PEに送信されます。
There is a well-known broadcast MAC address. An Ethernet frame whose destination MAC address is the broadcast MAC address must be sent to all stations in that VPLS. This can be accomplished by the same means that is used for flooding.
有名なブロードキャストMACアドレスがあります。宛先MACアドレスがブロードキャストMACアドレスであるイーサネットフレームは、そのVPLのすべてのステーションに送信する必要があります。これは、洪水に使用されるのと同じ手段によって達成できます。
There is also an easily recognized set of "multicast" MAC addresses. Ethernet frames with a destination multicast MAC address MAY be broadcast to all stations; a VE MAY also use certain techniques to restrict transmission of multicast frames to a smaller set of receivers, those that have indicated interest in the corresponding multicast group. Discussion of this is outside the scope of this document.
また、「マルチキャスト」MACアドレスの簡単に認識されたセットもあります。宛先マルチキャストMACアドレスを備えたイーサネットフレームは、すべてのステーションにブロードキャストできます。VEは、特定の手法を使用して、マルチキャストフレームの送信を、対応するマルチキャストグループに関心を示しているレシーバーの小さなセットへの送信を制限する場合があります。これについての議論は、このドキュメントの範囲外です。
When a PE capable of flooding (say PEx) receives a broadcast Ethernet frame, or one with an unknown destination MAC address, it must flood the frame. If the frame arrived from an attached CE, PEx must send a copy of the frame to every other attached CE, as well as to all other PEs participating in the VPLS. If, on the other hand, the frame arrived from another PE (say PEy), PEx must send a copy of the packet only to attached CEs. PEx MUST NOT send the frame to other PEs, since PEy would have already done so. This notion has been termed "split horizon" forwarding and is a consequence of the PEs being logically fully meshed for VPLS.
Split horizon forwarding rules apply to broadcast and multicast packets, as well as packets to an unknown MAC address.
Split Horizonの転送ルールは、ブロードキャストパケットとマルチキャストパケットに適用され、パケットは未知のMacアドレスに適用されます。
The key for normal Ethernet MAC learning is usually just the (6-octet) MAC address. This is called "unqualified learning". However, it is also possible that the key for learning includes the VLAN tag when present; this is called "qualified learning".
通常のイーサネットMAC学習のキーは、通常、（6オクセット）MACアドレスにすぎません。これは「資格のない学習」と呼ばれます。ただし、学習の鍵には、存在するときにVLANタグが含まれる可能性もあります。これは「資格のある学習」と呼ばれます。
In the case of VPLS, learning is done in the context of a VPLS instance, which typically corresponds to a customer. If the customer uses VLAN tags, one can make the same distinctions of qualified and unqualified learning. If the key for learning within a VPLS is just the MAC address, then this VPLS is operating under unqualified learning. If the key for learning is (customer VLAN tag + MAC address), then this VPLS is operating under qualified learning.
VPLSの場合、学習は通常、顧客に対応するVPLSインスタンスのコンテキストで行われます。顧客がVLANタグを使用している場合、資格のない学習と資格のない学習の同じ区別を作成できます。VPLS内での学習のキーがMACアドレスにすぎない場合、このVPLSは資格のない学習の下で動作しています。学習のキーが（Customer VLAN Tag Macアドレス）である場合、このVPLSは資格のある学習の下で動作しています。
Choosing between qualified and unqualified learning involves several factors, the most important of which is whether one wants a single global broadcast domain (unqualified) or a broadcast domain per VLAN (qualified). The latter makes flooding and broadcasting more efficient, but requires larger MAC tables. These considerations apply equally to normal Ethernet forwarding and to VPLS.
適格な学習と資格のない学習のいずれかを選択するには、いくつかの要因が含まれます。その中で最も重要なのは、単一のグローバルブロードキャストドメイン（資格のない）またはVLANごとのブロードキャストドメイン（資格）を必要とするかどうかです。後者は洪水と放送をより効率的にしますが、より大きなMacテーブルが必要です。これらの考慮事項は、通常のイーサネット転送とVPLに等しく適用されます。
In order to offer different Classes of Service within a VPLS, an implementation MAY choose to map 802.1p bits in a customer Ethernet frame with a VLAN tag to an appropriate setting of EXP bits in the pseudowire and/or tunnel label, allowing for differential treatment of VPLS frames in the packet switched network.
VPLS内でさまざまなクラスのサービスを提供するために、実装は、VLANタグを備えた顧客イーサネットフレームの802.1pビットを、擬似ワイヤーおよび/またはトンネルラベルの適切なexpビットにマッピングすることを選択できます。パケットスイッチネットワーク内のVPLSフレーム。
To be useful, an implementation SHOULD allow this mapping function to be different for each VPLS, as each VPLS customer may have its own view of the required behavior for a given setting of 802.1p bits.
各VPLS顧客が802.1pビットの特定の設定に必要な動作について独自のビューを持っている可能性があるため、実装を使用すると、このマッピング機能がVPLごとに異なることができます。
In deploying a network that supports VPLS, the SP must decide what functions the VPLS-aware device closest to the customer (the VE) supports. The default case described in this document is that the VE is a PE. However, there are a number of reasons that the VE might be a device that does all the Layer 2 functions (such as MAC address learning and flooding), and a limited set of Layer 3 functions (such as communicating to its PE), but, for example, doesn't do full-fledged discovery and PE-to-PE signaling. Such a device is called a "u-PE".
VPLSをサポートするネットワークを展開する際に、SPは顧客に最も近いVPLS認識デバイスがサポートする機能を決定する必要があります。このドキュメントで説明されているデフォルトのケースは、VEがPEであることです。ただし、VEがすべてのレイヤー2機能（MACアドレス学習や洪水など）を実行するデバイスと、レイヤー3機能の限られたセット（PEとの通信など）である可能性があるため、いくつかの理由があります。、たとえば、本格的な発見やPE-ToPEシグナル伝達は行われません。このようなデバイスは「U-PE」と呼ばれます。
As both of these cases have benefits, one would like to be able to "mix and match" these scenarios. The signaling mechanism presented here allows this. For example, in a given provider network, one PE may be directly connected to CE devices, another may be connected to u-PEs that are connected to CEs, and a third may be connected directly to a customer over some interfaces and to u-PEs over others. All these PEs perform discovery and signaling in the same manner. How they do learning and forwarding depends on whether or not there is a u-PE; however, this is a local matter, and is not signaled. However, the details of the operation of a u-PE and its interactions with PEs and other u-PEs are beyond the scope of this document.
これらのケースには両方とも利点があるため、これらのシナリオを「混合して一致させる」ことができるようにしたいと考えています。ここに示されているシグナル伝達メカニズムはこれを可能にします。たとえば、特定のプロバイダーネットワークでは、1つのPEがCEデバイスに直接接続され、別のPEがCESに接続されているU-PEに接続される場合があり、3分の1はいくつかのインターフェイスを介して顧客に直接接続できます。他の人よりもペス。これらのすべてのPEは、同じ方法で発見とシグナル伝達を行います。彼らがどのように学習と転送を行うかは、U-PEがあるかどうかに依存します。ただし、これは局所的な問題であり、信号はありません。ただし、U-PEの操作の詳細とPESおよびその他のU-PEとの相互作用は、このドキュメントの範囲を超えています。
The focus in Virtual Private LAN Service is the privacy of data, i.e., that data in a VPLS is only distributed to other nodes in that VPLS and not to any external agent or other VPLS. Note that VPLS does not offer confidentiality, integrity, or authentication: VPLS packets are sent in the clear in the packet switched network, and a man-in-the-middle can eavesdrop, and may be able to inject packets into the data stream. If security is desired, the PE-to-PE tunnels can be IPsec tunnels. For more security, the end systems in the VPLS sites can use appropriate means of encryption to secure their data even before it enters the Service Provider network.
仮想プライベートLANサービスの焦点は、データのプライバシーです。つまり、VPLSのデータは、そのVPLの他のノードにのみ分散され、外部エージェントや他のVPLには分散されていません。VPLSは機密性、整合性、または認証を提供しないことに注意してください。VPLSパケットは、パケットスイッチネットワーク内のクリアで送信され、中間者は盗聴でき、パケットをデータストリームに挿入できる場合があります。セキュリティが必要な場合、PE-ToPEトンネルはIPSECトンネルになる可能性があります。より多くのセキュリティのために、VPLSサイトの最終システムは、サービスプロバイダーネットワークに入る前であっても、適切な暗号化手段を使用してデータを保護することができます。
There are two aspects to achieving data privacy in a VPLS: securing the control plane and protecting the forwarding path. Compromise of the control plane could result in a PE sending data belonging to some VPLS to another VPLS, or blackholing VPLS data, or even sending it to an eavesdropper; none of which are acceptable from a data privacy point of view. Since all control plane exchanges are via BGP, techniques such as in [2] help authenticate BGP messages, making it harder to spoof updates (which can be used to divert VPLS traffic to the wrong VPLS) or withdraws (denial-of-service attacks). In the multi-AS methods (b) and (c) described in Section 3, this also means protecting the inter-AS BGP sessions, between the ASBRs, the PEs, or the Route Reflectors. One can also use the techniques described in Section 10 (b) and (c) of [6], both for the control plane and the data plane. Note that [2] will not help in keeping VPLS labels private -- knowing the labels, one can eavesdrop on VPLS traffic. However, this requires access to the data path within a Service Provider network.
VPLSでデータプライバシーを達成するには、コントロールプレーンの確保と転送パスの保護という2つの側面があります。コントロールプレーンの妥協により、一部のVPLSに属するデータを別のVPLに送信したり、Blackholing VPLSデータを送信したり、盗聴者に送信したりする可能性があります。データのプライバシーの観点から受け入れられるものはありません。すべてのコントロールプレーンの交換はBGPを介して行われるため、[2]などの手法はBGPメッセージの認証に役立ち、更新（間違ったVPLSへのトラフィックを迂回するために使用できます）または撤回するのが難しくなります（サービス拒否攻撃））。セクション3で説明されているMulti-ASメソッド（b）および（c）では、ASBR、PES、またはルートリフレクターの間のBGP間セッションを保護することも意味します。また、[6]のセクション10（b）および（c）で説明されている手法を使用して、コントロールプレーンとデータプレーンの両方で使用することもできます。[2]は、VPLSラベルをプライベートに保つのに役立ちません。ラベルを知って、VPLSトラフィックを盗聴できることを知っています。ただし、サービスプロバイダーネットワーク内のデータパスへのアクセスが必要です。
There can also be misconfiguration leading to unintentional connection of CEs in different VPLSs. This can be caused, for example, by associating the wrong Route Target with a VPLS instance. This problem, shared by [6], is for further study.
また、さまざまなVPLSのCESの意図的ではない接続につながる誤った構成もあります。これは、たとえば、間違ったルートターゲットをVPLSインスタンスに関連付けることで引き起こす可能性があります。[6]で共有されるこの問題は、さらなる研究のためです。
Protecting the data plane requires ensuring that PE-to-PE tunnels are well-behaved (this is outside the scope of this document), and that VPLS labels are accepted only from valid interfaces. For a PE, valid interfaces comprise links from P routers. For an ASBR, a valid interface is a link from an ASBR in an AS that is part of a given VPLS. It is especially important in the case of multi-AS VPLSs that one accept VPLS packets only from valid interfaces.
データプレーンを保護するには、PE-ToPEトンネルが行方不明になっていることを保証する必要があります（これはこのドキュメントの範囲外です）、VPLSラベルは有効なインターフェイスからのみ受け入れられます。PEの場合、有効なインターフェイスはPルーターからのリンクを構成します。ASBRの場合、有効なインターフェイスは、特定のVPLの一部であるASのASBRからのリンクです。Multi-AS VPLSSの場合、有効なインターフェイスからのみVPLSパケットを受け入れることが特に重要です。
MPLS-in-IP and MPLS-in-GRE tunneling are specified in [3]. If it is desired to use such tunnels to carry VPLS packets, then the security considerations described in Section 8 of that document must be fully understood. Any implementation of VPLS that allows VPLS packets to be tunneled as described in that document MUST contain an implementation of IPsec that can be used as therein described. If the tunnel is not secured by IPsec, then the technique of IP address filtering at the border routers, described in Section 8.2 of that document, is the only means of ensuring that a packet that exits the tunnel at a particular egress PE was actually placed in the tunnel by the proper tunnel head node (i.e., that the packet does not have a spoofed source address). Since border routers frequently filter only source addresses, packet filtering may not be effective unless the egress PE can check the IP source address of any tunneled packet it receives, and compare it to a list of IP addresses that are valid tunnel head addresses. Any implementation that allows MPLS-in-IP and/or MPLS-in-GRE tunneling to be used without IPsec MUST allow the egress PE to validate in this manner the IP source address of any tunneled packet that it receives.
MPLS-in-IPおよびMPLS-in-greトンネルは[3]で指定されています。このようなトンネルを使用してVPLSパケットを運ぶことが望ましい場合は、そのドキュメントのセクション8で説明したセキュリティ上の考慮事項を完全に理解する必要があります。そのドキュメントで説明されているように、VPLSパケットをトンネル化できるようにするVPLの実装は、そのように使用できるIPSECの実装を含める必要があります。トンネルがIPSECによって固定されていない場合、そのドキュメントのセクション8.2で説明されているボーダールーターでのIPアドレスフィルタリングの手法は、特定の出口PEでトンネルを出るパケットが実際に配置されたことを保証する唯一の手段です。適切なトンネルヘッドノードによるトンネルでは（つまり、パケットにスプーフィングされたソースアドレスがないこと）。ボーダールーターは頻繁にソースアドレスのみをフィルタリングするため、出力PEが受信したトンネルパケットのIPソースアドレスを確認し、有効なトンネルヘッドアドレスであるIPアドレスのリストと比較できない限り、パケットフィルタリングは効果的ではない場合があります。IPSECなしでMPLS-in-IPおよび/またはMPLS-in-greのトンネリングを使用できるようにする実装は、出力PEが受信したトンネルパケットのIPソースアドレスをこの方法で検証できるようにする必要があります。
IANA allocated value (25) for AFI for L2VPN information. This should be the same as the AFI requested by [11].
IANAは、L2VPN情報のAFIに値（25）を割り当てました。これは、[11]で要求されたAFIと同じでなければなりません。
IANA allocated an extended community value (0x800a) for the Layer2 Info Extended Community.
IANAは、Layer2 Info Extended Communityに拡張コミュニティ価値（0x800A）を割り当てました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[2] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[3] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[3] Worster、T.、Rekhter、Y。、およびE. Rosen、「IPまたは一般的なルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[4] Bates, T., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[4] Bates、T.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[5] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[5] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP拡張コミュニティ属性」、RFC 4360、2006年2月。
[6] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[6] Rosen、E。and Y. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[7] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[7] Martini、L.、Rosen、E.、El-Aawar、N。、およびG. Heron、「MPLSネットワーク上のイーサネットの輸送のためのカプセル化方法」、RFC 4448、2006年4月。
[8] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[8] Bates、T.、Chen、E。、およびR. Chandra、「BGPルートリフレクション：フルメッシュ内部BGP（IBGP）の代替」、RFC 4456、2006年4月。
[9] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[9] Andersson、L。およびE. Rosen、「レイヤー2の仮想プライベートネットワーク（L2VPNS）のフレームワーク」、RFC 4664、2006年9月。
[10] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[10] Lasserre、M.、ed。およびV. Kompella編、「ラベル分布プロトコル（LDP）シグナル伝達を使用した仮想プライベートLANサービス（VPLS）」、RFC 4762、2007年1月。
[11] Ould-Brahim, H., "Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs", Work in Progress, April 2006.
[11] Oould-Brahim、H。、「VRベースのレイヤー-3 VPNSの自動配記メカニズムとしてBGPを使用」、2006年4月、進行中の作業。
[12] Marques, P., "Constrained VPN Route Distribution", Work in Progress, June 2005.
[12] Marques、P。、「制約付きVPNルート分布」、2005年6月、進行中の作業。
[13] 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.
[13] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、2006年4月、RFC 4447。
[14] Kompella, K., "Layer 2 VPNs Over Tunnels", Work in Progress, January 2006.
[14] Kompella、K。、「トンネル上のレイヤー2 VPN」、2006年1月、進行中の作業。
[15] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e. ISO/IEC 15802-3: 1998.", IEEE Standard 802.1D, July 1998.
[15] Institute of Electrical and Electronics Engineers、「情報技術 - システム間の電気通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 共通仕様 - パート3：メディアアクセス制御（MAC）ブリッジ：改訂。これはISO/IEC 10038の改訂です：1993、802.1J-1992および802.6K-1992。P802.11C、P802.1PおよびP802.12E。ISO/IEC 15802-3：1998。」、IEEE Standard 802.1d、1998年7月。
The following contributed to this document:
次の文書に貢献しました。
Javier Achirica, Telefonica Loa Andersson, Acreo Giles Heron, Tellabs Sunil Khandekar, Alcatel-Lucent Chaitanya Kodeboyina, Nuova Systems Vach Kompella, Alcatel-Lucent Marc Lasserre, Alcatel-Lucent Pierre Lin Pascal Menezes Ashwin Moranganti, Appian Hamid Ould-Brahim, Nortel Seo Yeong-il, Korea Tel
ハビエル・アチリカ、テレフォニカ・ロア・アンダーソン、アコレオ・ジャイルズ・ヘロン、テラブス・スニル・カンデカル、アルカテル・ルーセント・チャイタニャ・コデボイナ、ヌオヴァ・システムヴァッハ・コペラ、アルカテル・ルセント・マーク・ラッセル、アルカテル・ルーセント・ピアール・ライン・ナーティアン・ハマンティアン・ハマンティアン・ハマンティアン・ハマンティアンヨンイル、韓国電話
Thanks to Joe Regan and Alfred Nothaft for their contributions. Many thanks too to Eric Ji, Chaitanya Kodeboyina, Mike Loomis, and Elwyn Davies for their detailed reviews.
Joe ReganとAlfred Nothaftの貢献に感謝します。Eric Ji、Chaitanya Kodeboyina、Mike Loomis、およびElwyn Daviesの詳細なレビューに感謝します。
Editors' Addresses
編集者のアドレス
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 US
EMail: kireeti@juniper.net
Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 US
EMail: yakov@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。