1.タイトル　EoMPLSサービスの現状とその技術、運用 2.発表者　NTTコミュニケーションズ 大澤 宏 氏 3.ロガー　小池 大介 AboveNet Japan, Inc. 4.時間　2004/1/30 11:00〜11:30 (発表11:00〜11:20、質疑応答11:20〜11:30) 5.発表の焦点、論点、議題 EoMPLSはCiscoやJuniperなど、メジャー所の製品には既にインプリされている が、「ウチではこういう風にEoMPLSを使っているよ」、という話がされる事は これまで余り無かった。 今回はNTT-Comでの事例を話し、他に使っている方がいれば意見交換をしたい。 6.発表の流れ + はじめに - NTT-Comでは3年ぐらい前からEoMPLSを使い始めた。 初めは広域Etherのバックボーンとして使用していたが、最近はユーザ 向けにEoMPLSを専用線ライクに提供すると言うサービスも行っている。 + Ether系 L2サービスの特徴 EoMPLSをEtherの線としてみた場合に、他のEther系サービスと比較し てどういう特徴があるか? - SONETベースのEthe専用線 とにかく安定している 信頼性が高いのが一番の特徴 1+1で無瞬断切り替え機能等を提供していると、多少遅延が多めになる - 広域Ether Switchを使ったマルチポイントのサービス Ether Switchの機能を網側で提供してくれる 機能面とは関係ないが、非常に安く提供されている ただ単にL2の線として使っているお客様(例えばISP)も多い 遅延が大きめ(場所による) ツリー型の論理構造を取るので、遠回りすることがあるため 極端な例を言えば、北海道から青森に行くのに東京を経由す る事も有り得る - それに対してEoMPLSを使ったサービスは… (今の所)Point to Pointである LSR(MPLSルータ)を使ったパケット多重型の網なので、従量型の課金設 定が可能輻輳やshapingにより遅延やjitterが発生する事があるので注 意が必要 MPLS-TEで、帯域の一部だけ保障しますよ、と言ったサービスが可能 QoSは広域Etherでも出来るが、広域Etherの場合ユーザポート で色々やるので少し性質が違う + どのような箱を持ってくれば作れますか?(NTT-Comの例) - 基幹の部分にはWDM 両端にSONETの伝送装置を置くと、SONETベースのEther専用線 (ギガウェイサービス) SONETの代わりにLSR(MPLSルータ)を付けると、EoMPLS (フレックスギガウェイサービス) MPLSルータの外側にEther Switchを持ってくると、広域Ether (e-VLAN) # 場所によって提供形態が違うので、全てこうだと言うわけ ではないです + EoMPLSの技術的な話 - XoMPLS X = Etherだけじゃなく、ATMやフレームリレー等も一緒に出来ます 似たような規格が色々あるので、他の規格と区別するためMartiniと呼 んでいる - 技術的な本質 LSPをトンネルとして使っている L2のフレームをカプセリングして反対側に送るだけ 細かい所は色々あるが、これだけ分かっていればとりあえずok + EoMPLsを使うと何がうれしいのか? - Gigaの口で150Mしか流さない、という線がたくさんあった場合、束ねる事 ができる - MPLSと言えばTE トラフィックが急増した -> 他の空いている経路に逃がそう、と言っ た柔軟な対応が可能 - マルチサービスエッジ ルータなので当然IP(ISP)ができる MPLSと言えばIP-VPNなのでこれもできる 最近だと、VPLS(LSRだけで広域Etherを提供する)もできる これらすべてを一個のノードで提供できる(一般論) # NTT-Comでは統合していない # MPLS網もIP-VPN網も別個のシステムになっている # 理由の一つとして、一台に統合しても今の所コストメリッ # トが出にくいと言うのがある + NTT-ComのMPLS網 - 現在約60ノード 年度内に70ノードぐらいまで増やす計画 OC-48、OC-192のPOSインターフェースで相互接続 - LSPは全てPrimary、Backupの冗長構成(Global Repair) 予備用のLSPを予め張っておき、障害時には切り替える - 特徴的な点として、ルーティングにはISISを使っている + 設計思想 - 大元のモチベーションとしては、リンクの帯域を有効利用したかった NTT-Comの持っているFiber、WDMのリソースを意識してトポロジーを組 んでいる - 結果として、コア、エッジの区別が無い完全にフラットな網になった 全てのルータが、UNIでもあり、別のルータからのトラフィックのフォ ワーディングもする ルーティングに関しても、ISISのl2 onlyで、コストもいじってない # 今までISIS周りでトラブルが起きたことは無く、非常に安定している - 手動TE リンク帯域に関わらず、流れているトラフィックを見て流す経路を決 めている - explicit route IPアドレスを手動で指定すると言う意味 - 網に載せているトラフィック EoMPLS(当然一番割合が多い)、広域Ether、OCN(ごく一部、アクセスま わりで使用)、ホットスポット、VoIP、マンションインターネット系 トラフィックパターンとしては通常のインターネット型(23時頃がピー ク) + こんなことも出来ます(付加的な機能) - リンクダウン情報転送 PE(MPLSエッジ)とユーザの間がきれた場合に、反対側にその情報を伝 え、反対側のポートも落として(APSでは無く、Etherの光を落とすだけ) 瞬時に代替経路に切り替える 何が嬉しいかと言うと、ユーザ側での切り替えが高速にできる LSPが完全に落ちた時は両方とも落とす様になっている - ATMのVP、VCライクに使って仮想専用線としてもつかえる - 時間が無いためスライド一つ飛ばします + 苦労話 TEを使って帯域を有効利用すると言うのが大元のモチベーションなの で、トラフィックを詰め込まなければいけない (〜以下は発表資料のpptと併読下さい〜) + LSPを新たに追加する - 図中のピンク色のノード間で追加する場合、 「赤い所は込んでいるので…」と単純に経路を選択すると、遠回りに なり、今度は遅延が気になってくる -> 混雑具合だけでなく、迂回分の遅延も考慮に入れなくてはならない - 「遅延は別にいいでしょう…」としても、この構成でバックアップを取ろ うとする と、single pointなノードが出来てしまう -> プロテクションも考慮に入れなくてはならない - この図ぐらいのトポロジーなら簡単に分かるが、実際はかなり複雑なトポ ロジーのため、パズルの様になってくる + QoS 帯域管理の運用も大変 + 判断する上で、3つぐらい見るところがある - グリーンのパケットは帯域保障分 たとえ今ちょっとしか流れていなくても、保障分まではいつでも流せ る様に確保しておかなければならない - イエローのパケットは従量分 実トラフィックを見なければいけない 流れた分だけ儲かると言う事もあり、基本的にはこのパケットは一切 落としてはいけない - レッドのパケットはベストエフォート分 これは実トラフィックを"見てはいけない" + 以上の項目を見て、溢れそうだと判断した場合… - 増設する? どこに増設するかが問題 柔軟なトポロジーを組んでいるので、あさっての方向に増設してそち らにトラフィックを逃がすと言う手もあるし… - LSPを移す? どのLSPをどこに移すのかが問題 移した事により今度はそっちが込んでしまい、LSPを玉突きのように移 していかなければならなくなったり… + 予備帯域の確保 大元のポリシーとしては、N対1の予備帯域を確保 -> 任意の一重故障の時にも帯域が溢れないような帯域設計をしようと 言う意味図の左上のリンクでの例(アニメーション) 今流れているトラフィックはオレンジとピンク 故障が発生すると、点線のバックアップ経路にトラフィックが移る ある線が故障した時、バックアップ経路に載っているトラフィックは オレンジ+緑になる 別のある線が故障した時、バックアップ経路に載っているトラフィッ クはピンク+緑になる ノードが故障した場合、LSPが完全に切れるのでトラフィックは緑だけ になる -> 他の所で障害が起こったからと言って、必ずしもトラフィックが増 えるとは限らない 上記の様な組み合わせをいちいち考え(障害を想定して)、必要な帯域 を算出しなければならない + レイヤー0/1 fiber route、WDMの問題 論理トポロジー的にプロテクションを取っていたとしても、実際は一 本のfiberを通っていたりすることがある 論理的なパスと実配線の差異にも注意しなければならない + バージョンアップ コア、エッジ共用のため、コアとしての動作、エッジとしての動作の 両方をチェックしなければならない 実際に、作業員を10人抱えて、丸一日使って一台バージョンアップし た事さえある - 色々苦労してます + シミュレータ TEのシミュレータは、出来合いのものがいくつかと、ATMの方にもTE関 連のシミュレータがあって、色々見てはいるものの、今の所は手作業 でやっている部分が多い + 今後について + Ether以外への適用 - ATM、フレームリレーに関してはもう技術的に問題なく出来ると考えてい て、今後やって行きたい - LSPがあがっているのにトラフィックが流れないというのが一番困るので… VCCV(keepalive系の技術) -> どんどん実装して欲しい (lspping、lsptracerouteなどはすでに幾つかの実装がある) ■質疑応答 JT　阿部さん TEのLSP管理は大変だと思うが、EoMPLSのVCIDの管理も大変では？ 具体的にはどのように管理されてますか? -> VCIDに関しては管理に苦労したことはない Gigabitの一束の線を入れているからそんなに数が行っていないと言う 事もある が、IDの範囲が広いので、網全体で一意のIDを使う事で何とか回して ます 国武さん ラボで、Explicitでglobal repairをやったことがあるが、高々10台程 度でもあきれるほど複雑だった (NTT-Comでは)それに加えてトラフィックも見てやっているので、感心 しました ただ、今後local repairまで視野に入れて、local repairの切り替わり 時の予備帯域まで考え出すと、将来的に本当に回していけるかという 気がしますが… -> 今回の発表の中では飛ばしてしまったが、全く同じ事を思っていま す 今の運用の仕方、あるいは、整理されてないトポロジーのため、local repairを使い始めた後、障害が起きて切り替わった時にトラフィック がどこに行くか分からないという状態になるのは目に見えている 今の所はまだ無いが、今後global repairの切り替え(1秒未満)では遅 い、50msで切り替えてくれ、と言われた時には考えなければいけない と思っている その時には、例えばトポロジーの全見直しぐらいの事をしなければい けないのでは、と思っている インテック・ネットコア ハガさん fast reroute関連でlocal repairの話が出たのでお聞きしますが、実 装はまだなんですか？ -> 網ではまだ使っていません まだ検討段階です 現状で、使われているルータはsingle vendorで固められているんです か? -> 使い分けとか細かい事は言えませんが、multiでやってます JT 松嶋さん バックアップ帯域の確保の話で、サービス毎に従量型とか帯域保障型 とかが決まってますが、local repair等の帯域の配分とかを考えると、 サービス別にバックアップLSPの設計をする事が重要になると思います そういう事も考えて帯域設計されているんですか? -> 別々のサービスが載ってはいますが、結局は先ほど挙げた3色に帰 結すると考えています なので、その3色だけ別々に管理できれば良いと思っています そのうち1色は一切考慮しないというポリシーになっているので、実質 2色だけ グリーンの帯域は単純に契約ベースで決まる話なので、それほど負荷 にはならない (コメント)今後色々なサービスを載せられてくると、オペレーション の問題で、例えばギガウェイのサービスはいいけどこっちのトラフィ ックはへこまさない様に、などと言われ出すと結構辛いのかなと思い ました -> VPLSでフルメッシュした時、ブロードキャストがsrcでコピーされ てしまってその瞬間に破綻するのでは、と言う問題もあったりします ブロードキャストだけshapeするとかは？ -> 実は広域Etherとかでもブロードキャストストーム防止のために、 ブロードキャストの帯域制限をしてたりします MPLSルータでもそういう機能は必要になると思っています JT 松嶋さん お客さんから見た時はEthernetなので、Ethernetのサービスを接いで 行く、と言うことができると思います これは、fast rerouteが発生して経路が変わったりした時に、RTTが１ linkで異様に変わる様な状況になります これをお客さんから見ると、地域の障害なのか中継の障害なのか切り 分けがしにくいのでは？ -> EtherのL2サービス全体に言える事だとは思いますが、確かにお客 さんから見え難いというのはある 実際に、遅延が絶対的に大きい、と言う話が苦情として多かったり、 網内でrerouteが起こった時に、遅延が突然変わったけどどうしたの、 と言う問い合わせがあったりします しかし、そこまで深い所を見ている、と言う話は聞いた事がないです (コメント)ちなみにウチの場合、いったん終端しているので、お客さ んにとっては分かりやすい反面、スポットで攻撃されるので結構辛い です お客さんから見ると嬉しいのかなと思いますが、こちらのオペレーシ ョンが丸分かりなのが辛いです NTT-Com ハマダさん この様にサービスの上にサービスが載っていたりすると、何かあった 時に、どこで問題が発生しているのかがわかりにくくならないか バーストトラフィックなどはいいが、遅延が発生した場合は？ 最終的にエンドユーザに届く所がどうなるか良く分からない 先ほどのトラフィック型の様にうまく分類されていくのか、それとも そのサービスの中でうまくやりくりをつける形になるのか エンド-エンドをどんなサービスタイトルで通しても、最終的に例えば フレックスギガウェイの所では低遅延なら低遅延で通る、と言う様に なるのか? -> サービスの上にサービスが載っているという点については、MPLS部 門から見ると上のサービス(例えばeVLAN)がお客様になります eVLANから何か言われれば、MPLS部門で調べたり対応したりします 仕事の回し方によってはお客さんから遠くなってしまいますが、今の 所はそういう形でやっています IPを喋っている訳ではないので、その点は救われています NTT　松井さん TEの運用について、手動でやっているということですが、TEのシミュ レータを使わない理由は何ですか? -> 自作で作ろうかという話もあって、あまり調べてないというのもあ るのですが、3つほど例を挙げた中で、すべてをうまいこと処理できる ものが見つからなかったというのが理由です これから探していって、作りこむなり、改造するなりしようと思って います TEのシミュレータがだめ、という理由があるわけではないです (コメント)私たちもTEのシミュレータを作ってますので、何かあれば よろしくお願いします 高知工科代　菊池さん パスはRSVPを使っているんですか？ -> そうです お客さんのトラフィックを逃がす場合は、お客さん単位でコントロー ルされているのですか？ -> Martiniの場合、同一対地のサーキットであれば1 LSPに重畳できる という利点があります 束ねられる時は束ねて設定しています それをさらに束ねたいという要求はあるんでしょうか？ -> あります 同一対地に伸びるサーキットが少なすぎて、なかなか束ねられないと 言う状況があります 管理の問題があったり、(実装によりますが)LSP数が増えてきた場合に 切り替えの時の断時間がだんだん上がってくるという問題があって、 少し気にしています RSVPoverRSVPみたいなラベルスタックがあるとうれしいですか？ -> やったらやったで技術的な問題が出てくる可能性がありますが、う れしいです (コメント)スライドが大変素敵だったので、資料の公開時はpdfだけで はなくてppt形式でも配布して下さい Cisco コウノさん 広域Ethernetサービスのバックボーンということで興味を持ったので すが、QoSポリシーは、広域Etherサービスに対してどの様に考えてい ますか？ -> 広域Ehterでは広域EtherでQosポリシーがある、と言う話ですか？ cosビットをちゃんと受け入れるのか、とか 単刀直入に言ってしまうと、EoMPLS側では土管を用意しているだけです 結構気になるのが、BPDUを落としたらどうなるのだろうと言う点なん ですが… -> 我々もそれが分かっているので、輻輳を起こさないように気をつけ なければいけないな、と思っています (今までほとんど起こさないでやってこれています) 広域Etherみたいな安いサービスをなのに、BPDUを落とさない様に設計 しなければいけないわけで… -> 私が考えていたのは、例えばBPDUにcos値をつけて投げてもらって、 それをMPLSルータ側でハンドリングできれば何とかなるんじゃないか、 と言う事 ただ、実装上の問題でできていません JPRS　松浦さん ISISを使っている理由はなんですか？ -> 当初別の仕事をしていたので又聞きになりますが、網の原型を作っ た時にISISを使うことが決まったそうです スケーラビリティ、configの打ちやすさ等などで比較した限りではほ ぼ互角で、ひとつだけISISが優れていた点として、使おうとしていた 機械のメーカーの開発リソースがISISに偏っている、という話を聞い て、ISISに決まったとか まとめ NTT-ComではEoMPLSを色々な所に使っています。 専用線ライクなサービスも出しました。 運用も色々大変ですが、工夫して頑張ってます。 今後も新技術が出てくると思うので、エンジニアとして期待しています。 #martini自体は単純なので基本的には問題無いが、運用部分を磨いてほしいと 思ってます 6.感想 一般には普段余り触る事のないEoMPLSという技術について、概要から最前線で の運用の苦労話までを知る事のできる貴重なセッションだった。 質疑応答でも深い話題が多く交わされ、実際にMPLSを運用されている方とのや り取りではEoMPLSをサービスとして運用した時の技術的な困難さが窺い知れた。 以上