JP4589342B2 - クラスタに基づくネットワークプロビジョニング - Google Patents

Description

本発明は、概して、例えば移動通信のコアネットワークや仮想プライベートネットワーク（Virtual Private Network、VPN）などのようなネットワークのための、ネットワークプロビジョニングに関し、より詳細には、このようなネットワークにおけるディメンショニングや承認制御（admission control）に関する。

ネットワークプロビジョニングは、一般には、ネットワークにおける資源の分配（割り当て）及び管理に関するものであり、しばしば、ネットワークにおける承認制御及びディメンショニングのうち少なくとも一方のような問題を含む。

実際の傾向として、ネットワークを構成するネットワークノードの数が急速に増大し、ネットワークの構造や仮想配置（トポロジ）が大きく、複雑になってきた。この傾向に並行してネットワークノード間のトラフィック量も増え続け、しばしばそれを予想するのが難しくなっている。また、ノード間のトラフィックはノードやトラフィックトランクの数が大きいので測定するのが困難になっている。従って、トラフィック行列の計算が非常に複雑である。多くの場合、トラフィック行列を計算することさえできない。さらに、ネットワークの再設定を要するようなトラフィックの変化の度合いを予想するのは非常に難しくなっている。

資源管理の領域には、現在未解決の課題が含まれる。ネットワークの有効利用を達成するためには顧客のトラフィックの流れを可能な限り良好に把握することが必要である。顧客の種々のアプリケーションをサポートするためにはネットワークプロバイダと顧客の間に、サ−ビス品質（ＱｏＳ）と帯域幅への要求条件を取り決めたサービスレベル契約（Service Level Agreement、SLA）が必要である。現在、ＳＬＡを定め、承認制御を実行するのに２つの方法がある。すなわち、トランクに基づく（顧客パイプ）モデルとホースに基づくモデルであり、いずれも静学（静的）モデルである。

承認制御は、いかなるネットワークプロビジョニングアーキテクチャにおいても欠かすことのできない要素であり、一般には通信ネットワークにおける所定の複数の資源を利用した接続の数を制御する問題である。結果として、承認された接続がサービス品質（ＱｏＳ）の要求条件を満たすために必要とされる資源へのアクセスを保証する。リンクレベルでは、承認制御は、ネットワークのトランスポートリンクに同時に存在することのできる接続の数に制限を加えるのが普通である。これは既にリンクのトランスポートに承認されている接続を保護するために新しい接続が拒否されるということを意味する。

接続承認制御の議論は一般に極めて複雑で、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）、仮想プライベートネットワーク（ＶＰＮ）及び同様の通信ネットワークなどのようなネットワークに対する主要課題は、有効であると同時に、複雑さを抑制したり高精度にしたりするような実用上の要求条件を達成する、効率的な承認制御戦略を見出すことである。

＜トランクモデル＞
トランスポートネットワークに対する、単純なサービスモデルもしくはトラフィックプロビジョニングモデルは専用線サービスをエミュレートするものである。このために、クライアントのノードは可能なすべての発着地の対（ペア）に対する帯域幅への要求条件を規定する必要がある。このモデル、すなわちトランクモデルは図１に示される。

トランスポートネットワークがトランクモデルに基づく場合には、各トランクが１つの顧客の端点から他の顧客の端点まで伸びているようなトランクのメッシュが作られる。顧客の端点はそれぞれのトランクに対して論理インタフェースを保持しなければならない。ＵＭＴＳのコアトランスポートネットワークを例にあげれば、顧客の端点はメディアゲートウェイ（ＭＧＷ）もしくは同等のノードであるということができる。

トランクモデルでは、通常ポイントトゥポイントのトラフィック需要が与えられる想定になっている。言い換えればトラフィック行列の仕様が必要である。本モデルはネットワークプロバイダがネットワークを最良の方法で利用できるようにするものである。なぜならトラフィック行列が既知で、ルーティング戦略があれば、必要なリンク容量が正確に求まるからである。他方、本モデルの限界となる部分は、端点間の通信パターンを記述するのが非常に難しいことである。また、正当化される前提としてネットワークプロバイダはトラフィック行列については非常に限られた情報しか持っておらず、顧客はノード間の負荷を正確に想定（予想）して決めることができないということがある。その結果、トラフィック行列が未知の場合、特にＶＰＮの場合には、トランクまたは顧客パイプモデルの適用が非常に限られる。本モデルの別の問題として、管理がかなり複雑なことがある。所要の容量を関連するノードに対して求めるには、各ノードにおいて入り（着信）と出（発信）のトラフィックを記述するパラメータがそれぞれの関連するノードごとに決定されなければならない。全メッシュの論理ネットワークの場合、設定されるパラメータの総和は、ネットワークもしくはその部分ネットワークにおけるノード数Ｎの２乗に比例する。

＜ホースモデル＞
別のトラフィックプロビジョニングモデルであるホースモデルでは、顧客は接続される端点の集合を規定する必要がある。ネットワーク内の端点間の接続性は以下を含むホースで規定される。

・端点からネットワークに入る（他の端点行きの）出トラフィックの総和に対して必要な容量
・ネットワークから端点に入る（他の端点発の）入トラフィックの総和に対して必要な容量
トランスポートネットワークのディメンショニングがホースモデルに基づく場合、顧客の端点は、ホースというプロバイダのアクセスルータへのただ１つの論理インタフェースを保持する。図２はホースにエッジ間のパイプを用いた代表的な構成を示したものである。

ホースモデルを使う場合、トラフィック行列は不要で、各ノードの入りと出のトラフィックの量だけが知られている必要がある。これらのトラフィックパラメータは、トランクモデルに比べてより正確に測定または予想され得る。従ってホースモデルは顧客から見れば非常に魅力的であるが、ネットワークプロバイダにとっては、行先ノードが分からないという点でトラフィックが不安定になるのでそれほど利点がない。ネットワークの過度なディメンショニングにつながるかもしれないが、本ネットワークは最悪の場合のトラフィック分布に対するディメンショニングをしておかなければならない。管理の複雑さの観点からはホースモデルはトランクモデルよりもかなり少ないパラメータしか必要としない。各ノードでは入りと出のトラフィック量の総和だけが規定されることになるので、設定に使われるパラメータの数はネットワーク内のノード数に比例する。

＜測定に基づく承認制御＞
さらに、別の種類のトラフィックプロビジョニングモデルとして測定に基づく承認制御（ＭＢＡＣ）がある。特に端点間の測定に基づく承認制御の例として、脱落に基づくＭＢＡＣは参考文献[1]及び[2]によって知られている。ＭＢＡＣでは、ノードがネットワーク性能を測定して承認制御の判断の指針を与える。例えば、データ受信機は遠隔サイトごとにユーザプレーンのパケットフローを監視し、リアルタイムトランスファープロトコル（ＲＴＰ）のシーケンス番号を比較することによって脱落したパケットを検出する。脱落したパケットは、ＩＰバックボーンでの輻輳を示し、ＲＴＰは、脱落した、もしくは、シーケンスから外れたパケットを検出する仕組みを提供する。ノードは、相手側に向かうパケット損失の比率が所定の閾値より少ない場合に限り新しい呼を承認する。待ち行列による時間遅れが非常に少ないような場合には、サービス品質はパケット損失によって厳密に測定される。

測定に基づくプロビジョニングの場合には、承認制御の判断は常にネットワークの実際の性能に基づいているので、予想外の事態はすべて適切に処理される。例えば、多重障害の状況でリンクに輻輳が起きた場合には、データ受信機でパケット損失が測定され、そのパケット損失によって輻輳がなくなるまで新規の呼は承認されない。

しかし、測定に基づく承認制御は、例えばＵＭＴＳシステムのバックボーンネットワークにおけるように、欠落に対する条件が厳密な場合には適切なＱｏＳが保証されないという欠点がある。このことで脱落に基づくＭＢＡＣが多くの場面で適用されないということになっているかもしれない。

従来の主なトラフィックプロビジョニングモデルをまとめて次の表に示す。

要約すれば静学的な承認制御はトランク、もしくは、ホースモデルに基づくものであるといえる。

トランクモデルは、承認制御がノードにおいて規定される仮想ポイントトゥポイントのトランクに基づくもので、ネットワークプロバイダがネットワークを最適な方法で利用して、より効果的なネットワーク運用ができるようにする。しかし、トランクモデルでは、相手側ノードに向かうトラフィックを記述するために、すべてのノードにＳＬＡに対応する多くの設定パラメータが必要である。トランク設定の複雑さは急激、実際にネットワークノードの数の２乗、に比例して増大するので、通常大規模ネットワークでは使われない。新しいノードがネットワークに追加されると、新しいトランクがすべての他ノードにおける容量制限を伴って規定、設定されなければならない。トランクモデルの他の重要な問題はトラフィック行列が不明、もしくは、部分的にしか知られていないということである。他方トランクモデルの主な利点は、利用可能な統計的なプロビジョニングの方法の中で最高の帯域幅効率をもたらすことである。

ホースモデルの場合には、ノードでの承認制御の際に着呼点をチェックしないので設定は大いに簡単である。ノードでは入りと出のトラフィック項目が設定されるだけでよい。さらに、ホースパラメータは簡単に測定または予測することができる。ホースモデルの主な欠点は、ネットワークでのかなり過度なディメンショニングを普通に引き起こすことである。ホースモデルにおけるネットワークノードの設定は非常に簡単で、事実、各ノードに２個のパラメータが設定されるだけである。システムに新しいノードが追加されても他のノードの設定に影響を与えない。しかし、ホースモデルの帯域幅効率はトランクモデルの帯域幅効率よりも悪い。

従って、管理の複雑さ、もしくは、帯域効率の悪さのために、トランクでもホースでもプロビジョニングが適用できないような大規模なコアネットワーク、大規模なＶＰＮ、あるいはその他の大規模ネットワークがあり得る。

＜関連技術＞
文献には、ホースもしくはトランクモデルに基づくネットワークディメンショニングを扱った論文があげられている。

ホースモデルの主要な考え方は「ノンブロッキングネットワーク」の理論に関する文献に以前から記載されてきた。例えば、参考文献[3]はホースモデルと全く同じ資源プロビジョニング概念に基づくネットワーク設計手法を記している。

参考文献[4]はＩＰ仮想プライベートネットワークのプロビジョニングにホースモデルを用いた場合の帯域幅効率の解析を記している。計算は音声ネットワーク及び大規模コーポレートネットワークから導かれるトラフィックのトレースドリブンシミュレーションに基づいている。これらは、異なるホースの実施形態ごとに要求されるネットワーク全体に亘る容量について、数値での結果を与えている。ホースモデルに必要な実際の過剰プロビジョニング（過度なプロビジョニング）がバックボーンネットワーク内には存在するものの、従来のパイプ及びホースモデルの帯域幅効率の比較はアクセスリンクに限られる。

参考文献[5]では、ホースの実施形態に対する最適コストの解はツリー状の構造に基づくべきであるとし、（ホースのトラフィック量が送受信で異なる）非対称ホースと拘束条件つきのリンク容量についての一般的な問題はＮＰ−ｈａｒｄ（ＮＰ困難、ＮＰ，非多項式）であることが証明されている。このことから証明可能な性能限界の近似アルゴリズムが[5]に記されている。

この分野での最新の重要な貢献が参考文献[6]に記載されており、ツリーに基づくホースの実施形態を改善する復元アルゴリズムを提案している。

参考文献[7]は、ホースとトランクの資源配分モデルについて資源効率の詳細な比較を示している。ホースモデルの過剰プロビジョニング係数は小規模なネットワーク(特にツリールーティングの場合)ではかなり小さくなり得ることが結論づけられている。しかし、最短経路ルーティングの場合には、過剰プロビジョニング係数はネットワークの規模に応じてかなり増大する。ＬＳＰのための帯域幅確保を組み合わせたときには、ホースモデルの帯域幅効率は低くなることが示されている。ＣＳＰＦルーティングの場合には、ホースモデルの帯域幅効率はさらに低下する。

トランクモデルに関する代表的な論文のいくつかを以下に示す。

参考文献[8]はトランクモデルに関連する種々のネットワーク設計作業の詳細な調査を示している。一般的な構成が提案され、通信ネットワークの設計に関連するいくつかの特別な場合が記されている。この方法は異なったコストモデルを扱うこともできる。

参考文献[9]、[10]及び[11]は種々の通信ネットワーク設計作業の解法に関するものである。

参考文献[12]には障害許容性のあるネットワークの設計について、他の発見的手法が提案されている。

さらに、参考文献[13]、[14]、[15]及び[16]は、障害保護機能のある場合と、ない場合の仮想プライベートネットワークの設計課題を扱っている。

上記のすべてのトランク確保の方法に共通する属性は、設定の複雑さは考慮していないが最小の容量で構成できるネットワークを設計する目的を持つということである。

参考文献[17]の目的は、分散制御アーキテクチャに既存の接続承認制御（ＣＡＣ）を実装し、ＩＰネットワーク上で端点間の資源プロビジョニング統制を行うことである。提案された方法は、基本ドメインに基づく階層ネットワーク、特に複数ＩＳＰが存在する環境に適用可能である。この方法は従来のトランクモデルに基づくもので、分散ＣＡＣ法を実装し、トラフィック集約を可能にするためにクラスタリングが導入されている。特に、ガウシアントラフィック予測器に基づく総和確保の、全要素が満たされたトラフィック行列による承認制御戦略が用いられている。

本発明の一般的な目的は、改良されたネットワークプロビジョニング戦略を提供することである。

本発明の目的は効率的な新しい承認制御戦略とともに、それに対応するネットワークディメンショニングの仕組みを提供することである。

より詳細な目的は（管理の複雑さの観点から）スケーラブルであると同時に、資源効率の良い承認制御とディメンショニング戦略を提供することである。

特有の目的は通信ネットワークのプロビジョニングに改良された方法と構成を提供することである。

別の特有の目的は、なかでも、ネットワークディメンショニングの目的に使われる設計及びサポートツールのうち少なくとも一方を提供することである。

本発明のさらに別の特有の目的は、通信ネットワークで運用される新しい承認制御装置を提供することである。

既に見てきたように従来技術では大規模ネットワークに対して適切なトラフィックプロビジョニングモデルを選択する場合の一般的な問題として、トランクモデルは資源効率は良いが管理が複雑であり、ホースモデルは設定は容易であるが帯域幅効率が悪いということがあった。

本発明は少なくともネットワークの一部を複数のクラスタに分割する発想に基づいている。ここで、各クラスタは少なくとも２個のノードを有する。本発明はまた、クラスタ内レベル及びクラスタ間レベルを含む少なくとも２つのレベルにおいて、トラフィックの制限を規定する発想に基づいている。ここで、トラフィックの制限は、クラスタ間のトラフィックに対するノード−クラスタ間のトラフィックの新規な制限を１つ以上含んでいる。最後に、規定されたトラフィック制限に基づいて、クラスタに基づくネットワークのプロビジョニングが実行される。クラスタに基づくプロビジョニングをこのように用いることによって、管理の複雑さと過剰プロビジョニングの間の最適なバランス、もしくはトレードオフを見出すことができる。

従来のトランクモデルでは、ノードからノードへのトラフィックに制限があり、一方、従来のホースモデルでは、ノードから他のすべてのノードへのトラフィックにのみ制限がある。本発明で提案されるモデルでは、（さらに）、トラフィックがノード−クラスタ間の１つ以上の制限にも拘束され得る。「ノード−クラスタ間の制限」という表現は、普通、所定のクラスタにおける所定のノードの、少なくとも１つの他のクラスタに対するトラフィック量の制限を意味すると理解すべきである。一般に、この制限は入り方向及び出方向のうち少なくとも一方のトラフィックについて規定される。

本発明によって提案される新しいノード−クラスタ間の（１以上の）制限は、クラスタ間レベルにおいて、いわゆるクラスタに基づくトランクモデルまたはクラスタに基づくホースモデルに適用されることが好ましい。換言すれば、クラスタ間トラフィック（複数クラスタ間のトラフィック）を記述するために、トラフィックについての利用可能な情報に応じて、クラスタに基づくトランクモデルまたはホースモデルが使えることが好ましい。また、クラスタをグループにして、いわゆるインター−ホースまたはインター−トランクのプロビジョニングを各クラスタグループに対して独立に選択することも可能である。

クラスタ内トラフィック（共通のクラスタに属する複数ノード間のトラフィック）は、必要ならばクラスタごとに独立に、従来のトランクモデルまたはホースモデルによって記述することができる。このことは、トラフィック記述モデルあるいは帯域幅配分モデルがネットワーク内の各クラスタに対して独立に選択でき、従来技術におけるネットワークプロビジョニングの方法に比べてより高い柔軟性が提供できることを意味している。

クラスタ内プロビジョニングにトランクモデルもしくはホースモデルを選択することと、クラスタ間プロビジョニングにクラスタに基づくトランクモデルもしくはホースモデルを選択することによって、以下の基本的な組合せができる。すなわち、
・イントラ−トランク、インター−トランク（イントラ−トランク＆インター−トランク）
・イントラ−ホース、インター−トランク（イントラ−ホース＆インター−トランク）
・イントラ−トランク、インター−ホース（イントラ−トランク＆インター−ホース）
・イントラ−ホース、インター−ホース（イントラ−ホース＆インター−ホース）
である。

従来のトランクモデルとホースモデルにはまた、別のトレードオフがある。トランクモデルはトラフィックの構造の変化に対して極めて敏感であるが、ホースモデルは非常に耐性がありそのような変化の影響を受けにくい。本発明で提案されるプロビジョニング戦略はこのトレードオフを調節することも可能である。

広範な研究とシミュレーションの結果、イントラ−ホース＆インター−トランクのプロビジョニングが、多くのトラフィックの応用や運用（状況）において、最高の総合性能を与えることが示されている。

提案のサービスモデルは、それゆえ、サイトまたはノードクラスタの概念に基づいて、サービスレベル契約(Service Level Agreements、SLA)のようなサービスレベル規定を、純粋なホース及びトランクモデルよりも柔軟に決めることを可能にする。クラスタをネットワークのサイトまたはノードの集合と規定することによって、サービスレベル規定において、クラスタ内プロビジョニングとクラスタ間プロビジョニングを区別することができる。

一般に、クラスタに基づくプロビジョニングは資源配分及びネットワーク管理のうちの少なくとも一方関連しており、さらに、承認制御及びネットワークディメンショニングのうちの少なくとも一方を含むことが好ましい。

クラスタに基づく承認制御にとって、サービスレベル規定もしくはＳＬＡにおけるノード−クラスタ間の（１以上の）トラフィック制限が、クラスタ間レベルにおける承認制御に適用されることが好ましい。クラスタ内レベルでは、ＳＬＡで決められた補助的なトラフィック内制限が時と場合に応じて適用されることがある。

クラスタに基づくディメンショニングでは、ネットワーク内の多数のリンクの容量は、少なくとも部分的に、クラスタ間レベルにおけるノード−クラスタ間のトラフィック制限に基づいてディメンショニングされることが好ましい。典型的には、ディメンショニング作業は、クラスタ内レベルにおける少なくとも１つの補助的なトラフィック制限にも基づいている。

ディメンショニング作業は、クラスタに基づくサービスレベル規定またはＳＬＡで与えられるトラフィック制限の少なくとも一部に基づいて所要のリンク容量を計算する、ネットワーク設計ツールもしくはサポートツールによって行われることが好ましい。そのような設計ツールを、ＳＬＡと同じトラフィック制限に基づいて動作する、クラスタに基づく承認制御機能を持ったネットワーク管理モジュールに組み込むことにより、ネットワーク資源とＣＡＣ設定が実際に調和されることが確かになる。

本発明の効果は次のとおりである。

・実装が簡単−ノードに加える変更はごく僅かでよい。
・管理の複雑さがスケーラブルである。
・スケーラビリティと帯域幅効率のほぼ最適なトレードオフが得られる。
・提案されたプロビジョニングモデルは、オペレータがネットワークのトラフィック分布の情報を正確に知らない場合でも使うことができる。

本発明、及び発明のその他の目的や効果は添付の図面と合わせた説明を参照することによってよりよく理解されよう。

本発明はクラスタに基づくプロビジョニングを提案するもので、好ましい実装において、基本的にはネットワークノードの設計にわずかな変更しか必要とせず、ルータには好ましくは新しい機能を必要としない。

基本となる着想は、ネットワークもしくは、少なくともネットワークの一部をマルチノードのクラスタもしくは論理資源ドメインに分割することである。従ってそのようなクラスタの各々は、少なくとも２つのノードを含む。最下レベルには、基本クラスタに分割されたネットワークノードがあり、必要なら基本クラスタはいわゆるスーパークラスタに分割されたり、さらに任意の上位レベルのクラスタに分割されたりしてもよい。しかし、基本の構想では、階層構造は、任意のスーパークラスタを有する基本クラスタに分割されたネットワークノードを含むことになっている。

着想は次に、少なくともクラスタ内レベルとクラスタ間レベルを含むネットワークに対し、１つ以上のノード−クラスタ間のクラスタ間レベルのトラフィック制限を設定し適用して、クラスタに基づくプロビジョニングを実行することである。このプロビジョニング戦略は大規模ネットワークに良好に適用でき、クラスタリングによってノード−クラスタ間の制限を規定することが可能になり、管理の複雑さと過剰プロビジョニングの間の適切なバランスを見出すことが可能になる。

提案されたサービスモデルは、ＶＰＮを背景にしたＳＬＡのようなサービスレベル規定を（サイトまたはノードクラスタの概念に基づいて）単なるホース及びトランクモデルよりも柔軟な方法で設定できるようにするものである。クラスタをネットワークサイトまたはノードの集合と規定することにより、サービスレベル規定（例えば、ＳＬＡ）における、クラスタ内トラフィックとクラスタ間トラフィックを区別することができる。

通常、帯域幅配分もしくは承認制御モデルとも言われる、トラフィックプロビジョニングモデルの選択は、トラフィック分布についての利用可能な情報に基づくことが好ましい。大まかに言って、「既知の」トラフィックに対してはトランクまたはトランク類似のモデルを用いるのがよく、「未知の」トラフィックに対してはホースまたはホース類似のモデルを使うのがよいとされる。

クラスタ内プロビジョニングにはトランク及びホースモデルを用いることができる。クラスタ内でのトランクプロビジョニングは、サービスレベル規定（例えば、ＳＬＡ）がクラスタ内のそれぞれ対となるノード間のポイントトゥポイント制限を含むことを意味するのが普通である。クラスタ内トラフィックのためのホースプロビジョニングは、同じクラスタ内の他のあらゆるノードまたはサイトへの総トラフィックは、各ノードまたはサイトで制限されることを意味するのが普通である。

外部クラスタが単一のエンティティと考えられる場合には、いわゆるクラスタに基づくトランクまたはホースモデルをプロビジョニングに用いることができる。クラスタ間トラフィックに関連するトランクプロビジョニングは、例えばトラフィックの帯域幅が各サイトまたはノードから各クラスタへという分と、各クラスタから各サイトまたはノードへという分とについて両者もしくはそれぞれについて合計したものに制限が加えられるようにして適用されてもよい。クラスタ間プロビジョニングのためのホースプロビジョニングは、例えばクラスタ間の総トラフィックに対する帯域幅制限を加えるようにして適用されてもよい。

クラスタに基づくプロビジョニングの利点の一つに、ＳＬＡのようなサービスレベル規定を利用可能なトラフィック情報にあわせて決められることがある。

図３のフローチャートに図示されるように、ネットワークはまずクラスタに分割または区分される（Ｓ１）。次のステップでは（Ｓ２）、本発明で提案された、新規の、ノード−クラスタ間の制限を含むトラフィック制限が設定または規定される。クラスタリングとそれに関連したトラフィック制限に基づいて、クラスタに基づくネットワークのプロビジョニングを行う（Ｓ３）。

上述のように、本発明の新しいプロビジョニング戦略は、特に大規模なネットワーク帯域幅効率と設定の複雑さの両方に関して良好に適合する。このプロビジョニング戦略ではまた、トラフィック構造の変化に対する感度と耐性のバランスを見出すことが可能である。

対象となる各クラスタ、すなわち、クラスタ内トラフィックに対して、ホース、トランクあるいはそれ以外の適当なトラフィックプロビジョニングモデルが用いられてもよい。このことは、しばしば承認制御モデルと言われるトラフィックプロビジョニングモデルが、必要ならネットワーク内の各クラスタに独立に選べること、従って、従来技術によるネットワークプロビジョニングに比べて高度な柔軟性を与えることを意味している。通常この作業は初期設定の段階で行われる。好ましくはトランクまたはホース型の記述はクラスタ内トラフィックに対してクラスタの範囲内で規定される。トランク型のクラスタ内トラフィックの記述では、ノード間のトラフィック需要がそれぞれ対となるノード間に与えられることを意味するのが普通である。ホース型のクラスタ内トラフィックの記述では、そのノードから同じクラスタにあるノードまで、あるいは同じクラスタにあるノードからそのノードへの総トラフック需要が規定されることを意味する。

同様に、クラスタ間トラフィック（複数クラスタの間のトラフィック）の記述では、ネットワーク（あるいは各クラスタの集合）に対して、いわゆるクラスタに基づくホース、トランクあるいはそれ以外のトラフィックプロビジョニングモデルを、好ましくは利用できるトラフィック情報に応じて、用いることができる。このことはクラスタに基づくトランクもしくはホース型の記述がクラスタ間トラフィックに対して適用されてもよいことを意味する。トランク型のクラスタ間トラフィック記述は、そのノードから他のクラスタへ、もしくは他のクラスタからそのノードへの総トラフィックが規定されることを通常意味し、ホース型のクラスタ間トラフィック記述では、所定のノードから、もしくは所定のノードへの総クラスタ間トラフィックが通常規定される。好ましくは、本発明による全体としてのプロビジョニング戦略は、クラスタ内プロビジョニングとクラスタ間プロビジョニングの双方に対し、適切なプロビジョニングモデルを選択することを可能にする。特に、静的トラフィックプロビジョニングモデルが考えられる。例えば、トランクモデル及びホースモデルのうち少なくとも一方の概念を、クラスタ内とクラスタ間のトラフィックに適用することによって、ネットワークの帯域幅効率を大きく低下させることなくトラフィック記述と管理を簡単化することができる。

クラスタ内プロビジョニングに対してのトランクモデルとホースモデルの選択と、クラスタ間プロビジョニングに対するクラスタに基づくトランクモデルとホースモデルの選択には、以下の基本的な組合せがある。

イントラ−トランク、インター−トランク：この場合は、クラスタ内とクラスタ間の両方でトランクモデルが使われる。

イントラ−ホース、インター−トランク：クラスタ内ではホースに基づくプロビジョニングが使われ、クラスタ間ではクラスタに基づくトランクモデルが使われる。

イントラ−トランク、インター−ホース：クラスタ内ではトランクモデルが使われ、クラスタ間トラフィックに対してはクラスタに基づくホースモデルが使われる。

イントラ−ホース，インター−ホース：この場合は、ホース−モデルに基づくプロビジョニングがクラスタ内とクラスタ間の両方で使われる。

既に述べたように、新しいプロビジョニング戦略は、ネットワークをクラスタに論理的に分割すること、及び、クラスタ間とクラスタ内のトラフィックを区別することに基づいていることが好ましい。

＜クラスタ内トラフィック＞
所定のクラスタＣｋとノードｕがそのクラスタにあるとする。このとき、このノードのクラスタ内トラフィックを、例えば次の２つの代表的な方法で求めることができる。

イントラ−トランク：この場合、Ｃｋ内の各ノードへまたは各ノードからのｕのトラフィック量を正確に制限する。

イントラ−ホース：この場合、同一クラスタ内の他のノードに向かうノードｕの出トラフィックの総和と、同一クラスタの他のノードからのノードｕの入りトラフィックの総和のみを制限する。

＜クラスタ間トラフィック＞
再びノードｕがクラスタＣｋにあるとする。このときも、クラスタＣｋの外にあるｕのトラフィックを記述するための代表的な２つの方法を以下のように紹介することができる。

インター−トランク：この場合、ノードｕの他の各クラスタへまたは他の各クラスタからのトラフィック量を制限することが好ましい。これは従来のポイントトゥポイントトランクよりも制限を緩めた記述であることに注意されたい。

インター−ホース：この場合は各ノードに対して、Ｃｋ以外のあらゆるクラスタ（のあらゆるノード）に向かう出トラフィックの総計と、Ｃｋ以外のあらゆるクラスタ（のあらゆるノード）から到来する入りトラフィックの総計に対してのみ制限を加える。

入りトラフィックと出トラフィックの間には一定の関係があるかもしれない。これは、実際には双方向の制限があることを基本的に意味する。

クラスタの集合に基づくサービスレベル規定（例えばＳＬＡ）がどのようにして構成できるかを示すために、ここで図４を参照する。図４は、クラスタに分けられたネットワークの簡単な例を示す。図４は、それぞれ１０．０．１．０、１０．０．２．０、及び、１０．０．３．０と記された３つのクラスタに分割された、代表的なネットワークを示している。正方形はバックボーンルータのようなノードを表わしており、その脇にＩＰアドレスが記されている。下の表は代表的なクラスタ内及びクラスタ間パラメータを併記したもので、（図４では灰色の正方形で示された）ＩＰアドレス１０．０．２．１を有する特定のノードにおいて、サービスレベル規定（例えばＳＬＡ）を記述するのに用いることができる。各々の対象となるノードにおいては同様の記述が行われる。

クラスタに基づくプロビジョニングの利点の一つに、ＳＬＡのようなサービスレベル規定に必要なトラフィック情報を、利用可能なトラフィック情報に合わせられることがある。ノード数Ｎのネットワークでは、入りと出の両方のトラフィックに制限があるとして、規定すべき帯域幅要素の数はノードあたり従来のホースモデルで２、従来のトランクモデルでは２（Ｎ−１）である。両方向に対して記入を１項目にすれば、当然制限の数は半分になる。新しいクラスタに基づくプロビジョニング方法では、帯域幅制限の数は上記２つのモデルによる両極の間のいろいろな値をとる。Ｍ個のクラスタ（Ｎ＞Ｍ＞１）があり、それぞれが同じ大きさ（Ｎ／Ｍ＞１）であるとする。このとき、ノードにおけるクラスタ内トラフィックのトラフィック制限の数はトランクモデルで２（Ｎ／Ｍ−１）、ホースモデルで２となり、クラスタ間トラフィックに対する制限の数は、トランクモデルで２（Ｍ−１）、ホースモデルで２となる。この結果、クラスタ内とクラスタ間のプロビジョニングの４つの組合せに対するトラフィック制限の総数は以下のとおりとなる。

・イントラ−トランク＆インター−トランク：２Ｍ＋２Ｎ／Ｍ−４
・イントラ−ホース＆インター−トランク：２Ｍ
・イントラ−トランク＆インター−ホース：２Ｎ／Ｍ
・イントラ−ホース＆インター−ホース：４

具体的な例としてノード数Ｎ＝９でクラスタ数Ｍ＝３の場合、各クラスタの大きさはＮ／Ｍ＝３ノードで、トラフィック制限の総数は、イントラ−トランク＆インター−トランクのときは８、イントラ−ホース＆インター−トランクのときは６、イントラ−トランク＆インター−ホースのときは６、最後にイントラ−ホース＆インター−ホースのときは4である。

クラスタがＩＰプレフィクスに基づいて識別される場合には、帯域幅制限の設定項目は普通ＩＰアドレスプレフィクスのリストと帯域幅の値を含む。そのような場合には、設定の複雑さは、帯域幅の値だけでなく、ＩＰアドレスプレフィクスの数にも依存する。クラスタが単一のＩＰプレフィクスに対応づけられるときは、クラスタがバラバラのＩＰプレフィクスで規定されるときに比べて設定は明らかに煩雑ではない。

クラスタの規定は、例えば以下に示す規則に従ってもよい。

・クラスタはＩＰアドレスの集合として規定されるのが好ましい。この集合は単一のサブネットもしくはＩＰサブネットの集合であってよい。もちろん、それなりの規定をすれば、ＩＰに基づくネットワークでない他のコネクションレスネットワークが用いられてもよい。

・クラスタの階層が多重に重なってもよい。言いかえれば、ノードは多重クラスタの一部であってもよい。

・通常、資源クラスタはネットワークの単一の部分に対応付けられるように限定されない。資源クラスタは多重ネットワーク部分を含んでよい。大抵の場合、クラスタは近接したノードを含むが、クラスタが分離したネットワーク部分を含むことを除外しない。

・資源は静的にプロビジョニングされることが好ましい。

一般に、クラスタに基づくプロビジョニングは、資源配分及びネットワーク管理のうち少なくとも一方に関係し、承認制御及びリンク容量ディメンショニングのうち少なくとも一方を含むことが好ましい。

クラスタを最適に選択することとそれに対応するディメンショニングは複雑な作業であるため、サポートツールを利用するのが便利である。例えば、クラスタの選択／設定は最適化作業と考えることができよう。ここで、目的関数は次の２つの要素を持つ。すなわち、（ａ）ＣＡＣ項目（エントリ）及びパラメータの数を最小にすること、及び、（ｂ）帯域幅効率を最大にすること、である。別の言い方をすれば、帯域幅効率が所定の値よりも良くなるように、また、ＣＡＣの設定パラメータの数が所定の限定値よりも少なくなるようにクラスタが選択されることが望ましい。ここで、設定パラメータの数が増えると達成稼働率も上がると通常仮定することに注意されたい。また、ＣＡＣ項目（エントリ）及びパラメータの数だけではなく、クラスタの設定におけるサブネットの数が管理の複雑さに影響を与えることに注意されたい。

例えば、設定パラメータの数を最小化して、純粋なトランクプロビジョニングに比べて、得られる過剰プロビジョニングの値が（例えば５０パーセントというような）あるしきい値以下になるようにすることができる。過剰プロビジョニングを最小化する他の方法に、設定パラメータの数を（例えば各ノード４パラメータというように）固定するものがある。

そして、ツールは、クラスタ数、階層レベル、ＣＡＣ項目（エントリ）及びパラメータの数の最大値、及び最大帯域幅効率というようなクラスタ設定への要求条件が規定されたとして、最適化作業を実行するアルゴリズムを含むことが好ましい。

クラスタの選択手順は一つまたは数個の選定基準を考慮してもよい。そのような基準のいくつかの例が以下に示される。：
・トラフィック：
ノード間のトラフィック分布に基づくクラスタ選択。

・ＩＰサブネットアドレス計画：
ＩＰサブネットアドレス計画に基づくクラスタ選択。

・空間配置：
ネットワークの空間配置（トポロジ）に基づくクラスタ選択。

・ＣＡＣ項目（エントリ）数：
ノードにおけるＣＡＣ項目（エントリ）／パラメータの数を最小にするクラスタ選択。

・帯域幅効率：
帯域幅効率を最大にするクラスタ選択。

設計ツールは上記の可能性の任意の組合せをサポートすることが好ましい。

ディメンショニングは、本提案のプロビジョニングモデルによるネットワークをディメンショニングする、オフラインのトラフィックエンジニアリングツールに基づいて行われることが好ましい。上述のように、クラスタ選択手順では、例えば、ＣＡＣ項目／パラメータの数を最小にするというようなよく規定された最適化作業に関して、所定の数のクラスタを求め、それらの間のノードを分割する。別の方法では、ネットワークの空間配置あるいは他の類似の要素に従ってかなり直接的にクラスタが構成される。

ホースモデルの場合には、ディメンショニングは、すべての空間配置情報とルーティングを同時に考慮して最良の帯域幅効率を得るような全体最適化に基づくことが好ましい。ホース及びトランクモデルのいずれにおいても最短経路ルーティングが用いられるであろう。

好ましい実施例においては、ディメンショニングアルゴリズムは、決められたクラスタ間及びクラスタ内トラフィック制限／設定に基づいて必要なリンク容量を計算するが、所要トラフィック量を線形計画法によって最適化するディメンショニングツールで実行されるのが好ましい。

クラスタ内及びクラスタ間プロビジョニングモデルに基づくディメンショニング作業は、必要な容量を計算するために新しいノード−クラスタ間の拘束条件／制限を必要とする。

具体的には、ネットワークディメンショニングは、実際のトラフィック行列の知識を前提にせず、トラフィック行列の付帯的な拘束条件をいくつか仮定するだけで、所定の付帯拘束条件を満たす任意のトラフィックを運ぶネットワークを設計することが目的である。

この付帯拘束条件は、主として事前にトラフィックについて知っていること、もしくは測定できることを表わす。従来のホース及びトランク制限に加えて、所定のクラスタ内のノードと他のクラスタもしくはクラスタの集合にある任意のノードの集合の間のトラフィックもまた制限されることがある。従来と同様に、トラフィックの記述には通常２つの値、すなわち、出と入りのトラフィック用の値、が用いられる。

次に、クラスタに基づく帯域幅確保の方法に必要なリンク容量がどのように計算されるかを簡単に説明する例を示す。提案されたアルゴリズムは、文献[7]の方法を拡張したものである。

ネットワークが方向つきのグラフＧ＝（Ｖ，Ｅ）で表わされるとする。頂点の集合Ｖはネットワークのノードの集合を表わし、実際のリンクは端点の集合Ｅで表わされる。この例ではまた、任意の対になったノード間のルーティングがなされているものとする。これは一般にそれぞれのノードｕとｖの対に対して、経路がｐ_ｕｖであるとすることである。

しかし、ルーティングをさらに一般的な方法で表わすことにする。それぞれのノードｕとｖの対に対して、Ｅ→［０，１］で定義されたフロー関数ｒ_ｕｖを導入する。ここでｒ_ｕｖ（ｅ）はｕとｖの間のトラフィックのうちのリンクｅを通るものを表わす。この方法は、単一経路ルーティングを（ｕ、ｖ間の経路の端点ではｒ_ｕｖ（ｅ）を１、経路の反対側の端点では０とすることで）扱うことができ、また、分割ルーティングも扱うことができる。ルーティングが与えられると、所定のトラフィック行列でリンクの負荷が決定される。ｕからｖへのトラフィック量をｔ_ｕｖとすれば、あるリンクｅのトラフィックは次式で表わされる。

本発明で提案された方法は、実際のトラフィック行列の知識を前提にせず、トラフィック行列の付帯的な拘束条件をいくつか仮定するだけで、付帯的な拘束条件に適合する任意のトラフィック行列を容量が満足するように、ネットワークが好適にディメンショニングされる。本発明は、実際のトラフィックをより正確に記述して不要な過剰ディメンショニングを防ぐために、クラスタに基づく付帯的な拘束条件を採用することが好ましい。

付帯的な拘束条件は以下のように分類される。

「トランクパラメータ」。ここでは、所定のノードｕから別のノードｖへのトラフィックの最大値が分かっている。この最大値をＴ_ｕ→ｖと表わせば、拘束条件は次式で表わすことができる。

「ホースパラメータ」。従来のホーストラフィックの記述では、あるノードｕから出るトラフィックと、そのノードｕに入るトラフィックを、それぞれＴ_ｕ→ｖとＴｖ_→ｕで表わされる値に制限する。これを数式で示せば、

及び、

となる。

「クラスタに基づくパラメータ」。ここでは、ノードｕと任意の（１つ以上のクラスタとみなされる）ノード集合Ｓの間のトラフィックが制限される。前述の場合と同様に、２つの値がトラフィックの記述に用いられる。すなわち、１つは出、他は入りのトラフィックに対するもので、それぞれＴ_ｕ→ｓ及びＴｓ_→ｕで表わされる。数式で示せば、

及び、

である。

上記の拘束条件はすべて線形であるので、これらの拘束条件を用いた最適化問題が効率的に解けることに注意されたい。容量確保の方法はノードのクラスタリングに基づいているので、ノードの集合はクラスタと呼ばれるｋ個の分離した部分集合に分割されることが好ましい。すなわち、Ｖ＝Ｃ_１∪Ｃ_２∪...∪Ｃ_ｋの場合、ｉ≠ｊであれば、Ｃ_ｉ∩Ｃ_ｊ＝０である。

この発想はクラスタ内のトラフィックとクラスタ間のトラフィックとを区別するものである。前に触れたように、それぞれの場合において２つの自然な可能性がある。

＜クラスタ内トラフィック＞
所定のクラスタＣ_ｋとそのクラスタにあるノードｕを考える。このとき、このノードのクラスタ内トラフィックを次の２つの代表的な方法で求めることができる。

イントラ−トランク：この場合、Ｃ_ｋの各ノードからｕへの、もしくは、ｕからＣ_ｋの各ノードへのトラフィック量を、各ｖ∈Ｃ_ｋ，ｕ≠ｖに対してパラメータＴ_ｕ→ｖを用いて制限することが好ましい。

イントラ−ホース：この場合、同一のクラスタにある他のノードに向かうノードｕの出トラフィックの総和と同一のクラスタにある他のノードからノードｕに入るトラフィックの総和のみをパラメータＴ_ｕ→Ｃｋ及びＴ_Ｃｋ→ｕを用いて制限する。

＜クラスタ間トラフィック＞
再び、クラスタＣ_ｋにあるノードｕを考える。ここでも、クラスタＣ_ｋの外にあるｕのトラフィックを記述するために以下のような２つの代表的な方法を導入することができる。

インター−トランク：この場合、ノードｕから他の各クラスタの第１集合へのトラフィック量と、他の各クラスタの第２集合からノードｕへのトラフィック量とを、例えば、各ｊ≠ｋに対し、パラメータＴ_ｕ→Ｃｊ及びＴ_Ｃｊ→ｕを用いて制限する。これは一般に従来のポイントトゥポイントトランクの制限を緩めた記述であることに注意されたい。他のクラスタの第１集合と他のクラスタの第２集合の大きさは、普通は同じであるが、異なっていてもよい。

インター−ホース：この場合、各ノードｕに対して他の任意のクラスタ（の中の任意のノード）へ向かう出トラフィックの総和と、Ｃ_ｋ以外の他の任意のクラスタ（の中の任意のノード）から来る入りトラフィックの総和のみを、パラメータＴ_{ｕ→ｖ＼Ｃｋ}及びＴ_{ｖ＼Ｃｋ→ｕ}を用いて制限する。

インター−トランクの制限は、通常、クラスタに基づくトランクモデルと呼ばれるものに相当し、インター−ホースの制限は、通常、クラスタに基づくホースモデルと呼ばれるものに相当する。

既に述べたように、本発明の目的は、起こり得るいかなる状態のトラフィックに対しても前提条件を満たすようにネットワークをディメンショニングすることである。こうしてそれぞれのリンクを、最悪のシナリオを想定してディメンショニングする。リンクｅのこの最大トラフィックを計算するために、前提条件を満たし、かつ、（数１）のトラフィックの値を最大にするトラフィック行列ｔ_ｕｖが求められなければならない。目的の関数（数１）と拘束条件（数２）、（数３）、及び、（数４）は線形関数なので、（数１）の値はどのような線形計画法、例えば、簡単なソフトウェアパッケージのｌｐ＿ｓｏｌｖｅ[18]など、によっても効率よく最大化される。もちろん、必要な全帯域幅を得るためには、各端点ｅ∈Ｅに対してこの手順を繰返す必要がある。

ｒ_ｕｖ（ｅ）は殆どのｕとｖの対（ペア）に対して０となるので、実際の解くべき線形計画の規模は、対応する経路に端点ｅが含まれないそれぞれの変数ｔ_ｕｖを除くことにより、大幅に減少することに注意されたい。また、残りの変数に影響を与えない拘束条件は除外してよい。

例として、イントラ−トランク＆インター−ホースのトラフィックの記述を用いる場合、線形計画は以下のようになる。

ただし、

これまでルーティングの選択によって、トランクディメンショニングでもホースディメンショニングでも、帯域幅効率にはかなりの差が出ることを示してきた。単なるトランクディメンショニングでは、最適な選択はトラフィックが最小区間経路をたどるときであり、ツリールーティング（すなわち、トラフィックが広がったツリー経由の経路をたどる）はホースディメンショニングの場合に最良の性能を与える。本発明のクラスタに基づくプロビジョニングでは、クラスタリングはネットワークを２レベルに分割するが、これは多レベルルーティングの方法を検討する契機となる。例えば、最短経路のツリールーティングに適用すれば、以下のような付加的なルーティング方法が生成される。

・クラスタ内では最短経路／クラスタ間では最短経路
・クラスタ間では最短経路／クラスタ間ではツリー
・クラスタ内ではツリー／クラスタ間では最短経路
・クラスタ内ではツリー／クラスタ間ではツリー

実験とシミュレーションによって、ルーティングが選択されたプロビジョニング方法に適合されると帯域幅効率が上がることが示されている。従って、明確な経路の計算と設定に関連したルーティングの最適化は、設計ツールの機能ともなり得る。ルーティングの最適化に関する詳細は、後にＶＰＮの分野に関連して述べる。

図５は、本発明の代表的な実施例によるネットワーク設計ツールのブロック図である。代表的なネットワーク設計ツール１００は、対話型の設計ツールもしくはサポートツールであることが好ましく、基本的には、ユーザインタフェース１１０、設定モジュール１２０及び好ましくはディメンショニングモジュール１３０をも含む。設定モジュール１２０は普通、クラスタ選択ユニット１２２、プロビジョニングモデル選択ユニット１２４、サービスレベル規定ユニット１２６、及び、任意選択のルーティング方法選択ユニット１２８を含む。オペレータは入力情報及び項目設定のうち少なくとも一方を、ユーザインタフェース１１０を介して入力することができるが、情報はエッジルータを含むネットワークからも入力することができる。クラスタ選択は例えば上述したような関係する情報に応じてクラスタ選択ユニット１２２によって行われる。（クラスタに基づく）ホースモデル及びトランクモデルのうち少なくとも一方のような適切なプロビジョニングモデルは選択ユニット１２４で設定される。クラスタ間及びクラスタ内のサービスレベル規定は、典型的には、サービスレベル規定ユニット１２６において設定（入力）される。任意選択のルーティング方法選択装置１２８では、選択されたプロビジョニングモデルの帯域幅効率を上げるためにルーティングが調整される。そして設計ツールは、明確な経路の計算と設定に関連した、ルーティングの最適化のための機能を含んでもよい。項目設定とクラスタに基づくサービスレベル規定に基づいて、ディメンショニングモジュール１３０はリンク容量の拘束条件に従うディメンショニングを行うのが好ましい。これは普通、クラスタ間レベルにおいてノード−クラスタ間の１つ以上のトラフィック制限に少なくとも部分的に基づいて、リンクがディメンショニングされることを意味し、また、クラスタ内レベルにおいて補助的な１つ以上のトラフィック制限にも基づいていることが好ましいことを意味する。上述のように、ディメンショニングモジュールは、所要のトラフィック量を線形計画法によって最適化し設定する。設計ツールの機能は普通、ソフトウェアに実装され、ネットワーク管理のコンピュータで実行されるが、設計ツールがハードウェアもしくはファームウェアとして実装されることを妨げる理由はない。

図６は本発明の代表的な実施例における承認制御装置の簡単なブロック図を示したものである。代表的な承認制御装置２００は設定モジュール２１０と承認制御機能２２０を含む。設定モジュールは適切なプロビジョニングモデルを規定する手段２１２とクラスタに基づくサービスレベル規定モジュール２１４を含む。クラスタ規定（定義）は通常、ノードごとに手作業、もしくは相応の遠隔機構で集中的に設定される。承認制御機能はＶＰＮ環境でのＳＬＡのようなサービスレベル規定の構成を反映するものとされる。言い換えれば、承認制御機能は普通、同じトラフィックに対する同じ帯域幅制限に基づいて、リアルタイムトラフィックに関連付けられたサービスレベル規定の一部としての集合を含む、もしくは運用する。承認制御では、新しい接続要求が適当な帯域幅制限を確認して処理され、帯域幅制限の適用に応じて、その接続が受け入れられるか、拒否されるべきかを決定する。ＣＡＣ機能は通常、それぞれの対応する端点ノードまたはエッジルータに配置される。

次に、モバイルコアトランスポートネットワークにおける、いわゆるメディアゲートウェイノードに対しての代表的な実装を参照して、本発明を説明する。しかし、本発明はこれに限定されることなく、固定及び移動ネットワーク、ＶＰＮネットワーク及び他の形のネットワークを含む一般の通信ネットワークに適用可能であることと理解されるべきである。

＜モバイルコアネットワーク環境における代表的な実装＞
特にモバイルコアネットワークに適合させた本発明の代表的な実施例では、トランク、ホース及びＭＢＡＣに基づくものを統合したネットワークプロビジョニングが用いられる。承認制御は以下のように分けられることが好ましい。

・正常状態と単一誤動作状態における承認：これは、クラスタのプロビジョニングによる静的プロビジョニング。

・多重誤動作時における予想外の輻輳：測定されたパケット損失率が設定レベルを超える場合、呼をブロックするためにＭＢＡＣが導入されることが好ましい。

＜クラスタの静的プロビジョニング＞
前に記されたのと同様の方法で、メディアゲートウェイノード（ＭＧＷ）のあるコアネットワークが大規模な空間配置（トポロジ）におけるＭＧＷでの設定パラメータ数を制限するために、クラスタもしくは論理資源領域に分割される。承認制御の設定は、次のフォーマットの記載項目を含むことが好ましい。すなわち、

＜クラスタ規定（定義）＞＜帯域幅制限（複数個の場合もある）＞

ここで、クラスタ規定はＩＰサブネットのリストであってよく、クラスタはＭＧＷの集合として規定される。

＜ネットワークの例＞
説明用のコアトランスポートネットワークにおけるクラスタ規定（定義）として可能なものを図７に示す。２つ以上のレベル、すなわち、対象となるノードとクラスタ、を論理ネットワーク表現に含むことができることを理解すべきである。図７の例では、楕円で示される任意選択のスーパークラスタがある。サイトもまた、クラスタと考えられることに注意されたい。

（サイト６における）ＭＧＷ６での承認制御のための項目（エントリ）として可能な集合は以下のとおりである。

＜クラスタ間−トランク＆クラスタ内−トランクのモデル＞
クラスタ間：
＜クラスタＡ＞＜ＢＷ＞
＜クラスタＢ１＞＜ＢＷ＞
＜クラスタＢ２＞＜ＢＷ＞
クラスタ内：
＜サイトルータ０＞＜ＢＷ＞
＜サイトルータ３＞＜ＢＷ＞
＜サイトルータ１０＞＜ＢＷ＞

この例では、クラスタＣはトランクモデルによってディメンショニングされる。クラスタＡ、Ｂ１、Ｂ２及びＣの間のトラフィックもトランクモデルによってディメンショニングされる。

ホースディメンショニングの帯域幅効率がクラスタＣのトラフィックに対して十分であれば、上のリストは以下で置き換えることができる。

＜クラスタ間−トランク＆クラスタ内−ホースのモデル＞
クラスタ間：
＜クラスタＡ＞＜ＢＷ＞
＜クラスタＢ１＞＜ＢＷ＞
＜クラスタＢ２＞＜ＢＷ＞
クラスタ内：
＜クラスタＣ＞＜ＢＷ＞
他のプロビジョニングモデルの例として以下を含む。

＜クラスタ間−ホース＆クラスタ内−トランクのモデル＞
クラスタ間：
＜クラスタＡ、Ｂ１、Ｂ２＞＜ＢＷ＞（共通の複数のホースパラメータ）
クラスタ内：
＜サイトルータ０＞＜ＢＷ＞
＜サイトルータ３＞＜ＢＷ＞
＜サイトルータ１０＞＜ＢＷ＞
＜クラスタ間−ホース＆クラスタ内−ホースのモデル＞
クラスタ間：
＜クラスタＡ、Ｂ１、Ｂ２＞＜ＢＷ＞
クラスタ内：
＜クラスタＣ＞＜ＢＷ＞
他の多くのクラスタの組合せをＭＧＷにおいて設定することが可能であり、この設定は、リンクにおける異なるディメンショニングを本質的に意味する。

＜ＭＧＷに関する要求条件＞
上のネットワークモデルを用いる場合の基本的な基準は、ＭＧＷの承認制御においてクラスタを区別することである。この区別は、例えばＩＰサブネットアドレスを用いて、もしくは、他の基準に基づいて実行することができる。

コアネットワークのアドレス計画（アドレス方式）は、クラスタ全体に単一のＩＰサブネットを規定することが不可能であるような場合がある。従って、ＭＧＷは単一のＣＡＣ記入項目に対して複数のＩＰサブネットの設定を許容すべきである。

静的承認制御を用いるために、帯域幅制限は各ＣＡＣ記入項目に対して設定されるべきである。

必要があれば、承認制御はＭＧＷで設定されたクラスタに対してパケット脱落の統計と帯域幅制限を考慮することができる。従って、パケット脱落の統計は依然として、ＣＡＣで設定されたクラスタに対する総量であってもよい。測定された損失率が設定された制限よりも少なく、かつ、承認された接続の帯域幅が設定限界を超えないときに限って接続が承認される。

障害許容性の観点から、冗長性の異なる３つの方法が考えられよう。

１．冗長性なし
２．単一のリンク障害
３．単一のノード障害

＜代表的なネットワークにおける結果＞
以下に、トラフィックパラメータが既知の現実的なモバイルコアネットワークの場合に提案されたプロビジョニングモデルの簡単な性能解析が示される。

ＭＧＷの観点から、異なるプロビジョニングモデルとクラスタ数に対してどれだけのＣＡＣ項目／パラメータが設定されるべきかということは非常に重要である。図８にＣＡＣの記入項目の平均個数がクラスタ数の関数として示されている。

図８によれば、３個のクラスタのとき、ＭＧＷあたりのＣＡＣの平均記入項目数が最小になることが分かる。ＣＡＣ記入項目から見れば、最も有利なプロビジョニング方法はイントラ−ホース＆インター−ホースであるが、イントラ−ホース＆インター−トランクも、ネットワークのクラスタ数が２個から４個までのうちはかなり良好である。

図９は提案されたプロビジョニングモデルを容量総計について比較したものである。
所要帯域幅から見ると、イントラ−トランク＆インター−トランクモデルが最良であるが、イントラ−ホース＆インター−トランクモデルも大いに魅力的な結果を出している。容量総計から見ると、過剰プロビジョニング係数の目標が２０％前後のとき、適切なクラスタ数は３であることに注意することが重要である。

図８と図９の結果から、ＣＡＣの記入項目数と帯域幅効率の間のトレードオフを考慮すれば、イントラ−ホース＆インター−トランクモデルが最高の総合特性を出すと結論づけることができよう。

異なるルーティング戦略の影響も検討されてきた。これに関して言えば、後述する最適ルーティングのシミュレーションから理解されるように、イントラ−ホース＆インター−トランクプロビジョニングモデルに、クラスタ内レベルでのツリールーティングとクラスタ間レベルでの最短経路ルーティングを組み合わせることが有利であろう。

リンク及びノードのうち少なくとも一方の故障からの保護も、例えば再ルーティングもしくは、バックアップ経路の使用で行われよう。リンクとノードの保護の影響も検討されてきた。

図１０はイントラ−ホース＆インター−トランクプロビジョニングが用いられる場合であって、保護がない場合と、リンク及びノードの保護がある場合の過剰プロビジョニングを示したものである。

特に仮想プライベートネットワーク（ＶＰＮ）の環境に対する本発明の補完的な説明をこれから行うことにする。

＜ＶＰＮ環境における代表的実装＞
一般に、仮想プライベートネットワーク（ＶＰＮ）は企業ビジネスにおいて重要な役割を果たす。これは、主としてネットワークを運用する際の顧客に対する大きな柔軟性があるからである。限られた資源とネットワーク管理基盤のもとで、顧客にとって魅力のあるシステム商品も開発されている。簡単で柔軟性のある帯域幅管理モデルを顧客に提案することも、ＶＰＮプロバイダの重要な目的であると考えられている。しかし、顧客にとって簡単ということは、オペレータにとってしばしば管理作業の増大とネットワークの利用効率低下を意味する。他方で、ネットワーク効率の低下と管理作業の増大は、運用コストの増大と高価なサービスを生むことになる。

すでに述べたように、ホース及びトランク資源プロビジョニングモデルには、効率的なバックボーン運用と柔軟な帯域幅モデルという相反する問題を解決する２つの例がある。トランクモデルとしても知られる顧客パイプモデルではポイントトゥポイントのトラフィック需要は、ＶＰＮの各サイトの対（ペア）の間で、オペレータが独立にサイトの対の間の帯域幅を確保できるようにしながら規定される。このモデルはＶＰＮプロバイダがネットワークを最善の方法で利用できるようにするもので、ルーティング情報も既知であれば既知のトラフィック行列は正確に必要なリンク容量を決定することができるからである。このモデルの限界となるところは、端点間の通信パターンを見積もることが非常に困難なことである。顧客はサイト間のトラフィック負荷を正確に予測かつ規定できないと思われるので、サービスレベル契約（ＳＬＡ）のためのサイト間のトラフィック行列を完全に記述することは困難である。トラフィック行列を推定することがツールでサポートされている場合でも、トラフィックのバラつきのために適切な帯域幅への要求条件を記述するのは難しい。

顧客パイプモデルの別の欠点は、トランク管理の複雑さである。資源確保にはそれぞれの発ノードにおいて着地ノードに向けた設定が、プロバイダのための監視設定及び顧客のための整形／承認制御設定を含めて必要である。顧客のサイト間に完全メッシュの論理ネットワークが仮定されるとき、設定されるパラメータの総数はＶＰＮにあるノード数の２乗に比例する。従って、大規模ネットワークの場合、設定の複雑さはトランクモデルの大きな欠点になるかもしれない。

ホースモデルはより実際的なやり方をするもので、各ノードでの入りトラフィック量の総和と出トラフィック量の総和を規定するだけでよい。これらのトラフィックパラメータは、プロバイダのネットワークへのリンクの物理的な容量に従うか、或いは、測定に基づいて規定することができる。どちらの方法が用いられるにせよ、トラフィック需要の推定は、顧客パイプモデルに比べてより簡単で正確である。ホースパラメータの設定には、顧客とプロバイダのいずれに対してもトランクの設定よりも手間がかからない。それぞれの発ノードに、入りと出のホースパラメータを各１個設定するだけでよい。こうして、設定パラメータの数はＶＰＮサイトの数に比例する。この性質のために、顧客にとってホースモデルが決定的に魅力的なものとなる。他方で、ホースモデルの導入はＶＰＮバックボーンにおける資源プロビジョニングに多大な影響を与える。所要サービス性能がどちらも同じであるとしたとき、トラフィック需要に関する部分的な情報に基づくネットワークディメンショニングは、トランクモデルに比べて過剰ディメンショニングが多い。さらに、ノード数及びリンク数についてのネットワーク規模の増加につれて必要な過剰プロビジョニングは著しく増大する。

従って、従来の資源プロビジョニング方法は、大規模なＶＰＮネットワークにうまく適合しないと言える。

ネットワークを複数ノードのクラスタに分割し、クラスタに基づくネットワークのプロビジョニングを少なくとも２レベルで行い、クラスタに基づくトラフィック記述を用いることによって、管理の複雑さと過剰プロビジョニングの間の適切なバランスを、既に記したのと同様もしくは類似のやり方で見出すことができる。そのようなプロビジョニング戦略は大規模ネットワークにうまく適合し、単に従来のトランクモデルにおける端点間需要や従来のホースモデルにおける端点から任意の相手への需要を用いる代わりに、クラスタリングをすることによって端点からクラスタへの需要を用いてＶＰＮトラフィックを記述することが可能になる。これらの新しい、いわゆるノード−クラスタ間のトラフィック制限は、主としてクラスタ間レベルに適用され、ＶＰＮネットワークにおける性能改善の鍵となっている。

例えば、ＶＰＮプロバイダと顧客の間に静的サービスレベル契約があるＱｏＳが有効なＶＰＮを考える。ＶＰＮプロバイダは、入りと出のトラフィックをＳＬＡに従って制御する監視機能を持っているのが普通である。ＶＰＮの顧客もまた、ネットワークの端点で同じ目的のために整形機を持ってもよい。さらに顧客は、ＳＬＡで規定されたトラフィック限界を超えることによって生じるＱｏＳの劣化を避けるためのリアルタイムサービスの承認制御機能を作動させるかもしれない。承認制御機能もまたＳＬＡの構成を反映すると想定される。すなわち、リアルタイムトラフィックに関連するＳＬＡの一部として集計された同じトラフィックに対して同じ帯域幅制限を含む。

ＶＰＮアーキテクチャの管理は一般にＶＰＮの顧客とＶＰＮプロバイダに対する作業を含む。ネットワークのトラフィックを測定したり、トラフィックが所定の限界を超えたときにＳＬＡを再交渉したりすることはしばしばＶＰＮ顧客に任されている。ＳＬＡに従って承認制御と整形の設定をすることも普通はＶＰＮの顧客がすることである。一方、ＳＬＡに規定された帯域幅を常にバックボーンで利用可能にすることは通常ＶＰＮプロバイダの責任である。再交渉の場合、プロバイダは増大したトラフィックに対応できるか、あるいは、いずれかのリンクの改善が必要かを調べなければならない。ＳＬＡによる監視機能を設定するかどうかもプロバイダに任されている。

ＶＰＮプロバイダの一番の興味は、顧客に対する作業を簡単なＳＬＡを提示するだけで済ませることである。しかし、トラフィックの記述が不十分であれば過剰プロビジョニングを招き、提示が高価なものになってしまう。従って、ＶＰＮ管理の複雑さとバックボーンにおける過剰プロビジョニングの合理的なバランスが必要になる。

提案されたサービスモデルは、ＶＰＮ環境におけるＳＬＡをサイトクラスタの概念に基づいて、単なるホース及びトランクモデルに比べてより柔軟な方法で設定することができる。クラスタをＶＰＮのサイトまたはノードの集合と規定することによって、ＳＬＡにおけるクラスタ内プロビジョニングとクラスタ間プロビジョニングを区別することができる。これは、ＶＰＮにおける特定の顧客の要求に対してＶＰＮオペレータが特注サービスの提案を可能にするものである。こうして、トラフィックの記述と管理は、ＶＰＮバックボーンの帯域幅効率を大きく変化させることなく簡単にすることができる。

クラスタに基づくプロビジョニングによって影響を受けるこの第１の作業は、トラフィック測定とＳＬＡ再交渉である。ＳＬＡの主題である総量が大きければ大きいほど、ＳＬＡが再交渉されるべきであると判断するのはそれだけ容易である。前に述べたように、クラスタに基づくプロビジョニングの１つの利点は、ＳＬＡでの所要トラフィック情報を、顧客の利用可能なトラフィック情報にあわせて調節できることである。

ＶＰＮの顧客に対して言及される他の作業として、リアルタイムトラフィックに対する承認制御、もしくは、ベストエフォートトラフィックの整形の設定、短く言えば複雑な管理、がある。この観点では、クラスタに基づくプロビジョニングの別の利点は、管理の複雑さに対してスケーラブルなことである。

ＳＬＡの様式は管理の複雑さに大いに影響を与える。クラスタに基づくプロビジョニングのためのＳＬＡは、端点間要素、端点間単一クラスタ要素、及び端点対マルチクラスタ要素を含んでもよい。換言すれば、帯域幅制限はサイトの集合に対して設定されてもよい。ここで、サイトの集合というのは、単一のサイト、クラスタ、あるいは複数のクラスタであってもよい。顧客のところでの整形及び承認制御では、ＩＰプレフィクスに基づいてクラスタを識別することがしばしばであるので、これらの機能のいずれについても、帯域幅制限のための設定記入項目には、ＩＰアドレスのプレフィクスの表と１個以上の帯域幅の値が含まれているのが普通である。こうして、設定の複雑さは帯域幅の値の数だけでなく、既に指摘したようにＩＰアドレスのプレフィクスの数にも依存し得ることが分かる。クラスタが単一のＩＰプレフィクスに対応付けられる場合には、個々に異なるプレフィクスを扱う場合に比べて明らかに設定は煩雑でない。従って、ＶＰＮの起動時にクラスタが既に規定されていれば、アドレス計画にはそれを考慮しておくことが好ましい。

ＶＰＮは、ある種のトンネリング技術を実装しているのが普通で、それも通常はＶＰＮのＩＰアドレッシングがＩＰバックボーンのアドレッシングとは独立であることを仮定している。整形及び承認制御は顧客のところに置かれると仮定されるので、それらはＶＰＮのアドレッシングをベースにすることになる。バックボーンとＶＰＮアドレスが独立であることで、他のＶＰＮとは独立に、実際のＶＰＮに合わせた最適アドレッシング計画を規定することができる。このようにしてクラスタの規定をＶＰＮに局所化することができる。

ＩＰアドレッシングがＶＰＮにおいて確定されると、クラスタ規定ではアドレッシング計画を考慮することが好ましい。例えば、わずかに多めの過剰プロビジョニングがバックボーンに必要になるが、ＩＰアドレスプレフィクスとクラスタの間に１対１の対応づけができることのほうが、いくつかの異なるＩＰプレフィクスを持つ物理的な空間配置に基づいたクラスタ規定よりもよいと思われる。ともあれ、帯域幅効率、計算すべきパラメータの数、及び設定の複雑さの間にトレードオフがあることは明らかである。

ＶＰＮプロバイダの責任について触れなおすことにしよう。監視設定は、顧客のもとでの整形及び承認制御と同程度の管理の複雑さを有するが、ＶＰＮプロバイダは監視設定を行うほかに、バックボーンのリンクが、入りの監視で制限されたトラフィックに対応しきれるかをチェックしなければならない。この点では、クラスタに基づく方法は、いくらかホースプロビジョニングと似ていて、ホースに基づく確保及びクラスタに基づく確保をサポートする資源確保プロトコルが現在存在しないので、この作業を実行するために複雑な計算が必要である。トランクに基づく資源要求に対して、ネットワーク資源をチェックすることは通常簡単である。それは、ルーテッドＩＰ ＶＰＮに対するアグリゲートＲＳＶＰもしくは将来のＮＳＩＳプロトコル及びＭＰＬＳ ＶＰＮ用のＲＳＶＰ−ＴＥのような、すべての資源確保プロトコルがトランク確保をサポートしているからである。以前に述べたように、プロバイダはルーティング最適化作業を管理してもよく、それによって実際に使われるネットワーク資源が最小になる。こうして、ＶＰＮプロバイダは最小帯域幅効率、帯域幅制限の最大数及びＩＰプレフィクスの最大数という要求条件あるいは制限条件のある最適化問題を解決しようとすることが望ましい。好ましくは、上述の基本的なリンク容量アルゴリズムは、クラスタに基づく選択された記述によって与えられたトラフィックに対して所要リンク容量を計算するために、ＶＰＮプロバイダによりネットワーク設計ツールに実装されて輻輳のないネットワークの設計を可能にする。

提案された方法の適用性と制限、及び、異なるルーティング戦略の効果と障害許容性が、ＶＰＮネットワークに対するいくつかのテストケースのシミュレーションによって調べられた。以下に、限られてはいるが解説のためにこれらから選んだシミュレーションについて簡単に記す。

＜性能検討＞
シミュレーションにおいて、ＡＴ＆Ｔの一般用として利用できる空間配置つきの基準バックボーンネットワークが性能解析のベースとして用いられた。４４リンクで結ばれた２５サイトで構成されるテストネットワークを得るために主に考慮したのは、Ｎ ＯＣ４８リンクとＮ ＯＣ１９２リンクに接続されたゲートウェイノード、バックボーンノードからなるネットワークの一部だけである。

最初に、提案されたクラスタに基づくプロビジョニングを、ルーティング最適化及び（障害）保護方法を考慮しないという異なる事例と比較する。次に、ルーティング最適化がどのようにして帯域幅効率を改善するのに用いられるかを検討する。最後に、結果に基づいて、保護方法の効果について言及する。

図１１は、過剰プロビジョニング係数を、異なるディメンショニング方法によるクラスタ数の関数として示したものである。プロビジョニング方法の比較は、ここでは最短経路ルーティングに基づくもので保護方法はないものとしている。必要なリンクの容量と管理の複雑さは方法の性能をあらわす主要な尺度なので、評価にはそれらを計算する。検討したネットワークの構成は、既に述べたように２５ノードのＡＴ＆Ｔネットワークと、あらかじめ計算されたトラフィック行列に基づいている。ディメンショニングは対象となる（１から２５までの）それぞれの番号のクラスタに対して行われた。クラスタに基づくプロビジョニング各方法に対して、今後以下の短い呼称を用いる。

・’ｔｔ’：クラスタ内及びクラスタ間トラフィックにトランクを用いる。

・’ｔｈ’：クラスタ内トラフィックにトランク、クラスタ間トラフィックにホースを用いる。

・’ｈｔ’：クラスタ内トラフィックにホース、クラスタ間トラフィックにトランクを用いる。

・’ｈｈ’：クラスタ内及びクラスタ間トラフィックにホースを用いる。

図１１はトランクモデルと比較した過剰プロビジョニング係数、すなわち、計算したプロビジョニング方法と純粋なトランクモデルとにおける所要容量の差の相対値を示したものである。

図１２は、管理の複雑さと密接な関係がある、サイトあたりの帯域幅制限数の平均値を示したものである。ここで、純粋なホース及びトランクプロビジョニングは表面上は示されてはいないが、その結果はクラスタに基づく方法の特別な場合と同等であるので、図から読み取れることに注意されたい。すなわち、クラスタ数が１のとき、方法’ｈｔ’と’ｈｈ’がホースモデルに相当し、方法’ｔｔ’と’ｔｈ’がトランクモデルに相当する。各サイトが個別のクラスタに属する場合（すなわち、ＡＴ＆Ｔネットワークに２５のクラスタがある場合）には、’ｈｈ’と’ｔｈ’がホースモデルに相当し、’ｔｔ’と’ｈｔ’がトランクモデルに相当する。

リンク容量と管理の複雑さに関して、クラスタに基づく４つの方法のすべてに対する結果は、ホース及びトランクプロビジョニングによる結果の間の値になっている。図はまた帯域幅効率と管理の複雑さのトレードオフを明確に示している。方法を比較するために実際に問題となるのは、目標とする過剰プロビジョニング値を与えるクラスタリングを用いた、必要な管理の複雑さである。管理の複雑さと過剰プロビジョニングを散布図にした図１３は、この観点で方法を比較するものである。図中の点は、それぞれのクラスタ設定における、管理の複雑さと過剰プロビジョニングの値を示している。方法’ｈｔ’は、ＡＴ＆Ｔネットワークにおいてという意味で最良であることが分かる。すなわち、どのような過剰プロビジョニングの値に対しても最小の管理の複雑さが得られている。例えば、バックボーンにおいて、トランクモデルでの要求条件から帯域幅を４０％多くすれば、サイトで必要とされる設定パラメータは２５から５に減少する。ここでホースモデルであれば帯域幅が１６０％も余分に必要で、各サイトで単一パラメータを持つことに注意されたい。

クラスタ内レベルでは、ホースプロビジョニングがトランクプロビジョニングよりも良いという理由は、クラスタ内でのリンク容量がプロビジョニング方法にあまり関係せず、トランクモデルではホースモデルよりもはるかに多い設定パラメータを必要とするからである。容量に僅かな差があるのはクラスタの空間配置がほぼツリー状に近いためで、これはホースモデルが最適になる場合に相当し、例となるＡＴ＆Ｔバックボーンネットワークの空間配置がまばらなことによるものである。

クラスタ間プロビジョニングに関しては、トランクプロビジョニングはホースプロビジョニングよりも明らかに性能が良い。これは異なるクラスタへのトラフィックが通常異なる経路を通るためである。従って、ＳＬＡにおける行先クラスタを無視する（すなわち、クラスタ間トラフィックにホースプロビジョニングを用いる）と、各クラスタに向かう最悪の場合のトラフィックはクラスタ間トラフィックの総和となってしまう。これは、特定の行先クラスタのトラフィックだけを考えるトランクモデルとの違いである。

次に、異なる観点からこのイントラ−ホース＆インター−トランク方法の性能について主に焦点があてられる。

前に述べたように、多レベルルーティングはネットワーク性能を改善するための有望な方法のように思われる。多レベルルーティングの場合、クラスタレベルの構造はノードレベルのアルゴリズムよりも次のような点で優れているのが普通である。すなわち、最短経路ルーティングがクラスタ内及びクラスタ間レベルの両方に用いられるとき、ルーティング経路は一般にクラスタ間リンクとの交差をできるだけなくすように選ばれ、それらの経路の中で全長が最も短くなるものが選ばれる。この原理は他の３つのルーティング方法においても同様に適用される。

これ以後、つぎのような短い呼称をクラスタに基づく各ルーティング方法に対して用いることにする。

・’ｓｓ’：クラスタ内最短経路／クラスタ間最短経路
・’ｓｔ’：クラスタ内最短経路／クラスタ間ツリー
・’ｔｓ’：クラスタ内ツリー／クラスタ間最短経路
・’ｔｔ’：クラスタ内ツリー／クラスタ間ツリー

上に述べた４つのそれぞれのルーティング方法は、リンクに対して適当な管理上の重み付けをした純粋な最短経路ルーティングとして実装されてもよいことに注意されたい。

図１４は、方法’ｈｔ’の過剰プロビジョニング係数を５つのルーティング（単純な最短と上述の４つのルーティング戦略）について求めたものを示している。図１４に基づいて導かれる基本的な結論は、クラスタ間レベルのツリールーティングを用いるのは、最短経路ルーティングを用いるよりも性能が悪くなるということである。クラスタ間ツリーの性能が相対的に悪い理由は、多くのクラスタ間の直接接続ができないようにしたために大きな迂回路ができてしまったことである。クラスタ内レベルでツリーもしくは最短経路ルーティングを用いても大きく変わらないことも分かる。検討されたネットワークが比較的まばらなため、ツリー及び最短経路ルーティングでのルーティング経路は非常に似ている。より密なネットワークでは、クラスタ内レベルのツリールーティングは最短経路ルーティングよりもよい特性を示す。

同様のテストが他の方法に対しても行われ、ルーティングに関しては、ホースディメンショニングが適用されたツリールーティングと、トランクモデルに基づいてディメンショニングされた部分ネットワークでの最短経路ルーティングを用いるのが、最適であることが結果から確かめられた。こうして、クラスタに基づく各方法には以下のような最良のルーティングの形が存在する。

・方法’ｈｈ’に対してルーティング’ｔｔ’
・方法’ｈｔ’に対してルーティング’ｔｓ’
・方法’ｔｈ’に対してルーティング’ｓｔ’
・方法’ｔｔ’に対してルーティング’ｓｓ’

このことで、選択されたプロビジョニング方法に対してルーティングを合わせれば、帯域幅効率のような性能を向上させられるということが確認できた。

また、４つの方法で最良のルーティングがどのような振舞いをするかを調べた。管理の複雑さを、異なるディメンショニング方法で最適ルーティングの場合の過剰プロビジョニングの関数として求めると、状況は各方法に対して最短経路ルーティングを用いた場合と非常に似たものになった。最大の差は、方法’ｈｔ’が全体的に最良であるとは言えないことである。それは、過剰プロビジョニング係数が５０％以上のとき、’ｔｈ’と’ｈｈ’の特定の設定で、同じ過剰プロビジョニングを実現する管理の複雑さが僅かではあるが小さい場合があることが判明したからである。

ルーティング戦略の効率は基となる空間配置の影響を受けていると思われるかもしれない。これを調べるために、ランダムに構成されたネットワークの空間配置に対して提案された方法がテストされた。最初に、ノードとリンクの数がＡＴ＆Ｔネットワークと同じ数のランダムな空間配置が検討された。１０個の異なるランダムグラフの平均リンク容量が、最適ルーティングを選んだ４つの各方法について計算され、ランダムな場合とＡＴ＆Ｔネットワークの場合とで大きな違いがないこと、どの空間配置においても方法’ｈｔ’が明らかに最良の性能を示すことが分かった。

ネットワークのリンク密度の影響も同じノード数（代表例では２５であった）の空間配置について、ノードの平均次数（あるいは、等価的にネットワークのリンク数を変化させて）を変化させて調べられた。１０個の異なるランダムグラフの平均リンク容量が、２．５から７．５まで０．５ステップ刻みの１１の異なる平均ノード次数について計算された。そして、過剰ディメンショニング係数が５０％以下となる管理の複雑さの最小値が求められた。図１５は、方法’ｈｔ’がリンク密度に関係なく最良であるが、その性能はネットワークのリンク数が増えるにつれて悪くなり、方法’ｔｔ’の性能に近づくことを示している。図には方法’ｈｈ’のグラフが示されていないが、これはこの方法はいかなるネットワーク密度においても、目標の５０％の過剰プロビジョニングを達成することができる設定が存在しないからであることに注意されたい。

別の重要な疑問は、プロビジョニング方法がネットワーク規模によってどう変化するかということである。そこで次のステップは、クラスタに基づくプロビジョニング方法の評価である。検討したネットワークは前と同様ランダムに生成された。ルータのインタフェースの数には限度があり、ネットワークは普通似たような能力のルータで構成されるので、ノード数を変化させる場合はノードの平均次数を一定（この場合は４）に保って、そのようなネットワークを比較した。テストの間、１０から５０まで１０刻みの数のノードを含むネットワークを検討した。１０個の異なる空間配置を構成し、それぞれの方法について平均のネットワーク容量を計算した。クラスタに基づくプロビジョニング方法の４つのすべてについて、最良ルーティング戦略のもとで、クラスタ数を可能な範囲の１からノードの数まで調べた。次に、過剰プロビジョニング係数が５０％以下となる設定のうちで最小の管理の複雑さとなるものを探した。図１６はネットワーク全体で設定されるパラメータの数の最小値を示している。

方法’ｈｈ’のグラフがここでもないのは、目標となる５０％の過剰プロビジョニングが大小いずれのネットワークにおいても実現できないことによる。方法’ｈｔ’と方法’ｔｔ’のグラフは直線状で、設定されるパラメータの数がノード数に比例して増加することを表わしており、両者の違いは、方法’ｈｔ’のほうが複雑さが小さい。これに比べて、方法’ｔｈ’はネットワークノード数の増加につれて急激に増大しており、普通はこの方法を大規模なネットワークでは用いるべきではないということを示している。

バックボーンネットワークにおいては、最も重要な要求条件の一つに障害許容性がある。この事実がいくつかのテストの契機になり、従来のディメンショニング方法と提案のクラスタに基づく方法を用いて然るべき障害許容性を持たせるのにどれだけの過剰プロビジョニングが必要かが調べられた。ＶＰＮに用いられるトンネリング技術は異なっていてもよい。保護の方法の主な違いは、バックボーンがルーテッドＩＰネットワークかＭＰＬＳに基づくネットワークかによるものである。

ＶＰＮバックボーンがルーテッドＩＰネットワークの場合、パケットのルートはルーティング表（テーブル）の実際の内容に基づいて決められるのが普通である。リンク障害の結果、影響を受けたルータのルーティング表はルーティングプロトコルによって更新されるであろう。変更されたリンク状態の情報に基づいてすべてのルーティング表が更新されると、パケットは残されたリンクだけを用いた最短経路を経由して送られることになる。このプロセスには数分を要する。これはまた、所定フローの保護経路が障害リンクに依存することを意味する。

ＶＰＮバックボーンがＭＰＬＳネットワークの場合は、ＭＰＬＳの先進的な障害処理方法を使うことができる。ＭＰＬＳにおける保護技術の１つは、予備のラベルスイッチ経路を用いるものである。言い換えれば、対になったサイトのそれぞれの間に、通常主と副の２つのＬＳＰが設定される。すべてのリンクが動作中のとき、主ＬＳＰが通信に使われる。主ＬＳＰの経路中のリンクに障害が起きた場合は、トラフィックの経路は副ＬＳＰに設定しなおされる。主ＬＳＰの経路のどこかが障害のときに副ＬＳＰが使えることを保証するために、この２つのＬＳＰには共通部分があってはならない。ＬＳＰは実際のリンク障害の前に設定されているので、所定フローの保護経路は障害リンクがどこであるかには依存しない。本方法の利点は、復旧時間がＩＰルーティングよりも非常に早いことである。早い経路再設定は、ＭＰＬＳネットワークにおける保護に対する別の可能な方法であり、しばしば予備のＬＳＰと結合して用いられる。障害からの復旧時間は、障害の起きたリンクに接続されたノードの間に局地的な迂回路を設けることによって、予備ＬＳＰに切替えるよりも早くなる。

ルーテッドＩＰネットワーク及び予備ＬＳＰのあるＭＰＬＳにおける保護方法の効果も、単一リンクで保護を共有する場合と単一ノード障害を仮定して調べられた。言い換えれば、どこかのリンクもしくはノードが障害になった（ただし、同時に２つ以上はないとする）場合には、リンクがトラフィック経路の再設定をサポートするように、ネットワークディメンショニングが行われた。リンク障害の場合、ネットワークの空間配置とフローの経路は変化する。ノード障害の場合は、そのノードのリンクのすべてが空間配置から除かれ、そのトラフィックもトラフィック行列からのぞかれる。

保護方法の効果が、ルーテッドネイティブＩＰバックボーンの場合について調べられた。その結果、クラスタに基づくプロビジョニングの４つの方法において、保護の導入のよる相対的な性能変化は見られないことが明らかにされた。方法’ｈｔ’のルーティング戦略の効果に関する結果から、調べた中で最良のルーティング戦略は、バックボーンにおいてクラスタリングと独立に管理上の重み付けがされている場合には、単純な最短経路ルーティングであるといえる。

経路保護の冗長構成がクラスタに基づくプロビジョニングの性能に与える影響も調べられた。クラスタ数の関数としての過剰プロビジョニングについては、保護方法の効率はネイティブＩＰ ＶＰＮとＭＰＬＳに基づくＶＰＮのいずれも似たような値である。クラスタに基づく方法に対して必要とされる過剰プロビジョニングについて、ルーティング戦略の効果も検討され、異なるルーティング戦略を用いても結果に大差がないことがここでも分かった。その理由は、用いられたルーティング戦略はネットワークのリンクに対する管理上の重み付けを決めることしかいないからである。重み付けは、主経路をルーテッドＩＰネットワークの目標経路にするように設定される。これに対して、経路保護はＥｄｍｏｎｄｓのアルゴリズムに基づいて主及び副経路を両経路の合計コストを最小にするように選ばれるので、最短経路と主経路は異なることがある。

要約すれば、クラスタに基づくプロビジョニング方法はＶＰＮプロバイダと顧客間のポイントトゥマルチポイント（クラスタ）のＳＬＡを規定することを可能にする。提案されたディメンショニングアルゴリズムはリンク容量を、好ましくは線形計画法を用いて、計算する。この計算は、ルーティングが事前に知られているとして、ネットワーク端におけるポイントトゥクラスタのトラフィック制限に従う、最悪の場合のトラフィック分布においても、どのリンクも輻輳しないように行われる。輻輳のないネットワーク設計は、ＶＰＮの顧客が輻輳があれば品質劣化が起きるような非適応のリアルタイムサービスをＶＰＮ上で利用できるようにするものである。ディメンショニングアルゴリズムは、ＶＰＮプロバイダにとって、クラスタに基づくＳＬＡとＱｏＳの保証を提供するための明らかに不可欠なツールである。なぜならネットワーク資源が利用可能かを調べることを手作業で行うのは複雑で、ＩＰに基づく資源確保プロトコルでもサポートされていないからである。

検討したネットワーク例に基づいて以下の結論が導かれる。クラスタに基づくプロビジョニングの４方法のうち最良のものは、設定パラメータ数が最小で、同じ過剰プロビジョニング目標値を達成し、ホースのような制限をクラスタ内トラフィック及びトランクのような制限をクラスタ間トラフィックに設けたものである。この方法は、ネットワーク構成、障害保護の有無、ルーティングの最適如何に関わらず、最良の性能を与える。

これはホースモデルとトランクモデルの最良の妥協策であることが示された。検討した２５ノードのネットワークでは、５個のクラスタを用いることによって、ノードあたりの帯域幅制限の数を２４から５に減らし、所要リンク帯域幅をトランクモデルに比べて経路最適化なしで４０％増やすことができた。同じネットワークにおいて、ホースモデルの場合は余分に必要な容量が１６０％である。

経路最適化は、クラスタに基づくプロビジョニングの過剰ディメンショニングをさらに減らし、上の例の５クラスタの場合には、４０％から２５％にすることができた。クラスタ内ホース＆クラスタ間トランクの選択されたモデルに対しては、２レベルルーティング、すなわち、ツリールーティングを各クラスタ内で、最短経路ルーティングをクラスタ間で用いる戦略が最良である。

ルーテッドＩＰネットワークにおける単一障害への許容には、１３５％の余分な容量がトランクモデルに必要である。５個のクラスタを有するクラスタに基づくプロビジョニングでは、全体のリンク容量をさらに３５％（保護なしのトランクに比べて１７０％）増やすことができる。クラスタ規定とは独立で、従ってすべてのＶＰＮに対して通用する、単純な最短経路ルーティングは、一般に最良のルーティング戦略である。

シミュレーションを通じて、ＶＰＮのサイトに対するＩＰアドレスの割当てを伴う、ほぼ最適な経験則によってクラスタは選択されているとする。クラスタ規定とアドレス割当てがこの順で行われるとき、次に各クラスタを単一のＩＰプレフィクスに対応付けることができる。これはＳＬＡのそれぞれの帯域幅制限を単一のＩＰプレフィクスに割り振れることを意味する。しかし、ＶＰＮのＩＰアドレッシングが厳しければ、どのクラスタもＩＰアドレッシングに基づいて規定される必要がある。これは帯域幅効率の増分を減らすことになる。さもなければ、クラスタ規定にＩＰアドレスの表（リスト）が必要になって、管理の複雑さを増すことになる。従って、ＩＰアドレッシングをクラスタに合わせることができればクラスタに基づく方法の利点を十分活かすことができる。

上に述べた実施例は単に例として示されたもので、本発明はそれらに限定されないことを理解すべきである。ここで開示された基本原理に基づく、さらなる修正、変更及び改善は本発明の範囲に含まれる。

＜略語集＞
ATM 非同期トランスファーモード Asynchronous Transfer Mode
BW 帯域幅 Bandwidth
CAC 接続承認制御 Connection Admission Control
CSPF 拘束条件に基づく最短経路優先 Constraint based Shortest Path First
GGSN ゲートウェイGPRSサポートノード Gateway GPRS Support Node
HLR ホームロケーションレジスタ Home Location Register
LSP ラベルスイッチ経路 Label Switched Path
MBAC 測定に基づく接続承認制御Measurement Based Connection Admission Control
MGW メディアゲートウェイ Media Gateway
MPLS 多プロトコルラベルスイッチング Multiple Protocol Label Switching
O&M 運用及び保守 Operation and Maintenance
QoS サービス品質 Quality of Service
RNC 無線ネットワーク制御装置 Radio Network Controller
RTP リアルタイムトランスファープロトコルReal-time Transfer Protocol
SGSN 在圏GPRSサポートノード Serving GPRS Support Node
TIPI トランスポートIPインフラストラクチャ Transport IP Infrastructure
UMTS 汎用移動通信システム Universal Mobile Telecommunications System
VC/VP 仮想回線／仮想経路 Virtual Circuit / Virtual Path
＜参考文献＞
[1] I. Szabo,「ベストエフォートネットワークにおけるＩＰ 電話の呼承認制御について」, Computer Communications, 26 (2003) pp. 304-313.
[2] I.Szabo,「ＩＰ電話をサポートする新しいエンドトゥエンド測定に基づく呼承認制御法の性能評価」, SCS, International Symposium on Performance Evaluation of Computer and Telecommunication Systems, Orlando, Florida, July 2001.
[3] J. A. Fingerhut, S. Suri, J. S. Turner, 「最小コスト非ブロッキング広帯域ネットワークの設計」, Journal of Algorithms, Vol. 24, no. 2, pp. 287-309, August 1997.
[4] N. G. Duffield and P. Goyal and A. Greenberg and P. Mishra and K. K. Ramakrishnan and J. E. Van der Merwe, 「仮想プライベートネットワークにおける資源管理のための柔軟なモデル」, ACM Sigcomm, San Diego, California, USA, August 1999.
[5] A. Kumar and R. Rastogi and A. Silberschatz and B. Yener, 「ホースモデルにおける仮想プライベートネットワークのプロビジョニングアルゴリズム」, ACM Sigcomm, Cambridge, Massachusetts, USA, August 2001
[6] G. Italiano and R. Rastogi and B. Yener, 「ホースモデルにおける仮想プライベートネットワークの修復アルゴリズム」, IEEE Infocom, New York, USA, June 2002.
[7] AlparJuttner,Istv nSzabo, and Aron Szentesi. 「仮想プライベートネットワークにおけるホース資源管理モデルの帯域幅効率について」, IEEE Infocom, April 2003.
[8] M. Minoux, 「ネットワーク合成及び最適ネットワーク設計問題：モデル、解決方法及び応用」, Networks, vol. 13, pp. 313-360, 1989.
[9] M.Piro, A.Juttner, J. Harmatos,A. Szentesi, P. Gajowniczek, and A. Myslek,「通信ネットワークの空間配置設計： 需要拘束条件下でのノード及びリンクの局所設定」, in17th International Teletraffic Congress, Salvador de Bahia, September 2001.
[10] M.Piro, A. Myslek, A. Jiittner, J. Harmatos, and A. Szentesi, 「MPLS ネットワークの空間配置設計」, in Global Communication Conference (GLOBECOM 2001), San Antonio, Texas, USA, November 2001.
[11] M. Piro and P. Gajowniczek, 「配分シミュレーションによる多物資総フロー問題の解法」, Telecommunication Systems, vol. 1, no.13, pp. 17 28,1997.
[12] T. Cinkler, T. Henk, and G. Gordos, 「単一障害から保護された効率的ネットワーク設計のための統計アルゴリズム」, DRCN 2000,2000.
[13] M. Maliosz and T. Cinkler, 「多ファイバ波長ルーティングネットワークにおける最適ＶＰＮ設計手法」, in Proc. ONDM, Budapest, Hungary, February 2003.
[14] M. Maliosz and T. Cinkler,「仮想プライベートネットワークの設定の最適化について」, in Proc. Polish-Czech-Hungarian Workshop, September 2001, pp.241 247.
[15] T. Cinkler and M. Maliosz, 「Configuration of Protected Virtual Private
保護された仮想プライベートネットワークの設定について」, in Proc. Third International Workshop on DESIGN OF RELIABLE COMMUNICATION NETWORKS, October 2001.
[16] K. G. Ramakrishnan, D. Mitra, and J. A.Morrison,「VPN DESIGNER：マルチサービス仮想プライベートネットワークのための設計ツール」, in Proc. 8th
International Telecom. Network Planning Symp, NETWORKS 98, Sorrento,
Italy, 1998, pp. 153-158.
[17] Chen-Nee Chuah, 「ＩＰネットワーク資源プロビジョニングのための集約かつ階層的な制御によるスケーラブルな枠組み」, University of California, Berkeley, 2001.
[18] M. Berkelaar and J. Dirks,「lpsolve 4.0」、ＦＴＰサーバ ftp://ftp. es. ele. tue. nl/pub/lp~solve.に発表予定。

従来のトランクモデルを示した概略図である。 従来のホースモデルを示した概略図である。 本発明の実施例による代表的なプロビジョニングの方法のフローチャートを示した図である。 クラスタに分割されたネットワークの単純な例を示した概略図である。 本発明の代表的な実施例によるネットワーク設計ツールのブロック図を示した図である。 本発明の代表的な実施形態に係る承認制御装置の簡単な概略ブロック図である。 例示的なコアトランスポートネットワークのための代表的なクラスタ定義を示す図である。 代表的なネットワークに対するクラスタの数の関数として平均的なＣＡＣの項目数を示した図である。 代表的なネットワークの合計容量に基づいて提案されたプロビジョニングモデルに関する比較を示した図である。 イントラ−ホース＆インター−トランクのプロビジョニングが用いられた場合について、代表的なネットワークにおける過剰プロビジョニングを、保護なしの場合と、リンク保護及びノード保護あり場合の各々について示した図である。 大規模バックボーン参照ネットワークに対して、異なるディメンショニング方法の変形例を適用した場合の、クラスタの数の関数として過剰プロビジョニング係数を示した図である。 大規模バックボーン参照ネットワークに対して、異なるディメンショニング方法の変形例を適用した場合の、管理の複雑さをクラスタ数の関数として示した図である。 大規模バックボーン参照ネットワークに対して、異なるディメンショニング方法の変形例を適用した場合の、管理の複雑さを過剰プロビジョニング係数の関数として示した図である。 大規模バックボーン参照ネットワークに対して、イントラ−ホース＆インター−トランクモデルを適用し、さらに、異なるルーティング戦略を適用した場合の、過剰プロビジョニング係数をクラスタ数の関数として示した図である。 異なるディメンショニング方法を適用した場合の、最低限達成可能な管理の複雑さをリンク密度（深度）の関数として示した図である。 最低限達成可能な管理の複雑さを、異なった規模のネットワークについて示した図である。

Claims (15)

1. ネットワークノードの集合を含む通信ネットワークのためのプロビジョニングの方法であって、
   多数の前記ネットワークノードを、各々が少なくとも２つのノードを含むクラスタに分割するステップと、
   クラスタ内レベル及びクラスタ間レベルを含む少なくとも２つのレベルにおいて、クラスタ間のトラフィックのためのノード−クラスタ間の少なくとも１つのトラフィック制限を含む、トラフィック制限を規定するステップと、
   前記トラフィック制限に基づき、クラスタに基づくプロビジョニングを実行するステップと、
   前記クラスタ内レベルにおいて、トラフィックのプロビジョニングモデルを選択するステップと、
   を備え、
   前記クラスタに基づくプロビジョニングを実行するステップは、前記クラスタ間レベルにおいて、前記ノード−クラスタ間の少なくとも１つのトラフィック制限に関連する、クラスタに基づくトランクモデル及びクラスタに基づくホースモデルのうちの一方を適用するステップを備える
   ことを特徴とする方法。
2. 前記クラスタに基づくプロビジョニングを実行するステップは、前記クラスタ内レベルにおいて、補助的な少なくとも１つのトラフィック制限に関連する、トランクモデル及びホースモデルのうちの少なくとも一方を適用するステップをさらに備えることを特徴とする請求項１に記載の方法。
3. 前記ノード−クラスタ間の少なくとも１つのトラフィック制限は、所定のクラスタにおける少なくとも１つの所定のクラスタに対し、少なくとも１つの他のクラスタに関するトラフィックの量を制限するように規定されることを特徴とする請求項１に記載の方法。
4. クラスタに基づくトランクモデルが前記クラスタ間レベルに適用されており、
   前記ノード−クラスタ間の少なくとも１つの制限は、
   所定のクラスタにおける所定のノードに対し、他のクラスタの第１の集合それぞれへのトラフィックの量を制限するように規定された制限の第１の集合と、
   前記所定のクラスタにおける前記所定のノードに対し、他のクラスタの第２の集合それぞれからのトラフィックの量を制限するように規定された制限の第２の集合と、
   を含むことを特徴とする請求項３に記載の方法。
5. 前記クラスタに基づくプロビジョニングは、クラスタに基づく承認制御を含むことを特徴とする請求項１に記載の方法。
6. 前記クラスタに基づくプロビジョニングは、クラスタに基づくディメンショニングを含むことを特徴とする請求項１に記載の方法。
7. トラフィックのプロビジョニングモデルを選択する前記ステップは、前記クラスタ内レベルにおいて、各々のクラスタのために個々に選択するステップをさらに備えることを特徴とする請求項１に記載の方法。
8. クラスタ内ルーティング及びクラスタ間ルーティングを含む少なくとも２つのレベルにおいて、クラスタに基づくルーティングを実行するステップをさらに備え、
   前記クラスタに基づくプロビジョニングを実行するステップは、
   前記クラスタ間レベルにおいて、クラスタに基づくトランクモデルを適用するステップと、
   前記クラスタ内レベルにおいて、ホースモデルを適用するステップと、
   を備え、
   前記クラスタに基づくルーティングを実行するステップは、
   前記クラスタ間レベルにおいて、最短経路ルーティングを適用するステップと、
   前記クラスタ内レベルにおいて、ツリールーティングを適用するステップと、
   を備えることを特徴とする請求項１に記載の方法。
9. 前記多数の前記ネットワークノードをクラスタに分割するステップは、以下に列挙するもののうちの少なくとも１つに基づいて前記クラスタを定義するステップを備えることを特徴とする請求項１に記載の方法。
   ・ノード間のトラフィックの分散
   ・サブネットアドレスプランニング
   ・ネットワークトポロジ
   ・ノードにおける承認制御パラメータの数を最小限にすること
   ・帯域幅の効率を最大限にすること
10. リンクによって相互に接続されているネットワークノードの集合を含む通信ネットワークのためのプログラムであって、当該プログラムはコンピュータを、
    多数の前記ネットワークノードを、各々が少なくとも２つのノードを含むクラスタに論理的に分割する手段と、
    クラスタ内のトラフィックのための少なくとも１つの制限とクラスタ間のトラフィックのためのノード−クラスタ間の少なくとも１つの制限とを含む、クラスタに基づくサービスレベルの規定を規定する手段と、
    前記クラスタに基づくサービスレベルの規定における前記トラフィック制限に基づいて多数の前記リンクの容量をディメンショニングする手段と、
    前記サービスレベルの規定において対応するトラフィック制限と共に使用するために、（ａ）クラスタ間のトラフィックの記述のためにクラスタに基づくトランクモデル及びクラスタに基づくホースモデルのうちの一方を選択し、かつ、（ｂ）クラスタ内のトラフィックの記述のためにトランクモデル及びホースモデルのうちの一方を選択する手段と、
    して機能させることを特徴とするプログラム。
11. 前記ディメンショニングする手段は、前記トラフィック制限によって規定される制約に従って、前記リンクのトラフィックの量の最大値を計算する手段を備えることを特徴とする請求項１０に記載のプログラム。
12. 前記多数の前記ネットワークノードをクラスタに分割する手段は、承認制御パラメータの数を最小限にすること及び帯域幅の効率を最大限にすることの間の所定の重み付けに基づいて前記クラスタを選択する手段を備えることを特徴とする請求項１０に記載のプログラム。
13. 前記プログラムは、前記コンピュータを、前記選択されたトラフィックの記述モデルに従ってルーティング方式を選択する手段として更に機能させ、
    前記ルーティング方式を選択する手段は、（ａ）前記クラスタ内レベルにおいて最短経路ルーティング及びツリールーティングのうちの一方を選択し、かつ、（ｂ）前記クラスタ間レベルにおいて最短経路ルーティング及びツリールーティングのうちの一方を選択する手段を備える
    ことを特徴とする請求項１０に記載のプログラム。
14. 多数のネットワークノードがクラスタに論理的に分割されていて各々のクラスタが少なくとも２つのノードを含む、リンクによって相互に接続されている前記ネットワークノードの集合を含む通信ネットワークにおいて動作する承認制御装置であって、
    クラスタ内のトラフィックのための少なくとも１つの制限とクラスタ間のトラフィックのためのノード−クラスタ間の少なくとも１つの制限とを含む、クラスタに基づくサービスレベルの規定を規定する手段と、
    クラスタ内の承認制御及びクラスタ間の承認制御を含む少なくとも２つのレベルにおいて、前記クラスタに基づくサービスレベルの規定における前記トラフィック制限に基づき、クラスタに基づく承認制御を実行する手段と、
    を備え、
    前記クラスタに基づく承認制御を実行する手段は、前記クラスタ間の承認制御のレベルにおいて、クラスタに基づくトランクモデル及びクラスタに基づくホースモデルのうちの一方に従って動作可能に構成され、
    前記クラスタに基づく承認制御を実行する手段は、前記クラスタ内の承認制御のレベルにおいて、トランクモデル及びホースモデルのうちの一方を適用するように構成される
    ことを特徴とする承認制御装置。
15. 前記クラスタに基づく承認制御を実行する手段は、
    前記クラスタ間の承認制御のための前記ノード−クラスタ間の少なくとも１つの制限に関連する、クラスタに基づくトランクモデルと、
    前記クラスタ内の承認制御のための前記クラスタ内のトラフィックの少なくとも１つの制限に関連する、ホースモデルと、
    を適用するように構成されることを特徴とする請求項１４に記載の承認制御装置。

Images