JP2007214971A - リソース管理装置、通信システムおよび通信方法 - Google Patents

Abstract

【課題】リソース管理装置によって管理されるリソースの使用状況と実際のトラヒックの利用状況との齟齬をなくす。
【解決手段】リソース管理サーバ２は、リソース確保要求メッセージに付加されたフローの識別情報およびＤＳＣＰ値を抽出し（Ｓ３）、フローの経路についてリソース確保をした後（Ｓ４）、発端末Ｔ１を収容するルータＲ１に識別情報およびＤＳＣＰ値を送信する（Ｓ６）。ルータＲ１は、受信した識別情報およびＤＳＣＰ値を登録する（Ｓ７）。その後、発端末Ｔ１から着端末宛のパケットが送信されると（Ｓ１１）、ルータＲ１は、登録されている識別情報およびＤＳＣＰ値とパケットに含まれる識別情報およびＤＳＣＰ値とを比較し（Ｓ１２）、識別情報が一致しＤＳＣＰ値が異なる場合に（Ｓ１３，ＮＯ）、登録されているＤＳＣＰ値をパケットに上書きする（Ｓ１４）。
【選択図】 図９

Description

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

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

リソース管理サーバは、通信ネットワークにおけるパケットが通過する経路を特定する経路情報テーブルと、ルータ間のリンクの総リソース量および利用可能な残リソース量を管理するリソース情報テーブルとを有する。リソース管理サーバが有する経路情報テーブルは、それぞれのルータが有する経路情報テーブルと同じものである。

リソース管理サーバは、リソース確保要求を受け付けると、その受付順にリソース確保の処理を開始する。具体的には、次のような処理を行う。
まず、通信を行う発端末および着端末のＩＰアドレスを基に、経路情報テーブルから当該通信に必要となるリンクを特定する。そして、リンク情報テーブルを参照し、特定されたリンクのそれぞれについて当該通信に必要な容量が利用可能か否かをチェックする。
その結果、特定されたすべてのリンクについて十分な容量が利用可能である場合には、リソース確保が可能であると判定する。そして、リソース確保要求に対して許諾応答するとともに、リンク情報テーブルにおいて、特定されたリンクの残リソース量から当該通信に割り当てられる容量を減算する。逆に、いずれかのリンクについて利用可能な容量が不足する場合には、リソース確保が不可能であると判定し、リソース確保要求に対して拒絶応答する（例えば、特許文献１および非特許文献１を参照）。

リソース確保要求が許諾された後、発端末と着端末との間で通信ネットワークを介した通信を開始する。通信ネットワークを構成するルータはリソース管理サーバと同じ経路情報テーブルを有するので、発端末から送信されたパケットはリソース管理サーバによって通信に必要なリソースが確保された経路を通過することになる。したがって、リソース確保要求の許諾を受けて通信を行なうことによって、その通信の品質が保証される。

以上のリソース管理方式の他にも、様々なＱｏＳ技術が従来から実用化されている。その一つに「Ｄｉｆｆ−ｓｅｒｖ（Differentiated Services）方式」がある。Ｄｉｆｆ−ｓｅｒｖ方式では、パケットのＩＰヘッダに用意されたＴｏＳ（Type of Service）フィールドに優先度を示すＤＳＣＰ値（Differentiated Services Code Point）を設定し、パケットが通過する経路上のルータがＤＳＣＰ値によって示される優先度にしたがってバッファや帯域の割り当てを行うことで、優先度が高い通信の品質を確保する。通常、ＤＳＣＰ値は特定の通信ネットワークの入口で設定され、その優先度は発端末が提供するサービス毎に予め決められている（例えば、非特許文献２〜４を参照）。

特開２００３−２５８８５５号公報 矢口他、「大規模ＩＰ網における管理サーバを用いたリソース管理方式の一提案と具体例」、信学総合大会、Ｂ−６−３１（２００２） RFC2597 4. Queueing and Discard Behavior RFC2474 2. Terminology Used in This Document および 4.1 A Default PHB RFC2475 2.2 Differentiated Services Region

このように、Ｄｉｆｆ−ｓｅｒｖという優先制御の概念が提案されている。Ｄｉｆｆ−ｓｅｒｖではＤＳＣＰ値による通信ネットワーク内での振る舞いを定義しており、ＣＤＮサービスにおけるコンテンツ配信サーバのように、信頼できる端末から付与されたＤＳＣＰ値については信用し、通信ネットワーク内で指定された振る舞いでパケットを転送することができる。しかし、信用できない端末から付与されたＤＳＣＰ値については、誤った振る舞いをしないように、特定のネットワークの入口でＤＳＣＰ値の付け替えを行う必要がある。

ＤＳＣＰ値については、汎用のルータなどで設定する仕組みが用意されている。この場合、ＤＳＣＰ値を適用する対象として、５ｔｕｐｌｅ（発着端末のＩＰアドレス、発着ポート番号、プロトコル種別など）などと呼ばれる識別情報で区別できるフローと、フロー毎の振る舞いを予め設定する必要がある。しかし、不特定多数の端末間で通信を行い、端末が移動する昨今の環境では、上述したすべての情報をネットワークの入口で予めもつことは不可能であり、ＤＳＣＰ値の付け替えは普及していない。

不正なＤＳＣＰ値が付与されたパケットが優先的に転送されれば、正しいＤＳＣＰ値が付与されたパケットの転送が阻害され、ときには廃棄される。その結果、リソース管理サーバによって確保されているはずのリソースが保証されず、リソース管理サーバによって管理されるリソースの使用状況と実際のトラヒックの利用状況とが整合しないという問題があった。

本発明は、このような課題を解決するためになされたものであり、その目的は、Ｄｉｆｆ−ｓｅｒｖの問題点を改善し、リソース管理サーバによって管理されるリソースの使用状況と実際のトラヒックの利用状況との齟齬をなくすことにある。

このような目的を達成するために、本発明にかかるリソース管理装置は、通信を行う発端末と着端末との間のフローを識別する識別情報とフローのＤＳＣＰ値とが付加された、リソース確保を要求する要求メッセージを受信するメッセージ受信手段と、受信された要求メッセージから識別情報およびＤＳＣＰ値を抽出する情報抽出手段と、抽出された識別情報に基づいてフローを特定するフロー特定手段と、特定されたフローの経路についてリソース確保を行う確保処理手段と、リソース確保された経路上のいずれかのノードに、抽出された識別情報およびＤＳＣＰ値を送信する情報送信手段とを備えることを特徴とする。

ここで、識別情報は、発端末のＩＰプレフィックスを含むＩＰアドレス、着端末のＩＰプレフィックスを含むＩＰアドレス、プロトコル番号、発ポート番号および着ポート番号を含み、ＤＳＣＰ値は、発端末のＩＰアドレス、着端末のＩＰアドレス、プロトコル番号、発ポート番号および着ポート番号のすべての組合わせに対して決定されるものであってもよい。
また、上述したリソース管理装置は、特定されたフローと抽出されたＤＳＣＰ値とを対応づけて記憶する記憶手段をさらに備えるものであってもよい。
また、確保処理手段は、抽出されたＤＳＣＰ値に基づく順番にリソース確保を行うものであってもよい。

また、本発明にかかる他のリソース管理装置は、複数のノードを含む通信ネットワークを分割した複数の管理範囲ごとに設けられ、通信ネットワークのリソースに関するメッセージを互いに送受信し、このメッセージに基づいてそれぞれの管理範囲内におけるリソース確保を行うリソース管理装置であって、通信を行う発端末と着端末との間のフローを識別する識別情報とフローのＤＳＣＰ値とが付加された、リソース確保を要求する要求メッセージを受信するメッセージ受信手段と、受信された要求メッセージから識別情報およびＤＳＣＰ値を抽出する情報抽出手段と、抽出された識別情報に基づいて、自装置の管理範囲内におけるフローを特定するフロー特定手段と、特定されたフローの経路についてリソース確保を行う確保処理手段と、リソース確保された経路上のいずれかのノードに、抽出された識別情報およびＤＳＣＰ値を送信する情報送信手段とを備えることを特徴とする。

このリソース管理装置は、リソース確保に成功したときに、リソース確保要求を許可する旨の応答メッセージを要求メッセージの送信元に送信するメッセージ送信手段をさらに備えるものであってもよい。
また、抽出されたＤＳＣＰ値を修正するＤＳＣＰ値修正手段をさらに備え、メッセージ送信手段は、ＤＳＣＰ値修正手段によりＤＳＣＰ値が修正されたときには、修正後のＤＳＣＰ値を応答メッセージに付加するものであってもよい。

また、メッセージ送信手段は、着端末が自装置の管理範囲内に属しない場合に、自装置の管理範囲と管理範囲が隣接する他のリソース管理装置に要求メッセージを送信し、メッセージ受信手段は、他のリソース管理装置からの応答メッセージを受信するものであってもよい。
また、情報送信手段は、受信された応答メッセージに修正後のＤＳＣＰ値が付加されている場合に、修正後のＤＳＣＰ値を自装置の管理範囲と他のリソース管理装置の管理範囲との境界にあるノードに送信するものであってもよい。

また、本発明にかかる通信システムは、通信ネットワークを構成する複数のノードと、通信ネットワークのリソース確保を行なうリソース管理装置とを備え、リソース管理装置は、通信を行う発端末と着端末との間のフローを識別する識別情報とフローのＤＳＣＰ値とが付加された、リソース確保を要求する要求メッセージを受信するメッセージ受信手段と、受信された要求メッセージから識別情報およびＤＳＣＰ値を抽出する情報抽出手段と、抽出された識別情報に基づいてフローを特定するフロー特定手段と、特定されたフローの経路についてリソース確保を行う確保処理手段と、リソース確保された経路上のいずれかのノードに、抽出された識別情報およびＤＳＣＰ値を送信する情報送信手段とを備えることを特徴とする。

また、ルータは、リソース管理装置から送信された識別情報およびＤＳＣＰ値を受信する情報受信手段と、受信された識別情報とＤＳＣＰ値とを対応づけて記憶する情報記憶手段と、パケットを受信するパケット受信手段と、受信されたパケットに含まれる識別情報およびＤＳＣＰ値と情報記憶手段に記憶されている識別情報およびＤＳＣＰ値とを比較し、識別情報が一致しＤＳＣＰ値が異なる場合に、パケットのＤＳＣＰ値を情報記憶手段に記憶されているＤＳＣＰ値に書き換えるＤＳＣＰ値管理手段とを備えるものであってもよい。

また、本発明にかかる通信方法は、リソース管理装置において、通信を行う発端末と着端末との間のフローを識別する識別情報とフローのＤＳＣＰ値とが付加された、リソース確保を要求する要求メッセージを受信するステップと、受信された要求メッセージから識別情報およびＤＳＣＰ値を抽出するステップと、抽出された識別情報に基づいてフローを特定するステップと、特定されたフローの経路についてリソース確保を行うステップと、リソース確保された経路上のいずれかのノードに、抽出された識別情報およびＤＳＣＰ値を送信するステップとを備えることを特徴とする。

さらに、ルータにおいて、リソース管理装置から送信された識別情報およびＤＳＣＰ値を受信するステップと、受信された識別情報とＤＳＣＰ値とを対応づけて情報記憶手段に記憶するステップと、パケットを受信するステップと、受信されたパケットに含まれる識別情報およびＤＳＣＰ値と情報記憶手段に記憶されている識別情報およびＤＳＣＰ値とを比較し、識別情報が一致しＤＳＣＰ値が異なる場合に、パケットのＤＳＣＰ値を情報記憶手段に記憶されているＤＳＣＰ値に書き換えるステップとを備えるものであってもよい。

また、本発明にかかる他の通信方法は、複数のノードを含む通信ネットワークを分割した複数の管理範囲ごとリソース管理装置を設け、それぞれのリソース管理装置の間で通信ネットワークのリソースに関するメッセージを送受信し、このメッセージに基づいてそれぞれの管理範囲内におけるリソース確保を行うリソース管理方法であって、一のリソース管理装置において、通信を行う発端末と着端末との間のフローを識別する識別情報とフローのＤＳＣＰ値とが付加された要求メッセージを受信するステップと、受信した要求メッセージから識別情報およびＤＳＣＰ値を抽出するステップと、着端末が自装置の管理範囲に属しない場合に、自装置の管理範囲と管理範囲が隣接する他のリソース管理装置に要求メッセージを送信するステップと、他のリソース管理装置から修正後のＤＳＣＰ値が付加された応答メッセージを受信するステップと、修正後のＤＳＣＰ値を自装置の管理範囲と他のリソース管理装置の管理範囲との境界にあるノードに送信するステップとを備えることを特徴とする。

本発明では、リソース管理装置によってフローの経路についてリソース確保が行われたときに、この経路上のノードに、フローの識別情報およびＤＳＣＰ値を送信する。したがって、通信ネットワークの入口となり得るすべてのノードでフローの識別情報およびＤＳＣＰ値を予めもっていなくても、信用できない端末から付与されたＤＳＣＰ値の付け替えを行うことができる。これにより、リソース管理サーバによって管理されるリソースの使用状況と実際のトラヒックの利用状況との齟齬をなくすことができる。

以下、図面を参照し、本発明の実施の形態について詳細に説明する。
１．第１の実施の形態
［通信システムの全体構成］
図１は、本発明の第１の実施の形態にかかる通信システムの全体構成を示すブロック図である。
図１に示す通信システムは、インターネットプロトコル（ＩＰ）に基づく通信ネットワーク１と、通信ネットワーク１のリソースを管理するリソース管理サーバ（リソース管理装置）２と、通信ネットワーク１に接続可能な端末Ｔ（Ｔ１〜Ｔ６）と、端末Ｔからの要求を受け付けてリソース管理サーバ２に橋渡しするアプリケーションサーバ３とを有する。

通信ネットワーク１は、ルータＲ（Ｒ１〜Ｒ７）や交換機（図示せず）、ＬＡＮスイッチ（図示せず）などの複数のノードと、ノード間を接続するリンクとから構成される。この通信ネットワーク１のリソースとは、通信を行う２つの端末間の経路を構成するリンクにおいて、課金によって所定時間払い出される容量のことをいう。連続課金によって容量の払い出しを継続することができる。

アプリケーションサーバ３は、端末Ｔまたはリソース管理サーバ２との間で各種メッセージを送信および受信する。具体的には、端末Ｔから送信されるリソース確保サービスの利用要求メッセージ（以下「サービス利用要求メッセージ」という）を受信し、このメッセージのフォーマットを変換したリソース確保要求メッセージをリソース管理サーバ２に送信する。また、リソース確保要求メッセージに対してリソース管理サーバ２から送信される応答メッセージを受信し、このメッセージのフォーマットを変換したメッセージを端末Ｔに送信する。より詳しく言えば、リソース管理サーバ２からリソース確保に成功した旨の応答メッセージを受信したときには、端末Ｔにリソース確保サービスの利用許可メッセージを送信し、リソース確保に失敗した旨の応答メッセージを受信したときには、リソース確保サービスの利用拒絶メッセージを送信する。

端末Ｔから送信されるサービス利用要求メッセージには、ユーザの識別子（ユーザＩＤ）、フローを識別する情報（以下「フロー識別情報」という）、このフローのＤＳＣＰ値、要求リソース量などの情報が付加される。フローは、５ｔｕｐｌｅ（発着端末のＩＰアドレス（ＩＰプレフィックスを含む）、発着ポート番号、プロトコル種別など）などと呼ばれる識別情報によって区別される。フローのＤＳＣＰ値は、発着端末のＩＰアドレス、発着ポート番号、プロトコル種別のすべての組合わせに対して決定される。サービス利用要求メッセージに付加された各種情報は、リソース確保要求メッセージにも付加される。

なお、ＤＳＣＰ値はアプリケーションサーバ３において適宜付加することができるので、サービス利用要求メッセージにＤＳＣＰ値が付加されない場合もある。
図１では、アプリケーションサーバ３は、通信ネットワーク１の入口となるルータＲ１に接続されているが、ルータＲ１と端末Ｔ１との間に接続された他のルータやスイッチに接続されていてもよい。

［リソース管理サーバの構成］
図２は、リソース管理サーバ２の機能ブロック図である。
このリソース管理サーバ２は、送受信部２１と、制御部２２と、データベース部２３とを有する。
ここで、送受信部２１は、通信インターフェースを備え、アプリケーションサーバ３との間で各種メッセージを送信および受信する。また、通信ネットワーク１を構成するルータＲに、後述するメッセージを送信する。

制御部２２は、アプリケーションサーバ３からのリソース確保要求メッセージに応じて、通信ネットワーク１のリソースを確保する処理を行う。具体的には、要求受付部２２１と、リソース処理部２２２と、メッセージ作成部２２３とを有する。
要求受付部２２１は、リソース確保要求メッセージに付加された各種情報を抽出し、抽出した情報の一つであるＤＳＣＰ値に基づいてリソース確保要求メッセージに対し受付番号を付与する。

リソース処理部２２２は、受付番号が小さい方から順にリソース確保処理を行う。すなわち、リソース確保要求メッセージから抽出されたフロー識別情報から発端末と着端末との間のフローを特定し、特定したフローの経路において必要な容量が確保可能か否かを判定し、確保可能である場合には必要な容量のリソースを確保する。したがって、リソース処理部２２２は、フロー特定部およびリソース確保処理部として機能する。

メッセージ作成部２２３は、リソース確保要求を許可または拒絶する旨の応答メッセージを作成し、送受信部２１を介してアプリケーションサーバ３に送信する。さらに、リソース確保に成功した場合には、リソース確保要求メッセージから抽出されたフロー識別情報およびＤＳＣＰ値を含む優先度通知メッセージを作成し、送受信部２１を介して発端末を収容するエッジルータに送信する。発端末と着端末との間で双方向通信を行う場合には、発端末を収容するエッジルータと着端末を収容するエッジルータの両方に優先度通知メッセージを送信する。これらに限らず、リソースを確保した経路上のいずれかのノード（ホームゲートウェイＨＧＷ、ポリシースイッチ（ポリシー設定を行うスイッチ）ＰＳＷなどのスイッチ類、エッジルータ、ゲートウェイルータ）に優先度通知メッセージを送信してもよい。

データベース部２３は、上述した制御部２２による処理に必要な各種情報を記憶する。具体的には、従来から用いられている経路情報テーブルおよびリンク情報テーブルの他に、以下のキューテーブル、受付番号テーブルおよびアクセスリストテーブルを記憶する。

アクセスリストテーブルは、リソース確保された発端末と着端末との間のフローと、このフローに設定されたＤＳＣＰ値とを対応づけたテーブルである。例えば図３に示すアクセスリストテーブル２３１は、フロー識別情報としての「発端末ＩＰアドレス」、「着端末ＩＰアドレス」、「ポート番号」および「プロトコル番号」と、フロー識別情報により特定されるフローの「ＤＳＣＰ値」という項目からなる。これらの情報は、リソース確保に成功したときに、リソース処理部２２２により登録される。

キューテーブルは、リソース確保要求メッセージの待ち行列（キュー）の管理に用いられるテーブルである。例えば図４に示すキューテーブル２３２は、「ＤＳＣＰ値」、「最終受付番号」、「制限量」および「蓄積量」という項目からなる。
「最終受付番号」とは、同じＤＳＣＰ値が付加された要求メッセージのキューの最終受付番号である。原則として、各キューに属する最後の要求メッセージの受付番号である。例えば、キューに２つの要求メッセージが属している場合には、２番目の要求メッセージの受付番号が最終受付番号となる。
「制限量」とは、キューの個別容量であり、それぞれのキューで蓄積可能な要求メッセージの数を表す。
「蓄積量」とは、その時点でキューに蓄積されている要求メッセージの数を表す。
なお、キューテーブル２３２の制限量等の情報が外部記憶装置に記録されている場合には、これらの情報をリソース管理サーバ２の起動時に読み込むこともできるし、起動後に読み込み途中変更することもできる。

受付番号テーブルは、リソース確保要求メッセージの受付番号の管理に用いられるテーブルである。例えば図５に示す受付番号テーブル２３３のように、「要求ＩＤ」および「受付番号」という項目からなる。
「要求ＩＤ」とは、要求メッセージに個別に付与された識別子である。
「受付番号」とは、要求ＩＤによって表される要求メッセージに付与された受付番号である。

［受付番号付与のアルゴリズム］
次に、図６および図７を参照し、要求受付部２２１による受付番号付与のアルゴリズムについて説明する。図６および図７は、ＤＳＣＰ値が１０，３０，５０のリソース確保要求メッセージのキュー（以下「ＤＳＣＰ値が１０，３０，５０のキュー」と略記する）を概念的に示す図である。

まず、図６を参照し、受付番号付与の基本的なアルゴリズムについて説明する。
ＤＳＣＰ値５０の要求メッセージ１が受信されたとき、要求受付部２２１はこの要求メッセージ１をＤＳＣＰ値５０のキューに振り分ける。このときＤＳＣＰ値５０のキューは空であるから、このキューの最終受付番号は「０」である。この最終受付番号「０」にＤＳＣＰ値「５０」を加算した値「５０」を、要求メッセージ１の受付番号とする。
その後、続いてＤＳＣＰ値３０の要求メッセージ２、ＤＳＣＰ値１０の要求メッセージ３が受信されたときにも、同様にしてそれぞれの受付番号を「３０」、「１０」とする。

さらにその後、ＤＳＣＰ値５０の要求メッセージ４が受信されたとき、要求受付部２２１はこの要求メッセージ４を再びＤＳＣＰ値５０のキューに振り分ける。このときＤＳＣＰ値５０のキューには最初の要求メッセージ１が蓄積されており、この要求メッセージ１の受付番号「５０」がキューの最終受付番号となっている。したがって、キューの最終受付番号「５０」にＤＳＣＰ値「５０」を加算した値「１００」を、要求メッセージ４の受付番号とする。

その結果、キューテーブル２３２の「最終受付番号」および受付番号テーブル２３３の「受付番号」は、それぞれ図４および図５に示すようになる。
リソース処理部２２２は、受付番号が小さいメッセージから順に処理を行うので、要求メッセージ３→要求メッセージ２→要求メッセージ１→要求メッセージ４の順にリソース確保の処理が行われることになる。

以上のように、本実施の形態では、受信された要求メッセージのＤＳＣＰ値をそのキューの最終受付番号に加算し、これにより得られた値を要求メッセージの受付番号とする。この場合には、優先度が高くＤＳＣＰ値が小さい要求メッセージは受付番号が小さくなり、処理の開始が早くなる。これに対し、優先度が低くＤＳＣＰ値が大きい要求メッセージは受付番号が大きくなり、処理の開始が遅くなる。

次に、図７を参照し、キューの最終受付番号の変更について説明する。
図６で説明したように要求メッセージ１〜４について受付番号が付与された後、要求メッセージ３，２，１についての処理が開始されると、その時点でこれらの要求メッセージ１〜３はそれぞれのキューから削除される。これにより、最終受付番号「０」を基準にして受付番号を決定した要求メッセージ１〜３が、すべて削除されたことになる。このままＤＳＣＰ値１０，３０のキューの最終受付番号を「０」のままにしておき、この最終受付番号を基準にした受付番号の決定を続けると、すでに受付番号が決定された要求メッセージ４が不利に扱われる場合がある。

そこで、本実施の形態では、最終受付番号「０」を基準にして受付番号を決定した要求メッセージ１〜３がすべてキューから削除された時点で、図７に示すように、ＤＳＣＰ値１０，３０，５０のキューの最終受付番号を、未処理の要求メッセージ４の受付番号の基準となった要求メッセージ１の受付番号「５０」に変更する。

このような最終受付番号の変更を行った後で、図７に示すようにＤＳＣＰ値３０の要求メッセージ５が受信されると、要求受付部２２１はこの要求メッセージ５をＤＳＣＰ値３０のキューに振り分け、このキューの最終受付番号「５０」にＤＳＣＰ値「３０」を加算した値「８０」を要求メッセージ５の受付番号とする。
この場合には、要求メッセージ４よりも要求メッセージ５の方が受付番号が小さいので、要求メッセージ５から先にリソース確保の処理が行われることになる。
なお、すべての要求メッセージが処理され、すべてのキューが空になった場合には、すべてのキューの最終受付番号を「０」に戻す。

なお、本実施の形態では、それぞれのキューに順位付けがなされている。受付番号が同じになった要求メッセージについては、順位が高いキューに属する要求メッセージから先に処理を行うものとする。例えば、ＤＳＣＰ値１０，３０，５０のキューの順位がそれぞれ１，２，３の場合には、ＤＳＣＰ値１０のキューに属する要求メッセージから順に処理が行われることになる。

［ルータの構成］
図８は、ルータＲの機能ブロック図である。
このルータＲは、送受信部４１と、データベース部４２と、解析部４３と、ヘッダ設定部４４とを有する。
ここで、送受信部４１は、通信インターフェースを備え、当該ルータＲが収容する端末または隣接する別のルータから送信されたパケットを受信する受信機能と、受信したパケットを次ホップのルータまたは当該ルータが収容する端末に送信する送信機能とを有する。また、リソース管理サーバ２から送信される優先度通知メッセージも、リソース管理サーバ２から直接、または別のルータを経由して受信することができる。

データベース部４２は、リソース管理サーバ２が保持する経路情報テーブルと同一の経路情報テーブルと、アクセスリストテーブルとを記憶する。アクセスリストテーブルには、リソース管理サーバ２に保持されているアクセスリストテーブルの中で、当該ルータＲに収容された端末ＴのＩＰアドレスが発端末ＩＰアドレスまたは着端末ＩＰアドレスとなっているデータが登録される。

解析部４３は、リソース管理サーバ２からの優先度通知メッセージに付加されたフロー識別情報およびＤＳＣＰ値を抽出し、データベース部４２のアクセスリストテーブルに登録する。また、送受信部４１の通信インターフェースのメモリ（情報記憶部）にアクセスリストテーブルを読み出す。

ヘッダ設定部４４は、パケットのＩＰヘッダからフローに関する情報を取得し、通信インターフェースに読み出されたアクセスリストテーブルと照合する。取得した情報がアクセスリストテーブルの情報と適合する場合には、さらに、ＩＰヘッダのＴｏＳフィールドに設定されたＤＳＣＰ値とアクセスリストテーブルのＤＳＣＰ値とを比較する。２つのＤＳＣＰ値が異なる場合には、ＩＰヘッダのＴｏＳフィールドに、アクセスリストテーブルのＤＳＣＰ値を上書き設定する。したがって、ヘッダ設定部４４は、ＤＳＣＰ値管理部として機能する。

［通信システムの動作］
次に、図９および図１０を参照し、通信に必要なリソースの確保から当該通信を行なうまでの処理について説明する。ここでは、端末Ｔ１から端末Ｔ６に通信する場合を例にして説明する。図９は、全体的な処理の流れを示すシーケンス図である。図１０は、リソース管理サーバ２によるリソース確保の処理の流れをより詳しく示すフローチャートである。

端末Ｔ１が端末Ｔ６に通信するにあたって、端末Ｔ１はまず、リソース確保サービスの利用要求メッセージをアプリケーションサーバ３に送信する（図９，ステップＳ１）。このメッセージには、フロー識別情報（発着端末である端末Ｔ１，Ｔ６のＩＰアドレス、発着ポート番号、プロトコル番号）、フローのＤＳＣＰ値、通信に必要な要求リソース量が付加される。
端末Ｔ１からのサービス利用要求メッセージを受信したアプリケーションサーバ３は、受信されたサービス利用要求メッセージをリソース管理サーバ２で読取可能な形式のリソース確保要求メッセージに変換し、リソース管理サーバ２に送信する（図９，ステップＳ２）。

アプリケーションサーバ３からのリソース確保要求メッセージを受信したリソース管理サーバ２では、まず要求受付部２２１が、リソース確保要求メッセージからフロー識別情報、ＤＳＣＰ値、要求リソース量を抽出する（図９，ステップＳ３）。なお、ここでＤＳＣＰ値を修正する場合もある。
ついで、要求受付部２２１およびリソース処理部２２２が、抽出したＤＳＣＰ値に基づく順番にリソース確保の処理を行う（図９，ステップＳ４）。この処理の詳細について、図１０を参照して説明する。

ここで、抽出したＤＳＣＰ値が例えば「３０」であったとすると、要求受付部２２１は、図４に示したキューテーブル２３２を参照し、ＤＳＣＰ値３０のキューに空きがあるか否かをチェックする（図１０，ステップＳ４１）。ＤＳＣＰ値３０のキューの蓄積量が制限量に達していない場合には、このキューに空きがあると判断し、蓄積量が制限量に達している場合には空きがないと判断することができる。

ＤＳＣＰ値３０のキューに空きがある場合には（図１０，ステップＳ４１のＹＥＳ）、要求受付部２２１は、受信されたリソース確保要求メッセージをＤＳＣＰ値３０のキューに蓄積する。具体的には、キューテーブル２３２におけるＤＳＣＰ値３０のキューの蓄積量に１を加算すればよい。また、キューテーブル２３２からＤＳＣＰ値３０のキューの最終受付番号「３０」を読み出し、この最終受付番号「３０」にＤＳＣＰ値「３０」を加算した値「６０」をリソース確保要求メッセージの受付番号とする（図１０，ステップＳ４２）。このとき、リソース確保要求メッセージに要求ＩＤを付与し、この要求ＩＤとともに受付番号を図５に示した受付番号テーブル２３３に書き込む。また、キューテーブル２３２におけるＤＳＣＰ値３０のキューの最終受付番号を「３０」から「６０」に書き換える。

これに対し、ＤＳＣＰ値３０のキューに空きがない場合には（図１０，ステップＳ４１のＮＯ）、要求受付部２２１は、ＤＳＣＰ値が「３０」のリソース確保要求メッセージを受け付けられないと判断する（図１０，ステップＳ４３）。この場合には、メッセージ作成部２２３がリソース確保要求を拒絶する旨の応答メッセージを作成し、この応答メッセージをアプリケーションサーバ３を経由して端末Ｔ１に送信する（図１０，ステップＳ４４）。このような処理を行うことにより、ＤＳＣＰ値３０のリソース確保要求メッセージが集中した場合でも、その一部を拒絶し、リソース管理サーバ２の処理能力を例えばＤＳＣＰ値５０等の他のＤＳＣＰ値のリソース確保要求メッセージの処理に振り分け、そのメッセージの処理が滞ることを防止できる。
なお、リソース確保要求メッセージから抽出したＤＳＣＰ値が「３０」以外の値である場合にも、同様に処理できることは言うまでもない。

リソース処理部２２２は、受付番号テーブル２３３を参照し、受付番号が小さい要求ＩＤに対応するリソース確保要求メッセージから順に、リソース確保の処理を行なう（ステップＳ４５）。このリソース確保の処理は従来と同じであるから、その詳細な説明は省略する。

リソース確保に成功した場合には、リソース処理部２２２は、図９のステップＳ３でリソース確保要求メッセージから抽出されたフロー識別情報およびＤＳＣＰ値を、データベース部２３のアクセスリストテーブル２３１に登録する（図９，ステップＳ５）。
また、メッセージ作成部２２３が、上記フロー識別情報およびＤＳＣＰ値を付加した優先度通知メッセージを作成し、このメッセージを発端末である端末Ｔ１を収容するルータＲ１に送信する（図９，ステップＳ６）。

リソース管理サーバ２からの優先度通知メッセージを受信したルータＲ１では、解析部４３が、優先度通知メッセージに付加された情報を抽出し、データベース部４２のアクセスリストテーブルに登録し、送受信部４１の通信インターフェースのメモリにアクセスリストテーブルを読み出す（図９，ステップＳ７）。また、アクセスリストテーブルへの登録に成功した旨を示す登録通知メッセージを作成し、リソース管理サーバ２に送信する（図９，ステップＳ８）。

ルータＲ１からの登録通知メッセージを受信したリソース管理サーバ２では、メッセージ作成部２２３が、リソース確保要求を許可する旨のリソース確保応答メッセージを作成し、このメッセージをアプリケーションサーバ３に送信する（図９，ステップＳ９）。アプリケーションサーバ３は、リソース確保応答メッセージを受信すると、リソース確保サービスの利用を許可する旨のサービス利用許可メッセージを端末Ｔ１に送信する（図９，ステップＳ１０）。

この後、サービス利用許可メッセージを受信した端末Ｔ１とＴ６との間で、通信が開始される。端末Ｔ１は、ＩＰヘッダに発着端末のＩＰアドレス等のフロー識別情報を設定し、ＩＰヘッダのＴｏＳフィールドにＤＳＣＰ値を設定したパケットを送信する（図９，ステップＳ１１）。

端末Ｔ１から送信されたパケットは、端末Ｔ１を収容するルータＲ１によって受信される。このパケットを受信したルータＲ１では、ヘッダ設定部４４が、端末Ｔ１からのパケットのＩＰヘッダからフロー識別情報を抽出する。そして、抽出したフロー識別情報を、通信インターフェースに読み出されているアクセスリストテーブルと照合する。アクセスリストテーブルの中に適合するフロー識別情報があった場合には、そのフロー識別情報に対応するＤＳＣＰ値と、抽出したＤＳＣＰ値とを比較する（図９，ステップＳ１２）。２つのＤＳＣＰ値が同一の場合には（図９，ステップＳ１３，ＹＥＳ）、このＤＳＣＰ値に応じた優先制御で、次ホップのルータ（ここではルータＲ４とする）にパケットを送信する（図９，ステップＳ１５）。例えばＤＳＣＰ値（優先度）に対応する帯域を割り当ててパケットを送信する。

これに対し、２つのＤＳＣＰ値が異なる場合には（図９，ステップＳ１３，ＮＯ）、パケットのＩＰヘッダのＴｏＳフィールドに、アクセスリストテーブルのＤＳＣＰ値を上書き設定し（図９，ステップＳ１４）、このＤＳＣＰ値に応じた優先制御でルータＲ４にパケットを送信する（図９，ステップＳ１５）。
なお、図９のステップＳ１２における照合の結果、アクセスリストテーブルの中に適合するフロー識別情報がなかった場合には、端末Ｔ１からのパケットを廃棄する。あるいは、ベストエフォートで非優先的に当該ルータＲ１を通過させることもできる。

これ続いて、端末Ｔ１から端末Ｔ６に同一フローの次のパケットが送信された場合にも、このパケットに対してルータＲ１は同様の処理を行う。

以上のように、本実施の形態では、リソース管理サーバ２において端末Ｔ１とＴ６との間のフローの経路についてリソース確保が行われたときに、通信ネットワーク１の入口となるルータＲ１にフロー識別情報およびＤＳＣＰ値を付加した優先度通知メッセージを送信する。これにより、ルータＲ１は、リソース管理サーバ２によってリソース確保されたフローの識別情報およびＤＳＣＰ値を取得することができる。

ここでは、端末Ｔ１から端末Ｔ６に通信する場合について説明したが、端末同士で双方向通信する場合にも本発明を適用することができる。この場合には、リソース管理サーバ２が、双方向通信を行う端末を収容するそれぞれのルータＲに対して優先度通知メッセージを送信することにより、それぞれのルータＲがリソース確保されたフローの識別情報およびＤＳＣＰ値を取得することができる。

したがって、本実施の形態では、通信ネットワーク１の入口となり得るすべてのルータＲでフローの識別情報およびＤＳＣＰ値を予めもっていなくても、信用できない端末から付与されたＤＳＣＰ値を付け替えることができる。これにより、不正なＤＳＣＰ値が付与されたパケットが優先的に転送され、正しいＤＳＣＰ値が付与されたパケットの転送が阻害されることや廃棄されることを防止することができる。したがって、リソース管理サーバ２によって確保されているリソースを保証し、リソース管理サーバ２によって管理されるリソースの使用状況と実際のトラヒックの利用状況とを整合させることができる。

また、本実施の形態では、リソース確保要求メッセージにＤＳＣＰ値を付加し、リソース管理サーバ２においてリソース確保要求メッセージからＤＳＣＰ値を抽出しこのＤＳＣＰ値に基づく順番にリソース確保の処理を行う。これにより、リソース確保要求メッセージが送られてきた順番ではなく、ＤＳＣＰ値によって表される優先度の高いメッセージから順にリソース確保の処理を行うことができる。

２．第２の実施の形態
次に、本発明の第２の実施の形態について説明する。この形態は、端末からアプリケーションサーバへのサービス利用要求メッセージを用いず、端末間での通信に用いられるパケットから必要な情報を取得してＤｉｆｆ−ｓｅｒｖを行うものである。

図１１は、本実施の形態におけるアプリケーションサーバの機能ブロック図である。
アプリケーションサーバ１０３は、発端末と通信ネットワーク１の入口との間に介在する。ここでは、発端末を端末Ｔ１、通信ネットワーク１の入口をルータＲ１とする。このアプリケーションサーバ１０３は、送受信部１３１と、情報抽出部１３２と、制御部１３３と、データベース部１３４とを有する。

ここで、送受信部１３１は、発端末である端末Ｔ１から着端末に送信されるパケットをルータＲ１に転送する。また、リソース管理サーバ２との間で各種メッセージの送信および受信を行う。
データベース部１３４はアクセスリストテーブルを記憶する。このアクセスリストテーブルは、発端末である端末Ｔ１と着端末との間のフローの識別情報と、このフローに設定されたＤＳＣＰ値とを対応づけたテーブルである。データベース部１３４はまた、登録ユーザに対して予め決められた要求リソース量を記憶する。登録ユーザの識別子として、発端末ＩＰアドレスを用いることができる。

情報抽出部１３２は、発端末である端末Ｔ１からのパケットのＩＰヘッダから、フロー識別情報およびＤＳＣＰ値を抽出する。
制御部１３３は、発端末である端末Ｔ１からのパケットのフローが初めてのフローの場合に、このフローに必要なリソースの確保を要求するリソース確保要求メッセージを作成し、リソース管理サーバに送信する。また、リソース管理サーバからリソース確保要求を許可する旨の応答メッセージがあったときに、情報抽出部１３２によりパケットから抽出されたフロー識別情報およびＤＳＣＰ値をデータベース部１３４のアクセスリストテーブルに登録するとともに、登録したデータを送受信部１３１の通信インターフェースのメモリ上に読み出す。

次に、図１２を参照し、通信に必要なリソースの確保から当該通信を行なうまでの処理について説明する。図１２は、全体的な処理の流れを示すシーケンス図である。ここでは、端末Ｔ１から端末Ｔ６に通信を行う場合を例にして説明する。
端末Ｔ１は端末Ｔ６宛のパケットをアプリケーションサーバ１０３に送信する（ステップＳ１０１）。パケットのＩＰヘッダには、フロー識別情報およびＤＳＣＰ値が設定されている。

端末Ｔ１からのパケットを受信したアプリケーションサーバ１０３では、情報抽出部１３１が、パケットのＩＰヘッダからフロー識別情報およびＤＳＣＰ値を抽出する（ステップＳ１０２）。
制御部１３３は、このパケットのフローが初めのフローであるか否かを判定する。例えば、情報抽出部１３１によって抽出されたフロー識別情報が通信インターフェースのメモリ上にない場合には、初めてのフローであると判定することができる（ステップＳ１０３）。初めてのフローの場合には、パケットの発端末ＩＰアドレスに対応する要求リソース量をデータベース部１３４から読み出し（ステップＳ１０４）、このリソース量とフロー識別情報およびＤＳＣＰ値とを付加したリソース確保要求メッセージを作成し、送受信部１３１からリソース管理サーバに送信する（ステップＳ１０５）。

リソース確保要求メッセージを受信したリソース管理サーバは、リソース確保が可能かどうかを判定する。この判定には、端末Ｔ１のユーザが不正ユーザでないかどうかの判定も含まれる。リソース確保が可能な場合には、リソース確保処理を行い（ステップＳ１０６）、リソース確保要求を許可する旨のリソース確保応答メッセージをアプリケーションサーバ１０３に送信する（ステップＳ１０７）。リソース確保処理において、ＤＳＣＰ値を修正する場合もある。

リソース確保応答メッセージを受信したアプリケーションサーバ１０３では、制御部１３３が、ステップＳ１０２で抽出されたフロー識別情報およびＤＳＣＰ値を、データベース部１３４のアクセスラインテーブルに登録する。さらに、登録したデータを送受信部１３１の通信インターフェースのメモリ上に読み出し、パケットのエントリールールとする（ステップＳ１０８）。その後、送受信部１３１が、ステップＳ１０１で端末Ｔ１から送信されたパケットを、ルータＲ１に送信する（ステップＳ１０９）。

以後、アプリケーションサーバ１０３の送受信部１３１で受信されたパケットに対して、通信インターフェースのメモリ上に読み出されたフロー識別情報およびＤＳＣＰ値を参照し、このエントリールールにしたがった制御を行う。

すなわち、端末Ｔ１から再びパケットが送信されると（ステップＳ１１０）、アプリケーションサーバ１０３では、情報抽出部１３１がパケットからフロー識別情報およびＤＳＣＰ値を抽出する（ステップＳ１１１）。そして、抽出したフロー識別情報を、通信インターフェースに読み出されているデータと照合する。このデータの中に適合するフロー識別情報があった場合には、そのフロー識別情報に対応するＤＳＣＰ値と、抽出したＤＳＣＰ値とを比較する（ステップＳ１１２）。２つのＤＳＣＰ値が同一の場合には（ステップＳ１１３，ＹＥＳ）、このＤＳＣＰ値に応じた優先制御でパケットをルータＲ１に送信する（ステップＳ１１５）。

これに対し、２つのＤＳＣＰ値が異なる場合には（ステップＳ１１３，ＮＯ）、パケットのＩＰヘッダのＴｏＳフィールドに、メモリ上のＤＳＣＰ値を上書き設定し（ステップＳ１１４）、上書きしたＤＳＣＰ値に応じた優先制御でパケットをルータＲ１に送信する（ステップＳ１１５）。
なお、ステップＳ１１２における照合の結果、適合するフロー識別情報がなかった場合には、端末Ｔ１からのパケットを廃棄する。あるいは、ベストエフォートで非優先的に当該アプリケーションサーバ１０３を通過させることもできる。

３．第３の実施の形態
次に、本発明の第３の実施の形態について説明する。この形態は、通信ネットワークを複数のリソース管理サーバにより管理するものである。
図１３は、本実施の形態にかかるリソース管理システムの全体構成を示すブロック図である。
このリソース管理システムは、通信ネットワークのリソースを管理する複数のリソース管理サーバ２Ａ，２Ｂから構成される。ここで、管理対象となる通信ネットワークは、互いにリンクされた複数のルータＲ（ＲＡ１，ＲＡ２，ＲＡ３，ＲＡ４，ＲＢ１，ＲＢ２，ＲＢ３，ＲＢ４）と端末Ｔ（ＴＡ１，ＴＡ２，ＴＢ１，ＴＢ２）とから構成される。

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

アプリケーションサーバ３は、端末（例えば、端末ＴＡ１）からのサービス利用要求を受けて、この端末が属する管理範囲（例えば、管理範囲１Ａ）のリソースを管理するリソース管理サーバ（例えば、リソース管理サーバ２Ａ）にリソース確保要求メッセージを送信する。

リソース管理サーバ２Ａ，２Ｂは、第１の実施の形態におけるリソース管理サーバ２と同様に、送受信部２１と、制御部２２と、データベース部２３とを有する。制御部２２はさらに、要求受付部２２１と、リソース処理部２２２と、メッセージ作成部２２３とを有する。

ただし、要求受付部２２１は、リソース確保要求メッセージから抽出したフロー識別情報を基に、着端末が自サーバの管理範囲に属するか否かを判定する機能と、リソース確保要求メッセージから抽出されたＤＳＣＰ値を必要に応じて所望の値に修正する機能（ＤＳＣＰ値修正機能）をさらに有する。ＤＳＣＰ値が修正された場合には、修正後のＤＳＣＰ値が応答メッセージに付加されることになる。

また、メッセージ作成部２２３および送受信部２１は、着端末が自サーバの管理範囲に属しない場合に、自サーバの管理範囲と管理範囲が隣接する他のリソース管理サーバ（以下「隣接サーバ」という）にリソース確保要求メッセージを転送する機能を有する。また、リソース確保要求メッセージの送信先である隣接サーバから応答メッセージを受信するとともに、応答メッセージを受信したときにリソース確保要求メッセージの送信元に応答メッセージを転送する機能を有する。さらに、受信した応答メッセージに修正後のＤＳＣＰ値が付加されていたときには、フロー識別情報および修正後のＤＳＣＰ値を自サーバの管理範囲と隣接サーバの管理範囲との境界にあるノードに送信する機能を有する。

次に、図１４を参照し、複数の管理範囲にまたがる通信に必要なリソースを確保する処理について説明する。ここでは、端末ＴＡ１から端末ＴＢ１に通信する場合を例にして説明する。図１４は、処理の流れを示すシーケンス図である。
端末ＴＡ１がリソース確保サービスの利用要求メッセージを送信し、これを受けてアプリケーションサーバ３がリソース確保要求メッセージをリソース管理サーバ２Ａに送信する（ステップＳ２０１）までの処理については、第１の実施の形態と同様である。

アプリケーションサーバ３からのリソース確保要求メッセージを受信したリソース管理サーバ２Ａでは、要求受付部２２１が、リソース確保要求メッセージからフロー識別情報、ＤＳＣＰ値、要求リソース量を抽出する（ステップＳ２０２）。そして、フロー識別情報を基に、着端末ＴＢ１が自サーバ２Ａの管理範囲１Ａに属するか否かを判定する。データベース部２３には管理範囲１Ａに属する端末のＩＰアドレスのリストが予め登録されており、このリストからフロー識別情報の着端末ＩＰアドレスを検索することにより、着端末ＴＢ１が管理範囲１Ａ内に属するか否かを判定することができる。

着端末ＴＢ１が管理範囲１Ａに属しない場合には、送受信部２１からリソース管理サーバ２Ｂにリソース確保要求メッセージを転送する（ステップＳ２０３）。
リソース管理サーバ２Ｂでは、要求受付部２２１がリソース確保要求メッセージからフロー識別情報、ＤＳＣＰ値、要求リソース量を抽出し（ステップＳ２０４）、着端末ＴＢ１が自サーバ２Ｂの管理範囲１Ｂに属するか否かを判定する。

着端末ＴＢ１が管理範囲１Ｂに属する場合には、リソース処理部２２２がリソース確保処理を行う（ステップＳ２０５）。この際、ＤＳＣＰ値の修正を行ったものとする。
リソース確保に成功した場合には、リソース処理部２２２は、ステップＳ２０４でリソース確保要求メッセージから抽出されたフロー識別情報および修正後のＤＳＣＰ値を、データベース部２３のアクセスリストテーブル２３１に登録する（ステップＳ２０６）。
また、メッセージ作成部２２３が、リソース確保要求を許可する旨のリソース確保応答メッセージを作成し、このメッセージをリソース管理サーバ２Ａに送信する（ステップＳ２０７）。このメッセージには、上記フロー識別情報および修正後のＤＳＣＰ値が付加される。

リソース確保応答メッセージを受信したリソース管理サーバ２Ａでは、リソース処理部２２２がリソース確保処理を行う（ステップＳ２０８）。
リソース確保に成功した場合には、リソース処理部２２２は、ステップＳ２０２でリソース確保要求メッセージから抽出されたフロー識別情報およびＤＳＣＰ値を、データベース部２３のアクセスリストテーブル２３１に登録する（ステップＳ２０９）。
また、リソース確保応答メッセージに付加された修正後のＤＳＣＰ値と、ステップＳ２０２でリソース確保要求メッセージから抽出されたＤＳＣＰ値とを比較する。両者の値が異なることから、ＤＳＣＰ値がリソース管理サーバ２Ａで修正されたことを検出する。

ＤＳＣＰ値がリソース管理サーバ２Ａで修正されたことを検出すると、メッセージ作成部２２３は、上記フロー識別情報および修正後のＤＳＣＰ値を付加した優先度通知メッセージを作成し、このメッセージを管理範囲１Ａと１Ｂとの境界にあるルータＲＡ４（管理範囲１Ａの出口）に送信する（ステップＳ２１０）。

リソース管理サーバ２Ａからの優先度通知メッセージを受信したルータＲＡ４では、解析部４３が、優先度通知メッセージに付加された情報を抽出し、データベース部４２のアクセスリストテーブルに登録し、送受信部４１の通信インターフェースのメモリにアクセスリストテーブルを読み出す（ステップＳ２１１）。また、アクセスリストテーブルへの登録に成功した旨を示す登録通知メッセージを作成し、リソース管理サーバ２Ａに送信する（ステップＳ２１２）。

ルータＲＡ４からの登録通知メッセージを受信したリソース管理サーバ２Ａでは、メッセージ作成部２２３が、リソース確保要求を許可する旨のリソース確保応答メッセージを作成し、このメッセージをアプリケーションサーバ３に送信する（ステップＳ２１３）。アプリケーションサーバ３は、リソース確保応答メッセージを受信すると、リソース確保サービスの利用を許可する旨のサービス利用許可メッセージを端末Ｔ１に送信する。

以上のように、本実施の形態では、複数のリソース管理サーバ２Ａ，２Ｂの間で各種メッセージを送受信することにより、複数の管理範囲１Ａ，１Ｂにまたがるフローの経路についてもリソース管理を行うことができる。
また、本実施の形態では、着端末側の管理範囲１Ｂを管理するリソース管理サーバ２ＢでＤＳＣＰ値を修正した場合に、修正後のＤＳＣＰ値を応答メッセージに付加してリソース管理サーバ２Ａに送信し、このリソース管理サーバ２Ａから管理範囲１Ａと１Ｂとの境界にあるルータＲＡ４に修正後のＤＳＣＰ値を通知する。これにより、端末ＴＡ１から端末ＴＢ１に送信されたパケットのＤＳＣＰ値を境界ルータＲＡ４において書き換え、管理範囲１Ｂ内においてリソース管理サーバ２Ｂが指定した振る舞いでパケットを転送させることができる。

なお、上述したアプリケーションサーバ３、リソース管理サーバ２，２Ａ，２ＢおよびルータＲは、それぞれ通信機能を有するコンピュータからなる。アプリケーションサーバ３、リソース管理サーバ２，２Ａ，２ＢおよびルータＲの上述した諸機能は、演算装置（ＭＰＵ）や記憶装置（ＲＯＭおよびＲＡＭ等の内部メモリの他、ＨＤＤ等の外部記憶装置を含む）等のコンピュータのハードウェア資源とこのコンピュータにインストールされたコンピュータ・プログラム（ソフトウェア）とが協働することによって実現することができる。

本発明は、例えば高品質の通信サービスを提供する分野に利用可能である。

本発明の第１の実施の形態にかかる通信システムの全体構成を示すブロック図である。 リソース管理サーバの機能ブロック図である。 アクセスリストテーブルのデータ構造の一例を示す図である。 キューテーブルのデータ構造の一例を示す図である。 受付番号テーブルのデータ構造の一例を示す図である。 受付番号付与の基本的なアルゴリズムについて説明する図である。 キューの最終受付番号の変更について説明する図である。 ルータの機能ブロック図である。 通信システムの全体的な処理の流れを示すシーケンス図である。 リソース管理サーバによるリソース確保の処理の流れを示すフローチャートである。 本発明の第２の実施の形態におけるアプリケーションサーバの機能ブロック図である。 通信システムの全体的な処理の流れを示すシーケンス図である。 本発明の第３の実施の形態にかかるリソース管理システムの全体構成を示すブロック図である。 処理の流れを示すシーケンス図である。

符号の説明

１…通信ネットワーク、１Ａ，１Ｂ…管理範囲、２，２Ａ，２Ｂ…リソース管理サーバ、３，１０３…アプリケーションサーバ、２１…送受信部、２２…制御部、２３…データベース部、４１…送受信部、４２…データベース部、４３…解析部、４４…ヘッダ設定部、１３１…送受信部、１３２…情報抽出部、１３３…制御部、１３４…データベース部、２２１…要求受付部、２２２…リソース処理部、２２３…メッセージ作成部、２３１…アクセスリストテーブル、２３２…キューテーブル、２３３…受付番号テーブル、Ｒ１〜Ｒ７，ＲＡ１〜ＲＡ４，ＲＢ１〜ＲＢ４…ルータ、Ｔ１〜Ｔ６，ＴＡ１，ＴＡ２，ＴＢ１，ＴＢ２…端末。

Claims (13)

1. 複数のノードを含む通信ネットワークのリソース確保を行なうリソース管理装置において、
   通信を行う発端末と着端末との間のフローを識別する識別情報と前記フローのＤＳＣＰ値とが付加された、リソース確保を要求する要求メッセージを受信するメッセージ受信手段と、
   受信された前記要求メッセージから前記識別情報および前記ＤＳＣＰ値を抽出する情報抽出手段と、
   抽出された前記識別情報に基づいて前記フローを特定するフロー特定手段と、
   特定された前記フローの経路についてリソース確保を行う確保処理手段と、
   リソース確保された前記経路上のいずれかのノードに、抽出された前記識別情報および前記ＤＳＣＰ値を送信する情報送信手段と
   を備えることを特徴とするリソース管理装置。
2. 請求項１に記載のリソース管理装置において、
   前記識別情報は、前記発端末のＩＰプレフィックスを含むＩＰアドレス、前記着端末のＩＰプレフィックスを含むＩＰアドレス、プロトコル番号、発ポート番号および着ポート番号を含み、
   前記ＤＳＣＰ値は、前記発端末のＩＰアドレス、前記着端末のＩＰアドレス、プロトコル番号、発ポート番号および着ポート番号のすべての組合わせに対して決定されることを特徴とするリソース管理装置。
3. 請求項１に記載のリソース管理装置において、
   特定された前記フローと抽出された前記ＤＳＣＰ値とを対応づけて記憶する記憶手段をさらに備えることを特徴とするリソース管理装置。
4. 複数のノードを含む通信ネットワークを分割した複数の管理範囲ごとに設けられ、前記通信ネットワークのリソースに関するメッセージを互いに送受信し、このメッセージに基づいてそれぞれの管理範囲内におけるリソース確保を行うリソース管理装置であって、
   通信を行う発端末と着端末との間のフローを識別する識別情報と前記フローのＤＳＣＰ値とが付加された、リソース確保を要求する要求メッセージを受信するメッセージ受信手段と、
   受信された前記要求メッセージから前記識別情報および前記ＤＳＣＰ値を抽出する情報抽出手段と、
   抽出された前記識別情報に基づいて、自装置の管理範囲内におけるフローを特定するフロー特定手段と、
   特定された前記フローの経路についてリソース確保を行う確保処理手段と、
   リソース確保された前記経路上のいずれかのノードに、抽出された前記識別情報および前記ＤＳＣＰ値を送信する情報送信手段と
   を備えることを特徴とするリソース管理装置。
5. 請求項４に記載のリソース管理装置において、
   リソース確保に成功したときに、リソース確保要求を許可する旨の応答メッセージを前記要求メッセージの送信元に送信するメッセージ送信手段をさらに備えることを特徴とするリソース管理装置。
6. 請求項５に記載のリソース管理装置において、
   抽出された前記ＤＳＣＰ値を修正するＤＳＣＰ値修正手段をさらに備え、
   前記メッセージ送信手段は、前記ＤＳＣＰ値修正手段により前記ＤＳＣＰ値が修正されたときには、修正後のＤＳＣＰ値を前記応答メッセージに付加することを特徴とするリソース管理装置。
7. 請求項６に記載のリソース管理装置において、
   前記メッセージ送信手段は、前記着端末が自装置の管理範囲内に属しない場合に、自装置の管理範囲と管理範囲が隣接する他のリソース管理装置に前記要求メッセージを送信し、
   前記メッセージ受信手段は、前記他のリソース管理装置からの応答メッセージを受信することを特徴とするリソース管理装置。
8. 請求項７に記載のリソース管理装置において、
   前記情報送信手段は、受信された前記応答メッセージに修正後のＤＳＣＰ値が付加されている場合に、前記修正後のＤＳＣＰ値を自装置の管理範囲と前記他のリソース管理装置の管理範囲との境界にあるノードに送信することを特徴とするリソース管理装置。
9. 通信ネットワークを構成する複数のノードと、前記通信ネットワークのリソース確保を行なうリソース管理装置とを備える通信システムにおいて、
   前記リソース管理装置は、
   通信を行う発端末と着端末との間のフローを識別する識別情報と前記フローのＤＳＣＰ値とが付加された、リソース確保を要求する要求メッセージを受信するメッセージ受信手段と、
   受信された前記要求メッセージから前記識別情報および前記ＤＳＣＰ値を抽出する情報抽出手段と、
   抽出された前記識別情報に基づいて前記フローを特定するフロー特定手段と、
   特定された前記フローの経路についてリソース確保を行う確保処理手段と、
   リソース確保された前記経路上のいずれかのノードに、抽出された前記識別情報および前記ＤＳＣＰ値を送信する情報送信手段とを備える
   ことを特徴とする通信システム。
10. 請求項９に記載の通信システムにおいて、
    前記ルータは、
    前記リソース管理装置から送信された前記識別情報および前記ＤＳＣＰ値を受信する情報受信手段と、
    受信された前記識別情報と前記ＤＳＣＰ値とを対応づけて記憶する情報記憶手段と、
    パケットを受信するパケット受信手段と、
    受信された前記パケットに含まれる識別情報およびＤＳＣＰ値と前記情報記憶手段に記憶されている前記識別情報および前記ＤＳＣＰ値とを比較し、識別情報が一致しＤＳＣＰ値が異なる場合に、前記パケットの前記ＤＳＣＰ値を前記情報記憶手段に記憶されている前記ＤＳＣＰ値に書き換えるＤＳＣＰ値管理手段とを備える
    ことを特徴とする通信システム。
11. 通信ネットワークを構成する複数のノードと、前記通信ネットワークのリソース確保を行なうリソース管理装置とを用いた通信方法において、
    前記リソース管理装置において、
    通信を行う発端末と着端末との間のフローを識別する識別情報と前記フローのＤＳＣＰ値とが付加された、リソース確保を要求する要求メッセージを受信するステップと、
    受信された前記要求メッセージから前記識別情報および前記ＤＳＣＰ値を抽出するステップと、
    抽出された前記識別情報に基づいて前記フローを特定するステップと、
    特定された前記フローの経路についてリソース確保を行うステップと、
    リソース確保された前記経路上のいずれかのノードに、抽出された前記識別情報および前記ＤＳＣＰ値を送信するステップ
    とを備えることを特徴とする通信方法。
12. 請求項１１に記載の通信方法において、
    前記ルータにおいて、
    前記リソース管理装置から送信された前記識別情報および前記ＤＳＣＰ値を受信するステップと、
    受信された前記識別情報と前記ＤＳＣＰ値とを対応づけて情報記憶手段に記憶するステップと、
    パケットを受信するステップと、
    受信された前記パケットに含まれる識別情報およびＤＳＣＰ値と前記情報記憶手段に記憶されている前記識別情報および前記ＤＳＣＰ値とを比較し、識別情報が一致しＤＳＣＰ値が異なる場合に、前記パケットの前記ＤＳＣＰ値を前記情報記憶手段に記憶されている前記ＤＳＣＰ値に書き換えるステップと
    を備えることを特徴とする通信方法。
13. 複数のノードを含む通信ネットワークを分割した複数の管理範囲ごとリソース管理装置を設け、それぞれのリソース管理装置の間で前記通信ネットワークのリソースに関するメッセージを送受信し、このメッセージに基づいてそれぞれの管理範囲内におけるリソース確保を行う通信方法であって、
    一のリソース管理装置において、
    通信を行う発端末と着端末との間のフローを識別する識別情報と前記フローのＤＳＣＰ値とが付加された要求メッセージを受信するステップと、
    受信した前記要求メッセージから前記識別情報および前記ＤＳＣＰ値を抽出するステップと、
    前記着端末が自装置の管理範囲に属しない場合に、自装置の管理範囲と管理範囲が隣接する他のリソース管理装置に前記要求メッセージを送信するステップと、
    前記他のリソース管理装置から修正後のＤＳＣＰ値が付加された応答メッセージを受信するステップと、
    前記修正後のＤＳＣＰ値を自装置の管理範囲と前記他のリソース管理装置の管理範囲との境界にあるノードに送信するステップと
    を備えることを特徴とする通信方法。

Images