JP2009055327A - ネットワークシステム - Google Patents

Abstract

【課題】端点間のＱｏＳ条件をネットワーク・ポリシーへフィードバック可能にする。
【解決手段】第１のコンピュータと第２のコンピュータとの間はＱｏＳ要求条件が設定された第１の通信を行い、前記第２のコンピュータは、前記第１の通信のＱｏＳを計測し、前記第１の通信の識別子及び前記計測結果を含む制御情報を、ネットワーク装置経由で前記第１のコンピュータに送信し、前記ネットワーク装置は、前記制御情報を捕捉し、前記捕捉した制御情報から抽出された第１の通信の識別子及び計測結果を含むメッセージを、資源管理サーバに送信し、前記資源管理サーバは、前記計測結果が前記ＱｏＳ要求条件を満たさない場合、前記ＱｏＳ要求条件を満たさない原因を推定し、前記原因があると判定されたネットワークノードにＱｏＳを設定することを特徴とするネットワークシステムである。
【選択図】図１

Description

本発明は、パケットを転送するネットワークシステムに関し、特にネットワークにおけるＱｏＳ保証に関する。

従来、インターネット等のネットワークシステムにおいては、端点間のＱｏＳ（すなわち、端末間や、サーバと端末との間における遅延及びジッター等）に関する通信品質を保証することは困難であった。しかし、ＩＴＵ−ＴやＥＴＳＩにおいて標準化がすすめられているＮＧＮ（Next Generation Networks）によると、インターネット・プロトコルに基づく新しいネットワークにおいて、端点間のＱｏＳを保証することが目標とされている。

従来の電話網のように、ネットワーク・サービスが画一化されていれば、必要なＱｏＳ仕様は予めネットワークによって把握されている。しかし、ＮＧＮにおいて広く使用されるようになると考えられる各種のマルチメディア通信においては、端末やホームゲートウェイは、ユーザがキャリアのネットワーク（ＮＧＮ）を使用してマルチメディア通信等を行う際に必要とされるＱｏＳ仕様を把握している。しかし、キャリアのネットワークは必要とされるＱｏＳ仕様を把握していない。従って、保証するべき端点間のＱｏＳ仕様を、それらの機器がネットワークに要求し、その要求に基づいて、ネットワーク資源管理サーバ（ＮＧＮの用語によればＲＡＣＦ（Resource Admission Control Functions））がポリシーを決定し、ルータなどのネットワーク資源を制御することができる。

ネットワークにおいて使用される帯域幅、許容される遅延、ジッター等に関するＱｏＳ仕様を伝えるためのプロトコルとして、ＮＧＮ標準においてはＩＥＴＦ（Internet Engineering Task Force）標準のプロトコルであるＳＩＰ（Session Initiation Protocol）やＲＳＶＰ（Resource ReserVation Protocol）が使用される。また、ＲＳＶＰより多様な目的で使用できるプロトコルとしてＮＳＬＰ（NSIS Signaling Layer Protocol、ここでＮＳＩＳはＩＥＴＦのワーキンググループ）がＩＥＴＦにおいて標準化の検討中である。

ＳＩＰ、ＲＳＶＰ及びＮＳＬＰ等のプロトコルを使用してＱｏＳ仕様をネットワークに伝えても、遅延及びジッター等の値は、ネットワークにおいて直接制御することはできない。ネットワークにおいて、資源管理サーバは、当該通信トラフィックのためにルータのどの資源（キュー及び出力帯域等）を使用させるかを決めるだけである。従って、ネットワークの混雑度や他のトラフィックの性質によっては、指定されたＱｏＳ仕様があらかじめ用意された方法によって守れないことがある。

このような場合には、トラフィック計測等の方法によって、指定された条件が満たされているかを確認し、満たされていなければフィードバックをかけることができる。フィードバックを使用したネットワークやシステムの制御に関しては、以下のような従来技術がある。

非特許文献１には、ＩＥＴＦの標準プロトコルであるＲＴＰ（Real-time Transport Protocol）及びＲＴＣＰ（Real-Time Control Protocol）を使用して、端点間でＱｏＳを向上させるための方法が記載されている。すなわち、リアルタイム通信において、受信側のアプリケーションが遅延及びジッター等を計測して、その結果をＲＴＣＰによって送信側に伝える。しかし、この方法では、ネットワークにおいて発生している問題を解決することはできない。

特許文献１には、データセンタにおけるネットワーク運用管理ポリシーを最適化するため、ポリシーの適用履歴等をデータセンタ内で収集し、収集した情報に基づいてポリシーを最適化する方法が記載されている。特許文献１に記載された方法によると、データセンタ内の阻害要因を排除して、ＱｏＳを向上させることができる。しかし、特許文献１に記載された方法では、端末側におけるＱｏＳ条件を把握することができないので、端点間の遅延及びジッター等に関するＱｏＳを保証することはできない。

特許文献２には、ネットワーク上に測定装置を設け、測定結果に基づいて制御サーバがネットワークを制御（ポリシーを配布）する方法が記載されている。特許文献２に記載された方法でも、特許文献１に記載された方法と同様に、端末側におけるＱｏＳ条件を把握することができず、端点間のＱｏＳを保証することはできない。

特許文献３には、端末に備わるＱｏＳ制御モジュールを「セントラルコントローラ」及び「セントラルデータベース」によって管理する方法が記載されている。特許文献３に記載された方法によると、ネットワークの混雑度等に応じて端末を制御することができ、端末をネットワークに適応させることができる。しかし、特許文献３に記載された方法では、非特許文献１に記載された方法と同様に、ネットワークを制御する機構が存在せず、ネットワークにおけるＱｏＳを制御することができない。
特許公開２００５−３５４２８０号公報 特許公開２００２−０１６５９９号公報 特許公開２００４−３２０１５９号公報 コリン・パーキンズ（Colin Perkins）著，「RTP - Audio and Video for the Internet」，アディソン・ウェースリー出版（Addison-Wesley Pub），２００３年６月 スー・ビー・ムーン（Sue B. Moon）他著，「Estimation and Removal of Clock Skew from Network Delay Measurements」， IEEE Infocom 1999，１９９９年３月，ｐ．２２７−２３４ リー・ツァン（Li Zhang）他著，「Clock Synchronization Algorithms for Network Measurements」，IEEE Infocom 2002，２００２年７月，ｐ．１６０−１６９ コスタス・ジー・アナノスタキス（Kostas G. Anagnostakis）他著，「cing: Measuring Network-Internal Delays Using Only Existing Infrastructure」，IEEE Infocom 2003，２００３年４月，ｐ．２１１２−２１２１

この発明は、前述した従来技術において実現できなかった、端点間のＱｏＳ条件のネットワーク・ポリシーへのフィードバックを可能にすることを目的とする。さらに、ネットワークがどのような状態にあっても、またネットワークの状態が変化しても、指定されたＱｏＳの仕様を満たすことを可能にする方法を提供することを目的とする。

本発明の代表的な一例を示せば以下の通りである。すなわち、通信インターフェースを備える第１のコンピュータ及び通信インターフェースを備える第２のコンピュータに接続されるネットワークシステムであって、前記第１のコンピュータと前記第２のコンピュータとの通信経路上に設けられ、パケットを転送する少なくとも一つのネットワークノードと、前記第２のコンピュータから送信される制御情報を前記第１のコンピュータに転送するとともに、前記制御情報を捕捉するネットワーク装置と、前記ネットワークノードを制御する資源管理サーバと、を備え、前記第１のコンピュータと前記第２のコンピュータとの間の通信のＱｏＳ要求条件が設定されており、前記第１のコンピュータは、前記第２のコンピュータに繰り返しパケットを送信して第１の通信を行い、前記第２のコンピュータは、前記第１の通信のＱｏＳを計測し、前記第１の通信の識別子及び前記計測結果を含む制御情報を、前記ネットワーク装置経由で前記第１のコンピュータに送信し、前記ネットワーク装置は、前記制御情報を捕捉し、前記捕捉した制御情報から抽出された第１の通信の識別子及び計測結果を含むメッセージを、前記資源管理サーバに送信し、前記資源管理サーバは、前記計測結果が前記ＱｏＳ要求条件を満たさない場合、前記ＱｏＳ要求条件を満たさない原因を推定し、前記原因があると判定された前記ネットワークノードにＱｏＳを設定することを特徴とするネットワークシステムである。

本発明の一実施形態によると、端末、サーバ及びゲートウェイ等から要求された端点間のＱｏＳを、より多様なネットワーク条件の下で保証することができる。さらに、ネットワークと端点とが協働することによって、ネットワークだけでＱｏＳを保証するより低コストでＱｏＳを保証することができる。

まず、本発明の概要について説明する。

本発明の実施の形態においては、第１の手段として、受信したＱｏＳ保証対象のトラフィックを受信した際に、受信したトラフィックに関する遅延、ジッター及び／又はパケット損失等のＱｏＳ条件を計測し、計測結果をレポート・パケットに記述し、送信側に送る端末及び／又はサーバ上のアプリケーション・プログラムを備える。なお、端末及び／又はサーバとネットワークとの間に設けられ、同様に機能するゲートウェイを使用してもよい。また、第２の手段として、前述したレポート・パケットの内容を捕捉して、資源管理サーバに報告するルータを備える。なお、ルータ及びルータ機能拡張装置の組み合わせであってもよい。さらに、第３の手段として、前述した報告に基づいて、ポリシー及びネットワークの設定を変更する資源管理サーバを備える。

これらの手段によって、通信時に受信側のアプリケーション・プログラムやゲートウェイが計測した結果を送信側のアプリケーション・プログラムやゲートウェイに送信する。ルータ又はルータ機能拡張装置は、送信された計測結果を捕捉して、捕捉した内容を資源管理サーバに伝える。資源管理サーバは、ＱｏＳ条件を満たすように、ネットワーク・ポリシーを修正することができる。

すなわち、ネットワークにおけるＱｏＳ保証機構、及び両端点を含むフィードバック・ループを構成することによって、両者が協調的にＱｏＳを保証することができる。

換言すると、ネットワークがどのような状態にあっても、またネットワークの状態が変化しても、端点間のＱｏＳの測定結果に基づいてネットワーク・ポリシーを調整することができ、これによって、端末、サーバ及びゲートウェイ等から要求された端点間のＱｏＳを、より多様なネットワーク条件の下で保証することができる。さらに、端点に設けられた装置とネットワークとが協調することによって、ネットワークだけでＱｏＳ保証する場合より、低コストでＱｏＳを保証することができる。

＜実施形態１＞
本発明の第１の実施の形態について説明する。

図１は、本発明の第１の実施の形態のネットワークシステムの構成を示すブロック図である。

本実施の形態においては、コンピュータ１０１からコンピュータ１０２に音声及び／又は画像を送信する。コンピュータ１０１において生成されたトラフィックは、アクセスネットワーク１１０を経由してボーダルータ１０３からキャリアのコアネットワーク１１２に入る。ネットワーク１１２は、ボーダルータ１０３及び１０４、及びコアルータ１０５、１０６及び１０７を備える。

ネットワーク１１２に入ったトラフィックは、コアルータ１０６及びコアルータ１０７を経由してボーダルータ１０４から出力されて、ネットワーク１１２から出る。ネットワーク１１２から出たトラフィックは、アクセスネットワーク１１１を経由してコンピュータ１０２に到達する。ネットワーク１１２のＱｏＳは、資源管理サーバ１０８によって管理されている。

また、コンピュータ１２１からコンピュータ１２２に音声及び／又は画像を送信する。コンピュータ１２１において生成されたトラフィックは、アクセスネットワーク１３０を経由してボーダルータ１０３からキャリアのネットワーク１１２に入る。ネットワーク１１２に入ったトラフィックは、コアルータ１０６及びコアルータ１０７を経由してボーダルータ１０４から出力されて、ネットワーク１１２から出る。ネットワーク１１２から出たトラフィックは、アクセスネットワーク１３１を経由してコンピュータ１２２に到達する。

コンピュータ１０１、コンピュータ１０２及び資源管理サーバ１０８は、いずれも中央処理ユニット（ＣＰＵ）、短期記憶ユニット（例えば、メモリ）、長期記憶ユニット（例えば、磁気ディスクドライブ）、及び通信ユニット（例えば、ネットワークインターフェースカード）を備える。中央処理ユニットは、短期記憶ユニット、長期記憶ユニット及び通信ユニットから入力されたデータによって動作し、短期記憶ユニット、長期記憶ユニット及び通信ユニットに演算結果を出力する。

ボーダルータ１０３、ボーダルータ１０４、コアルータ１０６及びコアルータ１０７は、各々、制御ユニット、複数の通信ユニット、ルーティング・ユニット及びスイッチ・ユニットを備える。各ルータは、第１の通信ユニットから入力されたパケットを、ルーティング・ユニットに保持された情報に従って、制御ユニットに制御されたスイッチ・ユニットを経由して第２又は第１の通信ユニットから出力する。

本実施の形態においては、ネットワーク１１２において、ＩＥＴＦにおいて標準化されているＤｉｆｆｓｅｒｖ（Differentiated Services）方式によってＱｏＳが制御される。Ｄｉｆｆｓｅｒｖによると、コア・ネットワーク（図１のネットワーク１１２）の入口又はそれ以前にＩＰパケットをクラス分けする。すなわち、ＩＰパケットのＤＳＣＰフィールドにはクラス毎に異なる値が書き込まれる（マーキングがされる）。コアルータ１０６及び１０７は、ＤＳＣＰフィールドの値に従って、クラス毎に異なるＱｏＳ制御を行う。本実施の形態においては、ボーダルータ１０３がマーキングを行い、コアルータ１０６及び１０７が、マーキングされたＤＳＣＰフィールドの値に従って、出力キューを選択する。

Ｄｉｆｆｓｅｒｖにおいては、各ルータにおけるトラフィックの転送を以下のように分類して制御している。

ＥＦ（Expedited Forwarding）：指定されたＱｏＳ条件を保証するサービスのための制御。ＥＦトラフィックは、他のトラフィックより優先され、優先キューによって扱われる。

ＡＦ（Assured Forwarding）：ＱｏＳ条件に差がある４クラスの転送制御（ＡＦ１、ＡＦ２、ＡＦ３、ＡＦ４）を定義することができる。通常、これらのクラスの間で帯域を分割し、ルータ輻輳時等の廃棄率にも差が設けられる。

ＤＦ（Default Forwarding）：ＤＥトラフィックは、ベストエフォートで扱われる。すなわち、ＱｏＳ制御は行われない。

コアルータ１０６及び１０７は出力インタフェース毎に４本のキューを備えるが、本実施の形態においては、これらのキューを以下のように使用する。

第１キュー：ＱｏＳ要求仕様が会話クラスと指定された音声トラフィックのための優先キュー。ＥＦの転送制御が行われる。

第２キュー：ＱｏＳ要求仕様が会話クラスと指定された画像トラフィック、及び、インタラクティブ・クラスと指定されたトラフィックのための帯域分割キュー（ＷＦＱ）。ＡＦの転送制御が行われる。すなわち、必要な帯域幅が確保されるようにｗ２の値が決められる。

第３キュー：ＱｏＳ要求仕様がストリーミング・クラスと指定された画像トラフィックのための帯域分割キュー（ＷＦＱ）。ＡＦの転送制御が行われる。すなわち、必要な帯域幅が確保されるようにｗ３の値が決められる。

第４キュー：上記以外のトラフィック（ベストエフォート・トラフィック）のための帯域分割キュー（ＷＦＱ）。ＤＦの転送制御が行われる。最低限の帯域幅が確保されるように、ｗ４に”０”でない値（例えば１％）が設定される。他のクラスによって使用されない余剰帯域が使用される。

第１キューに格納されたパケットは、他のキューに格納されたパケットより優先的にスケジューリングされる。第２〜４キューは、第１キューにパケットが存在しないときにスケジューリングされる。しかし、第２〜第４キューの出力帯域は、ｗ２、ｗ３、ｗ４に分割される（ｗ２＋ｗ３＋ｗ４＝１）。ｗ２、ｗ３、ｗ４の値は、コアルータにコマンドを入力することによって設定される。例えば、一つの優先キューと三つの帯域分割キューを使用することができるルータが販売されている。このようなルータは、前述したように帯域を分割する機能を備える。このようなキューの設定は、コアルータに予め初期設定してもよく、又は資源管理サーバ１０８の起動時に資源管理サーバ１０８がコアルータに初期設定してもよい。

図２Ａから図２Ｄは、本発明の第１の実施の形態において使用される資源要求のためのプロトコルのデータ形式を示す。

資源要求のためのプロトコルとして、既にＲＳＶＰ（Resource ReSerVation Protocol）が、ＩＥＴＦにおいて標準化されている。また、ＱｏＳ ＮＳＬＰ（NSIS Signaling Layer Protocol）が、ＮＳＩＳ（Next-Step In Signaling）ワーキンググループにおいて標準化中である。ＱｏＳ制御のために、これらのプロトコルを使用することも可能であるが、本実施の形態では、非標準のプロトコルであるが、より実装が容易なプロトコルを使用している。

本発明に係る資源要求のためのプロトコル（以下、ＳＮＳＬＰという）は、ＩＥＴＦの標準プロトコルであるＲＴＣＰ（Real-Time Control Protocol）上に実装される。ＲＴＣＰは音声、映像等を伝送するためのＩＥＴＦ標準プロトコルＲＴＰ（Real-time Transport Protocol）と組み合わせて使用される制御用のプロトコルであり、ＲＴＰと同様にＩＥＴＦ標準プロトコルであるＵＤＰ（User Datagram Protocol）上に実装される。ＳＮＳＬＰは、必ずしもＲＴＣＰ上に実装される必要はなく、ＵＤＰ上又はＴＣＰ上に実装されることも可能である。なお、ＲＴＣＰ上に実装されることによってメッセージの内容を簡素化することができる。

ＳＮＳＬＰは、ＲＳＶＰと同様にソフトステートのプロトコルである。すなわち、ＳＮＳＬＰのメッセージ中にはその有効期限（Refresh period）が記述され、有効期限内に再度ＳＮＳＬＰのメッセージを送って状態を更新しない限り、有効期限が切れて資源要求は無効になる。

図２Ａは、ＳＮＳＬＰメッセージを含むＲＴＣＰメッセージの形式を示す。

ＲＴＣＰヘッダの第１語２０１の第０バイトにはＳＮＳＬＰのメッセージタイプとして、以下のいずれかの値が含まれる。

129: RES (RESERVE)
130: RRES (RESPONSE_TO_RESERVE)
131: TEA (TEAR)
132: RTEA (RESPONSE_TO_TEAR)
133: NOT (NOTIFY)
135: REP (REPORT)
136: RREP (RESPONSE_TO_REPORT)

また、第１バイトには、このメッセージが標準ドキュメントにおいて記述されたものではなく、アプリケーションによって定義されるものであることを示す値である”２０４”が含まれる。

また、第２〜３バイトには、メッセージ・サイズが含まれる。ＲＴＣＰヘッダの第２語２０２には、ＲＴＰのストリームの識別子（ＳＳＲＣ／ＣＳＲＣ）が含まれる。また、第３語２０３には、このメッセージがＳＮＳＬＰのメッセージであることを示す文字列（ＳＮＳＬ）が含まれる。第４語以降には、ＳＮＳＬＰのメッセージ本体が含まれる。ＳＮＳＬＰのメッセージ本体については以下で説明する。

図２Ｂは、メッセージタイプが”ＲＥＳ”であるときのメッセージ本体の内容を示す。

ＲＥＳメッセージの第１語２１２には、有効期限（Refresh period）が記述される。また、これにつづく部分２１３には、ＱｏＳ要求仕様（QoS Desired）が記述される。ＱｏＳ要求仕様の内容は図２Ｃに示す。

ＱｏＳ要求仕様には、要求される帯域幅（bandwidth）２２２、ＩＴＵ−Ｔ標準 Ｙ．１５４１において規定されるＱｏＳクラス２２３、端点間の遅延（path latency）２２４、端点間のパケット損失（path loss ratio）２２５、端点間のジッター２２６が含まれる。ＱｏＳ要求仕様には保証すべき他のＱｏＳ値を追加することも可能である。

本実施の形態においては、ＱｏＳクラス２２３の値として、以下の値を使用することができる。

0: 会話クラス
1: ストリーミング・クラス
2: インタラクティブ・クラス
5: ベストエフォート・クラス

すなわち、ＱｏＳクラスが”０”であり、かつ、要求帯域幅が２００ｋｂｐｓ未満であるときは、ＥＦトラフィックとして扱われる。コアルータにおいて、このＥＦトラフィックには、第１キューが使用される。ＤＳＣＰは、ＥＦに割り当てられた唯一の値”４６”が使用される。

また、ＱｏＳクラスが”０”であり、かつ、要求帯域幅が２００ｋｂｐｓ以上であるときは、ＡＦ１トラフィックとして扱われ、ＤＳＣＰは、ＡＦ１１、すなわち１０が使用される。コアルータにおいて、このＡＦ１トラフィックには、第２キューが使用される。要求帯域幅によって、ＥＦとＡＦ１とを切り替えることによって、優先キューが帯域幅の広いトラフィックによって占有されることを避けることができる。また、帯域幅は狭いが遅延に敏感な音声トラフィックへの悪影響を避けることができる。このため、非優先キューのトラフィックが圧迫されることを避けることができる。

あるいは、要求帯域幅による判定の代わりに、会話音声がＥＦトラフィックとして扱われ、会話ビデオがＡＦ１トラフィックとして扱われるようにしても、同様の効果を得ることができる。ただし、図２Ｃに示すＱｏＳ要求仕様の内容には、音声かビデオかを判定するための情報が含まれていないため、ＱｏＳ仕様のフィールドに、音声かビデオかを判定するための情報を追加する必要がある。あるいは、音声かビデオかを判定するための情報を、セッション開始時に使用されるＳＩＰのＩＮＶＩＴＥメッセージ及びその応答である２００ＯＫメッセージに含まれるメディアの情報を使用して判定する必要がある。ＳＩＰメッセージの情報を使用する場合には、資源管理サーバ１０８が、音声かビデオかを判定するための情報を、ＩＮＶＩＴＥ／２００ＯＫメッセージの交換時にＳＩＰプロキシから受け取る必要がある。

また、ＱｏＳクラスが”１”又は”２”のトラフィックは、ＡＦトラフィックとして扱われ、ＤＳＣＰとしては、それぞれ、ＡＦ３１又はＡＦ２１が使用される。コアルータにおいて、これらのトラフィックには、それぞれ第３キュー又は第２キューが使用される。一方、ＱｏＳクラスが”５”のトラフィックは、ＤＦトラフィックとして扱われ、ＤＳＣＰとしては、ＤＦに割り当てられた値”０”が使用される。コアルータにおいて、このトラフィックには、第４キューが使用される。

図２Ｄは、メッセージタイプが”ＲＥＰ”の場合のメッセージ本体の内容を示す。

ＲＥＰメッセージのフィールド２７１には、条件コード（異常がなければ０）が記述される。フィールド２７２には、有効期限（Refresh period）が記述される。また、これにつづくフィールド２７３には、ＱｏＳ測定結果（QoS Measured）が記述される。ＱｏＳ測定結果の形式は図２Ｃに示すとおりである。さらに、フィールド２７４には、想定されるＱｏＳ値（QoS Expected）が記述される。ＱｏＳの想定値の形式は図２Ｃに示すとおりである。

図３Ａから図３Ｅは、本発明の第１の実施の形態において使用されるポリシー要求・配布のためのプロトコルのデータ形式を示す。

ポリシー要求・配布のためのプロトコルとして、既にＩＥＴＦによって、ＣＯＰＳ（Common Open Policy Service）が標準化されている。このため、ポリシー要求・配布のためにＣＯＰＳを使用することも可能であるが、ここではより実装が容易な非標準のプロトコル（以下、ＳＣＯＰＳという）を使用している。ポリシー要求・配布のためのプロトコルのメッセージタイプには、ＲＲＱ（Resource ReQuest）、ＴＲＱ（Tear ReQuest）、ＲＰＴ（RePorT）、ＤＥＣ（Decision）、及びＲＳＰ（Response）が含まれる。

図３Ａは、ＲＲＱタイプのメッセージの形式を示す。

ＲＲＱタイプのメッセージ（資源予約メッセージ）は以下の内容を含む：資源予約メッセージ送信者のＩＰアドレス３０１及びポートの識別子３０３；資源予約メッセージ受信者のＩＰアドレス３０２及びポートの識別子３０４；ＲＲＱメッセージを送信するボーダルータのＩＰアドレス３０５；資源予約メッセージを受信したネットワーク・インタフェースの識別子（番号）３０６；資源予約メッセージの有効期限３０７；及び、資源予約メッセージに含まれるＱｏＳ仕様３０８。本実施の形態においては、ＲＴＰによる通信だけを扱うため、ＲＲＱ型のメッセージ形式において、ＵＤＰとＴＣＰとの区別可能な記述をしていないが、ＴＣＰや他のＩＰプロトコルによる通信を扱う場合には、そのＩＰプロトコルを表すフィールドを追加するとよい。

図３Ｂは、ＴＲＱタイプのメッセージの形式を示す。

ＴＲＱタイプのメッセージ（資源解放メッセージ）は以下の内容を含む：資源解放メッセージ送信者のＩＰアドレス３１１及びポートの識別子３１３；資源解放メッセージ受信者のＩＰアドレス３１２及びポートの識別子３１４；ＴＲＱメッセージを送信するボーダルータのＩＰアドレス３１５；及び、その資源解放メッセージを受信したネットワーク・インタフェースの識別子（番号）３１６。ＴＲＱタイプのメッセージの形式も、必要に応じて、ＩＰプロトコルをあらわすフィールドを追加するとよい。

図３Ｃは、ＲＰＴタイプのメッセージの形式を示す。

ＲＰＴ型のメッセージ（測定結果報告メッセージ）は以下の内容を含む：測定結果報告メッセージ送信者のＩＰアドレス３２１及びポートの識別子３２３；測定結果報告メッセージ受信者のＩＰアドレス３２２及びポートの識別子３２４；ＲＰＴメッセージを送信するボーダルータのＩＰアドレス３２５；その資源予約メッセージを受信したネットワーク・インタフェースの識別子（番号）３２６；測定結果報告メッセージの有効期限３２７、測定結果報告メッセージに含まれるＱｏＳ測定結果３２８；及び、ボーダルータにおいて測定したネットワーク１１２内のＱｏＳ測定結果３２９。ＲＰＴタイプのメッセージの形式も、必要に応じて、ＩＰプロトコルを表すフィールドを追加するとよい。

図３Ｄ及び図３Ｅは、ＤＥＣタイプのメッセージの形式を示す。

ＤＥＣタイプのメッセージには、図３Ｄに示すエッジルータを設定するための第１の形式と、図３Ｅに示すコアルータを設定するための第２の形式とがある。ＤＥＣ型のメッセージの形式も、必要に応じて、ＩＰプロトコルを表すフィールドを追加してもよい。

図３Ｄは、ＤＥＣ型のメッセージの第１の形式を示す。

このメッセージ、すなわちエッジルータ設定のためのメッセージの形式は、以下の内容を含む：資源予約又は解放をすべきフローの送信者のＩＰアドレス（すなわち、資源予約又は解放メッセージ送信者のＩＰアドレス）３３１及びポートの識別子３１３；資源予約又は解放すべきフローの受信者のＩＰアドレス（すなわち、資源予約又は解放メッセージ受信者のＩＰアドレス）３３２及びポートの識別子３３４；ＤＥＣメッセージによって応答する元のＳＣＯＰＳメッセージ（ＲＲＱ、ＴＲＱ又はＲＰＴ）を送信したボーダルータのＩＰアドレス３３５；資源予約又は解放メッセージを受信したネットワーク・インタフェースの識別子（番号）３３６；資源予約の可否（成功、失敗等）又は予約の解除を表すコード３３７；前述したフローに割り当てられるべきＤＳＣＰ値３３８；前述したフローに割り当てられるべき帯域値３３９；及び、前述したフローに割り当てられるべきバーストサイズ３４０。

図３Ｅは、ＤＥＣ型のメッセージの第２の形式を示す。

このメッセージ、すなわちコアルータ設定のためのメッセージの形式は、以下の内容を含む：ＤＥＣ メッセージによって応答する元のＳＣＯＰＳメッセージ（ＲＲＱ、ＴＲＱ又はＲＰＴ）を送信したボーダルータのＩＰアドレス３３５；その資源予約又は解放メッセージを受信したネットワーク・インタフェースの識別子（番号）３３６；資源予約の可否（成功、失敗等）を表すコード３３７；この設定において扱われる出力インタフェースにおける優先キューを除く３つの帯域分割キューのウェイトｗ２ ３５８、ｗ３ ３５９、ｗ４ ３６０。

図４Ａから図４Ｄは、本発明の第１の実施の形態の通信シーケンスを示す。

本実施の形態においては、コンピュータ１０１が、音声又は映像をＲＴＰによって、コンピュータ１０２に送信する。制御情報はＲＴＣＰによって送受信される。これらの通信は、ＲＴＰ及びＲＴＣＰに関するＩＥＴＦの標準（ＲＦＣ３５５０及びＲＦＣ３５５１）に準拠している。

まず、通信開始時には、コンピュータ１０１が、資源要求メッセージを、コンピュータ１０２に送信する。通信中は、コンピュータ１０２がＱｏＳを計測して、計測結果メッセージを所定のタイミングで（例えば、周期的に）、コンピュータ１０１に送信する。この計測結果メッセージの内容は、ポリシーへのフィードバックのために使用される。通信終了時には、コンピュータ１０１が、資源解放メッセージを、コンピュータ１０２に送信する。

この通信シーケンスを実現するために、コンピュータ１０１及びコンピュータ１０２において動作するアプリケーション・プログラムに、これらのメッセージを送受信する機能を組み込む必要がある。すなわち、通信開始時にコンピュータ１０１で実行されるプログラムに、資源要求メッセージを送信するサブプログラムを組み込み、通信終了時にコンピュータ１０１で実行されるプログラムに、資源解放メッセージを送信するサブプログラムを組み込む。さらに、通信開始時にコンピュータ１０２で実行されるプログラムに、資源要求メッセージを受信するサブプログラムを組み込み、通信終了時にコンピュータ１０２で実行されるプログラムに資源解放メッセージを受信するサブプログラムを組み込む。さらに、通信中にコンピュータ１０２で実行されるパケット受信プログラムに、ＱｏＳ計測のサブプログラムを組み込み、通信中にコンピュータ１０１で実行されるプログラムに、計測結果メッセージを受信するサブプログラムを組み込む。

＜資源要求フェーズ＞
図４Ａは、本発明の第１の実施の形態の資源要求時のシーケンスを示す。

コンピュータ１０１は、コンピュータ１０２に（コンピュータ１０２のＩＰアドレスを受信者に指定して）ＳＮＳＬＰのＲＥＳメッセージ４０１を送信する。ＲＥＳメッセージ４０１は会話音声のための資源予約メッセージである。ＲＥＳメッセージ４０１に含まれる各フィールドには以下の値が記述される。

Refresh period: 5000.
Bandwidth: 80000 (bps).
Y.1541 QoS class: 0
Path latency: 100000 (us).
Path loss ratio: 0.001
Path jitter: 5000 (us).

本実施の形態においては、コンピュータ１０１とコンピュータ１０２とのあいだで会話音声が通信されることを想定した。しかし、他の種類の通信であっても、ＲＥＳメッセージ４０１に含まれるパラメタ値を変えることによって同様に処理することができる。

ＲＥＳメッセージ４０１は、ネットワーク１１２の入口のボーダルータ１０３で捕捉され、そのままＲＥＳメッセージ４０２として転送されると共に、その内容がＳＣＯＰＳのＲＲＱメッセージ４０３にコピーされる。ＲＲＱメッセージ４０３は資源管理サーバ１０８に送信される。すなわち、ＲＥＳメッセージのＩＰヘッダに含まれる送信者及び受信者のＩＰアドレス及びポートの識別子が、ＲＲＱメッセージのフィールド３０１〜３０４にコピーされる。また、ボーダルータ１０３のＩＰアドレス及びＲＥＳメッセージを受信したネットワーク・インタフェースの識別子が、フィールド３０５及び３０６にコピーされる。さらに、ＲＥＳメッセージの有効期限がフィールド３０７にコピーされ、ＱｏＳ要求仕様２１３がフィールド３０８にコピーされる。

転送されたＲＥＳメッセージ４０２は、ネットワーク１１２の出口のボーダルータ１０４に到達し、そのままＲＥＳメッセージ４０５として転送されると共に、その内容がＳＣＯＰＳのＲＲＱメッセージ４０６にコピーされて資源管理サーバ１０８に送信される。すなわち、ＲＥＳメッセージの内容がＲＲＱメッセージ４０６にコピーされると共に、ボーダルータ１０４のＩＰアドレス及びＲＥＳメッセージを受信したネットワーク・インタフェースの識別子が、フィールド３１５及び３１６にコピーされる。

資源管理サーバ１０８は、一つのフロー（コンピュータ１０１の指定されたポートからコンピュータ１０２の指定されたポートへのフロー）に関する、ネットワーク１１２への入口ボーダルータ１０３及び出口ボーダルータ１０４からのＲＲＱメッセージを両方とも受信した場合、当該フローに関する入口ボーダルータ１０３のポリシーを決定して、決定されたポリシーをＤＥＣメッセージ４０７としてボーダルータ１０３に送信する。資源管理サーバ１０８は各フローに関する情報を、そのフローの送信者のＩＰアドレス及びポートの識別子（ＵＤＰポート又はＴＣＰポート）をキーとして、内部データベースに保持する。

ＤＥＣメッセージ４０７の形式は、図３Ｄに示すＳＣＯＰＳのＤＥＣメッセージの形式１である。入口ボーダルータ１０３のためのポリシーの決定法及びその内容（ＤＥＣメッセージ４０７の内容）は、図５を使用して後述する。

また、コアルータ１０６及び／又は１０７のポリシーを変更する必要があれば、コアルータにポリシーを変更するためのＤＥＣメッセージ４０９及び／又は４１０をコアルータ１０６及び／又は１０７に送信する。ＤＥＣメッセージ４０９及び４１０の形式は、図３Ｅに示すＳＣＯＰＳのＤＥＣメッセージの形式２である。さらに、出口ボーダルータ１０４のポリシーを変更する必要があれば、ボーダルータのポリシーを変更するためのＤＥＣメッセージ４０８をボーダルータ１０４に送信する。ＤＥＣメッセージ４０８の形式は、図３Ｄに示すＳＣＯＰＳのＤＥＣメッセージの形式１である。

次に、資源管理サーバ１０８による、入口ボーダルータ１０３のためのポリシーの決定方法について説明する。

図５は、本発明の第１の実施の形態の入口ボーダルータ１０３のポリシーを決定する処理のフローチャートであり、図６は、本発明の第１の実施の形態のコアルータ１０６、１０７のポリシーを決定する処理のフローチャートである。

ポリシーは、入口ボーダルータ１０３及び出口ボーダルータ１０４の両方からの要求が揃った時点で決定される（７０１）。資源管理サーバ１０８は、これらの要求が揃ったときに、処理７０１において、これらの要求に含まれるＱｏＳクラス２２３の値に従って、マーキングすべきＤＳＣＰの値を決定する。

また、これらの要求に含まれる帯域値ｂ、及び、ネットワーク１１２において許容される遅延時間で、要求に含まれる遅延時間以下の値ｄから、ポリシングのための帯域値３３９及びバーストサイズ３４０を決定する。帯域値３３９は、要求に含まれる帯域値ｂを基準とし、バーストサイズ３４０は（ｂ／８）×ｄを基準とする。帯域値３３９及びバーストサイズ３４０によって、ＤＥＣメッセージ４０７の内容を決定する。その後、決定されたＤＥＣメッセージ４０７を、エッジポリシーとして、入口ボーダルータ１０３に送信する。

入口ボーダルータ１０３は、ＤＥＣメッセージ４０７の内容に従って、コンピュータ１０１からコンピュータ１０２への通信のパケットが到着した際に、ＤＳＣＰのマーキング及びポリシングを行うように、ルータ１０３の動作を設定する。

但し、要求に含まれる値をそのまま帯域値３３９及びバーストサイズ３４０の計算に使用するのでなく、また帯域値及びバーストサイズを独立に、”１”を初期値（基準値）とし、フロー毎にファクタを決める。そして、１を超えたり１未満になったファクタを元の値に乗じた値を使用して、帯域値３３９及びバーストサイズ３４０を決定する。決められたファクタの値は当該フローに関する情報の中に記述される。

なお、第１の実施の形態においては、入口ボーダルータ１０３がＤＳＣＰ値をマーキングしたが、コンピュータ１０１がＤＳＣＰ値をマーキングしてもよい。このときは、コンピュータ１０１が端末の機能及びマーキングをするネットワークノードの機能を併せ持つことになる。このとき、入口ボーダルータ１０３は、不正なＤＳＣＰ値が設定されていないか否かを検査し、不正なパケットを廃棄するように設定してもよい。

このように、第１の実施の形態においては、資源管理サーバ１０８が、コンピュータ１０１とコンピュータ１０２との通信経路上にあるルータ、すなわち入口ボーダルータ１０３及び出口ボーダルータ１０４からメッセージを受信する。これによって、資源管理サーバ１０８は、他の方法によらずに、当該フローのネットワーク１１２への入口及び出口を把握することができ、設定対象とすべきボーダルータ及びネットワーク１１２におけるパスを把握できる効果を奏する。

次に、資源管理サーバ１０８は、処理７０２において、入口ボーダルータ１０３と出口ボーダルータ１０４との間のパス上の各コアルータのポリシーを計算し、計算されたポリシーを配布する。すなわち、各コアルータ毎に、図６に示す処理が実行される。そのためには、まず入口ボーダルータ１０３と出口ボーダルータ１０４との間のパスを以下に説明する方法によって決定する。

例えば、コア・ネットワークがＭＰＬＳのように固定的なパスを持つネットワークである場合には、予め全ての入口ボーダルータと出口ボーダルータとの組み合わせについてパスを求めて、求められたパスの情報を入口ボーダルータと出口ボーダルータとの組をキーとしてデータベースに登録する。パスを求める必要が生じる毎に、このデータベースを検索する。

あるいは、コア・ネットワークのパスが動的に変化する場合には、入口ボーダルータ１０３と出口ボーダルータ１０４との間のシグナリング（メッセージのやりとり）を起動し、シグナリング・メッセージが通過したコアルータが、そのコアルータのＩＰアドレス等を、資源管理サーバ１０８に報告する。これによって、資源管理サーバ１０８がパスを把握できる。このようなシグナリングのためには、ＲＳＶＰやＳＮＳＬＰを使用することができる。入口ボーダルータ１０３は、コマンドライン又はＸＭＬによって、外部からＲＳＶＰ及びＳＮＳＬＰによるシグナリングを起動する機能を備える。前述したデータベース又はコアルータからの報告は、各コアルータの出口のネットワーク・インタフェースの識別子を含む。

このようにしてパスが決定されると、パス上の各コアルータは図６に示す処理を実行する。図６に示す処理では、まず、コアルータの出口インタフェースにおける各キュー（ＷＦＱ）の総帯域幅が計算される。そのためには、資源管理サーバ１０８が、既にポリシーが割り当てられたフローの要求帯域を加算した値を保持し、図５に示す処理によって新たに割り当てられた帯域を、総帯域幅に加算すればよい。各キューの総帯域幅の比からウェイトの比をもとめる場合には、インタフェース毎かつキュー毎に決められた”１”を初期値とするファクタを、総帯域幅の比に乗じたものをウェイト比とする。

前述した要求帯域の加算によって、既に各キューに割り当てられているウェイトではバランスが崩れる場合には、新たなウェイトを決めて、決められた新たなウェイトを含むＤＥＣメッセージ４０９又は４１０を送信する。しかし、既に割り当てられているウェイトのままでよい場合は、ＤＥＣメッセージ４０９及び４１０は送信されない。これによって、ＤＥＣメッセージ４０９及び４１０の送信によってコアルータに生じるオーバヘッドを抑制することができる。コアルータ１０６及び１０７は、ＤＥＣメッセージ４０９又は４１０を受信すると、その内容に従って帯域配分を変更する。

図６に示す処理において、加算と減算とが交互に行われると、毎回ＤＥＣメッセージ４０９及び４１０が生成されて、コアルータのオーバヘッドが大きくなるおそれがある。よって、帯域幅の変動量が所定の範囲である場合ば、ポリシーを変更しないようする。

例えば、ベストエフォート・トラフィックには２％の帯域を割り当てられ、調整するべきＡＦトラフィックに対応するＷＦＱが二つあって、それらの総帯域幅の比が１：１であって、それらのファクタがいずれも１である場合は、ＡＦトラフィックに対応するＷＦＱのウェイトはそれぞれ４９％となる。ウェイトの初期値を４９％、４９％と決め、変動許容幅を３％と決める。すなわち、総帯域幅が３％変動してもポリシーは変更されないと決める。すなわち、第１のＷＦＱの総帯域幅が増加して比が５２：４６になってもポリシーは変更されない。しかし、それが５３：４５になると、ウェイトが各々５３％と４５％とに変更される。

ここで変動許容幅を増加すれば（例えば、３％から５％にする）、ポリシーの変更頻度は減少し、より大規模なネットワークでもコアルータへの設定がボトルネックになることを避けることができる。すなわち、コアルータへの設定はよりスケーラブルになる。しかし、変動許容幅を増加させれば、全体としては帯域にまだ余裕があるのに特定のキューの帯域が不足する状態が発生する可能性がある。一方、変動許容幅を減少すれば（例えば、３％から１％にする）、ポリシーの変更頻度は増加してスケーラビリティは低くなるが、帯域をより有効に使用できる可能性がある。

なお、第１の実施の形態においては、ＡＦクラス間でＷＦＱに基づく帯域配分を行っているが、ＡＦクラス間で異なる優先度を設定することも可能である。この場合は、コアルータ１０６及び１０７は、ＤＥＣメッセージ４０９及び４１０を受信した場合に優先度を変更する。

ここで、図４Ａに戻って、シーケンスの説明を続ける。コンピュータ１０２はＲＥＳメッセージ４０５を受信すると、ＲＥＳメッセージ４０５の送信者であるコンピュータ１０１への応答として（コンピュータ１０１のＩＰアドレスを受信者ＩＰアドレスに指定して）ＲＲＥＳメッセージ４１１を送信する。ボーダルータ１０４は、ＲＲＥＳメッセージ４１１を、そのままＲＲＥＳメッセージ４１２として転送する。転送されたＲＲＥＳメッセージ４１２は、ボーダルータ１０３によって捕捉される。

ボーダルータ１０３は、まだＲＲＱメッセージ４０３に対する資源管理サーバ１０８からの応答ＲＳＰ４１８を受信していないため、ＲＲＥＳメッセージをコンピュータ１０１に転送せず、その代わりに、ＲＥＳメッセージ４０１に対する仮の応答であるＮＯＴメッセージ４１３を送信する。これは、コンピュータ１０１にＲＥＳメッセージ４０１に対する応答が届くまでに時間がかかることがあり、ＮＯＴメッセージ４１３を送信することによって、コンピュータ１０１においてタイムアウト処理が行われることを避けるためである。従って、タイムアウトするおそれがない場合はＮＯＴメッセージ４１３を送信する必要はない。

ＳＮＳＬＰは非標準のプロトコルであるため、既存のルータは、ＳＮＳＬＰプロトコルを処理する機能を備えない。ボーダルータ１０３がＳＮＳＬＰの処理機能を備えない場合には、ルータ機能拡張装置１２０１を使用して、ＳＮＳＬＰの処理機能をボーダルータ１０３に実装することができる。

図７は、本発明の第１の実施の形態のルータ機能拡張装置を示すブロック図である。

例えば、ルータ機能拡張装置１２０１のＬＡＮポート１２０２とボーダルータ１０３のＬＡＮポート１２０３とを、ＬＡＮケーブルによって接続する。ルータ機能拡張装置１２０１は、ルータ機能拡張プログラムがインストールされたパーソナル・コンピュータでよい。

ボーダルータ１０３は、ポリシールーティング機能を備える。ポリシールーティング機能は、多くの既存のルータが備えている機能である。ポリシールーティングの設定によって、ボーダルータ１０３は、ボーダルータ１０３のＬＡＮポート１２０３以外のポートに到着したＳＮＳＬＰパケットを、ルータ機能拡張装置１２０１に転送することができる。ポリシールーティングによると、特定の種類のパケットだけを選択的に特定のポートに転送することができる。しかし、到着したＳＮＳＬＰパケットが、ＳＮＳＬＰの下位プロトコルであるＵＤＰのパケットであり、かつ所定のＵＤＰポート番号を含む場合だけ、ＬＡＮポート１２０３に転送するように設定される。

ＳＮＳＬＰは、ＲＴＣＰ上に実装されているが、このＲＴＣＰ通信にはコンピュータ１０１とコンピュータ１０２との間のＲＴＰによる通信に使用されるＵＤＰポート（ポート番号＝ｐ）より、１大きいＵＤＰポート（ポート番号＝ｐ＋１）が使用される。従って、通信に使用されるＲＴＰのＵＤＰポート番号の範囲を予め定めておけば、予め定められた範囲に対応するＲＴＣＰのＵＤＰポートを判定することができる。従って、前述したように、ＳＮＳＬＰパケットをＬＡＮポート１２０３に転送することができる。ＬＡＮポート１２０３に転送されたパケットは、ＬＡＮポート１２０２において、ルータ機能拡張プログラムに捕捉される。

次に、ルータ機能拡張プログラム１３０１の動作を説明する。

図８は、本発明の第１の実施の形態のルータ機能拡張プログラムによる処理を示すフローチャートである。

ルータ機能拡張プログラム１３０１は、Ｌｉｎｕｘなどに実装されているプロミカス・モード（すなわち、通常使用するＩＰ層ではなく、ＯＳＩモデルにおける第２層の情報を指定することによって、当該コンピュータを宛先アドレスとしないパケットまで扱うことができるようにした通信モード）を使用して、ＩＰパケット以外のパケットも含めて、ＬＡＮポート１２０２に到着するすべてのＥｔｈｅｒｎｅｔパケットを捕捉する（Ｅｔｈｅｒｎｅｔは登録商標、以下同じ）。

ＬＡＮポート１２０２にＥｔｈｅｒｎｅｔパケットが到着すると（１３０２）、図８に示すプログラムが起動され、処理１３０３が実行される。すなわち、受信したパケットがＳＮＳＬＰパケットであれば、受信したＳＮＳＬＰパケットの内容をコピーしてＳＣＯＰＳパケットを生成し、生成されたＳＣＯＰＳパケットを資源管理サーバ１０８に送信する。

但し、ボーダルータ１０３が、通常のＥｔｈｅｒｎｅｔパケットとしてＳＮＳＬＰパケットを転送すると、このＳＮＳＬＰパケットがボーダルータ１０３のどのインタフェースに到着したのかを表す情報が、転送されるパケットの中には含まれない。そのため、ＳＣＯＰＳメッセージを生成する際に、図３Ａに示すネットワーク・インタフェース識別子３０６に記述すべき情報が分からない。

この問題を解決するためには以下のようにすればよい。ＬＡＮポート１２０２とＬＡＮポート１２０３との間のネットワークにおいて、タグＶＬＡＮを使用し、ネットワーク・インタフェースとＶＬＡＮ番号との対応を予め決めておく。ボーダルータ１０３がポリシールーティングする場合には、ＳＮＳＬＰパケットが到着したネットワーク・インタフェースに対応するＶＬＡＮ番号を指定すればよい。そして、ルータ機能拡張プログラム１３０１がＳＮＳＬＰパケットを受信した場合には、このＶＬＡＮ番号に対応するネットワーク・インタフェース識別子を求めて、求められたネットワーク・インタフェース識別子をフィールド３０６に記述すればよい。以上説明した処理は資源要求時だけでなく、以下に説明する資源開放時及び計測結果送信時にも適用してもよい。

ここで、図４Ａに戻って、シーケンスの説明を続ける。ボーダルータ１０３は、ＤＥＣメッセージ４０７を受信した場合、以下に説明する設定をする。ＤＥＣメッセージ４０７に含まれる送信者及び受信者のＩＰアドレス及びポートの識別子を含むフローを検出した場合に、検出されたフロー（パケット）にＤＥＣメッセージ４０７に含まれるＤＳＣＰ値３３８をマーキングする。さらに、指定された帯域値３３９を超えるトラフィックが検出されたフローがある場合は、ポリシングをする（すなわち、指定された帯域値を超えないようにトラフィックを制限する）。但し、検出されたフローに指定されたバーストサイズ３４０だけのバーストは許容される。

現在、コマンドによってこのような設定をすることができるルータがある。但し、このような設定が可能なルータがＤＥＣメッセージ４０７を直接受信することができない場合には、ルータ機能拡張装置１２０１によってＤＥＣメッセージ４０７を受信し、ルータ機能拡張装置１２０１がｆｌｏｗＱｏＳコマンドを発行して、発行されたコマンドによってボーダルータ１０３が設定をするようにすればよい。

ボーダルータ１０３は、ＤＥＣメッセージ４０７に基づくポリシーの設定が完了すると、その応答としてＲＰＴメッセージ４１４を資源管理サーバ１０８に送信する。ルータ機能拡張装置１２０１がＤＥＣメッセージ４０７を受信する場合は、ルータ機能拡張装置１２０１がＲＰＴメッセージ４１４を資源管理サーバ１０８に送信する。ボーダルータ１０４がＤＥＣメッセージ４０８を受信した場合も、受信したＤＥＣメッセージに基づくポリシーの設定が完了すると、ＤＥＣメッセージ４０８の応答としてＲＰＴメッセージ４１５を資源管理サーバ１０８に送信する。ボーダルータ１０４がＤＥＣメッセージ４０８を直接受信できない場合は、ルータ機能拡張装置１２０１をボーダルータ１０４に設置して、ルータ機能拡張装置１２０１がボーダルータ１０４の処理を代行すればよい。

コアルータ１０６及び１０７は、それぞれ、ＤＥＣメッセージ４０９及び４１０を受信した場合、以下に説明する設定をする。すなわち、第２キューにはウェイトｗ２を、第３キューにはウェイトｗ３を、第４キューにはウェイトｗ４を、それぞれ割り当てる。但し、ウェイトは既に初期設定されているので、設定されたウェイトを更新して設定する。

コアルータ１０６及び１０７も、それぞれ、ＤＥＣメッセージ４０９及び４１０に基づくポリシーの設定が完了すると、ＤＥＣメッセージ４０９及び４１０の応答としてＲＰＴメッセージ４１６及び４１７を資源管理サーバ１０８に送信する。コアルータ１０６及び／又は１０７がＤＥＣメッセージ４０９及び４１０を直接受信できない場合は、ルータ機能拡張装置１２０１をコアルータ１０６及び／又は１０７に設置して、ルータ機能拡張装置１２０１がコアルータ１０６及び／又は１０７の処理を代行すればよい。

資源管理サーバは全てのポリシー設定が完了すると、すなわち、全てのＲＰＴメッセージ４１４、４１５、４１６及び４１７を受信すると、ＲＲＱメッセージ４０３への応答としてＲＳＰメッセージ４１８をボーダルータ１０３に送信する。ボーダルータ１０３は、ＲＲＥＳメッセージ４１２を既に受信している場合は、ＲＳＰメッセージ４１８を受信した際に、ＲＲＥＳメッセージ４１９として、ＲＲＥＳメッセージ４１２をコンピュータ１０１に転送する。また、まだＲＲＥＳメッセージ４１２を受信していない場合は、ＲＲＥＳメッセージ４１２を受信したときに、ＲＲＥＳメッセージ４１９をコンピュータ１０１に送信する。

＜資源解放フェーズ＞
図４Ｂは、本発明の第１の実施の形態の資源解放時のシーケンスを示す。

コンピュータ１０１は、コンピュータ１０２に（コンピュータ１０２のＩＰアドレスを受信者に指定して）ＳＮＳＬＰのＴＥＡメッセージ４３１を送信する。ＴＥＡメッセージ４３１はネットワーク１１２の入口のボーダルータ１０３で捕捉され、そのままＴＥＡメッセージ４３２として転送されると共に、その内容がＳＣＯＰＳのＴＲＱメッセージ４３３にコピーされる。ＴＲＱメッセージ４３３は資源管理サーバ１０８に送信される。すなわち、ＴＥＡメッセージのＩＰヘッダに含まれる送信者及び受信者のＩＰアドレス及びポートの識別子がＴＲＱメッセージのフィールド３０１〜３０４にコピーされ、ボーダルータ１０３のＩＰアドレスとＴＥＡメッセージを受信したネットワーク・インタフェースの識別子がフィールド３０５、３０６にコピーされる。

転送されたＴＥＡメッセージ４３２がネットワーク１１２の出口のボーダルータ１０４に到達すると、ＴＥＡメッセージ４３２はそのままＴＥＡメッセージ４３５として転送されると共に、ＴＥＡメッセージ４３２の内容がＳＣＯＰＳのＴＲＱメッセージ４３６にコピーされて資源管理サーバ１０８に送信される。すなわち、ＴＥＡメッセージ４３２の内容がＴＲＱメッセージ４３６にコピーされ、ボーダルータ１０４のＩＰアドレスがフィールド３１５にコピーされ、ＴＥＡメッセージ４３５を受信したネットワーク・インタフェースの識別子がフィールド３１６にコピーされる。

資源管理サーバ１０８は、ＴＲＱメッセージ４３６を入口ボーダルータ１０３から受信した場合、資源を解放すべきフローに関する入口ボーダルータ１０３のポリシーを削除するため、ＤＥＣメッセージ４３７をボーダルータ１０３に送信する。ＤＥＣメッセージ４３７は、図３Ｅに示すＳＣＯＰＳのＤＥＣメッセージの形式１である。

また、コアルータ１０６及び／又は１０７のポリシーを変更する必要がある場合は、ポリシー変更のためのＤＥＣメッセージ４３９及び／又は４４０を、それぞれコアルータ１０６及び／又は１０７に送信する。ＤＥＣメッセージ４３９及び４４０は、図３Ｅに示すＳＣＯＰＳのＤＥＣメッセージの形式２である。さらに、出口ボーダルータ１０４のポリシーを削除する必要があれば、ＤＥＣメッセージ４３８をボーダルータ１０４に送信する。ＤＥＣメッセージ４３８は、図３Ｄに示すＳＣＯＰＳのＤＥＣメッセージの形式１である。

コンピュータ１０２はＴＥＡメッセージ４３５を受信すると、ＴＥＡメッセージ４３５の送信者であるコンピュータ１０１への応答として（コンピュータ１０１を受信者ＩＰアドレスに指定して）ＲＴＥＡメッセージ４４１を送信する。ボーダルータ１０４は、ＲＴＥＡメッセージ４４１を、そのままＲＴＥＡメッセージ４４２として転送する。転送されたＲＴＥＡメッセージ４４２は、ボーダルータ１０３によって捕捉される。

ボーダルータ１０３は、まだＴＲＱメッセージ４３３に対する資源管理サーバ１０８からの応答ＲＳＰ４４８を受信していないため、ＲＴＥＡメッセージをコンピュータ１０１に転送せず、その代わりに、ＴＥＡメッセージ４３１に対する仮の応答であるＮＯＴメッセージ４４３を送信する。これは、コンピュータ１０１にＴＥＡメッセージ４３１に対する応答が届くまでに時間がかかることがあり、ＮＯＴメッセージ４４３を送信することによって、コンピュータ１０１においてタイムアウト処理が行われることを避けるためである。従って、タイムアウトするおそれがない場合ときはＮＯＴメッセージ４４３を送信する必要はない。

ボーダルータ１０３は、ＤＥＣメッセージ４３７を受信した場合、以下に説明する設定をする。ＤＥＣメッセージ４３７に含まれる送信者及び受信者のＩＰアドレス及びポートの識別子を含むフローを検出した場合は、このフローについてボーダルータ１０３に設定されたマーキングとポリシングに関する設定を解除する。

ボーダルータ１０３は、ＤＥＣメッセージ４３７に基づくポリシーの設定が完了すると、その応答としてＲＰＴメッセージ４４４を資源管理サーバ１０８に送信する。ボーダルータ１０４がＤＥＣメッセージ４３８を受信した場合も、受信したＤＥＣメッセージ４３８に基づくポリシーの設定が完了すると、その応答としてＲＰＴメッセージ４４５を資源管理サーバ１０８に送信する。

コアルータ１０６及び１０７は、それぞれ、ＤＥＣメッセージ４３９及び４４０を受信した場合、以下に説明する設定をする。すなわち、第２キューにはウェイトｗ２を、第３キューにはウェイトｗ３を、第４キューにはウェイトｗ４を、それぞれ割り当てる。但し、ウェイトは既に初期設定されているので、設定されたウェイトを更新して設定する。

資源管理サーバ１０８が、入口ボーダルータ１０３のためのポリシーを決定する場合は、資源要求時と同様に図５に示す処理を使用すればよい。但し、処理７０２では、当該フローに関する設定を解除するように、ＤＥＣメッセージ４３７の内容を決定する。すなわち、コード３３７には予約解除のコードが指定される。

続いて、処理７０２において、資源管理サーバ１０８は、入口ボーダルータ１０３と出口ボーダルータ１０４との間のパス上の各コアルータのポリシーを計算し、計算されたポリシーを配布する。すなわち、各コアルータ毎に、図６に示す処理が実行される。

この図６に示す処理では、まず、コアルータの出口インタフェースにおける各キュー（ＷＦＱ）の総帯域幅が計算される。そのためには、資源管理サーバ１０８が、既にポリシーが割り当てられたフローの要求帯域を加算した値を保持し、図５に示す処理によって割り当てが解除された帯域を、総帯域幅から減算すればよい。この減算によって、既に各キューに割り当てられているウェイトではバランスが崩れる場合には、新たなウェイトを決めて、新たに決められたウェイトを含むＤＥＣメッセージ４０９及び４１０を送信する。しかし、既に割り当てられているウェイトのままでよい場合は、ＤＥＣメッセージ４０９及び４１０を送信しない。これによって、ＤＥＣメッセージ４０９及び４１０の送信によってコアルータに生じるオーバヘッドを抑制することができる。

コアルータ１０６及び１０７も、それぞれ、ＤＥＣメッセージ４３９及び４４０に基づくポリシーの設定が完了すると、ＤＥＣメッセージ４３９及び４４０の応答としてＲＰＴメッセージ４４６及び４４７を資源管理サーバ１０８に送信する。

資源管理サーバは全てのポリシーの設定が完了すると、すなわち、全てのＲＰＴメッセージ４４４、４４５、４４６及び４４７を受信すると、ＴＲＱメッセージ４３３への応答としてＲＳＰメッセージ４４８をボーダルータ１０３に送信する。ボーダルータ１０３は、ＲＴＥＡメッセージ４４２を既に受信していれば、ＲＳＰメッセージ４４８を受信した際に、ＲＴＥＡメッセージ４４９として、ＲＴＥＡメッセージ４４２をコンピュータ１０１に転送する。また、まだＲＴＥＡメッセージ４４２を受信していない場合は、ＲＴＥＡメッセージ４４２を受信したときに、ＲＴＥＡメッセージ４４９をコンピュータ１０１に送信する。

＜フィードバックフェーズ＞
図４Ｃは、本発明の第１の実施の形態の計測結果送信時（すなわち、フィードバック時）のシーケンスを示す。

コンピュータ１０２は、コンピュータ１０１に（コンピュータ１０１のＩＰアドレスを受信者に指定して）ＳＮＳＬＰのＲＥＰメッセージ４６１を送信する。資源予約（図４Ａ）及び資源解放（図４Ｂ）のときとは、メッセージを送信する方向が逆になっている。ＩＰネットワークにおいては、メッセージの送信の方向が異なる場合には、パケットが同一の経路を通過するとは限らない。しかし、本実施の形態では、同一のボーダルータ（すなわち、ボーダルータ１０４及びボーダルータ１０３）を通過する必-要がある。このようにメッセージを送信する際に、逆向きの経路を逆にたどって転送する仕組みは、ＲＳＶＰにおいて実現されている。よって、転送の方向によって経路が異なるかもしれないネットワーク（例えば、ＩＰネットワーク）においては、ＲＳＶＰと同様の仕組みを使用すればよい。

ＲＥＰメッセージ４６１は図３Ｃに示す形式であるが、このなかでＱｏＳ Ｍｅａｓｕｒｅｄ３２８は図２Ｃに示す形式をし、ＱｏＳに関する測定値を表している。ＱｏＳに関する測定値は、主に、遅延時間、ジッター及びパケット損失率があり、各々、以下のように求めることができる。

第１に、遅延時間２２４は以下のように求めることができる。コンピュータ１０２は、通信中、コンピュータ１０１によって送信されたＲＴＰパケット及びＲＴＣＰパケットを受信する毎に、遅延時間を測定し、測定された遅延時間を記録する。そして、ＲＥＰメッセージを送信する際に、測定結果をＱｏＳ Ｍｅａｓｕｒｅｄ３２８に記述してＲＥＰメッセージを送信する。

すなわち、ＲＴＣＰのＳＲ（Ｓｅｎｄｅｒ Ｒｅｐｏｒｔ）パケットを受信する毎に、ＳＲパケットに含まれる送信時刻を記録する。ＲＴＰパケットが到着する毎に、ＲＴＰパケットに含まれるタイムスタンプと前述したＳＲパケットの送信時刻とから、ＲＴＰパケットの送信時刻を求める。そして、ＲＴＰパケットの送信時刻と受信時刻との差を求めることによって、当該パケットの遅延時間を求めることができる。

前述した送信時刻は、コンピュータ１０１の内部時計に基づいて計測された時刻であるが、前述した受信時刻はコンピュータ１０２の内部時計に基づいて計測された時刻である。これらのコンピュータの内部時計はＩＥＴＦの標準プロトコルＮＴＰ（Network Time Protocol）によって同期することによって、高い精度（例えば、１ミリ秒以下）で合わせることが可能である。従って、遅延時間もほぼ１ミリ秒の精度で求めることができる。しかし、内部時計が正確に同期していない場合には、例えば、非特許文献２、３及び４に開示されている方法を使用することによって、測定値を補正し、高い精度（例えば、１０マイクロ秒以下）を得ることが可能である。

第２に、ジッター２２６は、前述したように求められた遅延時間を蓄積し、蓄積された遅延時間の標準偏差を計算することによって得ることができる。但し、この方法によって、ジッターを精度よく求めることができない場合は、以下の方法を用いることができる。

ＲＴＰパケットは通常、一定間隔で送信される。送信側においてパケットの間隔が十分に正確だと仮定できる場合は、受信側におけるパケット間隔と本来のパケット送信間隔とのズレを求めて、そのズレの２乗平均を計算することによって、ジッターの推定値を求めることができる。

第３に、パケット損失率２２５は、以下のように求めることができる。ＲＴＰパケットにはシーケンス番号があり、送信されるＲＴＰパケットに連続して付されている。従って、受信側において欠落したシーケンス番号がある場合は、欠落したシーケンス番号が付されたパケットが、通信途上で廃棄されたと判定することができる。従って、シーケンス番号の一定の範囲のなかで、廃棄されたパケットの割合を計算することによって、パケット損失率を求めることができる。

ＱｏＳ Ｍｅａｓｕｒｅｄ３２８は、帯域２２２及びＱｏＳクラス２２３のフィールドも含んでいるが、これらは測定値を表す場合には使用されない。

コンピュータ１０２から送出されたＲＥＰメッセージ４６１は、ネットワーク１１２の出口のボーダルータ１０４によって捕捉され、そのままＲＥＰメッセージ４６２として転送されると共に、その内容がＳＣＯＰＳのＲＰＴメッセージ４６３にコピーされて資源管理サーバ１０８に送信される。すなわち、ＲＥＰメッセージのＩＰヘッダに含まれる送信者及び受信者のＩＰアドレス及びポートの識別子が、ＲＰＴメッセージのフィールド３０１〜３０４にコピーされ、ボーダルータ１０４のＩＰアドレスがフィールド３０５６にコピーされ、ＲＥＰメッセージを受信したネットワーク・インタフェースの識別子がフィールド３０６にコピーされる。

転送されたＲＥＰメッセージ４６２は、ネットワーク１１２の入口のボーダルータ１０３に到達し、その内容がＳＣＯＰＳのＲＰＴメッセージ４６６にコピーされて資源管理サーバ１０８に送信される。すなわち、ＲＥＰメッセージの内容がＲＰＴメッセージ４６６にコピーされ、ボーダルータ１０３のＩＰアドレスがフィールド３２５にコピーされ、ＲＥＰメッセージを受信したネットワーク・インタフェースの識別子がフィールド３２６にコピーされる。

資源管理サーバ１０８は一つのフロー（コンピュータ１０１の指定されたポートからコンピュータ１０２の指定されたポートへのフロー）に関して、ネットワーク１１２への入口ボーダルータ１０３からのＲＰＴメッセージ及び出口ボーダルータ１０４からのＲＰＴメッセージの両方を受信した場合、当該フローに関する入口ボーダルータ１０３のポリシーを必要に応じて変更する。このため、ＤＥＣメッセージ４６８をボーダルータ１０３に送信する。ＤＥＣメッセージ４６８は、図３Ｄに示すＳＣＯＰＳのＤＥＣメッセージの形式１である。

また、コアルータ１０６及び／又は１０７のポリシーを変更する必要がある場合は、ポリシー変更のためのＤＥＣメッセージ４７０及び／又は４６９を、それぞれコアルータ１０６及び／又は１０７に送信する。ＤＥＣメッセージ４６９及び４７０は、図３Ｅに示すＳＣＯＰＳのＤＥＣメッセージの形式２である。さらに、出口ボーダルータ１０４のポリシーを変更する必要があれば、ＤＥＣメッセージ４６７をボーダルータ１０４に送信する。ＤＥＣメッセージ４６７、図３Ｄに示すＳＣＯＰＳのＤＥＣメッセージの形式１である。

次に、資源管理サーバ１０８による、資源解放フェーズの処理について説明する。資源解放フェーズの処理は、ポリシーを削除する以外は、資源要求フェーズの処理と同じである。

図９は、本発明の第１の実施の形態のポリシーサーバによるフィードバック時のポリシー改訂処理のフローチャートであり、図１０は、本発明の第１の実施の形態のエッジポリシーを更新する処理のフローチャートであり、図１１は、本発明の第１の実施の形態のコアポリシーを更新する処理のフローチャートである。

資源管理サーバ１０８は、図９に示すように、変更すべきポリシーを決定し、必要に応じて、ＤＥＣメッセージ４６７、４６９、４７０及び４６８を送信する。

具体的には、資源管理サーバ１０８が、入口ボーダルータ１０３及び出口ボーダルータ１０４の両方からＲＰＴメッセージを受信すると（９０１）、まず処理９０２を行う。すなわち、ＲＰＴメッセージに含まれるＲＴＰ送信者及び受信者の識別情報（ＩＰアドレス及びポートの識別子）に基づいて、そのＲＴＰフローを特定し、特定されたＲＴＰフローに関するＱｏＳ要求値を検索する。ＲＰＴメッセージに含まれるＱｏＳ計測値と検索されたＱｏＳ要求値とを比較して、要求値が満たされていなければ原因を推定する。

処理９０３においては、ステップ９０２における推定の結果、資源要求に原因があると判定された場合に、資源の要求に対応するコードをＤＥＣメッセージ４６８の条件コード３３７に記入する。条件コード３３７が記入されたＤＥＣメッセージ４６８は、ボーダルータ１０３に送信される。

例えば、コンピュータ１０１が要求（ＲＥＳメッセージ４０１による要求）を超えるトラフィックを送信している場合は、資源要求に原因があると判定される。これはボーダルータ１０３から、図４Ｃに示すシーケンスとは別に、当該フローのポリシングに関する統計情報を（例えば、ボーダルータ１０３が、ｓｈｏｗＱｏＳｉｐ−ｆｌｏｗコマンドを送信することによって）受け取り、異常なポリシングが発生しているか否かによって、資源要求に原因があるかを判定することができる。ポリシーが設定された全てのフローについて、ボーダルータ１０３から統計情報を受信し、受信した統計情報を記録しておくとよい。

ＤＥＣメッセージ４６８には、ＤＳＣＰ３３８、帯域３３９及びバーストサイズ３４０を記述することができるが、これらのフィールドはコンピュータ１０１が資源要求を改訂する際の参考値を通知するために使用することができる。すなわち、資源要求に含まれるＱｏＳクラスが不正であると推定される場合は、適正と推定されるＱｏＳクラスに対応するＤＳＣＰ値をフィールド３３８に記述することができる。例えば、ＴＣＰトラフィックに対して会話クラスが指定されている場合、ＱｏＳクラスが不正であると推定される。

また、資源要求に含まれる帯域が小さ過ぎると推定される場合は、適正と考えられる帯域の値をフィールド３３９に記述することができる。

ＤＥＣメッセージ４６８に含まれるＤＳＣＰ３３８、帯域３３９及びバーストサイズ３４０の内容は、ＲＥＰメッセージ４６５にコピーされる。コンピュータ１０１は、ＲＥＰメッセージ４６５を受信した場合、ＲＥＰメッセージ４６５に含まれるこれらの値を使用して、資源要求メッセージを発行することによって、資源要求を改訂することができる。これによって、不正な要求を補正することができる効果がある。

処理９０４においては、前述した推定の結果、資源管理サーバ１０８がボーダルータ１０３に配布したエッジポリシーに原因があると判定された場合に、ＤＥＣメッセージ４６８によって当該エッジポリシーを更新する。具体的には、図１０に示した手順に従ってエッジポリシーを更新する。

まず、処理１００１においては、当該フローに関するエッジポリシーに原因があると判定された場合に、原因があると判定されたエッジポリシーを更新する。すなわち、パケット廃棄率が要求値より大きく、当該エッジポリシーのポリシングで指定された帯域値が小さく設定されており、バーストサイズが小さく設定されている、の少なくとも一つの（すなわち、ポリシング・ファクタが過小な）場合、当該エッジポリシーに原因があると判定し、ポリシングで指定された帯域値及び／又はバーストサイズを大きく設定し直す（ポリシング・ファクタを増加させる）。

これによって、当該フローのＱｏＳを向上させ、要求範囲内とすることが可能となる効果がある。但し、ポリシング指定の最適値は、条件によって変化するため、最適値を求めて、求められた最適値を設定することは困難である。ポリシング指定が大幅に変化すると、ネットワークを不安定化させる可能性があるため、変化量を小さくし（すなわち、フィードバック量を抑制して）、次回の測定時に再調整するとよい。

続いて、処理１００２においては、他のフロー（例えば、コンピュータ１２１とコンピュータ１２２との間の通信）に関するエッジポリシーに原因があると判定された場合に、原因があると判定されたエッジポリシーを更新する。すなわち、パケット廃棄率、遅延及び／又はジッター等が要求値より大きく、他のエッジポリシーのポリシングで指定された帯域値及び／又はバーストサイズを大きく設定している（すなわち、ポリシング・ファクタが過大な）場合、他のエッジポリシーに原因があると判定して、ポリシングで指定された帯域値及び／又はバーストサイズを小さく設定し直す（ポリシング・ファクタを減少させる）。

これによって、他のフローのＱｏＳを要求の範囲に留めたまま、当該フローのＱｏＳを向上させ、要求範囲内とすることができる効果がある。

図９に示す処理に戻り、処理９０５においては、上記の推定の結果、資源管理サーバ１０８がコアルータ１０６及び／又はコアルータ１０７に配布したコアポリシーに原因があると判定された場合に、ＤＥＣメッセージ４６９及び／又はＤＥＣメッセージ４７０によってコアポリシーを更新する。例えば、当該クラス（当該フローに割り当てられたＤＳＣＰを使用しているフロー群）に関しては問題（遅延及び／又はジッターが過大等）が発生しているのに対して、他のクラス（他のＤＳＣＰを使用しているフロー群）には余裕がある（遅延及び／又はジッター等が要求値より十分に小さい）場合に、コアポリシーに原因があると判定される。このような場合は、図１１に示す手順に従ってコアポリシーを更新する。

すなわち、処理１１０１において、問題のない他のクラスから当該クラスに資源を振り替える。すなわち、ＷＦＱのウェイトを計算する際に、当該クラスのファクタを増加させ、他のクラスのファクタを減少させる。これによって、他のクラスに属するフローのＱｏＳをほぼ要求の範囲に留めたまま、当該クラスに属するフローのＱｏＳを向上させ、要求範囲内とすることができる効果がある。特に、当該クラスの第１のフローはフィードバック機構がない（すなわち、本実施の形態によるフィードバック時の処理が行われない）場合、当該クラスの第２のフローにフィードバック機構があれば、それによって当該クラスの全てのフローのＱｏＳが向上するため、第１のフローのＱｏＳも向上する効果がある。

入口ボーダルータ１０３は、基本的には、ＲＥＰメッセージ４６２の内容を、そのままＲＥＰメッセージ４６５としてコンピュータ１０１に転送する。但し、ＤＥＣメッセージ４６８によって、資源要求に不正があると判定された場合は、不正な資源要求の内容をＲＥＰメッセージ４６５に反映させる。すなわち、条件コード２７１にＤＥＣメッセージ４６８の条件コード３３７に対応するコードを記入する。また、ＤＥＣメッセージ４６８に帯域の参考値３３９が記入されていれば、記入された帯域の参考値をＱｏＳ Ｅｘｐｅｃｔｅｄ２７４における帯域値とする。ＱｏＳクラスの参考値が記入されている場合は、記入されたＱｏＳクラスの参考値をＱｏＳ Ｅｘｐｅｃｔｅｄ２７４におけるＱｏＳクラスとする。

コンピュータ１０２はＲＥＰメッセージ４６５を受信すると、ＲＥＰメッセージ４６５の送信者であるコンピュータ１０１への応答として（コンピュータ１０１を受信者ＩＰアドレスに指定して）ＲＲＥＰメッセージ４７１を送信する。ボーダルータ１０４は、ＲＲＥＰメッセージ４７１を、そのままＲＲＥＰメッセージ４７２として転送する。転送されたＲＲＥＰメッセージ４７２は、ボーダルータ１０３によって捕捉される。

ボーダルータ１０３は、まだＲＰＴメッセージ４６３に対する資源管理サーバ１０８からの応答ＲＳＰ４７８を受信していないため、ＲＲＥＰメッセージをコンピュータ１０１に転送せず、その代わりに、ＲＥＰメッセージ４６１に対する仮の応答であるＮＯＴメッセージ４７３を送信する。これは、コンピュータ１０１にＲＥＰメッセージ４６１に対する応答が届くまでに時間がかかることがあり、ＮＯＴメッセージ４７３を送信することによって、コンピュータ１０１においてタイムアウト処理が行われることを避けるためである。従って、タイムアウトするおそれがない場合はＮＯＴメッセージ４７３を送信する必要はない。

ボーダルータ１０３は、ＤＥＣメッセージ４６７を受信した場合、以下に説明する設定をする。ＤＥＣメッセージ４６７に含まれる送信者及び受信者のＩＰアドレス及びポートの識別子を含むフローを検出した場合に、検出されたフロー（パケット）にＤＥＣメッセージ４６７に含まれるＤＳＣＰ値３３８をマーキングする。さらに、指定された帯域値３３９を超えるトラフィックが検出されたフローがある場合は、ポリシングを行う（すなわち、指定された帯域値を超えないようにトラフィックを制限する）。但し、検出されたフローに指定されたバーストサイズ３４０だけのバーストは許容される。但し、当該フローに関する設定はすでに存在しているので、既存の設定を更新するかたちで設定を行う。

ボーダルータ１０３はＤＥＣメッセージ４６７に基づくポリシーの設定が完了するとその応答としてＲＰＴメッセージ４７４を資源管理サーバ１０８に送信する。ボーダルータ１０４がＤＥＣメッセージ４６８を受信した場合も、それにもとづくポリシーの設定が完了すると、その応答としてＲＰＴメッセージ４７５を資源管理サーバ１０８に送信する。

コアルータ１０６及び１０７がそれぞれＤＥＣメッセージ４７０及び４６９を受信すると、つぎのような設定を実行する。第２キューにはウェイトとしてｗ２、第３キューにはウェイトとしてｗ３、第４キューにはウェイトとしてｗ４を割り当てる。但し、ウェイトの設定はすでに存在しているので、それを更新して設定する。

コアルータ１０６及び１０７も、それぞれＤＥＣメッセージ４７０及び４６９に基づくポリシーの設定が完了すると、その応答としてＲＰＴメッセージ４７６及び４７７を資源管理サーバ１０８に送信する。

資源管理サーバは全てのポリシー設定が完了すると、すなわち、全てのＲＰＴメッセージ４７４、４７５、４７６及び４７７を受信すると、ＲＰＴメッセージ４６３への応答としてＲＳＰメッセージ４７８をボーダルータ１０３に送信する。ボーダルータ１０３は、ＲＲＥＰメッセージ４７２を既に受信している場合は、ＲＳＰメッセージ４７８を受信したときに、ＲＴＥＡメッセージ４７９として、ＲＲＥＰメッセージ４７２をコンピュータ１０１に転送する。また、まだＲＲＥＰメッセージ４７２を受信していない場合は、ＲＲＥＰメッセージ４７２を受信したときに、ＲＲＥＰメッセージ４７９をコンピュータ１０１に送信する。

以上説明した第１の実施の形態は以下の効果がある。第１に、資源要求時及び資源解放時と同一のプロトコル・スタックを使用することによって、ＱｏＳ測定結果をフィードバックするために、新たなプロトコル・スタックを開発する必要がない。よって、開発コストを抑制することができる効果がある。

第２に、ＱｏＳ測定結果をフィードバックするためのメッセージが資源要求時及び資源解放時で同一のパスを経由し同一の機構を使用するため、資源の調整が容易である効果がある。また、複数の機構の間での調停が不要になる効果がある。

第３に、コアルータは、資源要求、資源解放及び測定結果フィードバックのためのメッセージを処理せず、また、資源管理サーバからコアルータへの設定は、複数回のメッセージングについて１回だけ行われる。このため、全てのルータが資源要求等のメッセージを処理する方法に比べて、コア網における負荷を低減できる効果がある。さらに、スケーラブルなＱｏＳ保証が実現できる効果がある。

第４に、コア網における不適正な帯域配分等によって引き起こされる問題は、当該ＱｏＳクラスに属するフロー全体の問題である。このため、全てのフローを測定した結果をフィードバックしなくても、いくつかのフローからのフィードバックに基づいて帯域配分が補正される。よって、測定及びフィードバックが行われなかったフローのＱｏＳも改善される効果がある。

＜実施形態２＞
次に本発明の第２の実施の形態について説明する。

第２の実施の形態においては、計測結果の送信時（すなわち、フィードバック時）の各メッセージの内容と、各機器における処理内容が異なる点を除き、第１の実施の形態と同じである。第２の実施の形態においては、以下に説明するように、ＱｏＳ上の問題が発生した場合に、第１に、アプリケーション（特に、受信側のアプリケーション）を、ＱｏＳ上の問題の解決に参加させ、第２に、通信経路上の複数のネットワーク及び／又は複数のネットワーク機器の間で分担して解決をする。なお、第２の実施の形態では、前述した第１及び第２の特徴の両方を、第１の実施の形態のネットワークシステムに適用した例を示すが、第１又は第２の実施の形態のいずれかを、第１の実施の形態のネットワークシステムに適用してもよい。

アプリケーションを問題解決に参加させることは、以下に説明する意味である。第１の実施の形態においては要求値が満たされない場合、この問題を解決するために送信側のアプリケーションが要求値の変更を示唆されることはあったが、受信側のアプリケーションは問題の解決には参加していなかった。しかし、問題を解決するために受信側のアプリケーションが役割を果たせる場合がある。

例えば、遅延の測定結果は要求仕様を満たしているが、ジッターの測定結果は要求仕様より大きい場合は、受信側のアプリケーションがジッター・バッファのサイズを拡大することができれば、受信時の要求仕様を緩和しても、アプリケーションからの出力品質を維持することが可能である。このような場合には、ネットワークとアプリケーションとを協調させて、ＱｏＳの問題を解決することができる。

また、通信経路上の複数のネットワーク又は複数のネットワーク機器の間で問題解決を分担することは、以下に説明する意味である。図１に示すネットワークシステムは、コンピュータ１０１からコンピュータ１０２までの間に、三つのネットワーク（すなわち、ネットワーク１１０、ネットワーク１１２、ネットワーク１１１）を含む。第１の実施の形態においては、コンピュータ１０１を除けば、ネットワーク１１２（すなわち、入口ボーダルータ１０３から出口ボーダルータ１０４までの間）に、ＱｏＳを低下させる原因がある場合に、適切な処理が行われる。ネットワーク１１０及びネットワーク１１１も、ネットワーク１１２と同じ構造をしていれば、これらのネットワークも同じフィードバック処理を行うことができる。しかし、ネットワーク１１０、１１１及び１１２が連携せずにフィードバック処理を行えば、過剰な対策をとって、コスト高になる可能性がある。

また、特定のフロー及び／又は特定のクラスのＱｏＳを過剰に改善しようとした結果、他のフロー及び／又はクラスに悪影響を与える可能性がある。第２の実施の形態においては、ネットワークとアプリケーション間及びネットワーク間で情報を交換することによって、これらの問題を解決する。

第２の実施の形態において、計測結果送信時のシーケンスは図４Ｃに示すとおりである。また、ＲＥＰメッセージ４６１に含まれるＱｏＳ測定結果３２８の内容も同じである。しかし、ＱｏＳ Ｅｘｐｅｃｔｅｄ２７４を使用して、受信者からネットワークへ、ネットワーク間、及びネットワーク機器間で情報を交換する。

図１２Ａは、本発明の第２の実施の形態のアクセスネットワーク１１１の構成を示すブロック図であり、図１２Ｂは、本発明の第２の実施の形態のアクセスネットワーク１１２の構成を示すブロック図である。

コンピュータ１０２は、ネットワーク１１１のボーダルータ１４０１に接続され、ボーダルータ１４０２は、ネットワーク１１２のボーダルータ１０４に接続されている。また、ネットワーク１１０のボーダルータ１４１１はネットワーク１１２のボーダルータ１０３に接続され、ボーダルータ１４１２はコンピュータ１０１に接続されている。

コンピュータ１０１からコンピュータ１０２へ、ストリーミングデータが転送され、遅延が４００ミリ秒及びジッターが５０ミリ秒であるＱｏＳ要求仕様が定められている。コンピュータ１０２における測定の結果、遅延は２００ミリ秒であり、ジッターが２００ミリ秒である場合、遅延は要求仕様内であるが、ジッターが要求仕様を満たさない。

コンピュータ１０２が１００ミリ秒分のジッター・バッファを追加すれば、ジッター・バッファの入口におけるジッターが１５０ミリ秒までは耐えられる場合、ジッターの値として１５０ミリ秒が指定されたＲＥＰメッセージ４６１Ａを送信する。このＲＥＰメッセージ４６１Ａは、図２Ｄに示すＲＥＰメッセージ４６１と同じ形式を用い、ＱｏＳ Ｅｘｐｅｃｔｅｄ２７４にジッターの値として１５０ミリ秒を指定すればよい。ジッターの測定値は２００ミリ秒なので、ネットワークにおいてはジッターを５０ミリ秒減少させればよい。

ボーダルータ１４０１は、このＲＥＰメッセージ４６１Ａを受信し、受信したＲＥＰメッセージ４６１Ａの内容をネットワーク１１１の資源管理サーバ１４０４に報告する。また、ボーダルータ１４０２もこのＲＥＰメッセージ４６１Ａを受信し、受信したＲＥＰメッセージ４６１Ａの内容をネットワーク１１０の資源管理サーバ１４０４に報告する。

資源管理サーバ１４０４は、ボーダルータ１４０２及びコアルータ１４０３に更新されたポリシーを配布する。このポリシーは、ジッターを５０ミリ秒だけ減少させるように帯域やＷＦＱのウェイトが調整されたものである。ボーダルータ１４０２は、ＱｏＳ Ｅｘｐｅｃｔｅｄ２７４のジッターの値を５０ミリ秒だけ増加させる内容を含むＲＥＰメッセージ４６１Ｂを、ボーダルータ１０４に送信する。

なお、図４Ｃに示すＲＥＰメッセージ４６１は、コンピュータ１０２とボーダルータ１４０２との間のＲＥＰメッセージ４６１Ａ、及びボーダルータ１４０２とボーダルータ１０４との間のＲＥＰメッセージ４６１Ｂに分割されて転送される。

ボーダルータ１０４は、このＲＥＰメッセージ４６１Ｂを受信すると、受信したＲＥＰメッセージ４６１ＢをＲＥＰメッセージ４６２として転送し、さらに受信したＲＥＰメッセージ４６１Ｂの内容を資源管理サーバ１０８に報告する。５０ミリ秒だけジッターを減少させるように帯域やＷＦＱのウェイトを調整したポリシーが、資源管理サーバ１０８からボーダルータ１０３及びコアルータ１０６及び１０７に配布される。但し、コアルータ１０６及び１０７へのポリシーは、ＲＥＰメッセージが到着する毎に毎回配布される必要はなく、必要に応じて何回かに１回、配付すればよい。これによってコアルータ１０６及び１０７のオーバヘッドを減少させることができる。

また、ボーダルータ１０３はＲＥＰメッセージ４６２のＱｏＳ Ｅｘｐｅｃｔｅｄ２７４のジッターの値を５０ミリ秒増加させた内容のＲＥＰメッセージ４６５Ａをボーダルータ１０４に送信する。また、ＲＥＰメッセージ４６５Ａは、ネットワーク１１０にも送信される。

ボーダルータ１４１１は、このＲＥＰメッセージ４６５Ａを受信すると、受信したＲＥＰメッセージ４６５Ａの内容をネットワーク１１０における資源管理サーバ１４１４に報告する。また、受信したＲＥＰメッセージ４６５Ａの内容は、ボーダルータ１４１２からも資源管理サーバ１４１４に報告される。資源管理サーバ１４１４は、ボーダルータ１４１２及びコアルータ１４１３に更新されたポリシーを配布する。このポリシーは５０ミリ秒だけジッターを減少させるように、帯域及び／又はＷＦＱのウェイトを調整したものである。

また、ボーダルータ１４１２は、受信したＲＥＰメッセージ４６５ＡをＲＥＰメッセージ４６５Ｂとして、コンピュータ１０１に送信する。ＲＥＰメッセージ４６５Ｂの内容は、ＱｏＳ Ｅｘｐｅｃｔｅｄ２７４のジッターの値を５０ミリ秒だけ増加させたものである。

なお、図４Ｃに示すＲＥＰメッセージ４６５は、ボーダルータ１０３とボーダルータ１４１２との間のＲＥＰメッセージ４６５Ａ、及びボーダルータ１４１２とコンピュータ１０１との間のＲＥＰメッセージ４６５Ｂに分割されて転送される。

コンピュータ１０１に届いたＲＥＰメッセージ４６５ＢのＱｏＳ Ｅｘｐｅｃｔｅｄ２７４のジッターの値は、測定したジッターの値２００ミリ秒より大きい３００ミリ秒となっている。すなわち、１００ミリ秒だけ過剰に対策がなされており、コスト的に不利である。従って、コンピュータ１０１は、ＲＥＰメッセージ４６５に対する応答ＲＲＥＰメッセージ４７１のＱｏＳ Ｅｘｐｅｃｔｅｄ２７４にジッターの値を記述して、ボーダルータ１０３に通知する。

各ネットワークは、ＲＲＥＰメッセージ４７１及びそれと同じ内容のＲＲＥＰメッセージ４７２を受信することによって、ジッターの値を５０ミリ秒ずつ減少させようとした。しかし、減少させる幅を２００／３００（２／３）としてもよい。すなわち、約１７ミリＧＢ用だけ減少させればよいことが分かる。

従って、各ボーダルータのポリシーを変更するか、又は各資源管理サーバと通信することによって、新たなポリシーを受信する。又は、ＤＥＣメッセージ４６８、４６９及び４７０によってはポリシーを更新せず、仮の決定だけを各ルータに伝える。なお、ＲＲＥＰメッセージの受信後に各ボーダルータから通知を受けてから、新たにＤＥＣメッセージによってポリシーを配布してもよい。

前述したように、第２の実施の形態によると、ＱｏＳ上の問題が発生したときに、第１にアプリケーション（特に、受信側のアプリケーション）を、ＱｏＳ上の問題の解決に参加させることができ、第２に、通信経路上の複数のネットワーク及び／又は複数のネットワーク機器の間で分担して解決することができる。よって、より良いＱｏＳをより低コストに実現させることができる効果がある。

＜実施形態３＞
前述した第１の実施の形態においては、資源管理サーバを経由してポリシーを設定した。しかし、第１の実施の形態に、以下の変更を加えることもできる。すなわち、図４Ｃのシーケンスにおいては各ルータが、自ルータに関するＱｏＳ改善目標をＳＮＳＬＰのメッセージとして受け取ることができるので、資源管理サーバを使用しなくても、自ら設定を行うことができる。このようにすれば、資源管理サーバにメッセージが集中してボトルネックになることが避けられる効果がある。

次に、本発明の第３の実施の形態について説明する。

第３の実施の形態においては、計測結果の送信時（すなわち、フィードバック・フェーズ）におけるシーケンスとして、前述した図４Ｃに示すシーケンスを使用する代わりに図４Ｄに示すシーケンスを使用する。また、第３の実施の形態においては、第１の実施の形態におけるコンピュータ１０１からコンピュータ１０２への通信と同様に、コンピュータ１２１からコンピュータ１２２に音声をコーデック Ｇ．７１１によってデータを送信する。

コンピュータ１２１によって生成されたトラフィックは、アクセスネットワーク１１０を経由して、ボーダルータ１０３からキャリアのコアネットワーク１１２に入る。ネットワーク１１２に入ったトラフィックは、コアルータ１０６及びコアルータ１０７を経由して、ボーダルータ１０４においてネットワーク１１２から出力され、ネットワーク１１１を経由して、コンピュータ１２２に到達する。コンピュータ１２１及び１２２の構成は、コンピュータ１０１及び１０２の構成と同じである。

資源要求フェーズにおける、コンピュータ１２１とコンピュータ１２２の間の通信シーケンスは、図４Ａ及びその説明において、コンピュータ１０１をコンピュータ１２１に置き換え、コンピュータ１０２をコンピュータ１２２に置き換えたものである。また、コンピュータ１２１とコンピュータ１２２との間の資源解放フェーズにおける通信シーケンスは、図４Ｂ及びその説明において、コンピュータ１０１をコンピュータ１２１に置き換え、コンピュータ１０２をコンピュータ１２２に置き換えしたものである。

以下、フィードバック・フェーズにおけるシーケンス図４Ｄについて説明する。

図４Ｃに示すシーケンスにおいては、フィードバック時のルータの設定は、資源管理サーバ１０８（第２の実施の形態においては、資源管理サーバ１４０４、１４１４も）が変更していた。しかし、ネットワークの状態が頻繁に変化する場合には、頻繁に設定変更が必要になるので、資源管理サーバの負荷が大きくなる。そのため、第３の実施の形態においては、各ルータが変更を実行できるようにし、コアルータの負荷を減少させるために、コア・ネットワーク内だけのシグナリングを導入している。

図４Ｄにおいては、まず、コア・ネットワーク内におけるシグナリングが発生している。すなわち、まずボーダルータ１０４からＲＥＰメッセージ４８１が送信される。これは図４Ｃに示すシーケンスのようにフロー単位で送信するのではなくて、クラス毎に送信される。すなわち、特定のＤＳＣＰに対応するクラスのＱｏＳに問題がある場合に、一つのＲＥＰメッセージが生成される。ＱｏＳ上の問題は、ＲＥＰメッセージ４８１以前にボーダルータ１０４がコンピュータ１０２等から受信したＲＥＰメッセージや、ボーダルータ１０４で測定された出力キューに関する統計情報（キューにおけるパケット廃棄量やキュー長等の情報）が正常範囲から外れることによって検知される。

ボーダルータ１０４は、検知されたＱｏＳ上の問題を解決するために、ボーダルータ１０４における対策によって改善される範囲（遅延、ジッター等の量（差））を推定し、推定された遅延量等をＲＥＰメッセージ４８１のＱｏＳ Ｅｘｐｅｃｔｅｄ２７４に記述し、ＲＥＰメッセージ４８１をコアルータ１０７に送信する。

コアルータ１０７は、コアルータ１０７における対策によって改善される範囲（遅延、ジッターなどの量（差））を推定し、ＲＥＰメッセージ４８１のＱｏＳ Ｅｘｐｅｃｔｅｄ２７４の各フィールドの値に、推定された遅延量等を加算した値をＲＥＰメッセージ４８２に記述し、ＲＥＰメッセージ４８２をコアルータ１０６に送信する。

コアルータ１０６は、コアルータ１０６における対策によって改善される範囲（遅延、ジッターなどの量（差））を推定し、ＲＥＰメッセージ４８２のＱｏＳ Ｅｘｐｅｃｔｅｄ２７４の各フィールドの値に、推定された遅延量等を加算した値をＲＥＰメッセージ４８３に記述し、ＲＥＰメッセージ４８３をボーダルータ１０３に送信する。

各ルータにおける対策によって改善される遅延、ジッターの量は、以下のように推定される。

インターネット・トラフィックと似たトラフィックを生成するトラフィック生成装置（例えば、ＭＭＰＰ（Markov-Modulated Poisson Process）モデルに準拠したトラフィック生成装置）等を使用して、予め、会話音声、会話ビデオ、ストリーミング・ビデオ、Ｗｅｂ、ＦＴＰ及び制御トラフィック（ＳＩＰ及びＲＴＣＰ）等、様々なトラフィックを様々な割合で生成し、様々な条件の下で遅延、ジッター及びパケット損失率の平均値を計測する。このように事前に計測した状態のうち、推定時の状態に近く、かつ要求された遅延、ジッター及びパケット損失率を満たす状態における計測値を、推定値とすることができる。

また、推定時の状態に近いいくつかの状態における計測値から補間することによって、推定値を求めることもできる。推定時の状態と事前の状態との（距離の）近さは、ＱｏＳクラス毎のトラフィックの遅延、ジッター及びパケット損失率等の数値の近さを総合的に判定して決めることができる。例えば、遅延、ジッター及びパケット損失率のそれぞれについて距離を求め、それらを要素とするベクトル同士の距離として決める。

ボーダルータ１０３は、受信したＲＥＰメッセージ４８３のＱｏＳ Ｅｘｐｅｃｔｅｄ２７４の値によって、各ルータにおける対策がどれだけ過剰であるかを推定し、推定結果をＲＲＥＰメッセージ４８４に記述して返信する。コア・ネットワーク内の各ルータはＲＲＥＰメッセージ４８４及びそれが転送されたメッセージであるＲＲＥＰメッセージ４８５及び４８６の内容によって、実際にＱｏＳ上の対策をする。

対策がどれだけ過剰かは、端点間で交換されるＲＥＰメッセージ及びＲＲＥＰメッセージの内容に依存する。フロー毎に状況は異なるため、ボーダルータ１０３は、フロー毎の状況を平均して、対策が過剰かを判定する。端点間で交換されるメッセージ（ＲＥＰ４９１、４９２及び４９３、及びＲＲＥＰ４９７、４９８及び４９９等）は判定後に到着するため、判定結果と整合しない可能性があるが、その場合は、再度コア・ネットワーク内のシグナリングによって、ポリシーを更新する。

以上説明したように、第３の実施の形態によると、ＱｏＳ上の問題が発生した場合に、第１及び第２の実施の形態の効果に加え、資源管理サーバへの負荷の集中を避けることができる効果がある。また、フロー毎のメッセージをコアルータにおいて処理する必要がないため、スケーラブルなＱｏＳ保証を実現できる効果がある。

＜実施形態４＞
次に、本発明の第４の実施の形態について説明する。

図１３は、本発明の第４の実施の形態のネットワークシステムの構成を示すブロック図である。

第４の実施の形態においては、コンピュータ１０１からコンピュータ１０２に音声又は画像を送信する。コンピュータ１０１によって生成されたトラフィックは、ホームゲートウェイ５０１及びネットワーク１１０を経由して、ボーダルータ１０３からキャリアのネットワーク１１２に入る。ネットワーク１１２は、ボーダルータ１０３及び１０４、及びコアルータ５０５、５０６及び５０７を備える。

ネットワーク１１２に入ったトラフィックは、コアルータ５０５を経由して、ボーダルータ１０４においてネットワーク１１２から出力され、ネットワーク１１１及びホームゲートウェイ５０２を経由して、コンピュータ１０２に到達する。ネットワーク１１２のＱｏＳは、資源管理サーバ１０８によって管理されている。

第４の実施の形態のコンピュータ１０１及び１０２は、前述した第１から第３の実施の形態のコンピュータとは違って、ＳＮＳＬＰによるシグナリングの機能を備えない。第４の実施の形態においては、端点間でＳＮＳＬＰによるシグナリングを行う代わりに、ゲートウェイ５０１及び５０２が、コンピュータ１０１及び１０２からのメッセージを参照し、ＳＩＰによるセッション開始及び終了時に送信されるメッセージの内容を書き換えることによって、資源管理サーバ１０８にＱｏＳ要求仕様を伝える。さらに、ゲートウェイ５０２が測定したＱｏＳ測定結果を、セッション管理サーバ５０３を経由して、ゲートウェイ間で通信することによって、ネットワークにフィードバックする。コンピュータ１０１とゲートウェイ５０１との間、及びコンピュータ１０２とゲートウェイ５０２との間にＱｏＳを悪化させる原因がなければ、この方法によって、ＱｏＳ測定機能を備えない端点間でも実質的に端点間のＱｏＳを保証することができる。

図１４Ａから図１４Ｃは、本発明の第４の実施の形態の通信シーケンスを示す。

＜資源要求フェーズ＞
図１４Ａは、本発明の第１の実施の形態の資源要求時のシーケンスを示す。

コンピュータ１０１は、コンピュータ１０２に（コンピュータ１０２のＵＲＩを受信者に指定して）ＳＩＰのＩＮＶＩＴＥメッセージ６０１を送信する。ここで、ＳＩＰ（Session Initiation Protocol）は通信セッションの開始及び終了を制御するために設けられたＩＥＴＦの標準プロトコルである。ＩＮＶＩＴＥメッセージ６０１は、ＳＤＰ（Session Description Protocol）のメッセージを含んでいるが、このＳＤＰメッセージは以下のメディア指定を含む。

m=audio 8000 RTP/AVP 98
a=rtpmap:98 PCMU/8000/1
m=audio 8002 RTP/AVP 98
a=rtpmap:98 PCMU/8000/2
a=recvonly

このＳＤＰメッセージは、ＵＤＰポート８０００において、Ｇ．７１１というコーデックに従う双方向の１チャンネルの通信を行い、ポート８００２において、Ｇ．７１１の片方向（受信のみ）の２チャンネルの通信を行うことを意味する。従って、セッション管理サーバ５０３は、ＩＮＶＩＴＥメッセージ６０２の受信時に、ＲＴＰによる通信にＥｔｈｅｒｎｅｔを使用する場合は、ポート８０００を用いて、帯域幅が８０ｋｂｐｓの双方向通信を行い、ポート８００２を用いて、帯域幅が１４０ｋｂｐｓの単方向（受信のみ）の通信を行うことを知る。

ＩＮＶＩＴＥメッセージ６０２は、ゲートウェイ５０２において捕捉される。ＩＮＶＩＴＥメッセージ６０２に含まれるメディア指定の最初の２行に対して、以下の行をＩＮＶＩＴＥメッセージ６０２に追加する。

a=y1541-qos-class:0
a=path-latency:100000
a=path-loss-ratio:1000
a=jitter:50000

１行目はＹ．１５４１のＱｏＳクラスの指定であり、会話クラスが指定される。２行目は遅延の指定であり、単位はマイクロ秒である。従って、前述した指定は１００ミリ秒を表す。３行目はパケット損失率の指定であり、単位は0.00000001である。従って、前述した指定は0.001を表す。４行目はジッターの指定であり、単位はマイクロ秒である。従って、前述した指定は５０ミリ秒を表す。これらの指定はＩＥＴＦにおいて標準化されていない。

また、ＩＮＶＩＴＥメッセージ６０２に含まれるメディア指定の最後の３行に対して、以下の行をＩＮＶＩＴＥメッセージ６０２に追加する。その上でＩＮＶＩＴＥメッセージ６０２は、セッション管理サーバ５０３に転送される。

a=y1541-qos-class:1
a=path-latency:400000
a=path-loss-ratio:1000
a=jitter:50000

１行目はＹ．１５４１のＱｏＳクラスの指定であり、ストリーミング・クラスが指定される。２行目は遅延の指定であり、４００ミリ秒を表す。３行目はパケット損失率の指定であり、0.001を表す。４行目はジッターの指定であり、５０ミリ秒を表す。

前述したように、帯域幅はメディア指定から取得することができるが、以下の表現によって明示的に指定することもできる。

a=bandwidth:AS80000
及び
a=bandwidth:AS140000

ＩＮＶＩＴＥメッセージ６０２は、ネットワーク１１２のセッション管理サーバ５０３において捕捉される。セッション管理サーバ５０３は、ＩＮＶＩＴＥメッセージ６０２の内容を記憶する。また、ＩＮＶＩＴＥメッセージ６０２は、そのままＩＮＶＩＴＥメッセージ６０３として、ゲートウェイ５０２に転送される。転送されたＩＮＶＩＴＥメッセージ６０３はゲートウェイ５０２に到達し、ＩＮＶＩＴＥメッセージ６０１と同一内容のＩＮＶＩＴＥメッセージ６０５に書き換えられて、コンピュータ１０２に転送される。これは、ＱｏＳに関する表現を含んだままでは、コンピュータ１０２が正しく処理できないおそれがあるためである。

コンピュータ１０２は、ＩＮＶＩＴＥメッセージ６０５を受信すると、ＩＮＶＩＴＥメッセージ６０５の送信者であるコンピュータ１０１への応答として（コンピュータ１０１のＵＲＩを受信者に指定して）ＳＩＰの”２００ＯＫ”メッセージ６１１をゲートウェイ５０２に送信する。

ゲートウェイ５０２は”２００ＯＫ”メッセージ６１１にＱｏＳ要求仕様を追加して”２００ＯＫ”メッセージ６１２を生成する。このＱｏＳ要求仕様はＩＮＶＩＴＥメッセージ６０５のＱｏＳ要求仕様と同じである。すなわち、ゲートウェイ５０２が記憶していたＩＮＶＩＴＥメッセージ６０５のＱｏＳ要求仕様の内容である。この”２００ＯＫ”メッセージ６１２は、セッション管理サーバ５０３に転送される。

セッション管理サーバ５０３は、”２００ＯＫ”メッセージ６１２の内容をＩＮＶＩＴＥメッセージ６０２と対応付けて記憶する。セッション管理サーバ５０３は、ＩＮＶＩＴＥメッセージ６０３に含まれるコンピュータ１０１におけるＲＴＰ通信のＩＰアドレス及びポートの識別子、帯域幅（ポート８０００については８０ｋｂｐｓ、ポート８００２については１４０ｋｂｐｓ）、ＱｏＳクラス、遅延、パケット廃棄率、及びジッターの要求の記憶内容を参照して、これらの参照された情報をＲＲＥＱメッセージ６０４にコピーし、”２００ＯＫ”メッセージ６１２に含まれるコンピュータ１０２のＲＴＰ通信のＩＰアドレス及びポートの識別子をＲＲＥＱメッセージ６０４にコピーする。そして、セッション管理サーバ５０３は、ＲＲＥＱメッセージ６０４を資源管理サーバ１０８に送信する。

煩雑さを避けるために、図１４Ａには、ＲＲＥＱメッセージ６０４を一つだけ図示しているが、ＲＲＥＱメッセージは各送信ポート及び各受信ポートについて生成される。ここでは、コンピュータ１０１からの送信に使用されるポートは８０００だけであるが、コンピュータ１０１へ到達するデータの受信にはポート８０００及びポート８００２が使用される。よって、三つのメッセージが生成される。以下のＤＥＣ、ＯＫ及びＲＰＴメッセージも、各ＲＲＥＱメッセージに対応して独立に生成される。

資源管理サーバ１０８はＲＲＥＱメッセージ６０４を受信した場合、内部データベースを使用して当該フローに関する入口ボーダルータ１０３を求める。そして、求められた入口ボーダルータ１０３のポリシーを決定して、決定されたポリシーをＤＥＣメッセージ６０７として入口ボーダルータ１０３に送信する。

資源管理サーバ１０８が、入口ボーダルータ１０３のためのポリシーを決定する場合は、資源要求時と同様に図５に示す処理を使用すればよい。また、入口ボーダルータ１０３に送信されるＤＥＣメッセージ６０７の内容は図５を使用して後述する。

また、コアルータ５０５のポリシーを変更する必要があれば、ポリシー変更のためのＤＥＣメッセージ６０８を、コアルータ５０５に送信する。さらに、出口ボーダルータ１０４へポリシーを配布する必要があれば、ポリシーをＤＥＣメッセージ６０７としてボーダルータ１０４に送信する。

ボーダルータ１０３は、ＤＥＣメッセージ６０６に基づくポリシーの設定が完了すると、その応答としてＲＰＴメッセージ６１６を資源管理サーバ１０８に送信する。ボーダルータ１０４がＤＥＣメッセージ６０７を受信した場合も、受信したＤＥＣメッセージ６０７に基づくポリシーの設定が完了すると、その応答としてＲＰＴメッセージ６１７を資源管理サーバ１０８に送信する。

コアルータ５０５も、ＤＥＣメッセージ６０８に基づくポリシーの設定が完了すると、その応答としてＲＰＴメッセージ６１８を資源管理サーバ１０８に送信する。資源管理サーバは全てのポリシーの設定が完了すると（すなわち、ＩＮＶＩＴＥメッセージ６０２に含まれるＳＤＰメッセージに含まれた全てのポートに関する全てのＲＰＴメッセージ６１６、６１７及び６１８を受信すると）、ＲＲＥＱメッセージ６０４への応答としてＲＲＥＰメッセージ６１９をセッション管理サーバ５０３に送信する。

セッション管理サーバ５０３は、”２００ＯＫ”メッセージ６１２を既に受信していれば、ＲＲＥＰメッセージ６１９を受信した際に、”２００ＯＫ”メッセージ６１２をそのまま”２００ＯＫ”メッセージ６２０としてゲートウェイ５０１に転送する。また、まだ”２００ＯＫ”メッセージ６１２を受信していなければ、”２００ＯＫ”メッセージ６１２を受信したときに、”２００ＯＫ”メッセージ６２０をゲートウェイ５０１に送信する。

ゲートウェイ５０１は、”２００ＯＫ”メッセージ６２０からＱｏＳ要求仕様を除去して、”２００ＯＫ”メッセージ６２１としてコンピュータ１０１に転送する。これは、ＱｏＳに関する表現を含んだままでは、コンピュータ１０２が正しく処理できないおそれがあるためである。

コンピュータ１０１は、”２００ＯＫ”メッセージ６２１への応答として、ＡＣＫメッセージ６２２をコンピュータ１０２に送信する。ＡＣＫメッセージ６２２はゲートウェイ５０１、セッション管理サーバ５０３及びゲートウェイ５０２を経由するが、もとの形式のままコンピュータ１０２に到達する。

第４の実施の形態においては、第１の実施の形態と同様に、資源管理サーバ１０８がＱｏＳ要求仕様を把握することができるため、第１の実施の形態のように各ルータにポリシーを配布することができる。

第４の実施の形態においては、コンピュータ１０１及びコンピュータ１０２がＱｏＳ要求をふくむＳＩＰメッセージ送受信機能を備えているが、コンピュータ１０１及びコンピュータ１０２が、それぞれゲートウェイ５０１及びゲートウェイ５０２との間で、他のプロトコルを使用してＱｏＳ要求を通信し、ゲートウェイ５０１及びゲートウェイ５０２が、受信したＱｏＳ要求をＳＩＰに変換することもできる。

また、ゲートウェイ５０１及びゲートウェイ５０２が、コンピュータ１０１及びコンピュータ１０２からＱｏＳ要求を含まないＳＩＰメッセージを受信し、メディア指定が含まれるＳＤＰメッセージから必要なＱｏＳ要求を推定して、推定されたＱｏＳ要求をＳＩＰメッセージに追加することも可能である。

この場合、例えば、ＳＤＰメッセージが Ｇ．７１１の双方向の通信を含んでいれば、このＳＤＰメッセージに関する通信は会話クラスの通信と推定されるので、ＩＴＵ−Ｔ標準 Ｙ．１５４１に従って、その通信のＱｏＳクラスは”０”であり、遅延の要求値は１００ミリ秒、パケット損失の要求値は０．００１、ジッターの要求値は５０ミリ秒という推定をする。また、Ｇ．７１１の片方向の通信を含んでいれば、このＳＤＰメッセージに関する通信はストリーミング・クラスの通信と推定されるので、ＩＴＵ−Ｔ標準 Ｙ．１５４１に従って、その通信のＱｏＳクラスは”１”であり、遅延の要求値は４００ミリ秒、パケット損失の要求値は０．００１、ジッターの要求値は５０ミリ秒という推定をする。

＜資源解放フェーズ＞
図１４Ｂは、本発明の第４の実施の形態の資源解放時のシーケンスを示す。

コンピュータ１０１は、コンピュータ１０２に対して（コンピュータ１０２のＵＲＩを受信者に指定して）ＳＩＰのＢＹＥメッセージ６２１を送信する。ＢＹＥメッセージ６２１は、ゲートウェイ５０１によって、そのままＢＹＥメッセージ６２２としてセッション管理サーバ５０３に転送される。ＢＹＥメッセージ６２２は、そのままＢＹＥメッセージ６２３としてゲートウェイ５０２に転送される。さらに、ＢＹＥメッセージ６２３は、そのままＢＹＥメッセージ６２５としてコンピュータ１０２に転送される。

コンピュータ１０２は、ＢＹＥメッセージ６２５を受信すると、ＢＹＥメッセージ６２５の送信者であるコンピュータ１０１への応答として（コンピュータ１０１のＵＲＩを受信者に指定して）ＳＩＰの”２００ＯＫ”メッセージ６３１をゲートウェイ５０２に送信する。ゲートウェイ５０２は、”２００ＯＫ”メッセージ６３１をそのまま”２００ＯＫ”メッセージ６３２としてセッション管理サーバ５０３に転送する。

セッション管理サーバ５０３は、ＢＹＥメッセージ６２２における受信者及び送信者のＵＲＩと記憶された情報とに基づいて、ＩＮＶＩＴＥメッセージ６０３に含まれるコンピュータ１０１におけるＲＴＰ通信のＩＰアドレス及びポートの識別子を、ＲＲＥＱメッセージ６２４にコピーし、”２００ＯＫ”メッセージ６３２に含まれるコンピュータ１０２におけるＲＴＰ通信のＩＰアドレス及びポートの識別子をＲＲＥＱメッセージ６２４にコピーする。そして、セッション管理サーバ５０３は、ＲＲＥＱメッセージ６２４を資源管理サーバ１０８に送信する。

煩雑さをさけるために、図１４Ａには、ＲＲＥＱメッセージ６２４を一つだけ図示しているが、ＲＲＥＱメッセージは各送信ポート及び各受信ポートについて生成される。ここでは、コンピュータ１０１からの送信に使用されるポートは８０００だけであるが、コンピュータ１０１へ到達するデータの受信にはポート８０００及びポート８００２が使用される。よって、三つのメッセージが生成される。以下のＤＥＣ、ＯＫ及びＲＰＴメッセージも、各ＲＲＥＱメッセージに対応して独立に生成される。

資源管理サーバ１０８はＲＲＥＱメッセージ６２４を受信した場合、内部データベースを使用して当該フローに関する入口ボーダルータ１０３を求める。そして、求められた入口ボーダルータ１０３のポリシーを決定して、決定されたポリシーをＤＥＣメッセージ６２７としてボーダルータ１０３に送信する。ボーダルータ１０３は、配布されていたポリシーを解除し、資源を解放する。

また、コアルータ５０５のポリシーを変更する必要があれば、ポリシー変更のためのＤＥＣメッセージ６２８を、コアルータ５０５に送信する。さらに、出口ボーダルータ１０４のポリシーを変更する必要があれば、新たなポリシーをＤＥＣメッセージ６２７としてボーダルータ１０４に送信する。

ボーダルータ１０３は、ＤＥＣメッセージ６２６に基づくポリシーの解除が完了すると、その応答としてＲＰＴメッセージ６３６を資源管理サーバ１０８に送信する。ボーダルータ１０４がＤＥＣメッセージ６２７を受信した場合も、受信したＤＥＣメッセージ６２７に基づくポリシーの解除が完了すると、その応答としてＲＰＴメッセージ６３７を資源管理サーバ１０８に送信する。

コアルータ５０５も、ＤＥＣメッセージ６２８に基づくポリシーの解除が完了すると、その応答としてＲＰＴメッセージ６３８を資源管理サーバ１０８に送信する。資源管理サーバは全てのポリシーの解除が完了すると（すなわち、ＩＮＶＩＴＥメッセージ６０２に含まれるＳＤＰメッセージに含まれた全てのポートに関する全てのＲＰＴメッセージ６３６、６３７及び６３８を受信すると）、ＲＲＥＱメッセージ６２４への応答としてＲＲＥＰメッセージ６３９をセッション管理サーバ５０３に送信する。

セッション管理サーバ５０３は、”２００ＯＫ”メッセージ６３２を既に受信していれば、ＲＲＥＰメッセージ６３９を受信した際に、”２００ＯＫ”メッセージ６３２をそのまま”２００ＯＫ”メッセージ６４０としてゲートウェイ５０１に転送する。また、まだ”２００ＯＫ”メッセージ６３２を受信していなければ、”２００ＯＫ”メッセージ６３２を受信したときに、”２００ＯＫ”メッセージ６４０をゲートウェイ５０１に送信する。

ゲートウェイ５０１は、”２００ＯＫ”メッセージ６４０を、そのまま”２００ＯＫ”メッセージ６４１としてコンピュータ１０１に転送する。

第４の実施の形態においては、第１の実施の形態と同様に、資源管理サーバ１０８がＱｏＳ要求仕様を把握することができるため、第１の実施の形態のように、フィードバックに基づいて各ルータのポリシーを変更することができる。

また、ＳＤＰメッセージ中にＱｏＳ計測結果を挿入することによって、あらたなプロトコルを追加することなく、ＱｏＳの計測結果をフィードバックすることが可能になり、開発工数が低減される効果がある。また、ＱｏＳ計測結果は、メディアの指定など、既存のＳＤＰメッセージの内容を変更しないため、ＱｏＳ計測結果を必要としないＳＩＰプロキシやエージェントにおいては無視される。そのため、それらのプログラムを改訂する必要がなく、開発工数が低減される効果がある。

＜フィードバックフェーズ＞
図１４Ｃは、本発明の第１の実施の形態の計測結果送信時（すなわち、フィードバック時）のシーケンスを示す。

第４の実施の形態においては、ゲートウェイ５０２が遅延、ジッター及びパケット廃棄率を測定する。すなわち、ゲートウェイ５０２は、ＲＴＰパケットの通過時に、ＲＴＰパケットに含まれるタイムスタンプ及びＲＴＣＰのＳＲパケットから、遅延及びジッターを求める。また、ゲートウェイ５０２は、シーケンス番号を記録してパケット廃棄率を求める。その方法は、第１の実施の形態において、コンピュータ１０２が使用する方法と同じである。なお、コンピュータ１０１がＳＲパケットを生成しない場合は、ゲートウェイ５０１がゲートウェイ５０２にＳＲパケットを送信すればよい。

ゲートウェイ５０２は、コンピュータ１０２のＵＲＩを送信者に指定し、コンピュータ１０１のＵＲＩを受信者に指定して、ＳＩＰのＵＰＤＡＴＥメッセージ６４２をセッション管理サーバ５０３に送信する。

セッション管理サーバ５０３は、ＵＰＤＡＴＥメッセージ６４２をそのままＵＰＤＡＴＥメッセージ６４３としてゲートウェイ５０２に転送する。ゲートウェイ５０２は、ＵＰＤＡＴＥメッセージ６４３を受信すると、ＵＰＤＡＴＥメッセージ６４３をコンピュータ１０１へは転送せず、コンピュータ１０１のＵＲＩを受信者に指定して、ＳＩＰの”２００ＯＫ”メッセージ６５１をセッション管理サーバ５０３に送信する。

ＵＰＤＡＴＥメッセージ６４２は、ＳＤＰ（Session Description Protocol）のメッセージを含んでいるが、このＳＤＰメッセージは以下のメディア指定及びそのメディアに関するＱｏＳ計測結果を含む。

m=audio8000RTP/AVP98
a=rtpmap:98PCMU/8000/1
a=path-latency:12345
a=jitter:54321

１行目及び２行目は、計測対象のＲＴＰフローを指定する。ＩＮＶＩＴＥメッセージ等にＳＤＰの記載が含まれる場合は、一般的に、双方向の通信を意味する。しかし、ここでは受信側の計測結果を伝えることを目的とするため、受信フローだけを意味する。３行目は遅延の計測結果であり、単位はマイクロ秒である。従って、前述した指定は１２．３４５ミリ秒を表す。４行目はジッターの指定であり、単位はマイクロ秒である。従って、前述した指定は５４．３２１ミリ秒を表す。

ＵＰＤＡＴＥメッセージの本来の目的は、通信条件及び通信に使用するメディアを指定して、それらの指定を通信途中に変更することである。よって、前述したような計測結果をフィードバックすることは考慮されていない。従って、これらの指定はＩＥＴＦにおいて標準化されていない。しかし、ＵＰＤＡＴＥメッセージの内容はその受信者と送信者との間で決められればよく、計測結果の送受信のために使用することができる。

セッション管理サーバ５０３は、ＵＰＤＡＴＥメッセージ６４２の受信者及び送信者のＵＲＩと記憶された情報とに基づいて、コンピュータ１０１及びコンピュータ１０２におけるＲＴＰ通信のＩＰアドレス及びポートの識別子を、ＲＲＥＱメッセージ６４４にコピーする。そして、セッション管理サーバ５０３は、ＲＲＥＱメッセージ６４４を資源管理サーバ１０８に送信する。

資源管理サーバ１０８はＲＲＥＱメッセージ６４４を受信した場合、内部データベースを使用して当該フローに関する入口ボーダルータ１０３を求める。そして、必要があれば、求められた入口ボーダルータ１０３のポリシーを決定して、決定されたポリシーをＤＥＣメッセージ６４７としてボーダルータ１０３に送信する。ボーダルータ１０３は、配布されていたポリシーを変更する。

また、コアルータ５０５のポリシーを変更する必要があれば、ポリシー変更のためのＤＥＣメッセージ６４８を、コアルータ５０５に送信する。さらに、出口ボーダルータ１０４のポリシーを変更する必要があれば、新たなポリシーをＤＥＣメッセージ６４７としてボーダルータ１０４に送信する。

ボーダルータ１０３は、ＤＥＣメッセージ６４６に基づくポリシーの変更が完了すると、その応答としてＲＰＴメッセージ６５６を資源管理サーバ１０８に送信する。ボーダルータ１０４がＤＥＣメッセージ６４７を受信した場合も、受信したＤＥＣメッセージ６４７に基づくポリシーの解除が完了すると、その応答としてＲＰＴメッセージ６５７を資源管理サーバ１０８に送信する。

コアルータ５０５も、ＤＥＣメッセージ６４８に基づくポリシーの変更が完了すると、その応答としてＲＰＴメッセージ６５８を資源管理サーバ１０８に送信する。資源管理サーバは全てのポリシー解除が完了すると（すなわち、全てのＲＰＴメッセージ６５６、６５７及び６５８を受信すると）、ＲＲＥＱメッセージ６４４への応答としてＲＲＥＰメッセージ６５９をセッション管理サーバ５０３に送信する。

セッション管理サーバ５０３は、”２００ＯＫ”メッセージ６４２を既に受信していれば、ＲＲＥＰメッセージ６３９を受信した際に、”２００ＯＫ”メッセージ６４２をそのまま”２００ＯＫ”メッセージ６４６としてゲートウェイ５０２に転送する。また、まだ”２００ＯＫ”メッセージ６４２を受信していなければ、”２００ＯＫ”メッセージ６４２を受信したときに、”２００ＯＫ”メッセージ６４６をゲートウェイ５０２に送信する。ゲートウェイ５０２は、”２００ＯＫ”メッセージ６４６をコンピュータ１０２には転送しない。

また、第４の実施の形態においては、コンピュータ１０１及びコンピュータ１０２がＲＴＣＰメッセージを送信する機能を備える。しかし、コンピュータ１０１及びコンピュータ１０２がＲＴＣＰメッセージ送信機能を備えない場合は、ゲートウェイ５０１及びゲートウェイ５０２がＲＴＣＰメッセージ送信機能を代行することができる。

すなわち、ゲートウェイ５０１及びゲートウェイ５０２は、コンピュータ１０１及びコンピュータ１０２から送出されるＲＴＰパケットを監視し、ＲＴＰパケットの内容に基づいてＳＲパケット及び他のＲＴＣＰメッセージを生成することができる。ＳＲメッセージに含まれるタイムスタンプは、ゲートウェイ５０１がコンピュータ１０１から当該ＲＴＰパケットを受信した時刻を、ゲートウェイ５０１の内部時計に従って記入すればよい。

第４の実施の形態においては、第１の実施の形態と同様に、資源管理サーバ１０８がＱｏＳ要求仕様を把握することができるため、第１の実施の形態のように、フィードバックに基づいて各ルータのポリシーを変更することができる。

また、ＳＤＰメッセージ中にＱｏＳ計測結果を挿入することによって、あらたなプロトコルを追加することなく、ＱｏＳの計測結果をフィードバックすることが可能になり、開発工数が低減される効果がある。また、ＱｏＳ計測結果は、メディアの指定など、既存のＳＤＰメッセージの内容を変更しないため、ＱｏＳ計測結果を必要としないＳＩＰプロキシやエージェントにおいては無視される。そのため、それらのプログラムを改訂する必要がなく、開発工数が低減される効果がある。

本発明の第１〜第３の各実施の形態のネットワーク及びシステムの構成図である。 本発明の第１〜第４の各実施の形態において使用される資源要求プロトコルのＲＴＣＰメッセージのデータ形式の説明図である。 本発明の第１〜第４の各実施の形態において使用される資源要求プロトコルのデータ形式（メッセージタイプが”ＲＥＳ”であるときのメッセージ本体の内容）の説明図である。 本発明の第１〜第４の各実施の形態において使用される資源要求プロトコルのデータ形式（ＱｏＳ要求仕様の内容）の説明図である。 本発明の第１〜第４の各実施の形態において使用される資源要求プロトコルのデータ形式（メッセージタイプが”ＲＥＰ”であるときのメッセージ本体の内容）の説明図である。 本発明の第１〜第４の各実施の形態において使用されるポリシー要求・配布プロトコルのデータ形式（ＲＲＱタイプのメッセージの形式）の説明図である。 本発明の第１〜第４の各実施の形態において使用されるポリシー要求・配布プロトコルのデータ形式（ＴＲＱタイプのメッセージの形式）の説明図である。 本発明の第１〜第４の各実施の形態において使用されるポリシー要求・配布プロトコルのデータ形式（ＲＰＴタイプのメッセージの形式）の説明図である。 本発明の第１〜第４の各実施の形態において使用されるポリシー要求・配布プロトコルのデータ形式（エッジルータを設定するためのＤＥＣタイプのメッセージの形式）の説明図である。 本発明の第１〜第４の各実施の形態において使用されるポリシー要求・配布プロトコルのデータ形式（コアルータを設定するためのＤＥＣタイプのメッセージの形式）の説明図である。 本発明の第１〜第３の各実施の形態における資源要求フェーズのシーケンス図である。 本発明の第１〜第３の各実施の形態における資源解放フェーズのシーケンス図である。 本発明の第１及び第２の各実施の形態におけるフィードバック・フェーズのシーケンス図である。 本発明の第３の実施の形態におけるフィードバック・フェーズのシーケンス図である。 本発明の第１〜第４の各実施の形態における資源要求時のエッジポリシーを決定する処理を示すフローチャートである。 本発明の第１〜第４の各実施の形態における資源要求時のコアポリシーを決定する処理を示すフローチャートである。 本発明の第１〜第３の各実施の形態におけるルータ機能拡張装置を示すブロック図である。 本発明の第１〜第３の各実施の形態におけるルータ機能拡張プログラムによる処理を示すフローチャートである。 本発明の第１〜第４の各実施の形態におけるフィードバック時のポリシー改訂処理のフローチャートである。 本発明の第１〜第４の各実施の形態におけるフィードバック時のエッジポリシーを更新する処理のフローチャートである。 本発明の第１〜第４の各実施の形態におけるフィードバック時のコアポリシーを更新する処理のフローチャートである。 本発明の第２の実施の形態におけるアクセスネットワークの構成を示すブロック図である。 本発明の第２の実施の形態におけるアクセスネットワークの構成を示すブロック図である。 本発明の第４の実施の形態におけるネットワークシステムの構成を示すブロック図である。 本発明の第４の実施の形態における資源要求フェーズのシーケンス図である。 本発明の第４の実施の形態における資源解放フェーズのシーケンス図である。 本発明の第４の実施の形態におけるフィードバック・フェーズのシーケンス図である。

符号の説明

１０１、１２１ コンピュータ（送信者）
１０２、１２２ コンピュータ（受信者）
１０３、１０４ ボーダルータ
１０５、１０６、１０７ コアルータ
１０８ 資源管理サーバ
１１０、１１１、１３０、１３１ アクセスネットワーク
１１２ コアネットワーク
１４０１、１４０２、１４１１、１４１２ ボーダルータ
１４０３、１４１３ コアルータ
１４０４、 １４１４ 資源管理サーバ
５０１、５０２ ゲートウェイ
５０３ セッション管理サーバ
５０５、５０６、５０７ コアルータ

Claims (15)

1. 通信インターフェースを備える第１のコンピュータ及び通信インターフェースを備える第２のコンピュータに接続されるネットワークシステムであって、
   前記第１のコンピュータと前記第２のコンピュータとの通信経路上に設けられ、パケットを転送する少なくとも一つのネットワークノードと、
   前記第２のコンピュータから送信される制御情報を前記第１のコンピュータに転送するとともに、前記制御情報を捕捉するネットワーク装置と、
   前記ネットワークノードを制御する資源管理サーバと、を備え、
   前記第１のコンピュータと前記第２のコンピュータとの間の通信のＱｏＳ要求条件が設定されており、
   前記第１のコンピュータは、前記第２のコンピュータに繰り返しパケットを送信して第１の通信を行い、
   前記第２のコンピュータは、前記第１の通信のＱｏＳを計測し、前記第１の通信の識別子及び前記計測結果を含む制御情報を、前記ネットワーク装置経由で前記第１のコンピュータに送信し、
   前記ネットワーク装置は、前記制御情報を捕捉し、前記捕捉した制御情報から抽出された第１の通信の識別子及び計測結果を含むメッセージを、前記資源管理サーバに送信し、
   前記資源管理サーバは、前記計測結果が前記ＱｏＳ要求条件を満たさない場合、前記ＱｏＳ要求条件を満たさない原因を推定し、前記原因があると判定された前記ネットワークノードにＱｏＳを設定することを特徴とするネットワークシステム。
2. 前記ネットワークノードは、前記転送されるパケットによる通信の通信量を制限する第１のネットワークノードを含み、
   前記第１のネットワークノードが、前記第１の通信に設定されたＱｏＳ要求条件に従って、前記第１の通信の通信量を制限するように設定されている場合、
   前記資源管理サーバは、前記計測結果が前記ＱｏＳ要求条件を満たさない場合、前記第１のネットワークノードが前記ＱｏＳ要求条件を満たさない原因であると推定し、前記第１の通信の通信量の制限を緩和するように、前記第１のネットワークノードにＱｏＳを設定することを特徴とする請求項１に記載のネットワークシステム。
3. 前記ネットワークノードは、入力されたパケットを複数のクラスに分類し、前記クラスに配分された出力帯域に従って、前記分類されたパケットを出力する第２のネットワークノードを含み、
   前記第２のネットワークノードが、前記第１の通信に設定されたＱｏＳ要求条件に従って、前記第１の通信を第１のクラスに分類している場合に、
   前記資源管理サーバは、前記計測結果が前記ＱｏＳ要求条件を満たさない場合、前記第２のネットワークノードが前記ＱｏＳ要求条件を満たさない原因であると推定し、前記第２のネットワークノードが前記第１のクラスの出力帯域を増加するようにＱｏＳを設定することを特徴とする請求項１に記載のネットワークシステム。
4. 前記ネットワークノードは、入力されたパケットを複数のクラスに分類し、前記クラスに設定された優先度に従って、前記分類されたパケットをスケジューリングする第３のネットワークノードを含み、
   前記第３のネットワークノードが、前記第１の通信に設定されたＱｏＳ要求条件に従って、前記第１の通信を第１のクラスに分類している場合に、
   前記資源管理サーバは、前記計測結果が前記ＱｏＳ要求条件を満たさない場合、前記第３のネットワークノードが前記ＱｏＳ要求条件を満たさない原因であると推定し、前記第３のネットワークノードが前記第１のクラスの優先度を増加するようにＱｏＳを設定することを特徴とする請求項１に記載のネットワークシステム。
5. 前記資源管理サーバは、前記計測結果が前記設定されたＱｏＳ要求条件を超える場合、前記計測結果を前記ネットワークノードを経由して第１のコンピュータに通知することを特徴とする請求項１に記載のネットワークシステム。
6. 前記ネットワークシステムは、前記第１のコンピュータと前記第２のコンピュータとの通信以外の第２の通信のパケットを転送し、
   前記資源管理サーバは、前記計測結果が前記第１のＱｏＳ要求条件を満たさないが、前記第２の通信のＱｏＳの計測結果がＱｏＳ要求条件を満たす場合に、前記ネットワークノードが前記第２の通信の通信量を制限するようにＱｏＳを設定することを特徴とする請求項１に記載のネットワークシステム。
7. 前記ネットワークシステムは、さらに、前記ネットワークノードの機能を拡張する拡張装置を備え、
   前記第１のコンピュータは、前記第２のコンピュータとの通信セッションを開始するときに、前記通信セッションのための資源の要求を含む資源要求メッセージを前記ネットワークノード経由で前記第２のコンピュータに送信し、
   前記ネットワークノードは、前記資源要求メッセージが到達した場合に、前記到達した資源要求メッセージを前記拡張装置に転送し、
   前記拡張装置は、前記転送された資源要求メッセージを前記ネットワークノードに転送し、前記転送された資源要求メッセージに含まれる資源要求の内容を前記ネットワークノードにＱｏＳ設定をすることを特徴とする請求項１に記載のネットワークシステム。
8. 前記ネットワークシステムは、さらに、前記ネットワークノードの機能を拡張する拡張装置を備え、
   前記第１のコンピュータは、前記第２のコンピュータとの通信中に、前記第２のコンピュータとの通信に関する統計情報を送信し、
   前記ネットワークノードは、前記統計情報が到達した場合に、前記到達した統計情報を前記拡張装置に転送し、
   前記拡張装置は、前記転送された統計情報を前記ネットワークノードに転送し、前記転送された統計情報が前記ＱｏＳ要求条件を満たさない場合に、前記ネットワークノードのＱｏＳ設定を変更することを特徴とする請求項１に記載のネットワークシステム。
9. 前記制御情報は、前記第２のコンピュータによってＱｏＳの対策が可能な部分の情報を含み、
   前記資源管理サーバは、前記ネットワークノードが前記第２のコンピュータによって対策可能な部分を減じた分のＱｏＳを改善するようにＱｏＳを設定することを特徴とする請求項１に記載のネットワークシステム。
10. 前記ＱｏＳ要求条件は、ジッターに関する要求条件を含み、
    前記計測結果は、ジッターの計測値を含み、
    前記制御情報は、前記第２のコンピュータによってＱｏＳの対策が可能な部分の情報として、前記第２のコンピュータがバッファによって吸収可能なジッターの値を含むことを特徴とする請求項９に記載のネットワークシステム。
11. 通信インターフェースを備える第１のコンピュータ及び通信インターフェースを備える第２のコンピュータに接続されるネットワークシステムであって、
    第１のネットワークと、
    前記第１のコンピュータと前記第１のネットワークとの通信経路上に設けられた第１のゲートウェイと、
    前記第２のコンピュータと前記第１のネットワークとの通信経路上に設けられた第２のゲートウェイと、を備え、
    前記第１のネットワークは、
    前記第１のコンピュータと前記第２のコンピュータとの通信経路上に設けられ、パケットを転送する少なくとも一つのネットワークノードと、
    前記第２のコンピュータから送信される制御情報を前記第１のコンピュータに転送するとともに、前記制御情報を捕捉するネットワーク装置と、
    前記ネットワークノードを制御する資源管理サーバと、を備え、
    前記第１のコンピュータと前記第２のコンピュータとの間の通信のＱｏＳ要求条件が設定されており、
    前記第１のコンピュータは、前記第２のコンピュータに繰り返しパケットを送信して第１の通信を行い、
    前記第２のゲートウェイは、前記第１の通信のＱｏＳを計測して第１の計測結果を求め、前記第１の通信の識別子及び前記第１の計測結果を含む第１の制御情報を、前記ネットワーク装置経由で前記第１のゲートウェイに送信し、
    前記ネットワーク装置は、前記第１の制御情報を捕捉し、前記捕捉した第１の制御情報から抽出された第１の通信の識別子及び第１の計測結果を含むメッセージを、前記資源管理サーバに送信し、
    前記資源管理サーバは、前記第１の計測結果が前記ＱｏＳ要求条件を満たさない場合、前記ＱｏＳ要求条件を満たさない原因を推定し、前記原因があると判定された前記ネットワークノードにＱｏＳを設定することを特徴とするネットワークシステム。
12. 前記第２のコンピュータは、前記ネットワーク装置経由で前記第１のコンピュータに第２の制御情報を送信し、
    前記第２のゲートウェイは、前記第１の通信のＱｏＳを計測して第２の計測結果を求め、前記第２の計測結果を前記第２の制御情報に付加し、
    前記ネットワーク装置は、前記第２の制御情報を捕捉し、前記捕捉した第２の制御情報から抽出された第１の通信の識別子及び第２の計測結果を含むメッセージを、前記資源管理サーバに送信し、
    前記資源管理サーバは、前記第２の計測結果が前記ＱｏＳ要求条件を満たさない場合、前記ＱｏＳ要求条件を満たさない原因を推定し、前記原因があると判定された前記ネットワークノードにＱｏＳを設定することを特徴とする請求項１１に記載のネットワークシステム。
13. 通信インターフェースを備える第１のコンピュータ及び通信インターフェースを備える第２のコンピュータに接続されるネットワークシステムであって、
    前記第１のコンピュータと前記第２のコンピュータとの通信経路上に設けられ、パケットを転送する第４のネットワークノード及び第５のネットワークノードと、を備え、
    前記第１のコンピュータと前記第２のコンピュータとの間の通信のＱｏＳ要求条件が設定されており、
    前記第１のコンピュータは、前記第２のコンピュータに繰り返しパケットを送信する第１の通信を行い、
    前記第２のコンピュータは、前記第１の通信のＱｏＳを計測して計測結果を求め、前記第１の通信の識別子、前記計測結果及び前記第２のコンピュータによってＱｏＳの対策が可能な部分の情報を含む第３の制御情報を、前記第４のネットワークノード及び第５のネットワークノード経由で前記第１のコンピュータに送信し、
    前記第５のネットワークノードは、前記第３の制御情報が通過する際に、前記第２のコンピュータから前記第５のネットワークノードまでの間でＱｏＳの対策が可能な部分の情報を前記第３の制御情報に付加し、
    前記第４のネットワークノードは、前記第３の制御情報を参照し、第１のネットワークノードが他の箇所でＱｏＳの対策が可能な部分を減じた分のＱｏＳを改善するようにＱｏＳを設定することを特徴とするネットワークシステム。
14. 前記ＱｏＳ要求条件は、ジッターに関する要求条件を含み、
    前記第３の計測結果は、ジッターの計測値を含み、
    前記第３の制御情報は、前記第２のコンピュータから前記第５のネットワークノードまでの間でＱｏＳの対策が可能な部分の情報として、前記第５のネットワークノードがバッファによって吸収可能なジッターの値を含むことを特徴とする請求項１３に記載のネットワークシステム。
15. 通信インターフェースを備える第１のコンピュータ及び通信インターフェースを備える第２のコンピュータに接続されるネットワークシステムであって、
    前記第１のコンピュータと前記第２のコンピュータとの通信経路上に設けられ、パケットを転送する少なくとも一つのネットワークノードと、
    前記第２のコンピュータから送信される制御情報を前記第１のコンピュータに転送するとともに、前記制御情報を捕捉するネットワーク装置と、
    前記ネットワークノードを制御する資源管理サーバと、
    前記第１のコンピュータと前記第２のコンピュータとの間の通信のＱｏＳを計測する計測部と、を備え、
    前記第１のコンピュータと前記第２のコンピュータとの間の通信のＱｏＳ要求条件が設定されており、
    前記第１のコンピュータは、前記第２のコンピュータに繰り返しパケットを送信して第１の通信を行い、
    前記計測部は、前記第１の通信のＱｏＳを計測し、前記計測結果を前記ネットワーク装置を経由して前記資源管理サーバに送信し、
    前記資源管理サーバは、
    前記計測結果が前記ＱｏＳ要求条件を満たさない場合、前記ネットワークノードに新たに設定するＱｏＳ条件を計算し、
    前記新たに設定すべきＱｏＳ条件と現在のＱｏＳ条件との差が所定の範囲でない場合、前記ネットワークノードにＱｏＳを設定することを特徴とするネットワークシステム。

Images