原文：ftp://ftp.rfc-editor.org/in-notes/rfc2547.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
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 (C) The Internet Society (1999). All Rights Reserved.
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(Virtual Private Network)を提供する方法について説明している。MPLS(Multiprotocol Label Switching)はバックボーン越しにパケットを転送するために使用され、BGP(Border Gateway Protocol)はバックボーン越しに経路を配布するために使用される。この手法の主な目的は、企業ネットワークのための IP バックボーンの外部委託をサポートすることである。これは企業にとって単純でありながら、サービスプロバイダにとっては拡張性と柔軟性とを保ち、さらにサービスプロバイダが付加価値を加えることを可能にする方法で行われる。これらの手法は、それ自身が顧客に IP サービスを提供する VPN を提供するためにも利用することもできる。
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. 私たちが "バックボーン(backbone)" と呼ぶであろう共有ネットワークに接続している "サイト(sites)" の集合を考える。その集合のサブセットを多数作成するために、いくつかのポリシーを適用し、次の規則を課すとしよう：ある二つのサイトは、少なくとも一組のサブセットが両サイトを含む場合に限り、そのバックボーン越しの 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. 私たちが作成したサブネットこそ、"仮想プライベートネットワーク(Virtual Private Network)"(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 はその企業の "イントラネット(intranet)" である。ある VPN 内の各サイトを異なる企業が所有している場合、その VPN は "エクストラネット(extranet)" である。ひとつのサイトは二つ以上の 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. ひとつ以上のサービスプロバイダ(SP)がバックボーンを所有、運営している場合について考えてみよう。それらのサイトの所有者は、その SP の "顧客(customers)" である。ある特定のサイトの集合が VPN であるかどうかを決めるのは、その顧客のポリシーである。顧客によってはそのようなポリシーの実施を完全に SP 側の負担にしたいと考えるだろう。そうではない顧客は自分たちでそのポリシーを実施するか、実施する負担を SP と共有したいと望むかもしれない。私たちはこの文書において、これらのポリシーを実施するために使用できるメカニズムについて主に議論する。私たちの説明するメカニズムは、これらのポリシーを SP 単独で、あるいは VPN の顧客が SP と共同で実施するのに、十分に一般化されている。しかしながら大部分の議論は前者に焦点を当てている。
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 の中で各サイトが他の全サイトに直接の経路を持つようにする("フルメッシュ(full mesh)")こともできるし、特定のサイトの組が互いに直接の経路を持たないように制限する("部分メッシュ(partial mesh)")こともできる。
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. 私たちは、各サイトにひとつ以上のカスタマーエッジ(CE)デバイスが存在し、その各デバイスがひとつ以上のプロバイダエッジ(PE)ルータに、何らかのデータ回線(例えば PPP・ATM・イーサネット・フレームリレー・GRE トンネルなど)を経由して接続していると仮定する。
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. ある PE ルータが特定の VPN 内の CE デバイスに接続している場合、私たちは「その PE ルータはその VPN に接続している」と言う。同じように、PE ルータがある特定のサイト内の 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 のルーティングピアであるが、他のサイトの 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). SP とその顧客との間に明確な管理境界を維持することは重要である([4] 参照)。PE ルータと P ルータとは SP のみによって管理されるべきであり、SP の顧客はそれらへの管理アクセス権を持つべきではない。CE デバイスは顧客のみによって管理されるべきである(その顧客が管理サービスを SP に委託する契約をしている場合を除く)。
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 の所有者は、管理すべきバックボーンを持たないだけでなく、"仮想バックボーン(virtual backbone)" さえ持たない。SP は各々の VPN のために個別のバックボーンも "仮想バックボーン(virtual backbone)" も管理しなくてよい。バックボーン内のサイト-サイト間のルーティングは(VPN を形成するために使用されるポリシーの制約の下で)最適であり、トンネルの見かけ上の "仮想トポロジー(virtual topology)" による制約をまったく受けない。
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、B、C から成るイントラネットと、サイト A、B、C および "外部の(foreign)" サイト D から成るエクストラネットがあると仮定する。サイト A にサーバーが存在し、サイト 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. これは、サーバーへの経路を二つ設定可能でなければならないことを意味する。ひとつ目の経路はサイト B と C とによって使用され、トラフィックをサイト A に直接運ぶ。二つ目の経路はサイト D によって使用され、トラフィックをサイト B のファイアウォールに運ぶ。ファイアウォールがそのトラフィックの通過を許可すれば、それはサイト 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 に対応する転送テーブルは、少なくともひとつの VPN を S と共有する他のサイトへの経路のみを持つ。これは共有 VPN を持たないサイト間での通信を防ぐと共に、共有サイトを持たない二つの 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 デバイスに接続していない他のルータ(Pルータ)と PE ルータとから構成される。
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 ネットワーク間の境界をまたぐ場合、私たちはその二つのプロバイダ間に、プライベートな取り決めによって実現された相互信頼があると仮定する。具体的にいうと各プロバイダは、他のプロバイダが正しいルーティング情報だけを通すこと、そしてパケットが信頼できる送信元によって(MPLS[9] における意味において)ラベル付けされていた場合にのみ、そのラベル付けされたパケットを通過させることを信頼しなければならない。さらに私たちは、ラベルの切り替えられた経路がサービスプロバイダ間の境界をまたぐことが可能であると仮定する。
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. 暗号によるセキュリティ対策を行わない場合でも、VPN モデルはレベル 2 のバックボーン(例 フレームリレー)を使用する場合に得られるものに等しいレベルのセキュリティを提供するべきである。すなわち、誤った設定や故意により異なる 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 接続性を持つならば、それらの組織はひとつのサイトであり、それらの間の通信はバックボーンを使うことなく行われる。一般に、ひとつのサイトは地理的に近い組織の集まりから構成されるだろう。しかしながらこれは常に正しいわけではない。(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 デバイスは、(たとえひとつのサイトが複数の "仮想サイト(virtual sites)" から構成されているように見えても)常に単独のサイトに属するとみなされる。しかしながら、ひとつのサイトが複数の 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 デバイスに接続してよい(それらの CE デバイスが同じ VPN の中に存在しようと、異なる VPN の中に存在しようと)。堅牢性のために、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. 相互接続の基本単位はサイトであるが、ここで説明するアーキテクチャは、さらに細かい粒度の制御も許可している。例えば、あるサイトの特定の組織がひとつ以上のエクストラネットのメンバーであると同時に、ひとつのイントラネットのメンバーであってもよく、その一方で、同じサイトの他の組織はそのイントラネットだけのメンバーであるように制限されてもよい。
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 ルータはひとつ以上の "サイト別転送テーブル(per-site forwarding tables)" を保持する。PE ルータが接続しているサイトはすべて、これらのテーブルのひとつに対応する。ある特定のパケットの 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 は CE1 から知った経路を BGP を使用して PE2 と PE3 とに配布する。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 は、たとえあるサイトに複数の接続を持っていたとしても、サイトごとに唯ひとつの転送テーブルを保持する。また、異なるサイトが全く同じ経路の集合を使用するつもりであれば、同じ転送テーブルを共有することもできる。
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 ごとの唯一の転送テーブルはインターネットからの経路を常に含む必要があることを意味する。
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 が他の 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 の場合)、インターフェイスを複数の "サブインターフェイス(sub-interfaces)" に分割し、パケットをそれが届いたサブインターフェイスに基いて VPN に割り当てることもできる。もしくは単純に、各々の仮想サイトごとに異なるインターフェイスを使用してもよい。いずれにせよ、たとえ複数の仮想サイトが存在しても、サイトごとに唯ひとつの 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. これらの仕組みは CE が MPLS をサポートすることを必要としない。CE が MPLS をサポートす\る場合にどのようにして複数の仮想サイトをサポートすればよいかに付いて、セクション 8 に簡潔な考察が含まれている。
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 スピーカは、特定のアドレスプレフィクスに対して唯ひとつだけの経路を設定および配布できる。今のところ私たちは、各々の 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 マルチプロトコル拡張(BGP Multiprotocol Extensions) [3] は、BGP が複数の "アドレスファミリ(address families)" に由来する経路を転送することを可能にする。私たちは "VPN-IPv4 アドレスファミリ" の概念を取り入れる。VPN-IPv4 アドレスは 12 バイトで、8 バイトの "経路識別子(RD:Route Distinguisher)" で始まり、4 バイトの IPv4 アドレスで終わる。二つの VPN が同じ IPv4 アドレスプレフィクスを使用している場合、PE はそれらをユニークな VPN-IPv4 アドレスプレフィクスに変換する。これは、二つの異なる VPN において同じアドレスが使用されている場合に、それらのアドレスに対して完全に異なる二つ(各々の VPN にひとつずつ)のアドレスの導入が可能であることを保証する。
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 自身はいかなるセマンティクスも課さない。RD はその経路が配布される VPN の集合や、その経路の出所に関する情報を持たない。RD の目的は、単に一般的な 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 を持つ異なる 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. RD は、すべてのサービスプロバイダが他のプロバイダの作成した RD の割り当てと競合すること無く、自身の "番号空間(numbering space)" を管理できるように(つまり、RD 独自の割り当てが可能なように)設計されている。RD は、2 バイトの型フィールド、ひとつの管理者フィールド、ひとつの割り当て番号フィールドから構成される。型フィールドの値は、管理者フィールドの意味と残り二つのフィールドの長さとを決定する。管理者フィールドは割り当てられている番号の権威者を表し、割り当て番号フィールドは特定の目的のために(提示された権威者によって)割り当てられた番号を含む。例えば、管理者フィールドに自律組織番号(ASN)を持ち、(4 バイトの)番号フィールドに(IANA がその ASN を割り当てた) SP が割り当てた番号を持つ RD を持つことができる。RD は、VPN バックボーンサービスを提供する SP がいつでも必要な時にユニークな RD を生成できることを保証するために、このような構造になっている。しかしながら、この構造は何のセマンティクスも提供しない。BGP はこの様なアドレスプレフィクス二つを比較するとき、その構造をすべて無視する。
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 アドレスとまったく同じ意味を持つものとみなされる。具体的にいうと BGP は、この VPN-IPv4 アドレスとそれに対応するグローバルにユニークな IPv4 アドレスとを比較可能であるとみなす。それ以外の場合 BGP は、VPN-IPv4 アドレスとそれに対応するグローバルにユニークな IPv4 アドレスとを比較できないとみなす。
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 アドレスプレフィクスに対しても、ひとつの 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 は、特定の CE に通じる経路と特定の RD とを関連付けるように設定する必要がある。同じ CE に通じる全経路を同じ RD に関連付けるように設定してもよいし、異なる経路を、それらが同じ 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. すべてのサイト別転送テーブルは、ひとつまたは複数の "Target 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. PE ルータによって VPN-IPv4 経路が生成されると、それはひとつ以上の "Target 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.) Target VPN T に関連するどの経路も、Target VPN T に関連する転送テーブルを持つすべての PE ルータに配布されなければならない。このような経路を PE ルータが受信した場合、その経路は、その PE の Target 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. 本質的には、Target VPN 属性はサイト集合を識別する。特定の Target 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. PE ルータがサイト S から受け取った経路に接続する Target VPN の集合が存在する。また、PE ルータが別の PE ルータから受け取った経路が、サイト S に対応するどの転送テーブルに配置できるかを決定するために使用する Target VPN の集合が存在する。この二つの集合は区別され、同じである必要はない。
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. Target VPN 属性によって実行される機能は、BGP コミュニティ属性(BGP Communities Attribute)によって実行される機能に似ている。しかしながら、後者の形式は 2 バイトの番号空間しか許さないため、不十分である。より大きな番号空間を提供するように BGP コミュニティ属性を拡張することは極めて容易だろう。その形式を、私たちが RD について説明したのと同じように(セクション 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. 同じ VPN-IPv4 プレフィクスへの二つの経路を受け取った BGP スピーカは、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 をひとつしか持てないが、複数の Target VPN を持つことはできることに注意してほしい。BGP における拡張性は、複数の経路ではなく、複数の属性を伴なう単独の経路を持つ場合に改善される。より多くの経路を生成すること(つまり、より多くの RD を使用すること)で Target 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 は与えられた経路にどの Target VPN 属性が対応するかを、どのようにして判断するのだろうか？ 多くの可能な方法がある。特定のサイトに通じるすべての経路に特定の Target VPN を関連付けるように PE を設定してもよい。あるいは、特定のサイトに通じる特定の経路をひとつの Target VPN に、そして他の経路はまた別の Target VPN に関連付けるように PE を設定してもよい。あるいは CE ルータは、PE へ経路を配布するときに(セクション 6 参照)、各々の経路ごとにひとつ以上の Target VPN を指定してもよい。後者の方法は、VPN を実装するために使用されるメカニズムの制御を、SP から顧客に移行する。この方法が使用される場合でも、PE はそれ自身の設定にしたがって、許可されない Target VPN をすべて削除することが望ましく、またそれ自身の設定にしたがって、一部の Target 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 Target" と呼ぶのではなく、"Route Target" と呼ぶ方がより正確かもしれない。これは実際には、それらのサイトが直感的に 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 内の二つのサイトが、同じ自治組織に属する複数の PE に接続している場合、PE はそれらの間の IBGP 接続を用いて互いに VPN-IPv4 経路を配布することができる。あるいは、各々がルートリフレクタ(route reflector)への 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. VPN 内の二つのサイトが異なる自治組織に属す場合(例えばそれらが異なる SP に接続している場合)、PE ルータは、自治組織境界ルータ(ASBR:Autonomous System Border Router)か、ASBR がクライアントであるルートリフレクタか、どちらかに VPN-IPv4 経路を再配布するために、IBGP を使用する必要があるだろう。その ASBR は次に、別の AS 内の ASBR にそれらの経路を再配布するために、EBGP を使用する必要があるだろう。これにより、異なる 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 が存在する場合、それら二つの AS 間に、すべての VPN のためのすべての経路を持つ単独の ASBR が存在する必要はない。複数の ASBR が存在してもよく、その場合、各々が特定の VPN のサブネットのための経路だけを保持する。
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 ネクストホップ(BGP next hot)" としてそれ自身のアドレスを使用する。また PE ルータは、MPLS ラベルの割り当てと配布も行う。(原則的に PE ルータは、VPN-IPv4 経路ではく、ラベル付けされた VPN-IPv4 経路([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. この方法で配布される MPLS ラベルは、経路を導入するルータとその経路の BGP ネクストホップとの間にラベルスイッチパスが存在する場合にのみ利用可能であることに注意してほしい。そのラベルスイッチパスを設定するのに使用される手続きに付いて、私たちは何も仮定しない。ラベルスイッチパスは、事前確立(pre-established)の原則で設定されたり、経路がその導入を必要としたときに設定されたりしてよい。"ベストエフォート(best effort)" の経路でもよいし、トラフィックエンジニアリングされた経路であってもよい。PE ルータとある特定の経路のための BGP ネクストホップとの間には、ひとつまたは複数の、場合によっては異なる QoS 特性を持つ LSP が存在してよい。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 ルータが、ある特定の経路のどの Target VPN とも接続していない場合、そのルータはその経路を受け取るべきではない。そのルータに経路を配布する別の PE またはルートリフレクタは、そのルータに不必要な経路を送信しないように、アウトバウンドフィルタを適用すべきである。当然ながら、BGP 経由である経路を受け取った PE ルータが、その経路のどの Target 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 of Origin 属性に関連付けてよい。この属性はサイトの集合を一意に識別し、さらに、そのサイト集合内のひとつから来た対応する経路を識別する。この属性の典型的な用途は、その経路が繋がるサイトを所有する企業を識別すること、あるいはサイトのイントラネットを識別することだろう。しかしながら他の用途にも利用可能である。この属性は拡張された 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 を "構築する(constructing)" ときに使用できる。
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 of Origin" 属性ではなく、"Route Origin" 属性と呼ぶ方がより正確かもしれない。実際のところこの属性は、特定のサイトの集合が実際に VPN を構成しているかどうかに関係なく、その経路が特定のサイト集合のひとつから来ていることだけを識別する。
By setting up the Target VPN and VPN of Origin attributes properly, one can construct different kinds of VPNs. Target VPN 属性と VPN of Origin 属性とを適切に設定するすることで、様々な種類の 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 を表すために特定の Target VPN 属性値を生成することで可能である。この値は、その CUG 内の各々のサイトのサイト別転送テーブルと関連付けられる必要があり、さらにその CUG 内のサイトから学習したすべての経路と関連付けられる必要がある。この Target VPN 属性を持つすべての経路は、その CUG の中のサイトのひとつに接続しているすべての PE ルータに到達させるために、再配布される必要があるだろう。
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. あるいは、何らかの理由で "ハブとスポーク(hub and spoke)" のような VPN を作成したいと仮定する。これは、ひとつが "ハブ(Hub)"、もうひとつが "スポーク(Spoke) " を意味する二つの Target 属性値を使用することで可能である。このとき、ハブからの経路がスポークに配布されないようにしながら、スポークからの経路をハブに配布することができる。
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. イントラネットだけに属する多くのサイトだけでなく、イントラネットとエクストラネットとの両方に属する多くのサイトを持っていると仮定する。このとき、イントラネットとエクストラネットとの両方の経路が存在してもよく、それらはサイト集合全体を識別する Target VPN を持つ。イントラネットの経路だけを持つべきサイトは、"誤った(wrong)" VPN of Originを持つ経路をすべて除外することができる。
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. これら二つの属性は、サイトの様々な集合の中で経路情報の配布の制御を可能にする高い柔軟性を与えており、言い換えると、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 への経路に関する情報を持っていないとしたら、どのようにしてパケットはあるサイトから別のサイトへと転送されるのだろうか？
This is done by means of MPLS with a two-level label stack. これは二階層のラベルスタックを持つ 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.) PE ルータ(および VPN-IPv4 アドレスを再配布する ASBR)は、バックボーンの IGP ルーティングテーブルの中に、自身のための /32 アドレスプレフィクスを挿入する必要がある。これにより MPLS は、バックボーンネットワーク上の各ノードにおいて、その経路に対応するラベルを各々の PE ルータに割り当てることが可能となる。(バックボーン内の経路を切り替えるラベルを構成するための手続きによっては、/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. CE デバイスからパケットを受け取った PE は、パケットの宛先アドレスを調べるためのサイト別転送テーブルを選択する。一致するものが見つかると仮定する。
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 Next Hop)" だけでなく、そのパケットの宛先アドレスのためにその 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 によって行われ、パケットの IP ヘッダは、パケットがCE デバイスに到達するまで再び調べられることは無いということである。そのパケットが CE デバイスに送られる前に、最後の PE ルータが MPLS ラベルスタックから最後のラベルをポップし、その結果として CE デバイスは通常の IP パケットを見ることになる。(しかしながら、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 経路を含めないことを可能にしているのは二階層ラベリングであり、それはこのモデルの拡張性を保証するために不可欠なものであることに注意してほしい。バックボーンは CE への経路さえ持つ必要がなく、PE への経路だけを持てばよい。
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 に接続している PE ルータは、その VPN のサイトごとに、VPN 内のどのアドレスがどのサイトに属するのかを知っている必要がある。
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 は、これらの VPN-IPv4 経路を BGP への入力として扱う。サイトからの経路は決してバックボーンの 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(transit VPN)" の中にあるかどうかに依存する。"トランジット VPN (transit VPN)" は、"第三者(third party)" から(つまり VPN の中ではないが、PE ではないルータから)経路を受信し、PE ルータにそれらの経路を再配布するルータを含むものである。トランジット VPN ではない VPN は "スタブ VPN(stub VPN)" である。VPN の大多数(ほとんどすべての企業ネットワークを含む)は、この意味で "スタブ(stubs)" であると思われる。
The possible PE/CE distribution techniques are: 利用可能な PE/CE 配布技術は以下の通り：
From a purely technical perspective, this is by far the best technique: 純粋に技術的な観点から見て、これは非常に優れた手法である：
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 に属さないサイトは、ユニークな Autonomous System Number (ASN)を持つ必要がないことに注意してほしい。トランジット VPN 外にあるサイトのすべての CE は同じ ASN を使用することができる。これはプライベート ASN 空間から選択でき、PE によって取り除かれる。ルーティングのループは Site of 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 集団(BGP Confederation)として表現することは都合がよい。この場合、VPN 内の各サイトは、バックボーンへの二つの接続(ひとつは集団の中へ、もうひとつは外へ)を必要とするだろう。通常のイントラ集団(intra-confederation)の手順は、バックボーンとサイトとが異なるポリシーを持っているという事実を考慮するために、若干異なる必要があるだろう。そのバックボーンはひとつの接続上の集団のメンバーであるが、その他のメンバーではない。これらの手法は VPN サービスの顧客が ISP の場合に都合がよいだろう。この手法により、ISP である顧客は、ISP ピアのひとつから VPN バックボーンサービスを取得することが可能となる。
(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 がそのサイトから経路を "学習した(learned)" と言う。
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 経路を再配布する前に、その経路に特定の属性を割り当てなければならない。そのような属性は三つ存在する：
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 からのパケットをルーティンするために使用する転送テーブル内のすべての経路を CE に配布してよい。例外がひとつある：ある経路の Site of 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 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 にデフォルトルートを配布するだけで十分である。(場合によっては、その PE を指すデフォルトルートを CE に設定するだけでも十分である。) 一般にこれは、他のサイトへデフォルトルートを配布する必要の無いあらゆるサイトでうまくいく。(例えば、ある企業の VPN 内のあるサイトが、その企業のインターネットへのアクセスを持つ場合、そのサイトはその他のサイトへデフォルトルートを配布する必要があるだろうが、そのサイト自身へはデフォルトルートを配布できない。)
Whatever procedure is used to distribute routes from CE to PE will also be used to distribute routes from PE to CE. CE から PE へ経路を配布するために使用される手順はすべて、PE から CE への経路を配布するためにも使用されることになる。
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 はその経路ごとのラベルを CE に配布できる。CE からそのようなラベルの付いたパケットを受け取った PE は、(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 of Origin 属性と Target VPN 属性とによって表される)のための転送テーブルを含んでいてよい。CE が PE から全経路集合を受け取った場合、その PE はその CE から受け取るすべてのパケットについてアドレスを調べる必要が無くなるだろう。場合によってはその代わりに、PE が各 VPN のために単独の(ラベル付けされた)デフォルト経路を CE に配布することができる。その後 PE が CE からラベル付けされたパケットを受信したとき、PE はどの転送テーブルを調べるべきなのかを知る。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: 以下の前提条件の場合を考える:
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 を利用することで、MPLS の代わりに IP-within-IP トンネリングのような形式を利用することを試みるよりも、はるかに簡単にこのレベルのセキュリティを提供することができることは注目に値する。ラベル付けされたパケットを、上記の最初の条件がそのパケットに適用されない限り受け入れ拒否するのは簡単な問題である。IP-within-IP でトンネル化された IP パケットが "間違った(wrong)" 場所へ行こうしているとき、そのパケットの受け入れを拒否するようにルータを設定することはかなり難しい。
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 の利用により、ドメイン間の 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 ユーザーは Tunnnel Mode 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 ルータのすべての組み合わせの間に "セキュリティトンネル(security tunnel)" を生成することである。
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 トンネルの二つのエンドポイント間でパケットを運ぶ場合、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 ルータは同じセキュリティ要素(例えば同じ秘密鍵、同じアルゴリズムなど)を共有する。これにより入り口の CE は、データを受け取る次の CE がどれなのかを知る必要がなくなり、そのデータが向かう VPN を知るだけでよくなる。複数の VPN に属する CE は、そのそれぞれの VPN ために異なるセキュリティパラメータを利用できる。これは、例えばイントラネットのパケットがエクストラネットに公開されることを防ぐ。
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". このような仕組みでは、標準的なトンネルモード IPSEC を利用できない。なぜなら、"外側のヘッダ(outer header)" の IP 宛先アドレスフィールドを埋める手段がないためである。しかしながら転送に MPLS を利用する場合、実際には外側のヘッダはもはや必要としない。PE ルータはトンネルのエンドポイントの IP アドレスさえ知らなくとも、そのエンドポイントへパケットを送るために MPLS を利用できる。PE ルータは "内側のヘッダ(inner header)" の 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 サービスでもサービス品質(Quality of Service)は重要な要素である。MPLS/BGP VPN では、シムヘッダ [10] の "実験(experimental)" ビットの利用を通して、あるいは、バックボーンとして ATM が使用されている場合には ATM QoS 機能の利用を通して、ラベル付けされたパケットに既存の L3 QoS 機能を適用できる。[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 とへの経路だけを保持する必要がある。二階層ラベリングを使用することで、VPN 経路を P ルータの外に保持することが可能となる。
A PE router to maintains VPN routes, but only for those VPNs to which it is directly attached. PE ルータは VPN 経路を保持するが、それはその PE が直接接続している 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. ルートリフレクタと ASBR とは、各パーティションがサービスプロバイダによって提供される VPN のサブセットだけに経路を運ぶように、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. Cisco Systems は、この文書内で公開されている技術の一部の特許、またはその他の知的所有権を出願する可能性がある。Cisco Systems に委譲されたひとつ以上の特許によって保護されている、あるいは保護されることになるこの文書から生じるいかなる標準も、Cisco はそれらの特許を公開し、理にかなった非差別的な条件でライセンスする意向である。
Security issues are discussed throughout this memo. セキュリティ問題はこの文書全体を通して議論されている。
Significant contributions to this work have been made by Ravi Chandra, Dan Tappan and Bob Thomas. Ravi Chandra、Dan Tappan、Bob Thomas は、この成果物に重要な貢献をした。
Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 EMail: erosen@cisco.com Yakov Rekhter Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: yakov@cisco.com
[1] Awduche, Berger, Gan, Li, Swallow, and Srinavasan, "Extensions to RSVP for LSP Tunnels", Work in Progress.
[2] Bates, T. and R. Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.
[3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998.
[4] Gleeson, Heinanen, and Armitage, "A Framework for IP Based Virtual Private Networks", Work in Progress.
[5] Kent and Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[6] Li, "CPE based VPNs using MPLS", October 1998, Work in Progress.
[7] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[8] Rekhter and Rosen, "Carrying Label Information in BGP4", Work in Progress.
[9] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", Work in Progress.
[10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", Work in Progress.
Copyright (C) The Internet Society (1999). All Rights Reserved.
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.