間違いだらけのネットワーク作り(74) 99/05/01
「’Cisco Waveの感想’への感想」
 
 
 先週の「Cisco Wave」の感想という記事に3人の方から感想が寄せられました。その中でCisco社の方から頂いたものが大変参考になるので以下に引用させて頂きます。個人の感想・意見として寄せられたもので会社としての見解ではないと私は理解しています。

 文中、ATM網において1本のVCにQoS要求の異なる複数のAPを乗せてはATMのQoS制御が使えない、というのはこのページでも取り上げたことがあるテーマです。同一LAN上にある複数のAPがATM−WANに出ていく時、適切なQoSをどう与えるか。しかもAPはATMのことなど意識しなくてよい、という条件で。
 
 私はAP個々にQOSを与える=VCを変える、といった厳密性はあまり意味が無く、通常は音声、リアルタイム・データ、ノンリアルタイム・データ、CBR(サーキットエミュレーション)の4クラス程度にAPを分類し、それぞれに対応したVCにAPのトラヒックを振り分けてやればよいと考えています。音声、CBRは当然ルータを通したりはしません。なお、私の本業はメガリンクやDA/DR等の専用線を使った自営ATM/FR網なのでVCをどう設定しようが回線料は気にする必要がありません。今はこんな方針で設計していますが、ATMとIPの上手な組み合わせ方はまだまだ研究課題です。

以下、引用。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−ー
 松田様のページはたびたび拝見させて戴いております。示唆に富んだ
ご意見に「両手を上げて賛成するかどうかは別として」;-)、感心して
おりました。

 文中、「WANに入ったらATM/FRに任せてしまえば簡単なのに」という
ご意見に対し、少し補足したいという衝動にかられ、メールを書いてお
ります。

 Tag/MPLSでは確かに、エンド〜エンドの経路制御およびQOS保証という
点で、ATM/FRと同じようなことができます。でも、できるということと、
本当にそれをさせるか、ということは別問題で、本当にそれらが目的なら、
現在のATM/FRを利用した方が、コスト的にも、技術的にも、運用的にも、
ずっとリーズナブルであるような気がします。従って、現在と全く同等の
エンド〜エンドのQOS保証を求めるお客様に対しては、現在のATM/FR技術を
お奨めした方が良いと思います。

 MPLSによるバックボーンが狙うのは、少し違う顧客層ではないかと思う
のです。例えば、IPルータでマルチサービス(Voice,Video,Data,etc.)を
統合している、または統合することを計画している企業の、専用線コスト
削減のための仮想専用網への置き換え。このような顧客層は、ATMやFR技術
にあまり詳しくなかったりします。(ATM/FR上でダイナミックルーティン
グを実現するためには、NBMA等の設計上の考慮が必要です。また各VCがルー
ティングピアになるため、ルーティングテーブルが大きくなりがちで、大規
模ネットワークとなると、スケーラビリティの問題が出てきます。)また、
企業によっては、「各サイトに大体何Kbps/Mbps位の回線が必要」程度のト
ラフィック要件は把握しているが、各エンド〜エンドでのトラフィック量の
マトリックスなどきちんと押さえていない、なんてことも多々あります。

 ATMやFRのモデルでは、エンド〜エンドのCIR/MCR(SCR)で契約するため、
当然各拠点間のトラフィックマトリックスを押さえる必要があるとともに、
ATM/FRによるQOS保証をフルに活かす為には、各トラフィック特性(バース
トはしないが遅延センシティヴな音声、多少の遅延は許されるがバースティ
なデータ、廃棄にセンシティヴなSNA、等)毎にVCを分ける必要があります。

 ここで以下の仮定をします。

 仮定条件1)トラフィック特性毎にVCを分ける場合

  ・各サイト間x各トラフィック毎(Voice, BurstyData, LegacyData,
   etc.)にトラフィック終点始点のマトリックステーブルを作成、管理
   する必要がある。

     → 辣腕のネットワーク管理者でもいない限り、こんなテーブルを
      作成、管理するのは困難なのでは。特にサーバーが複数サイトに
      分散しているようなシステムの場合はいちいち管理しきれないと
      いう可能性が高い。

     → キャリア網は、通常VC単位で課金されるため、確かにVCを分け
      るのが理想であっても、なかなかそうは行かない。

 仮定条件2)トラフィック特性毎にVCを分けない場合

  ・1本のVCに、音声もバースティデータも、ミッションクリティカルデー
   タも混成させることになる。

     → せっかくのATM/FRのきめ細かいQOS制御もVC毎の制御であるため、
      1本のVCに多種のトラフィック特性が混在した場合は、効果が無く
      なる。例えば、松田様も、公衆キャリア網におけるVoFRは使えない、と書
      いていらっしゃるが、原因の一つはデータ用に最適化した(Foresight有+
      Ingress Buffer大)VCに、音声を 混在させているためと考えられる。(CPE
      側の優先制御機能が良くないのも原因の一つであろうが)。
   
*松田注:公衆キャリア網を固有名詞で名指しされていましたが削除しました。ご指摘のキャリアに
限らず、公衆FRにおいては音質劣化の要因が多く安定した良い音質は得られないというのが私の
意見です。ただ、「使えない」とまでは思っていません。現に一生懸命公衆FR上のVoFRを売っている
ベンダーやキャリアがいますし、それを受け入れているユーザがいます。
   
 従って、どちらの仮定条件をとってみても、問題となる訳です。このような
場合、確かにエンド〜エンドパスとしてのQOS保証はFR/ATMに比較して厳密では
ないけれども、IP QOS(Diffserve/Precedence Bits)をハンドリングできる
(音声、バースティデータ等異なるトラフィック特性を、バックボーンも連携
してハンドリングできる)、かつ、運用者が把握・管理するトラフィック量は、
ルータからその1ホップ先の接続先まででよい、というサービスは、一つの魅
力的なオプションなのではないでしょうか。また、肝心のQOSの面から捉えても、
1つのVCに何でもかんでも詰めこんで、結果ATM/FRのQOS機能をフルに活かせ
ないのなら、IP COSのバックボーンQOS制御へのマッピングによって、バック
ボーン機器がCOSをハンドルする方が、「まし」な場合が多いのではないでしょ
うか。勿論、MPLSでは、従来のATM/FRと共通バックボーンとすることもできる
のも、一つのメリットです。

 長くなってしまって申し訳ありませんでした。拙い文章で、意図が伝わるか
どうかはわかりませんが、今後もご意見を伺わせていただけることを楽しみに
しております。「技術というのは用途に応じて使い分けるもので、そんな単純
に割り切れるものではない。」というご意見には、全く賛成です。その時その
時の前提条件や用途が変わる以上、 「これが正しい技術」なんてものは無いと
思います。シスコがEverything over IPなどという場合も、「ある条件」の元
で言っている訳ですので、誤解の無い様にして戴ければ幸いです。

 
 

 
 

ホームページへ