JP2006270786A - リソース管理方法およびリソース管理装置、ならびにリソース管理システム - Google Patents

Abstract

【課題】リソース管理サーバ間の通信が一時的に不能になった場合でも、その前後でリソースの管理を正確に継続できるようにする。
【解決手段】一のリソース管理装置において、管理範囲が隣接する他のリソース管理装置へ送信すべきメッセージのファイルを作成するステップＳ１４と、他のリソース管理装置が通信可能となったときに他のリソース管理装置へファイルを送信するステップＳ１９と、他のリソース管理装置において、ファイルを受信するステップと、他のリソース管理装置が通信不能となる前の管理範囲内におけるリソースの管理内容をファイルに基づいて更新するステップとを備える。
【選択図】 図８

Description

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

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

このようなリソース管理の一例として、次のような方法が開示されている。
まず、通信ネットワークの運用開始前に、その通信ネットワーク中のリンク（接続情報）および各リンクのリソース容量を含むルーティング情報に基づいて、パケットが通過する経路を計算し、これを「経路テーブル」に記憶させるとともに、各リンクのリソース容量を「リソース管理テーブル」に記憶させる。このリソース管理テーブルによって、その通信ネットワークにおける総リソース容量と利用中のリソース容量または利用可能な残りリソース容量とが管理される。

通信ネットワークの運用開始後にあっては、リソース管理サーバにおいて、通信サービスの利用要求（リソース確保要求）を受け付けると、要求された通信の発着ＩＰアドレスを基に経路テーブルから当該通信に必要となるリンクを特定する。そして、リソース管理テーブルを参照し、これらのリンクのそれぞれについて当該通信に必要となる容量が利用可能か否かをチェックする。その結果、十分な容量が利用可能である場合には、通信サービスの利用要求に対して許諾応答するとともに、上記リンクからなるリソースを確保する。具体的には、リソース管理テーブルの利用中リソース容量に当該通信に割り当てられる容量を加算して記憶させる。これに対し、リソースを確保できない場合には、利用要求に対して拒絶応答する（例えば、特許文献１および非特許文献１を参照）。
また、リソースの使用終了時には、それまで通信用に確保していたリソースを速やかに解放する。

特開２００３−２５８８５５号公報 矢口他、「大規模ＩＰ網における管理サーバを用いたリソース管理方式の一提案と具体例」、信学総合大会、Ｂ−６−３１（２００２）

通信ネットワークが大規模になると、管理しなければならないリソースが膨大となるとともに、リソース管理サーバが対応すべきリソース確保要求が増大するので、１台のリソース管理サーバが通信ネットワーク全体のリソースを管理することは困難となる。このような問題に対処するには、通信ネットワークを、例えば地域ごとに複数の管理範囲に分割し、これらの管理範囲にそれぞれリソース管理サーバを設けることが考えられる。
異なる事業者によって運用されている複数の通信ネットワークを接続する場合には、各通信ネットワークにそれぞれリソース管理サーバを設ければよい。これは、大きな通信ネットワークを事業者ごとに分割し、それぞれに各事業者の通信ネットワークを管理範囲とするリソース管理装置を設けたものと捉えることができる。

このような通信ネットワークにおいて、通信を行う発端末と着端末とがそれぞれ異なる管理範囲に属する場合には、複数の管理範囲にまたがる一連のリソースを複数のリソース管理サーバの間で連携しながら管理する必要がある。その一つの管理方法として、管理範囲が隣接するリソース管理サーバ同士でリソースに関するメッセージを送受信し、このメッセージに基づいてそれぞれが管理範囲内のリソースを管理する方法が考えられる。

具体的に言えば、通信を開始するにあたって、リソース確保要求を受信したリソース管理サーバがその管理範囲内において必要なリソースを確保するとともに、必要に応じて管理範囲が隣接するリソース管理サーバ（以下、「隣接サーバ」と略記する）へリソース確保要求のメッセージを送信する。このメッセージを受信した隣接サーバもまたその管理範囲内においてリソースを確保し、必要に応じて他の隣接サーバへリソース確保要求のメッセージを送信する。

また、通信終了の際には、リソース解放要求を受信したリソース管理サーバがその管理範囲内において当該通信のために確保されていたリソースを解放するとともに、先にリソース確保要求のメッセージを送信した隣接サーバへ今度はリソース解放要求のメッセージを送信する。このメッセージを受信した隣接サーバもまたその管理範囲内においてリソースを解放し、先にリソース確保要求のメッセージを送信した他の隣接サーバへリソース解放要求のメッセージを送信する。

しかし、この方法では、例えば隣接サーバがその管理範囲内において通信に必要なリソースを確保した状態で故障し、その後のリソース解放要求のメッセージを受信できなかったとすると、隣接サーバの故障を修理し再起動したときに、本来解放されているべきリソースが確保されたままとなる。通信ネットワーク上では、当該通信の終了とともにリソースの使用も終了しているので、実際に利用されているリソース容量と隣接サーバのリソース管理テーブルで管理されている利用中リソース容量との間に齟齬が生じる。このため、隣接サーバが故障する前後でそのリソースの管理を正確に継続することができないという問題があった。

本発明は、このような課題を解決するためになされたものであり、その目的は、管理範囲が隣接するリソース管理サーバ同士でリソースに関するメッセージを送受信しながら複数の管理範囲にまたがる一連のリソースを管理するシステムにおいて、リソース管理サーバ間の通信が一時的に不能になった場合でも、その前後でリソースの管理を正確に継続できるようにすることにある。

このような目的を達成するために、本発明にかかるリソース管理方法は、互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けられた複数のリソース管理装置の間で前記通信ネットワークのリソースに関するメッセージを送受信し、このメッセージに基づいてそれぞれの管理範囲内におけるリソースを管理するリソース管理方法であって、一のリソース管理装置において、このリソース管理装置の管理範囲に隣接する他の管理範囲を管理する他のリソース管理装置へ送信すべきメッセージのファイルを作成するファイル作成ステップと、前記他のリソース管理装置が通信可能となったときに、前記他のリソース管理装置へ前記ファイルを送信するファイル送信ステップとを備えることを特徴とする。

このリソース管理方法は、前記他のリソース管理装置が通信不能になったことを検出する通信不能検出ステップを更に備えるものであってもよい。
また、前記通信不能検出ステップは、前記他のリソース管理装置から送信される通信状態メッセージを受信する通信状態メッセージ受信ステップと、前記通信状態メッセージが受信されたときから所定時間内に次の通信状態メッセージが受信されない場合に、前記他のリソース管理装置が通信不能になったと判定する判定ステップとを備えるものであってもよい。
また、前記ファイル作成ステップは、前記他のリソース管理装置の通信不能が検出されたときに、前記ファイルの作成を開始するものであってもよい。

また、前記ファイルが作成されていることを表すファイル存在通知を前記他のリソース管理装置へ送信するファイル存在通知送信ステップを更に備えるものであってもよい。
また、前記ファイル存在通知に基づいて前記他のリソース管理装置から送信される前記ファイルの送信依頼メッセージを受信する送信依頼メッセージ受信ステップを更に備え、前記ファイル送信ステップは、前記送信依頼メッセージが受信されたときに、前記ファイルを送信するものであってもよい。

また、前記ファイル作成ステップは、前記他のリソース管理装置に対し通信に必要なリソースの確保を要求するリソース確保要求メッセージ、このリソース確保要求メッセージのキャンセルを表すキャンセルメッセージ、すでに通信のために確保されているリソースの変更を要求するリソース変更要求メッセージおよびすでに通信のために確保されているリソースの解放を要求するリソース解放要求メッセージのうち少なくとも１つに基づいて前記ファイルを作成するものであってもよい。
また、前記他のリソース管理装置において、前記ファイルを受信するファイル受信ステップと、前記他のリソース管理装置が通信不能となる前の管理範囲内におけるリソースの管理内容を、受信された前記ファイルに基づいて更新するリソース管理ステップとを更に備えるものであってもよい。

また、通信に必要なリソースの制御を要求する要求メッセージを受信する要求メッセージ受信ステップと、前記通信の着端末が前記一のリソース管理装置の管理範囲内にあるか否かを判定する着端末存否判定ステップと、前記着端末が前記一のリソース管理装置の管理範囲内にないと判定されたときに、前記他のリソース管理装置へ前記要求メッセージを送信する要求メッセージ送信ステップと、前記要求メッセージに対する応答として前記他のリソース管理装置から返信される応答メッセージを受信する応答メッセージ受信ステップと、受信された前記応答メッセージを前記要求メッセージの送信元へ送信する応答メッセージ送信ステップと、前記要求メッセージを送信した後で前記応答メッセージが受信される前に、前記他のリソース管理装置の通信不能が検出されたときに、前記要求メッセージの送信元へ前記要求メッセージに基づいたリソースの制御をキャンセルさせるキャンセルメッセージを送信するキャンセルメッセージ送信ステップとを更に備えるものであってもよい。

また、通信に必要なリソースの制御を要求する要求メッセージを受信する要求メッセージ受信ステップと、前記他のリソース管理装置の通信不能が検出されると、検出後に前記他のリソース管理装置を経由するリソースの制御を要求する要求メッセージが受信されたときに、前記要求メッセージの送信元へ前記要求メッセージに基づいたリソースの制御を拒絶する拒絶応答メッセージを送信する拒絶応答メッセージ送信ステップとを更に備えるものであってもよい。

また、本発明にかかるリソース管理装置は、互いにリンクされた複数のルータと端末とから構成される通信ネットワークを分割した複数の管理範囲ごとに設けられ、前記通信ネットワークのリソースに関するメッセージを互いに送受信し、このメッセージに基づいてそれぞれの管理範囲内におけるリソースを管理するリソース管理装置であって、このリソース管理装置の管理範囲に隣接する他の管理範囲を管理する他のリソース管理装置へ送信すべきメッセージのファイルを作成するファイル作成手段と、前記他のリソース管理装置が通信可能となったときに、前記他のリソース管理装置へ前記ファイルを送信するファイル送信手段とを備えることを特徴とする。

このリソース管理装置は、前記他のリソース管理装置が通信不能になったことを検出する通信不能検出手段を更に備えるものであってもよい。
また、このリソース管理装置の通信状態を表す通信状態メッセージを前記他のリソース管理装置へ定期的に送信する通信状態メッセージ送信手段を更に備え、前記通信不能検出手段は、前記他のリソース管理装置から送信される通信状態メッセージを受信する通信状態メッセージ受信手段と、前記通信状態メッセージが受信されたときから所定時間内に次の通信状態メッセージが受信されない場合に、前記他のリソース管理装置が通信不能になったと判定する判定手段とを備えるものであってもよい。
また、前記ファイル作成手段は、前記通信不能検出手段によって前記他のリソース管理装置の通信不能が検出されたときに、前記ファイルの作成を開始するものであってもよい。

また、前記ファイルが作成されていることを表すファイル存在通知を前記他のリソース管理装置へ送信するファイル存在通知送信手段を更に備えるものであってもよい。
また、前記ファイル存在通知に基づいて前記他のリソース管理装置から送信される前記ファイルの送信依頼メッセージを受信する送信依頼メッセージ受信手段を更に備え、前記ファイル送信手段は、前記送信依頼メッセージが受信されたときに、前記ファイルを送信するものであってもよい。

また、前記ファイル作成手段は、前記他のリソース管理装置に対し通信に必要なリソースの確保を要求するリソース確保要求メッセージ、このリソース確保要求メッセージのキャンセルを表すキャンセルメッセージ、すでに通信のために確保されているリソースの変更を要求するリソース変更要求メッセージおよびすでに通信のために確保されているリソースの解放を要求するリソース解放要求メッセージのうち少なくとも１つに基づいて前記ファイルを作成するものであってもよい。
また、前記ファイルを受信するファイル受信手段と、このリソース管理装置が通信不能となる前の管理範囲内におけるリソースの管理内容を、受信された前記ファイルに基づいて更新するリソース管理手段とを更に備えるものであってもよい。

また、通信に必要なリソースの制御を要求する要求メッセージを受信する要求メッセージ受信手段と、前記通信の着端末がこのリソース管理装置の管理範囲内にあるか否かを判定する着端末存否判定手段と、前記着端末がこのリソース管理装置の管理範囲内にないと判定されたときに、前記他のリソース管理装置へ前記要求メッセージを送信する要求メッセージ送信手段と、前記要求メッセージに対する応答として前記他のリソース管理装置から返信される応答メッセージを受信する応答メッセージ受信手段と、受信された前記応答メッセージを前記要求メッセージの送信元へ送信する応答メッセージ送信手段と、前記要求メッセージを送信した後で前記応答メッセージが受信される前に、前記通信不能検出手段によって前記他のリソース管理装置の通信不能が検出されたときに、前記要求メッセージの送信元へ前記要求メッセージに基づいたリソースの制御をキャンセルさせるキャンセルメッセージを送信するキャンセルメッセージ送信手段とを更に備えるものであってもよい。

また、通信に必要なリソースの制御を要求する要求メッセージを受信する要求メッセージ受信手段と、前記通信不能検出手段によって前記他のリソース管理装置の通信不能が検出されると、検出後に前記他のリソース管理装置を経由するリソースの制御を要求する要求メッセージが受信されたときに、前記要求メッセージの送信元へ前記要求メッセージに基づいたリソースの制御を拒絶する拒絶応答メッセージを送信する拒絶応答メッセージ送信手段とを更に備えるものであってもよい。

また、本発明にかかるリソース管理システムは、互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けられた複数のリソース管理装置の間で前記通信ネットワークのリソースに関するメッセージを送受信し、このメッセージに基づいてそれぞれの管理範囲内におけるリソースを管理するリソース管理システムであって、一のリソース管理装置は、この一のリソース管理装置の管理範囲に隣接する他の管理範囲を管理する他のリソース管理装置へ送信すべきメッセージのファイルを作成するファイル作成手段と、前記他のリソース管理装置が通信可能となったときに、前記他のリソース管理装置へ前記ファイルを送信するファイル送信手段とを備え、前記他のリソース管理装置は、前記ファイルを受信するファイル受信手段と、この他のリソース管理装置が通信不能となる前の管理範囲内におけるリソースの管理内容を、受信された前記ファイルに基づいて更新するリソース管理手段とを備えることを特徴とする。
なお、前記一または他のリソース管理装置としては、上述した本発明にかかるリソース管理装置を用いることができる。

本発明では、リソース管理装置が他のリソース管理装置へ送信すべきメッセージのファイルを作成し、他のリソース管理装置と通信可能となったときにこのファイルを送信することによって、他のリソース管理装置は受信したファイルから通信不能の間のメッセージを得ることができる。よって、他のリソース管理装置が、通信不能となる以前のその管理範囲内におけるリソースの管理内容を、得られたメッセージに基づいて更新することにより、通信ネットワーク上において実際に利用されているリソースと管理内容との間の齟齬を解消し、他のリソース管理装置が通信不能となる前後でリソースの管理を正確に継続することが可能となる。

また、本発明では、他のリソース管理装置の通信不能状態が検出されたときにファイルの作成を開始することによって、他のリソース管理装置が通信不能の間のメッセージのファイルが作成される。このファイルを受信することによって、他のリソース管理装置は通信不能の間のメッセージを容易に得ることができる。
また、本発明では、リソース解放要求メッセージに基づいてファイルを作成することによって、このファイルを受信した他のリソース管理装置において、終了した通信のために確保されたリソースの解放が可能となる。また、キャンセルメッセージに基づいてファイルを作成することによって、他のリソース管理装置において、キャンセルされた通信のためのリソース確保の中止、またはすでに確保されたリソースの解放が可能となる。

また、本発明では、要求メッセージの送信先である他のリソース管理装置からの応答メッセージが受信される前に、他のリソース管理装置の通信不能が検出されたときに、要求メッセージの送信元へキャンセルメッセージを送信することによって、通信不能になったリソース管理装置から発側のリソース管理装置によって確保されたリソースを解放することができる。したがって、通信不能になったリソース管理装置が復旧するまでの間も、解放されたリソースを有効活用することが可能になる。
また、本発明では、他のリソース管理装置の通信不能が検出されると、検出後に他のリソース管理装置を経由する要求メッセージが受信されたときに、要求メッセージの送信元へ拒絶応答メッセージを送信することによって、通信不能になったリソース管理装置を経由するリソースの確保を防止し、リソースの有効活用が可能になる。

以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
１．第１の実施の形態
１−１．リソース管理システムの概要
図１は、本発明の第１の実施の形態にかかるリソース管理システムの概要を示すブロック図である。
このリソース管理システムは、通信ネットワークのリソースを管理する複数のリソース管理サーバＲＭＳ１，ＲＭＳ２，ＲＭＳ３から構成される。

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

このリソース管理システムでは、通信ネットワークが複数の管理範囲ＮＷ１，ＮＷ２，ＮＷ３に分割され、これらの管理範囲ＮＷ１〜ＮＷ３に対して、それぞれリソース管理サーバＲＭＳ１〜ＲＭＳ３が設けられている。図１においては、リソース管理サーバＲＭＳ１は、管理範囲ＮＷ１のリソースを管理するリソース管理装置、リソース管理サーバＲＭＳ２は、管理範囲ＮＷ２のリソースを管理するリソース管理装置、リソース管理サーバＲＭＳ３は、管理範囲ＮＷ３のリソースを管理するリソース管理装置である。これらのリソース管理サーバＲＭＳ１〜ＲＭＳ３は、互いに通信可能に接続される。
上述した構成は、個々の管理範囲ＮＷ１〜ＮＷ３をそれぞれ一つの通信ネットワーク、リソース管理サーバＲＭＳ１〜ＲＭＳ３をそれぞれ通信ネットワークＮＷ１〜ＮＷ３のリソースを管理するリソース管理装置と捉えることもできる。

アプリケーションサーバＡＳは、端末（例えば、端末Ｔ１１）からの通信要求を受けて、この端末が属する管理範囲（例えば、管理範囲ＮＷ１）のリソースを管理するリソース管理サーバ（例えば、リソース管理サーバＲＭＳ１）に要求メッセージを送信するサーバである。要求メッセージには、リソースの確保を要求するリソース確保要求メッセージ、および、確保されたリソースの解放を要求するリソース解放要求メッセージ等がある。
リソース確保要求メッセージには、要求される通信サービスにおける着端末の識別子（ＩＰアドレス）、確保したいリソース量、メッセージ送信元のサーバのＩＤ（送信元ＩＤ）、さらにメッセージ送信元がリソース管理サーバの場合には、そのサーバで確保されたリソースに付与されたリソースＩＤ（送信元リソースＩＤ）等が含まれる。また、リソース解放要求メッセージには、送信元リソースＩＤ等が含まれる。

なお、図１には、３つのリソース管理サーバＲＭＳ１〜ＲＭＳ３と３つの管理範囲ＮＷ１〜ＮＷ３とが描かれているが、これら以外に通信ネットワークに接続された第４，第５の管理範囲が存在するならば、これら第４，第５の管理範囲に対してそれぞれ第４，第５のリソース管理サーバを設け、これらをリソース管理サーバＲＭＳ１〜ＲＭＳ３と通信可能に接続してもよい。

１−２．リソース管理サーバ（ＲＭＳ）の構成
リソース管理サーバＲＭＳ１〜ＲＭＳ３は、それぞれ通信機能を有するコンピュータであり、それぞれ送受信部、データベース部、リソース制御部、相互生存確認処理部、エラーログ作成部およびエラーログ解析部を有する。これらの基本的な機能はリソース管理サーバＲＭＳ１〜ＲＭＳ３のそれぞれにおいて共通している。
なお、これらの機能は、演算装置（ＭＰＵ）や記憶装置（ＲＯＭおよびＲＡＭ等の内部メモリの他、ＨＤＤ等の外部記憶装置を含む）などのコンピュータのハードウェア資源とこのコンピュータにインストールされたコンピュータ・プログラム（ソフトウェア）とが協働することによって実現されるものである。

図２は、リソース管理サーバＲＭＳｉ（ｉ＝１，２，３）の機能ブロック図である。
送受信部１は、通信インターフェースを備え、アプリケーションサーバＡＳや、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉに隣接する他の管理範囲ＮＷｉ−１，ＮＷｉ＋１を管理する他のリソース管理サーバ（以下、単に「隣接サーバ」という）ＲＭＳｉ−１，ＲＭＳｉ＋１との間で、各種メッセージを送信および受信する。
データベース部２には、リソース管理に必要な各種情報が記録される。
リソース制御部３は、受信されたメッセージに応じて当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内におけるリソースの確保および解放を行うとともに、必要に応じて着側の隣接サーバＲＭＳｉ＋１へ送信すべきメッセージを作成する。

相互生存確認処理部４は、隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１との間で、アプリケーションレベル（起動しているプログラムまたは開始しているサービスレベル）で相互に通信可能か否かを検出する。通信不能となる原因としては、サーバ自体の故障や、サーバ間のＴＣＰコネクションの切断等が考えられる。なお、本実施の形態においては、サーバが通信可能な状態であることを「サーバが生存している」と表現する。
エラーログ作成部５は、リソース制御部３で作成されたメッセージのうち、着側の隣接サーバＲＭＳｉ＋１が通信不能のため送信されなかったメッセージのファイルを作成し保持する。このファイルを「エラーログ」と呼ぶ。
エラーログ解析部６は、発側の隣接サーバＲＭＳｉ−１から送信されるエラーログから元のメッセージを再生する。

以下、リソース管理サーバＲＭＳｉの各部の機能について、さらに詳しく説明する。
１−２−１．データベース部２
図２に示すように、データベース部２は、アドレスリスト２１、経路情報２２およびリソース管理テーブル２３を有する。
ここで、アドレスリスト２１は、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内にある端末のＩＰアドレスのリストである。
図３は、アドレスリスト２１のデータ構造の一例を示す図である。この例においては、アドレスリスト２１は、各端末の「端末ＩＰアドレス」と、その端末を収容するエッジノード（例えば、端末Ｔ１１を収容するルータＲ１１）を表す「端末収容エッジノード名」と、そのエッジノードのＩＰアドレス「端末収容エッジＩＰアドレス」という項目から構成される。

経路情報２２は、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内にあるリソースから構成される通信路の一覧（リスト）データベースである。
図４は、経路情報２２のデータ構造の一例を示す図である。この例においては、経路情報２２は、「発側エッジノード名（またはＩＰアドレス）」と、「着側エッジノード名（またはＩＰアドレス）」と、これらのノードを接続するリソースの容量「リソース容量（ＢＷ）」と、このリソースの詳細「リソース詳細」という項目から構成される。

経路を構成する個々のリソースは、「リソース詳細」に発側エッジノートと着側エッジノードとの間の経路を構成する個々のリソース、すなわちアクセスライン（端末とルータまたはスイッチングハブとの間のパス）やアクセス集線ライン（スイッチングハブとルータとの間のパス）およびリンク（ルータとルータとの間のパス）を列挙することによって定義される。
また、各経路には、「リソースＩＤ」が付与されている。このリソースＩＤは、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内においてユニークなものである。したがって、リソースＩＤを参照することによって、経路を構成するノード間のアクセスラインやリンクを列挙しなくても、管理範囲ＮＷｉ内における経路（リソースの集合）を特定することができる。

リソース管理テーブル２３は、リソース制御部３によって確保されたリソースを管理するテーブルである。
図５は、リソース管理テーブル２３のデータ構造の一例を示す図である。この例においては、リソース管理テーブル２３は、「リソースＩＤ」と、「送信元ＩＤ」と、「送信元リソースＩＤ」という項目から構成される。

ここで、「リソースＩＤ」は、リソース制御部３によって確保されたリソース（経路）を識別するものであり、上述した経路情報２２において使用されるリソースＩＤと同じものである。
「送信元ＩＤ」は、リソース確保要求メッセージの送信元、すなわち当該リソース管理サーバＲＭＳｉにリソース確保要求メッセージを送信した隣接サーバＲＭＳｉ−１（またはアプリケーションサーバＡＳ）の識別子である。
「送信元リソースＩＤ」は、リソース確保要求メッセージの送信元で確保されたリソースに付与されたリソースＩＤである。

１−２−２．リソース制御部３
図２に示すように、リソース制御部３は、メッセージ解析部３１と、着端末存否判定部３２と、リソース管理部３３と、メッセージ作成部３４とから構成される。

ここで、メッセージ解析部３１は、送受信部１で受信された各種メッセージを分析する機能を有する。具体的には、リソース確保要求メッセージが受信されたときには、このメッセージに含まれる着端末のＩＰアドレス、確保したいリソース量、送信元ＩＤおよび送信元リソースＩＤ等を特定する。また、リソース解放要求メッセージが受信されたときには、このメッセージに含まれる送信元リソースＩＤを特定する。また、後述するエラーログ送信依頼メッセージが受信されたときには、着側の隣接サーバＲＭＳｉ＋１よりエラーログの送信依頼があった旨をエラーログ作成部５に通知する。これにより、着側の隣接サーバＲＭＳｉ＋１へ送信すべきメッセージによって作成されたエラーログが送受信部１を介して隣接サーバＲＭＳｉ＋１へ送信されることになる。

着端末存否判定部３２は、データベース部２のアドレスリスト２１を参照して、受信されたリソース確保要求メッセージに含まれるＩＰアドレスに対応する着端末が当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内にあるか否かを判定する機能を有する。

リソース管理部３３は、データベース部２の経路情報２２およびリソース管理テーブル２３を参照して、受信されたリソース確保要求メッセージおよびリソース解放要求メッセージに応じて、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内において必要なリソースの確保および解放を行う機能を有する。この「管理範囲ＮＷｉ内において必要なリソース」とは、発端末が管理範囲ＮＷｉ内にあるとき（すなわち、リソース確保要求メッセージがアプリケーションサーバＡＳから送信されたとき）には、その発端末から管理範囲ＮＷｉのリソース出口ＩＰ、すなわち隣接する他の管理範囲ＮＷｉ＋１への出口となるルータＲ１４までのリソースである。このようなリソースは、リソース管理部３３によって経路情報２２から検索される。このリソースに対応するリソースＩＤは、リソース確保要求メッセージに含まれる送信元ＩＤおよび送信元リソースＩＤとともにリソース確保時にリソース管理テーブル２３に登録され、リソース解放時にリソース管理テーブル２３から削除される。

メッセージ作成部３４は、着側の隣接サーバＲＭＳｉ＋１へ送信すべきメッセージを必要に応じて作成する機能を有する。具体的には、着端末存否判定部３２による判定の結果、リソース確保要求メッセージに含まれるＩＰアドレスに対応する着端末が当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内にないと判定されたときに、隣接サーバＲＭＳｉ＋１へ送信すべきリソース確保要求メッセージを作成する。この際、リソース確保要求メッセージの送信元ＩＤとして、当該リソース管理サーバＲＭＳｉのＩＤを、また送信元リソースＩＤとして、当該リソース管理サーバＲＭＳｉで確保されたリソースのリソースＩＤを付加する。また、リソース解放要求メッセージに含まれる送信元リソースＩＤによって特定されるリソースが隣接サーバＲＭＳｉ＋１に繋がっている場合に、隣接サーバＲＭＳｉ＋１へ送信すべきリソース解放要求メッセージを作成する。

１−２−３．相互生存確認処理部４
図２に示すように、相互生存確認処理部４は、相互生存確認メッセージ作成部４１と、相互生存確認メッセージ解析部４２と、隣接サーバ通信状態判定部４３とから構成される。

ここで、相互生存確認メッセージ作成部４１は、当該リソース管理サーバＲＭＳｉのアプリケーションレベルにおける通信状態を表す相互生存確認メッセージを作成する機能を有する。作成された相互生存確認メッセージは、送受信部１から隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１へ送信される。特に、後述する状態「２−Ｗａｙ」の相互生存確認メッセージは、定期的に隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１へ送信される。その時間間隔は任意に設定可能である。例えば、デフォルトを１０秒間隔とし、１秒〜３分の間で設定変更可能としてもよい。

図６は、相互生存確認メッセージのフォーマットの一例を示す図である。
図６（ａ）に示すように、相互生存確認メッセージは、リソース管理サーバ間メッセージのヘッダ、このメッセージが相互生存確認メッセージであることを表すメッセージ番号、ホップ数、この相互生存確認メッセージ送信元のリソース管理サーバ固有の識別子、各種コード（コード番号、コード一式の長さ、データ）およびベンダーＩＤが含まれる。
相互生存確認メッセージに記載されるコードには、図６（ｂ）に示す３種類がある。

（１）コード名：「リソース管理サーバ通信状態」
相互生存確認メッセージには、当該リソース管理サーバＲＭＳｉの通信状態を表すデータとして、「Ｄｏｗｎ」、「Ａｔｔｅｍｐｔ」、「Ｉｎｉｔ」および「２−Ｗａｙ」のいずれか１つが付加される。
ここで、「Ｄｏｗｎ」は、当該リソース管理サーバＲＭＳｉ自体の故障等によって通信不能であるときに付加される。

「Ａｔｔｅｍｐｔ」は、当該リソース管理サーバＲＭＳｉと隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１との双方間でアプリケーションレベルにおける通信が開通していないときに付加される。例えば、後述する状態「２−Ｗａｙ」の相互生存確認メッセージが所定時間以上、当該リソース管理サーバＲＭＳｉで受信されないときに、状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージが送信されることになる。

「Ｉｎｉｔ」は、隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１から当該リソース管理サーバＲＭＳｉへの一方向のみでアプリケーションレベルにおける通信が開通した（と当該リソース管理サーバＲＭＳｉが判断した）ときに付加される。例えば、隣接サーバＲＭＳｉ＋１から送信された状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージが当該リソース管理サーバＲＭＳｉで受信されたときに、状態「Ｉｎｉｔ」の相互生存確認メッセージが送信されることになる。

「２−Ｗａｙ」は、当該リソース管理サーバＲＭＳｉと隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１との双方間でアプリケーションレベルにおける通信が開通しているときに付加される。例えば、隣接サーバＲＭＳｉ＋１から送信された状態「Ｉｎｉｔ」の相互生存確認メッセージがリソース管理サーバＲＭＳｉで受信されたときや、状態「２−Ｗａｙ」の相互生存確認メッセージが所定時間間隔でリソース管理サーバＲＭＳｉで受信されているときに、状態「２−Ｗａｙ」の相互生存確認メッセージが送信されることになる。
本実施の形態における相互生存確認ステータスの詳細を図７に示す。

（２）コード名：「エラーログ有無」
状態「Ａｔｔｅｍｐｔ」および「Ｉｎｉｔ」の相互生存確認メッセージには、当該リソース管理サーバＲＭＳｉのエラーログ作成部５によって作成されたエラーログの有無を表すデータとして、「Ｎｏ Ｌｏｇ」または「Ｌｏｇ ｅｘｉｓｔ」が表示される。「Ｎｏ Ｌｏｇ」は、エラーログが作成されていないことを表し、「Ｌｏｇ ｅｘｉｓｔ」は、エラーログが作成されていることを表す。「Ｎｏ Ｌｏｇ」または「Ｌｏｇ ｅｘｉｓｔ」が表示された相互生存確認メッセージを送信することによって、着側の隣接サーバＲＭＳｉ＋１へエラーログの有無を通知することが可能となる。

（３）コード名：「リソース管理サーバＩＤ」
相互生存確認メッセージには、エラーログの有無を表すデータを作成した当該リソース管理サーバＲＭＳｉのＩＤとして、「ＲＡ（ＡＣ）Ｉｄｅｎｔｉｆｅｒ」が付加される。

次に、相互生存確認メッセージ解析部４２は、送受信部１で受信された隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１からの相互生存確認メッセージを分析する機能を有する。具体的には、相互生存確認メッセージに含まれる各種コードのデータを抽出し、隣接サーバ通信状態判定部４３へ出力する。特に、当該リソース管理サーバＲＭＳｉが通信不能となっていた間に作成されたエラーログがあることを示す「Ｌｏｇ ｅｘｉｓｔ」が検出されたときには、相互生存確認メッセージの送信元ＩＤ（すなわち、発側の隣接サーバＲＭＳｉ−１のサーバＩＤ）および「Ｌｏｇ ｅｘｉｓｔ」が検出されたことをリソース制御部３のメッセージ作成部２３へ通知する。これにより、メッセージ作成部２３においてエラーログ送信依頼メッセージが作成され、送受信部１を介して隣接サーバＲＭＳｉ−１へ送信されることになる。

隣接サーバ通信状態判定部４３は、相互生存確認メッセージに含まれる各種コードのデータを基に、その相互生存確認メッセージの送信元である隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１の通信状態を判定する機能を有する。
例えば、着側の隣接サーバＲＭＳｉ＋１から送信される状態「２−Ｗａｙ」の相互生存確認メッセージが所定時間間隔で受信されているときには、隣接サーバＲＭＳｉ＋１は通信可能であると判定する。これに対し、先の状態「２−Ｗａｙ」の相互生存確認メッセージが受信されてから所定時間以上にわたって次の状態「２−Ｗａｙ」の相互生存確認メッセージが受信されないときには、隣接サーバＲＭＳｉ＋１が通信不能になったと判定する。判定基準となる上記所定時間は、状態「２−Ｗａｙ」の相互生存確認メッセージが送信される時間間隔に基づいて、任意に設定可能である。

通信不能になったと判定されたときには、その旨をリソース制御部３のメッセージ作成部３４へ通知し、隣接サーバＲＭＳｉ＋１へ送信すべきメッセージをエラーログ作成部５へ出力させる。これにより、隣接サーバ通信状態判定部４３によって隣接サーバＲＭＳｉ＋１の通信不能が検出されると同時に、エラーログ作成部５においてエラーログの作成が開始されることになる。通信不能になったと判定されたときにはまた、相互生存確認メッセージ作成部４１に状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージを作成させる。

また、状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージが受信されたときには、相互生存確認メッセージ作成部４１に状態「Ｉｎｉｔ」の相互生存確認メッセージを作成させる。また、エラーログ作成部５に対し、着側の隣接サーバＲＭＳｉ＋１へ送信すべきメッセージを基に作成されたエラーログがある場合には、その旨を相互生存確認メッセージ作成部４１に通知させる。これにより、相互生存確認メッセージ作成部４１で作成される状態「Ｉｎｉｔ」の相互生存確認メッセージに、エラーログの有無「Ｎｏ Ｌｏｇ」または「Ｌｏｇ ｅｘｉｓｔ」を表示させることが可能となる。
また、状態「Ｉｎｉｔ」の相互生存確認メッセージが受信されたときには、相互生存確認メッセージ作成部４１に状態「２−Ｗａｙ」の相互生存確認メッセージの作成を開始させる。

１−３．リソース管理システムの動作
次に、本実施の形態にかかるリソース管理システムの動作について、図８〜図１０を参照しながら説明する。図８は、通信不能となるリソース管理サーバに対して発側（アプリケーションサーバＡＳ側）の隣接サーバ（ここでは、リソース管理サーバＲＭＳ１）の動作の流れを示すフローチャートである。図９は、通信不能となるリソース管理サーバ（ここでは、リソース管理サーバＲＭＳ２）の動作の流れを示すフローチャートである。図１０は、隣接サーバ間（ここでは、リソース管理サーバＲＭＳ１とＲＭＳ２との間）で送受信されるメッセージのタイミングチャートである。なお、これらの図において、相互に対応するステップには同じ符号が付されている。

１−３−１．リソース管理サーバＲＭＳ１とＲＭＳ２との間、およびリソース管理サーバＲＭＳ２とＲＭＳ３との間で相互に通信可能な場合
リソース管理サーバＲＭＳ２は、相互生存確認メッセージ作成部４１において状態「２−Ｗａｙ」の相互生存確認メッセージを作成し、送受信部１より隣接するリソース管理サーバＲＭＳ１へ所定時間間隔で送信する。
リソース管理サーバＲＭＳ１は、状態「２−Ｗａｙ」の相互生存確認メッセージを所定時間間隔で受信することによって（図８のステップＳ１１，ＹＥＳ）、隣接サーバ通信状態判定部４３において相互生存確認メッセージの送信元であるリソース管理サーバＲＭＳ２が通信可能であると判定する（図８のステップＳ１２）。これにより、リソース管理サーバＲＭＳ２の生存がリソース管理サーバＲＭＳ１によって確認される。

リソース管理サーバＲＭＳ２の生存がリソース管理サーバＲＭＳ１によって確認されている間、リソース管理サーバＲＭＳ１が状態「２−Ｗａｙ」の相互生存確認メッセージをリソース管理サーバＲＭＳ２へ所定時間間隔で送信し続けることによって、リソース管理サーバＲＭＳ１の生存もまたリソース管理サーバＲＭＳ２によって確認される。
同様にして、ソース管理サーバＲＭＳ２とＲＭＳ３との間でも、互いに生存が確認される。
このようにして互いに生存が確認されている間は、リソース管理サーバＲＭＳ１〜ＲＭＳ３の間でリソース確保要求メッセージおよびリソース解放要求メッセージ等を互いに送受信し、これらのメッセージに基づいてそれぞれの管理範囲ＮＷ１〜ＮＷ３内におけるリソースの確保および解放をデータベース部２およびリソース制御部３によって行う。

１−３−２．リソース管理サーバＲＭＳ２が通信不能となった場合
ある通信サービスに必要なリソースを確保した状態で、リソース管理サーバＲＭＳ２が故障によって通信不能になったと仮定する。このとき、リソース管理サーバＲＭＳ１では、リソース管理サーバＲＭＳ２からの状態「２−Ｗａｙ」の相互生存確認メッセージが受信されなくなる（図８のステップＳ１１，ＮＯ）。このため、リソース管理サーバＲＭＳ１は、先の状態「２−Ｗａｙ」の相互生存確認メッセージが受信されてから所定時間経過後に、隣接サーバ通信状態判定部４３において相互生存確認メッセージの送信元であるリソース管理サーバＲＭＳ２が通信不能になったと判定する（図８のステップＳ１３）。

この後、相互生存確認メッセージ作成部４１において状態「２−Ｗａｙ」の相互生存確認メッセージの作成を停止し、これに代えて状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージの作成・送信を行う。

また、リソース管理サーバＲＭＳ２が通信不能の間に上記通信サービスが終了し、この通信サービスのために確保されたリソースの解放を要求するリソース解放要求メッセージがアプリケーションサーバＡＳからリソース管理サーバＲＭＳ１に送られてきたときには、自己の管理範囲ＮＷ１内において確保されていたリソースをデータベース部２およびリソース制御部３によって解放するとともに、リソース管理サーバＲＭＳ２へ送信すべきリソース解放要求メッセージを作成する。リソース管理サーバＲＭＳ２は通信不能であるから、作成されたリソース解放要求メッセージをエラーログ作成部５へ出力し、エラーログを作成する（図８のステップＳ１４）。このエラーログの作成は、リソース管理サーバＲＭＳ２からの状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージが受信されるまで行われる（図８のステップＳ１５，ＮＯ）。

１−３−３．リソース管理サーバＲＭＳ２が再び通信可能となった場合
リソース管理サーバＲＭＳ２の故障を修理し再起動させると（図９のステップＳ２１）、リソース管理サーバＲＭＳ２は、自己が有する隣接リソース管理サーバのリストにしたがってＴＣＰコネクション接続を能動的に行う（図９のステップＳ２２）。隣接リソース管理サーバのリストには、ＲＭＳ１およびＲＭＳ３が記載されているので、リソース管理サーバＲＭＳ２は、リソース管理サーバＲＭＳ１およびＲＭＳ３に対してＴＣＰコネクション接続を行う。ＴＣＰコネクション接続に失敗した場合には、繰り返しリトライする。リトライ回数は、予め設定可能である。以下、リソース管理サーバＲＭＳ２とＲＭＳ３との間の処理の説明を一部省略する。

リソース管理サーバＲＭＳ２からＲＭＳ１へのＴＣＰコネクションが確立した後、リソース管理サーバＲＭＳ２は、相互生存確認メッセージ作成部４１において状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージを作成し、アプリケーションレベルで送受信部１よりリソース管理サーバＲＭＳ１へ送信する（図９のステップＳ２３）。

状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージを受信したリソース管理サーバＲＭＳ１は（図８のステップＳ１５，ＹＥＳ）、この相互生存確認メッセージの送信元であるリソース管理サーバＲＭＳ２に対してＴＣＰコネクション接続を能動的に行う（図８のステップＳ１６）。リソース管理サーバＲＭＳ１からＲＭＳ２へのＴＣＰコネクションが確立した後、リソース管理サーバＲＭＳ１は、相互生存確認メッセージ作成部４１において状態「Ｉｎｉｔ」の相互生存確認メッセージを作成する。リソース管理サーバＲＭＳ２が通信不能の間にエラーログが作成されているので、状態「Ｉｎｉｔ」の相互生存確認メッセージには「Ｌｏｇ ｅｘｉｓｔ」を表示させる。この状態「Ｉｎｉｔ」の相互生存確認メッセージを、アプリケーションレベルで送受信部１よりリソース管理サーバＲＭＳ２へ送信する（図８のステップＳ１７）。

状態「Ｉｎｉｔ」の相互生存確認メッセージを受信したリソース管理サーバＲＭＳ２は（図９のステップＳ２４，ＹＥＳ）、相互生存確認メッセージ作成部４１において状態「２−Ｗａｙ」の相互生存確認メッセージを作成し、アプリケーションレベルで送受信部１よりリソース管理サーバＲＭＳ１へ送信する（図９のステップＳ２５）。

状態「２−Ｗａｙ」の相互生存確認メッセージを受信したリソース管理サーバＲＭＳ１は（図８のステップＳ１１，ＹＥＳ）、双方向のＴＣＰコネクションが確立した状態になるので、隣接サーバ通信状態判定部４３においてリソース管理サーバＲＭＳ２が通信可能になったと判定し（図８のステップＳ１２）、相互生存確認メッセージ作成部４１において状態「２−Ｗａｙ」の相互生存確認メッセージを作成し、送受信部１よりリソース管理サーバＲＭＳ２へ送信する（図１０のステップＳ３１）。
以後、状態「２−Ｗａｙ」の相互生存確認メッセージをリソース管理サーバＲＭＳ１とＲＭＳ２との間で定期的に送受信することによって、両サーバの通信状態の監視、すなわち両サーバ間のＴＣＰコネクションの双方向監視および両サーバ間の双方向アプリケーション生存監視を行う。

一方、図９のステップＳ２４において、リソース管理サーバＲＭＳ２に受信された状態「Ｉｎｉｔ」の相互生存確認メッセージには、「Ｌｏｇ ｅｘｉｓｔ」と表示されている（図９のステップＳ２６，ＹＥＳ）。このため、リソース管理サーバＲＭＳ２は、２−Ｗａｙ状態確立後、メッセージ作成部２３においてエラーログ送信依頼メッセージを作成し、送受信部１よりリソース管理サーバＲＭＳ１へ送信する（図９のステップＳ２７）。

エラーログ送信依頼メッセージを受信したリソース管理サーバＲＭＳ１は（図８のステップＳ１８，ＹＥＳ）、エラーログ送信依頼メッセージの送信元であるリソース管理サーバＲＭＳ２用のエラーログ（すなわち、リソース管理サーバＲＭＳ２へ送信すべきリソース解放要求メッセージによってエラーログ作成部５において作成されたエラーログ）を、送受信部１よりリソース管理サーバＲＭＳ２へ送信する（図８のステップＳ１９）。このようなエラーログの取得は、ＦＴＰ（File Transfer Protocol）を利用することができる。

リソース管理サーバＲＭＳ２は、エラーログを取得すると（図９のステップＳ２８，ＹＥＳ）、エラーログ解析部６においてエラーログから元のリソース解放要求メッセージを抽出し、リソース管理サーバＲＭＳ２が通信不能となる以前の管理範囲ＮＷ２内におけるリソースの管理内容を、データベース部２およびリソース制御部３によって更新する（図９のステップＳ２９）。

リソースの管理内容の更新方法について具体的に説明する。
まず、エラーログ解析部６によって抽出されたリソース解放要求メッセージをメッセージ解析部３１において分析し、このメッセージに含まれる送信元リソースＩＤを特定する。

この送信元リソースＩＤは、当該リソース管理サーバＲＭＳ２が通信不能となる以前に受信されたリソース確保要求メッセージに含まれた「送信元リソースＩＤ」と同じものである。上述したように、リソース確保要求メッセージに含まれた「送信元リソースＩＤ」は、リソース確保要求メッセージが受信されたときに管理範囲ＮＷ２内で確保されたリソースのリソースＩＤとともに、リソース管理テーブル２３に登録される。したがって、リソース解放要求メッセージに含まれる送信元リソースＩＤをキーにしてリソース管理テーブル２３を参照することにより、上記リソース確保要求メッセージが受信されたときに管理範囲ＮＷ２内で確保されたリソースを特定することができる。

このようにして特定されたリソースをリソース管理部３３において解放するとともに、このリソースのリソースＩＤをそれに対応する送信元ＩＤおよび送信元リソースＩＤとともにリソース管理テーブル２３から削除する。
また、当該リソース管理サーバＲＭＳ２の管理範囲ＮＷ２内で確保されたリソースが、隣接する管理範囲ＮＷ３に繋がっている場合には、管理範囲ＮＷ３を管理するリソース管理サーバＲＭＳ３へ送信すべきリソース解放要求メッセージをメッセージ作成部３４において作成する。この際、リソース解放要求メッセージの送信元リソースＩＤとして、当該リソース管理サーバＲＭＳ２で解放したリソースのリソースＩＤを付加する。このようにして作成されたリソース解放要求メッセージを、送受信部１よりリソース管理サーバＲＭＳ３へ送信する。

リソース管理サーバＲＭＳ２が通信不能（すなわち２−Ｗａｙ状態以外の状態）の間には、その管理範囲ＮＷ２内において新たにリソースが確保されることはない。したがって、リソース管理サーバＲＭＳ２が通信不能の間のリソース解放要求メッセージによって作成されたエラーログを用いて、リソース管理サーバＲＭＳ２が通信不能となる以前のリソースの管理内容を更新することにより、リソースの管理内容を通信ネットワーク上において実際に利用されているリソースに合わせることができる。よって、リソース管理サーバＲＭＳ２が通信不能となる前後でリソースの管理を正確に継続することが可能となる。

また、本実施の形態では、リソース管理サーバＲＭＳ２が通信不能となったことをリソース管理サーバＲＭＳ１が検出したときにエラーログの作成を開始するので、このエラーログをリソース管理サーバＲＭＳ２が受信することによって、リソース管理サーバＲＭＳ２は通信不能の間のメッセージを容易に取得することができる。
なお、リソース管理サーバＲＭＳ２の通信状態にかかわらず、リソース管理サーバＲＭＳ１がリソース管理サーバＲＭＳ２へ送信すべきメッセージのファイルを常時作成し、このファイルを受信したリソース管理サーバＲＭＳ２が、ファイルから通信不能の間のメッセージのみを選択的に抽出して利用するようにしてもよい。

また、本実施の形態では、通信不能となったリソース管理サーバＲＭＳ２からのエラーログ送信依頼メッセージを待って、リソース管理サーバＲＭＳ１からエラーログをリソース管理サーバＲＭＳ２へ送信する例を示したが、エラーログ送信依頼メッセージを待たずにエラーログを送信するようにしてもよい。

また、本実施の形態では、隣接する２つのリソース管理サーバの間で、状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージ、状態「Ｉｎｉｔ」の相互生存確認メッセージ、および状態「２−Ｗａｙ」の相互生存確認メッセージのやり取りを行うことによって双方向のＴＣＰコネクションが確立したと判定する３−Ｗａｙ方式を採用した例を示した。しかし、隣接する２つのリソース管理サーバがともに状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージを送信し、一方のサーバからの状態「Ａｔｔｅｍｐｔ」の相互生存確認メッセージを受信した他方のサーバが状態「２−Ｗａｙ」の相互生存確認メッセージを返信することによって、ＴＣＰコネクションが確立したと判定する２−Ｗａｙ方式を採用することもできる。

また、本実施の形態では、通信不能となったリソース管理サーバＲＭＳ２へ送信すべきメッセージのうち、リソース解放要求メッセージに基づいてエラーログを作成する例を示したが、その他のメッセージのエラーログを作成してもよい。
例えば、特定の通信サービスのために確保されたリソースだけではなく、通信不能となったリソース管理サーバＲＭＳ２の管理範囲ＮＷ２内において確保された全リソースの解放を要求する全リソース解放要求メッセージに基づいてエラーログを作成してもよい。
また、先に送信されたリソース確保要求メッセージのキャンセルを表すキャンセルメッセージに基づいてエラーログを作成してもよい。

また、通信サービスに必要なリソースの確保を要求するリソース確保要求メッセージや、すでに通信サービスのために確保されているリソースの変更を要求するリソース変更要求メッセージに基づいてエラーログを作成してもよい。
通信ネットワークの帯域は、リソース管理サーバによって管理される管理クラスと管理されない非管理クラスの２つに分けられている。リソース管理サーバがダウンしているときには、リソース確保の保証は得られないものの、ユーザは非管理クラスを使って通信することができる。ここで、上述したようにリソース確保要求メッセージに基づいてエラーログを作成することによって、リソース管理サーバがダウンしていたため非管理クラスを使わざるを得なかった通信を再起動後に管理クラスに移すことが可能となり、高品質な通信を提供できるようになる。

２．第２の実施の形態
次に、本発明の第２の実施の形態として、リソース確保要求に対してリソースを確保できたか否かを応答する機能を有する形態について説明する。
第２の実施の形態においては、上述した第１の実施の形態における構成要素に相当するものには同一符号を用いることとし、適宜その説明を省略する。
図１１は、本実施の形態で用いられるリソース管理サーバＲＭＳｉ（ｉ＝１，２，３）の機能ブロック図である。
リソース制御部１０３は、メッセージ解析部１３１と、着端末存否判定部３２と、リソース管理部１３３と、メッセージ作成部１３４とから構成される。

ここで、メッセージ作成部１３４は、第１の実施の形態におけるメッセージ作成部３４で作成される各種メッセージの他に、送受信部１で受信されたリソース確保要求メッセージに対する応答メッセージを作成する機能を有する。具体的には、受信されたリソース確保要求に応じたリソースの確保に成功した場合であって、着端末存否判定部３２による判定の結果、リソース確保要求メッセージに含まれるＩＰアドレスに対応する着端末が当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内にあると判定されたときに、リソースが確保されたことを示す確保応答メッセージを作成する。これに対し、受信されたリソース確保要求に応じたリソースの確保に失敗したときには、リソース確保要求を拒絶する拒絶応答メッセージを作成する。

上述したように、リソース確保要求メッセージには、「送信元ＩＤ」（リソース管理サーバＲＭＳｉへリソース確保要求メッセージを送信した送信元サーバのＩＤ）および「送信元リソースＩＤ」（送信元サーバで確保されたリソースのリソースＩＤ）が付加されている。このリソース確保要求メッセージに対する応答メッセージには、リソース確保要求メッセージにおける「送信元リソースＩＤ」が付加され、「送信元ＩＤ」によって特定される送信元サーバへ送受信部１より返信される。

メッセージ解析部１３１は、第１の実施の形態におけるメッセージ解析部３１の機能に加えて、リソース確保要求メッセージの送信先である隣接サーバＲＭＳｉ＋１から返信される応答メッセージが受信されたときには、この応答メッセージに含まれる「送信元リソースＩＤ」を特定する機能を有する。この「送信元リソースＩＤ」は、応答メッセージが受信されたリソース管理サーバＲＭＳｉにおいては、自己の管理範囲ＮＷｉ内で確保されたリソースの「リソースＩＤ」に相当する。

リソース管理部１３３は、第１の実施の形態におけるリソース管理部３３の機能に加えて、メッセージ解析部１３１によって特定された「リソースＩＤ」をキーにしてリソース管理テーブル１２３を参照し、対応する「送信元ＩＤ」および「送信元リソースＩＤ」を取得する。これらを基に、受信された応答メッセージと同種のメッセージがメッセージ作成部１３４において作成され、当該リソース管理サーバＲＭＳｉへリソース確保要求メッセージを送信した送信元サーバへ送受信部１より返信される。
拒絶応答メッセージが受信されたときには、さらに、メッセージ解析部１３１によって特定された「リソースＩＤ」によって識別されるリソースを解放するとともに、「リソースＩＤ」をそれに対応する「送信元ＩＤ」および「送信元リソースＩＤ」とともにリソース管理テーブル１２３から削除する。

データベース部１０２は、アドレスリスト２１、経路情報２２およびリソース管理テーブル１２３を有する。
図１２は、リソース管理テーブル１２３のデータ構造の一例を示す図である。この例においては、リソース管理テーブル１２３には、「待ち状態」という項目が追加されている。この「待ち状態」は、リソース管理サーバＲＭＳｉが着側の隣接サーバＲＭＳｉ＋１へリソース確保要求メッセージを送信した後に、送信先である隣接サーバＲＭＳｉ＋１から応答メッセージを受信したか否か、すなわち応答待ち状態であるか否かを示す。例えば、リソース確保要求メッセージを送信したときに、「待ち状態」に値「１」を立て、この要求メッセージに対する応答メッセージを受信したときに値「０」に戻す。

以上の構成によって、通信サービスに必要なリソースが複数のリソース管理サーバＲＭＳ１〜ＲＭＳ３にまたがる場合であっても、リソース確保要求メッセージを最初に送信したアプリケーションサーバＡＳへ応答メッセージを返信することができる。これにより、アプリケーションサーバＡＳは、一連のリソースを確保できたか否かを確認することが可能となる。

［通信不能判定によるキャンセルメッセージの返信］
さらに、本実施の形態では、相互生存確認処理部４の隣接サーバ通信状態判定部４３によって着側の隣接サーバＲＭＳｉ＋１が通信不能になったと判定されたときに、その旨がリソース制御部１０３のリソース管理部１３３およびメッセージ作成部１３４へ通知される。

リソース管理部１３３は、この通知を受けると、リソース管理テーブル１２３の「待ち状態」等を参照し、通信不能となった隣接サーバＲＭＳｉ＋１へ送信したリソース確保要求メッセージに応答待ち状態のものがあるか否かをチェックする。その結果、応答待ちのリソース確保要求メッセージがあるときには、このリソース確保要求メッセージを送信する際に自己の管理範囲ＮＷｉ内で確保されたリソースを解放するとともに、このリソースに対応する「リソースＩＤ」、「送信元ＩＤ」および「送信元リソースＩＤ」をリソース管理テーブル１２３から削除する。さらに、「送信元ＩＤ」および「送信元リソースＩＤ」を、応答待ち状態のリソース確保要求メッセージがあった旨とともにメッセージ作成部１３４へ通知する。

この通知を受けて、メッセージ作成部１３４は、リソース確保要求メッセージに基づくリソース確保をキャンセルさせるキャンセルメッセージを作成する。このキャンセルメッセージには、リソース管理部１３３から通知された「送信元リソースＩＤ」を付加する。そして、当該リソース管理サーバＲＭＳｉへリソース確保要求メッセージを送信した送信元サーバを「送信元ＩＤ」によって特定し、この送信元サーバへキャンセルメッセージを送受信部１より返信する。

リソース確保要求メッセージの送信先サーバから返信されるキャンセルメッセージが受信されたときには、上述した拒絶応答メッセージが受信されたときと同様に処理する。すなわち、まず、メッセージ解析部１３１によって、キャンセルメッセージに含まれる「送信元リソースＩＤ」、すなわち当該リソース管理サーバＲＭＳｉにおける「リソースＩＤ」を特定し、リソース管理部１３３において、「リソースＩＤ」に対応する「送信元ＩＤ」および「送信元リソースＩＤ」を取得する。そして、「リソースＩＤ」によって識別される管理範囲ＮＷｉ内で確保されたリソースを解放するとともに、「リソースＩＤ」を「送信元ＩＤ」および「送信元リソースＩＤ」とともに削除する。さらに、当該リソース管理サーバＲＭＳｉへリソース確保要求メッセージを送信した送信元サーバを「送信元ＩＤ」によって特定し、この送信元サーバへ「送信元リソースＩＤ」を付加したキャンセルメッセージを送受信部１より返信する。

これにより、複数のリソース管理サーバＲＭＳ１〜ＲＭＳ３にまたがる一連のリソースの確保が完了する前にリソース管理サーバＲＭＳ１〜ＲＭＳ３のいずれかが故障等によって通信不能になった場合には、通信不能になったリソース管理サーバから発側のリソース管理サーバによって確保されたリソースを解放することができる。したがって、通信不能になったリソース管理サーバが復旧し通信可能になるまでの間も、解放されたリソースを有効活用することが可能になる。

［通信不能判定による拒絶応答メッセージの返信］
また、リソース管理部１３３は、上述した着側の隣接サーバＲＭＳｉ＋１が通信不能になった旨の通知を受けると、その後に隣接サーバＲＭＳｉ＋１を経由するリソースの確保を要求するリソース確保要求メッセージが当該リソース管理サーバＲＭＳｉで受信されても、そのリソースの確保を行わない。この際、メッセージ作成部１３４は、リソース確保要求を拒絶する拒絶応答メッセージを作成する。この拒絶応答メッセージは、リソース確保要求メッセージの送信元サーバへ送受信部１より返信される。
これにより、故障等によって通信不能になったリソース管理サーバを経由するリソースの確保を防止し、リソースの有効活用が可能になる。

以上では、リソース確保要求メッセージに対してキャンセルメッセージまたは拒絶応答メッセージを返信する例を示したが、リソース変更要求メッセージ等、リソースの制御を要求する他のメッセージに対して同様の処理を行ってもよい。

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

本発明の第１の実施の形態にかかるリソース管理システムの概要を示すブロック図である。 本発明の第１の実施の形態におけるリソース管理サーバの機能ブロック図である。 本発明の第１の実施の形態におけるアドレスリストのデータ構造の一例を示す図である。 本発明の第１の実施の形態における経路情報のデータ構造の一例を示す図である。 本発明の第１の実施の形態におけるリソース管理テーブルのデータ構造の一例を示す図である。 本発明の第１の実施の形態において使用される相互生存確認メッセージのフォーマットの一例を示す図である。 本発明の第１の実施の形態における相互生存確認ステータスを示す図である。 通信不能となるリソース管理サーバに対して発側の隣接サーバの動作の流れを示すフローチャートである。 通信不能となるリソース管理サーバの動作の流れを示すフローチャートである。 ２つの隣接サーバ間で送受信されるメッセージのタイミングチャートである。 本発明の第２の実施の形態におけるリソース管理サーバの機能ブロック図である。 本発明の第２の実施の形態におけるリソース管理テーブルのデータ構造の他の例を示す図である。

符号の説明

１…送受信部、２，１０２…データベース部、３，１０３…リソース制御部、４…相互生存確認処理部、５…エラーログ作成部、６…エラーログ解析部、２１…アドレスリスト、２２…経路情報、２３，１２３…リソース管理テーブル、３１，１３１…メッセージ解析部、３２…着端末存否判定部、３３，１３３…リソース管理部、３４，１３４…メッセージ作成部、４１…相互生存確認メッセージ作成部、４２…相互生存確認メッセージ解析部、４３…隣接サーバ通信状態判定部、ＡＳ…アプリケーションサーバ、ＮＷ１〜ＮＷ３…管理範囲（通信ネットワーク）、Ｒ１１〜Ｒ１４，Ｒ２１〜Ｒ２４，Ｒ３１〜Ｒ３４…ルータ、ＲＭＳ１〜ＲＭＳ３…リソース管理サーバ、Ｔ１１，Ｔ１２，Ｔ３１，Ｔ３２…端末。

Claims (21)

1. 互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けられた複数のリソース管理装置の間で前記通信ネットワークのリソースに関するメッセージを送受信し、このメッセージに基づいてそれぞれの管理範囲内におけるリソースを管理するリソース管理方法であって、
   一のリソース管理装置において、このリソース管理装置の管理範囲に隣接する他の管理範囲を管理する他のリソース管理装置へ送信すべきメッセージのファイルを作成するファイル作成ステップと、
   前記他のリソース管理装置が通信可能となったときに、前記他のリソース管理装置へ前記ファイルを送信するファイル送信ステップと
   を備えることを特徴とするリソース管理方法。
2. 請求項１に記載のリソース管理方法において、
   前記他のリソース管理装置が通信不能になったことを検出する通信不能検出ステップを更に備えることを特徴とするリソース管理方法。
3. 請求項２に記載のリソース管理方法において、
   前記通信不能検出ステップは、
   前記他のリソース管理装置から送信される通信状態メッセージを受信する通信状態メッセージ受信ステップと、
   前記通信状態メッセージが受信されたときから所定時間内に次の通信状態メッセージが受信されない場合に、前記他のリソース管理装置が通信不能になったと判定する判定ステップと
   を備えることを特徴とするリソース管理方法。
4. 請求項２または３に記載のリソース管理方法において、
   前記ファイル作成ステップは、前記他のリソース管理装置の通信不能が検出されたときに、前記ファイルの作成を開始することを特徴とするリソース管理方法。
5. 請求項１〜４のいずれか１項に記載のリソース管理方法において、
   前記ファイルが作成されていることを表すファイル存在通知を前記他のリソース管理装置へ送信するファイル存在通知送信ステップを更に備えることを特徴とするリソース管理方法。
6. 請求項５に記載のリソース管理方法において、
   前記ファイル存在通知に基づいて前記他のリソース管理装置から送信される前記ファイルの送信依頼メッセージを受信する送信依頼メッセージ受信ステップを更に備え、
   前記ファイル送信ステップは、前記送信依頼メッセージが受信されたときに、前記ファイルを送信することを特徴とするリソース管理方法。
7. 請求項１〜６のいずれか１項に記載のリソース管理方法において、
   前記ファイル作成ステップは、前記他のリソース管理装置に対し通信に必要なリソースの確保を要求するリソース確保要求メッセージ、このリソース確保要求メッセージのキャンセルを表すキャンセルメッセージ、すでに通信のために確保されているリソースの変更を要求するリソース変更要求メッセージおよびすでに通信のために確保されているリソースの解放を要求するリソース解放要求メッセージのうち少なくとも１つに基づいて前記ファイルを作成することを特徴とするリソース管理方法。
8. 請求項１〜７のいずれか１項に記載のリソース管理方法において、
   前記他のリソース管理装置において、前記ファイルを受信するファイル受信ステップと、
   前記他のリソース管理装置が通信不能となる前の管理範囲内におけるリソースの管理内容を、受信された前記ファイルに基づいて更新するリソース管理ステップと
   を更に備えることを特徴とするリソース管理方法。
9. 請求項２〜４のいずれか１項に記載のリソース管理方法において、
   通信に必要なリソースの制御を要求する要求メッセージを受信する要求メッセージ受信ステップと、
   前記通信の着端末が前記一のリソース管理装置の管理範囲内にあるか否かを判定する着端末存否判定ステップと、
   前記着端末が前記一のリソース管理装置の管理範囲内にないと判定されたときに、前記他のリソース管理装置へ前記要求メッセージを送信する要求メッセージ送信ステップと、
   前記要求メッセージに対する応答として前記他のリソース管理装置から返信される応答メッセージを受信する応答メッセージ受信ステップと、
   受信された前記応答メッセージを前記要求メッセージの送信元へ送信する応答メッセージ送信ステップと、
   前記要求メッセージを送信した後で前記応答メッセージが受信される前に、前記他のリソース管理装置の通信不能が検出されたときに、前記要求メッセージの送信元へ前記要求メッセージに基づいたリソースの制御をキャンセルさせるキャンセルメッセージを送信するキャンセルメッセージ送信ステップと
   を更に備えることを特徴とするリソース管理方法。
10. 請求項２〜４のいずれか１項に記載のリソース管理方法において、
    通信に必要なリソースの制御を要求する要求メッセージを受信する要求メッセージ受信ステップと、
    前記他のリソース管理装置の通信不能が検出されると、検出後に前記他のリソース管理装置を経由するリソースの制御を要求する要求メッセージが受信されたときに、前記要求メッセージの送信元へ前記要求メッセージに基づいたリソースの制御を拒絶する拒絶応答メッセージを送信する拒絶応答メッセージ送信ステップと
    を更に備えることを特徴とするリソース管理方法。
11. 互いにリンクされた複数のルータと端末とから構成される通信ネットワークを分割した複数の管理範囲ごとに設けられ、前記通信ネットワークのリソースに関するメッセージを互いに送受信し、このメッセージに基づいてそれぞれの管理範囲内におけるリソースを管理するリソース管理装置であって、
    このリソース管理装置の管理範囲に隣接する他の管理範囲を管理する他のリソース管理装置へ送信すべきメッセージのファイルを作成するファイル作成手段と、
    前記他のリソース管理装置が通信可能となったときに、前記他のリソース管理装置へ前記ファイルを送信するファイル送信手段と
    を備えることを特徴とするリソース管理装置。
12. 請求項１１に記載のリソース管理装置において、
    前記他のリソース管理装置が通信不能になったことを検出する通信不能検出手段を更に備えることを特徴とするリソース管理装置。
13. 請求項１２に記載のリソース管理装置において、
    このリソース管理装置の通信状態を表す通信状態メッセージを前記他のリソース管理装置へ定期的に送信する通信状態メッセージ送信手段を更に備え、
    前記通信不能検出手段は、
    前記他のリソース管理装置から送信される通信状態メッセージを受信する通信状態メッセージ受信手段と、
    前記通信状態メッセージが受信されたときから所定時間内に次の通信状態メッセージが受信されない場合に、前記他のリソース管理装置が通信不能になったと判定する判定手段と
    を備えることを特徴とするリソース管理装置。
14. 請求項１２または１３に記載のリソース管理装置において、
    前記ファイル作成手段は、前記通信不能検出手段によって前記他のリソース管理装置の通信不能が検出されたときに、前記ファイルの作成を開始することを特徴とするリソース管理装置。
15. 請求項１１〜１４のいずれか１項に記載のリソース管理装置において、
    前記ファイルが作成されていることを表すファイル存在通知を前記他のリソース管理装置へ送信するファイル存在通知送信手段を更に備えることを特徴とするリソース管理装置。
16. 請求項１５に記載のリソース管理装置において、
    前記ファイル存在通知に基づいて前記他のリソース管理装置から送信される前記ファイルの送信依頼メッセージを受信する送信依頼メッセージ受信手段を更に備え、
    前記ファイル送信手段は、前記送信依頼メッセージが受信されたときに、前記ファイルを送信することを特徴とするリソース管理装置。
17. 請求項１１〜１６のいずれか１項に記載のリソース管理装置において、
    前記ファイル作成手段は、前記他のリソース管理装置に対し通信に必要なリソースの確保を要求するリソース確保要求メッセージ、このリソース確保要求メッセージのキャンセルを表すキャンセルメッセージ、すでに通信のために確保されているリソースの変更を要求するリソース変更要求メッセージおよびすでに通信のために確保されているリソースの解放を要求するリソース解放要求メッセージのうち少なくとも１つに基づいて前記ファイルを作成することを特徴とするリソース管理装置。
18. 請求項１１〜１７のいずれか１項に記載のリソース管理装置において、
    前記ファイルを受信するファイル受信手段と、
    このリソース管理装置が通信不能となる前の管理範囲内におけるリソースの管理内容を、受信された前記ファイルに基づいて更新するリソース管理手段と
    を更に備えることを特徴とするリソース管理装置。
19. 請求項１２〜１４のいずれか１項に記載のリソース管理装置において、
    通信に必要なリソースの制御を要求する要求メッセージを受信する要求メッセージ受信手段と、
    前記通信の着端末がこのリソース管理装置の管理範囲内にあるか否かを判定する着端末存否判定手段と、
    前記着端末がこのリソース管理装置の管理範囲内にないと判定されたときに、前記他のリソース管理装置へ前記要求メッセージを送信する要求メッセージ送信手段と、
    前記要求メッセージに対する応答として前記他のリソース管理装置から返信される応答メッセージを受信する応答メッセージ受信手段と、
    受信された前記応答メッセージを前記要求メッセージの送信元へ送信する応答メッセージ送信手段と、
    前記要求メッセージを送信した後で前記応答メッセージが受信される前に、前記通信不能検出手段によって前記他のリソース管理装置の通信不能が検出されたときに、前記要求メッセージの送信元へ前記要求メッセージに基づいたリソースの制御をキャンセルさせるキャンセルメッセージを送信するキャンセルメッセージ送信手段と
    を更に備えることを特徴とするリソース管理装置。
20. 請求項１２〜１４のいずれか１項に記載のリソース管理装置において、
    通信に必要なリソースの制御を要求する要求メッセージを受信する要求メッセージ受信手段と、
    前記通信不能検出手段によって前記他のリソース管理装置の通信不能が検出されると、検出後に前記他のリソース管理装置を経由するリソースの制御を要求する要求メッセージが受信されたときに、前記要求メッセージの送信元へ前記要求メッセージに基づいたリソースの制御を拒絶する拒絶応答メッセージを送信する拒絶応答メッセージ送信手段と
    を更に備えることを特徴とするリソース管理装置。
21. 互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けられた複数のリソース管理装置の間で前記通信ネットワークのリソースに関するメッセージを送受信し、このメッセージに基づいてそれぞれの管理範囲内におけるリソースを管理するリソース管理システムであって、
    一のリソース管理装置は、
    この一のリソース管理装置の管理範囲に隣接する他の管理範囲を管理する他のリソース管理装置へ送信すべきメッセージのファイルを作成するファイル作成手段と、
    前記他のリソース管理装置が通信可能となったときに、前記他のリソース管理装置へ前記ファイルを送信するファイル送信手段とを備え、
    前記他のリソース管理装置は、
    前記ファイルを受信するファイル受信手段と、
    この他のリソース管理装置が通信不能となる前の管理範囲内におけるリソースの管理内容を、受信された前記ファイルに基づいて更新するリソース管理手段とを備えることを特徴とするリソース管理システム。
    

Images