これまでのネットワークアーキテクチャの問題点

ここでは、これまでのネットワークアーキテクチャに関する技術開発の問題点を考えるために、IntServ、DiffServを例にとって考察する。

IntServの問題点

もともとインターネットにおいては、ネットワーク層プロトコルであるIPが経路到達性(reachability)を保証し、エンドホスト間のトランスポート層プロトコル (TCP) による再送制御によってはじめてパケットを失うことなく送受信できる。ネットワーク内、すなわち、IPにおいてはQoSを保証するという考え方はなく、IPはベストエフォートサービスであるといわれるゆえんでもある。一方、IntServでは、ネットワークのマルチメディア化、すなわち、従来のデータ系サービスに加えて、実時間系サービス(音声、動画像)をも提供することを企図した。実時間系サービスを提供しようとすれば、QoS保証の考え方が必要になる。ただし、ここで言うQoS保証とは、例えば、エンドホスト間に設定されたコネクションに対して、64Kbpsの帯域や50msec以内のエンド間遅延を絶対的に保証することを意味する。実時間系音声会話を従来の電話網における電話サービスと同じように実現しようとすれば、ネットワーク内においてコネクションごとに資源を確保する必要がある [1]。すなわち、エンド間コネクションが経由する経路上の各回線において一定の帯域を確保しなければならない。いったん帯域が確保されれば、エンド間遅延の保証も可能になる [3]。

すなわち、IntServアーキテクチャは、回線交換のしくみをインターネットに持ち込もうとしたものであった。しかし、いくつかの重要な問題点が指摘され、実用には至っていない。代表的な問題はスケーラビリティに関する問題である。インターネットにおいてスケーラビリティは重要な概念であり、将来的な拡張性を常に確保しておく必要がある。

  1. コネクション数に関するスケーラビリティ 各ルータでWFQなどのパケットスケジューリング方式を動作させるには、送受信IPアドレス、ポート番号の組による各コネクションの識別、および、コネクションごとのパケット処理が必要となる。
  2. ホップ数に関する問題 RSVPを用いるには、エンドホスト間の経路上のすべてのルータがRSVPシグナリングを処理できなければならない。ネットワーク規模が大きくなればなるほど、その処理オーバーヘッドは増大する。
  3. ディプロイメント(deployment)に関する問題 エンドホスト間の経路上のすべてのルータがIntServアーキテクチャを提供していないと、コネクションに対するQoS保証が実現できず、アーキテクチャ自体が破綻する。このような仮定を、運用されているネットワークに対して置くことの問題は明らかである。

また、IntServアーキテクチャを実現するためにはネットワーク資源の管理が必要になる。すなわち、各ルータにおいてアクティブなコネクションに関する情報を維持する必要がある。これは、いったんルータに故障が発生した場合の障害回復手続きが煩雑なものになることを意味する。RSVPにおいては、電話網における帯域確保の方法とは異なり、ソフトステート (soft state) による帯域確保を行っている。すなわち、定期間隔時間ごとに帯域確保の制御メッセージを流し、制御メッセージがない場合にはルータは帯域を解放することによって、システムの耐故障性の向上に注意が払われている。しかし、その場合でも、ネットワーク内にステート情報は残る。そもそもインターネットが発展してきた理由には、その分散志向、単純な構成と制御、その結果としての低コスト化指向にあり、IntServのようなアーキテクチャをインターネットに導入すること自体に矛盾がある。

DiffServの問題点

IntServアーキテクチャにおける問題点の克服を試みたのがDiffServ (Differentiated Services)である [6]。DiffServでは、IntServのようにQoSを保証するという考え方はあきらめ、QoSの差別化が意図された。例えば、パケット単位の優先権制御をルータに導入すれば、高い優先権を与えられたパケットは、低い優先権を与えられたパケットより、確実に速く転送される。DiffServアーキテクチャの標準化が急がれた背景には、インターネットの商用サービス化によるところも大きい。すなわち、インターネット接続サービス提供者 (ISP) は、ベストエフォートネットワークに対する単なる接続サービスだけでなく、そのQoSに対して他のISP業者との差別化を図る必要があった。そのため、実現困難なIntServよりも、QoSに関して不十分であってもより実現が容易なDiffServに期待が集まった。

DiffServにおいては、まず、コネクション数に関するスケーラビリティの問題に対応するため、コネクションの集合に対してクラスという概念を導入し、クラスごとにQoSが異なるような制御を施す。そのために、IPパケットのヘッダ部のTOS (Type of Service) フィールドをDSCP (Differenti-ated Services CodePoint) フィールドと読み替え、DSCPフィールドの値によって異なるQoSサービスを適用する。具体的には、ネットワークの入口に位置するルータ(エッジルータ)がDSCPの値をクラスごとに設定し、ネットワーク内部の各ルータはクラスごとに異なるサービスを施すようなパケットスケジューリングを行う。なお、TOSフィールドはIPv4でもともと規定されていたが、実際には用いられていなかったフィールドである。IPv6の場合には、トラヒッククラスフィールドを読み替える。

エッジルータがDSCPをどのように設定するかはネットワーク管理ポリシーによって決定される。すなわち、シグナリングプロトコルは不要で、ISPがあらかじめ決定しておくものである。ネットワーク内ルータはそれぞれ単独にパケットスケジューリングを動作させればよいので、コネクションごとのネットワーク資源の管理が不要になる。各ルータでは個別フローに関する情報を維持する必要はない。その代わりに、個別パケットがその処理に関する情報をDSCPフィールドによって運んでくる。それぞれのルータはその情報に従ってパケットスケジューリングを行う。これをPHB (Per Hop Behavior) と呼ぶ。その結果、エンドホスト間の経路上の少なくともひとつのルータにこの機構を導入すれば、それだけ分の品質の差別化は可能になる。

DiffServの特徴をまとめると以下のようになる。

  1. シグナリングプロトコルは不要で、各ルータはコネクションごとの情報を維持する必要はない。従って、IntServと比較してスケーラビリティを有する。
  2. ルータは、DSCPフィールドに従ってPHBを適用する。そのため、IPアドレスの識別以外にDSCPフィールドに関する処理も必要になるが、DSCPフィールドはIPヘッダ内にあるので、高速処理も可能である。

ルータにおいてPHBをいかに実現するかは標準では規定されていないが、上記サービスを実現するために各ルータに具体的なパケットスケジューリング方式を実装する必要がある。簡単な例としては、HOL (Head of Line) 優先権処理が挙げられる。バッファ内にクラス1 のパケットが蓄積されていれば、必ずそのパケットからサービスする。クラス1のパケットがない時のみクラス2のパケットをサービスするというものである。このしくみを利用すれば、クラス1とクラス2の差別化が可能になる。ただし、これはあくまでネットワーク側の論理である。クラス1に属するユーザが経験する品質がクラス2のそれより良いということが、果たしてクラス1のユーザにわかるだろうか? 高いクラスのユーザは、低いクラスのユーザより良いサービスを受けているということがわからなければ納得しないだろう。これがDiffServにおける根本的な問題である。優先権制御については、これまでも多くのネットワークにおいて提案がなされてきた。例えば、LANのアクセス制御(CSMA/CD方式、トークンリング方式)などである。しかし、それらが必ずしも成功していないことが、このような制御の限界を物語っている。 先に述べたWRR方式をクラス単位に適用すれば、クラスごとに帯域を割り当てることも可能になる。すなわち、コネクションごとの品質を保証するしくみは困難であるが、クラスに対して帯域を確保することは可能である。そのためには、DiffServにおいてどのようなポリシーに従ってネットワークを運用していくかを管理する必要がある。DiffServにおいてはエッジルータがDSCPを指定するが、例えば無制限にすべてのエッジルータがプレミアムサービスを指定すれば、DiffServの論理はただちに破綻する。破綻しないためには、エッジルータにおいて各サービスの割合をあらかじめ決定しておく必要がある。DiffServでは、ドメイン内での資源管理を行うサーバを帯域ブローカ (Bandwidth Broker) と呼んでいる。DiffServドメイン内の帯域管理は、集中的に行わなければならない。また、それゆえに、ドメインをまたがったQoS差別化を実現しようとすれば、ドメイン間の連携が必要になる。これがSLA (Service Level Agree-ment) の考え方である。しかし、これらも、本来のインターネットの考え方とは異なるものである。


なお、以上の議論は、

に詳細にまとめられている。また、ネットワークインフラストラクチャとしてのフォトニックネットワークの今後のあり方に関する議論は以下でもなされている。