JP2007501563A - 適応フローベースのルーティングを使用する多段データ・ネットワークにおいて動的容量および高可用性を達成するための方法および装置 - Google Patents

Abstract

処理ノードのクラスタから構成される多段ネットワーク内におけるフローについてのパスを決定するための方法とシステム。フロー・パスは、特定のフローのパケットが多段ネットワーク内のクラスタの特定のものを実際にトラバースするか否かの知識なしに決定することができる。種々の実現においては、多段ネットワークのノードを、それぞれの物理インターフェースやそれらにスーパーインポーズされる仮想接続グリッドを介して１または複数の物理ネットワーク・スイッチに結合し、フロー・ルーティング・フレームワークとシステム・マネジメント・フレームワークの使用を介して、それらのノードをいくつかのクラスタにグループ化するように構成することができる。各クラスタのノードは、類似したパケット処理機能を実行するように構成され、クラスタは、物理ネットワーク・インターフェースのトップにオーバーレイされた仮想インターフェースを介して通信結合される仮想ネットワークを通じて相互接続される。
【選択図】図５

Description

本発明は、２００３年８月５日に出願された「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｃｈｉｅｖｉｎｇ Ｄｙｎａｍｉｃ Ｃａｐａｃｉｔｙ ａｎｄ Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ ｉｎ Ｍｕｌｔｉ−ｓｔａｇｅ Ｄａｔａ Ｎｅｔｗｏｒｋｓ Ｕｓｉｎｇ Ａｄａｐｔｉｖｅ Ｆｌｏｗ−ｂａｓｅｄ Ｒｏｕｔｉｎｇ」と題された米国仮出願、番号６０／４９３，０５４に関し、かつその優先権を主張するものであり、当該出願は引用例として、ここに援用される。

本発明は、各段階に特化された機能を実行する種々のパケット・プロセッサを含む多段データ・ネットワークにおける、高可用性および当該ネットワークの全段階にわたる一様な動的容量マネジメントを達成するための、パケット・フローの適応ルーティングのための方法とシステムに関する。

エンタープライズ・データ・ネットワークは、伝統的にハブ、スイッチ、ブリッジ、ルータといったデータ・ネットワーキング装置を含む。これらのネットワークは、年を経て進化しており、さらに、ほんのわずかを例ではあるが、セキュリティから、トラフィック・マネジメント、コンテント・アウェア／アプリケーション−アウェア・データ・ルーティング、アプリケーション・アクセラレーションに至るまで、広範なエンタープライズ・ニーズにサービスを提供する高度に特化されたパケット処理機能を実行する専用アプライアンスを含むように進化を続けている。これらの専用アプライアンスは、通常、業界標準のローカル・エリア・ネットワーク接続ポート（たとえば、Ｅｔｈｅｒｎｅｔ（登録商標）ポート）をサポートする。つまり、これらのアプライアンスの間の相互接続は、ハブ、ブリッジ、スイッチ、ルータ等の伝統的なネットワーク装置を使用して達成される。

その種のネットワークにおいては、データ・トラフィックが１つのアプライアンスから次へと連続的に流れ、したがって多段ネットワークを作る。しばしば、異なるトラフィック・フローが、そのデータ・トラフィックの発信元と宛先またはそれが関連するアプリケーション等の評価基準によって弁別されるとおりに、専用装置の異なるシーケンスによって処理されることが必要となる。ネットワークのオペレータは、このフロー割り当てを、専用装置やそれらの間を相互接続するハードワイヤリングの冗長セットを使用することによって、あるいはデータ・トラフィック・ルータもしくはディスパッチャを多段ネットワークの各段階の始めと終わりに挿入することによって達成している。これらの構成は、柔軟性のないネットワーク・トポロジをもたらし、それらは、本質的に、新しい段階の包含（特に、トラフィック・フローのサブセットのための動的な包含）、任意の１または複数の段階のパケット処理容量の動的な拡張、段階を横切るハードウエアの相互交換性、１日の時間帯、トラフィック状態の変化、１または複数の段階における輻輳等の運用評価基準を基礎とする時間的に異なる瞬間に異なる特化機能を同一のハードウエアが実行する再使用等のサポートにつながらない。しかしながら、今日のエンタープライズ・ネットワークのオペレータは、ネットワーク・セキュリティ要件、トラフィック・フローの量と種類、ビジネス要件、新しいパケット処理機能の導入、あるいは現存するパケット処理機能の変更に応答するためにこの柔軟性を必要としている。

種々の実施態様において、本発明は、処理ノードのクラスタからなる多段ネットワーク内でフローのためのパスを集中化された態様で決定し、多段ネットワークのすべてのクラスタのためのフロー・パスの決定を表すノード選択情報を多段ネットワーク内の各フローのパケット内にエンコードする方法とシステムを含む。しかしながら代替構成においては、フロー・パスが分散された態様で決定される。いずれの場合においても、パケット内のほかのヘッダ情報をノード選択情報に置き換えることによって、あるいはパケットにノード選択情報を追加することによって、ノード選択情報をエンコードすることができる。フローは、そのフローのためのパスの決定に先行して種類ごとに分類される。

フローのパスは、特定のフローのパケットが多段ネットワーク内のクラスタの特定のものを実際にトラバースすることになるか否かの知識なしに決定することができる。各クラスタの個別のノードをパスに含めるための選択は、ラウンド・ロビン選択方法、重み付きラウンド・ロビン選択方法等、あるいは多段ネットワークのノードからの現在の負荷状態についてのリアルタイム情報を基礎とする負荷バランシング評価基準に従って行うことができる。

パケットのための実際のフロー・ルートは、それらのパケットが多段ネットワーク内のそれぞれのフロー・パスをトラバースするとき、ノード−バイ−ノード・ベースで決定することができる。しばしば、これらの実際のフロー・ルートは、あらかじめ決定済みのフロー・パス内に指定されたすべてのクラスタを含まないことになる。それにもかかわらず、それらのパケットによって取られる実際のフロー・ルートに関する情報を、その後に続く新しいフロー・パスの決定において使用することができる。

多段ネットワークのノードは、１または複数の物理ネットワーク・スイッチに、それぞれの物理インターフェースや、それらにスーパーインポーズされる仮想接続グリッド、すなわちフロー・ルーティング・フレームワークとシステム・マネジメント・フレームワークの使用を通じてノードをいくつかのクラスタにグループ化するように構成された仮想接続グリッドを介して結合することができる。各クラスタのノードは、類似のパケット処理機能を実行するように構成され、クラスタは、物理ネットワーク・インターフェースのトップの上にオーバーレイされる仮想インターフェースを介してノードが通信結合される仮想ネットワークを介して相互接続される。いくつかのケースでは、ノードが、それぞれブレード・サーバのシングル・ボード・コンピュータを構成する。

本発明は、種々の方法で実現することができる。たとえば、いくつかの態様は、複数のスタンド−アロン汎用および／または専用コンピュータをノードとして、仮想ローカル・エリア・ネットワーク（ＶＬＡＮ）やジャンボ・フレームをサポートするローカル・エリア・ネットワーク（ＬＡＮ）スイッチを１または複数の物理スイッチとして使用することができる。別の実装は、１または複数のブレード・サーバを使用することができ、そのブレードは、ネットワーク・ノードとして作用する。さらに別の態様は、ブレード・サーバや汎用および／または専用コンピュータの両方を使用することができる。

いずれの構成が使用されるかにかかわらず、ノードのフロー・マネジメント・ソフトウエアを、コンピュータ／ブレード・プロセッサに、仮想接続グリッドによって定義される多段ネットワークを通るデータ・フローの適応ルーティングを行わせるように構成することができる。多段ネットワークの各段階は、１または複数のネットワーク・サービスを実行する類似に構成されたアプリケーションプログラムのクラスタを含む。それに加えて、少なくとも１つのコンピュータ／ブレードは、リソース・マネジメントやプロビジョニング・ソフトウエアをストアすることができ、残りのコンピュータ／ブレードは、これらの残りのコンピュータ／ブレードに、アプリケーション需要、ネットワーク・パフォーマンス、あるいはアプリケーション応答時間によって駆動されるとおりに１または複数のネットワーク・サービスの必要容量の適応プロビジョニングを行わせるように構成されたプロビジョニング・エージェント・ソフトウエアをストアすることができる。プロビジョニングは、グラフィカル・ユーザ・インターフェースを通じた人間のインタラクションを介して、ノードや仮想インターフェースを表すアイコンを使用し、それらの間の相互接続を作成することによって、および／またはプログラム・インターフェースを通じ、ノードや仮想インターフェースの属性を提供するデータ・レコードを使用し、それらの間の所望の相互接続を指定することによって行うことができる。

本発明のさらに別の実施態様は、コンピュータ・ネットワーク内の第１の数のコンピュータ・システムの間の任意の相互接続を可能にするように構成された仮想接続グリッドを設定することを提供する。その際、コンピュータ・システムのそれぞれが、物理ネットワーク・スイッチング・デバイスのポートの上にオーバーレイされる１または複数の仮想ネットワーク（ＶＬＡＮ）の構成の結果として、物理ネットワークの接続メカニズムをエミュレートする第２の数の仮想リンクを介し、１または複数の物理ネットワーク・スイッチング・デバイスのそれぞれのポートに通信結合される。この仮想リンクは、コンピュータ・システムのうちの２つの間のポイント−ツー−ポイント接続（単方向または双方向とすることができる）を提供するケーブル；コンピュータ・システムのルート・コンピュータ・システムとそのコンピュータ・システムの複数のリーフ・コンピュータ・システムの間におけるポイント−ツー−マルチポイント接続（単方向または双方向）を提供するケーブル；それぞれが混交(promiscuous)または非混交モードのいずれかで動作する複数のコンピュータ・システムに対するマルチ−アクセス、ブロードキャスト可能な接続を提供するハブ；ユニキャスト・トラフィック分離を提供しつつ、複数のコンピュータ・システム対するマルチ−アクセス、ブロードキャスト可能な接続を提供するスイッチ；および／または仮想接続グリッドの外側のネットワークと複数のコンピュータ・システムの間におけるトランスペアレントなブリッジ接続であって、仮想接続グリッドの外側のネットワーク内のデバイスと複数のコンピュータ・システムの間におけるインタラクションのためのデータ・パスのトランスペアレンシーを提供するブリッジ接続をエミュレートすることができる。

パケットは、仮想リンクを横切る送信に先行して、それに含まれるそのオリジナルのヘッダ情報がそのパケットのエンドに追加されるように修正し、新しいヘッダ情報でオリジナルのヘッダ情報の置き換えができるように修正することができる。新しいヘッダ情報は、仮想接続グリッド内におけるそのパケットのためのフロー・パス決定情報を含むことができる。それに加えてコンピュータ・システムのうちのいずれがそのパケットを送信しているかを識別するように機能する認証情報をパケットに追加することができる。この種の場合においては、コンピュータ・システムの１つにおける受信時に、パケットのオリジナルのヘッダ情報をリストアすることができる。

さらに別の実施態様は、多段ネットワーク内でフローのためのパスを集中化された態様で決定すること、フロー・パスとノード選択情報をフローのそれぞれの各パケット内にエンコードすることを提供する。各フローのためのノード選択は、多段ネットワークの各クラスタについて、それぞれのフローが実際にいずれのパスを取るかについての知識を伴わずに行うことができる。フロー・パスとノード選択情報は、前述した態様でパケット内にエンコードし、あるいはそれに追加することができる。フローのためのパスの決定に先行して、パケット内にある情報のセットを使用し、またネットワーク管理者によって設定された評価基準に従って分類すること、ネットワーク管理者によって設定されたポリシーを基礎としてフロー・パスを割り当てることができる。類似の操作を、分散された態様で、多段ネットワークの各ノードにおいて実行することができ、その場合には、ノード選択情報だけがそれぞれのフローの各パケット内にエンコードされていればよい。

さらに別の実施態様は、類似のアプリケーション機能を有するノードのクラスタにノードがグループ化された多段ネットワークのノードにおいて両方向において、全体のフローを複製すること、その複製フローが作られたオリジナルのフローのためのオリジナルのフロー・パスとは異なる、結果として得られた複製フローのためのフロー・パスを指定することを考慮に入れる。複製フローは、複製フローとオリジナルのフローの両方を受信する終了ノードにおいて終了し、終了ノードは、分析のために複製フローとオリジナルのフローの内容を記録する。

本発明は、限定ではなく例を示す形で添付図面内に示されている。

ここでは、各段階において特化された機能を実行する種々のパケット・プロセッサ（ノード）を含む多段データ・ネットワーク内におけるパケット・フローの適応ルーティングのための方法とシステムについて述べる。これらの方法とシステムは、向上したプロセッサの可用性を提供し、ネットワークの全段階にわたる一様な動的なプロセッサ容量マネジメントを提供する。またここでは、この方法を実施し、多段ネットワークの各処理段階に必要な特化された機能のいずれかを展開するように相互交換可能に使用することのできる汎用コンピュータ・ハードウエアを使用する装置について述べる。その種の装置とほかの特化された装置、すなわち多段ネットワークの１または複数の段階に必要なパケット処理機能を実行するように特別に設計された装置を組み合わせ、当該特化された装置を採用する段階を含むネットワーク全体を通じて高い可用性と動的容量マネジメントを達成するシステムがここに述べられている。集合的に、これらの方法とシステムは、前述した問題に対する包括的かつスケーラブルなソリューションを可能にする。

このシステムの主要コンポーネントには、次のものが含まれる。
ａ．仮想接続グリッド
ｂ．サービスとシステム・ノード
ｃ．フロー・ルーティング・フレームワーク
ｄ．システム・マネジメント・フレームワーク
しかしながらここで想起する必要があるが、これらのコンポーネントは例示のみとしてここに与えられている。言い換えると、これらのシステム・コンポーネントについて現時点で好ましい種々の具体例が、本発明の中に織り込まれているコンセプトを読者に習熟させるために述べられている。これらの記述は、本発明の方法と特徴を採用する多段ネットワークのすべての可能な例という意味において包括的ではなく、そのように考えるべきでもない。その逆に、ここに記述され、示されている説明は、本発明を作り、使用する方法ならびにプロセスの完全、明瞭、簡潔な説明を提供するものとして見るべきであり、本件発明者らが当該発明者らの発明とすると特に指摘し、かつ明瞭に主張していると見られるべきは、これに付随する特許請求の範囲である。

本発明の明瞭な説明を提供するという目標達成の一助として以下の用語をここで使用する。
ｉ．ＩＮＯＤＥは、イングレス／エグレス・ノード(ingress/egress node)である。
ii．ＡＮＯＤＥは、アプリケーション・ノードである。
iii.ＭＮＯＤＥは、マネジメント・ノードである。
iv．ＦＮＯＤＥは、フロー・マネジメント・ノード（たとえば、後述するようにフロー・マネジメント機能を実行するように構成された専用ノード、ＩＮＯＤＥ、またはＡＮＯＤＥ）である。
ｖ．「フロー」は、アプリケーション・コンテキスト（たとえば、トランザクション、アプリケーション・セッション等）内の２つのエンティティ（たとえば、クライアントとサーバ）の間において交換されるパケット列である。
vi．「フロー・マネジメント・モジュール」は、外部ネットワークに接続されたすべてのＦＮＯＤＥ内に常駐する。
vii.「フロー分類」は、パケットの多重ストリーム内において個別のフローが識別されるプロセスである。
viii.「フロー・パス」は、アプリケーション・クラスタ（または仮想ネットワーク）に関してネットワーク・エンティティがパケットを処理するシーケンスを定義する。
ix．「フロー・ルート」は、アプリケーション・クラスタ（または仮想ネットワーク）内の特定のノードに関してネットワーク・エンティティがパケットを処理するシーケンスを定義する。
ｘ．「フロー・パス割り当て」は、静的または動的評価基準を基礎として特定パスにフローが向けられるプロセスである。
xi．「フロー複製」は、フローの正確な複製（クローン）が作られ、その複製フロー用に明瞭なフロー・パスが作られるプロセスである。
xii.「フロー分配」は、ノードが、特定のフローの全パケットが転送される次のホップ・ノードを、たとえば機能的等価ノードのリストから選択するプロセスである。次のホップ・ノードの選択は、集中化または分散が許される。
xiii.「適応ルーティング」は、次のホップの決定が動的に変化するメトリクス、たとえばノードのリソース利用等を基礎とするフロー・ルーティングの種類である。
xiv.「静的ルーティング」は、次のホップの決定がパケット・パラメータ、たとえばフローのＩＤとパケットの種類等を基礎とするフロー・ルーティングの種類である。
xv．「集中化された次のホップの選択」は、フロー・マネジメント・モジュールが、たとえばフローのための入口ポイントとして作用するＩＮＯＤＥ内で、そのフローのためのエンド−ツー−エンド・ルートをセットアップするプロセスである。
xvi.「分散された次のホップの選択」は、各ノードが、次のホップとして使用するノードのローカルな決定を行うプロセスである。
xvii.「クラスタＩＤ」は、ＭＮＯＤＥによってＡＮＯＤＥ、ＦＮＯＤＥ、ＩＮＯＤＥの各クラスタに割り当てられる一意的な番号である。
xviii.「ノードＩＤ」は、ＭＮＯＤＥによってクラスタの各ノードに割り当てられる番号である。この番号は、そのクラスタ内において一意的である。いったん割り当てられると、このノードＩＤは、そのノードがそのクラスタの外に出されるまで変更されない。
xix.「トポロジ」は、システム内のすべてのクラスタ、それらのクラスタ内の現在アクティブの全ノード、クラスタ間の相互接続のセットである。「トポロジ」は、ノードが故障したときに変化し、またノードのリスタート時に再び変化する。「トポロジ」は、管理者がフロー・パスを修正し、あるいはそれに対する追加もしくは削除を行うことによっても変化する。
xx．「トポロジＩＤ」は、ＭＮＯＤＥによってシステムのトポロジに割り当てられた番号である。

Ａ．仮想接続グリッド
ここで述べている接続グリッドと結果として得られるフロー分配技法について理解するためには、本発明のゴールの１つが複数のネットワーク・ノード間における管理されたトラフィック・フローのためのフレームワークを作ることであるとの理解が一助となる。言い換えると、過去に行われているように特化されたネットワーク装置とそれらの間のハードワイヤリング相互接続の冗長セットを組み立てること、あるいはデータ・トラフィック・ルータもしくはディスパッチャを多段ネットワークの各段の始まりと終わりに挿入することに代えて、本発明は、柔軟なオーバーレイをネットワーク・ノードのトップに作成することを求めており、当該オーバーレイは、異なるフローのニーズと、現在のネットワーク状態に従った動的フロー・パス割り当てやルーティングを考慮している。したがって、仮想接続グリッドは、１または複数の物理的なローカル・エリア・ネットワーク（ＬＡＮ）スイッチ（たとえば、Ｅｔｈｅｒｎｅｔスイッチ）の直上にソフトウエア的に構成される論理的なアブストラクションである。

図１を参照すると、接続グリッド１０は、中央仮想スイッチ１２、ノード１４ａ、１４ｂ、１４ｃ、１４ｄ（ほか）からなり、各ノード１４は、１または複数の仮想インターフェース１６を使用してグリッド１０に接続されている。この仮想インターフェース１６は、ノード１４によってサポートされる物理ＬＡＮインターフェース１８の直上にソフトウエア的に構成される論理的なアブストラクションである。物理インターフェース１８は、物理ＬＡＮスイッチ２０ａ、２０ｂ等に対する接続を提供し、これらは集合的に、仮想スイッチ１２等の１または複数の形式の仮想接続によって張られている。

仮想スイッチ１２は、完全なメッシュ接続を提供し、すべてのノードがそのスイッチによって管理された仮想接続グリッド１０の一部である限り、任意のノード１４を１または複数のほかのノードに接続することができる。後述するが、ノード１４間における異なる仮想リンクの使用を通じて、ほかの形式の接続も可能である。各接続フォーマットは、グリッドを仮想ネットワーク２２ａ、２２ｂ、２２ｃ等に論理的にパーティション分けするために使用可能なコマンドならびにコントロール・メッセージのセットをサポートする。各ノード１４は、仮想インターフェース１６を作り、それらを仮想ネットワーク２２に接続するために使用することのできるコマンドとコントロール・メッセージのセットをサポートする。その後は、仮想ネットワーク２２を単方向もしくは双方向トラフィック・フローのために使用することができる。

この態様において仮想ネットワーク２２を使用するためには、ＬＡＮスイッチ２０がＶＬＡＮタグ付けをサポートすることが好ましい。しかしながらスイッチ２０がその種のサポートを提供しない場合には、その種のサポートを提供する外部スイッチに対して接続を１対１対応でエクスポートすることができる。物理的に、各ノード１４は、ＬＡＮスイッチ２０上のポートに接続されており、類似の処理機能のノードは、クラスタ内にまとめてグループ化される。クラスタ間のパスが必要とされる場合には、ＶＬＡＮタグ付けが使用されて、それらの間に一意的な仮想リンクが作られる。このように仮想リンクは、ノードのクラスタ間における論理的な接続を構築し、仮想ネットワーク２２は、所望のクラスタ接続を提供するために必要とされる異なる仮想リンクを表す。

単一の仮想ネットワークが使用され、すべてのネットワーク・トラフィックがそれを通過するシステムを構築できることにも注意する必要がある。しかしながらこのソリューションは、ノード／クラスタのすべてが必ずしもすべてのネットワーク・トラフィックの処理を必要としないことから最適にはほど遠い。そのためノードは、不必要なパケットを受け取り、かつドロップすることを継続的に行うようになり、それによって処理リソースを無駄にすることになる。

そこでそれに代えて、各ノード１４に、そのノードの接続ニーズに従って異なる仮想ネットワーク２２に対して接続するための異なるＶＬＡＮタグを伴う１または複数の仮想インターフェース１６を割り当てる。これらのタブによって表されるＶＬＡＮは、各物理インターフェース１８上においてノードが、１または複数の送信ＶＬＡＮと１または複数の受信ＶＬＡＮを有して終わるように単方向（すなわち、送信または受信の両方ではなく、いずれか一方）態様で使用される。このアブストラクションは、ノードのアプリケーション・レイヤ・ソフトウエアから隠されており、それらは単一のＥｔｈｅｒｎｅｔポートを従来の態様で見ることになり、トラフィックの分離が考慮される。

このように、接続グリッド１０は、ノード１４間の仮想リンクのためのフレームワークを提供する。種々の種類の仮想リンクがサポートされており、次に例を挙げる。
ａ．外部リンク。外部リンクは、１または複数のノード１４とスイッチ２０上の外部ポート（たとえば、ユーザによって指定される）の間のリンクと考えることができる。外部ポートは、ＶＬＡＮタグ付きまたはタグなしモードで動作することができる。外部インターフェースがタグ付きでない場合には、それが接続されるスイッチ２０上のポートが、そのインターフェースに割り当てられた一意的なＶＬＡＮを伴って構成される。それ以外であれば、ポートがタグ付きモードで動作し、ＶＬＡＮを通過させる。したがって、複数の外部リンク（すなわちサブネット）が単一の外部ポートにわたってサポートされることになる場合には、ＶＬＡＮタグ付きモードが必要である。
ｂ．仮想ケーブル。仮想ケーブルは、２つのノード１４の間もしくはノードのクラスタの間、またはノードとノードのクラスタの間におけるポイント−ツー−ポイント・リンクである。ノード・クラスタについては詳細を後述する。
ｃ．仮想スイッチ。前述したとおり仮想スイッチ１２は、すべてのメンバに対するマルチキャスト／ブロードキャスト配信、周期的フラッド、ユニキャスト分離を含めて、仮想リンクのすべてのメンバ・ノードの間における従来的なスイッチ付きＥｔｈｅｒｎｅｔ接続を提供する。
ｄ．仮想ハブ。仮想ハブは、すべてのメンバ・ノード１４の間にハブ類似の接続を提供する。仮想ハブの１または複数のメンバ・ノードは、「仮想混交モード」で動作するように構成可能であり、これらのノードが、その仮想ハブ上のほかのすべてのノードによって送信されたすべてのパケットを受信することを可能にする。従来のＥｔｈｅｒｎｅｔスイッチは、そのスイッチの１または複数のポート上に構成されるＶＬＡＮの恣意的なセットについて、その種のユニキャスト・トラフィックの「スヌーピング」を提供しない。非混交モードのノードの場合には、ノードのメディア・アドレス・コントローラ（ＭＡＣ）アドレスに整合しないユニキャスト・パケットが無視される。その種の仮想ハブの使用は、以下に説明するノードのクラスタリングを考慮している。

種々の種類の仮想リンクが種々の形式のノード接続を提供し、それには次のものが含まれる。
ａ．指定のノード間における「マルチポイント−ツー−マルチポイント」（または完全メッシュ）接続。図２Ａに示されているが、この種類の接続は、マルチキャスト／ブロードキャスト、周期的フラッド、ユニキャスト分離を含めて、仮想リンクのすべてのメンバ・ノードの間に標準的なスイッチ付きＥｔｈｅｒｎｅｔ接続を提供する。マルチポイント−ツー−マルチポイント接続は、コントロール・パスのために使用されることがある。
ｂ．指定ルート・ノードと１または複数のリーフ・ノード（リーフ−ツー−リーフ接続は妨げられる）の間における「ポイント−ツー−マルチポイント」（またはスター）接続。図２Ｂに示されているが、ポイント−ツー−マルチポイント仮想リンクは、指定ルート・ノードとそのリンクに割り当てられている残りのノード（リーフ・ノードになる）の間におけるフローの交換を可能にする。この種類の仮想リンクは、リーフ・ノードがほかのリーフ・ノードからのブロードキャストまたはマルチキャスト・パケットのフラッドに遭遇しないという点において標準的なＶＬＡＮとは異なる。「仮想ハブ」機能は、ポイント−ツー−マルチポイント仮想リンクのオプション・モードである。仮想ハブ・モードにおいては、宛先ＭＡＣアドレスがユニキャスト、マルチキャスト、またはブロードキャストであるか否かによらず、ルート・ノードからのすべてのパケットがリーフ・ノードに対して複製される。これは、１または複数のリーフ・ノードが、クラスタ内のほかのリーフ・ノードによって処理されているフローの「シャドウ」処理もしくはモニタリングを（たとえば、バックアップ能力を提供するために）行う能力を提供する。トランスペアレントなクラスタリングは、この機能を利用する。
ｃ．３つのノード間における「ポイント−ツー−デュアルポイント」（または弾性リンク）接続。この場合、１つのノードがルート・ノードとして指定され、第２のノードがプライマリ・ノードとして指定され、第３のノードがスタンバイ・ノードとして指定される。すべてのノードが動作可能である場合、ルートとプライマリ・ノードの間において接続がイネーブルされる。プライマリ・ノードが故障すると、ルートとスタンバイ・ノードの間における接続がイネーブルされる。図２Ｃを参照するとわかるが、この種類の仮想リンクは、プライマリ・ノードが故障した場合のスタンバイ・ノードへの自動切り替えを提供する。
ｄ．「クラスタ化リンク」。クラスタ化リンク（図２Ｄ参照）は、ルート・ノードから下流ノードのクラスタに対する単方向フローをサポートする。ルート・ノードから送信されたすべてのパケットは、クラスタ内のすべてのノードに対して複製される。ルートから送信されたユニキャスト・パケットがあれば、すべてのクラスタ・ノードに対してブロードキャストされる。受信ノード内のパケットのイングレス処理が、宛先フィールド内にあるそのノードの固有ＭＡＣアドレスを置換する（このテクニックは、パケット内に、そのアドレスがイングレス上において置換される必要があることを示すユニキャスト・インジケータが埋め込まれていることを必要とする）；マルチキャストとブロードキャスト・パケットは変更されない。
ｅ．「クラスタ接続」。図２Ｅに示されているように、クラスタと隣接するノードの間の接続は、クラスタ化された仮想リンクを使用する。
ｆ．複製リンクも使用することができる。図２Ｆに示されているが、複製リンクは、任意の実在する一方向リンク上に「タップ」を配置する能力を提供する。複製リンク上においてユニキャスト・パケットを受信するノードは、宛先ＭＡＣアドレスフィールド内にそれ自身のＭＡＣアドレスを見つけることになる（クラスタ化ノードに類似）。

すべての仮想リンクは、互いに離隔され、かつシステム内のほかの内部と外部インターフェースから離隔されている。仮想リンクは、マネジメント・コンソール（後述）を介し、たとえばグラフィカル・ユーザ・インターフェース（ＧＵＩ）を使用してノードとノードのクラスタの間の接続を表すアイコンを単純にドラッグ・アンド・ドロップすることによって作ることができる。また仮想リンクは、ノードと仮想インターフェースの属性を提供するデータ・レコードを使用し、それらの間における所望の相互接続を指定することによってプログラム的に作ることもできる。仮想リンクは、いったん作られるとデータ・ストア（たとえばデータベース）にストアされる。データ・ストアは、仮想リンクについての情報（たとえば、リンクの種類、リンクＩＤ、ＶＬＡＮ ＩＤ等）のレポジトリとして機能する。ＭＮＯＤＥにある仮想リンク・マネージャ・アプリケーションに、このデータ・ストアの維持、接続グリッド１０内の仮想リンクの構成のマネジメントの責任を持たせることができる。その場合、各ノード１４の仮想リンク・エージェントは、仮想リンク・マネージャと通信し、それぞれの仮想リンクをそれに応じて構成し、削除することができる。

説明が適当と見られるもう１つの仮想リンクの形式は仮想プローブであり、それを使用して、ネットワーク分析またはリモート・モニタ（ＲＭＯＮ）アプリケーション等の診断アプリケーションのための接続を提供することができる。図２Ｇは、２つの種類の仮想プローブ接続を示している：すなわち、リンク・プローブとインターフェース・プローブである。この図において各ノード１４ｅ、１４ｆ、１４ｇは、１または複数の仮想リンク・インターフェース（ＶＬＩ）１６をサポートする。仮想ハブ１３ａ、１３ｂは、ノードＮ１とＮ２、ノードＮ２とＮ３をそれぞれ相互接続するために使用される。

仮想プローブは、コレクタ・ノード１４ｈと、１または複数のプローブ・ポイント１９からなる。プローブ・ポイントを仮想リンク上に配置してリンク・プローブ・ポイント１９ａを作り、あるいは仮想リンク・インターフェース上に配置してインターフェース・プローブ・ポイント１９ｂを作ることができる。複数のプローブ・ポイントを構成して、複数インターフェース・ストリーム修正の可能なアプリケーションをサポートすることも可能である。

リンク・プローブ・ポイント１９ａは、仮想リンク上にプローブ・ポイントを配置することによって構成され、イン−ラインまたはハブ−スタイルのプローブをシミュレーションする。それにおいてはすべてのインターフェースによって送信されるすべてのパケットが捕捉される。インターフェース・プローブ・ポイント１９ｂは、仮想インターフェース１６上にプローブ・ポイントを配置することによって構成され、ホスト−ベースの「シム」プローブをシミュレーションする。それにおいてインターフェースから受信されるすべてのパケットと、インターフェースへ送信されるすべてのパケットが捕捉される。コレクタ・ノード１４ｈは、クライアント・アプリケーションに対してＲＭＯＮプローブ等の単一のデータ・リンクを提供し、それが、プローブされるすべての仮想リンクに接続されたハブ上にコレクタ・ノード１９があるかのように混交モードにおける物理的なネットワーク・インターフェースとして動作する。１つのアプリケーションにおいては、コレクタ・ノードのインターフェースが、すべての収集済みパケットを、それらが外部インターフェースとアプリケーションに対して配信されたとおりに（すなわち、パケットのオリジナルのＭＡＣアドレスをリストアし、挿入されたフロー記述子（フロー記述子については後述を参照）があれば削除することによって）配信する。代替アプリケーションにおいては、インターフェースを、「生モード」で構成することが可能であり、それにおいてはパケットがプローブ・ポイント１９内の仮想リンク・ドライバによって送信および／または受信されたとおりに配信される。ノードへの、ノードからのパケット・フローのプロービングのために、プローブ・ポイント１９をクラスタの個別のメンバ・ノード上に配置することができる。

上記の接続を提供するために、ほかのリソースとのコンフリクトが回避されるように仮想リンクに割り当てられるＶＬＡＮ識別子（ＶＬＡＮ ＩＤ）を管理しなければならない。たとえば、タグ付きモードで動作している外部リンク（後述を参照）の場合においては、ルータ等の外部デバイスとのコンフリクトを回避するためにＶＬＡＮ ＩＤのユーザ割り当てが必要とされることがある。それ以外では、ＶＬＡＮ ＩＤをＶＬＡＮ ＩＤの予約済みブロックから選択して、ＶＬ種類もしくは業界標準規約に従って割り当てることができる。

ＶＬＡＮマネジメントに加えて、データ・パスのトランスペアレンシーを達成するために、外部リンクのためのＭＡＣアドレス、仮想ケーブル、仮想ハブを管理しなければならない。ＭＡＣアドレス・マネジメントは、ネイティブに動作する仮想スイッチ用には必要ない。いくつかの実施形態においては、仮想ハブを、それがＭＡＣアドレス・マネジメントに到来したとき、仮想ケーブルと同一の態様で扱うことができる。次に示す表は、本発明の各種の実施形態において使用することのできるＭＡＣアドレスの例を提供する。

ＭＡＣアドレスは、ノード１４へのパケットのイングレスとそこからのエグレスの間に、仮想ハブ上の仮想インターフェース１６によって処理される。パケットのイングレスの間においては、仮想インターフェース１６がすべてのパケットを、仮想リンクが外部リンクである場合には、変更せずに外部リンク・ブリッジ・モジュールに対して配信する。内部リンクについては、あらゆるアプリケーションに対するパケットの配信に先行して仮想インターフェース１６がオリジナルのパケット・アドレスを、そのパケットのフロー記述子からＭＡＣヘッダにコピーし（アプリケーションが、いずれかのレイヤ２機能を実行している場合）、フロー記述子を隠す。フロー記述子は、仮想リンク接続とフロー・マネジメントに関連付けされたネットワーク・パラメータを分配するためのイン−バンド・メカニズムを提供する識別子であり、詳細については後述する。

パケットのエグレスの間、外部リンクにおいては、仮想インターフェース１６がオリジナルのＭＡＣアドレスをパケットのフロー記述子からコピーし、それをパケット・ヘッダに追加する。内部リンクの場合には、仮想インターフェース１６が発信元アドレス用にＮＩＣアドレスを使用することになり、宛先アドレスを「ブロードキャスト・アドレス」にセットする。要求された発信元アドレスと宛先アドレスもまた、パケットのフロー記述子にコピーされる。

Ｂ．サービスおよびシステム・ノード
図３を参照すると、各ノード１４が概して以下を含む。
ａ．ハードウエア・プラットフォーム２４（たとえば、サーバまたはワークステーション等の汎用コンピュータ、あるいは特化されたハードウエアを伴う専用コンピュータのいずれか）；
ｂ．仮想接続グリッドが実装されるハードウエアを構成する１または複数のＬＡＮスイッチへの接続に使用される１または複数のＬＡＮ（たとえばＥｔｈｅｒｎｅｔ）インターフェース（物理ポート１８と関連ドライバ２６からなる）；
ｃ．オペレーティング・システム２８（たとえば、Ｗｉｎｄｏｗｓ（登録商標）、Ｓｏｌａｒｉｓ^TM、Ｌｉｎｕｘ等の汎用コンピュータ・オペレーティング・システム、または特化された機能を伴う専用オペレーティング・システム）；
ｄ．ノード１４を仮想接続グリッドに接続する１または複数の仮想インターフェースを生成するドライバ（１または複数）３０ａ、３０ｂ、３０ｃ等；
ｅ．ノード１４から多段ネットワーク内の次段の別のノードへのトラフィック・フローのルーティング、すなわち負荷共有、パフォーマンス、容量、可用性、トラフィック分類等に関係する種々の静的、動的ポリシーを基礎として適応的になされるルーティングを実行する特化されたソフトウエア（たとえば、フロー・ルーティング・モジュール３２）；
ｆ．「イングレス」／「エグレス」、「アプリケーション］、および／または「マネジメント」ノードによって要求される特化された機能を配信するアプリケーション・ソフトウエア３４；
ｇ．ノード１４に向けられたコマンドとコントロール・メッセージを受信し、それに作用を及ぼすマネジメント・エージェント（たとえば、ノード・マネジメント・モジュール３６）。

前述したとおり、接続グリッド１０の外部のネットワークへのトラフィック・フロー／ネットワークからのトラフィック・フローのルーティングに関係する機能を実行するシステム・ノードは、「イングレス／エグレス・ノード」またはＩＮＯＤＥとして知られる。ＩＮＯＤＥは、しばしば多段ネットワークを通るトラフィック・フローのルーティングにもかかわる。多段ネットワークの各段において要求される１または複数の特化されたパケット処理を実行するサービス・ノードは、「アプリケーション・ノード」またはＡＮＯＤＥとして知られる。フロー・マネジメント機能（接続グリッド内におけるフロー・ルーティングのため）を実行するように構成されたＩＮＯＤＥおよび／またはＡＮＯＤＥは、集合的にＦＮＯＤＥと呼ぶことができる。仮想接続グリッド、すべての仮想リンク、イングレス／エグレス・ノード、アプリケーション・ノードを含む全システムのコマンドとコントロールに関係する監視機能を実行するシステム・ノードは、「マネジメント・ノード」またはＭＮＯＤＥと呼ばれる。単一ノードが、ＩＮＯＤＥ、ＡＮＯＤＥ、またはＭＮＯＤＥに関連する機能の組み合わせを含むこともできる。いくつかのシステムにおいては、たとえばＩＮＯＤＥ上においてシステム・マネジメント機能、または１または複数のＡＮＯＤＥ上においてイングレス／エグレス機能を実装するとより効率的となることがある。

ＩＮＯＤＥは、仮想接続グリッド１０に入るトラフィックとそれを離れるすべてのトラフィックのための入口および／または出口ポイントとして作用する。グリッドに接続されるＩＮＯＤＥの数は任意とすることができる。各ＩＮＯＤＥは、１または複数の外部ネットワークに関連付けされる。外部ネットワークは、ＥｔｈｅｒｎｅｔＬＡＮにおけるような物理的なもの、あるいはＥｔｈｅｒｎｅｔＬＡＮの上に実現されるＶＬＡＮにおけるような仮想的なものとすることが可能である。

ＩＮＯＤＥ、または冗長性のためにクラスタとして構成される２もしくはそれを超える数のＩＮＯＤＥは、多段ネットワークの初段および最終段として働く。同一ＩＮＯＤＥまたはその種のノードのクラスタが、両方の機能（トラフィック・フローの入口および出口）を実行すること、あるいは異なるＩＮＯＤＥまたはその種のノードのクラスタが、一方もしくは他方の機能の実行に使用されるということは可能である。ＩＮＯＤＥは、トラフィック・フローを外部ネットワークに接続された適切な次のホップ・デバイスに振り向けるために必要なルーティング能力（静的ルーティングまたは１または複数のルーティング・プロトコル等−−ＲＩＰ、ＲＩＰｖ２、ＯＳＰＦ、ＩＧＲＰ、ＥＩＧＲＰ、ＢＧＰ、その他）を含むこともできる。これらのルーティング・プロトコルは、ＡＮＯＤＥ上における外部ネットワークからのパケット／外部ネットワークへのパケットのイングレス／エグレスと分離されるサービスとして実現することも可能である。

ＩＮＯＤＥは、「レイヤ２」モードでも動作可能であり、各外部ネットワークを一意的な内部仮想ネットワークにブリッジする。これは、任意の既存ネットワーク・トポロジ内への仮想接続グリッドのトランスペアレントな包含を考慮している。

ＡＮＯＤＥは、多段ネットワーク内の特定の段階のために指定された特化された機能を実行する。ＡＮＯＤＥのクラスタは、多段ネットワークの特定の段階の中で同一の特化された機能を実行する、２またはそれを超える数のＡＮＯＤＥを指定することによって作ることができる。その種の機能の例として、パケット・フィルタ、ファイアウォール、ＶＰＮサービス、侵入検出システム、ウェブ・フィルタリング、エンタープライズ・ネットワーク内に含まれる任意のパケット処理機能を挙げることができる。あるクラスタのすべてのメンバＡＮＯＤＥは、機能的に等価と見なされる。換言すれば、多段ネットワーク内の特定の段階のために指定されたトラフィック・フローは、そのクラスタの任意のメンバにルーティングすることができる。

ＭＮＯＤＥは、仮想インターフェース１６、仮想ネットワーク２２、仮想接続グリッド１０、グリッドに接続されているノード１４の構成、マネジメント、モニタリングに関係する特化された機能を実行する。またＭＮＯＤＥは、トラフィック・フロー・モニタリング機能、たとえばスループット、待ち時間、利用、エラー・レートといったシステム−ワイドなフロー統計、およびノードごとの待ち時間、ノードごとのスループット、ノードごとの利用、ノードごとのエラー・レートといったノード固有のフロー統計等を収集し、エクスポートする機能も実行する。

図４は、本発明に従ってノードと仮想接続グリッドを使用して構成された一例の多段ネットワーク４０の論理的な例示を提供する。特にこの例示は、以下からなる４段ネットワークを示している。
ａ．３つのＩＮＯＤＥ（冗長構成）。ＩＮＯＤＥ ＩＡ−１とＩＣ−１は、それぞれ１つの外部ネットワークに接続しており、ＩＮＯＤＥ ＩＢ−１は、２つの外部ネットワークに接続している。
ｂ．３つのアプリケーション・クラスタＡＡ、ＡＢ、ＡＣ。アプリケーション・クラスタＡＡは２つのＡＮＯＤＥ（ＡＡ−１、ＡＡ−２）を有し、アプリケーション・クラスタＡＢは３つのＡＮＯＤＥ（ＡＢ−１、ＡＢ−２、ＡＢ−３）を有し、アプリケーション・クラスタＡＣは３つのＡＮＯＤＥ（ＡＣ−１、ＡＣ−２、ＡＣ−３）を有している。これらのクラスタのすべてのノードは、同一のアプリケーション機能を実行する。
ｃ．２つのＭＮＯＤＥ（ＭＡ−１、ＭＢ−１）。
ｄ．仮想接続グリッド内側の５つの仮想ネットワーク（ＶＮ−１、ＶＮ−２、ＶＮ−３、ＶＮ−４、ＶＮ−５）。
ｅ．各外部ネットワークがＩＮＯＤＥを介して仮想接続グリッドに接続している４つの外部ネットワーク（ＥＮ−１、ＥＮ−２、ＥＮ−３、ＥＮ−４）。ＥＮ−１はＩＡ−１を介し、ＥＮ−２およびＥＮ−３はＩＢ−１を介し、ＥＮ−４はＩＣ−１を介してそれぞれ接続している。

これらのネットワークの４つの段階は、次のように考えることができる：第１段はＩＮＯＤＥ ＩＡ−１とＩＢ−１を含み、第２段はアプリケーション・クラスタＡＡまたはＡＢを含み、第３段はアプリケーション・クラスタＡＣを含み、第４段はＩＮＯＤＥ ＩＣ−１を含む。仮想ネットワークＶＮ−５とそれに接続されたＭＮＯＤＥ（複数）は、外部ネットワーク間のデータ・トラフィックがこの仮想ネットワークを流れないことから、この多段ネットワーク内の段階を表さない。それよりもむしろ仮想ネットワークＶＮ−５は、多段ネットワーク４０の種々のＩＮＯＤＥとＡＮＯＤＥに対するコマンドおよびコントロール・パス（破線の垂直リンクによって例示）を提供する。ノード対ノード通信は、コントロール・メッセージのセットを介して達成され、それらを使用してノード発見、ノード・ステータスと状態の問い合わせ、ノード状態の分配、ノード状態と統計データの収集または配布、フロー・ルートの分配、フロー固有の統計収集と配布といったことに使用することができる。

仮想ネットワークＶＮ−１〜ＶＮ−５は、前述した仮想接続グリッドを使用して作られる。その後多段ネットワーク４０のノード間の通信チャンネルを提供するのは、これらの仮想ネットワークである。これらの通信チャンネル（本発明に関しては仮想リンクと呼ばれる）にわたって送信されることになる情報は、フローに組織化されるパケットからなる。パケットはどのノードにもルーティングできるわけではない。それに代わりフローが保存されなければならず、それこそが以下に述べるフロー・ルーティング・フレームワークのタスクである。

Ｃ．フロー・ルーティング・フレームワーク
フローは、アプリケーション・コンテキスト内における２つのエンティティ間で交換される一連のパケットであり、いくつかの関連接続から構成することができる。これらのエンティティは、通常、クライアントとサーバ、２つのピア・アプリケーション、あるいはセンダと１または複数のレシーバである。アプリケーション・コンテキストは、単純なトランザクション（単一の要求と応答シーケンスからなる）、アプリケーション・セッション（１または複数の単純なトランザクションからなる）、または多重化されたパケットのストリームからフローのパケットの特定シーケンスの選出を助ける任意の評価基準とすることができる。多段ネットワークのいずれのノードが特定フローのパケットを処理することになるかを決定するプロセスは、「フロー・マネジメント」と「フロー・ルーティング」の両方に関係する。したがって、仮想接続グリッドのフロー・ルーティング・フレームワークは、フロー・マネジメント・モジュールとフロー・ルーティング・モジュールを含む。

フロー・マネジメントは、本発明に関して使用する場合、「フロー分類」と「フロー・パス割り当て」に関係する。その場合にフロー・マネジメント・モジュールは、フロー分類もしくは識別、各フローについて仮想接続グリッドを通る特定フロー・パス（システム・オペレータ定義のポリシーを基礎として作られる）の割り当てを行うソフトウエア・モジュール（多段ネットワークの特定ノード内に常駐）となる。

フロー分類は、多重化されたパケットのストリーム内において個別のフローが識別されるプロセスである。言い換えれば、フロー分類は、１または複数のパケットのシーケンスを基礎としてフローを識別することからなる。しばしば、アプリケーション・コンテキスト（たとえば、ＴＣＰセッション、あるいはＨＴＴＰ要求−応答シーケンスに類似した周知のフローの場合）は、フローを識別するために使用する評価基準を指定する。別のケースにおいては、ユーザが、フローを識別するための規則の恣意的なセット（ポリシーとしても知られる）を定義することができる。これらのポリシーを周知のアプリケーション・コンテキストとともに使用して、より高度の粒状性をフロー分類において達成することができる。したがってフロー分類は、パケット分類とは異なる。パケット分類はステートレスであり、識別プロセスは、パケット内に見つけることのできる評価基準の所定セットに対して行う単一のパケットのマッチングを伴う。これに対してフロー分類はステートフルであり、識別プロセスが、異なる時に到着するパケットのシーケンスを伴い、分類評価基準が、これらのパケットのいくつかにわたって見つけられる。フロー分類は、すべてのＩＮＯＤＥ上、新しいフローを発生するＡＮＯＤＥ（たとえば、ＮＡＴ、ＶＰＮ、プロキシ等）上において実行される。この機能を実行するモジュールは、フロー分類（ＦＣ）モジュールと呼ばれ、フロー分類の結果は、２つの値になる：すなわちフローの種類（たとえば、ＨＴＴＰ、ＦＴＰ等）とフローＩＤである。フローＩＤは、そのパケット内の種々のフィールドと、その特定フロー内のすべてのパケットのための定数のハッシュである。このハッシュ・アルゴリズムは、フローの種類に依存する。フロー内においては５タプルが常に定数でないことがある。たとえば、ＦＴＰデータ接続は、ＦＴＰコントロール接続と異なる発信元ポートを有することになる；しかしながら、両方の接続は同一のフローに属する。

フローが分類された後は、フロー・パス割り当てを行うことができる。フロー・パス割り当ては、フローが、静的もしくは動的評価基準に基づいて特定のパスに向けられるプロセスである。多段ネットワーク内における場合のように、指定フロー内のパケットをシリアルに処理することが求められるいくつかのエンティティが存在するとき、フロー・パスは、それらのエンティティがパケットを処理するシーケンスを定義する。より詳細に述べれば、本発明に関する場合、フロー・パスは、所定のフローのパケットについてクラスタ−ツー−クラスタのパスを表す。フロー・パスは、静的（たとえばオペレータによって指定された一定のシーケンス）もしくは動的（たとえばリアルタイムで変化することのできる評価基準のセットによって決定される）、あるいはハイブリッド（たとえば、パスの一部がオペレータによって指定され、残りがリアルタイムで決定される）とすることができる。たとえば、同一多段ネットワーク内に２つのフロー・パスが存在することがあり、フローを選択的に、オペレータ指定の評価基準、たとえばフローの発信元、フローの宛先、そのフローが関連付けされているアプリケーション等に基づいてフロー・パスの一方もしくは他方に割り当てることができる。

前述したとおり、フロー・マネジメント・モジュールは、トラフィック・フローが発生する外部ネットワークに接続されたすべてのＩＮＯＤＥ内に常駐する。各ＩＮＯＤＥ内のフロー・マネジメント・モジュールは、以下の機能を実行する。
ａ．新しいフローの開始、現在のフローの終了、非アクティブのフローの検出；
ｂ．システム・オペレータによって設定された評価基準またはポリシーに基づいたフローの分類；
ｃ．システム・オペレータによって設定された評価基準またはポリシーに基づいた各フローに対するフロー・パスの割り当て；
ｄ．フローとそれぞれに対するパス割り当てのテーブルの維持；
ｅ．ルーティングのスループット、待ち時間、利用、効率といったエンド−ツー−エンドのフロー固有の統計の収集；
ｆ．エンド−ツー−エンドのフロー関連の統計の収集と集計のためのインターフェースの提供；
ｇ．仮想接続グリッドを出るパケットの転送を決定するための、外部ネットワーク内のルータとそのほかのネットワーク・デバイスとのインタラクション。

ＡＮＯＤＥ上において動いているアプリケーションに応じて、ほとんどのＡＮＯＤＥは、いくつかの２次フロー（たとえば、ＲＡＤＩＵＳサーバまたはｓｙｓｌｏｇサーバと通信するためのフロー）の開始、または終了を行う。したがってＡＮＯＤＥは、フロー・マネジメント・モジュールを用いて構成することができる。しかしながら、この２次フロー上のトラフィックが、合計のデータ・トラフィックに比較して軽い場合には、固定のフロー・パスをそのフロー用に割り当ててもよく、その場合には２次フロー用のフロー分類／ルーティングを不要にすることができる。データ・トラフィック（ＶＰＮ等）のためのフローを開始／終了するＡＮＯＤＥについては、ＡＮＯＤＥにおいてフロー分類を実行するか、あるいはそれに代えてそのフローを、その種の機能を実行するＦＮＯＤＥにルーティングすることができる。

フロー・ルーティングは、フロー・マネジメントとは異なる。すなわちフロー・マネジメントは、フローのクラスタ−ツー−クラスタ・パスに関係し、フロー・ルーティングは、そのフローのパケットによって取られる実際のノード−ツー−ノード・ルートに関係する。言い換えるとフロー・ルートは、特定のフローに属するパケットによってトラバースされるノードの特定シーケンスである。したがってフロー・ルーティングは、特定のフローに属するパケットが、そのフローに割り当てられたフロー・ルート内の次のノードに転送されるプロセスである。

フロー・パスは、したがってフローによって取られるアプリケーション・クラスタ（または仮想ネットワーク）のシーケンスを定義するが、フロー・ルートは、トラバースされることになるそれらのアプリケーション・クラスタ（または仮想ネットワーク）内の特定のノードのシーケンスを定義する。この区別を図５に示すが、そこには、３つのＩＮＯＤＥ（ＩＤ−１、ＩＥ−１、ＩＦ−１）、５つの仮想ネットワーク（ＶＮ−６、ＶＮ−７、ＶＮ−８、ＶＮ−９、ＶＮ−１０）、３つの外部ネットワーク（ＥＮ−５、ＥＮ−６、ＥＮ−７）、７つのＡＮＯＤＥ（ＡＤ−１、ＡＤ−２、ＡＤ−３、ＡＥ−１、ＡＥ−２、ＡＦ−１、ＡＦ−２）を含む３つのアプリケーション・クラスタ（ＡＤ、ＡＥ、ＡＦ）を伴う３段のネットワーク５０が示されている。この図は、２つのフロー・パス５２、５４を例示している。フロー・パス５２は、外部ネットワークＥＮ−５内において発生し、アプリケーション・クラスタＡＤとＡＦを通り、外部ネットワークＥＮ−６内において終了する。フロー・パス５４は、外部ネットワークＥＮ−５内において発生し、アプリケーション・クラスタＡＤとＡＥを通り、外部ネットワークＥＮ−７内において終了する。ネットワーク５０を通る可能フロー・ルートは合計１２であり、そのうちの、次に示すノードをトラバースする４つが図示されている。
ｉ．ＩＤ−１−＞ＡＤ−１−＞ＡＦ−１−＞ＩＥ−１（フロー・ルート５６）；
ii．ＩＤ−１−＞ＡＤ−２−＞ＡＦ−２−＞ＩＥ−１（フロー・ルート５７）；
iii.ＩＤ−１−＞ＡＤ−２−＞ＡＥ−２−＞ＩＦ−１（フロー・ルート５８）；
iv．ＩＤ−１−＞ＡＤ−３−＞ＡＥ−１−＞ＩＦ−１（フロー・ルート５９）。

フローのステートフルな性質から、特定のフローに属するすべてのパケットが、そのフローの最初のパケットの受信に選択された同一のノード（または、バックアップ・ノードを維持する状態）に転送されることが不可欠である。また、フローが双方向かつ対称であることから、逆方向に移動する特定のフローに属するすべてのパケットは、順方向においてそれらのパケットが受信されたノードと同一のノードに対して送信されなければならない。これらの要件に適合するため、各ノードは、各フローについてのエントリを伴うルーティング・テーブルを維持することができる。エントリは、新しいフローの開始が検出されたときに作成され、そのフローの終了が検出されたときに削除される。パケットの逆方向パスが、フロー内におけるパケットの順方向パスと同一になることを保証するため、システム内の各エグレス・ポイントをはじめフローを終了するＡＮＯＤＥ（たとえば、ＮＡＴ、ＶＰＮ、プロキシ等）は、各フローに関連付けされた状態を維持し、「フローＩＤ」が順方向パスと同一であること、または「フロー・ルート」が順方向パスと同一であることを保証しなければならない。これらのパラメータについての詳細を以下に述べる。

フロー・ルーティング・テーブルは、すべてのフロー・パスの一部である仮想接続グリッドに接続されたＩＮＯＤＥとＡＮＯＤＥ内に常駐するフロー・ルーティング・モジュールのコンポーネントである。これらのソフトウエア・モジュールの主要な機能は、特定のデータ・フローに属するデータ・パケットの、近隣ノードの優勢な状態を考慮しつつ行う多段ネットワークの次段内のノードに対する適応的かつ信頼性のあるルーティングである。各ＩＮＯＤＥまたはＡＮＯＤＥ内のフロー・ルーティング・モジュールは、次に示す機能を実行する。
ａ．新しいフローの開始、現存するフローの終了の検出、さらには非アクティブ・フローの識別；
ｂ．新しいフローの順方向振り向けのための次のホップ・ノードの選択（次のホップ・ノードの選択に使用可能な方法はいくつか存在する：ラウンド・ロビン、重み付きラウンド・ロビン、アクティブ・フローの数を基礎とするアルゴリズム、利用可能な次のホップ・ノードからのリアルタイム・フィードバックを基礎とするアルゴリズム等）；
ｃ．ノードによって管理されるすべてのアクティブ・フローについてのルーティング・テーブルの維持：
ｉ．それぞれの新しいフローのためのエントリを、発信元と宛先のＩＰアドレス、発信元と宛先のポート番号、プロトコル識別子（５タプル）の一意的なセットによって定義されるとおりに作成する；
ii．フローが受信されたノードのＭＡＣアドレスをストアする（これは、フローの逆方向におけるパケットの転送に必要となる）；
iii.フローの複製が指定されたノードのＭＡＣアドレスをストアする；
iv．フローが終了したとき、またはタイムアウトが生じて非アクティブ・フローが示されたときにエントリを削除する；
ｄ．下流および同胞ノードに対するフローの作成と削除の通知の転送；
ｅ．次のホップ・ノードに対するパケットの転送；
ｆ．複製のためにフローが選択された場合における、１または複数の追加の指定ノードに対するパケットの転送；
ｇ．スループット、待ち時間、パケット数、バイト数等に関するフロー固有の統計と集計済み統計の維持；
ｈ．同胞ノードを含めた近隣ノードへのステータス情報の転送；
ｉ．ノード発見への参加；
ｊ．同胞ノードを含めた近隣ノードからのステータス情報の受信と処理；
ｋ．フロー固有とノードの統計の収集と集計のためのコール・バック・インターフェースの提供；
ｌ．ノードの障害とノードの輻輳を回るフローの再ルーティング。

フローの開始と終了を識別するためのアプリケーション固有のメカニズムとトランスポート・プロトコル固有のメカニズムがいくつか存在する。たとえば、ＴＣＰベースのフローの場合は、ＴＣＰ接続設定のためのパケット交換のシーケンスがフローの開始を示し、ＴＣＰ接続終了のためのパケット交換のシーケンスがフローの終了を示す。ＵＤＰ等の接続なしのトランスポート・プロトコルの場合においては、発信元と宛先のＩＰアドレス、発信元と宛先のＵＤＰポート番号、アプリケーション・プロトコル識別子の新しいセットを伴う最初のパケットを使用して新しいフローの開始を決定することができる。接続なしのプロトコルの場合は、トランスポート・レイヤに、フローの終了を示す明示的なパケットのシーケンスが存在しない。その種の場合においては、フローの開始と終了を、セッション−レイヤまたはアプリケーション−レイヤのプロトコルによって交換される情報を使用してより決定的に検出することができる。

フロー・ルーティングは、適応的または静的とすることができる。適応ルーティングは、ノードが、ノード・リソース利用度等の動的に変化するメトリックを基礎として特定フローのすべてのパケットが転送される次のホップ・ノードを、機能的に等価なノードのリストから選択するプロセスである。静的ルーティングは、フローＩＤとパケットの種類等のパケット・パラメータを基礎として次のホップが決定されるフロー・ルーティングの種類である。いずれの場合においても、次のホップの選択は、通常、新しいフローが検出された時点、および／または途中でフローの再ルーティングが必要となったときに生じる。ノードの障害や輻輳等のノードの動作状態がこの種の再ルーティングをトリガすることもできる。

次のホップ・ノードの選択は、集中化あるいは分散することができる。集中化アーキテクチャにおいては、仮想接続グリッド内へのフローのための入口ポイントとして作用するＩＮＯＤＥ等の指定ノードが、そのフローのためのエンド−ツー−エンドのルートをセットアップする。これは、フローに属するすべてのパケットのために、そのフローの持続期間にわたって使用されることになる回路をセットアップすることに類似している。非集中化または分散アーキテクチャにおいては、各ノードが、次のホップとして使用するノードをローカルに決定する。これは、ホップ−バイ−ホップ・パケット・ルーティングに類似である。

集中化または分散のいずれが次のホップの選択に使用されるかによらず、「フローの種類」と「トポロジＩＤ」が、イングレスノードにおいて各パケットにエンコードされる。それに加えて、「フローＩＤ」または「フロー・ルート」が（それぞれ）、分散された次のホップの選択が使用されるか、集中化された次のホップの選択が使用されるかに応じてパケットにエンコードされる。「フローの種類」パラメータは、主として統計のために使用される。パケット内にエンコードされる「トポロジＩＤ」パラメータは、そのフローが作られたときにカレントであったものである。これは、トポロジが変化し、現存するフローがその変化に起因して異なる取り扱いを必要とするときに有用な参考となり得る。

また２つの追加の情報ビットもパケット内にエンコードされる：すなわち「フロー開始」と「フロー終了」ビットである。これらのビットを多段ネットワーク内のほかのノードが使用して状態情報を作成し、あるいは削除することができる。しかしながら、フローの開始または終了が常に識別可能であるとは限らないことから、ノードは、これらのビットのみに頼るべきではない。

フローの種類、トポロジＩＤ、フローＩＤ／フロー・ルート、フローの開始／終了パラメータは、パケットの「フロー記述子」の一部である。すでに触れたように、フロー記述子は、仮想リンク接続や、フロー・マネジメントに関連付けされたネットワーキング・パラメータの分配のためのイン−バンド・メカニズムを提供する。これらは、スプーフィング攻撃の防止を補助するセキュリティ・エレメントもサポートすることができる。仮想接続グリッド内の各パケットは、フロー記述子を運ぶ。

フロー記述子は、各パケットのＭＡＣ、ＶＬＡＮ、またはＩＰヘッダ内にストアすることができる。すなわち、これらのヘッダ内の使用されていない情報を、多段ネットワーク内においてそのパケットが処理される時間が持続する間にわたってフロー記述子と置き換えることが可能である。置換された情報は、パケットのエグレスにおいて再挿入するため、あるいは１または複数のノード（すなわち、それらのノードにおいて動作しているアプリケーション・プログラム）がその情報を要求した場合のために保持する必要がある。この目的のために使用可能なこれらのヘッダ内の可能フィールドには次のものが含まれる。
ａ．ＭＡＣ：１６ビットの「種類」フィールドからのビットをいくつか使用する；
ｂ．ＶＬＡＮ：「ＶＬＡＮプライオリティ」フィールドの最大４ビットを使用する；
ｃ．ＩＰ：「チェックサム」フィールドの１６ビット、および／または「バージョン」フィールドの３ないし４ビットを使用する。
これらに代えて、各パケットのＶＬＡＮタグ・ヘッダとＩＰヘッダの間、もしくはパケットのエンドのいずれかにフロー記述子を挿入することができる。これは多段ネットワーク内のすべてのノードとスイッチ上のＥｔｈｅｒｎｅｔドライバが、従来的なＥｔｈｅｒｎｅｔサイズより大きいパケットに適合できる場合（たとえば、ノードとスイッチがＥｔｈｅｒｎｅｔジャンボ・フレームに適合している場合）に可能である。この種の情報は、そのパケットがネットワークから出る前に取り除く必要がある。

フロー記述子がパケットのエンドに取り付けられる場合には、そのパケットが種々のノードをトラバースする間、好ましくはそれをアプリケーションから隠す。フロー記述子は、適切な認証の後に仮想プローブを用いて可視化されるようにしてもよい。パケットに取り付けられることになるフロー記述子のためのフィールドの一例を次の表２に示す。

フロー・ルートに沿った各ノード内へのイングレス上においてオリジナルのＭＡＣアドレスが、上位のレイヤ・プロトコルにそのパケットを渡す前にパケット・ヘッダ内にリストアされる。ノードからのパケットのエグレスの前に、ＭＡＣヘッダ（発信元／宛先のＭＡＣアドレスとＶＬＡＮタグを含む）を修正することができる。オリジナルのＭＡＣヘッダは、フロー記述子内に保存される。

ノードの各クラスタのためのクラスタ・データは、そのクラスタのために割り当てられたノードのノードＩＤを含む。それに加えて、特定のクラスタがそのパケットを処理したことを示すビットをセットすることができる。これは、次の２つの目的のために行う。第１は、システム内のパケット・ループの検出にそれを使用すること。第２は、ＦＮＯＤＥが、クラスタ内の各ノードによって処理されたフローの数を測定するためにそれを使用すること。

分散された次のホップの選択が使用される場合には、フロー・パスが、あらかじめ決定されず、各ノードにおいてそのノード上で動作しているアプリケーションによって決定される。したがって、フロー・パスの割り当ては、それぞれのアプリケーションによって各ノードにおいて行われる。新しいフローが検出されるとき（たとえば、外部ネットワークからその新しいフローを受信するＩＮＯＤＥによって、または新しい２次フローを開始するＡＮＯＤＥによって）、検出しているノードのフロー分類モジュールが、その新しいフローに一意的なフローＩＤを割り当て、その指示子をそのローカル・テーブル内に保存する。この新しいフローに関連付けされているほかのパケットが検出されたとき、フロー分類モジュールは、対応するフローのすべてのパケット内にその新しいフローＩＤを挿入し、それによりそのフロー・パス内のほかのノードがフローＩＤを取り出すことが可能になり、フロー分類を実行する必要がなくなる。フローＩＤは、いくつかの実施形態においては２４ビット値であり、最大で１６００万の同時フローが考慮に入れられる。

新しいフローのパケットを受信した各ＡＮＯＤＥまたはＩＮＯＤＥにおいて、フロー・マッパ・モジュールが到来パケットからフロー記述子を抽出し、オリジナルのヘッダ値をリストアすることによってそのパケットを整える。フローＩＤは、そのパケットがフロー・パス内の次のホップに送信される前に、そのパケット内に再挿入できるように保存される。場合によっては、これがフロー情報とともにパケット情報（５タプル等）を（たとえばローカル・テーブル内に）保存すること、対応するアウトバウンド・パケットを識別してフロー記述子を再挿入することを必要とすることがある。このテーブルは、特定のノードにおいてパケットが処理される時間の持続する間にわたってのみエントリが維持されればよいことから、比較的小さくすることが可能である。

ノードは、パケットを送出する前に、次のホップのためのノードを選択する（たとえば、そのノードのフロー・マッパによってこの選択が実行される）。静的負荷バランシングの場合には、これが単純に、フローＩＤを１から「ｎ」までの値にハッシュすることによってなされる。その際、ｎは、次のクラスタ内のノードの数である。フロー内のすべてのパケットについてフローＩＤが同一であることから、次のホップは、そのフロー内のすべてのパケットについて同一となる。したがってノードが、フローの次のホップのためのテーブルもしくはそのほかのデータ構造を維持する必要はない。しかしながら、適応負荷バランシングが使用される場合には、すべてのアクティブ・フローのための状態テーブルとフローの次のホップのテーブルが各ノードで維持される必要がある。

逆方向におけるパケットの正しいフローを確保するために、ノードは、以下のアルゴリズムの１つを採用することができる。
ａ．ノードがすべてのアクティブ・フローとそのフローについての以前のホップのＭＡＣアドレスのテーブルを維持する（これは、パケット内の発信元Ｅｔｈｅｒｎｅｔアドレスである）。これが、すべてのパケットについて行われる。フロー・マッパが、いつ新しいフローが開始し、あるいは終了するかを知る必要はない。エントリがすでにそのフローＩＤ用に存在する場合には、単純にそれが上書きされる。フロー・マッパは、両方向の次のホップのＭＡＣアドレスを維持する必要がある。この種のアルゴリズムは、適応ルーティングが使用される場合に必要となる。
ｂ．ノードは、フローＩＤを単純に１からｎまでの値にハッシュすることによって次のホップを決定する。その際、ｎは、逆方向における次のクラスタ（または順方向における手前のクラスタ）内のノードの数である。フローのテーブルを維持する必要はない。このアプローチは、静的フロー・ルーティングの場合に使用することができる。

次のホップを選択するプロセスは、フローが最初に作られたときに有効であった値ｎを使用する。これは、トポロジの変更を伴う場合であっても、現存するフローが同一のノードにルーティングされることを保証する。当然のことながら、各ノードは、現在はもとより以前のトポロジを維持して、そのフローが作られたときの値「ｎ」を追跡する必要がある。これが、各パケットを伴うフローに関連付けされた「トポロジＩＤ」を含む理由である。

集中化された次のホップの選択が使用される場合には、外部ネットワークから新しいフローを受信するＩＮＯＤＥが、この特定のフローを処理することができる各クラスタ内のノードを選択する。ＩＮＯＤＥには、そのパケットが実際にいずれのクラスタを通るかわからないことから、パケットがすべてのクラスタをトラバースしない場合であっても、次のホップの選択がシステム内のすべてのクラスタについて行われる。言い換えると、多段ネットワークの各クラスタ内のノードが、フローがそのクラスタ内のいずれのノードも使用しないことになる場合においても、各フローを取り扱うために予約される。各クラスタ用に選択されたノード（前述したフロー・ルート・パラメータ）は、フローの種類とトポロジＩＤ等の追加のフロー情報とともにパケット内にエンコードされる。

ＩＮＯＤＥは、それが有している各クラスタ内の個別のノード上の負荷についての情報を基礎として、各クラスタのための次のホップを選択する。多くの負荷バランシング・テクニックのいずれを使用してもよい。たとえは、単純ラウンド・ロビンまたは重み付きラウンド・ロビン負荷バランシングを使用してもよく、あるいはより複雑な、実際の現在負荷および／またはフローの種類に関するノードからのフィードバックを頼るスキームを使用することもできる。好ましくは、負荷バランシングの決定が、フローについてのエンド−ツー−エンド特性を基礎として行われる。これらの特性は、それぞれのノード内に与えられているフロー・マッパを介してＩＮＯＤＥに伝えることができる。フロー作成時において選択が行われた後は、この選択がテーブル内に保存され、同一フローのためのすべての将来パケットが、各クラスタ内の同一のノードを使用する。

しばしば、フロー複製が必要になることがある。フロー複製は、フローの正確な複製（クローン）が作られ、その複製フロー用に明瞭なフロー・パスが作られるプロセスである。このパスは、オリジナルのフロー・パス内に含まれていたエンティティのシーケンスと異なるシーケンスを含むことができる。フロー複製は、新しいフロー・パス、所定のフロー・パス内の新しいか、あるい異なるはバージョンのエンティティ（たとえばノード）、あるいは新しいポリシーのテストを容易にする。

システム内のノードが故障したとき、そのシステム内のほかのすべてのノードにこの故障が通知される。これは、システム内のすべてのノードに対してトポロジ更新通知を送信するＭＮＯＤＥによって行うことができる。そのノードの障害の後に開始される新しいフローは、故障したノードを使用せず、それに代えて、影響を受けたクラスタ内の残りのノードによって扱われることになる。同様に、故障したノードを含まない現存するフローは、影響を受けない。しかしながら、それらのパス内に故障したノードを含んでいた現存するフローは、特別な扱いを必要とすることになる。次に、その種の事象を扱うためのストラテジをいくつか示す。
ａ．現存するフローのためのパケットを破棄する。このアプローチは、故障したノードが同一クラスタの別のノード内に存在しない何らかのアプリケーション固有の状態を維持していたという前提を基礎とする。したがって、そのフローのパケットが、影響を受けたクラスタ内の別のノードにリダイレクトされた場合であっても、それらのパケットがドロップされる傾向を有する。
ｂ．影響を受けたクラスタ内の別のノードにパケットをリダイレクトする。このプロセスは、故障したノードがそのフローについてのアプリケーション固有状態をまったく維持してなく、したがってほかのネットワーク・ノードは、影響を受けたフローからのパケットを取り扱うことができる場合に使用することができる。
ｃ．クラスタ内の各ノード用のバックアップ・ノードを使用する。このアプローチにおいては、一部もしくはすべてのノードが、それぞれのフローの一部もしくはすべてについてのアプリケーション固有状態情報を維持することになるが、その種の状態情報が純粋にそのフロー内のパケットによって決定されることを仮定する。クラスタ内の各ノード（それぞれのフローについてのプライマリ・ノードと呼ばれる）が、バックアップ・ノードに割り当てられる。プライマリ・ノードによって受信され、処理されるすべてのパケットもまた、そのノードのバックアップ・ノードによって受信され、処理されることになる。しかしながらバックアップ・ノードは、処理済みパケット（またはそのパケットの処理の結果として得られる情報）を、そのパスのさらに先に送る必要がない。それに代えてバックアップ・ノードは、プライマリ・ノードの障害を検出しないか知らされない限り、各パケットをドロップする（すなわち、出力を送出しない）。その種の情況においては、バックアップ・ノードが、影響を受けたフローのためのプライマリ・ノードとなり、パケットのドロップを停止する。実質的にバックアップ・ノードは、故障したプライマリ・ノードからフロー・パスをシームレスに引き継ぎ、フローが終了するまでこの役割を継続する。これは、その後に続いてオリジナルのプライマリ・ノードが再び利用可能となる場合であっても、そのノードがそのフローの状態情報を失ってしまっていることから真となる。ここで注意を要するが、トポロジが変化する場合には（たとえば、ノードの障害に起因して）、特定のプライマリ・ノードのためのバックアップ・ノードもまた変化することがあり、したがっていずれのノードが個々のフロー用に割り当てられているかを追跡するため、トポロジＩＤがそのフローＩＤに関連付けされる必要がある。このようにしてノードは、それらの割り当て済みバックアップの役割を、フロー−バイ−フロー・ベースで追跡することが可能になる。

Ｄ．システム・マネジメント・フレームワーク
システム・マネジメント・フレームワークによってオペレータは以下のことが可能になる。
ａ．以下のようなシステム構成オペレーションの実行：
ｉ．システムとサービス・ノード上におけるソフトウエアのインストール、更新、維持；
ii．２もしくはそれを超える数のノードにわたるソフトウエアと構成の変化の同期；
iii.サービスまたはアプリケーション・クラスタの作成と維持、プロセス容量の増加または減少；
iv．仮想ネットワーク・トポロジの作成と維持；
ｖ．外部ネットワークに対する相互接続の作成と維持；
vi．フロー・パスの作成と維持；
vii.ソフトウエアと構成を含めたノード環境の複製；
viii.システムの任意の部分のためのテスト環境の作成；
ix．システムの任意の部分のためのメータとモニタリング・ファシリティのセットアップ；
ｘ．スペアの展開と使用の管理。
ｂ．以下のようなシステム、要素、トラフィックのモニタリング・オペレーションの実行：
ｉ．全体的なシステム、アプリケーション・クラスタ、個別のノード、ソフトウエア要素のステータスのモニタ；
ii．システム・レベル、要素レベル、ネットワーク・レベル等におけるデータ・トラフィックのモニタ；
iii.フロー固有のステータスと統計のモニタ。
ｃ．以下のような診断とトラブルシューティング・オペレーションの実行：
ｉ．フロー・トラフィックの傾向の分析；
ii．システム、クラスタ、要素、ネットワーク、フロー・レベルにおけるスループット、待ち時間、利用度等のキー・メトリクス内の傾向の分析；
iii.エラー状態、パフォーマンス異常、システムのボトルネックの分析。

システム・マネジメント・フレームワークは、以下を含む：
ａ．仮想接続グリッドに接続された１または複数のマネジメント・ノード（ＭＮＯＤＥ）；
ｂ．仮想接続グリッドに接続された各ノード内において動作するノード・マネジメント・エージェント；
ｃ．互いに通信する目的のためにＭＮＯＤＥ、ＩＮＯＤＥ、ＡＮＯＤＥを接続する、仮想接続グリッド内側の１または複数の仮想ネットワーク；
ｄ．すべて内部マネジメント・ネットワークに接続されている、ノード内に常駐するノード・マネジメント・エージェントと、１または複数のシステム・マネジメント・ノードの間において交換される通信メッセージのセット；
ｅ．オペレータが使用するためのマネジメント・コンソールを構成する、仮想接続グリッドの外側の１または複数のワークステーションまたはサーバ・プラットフォーム上において動作するマネジメント・アプリケーションのスーツ；
ｆ．仮想接続グリッド上の指定ＭＮＯＤＥ、すなわちコンソールに対するシステム・マネジメント・インターフェースを提供するＭＮＯＤＥにマネジメント・コンソールを接続する１または複数の外部ネットワーク；
ｇ．マネジメント・コンソールとシステム・マネジメント・インターフェースを提供するＭＮＯＤＥの間において交換される通信メッセージのセット；
ｈ．オプションとする、外部ネットワークに接続されるワークステーションまたはサーバ・プラットフォーム上において動作するサード・パーティのマネジメント・アプリケーション（たとえば、チボリ（Ｔｉｖｏｌｉ）、ＨＰオープンビュー（ＨＰ ＯｐｅｎＶｉｅｗ）、ＣＡユニセンタ（ＣＡ Ｕｎｉｃｅｎｔｅｒ）、マイクロミューズ・ネットクール（Ｍｉｃｒｏｍｕｓｅ ＮｅｔＣｏｏｌ）等）；
ｉ．ＭＮＯＤＥからサード・パーティのアプリケーションへのシステム・マネジメント関連のデータをエクスポートすることを目的とした、サード・パーティのマネジメント・アプリケーションと、システム・マネジメント・インターフェースを提供するＭＮＯＤＥとの間において交換される通信メッセージのセット。

図６は、本発明の実施形態に従って構成されたシステム・マネジメント・フレームワークの一例を示している。システム・マネジメント・インターフェースは、クラスタＭＮとして構成されたＭＮＯＤＥ、ＭＮ−１、ＭＮ−２の冗長セットによって提供される。これらのノードは、内部マネジメント仮想ネットワークＶＮ−８に接続されている。すべてのＩＮＯＤＥ（ＩＮ−１、ＩＮ−２、ＩＮ−３）とＡＮＯＤＥ（ＡＧ−１、ＡＧ−２、ＡＨ−１、ＡＨ−２、ＡＨ−３）もまたこのネットワークに接続される。各ＩＮＯＤＥとＡＮＯＤＥ内には、マネジメント・エージェント６２が常駐し、それが、内部マネジメント・ネットワークＶＮ−８を使用して、ピア・マネジメント・エージェントをはじめ、２つのＭＮＯＤＥ（ＭＮ−１およびＭＮ−２）を含むシステム・マネジメント・ノード・クラスタＭＮに対するメッセージの交換を行う。

この図は、外部ネットワークＥＮ−８に接続されたワークステーションまたはサーバ・プラットフォーム上において動作しており、システム・マネジメント・ノード・クラスタＭＮとメッセージを交換するネットワーク・マネジメント・アプリケーション（ＭＡｐｐ−１）も示している。システム・マネジメント・フレームワークは、サード・パーティのコンポーネントを追加することによって拡張することも可能である。したがって、サード・パーティのネットワーク・マネジメント・アプリケーションＴＭＡ−２もまた外部ネットワークＥＮ−８に接続され、同様にシステム・マネジメント・ノード・クラスタＭＮと通信する。

システム・マネジメント・ノード・クラスタＭＮに加えて、サード・パーティのマネジメント・ノードＭＮ−３が、外部ネットワークＥＮ−９を通る接続を介したサード・パーティのマネジメント・アプリケーションＴＭＡ−１のコントロールの下に存在する。ここで注意を要するが、サード・パーティのマネジメント・ノードは、ほかの任意のＡＮＯＤＥまたはＩＮＯＤＥとまったく同様に、サービス接続グリッド内において管理され、ノード・マネジメント・エージェントを含む。

Ｅ．システムの実装
前述した、仮想接続グリッド、複数のシステムとサービス・ノード、フロー・ルーティング・フレームワーク、システム・マネジメント・フレームワークを含むシステムは、商業的に入手可能なハードウエア上で実現することができる。前述したとおり、仮想接続グリッドは、ＶＬＡＮをサポートする従来のＥｔｈｅｒｎｅｔスイッチ上にオーバーレイすることができる。システムとサービス・ノードは、従来のオペレーティング・システムが動作する従来のコンピュータ・ワークステーションまたはサーバ・コンピュータ上において、ノードをサービス接続として接続するフレームワーク、フロー・ルーティング・フレームワーク、システム・マネジメント・フレームワークのために特化されたソフトウエアの追加を伴って実現することができる。これらのフレームワークは、エージェントまたは、各ノードおよび適切であれば外部コンピュータ内で動作するソフトウエア、それらのエンティティの間において交換される通信メッセージのセットによって表される。

例を示すと、図７は、商業的に入手可能なＬＡＮスイッチとワークステーションまたはサーバを使用して、どのようにすれば図５に示されている論理システムのトポロジを実現できるかについて例示している。ネットワーク７０は、ワークステーション／サーバ７２ａ〜７２ｇの集合からなり、これらは、示されているとおりの種々のＡＮＯＤＥの機能を実行するように構成されている。すなわちワークステーション７２ａは、ＡＮＯＤＥ ＡＤ−１として動作するように構成され、ワークステーション７２ｂは、ＡＮＯＤＥ ＡＤ−２として動作するように構成され、以下も同様になる。ワークステーション７４ａ、７４ｂ、７４ｃは、それぞれＩＮＯＤＥ ＩＤ−１、ＩＥ−１、ＩＦ−１として動作するように構成される。図５には示されていないが、ここで認識されるとおり、システム・マネジメント・フレームワークを提供するために特定のＭＮＯＤＥが必要となり、図７においてはそれらが、ＭＮＯＤＥ ＭＣ−１と外部マネジメント・アプリケーションＭＡｐｐ−２として示されている。これらのＭＮＯＤＥは、それぞれ、マネジメント機能を実行するように構成されたコンピュータ・システム７６ａ、７６ｂとすることができる。

これらの種々のワークステーション／サーバは、図示のとおりＬＡＮスイッチ７８ａ、７８ｂ、７８ｃに結合される。これらの物理的な接続は、従来のＥｔｈｅｒｎｅｔ接続を使用して行われ、それの上に前述した仮想インターフェースや仮想ネットワークが作られて図５に例示されている論理トポロジが達成される。仮想ネットワークＶＮ−６、ＶＮ−７が例示されているが、ほかは、図を不必要に不明瞭化しないために示されていない。３つの物理ＬＡＮスイッチ７８ａ〜７８ｃが示されているが、充分な数のポートを有する単一のスイッチを使用すること、あるいはそれに代えて２もしくはそれを超える数のスイッチを相互接続できることを認識する必要がある。

スタンド−アロンの汎用サーバ・ハードウエアを作っている多くのベンダーは、現在、「ブレード・サーバ」と呼ばれる新しいフォーム・ファクタでそれらのサーバを提供している。ブレード・サーバは、スタンド−アロンの汎用コンピュータと同一もしくは類似のパフォーマンス能力を提供するシングル・ボード・コンピュータを収容するように設計された、いくつかのスロットを伴った冗長性が高い障害許容シャーシを含む。すべてのブレードは、ブレード・サーバ・システム構成の一部である高速スイッチを使用して相互接続される。ブレード・サーバの主なねらいとする応用は、サーバの合併、それに付随するコスト、電力、空間節約の恩典である。ブレード・サーバのフォーム・ファクタによってオペレータは、現在の代替手段によって提供されるよりはるかに低いコスト、消費電力、空間消費において非常に大量のサーバ容量または演算能力を展開することが可能になる。このことは、ブレード・サーバを大規模データ・センタ用の理想的なフォーム・ファクタとしている。

図８は、代表的なブレード・サーバ・シャーシを使用した図５に示した論理トポロジの実装を例示している。ブレード・サーバ８０は、シングル・ボード・コンピュータ８２ａ〜８２ｇの集合からなり、それらは、図示されているとおりの種々のＡＮＯＤＥの機能を実行するように構成されている。すなわちシングル・ボード・コンピュータ８２ａは、ＡＮＯＤＥ ＡＤ−１として動作するように構成され、シングル・ボード・コンピュータ８２ｂは、ＡＮＯＤＥ ＡＤ−２として動作するように構成され、以下も同様になる。これらのシングル・ボード・コンピュータは、すべて共通シャーシ内に収容される。

シングル・ボード・コンピュータ８４ａ、８４ｂ、８４ｃは、それぞれＩＮＯＤＥ ＩＤ−１、ＩＥ−１、ＩＦ−１として動作するように構成される。システム・マネジメント・フレームワークを提供するために必要となるＭＮＯＤＥは、ＭＮＯＤＥ ＭＥ−１（適正に構成されたシングル・ボード・コンピュータ８６として実現される）とＭＡｐｐ−３（ワークステーション８８として実現される）である。

これら種々のシングル・ボード・コンピュータは、図示のとおり、ブレード・サーバ８０内の高速スイッチ９０に結合される。これらの物理的な接続は、従来のブレード・サーバのバックプレーンを使用して行われ、図５に例示されている論理トポロジを達成させるために、それ等の接続に前述した仮想インターフェースと仮想ネットワークが形成される。仮想ネットワークＶＮ−６、ＶＮ−７が例示されているが、ほかは、図を不必要に不明瞭化しないために示されていない。

以上、各段階において特化された機能を実行する種々のパケット・プロセッサ（ノード）を含む多段ネットワーク内におけるパケット・フローの適応ルーティングを行うための方法とシステムについて述べてきた。ここに示されているとおり、本発明は、種々の実施形態において柔軟な接続グリッド、適応フロー・マネジメント、適応リソースプロビジョニングを提供する。これらの属性は、概して、従来的かつ商業的に入手可能な異種ソフトウエアが動作するハードウエア上において実現することができる。それにもかかわらず、本発明は、特定の例示したその実施形態を用いて述べられているが、本発明の範囲は、特許請求の範囲の表現によってのみ測定されるべきとする。

本発明の実施形態に従って構成された多段ネットワークのノードのための仮想接続グリッドを例示した説明図である。 本発明の仮想接続グリッドを使用して達成することのできる種々のノード相互接続を例示した説明図である。 本発明の仮想接続グリッドを使用して達成することのできる種々のノード相互接続を例示した説明図である。 本発明の仮想接続グリッドを使用して達成することのできる種々のノード相互接続を例示した説明図である。 本発明の仮想接続グリッドを使用して達成することのできる種々のノード相互接続を例示した説明図である。 本発明の仮想接続グリッドを使用して達成することのできる種々のノード相互接続を例示した説明図である。 本発明の仮想接続グリッドを使用して達成することのできる種々のノード相互接続を例示した説明図である。 本発明の実施形態に従って実現することのできる仮想プローブ機能を例示した説明図である。 多段ネットワークのノード、すなわち本発明の方法に従い、仮想インターフェース・ドライバを用いて構成されたノードの一般的な機能を例示した説明図である。 本発明の実施形態に従って、ノードならびに仮想接続グリッドを使用して構成された多段ネットワークの論理図を例示した説明図である。 本発明の実施形態に従って、多段ネットワーク内のフロー・パスとフロー・ルートの間の区別を例示した説明図である。 本発明の実施形態に従って構成されたシステム・マネジメント・フレームワークの例を示した説明図である。 従来のＬＡＮスイッチおよびワークステーションを使用して図５に示されている多段ネットワークの論理的な特徴を実現するための１つの構成を例示した説明図である。 ブレード・サーバを使用して図５に示されている多段ネットワークの論理的な特徴を実現するための別の構成を例示した説明図である。

Claims (63)

1. 処理ノードのクラスタからなる多段ネットワーク内でフローのためのパスを集中化された態様で決定することと、前記多段ネットワークのすべてのクラスタのためのフロー・パスの決定を表すノード選択情報を前記多段ネットワーク内の各フローのパケット内にエンコードすること、を含む方法。
2. 前記パスは、特定のフローのパケットが前記多段ネットワーク内の前記クラスタの特定のものを実際にトラバースすることになるか否かの知識なしに決定される請求項１に記載の方法。
3. 前記ノード選択情報が、前記パケット内のほかのヘッダ情報を前記ノード選択情報に置き換えることによって前記パケット内にエンコードされる請求項２に記載の方法。
4. 前記ノード選択情報のエンコーディングに先行して存在しているオリジナルのヘッダ情報が、前記多段ネットワークのノードにおいて実行するアプリケーション・プログラムによるパケットの処理に先行して前記パケットにリストアされる請求項３に記載の方法。
5. 前記ノード選択情報が、前記パケットに前記ノード選択情報を追加することによってエンコードされる請求項２に記載の方法。
6. 前記ノード選択情報が、前記多段ネットワークのノードにおいて実行しているアプリケーション・プログラムによるパケットの処理に先行して取り除かれる請求項５に記載の方法。
7. 各クラスタの個別のノードは、負荷バランシング評価基準に従って前記パス内に含めるために選択される請求項２に記載の方法。
8. 前記負荷バランシング評価基準は、ラウンド・ロビン選択方法を含む請求項７に記載の方法。
9. 前記負荷バランシング評価基準は、重み付きラウンド・ロビン選択方法を含む請求項７に記載の方法。
10. 前記負荷バランシング評価基準は、前記多段ネットワークの前記ノードからの現在の負荷状態についてのリアルタイム情報を含む請求項７に記載の方法。
11. 前記フローのためのパスの決定に先行して、前記フローが、前記パケット内にある情報のセットを使用し、かつネットワーク管理者によって設定された評価基準に従って分類され、フロー・パスが前記ネットワーク管理者によって設定されたポリシーを基礎として割り当てられる請求項２に記載の方法。
12. さらに、前記フローのパケットが前記多段ネットワーク内の前記フロー・パスをトラバースするとき、実際のフロー・ルートをノード−バイ−ノード・ベースで決定することを含む請求項１に記載の方法。
13. 前記実際のフロー・ルートは、前記フロー・パス内に指定されたすべてのクラスタを含まない請求項１２に記載の方法。
14. 前記実際のフロー・ルートに関係する情報が、その後に続く新しいフロー・パスの決定において使用される請求項１３に記載の方法。
15. 処理ノードのクラスタからなる多段ネットワーク内でフローのためのパスを分散された態様で決定することと、前記フロー・パスの決定を表すノード選択情報を前記多段ネットワーク内の各フローのパケット内にエンコードすること、を含む方法。
16. 前記ノード選択情報が、前記パケット内のほかのヘッダ情報を前記ノード選択情報に置き換えることによって前記パケット内にエンコードされる請求項１５に記載の方法。
17. 前記ノード選択情報のエンコーディングに先行して存在しているオリジナルのヘッダ情報が、前記多段ネットワークのノードにおいて実行するアプリケーション・プログラムによるパケットの処理に先行して前記パケットヘッダにリストアされる請求項１５に記載の方法。
18. 前記ノード選択情報が、前記パケット内にエンコードされたフロー識別子に対するハッシュ関数の適用を基礎として作られる請求項１５に記載の方法。
19. 前記ノード選択情報が、各パケットに追加される請求項１８に記載の方法。
20. 前記ノード選択情報が、前記多段ネットワークの前記ノードにおいて実行しているアプリケーション・プログラムによるパケットの処理に先行して取り除かれる請求項１９に記載の方法。
21. 前記ノードが種々のクラスタにグループ化され、各クラスタの個別のノードが負荷バランシング評価基準に従って選択される請求項２０に記載の方法。
22. 前記負荷バランシング評価基準は、ラウンド・ロビン選択方法を含む請求項２１に記載の方法。
23. 類似のアプリケーション機能を有するノードのクラスタにノードがグループ化された多段ネットワークのノードにおいて、両方向において、全体のフローを複製することと、前記複製フローが作られたオリジナルのフローのためのオリジナルのフロー・パスとは異なり、結果として得られた複製フローのためのフロー・パスを指定すること、を含む方法。
24. 前記複製フローが、前記複製フローと前記オリジナルのフローの両方を受信する終了ノードにおいて終了する請求項２３に記載の方法。
25. 前記終了ノードが、分析のために、前記複製フローと前記オリジナルのフローの内容を記録する請求項２４に記載の方法。
26. それぞれの物理インターフェースを介して１または複数の物理スイッチにノードが結合されている物理ネットワークにオーバーレイされる仮想接続グリッドを備え、その仮想接続グリッド内に設定された１または複数の仮想ネットワークに対する前記ノードの通信結合が提供されるように、前記仮想接続グリッドが、前記ノードの物理インターフェースにオーバーレイされる仮想インターフェースを含み、前記通信結合が、所望の接続パターンでの物理接続がエミュレートされるように構成された仮想リンクによって形成されることを特徴とするシステム。
27. 前記ノードのそれぞれは、フロー・マネジメント決定に応じて前記パケット内に含まれる情報を修正することによって、前記仮想接続グリッド内で送信されるパケットを操作するように構成されたフロー・マネジメント・モジュールを含む請求項２６に記載のシステム。
28. 前記フロー・マネジメント決定は、１または複数の外部ネットワークに結合され、かつ前記１または複数の外部ネットワークからフローを受信する前記ノードのフロー・マネジメント・モジュールにおいて、集中化された態様で、かつ前記仮想接続グリッド内におけるフロー−バイ−フロー・ベースで行われる請求項２７に記載のシステム。
29. 前記パケットは、フロー・ルーティング決定を指定する情報を追加することによって操作される請求項２８に記載のシステム。
30. 前記パケットは、前記パケット内の以前にエンコードされた情報を、前記フロー・ルーティング決定を指定する新しい情報に置き換えることによって操作される請求項２８に記載のシステム。
31. 前記パケットは、前記パケットにネットワーク・トポロジ状態情報を追加することによって操作され、そのネットワーク・トポロジ状態情報は、前記ノードの前記通信結合を反映する請求項２８に記載のシステム。
32. 前記パケットは、認証情報を追加することによって操作される請求項２８に記載のシステム。
33. フロー・パス決定は、いずれのノードを特定のフローが実際にトラバースすることになるかについての知識なしでなされる請求項２８に記載のシステム。
34. 前記システムは、ソフトウエアがストアされた複数のスタンド−アロン汎用および／または専用コンピュータを前記ノードとして、かつ仮想ローカル・エリア・ネットワーク（ＶＬＡＮ）とジャンボ・フレームをサポートするローカル・エリア・ネットワーク（ＬＡＮ）スイッチを前記１または複数の物理スイッチとして使用して実現される請求項２６に記載のシステム。
35. 前記ソフトウエアは、前記コンピュータに、仮想接続グリッドによって定義される多段ネットワークを通るデータ・フローの適応ルーティングを行わせるように構成されたフロー・マネジメント・ソフトウエアを含み、前記多段ネットワークの各段階は、１または複数のネットワーク・サービスを実行する類似に構成されたアプリケーションのクラスタを含む請求項３４に記載のシステム。
36. 前記コンピュータの少なくとも１つは、リソース・マネジメントとプロビジョニング・ソフトウエアをストアしており、前記コンピュータの残りのそれぞれは、前記コンピュータの残りのそれぞれに、アプリケーション需要、ネットワーク・パフォーマンス、あるいはアプリケーション応答時間によって駆動されるとおりに１または複数のネットワーク・サービスの必要容量の適応プロビジョニングを行わせるように構成されたプロビジョニング・エージェント・ソフトウエアをストアする請求項３４に記載のシステム。
37. プロビジョニングが、グラフィカル・ユーザ・インターフェースを通じた人間のインタラクションを介して、前記ノードと前記仮想インターフェースを表すアイコンを使用し、それらの間の相互接続を作成することによって行われる請求項３６に記載のシステム。
38. プロビジョニングが、プログラム・インターフェースを通じた人間のインタラクションを介して、前記ノードと前記仮想インターフェースの属性を提供するデータ・レコードを使用し、それらの間の所望の相互接続を指定することによって行われる請求項３６に記載のシステム。
39. 前記仮想接続グリッドは、１または複数のブレード・サーバを使用して実現され、前記ブレード・サーバの各ブレードは、前記ノードの１つとして供され、ソフトウエアをストアしている請求項２６に記載のシステム。
40. 前記ソフトウエアは、前記ブレードのプロセッサに、仮想接続グリッドによって定義される多段ネットワークを通るデータ・フローの適応ルーティングを行わせるように構成されたフロー・マネジメント・ソフトウエアを含み、前記多段ネットワークの各段階は、１または複数のネットワーク・サービスを実行する類似に構成されたアプリケーションのクラスタを含む請求項３９に記載のシステム。
41. 前記ブレードの少なくとも１つは、リソース・マネジメントとプロビジョニング・ソフトウエアをストアしており、前記ブレードの残りのそれぞれは、前記ブレードのプロセッサの残りのそれぞれに、アプリケーション需要、ネットワーク・パフォーマンス、あるいはアプリケーション応答時間によって駆動されるとおりに１または複数のネットワーク・サービスの必要容量の適応プロビジョニングを行わせるように構成されたプロビジョニング・エージェント・ソフトウエアをストアする請求項３９に記載のシステム。
42. プロビジョニングが、グラフィカル・ユーザ・インターフェースを通じた人間のインタラクションを介して、前記ノードと前記仮想インターフェースを表すアイコンを使用し、それらの間の相互接続を作成することによって行われる請求項４１に記載のシステム。
43. プロビジョニングが、プログラム・インターフェースを通じた人間のインタラクションを介して、前記ノードと前記仮想インターフェースの属性を提供するデータ・レコードを使用し、それらの間の所望の相互接続を指定することによって行われる請求項４１に記載のシステム。
44. 前記仮想接続グリッドは、１または複数のブレード・サーバと１または複数のスタンド−アロン汎用および／または専用コンピュータを前記ノードとして、仮想ローカル・エリア・ネットワーク（ＶＬＡＮ）とジャンボ・フレームをサポートする前記ブレード・サーバの外側のローカル・エリア・ネットワーク（ＬＡＮ）スイッチを前記１または複数の物理スイッチとして使用することによって実現される請求項２６に記載のシステム。
45. 前記ブレードと前記コンピュータのそれぞれは、前記ブレードのプロセッサと前記コンピュータに、仮想接続グリッドによって定義される多段ネットワークを通るデータ・フローの適応ルーティングを行わせるように構成されたフロー・マネジメント・ソフトウエアをストアしており、前記多段ネットワークの各段階は、１または複数のネットワーク・サービスを実行する類似に構成されたアプリケーションのクラスタを含む請求項４４に記載のシステム。
46. 前記コンピュータまたは前記ブレードの少なくとも１つは、リソース・マネジメントとプロビジョニング・ソフトウエアをストアしており、前記コンピュータおよび／または前記ブレードの残りのそれぞれは、前記コンピュータおよび／または前記ブレードのプロセッサの残りのそれぞれに、アプリケーション需要、ネットワーク・パフォーマンス、あるいはアプリケーション応答時間によって駆動されるとおりに１または複数のネットワーク・サービスの必要容量の適応プロビジョニングを行わせるように構成されたプロビジョニング・エージェント・ソフトウエアをストアする請求項４４に記載のシステム。
47. プロビジョニングが、グラフィカル・ユーザ・インターフェースを通じた人間のインタラクションを介して、前記ノードと前記仮想インターフェースを表すアイコンを使用し、それらの間の相互接続を作成することによって行われる請求項４４に記載のシステム。
48. プロビジョニングが、プログラム・インターフェースを通じた人間のインタラクションを介して、前記ノードと前記仮想インターフェースの属性を提供するデータ・レコードを使用し、それらの間の所望の相互接続を指定することによって行われる請求項４４に記載のシステム。
49. コンピュータ・ネットワーク内の第１の数のコンピュータ・システムの間の任意の相互接続を可能にするように構成された仮想接続グリッドを設定することを含み、前記コンピュータ・システムのそれぞれが、前記物理ネットワーク・スイッチング・デバイスのポートにオーバーレイされる１または複数の仮想ネットワーク（ＶＬＡＮ）の構成の結果として、物理ネットワークの接続メカニズムをエミュレートする第２の数の仮想リンクを介し、１または複数の物理ネットワーク・スイッチング・デバイスのそれぞれのポートに通信結合されることを特徴とする方法。
50. 前記仮想リンクの少なくとも１つは、前記コンピュータ・システムのうちの２つの間のポイント−ツー−ポイント接続を提供するケーブルを完全なスイッチ付き環境においてエミュレートする請求項４９に記載の方法。
51. 前記ポイント−ツー−ポイント接続は単方向である請求項５０に記載の方法。
52. 前記ポイント−ツー−ポイント接続は双方向である請求項５０に記載の方法。
53. 前記仮想リンクの少なくとも１つは、前記コンピュータ・システムのルート・コンピュータ・システムと前記コンピュータ・システムの複数のリーフ・コンピュータ・システムの間におけるポイント−ツー−マルチポイント接続を提供するケーブルを完全なスイッチ付き環境においてエミュレートする請求項４９に記載の方法。
54. 前記ポイント−ツー−マルチポイント接続は単方向である請求項５３に記載の方法。
55. 前記ポイント−ツー−マルチポイント接続は双方向である請求項５４に記載の方法。
56. 前記仮想リンクの少なくとも１つが、完全なスイッチ付き環境において、前記コンピュータ・システムの、それぞれが混交または非混交モードのいずれかで動作する複数に対するマルチ−アクセス、ブロードキャスト可能な接続を提供するハブをエミュレートする請求項４９に記載の方法。
57. 前記仮想リンクの少なくとも１つは、ユニキャスト・トラフィック分離を提供しつつ、前記コンピュータ・システムの複数に対するマルチ−アクセス、ブロードキャスト可能な接続を提供するスイッチを完全なスイッチ付き環境においてエミュレートする請求項４９に記載の方法。
58. 前記仮想リンクの少なくとも１つは、前記仮想接続グリッドの外側のネットワークと前記コンピュータ・システムの複数の間におけるトランスペアレントなブリッジ接続をエミュレートし、前記ブリッジ接続は、前記仮想接続グリッドの外側のネットワーク内のデバイスと前記コンピュータ・システムの複数の間におけるインタラクションのためのデータ・パスのトランスペアレンシーを提供する請求項４９に記載の方法。
59. 前記仮想リンクの少なくとも１つを横切る送信に先行して、パケットが、それに含まれるオリジナルのヘッダ情報が前記パケットのエンドに追加されるように修正される請求項４９に記載の方法。
60. 前記仮想リンクの少なくとも１つを横切る送信に先行して、パケットが、前記オリジナルのヘッダ情報に置き換えられる新しいヘッダ情報を有するようにさらに修正される請求項５９に記載の方法。
61. 前記新しいヘッダ情報は、前記仮想接続グリッド内における前記パケットのためのフロー・パス決定情報を含む請求項６０に記載の方法。
62. 認証情報が前記パケットに追加され、前記認証情報は、前記コンピュータ・システムのいずれが前記パケットを送信しているかを識別するように機能する請求項５９に記載の方法。
63. 前記コンピュータ・システムの１つにおける受信時に、パケットが、そのオリジナルのヘッダ情報を、前記パケットのエンドに追加された前記パケットのためのオリジナルのヘッダ情報を用いてリストアする請求項４９に記載の方法。

Images