間違いだらけのネットワーク作り(167) 2001/02/24
「VoIPによる大規模ネットワークの構築技法・要旨B」

今週は春めいた好天の日が続き、快適でした。  今週、一番面白かったのは関西で進んでいるプロジェクトのネットワーク設計レビュー。 テレビ会議を使って大阪のメンバーとレビューをしたのですが、なんとPolicyのないこと。 けちょんけちょんに問題点を指摘しておわりました。 困ったものです。 目的も設計目標値(レスポンス等)も明確にせず、平気でいられる人が多いのにあきれます。 この記事を読んでいる、あなたもそうかもしれませんが。 俺は違う、という方、それが当たり前です。 自慢するにおよびません。

日経BP社からNET&COM21講演の成績表(?)が届きました。
−−−−−−−−−−−−−−−−−−−−−−−−−−−
 ・フォーラムの中での入場者ランキングについて
 受講者数は、全36講座中第2位

  受講者満足度は、全36講座中第1位(スコアー:4.47)
 (スコア-とは・・・
  大変良かった  5点 良かった    4点
  どちらでもない 3点 あまり良くない 2点
  良くない    1点
  として、受講者アンケートを集計し、数値化したものになります。)
−−−−−−−−−−−−−−−−−−−−−−−−−−−
ネットワーク話術者を標榜する私としては大満足の結果です。 2時間45分も聞いていただいて、退屈させたかと心配していましたがスコア−を見ると大部分の方が「大変良かった」、「良かった」という評価をしてくれたようです。(ちなみに時間は2時間30分の予定だったのですが、私の話が横に脱線することが多いので皆さんに了解を得て延長していただきました。) これも、このホームページを見ている方が多数参加してくれたおかげだと思います。 ありがとうございました。 来年も講演するチャンスがありましたら、入場者数、受講者満足度ともに1位という「完全優勝」(?)を目指したいと思いますので、よろしくお願いします。

VoIPによる大規模ネットワークの構築技法・要旨B

今週はSUPERな設計の種あかしをして、この「要旨シリーズ」を終わります。 講演のスライドは77枚あり大部分は技術的な内容なのですが、この要旨ではあえて技術の中身はふれず、それ以前の「設計の考え方」に絞ってまとめました。 その方が、ミクロな技術の話より価値があると思うからです。

SUPERとは

S : Switchable  ネットの構成要素(機器、回線)を簡単にリプレ−スできる。
U : Upgradable  トラヒックの増大、機能追加に容易に対応できる。
P : Policy based  設計ポリシーが明確である。
E : Economical  イニシャルコスト、ランニングコストの妥当性
R : Reliable     信頼性、品質が高い。

Pは先週説明しました。 E、Rは説明するまでもないですね。 大事なのはS、Uです。 ネットワーク技術、製品、回線サービスはすごい速さで高機能化・低価格化が進んでいます。 いいものを何時でも取り入れ易くするにはネットの構成要素を簡単にSwitchできることが重要です。 VoIPをするなら、下図のように機能階層ごとに最適な製品やサービスを選択すべきです。 そうすれば各階層ごとにいつでも、Switchが可能になります。 OSIの考え方の基本ですね。 OSIは死にましたが、考え方は生きています。


Upgradableであるためにも階層化は重要ですね。 また、いつでもSwitchできるからといってネットワーク機器が1年で使えなくなったのでは困りますから、トラヒック増や機能追加にある程度対応できる拡張性も必要です。

VoIPの実例でいえば、米国のLevel3、日本のフュージョンコミュニケーションズ、ともにGWはSONUS社製を使っていますし、ルータはブランドで選択したりせず、処理能力の高いキャリア向けの装置を選択しています。 それぞれの階層でベストのものを選択し、より良い製品が現れたら、その階層だけリプレースする。 当然といえば当然ですが、あらかじめSUPERなポリシーを持ってないと、何もかも機能を一つのルータに詰め込んだり、1社の製品に漬かってしまって抜けられない、ということになります。

そいういう意味で、日経コミュニケーション、2月19日号の記事「サーベイ&チョイスVoIPゲートウェイ」はルータ組み込み型より、独立型のGWを数多く取り上げているのが好ましいですね。 たまたま独立型の製品が多いだけで、Switchableであるべき、などというポリシーがあるわけではないでしょうが。 それにしても、よくあれだけの製品を調べて比較表にしたものだと感心します。 90点。 ついでに評価して順位もついていれば100点なのですが。

掲示板の書き込みでは「VoIPにおける課金」が盛り上がっていました。 これはネットワーク管理というレイヤの話ですね。
現時点の最適の解は
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
 投稿者:YAMA  01/02/20 Tue 19:37:29
課金についての私の回答です。
弊社のトール網課金は、中継線を経由した通話のみ中継交換機で課金するという仕様です。しかし、交換機での課金装置はウン百もすると思います。
ルータ〜ルータ通話が収束してしまうVoIPの場合、必ずしも中継交換機を経由しませんので既存のトール網に依存しないVoIP課金を検討する必要がありました。
CiscoのVoiceManagerもテストを行いましたが、完璧にLogは取れませんでした。また、Cisco製品の機種にも依存してくる可能性が発生します。
結局は、不良NNIさんのおっしゃっている内容でRADIUSを2重化し、Logを自作プログラムで集計しています。この場合、全く通話Logの取りこぼしは発生
しませんし、機種やIOSのVersionに依存する可能性もないと思います。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
だと思います。 Switchableですし、サーバの能力を上げればUpgradableですね。 YAMAさんの書き込みを毎回読んで思うのは、プロだなあ、ということです。 プロというのは意識しなくても、SUPERな設計をしているのですね。 

以上で、「VoIPによる大規模ネットワークの構築技法・要旨」のシリーズは終わります。
 
 
 

ホームページへ