間違いだらけのネットワーク作り(159) 2000/12/23
「ホストと音声の統合」

22日(金)は日帰りで大阪出張。 往復の新幹線で、「VoIPによる大規模ネットワークの構築技法」という講演のレジュメを作りました。 今年のNET&COMに続いて、来年2月7〜9日幕張で開かれるNET&COM21のForumで講演することになったのです。 前回は「VoFR、VoIP、VToAでここまでできる」というテーマでしたが、今回はVoIPに絞りました。

レジュメの粗い流れは次のとおりです。
1.企業ネットワークの動向
2.企業ネットワーク設計の考え方
2.1トラヒック特性の劇的変化
2.2ポリシー・ベース・デザイン
2.3VoIPの企業ネットワークにおける位置付け
*VoIPの目的
*VoIPの近未来像−日米のキャリア、企業の動向
3.Voice over Packetsの基本
4.大規模VoIP設計のポイント
4.1設計のポイント
*音質劣化対策
*スケーラビリティ
4.2ケースの設定
4.3VoIP over ATM/FR−−sureなVoIP
4.4VoIP over L2VPN(CWC広域LANサ−ビス)−−ルータレス・ネットワークのすすめ
4.5VoIP over L3VPN(NTTコミュニケーションズArcstar)−−L3VPNの実力は?

どうでしょう?  細かい中身はこれからですが、言いたいことは決まっています。 中身を細かくするのは楽しい冬休みの宿題です。

「VoIPによる大規模ネットワークの構築技法」(セミナーID D6)
NET&COM21 Forum  2001年2月9日(金)  14:00〜16:30
幕張プリンスホテル プリンスホール2F

NET&COM21ホームページ(Forum事前申し込み可能)

前回のForumは約160名の方が参加し、情報化研究会の方や、会員ではないがこのページの読者がかなりいらっしゃいました。 (手をあげてもらったから分かるのです)
来年も多数の方の参加を期待します。

さて、今週は「IP−VPNの実像に迫る」は一休みして、掲示板に書き込まれたFR網でのホストと音声の統合についてコメントしたいと思います。

ホストと音声の統合

掲示板の内容は次のとおりです。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
FR網とホストと音声の統合  No: 224 [返信][削除]

 投稿者:ネットに悩む  00/12/21 Thu 14:45:16
音声統合の構築技法を見て救いを求めている者です。
私は、某企業のシステム部門にいるのですが、自社のホスト・イントラネットに
使用しているネットワークへ音声統合を進める役を請け負うことになりました。
そこで、2社(1社は某大手通信会社 1社は現行ホストメーカーと大手通信会社
の連合)に提案を依頼したのですが、私の知識不足もありどちらかに決め兼ねている次第です。
自社のネットワーク構成と疑問点は以下のようなのですが、ポイントだけでも指摘いただけないでしょうか?
構成:
   DA1500が7拠点(うち1拠点にホストあり)
   DA64が60拠点(エリア毎にPVCは近くのDA1500拠点へ設定
   末端の拠点は、DA1500拠点を1〜2箇所ホップしてホストやイントラ
   サーバーへ接続(ホストデータはIPカプセリングしています)
   WANはFR網です。
   DA64拠点のCIRは16Kbps DA1500拠点のCIRはホスト拠点
   が256Kbps その他DA1500拠点はしR64Kbps
   データ計測では、拠点によりますがDA帯域の10〜30%の使用率です。
統合案
   A案:IPゲートウエイでIP化した音声を現行ルータを介してWANへ
      出す。ルータでポートでの優先制御(PVCはデータ・音声同じ)
      DA64拠点はほぼ1CH(4個所は3CH) DA1500拠点は
      12CHと4CHに分かれます。CIRはDA1500の拠点は全て
      半分にします。*512Kということですか?
   B案:DA1500拠点のみFRADによるVOFRで現行データと音声を
      同一PVCでWANへ出します。CIRは、音声分を現行分に加算で
      す。
疑問点:
   ・ホストもある環境でCIRをどうするか
   ・DA64でも1CHなら大丈夫なのか
   ・近い将来にFRからIP−VPNへ移行するなら音声統合はしないほうが
    よいか(とりあえず1.5M拠点のみIPで音声統合するか)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

提案している2社とはどこだろう? と推測するのも楽しいですね。 A案は某大手通信会社、B案は現行ホストメーカーと大手通信会社の連合の提案。 現行ホストメーカーは富士通でFRADはモトローラのOEM、といったところでしょうか? つまらん提案ですね、B案は。 中途半端。 内容を細かく云々する以前に私だったら切って捨てます。 現行ホストメーカーは「当社の案を採用しないとホストのオンラインは保証できない」なんて脅していませんか? そんなこけおどしに惑わされないでくださいね。

私のような中立的なSIの方が客観的な提案が出来るのでお勧めです。 もし、提案を依頼されるならお受けします。 ビジネス・モードになりますので、その時はmatsudats@nttdata.co.jpまでメールください。 このホームページ上に書いていることは個人的意見ですので、念のため。

ホストのデータもIPカプセリングされていて、レガシー・データがないのはやりやすいですね。 ただ、FNAを単純にIPカプセリングしているだけだとタイムアウトを気にする必要があるので、カプセリングよりも完全なTCP/IPへの移行が将来的には必要でしょう。 

文面から想像すると社内へのパソコンの普及やそれを使ったWeb、メール等の利用は少ないですね。  社員一人一台レベルにPCが普及し、Web、メールが使われると回線帯域の10〜20%では済みません。

疑問点に対する直接的な回答にはなりませんが、以下のような点を検討する必要があると思います。  

@データ・音声統合のメリットはあるのか?
データ・音声統合の目的は経済効果だけです。 客観的に経済効果を確認しましたか? 

AVoIPを使うか、VoFRを使うか?
FRを使うメリットはレガシーを扱いやすいこと、VoFRはヘッダが短くオーバーヘッドが少ないことから低速回線に適していることです。 B案ではどちらも当てはまりませんね。
レガシーはないし、低速回線もない。 デメリットはFRADという装置が必要になること。 それがIP−VPNでは無駄になること。

さらにB案の欠点は高速拠点間の通信なのにデータと音声のPVCを同一にしていること。 なめてますね。 今後、Webやメールの利用が増えるとIPトラヒックは急増します。 IPトラヒックの集中する拠点でFRADがそれを受け止めるなんて、NGです。 処理能力が乏しいですから。 規模が大きく、IPトラヒックが多い場合はデータのPVCと音声のPVCは分離し、IP集中拠点では処理能力の高いルータを使うべきです。 IPのPVCはルータに、音声のPVCはFRADで受け止めるのです。 「企業内データ・音声統合網の構築技法」にも書いてあります。

VoIPのいいところはデータ、音声ともレイヤ3で扱え構成が単純なこと。 将来IP−VPNへ移行しても機器の無駄が生じないこと。(IP−VPNがFR網に比べて現時点で優れているとは言えませんが。) 難しいのは音質の確保。

掲示板の情報だけで確たる評価はできませんが、スジはA案の方がいいと思います。

BDA1500拠点のみ音声統合するのか、64K拠点まで含めるのか?
これも経済効果で判断すべきことですが、内線電話というのは社内どこでもかけられることが価値なのでやるなら全拠点対象としたいですね。 それで経済効果がでないならデータ・音声統合などしなければいい。 B案が1500拠点だけ対象にしているのは経済効果の問題でなく、技術的に64K拠点を統合する自信がないからではないでしょうか?

C現行ルータは使えるのか?
A案の方がスジがいいと言っても現行ルータが使い物になるものかどうかが問題です。 ポート番号での優先制御は可能なようですが、64K拠点を収容する1500拠点のルータは処理能力も充分で、次のDのような問題も処理できるのでしょうか?

D低速アクセスでの問題をどう処理するか?
64Kアクセス回線を使っている拠点ではVoIPを適用するにはパケット・ロスの対策、遅延の対策、RTPパケットのオーバヘッド対策が必要です。 パケット・ロス対策とは64K拠点向けの音声パケットが、64K回線への出口バッファがオーバー・フローして捨てられないようにすることです。 高速側から64K拠点向けの送出レートが64K未満になるように、高速側のルータで帯域制御するのが一つの対策です。

遅延対策としてはデータと音声が競合して音声パケットの送出が遅れないように、長いデータ・パケットを分割(フラグメント)し、かつ音声パケットを優先する必要があります。 現行ルータは優先制御はできるようですが、フラグメントはどうでしょう? 

RTPオーバーヘッドは音声パケットの3つのヘッダIP、UDP、RTPの合計40バイトが帯域を無駄遣いしないよう、ヘッダ圧縮する機能です。 ヘッダ圧縮なしに64Kで3チャネルは無理です。 ですが、A案では現行ルータでヘッダ圧縮なんてできませんね。  何故ならIPゲートウェイは文面からルータと独立した装置と思えるからです。 GWがルータと独立していてはRTPヘッダの圧縮はできません。 64Kで3チャネルの拠点が4ヵ所あるとのことですが、そんなことが何故可能なのでしょう?

ということで、Aをとっても、Bをとってもロクなことはなさそうです。 C案が必要です。
 
 
 

ホームページへ