特許 7542668 高性能コンピューティング環境での線形転送テーブル（ＬＦＴ）探索のためにグローバルルートヘッダ（ＧＲＨ）におけるサブネットプレフィックス値を用いるためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-22

(45)【発行日】2024-08-30

(54)【発明の名称】高性能コンピューティング環境での線形転送テーブル（ＬＦＴ）探索のためにグローバルルートヘッダ（ＧＲＨ）におけるサブネットプレフィックス値を用いるためのシステムおよび方法

(51)【国際特許分類】

   H04L 45/74 20220101AFI20240823BHJP

【ＦＩ】

H04L45/74

【請求項の数】 13

【外国語出願】

(21)【出願番号】P 2023033737

(22)【出願日】2023-03-06

(62)【分割の表示】P 2021164659の分割

【原出願日】2017-01-27

(65)【公開番号】P2023078206

(43)【公開日】2023-06-06

【審査請求日】2023-03-31

(31)【優先権主張番号】62/288,101

(32)【優先日】2016-01-28

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】15/416,642

(32)【優先日】2017-01-26

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】ヨンセン，ビョルン・ダグ

(72)【発明者】

【氏名】スリニバサン，アルビンド

(72)【発明者】

【氏名】ミュラー，シモン

【審査官】宮島 郁美

(56)【参考文献】

【文献】米国特許出願公開第２０１３／０２５９０３３（ＵＳ，Ａ１）

【文献】特表２０１５－５１７７６２（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１５／００９８４６６（ＵＳ，Ａ１）

【文献】米国特許出願公開第２００３／０２２３４３５（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ１２／００－１２／６６，１３／００，４１／００－４９／９０５７，６１／００－６５／８０，６９／００－６９／４０

(57)【特許請求の範囲】

【請求項1】

高性能コンピューティング環境でのネットワークスイッチ環境における線形転送テーブル探索のためにパケットヘッダを使用するための方法であって、
ネットワークファブリックを含むコンピュータ環境において、第１および第２のサブネットを提供することを備え、前記第１のサブネットは前記第２のサブネットとは異なり、前記第１のサブネットは、第１のセットのネットワークスイッチと、第１の線形転送テーブル（ＬＦＴ）と、第１の複数の物理ポートとを含み、前記第２のサブネットは、第２のセットのネットワークスイッチと、第２のＬＦＴと、第２の複数の物理ポートとを含み、前記方法はさらに、
前記第１のセットのネットワークスイッチの前記第１のＬＦＴが、前記第１のサブネットの前記第１のセットのネットワークスイッチのネットワークスイッチ間で転送されるべきパケットのサブネット内転送判断、ならびに前記第１および第２のサブネットのそれぞれの前記第１のセットのネットワークスイッチおよび前記第２のセットのネットワークスイッチの間で転送されるべきパケットのサブネット間転送判断の両方に対して用いられることを、
第１のパケットを、前記第１のサブネットの前記第１のセットのネットワークスイッチのうちの第１のネットワークスイッチで受信することと、
前記第１のパケットのローカルルートヘッダ（ＬＲＨ）を検査することと、
前記第１のパケットの前記ＬＲＨの条件を判断することと、
前記第１のＬＦＴが、前記ＬＦＴに適用される前記第１のパケットの前記ＬＲＨの選択された部分を使用して、前記第１のサブネットの前記第１の複数の物理ポートの特殊スイッチポート（ＳＳＰ）を索引付することに基づいて、前記サブネット間転送判断を行うこと、または、
前記サブネット内転送判断を行うこととによって、可能にすることを備える、高性能コンピューティング環境でのネットワークスイッチ環境における線形転送テーブル探索のためにパケットヘッダを使用するための方法。

【請求項2】

前記ＬＲＨの前記条件を判断することは、前記ＬＲＨの選択された部分を前記第１のネットワークスイッチに格納される所定の値と比較することを含み、
前記サブネット内転送判断を行うことは、前記ＬＲＨの前記選択された部分と前記第１のネットワークスイッチに格納される前記所定の値との間の不一致に基づいて、前記サブネット内転送判断を行うことを含む、請求項１に記載の方法。

【請求項3】

前記第１のパケットを、前記第２のサブネットの前記第２のセットのネットワークスイッチのうちの選択されたネットワークスイッチにルーティングすることは、
前記第１のパケットの前記ヘッダのグローバルルートヘッダ（ＧＲＨ）部分のセクションを選択することによって行われ、前記ヘッダの前記ＧＲＨ部分の前記選択されたセクションは、サブネット間ルート番号（ＩＳＲＮ）を格納し、前記ルーティングすることはさらに、
前記ＧＲＨの前記ＩＳＲＮを使用して、前記第１のネットワークスイッチの前記第１のＬＦＴを索引付けすることと、
前記ＧＲＨの前記ＩＳＲＮを使用して前記第１のＬＦＴを索引付けすることに従って、前記第１のパケットを前記第２のサブネットの前記第２のセットのネットワークスイッチのうちの前記選択されたネットワークスイッチにルーティングすることとによって行われ、前記第２のサブネットは前記ネットワークスイッチ環境の中間コアファブリックである、請求項１または２に記載の方法。

【請求項4】

前記ネットワークスイッチ環境の前記中間コアファブリックから、第２のパケットを、前記第１のサブネットの前記第１のセットのネットワークスイッチのうちの前記第１のネットワークスイッチで受信することと、
中間コアファブリックから受信される前記第２のパケットが前記ＩＳＲＮを使用して転送されていると判断することと、
前記第１のネットワークスイッチの同じ第１のＬＦＴを使用して、中間コアファブリックから受信される前記第２のパケットが、前記ＩＳＲＮを使用して、および前記第２のパケットのヘッダに含まれるターゲットローカル識別子（ＬＩＤ）を使用して転送されていると判断することに従って、前記サブネット内転送判断を行なうこととをさらに備える、請求項３に記載の方法。

【請求項5】

前記第１のネットワークスイッチでフィルタを使用して、前記第１のパケットのターゲットローカル識別子（ＬＩＤ）をフィルタリングして、前記第１のパケットが前記ＳＳＰをターゲットとしているかどうかを判断することをさらに備える、請求項１に記載の方法。

【請求項6】

前記サブネット間転送判断を行うことは、前記第１のパケットが前記ＳＳＰをターゲットとしていると判断することを含み、
前記サブネット内転送判断を行うことは、第１のパケットが前記ＳＳＰをターゲットとしていないと判断することを含む、請求項１または５に記載の方法。

【請求項7】

高性能コンピューティング環境でのネットワークスイッチ環境における線形転送テーブル探索のためにパケットヘッダを使用するためのシステムであって、
コンピュータ環境を備え、前記コンピュータ環境は、
ネットワークファブリックと、
第１のサブネットと、
第２のサブネットとを含み、前記第１のサブネットは前記第２のサブネットとは異なり、前記第１のサブネットは、第１のセットのネットワークスイッチと、第１の線形転送テーブル（ＬＦＴ）と、第１の複数の物理ポートとを含み、前記第２のサブネットは、第２のセットのネットワークスイッチと、第２のＬＦＴと、第２の複数の物理ポートとを含み、
前記第１のセットのネットワークスイッチの前記第１のＬＦＴが、前記コンピュータ環境によって、前記第１のサブネットの前記第１のセットのネットワークスイッチのネットワークスイッチ間で転送されるべきパケットのサブネット内転送判断、ならびに前記第１および第２のサブネットのそれぞれの前記第１のセットのネットワークスイッチおよび前記第２のセットのネットワークスイッチの間で転送されるべきパケットのサブネット間転送判断の両方に対して用いられ、前記コンピュータ環境は、
第１のパケットを、前記第１のサブネットの前記第１のセットのネットワークスイッチのうちの第１のネットワークスイッチで受信し、
前記第１のパケットのローカルルートヘッダ（ＬＲＨ）を検査し、
前記第１のパケットの前記ＬＲＨの条件を判断し、
前記第１のＬＦＴを使用して、
前記第１のＬＦＴが、前記ＬＦＴに適用される前記第１のパケットの前記ＬＲＨの選択された部分を使用して、前記第１のサブネットの前記第１の複数の物理ポートの特殊スイッチポート（ＳＳＰ）を索引付することに基づいて、前記サブネット間転送判断を行うか、または、
前記サブネット内転送判断を行う、高性能コンピューティング環境でのネットワークスイッチ環境における線形転送テーブル探索のためにパケットヘッダを使用するためのシステム。

【請求項8】

前記第１のサブネットの前記第１のセットのネットワークスイッチのうちの前記第１のネットワークスイッチは、
前記ＬＲＨの選択された部分を前記第１のネットワークスイッチに格納される所定の値と比較することによって前記第１のパケットの前記ＬＲＨの前記条件を判断し、
前記ＬＲＨの前記選択された部分と前記第１のネットワークスイッチに格納される前記所定の値との間の不一致に基づいて、前記サブネット内転送判断を行うよう動作可能である、請求項７に記載のシステム。

【請求項9】

前記第１のサブネットの前記第１のセットのネットワークスイッチのうちの前記第１のネットワークスイッチは、前記第１のパケットを、前記第２のサブネットの前記第２のセットのネットワークスイッチのうちの選択されたネットワークスイッチにルーティングするよう動作可能であり、前記ルーティングは、
前記第１のパケットの前記ヘッダのグローバルルートヘッダ（ＧＲＨ）部分のセクションを選択することによって行われ、前記ヘッダの前記ＧＲＨ部分の前記選択されたセクションは、サブネット間ルート番号（ＩＳＲＮ）を格納し、前記ルーティングはさらに、
前記ＧＲＨの前記ＩＳＲＮを使用して、前記第１のネットワークスイッチの前記第１のＬＦＴを索引付けすることと、
前記ＧＲＨの前記ＩＳＲＮを使用して前記第１のＬＦＴを索引付けすることに従って、前記第１のパケットを前記第２のサブネットの前記第２のセットのネットワークスイッチのうちの前記選択されたネットワークスイッチにルーティングすることとによって行われ、前記第２のサブネットは前記ネットワークスイッチ環境の中間コアファブリックである、請求項７または８に記載のシステム。

【請求項10】

前記第１のサブネットの前記第１のセットのネットワークスイッチのうちの前記第１のネットワークスイッチは、
前記ネットワークスイッチ環境の前記中間コアファブリックから、第２のパケットを、前記第１のサブネットの前記第１のセットのネットワークスイッチのうちの前記第１のネットワークスイッチで受信し、
中間コアファブリックから受信される前記第２のパケットが前記ＩＳＲＮを使用して転送されていると判断し、
前記第１のネットワークスイッチの同じ第１のＬＦＴを使用して、中間コアファブリックから受信される前記第２のパケットが、前記ＩＳＲＮを使用して、および前記第２のパケットのヘッダに含まれるターゲットローカル識別子（ＬＩＤ）を使用して転送されていると判断することに従って、前記サブネット内転送判断を行なうよう動作可能である、請求項９に記載のシステム。

【請求項11】

前記第１のサブネットの前記第１のセットのネットワークスイッチのうちの前記第１のネットワークスイッチは、
前記第１のネットワークスイッチでフィルタを使用して、前記第１のパケットのターゲットローカル識別子（ＬＩＤ）をフィルタリングして、前記第１のパケットが前記ＳＳＰをターゲットとしているかどうかを判断するよう動作可能である、請求項７に記載のシステム。

【請求項12】

前記第１のサブネットの前記第１のセットのネットワークスイッチのうちの前記第１のネットワークスイッチは、
前記第１のパケットが前記ＳＳＰをターゲットとしていないと判断することによって前記サブネット内転送判断を行ない、
前記第１のパケットが前記ＳＳＰをターゲットとしていると判断することによって前記サブネット間転送判断を行うよう動作可能である、請求項７または１１に記載のシステム。

【請求項13】

コンピュータに請求項１～６のいずれか１項に記載の方法を実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

著作権表示：
この特許文献の開示の一部は、著作権保護の対象となる資料を含む。著作権保有者は、この特許文献または特許開示の、それが特許商標庁の特許ファイルまたは記録に現れているとおりの、何人による複写複製にも異議を唱えないが、それ以外の場合にはすべての著作権をどのようなものであろうと所有する。

【0002】

発明の分野：
本発明は、一般にコンピュータシステムに関し、特に、ネットワーク環境においてネットワークスイッチ機能を提供することに関する。

【背景技術】

【0003】

背景：
導入されるクラウドコンピューティングアーキテクチャがより大規模になるのに応じて、従来のネットワークおよびストレージに関する性能および管理の障害が深刻な問題になってきている。クラウドコンピューティングファブリックのための基礎としてインフィニバンド（登録商標）（InfiniBand：ＩＢ）技術などの高性能な無損失相互接続を用いることへの関心がますます高まってきている。

【0004】

単一のＩＢサブネットにおける４８Ｋユニキャストローカル識別（ＬＩＤ）値空間は、エンドノードの数に関してサブネットのサイズの制限を表わす。仮想化されたホストチャネルアダプタ（ＨＣＡ）が複数の仮想ＨＣＡインスタンスを提供し、各そのような仮想ＨＣＡインスタンスが仮想ポートごとに独立したＬＩＤとともに構成されてもよい場合、この制限は特に重要である。

【0005】

ＩＢ標準規格では、複数のサブネットを同じＩＢファブリック内で接続して、パケット転送を、各中間サブネットごとおよび最終ターゲットサブネットについて、ファブリックワイドの１２８ビットの宛先グローバル識別子（ＤＧＩＤ）アドレス値から１６ビットの宛先ＬＩＤ（ＤＬＩＤ）アドレス値へのマッピングに基づいてサポートできるようにするために、ルータノードを定義する。

【0006】

しかしながら、ＩＢワイヤ速度で１２８ビットのＤＧＩＤ値を１６ビットのＤＬＩＤ値にマッピングするには、一意に探索できる個々のＤＧＩＤの数に関して（つまりハードウェア実装のための妥当なコスト／複雑さの制約内で）限られたスケーラビリティを有する複雑なコンテンツアドレス指定可能メモリ（ＣＡＭ）ベースの探索ハードウェアが必要である。これは、多数の個々の宛先にスケーリングするために、１２８ビットのＤＧＩＤ値を１６ビットのＤＬＩＤ値にマッピングすることは柔軟でなければならず、多数の個々のＤＧＩＤアドレスを単一の探索エントリを介してマッピングすることができるように、階層的スキームを使用できなければならないことを意味する。

【0007】

しかしながら、階層的なマッピング構造は、表現できるサブネットとエンドノードの総数に関してスケーラビリティを表わすが、それは、また、マルチサブネットファブリック全体の異なるフローおよびワークロードに対して負荷均衡およびＱＯＳ制約を維持するために個々の宛先を個別にルーティングする能力の厳しい制限も表わす。

【0008】

これは、本発明の実施形態が対処しようとする一般的な領域である。

【発明の概要】

【課題を解決するための手段】

【0009】

概要：
ここに開示されるのは、ミドルウェアおよびアプリケーション実行またはミドルウェアマシン環境のための設計されたシステムのような、ネットワーク環境においてサブネット内およびサブネット間アドレス解決をサポートできるシステムおよび方法であり、高性能コンピューティング環境での線形転送テーブル（ＬＦＴ）探索のためにグローバルルートヘッダ（ＧＲＨ）におけるサブネットプレフィックス値を用いる。例示のシステムおよび方法は、インフィニバンド（ＩＢ）アーキテクチャを有するネットワークのような高性能コンピューティング環境におけるネットワークスイッチ環境におけるＬＦＴ探索のためにＧＲＨにおけるサブネットプレフィックス値の使用を提供することができる。実施形態は、ネットワークファブリックを含むコンピュータ環境において、１つ以上のネットワークスイッチまたはホストに各々が関連付けられる１つ以上のサブネットを提供することができる。本明細書のシステムおよび方法は、サブネット内転送判断およびサブネット間転送判断の両方に同じ線形転送テーブルを使用できるようにすることができる。

【図面の簡単な説明】

【0010】

【図1】一実施形態によるインフィニバンド環境の一例を示す図である。

【図2】一実施形態による、パーティショニングされたクラスタ環境を示す図である。

【図3】一実施形態による、ネットワーク環境におけるツリートポロジを示す図である。

【図4】一実施形態に従った例示的な共有ポートアーキテクチャを示す図である。

【図5】一実施形態に従った例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。

【図6】一実施形態に従った例示的なｖＰｏｒｔアーキテクチャを示す図である。

【図7】一実施形態に従った、ＬＩＤが予めポピュレートされた例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。

【図8】一実施形態に従った、動的ＬＩＤ割当てがなされた例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。

【図9】一実施形態に従った、動的ＬＩＤ割当てがなされかつＬＩＤが予めポピュレートされているｖＳｗｉｔｃｈを備えた例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。

【図10】一実施形態による例示的なマルチサブネットインフィニバンドファブリックを示す。

【図11】一実施形態による、ネットワーク環境においてパケット転送ロジックにアクセスするためにインフィニバンド（ＩＢ）アドレス指定を使用するデータパケットフォーマットの図を示す。

【図12】一実施形態による、サブネット内およびサブネット間転送のための線形転送テーブル（ＬＦＴ）の例示的な部分を示す。

【図13】一実施形態による転送ドメインの図を示す。

【図14】一実施形態による、ＧＲＨ／ＩＳＲＮアドレス指定モードフォーマットからＬＲＨ／ＤＬＩＤベースの転送フォーマットへのパケットヘッダの修正を示す図である。

【図15】一実施形態による、ＬＲＨ／ＤＬＩＤアドレス指定モードからＧＲＨ／ＩＳＲＮアドレス指定モードにパケット転送を変更するための特殊スイッチポート境界を定義するメカニズムを提供するスイッチの図である。

【図16】一実施形態による、サブネット内転送およびサブネット間転送の両方について線形転送テーブル探索のためにパケットヘッダを使用する方法のフローチャートである。

【発明を実施するための形態】

【0011】

詳細な説明：
例示の実施形態は、同様の参照番号が同様の要素を指している添付図面の図において、限定のためではなく例示のために説明されている。なお、この開示における「ある」または「１つの」または「いくつかの」実施形態への参照は必ずしも同じ実施形態に対するものではなく、そのような参照は少なくとも１つを意味する。特定の実現例が説明されるが、これらの特定の実現例が例示的な目的のためにのみ提供されることが理解される。当業者であれば、他の構成要素および構成が、この発明の範囲および精神から逸脱することなく使用され得ることを認識するであろう。

【0012】

図面および詳細な説明全体にわたって同様の要素を示すために、共通の参照番号が使用され得る。したがって、ある図で使用される参照番号は、要素が別のところで説明される場合、そのような図に特有の詳細な説明において参照される場合もあり、または参照されない場合もある。

【0013】

高性能コンピューティング環境における線形転送テーブル（ＬＦＴ）探索のためにグローバルルートヘッダ（ＧＲＨ）におけるサブネットプレフィックス値を使用して仮想マシン（ＶＭ）のライブマイグレーションを可能にする、サブネット内およびサブネット間転送判断をサポートするシステムおよび方法がここに記載される。

【0014】

例示の実施形態の以下の説明は、高性能ネットワークのための例としてインフィニバンド^ＴＭ（ＩＢ）ネットワークを使用する。以下の説明を通して、インフィニバンド^ＴＭ規格（様々に、インフィニバンド規格、ＩＢ規格、またはレガシーＩＢ規格とも呼ばれる）を参照することができる。このような参照は、引用によりその全体が本明細書に援用される、http://www.inifinibandta.orgで入手可能なインフィニバンド（登録商標）トレード・アソシエーション・アーキテクチャ規格、第１巻、バージョン１．３（２０１５年３月リリース）を参照すると理解される。他のタイプの高性能ネットワークが何ら限定されることなく使用され得ることが、当業者には明らかであるだろう。以下の説明ではまた、ファブリックトポロジーについての一例として、ファットツリートポロジーを使用する。他のタイプのファブリックトポロジーが何ら限定されることなく使用され得ることが当業者には明らかであるだろう。

【0015】

現代（たとえばExascale（エクサスケール）時代）におけるクラウドの要求を満たすために、仮想マシンがリモート・ダイレクト・メモリ・アクセス（Remote Direct Memory Access：ＲＤＭＡ）などの低オーバーヘッドネットワーク通信パラダイムを利用できるこ
とが望ましい。ＲＤＭＡはＯＳスタックをバイパスし、ハードウェアと直接通信することで、シングルルートＩ／Ｏ仮想化（Single-Root I/O Virtualization：ＳＲ－ＩＯＶ）ネットワークアダプタのようなパススルー技術が使用可能となる。一実施形態に従うと、高性能な無損失相互接続ネットワークにおける適用可能性のために、仮想スイッチ（virtual switch：ｖＳｗｉｔｃｈ）ＳＲ－ＩＯＶアーキテクチャを提供することができる。ライブマイグレーションを実際に選択できるようにするためにネットワーク再構成時間が重要となるので、ネットワークアーキテクチャに加えて、スケーラブルであるとともにトポロジーに依存しない動的な再構成メカニズムを提供することができる。

【0016】

一実施形態に従うと、さらには、ｖＳｗｉｔｃｈを用いる仮想化された環境のためのルーティング戦略を提供することができ、ネットワークトポロジー（たとえばファットツリートポロジー）のための効率的なルーティングアルゴリズムを提供することができる。動
的な再構成メカニズムは、ファットツリーにおいて課されるオーバーヘッドを最小限にするためにさらに調整することができる。

【0017】

一実施形態に従うと、仮想化は、クラウドコンピューティングにおける効率的なリソース利用および融通性のあるリソース割当てに有益であり得る。ライブマイグレーションは、アプリケーションにトランスペアレントな態様で物理サーバ間で仮想マシン（virtual machine：ＶＭ）を移動させることによってリソース使用を最適化することを可能にする
。このため、仮想化は、ライブマイグレーションによる統合、リソースのオン・デマンド・プロビジョニングおよび融通性を可能にし得る。

【0018】

インフィニバンド（登録商標）
インフィニバンド（ＩＢ）は、インフィニバンド・トレード・アソシエーション（InfiniBand^TM Trade Association）によって開発されたオープン標準無損失ネットワーク技術である。この技術は、特に高性能コンピューティング（high-performance computing：ＨＰＣ）アプリケーションおよびデータセンタを対象とする、高スループットおよび少ない待ち時間の通信を提供するシリアルポイントツーポイント全二重相互接続（serial point-to-point full-duplex interconnect）に基づいている。

【0019】

インフィニバンド・アーキテクチャ（InfiniBand Architecture：ＩＢＡ）は、２層ト
ポロジー分割をサポートする。低層では、ＩＢネットワークはサブネットと呼ばれ、１つのサブネットは、スイッチおよびポイントツーポイントリンクを使用して相互接続される一組のホストを含み得る。より高いレベルでは、１つのＩＢファブリックは、ルータを使用して相互接続され得る１つ以上のサブネットを構成する。

【0020】

１つのサブネット内で、ホストは、スイッチおよびポイントツーポイントリンクを使用して接続され得る。加えて、サブネットにおける指定されたデバイス上に存在する、１つのマスター管理エンティティ、すなわちサブネットマネージャ（subnet manager：ＳＭ）があり得る。サブネットマネージャは、ＩＢサブネットを構成し、起動し、維持する役割を果たす。加えて、サブネットマネージャ（ＳＭ）は、ＩＢファブリックにおいてルーティングテーブル計算を行なう役割を果たし得る。ここで、たとえば、ＩＢネットワークのルーティングは、ローカルサブネットにおけるすべての送信元と宛先とのペア間の適正な負荷バランシングを目標とする。

【0021】

サブネット管理インターフェイスを通して、サブネットマネージャは、サブネット管理パケット（subnet management packet：ＳＭＰ）と呼ばれる制御パケットを、サブネット管理エージェント（subnet management agent：ＳＭＡ）と交換する。サブネット管理エ
ージェントは、すべてのＩＢサブネットデバイス上に存在する。ＳＭＰを使用することにより、サブネットマネージャは、ファブリックを発見し、エンドノードおよびスイッチを構成し、ＳＭＡから通知を受信することができる。

【0022】

一実施形態によれば、ＩＢネットワークにおけるサブネット内のルーティングは、スイッチに格納された線形転送テーブル（ＬＦＴ）に基づき得る。ＬＦＴは、使用中のルーティングメカニズムに従って、ＳＭによって計算される。サブネットでは、エンドノード上のホストチャネルアダプタ（Host Channel Adapter：ＨＣＡ）ポートおよびスイッチが、ローカル識別子（ＬＩＤ）を使用してアドレス指定される。線形転送テーブル（ＬＦＴ）における各エントリは、宛先ＬＩＤ（destination LID：ＤＬＩＤ）と出力ポートとから
なる。テーブルにおけるＬＩＤごとに１つのエントリのみがサポートされる。パケットがあるスイッチに到着すると、その出力ポートは、そのスイッチのフォワーディングテーブルにおいてＤＬＩＤを検索することによって判断される。所与の送信元－宛先ペア（ＬＩＤペア）間のネットワークにおいてパケットは同じ経路を通るため、ルーティングは決定
論的である。

【0023】

一般に、マスターサブネットマネージャを除く他のすべてのサブネットマネージャは、耐故障性のために待機モードで作動する。しかしながら、マスターサブネットマネージャが故障した状況では、待機中のサブネットマネージャによって、新しいマスターサブネットマネージャが取り決められる。マスターサブネットマネージャはまた、サブネットの周期的なスイープ（sweep）を行なってあらゆるトポロジー変化を検出し、それに応じてネ
ットワークを再構成する。

【0024】

さらに、サブネット内のホストおよびスイッチは、ローカル識別子（ＬＩＤ）を用いてアドレス指定され得るとともに、単一のサブネットは４９１５１個のユニキャストＬＩＤに制限され得る。サブネット内で有効なローカルアドレスであるＬＩＤの他に、各ＩＢデバイスは、６４ビットのグローバル一意識別子（global unique identifier：ＧＵＩＤ）を有し得る。ＧＵＩＤは、ＩＢレイヤー３（Ｌ３）アドレスであるグローバル識別子（global identifier：ＧＩＤ）を形成するために使用され得る。

【0025】

ＳＭは、ネットワーク初期化時間に、ルーティングテーブル（すなわち、サブネット内のノードの各ペア間の接続／ルート）を計算し得る。さらに、トポロジーが変化するたびに、ルーティングテーブルは、接続性および最適性能を確実にするために更新され得る。通常動作中、ＳＭは、トポロジー変化をチェックするためにネットワークの周期的なライトスイープ（light sweep）を実行し得る。ライトスイープ中に変化が発見された場合、
または、ネットワーク変化を信号で伝えるメッセージ（トラップ）をＳＭが受信した場合、ＳＭは、発見された変化に従ってネットワークを再構成し得る。

【0026】

たとえば、ＳＭは、リンクがダウンした場合、デバイスが追加された場合、またはリンクが除去された場合など、ネットワークトポロジーが変化する場合に、ネットワークを再構成し得る。再構成ステップは、ネットワーク初期化中に行なわれるステップを含み得る。さらに、再構成は、ネットワーク変化が生じたサブネットに制限されるローカルスコープを有し得る。また、ルータを用いる大規模ファブリックのセグメント化は、再構成スコープを制限し得る。

【0027】

一実施形態に従ったインフィニバンド環境１００の例を示す図１に、インフィニバンドファブリックの一例を示す。図１に示す例では、ノードＡ１０１～Ｅ１０５は、インフィニバンドファブリック１２０を使用して、それぞれのホストチャネルアダプタ１１１～１１５を介して通信する。一実施形態に従うと、さまざまなノード（たとえばノードＡ１０１～Ｅ１０５）はさまざまな物理デバイスによって表わすことができる。一実施形態に従うと、さまざまなノード（たとえばノードＡ１０１～Ｅ１０５）は仮想マシンなどのさまざまな仮想デバイスによって表わすこともできる。

【0028】

インフィニバンドにおけるパーティショニング
一実施形態によれば、ＩＢネットワークは、ネットワークファブリックを共有するシステムの論理グループの分離をもたらすためにセキュリティメカニズムとしてパーティショニングをサポートし得る。ファブリックにおけるノード上の各ＨＣＡポートは、１つ以上のパーティションのメンバであり得る。パーティションメンバーシップは、ＳＭの一部であり得る集中型パーティションマネージャによって管理される。ＳＭは、各ポートに関するパーティションメンバーシップ情報を、１６ビットのパーティションキー（partition key：Ｐ＿キー）のテーブルとして構成することができる。ＳＭはまた、これらのポート
を介してデータトラフィックを送信または受信するエンドノードに関連付けられたＰ＿Ｋｅｙ情報を含むパーティション実施テーブルを用いて、スイッチポートおよびルータポートを構成することができる。加えて、一般的な場合には、スイッチポートのパーティショ
ンメンバーシップは、（リンクに向かう）出口方向に向かってポートを介してルーティングされたＬＩＤに間接的に関連付けられたすべてのメンバーシップの集合を表わし得る。

【0029】

一実施形態によれば、パーティションは、あるグループのメンバが同じ論理グループの他のメンバとしか通信できないような、ポートの論理グループである。ホストチャネルアダプタ（ＨＣＡ）およびスイッチでは、パーティションメンバシップ情報を使用してパケットをフィルタリングして分離を実行できる。無効なパーティショニング情報を持つパケットは、そのパケットが着信ポートに到着するとすぐにドロップすることができる。パーティショニングされたＩＢシステムでは、パーティションを使用してテナントクラスタを作成できる。パーティションの適所における実施で、ノードは異なるテナントクラスタに属する他のノードと通信することはできない。このようにして、侵害されたテナントノードまたは悪意のあるテナントノードが存在する場合でも、システムのセキュリティを保証することができる。

【0030】

一実施形態によれば、ノード間の通信のために、管理キューペア（ＱＰ０およびＱＰ１）を除き、キューペア（Queue Pair：ＱＰ）およびエンドツーエンドコンテキスト（End-to-End context：ＥＥＣ）を特定のパーティションに割当てることができる。次に、Ｐ＿キー情報を、送信されたすべてのＩＢトランスポートパケットに追加することができる。パケットがＨＣＡポートまたはスイッチに到着すると、そのＰ＿キー値を、ＳＭによって構成されたテーブルに対して確認することができる。無効のＰ＿キー値が見つかった場合、そのパケットは直ちに破棄される。このように、通信は、パーティションを共有するポート間でのみ許可される。

【0031】

ＩＢパーティションのある例が、図２に示されており、それは、一実施形態による、パーティショニングされたクラスタ環境を示している。図２に示す例では、ノードＡ～Ｅ１０１～１０５は、インフィニバンドファブリック１２０を使用して、それぞれのホストチャネルアダプタ１１１～１１５を介して通信する。ノードＡ～Ｅは、パーティション、すなわちパーティション１，１３０、パーティション２，１４０、およびパーティション３，１５０に配置される。パーティション１は、ノードＡ１０１およびノードＤ１０４を含む。パーティション２は、ノードＡ１０１、ノードＢ１０２、およびノードＣ１０３を含む。パーティション３は、ノードＣ１０３およびノードＥ１０５を含む。パーティションの配置のため、ノードＤ１０４とノードＥ１０５とは、これらのノードがパーティションを共有しないので、通信することができない。一方、例えば、ノードＡ１０１とノードＣ１０３とは、これらのノードが両方ともパーティション２，１４０のメンバであるため、通信が許可される。

【0032】

インフィニバンドにおける仮想マシン
過去１０年の間に、ハードウェア仮想化サポートによってＣＰＵオーバーヘッドが実質的に排除され、メモリ管理ユニットを仮想化することによってメモリオーバーヘッドが著しく削減され、高速ＳＡＮストレージまたは分散型ネットワークファイルシステムの利用によってストレージオーバーヘッドが削減され、シングルルートＩ／Ｏ仮想化（Single Root Input/Output Virtualization：ＳＲ－ＩＯＶ）のようなデバイス・パススルー技術
を使用することによってネットワークＩ／Ｏオーバーヘッドが削減されてきたことに応じて、仮想化された高性能コンピューティング（High Performance Computing：ＨＰＣ）環境の将来見通しが大幅に改善されてきた。現在では、クラウドが、高性能相互接続ソリューションを用いて仮想ＨＰＣ（virtual HPC：ｖＨＰＣ）クラスタに対応し、必要な性能
を提供することができる。

【0033】

しかしながら、インフィニバンド（ＩＢ）などの無損失ネットワークと連結されたとき、仮想マシン（ＶＭ）のライブマイグレーションなどのいくつかのクラウド機能は、これ
らのソリューションにおいて用いられる複雑なアドレス指定およびルーティングスキームのせいで、依然として問題となる。ＩＢは、高帯域および低レイテンシを提供する相互接続ネットワーク技術であり、このため、ＨＰＣおよび他の通信集約型の作業負荷に非常によく適している。

【0034】

ＩＢデバイスをＶＭに接続するための従来のアプローチは直接割当てされたＳＲ－ＩＯＶを利用することによるものである。しかしながら、ＳＲ－ＩＯＶを用いてＩＢホストチャネルアダプタ（ＨＣＡ）に割当てられたＶＭのライブマイグレーションを実現することは難易度の高いものであることが判明した。各々のＩＢが接続されているノードは、３つの異なるアドレス（すなわちＬＩＤ、ＧＵＩＤおよびＧＩＤ）を有する。ライブマイグレーションが発生すると、これらのアドレスのうち１つ以上が変化する。マイグレーション中のＶＭ（VM-in-migration）と通信する他のノードは接続性を失う可能性がある。これ
が発生すると、ＩＢサブネットマネージャ（Subnet Manager：ＳＭ）にサブネット管理（Subnet Administration：ＳＡ）経路記録クエリを送信することによって、再接続すべき
仮想マシンの新しいアドレスを突きとめることにより、失われた接続を回復させるように試みることができる。

【0035】

インフィニバンドにおける層およびアドレス指定
ＩＢアーキテクチャは、複数の層に分割され、複数の層の各々は、他の層とは別々にかつ独立して動作する。ＩＢ層抽象化の一端では、ＩＢ物理層はＩＢシステムの電気的および機械的特性を定義し、ＩＢ層抽象化の他端では、ＩＢ上位層はホストとリモートクライアントとの間でトランザクションを通信する。ＩＢトランスポート層は、それぞれ、データの送受信時に、パーティショニング、チャネル多重化、トランスポートサービス、ならびにパケットセグメンテーションおよび再アセンブリを提供するように動作する。サブネット内におけるパケット転送およびスイッチングはＩＢリンク層で処理され、ＩＢネットワーク層はあるサブネットから別のサブネットへのパケットのルーティングを処理する。

【0036】

一般に、ネットワーク層は、単一のサブネット内および異なるサブネット間でパケットをルーティングするためのプロトコルを定義する。このために、ＩＢアーキテクチャは３つの異なるタイプのアドレスを使用する。第１のタイプのＩＢアドレスは、１６ビットのローカル識別子（ＬＩＤ）である。少なくとも１つの一意のＬＩＤがＳＭによって各ＨＣＡポートおよび各スイッチに割り当てられる。ＬＩＤは、サブネット内においてトラフィックをルーティングするために使用され、リンクレベルスイッチングは、パケットを、パケットのローカルルートヘッダ（ＬＲＨ）内のソースＬＩＤ（ＳＬＩＤ）によって指定されるデバイスから、ローカルルートヘッダＬＲＨ内の宛先ＬＩＤ（ＤＬＩＤ）によって指定されるデバイスに転送する。ＬＩＤが１６ビット長であるので、６５５３６個の固有のアドレス組合せを構成することができ、そのうち４９１５１個（０×０００１－０×ＢＦＦＦ）だけをユニキャストアドレスとして用いることができる。結果として、入手可能なユニキャストアドレスの数は、ＩＢサブネットの最大サイズを定義することとなる。

【0037】

第２のタイプのＩＢアドレスは、製造業者によって各々のデバイス（たとえば、ＨＣＡおよびスイッチ）ならびに各々のＨＣＡポートに割当てられた６４ビットのグローバル一意識別子（ＧＵＩＤ）である。ＳＭは、ＨＣＡポートに追加のサブネット固有ＧＵＩＤを割当ててもよく、これは、ＳＲ－ＩＯＶが用いられる場合に有用となる。ネットワーク層で動作するルータは、異なるサブネット間でグローバルルートヘッダ（ＧＲＨ）を含むパケットを送信する。ルータは、各デバイスの一意のＧＵＩＤを使用して、サブネット間でパケットを転送する。このプロセスでは、宛先サブネットにおける宛先ポートに向かうパケット経路における最後のルータは、ＬＲＨにおけるソースＬＩＤを宛先ポートの適切なＬＩＤに置き換えることによって、パケットのＬＲＨを修正する。

【0038】

第３のタイプのアドレスは１２８ビットのグローバル識別子（ＧＩＤ）である。ＧＩＤは有効なＩＰｖ６ユニキャストアドレスであり、少なくとも１つが各々のＨＣＡポートに割当てられている。ＧＩＤは、ファブリックアドミニストレータによって割当てられたグローバルに固有の６４ビットプレフィックスと各々のＨＣＡポートのＧＵＩＤアドレスとを組合わせることによって形成される。ＧＩＤはＬＩＤから独立しているため、サブネットの再構成によって影響を受けないままである。

【0039】

ファットツリー（Fat Tree：ＦＴｒｅｅ）トポロジーおよびルーティング
一実施形態によれば、ＩＢベースのＨＰＣシステムのいくつかは、ファットツリートポロジーを採用して、ファットツリーが提供する有用な特性を利用する。これらの特性は、各送信元宛先ペア間の複数経路の利用可能性に起因する、フルバイセクション帯域幅および固有の耐故障性を含む。ファットツリーの背後にある初期の概念は、ツリーがトポロジーのルート（root）に近づくにつれて、より利用可能な帯域幅を用いて、ノード間のより太いリンクを採用することであった。より太いリンクは、上位レベルのスイッチにおける輻輳を回避するのに役立てることができ、バイセクション帯域幅が維持される。

【0040】

図３は、一実施形態に従った、ネットワーク環境におけるツリートポロジーの例を示す。図３に示すように、ネットワークファブリック２００において、１つ以上のエンドノード２０１～２０４が接続され得る。ネットワークファブリック２００は、複数のリーフスイッチ２１１～２１４と複数のスパインスイッチまたはルート（root）スイッチ２３１～２３４とを含むファットツリートポロジーに基づき得る。加えて、ネットワークファブリック２００は、スイッチ２２１～２２４などの１つ以上の中間スイッチを含み得る。

【0041】

また、図３に示すように、エンドノード２０１～２０４の各々は、マルチホームノード、すなわち、複数のポートを介してネットワークファブリック２００のうち２つ以上の部分に接続される単一のノードであり得る。たとえば、ノード２０１はポートＨ１およびＨ２を含み、ノード２０２はポートＨ３およびＨ４を含み、ノード２０３はポートＨ５およびＨ６を含み、ノード２０４はポートＨ７およびＨ８を含み得る。

【0042】

加えて、各スイッチは複数のスイッチポートを有し得る。たとえば、ルートスイッチ２３１はスイッチポート１～２を有し、ルートスイッチ２３２はスイッチポート３～４を有し、ルートスイッチ２３３はスイッチポート５～６を有し、ルートスイッチ２３４はスイッチポート７～８を有し得る。

【0043】

一実施形態によれば、ファットツリールーティングメカニズムは、ＩＢベースのファットツリートポロジーに関して最も人気のあるルーティングアルゴリズムのうちの１つである。ファットツリールーティングメカニズムはまた、ＯＦＥＤ（Open Fabric Enterprise
Distribution：ＩＢベースのアプリケーションを構築しデプロイするための標準ソフト
ウェアスタック）サブネットマネージャ、すなわちＯｐｅｎＳＭにおいて実現される。

【0044】

ファットツリールーティングメカニズムの目的は、ネットワークファブリックにおけるリンクにわたって最短経路ルートを均一に広げるＬＦＴを生成することである。このメカニズムは、索引付け順序でファブリックを横断し、エンドノードの目標ＬＩＤ、ひいては対応するルートを各スイッチポートに割当てる。同じリーフスイッチに接続されたエンドノードについては、索引付け順序は、エンドノードが接続されるスイッチポートに依存し得る（すなわち、ポートナンバリングシーケンス）。各ポートについては、メカニズムはポート使用カウンタを維持することができ、新しいルートが追加されるたびに、ポート使用カウンタを使用して使用頻度が最小のポートを選択することができる。

【0045】

一実施形態に従うと、パーティショニングされたサブネットでは、共通のパーティショ
ンのメンバではないノードは通信することを許可されない。実際には、これは、ファットツリールーティングアルゴリズムによって割当てられたルートのうちのいくつかがユーザトラフィックのために使用されないことを意味する。ファットツリールーティングメカニズムが、それらのルートについてのＬＦＴを、他の機能的経路と同じやり方で生成する場合、問題が生じる。この動作は、リンク上でバランシングを劣化させるおそれがある。なぜなら、ノードが索引付けの順序でルーティングされているからである。パーティションに気づかずにルーティングが行なわれるため、ファットツリーでルーティングされたサブネットにより、概して、パーティション間の分離が不良なものとなる。

【0046】

一実施形態に従うと、ファットツリーは、利用可能なネットワークリソースでスケーリングすることができる階層ネットワークトポロジーである。さらに、ファットツリーは、さまざまなレベルの階層に配置された商品スイッチを用いて容易に構築される。さらに、ｋ－ａｒｙ－ｎ－ｔｒｅｅ、拡張された一般化ファットツリー（Extended Generalized Fat-Tree：ＸＧＦＴ）、パラレルポート一般化ファットツリー（Parallel Ports Generalized Fat-Tree：ＰＧＦＴ）およびリアルライフファットツリー（Real Life Fat-Tree：ＲＬＦＴ）を含むファットツリーのさまざまな変形例が、一般に利用可能である。

【0047】

また、ｋ－ａｒｙ－ｎ－ｔｒｅｅは、ｎレベルのファットツリーであって、ｋ^ｎエンドノードと、ｎ・ｋ^ｎ＿１スイッチとを備え、各々が２ｋポートを備えている。各々のスイッチは、ツリーにおいて上下方向に同数の接続を有している。ＸＧＦＴファットツリーは、スイッチのための異なる数の上下方向の接続と、ツリーにおける各レベルでの異なる数の接続とをともに可能にすることによって、ｋ－ａｒｙ－ｎ－ｔｒｅｅを拡張させる。ＰＧＦＴ定義はさらに、ＸＧＦＴトポロジーを拡張して、スイッチ間の複数の接続を可能にする。多種多様なトポロジーはＸＧＦＴおよびＰＧＦＴを用いて定義することができる。しかしながら、実用化するために、現代のＨＰＣクラスタにおいて一般に見出されるファットツリーを定義するために、ＰＧＦＴの制限バージョンであるＲＬＦＴが導入されている。ＲＬＦＴは、ファットツリーにおけるすべてのレベルに同じポートカウントスイッチを用いている。

【0048】

入出力（Input/Output：Ｉ／Ｏ）仮想化
一実施形態に従うと、Ｉ／Ｏ仮想化（I/O Virtualization：ＩＯＶ）は、基礎をなす物理リソースに仮想マシン（ＶＭ）がアクセスすることを可能にすることによって、Ｉ／Ｏを利用可能にすることができる。ストレージトラフィックとサーバ間通信とを組合せると、シングルサーバのＩ／Ｏリソースにとって抗し難い高い負荷が課され、結果として、データの待機中に、バックログが発生し、プロセッサがアイドル状態になる可能性がある。Ｉ／Ｏ要求の数が増えるにつれて、ＩＯＶにより利用可能性をもたらすことができ、最新のＣＰＵ仮想化において見られる性能レベルに匹敵するように、（仮想化された）Ｉ／Ｏリソースの性能、スケーラビリティおよび融通性を向上させることができる。

【0049】

一実施形態に従うと、Ｉ／Ｏリソースの共有を可能にして、ＶＭからリソースへのアクセスが保護されることを可能にし得るようなＩＯＶが所望される。ＩＯＶは、ＶＭにエクスポーズされる論理装置を、その物理的な実装から分離する。現在、エミュレーション、準仮想化、直接的な割当て（direct assignment：ＤＡ）、およびシングルルートＩ／Ｏ
仮想化（ＳＲ－ＩＯＶ）などのさまざまなタイプのＩＯＶ技術が存在し得る。

【0050】

一実施形態に従うと、あるタイプのＩＯＶ技術としてソフトウェアエミュレーションがある。ソフトウェアエミュレーションは分離されたフロントエンド／バックエンド・ソフトウェアアーキテクチャを可能にし得る。フロントエンドはＶＭに配置されたデバイスドライバであり得、Ｉ／Ｏアクセスをもたらすためにハイパーバイザによって実現されるバックエンドと通信し得る。物理デバイス共有比率は高く、ＶＭのライブマイグレーション
はネットワークダウンタイムのわずか数ミリ秒で実現可能である。しかしながら、ソフトウェアエミュレーションはさらなる不所望な計算上のオーバーヘッドをもたらしてしまう。

【0051】

一実施形態に従うと、別のタイプのＩＯＶ技術として直接的なデバイスの割当てがある。直接的なデバイスの割当てでは、Ｉ／ＯデバイスをＶＭに連結する必要があるが、デバイスはＶＭ間では共有されない。直接的な割当てまたはデバイス・パススルーは、最小限のオーバーヘッドでほぼ固有の性能を提供する。物理デバイスはハイパーバイザをバイパスし、直接、ＶＭに取付けられている。しかしながら、このような直接的なデバイスの割当ての欠点は、仮想マシン間で共有がなされないため、１枚の物理ネットワークカードが１つのＶＭと連結されるといったように、スケーラビリティが制限されてしまうことである。

【0052】

一実施形態に従うと、シングルルートＩＯＶ（Single Root IOV：ＳＲ－ＩＯＶ）は、
ハードウェア仮想化によって、物理装置がその同じ装置の複数の独立した軽量のインスタンスとして現われることを可能にし得る。これらのインスタンスは、パススルー装置としてＶＭに割当てることができ、仮想機能（Virtual Function：ＶＦ）としてアクセスすることができる。ハイパーバイザは、（１つのデバイスごとに）固有の、十分な機能を有する物理機能（Physical Function：ＰＦ）によってデバイスにアクセスする。ＳＲ－ＩＯ
Ｖは、純粋に直接的に割当てする際のスケーラビリティの問題を軽減する。しかしながら、ＳＲ－ＩＯＶによって提示される問題は、それがＶＭマイグレーションを損なう可能性があることである。これらのＩＯＶ技術の中でも、ＳＲ－ＩＯＶは、ほぼ固有の性能を維持しながらも、複数のＶＭから単一の物理デバイスに直接アクセスすることを可能にする手段を用いてＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）規格を拡張することができる。これにより、ＳＲ－ＩＯＶは優れた性能およびスケーラビリティを提供することができる。

【0053】

ＳＲ－ＩＯＶは、ＰＣＩｅデバイスが、各々のゲストに１つの仮想デバイスを割当てることによって複数のゲスト間で共有することができる複数の仮想デバイスをエクスポーズすることを可能にする。各々のＳＲ－ＩＯＶデバイスは、少なくとも１つの物理機能（ＰＦ）と、１つ以上の関連付けられた仮想機能（ＶＦ）とを有する。ＰＦは、仮想マシンモニタ（virtual machine monitor：ＶＭＭ）またはハイパーバイザによって制御される通
常のＰＣＩｅ機能であるのに対して、ＶＦは軽量のＰＣＩｅ機能である。各々のＶＦはそれ自体のベースアドレス（base address：ＢＡＲ）を有しており、固有のリクエスタＩＤが割当てられている。固有のリクエスタＩＤは、Ｉ／Ｏメモリ管理ユニット（I/O memory
management unit：ＩＯＭＭＵ）がさまざまなＶＦへの／からのトラフィックストリームを区別することを可能にする。ＩＯＭＭＵはまた、メモリを適用して、ＰＦとＶＦとの間の変換を中断する。

【0054】

しかし、残念ながら、直接的デバイス割当て技術は、仮想マシンのトランスペアレントなライブマイグレーションがデータセンタ最適化のために所望されるような状況においては、クラウドプロバイダにとって障壁となる。ライブマイグレーションの本質は、ＶＭのメモリ内容がリモートハイパーバイザにコピーされるという点である。さらに、ＶＭがソースハイパーバイザにおいて中断され、ＶＭの動作が宛先において再開される。ソフトウェアエミュレーション方法を用いる場合、ネットワークインターフェイスは、それらの内部状態がメモリに記憶され、さらにコピーされるように仮想的である。このため、ダウンタイムは数ミリ秒にまで減らされ得る。

【0055】

しかしながら、ＳＲ－ＩＯＶなどの直接的デバイス割当て技術が用いられる場合、マイグレーションはより困難になる。このような状況においては、ネットワークインターフェイスの内部状態全体は、それがハードウェアに結び付けられているのでコピーすることが
できない。代わりに、ＶＭに割当てられたＳＲ－ＩＯＶ ＶＦが分離され、ライブマイグレーションが実行されることとなり、新しいＶＦが宛先において付与されることとなる。インフィニバンドおよびＳＲ－ＩＯＶの場合、このプロセスがダウンタイムを数秒のオーダでもたらす可能性がある。さらに、ＳＲ－ＩＯＶ共有型ポートモデルにおいては、ＶＭのアドレスがマイグレーション後に変化することとなり、これにより、ＳＭにオーバーヘッドが追加され、基礎をなすネットワークファブリックの性能に対して悪影響が及ぼされることとなる。

【0056】

インフィニバンドＳＲ－ＩＯＶアーキテクチャ－共有ポート
さまざまなタイプのＳＲ－ＩＯＶモデル（たとえば共有ポートモデル、仮想スイッチモデルおよび仮想ポートモデル）があり得る。

【0057】

図４は、一実施形態に従った例示的な共有ポートアーキテクチャを示す。図に示されるように、ホスト３００（たとえばホストチャネルアダプタ）はハイパーバイザ３１０と対話し得る。ハイパーバイザ３１０は、さまざまな仮想機能３３０、３４０および３５０をいくつかの仮想マシンに割当て得る。同様に、物理機能はハイパーバイザ３１０によって処理することができる。

【0058】

一実施形態に従うと、図４に示されるような共有ポートアーキテクチャを用いる場合、ホスト（たとえばＨＣＡ）は、物理機能３２０と仮想機能３３０、３５０、３５０との間において単一の共有ＬＩＤおよび共有キュー対（Queue Pair：ＱＰ）のスペースがあるネットワークにおいて単一のポートとして現われる。しかしながら、各々の機能（すなわち、物理機能および仮想機能）はそれら自体のＧＩＤを有し得る。

【0059】

図４に示されるように、一実施形態に従うと、さまざまなＧＩＤを仮想機能および物理機能に割当てることができ、特別のキュー対であるＱＰ０およびＱＰ１（すなわちインフィニバンド管理パケットのために用いられる専用のキュー対）が物理機能によって所有される。これらのＱＰはＶＦにも同様にエクスポーズされるが、ＶＦはＱＰ０を使用することが許可されておらず（ＶＦからＱＰ０に向かって入来するすべてのＳＭＰが破棄され）、ＱＰ１は、ＰＦが所有する実際のＱＰ１のプロキシとして機能し得る。

【0060】

一実施形態に従うと、共有ポートアーキテクチャは、（仮想機能に割当てられることによってネットワークに付随する）ＶＭの数によって制限されることのない高度にスケーラブルなデータセンタを可能にし得る。なぜなら、ネットワークにおける物理的なマシンおよびスイッチによってＬＩＤスペースが消費されるだけであるからである。

【0061】

しかしながら、共有ポートアーキテクチャの欠点は、トランスペアレントなライブマイグレーションを提供することができない点であり、これにより、フレキシブルなＶＭ配置についての可能性が妨害されてしまう。各々のＬＩＤが特定のハイパーバイザに関連付けられており、かつハイパーバイザ上に常駐するすべてのＶＭ間で共有されているので、マイグレートしているＶＭ（すなわち、宛先ハイパーバイザにマイグレートする仮想マシン）は、そのＬＩＤを宛先ハイパーバイザのＬＩＤに変更させなければならない。さらに、ＱＰ０アクセスが制限された結果、サブネットマネージャはＶＭの内部で実行させることができなくなる。

【0062】

インフィニバンドＳＲ－ＩＯＶアーキテクチャモデル－仮想スイッチ（ｖＳｗｉｔｃｈ）
図５は、一実施形態に従った例示的なｖＳｗｉｔｃｈアーキテクチャを示す。図に示されるように、ホスト４００（たとえばホストチャネルアダプタ）はハイパーバイザ４１０と対話することができ、当該ハイパーバイザ４１０は、さまざまな仮想機能４３０、４４
０および４５０をいくつかの仮想マシンに割当てることができる。同様に、物理機能はハイパーバイザ４１０によって処理することができる。仮想スイッチ４１５もハイパーバイザ４０１によって処理することができる。

【0063】

一実施形態に従うと、ｖＳｗｉｔｃｈアーキテクチャにおいては、各々の仮想機能４３０、４４０、４５０は完全な仮想ホストチャネルアダプタ（virtual Host Channel Adapter：ｖＨＣＡ）であり、これは、ハードウェアにおいて、ＶＦに割当てられたＶＭに、ＩＢアドレス一式（たとえばＧＩＤ、ＧＵＩＤ、ＬＩＤ）および専用のＱＰスペースが割当てられていることを意味する。残りのネットワークおよびＳＭについては、ＨＣＡ４００は、仮想スイッチ４１５を介して追加のノードが接続されているスイッチのように見えている。ハイパーバイザ４１０はＰＦ４２０を用いることができ、（仮想機能に付与された）ＶＭはＶＦを用いることができる。

【0064】

一実施形態に従うと、ｖＳｗｉｔｃｈアーキテクチャは、トランスペアレントな仮想化を提供する。しかしながら、各々の仮想機能には固有のＬＩＤが割当てられているので、利用可能な数のＬＩＤが速やかに消費される。同様に、多くのＬＩＤアドレスが（すなわち、各々の物理機能および各々の仮想機能ごとに１つずつ）使用されている場合、より多くの通信経路をＳＭによって演算しなければならず、それらのＬＦＴを更新するために、より多くのサブネット管理パケット（ＳＭＰ）をスイッチに送信しなければならない。たとえば、通信経路の演算は大規模ネットワークにおいては数分かかる可能性がある。ＬＩＤスペースが４９１５１個のユニキャストＬＩＤに制限されており、（ＶＦを介する）各々のＶＭとして、物理ノードおよびスイッチがＬＩＤを１つずつ占有するので、ネットワークにおける物理ノードおよびスイッチの数によってアクティブなＶＭの数が制限されてしまい、逆の場合も同様に制限される。

【0065】

インフィニバンドＳＲ－ＩＯＶアーキテクチャモデル－仮想ポート（ｖＰｏｒｔ）
図６は、一実施形態に従った例示的なｖＰｏｒｔの概念を示す。図に示されるように、ホスト３００（たとえばホストチャネルアダプタ）は、さまざまな仮想機能３３０、３４０および３５０をいくつかの仮想マシンに割当てることができるハイパーバイザ４１０と対話することができる。同様に、物理機能はハイパーバイザ３１０によって処理することができる。

【0066】

一実施形態に従うと、ベンダーに実装の自由を与えるためにｖＰｏｒｔ概念は緩やかに定義されており（たとえば、当該定義では、実装がＳＲＩＯＶ専用とすべきであるとは規定されていない）、ｖＰｏｒｔの目的は、ＶＭがサブネットにおいて処理される方法を標準化することである。ｖＰｏｒｔ概念であれば、空間ドメインおよび性能ドメインの両方においてよりスケーラブルであり得る、ＳＲ－ＩＯＶ共有のポートのようなアーキテクチャおよびｖＳｗｉｔｃｈのようなアーキテクチャの両方、または、これらのアーキテクチャの組合せが規定され得る。また、ｖＰｏｒｔはオプションのＬＩＤをサポートするとともに、共有のポートとは異なり、ＳＭは、ｖＰｏｒｔが専用のＬＩＤを用いていなくても、サブネットにおいて利用可能なすべてのｖＰｏｒｔを認識する。

【0067】

インフィニバンドＳＲ－ＩＯＶアーキテクチャモデル－ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈ
一実施形態に従うと、本開示は、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャを提供するためのシステムおよび方法を提供する。

【0068】

図７は、一実施形態に従った、ＬＩＤが予めポピュレートされた例示的なｖＳｗｉｔｃｈアーキテクチャを示す。図に示されるように、いくつかのスイッチ５０１～５０４は、ネットワーク切替環境６００（たとえばＩＢサブネット）内においてインフィニバンドフ
ァブリックなどのファブリックのメンバ間で通信を確立することができる。ファブリックはホストチャネルアダプタ５１０、５２０、５３０などのいくつかのハードウェアデバイスを含み得る。さらに、ホストチャネルアダプタ５１０、５２０および５３０は、それぞれ、ハイパーバイザ５１１、５２１および５３１と対話することができる。各々のハイパーバイザは、さらに、ホストチャネルアダプタと共に、いくつかの仮想機能５１４、５１５、５１６、５２４、５２５、５２６、５３４、５３５および５３６と対話し、設定し、いくつかの仮想マシンに割当てることができる。たとえば、仮想マシン１ ５５０はハイパーバイザ５１１によって仮想機能１ ５１４に割当てることができる。ハイパーバイザ５１１は、加えて、仮想マシン２ ５５１を仮想機能２ ５１５に割当て、仮想マシン３
５５２を仮想機能３ ５１６に割当てることができる。ハイパーバイザ５３１は、さらに、仮想マシン４ ５５３を仮想機能１ ５３４に割当てることができる。ハイパーバイザは、ホストチャネルアダプタの各々の上で十分な機能を有する物理機能５１３、５２３および５３３を介してホストチャネルアダプタにアクセスすることができる。

【0069】

一実施形態に従うと、スイッチ５０１～５０４の各々はいくつかのポート（図示せず）を含み得る。いくつかのポートは、ネットワーク切替環境６００内においてトラフィックを方向付けるためにリニアフォワーディングテーブルを設定するのに用いられる。

【0070】

一実施形態に従うと、仮想スイッチ５１２、５２２および５３２は、それぞれのハイパーバイザ５１１、５２１、５３１によって処理することができる。このようなｖＳｗｉｔｃｈアーキテクチャにおいては、各々の仮想機能は完全な仮想ホストチャネルアダプタ（ｖＨＣＡ）であり、これは、ハードウェアにおいて、ＶＦに割当てられたＶＭに、ＩＢアドレス一式（たとえばＧＩＤ、ＧＵＩＤ、ＬＩＤ）および専用のＱＰスペースが割当てられていることを意味する。残りのネットワークおよびＳＭ（図示せず）については、ＨＣＡ５１０、５２０および５３０は、仮想スイッチを介して追加のノードが接続されているスイッチのように見えている。

【0071】

一実施形態に従うと、本開示は、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャを提供するためのシステムおよび方法を提供する。図７を参照すると、ＬＩＤは、さまざまな物理機能５１３、５２３および５３３に、さらには、仮想機能５１４～５１６、５２４～５２６、５３４～５３６（その時点でアクティブな仮想マシンに関連付けられていない仮想機能であっても）にも、予めポピュレートされている。たとえば、物理機能５１３はＬＩＤ１が予めポピュレートされており、仮想機能１ ５３４はＬＩＤ１０が予めポピュレートされている。ネットワークがブートされているとき、ＬＩＤはＳＲ－ＩＯＶ ｖＳｗｉｔｃｈ対応のサブネットにおいて予めポピュレートされている。ＶＦのすべてがネットワークにおけるＶＭによって占有されていない場合であっても、ポピュレートされたＶＦには、図７に示されるようにＬＩＤが割当てられている。

【0072】

一実施形態に従うと、多くの同様の物理的なホストチャネルアダプタが２つ以上のポートを有することができ（冗長性のために２つのポートが共用となっている）、仮想ＨＣＡも２つのポートで表わされ、１つまたは２つ以上の仮想スイッチを介して外部ＩＢサブネットに接続され得る。

【0073】

一実施形態に従うと、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャにおいては、各々のハイパーバイザは、それ自体のための１つのＬＩＤをＰＦを介して消費し、各々の追加のＶＦごとに１つ以上のＬＩＤを消費することができる。ＩＢサブネットにおけるすべてのハイパーバイザにおいて利用可能なすべてのＶＦを合計すると、サブネットにおいて実行することが可能なＶＭの最大量が得られる。たとえば、サブネット内の１ハイパーバイザごとに１６個の仮想機能を備えたＩＢサブネットにおいては、各々のハイパーバイザは、サブネットにおいて１７個のＬＩＤ（１６個の仮想機能ごとに１つの
ＬＩＤと、物理機能のために１つのＬＩＤ）を消費する。このようなＩＢサブネットにおいては、単一のサブネットについて理論上のハイパーバイザ限度は利用可能なユニキャストＬＩＤの数によって規定されており、（４９１５１個の利用可能なＬＩＤをハイパーバイザごとに１７個のＬＩＤで割って得られる）２８９１であり、ＶＭの総数（すなわち限度）は（ハイパーバイザごとに２８９１個のハイパーバイザに１６のＶＦを掛けて得られる）４６２５６である（実質的には、ＩＢサブネットにおける各々のスイッチ、ルータまたは専用のＳＭノードが同様にＬＩＤを消費するので、これらの数は実際にはより小さくなる）。なお、ｖＳｗｉｔｃｈが、ＬＩＤをＰＦと共有することができるので、付加的なＬＩＤを占有する必要がないことに留意されたい。

【0074】

一実施形態に従うと、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャにおいては、ネットワークが一旦ブートされると、すべてのＬＩＤについて通信経路が計算される。新しいＶＭを始動させる必要がある場合、システムは、サブネットにおいて新しいＬＩＤを追加する必要はない。それ以外の場合、経路の再計算を含め、ネットワークを完全に再構成させ得る動作は、最も時間を消費する要素となる。代わりに、ＶＭのための利用可能なポートはハイパーバイザのうちの１つに位置し（すなわち利用可能な仮想機能）、仮想マシンは利用可能な仮想機能に付与されている。

【0075】

一実施形態に従うと、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャはまた、同じハイパーバイザによってホストされているさまざまなＶＭに達するために、さまざまな経路を計算して用いる能力を可能にする。本質的には、これは、ＬＩＤを連続的にすることを必要とするＬＭＣの制約によって拘束されることなく、１つの物理的なマシンに向かう代替的な経路を設けるために、このようなサブネットおよびネットワークがＬＩＤマスク制御ライク（LID-Mask-Control-like：ＬＭＣライク）な特徴を用いること
を可能にする。ＶＭをマイグレートしてその関連するＬＩＤを宛先に送達する必要がある場合、不連続なＬＩＤを自由に使用できることは特に有用となる。

【0076】

一実施形態に従うと、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャについての上述の利点と共に、いくつかの検討事項を考慮に入れることができる。たとえば、ネットワークがブートされているときに、ＳＲ－ＩＯＶ ｖＳｗｉｔｃｈ対応のサブネットにおいてＬＩＤが予めポピュレートされているので、（たとえば起動時の）最初の経路演算はＬＩＤが予めポピュレートされていなかった場合よりも時間が長くかかる可能性がある。

【0077】

インフィニバンドＳＲ－ＩＯＶアーキテクチャモデル－動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈ
一実施形態に従うと、本開示は、動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈアーキテクチャを提供するためのシステムおよび方法を提供する。

【0078】

図８は、一実施形態に従った、動的ＬＩＤ割当てがなされた例示的なｖＳｗｉｔｃｈアーキテクチャを示す。図に示されるように、いくつかのスイッチ５０１～５０４は、ネットワーク切替環境７００（たとえばＩＢサブネット）内においてインフィニバンドファブリックなどのファブリックのメンバ間で通信を確立することができる。ファブリックは、ホストチャネルアダプタ５１０、５２０、５３０などのいくつかのハードウェアデバイスを含み得る。ホストチャネルアダプタ５１０、５２０および５３０は、さらに、ハイパーバイザ５１１、５２１および５３１とそれぞれ対話することができる。各々のハイパーバイザは、さらに、ホストチャネルアダプタと共に、いくつかの仮想機能５１４～５１６、５２４～５２６、５３４～５３６と対話し、設定し、いくつかの仮想マシンに割当てることができる。たとえば、仮想マシン１ ５５０はハイパーバイザ５１１によって仮想機能１ ５１４に割当てることができる。ハイパーバイザ５１１は、加えて、仮想マシン２
５５１を仮想機能２ ５１５に割当て、仮想マシン３ ５５２を仮想機能３ ５１６に割当てることができる。ハイパーバイザ５３１はさらに、仮想マシン４ ５５３を仮想機能１ ５３４に割当てることができる。ハイパーバイザは、ホストチャネルアダプタの各々の上において十分な機能を有する物理機能５１３、５２３および５３３を介してホストチャネルアダプタにアクセスすることができる。

【0079】

一実施形態に従うと、スイッチ５０１～５０４の各々はいくつかのポート（図示せず）を含み得る。いくつかのポートは、ネットワーク切替環境７００内においてトラフィックを方向付けるためにリニアフォワーディングテーブルを設定するのに用いられる。

【0080】

一実施形態に従うと、仮想スイッチ５１２、５２２および５３２は、それぞれのハイパーバイザ５１１、５２１および５３１によって処理することができる。このようなｖＳｗｉｔｃｈアーキテクチャにおいては、各々の仮想機能は完全な仮想ホストチャネルアダプタ（ｖＨＣＡ）であり、これは、ハードウェアにおいて、ＶＦに割当てられたＶＭに、ＩＢアドレス一式（たとえばＧＩＤ、ＧＵＩＤ、ＬＩＤ）および専用のＱＰスペースが割当てられていることを意味する。残りのネットワークおよびＳＭ（図示せず）については、ＨＣＡ５１０、５２０および５３０は、仮想スイッチを介して、追加のノードが接続されているスイッチのように見えている。

【0081】

一実施形態に従うと、本開示は、動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈアーキテクチャを提供するためのシステムおよび方法を提供する。図８を参照すると、ＬＩＤには、さまざまな物理機能５１３、５２３および５３３が動的に割当てられており、物理機能５１３がＬＩＤ１を受取り、物理機能５２３がＬＩＤ２を受取り、物理機能５３３がＬＩＤ３を受取る。アクティブな仮想マシンに関連付けられたそれらの仮想機能はまた、動的に割当てられたＬＩＤを受取ることもできる。たとえば、仮想マシン１ ５５０がアクティブであり、仮想機能１ ５１４に関連付けられているので、仮想機能５１４にはＬＩＤ５が割当てられ得る。同様に、仮想機能２ ５１５、仮想機能３ ５１６および仮想機能１ ５３４は、各々、アクティブな仮想機能に関連付けられている。このため、これらの仮想機能にＬＩＤが割当てられ、ＬＩＤ７が仮想機能２ ５１５に割当てられ、ＬＩＤ１１が仮想機能３ ５１６に割当てられ、ＬＩＤ９が仮想機能１ ５３４に割当てられている。ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈとは異なり、アクティブな仮想マシンにその時点で関連付けられていない仮想機能５２４～５２６および５３４～５３６はＬＩＤの割当てを受けない。

【0082】

一実施形態に従うと、動的ＬＩＤ割当てがなされていれば、最初の経路演算を実質的に減らすことができる。ネットワークが初めてブートしており、ＶＭが存在していない場合、比較的少数のＬＩＤを最初の経路計算およびＬＦＴ分配のために用いることができる。

【0083】

一実施形態に従うと、多くの同様の物理的なホストチャネルアダプタが２つ以上のポートを有することができ（冗長性のために２つのポートが共用となっている）、仮想ＨＣＡも２つのポートで表わされ、１つまたは２つ以上の仮想スイッチを介して外部ＩＢサブネットに接続され得る。

【0084】

一実施形態に従うと、動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈを利用するシステムにおいて新しいＶＭが作成される場合、どのハイパーバイザ上で新しく追加されたＶＭをブートすべきであるかを決定するために、自由なＶＭスロットが発見され、固有の未使用のユニキャストＬＩＤも同様に発見される。しかしながら、新しく追加されたＬＩＤを処理するためのスイッチのＬＦＴおよびネットワークに既知の経路が存在しない。新しく追加されたＶＭを処理するために新しいセットの経路を演算することは、いくつかのＶＭが毎分ごとにブートされ得る動的な環境においては望ましくない。大規模なＩＢサブネット
においては、新しい１セットのルートの演算には数分かかる可能性があり、この手順は、新しいＶＭがブートされるたびに繰返されなければならないだろう。

【0085】

有利には、一実施形態に従うと、ハイパーバイザにおけるすべてのＶＦがＰＦと同じアップリンクを共有しているので、新しいセットのルートを演算する必要はない。ネットワークにおけるすべての物理スイッチのＬＦＴを繰返し、（ＶＭが作成されている）ハイパーバイザのＰＦに属するＬＩＤエントリから新しく追加されたＬＩＤにフォワーディングポートをコピーし、かつ、特定のスイッチの対応するＬＦＴブロックを更新するために単一のＳＭＰを送信するだけでよい。これにより、当該システムおよび方法では、新しいセットのルートを演算する必要がなくなる。

【0086】

一実施形態に従うと、動的ＬＩＤ割当てアーキテクチャを備えたｖＳｗｉｔｃｈにおいて割当てられたＬＩＤは連続的である必要はない。各々のハイパーバイザ上のＶＭ上で割当てられたＬＩＤをＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈと動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈとで比較すると、動的ＬＩＤ割当てアーキテクチャにおいて割当てられたＬＩＤが不連続であり、そこに予めポピュレートされたＬＩＤが本質的に連続的であることが分かるだろう。さらに、ｖＳｗｉｔｃｈ動的ＬＩＤ割当てアーキテクチャにおいては、新しいＶＭが作成されると、次に利用可能なＬＩＤが、ＶＭの生存期間の間中ずっと用いられる。逆に、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈにおいては、各々のＶＭは、対応するＶＦに既に割当てられているＬＩＤを引継ぎ、ライブマイグレーションのないネットワークにおいては、所与のＶＦに連続的に付与されたＶＭが同じＬＩＤを得る。

【0087】

一実施形態に従うと、動的ＬＩＤ割当てアーキテクチャを備えたｖＳｗｉｔｃｈは、いくらかの追加のネットワークおよびランタイムＳＭオーバーヘッドを犠牲にして、予めポピュレートされたＬＩＤアーキテクチャモデルを備えたｖＳｗｉｔｃｈの欠点を解決することができる。ＶＭが作成されるたびに、作成されたＶＭに関連付けられた、新しく追加されたＬＩＤで、サブネットにおける物理スイッチのＬＦＴが更新される。この動作のために、１スイッチごとに１つのサブネット管理パケット（ＳＭＰ）が送信される必要がある。各々のＶＭがそのホストハイパーバイザと同じ経路を用いているので、ＬＭＣのような機能も利用できなくなる。しかしながら、すべてのハイパーバイザに存在するＶＦの合計に対する制限はなく、ＶＦの数は、ユニキャストＬＩＤの限度を上回る可能性もある。このような場合、当然、アクティブなＶＭ上でＶＦのすべてが必ずしも同時に付与されることが可能になるわけではなく、より多くの予備のハイパーバイザおよびＶＦを備えることにより、ユニキャストＬＩＤ限度付近で動作する際に、断片化されたネットワークの障害を回復および最適化させるための融通性が追加される。

【0088】

インフィニバンドＳＲ－ＩＯＶアーキテクチャモデル－動的ＬＩＤ割当てがなされかつＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈ
図９は、一実施形態に従った、動的ＬＩＤ割当てがなされてＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈを備えた例示的なｖＳｗｉｔｃｈアーキテクチャを示す。図に示されるように、いくつかのスイッチ５０１～５０４は、ネットワーク切替環境８００（たとえばＩＢサブネット）内においてインフィニバンドファブリックなどのファブリックのメンバ間で通信を確立することができる。ファブリックはホストチャネルアダプタ５１０、５２０、５３０などのいくつかのハードウェアデバイスを含み得る。ホストチャネルアダプタ５１０、５２０および５３０は、それぞれ、さらに、ハイパーバイザ５１１、５２１および５３１と対話することができる。各々のハイパーバイザは、さらに、ホストチャネルアダプタと共に、いくつかの仮想機能５１４、５１５、５１６、５２４、５２５、５２６、５３４、５３５および５３６と対話し、設定し、いくつかの仮想マシンに割当てることができる。たとえば、仮想マシン１ ５５０は、ハイパーバイザ５１１によって仮想機
能１ ５１４に割当てることができる。ハイパーバイザ５１１は、加えて、仮想マシン２
５５１を仮想機能２ ５１５に割当てることができる。ハイパーバイザ５２１は、仮想マシン３ ５５２を仮想機能３ ５２６に割当てることができる。ハイパーバイザ５３１は、さらに、仮想マシン４ ５５３を仮想機能２ ５３５に割当てることができる。ハイパーバイザは、ホストチャネルアダプタの各々の上において十分な機能を有する物理機能５１３、５２３および５３３を介してホストチャネルアダプタにアクセスすることができる。

【0089】

一実施形態に従うと、スイッチ５０１～５０４の各々はいくつかのポート（図示せず）を含み得る。これらいくつかのポートは、ネットワーク切替環境８００内においてトラフィックを方向付けるためにリニアフォワーディングテーブルを設定するのに用いられる。

【0090】

一実施形態に従うと、仮想スイッチ５１２、５２２および５３２は、それぞれのハイパーバイザ５１１、５２１、５３１によって処理することができる。このようなｖＳｗｉｔｃｈアーキテクチャにおいては、各々の仮想機能は、完全な仮想ホストチャネルアダプタ（ｖＨＣＡ）であり、これは、ハードウェアにおいて、ＶＦに割当てられたＶＭに、ＩＢアドレス一式（たとえばＧＩＤ、ＧＵＩＤ、ＬＩＤ）および専用のＱＰスペースが割当てられていることを意味する。残りのネットワークおよびＳＭ（図示せず）については、ＨＣＡ５１０、５２０および５３０は、仮想スイッチを介して、追加のノードが接続されているスイッチのように見えている。

【0091】

一実施形態に従うと、本開示は、動的ＬＩＤ割当てがなされＬＩＤが予めポピュレートされたハイブリッドｖＳｗｉｔｃｈアーキテクチャを提供するためのシステムおよび方法を提供する。図９を参照すると、ハイパーバイザ５１１には、予めポピュレートされたＬＩＤアーキテクチャを備えたｖＳｗｉｔｃｈが配置され得るとともに、ハイパーバイザ５２１には、ＬＩＤが予めポピュレートされて動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈが配置され得る。ハイパーバイザ５３１には、動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈが配置され得る。このため、物理機能５１３および仮想機能５１４～５１６には、それらのＬＩＤが予めポピュレートされている（すなわち、アクティブな仮想マシンに付与されていない仮想機能であってもＬＩＤが割当てられている）。物理機能５２３および仮想機能１ ５２４にはそれらのＬＩＤが予めポピュレートされ得るとともに、仮想機能２ ５２５および仮想機能３ ５２６にはそれらのＬＩＤが動的に割当てられている（すなわち、仮想機能２ ５２５は動的ＬＩＤ割当てのために利用可能であり、仮想機能３ ５２６は、仮想マシン３ ５５２が付与されているので、１１というＬＩＤが動的に割当てられている）。最後に、ハイパーバイザ３ ５３１に関連付けられた機能（物理機能および仮想機能）にはそれらのＬＩＤを動的に割当てることができる。これにより、結果として、仮想機能１ ５３４および仮想機能３ ５３６が動的ＬＩＤ割当てのために利用可能となるとともに、仮想機能２ ５３５には、仮想マシン４ ５５３が付与されているので、９というＬＩＤが動的に割当てられている。

【0092】

ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈおよび動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈがともに（いずれかの所与のハイパーバイザ内で独立して、または組合わされて）利用されている、図８に示されるような一実施形態に従うと、ホストチャネルアダプタごとの予めポピュレートされたＬＩＤの数はファブリックアドミニストレータによって定義することができ、（ホストチャネルアダプタごとに）０＜＝予めポピュレートされたＶＦ＜＝総ＶＦの範囲内になり得る。動的ＬＩＤ割当てのために利用可能なＶＦは、（ホストチャネルアダプタごとに）ＶＦの総数から予めポピュレートされたＶＦの数を減じることによって見出すことができる。

【0093】

一実施形態に従うと、多くの同様の物理的なホストチャネルアダプタが２つ以上のポー
トを有することができ（冗長性のために２つのポートが共用となっている）、仮想ＨＣＡも２つのポートで表わされ、１つまたは２つ以上の仮想スイッチを介して外部ＩＢサブネットに接続され得る。

【0094】

インフィニバンド－サブネット間通信（ファブリックマネージャ）
一実施形態によれば、本開示の実施形態は、単一サブネット内にインフィニバンドファブリックを提供することに加えて、２つ以上のサブネットにまたがるインフィニバンドファブリックを提供することもできる。

【0095】

図１０は、一実施形態による例示的なマルチサブネットインフィニバンドファブリックを示す。図に示すように、サブネットＡ１０００内では、ある数のスイッチ１００１～１００４が、サブネットＡ１０００（例えば、ＩＢサブネット）内において、インフィニバンドファブリックなどのファブリックのメンバ間において通信を提供することができる。ファブリックは、例えば、ホストチャネルアダプタ１０１０などのある数のハードウェアデバイスを含むことができる。ホストチャネルアダプタ１０１０は、次いで、ハイパーバイザ１０１１と対話することができる。ハイパーバイザは、次いで、それが対話するホストチャネルアダプタと関連して、ある数の仮想機能１０１４をセットアップすることができる。ハイパーバイザは、加えて、仮想マシンを仮想機能の各々に割り当てることができ、仮想マシン１ １０１０５が仮想機能１ １０１４に割り当てられるなどする。ハイパーバイザは、各ホストチャネルアダプタ上において、物理機能１０１３など、十分な機能を有する物理機能を介して、それらの関連付けられるホストチャネルアダプタにアクセスできる。サブネットＢ１０４０内では、ある数のスイッチ１０２１～１０２４が、サブネットＢ１０４０（例えば、ＩＢサブネット）内において、インフィニバンドファブリックなどのファブリックのメンバ間において通信を提供することができる。ファブリックは、例えば、ホストチャネルアダプタ１０３０などのある数のハードウェアデバイスを含むことができる。ホストチャネルアダプタ１０３０は、次いで、ハイパーバイザ１０３１と対話することができる。ハイパーバイザは、次いで、それが対話するホストチャネルアダプタと関連して、ある数の仮想機能１０３４をセットアップすることができる。ハイパーバイザは、加えて、仮想マシンを仮想機能の各々に割り当てることができ、仮想マシン２ １０３５が仮想機能２ １０３４に割り当てられるなどする。ハイパーバイザは、各ホストチャネルアダプタ上において、物理機能１０３３など、十分な機能を有する物理機能を介して、それらの関連付けられるホストチャネルアダプタにアクセスできる。各サブネット（すなわち、サブネットＡおよびサブネットＢ）内には１つのホストチャネルアダプタしか示されていないが、複数のホストチャネルアダプタおよびそれらの対応するコンポーネントを各サブネット内に含めることができることを理解されたい。

【0096】

一実施形態によれば、ホストチャネルアダプタの各々は、仮想スイッチ１０１２および仮想スイッチ１０３２などの仮想スイッチにさらに関連付けることができ、各ＨＣＡは、上述したように、異なるアーキテクチャモデルでセットアップすることができる。図１０内の両方のサブネットは、事前にポピュレートされたＬＩＤアーキテクチャモデルを有するｖＳｗｉｔｃｈを使用しているように示されているが、これはすべてのそのようなサブネット構成が同様のアーキテクチャモデルに従わなければならないことを意味するものではない。

【0097】

一実施形態によれば、各サブネット内の少なくとも１つのスイッチはルータに関連付けられることができ、サブネットＡ１０００内のスイッチ１００２はルータ１００５に関連付けられ、サブネットＢ１０４０内のスイッチ１０２１はルータ１００６に関連付けられるなどする。

【0098】

一実施形態によれば、少なくとも１つのデバイス（例えば、スイッチ、ノードなど）を
ファブリックマネージャ（図示せず）に関連付けることができる。ファブリックマネージャは、例えば、サブネット間ファブリックトポロジを発見し、ファブリックプロファイル（例えば、仮想マシンファブリックプロファイル）を作成し、仮想マシンファブリックプロファイルを構築するための基礎を形成する仮想マシン関連データベースオブジェクトを構築するために使用することができる。加えて、ファブリックマネージャは、どのサブネットがどのパーティション番号を使用してどのルータポートを介して通信することが許可されているかに関して、法的なサブネット間接続を定義することができる。

【0099】

一実施形態によれば、サブネットＡ内の仮想マシン１などの発信元でのトラフィックが、サブネットＢ内の仮想マシン２などの異なるサブネットの宛先にアドレス指定されている場合、トラフィックはサブネットＡ内のルータ、すなわちルータ１００５にアドレス指定され、ルータ１００５は次いでそのトラフィックをルータ１００６とのそれのリンクを介してサブネットＢに渡すことができる。

【0100】

全体的に、例示的な実施形態は、非常に大きなファブリックに多数のノードを提供し、さらに、サブネット境界を各々が有する複数のサブネットを提供する。サブネット境界は、独立したサブネットマネージャ（ＳＭ）を可能にする。特に、サブネット境界は、非常に大きなファブリック内の複数のサブネットの各々において／について１つの独立したＳＭを可能にする。

【0101】

さらに、非常に効率的なパケットルーティングが、ファブリック全体にわたって独自の方法でパケットフローをルーティングするために、線形転送テーブル（ＬＦＴ）探索プロトコルの単純な探索メカニズムの使用によって可能になる。

【0102】

ローカル／サブネット内ルーティング：
レイヤ２（Ｌ２）アドレス指定の場合、例示的な実施形態は、各サブネット内において「通常の」ローカルＩＤベースのルーティング／転送を使用する。つまり、ＩＢパケットのローカルルートヘッダ（ＬＲＨ）における１６ビットの宛先ローカル識別子（ＤＬＩＤ）は、スイッチポートでルーティングされているときに探索され、出力ポートは、ＩＢパケットのＬＲＨにおけるＤＬＩＤ値を使用してハードウェアでＬＦＴを直接索引付けすることによって迅速に発見される。

【0103】

レイヤ３（Ｌ３）アドレス／アドレス指定：
例示的な実施形態におけるパケットのグローバルルートヘッダ（ＧＲＨ）は、本質的に１２８ビットスキーム、すなわち一意の６４ビットのノードアドレス‐「ＧＵＩＤ」、および６４ビットのサブネットプレフィックス番号を使用する。例示的な実施形態は、多数の独立したサブネットに分割された非常に大きなファブリックを提供し、同じルート／ルーティング能力が異なるサブネットにまたがって使用可能にされる。すなわち、例示的な実施形態では、エンドポイント間の経路は、あたかも大きな単一のサブネットがあるかのような場合と同じ方法でルーティングすることができる。

【0104】

仮想マシン（ＶＭ）では、物理エンドノードは、多数の仮想エンドポイントを表すことができ、各仮想エンドポイントは、１６ビットのＤＬＩＤを含むそれら自体の完全なＩＢアドレスを有している（かつ、それを、レガシー互換性の理由のため、有するべきである）しかしながら、１６ビットのＤＬＩＤ空間はすぐに使い尽くされるようになる。本質的に、各仮想サブネットには、１６ビットＤＬＩＤを使用するアドレス空間ポインティング機能があるよりも多くの空間がある。

【0105】

したがって、例示的な実施形態によれば、全ファブリックは、独立したサブネットのセットに分割され、プライベートな「ＬＩＤ空間」が提供され、Ｌ３アドレスの６４ビット
のサブネットプレフィックス番号部分から指定されたビットフィールドを抽出するためのメカニズムが提供される。例示的な実施形態のメカニズムによれば、サブネット番号を符号化するためにＬ３アドレスの６４ビット全体を使用する代わりに、本実施形態は、指定されたビットフィールド（ＩＳＲＮ）をＬ３アドレスの６４ビットのサブネットプレフィックス番号部分から抽出するためのハードウェアサポートを提供する。したがって、中間インフラストラクチャを介して（仮想）サブネットＡから（仮想）サブネットＢへの通信がある場合、例示の実施形態は、Ｌ３アドレスの６４ビットのサブネットプレフィックス番号部分の指定されたビットフィールドにおいて、
ａ）宛先サブネットにおけるＬＩＤ／またはそのＬＩＤおよび
ｂ）「中間スイッチファブリック」インフラストラクチャの「中間」ＬＩＤの両方をエンコードする。

【0106】

グローバルルートヘッダ（ＧＲＨ）ベースの線形転送テーブル（ＬＦＴ）探索
ＩＢファブリック全体にわたるルーティング／転送の調整された管理を伴う単一のファブリック構成内においてサブネット内トラフィックおよびサブネット間トラフィックの両方に対してスケーラブルで柔軟性があり決定論的なルーティング／転送を可能にするために必要なスイッチ／ルータオンチップリソースの量を削減するために、ある実施形態に従って、単一のサブネット内のＬＩＤベースのテーブル探索と同じ方法で線形テーブル探索のために使用される番号を介してサブネット間のルートを識別するためのスキームが使用される。これに関して、図１１は、一実施形態による、ネットワーク環境においてパケット転送ロジックにアクセスするためにインフィニバンド（ＩＢ）アドレス指定スキームを使用するデータパケットフォーマットの図を示す。図に示すように、第１のＩＢサブネット１１００は、複数の物理（または仮想）ノード１１０１および１１０２と、サブネットアドミニストレータ（ＳＡ）１１２０とを含むことができる。第１のＩＢサブネット１１００内のソースノード１１０１は、中間ノード１１０２を介して、第１のＩＢサブネット１１００以外の第２のＩＢサブネットにおける宛先ノード１１０３にパケット（たとえば、ＩＢパケット１１１０）を送信することができる。宛先ノード１１０３は、それが第２のＩＢサブネット内にあることを表すために点線で示されている。

【0107】

ＩＢパケット１１１０は、ペイロード１１１４と、ＩＢプロトコルによるさまざまなヘッダとを含むことができる。これらのヘッダは、グローバルルーティングヘッダ（ＧＲＨ）１１１１、ローカルルーティングヘッダ（ＬＲＨ）１１１２、および他のヘッダ１１１３を含むことができる。さらに、ＩＢパケット１１１０は、さまざまな巡回冗長検査（ＣＲＣ）１１５とともに適用することができる。

【0108】

一実施形態によれば、システムは、第１のＩＢサブネット１１００および第２のＩＢサブネットにおけるサブネット内およびサブネット間アドレス指定をサポートするために、ＧＲＨ１１１１における宛先グローバル識別子（ＤＧＩＤ）１１２１のサブネットプレフィックス部分およびＬＲＨ１１１２における宛先ローカル識別子（ＤＬＩＤ）１１２２を利用できる。

【0109】

たとえば、システムは、（宛先ノード１１０３のためのＤＬＩＤの代わりに）中間ノード１１０２のためのＤＬＩＤになるように、ＩＢパケット１１１０におけるＤＬＩＤ１１２２を設定することができる。ＩＢサブネット１１００内では、ＩＢパケット１１１０は、ＳＡ１１２０によって解かれたＤＬＩＤ１１２２に基づいて、線形転送テーブルＬＦＴ探索を介して中間ノード１１０２にルーティングすることができる。したがって、ＩＢパケット１１１０は、中間ノード１１０２上に設けられたパケット転送ロジックを使用して処理することができる。同様のパケット転送ロジックを、必要であるように、または所望のように、他のノード１１０１および１１０３に設けることができる。

【0110】

さらに、システムは、ＧＲＨ１１１１におけるＤＧＩＤ１１２１の選択された部分を使用して、そのＤＬＩＤを宛先ノード１１０３のために示すことができる。したがって、中間ノード１１０２におけるパケット転送ロジックは、ＧＲＨ１１１１におけるＤＧＩＤ１１２１情報に基づいて、宛先ノード１１０３のための実際のＤＬＩＤを解く（または取得する）ことができる。

【0111】

一実施形態によれば、中間ノード１１０２は、必要に応じて追加のパケットヘッダ１１１３および／またはペイロード１１１４の修正を行うことができる。たとえば、ファブリックレベルアクセス制御は、ソースノード１１０１および宛先ノード１１０３が、関連するパーティションの限定されたメンバーであるか、または同じパーティションのメンバーでないように設定され得る。そのような場合、中間ノード１１０２は、修正されたパケットを宛先ノード１１０３に転送する前に、ＩＢパケット１１１０におけるＰ＿Ｋｅｙ値を変更することを許可されてもよい。

【0112】

図１１は、一実施形態に従ってターゲットサブネット番号１１４２およびターゲットＬＩＤ１１４３と共に使用されるサブネット間ルート番号（ＩＳＲＮ）１１４１を含むサブネットプレフィックス転送部分１１３１を含む例示的なパケット１１００のＤＧＩＤ部分１１２１を示す。ＩＳＲＮ１１４１は、サブネット内転送判断を、サブネット間転送判断と並んで両方を行うために、同じ線形転送テーブル（ＬＦＴ）が、実施形態に従って構成されたファブリックスイッチによって使用されることを可能にする。実施形態は、単一のファブリック構成内のサブネット間トラフィックが、異なるファブリック間のトラフィックとは異なるサブネットプレフィックス値を使用できるように、ファブリックローカル／内部サブネット番号および「グローバル」サブネット番号の両方をサポートする。

【0113】

ソースから最終的な宛先への経路に沿った任意のポイントにおけるＧＲＨ．ＤＧＩＤからＤＬＩＤへのどのようなマッピングも行なう必要性なしに、エンドツーエンドルートをパケットヘッダ内において完全に定義できるようにするために、ある実施形態は、サブネット間ルート番号、ターゲット「ファブリックローカルサブネット番号」、およびターゲットサブネットにおける宛先ＬＩＤ値の両方を含むＧＲＨ．ＤＧＩＤサブネットプレフィックスフォーマットを提供する。

【0114】

スイッチ／ルータポートに関連付けられる転送ドメインのスキームまたはプロトコルは、ある例示的な実施形態においてサポートされ、各転送ドメインタイプは、ＬＦＴにおける探索のためにどのアドレス情報が使用されるか、および転送ドメインタイプの変更が、ローカルルートヘッダをＧＲＨからのＤＬＩＤ値で更新する必要があることを意味するかどうかを、定義する。

【0115】

ソースサブネット、中間スイッチファブリックおよびターゲットサブネットを有する３レベル転送ドメイン構造をサポートするために、実施形態に従って上記のＤＧＩＤ．サブネットプレフィックスフォーマットが使用される。ソースサブネット１１００におけるソースノード１１０１および中間ノード１１０２は、線形転送テーブル（ＬＦＴ）探索のためにパケット１１００の最初のＬＲＨ．ＤＬＩＤを用い、中間スイッチファブリックにおける宛先ノード１１０３への遷移は、サブネットプレフィックス転送部分１１３１のサブネット間ルート番号１１４１がＬＦＴ探索に使用されることを意味する。中間スイッチファブリックは、便宜上、本明細書では「コアファブリック」とも呼ばれ得る。

【0116】

パケットが中間スイッチファブリックタイプ転送ドメイン内で転送されていることを示すために、一実施形態によれば、特殊なＤＬＩＤ値が使用され、特殊なＤＬＩＤ値は、入口スイッチポートにおけるレジスタに格納される値と照合される。特殊なＤＬＩＤ値は、「特殊スイッチポート」を表し、特殊スイッチポートはローカル仮想サブネットの「終わ
り」を定義する。これにより、単一のＬＦＴ探索操作を、ＬＲＨ．ＤＬＩＤ値ではなく、ＧＲＨ．ＤＧＩＤ．サブネットプレフィックスの関連セクションに基づかせることができる。

【0117】

一実施形態によれば、転送ドメインの変更がいつ行われるかを判断するために、各入口スイッチポートは、同じスイッチノードにおける各可能な出口ポートについてのタイプステータスを伴う１つ以上のレジスタを含み、ＬＦＴで探索されるターゲットポートが転送ドメインタイプの変更を表わす場合に、進入経路におけるパケット処理が次の転送ドメインのためのパケットを準備できるようにする。

【0118】

例示的な実施形態によれば、ＩＢパケット１１１０が、ソースノード１１０１のポートからなどのような、ソースサブネット１１００内のポートから、中間ノード１１０２のポートへなどのような、同様にソースサブネット１１００内のポートへのサブネット内転送である場合、パケットのＬＲＨ．ＤＬＩＤを直接使用して、標準的なサブネット内パケット転送のために各スイッチでＬＦＴを索引付けする。

【0119】

さらに、例示的な実施形態によれば、ＩＢパケット１１１０が、ソースノード１１０１のポートからなどのような、ソースサブネット１１００内のポートから、ソースサブネット１１００外の中間スイッチファブリックへの、サブネット間転送である場合、パケット１１１０のローカルルートヘッダ１１１２のＤＬＩＤ１１２２部分は、ソースサブネット１１００外の関連する中間スイッチファブリックにおける中間スイッチファブリック転送を表すように構成された値にローカルに更新される。

【0120】

さらに別の例示的な実施形態によれば、図１１を続けて参照すると、ＩＢパケットが宛先ノード１１０３などのソースサブネット１１００外の中間スイッチファブリックからソースノード１１０１または中間ノード１１０２などのターゲットソースサブネット１１００へのサブネット間転送である場合、ＬＲＨ．ＤＬＩＤはＤＧＩＤ．サブネットプレフィックスからのＤＬＩＤフィールドで更新され、次いで、それを用いて、パケットを、最終的な宛先ポートに、ターゲットソースサブネット１１００におけるＬＦＴ探索を用いて転送する。この遷移では、パケットＧＲＨ．ＤＧＩＤ．サブネットプレフィックスにおけるターゲットローカルサブネット番号が、このポートが表すローカルサブネット番号と一致しているかどうかを検証することもできる。このチェックは、好ましくは、そのような各ポートにおけるレジスタに基づく。

【0121】

例示的な実施形態では、任意のスイッチポートは、ローカル（ソース）サブネットと中間スイッチファブリックとの間の「ゲートウェイ」を表すことができ、そのような各ゲートウェイスイッチポートは、ローカルサブネットにおける１つ以上の特定のＤＬＩＤによって識別される。したがって、複数の並列コアファブリックが存在することができるファットツリーベースのトポロジを実現することが可能である。このようにして、各並列コアファブリックは独立してルーティングされるドメインを表すことができるため、完全なファブリックのアドレス指定スケーラビリティはトポロジでスケーリングできる。４８ＫのＬＦＴサイズは、これらの並列コアファブリックの各々内での制限に過ぎず、完全なコアファブリック内の個々の「サブネット間ルート番号」の数は、並列コアファブリックの数の４８Ｋ倍である。

【0122】

加えて、一実施形態によれば、内部ルートの独立した管理を伴う異なるファブリック構成間の「ランダムな」接続性を処理できるように、ある実施形態は、ファブリックローカル／内部サブネット番号を「グローバル」サブネット番号と並んで両方サポートするためのサポートスキームを提供して、単一のファブリック構成内のサブネット間トラフィックが、異なるファブリック間のトラフィックとは異なるサブネットプレフィックス値を使用
できるようにする。サポートスキームは、また、任意のサブネットプレフィックスおよびＧＵＩＤ値の転送を可能にするために、完全なＤＧＩＤ値のＴＣＡＭベースの探索およびマッピングを提供する。

【0123】

ファブリックモデル
例示的な実施形態によるコアファブリックモデルの概要として、ＩＢファブリック構成は、個々のサブネットに分解することができる一方で、個々の物理的または仮想的な宛先に対する個々の経路を明示的にルーティングできる柔軟性を依然として維持することができる、非常に大きなファットツリー構成に対するスケーリングを容易にする。システムは、階層的な態様で管理される単一のファブリック構成として構築されるが、最上位の管理エンティティは完全なファブリックの完全な可視性を有する。

【0124】

異なる独立して管理されるシステム間のネイティブなＩＢ接続性を依然としてサポートしながら、大きなシステム構築柔軟性を提供するために、例示的な実施形態のファブリックモデルは、同一の単一の最上位のエンティティによって管理されない異なるファブリック構成／トポロジ間における「任意の」ＩＢ接続性を可能にする。

【0125】

例示的な実施形態は、上記の目標を達成するため、および単一のファブリック構成内でサブネット間通信を提供するために、経路／ルート情報をパケットＧＲＨにおけるＤＧＩＤフィールドのサブネットプレフィックス部分１１３１の一部としてエンコードする。例示的な実施形態は、独立したＩＢファブリック間のＩＢ－ＩＢルーティングを可能にする標準的なサブネットプレフィックススキームもサポートする。

【0126】

数百または数千の物理ホストを有する非常に大きな構成にスケーリングすることに加えて、例示的な実施形態のシステムは、さらに、非常に小さなサブネット構成の使用も容易にし、単一の集積回路チップを使用して、異なるサブネットマネージャ（ＳＭ）のセットによって管理される異なるＩＢサブネットを各々が表わす複数の仮想スイッチを実現してもよい。加えて、非常に大きな全体ファブリック構成であっても、このような小さなサブネット構成を必要または所望に応じて依然として使用して、論理システム単位への所望の分解を反映させてもよい。一方、一部の構成では、依然としてより大きな単一のファブリックの一部である非常に大きな単一のサブネットトポロジを有してもよい。

【0127】

一般に、アップスケーリングおよびダウンスケーリングにおける柔軟性の必要性は、パケットルーティングおよび転送判断を処理するためのシステムオンチップリソースの点で課題を課す。これには、サブネット内およびサブネット間転送の両方、特に、異なるサブネットにおける個々の仮想エンドポイントに対処する能力が含まれる。

【0128】

ここにおける実施形態は、単一のファブリック構成内においてサブネット内トラフィックおよびサブネット間トラフィックの両方に対してスケーラブルで柔軟性があり決定論的なルーティング／転送を可能にするために必要なシステムオンチップリソースの量を削減するためのスキームを提供する。特に、「サブネット間ルート番号」（ＩＳＲＮ）を、単一のサブネット内のＬＩＤベースのテーブル探索に類似する態様でテーブル探索のために使用され得る番号を介してサブネット間ルートを識別するために使用できる。さらに、それ以外の場合は、標準または「レガシー」線形転送テーブルが、サブネット内およびサブネット間の両方の転送の判断に使用される。たとえば、図１２は、ＬＲＨ．ＤＬＩＤ値またはＩＳＲＮ値のいずれかによって等価的に０～４８ｋから索引付けることができる線形転送テーブル（ＬＦＴ）１２００の一部を示す。図示したＬＦＴ１２００において、テーブルにおける各エントリは、サポートされているポート番号または使用されていないエントリを表す「０×ＦＦ」エントリのいずれかを含む。更に加えて、単一のファブリック構成内のサブネット間トラフィックが、異なるファブリック間のトラフィックとは異なるサ
ブネットプレフィックス値を使用できるように、ファブリックローカル／内部サブネット番号および「グローバル」サブネット番号の両方をサポートする。さらに、ＧＲＨ．ＤＧＩＤ．サブネットプレフィックスフォーマットが提供され、サポートされる。例示的な実施形態では、ＧＲＨ．ＤＧＩＤサブネットプレフィックスフォーマットは、ソースから最終的な宛先への経路に沿った任意のポイントにおけるＧＲＨ．ＤＧＩＤからＤＬＩＤへのどのようなマッピングも行なう必要性なしに、エンドツーエンドルートをパケットヘッダ内において完全に定義できるようにするために、「サブネット間ルート番号」、ターゲット「ファブリックローカルサブネット番号」、およびターゲットサブネットにおける宛先ＬＩＤ値の両方を含む。

【0129】

個々のサブネット間における「ランダム化された」マルチ経路転送を伴う階層的トポロジを可能にするために、リーフスイッチベースの転送が提供される。さらに、異なるファブリック構成間の「ランダム」接続を扱うことができるように、例示的な実施形態は、単一のファブリック構成内のサブネット間トラフィックが、異なるファブリック間のトラフィックとは異なるサブネットプレフィックス値を使用できるように、ファブリックローカル／内部サブネット番号および「グローバル」サブネット番号の両方をサポートし、任意のサブネットプレフィックスおよびＧＵＩＤ値の転送を可能にするために、完全なＤＧＩＤ値のＴＣＡＭベースの探索およびマッピングを提供する。

【0130】

ローカルファブリック
一実施形態によれば、「ローカルファブリック」は、１つ以上の物理的な「リーフサブネット」および／または「コアファブリック」トポロジ内ならびにそのようなトポロジ間の接続性を表す物理的なＩＢファブリックインフラストラクチャである。ローカルファブリックは階層的な態様で管理されるが、たとえば制御プレーンソフトウェアなどの最上位の中央管理エンティティが任意のＩＤ値の割り当てを管理することができるという制約を伴い、物理接続およびルーティング（パケット転送）の両方の制約を完全なローカルファブリック（すなわち、ローカルファブリックの”全体的なビュー”）全体にわたって遵守する。

【0131】

リモートファブリック
一実施形態によれば、「リモートファブリック」は、１つ以上のＩＢリンクを介してローカルファブリックに接続される任意のトポロジ／インフラストラクチャであるが、リンクのリモート側のポートは、ローカルファブリックと同じ最上位の中央管理エンティティによって制御されない。２つの独立したローカルファブリックを接続するポートは、典型的には、ルータポートとして設定される。したがって、これら２つのポートは、一実施形態によれば、最小ＩＢサブネットを形成する。

【0132】

ゲートウェイサブネット
一実施形態によれば、「ゲートウェイサブネット」は、典型的には、１つのローカルファブリックからの１つのルータポートを他のローカルファブリックからのちょうど１つのルータポート（すなわち、中間スイッチなし）と接続することによって形成される「単純な」物理ＩＢサブネットである。ゲートウェイサブネットは、リンクアップ時に確立される単純な構成を持ち、パケット転送ポリシーは各側のルータによって独立して制御される。２つのルータポートは、リモートファブリックについて学習するために、相互発見プロトコルを実現する。これに代えて、および／または加えて、各ローカルファブリックにおける管理入力を、必要または所望に応じて選択的に用いて、異なるゲートウェイサブネットを介してルーティングされるべき１つ以上のリモートサブネット番号および個々のＧＩＤのセットを定義することができる。ここでのゲートウェイサブネット定義の重要な局面は、管理すべきルータまたはスイッチデバイスではなく、ＩＢリンク上の２つの最上位の管理ドメイン間の境界を配置することである。

【0133】

より複雑なゲートウェイサブネットは、ゲートウェイサブネット内のスイッチも管理を必要とし、この管理によって、直接リンクの場合には存在しないか、またはあまり存在しない複雑さおよびポリシーの問題が導入されることを暗示する。したがって、単一リンクの各側の充分に定義された所有者を有することよりも、ゲートウェイサブネットの所有権の問題が問題になる。しかしながら、大規模なネットワーク化の場合と同様に、複数のローカルファブリックが１つ以上の他のローカルファブリックを介して接続されている、より複雑な構成を想像することが可能である（つまり、中間ローカルファブリックのアドミニストレータは、接続された異なるリモートファブリックがこのローカルファブリックを介して通信することを許される方法を判断する）。本明細書の実施形態は、各ローカルファブリックが複数の他のローカルファブリックへの接続性を有することができるので、このより複雑なゲートウェイモデルに適用可能である。いずれにしても、これらのタイプの中間ローカルファブリックであっても、ローカルファブリックの任意の対の間の境界は、好ましくは、上で定義した最小ゲートウェイサブネットである。

【0134】

リーフサブネット
「リーフサブネット」は、それ自体のユニキャストおよびマルチキャストＬＩＤ空間を有する物理的なＩＢサブネットである。計算およびストレージサーバなどのホストタイプのエンドノードは、典型的には、単一のリーフサブネットを介してローカルファブリックに接続される。しかしながら、単一のホストが、さらに所望の通りに複数のリーフサブネットと接続されてもよい。リーフサブネットは、１つ以上の協働サブネットマネージャ（ＳＭ）インスタンスによって構成および制御され、リーフサブネット内では、パケットはパケットヘッダのＬＲＨ．ＤＬＩＤ部分に基づいて転送される。リーフサブネットは、レガシースイッチで構成されてもよく、中央の最上位の管理エンティティと並んで、リーフサブネットを制御しているサブネットマネージャのセットに入力されるポリシーを表す管理上定義された「識別サブネット番号」（ＩＳＮ）によって識別される。ＩＳＮは、グローバルに一意であってもよく、好ましくは、ＩＢリンクを介して、すなわちゲートウェイサブネットを介して直接接続できるすべてのローカルファブリックにわたって一意である。各リーフサブネットは、ポートを介して１つ以上の「コアファブリック」に接続されてもよく、各リーフサブネットは、少なくとも１つのコアファブリックに接続されると、少なくとも１つの「ファブリックローカルサブネット番号」（ＦＬＳＮ）に関連付けられる。ＦＬＳＮ値は、ローカルファブリックについての範囲を持ち、ローカルファブリック管理インフラストラクチャによって割り当てられる。加えて、リーフサブネットは、コアファブリック接続性を表さないルータポートを介して他のＩＢサブネットに接続されてもよい。一般的な場合において、このような「グローバル」接続は、ゲートウェイサブネットを介したリモートファブリックへの接続を表し、この種のグローバル接続の場合、ＩＳＮ値は、リモートサブネット／ファブリックからのこのリーフサブネットのＤＧＩＤベースのアドレス指定に使用される。しかしながら、２つのリーフサブネットを同じローカルファブリックにおいてこのように、すなわちローカルコアファブリックを使用せずに、接続することも可能である。この種の接続は、ＩＳＮまたはＦＬＳＮベースのＤＧＩＤアドレス指定のどちらを使用してもよい。直接、リーフサブネットからの、ローカルファブリック内またはリモートファブリックへの、ルータポートベースの接続には、システムポートまたは他のルータ実現例のどちらが関係してもよい。

【0135】

コアファブリック
一実施形態によれば、「コアファブリック」は、単一のローカルファブリックのコンテキスト内で１つ以上のリーフサブネットを接続する例示的な実施形態によるトポロジである。ここでは、「中間スイッチファブリック」という表現を代わりに使用してもよい。一実施形態によれば、コアファブリックは、たとえば、同じ物理サブネット内に既に直接的な接続性を有するセクションなど、単一のリーフサブネットの異なるセクション間に追加
の接続性を提供する。例示的な実施形態では、単一のコアファブリックは、単一の「サブネット間ルート番号」（ＩＳＲＮ）値空間を表すことが好ましい。単一のコアファブリックは直接接続されたエンドノードを有することができる。エンドノードの特殊なケースは、スイッチ管理ポート（ポート０）である。これらは専用のＩＳＲＮ値を介して到達することができ、ＧＲＨベースの通信が必要である。物理ＩＢリンクおよび／またはシステムポートを介して接続される物理エンドノードは、一般に、別個のＦＬＳＮ（またはＩＳＮ）値を表し、通信は、好ましくはＧＲＨベースである。このような直接接続されたエンドノードは、一般に、わずか２つのポートおよび単一のリンク、すなわちエンドノードポートおよび関連するシステムポートを有する、「単純な」リーフサブネットを表す。例示的な実施形態の環境では、直接接続された物理エンドノードは、ＤＬＩＤ値が一意でないかもしれないことをエンドノード実現例が処理できる限り、専用ＩＳＲＮ値を介してアドレス指定することもできることを理解されたい。一般に、ＦＬＳＮ値はローカルファブリック全体に対してグローバルでなければならないので、必要な値の空間を減らすために、別個のＦＬＳＮ値をそのようなエンドポートについて選択的に割り当てないかもしれない。

【0136】

ある例示的な実施形態による単一のコアファブリックは、従来の物理的ＩＢサブネット内での他の処理または取り扱いと同様の態様で直接ルート（ＤＲ）サブネット管理パケット（ＳＭＰ）を処理または他の態様で取り扱う。しかしながら、一実施形態によれば、単一のコアファブリックは、ＬＩＤベースの転送をＩＳＲＮベースの転送と並んでサポートするように構成されている。したがって、使用される総ＬＩＤ値空間は、使用される総ＩＳＲＮ値空間と調整される。調整には、両方のタイプの転送に同じ物理的ＬＦＴリソースの異なるセクションを使用すること、およびこれらのセクションのサイズを各システムポートについて実行時設定パラメータとして設定することが含まれる。

【0137】

例示的な実施形態では、重複するＬＩＤ値およびＩＳＲＮ値について、２つの使用される値空間の合計が、関与するハードウェアコンポーネントによってサポートされ得る限り、制限はない。十分なＬＩＤ値空間が割り当てられていると仮定すると、システムのポート０インスタンスおよび直接接続されたエンドノードの両方に、ＬＩＤベースのアドレス指定を介して、到達することができる。このように、単一のコアファブリックインスタンスは、従来のＩＢサブネットを表し、同時に、１つ以上の（他の）リーフサブネット間のコアファブリックとして機能しているので、ローカルファブリック内の宛先リーフサブネットを表すこともできる。

【0138】

加えて、例示的な実施形態では、単一コアファブリックは、１つ以上の他の各単一コアファブリックごとに独立したＩＳＲＮ値空間を依然として維持しながら、そのような単一コアファブリックへの直接的な物理的接続性を有することができる。ＤＲ ＳＭＰを、サポートされている任意の他のタイプの転送に依存することなく、２つのコアファブリックインスタンス間で通信するよう使用してもよい。値空間の調整と、ＬＩＤまたはＩＳＲＮ空間の特定のサブセットの予約とに基づいて、２つのコアファブリックにおけるエンドノードのすべてまたはサブセット間の通信を、ＬＩＤまたはＩＳＲＮベースのアドレス指定を使用して許可し得るかまたは他の態様で可能にする。

【0139】

単一のコアファブリックは、例示的な実施形態では、リモートファブリックへの接続性を表す１つ以上のルータポートを有してもよい。つまり、それらは、調整されたＦＬＳＮまたはＩＳＲＮ空間のない独立したローカルファブリックである。このようなリモート接続性は、好ましくはゲートウェイサブネットを使用して実現される。この場合、ローカルエンドノードまたは接続されたリーフサブネットとの間でパケットを転送することは、ＩＳＮベースのサブネットプレフィックス値を伴うＧＲＨ、およびＤＧＩＤフィールドにおける関連付けられるＧＵＩＤ値に基づく。そのような転送は、ＤＧＩＤの任意の部分の任意の特定のフォーマットに依存せず、代わりにＴＣＡＭベースの転送に依存する。

【0140】

アドレス指定モード
一実施形態によれば、パケットの「アドレス指定モード」は、パケットがソースから宛先へどのように送られるべきかを判断するために使用されるべき特定のヘッダ情報を定義する。ＩＢパケットは、パケットがソースから宛先へどのように送られるべきかに関する情報を含む複数のヘッダ（すなわち、ＬＲＨおよびＧＲＨ）を含んでもよい。したがって、パケットのアドレス指定モードは、どのようなそのような情報が次の転送判断に使用されるべきかを定義する。

【0141】

例示的な実施形態では、この文脈における関連するアドレス指定モードは、以下を含む：
ＬＲＨ／ＤＬＩＤアドレス指定モード；
ＧＲＨ／ＩＳＲＮアドレス指定モード；
ＧＲＨ／リーフスイッチアドレス指定モード；および
ＧＲＨ／ＤＧＩＤアドレス指定モード。

【0142】

転送モード
一実施形態によれば、「転送モード」は、パケット転送判断を実行するスイッチポートに適用される。「アドレス指定モード」の概念はＩＢパケットのヘッダに適用されるが、転送の判断を行うスイッチポートは、あるパケットアドレス指定モードに対応する「転送モード」で動作する。スイッチポートは１つより多いアドレス指定モードを同時にサポートしてもよい。したがって、スイッチポートが特定のパケットのために正しい転送モードを選択することを可能にするために、パケットは、スイッチポートが決定論的にアドレス指定モードを判断することを可能にする情報を含まなければならないかもしれない。そのような情報には、ＤＧＩＤタイプ情報および特定の転送モード（たとえば、ＧＲＨ／ＩＳＲＮ）を示すために予約された特殊なＤＬＩＤ値の両方が含まれる。また、場合によっては、次ホップアドレス指定モードは、パケットにおけるアドレス情報およびファブリックにおけるポートに関連付けられる構成情報の両方の関数である。宛先リーフサブネットに到達した時点を判断するための例示的な実施形態における能力は、次ホップアドレス指定モードがパケットにおけるアドレス情報およびファブリックにおけるポートに関連付けられる構成情報の両方の関数であることの例である。

【0143】

転送ドメイン
一実施形態によれば、任意の特定のリーフサブネット、コアファブリックまたはゲートウェイサブネットインスタンスは、「転送ドメイン」を表わしてもよい。ＩＢパケットが完全なＩＢファブリックを通じて転送されると、図１３に示すような１つ以上の「転送ドメイン」を通過し、そのような各転送ドメインは特定の転送モードおよび特定のアドレス値空間を表す。一実施形態によれば、「転送ドメイン」は、複数のリーフサブネットおよび複数のコアファブリックの間の境界である。最も単純なスキームでは、個々のシステムインスタンスは、単一の転送ドメイン、たとえば単一のリーフサブネットまたは単一のコアファブリックインスタンスに属する。この場合、リーフサブネットまたはコアファブリックインスタンスの任意の対間のすべての境界は、異なるシステムインスタンスを接続する１つ以上のリンク上に存在する。リーフサブネットおよびコアファブリックインスタンスの両方が任意のサイズを有することを可能にするために、個々のシステムインスタンスは、２つ以上の「仮想スイッチ」インスタンスに選択的に分割され、各そのような仮想スイッチは、すべてが単一のリーフサブネットまたは単一のコアファブリックへの、またはその内における接続性を表す、１つ以上の「仮想スイッチポート」の集まりを表す。この場合、転送ドメインの任意の対間の境界は、２つ以上の仮想スイッチインスタンスを接続するシステムクロスバー内に存在する。

【0144】

図１３に示すように、ソースサブネット内では、第１の転送ドメインで元の（またはレガシー）ＬＲＨ．ＤＬＩＤスキームを使用してＬＦＴ探索が実行される。第２の転送ドメインにおいては、図示のように、コアファブリック内における、ソースサブネットからコアファブリックへパケットを転送する際のＬＦＴ探索が、本明細書の例示的な実施形態によるＩＳＲＮスキームを使用して実行される。さらに、図示のように、第３の転送ドメインにおける、コアファブリックからターゲットサブネットにパケットを転送する際のＬＦＴ探索が、ターゲットＬＩＤ１１４３（図１１）に基づくＬＲＨ．ＤＬＩＤを使用して実行される。

【0145】

ゲートウェイポート
一実施形態によれば、転送ドメインへの接続性を表す物理的なシステムポートは、本明細書では「ゲートウェイポート」と呼ばれる。以下に述べる理由から、ゲートウェイポートは、パケットをゲートウェイポートに送信する同じシステムインスタンス上の別のポートの観点から定義される。まず、ゲートウェイポートにパケットを送信することは、送信が次のいずれかであるため、パケットに対するアドレス指定モードが変更されることを意味する。

【0146】

Ｉ．ソースリーフをコアファブリックに送信する。
ＩＩ．コアファブリックを宛先リーフに送信する、または
ＩＩＩ．ソースリーフを宛先リーフに送信する。

【0147】

パケットのアドレス指定モードは、ＩＢリンクから受信されるパケットに対して転送判断がどのように行われるかに適用されるので、図１３に示される１つの転送ドメインから他の転送ドメインへと交差するときのアドレス指定モードの変更は、一実施形態によれば、パケットがシステム入口ポートから出口ポート、たとえばゲートウェイポートなどに移動されるときに実施される。アドレス指定モードは、次いで、パケットがゲートウェイ／出口ポートからＩＢリンクに転送されるときにアクティブになる。

【0148】

この理由から、ゲートウェイポートは、パケットをゲートウェイポートに送信する同じシステムインスタンス上の別のポートの観点から定義される。

【0149】

異なる転送ドメイン間の境界を表すリンクは、通常、リンクの両側にゲートウェイポートを有することになることを理解されたい。リンクの両側にゲートウェイポートを持つ動機は、転送ポリシーの更新がリンクの各側に確実に含まれるようにすることで、リンクにわたる書き込み型管理操作の必要性を排除することである。たとえば、リンクの一方の側がコアファブリックを表し、他方の側がリーフサブネットを表す場合、リーフサブネット側のサブネットマネージャは、例示的な実施形態に従って、ＩＢリンク上で受信されるパケットの転送の完全な制御を有する。

【0150】

例示的な実施形態では、リンク上のパケットは、典型的には、各方向において異なるアドレス指定モードを有し、ＩＢリンクの各側のポートに対する転送モードは、リンクのその側の「転送ドメイン」に対応することになる。たとえば、リンクの一方の側がコアファブリックを表し、リンクの他方の側がリーフサブネットを表す場合、コアファブリックからリーフサブネットに転送されているパケットは、図１３の右側に示すようにＬＲＨ／ＤＬＩＤベースのアドレス指定モードを有することになり、リーフサブネットからコアファブリックに転送されているパケットは、図１３の左側に示すようにＧＲＨ／ＩＳＲＮベースのアドレス指定モードを有することになる。

【0151】

リンクの一方の側のみに位置する単一のゲートウェイポートの場合、その単一のゲートウェイポートは、リンクのリモート側の転送ドメインの一部として管理されることに注目
されたい。例として、リンクの一方の側がコアファブリックを表し、他方の側がリーフサブネットを表し、リーフサブネット側にゲートウェイポートがない場合は、リンクのコアファブリック側のポートはリーフサブネットの一部でもある必要があり、さらに、その転送ロジックが、そのリーフサブネットにおけるサブネットマネージャによって構成される必要もあるだろう。これは、このサブネットマネージャが、次いで、コアファブリック内の最初のホップ転送を効果的に実現することを意味するので、２つの転送ドメイン間の不要な依存性は、転送ドメイン間の境界をリンクからシステムクロスバーに移動させ、ゲートウェイはコアファブリック側に位置することによって、効果的に除去され得る。上述のことが、他の方向におけるパケットの転送に対して、対応して、行われる。

【0152】

一方、ゲートウェイポートをリンクの両側に有する場合、転送ドメイン間の唯一の依存性は、パケットをゲートウェイポートを介してＩＢリンクに転送することが、パケットが正しいアドレス指定モードを有するかまたはそれを提供されるという保証とともに行われる、ということである。アドレス指定モードの変更が行われるときにパケットの出力ポートが既に判断されているので、アドレス指定モードの変更はこの点で転送／ルーティング判断に影響を与えない。

【0153】

受信側では、入力パケット処理および転送判断は、その転送ドメインにおける任意のスイッチポートに対するのと同様に、標準のサブネット内プロトコルに従って実行される。

【0154】

単一のシステムインスタンス内のクロスバーベースの境界の場合、同じクロスバー上の、すなわち同じシステムインスタンス内の）任意の仮想スイッチインスタンスに対するゲートウェイポートである任意の物理ポートは、また、同じシステムインスタンス内の別の仮想スイッチ内の仮想スイッチポートであってもよい。

【0155】

特殊なケースは、システムインスタンスをあるリーフサブネットまたはコアファブリックに接続する単一のポートを含む。技術的には、単一のポートは定義上、ローカルサブネット／転送ドメイン内の他のソースエンドポートとターゲットエンドポートとの間のパケット転送を行うことができるという意味において、わずか単一の外部ポートを伴うスイッチは、スイッチ管理ポートへのアクセスを提供し、それによってスイッチ管理ポートをサブネット内のエンドポイントとして機能させるという点で、依然として有効な構成であるというＩＢＴＡの観点から、スイッチではない。本例示的実施形態では、このような単一のポートは、スイッチングについて依然として関連性があり、なぜならば、クロスバーベースの転送ドメイン境界を介する他のリーフサブネットおよび／またはコアファブリックへのアクセスを提供するからである。したがって、リモートリーフサブネットまたはコアファブリックの観点から、それはある数のゲートウェイポートに対するアクセスを提供するが、ローカル転送ドメイン内の仮想スイッチポートに対するアクセスは提供しない。

【0156】

上記に加えて、１つより多い物理ポートがシステムインスタンスを同じコアファブリックまたはリーフサブネットに接続する場合、このポートの集まりは、デフォルトで仮想スイッチインスタンスとして表されるであろうことに注目されたい。しかしながら、ファブリックトポロジの観点からは、この切換えられる接続性に対する必要性はないかもしれず、ポートの集まりを１つ以上の仮想スイッチとして表現することは、すべての個々のポートが、同一転送ドメインにおける他のポートへの接続性を許可せずに、他のリーフサブネットまたはコアファブリックにおけるゲートウェイポートへの接続性を与えるにすぎない場合を含んで、ファブリック定義ポリシーの問題になる。

【0157】

リーフサブネット仮想スイッチ
一実施形態によれば、「リーフサブネット仮想スイッチ」は、同じリーフサブネットに接続する単一のシステムインスタンス上の１つ以上の物理ポートの集まりをベースライン
として定義する。ファブリックローカルサブネット番号（ＦＬＳＮ）が使用されている場合、同じリーフサブネット仮想スイッチにおけるすべてのポートは、通常、同じＦＬＳＮ値を表わすことになる。概念的には、同じリーフサブネット仮想スイッチ内の異なるポートは異なるＦＬＳＮ値を表してもよく、各ポートは、すべて同じ物理サブネットを表すにもかかわらず、１つより多い値を表してもよいことに注目されたい。また、同じＦＬＳＮ値が、異なる物理リーフサブネットにおけるリーフサブネット仮想スイッチポートに関連付けられてもよい。

【0158】

上記スキームに対する１つの動機は、経路情報の変更を暗示することなく、リーフサブネット間のＶＭのマイグレーションを可能にすることである。しかしながら、完全な経路情報を維持するために、ＤＬＩＤを保存するか、またはＤＬＩＤについてそのような例外の場合に使用され得るマッピング機能を提供することができる。

【0159】

制限された数のマッピングリソース、およびポート当たり１つより多い制限された数のＦＬＳＮ値で、さらなる例示的な実施形態による高度なスキームは、２段階のマイグレーションスキームを使用し、マイグレーションは、第１ラウンドでは、制限されたハードウェアリソースの一部を使用して、経路更新なしに行なわれ、一方で、同時の経路更新プロセスを提供し、関連するすべてのピアによって経路情報が更新され、元の経路／アドレスはもはや必要ではなくなると、制限されたハードウェアリソースが再び解放され得るようする。

【0160】

例示的な実施形態では、リーフサブネット仮想スイッチは、それ自体を、標準的なＳＭＡ属性を介して標準的なＩＢスイッチとして提示する。したがって、レガシーサブネットマネージャ（ＳＭ）は、ローカルサブネットの一部である任意の他の標準的ＩＢレガシースイッチと同様に、システムベースのリーフサブネット仮想スイッチを発見および構成できる。

【0161】

さらに、例示的な実施形態では、リーフサブネット仮想スイッチを拡張して、ローカルファブリックの他の部分への接続性またはリモートファブリックへの接続性を提供するゲートウェイサブネットへの接続性を表してもよい。このような接続性は、１つ以上の「特殊な」ポートがリーフサブネット仮想スイッチに含まれ、たとえば、特殊なＳＭＡ属性を介する同じ仮想スイッチ上の追加のポート番号などとして直接確認できることを意味する。つまり、１つ以上のコアファブリックゲートウェイポートは１つ以上のコアファブリックへの接続性を提供でき、１つ以上の仮想ルータポートは、物理ルータポート、およびリーフサブネット仮想スイッチの範囲外のさまざまな他のポートへの接続性を提供できる。

【0162】

たとえば、仮想ルータポートは、標準的なＳＭＡ属性を介して間接的に確認され得るが、ルータポートとして識別される別のポートへの（仮想）リンクを有する別のスイッチポートによって表され得る。

【0163】

このようにして、レガシーサブネットマネージャ（ＳＭ）は、他のサブネットへのルータベースの接続性を発見し、利用することができる。しかしながら、システム認識サブネットマネージャ（ＳＭ）は特殊なＳＭＡ属性を利用して特殊なポートを直接発見することになるので、「レガシーＳＭ」サポートの必要性は減少することを理解されたい。

【0164】

さらに例示的な実施形態に関して、１つ以上のリーフサブネットゲートウェイポートは、１つ以上の他のリーフサブネットへの接続性を提供することができる。

【0165】

リーフサブネット仮想スイッチポート
例示的な実施形態によれば、リーフサブネット仮想スイッチポートは、リーフサブネッ
ト仮想スイッチインスタンスに属することができ、たとえばＩＢリンクに到着するパケットについて出力ポート番号を探索するためにＬＲＨ．ＤＬＩＤ値を使用する。このリーフサブネット仮想スイッチインスタンスに対して出力ポート番号が表すポートのタイプは、例示的実施形態では、メンバーの物理ポートに利用可能な構成情報によって定義される。出力ポートは、同じリーフサブネット仮想スイッチにおける別の仮想スイッチポート、コアファブリックゲートウェイポート、仮想ルータポート、または別のリーフサブネットへの直接接続性を提供するリーフサブネットゲートウェイポートを表してもよい。出力ポートは一般に物理ルータポートではない可能性があり、なぜならば、これは、新たなＬＲＨが、パケットＧＲＨに基づく動的な態様で構築されることになることを意味し、そして、これは、仮想ルータポートを介してしか行われ得ないからである。

【0166】

わずか２つのポート（すなわち、ローカルおよびリモートルータポート）を有する単純化されたゲートウェイサブネットの定義が与えられている場合、次のホップに使用するＤＬＩＤは、個定値に基づくか、またはローカル物理ルータポートにリモートルータポートのＬＩＤ値を記録させることに基づくであろう単純化されたスキームを提供し、これを次ホップＤＬＩＤとして用いることを保証することが可能であることを理解されたい。

【0167】

リーフサブネット仮想スイッチポートである物理ポートは、さらに、別のリーフサブネット仮想スイッチまたはコアファブリック仮想スイッチの観点から、リーフサブネットゲートウェイポートとして動作してもよいことをさらに理解されたい。

【0168】

コアファブリック仮想スイッチ
一実施形態によれば、「コアファブリック仮想スイッチ」は、同じコアファブリックに接続する単一のシステムインスタンス上の１つ以上の物理ポートの集まりをベースラインとして定義する。

【0169】

例示的な実施形態では、コアファブリック仮想スイッチは、それ自体を、選択された特殊なＳＭＡ属性を介して特殊なＩＢスイッチとして提示する。したがって、レガシーサブネットマネージャ（ＳＭ）は、例示的な実施形態のシステムのコアファブリック仮想スイッチを発見および構成することはできないことになる。

【0170】

コアファブリック仮想スイッチを拡張して、ローカルファブリックの他の部分への接続性またはリモートファブリックへの接続性を提供するゲートウェイサブネットへの接続性を表してもよい。このような接続性は、１つ以上の他の「特殊な」ポートがコアファブリック仮想スイッチに含まれ、たとえば、特殊な選択されたＳＭＡ属性を介して同じ仮想スイッチ上の追加のポート番号として直接確認できることを意味し、１つ以上のリーフサブネットゲートウェイポートは１つ以上のリーフサブネットへの接続性を提供でき、１つ以上の仮想ルータポートは、物理ルータポート、およびリーフサブネット仮想スイッチの範囲外のさまざまな他のポートへの接続性を提供でき、１つ以上のコアファブリックゲートウェイポートは、１つ以上の他のコアファブリックへの接続性を提供することができる。

【0171】

コアファブリック仮想スイッチポート
例示的な実施形態によれば、コアファブリック仮想スイッチインスタンスのコアファブリック仮想スイッチポートは、ＩＢリンクに到着するパケットについて出力ポート番号を探索するためにＧＲＨ．ＤＧＩＤ．ＩＳＲＮ値を使用する。探索されたポート番号がこのコアファブリック仮想スイッチインスタンスに対して表す出力ポートのタイプは、メンバーの物理ポートに利用可能な構成情報によって定義される。出力ポートは、同じコアファブリック仮想スイッチにおける別のコアファブリック仮想スイッチポート、リーフサブネットゲートウェイポート、仮想ルータポート、または別のコアファブリックへの直接接続性を提供するコアファブリックゲートウェイポートを表してもよい。

【0172】

出力ポートは一般に物理ルータポートではない可能性があり、なぜならば、これは、新たなＬＲＨが、パケットＧＲＨに基づく動的な態様で構築されなければならないことを意味し、そして、これは、仮想ルータポートを介してしか行われ得ないからである。

【0173】

コアファブリック仮想スイッチポートである物理ポートは、さらに、別のリーフサブネット仮想スイッチまたはコアファブリック仮想スイッチの観点から、コアファブリックゲートウェイポートとして動作してもよいことを理解されたい。

【0174】

コアファブリックゲートウェイポート
システムクロスバーベースの仮想スイッチおよび転送ドメイン境界の場合、コアファブリックゲートウェイポートである物理ポートは、関連するコアファブリック接続性を表わすコアファブリック仮想スイッチの観点から、コアファブリック仮想スイッチポートとして動作してもよいことが理解されるべきである。したがって、物理スイッチポートの観点からは、パケット転送代替策は、このセクションで説明するゲートウェイポート関連の転送に加えて、上で「コアファブリック仮想スイッチポート」に関して説明したものを含む。

【0175】

例示的な実施形態によれば、コアファブリックゲートウェイポートは、それらの仮想コアファブリックスイッチが他のコアファブリックインスタンス／転送ドメインも表すなど、同じシステムインスタンスにおける他のコアファブリック仮想スイッチに属する１つ以上のリーフサブネット仮想スイッチポートまたはコアファブリック仮想スイッチポートに対するコアファブリックインスタンスに対する入力またはそれからの出力を処理するポートを表す。

【0176】

システムクロスバーを介してパケットを受信するコアファブリックゲートウェイポートは、一般に、いかなるアドレス指定モードも変更できず、代わりに、受信されるパケットが、それを既に転送したシステム入口ポートからの正しいアドレス指定で設定されていることに依存し得る。

【0177】

例示的な実施形態では、物理ポートは複数の役割を有し得、特定の役割が入口ポートからパケットを転送する時点で判断されるので、一部のハードウェア設計上の制約により、この種のパイプライン化がより効率的になるのでなければ、一般に、アドレス情報を出力ポイントで更新する必要はないことに注目されたい。

【0178】

リンクベースの転送ドメイン境界の場合、コアファブリックゲートウェイポートは、ローカルシステムインスタンスが表すリーフサブネットの転送ドメインの一部である。したがって、ＩＢリンクに到着するパケットについての転送モードは、「ＬＲＨ／ＤＬＩＤ」転送モードである。

【0179】

システムクロスバーベースの転送ドメイン境界の場合、コアファブリックゲートウェイポートは、リモートコアファブリックインスタンスによって定義された転送ドメインの一部である。したがって、ＩＢリンク上に到着するパケットについての転送モードは、「ＧＲＨ／ＩＳＲＮ」転送モードである。

【0180】

探索されるポート番号が関連する転送ドメインに対して表わす出力ポートのタイプ（すなわち、ゲートウェイポートが表すコアファブリックインスタンス）は、物理ポートに利用可能な構成情報（すなわち、物理ポートの仮想スイッチポートのパーソナリティ（もしあれば）について略述されるのと同じ情報）によって定義される。

【0181】

出力ポートは、リーフサブネットゲートウェイポート、または２つのコアファブリックが単一のシステムクロスバーを介して接続されている場合にそうであるかもしれないような別のコアファブリックゲートウェイポートを表してもよく、また、仮想ルータポートを表してもよい。

【0182】

図１４は、一実施形態による、ＧＲＨ／ＩＳＲＮアドレス指定モードフォーマットからＬＲＨ／ＤＬＩＤベースの転送フォーマットへのパケットヘッダの変更を示す図である。パケットがコアファブリックゲートウェイポートからシステムクロスバー経由でリーフサブネットゲートウェイポートに移動するとき、この遷移はＧＲＨ／ＩＳＲＮアドレス指定モードからＬＲＨ／ＤＬＩＤベースの転送への変更を表わす。これは、図に示すように、新たなパケット１４００のヘッダ内に、パケットＧＲＨ１１１１から抽出されたＤＬＩＤ１１４３（すなわち、システム特有のＧＲＨ．ＤＧＩＤ．リモートＤＬＩＤフィールド）を有する新たなＬＲＨが構築されることを意味する。一般に、この転送は、パケットＦＬＳＮ値を、リーフサブネットゲートウェイポートに関連付けられたＦＬＳＮ値と相関付けることとは独立して、充分に定義されることに注目されたい。つまり、アドレス指定モードの変更を達成するために必要な唯一の情報は、出口ポートが入口ポートの観点からリーフサブネットゲートウェイポートとして定義されているということであり、これはどのようなＦＬＳＮ値が関係するかとは無関係である。この観察に基づいて、パケットＦＬＳＮ値とポートＦＬＳＮ値との相関は、本質的に、ルーティングが正しく設定されていることの「アサート」である。

【0183】

この問題は、エンドノードに関連付けられるＬＩＤの問題と同様である。ローカルＬＩＤは、パケットを送信するときに正しいＳＬＩＤを生成するために必要であるが、サブネットがＬＩＤ割当に従って正しくルーティングされる限り、一旦着信パケットが宛先エンドノードに到着すれば、パケットでＤＬＩＤを処理する必要は本質的にない。スイッチ転送テーブルが、初期または新たなＬＩＤ値をエンドノードに割り当てることに関して正しいシーケンスで更新される限り、エンドノードは、受信したＤＬＩＤが割当てられたＬＩＤと競合しているケースを決して見ない。

【0184】

一方、エンドノードにおいてＤＬＩＤチェックを任意にすることは、ファブリックは、原則として、単一のエンドノードへの転送のために、任意の数のＬＩＤおよび関連付けられるルーティングを用いることができることを意味する。宛先がリーフサブネットであるこの場合、ＦＬＳＮ値チェックを任意にすることは、異なるリーフサブネット間のＶＭマイグレーションをより柔軟に実現できることを意味する。

【0185】

図１５は、一実施形態による、ＬＲＨ／ＤＬＩＤアドレス指定モードからＧＲＨ／ＩＳＲＮアドレス指定モードにパケット転送を変更するための特殊スイッチポート境界を定義するメカニズムを提供するスイッチの図である。パケットがリーフサブネットゲートウェイポートからシステムクロスバー経由でコアファブリックゲートウェイポートに移動するとき、この遷移はＬＲＨ／ＤＬＩＤアドレス指定モードからＧＲＨ／ＩＳＲＮアドレス指定モードへの変更を表わす。これは、図に示すように、ＩＳＲＮベースの転送を識別する固定されたＤＬＩＤを有する新たなＬＲＨが構築されることを意味する。これに関して、スイッチ１５００は、ＬＲＨ／ＤＬＩＤアドレス指定モードからＧＲＨ／ＩＳＲＮアドレス指定モードにパケット転送を変更するための特殊スイッチポート境界を定義するメカニズムを提供する。中間スイッチファブリックへの進入をサポートする実施形態によれば、あるメカニズムが、ファブリックの選択されたスイッチ１５００に設けられ、それによって境界が画定され得る。一実施形態では、「特殊スイッチポート」（ＳＳＰ）１５１０が定義され、ＳＳＰはローカルサブネットの「終わり」を表す。一実施形態では、パケットは、元の／通常のローカルルートヘッダ１１１２におけるＤＬＩＤ１１２２（図１１）を使用して、ＬＦＴ１２００（図１２）を介して仮想サブネットの仮想エンドポートを表す
ＳＳＰ１５１０を指す。ＳＳＰには、この点でこのサブネットにおける「エンドポート」を表すことを示す属性が与えられる。特殊属性は、転送のモードにおける変更を示し、次の転送レベルでは、ローカルルートヘッダ１１１２におけるＤＬＩＤ１１２２を使用する代わりに、ＧＲＨ／Ｌ３アドレスの６４ビットのサブネットプレフィックス番号部分からの指定／専用ビットフィールド１１３１を使用する。本質的に、元のＤＬＩＤ１１２２は、指定／専用のビットフィールドまたはその一部で置き換えられて、例示的な実施形態による、ＩＳＲＮベースの転送で使用するための新たなＤＬＩＤ１１１０’を形成する。

【0186】

一実施形態では、スイッチ１５００は、ＬＩＤベースのフィルタリング技術を使用することができる。この実施形態では、スイッチ１５００は、ＳＳＰ１５１０をターゲットとするパケットを識別することができる受信（Ｒｘ）フィルタ１５２０を含むことができる。したがって、スイッチ１５００は、ＳＳＰ１５１０をターゲットとするデータフロートラフィックを、通常／レガシー転送モダリティポート１５３０をターゲットとするデータフロートラフィックから分離することができる。たとえば、Ｒｘフィルタ１５２０は、（たとえば、ＤＬＩＤベースのフィルタリングを使用して）サービスＤＬＩＤに基づいて混合データフロートラフィックを分離することができる。以下は、例示的なパケット転送ロジックＤＬＩＤテーブルである。

【0187】

ＤＬＩＤ＝０ｘＦ
ＤＬＩＤ＝０ｘＦＦ
着信パケットが一致するＤＬＩＤを有する場合（たとえば、０ｘＦまたは０ｘＦＦ）、Ｒｘフィルタ１５２０は、パケットをＳＳＰ１５１０に向けることができる。一方、着信パケットが一致するＤＬＩＤを有さない（すなわち、０ｘＦおよび０ｘＦＦ以外のＤＬＩＤを伴う）場合、Ｒｘフィルタ１５２０は、着信パケットを通常／レガシー転送モダリティポート１５３０に向けることができ、それは、ＩＢプロトコルエンジンを使用してＩＢパケットを標準的なＩＢプロトコルに従って処理できる。

【0188】

例示的な実施形態によれば、パケットがコアファブリックゲートウェイポートと別の（すなわち異なるコアファブリックインスタンスに接続される）コアファブリックゲートウェイポートとの間で移動する場合、同じＧＲＨ．ＤＧＩＤ．ＩＳＲＮ値が依然として転送に使用される。したがって、管理ソフトウェアは、１つのコアファブリックインスタンスから別のコアファブリックインスタンスに交差するパケットトラフィックが、２つ以上のコアファブリックの両方で一貫して処理されるＧＲＨ．ＤＧＩＤ．ＩＳＲＮ値を表していることを保証し、なぜならば、デフォルトでは、各コアファブリックインスタンスはそれ自体のＩＳＲＮ値空間を表わすからである。

【0189】

パケットがコアファブリックゲートウェイポートから仮想ルータポートに移動するとき、次ステップ転送スキームは仮想ルータポートによって実現されるポリシーの機能である。

【0190】

出力ポートは一般に物理ルータポートではない可能性があり、なぜならば、これは、新たなＬＲＨが、パケットＧＲＨに基づく動的な態様で構築されることになることを意味し、そして、これは、仮想ルータポートを介して行われるからである。

【0191】

リーフサブネットゲートウェイポート
システムクロスバーベースの転送ドメイン境界の場合、リーフサブネットゲートウェイポートである物理ポートは、関連するリーフサブネット接続性を表わすリーフサブネット仮想スイッチの観点から、リーフサブネット仮想スイッチポートとして動作してもよい。したがって、物理スイッチポートの観点からは、パケット転送代替策は、このセクションで説明するゲートウェイポート関連の転送に加えて、上で「リーフサブネット仮想スイッ
チポート」に関して説明したものを含む。

【0192】

例示的な実施形態によれば、リーフサブネットゲートウェイポートは、同じシステムインスタンスにおける他のリーフサブネット仮想スイッチに属する１つ以上のコアファブリックゲートウェイポートおよび／または１つ以上のリーフサブネット仮想スイッチポートに対するリーフサブネットインスタンスへの入力またはそれからの出力を処理するポートを表す。これに関して、システムクロスバーを介してパケットを受信するリーフサブネットゲートウェイポートは、一般に、いかなるアドレス指定モードも変更せず、代わりに、受信されるパケットが、それを転送したシステム入口ポートからの正しいアドレス指定で既に設定されていることに依存する。

【0193】

リンクベースの転送ドメイン境界の場合、リーフサブネットゲートウェイポートは、特定のシステムインスタンスが表すコアファブリックの転送ドメインの一部である。したがって、ＩＢリンク上に到着するパケットについての転送モードは、「ＧＲＨ／ＩＳＲＮ」転送モードである。

【0194】

システムクロスバーベースの転送ドメイン境界の場合、リーフサブネットゲートウェイポートは、リモートリーフサブネットインスタンスによって定義された転送ドメインの一部である。したがって、ＩＢリンクに到着するパケットについての転送モードは、「ＬＲＨ／ＤＬＩＤ」転送モードである。

【0195】

出力ポートは、コアファブリックゲートウェイポート、または２つのリーフサブネットが単一のシステムクロスバーを介して接続されているときなどのような別のリーフサブネットゲートウェイポートを表してもよく、また、仮想ルータポートを表してもよい。

【0196】

例示的な実施形態によれば、パケットがリーフサブネットゲートウェイポートからシステムクロスバー経由でコアファブリックゲートウェイポートに移動するとき、この遷移はＬＲＨ／ＤＬＩＤベースの転送モードからＧＲＨ／ＩＳＲＮベースの転送モードへの変更を表わす。

【0197】

例示的な実施形態によれば、パケットがコアファブリックゲートウェイポートからシステムクロスバー経由でリーフサブネットゲートウェイポートに移動するとき、この遷移はＧＲＨ／ＩＳＲＮアドレス指定モードからＬＲＨ／ＤＬＩＤアドレス指定モードへの変更を表わす。

【0198】

例示的な実施形態によれば、パケットがリーフサブネットゲートウェイポートと別の（すなわち異なるリーフサブネットに接続される）リーフサブネットゲートウェイポートとの間で移動する場合、元のパケットＬＲＨ．ＤＬＩＤ値は、出力ポートを探索するために用いられるが、以下に示すようにＬＲＨが次のホップのためにどのように構築されるかについて２つの代替策が存在する。

【0199】

第１の代替策として、パケットにＧＲＨがなく、宛先ポートが「修正無ＬＩＤ転送」を許可する場合、パケットは同じＬＲＨ．ＤＬＩＤで転送される。したがって、この場合、新たなＬＲＨ．ＤＬＩＤの生成を伴わずに１つのリーフサブネットインスタンスから別のリーフサブネットインスタンスに交差するパケットトラフィックが、両方のリーフサブネットで一貫して処理されるＬＲＨ．ＤＬＩＤ値を表していることを保証することは、管理ソフトウェア次第であり、なぜならば、デフォルトでは、各リーフサブネットインスタンスはそれ自体のＬＩＤ値空間を表わすからである。

【0200】

第２の代替策として、パケットがＩＳＲＮベースの転送を表すＧＲＨを有する場合、出
力ポートとのＦＬＳＮ一致がある場合には、パケットは転送される。上記のコアファブリックゲートウェイポートの議論で指摘したのと同様に、ルーティングおよび転送テーブルの設定が正しく行われている限り、この場合でも一般的にＦＬＳＮマッチングを実行する必要はないことに注目されたい。

【0201】

さらに、一実施形態によれば、異なる転送ドメイン間でのパケットの転送がＦＬＳＮ割当てと競合していないことを実際に検証するために、ＦＬＳＮチェックの使用を選択的に有効にすることができる。この場合にも、ＦＬＳＮ値チェックを任意にすることは、ＶＭ移行に関して以下に述べるように、異なるリーフサブネット間でのＶＭマイグレーションをより柔軟に実現できることを意味する。

【0202】

さらなる代替策として、パケットがＩＳＲＮベースの転送を表さないＧＲＨを有するが、宛先ポートが「修正無ＬＩＤ転送」を許可する場合、パケットは同じＬＲＨ．ＤＬＩＤで転送される。したがって、この場合も、管理ソフトウェアが、新たなＬＲＨ．ＤＬＩＤの生成を伴わずに１つのリーフサブネットインスタンスから別のリーフサブネットインスタンスに交差するパケットトラフィックが、両方のリーフサブネットで一貫して処理されるＬＲＨ．ＤＬＩＤ値を表していることを保証し、なぜならば、デフォルトでは、各リーフサブネットインスタンスはそれ自体のＬＩＤ値空間を表わすからである。

【0203】

パケットがリーフサブネットゲートウェイポートから仮想ルータポートに移動するとき、次ステップ転送スキームは仮想ルータポートによって実現されるポリシーの機能である。出力ポートは一般に物理ルータポートではない可能性があり、なぜならば、これは、新たなＬＲＨが、パケットＧＲＨに基づく動的な態様で構築されることになることを意味し、そして、これは、仮想ルータポートを介して行われるからである。

【0204】

組み合わされたコアファブリックおよびリーフサブネット仮想スイッチ
例示的な実施形態によれば、組み合わされたコアファブリックおよびリーフサブネット仮想スイッチ構成は、同じセットのポートがコアファブリックおよびリーフサブネット仮想スイッチの両方の特性を同時に提供することを可能にする。この構成の１つの動機は、非ＧＲＨベースのデータおよび制御トラフィックが、コアファブリックにおける１つ以上のシステムインスタンスと直接接続されたノード間で生ずることを可能にすることである。コアファブリック内の転送オプションについては上で説明した。

【0205】

この実施形態の実現の観点からは、物理的なシステムポートが、このポートの役割に対して出力ポートとして使用できる他のポートの役割を定義する構成情報を有する限り、異なる仮想スイッチインスタンス間の物理ポートメンバーシップの部分的な重複を許可することとは対照的に、特定のポートのセットを、組み合わされたコアファブリックおよびリーフサブネット仮想スイッチとして定義する制約を実施する必要がある。

【0206】

組み合わされたコアファブリックおよびリーフサブネット仮想スイッチポート
例示的な実施形態による組み合わされたコアファブリックおよびリーフサブネット仮想スイッチポートは、ＧＲＨ／ＩＳＲＮ転送モードとＬＲＨ／ＤＬＩＤ転送モードとの両方をサポートする。

【0207】

ＧＲＨ／ＩＳＲＮベースの転送を実行するために、ＬＲＨ．ＤＬＩＤは、ＩＳＲＮベースの経路におけるすべてのポートについて共通の特定の事前定義された値である。したがって、このＬＩＤ値は、システムチップレベルの定数であってもよく、または好ましくは物理ポートレジスタごとに定義され得る。

【0208】

結合ポートは、論理線形転送テーブル（ＬＦＴ）容量に関して、構成可能な数のＤＬＩ
Ｄエントリと、別の構成可能なＩＳＲＮ値範囲とをサポートすることができる。

【0209】

一般に、値のセットが任意のポートでサポートすることができるように、同じ仮想スイッチにおけるすべてのポートが同じＤＬＩＤおよび／またはＩＳＲＮ ＬＦＴ容量を有することが好ましいことに注目されたい。しかしながら、これは単なる構成ポリシーであり、例示的な実施形態の実現の制約ではない。

【0210】

同様に、組み合わされた仮想スイッチインスタンスタイプおよび単一の仮想スイッチインスタンスタイプを含む各仮想スイッチインスタンスは、例示的な実施形態では、ポートごとの線形転送テーブル（ＬＦＴ）または論理的に共通のＬＦＴをすべての仮想スイッチポートに対して論理的に表すように選択的に定義される。しかしながら、これはファームウェアオプションであり、なぜならば、物理的なＬＦＴ実装は、例示的な実施形態では、ポートごとまたはデュアルポートのセットごとに分散されるからである。このファームウェアオプションの１つの理由は、明らかに、ＩＢ規格に準拠したＩＢスイッチモードをサポートするとともに、サブネットマネージャならびに分散されたＬＦＴをサポートしないルーティングエンジンおよび初期化エンジンを使用できることである。

【0211】

仮想ルータポート
仮想ルータポートは、例示的な実施形態では、物理ポートの範囲外のシステムポート番号によって表される。したがって、仮想ルータポートには直接関連付けられる物理リンクはない。どの仮想スイッチポートでも仮想ルータポートを探索でき、仮想ルータポートは次いで物理出力ポートおよび次ホップＬＲＨを定義するためにパケットＧＲＨ上で構成可能なルーティング機能を使用する。

【0212】

例示的な実施形態におけるルーティング機能は、同じローカルファブリックにおけるエンドポイント間の階層的転送と、独立したローカルファブリックインスタンス間のジェネリックな転送との両方を含むことに注目されたい。

【0213】

ＧＲＨのないパケットが仮想ルータポートに送信される場合、好ましくは、パケットはドロップされるか、または新たなＬＲＨおよび物理的な出力ポートが構成可能な機能に基づいて生成される。

【0214】

各仮想スイッチポートは、パケットからのＤＬＩＤまたはＩＳＲＮ値がポートによってサポートされるＬＦＴ範囲外であるためにＬＦＴベースの探索が不可能な場合に中間出力ポートとして使用される関連付けられるデフォルト仮想ルータポートを有する。この場合、仮想ルータポートは、選択的に、パケットをＩＢ規格に従ってデフォルトとしてドロップするか、または物理出力ポートおよび次ホップＬＲＨを定義するためにパケットヘッダ上で構成可能な機能を実行するように動作可能である。

【0215】

物理ルータポート
物理ルータポートは、例示的な実施形態では、ローカルファブリックインスタンスへの進入またはローカルファブリックインスタンスから外に出ることを処理するポートである。物理ルータポートは、リンク側からＩＢ規格に準拠したルータポートとして表される。

【0216】

例示的な実施形態では、物理ルータポートは、リンク側から到着するパケットに使用される仮想ルータポートと同じパケット転送ロジックに関連付けられる。

【0217】

例示的な実施形態では、物理ルータポートは、パケットのパケットＧＲＨ上で選択された機能を実行し、次いで、物理ルータポートのリンク上で出るよう意図される新たなＬＲＨを生成した仮想ルータポートまたは別の物理ルータポートによって探索されるかまたは
他の態様で参照される。

【0218】

単純なＬＲＨ．ＤＬＩＤ挿入は、最小限のゲートウェイサブネットにおけるリモートルータポートに関連付けられるリモートＤＬＩＤ値に基づいて与えられる。

【0219】

サブネット間ルート番号（ＩＳＲＮ）
例示的な実施形態によれば、サブネット間ルート番号（ＩＳＲＮ）は、コアファブリックインスタンス内においてＬＦＴエントリを索引付けするために使用されるパケットＧＲＨ．ＤＧＩＤ．サブネットプレフィックスの可変部分によって定義される値である。ＩＳＲＮ値空間はコアファブリックインスタンスごとであり、ファブリックグローバルマネージャ（ＦＧＭ）はＩＳＲＮ値の使用を調整する。

【0220】

例示的な実施形態では、ＩＳＲＮ値を使用して転送されるべきパケットは、ＩＳＤＮ値がＬＦＴベースの転送に使用されるべきであることを受信側ポートに示す特殊な予約済みＬＲＨ．ＤＬＩＤ値を有する。

【0221】

一実施形態では、システムポートが「複数のパーソナリティ」を有する能力は、パケットが、使用するべき特定のタイプの転送メカニズムに関する情報を、ポートごとの構成情報としてこれ（のみ）を有することとは対照的に、含むべきであることを意味する。

【0222】

ファブリックローカルサブネット番号（ＦＬＳＮ）
例示的な実施形態によれば、ファブリックローカルサブネット番号（ＦＬＳＮ）は、ローカルファブリック内で宛先サブネットを識別する値である。すべてのＦＬＳＮ番号は、ファブリックグローバルマネージャ（ＦＧＭ）によって割り当てられ、管理されることが好ましい。ＩＳＲＮ値に基づいて転送されるパケットは、宛先ＦＬＳＮ値も有する。

【0223】

ＦＬＳＮ値は、論理ポートの役割を担うリーフサブネットゲートウェイポートに関連付けられ、そのようなポートに転送されるパケットは、宛先サブネットに到達したことを判断するために、パケットＦＬＳＮ番号がポートＦＬＳＮ番号と照合されることになる。

【0224】

一実施形態では、システムポートが「複数のパーソナリティ」を有する能力は、ポートごとの構成情報に単に依存することとは対照的に、パケットおよびポート情報の両方の組み合わせに基づいてパケットがそれらの宛先サブネットに到達したものとして認められることを意味する。

【0225】

ファブリックグローバルマネージャ（ＦＧＭ）
例示的な実施形態によれば、ファブリックグローバルマネージャ（ＦＧＭ）は、完全なローカルファブリックインスタンスの発見および構成を実行することができる「スーパーサブネットマネージャ」である。ＦＧＭは、個々のリーフサブネットにおける「ＦＧＭ認識」サブネットマネージャと協働する。

【0226】

各リーフサブネットサブネットマネージャは、ＦＧＭとは独立してそれ自体のローカルリーフサブネットを管理することができるが、ローカルファブリックにおける任意のコアファブリックまたは他のリーフサブネットを含む任意のサブネット間トラフィックを容易にするために、ＦＧＭに依存することになることに注目されたい。

【0227】

識別サブネット番号（ＩＳＮ）
例示的な実施形態によれば、識別サブネット番号（ＩＳＮ）は、グローバルまたはサイトに特定の一意性を有してもよい、管理上割り当てられたサブネット番号である。ＩＳＮ番号は、異なるローカルファブリックインスタンス間においてサブネット間トラフィック
に選択的に使用されるＧＩＤ値を形成するために、ＧＵＩＤとともに使用される。

【0228】

ハードウェアＧＵＩＤ（ＨＷ ＧＵＩＤ）
例示的な実施形態によれば、ハードウェアＧＵＩＤは、ハードウェアリソースの６４ビットのグローバルに一意の識別情報である。例示的な実施形態における各物理システムインスタンスは、ベースＨＷ ＧＵＩＤ値を有する。各システムベースの仮想スイッチインスタンスは、予め定義された方法でベースＨＷ ＧＵＩＤから導出されるＨＷ ＧＵＩＤを有する。各物理ＨＣＡは、ベースＨＷ ＧＵＩＤを有することになる。各仮想ＨＣＡポートは、予め定義された方法でベースＨＷ ＧＵＩＤから導出されるＨＷ ＧＵＩＤを有することになる。

【0229】

仮想ＧＵＩＤ（ｖＧＵＩＤ）
例示的な実施形態によれば、仮想ＧＵＩＤ（ｖＧＵＩＤ）は、グローバルに一意またはローカルファブリック内で一意である６４ビットのＧＵＩＤ値である。仮想ＧＵＩＤは、ローカルファブリックに存在する任意のＨＷ ＧＵＩＤに対して一意であることも保証される。

【0230】

仮想ＧＵＩＤは、典型的には仮想マシンインスタンスに関連付けられ、同じｖＧＵＩＤ値（ＶＭが使用している各ｖＨＣＡポートに対して１つ）は、通常、物理サーバとｖＨＣＡインスタンスとの間において複数のマイグレーション含んでもよいＶＭライフサイクル全体にわたるＶＭに関連付けられることになる。

【0231】

特定のｖＨＣＡインスタンスはそれのＨＷ ＧＵＩＤによって識別されるが、ＶＭがそれを使用しているときはいつでも、ｖＨＣＡポートは関連するＶＭ ｖＧＵＩＤ値を使用してアドレス指定することもできることに注目されたい。

【0232】

パケットヘッダフォーマットおよび規約：
パケットローカルおよびグローバルルートヘッダ（ＬＲＨ／ＧＲＨ）フォーマットおよび規約のための基準について以下に説明する。第１に、本明細書の例示的な実施形態で使用されるローカルルートヘッダ（ＬＲＨ）は、インフィニバンド（ＩＢ）規格によって定義される通りである。同様に、本明細書の例示的な実施形態で使用されるグローバルルートヘッダ（ＧＲＨ）は、インフィニバンド（ＩＢ）規格によって定義される通りであるが、２つの追加／例外のセットを有する：１）GRH.DGID.SUBNET_PREFIXはタイプ「ＩＳＲＮ」を有することができ、２）GRH.DGID.SUBNET_PREFIXはタイプ「LeafSwitchHierarchy（
リーフスイッチ階層）」を有することができる。

【0233】

GRH.DGID.SUBNET_PREFIXがタイプ「ＩＳＲＮ」である場合、GRH.DGID.SUBNET_PREFIXは、例示的な実施形態では、以下のフォーマットを有する（ＩＳＲＮタイプに加えて：
（宛先）ファブリックローカルサブネット番号
サブネット間ルート番号（すなわち、ソースリーフサブネットにおいて最初のＬＲＨ．ＤＬＩＤ値によって定義されるコアファブリックインスタンスにおける）
ＤＬＩＤ（ファブリックローカルサブネット番号で定義される宛先リーフサブネットにおける）。

【0234】

GRH.DGID.SUBNET_PREFIXがタイプ「LeafSwitchHierarchy」である場合、GRH.DGID.SUBNET_PREFIXは、例示的な実施形態では、以下のフォーマットを有する（LeafSwitchHierarchyタイプに加えて：
（宛先）ファブリックローカルサブネット番号
（宛先）リーフスイッチ番号
すべての特殊なサブフィールドは、ランタイムで定義されるサイズおよびオフセットを
有する。（すなわち、サブフィールド抽出を実行するために専用ＴＣＡＭエントリを使用することによって可能にされる）。

【0235】

ローカルファブリック全体にわたるＳＬ値およびＶＬ値のマッピングならびに選択：
本明細書の例示的な実施形態によれば、単一のリーフサブネット内において、ＬＲＨのみを有し、ＧＲＨを有さないパケットは、レガシーのＳＬからＶＬへのマッピングを使用していることになる。例示的な実施形態は、予約ビットおよび新たなヘッダバージョン番号を使用することによって、ローカルＬＩＤおよび／またはＳＬ／ＶＬ値空間を所望または必要に応じて選択的に拡張してもよい。ＬＦＴによって探索可能なポート番号の数を拡張することは、より多くのそのような「エイリアス」ポート番号が、関連付けられる物理ポートについて他のＳＬ／ＶＬマッピングを表すことを可能にする。（すなわち、ＳＬ／ＶＬ処理と同じ効果であるが、予約されたＬＲＨビットの所有権を主張できる使用に頼るのではなく、ＬＦＴメモリを消費する。）これは、トラフィック分離を達成するために異なるＳＬ値ではなく複数のＤＬＩＤ値を使用することを意味する。

【0236】

ＬＲＨおよびＧＲＨ無しの両方を伴う単一のリーフサブネットパケット内での値のマッピングならびに選択は、例示的な実施形態では、デフォルトで、レガシーのＳＬからＶＬへのマッピングを使用することになる。ＧＲＨフィールドは、好ましくは、コアファブリックにおけるのと同じ態様で使用される。

【0237】

リーフサブネット間およびコアファブリック内における値のマッピングならびに選択では、ＬＲＨのみを有するパケットは、好ましくは、単一のリーフサブネットにおけるように処理される。

【0238】

リーフサブネット間およびコアファブリック内における値のマッピングならびに選択では、ＬＲＨおよびＧＲＨの両方を有するパケットは、以下のスキームに基づいてＳＬ選択を有することになる：各トラフィッククラス値は、可能なＳＬ値のセットを表す；フローラベル値のハッシュは、トラフィッククラスによって定義された利用可能なＳＬ値の中から選択し、以下の「ゲートウェイサブネットを介したＳＬ値およびＶＬ値のマッピングならびに選択」で定義されているように、「積極的な」クレジット待機ポリシーに対してサポートが与えられる。

【0239】

ゲートウェイサブネットを介したＳＬ値およびＶＬ値のマッピングならびに選択：
デフォルトでは、ローカルファブリック内で使用するために定義されたものと同じＧＲＨベースのスキームが、例示的な実施形態によってサポートされる。基本的なマッピングに加えて、たとえば、リモートファブリックにおいてゲートウェイサブネット／ルータポートにパケットを送信するルータポートなどの出口ルータポートは、すべてのそのようなパケットまたはサブセットを、定義された基準に基づいて、ローカルファブリックに輻輳ツリーが蓄積されないようにパケットを「早期に」ドロップする、より「積極的な」クレジット待機ポリシーを有するとして分類してもよい。

【0240】

ローカルファブリック全体にわたるＰ＿Ｋｅｙ値のマッピングおよび選択：
例示的な実施形態における各転送ドメインは、ローカルファブリックレベルでの調整なしにリーフサブネットの内部のトラフィックに使用できるＰ＿Ｋｅｙ値の範囲を有する。つまり、すべての転送ドメインによって、同じプライベート範囲を使用できる。ローカル範囲外のＰ＿Ｋｅｙ値は、ＦＧＭを介して割当てられる。ＦＧＭは、ゲートウェイポートが、関連する転送ドメインに転送されることを許されるＰ＿Ｋｅｙ値を持つパケットの転送のみを受け入れることを保証する。

【0241】

さらなる例では、ＦＧＭは、異なる転送ドメイン間のような特定のゲートウェイポート
でのＰ＿Ｋｅｙ値のマッピングを含む特殊な経路を定義することができる。一般に、そのようなマッピングは、パケット不変ＣＲＣ（ＩＣＲＣ）が再計算されることを意味する。ＨＣＡなどのエンドノードからのサポートを含む代替スキームとして、あるスキームが提供され、通常のパケットＩＣＲＣは、０のパケットＰ＿Ｋｅｙ値に基づいて計算されるが、加えて、ＧＲＨにおいて、ＩＣＲＣに含まれない予約ビットフィールドを有し、しかし、それは、現在のＰ＿Ｋｅｙ値に対するＣＲＣパリティ値を含む。

【0242】

ゲートウェイサブネットを介するＰ＿Ｋｅｙ値のマッピングおよび選択：
本明細書で説明される例示的な実施形態は、一般に、異なるローカルファブリックインスタンス間の調整されたＰ＿Ｋｅｙ値割り当てについての仮定をなさない。ネイティブＩＢ通信は、この場合、関与するローカルファブリックインスタンス間の動的に交渉されるＰ＿Ｋｅｙ値に基づくか、または上記のローカルファブリックの場合について概説されたＰ＿Ｋｅｙマッピングスキームに基づく。

【0243】

ローカルファブリック全体にわたるマルチキャストパケットの転送：
例示的な実施形態では、各転送ドメインは、各転送ドメインに対してプライベートであるとみなされるＭＬＩＤ値の範囲を有し、すべての転送ドメインが同じプライベート範囲を使用することができる。プライベートＭＬＩＤにマッピングされるマルチキャストグループは、ローカル転送ドメイン内でのみ転送できる。ＦＧＭは、プライベートＭＬＩＤ転送が転送ドメイン境界を超えて行われないようにし、完全なローカルファブリックインスタンス全体にわたるマルチキャスト転送を実現するために使用できる共有ＭＬＩＤ値のセットを調整する。完全なローカルファブリック全体にわたって共有ＭＬＩＤ値を介して使用されるＭＧＩＤ値は、ＦＧＭによって割当てられる。そのようなＭＧＩＤ値は、それをＦＧＭ制御されるＭＧＩＤであるよう定義する選択されたビットフィールドを有する。各転送ドメイン内におけるローカルＳＭは、ＦＧＭ制御されるＭＧＩＤの競合する使用がないことを保証することを担う。

【0244】

さらなる例では、仮想ルータポートが使用される。この例では、１つの転送ドメインにおいて特定のＭＧＩＤおよびＭＬＩＤ値を有するマルチキャストパケットは、別の転送ドメインにおいては、同じＭＧＩＤ値で転送できるが、異なるＭＬＩＤ値を有する。

【0245】

ゲートウェイサブネットを介したマルチキャストパケットの転送：
本明細書で説明される例示的な実施形態は、一般に、異なるローカルファブリックインスタンス間の調整されたＭＧＩＤ値割り当てについての仮定をなさない。純粋なハードウェアベースの転送を伴うネイティブＩＢマルチキャスト通信は、この場合、関与するローカルファブリックインスタンス間の動的に交渉されるＭＧＩＤ値に基づく。

【0246】

例示的な実施形態では、デフォルトでは、異なるローカルファブリックインスタンス間のマルチキャスト転送は、ソフトウェアベースのプロキシサービスを構成することに基づき、ソフトウェアベースのプロキシサービスは、１つ以上の物理ルータポートに関連して動作し、ローカルファブリックまたは物理ルータポートからマルチキャストパケットを受信し、ペイロードを新たなマルチキャストパケットにおいて反対方向に転送する。プロキシは、好ましくは、デフォルトでは、ローカルファブリック側において通常のマルチキャストグループメンバーであり、たとえばゲートウェイサブネットを介するなどしてリモートファブリックから到着するすべてのマルチキャストパケットを傍受するために、物理ルータポートとの特殊な関係を有する。

【0247】

上記に加えて、リモートファブリックからのマルチキャストパケットがローカルファブリックにおけるマルチキャスト転送を妨げない態様でプロキシに転送されることを確実にするよう、あるメカニズムが選択的に提供される。これは、ローカルファブリックにおい
て専用ＭＬＩＤを使用する「デフォルトＭＣ宛先」のスキームまたは概念を使用し得る。これは、受信機が任意の数のＭＧＩＤを受信し、プロキシインスタンスに関連付けられるＱＰに転送できる限り、実行可能である。これは、多数のパーティションも含んでもよい。この機能性が関連するＨＣＡに対して保証することが困難である場合、本明細書の別の実施形態は、ＥｎｅｔパケットがＥｎｅｔＧＷポートで受信されたときにトンネリングされる方法と同様の方法で、システムがＩＢ ＭＣパケットをＩＢユニキャストパケットでトンネリングするように機能することである。したがって、プロキシ実装は、着信リモートＭＣパケットを、ローカルファブリック上でどのようにトンネリングするかとは無関係に、解釈して処理することができる。

【0248】

任意の数のパーティションを処理するために、ローカルファブリックからリモートファブリックへの方向に１つより多いＳＷプロキシが必要とされてもよいことに注目されたい。さらに、物理ルータポートについては、双方向のトンネリングが実現されることに注目されたい。また、プロキシ実装が両方のファブリックに存在する場合、専用のハードウェアサポートを必要とせずにプロキシ実装を協働させることによって、トンネリングが実現される。これに関連して、トンネリングスキームは、元のＩＢヘッダをトンネリングパケットにＩＢペイロードとして含めなければならないため、最大ＩＢ ＭＴＵをトンネリングされるＭＣパケットとして転送することができないことを意味する。プロキシは、好ましくは、同じＭＧＩＤ値が異なるローカルファブリックにおける２つの異なる論理マルチキャストグループに対して使用される場合を処理することができる。

【0249】

ローカルファブリックの初期発見および構成：
例示的な実施形態によれば、デフォルトでは、各システムインスタンスは、単一の従来のインフィニバンド（ＩＢ）スイッチとして動作する。このデフォルト構成では、既存のＩＢ サブネットマネージャまたはＳＭＰベースの診断および監視ツールは、完全な接続されたファブリックを単一のＩＢサブネットとして「見る」かまたは他の態様で学習することができる。

【0250】

システムインスタンスを複数の仮想スイッチに分割し、ポートタイプおよび関連付けられる構成情報を定義することは、例えば、通常のＳＭＡ動作の一部ではない「バンド外」構成ポリシーを表す。しかしながら、すべてまたはほとんどのバンド外構成操作は、「純粋な」バンド外構成の代替として、ベンダー固有のＳＭＰ操作を介して実装できる。例示的な実施形態では、各システムインスタンスは、任意のＩＢリンク状態から独立して利用可能であるＥネットベースの管理インターフェイスを有し、ＩＰｏｌＢ／ＥｏｌＢをサポートしもするので、「バンド外」構成は原則的に任意のインターフェイスを介したＩＰベースのアクセスを表すことに注目されたい。

【0251】

さらに、ローカル管理プロセッサに元来関連付けられるＰＣＩ－Ｅのような純粋な「ローカル」管理インターフェイスの概念はないことに注目されたい。それでも、セキュリティに対する「鶏と卵」構成問題を解決するために、Ｅｎｅｔインターフェイスは、例示の実施形態のシステムの一部である、例えば特定の独立した物理スイッチシャーシのような物理システムは、好ましくは、ポートベースのＶＬＡＮまたは他のアクセス制御規則を介してＥｎｅｔアクセスを確保している、という仮定を伴う構成ポリシーの最初のソースを表わしてもよい。この知識は、好ましくは、「先験的」に定義された生産時間であり、システムインスタンスについての永続的な構成情報である。

【0252】

シャーシ内部管理プロセッサを表すＨＣＡポートが存在し、ハードウェア設計によって定義されるような特定のシステムインスタンス上の特定のポートに接続される構成では、例示的な実施形態によるシステムインスタンスも、この接続性を有するローカルシステムポートに関する先験的情報を有するべきである。

【0253】

最初にＥｎｅｔインターフェイスまたは管理ホストチャネルアダプタ（ＨＣＡ）を介して供給される構成情報に基づいて、例示的な実施形態のシステムのファームウェアは、他のインターフェイスおよび／または管理Ｅｎｅｔインターフェイス上の他のソースからの構成操作も同様に認証することができる。このような構成情報は、例示的な実施形態のファームウェアによって確実かつ永続的に記憶される。

【0254】

さらなる例示的な実施形態によるファームウェアは、さらに、ファームウェアが初期展開時に他のインターフェイス／ソースからのアクセスを認証することを可能にする追加の「先験的な」永続的構成情報にアクセスを有してもよい。これには、ベンダー固有の管理ソフトウェアなどのための公開鍵を含めることができる。加えて、タイプ、およびおそらくはこのベンダーインスタンスのハードウェアＧＵＩＤに関連するような特定のアイデンティティも認証するために使用される秘密鍵が必要または所望され得るように存在する可能性がある。

【0255】

例示的な実施形態によれば、ポート役割および仮想スイッチが構成されているとき、例えばサブネットマネージャ（ＳＭ）およびＦＧＭインスタンスなどのバンド内管理コンポーネントは、レガシーＳＭＰベースのサブネット発見方法および１つ以上のベンダー固有のＳＭＰ方法の両方を使用して、ローカルの物理および／または仮想ファブリックのそれらの関連部分を発見することができる。

【0256】

例示的な実施形態によれば、各リーフサブネットは、好ましくは、独立したＳＭインスタンスによって他のリーフサブネットと並行して発見され構成される。

【0257】

コアファブリックにおいては、１つ以上の「マスタ」ＦＧＭインスタンスは、一般に、コアファブリックインスタンスごとに１つのマスタＦＧＭインスタンスと同時に動作してもよい。

【0258】

さらに、リーフサブネットにおけるサブネットマネージャは、それらのリーフサブネットの外部に、それらの転送ドメイン外であるＳＭＰアクセス（読出しまたは書込み）を有さないことが好ましい。リーフサブネットにおけるレガシーサブネットマネージャは、リーフサブネット内における普通の（仮想）スイッチポートおよびそれらのローカル接続性を検出できるのみであることになる。リーフサブネットにおけるファブリック認識サブネットマネージャは、好ましくは、ゲートウェイポートおよびそれらが表す接続性を発見することはできるが、ゲートウェイポートの構成を変更することはできない。リーフサブネットにおけるファブリック認識サブネットマネージャは、デフォルトでは、好ましくは、ゲートウェイポートを越えたリモートポート接続性やそれ以上のホップを発見できず、ゲートウェイポートを越えて構成情報を修正することもできない。

【0259】

例示的な実施形態では、ＦＧＭインスタンスは、デフォルトで、完全なローカルファブリックを発見することができることになる。ＦＧＭインスタンスは、例えば、特定のコアファブリックインスタンスの外部または完全なコアファブリックの外部などローカル転送ドメインの外部でのトポロジのホップ毎ＤＲ ＳＭＰベースの発見の実行を、たとえばＦＧＭインスタンスに対する構成オプションによって回避するか、または、そのような発見の実行を、リモート仮想システムにおけるアクセス制限によって、妨げられてもよい。アクセス制限は、典型的には、異なるファブリックレベルの所有者を持つ異なるリーフサブネットに適用される。この場合、中央ＦＧＭは、各コアファブリックインスタンスからのトポロジ情報および各リーフサブネットからのトポロジ情報を関連するサブネットマネージャまたはＦＧＭインスタンスを介して収集し、この情報を使用して完全なローカルファブリックの最適化されたルーティングを評価する。

【0260】

デフォルトでは、ローカルファブリック内における完全なエンド・ツー・エンド接続性は、各リーフサブネットにおけるすべてのエンドポート間、各リーフサブネットにおけるすべてのエンドポートとすべてのゲートウェイポートとの間、ならびに各コアファブリックインスタンスにおける各ゲートウェイポート間、および特にリーフサブネットゲートウェイポートの任意の対の間に完全な接続性が確立されている各転送ドメインのローカルルーティングの後に存在することに注目されたい。

【0261】

上記の完全な接続性に基づいて、中央ＦＧＭは、ソースリーフサブネットにおける経路と、もしあれば関連するコアファブリックインスタンスにおける経路と、宛先リーフサブネットにおける関連の経路とを組み合わせることに基づいて、ローカルファブリックにおけるすべての潜在的な「ピアの対」に対するエンド・ツー・エンド経路を選択することができる。中央ＦＧＭは、異なるリーフサブネット間のエンド・ツー・エンド経路がクレジットループを表さないことを保証する必要があるだろう。しかしながら、次の条件が満たされている限り、クレジットループ回避はトリビアルに保証される：各リーフサブネットは、ファットツリーを表し、そこでは、コアファブリックインスタンスおよび／または他のリーフサブネットへのゲートウェイポートはローカルリーフサブネットにおけるルートスイッチノードを表し、各コアファブリックインスタンスは、すべてのリーフサブネットゲートウェイポートを、通常のファットツリー内におけるリーフノード／ポートとして、ルーティングされる。

【0262】

例示的な実施形態によれば、完全なローカルファブリック内において専用または「主要な」ダウン経路を介して静的最適化を保証するために、中央ＦＧＭは、ターゲットリーフサブネットにおける宛先ノードのための専用または「主要な」ダウン経路を表すルートスイッチにおける出口ゲートウェイポートを使用することになるターゲットリーフサブネットのための経路を選択する。ルートスイッチに関する情報は、一般に、リーフサブネット内におけるマスタサブネットマネージャ（ＳＭ）から入手可能になる。リーフサブネットにおけるマスタサブネットマネージャ（ＳＭ）は、リーフサブネットのローカルルーティングの一部として宛先ノードについて本実施形態のシステムの仮想スイッチまたは完全な物理的インスタンスであってもよいルートスイッチを選択している。

【0263】

ゲートウェイポートの選択は、本来、現在ソースリーフサブネットからの接続性を有し、この時点でのリーフサブネット間トラフィックの「合理的な」均衡を表すコアファブリックインスタンスの選択も表す。

【0264】

次いで、中央ＦＧＭは、ソースリーフサブネットから選択されたコアファブリックインスタンスへの入口ゲートウェイポートと、選択されたコアファブリックインスタンスにおける選択された宛先出口ゲートウェイポートのための主要経路を表すＩＳＲＮ値とを選択する。

【0265】

コアファブリックインスタンスへの入口ゲートウェイポートの選択も、この時点におけるリーフサブネット間トラフィックの「合理的な」均衡を表す。

【0266】

例示的な実施形態によれば、ソースリーフサブネットにおけるソースポートから選択されたコアファブリックインスタンスへの選択された入口ゲートウェイポートへの経路は、ソースリーフサブネットにおけるマスタサブネットマネージャ（ＳＭ）によって定義される。この経路は、好ましくは、リーフサブネット間トラフィックについての潜在的な使用についての知識なしに、マスタサブネットマネージャ（ＳＭ）によって構築される。中央ＦＧＭは、ソースおよびターゲットリーフサブネットの両方におけるマスタサブネットマネージャからの情報を、選択されたコアファブリックインスタンスについての選択された
ＩＳＲＮ値と組合わせることに基づいて、完全な経路を構築できる。

【0267】

中央ＦＧＭは、ＬＩＤ値およびＩＳＲＮ値によって定義される純粋な経路情報に加えて、関与する各マスタサブネットマネージャからＳＬ値も取得し、さらにトラフィッククラスおよびフローラベルも選択し、コアファブリック内においてＳＬ／ＶＬ選択を反映し、ターゲットリーフサブネットが入るとＳＬ選択を反映する。

【0268】

最も単純なデフォルトの場合、単一のＳＬ値が選択され得、それは、完全なローカルファブリック全体を通じて、例えばレガシーの単一サブネットファットツリートポロジーに対してと同様のようにすべての転送ドメインにおいて固定されたＶＬへの一貫したマッピングによって、保存されることになることに注目されたい。

【0269】

ＤＬＩＤが最終的な宛先を表し、ファブリック内におけるさまざまなリンクおよび／またはスイッチ障害の結果としてファブリックを介して異なる経路を使用するよう、同じＤＬＩＤを再ルーティングできる、従来の単一のサブネットファブリックとは異なり、ファブリック内におけるＤＬＩＤ－ＩＳＲＮ－ＤＬＩＤベースのエンド・ツー・エンド経路は、ソースサブネットからコアファブリックへの入口ゲートウェイポートについてのＤＬＩＤ、およびコアファブリックインスタンスから宛先リーフサブネットへの出口ゲートウェイポートを表すＩＳＲＮ値の、調整された再ルーティングがない限り、障害の結果として更新する必要があるかもしれないことに注目されたい。したがって、例示的な実施形態では、ゲートウェイポートがもはや利用可能でない場合、同等の順方向接続性を提供できる代替ゲートウェイポートを表すよう、関連するＤＬＩＤ値またはＩＳＲＮ値の再ルーティングが行われるか、または影響を受けたフロー／通信ピアについての経路情報の更新が行われる。

【0270】

また、例示的な実施形態では、全体的なリーフサブネット間経路の再平衡化を実行するために、中央ＦＧＭは、１つ以上のフローのための新たな経路情報を選択的に生成し、関与するピアに通知するか、または関連するすべてのマスタサブネットマネージャおよびＦＧＭインスタンスを含む現在のＤＬＩＤ－ＩＳＲＮ－ＤＬＩＤベースの経路のエンド・ツー・エンド再ルーティングを調整する。

【0271】

物理ノードおよび仮想ノードポピュレーションのグローバルなオーバービューの維持：
例示的な実施形態によれば、各リーフサブネットにおける物理エンドノードおよび仮想エンドノードは、ローカルマスタサブネットマネージャ（ＳＭ）によって発見され、構成される。各マスタサブネットマネージャは、照会およびイベントによって、中央ＦＧＭに、それのローカルノードポピュレーションに関して通知する。物理および仮想管理サーバならびにスイッチ管理ポートを含む通信エンドノードを伴うコアファブリックの場合、関連するＦＧＭインスタンスは、リーフサブネットにおけるマスタＳＭと同じ態様で、ポピュレーションに関する情報を追跡または他の態様で維持する。これにより、中央ＦＧＭは、ＧＵＩＤに基づいて任意のエンドノードの所在を追跡することができ、したがって任意の必要な通信に関する関連する経路情報を構築することができる。

【0272】

一般に、単一のリーフサブネット内でのＶＭマイグレーションはリーフサブネット内でローカルに処理されるが、ルーティングまたは経路情報の変更は中央ＦＧＭインスタンスに伝達される。リーフサブネット境界を越えるＶＭマイグレーションは、一般に、中央ＦＧＭを介して調整される。

【0273】

中央ＦＧＭは、一般に、ｖＧＵＩＤの調整を担い、Ｐ＿Ｋｅｙ値は、さまざまなリーフサブネットおよびコアファブリックインスタンスの境界にわたる範囲を有することに注目されたい。したがって、現在のグローバルポリシーと同期していない転送ドメイン内にお
ける値の割当ては、関連する転送ドメイン外で可視になるよう許されもしなければ、他の転送ドメインに悪影響を与えもしないことになることに注目されたい。

【0274】

仮想マシン（ＶＭ）マイグレーション：
例示的な実施形態によれば、単一リーフサブネット内での仮想マシン（ＶＭ）マイグレーションは、一意のＤＬＩＤ値を用いて、ＶＭが表わしている仮想ＨＣＡポートを示す限り、アドレス情報の変更なしに生じ得る。

【0275】

ＶＭがリーフサブネットからマイグレーションされるたびに、一般に、アドレス指定情報は、ＶＭに到達するのにＬＲＨのみ（すなわち、ＧＲＨなし）に基づくアドレス指定を使用していた元のリーフサブネットにおけるすべてのピアについて更新され、なぜなら、ＧＲＨの使用がここで必要となるからである。同様に、ＶＭがリーフサブネットからマイグレーションされるたびに、アドレス指定情報は、現在ＧＲＨ／ＩＳＲＮベースのアドレス指定を使用している他の転送ドメインにおけるすべてのピアについて、更新される。これがあてはまるのは、元のサブネットで使用されるＶＭのＬＩＤ値を保持することが、最初のコアファブリックゲートウェイポートについてのＤＬＩＤおよび後のリーフサブネットゲートウェイポートについてのＩＳＲＮ値の両方の再ルーティングを実行することに加えて、可能でない限りにおいてである。

【0276】

さらなる例示的な実施形態によれば、ＶＭがマイグレーションされる新たなリーフサブネットを直接接続する、システムインスタンスにおける仮想ルータポートを介したＴＣＡＭベースの転送およびＬＲＨ生成を使用して、最初のコアファブリックゲートウェイポートについてのＬＩＤおよび後のリーフサブネットゲートウェイポートについてのＩＳＲＮ値が、関連する仮想ルータポートへの転送を提供するために再ルーティングされた、中間状態を有することが可能であり、仮想ルータポートは新たなＤＬＩＤを伴う最終的なＬＲＨの生成を行うことができる可能性があり、マイグレーションに続いて完全な古いアドレス指定情報が有効になるであろう。

【0277】

上記のスキームは、関連するすべてのピアについてのアドレス情報を更新するための「遅延」スキームと必要または所望に応じて組み合わせることができ、古い（元の）アドレス情報および新たなアドレス情報の両方がそのときＶＭに対して同時に有効となり得る。例えば、中央ＦＧＭによって、いずれのピアももはや古いアドレス情報に依存しないことが確認された場合、古いアドレス情報は「リサイクル」できる。

【0278】

このスキームは、少なくとも元のＩＳＲＮ値が、専らＶＭに対して（すなわち、リーフサブネットゲートウェイポートに対してそのようなものとしてではなく）割当てられ、それを、中間コアファブリック経路について同じＩＳＲＮを使用して他の宛先について競合を引き起こすことなく再ルーティングできるようにすることを前提とする。

【0279】

マイグレーション後にＶＭに到達するよう新たなコアファブリックインスタンスを使用しなければならないことを必要とする態様でＶＭマイグレーションが生じた場合、すべての通信リーフサブネットにおいてコアファブリックゲートウェイポートをアドレス指定するために使用されるＤＬＩＤ値について同じ制約が存在する。

【0280】

特別なケースとして、元のリーフサブネット内における通信ピアがある。－これらのピアが最初にＧＲＨ／ＩＳＲＮベースのアドレス指定を使用するように指示されている限り、元のＤＬＩＤ値およびＩＳＲＮ値の再ルーティングに基づいてＶＭマイグレーションを透過的に処理することができる（つまり、まず、元のＬＲＨ．ＤＬＩＤはＶＭを直接指していることになるが、マイグレーション後、これは、関連するコアファブリックゲートウェイポートを指すように更新されていることになる。

【0281】

リーフサブネットインスタンスからマイグレーションされているＶＭの観点からは、一般に、すべてのそれの通信ピアについてのアドレス情報を更新しなければならず、なぜならば、特に、最初のホップアドレス指定は、異なるリーフサブネットでは同じではないからである。これは、上のセクションで概説した通信ピアについてのアドレス透過性を実現するためのすべての拡張機能とは無関係である。

【0282】

上記のすべての場合において、前提は、ＦＬＳＮチェックがイネーブルにされていないこと、または同じＦＬＳＮ値を有するリーフサブネットインスタンス間でのみマイグレーションが行われること、またはシステム実装によっていくつかのＦＬＳＮ値が上述したように各ポートに関連付けられ、競合するＦＬＳＮ値を有する少数のマイグレーションを、任意の時点で、つまりすべてのピアが上述のようにアドレス情報を更新してしまうまで、処理することができること、であることに注目されたい。

【0283】

リーフサブネット／コアファブリックモデルに対するハードウェアサポート：
単一のリーフサブネット内では、例示的な実施形態のシステムは、インフィニバンド（ＩＢ）規格に従って線形転送テーブル（ＬＦＴ）を使用してＬＲＨ．ＤＬＩＤベースのパケット転送を実現する。デフォルトでは、各仮想スイッチは、完全な４８ＫのユニキャストＤＬＩＤ空間をサポートするＬＦＴと、完全な１６ＫのマルチキャストＤＬＩＤ空間をサポートするマルチキャスト転送テーブルとを有する。システムに対するＰＯＲが、物理ポートの対によって共有されるプライベートユニキャストおよびマルチキャストＬＦＴを有することになる限り、仮想スイッチポートメンバーシップを構成する最小限の細分性は、ＬＦＴを共有する２つのポートのグループである。次に、拡張されたＳＭおよびＦＧＭルーティングロジックで、仮想スイッチごとの複数の独立したＬＦＴをサポートしてもよい。しかしながら、ＬＦＴが１つより多い物理ポートによって共有されている限り、依存性は、実際の物理トポロジがそれ自体を複数の独立したＬＦＴの処理に供することである。

【0284】

物理ポート間でのＬＦＴの共有は、仮想スイッチごとに１つより多いＬＦＴを利用することが有益となるために、ケーブルコネクタ当たりのポートのグループ化（４ｘより大きい場合）および大きなローカルファブリックのケーブル接続された物理的接続性がどのように見えるべきかに対して影響を有することに注目されたい。また、さまざまな所有権を主張できる技術またはプレ標準技術を使用して、本システムの実施形態は、潜在的に、ＬＲＨ．ＤＬＩＤユニキャスト空間を４８Ｋを超えて拡張する可能性がある。

【0285】

例えば、異なるリーフサブネット間および／またはコアファブリックインスタンス間などの転送ドメイン間の境界を識別するために、例示的な実施形態のシステムは、以下に説明する特徴のセットを実現する。

【0286】

第１に、リーフサブネット内から、任意のコアファブリックゲートウェイポートが１つ以上のＤＬＩＤによって識別され、転送が通常のＬＲＨ．ＤＬＩＤベースの探索を使用して行われる。探索された出力ポートがＬＲＨ／ＤＬＩＤ（元のＬＲＨに基づく）からＧＲＨ／ＩＳＲＮへのアドレス指定モードにおける変更を必要とするコアファブリックゲートウェイポートを表すことを識別するために、パケットが出力ポートの出口リンクに到達する前にモードのこの変更を判断できる情報が提供される。パケットのストールを避けるために、この情報は、パケットが入口ポートで受信された後、可能な限り早く利用可能にされ、アービターがパケットを出力ポートに転送できるようにすると、新たなＬＲＨが準備され、充分に定義される。したがって、情報は、入口ポートにおける出力ポートの探索とともに利用できる。さらに、同じ出力ポートが、どの他のローカルシステムポートがパケットをそれにクロスバーを介して送信しているかに依って、１つより多い「パーソナリテ
ィ」を有することを可能にするために、各入力ポートに関連付けられるレジスタを介して利用可能なタイプの出力ポートを有することは最も柔軟なスキームである。これは、ＬＦＴエントリにおいてエンコードされるポートタイプを有することに対して空間を節約し、それは、柔軟性を与え、共有ＬＦＴエントリ、および出力ポートのタイプがチップ全体に対して一回定義される集中型アプローチを使用することの両方に対して、アクセス調停の必要性がない。新たなアドレス指定モードで新たなパケットを構築するためのハードウェアサポートは、内部レジスタに基づく固定されたＬＲＨ．ＤＬＩＤの生成、およびＧＲＨから正しいＩＳＲＮビットフィールドを識別して抽出するロジックを含む。

【0287】

第２に、コアファブリックインスタンス内では、入口ポートにおけるＧＲＨ／ＩＳＲＮ転送モードの識別は、着信ＬＲＨ．ＤＬＩＤ値を内部レジスタの内容と照合することに基づく。次いで、パケットＬＲＨ．ＤＬＩＤ値がレジスタに含まれる値と一致する場合、転送モードは、例示的な実施形態の「ＧＲＨ／ＩＳＲＮ」転送モードである。それ以外の場合、パケットＬＲＨ．ＤＬＩＤ値がレジスタに含まれる値と一致しない場合には、転送モードはインフィニバンド（ＩＢ）レガシー「ＬＲＨ／ＤＬＩＤ」転送モードである。

【0288】

例示的な実施形態では、性能および柔軟性のために、このレジスタは、好ましくは、すべてのポートに対して複製される。これは、サブネットマネージャ（ＳＭ）はこのシステム特徴を認識していないが、そのリーフサブネット内において利用可能なＬＦＴサイズを低減することを伴わない、リーフサブネット仮想スイッチインスタンスを有することも可能であることを意味する。コアファブリックインスタンス内からは、ゲートウェイポート（またはエンドポート）に向かうルートは、各「ルート内」システム入口ポートのＬＦＴから出力ポートを探索するために使用されるＩＳＲＮ値によって定義される。

【0289】

出力ポートが宛先リーフサブネットへのゲートウェイであることを判断するために、例示的な実施形態の単純な解決策は、パケットＦＬＳＮ番号を、探索された出力ポートに関連付けられるＦＬＳＮ番号と比較することである。しかしながら、入口ポートが１つより多いモードで動作することを依然として可能にしながらアドレス指定モードにおける必要な変更を識別するためには、入口ポートが、可能な出力ポートごとに、フラグを有して、出力ポートがアドレス指定モードにおける変更を表すかどうか、または出力ポートがアドレス指定モードの変更を表さないことを告げれば十分である。したがって、入力転送モードがＧＲＨ／ＩＳＲＮであり、出力ポートがアドレス指定モードにおける変更を表すものとして（すなわち、この入口ポートに対して）フラグを立てられる場合、アドレス指定モードはGRH.DGID.prefix.dlidに含まれるＤＬＩＤ値に基づいて決定論的にＬＲＨ／ＤＬＩＤに変更することができる。この場合、ＦＬＳＮ値を一致させることは、コアファブリックインスタンス内におけるＩＳＲＮベースのルーティングが正しい限り、追加の保全性チェックを表すに過ぎないであろうことに注目されたい。

【0290】

新たなアドレス指定モードを伴う新たなパケットを構築するためのＨＷサポートは、ＧＲＨから正しいＤＬＩＤビットフィールドを識別し抽出するロジックと、抽出されたＤＬＩＤ値に基づいた新たなＬＲＨの生成とを含む。

【0291】

第３に、２つのリーフサブネットが同じシステムインスタンス上の異なる仮想スイッチによって直接接続されている場合、典型的には、２つの仮想スイッチにおけるポート間に相互リーフサブネットゲートウェイポート関係が存在する。したがって、リーフサブネットＡ内からは、リーフサブネットＢへの直接接続性を提供する特定のリーフサブネットゲートウェイポートを識別する１つ以上のＤＬＩＤ値が存在することになる。次いで、出力ポートが宛先リーフサブネットへのゲートウェイであることを判断するために、例示的な実施形態の単純な解決策は、パケットＦＬＳＮ番号を、探索された出力ポートに関連付けられるＦＬＳＮ番号と比較することである。しかしながら、入口ポートが１つより多いモ
ードで動作することを依然として可能にしながらアドレス指定モードにおける必要な変更を識別するためには、上記のケースに対してのように、入口ポートが、可能な出力ポートごとに、フラグを有して、出力ポートがアドレス指定モードにおける変更を表すかどうか、または出力ポートがアドレス指定モードの変更を表さないかどうかを示せば十分である。

【0292】

それでも、アドレス指定モードの変更が、ＬＲＨ／ＤＬＩＤからＧＲＨ／ＩＳＲＮまたはＬＲＨ／ＤＬＩＤからＬＲＨ／ＤＬＩＤのいずれか（すなわち、この例におけるように）であり得る場合、出力ポートごとに単一のフラグ値のみを有することは十分ではない。したがって、出力ポートごとのフラグは、好ましくは、アドレス指定モードの変更だけでなく、ゲートウェイポートのタイプを識別する。しかしながら、ここでも、ＦＬＳＮマッチングを使用することは代替策であるが、これは、リーフサブネットインスタンス間の転送が正しく実現される限り、依然として主に保全性チェックである。

【0293】

リーフサブネット／コアファブリックモデルの追加ハードウェアサポート：
任意の数の入力ＤＧＩＤ．サブネットプレフィックス値をサポートするが、依然としてＤＧＩＤ．ＧＵＩＤ値をターゲット物理または仮想ＨＣＡポートについて検証できるようにするために、そのようなターゲット（ｖ）ＨＣＡは、実施形態に従って、あるモードを含み、着信ＧＲＨ．ＤＧＩＤを物理または仮想のＨＣＡポートについてハードウェアおよびエイリアスＧＩＤ値に対してチェックすることはＧＵＩＤ部分のみに制限され、サブネットプレフィックス部分は無視される。

【0294】

このモードは、各ＧＩＤテーブルエントリについて個々に選択的に指定してもよい。しかしながら、ＨＷの実現の観点からは、いくつかのテーブルエントリに対して連想的一致を有し、次いで、異なる一致基準に基づいて複数の一致も有することは、困難である。したがって、一実施形態によれば、チェックが常にＧＵＩＤ部分のみについて行われるモードで十分である。

【0295】

仮定は、その場合、各仮想ＨＣＡポートは、ＧＵＩＤ部分のみが考慮されるときにも一意である２つ以上のＧＩＤテーブルエントリとともに設定される、というものである。通常またはデフォルトの場合は、関連するｈｗＧＵＩＤは、現在アクティブなＶＭを表すｖＧＵＩＤとともに存在する、ということである。２つの対応するＧＩＤテーブルエントリは、各々、割り当てられたＩＳＮ値に基づくサブネットプレフィックス値を有することになる。

【0296】

（ＬＦＴ）探索のために（ＧＲＨ）におけるサブネットプレフィックス値を使用する方法
図１６は、高性能コンピューティング環境でのネットワークスイッチ環境における線形転送テーブル探索のためにパケットヘッダを使用するための一実施形態による方法１６００を示す。ここで、図の方法について説明する。第１および第２のサブネットは、ネットワークファブリックを含むコンピュータ環境で提供される。第１のサブネットは第２のサブネットとは異なる。第１のサブネットは、第１のセットのネットワークスイッチを含み、第１のセットのネットワークスイッチの各々は、線形転送テーブル（ＬＦＴ）および複数の物理ポートを含む。第２のサブネットは、第２のセットのネットワークスイッチを含み、第２のセットのネットワークスイッチの各々は、ＬＦＴおよび複数の物理ポートを含む。これは、本方法の例示的な実施形態の環境である。全体として、方法１６００は、第１のセットのネットワークスイッチのうちの第１のネットワークスイッチの同じ第１のＬＦＴが、第１のサブネットの第１のセットのネットワークスイッチのネットワークスイッチ間で転送されるべきパケットのサブネット内転送判断、ならびに第１および第２のサブネットのそれぞれの第１のセットのネットワークスイッチおよび第２のセットのネットワ
ークスイッチの間で転送されるべきパケットのサブネット間転送判断の両方に対して用いられることを可能にする。

【0297】

第１のステップ１６１０において、第１のパケットが、第１のサブネットの第１のセットのネットワークスイッチのうちの第１のネットワークスイッチで受信される。ステップ１６２０において、第１のパケットのヘッダの第１の部分が検査される。第１のパケットのヘッダの第１の部分の第１の条件がステップ１６３０で判断され、第１のパケットのヘッダの第１の部分の第２の条件がステップ１６４０で判断される。

【0298】

サブネット内転送判断は、第１のパケットのヘッダの第１の部分が第１の条件を有するか、そうでなければ第１の条件を示すと判断された場合に、ステップ１６３０において選択的に行われる。そうでない場合、第１のパケットのヘッダの第１の部分が第１の条件を有していないか、そうでなければ第１の条件を示していないと判断された場合、方法はサブネット間転送判断ステップ１６４０に進む。

【0299】

第１のパケットのヘッダの第１の部分が第１の条件を有するか、さもなければ第１の条件を示すと判断された場合など、サブネット内転送判断がステップ１６３０において選択的に行われる場合、パケットは、例示的実施形態に従って、ステップ１６３５において、サブネット内（ＬＲＨ／ＤＬＩＤ）転送を用いて処理される。

【0300】

同様に、第１のパケットのヘッダの第１の部分が第２の条件を有するか、さもなければ第２の条件を示すと判断された場合など、サブネット間転送判断がステップ１６４０において選択的に行われる場合、パケットは、例示的実施形態に従って、ステップ１６４５において、サブネット間（ＧＲＨ／ＩＳＲＮ）転送を用いて処理される。

【0301】

ステップ１６４５において、サブネット間転送が、第２のサブネットの第２のネットワークスイッチのセットのうちの選択されたネットワークスイッチに第１のパケットをルーティングするために、第１のパケットのヘッダの第１の部分の第２の条件に従って、第１のネットワークスイッチの第１のＬＦＴを使用して、選択的に行われる。

【0302】

例示的な実施形態では、第１のパケットのヘッダの第１の部分を検査することは、第１のパケットのヘッダのローカルルートヘッダ（ＬＲＨ）部分を検査することを含む。さらに、例示的な実施形態によれば、第１のパケットのヘッダの第１の部分の条件を判断することは、ＬＲＨの選択された部分を第１のネットワークスイッチに格納される所定の値と比較することと、ＬＲＨの選択された部分と所定の値との間の不一致に従って第１の条件を判断することと、ＬＲＨの選択された部分と所定の値との間の一致に従って第２の条件を判断することとを含む。

【0303】

さらに、例示的な実施形態では、ＬＲＨの選択された部分と所定の値との間の一致に従って第２の条件を選択的に判断することは、ＬＦＴを使用して、ＬＲＨの選択された部分を使用して特殊スイッチポート（ＳＳＰ）を索引付することを含む。

【0304】

特に、例示的実施形態に関して、第１のパケットを、第２のサブネットの第２のネットワークスイッチのセットのうちの選択されたネットワークスイッチにルーティングすることは、第１のパケットのヘッダのグローバルルートヘッダ（ＧＲＨ）部分のセクションを選択することを含み、ヘッダのＧＲＨ部分の選択されたセクションは、サブネット間ルート番号（ＩＳＲＮ）を格納し、ルーティングすることはさらに、ＧＲＨのＩＳＲＮを使用して、第１のネットワークスイッチの第１のＬＦＴを索引付けすることと、ＧＲＨのＩＳＲＮを使用して第１のＬＦＴを索引付けすることに従って、第１のパケットを第２のサブネットの第２のネットワークスイッチのセットのうちの選択されたネットワークスイッチ
にルーティングすることとを含み、第２のサブネットはネットワークスイッチ環境の中間コアファブリックである。

【0305】

さらに、例示的な実施形態によれば、第１のパケットのヘッダの第１の部分の第１または第２の条件のいずれもステップ１６３０およびステップ１６４０で判断されないときは、パケットはステップ１６５０で破棄される。すなわち、例示的な実施形態では、転送条件のいずれも満たされないため、パケットはステップ１６５０で破棄される。

【0306】

例示的実施形態の特徴は、ここに提示された特徴のうちのいずれかを行なうように処理システムをプログラミングするために使用可能な命令を格納した記憶媒体またはコンピュータ読取り可能媒体であるコンピュータプログラム製品において、それを使用して、またはその助けを借りて実現され得る。記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ装置、磁気カードもしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／もしくはデータを格納するのに好適な任意のタイプの媒体もしくは装置を含み得るものの、それらに限定されない。

【0307】

例示的実施形態の特徴は、機械読取り可能媒体のうちのいずれかに格納された状態で、処理システムのハードウェアを制御するために、および処理システムが例示的実施形態の結果を利用する他の機構とやり取りすることを可能にするために、ソフトウェアおよび／またはファームウェアに取込まれ得る。そのようなソフトウェアまたはファームウェアは、アプリケーションコード、装置ドライバ、オペレーティングシステム、および実行環境／コンテナを含み得るものの、それらに限定されない。

【0308】

例示的実施形態の特徴はまた、たとえば、特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）などのハードウェアコンポーネントを使用して、ハ
ードウェアにおいて実現されてもよい。ここに説明された機能を行なうようにハードウェアステートマシンを実現することは、関連技術の当業者には明らかであろう。

【0309】

加えて、例示的実施形態は、この開示の教示に従ってプログラミングされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取り可能記憶媒体を含む、１つ以上の従来の汎用または特殊デジタルコンピュータ、コンピューティング装置、マシン、またはマイクロプロセッサを使用して都合よく実現され得る。ソフトウェア技術の当業者には明らかであるように、この開示の教示に基づいて、適切なソフトウェアコーディングが、熟練したプログラマによって容易に準備され得る。

【0310】

さまざまな実施形態が上述されてきたが、それらは限定のためではなく例示のために提示されたことが理解されるべきである。この発明の精神および範囲から逸脱することなく、形状および詳細のさまざまな変更を行なうことができることは、関連技術の当業者には明らかであろう。

【0311】

例示的実施形態は、特定された機能およびそれらの関係の実行を示す機能的構築ブロックの助けを借りて上述されてきた。説明の便宜上、これらの機能的構築ブロックの境界は、この明細書中ではしばしば任意に規定されてきた。特定された機能およびそれらの関係が適切に実行される限り、代替的な境界を規定することができる。このため、そのようないかなる代替的な境界も、この発明の範囲および精神に含まれる。

【0312】

例示的実施形態の前述の説明は、例示および説明のために提供されてきた。それは、網羅的であるよう、またはこの発明を開示された形態そのものに限定するよう意図されては
いない。例示的実施形態の幅および範囲は、上述の例示的な実施形態のいずれによっても限定されるべきでない。多くの変更および変形が、当業者には明らかになるだろう。これらの変更および変形は、開示された特徴の関連するあらゆる組合せを含む。実施形態は、この発明の原理およびその実用的応用を最良に説明するために選択され説明されたものであり、それにより、考えられる特定の使用に適したさまざまな実施形態についての、およびさまざまな変更例を有するこの発明を、当業者が理解できるようにする。この発明の範囲は、請求項およびそれらの同等例によって定義されるよう意図されている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】