(57)【特許請求の範囲】
【請求項１】
ネットワーク通信における終端間(end-to-end)の資源配分を実施するための方法であって、
ａ．送信元端末からデータフローのためのＱＯＳドメインの入口ＱＥＲに資源要求メッセージを伝送するステップと、
ｂ．前記資源要求メッセージが、各ＱＯＳドメインの前記入口ＱＥＲと各ＱＯＳドメインの出口ＱＥＲとを順に通過し、前記資源要求メッセージのエッジルーターリストに各通過したＱＯＳドメインのＱＥＲＩＤを加えるステップと、
ｃ．前記エッジルーターリストを、前記データフローの送信先端末と接続されたＱＥＲに格納し、引き続いて前記送信先端末に前記資源要求メッセージを送信するステップと、
ｄ．前記送信先端末が、前記送信元端末に資源配分メッセージを戻すステップと、
ｅ．前記送信先端末に接続され、前記資源配分メッセージを受信する前記ＱＥＲが、前記格納されたエッジルーターリストに従って資源配分経路を決定し、前記決定された資源配分経路に沿って前記データフローのための前記資源配分メッセージを伝送し、前記通過したＱＥＲと隣接ＱＥＲとの間のデータフローから生成された集約フローのための資源予約の状態を判断し、前記集約フローのための資源を配分し、前記判断の結果に従って資源予約調整を実行し、そして前記資源配分メッセージを前記送信元端末に戻すステップと
を含み、
前記集約フローのための資源の前記配分は、固定配分と増加配分とを含み、
前記固定配分では、配分された資源の量が、前記集約フローによって要求される量に等しく、
前記増加配分では、或る粒度(granularity)で前記資源を配分し、配分された資源の量が、前記集約フローによって要求される量よりも多いか等しく、各粒度が資源の定量(fixed quantity)を規定する、方法。
【請求項２】
前記ステップｅは、
ｅ１．前記送信先端末に接続され、前記資源配分メッセージを受信する前記ＱＥＲが、前記送信先端末と前記ＱＥＲとの間で資源を配分し、前記ＱＥＲに格納された前記エッジルーターリストを前記資源配分メッセージに添付し、引き続いて前記資源配分メッセージを転送するステップと、
ｅ２．前記資源配分メッセージが各ＱＯＳドメインの前記ＱＥＲを通じて通過するときに、前記エッジルーターリストにおける前記ＱＯＳドメインの隣接ＱＥＲのＩＤをチェックし、そして、前記ＱＥＲと前記隣接ＱＥＲとの間に前記データフローを送信するための十分な資源があるかどうかを判断し、もし資源が十分にあれば、引き続いて前記資源配分メッセージを転送すると共にステップｅ４を実行し、もし資源が十分になければ、ステップｅ３を実行するステップと、
ｅ３．前記集約フローのための資源配分処理を起動して資源配分を実行し、引き続き前記資源配分メッセージを転送するステップと、
ｅ４．前記送信元端末と接続された前記ＱＥＲが、前記資源配分メッセージを受信し、資源配分を実行し、前記資源配分メッセージから前記エッジルーターリストを削除し、そして、前記資源配分メッセージを前記送信元端末に転送するステップと、
ｅ５．前記送信元端末が前記資源配分メッセージを受信して資源を配分するステップとを更に含む請求項１記載の方法。
【請求項３】
ステップｅ３における前記集約フローのための前記資源配分処理を起動して資源配分を実行するステップは、
もし、前記ＱＥＲに隣接するＱＥＲが次のホップであれば、前記ＱＥＲが次のホップでの前記ＱＥＲに前記集約フローのための資源要求を送信し、前記次のホップでの前記ＱＥＲが前記集約フローのための資源配分を実行し、そして前記集約フローのための資源配分メッセージを戻すステップと、
もし、前記ＱＥＲに隣接するＱＥＲが前のホップであれば、前記ＱＥＲが、前記集約フローのための資源配分を実行し、そして前記前のホップでの前記ＱＥＲに前記データフローのための資源配分メッセージと前記集約フローのための資源配分メッセージとを一緒に送信し、ＩＰネットワークについて、
前記データフローのための資源配分メッセージと前記集約フローのための資源配分メッセージとが同一のメッセージで運ばれるステップとを含み、
前記前のホップ又は次のホップは、前記データフロー伝送方向における前のホップ又は次のホップである請求項２記載の方法。
【請求項４】
前記資源要求メッセージと前記データフローのための前記資源配分メッセージとを受信すると、ＱＣＲは、前記資源要求メッセージと前記資源配分メッセージを廃棄せずに伝送するステップを更に含む請求項１記載の方法。
【請求項５】
ポリシーサーバーにより、各ＱＯＳドメインにおける資源配分に関する情報を収集し、前記集約フローのための資源配分を実施するステップを更に備えた請求項１記載の方法。
【請求項６】
前記資源要求メッセージと前記データフローのための資源配分メッセージは、送信元アドレスと、送信先アドレスと、フローＩＤと、集約フローＩＤと、トラヒックパラメータデスクリプションと、ＱＯＳエッジルーターリストとを含む請求項１記載の方法。
【請求項７】
前記ステップａは、前記資源要求メッセージが各ＱＯＳドメインの入口で受け入れ可能であることを判断するステップを更に含む請求項１記載の方法。
【請求項８】
前記ＱＥＲは、前のホップ／次のホップでのインターフェイスの前記ＱＯＳドメインが同一であるかどうかを判断することを通して決定される請求項１記載の方法。
【請求項９】
所定の高い優先度を有する集約フローによって所定の低い優先度を有する集約フローに配分された資源の先取りのための処理手順、即ち、前記所定の高い優先度を有する集約フローは資源要求を生成するが、事前配分された資源が前記データフローを送信するのに十分でないとき、前記所定の低い優先度を有する集約フローに配分された未使用の資源を先取りし、従って、前記所定の高い優先度を有する前記集約フローへの資源事前配分を実行する手順を更に含む請求項１記載の方法。
【請求項１０】
更に処理手順を含み、この処理手順を通じて、前記集約フローに配分される資源が解放(release)され、即ち、前記解放されるべき資源の累積トータルが所定量の資源に達したと判断されると、前記集約フローに配分された資源が解放される請求項１記載の方法。
【請求項１１】
別のイントラドメイン資源配分方法が各ＱＯＳドメインにおいて使用され、終端間(end-to-end)の資源配分を実施するための前記方法は、シグナリングに基づく資源配分方法と、ポリシーサーバーに基づく資源配分方法とを含む請求項１記載の方法。
【請求項１２】
前記送信元端末が、経路検出メッセージを前記送信先端末に送信し、前記送信先端末に接続されたポリシーサーバー又は前記ＱＥＲが前記エッジルーターリストを格納し、前記データフローの経路が変化したかどうかを検出し、もし、前記データフローの前記経路が変化していれば、新たな資源配分を確立すると共に古い資源配分を解約し、前記データフローの前記経路が変化していなければ、処理を行わないステップを更に含む請求項１記載の方法。
【請求項１３】
ＱＯＳドメインにおける集約フローの経路が前記ＱＯＳドメインを通して通過する前記データフローの経路と異なるとき、又は前記ＱＯＳドメインに複数の等価経路が存在するとき、前記ＱＯＳドメインの入口でのエッジルーターと前記ＱＯＳドメインの出口でのエッジルーターとの間のトンネルを確立し、そしてデータフロー伝送中に前記確立されたトンネルを通じて前記データフローを転送させるステップを更に含む請求項１記載の方法。
【請求項１４】
事前配置された資源の統計的調整の処理を含み、前記処理は、定期的に前記集約フローの時間遅延パラメータと平均レート(mean rate)とに従って事前配分された資源を調整するステップを更に含む請求項１記載の方法。
【請求項１５】
ネットワーク通信における終端間(end-to-end)の資源配分を実施するための方法であって、
ａ１１．送信元端末が、隣接ＱＯＳドメインのポリシーサーバーに対するデータフローのための資源要求を起動するステップと、
ｂ１１．前記ポリシーサーバーが、前記データフローのための集約フローＩＤを決定し、次のＱＯＳドメインと前記データフローのための現在のＱＯＳドメインとにおける経路を計算し、前記次のＱＯＳドメインのポリシーサーバーに前記資源要求を転送するステップと、
ｃ１１．各ＱＯＳドメインのポリシーサーバーが同様に処理を行うと共に、送信先端末に接続されたＱＯＳドメインのポリシーサーバーが、前記データフローのための要求メッセージを前記送信先端末に転送するステップと、
ｄ１１．前記送信先端末で、前記データフローに配分できる資源を決定すると共に、資源配分メッセージを前記ポリシーサーバーに戻すステップと、
ｅ１１．前記ポリシーサーバーが、前記現在のＱＯＳドメインを通る経路に沿ったノードでの集約フローのための資源を配分すると共に、データフロー伝送方向における前のＱＯＳドメインのポリシーサーバーに前記データフローのための資源配分メッセージを転送するステップと、
ｆ１１．前記送信元端末が、前記資源配分メッセージを受信して、資源を配分するステップとを含み、
前記集約フローのための資源の前記配分は、固定配分と増加配分とを含み、
前記固定配分では、配分された資源の量が、前記集約フローによって要求される量に等しく、
前記増加配分では、或る粒度(granularity)で前記資源を配分し、配分された資源の量が、前記集約フローによって要求される量よりも多いか等しく、各粒度が資源の定量(fixed quantity)を規定する、方法。
【請求項１６】
前記ポリシーサーバーは、当該ポリシーサーバーが存在するＱＯＳドメインにおける資源占有状況とトポロジー情報とに従って資源配分ソリューションを決定する請求項１５記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク通信の技術分野に関し、詳しくは、ネットワーク通信における
資源配分(resource allocation)を実施するためのシステム及び方法に関する。
【背景技術】
【０００２】
ネットワーク通信技術が進むにつれて、ネットワーク通信における特定のサービスのための特別な通信需要が存在するのが通例である。従って、特定のサービスの伝送需要を満足するために、例えば、基幹ネットワーク(backbone network)上のＦＴＰ(File Transfer Protocol)帯域幅を制限し、音声、ビデオ、および他の実時間サービスのための別の通信を提供するインターネット接続業者(ISP; Internet Service Provider)を実現し、そして時間依存のマルチメディアサービスのための低時間遅延と帯域幅を提供するために、ネットワーク資源を制御することが必要である。
【０００３】
この目的を達成するため、ＩＰ ＱＯＳ(Internet Protocol Quality of Service)技術が現れた。ＩＰ ＱＯＳは、ＩＰネットワークを介したサービスの提供能力を称し、即ち、フレームリレー(FR; Frame Relay)、非同期転送モード(ATM; Asynchronous Transfer Mode)、イーサネット（登録商標）、同期デジタル階層(SDH; Synchronous Digital Hierarchy)を含む下層ＩＰネットワークを通じた特定のフロー(flow)のための所要のサービス能力を提供し、通常、ＩＰ ＱＯＳを評価するために使用される技術基準は次の事柄を含む。
【０００４】
帯域幅／スループット(bandwidth/throughput)：これは、二つのノード間の特定のアプリケーションのためのフローの平均速度を言う。
【０００５】
時間遅延(time delay)：これは、ネットワークにおける二つのノード間でのデータパケットの平均往復時間を言う。
【０００６】
ディザリング(dithering)：これは、時間遅延の変動(variation of the delay time)を言う。
【０００７】
損失率(loss rate)：これは、ネットワークにおける伝送中に失われたパケットの割合を言い、データを加入者(subscriber)に正しく転送する際のネットワーク性能を評価するために使用される。
【０００８】
利用可能性(availability)：これは、ネットワークが加入者にサービスを提供することができる利用可能なサービス時間(available service time)の割合を言う。
【０００９】
通信ネットワークにおける終端間ＱＯＳ機能(end-to-end QOS function)を実施するために、通常、各ネットワーク要素、例えばルーターやイーサネット（登録商標）スイッチなどは、トラヒック管理および制御の提供、トラヒックシェーピング(traffic shaping)、メッセージ出力速度の調整、および、加入者のデータフローがネットワーク資源を使用することを許可するかどうかの決定のみならず、メッセージをクラス分け(classification)すると共に別の処理、待ち行列管理(queue management)を提供し、且つ別のクラスのメッセージが別のサービスの別のＱＯＳ要件を満たすために発送(dispatching)する能力を有する。
【００１０】
ＩＰ ＱＯＳは、ＲＳＶＰ(Resource Reserve Protocol)に基づく統合サービス(Integrated Service; IntServ)を含み、それは、終端間フロー(end-to-end flow)に基づくＱＯＳ技術であり、その技術を用いて、通信前に、二つの終端(ends)でのアプリケーションは、ネットワークのための要件とサービスのクラスに応じて帯域外ＲＳＶＰシグナリング(out-of-band RSVP signaling)を用いて終端間通信経路(end-to-end communication path)を設定(set up)し、そして、その経路上の各ルーターは、各フローの状態情報を記録すると共に、対応するサービス保証を提供する。
【００１１】
発展性と簡潔性を見つけ出すために、ＩＥＴＦ機関は、デファレンスサービス(Difference Service; DiffServ)技術を提唱した。それは、クラスに基づくＱＯＳ技術であり、主に基幹ネットワークで使用され、この技術は、サービスをクラス分けし、フロー制御を実行し、そしてサービスの要件に従ってネットワーク進入の際にメッセージのＤＳＣＰ(Difference Service Code Point)ドメインを設定し、それは、ＰＨＢ(Per Hop Behave)のために、資源配分(resource allocation)、キュー発送(queue dispatching)、およびパケット廃棄(packet discarding)を含んで、所定のＱＯＳメカニズムに従ってネットワークにおける通信タイプを識別すると共にポリシー(policies)を提供し、ＤｉｆｆＳｅｒｖドメインにおける全ノードはパケットにおけるＤＳＣＰフィールドに応じてＰＨＢに従う。
【００１２】
上記のＩｎｔＳｅｒｖ及びＤｉｆｆＳｅｒｖを組み込むために、統合サービスオーバーデファレンスサービス(IntServ over DiffServ)モデルが開発され、それは、通信ネットワークの二つの終端がＩｎｔＳｅｒｖ／ＲＳＶＰを支援すると仮定し、且つ、終端間経路、例えばＤｉｆｆＳｅｒｖドメインに沿ったＩｎｔＳｅｒｖ／ＲＳＶＰを支援しない幾つかのドメインを想定する。ＤｉｆｆＳｅｒｖドメインは、ＩｎｔＳｅｒｖドメインにおける仮想的なコネクションと見なされ、フローに基づくＲＳＶＰは、潜在的に、ＤｉｆｆＳｅｒｖで他の終端に伝送され、二つの終端間で或る帯域幅が予約される。図１に示されるように、送信元終端(source end)からＤｉｆｆＳｅｒｖドメインの入口までの帯域幅、並びにＤｉｆｆＳｅｒｖドメインの出口から送信先終端(destination end)までの帯域幅が保証される。しかしながら、ＤｉｆｆＳｅｒｖドメインにおいて、帯域幅は、集約フロー(aggregate flows)については保証されるが、個々のフローについては保証されない。この現象を克服するために、ＤｉｆｆＳｅｒｖドメインは、ＲＳＶＰ(Aggregate Resource Reserve Protocol)を支援する。
【００１３】
集約ＲＳＶＰ(aggregate RSVP)は、ＤｉｆｆＳｅｒｖドメインの入口ノードでフローに基づくＲＳＶＰ要求を収集し、この要求を統合し、そしてＤｉｆｆＳｅｒｖドメインの出口ノードからのトータルの帯域幅を要求する。新たなＲＳＶＰ要求または解約要求(Cancel request)があれば、集約ＲＳＶＰは、ＤｉｆｆＳｅｒｖドメインのエッジ間の予約帯域幅を調整する。トータルの帯域幅は、まさに、個々のフローの帯域幅の合計であるから、終端間ＱＯＳ保証が提供される。
【００１４】
ＩｎｔＳｅｒｖオーバーＤｉｆｆＳｅｒｖ技術は、通信ネットワーク資源の妥当な配分を実施することができるけれども、それは、次の欠点を有する。
（１）この技術は、ＩＰネットワークにのみ適用可能であり、ＲＳＶＰとしっかりと結合され、その適用は制限される。
（２）この技術は、集約モデル(aggregate model)にのみ適し、ピアツーピア(peer-to-peer)モデルには適さない。
（３）データフローからの結果の集約フローは、もっぱらネットワークにより決定され、アプリケーション端末(application terminal)との相互通信(interaction)は存在せず、従って、ネットワークは、大量の資源配分ポリシー情報を保持し且つ管理しなければならない。
（４）それは、集約帯域幅事前配分メカニズム(aggregate bandwidth pre-allocation mechanism)を持たない。その代わり、それは、第１アプリケーションフロートリガー確立メカニズム(first application flow-triggered establishment mechanism)を採用する。
（５）ホストと集約器(aggregator)／分散器(de-aggregator)との間には、集約帯域幅配分メカニズムは存在しない。従って、前記クライアント／サーバーモデルでは、サーバーと接続された集約器／分散器は、大量のデータフローに基づくキュー(queues)を支援しなければならない。
（６）それは、資源先取り(resource preemption)メカニズムを持たない。
【００１５】
マルチプロトコルラベルスイッチ(Multi-protocol Label Switch; MPLS)が出現すると、人々は、ＭＰＬＳ ＤｉｆｆＳｅｒｖおよびＭＰＬＳ ＴＥなどのＭＰＬＳを用いてトラヒック伝送のＱＯＳ問題の解決を試みはじめた。ＭＰＬＳとＤｉｆｆＳｅｒｖとの組み合わせは、ＭＰＬＳ ＤｉｆｆＳｅｒｖ（またはＭＰＬＳ ＣｏＳ）と称され、それは、ネットワークのエッジでラベル又はＤＳＣＰを集約し、ネットワークのコアでラベルに基づく転送(forwarding)又はＤＳＣＰに基づくＰＨＢを処理することを意味する。一方、ＭＰＬＳ ＴＥは、実際のネットワークトラヒックを物理的ネットワーク資源と整合させるために、限られたネットワーク資源を前提としてパイロットネットワークトラヒック及びルート提示性能を支援するＬＳＰを利用する。
【００１６】
ＤＳ意識のＴＥ(DS-Aware TE)は、ＭＰＬＳに基づく間接的ＱＯＳ技術であり、それは、ルーティング処理の有効な制御と妥当な資源構成(resource configuration)を通じてネットワーク資源の利用を最適化する。ＭＰＬＳは、Ｌａｙ−２およびＬａｙ−３技術を取り入れ、それは、トラヒックエンジニアリングを解決することにおいて本質的な利点を有する。ＭＰＬＳトラヒックエンジニアリングは、一組のルート律則パラメータを用いてトラヒックリレー(traffic relay)の要件を満足する可能なルートを探索することを通じてネットワーク性能を最適化する。設定中に、ＭＰＬＳ ＬＳＰは、幾つかの制約条件、例えば帯域幅、加入特性(affiliation property)などを運び、そして限られたルートを計算することを通じて、満足するルートを設定する。
【００１７】
しかしながら、図２に示されるように、もし、全ての迅速転送タイプ(Expedite Forwarding-Type; EF-type)のＬＳＰ帯域幅の合計がトータルの帯域幅の５０％を超えると、時間遅延は、Ｍ１ ｍｓを超え、それは、トラヒック伝送要件が満足されないことを意味する。従って、ＥＦサービス帯域幅は、５０％以内に厳密に制御される。図３に示されるように、ＡとＥとの間の帯域幅を２００Ｍと仮定すると、ＦとＥとの間のみならず、ＥとＣとの間、ＣとＤとの間、ＤとＦとの間の帯域幅は全て１００Ｍであり、そして、２０Ｍ ＥＦフローは、ＡからＤへの他の２０Ｍ ＥＦタイプのフローが確立されれば、限られた経路の計算を通じてＡ，Ｅ，Ｆ，Ｄを通る経路上に確立される。しかし、Ａ，Ｅ，Ｆ，Ｄを通る経路上の帯域幅が上記要件を満たすと共に最適であることが、ポイントＡでの計算を通じて分かる。ポイントＥで確立されたＥＦフローのためのＬＳＰ帯域幅の合計が、限られたルートの計算中にトータルの帯域幅の５０％を超えたかどうかを知ることはできないので、ポイントＡは、ポイントＥからポイントＦに８０Ｍ帯域幅が存在することを知っているのみである。従って、ポイントＥで確立されたＥＦタイプのＬＳＰについての時間遅延が保証されないことが有り得る。解決策は、既存のＭＰＬＳ ＴＥ(Multi-protocol Label Switch Traffic Engineering; MPLS TE)、即ちＭＰＬＳ ＤＳ意識ＴＥ(Multi-protocol Label Switch Difference Service-Aware Traffic Engineering)を拡張(expand)して、ポイントＡのポイントＥでの資源占有情報を通知することである。
【００１８】
ＭＰＬＳ ＤＳ意識のＴＥの基本概念は、オリジナルのＭＰＬＳ ＴＥに基づいてクラスに基づく制約条件(class-based constraint condition)を強化することであり、即ち、ＭＰＬＳ ＤＳ意識のＴＥドメインが内部ゲートウェイ(Interior Gateway Protocol; IGP)を通じて互いに各加入者定義のサービスクラスに応じて占有情報および資源を普及することである。接続が設定されている間、ＭＰＬＳシグナリングプロトコルは、帯域幅を特定するのみならず、サービスタイプ、ＥＦ、または確実な転送(Assured Forwarding)（ＡＦ）を特定し、それは、資源が関係するタイプを特定し、これにより、ネットワーク資源が加入者の要求(demand)に応じて最良に利用される。
【００１９】
しかしながら、既存のＤＳ意識のＴＥは、依然として次の欠点を有している。それはＭＰＬＳネットワークにしか適用できないことである。それは、単一の自立システム(autonomous system; AS)におけるＱＯＳ問題しか解決することができず、複数のＡＳにわたる問題を解決することはできない。更に、それは、終端間ＱＯＳ問題を解決することができないと共に、マルチキャスト資源要求を支援せず、従ってその適用可能範囲は限られている。
【発明の概要】
【発明が解決しようとする課題】
【００２０】
本発明の目的は、ネットワーク通信における終端間のＱＯＳ問題を解決すべく、ネットワーク通信における資源配分を実施するためのシステム及び方法を提供することである。
【課題を解決するための手段】
【００２１】
本発明の目的は、次のように達成される。
ネットワーク通信における資源配分を実施するためのシステムであって、該システムは、１又は２以上のＱＯＳ(Quality of Service)自立システム、即ちＱＯＳドメインを備え、個別の資源配分ソリューションが各ＱＯＳドメインに設定され、データフローのための終端間資源配分が、前記１又は２以上のＱＯＳドメインにおける予約資源(reserved resources)に基づき実施される。
【００２２】
前記ＱＯＳドメインは、
ＱＯＳエッジルーター（ＱＥＲ）とＱＯＳコアルーター（ＱＣＲ）とを更に備え、
前記ＱＯＳエッジルーターは、前記ＱＯＳドメインのエッジに配置され、前記資源、データフローの送信先、又は他のＱＯＳドメインに接続され、ＱＯＳドメイン間の又は前記ＱＯＳドメインにおける前記データフローから生成された集約フローのための資源予約経路(resource reservation path)を確立することと、前記集約フローの状態を維持することに関与し、
前記ＱＯＳコアルーターは、前記ＱＯＳドメインに配置されると共に、前記ＱＯＳドメインにおける集約フローのための資源予約経路を確立するように構成される。
【００２３】
前記ＱＯＳドメインは、前記ネットワークにおけるＡＲＥＡまたはルート自立システム（route Autonomous System）に等しいか、等しくない。
【００２４】
前記ＱＯＳドメインは、また、
ポリシーサーバー（ＰＳ）を備え、各ＱＯＳドメインは、ポリシーサーバーが組み込まれ、それは、前記ＱＯＳドメインに関連した前記資源配分ソリューションを維持するために使用され、即ち、前記集約フローのための資源を配分するために前記ＱＯＳエッジルーター及び前記ＱＯＳコアルーターと協調動作するために使用される。
【００２５】
前記システムは、また、アプリケーション端末を備え、前記アプリケーション端末は、送信元端末(source terminal)と送信先端末(destination terminal)とを備え、
前記送信元端末は、送信データフロー(outgoing data flows)を生成すると共に、前記データフローのための資源要求メッセージを前記ＱＯＳエッジルーターに送信し、
前記送信先端末は、受信データフロー(incoming data flows)を最終的に受信し、即ち前記データフローの前記送信先終端(destination end)として働く。
【００２６】
前記システムに基づくネットワーク通信における資源配分を実施するための方法であって、前記通信ネットワークを複数のＱＯＳドメインに分割するステップと、各集約フローのための資源配分を実施するために、前記アプリケーション端末と前記通信ネットワークとの間、および前記ＱＯＳドメイン間で、前記ＱＯＳドメインにおける資源配分ソリューションを決定し、これにより、データフローのための終端間の資源配分を実施するステップとを備える。
【００２７】
前記集約フローは、前記データフローで運ばれる前記情報による前記データフローのクラス分け(classifying)および集約(aggregating)を通じてＱＯＳドメインの前記入口エッジルーター(ingress edge router)において取得されたフローであり、ＱＯＳドメインの前記入口エッジルーターを通じて前記データフローが前記ＱＯＳドメインに流れ込み、前記複数の集約フローは、別の集約フローＩＤによって識別され、前記ＩＤは、ＱＯＳドメインの前記入口エッジルーターによって決定される。
【００２８】
前記方法を実施するための第１のアプローチは、
ａ．アプリケーション送信元端末が、伝送されるべき前記データフローのためのＱＯＳドメインの前記入口エッジルーターに資源要求メッセージを伝送するステップと、
ｂ．前記資源要求メッセージが、各ＱＯＳドメインの前記入口エッジルーターと各ＱＯＳドメインの出口エッジルーターとを順に通過し、前記資源要求メッセージのエッジルーターリストに各通過したＱＯＳドメインのエッジルーターＩＤを加え、前記ＱＯＳドメインの前記出口エッジルーターはＱＯＳエッジルーターであり、このＱＯＳエッジルーターを通じて前記データフローが前記ＱＯＳドメインから出力されるステップと、
ｃ．前記エッジルーターリストを、前記データフローの前記送信先端末と接続された前記ＱＯＳエッジルーターに格納し、引き続いて前記送信先端末に前記資源要求メッセージを送信するステップと、
ｄ．前記送信先端末が、前記資源要求メッセージを送信する前記送信元端末に資源配分メッセージを戻すステップと、
ｅ．前記資源配分メッセージを受信する前記ＱＯＳエッジルーターが、前記格納されたエッジルーターリストに従って前記資源配分経路を決定し、前記決定された資源配分経路に沿って前記データフローのための前記資源配分メッセージを伝送し、前記通過したＱＯＳエッジルーターと隣接ＱＯＳエッジルーターとの間の集約フローのための資源予約の状態を判断し、必要な調整を実行し、そして最終的に前記資源配分メッセージを前記アプリケーション送信元端末に戻すステップと
を含む。
【００２９】
前記ステップｅは、
ｅ１．前記資源配分メッセージを受信する最後のＱＯＳエッジルーターが、前記送信先端末と前記ＱＯＳエッジルーターとの間で資源を配分し、前記ＱＯＳエッジルーターに格納された前記エッジルーターリストを前記資源配分メッセージに添付し、引き続いて前記資源配分メッセージを転送するステップと、
ｅ２．前記資源配分メッセージが各ＱＯＳエッジルーターを通じて通過するときに、前記エッジルーターリストにおける前記隣接ＱＯＳエッジルーターＩＤをチェックし、そして、前記ＱＯＳエッジルーターと前記隣接ＱＯＳエッジルーターとの間に十分な資源があるかどうかを判断し、もし資源が十分にあれば、引き続いて前記資源配分メッセージを転送すると共にステップｅ４を実行し、もし資源が十分になければ、ステップｅ３を実行するステップと、
ｅ３．前記二つのＱＥＲ間の集約フローのための資源配分処理を起動して資源配分を実行し、引き続き前記資源配分メッセージを転送するステップと、
ｅ４．前記アプリケーション送信元端末と接続された前記ＱＯＳエッジルーターが、前記資源配分メッセージを受信し、資源配分を実行し、前記資源配分メッセージから前記エッジルーターリストを削除し、そして、前記資源配分メッセージを前記アプリケーション送信元端末に転送するステップと、
ｅ５．前記アプリケーション送信元端末が前記資源配分メッセージを受信して資源を配分するステップとを更に含む。
【００３０】
ステップｅ３において、集約フローのための前記資源配分処理を起動して資源配分を実行するステップは、
もし、前記ＱＯＳエッジルーターに隣接する前記ＱＯＳエッジルーターが次のホップ(the next hop)であれば、前記ＱＯＳエッジルーターが、次のホップでの前記ＱＯＳエッジルーターに集約フローのための資源要求を送信し、前記次のホップでの前記ＱＯＳエッジルーターが前記集約フローのための資源配分を実行し、そして集約フローのための資源配分メッセージを戻すステップと、
もし、前記ＱＯＳエッジルーターに隣接する前記ＱＯＳエッジルーターが前のホップ(the previous hop)であれば、前記ＱＯＳエッジルーターが、前記集約フローのための資源配分を実行し、前記前のホップでの前記ＱＯＳエッジルーターにデータフローのための資源配分メッセージと集約フローのための資源配分メッセージとを一緒に送信し、ＩＰネットワークについて、前記二つのメッセージが同一のメッセージで運ばれるステップとを含み、
前記前のホップ又は次のホップは、前記データフロー伝送方向における前のホップ又は次のホップである。
【００３１】
前記方法は、更に、前記資源要求とデータフローのための資源配分メッセージとを受信すると、前記ＱＯＳコアルーターは、前記メッセージを潜在的に伝送する。
【００３２】
前記資源要求と集約フローのための資源配分メッセージは、前記集約フローのためのトラヒックパラメータデスクリプションと、ＩＤと、送信先アドレスと、送信元アドレスとを含む。
【００３３】
前記方法を実施するための第２のアプローチは、
ａ１１．端末アプリケーションが、前記隣接ＱＯＳドメインの前記ポリシーサーバーに対するデータフローのための資源要求を起動するステップと、
ｂ１１．前記ポリシーサーバーが、前記データフローのための前記集約フローＩＤを決定し、次のＱＯＳドメインと前記データフローのための現在のＱＯＳドメインとにおける経路を計算し、そして前記次のＱＯＳドメインの前記ポリシーサーバーに前記資源要求を転送するステップと、
ｃ１１．各ＱＯＳドメインの前記ポリシーサーバーが同様に処理を行うと共に、前記送信先端末に接続された前記ＱＯＳドメインの前記ポリシーサーバーが、前記データフローのための前記要求メッセージを前記送信先端末に転送するステップと、
ｄ１１．前記送信先端末で、前記データフローに配分できる前記資源を決定すると共に、資源配分メッセージを前記ポリシーサーバーに戻すステップと、
ｅ１１．前記ポリシーサーバーが、現在のＱＯＳドメインを通じた経路に沿った前記ノードでの前記集約フローのための資源を配分すると共に、前記データフロー伝送方向における前記前のＱＯＳドメインの前記ポリシーサーバーに前記データフローのための前記資源配分メッセージを転送するステップと、
ｆ１１．前記アプリケーション送信元端末が、前記資源配分メッセージを受信して、資源を配分するステップとを含む。
【００３４】
前記資源要求と前記データフローのための資源配分メッセージは、送信元アドレスと、送信先アドレスと、フローＩＤと、集約フローＩＤと、トラヒックパラメータデスクリプションと、ＱＯＳエッジルーターリストとを含む。
【００３５】
前記ステップａ又はａ１１は、前記資源要求メッセージが各ＱＯＳドメインの前記入口で受け入れ可能であることを判断するステップを更に含む。
【００３６】
前記ポリシーサーバーは、前記ポリシーサーバーがある前記ＱＯＳドメインにおける資源占有状況とトポロジー情報とに従って前記資源配分ソリューションを決定する。
【００３７】
前記集約フローのための前記資源配分方法は、
固定配分方法(fixed allocation method)と増加配分方法(incremental allocation method)とを含み、
前記固定配分方法は、配分された資源の量が、前記集約フローによって要求される量に等しく、
前記増加配分方法は、或る粒度(granularity)で前記資源を配分し、配分された資源の量が、前記集約フローによって要求される量よりも多いか等しく、各量が資源の定量(fixed quantity)を規定する。
【００３８】
前記ＱＯＳエッジルーターは、前のホップ／次のホップでのインターフェイスの前記ＱＯＳドメインが同一(identical)であるかどうかを判断することを通して決定される。
【００３９】
前記方法は、更に、高い優先度を有する集約フローによって低い優先度を有する集約フローに配分された資源の先取りのための処理手順、即ち、高い優先度を有する集約フローは資源要求を生成するが、事前配分された資源が十分でないとき、それは、低い優先度を有する集約フローに配分された未使用の資源を先取りし、従って、高い優先度を有する前記集約フローへの前記資源事前配分を実行する手順を含む。
【００４０】
前記方法は、更に、処理手順を含み、この処理手順を通じて、前記集約フローに配分される前記資源が解放(release)され、即ち、前記解放されるべき資源の累積トータルが前記所定量の資源に達したと判断されると、前記集約フローに配分された資源が解放される。
【００４１】
前記方法において、別のＱＯＳドメインは、それらにおいて別のイントラドメイン(intra-domain)資源配分方法を使用してもよく、前記資源配分方法は、シグナリングに基づく資源配分方法(signaling-based resource allocation methods)と、ポリシーサーバーに基づく資源配分方法(policy server-based resource allocation methods)とを含む。
【００４２】
前記方法は、また、前記アプリケーション送信元端末が、経路検出メッセージを前記送信先端末に送信し、前記送信先端末に接続されたポリシーサーバー又は前記ＱＯＳエッジルーターが前記エッジルーターリストを格納し、前記データフロー経路が変化したかどうかを検出し、もし、前記データフロー経路が変化していれば、新たな資源配分を確立すると共に古い資源配分を解約し、前記データフロー経路が変化していなければ、処理を行わないステップを含む。
【００４３】
前記方法は、また、ＱＯＳドメインにおける前記集約フロー経路が前記ＱＯＳドメインを通して通過する前記データフロー経路と異なるとき、又は前記ＱＯＳドメインに複数の等価コスト経路(equivalent cost paths)が存在するとき、前記ＱＯＳドメインの入口でのエッジルーターと前記ＱＯＳドメインの出口でのエッジルーターとの間のトンネル(tunnel)を確立し、そしてデータフロー伝送中に前記確立されたトンネルを通じて前記データフローを転送させるステップを含む。
【００４４】
前記方法は、更に、事前配置された資源の統計的調整の処理を含み、前記処理は、定期的に前記集約フローの時間遅延パラメータと平均レート(mean rate)とに従って前記事前配分された資源を調整するステップを含む。
【発明の効果】
【００４５】
前記技術ソリューションから、本発明による複数のＱＯＳドメインに通信ネットワークを分割することを通じて前記通信ネットワークを管理するための前記方法は、終端間のＱＯＳ問題を有効に解決すると共に、次の利点を有する。
【００４６】
本発明によれば、終端間の経路情報は、送信元／送信先端末に接続されたＱＯＳとメインのエッジルーターでのみ維持され、その一方、他のＱＯＳドメインのエッジルーターは、集約フローのためのエッジ間(edge-to-edge)の資源予約情報のみを維持し、それは、ネットワークノードでの記憶装置(storage)およびシグナリングプロトコル処理のオーバーヘッドのみならず、他のネットワークノードに維持されたフロー状態情報を著しく減少させ、集約フローのための資源を予約するために、通常は特別なキュー(queues)が前記集約フローのために配分され、従って、所要数のキュー(queue)は、ＩｎｔＳｅｒｖアプローチと比較して、著しく減少され、これにより、ネットワークノードでの集約フロー状態情報が減少される。
【００４７】
前記ＱＯＳドメインは、ピアツウピア(peer-to-peer)モードにあり、従って、本発明は、ピアツウピアネットワークモデルおよび階層化ネットワークの両方に適用可能である。
【００４８】
ＩＰ伝送が上記二つのノード間で使用される限り、別のＱＯＳドメインが、別のイントラドメイン資源配分モードを使用してもよい。従って、本発明による方法は、異なるネットワーク間の相互接続を容易化することができ、これにより本発明の適用が拡大される。
【００４９】
エッジノードは、動的プロトコルを通じてデータフロー識別モードを取得し、このような識別モードは、アプリケーションレイヤ上の情報に代えてＩＰ情報を必要とするのみであり、従って、フローのクラス分けは、実施が単純であり、且つ小規模な構成作業負荷しか必要としない。
【００５０】
本発明によれば、高い優先度を有する集約フローは、低い優先度を有する集約フローに事前配分された資源を先取りすることができ、それは、有効な資源利用を確かにすると共に、資源が配分されたデータフローに影響を及ぼさない。
【００５１】
資源事前配分または増加資源配分アプローチは、シグナリングプロトコル上のオーバーヘッドのみならず、資源配分と解放の頻度を有効に減少させ、これによりネットワークを安定化させる。
【００５２】
資源は、次のホップでのエッジルーター上に配分されるので、マルチキャスト資源要求が支援され、且つ、資源予約経路の設定が一層促進される。
【００５３】
ほとんどの場合、本発明によれば、ＱＯＳドメインのエッジルーター間には、十分な資源が存在し、これにより、イントラドメイン資源配分メカニズムを起動する必要がなく、その代わり、ＱＥＲ処理のみが終端間の資源配分のために必要とされ、従って、平均設定時間(mean path setup time)が大幅に短縮される。
【図面の簡単な説明】
【００５４】
【図１】ＤｉｆｆＳｅｒｖに基づくＩｎｔＳｅｒｖモデルの説明図である。
【図２】ＤＳ意識のＴＥ技術ソリューションの資源配分曲線図である。
【図３】ＤＳ意識のＴＥのネットワーク図である。
【図４】本発明によるシステムの構成図である。
【図５】本発明による方法の手順を示す図である。
【図６】図４に示されたポリシーサーバーの作業手順を示す図である。
【図７】本発明によるシステムの図である。
【発明を実施するための形態】
【００５５】
本発明は、ネットワーク通信におけるデータフローの終端間(end-to-end)のＱＯＳ問題を解決し、クラスに基づく統合サービス(Class-Based Integrated Service; CB-IntServ)と呼ぶことができる。それは、任意のネットワークにおける終端間ＱＯＳ保証を提供するために、ネットワークのトポロジー(topology)又はスケール(scale)が何であろうと、ＩｎｔＳｅｒｖの制御プレーン(control plane)をＤｉｆｆＳｅｒｖの転送プレーン(forwarding plane)と結びつける。更に、本発明は、個々のドメインにおいて、複数のドメインにわたって、及び複数のＡＳにわたっての何れでも実施可能である。
【００５６】
個々のデータフローのための終端間ＱＯＳ保証を提供することは、スチームに基づく終端間経路(steam-based end-to-end path)が使用されなければならないことを意味しない。その代わり、単一のネットワーク装置について、唯一必要とされることは、それを通して通過するデータフローのための十分な資源を予約することであり、即ち資源予約が集約(aggregate)されることができ、これは、資源予約の場合において、同一クラスのデータフローのための複数のＱＯＳキューを採用することが実質的にただ一つのキューを採用することと同じ効果を果たすためである。しかしながら、別のクラスのサービスが別のＱＯＳ要件および別のトラヒックモデルを有することを考慮して、それらのための資源は別々に処理されなければならない。
【００５７】
ネットワーク装置で予約されるべき資源の量を決定するために、データフローのための資源要求は、伝送経路上の全てのノード（即ち、ネットワーク装置）に送られなければならならず、その機能は、シグナリング(signaling)、ポリシーサーバー(policy server)、または他のアプローチを通じて実施できる。
【００５８】
単一のネットワーク装置の場合と同様に、ネットワークおけるセグメントについて、そのセグメントを通して通過する各データフローのＱＯＳは、セグメントのエッジ間のサービスのクラスが十分である限り保証されることができ、同様に、セグメントで予約されるべき資源の量を決定するために、データフローのための資源要求はあらゆるセグメントを知らされていなければならない。
【００５９】
通常、資源予約は、二つの段階、即ち、資源要求段階と資源配分段階を含み、ＲＳＶＰにおいて、資源配分は資源要求の後に行われ、単一のデータサービスについて、資源事前配分を採用することは、ネットワーク資源を大幅に浪費すると共に頻繁なシグナリングの相互通信(interaction)をもたらし、ネットワークの安定性に影響を与える。しかしながら、集約されたクラス（即ち、集約フロー）について、全てのデータフローの同時性(concurrency)の可能性は、統計的多重化(statistical multiplexing)のために極めて低い。さらに、集約フローの数は制限され、従って、事前配分された資源が十分でない場合には、集約フローのための資源を事前配分し、動的に資源の量を増やすことが可能である。
【００６０】
詳細には、本発明によるネットワーク通信における資源配分を実施するためのシステムは、複数のＱＯＳ自立システムを備え、以下、ＱＯＳ−ＡＳまたはＱＯＳドメインと称す。そのそれぞれは個別に管理されると共に、統合されたＱＯＳポリシー(unified QOS policy)が一つのＱＯＳドメインで使用される。前記ＱＯＳ−ＡＳは、ルートＡＳまたはＡＲＥＡに等しくてもよく、等しくなくても良い。そして、最も単純なＱＯＳ−ＡＳはそのインターフェイスを備えた装置である。
【００６１】
内部的には、ＱＯＳ−ＡＳは、複数のプロトコル、例えばＩＰ、ＡＴＭ、ＦＲ、ＭＰＬＳおよびイーサネット（登録商標）を通じて、または十分な帯域幅で実施されてもよく、そして、外部に対しては見えない。以下、本発明は、更に、一例としてＩＰネットワークを用いて説明される。本発明によるＱＯＳドメインは次の構成を有する。
【００６２】
ＱＯＳエッジルーター(QOS Edge Router; QER)。これは、ＱＯＳ−ＡＳのエッジ(edge)に配置されると共に、アプリケーション端末又は他のＱＯＳ−ＡＳに接続され、クラス分け(classification)、ラベリング(labeling)、ポリシー、およびシェーピング(shaping)などに関与し、ＱＯＳ−ＡＳの全体について、ＱＯＳ−ＡＳにおけるシグナリングスタートポイントおよびエンドポイントとして働き、そして、エッジ間の集約フローのための資源予約経路を確立すると共に集約フローの状態を維持することに関与する。
【００６３】
もしＱＥＲが他のＱＯＳ−ＡＳまたはアプリケーション端末と接続されれば、ＱＥＲとアプリケーション端末との間またはＱＥＲと他のドメインのＱＥＲとの間の資源予約は、或るシグナリングプロトコルを通じて実行でき、もしアプリケーション端末と接続されれば、ＱＥＲは、ＱＯＳアプリケーションエッジルーター(QOS Application Edge Router; QAER)と呼ばれ、それはデータフローの状態を格納する。
【００６４】
ＱＥＲは二つのＱＯＳ−ＡＳに属してもよく、その場合、ＱＥＲ上のリンクもまた二つのＱＯＳ−ＡＳに属し、そしてＱＥＲは二つのＱＥＲとしてバーチャライズ(virtualize)される。
【００６５】
もし、異機種ネットワーク(herterogeneous network)（例えば、ＡＴＭ）におけるＱＯＳ−ＡＳと接続されれば、ＱＥＲは、また、異なるネットワーク間のＱＯＳパラメータをマッピングすることに関与する。
【００６６】
ＱＯＳコアルーター(QOS Core Router; QCR)。それはＱＯＳ−ＡＳに配置され、メッセージを転送することだけに関与し、ＱＯＳドメインにおけるシグナリングプロトコルを実行し、ＱＥＲ間の集約フローのための資源予約経路を確立し、そして、ＱＥＲが、実行されたクラス分け(classification)、ラベリング(labering)、ポリシー、およびシェーピング(shaping)などを有しているので、集約フローの状態情報を格納する。
【００６７】
ＱＣＲ及びＱＥＲの両方は、或るデータフローに関して定義される。物理的ルーターは、同時に、幾つかのデータフローのためのＱＣＲであると共に、幾つかの他のデータフローのためのＱＥＲであることが有り得る。
【００６８】
アプリケーション端末(Application terminal)。それは、インテリジェント端末サーバー、ＰＣ、ＰＤＡであってもよく、またはデータフローのための送信元(sources)または送信先(destinations)として働いてもよい。アプリケーション端末は、ＱＡＥＲを介してネットワークに資源要求メッセージを送信する。もし、資源が要求を満たせば、それは、保証されたＱＯＳで通信が実行される。もし、通信が双方向であれば、アプリケーション端末は、送信器および受信器の両方であり、両方向における資源を要求すると共に予約する。さらに、アプリケーション端末は、ＱＡＥＲに、固有の識別子、例えばアプリケーション端末から送られたポート情報またはアドレスによって排他的にそれを識別させることができる。
【００６９】
ポリシーサーバー(Policy server)。アプリケーション端末がネットワークに対して積極的に資源を要求すると、ネットワークは、或るポリシー、例えば、料金(charge)、セキュリティーなどに従ってそのために資源を配分するかどうかを決定する。もしデータフローの数が小さければ、その機能はＱＡＥＲ上で実施されてもよい。しかしながら、加入者およびネットワークの規模(scale)が拡大されれば、ポリシーサーバーは、その作業を行うために必要とされる。さらに、ポリシーサーバーは、ＱＯＳドメインのＱＥＲを構成することに積極的(active)であると共に、集約フローのための資源を配分することに積極的であってもよく、上記ポリシーサーバーは、ＱＯＳドメインにおけるリンク資源占有状態およびトポロジー情報に従って資源を配分する。
【００７０】
ネットワーク通信におけるＱＯＳ問題を解決するための究極のアプローチは、データフローのための終端間の資源（例えば、帯域幅）を保証することである。本発明によるネットワーク通信における資源配分のための方法は、ＱＯＳ問題を解決するために、ドメインによる保証(assurance)、事前配分(pre-allocation)、および動的調整（増加配分および統計的調整を含む）などの技術を採用する。本発明による方法は、ＱＯＳドメインにおける資源配分ソリューション、およびアプリケーション端末とネットワークとの間の資源配分ソリューションを含む。
【００７１】
ＱＯＳドメインにおける資源配分ソリューション。データフローは、ＱＯＳドメインのＱＥＲで限られた数の集約フロー、例えば、ＤｉｆｆＳｅｒｖシステムにおいて規定されたＥＦ(Expedited Forwarding)およびＡＦ(Assured Forwarding)に集約され、そして、資源は、ＱＯＳドメインにおけるエッジからエッジへの集約フローのために配分され、それは、ＱＯＳドメインのＱＥＲ間の専用集約フロートンネルを確立することと等価である。
【００７２】
更に、固有のＩＤが、或る方法、例えばＩＰｖ４／ｖ６におけるＤｉｆｆＳｅｒｖコードポイント(Diffserv Code Point)、ＩＰｖ６におけるフローラベル(flow-label)、ＭＰＬＳにおけるＥＸＰ、またはイーサネット（登録商標）における８０２．１ｐなどを用いて、集約フローのために決定され、そして、異種ネットワーク(heterogeneous network)にわたって互いにマッピングすることが必要とされる。
【００７３】
資源配分方法は、シグナリングまたはポリシーサーバーを通じて実施されてもよい。
【００７４】
ＱＯＳドメインにおけるシグナリングプロトコルのための要件は次の事柄を含む。
１．それは、ＱＥＲから開始し、ＱＥＲで終わる。
２．それは、経路に沿ったＱＣＲ上で稼動する。
３．それは、要求(request)、配分(allocation)、解約(cancel)、認証(acknowledgement)、およびエラー報告メッセージ(error report message)を有する。
４．要求されたメッセージで運ばれるデータは、送信元のＱＥＲ、送信先のＱＥＲ、集約フローＩＤ、トラヒックパラメータデスクリプションなどを含む。
５．配分メッセージで運ばれるデータは、送信元ＱＥＲ、送信先ＱＥＲ、集約フローＩＤ、認証され又は修正されたトラヒックパラメータデスクリプションなどを含む。
６．それは、増加配分を支援し、即ち、もともと配分された資源に基づき或る粒度で或る集約フローのための資源を付加または低減する。
７．それは、資源先取りを支援し、即ち、高い優先度を有する集約フローは、要求があると、低い優先度を有する集約フローに配分された未使用の資源を先取りすることができる。
８．それは、トランスポートレイヤ上のプロトコルに基づき信頼性のある伝送を保証する。
９．それは、マルチキャストを支援する。
１０．経路に沿った全てのノードは、各集約フローの状態を維持する。
【００７５】
ポリシーサーバーのための要件は、次の事柄を含む。
１．それは、ＱＯＳドメインにおける送信元アドレスおよびネットワーク資源利用に関する情報のみならず、ＱＯＳドメインのネットワーク装置からリンク状態（即ち、ＱＯＳドメインのトポロジー情報）を取得することができる。
２．それは、資源要求の要件を満たす終端間(edge-to-edge)の経路を計算することができる。
３．それは、経路に沿った全てのノードでの予約された資源の量を設定することができる。
【００７６】
資源配分は、ネットワークノード（伝送経路に沿ったネットワーク装置）からの支援を必要とする。もし、ネットワーク装置が十分な能力を備えていれば、それらは、＜送信元ＱＥＲ、送信先ＱＥＲ、および伝送経路＞の三組のための資源を予約することができると共に、上記三組に基づきクラス分けし発送(despatching)することができる。もし、装置が十分な能力を備えていなければ、それらは、あらゆる集約フローＩＤのための資源を予約し、そしてこの集約フローに基づきクラス分けおよび発送を実行してもよい。上述のいずれの場合でも、各ネットワークノードは、＜送信元ＱＥＲ、送信先ＱＥＲ、集約フローＩＤ、予約された資源＞の情報を維持しなければならない。
【００７７】
ＱＯＳドメイン間資源配分(resource allocation among QOS domains)。資源が配分されると共にＱＯＳドメインにおける集約フローのために予約された後、終端間(edge-to-edge)のチャンネルが形成される。しかしながら、終端間の資源予約を達成するためには、複数ドメインにおける上記終端間のチャンネルが接続されなければならない。従って、資源は、ＱＯＳドメイン間で配分されなければならない。ＱＯＳドメインにおける資源配分とＱＯＳドメイン間の資源配分とを組み合わせることを通じて、終端間資源配分チャンネルは、ネットワーク全体にわたって確立されることができる。
【００７８】
同様に、ＱＯＳドメイン間の資源配分は、シグナリングまたはポリシーサーバーに基づき実施されてもよい。
【００７９】
ドメイン間のシグナリングプロトコルのための要件は次の事柄を含む。
１．それは、ＱＥＲ間で稼動するのみであり、ＱＣＲ間またはＱＣＲとＱＥＲとの間で稼動する必要はない。
２．それは、もし、ＱＥＲが同時に二つのＱＯＳドメインに属すれば、資源を予約する必要はない。
３．それは、要求(request)、配分allocation)、解約(cancel)、認証(acknowledgement)、およびエラー報告メッセージ(error report messages)を備える。
４．要求メッセージで運ばれるデータは、送信元ＱＥＲ、送信先ＱＥＲ、集約フローＩＤ、およびトラヒックパラメータデスクリプションなどを含む。
５．配分メッセージで運ばれるデータは、送信元ＱＥＲ、送信先ＱＥＲ、集約フローＩＤ、認証又は修正されたトラヒックパラメータデスクリプションなどを含む。
６．それは、増加配分を支援する。即ち、もともと配分された資源に基づいて或る粒度で或る集約フローのための資源を低減(reduce)し又は付加(add)する。
７．それは、資源先取り(resource preemption)を支援する。即ち、高い優先度を有する集約フローは、要求があれば、低い優先度を有する集約フローに配分された未使用の資源を先取りすることができる。
８．それは、トランスポートレイヤ上のプロトコルに基づき信頼性のある伝送を保証する。
９．それはマルチキャスティング(multicasting)を支援する。
１０．ＱＥＲは、集約フローの状態を維持する。
【００８０】
ポリシーサーバーのための要件は次の事柄を含む。
１．各ＱＯＳドメインは、それ自身のポリシーサーバーを備える。ネットワーク全体が同一のポリシーサーバーによって管理される必要はない。
２．ポリシーサーバーは、互いにそれらの各ドメインにおける資源遊休情報(resource idlesse information)と終端間資源予約情報(edge-to-edge resource reservation information)を交換する。
３．それは、二つのドメインにおけるＱＥＲ間の資源利用情報を取得できる。
４．ＱＯＳドメインにおけるポリシーがＱＯＤドメインにおける終端間資源経路を計算した後、それは、次のＱＯＳドメインにおけるポリシーサーバーに経路を通知する。
５．各ドメインにおけるポリシーサーバーは、ネットワーク全体にわたって終端間経路に沿ったドメインにおけるノードを構成(configuring)することに関与する。
【００８１】
もし、ＱＯＳドメインが十分な能力を備えていれば、それらは、あらゆる＜送信元ＱＥＲ、送信先ＱＥＲ、集約フローＩＤ＞の三組のための資源を予約すると共に、この三組に基づきクラス分けおよび発送を実行してもよい。もし、ＱＯＳドメインが十分な能力を備えていなければ、それらは、あらゆる集約フローＩＤのための資源を予約すると共に、集約フローに基づきクラス分け(classification)および発送(dispatching)を実行してもよい。
【００８２】
アプリケーション端末とネットワークとの間の資源配分。ネットワーク全体にわたる終端間の資源予約チャンネルが確立された後、最終的にデータフローのための終端間資源配分を実施するため、アプリケーション端末とネットワークとの間の資源配分を実施すると共に、ネットワークの全域で終端間資源予約を調整することが必要である。
【００８３】
アプリケーション端末とネットワークとの間の資源配分のための二つのアプローチが存在する。一つは、集約フローのための資源を配分することであり、他の一つは、データフローのための資源を配分することである。２番目のアプローチは、１番目のアプローチのステップ、即ち事前配分(pre-allocation)である。
【００８４】
１番目のアプローチ、即ち、集約フローのための資源配分は、ＱＯＳドメイン間の資源配分に似ている。配分された資源は集約フローのためのものであるから、遠隔のアプリケーション(remote application)の送信先アドレスは未知であり、従って、予約は終端間(end-to-end)ではない。集約フロー用の資源配分のための二つのアプローチが存在する。一つは、ＱＡＥＲが資源を積極的に配分することである。もう一つは、アプリケーション端末がポリシーサーバーを介してＱＡＥＲへ資源を要求することである。ＱＡＥＲホストが資源を積極的に配分する場合において、ホストは資源配分に関与せず、集約フローのための資源はＱＡＥＲ上に配分されるのみであり、それは、プロキシ(proxy)とみなされてもよい。資源配分がポリシーサーバーを介して実行される場合においては、ホストは、帯域外、帯域内メカニズムで、ポリシーサーバーへ資源を要求してもよく、要求が受け入れられた後には、ポリシーサーバーは資源を配分するためにＱＡＥＲを通知する。
【００８５】
２番目のアプローチは、データフローのための資源を配分することであり、それは、終端間資源配分の一部である。アプリケーション端末はさまざまな形態をとり得るので、データフローのライフサイクル(life cycle)が異なり、従って、資源配分は、動的終端間シグナリングプロトコルを通じて実行される。終端間シグナリングのための要件は次の事柄を含む。
１．それは、アプリケーション端末間のみならず、アプリケーション端末とＱＡＥＲとの間で稼動することができる。
２．ＱＥＲは、従って、プロトコルと処理を認識する。しかしながら、メッセージは、終端間シグナリングプロトコルを通じてＱＥＲ間で潜在的に伝送される。
３．それは、要求(request)、配分(allocation)、解約(cancel)、認証(acknowledgement)、およびエラー報告メッセージ(error report message)を有する。
４．要求メッセージで運ばれるデータは、送信元アドレス(source address)、送信先アドレス(destination address)、フローＩＤ(flow ID)、提案された集約フローＩＤ(proposed aggregate flow ID)、トラヒックパラメータデスクリプション(traffic parameter description)、および通過されたＱＥＲのリスト(list of passed QERs)などを含む。
５．資源配分メッセージで運ばれるデータは、送信元アドレス(source address)、送信先アドレス(destination address)、フローＩＤ(flow ID)、配分された集約フローＩＤ(alloated aggregate flow ID)、認証または修正されたトラヒックパラメータデスクリプション(acknowledged or modified traffic parameter description)、および終端間ＱＥＲリスト(end-to-end QER list)などを含む。
６．要求メッセージがネットワークにおいて伝送されると、通過されたノードは、それがＱＥＲ自身であるかどうかを識別する。もし、それがＱＥＲ自身であれば、ノードはメッセージにおけるＱＥＲリストにそのＩＤを加える。
７．ＱＥＲリストは、ＱＥＲとアプリケーション端末との間の要求／配分メッセージから削除される。
８．終端間配分メッセージがＱＥＲに戻されると、ＱＥＲは、十分な資源がそれ自身と他のＱＥＲとの間の集約フローのために配分されたかどうかをチェックする。もし、十分な資源が配分されていなければ、ドメインにおける／ドメイン間のシグナリングプロトコルメカニズムが起動され、これら二つのＱＥＲ間の増加資源配分を実行する。
９．送信元(source)に接続されたＱＥＲは集約フローのクラスを決定する。それは、要求メッセージにおける提案されたクラスを使用してもよく、または別のクラスを割当てても良い。
１０．要求メッセージは、終端間の経路に沿ったＱＥＲが変更されたかどうかを検出するために、定期的に再伝送される。
１１．それは、トランスポートレイヤ上のプロトコルを用いて信頼性のある伝送を保証する。
１２．それは、マルチキャスト(multicasting)を支援する。
１３．使用されるプロトコルは、ドメイン間の資源配分のためのプロトコルと同じであってもよい。
１４．ドメインにおける資源配分プロトコルは容易に識別されることができる。
１５．ＱＡＥＲのみがデータフローの状態を維持する。送信先に接続されたＱＡＥＲはＱＥＲリストを含む。他のＱＥＲは、データフローの状態を維持しない。
【００８６】
上述したデータフローのための資源配分は、終端間資源配分処理である。一方、集約フローのための資源配分処理は、アプリケーション端末とＱＡＥＲとの間の資源配分を含み、ＱＯＳドメインにおける資源配分とＱＯＳドメイン間の資源配分とは、別個のセクションにおいて実行される。上記二つの資源配分メカニズムの組み合わせは、ネットワーク全体にわたるＱＯＳ資源配分処理を構成する。
【００８７】
実施を簡略化するために、終端間シグナリングプロトコルは、ＱＯＳドメイン間で使用されるもの、即ちデータフローのためのメッセージと同じであってもよく、集約フローは同一のプロトコルを通じて伝送されるが、しかしながら、別のアプリケーション環境においては、プロトコルは、データフローのための資源配分プロトコルまたは集約フローのための資源配分プロトコルとして働く。
【００８８】
以下、本発明による方法（即ち、終端間資源配分の全体処理）を、添付の図面を参照して説明する。
【００８９】
図４に示されるように、ＡＰＰ１は送信元端末であり、ＡＰＰ２は送信先端末であり、Ｒ１−Ｒ４は、４つのＱＯＡエッジルーターであり、ＰＳ１は、ＱＯＳドメイン１（ＱＯＳ−ＡＳ１）のポリシーサーバーであり、そしてＰＳ２は、ＱＯＳドメイン２（ＱＯＳ−ＡＳ２）のポリシーサーバーである。図４のネットワーク構造における資源配分処理は、図５に示され、次のステップを備える。
【００９０】
ステップ１：送信元端末ＡＰＰ１は、資源要求メッセージを起動する。この資源要求メッセージは、送信元アドレス＜ＡＰＰ１＞、送信先アドレス＜ＡＰＰ２＞、フローＩＤ＜送信元ポート、送信先ポート、プロトコル＞、提案された集約フローＩＤ＜ＤＳＣＰ１＞、およびトラヒックパラメータデスクリプションなどを含む。
【００９１】
ステップ２：送信元端末ＡＰＰ１と直接的に接続されたエッジルーターＲ１は、要求が受け入れられるかどうかを判断するために、ポリシーサーバーＰＳ１と相互通信(interact)する。もし要求が拒否されれば、要求失敗メッセージを戻す。もし要求が受け入れられれば、集約フローＩＤがＤＳＣＰ２であると判断する。それは、ＤＳＣＰ１と同じであってもよく、異なっても良い。そして、送信元端末ＡＰＰ１とエッジルーターＲ１との間に集約フローＤＳＣＰ２のための十分な資源が存在するかどうかをチェックする。資源が十分でなければ、要求失敗メッセージを戻す。資源が十分であれば、資源要求メッセージのＱＥＲリストにＲ１ ＩＤを加え、そして資源要求メッセージを転送する。
【００９２】
ステップ３：資源要求メッセージがエッジルーターＲ２を通じて通過すると、エッジルーターＲ２は、前のホップまたは次のホップでのインターフェイスが別のＱＯＳ−ＡＳに属することを検出することを通じてそれ自身がデータフローのＱＥＲであることを確認し、要求メッセージのＱＥＲリストにそれ自身のＩＤを加え、そして資源要求メッセージを転送する。
【００９３】
ステップ４：エッジルーターＲ３では、メッセージが新たなＱＯＳドメインに入るので、エッジルーターＲ３は、資源要求を受け入れるかどうかを判断するために、ＱＯＳ−ＡＳ２のポリシーサーバーＰＳ２と相互通信(interact)する。もし要求が拒否されれば、エッジルーターＲ３は、資源要求失敗メッセージを戻す。要求が受け入れられれば、エッジルーターＲ３は要求メッセージを転送する。
【００９４】
ステップ５：エッジルーターＲ４では、それは、送信先端末ＡＰＰ２に直接的に接続され、次のホップでのインターフェイスが送信先端末と接続されていることを検出することを通じてそれ自身がデータフローのためのＱＡＥＲであることを確認し、要求メッセージのＱＥＲリストにそれ自身のＩＤを加え、そして、エッジルーターＲ４と送信先端末ＡＰＰ２との間の集約フローのための十分な資源が存在するかどうかを判断し、もし資源が十分でなければ、要求失敗メッセージを送信元端末ＡＰＰ１に戻し、資源が十分であれば、ＱＥＲリストを格納し、そして削除されたＱＥＲリストと共に要求メッセージを送信先端末ＡＰＰ２に転送する。
【００９５】
ステップ６：送信先端末ＡＰＰ２は、データフローのための利用可能な資源を決定すると共に、送信元端末ＡＰＰ１に配分メッセージを戻す。
【００９６】
ステップ７および８：エッジルーターＲ４では、エッジルーターＲ４と送信先端末ＡＰＰ２との間の集約フローのための資源を配分し、ＱＥＲリストを加えると共に資源配分メッセージを転送し、そして、同時にエッジルーターＲ４とエッジルーターＲ３との間に十分な資源があるかどうかを判断し、もし資源が十分であれば、エッジルーターＲ３にデータフローのための資源配分メッセージを伝送し、資源が十分でなければ、エッジルーターＲ４では、エッジルーターＲ４とエッジルーターＲ３との間の集約フローのための資源配分処理を活性化し、そして同時に、エッジルーターＲ３に、集約フローのための資源配分メッセージとデータフローのための資源配分メッセージとを一緒に伝送する。ここで、ＩＰネットワークにおいては、上記二つのメッセージは、同一のプロトコルパケットに含めることができ、そしてメッセージがエッジルーターＲ３に到達すると、エッジルーターＲ３は、ＱＥＲリストからＲ４ ＩＤを読み取る。
【００９７】
もし、エッジルーターＲ４とエッジルーターＲ３との間のノードが資源配分要件を満足できなければ、それは、エッジルーターＲ３に集約フローのための要求失敗メッセージを送信するのみならず、エッジルーターＲ４に集約フローのための配分失敗メッセージを送信する。失敗メッセージを受信すると、エッジルーターＲ４は、送信先端末ＡＰＰ２に終端間配分失敗メッセージを送信する。
【００９８】
ステップ９，１０，１１：配分メッセージが、エッジルーターＲ３、エッジルーターＲ２、またはエッジルーターＲ１を通って通過すると、各エッジルーター（Ｒ３，Ｒ２，Ｒ１）は、ＱＥＲリストから前のＱＥＲ ＩＤを読み取り、それ自身と前のＱＥＲまたは次のＱＥＲとの間に予約された資源が十分に存在するかどうかをチェックし、もし資源が十分であれば、ＱＥＲは、送信元端末ＡＰＰ１に配分メッセージを転送し、資源が十分でなければ、資源を配分するために、ドメイン間の、ドメインにおけるシグナリングプロトコル処理を活性化し、もし配分が成功すれば、ＱＥＲは、引き続き送信元端末ＡＰＰ１に終端間資源配分メッセージを転送し、もし配分が失敗すれば、ＱＥＲは、送信元端末ＡＰＰ１に要求失敗メッセージを送信すると共に、送信先端末ＡＰＰ２に配分失敗メッセージを送信する。
【００９９】
もし、ＱＯＳドメインにおけるＱＥＲが、それ自身とデータフローの伝送方向における前のＱＥＲとの間の集約フローのための資源予約の状態を記録しなければ、集約フローのための資源調整のために使用される本方法は、ステップ７および８において述べられたものとわずかに異なる。ステップ１２，１３，１４を参照されたい。本方法は次のようである。エッジルーターＲ１が、それ自身とエッジルーターＲ２との間に十分な資源が存在するかどうかをチェックし、もし資源が十分であれば、ＱＥＲリストを削除すると共に終端間資源配分メッセージを送信元端末ＡＰＰ１に送信し、もし資源が十分でなければ、エッジルーターＲ１は、エッジルーターＲ２に集約フローのための資源要求メッセージを送信し、エッジルーターＲ２から資源配分メッセージを受信すると、ＱＥＲリストを削除すると共に終端間配分メッセージを送信元端末ＡＰＰ１に送信し、このような資源配分モードは、マルチキャスト資源配分を支援すると共に、資源予約経路の確立を迅速化することができる。
【０１００】
ステップ１５：送信元端末ＡＰＰ１は、データフローのための資源を配分すると共に終端間資源配分処理を完了する。
【０１０１】
以下、本発明による方法におけるポリシーサーバーの動作手順を、添付の図面を参照して詳細に説明する。図６に示されるように、ＱＯＳ−ＡＳのそれぞれには、ポリシーサーバーが存在し、それぞれＰＳ１およびＰＳ２と称される。ポリシーサーバーＰＳ１およびポリシーサーバーＰＳ２は、互いに、それらのＱＯＳ−ＡＳと管理されたエッジノード(managed edge node)についての情報を交換すると共に、ＱＯＳ−ＡＳにおけるノードでの資源配分に関する情報を収集する。更に、ポリシーサーバーＰＳ１およびポリシーサーバーＰＳ２は、ドメインにおける集約フローおよびＱＥＲとアプリケーション端末との間の集約フローのための資源を配分すると共に、互いに協調動作(cooperate)して、ＱＯＳドメイン間の集約フローのための資源を配分する。特定の手順は次の事柄を含む。
１．送信元端末ＡＰＰ１は、送信先端末ＡＰＰ２のような送信先アドレスを用いて、ポリシーサーバーＰＳ１への資源要求を起動(initiate)する。上記資源要求メッセージは、送信元アドレス＜ＡＰＰ１＞、送信先アドレス＜ＡＰＰ２＞、フローＩＤ＜送信元ポート、送信先ポート、プロトコル＞、提案された集約フローＩＤ＜ＤＳＣＰ１＞、およびトラヒックパラメータデスクリプションなどを含む。
２．ポリシーサーバーＰＳ１は、集約フローＩＤをＤＳＣＰ２と判断し、それは、ＤＳＣＰ１と同じであってもよく、異なっても良い。ポリシーサーバーＰＳ１は、経路が、ドメインにおけるノードの、ルートテーブルなどで検索することを通じてＱＯＳ−ＡＳ２に入ることを知り、そして、要求メッセージをポリシーサーバーＰＳ２に転送する。
３．ポリシーサーバーＰＳ２は、送信先端末ＡＰＰ２が、ドメインにおけるノードの、ルートテーブルなどにおける検査を通じて現在のドメインと直接的に接続されることを知り、そして要求メッセージを送信先端末ＡＰＰ２に転送する。
４．送信先端末ＡＰＰ２では、データフローに利用可能な資源を決定すると共に、資源配分メッセージをポリシーサーバーＰＳ２に戻す。
５．ポリシーサーバーＰＳ２は、エッジルーターＲ３とエッジルーターＲ４との間に十分な資源があるかどうかをチェックする。もし十分な資源がなければ、さらに、残りの資源が十分に存在するかどうかをチェックする。もし残りの資源が十分でなければ、要求失敗メッセージをポリシーサーバーＰＳ１に送信すると共に、資源配分失敗メッセージを送信先端末ＡＰＰ２に送信する。もし残りの資源が十分であれば、増加方法(incremental manner)でエッジルーターＲ３とエッジルーターＲ４との間の集約フローのための資源を配分し、そして配分メッセージをポリシーサーバーＰＳ１に転送する。
６．ポリシーサーバーＰＳ１での処理は、ポリシーサーバーＰＳ２での処理と同じである。
７．送信元端末ＡＰＰ１で資源を配分する。
【０１０２】
単一のＩＰ ＱＯＳドメインの場合において、本発明による方法の処理手順は次のようである。
【０１０３】
図７に示されるような単一のＩＰ ＱＯＳドメインでは、上述の手順は、次のように簡略化できる。終端間シグナリングプロトコルとドメインにおける資源配分のためのプロトコルは、一つのプロトコルに結合することができ、そして、ＱＥＲリストを記録することは不要である。特定の作業手順は、次の事柄を含む。
１．送信元端末ＡＰＰ３は、資源要求メッセージを起動し、この資源要求メッセージは、送信元アドレス＜ＡＰＰ３＞、送信先アドレス＜ＡＰＰ４＞、フローＩＤ＜送信元ポート、送信先ポート、プロトコル＞、提案された集約フローＩＤ＜ＤＳＣＰ３＞、およびトラヒックパラメータデスクリプションなどを含む。
２．送信元端末ＡＰＰ３と直接的に接続されたエッジルーターＲ５でフローＩＤをＤＳＣＰ４と判断し、これはＤＳＣＰ３と同一であるか又は異なる。
３．エッジルーターＲ５とエッジルーターＲ６との間のノードで終端間要求を潜在的に伝送する。
４．エッジルーターＲ６で、データフローＩＤおよび対応する集約フローＩＤを記録する。
５．送信先端末ＡＰＰ４で、フローのための利用可能な資源を決定し、配分メッセージを送信元端末ＡＰＰ３に戻し、上記メッセージは、アプリケーションアドレス＜ＡＰＰ３＞、送信先アドレス＜ＡＰＰ４＞、フローＩＤ＜送信元ポート、送信先ポート、プロトコル＞、配分された集約フローＩＤ＜ＤＳＣＰ４＞、および認証されたトラヒックパラメータデスクリプションなどを含む。
６．エッジルーターＲ６とエッジルーターＲ５との間の全体経路上に集約フローのための資源を配分する。もし資源が十分でなければ、資源要求失敗メッセージを送信元端末ＡＰＰ３に戻すと共に、配分失敗メッセージを送信先端末ＡＰＰ４に送信する。
７．エッジルーターＲ５で、データフローＩＤおよび対応する集約フローＩＤを記録する。
８．送信元端末ＡＰＰ３で、データフローのための資源を配分する。
【０１０４】
本発明による方法は、更に、終端間経路が変化した場合における次のような処理手順を含む。
【０１０５】
終端間経路が変化すると、制御プレーン(control plane)は、このような変化を認識し、それに応じて資源配分を変える。
【０１０６】
シグナリングプロトコル処理の場合には、図４に示されるように、処理手順は次のような事柄を含む。
１．ＱＡＥＲ、即ち送信先端末ＡＰＰ２と直接的に接続されたエッジルーターＲ４上のデータフローの状態でＱＥＲリスト情報を格納する。
２．送信元端末ＡＰＰ１は、経路が変化したかどうかを検出するために、定期的に終端間要求メセージを再伝送する。
３．要求メッセージが、ＱＡＥＲ、即ち送信先端末ＡＰＰ２と直接的に接続されたエッジルーターＲ４に到達すると、３つの場合が存在する。１）現在のＱＡＥＲが前の通過したＱＡＥＲと異なる。ここで、現在のＱＡＥＲはエッジルーターＲ４´と称される。２）現在のＱＡＥＲが前の通過したＱＡＥＲと同じである。しかし、そのＱＥＲリストが異なる。３）ＱＡＥＲが同じであり、ＱＥＲリストも同じである。そしてそれぞれ、ステップ４，５，６に進む。
４．上記１）の場合には、新たなＱＡＥＲ、即ちエッジルーターＲ４´は、新たな終端間配分メッセージを戻す。古いＱＡＥＲ、即ちエッジルーターＲ４は、タイムアウトの結果として、解約配分メッセージージ(Cancel Allocation message)を送信元端末ＡＰＰ１に送信すると共に、解約要求メッセージ(Cancel Request message)を送信先端末ＡＰＰ２に送信する。
５．上記２）の場合には、エッジルーターＲ４は、新たなフロー状態情報を生成すると共に、新たな配分メッセージ（新たなＱＥＲリストを含む）を送信元端末ＡＰＰ１に送信し、そして、フロー状態情報（ふるいＱＥＲリストを含む）がタイムアウトした後、解約配分メッセージを送信元端末ＡＰＰ１に送信する。
６．上記３）の場合には処理を行わない。
【０１０７】
ポリシーサーバー処理の場合では、処理手順は次のようである。
１．ポリシーサーバーＰＳ１およびポリシーサーバーＰＳ２でデータフロー状態で現在のＱＯＳドメインにおける通過したＱＥＲのリストを格納する。
２．送信元端末ＡＰＰ１は、経路が変化したかどうかを検出するために、定期的に終端間要求メッセージを再伝送する。
３．要求メッセージがポリシーサーバーＰＳ１を介してポリシーサーバーＰＳ２に到達すると、ポリシーサーバーＰＳ１およびポリシーサーバーＰＳ２は、それぞれ、対応するドメインにおける通過したＱＥＲが変化したかどうかを計算する。もしＱＥＲが変化していれば、古いＱＥＲ間の集約フローのための資源配分を解約し、そして新たなＱＥＲ間の集約フローのための資源を配分する。
４．ポリシーサーバーＰＳ１およびポリシーサーバーＰＳ２は、互いに協調動作して、ドメイン全域の一対のＱＥＲが変化したかどうかを計算する。もし一対のＱＥＲが変化していれば、古いＱＥＲ間の集約フローのための資源配分を解約し、そして新たなＱＥＲ間の集約フローのための資源を配分する。
【０１０８】
本発明による方法は、更に、集約フローのための資源発送(resource dispatching)の処置手順を含み、この処理手順は次の３つの手順を含む。
【０１０９】
事前配分された資源の統計的調整。起動中(during initialization)、終端間資源は、頻繁なシグナリング相互通信と資源配分および解除とがほとんどの場合に回避されるように、事前配分される。しかしながら、もし事前配分された資源が、集約フローの統計的特性(statistical characteristics)を満足しなければ、このようなメカニズムは、所望の有効性を提供しないであろう。従って、事前配分された資源の調整は、定期的または不定期的に実行されなければならない。終端間シグナリングについて、このような調整の間の時間インターバルは一層長い。
【０１１０】
上記調整は、資源が不足または過剰であるときには、いつでも、手動または自動的に実行される。このような調整の原理(basis)は、次のような終端間資源の使用の測定(measurement of usage)である。
１．ＱＥＲで事前配分された資源の各ペアを記録すること。
２．測定インターバルを設定すること。
３．インターバル内に、終端間平均レート、時間遅延などを計算すること。
４．次のインターバル内で統計的特性を満足するために次のインターバル内で資源を調整すること。
【０１１１】
通常、帯域幅がホストとＱＡＥＲとの間で調整されるとき、加入者の関与(participation)が必要とされ、例えば、加入者が帯域内(in-band)法または帯域外(out-of-band)法で或る種のサービスを申し込むときに、ネットワークは加入者に適切な帯域幅を配分する。
【０１１２】
増加調整(incremental adjustment)。集約(aggregation)の結果、終端間資源配分が益々増加し、すなわち、終端間のような終端間方法で資源を更新する代わりに、もともと配分された資源に基づき資源を加え又は低減させる。二つのシグナリングプロトコルは、予約および配分メッセージが資源予約のためのメッセージと異なることを可能とするために、要求および配分メッセージにおいて互いに異なる。
【０１１３】
頻繁な資源配送を更に低減させるために、資源は、ある粒度（いわゆる資源粒度(resource granularity)）で増加法で配分されてもよい。各資源粒度は、資源の定量(fixed quantity)を決定し、例えば、各粒度は１００Ｋとして決定されることができる。例えば、もし、要求された資源の量が３５０Ｋであれば、現在の資源要求を満足するために、４粒度(4 granularities)が配分される。同時に、それは、ある程度、次の資源要求を満足することができ、即ち、現在の集約フローのための配分された資源の量は、要求された資源の量に等しいか又はそれよりも多い。
【０１１４】
資源解放(resource release)中、もし、解放されるべき資源の量が粒度の限界(boundary)に到達しなければ、資源は、解放されるべき資源の蓄積量が粒度の限界に到達するまで、集約フローに解放されない。
【０１１５】
資源先取り(resource preemption)。終端間資源が集約フローについて事前配分されるにもかかわらず、集約フローは、新たな資源要求を有するけれども事前配分された資源が十分でないときには、低い優先度を有する集約フローに事前配分された資源を先取りしてもよい。シーケンスは：最低優先度から現在の優先度までである。
【０１１６】
先取りされた資源が解放されると、次の優先度を有する集約フローから始めて、それは、集約フローの現在の資源が事前配分された資源よりも少ないかどうかを判断し、そしてそうであれば、それに資源を解放する。
【０１１７】
資源先取りの単位もまた資源粒度(resource granularity)である。
【０１１８】
ただ一つのルーターとそのインターフェイスとを有するＱＯＳについて、上述の３つの処理手順もまた資源粒度(resource granularity)である。
【０１１９】
本発明において、アプリケーション端末とネットワークとの間の資源を要求するとき、要求メッセージは、要求メッセージはフローＩＤを運び、従って、それを通じて、ＱＡＥＲは、フローを識別すると共に、配分された集約フローＩＤに従ってそのための優先度を設定する。ＱＡＥＲは、また、データフローが規定のトラヒック特性(stated traffic characteristics)を満足することを保証するために、ＣＡＲ(Commit Access Rate)を決定する。
【０１２０】
本発明において、ローカル資源発送(local resource dispatching)は、統計的多重化(statistical multiplexing)を活用する。集約フローの予約された資源は、集約フロー間で動的に共有されることができる。処理サイクルにおいて、高い優先度を有する集約フローの未使用の資源は、低い優先度を有する集約フローによって使用されることができる。
【０１２１】
本発明において、データフロー経路が集約フロー経路と等しいことを保証するために（即ち、データフローが予約経路に沿って伝送されることを確保するために）、次の解決策が使用されてもよい。ＱＯＳ−ＡＳにおいて、データフローの経路は、フローの送信元アドレスと送信先アドレスとで規定される一方、集約フローの経路は、二つの終端でのＱＥＲのアドレスで規定される。特別な場合において、二つの経路が互いに等しくないことが起こり得る。例えば、次のような場合である。
１．ルートポリシー又はポリシーに基づくルーティング(routing)は、経路に沿ったノードで実施され、ルートがメトリックに基づく最適ルート(Metric-based optimal route)ではないことをもたらす。このようなノードは、通常、ＡＳＢＲまたはＡＢＲである。
２．ＱＯＳ−ＡＳには複数の等価な経路が存在するが、資源配分は、それらのうちの一つで実行される。資源は他の経路には配分されない。
【０１２２】
第１の例において、もし、ＱＥＲがＡＳＢＲ／ＡＢＲと等しく、且つルートポリシー／ポリシーに基づくルーティングがＱＯＳ−ＡＳにおいて実行されるノードが存在しなければ、二つの経路は互いに等しい。もし、集約フローの経路がＱＯＳ−ＡＳを通じて通過するデータフローの経路と異なれば、問題は、ＱＥＲ間のトンネルを確立して、そのトンネルを通じてアプリケーションフローを転送させることにより解決できる。
【０１２３】
第２の例において、問題は、ＱＥＲ間のトンネルを確立することを通じてのみ解決できる。
【０１２４】
動作処理(working process)の間、本発明に含まれる終端間シグナリングプロトコルは、次のように、フローのためのＱＥＲを識別する。
【０１２５】
ネットワーク装置で、そのインターフェイスを３つのタイプに識別する。
ａ．加入者インターフェイス。これは、直接的またはＱＯＳなしのネットワークを介して加入者に接続される。
ｂ．ＱＯＳ−ＡＳにおけるインターフェイス。これは、ＱＯＳ−ＡＳにおけるノードと直接的に接続される。（デフォルト）
ｃ．ＱＯＳ−ＡＳ間のインターフェイス。これは、別のＱＯＳ−ＡＳにおけるノードに接続される。
【０１２６】
もし、ＱＥＲが二つのＱＯＳ−ＡＳと交差(cross)していれば、そのインターフェイスの全てが、ＱＯＳ−ＡＳ間のインターフェイスとして構成され、そしてＱＯＳ−ＡＳ ＩＤがそのために設定される。
【０１２７】
要求メッセージがネットワーク装置に到達すると、それは、前のホップ／次のホップでのインターフェイスを計算し、そして、次のように、次のホップ／前のホップでのインターフェイスの組み合わせに従ってＱＥＲを決定する。
ａ／ａ：両方の終端での加入者に接続される。ＱＡＥＲ。
ａ／ｂまたはｂ／ａ：ＱＡＥＲ。
ａ／ｃまたはｃ／ａ：ＱＡＥＲ。
ｂ／ｂ：否ＱＥＲ。
ｂ／ｃまたはｃ／ｂ：ＱＥＲ。
ｃ／ｃ：二つのインターフェイスのＱＯＳ−ＡＳ ＩＤが同じであるかどうかを判断する。もしそれらが同じでなければ、それはＱＥＲである。もしそれらが同じであれば、それはＱＥＲではない。
【符号の説明】
【０１２８】
ＡＰＰ１  送信元端末
ＡＰＰ２  送信先端末
ＰＳ１，ＰＳ２  ポリシーサーバー
Ｒ１，Ｒ２，Ｒ３，Ｒ４  エッジルーター
【図１】
0004796157.tif 000002
【図２】
0004796157.tif 000003
【図３】
0004796157.tif 000004
【図４】
0004796157.tif 000005
【図５】
0004796157.tif 000006
【図６】
0004796157.tif 000007
【図７】
0004796157.tif 000008