JP4567160B2 - 帯域割り当て方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はパケット化された通信ネットワークにおいてトラフィックをルート間で分配する方法に関する。
【０００２】
【従来の技術】
通信ネットワークは、コンピュータ端末、電話、ファクシミリ、及びコンピュータファイルサーバなどの端末通信デバイス間で情報を伝達する。代表的なネットワークには、図１に示されているように、リンク１５．１−１５．１０などによって相互接続された交換ノード１０．１−１０．８が含まれる。一般に、各端末デバイス（図示せず）は、いずれかのノードに関連している。
【０００３】
現在の多くのネットワークにおいて、ソースノードからデスティネーションノード宛に伝達されるべき情報は、パケットすなわちセルに分割される。例えば、非同期転送モード（ＡＴＭ）プロトコルあるいはインターネットプロトコル（ＩＰ）に従うと、これらのパケットは、ソースノードからデスティネーションノード宛に独立に流れる。その経路上で遭遇する各ノードにおいては、パケットはそのパケットによって担われているヘッダ情報に従ってあるリンクあるいは別のリンクへ振り向けられる。以下、この種のネットワークを“パケット化された”ネットワークと呼称する。
【０００４】
電話通話などのある種の通信トランザクションは、デスティネーションにおけるパケットの到達のタイミングにかなり敏感である。絶対的あるいは相対的な遅延がかなりの量存在する場合、あるいは、パケットが異なった順序で到達する場合には、通話品質は受容不能と見なされる。この種のトランザクションの品質を保存するためには、そのトランザクションの間中、ソースからデスティネーションへのルート全体を維持することが望ましい。（以下、通信トランザクションを、ＦＡＸ画像やデータのトランザクションを含む場合においても、一般的に“通話”と呼称する。）
【０００５】
最も単純なネットワークにおいても、与えられたソースと与えられたデスティネーションとの間には、一般に複数個のルートが利用可能である。例えば、図１より、ノード１０．３からノード１０．４へは五つの可能なルートが存在することが明らかである。しかしながら、与えられたソース−デスティネーション対に対して考えられる全てのノードを利用可能にすることは必ずしも望ましくない。
例えば、ある種のルートは過多なリンクを通過しており（すなわち、多過ぎる“ホップ”を有している）、そのことによって全体としての遅延が受容不能な程度になる可能性がある。この問題は、各リンクが限られた帯域しか有していないという事実によってより複雑になる。それゆえ、近接したノード間の通話を遠くのリンクを介してルーティングすることは、そのリンクに近接して存在するノード間のある量のトラフィックを排除してしまうことになる。このことは、そのトラフィックのある部分に対して望ましくないほどの長距離ルートを強要することにもなる。
【０００６】
“トラフィックエンジニアリング”と呼称される考え方は、就中、許容されるルートの中でトラフィックをどのように分配するかという問題を取り扱う。ｋの分配は、所定のレベルのネットワーク性能を実現するような様式でなされることが望ましい。トラフィックエンジニアリング問題は、ネットワークが複数個のサービスクラスを担うことが必要とされる場合に、さらに複雑になる。例えば、同一のネットワークが、音声、映像、ＦＡＸ、及びｅメール伝送を担うことが要求される。これらのサービスは、各々、固有の帯域要求要求を有しており、さらに、どの位の遅延が許容されうるかに係る固有の要求をも有している。また、各々、どの程度の通話ブロッキングが許容されうるかに係る固有の要求も有している。複数のサービスクラスを担うネットワークは“マルチサービスネットワーク”と呼称される。
【０００７】
ネットワークトラフィックは、概して、サービス品質（ＱｏＳ）トラフィックとベストエフォート（ＢＥ）トラフィックとに分類される。
【０００８】
ＱｏＳトラフィックは、顧客に対して受容可能であるために不可欠な要求を満たさなければならないトラフィックである。この種の要求は、通常、受容可能な最大遅延に関連している。しかしながら、それらは他の性能パラメータを含む可能性がある。例えば、ブロッキングに係るパラメータが重要な場合もある。その種のタイプのパラメータには、通話損失比及びパケット損失比が含まれる。ＱｏＳ要求を満たすためには、関連するトラフィックが可能なルートよりなるある種の組に制限されなければならない。この、可能なルートの組、という概念は、ＱｏＳ方式においては、種々のポリシー制限に従うために限定された可能なルートの組を規定するために重宝である。
【０００９】
ＱｏＳトラフィックは、さらに、リアルタイムトラフィックと非リアルタイムトラフィックとに分類される。例えば、音声及び映像トラフィックを含むリアルタイムトラフィックは、顧客によって、それが到達した時点で用いられることを意味している。受信されるデータのスムーズな流れを妨げていると顧客が知覚する全ての遅延は、通常、受容不能である。ファクシミリ機との間のトラフィックなどを含む非リアルタイムトラフィックは、遅延に関してはより許容度の高いものであるが、迅速かつ比較的スムーズな伝達に係る顧客の期待を充足しなければならない。特に、重要なデータトラフィックは、通話損失比及びパケット損失比に関して厳しい制限を有することが多い。
【００１０】
ワールドワイドウェブ、ｅメール、及びＦＴＰなどを含むＢＥトラフィックは、遅延及び通話ブロッキングに関してより寛容である。ユーザは、完全なメッセージを受信するまでに、一般的には数分間、またある場合には数時間の間待機することを許容する。それゆえ、ネットワークサービスプロバイダは、最大遅延に関しては、いかなる特別の制限を保証することを期待されていない。その代わり、ネットワークが、より収益性の高いＱｏＳトラフィックを妨げること無く割くことのできる帯域を、利用可能になった時点で使うことができれば一般には充分である。
【００１１】
ネットワークサービスプロバイダがマルチサービスネットワークを最大限に活用するためには、相異なったサービスクラスに関してそれぞれに規定された、例えば遅延量などに係る制限が満たされることを顧客に対して保証することができることが望ましい。しかしながら、不当な量のトラフィックをブロックすることなくこの種の保証を実現するようなネットワークを設計することは困難である。
例えば、音声トラフィックが、音声通話に関しては最短ルーティングが本質的であるために、ある特定のリンクに集中してしまうような場合には、ファクシミリ伝送はそれらのリンクから除外されるべきである。これらのリンクがファクシミリ伝送のルーティングに必要とされる場合には、ファクシミリを送信するための試みがなされるたび毎にビジー信号が返されることになる。
【００１２】
マルチサービスネットワークにおけるトラフィックエンジニアリングに係る一つのアプローチが、Ｄ．Ｍｉｔｒａらによる“ＡＴＭネットワーク設計及び最適化：マルチレート損失ネットワークフレームワーク”という表題の論文（IEEE/ACM Transactions on Networking第４巻（１９９６年８月）第５３１−５４３頁）に記載されている。この論文は、ＴＡＬＩＳＭＡＮと呼称されるソフトウエアパッケージを記述している。ＴＡＬＩＳＭＡＮは、就中、ネットワークに係る長期間の平均収益によって特徴付けられる性能指標を最大化する目的で、マルチサービスＡＴＭネットワークにおけるジョイントルーティング問題を解決する（ジョイントルーティング問題は、関連する全てのソース−デスティネーション対を連大敵に取り扱うものである）。ＴＡＬＩＳＭＡＮモデルでは、収益指数は、個々のサービスルート（すなわち、与えられたサービスクラスに係るルート）に関して、サービスルートの収益パラメータに当該サービスルート上で受容されたトラフィック強度を乗じたものとして求められる。トラフィック強度は、通話の到達レートに通話当たりの保持時間を乗じたものとして定義される。これらの収益指数は全ストリームに関して、さらに個々のストリーム毎に全サービスルートに関して総和が取られ、全ネットワーク収益が求められる。ストリームは、与えられたサービスクラスに係るソース−デスティネーション対として規定される。
【００１３】
相異なったサービスクラスにおいて利用可能なルートの組が明確なポリシー要求を満たさなければならないようなマルチサービスネットワークに対する要求が強まりつつある。例えば帯域や遅延などのこれまで同様の要求に加えて、最近増加しつつある、仮想プライベートネットワークサービスに係る要求も存在する。
【００１４】
【発明が解決しようとする課題】
ネットワークの規模及び複雑さが増大するに連れ、トラフィックエンジニアリング問題を解くために必要とされる時間も増大する。変化するトラフィックパターンに向き合いつつネットワークの最も効率的な利用を実現するためには、トラフィックエンジニアリング問題のオンライン解法を実行することが望ましい。すなわち、発生した実際の状況に応じた解である。ＴＡＬＩＳＭＡＮなどのツールを利用しても、大規模あるいは複雑なネットワークに関しては、このことは必ずしも可能ではない。
【００１５】
【課題を解決するための手段】
本発明は、少なくとも一つのＱｏＳサービスクラスとＱｏＳクラスではない少なくとも一つのサービスクラスを有するネットワークにおけるトラフィックエンジニアリング問題を解決する方法を提供する。本発明に係る計算の複雑さは、それが多項式に基づくものであるために有限であり、数百ノード及び多数のサービスクラスを有するようなネットワークに関する解をも求めることが可能である。
通常のサイズのネットワークに適用された場合には、本発明に係る方法は、多くの場合、オンライン実行が可能な程度に高速である。
【００１６】
本発明に係る方法に従って、帯域は、少なくとも一つのＱｏＳサービスクラスにおいて、対応するサービスルートに割り当てられる。ここでは、“ＱｏＳ”という術語は、優先的に処理がなされるあらゆるサービスクラスを含むものとして広義に用いられている。この意味では、遅延に敏感なトラフィックと遅延に敏感ではないトラフィックの双方がＱｏＳトラフィックに含まれる。帯域割り当ては、ＱｏＳクラスにおける、各ソース−デスティネーション対間での与えられた帯域要求の組に応答してなされる。マルチコモディティフロー（ＭＣＦ）技法などの線型プログラミング手法が、ネットワーク収益などの適切な性能指数を最適化するような様式でこの割り当てをするように用いられる。
【００１７】
その後、線型プログラミング手法が、前記性能指数の最適値から離れることなくネットワーク利用率を最小化する新たな割り当てを行なうために再度使用される。次いで、残差ネットワークが識別される。この残差ネットワークは、ネットワーク内の各リンク上での未割り当ての帯域よりなる。
【００１８】
その後、ルーティング問題が少なくとも一つの非ＱｏＳサービスクラスに関して解かれる。この種の全てのサービスクラスは、ここでは制限無くＢＥクラスと呼称される。ルーティング問題は、ＢＥサービスクラスにおける全てのフローに係るルートの組を見出し、これらのルートの組の各々における対応するサービスルートに帯域を割り当てるように解かれる。この問題は、線型プログラミング手法を用いて、ベストエフォートトラフィックからのネットワーク収益などの適切な性能指数を最適化するように解かれる。
【００１９】
ＱｏＳクラスのプライオリティは、ＱｏＳ要求を、ＢＥ要求より前に、かつ、ＢＥ要求に関わらずにルーティングすることによって実現される。通常、ＱｏＳサービスクラスに係る実効帯域は、ＢＥクラスのものよりも大きい。これらのファクタの双方は、一般に、ＢＥトラフィックと比較した場合のＱｏＳトラフィックにおけるより少ない遅延、及びより少ない通話ブロッキング／パケット損失レートを実現する。
【００２０】
本発明の望ましい実施例においては、ＱｏＳサービスクラスに係るルーティング問題がルートベース定式化を用いて解かれ、制限されてかつ許容されうるルートの組に係るスペシフィケーションが容易に実現される。対照的に、ＢＥクラスに係るルーティング問題は、リンクベースの定式化を用いて解かれることが望ましい（この種の定式化は、しばしば“エッジベース”と呼称される）。リンクベース定式化は、接続度の高いネットワークに関する問題が解かれる際のスピードを改善する。しかしながら、リンクベース定式化のみでは完全な解とはならない。与えられたサービスクラスにおいて、リンクベース定式化は対応するソース−デスティネーション対に係るリンク毎の帯域割り当てを実現するが、サービスルートの割り当ては実現しない。ルートデコンポジションと呼称されるさらなる手続きが、リンクベースの解からサービスルートによる帯域割り当てを生成するために用いられる。
【００２１】
別の側面では、本発明は、各適切なサービスクラス毎の要求の組に応答してサービスルートに帯域を割り当てる目的での、前述された線型プログラミング手法の利用を含んでいる。重要なことは、この要求が、適切なサービスクラスに関連する実効帯域の割り当てを考慮するよう、さらに、実際に発生するトラフィック要求の確率論的な振る舞いを許容するように計算されることである。
【００２２】
本発明によっていずれかの側面において解かれるトラフィックエンジニアリング問題は、ルーティングと承認制御との組み合わせ問題であることに留意されたい。ルーティングの側面は、与えられたサービスクラスにおける与えられたソース−デスティネーション対間での要求が可能なルートの中で割り当てられることによって明示的に行なわれる。承認制御の側面は、最適割り当てが、全ての要求よりも少ない要求に対するものであるときに暗示的に行なわれる。簡潔に述べれば、承認制御は、例えば収益を最大化する目的でトラフィックが削除される場合に機能する。
【００２３】
【発明の実施の形態】
以下で用いる記号及び及び術語のまとめ
ネットワークはＮ個のノードとＬ個のリンクを有している。各々のリンクは、指数ｌの対応する対応する値に関連している。
【００２４】
サービスクラスはｓで示される。
【００２５】
ソース−デスティネーション対はσで表わされる。
【００２６】
ストリーム（ｓ，σ）は、特定のサービスクラスに係るソース−デスティネーション対である。
【００２７】
（ソース−デスティネーション対間の）各ルートは、指数ｒによって識別される。
【００２８】
与えられたストリーム（ｓ，σ）に係る可能なルートの組は
【数２１】

によって示される。
【００２９】
サービスルート（ｓ，ｒ）は、特定のサービスクラスｓに係るルートｒである。
【００３０】
要求行列
【数２２】

は、サービスクラスｓにおけるソース−デスティネーション対σ間の帯域要求Ｔ_{s, σ}よりなるＮ×Ｎ行列である。要求行列のエントリは、通常、トラフィック測定あるいは予測モデルに基づく。各ＱｏＳサービスクラスに係る要求行列が存在し、ベストエフォートトラフィックに関しても、要求行列
【数２３】

が存在する。
【００３１】
Ｃ_lはリンクｌの帯域すなわち容量である。
【００３２】
ＱｏＳ収益パラメータｅ_srは、与えられたＱｏＳサービスルートによって伝達された単位帯域当たりの収益である。
【００３３】
ベストエフォート収益パラメータｅ_{BE, σ}は、与えられたソース−デスティネーション対間の総ＢＥトラフィックによって担われた単位帯域当たりの収益である。ここでは、簡単のために、この収益レートはルート選択には依存しないと仮定する。ルート依存収益の場合への一般化は容易に実現され、本発明の範疇に含まれるものである。
【００３４】
Ｘ_srは、与えられたサービスルートで担われるフローすなわち帯域である。
【００３５】
Ｆ_σは、与えられたソース−デスティネーション対間の総ＢＥフローすなわち担われた帯域である。
【００３６】
Ｗ_QoSは、全ＱｏＳサービスクラスに係る総ネットワーク収益である。これは、積ｅ_srＸ_srを、全てのＱｏＳサービスクラス、全てのソース−デスティネーション対に関して、及び、各適切なストリーム毎に当該ルートの組（すなわち、可能なルートの組）に関して総和を計算することによって計算される：
【数２４】

【００３７】
Ｗ_BEは、ＢＥトラフィックに係る総ネットワーク収益である。これは、積ｅ_{BE, σ}Ｆ_σの全てのソース−デスティネーション対に関する総和を取ることによって計算される：
【数２５】

【００３８】
式２では、簡単のために、単一のＢＥサービスクラスしか存在しないと仮定している。複数個のＢＥクラスを有する場合への一般化は容易に実現され、本発明の範疇に含まれる。
【００３９】
図２に示された本発明の実施例に従って、ブロック２０に示されているように、それぞれのサービスルートに関する、ネットワークＱｏＳ収益を最大化するようなフローＸ_srを見出すというマルチコモディティフロー（ＭＣＦ）問題が解かれる。この問題への入力は、ＱｏＳ要求行列、リンク容量、各ＱｏＳストリームに係るルートの組、及び、種々のＱｏＳサービスルートに係る収益パラメータである。最大化は、（ｉ）与えられたストリームに関して、当該ストリームに係るルートの組に亘る全フローＸ_srの総和が、当該ストリームに係る要求を越えてはならない；（ｉｉ）フローＸ_srは全て非負で無ければならない；及び、（ｉｉｉ）与えられたリンクを通過する全フローの総和は当該リンクの容量を超えてはならない；という拘束条件の下で実行される。
【００４０】
数学的には、ブロック２０に示されたＭＣＦ問題は、次のように記述される：
【数２６】

このとき、全てのＱｏＳサービスクラスｓ及び全てのσに関して
【数２７】

であり、全てのＱｏＳサービスクラスｓ及び全てのσに関して
【数２８】

であり、かつ、全てのｌに関して
【数２９】

である。
【００４１】
上記拘束条件の最初のものに関しては、少なくともいくつかのストリームに関しては、適切なルートの組に亘る全てのフローの総和が関連する要求よりも少ない場合がありうる。すなわち、承認制御は、要求された帯域のうちのあるものを拒否するように機能する。与えられたストリーム（ｓ，σ）に関して、対応する損失比Ｌ_{s σ}は、以下のように定義される：
【数３０】

【００４２】
ブロック２０に示されたＭＣＦ問題は、Ｗ_QoS ^*を決定するように解かれる。Ｗ_QoS ^*は、総ＱｏＳネットワーク収益の最適値である。担われた総ＱｏＳトラフィックなどの他の性能指標が、ＭＣＦ問題のＱｏＳネットワーク収益と容易に置換されうる。
【００４３】
ブロック２５においては、第二のＭＣＦ問題が解かれる。第一ＭＣＦ問題への全ての入力は、第二のＭＣＦ問題の入力でもある。さらに、第一ＭＣＦ問題に対する解より得られたＷ_QoS ^*がここでは拘束条件として付け加わる。すなわち、ブロック２５におけるＭＣＦ問題は、総ネットワーク収益（あるいは他の性能指数）がＷ_QoS ^*あるいはＷ_QoS ^*より導出された指数よりも小さくないように解かれなければならない。この導出された指数の一例は、Ｗ_QoS ^*未満ではあるが同程度の大きさを有するＷ_QoS ^*の部分値である。ブロック２５のＭＣＦ問題の目的は、帯域ホップ数の総和より求められる、ＱｏＳトラフィックの総リソース利用率を最小にすることである。ＱｏＳトラフィックによる総リソース利用率Ｕ_QoSは、数学的には以下の表式によって表わされる：
【数３１】

ここで、第一の総和はリンクに亘って取られ、第二の総和はストリームに亘り、及び第三の総和は適切なルートの組に亘るものであるが、与えられたリンクｌを含むルートのみである。ＵＱｏＳは、収益に係る拘束条件の下で最小化されるべき目的とする関数である。
【００４４】
別のアプローチでは、リソース利用効率を表わす相異なった指標が最適化される。例えば、この別のアプローチは、最も利用率の高いリンクの利用率を最小化するものである。
【００４５】
さらに別のアプローチにおいては、拘束条件は、最も利用率の高いリンクの飽和を防止する目的で適用される。この種の拘束条件には、与えられたリンクの利用率に関して総リンク容量のうちの所定の割合で上限を与える。
【００４６】
ブロック２５の出力は、全サービスルートに係る、Ｕ_QoSを最小化するＵフローパラメータの組｛Ｘ_sr｝を含んでいる。ブロック３０では、各リンクｌの容量Ｃ_lが当該リンクを介してルーティングされる全てのフローＸ_srだけ減じられる。残存する容量はＣ_l’で表わされる。全ての残存する容量Ｃ_l’よりなる組｛Ｃｌ’｝は、“残差ネットワーク”と呼称される。
【００４７】
ブロック３５においては、ベストエフォートトラフィックに係る総ネットワーク収益（あるいは他のパラメータ）を最大化するというさらなるＭＣＦ問題が解かれる。このＭＣＦ問題を解くために、ネットワークは残差ネットワーク｛Ｃ_l ^'｝であると規定される。よって、ブロック３５への入力は、ベストエフォート要求行列
【数３２】

、｛Ｃ_l ^'｝の組、及び収益パラメータ｛ｅ_{BE, σ}｝の組である。
【００４８】
前述の議論において、ブロック２０及び２５のＭＣＦ問題が、ルートベースの問題として定式化された。すなわち、決定変数Ｘ_srは与えられたサービスルート上のフローに関連付けられているが、個々のリンクに関して個別に規定されてはいない。ＭＣＦ問題に係る別の定式化は、所謂リンクベース（すなわちエッジベース）定式化であり、各決定変数Ｙ_{σ l}、与えられたリンクｌ上の与えられたソース−デスティネーション対σを表わしている。
【００４９】
ルートベース定式化はＱｏＳトラフィックを取り扱う際に有用である。なぜなら、この定式化は、相異なったポリシー拘束条件及び遅延関係拘束条件の双方が、相異なったソース−デスティネーション対尾ｙび相異なったサービスクラスに係るルートに関して適用可能であるからである。これらの拘束条件は、例えば、許容可能総ホップ数などを含んでいる。この種の拘束条件は、総遅延、あるいは他の品質指標、が、希望される条件内に属していることを保証するために有用である。特に、ポリシー拘束条件及び他の拘束条件は、与えられたソース−デスティネーション対及びサービスクラスに関して許容されるルート数を制限する傾向がある。
【００５０】
しかしながら、各ルートの組に可能な複数個のルートを有する高度に相互接続されたネットワークにおいては、ルートベース定式化は非常に複雑になってしまう傾向がある。そのような場合には、ルートベース定式化でＭＣＦ問題を解くことは、現実的な意味では手に負えないものとなる可能性がある。他方、リンクベース定式化の複雑さは、ルート数には依存せず、リンク及びノードの数にのみ依存する。よって、ルートの組が巨大である場合には、リンクベース定式化が有利である。
【００５１】
ＱｏＳトラフィックとは異なり、ベストエフォートトラフィックは、通常、ルート中の許容可能なホップ数に係る上限などのポリシー拘束条件に従わない。よって、残差ネットワークの制限の中でのベストエフォートトラフィックに係るルートの組は極めて大きくなり、少なくともある場合においては、先験的な制限からは自由となる。結果として、ブロック３５においてベストエフォートトラフィックに関してＭＣＦ問題を解く場合には、一般に、リンクベース定式化を用いることが望ましいと思われる。
【００５２】
ブロック３５でのＭＣＦ問題の目的は、拘束条件（ｉ）ソース−デスティネーション対間の総フローＦ_σは非負でなければならず、かつ、対応するベストエフォート要求Ｔ_{BE, σ}よりも大きくてはいけない；（ｉｉ）各ソース−デスティネーション対に関して、与えられたノードに入ってくるリンクに関して取られたフローパラメータＹ_{σ l}の総和は、当該与えられたノードから出ていくリンクに関して取られた総和と、これらの総和が総フローＦ_σの＋１倍（デスティネーションの場合）あるいは−１倍（ソースの場合）だけ異なっている場合以外は、互いに等しくなければならない；（ｉｉｉ）全フローパラメータは非負でなければならない；及び、（ｉｖ）各リンクｌに関して、フローパラメータＹ_{σ l}の全ソース−デスティネーション対σに係る総和はリンク容量Ｃ_lを超過してはならない；という拘束条件に従いつつ、ベストエフォートネットワーク総収益ＷＢＥを最大化するベストエフォートパラメータの組｛Ｙ_{σ l}｝を決定することである。
【００５３】
この問題に関して本明細書において記載されている定式化が所謂“Ｎ²Ｌ”定式化であることは当業者には明らかである。少なくともある場合においては、“Ｎコモディティ”定式化として知られている別の定式化が、平均としてはより大きな計算効率を実現する場合がある。この別の定式化は、例えば、１９９７年１月２１日付の米国特許第５，５９６，７１９号に見出される。
【００５４】
ＱｏＳトラフィックの場合と同様、承認制御に起因するベストエフォート損失比は、
【数３３】

によって規定される。
【００５５】
ブロック３５の結果を適用する目的で、ルートベースベストエフォートフローパラメータの対応する組｛Ｘ_sr ^BE｝から最適の組｛Ｙ_{σ l}｝を回復することが必要である。このことを実現する手続きは、フローデコンポジションと呼称される。ブロック４０においては、フローデコンポジションが、対応するソース−デスティネーション対に係る総フローの組である入力｛Ｆ_σ｝及びリンクベースフローパラメータの組である入力｛Ｙ_{σ l}｝から組｛Ｘ_sr ^BE｝を導出する目的で実行される。
【００５６】
フローデコンポジションを実行する方法は当業者には公知である。その一例が図３に例示されており、以下に記述される。
【００５７】
ブロック４５においては、組｛Ｃ_l ^'｝、｛Ｆ_σ｝、及び｛Ｙ_{σ l}｝が入力として受容される。ブロック５０においては、ソース−デスティネーション対σが処理のために求められる。各ソース−デスティネーション対は、ブロック８０及び８５に示されているように、残存するものが無くなるまで処理される。
【００５８】
ブロック５５においては、還元されたグラフ
【数３４】

が、残差ネットワークから、現在のソース−デスティネーション対σに関して何らフローを担っていない各々のリンクを削除することによって生成される。ブロック６０においては、ルートｒが現在のソース−デスティネーション対を接続することによってトレースされる。ブロック６５においては、現在のルートに係るベストエフォートルートベースフローパラメータＸ_BE,rに対して、現在のルートの全てのリンク上の最小リンクベースフローパラメータに等しい値が割り当てられる。すなわち、
【数３５】

が割り当てられる。さらに、ブロック６５では、現在のソース−デスティネーション対に係る総フロー値Ｆσから量Ｘ_BE,rが減ぜられる。
【００５９】
前述されているように、ブロック６０においては、現在のソース−デスティネーション対を接続している特定のルートｒが
【数３６】

内でトレースされる。ブロック７０においては、現在のルートｒの各リンクに係るリンクベースフローパラメータＹ_{σ l}から量Ｘ_BE,rが減ぜられる。
【００６０】
ブロック７５に示されているように、現在のソース−デスティネーション対に係る総フロー値Ｆ_σがゼロに減ぜられるまで、すなわち、当該ノード対間の全てのフローがルートに関して割り当てられるまで、当該ソース−デスティネーション対に関してブロック５５−７０の手続きが反復される。その後、ブロック７５−８５に示されているように、新たなソース−デスティネーション対が獲得され、ブロック５５−７０の手続きが反復される。全体の手続きは、未処理のソース−デスティネーション対が存在しなくなるまで、残存するソース−デスティネーション対に関して反復される。
【００６１】
ブロック５５における（与えられたソース−デスティネーション対に関する）各反復において、還元されたグラフ
【数３７】

はさらにその直前の反復における条件から還元されることに留意されたい。しかしながら、新たなソース−デスティネーション対が求められる場合には、初期グラフ
【数３８】

は残差ネットワーク全体である。
【００６２】
ルートベースフローパラメータの組｛Ｘ_sr｝及び｛Ｘ_sr ^BE｝が求められた後、それらは、各ストリームにおいて与えられたトラフィックを当該トラフィックに係るルートの組における可能なルートに割り当てるために用いられる。ある割り当て方法例においては、与えられたルートに対して提供されるトラフィックの割合は、当該ルートに係るＸ_srをルートの組における全ルートに亘るＸ_srの総和で除した値にほぼ等しい。この種の方法が、例えば、ネットワークにおける種々のノードでの重み付け公平キューイングと共に用いられるソースノードにおける比例ルーティングを通じて実行されることは、当業者には明らかである。
【００６３】
比例ルーティング及び重み付け公平キューイングは当業者には公知であり、その詳細はここでは記述されない。しかしながら、教育的目的で、比例ルーティングの概要が以下に記述される。各ノードは、Ｓ個のサービスクラスの各々におけるＮ−１湖のソース−デスティネーション対に係る見込みソースノード、すなわち、Ｓ（Ｎ−１）個のストリームの各々に係る見込みソースノードである。これらのストリームの各々には複数個のルートが対応し、各々のルートがトラフィック要求Ｔ_{s σ}のうちの相対的なシェアＸ_sr／Ｔ_{s σ}を有している。この観点では、通話の削除は、そのような相対シェアを有する（見せかけのルート（ファントムルート）への）ルート割り当てとして取り扱われる。各ノードにおけるルータには、Ｓ（Ｎ−１）個のテーブルが、各ストリームに付き一つずつロードされる。
各テーブルには、適切なサービスルートに係る比Ｘ_sr／Ｔ_{s σ}の値がリストされている。通話要求は、ファントムルートを含むこれらのサービスルートに対して、比Ｘ_sr／Ｔ_{s σ}に比例して割り当てられる。
【００６４】
図２に関連して記述されている方法のある種の実施例においては、トラフィック要求Ｔ_{s, σ}は、測定、あるいは、トラフィックモデルからの予測によって求められた平均値である。この目的でトラフィックモデルが用いられる場合には、それは確率論的モデルであることが望ましい。なぜなら、この種のモデルは通信トラフィックの確率論的性質をより正確に説明するからである。
【００６５】
しかしながら、このような平均値の使用は、望ましくないほどの割合の損失につながる可能性がある。このことは、まさに、通信トラフィックが統計的性質を有するからである。実際には要求は一様には発生せず、比較的アクティビティの低い期間によって分離された“要求の束”のように発生する傾向がある。要求が一様に発生すると仮定される場合には、トラフィックエンジニアリングは、要求が束のように到達するような比較的高いアクティビティを有する期間に適用するのに充分な容量を実現することに失敗する可能性がある。結果として、特定のルートへのトラフィックの提供が、その種のルート中の単一あるいは複数個のリンクにおける容量が不充分であるために、拒絶されることになる。このような拒絶は、通話の損失につながる。
【００６６】
本発明の発明者は、大規模ネットワークにおいても計算上の容易さを維持しつつ、通話の到達に係る確率論的性質を考慮することによって、損失割合の低減を約束する方法を導出した。以下、当該方法を、ＱｏＳトラフィックに対して適用した場合が記述される。もちろん、当該方法は、ベストエフォートトラフィックに対しても適用可能である。
【００６７】
本発明に係る方法は、以下にまとめられているような、通信ネットワークの確率論的モデリングに係る種々の量を含んでいる。
【００６８】
例えばポワソン（Poisson）分布をしているような、与えられたストリーム（ｓ，σ）に係る通話の平均到達レートをΛ_{s σ}で表わす。
【００６９】
与えられたストリームに係る通話の平均保持時間を１／μ_{s σ}で表わす。
【００７０】
与えられたストリームの負荷、すなわちトラフィック強度を
【数３９】

と表わす。この量は、Λ_{s σ}／μ_{s σ}に等しい。
【００７１】
量Λ_{s σ}、１／μ_{s σ}及び実効帯域ｄ_sは、一般には、ネットワークの確率論的モデルに対する入力と考えられる。実効帯域は、パケットレベルの可変性、バッファオーバーフロー、バッファ遅延、及びトラフィックの振る舞いの他のパケットレベルＱｏＳ敏感効果及びディスクリプタをまとめ上げたパラメータである。
【００７２】
以下に議論する設計手続きは、さらに、量ρ_srを与える。これは、与えられたサービスルート（ｓ，ｒ）に関する負荷、すなわちトラフィック強度である。ρ_srの値は、前述されたフローパラメータＸ_srに類似のものである。ひとたびそれらが求められると、量ρ_srが、トラフィックエンジニアリング手続きで用いられる。この種の手続きは、例えば、上述された、フローパラメータＸ_srが適切なルートの組にトラフィックを割り当てるために用いられる手続きに類似のものである。
【００７３】
図４は、各々のストリームに関して、残存するストリームが無くなるまで反復される手続きを示している。ブロック９０において、最初のストリームが獲得される。ブロック９５では、行列
【数４０】

の要素Ｔ_{s, σ}が、以下の表式から求められる：
【数４１】

式６においては、αは非負の調節可能なパラメータであり、補償パラメータと呼称される。通話到達プロセスがより可変であると、より多くの補償が必要になり、よって、αの値がより大きいことが望ましい。例えば、理論的解析から、ポワソン分布に従った通話到達、指数関数的に分布する通話保持時間、及びネットワークの臨界負荷に関しては、およそ０．５というαの値が有用であることが見出された。
【００７４】
ブロック１００では、図２に示されたフローベースの設計手続きであるブロック２０及び２５が、フローパラメータＸ_srを求めるために実行される。ブロック９５で求められた要素Ｔ_{s, σ}が、このフローベースの設計手続きへの入力として用いられる。
【００７５】
ブロック１０５では、現在のストリームに係るルートの組の各々のルートに対する負荷ρ_srが、以下の表式から求められる：
【数４２】

【００７６】
ブロック１１０及び１１５に示されているように、ブロック９５−１０５の手続きは、残存するストリームが無くなるまで、各ストリームに関して反復される。その後、ブロック１２０に示されているように、例えば各サービスルート上の損失確率を計算する目的で確率論的ネットワークモデルを用いることによって、期待されるネットワーク性能に関する評価がなされる。これらの予測された損失確率のうちのいずれかがあまりにも高すぎる場合には、補償パラメータα、あるいは前述された方法において用いられている他のパラメータに対する調節がなされる。
【００７７】
図５は、ＱｏＳトラフィックに係るトラフィックエンジニアリングをまとめたものである。ブロック１２５及び１３０は図２に示されたブロック２０及び２５と同様のものであるが、図４に関して記述されているように、確率論的な修正を組み込んでいる。ブロック１３５においては、各サービスルートに関して理論的な損失割合が計算される。ブロック１４０えは、予測された損失レートがいずれかのサービスクラスにおいて高すぎるか否かに係る表示がなされる。
【００７８】
ブロック１４５及び１５０は、望まれない損失を低減する目的でトラフィックエンジニアリングを修正するための別の経路を示している。ブロック１４５においては、ＭＣＦ問題に入力される収益パラメータｅ_srが修正される。ネットワーク収益が第一ＭＣＦ問題で最大化され、第二ＭＣＦ問題で最適レベルに保たれているために、与えられたストリームに帰することが可能な収益の増加は、当該ストリームに係るトラフィックのブロッキングを低減する傾向がある。
【００７９】
ブロック１５０では、ブロック１３０のＭＣＦ問題に別の拘束条件が付加される。これらの拘束条件の性質は、特定の、高度に利用されているリンクにおける利用率を、総容量のうちのある部分に限定するものである。よって、ここでのＭＣＦ問題の目的は、収益に係る拘束条件及び特定のリンクにおける利用率と無撞着なリソース利用率の最小量を見出すことである。これらのリンクにおける容量を予約することによって、比較的高いアクティビティを有する期間におけるそれらリンクの過負荷を回避することが可能である。
【００８０】
ネットワーク設計において重要性を増している一つの問題は、仮想プライベートネットワーク（ＶＰＮ）の問題である。ＶＰＮは、特定の顧客に対して割り当てられた種々のリンクの各々における帯域より構成されるネットワークとして論理的には規定される。本明細書において記述されているトラフィックエンジニアリング技法が単一あるいは複数個のＶＰＮをサポートするネットワークに対して適用される場合には、ＶＰＮの帯域要求をどのように充足させるか、に係る問題が発生する。
【００８１】
本発明の発明者は、この問題に対する、少なくともある種の場合において有用な解法を考案した。当該解法によると、与えられたソース−デスティネーション対間の与えられたサービスクラスにおける要求が、これらの要求のうちのあるものが種々のＶＰＮに係るものであった場合においても、集合体として取り扱われる。その後、フローパラメータＸ_srあるいは負荷ρ_srが求められた後に、これらの量がＶＰＮ及び非ＶＰＮトラフィックに関して割り当てられる。
【００８２】
分割は２段階でなされる。まず、（与えられたストリームに係る）各ルート上の総フローが、総要求に対する非ＶＰＮ要求及びＶＰＮ要求による寄与に直接比例して、非ＶＰＮトラフィックとＶＰＮトラフィックとに分割される。その後、ＶＰＮフロー全体が、それぞれのシェアに従って、種々のＶＰＮ間で分配される。
【００８３】
種々のＶＰＮ間で対応するシェアを決定するための二つの方法が考案されている。一番目の手続きに従うと、各ＶＰＮのシェアは、当該ＶＰＮの総要求に対する寄与に直接比例する。第二の手続きに従うと、帰納的ビンパッキングに係る公知の方法が、各ＶＰＮのシェアを決定する目的で適用される。この第二の手続きは、単一ルート上の各ＶＰＮ要求のルーティングが目的である場合に特に有用である。
【００８４】
非常に簡潔に述べれば、帰納的ビンパッキングは、その対応する要求の大きさの逆順にＶＰＮに順序づけをすることから開始される。第一ＶＰＮに係る要求には、充分な容量を有するルートが割り当てられる。充分な容量を有するルートが存在しない場合には、可能な限りの要求が単一のルートに対して割り当てられ、残存している、未割り当ての要求の大きさによって決定される新たな順序がＶＰＮに対して与えられる。この手続きは、第一順位を有する新たなＶＰＮに係る要求のルーティングに関して反復される。
【００８５】
例
以下、図１に示されたネットワークに基づく理論的な解析が記述される。リンク１５．１−１５．１０の各々は、実際には、各々が一方向を有する一対の方向付けリンクである。各方向付けリンクは、ＯＣ３ユニットと呼称される１５５Ｍｂｐｓの帯域を有しており、リンク１５．３及び１５．８のみが、各方向ともに２ＯＣ３ユニット分の容量を有している。サービスクラスは、音声（クラス１）、画像（クラス２）、重要データ（クラス３）、及び、ベストエフォート（クラス４）である。クラス１及び２に関するルートの組は、最小ホップ数を有するルートに制限されている。クラス３に係るルートの組は、４ホップ以下のルートに制限されている。ベストエフォートクラスに係るルートの組には制限がない。四つのサービスクラスに係る要求行列は、表１に示された行列に、それぞれ０．４、０．１、０．２５、及び０．２５を乗ずることによって得られる。四つのサービスクラスに係る総要求は、それぞれ、５６３．５、１４０．９、３５２．２、及び３５２．２である。
【表１】

【００８６】
図２に示された手続き、ブロック２０及び２５が実行された。結果として得られた解では、全帯域要求が担われた。その後、図２に示された手続き全体が実行された。その結果得られた解では、担われた総ベストエフォート帯域は２７９．４Ｍｂｐｓであった。よって、２０．５％のベストエフォート帯域が失われた。
【００８７】
図２のブロック２５に示されたＱｏＳリソース利用率の最小化により、ＱｏＳクラスの総リソース利用率は２１２０Ｍｂｐｓ−ホップ数になった。残差ネットワークの対応する容量は、１０．３ＯＣ３ユニットであった。比較として、ＱｏＳリソース利用率の最大化も行なった。最大化された総利用率は２６６８Ｍｂｐｓ−ホップ数であり、残差ネットワークの対応する容量は、２．８５ＯＣ３ユニットであった。
【００８８】
さらに、図４に示された確率論的修正も適用し、確率論的モデルにおける損失確率を計算した。この目的のために、サービスクラス１、２、及び３に係る個々の通話の実効帯域を、それぞれ１６ｋｂｐｓ、６４０ｋｂｐｓ、及び３８４ｋｂｐｓとした。
【００８９】
ゼロ補正の場合には、総帯域要求
【数４３】

は１０５６．３Ｍｂｐｓであり、担われた総ＱｏＳ保証帯域
【数４４】

は１０４２．２Ｍｂｐｓ、及び、ネットワーク全体での損失確率は０．０１３４であった。担われた帯域に係る前述の表式においては、量Ｌ_srがサービスルート（ｓ，ｒ）に係る損失確率である。
【００９０】
α＝０．５の場合には、総帯域要求は９７８．８Ｍｂｐｓ、担われた総ＱｏＳ保証帯域は９７６．０Ｍｂｐｓ、ネットワーク全体での損失確率は０．００３であった。
【００９１】
α＝１の場合には、総帯域要求は９０１．３Ｍｂｐｓ、担われた総ＱｏＳ保証帯域は９０１．２Ｍｂｐｓ、ネットワーク全体での損失確率は０．０００１であった。
【００９２】
以上の説明は、本発明の一実施例に関するもので，この技術分野の当業者であれば、本発明の種々の変形例が考え得るが、それらはいずれも本発明の技術的範囲に包含される。
【００９３】
【発明の効果】
以上述べたごとく、本発明によれば、少なくとも一つのＱｏＳサービスクラスとＱｏＳクラスではない少なくとも一つのサービスクラスを有するネットワークにおけるトラフィックエンジニアリング問題を解決する方法が提供される。
【図面の簡単な説明】
【図１】 リンク及びノードよりなる通信ネットワーク例を模式的に示す図。
【図２】 本発明に係るトラフィックエンジニアリング手続きの全体像を示す流れ図。
【図３】 ある実施例において本発明を具体化する際に有用なフロー分解手続きを示す流れ図。
【図４】 ネットワークトラフィックの確率論的性質を考慮した帯域割り当てを実現する、図２に示された手続きへの拡張を示す流れ図。
【図５】 評価及び調節プロセスを含む、ＱｏＳトラフィック指向のトラフィックエンジニアリング手続きを示す流れ図。
【符号の説明】
１０ ノード
１５ リンク

Claims (8)

1. リンクによって相互接続されたノードを有するパケット化通信ネットワークを介したルートに帯域を割り当てる方法であって、前記ルートの各々はソースノードをデスティネーションノードへ接続するものであり、前記方法が、
   ａ）ＱｏＳクラスと呼称されるべき１又は複数個のサービスクラスｓの各々に対し、ネットワーク性能の性能指数Ｗを最適化する、可能なルート間での要求された帯域の初期割り当てを見出す段階を含み、ここで、最適化された値をＷ＊と表し、
   ｂ）前記ＱｏＳクラスの各々に対し、前記可能なルート間での要求された帯域の更なる割り当てがなされることによって、前記初期割り当てに取って代わる段階を含み、（ｉ）前記性能指数Ｗを前記Ｗ＊から導出される特定の最小値に少なくとも保ちつつ、前記ネットワークによるリソース利用を制限する基準を満たすように前記更なる割り当てがなされ、そして、（ｉｉ）前記更なる割り当てがフローパラメータＸ_ｓｒの組を与えるものであり、前記フローパラメータの各々は、ルートｒそれぞれに割り当てられたＱｏＳクラスｓにおける帯域量を表し、前記方法はさらに、
   ｃ）前記ネットワークの前記リンクの各々における未割り当ての帯域容量を識別する段階を含み、前記未割り当てのリンク容量は全体で残差ネットワークと呼称され、そして、
   ｄ）ＢＥクラスと呼称される少なくとも一つの更なるサービスクラスに対し、前記残差ネットワーク上のルートの組と、前記ネットワーク性能の更なる性能指数Ｗ_ＢＥを最適化する、当該ルート間での要求された帯域の割り当てとを決定する段階を含む、方法。
2. 前記要求された帯域の初期割り当てを見出す段階が、線型プログラミング問題を解く段階を有する、請求項１に記載の方法。
3. 前記要求された帯域の更なる割り当てが、前記ネットワークによるリソース利用率指標の最小化を指向した線型プログラミング問題を解くことを含む、請求項２に記載の方法。
4. 前記段階（ａ）及び（ｂ）の前記線型プログラミング問題がマルチコモディティフロー問題である、請求項３に記載の方法。
5. 前記性能指数ＷがＱｏＳサービスからのネットワーク収益である、請求項３に記載の方法。
6. 前記性能指数Ｗ_ＢＥがＢＥサービスからのネットワーク収益である、請求項３に記載の方法。
7. 前記段階（ｄ）が、
   リンクベースのマルチコモディティフロー問題を解く段階を含み、これにより、ソースノード及びデスティネーションノードよりなる適切な対の各々に対し、個々のリンクに係る帯域割り当てを決定し、そして、
   フロー分割を実行する段階を含み、このことによって、前記適切な対の各々を接続する対応するルートに係る帯域割り当てを決定する、請求項３に記載の方法。
8. 前記少なくとも一つのサービスクラスｓに対し、前記通信ネットワークが１又は複数個の仮想プライベートネットワーク（ＶＰＮ）をサポートし、前記要求された帯域が少なくとも一つのＶＰＮに係る要求を含み、そして、前記要求された帯域の前記サービスクラスｓにおけるルートへの前記割り当てがＶＰＮ関連要求及びＶＰＮ非関連要求の集合体に関して初期に実行され、前記方法が、さらに、
   前記サービスクラスｓにおける適切なソースとデスティネーションノードとの間の総要求に対する前記ＶＰＮ関連要求及び前記ＶＰＮ非関連要求のそれぞれの寄与に応じて、前記サービスクラスｓにおける可能なルートの各々に係る前記割り当てられた帯域をＶＰＮトラフィックに係る部分と非ＶＰＮトラフィックに係る部分とに分割する段階を含む、請求項１に記載の方法。

Images