(57)【要約】  本発明は、ＩＰネットワーク内でリソースを予約する方法および処理に関する。リソースの共有プールを利用して、無期限の予約を事前予約と混在させることにより、リソース稼働率が高くなる。無期限の予約への対応にもかかわらず、本発明はリソースを保証した即時のおよび事前の時間制限付予約を容認する。本発明は、稼動中の、あるいは「今にも稼動する」予約を変更することを可能にし、それはソフトステート型予約を容認することになる。本発明は、種々の時間配分と種々のプリエンプションリスクを持つ異種のアプリケーションをサポートする。無期限の事前予約の新規な概念も本発明に導入されている。
2005522097.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワーク内でネットワークリソースを予約する方法であって、１アプリケーションまたは一群のアプリケーションに対するリソースが、開始時間と終了時間とで規定される時間間隔でリソースマネジャにより予約され、該方法が、前記リソースを前記開始時間と前記終了時間の間保証するステップと、前記終了時間が過ぎた後で、前記アプリケーションがまだリソースを必要としていれば、該アプリケーションのために前記リソースを保持しておくステップとを備えたことを特徴とする方法。
【請求項２】
すべてのリソース予約は共有リソースプールを利用していることを特徴とする特許請求の範囲第１項に記載の方法。
【請求項３】
リソースマネジャは、前記終了時間を過ぎて稼動中の予約のリストを保持していることを特徴とする特許請求の範囲第１項に記載の方法。
【請求項４】
各アプリケーションに対しアプリケーションのクライアントにより個別の開始時間と終了時間が設定されたことを特徴とする特許請求の範囲第１項に記載の方法。
【請求項５】
各アプリケーションに対しリソースマネジャにより個別の開始時間と終了時間が設定されたことを特徴とする特許請求の範囲第１項に記載の方法。
【請求項６】
前記開始時間が現時間に設定されたことを特徴とする特許請求の範囲第１項に記載の方法。
【請求項７】
前記終了時間が現時間に設定されたことを特徴とする特許請求の範囲第６項に記載の方法。
【請求項８】
前記終了時間が無限時間に設定されたことを特徴とする特許請求の範囲第１項から第６項のいずれかに記載の方法。
【請求項９】
前記リソースへの請求が、保証されたリソースの量に基づいていることを特徴とする特許請求の範囲第１項に記載の方法。
【請求項１０】
前記リソースが、帯域幅と関連していることを特徴とする特許請求の範囲第１項に記載の方法。
【請求項１１】
特許請求の範囲第１項から第１０項のステップを実行するソフトウェアコード部分を備えたＩＰネットワーク内のルータまたはサーバの内部メモリに直接ロードできるコンピュータプログラム製品。
【請求項１２】
ＩＰネットワーク内のルータまたはサーバのリソースマネジャに、特許請求の範囲第１項から第１０項のステップの実行を管理させる読取可能なプログラムを備えた、コンピュータで使用できる媒体に格納されたコンピュータプログラム製品。
【請求項１３】
ＩＰネットワーク内でネットワークリソースを予約するリソースマネジャであって、前記リソースマネジャはアプリケーションまたは一群のアプリケーションに対するリソースを開始時間と終了時間とで規定される時間間隔で予約する手段を備え、前記リソースマネジャは、前記リソースを前記開始時間と前記終了時間の間保証する手段と、前記終了時間が過ぎた後で、前記アプリケーションがまだリソースを必要としていれば、該アプリケーションのために前記リソースを保持しておく手段とを備えたことを特徴とするリソースマネジャ。
【請求項１４】
すべてのリソース予約は共有リソースプールを利用していることを特徴とする特許請求の範囲第１３項に記載のリソースマネジャ。
【請求項１５】
前記リソースマネジャが、前記終了時間を過ぎて稼動中の予約のリストを保持する手段を備えていることを特徴とする特許請求の範囲第１３項に記載のリソースマネジャ。
【請求項１６】
前記リソースマネジャが、各アプリケーションのクライアントが前記アプリケーションに対し個別の開始時間と終了時間を設定することを可能にする手段を備えていることを特徴とする特許請求の範囲第１３項に記載のリソースマネジャ。
【請求項１７】
前記リソースマネジャが、各アプリケーションに対し個別の開始時間と終了時間を設定する手段を備えていることを特徴とする特許請求の範囲第１３項に記載のリソースマネジャ。
【請求項１８】
前記リソースマネジャが、前記開始時間を現時間に設定する手段を備えていることを特徴とする特許請求の範囲第１３項に記載のリソースマネジャ。
【請求項１９】
前記リソースマネジャが、前記終了時間を現時間に設定する手段を備えていることを特徴とする特許請求の範囲第１８項に記載のリソースマネジャ。
【請求項２０】
前記リソースマネジャが、前記終了時間を無限時間に設定する手段を備えていることを特徴とする特許請求の範囲第１３項から第１８項のいずれかに記載のリソースマネジャ。
【請求項２１】
前記リソースマネジャが、前記リソースへの請求を、保証されたリソースの量に基づかせる手段を備えたことを特徴とする特許請求の範囲第１３項に記載のリソースマネジャ。
【請求項２２】
前記リソースが帯域幅と関連していることを特徴とする特許請求の範囲第１３項に記載のリソースマネジャ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットプロトコル（ＩＰ）ネットワークに関するものである。
【０００２】
より詳細には、本発明は前記ＩＰネットワーク内でリソースを予約する方法、システムおよびリソースマネジャに関する。
【背景技術】
【０００３】
インターネットプロトコルが設計されたときの第１の目標は、既存ネットワークを相互接続する効率的な技法を提供することであった。別の重要な目標は、故障の際の生存性と、種々のサービスおよびアプリケーションをサポートする一般性であった。これらの目標を達成するため、ＩＰプロトコルは、ネットワークエレメントにおいて信号とフロー毎の状態を要求しないコネクションレス型データグラムネットワークを提供するよう設計された。そのアーキテクチャは、大規模なネットワークにも拡張でき、多数のエンド・トゥ・エンド接続（例えば、ワールドワイドウェブ）を行ってアプリケーションをサポートすることが判明した。
【０００４】
相互接続を可能にするためになされた設計上のトレードオフは、ネットワークレベルではベストエフォート型のサービスのみをサポートし、種々のレベルのサービスを得るためにはエンドポイントの機能に依存するということであった。ベストエフォート型のサービスは、経路上での遅延、損失および種々のスループットを許容することができる伝統的なデータアプリケーションのための適切なサポートを提供する。しかし、高荷重のトラフィックを伝えるネットワークでは、この種のサービスは、パケット損失や遅延に対してより敏感なアプリケーション（例えば、テレフォニ、ビデオオンデマンド、マルチメディア会議等）の要求を満たすには不適切であることが多い。
【０００５】
伝統的に、リアルタイムのアプリケーションを要求することは、その特定のアプリケーション向けに垂直最適化されたネットワークの上に構築されてきた。この設計原理は、それ自体の目的においては効率的であるが、新規のアプリケーションを容易にサポートせず、多くの場合アプリケーションを種々のリソース要求に応じて効率よく多重化することができないネットワークを生む。いくつかの異なるネットワークを並列して稼動させるコストは高くつくことが判明した。
【０００６】
ＩＰは当初から一般的な通信ソリューションとして設計されていた。ＩＰ技法は、安価であるとともに、伝統的なデータアプリケーションと、遅延に対して敏感なリアルタイムアプリケーションの両方をサポートするのに適切であることが今や認識されている。リアルタイムアプリケーションのために期待されるサービスを提供するためには、論理的に（および物理的に）離れたＩＰネットワークが使用される。各ＩＰネットワークは、非常に予測のつきやすいリソース要求を持つ、敏感なアプリケーション（例えばテレフォニ）の部分集合のみにサービスを提供する。アプリケーションの範囲を制限することにより、総リソース要求が予測可能となり、その結果、ネットワークを垂直最適化型ネットワークに用いられているのと同じトラフィックモデルを用いて必要な大きさにできる。動的なサービスの配備のサポートをＩＰ技法に要求せずとも、安価なＩＰ機器の恩恵を得ることができる。
【０００７】
ネットワーク運営者は現在、いくつかの並列ネットワークを維持する一般管理費を削減しようとしている。現在の動向の1つは、種々のネットワークサービス要求を持つ全種のアプリケーションを、同一の論理的ＩＰネットワーク（すなわち、インターネット）で運用することによりインフラストラクチャを簡素化することである。このことは、ＩＰネットワークにおけるアプリケーション異質性が増加していることを意味する。
【０００８】
無線アクセス技法はネットワークの辺縁でボトルネックを被り得る。1つのトレンドは、グローバルエリア・ライセンスバンド（例えば、ＧＳＭ、ＧＰＲＳ、ＵＭＴＳ）のための無線アクセス技法が、純粋な接続志向型から「オールＩＰ化」（IP all the way）に向けて移行してきていることである。これらのネットワークは、次世代版であっても、有線ＩＰネットワークに比べると比較的リソースに制約がある。これらのネットワークの手動操作機器は伝統的に人間の対話（例えば、音声）のためのリアルアイムアプリケーションを提供するが、それらは現在複数のアプリケーションを提供する方向に移行してきている。アプリケーションの異質性とリンクの異質性に加えて、ユーザのコミュニティーが、サービスに期待するものやサービスに対する支払い意欲（例えば、職業的ユーザやホーム・エンタテイメントのユーザ）において、より異質的になってきている。これらすべてのトレンドが、ユビキタスな複合サービスネットワークになりつつあるインターネットの方角に向いている。つまり、ネットワーク運営者や機器供給者がＩＰネットワークでサービスの品質（Quality of Service, ＱｏＳ）の差別化を提供すべき強力な商業的根拠が存在する。
【０００９】
研究・標準化団体では、ＱｏＳサポートの開発は、インターネットの信号型ソリューション（水平型ネットワークに用いられるソリューションと幾分類似したもの）を提供することから進展し、今ではよりステートレス（stateless）なソリューションが有利であるということを認識するに至っている。ＲＳＶＰ（リソース予約プロトコル）は、経路上でイントサーブ（Integrated Services、統合型サービス）をサポートするルータにおいてフロー毎のサービスの品質を設定するように標準化された信号プロトコルである。イントサーブは、ブラーデン（Braden）らによる「インターネットアーキテクチャにおける統合型サービス:概要」（Integrated Services in the Internet Architecture: an Overview）、インターネット技術標準化委員会（Internet Engineering Task Force, IETF）、ＲＦＣ１６３３に記載されている。経路上の各ルータは許可制御を行い、次いで個別アプリケーションのデータストリームを承認して期待されるサービスを提供する。このモデルは複雑すぎてインターネットの基幹に使われるようには拡張できないと議論されている。このモデルを、ネットワークに近いところまで使用を十分拡張できるとの主張もあった。
【００１０】
ルータにおけるフロー毎のＱｏＳ管理の拡張性の問題は、ＩＥＴＦで取り組まれている、ブレーク（Blake）らによる、「差別化型サービスのためのアーキテクチャ」（An Architecture for Differentiated Services）、ＩＥＴＦ、ＲＦＣ２４７５として知られる新たな手法を生んだ。その目的は、ルータでのフロー毎の状態を避けることにより、拡張性のあるＱｏＳサポートを提供することにある。基本概念は、ＩＰパケットのヘッダーが、パケットがルータから与えられるべき処理（ホップ毎の動作）を識別する小ラベル（ディフサーブ・フィールドとして知られる）を含むということである。結果として、基幹ルータにはいくつかのフォワーディング・クラスが設定されており、ラベルは、パケットをこれらのクラスにマッピングするために用られる。このアーキテクチャは、ネットワーク境界でのパケットマーカーおよび整理機能に依存して、意図したサービスの提供を確保する。
【００１１】
差別化型サービスの1つの利点は、インターネットを成功させた有利な特性をこのモデルが保持していることである。つまり、このモデルは、様々な種類の相互接続された物理的ネットワークを介した拡張性のある、ステートレスなフォワーディングをサポートする。しかし、標準型モデルは、ルータでの差別化型フォワーディングに制限されており、そのため、課題としては、エンドユーザに予測可能なサービスを提供することである。
【００１２】
定量的サービス（ベストエフォート型サービスよりは良いが、トラフィックの送信場所と、その時点で他で負担している負荷に依存している）の提供は、ルータでのディフサーブサポートと、半静的な許可制御とサービス提供のためのリソース管理機構のみに頼って行うことができた。定量的な（最低期待度の）サービスを提供するためには、リソースをリソース管理機構により動的に管理しなければならず、約束したサービスを提供するために十分なリソースがネットワーク内にあることを確認する動的な許可制御を必要とする。
【００１３】
リソースマネジャ
動的な許可制御を実行する実体を、ここでは、例えばＬ．Ｃ．ウルフ、Ｌ．デルグロッシ、Ｒ．スタインメッツ、Ｓ．シャラー、Ｈ．ウィッティグ（Wolf, L. C., Delgrossi, L., Steinmetz, R., Schaller, S., Wittig, H.）による、「リソースを事前予約する問題」（Issues of Reserving Resources in Advance）、ＩＢＭ欧州ネットワークセンター、ハイデルベルグ（IBM European Network Center Heidelberg）ＴＲ４３．９５０３、１９９５に記述されているようなリソースマネジャと呼ぶ。この実体は利用可能なリソースを常時監視し、クライアントから入ってくるリソース要求への許可制御を行う。許可制御実行のため、リソースマネジャは以前に許可されたリソース予約の履歴をも保存している。リソースマネジャは、新たなリソース要求を許可する決定を、利用可能なリソースの総量と、事前予約により現在予約済の量と、要求されたリソースの量とに基づいて決定する。リソースは長期にわたってスケジューリングされてもよいし、そうでなくてもよい。1つの要求が、異なる種類のリソースから構成され得る複数のリソースリポジトリへの許可制御を包含してもよい。帯域幅は、最も一般的な種類の管理対象リソースである。
【００１４】
リソース管理機構には特定の要求事項がある。エンドユーザにサービスを提供するためには、リソース管理機構はネットワークリソースについて認識していなければならず、約束したサービスに対しリソースを任意の精度（例えば、ポート範囲に関して、一対のサブネット間の集約トラフィックに関して）でスケジューリングする。この機構はリーフドメインとコアドメイン両方での精密なリソース管理を提供できなければならない。リーフドメイン、特に、帯域幅が非常に高価なためスペクトル効率が総合的な目標であるライセンスバンド無線アクセスでは、非常に細密な精度のリソース管理（例えば、アプリケーション毎のデータストリーム）への要求があり得る。その性能は、移動性と頻繁におこる譲渡を処理するのに十分でなければならない。
【００１５】
コアドメインでは、動的な集約リソース管理（例えば、宛先ドメイン毎、ＩＰテレフォニ用のポート範囲毎、等）を拡張性の理由で配設してもよい。インターネット・サービス・プロバイダー（ＩＳＰ）は、Ｃ．シュア、Ｌ．サブラマニアン、Ｒ．カッツ、Ａ．ジョゼフ（C. Chuah, L. Subramanian, R. Katz, and A. Joseph）による、「クリアリングハウスアーキテクチャを用いたＱｏＳの配備」（QoS provisioning using a clearing house architecture）（２０００年６月、於ペンシルバニア州ピッツバーグ、ＩＷＱｏＳ２０００予稿集）に記載されているように、事前予約と時間依存性契約（例えば、時刻、曜日）を用いた大量帯域幅を交渉するサポートが必要である。企業ネットワークでは、きちんと配備されたＬＡＮと隘路リース回線があることが多い。それらは、一定量のリソースを必要とする新たな内部サービス（例えば、マルチメディア会議）を実施するためのサポートを必要とし、これらのアプリケーションのためのリソース要求を管理するために、他のトラフィックへの過度な悪影響を回避するために制御されなければならない。
【００１６】
即時の無期限な要求の処理
ＩＰテレフォニなどの多くのアプリケーションは、即時の（即刻の）リソース要求に基づいている。これらのアプリケーションはその性質からして無期限、すなわち、リソース要求時にはセッションの持続時間は不明である（例えば、ＩＰテレフォニ）。即時に望まれる予約を以後即時予約と称し、事前には持続時間が不明である予約を無期限予約と称する。したがって、「今から」望まれる予約を、即時の無期限予約と称する。
【００１７】
この種のアプリケーションだけを持つシステムで許可制御を実行するには、図１に示すようにリソースマネジャは、予約済みのリソース（２）の最新合計を把握しているだけで、利用可能なリソース内での新規要求（１）許可が可能かどうかを調査することができる。このシステムにおいては、リソースを経時的にスケジューリングする必要はなく（カウンタのみは必要）、クライアントは必要になったときにリソースを要求することに留意されたい。添付図面のすべてのグラフは縦軸にリソース、横軸に時間をとっている。
【００１８】
リソースの経時的スケジューリング
事前に予約を行うことができることにより、クライアントは自らのネットワーク業務をより効率的に計画することができ、要求したリソースへのアクセスを得ることを事前に保証してもらうことができる。事前になされた予約はしばしば時間制限があり、そのため、Ｄ．フェラーリ、Ａ．グプタ、Ｇ．ベントレ（D. Ferrari, A. Gupta, and G. Ventre）による「リアルタイム接続の分散型事前予約」（Distributed advance reservation of real-time connections）、１９９５年４月、スプリンガー、ニューハンプシャー州ダーラム、ＮＯＳＳＤＡＶ予稿集、コンピュータサイエンス・レクチャーノート、ｐ．１５−２６の記述のように経時的にスケジューリングされることができる。
【００１９】
このように、開始時間と終了時間（または、持続時間）はしばしば既知であり、これらの予約を事前予約と称する。開始時間はすぐ先（即座であることすらある）であるかも知れないことに留意されたい。事前予約は、例えばＳ．ベルッソン、Ｒ．リンデルおよびＲ．ブレーデン（S. Bersson, R. Lindell and R. Braden）による「インターネットにおける事前予約のためのアーキテクチャ、テクニカルレポート」（An Architecture for advance reservations in the internet. Technical Report）南カリフォルニア大学情報科学研究所（USC Information Sciences Institute）、１９９８年７月、に記載のように、複数当事者の会議（例えば、ミーティング、会議、講義その他）、またはスポーツイベント等のような予定したイベントには、必要とされる時間にリソースが利用可能であることを確認しておくために特に不可欠である。大量のリソースを長距離で即時の許可を求めて要求することは、リソースが少ない場合は多分失敗となり、それは非常に支障がある。
【００２０】
ネットワーク運営者は集約リソース要求を経時的に手動あるいは自動で予測し、別のドメインとの間で正確に長期集約リソースを交渉することができる。エンドユーザのほとんどが即時要求を出したとしても、運営者は一般に、近隣者とトランク帯域幅を交渉して事前に計画しておく。このことは一般にリソースを経時的にスケジューリングすることを伴うので、新規の契約は現行契約が満了した時点で開始することができる。契約は、経時的に変化する（例えば、時間や曜日によって）集約帯域幅に関する場合もある。経時的にリソースをスケジューリングするためのサポートがあることは、このように複数のドメインと時間帯にわたり予測可能なサービスを効率良く供給する能力のためには不可欠である。
【００２１】
経時的に予約をスケジューリングする工程は非常に簡単明瞭である。図２に示すように、これはリソースと時間を巻き込んだ二次元的な問題である。許可制御は、ボックス（２）を２次元の時間―リソース図にはめ込むことを含む。リソースマネジャは、事前予約済リソース（１）を経時的に監視し、リソースの新規要求（２）を許可できるかどうか見極めなければならない。この場合、要求は開始時間（３）と終了時間（４）により制約され、ボックスの高さは要求されたリソースの量を表す。開示時間から終了時間まで常時（すべての関与するリソースリポジトリに）利用可能なリソースが十分あれば、要求は許可される。
【００２２】
持続時間が予め設定されて制約された予約のみのシステムにおいては、すべての許可された予約を取り分けておくので、予約許可後に利用可能なリソースが変化しない限り、クライアントはリソースへのアクセスを保証される。
【００２３】
従来技術
インターネット経由でＱｏＳを提供する最もよく知られたアーキテクチャは、事前予約を含まない。統合サービス（イントサーブ）アーキテクチャは、リソースが要求されたとき予約をオンデマンドで設定するためにＲＳＶＰプロトコルを用いる。事前予約をサポートするほとんどのアーキテクチャは、リソースの或る部分を即時で無期限の使用専用とし（図１）、別の部分を時間制限付きの事前予約に用いる（図２）ように、リソースを分割することによりこれを実行する。リソースを分割すると、利用可能なリソースを無期限の予約と事前予約の間で共有することはできなくなり、稼働率は低くなる。図３に示すように、図の下方にある無期限の予約のために予約されたリソースは、事前予約用に用いられることはない。分割のレベルを動的に調整することにより、稼働率を若干増やすことはできる。この方法は、そのセッションが２分以上継続しないかも知れないにもかかわらず、無限持続時間を用いて無期限の予約をすると見ることもできることに注目すべきである。
【００２４】
即時の無期限の予約を時間制限のある事前予約と混在させる１つの方法が開発され、それはオロフ・シェレン（Olov Schelen）の博士論文、「インターネットにおけるサービスの品質エージェント」（Quality of Service Agents in the Internet）、１９９８、ルーレオ、ルーレオ工科大学コンピュータ通信学部、コンピュータサイエンス・電気工学科（Department of Computer Science and Electrical Engineering, Division of Computer Communication, Lulea University of Technology, Lulea, 1998）に記述されている。この方法では、即時無期限予約と事前予約の許可制御は別々になっているものの、最新予約状況に関する情報をシグナリングすることにより、リソースはこの二つの間で共有されている。この方法は、即時無期限予約の持続時間の統計学的予測と、予約をプリエンプト処理（pre-empt）しなければならないリスクを稼動に対して比較検討することに基づいている。この方法は、二つのアルゴリズム間で共有が必要な情報を最小化することにより、即時無期限予約（図１のような）への許可制御の実行と簡易性を保持するように最適化された。
【００２５】
上述した方法を図４に示す。この方法は、新規の無期限予約（１）を許可するにあたり、ルック・アヘッド・タイム（look-ahead time）（３）内の許可済事前予約（４）のレベルを監視することに基づいている。したがって、ルック・アヘッド・タイム内の許可済事前予約を検討することにより将来のリソース稼働率を監視することが可能となる。新規の即時予約（１）は、将来の所定の先取り時間（３）、すなわちルック・アヘッド・タイムを見て、即時無期限予約の総和（１＋２）分に対して利用可能なリソースが十分にあれば許可される。事前予約の許可制御を行う際、事前に許可済の即時予約（１および２）を保護するために新規の事前予約をルック・アヘッド・タイム（３）内で許可しないようになっているので、即時（１＋２）予約を考慮する必要はない。［１］では、事前予約を行ってからそれが発効するまでの時間をブック・アヘッド・タイム（book-ahead time）（５）と呼び、それは少なくともルック・アヘッド・タイム（３）である。
【００２６】
無期限の予約を事前予約と混在させることの主な問題は、Ａ．Ｇ．グリーンバーグ、Ｒ．スリカント、Ｗ．ウィット（Greenberg, A. G., R. Srikant and W. Whitt）による、「先行予約および即時要求通話のためのリソース共有」（Resource sharing for Book-Ahead and Instantaneous-Request Calls）ＡＴ＆Ｔ研究所（AT & T Labs）１９９７に記載されているように、無期限の予約の持続時間が事前にわからないことである。リソースが図３のように無限に分割されていない場合、Ｆ．シル、Ｆ．ブレイター、Ｓ．クーン（Schill, F. Breiter, and S. Kuhn）による「ＲＳＶＰ上での事前予約プロトコルの設計と評価」（Design and evaluation of an advance reservation protocol on top of RSVP）、情報技術国際連合（International Federation for Information Prosessing、IFIP）、１９９８年シュツットガルト、チャップマンホール、第４回ブロードバンド通信国際会議予稿集ｐ．２３−４０に記載のように、リソースが共有されていると、オーバーブッキングの危険が常に存在する。
【００２７】
例えば、図５の無期限の予約（１）が（２）の予約よりも長引けば、リソースは（２）でオーバーブッキング状態となり、すべての影響を受ける予約に対してサービスを保証するため、1つまたは複数の予約をプリエンプション処理しなければならない。プリエンプション処理の対象となる予約の選択には、優先度、予約時間あるいはその他の方針に基づき、いくつか方法がある。この例においては、自然な解決は、無期限の予約をプリエンプション処理して、事前予約を優先させることである。
【００２８】
オロフ・シェレンにより提示されたソリューション（図４に示す）では、即時予約をプリエンプション処理しなければならないリスクは、ルック・アヘッド・タイムを調整することにより調整できる。しかし、この方法の問題点は、すべての予約に対してルック・アヘッド・タイムがひとつしかないことであり、それは、すべての無期限の予約が同じプリエンプションのリスクを負い、すべての予約の予測持続時間を同じにしなければならないことである。したがって、この方法は、プリエンプションのリスクに対して異なる要求を有する、および／または予測持続時間の統計的分布が異なっている異種のアプリケーションを同時にサポートできない。ＩＰテレフォニのために調整されたルック・アヘッド・タイムは２分間程であるのに対し、ビデオ会議アプリケーションに対してはかなり長いルック・アヘッド・タイムがなければならない。異なるアプリケーションにおいて予測持続時間が同じであったとしても、あるアプリケーションはプリエンプションのリスクをより低くしたいので、区画料金の低さと引き換えにプリエンプションに関する高リスク性を受け入れる（許可されやすいが、プリエンプション処理の対象にもされやすい）可能性のある別のアプリケーションよりも、長いルック・アヘッド・タイムを必要とする。
【００２９】
オロフ・シェレンにより記述されたこの方法では、事前になされた予約は、利用可能なリソースが変わらない限り、許可されたリソースを保証される一方で、即時の無期限の予約はプリエンプションのリスクを負う。したがって、リソースを確保するためには事前予約をしなければならず、この方法においては予約を少なくとも図４の事前のルック・アヘッド・タイム（５）にしなければならない。この方法は時間制限付きの即時の予約をサポートしていないので、すべての即時予約はプリエンプションリスクの対象となる。別の問題は、即時の無期限予約を保護するために事前予約をルック・アヘッド・タイム内で変更することができないということである。これも、更新しなければタイムアウトになり、更新時間がルック・アヘッド・タイムより少なければサポートされないソフトステート型予約ということを意味する。
【発明の開示】
【発明が解決しようとする課題】
【００３０】
したがって、本発明の目的は、リソースを即時に、また将来の使用のために予約する際にリソースをより効率的に利用する方法と装置を提供することにある。
【課題を解決するための手段】
【００３１】
発明の要約
上述した目的は、本発明の独立請求項により達成される。
【００３２】
好適な実施の形態は従属請求項に規定される。
【００３３】
共有リソースプールを利用して、無期限の予約を事前予約と混在させることにより、リソース稼働率が高くなる。本発明に係わる方法は、無期限の予約とともに事前および即時の時間制限付予約へのサポートを、リソースを保証して可能にする。この方法は、稼動中の、あるいは「今にも稼動する」予約の変更を許容し、それはソフトステート型予約を容認することになる。本発明は異種のアプリケーションを、種々の時間配分および種々のプリエンプションリスクでサポートする。無期限の事前予約の新規な概念も本発明に導入されている。本発明はプリエンプションリスクを適合させる可能性に対応する。
【００３４】
リソースマネジャは「リソースマネジャ」に記述されたアクションを実行する手段を備えている。本発明によれば、リソースマネジャは、リソースを予約する手段と、前記リソースを前記開始時間と前記終了時間の間保証する手段と、前記終了時間を過ぎた後で前記アプリケーションがまだリソースを必要としていれば、無期限のアプリケーション用にリソース予約を提供するため、該アプリケーション用に前記リソースを保持する手段をも備えている。
【００３５】
リソースマネジャは、利用可能なリソースが十分ない場合に無期限の予約のプリエンプション処理を制御するために、前記終了時間を満了した稼動中の予約のリストを維持する手段をも備えていてよい。
【００３６】
さらに、リソースマネジャは、前記アプリケーションに適合された前記開始時間および終了時間を選択するために、アプリケーションクライアントに前記アプリケーションの個別の開始時間および終了時間を設定させる手段をも備えていてよい。
【００３７】
さらに、リソースマネジャは、前記アプリケーションに適合された前記開始時間および終了時間を選択するために、前記アプリケーションの個別の開始時間および終了時間を設定する手段をも備えていてよい。
【００３８】
さらに、リソースマネジャは、リソースを即座に予約および保証するために、前記開始時間を現時間に設定する手段を備えていてよい。
【００３９】
さらに、リソースマネジャは、リソースを即座に割り当てるために、前記終了時間を現時間に設定する手段を備えていてよい。
【００４０】
さらに、リソースマネジャは、長時間リソースを保証するために、前記終了時間を無限時間に設定する手段を備えていてよい。
【００４１】
さらに、リソースマネジャは、前記リソースの請求を、保証されたリソースの量に基づかせる手段を備えていてもよい。
【発明を実施するための最良の形態】
【００４２】
本発明に係わる第１の好適な実施形態は、無期限の予約を、事前および即時の時間制限付予約と同じ方法で、かつ、同じリポジトリから予約する可能性を提供することに基づいている。このことは、図６に示すように、クライアントが出すかも知れず出さないかも知れない無期限の予約に対して開始時間（１）と終了時間（２）を導入することにより達成される。無期限の予約は、事前予約（４）とともに、開始時間（１）と終了時間（２）との間予約され、それにより、前記開始時間（１）と終了時間（２）との間リソースも保証される。図２のような予約と、本発明による無期限の予約の違いは、終了時間（２）が過ぎた後でも、該開始時間と終了時間の間予約されたリソースを使用できることである。
このように、このことで、無期限のアプリケーションがリソースを予約することが可能となる。リソース要求の「無期限動作」を、図６に矢印（３）で示す。終了時間（２）が過ぎた後では、予約されたリソースはプリエンプション処理のリスクの対象となる。このソリューションでは、終了時間（２）よりも長く続く無期限の予約のみがプリエンプション処理され得る。
【００４３】
本発明に係わる第２の好適な実施形態は、図７に示すように、無期限の予約、すなわち、その開始時間が将来の時間に設定されている無期限の予約を許容する。
【００４４】
図７の無期限な事前予約（１）は、許可制御をしてリソースを予約する際は他のあらゆる事前予約と同じと見なされるが、終了時間（２）が過ぎてもリソースは解放されず、代わりに、クライアントがそのリソースを望む限り、また、利用可能なリソースがある限りリソースを利用してよい。この種の予約は、例えば、予定よりも長引くビデオ会議や、予定時間よりも長引くことが多いスポーツイベントのためにリソースを予約する際に有用である。ビデオ・オンデマンド・アプリケーションでさえも、ユーザが映画を停止させたり巻き戻したりできる場合は予定より長引くことがある。これらの種類の予約を無期限にしておくと、終了時間を過ぎてもリソースは自動的に解放されない。
【００４５】
リソースマネジャは、終了時間が過ぎたすべての稼動中の無期限予約のリストを維持し、時間の経過につれこれらの予約を維持する利用可能なリソースがあることを検証することを要求される。最新の利用可能なリソースがオーバーブッキング状態になれば、終了時間を過ぎてリソースを用いている1つまたは複数のクライアントに対しプリエンプション処理が実行される。ほとんどの場合このリスト中のクライアントのうち1つをプリエンプション処理することが自然であるが、緊急通話などの例外もあり得る。すなわち、優先度の高い（例えば緊急）通話などの場合があれば、代わりに別のリソースをプリエンプション処理することが適切であり得る。その選択はローカルな規定次第である。本発明では、即時予約の特別扱いはない。時間制限付の予約または無期限の予約、およびその二つの混在という概念があるのみである。ゼロ持続時間（開始時間＝終了時間＝現在）を用いた即時の予約（今すぐ）をすることは、何ら保証を与えず（図５と同様）、図４のルック・アヘッド・タイムと等しい持続時間で即時の予約をすることは、リソースをルック・アヘッド・タイム内で保証することができる点においてオロフ・シェレンによる上述した方法と同じ結果をもたらす。
【００４６】
このソリューションは、異なるアプリケーションに対しクライアントまたはリソースマネジャで予め設定された値での各無期限の予約に対して、個別の開始時間と個別の終了時間を設定する可能性を実現させる。請求は、保証されたリソースの量（開始時間と終了時間の間の持続時間）に基づいていてもよいし、基づいていなくてもよい。クライアントがプリエンプションのリスクを低くしたいならば、リソースの予約をより長い持続時間で要求しなければならない。いっぽう、より長い持続時間の要求は受理されないかも知れない。したがって、持続時間は、望まれるブロッキング可能性に関して選択されることができ、より短い持続時間の予約のほうが許可されやすく、かつ、リソースを取り分けるわけではなく、その場合プリエンプションのリスクが非常に高くなるため、ゼロ持続時間の予約は常に許可される。本発明は、即時の時間制限付予約をサポートするが、それはソフトステート型の予約を可能にし、即時予約のための保証されたリソースを容認する。ソフトステート型の予約とは、しばらくすると解放される時間制限付予約であって、解放が例えばタイマーで制御されるものである。クライアントがソフトステート型の予約を保持したい場合、継続的に繰り返される更新操作が必要となる。ソフトステート型の予約と無期限型予約の違いは、無期限型予約はリソースが能動的な動作により解放されるまでそのリソースを維持していることにある。
【００４７】
図８は、本発明の一般モードによる、ＩＰネットワーク内でアプリケーションのためのリソースを予約する方法のフローチャートを示す。リソースはリソースマネジャにより予約されて制御され、リソースマネジャは前記ＩＰネットワーク内のサーバまたはルータ内に配置されている。
【００４８】
この方法は以下のステップを備えている：
８０１．クライアントはリソースマネジャに対しアプリケーションのためのリソースの予約を要求し、開始時間と終了時間を設定する。
８０２．リソースマネジャはその要求を許可する、あるいは拒絶する。
８０３．要求が許可されると、リソースマネジャは開始時間以降終了時間までリソースを予約し保証する。
８０４．終了時間が過ぎたとき、前記アプリケーションが前記予約されたリソースをまだ必要としていて、利用可能なリソースが十分あれば、該予約されたリソースは保持される。
【００４９】
本発明によるリソース予約方法はコンピュータプログラム製品によって実行され、該コンピュータプログラム製品はリソースマネジャに組み込まれていてよく、リソースマネジャはＩＰネットワーク内のルータまたはサーバに配置されている。
【００５０】
本発明は、上述した好適な実施の形態に限定されるものではない。
【００５１】
種々の別形態、変形形態および同等の形態を用いることができる。したがって、上述した実施の形態を、添付の請求項により規定される本発明の範囲を限定するものとしてとらえるべきではない。
【図面の簡単な説明】
【００５２】
【図１】即時の無期限のリソース要求の処理を示す。
【図２】経時的なリソーススケジューリングを示す。
【図３】無期限の事前予約のために分割されたリソースを示す。
【図４】ルック・アヘッド・タイムに基づく許可制御を示す。
【図５】予定されていた事前予約をどのようにして無期限の予約と混在させるかを示す。
【図６】本発明に係わる開始時間と終了時間を持つ即時の無期限の予約を示す。
【図７】本発明に係わる無期限の事前予約を示す。
【図８】本発明に係わる方法のフローチャートを示す。
【図１】
2005522097.tif 000003
【図２】
2005522097.tif 000004
【図３】
2005522097.tif 000005
【図４】
2005522097.tif 000006
【図５】
2005522097.tif 000007
【図６】
2005522097.tif 000008
【図７】
2005522097.tif 000009
【図８】
2005522097.tif 000010
【手続補正書】
【提出日】平成16年3月30日(2004.3.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＩＰネットワーク内でネットワークリソースを予約する方法であって、１アプリケーションまたは一群のアプリケーションに対するリソースが、開始時間と終了時間とで規定される時間間隔でリソースマネジャにより予約され、該方法が、前記リソースを前記開始時間と前記終了時間の間保証するステップと、前記終了時間が過ぎた後で、前記アプリケーションがまだリソースを必要としていれば、該アプリケーションのために前記リソースを保持し、その場合リソースマネジャは前記終了時間を過ぎて稼動中の予約のリストを保持しているステップとを備えたことを特徴とする方法。
【請求項２】
すべてのリソース予約は共有リソースプールを利用していることを特徴とする特許請求の範囲第１項に記載の方法。
【請求項３】
各アプリケーションに対しアプリケーションのクライアントにより個別の開始時間と終了時間が設定されたことを特徴とする特許請求の範囲第１項に記載の方法。
【請求項４】
各アプリケーションに対しリソースマネジャにより個別の開始時間と終了時間が設定されたことを特徴とする特許請求の範囲第１項に記載の方法。
【請求項５】
前記開始時間が現時間に設定されたことを特徴とする特許請求の範囲第１項に記載の方法。
【請求項６】
前記終了時間が現時間に設定されたことを特徴とする特許請求の範囲第５項に記載の方法。
【請求項７】
前記終了時間が無限時間に設定されたことを特徴とする特許請求の範囲第１項から第５項のいずれかに記載の方法。
【請求項８】
前記リソースへの請求が、保証されたリソースの量に基づいていることを特徴とする特許請求の範囲第１項に記載の方法。
【請求項９】
前記リソースが、帯域幅と関連していることを特徴とする特許請求の範囲第１項に記載の方法。
【請求項１０】
特許請求の範囲第１項から第９項のステップを実行するソフトウェアコード部分を備えたＩＰネットワーク内のルータまたはサーバの内部メモリに直接ロードできるコンピュータプログラム製品。
【請求項１１】
ＩＰネットワーク内のルータまたはサーバのリソースマネジャに、特許請求の範囲第１項から第９項のステップの実行を管理させる読取可能なプログラムを備えた、コンピュータで使用できる媒体に格納されたコンピュータプログラム製品。
【請求項１２】
ＩＰネットワーク内でネットワークリソースを予約するリソースマネジャであって、前記リソースマネジャはアプリケーションまたは一群のアプリケーションに対するリソースを開始時間と終了時間とで規定される時間間隔で予約する手段を備え、前記リソースマネジャは、前記リソースを前記開始時間と前記終了時間の間保証する手段と、前記終了時間が過ぎた後で、前記アプリケーションがまだリソースを必要としていれば、該アプリケーションのために前記リソースを保持しておく手段を備え、前記リソースマネジャは前記終了時間を過ぎた稼動中の予約のリストを保持する手段を備えている手段を備えたことを特徴とするリソースマネジャ。
【請求項１３】
すべてのリソース予約は共有リソースプールを利用していることを特徴とする特許請求の範囲第１２項に記載のリソースマネジャ。
【請求項１４】
前記リソースマネジャが、各アプリケーションのクライアントが前記アプリケーションに対し個別の開始時間と終了時間を設定することを可能にする手段を備えていることを特徴とする特許請求の範囲第１２項に記載のリソースマネジャ。
【請求項１５】
前記リソースマネジャが、各アプリケーションに対し個別の開始時間と終了時間を設定する手段を備えていることを特徴とする特許請求の範囲第１２項に記載のリソースマネジャ。
【請求項１６】
前記リソースマネジャが、前記開始時間を現時間に設定する手段を備えていることを特徴とする特許請求の範囲第１２項に記載のリソースマネジャ。
【請求項１７】
前記リソースマネジャが、前記終了時間を現時間に設定する手段を備えていることを特徴とする特許請求の範囲第１６項に記載のリソースマネジャ。
【請求項１８】
前記リソースマネジャが、前記終了時間を無限時間に設定する手段を備えていることを特徴とする特許請求の範囲第１２項から第１６項のいずれかに記載のリソースマネジャ。
【請求項１９】
前記リソースマネジャが、前記リソースへの請求を、保証されたリソースの量に基づかせる手段を備えたことを特徴とする特許請求の範囲第１２項に記載のリソースマネジャ。
【請求項２０】
前記リソースが帯域幅と関連していることを特徴とする特許請求の範囲第１２項に記載のリソースマネジャ。
【国際調査報告】
2005522097.tif 000011
2005522097.tif 000012
2005522097.tif 000013