(57)【特許請求の範囲】
【請求項１】
通信ネットワークのリソースに関する処理を要求する要求メッセージを受信したときに前記要求メッセージに付加されたサービス種別を含む付加情報を取得するステップと、
要求メッセージに関する前記付加情報に応じた優先度を記憶する優先度記憶手段から、取得された前記付加情報に対応する優先度を読み出すステップと、
受付番号が付与された要求メッセージの待ち行列を管理し、この待ち行列に属する最後の要求メッセージの受付番号である最終受付番号に、読み出された前記優先度の値を加算した値を、前記受信された要求メッセージの受付番号に決定するステップと、
前記受付番号の順に前記受信された要求メッセージに応じた処理を行うステップと、
を備えることを特徴とするリソース管理方法。
【請求項２】
請求項１に記載のリソース管理方法において、
前記優先度を読み出すステップは、前記受信された要求メッセージから前記付加情報が複数取得されたときに、取得された前記付加情報ごとに前記優先度を読み出し、
前記受付番号を決定するステップは、前記待ち行列を前記付加情報ごとに管理し、取得された前記付加情報のそれぞれの待ち行列の最終受付番号と前記付加情報のそれぞれに対応する前記優先度とを加算した値の合計を前記受信された要求メッセージの受付番号に決定する
ことを特徴とするリソース管理方法。
【請求項３】
請求項１に記載のリソース管理方法において、
前記受付番号を決定するステップは、前記待ち行列を前記付加情報の内容に基づく条件ごとに管理し、前記待ち行列に属する要求メッセージの処理が開始されるときに、前記要求メッセージを前記待ち行列から削除する
ことを特徴とするリソース管理方法。
【請求項４】
請求項３に記載のリソース管理方法において、
前記受付番号を決定するステップは、空の待ち行列の最終受付番号を、他の待ち行列に属する未処理の要求メッセージの受付番号の基準となった他の要求メッセージの受付番号に変更する
ことを特徴とするリソース管理方法。
【請求項５】
請求項２または３に記載のリソース管理方法において、
前記受付番号を決定するステップは、前記受信された要求メッセージにこの要求メッセージから取得された情報に応じた条件の待ち行列の最終受付番号に基づく受付番号を付与すると前記待ち行列の容量を超えるときに、前記要求メッセージの受付を拒絶する
ことを特徴とするリソース管理方法。
【請求項６】
請求項２または３に記載のリソース管理方法において、
前記受付番号を決定するステップは、前記受信された要求メッセージにこの要求メッセージから取得された付加情報に応じた条件の待ち行列の最終受付番号に基づく受付番号を付与すると前記待ち行列の容量を超えるときに、すべて条件の待ち行列の最終受付番号の中で最大の最終受付番号を選択し、この最終受付番号に前記読み出した優先度の値を付加した値を前記受信された要求メッセージの受付番号に決定する
ことを特徴とするリソース管理方法。
【請求項７】
請求項６に記載のリソース管理方法において、
前記受付番号を決定するステップは、前記受信された要求メッセージに受付番号を付与すると前記待ち行列の容量の合計を超えるときに、前記要求メッセージの受付を拒絶する  ことを特徴とするリソース管理方法。
【請求項８】
通信ネットワークのリソースに関する処理を要求する要求メッセージを受信したときに前記要求メッセージに付加されたフロー情報を含む付加情報を取得するステップと、
前記受信された要求メッセージから前記付加情報が複数取得されたときに、取得された前記付加情報ごとに優先度記憶手段から前記優先度を読み出し、読み出した前記優先度から新たな優先度を算出するステップと、
読み出された前記優先度に基づく順番に前記受信された要求メッセージに応じた処理を行うステップと
を備えることを特徴とするリソース管理方法。
【請求項９】
請求項８に記載のリソース管理方法において、
前記処理を行うステップは、前記新たな優先度に基づく順番に処理を行なう
ことを特徴とするリソース管理方法。
【請求項１０】
請求項８に記載のリソース管理方法において、
優先度に対応したＤＳＣＰ値を記憶するＤＳＣＰ値記憶手段を参照し、前記新たな優先度に対応するＤＳＣＰ値を求めるステップと、
求められた前記ＤＳＣＰ値を前記通信ネットワークを構成するノードに設定するステップと
をさらに備えることを特徴とするリソース管理方法。
【請求項１１】
通信ネットワークのリソースに関する処理を要求する要求メッセージに付加されたサービス種別を含む付加情報に応じた優先度を記憶する優先度記憶手段と、
前記要求メッセージを受信したときに前記要求メッセージに付加されている前記付加情報を取得する情報取得手段と、
取得された前記付加情報に対応する優先度を前記優先度記憶手段から読み出す優先度読出し手段と、
受付番号が付与された要求メッセージの待ち行列を管理し、この待ち行列に属する最後の要求メッセージの受付番号である最終受付番号に、読み出された前記優先度の値を加算した値を、前記受信された要求メッセージの受付番号に決定する受付番号決定手段と、
前記受付番号の順に前記受信された要求メッセージに応じた処理を行う処理手段と、
を備えることを特徴とするリソース管理装置。
【請求項１２】
請求項１１に記載のリソース管理装置において、
前記優先度読出し手段は、前記受信された要求メッセージから前記付加情報が複数取得されたときに、取得された前記付加情報ごとに前記優先度を読み出し、
前記受付番号決定手段は、前記待ち行列を前記付加情報ごとに管理し、取得された前記付加情報のそれぞれの待ち行列の最終受付番号と前記付加情報のそれぞれに対応する前記優先度とを加算した値の合計を前記受信された要求メッセージの受付番号に決定する
ことを特徴とするリソース管理装置。
【請求項１３】
請求項１１に記載のリソース管理装置において、
前記受付番号決定手段は、前記待ち行列を前記付加情報の内容に基づく条件ごとに管理し、前記待ち行列に属する要求メッセージの処理が開始されるときに、前記要求メッセージを前記待ち行列から削除する
ことを特徴とするリソース管理装置。
【請求項１４】
請求項１３に記載のリソース管理装置において、
前記受付番号決定手段は、空の待ち行列の最終受付番号を、他の待ち行列に属する未処理の要求メッセージの受付番号の基準となった他の要求メッセージの受付番号に変更する
ことを特徴とするリソース管理装置。
【請求項１５】
請求項１３または１４に記載のリソース管理装置において、
前記情報の内容に基づく条件ごとの待ち行列のそれぞれの容量を記憶する個別容量記憶手段をさらに備え、
前記受付番号決定手段は、前記受信された要求メッセージにこの要求メッセージから取得された付加情報に応じた条件の待ち行列の最終受付番号に基づく受付番号を付与すると前記待ち行列の容量を超えるときに、前記要求メッセージの受付を拒絶する
ことを特徴とするリソース管理装置。
【請求項１６】
請求項１３または１４に記載のリソース管理装置において、
前記情報の内容に基づく条件ごとの待ち行列のそれぞれの容量を記憶する個別容量記憶手段をさらに備え、
前記受付番号決定手段は、前記受信された要求メッセージにこの要求メッセージから取得された付加情報に応じた条件の待ち行列の最終受付番号に基づく受付番号を付与すると前記待ち行列の容量を超えるときに、すべて条件の待ち行列の最終受付番号の中で最大の最終受付番号を選択し、この最終受付番号に前記読み出した優先度の値を付加した値を前記受信された要求メッセージの受付番号に決定する
ことを特徴とするリソース管理装置。
【請求項１７】
請求項１６に記載のリソース管理装置において、
前記待ち行列の容量の合計を記憶する全体容量記憶手段をさらに備え、
前記受付番号決定手段は、前記受信された要求メッセージに受付番号を付与すると前記待ち行列の容量の合計を超えるときに、前記要求メッセージの受付を拒絶する
ことを特徴とするリソース管理装置。
【請求項１８】
通信ネットワークのリソースに関する処理を要求する要求メッセージに関する情報に応じた優先度を記憶する優先度記憶手段と、
前記要求メッセージを受信したときに前記要求メッセージに付加されているフロー情報を含む付加情報を取得する情報取得手段と、
前記受信された要求メッセージから前記付加情報が複数取得されたときに、取得された前記付加情報ごとに前記優先度記憶手段から前記優先度を読み出す優先度読み出し手段と、
前記読み出した前記優先度から新たな優先度を算出する優先度決定手段と、
読み出された前記優先度に基づく順番に前記要求メッセージに応じた処理を行う処理手段と
を備えることを特徴とするリソース管理装置。
【請求項１９】
請求項１８に記載のリソース管理装置において、
前記処理手段は、前記新たな優先度に基づく順番に処理を行なうことを特徴とするリソース管理装置。
【請求項２０】
請求項１８に記載のリソース管理装置において、
優先度に対応したＤＳＣＰ値を記憶するＤＳＣＰ値記憶手段と、
前記ＤＳＣＰ値記憶手段を参照し、前記新たな優先度に対応するＤＳＣＰ値を求めるＤＳＣＰ決定手段と、
求められた前記ＤＳＣＰ値を前記通信ネットワークを構成するノードに通知するＤＳＣＰ値通知手段と
をさらに備えることを特徴とするリソース管理装置。                
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークにおけるリソースを管理するリソース管理方法および装置に関する。
【背景技術】
【０００２】
通信ネットワーク、特にＩＰ（Internet  Protocol）ネットワークを利用して音声や映像等のコンテンツを提供する場合には、通信路の容量を超える利用要求によって輻輳が発生すると、パケットの損失等に伴い通信品質が劣化してしまう。このような通信品質の劣化を防ぐことを目的として、ネットワークレイヤにおけるリソース管理が研究されている。この種のリソース管理の一つに、通信ネットワークを構成するルータとは独立したリソース管理装置（リソース管理サーバ）を用いて、ルータ間のリンクのリソース量とその利用状況を管理するとともに、ユーザ端末等からのリソース確保要求に対して適切な容量のリソースを払い出す方式がある。その従来例を以下に説明する。
【０００３】
通信ネットワークの運用開始前に、まず、その通信ネットワーク内のルーティング情報を収集する。このルーティング情報には、通信ネットワーク中の各リンクのリソース量および接続情報が含まれている。ついで、各リンクの接続情報を基にパケットが通過する経路を計算し、その計算結果を基に経路情報テーブルを作成する。また、各リンクのリソース量から、リンク情報テーブルを作成する。このリンク情報テーブルによって、各リンクの総リソース量と、利用可能な残リソース量が管理される。
【０００４】
通信ネットワークの運用開始後にあっては、リソース管理サーバにおいてリソース確保要求を受け付けると、その受付順にリソース確保の処理を開始する。具体的には、次のような処理を行う。
まず、要求された通信の発着ＩＰアドレスを基に、経路情報テーブルから当該通信に必要となるリンクを特定する。そして、リンク情報テーブルを参照し、特定されたリンクのそれぞれについて当該通信に必要な容量が利用可能か否かをチェックする。
その結果、特定されたすべてのリンクについて十分な容量が利用可能である場合には、リソース確保が可能であると判定する。そして、リソース確保要求に対して許諾応答するとともに、リンク情報テーブルにおいて、特定されたリンクの残リソース量から当該通信に割り当てられる容量を減算する。逆に、いずれかのリンクについて利用可能な容量が不足する場合には、リソース確保が不可能であると判定し、リソース確保要求に対して拒絶応答する（例えば、特許文献１および非特許文献１を参照）。
【０００５】
リソース確保要求の許諾応答を受けて通信を開始することによって、その通信の品質が保証される。
その後、通信終了時には、それまで確保していたリソースを速やかに解放する。
【０００６】
【特許文献１】特開２００３−２５８８５５号公報
【非特許文献１】矢口他、「大規模ＩＰ網における管理サーバを用いたリソース管理方式の一提案と具体例」、信学総合大会、Ｂ−６−３１（２００２）
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来のリソース管理サーバは、種々のサービスに対応可能である。例えば、ＣＤＮ（Contents Delivery Service）、ＩＭＭ（Internet Messaging Service）、ファイル転送サービスなどにも対応可能である。ＣＤＮは、ＶＯＤ（Video On Demand）、マルチキャストなどの映像、音声の配信サービスであり、コンテンツ配信サーバとユーザ端末との間で通信を行う。ＩＭＭは、ユーザ同士が音声や動画を用いて２地点以上で通信を行う。ＶｏＩＰ（Voice over IP）などにも適用可能である。ファイル転送サーバは、サーバとユーザ端末との間でのファイル転送を、ＦＴＰ（File Transfer Protocol）やＷｅｂＤＡＶ（Web Distributed Authoring and Versioning）といったプロトコルや、特定のポートを用いて行う。リモートデスクトップなど、どこにでもＰＣ環境を実現するサービスにも適用可能である。
【０００８】
これらのサービスの違いの一つは、リソース確保要求に対して、確保するリソースの形態が異なることである。例えば、ユニキャスト方式では、コンテンツ配信サーバからユーザ端末までコンテンツ毎に帯域量に応じたリソースを確保するのに対し、ＣＤＮサービスの代表的なコンテンツ配信方式であるマルチキャスト方式では、コンテンツ配信サーバとエッジルータとの間の重複する経路では同一コンテンツに対しては一つの経路分のリソースしか確保しない。
【０００９】
その他にも、５ｔｕｐｌｅ（宛先ＩＰアドレス（ＩＰプレフィックスを含む）、宛先ポート番号、送信元ＩＰアドレス（ＩＰプレフィックスを含む）、送信元ポート番号、プロトコル種別）が異なる。または、ユーザ端末とリソース管理サーバとの間に介在するアプリケーションサーバからの一つのリソース確保要求において、前記ｔｕｐｌｅが異なる（例えば、宛先ポート番号を変えて、同一経路に二つのリソースを確保する場合がある）。さらに、アプリケーションサーバからの一つのリソース確保要求に対して、一方向でリソースを確保するか、双方向でリソースを確保するかが異なる。
【００１０】
また、従来のリソース管理サーバで対応可能なサービスには、通信ネットワークを構成する機器（以下「ＮＷ機器」という）に対して制御を行う必要のあるサービスと、必要のないサービスとがある。ＮＷ機器に対する制御が必要ないサービスとしては、例えば、信頼できる通信事業者が提供するＣＤＮサービスがある。ＣＤＮサービスでは、決められたルールにしたがってコンテンツ、例えばビデオストリームを通信ネットワークに送り出す。具体的には、所定の料金を支払ったユーザへのビデオストリームのパケットには、優先度の高いマークを付けて、通信ネットワークに送り出す。この場合には、最初からリソース管理サーバとＮＷ機器との間でネゴシエーションがとれているとして、通信ネットワークへのパケットの流入を許可する。したがって、リソース管理サーバがＮＷ機器への設定を行わないので、いわば１段階のシーケンスでリソース確保が完了する。
【００１１】
一方、ＮＷ機器に対する制御が必要なサービスとしては、例えばＩＭＭサービスがある。ＩＭＭサービスのように、不特定多数のユーザの間で双方向通信を行う場合には、ユーザが勝手に優先度を上げて、もしくは故意でなくても誤った優先度でトラヒックが通信ネットワークに流入してくることがある。この場合には、通信ネットワークの入口などでＮＷ機器への制御を行ない、当該ユーザのトラヒックの流入制御を行う必要がある。ここでいう流入制御には、ルールに基づく制御、ＤＳＣＰ値による優先度の異なる転送や、上限速度での制限などがある。リソース管理サーバによるリソース確保判定とは別に、流入制御の成功または失敗を判定可能なので、両者を別々のシーケンスとして処理する場合がある。この場合には、リソース（帯域量）としては確保できるが、思い通りの流入制御ができるかどうかを２段目のシーケンスで問い合わせ、その結果、成功して初めてサービスを享受できる。
【００１２】
このように、リソース管理サーバで対応可能なサービスには、シーケンスが１段階のサービスと２段階のサービスとがあり、サービス種別によってリソース管理サーバにかかる処理負荷やリソース確保に要する時間に違いがあった。また、異なるサービスを提供する事業者の種別や、リソース管理サーバの種別（アプリケーションサーバＩＰと優先度との対応テーブルを用いて優先度を決定）によっても、処理負荷やリソース確保に要する時間に違いがあった。
【００１３】
しかしながら、従来はサービス種別や事業者種別、リソース管理サーバ種別にかかわらず、単純にリソース確保要求の受付順にリソース確保の処理を開始していた。このため、例えば処理負荷が大きいサービスの要求が集中したときには、少数の要求しか処理することができず、その他の多数の要求を拒絶しなければならない場合があった。また、２段階シーケンスのサービスの要求と１段階シーケンスのサービスの要求を受け付けたときに、この順に処理を開始しても、短時間で処理が終わる１段階シーケンスのサービスの要求に対してリソースが確保された結果、先に受け付けた２段階シーケンスのサービスの要求が拒絶され、公平性を失する場合もあった。
【００１４】
本発明は、このような課題を解決するためになされたものであり、その目的は、リソース管理サーバへの要求をその性質に応じた順番で処理できるようにすることにある。
【課題を解決するための手段】
【００１５】
このような目的を達成するために、本発明に係るリソース管理方法は、通信ネットワークのリソースに関する処理を要求する要求メッセージを受信したときに要求メッセージに付加された情報を取得するステップと、要求メッセージに関する情報に応じた優先度を記憶する優先度記憶手段から、取得された情報に対応する優先度を読み出すステップと、読み出された優先度に基づく順番に受信された要求メッセージに応じた処理を行うステップとを備えることを特徴とする。
【００１６】
このリソース管理方法は、受付番号が付与された要求メッセージの待ち行列を管理し、この待ち行列に属する最後の要求メッセージの受付番号である最終受付番号に、読み出された優先度の値を加算した値を、受信された要求メッセージの受付番号に決定するステップをさらに備え、処理を行うステップは、受付番号の順に受信された要求メッセージに応じた処理を行うようにしてもよい。
【００１７】
ここで、優先度を読み出すステップは、受信された要求メッセージから情報が複数取得されたときに、取得された情報ごとに優先度を読み出し、受付番号を決定するステップは、待ち行列を情報ごとに管理し、取得された情報のそれぞれの待ち行列の最終受付番号と情報のそれぞれに対応する優先度とを加算した値の合計を受信された要求メッセージの受付番号に決定してもよい。
【００１８】
また、受付番号を決定するステップは、待ち行列を情報の内容に基づく条件ごとに管理し、待ち行列に属する要求メッセージの処理が開始されるときに、要求メッセージを待ち行列から削除してもよい。
また、受付番号を決定するステップは、空の待ち行列の最終受付番号を、他の待ち行列に属する未処理の要求メッセージの受付番号の基準となった他の要求メッセージの受付番号に変更してもよい。
【００１９】
また、受付番号を決定するステップは、受信された要求メッセージにこの要求メッセージから取得された情報に応じた条件の待ち行列の最終受付番号に基づく受付番号を付与すると待ち行列の容量を超えるときに、要求メッセージの受付を拒絶してもよい。あるいは、すべて条件の待ち行列の最終受付番号の中で最大の最終受付番号を選択し、この最終受付番号に読み出した優先度の値を付加した値を受信された要求メッセージの受付番号に決定してもよい。
後者の場合には、受付番号を決定するステップは、受信された要求メッセージに受付番号を付与すると待ち行列の容量の合計を超えるときに、要求メッセージの受付を拒絶してもよい。
【００２０】
また、優先度を読み出すステップは、受信された要求メッセージから情報が複数取得されたときに、取得された情報ごとに優先度記憶手段から優先度を読み出し、読み出した優先度から新たな優先度を算出するようにしてもよい。
この場合、処理を行うステップは、新たな優先度に基づく順番に処理を行なうようにしてもよい。さらに、優先度に対応したＤＳＣＰ値を記憶するＤＳＣＰ値記憶手段を参照し、新たな優先度に対応するＤＳＣＰ値を求めるステップと、求められたＤＳＣＰ値を通信ネットワークを構成するノードに設定するステップとを備えるようにしてもよい。
【００２１】
また、本発明にかかるリソース管理装置は、通信ネットワークのリソースに関する処理を要求する要求メッセージに関する情報に応じた優先度を記憶する優先度記憶手段と、要求メッセージを受信したときに要求メッセージに付加されている情報を取得する情報取得手段と、取得された情報に対応する優先度を優先度記憶手段から読み出す優先度読出し手段と、読み出された優先度に基づく順番に要求メッセージに応じた処理を行う処理手段とを備えることを特徴とする。
【００２２】
このリソース管理装置は、受付番号が付与された要求メッセージの待ち行列を管理し、この待ち行列に属する最後の要求メッセージの受付番号である最終受付番号に、読み出された優先度の値を加算した値を、受信された要求メッセージの受付番号に決定する受付番号決定手段をさらに備え、処理手段は、受付番号の順に受信された要求メッセージに応じた処理を行うようにしてもよい。
【００２３】
また、優先度読出し手段は、受信された要求メッセージから情報が複数取得されたときに、取得された情報ごとに優先度を読み出し、受付番号決定手段は、待ち行列を情報ごとに管理し、取得された情報のそれぞれの待ち行列の最終受付番号と情報のそれぞれに対応する優先度とを加算した値の合計を受信された要求メッセージの受付番号に決定するようにしてもよい。
【００２４】
また、受付番号決定手段は、待ち行列を情報の内容に基づく条件ごとに管理し、待ち行列に属する要求メッセージの処理が開始されるときに、要求メッセージを待ち行列から削除してもよい。
また、受付番号決定手段は、空の待ち行列の最終受付番号を、他の待ち行列に属する未処理の要求メッセージの受付番号の基準となった他の要求メッセージの受付番号に変更してもよい。
【００２５】
また、上述したリソース管理装置は、情報の内容に基づく条件ごとの待ち行列のそれぞれの容量を記憶する個別容量記憶手段をさらに備え、受付番号決定手段は、受信された要求メッセージにこの要求メッセージから取得された情報に応じた条件の待ち行列の最終受付番号に基づく受付番号を付与すると待ち行列の容量を超えるときに、要求メッセージの受付を拒絶してもよい。あるいは、すべて条件の待ち行列の最終受付番号の中で最大の最終受付番号を選択し、この最終受付番号に読み出した優先度の値を付加した値を受信された要求メッセージの受付番号に決定してもよい。
後者の場合には、上述したリソース管理装置は、待ち行列の容量の合計を記憶する全体容量記憶手段をさらに備え、受付番号決定手段は、受信された要求メッセージに受付番号を付与すると待ち行列の容量の合計を超えるときに、要求メッセージの受付を拒絶してもよい。
【００２６】
また、優先度読出し手段は、受信された要求メッセージから情報が複数取得されたときに、取得された情報ごとに優先度記憶手段から優先度を読み出し、読み出した優先度から新たな優先度を算出する優先度決定手段を備えるようにしてもよい。
この場合、処理手段は、新たな優先度に基づく順番に処理を行なうようにしてもよい。さらに、優先度に対応したＤＳＣＰ値を記憶するＤＳＣＰ値記憶手段と、ＤＳＣＰ値記憶手段を参照し、新たな優先度に対応するＤＳＣＰ値を求めるＤＳＣＰ決定手段と、求められたＤＳＣＰ値を通信ネットワークを構成するノードに通知するＤＳＣＰ値通知手段とを備えるようにしてもよい。
【発明の効果】
【００２７】
本発明では、要求メッセージに関する情報に応じた優先度を予め決めておき、受信した要求メッセージに付加されている情報を取得し、この情報に対応する優先度に基づく順番に要求メッセージに応じた処理を行う。これにより、受信した要求メッセージをその性質に応じた順番で処理できるようになる。例えば、処理負荷の大きい要求メッセージの処理が分散されるように優先度を調整することにより、リソース管理装置の処理能力を超えることによる要求の拒絶を低減させることができる。また、処理時間の長い要求メッセージが優先的に処理されるように優先度を調整することにより、処理時間の長短による要求メッセージ間の不公平を是正することができる。これとは逆に、優先度の調整によって、要求メッセージ間に差異をつけることもできる。
【００２８】
また、本発明では、受付番号が付与された要求メッセージの待ち行列を管理し、この待ち行列の最終受付番号に優先度の値を加算した値を受信された要求メッセージの受付番号とし、受付番号の順に要求メッセージに応じた処理を行う。この場合には、優先度の値の大きい情報が付加された要求メッセージは受付番号が大きくなり、処理の開始が遅くなる。これに対し、優先度の値の小さい情報が付加された要求メッセージは受付番号が小さくなり、処理の開始が早くなる。例えば、処理負荷が大きい要求メッセージに付加される情報の優先度の値を大きくすることにより、この種の要求メッセージの処理を分散させることができる。また、処理時間が長い要求メッセージに付加される情報の優先度の値を小さくすることにより、この種の要求メッセージを優先的に処理ことができる。
【００２９】
また、本発明では、受信された要求メッセージから情報が複数取得されたときに、それぞれの情報から求められる受付番号の合計を、受信された要求メッセージの受付番号とする。これにより、複数の情報に基づく受付番号の決定が可能となる。
【００３０】
また、本発明では、要求メッセージから取得される情報の内容に基づく条件ごとに待ち行列を管理し、空の待ち行列の最終受付番号を、他の待ち行列に属する未処理の要求メッセージの受付番号の基準となった他の要求メッセージの受付番号に変更する。これにより、すでに他の待ち行列に属する要求メッセージが、後から受信されて当該空の待ち行列に属することになる要求メッセージよりも不利に扱われることを防止できる。
【００３１】
また、本発明では、受信された要求メッセージにこの要求メッセージから取得した情報に応じた条件の待ち行列の最終受付番号に基づく受付番号を付与するとこの待ち行列の容量を超えるときに、要求メッセージの受付を拒絶する。これにより、特定の内容の要求メッセージが集中した場合に、その要求メッセージの新たな受付を拒絶し、他の要求メッセージの処理が滞ることを防止できる。
あるいは、要求メッセージの受付を拒絶しないで、すべての条件の待ち行列の最終受付番号の中で最大の最終受付番号に優先度の値を付加した値を、受信された要求メッセージの受付番号とする。これにより、他の条件の待ち行列の空き容量を有効活用しつつ、他の条件の待ち行列に属する要求メッセージの処理が滞ることを防止できる。
【００３２】
また、本発明では、受信された要求メッセージに受付番号を付与すると待ち行列の容量の合計を超えるときに、受信された要求メッセージの受付を拒絶する。これにより、要求メッセージが大量に到来しても、輻輳の発生を防止することができる。
【発明を実施するための最良の形態】
【００３３】
以下、図面を参照し、本発明の実施の形態について詳細に説明する。
１．第１の実施の形態
図１は、本発明の第１の実施の形態にかかるリソース管理サーバが適用されるシステムの全体構成を示すブロック図である。
図１に示すリソース管理サーバ１は、通信ネットワーク２のリソースを管理するリソース管理装置である。リソース管理サーバ１は、ＣＤＮ、ＩＭＭ、ファイル転送サービスなどの種々のサービスに対応可能である。
【００３４】
管理対象となる通信ネットワーク２は、インターネットプロトコル（ＩＰ）に基づく通信ネットワークであり、ルータＲ（Ｒ１〜Ｒ７）や交換機（図示せず）、ＬＡＮスイッチ（図示せず）などの複数のノードと、ノード間を接続するリンクとから構成される。この通信ネットワーク２のリソースとは、通信を行う２つの端末間の経路を構成するリンクにおいて、課金によって所定時間払い出される容量のことをいう。連続課金によって容量の払い出しを継続することができる。
【００３５】
アプリケーションサーバ３は、端末Ｔ（例えば端末Ｔ１）からの各種要求を受けて、その要求に応じたメッセージをリソース管理サーバ１に送信するサーバである。要求メッセージには、端末Ｔと他の端末との間で行う通信に必要な容量のリソースの確保を要求するリソース確保要求メッセージ、確保されたリソースについて容量の変更を要求するリソース変更要求メッセージ、確保されたリソースの解放を要求するリソース解放要求メッセージ等がある。
【００３６】
それぞれの要求メッセージには、ユーザＩＤ、アプリケーションＩＤ、ＣＤＮ，ＩＭＭ，ファイル転送サービスなどのサービス種別、要求メッセージにかかる要求の種別（要求種別）、フロー識別情報（発着端末のＩＰアドレス、発着ポート番号、プロトコル種別）、通信を行う端末間で送られるパケットの優先度を定義するＤＳＣＰ値（Differentiated Services Code Point）、通信を行ういずれかの端末がＶＬＡＮ（Virtual LAN）に属する場合にそのＶＬＡＮの識別子（ＶＬＡＮＩＤ）等の情報が付加される。
【００３７】
１−１．リソース管理サーバ１の構成
次に、リソース管理サーバ１の構成について説明する。
リソース管理サーバ１は、通信機能を有するコンピュータからなる。以下に説明するリソース管理サーバ１の諸機能は、演算装置（ＭＰＵ）や記憶装置（ＲＯＭおよびＲＡＭ等の内部メモリの他、ＨＤＤ等の外部記憶装置を含む）等のコンピュータのハードウェア資源とこのコンピュータにインストールされたコンピュータ・プログラム（ソフトウェア）とが協働することによって実現される。
【００３８】
図２は、リソース管理サーバ１の機能ブロック図である。
このリソース管理サーバ１は、送受信部１１と、制御部１２と、データベース部１３とを有する。
ここで、送受信部１１は、通信インターフェースを備え、アプリケーションサーバ３との間で各種メッセージを送信および受信する。
【００３９】
制御部１２は、送受信部１１で受信された要求メッセージに応じて、通信ネットワーク２のリソースに関する処理を行う。具体的には、要求受付部１２１と、リソース処理部１２２と、応答処理部１２３とを有する。
要求受付部（情報取得部、優先度読出し部、受付番号決定部）１２１は、送受信部１１で受信された要求メッセージから必要な情報を取得し、取得した情報に基づき要求メッセージに対し受付番号を付与する。要求メッセージの受付番号は、そのメッセージに関する様々な条件によって決定される。この条件をポリシーと呼ぶ。ポリシーは、例えば上述した要求メッセージに付加される情報ごとに設定される。すなわち、ユーザＩＤ、アプリケーションＩＤ、サービス種別、要求種別、フロー識別情報、ＤＳＣＰ値、ＶＬＡＮＩＤ等に設定される。
リソース処理部１２２は、受付番号が小さい方から順に要求メッセージに応じた処理を行う。
応答処理部１２３は、要求メッセージにかかる要求を許諾または拒絶する旨のメッセージを作成し、送受信部１１に出力する。
【００４０】
データベース部１３は、上述した制御部１２による処理に必要な各種情報を記憶する。具体的には、従来から用いられている経路情報テーブルおよびリンク情報テーブルの他に、ポリシーテーブルおよび受付番号テーブルを記憶する。
【００４１】
ポリシーテーブルは、ポリシーの内容を示すテーブルであり、例えば上述した要求メッセージに付加される情報ごとに設けられている。例えば図３に示すポリシーテーブル１３１は、ＣＤＮ，ＩＭＭ，ファイル転送サービスなどのサービス種別に関するポリシーであり、「サービス種別」、「優先度」、「最終受付番号」、「制限量」および「蓄積量」という項目からなる。
【００４２】
「優先度」とは、各サービスに設定された優先度である。値が小さいほど優先度が高い。
「最終受付番号」とは、各サービスを求める要求メッセージの待ち行列（キュー）の最終受付番号である。原則として、各キューに属する最後の要求メッセージの受付番号である。例えば、キューに２つの要求メッセージが属している場合には、２番目の要求メッセージの受付番号が最終受付番号となる。
「制限量」とは、各サービスを求める要求メッセージのキューの個別容量であり、そのキューで蓄積可能な要求メッセージの数を表す。
「蓄積量」とは、その時点でキューに蓄積されている要求メッセージの数を表す。
なお、ポリシーテーブル１３１の優先度および制限量等の情報が外部記憶装置に記録されている場合には、これらの情報をリソース管理サーバ１の起動時に読み込むこともできるし、起動後に読み込み途中変更することもできる。
【００４３】
受付番号テーブルは、要求メッセージの受付番号を示すテーブルである。例えば図４に示す受付番号テーブル１３２のように、「要求ＩＤ」および「受付番号」という項目からなる。
「要求ＩＤ」とは、要求メッセージに個別に付与された識別子である。
「受付番号」とは、要求ＩＤによって表される要求メッセージに付与された受付番号である。要求メッセージから複数の情報が抽出され、それぞれの情報に対して設定されたポリシーにしたがって複数の受付番号が求められた場合には、すべての受付番号を合計した値がその要求メッセージの受付番号として付与され、この欄に書き込まれる。
【００４４】
なお、優先度およびキューの個別容量（制限量）を記憶するデータベース部１３は、優先度記憶部および個別容量記憶部として機能する。
【００４５】
１−２．受付番号付与のアルゴリズム
次に、図５および図６を参照し、要求受付部１２１による受付番号付与のアルゴリズムについて説明する。ここでは、サービス種別に関するポリシーを例にして説明する。図５および図６は、サービスＡ〜Ｄを求めるリソース確保要求メッセージのキュー（以下「サービスＡ〜Ｄのキューと略記する）を概念的に示す図である。
【００４６】
まず、図５を参照し、受付番号付与の基本的なアルゴリズムについて説明する。
サービス種別「Ａ」の要求メッセージ１が受信されたとき、要求受付部１２１はこの要求メッセージ１をサービスＡのキューに振り分ける。このときサービスＡのキューは空であるから、このキューの最終受付番号は「０」である。この最終受付番号「０」にサービスＡの優先度「５０」を加算した値「５０」を、要求メッセージ１の受付番号とする。
その後、続いてサービス種別「Ｂ」の要求メッセージ２、サービス種別「Ｃ」の要求メッセージ３が受信されたときにも、同様にしてそれぞれの受付番号を「３０」、「１０」とする。
【００４７】
さらにその後、サービス種別「Ａ」の要求メッセージ４が受信されたとき、要求受付部１２１はこの要求メッセージ４を再びサービスＡのキューに振り分ける。このときサービスＡのキューには最初の要求メッセージ１が蓄積されており、この要求メッセージ１の受付番号「５０」がキューの最終受付番号となっている。したがって、キューの最終受付番号「５０」にサービスＡの優先度「５０」を加算した値「１００」を、要求メッセージ４の受付番号とする。
【００４８】
その結果、ポリシーテーブル１３１の「最終受付番号」および受付番号テーブル１３２の「受付番号」は、それぞれ図３および図４に示すようになる。
リソース処理部１２２は、受付番号が小さいメッセージから順に処理を行うので、要求メッセージ３→要求メッセージ２→要求メッセージ１→要求メッセージ４の順にリソース確保の処理が行われることになる。
【００４９】
次に、図６を参照し、キューの最終受付番号の変更について説明する。
図５で説明したように要求メッセージ１〜４について受付番号が付与された後、要求メッセージ３，２，１についての処理が開始されると、その時点でこれらの要求メッセージ１〜３はそれぞれのキューから削除される。これにより、最終受付番号「０」を基準にして受付番号を決定した要求メッセージ１〜３が、すべて削除されたことになる。このままサービスＢ〜Ｄのキューの最終受付番号を「０」のままにしておき、この最終受付番号を基準にした受付番号の決定を続けると、すでに受付番号が決定された要求メッセージ４が不利に扱われる場合がある。
【００５０】
そこで、本実施の形態では、最終受付番号「０」を基準にして受付番号を決定した要求メッセージ１〜３がすべてキューから削除された時点で、図６に示すように、サービスＡ〜Ｄのキューの最終受付番号を、未処理の要求メッセージ４の受付番号の基準となった要求メッセージ１の受付番号「５０」に変更する。
【００５１】
このような最終受付番号の変更を行った後で、図６に示すようにサービス種別「Ｄ」の要求メッセージ５が受信されると、要求受付部１２１はこの要求メッセージ５をサービスＤのキューに振り分け、このキューの最終受付番号「５０」にサービスＤの優先度「１０」を加算した値「６０」を要求メッセージ５の受付番号とする。
この場合には、要求メッセージ４よりも要求メッセージ５の方が受付番号が小さいので、要求メッセージ５から先にリソース確保の処理が行われることになる。
なお、すべての要求メッセージが処理され、すべてのキューが空になった場合には、すべてのキューの最終受付番号を「０」に戻す。
【００５２】
１−３．リソース管理サーバ１の動作
次に、上述したアルゴリズムに基づく受付番号付与の動作を中心に、リソース管理サーバ１の動作について説明する。
【００５３】
まず、図７を参照し、リソース管理サーバ１における全体的な処理の流れについて説明する。
送受信部１１でリソース確保要求メッセージを受信すると（ステップＳ１，ＹＥＳ）、要求受付部１２１は、受信されたリソース確保要求メッセージから、受付番号決定のポリシーが設定された情報を取得する（ステップＳ２）。ここでは、サービス種別などｎ個（ｎは１以上の整数）の情報を取得したものとする。
ｎ個の情報を取得した要求受付部１２１は、上述したアルゴリズムにしたがって、それぞれの情報について情報受付番号Ｎｏi（ｉ＝１，２，…，ｎ）を算出する（ステップＳ３〜７）。個々の情報受付番号Ｎｏi算出の詳しい処理の流れについては後述する。
【００５４】
ｎ個すべての情報について情報受付番号Ｎｏiを算出できた場合には、要求受付部１２１はｎ個の情報受付番号Ｎｏiの合計（ΣＮｏi）を求め、その値を要求受付番号としてリソース確保要求メッセージに付与する（ステップＳ８）。また、リソース確保要求メッセージに要求ＩＤを付与し、この要求ＩＤとともに要求受付番号を図４に示した受付番号テーブル１３２に書き込む。
リソース処理部１２２は、受付番号テーブル１３２を参照し、要求受付番号が小さい要求ＩＤに対応するリソース確保要求メッセージから順に、リソース確保の処理を開始する（ステップＳ９）。このリソース確保の処理は従来と同じであるから、その説明は省略する。
【００５５】
なお、個々の情報受付番号Ｎｏi算出の処理において、後述するようにリソース確保要求を受け付けられないと判断された場合には（ステップＳ５，ＹＥＳ）、応答処理部１２３はリソース確保要求を拒絶する旨の応答メッセージを作成し、この応答メッセージを送受信部１１よりリソース確保要求メッセージの送信元に返信する（ステップＳ１０）。
以上により、リソース確保要求メッセージを受信してから、このメッセージに受付番号を付与しリソース確保を行うまでの一連の処理が終了する。
【００５６】
次に、図８を参照し、ポリシーが設定された情報ごとの情報受付番号Ｎｏi算出の処理について説明する。
図７のステップＳ２において、受信されたリソース確保要求メッセージから例えばサービス種別「Ａ」の情報を取得すると、要求受付部１２１は、図３に示したポリシーテーブル１３１を参照し、サービスＡのキューに空きがあるか否かをチェックする（ステップＳ２１）。サービスＡのキューの蓄積量が制限量に達していない場合には、このキューに空きがあると判断し、蓄積量が制限量に達している場合には空きがないと判断することができる。
【００５７】
サービスＡのキューに空きがある場合には（ステップＳ２１，ＹＥＳ）、要求受付部１２１は、受信されたリソース確保要求メッセージをサービスＡのキューに蓄積する。具体的には、ポリシーテーブル１３１におけるサービスＡのキューの蓄積量に１を加算すればよい。また、ポリシーテーブル１３１からサービスＡの優先度「５０」とサービスＡのキューの最終受付番号「１００」を読み出し、両者を加算した値「１５０」をサービス種別についての情報受付番号Ｎｏiとする（ステップＳ２２）。このとき、ポリシーテーブル１３１におけるサービスＡのキューの最終受付番号を「１００」から「１５０」に書き換える。
【００５８】
これに対し、サービスＡのキューに空きがない場合には（ステップＳ２１，ＮＯ）、要求受付部１２１は、サービスＡのリソース確保要求メッセージを受け付けられないと判断する（ステップＳ２３）。この場合には、リソース確保要求を拒絶する旨の応答がなされることになる（図７のステップＳ１０）。このような処理を行うことにより、サービスＡの要求が集中した場合でも、その一部を拒絶し、リソース確保サーバ１の処理能力を他のサービスＢ〜Ｄの処理に振り分け、サービスＢ〜Ｄの処理が滞ることを防止できる。
以上により、サービス種別についての情報受付番号Ｎｏiの算出処理が終了する。
その他の情報の情報受付番号Ｎｏiの算出処理も同様に行われる。
【００５９】
以上のように、要求メッセージに関する情報に応じた優先度を予め決めておき、受信した要求メッセージに付加されている情報に対応する優先度に基づき受付番号を付与し、この受付番号の順に要求メッセージに応じた処理を行うことにより、受信した要求メッセージをその性質に応じた順番で処理することが可能となる。例えば、処理負荷の大きい要求メッセージの処理が分散されるように優先度を調整することにより、リソース管理サーバの処理能力を超えることによる要求の拒絶を低減させることができる。また、処理時間の長い要求メッセージが優先的に処理されるように優先度を調整することにより、処理時間の長短による要求メッセージ間の不公平を是正することができる。これとは逆に、優先度の調整によって、要求メッセージ間に差異をつけることもできる。
【００６０】
上述したように、本実施の形態では、受信された要求メッセージから取得した情報に応じた条件のキューの最終受付番号に優先度の値を加算した値を、要求メッセージの受付番号とする。この場合には、優先度の値の大きい情報が付加された要求メッセージは受付番号が大きくなり、処理の開始が遅くなる。これに対し、優先度の値の小さい情報が付加された要求メッセージは受付番号が小さくなり、処理の開始が早くなる。例えば、処理負荷が大きい要求メッセージに付加される情報の優先度の値を大きくすることにより、この種の要求メッセージの処理を分散させることができる。また、処理時間が長い要求メッセージに付加される情報の優先度の値を小さくすることにより、この種の要求メッセージを優先的に処理ことができる。
また、受信された要求メッセージから情報が複数取得されたときに、それぞれの情報から求められる情報受付番号の合計を、要求受付番号として要求メッセージに付与する。これにより、複数の情報に基づく受付番号の決定が可能となる。
【００６１】
なお、本実施の形態では、それぞれのキューに順位付けがなされている。したがって、受付番号が同じになった要求メッセージについては、順位が高いキューに属する要求メッセージから先に処理を行うものとする。例えば、サービスＡ，Ｂ，Ｃ，Ｄのキューの順位がそれぞれ１，２，３，４，の場合には、サービスＡのキューに属する要求メッセージから順に処理が行われることになる。
また、本実施の形態では、サービスＣとＤの優先度が同じ値に設定されているが、すべてのポリシーの優先度を同じ値に設定することもできる。
また、ポリシーの優先度を「０」にすることもできる。このポリシーを満たす要求メッセージは、リソース管理サーバ１の送受信部１１で受信されしだい、直ちに処理が開始される。したがって、このポリシーのキューは優先キューとして扱われることになる。
【００６２】
２．第２の実施の形態
図９は、本発明の第２の実施の形態にかかるリソース管理サーバの機能ブロック図である。この図では、図２に示した構成要素と同一の部分を、図２と同一の符号で示している。
この図に示すリソース管理サーバ１Ａは、制御部１２Ａの要求受付部１２１Ａが、第１の実施の形態における要求受付部１２１とは異なる機能を有している。また、データベース部１３Ａに記憶されるポリシーテーブル１３１Ａが、第１の実施の形態におけるポリシーテーブル１３１と一部異なっている。
【００６３】
図１０を参照し、要求受付部１２１Ａの機能について説明する。ここでは、第１の実施の形態と同様に、サービス種別に関するポリシーを例にして説明する。図１０は、サービスＡ〜Ｄのキューを概念的に示す図である。
サービスＡのキューにおける要求メッセージの蓄積量がそのキューの制限量に達すると、蓄積されている要求メッセージ１の処理が開始され、要求メッセージ１がキューから削除されない限り、キューに新たな要求メッセージ９を蓄積することはできない。
この場合に、本実施の形態では、要求メッセージ９を他のサービスＢ〜Ｄのキューの空き容量を利用して蓄積する。
【００６４】
しかし、仮に要求メッセージ９の受付番号が他のキューに属する要求メッセージの受付番号よりも小さくなり、要求メッセージ９が優先的に処理され、他のキューに属する要求メッセージの処理が滞ることは好ましくない。
そこで、本実施の形態では、すべてのサービスＡ〜Ｄのキューの最終受付番号の中で最大の最終受付番号「１２０」を選択し、この最終受付番号「１２０」にサービスＡの優先度「５０」を加算した値「１７０」を、要求メッセージ９の受付番号とする。これにより、他のキューに属する要求メッセージの処理を妨げることなく、他のキューの空き容量を有効利用することが可能となる。
【００６５】
この処理を実現するために、ポリシーテーブル１３１Ａには図１１に示すように、サービスＡ〜Ｄのキュー全体の最終受付番号の欄がある。このキュー全体の最終受付番号は、サービスＡ〜Ｄのそれぞれのキューの最終受付番号の中で最大のものと同じ値となる。
ポリシーテーブル１３１Ａにはさらに、キュー全体の「制限量」および「蓄積量」の欄がある。キュー全体の「制限量」とは、すべてのキューの全体容量（各キューの個別容量の合計）であり、すべてのキューで蓄積可能な要求メッセージの数を表す。キュー全体の「蓄積量」とは、その時点ですべてのキューに蓄積されている要求メッセージの数を表す。
なお、すべてのキューの全体容量を記憶するデータベース部１３Ａは、全体容量記憶部として機能する。
【００６６】
次に、図１２を参照し、キューの制限量に達した受付処理部１２１Ａの動作について説明する。この図では、図８に示した構成要素と同一の部分を、図８と同一の符号で示している。以下、第１の実施の形態の説明と同様に、サービスＡを求めるリソース確保要求メッセージの個別受付番号Ｎｏiを算出する処理について説明する。
サービスＡのキューに空きがある場合の処理は、第１の実施の形態と同じである（ステップＳ２１，Ｓ２２）。
【００６７】
サービスＡのキューに空きがない場合には（ステップＳ２１，ＮＯ）、要求受付部１２１は、再びポリシーテーブル１３１Ａを参照し、サービスＡ〜Ｄのキュー全体に空きがあるか否かをチェックする（ステップＳ２４）。サービスＡ〜Ｄのキュー全体の蓄積量が制限量に達していない場合には、キュー全体には空きがあると判断し、蓄積量が制限量に達している場合には、キュー全体にも空きがないと判断することができる。
【００６８】
サービスＡ〜Ｄのキュー全体に空きがある場合には（ステップＳ２４，ＹＥＳ）、要求受付部１２１は、ポリシーテーブル１３１ＡにおけるサービスＡ〜Ｄのキュー全体の蓄積量に１を加算する。また、ポリシーテーブル１３１ＡからサービスＡの優先度「５０」と、サービスＡ〜Ｄのキュー全体の最終受付番号「１２０」を読み出し、両者を加算した値「１７０」をサービス種別についての情報受付番号Ｎｏiとする（ステップＳ２５）。このとき、ポリシーテーブル１３１ＡにおけるサービスＡのキューの最終受付番号を「１００」から「１７０」に書き換える。この書き換えに連動して、キュー全体の最終受付番号も書き換えられる。
【００６９】
これに対し、サービスＡ〜Ｄのキュー全体にも空きがない場合には（ステップＳ２４，ＮＯ）、リソース確保要求を受け付けられないと判断する（ステップＳ２６）。この場合には、リソース確保要求を拒絶する旨の応答がなされることになる（図７のステップＳ１０）。これにより、リソース管理サーバ１Ａの処理能力を超えたリソース確保要求メッセージが大量に到来しても、輻輳の発生を防止することができる。
以上により、情報受付番号Ｎｏiの算出処理が終了する。
なお、サービスＡのような所定のポリシーのキューに空きがない場合に、本実施の形態のように他のキューの空き容量を利用して受付番号を付与するか、第１の実施の形態のようにリソース確保要求メッセージの受付を拒絶するかを選択できるようにしてもよい。
【００７０】
３．第３の実施の形態
次に、本発明の第３の実施の形態について説明する。本実施の形態にかかるリソース管理サーバは、要求メッセージに複数の情報が付加され、情報のそれぞれに優先度が設定されている場合に、複数の優先度から新たな優先度を決定し、新たな優先度に基づく順番に要求メッセージに応じた処理を行うものである。
図１３は、本実施の形態にかかるリソース管理サーバの機能ブロック図である。この図では、図２に示した構成要素と同一の部分を、図２と同一の符号で示している。
【００７１】
データベース部１３Ｂは、上述したポリシーテーブル１３１や受付番号テーブル１３２に加えて、要求メッセージに付加される情報に応じた優先度（演算方法を含む）を示す優先度対応テーブルを記憶している。図１４および図１５に優先度対応テーブルの例を示す。図１４に示す優先度対応テーブル１３３Ａには、フローに対応する優先度が設定されている。フローは、発着端末のＩＰアドレス、発着ポート番号、プロトコル種別などからなる５ｔｕｐｌｅと呼ばれる識別情報で区別される。図１５（ａ）に示す優先度対応テーブル１３３Ｂには、ＩＰプレジデンスに対応する優先度が設定されている。図１５（ｂ）に示す優先度対応テーブル１３３Ｃには、アプリケーションサーバＩＰに対応する優先度またはその演算方法が設定されている。図１５（ｃ）に示す優先度対応テーブル１３３Ｄには、ＤＳＣＰ値に対応する優先度が設定されている。
【００７２】
なお、優先度対応テーブル１３３Ｂ，１３３Ｃにおいて、「ａｎｙ」は「その他の場合」を意味し、「ｎ」は「要求拒絶」を意味する。例えば、ＩＰプレジデンスが「１１１」の場合には、要求メッセージにかかる要求が拒絶されることになる。
また、優先度が「０」となる条件に合致する場合には、最優先で処理が行われることになる。
【００７３】
制御部１２における要求受付部１２１Ｂは、優先度決定部１２４を有する。優先度決定部１２４は、データベース部１３Ｂに記憶されている優先度対応テーブルを参照し、要求メッセージに付加された情報に合致する条件がある場合には、この条件にしたがって新たな優先度を決定する。以下、具体的に説明する。
【００７４】
ここでは、データベース部１３Ｂに、図３に示したポリシーテーブル１３１の他、図１５（ｃ）に示した優先度対応テーブル１３３Ｄおよび図１５（ｂ）に示した優先度対応テーブル１３３Ｃが存在し、テーブル１３３Ｄがテーブル１３３Ｃに対して優先適用されるものとする。また、第１の実施の形態で説明したサービス種別「Ａ」の要求メッセージ４に、ＤＳＣＰ値「００１０００」、アプリケーションサーバＩＰ「１９２．１６８．１００．１」が付加されているものとする。この場合、ポリシーテーブル１３１を参照すると、サービス種別「Ａ」の優先度は「５０」、優先度対応テーブル１３３Ｄを参照するとＤＳＣＰ値「００１０００」の優先度は「−１０」、優先度対応テーブル１３３Ｃを参照するとアプリケーションサーバＩＰ「１９２．１６８．１００．１」の優先度演算方法は「＊０．８」であるから、これらの係数を順番に計算して（５０−１０）×０．８＝３２という新たな優先度を得る。
【００７５】
第１の実施の形態では、要求メッセージ４の受付番号はサービスＡのキューの最終受付番号「５０」に優先度「５０」を加算した値「１００」となるのに対し、本実施の形態では、最終受付番号「５０」に新たな優先度「３２」を加算した値「８２」となる。
リソース処理部１２２は、受付番号が小さい方から順に要求メッセージに応じた処理を行うので、サービス種別だけでなく、要求メッセージに付加された他の情報をも加味した順番で処理を行うことができる。
【００７６】
４．第４の実施の形態
次に、本発明の第４の実施の形態について説明する。本実施の形態にかかるリソース管理サーバは、第３の実施の形態で説明したように要求メッセージに関する情報に応じて優先度を決定した後、この優先度に対応するＤＳＣＰ値を求めるものである。
図１６は、本実施の形態にかかるリソース管理サーバの機能ブロック図である。この図では、図２または図１３に示した構成要素と同一の部分を、図２または図１３と同一の符号で示している。
【００７７】
データベース部１３Ｃは、上述したポリシーテーブル１３１や受付番号テーブル１３２、優先度対応テーブル１３３に加えて、優先度とＤＳＣＰ値との対応を示すＤＳＣＰ変換テーブルを記憶している。図１７にＤＳＣＰ変換テーブルの一例を示す。したがって、データベース部１３Ｃは、ＤＳＣＰ値記憶部として機能する。
制御部１２ＣのＤＳＣＰ決定部１２５は、データベース部１３Ｃに記憶されているＤＳＣＰ変換テーブル１３４を参照し、優先度決定部１２４によって決定された新たな優先度に対応するＤＳＣＰ値を求め、このＤＳＣＰ値をデータベース部１３Ｃのリソース管理テーブルに登録する。なお、本実施の形態では、受付番号の付与に優先度を用いず、受付順に処理を行う。
【００７８】
応答処理部１２３Ｃは、リソース確保要求メッセージを受信してリソース確保に成功した場合に、リソース確保要求メッセージから抽出されたフロー識別情報と、ＤＳＣＰ決定部１２５で求められたＤＳＣＰ値とを含むＤＳＣＰ通知メッセージを作成し、通信ネットワーク２の入口ノードに送信する。発端末から着端末に通信する場合には、入口ノードとして発端末を収容するエッジノードに送信する。したがって、応答処理部１２３ＣはＤＳＣＰ値通知部として機能する。
【００７９】
リソース管理サーバ１ＣからのＤＳＣＰ通知メッセージを受信したエッジルータは、ＤＳＣＰ通知メッセージに付加された情報を抽出し、フロー識別情報とＤＳＣＰ値とを対応づけたアクセスリストテーブルを通信インターフェースのメモリに設定する。
【００８０】
その後、発端末から着端末宛にパケットを送信すると、このパケットを受信した上記エッジルータは、パケットのＩＰヘッダからフロー識別情報およびＤＳＣＰ値を抽出し、抽出したフロー識別情報をアクセスリストテーブルと照合する。アクセスリストテーブルの中に適合するフロー識別情報があった場合には、そのフロー識別情報に対応するＤＳＣＰ値と、抽出したＤＳＣＰ値とを比較する。２つのＤＳＣＰ値が同一の場合には、このＤＳＣＰ値に応じた優先制御で、次ホップのルータにパケットを送信する。例えばＤＳＣＰ値に対応する帯域を割り当ててパケットを送信する。これに対し、２つのＤＳＣＰ値が異なる場合には、パケットのＩＰヘッダのＴｏＳフィールドに、アクセスリストテーブルのＤＳＣＰ値を上書き設定し、このＤＳＣＰ値に応じた優先制御で次ホップのルータにパケットを送信する。
【００８１】
以上のように、本実施の形態では、リソース管理サーバ１Ｃにおいて、要求メッセージに関する情報に応じて決定された優先度に対応するＤＳＣＰ値を求め、このＤＳＣＰ値を通信ネットワーク２の入口ノードに設定することができる。これにより、リソース管理サーバ１Ｃで求めたＤＳＣＰ値で定義された振る舞いでパケットを転送することができる。
なお、リソース管理サーバ１Ｃの応答処理部１２３Ｃは、２以上の端末の間で双方向通信を行う場合には、通信ネットワーク２の入口ノードとして、それぞれの端末を収容するエッジノードにＤＳＣＰ通知メッセージを送信するものとする。これらに限らず、リソースを確保した経路上のいずれかのノード（ホームゲートウェイＨＧＷ、ポリシースイッチ（ポリシー設定を行うスイッチ）ＰＳＷなどのスイッチ類、エッジルータ、ゲートウェイルータ）にＤＳＣＰ通知メッセージを送信してもよい。
【００８２】
５．第５の実施の形態
本発明の第５の実施の形態にかかるリソース管理システムは、複数のリソース管理サーバを用いて通信ネットワークを分割管理するものである。
図１８は、本実施の形態にかかるリソース管理システムの全体構成を示すブロック図である。
このリソース管理システムは、複数のリソース管理サーバ２０１Ａ，２０１Ｂ，２０１Ｃを有する。リソース管理サーバ２０１Ａ，２０１Ｂ，２０１Ｃは、互いに接続された通信ネットワーク２０２Ａ，２０２Ｂ，２０２Ｃのリソースをそれぞれ管理する。通信ネットワーク２０２Ａ，２０２Ｂ，２０２Ｃは、それぞれ自律システムＡＳまたはそのサブシステムＳｕｂＡＳである。
【００８３】
リソース管理サーバ２０１Ａ，２０１Ｂ，２０１Ｃは、複数の通信ネットワークに跨る経路のリソースを管理するため、隣り合うリソース管理サーバの間で各種メッセージをやり取りする機能を有する。例えば、通信ネットワーク２０２Ａと２０２Ｂとに跨る経路のリソースを確保する場合には、通信ネットワーク２０２Ａを管理するリソース管理サーバ２０１Ａは、自己の管理範囲内におけるリソース確保処理終了後に、通信ネットワーク２０２Ｂを管理するリソース管理サーバ２０１Ｂに、リソース確保要求メッセージを送信する。
【００８４】
リソース確保要求メッセージを始めとする各種の要求メッセージには、第１の実施の形態において例示した情報の他に、リソース要求元サーバＩＰ、リソース要求先サーバＩＰ、ＭＡＣアドレス、リソース要求元サーバＩＤ、リソース要求先サーバＩＤ、リソース管理サーバＩＤ、リソース管理サーバＩＰ、リソース管理サーバのＨＯＰ数（連携数）、ＯＳＰＦ（Open Shortest Path First）のＡＳ番号またはＳｕｂＡＳ番号等の情報がさらに付加される。
【００８５】
ここで、リソース要求元サーバＩＰとは、発端末が属する通信ネットワークを管理するリソース管理サーバのＩＰアドレスである。例えば、発端末が通信ネットワーク２０２Ａに属する場合には、リソース管理サーバ２０１ＡのＩＰアドレスがリソース要求元サーバＩＰとなる。
リソース要求先サーバＩＰとは、着端末が属する通信ネットワークを管理するリソース管理サーバのＩＰアドレスである。例えば、着端末が通信ネットワーク２０２Ｃに属する場合には、リソース管理サーバ２０１ＣのＩＰアドレスがリソース要求先サーバＩＰとなる。
【００８６】
ＭＡＣアドレスとは、要求メッセージを送信するサーバのＭＡＣアドレスである。例えば、リソース管理サーバ２０１Ａ，２０１Ｂ，２０１Ｃによって管理される一連の経路のリソースを確保する場合に、リソース管理サーバ２０１Ａ，２０１Ｂによるリソース確保処理終了後にリソース管理サーバ２０１Ｂから２０１Ｃに送信されるリソース確保要求メッセージには、リソース管理サーバ２０１ＢのＭＡＣアドレスが付加される。
【００８７】
リソース要求元サーバＩＤとは、発端末が属する通信ネットワークを管理するリソース管理サーバの識別子である。リソース要求先サーバＩＤとは、着端末が属する通信ネットワークを管理するリソース管理サーバの識別子である。
【００８８】
リソース管理サーバＩＤとは、要求メッセージを送信するリソース管理サーバの識別子である。リソース管理サーバＩＰとは、要求メッセージを送信するリソース管理サーバのＩＰアドレスである。例えば、リソース管理サーバ２０１Ａ，２０１Ｂ，２０１Ｃによって管理される一連の経路のリソースを確保する場合に、リソース管理サーバ２０１Ａ，２０１Ｂによるリソース確保処理終了後にリソース管理サーバ２０１Ｂから２０１Ｃに送信されるリソース確保要求メッセージには、リソース管理サーバ２０１Ｂの識別子またはＩＰアドレスがそれぞれリソース管理サーバＩＤまたはリソース管理サーバＩＰとなる。
【００８９】
ＡＳ番号またはＳｕｂＡＳ番号とは、要求メッセージを送信するサーバが管理する通信ネットワークの番号である。例えば、リソース管理サーバ２０１Ａ，２０１Ｂ，２０１Ｃによって管理される一連の経路のリソースを確保する場合に、リソース管理サーバ２０１Ａ，２０１Ｂによるリソース確保処理終了後にリソース管理サーバ２０１Ｂから２０１Ｃに送信されるリソース確保要求メッセージには、通信ネットワーク２０２Ｂの番号が付加される。
【００９０】
なお、要求メッセージに付加される以上の全情報に対応するコード番号を、要求メッセージに付加することができる。例えば、初めて要求メッセージを送信するときに全情報とコード番号と付加し、以後コード番号のみを付加してもよい。この場合には、全情報を毎回付加する必要がなくなる。
【００９１】
リソース管理サーバ２０１Ａ，２０１Ｂ，２０１Ｃは、第１または第２の実施の形態にかかるリソース管理サーバ１，１Ａと同様に、要求メッセージに関する様々なポリシーによって受付番号を決定し、この受付番号の順に要求メッセージに応じた処理を行う機能を有する。ポリシーは、例えば上述した要求メッセージに付加される情報ごとに設定される。すなわち、ユーザＩＤ、アプリケーションＩＤ、サービス種別、要求種別、フロー識別情報、ＤＳＣＰ値、ＶＬＡＮＩＤの他、リソース要求元サーバＩＰ、リソース要求先サーバＩＰ、ＭＡＣアドレス、リソース要求元サーバＩＤ、リソース要求先サーバＩＤ、リソース管理サーバＩＤ、リソース管理サーバＩＰ、ＡＳ番号またはＳｕｂＡＳ番号等に設定される。
【００９２】
このようにポリシーを設定することにより、要求メッセージの送信元または送信先等に応じて優先的な処理が可能となる。例えば迅速な処理を求めるリソース管理サーバから送信される要求メッセージを優先的に処理し、処理時間を短縮することもできる。
【００９３】
なお、本発明では、要求メッセージにおけるＩＰｖ６ヘッダのフローラベルフィールドに対しても優先度を決めることができる。また、要求メッセージの任意のバイト位置を識別して優先度を決めることができる。例えば、ＩＰヘッダのｍByte目からｎByte目までを識別して優先度を決めることができる。さらに、要求メッセージに付加されたフロー識別情報における発端末ＩＰアドレス（ＩＰプレフィックスを含む）、着端末ＩＰアドレス（ＩＰプレフィックスを含む）、発ポート番号、着ポート番号、プロトコル番号の全通りの組合わせに対して、優先度を決めることができる。以上の優先度を決定する元となる情報のすべてが、要求メッセージに関する情報となる。
【産業上の利用可能性】
【００９４】
本発明は、例えば高品質の通信サービスを提供する分野に利用可能である。
【図面の簡単な説明】
【００９５】
【図１】本発明の第１の実施の形態にかかるリソース管理サーバが適用されるシステムの全体構成を示すブロック図である。
【図２】本発明の第１の実施の形態にかかるリソース管理サーバの機能ブロック図である。
【図３】ポリシーテーブルのデータ構造の一例を示す図である。
【図４】受付番号テーブルのデータ構造の一例を示す図である。
【図５】受付番号付与の基本的なアルゴリズムについて説明する図である。
【図６】キューの最終受付番号の変更について説明する図である。
【図７】リソース管理サーバによる全体的な処理の流れを示すフローチャートである。
【図８】情報受付番号算出の処理の流れを示すフローチャートである。
【図９】本発明の第２の実施の形態にかかるリソース管理サーバの機能ブロック図である。
【図１０】キューにおける要求メッセージの蓄積量がそのキューの制限量に達したときの処理の流れを説明する図である。
【図１１】ポリシーテーブルのデータ構造の他の例を示す図である。
【図１２】情報受付番号算出の処理の流れを示すフローチャートである。
【図１３】本発明の第３の実施の形態にかかるリソース管理サーバの機能ブロック図である。
【図１４】優先度対応テーブルのデータ構造の一例を示す図である。
【図１５】優先度対応テーブルのデータ構造の他の例を示す図である。
【図１６】本発明の第４の実施の形態にかかるリソース管理サーバの機能ブロック図である。
【図１７】ＤＳＣＰ変換テーブルのデータ構造の一例を示す図である。
【図１８】本発明の第５の実施の形態にかかるリソース管理システムの全体構成を示すブロック図である。
【符号の説明】
【００９６】
１，１Ａ〜１Ｃ，２０１Ａ〜２０１Ｃ…リソース管理サーバ、２，２０２Ａ〜２０２Ｃ…通信ネットワーク、３…アプリケーションサーバ、１１…送受信部、１２，１２Ａ〜１２Ｃ…制御部、１３，１３Ａ〜１３Ｃ…データベース部、１２１，１２１Ａ，１２１Ｂ…要求受付部、１２２…リソース処理部、１２３，１２３Ｃ…応答処理部、１２４…優先度決定部、１２５…ＤＳＣＰ決定部、１３１，１３１Ａ…ポリシーテーブル、１３２…受付番号テーブル、１３３Ａ〜１１３Ｄ…優先度対応テーブル、１３４…ＤＳＣＰ変換テーブル、Ｒ１〜Ｒ７…ルータ、Ｔ１〜Ｔ６…端末。
【図１】
0004444214.tif 000002
【図２】
0004444214.tif 000003
【図３】
0004444214.tif 000004
【図４】
0004444214.tif 000005
【図５】
0004444214.tif 000006
【図６】
0004444214.tif 000007
【図７】
0004444214.tif 000008
【図８】
0004444214.tif 000009
【図９】
0004444214.tif 000010
【図１０】
0004444214.tif 000011
【図１１】
0004444214.tif 000012
【図１２】
0004444214.tif 000013
【図１３】
0004444214.tif 000014
【図１４】
0004444214.tif 000015
【図１５】
0004444214.tif 000016
【図１６】
0004444214.tif 000017
【図１７】
0004444214.tif 000018
【図１８】
0004444214.tif 000019