RFC4364 日本語訳
4364 BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, Y.Rekhter. February 2006. (Format: TXT=116446 bytes) (Obsoletes RFC2547) (Updated by RFC4577, RFC4684) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group E. Rosen
Request for Comments: 4364 Cisco Systems, Inc.
Obsoletes: 2547 Y. Rekhter
Category: Standards Track Juniper Networks, Inc.
February 2006
コメントを求めるワーキンググループE.ローゼン要求をネットワークでつないでください: 4364 シスコシステムズInc.は以下を時代遅れにします。 2547年のY.Rekhterカテゴリ: 規格はInc.2006年2月に杜松ネットワークを追跡します。
BGP/MPLS IP Virtual Private Networks (VPNs)
BGP/MPLS IP仮想私設網(VPNs)
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 Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes.
このドキュメントはService ProviderがIP Virtual兵士のNetworks(VPNs)を顧客に提供するのにIPバックボーンを使用するかもしれないメソッドを説明します。 このメソッドは顧客の縁のルータ(CEルータ)がService Providerの縁のルータ(PEルータ)にそれらのルートを送る「同輩モデル」を使用します。 顧客のルーティング・アルゴリズムに目に見えるどんな「オーバレイ」もありません、そして、異なったサイトのCEルータは互いと共にじっと見ません。 データ・パケットがバックボーンを通してトンネルを堀られるので、コアルータはVPNルートを知る必要はありません。
This document obsoletes RFC 2547.
このドキュメントはRFC2547を時代遅れにします。
Rosen & Rekhter Standards Track [Page 1] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Virtual Private Networks ...................................4
1.2. Customer Edge and Provider Edge ............................5
1.3. VPNs with Overlapping Address Spaces .......................6
1.4. VPNs with Different Routes to the Same System ..............7
1.5. SP Backbone Routers ........................................7
1.6. Security ...................................................8
2. Sites and CEs ...................................................8
3. VRFs: Multiple Forwarding Tables in PEs .........................9
3.1. VRFs and Attachment Circuits ...............................9
3.2. Associating IP Packets with VRFs ..........................10
3.3. Populating the VRFs .......................................11
4. VPN Route Distribution via BGP .................................12
4.1. The VPN-IPv4 Address Family ...............................13
4.2. Encoding of Route Distinguishers ..........................14
4.3. Controlling Route Distribution ............................15
4.3.1. The Route Target Attribute .........................15
4.3.2. Route Distribution Among PEs by BGP ................17
4.3.3. Use of Route Reflectors ............................20
4.3.4. How VPN-IPv4 NLRI Is Carried in BGP ................22
4.3.5. Building VPNs Using Route Targets ..................23
4.3.6. Route Distribution Among VRFs in a Single PE .......23
5. Forwarding .....................................................23
6. Maintaining Proper Isolation of VPNs ...........................26
7. How PEs Learn Routes from CEs ..................................27
8. How CEs Learn Routes from PEs ..................................30
9. Carriers' Carriers .............................................30
10. Multi-AS Backbones ............................................32
11. Accessing the Internet from a VPN .............................34
12. Management VPNs ...............................................36
13. Security Considerations .......................................37
13.1. Data Plane ...............................................37
13.2. Control Plane ............................................39
13.3. Security of P and PE Devices .............................39
14. Quality of Service ............................................39
15. Scalability ...................................................40
16. IANA Considerations ...........................................40
17. Acknowledgements ..............................................41
18. Contributors ..................................................41
19. Normative References ..........................................44
20. Informative References ........................................45
1. 序論…3 1.1. 仮想の私設のネットワーク…4 1.2. 顧客縁とプロバイダーは斜めに進みます…5 1.3. アドレス空間を重ね合わせるVPNs…6 1.4. 同じシステムへの異なったルートがあるVPNs…7 1.5. SPバックボーンルータ…7 1.6. セキュリティ…8 2. サイトとCEs…8 3. VRFs: PEsの複数の推進テーブル…9 3.1. VRFsと付属回路…9 3.2. IPパケットをVRFsに関連づけます…10 3.3. VRFsに居住します…11 4. BGPを通したVPN Route Distribution…12 4.1. VPN-IPv4はファミリーに演説します…13 4.2. ルートDistinguishersのコード化…14 4.3. ルート分配を制御します…15 4.3.1. ルート目標属性…15 4.3.2. BGPは分配をPEsに発送してください…17 4.3.3. ルート反射鏡の使用…20 4.3.4. どのようにVPN-IPv4 NLRIはBGPで運ばれるか…22 4.3.5. VPNsに使用を建てて、目標を発送してください…23 4.3.6. 独身のPEのVRFsに分配を発送してください…23 5. 転送します。23 6. VPNsの適切な分離を維持します…26 7. PEsはCEsからルートをどう学ぶか…27 8. CEsはPEsからルートをどう学ぶか…30 9. キャリアズキャリア…30 10. マルチ、バックボーン…32 11. VPNからインターネットにアクセスします…34 12. 管理VPNs…36 13. セキュリティ問題…37 13.1. データ飛行機…37 13.2. 飛行機を制御してください…39 13.3. PのセキュリティとPEデバイス…39 14. サービスの品質…39 15. スケーラビリティ…40 16. IANA問題…40 17. 承認…41 18. 貢献者…41 19. 標準の参照…44 20. 有益な参照…45
Rosen & Rekhter Standards Track [Page 2] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[2ページ]。
1. Introduction
1. 序論
This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers). Border Gateway Protocol (BGP) [BGP, BGP-MP] is then used by the Service Provider to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. This is done in a way that ensures that routes from different VPNs remain distinct and separate, even if two VPNs have an overlapping address space. The PE routers distribute, to the CE routers in a particular VPN, the routes from other the CE routers in that VPN. The CE routers do not peer with each other, hence there is no "overlay" visible to the VPN's routing algorithm. The term "IP" in "IP VPN" is used to indicate that the PE receives IP datagrams from the CE, examines their IP headers, and routes them accordingly.
このドキュメントはService ProviderがIP Virtual兵士のNetworks(VPNs)を顧客に提供するのにIPバックボーンを使用するかもしれないメソッドを説明します。 このメソッドは「同輩モデル」を使用します。そこでは、顧客の縁のルータ(CEルータ)はService Providerの縁のルータ(PEルータ)にそれらのルートを送ります。 そして、ボーダ・ゲイトウェイ・プロトコル(BGP)[BGP、BGP-MP]は、そのVPNに付けられているPEルータの中で特定のVPNのルートを交換するのにService Providerによって使用されます。 これは異なったVPNsからのルートが異なって別々のままで残っているのを確実にする方法で完了しています、2VPNsに重なっているアドレス空間があっても。 PEルータは他からのそのVPNの特定のVPN、ルートのCEルータをCEルータに分配します。 CEルータは互いと共にじっと見ません、したがって、VPNのルーティング・アルゴリズムに目に見えるどんな「オーバレイ」もありません。 「IP VPN」の「IP」という用語は、PEがそれに従って、CeからIPデータグラムを受けて、彼らのIPヘッダーを調べて、彼らを発送するのを示すのに使用されます。
Each route within a VPN is assigned a Multiprotocol Label Switching (MPLS) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] label; when BGP distributes a VPN route, it also distributes an MPLS label for that route. Before a customer data packet travels across the Service Provider's backbone, it is encapsulated with the MPLS label that corresponds, in the customer's VPN, to the route that is the best match to the packet's destination address. This MPLS packet is further encapsulated (e.g., with another MPLS label or with an IP or Generic Routing Encapsulation (GRE) tunnel header [MPLS-in-IP-GRE]) so that it gets tunneled across the backbone to the proper PE router. Thus, the backbone core routers do not need to know the VPN routes.
Multiprotocol Label Switching(MPLS)[MPLS-ARCH、MPLS-BGP、MPLS-ENCAPS]ラベルはVPNの中の各ルートに割り当てられます。 また、BGPがVPNルートを分配するとき、それはそのルートにMPLSラベルを分配します。 顧客データ・パケットがService Providerのバックボーンの向こう側に移動する前に、それは対応するMPLSラベルでカプセル化されます、顧客のVPNで、パケットの送付先アドレスへの最も良いマッチであるルートに。 このMPLSパケットがさらにカプセルに入れられるので(例えば、別のMPLSラベルかIPかGenericルート設定Encapsulation(GRE)トンネルヘッダー[IP GREのMPLS]と共に)、それはバックボーンの向こう側に適切なPEルータにトンネルを堀られます。 したがって、バックボーンコアルータはVPNルートを知る必要はありません。
The primary goal of this method is to support the case in which a client obtains IP backbone services from a Service Provider or Service Providers with which it maintains contractual relationships. The client may be an enterprise, a group of enterprises that need an extranet, an Internet Service Provider, an application service provider, another VPN Service Provider that uses this same method to offer VPNs to clients of its own, etc. The method makes it very simple for the client to use the backbone services. It is also very scalable and flexible for the Service Provider, and allows the Service Provider to add value.
このメソッドのプライマリ目標はクライアントがそれと契約上の関係を維持するService ProviderかService ProvidersからIPバックボーンサービスを得る場合をサポートすることです。 クライアントは企業、エクストラネット、インターネットサービスプロバイダ、アプリケーションサービスプロバイダー、それ自身のクライアントにVPNsを提供するこの同じメソッドなどを使用する別のVPN Service Providerを必要とする企業のグループであるかもしれません。 メソッドで、クライアントがバックボーンサービスを利用するのが非常に簡単になります。 それは、Service Providerにまた、非常にスケーラブルであって、フレキシブルであり、Service Providerが価値を高めるのを許容します。
Rosen & Rekhter Standards Track [Page 3] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[3ページ]。
1.1. Virtual Private Networks
1.1. 仮想私設網
Consider a set of "sites" that are attached to a common network that we call "the backbone". Now apply some policy to create a number of subsets of that set, and impose the following rule: two sites may have IP interconnectivity over that backbone only if at least one of these subsets contains them both.
私たちが「バックボーン」と呼ぶ一般的なネットワークに付けられている1セットの「サイト」を考えてください。 今度は、何らかの方針を適用して、そのセットの多くの部分集合を作成してください、以下の規則を課してください: 少なくともこれらの部分集合の1つがそれらの両方を含んでいる場合にだけ、2つのサイトがそのバックボーンの上にIPの相互接続性を持っているかもしれません。
These subsets are Virtual Private Networks (VPNs). Two sites have IP connectivity over the common backbone only if there is some VPN that contains them both. Two sites that have no VPN in common have no connectivity over that backbone.
これらの部分集合はVirtual兵士のNetworks(VPNs)です。 それらの両方を含むいくらかのVPNがある場合にだけ、2つのサイトが一般的なバックボーンの上にIPの接続性を持っています。 VPNが全く共通でない2つのサイトがそのバックボーンの上に接続性を全く持っていません。
If all the sites in a VPN are owned by the same enterprise, the VPN may be thought of as a corporate "intranet". If the various sites in a VPN are owned by different enterprises, the VPN may be thought of as an "extranet". A site can be in more than one VPN; e.g., in an intranet and in several extranets. In general, when we use the term "VPN" we will not be distinguishing between intranets and extranets.
VPNのすべてのサイトが同じ企業によって所有されているなら、VPNは法人の「イントラネット」として考えられるかもしれません。 VPNの様々なサイトが異なった企業によって所有されているなら、VPNは「エクストラネット」として考えられるかもしれません。 サイトが1VPNにあることができます。 例えば、イントラネットといくつかのエクストラネットで。 一般に、"VPN"という用語を使用する場合、私たちはイントラネットとエクストラネットを見分けないでしょう。
We refer to the owners of the sites as the "customers". We refer to the owners/operators of the backbone as the "Service Providers" (SPs). The customers obtain "VPN service" from the SPs.
私たちは「顧客」とサイトの所有者を呼びます。 私たちは「サービスプロバイダー」(SPs)とバックボーンの所有者/オペレータを呼びます。 顧客はSPsから「VPNサービス」を得ます。
A customer may be a single enterprise, a set of enterprises, an Internet Service Provider, an Application Service Provider, another SP that offers the same kind of VPN service to its own customers, etc.
顧客は単一の企業、企業、インターネットサービスプロバイダ、Application Service Provider、それ自身の顧客に対する同じ種類のVPNサービスを提供する別のSPなどのセットであるかもしれません。
The policies that determine whether a particular collection of sites is a VPN are the policies of the customers. Some customers will want the implementation of these policies to be entirely the responsibility of the SP. Other customers may want to share with the SP the responsibility for implementing these policies. This document specifies mechanisms that can be used to implement these policies. The mechanisms we describe are general enough to allow these policies to be implemented either by the SP alone or by a VPN customer together with the SP. Most of the discussion is focused on the former case, however.
サイトの特定の収集がVPNであるかどうか決定する方針は顧客の方針です。 何人かの顧客がこれらの方針の実装に完全にSPの責任であって欲しくなるでしょう。 他の顧客はこれらの政策を実施することへの責任をSPと共有したがっているかもしれません。 このドキュメントはこれらの政策を実施するのに使用できるメカニズムを指定します。 私たちが説明するメカニズムはこれらの政策がSPだけかSPに伴うVPN顧客によって実施されるのを許容するほど一般的です。 しかしながら、議論の大部分は前のケースに焦点を合わせられます。
The mechanisms discussed in this document allow the implementation of
a wide range of policies. For example, within a given VPN, one can
allow every site to have a direct route to every other site ("full
mesh"). Alternatively, one can force traffic between certain pairs
of sites to be routed via a third site. This can be useful, e.g., if
it is desired that traffic between a pair of sites be passed through
a firewall, and the firewall is located at the third site.
本書では議論したメカニズムはさまざまな方針の実装を許容します。 例えば、与えられたVPNの中では、あらゆるサイトがもので他のあらゆるサイト(「完全なメッシュ」)に直航路を持つことができます。 あるいはまた、ものによって、3番目のサイトを通してやむを得ずサイトのある組の間のトラフィックを発送できます。 これは役に立つ場合があります、例えば、1組のサイトの間のトラフィックがファイアウォールを通り抜けることが望まれていて、ファイアウォールが3番目のサイトに位置しているなら。
Rosen & Rekhter Standards Track [Page 4] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[4ページ]。
In this document, we restrict our discussion to the case in which the customer is explicitly purchasing VPN service from an SP, or from a set of SPs that have agreed to cooperate to provide the VPN service. That is, the customer is not merely purchasing internet access from an SP, and the VPN traffic does not pass through a random collection of interconnected SP networks.
本書では、私たちは議論を顧客がSPか、VPNサービスを提供するために協力するのに同意したSPsの1セットから明らかにVPNサービスを購入している場合に制限します。 すなわち、顧客はSPからインターネットアクセスを単に購入していません、そして、VPNトラフィックはインタコネクトされたSPネットワークの無作為の収集を通り抜けません。
We also restrict our discussion to the case in which the backbone provides an IP service to the customer, rather than, e.g., a layer 2 service such as Frame Relay, Asynchronous Transfer Mode (ATM), ethernet, High Level Data Link Control (HDLC), or Point-to-Point Protocol (PPP). The customer may attach to the backbone via one of these (or other) layer 2 services, but the layer 2 service is terminated at the "edge" of the backbone, where the customer's IP datagrams are removed from any layer 2 encapsulation.
また、私たちが議論をバックボーンがむしろ顧客に対するIPサービスを提供する場合に制限する、例えば、Frame Relay(PointからAsynchronous Transfer Mode(ATM)、イーサネット、High Level Data Link Control(HDLC)、またはポイントへのプロトコル(PPP))などの層2のサービス 顧客はこれらの(何らかの)層の2サービスの1つを通してバックボーンに付くかもしれませんが、層2のサービスは顧客のIPデータグラムがどんな層からも取り外されるバックボーンの「縁」2カプセル化で終えられます。
In the rest of this introduction, we specify some properties that VPNs should have. The remainder of this document specifies a set of mechanisms that can be deployed to provide a VPN model that has all these properties. This section also introduces some of the technical terminology used in the remainder of the document.
この序論の残りでは、私たちはVPNsが持っているはずであるいくつかの特性を指定します。 このドキュメントの残りはこれらのすべての特性を持っているVPNモデルを提供するために配布することができる1セットのメカニズムを指定します。 また、このセクションはドキュメントの残りに使用される専門語のいくつかを導入します。
1.2. Customer Edge and Provider Edge
1.2. 顧客縁とプロバイダー縁
Routers can be attached to each other, or to end systems, in a variety of different ways: PPP connections, ATM Virtual Circuits (VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2 Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc. We will use the term "attachment circuit" to refer generally to some such means of attaching to a router. An attachment circuit may be the sort of connection that is usually thought of as a "data link", or it may be a tunnel of some sort; what matters is that it be possible for two devices to be network layer peers over the attachment circuit.
ルータは互い、または、さまざまな異なった方法でエンドシステムに愛着できます: PPP接続、ATM Virtual Circuits(VCs)、Frame Relay VCs、イーサネットインタフェース、イーサネットインタフェースのVirtualローカル・エリア・ネットワーク(VLANs)、GREトンネル、Layer2Tunnelingプロトコル(L2TP)トンネル、IPsecトンネルなど 私たちは、一般に、ルータに付くそのようないくつかの手段を示すのに「付属回路」という用語を使用するつもりです。 付属回路は通常、「データ・リンク」として思われる接続の種類であるかもしれませんかそれはある種のトンネルであるかもしれません。 重要なことはそれが2台のデバイスが付属回路の上のネットワーク層同輩であることで可能であるということです。
Each VPN site must contain one or more Customer Edge (CE) devices. Each CE device is attached, via some sort of attachment circuit, to one or more Provider Edge (PE) routers.
それぞれのVPNサイトは1Customer Edge(CE)のデバイスを含まなければなりません。 それぞれのCEデバイスはある種の付属回路を通して1Provider Edge(PE)のルータに取り付けられます。
Routers in the SP's network that do not attach to CE devices are known as "P routers".
SPのネットワークにおけるCEデバイスに付かないルータは「Pルータ」として知られています。
CE devices can be hosts or routers. In a typical case, a site contains one or more routers, some of which are attached to PE routers. The site routers that attach to the PE routers would then be the CE devices, or "CE routers". However, there is nothing to prevent a non-routing host from attaching directly to a PE router, in which case the host would be a CE device.
CEデバイスは、ホストかルータであるかもしれません。 典型的な場合では、サイトは1つ以上のルータを含んでいます。その或るものはPEルータに付けられています。 そして、PEルータに付くサイトルータは、CEデバイス、または「CEルータ」でしょう。 しかしながら、何も付くのから直接PEルータまで非ルーティングホストを防ぐものがなくて、CEデバイスがどれがホストをケースに入れるかで、あるでしょう。
Rosen & Rekhter Standards Track [Page 5] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[5ページ]。
Sometimes, what is physically attached to a PE router is a layer 2 switch. In this case, we do NOT say that the layer 2 switch is a CE device. Rather, the CE devices are the hosts and routers that communicate with the PE router through the layer 2 switch; the layer 2 infrastructure is transparent. If the layer 2 infrastructure provides a multipoint service, then multiple CE devices can be attached to the PE router over the same attachment circuit.
時々、物理的にPEルータに付けられているものは層2のスイッチです。 この場合、私たちは、層2のスイッチがCEデバイスであると言いません。 CEデバイスは、むしろ、層2のスイッチを通ってPEルータで交信するホストとルータです。 層2のインフラストラクチャは見え透いています。 層の2インフラストラクチャが多点サービスを提供するなら、同じ付属回路の上のPEルータに複数のCEデバイスを取り付けることができます。
CE devices are logically part of a customer's VPN. PE and P routers are logically part of the SP's network.
CEデバイスは論理的にそうです。顧客のVPNの一部。 PEとPルータは論理的にそうです。SPのネットワークの一部。
The attachment circuit over which a packet travels when going from CE to PE is known as that packet's "ingress attachment circuit", and the PE as the packet's "ingress PE". The attachment circuit over which a packet travels when going from PE to CE is known as that packet's "egress attachment circuit", and the PE as the packet's "egress PE".
CEからPEまで行くときパケットが移動する付属回路はそのパケットとして知られているのが、「イングレス付属回路」と、パケット「イングレスPE」としてPEであるということです。 PEからCEまで行くときパケットが移動する付属回路はそのパケットとして知られているのが、「出口付属回路」と、パケット「出口PE」としてPEであるということです。
We will say that a PE router is attached to a particular VPN if it is attached to a CE device that is in a site of that VPN. Similarly, we will say that a PE router is attached to a particular site if it is attached to a CE device that is in that site.
私たちは、それがそのVPNのサイトにあるCEデバイスに取り付けられるならPEルータが特定のVPNに付けられると言うつもりです。 同様に、私たちは、それがそのサイトにあるCEデバイスに取り付けられるならPEルータが特定のサイトに付けられると言うつもりです。
When the CE device is a router, it is a routing peer of the PE(s) to which it is attached, but it is NOT a routing peer of CE routers at other sites. Routers at different sites do not directly exchange routing information with each other; in fact, they do not even need to know of each other at all. As a consequence, the customer has no backbone or "virtual backbone" to manage, and does not have to deal with any inter-site routing issues. In other words, in the scheme described in this document, a VPN is NOT an "overlay" on top of the SP's network.
CE装置がルータであることのそれが付けているPE(s)のルーティング同輩ですが、それは他のサイトのCEルータのルーティング同輩ではありません。 異なったサイトのルータは直接ルーティング情報を互いと交換しません。 事実上、彼らは互いを全く知る必要さえありません。 結果として、顧客には、どんな相互サイトルーティング問題にも対処するために、管理して、持っていない背骨か「仮想の背骨」が全くあります。 言い換えれば、本書では説明された計画では、VPNはSPのネットワークの上の「オーバレイ」ではありません。
With respect to the management of the edge devices, clear administrative boundaries are maintained between the SP and its customers. Customers are not required to access the PE or P routers for management purposes, nor is the SP required to access the CE devices for management purposes.
エッジデバイスの管理に関して、透明な管理境界はSPとその顧客の間で維持されます。 顧客は管理目的のためにPEかPルータにアクセスする必要はありません、そして、SPは管理目的のためにCE装置にアクセスする必要はありません。
1.3. VPNs with Overlapping Address Spaces
1.3. アドレス空間を重ね合わせるVPNs
If two VPNs have no sites in common, then they may have overlapping address spaces. That is, a given address might be used in VPN V1 as the address of system S1, but in VPN V2 as the address of a completely different system S2. This is a common situation when the VPNs each use an RFC 1918 private address space. Of course, within each VPN, each address must be unambiguous.
2VPNsがサイトが全く共通でないなら、それらには、重なっているアドレス空間があるかもしれません。 すなわち、与えられたアドレスはシステムS1のアドレスとしてVPN V1で使用されますが、完全に異なったシステムS2のアドレスとしてのVPN V2で使用されるかもしれません。 VPNsがそれぞれRFC1918プライベート・アドレススペースを使用するとき、これは日常の状況です。 もちろん、各VPNの中では、それぞれのアドレスは明白であるに違いありません。
Rosen & Rekhter Standards Track [Page 6] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[6ページ]。
Even two VPNs that do have sites in common may have overlapping address spaces, as long as there is no need for any communication between systems with such addresses and systems in the common sites.
サイトが共通である2VPNsさえ重なっているアドレス空間を持っているかもしれません、共通部位にそのようなアドレスとシステムがあるシステムのどんなコミュニケーションの必要も全くない限り。
1.4. VPNs with Different Routes to the Same System
1.4. 同じシステムへの異なったルートがあるVPNs
Although a site may be in multiple VPNs, it is not necessarily the case that the route to a given system at that site should be the same in all the VPNs. Suppose, for example, we have an intranet consisting of sites A, B, and C, and an extranet consisting of A, B, C, and the "foreign" site D. Suppose that at site A there is a server, and we want clients from B, C, or D to be able to use that server. Suppose also that at site B there is a firewall. We want all the traffic from site D to the server to pass through the firewall, so that traffic from the extranet can be access controlled. However, we don't want traffic from C to pass through the firewall on the way to the server, since this is intranet traffic.
サイトが複数のVPNsにあるかもしれませんが、そのサイトの与えられたシステムへのルートがすべてのVPNsで同じであるべきであることは、必ず事実であるというわけではありません。 例えば、サイトA、B、C、およびA、B、C、およびそこのサイトAのサーバである「外国」のサイトD.Supposeから成るエクストラネットから成るイントラネットがあります、そして、思ってください、そして、私たちはB、C、またはDからのクライアントにそのサーバを使用できて欲しいと思います。また、そこのサイトBのそれがファイアウォールであると仮定してください。 私たちは、すべてのサイトDからサーバまでの交通にファイアウォールを通り抜けて欲しいと思います、エクストラネットからの交通が制御されたアクセスになるように。 しかしながら、私たちは、Cからの交通にサーバへの途中にファイアウォールを通り抜けて欲しいと思いません、これがイントラネット交通であることで。
It is possible to set up two routes to the server. One route, used by sites B and C, takes the traffic directly to site A. The second route, used by site D, takes the traffic instead to the firewall at site B. If the firewall allows the traffic to pass, it then appears to be traffic coming from site B, and follows the route to site A.
2つのルートをサーバにセットアップするのは可能です。サイトBとCによって使用される1つのルートが、サイトDによって使用されるルートが代わりに交通がファイアウォールで通過できるサイトB.Ifのファイアウォールに交通を取って、次に、それがサイトBから来る交通であるように見える秒に直接サイトA.に交通を取って、サイトAにそのルートを取ります。
1.5. SP Backbone Routers
1.5. SP背骨ルータ
The SP's backbone consists of the PE routers, as well as other
routers ("P routers") that do not attach to CE devices.
SPの背骨はPEルータから成ります、CE装置に付かない他のルータ(「Pルータ」)と同様に。
If every router in an SP's backbone had to maintain routing information for all the VPNs supported by the SP, there would be severe scalability problems; the number of sites that could be supported would be limited by the amount of routing information that could be held in a single router. It is important therefore that the routing information about a particular VPN only needs to be present in the PE routers that attach to that VPN. In particular, the P routers do not need to have ANY per-VPN routing information whatsoever. (This condition may need to be relaxed somewhat when multicast routing is considered. This is not considered further in this paper, but is examined in [VPN-MCAST].)
SPの背骨のあらゆるルータがSPによって支持されたすべてのVPNsのためのルーティング情報を保守しなければならないなら、厳しいスケーラビリティ問題があるでしょうに。 サポートできたサイトの数はただ一つのルータで保持できたルーティング情報の量によって制限されるでしょう。 したがって、特定のVPNのルーティング情報が、そのVPNに付くPEルータで存在している必要があるだけであるのは、重要です。 特に、Pルータは全くどんな1VPNあたりのルーティング情報も必要としません。(この状態は、いくらかマルチキャストルーティングが考えられるとき、弛緩する必要があるかもしれません。 これは、この紙で、より遠くに考えられませんが、[VPN-MCAST]で調べられます。)
So just as the VPN owners do not have a backbone or "virtual backbone" to administer, the SPs themselves do not have a separate backbone or "virtual backbone" to administer for each VPN. Site-to- site routing in the backbone is optimal (within the constraints of the policies used to form the VPNs) and is not constrained in any way by an artificial "virtual topology" of tunnels.
それで、VPN所有者には管理する背骨か「仮想の背骨」があるだけではないように、SPs自身に各VPNのために管理する別々の背骨か「仮想の背骨」がありません。 背骨でのサイトからサイトへのルーティングは、最適であり(VPNsを形成するのに使用される方針の規制の中の)、トンネルの人工の「仮想のトポロジー」によって何らかの方法で抑制されません。
Rosen & Rekhter Standards Track [Page 7] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[7ページ]。
Section 10 discusses some of the special issues that arise when the backbone spans several Service Providers.
セクション10は背骨が数個のService Providersにかかるとき起こる増刊のいくつかについて論じます。
1.6. Security
1.6. セキュリティ
VPNs of the sort being discussed here, even without making use of cryptographic security measures, are intended to provide a level of security equivalent to that obtainable when a layer 2 backbone (e.g., Frame Relay) is used. That is, in the absence of misconfiguration or deliberate interconnection of different VPNs, it is not possible for systems in one VPN to gain access to systems in another VPN. Of course, the methods described herein do not by themselves encrypt the data for privacy, nor do they provide a way to determine whether data has been tampered with en route. If this is desired, cryptographic measures must be applied in addition. (See, e.g., [MPLS/BGP-IPsec].) Security is discussed in more detail in Section 13.
層2の背骨(例えば、Frame Relay)が使用されているとき、ここで暗号の安全策を利用さえしないで議論する種類のVPNsが入手可能なそれに同等なセキュリティのレベルを提供することを意図します。 すなわち、異なったVPNsのmisconfigurationか慎重なインタコネクトがないとき、1VPNのシステムが別のVPNのシステムへのアクセスを得るのは、可能ではありません。 もちろん、ここに説明された方法は自分たちでプライバシーのためのデータをコード化しません、そして、それらは途中でデータをいじってあるかどうか決定する方法を提供しません。 これが望まれているなら、さらに、暗号の測定を適用しなければなりません。 (例えば[MPLS/BGP-IPsec]見てください。) さらに詳細にセクション13でセキュリティについて議論します。
2. Sites and CEs
2. サイトとCEs
From the perspective of a particular backbone network, a set of IP systems may be regarded as a "site" if those systems have mutual IP interconnectivity that doesn't require use of the backbone. In general, a site will consist of a set of systems that are in geographic proximity. However, this is not universally true. If two geographic locations are connected via a leased line, over which Open Shortest Path First (OSPF) protocol [OSPFv2] is running, and if that line is the preferred way of communicating between the two locations, then the two locations can be regarded as a single site, even if each location has its own CE router. (This notion of "site" is topological, rather than geographical. If the leased line goes down, or otherwise ceases to be the preferred route, but the two geographic locations can continue to communicate by using the VPN backbone, then one site has become two.)
特定の背骨ネットワークの見解から、それらのシステムに背骨の使用を必要としない互いのIPの相互接続性があるなら、1セットのIPシステムは「サイト」と見なされるかもしれません。 一般に、サイトは1セットの地理的な近接中であることのシステムから成るでしょう。 しかしながら、これは一般に本当ではありません。 2つの地理的な位置がオープンShortest Path First(OSPF)プロトコル[OSPFv2]が走っている専用線を通してつなげられて、その線が2つの位置の間で交信する都合のよい方法であるなら、2つの位置をただ一つのサイトと見なすことができます、各位置にそれ自身のCEルータがあっても。 (地理的であるというよりむしろ「サイト」のこの概念は位相的です。 専用線が、落ちるか、またはそうでなければ、都合のよいルートであることをやめますが、2つの地理的な位置が、VPN背骨を使用することによって交信し続けることができるなら、当時の1つのサイトが2になりました。)
A CE device is always regarded as being in a single site (though as we shall see in Section 3.2, a site may consist of multiple "virtual sites"). A site, however, may belong to multiple VPNs.
CE装置はいつもただ一つのサイトにあると見なされます(私たちがセクション3.2で見るようにサイトが複数の「仮想のサイト」から成るかもしれませんが)。 しかしながら、サイトは複数のVPNsに属すかもしれません。
A PE router may attach to CE devices from any number of different sites, whether those CE devices are in the same or in different VPNs. A CE device may, for robustness, attach to multiple PE routers, of the same or of different service providers. If the CE device is a router, the PE router and the CE router will appear as router adjacencies to each other.
PEルータはいろいろな異なったサイトからCE装置に付くかもしれません、それらのCE装置が同じくらいか異なったVPNsにあるか否かに関係なく。 丈夫さのために、CE装置は同じくらいか異なったサービスプロバイダーの複数のPEルータに付くかもしれません。 CE装置がルータであるなら、PEルータとCEルータはルータ隣接番組として互いにおいて現れるでしょう。
While we speak mostly of "sites" as being the basic unit of interconnection, nothing here prevents a finer degree of granularity in the control of interconnectivity. For example, certain systems at
私たちはインタコネクトの原単位であるとしてほとんど「サイト」について話しますが、ここの何も相互接続性のコントロールにおける、よりすばらしい度の粒状を防ぎません。 例えば、あるシステム
Rosen & Rekhter Standards Track [Page 8] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[8ページ]。
a site may be members of an intranet as well as members of one or more extranets, while other systems at the same site may be restricted to being members of the intranet only. However, this might require that the site have two attachment circuits to the backbone, one for the intranet and one for the extranet; it might further require that firewall functionality be applied on the extranet attachment circuit.
サイトは1つ以上のエクストラネットのメンバーと同様にイントラネットのメンバーであるかもしれません、同じサイトの他のシステムがイントラネットのメンバー専用に制限されるかもしれませんが。 しかしながら、これは、サイトには背骨への2個の付属サーキット、イントラネットのためのもの、およびエクストラネットのための1つがあるのを必要とするかもしれません。 それは、ファイアウォールの機能性がエクストラネット付属サーキットに適用されるのをさらに必要とするかもしれません。
3. VRFs: Multiple Forwarding Tables in PEs
3. VRFs: PEsの複数の推進テーブル
Each PE router maintains a number of separate forwarding tables. One of the forwarding tables is the "default forwarding table". The others are "VPN Routing and Forwarding tables", or "VRFs".
それぞれのPEルータは多くの別々の推進テーブルを維持します。 推進テーブルの1つは「デフォルト推進テーブル」です。 他のものは、「VPNルート設定とForwardingテーブル」、または「VRFs」です。
3.1. VRFs and Attachment Circuits
3.1. VRFsと付属サーキット
Every PE/CE attachment circuit is associated, by configuration, with one or more VRFs. An attachment circuit that is associated with a VRF is known as a "VRF attachment circuit".
あらゆるPE/CE付属サーキットが構成によって1VRFsに関連づけられます。 VRFに関連している付属サーキットは「VRF付属サーキット」として知られています。
In the simplest case and most typical case, a PE/CE attachment circuit is associated with exactly one VRF. When an IP packet is received over a particular attachment circuit, its destination IP address is looked up in the associated VRF. The result of that lookup determines how to route the packet. The VRF used by a packet's ingress PE for routing a particular packet is known as the packet's "ingress VRF". (There is also the notion of a packet's "egress VRF", located at the packet's egress PE; this is discussed in Section 5.)
最も簡単な場合と最も典型的な場合では、PE/CE付属サーキットはちょうど1VRFに関連しています。 特定の付属サーキットの上にIPパケットを受け取るとき、関連VRFで送付先IPアドレスを調べます。 そのルックアップの結果はパケットを発送する方法を決定します。 特定のパケットを発送するのにパケットのイングレスPEによって使用されたVRFはパケット「イングレスVRF」として知られています。 (また、パケットのパケットの出口に位置する「出口VRF」PEの概念があります; セクション5でこれについて議論します。)
If an IP packet arrives over an attachment circuit that is not associated with any VRF, the packet's destination address is looked up in the default forwarding table, and the packet is routed accordingly. Packets forwarded according to the default forwarding table include packets from neighboring P or PE routers, as well as packets from customer-facing attachment circuits that have not been associated with VRFs.
IPパケットがどんなVRFにも関連づけられない付属サーキットの上に到着するなら、パケットの送付先アドレスはデフォルト推進テーブルで調べられます、そして、パケットはそれに従って、発送されます。 デフォルト推進テーブルに応じて進められたパケットは隣接しているPかPEルータからのパケットを含んでいます、VRFsに関連していない顧客に面する付属サーキットからのパケットと同様に。
Intuitively, one can think of the default forwarding table as containing "public routes", and of the VRFs as containing "private routes". One can similarly think of VRF attachment circuits as being "private", and of non-VRF attachment circuits as being "public".
直観的に、人は「公共のルート」を含むとしてのデフォルト推進テーブル、および「個人的なルート」を含むとしてのVRFsを考えることができます。 人は同様に「個人的」であるとしてのVRF付属サーキット、および「公共」であるとしての非VRF付属サーキットを考えることができます。
If a particular VRF attachment circuit connects site S to a PE router, then connectivity from S (via that attachment circuit) can be restricted by controlling the set of routes that gets entered in the corresponding VRF. The set of routes in that VRF should be limited to the set of routes leading to sites that have at least one VPN in
特定のVRF付属サーキットがPEルータにサイトSをつなげるなら、S(その付属サーキットを通した)からの接続性は、対応するVRFに入られるルートのセットを制御することによって、制限される場合があります。 そのVRFのルートのセットはそれが少なくとも1VPNを持っているサイトにつながるルートのセットに制限されるべきです。
Rosen & Rekhter Standards Track [Page 9] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[9ページ]。
common with S. Then a packet sent from S over a VRF attachment circuit can only be routed by the PE to another site S' if S' is in one of the same VPNs as S. That is, communication (via PE routers) is prevented between any pair of VPN sites that have no VPN in common. Communication between VPN sites and non-VPN sites is prevented by keeping the routes to the VPN sites out of the default forwarding table.
パケットがSであるなら別のサイトSへのPEをサーキットを発送できるだけであるVRF付属の上のSから送ったS.Thenについて一般的であるのは、S.ThatがVPNsであるのにもかかわらずの、コミュニケーション(PEルータを通した)がVPNが全く共通でないどんな組のVPNサイトの間でも同じくらいの1つでは、防がれるということです。 VPNサイトと非VPNサイトとのコミュニケーションは、デフォルト推進テーブルにVPNサイトへのルートを入れないようにすることによって、防がれます。
If there are multiple attachment circuits leading from S to one or more PE routers, then there might be multiple VRFs that could be used to route traffic from S. To properly restrict S's connectivity, the same set of routes would have to exist in all the VRFs. Alternatively, one could impose different connectivity restrictions over different attachment circuit from S. In that case, some of the VRFs associated with attachment circuits from S would contain different sets of routes than some of the others.
Sから1つ以上のPEルータに導く複数の付属サーキットがあれば、S.から交通を発送するのに使用できた複数のVRFsがあるかもしれません。Toは適切にSの接続性を制限して、同じセットのルートはすべてのVRFsに存在しなければならないでしょう。 あるいはまた、人は異なった付属サーキットの上のS.と異なった接続性制限を課すことができました。そのケース、Sからの付属サーキットに関連しているいくつかのInのVRFsが何人かの他のものより異なったセットのルートを含んでいるでしょう。
We allow the case in which a single attachment circuit is associated with a set of VRFs, rather than with a single VRF. This can be useful if it is desired to divide a single VPN into several "sub-VPNs", each with different connectivity restrictions, where some characteristic of the customer packets is used to select from among the sub-VPNs. For simplicity though, we will usually speak of an attachment circuit as being associated with a single VRF.
私たちはただ一つの付属サーキットが独身のVRFと共にというよりむしろVRFsの1セットに関連している場合を許します。 独身のVPNを数個の「サブVPNs」に分割するのが必要であるなら、これは役に立つ場合があります、それぞれ異なった接続性制限で。そこでは、顧客パケットの何らかの特性がサブVPNsの中で選び抜くのにおいて使用されています。 もっとも、簡単さのために、通常、私たちは独身のVRFに関連しているとして付属サーキットについて話すつもりです。
3.2. Associating IP Packets with VRFs
3.2. IPパケットをVRFsに関連づけます。
When a PE router receives a packet from a CE device, it must determine the attachment circuit over which the packet arrived, as this determines in turn the VRF (or set of VRFs) that can be used for forwarding that packet. In general, to determine the attachment circuit over which a packet arrived, a PE router takes note of the physical interface over which the packet arrived, and possibly also takes note of some aspect of the packet's layer 2 header. For example, if a packet's ingress attachment circuit is a Frame Relay VC, the identity of the attachment circuit can be determined from the physical Frame Relay interface over which the packet arrived, together with the Data Link Connection Identifier (DLCI) field in the packet's Frame Relay header.
PEルータがCE装置からパケットを受けるとき、パケットが到着した付属サーキットを決定しなければなりません、これが順番に、そのパケットを進めるのに使用できるVRF(または、VRFsのセット)を決定するとき。 一般に、パケットが到着した付属サーキットであり、PEルータがノートを取ることをパケットが到着して、またことによるとパケットの何らかの局面に注目する物理インターフェースを決定するには、2ヘッダーを層にしてください。 例えば、付属サーキットのアイデンティティはパケットのイングレス付属サーキットがFrame Relay VCであるなら、パケットが到着した物理的なFrame Relayインタフェースから決定できます、パケットのFrame RelayヘッダーのData Link Connection Identifier(DLCI)分野と共に。
Although the PE's conclusion that a particular packet arrived on a particular attachment circuit may be partially determined by the packet's layer 2 header, it must be impossible for a customer, by writing the header fields, to fool the SP into thinking that a packet that was received over one attachment circuit really arrived over a different one. In the example above, although the attachment circuit is determined partially by inspection of the DLCI field in the Frame Relay header, this field cannot be set freely by the customer.
2ヘッダー、特定のパケットが特定の付属サーキットの上に到着したというPEの結論はパケットの層のそばで部分的に決定しているかもしれませんが、顧客にとって、それは不可能であるに違いありません、SPが、1個の付属サーキットの上に受け取られたパケットが本当に異なったものの上で到着したと思うようにだますためにヘッダーフィールドを書くことによって。 例では、付属サーキットはFrame RelayヘッダーでのDLCI分野の点検で部分的に決定していますが、上では、顧客は自由にこの分野を設定できません。
Rosen & Rekhter Standards Track [Page 10] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[10ページ]。
Rather, it must be set to a value specified by the SP, or else the packet cannot arrive at the PE router.
むしろ、SPによって指定された値にそれを設定できなくなければなりませんか、パケットはPEルータに到着できません。
In some cases, a particular site may be divided by the customer into several "virtual sites". The SP may designate a particular set of VRFs to be used for routing packets from that site and may allow the customer to set some characteristic of the packet, which is then used for choosing a particular VRF from the set.
いくつかの場合、特定のサイトは数個の「仮想のサイト」への顧客に割られるかもしれません。 SPは、ルーティングパケットにそのサイトから使用されるためにVRFsの特定のセットを指定して、顧客が次にセットから特定のVRFを選ぶのに使用されるパケットの何らかの特性を設定するのを許容するかもしれません。
For example, each virtual site might be realized as a VLAN. The SP and the customer could agree that on packets arriving from a particular CE, certain VLAN values would be used to identify certain VRFs. Of course, packets from that CE would be discarded by the PE if they carry VLAN tag values that are not in the agreed-upon set. Another way to accomplish this is to use IP source addresses. In this case, the PE uses the IP source address in a packet received from the CE, along with the interface over which the packet is received, to assign the packet to a particular VRF. Again, the customer would only be able to select from among the particular set of VRFs that that customer is allowed to use.
例えば、それぞれの仮想のサイトはVLANとして実現されるかもしれません。 SPと顧客は、特定のCEから到着するパケットの上では、あるVLAN値が、あるVRFsを特定するのに使用されるのに同意できました。 もちろん、同意しているセットにないVLANタグ値を運ぶなら、そのCEからのパケットはPEによって捨てられるでしょう。 これを達成する別の方法はIPソースアドレスを使用することです。 この場合、PEはCEから受け取られたパケットでIPソースアドレスを使用します、パケットが特定のVRFにパケットを割り当てるために受け取られるインタフェースと共に。 一方、顧客は特定の中でその顧客が使用できるVRFsでセットから選び抜くことができるだけでしょう。
If it is desired to have a particular host be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with. It can do this, e.g., by sending packets from different virtual sites on different VLANs, or out different network interfaces.
特定のホストを複数の仮想のサイトにあるのが、必要であるなら、そのホストは、各パケットのためにパケットがどの仮想のサイトに関連しているかを決心しなければなりません。 それは、例えば、異なったVLANs、または出かけている異なったネットワーク・インターフェースに関する異なった仮想のサイトからパケットを送ることによって、これができます。
3.3. Populating the VRFs
3.3. VRFsに居住します。
With what set of routes are the VRFs populated?
何のセットのルートで、VRFsは居住されますか?
As an example, let PE1, PE2, and PE3 be three PE routers, and let CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from CE1, the routes that are reachable at CE1's site. If PE2 and PE3 are attached, respectively, to CE2 and CE3, and there is some VPN V containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2 and PE3 the routes that it has learned from CE1. PE2 and PE3 use these routes to populate the VRFs that they associate, respectively, with the sites of CE2 and CE3. Routes from sites that are not in VPN V do not appear in these VRFs, which means that packets from CE2 or CE3 cannot be sent to sites that are not in VPN V.
CE1、CE2、およびCE3が3つのCEルータであることを例として、PE1、PE2、およびPE3が3つのPEルータであることをさせてください、そして、させてください。 PE1がCE1からCE1のサイトで届いているルートを学ぶと仮定してください。 PE2とPE3がそれぞれCE2とCE3に取り付けられて、CE1、CE2、およびCE3を含むいくらかのVPN Vがあれば、PE1は、それがCE1から学んだルートをPE2とPE3に分配するのにBGPを使用します。 PE2とPE3は、CE2とCE3のサイトでそれぞれ、彼らが関連づけるVRFsに居住するのにこれらのルートを使用します。 VPN VにないサイトからのルートはこれらのVRFsに現れません。(VRFsはCE2かCE3からのパケットをVPN Vにないサイトに送ることができないことを意味します)。
When we speak of a PE "learning" routes from a CE, we are not presupposing any particular learning technique. The PE may learn routes by means of a dynamic routing algorithm, but it may also "learn" routes by having those routes configured (i.e., static routing). (In this case, to say that the PE "learned" the routes from the CE is perhaps to exercise a bit of poetic license.)
CEからルートを「学ぶ」PEについて話すとき、私たちは少しの特定の学習手法も予想していません。 PEはダイナミックルーティングアルゴリズムによってルートを学ぶかもしれませんが、それはそれらのルートを持っているのによるルートが構成した「学ぶ」(すなわち、スタティックルーティング)も学ぶかもしれません。 (この場合、PEがCEからルートを「学んだ」と言うのは、恐らく少しの詩的許容を運動させることです。)
Rosen & Rekhter Standards Track [Page 11] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[11ページ]。
PEs also need to learn, from other PEs, the routes that belong to a given VPN. The procedures to be used for populating the VRFs with the proper sets of routes are specified in Section 4.
また、PEsは、他のPEsから与えられたVPNに属すルートを学ぶ必要があります。 適切なセットのルートがあるVRFsに居住するのに使用されるべき手順はセクション4で指定されます。
If there are multiple attachment circuits leading from a particular PE router to a particular site, they might all be mapped to the same forwarding table. But if policy dictates, they could be mapped to different forwarding tables. For instance, the policy might be that a particular attachment circuit from a site is used only for intranet traffic, while another attachment circuit from that site is used only for extranet traffic. (Perhaps, e.g., the CE attached to the extranet attachment circuit is a firewall, while the CE attached to the intranet attachment circuit is not.) In this case, the two attachment circuits would be associated with different VRFs.
特定のPEルータから特定のサイトまで導く複数の付属サーキットがあれば、それらは同じ推進テーブルにすべて写像されるかもしれません。 しかし、方針が命令するなら、それらは異なった推進テーブルに写像されるかもしれません。 例えば、方針はサイトからの特定の付属サーキットがイントラネット交通にだけ使用されるということであるかもしれません、そのサイトからの別の付属サーキットがエクストラネット交通にだけ使用されますが。 (恐らく、そして、例えばエクストラネット付属サーキットに取り付けられたCEはファイアウォールです、イントラネット付属サーキットに取り付けられたCEがそうではありませんが。) この場合、2個の付属サーキットが異なったVRFsに関連しているでしょう。
Note that if two attachment circuits are associated with the same VRF, then packets that the PE receives over one of them will be able to reach exactly the same set of destinations as packets that the PE receives over the other. So two attachment circuits cannot be associated with the same VRF unless each CE is in the exact same set of VPNs as is the other.
2個の付属サーキットが関連していると同じVRF、PEが受ける当時のパケットで、それらの1つ以上がPEがもう片方の上で受けるパケットへのまさに同じセットの目的地に達することができることに注意してください。 それで、VPNsの全く同じセットに各CEがもう片方のようにない場合、2個の付属サーキットを同じVRFに関連づけることができません。
If an attachment circuit leads to a site which is in multiple VPNs, the attachment circuit may still associated with a single VRF, in which case the VRF will contain routes from the full set of VPNs of which the site is a member.
付属サーキットが複数のVPNsにあるサイトにつながるなら、付属サーキットはまだ独身のVRFに関連していた状態でつながっています、その場合、VRFがサイトがメンバーであるVPNsのフルセットからのルートを含むでしょう。
4. VPN Route Distribution via BGP
4. BGPを通したVPN Route Distribution
PE routers use BGP to distribute VPN routes to each other (more accurately, to cause VPN routes to be distributed to each other).
PEルータは、VPNルートを互いに分配するのにBGPを使用します(より正確に、VPNを引き起こすのは、互いに分配されるのを発送します)。
We allow each VPN to have its own address space, which means that a given address may denote different systems in different VPNs. If two routes to the same IP address prefix are actually routes to different systems, it is important to ensure that BGP not treat them as comparable. Otherwise, BGP might choose to install only one of them, making the other system unreachable. Further, we must ensure that POLICY is used to determine which packets get sent on which routes; given that several such routes are installed by BGP, only one such must appear in any particular VRF.
私たちは各VPNにそれ自身のアドレス空間を持たせます。(それは、与えられたアドレスが異なったVPNsの異系統を指示するかもしれないことを意味します)。 同じIPアドレス接頭語への2つのルートが実際に異系統へのルートであるなら、BGPが匹敵するとしてそれらを扱わないのを保証するのは重要です。 さもなければ、もう片方のシステムを手が届かなくして、BGPは、それらの1つだけをインストールするのを選ぶかもしれません。 さらに、私たちは、POLICYがどのパケットがどのルートで送られるかを決定するのに使用されるのを保証しなければなりません。 それを考えて、そのような数個のルートがBGP、そのようなものがどんな特定のVRFでも見えなければならない1つだけによってインストールされます。
We meet these goals by the use of a new address family, as specified below.
私たちは以下で指定されるとして新しいアドレス家族の使用でこれらの目標を達成します。
Rosen & Rekhter Standards Track [Page 12] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[12ページ]。
4.1. The VPN-IPv4 Address Family
4.1. VPN-IPv4アドレス家
The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes from multiple "address families". We introduce the notion of the "VPN-IPv4 address family". A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte Route Distinguisher (RD) and ending with a 4-byte IPv4 address. If several VPNs use the same IPv4 address prefix, the PEs translate these into unique VPN-IPv4 address prefixes. This ensures that if the same address is used in several different VPNs, it is possible for BGP to carry several completely different routes to that address, one for each VPN.
BGP Multiprotocol Extensions[BGP-MP]はBGPに複数の「アドレス家族」からルートを運ばせます。 私たちは「VPN-IPv4アドレス家」の概念を紹介します。 VPN-IPv4アドレスは12バイトの量です、8バイトのRoute Distinguisher(RD)と共に始まって、4バイトのIPv4アドレスで終わって。 数個のVPNsが同じIPv4アドレス接頭語を使用するなら、PEsはユニークなVPN-IPv4アドレス接頭語にこれらを翻訳します。 これは、同じアドレスが数個の異なったVPNsで使用されるなら、BGPが数個の完全に異なったルートをそのアドレスまで運ぶのが、可能であることを確実にします、各VPNあたり1つ。
Since VPN-IPv4 addresses and IPv4 addresses are different address families, BGP never treats them as comparable addresses.
VPN-IPv4アドレスとIPv4アドレスが異なったアドレス家族であるので、BGPは匹敵するアドレスとして彼らを決して扱いません。
An RD is simply a number, and it does not contain any inherent information; it does not identify the origin of the route or the set of VPNs to which the route is to be distributed. The purpose of the RD is solely to allow one to create distinct routes to a common IPv4 address prefix. Other means are used to determine where to redistribute the route (see Section 4.3).
RDは単に数です、そして、少しの固有の情報も含んでいません。 それは分配されているルートがことであるルートの起源かVPNsのセットを特定しません。 RDの目的は1つが一般的なIPv4アドレス接頭語に異なったルートを作成するのを唯一許容することです。 他の手段は、ルートをどこに再配付するかを決定するのに使用されます(セクション4.3を見てください)。
The RD can also be used to create multiple different routes to the very same system. We have already discussed a situation in which the route to a particular server should be different for intranet traffic than for extranet traffic. This can be achieved by creating two different VPN-IPv4 routes that have the same IPv4 part, but different RDs. This allows BGP to install multiple different routes to the same system, and allows policy to be used (see Section 4.3.5) to decide which packets use which route.
また、複数の異なったルートを全く同じシステムに作成するのにRDを使用できます。 私たちは既に、イントラネット交通において、特定のサーバへのルートがエクストラネット交通より異なるべきである状況について議論しました。 同じIPv4部分の、しかし、異なったRDsを持っている2つの異なったVPN-IPv4ルートを作成することによって、これを達成できます。 これは、BGPが複数の異なったルートを同じシステムにインストールするのを許容して、方針がどのパケットがどのルートを使用するかを決めるのに使用されるのを(セクション4.3.5を見ます)許容します。
The RDs are structured so that every Service Provider can administer its own "numbering space" (i.e., can make its own assignments of RDs), without conflicting with the RD assignments made by any other Service Provider. An RD consists of three fields: a 2-byte type field, an administrator field, and an assigned number field. The value of the type field determines the lengths of the other two fields, as well as the semantics of the administrator field. The administrator field identifies an assigned number authority, and the assigned number field contains a number that has been assigned, by the identified authority, for a particular purpose. For example, one could have an RD whose administrator field contains an Autonomous System number (ASN), and whose (4-byte) number field contains a number assigned by the SP to whom that ASN belongs (having been assigned to that SP by the appropriate authority).
RDsはあらゆるService Providerがそれ自身の「付番スペース」(すなわち、それ自身のRDsの課題をすることができる)を管理できるように、構造化されます、いかなる他のService ProviderによってもされるRD課題と闘争しないで。 RDは3つの分野から成ります: 2バイトのタイプ分野、管理者分野、および規定番号分野。 タイプ分野の値は他の2つの分野の長さを測定します、管理者分野の意味論と同様に。 管理者分野は規定番号権威を特定します、そして、規定番号分野は割り当てられた数を含んでいます、特定された権威で、特定の目的のために。 例えば、1つは管理者分野がAutonomous System番号(ASN)を含んで、(4バイト)のナンバーフィールドがそのASNが属するSPによって割り当てられた数を含むRDを持っているかもしれません(適切な権威によってそのSPに割り当てられて)。
RDs are given this structure in order to ensure that an SP that provides VPN backbone service can always create a unique RD when it
それであるときに、背骨サービスをVPNに供給するSPがいつもユニークなRDを作成できるのを確実にするためにこの構造をRDsに与えます。
Rosen & Rekhter Standards Track [Page 13] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[13ページ]。
needs to do so. However, the structure is not meaningful to BGP; when BGP compares two such address prefixes, it ignores the structure entirely.
そうするのが必要です。 しかしながら、構造はBGPに重要ではありません。 BGPがそのような2つのアドレス接頭語を比較するとき、それは構造を完全に無視します。
A PE needs to be configured such that routes that lead to a particular CE become associated with a particular RD. The configuration may cause all routes leading to the same CE to be associated with the same RD, or it may cause different routes to be associated with different RDs, even if they lead to the same CE.
PEが、構成される必要があるので、特定のCEに通じるルートが特定のRDに関連するようになります。 構成が、同じCEに通じるすべてのルートが同じRDに関連していることを引き起こすかもしれませんか、または異なったルートが異なったRDsに関連していることを引き起こすかもしれません、彼らが同じCEに通じても。
4.2. Encoding of Route Distinguishers
4.2. ルートDistinguishersのコード化
As stated, a VPN-IPv4 address consists of an 8-byte Route Distinguisher followed by a 4-byte IPv4 address. The RDs are encoded as follows:
述べられているように、VPN-IPv4アドレスは4バイトのIPv4アドレスがあとに続いた8バイトのRoute Distinguisherから成ります。 RDsは以下の通りコード化されます:
- Type Field: 2 bytes
- Value Field: 6 bytes
- 分野をタイプしてください: 2バイト--Fieldを評価してください: 6バイト
The interpretation of the Value field depends on the value of the type field. At the present time, three values of the type field are defined: 0, 1, and 2.
Value分野の解釈はタイプ分野の値に依存します。 現在では、タイプ分野の3つの値が定義されます: 0、1、および2。
- Type 0: The Value field consists of two subfields:
- 0はタイプします: Value分野は2つの部分体から成ります:
* Administrator subfield: 2 bytes
* Assigned Number subfield: 4 bytes
* 管理者部分体: 2バイト*はNumber部分体を割り当てました: 4バイト
The Administrator subfield must contain an Autonomous System
number. If this ASN is from the public ASN space, it must have
been assigned by the appropriate authority (use of ASN values
from the private ASN space is strongly discouraged). The
Assigned Number subfield contains a number from a numbering space
that is administered by the enterprise to which the ASN has been
assigned by an appropriate authority.
Administrator部分体はAutonomous System番号を含まなければなりません。 このASNが公共のASNスペースから来ているなら、それは適切な権威によって割り当てられたに違いありません(個人的なASNスペースからのASN値の使用は強くお勧めできないです)。 Assigned Number部分体はASNが適切な権威によって配属された企業によって管理される付番スペースからの数を含んでいます。
- Type 1: The Value field consists of two subfields:
- タイプ1: Value分野は2つの部分体から成ります:
* Administrator subfield: 4 bytes
* Assigned Number subfield: 2 bytes
* 管理者部分体: 4バイト*はNumber部分体を割り当てました: 2バイト
The Administrator subfield must contain an IP address. If this
IP address is from the public IP address space, it must have been
assigned by an appropriate authority (use of addresses from the
private IP address space is strongly discouraged). The Assigned
Number subfield contains a number from a numbering space which is
administered by the enterprise to which the IP address has been
assigned.
Administrator部分体はIPアドレスを含まなければなりません。 このIPアドレスが公共のIPアドレス空間から来ているなら、それは適切な権威によって割り当てられたに違いありません(プライベートアイピーアドレス空間からのアドレスの使用は強くお勧めできないです)。 Assigned Number部分体はIPアドレスが配属された企業によって管理される付番スペースからの数を含んでいます。
Rosen & Rekhter Standards Track [Page 14] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[14ページ]。
- Type 2: The Value field consists of two subfields:
- 2はタイプします: Value分野は2つの部分体から成ります:
* Administrator subfield: 4 bytes
* Assigned Number subfield: 2 bytes
* 管理者部分体: 4バイト*はNumber部分体を割り当てました: 2バイト
The Administrator subfield must contain a 4-byte Autonomous
System number [BGP-AS4]. If this ASN is from the public ASN
space, it must have been assigned by the appropriate authority
(use of ASN values from the private ASN space is strongly
discouraged). The Assigned Number subfield contains a number
from a numbering space which is administered by the enterprise to
which the ASN has been assigned by an appropriate authority.
Administrator部分体は4バイトのAutonomous System番号[BGP-AS4]を含まなければなりません。 このASNが公共のASNスペースから来ているなら、それは適切な権威によって割り当てられたに違いありません(個人的なASNスペースからのASN値の使用は強くお勧めできないです)。 Assigned Number部分体はASNが適切な権威によって配属された企業によって管理される付番スペースからの数を含んでいます。
4.3. Controlling Route Distribution
4.3. ルート分配を制御します。
In this section, we discuss the way in which the distribution of the VPN-IPv4 routes is controlled.
このセクションで、私たちはVPN-IPv4ルートの分配が制御されている方法について議論します。
If a PE router is attached to a particular VPN (by being attached to a particular CE in that VPN), it learns some of that VPN's IP routes from the attached CE router. Routes learned from a CE routing peer over a particular attachment circuit may be installed in the VRF associated with that attachment circuit. Exactly which routes are installed in this manner is determined by the way in which the PE learns routes from the CE. In particular, when the PE and CE are routing protocol peers, this is determined by the decision process of the routing protocol; this is discussed in Section 7.
PEルータが特定のVPN(そのVPNの特定のCEに付けられているのによる)に付けられるなら、それは付属CEルータからそのVPNのいくつかのIPルートを学びます。 特定の付属サーキットの上のCEルーティング同輩から学習されたルートはその付属サーキットに関連しているVRFにインストールされるかもしれません。 まさにどのルートがインストールされるかはこの様にPEがCEからルートを学ぶ方法で決定します。 PEとCEがルーティング・プロトコル同輩であるときに、特に、これはルーティング・プロトコルの決定の過程で決定します。 セクション7でこれについて議論します。
These routes are then converted to VPN-IP4 routes, and "exported" to BGP. If there is more than one route to a particular VPN-IP4 address prefix, BGP chooses the "best" one, using the BGP decision process. That route is then distributed by BGP to the set of other PEs that need to know about it. At these other PEs, BGP will again choose the best route for a particular VPN-IP4 address prefix. Then the chosen VPN-IP4 routes are converted back into IP routes, and "imported" into one or more VRFs. Whether they are actually installed in the VRFs depends on the decision process of the routing method used between the PE and those CEs that are associated with the VRF in question. Finally, any route installed in a VRF may be distributed to the associated CE routers.
これらのルートは、次に、VPN-IP4ルートに変換されて、BGPに「輸出されます」。 特定のVPN-IP4アドレス接頭語への1つ以上のルートがあれば、BGPは1つを「最もよく」選びます、BGP決定の過程を使用して。 そして、そのルートはBGPによってそれに関して知る必要がある他のPEsのセットに分配されます。 これらの他のPEsでは、BGPは再び特定のVPN-IP4アドレス接頭語のための最も良いルートを選ぶでしょう。 次に、選ばれたVPN-IP4ルートは、IPルートに変換し返されて、1VRFsに「輸入されます」。 それらが実際にVRFsにインストールされるかどうかがVRFがはっきりしていなく関連しているPEとそれらのCEsの間で使用されるルーティング方式の決定の過程に依存します。 最終的に、VRFにインストールされたどんなルートも関連CEルータに分配されるかもしれません。
4.3.1. The Route Target Attribute
4.3.1. ルート目標属性
Every VRF is associated with one or more Route Target (RT) attributes.
あらゆるVRFが1Route Target(RT)の属性に関連しています。
When a VPN-IPv4 route is created (from an IPv4 route that the PE has learned from a CE) by a PE router, it is associated with one or more
VPN-IPv4ルートがPEルータによって作成されるとき(PEがCEから学んだIPv4ルートから)、それは1つ以上に関連しています。
Rosen & Rekhter Standards Track [Page 15] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[15ページ]。
Route Target attributes. These are carried in BGP as attributes of the route.
Target属性を発送してください。 これらはルートの属性としてBGPで運ばれます。
Any route associated with Route Target T must be distributed to every PE router that has a VRF associated with Route Target T. When such a route is received by a PE router, it is eligible to be installed in those of the PE's VRFs that are associated with Route Target T. (Whether it actually gets installed depends upon the outcome of the BGP decision process, and upon the outcome of the decision process of the IGP (i.e., the intra-domain routing protocol) running on the PE/CE interface.)
Route Target Tに関連しているどんなルートもRoute Target T.Whenに関連しているVRFを持っているあらゆるPEルータに分配されて、PEルータでそのようなルートを受け取るということであるに違いない、それはPEのRoute Target Tに関連しているVRFsのものにインストールされる資格があります。(それが実際にインストールされるかどうかをBGP決定の過程の結果、IGP(すなわち、イントラドメインルーティング・プロトコル)がPE/CEインタフェースで走る決定の過程の結果に依存します。)
A Route Target attribute can be thought of as identifying a set of sites. (Though it would be more precise to think of it as identifying a set of VRFs.) Associating a particular Route Target attribute with a route allows that route to be placed in the VRFs that are used for routing traffic that is received from the corresponding sites.
1セットのサイトを特定するとRoute Target属性を考えることができます。 (VRFsの1セットを特定するとそれを考えるのが、より正確でしょうが。) 特定のRoute Target属性をルートに関連づけるのは、そのルートが対応するサイトから受けられるルーティング交通に使用されるVRFsに置かれるのを許容します。
There is a set of Route Targets that a PE router attaches to a route received from site S; these may be called the "Export Targets". And there is a set of Route Targets that a PE router uses to determine whether a route received from another PE router could be placed in the VRF associated with site S; these may be called the "Import Targets". The two sets are distinct, and need not be the same. Note that a particular VPN-IPv4 route is only eligible for installation in a particular VRF if there is some Route Target that is both one of the route's Route Targets and one of the VRF's Import Targets.
PEルータがサイトSから受け取られたルートに取り付けるRoute Targetsの1セットがあります。 これらは「輸出目標」と呼ばれるかもしれません。 そして、PEルータが別のPEルータから受け取られたルートはサイトSに関連しているVRFに置くことができたかどうか決定するのに使用するRoute Targetsの1セットがあります。 これらは「輸入目標」と呼ばれるかもしれません。 2セットは、異なって、同じである必要はありません。 ルートのRoute Targetsの1つとVRFのImport Targetsの1つの両方であるいくらかのRoute Targetがあれば、特定のVRFのインストールによって特定のVPN-IPv4ルートが適任であるだけであることに注意してください。
The function performed by the Route Target attribute is similar to that performed by the BGP Communities attribute. However, the format of the latter is inadequate for present purposes, since it allows only a 2-byte numbering space. It is desirable to structure the format, similar to what we have described for RDs (see Section 4.2), so that a type field defines the length of an administrator field, and the remainder of the attribute is a number from the specified administrator's numbering space. This can be done using BGP Extended Communities. The Route Targets discussed herein are encoded as BGP Extended Community Route Targets [BGP-EXTCOMM]. They are structured similarly to the RDs.
Route Target属性によって実行された機能はBGP Communities属性によって実行されたそれと同様です。 しかしながら、2バイトの付番スペースだけを許容するので、後者の形式は現在の目的に不十分です。 形式を構造化するのは望ましいです、私たちがRDsのために説明したことと同様です(セクション4.2を見てください)、タイプ分野が管理者分野の長さを定義して、属性の残りが指定されたアドミニストレータの付番スペースからの数であるように。 これはBGP Extended Communitiesを使用し終わることができます。 ここに議論したRoute TargetsはBGP Extended Community Route Targets[BGP-EXTCOMM]としてコード化されます。 それらは同様にRDsに構造化されます。
When a BGP speaker has received more than one route to the same VPN- IPv4 prefix, the BGP rules for route preference are used to choose which VPN-IPv4 route is installed by BGP.
BGPスピーカーが同じVPN- IPv4接頭語に1つ以上のルートを受け取ったとき、ルート好みのためのBGP規則は、どのVPN-IPv4ルートがBGPによってインストールされるかを選ぶのに使用されます。
Note that a route can only have one RD, but it can have multiple Route Targets. In BGP, scalability is improved if one has a single route with multiple attributes, as opposed to multiple routes. One
ルートが1RDしか持つことができませんが、複数のRoute Targetsを持つことができることに注意してください。 BGPでは、複数のルートと対照的に1つに複数の属性があるただ一つのルートがあるなら、スケーラビリティは改良されています。 1つ
Rosen & Rekhter Standards Track [Page 16] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[16ページ]。
could eliminate the Route Target attribute by creating more routes (i.e., using more RDs), but the scaling properties would be less favorable.
より多くのルート(すなわち、より多くのRDsを使用する)を作成することによってRoute Target属性を排除するかもしれませんが、スケーリング特性はそれほど好ましくないでしょう。
How does a PE determine which Route Target attributes to associate with a given route? There are a number of different possible ways. The PE might be configured to associate all routes that lead to a specified site with a specified Route Target. Or the PE might be configured to associate certain routes leading to a specified site with one Route Target, and certain with another.
PEは、どのRoute Target属性を与えられたルートに関連づけたらよいかをどのように決定しますか? 多くの異なった可能な道があります。 PEは、指定されたサイトにつながるすべてのルートを指定されたRoute Targetに関連づけるために構成されるかもしれません。 または、PEは1Route Targetによって指定されたサイトにつながる副ある一定のルートに構成されていて、別のものと共に確かであるかもしれません。
If the PE and the CE are themselves BGP peers (see Section 7), then the SP may allow the customer, within limits, to specify how its routes are to be distributed. The SP and the customer would need to agree in advance on the set of RTs that are allowed to be attached to the customer's VPN routes. The CE could then attach one or more of those RTs to each IP route that it distributes to the PE. This gives the customer the freedom to specify in real time, within agreed-upon limits, its route distribution policies. If the CE is allowed to attach RTs to its routes, the PE MUST filter out all routes that contain RTs that the customer is not allowed to use. If the CE is not allowed to attach RTs to its routes, but does so anyway, the PE MUST remove the RT before converting the customer's route to a VPN- IPv4 route.
その方法を指定するために、ルートはPEとCEが自分たちでBGP同輩(セクション7を見てください)であるなら、SPは顧客を許容するかもしれません、限界の中で分配されていることです。 SPと顧客は、あらかじめ顧客のVPNルートに付けることができるRTsのセットに同意する必要があるでしょう。 そして、CEはそれがPEに分配するそれぞれのIPルートにそれらのRTsの1つ以上を付けることができました。 これはリアルタイムで同意している限界の中でルート流通政策を指定する自由を顧客に与えます。 CEがRTsをルートに取り付けることができるなら、PE MUSTは顧客が使用できないRTsを含むすべてのルートを無視します。 CEがRTsをルートに取り付けるのは許容されていませんが、そうとにかくするなら、顧客のルートをVPN- IPv4ルートに変換する前に、PE MUSTはRTを取り外します。
4.3.2. Route Distribution Among PEs by BGP
4.3.2. BGPによるPEsの中のルート分配
If two sites of a VPN attach to PEs that are in the same Autonomous System, the PEs can distribute VPN-IPv4 routes to each other by means of an IBGP connection between them. (The term "IBGP" refers to the set of protocols and procedures used when there is a BGP connection between two BGP speakers in the same Autonomous System. This is distinguished from "EBGP", the set of procedures used between two BGP speakers in different Autonomous Systems.) Alternatively, each can have an IBGP connection to a route reflector [BGP-RR].
VPNの2つのサイトが同じAutonomous SystemにあるPEsに付くなら、PEsはそれらの間のIBGP接続によってVPN-IPv4ルートを互いに分配できます。 ("IBGP"という用語は同じ自律システムの2人のBGPスピーカーの間にBGP接続があるとき用いられたプロトコルと手順のセットについて言及します。 これは"EBGP"、異なった自律システムの2人のBGPスピーカーの間で用いられた手順のセットと区別されます。) あるいはまた、それぞれがルート反射鏡[BGP-RR]にIBGP接続を持つことができます。
When a PE router distributes a VPN-IPv4 route via BGP, it uses its own address as the "BGP next hop". This address is encoded as a VPN-IPv4 address with an RD of 0. ([BGP-MP] requires that the next hop address be in the same address family as the Network Layer Reachability Information (NLRI).) It also assigns and distributes an MPLS label. (Essentially, PE routers distribute not VPN-IPv4 routes, but Labeled VPN-IPv4 routes. Cf. [MPLS-BGP].) When the PE processes a received packet that has this label at the top of the stack, the PE will pop the stack, and process the packet appropriately.
PEルータがBGPを通してVPN-IPv4ルートを分配するとき、それは「BGP次ホップ」としてそれ自身のアドレスを使用します。 このアドレスは0のRDと共にVPN-IPv4アドレスとしてコード化されます。 ([BGP-MP]は、Network Layer Reachability情報(NLRI)と同じアドレス家族には次のホップアドレスがあるのを必要とします。) また、それは、MPLSラベルを割り当てて、分配します。 (本質的には、PEルータはVPN-IPv4ルートではなく、Labeled VPN-IPv4ルートを分配します。 Cf。 [MPLS-BGP。]) PEがスタックの先端にこのラベルを持っている容認されたパケットを処理するとき、PEはスタックを飛び出させて、適切にパケットを処理するでしょう。
Rosen & Rekhter Standards Track [Page 17] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[17ページ]。
The PE may distribute the exact set of routes that appears in the VRF, or it may perform summarization and distribute aggregates of those routes, or it may do some of one and some of the other.
PEがVRFに現れる正確なセットのルートを分配するかもしれませんか、総括を実行して、それらのルートの集合を分配するかもしれませんか、またはそれは1のいくつかと何らかのもう片方をするかもしれません。
Suppose that a PE has assigned label L to route R, and has distributed this label mapping via BGP. If R is an aggregate of a set of routes in the VRF, the PE will know that packets from the backbone that arrive with this label must have their destination addresses looked up in a VRF. When the PE looks up the label in its Label Information Base, it learns which VRF must be used. On the other hand, if R is not an aggregate, then when the PE looks up the label, it learns the egress attachment circuit, as well as the encapsulation header for the packet. In this case, no lookup in the VRF is done.
PEがRを発送するためにラベルLを割り当てて、BGPを通してこのラベルマッピングを分配したと仮定してください。 RがVRFの1セットのルートの集合であるなら、PEは、背骨からのこのラベルと共に到着するパケットがVRFで調べられたそれらの送付先住所を知っていなければならないのを知るでしょう。 PEがLabel Information基地の中でラベルを見上げると、それは、どのVRFを使用しなければならないかを学びます。 他方では、PEがラベルを見上げて、Rが集合でないなら出口付属サーキットを学びます、パケットのためのカプセル化ヘッダーと同様に。 この場合、VRFのルックアップを全くしません。
We would expect that the most common case would be the case where the route is NOT an aggregate. The case where it is an aggregate can be very useful though if the VRF contains a large number of host routes (e.g., as in dial-in), or if the VRF has an associated Local Area Network (LAN) interface (where there is a different outgoing layer 2 header for each system on the LAN, but a route is not distributed for each such system).
私たちは、最も一般的なケースがルートが集合でないケースであると予想するでしょう。 もっとも、VRFが多くのホストルートを含んでいるか(例えば、ダイヤルインのように)、またはVRFに関連ローカル・エリア・ネットワーク(LAN)インタフェースがあるなら、それが集合であるケースは非常に役に立つ場合があります(異なった出発している層があるところでは、LANの各システムのための2ヘッダー、しかし、ルートはそのような各システムのために分配されません)。
Whether or not each route has a distinct label is an implementation matter. There are a number of possible algorithms one could use to determine whether two routes get assigned the same label:
各ルートには異なったラベルがあるかどうかが、実現問題です。 1つが2つのルートが同じラベルが割り当てられるようになるかどうか決定するのに使用できた多くの可能なアルゴリズムがあります:
- One may choose to have a single label for an entire VRF, so that
a single label is shared by all the routes from that VRF. Then
when the egress PE receives a packet with that label, it must
look up the packet's IP destination address in that VRF (the
packet's "egress VRF"), in order to determine the packet's egress
attachment circuit and the corresponding data link encapsulation.
- 全体のVRFに、単一のラベルを持っているのを選ぶかもしれません、単一のラベルがそのVRFからすべてのルートで共有されるように。 次に、出口PEがそのラベルでパケットを受けるとき、そのVRF(パケット「出口VRF」)のパケットの受信者IPアドレスを調べなければなりません、パケットの出口付属サーキットと対応するデータ・リンクカプセル化を決定するために。
- One may choose to have a single label for each attachment
circuit, so that a single label is shared by all the routes with
the same "outgoing attachment circuit". This enables one to
avoid doing a lookup in the egress VRF, though some sort of
lookup may need to be done in order to determine the data link
encapsulation, e.g., an Address Resolution Protocol (ARP) lookup.
- それぞれの付属サーキットへの単一のラベルを持っているのを選ぶかもしれません、単一のラベルがすべてのルートで同じ「出発している付属サーキット」と共有されるように。 これは、1つが、出口VRFでルックアップをするのを避けるのを可能にします、ある種のルックアップが、データ・リンクカプセル化を決定するためにする必要があるかもしれませんが、例えば、Address Resolutionプロトコル(ARP)ルックアップ。
- One may choose to have a distinct label for each route. Then if
a route is potentially reachable over more than one attachment
circuit, the PE/CE routing can switch the preferred path for a
route from one attachment circuit to another, without there being
any need to distribute new a label for that route.
- 各ルートへの異なったラベルを持っているのを選ぶかもしれません。 そこがなければ、次に、ルートが1個以上の付属サーキットの上に潜在的に届くなら、PE/CEルーティングはある付属サーキットから別のサーキットまで都合のよい経路をルートに切り換えることができて、いずれでもあること、そのルートにラベルを新しく分配する必要があります。
Rosen & Rekhter Standards Track [Page 18] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[18ページ]。
There may be other possible algorithms as well. The choice of algorithm is entirely at the discretion of the egress PE, and is otherwise transparent.
また、他の可能なアルゴリズムがあるかもしれません。 完全に出口PEの裁量には、あります。そうでなければ、アルゴリズムの選択は、わかりやすいです。
In using BGP-distributed MPLS labels in this manner, we presuppose that an MPLS packet carrying such a label can be tunneled from the router that installs the corresponding BGP-distributed route to the router that is the BGP next hop of that route. This requires either that a label switched path exist between those two routers or else that some other tunneling technology (e.g., [MPLS-in-IP-GRE]) can be used between them.
この様にBGPによって分配されたMPLSラベルを使用する際に、私たちは、対応するBGPによって分配されたルートをインストールするルータから次のそのホップが発送するBGPであるルータまでそのようなラベルを運ぶMPLSパケットにトンネルを堀ることができるのを予想します。 これは、ラベルの切り換えられた経路がそれらの2つのルータの間に存在しているか、または彼らの間である他のトンネリング技術(例えば、[IP GREのMPLS])は使用できるのを必要とします。
This tunnel may follow a "best effort" route, or it may follow a traffic-engineered route. Between a given pair of routers, there may be one such tunnel, or there may be several, perhaps with different Quality of Service (QoS) characteristics. All that matters for the VPN architecture is that some such tunnel exists. To ensure interoperability among systems that implement this VPN architecture using MPLS label switched paths as the tunneling technology, all such systems MUST support Label Distribution Protocol (LDP) [MPLS-LDP]. In particular, Downstream Unsolicited mode MUST be supported on interfaces that are neither Label Controlled ATM (LC-ATM) [MPLS-ATM] nor Label Controlled Frame Relay (LC-FR) [MPLS-FR] interfaces, and Downstream on Demand mode MUST be supported on LC-ATM interfaces and LC-FR interfaces.
このトンネルは「ベストエフォート型」のルートに従うかもしれませんか、またはそれが交通で設計されたルートに従うかもしれません。 与えられた組のルータの間に、そのようなトンネルの1つがあるかもしれませんか、または数個があるかもしれません、恐らくService(QoS)の特性の異なったQualityと共に。 VPN構造のために重要なすべてはそのようなあるトンネルが存在しているということです。 MPLSラベルを使用することでこのVPN構造を実行するシステムの中の相互運用性がトンネリング技術として経路を切り換えたのを保証するために、そのようなすべてのシステムがLabel Distributionプロトコル(自由民主党)[MPLS-自由民主党]をサポートしなければなりません。 特に、Label Controlled ATM(LC-ATM)[MPLS-ATM]でなくてまたLabel Controlled Frame Relay(LC-フラン)[MPLS-FR]インタフェースでないインタフェースで、Downstream Unsolicitedモードを支持しなければなりません、そして、LC-ATMインタフェースとLC-FRインタフェースでDemandモードのDownstreamを支持しなければなりません。
If the tunnel follows a best-effort route, then the PE finds the route to the remote endpoint by looking up its IP address in the default forwarding table.
トンネルがベストエフォート型ルートに従うなら、PEは、デフォルト推進テーブルでIPアドレスを調べることによって、遠く離れた終点にルートを見つけます。
A PE router, UNLESS it is a route reflector (see Section 4.3.3) or an Autonomous System Border Router (ASBR) for an inter-provider VPN (see Section 10), should not install a VPN-IPv4 route unless it has at least one VRF with an Import Target identical to one of the route's Route Target attributes. Inbound filtering should be used to cause such routes to be discarded. If a new Import Target is later added to one of the PE's VRFs (a "VPN Join" operation), it must then acquire the routes it may previously have discarded. This can be done using the refresh mechanism described in [BGP-RFSH]. The outbound route filtering mechanism of [BGP-ORF] can also be used to advantage to make the filtering more dynamic.
PEルータ、UNLESS、それは、ルート反射鏡(セクション4.3.3を見る)か相互プロバイダーVPNのためのAutonomous System Border Router(ASBR)(セクション10を見る)であり、ルートのRoute Target属性の1つと同じImport Targetと少なくとも1VRFを持っていない場合、VPN-IPv4ルートをインストールするべきではありません。 本国行きのフィルタリングは、そのようなルートが捨てられることを引き起こすのに使用されるべきです。 新しいImport Targetが後でPEのVRFs(「VPNは接合する」という操作)の1つに加えられるなら、それは以前に捨てたかもしれないルートを入手しなければなりません。 これに使用できる、[BGP-RFSH]で説明されたメカニズムをリフレッシュしてください。 また、[BGP-ORF]の外国行きのルートフィルタリングメカニズムをフィルタリングをよりダイナミックにする利点に使用できます。
Similarly, if a particular Import Target is no longer present in any of a PE's VRFs (as a result of one or more "VPN Prune" operations), the PE may discard all routes that, as a result, no longer have any of the PE's VRF's Import Targets as one of their Route Target attributes.
同様に、特定のImport TargetがもうPEのVRFs(1つ以上の「VPNプルーン」操作の結果、)のいずれにも存在していないなら、PEはもう彼らのRoute Target属性の1つとしてその結果PEのVRFのImport Targetsのいずれも持っていないすべてのルートを捨てるかもしれません。
Rosen & Rekhter Standards Track [Page 19] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[19ページ]。
A router that is not attached to any VPN and that is not a Route Reflector (i.e., a P router) never installs any VPN-IPv4 routes at all.
どんなVPNにも付けられていなくて、またRoute Reflector(すなわち、Pルータ)でないルータは全くどんなVPN-IPv4ルートも決してインストールしません。
Note that VPN Join and Prune operations are non-disruptive and do not require any BGP connections to be brought down, as long as the refresh mechanism of [BGP-RFSH] is used.
VPN JoinとPrune操作が、非破壊的であり、どんなBGP接続も落ち込むのを必要としないことに注意してください、同じくらい長い、使用される[BGP-RFSH]のメカニズムをリフレッシュしてください。
As a result of these distribution rules, no one PE ever needs to maintain all routes for all VPNs; this is an important scalability consideration.
これらの分配規則の結果、いいえ1、PEは、すべてのVPNsのためにすべてのルートを維持する必要があります。 これは重要なスケーラビリティ考慮すべき事柄です。
4.3.3. Use of Route Reflectors
4.3.3. ルート反射鏡の使用
Rather than having a complete IBGP mesh among the PEs, it is advantageous to make use of BGP Route Reflectors [BGP-RR] to improve scalability. All the usual techniques for using route reflectors to improve scalability (e.g., route reflector hierarchies) are available.
PEsの中に完全なIBGPメッシュを持っているよりむしろ、スケーラビリティを改良するのに、BGP Route Reflectors[BGP-RR]を利用するのは有利です。 スケーラビリティ(例えば、ルート反射鏡階層構造)を改良するのにルート反射鏡を使用するためのすべての普通のテクニックが利用可能です。
Route reflectors are the only systems that need to have routing information for VPNs to which they are not directly attached. However, there is no need to have any one route reflector know all the VPN-IPv4 routes for all the VPNs supported by the backbone.
ルート反射鏡は彼らが直接付けられていないVPNsのためのルーティング情報を必要とする唯一のシステムです。 しかしながら、どんなルート反射鏡にも背骨によって支持されたすべてのVPNsですべてのVPN-IPv4ルートを知らせる必要は全くありません。
We outline below two different ways to partition the set of VPN-IPv4 routes among a set of route reflectors.
私たちは1セットのルート反射鏡の中でVPN-IPv4ルートのセットを仕切る2つ未満の異なった方法を概説します。
1. Each route reflector is preconfigured with a list of Route
Targets. For redundancy, more than one route reflector may be
preconfigured with the same list. A route reflector uses the
preconfigured list of Route Targets to construct its inbound
route filtering. The route reflector may use the techniques of
[BGP-ORF] to install on each of its peers (regardless of
whether the peer is another route reflector or a PE) the set of
Outbound Route Filters (ORFs) that contains the list of its
preconfigured Route Targets. Note that route reflectors should
accept ORFs from other route reflectors, which means that route
reflectors should advertise the ORF capability to other route
reflectors.
1. それぞれのルート反射鏡はRoute Targetsのリストであらかじめ設定されます。 冗長に関しては、1個以上のルート反射鏡が同じリストであらかじめ設定されるかもしれません。 ルート反射鏡は、本国行きのルートフィルタリングを構成するのにRoute Targetsのあらかじめ設定されたリストを使用します。 ルート反射鏡は、同輩各人(同輩が別のルート反射鏡かPEであることにかかわらず)の上にあらかじめ設定されたRoute Targetsのリストを含むOutbound Route Filters(ORFs)のセットをインストールするのに[BGP-ORF]のテクニックを使用するかもしれません。 ルート反射鏡が他のルート反射鏡からのORFsを受け入れるはずであることに注意してください。(ORFsは、ルート反射鏡が他のルート反射鏡へのORF能力の広告を出すはずであることを意味します)。
A service provider may modify the list of preconfigured Route
Targets on a route reflector. When this is done, the route
reflector modifies the ORFs it installs on all of its IBGP
peers. To reduce the frequency of configuration changes on
route reflectors, each route reflector may be preconfigured
with a block of Route Targets. This way, when a new Route
Target is needed for a new VPN, there is already one or more
サービスプロバイダーはルート反射鏡であらかじめ設定されたRoute Targetsのリストを変更するかもしれません。 これが完了していると、ルート反射鏡はそれがIBGP同輩のすべてにインストールするORFsを変更します。 ルート反射鏡で構成変更の頻度を減少させるために、それぞれのルート反射鏡はRoute Targetsの1ブロックであらかじめ設定されるかもしれません。 新しいRoute Targetが新しいVPNに必要であるときに、このように、1つ以上が既にあります。
Rosen & Rekhter Standards Track [Page 20] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[20ページ]。
route reflectors that are (pre)configured with this Route
Target.
反射鏡を発送してください、(前、)、このRoute Targetで、構成されています。
Unless a given PE is a client of all route reflectors, when a
new VPN is added to the PE ("VPN Join"), it will need to become
a client of the route reflector(s) that maintain routes for
that VPN. Likewise, deleting an existing VPN from the PE ("VPN
Prune") may result in a situation where the PE no longer needs
to be a client of some route reflector(s). In either case, the
Join or Prune operation is non-disruptive (as long as
[BGP-RFSH] is used, and never requires a BGP connection to be
brought down, only to be brought right back up.
新しいVPNがPEに加えられるとき、与えられたPEがすべてのルート反射鏡のクライアント(「VPNは接合する」)でないなら、それは、そのVPNのためにルートを維持するルート反射鏡のクライアントになる必要があるでしょう。 同様に、PE(「VPNプルーン」)から既存のVPNを削除すると、PEがもうあるルート反射鏡のクライアントである必要がない状況はもたらされるかもしれません。 どちらかのケース、JoinまたはPruneでは、操作は非破壊的です。([BGP-RFSH]が使用されて、BGP接続がちょうど前に落ち込んで、単に育つのを決して必要としない限り。
(By "adding a new VPN to a PE", we really mean adding a new
import Route Target to one of its VRFs, or adding a new VRF
with an import Route Target not had by any of the PE's other
VRFs.)
(「新しいVPNをPEに加えます」で、私たちは、新しい輸入Route TargetをVRFsの1つに加えるか、またはRoute TargetがPEの他のVRFsのいずれでも持っていなかった輸入で新しいVRFを加えると本当に言っています。)
2. Another method is to have each PE be a client of some subset of
the route reflectors. A route reflector is not preconfigured
with the list of Route Targets, and does not perform inbound
route filtering of routes received from its clients (PEs);
rather, it accepts all the routes received from all of its
clients (PEs). The route reflector keeps track of the set of
the Route Targets carried by all the routes it receives. When
the route reflector receives from its client a route with a
Route Target that is not in this set, this Route Target is
immediately added to the set. On the other hand, when the
route reflector no longer has any routes with a particular
Route Target that is in the set, the route reflector should
delay (by a few hours) the deletion of this Route Target from
the set.
2. 別の方法は各PEがルート反射鏡の何らかの部分集合のクライアントであることを持つことです。 ルート反射鏡は、Route Targetsのリストであらかじめ設定されないで、またクライアント(PEs)から受け取られたルートの本国行きのルートフィルタリングを実行しません。 むしろ、それはクライアント(PEs)のすべてから受け取られたすべてのルートを受け入れます。 ルート反射鏡はそれが受けるすべてのルートで運ばれたRoute Targetsのセットの動向をおさえます。 ルート反射鏡がすぐにこのセットにないRoute Targetと共にクライアントからルートを受けるとき、このRoute Targetはセットに追加されます。 他方では、ルート反射鏡にセットにある特定のRoute Targetがあるどんなルートももうないとき、ルート反射鏡はセットからこのRoute Targetの削除を遅らせるはずです(数時間までに)。
The route reflector uses this set to form the inbound route
filters that it applies to routes received from other route
reflectors. The route reflector may also use ORFs to install
the appropriate outbound route filtering on other route
reflectors. Just like with the first approach, a route
reflector should accept ORFs from other route reflectors. To
accomplish this, a route reflector advertises ORF capability to
other route reflectors.
ルート反射鏡は、それが他のルート反射鏡から受け取られたルートに適用する本国行きのルートフィルタを形成するのにこのセットを使用します。 また、ルート反射鏡は、他のルートの上で反射鏡をフィルターにかける適切な外国行きのルートをインストールするのにORFsを使用するかもしれません。 アプローチ、ルート反射鏡がまさしく1番目で受け入れるべきであるように、他のルート反射鏡からORFsを受け入れてください。 これを達成するために、ルート反射鏡は他のルート反射鏡へのORF能力の広告を出します。
When the route reflector changes the set, it should immediately
change its inbound route filtering. In addition, if the route
reflector uses ORFs, then the ORFs have to be immediately
changed to reflect the changes in the set. If the route
reflector doesn't use ORFs, and a new Route Target is added to
ルート反射鏡がすぐにセットを変えるとき、それは本国行きのルートフィルタリングを変えるべきです。 さらに、ルート反射鏡がORFsを使用するなら、すぐに、セットにおける変化を反映するためにORFsを変えなければなりません。 ルート反射鏡がORFsを使用しないで、新しいRoute Targetに加えられるなら
Rosen & Rekhter Standards Track [Page 21] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[21ページ]。
the set, the route reflector, after changing its inbound route
filtering, must issue BGP Refresh to other route reflectors.
セット(本国行きのルートフィルタリングを変えた後のルート反射鏡)は他のルート反射鏡にBGP Refreshを発行しなければなりません。
The delay of "a few hours" mentioned above allows a route
reflector to hold onto routes with a given RT, even after it
loses the last of its clients that are interested in such
routes. This protects against the need to reacquire all such
routes if the clients' "disappearance" is only temporary.
ルート反射鏡は前記のように「数時間」の遅れで与えられたRTがあるルートを頼りにすることができます、そのようなルートに興味を持っているクライアントの最終を失った後にさえ。 クライアントの「消滅」が一時的であるだけであるなら、これはすべてのそのようなものが発送するreacquireに必要性から守ります。
With this procedure, VPN Join and Prune operations are also
non-disruptive.
また、この手順で、VPN JoinとPrune操作も非破壊的です。
Note that this technique will not work properly if some client
PE has a VRF with an import Route Target that is not one of its
export Route Targets.
いくらかのクライアントPEに輸出Route Targetsのひとりでない輸入Route TargetとVRFがあるとこのテクニックが適切に働かないことに注意してください。
In these procedures, a PE router which attaches to a particular VPN "auto-discovers" the other PEs that attach to the same VPN. When a new PE router is added, or when an existing PE router attaches to a new VPN, no reconfiguration of other PE routers is needed.
これらの手順、特定のVPNに付くPEルータ、「自動、発見、」 同じVPNに付く他のPEs。 新しいPEルータが加えられるか、または既存のPEルータが新しいVPNに付くとき、他のPEルータの再構成は全く必要ではありません。
Just as there is no one PE router that needs to know all the VPN-IPv4 routes supported over the backbone, these distribution rules ensure that there is no one Route Reflector (RR) that needs to know all the VPN-IPv4 routes supported over the backbone. As a result, the total number of such routes that can be supported over the backbone is not bounded by the capacity of any single device, and therefore can increase virtually without bound.
ちょうど背骨の上で支えられたすべてのVPN-IPv4ルートを知る必要がある1PEのルータが全くないとき、これらの分配規則は、背骨の上で支えられたすべてのVPN-IPv4ルートを知る必要がある1Route Reflector(RR)が全くないのを確実にします。 その結果、背骨の上で支えることができるそのようなルートの総数はどんな単一の装置の容量に従ってもバウンドしていなくて、したがって、実際にはバウンドなしで増加できるということです。
4.3.4. How VPN-IPv4 NLRI Is Carried in BGP
4.3.4. VPN-IPv4 NLRIはBGPでどう運ばれるか。
The BGP Multiprotocol Extensions [BGP-MP] are used to encode the NLRI. If the Address Family Identifier (AFI) field is set to 1, and the Subsequent Address Family Identifier (SAFI) field is set to 128, the NLRI is an MPLS-labeled VPN-IPv4 address. AFI 1 is used since the network layer protocol associated with the NLRI is still IP. Note that this VPN architecture does not require the capability to distribute unlabeled VPN-IPv4 addresses.
BGP Multiprotocol Extensions[BGP-MP]は、NLRIをコード化するのに使用されます。 Address Family Identifier(AFI)分野が1に設定されて、Subsequent Address Family Identifier(サフィ)分野が128に設定されるなら、NLRIはMPLSによってラベルされたVPN-IPv4アドレスです。 AFI1は、それでも、NLRIに関連しているネットワーク層プロトコルがIPであるので、使用されています。 このVPN構造がラベルされていないVPN-IPv4アドレスを配布する能力を必要としないことに注意してください。
In order for two BGP speakers to exchange labeled VPN-IPv4 NLRI, they must use BGP Capabilities Advertisement to ensure that they both are capable of properly processing such NLRI. This is done as specified in [BGP-MP], by using capability code 1 (multiprotocol BGP), with an AFI of 1 and an SAFI of 128.
交換するVPN-IPv4 NLRIのレッテルを貼られた2人のBGPスピーカーにとって整然とします、彼らは彼らの両方が適切にそのようなNLRIを処理できるのを保証するのにBGP Capabilities Advertisementを使用しなければなりません。 [BGP-MP]で指定されるようにこれをします、能力コード1(multiprotocol BGP)を使用することによって、1のAFIと128のサフィと共に。
The labeled VPN-IPv4 NLRI itself is encoded as specified in [MPLS-BGP], where the prefix consists of an 8-byte RD followed by an IPv4 prefix.
ラベルされたVPN-IPv4 NLRI自身は[MPLS-BGP](接頭語はIPv4接頭語があとに続いた8バイトのRDから成る)で指定されるようにコード化されます。
Rosen & Rekhter Standards Track [Page 22] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[22ページ]。
4.3.5. Building VPNs Using Route Targets
4.3.5. ルート目標を使用することでVPNsを造ります。
By setting up the Import Targets and Export Targets properly, one can construct different kinds of VPNs.
適切にImport TargetsとExport Targetsをセットアップすることによって、1つはVPNsの異種を構成できます。
Suppose it is desired to create a fully meshed closed user group, i.e., a set of sites where each can send traffic directly to the other, but traffic cannot be sent to or received from other sites. Then each site is associated with a VRF, a single Route Target attribute is chosen, that Route Target is assigned to each VRF as both the Import Target and the Export Target, and that Route Target is not assigned to any other VRFs as either the Import Target or the Export Target.
完全にかみ合っているクローズド・ユーザ・グループ(すなわち、それぞれが直接もう片方に交通を送ることができますが、交通を発信できないか、他のサイトから受けることができない1セットのサイト)を創設することが望まれていると仮定してください。 次に、それぞれのサイトはVRFに関連しています、そして、ただ一つのRoute Target属性は選ばれています、そして、そのRoute TargetはImport TargetとExport Targetの両方として各VRFに割り当てられます、そして、そのRoute TargetはImport TargetかExport Targetのどちらかとしていかなる他のVRFsにも割り当てられません。
Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and
あるいはまた、1つが、いかなる理由でもVPNの「ハブとスポーク」種類を作成することを望んでいたと仮定してください。 1意味「ハブ」と1つの意味が、2つのRoute Target値の使用でこれができるだろうと「話しました」。 そして「ハブ」がハブサイトに取り付けられたVRFsではExport Targetである。
"Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target.
「話しだった」はImport Targetです。 スポークサイトに取り付けられたVRFsでは、「ハブ」はImport Targetです、そして、「スポーク」はExport Targetです。
Thus, the methods for controlling the distribution of routing information among various sets of sites are very flexible, which in turn provides great flexibility in constructing VPNs.
したがって、様々なセットのサイトの中でルーティング情報の分配を制御するための方法は非常にフレキシブルです(順番にかなりの柔軟性をVPNsを組み立てるのに提供します)。
4.3.6. Route Distribution Among VRFs in a Single PE
4.3.6. 独身のPEのVRFsの中のルート分配
It is possible to distribute routes from one VRF to another, even if both VRFs are in the same PE, even though in this case one cannot say that the route has been distributed by BGP. Nevertheless, the decision to distribute a particular route from one VRF to another within a single PE is the same decision that would be made if the VRFs were on different PEs. That is, it depends on the Route Target attribute that is assigned to the route (or would be assigned if the route were distributed by BGP), and the import target of the second VRF.
1VRFから別のVRFまでルートを分配するのは可能です、両方のVRFsが同じPEにあっても、人は、この場合ルートがBGPによって分配されたと言うことができませんが。 それにもかかわらず、独身のPEの中で1VRFから別のVRFまで特定のルートを分配するという決定はVRFsが異なったPEsにあるならされる同じ決定です。 すなわち、それはルート(または、ルートがBGPによって分配されるなら、割り当てられる)、および第2VRFの輸入目標に割り当てられるRoute Target属性に依存します。
5. Forwarding
5. 推進
If the intermediate routers in the backbone do not have any information about the routes to the VPNs, how are packets forwarded from one VPN site to another?
背骨の中間的ルータがルートの情報を少しのVPNsに持っていないなら、1つのVPNサイトから別のサイトまでどのようにパケットを進めますか?
When a PE receives an IP packet from a CE device, it chooses a particular VRF in which to look up the packet's destination address. This choice is based on the packet's ingress attachment circuit.
PEがCE装置からIPパケットを受けるとき、それはパケットの送付先アドレスを調べる特定のVRFを選びます。 この選択はパケットのイングレス付属サーキットに基づいています。
Rosen & Rekhter Standards Track [Page 23] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[23ページ]。
Assume that a match is found. As a result we learn the packet's "next hop".
マッチが見つけられると仮定してください。 その結果、私たちはパケットの「次のホップ」を学びます。
If the packet's next hop is reached directly over a VRF attachment circuit from this PE (i.e., the packet's egress attachment circuit is on the same PE as its ingress attachment circuit), then the packet is sent on the egress attachment circuit, and no MPLS labels are pushed onto the packet's label stack.
パケットの次のホップにVRF付属サーキットの直接上にこのPEから達しているなら(すなわち、パケットの出口付属サーキットがイングレス付属サーキットと同じPEにあります)、出口付属サーキットにパケットを送ります、そして、パケットのラベルスタックにMPLSラベルを全く押しません。
If the ingress and egress attachment circuits are on the same PE, but are associated with different VRFs, and if the route that best matches the destination address in the ingress attachment circuit's VRF is an aggregate of several routes in the egress attachment circuit's VRF, it may be necessary to look up the packet's destination address in the egress VRF as well.
イングレスと出口付属サーキットが同じPEにありますが、異なったVRFsに関連していて、イングレス付属サーキットのVRFの送付先アドレスに最もよく合っているルートが出口付属サーキットのVRFの数個のルートの集合であるなら、また、出口VRFのパケットの送付先アドレスを調べるのが必要であるかもしれません。
If the packet's next hop is NOT reached through a VRF attachment circuit, then the packet must travel at least one hop through the backbone. The packet thus has a "BGP Next Hop", and the BGP Next Hop will have assigned an MPLS label for the route that best matches the packet's destination address. Call this label the "VPN route label". The IP packet is turned into an MPLS packet with the VPN route label as the sole label on the label stack.
パケットの次のホップにVRF付属サーキットを通して達していないなら、パケットは背骨を通して少なくともワンバウンドで移動しなければなりません。 パケットには、その結果、「BGP次ホップ」があります、そして、BGP Next Hopはパケットの送付先アドレスに最もよく合っているルートにMPLSラベルを割り当ててしまうでしょう。 このラベルを「VPNルートラベル」と呼んでください。 IPパケットはラベルスタックの上の唯一のラベルとしてのVPNルートラベルがあるMPLSに変わっているパケットです。
The packet must then be tunneled to the BGP Next Hop.
そして、BGP Next Hopにパケットにトンネルを堀らなければなりません。
If the backbone supports MPLS, this is done as follows:
背骨がMPLSを支えるなら、以下の通りこれをします:
- The PE routers (and any Autonomous System border routers) that
redistribute VPN-IPv4 addresses need to insert /32 address
prefixes for themselves into the IGP routing tables of the
backbone. This enables MPLS, at each node in the backbone
network, to assign a label corresponding to the route to each PE
router. To ensure interoperability among different
implementations, it is required to support LDP for setting up the
label switched paths across the backbone. However, other methods
of setting up these label switched paths are also possible.
(Some of these other methods may not require the presence of the
/32 address prefixes in the IGP.)
- VPN-IPv4アドレスを再配付するPEルータ(どんなAutonomous Systemもルータに接している)は自分たちのための背骨のIGP経路指定テーブルへの差し込み/32のアドレス接頭語にそうしなければなりません。 これはMPLSを有効にします、背骨ネットワークにおける各ノードで、それぞれのPEルータへのルートに対応する案配aラベルに。 異なった実現の中で相互運用性を確実にするために、それが背骨の向こう側に切り換えられた経路をラベルに設定するために自由民主党を支持するのに必要です。 しかしながら、また、これらのラベルの切り換えられた経路をセットアップする他の方法も可能です。 (これらの他の方法のいくつかが32アドレスがIGPに前に置く/を存在に要求しないかもしれません。)
- If there are any traffic engineering tunnels to the BGP next hop,
and if one or more of those is available for use by the packet in
question, one of these tunnels is chosen. This tunnel will be
associated with an MPLS label, the "tunnel label". The tunnel
label gets pushed on the MPLS label stack, and the packet is
forwarded to the tunnel's next hop.
- 何か次のBGPへのトンネルが飛び越す交通工学があって、それらの1つ以上が問題のパケットで使用に利用可能であるなら、これらのトンネルの1つは選ばれています。 このトンネルはMPLSラベル、「トンネルラベル」に関連するでしょう。 MPLSラベルスタックにトンネルラベルを押します、そして、トンネルの次のホップにパケットを送ります。
Rosen & Rekhter Standards Track [Page 24] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[24ページ]。
- Otherwise,
- そうでなければ
* The packet will have an "IGP Next Hop", which is the next hop
along the IGP route to the BGP Next Hop.
* パケットは「次のIGPは跳ぶ」という(IGPに沿った次のホップです)ルートをBGP Next Hopに持つでしょう。
* If the BGP Next Hop and the IGP Next Hop are the same, and if
penultimate hop popping is used, the packet is then sent to
the IGP Next Hop, carrying only the VPN route label.
* BGP Next HopとIGP Next Hopが同じであり、終わりから二番目のホップの飛び出しが使用されているなら、パケットをIGP Next Hopに送ります、VPNルートラベルだけを運んで。
* Otherwise, the IGP Next Hop will have assigned a label for
the route that best matches the address of the BGP Next Hop.
Call this the "tunnel label". The tunnel label gets pushed
on as the packet's top label. The packet is then forwarded
to the IGP Next Hop.
* さもなければ、IGP Next HopはBGP Next Hopのアドレスに最もよく合っているルートにラベルを割り当ててしまうでしょう。 「トンネルラベル」にこれに電話をしてください。 トンネルラベルはパケットのトップラベルとして押されます。 そして、パケットをIGP Next Hopに送ります。
- MPLS will then carry the packet across the backbone to the BGP
Next Hop, where the VPN label will be examined.
- そして、MPLSは背骨の向こう側にBGP Next Hopまでパケットを運ぶでしょう。そこでは、VPNラベルが調べられるでしょう。
If the backbone does not support MPLS, the MPLS packet carrying only the VPN route label may be tunneled to the BGP Next Hop using the techniques of [MPLS-in-IP-GRE]. When the packet emerges from the tunnel, it will be at the BGP Next Hop, where the VPN route label will be examined.
背骨がMPLSを支えないなら、[IP GREのMPLS]のテクニックを使用することでVPNルートラベルだけを運ぶMPLSパケットはBGP Next Hopにトンネルを堀られるかもしれません。 パケットがトンネルから現れるとき、それはBGP Next Hopにあるでしょう。そこでは、VPNルートラベルが調べられるでしょう。
At the BGP Next Hop, the treatment of the packet depends on the VPN route label (see Section 4.3.2). In many cases, the PE will be able to determine, from this label, the attachment circuit over which the packet should be transmitted (to a CE device), as well as the proper data link layer header for that interface. In other cases, the PE may only be able to determine that the packet's destination address needs to be looked up in a particular VRF before being forwarded to a CE device. There are also intermediate cases in which the VPN route label may determine the packet's egress attachment circuit, but a lookup (e.g., ARP) still needs to be done in order to determine the packet's data link header on that attachment circuit.
BGP Next Hopでは、パケットの処理はVPNルートラベルによります(セクション4.3.2を見てください)。 多くの場合、PEはこのラベルからパケットが送られるべきである(CE装置に)付属サーキットを決定できるでしょう、そのインタフェースへの適切なデータ・リンク層ヘッダーと同様に。 他の場合では、PEは、パケットの送付先アドレスが、CE装置に送る前に特定のVRFで調べる必要を決定できるだけであるかもしれません。 また、VPNルートラベルがパケットの出口付属サーキットを決定するかもしれない中間的場合がありますが、ルックアップ(例えば、ARP)は、まだその付属サーキットの上のパケットのデータ・リンクヘッダーを決定するためにする必要があります。
Information in the MPLS header itself, and/or information associated with the label, may also be used to provide QoS on the interface to the CE.
また、MPLSヘッダーの情報自体、そして/または、ラベルに関連している情報は、インタフェースでQoSをCEに供給するのに使用されるかもしれません。
In any event, if the packet was an unlabeled IP packet when it arrived at its ingress PE, it will again be an unlabeled packet when it leaves its egress PE.
出口をPEに出るとき、とにかく、イングレスPEに到着したとき、パケットがラベルされていないIPパケットであったなら、それは再びラベルされていないパケットになるでしょう。
The fact that packets with VPN route labels are tunneled through the backbone is what makes it possible to keep all the VPN routes out of the P routers. This is crucial to ensuring the scalability of the
VPNルートラベルがあるパケットが背骨を通してトンネルを堀られるという事実はすべてのVPNルートをPルータに入れないようにするのを可能にすることです。 スケーラビリティを確実にしますこれが重要である。
Rosen & Rekhter Standards Track [Page 25] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[25ページ]。
scheme. The backbone does not even need to have routes to the CEs, only to the PEs.
計画してください。 背骨はCEsと、そして、PEsだけにルートを必要とさえしません。
With respect to the tunnels, it is worth noting that this specification:
トンネルの、それに注意する価値がある、この仕様:
- DOES NOT require that the tunnels be point-to-point; multipoint-
to-point can be used;
- DOES NOTは、トンネルが二地点間であることを必要とします。 多点をポイントまで使用できます。
- DOES NOT require that there be any explicit setup of the tunnels,
either via signaling or via manual configuration;
- DOES NOTはいずれかがシグナリングの近く、または、手動の構成を通したトンネルの明白なセットアップであったならそこでそれを必要とします。
- DOES NOT require that there be any tunnel-specific signaling;
- DOES NOTはいずれかがトンネル特有のシグナリングであったならそこでそれを必要とします。
- DOES NOT require that there be any tunnel-specific state in the P
or PE routers, beyond what is necessary to maintain the routing
information and (if used) the MPLS label information.
- DOES NOTはいずれかがPかPEルータでトンネル特有の状態であったならそこでそれを必要とします、ルーティングが情報と(使用されるなら)MPLSラベル情報であることを支持するのに必要なことを超えて。
Of course, this specification is compatible with the use of point- to-point tunnels that must be explicitly configured and/or signaled, and in some situations there may be reasons for using such tunnels.
もちろん、この仕様はトンネルをポイントへの明らかに構成しなければならないポイントトンネルの使用と互換性がある、示して、そして/または、あるかもしれないいくつかの状況そのようなものを使用するために推論します。
The considerations that are relevant to choosing a particular tunneling technology are outside the scope of this specification.
この仕様の範囲の外に特定のトンネリング技術を選ぶと関連している問題があります。
6. Maintaining Proper Isolation of VPNs
6. VPNsの適切な孤立を維持します。
To maintain proper isolation of one VPN from another, it is important that no router in the backbone accept a tunneled packet from outside the backbone, unless it is sure that both endpoints of that tunnel are outside the backbone.
別のものから1VPNの適切な孤立を維持するために、背骨でどんなルータも背骨の外からトンネルを堀られたパケットを受け入れないのは、重要です、背骨の外にそのトンネルの両方の終点があるのが、確かでない場合。
If MPLS is being used as the tunneling technology, this means that a router in the backbone MUST NOT accept a labeled packet from any adjacent non-backbone device unless the following two conditions hold:
MPLSがトンネリング技術として使用されているなら、これは、以下の2つの条件が成立しないなら背骨のルータがどんな隣接している非背骨装置からもラベルされたパケットを受け入れてはいけないことを意味します:
1. the label at the top of the label stack was actually
distributed by that backbone router to that non-backbone
device, and
そして1. ラベルスタックの先端のラベルが実際にその背骨ルータによってその非背骨装置に分配された。
2. the backbone router can determine that use of that label will
cause the packet to leave the backbone before any labels lower
in the stack will be inspected, and before the IP header will
be inspected.
2. 背骨ルータは、どんなラベルもスタックに下ろされる前に、パケットが意志で背骨を残すそのラベルの使用が点検されて、IPヘッダーの前で点検されることを決定できます。
The first condition ensure that any labeled packets received from non-backbone routers have a legitimate and properly assigned label at
最初の状態は、いずれもルータが正統の、そして、適切に割り当てられたラベルを持っている非背骨から受け取られたパケットをラベルしたのを確実にします。
Rosen & Rekhter Standards Track [Page 26] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[26ページ]。
the top of the label stack. The second condition ensures that the backbone routers will never look below that top label. Of course, the simplest way to meet these two conditions is just to have the backbone devices refuse to accept labeled packets from non-backbone devices.
ラベルスタックの先端。 第2状態は、背骨ルータがそのトップラベルの下で決して見ないのを確実にします。 もちろん、これらの2つの条件を満たす最も簡単な方法は背骨装置に非背骨装置からラベルされたパケットを受け入れるのをちょっと拒否させることです。
If MPLS is not being used as the tunneling technology, then filtering must be done to ensure that an MPLS-in-IP or MPLS-in-GRE packet can be accepted into the backbone only if the packet's IP destination address will cause it to be sent outside the backbone.
トンネリング技術としてMPLSを使用していないなら、背骨の外でパケットの受信者IPアドレスでそれを送る場合にだけIPにおけるMPLSかGREのMPLSパケットを背骨に受け入れることができるのを保証するためにフィルタリングをしなければなりません。
7. How PEs Learn Routes from CEs
7. PEsはCEsからルートをどう学ぶか。
The PE routers that attach to a particular VPN need to know, for each attachment circuit leading to that VPN, which of the VPN's addresses should be reached over that attachment circuit.
特定のVPNに付くPEルータは、知る必要があります、その付属サーキットの上にVPNのアドレスについて達するべきであるそのVPNに通じるそれぞれの付属サーキットに。
The PE translates these addresses into VPN-IPv4 addresses, using a configured RD. The PE then treats these VPN-IPv4 routes as input to BGP. Routes from a VPN site are NOT leaked into the backbone's IGP.
構成されたRDを使用して、PEはこれらのアドレスをVPN-IPv4アドレスに翻訳します。 そして、PEはBGPに入力されるようにこれらのVPN-IPv4ルートを扱います。 VPNサイトからのルートは背骨のIGPに漏らされません。
Exactly which PE/CE route distribution techniques are possible depends on whether or not a particular CE is in a "transit VPN". A "transit VPN" is one that contains a router that receives routes from a "third party" (i.e., from a router that is not in the VPN, but is not a PE router) and that redistributes those routes to a PE router. A VPN that is not a transit VPN is a "stub VPN". The vast majority of VPNs, including just about all corporate enterprise networks, would be expected to be "stubs" in this sense.
まさにどのPE/CEルート分配技法が可能であるかは特定のCEが「トランジットVPN」であるかどうかによります。 「トランジットVPN」は「第三者」(すなわち、VPNにありませんが、PEルータでないルータからの)からルートを受けて、それらのルートをPEルータに再配付するルータを含むものです。 トランジットVPNでないVPNは「スタッブVPN」です。 ほとんどすべての集団経営ネットワークを含むVPNsのかなりの大部分がこの意味で「スタッブ」であることが期待されるでしょう。
The possible PE/CE distribution techniques are:
可能なPE/CE分配技法は以下の通りです。
1. Static routing (i.e., configuration) may be used. (This is
likely to be useful only in stub VPNs.)
1. スタティックルーティング(すなわち、構成)は使用されるかもしれません。 (これはスタッブVPNsだけで役に立つ傾向があります。)
2. PE and CE routers may be Routing Information Protocol (RIP)
[RIP] peers, and the CE may use RIP to tell the PE router the
set of address prefixes that are reachable at the CE router's
site. When RIP is configured in the CE, care must be taken to
ensure that address prefixes from other sites (i.e., address
prefixes learned by the CE router from the PE router) are never
advertised to the PE. More precisely: if a PE router, say,
PE1, receives a VPN-IPv4 route R1, and as a result distributes
an IPv4 route R2 to a CE, then R2 must not be distributed back
from that CE's site to a PE router, say, PE2, (where PE1 and
PE2 may be the same router or different routers), unless PE2
maps R2 to a VPN-IPv4 route that is different than (i.e.,
contains a different RD than) R1.
2. PEとCEルータはルーティング情報プロトコル(RIP)[RIP]同輩であるかもしれません、そして、CEはCEルータのサイトで届いているアドレス接頭語のセットをPEルータに言うのにRIPを使用するかもしれません。 RIPがCEで構成されるとき、他のサイト(すなわち、アドレス接頭語はCEルータでPEルータから学んだ)からのアドレス接頭語が決してPEに広告を出さないのを保証するために注意しなければなりません。 より正確: すなわち、PEルータ(たとえば、PE1)がVPN-IPv4ルートR1を受けて、その結果IPv4ルートR2をCEに分配するなら、たとえば、PEルータか、PE2か、そのCEのサイトから(PE1とPE2はどこの同じルータであるかもしれないか、そして、異なったルータ)までR2を分配してはいけません、PE2が異なったVPN-IPv4ルートにR2を写像しない場合(異なったRDを含んでいる、)、R1。
Rosen & Rekhter Standards Track [Page 27] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[27ページ]。
3. The PE and CE routers may be OSPF peers. A PE router that is
an OSPF peer of a CE router appears, to the CE router, to be an
area 0 router. If a PE router is an OSPF peer of CE routers
that are in distinct VPNs, the PE must of course be running
multiple instances of OSPF.
3. PEとCEルータはOSPF同輩であるかもしれません。 CEルータのOSPF同輩であるPEルータは、領域0ルータになるようにCEルータに現れます。 PEルータが異なったVPNsにあるCEルータのOSPF同輩であるなら、PEはもちろんOSPFの複数の例を走らせていなければなりません。
IPv4 routes that the PE learns from the CE via OSPF are
redistributed into BGP as VPN-IPv4 routes. Extended Community
attributes are used to carry, along with the route, all the
information needed to enable the route to be distributed to
other CE routers in the VPN in the proper type of OSPF Link
State Advertisement (LSA). OSPF route tagging is used to
ensure that routes received from the MPLS/BGP backbone are not
sent back into the backbone.
VPN-IPv4ルートとしてPEがOSPFを通してCEから学ぶIPv4ルートをBGPに再配付します。 拡張Community属性は運ぶのに使用されます、ルートと共に、ルートがOSPF Link州Advertisementの適切なタイプでVPNの他のCEルータに分配されるのを可能にするのに必要であるすべての情報(LSA)。 OSPFルートタグ付けは、MPLS/BGP背骨から受け取られたルートが背骨に返送されないのを保証するのに使用されます。
Specification of the complete set of procedures for the use of
OSPF between PE and CE can be found in [VPN-OSPF] and
[OSPF-2547-DNBIT].
[VPN-OSPF]と[OSPF-2547-DNBIT]でPEとCEの間のOSPFの使用のための完全なセットの手順の仕様を見つけることができます。
4. The PE and CE routers may be BGP peers, and the CE router may
use BGP (in particular, EBGP to tell the PE router the set of
address prefixes that are at the CE router's site. (This
technique can be used in stub VPNs or transit VPNs.)
4. PEとCEルータはBGP同輩であるかもしれません、そして、CEルータはBGPを使用するかもしれません。(特に、アドレスのセットがそれを前に置くとPEルータに言うEBGPがCEルータのサイトにあります。(スタッブVPNsかトランジットVPNsにこのテクニックを使用できます。)
This technique has a number of advantages over the others:
このテクニックには、他のものより多くの利点があります:
a) Unlike the IGP alternatives, this does not require the PE
to run multiple routing algorithm instances in order to
talk to multiple CEs.
a) IGP代替手段と異なって、これは、複数のCEsと話すためにPEが複数のルーティング・アルゴリズム例を走らせるのを必要としません。
b) BGP is explicitly designed for just this function:
passing routing information between systems run by
different administrations.
b) BGPはまさしくこの機能のために明らかに設計されています: ルーティング情報をシステムの間に通過して、異なった政権で走ってください。
c) If the site contains "BGP backdoors", i.e., routers with
BGP connections to routers other than PE routers, this
procedure will work correctly in all circumstances. The
other procedures may or may not work, depending on the
precise circumstances.
c) サイトが「BGP裏口」、すなわち、BGP接続があるルータをPEルータ以外のルータに含んでいると、この手順はすべての事情で正しく利くでしょう。 正確な事情によって、他の手順は利くかもしれません。
d) Use of BGP makes it easy for the CE to pass attributes of
the routes to the PE. A complete specification of the
set of attributes and their use is outside the scope of
this document. However, some examples of the way this
may be used are the following:
d) BGPの使用で、CEがルートの属性をPEに通過するのが簡単になります。 このドキュメントの範囲の外に属性のセットと彼らの使用の完全な仕様があります。 しかしながら、これが使用されるかもしれない方法に関するいくつかの例が以下です:
Rosen & Rekhter Standards Track [Page 28] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[28ページ]。
- The CE may suggest a particular Route Target for each
route, from among the Route Targets that the PE is
authorized to attach to the route. The PE would then
attach only the suggested Route Target, rather than
the full set. This gives the CE administrator some
dynamic control of the distribution of routes from
the CE.
- CEは各ルートに特定のRoute Targetを勧めるかもしれません、PEがルートに付けるのが認可されるRoute Targetsから。 そして、PEはフルセットよりむしろ提案されたRoute Targetだけを取り付けるでしょう。 これはルートの分配の何らかの動的制御をCEからCE管理者に与えます。
- Additional types of Extended Community attributes may
be defined, where the intention is to have those
attributes passed transparently (i.e., without being
changed by the PE routers) from CE to CE. This would
allow CE administrators to implement additional route
filtering, beyond that which is done by the PEs.
This additional filtering would not require
coordination with the SP.
- 追加タイプのExtended Community属性(意志はそれらの属性を透明にCEからCEまで通過させる(すなわち、PEルータで変えないで)ことである)は定義されるかもしれません。 これで、CE管理者はPEsによって行われるそれを超えて追加ルートフィルタリングを実行できるでしょう。 この追加フィルタリングはSPとのコーディネートを必要としないでしょう。
On the other hand, using BGP may be something new for the CE
administrators.
他方では、BGPを使用するのは、CE管理者にとって、何か新しいものであるかもしれません。
If a site is not in a transit VPN, note that it need not have a
unique Autonomous System Number (ASN). Every CE whose site is
not in a transit VPN can use the same ASN. This can be chosen
from the private ASN space, and it will be stripped out by the
PE. Routing loops are prevented by use of the Site of Origin
attribute (see below).
VPN、サイトがトランジットでないなら、ユニークなAutonomous System Number(ASN)を持つ必要はないことに注意してください。 サイトがトランジットに、VPNが同じASNを使用できるということであるというわけではないあらゆるCE。 個人的なASNスペースからこれを選ぶことができます、そして、それはPEによって取り除かれるでしょう。 ルート設定輪はOrigin属性のSiteの使用で防がれます(以下を見てください)。
What if a set of sites constitutes a transit VPN? This will
generally be the case only if the VPN is itself an Internet
Service Provider's (ISP's) network, where the ISP is itself
buying backbone services from another SP. The latter SP may be
called a "carrier's carrier". In this case, the best way to
provide the VPN is to have the CE routers support MPLS, and to
use the technique described in Section 9.
1セットのサイトがトランジットVPNを構成すると、どうなるでしょうか? 一般に、これはVPNがそれ自体でインターネットサービスプロバイダ(ISPのもの)のネットワークにすぎないならなるでしょう。そこでは、そう、ISPは別のSPから背骨サービスを買っています。 後者のSPは「キャリヤーのキャリヤー」と呼ばれるかもしれません。 この場合、VPNを提供する最も良い方法は、CEルータにMPLSを支持させて、セクション9で説明されたテクニックを使用することです。
When we do not need to distinguish among the different ways in which a PE can be informed of the address prefixes that exist at a given site, we will simply say that the PE has "learned" the routes from that site. This includes the case where the PE has been manually configured with the routes.
与えられたサイトに存在するアドレス接頭語についてPEを知らすことができる異なった方法の中で区別する必要はないなら、私たちは、PEがそのサイトからルートを「学んだ」と単に言うつもりです。 これはPEがルートによって手動で構成されたケースを含んでいます。
Before a PE can redistribute a VPN-IPv4 route learned from a site, it must assign a Route Target attribute (see Section 4.3.1) to the route, and it may assign a Site of Origin attribute to the route.
PEがサイトから学習されたVPN-IPv4ルートを再配付できる前に、Route Target属性(セクション4.3.1を見る)をルートに割り当てなければなりません、そして、Origin属性のSiteをルートに割り当てるかもしれません。
The Site of Origin attribute, if used, is encoded as a Route Origin Extended Community [BGP-EXTCOMM]. The purpose of this attribute is to uniquely identify the set of routes learned from a particular
使用されるなら、Origin属性のSiteはRoute Origin Extended Community[BGP-EXTCOMM]としてコード化されます。 この属性の目的は唯一事項から学習されたルートのセットを特定することです。
Rosen & Rekhter Standards Track [Page 29] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[29ページ]。
site. This attribute is needed in some cases to ensure that a route learned from a particular site via a particular PE/CE connection is not distributed back to the site through a different PE/CE connection. It is particularly useful if BGP is being used as the PE/CE protocol, but different sites have not been assigned distinct ASNs.
サイト。 この属性が、いくつかの場合、特定のサイトから特定のPE/CE接続で学習されたルートが異なったPE/CE接続でサイトに分配して戻されないのを保証するのに必要です。 PE/CEが議定書を作るときBGPが使用されていますが、異なったASNsが異なったサイトに割り当てられていないなら、特に役に立ちます。
8. How CEs Learn Routes from PEs
8. CEsはPEsからルートをどう学ぶか。
In this section, we assume that the CE device is a router.
このセクションでは、私たちは、CE装置がルータであると思います。
If the PE places a particular route in the VRF it uses to route packets received from a particular CE, then in general, the PE may distribute that route to the CE. Of course, the PE may distribute that route to the CE only if this is permitted by the rules of the PE/CE protocol. (For example, if a particular PE/CE protocol has "split horizon", certain routes in the VRF cannot be redistributed back to the CE.) We add one more restriction on the distribution of routes from PE to CE: if a route's Site of Origin attribute identifies a particular site, that route must never be redistributed to any CE at that site.
PEがそれが特定のCEから受け取られたパケットを発送するのに使用するVRFの特定のルートを置くなら、一般に、PEはそのルートをCEに分配するかもしれません。 もちろん、これがPE/CEプロトコルの規則で受入れられる場合にだけ、PEはそのルートをCEに分配するかもしれません。 (例えば、特定のPE/CEプロトコルを「地平線を分けさせた」なら、VRFのある一定のルートをCEに再配付であって戻しできません。) 私たちはルートのPEからCEまでの分配のときにもうひとつの制限を加えます: ルートのOrigin属性のSiteが特定のサイトを特定するなら、そのサイトのどんなCEにもそのルートを決して再配付してはいけません。
In most cases, however, it will be sufficient for the PE to simply distribute the default route to the CE. (In some cases, it may even be sufficient for the CE to be configured with a default route pointing to the PE.) This will generally work at any site that does not itself need to distribute the default route to other sites. (E.g., if one site in a corporate VPN has the corporation's access to the Internet, that site might need to have default distributed to the other site, but one could not distribute default to that site itself.)
多くの場合、しかしながら、PEが単にデフォルトルートをCEに分配するのは、十分です。 (いくつかの場合、CEがPEを示すデフォルトルートによって構成されるのは、十分でさえあるかもしれません。) 一般に、これは他のサイトにデフォルトルートを分配する必要性をそれ自体にするというわけではないどんなサイトでも働くでしょう。 (例えば、法人のVPNの1つのサイトが会社のアクセスをインターネットに持つなら、そのサイトは、もう片方のサイトにデフォルトを分配させる必要があるかもしれませんが、1つはそのサイト自体にデフォルトを分配できませんでした。)
Whatever procedure is used to distribute routes from CE to PE will also be used to distribute routes from PE to CE.
また、CEからPEまでルートを分配するのに用いられるどんな手順も、PEからCEまでルートを分配するのに用いられるでしょう。
9. Carriers' Carriers
9. キャリアズキャリア
Sometimes a VPN may actually be the network of an ISP, with its own peering and routing policies. Sometimes a VPN may be the network of an SP that is offering VPN services in turn to its own customers. VPNs like these can also obtain backbone service from another SP, the "carrier's carrier", using essentially the same methods described in this document. However, it is necessary in these cases that the CE routers support MPLS. In particular:
時々、VPNは実際にそれ自身のじっと見るのとルーティング方針があるISPのネットワークであるかもしれません。 それ自身の顧客にとって時々、VPNは順番にサービスをVPNに提供しているSPのネットワークであるかもしれません。 また、別のSP、「キャリヤーのキャリヤー」からこれらのようなVPNsは背骨サービスを得ることができます、本書では説明された本質的には同じ方法を使用して。 しかしながら、これらの場合では、CEルータがMPLSを支持するのが必要です。 特に:
- The CE routers should distribute to the PE routers ONLY those
routes that are internal to the VPN. This allows the VPN to be
handled as a stub VPN.
- CEルータはVPNに内部であることのそれらのルートだけをPEルータに分配するべきです。 これは、VPNがスタッブVPNとして扱われるのを許容します。
Rosen & Rekhter Standards Track [Page 30] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[30ページ]。
- The CE routers should support MPLS, in that they should be able
to receive labels from the PE routers, and send labeled packets
to the PE routers. They do not need to distribute labels of
their own, though.
- CEルータはMPLSを支持するべきです、彼らがPEルータからラベルを受けて、ラベルされたパケットをPEルータに送ることができるべきであるので。 もっとも、彼らはそれら自身のラベルを分配する必要はありません。
- The PE routers should distribute, to the CE routers, labels for
the routes they distribute to the CE routers.
- PEルータはそれらがCEルータに分配するルートのためにCEルータにラベルを分配するべきです。
The PE must not distribute the same label to two different CEs
unless one of the following conditions holds:
以下の条件の1つが持ちこたえない場合、PEは2異なったCEsに同じラベルを分配してはいけません:
* The two CEs are associated with exactly the same set of VRFs;
* 2CEsがVRFsのまさに同じセットに関連しています。
* The PE maintains a different Incoming Label Map ([MPLS-ARCH])
for each CE.
* PEは各CEのために、異なったIncoming Label Map([MPLS-ARCH])を維持します。
Further, when the PE receives a labeled packet from a CE, it must
verify that the top label is one that was distributed to that CE.
PEがCEからラベルされたパケットを受けるとき、さらに、それは、トップラベルがそのCEに分配されたものであることを確かめなければなりません。
- Routers at the different sites should establish BGP connections
among themselves for the purpose of exchanging external routes
(i.e., routes that lead outside of the VPN).
- 異なったサイトのルータは外部経路(すなわち、VPNの外で導くルート)を交換する目的のために自分たちの中でBGP接続を確立するべきです。
- All the external routes must be known to the CE routers.
- すべての外部経路をCEルータに知っていなければなりません。
Then when a CE router looks up a packet's destination address, the routing lookup will resolve to an internal address, usually the address of the packet's BGP next hop. The CE labels the packet appropriately and sends the packet to the PE. The PE, rather than looking up the packet's IP destination address in a VRF, uses the packet's top MPLS label to select the BGP next hop. As a result, if the BGP next hop is more than one hop away, the top label will be replaced by two labels, a tunnel label and a VPN route label. If the BGP next hop is one hop away, the top label may be replaced by just the VPN route label. If the ingress PE is also the egress PE, the top label will just be popped. When the packet is sent from its egress PE to a CE, the packet will have one fewer MPLS labels than it had when it was first received by its ingress PE.
そして、CEルータがパケットの送付先アドレスを調べるとき、ルーティングルックアップは、次に跳ぶように内部のアドレス、通常パケットのBGPのアドレスに決議するでしょう。 CEは適切にパケットをラベルして、パケットをPEに送ります。 VRFのパケットの受信者IPアドレスを調べるよりむしろPE、パケットの先端MPLSが次のBGPを選択するためにラベルする用途は跳びます。 その結果、次のホップがBGPであるなら遠くで十二分にワンバウンドである、トップラベルを2個のラベル、トンネルラベル、およびVPNルートラベルに取り替えるでしょう。 次のホップがBGPであるなら遠くでワンバウンドである、トップラベルをまさしくVPNルートラベルに取り替えるかもしれません。 イングレスPEが出口もPEであるなら、トップラベルはただ飛び出すでしょう。 出口PEからCEにパケットを送るとき、パケットはイングレスPEによって受け取られた1番目であったときに、それが持っていたよりさらに少ないMPLSがラベルする1つを持つでしょう。
In the above procedure, the CE routers are the only routers in the VPN that need to support MPLS. If, on the other hand, all the routers at a particular VPN site support MPLS, then it is no longer required that the CE routers know all the external routes. All that is required is that the external routes be known to whatever routers are responsible for putting the label stack on a hitherto unlabeled packet and that there be label switched path that leads from those routers to their BGP peers at other sites. In this case, for each
上の手順で、CEルータはVPNでMPLSを支持する必要がある唯一のルータです。 他方では、特定のVPNサイトのすべてのルータがMPLSを支持するなら、もうCEルータがすべての外部経路を知るのが必要ではありません。 必要であるすべては外部経路がいかなるルータもそこにこれまでラベルされていないパケットとそれにラベルスタックを置くのに責任があるのが、ラベルが他のサイトでそれらのルータから彼らのBGP同輩まで導く経路を切り換えたということであるということであっても知られているということです。 この場合、それぞれ
Rosen & Rekhter Standards Track [Page 31] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[31ページ]。
internal route that a CE router distributes to a PE router, it must also distribute a label.
インターナルはそれを発送します。CEルータはPEにルータを分配します、また、それがラベルを分配しなければなりません。
10. Multi-AS Backbones
10. マルチ、背骨
What if two sites of a VPN are connected to different Autonomous Systems (e.g., because the sites are connected to different SPs)? The PE routers attached to that VPN will then not be able to maintain IBGP connections with each other, or with a common route reflector. Rather, there needs to be some way to use EBGP to distribute VPN-IPv4 addresses.
VPNの2つのサイトが異なったAutonomous Systemsにつなげられると(例えば、サイトが異なったSPsにつなげられるので)、どうなるでしょうか? そのVPNに付けられたPEルータはその時、互い、または一般的なルート反射鏡とのIBGP接続を維持できないでしょう。 むしろ、VPN-IPv4アドレスを配布するのにEBGPを使用する何らかの方法があるのが必要です。
There are a number of different ways of handling this case, which we present in order of increasing scalability.
スケーラビリティを増加させることの順に私たちが提示する本件を扱う多くの異なった方法があります。
a) VRF-to-VRF connections at the AS (Autonomous System) border
routers.
a) VRFからVRFとのAS(自治のSystem)での接続はルータに接しています。
In this procedure, a PE router in one AS attaches directly to a
PE router in another. The two PE routers will be attached by
multiple sub-interfaces, at least one for each of the VPNs
whose routes need to be passed from AS to AS. Each PE will
treat the other as if it were a CE router. That is, the PEs
associate each such sub-interface with a VRF, and use EBGP to
distribute unlabeled IPv4 addresses to each other.
この手順で、1ASのPEルータは直接別のもののPEルータに付きます。 2つのPEルータが複数のサブインタフェース、ルートがASからASまで通過される必要があるそれぞれのVPNsのための少なくともものまでに付けられるでしょう。 各PEはまるでそれがCEルータであるかのようにもう片方を扱うでしょう。 すなわち、PEsは、VRFとのそのようなそれぞれのサブインタフェースを関連づけて、ラベルされていないIPv4アドレスを互いに配布するのにEBGPを使用します。
This is a procedure that "just works", and that does not
require MPLS at the border between ASes. However, it does not
scale as well as the other procedures discussed below.
これは「ただ働い」て、ASesの間の境界でMPLSを必要としない手順です。 しかしながら、それは以下で議論した他の手順と同様に比例しません。
b) EBGP redistribution of labeled VPN-IPv4 routes from AS to
neighboring AS.
b) ラベルされたVPN-IPv4ルートのASによる隣接するEBGP再分配。
In this procedure, the PE routers use IBGP to redistribute
labeled VPN-IPv4 routes either to an Autonomous System Border
Router (ASBR), or to a route reflector of which an ASBR is a
client. The ASBR then uses EBGP to redistribute those labeled
VPN-IPv4 routes to an ASBR in another AS, which in turn
distributes them to the PE routers in that AS, or perhaps to
another ASBR which in turn distributes them, and so on.
この手順で、PEルータは、Autonomous System Border Router(ASBR)、または、ASBRがクライアントであるルート反射鏡にラベルされたVPN-IPv4ルートを再配付するのにIBGPを使用します。 そして、ASBRは、順番に恐らく順番に彼らを分配する別のASBRにそのASのPEルータ、または、彼らを分配する別のASなどでVPN-IPv4ルートとラベルされたものをASBRに再配付するのにEBGPを使用します。
When using this procedure, VPN-IPv4 routes should only be
accepted on EBGP connections at private peering points, as part
of a trusted arrangement between SPs. VPN-IPv4 routes should
neither be distributed to nor accepted from the public
Internet, or from any BGP peers that are not trusted. An ASBR
should never accept a labeled packet from an EBGP peer unless
it has actually distributed the top label to that peer.
個人的なじっと見るポイントでのEBGP接続のときにこの手順を用いるとき、VPN-IPv4ルートを受け入れるだけであるべきです、SPsの間の信じられた配置の一部として。 VPN-IPv4ルートは、信じられない同輩を、どちらも分配して、公共のインターネットか、どんなBGPからも受け入れるべきではありません。 実際にその同輩にトップラベルを分配していない場合、ASBRはEBGP同輩からラベルされたパケットを決して受け入れるはずがありません。
Rosen & Rekhter Standards Track [Page 32] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[32ページ]。
If there are many VPNs having sites attached to different
Autonomous Systems, there does not need to be a single ASBR
between those two ASes that holds all the routes for all the
VPNs; there can be multiple ASBRs, each of which holds only the
routes for a particular subset of the VPNs.
多くのVPNsがあれば、そこの異なったAutonomous Systemsにサイトを添付させるのは、すべてのVPNsのためのすべてのルートを保持するそれらの2ASesの間の独身のASBRである必要がありません。 複数のASBRsがあることができます。それはそれぞれVPNsの特定の部分集合のためのルートだけを保持します。
This procedure requires that there be a label switched path
leading from a packet's ingress PE to its egress PE. Hence the
appropriate trust relationships must exist between and among
the set of ASes along the path. Also, there must be agreement
among the set of SPs as to which border routers need to receive
routes with which Route Targets.
この手順はパケットのイングレスPEから出口PEまでラベルが切り換えられた経路先導であったならそこでそれを必要とします。 したがって、適切な信用関係は経路に沿ってセットの間と、そして、ASesのセットの中に存在しなければなりません。 また、境界ルータがどのRoute Targetsと共にルートを受け取る必要があるSPsのセットの中に協定があるに違いありません。
c) Multi-hop EBGP redistribution of labeled VPN-IPv4 routes
between source and destination ASes, with EBGP redistribution
of labeled IPv4 routes from AS to neighboring AS.
c) ラベルされたVPN-IPv4のマルチホップEBGP再分配はソースと目的地の間でASesを発送します、ラベルされたIPv4ルートのASによる隣接するEBGP再分配で。
In this procedure, VPN-IPv4 routes are neither maintained nor
distributed by the ASBRs. An ASBR must maintain labeled IPv4
/32 routes to the PE routers within its AS. It uses EBGP to
distribute these routes to other ASes. ASBRs in any transit
ASes will also have to use EBGP to pass along the labeled /32
routes. This results in the creation of a label switched path
from the ingress PE router to the egress PE router. Now PE
routers in different ASes can establish multi-hop EBGP
connections to each other, and can exchange VPN-IPv4 routes
over those connections.
この手順で、VPN-IPv4ルートは、ASBRsによって維持されないで、また分配されません。 ASBRはASの中でラベルされたIPv4 /32ルートをPEルータに維持しなければなりません。 それは、他のASesにこれらのルートを分配するのにEBGPを使用します。 また、どんなトランジットASesにおけるASBRsも、ラベルされた/32ルートを回すのにEBGPを使用しなければならないでしょう。 ラベルの創造におけるこの結果はイングレスPEルータから出口PEルータに経路を切り換えました。 今、異なったASesのPEルータは、マルチホップEBGP接続を互いに確立できて、それらの接続の上とVPN-IPv4ルートを交換できます。
If the /32 routes for the PE routers are made known to the P
routers of each AS, everything works normally. If the /32
routes for the PE routers are NOT made known to the P routers
(other than the ASBRs), then this procedure requires a packet's
ingress PE to put a three-label stack on it. The bottom label
is assigned by the egress PE, corresponding to the packet's
destination address in a particular VRF. The middle label is
assigned by the ASBR, corresponding to the /32 route to the
egress PE. The top label is assigned by the ingress PE's IGP
Next Hop, corresponding to the /32 route to the ASBR.
PEルータのための/32ルートがそれぞれのASのPルータに明らかにされるなら、通常、すべてが働いています。 PEルータのための/32ルートがPルータ(ASBRsを除いた)に明らかにされないなら、この手順は、パケットのイングレスPEが3ラベルのスタックをそれに置くのを必要とします。 特定のVRFのパケットの送付先アドレスに対応している、化粧紙は出口PEによって割り当てられます。 出口PEへの/32ルートに対応している、中央ラベルはASBRによって割り当てられます。 ASBRへの/32ルートに対応している、トップラベルはイングレスPEのIGP Next Hopによって割り当てられます。
To improve scalability, one can have the multi-hop EBGP
connections exist only between a route reflector in one AS and
a route reflector in another. (However, when the route
reflectors distribute routes over this connection, they do not
modify the BGP next hop attribute of the routes.) The actual
PE routers would then only have IBGP connections to the route
reflectors in their own AS.
スケーラビリティを改良するために、1つで、マルチホップEBGP接続は1ASのルート反射鏡と別のもののルート反射鏡だけの間に存在できます。 (しかしながら、ルート反射鏡がこの接続の上にルートを分配するとき、それらは次のホップが結果と考えるルートのBGPを変更しません。) そして、実際のPEルータには、ルート反射鏡にはIBGP接続がそれら自身のASにあるだけでしょう。
Rosen & Rekhter Standards Track [Page 33] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[33ページ]。
This procedure is very similar to the "carrier's carrier"
procedures described in Section 9. Like the previous
procedure, it requires that there be a label switched path
leading from a packet's ingress PE to its egress PE.
この手順は手順がセクション9で説明した「キャリヤーのキャリヤー」と非常に同様です。 前の手順のように、それはパケットのイングレスPEから出口PEまでラベルが切り換えられた経路先導であったならそこでそれを必要とします。
11. Accessing the Internet from a VPN
11. VPNからインターネットにアクセスします。
Many VPN sites will need to be able to access the public Internet, as well as to access other VPN sites. The following describes some of the alternative ways of doing this.
多くのVPNサイトが、公共のインターネットにアクセスして、他のVPNサイトにアクセスできる必要があるでしょう。 以下はこれをする代替の方法のいくつかを述べます。
1. In some VPNs, one or more of the sites will obtain Internet
access by means of an "Internet gateway" (perhaps a firewall)
attached to a non-VRF interface to an ISP. The ISP may or may
not be the same organization as the SP that is providing the
VPN service. Traffic to/from the Internet gateway would then
be routed according to the PE router's default forwarding
table.
1. いくつかのVPNsでは、サイトの1つ以上は非VRFインタフェースに付けられた「インターネット・ゲートウェイ」(恐らくファイアウォール)によるインターネット・アクセスをISPとして得るでしょう。 ISPはVPNサービスを提供しているSPと同じ組織であるかもしれません。 そして、PEルータのデフォルト推進テーブルに応じて、インターネット・ゲートウェイからの/へのトラフィックは発送されるでしょう。
In this case, the sites that have Internet access may be
distributing a default route to their PEs, which in turn
redistribute it to other PEs and hence into other sites of the
VPN. This provides Internet access for all of the VPN's sites.
この場合、インターネット・アクセスを持っているサイトはそれらのPEsにデフォルトルートを分配しているかもしれません。(順番に、PEsは他のPEsと、そして、したがって、VPNの他のサイトの中にそれを再配付します)。 これはVPNのサイトのすべてのためのインターネット・アクセスを提供します。
In order to properly handle traffic from the Internet, the ISP
must distribute, to the Internet, routes leading to addresses
that are within the VPN. This is completely independent of any
of the route distribution procedures described in this
document. The internal structure of the VPN will in general
not be visible from the Internet; such routes would simply lead
to the non-VRF interface that attaches to the VPN's Internet
gateway.
インターネットからトラフィックを適切に扱うために、ISPはVPNの中にあるアドレスにつながるルートをインターネットに分配しなければなりません。 これは本書では説明されたルート分配手順のいずれからも完全に独立しています。 一般に、VPNの内部の構造はインターネットから目に見えないでしょう。 そのようなルートは単にVPNのインターネット・ゲートウェイに付く非VRFインタフェースに通じるでしょう。
In this model, there is no exchange of routes between a PE
router's default forwarding table and any of its VRFs. VPN
route distribution procedures and Internet route distribution
procedures are completely independent.
このモデルには、PEルータのデフォルト推進テーブルとVRFsのどれかの間には、ルートの交換が全くありません。 VPNルート分配手順とインターネットルート分配手順は完全に独立しています。
Note that although some sites of the VPN use a VRF interface to
communicate with the Internet, ultimately all packets to/from
the Internet traverse a non-VRF interface before
leaving/entering the VPN, so we refer to this as "non-VRF
Internet access".
私たちが「非VRFインターネット・アクセス」にこれについて言及するように、VPNのいくつかのサイトがインターネットで交信するのにVRFインタフェースを使用しますが、VPNに残すか、または入る前に結局インターネットからの/へのすべてのパケットが非VRFインタフェースを横断することに注意してください。
Note that the PE router to which the non-VRF interface attaches
does not necessarily need to maintain all the Internet routes
in its default forwarding table. The default forwarding table
could have as few as one route, "default", which leads to
非VRFインタフェースが付くPEルータが、必ずデフォルト推進テーブルのすべてのインターネットルートを維持する必要であるというわけではないことに注意してください。 推進テーブルが最小1つのルート、導く「デフォルト」を持つことができたデフォルト
Rosen & Rekhter Standards Track [Page 34] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[34ページ]。
another router (probably an adjacent one) that has the Internet
routes. A variation of this scheme is to tunnel packets
received over the non-VRF interface from the PE router to
another router, where this other router maintains the full set
of Internet routes.
インターネットルートがある別のルータ(たぶん隣接しているもの)。 この他のルータがインターネットルートのフルセットを維持するPEルータから別のルータまでの非VRFインタフェースの上に受け取られたトンネルパケットにはこの体系の変化があります。
2. Some VPNs may obtain Internet access via a VRF interface ("VRF
Internet access"). If a packet is received by a PE over a VRF
interface, and if the packet's destination address does not
match any route in the VRF, then it may be matched against the
PE's default forwarding table. If a match is made there, the
packet can be forwarded natively through the backbone to the
Internet, instead of being forwarded by MPLS.
2. いくつかのVPNsがVRFインタフェース(「VRFインターネット・アクセス」)を通してインターネット・アクセスを得るかもしれません。 パケットの送付先アドレスがVRFのどんなルートにも合っていないならパケットがPEによってVRFインタフェースの上に受け取られるなら、それはPEのデフォルト推進テーブルに取り組まされるかもしれません。 そこでマッチを作るなら、バックボーンを通してネイティブにパケットをインターネットに送ることができます、MPLSによって進められることの代わりに。
In order for traffic to flow natively in the opposite direction
(from Internet to VRF interface), some of the routes from the
VRF must be exported to the Internet forwarding table.
Needless to say, any such routes must correspond to globally
unique addresses.
トラフィックがネイティブに逆方向(インターネットからVRFインタフェースまでの)に流れるように、インターネット推進テーブルにVRFからのいくつかのルートをエクスポートしなければなりません。 言うまでもなく、どんなそのようなルートもグローバルにユニークなアドレスに対応しなければなりません。
In this scheme, the default forwarding table might have the
full set of Internet routes, or it might have as little as a
single default route leading to another router that does have
the full set of Internet routes in its default forwarding
table.
この体系では、デフォルト推進テーブルがインターネットルートのフルセットを持っているかもしれませんか、またはルートはそれでデフォルト推進テーブルのインターネットルートのフルセットを持っている別のルータにただ一つのデフォルトと同じくらい少なく導くかもしれません。
3. Suppose the PE has the capability to store "non-VPN routes" in
a VRF. If a packet's destination address matches a "non-VPN
route", then the packet is transmitted natively, rather than
being transmitted via MPLS. If the VRF contains a non-VPN
default route, all packets for the public Internet will match
it, and be forwarded natively to the default route's next hop.
At that next hop, the packets' destination addresses will be
looked up in the default forwarding table, and may match more
specific routes.
3. PEがVRFに「非VPNルート」を保存する能力を持っていると仮定してください。 パケットの送付先アドレスが「非VPNルート」に合っているなら、パケットはMPLSを通して伝えられるよりネイティブにむしろ伝えられます。 VRFが非VPNデフォルトルートを含んでいると、公共のインターネットへのすべてのパケットが、それを合わせて、ネイティブをデフォルトルートの次のホップへの送りのようになるでしょう。 その次のホップでは、パケットの送付先アドレスは、デフォルト推進テーブルで調べられて、より特定のルートに合うかもしれません。
This technique would only be available if none of the CE
routers is distributing a default route.
CEルータのいずれもデフォルトルートを分配していない場合にだけ、このテクニックは利用可能でしょう。
4. It is also possible to obtain Internet access via a VRF
interface by having the VRF contain the Internet routes.
Compared with model 2, this eliminates the second lookup, but
it has the disadvantage of requiring the Internet routes to be
replicated in each such VRF.
4. また、VRFにインターネットルートを含ませるのによるVRFインタフェースを通してインターネット・アクセスを得るのも可能です。 モデル2と比べて、これは2番目のルックアップを排除しますが、それには、インターネットルートがそのような各VRFで模写されるのが必要であることの不都合があります。
If this technique is used, the SP may want to make its
interface to the Internet be a VRF interface, and to use the
このテクニックが使用されているなら、SPはインターネットへのインタフェースがVRFインタフェースであることを作りたくて、使用に使用するかもしれません。
Rosen & Rekhter Standards Track [Page 35] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[35ページ]。
techniques of Section 4 to distribute Internet routes, as VPN-
IPv4 routes, to other VRFs.
インターネットを分配するセクション4のテクニックはVPN- IPv4として他のVRFsにルートを発送します。
It should be clearly understood that by default, there is no exchange of routes between a VRF and the default forwarding table. This is done ONLY upon agreement between a customer and an SP, and only if it suits the customer's policies.
デフォルトで、VRFとデフォルト推進テーブルの間には、ルートの交換が全くないのが明確に理解されるべきです。 顧客とSPとの協定だけのときにこれをして、それが顧客の方針に合うだけであるかどうかはそうします。
12. Management VPNs
12. 管理VPNs
This specification does not require that the sub-interface connecting a PE router and a CE router be a "numbered" interface. If it is a numbered interface, this specification allows the addresses assigned to the interface to come from either the address space of the VPN or the address space of the SP.
この仕様は、PEルータとCEルータを接続するサブインタフェースが「番号付」のインタフェースであることを必要としません。 それが番号付のインタフェースであるなら、この仕様で、インタフェースに割り当てられたアドレスはVPNのアドレス空間かSPのアドレス空間のどちらかから来ます。
If a CE router is being managed by the Service Provider, then the Service Provider will likely have a network management system that needs to be able to communicate with the CE router. In this case, the addresses assigned to the sub-interface connecting the CE and PE routers should come from the SP's address space, and should be unique within that space. The network management system should itself connect to a PE router (more precisely, be at a site that connects to a PE router) via a VRF interface. The address of the network management system will be exported to all VRFs that are associated with interfaces to CE routers that are managed by the SP. The addresses of the CE routers will be exported to the VRF associated with the network management system, but not to any other VRFs.
CEルータがService Providerによって管理されていると、Service Providerには、CEルータで交信できる必要があるネットワーク管理システムがおそらくあるでしょう。 この場合、CEとPEルータを接続しながらサブインタフェースに割り当てられたアドレスは、SPのアドレス空間から来るべきであり、そのスペースの中でユニークであるべきです。 ネットワーク管理システムがそうするべきである、それ自体、VRFインタフェースを通してPEルータ(より正確に、PEルータに接続するサイトにいる)に接続してください。 ネットワーク管理システムのアドレスはSPによって管理されるCEルータへのインタフェースに関連しているすべてのVRFsにエクスポートされるでしょう。 CEルータのアドレスは、ネットワーク管理システムに関連しているVRFにエクスポートされますが、いかなる他のVRFsにもエクスポートされるというわけではないでしょう。
This allows communication between the CE and network management system, but does not allow any undesired communication to or among the CE routers.
これは、CEとネットワーク管理システムの間にコミュニケーションを許容しますが、ルータかCEルータの中に少しの望まれないコミュニケーションも許容しません。
One way to ensure that the proper route import/exports are done is to use two Route Targets; call them T1 and T2. If a particular VRF interface attaches to a CE router that is managed by the SP, then that VRF is configured to:
適切なルート輸入/輸出が完了しているのを保証する1つの方法は2Route Targetsを使用することです。 それらをT1とT2と呼んでください。 特定のVRFインタフェースがSPによって管理されるCEルータに付くなら、そのVRFは以下のことのために構成されます。
- import routes that have T1 attached to them, and
- そしてT1を持っている輸入ルートがそれらに付いた。
- attach T2 to addresses assigned to each end of its VRF
interfaces.
- VRFインタフェースの各端まで割り当てられたアドレスにT2を取り付けてください。
If a particular VRF interface attaches to the SP's network management system, then that VRF is configured to attach T1 to the address of that system, and to import routes that have T2 attached to them.
特定のVRFインタフェースがSPのネットワーク管理システムに付くなら、そのVRFは、そのシステムのアドレスにT1を取り付けて、T2をそれらに取り付けるルートをインポートするために構成されます。
Rosen & Rekhter Standards Track [Page 36] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[36ページ]。
13. Security Considerations
13. セキュリティ問題
13.1. Data Plane
13.1. データ飛行機
By security in the "data plane", we mean protection against the following possibilities:
「データ飛行機」のセキュリティで、私たちは以下の可能性に対する保護を言っています:
- Packets from within a VPN travel to a site outside the VPN, other
than in a manner consistent with the policies of the VPN.
- VPNの方針と一致した方法以外のVPNの外のVPN旅行からサイトまでのパケット。
- Packets from outside a VPN enter one of the VPN's sites, other
than in a manner consistent with the policies of the VPN.
- VPNの外からのパケットはVPNのサイトの1つに入ります、VPNの方針と一致した方法を除いて。
Under the following conditions:
以下の条件の下で:
1. a backbone router does not accept labeled packets over a
particular data link, unless it is known that that data link
attaches only to trusted systems, or unless it is known that
such packets will leave the backbone before the IP header or
any labels lower in the stack will be inspected, and
そして1. バックボーンルータは特定のデータ・リンクの上にラベルされたパケットを受け入れません、そのデータ・リンクが信じられたシステムだけに付くのが知られていないか、またはIPヘッダーかどんなラベルもスタックに下ろされる前にパケットがバックボーンを残すそのようなものが点検されるのが知られていない場合。
2. labeled VPN-IPv4 routes are not accepted from untrusted or
unreliable routing peers,
2. ラベルされたVPN-IPv4ルートは信頼されていないか頼り無いルーティング同輩から受け入れられません。
3. no successful attacks have been mounted on the control plane,
3. どんなうまくいっている攻撃も制御飛行機で仕掛けられていません。
the data plane security provided by this architecture is virtually identical to that provided to VPNs by Frame Relay or ATM backbones. If the devices under the control of the SP are properly configured, data will not enter or leave a VPN unless authorized to do so.
このアーキテクチャによって提供されたデータ飛行機セキュリティは実際にはFrame RelayかATMバックボーンによってVPNsに提供されたそれと同じです。 SPのコントロールの下におけるデバイスが適切に構成されて、そうするのは認可されないと、データが、VPNを入りもしませんし、残しもしないでしょう。
Condition 1 above can be stated more precisely. One should discard a labeled packet received from a particular neighbor unless one of the following two conditions holds:
より正確に上記の状態1を述べることができます。 以下の2つの条件の1つが持ちこたえない場合特定の隣人から受け取られたラベルされたパケットを捨てるべきです:
- the packet's top label has a label value that the receiving
system has distributed to that neighbor, or
- またはパケットのトップラベルには受電方式がその隣人に分配したラベル値がある。
- the packet's top label has a label value that the receiving
system has distributed to a system beyond that neighbor (i.e.,
when it is known that the path from the system to which the label
was distributed to the receiving system may be via that
neighbor).
- パケットのトップラベルには、受電方式がその隣人でシステムに分配したラベル値があります(すなわち、いつその隣人を通してラベルが分配されたシステムから受電方式までの経路があるかもしれないのが知られていますか)。
Rosen & Rekhter Standards Track [Page 37] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[37ページ]。
Condition 2 above is of most interest in the case of inter-provider VPNs (see Section 10). For inter-provider VPNs constructed according to scheme b) of Section 10, condition 2 is easily checked. (The issue of security when scheme (c) of Section 10 is used is for further study.)
状態2 上では、関心が相互プロバイダーVPNsの場合で大部分です(セクション10を見てください)。 セクション10の体系b)通りに組み立てられた相互プロバイダーVPNsがないかどうか状態2は容易にチェックされます。 (セクション10の体系(c)が使用されているとき、さらなる研究には秘密保持の問題があります。)
It is worth noting that the use of MPLS makes it much simpler to provide data plane security than might be possible if one attempted to use some form of IP tunneling in place of the MPLS outer label. It is a simple matter to have one's border routers refuse to accept a labeled packet unless the first of the above conditions applies to it. It is rather more difficult to configure a router to refuse to accept an IP packet if that packet is an IP tunneled packet whose destination address is that of a PE router; certainly, this is not impossible to do, but it has both management and performance implications.
MPLSの使用でデータ飛行機セキュリティを提供するのが1つが、MPLSの外側のラベルに代わって何らかのフォームのIPトンネリングを使用するのを試みるなら可能であるというよりもはるかに簡単になることに注意する価値があります。 上記の状態の1番目がそれに適用されない場合人の境界ルータにラベルされたパケットを受け入れるのを拒否させるのは、簡単な事柄です。 IPパケットを受け入れるのを拒否するルータがそのパケットがIPであるなら送付先アドレスがPEルータのものであるパケットにトンネルを堀ったのを構成するのはかなり難しいです。 確かに、これはするのが不可能ではありませんが、それは管理と性能含意の両方を持っています。
MPLS-in-IP and MPLS-in-GRE tunneling are specified in [MPLS-in-IP-GRE]. If it is desired to use such tunnels to carry VPN packets, then the security considerations described in Section 8 of that document must be fully understood. Any implementation of BGP/MPLS IP VPNs that allows VPN 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トンネリングは[IP GREのMPLS]で指定されます。 VPNパケットを運ぶのにそのようなトンネルを使用するのが必要であるなら、そのドキュメントのセクション8で説明されたセキュリティ問題を完全に理解しなければなりません。 VPNパケットをそのドキュメントで説明されるようにトンネルを堀らせるBGP/MPLS IP VPNsのどんな実装もそこに説明されているとして使用できるIPsecの実装を含まなければなりません。 トンネルがIPsecによって固定されていないなら、そのドキュメントのセクション8.2で説明された境界ルータにおけるIPアドレスフィルタリングのテクニックは特定の出口PEでトンネルを出るパケットが実際に適切なトンネルヘッドノードによってトンネルに置かれたのを確実にする唯一の手段(すなわち、パケットがするのにおいて、偽造しているソースアドレスがない)です。 境界ルータが頻繁にソースアドレスだけをフィルターにかけるので、出口PEがそれが受けるどんなトンネルを堀られたパケットのIPソースアドレスもチェックして、有効なトンネルヘッドアドレスであるIPアドレスのリストとそれを比較できないなら、パケットフィルタリングは有効でないかもしれません。 IPにおけるMPLS、そして/または、GREのMPLSトンネリングがIPsecなしで使用されるのを許容するどんな実装でも、出口PEはこの様にそれが受けるどんなトンネルを堀られたパケットのIPソースアドレスも有効にすることができなければなりません。
In the case where a number of CE routers attach to a PE router via a LAN interface, to ensure proper security, one of the following conditions must hold:
多くのCEルータが適切なセキュリティを確実にするためにLANインタフェースを通してPEルータに付く場合では、以下の条件の1つは持ちこたえなければなりません:
1. All the CE routers on the LAN belong to the same VPN, or
1. またはLANのすべてのCEルータが同じVPNに属す。
2. A trusted and secured LAN switch divides the LAN into multiple
VLANs, with each VLAN containing only systems of a single VPN;
in this case, the switch will attach the appropriate VLAN tag
to any packet before forwarding it to the PE router.
2. 信じられて機密保護しているLANスイッチはLANを複数のVLANsに分割します、各VLANが独身のVPNのシステムだけを含んでいて。 この場合、PEルータにそれを送る前に、スイッチは適切なVLANタグをどんなパケットにも取り付けるでしょう。
Rosen & Rekhter Standards Track [Page 38] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[38ページ]。
Cryptographic privacy is not provided by this architecture, nor by Frame Relay or ATM VPNs. These architectures are all compatible with the use of cryptography on a CE-CE basis, if that is desired.
暗号のプライバシーはこのアーキテクチャと、Frame RelayかATM VPNsによって提供されません。 それが望まれているなら、これらのアーキテクチャはCE-CEベースにおける暗号の使用とすべて互換性があります。
The use of cryptography on a PE-PE basis is for further study.
さらなる研究にはPE-PEベースにおける暗号の使用があります。
13.2. Control Plane
13.2. 制御飛行機
The data plane security of the previous section depends on the security of the control plane. To ensure security, neither BGP nor LDP connections should be made with untrusted peers. The TCP/IP MD5 authentication option [TCP-MD5] should be used with both these protocols. The routing protocol within the SP's network should also be secured in a similar manner.
前項のデータ飛行機セキュリティは制御飛行機のセキュリティによります。 セキュリティを確実にするために、信頼されていない同輩と共にBGPも自由民主党の接続も作るべきではありません。 TCP/IP MD5認証オプション[TCP-MD5]はこれらのプロトコルの両方と共に使用されるべきです。 また、同じようにSPのネットワークの中のルーティング・プロトコルを保証するべきです。
13.3. Security of P and PE Devices
13.3. PのセキュリティとPEデバイス
If the physical security of these devices is compromised, data plane security may also be compromised.
また、これらの装置の物理的なセキュリティが妥協するなら、データ飛行機セキュリティは妥協するかもしれません。
The usual steps should be taken to ensure that IP traffic from the public Internet cannot be used to modify the configuration of these devices, or to mount Denial of Service attacks on them.
これらの装置の構成を変更するか、またはそれらにサービス妨害攻撃を仕掛けるのに公共のインターネットからのIP交通を使用できないのを保証するために普通の方法を取るべきです。
14. Quality of Service
14. サービスの質
Although not the focus of this paper, Quality of Service is a key component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS capabilities can be applied to labeled packets through the use of the "experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM is used as the backbone, through the use of ATM QoS capabilities. The traffic engineering work discussed in [MPLS-RSVP] is also directly applicable to MPLS/BGP VPNs. Traffic engineering could even be used to establish label switched paths with particular QoS characteristics between particular pairs of sites, if that is desirable. Where an MPLS/BGP VPN spans multiple SPs, the architecture described in [PASTE] may be useful. An SP may apply either intserv (Integrated Services) or diffserv (Differentiated Services) capabilities to a particular VPN, as appropriate.
この紙の焦点ではありませんが、ServiceのQualityはどんなVPNサービスの主要なコンポーネントです。 または、ATMが背骨として使用されるところでMPLS/BGP VPNsでは、詰め物のヘッダー[MPLS-ENCAPS]における「実験的な」ビットの使用で既存のL3 QoS能力をラベルされたパケットに適用できます、ATM QoS能力の使用で。 また、[MPLS-RSVP]で議論した交通技術系も直接MPLS/BGP VPNsに適切です。 交通工学は使用されて、特定の組のサイトの間には、特定のQoSの特性がある状態で、ラベルを設立するのが経路を切り換えました、それが望ましいならことでさえあるかもしれません。 MPLS/BGP VPNが複数のSPsにかかっているところでは、[PASTE]で説明された構造は役に立つかもしれません。 SPは適宜特定のVPNへのintserv(統合Services)かdiffserv(Servicesを微分する)能力のどちらかを適用するかもしれません。
Rosen & Rekhter Standards Track [Page 39] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[39ページ]。
15. Scalability
15. スケーラビリティ
We have discussed scalability issues throughout this paper. In this section, we briefly summarize the main characteristics of our model with respect to scalability.
私たちはこの紙中でスケーラビリティ問題について議論しました。 このセクションで、私たちはスケーラビリティに関して簡潔に私たちのモデルの主な特性をまとめます。
The Service Provider backbone network consists of (a) PE routers, (b) BGP Route Reflectors, (c) P routers (that are neither PE routers nor Route Reflectors), and, in the case of multi-provider VPNs, (d) ASBRs.
Service Provider背骨ネットワークは(a) PEルータ、(b) BGP Route Reflectors、(c) Pルータ(それは、PEルータでなくてまたRoute Reflectorsでない)、および(d) マルチプロバイダーVPNsの場合におけるASBRsから成ります。
P routers do not maintain any VPN routes. In order to properly forward VPN traffic, the P routers need only maintain routes to the PE routers and the ASBRs. The use of two levels of labeling is what makes it possible to keep the VPN routes out of the P routers.
PルータはどんなVPNルートも維持しません。 適切に交通をVPNに送るために、PルータはPEルータとASBRsにルートを維持するだけでよいです。 2つのレベルのラベリングの使用はPルータにVPNルートを入れないようにするのを可能にすることです。
A PE router maintains VPN routes, but only for those VPNs to which it is directly attached.
VPNルートを維持しますが、PEルータはそれが直接付けられているそれらのVPNsだけのためにそうします。
Route reflectors can be partitioned among VPNs so that each partition carries routes for only a subset of the VPNs supported by the Service Provider. Thus, no single route reflector is required to maintain routes for all VPNs.
各パーティションがService Providerによって支持されたVPNsの部分集合だけのためにルートを運ぶように、VPNsの中でルート反射鏡を仕切ることができます。 したがって、どんな単一のルート反射鏡も、すべてのVPNsのためにルートを維持するのに必要ではありません。
For inter-provider VPNs, if the ASBRs maintain and distribute VPN- IPv4 routes, then the ASBRs can be partitioned among VPNs in a similar manner, with the result that no single ASBR is required to maintain routes for all the inter-provider VPNs. If multi-hop EBGP is used, then the ASBRs need not maintain and distribute VPN-IPv4 routes at all.
相互プロバイダーVPNsに関しては、どんな独身のASBRもASBRsがVPN- IPv4ルートを維持して、分配するなら、VPNsの中で同じようにASBRsを仕切ることができて、その結果、すべての相互プロバイダーVPNsのためにルートを維持する必要はありません。 マルチホップEBGPが使用されているなら、ASBRsは全くVPN-IPv4ルートを維持して、分配する必要はありません。
As a result, no single component within the Service Provider network has to maintain all the routes for all the VPNs. So the total capacity of the network to support increasing numbers of VPNs is not limited by the capacity of any individual component.
その結果、Service Providerネットワークの中のどんなただ一つのコンポーネントもすべてのVPNsのためにすべてのルートを維持しなければならないというわけではありません。 それで、ネットワークがVPNsの数を増加させるのを支持する総容積はどんな個々のコンポーネントの容量によっても制限されません。
16. IANA Considerations
16. IANA問題
The Internet Assigned Numbers Authority (IANA) has created a new registry for the "Route Distinguisher Type Field" (see Section 4.2). This is a two-byte field. Types 0, 1, and 2 are defined by this document. Additional Route Distinguisher Type Field values with a high-order bit of 0 may be allocated by IANA on a "First Come, First Served" basis [IANA]. Values with a high-order bit of 1 may be allocated by IANA based on "IETF consensus" [IANA].
インターネットAssigned民数記Authority(IANA)は「ルートDistinguisherタイプ分野」に新しい登録を作成しました(セクション4.2を見てください)。 これは2バイトの分野です。 タイプ0、1、および2はこのドキュメントによって定義されます。 0の高位のビットがある追加Route Distinguisher Type Field値は「先着順」ベース[IANA]にIANAによって割り当てられるかもしれません。 1の高位のビットがある値は「IETFコンセンサス」[IANA]に基づくIANAによって割り当てられるかもしれません。
Rosen & Rekhter Standards Track [Page 40] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[40ページ]。
This document specifies (see Section 4.3.4) the use of the BGP Address Family Identifier (AFI) value 1, along with the BGP Subsequent Address Family Identifier (SAFI) value 128, to represent the address family "VPN-IPv4 Labeled Addresses", which is defined in this document.
このドキュメントは、アドレス家族本書では定義される「アドレスとラベルされたVPN-IPv4」を表すためにBGP Subsequent Address Family Identifier(サフィ)値128に伴うBGP Address Family Identifier(AFI)価値1の使用を指定します(セクション4.3.4を見ます)。
The use of AFI value 1 for IP is as currently specified in the IANA registry "Address Family Identifier", so IANA need take no action with respect to it.
AFI価値1のIPの使用が同じくらい現在IANA登録「アドレス家族識別子」で指定されるので、IANAはそれに関して行動を全く取る必要はありません。
The SAFI value 128 was originally specified as "Private Use" in the IANA "Subsequent Address Family Identifier" registry. IANA has changed the SAFI value 128 from "private use" to "MPLS-labeled VPN address".
サフィ値128は元々、「私用」としてIANA「その後のアドレス家族識別子」登録で指定されました。 IANAはサフィ値128を「私用」から「MPLSによってラベルされたVPNアドレス」に変えました。
17. Acknowledgements
17. 承認
The full list of contributors can be found in Section 18.
セクション18で貢献者の完全リストを見つけることができます。
Significant contributions to this work have also been made by Ravi Chandra, Dan Tappan, and Bob Thomas.
また、この仕事への重要な貢献はラービーチャンドラ、ダン・タッパン、およびボブ・トーマスによってされました。
We also wish to thank Shantam Biswas for his review and contributions.
また、彼のレビューと貢献についてShantamビスワスに感謝申し上げます。
18. Contributors
18. 貢献者
Tony Bogovic Telcordia Technologies 445 South Street, Room 1A264B Morristown, NJ 07960
トニーBogovic Telcordia Technologies445のSouth通り、余地の1A264Bモリスタウン、ニュージャージー 07960
EMail: tjb@research.telcordia.com
メール: tjb@research.telcordia.com
Stephen John Brannon Swisscom AG Postfach 1570 CH-8301 Glattzentrum (Zuerich), Switzerland
スティーブンジョンBrannon Swisscom株式会社Postfach1570CH-8301 Glattzentrum(Zuerich)、スイス
EMail: stephen.brannon@swisscom.com
メール: stephen.brannon@swisscom.com
Rosen & Rekhter Standards Track [Page 41] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[41ページ]。
Marco Carugi Nortel Networks S.A. Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT 78928 YVELINES Cedex 9 - FRANCE
マルコCarugiノーテルNetworks S.A.Parc d'activites deマニー-レスJeunes Bois CHATEAUFORT78928イブリーヌCedex9--フランス
EMail: marco.carugi@nortelnetworks.com
メール: marco.carugi@nortelnetworks.com
Christopher J. Chase AT&T 200 Laurel Ave Middletown, NJ 07748 USA
クリストファーJ.チェイスAT&T200ローレルAve Middletown、ニュージャージー07748米国
EMail: chase@att.com
メール: chase@att.com
Ting Wo Chung Bell Nexxia 181 Bay Street Suite 350 Toronto, Ontario M5J2T3
チリンチリンWo青ベルNexxia181カナダ金融界スイート350トロント、オンタリオM5J2T3
EMail: ting_wo.chung@bellnexxia.com
メール: ting_wo.chung@bellnexxia.com
Eric Dean
エリック・ディーン
Jeremy De Clercq Alcatel Network Strategy Group Francis Wellesplein 1 2018 Antwerp, Belgium
ジェレミーDe Clercqアルカテルネットワーク戦略グループフランシスWellesplein1 2018アントワープ(ベルギー)
EMail: jeremy.de_clercq@alcatel.be
メール: jeremy.de_clercq@alcatel.be
Luyuan Fang AT&T IP Backbone Architecture 200 Laurel Ave. Middletown, NJ 07748
Luyuan牙のAT&T IP背骨構造200ローレルAve。 ミドルタウン、ニュージャージー 07748
EMail: luyuanfang@att.com
メール: luyuanfang@att.com
Rosen & Rekhter Standards Track [Page 42] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[42ページ]。
Paul Hitchen BT BT Adastral Park Martlesham Heath, Ipswich IP5 3RE UK
ポールHitchen BT BT Adastral公園Martleshamヒース、イプスウィッチIP5 3REイギリス
EMail: paul.hitchen@bt.com
メール: paul.hitchen@bt.com
Manoj Leelanivas Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 USA
Manoj Leelanivas杜松はInc.385Ravendale Driveカリフォルニア94043マウンテンビュー(米国)をネットワークでつなぎます。
EMail: manoj@juniper.net
メール: manoj@juniper.net
Dave Marshall Worldcom 901 International Parkway Richardson, Texas 75081
Dave Marshall Worldcom901の国際パークウェイのリチャードソン、テキサス 75081
EMail: dave.marshall@wcom.com
メール: dave.marshall@wcom.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
ルカマティーニシスコシステムズ, Inc.9155のEastニコルズAvenue、イングルウッド、Suite400CO 80112
EMail: lmartini@cisco.com
メール: lmartini@cisco.com
Monique Jeanne Morrow Cisco Systems, Inc. Glatt-com, 2nd floor CH-8301 Glattzentrum, Switzerland
モニークジャンヌモローシスコシステムズInc.グラット-com、2階のCH-8301 Glattzentrum、スイス
EMail: mmorrow@cisco.com
メール: mmorrow@cisco.com
Rosen & Rekhter Standards Track [Page 43] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[43ページ]。
Ravichander Vaidyanathan Telcordia Technologies 445 South Street, Room 1C258B Morristown, NJ 07960
Ravichander Vaidyanathan TelcordiaのTechnologies445のSouth通り、余地の1C258Bモリスタウン、ニュージャージー 07960
EMail: vravi@research.telcordia.com
メール: vravi@research.telcordia.com
Adrian Smith BT BT Adastral Park Martlesham Heath, Ipswich IP5 3RE UK
エードリアンスミスBT BT Adastral公園Martleshamヒース、イプスウィッチIP5 3REイギリス
EMail: adrian.ca.smith@bt.com
メール: adrian.ca.smith@bt.com
Vijay Srinivasan 1200 Bridge Parkway Redwood City, CA 94065
Parkwayレッドウッドシティー、ビジェイSrinivasan1200Bridgeカリフォルニア 94065
EMail: vsriniva@cosinecom.com
メール: vsriniva@cosinecom.com
Alain Vedrenne Equant Heraklion, 1041 route des Dolines, BP347 06906 Sophia Antipolis, Cedex, France
アラン・ベドレン・イクアントヘラクリオン、1041ルートdes Dolines、BP347 06906ソフィアAntipolis、Cedex、フランス
EMail: Alain.Vedrenne@equant.com
メール: Alain.Vedrenne@equant.com
19. Normative References
19. 引用規格
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006.
[BGP]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858,
June 2000.
[BGP-MP]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
[BGP-EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP
Extended Communities Attribute", RFC 4360, February
2006.
[BGP-EXTCOMM] サーングリとS.とタッパン、D.とY.Rekhter、「BGPは共同体属性を広げた」RFC4360、2006年2月。
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[MPLS-アーチ] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
Rosen & Rekhter Standards Track [Page 44] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[44ページ]。
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label
Information in BGP-4", RFC 3107, May 2001.
「BGP-4インチ、RFC3107、2001年5月にラベル情報を運ぶ」[MPLS-BGP]Rekhter、Y.、およびE.ローゼン。
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.
[MPLS-ENCAPS]ローゼンとE.とタッパンとD.とFedorkowとG.とRekhterとY.とファリナッチとD.と李、T.とA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
20. Informative References
20. 有益な参照
[BGP-AS4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
AS Number Space", Work in Progress, March 2004.
[BGP-AS4] 「数としての4八重奏のスペースのBGPサポート」というVohra、Q.、およびE.チェンは進歩、2004年3月に働いています。
[BGP-ORF] Chen, E. and Y. Rekhter, "Cooperative Route
Filtering Capability for BGP-4", Work in Progress,
March 2004.
[BGP-ORF] チェン、E.、およびY.Rekhterは「2004年3月にBGP-4インチ、処理中の作業のためにフィルタリング能力を協力して発送します」。
[BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC
2918, September 2000.
[BGP-RFSH]チェン、E.、「ルートは2000年9月にBGP-4インチ、RFC2918のために能力をリフレッシュします」。
[BGP-RR] Bates, T., Chandra, R., and E. Chen, "BGP Route
Reflection - An Alternative to Full Mesh IBGP", RFC
2796, April 2000.
[BGP-RR] ベイツ、T.、チャンドラ、R.、およびE.チェン、「BGPは反射を発送します--完全なメッシュIBGPへの代替手段」、RFC2796、2000年4月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[IANA]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y., and P. Doolan, "MPLS
using LDP and ATM VC Switching", RFC 3035, January
2001.
[MPLS-気圧] デイビー、B.、ローレンス、J.、McCloghrie、K.、ローゼン、E.、ツバメ、G.、Rekhter、Y.、およびP.Doolan、「自由民主党と気圧VCの切り換えを使用するMPLS」、RFC3035(2001年1月)。
[MPLS/BGP-IPsec] Rosen, E., De Clercq, J., Paridaens, O., T'Joens,
Y., and C. Sargor, "Architecture for the Use of
PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in
Progress, March 2004.
[MPLS/BGP-IPsec]ローゼン、E.、J.、Paridaens、O.、T'Joens、Y.、およびC.Sargor、「BGP/MPLS IP VPNsにおけるPE-PE IPsec Tunnelsの使用のための構造」というDe Clercqは進行中(2004年3月)で働いています。
[MPLS-FR] Conta, A., Doolan, P., and A. Malis, "Use of Label
Switching on Frame Relay Networks Specification",
RFC 3034, January 2001.
[MPLS-FR] コンタ、A.、Doolan、P.、およびA.Malis、「フレームリレーにおけるラベルの切り換えの使用は仕様をネットワークでつなぎます」、RFC3034、2001年1月。
[MPLS-in-IP-GRE] Worster, T., Rekhter, Y., and E. Rosen,
"Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", RFC 4023, March 2005.
[IP GREのMPLS] オースター、T.、Rekhter、Y.、およびE.ローゼン、「IPか一般ルーティングのカプセル化(GRE)でMPLSを要約します」、RFC4023(2005年3月)。
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette,
A., and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[MPLS-自由民主党] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
Rosen & Rekhter Standards Track [Page 45] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[45ページ]。
[MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
[MPLS-RSVP] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[OSPFv2]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[PASTE] Li, T. and Y. Rekhter, "A Provider Architecture for
Differentiated Services and Traffic Engineering
(PASTE)", RFC 2430, October 1998.
[ペースト] 李とT.とY.Rekhter、「微分されたサービスと交通工学(ペースト)のためのプロバイダー構造」、RFC2430、1998年10月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[裂きます] マルキン、G.は「1998年11月にバージョン2インチ、STD56、RFC2453を裂きます」。
[OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault,
"Using an LSA Options Bit to Prevent Looping in
BGP/MPLS IP VPNs", Work in Progress, March 2004.
[OSPF-2547-DNBIT] 「BGP/MPLS IP VPNsで輪にするのを防ぐのにLSAオプションビットを使用し」て、ローゼン、E.、Psenak、P.、およびP.Pillay-Esnaultは進行中(2004年3月)で働いています。
[TCP-MD5] Heffernan, A., "Protection of BGP Sessions via the
TCP MD5 Signature Option", RFC 2385, August 1998.
[TCP-MD5] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[VPN-MCAST] Rosen, E., Cai, Y., and J. Wijsnands, "Multicast in
MPLS/BGP VPNs", Work in Progress, May 2004.
[VPN-MCAST] ローゼン、E.、Cai、Y.、およびJ.Wijsnands、「MPLS/BGP VPNsのマルチキャスト」が進歩、2004年5月に働いています。
[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF
as the PE/CE Protocol in BGP/MPLS VPNs", Work in
Progress, February 2004.
[VPN-OSPF]ローゼン、E.、P.、およびP.Pillay-Esnault、「BGP/MPLS VPNsのPE/CeプロトコルとしてのOSPF」というPsenakは進行中(2004年2月)で働いています。
Authors' Addresses
作者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
マサチューセッツ通りBoxborough、エリックC.ローゼンシスコシステムズInc.1414MA 01719
EMail: erosen@cisco.com
メール: erosen@cisco.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
ヤコフRekhter Juniperは1194N.マチルダ・Avenueサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: yakov@juniper.net
メール: yakov@juniper.net
Rosen & Rekhter Standards Track [Page 46] RFC 4364 BGP/MPLS IP VPNs February 2006
ローゼンとRekhter規格はBGP/MPLS IP VPNs2006年2月にRFC4364を追跡します[46ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rosen & Rekhter Standards Track [Page 47]
ローゼンとRekhter標準化過程[47ページ]
一覧
スポンサーリンク
