【文献】
Arjun Singh, et al.,Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's Datacenter Network,SIGCOMM '15 August17-21,2015,London,United Kingdom,米国,2015年 8月17日,p.183-197,URL,https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/43837.pdf
【文献】
Yangyang Li, et al.,Application Utility-Based Bandwidth Allocation Scheme for Data Center Networks ,Parallel and Distributed Computing, Applications and Technologies (PDCAT), 2012 13th International Conference on ,2013年 9月14日,p.268-273
(58)【調査した分野】(Int.Cl.,DB名)
相互に通信する複数のファブリックブロックと各ファブリックブロック内の1つ以上のミドルブロックとを有するコンピュータネットワーク内のトラフィック工学の方法であって、前記方法は、
1つ以上のプロセッサによって、前記複数のファブリックブロックの中からソースファブリックブロックFBsを識別するステップと、
ラウンドロビン順序で、前記複数のファブリックブロックの各宛先ファブリックブロックを評価するステップと、
前記1つ以上のプロセッサによって、ラウンドロビン順序で、選択された宛先ファブリックブロックFBd内の1つの宛先ミドルブロックMBdを選ぶステップと、
前記1つ以上のプロセッサによって、ラウンドロビン順序で、ソースファブリックブロックFBsを選択するステップと、
前記1つ以上のプロセッサによって、前記ソースファブリックブロックFBs内のすべてのミドルブロックの中からソースミドルブロックのサブセットMを識別するステップとを含み、前記ソースミドルブロックのサブセットは、前記宛先ミドルブロックMBdまでの利用できる経路長が最短であると識別されたものであり、
前記1つ以上のプロセッサによって、以下の条件
min(demand(MBs, FBd), spf_capacity(MBs, MBd))
を最大にする前記サブセットM内のソースミドルブロックMBsのうちの1つのソースミドルブロックMBsを、ネットワーク経路で使用するために選択するステップを含み、前記条件において、spf_capacity(MBs, MBd)は、前記ソースミドルブロックMBsと前記宛先ミドルブロックMBdの間の最短経路容量を表わし、demand(MBs, FBd)は、前記ソースミドルブロックMBsと前記宛先ファブリックブロックFBdの間の要求を表わす、方法。
前記条件を最大にするソースミドルブロックと宛先ミドルブロックの選択を繰返すことによって帯域幅割当てを容易にするルート計算グラフを生成するステップをさらに含む、請求項1に記載の方法。
ソースファブリックブロックごとに、宛先ファブリックブロックへの要求を、前記宛先ファブリックブロック内の故障がない各ミドルブロック間で等しく分割するステップをさらに含む、請求項1または2に記載の方法。
前記1つ以上のプロセッサはさらに、前記条件を最大にするソースミドルブロックと宛先ミドルブロックの選択を繰返すことによって帯域幅割当てを容易にするルート計算グラフを生成するように構成される、請求項10に記載のシステム。
前記1つ以上のプロセッサはさらに、ソースファブリックブロックごとに、宛先ファブリックブロックへの要求を、前記宛先ファブリックブロック内の故障がない各ミドルブロック間で等しく分割するように構成される、請求項10または11に記載のシステム。
前記方法は、前記条件を最大にするソースミドルブロックと宛先ミドルブロックの選択を繰返すことによって帯域幅割当てを容易にするルート計算グラフを生成するステップをさらに含む、請求項19に記載のプログラム。
【発明を実施するための形態】
【0012】
詳細な説明
本開示の局面、特徴、および利点は、以下の実施形態の説明および添付の図面を参照しながら検討されたときに理解されるであろう。異なる図面における同一の参照番号は、同一のまたは同様の要素を示す場合がある。さらに、以下の説明は限定的なものではなく、本技術の範囲は、以下の請求項とその均等物によって定められる。代表的な実施形態に従う特定のプロセスが、線図として表現されている図面に示されているが、これは、本明細書で明記されていない限り、必要条件ではない。異なるプロセスは、異なる順序でまたは同時に実行されてもよい。ステップは、特に記載されていない限り、追加されるまたは削除される場合もある。
【0013】
本明細書に記載の技術は、直接接続トポロジを採用したネットワークを含むデータセンターネットワークに対し、トラフィック工学の解決策を示す。上記のように、大規模データセンターネットワークは、コストと帯域幅の兼ね合いが取れた多段のスイッチを含み得る。この技術のある局面では、複数の最適化目標を有しさまざまな割当て戦略を用いて効率的なデータルーティングを提供する、公平性関数(fairness function)が採用される。
【0014】
多くのネットワーク割当てアルゴリズムは、公平さとサービスのクラスを考慮する。しかしながら、スーパースイッチのネットワークでは、低レベルの物理スイッチング要素で構成されたグラフを検討する代わりに、スイッチングの抽象性を活用することが可能である。この手法は、より一層小さなグラフを作成し、結果的に割当てのスピードアップにつながる。加えて、帯域幅割当ての解決策は、本明細書に記載のように、ネットワーク内のさまざまなフロー全体のマクシミン公平性(max-min fairness)のような単純な公平性の概念を考慮する場合があるが、スイッチをグループ化することにより、スーパーブロックのさまざまなミドルブロックを通るトラフィック全体の公平性のような新たな公平性の要件が生まれる。その他の制約は、スイッチ内のトンネルエントリの数に制限があることに由来する。
【0015】
以下で詳細に説明する特定の局面に従うと、公平性関数は、複数の最適化目標を含む。このような目標は、重要性が低くなる順に考慮されてもよく、
1.サービスのクラスの維持、
2.マクシミン公平性、
3.スーパーブロック内のマクシミン公平性、
4.経路距離の最短化、
5.経路の総数の最小化、および
6.所与の要求を満たすのに必要な経路の数の最小化
を含み得る。
【0016】
第1の目標について、サービスのクラスは、優先グループにグループ分けしてもよい。厳密な優先度が、さまざまな優先グループ全体に適用され、各優先グループ内で公平性が重み付けされる。サービスのクラスの、優先グループへの分割、および、サービスのさまざまなクラスの重みは、全体のプロセスに対する入力として与えられる。
【0017】
この技術の局面は、ミドルブロックからグラフを構成することを含み、満たすことができる要求がなくなったときに限り、選ばれたミドルブロックをスイッチングチップに分解する。そうすることによって異なる抽象レベルのスイッチのグラフが作成される。ソースと宛先の間にkディスジョイント(disjoint)最短経路を常に作る解決策とは異なり、経路はオンデマンドで決定される。このような手法には主な利点が2つある。第1に、不必要な経路は作成されない。第2に、実際に必要なときに利用できない経路は計算されない。たとえば、このプロセスが、第1のソース(src1)から第1の宛先(dst1)までの10の経路を予め計算している場合、これらの経路は、第2のソース(src2)から第2の宛先(dst2)までの経路と、リンクを共有する場合がある。よって、これらを十分に用いてsrc1からdst1への要求を割当てることに固執した場合、公平性が損なわれるかもしれない。代わりに、ある局面に従う反復手法が採用される。
【0018】
一例として、いくつかの要求を割当てようとする場合、最初にすべてのノード対間の最小長さのすべての(必ずしもディスジョイントではない)経路を計算する(上記k最短経路wと異なり、最小長さの経路のみが計算され、したがって、このステップで作られたすべての経路の経路長が等しい)。このプロセスは次に、最適化目標を満たす多段注水手順を用いる。ソースから宛先までの最小長さのすべての経路が使い果たされたときに初めて、使用可能な帯域幅の容量を有する、ソースと宛先の間の次の最短経路が計算される。
【0019】
このプロセスは、ノードおよびリンクの故障時に、割当てをインクリメンタルに調整し、必要最小限の割当て変更のみを実施するように構成されている。ソースと宛先の間の要求を満たすことができない場合は、分解技術を用いてミドルブロックをネットワークグラフ内のスイッチングチップに置換える。その後このプロセスは残りの要求を割当てようと試みる。
【0020】
これは、トラフィックのバランスを取ること、チップテーブルエントリを最小にすること等の、現実の生産ニーズを取込むロバストな最適化関数を提供するという点において、好都合である。グラフを繰返し分解することによって、スーパークラスタで使用されているスイッチング要素の抽象性を活用する。採用されている技術は、要求変更、故障に合わせて、サービスパラメータの品質を考慮する。
【0021】
図1は、代表的な多段データセンターネットワーク100を示す。ネットワーク100は、複数のファブリックブロック102を含み、これらの複数のファブリックブロックは、一点鎖線で表わされたリンク104を介して直接接続されて示されている。実際、リンク104は光ファイバリンクであってもよい。この例において、各ファブリックブロック102は、複数のトップオブラックスイッチ1081〜108Nを相互に接続する複数のミドルブロック1061〜106Nを含む2段ネットワークを備えている。
【0022】
各ミドルブロック106は、2段のスイッチ、すなわち第1段110(S2)と第2段112(S3)とを含み得る。各ミドルブロックの2段ネットワークのS2およびS3スイッチは、Clos配置で相互接続されていてもよい。ファブリックブロック102間の接続と同様に、ミドルブロック106およびTORスイッチ108は、リンク114を介して直接接続されている。このリンクも光ファイバリンクであってもよい。
【0023】
図2に示されるように、各スイッチ200は、1つ以上のプロセッサ202、たとえばCPUおよび/またはASICを含み得る。スイッチ200はまた、命令206およびデータ208を格納するメモリ204を含む。ポート210を介した複数の接続によって、データセンターネットワーク内の他のスイッチ間の通信リンクが提供される。
【0024】
このような多段データセンターネットワークのためのトラフィック工学は、従来のISPネットワークでは生じないさまざまな課題に取り組む必要がある。たとえば、トラフィック工学は、従来のISPネットワークよりも桁違いに大きいデータセンターネットワークのためのルートを効率的に計算するのに見合ったものでなければならず、また、故障時のルート収束時間を最小にしなければならない。加えて、データセンターネットワーク内のトポロジの不均一性に対処し、ブロック内リンク上でもブロック間リンク上でも終端間のトラフィックの流れの輻輳を低減しなければならない。さらに、トラフィック工学は、ネットワークスイッチ内の限られたフォワーディング(forwarding)テーブルエントリを考慮する必要もある。
【0025】
このような課題に対処するために、トラフィック工学の解決策のある局面では、入力としてさまざまな情報を用いて、一組の終端間経路を通るブロック間トラフィックに対する帯域幅割当てを決定する。この入力情報は、ブロック間トポロジ、所与のサービスクラス(class of service)(「CoS」)について一対のソースファブリックブロックと宛先ファブリックブロックとの間の所望の総スループットを示す一組のトラフィック要求、異なるCoS間のスケジューリングポリシー(たとえば優先グループ化)、および、トランジットブロック間トラフィックを扱うミドルブロックの容量のうちの、いくつかまたはすべてを考慮している。
【0026】
そのために、多数の最適化目標が考慮される。ある目標は、異なるソースファブリックブロックと宛先ファブリックブロックとの間のトラフィック要求間の公平性である。別の目標は、ブロック間トラフィックのホップカウントを最小にすることによってレイテンシを減じることである。他の目標は、ブロック間トラフィックの経路数を最小にすることによってフォワーディングテーブルエントリの数を減じることである。さらに他の目標は、ブロック間リンクおよびブロック内リンク上の輻輳を最小にすることである。もう1つの目標は、トラフィック工学プロセスの実行時速度を最小にすることである。さらに他の目標は、故障が発生した場合のルート収束時間を最小にすることである。さらに他の目標は、サービス品質を考慮することである。これらの目標は、以下で詳細に述べるようにして達成される。
【0027】
本明細書に記載の帯域幅割当てのある局面では、「注水」技術を取入れることにより、同じペースで異なるソース−宛先ファブリックブロック対のトラフィック要求に対する帯域幅割当てを増す。帯域幅割当ては、完全に満たされたトラフィック要求についてはフリーズし、まだ満たされていない要求については増し続ける。これは、一例では、最短経路を先ず優先することによってホップカウントを減じしたがってブロック間トラフィックのレイテンシを減じることによって、行なわれる。
【0028】
図3および
図4に関連して示されているように、各ファブリックブロック内のスイッチはClosトポロジで相互に接続されているが、それでもなお輻輳は発生し得る。
図3は代表的なネットワーク300を示し、その3つのファブリックブロック302はたとえば光配線(図示せず)によって接続されている。ファブリックブロックBのミドルブロック306とTORスイッチ308が相互に接続されており、各ミドルブロック306のS2スイッチ310とS3スイッチも相互に接続されている。これは
図1に関連して先に述べた通りである。
【0029】
この例において、各ミドルブロック306は、コスト削減のために2段のみを含み得るClosネットワークである。ブロック内トラフィック314は実線で示され、ブロック間トラフィック316は点線で示されている。輻輳318は、ファブリックブロックB内のこのようなミドルブロックが、ブロック内トラフィックと、ファブリックブロックCを宛先とするファブリックブロックAからのトランジットブロック間トラフィック双方を扱っている場合に、起こり得る。
【0030】
図4は、ファブリックブロックAとDの間の最短経路の利用を最大にするためのネイティブな帯域幅割当て方式の代表的なシナリオ400を示す。ここで、ファブリックブロック402間のブロック間通信は40ギガビット/秒(40G)で発生するのに対し、ブロック内通信は10ギガビット/秒(10G)の速度で発生する。ミドルブロック406を経由したTORスイッチ408からファブリックブロックDへのブロック間トラフィックの最大速度が20ギガビット/秒(20G)の場合、結果として、速度が超過したときにアップリンク上で輻輳418が発生する。
【0031】
ミドルブロック間エッジにおける輻輳を最小にするために、トラフィック工学プロセスのある局面は、経路の容量を、(a)ボトルネックブロック間リンクの容量と(b)輻輳なしでトランジットブロック間トラフィックを扱うためのボトルネックミドルブロックの容量との間の最小容量として決定する。各ミドルブロックエッジ接続は、1つ以上の物理通信リンクを含み得る。
【0032】
TORアップリンク上の輻輳を最小にするために、トラフィック工学プロセスは、以下で説明する戦略を用いることにより、ブロック間およびブロック内「マクシミン」公平性を保証する。このプロセスを示すフロー
図450が
図4Aに示される。
【0033】
先ず、ブロック452に示されるように、このプロセスは、ファブリックブロックごとに、宛先ファブリックブロックへの帯域幅要求を、このファブリックブロックのミドルブロック間で等しく分割する。次に、このプロセスは下記のヒューリスティックな注水戦略を用いて、同じペースで異なるソース/宛先ファブリックブロックへの帯域幅割当てを増し、加えて、以下のように、ラウンドロビン方式で、ソースまたは宛先ファブリックブロック内の異なるミドルブロックに対してブロック間経路帯域幅を等しく割当てる。
【0034】
ブロック454に示されるように、宛先ファブリックブロックFB
dを、ラウンドロビン方式で考慮する。ブロック456に示されるように、ファブリックブロックFB
dを考慮するたびに、ラウンドロビン方式で選ばれた、FB
d内の1つの宛先ミドルブロックMB
dに注目する。ブロック458に示されるように、ソースファブリックブロックFB
sをラウンドロビン方式で選択する。
【0035】
ブロック460に示されるように、ソースファブリックブロックFB
s内のミドルブロックの中から、利用できる、宛先ミドルブロックMB
dへの経路長が、最短である、サブセットMを発見する。ここで、ブロック462に示されるように、サブセットM内のミドルブロックの中から、
min(demand(MB
s, FB
d), spf_capacity(MB
s, MB
d))
を最大にするミドルブロックを選択する。ここで、spf_capacity(MB
s, MB
d)は、ソースミドルブロックMB
sと前記宛先ミドルブロックMB
dの間の最短経路容量(shortest path capacity)を表わし、demand(MB
s, FB
d)は、ソースミドルブロックMB
sと宛先ファブリックブロックFB
dの間の要求(demand)を表わす。
【0036】
このシナリオにおいて、スケーラビリティと経路数の最小化のために、トラフィック工学プロセスは先ず、各ミドルブロックを単一ノードとしてスケールアウトし、すべてのミドルブロックレベル経路を計算する。このプロセスは、すべての要求をこのような経路によって満たすことができた場合に終了し、
図5および
図6に示される各ミドルブロックレベル経路に対する「トンネル」をセットアップする。
【0037】
図5は、ソースミドルブロック502と、宛先ミドルブロック504と、トランジットミドルブロック506とを備えた配置500を示す。ミドルブロックは各々、上記のようにClos配置で相互に接続されたS2スイッチとS3スイッチの2段のネットワークを有し得る。
図6の例600は、トランジットミドルブロック606の2段スイッチネットワークを経由したソースミドルブロック602と宛先ミドルブロック604の間の代表的なミドルブロックレベル経路を示す。ここで、破線は異なるスイッチ間のエッジを示す。この配置は、トラフィック工学プロセスの実行時間を最短にし、典型的には何百ものトンネルだけで、スイッチ上でプログラムされるトンネルテーブルエントリを最小にするのに役立つ。
【0038】
満たされた要求がすべての要求ではない場合、トラフィック工学プロセスは引続き、ミドルブロック内でのバウンス(bouncing)を必要としない、残りのブロック間帯域幅を識別する。本開示のある局面に従うと、ある手法は、
図7A〜
図7Bに繰返し示されている、抽象レベルを下げたグラフを構築する。
図7Aは、ソースミドルブロック702と、宛先ミドルブロック704と、2つのトランジットミドルブロック706および708とを有するルート計算グラフ700を示す。ここで示されているように、トランジットミドルブロック706(MB1)はすでにS3チップに分解されている。
図7Bの
図750は、トランジットミドルブロックMB2をS3スイッチに分解したグラフを、破線で示された、異なるミドルブロック間の対応するエッジとともに、示している。
【0039】
このようなグラフでは、残容量が0のミドルブロックが、一組の切離されたS3スイッチに分解される。トラフィック工学プロセスは、残容量が非ゼロの一組のミドルブロックを通過する新たなブロック間経路と、残容量がないミドルブロック内のS3スイッチを判断する。これを、グラフがミドルブロック内にS3スイッチしか含まなくなるまで、または、満たすことができる要求がなくなるまで、繰返す。
【0040】
ミドルブロックから得られたグラフからスタートし、満たすことができる要求がこれ以上ない場合にのみスイッチに分解することには、ある利点がある。この利点は、総容量が遥かに多いと思われるミドルブロックレベル経路よりも、スイッチレベル経路の方が多いという観察に由来する。このことを以下で詳細に示す。
【0041】
たとえば、ファブリックブロック(FB)の各ミドルブロック(MB)が8個のS2スイッチと8個のS3スイッチを含むと想定する。第1のミドルブロックMB1と第2のミドルブロックMB2との間の、1ホップのミドルブロックレベル経路は、3ホップのスイッチレベル経路、すなわちMB1.s2---MB1.s3---MB2.s3---MB2.s2に変換されるであろう。
【0042】
この場合、各ミドルブロックには8個のS2レベルスイッチがあるので、これらのS2スイッチのうちのいずれかを用いて、ソースミドルブロックにおいても宛先ミドルブロックにおいても、この経路を通ることができる。よって、合計64の異なるスイッチレベル経路があり、各スイッチレベル経路はMB1.s2とMB2.s2の固有の組合わせによって識別される。たとえば、2つの異なるスイッチレベル経路を、
MB1.s2[0]---MB1.s3[2]---MB2.s3[4]---MB2.s2[0]
MB1.s2[0]---MB1.s3[1]---MB2.s3[3]---MB2.s2[1]
とすることができる。ここで、括弧内の数字は、経路が通る特定のs2およびs3チップを特定している。
【0043】
2つのミドルブロックを複数のS3リンクによって接続することが可能である。このような場合、1ホップの場合の経路の総数は、第1のミドルブロックMB1のS3スイッチと第2のミドルブロックMB2のS3スイッチの間のリンクの数を、64で乗じたものである。長さkの経路の場合、経路上の各MB対を接続するS3リンクがたとえ1つだけであっても、スイッチレベル経路の数は8
(k+1)である。よって、スイッチを分離し、最初にミドルブロックレベル経路を見ることによって、グラフが大幅に減じられ、したがってルート計算プロセスがスピードアップする。
【0044】
トポロジイベント時のルート輻輳を最小にするために、トラフィック工学プロセスのある局面では、この故障イベントの影響を受ける要求、または、リンク/スイッチアップイベントの前に満たされなかった残りの要求を識別し、このような要求に対して割当てるべき、最小セットの新たな経路を求める。このインクリメンタルな更新は、最初から経路帯域幅割当てアルゴリズムを全体的に再実行する代わりに行なわれる。
【0045】
さまざまなサービスクラス(CoS)がトラフィック工学プロセスによってサポートされる。このプロセスは、各々三つ組(CoS、ソースMB、宛先ファブリックブロック)として表わすことができる一組の要求を処理する。サービスクラスは優先グループにグループ分けされる。たとえば、サービスクラスが4つ(CoS1、CoS2、CoS3、およびCoS4)の場合、可能な構成は、第1の優先部ループ1にCoS1とCoS2をまとめてグループ分けし第2の優先グループ2にCoS3とCoS4をまとめてグループ分けするように指示することであろう。異なるサービスクラスを優先グループに分けるという取決めは、プロセスへの入力の役割を果たす。
【0046】
このプロセスは、優先グループ内の公平な割当てに重み付けされた状態で、異なる優先グループ間に厳密な優先度を適用することが望ましい、よって、このプロセスは先ず、優先グループ1内のすべての要求を満たそうと試み、満たしてから、優先グループ2に移る。グループ1に帯域幅を割当てるとき、「重み付けされた注水」を実行し、この場合、重みはプロセスに対する入力として与えられる。基本的には、毎回要求をいくらかの量(デルタ)減じることを試みる代わりに、デルタ*重み(CoS)に従いサービスのクラスの重み付けを考慮しながら要求をその量だけ減じる。よって、
図4Aに関連付けて先に説明したプロセスフローを複数の優先グループに対して繰返してもよく、また、優先グループ内の各CoSに対して繰返してもよい。
【0047】
この技術の局面に従うトラフィック工学プロセスの高レベル疑似コードの例(「GraphConstruction」)を以下に示す。GraphConstruction()関数は、ブロック間トポロジに基づいてルート計算用のグラフを構築する。最初に、このグラフは、各ノードがミドルブロックを表わす最高抽象レベルからスタートし、抽象レベルを徐々に下げて混合抽象レベルの経路を識別することにより、追加要求を満たす。疑似コードの残りは、上記割当て戦略を実現する。
【0049】
トラフィック工学プロセスは、経路決定と帯域幅割当てのために以下のビルディングブロックのうちのいくつかまたはすべてを使用することが望ましい。
【0050】
(I)最短経路計算
ダイクストラ(Dijkstra)単一ソース最短経路アルゴリズムの変形を実現して最短経路を計算することが可能である。本明細書に記載の技術の局面において使用するこの変形において、入力はソースMB(src)および残余のミドルブロックグラフである。このアルゴリズムは、srcから他のノード各々への最短経路すべてを発見する。グラフ内のノードごとに、このアルゴリズムは、srcからこのノードまでのすべての最短経路に対応する先行要素(predecessors)のリストを作成する。
【0051】
エッジは、その残容量が0よりも多くかつそのエンドポイントノードの残容量が0よりも多いならば、存続可能とみなされる。このアルゴリズムは、ソースノードの所与のリストから並列に実行される。最初、このリストは、グラフ内のすべてのノードを含む。いくつかのソースノードと宛先ノードの間のすべての最短経路が使い果たされたときに、関連するソースノードしか含まないリストを用いた最短経路探索が呼び出される(以下を参照)。
【0052】
(II)最大容量最短経路を発見する
再帰的関数を用いて、所与のソースノード(src)から所与の宛先ノード(dst)までの最大容量最短経路を発見してもよい。srcとdstに加えて、再帰的関数は、入力として、srcからdstまでの最短経路に対応するdstの先行要素のリストを取る。この関数は、この先行要素を1つずつ調べ、最小化関数に従って最後のホップの容量(the capacity of the last hop)を計算する。
【0053】
last_hop_capacity = min(predecessor mb capacity, dst mb capacity, edge capacity between predecessor and dst)
last_hop_capacityが、これまでにわかっている最大経路容量よりも小さい場合は、この先行要素をそれ以上考慮する理由はない。そうでなければ、この関数はこの先行要素に対して再帰的に呼び出され、この先行要素を用いる全経路容量は、min(last_hop_capacity, max capacity path from src to predecessor)となる。この経路容量がそれまでに発見された最大値よりも大きい場合は、最大値が更新される。この再帰は、すでに発見されている最大容量経路の再計算を回避するためにキャッシュを用いる。
【0054】
(III)2つのミドルブロック間の次の有用な最短経路(path)を得る(get)
この方法(「get_path」)は、ソースノード(MB
s)と宛先ノード(MB
d)をパラメータとして得て、これらのノード間の容量が空でない最短経路を発見する。これは、以下の3つのステップに従ってその経路探索を拡大する。第1に、ソースと宛先の間に帯域幅を割当てるのに使用した最後の経路にまだいくらかの容量がある場合は、この経路を使用する。このために、システムは常に、すべてのノード対のノード間に割当てるために使用した最後の経路を覚えている(たとえばキャッシュに格納する)。第2に、このプロセスは、最短経路計算アルゴリズムの直前の呼出しによって発見された最短経路の中から、最大容量最短経路を発見する。戻された経路の容量が空でない場合はこの経路を使用する。第3に、最短経路計算アルゴリズムを呼び出して新たな最短経路を探すが、今回は、グラフ内のソースから他のすべてのノードまでのみである。次に、発見した最短経路の中から、最大容量最短経路を発見する。ここで、戻された経路の容量が空でない場合はこの経路を使用する。
【0055】
(IV)経路(path)に帯域幅を割当てる(allocate)
この方法(「allocate_path」)は、経路と要求をパラメータとして得て、この経路にmin(path capacity, demand)を割当てる。すべてのリンクおよびすべてのノード(ミドルブロック)に対し、残容量が維持される。
【0056】
(V)経路(path)の転置インデックス(index)
この方法(「index_path」)は、経路をパラメータとして得る。所与の経路内のすべてのノードとリンクに対し、経路識別子を、ノード/リンクを通る経路のリストに追加し、逆インデックスを作成する。これにより、システムは、再割当て用の関連経路を考慮するだけで、リンクおよびノードの故障に対して効率的に反応することができる。たとえば、2つの経路すなわちp
1=(a,b,c)とp
2(d、b、c、e)が存在する場合、システムは、リンクについて以下のインデックス(と、同様にノードのインデックス)を得るであろう。
(a,b):p
1
(b,c):p
1,p
2
(d,b):p
2
(c,e):p
2
この技術のある局面に従い、経路は固有経路IDによって表わされる。固有経路IDは、経路内の一連のノードIDをハッシュすることによって作成されてもよい。
【0057】
(VI)帯域幅割当て:最も帯域幅の広い経路(widest path)
このプロセス(「widest_path」)における入力は、ソースファブリックブロックFB
s、宛先ミドルブロックMB、および容量を示す定数DELTAである。目標は、ソースファブリックブロックFBs内の「最良」ミドルブロックを発見し、このソースミドルブロックと所与のミドルブロックMBの間の次の有用な経路にDELTAを割当て、使用した経路にインデックスを付けることである。このプロセスは、適切なソースミドルブロックが発見されなかった場合、「最良」のソースミドルブロックまたはナル(null)を返す。
【0058】
エッジ容量はDELTAの倍数であると想定する。この想定は、DELTA容量未満の容量の経路は必然的に残容量がないことを意味する。したがって、get_pathが呼び出されると、このプロセスは、少なくともDELTA残容量を有する2つのノード間の最短経路を探す。このような経路が発見されなかった場合、ソースと宛先の間には何らかの長さの有用な経路はこれ以上ないと判断される。
【0059】
このプロセスにおいて、FB
s内の「最良の」ソースミドルブロックは(以下の順で)、
a)MBへの次の有用な経路の少なくともDELTA容量と、MBを囲むスーパーブロックへの満たされていない少なくともDELTA要求を有し、
b)MBへの最小距離を有し、
c)MBを囲むファブリックブロックへの満たされていない最大要求を有する、
ソースミドルブロックである。
【0060】
このプロセスは、任意でこのような「最良」ミドルブロックのうちの1つを選択し、このミドルブロックと所与のミドルブロックMBの間の次の有用な最短経路にDELTAを割当てる。この割当て自体は、ソースおよび宛先ミドルブロックの対からリストへのマッピングであり、各要素は、異なる経路を表わし、経路の固有IDとこの経路に対する割当て容量を含む。
【0061】
(VII)帯域幅(bandwidth)割当て(allocate):可能な宛先を評価する
このプロセス(「allocate_bandwidth」)において、入力は、ミドルブロックからファブリックブロックへの要求であり、出力は満たされていない要求に対応付けられたグラフ内のノード間の割当てである。このプロセスは、可能な宛先ファブリックブロックを経由して循環する。宛先ファブリックブロックごとに、このプロセスは、現在の宛先ミドルブロックを維持し、割当てのためにファブリックブロックを考慮するたびに、その宛先ファブリックブロック内のミドルブロックを経由して循環する。このシステムはまた、「燃やされたターゲットミドルブロック」のリストを格納する。これらのブロックは、プロセスがソースを発見することができていない宛先ミドルブロックである。このため、将来これらを再び考慮する理由はない。このプロセスは、グラフ内のすべてのミドルブロックが「尽くされた(burned)」ときに終了する。
【0062】
このプロセスは、宛先ミドルブロックが与えられると、ソースファブリックブロックをラウンドロビン方式で選択する。次に、このソースファブリックブロックと宛先ミドルブロックをパラメータとして、widest_path帯域幅割当てプロセスを呼び出す。widest_path帯域幅割当てプロセスによって、DELTAの割当てに成功した場合、allocate_bandwidthプロセスがスタートに戻り、今回は、(ラウンドロビン方式で)他の宛先ミドルブロックを考慮する。そうでなければ、allocate_bandwidthプロセスは、ラウンドロビン方式で他のソースファブリックブロックを選択し、このファブリックブロックからのwidest_path帯域幅割当てプロセスを呼出し、同様のプロセスを経て、最終的に、widest_path帯域幅割当てプロセスが、割当てに成功するか、または、allocate_bandwidthプロセスが、可能なすべてのソーススーパーブロックを経由して循環したことになる。後者の場合、このプロセスは宛先ミドルブロックを「尽くす(burn)」。
【0063】
上記のように、各「割当て」は、いくつかのソースおよび宛先ミドルブロック間の経路のリストであり、各経路には割当てられた容量がある。allocate_bandwidthプロセスの最終ステップは、これらの量を正規化し、これらをたとえば以下のプロセスを用いて関連する「重み」にする。
【0064】
このプロセスに対する入力は、割当て容量のリストである。各量は、同一のソースと宛先間の、異なる経路に対する割当てに対応する。出力は、割当て容量当たりの関連する重みのリストである。このプロセスは以下の決定を行なう。リスト内の、「max_allocation」と示された最大割当て容量を発見する。割当て容量ごとに、ceilとして計算された(10 * allocation / max_allocation)重み(1〜10の規模)を生成する。ここで、「ceil」はceiling(天井)を意味する、すなわち、次に大きい整数値まで切り上げることを意味する。次に、重みを、これら重みの最大公分母(greatest common denominator)(「GCD」を用いて正規化する。たとえば、9:6:3は、3:2:1になる。
【0065】
(VIII)割当て解除プロセス
本開示のある局面に従うと、物理リンクが故障したとき、このシステムは、このリンクを通るすべての経路の割当て解除を行なってもよい。グラフ内で、物理リンクは、2つのミドルブロック間のエッジの一部であり、したがって、物理リンクの故障は、結果としてエッジ容量の減少を引起す。よって、正しい容量の割当て解除(deallocate)によってこの新たな容量に見合うようにする必要がある。割当て解除(「deallocate_paths_through_link」)は、経路の逆インデックスを用いて、影響を受けた可能性がある経路を発見する。
【0066】
このプロセスに対する入力は、2つのミドルブロック間のエッジとその新たな容量である。この新たな容量が、リンクを通した現在の割当てを満たすのに十分であれば、このプロセスは終了する。そうでなければ、このプロセスは割当て解除すべき帯域幅の容量を計算する。あるシナリオにおいて、このプロセスは、新たな容量を満たすのに十分な帯域幅のみを割当て解除するので、割当て解除後の残エッジ容量は0である。これに代わるものとして、残容量が0よりも多くなるように、必要分よりも少し多く割当て解除することが可能である。そうすることにより、システムは、毎回割当て解除することなく、その後のいくつかの故障を許容することができる(初回は過剰反応するがそのしばらく後になってからはセーブする)。
【0067】
影響を受けた通信リンクを通るすべての経路を考慮し、割当容量の降順で分類してもよい。そうする理由は、割当て解除プロセスの影響を受ける経路はできる限り少なくする必要があるからである。経路ごとに、割当容量を更新する、または、経路が完全に空になっている場合はこの経路を割当てから完全に除外する。経路に沿った残リンクおよびノード容量を更新し、それとともに、経路上のソースノードと宛先ノード間の満たされていない要求と逆経路インデックスを更新する。このプロセスは、割当て解除が、影響を受けた通信リンクの新たな容量を満たしたときに、完了する。
【0068】
(IX)エッジ容量更新プロセス
エッジ容量(capacities)更新(update)プロセス(「capacities_update_delta」)は、フォームの対(エッジ、容量デルタ(delta))のリストを入力として用いる。このプロセスはリストを評価する。リスト内のエッジごとに、容量が減少していれば、このプロセスは割当て解除(「deallocate_paths_through_link」)を呼び出した後にリンク容量を更新する。リストの作成後、システムは、満たされていない要求があるか否か判断するために検査する。あれば、allocate_bandwidthプロセスを呼び出してインクリメンタルな帯域幅割当てを試みる。なお、リンク容量が変わらない場合または増加した場合、このプロセスは、割当て解除を行なう必要はないが、システムは、場合によっては、割当て解除が行なわれた場合、満たされていない前の要求を満たすことができる。
【0069】
(X)ノードおよびリンクアップ/ダウンイベントの処理
ここで、通知を通して受けたイベントのリストは、プロセスに対する入力として扱われる。出力は、真/偽として扱われ得る。出力は、割当て変更があった場合は真であり、そうでなければ偽である。ここで、変更リストは同じエンティティ(リンク/ノード)を2回含むことはないと想定する。イベントの処理順序は重要ではないはずである。システムは、エッジから、このエッジのデルタ容量へのマップを維持する。システムはまた、リンクのセット(P)を維持する。この一組のリンクとは、システムが、そのエンドポイントスイッチのうちの1つに対する「リンクアップ」イベントまたはノードアップイベントを受けた、一組のリンクである。
【0070】
「リンクダウン」イベントの場合、システムは、リンク状態をダウンとして示し、このリンクを含むエッジはこの時点で容量が減少しているはずであることを思い出す。この状況において、デルタは、単一リンク容量の量が負である。
【0071】
「ノードダウン」(スイッチダウン)イベントの場合、ノードに接触するすべての進入または退出リンクについて、リンクは、まだ有用であれば、上記のようにリンクダウンイベントとして処理される。
【0072】
「リンクアップ」イベントの場合、システムはリンクを上記セットPに追加する。
「ノードアップ」イベントの場合は、ノードに接触するすべての進入または退出リンクについて、このプロセスはリンクを上記セットPに追加する。すべてのイベントが処理された後に、このプロセスはセットPを評価する。Pの中のすべてのリンクについて、リンクが有用であれば、このプロセスは、このリンクを含むエッジはこの時点で容量が増加しているはずであることを思い出す。デルタは、単一リンク容量の量が正である。
【0073】
セットPを有する理由は、たとえば、「ノードアップ」イベントが、システムがこのノードに接触するリンクを使用できることを必ずしも意味しないことにある。なぜなら、リンクまたはその他端スイッチがダウンである可能性があるからである。上記プロセスの場合、リンクを「有用」にする最初のイベントは、エッジの容量を増大させる。システムは、エッジのリストとこれらのデルタ容量を受けて、上記エッジ容量更新プロセス(capacities_update_delta)を呼び出す。いずれかの割当てが変更されていれば、このプロセスは新たな割当てマップを出力する。
【0074】
上記プロセスおよび動作は、
図2の装置200等の処理装置、たとえば、ネットワークフロー制御を管理するように構成されたスイッチまたは他の計算装置によって、実現されてもよい。上記のように、装置200は、1つ以上のプロセッサ202と、命令206とデータ208を格納するメモリ204とを含み得る。メモリは、ハードドライブ、キャッシュ、メモリカード、ROM、RAM、DVD、CD−ROM、書込み可能および読出し専用メモリ等の、プロセッサによってアクセス可能な情報を格納することができる、何らかの非一時的なメモリであればよい。
【0075】
命令206は、機械コード等の、プロセッサが直接実行する一組の命令であってもよく、または、スクリプト等の、プロセッサが間接的に実行する一組の命令であってもよい。この点に関して、「命令」、「アプリケーション」、「ステップ」および「プログラム」という用語は、本明細書では区別なく使用できる。命令は、プロセッサによって直接処理されるためにオブジェクトコードフォーマットで格納されてもよく、または、オンデマンドで解釈されるかもしくは予めコンパイルされているスクリプト、もしくは、独立したソースコードモジュールの集合を含む、他の計算装置言語で格納されてもよい。
【0076】
データ208は、命令206に従い、プロセッサ202によって、取出す、格納する、または修正することができる。たとえば、本明細書に記載の主題は特定のデータ構造によって限定される訳ではないが、データは、コンピュータのレジスタに、または、多数の異なるフィールドおよび記録を有するテーブルとしてリレーショナルデータベースに、またはXML文書に格納することができる。データはまた、二値、ASCIIまたはユニコード等であるがこれらに限定されない、計算装置による読取が可能なフォーマットで、フォーマットすることができる。加えて、データは、数字、記述テキスト、所有コード、ポインタ、他のネットワークロケーション等の他のメモリに格納されたデータの参照、または、関連データの計算のために機能が使用する情報といった、関連情報を識別するのに十分な情報を含み得る。
【0077】
1つ以上のプロセッサ202は、市場で入手可能なCPU等の従来のプロセッサを含み得る。これに代わるものとして、プロセッサは、ASICまたはその他のハードウェアベースのプロセッサ等の専用構成要素であってもよい。
図2は、装置200のプロセッサ、メモリ、およびその他の要素を、同一ブロック内にあるものとして機能的に示しているが、プロセッサ、コンピュータ、計算装置、またはメモリは実際、同一の物理的ハウジング内に格納される場合も格納されない場合もある、複数のプロセッサ、コンピュータ、計算装置、またはメモリを含み得る。たとえば、メモリは、スイッチ200とは異なるハウジング内にあるハードドライブまたはその他の記憶媒体であってもよい。したがって、プロセッサ、コンピュータ、計算装置、またはメモリに言及する場合、それは、並列動作する場合もしない場合もある、プロセッサ、コンピュータ、計算装置、またはメモリの集合に言及している場合も含まれることが理解されるであろう。たとえば、スイッチ200は、負荷分散されたサーバファームとして動作する1つ以上のサーバ計算装置を含み得る。さらに、本明細書に記載のいくつかの機能は、1つのプロセッサを有する1つの計算装置上で実行されるものとして示される場合があるが、記載されている主題のさまざまな局面は、たとえば、有線または無線ネットワークを通して情報通信する複数の計算装置によって実現できる。また、動作またはプロセスを特定の順序で示しているまたは説明している場合があるかもしれないが、本明細書で明記されていない限り、このような動作またはプロセスは、他の順序でまたは並列に実行されてもよい。
【0078】
実施形態の上記説明は、請求項によって定められる本開示を限定するものとしてではなく例示として理解されねばならない。また、本開示の例示(および「〜等の」、「たとえば」、「〜を含む」等のような表現)が、本開示を挙げられた特定の例に限定するものとして解釈されてはならないことが、理解されるであろう。むしろ、上記例は、可能性がある多数の実施形態のうちのいくつかのみを示すことを意図したものである。