間違いだらけのネットワーク作り(79) 99/06/05
「VoIPエトセトラ」
 

 先週から今週にかけて3つの企業からVoIPを拡大する、あるいはこれから導入したいのだが、という相談やら情報交換があり、さらに私自身が検討しているVoIPネットワークに関してベンダーとの打ち合わせありで、VoIP Weekという感じでした。このホームページの副題にもVoIPを加えました。

 VoIPを既に運用している企業の方はわざわざ私を訪問されました。メールで「数拠点、768Kで接続してVoIPをやっている。音質良好」という情報を頂いた方です。先週の記事でも取り上げさせて頂きました。数拠点とは3拠点でした。運用されているのは事実でも、この規模ではまだ実験段階と言わざるを得ません。ボイス・スイッチングはVoIPルータでなく、PBXで行っているとのこと。電源のON/OFFで電話のルーティング情報が消えるというバグがあり、ルータでの音声スイッチが使えない。FAXは先週の記事でまだ使えない機種があると書きましたが、これは誤りでした。様々なトラブルのエピソードが大変参考になりました。

 これからVoIPを始めようかと考えている方からはメールが来ました。にべもなく、「ベンダーのデバグに協力するんですか?」と返信。ビックリするくらい早いレスポンスで電話がかかってきました。私の印象はベンダーの話を聞いても、実運用している方の話を聞いても、ヤワラカスギルという印象です。何もあわてて苦労する必要はないし、本当にこんなにヤワクてVoIPが根付くのかというのが正直な感想です。

 先週の記事で1年以内に200拠点のVoIPネットワークを作ろうとしている企業がある、と書きました。ベンダーから聞いたことを書いたのですが、VoIPの現在の到達レベルを詳しく知れば知るほど「本当???」という感じになっています。皆さん、2〜3年後でないと出来そうにないことを今出来るかのような幻想を抱いているのではないでしょうか?私も3年ほど前、外国製VoFR製品のデバグに1年近く協力したことがありますが、今のVoIP製品の状況はその時のVoFRより悪いと思います。ベンダーのデバグに協力するなんてマッピラですし、ましてやエンドユーザにご迷惑をかけては大変です。

 VoIPはいつかは使いものになるでしょうが、「今すぐ」ではありません。ベンダーはユーザに製品を出荷してからデバグするという悪しき体質を改めて、ユーザへの宣伝に使うコストを品質向上に回して欲しいものです。あるいはデバグ協力料というのを代理店やユーザに支払ってはどうでしょう?

 ということで、VoIPの悪口をさんざん並べました。くちなおしに情報化研究会のSさん(匿名希望)から頂いたMPLSについてのコメントを紹介します。ちなみに、6月26日(土)に予定している情報化研究会「やさしいMPLS」はまだ3週間前というのに既に17人の方から申込が来ています。

以下、引用。
===============================================================================
 ここ数回の「間違いだらけのネットワーク作り」で書かれている
MPLSに関してですが、私のMPLSに対する解釈は以下のようなものです。
参考になればと思い書かせてもらいます。私自身はユーザの立場で
技術に精通しているわけではないので、間違いがあれば、ご指摘ください。

(1)MPLSはPVCの登録を自動化するプロトコル
 MPOAがSVCを使って回線を自動設定するプロトコルだとすると、
MPLSはPVCの設定を自動化したプロトコルと解釈できます。
 通常、PVCはNMS等から手動で設定しますが、これだと管理が面倒なので、
自動的に設定できないかなぁ?というのはいつも思うことです。
 これを自動的にIPアドレスに従って設定してくれるのがMPLS。
つまり、従来NMSからやっていたPVC設定を分散したノードが自動的にやって
くれる(MPLS用に標準化してプロトコルを使って)という訳です。
 ここで、レイヤ2はATMでもFRでも何でもOK。PVCなんだから当たり前です。
 MPLSの原理は、レイヤ2のヘッダ(VPI/VCI等)をラベルという名前に読み
替えて転送に使用するという、まさにATMと同じ原理です。ヘッダ内での
優先レベルの指定など若干機能が加えられてはいますけどね。ですから、
MPLSはルータの新方式という人もいますが、MPLSはルータというよりも
原理的にはATM(またはその亜流)と見なした方が正確でしょう。
 ラベルスイッチと言われているものは、PVC設定のタイミングにより、
ネットワークの構成を基に事前に適当にPVCを設定しておくトポロジー
ドリブン方式(タグスイッチ,MPLS等)、パケットが来たときに設定する
フロードリブン方式(東芝のCSR等)に分けられますが、これらの方式では
事前に流れるトラヒックを予想できないのでQOS制御はある程度適当に
せざるを得ないです。いわゆるCOSです。

(2)MPLSはISPやキャリヤ向きでMPOAがクローズドネットワーク向き
 両技術は規模や適用領域により使い分けがなされるのかな?
と思っています。
 MPOAは厳密なQOSをやろうと思えば可能で、端末数が限られている
場合には非常に有効ですが、不特定多数の端末を相手にするインターネット
のような環境では、MPLSの方が「高速化に関しては」向いているのでは、
という印象です。
 もちろん今後のQOSの必要性を考えると一番いいのは両方を同じプラット
フォームで提供できるようにしておくことでしょうね。つまりベースをATMにして、
両方に対応するというのがベストだろうと思います。実際に、現行のATM製品
にMPLS機能を付加してくるメーカさんが多そうですし。
 ちなみに、私のところでは自営回線によるクローズドネットワークですので
MPOAを使うという方向で検討をしています。

(3)MPLSとATMの関係
 一応、MPLSはレイヤ2プロトコルは何でもよいことになっていますが、
実際に実現しようと思うと、新規に設計するよりも、今ある比較的安価な技術の
モデファイで対応可能、ATMネイティブアプリや回線交換(CES)とプラットフォーム
も統合できる等の理由からATMベースのMPLSが、将来性、拡張性などを考えると
一番いいのではと思います。
 私はMPLSとATMは対立するものではなく、MPLSはATMの一形態であるし
(元々そういう経緯で考案された)、ラベルを使ったパケット交換方式全体を
包含するという意味ではその逆でもあると理解しています。
 いずれにしてもMPLSとATMは非常に近いので、わざわざMPLS専用の
パケットフォーマットを作って、IPにしか使えないという風にするよりも、
ATMベースにして何にでも使える方がいいと思いますね。
 MPLS専用の方が非常にメリットがあるならば別ですが、ATMでやっても
大差ないでしょうし、多様なアプリが収容できるなどのメリットもあります。

4)QOSについて
 今後はW-CDMA等を使った動画アプリ(試作品やPHSでも出てきましたね)の
増加や、一部、携帯電話で始まっているような高音質化などの品質の差別化
競争となってくると、QOSというのが重要なキーワードになってくるような
気がしています。
 近い将来、音声の帯域よりデータの方が圧倒的に多くなるのでQOSはあまり
考えなくてもよいという主張もよく耳にします。確かに今のままだとそうですが、
音声が64kbpsのままかどうかというのも疑問ですし、皆が普通に384kbpsとか
でTV電話するような時代が来たら状況は一変します。QOSを無視するどころか、
それが主役になるかもしれないんですからね。そしてそれはもしかした
らもうすぐ来るのかもしれません。
その時、ネットワークがそれに耐えられるアーキテクチャであるかないかは
そのキャリヤの存亡に関わってくるような問題になるでしょうね。
今後どうなっていくのかは誰にもわかりませんが、一つ言えることは、
どのようなケースにも対応できるような柔軟性のあるネットワークを作って
おくことが重要だという事だと思います。
 

ホームページへ