Network Working Group E. Rosen
Request for Comments: 2547 Y. Rekhter
Category: Informational Cisco Systems, Inc.
March 1999
BGP/MPLS VPNs
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border Gateway Protocol) is used for distributing routes over the backbone. The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. These techniques can also be used to provide a VPN which itself provides IP service to customers.
この文書では、IPバックボーンを持つサービスプロバイダーが顧客のためのVPN（仮想プライベートネットワーク）を提供することができる方法を説明します。 MPLS（マルチプロトコルラベルスイッチング）はバックボーン上でパケットを転送するために使用され、BGP（ボーダーゲートウェイプロトコル）はバックボーン上のルートを配布するために使用されます。この方法の主な目的は、企業ネットワークのためのIPバックボーンサービスのアウトソーシングをサポートすることです。これは、サービスプロバイダーのため、まだ拡張性と柔軟性ながら、企業のための簡単な方法であるそう、およびサービスプロバイダーが値を追加することができるようにします。また、これらの技術は、それ自体が顧客にIPサービスを提供してVPNを提供するために使用することができます。
Table of Contents
目次
1 Introduction ....................................... 2
1.1 Virtual Private Networks ........................... 2
1.2 Edge Devices ....................................... 3
1.3 VPNs with Overlapping Address Spaces ............... 4
1.4 VPNs with Different Routes to the Same System ...... 4
1.5 Multiple Forwarding Tables in PEs .................. 5
1.6 SP Backbone Routers ................................ 5
1.7 Security ........................................... 5
2 Sites and CEs ...................................... 6
3 Per-Site Forwarding Tables in the PEs .............. 6
3.1 Virtual Sites ...................................... 8
4 VPN Route Distribution via BGP ..................... 8
4.1 The VPN-IPv4 Address Family ........................ 9
4.2 Controlling Route Distribution ..................... 10
4.2.1 The Target VPN Attribute ........................... 10
4.2.2 Route Distribution Among PEs by BGP ................ 12
4.2.3 The VPN of Origin Attribute ........................ 13
4.2.4 Building VPNs using Target and Origin Attributes ... 14
5 Forwarding Across the Backbone ..................... 15
6 How PEs Learn Routes from CEs ...................... 16
7 How CEs learn Routes from PEs ...................... 19
8 What if the CE Supports MPLS? ...................... 19
8.1 Virtual Sites ...................................... 19
8.2 Representing an ISP VPN as a Stub VPN .............. 20
9 Security ........................................... 20
9.1 Point-to-Point Security Tunnels between CE Routers . 21
9.2 Multi-Party Security Associations .................. 21
10 Quality of Service ................................. 22
11 Scalability ........................................ 22
12 Intellectual Property Considerations ............... 23
13 Security Considerations ............................ 23
14 Acknowledgments .................................... 23
15 Authors' Addresses ................................. 24
16 References ......................................... 24
17 Full Copyright Statement............................. 25
Consider a set of "sites" which are attached to a common network which we may call the "backbone". Let's apply some policy to create a number of subsets of that set, and let's 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相互接続性を有することができます。
The subsets we have created are "Virtual Private Networks" (VPNs). Two sites have IP connectivity over the common backbone only if there is some VPN which contains them both. Two sites which 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 is a corporate "intranet". If the various sites in a VPN are owned by different enterprises, the VPN is an "extranet". A site can be in more than one VPN; e.g., in an intranet and several extranets. We regard both intranets and extranets as VPNs. In general, when we use the term VPN we will not be distinguishing between intranets and extranets.
VPN内のすべてのサイトが同じ企業によって所有されている場合、VPNは企業「イントラネット」です。 VPNのさまざまなサイトが異なる企業によって所有されている場合、VPNは「エクストラネット」です。サイトが複数のVPNにすることができ、例えば、イントラネットおよびエクストラネットのいくつかです。私たちは、VPNなどのイントラネットやエクストラネットの両方を考えています。我々は長期的なVPNを使用する場合、一般的に、我々は、イントラネットやエクストラネットを区別されることはありません。
We wish to consider the case in which the backbone is owned and operated by one or more Service Providers (SPs). The owners of the sites are the "customers" of the SPs. 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 implement these policies themselves, or to share with the SP the responsibility for implementing these policies. In this document, we are primarily discussing mechanisms that may 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.
私たちは、背骨が一つ以上のサービスプロバイダ（SPS）が所有、運営されている場合を考えることを望みます。サイトの所有者は、SPSの「顧客」です。サイトの特定のコレクションが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, we can allow every site to have a direct route to every other site ("full mesh"), or we can restrict certain pairs of sites from having direct routes to each other ("partial mesh").
このドキュメントで説明する機能は、政策の広い範囲の実装を可能にします。例えば、所与のVPN内で、我々は、すべてのサイトが他のすべてのサイト（「フルメッシュ」）への直接ルートができるようにすることができ、又はお互い（「部分的メッシュ」）への直接経路を有するから、サイトの特定のペアを制限することができ。
In this document, we are particularly interested in the case where the common backbone offers an IP service. We are primarily concerned with the case in which an enterprise is outsourcing its backbone to a service provider, or perhaps to a set of service providers, with which it maintains contractual relationships. We are not focused on providing VPNs over the public Internet.
この文書では、我々は一般的なバックボーンがIPサービスを提供しています場合に特に興味を持っています。私たちは、企業がサービスプロバイダへ、または多分それは契約関係を維持しているサービスプロバイダーのセットにその骨格をアウトソーシングしている場合と、主に懸念しています。私たちは公共のインターネット上でVPNを提供することに焦点を当てていません。
In the rest of this introduction, we specify some properties which VPNs should have. The remainder of this document outlines a VPN model which has all these properties. The VPN Model of this document appears to be an instance of the framework described in [4].
この導入の残りの部分では、我々は、VPNが持つべきいくつかのプロパティを指定します。このドキュメントの残りの部分では、これらすべての特性を有しているVPNモデルの概要を説明します。この文書のVPNモデル[4]に記載のフレームワークのインスタンスであるように見えます。
We suppose that at each site, there are one or more Customer Edge (CE) devices, each of which is attached via some sort of data link (e.g., PPP, ATM, ethernet, Frame Relay, GRE tunnel, etc.) to one or more Provider Edge (PE) routers.
私たちは、各サイトで、1へのデータリンク（例えば、PPP、ATM、イーサネット、フレームリレー、GREトンネルなど）のいくつかの並べ替えを介して結合して、それぞれが一つ以上のカスタマーエッジ（CE）デバイスがあると仮定します以上のプロバイダエッジ（PE）ルータ。
If a particular site has a single host, that host may be the CE device. If a particular site has a single subnet, that the CE device may be a switch. In general, the CE device can be expected to be a router, which we call the CE router.
特定のサイトが単一のホストを持っている場合は、そのホストがCEデバイスであってもよいです。特定のサイトが単一のサブネットを持っている場合、CEデバイスがスイッチであってもよいこと。一般的には、CEデバイスは、我々はCEルータを呼び出すルータであると期待できます。
We will say that a PE router is attached to a particular VPN if it is attached to a CE device which is in that VPN. Similarly, we will say that a PE router is attached to a particular site if it is attached to a CE device which 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 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 (except in the case where this is necessary for security purposes, see section 9). As a consequence, very large VPNs (i.e., VPNs with a very large number of sites) are easily supported, while the routing strategy for each individual site is greatly simplified.
CE装置がルータである場合、それが結合しているPE（S）のルーティングピアであるが、他の部位でのCEルータのルーティングピアではありません。異なるサイトのルータは、直接相互にルーティング情報を交換しません。実際に、彼らも全くお互いを知っている必要はありません（これはセキュリティ上の目的のために必要である場合を除いて、セクション9を参照してください）。各個々のサイトのルーティング戦略が大幅に簡略化されている間その結果、非常に大規模なVPNは（すなわち、サイトの非常に大きな数のVPNは）、容易に、支持されています。
It is important to maintain clear administrative boundaries between the SP and its customers (cf. [4]). The PE and P routers should be administered solely by the SP, and the SP's customers should not have any management access to it. The CE devices should be administered solely by the customer (unless the customer has contracted the management services out to the SP).
（[4]参照）SPとその顧客との間に明確な管理境界を維持することが重要です。 PEとPルータは、SPによってのみ投与されるべきである、とSPの顧客は、それへの管理アクセスを持つべきではありません。 （顧客がSPに出管理サービスを契約していない限り）CEデバイスは、顧客が単独で投与されるべきです。
We assume that any two non-intersecting VPNs (i.e., VPNs with no sites in common) may have overlapping address spaces; the same address may be reused, for different systems, in different VPNs. As long as a given endsystem has an address which is unique within the scope of the VPNs that it belongs to, the endsystem itself does not need to know anything about VPNs.
我々は仮定する任意の二つの非交差のVPN（すなわち、共通でない部位とのVPN）重複アドレス空間を有していてもよいです。同じアドレスが異なるVPNに、異なるシステムのために、再利用することができます。限り、与えられたエンドシステムは、それが属するVPNの範囲内でユニークなアドレスを持っているように、エンドシステム自体は、VPNのについて何を知っている必要はありません。
In this model, the VPN owners do not have a backbone to administer, not even a "virtual backbone". Nor do the SPs have to administer a separate backbone or "virtual backbone" 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の所有者は、いなくても「仮想バックボーン」を投与するバックボーンを持っていません。 NOR SPは、各VPNのための個別のバックボーンまたは「仮想バックボーン」を投与する必要があります。バックボーンにおけるサイト間のルーティングは、（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からのトラフィックは、サーバへの途中にファイアウォールを通過する必要はありません。
This means that it needs to be 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への経路をたどることにします
Each PE router needs to maintain a number of separate forwarding tables. Every site to which the PE is attached must be mapped to one of those forwarding tables. When a packet is received from a particular site, the forwarding table associated with that site is consulted in order to determine how to route the packet. The forwarding table associated with a particular site S is populated only with routes that lead to other sites which have at least one VPN in common with S. This prevents communication between sites which have no VPN in common, and it allows two VPNs with no site in common to use address spaces that overlap with each other.
各PEルータは、別の転送テーブルの数を維持する必要があります。 PEが結合しているすべてのサイトは、それらのフォワーディングテーブルのいずれかにマッピングされなければなりません。パケットが特定のサイトから受信した場合、そのサイトに関連付けられている転送テーブルは、どのルートパケットに決定するために調べられます。特定の部位Sに関連付けられている転送テーブルのみS.と共通の少なくとも一つのVPNこれは、一般的にはVPNを持たない部位との間の通信を防ぎ、そしてそれはサイトと2つのVPNを可能にする持っている他のサイトに導く経路に取り込まれ一般的に重なるアドレス空間を使用します。
The SP's backbone consists of the PE routers, as well as other routers (P routers) which 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, this model would have 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 to require therefore that the routing information about a particular VPN be present ONLY in those PE routers which attach to that VPN. In particular, the P routers should not need to have ANY per-VPN routing information whatsoever.
SPのバックボーン内のすべてのルータはSPでサポートされているすべてのVPNのルーティング情報を維持しなければならないとしたら、このモデルは深刻なスケーラビリティの問題を持っているでしょう。サポートできるサイトの数は、単一のルータで開催することができ、ルーティング情報の量によって制限されるだろう。特定のVPNについてのルーティング情報のみそのVPNに接続これらのPEルータに存在することが必要とすることが重要です。具体的には、Pルータは一切あたり-VPNルーティング情報を持っている必要はありません。
VPNs may span multiple service providers. We assume though that when the path between PE routers crosses a boundary between SP networks, it does so via a private peering arrangement, at which there exists mutual trust between the two providers. In particular, each provider must trust the other to pass it only correct routing information, and to pass it labeled (in the sense of MPLS [9]) packets only if those packets have been labeled by trusted sources. We also assume that it is possible for label switched paths to cross the boundary between service providers.
VPNは、複数のサービスプロバイダにまたがることがあります。私たちは、PEルータ間のパスがSPネットワーク間の境界を越えたとき、それは2つのプロバイダ間の相互信頼が存在しているのプライベートピアリングアレンジメントを介してそうしていることしかし前提としています。具体的には、各プロバイダは、正しいルーティング情報を渡すために、それらのパケットが信頼できるソースによって標識されている場合のみパケット（[9] MPLSの意味で）、それは標識渡す他を信頼しなければなりません。また、ラベルは、サービスプロバイダとの間の境界を横断するパスを切り替えることが可能であることを前提としています。
A VPN model should, even without the use of cryptographic security measures, provide a level of security equivalent to that obtainable when a level 2 backbone (e.g., Frame Relay) is used. That is, in the absence of misconfiguration or deliberate interconnection of different VPNs, it should not be possible for systems in one VPN to gain access to systems in another VPN.
レベル2バックボーン（例えば、フレームリレー）を使用した場合のVPNモデルは、さらに暗号化セキュリティ対策を使用することなく、その入手にセキュリティ同等のレベルを提供すべきです。すなわち、設定ミス又は異なるVPNの意図的な相互接続が存在しない場合には、別のVPN内のシステムへのアクセスを獲得する一つのVPN内のシステムのために可能であるべきではないれています。
It should also be possible to deploy standard security procedures.
また、標準的なセキュリティ手順を展開することが可能なはずです。
From the perspective of a particular backbone network, a set of IP systems constitutes a site if those systems have mutual IP interconnectivity, and communication between them occurs without use of the backbone. In general, a site will consist of a set of systems which are in geographic proximity. However, this is not universally true; two geographic locations connected via a leased line, over which OSPF is running, will constitute a single site, because communication between the two locations does not involve the use of the backbone.
特定のバックボーンネットワークの観点から、IPシステムのセットは、これらのシステムは、相互のIP相互接続性を持っている場合は、サイトを構成し、それらの間の通信は、バックボーンを使用せずに発生します。一般的には、サイトが地理的に近接しているシステムのセットで構成されます。しかし、これは普遍的真実ではありません。 2つの位置の間の通信は、バックボーンの使用を伴わないため、OSPFを実行している上に専用線を介して接続された二つの地理的位置は、単一の部位を構成します。
A CE device is always regarded as being in a single site (though as we shall see, a site may consist of multiple "virtual sites"). A site, however, may belong to multiple VPNs.
（私たちが見るように、サイトは複数の「仮想サイト」から構成されてもよいが）CEデバイスは常に単一のサイトであると見なされます。このサイトは、しかし、複数のVPNに属していてもよいです。
A PE router may attach to CE devices in 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 the basic unit of interconnection is the site, the architecture described herein allows 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.
相互接続の基本単位はサイトであるが、本明細書に記載されるアーキテクチャは、相互接続の制御における粒度の細かい程度を可能にします。同じサイトで他のシステムのみイントラネットのメンバーであることに制限されてもよい、例えば、サイトで特定のシステムは、イントラネットのメンバーならびに1つのまたは複数のエクストラネットのメンバーであってもよいです。
Each PE router maintains one or more "per-site forwarding tables". Every site to which the PE router is attached is associated with one of these tables. A particular packet's IP destination address is looked up in a particular per-site forwarding table only if that packet has arrived directly from a site which is associated with that table.
各PEルータは、1つ以上の「サイトごとの転送テーブル」を維持しています。 PEルータが接続されているすべてのサイトは、これらのテーブルのうちの1つに関連付けられています。特定のパケットの宛先IPアドレスは、そのパケットは、そのテーブルに関連付けられているサイトから直接到着した場合にのみ、特定のサイトごとの転送テーブル内でルックアップされます。
How are the per-site forwarding tables populated?
どのようにサイトごとの転送テーブルが移入されますか？
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 which 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 which it has learned from CE1. PE2 and PE3 use these routes to populate the forwarding tables which they associate respectively with the sites of CE2 and CE3. Routes from sites which are not in VPN V do not appear in these forwarding tables, which means that packets from CE2 or CE3 cannot be sent to sites which 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のサイトとそれぞれ関連付ける転送テーブルを移入するためにこれらのルートを使用します。 VPN Vに含まれていないサイトからのルートはCE2やCE3からのパケットがVPN Vにないサイトに送信することができないことを意味し、これらの転送テーブルには表示されません。
If a site is in multiple VPNs, the forwarding table associated with that site can contain routes from the full set of VPNs of which the site is a member.
サイトが複数のVPNにある場合、そのサイトに関連付けられている転送テーブルは、サイトがメンバーであるVPNのフルセットからのルートを含むことができます。
A PE generally maintains only one forwarding table per site, even if it is multiply connected to that site. Also, different sites can share the same forwarding table if they are meant to use exactly the same set of routes.
PEは、一般に、それが乗算そのサイトに接続されている場合でも、サイトごとに1つだけ転送テーブルを維持します。彼らは正確にルートの同じセットを使用するように意図されている場合にも、別のサイトが同じ転送テーブルを共有することができます。
Suppose a packet is received by a PE router from a particular directly attached site, but the packet's destination address does not match any entry in the forwarding table associated with that site. If the SP is not providing Internet access for that site, then the packet is discarded as undeliverable. If the SP is providing Internet access for that site, then the PE's Internet forwarding table will be consulted. This means that in general, only one forwarding table per PE need ever contain routes from the Internet, even if Internet access is provided.
パケットが特定の直接接続されているサイトからPEルータによって受信されると仮定したが、パケットの宛先アドレスは、そのサイトに関連付けられている転送テーブル内のエントリと一致しません。 SPは、そのサイトのインターネットへのアクセスを提供していない場合、パケットが配信不能として破棄されます。 SPは、そのサイトのインターネットへのアクセスを提供している場合は、PEのインターネット転送テーブルが参照されます。これは、一般的には、PEごとに1つだけ転送テーブルは、これまでのインターネットアクセスが提供されている場合でも、インターネットからのルートが含まれている必要があることを意味します。
To maintain proper isolation of one VPN from another, it is important that no router in the backbone accept a labeled packet from any adjacent non-backbone device unless (a) the label at the top of the label stack was actually distributed by the backbone router to the non-backbone device, and (b) 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. These restrictions are necessary in order to prevent packets from entering a VPN where they do not belong.
別のVPNの適切な分離を維持するために、（a）は、ラベルスタックの最上部のラベルが実際バックボーンルータによって配布された場合を除き、バックボーンには、ルータは、任意の隣接する非バックボーン装置からラベル付きパケットを受け入れないことが重要です非バックボーンデバイスへ、および（b）のバックボーンルータは、パケットが検査されるスタックの下の任意のラベルの前にバックボーンを残すことになりますそのラベルの使用を決定することができ、およびIPヘッダの前に検査されます。これらの制限は、彼らが属していないVPNに入るのパケットを防ぐために必要です。
The per-site forwarding tables in a PE are ONLY used for packets which arrive from a site which is directly attached to the PE. They are not used for routing packets which arrive from other routers that belong to the SP backbone. As a result, there may be multiple different routes to the same system, where the route followed by a given packet is determined by the site from which the packet enters the backbone. E.g., one may have one route to a given system for packets from the extranet (where the route leads to a firewall), and a different route to the same system for packets from the intranet (including packets that have already passed through the firewall).
PEにおけるサイトごとの転送テーブルのみ直接PEに取り付けられているサイトから到着するパケットのために使用されます。これらは、SPバックボーンに所属する他のルータから到着したパケットをルーティングするために使用されていません。結果として、所与のパケットに続く経路はパケットがバックボーンに入り、そこからサイトによって決定されているのと同じシステムに複数の異なる経路が存在してもよいです。例えば、一方が一方（ルートはファイアウォールに至る）エクストラネットからのパケットのために与えられたシステムへのルート、および（既にファイアウォールを通過したパケットを含む）、イントラネットからのパケットのために同じシステムに異なる経路を有していてもよいです。
In some cases, a particular site may be divided by the customer into several virtual sites, perhaps by the use of VLANs. Each virtual site may be a member of a different set of VPNs. The PE then needs to contain a separate forwarding table for each virtual site. For example, if a CE supports VLANs, and wants each VLAN mapped to a separate VPN, the packets sent between CE and PE could be contained in the site's VLAN encapsulation, and this could be used by the PE, along with the interface over which the packet is received, to assign the packet to a particular virtual site.
いくつかのケースでは、特定のサイトは、おそらくのVLANを使用することにより、複数の仮想サイトに顧客によって分割することができます。各仮想サイトでは、VPNの異なるセットの部材であってもよいです。 PEは、各仮想サイトに別々の転送テーブルを含む必要があります。 CE VLANをサポートし、各VLANは別々のVPNにマッピングされたい場合、例えば、CEおよびPE間で送信されるパケットは、サイトのVLANカプセル化に含まれることができ、これは上インターフェースと共に、PEで使用することができますパケットは、特定の仮想サイトにパケットを割り当てるために、受信されます。
Alternatively, one could divide the interface into multiple "sub-interfaces" (particularly if the interface is Frame Relay or ATM), and assign the packet to a VPN based on the sub-interface over which it arrives. Or one could simply use a different interface for each virtual site. In any case, only one CE router is ever needed per site, even if there are multiple virtual sites. Of course, a different CE router could be used for each virtual site, if that is desired.
あるいは、（インターフェイスがフレームリレーまたはATMである場合は特に）複数の「サブインターフェース」にインターフェイスを分割し、それが到着する上サブインターフェースに基づいてVPNにパケットを割り当てることができます。または1つは、単純に、各仮想サイトごとに異なるインタフェースを使用することができます。いずれにせよ、一つだけCEルータは、これまでに複数の仮想サイトがある場合でも、サイトごとに必要とされています。それが希望される場合はもちろん、異なるCEルータは、各仮想サイトを使用することができます。
Note that in all these cases, the mechanisms, as well as the policy, for controlling which traffic is in which VPN are in the hand of the customer.
これらすべてのケースでは、メカニズムだけでなく、政策が、どのトラフィックを制御するためのVPNは、顧客の手にあるされていることに注意してください。
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, our out different network interfaces.
それは特定のホストが複数の仮想サイトであることが望まれる場合、そのホストがパケットが関連付けられている仮想サイト各パケットのために、決定しなければなりません。それは私たちのうち、異なるネットワーク・インタフェース、異なるVLAN上の異なる仮想サイトからのパケットを送信することにより、例えば、これを行うことができます。
These schemes do NOT require the CE to support MPLS. Section 8 contains a brief discussion of how the CE might support multiple virtual sites if it does support MPLS.
これらのスキームは、MPLSをサポートするためにCEを必要としません。第8章では、それはMPLSをサポートしている場合、CEは複数の仮想サイトをサポートするかもしれない方法の簡単な説明が含まれています。
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を使用します。
A BGP speaker can only install and distribute one route to a given address prefix. Yet we allow each VPN to have its own address space, which means that the same address can be used in any number of VPNs, where in each VPN the address denotes a different system. It follows that we need to allow BGP to install and distribute multiple routes to a single IP address prefix. Further, we must ensure that POLICY is used to determine which sites can be use which routes; given that several such routes are installed by BGP, only one such must appear in any particular per-site forwarding table.
BGPスピーカはのみ与えられたアドレスプレフィックスへのルートを1つインストールして配布することができます。しかし、我々は、各VPNが同じアドレスが各VPNでアドレスが別のシステムを表しVPNの任意の数で使用することができることを意味し、独自のアドレス空間を持つことができます。我々がBGPは単一のIPアドレスのプレフィックスに複数のルートをインストールし、配布できるようにする必要があるということになります。さらに、我々は、ポリシーはサイトがどのルートを使用することができるかを決定するために使用されていることを確認する必要があります。いくつかのそのようなルートがBGPによってインストールされていることを考えると、唯一のそのような任意の特定のサイトごとの転送テーブルに表示されなければなりません。
We meet these goals by the use of a new address family, as specified below.
下記の指定された私たちは、新しいアドレスファミリを使用することで、これらの目標を達成します。
The BGP Multiprotocol Extensions [3] 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 two 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 two different VPNs, it is possible to install two completely different routes to that address, one for each VPN.
BGPマルチプロトコル拡張機能は、[3] BGPは、複数の「アドレスファミリー」からのルートを運ぶことができます。私たちは、「VPN-IPv4アドレスファミリー」の概念を導入します。 VPN-IPv4アドレスは8バイトの「ルート識別子（RD）」で始まる4バイトのIPv4アドレスで終わる、12バイトの量です。 2つのVPNが同じIPv4アドレスのプレフィックスを使用する場合、PEはユニークなVPN-IPv4アドレスのプレフィックスにこれらを翻訳します。これは、同じアドレスが2つの異なるVPNで使用される場合、そのアドレスに2つの完全に異なる経路、各VPNのための1つをインストールすることが可能であることを保証します。
The RD does not by itself impose any semantics; it contains no information about the origin of the route or about 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.2).
RDは、それ自体で任意のセマンティクスを課しません。それは経路の起源について又は経路が分散されるべきVPNのセットに関する情報が含まれていません。 RDの目的は1つが、共通のIPv4アドレスのプレフィックスに明確なルートを作成できるようにするためだけです。他の手段は、経路を再配布する場所を決定するために使用される（セクション4.2参照）。
The RD can also be used to create multiple different routes to the very same system. In section 3, we gave an example where the route to a particular server had to 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.2.3) to decide which packets use which route.
RDはまた、非常に同じシステムに複数の異なる経路を作成するために使用することができます。セクション3では、我々は、特定のサーバへのルートは、エクストラネットのトラフィックよりもイントラネットトラフィックのために異なるように持っていた例を挙げました。これは、同じIPv4の一部が、別のRDを有する2つの異なるVPN-IPv4ルートを作成することによって達成することができます。これは、BGPは、同じシステムに複数の異なる経路をインストールすることができ、ポリシーがどの経路を使用するパケットかを決定する（セクション4.2.3を参照）を使用することが可能になります。
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 a two-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 which 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 IANA has assigned that ASN. RDs are given this structure in order to ensure that an SP which provides VPN backbone service can always create a unique RD when it needs to do so. However, the structuring provides no semantics. When BGP compares two such address prefixes, it ignores the structure entirely.
すべてのサービスプロバイダは、独自の「ナンバリングスペース」を管理できるようにRDSは、他のサービスプロバイダによって作られたRDの割り当てと競合することなく、（すなわち、のRDの独自の割り当てを行うことができます）構成されています。 RDは、2バイトのタイプフィールド、管理者フィールド、および割り当てられた番号フィールドで構成されています。タイプフィールドの値は、他の2つのフィールドの長さ、ならびに管理者フィールドのセマンティクスを決定します。管理者の欄には、割り当てられた番号の権限を識別し、割り当てられた番号フィールドは、特定の目的のために、識別権威によって、割り当てられた番号が含まれています。例えば、1は、その管理者フィールド（4バイト）数フィールドIANAがASNことを割り当てた人にSPによって割り当てられた番号が含まれている自律システム番号（ASN）、およびが含まれているRDを持つことができます。 RDSは、それはそうする必要があるときにVPNバックボーンサービスを提供してSPは常にユニークなRDを作成できることを確実にするために、この構造を与えられています。しかし、構造化は何の意味論を提供していません。 BGPは、2つのこのようなアドレスプレフィックスを比較した場合、それは完全に構造を無視します。
If the Administrator subfield and the Assigned Number subfield of a VPN-IPv4 address are both set to all zeroes, the VPN-IPv4 address is considered to have exactly the same meaning as the corresponding globally unique IPv4 address. In particular, this VPN-IPv4 address and the corresponding globally unique IPv4 address will be considered comparable by BGP. In all other cases, a VPN-IPv4 address and its corresponding globally unique IPv4 address will be considered noncomparable by BGP.
管理者のサブフィールドとVPN-IPv4アドレスの割り当てられた番号のサブフィールドが両方のすべてゼロに設定されている場合、VPN-IPv4アドレスは、対応するグローバルにユニークなIPv4アドレスとまったく同じ意味を持つと考えられています。特に、このVPN-IPv4アドレスと対応するグローバルにユニークなIPv4アドレスは、BGPにより、同等とみなされます。他のすべてのケースでは、VPN-IPv4アドレスとそれに対応するグローバルにユニークなIPv4アドレスは、BGPによって比較不可能とみなされます。
A given per-site forwarding table will only have one VPN-IPv4 route for any given IPv4 address prefix. When a packet's destination address is matched against a VPN-IPv4 route, only the IPv4 part is actually matched.
与えられたサイトごとの転送テーブルは、任意のIPv4アドレスのプレフィックスの1 VPN-IPv4ルートを持っています。パケットの宛先アドレスがVPN-IPv4ルートと照合されている場合、IPv4のみの部分は、実際には一致しています。
A PE needs to be configured to associate routes which lead to particular CE with a particular RD. The PE may be configured to associate all routes leading to the same CE with the same RD, or it may be configured to associate different routes with different RDs, even if they lead to the same CE.
PEは、特定のRDと特定のCEにつながるルートを関連付けるように構成する必要があります。 PEは、同じRDと同じCEに至るすべてのルートを関連付けるように構成されてもよく、または同じCEにつながる場合であっても、異なるのRDと異なる経路を関連付けるように構成されてもよいです。
In this section, we discuss the way in which the distribution of the VPN-IPv4 routes is controlled.
ここでは、VPN-IPv4ルートの分布を制御する方法を議論します。
Every per-site forwarding table is associated with one or more "Target VPN" attributes.
すべてのサイトごとの転送テーブルは、1つ以上の「ターゲットVPN」属性と関連付けられています。
When a VPN-IPv4 route is created by a PE router, it is associated with one or more "Target VPN" attributes. These are carried in BGP as attributes of the route.
VPN-IPv4ルートをPEルータによって作成されたとき、それは、1つまたは複数の関連付けられている「ターゲットVPN」が属性。これらは、ルートの属性としてBGPに運ばれます。
Any route associated with Target VPN T must be distributed to every PE router that has a forwarding table associated with Target VPN T. When such a route is received by a PE router, it is eligible to be installed in each of the PE's per-site forwarding tables that is associated with Target VPN T. (Whether it actually gets installed depends on the outcome of the BGP decision process.)
そのような経路がPEルータによって受信されるときに、ターゲットVPN Tに関連付けられた任意の経路が標的VPN T.関連付けられた転送テーブルを持つすべてのPEルータに配布する必要があり、PEのサイトごとのそれぞれに設置対象でありますターゲットVPN T.に関連付けされたテーブルの転送（それが実際にインストールされるかどうかは、BGP決定プロセスの結果に依存します。）
In essence, a Target VPN attribute identifies a set of sites. Associating a particular Target VPN attribute with a route allows that route to be placed in the per-site forwarding tables that are used for routing traffic which is received from the corresponding sites.
本質的には、ターゲットVPN属性は、サイトのセットを識別する。経路に特定のターゲットVPN属性の関連付け経路は、対応するサイトから受信されたトラフィックをルーティングするために使用されるサイトごとの転送テーブルに配置することが可能となります。
There is a set of Target VPNs that a PE router attaches to a route received from site S. And there is a set of Target VPNs that a PE router uses to determine whether a route received from another PE router could be placed in the forwarding table associated with site S. The two sets are distinct, and need not be the same.
サイトS.から受信したPEルータが別のPEルータから受信したルートが転送テーブルに配置することができるかどうかを決定するために使用するターゲットVPNのセットがあるPEルータが経路に付着することをターゲットVPNのセットが存在しますサイトS.に関連する2つのセットが区別され、同じである必要はありません。
The function performed by the Target VPN attribute is similar to that performed by the BGP Communities Attribute. However, the format of the latter is inadequate, since it allows only a two-byte numbering space. It would be fairly straightforward to extend the BGP Communities Attribute to provide a larger numbering space. It should also be possible to structure the format, similar to what we have described for RDs (see section 4.1), 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.
ターゲットVPN属性によって実行される機能は、BGPコミュニティ属性によって実行されるものと類似しています。それは2つだけのバイトの番号空間を可能にするので、後者の形式は、不十分です。より大きな番号のスペースを提供するために、BGPコミュニティ属性を拡張するために、非常に簡単になります。また、タイプフィールドは、管理者フィールドの長さを規定するように、我々はRDS（セクション4.1を参照）について記載したものと同様のフォーマットを、構成することが可能であるべきであり、属性の残りの部分は、指定された管理者の数でありスペースの番号。
When a BGP speaker has received two routes to the same VPN-IPv4 prefix, it chooses one, according to the BGP rules for route preference.
BGPスピーカが同じVPN-IPv4プレフィクスへの2つのルートを受信した場合には、ルートの嗜好のBGP規則に従って、いずれかを選択します。
Note that a route can only have one RD, but it can have multiple Target VPNs. In BGP, scalability is improved if one has a single route with multiple attributes, as opposed to multiple routes. One could eliminate the Target VPN attribute by creating more routes (i.e., using more RDs), but the scaling properties would be less favorable.
ルートは唯一のRDを持つことができることに注意してください、それは、複数のターゲットVPNを持つことができます。一つは複数の属性を持つ単一のルートを有する場合、複数の経路とは対照的に、BGPにおいて、スケーラビリティが向上します。一つは（すなわち、より多くのRDを使用して）複数のルートを作成することにより、ターゲットVPN属性を排除することができるが、スケーリング特性はあまり良好であろう。
How does a PE determine which Target VPN 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 particular site with a particular Target VPN. Or the PE might be configured to associate certain routes leading to a particular site with one Target VPN, and certain with another. Or the CE router, when it distributes these routes to the PE (see section 6), might specify one or more Target VPNs for each route. The latter method shifts the control of the mechanisms used to implement the VPN policies from the SP to the customer. If this method is used, it may still be desirable to have the PE eliminate any Target VPNs that, according to its own configuration, are not allowed, and/or to add in some Target VPNs that according to its own configuration are mandatory.
どのPEは、ターゲットVPNは、所定のルートに関連付ける属性を決定していますか？異なる可能ないくつかの方法があります。 PEは、特定のターゲットVPNと特定のサイトにつながるすべてのルートを関連付けるように構成されるかもしれません。またはPEは、一つのターゲットVPNと特定のサイトにつながる特定のルートを関連付けるように構成され、かつ互いに一定のかもしれません。それはPEにこれらのルートを分配するとき、またはCEルータは、各経路の1つまたは複数のターゲットVPNを指定するかもしれない、（セクション6を参照します）。後者の方法は、顧客へのSPからVPNポリシーを実装するために使用される機構の制御を移します。この方法を使用する場合、まだPEは、独自の構成によれば、許可されていない任意のターゲットVPNを排除、および/または独自の構成によれば必須であるいくつかのターゲットのVPNに追加することが望ましいかもしれません。
It might be more accurate, if less suggestive, to call this attribute the "Route Target" attribute instead of the "VPN Target" attribute. It really identifies only a set of sites which will be able to use the route, without prejudice to whether those sites constitute what might intuitively be called a VPN.
あまり示唆的かどうかは代わりに「VPNターゲット」属性の「ルートターゲット」属性この属性を呼び出すために、より正確かもしれません。それは本当に、これらのサイトは、直感的にVPNと呼ばれるかもしれないものを構成するかどうかに偏見なしに、ルートを使用することができるようになりますサイトのセットのみを識別します。
If two sites of a VPN attach to PEs which are in the same Autonomous System, the PEs can distribute VPN-IPv4 routes to each other by means of an IBGP connection between them. Alternatively, each can have an IBGP connection to a route reflector.
VPNの2つのサイトが同じ自律システムにあるPEに取り付ける場合、PEは、それらの間のIBGP接続によって相互にVPN-IPv4ルートを配布することができます。代替的に、それぞれがルートリフレクタとIBGP接続を有することができます。
If two sites of VPN are in different Autonomous Systems (e.g., because they are connected to different SPs), then a PE router will need to use IBGP to redistribute 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 will then need to use EBGP to redistribute those routes to an ASBR in another AS. This allows one to connect different VPN sites to different Service Providers. However, 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.
（それらは異なるSPに接続されているため、例えば）VPNの2つのサイトが異なる自律システムにある場合、PEルータは、自律システム境界ルータ（ASBR）に、またはのいずれかVPN-IPv4ルートを再配布するIBGPを使用する必要がありますルートリフレクタは、そのASBRは、クライアントです。 ASBRは、別のAS内のASBRにそれらのルートを再配布するEBGPを使用する必要があります。これは、1つは、異なるサービスプロバイダに異なるVPNサイトを接続することができます。しかし、VPN-IPv4ルートのみのSPとの間の信頼された装置の一部として、プライベートピアリングポイントでEBGP接続で受け入れられるべきです。 VPN-IPv4経路は、どちらに配布されなかったり、公衆インターネットから受け入れるべきです。
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 which 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、存在し得ます。
When a PE router distributes a VPN-IPv4 route via BGP, it uses its own address as the "BGP next hop". It also assigns and distributes an MPLS label. (Essentially, PE routers distribute not VPN-IPv4 routes, but Labeled VPN-IPv4 routes. Cf. [8]) When the PE processes a received packet that has this label at the top of the stack, the PE will pop the stack, and send the packet directly to the site from to which the route leads. This will usually mean that it just sends the packet to the CE router from which it learned the route. The label may also determine the data link encapsulation.
PEルータは、BGPを介してVPN-IPv4ルートを配布するとき、それは「BGPネクストホップ」として自身のアドレスを使用します。また、MPLSラベルを割り当て、配布しています。 （本質的には、PEルータはVPN-IPv4ルートをしないVPN-IPv4ルートを配布するが、標識された。Cfと[8]）PEがスタックの一番上にこのラベルを有する受信したパケットを処理するとき、PEは、スタックをポップし、どのルートがつながるからサイトに直接パケットを送信します。これは通常、それはちょうどそれがルートを学習したCEルータにパケットを送信することを意味します。ラベルは、データリンクのカプセル化を決定することができます。
In most cases, the label assigned by a PE will cause the packet to be sent directly to a CE, and the PE which receives the labeled packet will not look up the packet's destination address in any forwarding table. However, it is also possible for the PE to assign a label which implicitly identifies a particular forwarding table. In this case, the PE receiving a packet that label would look up the packet's destination address in one of its forwarding tables. While this can be very useful in certain circumstances, we do not consider it further in this paper.
ほとんどの場合、PEによって割り当てられたラベルは、パケットがCEに直接送信されることになります、とラベルされたパケットを受信したPEは、任意の転送テーブル内のパケットの宛先アドレスを検索しません。しかし、PEは暗黙特定の転送テーブルを識別するラベルを割り当てることも可能です。この場合、PEは、その転送テーブルの一つに、パケットの宛先アドレスをルックアップするでしょうラベルパケットを受信しました。これは特定の状況に非常に有用になることができますが、我々はこの論文ではさらにそれを考慮していません。
Note that the MPLS label that is distributed in this way is only usable if there is a label switched path between the router that installs a route and the BGP next hop of that route. We do not make any assumption about the procedure used to set up that label switched path. It may be set up on a pre-established basis, or it may be set up when a route which would need it is installed. It may be a "best effort" route, or it may be a traffic engineered route. Between a particular PE router and its BGP next hop for a particular route there may be one LSP, or there may be several, perhaps with different QoS characteristics. All that matters for the VPN architecture is that some label switched path between the router and its BGP next hop exists.
ラベルは、経路およびその経路のBGPネクストホップをインストールルータ間のパスを切り換えがある場合、このように分散されるMPLSラベルのみが使用可能であることに留意されたいです。私たちは、そのラベルを設定するために使用される手順についての仮定はパスを切り替えることはありません。これは、事前に確立された基準で設定することができる、またはそれを必要とするルートがインストールされている場合には、設定することができます。これは、「ベストエフォート」の経路であってもよいし、トラフィックエンジニアリング経路であり得ます。特定の経路のための特定のPEルータとそのBGPネクストホップの間に1つのLSPが存在してもよい、またはおそらくは異なるQoS特性を有する、いくつかが存在してもよいです。 VPNアーキテクチャのために重要なのは、いくつかのラベルがルータ間のパスを切り替え、そのBGPネクストホップが存在することです。
All the usual techniques for using route reflectors [2] to improve scalability, e.g., route reflector hierarchies, are available. If route reflectors are used, there is no need to have any one route reflector know all the VPN-IPv4 routes for all the VPNs supported by the backbone. One can have separate route reflectors, which do not communicate with each other, each of which supports a subset of the total set of VPNs.
ルートリフレクタ[2]スケーラビリティを向上させるために使用するためのすべての通常の技術は、例えば、ルートリフレクタ階層は、利用可能です。ルートリフレクタを使用している場合は、いずれかのルートリフレクタがバックボーンでサポートされているすべてのVPNのすべてのVPN-IPv4ルートを知る持ってする必要はありません。一つは、VPNの総セットのサブセットをサポートそれぞれが互いに連通していない別のルートリフレクタを有することができます。
If a given PE router is not attached to any of the Target VPNs of a particular route, it should not receive that route; the other PE or route reflector which is distributing routes to it should apply outbound filtering to avoid sending it unnecessary routes. Of course, if a PE router receives a route via BGP, and that PE is not attached to any of the route's target VPNs, the PE should apply inbound filtering to the route, neither installing nor redistributing it.
所与のPEルータが特定のルートのターゲットVPNのいずれかに結合されていない場合、そのルートを受けるべきではありません。それへのルートを配布している他のPEまたはルートリフレクタはそれを不要なルートを送信することを避けるためにアウトバウンドフィルタリングを適用すべきです。 PEルータは、BGPを経由する経路を受け取り、そのPEがルートのターゲットのVPNのいずれかに結合されていない場合はもちろん、PEは、ルート、どちらもインストールもそれを再配布するインバウンドフィルタリングを適用する必要があります。
A router which is not attached to any VPN, i.e., a P router, never installs any VPN-IPv4 routes at all.
任意のVPNに接続されていないルータは、すなわち、Pルータは、まったくVPN-IPv4ルートをインストールすることはありません。
These distribution rules ensure that there is no one box which needs to know all the VPN-IPv4 routes that are supported over the backbone. As a result, the total number of such routes that can be supported over the backbone is not bound by the capacity of any single device, and therefore can increase virtually without bound.
これらの配信ルールは、バックボーン上でサポートされているすべてのVPN-IPv4ルートを知る必要があります誰箱がないことを確認してください。その結果、主鎖上に支持することができるそのような経路の総数は、任意の単一デバイスの容量によって結合されていないので、事実上際限なく増加させることができます。
A VPN-IPv4 route may be optionally associated with a VPN of Origin attribute. This attribute uniquely identifies a set of sites, and identifies the corresponding route as having come from one of the sites in that set. Typical uses of this attribute might be to identify the enterprise which owns the site where the route leads, or to identify the site's intranet. However, other uses are also possible. This attribute could be encoded as an extended BGP communities attribute.
VPN-IPv4ルートは、任意の起源属性のVPNに関連付けられてもよいです。この属性は、一意のサイトのセットを識別し、そのセット内のサイトから来るものとして対応する経路を識別する。この属性の典型的な用途は、ルートがリードサイトを所有している企業を特定するために、またはサイトのイントラネットを識別するかもしれません。しかし、他の用途も可能です。拡張BGPコミュニティ属性としてこの属性は、エンコードすることができます。
In situations in which it is necessary to identify the source of a route, it is this attribute, not the RD, which must be used. This attribute may be used when "constructing" VPNs, as described below.
ルートのソースを識別するために必要である状況では、この属性ではなく、使用しなければならないRD、です。 VPNを「構築」するとき後述のように、この属性は、使用することができます。
It might be more accurate, if less suggestive, to call this attribute the "Route Origin" attribute instead of the "VPN of Origin" attribute. It really identifies the route only has having come from one of a particular set of sites, without prejudice as to whether that particular set of sites really constitutes a VPN.
あまり示唆的かどうかは「ルート起源」属性の代わりに、「VPN起源の」属性この属性を呼び出すために、より正確かもしれません。それは本当にサイトの特定のセットが実際にVPNを構成しているかどうかについての偏見なしに、サイトのみの特定のセットのいずれかから来ているルートを特定します。
By setting up the Target VPN and VPN of Origin attributes properly, one can construct different kinds of VPNs.
適切属性起源のターゲットVPNとVPNを設定することで、1は、VPNの種類を構築することができます。
Suppose it is desired to create a Closed User Group (CUG) which contains a particular set of sites. This can be done by creating a particular Target VPN attribute value to represent the CUG. This value then needs to be associated with the per-site forwarding tables for each site in the CUG, and it needs to be associated with every route learned from a site in the CUG. Any route which has this Target VPN attribute will need to be redistributed so that it reaches every PE router attached to one of the sites in the CUG.
サイトの特定のセットが含まれている非公開ユーザグループ（CUG）を作成することが望まれていると仮定します。これは、CUGを表現するために特定のターゲットVPN属性値を作成することによって行うことができます。この値は、CUGの各サイトごとのサイト転送テーブルに関連付けする必要があり、それはすべてのルートがCUG内のサイトから学んだに関連付けする必要があります。それはCUGのサイトのいずれかに取り付けたすべてのPEルータに到達するように、このターゲットVPN属性を持つすべてのルートを再配布する必要があります。
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 Target Attribute values, one meaning "Hub" and one meaning "Spoke". Then routes from the spokes could be distributed to the hub, without causing routes from the hub to be distributed to the spokes.
また、1を作成するには、どんな理由であれ、所望の「ハブとスポーク」VPNのようなものを想定。これは、2つの目標を使用することによって行うことができる値は、1つの意味「ハブ」属性と1つの意味「スポーク」。次いでスポークからのルートはスポークに配布するハブからルートを引き起こすことなく、ハブに分配することができます。
Suppose one has a number of sites which are in an intranet and an extranet, as well as a number of sites which are in the intranet only. Then there may be both intranet and extranet routes which have a Target VPN identifying the entire set of sites. The sites which are to have intranet routes only can filter out all routes with the "wrong" VPN of Origin.
1は、イントラネットやエクストラネットにあるサイトの数だけでなく、唯一のイントラネット内にあるサイトの数を持っていると仮定します。次に、サイトの全体のセットを識別するターゲットVPNを有し、イントラネットおよびエクストラネット両方の経路が存在してもよいです。イントラネットのルートを持っているサイトは、唯一の起源の「間違った」VPNを持つすべてのルートをフィルタリングすることができます。
These two attributes allow great flexibility in allowing one to control the distribution of routing information among various sets of sites, which in turn provides great flexibility in constructing VPNs.
これらの2つの属性が1ターンでVPNを構築する上で大きな柔軟性を提供してサイトの様々なセットの中の情報を、ルーティングの分布を制御することができるように大きな柔軟性を可能にします。
If the intermediate routes 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サイトから転送されたパケットは？
This is done by means of MPLS with a two-level label stack.
これは、2つのレベルのラベルスタックにMPLSを用いて行われます。
PE routers (and ASBRs which 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. (Certain procedures for setting up label switched paths in the backbone may not require the presence of the /32 address prefixes.)
（VPN-IPv4アドレスを再配布とのASBR）PEルータは、バックボーンのIGPルーティングテーブルに自分自身のために/ 32アドレスプレフィックスを挿入する必要があります。これは、各PEルータへのルートに対応するラベルを割り当てるために、バックボーンネットワーク内の各ノードで、MPLSを可能にします。 （ラベルを設定するための特定の手順は、/ 32アドレスプレフィックスの存在を必要としないかもしれないバックボーン内のパスを切り替えます。）
When a PE receives a packet from a CE device, it chooses a particular per-site forwarding table in which to look up the packet's destination address. Assume that a match is found.
PEはCEデバイスからパケットを受信すると、パケットの宛先アドレスを検索するには、特定のサイトごとの転送テーブルを選択します。一致が検出されたと仮定します。
If the packet is destined for a CE device attached to this same PE, the packet is sent directly to that CE device.
パケットが同じPEに取り付けられたCE装置宛である場合、パケットはそのCEデバイスに直接送信されます。
If the packet is not destined for a CE device attached to this same PE, the packet's "BGP Next Hop" is found, as well as the label which that BGP next hop assigned for the packet's destination address. This label is pushed onto the packet's label stack, and becomes the bottom label. Then the PE looks up the IGP route to the BGP Next Hop, and thus determines the IGP next hop, as well as the label assigned to the address of the BGP next hop by the IGP next hop. This label gets pushed on as the packet's top label, and the packet is then forwarded to the IGP next hop. (If the BGP next hop is the same as the IGP next hop, the second label may not need to be pushed on, however.)
パケットが同じPEに取り付けられたCE装置宛されていない場合は、パケットの「BGPネクストホップ」は、BGPネクストホップがパケットの宛先アドレスに割り当てられたことを見出し、ならびにラベルです。このラベルはパケットのラベルスタックにプッシュし、下のラベルとなっています。その後、PEは、BGPネクストホップへのIGPルートを検索し、従ってIGPネクストホップ、並びにIGPネクストホップによってBGPネクストホップのアドレスに割り当てられたラベルを決定します。このラベルはパケットのトップラベルとしてのプッシュされ、パケットはIGPネクストホップに転送されます。 （BGPネクストホップがIGPネクストホップと同じである場合、第二の標識は、しかし、上のプッシュする必要はないかもしれません。）
At this point, MPLS will carry the packet across the backbone and into the appropriate CE device. That is, all forwarding decisions by P routers and PE routers are now made by means of MPLS, and the packet's IP header is not looked at again until the packet reaches the CE device. The final PE router will pop the last label from the MPLS label stack before sending the packet to the CE device, thus the CE device will just see an ordinary IP packet. (Though see section 8 for some discussion of the case where the CE desires to received labeled packets.)
この時点で、MPLSバックボーンを越えて、適切なCEデバイスにパケットを運ぶでしょう。すなわち、PルータとPEルータによってすべての転送の決定は、現在MPLSを用いて作られており、パケットは、CEデバイスに到達するまで、パケットのIPヘッダは再び見ていません。最終PEルータは、このようにCEデバイスが普通のIPパケットが表示され、CEデバイスにパケットを送信する前に、MPLSラベルスタックから最後のラベルをポップします。 （ただし、CEは、標識されたパケットを受信することを望むケースのいくつかの議論のためにセクション8を参照）。
When a packet enters the backbone from a particular site via a particular PE router, the packet's route is determined by the contents of the forwarding table which that PE router associated with that site. The forwarding tables of the PE router where the packet leaves the backbone are not relevant. As a result, one may have multiple routes to the same system, where the particular route chosen for a particular packet is based on the site from which the packet enters the backbone.
パケットは、特定のPEルータを介して特定のサイトからバックボーンに入ると、パケットのルートは、PEルータがそのサイトに関連付けられている転送テーブルの内容によって決定されます。パケットがバックボーンの葉PEルータの転送テーブルは関係ありません。結果として、一つは特定のパケットのために選択された特定の経路は、パケットがバックボーンに入り、そこからサイトに基づいており、同じシステム、への複数の経路を有することができます。
Note that it is the two-level labeling that makes it possible to keep all the VPN routes out of the P routers, and this in turn is crucial to ensuring the scalability of the model. The backbone does not even need to have routes to the CEs, only to the PEs.
それが可能Pルータのうち、すべてのVPNルートを保つことができる2レベルの標識があり、これが今度はモデルの拡張性を確保するために重要であることに注意してください。バックボーンでも唯一のPEに、CEにルートを持っている必要はありません。
The PE routers which attach to a particular VPN need to know, for each of that VPN's sites, which addresses in that VPN are at each site.
そのVPNに対応し、そのVPNのサイトごとに、知っておく必要があり、特定のVPNに接続PEルータは各サイトです。
In the case where the CE device is a host or a switch, this set of addresses will generally be configured into the PE router attaching to that device. In the case where the CE device is a router, there are a number of possible ways that a PE router can obtain this set of addresses.
CEデバイスはホスト又はスイッチである場合には、アドレスのこのセットは、一般に、そのデバイスに取り付けるPEルータに設定されます。 CE装置がルータである場合には、PEルータがアドレスのセットを得ることができる可能な多くの方法があります。
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. In no case will routes from a site ever be leaked into the backbone's IGP.
PEは、設定RDを使用して、VPN-IPv4アドレスにこれらのアドレスを変換します。 PEは、その後BGPへの入力としてこれらのVPN-IPv4ルートを扱います。いかなる場合には、サイトからのルートは、これまで背骨のIGPに漏出されます。
Exactly which PE/CE route distribution techniques are possible depends on whether a particular CE is in a "transit VPN" or not. A "transit VPN" is one which contains a router that receives routes from a "third party" (i.e., from a router which is not in the VPN, but is not a PE router), and that redistributes those routes to a PE router. A VPN which 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 RIP peers, and the CE may use RIP to tell the PE router the set of address prefixes which 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
2. PEとCEルータは、RIPピアであってもよく、CEは、PEルータにCEルータのサイトで到達可能なアドレスプレフィックスのセットを伝えるためにRIPを使用することができます。 RIPは、CEに構成されている場合、注意が（すなわち、PEルータからCEルータによって学習されたアドレスプレフィックス）がPEにアドバタイズされることはありません他のサイトからのアドレスプレフィックスを確保するために注意しなければなりません。より正確には：PEルータは、PE1を言う場合、VPN-IPv4ルートを受信します
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 which is different than (i.e., contains a different RD than) R1.
R1、そして結果は、次にR2がない限り、（PE1及びPE2は、同じルータまたは異なるルータであってもよい場合）、バックそのCEのサイトからPEルータに分配PE2言ってはならない、CEへのIPv4ルートR2を分配するよう異なるVPN-IPv4ルートにPE2マップR2 R1（すなわち、異なるRDを含んでいます）。
3. The PE and CE routers may be OSPF peers. In this case, the site should be a single OSPF area, the CE should be an ABR in that area, and the PE should be an ABR which is not in that area. Also, the PE should report no router links other than those to the CEs which are at the same site. (This technique should be used only in stub VPNs.)
3. PEとCEルータがOSPFピアであってもよいです。この場合、サイトは単一のOSPFエリアであるべきで、CEは、その領域内のABRであるべきであり、PEはその領域でないABRであるべきです。また、PEは、同じサイトにあるCEにこれら以外のルータリンクをレポートするべきではありません。 （この技術はスタブのVPNにのみ使用されるべきです。）
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 which 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を。）
From a purely technical perspective, this is by far the best technique:
純粋に技術的な観点から、これは最善の手法です。
a) Unlike the IGP alternatives, this does not require the
PE to run multiple routing algorithm instances in order
to talk to multiple CEs
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. For example, the CE may suggest a particular Target for each route, from among the Target attributes that the PE is authorized to attach to the route.
D）BGPの使用は、それが簡単にCEがPEへのルートの属性を渡すようになります。例えば、CEは、ターゲットがPEがルートに接続を許可されていること属性の中から、各経路の特定の標的を示唆し得ます。
On the other hand, using BGP is likely to be something new for the CE administrators, except in the case where the customer itself is already an Internet Service Provider (ISP).
一方、BGPを使用すると、顧客自身が既にインターネットサービスプロバイダ（ISP）である場合を除いて、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 which 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）を持つ必要はないことに注意してください。トランジットVPNではありません、そのサイトのすべてのCEは同じASNを使用することができます。これは、プライベートASN空間から選択することができ、それがPEによって取り除かれます。ルーティングループがorigin属性のサイトを使用することによって防止される（下記参照）。
If a set of sites constitute a transit VPN, it is convenient to represent them as a BGP Confederation, so that the internal structure of the VPN is hidden from any router which is not within the VPN. In this case, each site in the VPN would need two BGP connections to the backbone, one which is internal to the confederation and one which is external to it. The usual intra-confederation procedures would have to be slightly modified in order to take account for the fact that the backbone and the sites may have different policies. The backbone is a member of the confederation on one of the connections, but is not a member on the other. These techniques may be useful if the customer for the VPN service is an ISP. This technique allows a customer that is an ISP to obtain VPN backbone service from one of its ISP peers.
サイトの集合がトランジットVPNを構成する場合はVPNの内部構造は、VPN内にない任意のルータから隠されているように、BGPコンフェデレーションとしてそれらを表現するために便利です。この場合、VPN内の各サイトは、バックボーン、連合の内部で1、それの外部にある一から二BGP接続が必要になります。通常のイントラコンフェデレーション手順が少しバックボーンとサイトが異なるポリシーを持っている可能性があるという事実のために考慮するために修正しなければならないであろう。バックボーンは、接続のいずれに同盟のメンバーであるが、他のメンバーではありません。 VPNサービスの顧客がISPである場合には、これらの技術は有用である可能性があります。この技術は、そのISPピアの1つからVPNバックボーンサービスを得るためのISPである顧客を可能にします。
(However, if a VPN customer is itself an ISP, and its CE routers support MPLS, a much simpler technique can be used, wherein the ISP is regarded as a stub VPN. See section 8.)
（VPNの顧客がISP自体であり、そのCEルータがMPLSをサポートする場合は、はるかに単純な手法は、ISPはスタブVPNとみなされており、使用することができる。セクション8を参照します）。
When we do not need to distinguish among the different ways in which a PE can be informed of the address prefixes which exist at a given site, we will simply say that the PE has "learned" the routes from that site.
我々はPEが特定のサイトに存在するアドレスプレフィックスの通知をすることができるさまざまな方法を区別する必要がない場合は、我々は単にPEは、そのサイトからのルートを「学習」していると言うだろう。
Before a PE can redistribute a VPN-IPv4 route learned from a site, it must assign certain attributes to the route. There are three such attributes:
PEがサイトから学んだVPN-IPv4ルートを再配布する前に、それがルートに特定の属性を割り当てる必要があります。このような3つの属性があります。
- Site of Origin
- 起源のサイト
This attribute uniquely identifies the site from which the PE router learned the route. All routes learned from a particular site must be assigned the same Site of Origin attribute, even if a site is multiply connected to a single PE, or is connected to multiple PEs. Distinct Site of Origin attributes must be used for distinct sites. This attribute could be encoded as an extended BGP communities attribute (section 4.2.1).
この属性は一意にPEルータがルートを学習したサイトを識別します。特定のサイトから学んだすべてのルートは、サイトを乗算単一PEに接続されている、または複数のPEに接続されている場合でも、起源属性の同じサイトを割り当てる必要があります。起源属性の異なる部位は異なる部位に使用する必要があります。この属性は、拡張BGPコミュニティ属性（セクション4.2.1）としてエンコードすることができます。
- VPN of Origin
- 起源のVPN
See section 4.2.1.
セクション4.2.1を参照してください。
- Target VPN
- ターゲットVPN
See section 4.2.1.
セクション4.2.1を参照してください。
In this section, we assume that the CE device is a router.
このセクションでは、我々は、CEデバイスがルータであることを前提としています。
In general, a PE may distribute to a CE any route which the PE has placed in the forwarding table which it uses to route packets from that CE. There is one exception: 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にPEは、それがそのCEからパケットをルーティングするために使用する転送テーブルに配置された任意の経路を配布することができます。 1つの例外があります：起源属性のルートのサイトは、特定のサイトを識別する場合、そのルートは、そのサイトのすべての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 which 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からのルートを配布するために使用されます。
In the case where the CE supports MPLS, AND is willing to import the complete set of routes from its VPNs, the PE can distribute to it a label for each such route. When the PE receives a packet from the CE with such a label, it (a) replaces that label with the corresponding label that it learned via BGP, and (b) pushes on a label corresponding to the BGP next hop for the corresponding route.
CEがMPLSをサポートし、そのVPNのルートからの完全なセットをインポートする意思がある場合には、PEは、そのような各経路のためにそれにラベルを分配することができます。 PEは、そのようなラベルとCEからパケットを受信すると、（A）は、BGPを介して学習し、（b）は、対応するルートのBGPネクストホップに対応するラベルを押圧対応するラベルとそのラベルを置き換えます。
If the CE/PE route distribution is done via BGP, the CE can use MPLS to support multiple virtual sites. The CE may itself contain a separate forwarding table for each virtual site, which it populates as indicated by the VPN of Origin and Target VPN attributes of the routes it receives from the PE. If the CE receives the full set of routes from the PE, the PE will not need to do any address lookup at all on packets received from the CE. Alternatively, the PE may in some cases be able to distribute to the CE a single (labeled) default route for each VPN. Then when the PE receives a labeled packet from the CE, it would know which forwarding table to look in; the label placed on the packet by the CE would identify only the virtual site from which the packet is coming.
CE / PE経路分布をBGPを介して行われる場合、CEは、複数の仮想サイトをサポートするためにMPLSを使用することができます。 CE自体は、それがPEから受け取った経路の起源のVPNとターゲットVPN属性によって示されるように、それが移入各仮想サイトのための別個の転送テーブルを含んでいてもよいです。 CEがPEからのルートのフルセットを受信した場合、PEがCEから受信したパケット上で、すべての任意のアドレスの検索を行う必要はありません。代替的に、PEは、ある場合にはCEに各VPNのための単一の（標識された）デフォルトルートを配布することができるかもしれません。 PEは、CEからの標識されたパケットを受信したときに、それが中に見ているフォワーディングテーブルを知っているであろう。 CEによってパケット上に置かれたラベルは、パケットが来ているからだけで仮想サイトを識別します。
If a particular VPN is actually an ISP, but its CE routers support MPLS, then the VPN can actually be treated as a stub VPN. The CE and PE routers need only exchange routes which are internal to the VPN. The PE router would distribute to the CE router a label for each of these routes. Routers at different sites in the VPN can then become BGP peers. When the CE router looks up a packet's destination address, the routing lookup always resolves 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.
特定のVPNが実際ISPであるが、そのCEルータがMPLSをサポートしている場合、次にVPNは実際にスタブVPNとして扱うことができます。 CEおよびPEルータはVPNの内部にのみ交換ルートを必要とします。 PEルータは、これらの経路のそれぞれについて、CEルータにラベルを分配することになります。 VPNで異なるサイトのルータは、BGPピアになることができます。 CEルータは、パケットの宛先アドレスをルックアップするとき、ルーティングルックアップは常に内部アドレス、パケットのBGPネクストホップの通常のアドレスに解決されます。 CEは適切パケットをラベル及びPEにパケットを送信します。
Under the following conditions:
以下の条件の下で：
a) labeled packets are not accepted by backbone routers from untrusted or unreliable sources, 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
A）標識されたパケットは、そのようなパケットはIPヘッダまたはスタックの下位に検査される任意のラベルの前にバックボーンを残すことが知られていない限り、信頼できない、または信頼できないソースからのバックボーンルータによって受け入れられ、そしてれません
b) labeled VPN-IPv4 routes are not accepted from untrusted or unreliable sources,
b）は、VPN-IPv4経路は、信頼できない、または信頼できないソースから受け付けていない標識されました、
the security provided by this architecture is virtually identical to that provided to VPNs by Frame Relay or ATM backbones.
このアーキテクチャによって提供されるセキュリティは、フレームリレーやATMバックボーンでVPNに提供されるものと実質的に同じです。
It is worth noting that the use of MPLS makes it much simpler to provide this level of security than would be possible if one attempted to use some form of IP-within-IP tunneling in place of MPLS. It is a simple matter to refuse to accept a labeled packet unless the first of the above conditions applies to it. It is rather more difficult to configure the a router to refuse to accept an IP packet if that packet is an IP-within-IP tunnelled packet which is going to a "wrong" place.
これは、MPLSの使用は、それははるかに簡単な1がMPLSの代わりにIP-内-IPトンネリングのいくつかのフォームを使用しようとした場合に可能であるよりもこのレベルのセキュリティを提供することができることは注目に値します。上記の条件の最初は、それに適用されない限り、ラベル付きパケットを受け入れることを拒否することは簡単なことです。それは、そのパケットは、「間違った」場所に起こっているパケットをIP-内-IPトンネルされる場合は、IPパケットを受け入れることを拒否するようにルータを設定するために、むしろより困難です。
The use of MPLS also allows a VPN to span multiple SPs without depending in any way on the inter-domain distribution of IPv4 routing information.
MPLSの使用はまた、VPNは、IPv4ルーティング情報のドメイン間分布に何らかの方法で依存することなく、複数のSPにまたがることを可能にします。
It is also possible for a VPN user to provide himself with enhanced security by making use of Tunnel Mode IPSEC [5]. This is discussed in the remainder of this section.
これは、VPNユーザがトンネルモードIPSECを利用することにより、高度なセキュリティで自分自身を提供することも可能である[5]。これは、このセクションの残りの部分で説明されています。
A security-conscious VPN user might want to ensure that some or all of the packets which traverse the backbone are authenticated and/or encrypted. The standard way to obtain this functionality today would be to create a "security tunnel" between every pair of CE routers in a VPN, using IPSEC Tunnel Mode.
セキュリティ意識の高いVPNユーザは、バックボーンを通過するパケットの一部またはすべてが認証および/または暗号化されていることを確認したい場合があります。今日、この機能を入手するための標準的な方法は、IPSECトンネルモードを使用して、VPNにCEルータの各ペア間の「セキュリティトンネル」を作成することです。
However, the procedures described so far do not enable the CE router transmitting a packet to determine the identify of the next CE router that the packet will traverse. Yet that information is required in order to use Tunnel Mode IPSEC. So we must extend those procedures to make this information available.
しかし、これまでに説明した手順は、パケットが横断する次のCEルータの識別を決定するためにパケットを送信するCEルータを有効にしないでください。しかし、その情報はトンネルモードIPSECを使用するために必要とされます。だから我々は、この情報を利用できるように、これらの手順を拡張する必要があります。
A way to do this is suggested in [6]. Every VPN-IPv4 route can have an attribute which identifies the next CE router that will be traversed if that route is followed. If this information is provided to all the CE routers in the VPN, standard IPSEC Tunnel Mode can be used.
これを行う方法は、[6]で提案されました。すべてのVPN-IPv4ルートは、そのルートが続く場合トラバースされる次のCEルータを識別する属性を持つことができます。この情報はVPN内のすべてのCEルータに提供されている場合は、標準のIPSECトンネルモードを使用することができます。
If the CE and PE are BGP peers, it is natural to present this information as a BGP attribute.
CEおよびPEは、BGPピアである場合は、BGP属性としてこの情報を提供するように自然です。
Each CE that is to use IPSEC should also be configured with a set of address prefixes, such that it is prohibited from sending insecure traffic to any of those addresses. This prevents the CE from sending insecure traffic if, for some reason, it fails to obtain the necessary information.
IPSECを使用することで、各CEも、それはこれらのアドレスのいずれかに安全でないトラフィックを送信することが禁止されるように、アドレスプレフィックスのセットで構成されなければなりません。 、何らかの理由で、それは必要な情報を取得するために失敗した場合、これは安全でないトラフィックを送信してからCEを防ぐことができます。
When MPLS is used to carry packets between the two endpoints of an IPSEC tunnel, the IPSEC outer header does not really perform any function. It might be beneficial to develop a form of IPSEC tunnel mode which allows the outer header to be omitted when MPLS is used.
MPLSはIPSECトンネルの2つのエンドポイント間でパケットを運ぶために使用される場合、IPSEC外部ヘッダは、実際に任意の機能を実行しません。 MPLSを使用した場合に外部ヘッダを省略することを可能にするIPSecトンネルモードの形態を開発することは有益かもしれません。
Instead of setting up a security tunnel between each pair of CE routers, it may be advantageous to set up a single, multiparty security association. In such a security association, all the CE routers which are in a particular VPN would share the same security parameters (.e.g., same secret, same algorithm, etc.). Then the ingress CE wouldn't have to know which CE is the next one to receive the data, it would only have to know which VPN the data is going to. A CE which is in multiple VPNs could use different security parameters for each one, thus protecting, e.g., intranet packets from being exposed to the extranet.
代わりに、CEルータの各ペアの間でセキュリティトンネルを設定するのではなく、単一の、マルチパーティセキュリティアソシエーションをセットアップすることが有利であり得ます。そのようなセキュリティ関連して、特定のVPNにあるすべてのCEルータは、同じセキュリティパラメータ（.e.g。、同じ秘密、同じアルゴリズム、等）を共有することになります。そして、入口CEは、それが唯一のデータがしようとしているVPNを知っている必要があります、データを受信するための次の一つであるCE知っている必要はないでしょう。複数のVPNにあるCEは、したがって、例えば、エクストラネットにさらされるからイントラネット・パケットを保護し、それぞれに異なるセキュリティパラメータを使用することができます。
With such a scheme, standard Tunnel Mode IPSEC could not be used, because there is no way to fill in the IP destination address field of the "outer header". However, when MPLS is used for forwarding, there is no real need for this outer header anyway; the PE router can use MPLS to get a packet to a tunnel endpoint without even knowing the IP address of that endpoint; it only needs to see the IP destination address of the "inner header".
「外部ヘッダ」のIP宛先アドレスフィールドに入力する方法がないので、このような方式で、標準的なトンネルモードIPSECを使用することができませんでした。 MPLSを転送するために使用される場合しかし、とにかくこのアウターヘッダのための実際の必要がありません。 PEルータでもそのエンドポイントのIPアドレスを知らなくても、トンネルのエンドポイントにパケットを取得するためにMPLSを使用することができます。それが唯一の「インナーヘッダ」のIP宛先アドレスを参照する必要があります。
A significant advantage of a scheme like this is that it makes routing changes (in particular, a change of egress CE for a particular address prefix) transparent to the security mechanism. This could be particularly important in the case of multi-provider VPNs, where the need to distribute information about such routing changes simply to support the security mechanisms could result in scalability issues.
このようなスキームの重要な利点は、それがルーティング変更を行うことがある（特に、特定のアドレスプレフィックスの出力CEの変化）のセキュリティメカニズムに透明。これは、単にセキュリティメカニズムをサポートするために、ルーティングの変更についての情報を配布する必要がスケーラビリティの問題につながる可能性があり、マルチプロバイダVPNの場合に特に重要であり得ます。
Another advantage is that it eliminates the need for the outer IP header, since the MPLS encapsulation performs its role.
別の利点は、MPLSカプセル化がその役割を行うので、それは、外側の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 [10], or, where ATM is used as the backbone, through the use of ATM QoS capabilities. The traffic engineering work discussed in [1] is also directly applicable to MPLS/BGP VPNs. Traffic engineering could even be used to establish LSPs 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 [7] may be useful. An SP may apply either intserv or diffserv capabilities to a particular VPN, as appropriate.
この論文の焦点ではないが、サービスの質は、任意のVPNサービスの重要な要素です。 MPLS / BGPのVPNにおいて、既存のL3 QoS機能は、ATMのQoS機能を使用することにより、ATMをバックボーンとして使用されるシムヘッダ[10]、または、で「実験」ビットを使用することによってラベル付きパケットに適用することができます。 [1]で説明したトラフィックエンジニアリング作業もMPLS / BGPのVPNに直接適用可能です。トラフィックエンジニアリングであってもそれが望ましい場合は、サイトの特定のペア間の特定のQoS特性を持つLSPを確立するために使用することができます。 MPLS / BGP VPNが複数のSPに及ぶ場合、に記載アーキテクチャは、[7]に有用であり得ます。 SPは、必要に応じて、特定のVPNへのIntServや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 (which are neither PE routers nor Route Reflectors), and, in the case of multi-provider VPNs, (d) ASBRs.
サービスプロバイダバックボーンネットワークは、（a）は、PEルータで構成され、（b）は、BGPルートリフレクタ、（C）のP（いずれもPEルータでもルートリフレクタである）、ルータ、及び、マルチプロバイダVPNの場合には、（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 to maintains VPN routes, but only for those VPNs to which it is directly attached.
PEルータは、VPNルートを維持するが、それだけが直接取り付けられるものVPNのために。
Route reflectors and ASBRs can be partitioned among VPNs so that each partition carries routes for only a subset of the VPNs provided by the Service Provider. Thus no single Route Reflector or ASBR is required to maintain routes for all the VPNs.
各パーティションは、サービスプロバイダによって提供されるVPNのサブセットのみのルートを運ぶようにルートリフレクタとのASBRは、VPN間で分割することができます。したがって単一のルートリフレクタまたはASBRは、すべてのVPNの経路を維持するために必要とされません。
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の数の増加をサポートするためのネットワークの総容量は、任意の個々のコンポーネントの容量によって限定されるものではありません。
Cisco Systems may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non-discriminatory terms.
シスコシステムズは、本文書に開示された技術のすべてのいくつかのための特許またはその他の知的財産の保護を求めることができます。本書に起因するすべての基準があるか、シスコシステムズに割り当てられた1つまたは複数の特許により保護さとなった場合、シスコはこれらの特許を開示し、合理的かつ非差別的な条件でそれらのライセンスを取得する予定です。
Security issues are discussed throughout this memo.
セキュリティの問題は、このメモ中で議論されています。
Significant contributions to this work have been made by Ravi Chandra, Dan Tappan and Bob Thomas.
この作品への重要な貢献はラヴィチャンドラ、ダンタッパンボブトーマスによって行われています。
Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
エリックC.ローゼンシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Yakov Rekhter Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
ヤコフ・レックターシスコシステムズ社170タスマン・ドライブサンノゼ、CA、95134
EMail: yakov@cisco.com
メールアドレス：yakov@cisco.com
[1] Awduche, Berger, Gan, Li, Swallow, and Srinavasan, "Extensions to RSVP for LSP Tunnels", Work in Progress.
[1] Awduche、バーガー、ガン、李、ツバメ、およびSrinavasanを、進行中で働いて "LSPトンネルのためのRSVPへの拡張"。
[2] Bates, T. and R. Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.
[2]ベイツ、T.、およびR. Chandrasekaranは、 "BGPルートリフレクション：フルメッシュIBGPへの代替"、RFC 1966、1996年6月。
[3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998.
[3]ベイツ、T.、チャンドラ、R.、カッツ、D.およびY. Rekhter、 "BGP4のためのマルチプロトコル拡張機能"、RFC 2283、1998年2月。
[4] Gleeson, Heinanen, and Armitage, "A Framework for IP Based Virtual Private Networks", Work in Progress.
[4]グリーソン、Heinanen、およびアーミテージ、「IPベースの仮想プライベートネットワークのための枠組み」、進行中の作業を。
[5] Kent and Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5]ケントとアトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC 2401、1998年11月。
[6] Li, "CPE based VPNs using MPLS", October 1998, Work in Progress.
[6]李、 "MPLSを使用したCPEベースのVPN" を、1998年10月、進行中の作業。
[7] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[7]李、T.とY. Rekhter、 "差別化サービスおよびトラフィックエンジニアリングのためのプロバイダのアーキテクチャ（ペースト）"、RFC 2430、1998年10月に。
[8] Rekhter and Rosen, "Carrying Label Information in BGP4", Work in Progress.
「BGP4でラベル情報を運ぶ」[8] Rekhterとローゼンは進行中で働いています。
[9] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", Work in Progress.
[9]ローゼン、Viswanathanの、そしてCallon、 "マルチプロトコルラベルスイッチングアーキテクチャ" を、進行中の作業。
[10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", Work in Progress.
[10]ローゼン、Rekhter、タッパン、ファリナッチ、Fedorkow、李、およびコンタ、 "MPLSラベルスタックコード化" が進行中で働いています。
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。