RFC2547 日本語訳
2547 BGP/MPLS VPNs. E. Rosen, Y. Rekhter. March 1999. (Format: TXT=63270 bytes) (Obsoleted by RFC4364) (Status: INFORMATIONAL)
RFC一覧
英語原文
Network Working Group E. Rosen
RFC： 2547 Y. Rekhter
分類： 情報提供 Cisco Systems, Inc.
1999年3月
BGP／MPLS VPN
このメモのステータス
このメモはインターネット業界に対する情報提供であり、いかなるインター
ネット標準も規定しない。このメモの配布は自由である。
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
概 要
このドキュメントは、IPバックボーンを持つサービスプロバイダが顧客にVPN
（仮想プライベートネットワーク）を提供するための手法について述べてい
る。MPLS（マルチプロトコルラベルスイッチング）はバックボーン上でのパ
ケット転送に使用され、BGP（ボーダゲートウェイプロトコル）はバックボー
ン上での経路配布に使用される。この手法の第1の目標は、企業ネットワーク
に対してIPバックボーンのアウトソーシングサービスをサポートすることで
ある。この手法は、企業にとって単純で、サービスプロバイダにとって規模
拡張性と柔軟性を保つように行い、一方でサービスプロバイダが付加価値を
付けられるようにする。この技術を使用して、そのVPN自体がIPサービスを顧
客に提供するようなVPNを提供することもできる。
目 次
1 序論 ............................................... 2
1.1 仮想プライベートネットワーク ....................... 2
1.2 エッジ装置 ......................................... 3
1.3 アドレス空間が重なるVPN ............................ 4
1.4 同一システムへの異なる経路を持つVPN ................ 4
1.5 PEにおける複数の転送テーブル ....................... 4
1.6 SPバックボーンルータ ............................... 4
1.7 セキュリティ ....................................... 5
2 サイトとCE ......................................... 5
3 PEにおけるサイト別転送テーブル ..................... 6
3.1 仮想サイト ......................................... 7
4 BGPによるVPN経路配布 ............................... 8
4.1 VPN-IPv4アドレスファミリー ......................... 8
4.2 経路配布の制御 ..................................... 9
4.2.1 ターゲットVPN属性 .................................. 9
4.2.2 BGPによるPE間の経路配布 ............................ 10
Rosen & Rekhter 情報提供 [Page 1]
RFC 2547 BGP/MPLS VPNs 1999年3月
4.2.3 起源VPN属性 ........................................ 12
4.2.4 ターゲット属性と起源属性を使用したVPNの構築 ........ 12
5 バックボーン内の転送 ............................... 13
6 PEがCEから経路を学ぶ方法 ........................... 14
7 CEがPEから経路を学ぶ方法 ........................... 16
8 CEがMPLSをサポートする場合どうなるか ............... 17
8.1 仮想サイト ......................................... 17
8.2 ISP VPNのスタブVPNとしての表現 ..................... 17
9 Security ........................................... 18
9.1 CEルータ間のポイントツーポイントセキュリティトンネル. 18
9.2 マルチパーティセキュリティアソシエーション ......... 19
10 サービス品質 ....................................... 19
11 規模拡張性 ......................................... 20
12 知的財産に関する配慮 ............................... 20
13 セキュリティへの配慮 ............................... 20
14 謝辞 ............................................... 20
15 著者連絡先 ......................................... 21
16 参考文献 ........................................... 21
17 著作権表明全文 ..................................... 22
1. 序論
1.1. 仮想プライベートネットワーク
「バックボーン」と呼ぶことができる共有ネットワークに接続された「サイ
ト」の集合を考える。この集合からいくつかの部分集合を作るために、ある
ポリシーを適用しよう。そして、2つのサイトがこの部分集合の1つ以上に含
まれるときにだけバックボーン上でIPの相互接続性を持つことができる、と
いう規則を課してみよう。
我々が作ったこの部分集合は「仮想プライベートネットワーク」（VPN）であ
る。2つのサイトを含むようなVPNがある場合にのみ、それらのサイトは共有
バックボーン上でIPの相互接続性を持つ。また、2つのサイトが共通のVPNを
持たない場合は、そのバックボーン上で接続性を持たない。
VPN内の全サイトが同じ企業のものである場合、VPNは企業「イントラネット」
である。また、VPN内の各サイトが異なる企業のものである場合、VPNは「エ
クストラネット」である。1つのサイトは2つ以上のVPNに所属することもでき
る。例えば、イントラネットといくつかのエクストラネットに所属できる。
一般的に、VPNという用語を使うときイントラネットとエクストラネットの区
別をしない。
バックボーンを1社以上のサービスプロバイダ（SP）が所有し、運用している
ケースを考えたい。サイトの所有者はSPの「顧客」である。サイトの集まり
がVPNとなるかどうかを決定するポリシーは顧客のポリシーである。一部の顧
客はこのポリシーの実現を完全にSP任せとしたいだろう。別の顧客は、自ら
の手でこのポリシーを実現したい、あるいはこのポリシーの実現をSPと分担
したいと思うかもしれない。このドキュメントでは主に、このポリシーを実
Rosen & Rekhter 情報提供 [Page 2]
RFC 2547 BGP/MPLS VPNs 1999年3月
現するために使用可能なメカニズムについて議論していく。我々が述べるメ
カニズムは十分一般的で、SP単独でもVPN顧客とSPの共同でもこのポリシーの
実現は可能である。しかし、議論の大部分は前者のケースに焦点を当てる。
このドキュメントで議論するメカニズムは、広範囲にわたるポリシーの実現
を可能にする。例えば、あるVPNの中で、全てのサイトが他の全てのサイトと
直接の経路を持つようにもできるし（「完全メッシュ」）、ある組み合わせ
のサイト同士はお互いへの直接の経路を持てないよう制限することもできる
（「部分メッシュ」）。
このドキュメントでは、共有バックボーンでIPサービスを提供するケースに
特に関心がある。我々は、契約関係の維持によって、企業がサービスプロバ
イダに、場合によっては複数のサービスプロバイダにバックボーンをアウト
ソーシングするようなケースに一番関心がある。公衆インターネット上でVPN
を提供することに関心は無い。
この序論の残りで、VPNが持つべきいくつかの特性を規定する。このドキュメ
ントの以降の部分で、このような特性を全て持っているVPNモデルのアウトラ
インを描く。このドキュメントのVPNモデルは[4]で書かれているフレームワ
ークの例となるものである。
1.2. エッジ装置
各サイトに1つ以上の顧客エッジ（CE）装置があり、そのそれぞれがある種の
データリンク（例えば、PPP、ATM、イーサネット、フレームリレー、GREトン
ネルなど）を用いて1つ以上のプロバイダエッジ（PE）ルータに接続されてい
る。
あるサイトに1つホストがあるとき、そのホストがCE装置でもよい。あるサイ
トに1つサブネットがあるとき、そのCE装置はスイッチでもよい。一般的にCE
装置はルータであると考えて良い。我々はこれをCEルータと呼ぶ。
PEルータがあるVPNに属するCE装置に接続されているとき、PEルータはその
VPNに接続されていると言うことにする。同様に、PEルータがあるサイトのCE
装置に接続されているとき、そのサイトに接続されていると言うことにする。
CE装置がルータであるとき、接続しているPEのルーティングピアではあるが、
他サイトのCEルータのルーティングピアではない。異なるサイトのルータ同
士は、お互いに直接ルーティング情報を交換することは無い。実際、お互い
を知る必要すら全くない（セキュリティのために必要な場合を除く、第9章参
照）。その結果、非常に大規模なVPN（すなわち、非常に多数のサイトを持つ
VPN）のサポートが容易になり、個々のサイトのルーティング設計は非常に単
純になる。
SPと顧客の管理上の境界をはっきりと守ることは大事である（[4]参照）。PE
ルータとPルータはSP単独で管理されるべきで、SPの顧客がそれに対していか
なる操作手段も持つべきでない。また、CE装置は（顧客がSPと外部運用サー
ビスを契約していない限り）顧客単独で管理されるべきである。
Rosen & Rekhter 情報提供 [Page 3]
RFC 2547 BGP/MPLS VPNs 1999年3月
1.3. アドレス空間が重なるVPN
2つの交わらないVPN同士（すなわち共通のサイトを持たないVPN同士）は、ア
ドレス空間が重なっても構わない。同じアドレスを異なるVPNの異なるシステ
ムに再利用可能である。エンドシステムが所属VPNの範囲内でユニークなアド
レスを持っている限り、そのエンドシステム自身はVPNについて何も知る必要
が無い。
このモデルにおいて、VPN所有者は管理するバックボーンを持っておらず、
「仮想バックボーン」でさえも持っていない。SPは、各VPNに対する個別のバ
ックボーンも、「仮想バックボーン」も管理する必要が無い。（VPNを作るの
に使用するポリシーの制約内では）バックボーンにおけるサイト対サイトの
ルーティングが最も望ましく、このルーティングがトンネルの不自然な「仮
想トポロジー」で制限されることは全く無い。
1.4. 同一システムへの異なる経路を持つVPN
サイトが複数のVPNに属することも可能であるが、そのサイトのシステムへの
経路が全てのVPNで同じにする必要はない。例えば、サイトA、B、Cで構成さ
れるイントラネットと、A、B、Cと「外部」サイトDで構成されるエクストラ
ネットがあると仮定する。そして、サイトAにサーバがあると仮定し、B、C、
Dからのクライアントがそのサーバを使用できるようにしたいとする。サイト
Bにはファイアウォールがあることも仮定する。サイトDからのトラフィック
は全てファイアウォールを経由するようにして、エクストラネットからのト
ラフィックをアクセス制御できるようにしたい。しかし、Cからのトラフィッ
クは、イントラネットのトラフィックなので、サーバまでの途中でファイア
ウォールを経由するようにしたくない。
これは、サーバへ経路を2つ設定できるようにする必要があることを意味する。
1つの経路はサイトBとCで使用され、直接サイトAへのトラフィックを運ぶ。
2つ目の経路はサイトDで使用され、代わりにサイトBのファイアウォールにト
ラフィックを運ぶ。ファイアウォールがトラフィックを通せば、サイトBから
来るトラフィックになり、サイトAへの経路を辿る。
1.5. PEにおける複数の転送テーブル
各PEルータは、多くの別個の転送テーブルを保持する必要がある。このPEに
接続されている全てのサイトが、これらの転送テーブルの1つに対応付けられ
る必要がある。パケットをあるサイトから受信したときは、そのサイトに関
する転送テーブルを調べ、どのようにパケットをルーティングするかを決定
する。あるサイトSに関する転送テーブルは、Sと共通のVPNを1つ以上持つ他
サイトへの経路しか持たない。これによって、共通のVPNを持たないサイト同
士が通信できないようになり、共通のサイトを持たない2つのVPNがお互いに
重なるアドレス空間を使用できるようになる。
1.6. SPバックボーンルータ
SPのバックボーンはPEルータと、CE装置に接続されていないそれ以外のルー
Rosen & Rekhter 情報提供 [Page 4]
RFC 2547 BGP/MPLS VPNs 1999年3月
タ（Pルータ）で構成される。
SPのバックボーンの全ルータが、SPがサポートする全VPNのルーティング情報
を持つ必要があるとすれば、このモデルは困難な規模拡張性の問題をはらむ
ことになる。1つのルータが保持できるルーティング情報の量によってサポー
ト可能なサイトの数は制限されるだろう。したがって、あるVPNに関するルー
ティン霏P8疏 0y` メンバーであってよい。そのときPEは各仮想サイトごとに別々の転送テーブ
ルを持つ必要がある。例えば、CEがVLANをサポートしていて、各VLANを異な
るVPNに対応させたい場合、CEとPEの間で送信されるパケットはそのサイトの
VLANカプセル化フレームに格納できる。これは、パケットをそれぞれの仮想
サイトに割り当てるために、パケットを受信したインタフェースと併せてPE
で使用される。
あるいは、インタフェースを複数の「サブインタフェース」に分け（特にフ
レームリレーやATMの場合）、到着したサブインタフェースに基づいてパケッ
トをVPNに割り当てることもできる。また、単純に仮想サイトごとに異なるイ
ンタフェースを使用することもできる。いずれにしても、複数の仮想サイト
があろうと、CEルータがサイトごとに1つだけ必要であるのは変わらない。も
ちろん、必要に応じて、各仮想サイトごとに異なるCEルータを使用すること
も可能である。
このような場合は常に、どのトラフィックがどのVPNに入るかを制御するため
のメカニズムは、ポリシーと同様、顧客の責任となる。
あるホストを複数の仮想サイトに所属させたいなら、それぞれのパケットに
ついて、どの仮想サイトとパケットを関連付けるか、そのホストが決めなけ
ればならない。これを行うには、例えば、異なるVLAN上にある異なる仮想サ
イトからのパケットを、異なるネットワークインタフェースへ送信すればよ
い。
これらの方式はCEがMPLSをサポートしている必要は“ない”。第8節では、CE
がMPLSをサポートしているとき、どのようにして複数の仮想サイトをサポー
トできるかを簡単に説明している。
Rosen & Rekhter 情報提供 [Page 7]
RFC 2547 BGP/MPLS VPNs 1999年3月
4. BGPによるVPN経路配布
PEルータはBGPを使用して、VPN経路をお互いに配布している（より正確に言
えば、VPN経路がお互いに配布されるようにしている）。
BGPスピーカは、あるアドレスプレフィックスへの経路を1つだけしかインス
トールおよび配布できない。それでも我々は、各VPNが固有のアドレス空間を
持てるようにする。つまり、同一のアドレスが複数のVPNで使用可能であるこ
とを意味する。ここで、それぞれのVPNでこのアドレスは異なるシステムを表
す。要するに、BGPが1つのIPアドレスプレフィックスに対する複数の経路を
インストールおよび配布できるようにする必要があるということである。さ
らに、どのサイトがどの経路を使用できるかを決めるために、“ポリシー”
を使用できるようにしなければならない。もしこのような経路が複数、BGPで
インストールされている場合、個々のサイト別転送テーブルには、そのうち
1つだけが現れるようにしなければならない。
我々は、次に規定する新しいアドレスファミリーを使用してこの目標を達成
する。
4.1. VPN-IPv4アドレスファミリー
BGPマルチプロトコル拡張[3]によって、BGPは複数の「アドレスファミリー」
から経路を運ぶことが可能になった。我々は「VPN-IPv4アドレスファミリー」
の概念を導入する。VPN-IPv4アドレスは12バイトの数で、8バイトの「ルート
識別子（RD）」から始まり、4バイトのIPv4アドレスで終わる。2つのVPNが同
じIPv4アドレスプレフィックスを使用する場合、PEはこれらをユニークな
VPN-IPv4アドレスプレフィックスに変換する。これは、同じアドレスが2つの
VPNで使用されているとき、そのアドレスに対して各VPNに1つずつ計2つの完
全に異なる経路がインストール可能であることを保証する。
RD自身は意味を持っていない。経路の起源についての情報や経路が配布され
るべきVPNについての情報は何ら含んでいない。RDの目的は単に、共通のIPv4
アドレスプレフィックスへの複数の経路を作成可能にすることだけである。
どこに経路を再配布するかは、別の手段を使用する（第4.2節を参照）。
RDを使用して、全く同じシステムに対して複数の異なる経路を作成すること
もできる。第3節では、あるサーバへの経路がイントラネットトラフィックと
エクストラネットトラフィックとで異なっていなければならないような例を
挙げた。これは、IPv4部が同じでRDが異なる2つのVPN-IPv4経路を作成するこ
とで達成できる。これによって、BGPは同一のシステムに対して複数の異なる
経路をインストール可能になり、ポリシーで（第4.2.3節参照）どのパケット
がどの経路を使用するかを決定できる。
全てのサービスプロバイダが、他のサービスプロバイダの割当てたRDと衝突
しない独自の「番号空間」を管理できる（すなわち、独自のRD割当ができる）
ように、RDの構成が決められている。RDは、2バイトのタイプフィールド、管
理者フィールド、割当番号フィールドで構成されている。タイプフィールド
の値によって、他の2つのフィールドの長さと管理者フィールドの意味が決ま
Rosen & Rekhter 情報提供 [Page 8]
RFC 2547 BGP/MPLS VPNs 1999年3月
る。管理者フィールドで番号割当組織が分かる。そして、割当番号フィール
ドは、特定用途のためにその組織が割当てた番号を持っている。例えば、自
律システム番号（ASN）をRDの管理者フィールドに入れ、IANAによってその
ASNが与えられているSPが割当てた番号を（4バイトの）番号フィールドに入
れることもできる。RDがこの構成を与えられているのは、VPNバックボーンを
提供しているSPが必要なときにいつもユニークなRDを作れるためである。し
かし、この構成は何ら意味を持っていない。BGPがこのような2つのアドレス
プレフィックス比較するときは、この構成を完全に無視する。
VPN-IPv4アドレスの管理者サブフィールドと割当番号サブフィールドが両方
とも全て0である場合、VPN-IPv4アドレスは、相当するグローバルにユニーク
なIPv4アドレスと全く同じ意味を持つと見なされる。特に、このVPN-IPv4ア
ドレスと相当するグローバルにユニークなIPv4アドレスは、BGPで等価に扱わ
れるだろう。それ以外はいつも、VPN-IPv4アドレスと相当するグローバルに
ユニークなIPv4アドレスは、BGPで違うものとして扱われるだろう。
サイト別フォワーディングテーブルは、全てのIPv4アドレスプレフィックス
に対してVPN-IPv4の経路を各1つずつ持っている。パケットの宛先アドレスが
VPN-IPv4経路と一致するとき、IPv4部分だけが実際に一致している。
PEは、CEに向かう経路をRDと関連付けるよう設定する必要がある。同じCEに
向かう全ての経路を同じRDに関連付けるよう、PEを設定できるし、あるいは、
同じCEに向かう経路でも、異なる経路なら異なるRDに関連付けることができ
る。
4.2. 経路配布の制御
この節では、VPN-IPv4経路の配布を制御する方法について議論する。
4.2.1. ターゲットVPN属性
全てのサイト別転送テーブルは1つ以上の「ターゲットVPN」属性と関連付け
られる。
VPN-IPv4経路がPEルータによって作成されるとき、1つ以上の「ターゲット
VPN」属性と関連付けられる。このターゲットVPNはBGPにおいて経路の属性と
して運ばれる。
あるターゲットVPN Tと関連する経路はいずれも、ターゲットVPN Tに関する
転送テーブルを持っている全PEルータに配布する必要がある。このような経
路がPEルータで受信されたとき、その経路は、そのPEが持つターゲットVPN T
に関するサイト別転送テーブルの各々にインストールされる資格がある（実
際にインストールされるかどうかは、BGPの決定処理の結果による）。
本質的に、ターゲットVPN属性がサイトの集合を識別する。特定のターゲット
VPN属性と経路とを関連付けることで、その経路を、対応するサイトからの受
信トラフィックのルーティングに使用するサイト別転送テーブルに入れるこ
とが許される。
Rosen & Rekhter 情報提供 [Page 9]
RFC 2547 BGP/MPLS VPNs 1999年3月
PEルータがサイトSからの受信経路と結びつけるターゲットVPNの集合がある。
そして、別のPEから受信した経路をサイトSに関する転送テーブルに入れるか
を決定するのにPEルータが使用するターゲットVPNの集合がある。この2つの
集合は区別され、同一である必要はない。
ターゲットVPN属性によって実行される機能は、BGPコミュニティ属性によっ
て実行されることと同様である。しかし、後者のフォーマットは2バイト分の
番号空間しか許可されないため、不十分である。BGPコミュニティ属性を拡張
して、もっと大きい番号空間を提供するのがとても簡単である。RDで述べた
ものと同様のフォーマット（第4.1節参照）の構成も可能であるべきで、この
場合、タイプフィールドは管理者フィールドの長さを定義し、残りの属性は
指定された管理者の番号空間からの番号となる。
BGPスピーカが1つのVPN-IPv4プレフィックスに対して2つの経路を受信したと
きは、BGPの経路優先規則に従って1つを選択する。
1つの経路は、RDを1つしか持つことができないが、ターゲットVPNなら複数持
てることに注目しよう。BGPで、1つの経路に複数の属性が付けられるならば、
規模拡張性は向上する。これは、経路を複数にする場合と対照的である。複
数の経路を作成することで（すなわちより多くのRDを使用することで）ター
ゲットVPN属性をなくすことも可能だが、規模拡張性の面でより不利になって
しまうだろう。
PEは、経路に関連付けるターゲットVPN属性をどのようにして決めるのだろう
か。それには、いくつかの異なるやり方が可能である。PEは、あるサイトに
向かう全経路に1つのターゲットVPNを関連付けることもできる。またPEは、
あるサイトに向かう一部の経路に1つのターゲットVPNを関連付け、そして同
じサイトに向かう別の経路に別のターゲットVPNを関連付けることもできる。
また、CEルータは、これらの経路をPEに配布するときに（第6節参照）、各経
路に対して1つ以上ターゲットVPNを指定できる。最後の方法は、VPNポリシー
実現に使用するメカニズムの制御を、SPから顧客に転嫁している。この方法
を使った場合、PEは自身の設定に従って許可されないターゲットVPNを全て削
除するようにしたり、自身の設定に従ってターゲットVPNをいくつか追加した
りすることが望ましい。
あまり示唆的ではないが、この属性を「VPNターゲット」属性と呼ぶ代わりに
「ルートターゲット」属性と呼ぶ方が、より正確かもしれない。実際には、
経路を使用できるサイトの集合を見分けるだけで、それが直感的にVPNと呼べ
るものを構成するサイトかどうかにとらわれない。
4.2.2. BGPによるPE間の経路配布
VPNの2サイトが接続されているPEが同一自律システムにある場合、PE同士は、
その間のIBGP接続を用いてVPN-IPv4経路をお互いに配布することができる。
そうする代わりに、各PEがルートリフレクタとIBGP接続を持つこともできる。
VPNの2サイトが異なる自律システムにある場合（例えば、異なるSPと接続さ
れているなど）、PEルータはIBGPを使用して。VPN-IPv4経路を自律システム
Rosen & Rekhter 情報提供 [Page 10]
RFC 2547 BGP/MPLS VPNs 1999年3月
境界ルータ（ASBR）あるいはASBRをクライアントとするルートリフレクタに
配布する必要がある。そのとき、このASBRはEBGPを使用してこの経路をもう
1つのASのASBRに配布する必要がある。これによって、異なるVPNサイトを異
なるサービスプロバイダに接続することが可能になる。しかし、VPN-IPv4経
路を受けるのは、信頼できる取り決めの1つとして、プライベートピアリング
ポイントでのEBGP接続だけにするべきである。VPN-IPv4経路は、公衆インタ
ーネットに配布すべきではないし、また公衆インターネットから受け入れる
ベきでもない。
異なる自律システムに接続されているサイトを持つようなVPNが多くある場合、
この2つのASの間にあるASBRが単独で全てのVPNの全ての経路を保持する必要
はない。複数のASBRが存在し、それぞれが全VPNのサブセットに対する経路だ
けを保持するようにすることができる。
PEルータがVPN-IPv4経路をBGPで配布するとき、自身が持つアドレスを「BGP
ネクストホップ」として使用する。また、MPLSラベルの割当と配布も行う
（本来、PEルータはVPN-IPv4経路ではなく、ラベル付きVPN-IPv4経路を配布
する。[8]参照）。このラベルがスタックの最上位にある受信パケットをPEが
処理するとき、PEはスタックをポップして、経路が向かうサイトに直接その
パケットを送信する。これは通常、経路を学んだCEルータにパケットが送信
されることになる。このラベルはデータリンクのカプセル化も決めることが
できる。
ほとんどの場合、PEが割当てたラベルによってパケットはCEに直接送信され
て、ラベル付きパケットを受信したPEがパケットの宛先アドレスを転送テー
ブルでルックアップすることはないだろう。しかし、転送テーブルを暗黙の
うちに示すようなラベルをPEが割り当てることも可能である。この場合、こ
のラベルを持つパケットを受信したPEは、転送テーブルの1つでパケットの宛
先アドレスをルックアップするだろう。これは状況によっては非常に便利で
はあるが、この文書ではこれ以上考えない。
この方法で配布されるMPLSラベルは、経路をインストールしたルータとその
経路のBGPネクストホップの間にラベルスイッチパスがあるときだけ使用でき
ることに注意する。このラベルスイッチパスを設定するために使用する手続
きについて、我々は何も決めていない。このラベルスイッチパスは、事前確
率を原則として設定するか、ラベルスイッチパスを必要とする経路がインス
トールされたときに設定する。これは、「ベストエフォート」の経路であっ
ても、トラフィックエンジニアリングされた経路であっても構わない。ある
PEルータとある経路のBGPネクストホップの間には1つのLSPがあるかもしれな
いし、複数のLSPかもしれない。複数の場合は、おそらく異なるQoS特性を持
っているだろう。VPNアーキテクチャでは、ルータとBGPネクストホップの間
に何かラベルスイッチパスが存在することだけでよい。
規模拡張性を向上させるためにルートリフレクタ[2]を使用する際に有用な技
術、例えばルートリフレクタの階層化などは、全て利用可能である。ルート
リフレクタを使用する場合、それぞれのルートリフレクタがバックボーンで
サポートする全VPNに対する全VPN-IPv4経路を知っている必要は無い。ルート
リフレクタを分けて、お互いに通信しないで、それぞれがVPNの全集合のうち
Rosen & Rekhter 情報提供 [Page 11]
RFC 2547 BGP/MPLS VPNs 1999年3月
の一部をサポートするようにできる。
PEルータが、ある経路が持つターゲットVPNと全く接続されていない場合、そ
の経路は受け取るべきではない。他のPEや、そのPEに経路を配布するルート
リフレクタは、無用な経路を送信することを避けるために出力フィルタを適
用するのがよい。PEルータがBGPで経路を受信したが、そのPEはその経路のタ
ーゲットVPNに全く接続されていない場合、PEは、その経路に対する入力フィ
ルタを適用して、インストールと再配布をしないようにするのが当然だろう。
全くVPNと接続されていないルータ、すなわちPルータは、VPN-IPv4経路を一
切インストールしてはいけない。
この配布規則によって、1つのボックスがバックボーン上でサポートされる全
てのVPN-IPv4経路を知らなければならない、ということはなくなる。その結
果、バックボーン上でサポートできる経路数の合計が1つの装置の性能によっ
て制限されたりしなくなる。
4.2.3. 起源VPN属性
VPN-IPv4経路は、オプションで起源VPN属性と関連付けることができる。この
属性は、サイトの集合をユニークに特定し、その集合の中のサイトの1つから
来ている対応する経路を識別する。この属性の典型的な使い方は、その経路
の宛先となるサイトを持つ企業を特定することや、そのサイトのイントラネ
ットを特定することが可能だろう。しかし、別の使い方も可能である。この
属性は拡張BGPコミュニティ属性として符号化することができる。
ある経路の送信元を特定しないといけない状況では、この属性を使用しなけ
ればならず、RDは使用しない。以下で述べるようにVPNを「構築する」ときに
この属性が使用できる。
あまり示唆的ではないが、この属性を「起源VPN」属性と呼ぶ代わりに「ルー
ト起源」属性と呼ぶ方がより正確かもしれない。実際には、経路があるサイ
トの集合の1つから来ていることだけを見分けられ、そのサイトの集合が実際
にVPNを構成しているかどうかにとらわれない。
4.2.4. ターゲット属性と起源属性を使用したVPNの構築
ターゲットVPN属性および起源VPN属性を適切に設定することで、様々なVPNを
構築することができます。
あるサイトの集合を含む閉域ユーザグループ（CUG）を作成したいとする。こ
れは、CUGを表すターゲットVPN属性値を作成することで実施できる。そして
この値は、CUGの各サイトに対するサイト別転送テーブルに関連付けられる必
要があり、かつCUGのサイトから学んだ全ての経路と関連付けられる必要があ
る。このターゲットVPN属性を持つ経路は全て再配布され、CUGのサイトのい
ずれかに接続されている全PEルータに到着している必要がある。
あるいはまた、何らかの理由で「ハブアンドスポーク」型のVPNを作成したい
Rosen & Rekhter 情報提供 [Page 12]
RFC 2547 BGP/MPLS VPNs 1999年3月
とする。これは、2つのターゲット属性値を使用することで実行できる。1つ
は「ハブ」を表し、1つは「スポーク」を表す。このとき、ハブからの経路が
スポークに配布されないようにしながら、スポークからの経路はハブに配布
することができる。
イントラネットとエクストラネットに属しているいくつかのサイトと、イン
トラネットだけに属しているいくつかのサイトがあると仮定する。このとき、
イントラネットとエクストラネットの両方の経路があり得て、これらはサイ
トの全体集合を示すターゲットVPNを持っている。イントラネット経路だけを
持つべきサイトは、「不適切」な起源VPNを持つ全ての経路をフィルタリング
することができる。
この2つの属性は高い柔軟性を可能にし、様々なサイトの異なる集合の間でル
ーティング情報の配布を制御可能にできる。その結果、これはVPNの構築に高
い柔軟性を与えることになる。
5. バックボーン内の転送
バックボーン内の中間経路がVPNへの経路情報を持たない場合、どのようにし
てあるVPNサイトから別のVPNサイトにパケットが転送されるのだろうか。
これは、2階層のラベルスタックを使ったMPLSの手法によって実行される。
PEルータ（とVPN-IPv4アドレスを再配布するASBR）は、自身の/32アドレスプ
レフィックスをバックボーンネットワークのIGPルーティングテーブルに入れ
る必要がある。これによって、バックボーンネットワークの各ノードで、
MPLSが各PEルータへの経路に対応するラベルを割り当てることが可能になる
（バックボーンにラベルスイッチパスを設定する手続きによっては、/32アド
レスプレフィックスが無くても構わない）。
PEがCE装置からパケットを受信したとき、そのパケットの宛先アドレスをル
ックアップするためのサイト別転送テーブルが選ばれる。ここでは、一致す
るものが見つかるものとする。
パケットが同一PEに接続されているCE装置宛である場合、そのパケットはそ
のCE装置に直接送信される。
パケットが同一PEに接続されているCE装置宛でない場合、パケットの「BGPネ
クストホップ」と、このBGPネクストホップがパケットの宛先アドレスに割当
てたラベルを見つける。このラベルはパケットのラベルスタックにプッシュ
され、最下位ラベルとなる。そしてPEはBGPネクストホップへのIGP経路をル
ックアップし、これによってIGPネクストホップと、このIGPネクストホップ
がBGPネクストホップのアドレスに割当てたラベルが決まる。このラベルはパ
ケットの最上位ラベルとしてプッシュされ、それからこのパケットはIGPネク
ストホップに転送される（しかし、BGPネクストホップがIGPネクストホップ
と同じである場合、2番目のラベルがプッシュされる必要はないかもしれな
い）。
Rosen & Rekhter 情報提供 [Page 13]
RFC 2547 BGP/MPLS VPNs 1999年3月
このとき、MPLSはパケットをバックボーンを通して適切なCE装置に運ぶこと
になる。すなわち、PルータとPEルータによる全ての転送決定は、このとき
MPLSを使って行われ、パケットのIPヘッダはパケットがCE装置に到着するま
で再び参照されることは無い。最後のPEルータは、パケットをCE装置に送信
する前にMPLSラベルスタックから最後のラベルをポップするので、CE装置は
オリジナルのIPパケットを見ることになる（なお、CEがラベル付きパケット
を受信したいケースの議論の一部は第8章を参照せよ）。
パケットがあるサイトからPEルータを通してバックボーンに入るとき、この
パケットの経路は、そのPEルータがそのサイトに関連付けた転送テーブルの
内容によって決定される。パケットがバックボーンから出ていくPEルータの
転送テーブルとは関係ない。その結果、同一のシステムに向かう複数の経路
を持つことができ、この場合、パケットに対して選ばれる経路はパケットが
バックボーンに入るサイトに基づくことになる。
Pルータから全てのVPN経路を除去することを可能にしているのは2階層のラベ
ル付けであり、この結果、このモデルの規模拡張性が得られていることに注
意する。バックボーンはCEへの経路でさえ持つ必要はなく、PEへの経路だけ
が必要となる。
6. PEがCEから経路を学ぶ方法
あるVPNに接続されたPEルータは、そのVPNのサイトのそれぞれについて、VPN
のどのアドレスがそれぞれのサイトにあるかを知っている必要がある。
CE装置がホストまたはスイッチである場合、通常このアドレスの集合をその
装置と接続されているPEルータに設定する。CE装置がルータである場合、PE
ルータがこのアドレスの集合を得るための方法はいくつかある。
PEは、設定されたRDを使用してこのアドレスをVPN-IPv4アドレスに変換する。
そして、PEはこのVPN-IPv4経路をBGPへの入力として扱う。サイトからの経路
がバックボーンのIGPへ流れ込むことはあり得ない。
正確に言うと、どのPE／CE経路配布技術が可能であるかはCEが属しているの
が「トランジットVPN」であるかどうかに因る。「トランジットVPN」とは、
「第三者」から（すなわち、VPN内にないルータから）の経路を受信し、その
経路をPEルータに再配布するルータを含むものである。トランジットVPNでな
いVPNは「スタブVPN」である。およそ全てのグループ企業ネットワーク等を
含めて、圧倒的多数のVPNがこの意味での「スタブ」であると思われる。
使用可能なPE／CE配布技術は次のとおりである。
1. 静的ルーティング（すなわち設定）は使用可能である（おそらくこれ
はスタブVPNでしか役に立たないだろう）。
2. PEルータとCEルータがRIPピアになり、CEはRIPを使用してPEルータに
CEルータのサイトで到達可能なアドレスプレフィックスの集合を教え
ることができる。RIPをCEで設定したときは、他のサイトからのアドレ
Rosen & Rekhter 情報提供 [Page 14]
RFC 2547 BGP/MPLS VPNs 1999年3月
スプレフィックス（すなわち、PEルータからCEルータが学んだアドレ
スプレフィックス）を決してPEに広報しないよう注意しなければなら
ない。より正確に言うと次のようになる。PEルータPE1が、VPN-IPv4経
路R1を受信し、その結果IPv4経路R2をCEに配布した場合、R2はそのCE
のサイトからPEルータPE2に戻すような配布をしてはならない（ここで、
PE1とPE2は同一ルータかもしれないし、異なるルータかもしれない）。
ただし、PE2がR2をR1とは異なる（すなわち、R1とは異なるRDを持った）
VPN-IPv4経路に対応付けている場合は除く。
3. PEルータとCEルータがOSPFピアとなることができる。この場合、サイ
トは1つのOSPFエリアであるべきで、CEはそのエリアのABRであり、PE
はそのエリア以外のABRであるべきである。また、PEは同一サイトにあ
るCEにこれ以外のルータリンクをレポートすべきではない（この技術
はスタブVPNでのみ使うべきである）。
4. PEルータとCEルータがBGPピアとなり、CEルータはBGP（特にEBGP）を
使用して、PEルータにCEルータのサイトのアドレスプレフィックス集
合を教えることができる（この技術はスタブVPNでもトランジットVPN
でも使用できる）。
純粋に技術的な視点から見ると、これは以下で見るように断然良い技
術である。
a) IGPの他の手段とは異なり、これはPEが複数のCEと話すために
複数のルーティングアルゴリズムインスタンスを実行する必
要が無い。
b) BGPは、異なる管理で動作しているシステム間でルーティング
情報を渡すという、まさにこの機能のためのものとして設計
されている。
c) サイトが「BGPバックドア」、すなわちPEルータ以外のルータ
とBGP接続を持つルータを含むときでも、このプロシージャは
全ての状況で正しく動作するだろう。他のプロシージャは、
具体的な状況によって動作したりしなかったりする。
d) BGPを使用することで、経路の属性をCEからPEへ渡すことが容
易になる。例えば、CEは各経路に対して、PEが経路に付ける
ことを許可したターゲット属性の中から、特定のターゲット
を使うように促すことができる。
一方で、顧客自身がすでにインターネットサービスプロバイダ（ISP）
であるという場合を除けば、BGPを使用することは、CE管理者にとっ
てほとんど未知のものとなるだろう。
サイトの属しているVPNがトランジットVPNではないなら、ユニークな
自律システム番号（ASN）を持つ必要がないことに注意する。トラン
ジットVPNに属していないサイトのCEは、全て同一のASNを使用するこ
Rosen & Rekhter 情報提供 [Page 15]
RFC 2547 BGP/MPLS VPNs 1999年3月
とができる。これはプライベートASN空間から選ぶことができ、PEに
よって取り除かれる。ルーティングループは起源サイト属性（後述）
を使用することで防がれる。
あるサイトの集合がトランジットVPNを構成するとき、BGPコンフェデ
レーションとして記述し、VPNの内部構造がVPN外のルータから見えな
くなるようにする方が都合がよい。この場合、VPN内の各サイトはバ
ックボーンに対して2つのBGP接続を必要とする。1つはコンフェデレ
ーションの内部で、1つは外部である。バックボーンとサイトが異な
るポリシーを持てることを考慮するために、 従来のイントラコンフ
ェデレーションプロシージャを多少修正する必要がある。バックボー
ンは1つの接続上ではコンフェデレーションのメンバーであるが、他
の接続上ではメンバーではない。この技術はVPNサービスの顧客がISP
であるとき役に立つ可能性がある。この技術では、顧客がISPである
の場合、自分のISPピアの1つからVPNバックボーンサービスを得るこ
とができる。
（しかし、VPNの顧客がISP自身であり、CEルータがMPLSをサポートし
ているなら、もっと単純な技術が使用でき、ISPはスタブVPNと見なさ
れる。第8章参照）
PEがサイトのアドレスプレフィックスを知るための各種手法を区別しなくて
よいとき、単純にPEはそのサイトから経路を「学んで」いると言うことにす
る。
PEがサイトから学んだVPN-IPv4経路を再配布するには、その前に経路に属性
を割り当てる必要がある。このときの属性は次のとおり3つある。
- 起源サイト
この属性は、PEルータが経路を学んだサイトをユニークに特定する。あ
る1つのサイトから学んだ経路は、全て同一の起源サイト属性が割り当
てられなければならない。たとえサイトが1つのPEに複数接続されてい
ても、また複数のPEと接続されていてもである。異なる起源サイト属性
は、異なるサイトに使用されなければならない。この属性は拡張BGPコ
ミュニティ属性として符号化される（第4.2.1節）。
- 起源VPN
第4.2.1節参照。
- ターゲットVPN
第4.2.1節参照。
7. CEがPEから経路を学ぶ方法
この節では、CE装置がルータであることを仮定している。
Rosen & Rekhter 情報提供 [Page 16]
RFC 2547 BGP/MPLS VPNs 1999年3月
一般的にPEは、CEから送られてきたパケットをルーティングするために使用
する転送テーブルにPEが入れた経路は全て、そのCEに配布して構わない。た
だし1つの例外がある。それは、経路の起源サイト属性があるサイトを示して
いるとき、そのサイトのCEにはその経路を再配布してはならないということ
である。
しかし、ほとんどの場合、PEが単純にCEへデフォルトルートを配布するだけ
で十分であろう（この場合、PEへ向けたデフォルトルートをCEに設定すれば
十分でもある）。これは一般的に、自身でデフォルトルートを他のサイトに
配布する必要がないサイトならどこでも使えるだろう（例えば、企業VPN内の
あるサイトがその企業のインターネットへのアクセスを持っているとき、そ
のサイトはデフォルトを他のサイトに配布する必要があるかもしれないが、
そのサイト自身に対してデフォルトを配布できない）。
CEからPEへ経路を配布するのに使用するプロシージャは全て、PEからCEへ経
路を配布するのにも使用される。
8. CEがMPLSをサポートする場合どうなるか
CEがMPLSをサポートし、“かつ”VPNからの経路全体を取り込んで構わないな
ら、PEはこの経路のそれぞれのラベルを配布することができる。PEがこのよ
うなラベルの付いたパケットをCEから受信したとき、PEは（a）そのラベルを
BGPで学んだ対応するラベルに置き換え、（b）それに対応する経路へのBGPネ
クストホップに対するラベルをプッシュする。
8.1. 仮想サイト
CE／PE経路配布がBGPで行われた場合、CEはMPLSを使用して複数の仮想サイト
をサポートできる。CE自身が各仮想サイトに対する個別の転送テーブルを持
てる。このテーブルは、PEから受信した経路の起源VPN属性とターゲットVPN
属性に従って格納されている。CEが経路全体をPEから受信している場合、PE
がCEから受信したパケットのアドレスルックアップは全く必要ない。別の方
法として、各VPNごとに1つの（ラベル付き）デフォルトルートをPEがCEへ配
布することが可能な場合もある。そのとき、PEはラベル付きパケットをCEか
ら受信したとき、どの転送テーブルを調べたらいいかを知っていることにな
る。CEがパケットに付けたラベルによって、パケットが入ってきた仮想サイ
トだけが識別されるのである。
8.2. ISP VPNのスタブVPNとしての表現
あるVPNは実はISPであるのだが、そのCEルータがMPLSをサポートしている場
合、そのVPNは実際にスタブVPNとして扱うことができる。CEルータとPEルー
タは、VPNの内部の経路だけを交換する必要がある。PEルータは、この経路の
それぞれに対するラベルをCEルータに配布するだろう。このとき、VPN内の異
なるサイトのルータ同士はBGPピアとなれる。CEルータがパケットの宛先アド
レスをルックアップするとき、ルーティングルックアップは常に内部アドレ
スで解決される。これは通常、パケットのBGPネクストホップのアドレスとな
る。CEはパケットに適切なラベル付けをしてPEにパケットを送信する。
Rosen & Rekhter 情報提供 [Page 17]
RFC 2547 BGP/MPLS VPNs 1999年3月
9. セキュリティ
以下の条件
a) バックボーンルータは、信頼できないまたは不確かな起源からラベル
付きパケットを受け入れない。ただし、IPヘッダやスタック中の下位
ラベルを調べずに、そのパケットをバックボーンから送出する場合は
除く。
b) ラベル付きVPN-IPv4経路は、信頼できない、あるいは不確かな起源か
ら受け入れない。
が満たされているなら、このアーキテクチャが提供するセキュリティはフレ
ームリレーやATMバックボーンがVPNに提供するセキュリティと実質同等とな
る。
注目すべきは、MPLSを使わずにIP-within-IPトンネリングの形式のどれかを
使ってこのレベルのセキュリティを提供できるようにするよりも、MPLSを使
用して提供する方がずっと簡単だということである。上記条件の1番目が当て
はまらない場合に、ラベル付きパケットの受信を拒否するというのは簡単で
ある。IPパケットがIP-within-IPトンネリングされたパケットの場合、ルー
タに「誤った」場所に向かっているパケットを受信拒否させる設定はかなり
難しい。
MPLSを使用することで、IPv4ルーティング情報のドメイン間配布による方法
に頼らずに、VPNが複数のSPを跨がるようにできる。
VPNユーザがトンネルモードIPSEC [5]を使用して、セキュリティを高めるこ
とも可能である。これはこの節の以降で議論する。
9.1. CEルータ間のポイントツーポイントセキュリティトンネル
セキュリティを意識しているVPNユーザは、バックボーンを通るようなパケッ
トの一部あるいは全てに認証や暗号化を適用したいと考えるかもしれない。
現在、この機能を得るための標準的なやり方は、IPSECトンネルモードを使用
して、VPNのCEルータのあらゆる組合せに「セキュリティトンネル」を作るこ
とだろう。
しかし、これまで述べてきた手法では、パケットを送信するCEルータが、パ
ケットを送るべき次のCEルータがどれか決定できない。いまだに、この情報
はIPSECトンネルモードを使用するために必要なのである。したがって、この
ような情報を利用できるようにするために、我々はこの手法を拡張しなけれ
ばならない。
これを実行する方法は[6]に示されている。全てのVPN-IPv4経路は、その経路
を通るとき通過する次のCEルータを判別する属性を持つことができる。この
情報がVPN内の全てのCEルータに提供されれば、標準的なIPSECトンネルモー
ドを使用することができる。
Rosen & Rekhter 情報提供 [Page 18]
RFC 2547 BGP/MPLS VPNs 1999年3月
CEとPEがBGPピアの場合は、この情報をBGP属性として提供するのが自然であ
る。
IPSECを使用する各CEはアドレスプレフィックスの集合を設定して、このアド
レスのいずれかへ危険なトラフィックが送信されるのを全て禁止すべきであ
る。これは、何かの理由で必要な情報を得ることに失敗したとき、CEが危険
なトラフィックを送信することを防ぐ。
MPLSを使用してIPSECトンネルの2つのエンドポイント間でパケットを運ぶと
き、IPSECの外側ヘッダは実際には何も機能しない。MPLS使用時に外側ヘッダ
を省略できるIPSECトンネルモードの方式を作ることは有益かもしれない。
9.2. マルチパーティセキュリティアソシエーション
CEルータの各ペアの間でセキュリティトンネルを設定する代わりに、単一の
マルチパーティセキュリティアソシエーションを設定することは都合が良い
こともある。このセキュリティアソシエーションでは、あるVPNに所属する全
てのCEルータが同一のセキュリティパラメータを共有する（例えば、同じ秘
密鍵、同じアルゴリズムなど）。そして、入口CEは、どれがデータを受け取
る次のCEかを知る必要が無くなり、どのVPNにデータが行くかを知るだけでよ
くなる。複数のVPNに所属するCEは、それぞれに対して異なるセキュリティパ
ラメータを使うことができ、したがって、例えばイントラネットパケットが
エクストラネットに晒されることなどを防ぐ。
このようなやり方の場合、標準的なトンネルモードIPSECは使用できない。な
ぜなら、「外側ヘッダ」のIP宛先アドレスフィールドに埋める方法が無いか
らである。しかし、実際にはMPLSを転送に使用する際、この外側ヘッダを処
理する必要は無い。トンネルのエンドポイントのIPアドレスを知らなくても、
PEルータはMPLSを使用してそのエンドポイントにパケットを送ることができ
る。「内側ヘッダ」のIP宛先アドレスだけを知っていればよいのである。
このようなやり方の大きな利点は、ルーティングの変更（特に、あるアドレ
スプレフィックスに対する出口CEの変更）がセキュリティメカニズムに対し
て透過的になることである。これは、マルチプロバイダVPNの場合に特に重要
となることがある。マルチプロバイダのとき、セキュリティメカニズムをサ
ポートするためだけに、このようなルーティング変更の情報を配布しないと
いけないというのは、規模拡張性の問題を引き起こしてしまう可能性がある。
もう1つの利点は、外側IPヘッダの必要性が無くなることである。なぜなら、
MPLSカプセル化がその役目を実行するからである。
10. サービス品質
この文書の焦点ではないが、どのVPNサービスでもサービス品質は鍵となる要
素である。MPLS／BGP VPNでは、シムヘッダ[10]の「試験」ビットを使用して、
あるいはバックボーンにATMを使用している場合はATM QoS機能を使用して、
既存のL3 QoS機能をラベル付きパケットに適用できる。[1]で議論されている
Rosen & Rekhter 情報提供 [Page 19]
RFC 2547 BGP/MPLS VPNs 1999年3月
トラフィックエンジニアリングの動作はMPLS／BGP VPNに直接適用可能である。
必要ならトラフィックエンジニアリングを使って、特定のサイトの組み合わ
せの間で、特定のQoS特性を持ったLSPを確立することができる。MPLS／BGP
VPNが複数のSPを跨ぐ場合、[7]に記述されているアーキテクチャが有効な場
合もある。SPは統合サービスか差別化サービスかのどちらか相応しい方の機
能を、VPNに適用することができる。
11. 規模拡張性
この文書を通して規模拡張性の問題を議論してきた。この節では、規模拡張
性に関して我々のモデルの主な特性を簡単にまとめる。
サービスプロバイダのバックボーンネットワークは（a）PEルータ、（b）BGP
ルートリフレクタ、（c）（PEルータでもルートリフレクタでもない）Pルー
タ、そしてマルチプロバイダVPNの場合の（d）ASBRで構成される。
PルータはVPNの経路を一切保持しない。VPNトラフィックを正しく転送するた
めに、PルータはPEルータとASBRへの経路だけを保持すればよい。2階層のラ
ベル付けを使用することで、VPN経路をPルータから排除できるのである。
PEルータはVPN経路を保持するが、直接接続されているVPNだけを維持してい
る。
ルートリフレクタやASBRは、VPNの中でパーティショニングすることができ、
それぞれのパーティションはそのサービスプロバイダが提供するVPNのうち一
部のVPNの経路だけを運ぶ。したがって、1つのルートリフレクタまたはASBR
が全VPNの経路を保持する必要はない。
結果として、サービスプロバイダネットワーク内の1つの構成要素が全ての
VPNの全ての経路を保持する必要はない。よって、VPN数増加に対応するため
のネットワークの性能の合計は、個々の構成要素の性能に限られない。
12. 知的財産に関する配慮
Cisco Systemsは、このドキュメントで発表された全ての技術に対して特許ま
たは他の知的財産保護を求めることができる。この文書から生じた標準が
Cisco Systemsに委譲された1つ以上の特許権によって保護されている、ある
いは保護される予定の場合、Ciscoはこの特許を開示し、妥当かつ無差別な条
件で使用を許諾する意向がある。
13. セキュリティへの配慮
このメモ全体でセキュリティ問題を議論してきた。
14. 謝辞
Ravi Chandra、Dan Tappan、Bob Thomasには本作業への多大なる貢献をいた
だいた。
Rosen & Rekhter 情報提供 [Page 20]
RFC 2547 BGP/MPLS VPNs 1999年3月
15. 著者連絡先
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
16. 参考文献
[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.
Rosen & Rekhter 情報提供 [Page 21]
RFC 2547 BGP/MPLS VPNs 1999年3月
17. 著作権表明全文
Copyright (C) The Internet Society (1999). All Rights Reserved.
本ドキュメントと その翻訳を他者へ複製、提供して構わない。また本ドキュ
メントの解説や説明もしくは実装段階で補足するような派生物は、上記著作
権表示とこの段落を含めて提供することで、全部または一部をいかなる制限
も設けずに作成、複製、出版、配布してもよい。しかし、本ドキュメント自
身には、著作権表示の削除や、Internet Societyや他のインターネット団体
への参照を削除など、いかなる修正も許されない。ただし、インターネット
標準の開発目的に必要な場合を除く。この場合、インターネット標準化過程
で定義される著作権に対する手続きに従わなければならない。また、英語以
外の言語に翻訳する際に必要な場合も除く。
上記で認められた制限付きの許可は永久的なものであり、Internet Society
や、それを継続または譲渡された者によって破棄されることはない。
本文書およびその中に含まれる情報は、「無保証」を原則に提供され、
Internet SocietyとInternet Engineering Task Forceは、明示的・暗示的な
全ての保証を放棄する。この保証には、文中の情報を使用することがいかな
る権利も侵害しないという保証、また商用利用や特定の目的に対する適合性
の暗黙の保証も含まれるが、それに限らない。
Rosen & Rekhter 情報提供 [Page 22]
一覧
スポンサーリンク
