JP2004529550A - データネットワークにおけるプールに基づいた資源管理 - Google Patents

Abstract

ある実施例において、この発明のネットワークシステムは、少なくとも、第一ルータ(１５６）と、上流リンクを介して第一ルータ(１５６）から第二ルータ(１５８)へのデータフローを許可するために上流リンクに接続された第二ルータ(１５８)とを含む。第二ルータ(１５８)は制御面（１５８ａ）と、上流リンクに接続された入力ポートおよび下流リンクに接続可能な出力ポートを有するデータ面（１５８ｂ）とを含み。制御面（１５８ａ）は第一ルータ(１５６）の資源能力に対応する能力を有する仮想プール（２５０）および許可制御機能（１８２）を含む。入力ポートから出力ポートへのデータ面（１５８ｂ）を介したフローのための資源の予約をするための要求に応答して、許可制御機能（１８２）は、仮想プール（２５０）内で資源の利用可能性を参照することによって上流リンクに対する許可制御を実行する。ある実施例において、要求は統合されたサービスフローに対する資源を予約する要求であって、仮想プール（２５０）の能力は第一ルータ(１５６）によってサポートされた統合されたサービスのサービスクラスの資源能力に対応する。

Description

【０００１】
[０１］ この発明は通信ネットワークに関し、特に、ネットワーク内の選択されたトラフィックフローに対して向上されたサービスの質（ＱｏＳ）を提供する通信ネットワークに関する。
【０００２】
[０２］ ネットワークサービスプロバイダに対して、ネットワーク設計および管理における最も重要な考慮はネットワークサービス顧客から生じるトラフィックとサービスプロバイダのネットワークの外部（例えばインターネットから）から生じるトラフィック（例えばインターネットから）との間のアクセス能力およびネットワーク資源を適切に割り当てることである。この考慮はあるフローに対して特別なサービスの質（ＱｏＳ）を保証または最低の通信帯域を提供することをネットワークサービスプロバイダに要求するサービスレベルアグリーメント（ＳＬＡ）を含む予約を行ったネットワーク顧客のトラフィックに関して特に重要である。そのようなサービスの提供は、十分なアクセス能力およびネットワーク資源が顧客に利用可能であるということを確実にするために、特定されたＱｏＳを達成し、許可制御の強化されたネットワークアーキテクチャおよびプロトコルを実行することをネットワークサービスプロバイダに要求する。
【０００３】
[０３］ インターネットプロトコル（ＩＰ）ネットワークにおいては、ＱｏＳを達成し、音声または非同期転送モード（ＡＴＭ）のような、コネクション型のネットワークサービスの許可制御に匹敵する許可制御を実行するためのまっすぐなアプローチは、ＱｏＳを要求するＩＰパケット対して、同じホップごとの（hop-by-hop)資源予約信号送信の切り換えの実例をエミュレートすることである。実際、統合されたサービス（Intserv、イントサーブ）のためのインターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって開発されたＩＰ信号送信標準はこのアプローチを正確に採用している。ＩＥＴＦ ＲＦＣ１６３３に述べられているように[R. Branden et al., "Integrated Services in the Internet Architecture: an Overview" June 1994]、イントサーブは、アプリケーションが、自分のデータパケットに対して配送サービスの多数の制御されたレベルの中から選択できるようなフローごとのＩＰ ＱｏＳアーキテクチャである。この能力をサポートするために、イントサーブは、パケットフローの送信器で、アプリケーションがパケットフローの受信器に対する経路に沿ったすべてのネットワーク要素から、向上されたＱｏＳクラスを受信するフローを開始するために規定されたことを許容するために、ＩＥＴＦ ＲＦＣ２２０５[R. Branden et al., "Resource ReSerVation Protocol (RSVP)-Version 1 Functional Specification" Sept. 1997]によって規定された。
【０００４】
[０４］ ＲＳＶＰは単純なフロー（例えばＲＳＶＰは単一方向のフローに対する資源を要求する）に対する単純な資源を要求するために使用されるネットワーク装置の制御面におけるＱｏＳ信号送信プロトコルである。ＲＳＶＰはルーティング機能は有さないが、ルーティングに応じて転送されるパケットのためのＱｏＳを確実にするためのユニキャストまたはマルチキャストのルーティングプロトコルを動作するために代わりに設計されている。（すなわち、ＲＳＶＰはＱｏＳのためのポリシ(policy)および許可制御が適応される下流インターフェイスを決定するために転送テーブルを調べる（ルーティングが存在する(populated)）。
【０００５】
[０５］ 図１はＲＦＣ２２０５に応じてＱｏＳを達成するためのＲＳＶＰを使用したイントサーブ(Intserv)ノードの処理モデルのブロック図である。例示されているように、送信ホスト１００はアプリケーション１０４を実行し、アプリケーション１０４は一般的にインターネットトラフィックに与えられる”ベストエフォート”型のＱｏＳよりも高いＱｏＳを要求するデータ（例えばビデオ配信またはＩＰを介した音声（ＶｏＩＰ））を送信する。送信ホスト１００と受信ホスト１１８との間にはルーティングプロセス１１６を実行するルータ１０２のような一以上の付加的なノードに接続されている。
【０００６】
[０６］ 制御面において、各ネットワークノードはＲＳＶＰメッセージのノード間の通信をサポートするＲＳＶＰ処理１０６と、向上されたＱｏＳフローのための資源予約を行うための管理許可をユーザが有しているかどうかを判定するポリシ制御ブロック１０８と要求されたＱｏＳを提供するための十分な発信帯域幅を有しているかどうかを判定する許可制御ブロック１１０とを含む。データ面においては、各ノードは、フローのパケットを特定し各パケットのためのＱｏＳクラスを判定するパケット分類器１１２と、パケット分類器１１２によって実行されるパケット分類に応じて各フローに要求されるＱｏＳを実際に実行するパケットスケジューラとを含む。
【０００７】
[０７］ ＲＳＶＰセッションを開始するために、アプリケーション１０４はＰＡＴＨメッセージを送信する。ＰＡＴＨメッセージは、送信ホスト１００と受信ホスト１１８との間の各ノードでＲＳＶＰ処理１０６に連続的に渡される。送信ホスト１００はＲＳＶＰセッションを開始するが、受信器ホスト１１８は、受信ホスト１１８と送信ホスト１００との間の逆経路に沿って、各ネットワークノードにＱｏＳ要求を含むＲＥＳＶメッセージを送信することによって、セッションのための特定されたＱｏＳを要求する責任を有する。ＲＥＳＶメッセージの受信に応答して、各ＲＳＶＰプロセッサ１０６はそのローカルポリシ制御モジュール１０８および許可制御ブロック１１０に予約要求を渡す。上で述べたように、ポリシ制御ブロック１０８は、ユーザが予約をするための管理許可を有しているかどうかを判定し、許可制御ブロック１１０はノードが要求されたＱｏＳを供給するための十分に利用可能な資源（すなわち下流リンク帯域幅）を有しているかどうかを判定する。両方のチェックが送信ホスト１００と受信ホスト１１８との間のすべてのノードで成功すると、各ＲＳＶＰ処理１０６は所望のＱｏＳを得るために、ローカルパケット分類器１１２とパケットスケジューラ１１４におけるパラメータを設定し、ＲＳＶＰ処理１０６は送信ホスト１００で要求されたＱｏＳが許可されたことをアプリケーション１０４に知らせる。他方、もし経路内の任意のノードにおいていずれかのチェックが失敗すると、送信ホスト１００のＲＳＶＰ処理１０６はアプリケーション１０４にエラー通知を戻す。
【０００８】
[０８］ 概念的には大変単純ではあるが、イントサーブＱｏＳの提供は、各ネットワークノードで要求されるコンピュータ的に集中されたＲＳＶＰ処理のために、拡張性が限定される。特に、ＲＳＶＰはフローごとのＲＳＶＰ信号送信、フローごとの分類、フローごとの取り締まり(policy)／シェイピング(shaping)、フローごとの資源管理およびフローごとのソフト状態情報の周期的なリフレッシュを要求する。その結果、イントサーブＲＳＶＰ信号送信によって要求される処理は電話またはＡＴＭ信号送信の処理に匹敵し、そのような信号によって要求される大規模な処理を扱うために各ＩＰルータ内で高性能の（例えば高価な）プロセッサを要求する。
【０００９】
[０９］ 従来のイントサーブＲＳＶＰ信号送信を使用したＩＰ ＱｏＳを実行することに関連した拡張性および他の問題の認識において、ＩＥＴＦはＲＳＣ２４７５において規定された差別化されたサービス（Differentiated Service,ディフサーブまたはＤＳ）プロトコルを普及させた。ディフサーブは各ＩＰ層のパケットヘッダのＤＳフィールド（例えば、ＩＰｖ４のサービスタイプ（ＴＯＳ）バイトまたはＩＰｖ６トラフィックのクラスバイト）内の集合トラフィック分類を搬送することによって拡張性を達成するＩＰ ＱｏＳアーキテクチャである。ＤＳフィールドの最初の６ビットは、ディフサーブドメイン内のその経路に沿った各ノードでパケットのための特定のサービスのクラスまたはホップ単位動作（Per-Hop Behavior,ＰＨＢ）を要求するディフサーブコードポイント（Diffserv Code Point,ＤＳＣＰ）を符号化する。
【００１０】
[１０］ ディフサーブドメインにおいては、ネットワーク資源は、ディフサーブドメイン内においてディフサーブドメインへの入場およびディフサーブドメイン内のトラフィック転送時のＤＳＣＰマーキングおよびトラフィック条件を管理するサービス条件ポリシに応じてパケットフローに割り当てられる。マーキングおよび条件操作はディフサーブネットワーク境界においてのみ実行されねばならない。このように、特定されたＱｏＳを有するフローを確立するために送信器と受信器間で端末間の信号送信を要求するよりも、ディフサーブは各ＩＰパケットのヘッダを検査および／またはマーク付けることによってだけで集合したフローに対して入り口境界ルータがＱｏＳを提供することを可能にする。
【００１１】
[１１］ ＲＳＣ２９９８[Y. Bernet et al., "A Framework for Intergrated Services Operation over Diffserv Networks" Nov. 2000]に述べられ、また図２に例示されているように、統合されたサービス（Integrated Service)は差別化されたサービス(Differentiated Service)ドメインにおいて実施される。図２に例示されたネットワークモデルにおいては、エッジルータ（ＥＲ）１２０、１２８は統合サービス承知（aware)顧客ＬＡＮ（図示なし）をディフサーブネットワーク１２４の境界ルータ（ＢＲ）１２２、１２６に接続する。ＬＡＮ−ＴＸ（送信）からＬＡＮ−ＲＸ（受信）へ一方方向のトラフィックフローを反映するために、エッジルータ１２０および境界ルータ１２２は送信または入り口側においてそれぞれＥＲ−ＴＸおよびＢＲ−ＴＸとラベル付けされ、エッジルータ１２８および境界ルータ１２６は受信器すなわち出口側でそれぞれＥＲ−ＲＸおよびＢＲ−ＲＸとラベル付けされる。
【００１２】
[１２］ 論理的に見ると、ルータ１２０、１２２、１２６および１２８の各々はそれぞれのルータの上下半分においてそれぞれ示されているような制御およびデータ面(control and data planes)を有する。データ面はルータの転送経路（例えばインターフェイスカードおよびスイッチング構成）における従来のハードウエア要素のすべてを含み、制御面は制御ハードウエア（例えば制御プロセッサ）およびデータ面の操作をサポートかつ指示する制御ソフトウエア（例えばルーティング、信号送信およびプロトコルスタック）を含む。
【００１３】
[１３］ データ面において、パケットはＥＲ−ＴＸ１２０のデータ面１２０ｂによって適切なＤＳＣＰ（例えば、起点アドレス、宛先アドレス、プロトコルＩＤ、起点ポートおよび宛先ポートのイントサーブの５タプルに基づいて）でパケットがマークされ、ディフサーブネットワーク１２４に転送される。それからパケットは、ＥＲ−ＲＸ１２８のデータ面１２８ｂへディフサーブネットワーク１２４を介して単にディフサーブ転送される。制御面において、エッジルータ１２０、１２８および境界ルータ１２２、１２６の各々は、ポリシ決定ポイント（ＰＤＰ）１３０ａ、１３０ｂにおいて実行されるポリシを参照してイントサーブ（ＩＳ）処理を実行する制御面を有している。ＥＲ−ＴＸ１２０においては、制御面１２０ａはイントサーブのフローごとの分類およびフローごとの取り締まり(policing)を実行する。境界ルータ１２２および１２６においては、エッジルータ１２０、１２８に対抗しているイントサーブのインターフェイスはＲＳＶＰ信号送信を管理し、イントサーブポリシおよび許可制御機能を実行し、経路状態ブロックおよび予約状態ブロックでフローごとの状態を維持する。ＥＲ−ＲＸ１２８の制御面１２８ａは発信パケットがＬＡＮ−ＲＸに転送される前にイントサーブのフローごとのシェイピング(shaping)を実行する。
【００１４】
[１４］ 上で議論したように、トラフィックフローを送信する前に、ＬＡＮ−ＴＸにおける送信ホストはＲＳＶＰ ＰＡＴＨメッセージを開始する。ＬＡＮ−ＲＸにおける受信ホストがＰＡＴＨメッセージを受信したとき、受信ホストは所望のＱｏＳを提供するために資源の予約を要求するために、逆データ経路に沿ってＲＥＳＶメッセージを戻す。ＲＥＳＶメッセージを受信した後、イントサーブ制御面を有する各中間ルータは、その下流リンクのみに対して許可制御を実行する。このように、ＥＲ−ＲＸ１２８はＬＡＮ−ＲＸのための許可制御を実行し、ＢＲ−ＲＸ１２６はそれ自身とＥＲ−ＲＸ１２８間のリンクのための許可制御を実行し、ＢＲ−ＴＸ１２２はＢＲ−ＲＸ１２６へのディフサーブネットワーク１２４を介した経路のための許可制御を実行し、ＥＲ-ＴＸ１２０はそれ自身とＢＲ−ＴＸ１２２との間のリンクのための許可制御を実行する。ＲＳＶＰ許可制御処理は、各リンクでの資源の利用可能性を確認し、それに応じて、リンクのための残りの資源を調整する。
【００１５】
[１５］ イントサーブのフローごとの許可制御は制御面において実行されるが、トラフィックフローに対するＱｏＳの実際の転送はデータ面において実行される。ＥＲ−ＴＸ１２０は、イントサーブ入力インターフェイス（ＩＳ ＩＮ）で受信したデータパケットでイントサーブ動作（例えばフローごとの分類、フローごとの取り締まりおよびフローごとのＤＳＣＰマーキング）を実行する。ＥＲ−ＴＸ１２０のディフサーブ出力インターフェイス（ＤＳ ＯＵＴ）においては、データパケットは特定され、そのＤＳＣＰ値のみに基づいてクラスに基づいて列が形成される。ＢＲ−ＴＸ１２２は、それからその入力インターフェイス（ＤＳ ＩＮ）で各顧客に対するクラスごとの取締りを実行し、その出力インターフェイス（ＤＳ ＯＵＴ）でクラスに基づく列作成を行う。ＢＲ−ＲＸ１２６で入力インターフェイス（ＤＳ ＩＮ）での動作は実行されず、クラスに基づく列および選択的なクラスごとのシェイピングは出力インターフェイスで各顧客ポートに対して実行される。ＥＲ−ＲＸ１２８はその入力インターフェイス（ＤＳ ＩＮ）で受信したパケットを転送し、そのイントサーブ出力インターフェイス（ＩＳ ＯＵＴ）でフローごとのスケジューリングまたはシェイピングを実行してもよい。
【００１６】
[１６］ ディフサーブ標準は、ディフサーブドメインにおけるイントサーブの処理集中型信号送信を単純なクラスに基づく処理と置き換えることによってイントサーブの拡張性を改良するが、ディフサーブプロトコルの実行は、異なった問題を導入する。特に、ディフサーブはサービスクラスのホストのマーキングを許容するため、ディフサーブネットワークの顧客リンク（例えばＢＲ−ＲＸ１２６の発信リンク）は、もし多くのホストがそのリンクに対して高い優先度に設定されたＤＳフィールドでパケットを送信すると、サービスの拒否（ＤｏＳ）攻撃を経験できる。
【００１７】
[１７］ さらに、ディフサーブドメイン内で拡張性におけるいくつかの改良にもかかわらず、ＲＳＶＰを使用したイントサーブ許可制御はフローごとの状態設定、フローごとの状態リフレッシュ、フローごとのトラフィック管理およびサービスプロバイダのネットワークの各エッジおよび境界ルータの資源予約をまだ要求する。境界ルータはネットワーク集合点として何千ものトラフィックフローを処理するため、多くのベンダの境界ルータはそのような大量のフローに対するフロー状態を設定できない。その結果、ＲＳＶＰのフローごとの許可制御はルータベンダによってはほんのたまにしか実行されず、またベンダーによってサポートされることはなかった。このように、ＲＳＶＰを使用した従来のイントサーブのフローごとの許可制御は拡張性に欠けるため望ましくない状態で残っていた。
【００１８】
[１８］ この発明は許可制御を実行するための改良された方法、装置およびシステムを導入することによって先行技術における前記のおよび付加的な欠点に対処する。
【００１９】
[１９] 発明のある実施例に従うと、この発明のネットワークシステムは、少なくとも、第一ルータと、上流リンクを介して第一ルータから第二ルータへのデータフローを許可するために上流リンクに接続された第二ルータとを含む。第二ルータは制御面と、上流リンクに接続された入力ポートおよび下流リンクに接続可能な出力ポートを有するデータ面とを含み。制御面は第一ルータの資源能力に対応する能力を有する仮想プールおよび許可制御機能を含む。入力ポートから出力ポートへのデータ面を介したフローのための資源の予約をするための要求に応答して、許可制御機能は、仮想プール内で資源の利用可能性を参照することによって上流リンクに対する許可制御を実行する。ある実施例において、要求は統合されたサービスフローに対する資源を予約する要求であって、仮想プールの能力は第一ルータによってサポートされた統合されたサービスのサービスクラスの資源能力に対応する。
【００２０】
[２０］ この発明の追加の目的、特徴および利点は以下の詳細な記載から明らかとなるであろう。
【００２１】
[２１］ この発明の特徴であると信じられる新規な特徴は添付クレームにおいて述べられている。しかしながら、発明自体および好ましい使用モード、その更なる目的および利点は添付の図面と共に読まれたとき、例示的な実施例の以下の詳細な記載を参照することによって最もよく理解されるであろう。
【００２２】
Ｉ.ネットワークモデルの概要
[３２］ 再び図、特に図３を参照して、この発明に従うディフサーブドメイン上でのエッジに基づくイントサーブを実施することによって選択されたトラフィックに対して向上されたＱｏＳを提供する、拡張性のあるネットワークモデルの高レベルのブロック図が示されている。特に、以下に詳細に述べるように、例示されたネットワークモデルは、資源予約および管理のための、クラスに基づく資源プールに対するフローごとの帯域幅の要求をマップ化する機構を用いて、ディフサーブドメインにおいてネットワーク装置からイントサーブのフローごとの許可制御を除去することによって、ネットワークの拡張性を改良する。理解の容易のために、図３は図２において使用されたのと同じ受信器／送信器およびデータ面／制御面の表記を採用する。
【００２３】
[３３］ 図３において、統合されたサービス承知(aware)ＬＡＮ−ＴＸおよびＬＡＮ−ＲＸは、各々が一以上のホストを含み、顧客構内装置（customer premises equipment,ＣＰＥ）エッジルータ（ＥＲ）１５０,１５８に接続されている。エッジルータ１５０,１５８は順にディフサーブネットワーク１２４の境界ルータ（ＢＲ）１５２,１５６に対してアクセスネットワーク（例えばＬ２アクセスネットワーク）によって接続されている。ネットワークサービスプロバイダはルータ１５０,１５２,１５６および１５８を設定して一以上のＰＤＰ１６０を使用してルータ１５０,１５２,１５６および１５８に許可制御および他のポリシをインストールする。
【００２４】
[３４］ この設定を使用して、図３のネットワークモデルはＬＡＮ−ＴＸにおける送信ホストからＬＡＮ−ＲＸの受信ホストに一方方向のトラフィックのフローをサポートする。典型的であるが、そのような通信は各プロトコル層がより高い層および低い層のプロトコルから独立しているような、層化されたプロトコルアーキテクチャを使用して好ましくは実行される。ある好ましい実施例においては、通信はＩＳＯ／ＯＳＩ（国際標準化機構／開放型システム間相互接続）の参照モデルのレイヤ３に対応するネットワークレベルでよく知られたインターネットプロトコル（ＩＰ）を採用している。ネットワーク層の上で通信がＯＳＩ／ＩＳＯ参照モデルのレイヤ４に対応する転送層におけるＴＣＰ（送信制御プロトコル）またはＵＤＰ（ユーザデータグラムプロトコル）のいずれかを採用してもよい。
【００２５】
[３５］ 転送層の上で、通信は部分的に要求されたＱｏＳによって、およびフローの他の要求によって決定されるように、多くの異なるプロトコルの任意のものを採用してもよい。例えば、国際電気通信ユニオン（ＩＴＵ）Ｈ.３２３プロトコルおよびＩＥＴＦセッション開始プロトコル（ＳＩＰ）がＩＰネットワーク上で、音声、ビデオ、マルチメディアおよび向上されたＱｏＳセッションの別のタイプの信号送信を提供するために共通に使用される。端末間プロトコルとして、ＳＩＰは端縁ノードに各種の呼び出し特性（例えばファインドミー／フォローミー）を使用した呼び出し処理を制御するための能力を有利に許容する。
【００２６】
[３６］ 少なくとも各エッジおよびディフサーブ境界ルータにおいてイントサーブ処理を実行するイントサーブ制御面を要求する図２に例示した先行技術のネットワークモデルと対照的に、図３に例示したネットワークモデルは、ネットワークの極端な端すなわち、ネットワークで管理されたＣＰＥエッジルータ１５０、１５８でのみイントサーブ処理を採用する。このように、例示された単一方向のパケットフローに対して、エッジルータ１５０、１５８はＬＡＮ−ＴＸからＬＡＮ−ＲＸへ送信されたフローのための向上されたＱｏＳを提供するためのＲＳＶＰ信号送信を使用したイントサーブ許可制御を実行する。エッジルータ１５０、１５８はディフサーブネットワーク１５４に対して（およびディフサーブネットワーク１５４がうまくトラフィック処理されている（engineered)と仮定して）イントサーブ許可制御を実行するため、ディフサーブネットワーク１５４に対して如何なる追加の許可制御も実行する必要はない。その結果、この発明によれば、境界ルータ１５２、１５６および例示されていないコアルータも含めてディフサーブネットワーク１５４におけるどのルータも、参照番号１５２ａおよび１５６ａで示されているようなイントサーブ制御面を有するよう要求されない。その結果、境界ルータ１５２および１５６はサービスプロバイダネットワークの向上された拡張性を促進するためにかなり単純化されうる。
【００２７】
[３７］ 境界ルータ１５２、１５６におけるこの有利な単純化を達成するために、図３のネットワークモデルは従来のイントサーブＲＳＶＰ信号送信モデルに対して修正が行われ、それは上記したように、下流リンクに対して許可制御を実行するために各ノードで対称的な処理を常に実行する。図３に例示されたネットワークモデルにおいては、受信ホストによって戻されたＲＳＶＰ ＲＥＳＶメッセージはエッジルータ１５０、１５８のイントサーブ制御面１５０ａ、１５８ａによってのみ処理され、エッジルータ１５０、１５８は要求された資源の利用可能性を確認し、それに応じて資源の数を調整する。特に、ＥＲ−ＴＸ１５０のイントサーブ制御面１５０ａはそれ自身とＢＲ−ＴＸ１５２間のリンクに対する下流許可制御を実行する。しかしながら、ＥＲ−ＲＸ１５８のイントサーブ制御面１５８ａはその下流リンク（例えばＬＡＮ−ＲＸ）のためだけではなく、それ自身およびＢＲ−ＲＸ１５６のためにも許可制御を実行する。これは、上流リンク境界ルータ１５２、１５６はＲＳＶＰ承知型ではないためである。
【００２８】
[３８］ 概念的には立派ではあるが、この図３に示されたネットワークモデルは効力のあるネットワークの実施を得るために対処されなければならない些細ではない多くの挑戦事項を有している。例えば、従来のイントサーブＲＳＶＰ信号送信は各ノードにおいて対称的であったため、ＥＲ−ＲＸ１５６に、それは「受信」エッジルータであり、それゆえその上流リンクに対して許可制御を実行しなければならないということを知らせるために如何なる従来の機構も提供されない。加えて、従来のイントサーブＲＳＶＰ信号送信は、ＥＲ−ＲＸ１５６に許可制御が実行されねばならない上流リンクに対する資源の利用可能性および資源の能力に関する如何なる情報も提供しなかった。さらにＲＦＣ２９９８（および一般の技術）はＥＲ−ＴＸ１５０でどのようにディフサーブ／イントサーブ相互作用を実行するのかということに対して如何なる手引きも提供せず、特に、イントサーブクラスをディフサーブクラスにどのようにマップ化するのかということを開示しなかった。図３に示されたネットワークモデルの実施に関するこれらおよび他の問題に対する好ましい解法は以下に詳細に述べる。
【００２９】
ＩＩ．受信エッジルータ識別
[３９］ 図４を参照して、ＥＲ−ＲＸ１５８のようなエッジルータがそれが受信エッジルータであると決定できる、ある好ましい方法が示されている。示された操作シナリオにおいて、顧客ＬＡＮ、エッジルータ１５０、１５８および境界ルータ１５２、１５６の各々は異なるＩＰアドレスを有し、ＥＲ−ＲＸ１５８に接続された顧客ＬＡＮは、各々がＥＲ−ＲＸ１５８に割り当てられたＩＰアドレスのサブネットであるＩＰアドレスが割り当てられている。
【００３０】
[４０］ 上記したように、ＬＡＮ−ＴＸの送信ホストはＲＳＶＰ ＰＡＴＨメッセージを送信することによってＬＡＮ−ＲＸにおける受信ホストで向上されたＱｏＳセッションを開始する。ＰＡＴＨメッセージにおいて特定された宛先アドレス（ＤｅｓｔＡｄｄｒｅｓｓ）に基づいて、これは例示された例ではａ.ｂ.ｐ.ｄで例示されるが、ＰＡＴＨメッセージはディフサーブネットワーク１５４を介してＬＡＮ−ＲＸへ発送される。ＰＡＴＨメッセージに応答して、受信ホストは宛先アドレスを特定するセッションオブジェクトを含むＲＳＶＰ ＲＥＳＶメッセージを送信する。ＲＥＳＶメッセージの受信をすると、ＥＲ−ＲＸ１５８のイントサーブ制御面１５８ａにおけるＲＳＶＰ処理は、宛先アドレスを各付随した顧客ＬＡＮのＩＰサブネットアドレスと比較することによって、ＥＲ−ＲＸ１５８が受信エッジルータかどうかを判定することができる。もし、そして宛先アドレスが付随した顧客サブネットの一つに入りされすれば、ＥＲ−ＲＸ１５８は、それがトラフィックフローのための受信エッジルータであるということを知る。例えば、ＥＲ−ＲＸ１５８が宛先アドレスａ.ｂ.ｐ.ｄを含むセッションオブジェクトを有するＲＥＳＶメッセージを受信したとき、ＥＲ−ＲＸ１５８はそれが受信エッジルータであることを知る。というのは、ＬＡＮ−ＲＸのＩＰアドレス（例えばａ.ｂ.ｐ.ｄ）はａ.ｂ.ｐ.０／２４のＩＰサブネットアドレスであるからである。ＥＲ−ＲＸ１５８はそれゆえ向上されたＱｏＳフローのための上流リンクに対するイントサーブ許可制御を実行する。
【００３１】
[４１］ 受信エッジルータを特定するこの方法は単純であるという利点を有してはいるが、それは各宛先アドレスが受信エッジルータのＩＰアドレスのサブネットを特定することを要求する。この制限が好ましくないような実施例においては、受信エッジルータを特定する代わりの方法が採用されてもよい。例えば、図６に関して詳細に以下に述べるように、受信エッジルータはＰＤＰ１６０によってエッジルータ１５０、１５８に設定されたエッジポイント識別を介して特定されてもよい。これらのポリシデータ構造は、ルータが受信エッジルータであるためのＩＰアドレスの一以上の範囲を特定する。
【００３２】
ＩＩＩ.資源管理
[４２］ 資源の利用可能性を追跡するために（上流許可制御を実行するために利用される資源利用可能性を含む）、各イントサーブ承知エッジルータは、各イントサーブクラスのための制御面内に分離されたまたは共有された仮想のプールを維持し、そこでは各仮想のプールは、ルータが許可制御を実行するためのリンク上の関連したイントサーブクラスに対する資源の利用可能性を表す。エッジルータがＲＳＶＰ ＲＥＳＶメッセージを受信するときはいつも、エッジルータは、要求されたイントサーブクラスにおける資源の利用可能性を決定するために、適切な仮想プールに対して要求された帯域幅をチェックすることによってリンク上の許可制御を実行する。仮想プールが要求された帯域幅が利用可能な帯域幅よりも狭いと指示したとき、資源予約は認められ、仮想プールの保存可能な資源は保存された帯域の量だけ減少される。しかしながら、もし要求された帯域幅が仮想プールの利用可能な帯域幅を超えているときは、ＱｏＳ要求は否定される。
【００３３】
[４３］ イントサーブ許可制御とディフサーブデータ面機能との間の相互作用は、イントサーブ許可制御を実行するために利用される仮想プールを、データ面におけるクラスに基づくＱｏＳを配送するためのディフサーブによって採用された論理列に関連つけることによって達成される。特に、各イントサーブクラスは一つおよび唯一のディフサーブ論理列に独自に関連している。しかしながら、イントサーブ許可制御を実行するのに利用される仮想プールと同様に、別の論理列が一以上のイントサーブクラスの各々に対して実行され、一以上の論理列が多数のイントサーブクラスに関連した共有された列として実行されてもよい。
【００３４】
[４４］ 次の表Ｉは、サービスプロバイダネットワークの境界およびエッジ内で実施されてもよい論理列および仮想プールの可能な組み合わせを要約している。
【００３５】
【表Ｉ】

【００３６】
[４５］ 表Ｉに示されているように、次の３つのケースが可能である。分離された論理列付の分離された仮想プール、共有された論理列付の共有された仮想プール、共有された論理列付の分離された仮想プールである。多数のイントサーブクラスによって共有された仮想プールの場合は、個々のクラスベースで利用可能な仮想プール情報が存在しないため、各イントサーブクラスに対する分離された論理列を有する実施には適用されない。重要なことは、同じネットワークにおける境界およびエッジルータは、マーキングが正確に実行されている限り、異なるケースを同時に実施するために設定されてもよい、ということである。
【００３７】
[４６］ 図５および６を参照して、各イントサーブサービスクラスにおけるトラフィックが表Ｉのケース１に応じたデータ面における分離された論理列および制御面における分離された仮想プールに割り当てられた、図３のネットワークモデルのエッジおよび境界ルータのより詳細なブロック図が示されている。まず図５を参照して、ＥＲ−ＴＸ１５０のより詳細なブロック図が示されている。上記したように、ＥＲ−ＴＸ１５０は、ＲＳＶＰ信号送信を管理し、イントサーブポリシおよび許可制御を実行するイントサーブ１５０ａと、ディフサーブのクラスに基づくＱｏＳのリンクレベルの配送を提供するデータ面１５０ｂとを有している。制御面１５０ａはＲＳＶＰ処理１８０、関連する仮想プール１８４を有する許可制御ブロック１８２、ポリシ制御ブロック１８８、ＩＳ−ＤＳ相互作用機能（ＩＷＦ）設定ブロック１８６およびＥＲ−ＴＸ１５０がＰＤＰ１６０ａでポリシ情報を通信するポリシ設定インターフェイス（ＰＣＩ）１９０とを含む。データ面１５０ｂは入力ポート２００と、転送機能２０８と、各々がディフサーブクラスに対応する多くの列２１２を有する出力ポート２１０とを含む。
【００３８】
[４７］ 上記したように、制御面１５０ａ内のＲＳＶＰ処理１８０は、向上されたＱｏＳフローに対する資源を保存（および解放）するために利用されるＲＳＶＰ信号送信（例えばＰＡＴＨおよびＲＥＳＶメッセージ）を処理する。向上されたＱｏＳフローに対する資源を要求するＲＥＳＶメッセージの受信に応答して、ＲＳＶＰ処理１８０は要求者がＱｏＳフローを確立するために管理許可を有しているかということおよび要求されたＱｏＳをサポートするために十分に利用可能な資源を下流インターフェイスが有しているかどうかということを確認するために、許可制御ブロック１８２およびポリシ制御ブロック１８８に問い合わせを行う。管理許可を決定するのに加えて、ポリシ制御ブロック１８８は、証明書または署名に基づく鑑定、認定された要求者間の帯域幅分布の管理および継続中の高い優先度を有するフローに対する割り当てられた資源の先取りのような追加のポリシを実行できる。
【００３９】
[４８］ 例示された実施例においては、各サポートされたイントサーブクラス（例えば保障されたサービス（ＧＳ）および制御された負荷（ＣＬ））は分離された仮想プール１８４ａ、１８４ｂを有する。許可制御ブロック１８２は仮想資源プール１８４を使用して各イントサーブクラスに対する下流リンクで資源の利用可能性をモニタする。このように、許可制御ブロック１８２は十分な利用可能な帯域幅が要求されたイントサーブクラスに関連した仮想プールに存在すれば、予約要求を許可し、そうでなければ、予約要求を否定する。許可制御ブロック１８２は各成功した予約によって要求された量だけ仮想プールにある利用可能な資源を減らし、フローの終了によって解放された資源の量だけ仮想プールにおける予約可能な資源を増やす。重要なことは、仮想プールの数および各仮想プール１８４に割り当てられた帯域幅および仮想プールとディフサーブクラスとの間のマッピングは固定されず、ＰＤＰ１６０によってＥＲ−ＴＸ１５０（および他のネットワーク要素）でインストールされたポリシとして代わりに表現される。共通のオープンポリシサービス（Common Open Policy Service,ＣＯＰＳ）または他のプロトコルを利用するといった、ポリシは、たとえば、ＲＳＶＰ ＲＥＳＶメッセージに応答して、例えば、ＰＤＰ１６０によってネットワーク要素に押されるか(push)、またはネットワーク要素によってＰＤＰ１６０から引かれ(pull)てもよい。
【００４０】
[４９］ ＰＤＰ１６０ａはＩＳ−ＤＳ ＩＷＦ設定ブロック１８６（例えば、ＧＳからＤＳＣＰ１０００１１、ＣＬからＤＳＣＰ０１００１１へ）でイントサーブクラスとディフサーブクラス（およびＤＳＣＰ）間のマッピングを設定する。ＩＳ−ＤＳ ＩＷＦ設定ブロック１８６は、ＲＳＶＰ処理１８０から設定をまた受信してもよい。これらの設定に基づいて、ＩＳ−ＤＳ ＩＷＦ設定ブロック１８６は各イントサーブフローに対してパケット分類器２０２、ポリサ２０４および入力ポート２００上のマーカ２０６を動的に供給する（ある実施例においては、パケット分類器２０２、ポリサ２０４およびマーカ２０６はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）または特定用途向け集積回路（ＡＳＩＣ）のような単一の集積モジュールとして実施されてもよい）。
【００４１】
[５０］ この供給に従って、各イントサーブフロー内のパケットは、そのサービスクラスはイントサーブ５タプルによって示されるが、集合ディフサーブクラスの適切なＤＳＣＰでパケット分類器２０２およびマーカ２０６によって分類されかつマーク付けされる（例えば、実験的またはローカルの使用に対して予約された１６コードポイント（プール２ｘｘｘｘ１１）の一つで）。このようにして、向上されたＱｏＳを有するイントサーブフローは優先されるディフサーブクラスに集合される。図５に示された実施例は表Ｉからのケース１を反映しているため、分離された論理列２１２が他のディフサーブクラス（例えば促進された転送（ＥＦ）、保証された転送（ＡＦ）およびデフォルトのベストエフォート型（ＢＥ）クラス）に割り当てられた論理列に加えて、各サポートされたイントサーブクラス（ＧＳおよびＣＬ）に対してポート２１０に提供される。スケジューラ２１４は、それからＰＤＰ１６０ａによって各論理列２１２に割り当てられたスケジューラの重みつけに従って、論理列２１２からパケット送信を計画することによって各論理列２１２内のパケットに対して適切なＱｏＳを提供する。
【００４２】
[５１］ ＥＲ−ＴＸ１５０の例示された実施例はネットワークサービスプロバイダによって管理されているため、ＥＲ−ＴＸ１５０はＱｏＳの「窃盗」が生じないように、パケットにＤＳＣＰを正確にマークするためにネットワークサービスプロバイダによって信頼されうる。ＥＲ−ＴＸがネットワークサービスプロバイダによって管理されない別の実施例においては、ＰＤＰサーバ１６０ａがＥＲ−ＴＸ１５０の代わりにＢＲ−ＴＸ１５２に対してディフサーブ分類ポリシを提供してもよい。たとえ分離された列がエッジおよび境界ルータで実施されたとしても、ディフサーブネットワーク１５４のコアルータはイントサーブフローのために別のディフサーブ列を実施する必要がないということを注意すべきである。
【００４３】
[５２］ 図６を参照して、表Ｉのケース１の好ましい実施例に従ったＢＲ−ＲＸ１５６およびＥＲ−ＲＸ１５８のより詳細なブロック図が例示されている。上記したように、ＢＲ−ＲＸ１５６およびＥＲ−ＲＸ１５８はそれぞれの制御面１５６ａ、１５８ａおよびデータ面１５６ｂ、１５８ｂを有している。ＥＲ−ＲＸ１５８の制御面１５８ａはＰＣＩ１９０と、関連する許可およびポリシ制御ブロック１８２、１８８を有するＲＳＶＰ処理１８０と、許可制御ブロック１８２が上流許可制御を実行する、エッジポイント特定テーブル２５２および上流仮想プール２５０とを含む。対照的に、ＢＲ−ＲＸ１５６ａはイントサーブ制御面を有することなく、データ面１５６ｂの要素がＰＤＰ１６０ｂによって設定されるＰＣＩ１９０のみを代わりに含む。
【００４４】
[５３］ ＥＲ−ＲＸ１５８の制御面１５８ａ内で、ＰＤＰ１６０ｂはどの顧客が向上されたＱｏＳフローに対する資源予約を要求する管理許可を有しているかということをローカルのポリシ制御１８８が判定するポリシをインストールする。加えて、ＰＤＰ１６０ｂはＥＲ−ＲＸ１５８が受信エッジルータである、宛先ＩＰアドレスの一以上の範囲を特定するエッジポイント識別表２５２をインストールする。このように、顧客がポリシ制御１８８によって管理許可を認められるための向上されたＱｏＳフローを要求するＲＥＳＶメッセージの受信に応じて、許可制御１８２はＥＲ−ＲＸ１５８が要求されたフローに対する受信エッジルータであるかどうかを判定するためにエッジポイント識別表２５２に問い合わせを行う。そうでなければ、ＥＲ−ＲＸ１５８は従来の下流許可制御を実行する。しかしながら、もしエッジポイント識別表２５２が、ＥＲ−ＲＸ１５８が、要求されたフローに対する受信エッジルータであると示したときは、許可制御ブロック１８２は仮想プール２５０内の各イントサーブクラスに対してＰＤＰ１６０ｂによって割り当てられた上流仮想プール能力を参照して、上流許可制御を実行する。一般に上で述べたように、各仮想プール２５０ａ、２５０ｂはＥＲ−ＲＸ１５８およびＢＲ−ＴＸ１５２間の上流リンクで特定のイントサーブクラスの要求されたフローに対する十分な帯域幅の利用可能性を確認するために許可制御ブロック１８２によって利用される。参照符号２５２で示されるように、ＰＤＰ１６０ｂはＥＲ−ＲＸ１５８で仮想のプール使用に関する周期的または求められたフィードバックを得、実際に使用されているイントサーブの帯域幅がオプレータが特定した能力よりも小さいということを確認するために、データ面において実行された論理列およびスケジューラの重みつけに対する更新を行って仮想プールの能力に対する任意のオペレータが開始した調停を動的に調整する。
【００４５】
[５４］ データ面を参照して、ＥＲ−ＲＸ１５８のデータ面１５８ｂはこの発明が不明確になるのを避けるために、その詳細が省力された、従来の分類、転送およびイントサーブ列で実行されてもよい。ＢＲ−ＲＸ１５６のデータ面１５６ｂは、分類器２２２を有する入力ポート２２０と、複数のディフサーブ物理列２４２およびスケジューラ２４４を有する出力ポート２４０と、分類器２２２によって実行された分類に応じて出力ポート２４０で適切な物理列２４２に入力ポートからのパケットを交換する転送機能２３０とを含む。示されたように、分類器２２２および物理列２４２は、ＥＲ−ＲＸ１５８の制御面１５８ａの上流イントサーブ仮想プールの設定を反映するために調整された方法でＰＤＰ１６０ｂによって設定される。特に、例示された実施例では、分類器２２２はイントサーブトラフィックが集合される、別のディフサーブクラスに属するパケットを特定するよう設定される。イントサーブトラフィックの形式を表す各ディフサーブクラスのそのようなパケットは、出力ポート２４０のイントサーブＧＳおよびＣＬに対する別の物理列２４２に対して転送される。ＰＤＰ１６０ｂはスケジューリングの重み付けを設定し、スケジューラ２４４は列２４２の各々に与える。加えて、ＰＤＰ１６０は、仮想プール能力が実際の資源プール能力を超えないということを確実にするために、ＥＲ−ＲＸ１５８の仮想プール能力の合計をＢＲ−ＲＸ１５６のデータ面１５６ｂの列能力および重み付けによって指示された資源プール能力と釣り合わせる。このように、本質的に、ＥＲ−ＲＸはＢＲ−ＲＸのプロキシとして上流許可制御を実行する。
【００４６】
[５５］ 図５および６において示されたディフサーブ列と仮想プールを分離するための異なるイントサーブクラスのマッピングはすべてのイントサーブクラスを単一のディフサーブ列にマッピングするよりもよりよいトラフィック管理を許容する。このようにディフサーブネットワークを介してのイントサーブクラス間の区別を保存することによって、異なるトラフィックタイプ（例えばＶｏＩＰ、ビデオＩＰおよびファイル転送）は最適の処理が提供され、企業資源計画が単純になる。しかしながら、上記したように、サービスプロバイダネットワークにおけるいくつかの、またはすべてのルータはケース２および３に従って代わりに実行されてもよい。ケース１の代わりにケース２を実行するために、ＥＲ−ＴＸ１５０およびＥＲ−ＲＸ１５８は、複数のイントサーブクラスのための単一の共有された仮想プールで設定され、ＥＲ−ＴＸ１５０およびＢＲ−ＲＸ１５６は多数のイントサーブクラスのための単一の共有された論理列で設定される。代わりに、ケースＩＩＩを実行するために、ＥＲ−ＴＸ１５０およびＥＲ−ＲＸ１５８は別の仮想のプールで設定され、ＥＲ−ＴＸ１５０およびＢＲ−ＲＸ１５６は多数のイントサーブクラスのための単一の共有された列で設定される。
【００４７】
[５６］ 特定のフローに対して向上されたＱｏＳを提供するために、ＢＲ−ＴＸ１５２の制御面１５２ａまたはデータ面１５２ｂのフローに特定されたネットワーク設定は不要であるということに注意のこと。これは、下流ＥＲ−ＲＸ１５８によって提供される許可制御によってＢＲ−ＴＸ１５２の下流リンクが向上されたＱｏＳフローをサポートするに十分な帯域幅を有するということを確実にされ、特定のディフサーブクラスに対するイントサーブフローのマッピングによってデータ面１５２ｂが要求されたＱｏＳを達成するということを確実にされるためである。
【００４８】
ＩＶ． ＰＤＰ
[５７］ 図７を参照して、この発明の好ましい実施例に応じた、ＰＤＰ１６０として採用されてもよいサーバコンピュータシステムのハイレベルのブロック図が示されている。ＰＤＰ１６０はストレージサブシステム２６８に相互接続２６４を介して接続された一以上のプロセッサ２６２を含む。ストレージサブシステム２６８は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、磁気ディスク、光ディスクおよび／または他のストレージ技術を含んでもよい。ストレージサブシステム２６８はネットワーク要素を設定し、ネットワークポリシをインストールかつ決定するためにプロセッサ２６２によって処理されたデータ（例えば表２８０−２９０）および命令（例えば設定マネージャ２９２）のためのストレージを提供する。また相互接続２６４には、一以上の入力装置（例えばキーボードおよび／またはグラフィカルポインティング装置）２７０、一以上の出力装置（例えばディスプレイ）２７２および通信インターフェイス２７４が接続されてもよく、この通信インターフェイス２７４を介してコンピュータシステム２６０はルータ１５０、１５２、１５６および１６０のようなネットワーク装置と通信してもよい。
【００４９】
[５８］ 上記した方法でルータ１５０、１５６、１６０にポリシを設定およびインストールするために、各ＰＤＰ１６０はストレージサブシステム２６８内に多くのポリシルールクラス（ＰＲＣ）表を好ましくは実行する。ある好ましい実施例においては、これらのＰＲＣ表は少なくとも許可制御仮想プール表２８０、イントサーブ能力表２８２、イントサーブからディフサーブへの相互作用機能表２８４、エッジポイント識別表２８６、プール使用フィードバック表２８８および境界資源プール表２９０を含む。
【００５０】
[５９］ 許可制御仮想プール表２８０は、各種イントサーブクラスのための許可制御を実行するために使用されるエッジルータ１５０、１５８の仮想プールの能力を決定する。許可制御仮想プール表２８０においては、すべてのイントサーブクラスに関連した仮想のプールに割り当てられた能力の合計は各許可されたフローの要求されたＱｏＳがデータ面において達成できるということを確実にするために、関連した境界ルータのデータ面列の能力よりも少なくなるように設定される。表はさらに許可制御が予約、およびエッジルータに関連した境界ルータの論理インターフェイス名を受け付けるかどうか特定する。模範的な実施例においては、許可制御仮想プール表２８０は以下のように規定されてもよい。
【００５１】
AdmCtlVirtualPoolTable
論理インターフェイス名
記述：このＳＮＭＰストリングは許可制御仮想プールエントリに関連した論理インターフェイスを特定する。
【００５２】
オブジェクトタイプ：ＳＮＭＰストリング
命令
記述：この属性は（１）入来または（２）発信のいずれかとしてインターフェイスに対するトラフィックの流れの関係を示す。この属性はＥＲ−ＲＸ仮想資源プールとＥＲ−ＴＸ仮想資源プールとを差別化するために境界論理インターフェイス名と組み合わせて使用される。ＥＲ−ＲＸ上流仮想資源プールは入来命令および非資源プールおよびＥＲ−ＴＸ仮想資源プールを有する。ＥＲ−ＲＸ上流仮想資源プールは、着信命令および空でない境界論理インターフェイス名を有する。ＥＲ−ＴＸ下流仮想資源プールは発信命令および空でない境界論理インターフェイス名属性を有している。ＥＲ−ＲＸ下流仮想資源プールは、発信命令および空の境界論理インターフェイス名属性を有している。
【００５３】
ＩｎｔＳｒｖＣｌａｓｓ
記述：このビットストリングは、この仮想プールからの許可制御によって割り当てられる資源を有するイントサーブクラスを示す。
【００５４】
オブジェクトタイプ：ビット
制御された負荷サービス（１）
保証されたサービス（２）
ナルサービス（３）
他（４）
VirtualPoolMaxAbsRate
記述：このプールがAdmCtIIntSrvClassによって規定されるイントサーブセッションに割り当ててもよいキロビットで表された最大絶対割合。ＥＲ−ＲＸ上流仮想資源プールの和は関連するBoundaryInterfaceNameに対するResourcePoolMaxAbsRateを超えないようになっている。
【００５５】
オブジェクトタイプ：署名なし３２
BoudaryLogicalInterfaceName
記述：このエントリによって規定されるローカルの仮想プールの能力を支配する資源プールおよび隣接する境界ルータを識別する。空の属性はVirtualPoolMaxAbsRateがこのエントリのLogicalInterfaceNameに対して規定されたローカルなResourcePoolMaxAbsRate支配されるということを意味する。空でない属性はこのBoudaryLogicalInterfaceNameに対して規定された遠隔の仮想プール能力がこのエントリのVirtualPoolMaxAbsRateの値を支配するということを示す。
【００５６】
オブジェクトタイプ：ＳＮＭＰストリング
AcceptReservations
記述：この値は、ＲＳＶＰ ＲＥＳＶ要求を処理することを許可制御が試みるかどうかを示す。値０は予約が処理されないことを示す。値１は予約が処理されることを意味する。
【００５７】
オブジェクトタイプ：署名なし３２
[６０］ イントサーブ能力表２８２はディフサーブ列重み付けおよびシェイパパラメータの両方の条件でイントサーブクラスに割り当てられたデータ面データの速度能力を規定する。これらの速度能力は、表によって一以上のエッジルータ仮想プールに関連する。ある好ましい実施例に従う、このポリシ規則クラスは差別化されたサービスポリシ情報ベース（ＰＩＢ）に含まれる。
【００５８】
[６１］ イントサーブからディフサーブへのＩＷＦ表２８４は、制御面におけるＲＳＶＰ処理とデータ面におけるディフサーブとの間の相互作用のために使用される属性を規定する。これらの属性は、ディフサーブが各フローに対して適切なＱｏＳを達成するように、イントサーブトラフィックフロー分類、取り締まりおよびマーク付けをするために、ＥＲ−ＴＸ１５０の入力ポート２００で分類器２０２、ポリサ２０４およびマーカ２０６によって使用される。加えて、表は特定のイントサーブクラスを有するフローに対して使用される特定のスケジューラ事例を特定する。イントサーブからディフサーブＩＷＦ表２８４の模範的な実施例は以下の通りである。
イントサーブからディフサーブへの相互作用機能表
IwfPrid
記述：これはPktIwfTableエントリの独自の識別子である。
オブジェクトタイプ：事例ＩＤ（署名なし３２）
IwfIntSrvClass
記述：この特定の相互作用機能エントリの属性に関連するイントサーブクラスの値（それはAdmCtlIntSrvClass内の対応するビットセットを有さなければならない）
オブジェクトタイプ：署名なし３２
IwfDSCP
記述：イントサーブクラスタイプがPktIwfIntSrvClassの値に合致した状態で、セッションのためのデータの流れに割り当てるＤＳＣＰの値
オブジェクトタイプ：整数値０−６３
IwfOutOfProfile
記述：この値はデータストリームがプロファイルになっていないときのポリシング(policing)行為を示す。特徴は関連するMeterTableEntryによって規定されうる。値１はプロファイル外のパケットが脱落されることを意味する。値２はプロファイルでないパケットがIwfRemarkValueにおいて規定されたＤＳＣＰで注意されることを示す。
オブジェクトタイプ：署名なし３２
IwfRemarkValue
記述：プロファイルのないパケットに注意するためのＤＳＣＰの値
この値はIwfOutOfProfileがセットされているときのみ使用される。
オブジェクトタイプ：署名なし３２値０−６３
IwfSchedulerPrid
記述：特定のスケジューラの事例ＩＤの値であって、イントサーブクラスが属性IwfIntSrvClassの値と一致したときのセッションのデータストリームによって使用される。
オブジェクトタイプ：署名なし３２
[６２］ エッジポイント識別子表２８６はエッジルータが受信エッジルータであるためのアドレスの範囲を規定する。この情報は始めにＰＤＰ１６０で設定されてもよいし、ローカルで学ばれてもよい。ＥＸ−ＲＸ１５８の許可制御ブロック１８２は、これらのアドレス範囲の一つ内に入るＲＳＶＰ ＳＥＳＳＩＯＮオブジェクト内の宛先アドレスを特定する予約要求のための上流許可制御を実行する。特定のエッジルータのための値は、ＰＤＰ１６０によってＣＯＰＳまたは他のポリシプロトコルを利用したローカルのエッジポイント識別表２８６に対して押し下げ（pushed down)られてもよい。ある実施例によれば、エッジポイント識別表２８６は以下のように規定されてもよい。
【００５９】
端部点識別表
ReceiverDomainPrid
記述：このポリシ規則クラスのエントリの独自の識別子
オブジェクトタイプ：事例ＩＤ、３２ビット署名なし
ReceiverAddrType
記述：ＲＦＣ２８５１[M. Daniele et al., "Textual Conventions for Internet Network Addresses" June 2000]において規定されたアドレスタイプを特定するシュミレーション値
オブジェクトタイプ：ＲＦＣ２８５１によって規定されるＩＮＥＴアドレスタイプ
ReceiverAddr
記述：セッションオブジェクト宛先アドレスが合致するためのＩＰアドレス
オブジェクトタイプ：ＲＦＣ２８５１によって規定されるＩＮＥＴアドレス
ReceiverAddrMask
記述：ＩＮＥＴアドレスを合わせるためのマスクの長さ
オブジェクトタイプ：署名なし３２
[６３］ プール使用フィードバック表２８８はイントサーブフローによって消費される現在の資源を特定するエントリを含む。このＰＲＣ表はＰＤＰによって使用され、オペレータが開始した能力の更新の準備をいつ完成するかを決定するものであり、模範的な実施例において以下のように規定されてもよい。
【００６０】
プール使用フィードバック表
UsageFeedbackPrid
記述：仮想プール使用フィードバックエントリの独自の識別子
オブジェクトタイプ：事例Ｉｄ（署名なし３２）
PoolPrid
記述：特定の使用が記述される特定のAdmCtlVirtualPoolエントリの事例ＩＤの値
オブジェクトタイプ：署名なし３２
ReourseAbsRateInUse
記述：使用中のイントサーブ資源の現在のトータルの値
[６４］ 境界の資源プール表２９０は所与の出口境界ルータ（ＢＲ−ＲＸ）に関連した各種許可制御仮想プールに対するＰＤＰ１６０によって割り当てられてもよいトータルの割合能力を規定する。このＰＲＣ表は模範的な実施例において以下のように規定されてもよい。
【００６１】
境界資源プール表
BoundaryResourcePoolTableBoudaryResourcePoolPrid
記述：仮想プール使用フィードバックエントリの独自の識別子
オブジェクトタイプ：事例ＩＤ（署名なし３２）
BoundaryLogicalInterfaceName
記述：AdmissionCtlVirtualPoolTableにおけるこのエントリに関連するローカルの仮想プールの能力を支配する隣接した境界ルータおよび資源プールを特定する。
【００６２】
オブジェクトタイプ：ＳＮＭＴストリング
ResourcePoolMaxAbsRate
記述：AdmCtlIntSrvClassによって規定されたイントサーブセッションに割り当てられてもよいキロビットで表された最大絶対速度。ＥＲ−ＲＸの上流仮想プールの合計は関連したBoundaryInterfaceNameのためのResourcePoolMaxAbsRateを超えないようになっている。
【００６３】
オブジェクトタイプ：署名なし３２
Ｖ．ネットワーク設定
[６５］ 図８Ａ−８Ｃを参照して、多数のネットワークダイアグラムが示されている。これらはＰＤＰ１６０ｂがＢＲ−ＲＸ１５６およびＥＲ−ＲＸ１５８のポリシを設定およびインストールする好ましい技術を共に例示する。例示された機能は、例えば、設定管理ソフトウエア２９２のＰＤＰ１６０による実行によって行われてもよい。各図において、ＰＤＰ１６０ｂとルータ１５６、１５８の間の通信は、別のプロトコルを採用してもよいということを理解すべきではあるが、ＣＯＰＳを利用して行われると仮定される。
【００６４】
[６６］ 図８Ａはサービス開始時にＢＲ−ＲＸ１５６でディフサーブ論理列帯域幅でＥＲ−ＲＸ１５８の仮想プール能力を同期化するＰＤＰ１６０ｂを例示する。図８Ａの参照符号３００で示されるように、ネットワーク管理システム（ＮＭＳ）は例えば、サービス開始時に顧客に対してイントサーブ能力の設定を開始してもよい。応じて、ＰＤＰ１６０ｂは、ディフサーブネットワーク１５４の境界ルータの下流に存在する各ネットワーク管理エッジルータ（ＥＲ−ＲＸ１５８だけがその中で示されている）に対してイントサーブ仮想プール能力の設定を押す。例えば、示された実施例において、ＰＤＰ１６０ｂは、イントサーブＧＳクラスに対して１０メガビットを、イントサーブＣＬクラスに対して２５メガビットを割り当てるメッセージでＥＲ−ＲＸ１５８にインターフェイス１．ｍ．ｎ．ｂ／３０でＬＰ１によってサポートされた各イントサーブクラスに対して仮想のプール能力を押す。もし設定がうまくＥＲ−ＲＸ１５８にインストールされたときは、ＥＲ−ＲＸ１５８は参照番号３０４で示されるように通知（ＡＣＫ）メッセージで応答する。ＰＤＰ１６０ｂは参照番号３０６で示されているように、それからＢＲ−ＲＸ１５６に対応するディフサーブ列の設定およびスケジューラ重み付けを押す。ＢＲ−ＲＸ１５６はまた、もし設定がうまくインストールされたときは、ＡＣＫ３０８をＰＤＰ１６０ｂに戻す。
【００６５】
[６７］ もしＥＲ−ＲＸ１５８がＰＤＰ１６０ｂによって押された仮想のプール能力のインストールに失敗すると、ＥＲ−ＲＸ１５８はＰＤＰ１６０ｂに否定的な通知（ＮＡＣＫ）を戻す。それに応じて、ＰＤＰ１６０ｂは、「ＥＲ ＸＸに統合サービス仮想プールを設定するのに失敗した」のような警告メッセージをネットワークオペレータに送る。同様に、もし列およびスケジューラ重み付けがＢＲ−ＲＸ１５６にインストールできないときは、ＢＲ−ＲＸ１５６は、ＰＤＰ１６０上にＮＡＣＫを戻す。仮想プールの設定を解放するためにメッセージをＥＲ−ＲＸ１５８に送信し、また、「ＢＲ ＸＸに列およびスケジューラを設定するのに失敗した」という警告メッセージをネットワークオペレータに送信してもよい。
【００６６】
[６８］ ＰＤＰ１６０ｂは、ＢＲ−ＲＸ１５６およびＥＲ−ＲＸ１５８のようなネットワーク要素と直接に通信するのではなく、他のネットワーク要素を介して通信してもよいということに注意すべきである。例えば、ＰＤＰ１６０ｂとＢＲ−ＲＸ１５６との間のメッセージはＥＲ−ＲＸ１５８を介して通信されてもよい。
【００６７】
[６９］ サービス更新（すなわち、予約されたイントサーブ能力の増加または減少）が既存のネットワークサービス顧客に対して実行されるシナリオについて次に述べる。現在の予約された帯域幅が新しく予約された能力より低いときは、ＢＲ−ＲＸ能力の増加または減少は、まっすぐな処理である。というのは、新しい能力は、すべての継続中の顧客トラフィックを収容することができ、サービスの衝撃が見られないからである。しかしながら、現在の予約された帯域幅が新しく要求された能力より大きいときのＢＲ−ＲＸ能力の減少は、図８Ｂを参照して述べられるように、ＰＤＰ１６０ｂ、ＢＲ−ＲＸ１５６およびＥＲ−ＲＸ１５８間の調整が必要になる。
【００６８】
[７０］ 図８Ｂにおいて、ＮＭＳは参照番号３２０で示されるように、既存のネットワークサービス顧客に対してイントサーブ能力の再設定を始めてもよい。参照番号３２２で示されるように、ＰＤＰ１６０ｂはＥＲ−ＲＸ１５８の新しい仮想プール能力値をインストールする。ＥＲ−ＲＸ１５８の許可制御ブロック１８２は各新しい仮想プール能力値を各仮想プール内の現在予約されている資源の量と比較する。もし新しい仮想のプール能力値が各仮想プールから現在予約されている資源の量よりも大きいときは、ＥＲ−ＲＸ１５８の許可制御ブロック１８２は、仮想プール能力値を新しい値で上書きし、直ちにＰＤＰ１６０ｂにＡＣＫ３２４を送信する。しかしながら、もし新しい仮想プール能力の値が現在予約されている資源の量よりも少ないときは、ＥＲ−ＲＸ１５８の許可制御ブロック１８２は、新しい能力値を古い能力値に上書きすることなく保存する。ＥＲ−ＲＸ１５８の許可制御ブロック１８２は予約された資源の量が新しい仮想プール能力より少なくなるまで、更新が実行される仮想プールからの新しい予約を受け付けない。ひとたび予約された資源が新しい仮想プール能力より少なくなったとき、ＥＲ−ＲＸ１５８の許可制御ブロック１８２は、古い仮想プール能力値を新しい値で上書きし、ＡＣＫ３２４をＰＤＰ１６０ｂに送信することによって新しい仮想プール能力値の受け入れを通知する。
【００６９】
[７１］ ＰＤＰ１６０ｂはＥＲ−ＲＸ１５８からＡＣＫ３２４をＰＤＰ１６０ｂが受信するまでＢＲ−ＲＸ１５６の新しいスケジューラの重み付けのインストールを遅延する。ＡＣＫ３２４に応答して、ＰＤＰ１６０ｂは参照番号３２６に例示されているように、ＢＲ−ＲＸ１５６に列設定およびスケジューラ重み付けを押す。新しい列設定およびスケジューラの重み付けが成功裏にインストールされたのち、ＢＲ−ＲＸ１５６がＰＤＰ１６０ｂにＡＣＫ３２８を戻す。
【００７０】
[７２］ 代わりの実施例において、ＰＤＰ１６０ｂはＥＲ−ＲＸ１５８の代わりにいつ仮想プール能力の更新を行うべきかということを決定する。この実施例において、ＰＤＰ１６０ｂは現在予約されたイントサーブ帯域幅のＥＲ−ＲＸ１５８のレポートを求めるか、または、これによる定期的には求められないレポートまたはプログラムする。もし現在予約されている帯域幅が、ＮＭＳによって特定された新しい能力よりも大きいときは、ＰＤＰ１６０ｂはＥＲ−ＲＸ１５８に対して、予約された帯域幅が新しい能力より低くなるまで新しい予約を受け付けるのを停止するポリシを押す。メッセージの量をさらに減らすために、ＰＤＰ１６０ｂはＥＲ−ＲＸ１５８に対して予約された帯域幅が新しい能力よりも少なくなった後でのみＰＤＰ１６０ｂに対して単一の求められないレポートを送信するよう指示する。現在予約されたイントサーブ帯域幅が新しい仮想プール能力よりも少ないということを示すＥＲ−ＲＸ１５８からのメッセージに応答して、ＰＤＰ１６０ｂはＥＲ−ＲＸ１５８に新しいイントサーブ仮想プールポリシを押し、上記した方法でＢＲ-ＲＸ１５６に対応する新しいスケジューラ列および重み付けを押す。
【００７１】
[７３］ もしＰＤＰ１６０ｂがＥＲ−ＲＸ１５８またはＢＲ−ＲＸ１５６のいずれかを更新できないときは、ＰＤＰ１６０ｂは、古い仮想プール能力および列およびスケジューラの重み付け設定に戻してもよい。加えて、ＰＤＰ１６０ｂは失敗の理由（例えば「ＥＲ ＸＸ！に更新された統合されたサービスの仮想プール能力の設定に失敗」または「ＢＲ ＸＸ！に更新されたスケジューラ重みづけを設定するのに失敗」）を述べるためにネットワークオペレータに対して警告メッセージを送信してもよい。
【００７２】
[７４］ ＰＤＰ（例えばＰＤＰサーバ１６０ｂ）が一点において故障とならないように、バックアップＰＤＰが一以上の主要なＰＤＰに利用されてもよい。主要なＰＤＰが故障したときは、イントサーブサービスはＰＤＰをバックアップするよう切り換えられてもよく、主要なＰＤＰによって制御された各ＥＲ−ＲＸはその現在の予約状態をバックアップＰＤＰに報告してもよい。しかしながら、各ＥＲ−ＲＸはバックアップＰＤＰに対する切り換えが完了するまで新しい予約の受付を停止すべできある。主要なＰＤＰが復帰した後、バックアップＰＤＰは主要なＰＤＰとまず同期し、それから各ＥＲ−ＲＸに主要なＰＤＰに戻るよう切り換えることを通知する。主要なＰＤＰに切り換えた後、各ＥＲ−ＲＸはその予約状態を主要なＰＤＰと同期させる。
【００７３】
[７５］ 故障したＥＲまたはＢＲの場合は、ＩＰルーティングおよびＲＳＶＰリフレッシュメッセージが使用されて、故障したＥＲまたはＢＲの周りで新しいルートを発見したり、フローを別の経路に切り換える。別のルートへの切り換えがうまくいくと、ＰＤＰ１６０ｂは、故障したＥＲ−ＲＸに対して、イントサーブトラフィックに割り当てられたディフサーブ列を解放するために対応するＢＲ−ＲＸ１５６に対してポリシを押してもよいし、または、故障したＢＲ−ＲＸのために設定された仮想プールを解放するために故障したＢＲ−ＲＸの下流にあるすべてのＥＲ−ＲＸに対してポリシを押してもよい。
【００７４】
[７６］ 図８Ｃを参照して、ＮＭＳまたはネットワークサービスプロバイダのオペレータが、ＢＲ−ＲＸ１５６で列およびスケジューラ重み付けを直接変更する模範的なシナリオが例示されている。更新に応答して、ＢＲ−ＲＸ１５６は変更をＰＤＰ１６０ｂに通知する。通知に含まれていないときは、ＰＤＰ１６０ｂは参照番号３４２で示されているように、ＢＲ−ＲＸ１５６から設定更新を引出し、それから参照番号３４４で示されているように、すべての影響を受けるＥＲ−ＲＸ（そのうちＥＲ−ＲＸ１５８のみが示されている）上に仮想プール能力の新しい設定を押す。
【００７５】
ＶＩ．結論
[７７］ 今まで述べてきたように、この発明はディフサーブドメインにおいてエッジに基づくイントサーブを実行することによって選択されたフローに対する端末間ＱｏＳを提供する拡張性のあるＩＰネットワークモデルを提供する。ネットワークモデルは、ＣＰＥエッジルータでおいてのみイントサーブＲＳＶＰ処理を利用するフローごとの許可制御と、エッジルータ識別の受信、受信エッジルータでの上流許可制御、プールに基づく資源管理およびポリシ管理による受信境界ルータと受信エッジルータとの間の帯域幅情報の同期を含む、多くの機能をサポートする。追加の機能を導入するにもかかわらず、この発明のネットワークモデルは、既存のイントサーブ、ＣＯＰＳおよびディフサーブモデル、ポリシおよび管理情報ベースを使用したディフサーブポリシ準備と矛盾しない。この発明のネットワークモデルは、標準化されたアーキテクチャを維持しながらも有利に拡張性を高め、それゆえ容易に実行が可能である。
【００７６】
[７８］ 上記したように、この発明の多くの実施例が述べられてきたが、それらは単なる例として示されたものであり、限定ではないと理解されるべきである。このように、この発明の広さおよび範囲は上記の模範的な実施例によって限定されるべきではなく、以下のクレームおよびその均等物によってのみ規定されるべきである。例えば、この発明はまず資源保存型プロトコル（ＲＳＶＰ）およびインターネットプロトコル（ＩＰ）を採用した実施例に関してまず議論されたが、この発明はセッション開始プロトコル（ＳＩＰ）およびＩＴＵ Ｈ．３２３を含む他の通信プロトコルに適応可能である。他の通信プロトコルはポリシおよび利用可能な資源に基づいて、向上されたＱｏＳフローの選択的な許可または拒否によって許可制御を実行するために使用されてもよい。さらに、この発明は選択されたネットワークフローに対して端末間のＱｏＳを達成するために各種機能を実行する各種ハードウエア要素に関して述べられたが、そのような機能はコンピュータ読出し可能媒体において具体化されたプログラムコードの実行を介して実現されうる。ここで使用される「コンピュータ読出し可能媒体」という文言は実行のためにデータ処理システムに対して命令を提供するのに加わる任意の媒体を言う。そのような媒体は多くの形態をとり、限定されるものではないが、不揮発性媒体、揮発性媒体および送信媒体を含む。
【図面の簡単な説明】
【００７７】
[２２］
【図１】ＲＦＣ２２０５に応じて、ＲＳＶＰ信号送信を使用してフローごとのＱｏＳが実行された従来の統合サービス（イントサーブ）のノードの処理モデルを示す図である。
【００７８】
[２３］
【図２】統合されたサービス（イントサーブ）がＲＦＣ２９９８に応じて差別化されたサービス（ディフサーブ）ドメイン上で実行された、従来のネットワークモデルを例示する図である。
【００７９】
[２４］
【図３】この発明の好ましい実施例に従ってディフサーブドメインの境界ルータにおけるイントサーブ処理を除去しながら、ディフサーブドメイン上でイントサーブを実行する高レベルのネットワークモデルを示す図である。
【００８０】
[２５］
【図４】トラフィックフローの受信エッジルータが図３のネットワークモデル内で特定されうる一つの方法を例示する図である。
【００８１】
[２６］
【図５】この発明の好ましい実施例に従った送信エッジルータのより詳細なブロック図である。
【００８２】
[２７］
【図６】この発明の好ましい実施例に従う、受信境界ルータおよび受信エッジルータのより詳細なブロック図である。
【００８３】
[２８］
【図７】この発明の好ましい実施例に従うポリシ決定点（ＰＤＰ）を実行するために使用されてもよい模範的なサーバコンピュータシステムのブロック図である。
【００８４】
[２９］
【図８Ａ】サービス開始時において、受信境界ルータおよび受信エッジルータでのポリシをインストールする好ましい方法を示す図である。
【００８５】
[３０］
【図８Ｂ】図８Ｂはサービス更新に応答して受信境界ルータおよび受信エッジルータでポリシをインストールする好ましい方法を例示する図である。
【００８６】
[３１］
【図８Ｃ】受信境界ルータへの直接のサービス更新に続くポリシ同期の好ましい方法を示す図である。

Claims (47)

1. 上流リンクに接続可能な入力ポートと下流リンクに接続可能な出力ポートとを有するデータ面と、
   制御面とを含み、制御面は、
   上流リンクに接続された上流ルータの資源能力に対応する能力を有する仮想プールと、
   前記入力ポートから前記出力ポートへの前記データ面を介したフローのための資源を予約する要求に応答して、前記仮想プール内で資源の利用可能性を参照して上流リンクのための許可制御を実行する許可制御機能とを含む、ルータ。
2. 前記仮想プールは第一の仮想プールであり、
   前記制御面は第二仮想プールをさらに含み、
   前記第一および第二の仮想プールの各々は、第一および第二サービスクラスのそれぞれの一つに関連し、
   前記許可制御機能は、前記要求によって指示されたサービスクラスに関連する第一および第二の仮想プールの一つにおける資源の利用可能性を参照することによって前記上流リンクの前記フローに対する許可制御を実行する、請求項１に記載のルータ。
3. 前記第一および第二サービスクラスは第一および第二の統合されたサービスのサービスクラスを含み、
   前記要求は統合されたサービスフローに対する資源の予約をするための資源予約プロトコル（ＲＳＶＰ）要求である、請求項１に記載のルータ。
4. 前記許可制御機能と通信する資源予約プロトコル（ＲＳＶＰ）機能をさらに含み、前記資源予約プロトコル（ＲＳＶＰ）機能は前記要求を受信し、前記要求を前記許可制御機能に提供する、請求項３に記載のルータ。
5. 前記許可制御機能は、前記ルータがフローに対する受信エッジルータであるかどうかを判定する手段を含み、前記許可制御ブロックは前記ルータがフローのための受信エッジルータであるという判定に応じてのみ、上流リンクに対して許可制御を実行する、請求項１に記載のルータ。
6. フローの起点が資源予約を要求する権限があるかどうかを判定するポリシ制御をさらに含む、請求項１に記載のルータ。
7. 出力ポートを有するる第一ルータと、
   第一ルータの出力ポートに接続された上流リンクと、
   第二ルータとを含み、第二ルータは、
   上流リンクに接続された入力ポートおよび下流リンクに接続可能な出力ポートを有するデータ面と
   制御面とを含み、制御面は、
   第一ルータの資源能力に対応する能力を有する仮想プールと、
   前記データ面を介した前記入力ポートから前記出力ポートに対するフローに対する資源を予約する要求に応答して、前記仮想プール内で資源の利用可能性を参照して上流リンクに対する許可制御を実行する許可制御機能を含む、ネットワークシステム。
8. 前記仮想プールは第一仮想プールであり、
   前記制御面は第二仮想プールをさらに含み、
   前記第一および第二仮想プールの各々は第一および第二サービスクラスのそれぞれの一つに関連し、
   前記許可制御機能は、前記要求によって指示されたサービスクラスに関連した前記第一および第二の仮想プールの一つの資源利用可能性を参照して、前記上流リンクの前記フローに対する許可制御を実行する、請求項７に記載のネットワークシステム。
9. 前記第一および第二サービスクラスは第一および第二の統合されたサービスのサービスクラスを含み、
   前記要求は、統合されたサービスフローに対する資源予約に対する資源予約プロトコル（ＲＳＶＰ）要求である、請求項７に記載のネットワークシステム。
10. 前記第二ルータは、前記許可制御機能と通信する資源予約プロトコル（ＲＳＶＰ）機能をさらに含み、前記ＲＳＶＰ機能は前記要求を受信して前記要求を前記許可制御機能に提供する、請求項９に記載のネットワークシステム。
11. 前記第一ルータは、転送機能と、各々が異なったサービスの質を提供する複数の列を含み、前記転送機能は統合されたサービスフローのパケットを前記第二ルータに対して送信するための、前記複数の列の多数の異なる列に切り替える、請求項９に記載のネットワークシステム。
12. 前記第一ルータを含む複数の第一ルータを有するサービスプロバイダネットワークをさらに含み、前記複数の第一ルータの各々は、一以上の列を含み、前記サービスプロバイダネットワークの異なった第一ルータは統合されたサービスクラスと前記一以上の列との間で異なったマッピングを同時に実行する、請求項１１に記載のネットワークシステム。
13. 前記第一ルータを含む複数の第一ルータを有するサービスプロバイダネットワークをさらに含み、前記複数の第一ルータの各々は複数の差別されたサービスクラスをサポートする差別化されたサービスルータであり、前記サービスプロバイダネットワークの異なる第一ルータは、統合されたサービスクラスと前記複数の差別化されたサービスクラスとの間で異なったマッピングを同時に実行する、請求項１１に記載のネットワークシステム。
14. 前記許可制御機能はフローに対して前記第二ルータが受信エッジルータかどうかを判定する手段を含み、前記許可制御ブロックは、前記第二ルータがフローに対する受信エッジルータであるという判定に基づいてのみ上流リンクに対して許可制御を実行する、請求項７に記載のネットワークシステム。
15. 前記エッジルータは受信エッジルータを含み、前記ネットワークシステムは送信エッジルータをさらに含み、送信エッジルータは、
    データ面と、
    制御面とを含み、制御面は、
    前記送信エッジルータの下流リンクの資源能力に対応する能力を有する仮想プールと、前記受信エッジルータに対する前記送信エッジルータの前記データ面を介してフローに対する資源を予約するための要求に応じて、送信エッジルータの前記仮想プール内で資源の利用可能性を参照することによって、送信エッジルータの下流リンクに対する許可制御を実行する、請求項１４に記載のネットワークシステム。
16. 前記制御面は、フローの起点が資源予約を要求する権限を有しているかどうかを判定するポリシ制御をさらに含む、請求項７に記載のネットワークシステム。
17. 前記出力ポートに接続された下流リンクと、
    下流リンクに接続された顧客ネットワークとをさらに含む、請求項７に記載のネットワークシステム。
18. 上流リンクに接続された入力ポートと下流リンクに接続された出力ポートとを有するルータの動作方法であって、前記方法は、
    上流リンクに接続された上流ルータの資源能力に対応する能力を有する仮想プールを維持するルータとを含み、
    前記ルータは、前記下流リンクに対して前記ルータを介したフローに対して資源を予約するための要求を受信し、
    前記要求に応答して、前記ルータは前記仮想プール内で資源の利用可能性を参照して上流リンクに対する許可制御を実行する、方法。
19. 前記仮想プールは第一仮想プールであって、
    仮想プールを維持するステップは、第一および第二サービスクラスのそれぞれの一つに各々が関連する第一および第二の仮想プールを前記ルータが維持するステップを含み、許可制御を実行するステップは、前記ルータが前記要求によって指示されたサービスクラスに関連した前記第一および第二の仮想プールの一つにおける資源の利用可能性を参照して、前記上流リンクで前記フローに対して許可制御を実行するステップを含む、請求項１８に記載の方法。
20. 前記第一および第二のサービスクラスは第一および第二の統合されたサービスクラスを含み、
    前記受信するステップは、統合されたサービスフローに対して資源予約プロトコル（ＲＳＶＰ）要求を受信するステップを含む、請求項１９に記載の方法。
21. 前記上流ルータは複数の列を含むデータ面を含み、前記方法はさらに、前記複数の面を使用して複数の統合されたサービスフローに対して複数の異なるサービスの質を提供するステップをさらに含む、請求項１８に記載の方法。
22. 前記第一ルータは、それぞれが一以上の列を有する複数の第一ルータを含むサービスプロバイダネットワークに属し、前記方法は、統合されたサービスクラスと前記複数の第一ルータの異なるクラスで前記一以上の列との間の異なったマッピングを同時に実行するステップをさらに含む、請求項２１に記載の方法。
23. 前記上流ルータは各々が複数の差別化されたサービスクラスをサポートする複数の差別化されたサービスルータの一つを含み、前記方法は、統合されたサービスクラスと、前記複数の差別化されたサービスルータの異なるクラスにおける前記複数の差別化されたサービスクラスとの間で異なったマッピングを同時に実行するステップをさらに含む、請求項２１に記載の方法。
24. 前記ルータがフローに対して受信エッジルータかどうかを判定するステップをさらに含み、前記ルータは、前記ルータがフローに対する受信エッジルータであるという判定に応じてのみ、上流リンクに対して許可制御を実行する、請求項１８に記載の方法。
25. フローの起点が資源予約を要求する権限を有するかどうかを判定することによってポリシ制御を実行するステップをさらに含む、請求項１８に記載の方法。
26. 前記ルータは受信エッジルータを含み、前記方法は、前記受信エッジルータから送信エッジルータへ前記要求を送信するステップをさらに含む、請求項１８に記載の方法。
27. 前記送信するステップは、介在するいずれのルータにおいても許可制御を実行することなく、前記送信エッジルータに対して前記要求を送信するステップを含む、請求項２６に記載の方法。
28. 前記送信エッジルータは、前記送信エッジルータの下流リンクの資源能力に対応する能力を有する仮想プールを維持し、
    フローに対する資源を予約する要求の受信に応答して、前記送信エッジルータは、前記送信エッジルータによって維持された仮想プール内で資源の利用可能性を参照して、送信エッジルータの下流リンクに対する許可制御を実行する、請求項２６に記載の方法。
29. フローの許可に応答して、ルータは下流リンクに接続された顧客のネットワークに対するフローのルーティングを行う、請求項１８に記載の方法。
30. 上流リンクに接続された入力ポートと下流リンクに接続された出力ポートとを有するルータの動作のためのプログラムプロダクトであって、前記プログラムプログラムプロダクトは、
    コンピュータ使用可能媒体と、
    制御プログラムとを含み、制御プログラムは、
    ルータに対して上流リンクに接続された上流ルータの資源能力に対応する能力を有する仮想プールを維持させる命令と、
    ルータに対して前記下流リンクに対して前記ルータを介してフローのための資源を予約する要求を受信させる命令と、
    ルータに対して、前記要求に応答して、前記一以上の資源プール内で利用可能な資源を参照して、上流リンクに対して許可制御を実行させる命令とを含む、プログラムプロダクト。
31. 前記仮想プールは第一仮想プールであって、
    前記ルータに対して仮想プールを維持させる命令は、前記ルータに対して第一および第二サービスクラスのそれぞれの一つに関連した第一および第二仮想プールを維持させる命令を含み、
    前記ルータに許可制御を実行させる命令は、前記ルータに、前記要求によって指示されたサービスクラスに関連した前記第一および第二の仮想プールの一つにおける利用可能な資源を参照して、前記上流リンクで、前記フローに対する許可制御を実行させる命令を含む、請求項３０に記載のプログラムプロダクト。
32. 前記第一および第二サービスクラスは第一および第二の統合されたサービスのサービスクラスを含み、
    前記ルータに対して要求を受信させる命令は、前記ルータに対して統合されたサービスフローに対する資源予約プロトコル（ＲＳＶＰ）要求を受信させる命令を含む、請求項３１に記載のプログラムプロダクト。
33. 前記ルータに対して前記ルータがフローに対する受信エッジルータであるかどうかを判定させる命令をさらに含み、前記ルータは、前記ルータがフローに対する受信エッジルータであるという判定に応じてのみ上流リンクに対して許可制御を実行する、請求項３０に記載のプログラムプロダクト。
34. 前記ルータに対してフローの起点が資源予約を要求する権限を有するかどうかを判定させることによって、ポリシ制御を実行させる命令をさらに含む、請求項３０に記載のプログラムプロダクト。
35. 前記ルータは受信エッジルータを含み、前記プログラムプロダクトは、前記受信エッジルータに対して送信エッジルータに前記要求を送信させる命令をさらに含む、請求項３０に記載のプログラムプロダクト。
36. 前記送信エッジルータに前記送信エッジルータの下流リンクの資源能力に対応する能力を有する仮想プールを維持させる命令と、
    前記送信エッジルータに対して、フローに対する資源を予約するための受信に応答して、前記送信エッジルータによって維持される仮想プール内で利用可能な資源を参照して、送信エッジルータの下流リンクに対する許可制御を実行させる命令をさらに含む、請求項３７に記載のプログラムプロダクト。
37. 前記ルータに対して、フローの許可に応答して下流リンクに接続された顧客ネットワークに対するフローのルートを決定させる命令をさらに含む、請求項３０に記載のプログラムプロダクト。
38. データ格納媒体と、
    前記コンピュータ使用可能媒体内で符号化された仮想プールデータ構造を含み、前記仮想プールデータ構造は、仮想プール能力に対応する資源能力を有する上流境界ルータを含むデータネットワークの出口エッジルータの仮想プール能力を特定し、前記仮想プール能力は、一以上のサービスクラスで前記上流境界ルータからのトラフィックによって前記出口エッジルータで予約されてもよい、最大予約可能帯域幅を特定し、前記仮想プールデータ構造はデータネットワークの上流境界ルータで前記仮想プール能力を関連づける、データ格納装置。
39. 前記仮想プールデータ構造は、前記一以上のサービスクラスのどれが仮想プール能力からそれらに割り当てられた資源を有しているかを特定するサービスクラスフィールドをさらに含む、請求項３８に記載のデータ格納装置。
40. 前記仮想プールデータ構造は、特定された仮想プール能力からの資源を要求する予約要求が出口エッジルータの許可制御機能によって処理されるかどうかを示す予約フィールドをさらに含み、請求項３８に記載のデータ格納装置。
41. 前記コンピュータ使用可能媒体内で符号化された資源能力データ構造をさらに含み、前記資源能力データ構造は、データネットワークの境界ルータのデータ面内で前記一以上のサービスクラスの各々に割り当てられた資源能力を特定し、前記資源能力データ構造は、前記資源能力をデータネットワークの下流出口エッジルータの一以上の仮想プール能力に関連づける、請求項３８に記載のデータ格納装置。
42. 前記仮想プールデータ構造は、関連したエッジルータに対する仮想プール能力を各々が特定する複数のエントリを含み、前記データ格納装置は前記仮想プール能力の最大集合を特定する前記コンピュータ使用可能媒体内で符号化された境界資源データ構造をさらに含む、請求項３８に記載のデータ格納装置。
43. 前記コンピュータ使用可能媒体内で符号化されたプール使用データ構造をさらに含み、前記プール使用データ構造は、仮想プール能力の現在予約された部分を示す、請求項３８に記載のデータ格納装置。
44. データ格納媒体と、
    前記コンピュータ使用可能媒体内で符号化された相互作用機能データ構造を含み、前記相互作用機能データ構造は、一以上の統合されたサービスのサービスクラスの入来フローをルーティングする入り口エッジルータのための複数の差別化されたサービストラフィック制御パラメータを特定し、前記トラフィック制御パラメータは、少なくともマーキングパラメータとスケジューリングパラメータとを含む、データ格納装置。
45. 前記トラフィック制御パラメータは取り締まり（policing)パラメータをさらに含む、請求項４４に記載のデータ格納装置。
46. データ格納媒体と、
    前記コンピュータ使用可能媒体内で符号化されたエッジルータ識別データ構造とを含み、前記エッジルータ識別データ構造はデータネットワークのルータをルータが受信エッジルータであるための一以上のネットワークアドレスと関連づける、データ格納装置。
47. データ格納媒体と、
    前記コンピュータ使用可能媒体内で符号化されたプール使用データ構造とを含み、前記プール使用データ構造は、仮想プール能力に対応する資源能力を有する上流境界ルータを含むデータネットワークの出口エッジルータのための仮想プール能力の現在予約されている部分を示す、データ格納装置。

Images