Network Working Group E. Rosen
Request for Comments: 4364 Cisco Systems, Inc.
Obsoletes: 2547 Y. Rekhter
Category: Standards Track Juniper Networks, Inc.
February 2006
BGP/MPLS IP Virtual Private Networks (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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（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.
このドキュメントでは、サービスプロバイダが顧客のためにIP仮想プライベートネットワーク（VPN）を提供するために、IPバックボーンを使用することができますする方法を説明します。この方法は、顧客のエッジルータ（CEルータ）がサービスプロバイダーのエッジルータ（PEルータ）へのルートを送信する「ピア・モデル」を使用します。そこに顧客のルーティングアルゴリズムには見えない「オーバーレイ」はなく、異なるサイトのCEルータは、相互にピアはありません。コアルータは、VPNルートを知っている必要はありませんように、データパケットは、バックボーンを介してトンネリングされています。
This document obsoletes RFC 2547.
この文書はRFC 2547を廃止します。
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
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.
このドキュメントでは、サービスプロバイダが顧客のためにIP仮想プライベートネットワーク（VPN）を提供するために、IPバックボーンを使用することができますする方法を説明します。この方法は、顧客のエッジルータ（CEルータ）がサービスプロバイダーのエッジルータ（PEルータ）へのルートを送信する「ピア・モデル」を、使用しています。ボーダーゲートウェイプロトコル（BGP）BGP、BGP-MP]は、そのVPNに接続されているPEルータの間で特定のVPNのルートを交換するためにサービス・プロバイダによって使用されます。これは、2つのVPNが重なったアドレス空間を持っている場合でも、異なるVPNからのルートは異なる別個のままであることを保証した方法で行われます。 PEルータはそのVPNの他のCEルータからのルート、特定のVPNの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.
VPNは、マルチプロトコルラベルスイッチング（MPLS）MPLS-ARCH、MPLS-BGP、MPLS-ENCAPS]ラベルが割り当てられている内の各経路; BGPは、VPNルートを配布するとき、それはまた、そのルートのMPLSラベルを配布しています。顧客データパケットがサービスプロバイダのバックボーン上を移動する前に、パケットの宛先アドレスにベストマッチであるルートに、顧客のVPNに、対応MPLSラベルでカプセル化されます。これは、パケットがさらにカプセル化されているMPLS（例えば、別のMPLSラベルまたはIPまたは汎用ルーティングカプセル化（GRE）トンネルヘッダで[MPLS-で-IP-GRE]）は、それが適切な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.
この方法の主な目的は、クライアントが、それは契約関係を保持しているサービスプロバイダやサービスプロバイダからIPバックボーンサービスを取得する場合をサポートすることです。クライアントは、企業、エクストラネット、インターネットサービスプロバイダー、アプリケーションサービスプロバイダは、この方法は、それを作るなど、独自のの顧客にVPNを提供するために、この同じメソッドを使用する別のVPNサービスプロバイダを必要とする企業の基であってもよいですバックボーンサービスを使用するクライアントのための非常にシンプル。また、サービスプロバイダーのための非常にスケーラブルで柔軟性があり、サービスプロバイダーが値を追加することができます。
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.
私たちは「バックボーン」と呼ぶ共通のネットワークに接続されている「サイト」のセットを考えてみましょう。 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.
これらのサブセットは、仮想プライベートネットワーク（VPN）です。それらの両方が含まれているいくつかのVPNがある場合のみ二つのサイトは、共通のバックボーン上でIP接続を持っています。共通にはVPNを持たない二つのサイトがそのバックボーン上で何の接続性を持っていません。
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は「エクストラネット」と考えることができます。サイトが複数のVPNにすることができ、例えば、イントラネットおよびいくつかのエクストラネットです。私たちは用語「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.
顧客は単一の企業など、企業の集合、インターネットサービスプロバイダー、アプリケーション・サービス・プロバイダ、独自の顧客に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番目のサイトを経由してルーティングすることがサイトの特定のペア間のトラフィックを強制することができます。サイトのペア間のトラフィックがファイアウォールを通過することが望まれ、ファイアウォールは、第3のサイトに配置されている場合、これは、例えば、有用であり得ます。
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サービスを購入する、またはVPNサービスを提供するために協力することに合意しているのSPのセットからされている場合に我々の議論を制限します。これは、顧客が単に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.
我々はまた、例えば、フレームリレー、非同期転送モード（ATM）などのレイヤ2サービス、イーサネット、ハイレベルデータリンク制御（HDLCをバックボーンには、顧客へのIPサービスを提供する場合に我々の議論を制限するのではなく、 ）、またはポイントツーポイントプロトコル（PPP）。お客様は、これらの（または他の）レイヤ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.
この導入の残りの部分では、我々は、VPNが持つべきいくつかのプロパティを指定します。この文書の残りの部分は、これらすべての特性を有するVPNモデルを提供するために展開することができる機構の集合を指定します。このセクションでは、文書の残りの部分で使用される技術用語のいくつかを紹介します。
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.
GREトンネルは、イーサネットインターフェイス上でPPP接続、ATM仮想回線（VCS）、フレームリレーのVC、イーサネットインターフェイス、仮想ローカルエリアネットワーク（VLAN）：ルータはお互いに取り付けることができる、またはシステムを終了するには、様々な異なる方法で、レイヤ2トンネリングプロトコル（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サイトは、一つ以上のカスタマーエッジ（CE）デバイスが含まれている必要があります。各CEデバイスは、1つまたは複数のプロバイダエッジ（PE）ルータに、アタッチメント回路のある種を介して、取り付けられています。
Routers in the SP's network that do not attach to CE devices are known as "P routers".
CEデバイスに接続していないSPのネットワーク内のルータは、「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デバイスは、ホストまたはルータことができます。典型的なケースでは、サイトは、PEルータに接続されているいくつかは、1つまたは複数のルータを含んでいます。 PEルータに接続し、サイトのルータは、CEデバイス、または「CEルータ」になります。しかし、ホストは、CE機器であろうその場合、PEルータに直接付着する非ルーティングホストを防止するものは何もありません。
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のインフラストラクチャは、マルチポイントサービスを提供する場合は、複数のCEデバイスが同一の接続回線上のPEルータに取り付けることができます。
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デバイスにアクセスするために必要とされます。
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.
2つのVPNが共通で何のサイトを持っていない場合は、それらは、重複アドレス空間を持つことができます。すなわち、完全に異なるシステムS2のアドレスとして、システムS1のアドレスとしてではなく、VPN V2にVPN V1に使用されるかもしれない与えられたアドレスです。 VPNのそれぞれがRFC 1918プライベートアドレス空間を使用するとき、これは一般的な状況です。もちろん、各VPN内では、各アドレスは明確なでなければなりません。
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.
共通のサイトを持っていても2つのVPNは限り共通のサイトでこのようなアドレスやシステムとのシステム間のすべての通信のための必要がないよう、重複アドレス空間を持つことができます。
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.
サイトが複数のVPNであってもよいが、必ずしもそのサイトの所与のシステムへのルートがすべてのVPNで同じでなければならない場合ではありません。例えば、我々は、サイトAのサーバがあることを仮定し、A、B、およびCのサイトからなるイントラネット、およびA、B、Cからなるエクストラネット、および「外来」サイトD.を持っている、と仮定し、我々 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のサイトで使用される一つの経路は、それは次に表示され、ファイアウォールは、トラフィックを通過させる場合はサイトBでファイアウォールに代えてトラフィックをとり、サイトAに直接サイトDによって使用される第2の経路を、トラフィックを取りトラフィックは、サイトBから来る、とサイトAへの経路をたどることにします
The SP's backbone consists of the PE routers, as well as other routers ("P routers") that do not attach to CE devices.
SPのバックボーンはCEデバイスに接続していないPEルータだけでなく、他のルータ（「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でサポートされているすべてのVPNのルーティング情報を維持しなければならなかった場合、深刻なスケーラビリティの問題が存在することになります。サポートできるサイトの数は、単一のルータで開催することができ、ルーティング情報の量によって制限されるだろう。これは、特定のVPNについてのルーティング情報のみをそのVPNに接続PEルータに存在する必要があることが重要です。具体的には、Pルータは一切あたり-VPNルーティング情報を持っている必要はありません。 （この条件は、マルチキャストルーティングを考慮すると、幾分緩和される必要があるかもしれない。これは、この論文ではさらに考慮されていないが、[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の所有者が管理するためのバックボーンまたは「仮想バックボーン」を持たないようにだけ、のSP自体は、各VPNのために管理するには、別のバックボーンまたは「仮想バックボーン」を持っていません。バックボーンにおけるサイト間のルーティングは、（VPNを形成するために使用されるポリシーの制約内で）が最適であるとトンネルの人工的な「仮想トポロジー」でどのような方法で制約されません。
Section 10 discusses some of the special issues that arise when the backbone spans several Service Providers.
セクション10は、バックボーンは、いくつかのサービスプロバイダにまたがる場合に生じる特殊な問題のいくつかを説明します。
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.
ここで議論されている種類のVPNは、さらに暗号化セキュリティ対策を使用することなく、レイヤ2バックボーン（例えば、フレームリレー）を使用する場合に得られるとセキュリティと同等のレベルを提供することを意図しています。つまり、設定ミス又は異なるVPNの意図的な相互接続が存在しない場合に、別のVPN内のシステムへのアクセスを得るために、1つのVPN内のシステムのために不可能です。もちろん、本明細書に記載の方法は、自分でプライバシーのためにデータを暗号化せず、また、データが途中で改ざんされているかどうかを判断するための方法を提供します。これを希望する場合は、暗号化の対策はほかに適用されなければなりません。 （参照、例えば、[MPLS / BGP-のIPsec]。）セキュリティは、セクション13でより詳細に説明します。
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相互接続性を持っている場合、特定のバックボーンネットワークの観点から、IPシステムのセットは、「サイト」とみなすことができます。一般的には、サイトが地理的に近接しているシステムのセットで構成されます。しかし、これは普遍的真実ではありません。 2つの地理的位置は、オープンショーテストパスファースト（OSPF）プロトコル[OSPFv2の]が実行されている上に専用線を介して接続され、その行は、2つの位置の間で通信する好ましい方法である場合、2つの位置は、とみなすことができる場合単一のサイト、それぞれの場所には独自のCEルータを持っている場合でも。 （「サイト」のこの概念は位相的ではなく、地理的です。専用線がダウンした、またはそれ以外の場合は、優先ルートでなくなるが、二つの地理的な位置は、VPNバックボーンを使用して通信を継続することができ、その後、1つのサイトはなってきた場合二。）
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.
（我々は3.2節で見るように、サイトは複数の「仮想サイト」から構成されてもよいが）CEデバイスは常に単一のサイトであると見なされます。このサイトは、しかし、複数のVPNに属していてもよいです。
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デバイスが同じまたは異なるVPNにあるかどうか、異なるサイトの任意の数からCEデバイスに取り付けることができます。 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 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つのまたは複数のエクストラネットのメンバーであってもよいです。しかし、このサイトは、バックボーン、イントラネット用とエクストラネットのための一から二の接続回線を持っている必要があります。それはさらにファイアウォール機能は、エクストラネット接続回線に適用することが必要な場合があります。
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ルーティングおよび転送テーブル」、または「のVRF」です。
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アタッチメント回路は、一の以上のVRFと、コンフィギュレーションによって、関連付けられています。 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アタッチメント回路は、正確に一つのVRFに関連付けられています。 IPパケットは、特定の接続回線を介して受信された場合、その宛先IPアドレスが関連付けられたVRF内で検索されます。その検索の結果はどのようにパケットをルーティングすることを決定し。特定のパケットをルーティングするためのパケットの入口PEによって使用されるVRFは、パケットの「入口VRF」として知られています。 （パケットの出力PEにあるパケットの「出口のVRF」、という考え方もあります。これは、第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ルータからのパケット、並びにのVRFに関連付けられていない顧客向け接続回線からのパケットを含みます。
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".
直感的に、一つは「プライベートルート」を含むように、とのVRFの「パブリックルート」を含むように、デフォルトの転送テーブルと考えることができます。一つは、同様に「パブリック」として「プライベート」であるとして、非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 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.
特定のVRFの接続回線は、PEルータにサイトSを接続した場合、S（その接続回線を介して）からの接続は、対応するVRFに入力されますルートのセットを制御することによって制限することができます。そのVRF内のルートのセットは、VRFの接続回線上Sから送信されたパケットのみを別のサイトにPEによってルーティングすることができるS.で少なくとも1つの共通のVPNを有する部位に至る経路のセットに限定されるべきです「Sがあれば」であるS.同じVPNのいずれかにあるSは、（PEルータを介して）通信は、共通にはVPNを持たないVPNサイトの任意のペアの間に防止されます。 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の接続を制限するSからトラフィックをルーティングするために使用することができる複数のVRFがある可能性があり、経路の同じセットが、全てに存在しなければなりませんVRF。あるいは、その場合、S.異なる接続回線上の異なる接続制限を課すことができ、Sから接続回線に関連付けられたVRFの一部は、他のいくつかよりも経路の異なるセットを含むであろう。
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の一組のではなく、単一のVRFに関連付けられた場合を許します。顧客のパケットの一部の特性はサブVPNの中から選択するために使用されるいくつかの「サブVPN」を、異なる接続制限のそれぞれに単一のVPNを分割することが望まれる場合に有用であり得ます。しかし簡単にするために、我々は通常、単一のVRFに関連するものとして接続回線の話をします。
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（またはVRFのセット）を決定するように、それは、パケットが到着した上接続回線を決定しなければなりません。一般的に、パケットが到着した上接続回線を決定するために、PEルータは、パケットが到着する物理インタフェースのメモを取り、そしておそらく、パケットのレイヤ2ヘッダのいくつかの側面に留意します。パケットの中のパケットの入口接続回線がフレームリレーVCである場合、例えば、接続回線の識別は、データリンク接続識別子と共に、パケットが到着する物理フレームリレーインターフェースから決定することができる（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.
特定のパケットが特定の接続回線に到着したことをPEの結論は、部分的にパケットのレイヤ2ヘッダーによって決定することができるが、それであることが確認されたパケットを考えることにSPをだますために、ヘッダフィールドを書き込むことによって、顧客のために不可能である必要があります本当に別のものの上に到着した1つの接続回線を介して受信。接続回線は、フレームリレーヘッダーのDLCIフィールドの検査によって部分的に決定されるが、上記の例では、このフィールドは、顧客が自由に設定することができません。
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は、そのサイトからのパケットをルーティングし、顧客は、次にセットから特定のVRFを選択するために使用されるパケットのいくつかの特性を設定することを可能にするために使用されるの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の値が特定のVRFを識別するために使用されることに同意することができます。彼らは合意されたセットに含まれていないVLANタグの値を運ぶ場合はもちろん、そのCEからのパケットは、PEによって廃棄されます。これを達成するもう一つの方法は、IP送信元アドレスを使用することです。この場合、PEは、特定のVRFにパケットを割り当てるために、パケットのIPソースアドレスがパケットを受信した上インターフェイスとともに、CEから受信した使用します。ここでも、顧客はその顧客が使用を許可されていることのVRFの特定のセットの中から選択することができるであろう。
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.
それは特定のホストが複数の仮想サイトであることが望まれる場合、そのホストがパケットが関連付けられている仮想サイト各パケットのために、決定しなければなりません。それは、例えば、異なるVLAN上の異なる仮想サイトからのパケットを送信することにより、または異なるネットワーク・インタフェースから、これを行うことができます。
With what set of routes are the VRFs populated?
ルートの設定したものでVRFが移入されますか？
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.
一例として、PE1、PE2、PE3および三台のPEルータであるとすると、CE1、CE2、CE3及び三台のCEルータとします。 PE1はCE1、CE1のサイトで到達可能なルートから、学習しているとします。 PE2及びPE3がCE2およびCE3に、それぞれ取り付けられ、CE1、CE2及びCE3を含むいくつかのVPN Vが存在する場合、PE1はPE2及びPE3には、CE1から学習した経路を配布するためにBGPを使用します。 PE2とPE3は、彼らがCE2とCE3のサイトと、それぞれ関連付けることVRFを移入するためにこれらのルートを使用します。 VPN Vに含まれていないサイトからのルートはCE2やCE3からのパケットがVPN Vにないサイトに送信することができないことを意味し、これらのVRFには表示されません。
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からルートを「学習」と言うことと、詩のライセンスのビットを行使するためにおそらくあります。）
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.
PEはまた、他のPEから、特定のVPNに所属するルートを学習する必要があります。経路の適切なセットでVRFを移入するために使用される手順は、セクション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ルータから先頭の複数の接続回線がある場合、それらはすべて同じ転送テーブルにマップされている可能性があります。しかし、政策のおもむくままならば、それらは異なるフォワーディングテーブルにマッピングすることができます。例えば、ポリシーは、そのサイトから別の接続回線のみエクストラネットトラフィックのために使用されるサイトから特定の接続回線は、のみイントラネットトラフィックに使用されていることかもしれません。この場合、2つの接続回線は、異なるVRFに関連付けられているであろう（イントラネットアタッチメント回路に取り付けられたCEはされない。おそらく、例えば、エクストラネット接続回線に取り付けられたCEは、ファイアウォールです）。
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が他の上に受信パケットとして宛先の全く同じセットに到達することができるであろうことに留意されたいです。他方であるように、各CEは、VPNのまったく同じセット内にある場合を除きので、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.
アタッチメント回路は、複数のVPNにあるサイトにつながる場合は、接続回線がまだVRFは、サイトがメンバーであるVPNのフルセットからのルートを含んでなる場合には、単一のVRFに関連付けられてもよいです。
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経路が互いに分散させるために、より正確に）互いにVPNルートを配布するためにBGPを使用します。
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は、与えられたアドレスが異なるVPNで異なるシステムを示すことができることを意味し、独自のアドレス空間を持つことができます。同じIPアドレスのプレフィックスへの2つのルートが実際に異なるシステムへのルートであれば、BGPが同等として扱うないことを確認することが重要です。そうでなければ、BGPは、他のシステムが到達不能になって、そのうちの一つだけをインストールすることもできます。さらに、我々は、ポリシーがどのルートに送信されますどのパケットを決定するために使用されていることを確認する必要があります。そのようないくつかのルートがBGPによってインストールされていることを考えると、一つだけ、そのような任意の特定のVRFに表示されなければなりません。
We meet these goals by the use of a new address family, as specified below.
下記の指定された私たちは、新しいアドレスファミリを使用することで、これらの目標を達成します。
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マルチプロトコル拡張[BGP-MP]はBGPは、複数の「アドレスファミリー」からのルートを運ぶことができます。私たちは、「VPN-IPv4アドレスファミリー」の概念を導入します。 VPN-IPv4アドレスは8バイトのルート識別子（RD）で始まる4バイトのIPv4アドレスで終わる、12バイトの量です。複数のVPNが同じIPv4アドレスのプレフィックスを使用する場合、PEはユニークなVPN-IPv4アドレスのプレフィックスにこれらを翻訳します。これは、同じアドレスは、いくつかの異なるVPNに使用されている場合、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は、単に数であり、それは、任意の固有の情報が含まれていません。それがルートまたはルートを配布先となるVPNのセットの起源を識別しません。 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の一部が、別のRDを有する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は、他のサービスプロバイダによって行われたRDの割り当てと競合することなく、（すなわち、のRDの独自の割り当てを行うことができます）構成されています。 2バイトのタイプフィールド、管理者フィールド、および割り当てられた番号フィールド：RDは、三つのフィールドで構成されています。タイプフィールドの値は、他の2つのフィールドの長さ、ならびに管理者フィールドのセマンティクスを決定します。管理者の欄には、割り当てられた番号の権限を識別し、割り当てられた番号フィールドは、特定の目的のために、識別権威によって、割り当てられた番号が含まれています。例えば、一つはその管理者フィールド自律システム番号（ASN）とが含まれているRDを有することができる（4バイト）番号フィールドは、そのASNを（によりそのSPに割り当てられた所属誰に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 needs to do so. However, the structure is not meaningful to BGP; when BGP compares two such address prefixes, it ignores the structure entirely.
RDSは、それはそうする必要があるときにVPNバックボーンサービスを提供してSPは常にユニークなRDを作成できることを確実にするために、この構造を与えられています。しかし、この構造は、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に関連付けされる可能性があり、またはそれは、彼らが同じCEにつながる場合でも、異なる経路が異なるのRDに関連付けされる可能性があります。
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バイトのルート識別子で構成されています。次のようにRDSはエンコードされます。
- Type Field: 2 bytes - Value Field: 6 bytes
- タイプフィールド：2バイト - 値フィールド：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フィールドの解釈は、タイプフィールドの値に依存します。 1,0、および2：現時点で、タイプフィールドの3つの値が定義されています。
- Type 0: The Value field consists of two subfields:
- タイプ0：Valueフィールドは、2つのサブフィールドで構成されています。
* Administrator subfield: 2 bytes
* Assigned Number subfield: 4 bytes
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.
管理者のサブフィールドは、自律システム番号が含まれている必要があります。このASNは、公共ASNスペースからのものである場合、それは適切な権威によって割り当てられている必要があります（プライベートASN空間からASN値の使用を強くお勧めします）。割り当てられた番号サブフィールドは、ASNは、適切な権限によって割り当てられている企業によって投与されるナンバリング空間から番号を含みます。
- Type 1: The Value field consists of two subfields:
- タイプ1：Valueフィールドは、2つのサブフィールドで構成されています。
* Administrator subfield: 4 bytes
* Assigned Number subfield: 2 bytes
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.
管理者のサブフィールドには、IPアドレスが含まれている必要があります。このIPアドレスは、パブリックIPアドレス空間からのものである場合、それは適切な権威によって割り当てられている必要があります（プライベートIPアドレス空間からアドレスの使用を強くお勧めします）。割り当てられた番号のサブフィールドには、IPアドレスが割り当てられている企業によって管理された番号空間から番号が含まれています。
- Type 2: The Value field consists of two subfields:
- タイプ2：Valueフィールドは、2つのサブフィールドで構成されています。
* Administrator subfield: 4 bytes
* Assigned Number subfield: 2 bytes
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.
管理者のサブフィールドは、4バイト自律システム番号[BGP-AS4]を含んでいなければなりません。このASNは、公共ASNスペースからのものである場合、それは適切な権威によって割り当てられている必要があります（プライベートASN空間からASN値の使用を強くお勧めします）。割り当てられた番号サブフィールドは、ASNは、適切な権限によって割り当てられている企業によって投与されるナンバリング空間から番号を含みます。
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内の特定のCEに取り付けられることによって）特定のVPNに接続されている場合、それは、添付の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アドレスのプレフィックスに複数のルートがある場合は、BGPは、BGP決定プロセスを使用して、一つの「最高」を選択します。そのルートは、それについて知る必要がある他のPEのセットにBGPで配布されています。これらの他のPEでは、BGPは再び、特定のVPN-IP4アドレス接頭語のための最適なルートを選択します。次いで、選択されたVPN-IP4ルートは、一の以上のVRFへのIPルートに逆変換、および「インポート」されています。それらは実際のVRFにインストールされているかどうかPE、問題のVRFに関連付けられているもののCE間で使用されるルーティング方法の決定プロセスに依存します。最後に、VRFにインストールされたルートは、関連するCEルータに分配することができます。
Every VRF is associated with one or more Route Target (RT) attributes.
すべてのVRFは、一つ以上のルートターゲット（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ルートから）作成されたとき、それは、一つ以上と関連しています
Route Target attributes. These are carried in BGP as attributes of the route.
ルートターゲット属性。これらは、ルートの属性として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.)
そのような経路がPEルータによって受信されるとルートターゲットTに関連する任意のルートがルートターゲットT.関連付けられたVRFを有するすべてのPEルータに配布する必要があり、関連していることPEののVRFのものにインストールの対象でありますルートターゲットTと（それが実際にインストールされるかどうかはBGP決定プロセスの結果に依存し、PE / CEインターフェイス上で実行されているIGP（すなわち、ドメイン内ルーティングプロトコル）の決定プロセスの結果に依存します。 ）
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.
ルートターゲット属性は、サイトのセットを特定するものと考えることができます。 （ただし、それはのVRFのセットを識別すると考えるのがより正確であろう。）特定のルートターゲットは、ルートの属性の関連付けは、そのルートが対応する部位から受信されるトラフィックをルーティングするために使用されるのVRF内に配置されることを可能にします。
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から受信した経路にアタッチルートターゲットのセットがあります。これらは、「エクスポートターゲット」と呼ばれることもあります。そして、PEルータがルートサイトSに関連付けられたVRF内に配置することができる別のPEルータから受信したか否かを決定するために使用するルートターゲットのセットがあります。これらは、「インポートターゲット」と呼ばれることもあります。二組は区別され、同じである必要はありません。ルートのルートターゲットの一つとVRFのインポート目標の一つでもあり、いくつかのルートターゲットがある場合、特定のVPN-IPv4ルートが特定のVRFでのインストールのためだけに資格があることに注意してください。
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.
ルートターゲットの属性によって実行される機能は、BGPコミュニティ属性によって行われたものと同様です。それだけで2バイトの番号空間を可能にするので、後者の形式は、本発明の目的のためには不十分です。タイプフィールドは、管理者フィールドの長さを規定するように、我々はRDS（セクション4.2を参照）について記載したものと同様のフォーマットを、構造化することが望ましい、と属性の残りの部分は、指定された管理者の番号空間から数であります。これは、BGP拡張コミュニティを使用して行うことができます。本明細書で説明ルートターゲットは、BGP拡張コミュニティルートターゲット[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プレフィクスに複数の経路を受信した場合、ルートの嗜好のBGPルールは、BGPによってインストールされたVPN-IPv4の経路を選択するために使用されます。
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 could eliminate the Route Target attribute by creating more routes (i.e., using more RDs), but the scaling properties would be less favorable.
ルートは唯一のRDを持つことができることに注意してください、それは、複数のルートターゲットを持つことができます。一つは複数の属性を持つ単一のルートを有する場合、複数の経路とは対照的に、BGPにおいて、スケーラビリティが向上します。一つは（すなわち、より多くのRDを使用して）複数のルートを作成することにより、ルートターゲット属性を排除することができるが、スケーリング特性はあまり良好であろう。
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は、ルートターゲットは、所定のルートに関連付ける属性を決定していますか？異なる可能ないくつかの方法があります。 PEは、指定したルートターゲットで指定されたサイトにつながるすべてのルートを関連付けるように構成されることがあります。またはPEは、一つのルートターゲットと指定されたサイトにつながる特定のルートを関連付けるように構成され、かつ互いに一定のかもしれません。
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ルートに添付することが許可されているRTのセットに事前に同意する必要があります。 CEは、それはPEに分配する各IPルートにそれらのRTの一つ以上を付けることができました。これは、顧客に合意した限度、そのルートの配布ポリシーの中、リアルタイムで指定する自由を与えます。 CEはそのルートにのRTを付着させている場合は、PEは、顧客が使用を許可されていないのRTが含まれているすべてのルートをフィルタリングしなければなりません。 CEはそのルートにのRTを付着させ、とにかくそうされていない場合は、PEは、VPN-IPv4ルートに顧客のルートを変換する前にRTを削除する必要があります。
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つのサイトが同じ自律システムにあるPEに取り付ける場合、PEは、それらの間のIBGP接続によって相互にVPN-IPv4ルートを配布することができます。 （用語「IBGP」は、同じ自律システム内の2つのBGPスピーカ間のBGP接続がある場合に使用されるプロトコルおよび手順のセットを指す。これは、異なる二つのBGPスピーカとの間に使用される手順のセットを「EBGP」と区別されます自律システム）あるいは、それぞれがルートリフレクタ[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]が次のホップアドレスはネットワーク層到達可能性情報（NLRI）と同じアドレスファミリーであることを必要とする。）と、このアドレスは符号化されているまた、割り当てとが配信MPLSラベル。 （本質的には、PEルータはVPN-IPv4ルートない配布が、標識されたVPN-IPv4経路。Cfと[MPLS-BGP]。）PEは、スタックの最上部にこのラベルを有する受信したパケットを処理するとき、PEがポップアップ表示されますスタック、および適切なパケットを処理します。
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に表示されたルートの正確なセットを配布することができ、またはそれは、集約を実行し、それらのルートの凝集物を分配することができる、またはそれは一方及び他方の一部の一部を行うことができます。
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内のルートの集合の集合体である場合には、PEは、このラベルで到着バックボーンからのパケットが宛先アドレスがVRFに見上げていなければならないことを知っているだろう。 PEは、そのラベル情報ベースにラベルを検索する場合は、VRFを使用する必要がある学習します。 Rが集合でない場合は、PEラベルを調べたときに他方、その後、それは、出力アタッチメント回路、ならびに、パケットのカプセル化ヘッダを学習します。この場合は、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内のパケットのIP宛先アドレス（パケットの「出口のVRF」）をルックアップする必要があります。
- 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.
- 単一のラベルが同じ「発信接続回線」を持つすべての経路によって共有されるように、一つは、各接続回線のために単一のラベルを有するように選択することができます。検索のいくつかの並べ替えは、データリンクのカプセル化、例えば、アドレス解決プロトコル（ARP）のルックアップを決定するために行われる必要があるかもしれませんが、これは、出口VRF内のルックアップを行うことを避けるために1つを可能にします。
- 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.
- 一つは、各ルートのための明確なラベルを持つように選択することができます。ルートは、複数の接続回線上の潜在的に到達可能である場合、PE / CEルーティングは、そのルートに新しいラベルを配布する必要があることなく、別の接続回線からのルートの優先パスを切り替えることができます。
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ラベルを使用して、我々は、そのようなラベルを運ぶMPLSパケットは、その経路のBGPネクストホップであるルータに対応するBGP-分散経路をインストールルータからトンネルすることができることを前提とします。これは、ラベルスイッチパスことのいずれかが必要（例えば、[MPLS-で-IP-GRE]）いくつかの他のトンネリング技術は、それらの間に使用することができることを他のものつのルータ間に存在しますか。
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.
このトンネルは、「ベストエフォート」のルートをたどること、またはそれは、トラフィックエンジニアリングの経路に従うことができます。ルータの所与の対の間で、そのようなトンネルがあってもよい、または多分サービス（QoS）の異なる品質特性を有する、いくつかが存在してもよいです。 VPNアーキテクチャのために重要なのは、このようないくつかのトンネルが存在することです。 MPLSラベルを使用して、このVPNアーキテクチャは、トンネリング技術としてパスを切り替える実装するシステム間の相互運用性を確保するために、すべてのそのようなシステムは、ラベル配布プロトコル（LDP）[MPLS-LDP]をサポートしなければなりません。 MUST特に、下流迷惑モードがいずれもATM（LC-ATM）を制御レーベル[MPLS-ATM]やレーベル制御フレームリレー（LC-FR）[MPLS-FR]インターフェースであるインターフェース上でサポートされなければならない、と需要モードのダウンストリームLC-ATMインターフェイス及びLC-FRインターフェイス上でサポートすることができます。
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.
それはルートリフレクタ（セクション4.3.3を参照のこと）またはインタープロバイダVPNのための自律システム境界ルータ（ASBR）（セクション10を参照）でない限り、それはでない限り、VPN-IPv4ルートをインストールするべきではないPEルータルートのルートターゲット属性のものと同一のインポート先との少なくとも1つのVRF。インバウンドフィルタリングは、このようなルートが破棄させるために使用する必要があります。新しいインポートターゲットが後PEののVRFの一つ（「VPN参加」操作）に追加された場合、それはそれが以前に破棄されたかもしれないルートを取得しなければなりません。これは、[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.
特定のインポート対象は、もはやPEのVRFの（1つまたは複数の「VPNプルーン」オペレーションの結果として）のいずれかに存在する場合に同様に、PEは、結果として、もはやのいずれかを有し、すべてのルートを破棄しなくてもよいですそのルートターゲット属性の一つとして、PEのVRFのインポートターゲット。
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に接続されていないし、それがルートリフレクタ（即ち、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参加ことに注意してくださいとプルーンの操作は無停止であり、限り[BGP-RFSH]のリフレッシュメカニズムが使用されているように、倒さなければ任意のBGP接続を必要としません。
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は、これまでのすべてのVPNのすべてのルートを維持する必要がありません。これは重要なスケーラビリティの考慮事項です。
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.
むしろ完全IBGPは、PEの間でメッシュを有するよりも、スケーラビリティを向上させるためにBGPルートリフレクタ[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.
ルートリフレクタは、それらが直接結合していないVPNへのルーティング情報を持っている必要がある唯一のシステムです。しかし、いずれかのルートリフレクタがバックボーンでサポートされているすべてのVPNのすべてのVPN-IPv4ルートを知る持ってする必要はありません。
We outline below two different ways to partition the set of VPN-IPv4 routes among a set of route reflectors.
我々は、ルートリフレクタのセット間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.各ルートリフレクタは、ルートターゲットのリストをあらかじめ設定されています。冗長性のために、複数のルートリフレクタは、同じリストを事前設定することができます。ルートリフレクタは、インバウンドルートフィルタリングを構築するルートターゲットの事前設定されたリストを使用します。ルートリフレクタは（かかわらず、ピアが別のルートリフレクタまたはPEであるかどうかの）ピアのそれぞれにインストールするために、その事前設定済みのリストを含むアウトバウンドルートフィルタ（のORF）のセットを[BGP-ORF]の技術を使用することができますルートターゲット。ルートリフレクタは、他のルートリフレクタのORFの機能をアドバタイズする必要があることを意味し、他のルートリフレクタからの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 reflectors that are (pre)configured with this Route Target.
サービスプロバイダは、ルートリフレクタに事前設定されたルートターゲットのリストを変更することがあります。これが行われると、ルートリフレクタは、そのIBGPピアのすべてにインストールするORFを変更します。ルートリフレクタの設定変更の頻度を減らすために、各ルートリフレクタは、ルートターゲットのブロックに事前設定することができます。新しいルートターゲットを新しいVPNのために必要とされる場合、この方法は、（事前に）、このルートターゲットで構成された1つ以上のルートリフレクタはすでに存在します。
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.
所与のPEは、すべてのルートリフレクタのクライアントでない限り、新しいVPNがPE（「VPN参加」）に追加されたとき、それはそのVPNのルートを維持するルートリフレクタ（単数または複数）のクライアントになる必要があります。同様に、PE（「VPNプルーン」）から既存のVPNを削除すると、PEは、もはや一部のルートリフレクタ（単数または複数）のクライアントする必要がある状況をもたらし得ます。いずれの場合も、参加やプルーンの動作は非破壊的である（限り、[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.)
（「PEに新しいVPNを追加すること」によって、我々は本当に、そののVRFの一つに新しいインポートルートターゲットを追加する、またはPEの他のVRFのいずれによっても持っていない、インポートルートターゲットを持つ新しい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がルートリフレクタのサブセットのクライアントであることです。ルートリフレクタは、ルートターゲットのリストを事前設定されていない、とそのクライアント（PES）から受信したルートのインバウンド経路フィルタリングを実行しません。むしろ、それは、そのクライアント（PES）の全てから受信したすべてのルートを受け入れます。ルートリフレクタは、それが受信するすべてのルートによって運ばれるルートターゲットのセットを追跡します。ルートリフレクタは、そのクライアントこのセットにはないルートターゲットのルートから受信した場合、このルートターゲットは直ちにセットに追加されます。一方、ルートリフレクタがもはやセットに含まれる特定のルートターゲットを持つ任意のルートを有する場合、ルートリフレクタは（数時間まで）セットから、このルートターゲットの削除を遅らせるべきではありません。
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.
ルートリフレクタは、それが他のルートリフレクタから受信したルートに適用されるインバウンドルートフィルタを形成するために、このセットを使用します。ルートリフレクタは、他のルートリフレクタ上の適切なアウトバウンドルートフィルタリングをインストールするためのORFを使用してもよいです。ちょうど最初のアプローチと同様に、ルートリフレクタは、他のルートリフレクタからのORFを受け入れるべきです。これを達成するために、ルートリフレクタは、他のルートリフレクタに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 the set, the route reflector, after changing its inbound route filtering, must issue BGP Refresh to other route reflectors.
ルートリフレクタが設定を変更すると、それはすぐにそのインバウンドルートフィルタリングを変更する必要があります。ルートリフレクタは、ORFのを使用する場合に加えて、その後のORFは直ちにセットの変更を反映するように変更されなければなりません。ルートリフレクタはのORFを使用していない、と新しいルートターゲットがセットに追加されている場合は、ルートリフレクタは、そのインバウンドルートフィルタリングを変更した後、他のルートリフレクタにBGP更新を発行する必要があります。
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を有する経路上に保持するためのルートリフレクタを可能にします。これは、クライアントの 『失踪』は一時的なものであれば、すべてのそのような経路を再取得する必要性から保護します。
With this procedure, VPN Join and Prune operations are also non-disruptive.
この手順で、VPNが参加し、プルーン操作も無停止されています。
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は、そのエクスポートルートターゲットの一つではないインポートルートターゲットと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「自動発見」は、同じVPNに接続他のPEに付着PEルータ。新しい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ルートを知る必要がない1つのPEルータが存在しないのと同様に、これらの分布規則は上にサポートされているすべてのVPN-IPv4ルートを知る必要が誰ルートリフレクタ（RR）がないことを確認します背骨。その結果、主鎖上に支持することができるそのような経路の総数は、任意の単一デバイスの容量によって囲まれていないので、際限なく事実上増加させることができます。
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マルチプロトコル拡張[BGP-MP]はNLRIを符号化するために使用されます。アドレスファミリ識別子（AFI）フィールドが1に設定され、次のアドレスファミリ識別子（SAFI）フィールドが128に設定されている場合、NLRIはMPLS標識VPN-IPv4アドレスです。 NLRIに関連付けられたネットワーク層プロトコルは依然としてIPであるので、AFI 1が使用されます。この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機能広告を使用しなければなりません。 1のAFIと128のSAFIと、機能コード1（マルチBGP）を使用して、[BGP-MP]で指定されるように行われます。
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.
プレフィックスは、IPv4プリフィックスに続く8バイトのRDから成る[MPLS-BGP]で指定されるように標識されたVPN-IPv4のNLRI自体が符号化されます。
By setting up the Import Targets and Export Targets properly, one can construct different kinds of VPNs.
インポートとエクスポートターゲット目標を適切に設定することで、1は、VPNの種類を構築することができます。
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.
完全に噛合閉じたユーザグループ、すなわち、それぞれが相互に直接トラフィックを送信することができるサイトのセットを作成することが望まれると仮定するが、トラフィックを送信または他のサイトから受信することができません。各サイトはVRFに関連付けられて、単一経路目標属性がルートターゲットをインポート対象とエクスポートターゲットの両方として各VRFに割り当てられている、選択され、そしてルートターゲットは、いずれかのインポートのような任意の他のVRFに割り当てられていないことターゲットまたはエクスポートターゲット。
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のようなものを想定。これは、2つのルートターゲット値、1つの意味「ハブ」と1つの意味の「スポーク」を使用することによって行うことができます。ハブサイトに添付のVRFでは、「ハブは、」エクスポート対象で、
"Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target.
「スポークは、」インポート対象です。スポークサイトに添付のVRFでは、「ハブ」のインポートターゲットであるとエクスポート対象である「スポーク」。
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.
したがって、サイトの様々なセットの間でルーティング情報の配布を制御するための方法は、順番にVPNを構築する上で大きな柔軟性を提供する、非常に柔軟です。
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.
なお、この場合、一つの経路は、BGPによって分配されたと言うことができないにも関わらず、両方のVRFが同じPEにあっても、別のVRFからのルートを配布することが可能です。それにもかかわらず、単一のPE内の別のVRFから特定のルートを配布する決定は、のVRFが異なるのPEにあった場合に行われるであろう同じ決定です。つまり、ルートに割り当てられている（またはルートがBGPによって分配された場合に割り当てられる）ルートターゲット属性に依存して、であり、そして第二のVRFのインポート・ターゲット。
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?
バックボーンにおける中間ルータはVPNへのルートに関する情報を持っていない場合、どのように別の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を選択します。この選択は、パケットのイングレス付属回路に基づいています。
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.
パケットの次のホップは、このPEからVRF添付回路上に直接到達した場合（すなわち、パケットの出口接続回線は、その入口接続回線と同じ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にあるが、異なるVRFに関連付けられている場合、および最高の入口アタッチメント回路の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の接続回線を介して到達されていない場合、パケットは、バックボーンを介して、少なくとも1つのホップを移動しなければなりません。パケットは、このように、「BGPネクストホップ」を持っており、BGPネクストホップは最高のパケットの宛先アドレスと一致するルートのMPLSラベルを割り当てられています。 「VPNルートラベル」このラベルを呼び出します。 IPパケットは、ラベルスタック上の唯一のラベルとしてVPNルートラベルとMPLSパケットに変換されます。
The packet must then be tunneled to the BGP Next Hop.
その後、パケットはBGPネクストホップにトンネリングする必要があります。
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ルータ（および任意の自律システム境界ルータ）は、バックボーンのIGPルーティングテーブルに自身/ 32アドレスプレフィックスを挿入する必要があります。これは、各PEルータへのルートに対応するラベルを割り当てるために、バックボーンネットワーク内の各ノードで、MPLSを可能にします。異なる実装間の相互運用性を確保するためには、ラベルを設定するためのLDPをサポートバックボーン全体でパスを切り替えるために必要とされます。しかし、これらのラベルを設定する他の方法は、パスも可能で切り替えます。 （これらの他の方法のいくつかは、IGPに/ 32アドレスプレフィックスの存在を必要としないかもしれません。）
- 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つ以上が該当のパケットが使用可能である場合ならば、これらのトンネルの一つが選択されています。このトンネルは、MPLSラベル、「トンネルラベル」に関連付けられます。トンネルラベルは、MPLSラベルスタックにプッシュされ、パケットがトンネルのネクストホップに転送されます。
- Otherwise,
- そうでなければ、
* The packet will have an "IGP Next Hop", which is the next hop
along the IGP route to the 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ネクストホップとIGPネクストホップは同じであり、最後から二番目のホップポッピングが使用されている場合、パケットは、唯一のVPNルートラベルを運ぶ、IGPネクストホップに送信された場合。
* 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ネクストホップは最高のBGPネクストホップのアドレスと一致するルートのラベルが割り当てられています。この「トンネルラベル」コール。トンネルラベルはパケットのトップラベルとしてのプッシュされます。その後、パケットはIGPネクストホップに転送されます。
- MPLS will then carry the packet across the backbone to the BGP Next Hop, where the VPN label will be examined.
- MPLSは、VPNラベルを検討するBGPネクストホップにバックボーン間でパケットを運ぶでしょう。
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をサポートしていない場合、唯一のVPNルートラベルを運ぶMPLSパケットは、[MPLS-で-IP-GRE]の技術を使用して、BGPネクストホップにトンネリングすることができます。パケットがトンネルから出たとき、それはVPNルートラベルを検討するBGPネクストホップ、であろう。
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ネクストホップでは、パケットの治療は、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ヘッダ自体、及び/又はラベルに関連付けられた情報の情報は、また、CEへのインターフェイス上でQoSを提供するために使用され得ます。
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 scheme. The backbone does not even need to have routes to the CEs, only to the PEs.
VPNルートラベル付きパケットは、バックボーンを介してトンネリングされているという事実は、Pルータのうち、すべてのVPNルートを維持することを可能にするものです。これは、スキームの拡張性を確保するために不可欠です。バックボーンでも唯一のPEに、CEにルートを持っている必要はありません。
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 require that there be any explicit setup of the tunnels, either via signaling or via manual configuration;
- トンネルの明示的な設定は、シグナリングを介して、または手動設定のいずれかを介して、そこにあることを必要としません。
- DOES NOT require that there be any tunnel-specific signaling;
- 任意トンネル固有シグナリングが存在することを必要としません。
- 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.
- ルーティング情報を維持するために必要なものを超えて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.
特定のトンネリング技術の選択に関連する考慮事項は、この仕様の範囲外です。
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.
別のVPNの適切な分離を維持するために、そのトンネルの両方のエンドポイントがバックボーンの外にあることを確認しない限り、バックボーンには、ルータは、バックボーン外部からトンネリングされたパケットを受け入れないことが重要です。
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 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の条件は、バックボーンルータは、その最上位のラベルの下に見えることはありませんことを保証します。もちろん、これらの二つの条件を満たすための最も簡単な方法は、デバイスが非バックボーンデバイスからラベル付きパケットを受け入れることを拒否バックボーンを持っているだけです。
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がトンネリング技術として使用されていない場合は、フィルタリングがin-IP MPLS-またはMPLS-で-GREパケットは、パケットのIP宛先アドレスは、それが可能になります場合にのみ、バックボーンに受け入れられることを保証するために行われなければなりませんバックボーンの外に送りました。
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.
PEは、設定RDを使用して、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」です。ちょうど約すべての企業のエンタープライズネットワークを含むVPNの大半は、この意味での「スタブ」であることが予想されます。
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.スタティックルーティング（すなわち、構成）を使用することができます。 （これはスタブVPNのに有用である可能性が高いです。）
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は、PEルータにCEルータのサイトで到達可能なアドレスプレフィックスのセットを伝えるためにRIPを使用することができます。 RIPは、CEに構成されている場合、注意が（すなわち、PEルータからCEルータによって学習されたアドレスプレフィックス）がPEにアドバタイズされることはありません他のサイトからのアドレスプレフィックスを確保するために注意しなければなりません。より正確には：PEルータ場合、たとえば、PE1は、VPN-IPv4の経路R1を受信し、その結果がCEへのIPv4ルートR2を分配するように、その後、R2はたとえば、バックそのCEのサイトからPEルータに分配されてはなりません、PE2は、（PE1及びPE2は、同じルータまたは異なるルータであってもよい場合）とは異なるVPN-IPv4ルートにPE2マップR2ない限り、R1（すなわち、異なるRDを含んでいます）。
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ルータは、別個のVPN内にある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.
PEは、OSPFを介してCEから学習したIPv4ルートは、VPN-IPv4ルートとしてBGPに再配布されます。拡張コミュニティ属性は、ルートと一緒に、OSPFリンクステートアドバタイズメント（LSA）の適切なタイプでVPN内の他のCEルータに配布するためのルートを有効にするために必要なすべての情報を運ぶために使用されています。 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].
PEとCEの間でOSPFを使用するための手順の完全なセットの指定は、[VPN-OSPF]と[OSPF-2547-DNBIT]に見出すことができます。
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ルータはPEルータにCEルータのサイトにあるアドレスプレフィックスのセットを伝えるために、具体的には（EBGPをBGPを使用することができます。（この技術はスタブで使用することができますVPNのか、トランジットVPNを。）
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の選択肢とは異なり、これは複数のCEと話をするために、複数のルーティングアルゴリズムのインスタンスを実行するために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.
サイトには、「BGPのバックドア」、PEルータ以外のルータへのBGP接続を持つ、すなわち、ルータが含まれている場合c）は、この手順は、すべての状況で正しく動作します。他の手順は、または正確な状況に応じて、動作してもしなくてもよいです。
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へのルートの属性を渡すようになります。一連の属性とその使用の完全な仕様は、このドキュメントの範囲外です。しかし、これを使用することができる方法のいくつかの例は次のとおりです。
- 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.
- 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.
- 意図はCEにCEから（すなわち、PEルータによって変更されずに）透過的に渡さそれらの属性を有することである拡張コミュニティのさらなるタイプは、定義することができる属性。これは、CE管理者はのPEによって行われていることを超えて、追加のルートフィルタリングを実装できるようになります。この追加フィルタは、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にない場合、それはユニークな自律システム番号（ASN）を持つ必要はないことに注意してください。そのサイトのすべてのCEは同じASNを使用することができますトランジットVPNではありません。これは、プライベートASN空間から選択することができ、それがPEによって取り除かれます。ルーティングループが起源属性のサイトを利用することによって防止されている（下記参照）。
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.
どのようなサイトの集合がトランジットVPNを構成している場合は？これは、一般的にVPNは、インターネットサービスプロバイダのISPが別のSPからバックボーンサービスを購入し、それ自体である（ISP）のネットワーク、自身である場合にのみの場合となります。後者の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ルートがサイトから学んだ再配布する前に、それがルートにルートターゲットの属性を（4.3.1項を参照）を割り当てる必要があり、それが起源のサイトがルートに属性を割り当てることができます。
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 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.
発生部位は、使用する場合、ルート起源拡張コミュニティ[BGP-EXTCOMM]として符号化された属性。この属性の目的は、一意に特定のサイトから学習したルートのセットを識別することです。この属性は、ルートは、特定のPE / CE接続を介して、特定のサイトから学んだ別のPE / CE接続を介してバックサイトに分散されていないことを保証するために、いくつかのケースで必要とされています。 BGPは、PE / CEプロトコルとして使用されている場合には、特に有用であるが、異なる部位が異なるAS番号を割り当てられていません。
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は、これはPE / CEプロトコルの規則によって許可された場合にのみ、CEへのルートを分配することができます。 （特定のPE / CEプロトコルが「スプリットホライズン」、VRF内の特定のルートを有する場合、例えば、バックCEに再配布することはできない。）我々は、CEのPEからのルートの分布上の一の以上の制限を追加する：ルートのサイトならORIGIN属性の特定のサイトを識別し、そのルートは、そのサイトのすべての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.
PEとCEからルートを配布するために使用されるどのような手順でもCEのPEからのルートを配布するために使用されます。
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のネットワークであってもよいです。これらのようなVPNはまた、本質的に、この文書で説明したのと同じ方法を使用して、別のSP、「キャリアのキャリア」からバックボーンサービスを得ることができます。しかし、それは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ルータは、PEルータVPNの内部にあるそれらのルートに配布すべきです。これは、VPNはスタブVPNとして扱うことができるようになります。
- 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.
- 彼らはPEルータからラベルを受け取り、PEルータにラベル付きパケットを送信することができるはずという点で、CEルータは、MPLSをサポートする必要があります。彼らは、しかし、自分自身のラベルを配布する必要はありません。
- 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:
次のいずれかの条件が成立していない限りPEは、二つの異なるCEに同じラベルを配布してはいけません。
* The two CEs are associated with exactly the same set of VRFs;
* 2つのCEは、VRFのと全く同じセットに関連付けられています。
* The PE maintains a different Incoming Label Map ([MPLS-ARCH]) for each CE.
* PEは各CEに異なる着信ラベルマップ（[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にパケットを送信します。 PEはなく、VRF内のパケットの宛先IPアドレスを調べるには、BGPネクストホップを選択するために、パケットのトップMPLSラベルを使用しています。 BGPネクストホップはホップ以上離れている場合、結果として、トップラベルは、2つのラベル、トンネルラベルとVPN経路ラベルによって置き換えられます。 BGPネクストホップが1ホップ離れている場合は、トップラベルはただのVPNルートラベルに置き換えることができます。イングレスPEも出力PEの場合は、トップラベルはちょうどポップされます。パケットがCEへの出口PEから送信された場合、パケットは、それが最初に入口PEによって受信されたときに持っていたよりも1つ少ないMPLSラベルを有することになります。
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 internal route that a CE router distributes to a PE router, it must also distribute a label.
上記の手順では、CEルータはMPLSをサポートする必要があるVPNの唯一のルータです。一方、特定のVPNサイトのサポートMPLSのすべてのルータが、もはや、CEルータは、すべての外部ルートを知っていることが必要とされていない場合。必要とされるすべての外部ルートが、これまでの非標識のパケットにラベルスタックを置くため、ラベルは他のサイトで彼らのBGPピアにこれらのルータからリードスイッチパスが存在することが担当しているものは何でもルータに知られることです。この場合、CEルータはPEルータに分配する各内部経路のため、それはまた、ラベルを配布しなければなりません。
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.
（サイトが異なるSPに接続されているので、例えば）VPNの2つのサイトが異なる自律システムに接続されている場合はどう？その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）AS（自律システム）境界ルータのVRF-に-VRFの接続。
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.
この手順では、一つのAS内のPEルータは、他にPEルータに直接付着します。 2つのPEルータは、その経路ASするから渡される必要があるVPNの各々のための少なくとも一つの、複数のサブインターフェイスによって結合されるであろう。それはCEルータであるかのように、各PEは、他を扱います。すなわち、PEが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.
これは、「ただ働き」の手順であり、それはAS間の境界でMPLSを必要としません。しかし、それはスケールだけでなく、以下で説明する他の手順はありません。
b) EBGP redistribution of labeled VPN-IPv4 routes from AS to neighboring AS.
隣接ASへのASからの標識されたVPN-IPv4経路のB）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ルータは、自律システム境界ルータ（ASBR）に、またはASBRがクライアントとなっているルートリフレクタのいずれかに標識されたVPN-IPv4ルートを再配布するIBGPを使用します。 ASBRは、その後順番にようにそのAS内のPEルータへの、又はおそらく順番にそれらを分配する別のASBRに配布し、別のAS内のASBRにそれらの標識されたVPN-IPv4ルートを再配布する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.
この手順を使用する場合、VPN-IPv4ルートのみのSPとの間の信頼された装置の一部として、プライベートピアリングポイントでEBGP接続で受け入れられるべきです。 VPN-IPv4経路は、どちらに配布されなかったり、公衆インターネットからの、または信頼されていないすべてのBGPピアから受け入れられるべきです。それは実際にそのピアにトップラベルを配布していない限り、ASBRは、EBGPピアからラベル付きパケットを受け入れるべきではありません。
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.
異なる自律システムに接続部位を有する多数のVPNがある場合は、すべてのVPNのすべてのルートを保持しているこれら二つのAS間の単一ASBRがあるように必要はありません。 VPNの特定のサブセットのための唯一の経路を保持している各々が複数のASBR、存在し得ます。
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から先頭の経路が切り替えられていることが必要です。したがって、適切な信頼関係は、間、パスに沿ってのASの組の間に存在しなければなりません。これに境界ルータは、ルートがターゲットとルートを受信する必要があるとして、また、のSPのセットの中の合意がなければなりません。
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.
ASからAS隣接する標識されたIPv4ルートのEBGP再分配とソースと宛先AS間標識VPN-IPv4ルートのC）マルチホップ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経路はどちらも維持されていないものASBRによって配布します。 ASBRは、AS内のPEルータへの標識のIPv4 / 32ルートを維持しなければなりません。これは、他のASにこれらのルートを配布するためにEBGPを使用しています。任意の中継のAS内のASBRはまた、標識された/ 32の経路に沿って通過するEBGPを使用する必要があります。ラベルの作成でこの結果は、出力PEルータに入力PEルータからのパスを切り替えます。今別のAS内の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ルートが（ASBRは除く）Pルータに知らされていない場合、この手順はそれに3-ラベルスタックを置くために、パケットのイングレスPEが必要です。底ラベルは、特定のVRFにパケットの宛先アドレスに対応する、出口PEによって割り当てられます。中間ラベルは出口PEへ/ 32の経路に対応し、ASBRによって割り当てられます。トップラベルは、ASBRに/ 32の経路に対応する、入力PEのIGPネクストホップによって割り当てられます。
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.
スケーラビリティを向上させるためには、マルチホップEBGP接続が一つだけASにルートリフレクタと別のルートリフレクタとの間に存在していてもよいです。 （ルートリフレクタは、この接続を介してルートを配布するときしかし、それらはルートのBGPネクストホップ属性を変更しない。）実際のPEルータは次いでのみ独自のAS内のルートリフレクタにIBGP接続を有するであろう。
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から先頭の経路が切り替えられていることが必要です。
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.
いくつかのVPNにおいて、サイトのうちの1つ以上は、ISPへの非VRFインターフェイスに接続「インターネットゲートウェイ」（おそらくファイアウォール）によってインターネットへのアクセスを取得します。 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.
この場合、インターネットへのアクセスを持っているサイトは、今度は他のPEに、したがって、VPNの他のサイトにそれを再配布され、そのPEにデフォルトルートを配布することができます。これは、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ルータのデフォルトフォワーディングテーブルとのVRFの間の経路の交換はありません。 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".
VPNのいくつかのサイトは、VRFインターフェイスを使用していますが、インターネットからVPNに入る/離れる前に非VRFインターフェイスを横断する/、インターネットで最終的にすべてのパケットを通信することに注意してください、私たちは「非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 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.
非VRFインターフェイスと接続しているPEルータは、必ずしもそのデフォルトの転送テーブル内のすべてのインターネットルートを維持する必要はないことに注意してください。デフォルトの転送テーブルには、インターネットルートを持っている別のルータ（おそらく隣接する1）につながるつのルート、「デフォルト」、など、いくつかのように持つことができます。このスキームの変形は、トンネルパケットに、この他のルータは、インターネットルートのフルセットを維持する他のルータへの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.一部のVPNは、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 techniques of Section 4 to distribute Internet routes, as VPN-IPv4 routes, to other VRFs.
この技術を使用する場合、SPは、インターネットへのインターフェイスがVRFインタフェースであり、そして他のVRFに、VPN-IPv4ルートとして、インターネットルートを分配する第4の技術を使用するようにすることができます。
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間の合意により行われ、それが顧客の方針に合っている場合のみ。
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ルータは、サービスプロバイダーによって管理されている場合は、サービスプロバイダは、おそらくCEルータと通信できるようにする必要があるネットワーク管理システムを持っています。この場合には、CEおよびPEルータを接続するサブインターフェースに割り当てられたアドレスは、SPのアドレス空間から来る必要があり、その空間内で一意でなければなりません。ネットワーク管理システムは、それ自体がVRFインターフェイスを介して（より正確には、PEルータに接続する部位であっても）PEルータに接続する必要があります。ネットワーク管理システムのアドレスはSPによって管理されるCEルータへのインターフェイスに関連付けられたすべてのVRFにエクスポートされます。 CEルータのアドレスは、ネットワーク管理システムに関連付けられているVRFにではなく、他のVRFにエクスポートされます。
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つの方法は、2つのルートターゲットを使用することです。 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を有するルートをインポートします。
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の方針と一致した方法以外の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,
前記標識されたVPN-IPv4経路は、信頼できない、または信頼できないルーティングピアから受け入れられません
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.
このアーキテクチャによって提供されるデータプレーンのセキュリティは、フレームリレー、またはATMバックボーンによってVPNに提供されるものと実質的に同一です。 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つの条件のいずれかが成り立つ場合を除き一つは、特定のネイバーから受け取ったラベル付きパケットを破棄する必要があります。
- 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).
- パケットのトップラベルは、受信システムがその隣人を越えてシステムに分散していることラベル値を有する（すなわち、それはラベルが受信システムに分散したシステムからのパスがその隣人を介してもよいことが知られている場合） 。
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は、上記インタープロバイダVPNの場合に最も重要である（セクション10を参照）。第10のスキームBに従って構成されたインタープロバイダのVPN）のため、条件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つの境界ルータは、上記の条件の最初は、それに適用されない限り、ラベル付きパケットを受け入れることを拒否持つことは簡単なことです。それは、そのパケットは、宛先アドレスがPEルータのことであるIPトンネリングされたパケットである場合は、IPパケットを受け入れることを拒否するようにルータを設定するために、むしろより困難です。確かに、これを行うのは不可能ではないが、それは管理とパフォーマンスの両方の意味を持っています。
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.
MPLS-で-IPとMPLSインGREトンネリングは[MPLS-で-IP-GRE]で指定されています。それはVPNパケットを運ぶために、このようなトンネルを使用することが所望される場合、そのドキュメントのセクション8で説明したセキュリティ上の考慮事項は、十分に理解されなければなりません。そこに記載されている使用することができるのIPsecの実装を含む必要があることを文書に記載されているようにVPNパケットを許可BGP / MPLS IP VPNのいずれかの実装では、トンネリングされます。トンネルは、IPSecで保護されていない場合、そのドキュメントのセクション8.2に記載境界ルータにおけるIPアドレスフィルタリングの手法は、特定の出口PEでトンネルを出るパケットが実際に置かれたことを保証する唯一の手段であります適切なトンネルヘッドノードによりトンネル内（すなわち、パケットがスプーフィングされた送信元アドレスを持っていないこと）。境界ルータが頻繁にのみソースアドレスをフィルタリングするので、出口PEは、それが受信する任意のトンネリングされたパケットのIPソースアドレスをチェックし、有効なトンネルの先頭アドレスであるIPアドレスのリストと比較することができない限り、パケットフィルタリングが有効ではないかもしれません。 IPsecのなしで使用するMPLS-で-IPおよび/またはMPLSインGREトンネリング可能にする任意の実装では、出口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ルータに取り付ける場合には、次のいずれかの条件を満たさなければなりません。
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. Aは、信頼できると固定LANスイッチは、単一のVPNのシステムのみを含む各VLANで、複数のVLANにLANを分割します。この場合、スイッチは、PEルータに転送する前に、パケットに適切なVLANタグを添付します。
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.
暗号プライバシーはこのアーキテクチャによって、またフレームリレーやATMのVPNによって提供されていません。それが望まれる場合、これらのアーキテクチャは、すべてのCE-CEベースで暗号化の使用と互換性があります。
The use of cryptography on a PE-PE basis is for further study.
PE-PEベースで暗号の使用は、今後の検討課題です。
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やLDP接続が信頼できないピアとなされるべきです。 TCP / IP MD5認証オプション[TCP-MD5]はこれらのプロトコルの両方で使用する必要があります。 SPのネットワーク内のルーティングプロトコルも同様に確保されるべきです。
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トラフィックは、これらのデバイスの設定を変更するために使用することができない、またはそれらのサービス拒否攻撃をマウントするように注意する必要があります。
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.
この論文の焦点ではないが、サービスの質は、任意のVPNサービスの重要な要素です。 MPLS / BGP VPNの中で、既存のL3 QoS機能は、ATMの使用を介して、ATMをバックボーンとして使用されるシムヘッダ[MPLS-ENCAPS]、または、で「実験」ビットを使用することによってラベル付きパケットに適用することができますQoS機能。 [MPLS-RSVP]で議論トラフィックエンジニアリング作業もMPLS / BGP VPNに直接適用されます。それが望ましい場合は、トラフィックエンジニアリングをしてもラベルを確立するために使用することができ、サイトの特定のペア間の特定のQoS特性を持つパスを切り替えます。 MPLS / BGP VPNが複数のSPに及ぶ場合、[PASTE]に記載のアーキテクチャは、有用であり得ます。 SPは適宜のIntServ（統合サービス）、または特定のVPNへのDiffServ（差別化サービス）機能のいずれかを適用することができます。
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.
サービスプロバイダバックボーンネットワークは、（a）は、PEルータで構成され、（b）は、BGPルートリフレクタ、マルチプロバイダVPNの場合、及び、（いずれもPEルータでもルートリフレクタである）、（C）Pルータ、（D） ASBR。
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ルータとのASBRへのルートを維持するだけでよいです。ラベルの二つのレベルの使用は、Pルータのうち、VPNルートを維持することを可能にするものです。
A PE router maintains VPN routes, but only for those VPNs to which it is directly attached.
PEルータは、のみが直接結合しているものVPNの、VPNルートを維持します。
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.
各パーティションは、サービスプロバイダによってサポートされているVPNのサブセットのみのルートを運ぶようにルートリフレクタは、VPN間で分割することができます。したがって、単一のルートリフレクタは、すべてのVPNの経路を維持するために必要とされません。
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.
ASBRは、VPN-IPv4ルートを維持し、配布する場合インタープロバイダのVPNについては、その後のASBRは単一ASBRは全てインタープロバイダVPNの経路を維持するために必要とされない、その結果、同様の方法で、VPN間で分割することができます。マルチホップEBGPが使用される場合、その後のASBRは全く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.
結果として、サービスプロバイダネットワーク内の単一コンポーネントは、すべてのVPNのすべてのルートを維持しなければなりません。だから、VPNの数の増加をサポートするためのネットワークの総容量は、任意の個々のコンポーネントの容量によって限定されるものではありません。
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].
IANA（Internet Assigned Numbers Authority）は、「ルート識別子タイプフィールド」（4.2節を参照）のための新しいレジストリを作成しました。これは、2バイトのフィールドです。タイプ0、1、および2は、この文書で定義されています。 0の上位ビットと追加のルート識別子タイプフィールドの値が「最初に来、最初に配信」基礎[IANA]にIANAによって割り当てられてもよいです。 1の上位ビットとの値は、「IETFコンセンサス」[IANA]に基づいて、IANAによって割り当てられてもよいです。
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.
この文書で指定します（4.3.4項を参照）BGPを使用すると、アドレスファミリ「VPN-IPv4の標識アドレス」を表現するために、BGP次のアドレスファミリ識別子（SAFI）値128と一緒に、ファミリ識別子（AFI）値1アドレスこの文書で定義されています。
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.
IANAはそれに関して何もアクションを取る必要はないので、IPのためのAFI値が1の使用は、現在、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".
SAFI値128はもともとIANA「次のアドレスファミリ識別子」レジストリ内の「私用」として指定されました。 IANAは、「MPLS-VPNラベルされたアドレス」に「私的使用」からSAFI値128を変更しました。
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ビスワスに感謝したいです。
Tony Bogovic Telcordia Technologies 445 South Street, Room 1A264B Morristown, NJ 07960
トニーBogovicのTelcordia Technologies社445サウスストリート、ルーム1A264Bモリスタウン、NJ 07960
EMail: tjb@research.telcordia.com
メールアドレス：tjb@research.telcordia.com
Stephen John Brannon Swisscom AG Postfach 1570 CH-8301 Glattzentrum (Zuerich), Switzerland
スティーブン・ジョン・ブラノンスイスコムAG私書箱1570 CH-8301 Glattzentrum（チューリッヒ）、スイス
EMail: stephen.brannon@swisscom.com
メールアドレス：stephen.brannon@swisscom.com
Marco Carugi Nortel Networks S.A. Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT 78928 YVELINES Cedex 9 - FRANCE
マルコCarugi Nortel NetworksのS.A.社パーク活動マニレジュンヌボワCHATEAUFORT 78928イヴリーヌCedexの9 - FRANCE
EMail: marco.carugi@nortelnetworks.com
メールアドレス：marco.carugi@nortelnetworks.com
Christopher J. Chase AT&T 200 Laurel Ave Middletown, NJ 07748 USA
クリストファー・J・チェース・AT＆T 200ローレルアベニューミドルタウン、NJ 07748 USA
EMail: chase@att.com
メールアドレス：chase@att.com
Ting Wo Chung Bell Nexxia 181 Bay Street Suite 350 Toronto, Ontario M5J2T3
チョン・ベルNexxia 181ベイストリートスイート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
ジェレミー・デ・Clercqアルカテル・ネットワーク戦略グループフランシスWellesplein 1 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ローレルアベニュー。ミドルタウン、NJ 07748
EMail: luyuanfang@att.com
メールアドレス：luyuanfang@att.com
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ジュニパーネットワークス株式会社385 Ravendaleドライブマウンテンビュー、CA 94043 USA
EMail: manoj@juniper.net
メールアドレス：manoj@juniper.net
Dave Marshall Worldcom 901 International Parkway Richardson, Texas 75081
デイブマーシャルワールドコム901国際パークウェイリチャードソン、テキサス州75081
EMail: dave.marshall@wcom.com
メールアドレス：dave.marshall@wcom.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
ルカ・マティーニシスコシステムズ株式会社9155東ニコルズアベニュー、スイート400イングルウッド、CO、80112
EMail: lmartini@cisco.com
メールアドレス：lmartini@cisco.com
Monique Jeanne Morrow Cisco Systems, Inc. Glatt-com, 2nd floor CH-8301 Glattzentrum, Switzerland
モニークジャンヌ・モローシスコシステムズ、株式会社グラット-COM、2階CH-8301 Glattzentrum、スイス
EMail: mmorrow@cisco.com
メールアドレス：mmorrow@cisco.com
Ravichander Vaidyanathan Telcordia Technologies 445 South Street, Room 1C258B Morristown, NJ 07960
RavichanderがVaidyanathanのTelcordia Technologies社445サウスストリート、ルーム1C258Bモリスタウン、NJ 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
ビジェイ・スリニバサン1200ブリッジパークウェイレッドウッドシティ、CA 94065
EMail: vsriniva@cosinecom.com
メールアドレス：vsriniva@cosinecom.com
Alain Vedrenne Equant Heraklion, 1041 route des Dolines, BP347 06906 Sophia Antipolis, Cedex, France
アランVedrenneイクアントイラクリオン、1041ルートDolines、BP347 06906ソフィアアンティポリスセデックス、フランス
EMail: Alain.Vedrenne@equant.com
メールアドレス：Alain.Vedrenne@equant.com
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP] Rekhter、Y.とT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、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のためのマルチプロトコルの拡張"、RFC 2858、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は、RFC 4360、2006年2月の "BGP拡張コミュニティ属性"。
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH]ローゼン、E.、Viswanathanの、A.、およびR. Callon、RFC 3031、2001年1月 "マルチプロトコルラベルスイッチングアーキテクチャ"。
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[MPLS-BGP] Rekhter、Y.、およびE.ローゼン、 "BGP-4でのキャリングラベル情報"、RFC 3107、2001年5月。
[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ラベルスタックエンコーディング"、RFC 3032、 2001年1月。
[BGP-AS4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet AS Number Space", Work in Progress, March 2004.
[BGP-AS4] Vohra著、Q.およびE.チェン、 "ナンバースペースAS 4オクテットのためのBGPのサポート"、進歩、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、 "BGP-4のための共同ルートフィルタリング機能"、進歩、2004年3月での作業。
[BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[BGP-RFSH]チェン、E.、 "BGP-4のためのルートリフレッシュ機能"、RFC 2918、2000年9月。
[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への代替"、RFC 2796、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問題部に書くためのガイドライン"、BCP 26、RFC 2434、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-ATM]デイビー、B.、ローレンス、J.、McCloghrie、K.、ローゼン、E.、ツバメ、G.、Rekhter、Y.、およびP. Doolan、 "LDPおよびATM VCスイッチングを使用してMPLS"、 RFC 3035、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.、デClercq、J.、Paridaens、O.、T'Joens、Y.、およびC. Sargor、「BGP / MPLSにおけるPE-PEのIPsecトンネルを使用するためのアーキテクチャIP VPN」を、進歩、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、 "フレームリレーネットワークの仕様上のラベルスイッチングの使用"、RFC 3034、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.
[MPLS-で-IP-GRE] Worster、T.、Rekhter、Y.、およびE.ローゼン、 "IP又は総称ルーティングカプセル化（GRE）でMPLSカプセル化"、RFC 4023、2005年3月。
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[MPLS-LDP]アンダーソン、L.、Doolan、P.、フェルドマン、N.、Fredette、A.およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[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.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209 、2001年12月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
【のOSPFv2]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、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、 "差別化サービスプロバイダのためのアーキテクチャとトラフィックエンジニアリング（PASTE）"、RFC 2430、1998年10月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIP]マルキン、G.、 "RIPバージョン2"、STD 56、RFC 2453、1998年11月。
[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.
進歩、2004年3月に、仕事を "BGP / MPLS IP VPNの中でループを防止するためにLSAオプションビットを使用する" [OSPF-2547-DNBIT]ローゼン、E.、Psenak、P.、およびP. Pillay-Esnault、。
[TCP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[TCP-MD5] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[VPN-MCAST] Rosen, E., Cai, Y., and J. Wijsnands, "Multicast in MPLS/BGP VPNs", Work in Progress, May 2004.
[VPN-MCAST]ローゼン、E.、カイ、Y.、およびJ. Wijsnands、 "MPLS / BGPのVPNにおけるマルチキャスト" は進歩、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.、Psenak、P.、およびP. Pillay-Esnault、進歩、2004年2月に、ワーク "OSPF PE / CEのBGP / MPLS VPNの中のプロトコルとして"。
Authors' Addresses
著者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
ヤコフ・レックタージュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。