(57)【特許請求の範囲】
【請求項１】
相互に通信する複数のファブリックブロックと各ファブリックブロック内の１つ以上のミドルブロックとを有するコンピュータネットワーク内のトラフィック工学の方法であって、前記方法は、
１つ以上のプロセッサによって、前記複数のファブリックブロックの中からソースファブリックブロックＦＢｓを識別するステップと、
ラウンドロビン順序で、前記複数のファブリックブロックの各宛先ファブリックブロックを評価するステップと、
前記１つ以上のプロセッサによって、ラウンドロビン順序で、選択された宛先ファブリックブロックＦＢｄ内の１つの宛先ミドルブロックＭＢｄを選ぶステップと、
前記１つ以上のプロセッサによって、ラウンドロビン順序で、ソースファブリックブロックＦＢｓを選択するステップと、
前記１つ以上のプロセッサによって、前記ソースファブリックブロックＦＢｓ内のすべてのミドルブロックの中からソースミドルブロックのサブセットＭを識別するステップとを含み、前記ソースミドルブロックのサブセットは、前記宛先ミドルブロックＭＢｄまでの利用できる経路長が最短であると識別されたものであり、
前記１つ以上のプロセッサによって、以下の条件
min(demand(MBs, FBd), spf_capacity(MBs, MBd))
を最大にする前記サブセットＭ内のソースミドルブロックＭＢｓのうちの１つのソースミドルブロックＭＢｓを、ネットワーク経路で使用するために選択するステップを含み、前記条件において、spf_capacity(MBs, MBd)は、前記ソースミドルブロックＭＢｓと前記宛先ミドルブロックＭＢｄの間の最短経路容量を表わし、demand(MBs, FBd)は、前記ソースミドルブロックＭＢｓと前記宛先ファブリックブロックＦＢｄの間の要求を表わす、方法。
【請求項２】
前記条件を最大にするソースミドルブロックと宛先ミドルブロックの選択を繰返すことによって帯域幅割当てを容易にするルート計算グラフを生成するステップをさらに含む、請求項１に記載の方法。
【請求項３】
ソースファブリックブロックごとに、宛先ファブリックブロックへの要求を、前記宛先ファブリックブロック内の故障がない各ミドルブロック間で等しく分割するステップをさらに含む、請求項１または２に記載の方法。
【請求項４】
各ミドルブロックを単一ノードとしてスケールアウトするステップと、
ミドルブロックごとにすべてのミドルブロックレベル経路を求めるステップと、
ミドルブロックレベル経路ごとにトンネルテーブルをセットアップするステップとをさらに含む、請求項１から３のいずれか１項に記載の方法。
【請求項５】
満たされた要求がすべての要求ではない場合、残りのブロック間帯域幅を識別するステップをさらに含む、請求項１から４のいずれか１項に記載の方法。
【請求項６】
複数の優先グループに対して前記方法を繰返し実行するステップをさらに含む、請求項１から５のいずれか１項に記載の方法。
【請求項７】
前記複数の優先グループ各々の中のサービスのクラスごとに前記方法を繰返し実行するステップをさらに含む、請求項６に記載の方法。
【請求項８】
前記複数の優先グループの中のサービスの各クラスに重み付けを適用するステップをさらに含む、請求項７に記載の方法。
【請求項９】
アップリンクイベントとダウンリンクイベントのうちの少なくとも一方に基づいて、前記ソースミドルブロックＭＢｓの選択を更新するステップをさらに含む、請求項１から８のいずれか１項に記載の方法。
【請求項１０】
１つ以上のプロセッサを備えたシステムであって、前記１つ以上のプロセッサは、
コンピュータネットワーク内で相互に通信する複数のファブリックブロックの中からソースファブリックブロックＦＢｓを識別するように構成され、
ラウンドロビン順序で、前記複数のファブリックブロックの各宛先ファブリックブロックを評価するように構成され、
ラウンドロビン順序で、選択された宛先ファブリックブロックＦＢｄ内の１つの宛先ミドルブロックＭＢｄを選ぶように構成され、
ラウンドロビン順序で、ソースファブリックブロックＦＢｓを選択するように構成され、
前記ソースファブリックブロックＦＢｓ内のすべてのミドルブロックの中からソースミドルブロックのサブセットＭを識別するように構成され、前記ソースミドルブロックのサブセットは、前記宛先ミドルブロックＭＢｄまでの利用できる経路長が最短であると識別されたものであり、
以下の条件
min(demand(MBs, FBd), spf_capacity(MBs, MBd))
を最大にする前記サブセットＭ内のソースミドルブロックＭＢｓのうちの１つのソースミドルブロックＭＢｓを、ネットワーク経路で使用するために選択するように構成され、前記条件において、spf_capacity(MBs, MBd)は、前記ソースミドルブロックＭＢｓと前記宛先ミドルブロックＭＢｄの間の最短経路容量を表わし、demand(MBs, FBd)は、前記ソースミドルブロックＭＢｓと前記宛先ファブリックブロックＦＢｄの間の要求を表わす、システム。
【請求項１１】
前記１つ以上のプロセッサはさらに、前記条件を最大にするソースミドルブロックと宛先ミドルブロックの選択を繰返すことによって帯域幅割当てを容易にするルート計算グラフを生成するように構成される、請求項１０に記載のシステム。
【請求項１２】
前記１つ以上のプロセッサはさらに、ソースファブリックブロックごとに、宛先ファブリックブロックへの要求を、前記宛先ファブリックブロック内の故障がない各ミドルブロック間で等しく分割するように構成される、請求項１０または１１に記載のシステム。
【請求項１３】
前記１つ以上のプロセッサはさらに、
各ミドルブロックを単一ノードとしてスケールアウトし、
ミドルブロックごとにすべてのミドルブロックレベル経路を求め、
ミドルブロックレベル経路ごとにトンネルテーブルをセットアップするように、構成される、請求項１０から１２のいずれか１項に記載のシステム。
【請求項１４】
前記１つ以上のプロセッサはさらに、満たされた要求がすべての要求ではない場合、残りのブロック間帯域幅を識別するように構成される、請求項１０から１３のいずれか１項に記載のシステム。
【請求項１５】
前記１つ以上のプロセッサはさらに、複数の優先グループに対し、前記条件を最大にする前記サブセットＭ内のソースミドルブロックＭＢｓのうちの１つを選択することを繰返し実行するように構成される、請求項１０から１４のいずれか１項に記載のシステム。
【請求項１６】
前記１つ以上のプロセッサは、前記複数の優先グループ各々の中のサービスのクラスごとに前記条件を最大にする前記サブセットＭ内のソースミドルブロックＭＢｓのうちの１つを選択することを繰返し実行するように構成される、請求項１５に記載のシステム。
【請求項１７】
前記１つ以上のプロセッサはさらに、前記複数の優先グループの中のサービスの各クラスに重み付けを適用するように構成される、請求項１６に記載のシステム。
【請求項１８】
アップリンクイベントとダウンリンクイベントのうちの少なくとも一方に基づいて、前記ソースミドルブロックＭＢｓの選択を更新することをさらに含む、請求項１０から１７のいずれか１項に記載のシステム。
【請求項１９】
１つ以上のプロセッサに方法を実行させるためのプログラムであって、前記方法は、相互に通信する複数のファブリックブロックと各ファブリックブロック内の１つ以上のミドルブロックとを有するコンピュータネットワーク内のトラフィック工学の方法であって、前記方法は、
１つ以上のプロセッサによって、前記複数のファブリックブロックの中からソースファブリックブロックＦＢｓを識別するステップと、
ラウンドロビン順序で、前記複数のファブリックブロックの各宛先ファブリックブロックを評価するステップと、
前記１つ以上のプロセッサによって、ラウンドロビン順序で、選択された宛先ファブリックブロックＦＢｄ内の１つの宛先ミドルブロックＭＢｄを選ぶステップと、
前記１つ以上のプロセッサによって、ラウンドロビン順序で、ソースファブリックブロックＦＢｓを選択するステップと、
前記１つ以上のプロセッサによって、前記ソースファブリックブロックＦＢｓ内のすべてのミドルブロックの中からソースミドルブロックのサブセットＭを識別するステップとを含み、前記ソースミドルブロックのサブセットは、前記宛先ミドルブロックＭＢｄまでの利用できる経路長が最短であると識別されたものであり、
前記１つ以上のプロセッサによって、以下の条件
min(demand(MBs, FBd), spf_capacity(MBs, MBd))
を最大にする前記サブセットＭ内のソースミドルブロックＭＢｓのうちの１つのソースミドルブロックＭＢｓを、ネットワーク経路で使用するために選択するステップを含み、前記条件において、spf_capacity(MBs, MBd)は、前記ソースミドルブロックＭＢｓと前記宛先ミドルブロックＭＢｄの間の最短経路容量を表わし、demand(MBs, FBd)は、前記ソースミドルブロックＭＢｓと前記宛先ファブリックブロックＦＢｄの間の要求を表わす、プログラム。
【請求項２０】
前記方法は、前記条件を最大にするソースミドルブロックと宛先ミドルブロックの選択を繰返すことによって帯域幅割当てを容易にするルート計算グラフを生成するステップをさらに含む、請求項１９に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
相互参照
本願は、その開示を本明細書に引用により援用する２０１３年１２月２３日に出願された米国特許出願第１４／１３９，１５０号の継続出願である。
【背景技術】
【０００２】
背景
コンピュータデータセンターでは、多数の異なるホストを用いて大量のデータを処理し、保存し、転送する。各ホストは、１つ以上のプロセッサと、メモリと、インターフェイスとを含み得る。サーバ等のホストは、ラック内に配置されることが多く、１ラック当たり複数のサーバが収容される。各ラックは、次のスイッチング層との通信のためのトップオブラック（top-of-rack）（「ＴＯＲ」）スイッチを有する場合がある。このスイッチング層は、二分化された大量の局所トラフィックを提供するスイッチ（「ミドルブロック」）のクラスタを含み得る。さらに、複数のミドルブロックは、より大きなクラスタ（「ファブリックブロック」）に論理的にグループ分けされる場合がある。これによって、多重レベルのスイッチング配置が生まれる。
【０００３】
ファブリックブロックは、これらのファブリックブロックの最上段のスイッチを高価な長距離ファイバおよび光学部品を用いて相互に接続した状態で、データセンター全体に配置することができる。ファブリックブロック間の相互接続には、二分化帯域幅とコスト削減の兼ね合いをつけるために、ＣＬＯＳタイプのトポロジを用いる代わりに、直接接続を採用することが多い。しかしながら、サービスのさまざまなクラスも考慮し、かつ、多重レベルスイッチング環境の中で効率的に機能する、帯域幅が公平に割当てられたシステムを提供することは、困難である。これは、ホストの数およびデータセンター全体のサイズが増すと、特に困難になる可能性がある。
【発明の概要】
【課題を解決するための手段】
【０００４】
簡単な概要
本開示のある局面は、さまざまな情報に基づいて、一組の終端間（end-to-end）経路を通るデータセンターネットワーク内のブロック間トラフィックの帯域幅割当てを決定する。これは、多数の最適化目標とヒューリスティックな注水（water-filling）戦略を用いることにより、不必要な経路を生成することを回避するとともに実際に必要なときには利用できないであろう経路を決定することを回避する。
【０００５】
本開示のある局面に従い、コンピュータネットワーク内のトラフィック工学の方法が提供される。このコンピュータネットワークは、相互に通信する複数のファブリックブロックと、各ファブリックブロック内の１つ以上のミドルブロックとを有する。この方法は、１つ以上のプロセッサによって、複数のファブリックブロックの中からソースファブリックブロックＦＢｓを識別するステップと、ラウンドロビン順序で、複数のファブリックブロックの各宛先ファブリックブロックを評価するステップと、１つ以上のプロセッサによって、ラウンドロビン順序で、選択された宛先ファブリックブロックＦＢｄ内の１つの宛先ミドルブロックＭＢｄを選ぶステップと、１つ以上のプロセッサによって、ラウンドロビン順序で、ソースファブリックブロックＦＢｓを選択するステップと、１つ以上のプロセッサによって、ソースファブリックブロックＦＢｓ内のすべてのミドルブロックの中からソースミドルブロックのサブセットＭを識別するステップとを含み、このソースミドルブロックのサブセットは、宛先ミドルブロックＭＢｄまでの利用できる経路長が最短であると識別されたものであり、上記方法はさらに、１つ以上のプロセッサによって、以下の条件
min(demand(MBs, FBd), spf_capacity(MBs, MBd))
を最大にするサブセットＭ内のソースミドルブロックＭＢｓのうちの１つのソースミドルブロックＭＢｓを、ネットワーク経路で使用するために選択するステップを含み、上記条件において、spf_capacity(MBs, MBd)は、ソースミドルブロックＭＢｓと宛先ミドルブロックＭＢｄの間の最短経路容量を表わし、demand(MBs, FBd)は、ソースミドルブロックＭＢｓと宛先ファブリックブロックＦＢｄの間の要求を表わす。
【０００６】
ある代替例において、上記方法はさらに、上記条件を最大にするソースミドルブロックと宛先ミドルブロックの選択を繰返すことによって帯域幅割当てを容易にするルート計算グラフを生成するステップを含む。別の代替例において、上記方法はさらに、ソースファブリックブロックごとに、宛先ファブリックブロックへの要求を、宛先ファブリックブロック内の故障がない各ミドルブロック間で等しく分割するステップを含む。
【０００７】
上記方法はさらに、各ミドルブロックを単一ノードとしてスケールアウトするステップと、ミドルブロックごとにすべてのミドルブロックレベル経路を求めるステップと、ミドルブロックレベル経路ごとにトンネルテーブルをセットアップするステップとを含み得る。他の例において、満たされた要求がすべての要求ではない場合、上記方法はさらに、残りのブロック間帯域幅を識別するステップを含む。
【０００８】
別の代替例において、上記方法は、複数の優先グループに対して繰返し実行される。これは、複数の優先グループ各々の中のサービスのクラスごとに上記方法を繰返し実行することを含み得る。この場合、上記方法はさらに、複数の優先グループの中のサービスの各クラスに重み付けを適用するステップを含み得る。
【０００９】
他の代替例において、上記方法はさらに、アップリンクイベントとダウンリンクイベントのうちの少なくとも一方に基づいて、ソースミドルブロックＭＢｓの選択を更新するステップをさらに含む。
【００１０】
上記方法は、下記のように１つ以上のプロセッサによって実行されてもよい。この方法を実行するための命令を格納した記録媒体も提供される。
【図面の簡単な説明】
【００１１】
【図１】本開示の局面で使用する多段データセンターネットワークの一例を示す。
【図２】本開示の局面で使用するホスト計算装置の一例を示す。
【図３】ミドルブロック内エッジにおける輻輳の一例を示す。
【図４】トップオブラックアップリンク上の輻輳の一例を示す。
【図４Ａ】本開示の局面に従うトラフィック工学プロセスのフロー図を示す。
【図５】本開示の局面に従うルート計算グラフの一例を示す。
【図６】本開示の局面に従うソースミドルブロックと宛先ミドルブロックの間のミドルブロック経路の一例を示す。
【図７Ａ】本開示の局面に従うルート計算グラフの別の例を示す。
【図７Ｂ】本開示の局面に従う混合抽象レベルのブロック間経路の一例を示す。
【発明を実施するための形態】
【００１２】
詳細な説明
本開示の局面、特徴、および利点は、以下の実施形態の説明および添付の図面を参照しながら検討されたときに理解されるであろう。異なる図面における同一の参照番号は、同一のまたは同様の要素を示す場合がある。さらに、以下の説明は限定的なものではなく、本技術の範囲は、以下の請求項とその均等物によって定められる。代表的な実施形態に従う特定のプロセスが、線図として表現されている図面に示されているが、これは、本明細書で明記されていない限り、必要条件ではない。異なるプロセスは、異なる順序でまたは同時に実行されてもよい。ステップは、特に記載されていない限り、追加されるまたは削除される場合もある。
【００１３】
本明細書に記載の技術は、直接接続トポロジを採用したネットワークを含むデータセンターネットワークに対し、トラフィック工学の解決策を示す。上記のように、大規模データセンターネットワークは、コストと帯域幅の兼ね合いが取れた多段のスイッチを含み得る。この技術のある局面では、複数の最適化目標を有しさまざまな割当て戦略を用いて効率的なデータルーティングを提供する、公平性関数（fairness function）が採用される。
【００１４】
多くのネットワーク割当てアルゴリズムは、公平さとサービスのクラスを考慮する。しかしながら、スーパースイッチのネットワークでは、低レベルの物理スイッチング要素で構成されたグラフを検討する代わりに、スイッチングの抽象性を活用することが可能である。この手法は、より一層小さなグラフを作成し、結果的に割当てのスピードアップにつながる。加えて、帯域幅割当ての解決策は、本明細書に記載のように、ネットワーク内のさまざまなフロー全体のマクシミン公平性（max-min fairness）のような単純な公平性の概念を考慮する場合があるが、スイッチをグループ化することにより、スーパーブロックのさまざまなミドルブロックを通るトラフィック全体の公平性のような新たな公平性の要件が生まれる。その他の制約は、スイッチ内のトンネルエントリの数に制限があることに由来する。
【００１５】
以下で詳細に説明する特定の局面に従うと、公平性関数は、複数の最適化目標を含む。このような目標は、重要性が低くなる順に考慮されてもよく、
１．サービスのクラスの維持、
２．マクシミン公平性、
３．スーパーブロック内のマクシミン公平性、
４．経路距離の最短化、
５．経路の総数の最小化、および
６．所与の要求を満たすのに必要な経路の数の最小化
を含み得る。
【００１６】
第１の目標について、サービスのクラスは、優先グループにグループ分けしてもよい。厳密な優先度が、さまざまな優先グループ全体に適用され、各優先グループ内で公平性が重み付けされる。サービスのクラスの、優先グループへの分割、および、サービスのさまざまなクラスの重みは、全体のプロセスに対する入力として与えられる。
【００１７】
この技術の局面は、ミドルブロックからグラフを構成することを含み、満たすことができる要求がなくなったときに限り、選ばれたミドルブロックをスイッチングチップに分解する。そうすることによって異なる抽象レベルのスイッチのグラフが作成される。ソースと宛先の間にｋディスジョイント（ｄｉｓｊｏｉｎｔ）最短経路を常に作る解決策とは異なり、経路はオンデマンドで決定される。このような手法には主な利点が２つある。第１に、不必要な経路は作成されない。第２に、実際に必要なときに利用できない経路は計算されない。たとえば、このプロセスが、第１のソース（ｓｒｃ１）から第１の宛先（ｄｓｔ１）までの１０の経路を予め計算している場合、これらの経路は、第２のソース（ｓｒｃ２）から第２の宛先（ｄｓｔ２）までの経路と、リンクを共有する場合がある。よって、これらを十分に用いてｓｒｃ１からｄｓｔ１への要求を割当てることに固執した場合、公平性が損なわれるかもしれない。代わりに、ある局面に従う反復手法が採用される。
【００１８】
一例として、いくつかの要求を割当てようとする場合、最初にすべてのノード対間の最小長さのすべての（必ずしもディスジョイントではない）経路を計算する（上記ｋ最短経路ｗと異なり、最小長さの経路のみが計算され、したがって、このステップで作られたすべての経路の経路長が等しい）。このプロセスは次に、最適化目標を満たす多段注水手順を用いる。ソースから宛先までの最小長さのすべての経路が使い果たされたときに初めて、使用可能な帯域幅の容量を有する、ソースと宛先の間の次の最短経路が計算される。
【００１９】
このプロセスは、ノードおよびリンクの故障時に、割当てをインクリメンタルに調整し、必要最小限の割当て変更のみを実施するように構成されている。ソースと宛先の間の要求を満たすことができない場合は、分解技術を用いてミドルブロックをネットワークグラフ内のスイッチングチップに置換える。その後このプロセスは残りの要求を割当てようと試みる。
【００２０】
これは、トラフィックのバランスを取ること、チップテーブルエントリを最小にすること等の、現実の生産ニーズを取込むロバストな最適化関数を提供するという点において、好都合である。グラフを繰返し分解することによって、スーパークラスタで使用されているスイッチング要素の抽象性を活用する。採用されている技術は、要求変更、故障に合わせて、サービスパラメータの品質を考慮する。
【００２１】
図１は、代表的な多段データセンターネットワーク１００を示す。ネットワーク１００は、複数のファブリックブロック１０２を含み、これらの複数のファブリックブロックは、一点鎖線で表わされたリンク１０４を介して直接接続されて示されている。実際、リンク１０４は光ファイバリンクであってもよい。この例において、各ファブリックブロック１０２は、複数のトップオブラックスイッチ１０８１〜１０８Ｎを相互に接続する複数のミドルブロック１０６１〜１０６Ｎを含む２段ネットワークを備えている。
【００２２】
各ミドルブロック１０６は、２段のスイッチ、すなわち第１段１１０（Ｓ２）と第２段１１２（Ｓ３）とを含み得る。各ミドルブロックの２段ネットワークのＳ２およびＳ３スイッチは、Ｃｌｏｓ配置で相互接続されていてもよい。ファブリックブロック１０２間の接続と同様に、ミドルブロック１０６およびＴＯＲスイッチ１０８は、リンク１１４を介して直接接続されている。このリンクも光ファイバリンクであってもよい。
【００２３】
図２に示されるように、各スイッチ２００は、１つ以上のプロセッサ２０２、たとえばＣＰＵおよび／またはＡＳＩＣを含み得る。スイッチ２００はまた、命令２０６およびデータ２０８を格納するメモリ２０４を含む。ポート２１０を介した複数の接続によって、データセンターネットワーク内の他のスイッチ間の通信リンクが提供される。
【００２４】
このような多段データセンターネットワークのためのトラフィック工学は、従来のＩＳＰネットワークでは生じないさまざまな課題に取り組む必要がある。たとえば、トラフィック工学は、従来のＩＳＰネットワークよりも桁違いに大きいデータセンターネットワークのためのルートを効率的に計算するのに見合ったものでなければならず、また、故障時のルート収束時間を最小にしなければならない。加えて、データセンターネットワーク内のトポロジの不均一性に対処し、ブロック内リンク上でもブロック間リンク上でも終端間のトラフィックの流れの輻輳を低減しなければならない。さらに、トラフィック工学は、ネットワークスイッチ内の限られたフォワーディング（forwarding）テーブルエントリを考慮する必要もある。
【００２５】
このような課題に対処するために、トラフィック工学の解決策のある局面では、入力としてさまざまな情報を用いて、一組の終端間経路を通るブロック間トラフィックに対する帯域幅割当てを決定する。この入力情報は、ブロック間トポロジ、所与のサービスクラス（class of service）（「ＣｏＳ」）について一対のソースファブリックブロックと宛先ファブリックブロックとの間の所望の総スループットを示す一組のトラフィック要求、異なるＣｏＳ間のスケジューリングポリシー（たとえば優先グループ化）、および、トランジットブロック間トラフィックを扱うミドルブロックの容量のうちの、いくつかまたはすべてを考慮している。
【００２６】
そのために、多数の最適化目標が考慮される。ある目標は、異なるソースファブリックブロックと宛先ファブリックブロックとの間のトラフィック要求間の公平性である。別の目標は、ブロック間トラフィックのホップカウントを最小にすることによってレイテンシを減じることである。他の目標は、ブロック間トラフィックの経路数を最小にすることによってフォワーディングテーブルエントリの数を減じることである。さらに他の目標は、ブロック間リンクおよびブロック内リンク上の輻輳を最小にすることである。もう１つの目標は、トラフィック工学プロセスの実行時速度を最小にすることである。さらに他の目標は、故障が発生した場合のルート収束時間を最小にすることである。さらに他の目標は、サービス品質を考慮することである。これらの目標は、以下で詳細に述べるようにして達成される。
【００２７】
本明細書に記載の帯域幅割当てのある局面では、「注水」技術を取入れることにより、同じペースで異なるソース−宛先ファブリックブロック対のトラフィック要求に対する帯域幅割当てを増す。帯域幅割当ては、完全に満たされたトラフィック要求についてはフリーズし、まだ満たされていない要求については増し続ける。これは、一例では、最短経路を先ず優先することによってホップカウントを減じしたがってブロック間トラフィックのレイテンシを減じることによって、行なわれる。
【００２８】
図３および図４に関連して示されているように、各ファブリックブロック内のスイッチはＣｌｏｓトポロジで相互に接続されているが、それでもなお輻輳は発生し得る。図３は代表的なネットワーク３００を示し、その３つのファブリックブロック３０２はたとえば光配線（図示せず）によって接続されている。ファブリックブロックＢのミドルブロック３０６とＴＯＲスイッチ３０８が相互に接続されており、各ミドルブロック３０６のＳ２スイッチ３１０とＳ３スイッチも相互に接続されている。これは図１に関連して先に述べた通りである。
【００２９】
この例において、各ミドルブロック３０６は、コスト削減のために２段のみを含み得るＣｌｏｓネットワークである。ブロック内トラフィック３１４は実線で示され、ブロック間トラフィック３１６は点線で示されている。輻輳３１８は、ファブリックブロックＢ内のこのようなミドルブロックが、ブロック内トラフィックと、ファブリックブロックＣを宛先とするファブリックブロックＡからのトランジットブロック間トラフィック双方を扱っている場合に、起こり得る。
【００３０】
図４は、ファブリックブロックＡとＤの間の最短経路の利用を最大にするためのネイティブな帯域幅割当て方式の代表的なシナリオ４００を示す。ここで、ファブリックブロック４０２間のブロック間通信は４０ギガビット／秒（４０Ｇ）で発生するのに対し、ブロック内通信は１０ギガビット／秒（１０Ｇ）の速度で発生する。ミドルブロック４０６を経由したＴＯＲスイッチ４０８からファブリックブロックＤへのブロック間トラフィックの最大速度が２０ギガビット／秒（２０Ｇ）の場合、結果として、速度が超過したときにアップリンク上で輻輳４１８が発生する。
【００３１】
ミドルブロック間エッジにおける輻輳を最小にするために、トラフィック工学プロセスのある局面は、経路の容量を、（ａ）ボトルネックブロック間リンクの容量と（ｂ）輻輳なしでトランジットブロック間トラフィックを扱うためのボトルネックミドルブロックの容量との間の最小容量として決定する。各ミドルブロックエッジ接続は、１つ以上の物理通信リンクを含み得る。
【００３２】
ＴＯＲアップリンク上の輻輳を最小にするために、トラフィック工学プロセスは、以下で説明する戦略を用いることにより、ブロック間およびブロック内「マクシミン」公平性を保証する。このプロセスを示すフロー図４５０が図４Ａに示される。
【００３３】
先ず、ブロック４５２に示されるように、このプロセスは、ファブリックブロックごとに、宛先ファブリックブロックへの帯域幅要求を、このファブリックブロックのミドルブロック間で等しく分割する。次に、このプロセスは下記のヒューリスティックな注水戦略を用いて、同じペースで異なるソース／宛先ファブリックブロックへの帯域幅割当てを増し、加えて、以下のように、ラウンドロビン方式で、ソースまたは宛先ファブリックブロック内の異なるミドルブロックに対してブロック間経路帯域幅を等しく割当てる。
【００３４】
ブロック４５４に示されるように、宛先ファブリックブロックＦＢｄを、ラウンドロビン方式で考慮する。ブロック４５６に示されるように、ファブリックブロックＦＢｄを考慮するたびに、ラウンドロビン方式で選ばれた、ＦＢｄ内の１つの宛先ミドルブロックＭＢｄに注目する。ブロック４５８に示されるように、ソースファブリックブロックＦＢｓをラウンドロビン方式で選択する。
【００３５】
ブロック４６０に示されるように、ソースファブリックブロックＦＢｓ内のミドルブロックの中から、利用できる、宛先ミドルブロックＭＢｄへの経路長が、最短である、サブセットＭを発見する。ここで、ブロック４６２に示されるように、サブセットＭ内のミドルブロックの中から、
min(demand(MBs, FBd), spf_capacity(MBs, MBd))
を最大にするミドルブロックを選択する。ここで、spf_capacity(MBs, MBd)は、ソースミドルブロックＭＢｓと前記宛先ミドルブロックＭＢｄの間の最短経路容量（shortest path capacity）を表わし、demand(MBs, FBd)は、ソースミドルブロックＭＢｓと宛先ファブリックブロックＦＢｄの間の要求（demand）を表わす。
【００３６】
このシナリオにおいて、スケーラビリティと経路数の最小化のために、トラフィック工学プロセスは先ず、各ミドルブロックを単一ノードとしてスケールアウトし、すべてのミドルブロックレベル経路を計算する。このプロセスは、すべての要求をこのような経路によって満たすことができた場合に終了し、図５および図６に示される各ミドルブロックレベル経路に対する「トンネル」をセットアップする。
【００３７】
図５は、ソースミドルブロック５０２と、宛先ミドルブロック５０４と、トランジットミドルブロック５０６とを備えた配置５００を示す。ミドルブロックは各々、上記のようにＣｌｏｓ配置で相互に接続されたＳ２スイッチとＳ３スイッチの２段のネットワークを有し得る。図６の例６００は、トランジットミドルブロック６０６の２段スイッチネットワークを経由したソースミドルブロック６０２と宛先ミドルブロック６０４の間の代表的なミドルブロックレベル経路を示す。ここで、破線は異なるスイッチ間のエッジを示す。この配置は、トラフィック工学プロセスの実行時間を最短にし、典型的には何百ものトンネルだけで、スイッチ上でプログラムされるトンネルテーブルエントリを最小にするのに役立つ。
【００３８】
満たされた要求がすべての要求ではない場合、トラフィック工学プロセスは引続き、ミドルブロック内でのバウンス（bouncing）を必要としない、残りのブロック間帯域幅を識別する。本開示のある局面に従うと、ある手法は、図７Ａ〜図７Ｂに繰返し示されている、抽象レベルを下げたグラフを構築する。図７Ａは、ソースミドルブロック７０２と、宛先ミドルブロック７０４と、２つのトランジットミドルブロック７０６および７０８とを有するルート計算グラフ７００を示す。ここで示されているように、トランジットミドルブロック７０６（ＭＢ１）はすでにＳ３チップに分解されている。図７Ｂの図７５０は、トランジットミドルブロックＭＢ２をＳ３スイッチに分解したグラフを、破線で示された、異なるミドルブロック間の対応するエッジとともに、示している。
【００３９】
このようなグラフでは、残容量が０のミドルブロックが、一組の切離されたＳ３スイッチに分解される。トラフィック工学プロセスは、残容量が非ゼロの一組のミドルブロックを通過する新たなブロック間経路と、残容量がないミドルブロック内のＳ３スイッチを判断する。これを、グラフがミドルブロック内にＳ３スイッチしか含まなくなるまで、または、満たすことができる要求がなくなるまで、繰返す。
【００４０】
ミドルブロックから得られたグラフからスタートし、満たすことができる要求がこれ以上ない場合にのみスイッチに分解することには、ある利点がある。この利点は、総容量が遥かに多いと思われるミドルブロックレベル経路よりも、スイッチレベル経路の方が多いという観察に由来する。このことを以下で詳細に示す。
【００４１】
たとえば、ファブリックブロック（ＦＢ）の各ミドルブロック（ＭＢ）が８個のＳ２スイッチと８個のＳ３スイッチを含むと想定する。第１のミドルブロックＭＢ１と第２のミドルブロックＭＢ２との間の、１ホップのミドルブロックレベル経路は、３ホップのスイッチレベル経路、すなわちMB1.s2---MB1.s3---MB2.s3---MB2.s2に変換されるであろう。
【００４２】
この場合、各ミドルブロックには８個のＳ２レベルスイッチがあるので、これらのＳ２スイッチのうちのいずれかを用いて、ソースミドルブロックにおいても宛先ミドルブロックにおいても、この経路を通ることができる。よって、合計６４の異なるスイッチレベル経路があり、各スイッチレベル経路はＭＢ１．ｓ２とＭＢ２．ｓ２の固有の組合わせによって識別される。たとえば、２つの異なるスイッチレベル経路を、
MB1.s2[0]---MB1.s3[2]---MB2.s3[4]---MB2.s2[0]
MB1.s2[0]---MB1.s3[1]---MB2.s3[3]---MB2.s2[1]
とすることができる。ここで、括弧内の数字は、経路が通る特定のｓ２およびｓ３チップを特定している。
【００４３】
２つのミドルブロックを複数のＳ３リンクによって接続することが可能である。このような場合、１ホップの場合の経路の総数は、第１のミドルブロックＭＢ１のＳ３スイッチと第２のミドルブロックＭＢ２のＳ３スイッチの間のリンクの数を、６４で乗じたものである。長さｋの経路の場合、経路上の各ＭＢ対を接続するＳ３リンクがたとえ１つだけであっても、スイッチレベル経路の数は８（ｋ＋１）である。よって、スイッチを分離し、最初にミドルブロックレベル経路を見ることによって、グラフが大幅に減じられ、したがってルート計算プロセスがスピードアップする。
【００４４】
トポロジイベント時のルート輻輳を最小にするために、トラフィック工学プロセスのある局面では、この故障イベントの影響を受ける要求、または、リンク／スイッチアップイベントの前に満たされなかった残りの要求を識別し、このような要求に対して割当てるべき、最小セットの新たな経路を求める。このインクリメンタルな更新は、最初から経路帯域幅割当てアルゴリズムを全体的に再実行する代わりに行なわれる。
【００４５】
さまざまなサービスクラス（ＣｏＳ）がトラフィック工学プロセスによってサポートされる。このプロセスは、各々三つ組（ＣｏＳ、ソースＭＢ、宛先ファブリックブロック）として表わすことができる一組の要求を処理する。サービスクラスは優先グループにグループ分けされる。たとえば、サービスクラスが４つ（ＣｏＳ１、ＣｏＳ２、ＣｏＳ３、およびＣｏＳ４）の場合、可能な構成は、第１の優先部ループ１にＣｏＳ１とＣｏＳ２をまとめてグループ分けし第２の優先グループ２にＣｏＳ３とＣｏＳ４をまとめてグループ分けするように指示することであろう。異なるサービスクラスを優先グループに分けるという取決めは、プロセスへの入力の役割を果たす。
【００４６】
このプロセスは、優先グループ内の公平な割当てに重み付けされた状態で、異なる優先グループ間に厳密な優先度を適用することが望ましい、よって、このプロセスは先ず、優先グループ１内のすべての要求を満たそうと試み、満たしてから、優先グループ２に移る。グループ１に帯域幅を割当てるとき、「重み付けされた注水」を実行し、この場合、重みはプロセスに対する入力として与えられる。基本的には、毎回要求をいくらかの量（デルタ）減じることを試みる代わりに、デルタ＊重み（ＣｏＳ）に従いサービスのクラスの重み付けを考慮しながら要求をその量だけ減じる。よって、図４Ａに関連付けて先に説明したプロセスフローを複数の優先グループに対して繰返してもよく、また、優先グループ内の各ＣｏＳに対して繰返してもよい。
【００４７】
この技術の局面に従うトラフィック工学プロセスの高レベル疑似コードの例（「GraphConstruction」）を以下に示す。GraphConstruction()関数は、ブロック間トポロジに基づいてルート計算用のグラフを構築する。最初に、このグラフは、各ノードがミドルブロックを表わす最高抽象レベルからスタートし、抽象レベルを徐々に下げて混合抽象レベルの経路を識別することにより、追加要求を満たす。疑似コードの残りは、上記割当て戦略を実現する。
【００４８】
【数１】
0006275263.tif 000002
【００４９】
トラフィック工学プロセスは、経路決定と帯域幅割当てのために以下のビルディングブロックのうちのいくつかまたはすべてを使用することが望ましい。
【００５０】
（Ｉ）最短経路計算
ダイクストラ（Dijkstra）単一ソース最短経路アルゴリズムの変形を実現して最短経路を計算することが可能である。本明細書に記載の技術の局面において使用するこの変形において、入力はソースＭＢ（ｓｒｃ）および残余のミドルブロックグラフである。このアルゴリズムは、ｓｒｃから他のノード各々への最短経路すべてを発見する。グラフ内のノードごとに、このアルゴリズムは、ｓｒｃからこのノードまでのすべての最短経路に対応する先行要素（predecessors）のリストを作成する。
【００５１】
エッジは、その残容量が０よりも多くかつそのエンドポイントノードの残容量が０よりも多いならば、存続可能とみなされる。このアルゴリズムは、ソースノードの所与のリストから並列に実行される。最初、このリストは、グラフ内のすべてのノードを含む。いくつかのソースノードと宛先ノードの間のすべての最短経路が使い果たされたときに、関連するソースノードしか含まないリストを用いた最短経路探索が呼び出される（以下を参照）。
【００５２】
（ＩＩ）最大容量最短経路を発見する
再帰的関数を用いて、所与のソースノード（ｓｒｃ）から所与の宛先ノード（ｄｓｔ）までの最大容量最短経路を発見してもよい。ｓｒｃとｄｓｔに加えて、再帰的関数は、入力として、ｓｒｃからｄｓｔまでの最短経路に対応するｄｓｔの先行要素のリストを取る。この関数は、この先行要素を１つずつ調べ、最小化関数に従って最後のホップの容量（the capacity of the last hop）を計算する。
【００５３】
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）となる。この経路容量がそれまでに発見された最大値よりも大きい場合は、最大値が更新される。この再帰は、すでに発見されている最大容量経路の再計算を回避するためにキャッシュを用いる。
【００５４】
（ＩＩＩ）２つのミドルブロック間の次の有用な最短経路（path）を得る（get）
この方法（「get_path」）は、ソースノード（ＭＢｓ）と宛先ノード（ＭＢｄ）をパラメータとして得て、これらのノード間の容量が空でない最短経路を発見する。これは、以下の３つのステップに従ってその経路探索を拡大する。第１に、ソースと宛先の間に帯域幅を割当てるのに使用した最後の経路にまだいくらかの容量がある場合は、この経路を使用する。このために、システムは常に、すべてのノード対のノード間に割当てるために使用した最後の経路を覚えている（たとえばキャッシュに格納する）。第２に、このプロセスは、最短経路計算アルゴリズムの直前の呼出しによって発見された最短経路の中から、最大容量最短経路を発見する。戻された経路の容量が空でない場合はこの経路を使用する。第３に、最短経路計算アルゴリズムを呼び出して新たな最短経路を探すが、今回は、グラフ内のソースから他のすべてのノードまでのみである。次に、発見した最短経路の中から、最大容量最短経路を発見する。ここで、戻された経路の容量が空でない場合はこの経路を使用する。
【００５５】
（ＩＶ）経路（path）に帯域幅を割当てる（allocate）
この方法（「allocate_path」）は、経路と要求をパラメータとして得て、この経路にmin(path capacity, demand）を割当てる。すべてのリンクおよびすべてのノード（ミドルブロック）に対し、残容量が維持される。
【００５６】
（Ｖ）経路（path）の転置インデックス（index）
この方法（「index_path」）は、経路をパラメータとして得る。所与の経路内のすべてのノードとリンクに対し、経路識別子を、ノード／リンクを通る経路のリストに追加し、逆インデックスを作成する。これにより、システムは、再割当て用の関連経路を考慮するだけで、リンクおよびノードの故障に対して効率的に反応することができる。たとえば、２つの経路すなわちｐ１＝（ａ，ｂ，ｃ）とｐ２（ｄ、ｂ、ｃ、ｅ）が存在する場合、システムは、リンクについて以下のインデックス（と、同様にノードのインデックス）を得るであろう。
（ａ，ｂ）：ｐ１
（ｂ，ｃ）：ｐ１，ｐ２
（ｄ，ｂ）：ｐ２
（ｃ，ｅ）：ｐ２
この技術のある局面に従い、経路は固有経路ＩＤによって表わされる。固有経路ＩＤは、経路内の一連のノードＩＤをハッシュすることによって作成されてもよい。
【００５７】
（ＶＩ）帯域幅割当て：最も帯域幅の広い経路（widest path）
このプロセス（「widest_path」）における入力は、ソースファブリックブロックＦＢｓ、宛先ミドルブロックＭＢ、および容量を示す定数ＤＥＬＴＡである。目標は、ソースファブリックブロックＦＢｓ内の「最良」ミドルブロックを発見し、このソースミドルブロックと所与のミドルブロックＭＢの間の次の有用な経路にＤＥＬＴＡを割当て、使用した経路にインデックスを付けることである。このプロセスは、適切なソースミドルブロックが発見されなかった場合、「最良」のソースミドルブロックまたはナル（null）を返す。
【００５８】
エッジ容量はＤＥＬＴＡの倍数であると想定する。この想定は、ＤＥＬＴＡ容量未満の容量の経路は必然的に残容量がないことを意味する。したがって、get_pathが呼び出されると、このプロセスは、少なくともＤＥＬＴＡ残容量を有する２つのノード間の最短経路を探す。このような経路が発見されなかった場合、ソースと宛先の間には何らかの長さの有用な経路はこれ以上ないと判断される。
【００５９】
このプロセスにおいて、ＦＢｓ内の「最良の」ソースミドルブロックは（以下の順で）、
ａ）ＭＢへの次の有用な経路の少なくともＤＥＬＴＡ容量と、ＭＢを囲むスーパーブロックへの満たされていない少なくともＤＥＬＴＡ要求を有し、
ｂ）ＭＢへの最小距離を有し、
ｃ）ＭＢを囲むファブリックブロックへの満たされていない最大要求を有する、
ソースミドルブロックである。
【００６０】
このプロセスは、任意でこのような「最良」ミドルブロックのうちの１つを選択し、このミドルブロックと所与のミドルブロックＭＢの間の次の有用な最短経路にＤＥＬＴＡを割当てる。この割当て自体は、ソースおよび宛先ミドルブロックの対からリストへのマッピングであり、各要素は、異なる経路を表わし、経路の固有ＩＤとこの経路に対する割当て容量を含む。
【００６１】
（ＶＩＩ）帯域幅（bandwidth）割当て（allocate）：可能な宛先を評価する
このプロセス（「allocate_bandwidth」）において、入力は、ミドルブロックからファブリックブロックへの要求であり、出力は満たされていない要求に対応付けられたグラフ内のノード間の割当てである。このプロセスは、可能な宛先ファブリックブロックを経由して循環する。宛先ファブリックブロックごとに、このプロセスは、現在の宛先ミドルブロックを維持し、割当てのためにファブリックブロックを考慮するたびに、その宛先ファブリックブロック内のミドルブロックを経由して循環する。このシステムはまた、「燃やされたターゲットミドルブロック」のリストを格納する。これらのブロックは、プロセスがソースを発見することができていない宛先ミドルブロックである。このため、将来これらを再び考慮する理由はない。このプロセスは、グラフ内のすべてのミドルブロックが「尽くされた(burned）」ときに終了する。
【００６２】
このプロセスは、宛先ミドルブロックが与えられると、ソースファブリックブロックをラウンドロビン方式で選択する。次に、このソースファブリックブロックと宛先ミドルブロックをパラメータとして、widest_path帯域幅割当てプロセスを呼び出す。widest_path帯域幅割当てプロセスによって、ＤＥＬＴＡの割当てに成功した場合、allocate_bandwidthプロセスがスタートに戻り、今回は、（ラウンドロビン方式で）他の宛先ミドルブロックを考慮する。そうでなければ、allocate_bandwidthプロセスは、ラウンドロビン方式で他のソースファブリックブロックを選択し、このファブリックブロックからのwidest_path帯域幅割当てプロセスを呼出し、同様のプロセスを経て、最終的に、widest_path帯域幅割当てプロセスが、割当てに成功するか、または、allocate_bandwidthプロセスが、可能なすべてのソーススーパーブロックを経由して循環したことになる。後者の場合、このプロセスは宛先ミドルブロックを「尽くす（burn）」。
【００６３】
上記のように、各「割当て」は、いくつかのソースおよび宛先ミドルブロック間の経路のリストであり、各経路には割当てられた容量がある。allocate_bandwidthプロセスの最終ステップは、これらの量を正規化し、これらをたとえば以下のプロセスを用いて関連する「重み」にする。
【００６４】
このプロセスに対する入力は、割当て容量のリストである。各量は、同一のソースと宛先間の、異なる経路に対する割当てに対応する。出力は、割当て容量当たりの関連する重みのリストである。このプロセスは以下の決定を行なう。リスト内の、「max_allocation」と示された最大割当て容量を発見する。割当て容量ごとに、ceilとして計算された（10 * allocation / max_allocation）重み（１〜１０の規模）を生成する。ここで、「ceil」はceiling（天井）を意味する、すなわち、次に大きい整数値まで切り上げることを意味する。次に、重みを、これら重みの最大公分母（greatest common denominator）（「ＧＣＤ」を用いて正規化する。たとえば、９：６：３は、３：２：１になる。
【００６５】
（ＶＩＩＩ）割当て解除プロセス
本開示のある局面に従うと、物理リンクが故障したとき、このシステムは、このリンクを通るすべての経路の割当て解除を行なってもよい。グラフ内で、物理リンクは、２つのミドルブロック間のエッジの一部であり、したがって、物理リンクの故障は、結果としてエッジ容量の減少を引起す。よって、正しい容量の割当て解除（deallocate）によってこの新たな容量に見合うようにする必要がある。割当て解除（「deallocate_paths_through_link」）は、経路の逆インデックスを用いて、影響を受けた可能性がある経路を発見する。
【００６６】
このプロセスに対する入力は、２つのミドルブロック間のエッジとその新たな容量である。この新たな容量が、リンクを通した現在の割当てを満たすのに十分であれば、このプロセスは終了する。そうでなければ、このプロセスは割当て解除すべき帯域幅の容量を計算する。あるシナリオにおいて、このプロセスは、新たな容量を満たすのに十分な帯域幅のみを割当て解除するので、割当て解除後の残エッジ容量は０である。これに代わるものとして、残容量が０よりも多くなるように、必要分よりも少し多く割当て解除することが可能である。そうすることにより、システムは、毎回割当て解除することなく、その後のいくつかの故障を許容することができる（初回は過剰反応するがそのしばらく後になってからはセーブする）。
【００６７】
影響を受けた通信リンクを通るすべての経路を考慮し、割当容量の降順で分類してもよい。そうする理由は、割当て解除プロセスの影響を受ける経路はできる限り少なくする必要があるからである。経路ごとに、割当容量を更新する、または、経路が完全に空になっている場合はこの経路を割当てから完全に除外する。経路に沿った残リンクおよびノード容量を更新し、それとともに、経路上のソースノードと宛先ノード間の満たされていない要求と逆経路インデックスを更新する。このプロセスは、割当て解除が、影響を受けた通信リンクの新たな容量を満たしたときに、完了する。
【００６８】
（ＩＸ）エッジ容量更新プロセス
エッジ容量（capacities）更新（update）プロセス（「capacities_update_delta」）は、フォームの対（エッジ、容量デルタ（delta））のリストを入力として用いる。このプロセスはリストを評価する。リスト内のエッジごとに、容量が減少していれば、このプロセスは割当て解除（「deallocate_paths_through_link」）を呼び出した後にリンク容量を更新する。リストの作成後、システムは、満たされていない要求があるか否か判断するために検査する。あれば、allocate_bandwidthプロセスを呼び出してインクリメンタルな帯域幅割当てを試みる。なお、リンク容量が変わらない場合または増加した場合、このプロセスは、割当て解除を行なう必要はないが、システムは、場合によっては、割当て解除が行なわれた場合、満たされていない前の要求を満たすことができる。
【００６９】
（Ｘ）ノードおよびリンクアップ／ダウンイベントの処理
ここで、通知を通して受けたイベントのリストは、プロセスに対する入力として扱われる。出力は、真／偽として扱われ得る。出力は、割当て変更があった場合は真であり、そうでなければ偽である。ここで、変更リストは同じエンティティ（リンク／ノード）を２回含むことはないと想定する。イベントの処理順序は重要ではないはずである。システムは、エッジから、このエッジのデルタ容量へのマップを維持する。システムはまた、リンクのセット（Ｐ）を維持する。この一組のリンクとは、システムが、そのエンドポイントスイッチのうちの１つに対する「リンクアップ」イベントまたはノードアップイベントを受けた、一組のリンクである。
【００７０】
「リンクダウン」イベントの場合、システムは、リンク状態をダウンとして示し、このリンクを含むエッジはこの時点で容量が減少しているはずであることを思い出す。この状況において、デルタは、単一リンク容量の量が負である。
【００７１】
「ノードダウン」（スイッチダウン）イベントの場合、ノードに接触するすべての進入または退出リンクについて、リンクは、まだ有用であれば、上記のようにリンクダウンイベントとして処理される。
【００７２】
「リンクアップ」イベントの場合、システムはリンクを上記セットＰに追加する。
「ノードアップ」イベントの場合は、ノードに接触するすべての進入または退出リンクについて、このプロセスはリンクを上記セットＰに追加する。すべてのイベントが処理された後に、このプロセスはセットＰを評価する。Ｐの中のすべてのリンクについて、リンクが有用であれば、このプロセスは、このリンクを含むエッジはこの時点で容量が増加しているはずであることを思い出す。デルタは、単一リンク容量の量が正である。
【００７３】
セットＰを有する理由は、たとえば、「ノードアップ」イベントが、システムがこのノードに接触するリンクを使用できることを必ずしも意味しないことにある。なぜなら、リンクまたはその他端スイッチがダウンである可能性があるからである。上記プロセスの場合、リンクを「有用」にする最初のイベントは、エッジの容量を増大させる。システムは、エッジのリストとこれらのデルタ容量を受けて、上記エッジ容量更新プロセス（capacities_update_delta）を呼び出す。いずれかの割当てが変更されていれば、このプロセスは新たな割当てマップを出力する。
【００７４】
上記プロセスおよび動作は、図２の装置２００等の処理装置、たとえば、ネットワークフロー制御を管理するように構成されたスイッチまたは他の計算装置によって、実現されてもよい。上記のように、装置２００は、１つ以上のプロセッサ２０２と、命令２０６とデータ２０８を格納するメモリ２０４とを含み得る。メモリは、ハードドライブ、キャッシュ、メモリカード、ＲＯＭ、ＲＡＭ、ＤＶＤ、ＣＤ−ＲＯＭ、書込み可能および読出し専用メモリ等の、プロセッサによってアクセス可能な情報を格納することができる、何らかの非一時的なメモリであればよい。
【００７５】
命令２０６は、機械コード等の、プロセッサが直接実行する一組の命令であってもよく、または、スクリプト等の、プロセッサが間接的に実行する一組の命令であってもよい。この点に関して、「命令」、「アプリケーション」、「ステップ」および「プログラム」という用語は、本明細書では区別なく使用できる。命令は、プロセッサによって直接処理されるためにオブジェクトコードフォーマットで格納されてもよく、または、オンデマンドで解釈されるかもしくは予めコンパイルされているスクリプト、もしくは、独立したソースコードモジュールの集合を含む、他の計算装置言語で格納されてもよい。
【００７６】
データ２０８は、命令２０６に従い、プロセッサ２０２によって、取出す、格納する、または修正することができる。たとえば、本明細書に記載の主題は特定のデータ構造によって限定される訳ではないが、データは、コンピュータのレジスタに、または、多数の異なるフィールドおよび記録を有するテーブルとしてリレーショナルデータベースに、またはＸＭＬ文書に格納することができる。データはまた、二値、ＡＳＣＩＩまたはユニコード等であるがこれらに限定されない、計算装置による読取が可能なフォーマットで、フォーマットすることができる。加えて、データは、数字、記述テキスト、所有コード、ポインタ、他のネットワークロケーション等の他のメモリに格納されたデータの参照、または、関連データの計算のために機能が使用する情報といった、関連情報を識別するのに十分な情報を含み得る。
【００７７】
１つ以上のプロセッサ２０２は、市場で入手可能なＣＰＵ等の従来のプロセッサを含み得る。これに代わるものとして、プロセッサは、ＡＳＩＣまたはその他のハードウェアベースのプロセッサ等の専用構成要素であってもよい。図２は、装置２００のプロセッサ、メモリ、およびその他の要素を、同一ブロック内にあるものとして機能的に示しているが、プロセッサ、コンピュータ、計算装置、またはメモリは実際、同一の物理的ハウジング内に格納される場合も格納されない場合もある、複数のプロセッサ、コンピュータ、計算装置、またはメモリを含み得る。たとえば、メモリは、スイッチ２００とは異なるハウジング内にあるハードドライブまたはその他の記憶媒体であってもよい。したがって、プロセッサ、コンピュータ、計算装置、またはメモリに言及する場合、それは、並列動作する場合もしない場合もある、プロセッサ、コンピュータ、計算装置、またはメモリの集合に言及している場合も含まれることが理解されるであろう。たとえば、スイッチ２００は、負荷分散されたサーバファームとして動作する１つ以上のサーバ計算装置を含み得る。さらに、本明細書に記載のいくつかの機能は、１つのプロセッサを有する１つの計算装置上で実行されるものとして示される場合があるが、記載されている主題のさまざまな局面は、たとえば、有線または無線ネットワークを通して情報通信する複数の計算装置によって実現できる。また、動作またはプロセスを特定の順序で示しているまたは説明している場合があるかもしれないが、本明細書で明記されていない限り、このような動作またはプロセスは、他の順序でまたは並列に実行されてもよい。
【００７８】
実施形態の上記説明は、請求項によって定められる本開示を限定するものとしてではなく例示として理解されねばならない。また、本開示の例示（および「〜等の」、「たとえば」、「〜を含む」等のような表現）が、本開示を挙げられた特定の例に限定するものとして解釈されてはならないことが、理解されるであろう。むしろ、上記例は、可能性がある多数の実施形態のうちのいくつかのみを示すことを意図したものである。
【図１】
0006275263.tif 000003
【図２】
0006275263.tif 000004
【図３】
0006275263.tif 000005
【図４】
0006275263.tif 000006
【図４Ａ】
0006275263.tif 000007
【図５】
0006275263.tif 000008
【図６】
0006275263.tif 000009
【図７Ａ】
0006275263.tif 000010
【図７Ｂ】
0006275263.tif 000011