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
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）IETFトラスト（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作業部会は最終的に異なる方法で同様の機能を実行する2つの別々の文書、RFC 4762およびこの文書を、作成しました。彼らはお互いにはっきりと互換性があるにもかかわらず、それぞれの方法は一般に「VPLS」と呼ばれていることに注意してください。
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（Virtual Private Network）を提供しています。しかし、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]として表示され、機能するネットワークを切り替えました。これは、パケット交換網を越えて、これらの個々の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]は、ネットワークを切り替えました。これらの両方は、しかし、ポイントツーポイントのイーサネットサービスを提供しています。どのような上記の二つからVPLSを区別することは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.
VPLSの基礎となる機能モデルは、これは、それらの相互作用を提供しているサービス、サービスを提供するために相互作用するネットワークコンポーネントを記述し、ハイレベルの第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
この文書で説明した制御プレーンは、マルチプロトコルBGP [4]、すなわち、VPLSメンバーの自動検出のために、与えられたVPLSインスタンスを構成する疑似回線のセットアップおよびティアダウンのために、VPLSサービスを確立するために使用します。第3節では、これに焦点を当て、
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].
また、マルチホーミングの処理方法を自律システム境界にまたがるVPLSの設定方法を説明し、同様に。 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.
転送プレーンと取らなければならないVPLSサービスを提供し、参加プロバイダエッジ（PE）ルータはセクション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の相互作用が記述されています。デカップリングはVPLSのより柔軟な展開が可能になります。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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]は使用されていると同様の用語：CE（カスタマエッジ）デバイスとP（プロバイダのみ）およびPE（プロバイダーエッジ）ルータ、顧客とサービス・プロバイダ（SP）ネットワーク。しかし、ここでは、追加の概念は、「U-PE」、レイヤ2アグリゲーションに使用レイヤ2のPE装置とがあります。 U-PEの概念は5 PEとU-PEデバイスは、彼らがVPLSサービスが提供されていることを知っていることを意味し、「VPLS対応」しているセクションでさらに説明されます。用語「VE」は、PEまたはU-PEのいずれかとすることができるVPLSエッジデバイスを指します。
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非対応です。限りCEに関しては、それは、レイヤ2を介してVPLS内の他のCEに交換ネットワークに接続されています。これは、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-気づいていないレイヤ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.
用語「デマルチプレクサ」は、パケットが属するVPLSならびに入口PEを識別するデータパケット内の識別子を指します。この文書では、デマルチプレクサは、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.
サービス・プロバイダ・ネットワークは、パケット交換ネットワークです。 PEが（論理的に）完全に（例えば、VPLSのような）サービスに属するパケットがカプセル化されて転送される上にトンネルと噛合されているものとします。トラフィックエンジニアリング（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の不可欠な一部です。しかし、これらの活動は、VPLSは、以下で説明するには、何のSPデバイスはパケットをあふれさせるか、その代わりに、MACアドレスを学習するために別のSPデバイスを要求しない、すなわち、SPデバイスにプライベートです。
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が完全データプレーンに噛合されているものとする、すなわち、そのVPLSに参加するPEのすべての対の間の双方向疑似回線があり、したがって、すべての（入力）PEは、出力にVPLSパケットを送信することができますPE（S）を直接には、中間PEを必要とせずに（セクション4.2.5を参照。）これは、PEは、必要に応じて設定する別のPEにメッセージを送ることができるように、VPLSのPEは、論理的に完全に制御プレーンに噛合されている必要がスードワイヤ。コントロールプレーン内の論理フルメッシュを達成するための代替案に関する議論については、セクション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は、それらがLANで接続されているかのようにVは、SPネットワークを介して対話することができます与えられたVPLSインスタンスに属するCEデバイスで「LANサービス」です。 VPLSは異なるVPLSsに属するCEデバイスに「プライベート」で対話することはできません。 VPLSは、複数のVPLSsに「仮想」である一般的なパケット交換網を介して提供することができます。
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を「発見」し、およびデマルチプレクサを交換するために相互作用します。これらの相互作用は、制御駆動ではなく、データ駆動型です。
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は同じVPLSでリモートのPEまたはU-PESとの接続を確立するための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デバイスは、[6] VPLSとIP VPNの両方に同時に参加することができます。これらは独立したサービスであり、情報がこの交換持つ異なるアドレスファミリ識別子（AFIS）と次のアドレスファミリ識別子（SAFIs）に使用するネットワーク層到達可能性情報（NLRI）として別々に保持されているサービスの種類ごとに交換しました。したがって、実装は、各サービスに対して個別のルーティング・ストレージを維持しなければなりません。しかし、複数のサービスが同じ基本トンネルを使用することができます。 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.
前者のアプローチは、（与えられたVPLS内のすべてのPEは、そのVPLS内の他のすべてのPEへの疑似回線を確立すること、すなわち、）所定のVPLSに関与するのPEが完全に噛合されていることが要求されるので、特に、かなりの構成集約的です。また、VPLSの変化（すなわち、PEが追加、またはVPLSから除去される）のトポロジーは、その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が、この場合BGPに、いくつかのプロトコルを用いて与えられたVPLSの一部である自動検出手法では、各PE「発見」。これは、各PEの設定はこれだけPEに設立さVPLSインスタンスのアイデンティティから成ることができ、その内の他のすべてのPEのないアイデンティティは、VPLSインスタンス - それは、自動検出です。また、場合VPLS変化のみ影響を受けたPEの構成変更のトポロジー。他のPEは自動的に変更を知ると合わせます。
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. A PEのメンバーであるVPLSのV内のすべての他のPEに伝えることができなければなりません。これらの両方を行うために、PEは、VPLS、すべての他の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デバイスはまた、与えられたVPLSを構成するものを知っている必要があります。しかし、彼らは同じレベルの詳細を必要としません。 U-PEが接続されたPE（又はPEは）U-PEにVPLSのアブストラクションを与えます。これは第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]。それは[5]形式[5]に記載されている特にVPLS、ルートターゲットコミュニティのメンバーを識別するために、BGP拡張コミュニティを使用します。ルートターゲットの使用のセマンティクスは、[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.
それはVPLSsが完全に噛合していると仮定されているように、単一のルートターゲットRTは、与えられたVPLS Vために十分であり、実際に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は、それがルートターゲットRTで（次のサブセクションを参照）Vに対するそのNLRIを注釈を付けることにより、VPLS Vに属し、ルートターゲットRTを有する他のPEからのNLRIをを受け入れることにより、これに作用する（典型的にはI-BGPを介して）発表します。 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.
検出が完了すると、VPLS内のPEの各対は確立することができなければならない（及び破棄）デマルチプレクサを互いに、すなわち、交換機に疑似回線を（および撤回します）。このプロセスは、シグナリングとして知られています。シグナリングはまた、PEは、所与のVPLSのために設定疑似回線の特定の特性を送信するために使用されます。
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.
デマルチプレクサは、トンネルを介して搬送されるトラフィックのいくつかの異なるストリームを区別するために使用されていることを思い出して、各ストリームは、おそらく異なるサービスを表します。 VPLSの場合には、デマルチプレクサは言うだけでなく、特定のパケットが属するだけでなく、入口PEを識別するVPLSれます。前者の情報は、パケットを転送するために使用されます。後者の情報は、MACアドレスを学習するために使用されています。ここで説明するデマルチプレクサは、MPLSラベルです。しかし、PE-に-PEトンネルは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.
各リモートPEにデマルチプレクサを送信するために別個のBGPアップデートメッセージを使用してN遠隔のPEのためのNそのようなメッセージを送信する発信PEを必要とするであろう。この文書で説明するソリューションは、PEは、代わりにN、個々のメッセージの、すべてのリモートのPEのためのデマルチプレクサを含む単一（共通）更新メッセージを送信することを可能にします。これを行うと、発信PE上だけでなく、他のPEにこの更新を配布することに関与し得る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及びAによって定義されたラベルブロック、ブロックサイズVBS VEは、ラベル{LB、LB + 1、...、LB + VBS-1}の連続集合です。ここでは、ラベルブロックがどのように動作するかです。与えられたVPLS内のすべてのPEが割り当てられているユニークは、その構成の一部としてIDをVE。 VPLSの更新を送信することを望むPE Xは、他のすべてのPEに同じラベルブロック情報を送信します。各受信PEラベルベースにIDをVEの（ユニークな）を添加することによってPE Xを意図ラベルを推定します。このように、各受信PEは、VPLSのためのPEのXの一意のデマルチプレクサを得ます。
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.
この単純な概念は、ブロックがVBOをオフセットVEの概念で強化されています。 <LB、VBO、VBS>で定義されたラベルブロックは、集合{LB + VBO、LB + VBO + 1、...、LB + VBO + VBS-1}です。したがって、代わりに全てのVPLSにIDをVEカバーする単一の大きなラベルブロックの一つは、異なるラベル基材とのそれぞれを、いくつかのラベルブロックを有することができます。これは、ラベルブロック管理が容易になり、また、PE XはPE Xが既にアドバタイズたラベルブロックのセットによって覆われていないID VEとVPLSに参加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プロセスが、そのためにいくつかの広告を受信するために待機することを望むかもしれないラベルブロック割り当ての効率を改善するために、他のPEからの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は（[4]を参照）VPLSメンバーシップ及びデマルチプレクサを交換するために使用される新しいAFIとSAFIと、以下に説明します。
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は、以下の情報要素を有する：IDをVE、ブロックサイズ、およびラベルベースのVE、ブロックオフセットVE。 VPLS NLRIの形式は以下のとおりです。 AFIはL2VPN AFI（25）であり、そしてSAFIはVPLS SAFI（65）です。 Lengthフィールドは、オクテットです。
+------------------------------------+
| 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).
VPLSに参加するPEは、少なくとも1つのIDをVE有していなければなりません。 PEは、VEである場合、それは典型的には、1つのIDをVE有します。 PEは、いくつかのU-PEに接続されている場合、それは別個の各U-PEのIDをVEました。それはさらに、そのVPLSのためのVEとしてそれ自体が作用すると、自身のIDをVE有していてもよいです。以下では、我々は、VPLS NLRI PE-Aを発表PEを呼び出します、私たちはそのPE-aがIDのV（いずれか自体またはu-PEは、PE-Aをするために接続し、PEに属する）VE所有していると仮定します。
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は、通常、ネットワーク管理者によって割り当てられます。その範囲は、VPLSにローカルです。与えられた（3.5節を参照）CEがマルチホームでない限りIDは、唯一のPEに属するべきであるVE。
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:
ラベルブロックは、指定されたIDをVE到達するために使用されるデマルチプレクサラベルのセットです。 VPLS BGP NLRIは、ブロックがVBOオフセットVEブロックサイズVBSをVE、およびラベル基材LBは、そのピア次のと通信し、IDのVをVE：
label block for V: labels from LB to (LB + VBS - 1), and
Vのラベルブロック：ラベルLBからの（LB + VBS - 1）、及び
remote VE set for V: from VBO to (VBO + VBS - 1).
遠隔Vに設定されたVE：VBO乃至（VBO + VBS - 1）。
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).
リモートとの間に1対1の対応が存在しVEとラベルブロックである：ID（VBO + n）は（LB + n）をラベルに対応VE。
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の一部であり、でアナウンスを行うと仮定ID VをVE、ブロックはVBOオフセットVEブロックサイズVBS、ラベルベースのLBをVE PE-bはまた、VPLS fooの一部であり、ID WをVEた、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-する：デマルチプレクサラベルPE-AのためにPE-Bからのトラフィックを送信するためには、（ - VBO LB + W）として計算されます。
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は、いくつかに属している場合、リモート、PE-bが発表に設定VEとは、ブロックが「VBOオフセットVE言う、ブロックのVEサイズVBS「およびラベル基材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-からPWは：（LB ' - VBO + V'）：PE-BはPE-Aからのトラフィックを期待するべき上デマルチプレクサラベルは次のように計算されます。
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.
以下の拡張属性、「レイヤ2情報拡張コミュニティ」が与えられたVPLSの設定であることを疑似回線に関する制御情報を通知するために使用されます。拡張コミュニティ値は、（現在使用値0x800A）でIANAによって割り当てられるべきです。この情報は、疑似回線上で使用する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：レイヤ2情報拡張コミュニティ
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 AコントロールワードこのPEにVPLSパケットを送信するときに[7]、または、それぞれ、Cは1又は0であるか否かに応じて、存在してはならないMUST
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
このPEにVPLSパケットを送信する際のフレームのSシーケンス・送達又はSは、それぞれ、1又は0であるか否かに応じて、使用してはいけませんMUST
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
新しいVPLSを作成するには、VPLS fooが言う、ネットワーク管理者はVPLS fooのRTを選択する必要があり、RT-fooが言います。これはVPLS fooのに役立つすべてのPEによって使用されます。与えられたPEを設定するには、PEが-、VPLS fooの一部であることを、ネットワーク管理者だけのためのVE ID Vを選択しなければならないと言います
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.
エンドウ。 （PE-AをU-PEに接続されている場合は、PE-つ以上で構成することができるIDをVE、その場合には、以下がごとに行われるIDをVE）。 PEはまた、ルート識別子（RD）を用いて構成することができます。いない場合、それはVPLS fooのユニークなRDを生成します。 RDは、RD-FOO-Aであると言います。次に、初期ラベルブロックと遠隔により定義され、Vに設定されたVE生成するブロックがVBOオフセットVE-PE、ブロックサイズVBS、ラベルベースのLBを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は、次いで、RD RD-FOO-、VE、ID VをVEブロックVBOオフセットVEブロックサイズVBSとラベル基材LBを有するVPLS BGP NLRIを作成しますこのために、それはレイヤ2情報拡張コミュニティとRT、RT-FOOを添付する。それは、それ自体として、このNLRIのためのBGPネクストホップを設定し、そのピアにこのNLRIを発表しました。組み合わせ<AFI = L2VPN AFI、SAFI = VPLS SAFI>の次のホップのネットワークアドレスに関連付けられたネットワーク層プロトコルはIPです。この関連付けは、ネクストホップフィールドの長さの値が4である場合、ネクストホップは、IPv4アドレスを含む[4]、セクション5で必要とされます。この値が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は、別のPE、PE-Bを言う、VPLS BGPアナウンスメントRT-fooでとID WをVEから聞く場合には、PE-AはPE-bは同じVPLS（自動検出）のメンバーであることを知っています。 PEは、その後、セクション3.2でメカニズムを使用して、PE-AおよびPE-Bとの間のVPLS擬似回線のその部分を設定しなければなりません。同様に、PE-BはPE-aが同じVPLSであり、PE-Bは、VPLS擬似回線のその部分を設定する必要があることを発見したであろう。したがって、シグナリングおよびスードワイヤ設定も同じ更新メッセージを用いて達成されます。
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は、リモートPE-ために発表するように設定VEに存在しない場合VPLSのFOOのID VをVE、PE-BはPE-する疑似回線のその部分を設定することはできません。これに対処するために、PE-それはVPLS fooのために作られた古い発表（複数可）を撤回することを選択し、そしてより大きな、リモート全てカバーセットと対応するラベルブロックをVEとの新しいアップデートを発表することができますVPLS fooの中にある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のからIDのVをVE、そしてPE-、VPLS fooの中にそのCEにPE-Aのすべてのリンクがダウンした場合に含まれているID V. VEのVPLS fooのすべての発表を撤回しなければなりませんその後、PEは、VPLS fooのすべてのNLRIをを撤回またはVPLS fooの中の他のPEはPE-aは、もはやそのCEに接続されていることを何らかの方法で知っているべきであるのいずれか。
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を介して発表されています。これは、VPLS内のすべてのサイトが単一の自律システム（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内のサイトは、異なるのAS内のPEに接続することができます。これは二つの問題につながる：1）があり、これらのPE間のI-BGP接続ではありませんので、のAS間でのシグナル伝達のいくつかの手段が必要とされています。 2）AS間PE-に-PEトンネルが存在しなくてもよいです。
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）。すべてのこれらの方法は、マルチAS VPLSでアナログを持っています。
Here is a diagram for reference:
ここで参照するための図です。
__________ ____________ ____________ __________
/ \ / \ / \ / \
\___/ AS 1 \ / AS 2 \___/
\ /
+-----+ +-------+ | +-------+ +-----+
| PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 |
+-----+ +-------+ | +-------+ +-----+
___ / \ ___
/ \ / \ / \
\__________/ \____________/ \____________/ \__________/
Figure 5: Inter-AS VPLS
図5：インター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.
上記参照のように、インタープロバイダVPLSをシグナリングするための3つの方法が与えられます。これらは、スケーラビリティを向上させるために提示されています。方法（a）は、概念的に理解することが最も簡単であり、かつ簡単に展開します。しかし、AS間のイーサネット相互接続を必要とし、両方がAS境界ルータ（のASBR）上の制御及びデータプレーン状態をVPLS。 （b）の方法は、（イーサネットである必要はない）AS-AS相互接続上のASBRとMPLS上のVPLS制御プレーンの状態を必要とします。方法（c）は、AS-AS相互接続上のMPLS、しかしのASBR上のいかなる種類の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境界ルータ（ASBR1）は、ここでAS2としてAS1とASBR1が接続されているASにまたがる全てVPLSsに対するPEとして機能します。隣接AS（ASBR2）にASBRは、AS1とAS2にまたがるVPLSsためのCEとしてASBR1によって観察されます。このためのPEは、ビューのAS2の点からVPLS、およびCEとしてASBR1を閲覧と同様に、ASBR2が作用します。
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を必要としないが、このリンクキャリーイーサネットトラフィックこととごとに個別のVLANサブインターフェイスは、このリンクを通過するがVPLSされることを必要はありません。さらに、ASBR1は、PEの操作を行うことが必要です（発見、シグナリング、MACアドレス学習、洪水、カプセル化、など）ASBR1を通過するすべてのVPLSsため。これは、マルチAS VPLSsの数を制限する制御プレーンとデータプレーンの両方、ASBR1に大きな負担を課します。
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.
一般的に、冗長性のためのASの対の間の複数の接続が存在するであろうことに留意されたいです。この場合には、スパニングツリープロトコル（STP）[15]、またはループ検出および防止の他の手段は、ループフリーのトポロジは、各VPLSで構築することができるように、これらのASにまたがる各VPLS上で実行されなければなりません。これらのデバイスは、このような各VPLSのためのループ検出アルゴリズムを実行する必要があり、これは、それらのVPLSsに参加するのASBRとのPEにさらに負担を課します。どのようにこれを達成することができることは、この文書の範囲外です。
3.4.2. Method (b): EBGP Redistribution of VPLS Information between ASBRs
3.4.2. （B）の方法：ASBR間VPLS情報のEBGP再配布
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.
この方法は、（おそらくルートリフレクタを介して）AS2にASBR1およびASBR2間ピアリングE-BGPをAS1におけるAS1とASBR1におけるPE間のI-BGPピアリングを必要とし、ASBR2およびAS2内のPE間のI-BGPピアリング。上記の例では、PE1はBGPのネクストホップとしてラベルブロックとそれ自体とASBR1にVPLS NLRIを送信します。 ASBR1は、BGPネクストホップとして新しいラベルと自身とASBR2にNLRIを送信します。そしてASBR2は、ネクストホップとして新しいラベルと自身とPE2にNLRIを送信します。 PE1からPE2へASBR2からASBR1、ASBR2にASBR1からT2、およびT3にT1：対応して、3つのトンネルがあります。各トンネル内で、使用する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と同一です。正確には、長さ、ルート区分は、ザはIDをVE、ザ・ブロックオフセットVE、及びザは、ブロックサイズが同じでなければなりませんVE。ラベル基材が異なる場合があります。次のようにまた、ASBR1はまた、その転送パスを更新する必要があり：PE1によって送信されたラベル基材がL1である場合、ラベルブロックサイズはN、ASBR1によって送信されたラベル基材がL2であり、そしてASBR1からPE1へトンネルラベルはTであり、その後、ASBR1は、転送パスに次のようにインストールする必要があります。
swap L2 with L1 and push T,
スワップL1とL2とプッシュT、
swap L2+1 with L1+1 and push T, ...
スワップL1 + 1とL2 + 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はPE1にVPLSパケットを送信したい場合は、PE2はPE1がためASBR2のラベルブロックから右VPLSラベルを取得するためにIDをVE使用し、ASBR2に到達するためにトンネルラベルを使用しています。 ASBR2はASBR1からラベルにVPLSラベルをスワップ。 ASBR1は次にPE1からラベルでVPLSラベルをスワップ、および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を必要とするが、リンク層は、イーサネット（登録商標）である必要はありません。さらに、ASBRははVPLS情報の配信に参加しています。しかし、のASBRのデータプレーンの要件は、ラベル操作に限定され、方法は、（a）の場合よりもはるかに簡単です。最後に、ループのないVPLSトポロジの構築は、すなわち、意思決定をルーティングすることにより行われます。 BGPパスとネクストホップの選択、そのあたり-VPLSベースでスパニングツリープロトコルを実行する必要はありません。したがって、この方法は方法（A）よりもかなりよりスケーラブルです。
3.4.3. Method (c): Multi-Hop EBGP Redistribution of VPLS Information between ASes
3.4.3. 方法（C）：AS間VPLS情報のマルチホップEBGP再配布
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.
この方法では、マルチホップAS2にPES（又は好ましくは、ルートリフレクタ）AS1及びPES（またはルートリフレクタ）との間のピアリングE-BGPがあります。 PE1はPE2にラベルとネクストホップの自己とのVPLS NLRIを送信します。これはルートリフレクタを介してである場合、BGPのネクストホップは変更されません。これは、PE1からPE2へのトンネルLSPが存在することを必要とします。このトンネルLSPは、例えばPEループバックのために標識されたIPv4ルートを交換するE-BGPを使用して、正確に[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がPE2にVPLSパケットを送信したい場合には、それは自身のVPLSに対応するラベルをパケットにIDをVEプッシュします。その後、トンネルラベル（s）は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情報を必要としません。 ASBRは、制御プレーンにおいてのみPE-に-PEトンネルLSPを設定し、データプレーンのラベル操作を行う必要があります。ここでも、この方法の場合のように（b）は、ループのないVPLSトポロジの構築は、ルーティングの決定、すなわち、BGPパスとネクストホップの選択によって行われ、そのあたり-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.
複数のASにまたがるVPLSのIDをVEの割り当てを容易にするために、一方が各ASの範囲を割り当てることができます。例えば、AS1の用途は100の範囲1内のIDをVE、101から200までAS2、AS2などにAS1及び20に取り付けられた10のサイトがある場合は、割り当てられたIDが120、これに1〜10及び101とすることができるVE IDはユニーク保たれているVEようにしながら交換され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に割り当てることができます。唯一の注意点は、のAS間でID範囲をVEとの間に重複が存在しないことです。この規則の例外は、以下で扱われるマルチホーミングです。
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.
頻繁にも、異なるのASで、おそらく、複数のPEに接続する、すなわち、マルチホームVPLSサイトに望まれています。このような場合には、同じサイトに接続されたPEは同じかで構成することができるIDをVE又は異なるとIDをVE。後者の場合には、ループのないVPLSトポロジを構築するために、CEデバイス上の、およびおそらくのPE上でSTPを実行するために必須です。これはどのように達成することができ、この文書の範囲外です。しかし、この節の残りの部分では、いくつかの詳細に前者の場合を説明します。 CEの上のSPとSTPによってマルチホーミングが共存することができることに留意されたいです。したがって、CEができる場合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.
同じサイトに接続されたPEは、同一のIDをVE割り当てられている場合には、ループのないトポロジがBGPパス選択によって、特に、メカニズムをルーティングすることにより構成されています。 BGPスピーカは、2つの等価なNLRIを（定義については以下を参照）を受信すると、そのようなNLRIを選択するかを決定するためにローカルプリファレンス等のパスの長さなどの標準的な経路選択基準を適用します。それは一つだけ選択する必要があります。選択された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.
ルート識別子は、インクルードはID VEの場合、2つのVPLS NLRIを、ビューのパス選択点から等価であると考えられる、とザ・ブロックが同じであるオフセットVE。 2個のPEが同じで与えられたVPLSでIDをVE割り当てられている場合、それらは同じルート識別子を使用しなければならない、と彼らは同じオフセット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を使用した場合1がVPLSコントロールプレーンを拡張する方法について説明します。コントロールプレーンのスケーリングの少なくとも三つの側面があります。
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.
VPLSやその他のアプリケーションのためかどうか3、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 VPNのBGPの使用は、これらすべての問題のいくつかの優れたソリューションをもたらしました。基本的な技術は、BGPルートリフレクタ（RRS）を使用して、階層である[8]。アイデアは、それ自体が完全に噛合されているルートリフレクタの小さなセットを指定し、各BGPスピーカと1つのまたは複数のRR間のBGPセッションを確立することです。このように、すべてのBGPスピーカ間で直接フルメッシュ接続のための必要はありません。プロバイダの特定のスケーリングの必要がRRの多数を必要とする場合、この技術は、再帰的に適用することができる：RRのうちのフルメッシュ接続性は、RRのさらに別のレベルによって仲介することができます。 RRの使用は、上記課題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].
のRRは、VPLSやVPNのために使用されるように、純粋にコントロールプレーン技術であることに注意することが重要です。 RRの使用には、データプレーンの状態とのRRには、データプレーンフォワーディング要件を導入していないし、どのような方法でVPLSトラフィックの転送パスを変更しません。これは、[10]で定義された階層型VPLSの技術とは対照的です。
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.
このアプローチの別の結果は、RRの一組は、すべてのBGPメッセージを処理することが必要とされないこと、または特定のRRが所与のPEからのすべてのメッセージを処理することです。一つは、RRのいくつかのセットを定義することができ、例えば、セットはVPLSを処理するために、別のIP VPNを処理するため、および他のインターネットルーティングのために。別のパーティショニングは、一つのRRのセット、およびRRの別のセットによって処理VPLSsとIP VPNの別のサブセットによって処理VPLSsとIP VPNのいくつかのサブセットを有することとすることができます。ルートターゲットフィルタリング（RTF）の使用は、[12]に記載され、これは簡単でより効果的にすることができます。
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 VPLSメッセージのそれはちょうど興味のBGPスピーカに渡す）RTFを使用することによって対処されます。この技術はRRの使用に直交しているが、のRRと一緒にうまく動作します。 RTFは、AS間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.
それはしばしば混乱の源である制御プレーンの側面を言及する価値があります。ノーMACアドレスは、BGPを介して交換されています。すべてのMACアドレス学習とエージングは各PEによって個別データプレーンで行われます。 BGP VPLSメッセージ交換の唯一のタスクは、自動検出およびラベル交換です。
Thus, BGP processing for VPLS occurs when
したがって、VPLSのためのBGP処理がときに発生します
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.
これらのイベントは比較的まれであり、一般的に、このような各イベントは、一つの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を実装PEと、U-PEのためのデータプレーンの二つの側面を論じています。
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デバイスから受信したイーサネットフレームは、パケット上の送信のためにカプセル化されたPEを接続するネットワークを切り替えます。カプセル化は、[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のネットワークがサポートしているVPLSのために全体のサービスプロバイダーのネットワークを単一の論理的な学習ブリッジとして表示されなければならないことを意味します。 SP「ブリッジ」の論理ポートは、顧客のポートだけでなく、VE上の疑似回線です。学習ブリッジはそのポート上のMACアドレスを学習と同じように、SPブリッジは、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.
論理ポートP上の送信元MACアドレスを学習S VE場合は、その後「をインクルードは、新しいポートPを反映するようにFIBを更新しなければならないVE、」別のポートPにSを見ています。 A 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 PEは学習ブリッジがそうであるようにずっと同じ論理ポートに関連付けられたMACアドレスを、除去するための老化のメカニズムを持っているべきです。それ別の論理ポートに論理ポートから「移動」場合はMACアドレスを再学習することができるように、いずれかのステーションがどのMACアドレスが属していることを本当に移動したため、またはこれを原因LANにおけるトポロジ変更のためにこれが必要ですMACは、新しいポートに到着して取り組みます。また、高齢化は、VPLSことにだけアクティブMACアドレスではなく、すべてのMACアドレスへのVPLS 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の「年齢」は年齢がエージング時間Tを超えた場合、それがポートP上のソースMACとして最後に見られたからの時間で、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.
実装ごとのVPLS基づいてエージング時間Tを設定する設定つまみを提供しなければなりません。それは、そのようなこと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にない宛先にパケットを受信すると、それは他のすべてのポートにパケットをフラッディングします。同様に、VPLS内の他のすべてのVEに未知の宛先にパケットをフラッディングしますVE。
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).
CE2はPE2にイーサネットフレーム、及びフレームに宛先MACアドレスを送信した場合は、上記図1において、（すなわち、VPLSのために）PE2のFIBにした、次いでPE2が同じVPLS内の他のすべてのPEにそのフレームをフラッディングするための責任を負います。 （PE1は、MACアドレスことを「所有」とCE知っていなければ）そのフレームを受信すると、PE1はさらにCE1とCE5にフレームをフラッディングについて責任を負うことになります。
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-のPEを持っていることを発表するでしょう。 、PE3のいずれか、それは二つのフレーム、各U-PEのための1つを受け取ることになる場合には、フラッディングが不可能であることを発表することができ、またはそれは、それがフレームのコピーを受け取ることになる場合には、フラッディングが可能であることを発表することができそれは両方の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アドレスが、そのVPLSのすべてのステーションに送信しなければならない放送でイーサネットフレーム。これは、洪水のために使用されているものと同じ手段によって達成することができます。
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アドレスを持つイーサネットフレームは、すべてのステーションにブロードキャストすることができます。 Aはまた、受信機、対応するマルチキャストグループに関心を示しているものの小さなセットにマルチキャストフレームの送信を制限する特定の技術を使用することができる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.
洪水の可能PE（PEXを言う）は、ブロードキャストイーサネットフレーム、または未知の宛先MACアドレスを持つ1を受信すると、フレームをあふれなければなりません。フレームが付属CEから到着した場合、PEXは、VPLSに参加しているすべての他のPEにだけでなく、他のすべての添付CEへのフレームのコピーを送信する必要があります。一方、フレームが別のPE（PEYを言う）から到着し、場合、PEXは添付のCEにパケットのコピーを送信する必要があります。 PEYはまだ行っていたので、PEXは、他のPEにフレームを送ってはいけません。この概念は、「スプリットホライズン」転送および論理的に完全にVPLSのためにメッシュ化されたPEの結果であると呼ばれています。
Split horizon forwarding rules apply to broadcast and multicast packets, as well as packets to an unknown MAC address.
スプリットホライズン転送ルールは、未知の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。学習のための鍵は（顧客のVLANタグ+ 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.
資格と資格のない学習の間で選択すると、1は、単一のグローバルブロードキャストドメイン（非修飾）または（資格）VLANごとのブロードキャストドメインを望んでいるかどうかである最も重要なもののいくつかの要因が関与します。後者は、洪水や放送がより効率的になりますが、より大きなMACテーブルが必要です。これらの考慮事項は、通常のイーサネット転送にとVPLSにも同様に適用されます。
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内のサービスの異なるクラスを提供するために、実装は、微分処理を可能にする、疑似回線及び/又はトンネルラベルのEXPビットの適切な設定にVLANタグを顧客イーサネットフレーム内802.1Pビットをマッピングするために選ぶかもしれ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.
各顧客が802.1Pビットの所定の設定に必要な行動の独自のビューを有していてもよいVPLSとして有用であるために、実装は、各VPLSのために異なるように、このマッピング機能を可能にすべきです。
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はサポートしています（インクルードは、VE）、顧客に最も近いVPLS対応のデバイスを機能かを決める必要があります。この文書で説明するデフォルトケースザがPEであるVEということです。しかし、そこザは（例えば、そのPEに通信するように）全て（例えば、MACアドレス学習及びフラッディングなど）、レイヤ2つの機能とレイヤ3つの機能の限られたセットを行う装置であるかもしれないVEいくつかの理由があるが、例えば、本格的な発見およびPE-に-PEシグナリングを行いません。そのようなデバイスは、「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.
これらの例の両方が利益を持っているとして、一つは「ミックスと一致し、」これらのシナリオをできるようにしたいと思います。ここで紹介するシグナリングメカニズムはこれを可能にします。例えば、所与のプロバイダ・ネットワーク、PEは、直接CEデバイスに接続することができるかに、別のCEに接続されているU-PEに接続され、第三のは、いくつかのインタフェース上に顧客に直接接続されてもよいとU-します他人オーバーのPE。これらのすべてのPEは同じように発見し、シグナリングを行います。彼らはどのように学習しないと転送は、U-PEがあるかどうかに依存します。しかし、これはローカルの問題である、と知らされていません。しかし、U-PEおよびPEと他のU-PESとの相互作用の動作の詳細は、この文書の範囲を超えています。
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にVPLSはなくVPLS内のデータのみがその内の他のノードに配布されていること、すなわち、データのプライバシーです。 VPLSは、機密性、完全性、または認証を提供しないことに注意してください：VPLSパケットは、パケット交換ネットワーク、およびのman-in-the-middleを盗聴することができ、およびデータストリームにパケットを注入することができるかもしれ中に平文で送信されます。セキュリティが望まれる場合、PE-に-PEトンネルは、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つの側面がある：制御プレーンを確保し、転送パスを保護します。制御プレーンの妥協は、PE別のVPLSにいくつかのVPLSに属するデータを送信、またはVPLSデータをブラックホール、あるいは盗聴者に送信につながる可能性があり、いずれもビューのデータプライバシーの観点から許容されません。すべての制御プレーンの交換は、BGPを介しているので、このようなのような技術[2]が困難（間違ったVPLSにVPLSトラフィックを迂回するために使用することができる）の更新をスプーフィングまたは（サービス拒否攻撃を撤回すること、BGPメッセージを認証する手助け）。マルチAS法（b）及び第3節に記載の（c）において、これはまた、ASBRは、PEの、またはルートリフレクタ間の相互AS 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.
また、異なるVPLSsで開催中の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-に-PEトンネルは行儀であることを確実に必要とし、それはラベルが有効なインターフェイスからのみ受け付けられVPLS。 PEのために、有効なインターフェイスは、Pルータからリンクを含みます。 ASBRの場合は、有効なインターフェイスは、それが与えられたVPLSの一部であるとしてASBRからのリンクです。 1つが唯一の有効なインタフェースからVPLSパケットを受け入れることを、マルチAS VPLSsの場合に特に重要です。
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.
インIP MPLS-とMPLSインGREトンネリングは、[3]で指定されています。それはVPLSパケットを運ぶために、このようなトンネルを使用することが所望される場合、そのドキュメントのセクション8で説明したセキュリティ上の考慮事項は、十分に理解されなければなりません。その文書に記載されているようにVPLSパケットがトンネリングされることを可能にするVPLSの任意の実装は、としてそこに記載されている使用することができるのIPsecの実装を含まなければなりません。トンネルは、IPSecで保護されていない場合、そのドキュメントのセクション8.2に記載境界ルータにおけるIPアドレスフィルタリングの手法は、特定の出口PEでトンネルを出るパケットが実際に置かれたことを保証する唯一の手段であります適切なトンネルヘッドノードによりトンネル内（すなわち、パケットがスプーフィングされた送信元アドレスを持っていないこと）。境界ルータが頻繁にのみソースアドレスをフィルタリングするので、出口PEは、それが受信する任意のトンネリングされたパケットのIPソースアドレスをチェックし、有効なトンネルの先頭アドレスであるIPアドレスのリストと比較することができない限り、パケットフィルタリングが有効ではないかもしれません。 IPsecのなしで使用するMPLS-で-IPおよび/またはMPLSイン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は、レイヤ2情報拡張コミュニティのための拡張コミュニティ値（0x800a）を割り当てました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.ローゼン、 "IP又は総称ルーティングカプセル化（GRE）でカプセル化MPLS"、RFC 4023、2005年3月。
[4] Bates, T., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[4]ベイツ、T.、カッツ、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]サングリ、S.、タッパン、D.、およびY. Rekhterは、RFC 4360、2006年2月、 "BGPはコミュニティ属性を拡張します"。
[6] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[6]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、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]マティーニ、L.、ローゼン、E.、エル・Aawar、N.、およびG.サギ、 "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]ベイツ、T.、チェン、E.、およびR.チャンドラ、 "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]アンデション、L.およびE.ローゼン、RFC 4664 "レイヤ2個の仮想プライベートネットワーク（のL2VPN）のためのフレームワーク"、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.、エド。そして、V. Kompella、エド。、 "仮想プライベートLANサービス（VPLS）ラベル配布プロトコル（LDP）シグナリングの使用"、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.
"VRベースのレイヤ3 VPNの自動検出メカニズムとしてBGPを使用する" [11]ウルド-Brahimの、H.、進行中、仕事、2006年4月。
[12] Marques, P., "Constrained VPN Route Distribution", Work in Progress, June 2005.
[12]マルケス、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]マティーニ、L.、ローゼン、E.、エル・Aawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して、擬似回線の設定とメンテナンス"、RFC 4447、2006年4月。
[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]電気学会電子技術、「情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - 第3部：メディアアクセス制御（MAC）はブリッジ：リビジョンこれはISOの改訂版です/ IEC 10038：1993、802.1j-1992と802.6k-1992それはP802.11c、P802.1pとP802.12eを組み込んだISO / IEC 15802-3：1998」、IEEE標準802.1D、1998年7月。
Appendix A. Contributors
付録A.協力者
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
Appendix B. Acknowledgements
付録B.謝辞
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.
彼らの貢献のためのジョー・リーガンとアルフレッドNothaftに感謝します。その詳細なレビューのためにあまりにもエリック智、Chaitanya Kodeboyina、マイク・ルーミス、とエルウィン・デイヴィスに感謝します。
Editors' Addresses
エディタのアドレス
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
Kireeti Kompellaジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089米国
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
ヤコフ・レックタージュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089米国
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。