(57)【要約】【課題】リソース管理装置を分散配備することによって得られる全体の処理能力を向上させる。【解決手段】（ｂ）のように、リンクａ〜ｆのそれぞれのリソース容量を複数に分割し、リソース容量の一部ずつを複数台のリソース管理装置Ｃ，Ｄに管理させる。これにより、（ａ）のように各リソース管理装置の管理範囲をリンクによって分割する場合と比較して、各リソース管理装置の管理範囲が広がる。よって、１つの通信サービス利用要求で使用されるリンクが複数台のリソース管理装置の管理範囲に及ぶ頻度は低くなり、これに伴ってリソース管理装置間で利用要求を転送する回数も少なくなる。【選択図】        図７
2004260537.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク中の各リンクのリソース利用状況の情報を保持するリソース情報保持手段と、前記ネットワークに接続される複数の端末の間の通信で利用されるリンクを検索する利用リンク検索手段と、検索された前記リンクで前記通信に必要なリソースを確保できるかどうかを前記リソース利用状況の情報を参照して判定するリソース確保可否判定手段とを有するリソース管理装置を複数備え、
各リンクのリソース容量は、前記リソース管理装置のそれぞれに一部ずつ割り当てられ、
前記リソース管理装置のリソース情報保持手段は、割り当てられたリソース容量に対するリソース利用状況の情報を保持することを特徴とするリソース管理システム。
【請求項２】
請求項１に記載されたリソース管理システムにおいて、
前記リソース管理装置は、前記リソース確保可否判定手段でリソースを確保できないリンクがあると判定したときに、そのリンクで前記通信に必要なリソースの確保要求を他のリソース管理装置に送信する送信手段を更に有し、
前記リソース確保可否判定手段は、他のリソース管理装置からのリソースの確保要求を受信したときに、前記確保要求で指定されているリンクで通信に必要なリソースを確保できるかどうかを前記リソース利用状況の情報を参照して判定する手段を含むことを特徴とするリソース管理システム。
【請求項３】
ネットワーク中の各リンクのリソース利用状況の情報を保持し、前記ネットワークに接続される複数の端末の間の通信で利用されるリンクを検索するとともに、検索された前記リンクで前記通信に必要なリソースを確保できるかどうかを前記リソース利用状況の情報を参照して判定するリソース管理方法において、
前記通信で利用されるリンクの検索と前記通信に必要なリソースの確保可否判定とからなる一連の処理を分散並列処理する装置を複数設け、
各リンクのリソース容量を複数に分割し、リソース容量の一部ずつを前記装置のそれぞれに割り当て、割り当てられたリソース容量に対するリソース利用状況の情報を保持させることを特徴とするリソース管理方法。
【請求項４】
請求項３に記載されたリソース管理方法において、
一の装置で前記通信に必要なリソースを確保できないリンクがあると判定したときに、そのリンクで前記通信に必要なリソースの確保を他の装置に要求し、
前記他の装置で要求された前記リンクで通信に必要なリソースを確保できるかどうかを前記リソース利用状況の情報を参照して判定することを特徴とするリソース管理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークにおけるリソース利用状況を管理し、新規な通信サービス利用要求に対してその通信に必要なリソースを確保できるかどうかを判定するリソース管理システムおよび方法に関する。
【０００２】
【従来の技術】
ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワーク上での映像・音声などの通信サービスでは、ネットワークのリソース容量を超える利用要求によって発生する輻輳などによる品質劣化に対しては再送制御などのアプリケーションレベルの品質向上技術では大きな効果が望めず、ネットワークレイヤにおいて各通信フローに対し排他的に利用リソースを確保する必要がある。
各通信フローの利用リソースを確保するためには、ネットワークにおけるリソース利用状況を管理し、新規な通信サービス利用要求に対して利用を許容するかどうかの受付判定を行う受付制御機能が必要となる。この機能を実現するには、転送レイヤにおいてルータ・スイッチなどの自律的な動作によって行う方法と、制御レイヤにおいてルータ・スイッチとは独立したサーバ内での処理によって行う方法とがあり、それぞれについて研究が行われている。
【０００３】
受付制御を制御レイヤで行う場合、リソース管理装置において、転送レイヤで決定される各通信フローのネットワーク上における経路、すなわちどのリンクを利用するかの特定と、各リンクのリソース利用状況の管理とを行わなければならない。リンクのリソース利用状況の管理にあたっては、そのリンクのリソース容量と現在利用中のリソースとを基に利用可能な残りのリソースを求め、これらの管理を行う。受付制御を制御レイヤで行う従来例として、例えば次のような方法が提案されている
【０００４】
まず、リソース管理装置でネットワーク内のルーティング情報を収集する。このルーティング情報には、ネットワーク中の各リンクのリソース容量および接続情報が含まれている。次いで、各リンクの接続情報を基に、通信がどのリンクを通過するかの経路計算を行う。そして、経路計算の結果を基に経路テーブルを作成し、各リンクのリソース容量からリンクリソース管理テーブルを作成する。これらのテーブルは、ネットワークを運用する前に予め作成しておく。
【０００５】
そして、ネットワークの運用開始後、リソース管理装置で通信サービスの利用要求を受信すると、要求された通信の発着ＩＰアドレスを基に経路テーブルから、どのリンクを利用する通信であるかを特定する。そして、特定されたリンクのそれぞれについて、リンクリソース管理テーブルから、要求された通信が必要とするリソースがそのリンクに残っているかどうかをチェックする。ここで、リソースの残りが足りれば、リンクリソース管理テーブルにおける利用中リソースに上記通信が必要とするリソースの値を加算し、通信サービスの利用要求に対して許諾応答する。逆にリソースの残りが足りなければ、利用要求に対して拒絶応答する（例えば、非特許文献１参照。）。
【０００６】
【非特許文献１】
矢口、他：「大規模ＩＰ網における管理サーバを用いたリソース管理方式の一提案と具体例」、信学総合大会、Ｂ−６−３１（２００２）
【０００７】
【発明が解決しようとする課題】
このような受付制御技術をサービスに適用する場合、サービスによっては大規模なネットワークを対象にする可能性があり、リソース管理装置１台では処理能力が不足することも想定される。このような場合には、リソース管理装置の台数を増やし、複数台のリソース管理装置に分散並列処理を行わせることで、全体の処理能力を向上させることも考えなければならない。
しかしながら、上述した受付制御技術の従来例では、各リンクのリソース利用状況を管理するにあたって、リンクリソース管理テーブルとその検索・更新処理をすべてのリソース管理装置で共有する必要がある。つまり、あるリソース管理装置が受け付ける通信サービスの利用要求で使用されるリンクとそのリソース利用状況は、そのリソース管理装置で検索・更新可能となっている必要があるので、リンクリソース管理テーブルを各リソース管理装置毎に単純に分割することはできない。
【０００８】
例えば、リンクリソース管理テーブルを単純にリンクによって分割し、あるリソース管理装置がネットワーク中の一部のリンクを担当するというような管理方法を採用すると、１つの利用要求で使用されるリンクが１台のリソース管理装置の管理範囲に収まらず、複数台のリソース管理装置の管理範囲に及ぶことも起こりうる。この場合、その利用要求に対して何度もリソース管理装置間で利用要求を転送しなければならなくなり、その無駄な処理負荷によって分散並列処理を行う効果が減殺されてしまう。
このように、リンクリソース管理テーブルを複数台のリソース管理装置毎に単純に分割することができないために、従来はリソース管理装置の分散配備が困難であるという問題があった。
【０００９】
本発明はこのような課題を解決するためになされたものであり、その目的は、リソース管理装置を分散配備することによって得られる全体の処理能力を従来より向上させることにある。
【００１０】
【課題を解決するための手段】
このような目的を達成するために、本発明のリソース管理システムは、ネットワーク中の各リンクのリソース利用状況の情報を保持するリソース情報保持手段と、ネットワークに接続される複数の端末の間の通信で利用されるリンクを検索する利用リンク検索手段と、検索されたリンクで通信に必要なリソースを確保できるかどうかをリソース利用状況の情報を参照して判定するリソース確保可否判定手段とを有するリソース管理装置を複数備え、各リンクのリソース容量は、リソース管理装置のそれぞれに一部ずつ割り当てられ、リソース管理装置のリソース情報保持手段は、割り当てられたリソース容量に対するリソース利用状況の情報を保持することを特徴とする。
リソース管理装置のそれぞれにはネットワーク中の各リンクのリソース容量の一部ずつが割り当てられているので、リソース管理装置のそれぞれでネットワーク中の各リンクを管理することになる。このため、各リソース管理装置の管理範囲を単純にリンクによって分割する場合と比較して、各リソース管理装置の管理範囲が広範囲になるので、１つの通信サービス利用要求で使用されるリンクが複数台のリソース管理装置の管理範囲に及ぶ頻度は低くなり、これに伴ってリソース管理装置間で利用要求を転送する回数も少なくなる。
【００１１】
ここで、リソース管理装置が、リソース確保可否判定手段でリソースを確保できないリンクがあると判定したときに、そのリンクで通信に必要なリソースの確保要求を他のリソース管理装置に送信する送信手段を更に有し、リソース確保可否判定手段が、他のリソース管理装置からのリソースの確保要求を受信したときに、確保要求で指定されているリンクで通信に必要なリソースを確保できるかどうかをリソース利用状況の情報を参照して判定する手段を含むようにしてもよい。
これにより、一のリソース管理装置でリンクのリソースを確保できない場合に、他のリソース管理装置で確保することが可能となる。
【００１２】
また、本発明のリソース管理方法は、ネットワーク中の各リンクのリソース利用状況の情報を保持し、ネットワークに接続される複数の端末の間の通信で利用されるリンクを検索するとともに、検索されたリンクで通信に必要なリソースを確保できるかどうかをリソース利用状況の情報を参照して判定するリソース管理方法において、通信で利用されるリンクの検索と通信に必要なリソースの確保可否判定とからなる一連の処理を分散並列処理する装置を複数設け、各リンクのリソース容量を複数に分割し、リソース容量の一部ずつを前記装置のそれぞれに割り当て、割り当てられたリソース容量に対するリソース利用状況の情報を保持させることを特徴とする。
【００１３】
ここで、一の装置で、通信に必要なリソースを確保できないリンクがあると判定したときに、そのリンクで通信に必要なリソースの確保を他の装置に要求し、他の装置で、要求されたリンクで通信に必要なリソースを確保できるかどうかをリソース利用状況の情報を参照して判定するようにしてもよい。
【００１４】
【発明の実施の形態】
以下、本発明の一実施の形態について、図面を参照して詳細に説明する。
図１は、本発明の一実施の形態に係るリソース管理システムが適用されるＩＰネットワークの概要を示す図である。説明を簡単にするため、ＩＰネットワーク５の構成要素としてコアルータ５１，５２，５３およびエッジルータ６１，６２，６３，６４のみを示している。エッジルータ６１〜６４は、ネットワーク５を利用する端末４１，４２，４３，４４，４５，４６を収容するものとする。
アプリケーションサーバ３は、ユーザ向けに通信サービスの利用手段を提供するサーバであり、ユーザの端末４１から希望する通信サービスの利用要求があると、リソース管理システムに対し、その通信に必要なネットワーク５のリソース確保を要求する。
【００１５】
リソース管理システムは、分散配備された複数台のリソース管理装置によって構成される。本実施の形態では、２台のリソース管理装置１，２によって構成されるものとする。リソース管理装置１，２は、ＩＰネットワーク５に接続される２つの端末の間の通信における経路を特定し、その通信に必要なリソースをその経路上の各リンクで確保できるかどうかを判定し、そのリソースを確保できる場合には確保し、確保できない場合には通信サービスの利用要求を拒む応答を行う装置である。このため、リソース管理装置１，２は、それぞれネットワーク５中で利用される可能性のあるすべてのリンクのリソース利用状況を管理する。具体的には、各リンクのリソース容量、現在利用中のリソース、利用可能な残りのリソースを管理する。
【００１６】
ここで、リソース管理装置１，２は、各リンクのリソース容量を２分割したその一部ずつを管理する。例えば、あるリンクのリソース容量が１００Ｍｂｐｓの場合、リソース管理装置１，２ではそれぞれそのリンクのリソース容量を５０Ｍｂｐｓとして管理する。したがって、リソース管理装置１，２は、それぞれすべてのリンクのリソース利用状況を管理するが、各リンクの全リソース容量の管理は行わない。
なお、リソース管理装置１，２はＩＰネットワーク５内のいずれかのルータに接続される。
【００１７】
次に、リソース管理装置１の構成について説明する。図２は、リソース管理装置１およびアプリケーションサーバ３の構成を示すブロック図である。
リソース管理装置１は、端末情報入力部１１と、端末収容エッジ対応情報記憶部１２と、リンク情報収集部１３と、経路算出部１４と、経路情報記憶部１５と、リンクリソース管理テーブル作成部１６と、リンクリソース管理テーブル記憶部１７と、リソース確保要求受付判定部１８と、管理装置間通信部１９とを有している。
【００１８】
ここで、端末情報入力部１１には、管理者の操作やアプリケーションサーバ経由によるユーザの操作などによって、ネットワーク５を利用する端末４１〜４６に関する情報が入力される。例えば、端末４１〜４６のＩＰアドレス、および端末４１〜４６のそれぞれが収容されるエッジノード（ノード名、ノードＩＰアドレスなど）が入力される。これらの情報を端末収容エッジ対応情報１１Ａと呼ぶ。端末収容エッジ対応情報１１Ａの一例を図４（ａ）に示す。
端末収容エッジ対応情報記憶部１２は、端末情報入力部１１から入力される端末収容エッジ対応情報１１Ａを保持する。
【００１９】
リンク情報収集部１３は、ネットワーク５中で利用される可能性のあるすべてのリンクについて、そのリンクのリソース容量５Ａおよび接続情報５Ｂを収集する。ここで、リンクの接続情報５Ｂとは、どのノードのどのインタフェースと、どのノードのどのインタフェースが接続されているリンクであるかを示す情報である。リソース容量５Ａおよび接続情報５Ｂの収集は、例えばＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）によるＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）情報の収集によって行うことができる。
【００２０】
経路算出部１４は、リンク情報収集部１３によって収集された各リンクの接続情報５Ｂを基に、利用される可能性のあるすべてのエッジノードについて、あるエッジノードから他のエッジノードヘの通信がどのリンクを通過するかという経路計算を行い、経路情報１４Ａを作成する。経路情報１４Ａの一例を図４（ｂ）に示す。
経路情報記憶部１５は、経路算出部１４によって作成された経路情報１４Ａを保持する。
【００２１】
リンクリソース管理テーブル作成部１６は、リンク情報収集部１３によって収集された各リンクのリソース容量５Ａから、リンクリソース管理テーブル１６Ａを作成する。リンクリソース管理テーブル１６Ａは、例えば図４（ｃ）に示すように、ネットワーク５中で利用される可能性のあるすべてのリンクに、それぞれのリソース容量と現在利用中のリソースとが対応付けられたテーブルである。リソース容量から現在利用中のリソースを減算することによって、利用可能な残りのリソースを求めることができる。
【００２２】
上述したように、リソース管理装置１，２は、各リンクのリソース容量を２分割したその一部ずつを管理するようになっている。したがって、リソース管理装置１におけるリンクリソース管理テーブル１６Ａは、リソース管理装置１に割り当てられたリソース容量に基づいて作成される。例えば、リソース容量が１００Ｍｂｐｓのリンクについて、リソース管理装置１に５０Ｍｂｐｓが割り当てられている場合、リンクリソース管理テーブル１６Ａは割り当てられた５０Ｍｂｐｓに基づいて作成される。なお、リソース管理装置１，２に対する各リンクのリソース容量の割り当ては、予め設定されている。
リンクリソース管理テーブル記憶部１７は、リンクリソース管理テーブル作成部１６によって作成されたリンクリソース管理テーブル１６Ａを保持する。
【００２３】
リソース確保要求受付判定部１８は、アプリケーションサーバ３からのリソース確保要求３２Ａを受け付け、リソース確保が可能かどうかを判定する。その具体的な手順は次の通りである。
アプリケーションサーバ３からのリソース確保要求３２Ａには、ユーザが要求する通信における発側・着側端末のＩＰアドレス、およびその通信に必要なリソースの情報が含まれている。リソース確保要求受付判定部１８ではまず、この発側・着側端末のＩＰアドレスを基に、端末収容エッジ対応情報１１Ａから、発側・着側端末を収容しているエッジノードを検索する。
続いて、得られたエッジノードを基に、経路情報１４Ａからその通信が通過するリンクを検索する。通信が通過するリンクは１つの場合もあるが、複数の場合もある。
【００２４】
続いて、リンクリソース管理テーブル１６Ａを参照し、得られたすべてのリンクについて通信に必要なリソースを確保できるかどうかを判定する。具体的には、リソース管理装置１に割り当てられたリソース容量の残りと通信に必要なリソースとを比較し、前者が後者よりも大きければリソース確保が可能であると判定し、その逆であればリソース確保が不可能であると判定する。
【００２５】
この結果、すべてのリンクについてリソース確保が可能であると判定した場合には、アプリケーションサーバ３に対して、リソース確保が可能である旨の応答１８Ａを返信する。また、該当するリンクについて、リンクリソース管理テーブル１６Ａにおける利用中リソースの値に、新たに利用されるリソースの値を加算する。
一方、少なくとも１つのリンクについてリソース確保が不可能であると判定した場合には、管理装置間通信部１９を用いて、分散配備された他のリソース管理装置２に対して、リソース確保が不可能なリンクのリソース確保要求１９Ａを送信する。
【００２６】
リソース管理装置２でそのリンクについてリソース確保が可能な場合には、ユーザが要求する通信が通過するリンクのすべてについてリソース確保が可能となるので、リソース管理装置２から返信されるリソース確保が可能である旨の応答２９Ｂをリソース管理装置１の管理装置間通信部１９で受信することにより、リソース確保要求受付判定部１８でアプリケーションサーバ３に対してリソース確保が可能である旨の応答１８Ａを返信する。また、リソース管理装置１でリソース確保が可能であると判定したリンクについて、リンクリソース管理テーブル１６Ａにおける利用中リソースの値に、新たに利用されるリソースの値を加算する。
【００２７】
これに対し、リソース管理装置２でもそのリンクについてリソース確保が不可能な場合には、リソース管理装置２から返信されるリソース確保が不可能である旨の応答２９Ｂをリソース管理装置１の管理装置間通信部１９で受信することにより、リソース確保要求受付判定部１８でアプリケーションサーバ３に対してリソース確保が不可能である旨の応答１８Ａを返信する。
【００２８】
ここでは、リソース管理装置１がリソース管理装置２に対してリソース確保要求１９Ａを送信する場合について説明したが、これとは逆に、リソース管理装置２がリソース管理装置１に対してリソース確保要求２９Ａを送信する場合もある。この場合には、リソース管理装置２から送信されるリソース確保要求２９Ａをリソース管理装置１の管理装置間通信部１９で受信すると、リソース確保要求受付判定部１８で、要求されたリンクについて通信に必要なリソースを確保できるかどうかを、リンクリソース管理テーブル１６Ａを参照して判定する。
【００２９】
この結果、要求されたリンクについてリソース確保が可能であると判定した場合には、送信元のリソース管理装置２に対して、リソース確保が可能である旨の応答１９Ｂを返信する。また、該当するリンクについて、リンクリソース管理テーブル１６Ａにおける利用中リソースの値に、新たに利用されるリソースの値を加算する。
一方、要求されたリンクについてリソース確保が不可能であると判定した場合には、送信元のリソース管理装置２に対して、リソース確保が不可能である旨の応答１９Ｂを返信する。
【００３０】
図３に示すように、リソース管理装置２もまた、リソース管理装置１と同様の構成を有している。すなわち、リソース管理装置２は、端末情報入力部２１と、端末収容エッジ対応情報記憶部２２と、リンク情報収集部２３と、経路算出部２４と、経路情報記憶部２５と、リンクリソース管理テーブル作成部２６と、リンクリソース管理テーブル記憶部２７と、リソース確保要求受付判定部２８と、管理装置間通信部２９とを有している。
【００３１】
なお、図２に示すように、アプリケーションサーバ３は、ユーザが使用する端末４１からの通信サービスの利用要求を受け付ける利用要求受付部３１と、その通信が利用するネットワーク５のリソース確保をリソース管理装置１に対して要求するリソース確保要求部３２とを有している。リソース確保要求部３２がリソース管理装置１に対して送信するリソース確保要求３２Ａには、ユーザが要求する通信における発側・着側端末のＩＰアドレス、およびその通信に必要なリソースの情報が含まれている。
【００３２】
なお、本実施の形態では、リンクリソース管理テーブル記憶部１７，２７によってリソース情報保持手段が構成され、リソース確保要求受付判定部１８，２８によって利用リンク検索手段およびリソース確保可否判定手段が構成される。
また、本実施の形態におけるリソース管理装置１，２の各部の機能は、所定のプログラムにしたがってコンピュータを動作させることによって実現することができる。
【００３３】
次に、本実施の形態の動作について説明する。まず、図２および図３を参照し、リソース管理装置１，２の事前設定について説明する。
リソース管理装置１では、管理者やユーザの操作により端末情報入力部１１を用いて端末収容エッジ対応情報１１Ａが入力されると、入力された端末収容エッジ対応情報１１Ａを端末収容エッジ対応情報記憶部１２で保持する。
【００３４】
一方、リンク情報収集部１３では、ネットワーク５中で利用される可能性のあるすべてのリンクについて、そのリンクのリソース容量５Ａおよび接続情報５Ｂを収集する。これらの情報５Ａ，５Ｂを基に、経路算出部１４およびリンクリソース管理テーブル作成部１６によって、経路情報１４Ａおよびリンクリソース管理テーブル１６Ａを作成する。ここで、リンクリソース管理テーブル１６Ａは、リソース管理装置１に割り当てられたリソース容量に基づいて作成される。例えば、ルータ６４−ルータ５２のリンクの実際のリソース容量１００Ｍｂｐｓのうち１／２がリソース管理装置１に割り当てられているとすると、リンクリソース管理テーブル１６Ａは割り当てられた５０Ｍｂｐｓに基づいて作成される。経路情報１４は経路情報記憶部１５で保持し、リンクリソース管理テーブル１６Ａはリンクリソース管理テーブル記憶部１４で保持する。
【００３５】
リソース管理装置２でも同様に、端末収容エッジ対応情報２１Ａの保持し、リソース容量５Ａおよび接続情報５Ｂの収集、経路情報２４Ａ・リンクリソース管理テーブル２６Ａの作成を行い保持する。リンクリソース管理テーブル２６Ａは、リソース管理装置２に割り当てられたリソース容量に基づいて作成される。例えば、ルータ６４−ルータ５２のリンクの実際のリソース容量１００Ｍｂｐｓのうち残りの１／２がリソース管理装置１に割り当てられているとすると、リンクリソース管理テーブル１６Ａは割り当てられた５０Ｍｂｐｓに基づいて作成される。
【００３６】
次に、図１〜図５を参照し、通信開始時の処理について説明する。図５は、通信開始時の処理の流れを示すフローチャートである。ここでは、映像配信サービスにおいて、帯域リソースを確保する場合を例にして説明する。
ユーザは、端末４１からアプリケーションサーバ３の利用要求受付部３１を用いて、希望する通信サービスの利用要求を行う（ステップＳ１）。利用要求受付手段３１が映像コンテンツの一覧を提供するＷｅｂアプリケーションサーバ機能を有している場合には、ユーザはＷｅｂ（ＨＴＴＰ）で希望するコンテンツの視聴を選択するればよい。ユーザが端末４６の配信サーバから６Ｍｂｐｓのビットレートをもつ映像ストリームコンテンツを受信し視聴する通信サービスを選択したとすると、アプリケーションサーバ３ではユーザの端末ＩＰアドレスと、コンテンツの配信元である端末４６のＩＰアドレス、またコンテンツを視聴するのに確保が必要な帯域幅（６Ｍｂｐｓ）の情報を含むリソース確保要求３２Ａを、リソース確保要求部３２からリソース管理装置１に対して送信する（ステップＳ２）。
【００３７】
リソース管理装置１では、アプリケーションサーバ３からのリソース確保要求３２Ａをリソース確保要求受付判定部１８で受け付け、帯域確保が可能どうかを判定する。具体的にはまず、その通信における発側端末４６および着側端末４１のそれぞれのＩＰアドレスを基に、端末収容エッジ対応情報１１Ａから発側・着側端末４６，４１を収容しているエッジノードを検索し、発エッジがルータ６４、着エッジがルータ６１であることを知る（ステップＳ３）。次いで、経路情報１４Ａからその通信が通過するリンクを検索し、ルータ６４−ルータ５２，ルータ５２−ルータ６１の２リンクを利用することを知る（ステップＳ４）。次いで、リンクリソース管理テーブル１６Ａから、各リンクの残帯域を検索する（ステップＳ５）。次いで、各リンクの残帯域と通信に必要な帯域６Ｍｂｐｓとを比較し、各リンクにおいて通信に必要な帯域が確保できるかどうかを判定する。
【００３８】
この結果、すべてのリンクについて帯域確保が可能であると判定した場合には（ステップＳ６，ＹＥＳ）、アプリケーションサーバ３に対して、帯域確保が可能である旨の応答１８Ａを返信する（ステップＳ７）。また、該当するリンクについて、リンクリソース管理テーブル１６Ａにおける利用中帯域の値に６Ｍｂｐｐｓを加算する（ステップＳ８）。
リソース管理装置１から帯域確保が可能である旨の応答１８Ａを受信したアプリケーションサーバ３では、その旨の応答３１Ａをユーザが使用する端末４１に返信する（ステップＳ９）。これにより、端末４１は端末４６の配信サーバと通信を開始する。
【００３９】
一方、ルータ６４−ルータ５２のリンクで残帯域が３Ｍｂｐｓしかなかったとすると、リソース管理装置１のリソース確保要求受付判定部１８では、ルータ５２−ルータ６１のリンクでは通信に必要な帯域６Ｍｂｐｚを確保を確保できるが、ルータ６４−ルータ５２のリンクでは確保できないと判定する（ステップＳ６，ＮＯ）。この場合には、管理装置間通信部１９を用いて、分散配備された他のリソース管理装置２に対して、ルータ６４−ルータ５２のリンクのみについて、６Ｍｂｐｓのリソース確保要求１９Ａを送信する（ステップＳ１０）。
【００４０】
リソース管理装置２では、リソース管理装置１からのリソース確保要求１９Ａをリソース確保要求受付判定部２８で受け付け、リンクリソース管理テーブル２６Ａから、指定されたルータ６４−ルータ５２のリンクの残帯域を検索する（ステップＳ１１）。そして、検索結果を基に、指定されたリンクにおいて通信に必要な６Ｍｂｐｓの帯域が確保できるかどうかを判定する。
この結果、指定されたリンクについて帯域確保が可能であると判定した場合には（ステップＳ１２，ＹＥＳ）、管理装置間通信部２９を用いて、リソース管理装置１に対して、帯域確保が可能である旨の応答２９Ｂを返信する（ステップＳ１３）。また、該当するリンクについて、リンクリソース管理テーブル２６Ａにおける利用中帯域の値に６Ｍｂｐｓを加算する（ステップＳ１４）。
【００４１】
リソース管理装置２から帯域確保が可能である旨の応答２９Ｂを受信したリソース管理装置１では、ユーザが要求する通信が通過するリンクのすべてについて帯域確保が可能となるので、リソース確保要求受付判定部１８でアプリケーションサーバ３に対して帯域確保が可能である旨の応答１８Ａを返信し（ステップＳ７）、リソース管理装置１で帯域を確保するルータ６４−ルータ５２のリンクについて、リンクリソース管理テーブル１６Ａにおける利用中リソースの値に６Ｍｂｐｓを加算する（ステップＳ８）。その後のアプリケーションサーバ３および端末４１の動作は上述したものと同じである。
【００４２】
これに対し、リソース管理装置２でも指定されたリンクについて帯域確保が不可能であると判定した場合には（ステップＳ１２，ＮＯ）、管理装置間通信部２９を用いて、リソース管理装置１に対して、帯域確保が不可能である旨の応答２９Ｂを返信する（ステップＳ１５）。
リソース管理装置２から帯域確保が不可能である旨の応答２９Ｂを受信したリソース管理装置１では、リソース確保要求受付判定部１８でアプリケーションサーバ３に対して帯域確保が不可能である旨の応答１８Ａを返信する（ステップＳ１６）。
リソース管理装置１から帯域確保が不可能である旨の応答１８Ａを受信したアプリケーションサーバ３では、その旨の応答３１Ａをユーザが使用する端末４１に返信する（ステップＳ１７）。この場合、端末４１は通信サービスを利用することができない。
【００４３】
なお、ステップＳ９の後、端末４１，４６間の通信終了時に、リソース管理装置１，２は確保した帯域リソースを解放する処理を行う。具体的には、ルータ６４−ルータ５２，ルータ５２−ルータ６１の２つのリンクの帯域をリソース管理装置１のみで確保した場合には、リソース管理装置１で各リンクの利用中リソースから６Ｍｂｐｓを減算する。一方、少なくとも１つのリンクの帯域をリソース管理装置２で確保した場合には、リソース管理装置１からリソース管理装置２へ通信が終了した旨を通知し、リソース管理装置２でもリンクの利用中リソースから６Ｍｂｐｓを減算する。
【００４４】
次に、図６および図７を参照し、本実施の形態のようにリソース管理することによって得られる作用効果について説明する。
図６に示すようなリソース容量が１００Ｍｂｐｓのリンクａ，ｂ，ｃ，ｄ，ｅ，ｆを管理する場合、リンクリソース管理テーブルを単純にリンクによって分割し、図７（ａ）に示すようにリンクａ〜ｃをリソース管理装置Ａで管理し、リンクｄ〜ｆをリソース管理装置Ｂで管理するというような管理方法を採用すると、端末４７，４８間の通信で利用されるリンクが２台のリソース管理装置Ａ，Ｂの管理範囲に及ぶことになる。この場合、この通信の利用要求に対してリソース管理装置Ａ，Ｂ間で利用要求を転送しなければならなくなり、その無駄な処理負荷によって分散並列処理を行う効果が減殺されてしまう。
【００４５】
これに対し、リンクリソース管理テーブルを各リンクのリソース容量によって分割し、図７（ｂ）に示すようにリソース管理装置Ｃ，Ｄのそれぞれにリンクａ〜ｆのリソース容量を５０Ｍｂｐｓずつ割り当てる本実施の形態に係る管理方法を採用すると、リソース管理装置Ｃ，Ｄのそれぞれでリンクａ〜ｆのすべてを管理することになる。したがって、端末４７，４８間の通信の利用要求に対して、原則としてリソース管理装置Ｃ，Ｄ間で利用要求を転送する必要がなくなる。ただし、通信に必要なリソースが不足するリンクが存在する場合には、リソース管理装置Ｃ，Ｄ間での利用要求の転送が必要となるが、その頻度は図７（ａ）に示した管理方法と比べるとかなり低くなる。
【００４６】
また、通信終了時に、確保されたリソースを解放する処理を行う場合、図７（ａ）に示した管理方法では、リソース管理装置Ａ，Ｂ間で通信を行ってリンクａ〜ｆの利用中リソースの減算を行う必要がある。これに対し、図７（ｂ）に示した本実施の形態に係る管理方法では、原則としてリソース管理装置Ｃ，Ｄ間の通信を行わず、リソース管理装置Ｃ，Ｄのいずれかで解放処理を行えばよい。
したがって、本実施の形態に係る管理方法によれば、２台のリソース管理装置で分散並列処理を行う際の処理負荷を低減することができる。よって、ネットワーク事集者、通信サービス事集者は、ユーザに対してより高品質な通信サービスを大規模に提供し、収益をあげることが可能になる。
【００４７】
なお、本実施の形態では、リソース管理システムが２台のリソース管理装置１，２によって構成される例を示したが、３台以上のリソース管理装置によって構成される場合もある。この場合、ネットワーク５の各リンクのリソース容量を複数に分割し、リソース容量の一部ずつを複数台のリソース管理装置に管理させる。リソース確保処理の際には、リソース確保要求を受信したリソース管理装置は、図１に示したリソース管理装置２と同様の処理を行うが、該当リンクでリソース確保が不可能な場合には、リソース確保要求を別のリソース管理装置に対して転送する。この結果、すべてのリソース管理装置で該当リンクでリソース確保が不可能な場合には、最終的にその旨の応答１８Ａがアプリケーションサーバ３に対して返信されることになる。
【００４８】
また、本実施の形態では、複数のリソース管理装置のそれぞれがネットワーク５中で利用される可能性のあるすべてのリンクのリソース利用状況を管理する例を示したが、必ずしもそれぞれがすべてのリンクのリソース利用状況を管理しなくても、分散並列処理を行う際の処理負荷を低減する効果は得られる。
【００４９】
【発明の効果】
以上説明したように、本発明では、ネットワーク中の各リンクのリソース容量を複数に分割し、リソース容量の一部ずつを複数台のリソース管理装置に管理させる。これにより、各リソース管理装置の管理範囲が広がるので、１つの通信サービス利用要求で使用されるリンクが複数台のリソース管理装置の管理範囲に及ぶ頻度は低くなり、これに伴ってリソース管理装置間で利用要求を転送する回数も少なくなる。したがって、処理負荷を低減して分散並列処理を行うことができる。
【００５０】
また、本発明では、一のリソース管理装置でリソースを確保できないリンクがある場合に、他のリソース管理装置に対しそのリンクのリソースを確保できるか否かを判定させる。これにより、他のリソース管理装置で管理するリソースに余裕があれば、そのリソースを利用することにより通信が可能になる。
【図面の簡単な説明】
【図１】本発明の一実施の形態に係るリソース管理システムが適用されるＩＰネットワークの概要を示す図である。
【図２】一方のリソース管理装置およびアプリケーションサーバの構成を示すブロック図である。
【図３】他方のリソース管理装置の構成を示すブロック図である。
【図４】リソース管理装置で保持する各種情報の一例を示す図である。
【図５】通信開始時の処理の流れを示すフローチャートである。
【図６】本発明の一実施の形態によって得られる作用効果を説明するための図である。
【図７】リンクリソース管理テーブルの分割方法を示す図である。
【符号の説明】
１，２…リソース管理装置、３…アプリケーションサーバ、５…ＩＰネットワーク、５Ａ…リソース容量５Ａ、５Ｂ…接続情報、１１，２１…端末情報入力部、１１Ａ，２１Ａ…端末収容エッジ対応情報、１２，２２…端末収容エッジ対応情報記憶部、１３，２３…リンク情報収集部、１４，２４…経路算出部、１４Ａ，２４Ａ…経路情報、１５，２５…経路情報記憶部、１６，２６…リンクリソース管理テーブル作成部、１６Ａ，２６Ａ…リンクリソース管理テーブル、１７，２７…リンクリソース管理テーブル記憶部、１８，２８…リソース確保要求受付判定部、１８Ａ，１９Ｂ，２９Ｂ…リソース確保要求の応答、１９，２９…管理装置間通信部、１９Ａ，２９Ａ，３２Ａ…リソース確保要求、３１…利用要求受付部、３１Ａ…通信利用要求の応答、３２…リソース確保要求部、４１〜４８…端末、４１Ａ…通信利用要求、５１〜５３…コアルータ、６１〜６４…エッジルータ。
【図１】
2004260537.tif 000003
【図２】
2004260537.tif 000004
【図３】
2004260537.tif 000005
【図４】
2004260537.tif 000006
【図５】
2004260537.tif 000007
【図６】
2004260537.tif 000008
【図７】
2004260537.tif 000009