JP4901231B2 - リソース管理装置 - Google Patents

Description

本発明は、通信ネットワークのリソース管理とログファイルの管理を行うリソース管理装置に関する。

通信ネットワーク、特にＩＰ（Internet Protocol）ネットワークを利用して音声や映像等のコンテンツを提供する場合、通信路の容量を超えた利用要求によって輻輳が発生すると、パケットの損失等に伴い通信品質が劣化してしまう。従来より、このような通信品質の劣化を防ぐことを目的として、リソース管理装置（リソース管理サーバ）によるネットワークレイヤにおけるリソース管理が研究されている。

リソース管理装置によるリソース管理は、通信ネットワークを構成するルータとは独立したサーバ（リソース管理装置）により、通信ネットワークを構成するノード間（リンク）の伝送容量とその利用状況を管理するとともに、ユーザ端末等からのリソース確保要求に対して適当なリソースを払い出すものである。

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

通信ネットワークが運用を開始した後では、リソース管理サーバは、通信サービスの利用要求（リソース確保要求）を受け付けると、要求された通信の発着ＩＰアドレスを基に上記経路テーブルから当該通信に必要となるリンクを特定し、上記リソース管理テーブルを参照することによって、これらのリンクの各々について当該通信に必要となる伝送容量（リソース）が利用可能か否かをチェックする。

十分なリソースが利用可能である場合には、上記通信サービスの利用要求に対して許諾応答するとともに、上記リソース管理テーブルの利用中リソース容量に当該通信に割り当てられるリソース量を加算して記憶させる。一方、必要なリソースを確保できない場合には、上記利用要求に対して不許可（不可）とする（特許文献１及び非特許文献１参照）。この方法では、通信用に確保していたリソースは、リソースの使用終了時に速やかに解放している。

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

ところで、上述したリソースの確保動作などは、リソース管理装置に高い負荷をかけることになるが、リソース確保動作の増加によりこの負荷が増加することで、リソース管理装置が輻輳状態となる。この輻輳状態となると、リソースの確保動作が行えなくなるなど障害が発生する。このため、リソース管理装置では、自身の輻輳状態を判断するようにしている。しかしながら、従来の技術では、リソースを確保する動作の中で、自装置の負荷の状態を判定することで輻輳の判定を行っていたので、輻輳の判定事態に処理負荷がかかり、また、輻輳の判定が得られるまでに時間を要するという問題があった。

本発明は、以上のような問題点を解消するためになされたものであり、より少ない負荷でより迅速に輻輳状態の判定が行えるようにすることを目的とする。

本発明に係るリソース管理装置は、互いにリンクされた複数のルータと端末とから構成される通信ネットワークのリソースを管理するリソース管理装置であって、要求される通信における確保したいリソース量を少なくとも含むリソース確保要求を受け付けて必要なリソースを確保するリソース管理手段と、受け付けられたリソース確保要求の数が予め設定されている輻輳判定閾値以上のときに輻輳状態と判定する輻輳判定手段とを少なくとも備え、リソース管理手段は、輻輳判定手段による輻輳状態の判定によりリソース管理装置が輻輳状態であると判断し、リソース解放要求以外のリソース確保要求を含めた他の要求の受け付けを破棄するようにしたものである。

上記リソース管理装置において、輻輳判定手段は、輻輳状態の判定に加え、受け付けられたリソース確保要求の数が、予め設定されている輻輳ピーク判定閾値以上のときに輻輳ピーク状態と判定し、リソース管理手段は、輻輳判定手段による輻輳ピーク状態の判定によりリソース管理装置が輻輳ピーク状態であると判断し、リソース管理装置が受け付けたすべての要求を破棄するようにしてもよい。また、輻輳判定手段は、輻輳状態の判定に加え、受け付けられたリソース確保要求の数が、輻輳判定閾値より少ない予め設定されている非輻輳判定閾値未満のときに非輻輳状態と判定し、リソース管理手段は、輻輳判定手段による非輻輳状態の判定により、リソース管理装置が輻輳状態ではないと判断するようにしてもよい。

以上説明したように、本発明によれば、輻輳判定手段により、受け付けられたリソース確保要求の数が予め設定されている輻輳判定閾値以上のときに輻輳状態と判定するようにしたので、より少ない負荷でより迅速に輻輳の判定が行えるという優れた効果が得られる。

以下、本発明の実施の形態について図を参照して説明する。図１は、本発明の実施の形態におけるリソース管理装置を用いたリソース管理システムの構成例を示す構成図である。図１に示すリソース管理システムは、通信ネットワーク２００を構成する各管理範囲ネットワーク２０１毎に、リソースを管理するリソース管理サーバ１０１を備えている。各リソース管理サーバ（リソース管理装置）１０１は、管理対象となる管理範囲ネットワーク２０１のリソースを管理している。管理対象となる通信ネットワーク２００は、いわゆるインターネットプロトコル（ＩＰ）に基づく通信ネットワークである。

管理範囲ネットワーク２０１は、例えば、互いに接続（リンク）された複数のルータ２０２，端末（Ｔ）２０３から構成される。また、管理範囲ネットワーク２０１は、複数の端末２０３を集線していずれかのルータ２０２に接続するスイッチングハブ（ＳＷ）２０４及びゲートウエイ装置（ＧＷ）２０５を備えている。このように構成されている管理範囲ネットワーク２０１におけるリソースは、通信を行う二つの端末２０３間の通信経路を構成するための、端末２０３といずれかのルータ２０２との間のアクセスライン及びルータ２０２の間のリンクである。

なお、図１に示すリソース管理システムにおいては、通信ネットワーク２００を複数の管理範囲ネットワーク２０１に分割し、これらの管理範囲に対して各々リソース管理サーバ１０１が設けられている。また、各リソース管理サーバ１０１は、互いに通信可能に接続されている。

また、アプリケーションサーバ（ＡＳ）３０１は、いずれかの端末２０３からの通信要求を受け、当該端末２０３が属する管理範囲ネットワーク２０１のリソースを管理するリソース管理サーバ１０１に要求メッセージを送信する。この要求メッセージには、少なくとも、要求される通信における端末２０３の識別子及び確保したいリソース量が含まれており、図１に示すシステムにおいては、この識別子として、端末２０３のＩＰアドレスが用いられる。

各リソース管理サーバ１０１は、各々通信機能を有するコンピュータであり、各々送受信部１０２，制御部１０３，主記憶部１０４とを有している。また、各リソース管理サーバ１０１は、ログ管理部１０５，ログ記憶部１０６，輻輳判定部１０７，及びログ表示部１０８を備えている。これらの機能は、中央演算装置（ＣＰＵ）や記憶装置（ＲＯＭ及びＲＡＭ等の内部メモリの他、固定ディスク装置等の外部記憶装置を含む）などのコンピュータのハードウェア資源とこのコンピュータにインストールされたコンピュータ・プログラム（ソフトウェア）とが協働することによって実現することができる。

上述したように構成された通信ネットワーク２００において、アプリケーションサーバ３０１により、コンテンツの提供などのサービスを行うことが可能とされている。例えば、いずれかのアプリケーションサーバ３０１が、いずれかの端末Ｔ２０３からのコンテンツ送信の要求を受けると、アプリケーションサーバ３０１は、当該端末Ｔ２０３に対して要求されたコンテンツを送出する。このようなコンテンツの配信において、リソース管理サーバ１０１が、必要となるリソースの管理を行う。

上述の場合、コンテンツ送信の要求を受け付けたアプリケーションサーバ３０１は、要求もとの端末Ｔ２０３が所属する管理範囲ネットワーク２０１を管理するリソース管理サーバ１０１に、上記コンテンツの送出のためのリソースの要求メッセージを送信する。この要求メッセージには、少なくとも、要求される通信における要求もとの端末Ｔ２０３の識別子と、確保したいリソース量とが含まれている。端末Ｔ２０３の識別子としては、例えば、要求もとの端末Ｔ２０３のＩＰアドレスなどを用いることができる。

リソース管理サーバ１０１において、送受信部１０２は、通信インターフェースを備え、各種メッセージを送信及び受信する。送受信部１０２は、アプリケーションサーバ３０１や他のリソース管理サーバ１０１から送信されてきた要求メッセージを受信する。送受信部１０２は、要求メッセージを隣接する他のリソース管理サーバ１０１に送信する。また、送受信部１０２は、リソース管理サーバ１０１間の応答メッセージを送受信する。

制御部１０３は、リソース管理サーバ１０１（送受信部１０２）が受信した要求メッセージに応じた処理を行う。制御部１０３は、受信された各メッセージを分析し、例えば、受信メッセージに含まれる要求もと端末Ｔ２０３のＩＰアドレスを識別する。また、制御部１０３は、識別したＩＰアドレスに対応する端末Ｔ２０３が、自信の管理範囲内であることを、データベースを参照して判定する。

また、制御部１０３は、主記憶部１０４に用意されている経路情報及びリソース管理テーブルを参照し、必要なリソースを確保する。制御部１０３が確保したリソースの状態は、主記憶部１０４の中のリソース管理テーブルで管理される。このとき、制御部１０３は、上述したリソース確保の要求を受け付けると、要求を受け付けたことを示すメッセージを生成する。例えば、制御部１０３は、yyyymmddhhss（日付と時刻）、「受付内容：リソース確保要求」、「リソースＩＤ」、「リソース管理サーバＩＤ」などを含むメッセージを生成する。また、上記メッセージは、要求されたりソース確保の対象となるリンクの情報を含んでいてもよい。生成されたメッセージは、通信ネットワーク２００上に送出される。

より詳細に説明すると、要求メッセージ（リソース確保の要求）を受け付けた制御部１０３は、まず、受け付けた要求に設定されているパラメータの状態などを確認することで、リソース確保の要求の可否を判断する。これらの判断で、要求が受け付けられないとされた場合、制御部１０３は、要求不可を応答する。次に、制御部１０３は、受け付けた要求の送信元が、自身の管理している管理範囲ネットワークに収容されている端末であるかどうかを判定する。要求の送信元が管理範囲ネットワーク内にある場合、制御部１０３は、リソース確保処理を開始する。ただし、リソース確保処理を開始してから、所定時間以内にリソース確保処理が終了しない場合、制御部１０３は、リソースの確保が失敗したものと判断し、要求不可を応答する。

上述のようにして、リソース確保の要求が受け付けられると、制御部１０３は、受け付けた要求のリソース確保処理を開始する。このリソース確保処理で、制御部１０３は、例えば、現在実施されているサービス状態の確認、要求されたリソースが使用されるサービスで用いられるデータの確認、要求されたリソースが使用されるサービスの競合などの状態の確認などを行う。また、制御部１０３は、受け付けた要求に必要なリソースを生成し、要求もとのアプリケーションサーバ３０１にリソースが確保されたことを応答し、生成したリソースを、受け付けた要求により指定された終了時まで使用される対象として設定する。また、制御部１０３は、リソースの生成とともに、必要な帯域を確保する。

なお、制御部１０３は、受け付けた要求の送信元が、自身の管理している管理範囲ネットワークに収容されていない場合など、必要に応じて管理範囲が隣接する他のリソース管理サーバへ、リソース確保要求のメッセージを送信する。このメッセージを受信した他のリソース管理サーバもまた自身の管理範囲内においてリソースを確保し、必要に応じて他のリソース管理サーバへリソース確保要求のメッセージを送信する。例えば、受け付けた要求メッセージに含まれる識別子を元に、例えばコンテンツの配信先の端末Ｔ２０３が、管理範囲外と判定した場合、及び要求されたリソースが自身管理範囲を超えた部分を含んでいるなどの場合、制御部１０３は、隣接する管理範囲ネットワーク２０１を管理するリソース管理サーバ１０１に対し、リソース確保のための要求メッセージを生成する。

次に、ログ管理部１０５は、リソース管理サーバ１０２（送受信部１０２）が受け付けたイベント発生のメッセージ及びリソース管理サーバ１０２におけるイベント発生のメッセージを収集し、新たに発生したメッセージをログ記憶部１０６に記憶されているログファイルに追加して更新する。ログ表示部１０８は、ログ記憶部１０６に記憶されているログファイルを参照し、ログファイル内にあるメッセージを管理者に視認可能な状態に表示する。

上述したことに加え、図１のリソース管理装置によれば、送受信部１０２によりリソース確保の要求が受け付けられると、制御部１０３による前述したリソース確保の要求の可否の判断の前に、輻輳判定部１０７に設定されてる輻輳判定を確認し、この確認結果により、リソース確保の要求の可否を判断するようにした。輻輳判定部１０７の動作について説明すると、輻輳判定部１０７は、受け付けられているリソース確保の要求の数（受付数）が予め設定されている「輻輳判定用の閾値」以上となると、輻輳状態に突入したものと判定し、また、受付数が、予め設定されている「輻輳解除用の閾値」未満となると、輻輳状態が解消したものと判定する。また、輻輳判定部１０７は、受付数が、予め設定されている「輻輳ピーク判定の閾値」以上となると、輻輳状態により受け付けができない状態と判定する。

このような輻輳判定部１０７の判定の結果、輻輳状態と判定されると、制御部１０３は、リソース確保やリソース変更の要求を受け付けず、これらの要求の不可を応答する。なお、この段階では、制御部１０３は、リソース解放の要求は受け付ける。また、輻輳判定部１０７により、輻輳状態により受け付けができないと判定されると、制御部１０３は、リソース確保やリソース変更の要求に加えてリソース解放の要求を含めたすべての要求を受け付けず、要求不可を応答する。一方、輻輳判定部１０７により、輻輳状態ではないと判定されると、リソース確保などの各要求を受け付ける。このように、制御部１０３は、前述したリソース確保要求の可否判断や、要求種別・リソース種別を判断するなどのリソース確保処理を行う前に、輻輳判断が行えるようになる。

リソース管理装置１０１（制御部１０３）では、前述したように複数ステップの処理によりリソース確保を行うため、リソース確保の処理のために高い負荷がかかり、この負荷の増加により輻輳状態が引き起こされる。このため、従来では、リソース確保（管理）の処理能力（処理状態）により、輻輳の判定を行うようにしている。しかしながら、このような輻輳の判定では、輻輳判定の処理自体に負荷がかかり、また、輻輳判定の結果が得られるまでに、多くの処理ステップが必要となり、無駄が多い。

これに対し、上述した輻輳判定部１０７の輻輳判定によれば、制御部１０３によるリソース確保の処理が行われる前に、輻輳の判定が行えるので、処理の無駄が省けるようになる。また、上述した輻輳判定部１０７の輻輳判定によれば、輻輳の判定のために処理の負荷が増えることがないので、輻輳の判定がより高速に行えるようになり、リソース管理装置全体の性能の向上が図れるようになる。

また、輻輳判定部１０７は、判定結果のメッセージをログとして出力するので、輻輳状態であることが、ログ表示部１０８に表示されるようになり、管理者に認識可能な状態となる。このように、図１に示すリソース管理装置によれば、輻輳状態であることが、管理者に容易に認知されるようになり、ネットワークにおけるリソース不足の状態が、管理者に容易に把握できるようになる。この結果、管理者は、リソースの増設契機を容易に判断できるようになる。

以下、図１に示すリソース管理装置の輻輳判定部１０７の動作例について図２のフローチャートを用いて説明する。例えば、制御部１０３によりリソース確保の要求が受け付けられ、リソース確保の要求の受付数が増加する。また、制御部１０３により、確保されていたりソースが解放されると、リソース確保の要求の受付数が減少する。これらのリソース確保の要求数は、例えば受信キューとして制御部１０３に記憶されている。

輻輳判定部１０７は、例えば上記受信キューを監視し、リソース確保の要求が受け付けられている受付数の変化を検出すると（ステップＳ２０１）、現状の要求の受付数を確認し、受け付けられているリソース確保の要求の数（受付数）が予め設定されている「輻輳ピーク判定の閾値」以上の場合（ステップＳ２０２）、リソース管理サーバ１０１がすべての要求の受け付けができない状態であることを示す受付不能判定を設定し、また、輻輳がピーク状態であることを示すメッセージを出力する（ステップＳ２０３）。判定の設定は、例えば、輻輳判定部１０７にフラグとして記憶される。

次に、ステップＳ２０２で、受付数が「輻輳ピーク判定の閾値」未満との判定された場合、輻輳判定部１０７は、受付数が予め設定されている「輻輳判定用の閾値」以上であることを検出すると（ステップＳ２０４）、リソース管理サーバ１０１が輻輳状態であることを示す輻輳状態判定を設定し、また、輻輳状態であることを示すメッセージを出力する（ステップＳ２０５）。

次に、ステップＳ２０４の判断で、受付数が「輻輳判定用の閾値」未満との判定された場合、輻輳判定部１０７は、受付数が予め設定されている「輻輳解除用の閾値」以上であることを検出すると（ステップＳ２０６）、この場合も、リソース管理サーバ１０１が輻輳状態であることを示す輻輳状態判定を設定し、また、輻輳状態であることを示すメッセージを出力する（ステップＳ２０５）。一方、ステップＳ２０４の判断で、受付数が「輻輳解除用の閾値」未満との判定された場合、輻輳判定部１０７は、リソース管理サーバ１０１が輻輳状態ではないことを示す非輻輳状態判定を設定し、加えて、輻輳状態は解消されていることを示すメッセージを出力する（ステップＳ２０７）。また、上述した、各判定の設定は、受付数が変化するまで保持される。

上述したように、輻輳判定部１０７より各判定が出力されている中で、送受信部１０２に、例えばリソース確保の要求が受け付けられると、制御部１０３は、まず、輻輳判定部１０７に設定されている判定を確認する。この確認で、受付不能判定の出力を検出した制御部１０３では、受付不能状態であることを示すメッセージを出力し、また、リソース確保要求に加えてリソース解放の要求などのすべての要求の受け付けを破棄し、受付不可のメッセージを応答（出力）する。

また、上記確認で、輻輳状態判定の設定を検出した制御部１０３では、リソース解放の要求以外の他の要求の受け付けを破棄し、受け付けが不可であることを要求もとに応答する。また、上記確認で、非輻輳状態判定の設定を検出した制御部１０３では、すべての要求を受け付け、リソース確保処理などの所定の処理を行う。また、ログ表示部１０８は、まず、ログ記憶部１０６に記憶されているログファイルの増加を検出すると、ログファイルを参照する。ログ記憶部１０６は、予め設定されている時間間隔で、ログファイルの増加を検出する。ついで、ログ表示部１０８は、ログファイル内にあるメッセージを保守管理者に視認可能な状態に表示する。

例えば、ログ表示部１０８は、図１には示していないモニターを備え、このモニターに上記メッセージの表示を行う。従って、輻輳判定部１０７より出力されてログに格納された前述のメッセージが、モニターに表示されることになる。このように、モニターに輻輳発生の状態を示すメッセージが表示されれば、保守管理者にとって、リソース確保要求が多発している状態が容易に識別（認識）されるようになる。

なお、上述では、受け付けられているリソース確保の要求の数（要求数）が変化したときに、輻輳の状態を判定するようにしたが、これに限るものではない。例えば、５分間隔など、予め設定されている間隔で、輻輳の状態を判定するようにしてもよい。また、上述では、輻輳判定部１０７により、輻輳の状態の判定を行うようにしたが、これに限るものではなく、計数されているリソース確保の要求数をもとに、制御部１０３で輻輳の状態を判定してもよい。

ところで、次に示すように、新たにログファイル制御部を追加し、ログ記憶部１０６に記憶されるログファイルを制御して管理するようにしてもよい。まず、ログ管理部１０５は、例えばファイル名が「ｌｏｇ」とされているログファイルのみに検出したメッセージを追加する。また、ログ管理部１０５は、ロブ記憶部１０６内に、ファイル名が「ｌｏｇ」とされているログファイルが存在しない場合、ファイル名を「ｌｏｇ」としたログファイルを新規に生成し、検出したメッセージを追加する。このようにログ管理部１０５がロギングしている状態で、輻輳判定部１０７によりログファイルの容量が規定値以上となったことが検出されると、ログファイル制御部が、ログファイルのファイル名を「ｌｏｇ．０」に変更した待避ログファイルを生成する。このようにすることで、１つのログファイルの容量の増大が抑制されるようになり、表示されるログファイルの内容が、確認しやすくなる。

このようにログファイルを制御している場合、ログファイル制御部が、ファイル名「ｌｏｇ」のログファイルの容量が規定値以上となると、このログファイルに、例えば「log change」などの変更を示す識別情報を追加し、この後、ログファイルのファイル名を「ｌｏｇ．０」に変更した待避ログファイルを生成してもよい。ログ表示部１０８は、ファイル名が「ｌｏｇ」のログファイルを参照し、参照しているログファイルのメッセージを表示出力している。このため、前述したように、参照しているファイルのファイル名が「ｌｏｇ．０」に変更されると、メッセージの表示出力を行う対象のファイルがないため、表示が不可能となる。この場合、ログ表示部１０８は、ファイル名「ｌｏｇ」のログファイルを再参照することで、ファイル名が「ｌｏｇ」のログファイルのメッセージを表示が可能となる。しかしながら、ログ表示部１０８は、自動的には再参照を行えない。ここで、ログ表示部１０８が、現在参照しているログファイル内に「log change」が検出されると再参照を行うようにすれば、新たに生成されたファイル名「ｌｏｇ」のログファイルの参照が可能となる。

また、ログファイル制御部により、特定のファイル名のログファイルのファイル名に０から始まる整数の数字を付加して新たなファイル名に変更した待避ログファイルを生成し、輻輳判定部１０７の監視により、ファイル名「ｌｏｇ」のログファイルの容量が規定値以上となる毎に、すでに存在している待避ログファイルのファイル名に付加されている数字を増加された数字に変更してもよい。例えば、１つめの待避ファイルが生成されるときは、ファイル名「ｌｏｇ」のログファイルをファイル名「ｌｏｇ．０」に変更して第１待避ログファイルを生成する。次に、２つめの待避ファイルが生成される段階では、この時点におけるファイル名「ｌｏｇ」のログファイルをファイル名「ｌｏｇ．０」に変更して第２待避ログファイルを生成し、かつ、第１待避ログファイルのファイル名を「ｌｏｇ．１」に変更する。

次に、３つめの待避ファイルが生成される段階では、この時点におけるファイル名「ｌｏｇ」のログファイルをファイル名「ｌｏｇ．０」に変更して第３待避ログファイルを生成し、かつ、第１待避ログファイルのファイル名を「ｌｏｇ．２」に変更し、第２待避ログファイルのファイル名を「ｌｏｇ．１」に変更する。次に、４つめの待避ファイルが生成される段階では、この時点におけるファイル名「ｌｏｇ」のログファイルをファイル名「ｌｏｇ．０」に変更して第４待避ログファイルを生成し、かつ、第１待避ログファイルのファイル名を「ｌｏｇ．３」に変更し、第２待避ログファイルのファイル名を「ｌｏｇ．２」に変更し、第３待避ログファイルのファイル名を「ｌｏｇ．１」に変更する。

このようにすることで、複数生成される待避ログファイルが管理が容易となる。例えば、ファイル名に付加されている数字により、待避ログファイルの新旧が容易に判断可能となる。この場合、ログ表示部１０８は、待避ログファイルのタイムスタンプを確認することなどにより待避ログファイルが更新されたことを検出し、新規にログファイルの参照を行うようにすればよい。

ところで、リソース管理サーバ１０１は、各々自身を識別するための識別情報や、自身の管理範囲を識別するための識別情報などを備えている。例えば、リソース管理サーバ１０１には、ＩＰアドレスとともに局名，識別子の組が識別情報として与えられている。これらは、参照テーブルとして備えられている。ログ表示部１０８により局名「東京」が選択されると、参照テーブルが参照され、ログ表示部１０８は、「東京」と組にされているＩＰアドレス「１９２．１６８．０．５」に対応するリソース管理サーバ１０１のログ記憶部１０６に格納されているログファイルを参照可能となる。

本発明の実施の形態におけるリソース管理装置を用いたリソース管理システムの構成例を示す構成図である。 図１に示すリソース管理装置１０１における輻輳判定部１０７の動作例を説明するフローチャートである。

符号の説明

１０１…リソース管理サーバ、１０２…送受信部、１０３…制御部、１０４…主記憶部、１０５…ログ管理部、１０６…ログ記憶部、１０７…輻輳判定部１０７、１０８…ログ表示部、２００…通信ネットワーク、２０１…管理範囲ネットワーク、２０２…ルータ、２０３…端末（Ｔ）、２０４…スイッチングハブ（ＳＷ）、２０５…ゲートウエイ装置（ＧＷ）、３０１…アプリケーションサーバ（ＡＳ）。

Claims (3)

1. 互いにリンクされた複数のルータと端末とから構成される通信ネットワークのリソースを管理するリソース管理装置であって、
   要求される通信における確保したいリソース量を少なくとも含むリソース確保要求を受け付けて必要なリソースを確保するリソース管理手段と、
   受け付けられた前記リソース確保要求の数が予め設定されている輻輳判定閾値以上のときに輻輳状態と判定する輻輳判定手段と
   を少なくとも備え、
   前記リソース管理手段は、前記輻輳判定手段による前記輻輳状態の判定により前記リソース管理装置が輻輳状態であると判断し、リソース解放要求は受け付けて、リソース解放要求以外の前記リソース確保要求を含めた他の要求の受け付けを破棄する
   ことを特徴とするリソース管理装置。
2. 請求項１記載のリソース管理装置において、
   前記輻輳判定手段は、前記輻輳状態の判定に加え、受け付けられた前記リソース確保要求の数が、予め設定されている輻輳ピーク判定閾値以上のときに輻輳ピーク状態と判定し、
   前記リソース管理手段は、前記輻輳判定手段による前記輻輳ピーク状態の判定により前記リソース管理装置が輻輳ピーク状態であると判断し、前記リソース管理装置が受け付けたすべての要求を破棄する
   ことを特徴とするリソース管理装置。
3. 請求項１又は２記載のリソース管理装置において、
   前記輻輳判定手段は、前記輻輳状態の判定に加え、受け付けられた前記リソース確保要求の数が、前記輻輳判定閾値より少ない予め設定されている非輻輳判定閾値未満のときに非輻輳状態と判定し、
   前記リソース管理手段は、前記輻輳判定手段による前記非輻輳状態の判定により、前記リソース管理装置が輻輳状態ではないと判断する
   ことを特徴とするリソース管理装置。
   
   

Images