間違いだらけのネットワーク作り(139) 2000/08/05
「IP−VPNは設計不能?/帯域制御装置の役割」

心は夏休みモードなのですが、現実の仕事は何故かピークが重なって大変です。 ただ結構やりがいのある仕事にめぐまれているので、脳も足もヨシヨシという感じでフルに活動しています。 今年の夏はまだ京都の川床に行っていないので、なんとか時間を作って夏が終わらないうちに行きたいと画策しているところです。 四条大橋近くの川床で鴨川の夜風にあたりながら、ライトアップされた南座や橋を行き交う人を見ながら食事をすると、何故か夏だなあ、いいなあ、と思えるのです。 海とか山でなく、暑い京都の真中で夏を感じるというのが変わっていますね。 

IP−VPNは設計不能?

現在設計している大規模ネットワークでトラヒック分析がおわり、さてATM専用線を使おうか、IP−VPNを試してみようか、と比較検討をし始めた瞬間、「IP−VPNなんか使っても真面目な設計なんか出来ない」ということが判明しました。 理由は簡単、エンド〜エンドの帯域保証がないから帯域設計が成り立たないのです。

Probeまで使って現状のトラヒック・フローとピーク時の使用帯域を基幹業務、web、メール等アプリケーション別に明らかにし、2年後のトラヒックを予測して「さあ、帯域設計をして回線を決めよう」というフェーズ。 ATM専用線や通常の専用線ならトラヒックの流れに応じた最適なトポロジーを決め、目標とするレスポンスやスループットを満たす帯域幅を計算すればキチンとした設計が出来ます。

しかし、IP−VPNではアクセス回線の速度をどうするか、という選択肢はあってもエンド〜エンドでの帯域幅がピーク時にどれだけ確保されるか分からないのです。 簡単なモデルとして東京、名古屋、大阪の3拠点のみのネットワークを想定しましょう。  帯域設計の結果、東京〜大阪間は基幹業務で0.5M、WEB+メールで2M、音声でO.5M、同様に東京〜名古屋間は0.25M、1M、0.25M、大阪〜名古屋間は0M、0.25M、0.25M必要になったとしましょう。 さて、IP−VPNを使うとして各拠点は何Mのアクセス回線を持てばいのでしょうか? 各拠点の必要帯域幅の合計を持てばいいのでしょうか? たとえば東京なら大阪、名古屋との必要帯域の合計は4.5M、名古屋は2M、大阪は3.5Mです。 それぞれの拠点がこの帯域幅以上のアクセス回線を使えば、東京〜大阪間では3M、東京〜名古屋間では1.5Mの帯域がピーク時において保証されるのでしょうか?

日本テレコムのSOLTERIAでも、NTTコミュニケーションのスーパーVPNでも、そんな帯域保証のことは一切言及していません。 保証などないのです。 これではネットワーク設計になりません。

両社のIP−VPNのホームページを見ると、判で押したように同じようなメリットが書いています。 いわく、MPLSを使ったフレームリレーやATM同様のセキュアなVPNを実現、自由なIPアドレスが利用可能、高速で安価・・・。 たしかに高速ですよ、アクセス部分だけは。 でも、エンド〜エンドの保証がフレームリレーのCIRやATMのPCRのように保証できなければ、ユーザの得られるレスポンスやスループットがどうなるか分からない。  パケットシェーパーなんかつけてもダメですよ。 エンド〜エンドの帯域が保証されていれば意味がありますが、保証のないIP−VPNではキャリアのバックボーンが混雑したらすべてが遅くなるのですから。

帯域保証のないIP−VPNが100%保証のあるATM専用線より安いのは当たり前ですね。  「安けりゃいいじゃないですか、いい加減で。 真面目にトラヒック分析してレスポンスの保証なんか考えるのよしましょう。 情報システム部門の人も仕事が楽ならいいんでしょ。 IP−VPNだといっておけば何も分からない上司も流行り(?)だから許してくれるし。」 まあ、いつもどおり口が悪いですが、これがIP−VPNのコンセプトですね。 

日本テレコムさん、NTTコミュニケーションズさん、IP−VPNを使った真面目な設計の仕方がありましたら、是非、ホームページに公開してください。
 

帯域制御装置の役割

先週引用したパケティアの原田さんから追加のメールを頂いたので、また紹介します。 先週の記事で私が次のコメントをしました。

*実はコンサルティングさせていただいている企業でも既にパケットシェーパーを多数使っています。 ここで問題になっているのは数10メガという高速回線が当たり前になる次期ネットワークではパケットシェーパーのWindow制御方式の帯域制御では無理ではないか、ということです。

これに対する原田さんのコメントは以下のとおりです。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
基幹回線の速度によって適用すべき技術が異なって来ることはありません。 必要とされる技術が異なってくるのは、むしろシステムの設計上あるいは運用上の問題です。
もし仮に数百Mbpsの回線速度だったとしたら、RSVPのようなシステムが最適の選択なのでしょうか? 必ずしもそうとは言えないと思います。

CiscoやLucentといった企業が描く次世代のネットワークは、数百Mbpsのネットワークをポリシーサーバを立てて、RSVPやMPLSなどを用いて制御するシステムです。 残念ながらこういったシステムはコンセプトが先行し、実際にRSVPを使用したソリューションは、米Juniper Networksなどが、やっといくつかの導入事例を示しただけで、いまだ普及期に入っていないのが現実です。

このような、いわゆる「次世代」ネットワークが末端に適用できるまでに普及するのは、まだまだ時間がかかりますし、それに対する障害も多く(コストや既存の設備の有効利用などの点で)、必ずしも最適の選択とは思えません。 また、RSVPが必要とするラベルに適応しないシステムやアプリケーションも多く、システムの改訂を待つ必要がある場合もあります。 PacketShaperのソリューションは、アプローチの仕方が異なります。 既存のネットワークにシームレスに導入できることを目指したもので、今エンドユーザが抱えている問題にフォーカスしており、RSVPのような「次世代システム」と正面から競合するものではありません。 むしろ共存できるシステムであると考えています。

PacketShaperのコンセプトは「エッジデバイス」で、ネットワークのできる限り「末端=エッジ」に設置するもので、そもそも数十Mbpsから数百Mbpsという基幹ネットワークは想定していません。 たとえ、数百Mbpsという立派なネットワークを持っている企業であっても、末端の営業所や工場などは細い回線しか持ち得ません。 しかし、実際に混雑するのはこういった細い回線だからです。 PacketShaperはこのように現在起こっている回線の混雑を解消するために設計されました。 PacketShaperがエッジデバイスとしてデザインされたのは、こういう理由によるものです。 バックボーンの帯域に問題が出るような「次世代」にRSVPやMPLSの技術が適しているのか、いないのかわからないとうのが正直なところです。 もしかしたら、弊社も網側に対応したソリューションの優先順位をあげるかのもしれません。

結論として、今後のネットワークの方向性に関わらず、PacketShaperのようなソリューションは、特にアプリケーションの個別認識能力や個々のトラフィックフローを制御できるという点で、今後とも必ず必要になる技術です。 PacketShaperは、他のシステムの妨害となることは無いので、例えば、基幹の高速ATM回線は、ルータによる制御を行い、各支店間はPacketShaperを導入して、アプリケーション別の制御を行うことも可能です。 これは基幹回線の速度に依存するものではありません。

PacketShaper製品は、現在45Mbpsまでカバーします。今後の製品ラインナップとして、100Mbps対応製品を年内に、またその後のロードマップとして、ギガビットのサポートも視野に入れて開発を行っております。 対応する速度域はハードウエア技術の進歩により変化しますが、結局のところ、LAN/WAN速度の全体的な底上げで、技術自体が陳腐化するものではないと考えています。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
*原田さんのていねいで詳しいコメントに感謝します。

基幹回線の速度によって適用すべき技術が異なって来ることはありません、ということですが説明がないので納得できません。 私は直感的にはWindow制御方式とQueuing方式を比較すると高速ネットワークへの対応力は後者が優れているのではないかと思います。 パケットシェパーのWindows制御方式はエンドシステムが送信したTCPのWindowサイズをパケットシェーパーが勝手に書き換えてスループットを制御する方式と理解しています。 書き換えとそれに対するエンドシステムの反応、という方式よりルータだけで実行できるQueuingの方がシンプルで高速化に追随しやすいのでは、と素人考えでは感じるのですが、どうなのでしょう?

*好き嫌いの話をしても仕方ないのですが、エンドシステムが設定する情報をネットワークが書き換えるというのがそもそも気に入りません。 ラベルやDLCIはもともとネットワークが書き換えながら使うものなのですが、Windowサイズはエンドシステムが相手システムに対して「これだけ送っていいよ」と意思表示する情報です。 それを書き換えるというのは変則的だと思うのです。

*QoS制御の理想形はATMのようなメカニズムではないでしょうか? エンドシステムからネットワークにQoSを明示的に要求し、ネットワークがそれを実現する。 IPの世界もATMと同様のメカニズムを目指しているのではないでしょうか? MPLSはその手始めのように思います。 まだまだ道のりは遠そうですが。 
 
 

ホームページへ