間違いだらけのネットワーク作り(142) 2000/08/26
「なつかしいFRAD」

今週もあわただしく時間が過ぎ、このページに書くような面白い話題もなかったな、と思いつつパソコンに向かっています。 こういうときは日経コミュニケーションの記事をネタにするのが一番、と決めているのですが、ここのところ興味をひかれる記事がなく空しく机の上に積んでいる状態です。  気を取り直して8月7日号のケース・スタディを見るとなつかしいFRADを見つけたので、このネットワークにコメントすることにしました。 

また、前置きが長くなりますが今週の入会申し込みの中から元気があっていいなあ、と感じるT子さんのメールを紹介します。

”始めまして。 T子と申します。 私はソフトウェア開発に従事して3年のプログラマーですが、最近の便利なツールを使ってソフトは作れるようになりましたがネットワークやデータ通信、その辺りはややこしくてマニアじゃないと分からないと諦めてしまっていました。 でも顧客の質問にも答えられないようではコンピュータ業界の人間とはいえないと奮起して、勉強を始めました。

たくさんの本と格闘して理論は頭につめこみましたが、その理論と現実のものがうまく融合できずに苦しんでいたところこのホームページを見つけ、丁寧な内容に感動して早速 「企業内データ・音声統合網の構築技法」を購入し、また感動しています。”

若さと元気があふれていますね。 「感動」という言葉は中年にはなかなか使えませんが、T子さんのメールを読んだ私も感動しました。

今週設置した「ネットワーク掲示板」、IP−VPNについての質問が書き込まれ、CWCの八巻さんがL2−VPNのメリットを答えてくれました。 L3−VPNのメリットは書き込まれないのですが、L2に対して優位な点などないのでしょうか? 私は「設計不能」と悪態をつきましたが、L3−VPNを売り込んでいるキャリアの方、あるいはL3-VPNを採用したユーザの方に、何をセールスポイントに売り込んでいるのか、あるいは何故、L3−VPNを採用したのか書き込んで欲しいものです。

堂々と実名、メールアドレス付きで書き込んでくれたCWCの八巻さんに感謝します。

なつかしいFRAD

日経コミュニケーション8月7日号、116ページに富士電機総設のネットワーク・ケーススタディが載っています。 無線アクセスを使ったというのが目玉ですが、まあ、それはアクセス回線が無線になったというだけで私にはさして興味はわきません。 面白いのは117ページのネットワーク構成図です。 「なつかしいなあ」というのが感想です。 こういうネットワーク構成自体、最近では設計しなくなったのと、VoFRに使われているMARATHONというFRADがなつかしかったのです。

MARATHONは私のVoXXの先生です。 94年にMARATHONを使って初めてデータ・音声統合網を動かしました。 この時は独自のセルリレーを使っていました。 MARATHONはもともとMICOMというアメリカの会社の製品です。 ロサンゼルス郊外のシミバレーにぽつんとある工場も訪問したことがあります。 96年春にはフレームリレーとG.729に対応し、その年に100支店規模の銀行ネットワークの設計に使いました。 もちろんMARATHONは処理能力の小さいFRADですから、それだけでは銀行ネットワークは動きません。 大型のATM/フレームリレー交換機をセンターに設置し、支店にMARATHONを置く、という構成をとりました。 レガシーデータ(HDLC)、TCP/IP、電話・FAXを64Kから256Kの専用線で統合しました。  現在も安定して稼動しています。

私のデータ・音声統合網の設計ノウハウはMARATHONを使った大規模VoFR網の構築を通じて得られたものがほとんどです。 ただ、2年前からMARATHONを扱うのは止めました。 そのなつかしいMARATHONに日経コミュニケーションで会えるとは。 まだ頑張っていたんだな、という感じです。

さて、117ページのネットワーク構成図を見てみましょう。 このネットワーク構成の特徴は音声統合をしている支社や支店で基幹業務用のアクセス回線/PVCと音声・情報系用のアクセス回線/PVCを分け、本社側もトラック別に1.5Mの回線を分けていること。 スッキリした理想的なネットワーク構成とは言えませんね。 上記の銀行ネットワークのようにトラヒックの統合が出来ないのは何故でしょう?  MARATHONだけでは処理能力とQoS制御が弱いからです。

MARATHONの処理能力を検証しましょう。 64Kといった低速で音声を扱う場合、パケット長は遅延を少なくするため短くせざるを得ません。 支店のMARATHONは情報系のデータ・パケットを短くフラグメントし、音声パケットと多重化して1本の音声/情報系用PVCに送出します。 パケット長はせいぜい200バイト程度にせねばなりません。 64Kをフルに使うと上り/下りで80PPSのトラヒックが発生します。 使用率が50%としても40PPSです。 支店ではMARAHONの処理能力は問題になりません。 本社側ではどうでしょう? 

支社/支店からの音声および情報系のトラヒックは、本社側では1.5Mの回線でMARATHONに接続されています。 このMARATHONにかかるトラヒック負荷はどうなるでしょう? 1支社・支店で40PPSとして23支社・支店ですから920PPSとなります。 MARATHONには300PPS程度の処理能力しかありません。 結果的にどうなるか? 本社のMARATHONの処理能力不足のため、支社・支店の64K回線、本社の1.5M回線を使い切れなくなるのです。 ノードの処理能力不足で回線が使い切れてなくてもユーザはなかなか気づかないものです。 情報系で20支店程度の支店から同時にファイル転送を行い、どの程度スループットが出ているかというテストをすれば回線が使い切れているかどうか検証できます。

もし、MARATHONに充分な処理能力と音声、基幹系を優先制御する機能があれば、各支店の基幹系と音声/情報系のアクセス回線を分ける必要はありません。 本社の1.5M回線も3本ともMARAHONで受ければいいのです。 しかし、MARATHONには限界があるので、上記の銀行ネットワークでは大型のATM/フレームリレー交換機を併用したのです。

23支社・支店でアクセス回線とPVCを2本引いて、毎月その回線料を払うより、本社に小型で処理能力が高くQoS制御が可能なフレームリレー交換機を設置してアクセス回線を統合する方が得策だと思います。 本社に置くフレームリレー交換機はポート数がごく少ないですからコストは問題になりません。 このフレームリレー交換機に支社・支店のMARATHONおよび営業所のルータをフレームリレー網で接続すればよいのです。 もちろんアクセス回線は各サイト1本です。 支店のMARATHONは256K程度までは使えますから、ルータのトラヒックは基幹系も情報系もMARAHONから送出して何の問題もありません。 バックアップが必要なら支店ルータから本社のルータへINSのルートを用意しておけば良いでしょう。
 

今回はレトロな話題になりました。  
 

ホームページへ