RFC4762 日本語訳
4762 Virtual Private LAN Service (VPLS) Using Label DistributionProtocol (LDP) Signaling. M. Lasserre, Ed., V. Kompella, Ed.. January 2007. (Format: TXT=82778 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Lasserre, Ed.
Request for Comments: 4762 V. Kompella, Ed.
Category: Standards Track Alcatel-Lucent
January 2007
ワーキンググループのM.ラセール、エドをネットワークでつないでください。コメントのために以下を要求してください。 エド4762V.Kompella、カテゴリ: 2007年1月にアルカテル透明な標準化過程
Virtual Private LAN Service (VPLS) Using
Label Distribution Protocol (LDP) Signaling
ラベル分配プロトコル(自由民主党)シグナリングを使用する仮想の個人的な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 4761 and this document, that perform similar functions using different signaling protocols. Be aware that each method is commonly referred to as "VPLS" even though they are distinct and incompatible with one another.
L2VPN作業部会は2通の別々のドキュメント、RFC4761、およびこのドキュメントを製作して、それは、異なったシグナリングプロトコルを使用することで同様の機能を実行します。 彼らがお互いと異なって非互換ですが、各メソッドが一般的に「VPLS」と呼ばれるのを意識してください。
Abstract
要約
This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.
このドキュメントはpseudowiresを使用することでVirtual兵士のLAN Service(VPLS)ソリューションについて説明します、以前に、他のトンネリング技術の上で実装されて、Transparent LAN Services(TLS)として知られているサービス。 VPLSは与えられたセットのユーザのための見習われたLANセグメントを作成します。 すなわち、それはイーサネットMACでアドレスを学んで、完全に転送できて、非公開であるに対して与えられたセットのユーザLayer2放送ドメインを作成します。 独身のProvider Edge(PE)ノードから複数のVPLSサービスをサポートすることができます。
This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448.
このドキュメントはRFC4447を広げていて、Label Distributionプロトコル(自由民主党)を使用することでpseudowireラベルに合図するコントロール飛行機機能について説明します。 それは発見プロトコルに不可知論者です。 また、MACアドレスの習得に特に焦点を合わせて、推進のデータ飛行機機能は説明されます。 VPLSパケットのカプセル化はRFC4448によって説明されます。
Lasserre & Kompella Standards Track [Page 1] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Conventions ................................................4
3. Acronyms ........................................................4
4. Topological Model for VPLS ......................................5
4.1. Flooding and Forwarding ....................................6
4.2. Address Learning ...........................................6
4.3. Tunnel Topology ............................................7
4.4. Loop free VPLS .............................................7
5. Discovery .......................................................7
6. Control Plane ...................................................7
6.1. LDP-Based Signaling of Demultiplexers ......................8
6.1.1. Using the Generalized PWid FEC Element ..............8
6.2. MAC Address Withdrawal .....................................9
6.2.1. MAC List TLV ........................................9
6.2.2. Address Withdraw Message Containing MAC List TLV ...11
7. Data Forwarding on an Ethernet PW ..............................11
7.1. VPLS Encapsulation Actions ................................11
7.2. VPLS Learning Actions .....................................12
8. Data Forwarding on an Ethernet VLAN PW .........................13
8.1. VPLS Encapsulation Actions ................................13
9. Operation of a VPLS ............................................14
9.1. MAC Address Aging .........................................15
10. A Hierarchical VPLS Model .....................................16
10.1. Hierarchical Connectivity ................................16
10.1.1. Spoke Connectivity for Bridging-Capable Devices ...17
10.1.2. Advantages of Spoke Connectivity ..................18
10.1.3. Spoke Connectivity for Non-Bridging Devices .......19
10.2. Redundant Spoke Connections ..............................21
10.2.1. Dual-Homed MTU-s ..................................21
10.2.2. Failure Detection and Recovery ....................22
10.3. Multi-domain VPLS Service ................................23
11. Hierarchical VPLS Model Using Ethernet Access Network .........23
11.1. Scalability ..............................................24
11.2. Dual Homing and Failure Recovery .........................24
12. Contributors ..................................................25
13. Acknowledgements ..............................................25
14. Security Considerations .......................................26
15. IANA Considerations ...........................................26
16. References ....................................................27
16.1. Normative References .....................................27
16.2. Informative References ...................................27
Appendix A. VPLS Signaling using the PWid FEC Element .............29
1. 序論…3 2. 用語…3 2.1. コンベンション…4 3. 頭文字語…4 4. VPLSの位相的なモデル…5 4.1. 氾濫と推進…6 4.2. 学習を扱ってください…6 4.3. トポロジーにトンネルを堀ってください…7 4.4. 自由なVPLSを輪にしてください…7 5. 発見…7 6. 飛行機を制御してください…7 6.1. デマルチプレクサの自由民主党ベースのシグナリング…8 6.1.1. 一般化されたPWid FEC要素を使用します…8 6.2. マックーアドレス退出…9 6.2.1. MACはTLVを記載します…9 6.2.2. アドレスはMACリストTLVを含むメッセージを引き下がらせます…11 7. イーサネットPWにおけるデータ推進…11 7.1. VPLSカプセル化動作…11 7.2. VPLS学習動作…12 8. イーサネットVLAN PWにおけるデータ推進…13 8.1. VPLSカプセル化動作…13 9. VPLSの操作…14 9.1. マックーアドレスの年をとること…15 10. 階層的なVPLSはモデル化します…16 10.1. 階層的な接続性…16 10.1.1. ブリッジするできるデバイスのために接続性を話しました…17 10.1.2. スポークの接続性の利点…18 10.1.3. 非のブリッジするデバイスのために接続性を話しました…19 10.2. 余分なスポークコネクションズ…21 10.2.1. 二元的である、-、家へ帰り、MTU-s…21 10.2.2. 失敗検出と回復…22 10.3. マルチドメインVPLSサービス…23 11. イーサネットアクセスネットワークを使用して、階層的なVPLSはモデル化します…23 11.1. スケーラビリティ…24 11.2. デュアルホーミングと失敗回復…24 12. 貢献者…25 13. 承認…25 14. セキュリティ問題…26 15. IANA問題…26 16. 参照…27 16.1. 標準の参照…27 16.2. 有益な参照…27 PWid FEC要素を使用することで合図する付録A.VPLS…29
Lasserre & Kompella Standards Track [Page 2] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[2ページ]。
1. Introduction
1. 序論
Ethernet has become the predominant technology for Local Area Network (LAN) connectivity and is gaining acceptance as an access technology, specifically in Metropolitan and Wide Area Networks (MAN and WAN, respectively). The primary motivation behind Virtual Private LAN Services (VPLS) is to provide connectivity between geographically dispersed customer sites across MANs and WANs, as if they were connected using a LAN. The intended application for the end-user can be divided into the following two categories:
イーサネットは、ローカル・エリア・ネットワーク(LAN)の接続性のために支配的な技術になって、アクセス技術として承認を獲得しています、特にMetropolitanとワイドエリアネットワーク(それぞれMANとWAN)で。 Virtual兵士のLAN Services(VPLS)の後ろのプライマリ動機はMANsとWANの向こう側に地理的に分散している顧客サイトの間に接続性を提供することです、まるでそれらがLANを使用することで接続されるかのように。 エンドユーザの意図しているアプリケーションを以下の2つのカテゴリに分割できます:
- Connectivity between customer routers: LAN routing application
- 顧客ルータの間の接続性: LANルーティングアプリケーション
- Connectivity between customer Ethernet switches: LAN switching
application
- 顧客イーサネットスイッチの間の接続性: LAN切り換えアプリケーション
Broadcast and multicast services are available over traditional LANs. Sites that belong to the same broadcast domain and that are connected via an MPLS network expect broadcast, multicast, and unicast traffic to be forwarded to the proper location(s). This requires MAC address learning/aging on a per-pseudowire basis, and packet replication across pseudowires for multicast/broadcast traffic and for flooding of unknown unicast destination traffic.
放送とマルチキャストサービスは伝統的なLANの上で利用可能です。 同じ放送ドメインに属すサイトとそれは適切な位置に送られるネットワークが放送すると予想するMPLS、マルチキャスト、およびユニキャストトラフィックでつなげられます。 これはマルチキャスト/放送トラフィックと未知のユニキャスト目的地トラフィックの氾濫でpseudowiresの向こう側に1pseudowireあたり1個のベースで学習/古いMACアドレス、およびパケット模写を必要とします。
[RFC4448] defines how to carry Layer 2 (L2) frames over point-to- point pseudowires (PW). This document describes extensions to [RFC4447] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic across multiple sites that belong to the same L2 broadcast domain or VPLS. Note that the same model can be applied to other 802.1 technologies. It describes a simple and scalable way to offer Virtual LAN services, including the appropriate flooding of broadcast, multicast, and unknown unicast destination traffic over MPLS, without the need for address resolution servers or other external servers, as discussed in [L2VPN-REQ].
[RFC4448]はポイントからポイントの上のLayer2(L2)フレームpseudowires(PW)を運ぶ方法を定義します。 このドキュメントは、同じL2放送ドメインに属す複数のサイトかVPLSの向こう側にイーサネット/802.3とVLAN[802.1Q]トラフィックを輸送するために[RFC4447]に拡大について説明します。 他の802.1の技術に同じモデルを適用できることに注意してください。 それはバーチャルLANサービスを提供する簡単でスケーラブルな方法を述べます、MPLSの上に放送、マルチキャスト、および未知のユニキャスト目的地トラフィックの適切な氾濫を含んでいて、アドレス解決サーバか他の外部のサーバの必要性なしで、[L2VPN-REQ]で議論するように。
The following discussion applies to devices that are VPLS capable and have a means of tunneling labeled packets amongst each other. The resulting set of interconnected devices forms a private MPLS VPN.
以下の議論はできるVPLSであり、互いの中にトンネリングの手段をパケットとラベルするデバイスに適用されます。 結果として起こるセットのインタコネクトされたデバイスは個人的なMPLS VPNを形成します。
2. Terminology
2. 用語
Q-in-Q 802.1ad Provider Bridge extensions also known
as stackable VLANs or Q-in-Q.
また、stackable VLANsかQのQとして知られているQのQ802.1ad Provider Bridge拡張子。
Qualified learning Learning mode in which each customer VLAN is
mapped to its own VPLS instance.
それぞれの顧客VLANがそれ自身のVPLSインスタンスに写像される適切な学習Learningモード。
Lasserre & Kompella Standards Track [Page 3] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[3ページ]。
Service delimiter Information used to identify a specific customer
service instance. This is typically encoded in
the encapsulation header of customer frames
(e.g., VLAN Id).
サービスデリミタ情報は以前はよく特定の顧客サービスインスタンスを特定していました。 これは顧客フレーム(例えば、VLAN Id)のカプセル化ヘッダーで通常コード化されます。
Tagged frame Frame with an 802.1Q VLAN identifier.
802.1Q VLAN識別子があるタグ付けをされたフレームFrame。
Unqualified learning Learning mode where all the VLANs of a single
customer are mapped to a single VPLS.
独身の顧客のすべてのVLANsが独身のVPLSに写像される資格のない学習Learningモード。
Untagged frame Frame without an 802.1Q VLAN identifier.
802.1Q VLAN識別子なしでフレームFrameをUntaggedしました。
2.1. Conventions
2.1. コンベンション
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Acronyms
3. 頭文字語
AC Attachment Circuit
交流付属回路
BPDU Bridge Protocol Data Unit
BPDUブリッジプロトコルデータ単位
CE Customer Edge device
CE Customer Edgeデバイス
FEC Forwarding Equivalence Class
FEC推進同値類
FIB Forwarding Information Base
空言推進Information基地
GRE Generic Routing Encapsulation
GRE一般ルーティングのカプセル化
IPsec IP security
IPsec IPセキュリティ
L2TP Layer Two Tunneling Protocol
L2TP層Twoのトンネリングプロトコル
LAN Local Area Network
LANローカル・エリア・ネットワーク
LDP Label Distribution Protocol
自由民主党ラベル分配プロトコル
MTU-s Multi-Tenant Unit switch
MTU-s Multi-テナントUnitスイッチ
PE Provider Edge device
PE Provider Edgeデバイス
PW Pseudowire
PW Pseudowire
STP Spanning Tree Protocol
STPスパニングツリープロトコル
Lasserre & Kompella Standards Track [Page 4] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[4ページ]。
VLAN Virtual LAN
VLANバーチャルLAN
VLAN tag VLAN Identifier
VLANタグVLAN Identifier
4. Topological Model for VPLS
4. VPLSの位相モデル
An interface participating in a VPLS must be able to flood, forward, and filter Ethernet frames. Figure 1, below, shows the topological model of a VPLS. The set of PE devices interconnected via PWs appears as a single emulated LAN to customer X. Each PE will form remote MAC address to PW associations and associate directly attached MAC addresses to local customer facing ports. This is modeled on standard IEEE 802.1 MAC address learning.
VPLSに参加するインタフェースは、前方に浸水して、イーサネットフレームをフィルターにかけることができなければなりません。 図1は以下にVPLSの位相モデルを示しています。 顧客X.Each PEへのただ一つの見習われたLANがリモートMACアドレスをPW協会に形成して、直接添付のMACアドレスを地方の顧客面しているポートに関連づけるのに従って、PWsを通してインタコネクトされたPEデバイスのセットは現れます。 標準のIEEE802.1MACアドレス学習はこれに似せられます。
+-----+ +-----+
| CE1 +---+ ........................... +---| CE2 |
+-----+ | . . | +-----+
Site 1 | +----+ +----+ | Site 2
+---| PE | Cloud | PE |---+
+----+ +----+
. .
. +----+ .
..........| PE |...........
+----+ ^
| |
| +-- Emulated LAN
+-----+
| CE3 |
+-----+
Site 3
+-----+ +-----+ | CE1+---+ ........................... +---| CE2| +-----+ | . . | +-----+ サイト1| +----+ +----+ | サイト2+---| PE| 雲| PE|---+ +----+ +----+ . . . +----+ . ..........| PE|........... +----+ ^ | | | +--見習われたLAN+-----+ | CE3| +-----+ サイト3
Figure 1: Topological Model of a VPLS for
Customer X with three sites
図1: 3つのサイトがあるCustomer XのためのVPLSの位相的なModel
We note here again that while this document shows specific examples using MPLS transport tunnels, other tunnels that can be used by PWs (as mentioned in [RFC4447]) -- e.g., GRE, L2TP, IPsec -- can also be used, as long as the originating PE can be identified, since this is used in the MAC learning process.
私たちは、ここでまた、一方、このドキュメントがMPLS輸送トンネルを使用することで特定の例を示している間PWs([RFC4447]で言及されるように)が使用できる他のトンネル(例えば、GRE、L2TP、IPsec)を使用できることに注意します、起因しているPEを特定できる限り、これがMAC学習過程で使用されるので。
The scope of the VPLS lies within the PEs in the service provider network, highlighting the fact that apart from customer service delineation, the form of access to a customer site is not relevant to the VPLS [L2VPN-REQ]. In other words, the attachment circuit (AC) connected to the customer could be a physical Ethernet port, a logical (tagged) Ethernet port, an ATM PVC carrying Ethernet frames, etc., or even an Ethernet PW.
VPLSの範囲はサービスプロバイダーネットワークでPEsに属します、顧客サービス輪郭描写は別として顧客サイトへのアクセスのフォームがVPLS[L2VPN-REQ]に関連していないという事実を目立たせて。 言い換えれば、顧客につなげられた付属回路(西暦)は、物理的なイーサネットポート、論理的な(タグ付けをされた)イーサネットポート、イーサネットフレームなどを運ぶATM PVC、またはイーサネットPWでさえあるかもしれません。
Lasserre & Kompella Standards Track [Page 5] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[5ページ]。
The PE is typically an edge router capable of running the LDP signaling protocol and/or routing protocols to set up PWs. In addition, it is capable of setting up transport tunnels to other PEs and delivering traffic over PWs.
通常、PEはPWsをセットアップするために自由民主党シグナリングプロトコル、そして/または、ルーティング・プロトコルを実行できる縁のルータです。 さらに、それは、他のPEsに輸送トンネルを設立して、PWsの上にトラフィックを提供できます。
4.1. Flooding and Forwarding
4.1. 氾濫と推進
One of attributes of an Ethernet service is that frames sent to broadcast addresses and to unknown destination MAC addresses are flooded to all ports. To achieve flooding within the service provider network, all unknown unicast, broadcast and multicast frames are flooded over the corresponding PWs to all PE nodes participating in the VPLS, as well as to all ACs.
イーサネットサービスの属性の1つは放送演説と、そして、未知の送付先MACアドレスに送られたフレームがすべてのポートへあふれるということです。 サービスプロバイダーネットワークの中で氾濫を達成するために、すべての未知のユニキャスト、放送、およびマルチキャストフレームはすべてのPEノードへの対応するPWsの上でVPLSに参加するのにおいて水につかっています、よくすべてのACsのように。
Note that multicast frames are a special case and do not necessarily have to be sent to all VPN members. For simplicity, the default approach of broadcasting multicast frames is used.
マルチキャストフレームが特別なケースであり、必ずすべてのVPNメンバーに送られる必要はないことに注意してください。 簡単さにおいて、放送マルチキャストフレームのデフォルトアプローチは使用されています。
To forward a frame, a PE MUST be able to associate a destination MAC address with a PW. It is unreasonable and perhaps impossible to require that PEs statically configure an association of every possible destination MAC address with a PW. Therefore, VPLS-capable PEs SHOULD have the capability to dynamically learn MAC addresses on both ACs and PWs and to forward and replicate packets across both ACs and PWs.
フレーム、PE MUSTを進めるには、送付先MACアドレスをPWに関連づけることができてください。 PEsがPWで静的にあらゆる可能な送付先MACアドレスの協会を構成するのが必要であるのは、無理であって、恐らく不可能です。 したがって、VPLSできるPEs SHOULDには、ACsとPWsの両方の向こう側にパケットをダイナミックにACsとPWsの両方に関するMACアドレスを学んで、進めて、模写する能力があります。
4.2. Address Learning
4.2. アドレス学習
Unlike BGP VPNs [RFC4364], reachability information is not advertised and distributed via a control plane. Reachability is obtained by standard learning bridge functions in the data plane.
BGP VPNs[RFC4364]と異なって、可到達性情報は、制御飛行機を通して広告を出して、分配されません。 データ飛行機での標準のラーニングブリッジ機能は可到達性を得ます。
When a packet arrives on a PW, if the source MAC address is unknown, it needs to be associated with the PW, so that outbound packets to that MAC address can be delivered over the associated PW. Likewise, when a packet arrives on an AC, if the source MAC address is unknown, it needs to be associated with the AC, so that outbound packets to that MAC address can be delivered over the associated AC.
ソースMACアドレスが未知であるならパケットがPWで到着するとき、PWに関連しているのが必要です、そのMACアドレスへの外国行きのパケットを関連PWの上に提供できるように。 ソースMACアドレスが未知であるならパケットが西暦で到着するとき、同様に、西暦に関連しているのが必要です、そのMACアドレスへの外国行きのパケットを関連西暦の上に提供できるように。
Standard learning, filtering, and forwarding actions, as defined in [802.1D-ORIG], [802.1D-REV], and [802.1Q], are required when a PW or AC state changes.
標準の学習、PWか交流状態が変化するとき、[802.1D-ORIG]、[802.1D-REV]、および[802.1Q]で定義されるように動作をフィルターにかけて、進めるのが必要です。
Lasserre & Kompella Standards Track [Page 6] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[6ページ]。
4.3. Tunnel Topology
4.3. トンネルトポロジー
PE routers are assumed to have the capability to establish transport tunnels. Tunnels are set up between PEs to aggregate traffic. PWs are signaled to demultiplex encapsulated Ethernet frames from multiple VPLS instances that traverse the transport tunnels.
PEルータには輸送トンネルを確立する能力があると思われます。 トンネルは、トラフィックに集めるためにPEsの間でセットアップされます。 PWsは輸送トンネルを横断する複数のVPLSインスタンスからイーサネットフレームであるとカプセル化された「反-マルチプレックス」に合図されます。
In an Ethernet L2VPN, it becomes the responsibility of the service provider to create the loop-free topology. For the sake of simplicity, we define that the topology of a VPLS is a full mesh of PWs.
イーサネットL2VPNでは、無輪のトポロジーを作成するのはサービスプロバイダーの責任になります。 簡単にするために、私たちはそれを定義します。VPLSのトポロジーはPWsの完全なメッシュです。
4.4. Loop free VPLS
4.4. 自由なVPLSを輪にしてください。
If the topology of the VPLS is not restricted to a full mesh, then it may be that for two PEs not directly connected via PWs, they would have to use an intermediary PE to relay packets. This topology would require the use of some loop-breaking protocol, like a spanning tree protocol.
VPLSのトポロジーが完全なメッシュに制限されないなら、多分、PWsを通して直接接続されなかった2PEsに関して彼らは、パケットをリレーするのに仲介者PEを使用しなければならないでしょう。 このトポロジーはスパニングツリープロトコルのような何らかの輪を壊すプロトコルの使用を必要とするでしょう。
Instead, a full mesh of PWs is established between PEs. Since every PE is now directly connected to every other PE in the VPLS via a PW, there is no longer any need to relay packets, and we can instantiate a simpler loop-breaking rule: the "split horizon" rule, whereby a PE MUST NOT forward traffic from one PW to another in the same VPLS mesh.
代わりに、PWsの完全なメッシュはPEsの間に設立されます。 あらゆるPEが現在PWを通して直接VPLSの他のあらゆるPEに接続されるので、パケットをリレーする少しの必要ももうありません、そして、私たちは、より簡単な輪を壊す規則を例示できます: 「分裂地平線」規則。(同じVPLSの1PWから別のPWまでのPE MUST NOTの前進のトラフィックはその規則でかみ合います)。
Note that customers are allowed to run a Spanning Tree Protocol (STP) (e.g., as defined in [802.1D-REV]), such as when a customer has "back door" links used to provide redundancy in the case of a failure within the VPLS. In such a case, STP Bridge PDUs (BPDUs) are simply tunneled through the provider cloud.
顧客が失敗に関するケースに冗長を供給するのにVPLSの中で「裏口」リンクを使用させる時のように顧客がSpanning Treeプロトコル(STP)を実行できることに(例えば、[802.1D-REV]で定義されるように)注意してください。 このような場合には、STP Bridge PDUs(BPDUs)はプロバイダー雲を通して単にトンネルを堀られます。
5. Discovery
5. 発見
The capability to manually configure the addresses of the remote PEs is REQUIRED. However, the use of manual configuration is not necessary if an auto-discovery procedure is used. A number of auto- discovery procedures are compatible with this document ([RADIUS-DISC], [BGP-DISC]).
手動でリモートPEsのアドレスを構成する能力はREQUIREDです。 しかしながら、自動発見手順が使用されているなら、手動の構成の使用は必要ではありません。 [BGP-DISC)、多くの自動発見手順がこのドキュメント[RADIUS-DISC]と互換性があります。
6. Control Plane
6. 制御飛行機
This document describes the control plane functions of signaling of PW labels. Some foundational work in the area of support for multi- homing is laid. The extensions to provide multi-homing support should work independently of the basic VPLS operation, and they are not described here.
このドキュメントはPWラベルのシグナリングのコントロール飛行機機能について説明します。 マルチの家へ帰りのサポートの領域でのいくらかの基礎的な仕事が横たえられます。 マルチホーミングサポートを提供する拡大は基本的なVPLS操作の如何にかかわらず働くべきです、そして、彼らはここで説明されません。
Lasserre & Kompella Standards Track [Page 7] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[7ページ]。
6.1. LDP-Based Signaling of Demultiplexers
6.1. デマルチプレクサの自由民主党ベースのシグナリング
A full mesh of LDP sessions is used to establish the mesh of PWs. The requirement for a full mesh of PWs may result in a large number of targeted LDP sessions. Section 10 discusses the option of setting up hierarchical topologies in order to minimize the size of the VPLS full mesh.
自由民主党のセッションの完全なメッシュは、PWsのメッシュを証明するのに使用されます。 PWsの完全なメッシュのための要件は多くの狙っている自由民主党のセッションのときに結果として生じるかもしれません。 セクション10はVPLSの完全なメッシュのサイズを最小にするために階層的なtopologiesをセットアップするオプションについて論じます。
Once an LDP session has been formed between two PEs, all PWs between these two PEs are signaled over this session.
自由民主党のセッションが2PEsの間でいったん形成されると、これらの2PEsの間のすべてのPWsがこのセッションの間、合図されます。
In [RFC4447], two types of FECs are described: the PWid FEC Element (FEC type 128) and the Generalized PWid FEC Element (FEC type 129). The original FEC element used for VPLS was compatible with the PWid FEC Element. The text for signaling using the PWid FEC Element has been moved to Appendix A. What we describe below replaces that with a more generalized L2VPN descriptor, the Generalized PWid FEC Element.
[RFC4447]では、FECsの2つのタイプが説明されます: PWid FEC Element(FECは128をタイプする)とGeneralized PWid FEC Element(FECは129をタイプします)。 VPLSに使用される元のFEC要素はPWid FEC Elementと互換性がありました。 PWid FEC Elementを使用するシグナリングがAppendix A.Whatに動かされて、私たちが下について説明するということであるので、テキストはそれをさらに一般化されたL2VPN記述子(Generalized PWid FEC Element)に取り替えます。
6.1.1. Using the Generalized PWid FEC Element
6.1.1. 一般化されたPWid FEC要素を使用します。
[RFC4447] describes a generalized FEC structure that is be used for VPLS signaling in the following manner. We describe the assignment of the Generalized PWid FEC Element fields in the context of VPLS signaling.
[RFC4447]は以下の方法でVPLSシグナリングにおいて使用されていた状態であることである一般化されたFEC構造について説明します。 私たちはVPLSシグナリングの文脈における、Generalized PWid FEC Element分野の課題について説明します。
Control bit (C): This bit is used to signal the use of the control word as specified in [RFC4447].
ビット(C)を制御してください: このビットは、[RFC4447]の指定されるとしての規制単語の使用に合図するのに使用されます。
PW type: The allowed PW types are Ethernet (0x0005) and Ethernet tagged mode (0x004), as specified in [RFC4446].
PWはタイプします: 許容PWタイプは、[RFC4446]で指定されるようにイーサネット(0×0005)とイーサネットのタグ付けをされたモード(0×004)です。
PW info length: As specified in [RFC4447].
PWインフォメーションの長さ: [RFC4447]で指定されるように。
Attachment Group Identifier (AGI), Length, Value: The unique name of this VPLS. The AGI identifies a type of name, and Length denotes the length of Value, which is the name of the VPLS. We use the term AGI interchangeably with VPLS identifier.
付属グループ識別子(AGI)、長さは以下を評価します。 このVPLSというユニークな名前。 AGIは一種の名前を特定します、そして、LengthはValueの長さを指示します。(ValueはVPLSという名前です)。 私たちはVPLS識別子と共にAGIという用語を互換性を持って使用します。
Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null because the mesh of PWs in a VPLS terminates on MAC learning tables, rather than on individual attachment circuits. The use of non-null TAII and SAII is reserved for future enhancements.
付属の個々の識別子(TAII)、ソースの付属の個々の識別子(SAII)を狙ってください: VPLSのPWsのメッシュが個々の付属回路の上にというよりむしろMAC学習テーブルで終わるので、これらはヌルです。 非ヌルTAIIとSAIIの使用は今後の増進のために控えられます。
Lasserre & Kompella Standards Track [Page 8] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[8ページ]。
Interface Parameters: The relevant interface parameters are:
パラメタを連結してください: 関連インタフェース・パラメータは以下の通りです。
- MTU: The MTU (Maximum Transmission Unit) of the VPLS MUST be the
same across all the PWs in the mesh.
- MTU: MTU、(最大のTransmission Unit) VPLS MUSTでは、メッシュのすべてのPWsの向こう側に同じであってください。
- Optional Description String: Same as [RFC4447].
- 任意の記述ストリング: [RFC4447]と同じです。
- Requested VLAN ID: If the PW type is Ethernet tagged mode, this
parameter may be used to signal the insertion of the appropriate
VLAN ID, as defined in [RFC4448].
- VLAN IDは要求しました: PWタイプがイーサネットのタグ付けをされたモードであるなら、このパラメタは適切なVLAN IDの挿入に合図するのに使用されるかもしれません、[RFC4448]で定義されるように。
6.2. MAC Address Withdrawal
6.2. マックーアドレス退出
It MAY be desirable to remove or unlearn MAC addresses that have been dynamically learned for faster convergence. This is accomplished by sending an LDP Address Withdraw Message with the list of MAC addresses to be removed to all other PEs over the corresponding LDP sessions.
より速い集合のためにダイナミックに学習されたMACアドレスを取り除くか、または忘れるのが望ましいかもしれません。 これはMACアドレスのリストで自由民主党Address Withdraw Messageを送ることによって達成されて、対応する自由民主党のセッションの間、他のすべてのPEsに移されます。
We introduce an optional MAC List TLV in LDP to specify a list of MAC addresses that can be removed or unlearned using the LDP Address Withdraw Message.
私たちは、自由民主党Address Withdraw Messageを使用することで取り除くか、または忘れることができるMACアドレスのリストを指定するために自由民主党で任意のMAC List TLVを導入します。
The Address Withdraw message with MAC List TLVs MAY be supported in order to expedite removal of MAC addresses as the result of a topology change (e.g., failure of the primary link for a dual-homed VPLS-capable switch).
MAC List TLVsがあるAddress Withdrawメッセージがトポロジー変化の結果としてMACアドレスの取り外しを速めるためにサポートされるかもしれない、(例えば、aのためのプライマリリンクの失敗、二元的である、-、家へ帰り、VPLSできるスイッチ)
In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list.
自由民主党集合時間に影響を最小にするために、空のリストがあるMACアドレス退出メッセージを送るのは望ましいかもしれません。(その時、MACリストTLVは多くのMACアドレスを含みます)。
6.2.1. MAC List TLV
6.2.1. MACリストTLV
MAC addresses to be unlearned can be signaled using an LDP Address Withdraw Message that contains a new TLV, the MAC List TLV. Its format is described below. The encoding of a MAC List TLV address is the 6-octet MAC address specified by IEEE 802 documents [802.1D-ORIG] [802.1D-REV].
新しいTLVを含む自由民主党Address Withdraw Messageを使用することで忘れられるべきMACアドレスに合図できます、MAC List TLV。 形式は以下で説明されます。 MAC List TLVアドレスのコード化はIEEE802ドキュメント[802.1D-ORIG][802.1D-REV]によって指定された6八重奏のMACアドレスです。
Lasserre & Kompella Standards Track [Page 9] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[9ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | MAC Address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MACアドレス#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MACアドレス#1| マックーアドレス#2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MACアドレス#2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MACアドレス#n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MACアドレス#n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit: Unknown bit. This bit MUST be set to 1. If the MAC address format is not understood, then the TLV is not understood and MUST be ignored.
Uに噛み付きました: 未知のビット。 このビットを1に設定しなければなりません。 MACアドレス形式が理解されていないなら、TLVを理解されないで、無視しなければなりません。
F bit: Forward bit. This bit MUST be set to 0. Since the LDP mechanism used here is targeted, the TLV MUST NOT be forwarded.
Fに噛み付きました: ビットを進めてください。 このビットを0に設定しなければなりません。 以来ここで使用された自由民主党メカニズムが狙う、TLV MUST NOT、進めてください。
Type: Type field. This field MUST be set to 0x0404. This identifies the TLV type as MAC List TLV.
以下をタイプしてください。 分野をタイプしてください。 この分野を0×0404に設定しなければなりません。 これは、TLVタイプがMAC List TLVであると認識します。
Length: Length field. This field specifies the total length in octets of the MAC addresses in the TLV. The length MUST be a multiple of 6.
長さ: 長さの分野。 この分野はTLVのMACアドレスの八重奏で全長を指定します。 長さは6の倍数であるに違いありません。
MAC Address: The MAC address(es) being removed.
マックーアドレス: MACは取り除かれる(es)を扱います。
The MAC Address Withdraw Message contains a FEC TLV (to identify the VPLS affected), a MAC Address TLV, and optional parameters. No optional parameters have been defined for the MAC Address Withdraw signaling. Note that if a PE receives a MAC Address Withdraw Message and does not understand it, it MUST ignore the message. In this case, instead of flushing its MAC address table, it will continue to use stale information, unless:
マックーアドレスWithdraw MessageはFEC TLV(影響を受けるVPLSを特定する)、マックーアドレスTLV、および任意のパラメタを含んでいます。 どんな任意のパラメタもマックーアドレスWithdrawシグナリングのために定義されていません。 PEがマックーアドレスWithdraw Messageを受けて、それを理解していないなら、メッセージを無視しなければならないことに注意してください。 この場合MACアドレス・テーブルを洗い流すことの代わりに聞き古した情報を使用し続ける、:
- it receives a packet with a known MAC address association, but
from a different PW, in which case it replaces the old
association; or
- それは知られているMACアドレス関係が、異なったPWからパケットを受けます、その場合、古い協会に取って代わります。 または
- it ages out the old association.
- それは古い協会から年をとります。
Lasserre & Kompella Standards Track [Page 10] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[10ページ]。
The MAC Address Withdraw message only helps speed up convergence, so PEs that do not understand the message can continue to participate in the VPLS.
マックーアドレスWithdrawメッセージが加速集合を助けるだけであるので、メッセージを理解していないPEsは、VPLSに参加し続けることができます。
6.2.2. Address Withdraw Message Containing MAC List TLV
6.2.2. アドレスはMACリストTLVを含むメッセージを引き下がらせます。
The processing for MAC List TLV received in an Address Withdraw Message is:
Address Withdraw Messageに受け取られたMAC List TLVのための処理は以下の通りです。
For each MAC address in the TLV:
各MACに関しては、TLVで以下を扱ってください。
- Remove the association between the MAC address and the AC or PW
over which this message is received.
- このメッセージが受信されているMACアドレスと西暦かPWの間との協会を取り除いてください。
For a MAC Address Withdraw message with empty list:
空のリストがあるマックーアドレスWithdrawメッセージのために:
- Remove all the MAC addresses associated with the VPLS instance
(specified by the FEC TLV) except the MAC addresses learned over
the PW associated with this signaling session over which the
message was received.
- メッセージが受け取られたこのシグナリングセッションに関連しているPWの上で学習されたMACアドレスを除いて、VPLSインスタンス(FEC TLVによって指定される)に関連しているすべてのMACアドレスを取り除いてください。
The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV.
MAC List TLVの範囲はマックーアドレスWithdraw MessageのFEC TLVで指定されたVPLSです。 TLVの長さの分野からMACアドレスの数を推論できます。
7. Data Forwarding on an Ethernet PW
7. イーサネットでPWを進めるデータ
This section describes the data plane behavior on an Ethernet PW used in a VPLS. While the encapsulation is similar to that described in [RFC4448], the functions of stripping the service-delimiting tag and using a "normalized" Ethernet frame are described.
このセクションはVPLSで使用されるイーサネットPWでデータ飛行機の振舞いについて説明します。 カプセル化が[RFC4448]で説明されたそれと同様である間、サービスを区切るタグを剥取って、「正常にされた」イーサネットフレームを使用する機能は説明されます。
7.1. VPLS Encapsulation Actions
7.1. VPLSカプセル化動作
In a VPLS, a customer Ethernet frame without preamble is encapsulated with a header as defined in [RFC4448]. A customer Ethernet frame is defined as follows:
VPLSでは、序文のない顧客イーサネットフレームはヘッダーと共に[RFC4448]で定義されるようにカプセル化されます。 顧客イーサネットフレームは以下の通り定義されます:
- If the frame, as it arrives at the PE, has an encapsulation that
is used by the local PE as a service delimiter, i.e., to identify
the customer and/or the particular service of that customer, then
that encapsulation may be stripped before the frame is sent into
the VPLS. As the frame exits the VPLS, the frame may have a
service-delimiting encapsulation inserted.
- PEに到着するときフレームにすなわちその顧客の顧客、そして/または、特定のサービスを特定するのにサービスデリミタとして地方のPEが使用されるカプセル化があるなら、フレームをVPLSに送る前にそのカプセル化を剥取るかもしれません。 フレームがVPLSを出るとき、フレームで、サービスを区切るカプセル化を挿入するかもしれません。
Lasserre & Kompella Standards Track [Page 11] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[11ページ]。
- If the frame, as it arrives at the PE, has an encapsulation that
is not service delimiting, then it is a customer frame whose
encapsulation should not be modified by the VPLS. This covers,
for example, a frame that carries customer-specific VLAN tags that
the service provider neither knows about nor wants to modify.
- PEに到着するときフレームにサービスの区切りでないカプセル化があるなら、それはカプセル化がVPLSによって変更されるはずがない顧客フレームです。 これは例えばサービスプロバイダーがどちらも知らないで、変更したがっている顧客特有のVLANタグを運ぶフレームを覆っています。
As an application of these rules, a customer frame may arrive at a customer-facing port with a VLAN tag that identifies the customer's VPLS instance. That tag would be stripped before it is encapsulated in the VPLS. At egress, the frame may be tagged again, if a service-delimiting tag is used, or it may be untagged if none is used.
これらの規則の適用として、顧客フレームは顧客のVPLS例を特定するVLANタグと共に顧客に面するポートに到着するかもしれません。 VPLSでそれを要約する前にそのタグを剥取るでしょう。 出口では、フレームが再びタグ付けをされるかもしれません、サービスを区切るタグが使用されているか、またはなにも使用されていないならそれが非タグ付けをされるかもしれないなら。
Likewise, if a customer frame arrives at a customer-facing port over an ATM or Frame Relay VC that identifies the customer's VPLS instance, then the ATM or FR encapsulation is removed before the frame is passed into the VPLS.
同様に、顧客フレームが顧客のVPLS例を特定するATMかFrame Relay VCの上の顧客に面するポートに到着するなら、フレームがVPLSに通り過ぎられる前にATMかFRカプセル化が取り外されます。
Contrariwise, if a customer frame arrives at a customer-facing port with a VLAN tag that identifies a VLAN domain in the customer L2 network, then the tag is not modified or stripped, as it belongs with the rest of the customer frame.
逆に、顧客フレームが顧客L2ネットワークでVLANドメインを特定するVLANタグと共に顧客に面するポートに到着するなら、タグは、変更もされませんし、剥取られもしません、顧客フレームの残りで属するとき。
By following the above rules, the Ethernet frame that traverses a VPLS is always a customer Ethernet frame. Note that the two actions, at ingress and egress, of dealing with service delimiters are local actions that neither PE has to signal to the other. They allow, for example, a mix-and-match of VLAN tagged and untagged services at either end, and they do not carry across a VPLS a VLAN tag that has local significance only. The service delimiter may be an MPLS label also, whereby an Ethernet PW given by [RFC4448] can serve as the access side connection into a PE. An RFC1483 Bridged PVC encapsulation could also serve as a service delimiter. By limiting the scope of locally significant encapsulations to the edge, hierarchical VPLS models can be developed that provide the capability to network-engineer scalable VPLS deployments, as described below.
上の規則に従うことで、いつもVPLSを横断するイーサネットフレームは顧客イーサネットフレームです。 サービスデリミタに対処するイングレスにおける2つの動作と出口がどちらのPEももう片方に合図するために持っていない地方の動きであることに注意してください。 彼らは例えばどちらかでのタグ付けをされて非タグ付けをされたサービスが終わらせるVLANのミックスとマッチを許します、そして、それらはVPLSの向こう側にローカルの意味しか持っていないVLANタグを運びません。 また、サービスデリミタはMPLSラベルであるかもしれません。([RFC4448]によって与えられたイーサネットPWはアクセスサイド接続としてそのラベルでPEに機能できます)。 また、RFC1483 Bridged PVCカプセル化はサービスデリミタとして機能できました。 局所的に重要なカプセル化の範囲を縁に制限することによって、ネットワーク・デザイナーのスケーラブルなVPLS展開に能力を提供する階層的なVPLSモデルは開発できます、以下で説明されるように。
7.2. VPLS Learning Actions
7.2. VPLS学習動作
Learning is done based on the customer Ethernet frame as defined above. The Forwarding Information Base (FIB) keeps track of the mapping of customer Ethernet frame addressing and the appropriate PW to use. We define two modes of learning: qualified and unqualified learning. Qualified learning is the default mode and MUST be supported. Support of unqualified learning is OPTIONAL.
顧客イーサネットフレームに基づいて、上で定義されるように、学びます。 Forwarding Information基地(FIB)は使用する顧客イーサネットフレームアドレシングと適切なPWに関するマッピングの動向をおさえます。 私たちは学習の2つの方法を定義します: 適切で資格のない学習。 適切な学習をデフォルトモードであり、支持しなければなりません。 資格のない学習のサポートはOPTIONALです。
Lasserre & Kompella Standards Track [Page 12] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[12ページ]。
In unqualified learning, all the VLANs of a single customer are handled by a single VPLS, which means they all share a single broadcast domain and a single MAC address space. This means that MAC addresses need to be unique and non-overlapping among customer VLANs, or else they cannot be differentiated within the VPLS instance, and this can result in loss of customer frames. An application of unqualified learning is port-based VPLS service for a given customer (e.g., customer with non-multiplexed AC where all the traffic on a physical port, which may include multiple customer VLANs, is mapped to a single VPLS instance).
資格のない学習では、独身の顧客のすべてのVLANsが独身のVPLSによって扱われます。(VPLSは、彼らが皆、ただ一つの放送ドメインとただ一つのMACアドレス空間を共有することを意味します)。 VPLS例の中で彼らを微分できません、そして、これはこれが、MACアドレスが、顧客VLANsの中にユニーク、そして、非重なる必要を意味するか、または顧客フレームの損失をもたらすことができます。 資格のない学習の応用は与えられた顧客(例えば、非多重送信された西暦が複数の顧客VLANsを含むかもしれない物理的なポートにおけるすべての交通がただ一つのVPLS例に写像されるところにある顧客)のためのポートベースのVPLSサービスです。
In qualified learning, each customer VLAN is assigned to its own VPLS instance, which means each customer VLAN has its own broadcast domain and MAC address space. Therefore, in qualified learning, MAC addresses among customer VLANs may overlap with each other, but they will be handled correctly since each customer VLAN has its own FIB; i.e., each customer VLAN has its own MAC address space. Since VPLS broadcasts multicast frames by default, qualified learning offers the advantage of limiting the broadcast scope to a given customer VLAN. Qualified learning can result in large FIB table sizes, because the logical MAC address is now a VLAN tag + MAC address.
適切な学習では、それぞれの顧客VLANはそれ自身のVPLS例に割り当てられます。(それは、それぞれの顧客VLANにはそれ自身の放送ドメインとMACアドレス空間があることを意味します)。 したがって、適切な学習では、顧客VLANsの中のMACアドレスは互いに重なるかもしれませんが、それぞれの顧客VLANにはそれ自身のFIBがあるので、彼らは正しく扱われるでしょう。 すなわちそれぞれの顧客VLANには、それ自身のMACアドレス空間があります。 VPLSがデフォルトでマルチキャストフレームを放送するので、適切な学習は放送範囲を与えられた顧客VLANに制限する利点を示します。 適切な学習は大きいFIBテーブル・サイズをもたらすことができます、現在論理的なMACアドレスがVLANタグ+MACアドレスであるので。
For STP to work in qualified learning mode, a VPLS PE must be able to forward STP BPDUs over the proper VPLS instance. In a hierarchical VPLS case (see details in Section 10), service delimiting tags (Q-in-Q or [RFC4448]) can be added such that PEs can unambiguously identify all customer traffic, including STP BPDUs. In a basic VPLS case, upstream switches must insert such service delimiting tags. When an access port is shared among multiple customers, a reserved VLAN per customer domain must be used to carry STP traffic. The STP frames are encapsulated with a unique provider tag per customer (as the regular customer traffic), and a PEs looks up the provider tag to send such frames across the proper VPLS instance.
STPが適切な学習モードで働くように、VPLS PEは適切なVPLS例の上にSTP BPDUsを送ることができなければなりません。 階層的なVPLS場合(セクション10で詳細を見る)では、PEsが明白にすべての顧客交通を特定できるように、タグ(QのQか[RFC4448])を区切るサービスは加えることができます、STP BPDUsを含んでいて。 基本的なVPLS場合では、上流のスイッチは、タグを区切りながら、そのようなサービスを挿入しなければなりません。 アクセスポートが複数の顧客の中で共有されるとき、STP交通を運ぶのに顧客ドメインあたり1予約されたVLANを使用しなければなりません。 STPフレームは顧客(上得意交通としての)あたり1個のユニークなプロバイダータグで要約されます、そして、PEsは適切なVPLS例の向こう側にそのようなフレームを送るためにプロバイダータグを見上げます。
8. Data Forwarding on an Ethernet VLAN PW
8. イーサネットでVLAN PWを進めるデータ
This section describes the data plane behavior on an Ethernet VLAN PW in a VPLS. While the encapsulation is similar to that described in [RFC4448], the functions of imposing tags and using a "normalized" Ethernet frame are described. The learning behavior is the same as for Ethernet PWs.
このセクションはVPLSのイーサネットVLAN PWでデータ飛行機の振舞いについて説明します。 カプセル化が[RFC4448]で説明されたそれと同様である間、タグを課して、「正常にされた」イーサネットフレームを使用する機能は説明されます。 学習挙動はイーサネットPWsのように同じです。
8.1. VPLS Encapsulation Actions
8.1. VPLSカプセル化動作
In a VPLS, a customer Ethernet frame without preamble is encapsulated with a header as defined in [RFC4448]. A customer Ethernet frame is defined as follows:
VPLSでは、序文のない顧客イーサネットフレームはヘッダーと共に[RFC4448]で定義されるように要約されます。 顧客イーサネットフレームは以下の通り定義されます:
Lasserre & Kompella Standards Track [Page 13] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[13ページ]。
- If the frame, as it arrives at the PE, has an encapsulation that
is part of the customer frame and is also used by the local PE as
a service delimiter, i.e., to identify the customer and/or the
particular service of that customer, then that encapsulation is
preserved as the frame is sent into the VPLS, unless the Requested
VLAN ID optional parameter was signaled. In that case, the VLAN
tag is overwritten before the frame is sent out on the PW.
- フレームをPEに到着するとき顧客フレームの一部であるカプセル化を持って、また、すなわち、地方のPEがその顧客の顧客、そして/または、特定のサービスを特定するのにサービスデリミタとして使用するなら、フレームをVPLSに送るとき、そのカプセル化を保存します、Requested VLANのIDの任意のパラメタが合図されなかったなら。 その場合、PWにフレームを出す前にVLANタグを上書きします。
- If the frame, as it arrives at the PE, has an encapsulation that
does not have the required VLAN tag, a null tag is imposed if the
Requested VLAN ID optional parameter was not signaled.
- PEに到着するときフレームで必要なVLANタグを持っていないカプセル化があって、Requested VLANのIDの任意のパラメタが合図されなかったなら、ヌルタグは課されます。
As an application of these rules, a customer frame may arrive at a customer-facing port with a VLAN tag that identifies the customer's VPLS instance and also identifies a customer VLAN. That tag would be preserved as it is encapsulated in the VPLS.
これらの規則の適用として、顧客フレームは顧客のVPLS例を特定して、また顧客VLANを特定するVLANタグと共に顧客に面するポートに到着するかもしれません。 それがVPLSで要約されるとき、そのタグは保存されるでしょう。
The Ethernet VLAN PW provides a simple way to preserve customer 802.1p bits.
イーサネットVLAN PWは顧客802.1pビットを保存する簡単な方法を提供します。
A VPLS MAY have both Ethernet and Ethernet VLAN PWs. However, if a PE is not able to support both PWs simultaneously, it SHOULD send a Label Release on the PW messages that it cannot support with a status code "Unknown FEC" as given in [RFC3036].
VPLS MAYには、イーサネットとイーサネットVLAN PWsの両方があります。 しかしながら、aであるなら、PEは同時に両方のPWsを支持できません、それ。SHOULDは[RFC3036]で与えるようにステータスコードで「未知のFEC」を支持できないというPWメッセージにLabel Releaseを送ります。
9. Operation of a VPLS
9. VPLSの操作
We show here, in Figure 2, below, an example of how a VPLS works. The following discussion uses the figure below, where a VPLS has been set up between PE1, PE2, and PE3. The VPLS connects a customer with 4 sites labeled A1, A2, A3, and A4 through CE1, CE2, CE3, and CE4, respectively.
私たちは図2にここに下、VPLSがどう働くかに関する例を示しています。 以下の議論は以下の図を使用します。そこでは、VPLSがPE1と、PE2と、PE3の間でセットアップされました。 VPLSはCE1、CE2、CE3、およびCE4を通してそれぞれA1、A2、A3、およびA4に分類される4つのサイトに顧客を接続します。
Initially, the VPLS is set up so that PE1, PE2, and PE3 have a full mesh of Ethernet PWs. The VPLS instance is assigned an identifier (AGI). For the above example, say PE1 signals PW label 102 to PE2 and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3.
初めは、VPLSは、PE1、PE2、およびPE3にはイーサネットPWsの完全なメッシュがあるように、セットアップされます。 識別子(AGI)はVPLS例に割り当てられます。 上記の例に関しては、PE1信号PWがPE1へのPWラベル201とPE3への203とPE2への102とPE3への103、およびPE2信号をラベルすると言ってください。
Lasserre & Kompella Standards Track [Page 14] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[14ページ]。
-----
/ A1 \
---- ----CE1 |
/ \ -------- ------- / | |
| A2 CE2- / \ / PE1 \ /
\ / \ / \---/ \ -----
---- ---PE2 |
| Service Provider Network |
\ / \ /
----- PE3 / \ /
|Agg|_/ -------- -------
-| |
---- / ----- ----
/ \/ \ / \ CE = Customer Edge Router
| A3 CE3 -CE4 A4 | PE = Provider Edge Router
\ / \ / Agg = Layer 2 Aggregation
---- ----
----- /A1\---- ----CE1| / \ -------- ------- / | | | A2 CE2/\/PE1\/\/\/\---/ \ ----- ---- ---PE2| | サービスプロバイダーネットワーク| \ / \ / ----- PE3/\/|Agg|_/ -------- ------- -| | ---- / ----- ---- /\/\/\Ceは顧客縁のルータと等しいです。| A3 CE3 -CE4 A4| PEはプロバイダー縁ルータ\/\/Agg=層2の集合と等しいです。---- ----
Figure 2: Example of a VPLS
図2: VPLSに関する例
Assume a packet from A1 is bound for A2. When it leaves CE1, say it has a source MAC address of M1 and a destination MAC of M2. If PE1 does not know where M2 is, it will flood the packet; i.e., send it to PE2 and PE3. When PE2 receives the packet, it will have a PW label of 201. PE2 can conclude that the source MAC address M1 is behind PE1, since it distributed the label 201 to PE1. It can therefore associate MAC address M1 with PW label 102.
A1からのパケットがA2に向かっていると仮定してください。 CE1が残っているときには、M1のソースMACアドレスとM2の目的地MACを持っていると言ってください。 PE1が、M2がどこにあるかを知らないと、パケットをあふれさせるでしょう。 すなわち、PE2とPE3にそれを送ってください。 PE2がパケットを受けるとき、それは201のPWラベルを持つでしょう。 ラベル201をPE1に分配したので、PE2は、PE1の後ろにソースMACアドレスM1があると結論を下すことができます。 したがって、それはMACアドレスM1をPWラベル102に関連づけることができます。
9.1. MAC Address Aging
9.1. マックーアドレスの年をとること
PEs that learn remote MAC addresses SHOULD have an aging mechanism to remove unused entries associated with a PW label. This is important both for conservation of memory and for administrative purposes. For example, if a customer site A, is shut down, eventually the other PEs should unlearn A's MAC address.
リモートMACがSHOULDを記述することを学ぶPEsがPWラベルに関連している未使用のエントリーを取り除く老朽化しているメカニズムを持っています。 これはメモリの保護と管理目的のために重要です。 例えば、顧客サイトAであるなら、閉鎖、結局PEsが忘れるはずであるもう片方がAのMACアドレスですか?
The aging timer for MAC address M SHOULD be reset when a packet with source MAC address M is received.
MACがソースMACがあるパケットであることのリセットがアドレスMであったならM SHOULDを記述するので、老朽化しているタイマは受け取られています。
Lasserre & Kompella Standards Track [Page 15] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[15ページ]。
10. A Hierarchical VPLS Model
10. 階層的なVPLSモデル
The solution described above requires a full mesh of tunnel LSPs between all the PE routers that participate in the VPLS service. For each VPLS service, n*(n-1)/2 PWs must be set up between the PE routers. While this creates signaling overhead, the real detriment to large scale deployment is the packet replication requirements for each provisioned PWs on a PE router. Hierarchical connectivity, described in this document, reduces signaling and replication overhead to allow large-scale deployment.
上で説明された解決策はVPLSサービスに参加するすべてのPEルータの間のトンネルLSPsの完全なメッシュを必要とします。 それぞれのVPLSサービスにおいて、PEルータの間でn*(n-1)/2PWsをセットアップしなければなりません。 これはシグナリングオーバーヘッドを作成しますが、大規模展開への本当の損傷はPEルータのそれぞれの食糧を供給されたPWsのためのパケット模写要件です。 本書では説明された階層的な接続性は、大規模な展開を許すためにシグナリングと模写オーバーヘッドを下げます。
In many cases, service providers place smaller edge devices in multi-tenant buildings and aggregate them into a PE in a large Central Office (CO) facility. In some instances, standard IEEE 802.1q (Dot 1Q) tagging techniques may be used to facilitate mapping CE interfaces to VPLS access circuits at a PE.
多くの場合、サービスプロバイダーは、より小さいエッジデバイスを雑居ビルに置いて、大きいセントラルオフィス(CO)施設でそれらをPEに集めます。 ある場合に、標準のIEEE 802.1q(ドット1Q)タグ付けのテクニックは、PEのVPLSアクセスサーキットにCEインタフェースを写像するのを容易にするのに使用されるかもしれません。
It is often beneficial to extend the VPLS service tunneling techniques into the access switch domain. This can be accomplished by treating the access device as a PE and provisioning PWs between it and every other edge, as a basic VPLS. An alternative is to utilize [RFC4448] PWs or Q-in-Q logical interfaces between the access device and selected VPLS enabled PE routers. Q-in-Q encapsulation is another form of L2 tunneling technique, which can be used in conjunction with MPLS signaling, as will be described later. The following two sections focus on this alternative approach. The VPLS core PWs (hub) are augmented with access PWs (spoke) to form a two- tier hierarchical VPLS (H-VPLS).
VPLSサービストンネリングのテクニックをアクセススイッチドメインに広げるのはしばしば有益です。 アクセス装置をPEとして扱って、それと他のあらゆる縁の間のPWsに食糧を供給することによって、これを達成できます、基本的なVPLSとして。 代替手段が[RFC4448]PWsを利用することであったまたはアクセス装置と選択されたVPLSとのQのQ論理的なインタフェースはPEルータを可能にしました。 QのQカプセル化は後での別のフォームのL2トンネリングのテクニックです。(説明されているようにMPLSシグナリングに関連してそのテクニックを使用できます)。 以下の2つのセクションがこの代替的アプローチに焦点を合わせます。 VPLSコアPWs(ハブ)は、2階層的なVPLS(H-VPLS)層を形成するためにアクセスPWs(話した)と共に増大します。
Spoke PWs may be implemented using any L2 tunneling mechanism, and by expanding the scope of the first tier to include non-bridging VPLS PE routers. The non-bridging PE router would extend a spoke PW from a Layer-2 switch that connects to it, through the service core network, to a bridging VPLS PE router supporting hub PWs. We also describe how VPLS-challenged nodes and low-end CEs without MPLS capabilities may participate in a hierarchical VPLS.
実行された使用がどんなL2トンネリングメカニズムと、広がることによって範囲であったかもしれないならも非の橋を架けるVPLS PEルータを含む最初の層についてPWsを話しました。 非の橋を架けるPEルータは接続するLayer-2スイッチからそれまでaスポークPWを広げているでしょう、サービスコアネットワークを通して、ハブPWsを支持する橋を架けるVPLS PEルータに。 また、私たちはMPLS能力のないVPLSによって挑戦されたノードとローエンドCEsがどう階層的なVPLSに参加するかもしれないかを説明します。
For rest of this discussion we refer to a bridging capable access device as MTU-s and a non-bridging capable PE as PE-r. We refer to a routing and bridging capable device as PE-rs.
この議論の残りについて、私たちはPE-rとしてMTU-sと非の橋を架けることのできるPEと橋を架けることのできるアクセス装置を呼びます。 私たちはルーティングと橋を架けることのできる装置をPE-rsと呼びます。
10.1. Hierarchical Connectivity
10.1. 階層的な接続性
This section describes the hub and spoke connectivity model and describes the requirements of the bridging capable and non-bridging MTU-s devices for supporting the spoke connections.
このセクションは、ハブについて説明して、接続性モデルを話して、スポーク接続を支持するための橋を架けることのできて非橋を架けているMTU-s装置の要件について説明します。
Lasserre & Kompella Standards Track [Page 16] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[16ページ]。
10.1.1. Spoke Connectivity for Bridging-Capable Devices
10.1.1. 橋を架けるできる装置のために接続性を話しました。
In Figure 3, below, three customer sites are connected to an MTU-s through CE-1, CE-2, and CE-3. The MTU-s has a single connection (PW-1) to PE1-rs. The PE-rs devices are connected in a basic VPLS full mesh. For each VPLS service, a single spoke PW is set up between the MTU-s and the PE-rs based on [RFC4447]. Unlike traditional PWs that terminate on a physical (or a VLAN-tagged logical) port, a spoke PW terminates on a virtual switch instance (VSI; see [L2FRAME]) on the MTU-s and the PE-rs devices.
図3では、3つの顧客サイトがCE-1、CE-2、およびCE-3を通して以下では、MTU-sにつなげられます。 MTU-sは単独結合(PW-1)をPE1-rsに持っています。 PE-rs装置は基本的なVPLS完全なメッシュで接続されます。 それぞれのVPLSサービスにおいて、a単一のスポークPWは[RFC4447]に基づくMTU-sとPE-rsの間でセットアップされます。 または、身体検査のときに終わる伝統的なPWs、(aがVLANタグ付けをした、論理的である、)、ポート(PWがMTU-sとPE-rs装置で仮想のスイッチ例(VSI; [L2FRAME]を見る)で終えるスポーク)
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ MTU-s PE1-rs / |
+--------+ +--------+ / |
| | | | / |
| -- | PW-1 | -- |---/ |
| / \--|- - - - - - - - - - - | / \ | |
| \S / | | \S / | |
| -- | | -- |---\ |
+--------+ +--------+ \ |
/ \ |
---- +--------+
|Agg | | |
---- | -- |
/ \ | / \ |
CE-2 CE-3 | \S / |
| -- |
+--------+
PE3-rs
Agg = Layer-2 Aggregation
--
/ \
\S / = Virtual Switch Instance
--
PE2-rs+--------+ | | | -- | | / \ | Ce-1| \S/| \ | -- | \ +--------+ \MTU-s PE1-rs/| +--------+ +--------+ / | | | | | / | | -- | PW-1| -- |---/ | | / \--|- - - - - - - - - - - | / \ | | | \S/| | \S/| | | -- | | -- |---\ | +--------+ +--------+ \ | / \ | ---- +--------+ |Agg| | | ---- | -- | / \ | / \ | Ce-2Ce-3| \S/| | -- | +--------層-2+ PE3-rs Agg=集合--/\\S/=仮想のスイッチ例--
Figure 3: An example of a hierarchical VPLS model
図3: 階層的なVPLSモデルに関する例
The MTU-s and the PE-rs treat each spoke connection like an AC of the VPLS service. The PW label is used to associate the traffic from the spoke to a VPLS instance.
MTU-sとPE-rsの御馳走はVPLSサービスの西暦のようにそれぞれ接続を話しました。 PWラベルは、スポークからVPLS例までの交通を関連づけるのに使用されます。
Lasserre & Kompella Standards Track [Page 17] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[17ページ]。
10.1.1.1. MTU-s Operation
10.1.1.1. MTU-s操作
An MTU-s is defined as a device that supports layer-2 switching functionality and does all the normal bridging functions of learning and replication on all its ports, including the spoke, which is treated as a virtual port. Packets to unknown destinations are replicated to all ports in the service including the spoke. Once the MAC address is learned, traffic between CE1 and CE2 will be switched locally by the MTU-s, saving the capacity of the spoke to the PE-rs. Similarly traffic between CE1 or CE2 and any remote destination is switched directly onto the spoke and sent to the PE-rs over the point-to-point PW.
MTU-sは層-2切り換えの機能性を支持して、すべてのポートで学習と模写のすべての正常な橋を架ける機能をする装置と定義されます、スポーク(仮想のポートとして扱われる)を含んでいて。 未知の目的地へのパケットはスポークを含むサービスですべてのポートに模写されます。 MACアドレスがいったん学習されると、CE1とCE2の間の交通はMTU-sによって局所的に切り換えられるでしょう、スポークの容量をPE-rsに節約して。 同様に、CE1かCE2とどんな遠く離れた目的地の間の交通を直接スポークに切り換えて、二地点間PWの上のPE-rsに送ります。
Since the MTU-s is bridging capable, only a single PW is required per VPLS instance for any number of access connections in the same VPLS service. This further reduces the signaling overhead between the MTU-s and PE-rs.
MTU-sが橋を架けることであるので、できる独身のPWだけが同じVPLSサービスにおけるいろいろなアクセス接続にVPLS例単位で必要です。 これはさらにMTU-sとPE-rsの間のシグナリングオーバーヘッドを下げます。
If the MTU-s is directly connected to the PE-rs, other encapsulation techniques, such as Q-in-Q, can be used for the spoke.
MTU-sが直接PE-rsに接続されるなら、スポークにQのQなどの他のカプセル化技術を使用できます。
10.1.1.2. PE-rs Operation
10.1.1.2. PE-rs操作
A PE-rs is a device that supports all the bridging functions for VPLS service and supports the routing and MPLS encapsulation; i.e., it supports all the functions described for a basic VPLS, as described above.
PE-rsはVPLSサービスのためにすべての橋を架ける機能をサポートして、ルーティングとMPLSカプセル化を支持する装置です。 すなわち、それは基本的なVPLSのために上で説明されるように説明されたすべての機能をサポートします。
The operation of PE-rs is independent of the type of device at the other end of the spoke. Thus, the spoke from the MTU-s is treated as a virtual port, and the PE-rs will switch traffic between the spoke PW, hub PWs, and ACs once it has learned the MAC addresses.
PE-rsの操作はスポークのもう一方の端で装置のタイプから独立しています。 したがって、MTU-sからのスポークは仮想のポートとして扱われます、そして、いったんMACアドレスを学ぶと、PE-rsはスポークPWと、ハブPWsと、ACsの間の交通を切り換えるでしょう。
10.1.2. Advantages of Spoke Connectivity
10.1.2. スポークの接続性の利点
Spoke connectivity offers several scaling and operational advantages for creating large-scale VPLS implementations, while retaining the ability to offer all the functionality of the VPLS service.
スポークの接続性は、すべてのVPLSサービスの機能性を提供する能力を保有している間、大規模なVPLS実現を作成するためにいくつかのスケーリングとオペレーショナル・アドバンテージを提供します。
- Eliminates the need for a full mesh of tunnels and full mesh of
PWs per service between all devices participating in the VPLS
service.
- VPLSサービスに参加しながら、すべての装置の間でトンネルの完全なメッシュと1サービスあたりのPWsの完全なメッシュの必要性を排除します。
- Minimizes signaling overhead, since fewer PWs are required for the
VPLS service.
- より少ないPWsがVPLSサービスに必要であるので、シグナリングオーバーヘッドを最小にします。
Lasserre & Kompella Standards Track [Page 18] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[18ページ]。
- Segments VPLS nodal discovery. MTU-s needs to be aware of only
the PE-rs node, although it is participating in the VPLS service
that spans multiple devices. On the other hand, every VPLS PE-rs
must be aware of every other VPLS PE-rs and all of its locally
connected MTU-s and PE-r devices.
- セグメントVPLSこぶのような発見。 MTU-sは、PE-rsノードだけを意識している必要があります、複数の装置にかかるVPLSサービスに参加していますが。 他方では、あらゆるVPLS PE-rsがその局所的に接続されたMTU-sとPE-r装置の他のあらゆるVPLS PE-rsとすべてを意識しているに違いありません。
- Addition of other sites requires configuration of the new MTU-s
but does not require any provisioning of the existing MTU-s
devices on that service.
- 他のサイトの添加は、新しいMTU-sの構成を必要としますが、そのサービスときの既存のMTU-s装置のどんな食糧を供給することは必要としません。
- Hierarchical connections can be used to create VPLS service that
spans multiple service provider domains. This is explained in a
later section.
- 複数のサービスプロバイダードメインにかかるVPLSサービスを作成するのに階層的な接続を使用できます。 これは後のセクションで説明されます。
Note that as more devices participate in the VPLS, there are more devices that require the capability for learning and replication.
より多くの装置がVPLSに参加するとき学習と模写のために能力を必要とするより多くの装置があることに注意してください。
10.1.3. Spoke Connectivity for Non-Bridging Devices
10.1.3. 非の橋を架ける装置のために接続性を話しました。
In some cases, a bridging PE-rs may not be deployed, or a PE-r might already have been deployed. In this section, we explain how a PE-r that does not support any of the VPLS bridging functionality can participate in the VPLS service.
いくつかの場合、橋を架けるPE-rsが配備されないかもしれませんか、またはPE-rは既に配備されたかもしれません。 このセクションで、私たちはVPLS橋を架けることの機能性のいずれも支持しないPE-rがどうVPLSサービスに参加できるかを説明します。
In Figure 4, three customer sites are connected through CE-1, CE-2, and CE-3 to the VPLS through PE-r. For every attachment circuit that participates in the VPLS service, PE-r creates a point-to-point PW that terminates on the VSI of PE1-rs.
図4では、3つの顧客サイトがPE-rを通してCE-1、CE-2、およびCE-3を通してVPLSにつなげられます。 VPLSサービスに参加するあらゆる付属サーキットに、PE-rはPE1-rsのVSIで終わる二地点間PWを作成します。
Lasserre & Kompella Standards Track [Page 19] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[19ページ]。
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ PE-r PE1-rs / |
+--------+ +--------+ / |
|\ | | | / |
| \ | PW-1 | -- |---/ |
| ------|- - - - - - - - - - - | / \ | |
| -----|- - - - - - - - - - - | \S / | |
| / | | -- |---\ |
+--------+ +--------+ \ |
/ \ |
---- +--------+
| Agg| | |
---- | -- |
/ \ | / \ |
CE-2 CE-3 | \S / |
| -- |
+--------+
PE3-rs
PE2-rs+--------+ | | | -- | | / \ | Ce-1| \S/| \ | -- | \ +--------+ \PE-r PE1-rs/| +--------+ +--------+ / | |\ | | | / | | \ | PW-1| -- |---/ | | ------|- - - - - - - - - - - | / \ | | | -----|- - - - - - - - - - - | \S/| | | / | | -- |---\ | +--------+ +--------+ \ | / \ | ---- +--------+ | Agg| | | ---- | -- | / \ | / \ | Ce-2Ce-3| \S/| | -- | +--------+ PE3-rs
Figure 4: An example of a hierarchical VPLS
with non-bridging spokes
図4: 非の橋を架けるスポークがある階層的なVPLSに関する例
The PE-r is defined as a device that supports routing but does not support any bridging functions. However, it is capable of setting up PWs between itself and the PE-rs. For every port that is supported in the VPLS service, a PW is set up from the PE-r to the PE-rs. Once the PWs are set up, there is no learning or replication function required on the part of the PE-r. All traffic received on any of the ACs is transmitted on the PW. Similarly, all traffic received on a PW is transmitted to the AC where the PW terminates. Thus, traffic from CE1 destined for CE2 is switched at PE1-rs and not at PE-r.
PE-rは掘るのを支持する装置と定義されますが、どんな橋を架ける機能もサポートしません。 しかしながら、それはそれ自体とPE-rsの間のPWsをセットアップできます。 VPLSサービスで支えられるあらゆるポートに関しては、PWはPE-rからPE-rsまでセットアップされます。 PWsがいったんセットアップされると、PE-r側の必要であるどんな学習も模写機能もありません。 ACsのいずれでも受けられたすべての交通がPWで伝えられます。 同様に、PWで受けられたすべての交通が西暦にPWが終わるところに送られます。 したがって、CE2のために運命づけられたCE1からの交通はPE-rで切り換えられるのではなく、PE1-rsで切り換えられます。
Note that in the case where PE-r devices use Provider VLANs (P-VLAN) as demultiplexers instead of PWs, PE1-rs can treat them as such and map these "circuits" into a VPLS domain to provide bridging support between them.
PE-r装置がPWsの代わりにデマルチプレクサとしてProvider VLANs(P-VLAN)を使用する場合では、PE1-rsがそういうものとして彼らを扱うことができることに注意してください、そして、提供するために彼らの間のサポートに橋を架けながら、これらの「サーキット」をVPLSドメインに写像してください。
Lasserre & Kompella Standards Track [Page 20] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[20ページ]。
This approach adds more overhead than the bridging-capable (MTU-s) spoke approach, since a PW is required for every AC that participates in the service versus a single PW required per service (regardless of ACs) when an MTU-s is used. However, this approach offers the advantage of offering a VPLS service in conjunction with a routed internet service without requiring the addition of new MTU-s.
このアプローチは、橋を架けるできる(MTU-s)より多くのオーバーヘッドがアプローチを話したと言い足します、PWがMTU-sが使用されているときサービス(ACsにかかわらず)単位で必要である独身のPWに対してサービスに参加するあらゆる西暦に必要であるので。 しかしながら、このアプローチは新しいMTU-sの添加を必要とすることのない発送されたインターネットサービスに関連してVPLSサービスを提供する利点を示します。
10.2. Redundant Spoke Connections
10.2. 余分なスポークコネクションズ
An obvious weakness of the hub and spoke approach described thus far is that the MTU-s has a single connection to the PE-rs. In case of failure of the connection or the PE-rs, the MTU-s suffers total loss of connectivity.
ハブの明白な弱点とこれまでのところ説明されたスポークアプローチはMTU-sがPE-rsに単独結合を持っているということです。 接続かPE-rsの失敗の場合には、MTU-sは接続性の丸損を受けます。
In this section, we describe how the redundant connections can be provided to avoid total loss of connectivity from the MTU-s. The mechanism described is identical for both, MTU-s and PE-r devices.
このセクションで、私たちはMTU-sからの接続性の丸損を避けるためにどう余分な接続を提供できるかを説明します。 両方、MTU-s、およびPE-r装置に、説明されたメカニズムは同じです。
10.2.1. Dual-Homed MTU-s
10.2.1. 二元的である、-、家へ帰り、MTU-s
To protect from connection failure of the PW or the failure of the PE-rs, the MTU-s or the PE-r is dual-homed into two PE-rs devices. The PE-rs devices must be part of the same VPLS service instance.
PE-rs、MTU-sまたはPE-rのPWか失敗の接続失敗から保護するのがある、二元的である、-、家へ帰り、2台のPE-rs装置に。 PE-rs装置は同じVPLSサービス例の一部であるに違いありません。
In Figure 5, two customer sites are connected through CE-1 and CE-2 to an MTU-s. The MTU-s sets up two PWs (one each to PE1-rs and PE3-rs) for each VPLS instance. One of the two PWs is designated as primary and is the one that is actively used under normal conditions, whereas the second PW is designated as secondary and is held in a standby state. The MTU-s negotiates the PW labels for both the primary and secondary PWs, but does not use the secondary PW unless the primary PW fails. How a spoke is designated primary or secondary is outside the scope of this document. For example, a spanning tree instance running between only the MTU-s and the two PE-rs nodes is one possible method. Another method could be configuration.
図5では、2つの顧客サイトがCE-1とCE-2を通してMTU-sにつなげられます。 MTU-sはそれぞれのVPLS例あたり2PWs(それぞれPE1-rsとPE3-rsへの1)をセットアップします。 2PWsの1つは、第一で任じられて、活発に正常な状況では使用されるものです、第2PWは二次として指定されて、予備状態で持たれていますが。 MTU-sは両方の第一の、そして、二次のPWsのためにPWラベルを交渉しますが、第一のPWが失敗しない場合、二次PWを使用しません。 このドキュメントの範囲の外にスポークがどう予備選挙か2番目に指定されるかがあります。 例えば、MTU-sと2つのPE-rsノードだけの間を走るスパニングツリー例は1つの可能な方法です。 別の方法は構成であるかもしれません。
Lasserre & Kompella Standards Track [Page 21] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[21ページ]。
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ MTU-s PE1-rs / |
+--------+ +--------+ / |
| | | | / |
| -- | Primary PW | -- |---/ |
| / \ |- - - - - - - - - - - | / \ | |
| \S / | | \S / | |
| -- | | -- |---\ |
+--------+ +--------+ \ |
/ \ \ |
/ \ +--------+
/ \ | |
CE-2 \ | -- |
\ Secondary PW | / \ |
- - - - - - - - - - - - - - - - - | \S / |
| -- |
+--------+
PE3-rs
Figure 5: An example of a dual-homed MTU-s
PE2-rs+--------+ | | | -- | | / \ | Ce-1| \S/| \ | -- | \ +--------+ \MTU-s PE1-rs/| +--------+ +--------+ / | | | | | / | | -- | プライマリPW| -- |---/ | | / \ |- - - - - - - - - - - | / \ | | | \S/| | \S/| | | -- | | -- |---\ | +--------+ +--------+ \ | / \ \ | / \ +--------+ / \ | | Ce-2円| -- | \セカンダリPW| / \ | - - - - - - - - - - - - - - - - - | \S/| | -- | +--------+ PE3-rs数値5: aに関する例、二元的である、-、家へ帰り、MTU-s
10.2.2. Failure Detection and Recovery
10.2.2. 失敗検出と回復
The MTU-s should control the usage of the spokes to the PE-rs devices. If the spokes are PWs, then LDP signaling is used to negotiate the PW labels, and the hello messages used for the LDP session could be used to detect failure of the primary PW. The use of other mechanisms that could provide faster detection failures is outside the scope of this document.
MTU-sはPE-rsデバイスにスポークの使用法を制御するはずです。 そして、自由民主党シグナリングがスポークがPWsであるならPWラベルを交渉するのに使用される、こんにちは、プライマリPWの失敗を検出するのに自由民主党のセッションに使用されるメッセージは使用できました。 このドキュメントの範囲の外により速い検出失敗を提供できた他のメカニズムの使用があります。
Upon failure of the primary PW, MTU-s immediately switches to the secondary PW. At this point, the PE3-rs that terminates the secondary PW starts learning MAC addresses on the spoke PW. All other PE-rs nodes in the network think that CE-1 and CE-2 are behind PE1-rs and may continue to send traffic to PE1-rs until they learn that the devices are now behind PE3-rs. The unlearning process can take a long time and may adversely affect the connectivity of higher-level protocols from CE1 and CE2. To enable faster convergence, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2), using the MAC List
プライマリPWの失敗を、MTU-sはすぐに、セカンダリPWに切り換えます。 ここに、セカンダリPWを終えるPE3-rsは、MACがスポークの上でPWを扱うことを学び始めます。 彼らが、現在、PE3-rsの後ろにデバイスがあることを学ぶまで、ネットワークにおける他のすべてのPE-rsノードが、PE1-rsの後ろにCE-1とCE-2があると思って、トラフィックをPE1-rsに送り続けるかもしれません。 アンラーニングプロセスは、長くかかることができて、CE1とCE2から上位レベル・プロトコルの接続性に悪影響を与えるかもしれません。 より速い集合を可能にするために、セカンダリPWが動かされたPE3-rsは豊富なメッセージを出すかもしれません(セクション6.2で説明されるように)、MAC Listを使用して
Lasserre & Kompella Standards Track [Page 22] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[22ページ]。
TLV, as defined in Section 6, to all PE-rs nodes. Upon receiving the message, PE-rs nodes flush the MAC addresses associated with that VPLS instance.
セクション6で定義されるすべてのPE-rsノードへのTLV。 メッセージを受け取ると、PE-rsノードはそのVPLSインスタンスに関連しているMACアドレスを洗い流します。
10.3. Multi-domain VPLS Service
10.3. マルチドメインVPLSサービス
Hierarchy can also be used to create a large-scale VPLS service within a single domain or a service that spans multiple domains without requiring full mesh connectivity between all VPLS-capable devices. Two fully meshed VPLS networks are connected together using a single LSP tunnel between the VPLS "border" devices. A single spoke PW per VPLS service is set up to connect the two domains together.
また、すべてのVPLSできるデバイスの間で単一領域の中の大規模なVPLSサービスか完全なメッシュの接続性を必要としないで複数のドメインにかかるサービスを作成するのに階層構造を使用できます。 2つの完全にかみ合っているVPLSネットワークが、VPLS「境界」デバイスの間の単一のLSPトンネルを使用することで一緒に接続されます。 1VPLSあたりのPWが修理する単一のスポークは、2つのドメインを一緒につなげるためにセットアップされます。
When more than two domains need to be connected, a full mesh of inter-domain spokes is created between border PEs. Forwarding rules over this mesh are identical to the rules defined in Section 4.
2つ以上のドメインが、接続される必要があるとき、相互ドメインスポークの完全なメッシュは境界PEsの間で作成されます。 このメッシュの上の推進規則はセクション4で定義された規則と同じです。
This creates a three-tier hierarchical model that consists of a hub- and-spoke topology between MTU-s and PE-rs devices, a full-mesh topology between PE-rs, and a full mesh of inter-domain spokes between border PE-rs devices.
そして、これがハブから成る3層の階層的なモデルを創造する、-、話し、MTU-sとPE-rsデバイスの間のトポロジー、PE-rsと、境界PE-rsデバイスの間の相互ドメインスポークの完全なメッシュの間の完全なメッシュトポロジー。
This document does not specify how redundant border PEs per domain per VPLS instance can be supported.
このドキュメントはどうVPLSインスタンスあたりのドメインあたりの余分な境界PEsをサポートすることができるかを指定しません。
11. Hierarchical VPLS Model Using Ethernet Access Network
11. イーサネットアクセスネットワークを使用して、階層的なVPLSはモデル化します。
In this section, the hierarchical model is expanded to include an Ethernet access network. This model retains the hierarchical architecture discussed previously in that it leverages the full-mesh topology among PE-rs devices; however, no restriction is imposed on the topology of the Ethernet access network (e.g., the topology between MTU-s and PE-rs devices is not restricted to hub and spoke).
このセクションでは、階層的なモデルは、イーサネットアクセスネットワークを含むように広げられます。 このモデルはPE-rsデバイスの中で完全なメッシュトポロジーを利用するので以前に議論した階層的なアーキテクチャを保有します。 しかしながら、制限は全くイーサネットアクセスネットワークのトポロジーに課されません(例えばMTU-sとPE-rsデバイスの間のトポロジーは、ハブに制限されないで、話しました)。
The motivation for an Ethernet access network is that Ethernet-based networks are currently deployed by some service providers to offer VPLS services to their customers. Therefore, it is important to provide a mechanism that allows these networks to integrate with an IP or MPLS core to provide scalable VPLS services.
イーサネットアクセスネットワークに関する動機はイーサネットを拠点とするネットワークが現在彼らの顧客に対するサービスをVPLSに提供するためにいくつかのサービスプロバイダーによって配布されるということです。 したがって、これらのネットワークが提供するためにIPかMPLSコアと統合されるメカニズムにスケーラブルなVPLSサービスを供給するのは重要です。
One approach of tunneling a customer's Ethernet traffic via an Ethernet access network is to add an additional VLAN tag to the customer's data (which may be either tagged or untagged). The additional tag is referred to as Provider's VLAN (P-VLAN). Inside the provider's network each P-VLAN designates a customer or more specifically a VPLS instance for that customer. Therefore, there is a one-to-one correspondence between a P-VLAN and a VPLS instance. In
イーサネットアクセスネットワークを通して顧客のイーサネットトラフィックにトンネルを堀る1つのアプローチは顧客のデータ(タグ付けをされるか、または非タグ付けをされるかもしれない)に追加VLANタグを追加することです。 追加タグはProviderのVLAN(P-VLAN)と呼ばれます。 プロバイダーのネットワークの中では、各P-VLANはその顧客のために顧客か、より明確にVPLSインスタンスを任命します。 したがって、P-VLANとVPLSインスタンスとの1〜1つの通信があります。 コネ
Lasserre & Kompella Standards Track [Page 23] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[23ページ]。
this model, the MTU-s needs to have the capability of adding the additional P-VLAN tag to non-multiplexed ACs where customer VLANs are not used as service delimiters. This functionality is described in [802.1ad].
このモデル、MTU-sは顧客VLANsがサービスデリミタとして使用されない非多重送信されたACsに追加P-VLANタグを加える能力を必要とします。 この機能性は[802.1ad]で説明されます。
If customer VLANs need to be treated as service delimiters (e.g., the AC is a multiplexed port), then the MTU-s needs to have the additional capability of translating a customer VLAN (C-VLAN) to a P-VLAN, or to push an additional P-VLAN tag, in order to resolve overlapping VLAN tags used by different customers. Therefore, the MTU-s in this model can be considered a typical bridge with this additional capability. This functionality is described in [802.1ad].
顧客VLANsが、サービスデリミタとして扱われる必要があるなら(例えば、西暦は多重送信されたポートです)、MTU-sは、P-VLANの顧客VLAN(C-VLAN)を翻訳する追加能力を持っているか、または追加P-VLANタグを押す必要があります、VLANタグが異なった顧客で使用した重なることを決議するために。 したがって、この追加能力がある典型的なブリッジであるとこのモデルのMTU-sを考えることができます。 この機能性は[802.1ad]で説明されます。
The PE-rs needs to be able to perform bridging functionality over the standard Ethernet ports toward the access network, as well as over the PWs toward the network core. In this model, the PE-rs may need to run STP towards the access network, in addition to split-horizon over the MPLS core. The PE-rs needs to map a P-VLAN to a VPLS- instance and its associated PWs, and vice versa.
PE-rsは、アクセスネットワークに向かった標準のイーサネットポートの上と、そして、ネットワークコアに向かったPWsの上で機能性をブリッジしながら働くことができる必要があります。 このモデルでは、PE-rsは、アクセスネットワークに向かってSTPを実行する必要があるかもしれません、MPLSコアの上の分裂地平線に加えて。 PE-rsは、VPLSインスタンスとその関連PWsにP-VLANを写像する必要があります、そして、逆もまた同様です。
The details regarding bridge operation for MTU-s and PE-rs (e.g., encapsulation format for Q-in-Q messages, customer's Ethernet control protocol handling, etc.) are outside the scope of this document and are covered in [802.1ad]. However, the relevant part is the interaction between the bridge module and the MPLS/IP PWs in the PE-rs, which behaves just as in a regular VPLS.
MTU-sとPE-rs(例えば、QのQメッセージのためのカプセル化形式、顧客のイーサネット制御プロトコル取り扱い)のためのブリッジ・オペレーションに関する詳細は、このドキュメントの範囲の外にあって、[802.1ad]でカバーされています。 しかしながら、関連部分はPE-rsのブリッジモジュールとMPLS/IP PWsとの相互作用です。(PE-rsはちょうど通常のVPLSのように振る舞います)。
11.1. Scalability
11.1. スケーラビリティ
Since each P-VLAN corresponds to a VPLS instance, the total number of VPLS instances supported is limited to 4K. The P-VLAN serves as a local service delimiter within the provider's network that is stripped as it gets mapped to a PW in a VPLS instance. Therefore, the 4K limit applies only within an Ethernet access network (Ethernet island) and not to the entire network. The SP network consists of a core MPLS/IP network that connects many Ethernet islands. Therefore, the number of VPLS instances can scale accordingly with the number of Ethernet islands (a metro region can be represented by one or more islands).
各P-VLANがVPLSインスタンスに対応しているので、インスタンスがサポートしたVPLSの総数は4Kに制限されます。 プロバイダーのそれのように剥取られたネットワークの中のローカル・サービスデリミタがVPLSインスタンスでPWに写像されるとき、P-VLANは役立ちます。 したがって、4Kの限界は全体のネットワークで適用するのではなく、イーサネットアクセスネットワーク(イーサネット島)だけの中で適用されます。 SPネットワークは多くのイーサネット島をつなげるコアMPLS/IPネットワークから成ります。 したがって、VPLSインスタンスの数はイーサネット島の数でそれに従って、比例できます(1つ以上の島のそばに地下鉄領域を表すことができます)。
11.2. Dual Homing and Failure Recovery
11.2. デュアルホーミングと失敗回復
In this model, an MTU-s can be dual homed to different devices (aggregators and/or PE-rs devices). The failure protection for access network nodes and links can be provided through running STP in each island. The STP of each island is independent of other islands and do not interact with others. If an island has more than one PE-rs, then a dedicated full-mesh of PWs is used among these PE-rs
MTU-sがこのモデルでは、そうであることができる、二元的である、異なったデバイス(アグリゲータ、そして/または、PE-rsデバイス)と家へ帰りました。 実行しているSTPを通してアクセスネットワーク・ノードとリンクのための失敗保護を各島に提供できます。 それぞれの島のSTPは他の島から独立しています、そして、他のものと対話しないでください。 島に1PE-rsがあるなら、PWsの専用完全なメッシュはこれらのPE-rsの中で使用されます。
Lasserre & Kompella Standards Track [Page 24] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[24ページ]。
devices for carrying the SP BPDU packets for that island. On a per-P-VLAN basis, STP will designate a single PE-rs to be used for carrying the traffic across the core. The loop-free protection through the core is performed using split-horizon, and the failure protection in the core is performed through standard IP/MPLS re- routing.
その島までSP BPDUパケットを運ぶためのデバイス。 1P-VLANあたり1個のベースでは、STPは、コアの向こう側にトラフィックを運ぶのに使用されるために独身のPE-rsを指定するでしょう。 コアを通した無輪の保護は分裂地平線を使用することで実行されます、そして、コアでの失敗保護は標準のMPLS再IP/ルーティングで実行されます。
12. Contributors
12. 貢献者
Loa Andersson, TLA Ron Haberman, Alcatel-Lucent Juha Heinanen, Independent Giles Heron, Tellabs Sunil Khandekar, Alcatel-Lucent Luca Martini, Cisco Pascal Menezes, Independent Rob Nath, Alcatel-Lucent Eric Puetz, AT&T Vasile Radoaca, Independent Ali Sajassi, Cisco Yetik Serbest, AT&T Nick Slabakov, Juniper Andrew Smith, Consultant Tom Soon, AT&T Nick Tingle, Alcatel-Lucent
Loaアンデション、TLAロンハーバーマン、アルカテル透明なユハHeinanen、独立しているジャイルスサギ、Tellabs Sunilカンデーカル、アルカテル透明なルカMartini、コクチマスPascalメネゼス、独立しているロブ・ナッツ、アルカテル透明なエリックPuetz、AT&TバシレRadoaca、独立しているアリSajassi、コクチマスYetik Serbest、AT&TはすぐSlabakov、Juniperアンドリュー・スミス、コンサルタントのトムに傷を付けます、AT&TニックTingle、アルカテル透明です。
13. Acknowledgments
13. 承認
We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel Halpern, Bill Hong, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov Rekhter, Sasha Vainshtein, and Du Wenhua for their valuable feedback.
それらの有益なフィードバックについてジョー・リーガン、Kireeti Kompella、Anoop Ghanwani、ジョエル・アルペルン、ビルHong、リック・ワイルダー、ジム・ギシャール、スティーブ・フィリップス、Normフィンランド人、マットSquire、Muneyoshi鈴木、Waldemar Augustyn、エリック・ローゼン、ヤコフRekhter、サシャVainshtein、およびDu Wenhuaに感謝申し上げます。
We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu (Ixia), and Charlie Hundall for identifying issues with the draft in the course of the interoperability tests.
また、相互運用性テストの間に問題を草稿と同一視して頂いて、ラジブPapneja(ISOCORE)、ウィンストン・リュウ(イキシア)、およびチャーリーHundallに感謝申し上げます。
We would also like to thank Ina Minei, Bob Thomas, Eric Gray and Dimitri Papadimitriou for their thorough technical review of the document.
また、彼らのドキュメントの徹底的な技術審査について伊奈Minei、ボブ・トーマス、エリック・グレー、およびディミトリPapadimitriouに感謝申し上げます。
Lasserre & Kompella Standards Track [Page 25] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[25ページ]。
14. Security Considerations
14. セキュリティ問題
A more comprehensive description of the security issues involved in L2VPNs is covered in [RFC4111]. An unguarded VPLS service is vulnerable to some security issues that pose risks to the customer and provider networks. Most of the security issues can be avoided through implementation of appropriate guards. A couple of them can be prevented through existing protocols.
L2VPNsにかかわる安全保障問題の、より包括的な記述は[RFC4111]でカバーされています。 無防備のVPLSサービスは顧客とプロバイダーネットワークに危険を引き起こすいくつかの安全保障問題に被害を受け易いです。 適切な番人の実装を通して安全保障問題の大部分を避けることができます。 既存のプロトコルを通してそれらのカップルを防ぐことができます。
- Data plane aspects
- データ飛行機局面
- Traffic isolation between VPLS domains is guaranteed by the
use of per VPLS L2 FIB table and the use of per VPLS PWs.
- VPLSドメインの間のトラフィック分離が1VPLS L2 FIBあたりのテーブルと使用の使用で保証される、VPLS PWs単位で。
- The customer traffic, which consists of Ethernet frames, is
carried unchanged over VPLS. If security is required, the
customer traffic SHOULD be encrypted and/or authenticated
before entering the service provider network.
- 顧客トラフィック(イーサネットフレームから成る)はVPLSの上で変わりがない状態で運ばれます。 セキュリティが必要であるなら、暗号化されている、そして/または、サービスプロバイダーネットワークに入る前に認証された顧客トラフィックSHOULDです。
- Preventing broadcast storms can be achieved by using routers
as CPE devices or by rate policing the amount of broadcast
traffic that customers can send.
- CPEデバイスとしてルータを使用するか、顧客が送ることができる放送トラフィックの量を取り締まるレートでブロードキャスト・ストームを防ぐのを達成できます。
- Control plane aspects
- コントロール飛行機局面
- LDP security (authentication) methods as described in
[RFC3036] SHOULD be applied. This would prevent
unauthenticated messages from disrupting a PE in a VPLS.
- 適用されていて、[RFC3036]SHOULDで説明される自由民主党セキュリティ(認証)メソッド。 これは、非認証されたメッセージがVPLSでPEを混乱させるのを防ぐでしょう。
- Denial of service attacks
- サービス不能攻撃
- Some means to limit the number of MAC addresses (per site per
VPLS) that a PE can learn SHOULD be implemented.
- 或るものは、PEが、SHOULDが実装されることを学ぶことができることをMACの数が扱う(1VPLSあたりのサイト単位で)限界に意味します。
15. IANA Considerations
15. IANA問題
The type field in the MAC List TLV is defined as 0x404 in Section 6.2.1.
MAC List TLVのタイプ分野はセクション6.2.1で0×404と定義されます。
Lasserre & Kompella Standards Track [Page 26] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[26ページ]。
16. References
16. 参照
16.1. Normative References
16.1. 引用規格
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April
2006.
[RFC4447] マティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップとメインテナンスが(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over
MPLS Networks", RFC 4448, April 2006.
[RFC4448] マティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、およびG.サギ、「MPLSネットワークの上のイーサネットの輸送のためのカプセル化メソッド」、RFC4448(2006年4月)。
[802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std
802.1D-1993 "MAC Bridges".
[802.1D-ORIG]オリジナルの802.1D--ISO/IEC10038、ANSI/IEEE Std 802.1D-1993「MACブリッジ。」
[802.1D-REV] 802.1D - "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.
[802.1D-REV]802.1D--「情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク(一般的な仕様)は3を分けます」。 メディアアクセスは(MAC)ブリッジを制御します: 改正。 これはISO/IEC10038の改正です: 1993 802.1j-1992と802.6k-1992。 「P802.11c、P802.1p、およびP802.12e.を組み込みます」 ISO/IEC15802-3: 1998.
[802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE
Standards for Local and Metropolitan Area Networks:
Virtual Bridged Local Area Networks", July 1998.
[802.1Q]802.1Q--ANSI/IEEEが標準のP802.1Q/D11を作成する、「地方とメトロポリタンエリアネットワークのIEEE規格:」 1998年7月の「仮想のブリッジしているローカル・エリア・ネットワーク。」
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", RFC 3036, January
2001.
[RFC3036] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、2006年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
16.2. Informative References
16.2. 有益な参照
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 2006年2月。
[RADIUS-DISC] Heinanen, J., Weber, G., Ed., Townsley, W., Booth, S.,
and W. Luo, "Using Radius for PE-Based VPN Discovery",
Work in Progress, October 2005.
[半径ディスク]Heinanen、J.、ウェーバー、G.(エド)、「PEベースのVPN発見に半径を使用し」て、Townsley、W.、ブース、S.、およびW.羅は進行中(2005年10月)で働いています。
Lasserre & Kompella Standards Track [Page 27] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[27ページ]。
[BGP-DISC] Ould-Brahim, H., Ed., Rosen, E., Ed., and Y. Rekhter,
Ed., "Using BGP as an Auto-Discovery Mechanism for
Network-based VPNs", Work in Progress, September 2006.
[BGP-ディスク]オールド-Brahim、H.(エド)、「ネットワークベースのVPNsに自動発見メカニズムとしてBGPを使用し」て、ローゼン、E.(エド)、およびY.Rekhter(エド)は進行中(2006年9月)で働いています。
[L2FRAME] Andersson, L. and E. Rosen, "Framework for Layer 2
Virtual Private Networks (L2VPNs)", RFC 4664,
September 2006.
[L2FRAME] アンデションとL.とE.ローゼン、「層2の仮想私設網(L2VPNs)のためのフレームワーク」、RFC4664、2006年9月。
[L2VPN-REQ] Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider-Provisioned Virtual Private
Networks", RFC 4665, September 2006.
[L2VPN-REQ] AugustynとW.とY.Serbest、「2つの層のプロバイダーで食糧を供給された仮想私設網のためのサービス要件」、RFC4665、2006年9月。
[RFC4111] Fang, L., "Security Framework for Provider-Provisioned
Virtual Private Networks (PPVPNs)", RFC 4111, July
2005.
[RFC4111] 牙、L.、「プロバイダーで食糧を供給された仮想私設網(PPVPNs)のためのセキュリティフレームワーク」、RFC4111、2005年7月。
[802.1ad] "IEEE standard for Provider Bridges", Work in
Progress, December 2002.
[802.1ad] 「ProviderブリッジスのIEEE規格」、Progress、2002年12月のWork。
Lasserre & Kompella Standards Track [Page 28] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[28ページ]。
Appendix A. VPLS Signaling using the PWid FEC Element
PWid FEC要素を使用する付録A.VPLSシグナリング
This section is being retained because live deployments use this version of the signaling for VPLS.
ライブ展開がVPLSにシグナリングのこのバージョンを使用するので、このセクションは保有されています。
The VPLS signaling information is carried in a Label Mapping message sent in downstream unsolicited mode, which contains the following PWid FEC TLV.
VPLSシグナリング情報は川下の求められていないモードで送られたLabel Mappingメッセージで運ばれます。モードは以下のPWid FEC TLVを含みます。
PW, C, PW Info Length, Group ID, and Interface parameters are as defined in [RFC4447].
PW、C、PW Info Length、Group ID、およびInterfaceパラメタが[RFC4447]で定義されるようにあります。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW TLV |C| PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface parameters | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW TLV|C| PWはタイプします。|PWインフォメーションLength| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース・パラメータ| ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We use the Ethernet PW type to identify PWs that carry Ethernet traffic for multipoint connectivity.
私たちは、多点の接続性のためにイーサネットトラフィックを運ぶPWsを特定するのにイーサネットPWタイプを使用します。
In a VPLS, we use a VCID (which, when using the PWid FEC, has been substituted with a more general identifier (AGI), to address extending the scope of a VPLS) to identify an emulated LAN segment. Note that the VCID as specified in [RFC4447] is a service identifier, identifying a service emulating a point-to-point virtual circuit. In a VPLS, the VCID is a single service identifier, so it has global significance across all PEs involved in the VPLS instance.
VPLSでは、私たちは、見習われたLANセグメントを特定するのに、VCID(PWid FECを使用するときより一般的な識別子(AGI)で代入されて、広がりがVPLSの範囲であると扱った)を使用します。 二地点間仮想の回路を見習うサービスを特定して、[RFC4447]の指定されるとしてのVCIDがサービス識別子であることに注意してください。 VPLSでは、VCIDがただ一つのサービス識別子であるので、それはVPLSインスタンスにかかわるすべてのPEsの向こう側にグローバルな意味を持っています。
Lasserre & Kompella Standards Track [Page 29] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[29ページ]。
Authors' Addresses
作者のアドレス
Marc Lasserre Alcatel-Lucent EMail: mlasserre@alcatel-lucent.com
マークのラセールのアルカテル透明なEMail: mlasserre@alcatel-lucent.com
Vach Kompella Alcatel-Lucent EMail: vach.kompella@alcatel-lucent.com
Vach Kompellaのアルカテル透明なメール: vach.kompella@alcatel-lucent.com
Lasserre & Kompella Standards Track [Page 30] RFC 4762 Virtual Private LAN Service over LDP January 2007
ラセールとKompella規格は仮想の個人的なLANサービスオーバー自由民主党2007年1月にRFC4762を追跡します[30ページ]。
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機能のための基金は現在、インターネット協会によって提供されます。
Lasserre & Kompella Standards Track [Page 31]
ラセールとKompella標準化過程[31ページ]
一覧
スポンサーリンク
