RFC4761 日本語訳
4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discoveryand Signaling. K. Kompella, Ed., Y. Rekhter, Ed.. January 2007. (Format: TXT=65219 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Kompella, Ed.
Request for Comments: 4761 Y. Rekhter, Ed.
Category: Standards Track Juniper Networks
January 2007
ワーキンググループK.Kompella、エドをネットワークでつないでください。コメントのために以下を要求してください。 エド4761Y.Rekhter、カテゴリ: 規格は2007年1月に杜松ネットワークを追跡します。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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通の別々のドキュメント、RFC4762、およびこのドキュメントを製作して、それは結局、異なったマナーで同様の機能を実行します。 彼らがお互いと異なって非互換ですが、各方法が一般的に「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.
また、Transparent LAN Serviceとして知られている仮想の兵士のLAN Service(VPLS)とVirtual兵士のSwitched Networkサービスは役に立つService Provider提供です。 サービスはLayer2Virtual兵士のNetwork(VPN)を提供します。 しかしながら、VPLSの場合では、多点イーサネットLANでVPNの顧客に接します、普通のLayer2VPNsと対照して。VPNsは現実に二地点間です。
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に送るための規則について説明します。
Kompella & Rekhter Standards Track [Page 1] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[1ページ]RFC4761BGP自動発見と2007年1月に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
1. 序論…3 1.1. このドキュメントの範囲…3 1.2. このドキュメントで中古のコンベンション…4 2. 機能的なモデル…4 2.1. 用語…5 2.2. 仮定…5 2.3. 相互作用…6 3. 飛行機を制御してください…6 3.1. 自動発見…7 3.1.1. 機能…7 3.1.2. 仕様を議定書の中で述べてください…7 3.2. シグナリング…8 3.2.1. ブロックをラベルしてください…8 3.2.2. VPLS BGP NLRI…9 3.2.3. PWセットアップと分解…10 3.2.4. シグナリングPE能力…10 3.3. BGP VPLS操作…11 3.4. マルチ、VPLS…13 3.4.1. 方法(a): ASBRsのVPLSからVPLSへのコネクションズ。13 3.4.2. 方法(b): ASBRsの間のVPLS情報のEBGP再分配…14 3.4.3. 方法(c): VPLS情報のマルチホップEBGP再分配…15 3.4.4. 複数のASesの向こう側のVE IDの配分…16 3.5. マルチホーミングと経路選択…16 3.6. 階層的なBGP VPLS…17 4. データ飛行機…18 4.1. カプセル化…18 4.2. 転送します。18 4.2.1. マックーアドレス学習…18 4.2.2. 古い…19 4.2.3. 氾濫…19 4.2.4. 放送とマルチキャスト…20 4.2.5. 「分裂地平線」推進…20 4.2.6. 適切で資格のない学習…21 4.2.7. サービスのクラス…21 5. 展開オプション…21 6. セキュリティ問題…22 7. IANA問題…23 8. 参照…24 8.1. 標準の参照…24 8.2. 有益な参照…24 付録A.貢献者…26 付録B.承認…26
Kompella & Rekhter Standards Track [Page 2] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[2ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
1. Introduction
1. 序論
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.
また、Transparent LAN Serviceとして知られている仮想の兵士のLAN Service(VPLS)とVirtual兵士のSwitched Networkサービスは役に立つサービス提供です。 Virtual兵士のLANはイーサネットLANとして(ほとんど)すべての点でService Providerの顧客にとって現れます。 しかしながら、VPLSでは、顧客は皆、単一のLANに接続されません。 顧客は地下鉄か広い領域の向こう側に広げられるかもしれません。 本質では、VPLSは、単一のLAN[9]として現れて、機能するようにパケット交換網の向こう側にいくつかの個々のLANをくっつけます。 これは、パケット交換網の向こう側にこれらの個々のLANを接続するpseudowiresの文脈に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] どれで、人は内部連絡としてイーサネットでLayer2VPNを造ることができるか。 そして、[13]。(その[13]は、パケット交換網の向こう側にイーサネット接続をセットアップするために1つを許容します)。 しかしながら、これらの両方が二地点間イーサネットサービスを提供します。 上の2とVPLSを区別することはVPLSが多点サービスを提供するということです。 VPLSのためにLabel Distributionプロトコル(自由民主党)を使用することでpseudowiresをセットアップするためのメカニズムは[10]で定義されます。
1.1. Scope of This Document
1.1. このドキュメントの範囲
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
本書では説明された制御飛行機は、与えられたVPLS例を構成するpseudowiresのすなわち、VPLSメンバーの自動発見とセットアップと分解のためのVPLSサービスを証明するのにMultiprotocol BGP[4]を使用します。 そしてセクション3がこれに焦点を合わせる。
Kompella & Rekhter Standards Track [Page 3] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[3ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
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].
また、Autonomous System境界にかかるVPLSがどのようにセットアップされるか、そして、マルチホーミングがどのように扱われるかを説明します。 VPNsに制御飛行機として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.
参加Provider Edge(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では、'衝撃を吸収された'操作の概念は定義されます、そして、衝撃を吸収されて非衝撃を吸収されたPEsの相互作用は説明されます。 デカップリングはVPLSの、よりフレキシブルな展開を考慮します。
1.2. Conventions Used in This Document
1.2. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
2. Functional Model
2. 機能論的モデル
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
----- /A1\---- ____CE1| / \ -------- -------- / | | | A2 CE2/\/PE1\/\/\/\___/ | \ ----- ---- ---PE2| \ | | \ ----- | サービスプロバイダーネットワーク| \ / \ | | CE5 A5| | ___ | / \ / |----| \/\PE4_/----- |u-PE|--PE3/\/|----| -------- ------- ---- / | ---- /\/\/\Ceは顧客エッジデバイスと等しいです。| A3 CE3 --CE4 A4| PEはプロバイダー縁ルータ\/\/u-PE=層2の集合と等しいです。---- ---- <n>は顧客サイトnと等しいです。
Figure 1: Example of a VPLS
図1: VPLSに関する例
Kompella & Rekhter Standards Track [Page 4] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[4ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
2.1. Terminology
2.1. 用語
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が(プロバイダー唯一)であることでのService Provider(SP)ネットワークとPE(プロバイダーEdge)ルータ、およびCE(顧客Edge)装置をもっている顧客。 しかしながら、ここに、"u-PE"にLayer2PE装置がLayerに2集合を使用したという追加概念があります。 u-PEの概念はセクション5で、より詳しく説明されます。 PEとu-PE装置は「VPLS意識している」(彼らが、VPLSサービスが提供されているのを知っていることを意味します)。 "VE"という用語はVPLSエッジデバイスについて言及します。(それは、PEかu-PEのどちらかであるかもしれません)。
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に関する限り、それはLayer2交換網でVPLSの他のCEsに接続されます。 これは、CE装置への変化が全くあるはずがないことを意味します、ハードウェアかソフトウェアに、VPLSを提供するために。
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装置はPEかLayer2スイッチを通したVPLS気づかないu-PEに接続されるかもしれません。 VPLS観点から、そのようなLayer2スイッチについて、目に見えなく、したがって、さらに議論しないでしょう。 その上、u-PEはLayer2とLayer3装置を通して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.
"「反-マルチプレクサー」"という用語はパケットがイングレスPEと同様に属するVPLSを特定するデータ・パケットの識別子を示します。 本書では、「反-マルチプレクサー」は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)の具体化と同様にサービスについて言及するでしょう。 どの用法が意図するかは、文脈から明確であるはずです。
2.2. Assumptions
2.2. 仮定
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.
Service Provider Networkはパケット交換網です。 サービス(VPLSなどの)に属すパケットがカプセルに入れられて、送られるトンネルでPEsによって(論理的に)完全に網の目にかけられると思われます。 これらのトンネルはIPトンネルであるかもしれません、Encapsulation(GRE)、またはMPLSトンネルがResource予約プロトコルで確立したGenericルート設定などのように--交通Engineering(RSVP-TE)か自由民主党。 これらのトンネルはそれらの上に提供されたサービスの如何にかかわらず確立されます。 本書ではこれらのトンネルのシグナリングと設立について議論しません。
"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装置もそのに代わってパケットをあふれさせるか、またはMACアドレスを学ぶよう別のSP装置に要求しません。
Kompella & Rekhter Standards Track [Page 5] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[5ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
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(s)に送ることができるので参加するすべての組のPEsの間には、双方向のpseudowireがあります、データ飛行機によってVPLSに参加するすべてのPEsが完全に網の目にかけられると思われて、中間的PEの必要性なしで(.5にセクション4.2を見てください) これは、PEが必要なpseudowiresをセットアップするために別のPEにメッセージを送ることができるようにVPLS PEsが制御飛行機によって論理的に完全に網の目にかけられるのを必要とします。 セクション3.6を見て、代替手段についての議論は制御飛行機に論理的な完全なメッシュを実現してください。
2.3. Interactions
2.3. 相互作用
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.
まるで彼らがLANによって接続されるかのように与えられたVPLS例Vに属すCE装置がSPネットワークを通して相互作用できるので、VPLSは「LANサービス」です。 異なったVPLSsに属すCE装置が相互作用できないので、VPLSは「個人的です」。 一般的なパケット交換網の上に複数のVPLSsを提供できるので、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装置は、他のすべてのPEsが同じVPLSに参加していると「発見し」て、「反-マルチプレクサー」を交換するために相互作用します。 これらの相互作用はコントロールによるデータ駆動型ではなく駆動です。
u-PEs interact with PEs to establish connections with remote PEs or u-PEs in the same VPLS. This interaction is control-driven.
u-PEsは、リモートPEsかu-PEsと共に同じVPLSに関係を樹立するためにPEsと対話します。 この相互作用はコントロールによる駆動です。
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装置は同時に、VPLSとIP VPNs[6]の両方に参加できます。 これらは独立しているサービスです、そして、この交換に使用されるNetwork Layer Reachability情報(NLRI)が異なったAddress Family Identifiers(AFIs)とSubsequent Address Family Identifiers(SAFIs)を持っているとき、それぞれのタイプのサービスと交換された情報は別々に保たれます。 その結果、実現は各サービスのための別々のルーティング格納を維持しなければなりません。 しかしながら、複数のサービスが同じ基本的なトンネルを使用できます。 VPLSかVPNラベルが異なることへのパケット属が調整する「反-マルチプレックス」に使用されます。
3. Control Plane
3. 制御飛行機
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制御飛行機の2つの第一の機能があります: VPLSを構成するpseudowiresの自動発見、セットアップ、および分解は、しばしばシグナリングと呼びました。 セクション3.1とセクション3.2はこれらの機能について説明します。 これらの機能の両方がただ一つのBGP Update広告で達成されます。 セクション3.3は、VPLSのためにBGPプロトコル操作を詳しく述べることによってどのようにこれをするかを説明します。 セクション3.4はその長さAutonomous Systemsのpseudowiresを上がっている設定について説明します。セクション3.5はマルチホーミングがどう扱われるかを説明します。
Kompella & Rekhter Standards Track [Page 6] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[6ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
3.1. Auto-Discovery
3.1. 自動発見
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例に参加するすべてのPEsを見つける過程を示します。 PEは、与えられたVPLSの他のすべてのPEsのアイデンティティで構成できるか、または他のPEsを発見するのに何らかのプロトコルを使用できます。 後者は自動発見と呼ばれます。
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に参加するPEsが完全に網の目にかけられるのが必要であるので(すなわち、与えられたVPLSのあらゆるPEがそのVPLSの他のあらゆるPEにpseudowiresを設立します) VPLSのトポロジーが変化するとき(すなわち、PEから加えられるか、または取り外されます、VPLS)、その上、そのVPLSのすべてのPEsでの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は、どの他のPEsが何らかのプロトコル、この場合BGPによる与えられたVPLSの一部であるかを「発見します」。 これで、各PEの構成はそのVPLS例における、他のあらゆるPEのアイデンティティではなく、このPEで確立されたVPLS例のアイデンティティだけから成ります--すなわち、自動発見にされる。 VPLSのトポロジーが変化するとき、そのうえ、影響を受けるPEだけの構成は変化します。 他のPEsは自動的に変化を見つけて、適合します。
3.1.1. Functions
3.1.1. 機能
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.A PEのメンバーには、もうVPLSに参加しないと宣言する手段がなければなりません。 これらの両方をするために、PEには、VPLSを特定する手段と他のすべてのPEsに交信する手段がなければなりません。
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(または、PEs)はVPLSの抽象化をu-PEに与えます。 これはセクション5で説明されます。
3.1.2. Protocol Specification
3.1.2. プロトコル仕様
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]に基づいています。 それはVPLSの特にRoute Target共同体のメンバーを特定する拡張共同体[5]、形式が[5]で説明されるBGPを使用します。 Route Targetsの使用の意味論は[6]で説明されます。 VPLSにおける彼らの使用は同じです。
Kompella & Rekhter Standards Track [Page 7] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[7ページ]RFC4761BGP自動発見と2007年1月に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が完全に網の目にかけられると思われたとき、独身のRoute Target 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はV(次の小区分を見る)のためにRoute Target RTと共にNLRIsを注釈することによってVPLS Vに属して、Route Target RTを持っている他のPEsからNLRIsを受け入れることによってこれに影響すると発表します(通常I-BGPを通して)。 PEは、Route Target RTと共に広告を出したのがもうすべてのNLRIsを引っ込めることによってVに参加しないと発表します。
3.2. Signaling
3.2. シグナリング
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の各組のPEsは互いにpseudowiresを設立できなければなりません(裂け目はダウンします)、すなわち、交換(引き下がる)「反-マルチプレクサー」。 この過程はシグナリングとして知られています。 また、シグナリングもPEが与えられたVPLSのためにセットアップするpseudowiresのある特性を伝えるのにおいて使用されています。
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の場合では、パケットがどの特定のVPLSに属するかを言うだけではなく、「反-マルチプレクサー」はイングレスPEを特定もします。 前の情報はパケットを進めるのに使用されます。 後者の情報は学習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 Updateメッセージを使用するのは、由来しているPEがNリモートPEsへのそのようなNメッセージを送るのを必要とするでしょう。 PEはすべてのリモートPEsのために本書では説明された解決策で「反-マルチプレクサー」を含むただ一つ(一般的な)のアップデートメッセージを送ることができます、N個々のメッセージの代わりに。 これをすると、コントロール飛行機荷重は由来しているPEの上と、そして、他のPEsにこのUpdateを分配するのにかかわるかもしれないBGP Route Reflectorsの上で抑えられます。
3.2.1. Label Blocks
3.2.1. ラベルブロック
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ですか? ここに、ラベルブロックがどう働いているかがあります。 ユニークなVE IDはそれらの構成の一部として与えられたVPLSの中のすべてのPEsに割り当てられます。 VPLSアップデートを送りたがっているPE Xは同じラベルブロック情報を他のすべてのPEsに送ります。 それぞれ、PEを受けると、PE Xのために(ユニーク)のVE IDをラベルベースに加えることによって意図するラベルは推論されます。 この様に、それぞれPEを受けると、ユニークな「反-マルチプレクサー」はそのVPLSのためのPE Xのために手に入れられます。
Kompella & Rekhter Standards Track [Page 8] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[8ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
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。 したがって、カバーする1つの大きいラベルブロックの代わりにVPLS、1のすべてのVE IDがいくつかのラベルブロックを持つことができます、それぞれ異なったラベルベースで。 これは、ラベルブロック管理をより簡単にして、また、PE Xが優雅にPE Xが既に広告を出したラベルブロックのセットで覆われていないVE IDに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の過程は、他のPEsからのそのVPLS例がラベルブロック配分の効率を高めるようにいくつかの広告を受け取るのを待ちたがっているかもしれません。
3.2.2. VPLS BGP NLRI
3.2.2. VPLS BGP NLRI
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とサフィと共に。([4])がVPLS会員資格と「反-マルチプレクサー」を交換するのに使用されるのを確実にしてください。
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 Block Offset、VE Block Size、およびラベルベース。 VPLS NLRIの書式を以下に与えます。 AFIはL2VPN AFI(25)です、そして、サフィは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) |
+------------------------------------+
+------------------------------------+ | 長さ(2つの八重奏)| +------------------------------------+ | ルートDistinguisher(8つの八重奏)| +------------------------------------+ | VE ID(2つの八重奏)| +------------------------------------+ | VE Block Offset(2つの八重奏)| +------------------------------------+ | VE Block Size(2つの八重奏)| +------------------------------------+ | Label基地(3つの八重奏)| +------------------------------------+
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は少なくとも1VE IDを持たなければなりません。 PEがVEであるなら、それは1VE IDを通常持っています。 PEが数個のu-PEsに接続されるなら、それは各u-PEのための異なったVE IDを持っています。 そのVPLSのためのVEとして機能するなら、それはさらに、それ自体のためのVE IDを持っているかもしれません。 続くことではPE発表をVPLS NLRI PE-aと呼ぶつもりです、そして、私たちはPE-aがVE ID Vを所有していると思うつもりです。(PE-a自身、または、u-PEに属するのはPE-a)に接続しました。
Kompella & Rekhter Standards Track [Page 9] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[9ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
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に地元です。 CEが属さない場合与えられたVE IDが1PEだけに属すはずである、マルチ、家へ帰り、(セクション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に達するのに使用される1セットの「反-マルチプレクサー」ラベルです。 VE ID V、VE Block Offset VBO、VE Block Size VBS、およびラベルベースLBとVPLS BGP NLRIは以下を同輩に伝えます:
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).
リモートVEはVのためにセットしました: 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).
リモートVEセットとラベルブロックの間には、1〜1つの通信があります: VE ID(VBO+n)は、(LB+n)をラベルするために対応しています。
3.2.3. PW Setup and Teardown
3.2.3. PWセットアップと分解
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 Block Offset VBO、VE Block Size 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. PE-aへのPWへのセット: PE-bからPE-aまでの交通を送る「反-マルチプレクサー」ラベルとして、計算されます(LB+W--VBO)。
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. 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.
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. 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').
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.
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.
3.2.4. Signaling PE Capabilities
3.2.4. Signaling PE Capabilities
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 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
Kompella & Rekhter Standards Track [Page 10] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella & Rekhter Standards Track [Page 10] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
the pseudowires), Control Flags (control information regarding the pseudowires), and the Maximum Transmission Unit (MTU) to be used on the pseudowires.
the pseudowires), Control Flags (control information regarding the pseudowires), and the Maximum Transmission Unit (MTU) to be used on the pseudowires.
The Encaps Type for VPLS is 19.
The Encaps Type for VPLS is 19.
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octet) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
+------------------------------------+ | 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
Figure 3: Layer2 Info Extended Community
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |C|S| (MBZ = MUST Be Zero) +-+-+-+-+-+-+-+-+
Figure 4: Control Flags Bit Vector
Figure 4: Control Flags Bit Vector
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.
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.
Name Meaning
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 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
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 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
3.3. BGP VPLS Operation
3.3. BGP VPLS Operation
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
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
Kompella & Rekhter Standards Track [Page 11] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella & Rekhter Standards Track [Page 11] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
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. (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 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 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.
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.
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.
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.
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.
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.
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.
Kompella & Rekhter Standards Track [Page 12] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella & Rekhter Standards Track [Page 12] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
3.4. Multi-AS VPLS
3.4. Multi-AS VPLS
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).
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).
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.
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.
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.
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.
Here is a diagram for reference:
Here is a diagram for reference:
__________ ____________ ____________ __________
/ \ / \ / \ / \
\___/ AS 1 \ / AS 2 \___/
\ /
+-----+ +-------+ | +-------+ +-----+
| PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 |
+-----+ +-------+ | +-------+ +-----+
___ / \ ___
/ \ / \ / \
\__________/ \____________/ \____________/ \__________/
__________ ____________ ____________ __________ / \ / \ / \ / \ \___/ AS 1 \ / AS 2 \___/ \ / +-----+ +-------+ | +-------+ +-----+ | PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 | +-----+ +-------+ | +-------+ +-----+ ___ / \ ___ / \ / \ / \ \__________/ \____________/ \____________/ \__________/
Figure 5: Inter-AS VPLS
Figure 5: 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.
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.
3.4.1. Method (a): VPLS-to-VPLS Connections at the ASBRs
3.4.1. Method (a): VPLS-to-VPLS Connections at the ASBRs
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.
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.
Kompella & Rekhter Standards Track [Page 13] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella & Rekhter Standards Track [Page 13] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
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.
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.
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.
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.
3.4.2. Method (b): EBGP Redistribution of VPLS Information between
ASBRs
3.4.2. Method (b): EBGP Redistribution of VPLS Information between ASBRs
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.
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.
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:
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:
Kompella & Rekhter Standards Track [Page 14] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella & Rekhter Standards Track [Page 14] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
swap L2 with L1 and push T,
swap L2 with L1 and push T,
swap L2+1 with L1+1 and push T, ...
swap L2+1 with L1+1 and push T, ...
swap L2+N-1 with L1+N-1 and push T.
swap L2+N-1 with L1+N-1 and push T.
ASBR2 must act similarly, except that it may not need a tunnel label if it is directly connected with ASBR1.
ASBR2 must act similarly, except that it may not need a tunnel label if it is directly connected with 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.
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.
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).
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).
3.4.3. Method (c): Multi-Hop EBGP Redistribution of VPLS Information
between ASes
3.4.3. Method (c): Multi-Hop EBGP Redistribution of VPLS Information between ASes
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.
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.
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.
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.
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
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
Kompella & Rekhter Standards Track [Page 15] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella & Rekhter Standards Track [Page 15] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
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.
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.
3.4.4. Allocation of VE IDs across Multiple ASes
3.4.4. Allocation of VE IDs across Multiple ASes
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.
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.
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.
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.
3.5. Multi-homing and Path Selection
3.5. Multi-homing and Path Selection
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.
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.
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.
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.
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.
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.
Kompella & Rekhter Standards Track [Page 16] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella & Rekhter Standards Track [Page 16] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
3.6. Hierarchical BGP VPLS
3.6. Hierarchical BGP VPLS
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:
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:
1. alleviating the full mesh connectivity requirement among VPLS BGP
speakers;
1. alleviating the full mesh connectivity requirement among VPLS BGP speakers;
2. limiting BGP VPLS message passing to just the interested speakers
rather than all BGP speakers; and
2. limiting BGP VPLS message passing to just the interested speakers rather than all BGP speakers; and
3. simplifying the addition and deletion of BGP speakers, whether
for VPLS or other applications.
3. simplifying the addition and deletion of BGP speakers, whether for VPLS or other applications.
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.
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.
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].
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].
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.
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.
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].
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].
Kompella & Rekhter Standards Track [Page 17] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella & Rekhter Standards Track [Page 17] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
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.
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.
Thus, BGP processing for VPLS occurs when
Thus, BGP processing for VPLS occurs when
1. a PE joins or leaves a VPLS; or
1. a PE joins or leaves a VPLS; or
2. a failure occurs in the network, bringing down a PE-PE tunnel or
a PE-CE link.
2. a failure occurs in the network, bringing down a PE-PE tunnel or a PE-CE link.
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.
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.
4. Data Plane
4. Data Plane
This section discusses two aspects of the data plane for PEs and u-PEs implementing VPLS: encapsulation and forwarding.
This section discusses two aspects of the data plane for PEs and u-PEs implementing VPLS: encapsulation and forwarding.
4.1. Encapsulation
4.1. Encapsulation
Ethernet frames received from CE devices are encapsulated for transmission over the packet switched network connecting the PEs. The encapsulation is as in [7].
Ethernet frames received from CE devices are encapsulated for transmission over the packet switched network connecting the PEs. The encapsulation is as in [7].
4.2. Forwarding
4.2. Forwarding
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 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.
4.2.1. MAC Address Learning
4.2.1. MAC Address Learning
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.
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.
Kompella & Rekhter Standards Track [Page 18] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella & Rekhter Standards Track [Page 18] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
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.
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.
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.
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.
4.2.2. Aging
4.2.2. Aging
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 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.
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.
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.
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.
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.
4.2.3. Flooding
4.2.3. Flooding
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.
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.
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
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
Kompella & Rekhter Standards Track [Page 19] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella & Rekhter Standards Track [Page 19] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
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).
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).
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.
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.
4.2.4. Broadcast and Multicast
4.2.4. 放送とマルチキャスト
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アドレスがあるイーサネットフレームはすべてのステーションに放送されるかもしれません。 使用マルチキャストフレームのトランスミッションをより小さいセットの受信機、対応するマルチキャストへの関心を示したものに制限するテクニックが分類されるのを確信しているもVE MAY。 このドキュメントの範囲の外にこの議論はあります。
4.2.5. "Split Horizon" Forwarding
4.2.5. 「分裂地平線」推進
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.
氾濫(PExを言う)ができるPEが未知の送付先MACアドレスで1か1個の放送イーサネットフレームを受け取るとき、それはフレームをあふれさせなければなりません。 フレームが付属CEから届いたなら、PExは他のあらゆる付属CEにフレームのコピーを送らなければなりません、よくVPLSに参加する他のすべてのPEsのように。 他方では、フレームが別のPEから届いたなら(PEyを言ってください)、PExはパケットのコピーを付属CEsだけに送らなければなりません。 PEyは既にそうしたでしょう、したがって、PExが他のPEsにフレームを送ってはいけません。 この概念は、「分裂地平線」推進と呼ばれて、VPLSのために論理的に完全にかみ合って、PEsの結果です。
Split horizon forwarding rules apply to broadcast and multicast packets, as well as packets to an unknown MAC address.
規則が放送するのに当てはまる地平線推進、マルチキャストパケット、およびパケットを未知のMACアドレスに分けてください。
Kompella & Rekhter Standards Track [Page 20] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[20ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
4.2.6. Qualified and Unqualified Learning
4.2.6. 適切で資格のない学習
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タグを使用するなら、1つは適切で資格のない学習の同じ区別をすることができます。 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.
適切で資格のない学習を選ぶと、人が、ただ一つのグローバルな放送ドメイン(資格のない)か1VLANあたり1つの放送ドメインに(適切)であって欲しいかどうかという中でそれのもの最も重要であることであるいくつかの要素がかかわります。 後者は、氾濫ともう少し放送するのを効率的にしますが、より大きいMACテーブルを必要とします。 これらの問題は等しく通常のイーサネット推進と、そして、VPLSに適用されます。
4.2.7. Class of Service
4.2.7. サービスのクラス
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の中でServiceの異なったClassesを提供するために、実現は、pseudowire、そして/または、トンネルラベルで顧客イーサネットフレームでVLANタグでEXPビットの適切な設定に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.
役に立つように、SHOULDがそれぞれのVPLS顧客として各VPLSにおいて異なるのをこのマッピング機能を許容する実現はそれ自身の802.1pビットの与えられた設定のための必要な振舞いの視点を持っているかもしれません。
5. Deployment Options
5. 展開オプション
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)サポート。 本書では説明された不履行格はVEがPEであるということです。 しかしながら、VEが機能(MACアドレス学習や氾濫などの)、および限られたセットのLayer3機能(PEに交信などなどの)をすべてのLayer2にしますが、例えば完全な羽毛でおおわれた発見とPEからPEへのシグナリングはしない装置であるかもしれない多くの理由があります。 そのような装置は"u-PE"と呼ばれます。
Kompella & Rekhter Standards Track [Page 21] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[21ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
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つはこれらのシナリオに「混ぜて、合わせたがっています」。 ここに提示されたシグナル伝達機構はこれを許容します。 例えば、与えられたプロバイダーネットワークでは、1PEが直接CE装置に接続されるかもしれません、そして、別のものはCEsに接続されるu-PEsに接続されるかもしれません、そして、3分の1は直接いくつかのインタフェースにわたる顧客と、そして、他のものの上のu-PEsに接されるかもしれません。 これらのすべてのPEsが同じ方法で発見とシグナリングを実行します。 学習と彼らがどう推進するかはu-PEがあるかどうかによります。 しかしながら、これは、地域にかかわる事柄であり、合図されません。 しかしながら、u-PEの操作の詳細とPEsと他のu-PEsとのその相互作用はこのドキュメントの範囲を超えています。
6. Security Considerations
6. セキュリティ問題
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.
Virtual兵士のLAN Serviceの焦点がデータのプライバシーである、すなわち、VPLSのそのデータはどんな外部のエージェントや他のVPLSではなく、そのVPLSの他のノードにも分配されるだけです。 VPLSが秘密性、保全、または認証を提供しないことに注意してください: パケット交換網による明確でVPLSパケットを送って、中央の男性は、盗み聞くことができて、データ・ストリームにパケットを注ぐことができるかもしれません。 セキュリティが望まれているなら、PEからPEへのトンネルはIPsecトンネルであるかもしれません。 より多くのセキュリティのために、VPLSサイトのエンドシステムはService Providerネットワークに入る前にさえ暗号化がそれらのデータを保証する適切な手段を使用できます。
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に別のVPLS、またはblackholing VPLSデータに属させるか、またはそれを立ち聞きする者に送りさえするPEをもたらすかもしれません。 それのいずれもデータプライバシー観点から許容できません。 以来、BGPを通して、[2]などのテクニックは、BGPメッセージを認証するのを助けます、アップデート(VPLS交通を間違ったVPLSに紛らすのに、使用できる)をだますのをより困難にしてことであるか制御飛行機が交換するすべてが引き下がります(サービス不能攻撃)。 また、セクション3で説明されたマルチAS方法(b)と(c)で、これは、相互AS BGPセッションを保護することを意味します、ASBRs、PEs、またはRoute Reflectorsの間で。 また、1つは[6]のセクション10(b)と(c)で説明されたテクニックを使用できます、制御飛行機とデータ飛行機のために。 [2]が、VPLSラベルを個人的に保つのを手伝わないことに注意してください--ラベルを知っていて、1つはVPLS交通を立ち聞きできます。 しかしながら、これはService Providerネットワークの中でデータ経路へのアクセスを必要とします。
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の意図的でない接続に通じるmisconfigurationがあることができます。 例えば、これは、間違ったRoute TargetをVPLS例に関連づけることによって、引き起こされる場合があります。 さらなる研究には[6]によって共有されたこの問題があります。
Kompella & Rekhter Standards Track [Page 22] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[22ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
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の一部であるASの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とGREのMPLSトンネリングは[3]で指定されます。 VPLSパケットを運ぶのにそのようなトンネルを使用するのが必要であるなら、そのドキュメントのセクション8で説明されたセキュリティ問題を完全に理解しなければなりません。 VPLSパケットをそのドキュメントで説明されるようにトンネルを堀らせるVPLSのどんな実現もそこに説明されているとして使用できるIPsecの実現を含まなければなりません。 トンネルがIPsecによって固定されていないなら、そのドキュメントのセクション8.2で説明された境界ルータにおけるIPアドレスフィルタリングのテクニックは特定の出口PEでトンネルを出るパケットが実際に適切なトンネルヘッドノードによってトンネルに置かれたのを確実にする唯一の手段(すなわち、パケットがするのにおいて、だまされたソースアドレスがない)です。 境界ルータが頻繁にソースアドレスだけをフィルターにかけるので、出口PEがそれが受けるどんなトンネルを堀られたパケットのIPソースアドレスもチェックして、有効なトンネルヘッドアドレスであるIPアドレスのリストとそれを比較できないなら、パケットフィルタリングは有効でないかもしれません。 IPにおけるMPLS、そして/または、GREのMPLSトンネリングがIPsecなしで使用されるのを許容するどんな実現でも、出口PEはこの様にそれが受けるどんなトンネルを堀られたパケットのIPソースアドレスも有効にすることができなければなりません。
7. IANA Considerations
7. IANA問題
IANA allocated value (25) for AFI for L2VPN information. This should be the same as the AFI requested by [11].
IANAはL2VPN情報のためのAFIのために値(25)を割り当てました。 これはAFIが[11]から要求したのと同じであるべきです。
IANA allocated an extended community value (0x800a) for the Layer2 Info Extended Community.
IANAは拡張共同体値を割り当てました。(Layer2 Info Extended Communityのための0x800a)。
Kompella & Rekhter Standards Track [Page 23] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[23ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[2] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[3] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in
IP or Generic Routing Encapsulation (GRE)", RFC 4023,
March 2005.
[3] オースター、T.、Rekhter、Y.、およびE.ローゼン、「IPか一般ルーティングのカプセル化(GRE)でMPLSを要約します」、RFC4023(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インチのためのMultiprotocol拡張子、RFC4760、2007年1月。」
[5] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[5] サーングリとS.とタッパン、D.とY.Rekhter、「BGPは共同体属性を広げた」RFC4360、2006年2月。
[6] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006.
[6] ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 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ネットワークの上のイーサネットの輸送のためのカプセル化方法」、RFC4448(2006年4月)。
8.2. Informative References
8.2. 有益な参照
[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)への代替手段」、RFC4456、2006年4月。
[9] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006.
[9] アンデションとL.とE.ローゼン、「層2の仮想私設網(L2VPNs)のための枠組み」、RFC4664、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] エドラセール、M.、エドV.Kompella、「仮想の個人的なLANサービス(VPLS)はラベル分配プロトコル(自由民主党)シグナリングを使用すること」でのRFC4762(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] オールド-Brahim(「VRベースの層-3VPNsに自動発見メカニズムとしてBGPを使用する」H.)は進歩、2006年4月に働いています。
[12] Marques, P., "Constrained VPN Route Distribution", Work in
Progress, June 2005.
[12] P.、「強制的なVPNルート分配」という捕獲許可は進歩、2005年6月に働いています。
Kompella & Rekhter Standards Track [Page 24] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[24ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
[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.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。
[14] Kompella, K., "Layer 2 VPNs Over Tunnels", Work in Progress,
January 2006.
[14] K.、「Tunnelsの上の層2のVPNs」というKompellaは進歩、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/IEC10038の改正です: 1993 802.1j1992 そして、802.6k-1992。 それはP802.11c、P802.1p、およびP802.12eを組み込みます。 ISO/IEC15802-3: 「1998.」 1998年7月のIEEEの標準の802.1D。
Kompella & Rekhter Standards Track [Page 25] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[25ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
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
ハビエルAchirica、テレフォニカのLoaアンデション、Acreoジャイルスサギ、Tellabs Sunilカンデーカル、アルカテル透明なChaitanya Kodeboyina、ヌオーヴァシステムVach Kompella、アルカテル透明なマーク・ラセール、アルカテル透明なピアー・リンパスカルメネゼスAshwin Moranganti、Appianハミドオールド-Brahim、ノーテル、Seo Yeong、-、不-、韓国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をありがとうございます。 また、彼らの詳細なレビューのためにエリックJi、Chaitanya Kodeboyina、マイク・ルーミス、およびElwynデイヴィースをありがとうございます。
Kompella & Rekhter Standards Track [Page 26] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[26ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
Editors' Addresses
エディタのアドレス
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
Kireeti Kompella杜松は1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア94089米国
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
ヤコフRekhter Juniperは1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア94089米国
EMail: yakov@juniper.net
メール: yakov@juniper.net
Kompella & Rekhter Standards Track [Page 27] RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007
Kompella&Rekhter標準化過程[27ページ]RFC4761BGP自動発見と2007年1月にVPLSのために合図すること。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Kompella & Rekhter Standards Track [Page 28]
Kompella&Rekhter標準化過程[28ページ]
一覧
スポンサーリンク
