JP2006505187A - Ｉｐネットワーク内においてリソースを予約する方法および装置 - Google Patents

Abstract

本発明は、ＩＰネットワーク内においてネットワーク・リソースの事前割り付けを行うための方法に関する。予約されるリソースを、利用可能な使用履歴統計がそのリソース予約要求に適用可能な場合には、その使用履歴統計を基礎として割り付ける。適用可能な使用履歴統計が利用可能でない場合には、要求されたリソース予約について個別にネットワーク・リソースを割り付け、個別に割り付けたリソースの結果を基礎として使用履歴統計を更新する。また本発明は、この方法が具体化されるリソース・マネージャ、および本発明に従った方法のステップを実行するコンピュータ・プログラム・プロダクトにも関係する。

Description

本発明は、インターネット・プロトコル（ＩＰ）ネットワーク内におけるリソース・マネージャ、およびＩＰネットワーク内におけるネットワーク・リソースを割り付けるための方法、および当該方法のステップを実行するためのコンピュータ・プログラム・プロダクトに関する。

特に本発明は、ＩＰネットワーク内において、あらかじめネットワーク・リソースを割り付けるための方法、および当該方法のステップを実行するためのコンピュータ・プログラム・プロダクトならびにリソース・マネージャに関する。

現在のネットワークの傾向は、「ＩＰオール・ザ・ウェイ」をワイヤードならびにワイヤレス・ユニットに提供することへ向いている。いくつかの現在の目的は、ネットワーク・インフラストラクチャを単純化し、広範なアプリケーションをサポートし、かつ通信サービスに係る多様なユーザ要求をサポートすることである。これを可能にするためには、サービスの差別化ならびに動的リソース・マネジメントをＩＰネットワーク内においてサポートするスケーラブルな解決策が必要とされている。

インターネット・プロトコルが設計されたときの主要目標は、現存するネットワークを相互接続するための効果的なテクニックを提供することであった。この相互接続を可能にするためになされた１つの設計上のトレード−オフは、ネットワーク・レベルにおいて単にベスト−エフォート・サービスだけをサポートすることであり、サービスの種々のレベルの獲得をエンドポイント機能に頼っている。ベスト−エフォート・サービスは、パスに沿った遅延、損失、およびスループットの変動を許容することのできる伝統的なデータ・アプリケーションのための適切なサポートを提供する。しかしながら、高いトラフィック負荷を担うネットワークにおいては、しばしば、このタイプのサービスが、よりパケットの損失ならびに遅延に対して敏感な、たとえば電話、ビデオ・オン・デマンド、マルチメディア会議等といったアプリケーションの要求を満たすために充分なものとならない。これらのタイプのアプリケーションは、ベスト−エフォートが提供できるものより信頼性の高いリソース割り付けを要求する。

したがって、ネットワーク・オペレータならびに装置プロバイダが、ＩＰネットワーク内においてＱｏＳ（Ｑｕａｌｉｔｙ−ｏｆ−Ｓｅｒｖｉｃｅ（クォリティ−オブ−サービス）；サービスの質）の差別化を提供する強い商業的理由が存在する。言い換えると、ネットワーク内のユーザは、それぞれの優先順位に応じて異なるグループに分割され、たとえば高い優先順位を有するユーザには、低い優先順位を有するユーザより可用性の高いリソースが提供される。

ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（リソース・リザベーション・プロトコル））は、パスに沿って、ＩｎｔＳｅｒｖ（イントサーブ；Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ（インテグレーテッド・サービセズ）；ブラデン（Ｂｒａｄｅｎ）ほか著「インテグレーテッド・サービセズ・イン・ジ・インターネット・アーキテクチャ：アン・オーバービュー（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ ｉｎ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ａｒｃｈｉｔｅｃｔｕｒｅ：ａｎ Ｏｖｅｒｖｉｅｗ）」（ＩＥＴＦ，ＲＦＣ１６３３）に定義されている）をサポートするルータ内においてフロー毎ＱｏＳをセットアップするシグナリング・プロトコル標準である。ＲＳＶＰ内においては、すべてのリソース要求がエンド・ツー・エンドでシグナリングが行われ、その結果、大量のシグナリングを招くことになる。

ルータ内におけるフロー毎ＱｏＳマネジメントのスケーラビリティ問題は、ブレイク（Ｂｌａｋｅ）ほか著「アン・アーキテクチャ・フォア・ディファレンシエイテッド・サービセズ（Ａｎ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ）」（ＩＥＴＦ，ＲＦＣ２４７５）に定義されている差別化されたサービスのアーキテクチャを結果としてもたらした。目的は、ルータ内におけるフロー毎状態を回避することによってスケーラブルＱｏＳのサポートを提供することである。基本的なアイディアは、ＩＰパケット・ヘッダが、ルータによってそのパケットに与えられるべきホップ毎挙動の扱いを識別する小さいラベル（ｄｉｆｆｓｅｒｖ（ディフサーブ）フィールドとして知られている）含むというものである。しかしながら、標準モデルは、ルータ内における差別化された転送に限定され、したがってエンド・ユーザに対して予測可能なサービスを提供するという難題が残されている。

動的アドミッション・コントロールを実行するエンティティを、ここではリソース・マネージャと呼び、さらに詳しくはウルフ，Ｌ．Ｃ．（Ｗｏｌｆ，Ｌ．Ｃ．）、デルグロッシ，Ｌ．（Ｄｅｌｇｒｏｓｓｉ，Ｌ．）、シュタインメッツ，Ｒ．（Ｓｔｅｉｎｍｅｔｚ，Ｒ．）、シャラー，Ｓ（Ｓｃｈａｌｌｅｒ，Ｓ）、ウィッティグ，Ｈ．（Ｗｉｔｔｉｇ，Ｈ．）著「イッシューズ・オブ・リザービング・リソーセズ・イン・アドバンス（Ｉｓｓｕｅｓ ｏｆ Ｒｅｓｅｒｖｉｎｇ Ｒｅｓｏｕｒｃｅｓ ｉｎ Ａｄｖａｎｃｅ）」（ＩＢＭヨーロピアン・ネットワーク・センター・ハイデルベルグ（ＩＢＭ Ｅｕｒｏｐｅａｎ Ｎｅｔｗｏｒｋ Ｃｅｎｔｅｒ Ｈｅｉｄｅｌｂｅｒｇ）、ＴＲ ４３．９５０３、１９９５年）に述べられている。リソース・マネージャは、利用可能な伝送リソース、たとえば帯域幅を常に追跡し、クライアントから到来するリソースに関する要求に対するアドミッション・コントロールを実行する。リソース・マネージャは、１つのドメイン内においてリソースをマネージする。アドミッション・コントロールを実行するために、リソース・マネージャは、以前に取得を認めたリソース予約の履歴のストアも行う。リソース・マネージャは、利用可能なリソースの総量、以前の予約によって現在予約されているリソースの量、および要求されたリソースの量を基礎としてリソースに関する新しい要求を認める決定を行う。リソースは、時間にわたってスケジュールされることもあれば、スケジュールされないこともある。１つの要求が、複数の、異なるタイプのリソースから構成することができるリソース・リポジトリに対するアドミッション・コントロールを必要とすることもある。マネージされるもっとも一般的なタイプのリソースは、帯域幅である。

リソース・マネジメント・メカニズムには、特殊な要件が存在する。サービスをエンド・ユーザへ提供するために、これらのメカニズムは、ネットワーク・リソースを知っていなければならず、また委ねられたサービスについて、それらのスケジュールを任意の粒状度（たとえば、ポート・レンジについて、サブネットのペアの間の統合トラフィックについて等）において行うことができる。

これらのメカニズムは、リーフ・ドメインならびにコア・ドメインの両方において正確なリソース・コントロールを提供する必要がある。リーフ・ドメインにおいては、非常に細かい粒状度（たとえば、アプリケーション・データ・ストリームごと）のリソース・コントロールのための要件が存在することがあり、特に、帯域幅が非常に貴重でありスペクトル効率がほとんど包括的な目標ともなるライセンスされた帯域のワイヤレス・アクセスにおいてそれが当てはまる。パフォーマンスもまた、モビリティおよび周波数のハンド−オーバに充分なものでなければならない。コア・ドメイン内においては、動的に統合される（たとえば、ディスティネーション・ドメインごと、ＩＰ電話用ポート・レンジごと等）リソース・マネジメントが、スケーラビリティの理由のために提供されることがある。ＩＳＰは、先行予約および時間依存契約（たとえば、時刻、曜日等）を使用することによって互いにバルク帯域幅の交渉を行うためのサポートを必要とする。エンタープライズ・ネットワークにおいては、しばしば、周到に準備されたＬＡＮ、およびボトルネックとなる、サイトの相互接続のためのリースされるラインが存在する。これらは、特定量のリソースを必要とする新しい内部サービス（たとえば、マルチメディア会議）の展開のためのサポートを必要とするが、それらのアプリケーションは、ほかのトラフィックへ不利な影響が過度に及ぶことを回避するべくコントロールされなければならない。

２００２年３月２８日に出願された国際特許出願ＰＣＴ／ＳＥ０２／００６１８号には、即時オープン−エンド要求（リソースが要求された時点でセッションの持続時間が未知である）およびリソースの事前割り付けの要求の混合をどのようにリソース・マネージャが扱うかについて開示されている。

事前割り付けの統計的利得を増加させるために、複数ディスティネーションを、より大きなディスティネーション・プレフィクスへ統合し、オロフ・シェレーン（Ｏｌｏｖ Ｓｈｅｌｅｎ）の博士論文「クォリティ・オブ・サービス・エージェンツ・イン・ジ・インターネット（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ａｇｅｎｔｓ ｉｎ ｔｈｅ Ｉｎｔｅｒｎｅｔ）」（コンピュータ・サイエンス電気・電子工学専攻、コンピュータ通信学部、ルレオ、１９９８年）に紹介されたファンネル・コンセプトを採用することができる。

ファンネル・モデルを伴うアイディアは、リソース・マネージャが、ほかのリソース・マネージャにリソースを求めることができるというものである。異なるソースから同一ディスティネーションへの予約は統合されて、それらがパスに沿って併合されるため、それぞれのリソース・マネージャは、それらの隣接ピアを伴うディスティネーション・ドメイン当たり、多くとも１つの予約を有する。さらに改良したファンネル・コンセプトが、２００１年９月４日に出願されたスウェーデン特許出願第０１０２９２９−７号に記述されている。

最先端技術
現在のところ、リソース・マネージャの仕様ならびに実装について知られているものは非常に少なく、複数のリソース・マネージャを伴う予約、すなわち関係するリソース・マネージャが異なるドメインに属するリソースをマネージする場合にはインター−ドメイン予約と呼ばれる予約を扱っているものはさらに少ない。前述したファンネル・コンセプトは、各インター−ドメイン・ホップ内におけるリソースの過剰割り付けを伴う方法を記述しており、使用統計を基礎としてリソースを事前割り付けする方法については何も述べていない。

Ｐ．パン（Ｐ．Ｐａｎ）、Ｅ．ハフネ（Ｅ．Ｈａｈｎｅ）、およびＨ．シュルツリン（Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ）著「ＢＧＲＰ：ア・ツリー−ベースト・アグリゲーション・プロトコル・フォア・インター−ドメイン・リザベーションズ（Ａ Ｔｒｅｅ−Ｂａｓｅｄ Ａｇｇｒｅｇａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｉｎｔｅｒ−ｄｏｍａｉｎ Ｒｅｓｅｒｖａｔｉｏｎｓ）」（ジャーナル・オブ・コミュニケーションズ・アンド・ネットワークス（Ｊｏｕｒｎａｌ ｏｆ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｎｅｔｗｏｒｋｓ））第２巻、第２号、２０００年６月、ｐ．１５７−１６７）においては、ボーダー・ゲートウェイ・リソース・プロトコル（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｒｅｓｏｕｒｃｅ Ｐｒｏｔｏｃｏｌ）（ＢＧＲＰ）と呼ばれるプロトコルが開発され、状態ならびにシグナリングの観点から、ＲＳＶＰに伴うインター−ドメインのスケーラビリティ問題に対処している。それにおいては、ソース・ドメイン内の境界ルータ（ドメイン境界に近接して配置されるルータ）内において、同一ディスティネーションを伴う予約が統合される。さらにシグナリングを少なくするために、次の２つの拡張が提案されている：
過剰予約、量子化、およびヒステリシス
クワイエット・グラフティングおよびＣＩＤＲラベリング。

過剰予約においては、ソースのリーフ・ドメインがリソースの過剰割り付けを行い、そのため、そのドメイン内における各個別の要求のためにシグナリングを行う必要がない。クワイエット・グラフティングは、それが中間ルータの１つであることを意味しており、『ポピュラーな』ディスティネーションに対してリソースの過剰割り当てを行う。これらの拡張に伴う問題については後述する。

Ｑボーン・シグナリング（ＱＢｏｎｅ Ｓｉｇｎａｌｉｎｇ）ワークグループは、ＳＩＢＢＳと呼ばれるインター−ドメインＱｏＳシグナリングのためのプロトコルの仕様作成を開始した。これらのコンセプトは、ディスティネーションに対するリソースの事前割り付けを包含せず、それに代えてホップごとの各予約要求のシグナリングに頼る。イブラヒム・カリル（Ｉｂｒａｈｉｍ Ｋｈａｌｉｌ）、トルステン・ブロウン（Ｔｏｒｓｔｅｎ Ｂｒａｕｎ）著「インプリメンテーション・オブ・ア・バンドウィズ・プローカ・フォア・ダイナミック・エンド−ツー−エンド・リソース・リザベーション・イン・アウトソースド・バーチュアル・プライベート・ネットワークス（Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｆ ａ Ｂａｎｄｗｉｄｔｈ Ｂｒｏｋｅｒ ｆｏｒ Ｄｙｎａｍｉｃ Ｅｎｄ−ｔｏ−Ｅｎｄ Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ ｉｎ Ｏｕｔｓｏｕｒｃｅｄ Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋｓ）」（ユニバーシティ・オブ・ベルン（Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｂｅｒｎｅ）スイス）においては、エンド−ツー−エンドのアドミッション・コントロールが論じられているが、ほかのドメインに対するリソースの事前割り付けのためのアルゴリズムは与えられていない。Ｖ．サンダー（Ｖ． Ｓａｎｄｅｒ）ほか著「エンド−ツー−エンド・プロビジョン・オブ・ポリシー・インフォメーション・フォア・ネットワークＱｏＳ（Ｅｎｄ−ｔｏ−Ｅｎｄ Ｐｒｏｖｉｓｉｏｎ ｏｆ Ｐｏｌｉｃｙ Ｉｎｆｏｒｍａｔｉｏｎ ｆｏｒ Ｎｅｔｗｏｒｋ ＱｏＳ）」（ザ・ユニバーシティ・オブ・シカゴ（Ｔｈｅ Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｃｈｉｃａｇｏ）、シカゴ）においては、異なるリソース・マネージャ間のインター−ドメイン予約ならびにシグナリングが論じられており、主として２つのシグナリング・モデルについて論じられている。しかしならがら、シグナリングを低減するためのリソースの事前割り付けは考慮されていない。

もっとも一般的なタイプの事前割り付けは、隣接リソース・マネージャ間におけるリソースの静的な量であり、マニュアル構成される。これはしばしば、２つの近隣リソース・マネージャの間のサービス・レベル合意の一部となる。

多くの予約の過剰割り付けならびに一括統合は、アドミッション決定がローカライズされることからパフォーマンスおよびスケーリング問題を解決する。ほかにとり得る案、すなわち各アドミッション決定のための複数のリソース・マネージャを必要とする代替案は、パフォーマンスを低下させ、遅延を増加させ、またすべての関連するリソース・マネージャ内に状態毎予約を導くことがある。

ホップごとのリソースの過剰割り付けを使用するすべての方法に伴う１つの問題は、多くのリソース・マネージャのホップにわたる予約が、それぞれのホップごとに過剰割り付けされ、その結果、各ホップのために過剰割り付けの増加が招かれることである。たとえば、望ましい量の２倍の予約を行う過剰割り付けアルゴリズムが使用された場合においては、パスに沿って予約される合計量は、ホップの数に伴って指数関数的に増加することになり、言い換えるとすでに過剰割り付け済みの要求に対して再三にわたり過剰割り付けが繰り返される。図２には、クライアントを包含する第１のドメイン２００、およびリソース・マネージャＲＭ４を包含する第２のドメイン２０４が示されている。クライアントは、第２のドメイン２０４に対し、中間ドメイン２０１、２０２、２０３内にそれぞれ配置されたリソース・マネージャＲＭ１、ＲＭ２、およびＲＭ３を経由してリソースを要求する。このように図２は、過剰予約がホップの数に伴って指数関数的に増加することを例示している。

それに加えて、多くのホップにわたるシグナリングは、クライアントのための応答に長い遅延を招くことがある。

Ｓ．ユーリグ（Ｓ．Ｕｈｌｉｇ）、Ｏ．ボナベンチャー（Ｏ．Ｂｏｎａｖｅｎｔｕｒｅ）著「ＩＳＴプロジェクト・アトリウム・レポートＩ４．２−アナリシス・オブ・インタードメイン・トラフィック（ＩＳＴ Ｐｒｏｊｅｃｔ ＡＴＲＩＵＭ Ｒｅｐｏｒｔ Ｉ４．２−Ａｎａｌｙｓｉｓ ｏｆ Ｉｎｔｅｒｄｏｍａｉｎ Ｔｒａｆｆｉｃ）」（テクニカル・レポート、２００１年）によれば、ネットワーク使用はしばしば時刻、曜日等について周期的であり、特にクライアントが何らかの地理的な局在性を有する場合にそれが当てはまる。サービスに関する代表的な使用は、たとえば図３のグラフに示されている使用に類似すると見られる。図３に示されている使用をカバーするべくリソースの静的な量をマニュアルで割り付けるためには、ピーク使用に等しいレベルが割り付けられなければならない。実際にこの場合においては、使用における変動ならびに散発的なピークが静的なレベルによってカバーされることを保証するために、より多くのリソースを割り付けなければならない。ここで注意する必要があるが、より低い使用の期間（たとえば、この例の場合であれば夜間）においては、この種の静的な過剰割り付けは、大量の不使用リソースを招くこと、すなわち低い利用度を招くことになる。

利用度を増加させる１つの方法は、割り当て済みリソースの『静的』レベルを時間ごとにマニュアル修正する方法であるが、これは非常に時間を要することになる。リソースが必要とされるときに、レベルの修正を自動的に行うことも可能であるが、必要とされるリソースが利用可能であるという保証がないことから冒険を伴う。したがって、あらかじめリソースの事前割り付けを可能にする方が好ましい。この例においては、異なる時刻に異なるレベルを伴うまる１日について、以前の使用履歴が利用可能であれば、好ましくはその種の使用履歴を基礎として事前割り付けが行われる。

図４は、一例として１日分を遡る使用履歴を左側に、および現在の予約済みリソースを右側に示している。この例においては、たとえばＩＰ電話アプリケーションからの大量の短期の即時予約が存在し、さらにいくつかの予約が、たとえばマルチパート会議のためにあらかじめなされている。これらの即時予約が極めて短い（約数分）ものとなり得ることを前提にすると、単に現在の予約（図の右側）に注意を向けることによって、必要なリソースをあらかじめ予測することは困難となろう。

時間的に遡って注目するだけで、各時間当たりどの程度のリソースが実際に予約されたかについて知ることが可能である。このように、あらかじめリソースを割り付けることを可能にするためには、使用履歴が重要である。大量の事前予約が存在する場合であっても、クライアントが遠い未来より近い未来により多くの予約を行う傾向にあることから、必要なリソースを予測することは困難になる。

図４に示されている例においては、到来する日のために必要となるリソースについて、図５に図示されているとおり、前日の使用履歴を基礎として事前割り付けを行うことができる。図５内の矢印は、リソースの要求が使用履歴を基礎として予測されたところを示している。この例においては、各単位時間に関するリソースの事前割り付けが、前日の対応する単位時間の使用履歴を基礎としている。この種の履歴のみに基づく事前割り付けは、静的割り付けより良好な利用度を提供するが、変化した使用パターンに使用履歴を適合させることが不可能であることから、使用パターン内の散発的ピークならびに変動を非常に良好に扱うとは言えない。たとえば、あるクライアントが、利用可能な使用履歴統計に対応しないリソースの予約を要求した場合に、統計が要求を基礎としていない限り、その要求が認められることはなく、利用可能な統計の更新がなされることもない。別の例として、開始時に利用可能な使用履歴統計が存在しないことが挙げられる。つまり、以前の使用統計を基礎として割り付けできるリソースが存在せず、このことは可能性のある唯一の利用可能な使用統計は要求を基礎とすることを含意している。しかしながら、実際に認められ、使用されたリソースを基礎とせず、要求されたリソースのみを基礎とする使用履歴は、クライアントが、リソース・マネージャによって認められるまで同一のリソースのための多くの要求を行ったということもあり得るため、しばしば誤りをもたらす。

欧州特許ＥＰ １０３５６６６ Ａ２号は、リソースを予約するための装置を開示している。この装置は、アクティブ・セッションを監視し、近い未来において予測される変化を基礎として予約の調整を行う。この欧州特許ＥＰ １０３５６６６ Ａ２号の欠点は、あらかじめリソースを予約できないこと、すなわちそのセッションが開始される前、たとえば１日先行して午後７時〜８時の間にリソースを予約できないことである。

したがって本発明は、変化する使用パターンに対して極少のシグナリングを伴って自動的に適合され、しかも高い利用度をもたらす、あらかじめネットワーク・リソースを割り付けるリソース・マネージャならびにその方法を提供することをその目的とする。

上記の目的は、独立請求項の特徴部分に示されたリソース・マネージャ、方法、およびコンピュータ・プログラム・プロダクトによって達成される。

好ましい実施態様は、従属請求項の中に示されている。

本発明に伴う利点は、アルゴリズム１を使用することによってあらかじめリソースを予約できるようになることであり、言い換えると、リソースを予約するセッションが開始される前にである。さらに、セッションのために意図されたリソースの予約を行うこと、たとえば１日先行して午後７時〜８時の間にリソースを予約することも可能である。予約されるリソースに選択される量は、その時間期間に関する使用統計を基礎とする。その結果、すべてのリソース予約の主要な部分を、このように取り扱うことができる。しかしながら、ネットワーク使用に変化を生じる別の状況も存在し、たとえば散発的なピーク使用がある。したがって、その種の変化を取り扱うことのできるアルゴリズム２が導入されている。このように、アルゴリズム１および２が同時並列に作用し、それにおいてアルゴリズム１は、使用履歴を基礎とし、アルゴリズム２は現在のリソース要求ならびに近い未来のリソース要求を基礎とする。

本発明に伴う別の利点は、本発明に従って組み合わされたアルゴリズム１および２が、リソース・マネージャ間におけるエンド−ツー−エンド・シグナリングを低減することであり、したがってローカル決定を採用することによってアドミッション・コントロールの速度を向上させることである。これは、クライアントのための要求から応答までの平均的遅延も短縮することになる。正常オペレーションにおいては、数万のインター−ドメイン予約要求を、単一のインター−ドメイン事前割り付けリソースへ統合することができる。これもまた、パスに沿って別のリソース・マネージャ内にストアされる必要のある状態を低減する。

本発明に伴うこのほかの利点は、この解決策が、使用パターンの任意の周期性に対する適合によって利用度を増加し、かつリソースが必要とされる時点においてそれらが利用可能となるように、あらかじめリソースの事前割り付けを行うことによってサービスの可用性が増加することである。

図１は、本発明を具体化することのできるＩＰネットワーク１００を例示している。ネットワーク１００は、少なくとも１つのネットワーク・ドメインＡ；Ｂ；Ｃ、少なくとも２つのリソース・マネージャａ；ｂ；ｃ；ｄを包含し、それにおいてリソース・マネージャａ；ｂ；ｃ；ｄは、同一ネットワーク・ドメイン内、もしくは異なるネットワーク・ドメイン内に置かれる。各ネットワーク・ドメインは、複数のルータ、エンドポイント（たとえば、コンピュータ、ＩＰ電話等）および互いに接続されるサーバ（図１には図示されていない）を包含することができる。しかしながら各ドメインは、少なくとも１つのリソース・マネージャａ；ｂ；ｃ；ｄを包含し、複数のサーバもしくはルータの１つの中にそれが実装されている。これらのリソース・マネージャは、互いに通信１０９〜１１４を行うべく適合されている。

変化する使用パターンに対して極少のシグナリングを伴って自動的に適合され、しかも高い利用度をもたらす、リソースの事前割り付けの問題に対する解決策は、本発明に従って、並列に作用する第１のアルゴリズムおよび第２のアルゴリズムを組み合わせることである。これらのアルゴリズムは、クライアントから、もしくは第２のリソース・マネージャからリソース予約要求を受け取り、さらに第３のリソース・マネージャにリソースを要求する第１のリソース・マネージャによって使用される。また、要求されるリソースを、第１のリソース・マネージャ自体が必要とするということも可能である。したがって、要求されたリソースが認められた場合に第１のリソース・マネージャは、要求エンティティに対して、すなわちクライアント、第２のリソース・マネージャ、もしくは第１のリソース・マネージャ自体に対してリソースを割り付ける。

簡単に述べれば、第１のアルゴリズムは時間的に後方に注目し、第２のアルゴリズムは前方に注目する。言い換えると第１のアルゴリズム、すなわちアルゴリズム１は、リソース使用の履歴統計を使用する。この統計は、いつ、どの程度のリソース要求が実際に認められ、かつ予約されたかを記述し、さらに到来する要求を予測し、予測されたリソース要求の事前割り付けをあらかじめ行う。第１のアルゴリズムは、リソースを使用するセッションが開始される前にリソースを前もって予約するために使用される。

第２のアルゴリズム、すなわちアルゴリズム２は、有効な使用履歴統計が使用できないとき、各リソース予約について個別にネットワーク・リソースを割り付けるのでアルゴリズム１によって割り付けられる事前割り付けリソースが適切でない。それに加えてアルゴリズム２は、アルゴリズム１の中で使用される上記の使用履歴統計を、個別に割り付けたリソースに基づいて更新する。

以前に使用されていないディスティネーションが使用されようとしていること、あるいはシステムが使用履歴を伴うことなく開始されたことのいずれかに起因して利用可能な以前の使用統計がまったく存在しない場合には、アルゴリズム１が、いずれかのリソースの事前割り付けを行うことはなく、したがってアルゴリズム２が、受け取った各予約要求について個別にシグナリングを行わなければならない。しかしながら、アルゴリズム２によるリソース割り付けからもたらされる結果が、アルゴリズム１用の使用履歴統計のために収集される。時間の経過に伴って使用統計の量が増加され、その結果アルゴリズム１が、使用されているディスティネーションに対するリソースの事前割り付けを開始することになる（ディスティネーションは、たとえばアプリケーション、ホスト、ネットワーク・プレフィクス、自律システム（ＡＳ）全体であり、複数のサービスがサポートされている場合には、ネットワーク・サービスに依存することもできる）。時間の経過とともに、アルゴリズム１によって事前割り付けが行われることになるリソースがますます多くなり、まれに現れる散発的な使用のピークだけがアルゴリズム２によって扱われるまでアルゴリズム２によって割り付けられる必要のあるリソースがますます少なくなる。

図６は、統計が構築されるに従って、アルゴリズム１によって割り付けられる、要求されたリソースの合計量がますます増加する様子を示している（曲線６０２）。アルゴリズム２（曲線６０４）を有していない場合には、アルゴリズム１が、その統計の基礎を、認められ、かつ使用されたリソースではなく、要求されたリソースに置かなければならないが、これは、クライアントが１つの必要なリソースに対して複数回の試行ならびに要求を行うことがあるため、誤った結果をもたらすことがある。前述したとおり、これは、開始時に統計が利用できないことに起因し、アルゴリズム２を有していない場合には、要求されるリソースが利用可能なデータだけとなることを含意する統計が収集されない。アルゴリズム１によるリソース割り当ての頻度は、アルゴリズム１が使用することのできる使用統計を構築するためにアルゴリズム２の使用６０４もなされることに起因して、増加６０２を呈する。

使用パターンにおける大きな変化、あるいは前述の例のように統計をまったく伴わない開始は、アルゴリズム２による大量のシグナリングを必要とすることがある。その場合は、アルゴリズム１の適応を高速化する上で統計のマニュアル調整もしくは初期化が望ましいことがある。たとえば、作成した統計を伴ってアルゴリズム１を構成し、その後、真の統計が用意されるまでアルゴリズム１がリソースの割り付けを開始することが可能である。

あらかじめ行われるリソース・マネージャ間のリソースの事前割り付けは、すべてのリソース・マネージャに関連するシグナリングが、各クライアントの予約のために必要とはならないという結果をもたらす。たとえばＩＰ電話システムにおいて、単位時間内に、あるディスティネーションに対して数万の要求が行われることがあり、それの事前割り付けを、リソース・マネージャによって、その単位時間全体について１つの要求だけを使用してあらかじめ行うことができる。ここで注意を要するが、統計は、好ましくはディスティネーションごとのリソース使用を基礎とする。複数のリソース・マネージャが関連する場合には、望ましいディスティネーションへのリソースの事前割り付けを行うために、中間リソース・マネージャが、そのトラフィックのディスティネーションを知っていなければならない。２つの異なるリソース・マネージャの間におけるサービス・レベルの合意を単に調整するだけでは、設定されるべき各予約のために、すべての関連するリソース・マネージャに対するシグナリングが、これまでどおり必要となることから、クライアントから要求されたリソースに適合する上で充分ではない。特定のリソース・マネージャ内においてローカルに事前割り付け済みリソースを有する、本発明に従ったリソース・マネージャは、すべての関連するリソース・マネージャに対するシグナリングを伴うことなく、新しい予約要求を受け入れること、あるいは拒否することについてのローカル決定を行うことができる。これは、アドミッション・コントロールのレートを増加させ、クライアント要求に関する遅延を短縮することになる。

アルゴリズム１は、あらかじめ、たとえば使用履歴統計の周期性に基づいて、時刻、日、週全体等を単位として事前割り付けを行うことができる。前述の例の場合であれば、アルゴリズム１が、リソース・マネージャ間の各シグナリングについて、好ましくは１日先行して割り付けを行い、かつ１時間を単位として割り付けを行う。別の実施態様においては、リソース・マネージャが毎時１回のシグナリングを行い、さらに別の実施態様においてはリソース・マネージャが一度にすべてのリソースの割り付けを行う。アルゴリズム２がリソース予約の誘因ごとにリソースの割り付けを行うことから、アプリケーションならびに使用パターンに応じて、時間当たり多数の（数千の）シグナリングが各ディスティネーションについて生じることがあり、したがってアルゴリズム１が可能な限り多くのリソースをカバーすることが望ましい。

さらに、アルゴリズム２が予約の誘因ごとにリソースを予約し、リソースの過剰割り付けを行わないことから、前述し、かつ図２に示したホップ当たりの過剰割り付けに伴う問題が回避される。

アルゴリズム１は、ディスティネーションごとにリソースの事前割り付けを行う。各割り付けの誘因の間の時間間隔を、すべてのディスティネーションについて等しいものとしてもよく、あるいはディスティネーション間で異なるものとしてもよい。あるディスティネーションについて、複数のサービスもしくはトラフィック需要が存在する場合には、個別のサービスに関する統計を使用してリソースの事前割り付けを行うことができ、それもまたサービス要求に依存する。

以前の使用からストアされた統計は、ピーク値、平均値、変動等を含むことがあり、これらのパラメータを基礎としてリソースの事前割り付けを行う（たとえば、平均＋２×（変動の平方根））べくアルゴリズム１を構成することが可能となる必要がある。事前割り付けの量は、過剰割り付けと、アルゴリズム２によって行われなければならないシグナリングの量の間におけるトレード−オフである。また、先行してリソースが割り付けられるべき時間、および事前割り付けならびに統計の粒状度、たとえばその例において毎時パラメータ当たり１つの値といった粒状度の構成が可能であることが望ましい。各ディスティネーションについてストアされる統計履歴データを低減するために、以前の値に重み付けを行って新しい値としてもよい。一例は、それぞれの新しい日ならびに単位時間について、０．５×（以前の値）＋０．５×（新しい値）を使用することである。この方法によればアルゴリズムが、１日だけ遡る場合に比べて、より緩やかに使用における一時的な変化に適応することになる。別の例は、０．９×（以前の値）＋０．１×（新しい値）の使用であり、その場合には適応が非常に緩やかになる。

次に、本発明に従ったＩＰネットワーク内における割り付けのための方法について、包括的な態様で説明し、図８のフローチャートに例示する。この方法は、以下のステップを含む：
８０１：利用可能な使用履歴統計がリソース予約要求に対して適用可能な場合には、その使用履歴統計を基礎として予約されるリソースの割り付けを行う。
８０２：適用可能な使用履歴統計が利用可能でない場合には、要求されたリソース予約について個別にリソースを割り付ける。
８０３：個別に割り付けたリソースの結果を基礎として使用履歴統計を更新する。

本発明の一実施態様によれば、この方法がリソース・マネージャによって実行され、それにおいてリソース・マネージャは、ＩＰネットワーク内のルータもしくはサーバ内に置かれる。リソース・マネージャは、有効な使用履歴統計７０８が、ネットワーク・リソース予約要求に対して適用可能な場合に、その使用履歴統計７０８を基礎として予約されるネットワーク・リソースの割り付けをあらかじめ行うための手段７０２、適用可能な使用履歴統計７０８が利用可能でない場合に、要求されたネットワーク・リソース予約について個別にネットワーク・リソースを割り当てるための手段７０４、および個別に割り付けを行ったネットワーク・リソースを基礎として使用履歴統計７０８を更新するための手段７０６を包含している。

この方法は、この方法のステップを実行するためのソフトウエア・コード手段を包含するコンピュータ・プログラム・プロダクトを介して具体化することもできる。このコンピュータ・プログラム・プロダクトは、ルータおよび／またはサーバ内の処理手段上において実行される。コンピュータ・プログラムは、直接もしくはコンピュータ使用可能メディアからロードされる。

本発明は、以上の好ましい実施態様に限定されない。各種の変更、修正、および等価物を使用してもよい。したがって以上の実施態様は、付随する特許請求の範囲によって定義される本発明に対する限定として捉えられるべきではない。

本発明を具体化することのできるＩＰネットワークを略図的に示した説明図である。 ネットワーク内の各ホップにおける過剰割り付けを略図的に示した説明図である。 代表的な時刻別の使用パターンを示したグラフである。 使用履歴を左側に、および現在予約されているリソースを右側に示したグラフである。 以前の使用履歴を基礎とする１日のリソースの事前割り付けを示したグラフである。 本発明に従って２つのアルゴリズムによって割り付けられるリソースの量を示したグラフである。 本発明に従ったリソース・マネージャを示したブロック図である。 本発明に従った方法を示したフローチャートである。

符号の説明

１ アルゴリズム
２ アルゴリズム
１００ ネットワーク；ＩＰネットワーク
２００ 第１のドメイン
２０１ 中間ドメイン
２０２ 中間ドメイン
２０３ 中間ドメイン
２０４ 第２のドメイン
６０２ リソースの合計量の増加曲線
６０４ アルゴリズム２の曲線
７０２ 手段
７０４ 手段
７０６ 手段
７０８ 使用履歴統計
１０９ 通信
１１０ 通信
１１１ 通信
１１２ 通信
１１３ 通信
１１４ 通信
ａ リソース・マネージャ
Ａ ネットワーク・ドメイン
ｂ リソース・マネージャ
Ｂ ネットワーク・ドメイン
ｃ リソース・マネージャ
Ｃ ネットワーク・ドメイン
ｄ リソース・マネージャ
ＲＭ１ リソース・マネージャ
ＲＭ２ リソース・マネージャ
ＲＭ３ リソース・マネージャ
ＲＭ４ リソース・マネージャ

Claims (18)

1. ＩＰネットワーク内においてネットワーク・リソースの割り付けを行うための、
   予約されるネットワーク・リソースを、あらかじめ、前記リソースを使用することになるセッションが開始される前に、利用可能な使用履歴統計が前記ネットワーク・リソース予約要求に適用可能であれば、前記使用履歴統計を基礎として割り付けるステップ（８０１）を包含する方法であって、さらに、
   適用可能な使用履歴統計が利用可能でなければ、前記要求されたネットワーク・リソース予約について個別にネットワーク・リソースを割り付けるステップ（８０２）、および、
   前記個別に割り付けられたネットワーク・リソースを基礎として、前記使用履歴統計を更新するステップ（８０３）、
   を包含することを特徴とする方法。
2. さらに、
   使用履歴統計をマニュアル調整するステップ、
   を包含することを特徴とする請求項１に記載の方法。
3. 前記個別に割り付けられるネットワーク・リソースは、予約の誘因ごとに割り付けられる、請求項１〜２のいずれかに記載の方法。
4. 前記割り付けられ、予約されるネットワーク・リソースは、ディスティネーションごとの使用履歴統計を基礎として割り付けられる、請求項１〜３のいずれかに記載の方法。
5. ネットワーク・リソースが使用履歴統計を基礎として割り付けられる各誘因の間の時間間隔は、すべてのディスティネーションについて等しくてもよく、あるいはディスティネーション間で異なってもよいとする、請求項４に記載の方法。
6. 前記予約されるネットワーク・リソースの割り付けは、さらに個別のサービスについての統計を基礎とする、請求項４に記載の方法。
7. 前記使用履歴統計は、ピーク値パラメータ、平均値パラメータ、または変動パラメータのいずれかを包含する、請求項１〜６のいずれかに記載の方法。
8. 前記リソース・マネージャは、前記ＩＰネットワーク内のサーバもしくはルータ内に実装される、請求項１〜７のいずれかに記載の方法。
9. 請求項１〜８のいずれかのステップを実行するためのソフトウエア・コード部分を包含するＩＰネットワーク内のサーバおよび／またはルータ内に直接ロード可能なコンピュータ・プログラム・プロダクト。
10. ＩＰネットワーク内のサーバおよび／またはルータ内の処理手段に請求項１〜８のいずれかのステップの実行をコントロールさせるための可読プログラムを包含するコンピュータ使用可能メディアにストアされるコンピュータ・プログラム・プロダクト。
11. ＩＰネットワーク内においてネットワーク・リソースの割り付けを行うための手段を包含し、
    予約されるネットワーク・リソースを、あらかじめ、前記リソースを使用することになるセッションが開始される前に、利用可能な使用履歴統計（７０８）が前記ネットワーク・リソース予約要求に適用可能であれば、前記使用履歴統計を基礎として割り付けるための手段（７０２）を包含するＩＰネットワーク内のリソース・マネージャであって、さらに、
    適用可能な使用履歴統計（７０８）が利用可能でなければ、
    前記要求されたネットワーク・リソース予約について個別にネットワーク・リソースを割り付けるための手段（７０４）、および、
    前記個別に割り付けられたネットワーク・リソースを基礎として、前記使用履歴統計（７０８）を更新するための手段（７０６）、
    を包含することを特徴とするリソース・マネージャ。
12. 前記リソース・マネージャは、使用履歴統計をマニュアル調整するための手段を包含する、請求項１１に記載のリソース・マネージャ。
13. 前記リソース・マネージャは、前記個別に割り付けられるネットワーク・リソースを予約の誘因ごとに割り付けるための手段を包含する、請求項１１〜１２のいずれかに記載のリソース・マネージャ。
14. 前記リソース・マネージャは、前記割り付けられ、予約されるネットワーク・リソースをディスティネーションごとの使用履歴統計を基礎として割り付けるための手段を包含する、請求項１１〜１３のいずれかに記載のリソース・マネージャ。
15. ネットワーク・リソースが使用履歴統計を基礎として割り付けられる各誘因の間の時間間隔は、すべてのディスティネーションについて等しくてもよく、あるいはディスティネーション間で異なってもよいとする、請求項１４に記載のリソース・マネージャ。
16. 前記ネットワーク・リソースを割り付けるための手段は、さらに、前記ネットワーク・リソース予約の割り付けのために個別のサービスについての統計を使用するための手段を包含する、請求項１４に記載のリソース・マネージャ。
17. 前記使用履歴統計は、ピーク値パラメータ、平均値パラメータ、または変動パラメータのいずれかを包含する、請求項１１〜１６のいずれかに記載のリソース・マネージャ。
18. 前記リソース・マネージャは、前記ＩＰネットワーク内のサーバもしくはルータ内に実装される、請求項１１〜１７のいずれかに記載のリソース・マネージャ。

Images