(57)【要約】【課題】  複数の管理範囲にまたがる一連のリソースの確保を要求するリソース確保要求をキャンセルする。【解決手段】  要求メッセージを受信した一のリソース管理装置（ＲＭＳ１）において、受信した要求メッセージから、要求される通信における着端末が当該リソース管理装置の管理範囲内にあるか否かを判定し、この判定の結果、前記着端末が当該リソース管理装置の管理範囲（ＮＷ１）内にないと判定されたときは、当該リソース管理装置の管理範囲(ＮＷ１）内において必要なリソースを確保するとともに、隣接する他の管理範囲（ＮＷ２）のリソースを管理する他のリソース管理装置（ＲＭＳ２）に前記要求メッセージを送信する一方、必要に応じてこの要求メッセージをキャンセルするキャンセルメッセージを前記他のリソース管理装置に送信する。【選択図】        図１
2006287850.tif 000002
【特許請求の範囲】
【請求項１】
互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けた複数のリソース管理装置によって前記通信ネットワークのリソースを管理するリソース管理方法であって、
一のリソース管理装置において、要求される通信における着端末の識別子と確保したいリソース量とを少なくとも含む要求メッセージを受信する第１の受信ステップと、
受信した要求メッセージに含まれた前記識別子に対応する前記着端末が当該リソース管理装置の管理範囲内にあるか否かを判定する第１の判定ステップと、
この判定ステップの結果、前記着端末が当該リソース管理装置の管理範囲内にないと判定されたときは、隣接する他の管理範囲のリソースを管理する他のリソース管理装置に前記要求メッセージを送信する第１の送信ステップと、
前記要求メッセージをキャンセルするキャンセルメッセージを前記他のリソース管理装置に送信する第２の送信ステップと
を有することを特徴とするリソース管理方法。
【請求項２】
請求項１に記載されたリソース管理方法において、
さらに、
当該リソース管理装置の管理範囲内において前記要求メッセージの受信に応じてリソースを確保する第１の管理ステップと、
先に受信した要求メッセージに対するキャンセルメッセージを受信する第２の受信ステップと、
当該リソース管理装置の管理範囲内において前記要求メッセージの受信に応じて確保されたリソースを前記キャンセルメッセージの受信に応じて解放する解放ステップと
を有する
ことを特徴とするリソース管理方法。
【請求項３】
請求項１に記載されたリソース管理方法において、
さらに、当該リソース管理装置の管理範囲内において、受信した前記要求メッセージに応じたリソースを確保する処理を実行する第１の管理ステップを有し、
前記第２の送信ステップは、
前記第１の管理ステップにおいて前記要求メッセージに応じたリソースを確保できなかったときに、前記キャンセルメッセージを前記他のリソース管理装置に送信する
ことを特徴とするリソース管理方法。
【請求項４】
請求項１乃至３のいずれか１つに記載されたリソース管理方法において、
前記第２の送信ステップは、
前記要求メッセージの送信先である前記他のリソース管理装置の管理範囲内においてリソースが確保されているか否かを判定し、確保されている場合には前記キャンセルメッセージを送信し、確保されていない場合には、前記キャンセルメッセージを送信しない
ことを特徴とするリソース管理方法。
【請求項５】
請求項１乃至４のいずれか１つに記載のリソース管理方法において、
さらに、
前記他のリソース管理装置からの前記要求メッセージに対する応答メッセージを当該リソース管理装置において受信したか否かを判定する第２の判定ステップを有し、
前記第２の送信ステップは、
前記応答メッセージを受信しないときに、前記キャンセルメッセージを前記要求メッセージの送信先に送信する
ことを特徴とするリソース管理方法。
【請求項６】
請求項１乃至５のいずれか１つに記載のリソース管理方法において、
さらに、
前記第１の受信ステップにおいて受信した要求メッセージの送信元を識別する識別子を管理する第２の管理ステップ
を有し、
前記第２の送信ステップは、
前記識別子によって特定される当該要求メッセージの送信元に前記キャンセルメッセージを送信する
ことを特徴とするリソース管理方法。
【請求項７】
請求項６に記載のリソース管理方法において、
前記第２の管理ステップは、
前記要求メッセージの送信元を識別する識別子として前記着端末の識別子を管理する
ことを特徴とするリソース管理方法。
【請求項８】
請求項６に記載のリソース管理方法において、
前記第２の管理ステップは、
前記要求メッセージの送信元を識別する識別子として前記要求される通信を識別する固有の識別子を管理する
ことを特徴とするリソース管理方法。
【請求項９】
請求項６に記載のリソース管理方法において、
前記第２の管理ステップは、
前記要求メッセージの送信元を識別する識別子として、要求メッセージを送信する当該リソース管理装置の管理範囲において確保されたリソースに対して割り当てられたリソースＩＤを管理する
ことを特徴とするリソース管理方法。
【請求項１０】
請求項１乃至９のいずれかに記載されたリソース管理方法において、
要求メッセージに対して当該リソース管理装置の管理範囲内におけるリソース確保の状態と、他のリソース管理装置におけるリソース確保の結果とのうち少なくとも１つを表示する表示ステップを有すること
ことを特徴とするリソース管理方法。
【請求項１１】
互いにリンクされた複数のルータと端末とから構成される通信ネットワークを分割した複数の管理範囲ごとに設けられ、前記通信ネットワークのリソースを管理するリソース管理装置であって、
要求される通信における着端末の識別子と確保したいリソース量とを少なくとも含む要求メッセージを受信する第１の受信部と、
受信した要求メッセージに含まれた前記識別子に対応する前記着端末が当該リソース管理装置の管理範囲内にあるか否かを判定する第１の判定部と、
この判定ステップの結果、前記着端末が当該リソース管理装置の管理範囲内にないと判定されたときは、隣接する他の管理範囲のリソースを管理する他のリソース管理装置に前記要求メッセージを送信する第１の送信部と、
前記要求メッセージをキャンセルするキャンセルメッセージを前記他のリソース管理装置に送信する第２の送信部と
を有することを特徴とするリソース管理装置。
【請求項１２】
請求項１１に記載されたリソース管理装置において、
さらに、
当該リソース管理装置の管理範囲内において前記要求メッセージの受信に応じてリソースを確保する第１の管理部と、
先に受信した要求メッセージに対するキャンセルメッセージを受信する第２の受信部と
を有し、
前記第１の管理部は、
当該リソース管理装置の管理範囲内において前記要求メッセージの受信に応じて確保されたリソースを前記キャンセルメッセージの受信に応じて解放する
ことを特徴とするリソース管理装置。
【請求項１３】
請求項１１に記載されたリソース管理装置において、
さらに、当該リソース管理装置の管理範囲内において、受信した前記要求メッセージに応じたリソースを確保する処理を実行する第１の管理部を有し、
前記第２の送信部は、
前記第１の管理部において前記要求メッセージに応じたリソースを確保できなかったときに、前記キャンセルメッセージを前記他のリソース管理装置に送信する
ことを特徴とするリソース管理装置。
【請求項１４】
請求項１１乃至１３のいずれか１つに記載されたリソース管理装置において、
前記第２の送信部は、
前記要求メッセージの送信先である前記他のリソース管理装置の管理範囲内においてリソースが確保されているか否かを判定し、確保されている場合には前記キャンセルメッセージを送信し、確保されていない場合には、前記キャンセルメッセージを送信しない
ことを特徴とするリソース管理装置。
【請求項１５】
請求項１１乃至１４のいずれか１つに記載のリソース管理装置において、
さらに、前記他のリソース管理装置からの前記要求メッセージに対する応答メッセージを当該リソース管理装置において受信したか否かを判定する第２の判定部を有し、
前記第２の送信部は、
前記応答メッセージを受信しないときに、前記キャンセルメッセージを前記要求メッセージの送信先に送信する
ことを特徴とするリソース管理装置。
【請求項１６】
請求項１１乃至１５のいずれか１つに記載のリソース管理装置において、
さらに、
前記第１の受信部において受信した要求メッセージの送信元を識別する識別子を管理する第２の管理部
を有し、
前記第２の送信部は、
前記識別子によって特定される当該要求メッセージの送信元に前記キャンセルメッセージを前記識別子を付加して送信する
ことを特徴とするリソース管理装置。
【請求項１７】
請求項１６に記載のリソース管理装置において、
前記第２の管理部は、
前記要求メッセージの送信元を識別する識別子として前記着端末の識別子を管理する
ことを特徴とするリソース管理装置。
【請求項１８】
請求項１６に記載のリソース管理装置において、
前記第２の管理部は、
前記要求メッセージの送信元を識別する識別子として前記要求される通信を識別する固有の識別子を管理する
ことを特徴とするリソース管理装置。
【請求項１９】
請求項１６に記載のリソース管理装置において、
前記第２の管理部は、
前記要求メッセージの送信元を識別する識別子として、要求メッセージを送信する当該リソース管理装置の管理範囲において確保されたリソースに対して割り当てられたリソースＩＤを管理する
ことを特徴とするリソース管理装置。
【請求項２０】
請求項１１乃至１９のいずれかに記載されたリソース管理装置において、
要求メッセージに対して当該リソース管理装置の管理範囲内におけるリソース確保の状態と、他のリソース管理装置におけるリソース確保の結果とのうち少なくとも１つを表示する表示表示部を有すること
ことを特徴とするリソース管理装置。
【請求項２１】
互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けた複数のリソース管理装置によって前記通信ネットワークのリソースを管理するリソース管理システムであって、
前記リソース管理装置は、請求項１１乃至２０のいずれかに記載されたリソース管理装置であることを特徴とするリソース管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークにおけるリソースを管理するリソース管理方法およびリソース管理装置ならびにリソース管理システムに関する。
【背景技術】
【０００２】
通信ネットワーク、特にＩＰ（Internet  Protocol）ネットワークを利用して音声や映像等のコンテンツを提供する場合、通信路の容量を超えた利用要求によって輻輳が発生すると、パケットの損失等に伴い通信品質が劣化してしまう。
従来より、このような通信品質の劣化を防ぐことを目的として、リソース管理装置によるネットワークレイヤにおけるリソース管理が研究されている。
【０００３】
リソース管理装置によるリソース管理は、通信ネットワークを構成するルータとは独立したサーバ（以下、「リソース管理サーバ」または「リソース管理装置」という）により、通信ネットワークを構成するノード間（リンク）の伝送容量とその利用状況を管理するとともに、ユーザ端末等からのリソース確保要求に対して適当なリソースを払い出すものである。
【０００４】
このようなリソース管理の一例として、次のような方法が開示されている。
まず、通信ネットワークの運用開始前に、その通信ネットワーク中のリンク（接続情報）および各リンクのリソース容量を含むルーティング情報に基づいて、パケットが通過する経路を計算し、これを記憶装置に記憶させるとともに、各リンクのリソース容量を記憶させる。計算された経路を記憶したものを「経路テーブル」、各リンクのリソース容量を記憶したものを「リソース管理テーブル」という。このリソース管理テーブルによって、その通信ネットワークにおける総リソース容量と利用中のリソース容量または利用可能な残りリソース容量とが管理される。
【０００５】
通信ネットワークの運用開始後にあっては、リソース管理サーバは、通信サービスの利用要求（リソース確保要求）を受け付けると、要求された通信の発着ＩＰアドレスを基に上記経路テーブルから当該通信に必要となるリンクを特定し、上記リソース管理テーブルを参照することによって、これらのリンクのそれぞれについて当該通信に必要となる伝送容量（リソース）が利用可能か否かをチェックする。
十分なリソースが利用可能である場合には、上記通信サービスの利用要求に対して許諾応答するとともに、上記リソース管理テーブルの利用中リソース容量に当該通信に割り当てられるリソース量を加算して記憶させる。一方、必要なリソースを確保できない場合には、上記利用要求に対して不許可とする（特許文献１および非特許文献１参照）。
また、リソースの使用終了時には、それまで通信用に確保していたリソースを速やかに解放しなければならない。
【０００６】
なお、出願人は、本明細書に記載した先行技術文献情報で特定される先行技術文献以外には、本発明に関連する先行技術文献を出願時までに発見するには至らなかった。
【特許文献１】特開２００３−２５８８５５号公報
【非特許文献１】矢口他、「大規模ＩＰ網における管理サーバを用いたリソース管理方式の一提案と具体例」、信学総合大会、Ｂ−６−３１（２００２）
【発明の開示】
【発明が解決しようとする課題】
【０００７】
通信ネットワークが大規模になると、管理しなければならないリソースが膨大となるとともに、リソース管理装置が対応すべきリソース確保要求が増大するので、１台のリソース管理装置が通信ネットワーク全体のリソースを管理することは困難となる。
このような問題に対処するには、通信ネットワークを、例えば地域ごとに複数の管理範囲に分割し、これらの管理範囲にそれぞれリソース管理装置を設けることが考えられる。また、異なる事業者によって運用されている通信ネットワークにはそれぞれリソース管理装置が存在している。これら複数の通信ネットワークを接続する場合には、大きな通信ネットワークを事業者ごとに分割し、それぞれに各事業者の通信ネットワークを管理範囲とするリソース管理装置を設けたものと考えることができる。
このような通信ネットワークにおいて、通信を行う発端末と着端末とがそれぞれ異なる管理範囲に属する場合には、それぞれの管理範囲内で別々にリソースを確保することとなる。
【０００８】
しかしながら、複数の管理範囲にまたがるリソース確保要求は、リソース管理装置にとって自己の管理範囲にない発端末または着端末を含むので、従来のリソース管理装置では、このようなリソース確保要求に対応することができないという問題があった。
また、複数の管理範囲にまたがるリソース確保要求に対応できたとしても、各リソース管理装置は、自己の管理範囲内においてリソースを確保することができるのみなので、いずれか１つの管理範囲においてリソースが確保できなかった場合には、たとえ他のすべてのリソース管理装置においてリソースを確保できたとしても、ロールバックを行ったうえで、あらためてリソースの確保をやり直さなければならない。さらに、仮に各リソース管理装置がそれぞれの管理範囲内でリソースを確保できたとしても、それらの確保されたリソースを管理範囲間で整合させるには、さらに多くの時間が必要となる。
【０００９】
したがって、複数の管理範囲にまたがるリソース確保要求に対して、各リソース管理装置がそれぞれの管理範囲内で別々にリソースを確保していたのでは、必要なリソースを確保するまでに多くの処理時間が必要となり、現実には一連のリソースを確保することが困難である。そこで、発明者等は、複数の管理範囲にまたがるリソースに関する要求に対しては、複数のリソース管理装置の間で要求メッセージを送受信しながら一連のリソースを確保する技術を開発した（特願２００４−３４９６４９）。
【００１０】
ところが、複数の管理範囲にわたって一連のリソースが確保される前に、リソースの確保を取り消したい場合も考えられる。例えば、複数の管理範囲のうちの一部においてでも必要なリソースが確保できなかった場合等には、複数の管理範囲にまたがって一連のリソースを確保することはできない。また、ユーザ自身が複数の管理範囲にわたって一連のリソースが確保される前にリソースの確保を取り消したい場合にも、一連のリソースの確保が完了する前なので、リソースを解放させるリソース解放要求を送受信することができず、その結果として、一部の管理範囲において確保済みのリソースを解放させることができないことも考えられる。このような状態を放置すれば、他の管理範囲においてはリソースが確保されたまま、有効に活用されない可能性がある。また、ユーザや事業者に無用な接続コストを負担させるおそれもある。
【００１１】
そこで、本発明は、複数の管理範囲にまたがるリソースを確保する際に、リソース確保要求をキャンセルできるようにすることを目的とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決するために、本発明は、複数の管理範囲にまたがるリソースに関する要求に対しては、複数のリソース管理装置の間でリソース確保要求メッセージ（以下、「要求メッセージ」という。）を送受信しながら一連のリソースを確保する一方、必要に応じて、要求メッセージをキャンセルするキャンセルメッセージを送信するものである。
具体的には、本発明にかかる第１のリソース管理方法は、互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けた複数のリソース管理装置によって前記通信ネットワークのリソースを管理するリソース管理方法であって、一のリソース管理装置において、要求される通信における着端末の識別子と確保したいリソース量とを少なくとも含む要求メッセージを受信する第１の受信ステップと、受信した要求メッセージに含まれた前記識別子に対応する前記着端末が当該リソース管理装置の管理範囲内にあるか否かを判定する第１の判定ステップと、この判定ステップの結果、前記着端末が当該リソース管理装置の管理範囲内にないと判定されたときは、隣接する他の管理範囲のリソースを管理する他のリソース管理装置に前記要求メッセージを送信する第１の送信ステップと、前記要求メッセージをキャンセルするキャンセルメッセージを前記他のリソース管理装置に送信する第２の送信ステップとを有することを特徴とする。
【００１３】
前記要求メッセージの送信先である他のリソース管理装置は、キャンセルメッセージを受信すると、先に受信した要求メッセージをキャンセルする。
【００１４】
また、本発明にかかる第２のリソース管理方法として、上記の第１のリソース管理方法において、さらに、当該リソース管理装置の管理範囲内において前記要求メッセージの受信に応じてリソースを確保する第１の管理ステップと、先に受信した要求メッセージに対するキャンセルメッセージを受信する第２の受信ステップと、当該リソース管理装置の管理範囲内において前記要求メッセージの受信に応じて確保されたリソースを前記キャンセルメッセージの受信に応じて解放する解放ステップとを有していてもよい。
【００１５】
また、本発明にかかる第３のリソース管理方法として、上記の第１のリソース管理方法において、さらに、当該リソース管理装置の管理範囲内において、受信した前記要求メッセージに応じたリソースを確保する処理を実行する第１の管理ステップを有し、前記第２の送信ステップは、前記第１の管理ステップにおいて前記要求メッセージに応じたリソースを確保できなかったときに、前記キャンセルメッセージを前記他のリソース管理装置に送信するようにしてもよい。
【００１６】
また、本発明にかかる第４のリソース管理方法として、上記のいずれかのリソース管理方法において、前記第２の送信ステップは、前記要求メッセージの送信先である前記他のリソース管理装置の管理範囲内においてリソースが確保されているか否かを判定し、確保されている場合には前記キャンセルメッセージを送信し、確保されていない場合には、前記キャンセルメッセージを送信しないようにしてもよい。
【００１７】
また、本発明にかかる第５のリソース管理方法として、上記のいずれかのリソース管理方法において、さらに、前記他のリソース管理装置からの前記要求メッセージに対する応答メッセージを当該リソース管理装置において受信したか否かを判定する第２の判定ステップを有し、前記第２の送信ステップは、前記応答メッセージを受信しないときに、前記キャンセルメッセージを前記要求メッセージの送信先に送信するようにしてもよい。
【００１８】
また、本発明にかかる第６のリソース管理方法として、上記のいずれかのリソース管理方法において、さらに、前記第１の受信ステップにおいて受信した要求メッセージの送信元を識別する識別子を管理する第２の管理ステップを有し、前記第２の送信ステップは、前記識別子によって特定される当該要求メッセージの送信元に前記キャンセルメッセージを送信するようにしてもよい。
【００１９】
キャンセルメッセージを、識別子に基づいて要求メッセージの送信元に送信することによって、一連のリソースが確保される前であっても送信元のリソース管理装置が確保したリソースを解放させることができる。
【００２０】
また、本発明にかかる第１のリソース管理装置は、互いにリンクされた複数のルータと端末とから構成される通信ネットワークを分割した複数の管理範囲ごとに設けられ、前記通信ネットワークのリソースを管理するリソース管理装置であって、要求される通信における着端末の識別子と確保したいリソース量とを少なくとも含む要求メッセージを受信する第１の受信部と、受信した要求メッセージに含まれた前記識別子に対応する前記着端末が当該リソース管理装置の管理範囲内にあるか否かを判定する第１の判定部と、この判定ステップの結果、前記着端末が当該リソース管理装置の管理範囲内にないと判定されたときは、隣接する他の管理範囲のリソースを管理する他のリソース管理装置に前記要求メッセージを送信する第１の送信部と、前記要求メッセージをキャンセルするキャンセルメッセージを前記他のリソース管理装置に送信する第２の送信部とを有することを特徴とする。
【００２１】
また、本発明にかかる第２のリソース管理装置として、上記の第１のリソース管理装置において、さらに、当該リソース管理装置の管理範囲内において、受信した前記要求メッセージに応じたリソースを確保する処理を実行する第１の管理部を有し、前記第２の送信部は、前記第１の管理部において前記要求メッセージに応じたリソースを確保できなかったときに、前記キャンセルメッセージを前記他のリソース管理装置に送信するようにしてもよい。
【００２２】
また、本発明にかかる第３のリソース管理装置として、上記の第１のリソース管理装置において、さらに、当該リソース管理装置の管理範囲内において前記要求メッセージの受信に応じてリソースを確保する第１の管理部と、先に受信した要求メッセージに対するキャンセルメッセージを受信する第２の受信部とを有し、前記第１の管理部は、当該リソース管理装置の管理範囲内において前記要求メッセージの受信に応じて確保されたリソースを前記キャンセルメッセージの受信に応じて解放するようにしてもよい。
【００２３】
また、本発明にかかる第４のリソース管理装置として、上記のいずれかのリソース管理装置において、前記第２の送信部は、前記要求メッセージの送信先である前記他のリソース管理装置の管理範囲内においてリソースが確保されているか否かを判定し、確保されている場合には前記キャンセルメッセージを送信し、確保されていない場合には、前記キャンセルメッセージを送信しないようにしてもよい。
【００２４】
また、本発明にかかる第５のリソース管理装置として、上記のいずれかのリソース管理装置において、さらに、前記他のリソース管理装置からの前記要求メッセージに対する応答メッセージを当該リソース管理装置において受信したか否かを判定する第２の判定部を有し、前記第２の送信部は、前記応答メッセージを受信しないときに、前記キャンセルメッセージを前記要求メッセージの送信先に送信するようにしてもよい。
【００２５】
また、本発明にかかる第６のリソース管理装置として、上記のいずれかのリソース管理装置において、さらに、前記第１の受信部において受信した要求メッセージの送信元を識別する識別子を管理する第２の管理部を有し、前記第２の送信部は、前記識別子によって特定される当該要求メッセージの送信元に前記キャンセルメッセージを前記識別子を付加して送信するようにしてもよい。
【００２６】
ここで要求メッセージの送信元と識別する上記識別子として、例えば、上記着端末の識別子を管理してもよいし、前記要求される通信を識別するために与えられた固有の識別子、例えば、要求メッセージを送信する当該リソース管理装置の管理範囲において確保されたリソースに対して割り当てられたリソースＩＤを管理してもよい。
【００２７】
また、本発明においては、要求メッセージに対して当該リソース管理装置の管理範囲内におけるリソース確保の状態と、他のリソース管理装置におけるリソース確保の結果とのうち少なくとも１つを表示するようにしてもよい。
【００２８】
また、前記リソース管理装置は、上述したリソース管理装置のいずれかを用いれば、互いにリンクされた複数のルータと端末とから構成される通信ネットワークを複数の管理範囲に分割し、これらの管理範囲ごとに設けた複数のリソース管理装置によって前記通信ネットワークのリソースを管理するリソース管理システムを構成することができる。
【発明の効果】
【００２９】
本発明によれば、複数の管理範囲にまたがるリソース確保要求に対して、複数のリソース管理装置の間で送信された要求メッセージをキャンセルすることができる。したがって、無駄なリソースの確保を防止することが可能となる。
また、キャンセルメッセージを受信したリソース管理装置において、すでに確保済みのリソースを解放することによって、一連のリソースが確立される前でもそれまでに確保されたリソースを解放することが可能となり、リソースの有効利用に資することができる。連携しながら一連のリソースを確保することができる。さらに、キャンセルメッセージを要求メッセージの送信先に加え、要求メッセージの送信元にも送ることによって、リソースをより効率的に利用することが可能となる。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施の形態について、図面を参照しながら説明する。
１．第１の実施の形態
１−１．  リソース管理システムの概要
図１は、本発明の第１の実施の形態にかかるリソース管理システムの概要を説明する図である。
このリソース管理システムは、通信ネットワークのリソースを管理する複数のリソース管理装置（サーバ）ＲＭＳ１，ＲＭＳ２から構成されている。
ここで管理対象となる通信ネットワークは、いわゆるインターネットプロトコル（ＩＰ）に基づく通信ネットワークであり、互いにリンクされた複数のルータＲ（Ｒ１１〜Ｒ１３，Ｒ２１〜Ｒ２３）と端末Ｔ（Ｔ１１〜Ｔ１６，Ｔ２１〜Ｔ２６）とから構成される。また、図１に示された通信ネットワークは、上記ルータおよび端末の他に、複数の端末を集線し、ルータと接続するレイヤー２スイッチＳＷ（ＳＷ１１，ＳＷ１２，ＳＷ２１，ＳＷ２２）やゲートウェイ装置ＧＷ（ＧＷ１１，ＧＷ２１）を含んでいる。
この通信ネットワークにおいて１対の端末が通信を行う際のリソースは、通信を行う二つの端末（発端末および着端末）間の通信路を構成する、端末とルータＲとの間のアクセスラインおよびルータＲ間のリンクである。
【００３１】
このリソース管理システムにおいては、通信ネットワークを複数の管理範囲ＮＷ１，ＮＷ２に分割し、これらの管理範囲に対して、それぞれリソース管理サーバＲＭＳ１，ＲＭＳ２が設けられている。図１によれば、リソース管理サーバＲＭＳ１は、管理範囲ＮＷ１のリソースを管理するリソース管理装置、リソース管理サーバＲＭＳ２は、管理範囲ＮＷ２のリソースを管理するリソース管理装置である。これらのリソース管理サーバＲＭＳ１，ＲＭＳ２は互いに通信可能に接続されている。
上述した構成は、個々の管理範囲ＮＷ１，ＮＷ２をそれぞれ一つの通信ネットワーク、リソース管理サーバＲＭＳ１，ＲＭＳ２をそれぞれ通信ネットワークＮＷ１，ＮＷ２のリソースを管理するリソース管理装置と考えることもできる。
【００３２】
アプリケーションサーバＡＳ（ＡＳ１，ＡＳ２）は、端末（例えば、端末１１）からの通信要求をうけて、当該端末が属する管理範囲（例えば管理範囲ＮＷ１）のリソースを管理するリソース管理サーバ（例えば、リソース管理サーバＲＭＳ１）に対して、リソースの確保を要求する要求メッセージを送信するサーバである。
要求メッセージには、少なくとも、要求される通信における着端末の識別子と確保したいリソース量とが含まれており、本実施の形態においては、この識別子として、着側端末のＩＰアドレスを用いるものとする。
【００３３】
なお、図１には、２つのリソース管理サーバＲＭＳ１，ＲＭＳ２と２つの管理範囲（ＮＷ１，ＮＷ２）とが描かれているが、これら以外に通信ネットワークに接続された第３、第４の管理範囲が存在するならば、これら第３，第４の管理範囲に対してそれぞれ第３、第４のリソース管理サーバを設け、これらをリソース管理サーバＲＭＳ１，ＲＭＳ２と接続してもよい。
【００３４】
１−２．  リソース管理サーバ（ＲＭＳ）の構成
各リソース管理サーバＲＭＳ１，ＲＭＳ２は、それぞれ通信機能を有するコンピュータであり、それぞれ送受信部１１，２１と制御部１２，２２とデータベース部１３，２３とを有している。これらの基本的な機能は、各リソース管理サーバに共通しているので、以下に、リソース管理サーバＲＭＳ１を例に、リソース管理サーバの構成および機能を説明する。
なお、これらの機能は、中央演算装置（ＣＰＵ）や記憶装置（ＲＯＭおよびＲＡＭ等の内部メモリの他、ＨＤＤ等の外部記憶装置を含む）などのコンピュータのハードウェア資源とこのコンピュータにインストールされたコンピュータ・プログラム（ソフトウェア）とが協働することによって実現されるものである。
【００３５】
図２は、リソース管理サーバＲＭＳ１の機能ブロック図である。
リソース管理サーバＲＭＳ１において、送受信部１１は、通信インターフェースを備え、各種メッセージを送信および受信する。
この送受信部１１は、アプリケーションサーバＡＳ１や他のリソース管理サーバから送信されてきた要求メッセージを受信する第１の受信部として作用するほか、後述するように、要求メッセージを隣接する他のリソース管理サーバ（例えば、リソース管理サーバＲＭＳ２）に送信する第１の送信部としても作用する。
また、後述するように、リソース管理サーバＲＭＳ間で応答メッセージをやり取りする場合には、この送受信部１１は、後述する応答メッセージおよびキャンセルメッセージを受信する第２の受信部およびこれらのメッセージを送信する第２の送信部としても作用する。
【００３６】
制御部１２は、受信した要求メッセージに応じた処理をリソース管理サーバＲＭＳ１に行わせる制御部であり、具体的には、図２に示すように、メッセージ解析部１２１と判定部１２２と管理部１２３とメッセージ作成部１２４とから構成される。
ここで、メッセージ解析部１２１は、送受信部１１で受信した各種メッセージを分析する機能を備えており、例えば、受信メッセージに含まれる着側端末のＩＰアドレスは、このメッセージ解析部１２１において識別される。また、このメッセージ解析部１２１は、後述するメッセージの送信元の識別子やリソースＩＤ等を抽出する。
【００３７】
判定部１２２は、データベース部１３（より具体的には、後述するアドレスリスト１３１）を参照して、受信した要求メッセージに含まれたＩＰアドレスに対応する着端末がリソース管理サーバＲＭＳ１の管理範囲内にあるか否かを判定する第１の判定部として作用する。
【００３８】
管理部１２３は、データベース部１３（より具体的には、後述する経路情報１３２および管理テーブル１３３）とともに、必要なリソースを確保する第１の管理部としての機能の他、受信した各種メッセージから抽出された各種ＩＤを記憶、管理する第２の管理部としての機能を有するとともに、要求メッセージの送信先から応答メッセージを受信したか否かを判定する第２の判定部としても作用する。
【００３９】
メッセージ作成部１２４は、判定部１２２による判定の結果、着端末がリソース管理サーバＲＭＳ１の管理範囲内にないと判定されたときは、受信した要求メッセージから隣接する他の管理範囲のリソースを管理する他のリソース管理装置に送信する要求メッセージを作成する機能を有する。また、後述するように、リソース管理サーバＲＭＳ間で応答メッセージをやり取りする場合には、他のリソース管理サーバから応答メッセージを受信したときは、この応答メッセージから、前記要求メッセージの送信元に送信する応答メッセージを作成する一方、判定部１２２において前記着端末が当該リソース管理装置の管理範囲内にあると判定されたときは、前記要求メッセージの送信元に送信する応答メッセージを作成する機能を有する。
したがって、このようなメッセージ作成部１２４は、上述した送受信部１１とともに、第１および第２の送信部を構成する。
【００４０】
データベース部１３は、図２に示すように、アドレスリスト１３１、経路情報１３２、管理テーブル１３３を有する。
ここで、アドレスリスト１３１は、当該リソース管理サーバＲＭＳ１の管理範囲内にある端末Ｔ１１〜Ｔ１４およびゲートウェイＧＷ１１のIＰアドレスのリストである。なお、本実施の形態においては、ユーザネットワークインタフェース（ユーザとの境界点）としてゲートウェイＧＷ１１が存在するため、そのIＰアドレスを上記リストに含むと説明したが、一般的には、ゲートウェイＧＷ１１のIＰアドレスを必ずしも含むとは限らない。
【００４１】
図３は、本実施の形態におけるアドレスリスト１３１のデータ構造の一例を示す図である。ここに示すように、アドレスリスト１３１は、各端末の「端末ＩＰアドレス」と、その端末を収容するエッジノード（例えば、端末Ｔ１１を収容するルータＲ１１）を表す「端末収容エッジノード名」と、その端末収容エッジのＩＰアドレスとから構成されている。したがって、上述した判定部１２２は、受信された要求メッセージに含まれた着端末のＩＰアドレスとこのアドレスリスト１３１の「端末ＩＰアドレス」とを照合することにより、その着端末が当該リソース管理サーバＲＭＳ１の管理範囲内にあるか否かを判定することができる。
【００４２】
また、経路情報１３２は、当該リソース管理サーバＲＭＳ１の管理範囲内にあるリソースから構成される経路（通信路）の一覧（リスト）データベースである。
図４は、本実施の形態における経路情報１３２のデータ構造の一例を示す図である。この例において、発側エッジノードと着側エッジノードとの間の経路を表す経路情報は、その「発側エッジノード識別子（またはＩＰアドレス）」と「着側エッジノード識別子（またはＩＰアドレス）」と、この経路の詳細を示す「リソース詳細」とから構成される。
【００４３】
図４に示すように、各経路には、「経路ＩＤ」が付与されている。この経路ＩＤは、その管理範囲内においてユニークなものであり、したがって、経路ＩＤを参照することによって、経路を構成するノード間のアクセスラインやリンクを列挙しなくても、管理範囲内における特定の経路（リソースの集合）を特定することができる。
【００４４】
また、上記「リソース詳細」には、経路を構成する個々のリソースとして、発側エッジノードと着側エッジノードとの間の経路を構成する個々のノードまたはリンク、例えばアクセスライン（端末とルータまたはレイヤー２スイッチとの間のパス）やアクセス集線ライン（レイヤー２スイッチとルータの間のパス）およびリンク（ルータとルータの間のパス）の一覧が記憶されている。
【００４５】
なお、各リソース管理サーバＲＭＳ１，ＲＭＳ２は、アドレスリスト１３１に基づいて経路を算出する経路算出部（図示せず）を備え、管理範囲内のすべての経路をあらかじめ算出し、各リソース管理サーバＲＭＳ側で経路情報１３２に記憶させておくものとする。
【００４６】
管理テーブル１３３は、受信した要求メッセージとそれに起因するリソース確保の状態を管理するテーブルである。
本実施の形態において、この管理テーブル１３３は、上述した管理部１２３とともに、当該リソース管理装置の管理範囲内にあるリソースの使用状況を管理する（いわゆる「ローカルなリソース管理」）一方、メッセージの送受信に伴う複数の管理範囲にまたがるリソース確保の状況を管理する。
【００４７】
いわゆる「ローカルなリソース管理」については、管理テーブル１３３は、図示はしないが、例えば、経路情報（図４参照）の「経路詳細」に列挙された各リンクについて、そのリンクの発ノード、着ノード、総リソース量（通信容量）、および使用中のリソース量を記憶することにより、当該リソース管理装置の管理範囲内にあるリソースの使用状況を管理する。
【００４８】
一方、複数の管理範囲にまたがるリソース確保の状況の管理については、管理テーブル１３３は、要求メッセージに含まれた情報とその要求メッセージの送信先からの応答の有無およびその内容を管理する。
図５は、複数の管理範囲にまたがるリソース確保の状況の管理に関する、本実施の形態における管理テーブル１３３のデータ構造の一例を示す図である。ここに示すように、管理テーブル１３３は、「リソースＩＤ」と「送信元ＩＤ」と「送信元リソースＩＤ」と「送信中状態」と「タイマ」という項目から構成することができる。
【００４９】
ここで「リソースＩＤ」は、確保要求に応じて当該リソース管理サーバＲＭＳ１の管理範囲内において確保されたリソース（一連の経路）を識別するものである。このリソースＩＤは当該リソース管理サーバＲＭＳ１の管理部１２３によって付与され、確保要求ごとにユニークなものである。
なお、上述した「リソースＩＤ」としては、各リソース管理サーバにおいて独自に生成してもよいが、例えば、アプリケーションサーバＡＳ１や当該要求メッセージを最初に受信したリソース管理サーバＲＭＳ１等の要求元が最初に指定したリソースＩＤを、これを受け取った他のリソース管理サーバＲＭＳ２においても自己のリソースＩＤとして使用するようにしてもよい。また、着端末の識別子（例えば、ＩＰアドレス）をリソースＩＤとして用いるようにしてもよい。
【００５０】
「送信元ＩＤ」は、要求メッセージの送信元、すなわち、当該リソース管理サーバＲＭＳ１に要求メッセージを送信したサーバのＩＤ（識別子）である。この「送信元ＩＤ」は要求メッセージから抽出される。
「送信元リソースＩＤ」は、要求メッセージの送信元となった他のリソース管理サーバにおいて確保されたリソースに付与されたリソースＩＤである。この「送信元リソースＩＤ」も、要求メッセージから抽出される。
「送信中状態」は、要求メッセージを送信したリソース管理サーバＲＭＳ１がその送信先である他のリソース管理サーバ（例えば、ＲＭＳ２）からの応答メッセージを受信したか否かを示す。例えば、要求メッセージを送信したときに、「送信中状態」に値「１」を立て、この要求メッセージに対する応答メッセージを受信したときは値「０」を記憶させるようにできる。
「タイマ」には、要求メッセージを送信したときに始動し、この要求メッセージに対する応答メッセージを受信するまでの時間をカウントするタイマの値を記憶させることができる。
【００５１】
なお、本実施の形態において、上述したデータベース部１３は、リソース管理サーバＲＭＳ１内に設けるものとするが、このデータベース部１３の一部または全部をリソース管理サーバＲＭＳ１とは異なるサーバに置き、両者を通信回線で接続するようにしても良い。
また、リソース管理サーバＲＭＳ１にデータベース部１３を置く場合において、そこに記憶させるデータ、特にアドレスリスト１３１は、当該リソース管理サーバＲＭＳ１の管理範囲内の端末情報みならず、他のリソース管理サーバＲＭＳ２の管理範囲内の端末情報を含むように構成しても良い。
【００５２】
１−３．  リソース管理サーバによるリソースの管理
（１）要求メッセージのメッセージフォーマット
図６Ａおよび図６Ｂは、リソース管理サーバＲＭＳにおいて受信される要求メッセージのメッセージフォーマットの一例を示す図である。
リソースの確保を要求する要求メッセージには、少なくとも次の２つの情報が含まれている。
（ａ）「Ｎｏ．４：ＤｅｓｔｉｎａｔｉｏｎＩＰ」：要求される通信における着端末の識別子を表す。
（ｂ）「Ｎｏ．５：リソース量」：確保したいリソース量（ＢＷ）を表す。
さらに、本実施の形態においては、図６に示すように、要求メッセージには次のものが含まれている。
（ｃ）「Ｎｏ．１：リソース要求元サーバのＩＰ」：当該要求メッセージをリソース管理サーバに渡した要求元サーバ（例えばアプリケーションサーバＡＰ１）の識別子（本実施の形態においては、ＩＰアドレス）を示す。
（ｄ）「Ｎｏ．８：リソース管理サーバＩＤ」（いわゆる「送信元ＩＤ」）：当該要求メッセージを送信したリソース管理サーバの識別子を表す。
（ｅ）「Ｎｏ．７：リソースＩＤ」：当該要求メッセージを送信した送信元リソース管理サーバにおいて確保されたリソースに付与されたリソースＩＤ、すなわち送信元リソースＩＤを表す。
（ｆ）「Ｎｏ．３：リソースの出口ＩＰ」：送信元リソース管理サーバが管理する管理範囲の出口ＩＰを示す。
【００５３】
（２）リソースの確保動作
次に、本実施の形態におけるリソースの確保動作について説明する。
図７は、各リソース管理サーバにおけるリソース確保の手順を表すフローチャートである。このフローチャートに沿って、リソース管理サーバＲＭＳ１の動作は次のように説明することができる。
リソース管理サーバＲＭＳ１は、まず、要求メッセージを受信すると（Ｓ０１：Ｙｅｓ）、その中に含まれる着端末のＩＰアドレス（ＤｅｓｔｉｎａｔｉｏｎＩＰまたはＤＡ）を特定し、データベース部１３のアドレスリストを参照することにより、その着端末がリソース管理サーバＲＭＳ１の管理範囲ＮＷ１内に存在するか否かを判定する（Ｓ０２）。また、要求メッセージから抽出された「送信元ＩＤ」および「送信元リソースＩＤ」を管理テーブル１３３に記憶させる。
【００５４】
（２−ａ）着端末が管理範囲内にある場合
着端末が管理範囲ＮＷ１内にある場合（Ｓ０２：Ｙｅｓ）は、管理部１２３が経路情報１３２と管理テーブル１３３とを参照し、着端末に至る経路と特定し、要求メッセージに含まれた確保したいリソース量（ＢＷ）を満たすリソースを確保する（Ｓ０３）。
このとき、当該経路に含まれるすべてのリンクにおいて上記確保したいリソース量（ＢＷ）以上のリソースが使用可能であれば、必要なリソースを確保したうえで（Ｓ０３）、要求メッセージの送信元を応答メッセージの送信先として特定し（Ｓ０４）、要求メッセージの送信元に対して「確保ＯＫ」の応答メッセージを送信する（Ｓ０５）。
【００５５】
しかしながら、リソース確保の際（Ｓ０３）に、いずれかのリンクにおいて使用可能なリソース量（＝総リソース量―すでに使用中のリソース量）が上記確保したいリソース量（ＢＷ）に満たない場合には、必要なリソースを確保することができないので、要求メッセージの送信元に対して「確保ＮＧ」の応答メッセージを送信する（Ｓ０４，Ｓ０５）。このとき、後述するように、所定のキャンセル処理（Ｓ１４）を行い、要求メッセージの送信元においてすでに確保されているリソースを解放させるようにしてもよい。
【００５６】
（２−ｂ）着端末が管理範囲内にない場合
一方、着端末が管理範囲ＮＷ１内にない場合（Ｓ０２：Ｎｏ）は、タイマを始動させ（Ｓ０６）、管理範囲ＮＷ１内において必要なリソースを確保する（Ｓ０７）とともに、要求メッセージを隣接する他の管理範囲ＮＷ２を管理する他のリソース管理サーバＲＭＳ２に送信する（Ｓ０８）。
【００５７】
ここで、「着端末が管理範囲内にない場合のリソースの確保（Ｓ０７）」とそれに伴う「リソース確保状態の管理」、および「要求メッセージの送信（Ｓ０８）」について詳述する。
（２−ｂ−１）  着端末が管理範囲内にない場合のリソースの確保（Ｓ０７）について
上述した「管理範囲ＮＷ１内において必要なリソース」とは、発端末が管理範囲ＮＷ１内にあるとき（すなわち、要求メッセージがいずれかのアプリケーションサーバから送信されたとき）は、その発端末からその管理範囲ＮＷ１のリソース出口ＩＰ、すなわち、隣接する他の管理範囲ＮＷ２への出口となるルータＲ１３までのリソースである。このようなリソースは、管理部１２３によって経路情報１３２（図４参照）から検索され、管理テーブル１３３を参照することによってその経路に含まれる各リンクの使用状態を知ることができる。
【００５８】
このとき、当該経路に含まれるすべてのリンクにおいて上記確保したいリソース量（ＢＷ）以上のリソースが使用可能であれば、必要なリソースを確保し（Ｓ０７：Ｙｅｓ）、この確保したリソースに対して「リソースＩＤ」（第１のリソースＩＤ）を付与する。しかし、いずれかのリンクにおいて使用可能なリソース量（＝総リソース量―すでに使用中のリソース量）が上記確保したいリソース量（ＢＷ）に満たない場合には（Ｓ０７：Ｎｏ）、要求メッセージの送信元を応答メッセージの送信先として特定し（Ｓ１２）、「確保ＮＧ」の応答メッセージを送信する（Ｓ１３）。
このときもまた、上述した「着端末が管理範囲内にある場合」と同様に、所定のキャンセル処理（Ｓ１４）を行い、要求メッセージの送信元においてすでに確保されているリソースを解放させるようにしてもよい。
【００５９】
（２−ｂ−２）  リソース確保状態の管理について
必要なリソースを確保した場合は、この確保したリソースに対して付与された「リソースＩＤ」と、図６に示す要求メッセージの「Ｎｏ．８：リソース管理サーバＩＤ」に含まれた当該要求メッセージの送信元ＩＤとを、管理テーブル１３３（図５参照）の「リソースＩＤ」と「送信元ＩＤ」とにそれぞれ記憶する。ここで、この送信元ＩＤは、具体的には、要求メッセージの送信元となったサーバ（例えば、アプリケーションサーバＡＳ１または図１には図示しない他のリソース管理サーバ）のＩＰアドレスである。
同様に、図６に示す要求メッセージの「Ｎｏ．７：リソースＩＤ」に含まれた送信元リソースＩＤ（これは当該要求メッセージの送信元サーバにおいて付与されたリソースＩＤ）を、管理テーブル１３３の「送信元リソースＩＤ」（図５参照）に記憶する。
【００６０】
これによって、当該リソース管理サーバＲＭＳ１において付与された「リソースＩＤ」と、要求メッセージから抽出された「送信元ＩＤ」と「送信元リソースＩＤ」とを関連づけて管理することができる。
このように、当該リソース管理サーバにおいて確保したリソースのリソースＩＤをその先のリソース管理サーバにおいて送信元リソースＩＤとして記憶することによって、複数のリソース管理サーバにわたって一連のリソースを確保する際に、いわゆる「リソースＩＤのは鎖」が形成されることになる。
【００６１】
（２−ｂ−３）  要求メッセージの送信（Ｓ０８）について
リソース管理サーバＲＭＳ１は、要求メッセージの「Ｎｏ．８：リソース管理サーバＩＤ」と「Ｎｏ．７：リソースＩＤ」（図６参照）を、それぞれ、送信元となる当該リソース管理サーバＲＭＳ１の識別子（例えばＩＰアドレス）と当該リソース管理サーバＲＭＳ１において確保されたリソースのリソースＩＤとに変更した上で、その要求メッセージを他のリソース管理サーバＲＭＳ２に送信する。隣接するリソース管理サーバが複数存在する場合には、要求メッセージをこれらのリソース管理サーバに同時に送信してもよい。
そして、この要求メッセージを他のリソース管理サーバＲＭＳ２に送信すると、図５に示した管理テーブル１３３の「送信状態」の欄に値「１」を立てる。
【００６２】
１−４．リソース確保要求に対する応答
上述したような要求メッセージを受信した他のリソース管理サーバＲＭＳ２では、リソース管理サーバＲＭＳ１について上述した手順（特に図７に示すＳ０１およびＳ０２）と同様の手順に従い、要求メッセージを処理する。このとき、要求メッセージに含まれた識別子で特定される着側端末が管理範囲ＮＷ２内にある場合には（図７、Ｓ０２：Ｙｅｓ）、リソースを確保を試み（図７、Ｓ０３）、当該要求メッセージの送信元であるリソース管理サーバＲＭＳ１に応答メッセージを送信し（図７、Ｓ０５）、リソース確保の結果（リソースが確保できれば「確保ＯＫ」、確保できなければ「確保ＮＧ」）を知らせる。また、リソースを確保できなかった場合には、「確保ＮＧ」の応答メッセージに代えて、または「確保ＮＧ」の応答メッセージと併せて、要求メッセージの送信元に対して後述するキャンセルメッセージを送信するようにしてもよい。
このとき、リソース管理サーバＲＭＳ２は、応答メッセージまたはキャンセルメッセージの送信先を、要求メッセージの「Ｎｏ．８：リソース管理サーバＩＤ」（図７参照）に含まれた送信元ＩＤによって特定することができる。
【００６３】
（１）応答メッセージおよびキャンセルメッセージのメッセージフォーマット
応答メッセージおよびキャンセルメッセージのメッセージフォーマット（データ構造）は、基本的には、図６Ａに示した要求メッセージと共通するが、「メッセージコードＮｏ」のフィールドに、それぞれ「応答メッセージ」および「キャンセルメッセージ」を表す値が入ることと、「コード番号」以下のフィールドに挿入されるデータの内容が、図８に示すフォーマットとなる点で若干相違する。
【００６４】
図８は、本実施の形態における応答メッセージおよびキャンセルメッセージのメッセージフォーマットの一例を示す図である。ここで図８Ａは、リソース確保に成功した場合（「確保ＯＫ」）の応答メッセージ、図８Ｂは、リソース確保に失敗した場合（「確保ＮＧ」）の応答メッセージ、図８Ｃは、キャンセルメッセージにそれぞれ対応する。
本実施の形態において、確保に成功した場合の応答メッセージ（図８Ａ）には、次のものが含まれている。
（ａ）「Ｎｏ．１：リソース要求元サーバのＩＰ」：要求メッセージを最初に発したサーバのＩＰアドレス。本実施の形態においては、例えば、リソース確保要求を最初にリソース管理サーバＲＭＳ１に渡したサーバ（例えばアプリケーションサーバＡＰ１）のＩＰアドレスである。
（ｂ）「Ｎｏ．２：リソースＩＤ」：要求メッセージを当該リソース管理サーバＲＭＳ２に送信した送信元リソース管理サーバＲＭＳ１において確保されたリソースに対して付与されたリソースＩＤ、すなわち「送信元リソースＩＤ」。
（ｃ）「Ｎｏ．３：リソース管理サーバＩＤ」：要求メッセージの送信元のサーバ、すなわち、当該応答メッセージの送信先となるサーバのＩＤ（いわゆる「送信元ＩＤ」）。
【００６５】
また、本実施の形態において、確保に失敗した場合の応答メッセージ（図８Ｂ）には、
「Ｎｏ．１：リソース要求元サーバのＩＰ」（要求メッセージを最初に発したサーバのＩＰアドレス）の他、「Ｎｏ．２：応答メッセージ」（確保ＮＧの理由）および「Ｎｏ．３：輻輳フラグ」が含まれる。さらに、図８Ａと同様に、ここに「送信元ＩＤ」と「送信元リソースＩＤ」とを付加してもよい。
【００６６】
また、キャンセルメッセージ（図８Ｃ）には、次のものが含まれている。
（ａ）「Ｎｏ．１：リソース管理サーバＩＤ」：要求メッセージの送信元のサーバ、すなわち、当該キャンセルメッセージの送信先となるサーバのＩＤ（いわゆる「送信元ＩＤ」）。
（ｂ）「Ｎｏ．２：リソースＩＤ」：要求メッセージを当該リソース管理サーバＲＭＳ２に送信した送信元リソース管理サーバＲＭＳ１において確保されたリソースに対して付与されたリソースＩＤ、すなわち「送信元リソースＩＤ」。
（ｃ）「Ｎｏ．３：キャンセル後のリソース量」
【００６７】
（２）応答メッセージの送信先の特定
次に、上述したような応答メッセージをリソース管理サーバＲＭＳ２から受信したリソース管理サーバＲＭＳ１の動作について説明する。また、キャンセルメッセージの送信先は、大きく分けて要求メッセージの送信元と送信先とがあるが、前者については、応答メッセージの送信先の特定と同様である（なお、キャンセルメッセージを要求メッセージの送信先に送信する場合の処理については、後述することとする。）。
まず、リソース管理サーバＲＭＳ１は、次のようにして応答メッセージの送信先を特定する（図７、Ｓ１０）。
リソース管理サーバＲＭＳ１は、要求メッセージの送信先となった他のリソース管理サーバＲＭＳ２からの応答メッセージを受信すると（Ｓ０９：Ｙｅｓ）、この応答メッセージをメッセージ解析部１２１において解析し、「Ｎｏ．２：リソースＩＤ」に含まれる「送信元リソースＩＤ」を特定する。この応答メッセージから抽出された「送信元リソースＩＤ」は、この応答メッセージを受信したリソース管理サーバＲＭＳ１が、自己の管理範囲内で確保されたリソースに対して割り当てたリソースＩＤである。したがって、リソース管理サーバＲＭＳ１の管理部１２３は、このリソースＩＤをキーにして管理テーブル１３３を参照することにより、この「リソースＩＤ」に関連づけられた「送信元ＩＤ」と「送信元リソースＩＤ」とを取得することができる（図７、Ｓ１０）。このようにして取得された「送信元ＩＤ」によって特定されるサーバは、リソース管理サーバＲＭＳ１にとって、先に受信した要求メッセージの送信元であると同時に、当該応答メッセージの送信先となる。
【００６８】
リソース管理サーバＲＭＳ１は、上述のようにして要求メッセージを送信した送信元サーバを応答メッセージの送信先として特定した後、当該応答メッセージの「Ｎｏ．２：リソースＩＤ」と「Ｎｏ．３：リソース管理サーバＩＤ」とを、それぞれ管理テーブル１３３から読み出された「送信元リソースＩＤ」と「送信元ＩＤ」とに書き換えた後、これを送信する（図７、Ｓ１１）。
また、リソース管理サーバＲＭＳ１は、さらに、上記管理テーブル１３３中の「送信中状態」を「１」から「０」に変更することによって、「確保ＯＫ」の応答を受信した旨を記録して、一連の処理を終了する。
【００６９】
このように自己の管理テーブル１３３に記憶された「送信元リソースＩＤ」を応答メッセージに付加することによって、当該応答メッセージを受信した他のリソース管理サーバがその管理テーブルを参照することによってその応答メッセージに関係するリソースＩＤを一意に特定することができる。したがって、当該他のリソース管理サーバが複数の要求メッセージを送信していた場合であっても、当該応答メッセージの送信先を一意に決定することができる。
【００７０】
一方、タイマを始動させてから所定の時間内に応答メッセージが受信されない場合（図７、Ｓ０９：Ｎｏ）は、要求メッセージの送信元を応答メッセージの送信先として特定し（Ｓ１２）、「確保ＮＧ」の応答メッセージを送信する（Ｓ１３）とともに、後述する所定のキャンセル処理（Ｓ１４）を実行して、少なくとも要求メッセージの送信先にキャンセルメッセージを送信して一連の処理を終了する。
【００７１】
以上の手順により、複数の管理範囲にまたがるリソース確保要求に対して、一連のリソースを確保することができるとともに、一度送信された要求メッセージをキャンセルすることができる。
また、要求メッセージに送信元ＩＤを付加して送信することにより、この要求メッセージに応答するリソース管理サーバでは、送信元ＩＤに基づいて応答メッセージの送信先を効率よく特定することができるので、応答の高速化を図ることができる。
さらに、本実施の形態においては、データベース部１３の管理テーブル１３３において「送信元リソースＩＤ」と「リソースＩＤ」とを対にして管理するとともに、要求メッセージには、送信元ＩＤとともに各管理範囲内において確保されたリソースに付与されたリソースＩＤを送受信し、応答メッセージには、対応する要求メッセージの送信元におけるリソースＩＤ（送信元リソースＩＤ）を付加して送受信している。これによって、いわゆる「リソースＩＤの鎖」をたどることが可能となり、個々の要求メッセージを区別することができる。したがって、同一の送信元リソース管理サーバから複数の要求メッセージを受信していた場合にでも、リソースの確保および応答の並列処理が可能となるという効果が得られる。
【００７２】
なお、本実施の形態においては、要求メッセージに付加された「送信元リソースＩＤ」は、隣接するエリアを管理するリソース管理サーバが独自に割り当てたリソースＩＤとして説明したが、最初に要求メッセージを送信するリソース管理サーバにおいて割り当てたリソースＩＤ（第１のリソースＩＤ）をリソース管理サーバ間で持ちまわるようにしてもよい。すなわち、要求メッセージを最初に送信するリソース管理サーバの管理範囲において確保されたリソースに対して第１のリソースＩＤを割り当てたら、この第１のリソースＩＤを要求メッセージに付加して他のリソース管理装置に送信し、この要求メッセージを受信した当該他のリソース管理サーバにおいては、自己の管理範囲内で確保したリソースに独自に割り当てたリソースＩＤ（第２のリソースＩＤ）に代えて、第１のリソースＩＤを要求メッセージや応答メッセージに付加して送信するようにしてもよい。この場合、例えば、第３番目以降のリソース管理サーバにおいては、「第１のリソースＩＤ」として、最初に要求メッセージを送信したリソース管理サーバにおいて割り当てられたリソースＩＤを管理することとなる。このとき「第１のリソースＩＤ」とともに「第２のリソースＩＤ」として自己が割り当てたリソースＩＤとを管理するようにしてもよい。
【００７３】
また、第１のリソースＩＤとともに、当該要求メッセージを転送するリソース管理サーバの識別子を要求メッセージに付加してもよいが、この第１のリソースＩＤを割り当てた（すなわち当該要求メッセージを最初に送信した）リソース管理サーバの識別子を付加して要求メッセージや応答メッセージを送信するようにしてもよい。
このように要求メッセージを最初に送信するリソース管理サーバにおいて割り当てられたリソースＩＤやこのリソース管理サーバの識別子を要求メッセージに付加することにより、他のリソース管理サーバからの応答を要求メッセージを最初に送信したリソース管理サーバに直接送信することが可能になる。これにより、例えばアプリケーションサーバがリソース管理サーバを選択する必要がなくなるなど、要求の一元管理が可能となり、処理のより一層の効率化を図ることができる。
【００７４】
また、応答メッセージが受信されない場合には、キャンセル処理に移行する前に、要求メッセージを所定回数再送するように構成してもよい。また、上述したように、要求メッセージの送信元に対して、応答メッセージに代えてまたは併せてキャンセルメッセージを送信しても良い。
【００７５】
以上のように、本発明においては、各種メッセージに、（ａ）要求メッセージの送信元（隣接するエリアを管理するリソース管理サーバ）の送信元リソースＩＤと当該リソース管理サーバが割り当てたリソースＩＤとを付加する；（ｂ）要求メッセージを最初に送信するリソース管理サーバが割り当てたリソースＩＤを付加する；（ｃ）要求メッセージを最初に送信するリソース管理サーバが割り当てたリソースＩＤと当該リソース管理サーバが独自に割り当てたリソースＩＤとを付加する、という様々な形態をとることができる。
また、各種メッセージには、（ア）当該メッセージを送信する各リソース管理サーバの識別子や（イ）当該メッセージを最初に送信するリソース管理サーバの識別子などを付加することができる。
【００７６】
１−５．リソース量の変更
複数の管理範囲にまたがって確保された一連のリソースのリソース量は、上述したリソース確保と同様に、要求メッセージをリソース管理サーバ間で送受信することにより実現することができる。リソース量の変更の場合、すでにリソースが確保された一連の経路が特定されている点で上述したリソース確保と異なる。本実施の形態においては、すでに特定されている一連の経路は、リソースＩＤによって特定される。
リソース量の変更は、一連の経路を構成するリンクのすべてにおいて、変更後のリソース量（容量）を払い出すことができるならば、変更は可能（「変更ＯＫ」）であるが、一つのリンクにおいても、要求されたリソース量（容量）を払い出すことができなければ、変更は不可能（「変更ＮＧ」）である。
【００７７】
（１）リソース量の変更要求メッセージのメッセージフォーマット
図９に、リソース量の変更を要求する要求メッセージのメッセージフォーマットの一例を示す。ここに示すように、確保したい変更後のリソース量を表す「Ｎｏ．２：リソース量」と「Ｎｏ．３：リソースＩＤ」（送信元リソースＩＤ）を含む点で、上述したリソース確保要求のメッセージフォーマット（図６参照）と共通する。また、この要求メッセージには、送信元ＩＤを表す「Ｎｏ．４：リソース管理サーバＩＤ」も含まれている。
このような要求メッセージから「Ｎｏ．３：リソースＩＤ」に含まれた「送信元リソースＩＤ」を抽出し、データベース部１３の管理テーブル１３３を参照することにより、各リソース管理サーバは、リソース量の変更の対象となるリソース（一連の経路）を特定することができる。
【００７８】
（２）リソース量の変更の手順
図１０は、リソース量の変更の手順を表すフローチャートである。
まず、リソース管理サーバＲＭＳ１は、リソース量の変更の要求メッセージを受信すると（Ｓ３０）、その要求メッセージによって特定される確保済のリソース（一連の経路）が存在するか否かを確認する（Ｓ３１）。具体的には、管理テーブル１３３を参照し、要求メッセージの「Ｎｏ．３：リソースＩＤ」に記録されている「送信元リソースＩＤ」が自己の管理テーブル１３３（図５参照）に記憶されているか否かを確認する。
【００７９】
確認の結果、リソースがまだ確保されていない（要求メッセージに含まれた送信元リソースＩＤが管理テーブル１３３に記録されていない）場合には（Ｓ３１：Ｎｏ）、当該要求を拒否（Ｒｅｊｅｃｔ）する（Ｓ３７）。
一方、リソース量の変更の対象となるリソース（一連の経路）がすでに確保されている場合には（Ｓ３１：Ｙｅｓ）、隣接するリソース管理サーバＲＭＳ２において一連の経路が確保されているか否かを確認する（Ｓ３２）。この確認は、例えば、管理テーブル１３３の「送信中状態」を参照することによって行うことができる。
【００８０】
隣接するリソース管理サーバＲＭＳ２において一連の経路が確保されていない場合（Ｓ３２：Ｎｏ）は、リソース管理サーバＲＭＳ１の管理範囲内に着信端末が存在すると考えられるので、当該管理範囲内におけるリソースのリソース量の変更を行う（Ｓ３６）。そして、当該要求メッセージの送信元を特定した上で（Ｓ４５）、変更の結果（「変更ＯＫ」または「変更ＮＧ」）を表す応答メッセージを送信する（Ｓ４６）。
【００８１】
これに対し、隣接するリソース管理サーバＲＭＳ２において一連の経路が確保されている場合（Ｓ３２：Ｙｅｓ）は、タイマを起動した上で（Ｓ３３）、当該管理範囲内におけるリソースのリソース量の変更を行う（Ｓ３４）。また、リソース量の変更と並行して当該要求メッセージを隣接するリソース管理サーバＲＭＳ２に送信する（Ｓ３５）。
リソース量の変更処理（Ｓ３４）を行った結果、必要なリソース量が確保できない場合（Ｓ３８：Ｎｏ）、応答メッセージの送信先を特定したうえで（Ｓ４０）、「変更ＮＧ」の応答メッセージを送信し（Ｓ４１）一連の処理を終了する。このとき併せて後述する所定のキャンセル処理を行っても良い（Ｓ４２）。
【００８２】
一方、リソース量の変更処理（Ｓ３４）を行い、必要なリソース量を確保した場合（Ｓ３８：Ｙｅｓ）は、先に転送した要求メッセージ（Ｓ３５）に対する応答メッセージをあらかじめ定められた時間内に受信したか否かを判断する（Ｓ３９）。そして、所定時間内に「変更ＯＫ」を示す応答があった場合（Ｓ３９：Ｙｅｓ）は、管理テーブル１３３を参照することによって応答メッセージの送信先を特定し（Ｓ４３）、「変更ＯＫ」の応答メッセージを送信する（Ｓ４４）。
これに対し、所定時間内に応答がなかった場合、すなわちタイムアウトの場合（Ｓ３９：Ｎｏ）や「変更ＮＧ」の応答メッセージを受信したときは、他のリソース管理サーバＲＭＳ２においてはリソースの確保を行えなかったものとみなし、上述したＳ４０乃至Ｓ４１の処理を実行する。
【００８３】
なお、応答メッセージのメッセージフォーマットおよび応答メッセージの送信先の特定については、上述したリソース確保の要求に対する応答メッセージの場合と基本的に同じである。よって、その説明は省略する。
【００８４】
１−６．リソースの解放
次に、複数の管理範囲にまたがって確保された一連のリソースの解放について説明する。
一連のリソースを解放するときも、上述したリソース確保および変更と同様に、解放の要求メッセージをリソース管理サーバ間で送受信することにより実現することができる。
【００８５】
（１）リソースの解放要求メッセージのメッセージフォーマット
図１１に、リソースの解放を要求する要求メッセージのメッセージフォーマットの一例を示す。ここに示すように、「Ｎｏ．２：リソースＩＤ」や「Ｎｏ．３：リソース管理サーバＩＤ」を有することにより、解放を要求する要求メッセージにおいても「送信元リソースＩＤ」や「送信元ＩＤ」が含まれている点において、上述したリソース量の変更要求のメッセージフォーマット（図９参照）と共通する。
このような要求メッセージを受信したリソース管理サーバＲＭＳ１は、この要求メッセージから抽出された「送信元リソースＩＤ」に基づいて管理テーブル１３３を参照することによって、解放すべきリソースを特定することができる。
【００８６】
（２）リソース解放の手順
図１２は、リソース解放の手順を表すフローチャートである。
まず、リソース管理サーバＲＭＳ１は、リソース解放の要求メッセージを受信すると（Ｓ５０）、自己の管理範囲内にその要求メッセージによって特定される確保済のリソース（一連の経路）が存在するか否かを確認する（Ｓ５１）。具体的には、管理テーブル１３３を参照し、要求メッセージの「Ｎｏ．２：リソースＩＤ」に記録されている「送信元リソースＩＤ」が自己の管理テーブル１３３（図５参照）に記憶されているか否かを確認する。
【００８７】
確認の結果、リソースがまだ確保されていない（要求メッセージに含まれた送信元リソースＩＤが管理テーブル１３３に記録されていない）場合には（Ｓ５１：Ｎｏ）、当該要求を拒否（Ｒｅｊｅｃｔ）する（Ｓ５２）。
一方、自己の管理範囲内において解除の対象となるリソース（一連の経路）がすでに確保されている場合には（Ｓ５１：Ｙｅｓ）、隣接するリソース管理サーバにおいて一連の経路が確保されているか否かを確認する（Ｓ５３）。この確認は、例えば、管理テーブル１３３の「送信中状態」を参照することによって行うことができる。
【００８８】
隣接するリソース管理サーバＲＭＳ２において一連の経路が確保されていない場合（Ｓ５３：Ｎｏ）は、リソース管理サーバＲＭＳ１の管理範囲内に着信端末が存在すると考えられるので、解放可能か否かを確認した後（Ｓ５４）、当該管理範囲内におけるリソースの解放を行い（Ｓ５５）、一連の処理を終了する。
これに対し、隣接するリソース管理サーバＲＭＳ２において一連の経路が確保されている場合（Ｓ５３：Ｙｅｓ）は、自己の管理範囲内で確保されたリソースの解放が可能か否かを確認した後（Ｓ５４）、当該管理範囲内におけるリソースの解放を行う（Ｓ５５）とともに、当該要求メッセージを隣接するリソース管理サーバＲＭＳ２に送信して（Ｓ５６）、一連の処理を終了する。
なお、自己の管理範囲内においてリソースの解放が可能でない場合（Ｓ５４：Ｎｏ）は、「ＮＧログ」を作成した上で（Ｓ５７）一連の処理を終了する。
【００８９】
１−７．キャンセル処理
本実施の形態において、「キャンセル」の主たる意味は、第１には、他のリソース管理サーバＲＭＳ２に送信した要求メッセージをキャンセルし（取り消し）、要求メッセージの送信先（他のリソース管理サーバＲＭＳ２）におけるリソースの確保を差し止めることであり、第２には、要求メッセージの送信先、さらにはその送信元においてすでに確保されているリソースを解放させることである。本実施の形態においては、上記の２つの処理を行うものとして説明するが、本発明においては、いずれか一方のみを行うようにしても良い。
【００９０】
キャンセル処理を行うのは、図７に示すように、所定時間内に応答メッセージを受信できなかった場合（Ｓ０９：Ｎｏ）の他に、他のリソース管理サーバＲＭＳ２からキャンセルメッセージを受信した場合がある。キャンセル処理は、いずれの場合においても、次の２つの手順、すなわち、（１）キャンセルメッセージの送信と（２）確保済みリソースの解放に分けることができる。
【００９１】
（１）キャンセルメッセージの送信
キャンセルメッセージの送信先は、基本的には、要求メッセージ（これは、リソース確保要求メッセージの他、上述した変更要求メッセージ等も含まれる概念である。）の送信先であるが、キャンセルメッセージを受信したことによって行われるキャンセル処理においては、要求メッセージの送信元に対して送信するようにしてもよい。
このとき、リソース管理サーバＲＭＳ１は、自己の管理テーブル１３３を参照することにより、要求メッセージの送信先においてリソースがすでに確保されているか否かを判定することができるので、この判定の結果、要求メッセージの送信先（リソース管理サーバＲＭＳ２）においてリソースが確保されているときだけキャンセルメッセージを送信する（確保されていないときにはキャンセルメッセージを送信しない）ようにしてもよい。すなわち、要求メッセージの送信先（リソース管理サーバＲＭＳ２）において既に確保済みのリソースを解放することを目的とするならば、要求メッセージの送信先においてリソースが確保されていないときにはキャンセルメッセージの送信を見合わせることろによって、ネットワーク上のトラヒックを抑えることが可能となる。
【００９２】
（２）確保済みリソースの解放
リソース管理サーバＲＭＳ１がキャンセルメッセージを送信するときや、他のリソース管理サーバＲＭＳ２からキャンセルメッセージを受信したときに、リソース管理サーバＲＭＳ１においてすでに確保済みのリソースがある場合にはこれを解放する。
このとき、１つのリソース管理サーバＲＭＳ１において確保済みリソースが複数ある場合でも、それらを識別する識別子、例えば、リソース確保要求メッセージに含まれていた着端末の識別子や、アプリケーションサーバＡＳがリソース確保要求ごとに付与したリソースＩＤ、または各リソース管理サーバＲＭＳごとに付与したリソースＩＤ等（これらは要求メッセージの送信元を識別する識別子でもある。）を参照することにより、確保済みのリソースごとに解放を行うことができる。
【００９３】
ここで図１３を参照して、リソース管理サーバＲＭＳ１においてキャンセルメッセージを受信した場合を例に、キャンセル処理の一例を説明すると次のようになる。
まず、リソース管理サーバＲＭＳ１は、キャンセルメッセージを受信すると（Ｓ６１：Ｙｅｓ）、そのキャンセルの対象となる要求メッセージの送信先（リソース管理サーバＲＭＳ２）においてすでにリソースが確保されているか否かを確かめる（Ｓ６２）。その結果、要求メッセージの送信先（リソース管理サーバＲＭＳ２）において既にリソースが確保されているときには（Ｓ６２：Ｙｅｓ）、リソース管理サーバＲＭＳ２に対してキャンセルメッセージを送信し、自己（リソース管理サーバＲＭＳ１）の管理範囲内で確保したリソースを解放または変更する（Ｓ６３）。また、リソース管理サーバＲＭＳ２においてリソースが確保されていないときには（Ｓ６２：Ｎｏ）、キャンセルメッセージをリソース管理サーバＲＭＳ２に送信することなく、自己（リソース管理サーバＲＭＳ１）の管理範囲内で確保したリソースを解放または変更する（Ｓ６３）
【００９４】
以上のように、本実施の形態にかかるリソース管理システムによれば、複数の管理範囲にまたがるリソースの確保、リソース量の変更およびリソースの解放を、要求メッセージを複数のリソース管理サーバ間で送受信することにより、複数の管理範囲にまたがるリソースの確保、変更、解放を実現することができる。
【００９５】
また、複数のリソース管理装置間で応答メッセージを送受信することによって、複数の範囲にまたがるリソース確保の要求およびリソース量の変更の要求に対して、一連のリソースを確保することができたか否かを確認することができる。
さらに、各リソース管理装置によって確保されたリソースを特定する第１のリソースＩＤと、受信した要求メッセージに含まれていた当該要求メッセージの送信元を表す識別子と、その要求メッセージの送信先である他のリソース管理装置からの応答の有無とを関連づけて記憶することによって、複数の管理範囲にまたがるリソース確保要求に対して、複数のリソース管理装置を順番に経由して一連のリソースを確保する途中経過を管理することができる。
【００９６】
また、確保中のリソースを、「リソースＩＤ」によって識別することにより、複数の要求メッセージを並列に処理することも可能となる。
さらに、各リソース管理サーバにおいて付与された「リソースＩＤ」（第１のリソースＩＤ）を「送信元リソースＩＤ」（第２のリソースＩＤ）として要求メッセージに付与して送信するとともに、その要求メッセージを受信したリソース管理サーバにおいて、当該リソース管理サーバにおいて付与されたリソースＩＤ（第１のリソースＩＤ）と、その要求メッセージを送信したサーバのＩＤ（送信元ＩＤ）と「送信元リソースＩＤ」（第２のリソースＩＤ）と、を関連づけて管理することによって、各リソース管理サーバは、応答メッセージを送信すべき（要求メッセージの送信元である）リソース管理装置を特定することができる。したがって、各リソース管理装置で複数の要求メッセージを並列に処理することができる。
【００９７】
また、本発明の他の形態によれば、前記要求メッセージに含まれた着端末の識別子に基づいて解放すべき確保済みリソースを特定することにより、複数のリソースに対して、解放処理を個別または並列に行うことができる。
【００９８】
２．第２の実施の形態
次に本発明の第２の実施の形態について説明する。この第２の実施の形態について、上述した第１の実施の形態と同一の構成については、同一の符号を用いることとし、その説明を省略する。
２−１．  リソース管理システムの概要
第２の実施の形態にかかるリソース管理システムは、要求メッセージに含まれた着端末ＩＤに基づいて要求メッセージを他のリソース管理サーバに送信するか否かを決定する点において、上述した第１の実施の形態にかかるリソース管理システムと共通する。しかしながら、第２の実施の形態においては、要求メッセージに着端末ＩＤに加えて発端末ＩＤが含まれること、およびリソース管理サーバＲＭＳ１，ＲＭＳ２のデータベース部１３の管理テーブル１３３において、「リソースＩＤ」に代えて着端末のＩＤおよび発端末のＩＤの対が記憶されることが、上述した第１の実施の形態と異なる点である。なお、これら発着信端末のＩＤとしては、例えば、着端末および発端末のＩＰアドレスをそれぞれ用いることができる。
【００９９】
２−２．  リソース管理サーバ（ＲＭＳ）の構成
第２の実施の形態におけるリソース管理サーバの基本的な構造は、図２に示す第１の実施の形態にかかるリソース管理サーバと同じである。ただし、管理テーブル１３３のデータ構造が第１の実施の形態とは異なる。
図１４は、この第２の実施の形態における管理テーブル１３３のデータ構造の一例を示す図である。ここに示すとおり、「着端末ＩＤ」および「発端末ＩＤ」が、「送信元ＩＤ」や「送信中状態」等と関連付けられて記憶されている。
【０１００】
２−３．  リソース管理サーバによるリソースの管理
（１）要求メッセージのメッセージフォーマット
第２の実施の形態においては、要求メッセージには、「発端末ＩＤ」および「着端末ＩＤ」が含まれる。第１の実施の形態と異なり、「リソースＩＤ」および「送信元リソースＩＤ」は必須ではない。
【０１０１】
（２）リソースの確保動作
リソースの確保においては、第１の実施の形態と同様に、要求メッセージに含まれた着端末ＩＤが当該要求メッセージを受信したリソース管理サーバＲＭＳ１のアドレスリスト１３１にあるか否かによって、要求メッセージを隣接する他のリソース管理サーバＲＭＳ２に送信するか否かを決定する。
リソースの確保動作自体は、第１の実施の形態と同じであるので、その説明を省略する。
【０１０２】
２−４．リソース確保要求に対する応答
（１）応答メッセージのメッセージフォーマット
第２の実施の形態においては、応答メッセージには、要求メッセージに含まれていた「発端末ＩＤ」および「着端末ＩＤ」が含まれる。第１の実施の形態と異なり、「送信元リソースＩＤ」は必須ではない。
【０１０３】
（２）応答メッセージおよびキャンセルメッセージの送信先の特定
第２の実施の形態においては、図１４に示すように、各リソース管理サーバにおいて「着端末ＩＤ」および「発端末ＩＤ」を「送信元ＩＤ」と関連づけて管理する一方、確保、変更、解放の要求メッセージや応答メッセージ、さらにはキャンセルメッセージにこれらの着端末ＩＤおよび発端末ＩＤを付加して送信する。
【０１０４】
上述した着端末ＩＤおよび発端末ＩＤの組は、要求ごとによって一意に定まり、かつ重複することは少ないと考えられる。したがって、各リソース管理サーバにおいては、受信した応答メッセージに含まれている着端末ＩＤおよび発端末ＩＤの対に基づいて管理テーブル１３３を参照することによって、応答メッセージの送信先、すなわち要求メッセージの送信元を特定することができる。
また、着端末ＩＤおよび発端末ＩＤの対を参照することによって、応答メッセージやキャンセルメッセージが対象とするリソースを一意に特定することができる。よって、複数のメッセージを並列に処理することができる。
【０１０５】
以上のように、第２の実施の形態によれば、各リソース管理サーバにおける並列処理を行うことができる。
【０１０６】
３．第３の実施の形態
３−１．  リソース管理システムの概要
第１の実施の形態においては、リソース管理サーバＲＭＳ１のデータベース部１３のアドレスリスト１３１に、当該リソース管理サーバＲＭＳ１の管理範囲内の端末Ｔ１１〜Ｔ１４（およびゲートウェイＧＷ１１）のＩＰアドレスを記憶させる一方、要求メッセージが、要求される通信における着端末のＩＰアドレスを含むように構成され、この着端末のＩＰアドレスと上記アドレスリスト１３１とを照合することで、その着端末が管理範囲内にあるか否かを判定していた。
これに対し、本発明の第３の実施の形態は、ＩＰアドレスに代えて、各端末のグループを識別子として用いるものである。
ここで「グループ」とは、１または複数の端末の集合である。本実施の形態においては、グループは、１のリソース管理サーバの管理範囲に含まれる端末の集合とするか、その部分集合とすることが望ましい。このようなグループは、例えば、通信ネットワークを構成するルータごとに定義することができる。
なお、この第３の実施の形態について、上述した第１の実施の形態と同一の構成については、同一の符号を用い、その説明を省略することとする。
【０１０７】
３−２．  リソース管理サーバ（ＲＭＳ）の構成
図１５は、第３の実施の形態におけるリソース管理サーバＲＭＳ１の構成の一例を示す図である。すなわち、図２と比較すると明らかなように、この第３の実施の形態においては、リソース管理サーバＲＭＳ１のデータベース部１３は、アドレスリスト１３１に代えて識別子管理テーブル１３４を備えている。
【０１０８】
図１６は、リソース管理サーバＲＭＳ１のデータベース部１３の識別子管理テーブル１３４の構成の一例を示す図である。
この識別子管理テーブル１３４は、「識別子」としてグループが登録されており、各グループを構成する端末のＩＰアドレスが各識別子（すなわちグループ）に対応付けられている。
また、本実施の形態においては、あらかじめ要求メッセージの送信先が同一となるようにグループを構成することによって、各グループごとに要求メッセージの送信先となる他のリソース管理サーバのＩＤと、この他のリソース管理サーバの管理範囲への出口ＩＰとを識別子管理テーブル１３４に登録しておくことが可能となる。
【０１０９】
３−３．  リソース管理サーバによるリソースの管理
グループを要求メッセージに含まれる識別子として使用することにより、リソース管理サーバＲＭＳ１の判定部１２２は、この識別子管理テーブル１３４を参照することによって、当該要求メッセージを送信すべき他のリソース管理サーバを自動的に定めることができる。
また、識別子管理テーブル１３４においてグループごとに記録された出口ＩＰを参照することで、確保すべき管理範囲外のリソースに対する要求先を容易に特定することができる。
このような第３の実施の形態によれば、個々の着端末のＩＰアドレスに基づいて判定する場合に比べて、判定作業の効率化を図ることができ、処理の高速化を図ることが可能となる。
なお、識別子管理テーブル１３４に、出口ＩＰの代わりにリソース管理サーバの識別子と管理範囲またはグループの識別子が記述されている場合も、リソース要求の転送先を容易に特定することができる。
【０１１０】
４．第４の実施の形態
第４の実施の形態は、端末のＩＰアドレスの上位ビットに基づいて管理範囲内か否かを判定する点に特徴を有するリソース管理システムである。
例えばＩＰｖ６アドレスを考えた場合、ＩＰアドレスは単純には１２８ｂｉｔｓの長さを有する。したがって、第１の実施の形態において述べたように、各種識別子としてＩＰアドレスを用いた場合、その長さゆえに、管理範囲内か否かを判定するには、検索対象空間が膨大となり、時間がかかりすぎるおそれがある。
そこで、第４の実施の形態は、着端末の識別子としてＩＰアドレス全体を用いる代わりに、ＩＰアドレスの一部を用いるようにしたものである。これは、ＩＰアドレスの一部分に着目することによって、通信ネットワークをサブネットに分割して管理することができることを利用したものである。
【０１１１】
例えば、通信ネットワークをルータごとに分割し、各端末のＩＰアドレスの上位ビットには、同一のルータに収容される端末のＩＰアドレスの上位ビットには、サブネットアドレスとして同一のビット列を割り当てておく。
ＩＰアドレスからサブネットアドレスを得るには、サブネット・マスクを使用すればよい。
【０１１２】
図１７は、第４の実施の形態におけるリソース管理サーバＲＭＳ１の構成の一例を示す図である。データベース部１３には、サブネットリスト１３５が設けられている。このサブネットリスト１３５には、リソース管理サーバＲＭＳ１の管理範囲内にあるサブネットアドレスがあらかじめ記憶されている。
また、メッセージ解析部１２１においてサブネット・マスク機能を設けることによって、ＩＰアドレスからサブネットアドレスを得ることができる。
判定部１２２は、メッセージ解析部１２１より得られたサブネットアドレスでデータベース部１３のサブネットリスト１３５を検索することによって、着端末がリソース管理サーバＲＭＳ１の管理範囲中に存在するか否かを判定する。
【０１１３】
以上のように、ＩＰアドレスの上位ビットまたはサブネットアドレスを用いることにより、検索範囲を少なくすることができ、判定作業の効率化と処理の高速化を図ることが可能となる。
【０１１４】
５．第５の実施の形態
５−１．リソース管理システムの概要
本発明の第５の実施の形態にかかるリソース管理システムにおいては、リソース管理サーバが、要求メッセージに対して、当該リソース管理装置の管理範囲内におけるリソース確保の結果と、その要求メッセージを送信した他のリソース管理装置からの応答メッセージおよびキャンセルメッセージの受信の有無と、受信した応答メッセージに含まれた他のリソース管理装置におけるリソース確保の結果とを表示する表示部を有する。それ以外の構成および動作は、上述した第１の実施の形態と同様であるので、以下、同一の構成については同一の符号を用い、その説明を省略する。
【０１１５】
５−２．  リソース管理サーバ（ＲＭＳ）の構成
図１８は、第５の実施の形態におけるリソース管理サーバＲＭＳ１の構成を示す図である。ここに示すように、リソース管理サーバＲＭＳ１は、表示部１４を有している。
このリソース管理サーバによる「リソースの管理」および「リソース確保要求に対する応答」の動作ならびに各メッセージフォーマットは、第１の実施の形態と同一とし、その説明は省略する。
【０１１６】
５−３．表示する情報
第５の実施の形態において、リソース管理サーバＲＭＳ１が表示する情報は、次の３項目である。
（ａ）リソース管理装置ＲＭＳ１の管理範囲内におけるリソース確保の状態。
（ｂ）要求メッセージを送信した他のリソース管理サーバからの応答メッセージまたはキャンセルメッセージの受信の有無。
（ｃ）他のリソース管理装置におけるリソース確保の結果。
本実施の形態においては、上記（ａ）に関しては、「自リソース確保処理中」、「自リソース確保ＯＫ」、「自リソース確保ＮＧ」の３つの状態がある。また、上記（ｂ）および（ｃ）に関しては、あわせて、「中継リソース確保処理中」、「中継リソース確保処理結果ＯＫ」、「中継リソース確保処理結果ＮＧ」の３つの状態がある。
【０１１７】
５−４．表示動作
次に図１８と、図５に示す管理テーブル１３３のデータ構造および図７に示すリソース確保の手順を表すフローチャートとを参照して、表示動作について説明する。
上記（ａ）（リソース管理装置ＲＭＳ１の管理範囲内におけるリソース確保の状態）については、リソース確保の要求メッセージを受信すると（Ｓ０１：Ｙｅｓ）、管理部１２３は、表示部１４に「自リソース確保処理中」を表示させる。そして、当該要求メッセージに対するリソース確保の処理（Ｓ０３またはＳ０７）が終了すると、その結果に応じて「自リソース確保ＯＫ」または「自リソース確保ＮＧ」を表示させる。
【０１１８】
一方、上記（ｂ）および（ｃ）（要求メッセージを送信した他のリソース管理サーバからの応答メッセージまたはキャンセルメッセージの受信の有無とその結果）については、次のようにして表示を行う。
当該リソース管理サーバが他の隣接するリソース管理サーバに要求メッセージを送信すると（Ｓ０８）、管理テーブル１３３の「送信中状態」には値「１」が立てられ、この要求メッセージに対する応答メッセージまたはキャンセルメッセージを受信すると（Ｓ０９：Ｙｅｓ）、値「０」が立てられる。
したがって、管理部１２３は、この「送信中状態」に値「１」が立てられると、表示部１４には、「中継リソース確保処理中」を表示させる。また、値「０」が立てられたときには、応答メッセージの内容に応じて、「確保ＯＫ」の場合には「中継リソース確保処理結果ＯＫ」を、「確保ＮＧ」のときには「中継リソース確保処理結果ＮＧ」を表示部１４に表示させることができる。また、キャンセルメッセージを受信したときには、要求メッセージがキャンセルされたことを表示する。
なお、本実施の形態においては、所定の時間内に応答が得られなかった場合（Ｓ０９：Ｎｏ）には、「中継リソース確保処理結果ＮＧ」を表示させる。
【０１１９】
以上のように、本実施の形態にかかるリソース管理システムにおいては、任意のリソース管理サーバにおいて、リソース確保の要求に対する当該リソース管理サーバの管理範囲内におけるリソース確保の状態と他のリソース管理サーバの管理範囲におけるリソース確保の状態とを知ることができる。
【産業上の利用可能性】
【０１２０】
本発明は、広域通信ネットワークを利用した高品質の通信サービスに利用することができる。
【図面の簡単な説明】
【０１２１】
【図１】本発明の第１の実施の形態にかかるリソース管理システムの概要を説明する図である。
【図２】本発明の第１の実施の形態におけるリソース管理サーバＲＭＳ１の機能ブロック図である。
【図３】本発明の第１の実施の形態におけるアドレスリストのデータ構造の一例を示す図である。
【図４】本発明の第１の実施の形態における経路情報のデータ構造の一例を示す図である。
【図５】本発明の第１の実施の形態における管理テーブルのデータ構造の一例を示す図である。
【図６Ａ】本発明の第１の実施の形態において使用される要求メッセージのメッセージフォーマットの一例を示す図である。
【図６Ｂ】本発明の第１の実施の形態において使用される要求メッセージのメッセージフォーマットの一例を示す図である。
【図７】本発明の第１の実施の形態におけるリソース確保の手順を表すフローチャートである。
【図８Ａ】本発明の第１の実施の形態における応答メッセージ（確保ＯＫ）のメッセージフォーマットの一例を示す図である。
【図８Ｂ】本発明の第１の実施の形態における応答メッセージ（確保ＮＧ）のメッセージフォーマットの一例を示す図である。
【図８Ｃ】本発明の第１の実施の形態におけるキャンセルメッセージのメッセージフォーマットの一例を示す図である。
【図９】本発明の第１の実施の形態において使用されるリソース量の変更を要求する要求メッセージのメッセージフォーマットの一例を示す図である。
【図１０】本発明の第１の実施の形態におけるリソース量の変更の手順を表すフローチャートである。
【図１１】本発明の第１の実施の形態において使用されるリソースの解放を要求する要求メッセージのメッセージフォーマットの一例を示す図である。
【図１２】本発明の第１の実施の形態におけるリソースの解放の手順を表すフローチャートである。
【図１３】本発明の第１の実施の形態におけるキャンセル処理の手順の一例を表すフローチャートである。
【図１４】本発明の第２の実施の形態における管理テーブルのデータ構造の一例を示す図である。
【図１５】本発明の第３の実施の形態におけるリソース管理サーバの構成の一例を示す図である。
【図１６】本発明の第３の実施の形態における識別子管理テーブルの構成の一例を示す図である。
【図１７】本発明の第４の実施の形態におけるリソース管理サーバの構成の一例を示す図である。
【図１８】本発明の第５の実施の形態におけるリソース管理サーバの構成の一例を示す図である。
【符号の説明】
【０１２２】
１１，２１…送受信部、１２，２２…制御部、１２１…メッセージ解析部、１２２…判定部、１２３…リソース管理部、１２４…メッセージ作成部、１３，２３…データベース部、１３１…アドレスリスト、１３２…経路情報、１３３…管理テーブル、１３４…識別子管理テーブル、１３５…サブネットリスト、１４…表示部、ＡＬ１１〜ＡＬ２５…アクセスライン、ＡＬＣ１１〜ＡＬＣ２２…アクセス集線ライン、ＡＳ１，ＡＳ２…アプリケーションサーバ、ＧＷ１１，ＧＷ２１…ゲートウェイ、ＮＷ１，ＮＷ２…管理範囲（通信ネットワーク）、Ｒ１１〜Ｒ２３…ルータ、ＲＭＳ１，ＲＭＳ２…リソース管理サーバ、ＳＷ１，ＳＷ２…レイヤー２スイッチ、Ｔ１１〜Ｔ２６…端末。
【図１】
2006287850.tif 000003
【図２】
2006287850.tif 000004
【図３】
2006287850.tif 000005
【図４】
2006287850.tif 000006
【図５】
2006287850.tif 000007
【図６Ａ】
2006287850.tif 000008
【図６Ｂ】
2006287850.tif 000009
【図７】
2006287850.tif 000010
【図８Ａ】
2006287850.tif 000011
【図８Ｂ】
2006287850.tif 000012
【図８Ｃ】
2006287850.tif 000013
【図９】
2006287850.tif 000014
【図１０】
2006287850.tif 000015
【図１１】
2006287850.tif 000016
【図１２】
2006287850.tif 000017
【図１３】
2006287850.tif 000018
【図１４】
2006287850.tif 000019
【図１５】
2006287850.tif 000020
【図１６】
2006287850.tif 000021
【図１７】
2006287850.tif 000022
【図１８】
2006287850.tif 000023