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

Abstract

【課題】リソース管理サーバ内の簡便な処理により、リソースを解放できるようにする。
【解決手段】自己の管理範囲内でリソースを確保するリソース管理部３０３と、確保されたリソースを特定する情報が登録されたリソース管理テーブル２０３と、確保されたリソースを特定する情報が付加されたリソース擬似解放要求メッセージを作成しリソース管理部３０３へ出力するリソース擬似解放処理部３０５とを備える。リソース管理部３０３は、リソース管理テーブル２０３を参照してリソース擬似解放要求メッセージに付加された情報によりリソースを特定し、特定されたリソースを解放する。
【選択図】 図２

Description

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

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

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

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

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

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

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

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

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

しかし、この方法では、リソース確保要求のメッセージを受信したリソース管理サーバがその管理範囲内でリソースを確保して通信が開始した後、この通信の終了前に、当該リソース管理サーバとメッセージ送信元の隣接サーバとの間の接続が切断された場合や、この隣接サーバがダウンした場合などには、当該リソース管理サーバは、隣接サーバからリソース解放要求のメッセージを受信することができない。このような場合には、通信のために確保されたリソースが、その通信の終了後も長期間にわたって解放されることはない。リソースが確保され続ける間は、このリソースを新規の通信に使用することもできず、無駄なリソース消費となるという問題があった。

また、当該リソース管理サーバがリソース解放要求のメッセージを受信できないと、リソース確保要求のメッセージ送信先の隣接サーバへリソース解放要求のメッセージを送信することもできない。このため、リソースを確保した隣接サーバにおいても同様に、無駄なリソース消費となるという問題があった。
さらに、リソース管理サーバの保守者からは、複数の管理範囲にまたがる一連のリソースを任意に解放できるようにしたいという要望があった。

例えば、リソース管理テーブルの「利用中のリソース容量」から、確保されているリソースの容量を減算する作業をマニュアルで行うことで、リソースを解放することが可能である。しかし、リソースが多数のリンクからなる場合には、その作業は困難なものとなる。また、一連のリソースを確保するすべてのリソース管理サーバにおいて同様の作業を行うことは極めて困難である。

本発明は、このような課題を解決するためになされたものであり、その目的は、リソース管理サーバ内の簡便な処理により、その管理範囲内およびそれに隣接する管理範囲内において確保されたリソースを解放できるようにする。

このような目的を達成するために、本発明にかかるリソース管理装置は、互いにリンクされた複数のルータと端末とから構成される通信ネットワークを分割した複数の管理範囲ごとに設けられ、それぞれの管理範囲内におけるリソースを管理するリソース管理装置であって、当該リソース管理装置の管理範囲内でリソースを確保するリソース確保手段と、確保された前記リソースを特定する情報を記録する記録手段と、前記情報が付加された第１のリソース解放要求メッセージを作成するメッセージ作成手段と、前記記録手段を参照して前記第１のリソース解放要求メッセージに付加された前記情報により前記リソースを特定し、特定された前記リソースを解放するリソース解放手段とを備えることを特徴とする。

このリソース管理装置は、要求される通信における着端末の識別子および確保したいリソース量を含むリソース確保要求メッセージを受信するメッセージ受信手段と、前記リソース確保要求メッセージに含まれる前記識別子に対応する前記着端末が前記当該リソース管理装置の管理範囲内にないときに、管理範囲が隣接する他のリソース管理装置へ前記リソース確保要求メッセージを送信するメッセージ送信手段とを更に備え、前記リソース確保手段は、前記リソース確保要求メッセージが受信されたときに前記リソースを確保するとともに、確保された前記リソースを特定する前記情報を前記記録手段に記録し、前記リソース確保要求メッセージが前記他のリソース管理装置へ送信されたときに、前記記録手段に記録されている前記情報に前記他のリソース管理装置の識別子を関連づけて記録するものであってもよい。

ここで、前記メッセージ送信手段は、前記第１のリソース解放要求メッセージに基づく前記リソースの解放時に、前記記録手段において前記リソースを特定する前記情報に関係づけられた前記識別子に対応する前記他のリソース管理装置へ、前記他のリソース管理装置の管理範囲内で確保されたリソースを特定する情報が付加された第２のリソース解放要求メッセージを送信するものであってもよい。
また、前記メッセージ受信手段は、前記当該リソース管理装置の管理範囲内で確保された前記リソースを特定する前記情報が付加された第３のリソース解放要求メッセージを受信し、前記リソース解放手段は、前記記録手段を参照して前記第３のリソース解放要求メッセージに付加された前記情報により前記リソースを特定し、特定された前記リソースを解放するものであってもよい。

上述したリソース管理装置は、前記リソース確保手段により前記リソースが確保されてからの時間をカウントするタイマを更に備え、前記メッセージ作成手段は、確保された前記リソースが解放されることなく所定時間を経過したときに、前記リソースに対する前記第１のリソース解放要求メッセージを作成するものであってもよい。
または、前記リソース確保要求メッセージの送信元との通信状態を検出する通信状態検出手段と、前記送信元との通信不能が検出されたときに、前記送信元からの前記リソース確保要求メッセージにより前記当該リソース管理装置の管理範囲内で確保されてから未だに解放されていないリソースを検索する未解放リソース検索手段とを更に備え、前記メッセージ作成手段は、検索されたリソースに対する前記第１のリソース解放要求メッセージを作成するものであってもよい。

または、前記当該リソース管理装置の保守者による操作に基づき確保済みのリソースに対する解放要求を前記メッセージ作成手段へ出力する管理端末を更に備え、前記メッセージ作成手段は、前記解放要求に基づき前記第１のリソース解放要求メッセージを作成するものであってもよい。
また、上述したリソース管理装置は、リソースの解放に失敗したときに解放失敗を示すログを作成し保持するログ管理手段を更に備えるものであってもよい。

また、本発明に係るリソース管理方法は、互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けられたリソース管理装置によって前記通信ネットワークのリソースを管理するリソース管理方法であって、一のリソース管理装置において、前記一のリソース管理装置の管理範囲内でリソースを確保するとともに、前記リソースを特定する情報を記録手段に記録するステップと、前記情報が付加された第１のリソース解放要求メッセージを作成するステップと、前記第１のリソース解放要求メッセージに基づき、前記記録手段を参照して前記情報により前記リソースを特定し、特定された前記リソースを解放するステップとを備えることを特徴とする。

このリソース管理方法は、要求される通信における着端末の識別子および確保したいリソース量を含むリソース確保要求メッセージを受信するステップと、前記リソース確保要求メッセージに含まれる前記識別子に対応する前記着端末が前記一のリソース管理装置の管理範囲内にないときに、管理範囲が隣接する他のリソース管理装置へ前記リソース確保要求メッセージを送信するとともに、前記記録手段に記録されている前記情報に前記他のリソース管理装置の識別子を関連づけて記録するステップとを更に備え、前記リソースを確保するステップは、前記リソース確保要求メッセージが受信されたときに前記リソースを確保するものであってもよい。

また、前記第１のリソース解放要求メッセージに基づく前記リソースの解放時に、前記記録手段から前記リソースを特定する前記情報に関係づけられた前記識別子を検索するステップと、検索された前記識別子に対応する前記他のリソース管理装置へ、前記他のリソース管理装置の管理範囲内で確保されたリソースを特定する情報が付加された第２のリソース解放要求メッセージを送信するステップとを更に備えるものであってもよい。
ここで、前記他のリソース管理装置において、前記第２のリソース解放要求メッセージを受信するステップと、前記第２のリソース解放要求メッセージに付加された前記情報により、前記他のリソース管理装置の管理範囲内で確保された前記リソースを特定し、特定された前記リソースを解放するステップとを備えるものであってもよい。

また、上述したリソース管理方法において、前記第１のリソース解放要求メッセージを作成するステップは、確保された前記リソースが解放されることなく所定時間を経過したときに、前記リソースに対する前記第１のリソース解放要求メッセージを作成するものであってもよい。
または、前記リソース確保要求メッセージの送信元との通信状態を検出するステップと、前記送信元との通信不能が検出されたときに、前記送信元からの前記リソース確保要求メッセージにより前記一のリソース管理装置の管理範囲内で確保されてから未だに解放されていないリソースを検索するステップとを更に備え、前記第１のリソース解放要求メッセージを作成するステップは、検索されたリソースに対する前記第１のリソース解放要求メッセージを作成するものであってもよい。

または、前記第１のリソース解放要求メッセージを作成するステップは、前記一のリソース管理装置の保守者による確保済みのリソースに対する解放要求に基づき、前記第１のリソース解放要求メッセージを作成するものであってもよい。
また、上述したリソース管理方法は、リソースの解放に失敗したときに解放失敗を示すログを作成し保持するステップを更に備えるものであってもよい。

また、本発明に係るリソース管理システムは、互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けられたリソース管理装置によって前記通信ネットワークのリソースを管理するリソース管理システムであって、前記リソース管理装置は、上述したリソース管理装置であることを特徴とする。

本発明では、当該リソース管理装置の内部でリソース解放要求メッセージを作成し、このメッセージに基づいて自己の管理範囲内において確保されたリソースを解放する。このため、リソース確保要求メッセージの送信元がダウンするなどしてリソース解放要求メッセージが送られて来なくても、リソースを解放することができる。
さらに、当該リソース管理装置からリソース確保要求メッセージの送信先へリソース解放要求メッセージを送信することによって、この送信先の管理範囲内において確保されたリソースを解放することができる。
したがって、リソース解放要求メッセージが送られて来なくても、複数の管理範囲にまたがる一連のリソースを解放し、新規の通信に使用することが可能となり、リソースを有効に利用することができる。

また、自装置内で作成されたリソース解放要求メッセージを用いて、あたかもリソース解放要求メッセージを受信したときと同様の処理を擬似的に行うことにより、通常の解放処理と同じ性能で、解放処理を行うことができる。したがって、リソース容量の減算作業をマニュアルで行う必要がないので、解放処理を正確かつ簡便に行うことができる。
また、当該リソース管理装置の保守者からの指示に基づいてリソース解放要求メッセージを作成することによって、保守者が任意にリソースを解放できるようになる。

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

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

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

アプリケーションサーバＡＳは、端末（例えば、端末Ｔ１１）からの通信要求を受けて、この端末が属する管理範囲（例えば、管理範囲ＮＷ１）のリソースを管理するリソース管理サーバ（例えば、リソース管理サーバＲＭＳ１）に要求メッセージを送信するサーバである。要求メッセージには、通信に必要なリソースの確保を要求するリソース確保要求メッセージ、確保されたリソースの変更を要求するリソース変更要求メッセージ、および確保されたリソースの解放を要求するリソース解放要求メッセージ等がある。

なお、図１には３つのリソース管理サーバＲＭＳ１〜ＲＭＳ３と３つの管理範囲ＮＷ１〜ＮＷ３とが描かれているが、通信ネットワークが４つ以上の管理範囲に分割された場合にも、それぞれの管理範囲にリソース管理サーバを設ければよい。

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

図２は、リソース管理サーバＲＭＳｉ（ｉ＝１，２，３）の機能ブロック図である。
送受信部ｉ１は、通信インターフェースを備え、アプリケーションサーバＡＳや、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉに隣接する他の管理範囲ＮＷｉ−１，ＮＷｉ＋１を管理する他のリソース管理サーバ（以下、単に「隣接サーバ」という）ＲＭＳｉ−１，ＲＭＳｉ＋１との間で、各種メッセージを送信および受信する。
データベース部（記録手段）ｉ２には、リソース管理サーバ本体ｉ３によるリソース管理に必要な各種情報が記録される。

リソース管理サーバ本体ｉ３は、受信された要求メッセージに応じて当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内におけるリソースの確保および解放を行うとともに、必要に応じて着側の隣接サーバＲＭＳｉ＋１へ送信すべきメッセージを作成する。
なお、リソース管理サーバＲＭＳｉには、保守者によるリソース管理サーバＲＭＳｉの保守管理に用いられる保守端末ｉ４が接続されている。

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

経路情報２０２は、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内にあるリソースから構成される通信経路のリストである。例えば、経路情報２０１は、管理範囲ＮＷｉ内における経路の入口となるエッジノード（入口ノード）のＩＰアドレスと、経路の出口となるエッジノード（出口ノード）のＩＰアドレスと、これらのノード間を接続するリソースの容量（総容量および利用中の容量（または利用可能な残りの容量））と、これらのリソースの詳細情報とからなる。

リソースの詳細情報には、入口ノードと出口ノードとの間や発端末と着端末との間の経路を構成する個々のリソース、すなわちアクセスライン（端末とルータまたはスイッチングハブとの間のパス）やアクセス集線ライン（スイッチングハブとルータとの間のパス）およびリンク（ルータとルータとの間のパス）、発端末のＩＰ、着端末のＩＰ、当該経路を使用しているユーザＩＤが列挙されている。ただし、発端末ＩＰや着端末ＩＰは必ずしも表記されていなくてもよい。当該リソース管理装置の管理範囲ＮＷｉ内で経路の入口ノードのＩＰアドレスと出口ノードのＩＰアドレスが特定できればよい。
また、各経路には、「リソースＩＤ」が付与されている。このリソースＩＤは、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内においてユニークな識別子である。したがって、リソースＩＤを参照することによって、経路を構成するノード間のアクセスラインやリンクを列挙しなくても、管理範囲ＮＷｉ内における経路（リソースの集合）を特定することができる。

リソース管理テーブル２０３は、リソース管理サーバ本体ｉ３によって確保されたリソースに関する情報（リソース情報）を管理するテーブルである。リソース管理テーブル２０２は、例えば図３に示すように、「リソースＩＤ」、「着端末ＩＰ」、「リソース容量」、「送信元サーバＩＤ」、「送信元リソースＩＤ」、「送信先サーバＩＤ」、「送信先リソースＩＤ」、「タイマ」および「リソース確保状態」という項目を含む。

ここで、「リソースＩＤ」は、リソース管理サーバ本体ｉ３によって確保されたリソース（経路）を識別するものであり、上述した経路情報２０２において使用されるリソースＩＤと同じものである。
「着端末ＩＰ」は、通信の着端末のＩＰアドレスである。
「リソース容量」は、リソースを構成するリンク等の総容量および利用中の容量（または利用可能な残りの容量）である。

「送信元サーバＩＤ」および「送信先サーバＩＤ」は、発端末と着端末との間の通信経路が管理範囲に含まれるリソース管理サーバのうち、管理範囲が当該リソース管理サーバＲＭＳｉに隣接する隣接サーバ等の識別子である。より詳しくは、「送信元サーバＩＤ」は、リソース確保要求メッセージの送信元、すなわち当該リソース管理サーバＲＭＳｉへリソース確保要求メッセージを送信した隣接サーバＲＭＳｉ−１（またはアプリケーションサーバＡＳ）の識別子である。また、「送信先サーバＩＤ」は、リソース確保要求メッセージの送信先、すなわち当該リソース管理サーバＲＭＳｉからリソース確保要求メッセージを送信した隣接サーバＲＭＳｉ＋１の識別子である。

「送信元リソースＩＤ」は、リソース確保要求メッセージの送信元、すなわち隣接サーバＲＭＳｉ−１によって確保されたリソースに付与されたリソースＩＤである。「送信先リソースＩＤ」は、リソース確保要求メッセージの送信先、すなわち隣接サーバＲＭＳｉ＋１によって確保されたリソースに付与されたリソースＩＤである。

「タイマ」には、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉにおいてリソースが確保されたときに始動し、確保されたリソースが解放されるまで時間をカウントするタイマの値が表示される。
「リソース確保状態」は、タイマの値が基準時間を超えたか否かを示す。例えば、初期値を「０」とし、タイマの値が基準時間を超えたときに「１」を立てる。リソース確保状態が「１」になったときには、リソースが確保されてから解放されることなく基準時間が経過したことが分かる。なお、基準時間は任意に設定可能であり、例えば２４時間とすることができる。

１−２−２．リソース管理サーバ本体ｉ３
図２に示すように、リソース管理サーバ本体ｉ３は、メッセージ解析部３０１と、着端末存否判定部３０２と、リソース管理部３０３と、メッセージ作成部３０４と、リソース擬似解放処理部（リソース擬似解放要求メッセージ作成部）３０５と、エラーログ管理部３０６とから構成される。
ここで、メッセージ解析部３０１は、送受信部ｉ１で受信された各種メッセージを分析する。例えば、リソース確保要求メッセージに含まれる着端末のＩＰアドレスは、このメッセージ解析部３０１において識別される。
着端末存否判定部３０２は、データベース部ｉ２のアドレスリスト２０１を参照して、受信されたリソース確保要求メッセージに含まれるＩＰアドレスに対応する着端末が当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内にあるか否かを判定する。

リソース管理部３０３は、受信された要求メッセージに応じて、データベース部ｉ２の経路情報２０２を参照してリソース管理テーブル２０３の内容を更新し、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内において通信に必要なリソースの確保、および確保されたリソースの解放を行う。したがって、リソース管理部３０３は、リソース確保手段およびリソース解放手段として作用する。リソース管理部３０３はまた、定期的にリソース管理テーブル２０３の「リソース確保状態」をチェックし、確保されてから解放されることなく基準時間が経過したリソースを検出する。このリソースを「未解放リソース」と呼ぶ。

メッセージ作成部３０４は、着端末存否判定部３０２による判定の結果、着端末が当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内にないと判定されたときに、隣接サーバＲＭＳｉ＋１へ送信すべきリソース確保要求メッセージを作成する。また、リソース管理部３０３によって解放されたリソースに繋がるリソースが隣接サーバＲＭＳｉ＋１によって確保されている場合に、この隣接サーバＲＭＳｉ＋１へ送信すべきリソース解放要求メッセージを作成する。

リソース擬似解放処理部３０５は、リソース管理部３０３によって未解放リソースが検出されたときに、その旨を保守端末ｉ４に通知し、これに対する保守端末ｉ４からの指示に基づいてリソース擬似解放要求メッセージ（第１のリソース解放要求メッセージ）をメッセージ解析部３０１へ出力し、隣接サーバＲＭＳｉ−１からのリソース解放要求メッセージが受信されたときと同様の処理をメッセージ解析部３０１、リソース管理部３０３およびメッセージ作成部３０４等に擬似的に行わせる。具体的には、リソース管理部３０３によって検出された未解放リソースを強制的に解放させる。解放させたリソースに繋がるリソースが隣接サーバＲＭＳｉ＋１によって確保されている場合には、そのリソースを解放させるリソース擬似解放要求メッセージ（第２のリソース解放要求メッセージ）を作成させ、隣接サーバＲＭＳｉ＋１へ送信させる。

エラーログ管理部３０６は、リソース管理部３０３によるリソースの解放に失敗したときにエラーログを作成し、保持する。エラーログには、yyyymmddhhss（日付と時刻）、「エラー内容：解放失敗」、「リソースＩＤ」、「リソース管理サーバＩＤ」が記載される。エラーログ管理部３０６で保持されているエラーログは、保守端末ｉ４から閲覧可能である。

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

（１）「リソースＩＤ」：リソース管理サーバにおいて独自に付与されたリソースＩＤである。
（２）「リソース管理サーバＩＤ」：上記（１）のリソースＩＤを付与したリソース管理サーバ固有の識別子である。
（３）「解放後のリソース量」：解放後に指定のリソース量である。この値を「０」に設定すれば、リソースを完全に解放できる。また、「０」以外の値に設定すれば、リソースを部分的に解放し、リソース量を変更できる。

１−３．リソース管理サーバの動作
次に、複数の管理範囲を経由する通信を行う際のリソースの確保から解放または擬似解放までの一連の処理について説明する。
図５は、リソース管理サーバＲＭＳｉによって行われるリソースの確保から解放または擬似解放までの一連の処理の流れの概略を示すフローチャートである。
複数の管理範囲を経由する通信を開始する際には、その通信に必要なリソースの確保を要求するリソース確保要求メッセージが隣接サーバＲＭＳｉ−１から送られて来る。リソース管理サーバＲＭＳｉは、このリソース確保要求メッセージを受信すると（ステップＳ１，ＹＥＳ）、自己の管理範囲ＮＷｉ内において、要求されたリソースを確保する（ステップＳ２）。

その後、通信を終了する際に、その通信のために確保されていたリソースの解放を要求するリソース解放要求メッセージが隣接サーバＲＭＳｉ−１から送られて来る。リソース管理サーバＲＭＳｉは、このリソース解放要求メッセージを受信すると（ステップＳ３，ＹＥＳ）、自己の管理範囲ＮＷｉ内において、確保されていたリソースを解放し（ステップＳ４）、一連の処理を終了する。
しかし、隣接サーバＲＭＳｉ−１がダウンするなどしてリソース解放要求メッセージが送られて来ない場合には（ステップＳ３，ＮＯ）、リソース管理サーバＲＭＳｉは、ステップＳ２でリソースを確保してから基準時間経過後に（ステップＳ５，ＹＥＳ）、リソース解放要求メッセージが受信されたときと同様に、確保されていたリソースの解放処理を擬似的に行い（ステップＳ６）、一連の処理を終了する。

以下、各処理の詳細を説明する。
１−３−１．リソース確保処理（ステップＳ２）
図６は、リソース管理サーバＲＭＳｉによるリソース確保処理の流れを示すフローチャートである。

送受信部ｉ１において隣接サーバＲＭＳｉ−１からのリソース確保要求メッセージが受信されると（図５のステップＳ１，ＹＥＳ）、メッセージ解析部３０１は、リソース確保要求メッセージに含まれる「着端末ＩＰ」、「確保したいリソース量」、「サーバＩＤ」および「リソースＩＤ」を抽出する。ここで、「着端末ＩＰ」は、通信を行う着端末のＩＰアドレス、「確保したいリソース量」は、通信に必要なリソース量、「サーバＩＤ」は、リソース確保要求メッセージの送信元である隣接サーバＲＭＳｉ−１のサーバＩＤ、「リソースＩＤ」は、隣接サーバＲＭＳｉ−１の管理範囲ＮＷｉ−１において確保されたリソースを特定するリソースＩＤである。
そして、着端末存否判定部３０２は、アドレスリスト２０１を参照し、着端末が当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内にあるか否かを判定する（ステップＳ２１）。

着端末が管理範囲ＮＷｉ内にあった場合には（ステップＳ２１，ＹＥＳ）、リソース管理部３０３は、経路情報２０２を参照し、管理範囲ＮＷｉ内におけるリソースを検索する。そして、検索されたリソースの利用中容量に、メッセージに含まれていた「確保したいリソース量」を加算する。さらに、このリソースを特定するリソースＩＤをリソース管理テーブル２０３に登録する。この際、リソース管理テーブル２０３の「リソース容量」の欄に、加算処理後のリソース容量を記載する。また、「着端末ＩＰ」、「送信元サーバＩＤ」および「送信元リソースＩＤ」の欄に、リソース確保要求メッセージに含まれていた着端末ＩＰ、サーバＩＤおよびリソースＩＤをそれぞれ記載する（ステップＳ２２）。
このようにして管理範囲ＮＷｉ内におけるリソース確保が終了すると、リソースが確保されてから解放されるまで時間をカウントするタイマを始動させる（ステップＳ２３）。

メッセージ作成部３０４は、図５のステップＳ１で受信されたリソース確保要求メッセージの送信元である隣接サーバＲＭＳｉ−１を、リソース確保要求メッセージから抽出された「サーバＩＤ」によって特定し、この隣接サーバＲＭＳｉ−１へ送信する応答メッセージを作成する。応答メッセージには、リソース確保要求メッセージから抽出された「リソースＩＤ」および当該リソース管理サーバＲＭＳｉにおいて確保されたリソースを特定するリソースＩＤを、それぞれ「送信元リソースＩＤ」および「リソースＩＤ」として付加する。この応答メッセージを送受信部ｉ１より隣接サーバＲＭＳｉ−１へ送信することによって（ステップＳ２４）、隣接サーバＲＭＳｉ−１は、応答メッセージに付加された情報から、どのリソースに繋がるリソースがリソース確保要求メッセージの送信先で確保されたのか、また送信先で確保されたリソースの識別子を知ることができる。ここで、メインルーチンに戻る。

これに対し、着端末存否判定部３０２による判定の結果、着端末が管理範囲ＮＷｉ内になかった場合には（ステップＳ２１，ＮＯ）、ステップＳ２２と同様にして管理範囲ＮＷｉ内においてリソースを確保し（ステップＳ２５）、タイマを始動させる（ステップＳ２６）。さらに、メッセージ作成部３０４がリソース確保要求メッセージを作成して、送受信部ｉ１より隣接サーバＲＭＳｉ＋１へ送信する（ステップＳ２７）。このリソース確保要求メッセージには、受信されたリソース確保要求メッセージから抽出された「着端末ＩＰ」および「確保したいリソース量」をそのまま付加し、当該リソース管理サーバＲＭＳｉの識別子および当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉにおいて確保されたリソースを特定するリソースＩＤを、それぞれ「サーバＩＤ」および「リソースＩＤ」として付加する。リソース確保要求メッセージを送信する際には、リソース管理テーブル２０３の「リソースＩＤ」に関連づけて、「送信先サーバＩＤ」に隣接サーバＲＭＳｉ＋１の識別子を記載する。

その後、リソース確保要求メッセージの送信先となった隣接サーバＲＭＳｉ＋１からの応答メッセージを送受信部ｉ１において受信すると（ステップＳ２８，ＹＥＳ）、メッセージ解析部３０１は、応答メッセージに含まれる「リソースＩＤ」および「送信元リソースＩＤ」を抽出する。ここで、「リソースＩＤ」は、隣接サーバＲＭＳｉ＋１の管理範囲ＮＷｉ＋１において確保されたリソースを特定するリソースＩＤであり、当該リソース管理サーバＲＭＳｉから見ると「送信先リソースＩＤ」に当たるものである。したがって、抽出されたリソースＩＤをリソース管理テーブル２０３の「送信先リソースＩＤ」に記載する。

また、応答メッセージ中の「送信元リソースＩＤ」は、当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉ内において確保されたリソースを特定するリソースＩＤである。したがって、リソース管理部３０３は、リソース管理テーブル２０３を参照して、このリソースＩＤに関係づけられた「送信元サーバＩＤ」および「送信元リソースＩＤ」を検索する。このようにして取得した「送信元サーバＩＤ」から、図５のステップＳ１で受信されたリソース確保要求メッセージの送信元である隣接サーバＲＭＳｉ−１を特定し（ステップＳ２９）、この隣接サーバＲＭＳｉ−１へ送信する応答メッセージをメッセージ作成部３０４が作成する。応答メッセージには、取得した「送信元リソースＩＤ」および当該リソース管理サーバＲＭＳｉの管理範囲ＮＷｉにおいて確保されたリソースを特定する「リソースＩＤ」を付加する。この応答メッセージを送受信部ｉ１より隣接サーバＲＭＳｉ−１へ送信する（ステップＳ３０）。ここで、メインルーチンに戻る。

例えば、通信の発端末および着端末がそれぞれ管理範囲ＮＷ１内および管理範囲ＮＷ３内にある場合には、リソース管理サーバＲＭＳ１が図５のステップＳ１および図６のステップＳ２１，Ｓ２５〜Ｓ３０の処理を行い、リソース管理サーバＲＭＳ２が図５のステップＳ１および図６のＳ２１，Ｓ２５〜Ｓ３０の処理を行い、リソース管理サーバＲＭＳ３が図５のステップＳ１および図６のステップＳ２１〜Ｓ２４の処理を行うことによって、３つの管理範囲ＮＷ１〜ＮＷ３にまたがる一連のリソースを確保することができる。
なお、リソース管理サーバＲＭＳ１は、図５のステップＳ１において、アプリケーションサーバＡＳからのリソース確保要求メッセージを受信する。このリソース確保要求メッセージには「リソースＩＤ」が含まれていないので、リソース管理テーブル２０３の「送信元リソースＩＤ」は空欄となる。

１−３−２．リソース解放処理（ステップＳ４）
図７は、リソース管理サーバＲＭＳｉによるリソース解放処理の流れを示すフローチャートである。

送受信部ｉ１において隣接サーバＲＭＳｉ−１からのリソース解放要求メッセージが受信されると（図５のステップＳ３，ＹＥＳ）、メッセージ解析部３０１は、リソース解放要求メッセージに含まれる「リソースＩＤ」を抽出する。このリソースＩＤは、リソース確保要求メッセージの送信元である隣接サーバＲＭＳｉ−１の管理範囲ＮＷｉ−１において確保されたリソースを特定するリソースＩＤであり、当該リソース管理サーバＲＭＳｉから見ると「送信元リソースＩＤ」に当たるものである。したがって、リソース管理部３０３は、この送信元リソースＩＤをキーにしてリソース管理テーブル２０３を参照し、送信元リソースＩＤに関係づけられた自己の管理範囲ＮＷｉ内における「リソースＩＤ」を検索する。このリソースＩＤに関係づけられた情報（例えば「送信先リソースＩＤ」）から、リソースＩＤによって特定されるリソースに繋がるリソースが隣接サーバＲＭＳｉ＋１によって確保されているか否かを判定する（ステップＳ４１）。

隣接サーバＲＭＳｉ＋１によってリソースが確保されていない場合には（ステップＳ４１，ＮＯ）、自己の管理範囲ＮＷｉ内におけるリソースの利用中容量から、図６のステップＳ２２またはＳ２５で確保したリソース量を減算する。さらに、リソースＩＤおよびこれに関連づけられた情報をリソース管理テーブル２０３から削除する。これにより、自己の管理範囲ＮＷｉ内において、リソースが解放される（ステップＳ４３）。

これに対し、隣接サーバＲＭＳｉ＋１によってリソースが確保されている場合には（ステップＳ４１，ＹＥＳ）、メッセージ作成部３０４がリソース解放要求メッセージを作成し、送受信部ｉ１より隣接サーバＲＭＳｉ＋１へ送信する（ステップＳ４２）。このリソース解放要求メッセージには、当該リソース管理サーバＲＭＳｉの「サーバＩＤ」および検索された「リソースＩＤ」を付加する。
そして更に、上述したように、リソース管理部３０３が、自己の管理範囲ＮＷｉ内において、リソースを解放する（ステップＳ４３）。

ステップＳ４３において、リソースの解放に成功した場合には（ステップＳ４４，ＹＥＳ）、タイマをリセットし（ステップＳ４５）、メインルーチンに戻る。
これに対し、万が一、リソースの解放に失敗した場合には（ステップＳ４４，ＮＯ）、エラーログ管理部３０６が、解放に失敗したことを示すエラーログを作成し（ステップＳ４６）、メインルーチンに戻る。

例えば、通信の発端末および着端末がそれぞれ管理範囲ＮＷ１内および管理範囲ＮＷ３内にある場合には、リソース管理サーバＲＭＳ１が図５のステップＳ１および図７のステップＳ４１〜Ｓ４６の処理を行い、リソース管理サーバＲＭＳ２が図５のステップＳ１および図７のステップＳ４１〜Ｓ４６の処理を行い、リソース管理サーバＲＭＳ３が図５のステップＳ１および図７のステップＳ４１，Ｓ４３〜Ｓ４６の処理を行うことによって、３つの管理範囲ＮＷ１〜ＮＷ３にまたがって確保された一連のリソースを解放することができる。

なお、アプリケーションサーバＡＳは、リソースＩＤに相当するものを保持しないので、リソースＩＤに代わる情報をリソース解放要求メッセージに付加する。例えば、初段のリソース管理サーバＲＭＳ１からの応答メッセージに付加されたリソースＩＤをリソース解放要求メッセージに付加することができる。このリソースＩＤは、リソース管理サーバＲＭＳ１で確保されたリソースを特定するＩＤである。なお、リソース管理サーバＲＭＳ１からの応答メッセージに送信先リソースＩＤ（後段のリソース管理サーバＲＭＳ２で確保されたリソースを特定するＩＤ）が付加されている場合には、この送信先リソースＩＤをリソース解放要求メッセージに付加するようにしてもよい。

これに対し、リソース管理サーバＲＭＳｉは一般に、リソース管理テーブル２０３の「送信元リソースＩＤ」、「リソースＩＤ」、「送信先リソースＩＤ」の順に、リソース解放要求メッセージに付加された情報を検索していくものとする。これにより、アプリケーションサーバＡＳからリソース解放要求メッセージを受信したリソース管理サーバＲＭＳ１は、リソース管理テーブル２０３の「リソースＩＤ」または「送信先リソースＩＤ」の中から、リソース解放要求メッセージに付加された情報を見つけ、解放要求の対象リソースを特定することが可能となる。

なお、リソース解放要求メッセージに「送信元リソースＩＤ」、「リソースＩＤ」、「送信先リソースＩＤ」のいずれを付加しているかを表すフラグを立てるようにしてもよい。あるいは、それぞれのリソース管理サーバＲＭＳｉが管理範囲ＮＷｉにおいて「送信元リソースＩＤ」、「リソースＩＤ」、「送信先リソースＩＤ」のいずれを用いるかのルールを設けるようにしてもよい。これにより、リソース解放要求メッセージを受信したリソース管理サーバによる検索処理を高速化することができる。

応答メッセージを返信しないシステムの場合には、リソース確保処理において、アプリケーションサーバＡＳが独自の識別子を付加したリソース確保要求メッセージをリソース管理サーバＲＭＳ１へ送信する。このリソース確保要求メッセージを受信したリソース管理サーバＲＭＳ１は、リソース確保処理を行ったときに、リソース確保要求メッセージに付加された上記識別子をリソース管理テーブル２０３に記載する。リソース解放処理の際に、アプリケーションサーバＡＳがリソース解放要求メッセージに同じ識別子を付加することにより、リソース管理サーバＲＭＳ１は解放要求の対象リソースを特定することができる。

１−３−３．リソース擬似解放処理（ステップＳ６）
図８は、リソース管理サーバＲＭＳｉによるリソース擬似解放処理の流れを示すフローチャートである。
図６のステップＳ２２，Ｓ２５でリソース管理サーバＲＭＳｉの管理範囲ＮＷｉにおいてリソースが確保されてから基準時間が経過してもリソース解放要求メッセージが送られて来ない場合には（ステップＳ５，ＹＥＳ）、リソース管理テーブル２０３の「リソース確保状態」に「１」が立つ。これを検出したリソース管理部３０３は、確保されてから基準時間が経過した未解放リソースＲ１の情報（「送信元サーバＩＤ」および「送信元リソースＩＤ」を含む）をリソース擬似解放処理部３０５へ出力する。

これを受けて、リソース擬似解放処理部３０５は、保守端末ｉ４に対し、確保されてから基準時間が経過した未解放リソースＲ１が検出されたことと、この未解放リソースＲ１の情報とを通知する（ステップＳ６１）。これらは、保守端末ｉ４のディスプレイに表示される。

この表示を見た保守者が保守端末ｉ４を操作し、リソース擬似解放処理部３０５に対し未解放リソースＲ１の解放を指示すると、リソース擬似解放処理部３０５は、未解放リソースＲ１の解放を要求するリソース擬似解放要求メッセージ（第１のリソース解放要求メッセージ）を作成し、メッセージ解析部３０１へ出力する（ステップＳ６２）。リソース擬似解放要求メッセージは、このメッセージがリソース擬似解放要求メッセージであることを表すメッセージ番号を除き、基本的にはリソース解放要求メッセージと同じものであり、解放したい未解放リソースＲ１に関連する「送信元サーバＩＤ」および「送信元リソースＩＤ」がそれぞれ「サーバＩＤ」および「リソースＩＤ」として付加されている。したがって、リソース擬似解放要求メッセージが入力されたメッセージ解析部３０１は、リソース解放要求メッセージが受信されたときと同じように動作し、その後のリソース管理部３０３、メッセージ作成部３０４およびエラーログ管理部３０６の動作もリソース解放要求メッセージが受信されたときと同様である。以下、具体的に説明する。

リソース擬似解放要求メッセージが入力されたメッセージ解析部３０１は、リソース擬似解放要求メッセージに含まれる「リソースＩＤ」を抽出する。このリソースＩＤは、リソース確保要求メッセージの送信元である隣接サーバＲＭＳｉ−１の管理範囲ＮＷｉ−１において確保されたリソースを特定するリソースＩＤであり、当該リソース管理サーバＲＭＳｉから見ると「送信元リソースＩＤ」に当たるものである。したがって、リソース管理部３０３は、この送信元リソースＩＤをキーにしてリソース管理テーブル２０３を参照し、送信元リソースＩＤに関係づけられた自己の管理範囲ＮＷｉ内における「リソースＩＤ」を検索する。このリソースＩＤに関係づけられた情報（例えば「送信先リソースＩＤ」）から、リソースＩＤによって特定される未解放リソースＲ１に繋がるリソースが隣接サーバＲＭＳｉ＋１によって確保されているか否かを判定する（ステップＳ６３）。

隣接サーバＲＭＳｉ＋１によってリソースが確保されていない場合には（ステップＳ６３，ＮＯ）、自己の管理範囲ＮＷｉ内における未解放リソースＲ１の利用中容量から、図６のステップＳ２２またはＳ２５で確保したリソース量を減算する。さらに、リソースＩＤおよびこれに関連づけられた情報をリソース管理テーブル２０３から削除する。これにより、管理範囲ＮＷｉ内において、未解放リソースＲ１が解放される（ステップＳ６５）。

これに対し、隣接サーバＲＭＳｉ＋１によってリソースが確保されている場合には（ステップＳ６３，ＹＥＳ）、メッセージ作成部３０４がリソース擬似解放要求メッセージ（第２のリソース解放要求メッセージ）を作成し、送受信部ｉ１より隣接サーバＲＭＳｉ＋１へ送信する（ステップＳ６４）。このリソース擬似解放要求メッセージには、当該リソース管理サーバＲＭＳｉの「サーバＩＤ」および検索された「リソースＩＤ」を付加する。
そして更に、上述したように、リソース管理部３０３が、自己の管理範囲ＮＷｉ内において、未解放リソースＲ１を解放する（ステップＳ６５）。

ステップＳ６５において、リソースの解放に成功した場合には（ステップＳ６６，ＹＥＳ）、タイマをリセットし（ステップＳ６７）、メインルーチンに戻る。
これに対し、万が一、リソースの解放に失敗した場合には（ステップＳ６６，ＮＯ）、エラーログ管理部３０６が、解放に失敗したことを示すエラーログを作成し（ステップＳ６８）、メインルーチンに戻る。

例えば、通信の発端末および着端末がそれぞれ管理範囲ＮＷ１内および管理範囲ＮＷ３内にあり、管理範囲ＮＷ１を管理するリソース管理サーバＲＭＳ１がダウンした場合には、ダウンしたリソース管理サーバＲＭＳ１からリソース解放要求メッセージが送られて来なくても、リソース管理サーバＲＭＳ２がステップＳ６１〜Ｓ６８の処理を行うことによって、自己の管理範囲ＮＷ２において確保されたリソースを解放することができる。
また、リソース管理サーバＲＭＳ２からリソース管理サーバＲＭＳ３へリソース擬似解放要求メッセージを送信することによって、リソース管理サーバＲＭＳ３がリソース解放要求メッセージを受信したときの同様に図７のステップＳ４１，Ｓ４３〜Ｓ４６と同様の処理を行い、自己の管理範囲ＮＷ３において確保されたリソースを解放することができる。

このように、リソース管理サーバＲＭＳ１がダウンし、リソース解放要求メッセージが送られて来なくても、リソース管理サーバＲＭＳ２，ＲＭＳ３の管理範囲ＮＷ２，ＮＷ３において確保されたリソースが解放されるので、解放されたリソースを新規の通信に使用することが可能となり、リソースを有効に利用することができる。

なお、この例において、リソース管理サーバＲＭＳ２，ＲＭＳ３は同一の構成を有しているので、前段のリソース管理サーバＲＭＳ２よりも先に後段のリソース管理サーバＲＭＳ３から擬似解放処理が開始される場合もある。しかし、リソース管理サーバＲＭＳ２，ＲＭＳ３において、擬似解放処理を開始する基準時間を同じ値に設定した場合には、リソースが確保された順に擬似解放処理を開始することになる。したがって、前段のリソース管理サーバＲＭＳ２から擬似解放処理が開始し、後段のリソース管理サーバＲＭＳ３へ伝えられるため、この逆の順で擬似解放処理が行われる可能性は低い。たまたまリソース擬似解放要求メッセージが送られてくる前にリソース管理サーバＲＭＳ３において擬似解放処理が行われたとしても、解放済みのリソースに対するリソース擬似解放要求メッセージを無効とすることによって、リソース管理サーバＲＭＳ３において処理が錯綜することを防止することができる。

また、本実施の形態では、本来リソース確保要求メッセージの送信元から送信されるリソース解放要求メッセージと同様のリソース擬似解放要求メッセージを自サーバ内で作成し、このリソース擬似解放要求メッセージを用いて、あたかもリソース解放要求メッセージを受信したときと同様の処理を行うことにより、通常の解放処理と同じ性能で、擬似的な解放処理を行うことができる。本実施の形態では、リソース容量の減算をマニュアルで行う作業を伴わないので、解放処理を正確かつ簡便に行うことができる。

また、本実施の形態では、解放対象の未解放リソースＲ１を特定する情報として、リソース擬似解放要求メッセージに、「リソースＩＤ」を付加する例を示したが、これに限定されるものではない。例えば、リソースＩＤの代わりに、「送信先リソースＩＤ」、「着端末ＩＰ」、発端末から着端末までの一連のリソースにリソースＩＤが付与されている場合には、このリソースＩＤを付加してもよい。

ここで、「リソースＩＤ」、「着端末ＩＰ」、一連のリソースに付与されたリソースＩＤの何れかをリソース擬似解放要求メッセージに付与する場合には、メッセージ送信先からリソース確保要求メッセージに対する応答メッセージが来なくても、メッセージ送信先に対しリソースの擬似解放処理を要求することができる。より詳しく言えば、何らかの理由によって応答メッセージが欠落した場合に、先に送信したメッセージによるリソース確保要求をキャンセルし、メッセージ送信先ですでにリソースが確保されている場合には、確保されたリソースを解放することができる。

さらに、上述したように、リソース擬似解放要求メッセージの「解放後のリソース量」に「０」以外の値に設定することによって、リソース量の変更が可能である。
また、本実施の形態では、リソース擬似解放処理部３０５が保守端末ｉ４からの指示に基づいてリソース擬似解放処理を開始する例を示したが、リソース管理部３０３から未解放リソースＲ１の情報を受けた時点で、保守端末ｉ４からの指示に基づくことなくリソース擬似解放処理を開始するようにしてもよい。

２．第２の実施の形態
次に、本発明の第２の実施の形態について説明する。本実施の形態は、各リソース管理サーバＲＭＳｉがそれぞれの隣接サーバＲＭＳｉ−１，ｉ＋１の通信状態を検出し、隣接サーバＲＭＳｉ−１，ｉ＋１が通信不能となったときに、リソース擬似解放処理を行うものである。

２−１．リソース管理サーバＲＭＳｉの構成
図９は、本実施の形態で用いられるリソース管理サーバＲＭＳｉの機能ブロック図である。この図において、図２における構成要素に相当する構成要素を同一符号で示し、その説明を適宜省略する。

図９に示すリソース管理サーバＲＭＳｉは、通信状態検出部３０７を備えている。通信状態検出部３０７は、隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１との間で、アプリケーションレベル（起動しているプログラムまたは開始しているサービスレベル）で相互に通信可能か否かを検出する。例えば、隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１との間で所定の通信状態確認メッセージを定期的に送信し合い、隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１からの通信状態確認メッセージが定期的に受信されているときには、隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１は通信可能であると判定し、先の通信状態確認メッセージが受信されてから所定時間以上にわたって次の通信状態確認メッセージが受信されないときには、隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１は通信不能になったと判断することができる。なお、通信不能となる原因としては、サーバ間のＴＣＰコネクションの切断や、サーバのダウン等が考えられる。

リソース擬似解放処理部（リソース擬似解放要求メッセージ作成部）３１５は、リソース確保要求メッセージの送信元である隣接サーバＲＭＳｉ−１の通信不能が検出されたときに、その旨を保守端末ｉ４に通知し、これに対する保守端末ｉ４からの指示に基づいてリソース擬似解放要求メッセージ（第１のリソース解放要求メッセージ）をメッセージ解析部３０１へ出力し、隣接サーバＲＭＳｉ−１からのリソース解放要求メッセージが受信されたときと同様の処理をメッセージ解析部３０１、リソース管理部３１３、メッセージ作成部３０４およびエラーログ管理部３０６に擬似的に行わせる。

本実施の形態では、各リソース管理サーバＲＭＳｉでそれぞれの隣接サーバＲＭＳｉ−１，ｉ＋１の通信状態を検出する機能を有するため、第１の実施の形態のようにリソースが確保されてから解放されることなく基準時間が経過したか否かを検出する必要がない。したがって、リソース管理テーブル２１３には、「タイマ」および「リソース確保状態」の項目がなくてもよい。

２−２．リソース管理サーバＲＭＳｉの動作
次に、複数の管理範囲を経由する通信を行う際のリソースの確保から解放または擬似解放までの一連の処理について説明する。
図１０は、リソース管理サーバＲＭＳｉによって行われるリソースの確保から解放または擬似解放までの一連の処理の流れの概略を示すフローチャートである。
複数の管理範囲を経由する通信を開始する際には、その通信に必要なリソースの確保を要求するリソース確保要求メッセージが隣接サーバＲＭＳｉ−１から送られて来る。リソース管理サーバＲＭＳｉは、このリソース確保要求メッセージを受信すると（ステップＳ１０１，ＹＥＳ）、自己の管理範囲ＮＷｉ内において、要求されたリソースを確保する（ステップＳ１０２）。

その後、通信を終了する際に、その通信のために確保されていたリソースの解放を要求するリソース解放要求メッセージが隣接サーバＲＭＳｉ−１から送られて来る。リソース管理サーバＲＭＳｉは、このリソース解放要求メッセージを受信すると（ステップＳ１０３，ＹＥＳ）、自己の管理範囲ＮＷｉ内において、確保されていたリソースを解放し（ステップＳ１０４）、一連の処理を終了する。
しかし、リソース解放要求メッセージが送られて来る前に（ステップＳ１０３，ＮＯ）、隣接サーバＲＭＳｉ−１がダウンするなどして通信不能となると（ステップＳ１０５，ＹＥＳ）、リソース解放要求メッセージが受信されたときと同様に、確保されていたリソースの解放処理を擬似的に行い（ステップＳ１０６）、一連の処理を終了する。

以上の処理において、ステップＳ１０２のリソース確保処理およびＳ１０４のリソース解放処理は、第１の実施の形態における図６および図７に示した処理と概ね同じであるから、その説明は省略する。ただし、本実施の形態では、リソースが確保されてからの時間をカウントしないので、図６のステップＳ２３，Ｓ２６および図７のステップＳ４５は不要である。
ここでは、ステップＳ１０６のリソース擬似解放処理について詳細に説明する。図１１は、リソース管理サーバＲＭＳｉによるリソース擬似解放処理の流れを示すフローチャートである。

リソース管理サーバＲＭＳｉは、隣接サーバＲＭＳｉ−１，ＲＭＳｉ＋１と、通信状態確認メッセージを定期的に送信し合う。隣接サーバＲＭＳｉ−１がダウンすると、この隣接サーバＲＭＳｉ−１からの通信状態確認メッセージが、リソース管理サーバＲＭＳｉで受信されなくなる。隣接サーバＲＭＳｉ−１からの通信状態確認メッセージが所定時間以上にわたって受信されなくなった時点で、リソース管理サーバＲＭＳｉの通信状態検出部３０７は、隣接サーバＲＭＳｉ−１が通信不能になったと判断し、その旨をリソース擬似解放処理部３１５へ通知する。

この通知を受けたリソース擬似解放処理部３１５は、リソース管理部３０３に対し、隣接サーバＲＭＳｉ−１からのリソース確保要求メッセージの受信によって自己の管理範囲ＮＷｉ内において確保されてから未だに解放されていないリソースの検索を依頼する。上述したように、隣接サーバＲＭＳｉ−１からのリソース確保要求メッセージの受信によってリソースが確保されると、リソース管理テーブル２０３の「送信元サーバＩＤ」に、隣接サーバＲＭＳｉ−１のサーバＩＤが記載される。そこで、リソース擬似解放処理部３１５からの依頼を受けたリソース管理部３０３は、リソース管理テーブル２０３を参照して、「送信元サーバＩＤ」として隣接サーバＲＭＳｉ−１のサーバＩＤが記載された未解放リソースＲ２の情報（「リソースＩＤ」、「送信元リソースＩＤ」等を含む）を検索する（ステップＳ１６１）。

この未解放リソースＲ２の情報をリソース擬似解放処理部３１５に返信すると、リソース擬似解放処理部３１５は、保守端末ｉ４に対し、隣接サーバＲＭＳｉ−１が通信不能になったことと、隣接サーバＲＭＳｉ−１からのリソース確保要求メッセージの受信によって確保された未解放リソースＲ２の情報のリストとを通知する（ステップＳ１６２）。これらは、保守端末ｉ４のディスプレイに表示される。

この表示を見た保守者が保守端末ｉ４を操作し、リソース擬似解放処理部３１５に対し未解放リソースＲ２の解放を指示すると、リソース擬似解放処理部３１５は、未解放リソースＲ２の解放を要求するリソース擬似解放要求メッセージ（第１のリソース解放要求メッセージ）を作成し、メッセージ解析部３０１へ出力する（ステップＳ１６３）。リソース擬似解放要求メッセージが入力されたメッセージ解析部３０１は、リソース解放要求メッセージが受信されたときと同じように動作し、その後のリソース管理部３０３、メッセージ作成部３０４およびエラーログ管理部３０６の動作もリソース解放要求メッセージが受信されたときと同様である（ステップＳ１６４〜Ｓ１６８）。その動作は図８のステップＳ６３〜Ｓ６６，Ｓ６８と概ね同じであるから、その説明は省略する。ただし、本実施の形態では、リソースが確保されてからの時間をカウントしないので、図８のステップＳ６７は不要である。

例えば、通信の発端末および着端末がそれぞれ管理範囲ＮＷ１内および管理範囲ＮＷ３内にあり、管理範囲ＮＷ１を管理するリソース管理サーバＲＭＳ１がダウンした場合には、ダウンしたリソース管理サーバＲＭＳ１からリソース解放要求メッセージが送られて来なくても、リソース管理サーバＲＭＳ２がステップＳ１６１〜Ｓ１６８の処理を行うことによって、自己の管理範囲ＮＷ２において確保されたリソースを解放することができる。
また、リソース管理サーバＲＭＳ２からリソース管理サーバＲＭＳ３へリソース擬似解放要求メッセージ（第２のリソース解放要求メッセージ）を送信することによって、リソース管理サーバＲＭＳ３がリソース解放要求メッセージを受信したときの同様に図７のステップＳ４１，Ｓ４３，Ｓ４４，Ｓ４６と同様の処理を行い、自己の管理範囲ＮＷ３において確保されたリソースを解放することができる。

なお、本実施の形態では、リソース擬似解放処理部３１５が保守端末ｉ４からの指示に基づいてリソース擬似解放処理を開始する例を示したが、通信状態検出部３０７からリソース管理サーバＲＭＳｉの通信不能が通知された時点で、保守端末ｉ４からの指示に基づくことなくリソース擬似解放処理を開始するようにしてもよい。

３．第３の実施の形態
次に、本発明の第３の実施の形態について説明する。本実施の形態は、各リソース管理サーバＲＭＳｉの管理者が、その管理範囲ＮＷｉにおいて確保されているリソースを強制的に解放できるようにしたものである。

３−１．リソース管理サーバＲＭＳｉの構成
図１２は、本実施の形態で用いられるリソース管理サーバＲＭＳｉの機能ブロック図である。この図において、図２における構成要素に相当する構成要素を同一符号で示し、その説明を適宜省略する。

図１２に示すリソース管理サーバＲＭＳｉは、保守運用部（リソース擬似解放要求メッセージ作成部）３２５を備えている。保守運用部３２５は、保守端末ｉ４からの指示を受けて、当該リソース管理サーバＲＭＳｉの保守・運用に必要な処理を行う。具体的には、保守端末ｉ４からのリソース情報閲覧要求を受けて、リソース管理部３０３を制御し、リソース管理テーブル２０２に登録されているリソースの情報を読み出し、送受信部ｉ１より保守端末ｉ４へ送信する。また、保守端末ｉ４からのリソース解放要求を受けて、リソース擬似解放要求メッセージ（第１のリソース解放要求メッセージ）をメッセージ解析部３０１へ出力し、隣接サーバＲＭＳｉ−１からのリソース解放要求メッセージが受信されたときと同様の処理をメッセージ解析部３０１、リソース管理部３０３、メッセージ作成部３０４およびエラーログ管理部３０６に擬似的に行わせる。

３−２．リソース管理サーバＲＭＳｉの動作
次に、複数の管理範囲を経由する通信を行う際のリソースの確保から解放または擬似解放までの一連の処理について説明する。
図１３は、リソース管理サーバＲＭＳｉによって行われるリソースの確保から解放または擬似解放までの一連の処理の流れの概略を示すフローチャートである。この図のステップＳ１〜Ｓ４は図５のステップＳ１〜Ｓ４と同じであるから、その説明は省略する。

保守者が保守端末ｉ４を操作し、保守運用部３２５に対し、未解放リソースの情報についての閲覧要求を送信する（ステップＳ２０５，ＹＥＳ）。この要求を受けた保守運用部３２５は、リソース管理部３０３を制御し、自己の管理範囲ＮＷｉ内において確保されている未解放リソースＲ３の情報（「リソースＩＤ」、「送信元サーバＩＤ」、「送信元リソースＩＤ」等を含む）をリソース管理テーブル２０３から読み出し、読み出されたリソースＲ３の情報を保守端末ｉ４へ返信する。このリソースＲ３の情報は保守端末ｉ４のディスプレイに表示される（ステップＳ２０６）。

この表示を見た保守者が保守端末ｉ４を再び操作し、保守運用部３２５に対し未解放リソースＲ３の解放要求を送信すると（ステップＳ２０７，ＹＥＳ）、この要求を受けた保守運用部３２５は、未解放リソースＲ３の解放処理を擬似的に行う（ステップＳ２０８）。すなわち、保守運用部３２５は、未解放リソースＲ３の解放を要求するリソース擬似解放要求メッセージ（第１のリソース解放要求メッセージ）を作成し、メッセージ解析部３０１へ出力する。リソース擬似解放要求メッセージが入力されたメッセージ解析部３０１は、リソース解放要求メッセージが受信されたときと同じように動作し、その後のリソース管理部３０３、メッセージ作成部３０４およびエラーログ管理部３０６の動作もまた、リソース解放要求メッセージが受信されたときと同様である。このリソース擬似解放処理の詳細は、図８のステップＳ６３〜Ｓ６８と同様であるから、その説明は省略する。

本実施の形態によれば、リソース解放要求が送られて来なくても、リソース管理サーバＲＭＳｉの保守者の指示により、自己の管理範囲ＮＷｉにおいて確保されたリソースを解放することができる。また、図８のステップＳ６４のように、隣接サーバＲＭＳｉ＋１へリソース擬似解放要求メッセージ（第２のリソース解放要求メッセージ）を送信することによって、隣接サーバＲＭＳｉ＋１がリソース解放要求メッセージを受信したときの同様に図７のステップＳ４１〜Ｓ４６と同様の処理を行い、その管理範囲ＮＷｉ＋１において確保されたリソースを解放することができる。したがって、リソース管理サーバＲＭＳｉの保守者の指示により、複数の管理範囲にまたがる一連のリソースを解放することが可能となる。

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

本発明の第１の実施の形態にかかるリソース管理システムの概要を示すブロック図である。 本発明の第１の実施の形態におけるリソース管理サーバの機能ブロック図である。 リソース管理テーブルのデータ構造の一例を示す図である。 リソース擬似解放要求メッセージのフォーマットの一例を示す図である。 リソース管理サーバによって行われるリソースの確保から解放または擬似解放までの一連の処理の流れの概略を示すフローチャートである。 リソース管理サーバによるリソース確保処理の流れを示すフローチャートである。 リソース管理サーバによるリソース解放処理の流れを示すフローチャートである。 リソース管理サーバによるリソース擬似解放処理の流れを示すフローチャートである。 本発明の第２の実施の形態におけるリソース管理サーバの機能ブロック図である。 リソース管理サーバによって行われるリソースの確保から解放または擬似解放までの一連の処理の流れの概略を示すフローチャートである。 リソース管理サーバによるリソース擬似解放処理の流れを示すフローチャートである。 本発明の第３の実施の形態におけるリソース管理サーバの機能ブロック図である。 リソース管理サーバによって行われるリソースの確保から解放または擬似解放までの一連の処理の流れの概略を示すフローチャートである。

符号の説明

１１，２１，３１…送受信部、１２，２２，３２…データベース部、１３，２３，３３…サーバ本体、１４，２４，３４…保守端末、２０１…アドレスリスト、２０２…経路情報、２０３，２１３…リソース管理テーブル、３０１…メッセージ解析部、３０２…着端末存否判定部、３０３，３１３…リソース管理部、３０４…メッセージ作成部、３０５，３１５…リソース擬似解放処理部、３０６…エラーログ管理部、３０７…通信状態検出部、３２５…保守運用部、ＡＳ…アプリケーションサーバ、ＮＷ１〜ＮＷ３…管理範囲（通信ネットワーク）、Ｒ１１〜Ｒ１４，Ｒ２１〜Ｒ２４，Ｒ３１〜Ｒ３４，…ルータ、ＲＭＳ１〜ＲＭＳ３…リソース管理サーバ、Ｔ１１，Ｔ１２，Ｔ３１，Ｔ３２…端末。

Claims (17)

1. 互いにリンクされた複数のルータと端末とから構成される通信ネットワークを分割した複数の管理範囲ごとに設けられ、それぞれの管理範囲内におけるリソースを管理するリソース管理装置であって、
   当該リソース管理装置の管理範囲内でリソースを確保するリソース確保手段と、
   確保された前記リソースを特定する情報を記録する記録手段と、
   前記情報が付加された第１のリソース解放要求メッセージを作成するメッセージ作成手段と、
   前記記録手段を参照して前記第１のリソース解放要求メッセージに付加された前記情報により前記リソースを特定し、特定された前記リソースを解放するリソース解放手段と
   を備えることを特徴とするリソース管理装置。
2. 請求項１に記載のリソース管理装置において、
   要求される通信における着端末の識別子および確保したいリソース量を含むリソース確保要求メッセージを受信するメッセージ受信手段と、
   前記リソース確保要求メッセージに含まれる前記識別子に対応する前記着端末が前記当該リソース管理装置の管理範囲内にないときに、管理範囲が隣接する他のリソース管理装置へ前記リソース確保要求メッセージを送信するメッセージ送信手段とを更に備え、
   前記リソース確保手段は、
   前記リソース確保要求メッセージが受信されたときに前記リソースを確保するとともに、確保された前記リソースを特定する前記情報を前記記録手段に記録し、
   前記リソース確保要求メッセージが前記他のリソース管理装置へ送信されたときに、前記記録手段に記録されている前記情報に前記他のリソース管理装置の識別子を関連づけて記録することを特徴とするリソース管理装置。
3. 請求項２に記載のリソース管理装置において、
   前記メッセージ送信手段は、前記第１のリソース解放要求メッセージに基づく前記リソースの解放時に、前記記録手段において前記リソースを特定する前記情報に関係づけられた前記識別子に対応する前記他のリソース管理装置へ、前記他のリソース管理装置の管理範囲内で確保されたリソースを特定する情報が付加された第２のリソース解放要求メッセージを送信することを特徴とするリソース管理装置。
4. 請求項３に記載のリソース管理装置において、
   前記メッセージ受信手段は、前記当該リソース管理装置の管理範囲内で確保された前記リソースを特定する前記情報が付加された第３のリソース解放要求メッセージを受信し、
   前記リソース解放手段は、前記記録手段を参照して前記第３のリソース解放要求メッセージに付加された前記情報により前記リソースを特定し、特定された前記リソースを解放することを特徴とするリソース管理装置。
5. 請求項１に記載のリソース管理装置において、
   前記リソース確保手段により前記リソースが確保されてからの時間をカウントするタイマを更に備え、
   前記メッセージ作成手段は、確保された前記リソースが解放されることなく所定時間を経過したときに、前記リソースに対する前記第１のリソース解放要求メッセージを作成することを特徴とするリソース管理装置。
6. 請求項２に記載のリソース管理装置において、
   前記リソース確保要求メッセージの送信元との通信状態を検出する通信状態検出手段と、
   前記送信元との通信不能が検出されたときに、前記送信元からの前記リソース確保要求メッセージにより前記当該リソース管理装置の管理範囲内で確保されてから未だに解放されていないリソースを検索する未解放リソース検索手段とを更に備え、
   前記メッセージ作成手段は、検索されたリソースに対する前記第１のリソース解放要求メッセージを作成することを特徴とするリソース管理装置。
7. 請求項１に記載のリソース管理装置において、
   前記当該リソース管理装置の保守者による操作に基づき確保済みのリソースに対する解放要求を前記メッセージ作成手段へ出力する管理端末を更に備え、
   前記メッセージ作成手段は、前記解放要求に基づき前記第１のリソース解放要求メッセージを作成することを特徴とするリソース管理装置。
8. 請求項１〜７の何れか１項に記載のリソース管理装置において、
   リソースの解放に失敗したときに解放失敗を示すログを作成し保持するログ管理手段を更に備えることを特徴とするリソース管理装置。
9. 互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けられたリソース管理装置によって前記通信ネットワークのリソースを管理するリソース管理方法であって、
   一のリソース管理装置において、前記一のリソース管理装置の管理範囲内でリソースを確保するとともに、前記リソースを特定する情報を記録手段に記録するステップと、
   前記情報が付加された第１のリソース解放要求メッセージを作成するステップと、
   前記第１のリソース解放要求メッセージに基づき、前記記録手段を参照して前記情報により前記リソースを特定し、特定された前記リソースを解放するステップと
   を備えることを特徴とするリソース管理方法。
10. 請求項９に記載のリソース管理方法において、
    要求される通信における着端末の識別子および確保したいリソース量を含むリソース確保要求メッセージを受信するステップと、
    前記リソース確保要求メッセージに含まれる前記識別子に対応する前記着端末が前記一のリソース管理装置の管理範囲内にないときに、管理範囲が隣接する他のリソース管理装置へ前記リソース確保要求メッセージを送信するとともに、前記記録手段に記録されている前記情報に前記他のリソース管理装置の識別子を関連づけて記録するステップとを更に備え、
    前記リソースを確保するステップは、前記リソース確保要求メッセージが受信されたときに前記リソースを確保することを特徴とするリソース管理方法。
11. 請求項１０に記載のリソース管理方法において、
    前記第１のリソース解放要求メッセージに基づく前記リソースの解放時に、前記記録手段から前記リソースを特定する前記情報に関係づけられた前記識別子を検索するステップと、
    検索された前記識別子に対応する前記他のリソース管理装置へ、前記他のリソース管理装置の管理範囲内で確保されたリソースを特定する情報が付加された第２のリソース解放要求メッセージを送信するステップと
    を更に備えることを特徴とするリソース管理方法。
12. 請求項１１に記載のリソース管理方法において、
    前記他のリソース管理装置において、前記第２のリソース解放要求メッセージを受信するステップと、
    前記第２のリソース解放要求メッセージに付加された前記情報により、前記他のリソース管理装置の管理範囲内で確保された前記リソースを特定し、特定された前記リソースを解放するステップと
    を備えることを特徴とするリソース管理方法。
13. 請求項９に記載のリソース管理方法において、
    前記第１のリソース解放要求メッセージを作成するステップは、確保された前記リソースが解放されることなく所定時間を経過したときに、前記リソースに対する前記第１のリソース解放要求メッセージを作成することを特徴とするリソース管理方法。
14. 請求項１０に記載のリソース管理方法において、
    前記リソース確保要求メッセージの送信元との通信状態を検出するステップと、
    前記送信元との通信不能が検出されたときに、前記送信元からの前記リソース確保要求メッセージにより前記一のリソース管理装置の管理範囲内で確保されてから未だに解放されていないリソースを検索するステップとを更に備え、
    前記第１のリソース解放要求メッセージを作成するステップは、検索されたリソースに対する前記第１のリソース解放要求メッセージを作成することを特徴とするリソース管理方法。
15. 請求項９に記載のリソース管理方法において、
    前記第１のリソース解放要求メッセージを作成するステップは、前記一のリソース管理装置の保守者による確保済みのリソースに対する解放要求に基づき、前記第１のリソース解放要求メッセージを作成することを特徴とするリソース管理方法。
16. 請求項９〜１５の何れか１項に記載のリソース管理方法において、
    リソースの解放に失敗したときに解放失敗を示すログを作成し保持するステップを更に備えることを特徴とするリソース管理方法。
17. 互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けられたリソース管理装置によって前記通信ネットワークのリソースを管理するリソース管理システムであって、
    前記リソース管理装置は、請求項１〜８の何れか１項に記載のリソース管理装置であることを特徴とするリソース管理システム。
    

Images