■日時：2000/6/16（金）　15:20〜16:55 ■場所：Canon本社（下丸子） ■タイトル： パネルセッション「MPLSによるIP-VPNサービス」 ■発表者: 　　コーディネーター：石井 秀雄（グローバルワン株式会社） 　　パネリスト　　　：松嶋 聡 （日本テレコム株式会社） 　　　　　：池尻 雄一（NTTコミュニケーションズ株式会社） 　　（敬称略） ■ログ：村井 朋生（古河電工株式会社） 　　　　山川 裕之（古河電工株式会社） 　　　　浜田 泰幸（NTTコミュニケーションズ株式会社） ---------------------（内容）--------------------- ◆はじめに（石井さん） 　MPLSについて発表しようと思ったが、新技術であり最近注目されて 　いる故、パネルセッションという形式にした方がいいとのことで 　池尻さんと松嶋さんといっしょにやることになった。 ○MPLSってなに？ 　・MPLSはVPNを作るものだけではない 　・ネットワークとしてTCP/IP を利用し、Qos/Cos 等の実装も可能 ○MPLSを使ったIP-VPNの利点 　・とにかく新しいから良い 　・PVCやFRと言ったフルメッシュ相当のネットワーク環境を構築可能 　・かってにVPNになる 　・プライベートでも、同一のアドレスでもラベルやtagでつながる ○どんな構成？ 　・たとえば10拠点でVoIPするとメッシュで高くなるがMPLSならそんな 　　こともない！ ○問題点は・・・ 　・OSPF、BGPは大丈夫というが・・・ 　・VPNでは同じアドレスが複数存在するので、現状のインターネット 　　の経路数8万経路を軽く越えて、100万を超えることも考えられる？ 　・BGPに関してはルートリフレクタも必要か？ ○技術面 　・3社での直面している問題点は？（そこら辺をこの場で話したい） ◆RFC2547の仕組み（池尻さん） ○MPLS-VPNとは？ 　・C社が中心にRFCを記述、InformationalなIP-VPN技術 　・VPN経路情報交換にBGPを使用 　・レイヤ3がエッジで終端されるPeerモデルのIP-VPNである ○RFC2547に登場するルータたち 　・PLS PEルータ、MPLS Pルータ、MPLS CEルータ 　・PEルータ：MPLSエッジルータ、お客様を収容するルータ 　・Pルータ：MPLSコアルータ 　・CEルータ：お客様ルータ 　・PEルータのみVPN経路を知っている ・PルータはVPN経路を知る必要はない ○プロトコル構成（図参照） 　・IGP（OSPF,ISIS）をしゃべっていることが前提 　・VPNに関する情報をmpBGPにて交換（フルメッシュ。RR設置も可） 　・Pルータはルーティングに関しては知らない 　・PEルータのみルーティングに関して知っている 　・PEルータ、Pルータ間でラベル情報を交換 ○パケットの流れ 　・レイヤ2ヘッダとIPヘッダの間にラベル情報をmpBGPの情報が入る 　・2つのラベル(VPNラベル、経路ラベル)を利用したデータ転送 　・PEルータで2つのラベルが付けられ、経路ラベルにより出口のPE 　　ルータへ 　・Pルータは経路ラベルのみ参照し出口のPEルータへ転送 　・出口のPEルータでVPNラベルが外され目的のCEルータへ転送 ○RFC2547モデルの特徴 　・CEルータは普通のルータである！なにも必要なし 　・PEとCEの間はいろんなルーティングプロトコルが使える 　　→収容効率が上がる！ 　　→いろんなユーザに対応可能 　・複数のVPNを1台のPEルータに収容可能 ○PE-CE間のルーティングプロトコル 　・いろいろあります！（static、BGP、RIP、OSPFなど、そのISP次第！） 　・PE-CE間のプロトコルからバックボーンへはPEでmpBGPに対し、 　　Redstributeする ○複数のVPN 　・VRF 　　→インタフェース、バックボーンそれぞれでVPNテーブルを持っている ○異なるVPN間で同じアドレス 　・IPv4のアドレスを8byte→12byteへ拡張する（Route Distinguisher 　　（RD）を使用） 　・RD(8byte)のフォーマット：Type 2 bytes, Value 6 bytes 　・RDにはTypeは2種類が定義されている 　・Type0にASN(2bytes)+任意(4bytes)、Type1にIPAddress(4bytes)+ 　　任意(2bytes)を割り当てて識別する 　　→ASを認識できるのでこれを使ってISP間接続も可能になる 　・RDが違うと別経路！(最適経路決定も別) ○技術詳細 　・BGPで運べるの？ 　　→multiprotocol extensions for BGP-4(RFC2283)ならOK 　・経路制御 　　→BGPと同じ！ 　　→拡張コミュニティーもある ○multiprotocol extensions for BGP-4（mpBGP） 　・マルチキャストやIPv6と同じ 　・mpBGPがやり取りできるルータと認識できればコミュニケートする ○拡張コミュニティー 　・かならずRoute Target（RT)がつく 　・VRFには必ずひとつ以上のRTが割り当てられる 　・このRTによってVPN間接続やAS間接続が可能となる 　・RTとRDは同じ形式 　・ルーティングテーブルでVPN-AのアドレスをVPN-Bに突っ込むこと 　　により、２VPN間で相互通信が可能 ○RFCの実際 　・実は細かい規定はない！ 　・実際に動くのはC社のみ？ 　・コアはVPNの経路を知らないのでとっても軽いが、エッジはルーティング 　　やラベリングのためにメモリの消費など重くなっている 　・VPNごとに経路を持つので、経路がすぐに膨れ上がる！フルルートが 　　くると厳しい ○RFCの将来 　・draft-rossen-rfc2547bis-01.txtでアップデート中 　・C社以外にも広がってほしい 　・VPNの経路のやり取りとThe Internetの2つになるのかな・・・ 　・TE(Traffic Engineering)との組合せ、IPSECとの戦い、VPNの方式が 　　多数あるので果たしてMPLSがメジャーになるのだろうか？ 　・将来の展望は未定 ◆LDPについて（松嶋さん） ○LDPとは？ 　・Mラベル情報を運ぶためのプロトコルの一つ 　・他には RSVP Extension, BGP など 　・Destination ベースのLDP ○LDPを使ったMPLS 　・AS内のIGPに適用される 　・経路の出所となるルータLER：MPLSではないルータを収容しているルータ 　・集約経路を持っているところもLER(エッジ)である ○ちょっと詳細 　・Hello（マルチキャスト） 　・初期化（Init） 　・ネゴが取れるとpeerが張れる！ 　・あとはHelloやkeepaliveでpeerをメンテする 　・ここら辺は通常のやり取りといっしょかな？ ○いろんな動作モード 　・動作モードは、 ラベル分配モード とりあえず全部 要求分だけ ラベル分配コントロールモード（勝手に訳す） 直ちに 相手を待って ラベル保持モード 必要分だけ とりあえず全部 それぞれのモードのうちひとつを選んで動作 　・選ぶモードによってLSRの性格が変わる！ ○実際の動作 　・まずはIGPで経路を設定 　・次にノード間でそれぞれラベルを設定 　・ラベルがアサインされたらすぐに隣のLSRに教えたり、逆にラベルを 　　聞いたり、知らないと教えなかったりする（そういう動作がそれぞれ 　　のモードに相当） 　・IGPのNextHopが変わると以前アサインしたラベルをリリースする 　　（アサインし直す）→ラベルの資源の有効活用をしている 　・上記とは逆に両方保持して、トポロジの変化に対応する場合もある ○LDPのメッセージ 　・各種LDPメッセージヘッダ、必須パラメータ、オプションパラメータ 　　で構成 ○LDPの使われどころ 　・IP-VPN等のコアのセッションで使用する 　・P〜PE間はLDPにてラベルを交換し、PE〜PE間ではBGPにてラベル交換 　・普通のIPネットワークでも利用可能 　　→コアルータはBGPを知らなくても中継可能 ○LDPの実装状況 　・C社：実際はまだリリースされていない 　・J社：JUNOS4.0で、これから 　・他にもあり 　・C社は実際にはTDP（tag）でLDPと互換性はないが、動作はいっしょ ◆MPLS Configration例（Ciscoの場合）（石井さん） ○BGPの運用している人（５％程度？）に向けて話します（笑） ○CE編 　・特別な設定は必要なし！ 　・ただしダイナミックルーティングに関してはISPにご相談 　・スタティックもOK ○PE編 　・小難しい説明があったがコマンド一発！ 　・ユーザ単位にVRFを入れる 　・インタフェースに入ってvpn番号、RD、ターゲットのRDを書く 　　→するとそのVPNに所属し、そのターゲット（自分も含める）と通信が 　　　可能になる 　・BGPではPEとpeerをはる 　・neighbor XXX activateと入れないと実は動かない！これがミソ？？ 　・neighbor XXX as-overrideと入れると仮に同じASであったとしても 　　バックボーンのASに書き換えて通信することができる！ 　・AS番号としては250→100→250でも片端では100 100と見える！ ○Zebra MPLS-VPNサポート 　・ZebraにMPLS-VPNを実装！（RRにできる？） ◆パネルセッション（3人で） ○VoIPがターゲットだと思うが・・・使えるか？（松嶋さん） 　・とりあえずパケットにボイスを乗せたい！という要望がある 　・なぜダメか？ 　　→回線が細い、遅延に弱い 　・T1くらいあれば何とかなるかな？ 　・フルメッシュでVoFR、VoATMならある程度いけるのではないだろうか？ 　・フルメッシュモデルのMPLS-VPNなら筋がいい ○（池尻さん） 　・128kくらいでやりたいといわれるが・・・ 　・他のセッションが走っているところでボイスを流すと100〜200msくらい 　　の遅延がすぐ出てしまうので、使えなくなる 　・やはり他の技術（WFQ等）と組み合わせないとMPLS-VPNとは言え使えない ○（石井さん） 　・MPLSは何でもOKではない 　・J社とC社のLDPの接続が気になる（J社のホームページではできると 　　いっている） ○（松嶋さん） 　・実はLDPでの接続実験をした 　・とりあえずつながった 　・問題は小さいのでいずれ解消される 　・C社は結構いいつくりをしていたので是非早く出して欲しい！ ○（石井さん） 　・MLで議論になっているのはルーティングテーブルが大きくなることが 　　上がっている 　・いいソリューションはないか、とのことでZebraでのRR対応を考えた 　・C社のRRはC社のルータでしか動かない、そのためにルータは買えない 　　小規模の場合は特に無理 　・Zebraにはいろいろ実装して、かなりマニアックなコマンドのある ○（松嶋さん） 　・石黒さんは一晩でいろいろ乗せてくれる ○（石黒さん） 　・完璧だと思ってるけど、C社のルータはなぜかNextHopが火星を 　　向いちゃう 　・いろいろ苦労している 　・せっかく作ったので、ぜひこの先も使って欲しい！ 　・prefixがかなり長いのでメモリがすごく消費する・・・ ○（池尻さん） 　・RFCには細かいことはぜんぜん書いていないので、Zebraへの実装でいろ 　　いろわかることがあって勉強になった ○Q&A（Q：質問、A：回答、C：コメント） Q1：ATMやFRに比べて（オペレーションの視点から）楽になるのか？ A1：（松嶋さん）お客様は楽になると信じている。PVCの管理などはいら 　　ない。キャリアのオペレータはしんどい。（現状、Staticのみなので） 　　また、お客様IGPを受けると・・・・ 　　（池尻さん）お客様のルーティングはキャリアでやるので楽になる 　　はず。ただ、BGPで接続する場合には、その管理をお客様でやっても らわなくてはいけない。 　　（石井さん）基本的には同じだが、うちはグローバルなので、ちょっと 　　事情が違う。お客様にいまどきStaticをお願いできない。 Q2：これはスケールしないのでは？数が大きくなってきたときに回らない 　　のでは？ A2：（松嶋さん）スケールしない面もある。お客様のIGPを受けるとモロ 　　影響が出てしまう。現状は力任せでやるしかない。あとはメモリを 　　ふんだんにつんだRRに任せたい。 　　PEはメッシュで張るが自分の属さないVPNの経路ははじくので大丈夫。 　　（池尻さん）お客様の経路設計がめちゃめちゃだとダメなので、その 　　ケアは必要。 Q3：米国ではトラフィックエンジニアリングがメインのようだが、その 　　動向は？ A3：（松嶋さん）スタートポロジーなので線さえ太くすれば、どこかを 　　迂回する必要はまだない。 　　（石井さん）USでは太いところと細いところの差が激しいのでトラ 　　フィックエンジニアリングが必須だと思う。（日本とは事情が違う） C4：スケーラビリティに関してはベンダによっても違うようだ。IETFでも 　　今後話される。 Q5：今使っているVPNをそのまま使いたい。今使っているOSPFを使いたい。 　　全部できなくてもArea0だけでも使いたい。 A5：（松嶋さん）本当にOSPFでやらなきゃいけないお客様は実は少ない気 　　がする。たとえばDefaultを使ったり。なので、VPNでは一番しっかり 　　したStaticを勧めたい。キャリアのエゴかも知れないが、お客様との 　　お互いに幸せになれる案を採用したい。また、Zebraに期待したい。 C6：複数社のVPNを使いたい。 C7：（石川さん）IPsecなども必要だと思う。今後もいいものにしていき 　　たい。