JP2006203343A - リソース管理装置および方法 - Google Patents

Abstract

【課題】リソース管理装置においてリソース確保要求を受け付けてからその応答をするまでの時間を短縮する。
【解決手段】通信経路毎に利用可能なリソース残量と予め設定された閾値との大小を示すリソース残量指標をデータベース部１３に保持する。リソース確保要求メッセージを受信したときに、リソース残量が閾値よりも大きいことをリソース残量指標が示していれば、リソース確保可否判定部１２３によってリソース確保が可能であると判定する。
【選択図】 図２

Description

本発明は、通信ネットワークにおけるリソースを管理するリソース管理装置および方法に関する。

通信ネットワーク、特にＩＰ（Internet Protocol）ネットワークを利用して音声や映像等のコンテンツを提供する場合には、通信路の容量を超える利用要求によって輻輳が発生すると、パケットの損失等に伴い通信品質が劣化してしまう。このような通信品質の劣化を防ぐことを目的として、ネットワークレイヤにおけるリソース管理が研究されている。この種のリソース管理の一つに、通信ネットワークを構成するルータとは独立したリソース管理装置（リソース管理サーバ）を用いて、通信ネットワークを構成するノード間（リンク）のリソース容量とその利用状況を管理するとともに、ユーザ端末等からのリソース確保要求に対して適切なリソースを払い出す方式がある。その従来例を以下に説明する。

通信ネットワークの運用開始前に、まず、その通信ネットワーク内のルーティング情報を収集する。このルーティング情報には、通信ネットワーク中の各リンクのリソース容量および接続情報が含まれている。ついで、各リンクの接続情報を基にパケットが通過する通信経路を計算し、その計算結果を基に経路テーブルを作成する。また、各リンクのリソース容量から、リンクリソース管理テーブルを作成する。このリンクリソース管理テーブルによって、各リンクの総リソース容量と、利用可能なリソース残量が管理される。

通信ネットワークの運用開始後にあっては、リソース管理サーバにおいて通信サービスの利用要求（リソース確保要求）を受け付けると、要求された通信の発着ＩＰアドレスを基に、経路テーブルから当該通信に必要となるリンクを特定する。そして、リンクリソース管理テーブルを参照し、特定されたリンクのそれぞれについて当該通信に必要となる容量が利用可能か否かをチェックする。
その結果、特定されたすべてのリンクについて十分な容量が利用可能である場合には、リソース確保が可能であると判定する。そして、リソース確保要求に対して許諾応答するとともに、リンクリソース管理テーブルにおいて、特定されたリンクのリソース残量から当該通信に割り当てられる容量を減算する処理を行う。逆に、いずれかのリンクについて利用可能な容量が不足する場合には、リソース確保が不可能であると判定し、リソース確保要求に対して拒絶応答する（例えば、特許文献１および非特許文献１を参照）。

リソース確保要求の許諾応答を受けて通信サービスを利用することによって、通信品質が担保される。
その後、通信サービスの利用終了時には、それまで確保していたリソースを速やかに解放する。

なお、出願人は、本明細書に記載した先行技術文献情報で特定される先行技術文献以外には、本発明に関連する先行技術文献を出願時までに発見するには至らなかった。
特開２００３−２５８８５５号公報 矢口他、「大規模ＩＰ網における管理サーバを用いたリソース管理方式の一提案と具体例」、信学総合大会、Ｂ−６−３１（２００２）

このように、従来の技術では、リソース確保が可能か否かを判定するために、通信に用いられるすべてのリンクについて、利用可能なリソース残量をチェックする必要がある。このため、リソース確保が可能か否かの判定に長時間を要し、リソース確保要求に対する応答が遅れてしまう。リソース確保要求を行った端末間の通信はリソース管理サーバからの応答を待って開始されるので、応答の遅れに伴って通信開始時間も遅れてしまうという問題があった。例えばザッピングを行って映像コンテンツを選択しているときに、配信開始時間が遅れると、視聴者に対して不快感を与えることとなる。

本発明は、このような課題を解決するためになされたものであり、その目的は、リソース管理サーバにおいてリソース確保要求を受け付けてからその応答をするまでの時間を短縮することにある。

リソース管理サーバ（リソース管理装置）によって管理されるリソースの残量に余裕がある場合には、実際のリソース使用率も低い。したがって、リソース確保要求された通信経路のリソース残量に余裕があることがわかれば、その通信経路に含まれるすべてのリンクについてリソース残量をチェックせずにリソース確保が可能であると判定しても、通信品質を担保できる。
したがって、本発明にかかるリソース管理サーバは、通信経路毎に利用可能なリソース残量と予め設定された閾値との大小を示す残量情報を記憶する残量情報記憶手段と、リソース残量が閾値よりも大きいことを残量情報が示している場合に、リソース確保要求メッセージに基づくリソース確保が可能であると判定するリソース確保可否判定手段とを備えるものである。

また、リソース確保可否判定手段によりリソース確保が可能であると判定されたときに、リソース確保を許諾する旨の応答メッセージをリソース確保要求メッセージの送信元に送信するメッセージ送信手段を更に備えるようにしてもよい。
また、リソース確保処理を行うことによりリソース残量が閾値よりも小さくなったときと、確保されたリソースを解放する処理を行うことによりリソース残量が閾値よりも大きくなったときに、残量情報の内容を書き換える残量情報更新手段を更に備えるようにしてもよい。

また、本発明にかかるリソース管理方法は、通信経路毎に利用可能なリソース残量と予め設定された閾値との大小を示す残量情報を保持するステップと、リソース残量が閾値よりも大きいことを残量情報が示している場合に、リソース確保要求メッセージに基づくリソース確保が可能であると判定するステップとを備えるものである。

また、リソース確保が可能であると判定したときに、リソース確保を許諾する旨の応答メッセージをリソース確保要求メッセージの送信元に送信するステップを更に備えるようにしてもよい。
また、リソース確保処理を行うことによりリソース残量が閾値よりも小さくなったときと、確保されたリソースを解放する処理を行うことによりリソース残量が閾値よりも大きくなったときに、残量情報の内容を書き換えるステップを更に備えるようにしてもよい。

上述したように、本発明では、通信経路毎にリソース残量と閾値との大小を示す残量情報を保持し、この残量情報に基づいてリソース確保が可能か否かを判定する。これにより、リソース確保が可能か否かの判定の際に、通信経路に含まれるすべてのリンクについてリソース残量をチェックする必要がなくなるので、当該判定に要する時間を短縮できる。その結果、リソース確保要求メッセージを受信してから応答メッセージを送信するまでの時間を短縮できる。

以下、本発明の一実施の形態について、図面を参照しながら詳細に説明する。
図１は、本発明の一実施の形態にかかるリソース管理サーバが適用されるシステムの全体構成を示すブロック図である。
図１に示すリソース管理サーバ１は、通信ネットワーク２のリソースを管理するリソース管理装置である。

管理対象となる通信ネットワーク２は、インターネットプロトコル（ＩＰ）に基づく通信ネットワークであり、互いにリンクされた複数のルータＲ（Ｒ１〜Ｒ７）と端末Ｔ（Ｔ１〜Ｔ６）とから構成される。この通信ネットワーク２のリソースとは、通信を行う２つの端末間の通信経路を構成する、端末ＴとルータＲとの間のアクセスラインおよびルータＲ相互間のリンクのことをいう。

アプリケーションサーバＡＳは、端末Ｔからの各種要求を受けて、その要求に応じたメッセージをリソース管理サーバ１に送信するサーバである。要求メッセージには、端末Ｔと他の端末との間で行う通信に必要なリソースの確保を要求するリソース確保要求メッセージ、確保されたリソースの解放を要求するリソース解放要求メッセージ等がある。それぞれの要求メッセージには、要求メッセージの種類を示すメッセージ番号、通信を行う２つの端末の識別子、通信に必要なリソースの容量等の情報が付加されている。なお、本実施の形態では、端末の識別子としてＩＰアドレスを用いることとする。

次に、リソース管理サーバ１の構成について説明する。
リソース管理サーバ１は、通信機能を有するコンピュータからなる。以下に説明するリソース管理サーバ１の諸機能は、演算装置（ＭＰＵ）や記憶装置（ＲＯＭおよびＲＡＭ等の内部メモリの他、ＨＤＤ等の外部記憶装置を含む）等のコンピュータのハードウェア資源とこのコンピュータにインストールされたコンピュータ・プログラム（ソフトウェア）とが協働することによって実現される。

図２は、リソース管理サーバ１の機能ブロック図である。
図２に示すように、リソース管理サーバ１は、送受信部１１と、制御部１２と、データベース部１３とを有する。
ここで、送受信部１１は、通信インターフェースを備え、アプリケーションサーバＡＳとの間で各種メッセージを送信および受信する。

制御部１２は、受信された要求メッセージに応じて、通信ネットワーク２のリソース管理を行なう。具体的には、送受信部１１で受信された各種要求メッセージを分析するメッセージ解析部１２１と、分析結果を基にリソースの確保または解放が要求される通信経路を検出する通信経路検出部１２２と、検出された通信経路においてリソース確保が可能であるか否かを判定するリソース確保可否判定部１２３と、判定結果にしたがってリソース確保要求に対し許諾応答または拒絶応答を行う応答処理部１２４と、リソース確保および解放の処理を行うリソース確保・解放処理部１２５と、各通信経路の利用可能なリソース残量に十分余裕があるか否かの指標であるリソース残量指標の内容を必要に応じて書き換えるリソース残量指標更新部１２６とから構成される。

リソース残量指標は、通信経路のリソース残量と予め設定された閾値との大小によって規定される。閾値は、リソース残量に十分余裕があるとされる最大の値であり、リソース管理サーバ１の保守者によって適宜設定される。本実施の形態では、通信経路を構成するすべてのリンクのリソース残量が閾値以上の場合に、リソース残量指標の値を「０」とし、通信経路を構成するリンクのいずれかが閾値よりも小さくなると、リソース残量指標の値を「１」にする。後述するように、リソース残量指標は、リソース確保可否判定部１２３による判定に用いられる。

データベース部１３は、上述した制御部１２によるリソース管理に必要な各種情報を記憶する。具体的には、アドレスリスト１３１と、経路テーブル１３２と、リンクリソース管理テーブル１３３を記憶する。
ここで、アドレスリスト１３１は、通信ネットワーク２に属する端末Ｔ１〜Ｔ６およびルータＲ１〜Ｒ７のＩＰアドレスのリストである。例えば図３に示すように、アドレスリスト１３１は、端末Ｔ１〜Ｔ６のＩＰアドレスと、各端末を収容するエッジノード（例えば、端末Ｔ１を収容するルータＲ１）の名称およびそのＩＰアドレスとからなる。

経路テーブル１３２は、端末Ｔ１〜Ｔ６を収容するすべてのエッジノード（ルータＲ１〜Ｒ４）間の通信経路を示すテーブルである。例えば図４に示すように、経路テーブル１３２は、発端末を収容する発側エッジノードの名称と、発端末との間で通信を行う着端末を収容する着側エッジノードの名称と、これら２つのエッジノード間の通信経路の番号と、この通信経路を構成するリンクのリストと、通信経路のリソース残量指標とを有する。
リンクリソース管理テーブル１３３は、通信ネットワーク２中のすべてのリンクの総リソース容量と、利用可能なリソース残量とを示すテーブルである。リンクリソース管理テーブル１３３の一例を図５に示す。

次に、リソース管理サーバ１の動作について説明する。
まず、図６を参照し、端末Ｔ４が端末（以下「配信サーバ」という）Ｔ１による映像配信サービスを利用する際に、リソース管理サーバ１が通信ネットワーク２において必要なリソースを確保する動作について説明する。

端末Ｔ４が配信サーバＴ１による映像配信サービスの利用要求をアプリケーションサーバＡＳに送信すると、この利用要求を受けてアプリケーションサーバＡＳはリソース確保要求メッセージを作成し、リソース管理サーバ１に送信する。リソース確保要求メッセージには、このメッセージがリソース確保要求であることを示すメッセージ番号、映像配信を行う発端末としての配信サーバＴ１のＩＰアドレス、映像配信を受ける着端末としての端末Ｔ４のＩＰアドレス、映像配信に必要なリソースの容量が付加されている。

このリソース確保要求メッセージを送受信部１１で受信したリソース管理サーバ１では、制御部１２の各部１２１〜１２６が次のように動作する（ステップＳ１，ＹＥＳ）。
まず、メッセージ解析部１２１が、受信したメッセージに付加されているメッセージ番号から、このメッセージが「リソース確保要求」であると判断する（ステップＳ２，ＹＥＳ）。さらに、メッセージに付加されている配信サーバＴ１および端末Ｔ４のＩＰアドレス、映像配信に必要なリソースの容量を抽出する。

ついで、通信経路検出部１２２が、図３に示したアドレスリスト１３１を参照し、メッセージから抽出した配信サーバＴ１および端末Ｔ４のＩＰアドレスをキーにして、配信サーバＴ１および端末Ｔ４をそれぞれ収容するエッジノードを検索し、発側エッジノードがルータＲ１、着側エッジノードがルータＲ３であることを知る。続いて、図４に示した経路テーブル１３２を参照し、ルータＲ１とルータＲ３との間の通信ネットワーク２における通信経路を検索し、その番号が「２」であることを知る（ステップＳ３）。

ついで、リソース確保可否判定部１２３が、番号「２」の通信経路でリソース確保が可能か否かを判定するために、経路テーブル１３２のリソース残量指標を参照する。リソース残量指標の値は「０」であり（ステップＳ４，ＹＥＳ）、番号「２」の通信経路にはリソース残量に十分余裕があるから、映像配信に必要とされる容量にかかわらず、リソース確保可能であると判定する（ステップＳ５）。

その後、直ちに、応答処理部１２４がリソース確保を許諾する旨の応答メッセージを作成し、送受信部１１からアプリケーションサーバＡＳに送信する（ステップＳ６）。
また、リソース確保・解放処理部１２５が、経路テーブル１３２のリンクリストを参照し、番号「２」の通信経路がリンクＲ１−Ｒ５とリンクＲ５−Ｒ３とからなることを知る。続いて、図５に示したリンクリソース管理テーブル１３３から、リンクＲ１−Ｒ５の現在のリソース残量の値を読み出す。この値から映像配信に必要とされる容量の値を減算し、得られた値をリンクＲ１−Ｒ５の新たなリソース残量として、リンクリソース管理テーブル１３３に書き込む。リンクＲ５−Ｒ３についても同様の処理を行う。これにより、映像配信のためのリソースが確保される（ステップＳ７）。

ここで、リソース残量指標更新部１２６が、リンクＲ１−Ｒ５，Ｒ５−Ｒ３の新たなリソース残量と閾値との大小を比較する。その結果、両方のリンクのリソース残量が閾値以上である場合には（ステップＳ８，ＹＥＳ）、そのまま一連の処理を終了する。これに対し、少なくともいずれかのリンクのリソース残量が閾値よりも小さくなったときには（ステップＳ８，ＮＯ）、番号「２」の通信経路のリソース残量指標の値を「０」から「１」に書き換えた後（ステップＳ９）、一連の処理を終了する。

一方、リソース確保可否判定部１２３が経路テーブル１３２のリソース残量指標を参照したときに、その値が仮に「０」ではなく「１」であったとすると（ステップＳ４，ＮＯ）、従来と同様にリソース確保の可否判定を行う。すなわち、リソース確保可否判定部１２３はまず、経路テーブル１３２のリンクリストを参照し、番号「２」の通信経路がリンクＲ１−Ｒ５とリンクＲ５−Ｒ３とからなることを知る。続いて、リンクリソース管理テーブル１３３からそれぞれのリンクの現在のリソース残量の値を読み出し、映像配信に必要とされる容量の値との大小を比較する。

その結果、すべてのリンクのリソース残量が映像配信に必要とされる容量よりも大きい場合には、リソース確保可否判定部１２３はリソース確保可能であると判定する（ステップＳ１０，ＹＥＳ）。この場合には、リソース確保・解放処理部１２５および応答処理部１２４が、従来と同様にリソース確保処理を行い（ステップＳ１１）、リソース確保を許諾する旨の応答メッセージをアプリケーションサーバＡＳに送信する（ステップＳ１２）。
これに対し、いずれかのリンクのリソース残量が映像配信に必要とされる容量よりも小さいときには、リソース確保可否判定部１２３はリソース確保が不可能であると判定する（ステップＳ１０，ＮＯ）。この場合には、応答処理部１２４が、従来と同様にリソース確保を拒絶する旨の応答メッセージをアプリケーションサーバＡＳに送信する（ステップＳ１３）。

アプリケーションサーバＡＳは、リソース確保を許諾する旨の応答メッセージを受けると、端末Ｔ４に対し通信品質を保証した上で、配信サーバＴ１による映像配信サービスの利用を許可する。これにより、配信サーバＴ１から端末Ｔ４への高品質な映像配信が開始される。

本実施の形態のように、リソース確保が可能か否かの判定に上述した通信経路のリソース残量指標を用いることによって、通信経路のリソース残量に十分余裕がある場合には、通信経路に含まれるすべてのリンクについてリソース残量をチェックする必要がなくなるので、上記判定に要する時間を短縮できる。その結果、リソース管理サーバ１がリソース確保要求メッセージを受信してから、リソース確保を許諾する旨の応答メッセージを送信するまでの時間を短縮できる。それに応じて、配信サーバＴ１から端末Ｔ４への映像配信開始時間を早くできる。これにより、例えばザッピングを行って映像コンテンツを選択する場合にも、視聴者に対して不快感を与えなくてすむようになる。

次に、図６および図７を参照し、配信サービスＴ１から端末Ｔ４への映像配信が終了した後に、リソース管理サーバ１が映像配信のために確保されていたリソースを解放する動作について説明する。

端末Ｔ４が配信サーバＴ１による映像配信の終了を通知すると、この通知を受けてアプリケーションサーバＡＳはリソース解放要求メッセージを作成し、リソース管理サーバ１に送信する。リソース解放要求メッセージには、このメッセージがリソース解放要求であることを示すメッセージ番号、発端末としての配信サーバＴ１のＩＰアドレス、着端末としての端末Ｔ４のＩＰアドレス、映像配信のために確保されたリソースの容量が付加されている。

このリソース解放要求メッセージを送受信部１１で受信したリソース管理サーバ１では、制御部１２の各部が次のように動作する（図６のステップＳ１，ＹＥＳ）。
まず、メッセージ解析部１２１が、受信したメッセージに付加されているメッセージ番号から、このメッセージが「リソース解放要求」であると判断する（図６のステップＳ２，ＮＯ、図７のステップＳ２１，ＹＥＳ）。さらに、メッセージに付加されている配信サーバＴ１および端末Ｔ４のＩＰアドレス、映像配信のために確保されたリソースの容量を抽出する。

ついで、通信経路検出部１２２が、図６のステップＳ３と同様にして、通信ネットワーク２における通信経路を検索し、その番号が「２」であることを知る（図７のステップＳ２２）。

ついで、リソース確保・解放処理部１２５が、図４に示した経路テーブル１３２のリンクリストを参照し、番号「２」の通信経路がリンクＲ１−Ｒ５とリンクＲ５−Ｒ３とからなることを知る。続いて、図５に示したリンクリソース管理テーブル１３３から、リンクＲ１−Ｒ５の現在のリソース残量の値を読み出す。この値から映像配信のために確保された容量の値を加算し、得られた値をリンクＲ１−Ｒ５の新たなリソース残量として、リンクリソース管理テーブル１３３に書き込む。リンクＲ５−Ｒ３についても同様の処理を行う。これにより、映像配信のために確保されたリソースが解放される（図７のステップＳ２３）。

番号「２」の通信経路の現在のリソース残量指標の値が「０」である場合には（図７のステップＳ２４，ＹＥＳ）、そのまま一連の処理を終了する。
これに対し、現在のリソース残量指標の値が「０」ではなく「１」である場合には（図７のステップＳ２４，ＮＯ）、リソース残量指標更新部１２６が、リンクＲ１−Ｒ５，Ｒ５−Ｒ３の新たなリソース残量と閾値との大小を比較する。その結果、まだいずれかのリンクのリソース残量が閾値よりも小さい場合には（図７のステップＳ２５，ＮＯ）、そのまま一連の処理を終了する。しかし、両方のリンクのリソース残量が閾値以上になったときには（図７のステップＳ２５，ＹＥＳ）、番号「２」の通信経路のリソース残量指標の値を「１」から「０」に書き換えた後（図７のステップＳ２６）、一連の処理を終了する。

このように、通信経路を構成するすべてのリンクのリソース残量が閾値以上になったときに、その通信経路のリソース残量指標の値を「１」から「０」に戻すことによって、次にこの通信経路に対するリソース確保要求がきたときに、リソース残量指標を用いて迅速にリソース確保可否判定を行うことができる。

本実施の形態では、リソース残量指標の書換対象をリソースの確保または解放を行った通信経路に限った場合について説明したが、リソースの確保または解放によってリソース残量と閾値との大小関係が変化したリンクを含むすべての通信経路をリソース残量指標の書換対象とすることもできる。
具体的には、図６のステップＳ７，Ｓ１１においてリソース確保処理を行った結果、いずれかのリンクのリソース残量が閾値よりも小さくなった場合に、そのリンクを含む通信経路を経路テーブル１３２のリンクリストを参照して検索し、その通信経路のリソース残量指標の値を「１」に設定する。
また、図７のステップＳ２３においてリソース解放処理を行った結果、いずれかのリンクのリソース残量が閾値以上になった場合に、そのリンクを含む通信経路を経路テーブル１３２のリンクリストを参照して検索し、それぞれの通信経路についてその通信経路を構成するすべてのリンクのリソース残量と閾値との大小を比較し、すべてのリンクのリソース残量が閾値以上になった通信経路のリソース残量指標の値を「０」に設定する。

図８は、リソース管理サーバの機能ブロック図である。この図では、図２に示した構成要素と同一の構成要素を図２と同一の符号で示している。
図８に示すリソース管理サーバ１Ａの制御部１２Ａは、保守端末１Ｂによるデータベース部１３へのアクセスを可能にする保守運用部１２７を更に有する。例えば、保守端末１Ｂから経路テーブル１３２の表示要求が入力されると、保守運用部１２７はデータベース部１３から経路テーブル１３２を読み出し、保守端末１Ｂのディスプレイに表示する。これにより、リソース管理サーバ１Ａの保守者は、経路テーブル１３２に含まれるリソース残量指標を閲覧できる。

なお、リソース残量指標は、リソース確保可否の判定以外にも、次のように利用することができる。
リソース残量指標の値が頻繁に「１」になる通信経路は、リソース残量に余裕がない状況に陥りやすいので、リソースが不足していると考えられる。このため、所定期間内で指数の値が「１」になる回数を通信経路毎に計数し、リソースが不足している通信経路を検出することによって、リンクの増設契機を与えることができる。
また、リソース残量指数の値が「１」になった通信経路を利用する可能性のある端末に、その通信経路のリソース残量に余裕がないことを通知するようにしてもよい。例えば、リソース残量に余裕がなくなった通信経路を介して配信サーバから人気番組の配信を受ける可能性のある端末に、上述の通知を行うことなどが考えられる。この通知を行うことによって、人気番組を見る予定のユーザに、早期のリソース確保を促すことができる。

本発明は、広域通信ネットワークを利用した高品質の通信サービスに利用することができる。

本発明の一実施の形態にかかるリソース管理サーバが適用されるシステムの全体構成を示すブロック図である。 リソース管理サーバの機能ブロック図である。 アドレスリストのデータ構造の一例を示す図である。 経路テーブルのデータ構造の一例を示す図である。 リンクリソース管理テーブルのデータ構造の一例を示す図である。 リソース管理サーバによるリソース確保処理の流れを示すフローチャートである。 リソース管理サーバによるリソース解放処理の流れを示すフローチャートである。 リソース管理サーバの変形例の機能ブロック図である。

符号の説明

１，１Ａ…リソース管理サーバ、１Ｂ…保守端末、１１…送受信部、１２，１２Ａ…制御部、１２１…メッセージ解析部、１２２…通信経路検索部、１２３…リソース確保可否判定部、１２４…応答処理部、１２５…リソース確保・解放処理部、１２６…リソース残量指標更新部、１２７…保守運用部、１３…データベース部、１３１…アドレスリスト、１３２…経路テーブル、１３３…リンクリソース管理テーブル、２…通信ネットワーク、ＡＳ…アプリケーションサーバ、Ｒ…ルータ、Ｔ…端末（Ｔ１…配信サーバ）。

Claims (6)

1. リソース確保要求メッセージに応じて、通信ネットワークに属する端末間の通信経路において通信に必要なリソースを確保するリソース管理装置であって、
   前記通信経路毎に利用可能なリソース残量と予め設定された閾値との大小を示す残量情報を記憶する残量情報記憶手段と、
   前記リソース残量が前記閾値よりも大きいことを前記残量情報が示している場合に、前記リソース確保要求メッセージに基づくリソース確保が可能であると判定するリソース確保可否判定手段と
   を備えることを特徴とするリソース管理装置。
2. 請求項１に記載のリソース管理装置において、
   前記リソース確保可否判定手段によりリソース確保が可能であると判定されたときに、リソース確保を許諾する旨の応答メッセージを前記リソース確保要求メッセージの送信元に送信するメッセージ送信手段を更に備えることを特徴とするリソース管理装置。
3. 請求項１または２に記載のリソース管理装置において、
   リソース確保処理を行うことにより前記リソース残量が前記閾値よりも小さくなったときと、確保されたリソースを解放する処理を行うことにより前記リソース残量が前記閾値よりも大きくなったときに、前記残量情報の内容を書き換える残量情報更新手段を更に備えることを特徴とするリソース管理装置。
4. リソース確保要求メッセージに応じて、通信ネットワークに属する端末間の通信経路において通信に必要なリソースを確保するリソース管理方法であって、
   前記通信経路毎に利用可能なリソース残量と予め設定された閾値との大小を示す残量情報を保持するステップと、
   前記リソース残量が前記閾値よりも大きいことを前記残量情報が示している場合に、前記リソース確保要求メッセージに基づくリソース確保が可能であると判定するステップと
   を備えることを特徴とするリソース管理方法。
5. 請求項４に記載のリソース管理方法において、
   リソース確保が可能であると判定したときに、リソース確保を許諾する旨の応答メッセージを前記リソース確保要求メッセージの送信元に送信するステップを更に備えることを特徴とするリソース管理方法。
6. 請求項４または５に記載のリソース管理方法において、
   リソース確保処理を行うことにより前記リソース残量が前記閾値よりも小さくなったときと、確保されたリソースを解放する処理を行うことにより前記リソース残量が前記閾値よりも大きくなったときに、前記残量情報の内容を書き換えるステップを更に備えることを特徴とするリソース管理方法。
   

Images