(１)　IntServ over DiffServ

　アクセスネットワークはIntServ，バックボーンネットワークはDiffServをサポートする形態である(4)．IntServからはDiffServクラウドはIntServアクセスネットワークをつなぐ仮想リンクにみえる（図2）．DiffServはバックボーンネットワークのリソースをアクセスネットワークに分配する．IntServはそのリソースを細分し，リソース予約要求に応じて個々のフローに分配する．送信ホストが受信ホストとRSVP PATHメッセージ，RESVメッセージを交換するとき，これらはDiffServバックボーンネットワークでは無視される．アクセスルータではポリシーサーバの指示によりアドミッションコントロールを行い，仮想リンクにおけるリソース予約が可能な場合にはRESVメッセージを通過させる．

　DiffServバックボーンネットワークは一般に複数のDiffServ管理ドメインから構成され，ドメイン間を通過する集合フローに対して，SLAに基づいて，ドメイン間のリソース割当が行われる．ドメイン間集合フローのトラヒック特性が変化する場合には動的なSLA交渉とリソース割当が望ましく，帯域ブローカの適用が考えられるが，個々のデータフローに対応するものではない(5)．ドメイン間のリソース割当が集合フローのトラヒック特性を的確に反映していない場合には，アクセスネットワークにおける個々のフローに対するアドミッションコントロールと不整合が大きくなる可能性がある．

　(２)　IntServ/RSVPの軽量化

　IntServ/RSVPでは，フローが通過する送信・受信ホスト間のすべてのルータにおいて，個々のフローの状態を保持することが， スケーラビリティ問題の根源にある．そこで，サブネット間のリソース予約を集約したり，ルータが管理する状態を集約することにより，スケーラビリティを向上させることが考えられる(6),(7)．これにより多くのフローが同一のサービスクラスを共有するため，個々のフローのリソース予約における分離性が完全ではなくなることが欠点である．

　IntServ/RSVPのアドミッションコントロールにはパラメータベースと測定ベースがある．パラメータに基づくアドミッションコントロール方式では，個々のフローのトラヒック特性を記述するため幾つかのパラメータが用いられる．各ルータで個々のフローのパラメータを保持する必要がある．これをもとに，トータルの所要レートを計算し，リンク容量に比較することにより，アドミッションコントロールを行う．この方式は保証サービス，確率サービスの実現をターゲットとする立場のものである．これに対して，測定に基づくアドミッションコントロール方式では，各リンクの実際の負荷を測定により求める(3),(8),(9)．この方式は予期サービスをターゲットとする立場からリンクの使用効率の向上を目的として提案されたものであり，各ルータで集合フローを測定するので，個々のフローのパラメータを管理する必要はない．

　一方，確率サービスを実現する立場から，測定には依存せず，しかもルータでフローごとの状態保持を不要とするアプローチも提案されている(10)．この方式では，Dynamic Packet State (DPS)がキー技術である．各ルータで各出リンクの集合フローの予約レート（集計予約レート）を保持し，ローカルなアドミッションコントロール判断を行う．一般に，ルータでフローごとの状態を持たず，集計予約レートのみを保持し，新フローの追加，フローの終了時にそれらのレートを加算，減算することにより，集計予約レートを更新する方式はロバストではない(10)．DPSでは，入り口ルータがパケットヘッダに情報を付加する．すなわち，フロー i の k 番目のパケットに，k−1番目のパケットの送出時刻から k 番目のパケットの送出時刻までの経過時間とフロー i のレートの積を入れる．これにより，各ルータでは集計予約レートを計算できる．これにより，ロバスト性を向上させている．

　このように， これらの方式では，ルータにおいてフローごとの状態を保持する必要がなく，スケーラビリティの向上が図られている．しかし，フローごとのシグナリング，ルータでの測定処理，アドミッションコントロール等が必要であることは変らず，このアプローチによるスケーラビリティ向上には限界がある．