特許 7607109 高性能コンピューティング環境においてパーティションメンバーシップに関連して定義されるマルチキャストグループメンバーシップを提供するシステムおよび方法

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

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

(11)【特許番号】

(24)【登録日】2024-12-18

(45)【発行日】2024-12-26

(54)【発明の名称】高性能コンピューティング環境においてパーティションメンバーシップに関連して定義されるマルチキャストグループメンバーシップを提供するシステムおよび方法

(51)【国際特許分類】

   H04L 45/42 20220101AFI20241219BHJP

   H04L 41/0806 20220101ALI20241219BHJP

【ＦＩ】

H04L45/42

H04L41/0806

【請求項の数】 15

【外国語出願】

(21)【出願番号】P 2023217956

(22)【出願日】2023-12-25

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

【原出願日】2018-03-22

(65)【公開番号】P2024038087

(43)【公開日】2024-03-19

【審査請求日】2024-01-23

(31)【優先権主張番号】62/476,423

(32)【優先日】2017-03-24

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

(31)【優先権主張番号】62/547,203

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,206

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,213

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,218

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,223

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,225

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,255

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,258

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,259

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,260

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,261

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】62/547,264

(32)【優先日】2017-08-18

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

(31)【優先権主張番号】15/927,448

(32)【優先日】2018-03-21

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

(73)【特許権者】

【識別番号】502303739

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

(74)【代理人】

【識別番号】110001195

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

(72)【発明者】

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

(72)【発明者】

【氏名】ボグダンスキー，バルトシュ

(72)【発明者】

【氏名】ホレン，リネ

【審査官】吉田 歩

(56)【参考文献】

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

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

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

【文献】特表２００４－５３７９１８（ＪＰ，Ａ）

【文献】V.Kasyap，RFC 4392, IP over InfiniBand (IPoIB) Architecture，2006年04月，<https://rfc-editor.org/rfc/pdfrfc/rfc4392.txt.pdf>, 検索日[2024.11.14]

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

Ｈ０４Ｌ ４５／４２

Ｈ０４Ｌ ４１／０８０６

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

【請求項1】

高性能コンピューティング環境においてパーティションメンバーシップに対して定義されたマルチキャストグループメンバーシップを提供するための方法であって、
１つ以上のマイクロプロセッサを備えるコンピュータにおいて、１つ以上のスイッチとサブネットマネージャとを備えるサブネットを提供することと、
サブネットのエンドノードにおいて、マルチキャスト参加要求メッセージを生成することとを含み、前記マルチキャスト参加要求メッセージは、複数のサブネット管理属性を含み、前記エンドノードは、前記サブネット内で定義されるパーティションのメンバーであり、前記方法はさらに、
前記マルチキャスト参加要求メッセージの前記複数のサブネット管理属性のうちの１つを介して、前記パーティションのすべてのメンバーが同じマルチキャストグループに追加されるべきであることを示すことを含む、方法。

【請求項2】

前記マルチキャスト参加要求メッセージの前記複数のサブネット管理属性のうちの別のサブネット管理属性を介して、前記パーティションの識別子を示すことをさらに含む、請求項１に記載の方法。

【請求項3】

前記サブネットマネージャにおいて、前記マルチキャスト参加要求メッセージを受信することと、
前記マルチキャスト参加要求メッセージを受信すると、前記パーティションのすべてのメンバーを同じマルチキャストグループに追加することとをさらに含む、請求項２に記載の方法。

【請求項4】

スパニングツリーを生成することをさらに含み、前記スパニングツリーは、前記サブネットのうち、前記パーティションのメンバーであるすべてのエンドノードを含む、請求項３に記載の方法。

【請求項5】

生成された前記スパニングツリーに基づいて更新されるべき前記１つ以上のスイッチのセットを決定することをさらに含む、請求項４に記載の方法。

【請求項6】

生成された前記スパニングツリーを、決定された各スイッチに分散させることをさらに含む、請求項５に記載の方法。

【請求項7】

各決定されたスイッチにおいて、生成された前記スパニングツリーに基づいてマルチキャスト転送テーブルを更新することをさらに含む、請求項６に記載の方法。

【請求項8】

高性能コンピューティング環境においてパーティションメンバーシップに対して定義されたマルチキャストグループメンバーシップを提供するためのシステムであって、
１つ以上のマイクロプロセッサを含むコンピュータにおいて、
１つ以上のスイッチとサブネットマネージャとを含むサブネットを備え、
マルチキャスト参加要求メッセージが、サブネットのエンドノードにおいて生成され、前記マルチキャスト参加要求メッセージは、複数のサブネット管理属性を含み、前記エンドノードは、前記サブネット内で定義されるパーティションのメンバーであり、
前記マルチキャスト参加要求メッセージの前記複数のサブネット管理属性のうちの１つを介して、前記パーティションのすべてのメンバーが同じマルチキャストグループに追加されるべきであるという指示が提供される、システム。

【請求項9】

前記マルチキャスト参加要求メッセージの前記複数のサブネット管理属性のうちの別のサブネット管理属性を介して、前記パーティションの識別子の指示が提供される、請求項８に記載のシステム。

【請求項10】

前記マルチキャスト参加要求メッセージは、前記サブネットマネージャにおいて受信され、
前記マルチキャスト参加要求メッセージを受信すると、前記パーティションのすべてのメンバーが同じマルチキャストグループに追加される、請求項９に記載のシステム。

【請求項11】

スパニングツリーが生成され、前記スパニングツリーは、前記サブネットのうち、前記パーティションのメンバーであるすべてのエンドノードを含む、請求項１０に記載のシステム。

【請求項12】

生成された前記スパニングツリーに基づいて更新されるべき前記１つ以上のスイッチのセットに関する決定が行われる、請求項１１に記載のシステム。

【請求項13】

生成された前記スパニングツリーは、決定された各スイッチに分散される、請求項１２に記載のシステム。

【請求項14】

マルチキャスト転送テーブルが、決定された各スイッチにおいて更新され、各更新は、生成された前記スパニングツリーに基づく、請求項１３に記載のシステム。

【請求項15】

命令を有するコンピュータプログラムであって、前記命令は、読み出され、実行されると、コンピュータに請求項１～７のいずれか１項に記載の方法を実行させる、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

著作権表示
本特許文献の開示の一部には、著作権保護の対象となるものが含まれている。著作権者は、この特許文献または特許開示の何者かによる複製が、特許商標庁の特許ファイルまたは記録にある限り、それに対して異議を唱えないが、そうでなければ、いかなる場合もすべての著作権を留保する。

【0002】

優先権の主張および関連出願への相互参照
この出願は、２０１７年３月２４日に提出された「ＳＡアクセスおよびスタートアップフェイルオーバー時間を最小限にするインフィニバンドファブリック最適化のためのシステムならびに方法（SYSTEM AND METHOD FOR INFINIBAND FABRIC OPTIMIZATIONS TO MINIMIZE SA ACCESS AND STARTUP FAILOVER TIMES）」と題する米国仮特許出願第６２／４７６，４２３号；２０１７年８月１８日に提出された「高性能コンピューティング環境においてＳＡアクセスの必要性を低減するために同種のファブリック属性を提供するシステムおよび方法（SYSTEM AND METHOD TO PROVIDE HOMOGENEOUS FABRIC ATTRIBUTES TO REDUCE THE NEED FOR SA ACCESS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題する米
国仮特許出願第６２／５４７，２０３号；２０１７年８月１８日に提出された「高性能コンピューティング環境において同種のファブリック属性に基づいてＡＲＰ応答およびピアツーピアネゴシエーションから導出されるパスレコードを提供するシステムならびに方法（SYSTEM AND METHOD TO PROVIDE PATH RECORDS DERIVED FROM ARP RESPONSES AND PEER-TO-PEER NEGOTIATION ON HOMOGENOUS FABRIC ATTRIBUTE IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題する米国仮特許出願第６２／５４７，２０６号；２０１７年８月１８日に提出された「高性能コンピューティング環境においてパーティションメンバーシップに対して定義されたマルチキャストグループメンバーシップを提供するシステムおよび方法」と題する米国仮特許出願第６２／５４７，２１３号；２０１７年８月１８日に提出された「高性能コンピューティング環境において正規パーティションメンバーおよび制限付きパーティションメンバーの両方を容易にするためにマルチキャストグループごとにデュアルマルチキャストＬＩＤ割り当てを提供するシステムならびに方法（SYSTEM AND METHOD TO PROVIDE DUAL MULTICAST LID ALLOCATION PER MULTICAST GROUP TO FACILITATE
BOTH FULL AND LIMITED PARTITION MEMBERS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題する米国仮特許出願第６２／５４７，２１８号；２０１７年８月１８日に提出された「高性能コンピューティング環境において関連するＭＧＩＤについて受信マルチキャストメッセージ上でマルチキャストグループＭＬＩＤダイナミックディスカバリを提供するシステムおよび方法（SYSTEM AND METHOD TO PROVIDE MULTICAST GROUP MLID DYNAMIC DISCOVERY ON RECEIVED MULTICAST MESSAGES FOR RELEVANT MGID IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題する米国仮特許出願第第６２／５４７，２２３号；２０１７年８月１８日に提出された「高性能コンピューティング環境において追加のＳＭＡ属性としてパーティションごとにデフォルトのマルチキャストＬＩＤ値を提供するシステムおよび方法（SYSTEM AND METHOD TO PROVIDE DEFAULT MULTICAST LID VALUES PER PARTITION AS ADDITIONAL SMA ATTRIBUTES IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題する米国仮特許出願第６２／５４７，２２５号；２０１７年８月１８日に提出された「高性能コンピューティング環境においてＳＭポリシー入力として定義されるパーティションごとのデフォルトのマルチキャストＬＩＤに対する明示的なマルチキャストＬＩＤ割り当てを提供するシステムおよび方法（SYSTEM AND METHOD TO PROVIDE EXPLICIT MULTICAST LID ASSIGNMENT FOR PER PARTITION DEFAULT MULTICAST LIDS DEFINED AS SM PO
LICY INPUT IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題する米国仮特許出願第６２／５４７，２５５号；２０１７年８月１８日に提出された「高性能コンピューティング環境において拡張ポート情報としてアナウンスメントおよびディスカバリのためにデフォルトのマルチキャストグループ（ＭＣＧ）を提供するシステムおよび方法（SYSTEM AND METHOD TO PROVIDE DEFAULT MULTICAST GROUP (MCG) FOR ANNOUNCEMENTS AND DISCOVERY AS EXTENDED PORT INFORMATION IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」
と題する米国仮特許出願第６２／５４７，２５８号；２０１７年８月１８日に提出された「高性能コンピューティング環境におけるアナウンスメントのスケーラブルな転送および情報要求インターセプトのためにデフォルトのマルチキャストプロキシを提供するシステムならびに方法（SYSTEM AND METHOD TO PROVIDE DEFAULT MULTICAST PROXY FOR SCALABLE FORWARDING OF ANNOUNCEMENTS AND INFORMATION REQUEST INTERCEPTING IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題する米国仮特許出願第６２／５４７，２５９号；２０１７年８月１８日に提出された「高性能コンピューティング環境において複数のパーティションにおいてマルチキャストベースのアナウンスメントを受信するためにキューペア１を用いるシステムおよび方法（SYSTEM AND METHOD TO USE QUEUE PAIR 1 FOR RECEIVING MULTICAST BASED ANNOUNCMENTS IN MULTIPLE PARTITIONS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題する米国仮特許出願第６２／５４７，２６０号；２０１
７年８月１８日に提出された「高性能コンピューティング環境においてＧＵＩＤからＬＩＤへのキャッシュコンテンツのための基礎としてすべての着信マルチキャストパケットを用いるシステムおよび方法（SYSTEM AND METHOD TO USE ALL INCOMING MULTICAST PACKETS AS A BASIS FOR GUID TO LID CACHE CONTENTS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題する米国仮特許出願第６２／５４７，２６１号；および２０１７年８月
１８日に提出された「高性能コンピューティング環境におけるデフォルトのＩＢマルチキャストグループを介する組み合わされたＩＢおよびＩＰアドレスならびに名前解決スキームを提供するシステムならびに方法（SYSTEM AND METHOD TO PROVIDE COMBINED IB AND IP ADDRESS AND NAME RESOLUTION SCHEMES VIA DEFAULT IB MULTICAST GROUPS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題する仮特許出願第６２／５４７，２６４号
の優先権の利益を主張し、これらの各出願をここに引用により援用する。

【0003】

この出願は、以下の特許出願に関連しており、それらの各々はその全体がここに引用により援用される。本願と同時に提出された「高性能コンピューティング環境においてＳＡアクセスの必要性を低減するために同種のファブリック属性を提供するシステムおよび方法（SYSTEM AND METHOD TO PROVIDE HOMOGENEOUS FABRIC ATTRIBUTES TO REDUCE THE NEED FOR SA ACCESS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題される米国特
許出願、出願番号 ／ 、（弁護士整理番号ＯＲＡＣＬ‐０５８２８ＵＳ１）；本願と同時に提出された「高性能コンピューティング環境において同種のファブリック属性に基づいてＡＲＰ応答およびピアツーピアネゴシエーションから導出されるパスレコードを提供するシステムならびに方法（SYSTEM AND METHOD TO PROVIDE PATH RECORDS DERIVED FROM ARP RESPONSES AND PEER-TO-PEER NEGOTIATION ON HOMOGENOUS FABRIC ATTRIBUTE IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題される米国特許出願、出願番号 ／ 、（弁護士整理番号ＯＲＡＣＬ‐０５８２９ＵＳ１）；本願と同時に提出された「高性能コンピューティング環境において正規パーティションメンバーおよび制限付きパーティションメンバーの両方を容易にするためにマルチキャストグループごとにデュアルマルチキャストＬＩＤ割り当てを提供するシステムおよび方法（SYSTEM AND
METHOD TO PROVIDE DUAL MULTICAST LID ALLOCATION PER MULTICAST GROUP TO FACILITATE BOTH FULL AND LIMITED PARTITION MEMBERS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT）」と題される米国特許出願、出願番号 ／ 、（代理整理番号ＯＲＡＣＬ‐０５８３１ＵＳ１）；本願と同時に提出された「高性能コンピューティング環境において関連するマルチキャストＧＩＤの受信マルチキャストメッセージに基づいてマルチキャストグループマルチキャストＬＩＤダイナミックディスカバリを提供するシステムお
よび方法（SYSTEM AND METHOD TO PROVIDE MULTICAST GROUP MULTICAST LID DYNAMIC DISCOVERY BASED ON RECEIVED MULTICAST MESSAGES FOR RELEVANT MULTICAST GID IN A HIGH
PERFORMANCE COMPUTING ENVIRONMENT）」と題される米国特許出願、出願番号 ／
、（弁護士整理番号ＯＲＡＣＬ‐０５８３２ＵＳ１）。

【背景技術】

【0004】

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

【発明の概要】

【0005】

概要：
高性能コンピューティング環境でパーティションメンバーシップに関連するマルチキャストグループ（ＭＣＧ）メンバーシップを提供するシステムおよび方法。高性能コンピューティング環境でパーティションメンバーシップに関連して定義されるマルチキャストグループメンバーシップを提供する例示的な方法は、サブネットマネージャが、マルチキャストグループを作成する要求を受信することができ、要求はインジケータを含み、インジケータは、サブネットにおいて定義されるパーティションの各メンバーがマルチキャストグループに関連付けられることを示す。この方法は、サブネットマネージャが、サブネットにおいて定義されるパーティションのメンバーである、ある数の追加のエンドポートを決定することができる。この方法は、サブネットマネージャが、パーティションのメンバーである、ある数の追加のエンドポートを、マルチキャストグループを定義する識別子に関連付けることができる。この方法は、サブネットマネージャが、マルチキャストグループを定義する識別子を含むマルチキャストパケットを、マルチキャストグループを定義する識別子に関連付けられた各エンドポートに配信するためのルートを定義することができる。

【図面の簡単な説明】

【0006】

【図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】一実施形態による、高性能コンピューティング環境において複数のパーティションでマルチキャストベースのアナウンスメントを受信するためにキューペア１（ＱＰ１）を用いるシステムを示す。

【図64】一実施形態による、高性能コンピューティング環境において複数のパーティションでマルチキャストベースのアナウンスメントを受信するためにキューペア１（ＱＰ１）を用いる方法のフローチャートを示す。

【図65】一実施形態による、高性能コンピューティング環境においてグローバル一意識別子（ＧＵＩＤ）からローカル識別子（ＬＩＤ）へのキャッシュコンテンツの基礎としてすべての着信マルチキャスト（ＭＣ）パケットを用いる方法のフローチャートを示す。

【図66】一実施形態による、高性能コンピューティング環境においてグローバル一意識別子（ＧＵＩＤ）からローカル識別子（ＬＩＤ）へのキャッシュコンテンツの基礎としてすべての着信マルチキャスト（ＭＣ）パケットを用いるシステムを示す。

【図67】一実施形態による、高性能コンピューティング環境においてグローバル一意識別子（ＧＵＩＤ）からローカル識別子（ＬＩＤ）へのキャッシュコンテンツの基礎としてすべての着信マルチキャスト（ＭＣ）パケットを用いるシステムを示す。

【図68】一実施形態による、高性能コンピューティング環境においてグローバル一意識別子（ＧＵＩＤ）からローカル識別子（ＬＩＤ）へのキャッシュコンテンツの基礎としてすべての着信マルチキャスト（ＭＣ）パケットを用いる方法のフローチャートを示す。

【図69】一実施形態による、高性能コンピューティング環境において、デフォルトのＩＢマルチキャストグループを介して、組み合わされたＩＢおよびＩＰアドレスならびに名前解決スキームを提供する方法のフローチャートを示す。

【図70】一実施形態による、高性能コンピューティング環境において、デフォルトのＩＢマルチキャストグループを介して、組み合わされたＩＢおよびＩＰアドレスならびに名前解決スキームを提供するシステムを示す。より具体的には、この図は、従来のＧＵＩＤからＬＩＤへのキャッシュを示す。

【図71】一実施形態による、高性能コンピューティング環境において、デフォルトのＩＢマルチキャストグループを介して、組み合わされたＩＢおよびＩＰアドレスならびに名前解決スキームを提供する方法のフローチャートを示す。

【図72】一実施形態による、高性能コンピューティング環境において、デフォルトのＩＢマルチキャストグループを介して、組み合わされたＩＢおよびＩＰアドレスならびに名前解決スキームを提供する方法のフローチャートを示す。

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

【0007】

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

【0008】

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

【0009】

本明細書では、高性能コンピューティング環境においてパーティションメンバーシップに関して定義されたマルチキャストグループメンバーシップを提供するシステムおよび方法について説明する。

【0010】

この発明の以下の説明は、高性能ネットワークの一例として、インフィニバンド^ＴＭ（ＩＢ）ネットワークを使用する。以下の説明全体にわたり、インフィニバンド^ＴＭの仕様（インフィニバンド仕様、ＩＢ仕様、またはレガシーＩＢ仕様など、さまざまな呼ばれ方がある）を引用することがある。このような引用は、２０１５年３月に発表され、http://www.inifinibandta.orgから入手可能な、本明細書にその全体を引用により援用するInfiniBand Trade Association Architecture Specification, Volume 1, Version 1.3を引用
することであると理解される。他のタイプの高性能ネットワークが何ら限定されることなく使用され得ることが、当業者には明らかであるだろう。以下の説明ではまた、ファブリックトポロジーについての一例として、ファットツリートポロジーを使用する。他のタイプのファブリックトポロジーが何ら限定されることなく使用され得ることが当業者には明らかであるだろう。

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

ＳＭは、サブネット管理（ＳＡ）をローカルサブネットに提供する役割を果たす。ＳＡは、ローカルサブネットに関するいくつかのタイプの情報へのアクセスおよびその保存を提供する。ＳＡを提供するために、サブネットマネージャは通常、サブネット関連情報を記憶するためのクエリ可能なデータベースを保持する。一般にＳＡによって記憶／提供される情報の例には、エンドノード間のパス、イベントの通知、サービス属性など、エンドノードがサブネットでの動作に必要な情報；パーティショニングデータ、M_Keysなどの非アルゴリズム情報；トポロジーデータ、スイッチ転送テーブルなど、他の管理エンティティに役立つオプションの情報が含まれる。

【0018】

ＳＡが提供するデータは、管理データグラム（ＭＡＤ）の使用を介してアクセス、照会、または報告される。ＭＡＤは標準化された管理パケットであり、他の用途の中でも特に、ＳＭ／ＳＡとＩＢデバイスとの間、およびＩＢデバイス、それら自体間の管理操作を可能にする。

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

ＩＢサブネットでは、各エンドノードは１つ以上のホストチャネルアダプタ（ＨＣＡ）を含むことができる。ＨＣＡは、データパケットの生成および送信、ならびにデータパケットの受信および処理を担う。各ホストチャネルアダプタ（ＨＣＡ）は、１つ以上のポートを有することができる。ＨＣＡのポートは、ＨＣＡ、およびＨＣＡを含むエンドノードをネットワークファブリックに接続するために用いられる。たとえば、ＨＣＡのポートは、ケーブル（ツイストペア銅線、光ファイバーケーブルなど）などの物理的媒体を介してサブネットスイッチに接続することができる。

【0024】

ネットワークファブリックに接続されたＨＣＡポートには、ローカルサブネットマネージャ（つまり、ＨＣＡが接続されるサブネットのサブネットマネージャ）によってローカル識別子（ＬＩＤ）が割り当てられる。ＬＩＤは、ＨＣＡポートのアドレス指定に用いられる。他のサブネットノードにも、ローカルサブネットマネージャによってＬＩＤを割り当てることができる。たとえば、サブネットホストおよびスイッチに、サブネットマネージャによってローカル識別子（ＬＩＤ）を割り当てることができ、サブネットホストおよびスイッチは、それらの割り当てられたＬＩＤによってアドレス指定することができる。ＬＩＤはサブネット内で一意であり、単一のサブネットは４９１５１のユニキャストＬＩＤに制限され得る。

【0025】

一実施形態によれば、ＩＢネットワークにおけるサブネット内ルーティングは、ローカルサブネットスイッチに格納された線形転送テーブル（ＬＦＴ）に基づくことができる。ＬＦＴは、使用中のルーティングメカニズムに従ってＳＭによって計算される。各データパケットには、パケットを作成したポートを識別するソースＬＩＤ（ＳＬＩＤ）と、パケットの配信先ポートを識別する宛先ＬＩＤ（ＤＬＩＤ）とが含まれる。さらに、線形転送テーブル（ＬＦＴ）の各エントリは、ＤＬＩＤと出力ポートとで構成される。テーブル内のＬＩＤごとに１つのエントリのみがサポートされる。パケットがスイッチに到着すると、その出力ポートはスイッチの転送テーブルにおいてパケットのＤＬＩＤを探索することにより判断される。次に、パケットは、ＬＦＴにおけるパケットのＤＬＩＤに対応するスイッチポートを介して外部に転送される。ルーティングは、パケットがネットワーク内で所与の送信元／宛先ペア（ＬＩＤペア）間において同じパスを取るため、決定論的である。

【0026】

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

【0027】

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

【0028】

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

【0029】

サブネット内で有効で一意のローカルアドレスであるＬＩＤに加えて、各ＩＢデバイス（例えばＨＣＡまたはスイッチ）は６４ビットのグローバル一意識別子（ＧＵＩＤ）を有することができる。さらに、ＨＣＡの各ポートは独自のＧＵＩＤを有することができる。ＩＢデバイスのＧＵＩＤは、デバイスのベンダーによって割り当てられることができる。ＩＢデバイスのＧＵＩＤは、ネットワークインターフェイスカードのメディアアクセス制御（ＭＡＣ）アドレスのように、デバイスにハードコーディングすることができる。ＧＵＩＤを用いて、ＩＢレイヤ３（Ｌ３）アドレスであるグローバル識別子（ＧＩＤ）を形成することができる。

【0030】

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

【0031】

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

【0032】

Ｐ＿Ｋｅｙは、制限付きまたは正規の、２つのタイプのパーティションメンバーシップのいずれかを指定することができる。Ｐ＿Ｋｅｙの上位ビットは、自身のＰ＿ＫｅｙテーブルにＰ＿Ｋｅｙを有するＨＣＡのメンバーシップのタイプを指定するために用いられる。値１は正規メンバーを示し、値０は制限付きメンバーを示す。制限付きパーティションメンバーは、他の制限付きメンバーからのパケットを受け入れることはできない。ただし、他のすべての組み合わせのメンバーシップタイプ間での通信は許可される。

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

ＩＢは３つの異なるタイプのアドレスを用いる。第１のタイプのアドレスは１６ビットのローカル識別子（ＬＩＤ）である。少なくとも１つの固有のＬＩＤは、ＳＭによって各々のＨＣＡポートおよび各々のスイッチに割当てられる。ＬＩＤはサブネット内のトラフィックをルーティングために用いられる。ＬＩＤが１６ビット長であるので、６５５３６個の固有のアドレス組合せを構成することができ、そのうち４９１５１個（０×０００１－０×ＢＦＦＦ）だけをユニキャストアドレスとして用いることができる。結果として、入手可能なユニキャストアドレスの数は、ＩＢサブネットの最大サイズを定義することとなる。第２のタイプのアドレスは、製造業者によって各々のデバイス（たとえば、ＨＣＡおよびスイッチ）ならびに各々のＨＣＡポートに割当てられた６４ビットのグローバル一意識別子（ＧＵＩＤ）である。ＳＭは、ＨＣＡポートに追加のサブネット固有ＧＵＩＤを割当ててもよく、これは、ＳＲ－ＩＯＶが用いられる場合に有用となる。第３のタイプのアドレスは１２８ビットのグローバル識別子（ＧＩＤ）である。ＧＩＤは有効なＩＰｖ６ユニキャストアドレスであり、少なくとも１つが各々のＨＣＡポートに割当てられている。ＧＩＤは、ファブリックアドミニストレータによって割当てられたグローバルに固有の６４ビットプレフィックスと各々のＨＣＡポートのＧＵＩＤアドレスとを組合わせることによって形成される。

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【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】

仮想デュアルポートルータ
一実施形態に従うと、デュアルポートルータアブストラクション（dual port router abstraction）は、ＧＲＨ（グローバルルートヘッダ（global route header））からＬＲ
Ｈ（ローカルルートヘッダ（local route header））への変換を、通常のＬＲＨベースのスイッチングの実行に加えて行なう機能を有するスイッチハードウェア実装に基づいてサブネット間ルータ機能を規定することを可能にする簡単な方法を提供することができる。

【0102】

一実施形態に従うと、仮想デュアルポートルータは、対応するスイッチポートの外部で論理的に接続することができる。この仮想デュアルポートルータは、サブネットマネージャ等の標準管理エンティティに対しインフィニバンド規格に準拠したビューを提供することができる。

【0103】

一実施形態に従うと、デュアルポートルータモデルは、異なるサブネットを、各サブネットがサブネットへの進入（ingress）経路におけるパケット転送とアドレスマッピング
とを完全に制御し、かつ、間違って接続されたサブネットのうちいずれのサブネット内のルーティングおよび論理的接続にも影響を与えないように、接続できることを、示している。

【0104】

一実施形態に従うと、間違って接続されたファブリックを含む状況において、仮想デュアルポートルータアブストラクションを使用することにより、サブネットマネージャおよびＩＢ診断ソフトウェア等の管理エンティティが、遠隔サブネットへの意図しない物理的接続の存在下で、正しく作用するようにすることもできる。

【0105】

図１１は、一実施形態に従う、高性能コンピューティング環境における２つのサブネッ
ト間の相互接続を示す。仮想デュアルポートルータを用いて構成する前に、サブネットＡ
１１０１内のスイッチ１１２０を、スイッチ１１２０のスイッチポート１１２１を通し、物理接続１１１０を介して、サブネットＢ １１０２内のスイッチ１１３０に、スイッチ１１３０のスイッチポート１１３１を通して接続することができる。このような実施形態において、スイッチポート１１２１および１１３１の各々は、スイッチポートとしてもルータポートとしても機能することができる。

【0106】

一実施形態に従うと、この構成の問題は、インフィニバンドサブネット内のサブネットマネージャ等の管理エンティティが、スイッチポートでもありルータポートでもある物理ポートを区別できないことである。このような状況において、ＳＭは、スイッチポートを、このスイッチポートに接続されたルータポートを有するものとして扱うことができる。しかしながら、スイッチポートがたとえば物理リンクを介して別のサブネットマネージャを有する別のサブネットに接続されている場合、サブネットマネージャはディスカバリメッセージを物理リンクに送ることができる。しかしながら、このようなディスカバリメッセージは他方のサブネットでは許可されない。

【0107】

図１２は、一実施形態に従う、高性能コンピューティング環境におけるデュアルポート仮想ルータ構成を介した２つのサブネット間の相互接続を示す。

【0108】

一実施形態に従うと、構成後に、デュアルポート仮想ルータ構成を、サブネットマネージャの責任であるサブネットの端部を示す適切なエンドノードが、サブネットマネージャにわかるように、提供することができる。

【0109】

一実施形態に従うと、サブネットＡ １２０１内のスイッチ１２２０におけるスイッチポートは、仮想リンク１２２３を介して仮想ルータ１２１０内のルータポート１２１１に接続（すなわち論理的に接続）することができる。仮想ルータ１２１０（たとえばデュアルポート仮想ルータ）は、実施形態ではスイッチ１２２０の外部にあるものとして示されているが、論理的にはスイッチ１２２０の中に含めることができ、第２のルータポートであるルータポートＩＩ １２１２も含み得る。一実施形態に従うと、２つの端部を有し得る物理リンク１２０３は、サブネットＡ １２０１を、サブネットＢ １２０２に、物理リンクの第１の端部を介し、物理リンクの第２の端部を介し、ルータポートＩＩ １２１２を介し、サブネットＢ １２０２内の仮想ルータ１２３０に含まれるルータポートＩＩ
１２３２を介して、接続することができる。仮想ルータ１２３０はさらに、仮想リンク１２３３を介してスイッチ１２４０上のスイッチポート１２４１に接続（すなわち論理的に接続）することができるルータポート１２３１を含み得る。

【0110】

一実施形態に従うと、サブネットＡ上のサブネットマネージャ（図示せず）は、仮想ルータ１２１０上のルータポート１２１１を、当該サブネットマネージャが制御するサブネットの終点として検出することができる。デュアルポート仮想ルータアブストラクションは、サブネットＡ上のサブネットマネージャが、サブネットＡを通常のやり方で（たとえばインフィニバンド規格に規定されているように）扱うことを可能にする。サブネット管理エージェント（subnet management agent）レベルにおいて、デュアルポート仮想ルー
タアブストラクションを提供して通常のスイッチポートがＳＭにわかるようにし、その後、ＳＭＡレベルにおいて、当該アブストラクションを提供してこのスイッチポートに接続されている別のポートが存在しこのポートがデュアルポート仮想ルータ上のルータポートとなるようにすることができる。ローカルＳＭでは、従来のファブリックトポロジーを引続き使用することができ（このトポロジーにおいてＳＭはポートを標準スイッチポートとみなす）、したがって、ＳＭはルータポートをエンドポートとみなす。物理的接続は、２つの異なるサブネット内のルータポートとしても構成されている２つのスイッチポート間で行なうことができる。

【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】

一実施形態によれば、いくつかの追加のSMA/PortInfo（ポート情報）属性を含めることができる。

【0159】

一実施形態によれば、「Homogenous Fabric Attributes（同種ファブリック属性）」をサポートするためのポート機能をサポートすることができる。この属性のデフォルト値は偽である。それは、リンクアップでサポートＳＭＡにより真にセットされることができる。真にセットされると、サポートマスターＳＭが、関連するＳＭＡプロパティを更新してもよい。

【0160】

一実施形態によれば、「HomogeneousSubnet（同種サブネット）」フラグをサポートす
ることができる。このフラグのデフォルト値は偽とすることができる。このフラグは、このローカルポートから潜在的に見えるローカルサブネット内のすべてのエンドポートが同じパスプロパティを有し、すべての中間リンクが同じプロパティをサポートする場合に、サポートマスターＳＭによって設定されることができる。真にセットされると、ローカルＩＢクライアントは、ローカルポートプロパティから、関連するパスプロパティを安全に導出することができる。

【0161】

一実施形態によれば、「SemiHomogeneousSubnet（準同種サブネット）」フラグをサポ
ートすることができる。このフラグのデフォルト値は偽とすることができる。このフラグは、中間リンクが、常に、ローカルポートがサポートする値とローカルポートから見えるローカルサブネット内のピアポートがサポートする値との間の最小値と同じパスプロパティをサポートする場合に、サポートマスターＳＭによって設定されることができる。フラグの値が真にセットされている場合、ローカルポートは、関連するピアポートと直接、ネゴシエーションに基づいて、パスプロパティを判断することができる。

【0162】

一実施形態によれば、有効フラグ（真／偽）、ＭＴＵ（法的ＭＴＵ値）、レート（法的レート値）の「SubnetGlobalMinimalPathParameters（サブネットグローバル最小パスパ
ラメータ）」レコードをサポートすることができる。これは、サポートマスターＳＭによって、このローカルポートから潜在的に見えるローカルサブネット内の任意のエンドポートおよび任意の中間リンクによってサポートされる最小値に設定することができる。真にセットされると、ローカルＩＢクライアントは、ローカルサブネット内の通信にこれらのパスプロパティを用いることを選択することができる。

【0163】

一実施形態によれば、「HomogeneousFabric（同種のファブリック）」フラグをサポー
トすることができる。このフラグのデフォルト値は偽とすることができる。このフラグは、ローカルポートから潜在的に見えるすべてのエンドポートが同じパスプロパティを有し、すべての中間リンクが同じプロパティをサポートする場合に、サポートマスターＳＭによって設定されることができる。真にセットされると、ローカルＩＢクライアントはローカルポートプロパティからすべてのパスプロパティを安全に導出することができる。

【0164】

一実施形態によれば、「SemiHomogeneousFabric（準同種ファブリック）」フラグをサ
ポートすることができる。このフラグのデフォルト値は偽とすることができる。このフラグは、中間リンクが、常に、ローカルポートがサポートする値とローカルポートから見えるピアポートがサポートする値との間の最小値と同じパスプロパティをサポートする場合に、サポートマスターＳＭによって設定されることができる。真にセットされると、ローカルＩＢクライアントは、直接、関連するピアポートと、ネゴシエーションに基づいて、パスプロパティを判断することができる。

【0165】

一実施形態によれば、「FabricGlobalMinimalPathParameters（ファブリックグローバ
ル最小パスパラメータ）」‐有効フラグ（真／偽）、ＭＴＵ（法的ＭＴＵ値）、レート（法的レート値）のレコードをサポートすることができる。これは、サポートマスターＳＭによって、このローカルポートから潜在的に見える任意のエンドポートおよび中間リンクによってサポートされる最小値に設定することができる。真にセットされると、ローカルＩＢクライアントは、通信にこれらのパスプロパティを用いることを選択することができる。

【0166】

図１９は、一実施形態による、高性能コンピューティング環境においてＳＡアクセスの必要性を低減するために同種のファブリック属性をサポートするシステムを示す。

【0167】

一実施形態によれば、図１９は、複数のノード、ノードＡ～ノードＥ、１９１０～１９１４を含む簡略化されたインフィニバンドファブリックを示し、それらは、多数のスイッチ１９０２およびサブネットマネージャ／サブネットアドミニストレータ１９０１を含むＩｎｆｉｎｉＢａｎｄファブリック１９００を介して（それぞれ）ホストチャネルアダプタ１９２０～１９２４を介して相互接続される。

【0168】

一実施形態によれば、サブネットマネージャ／サブネットアドミニストレータ１９０１は、複数のホスト（例えば、ノードＡ～Ｅ）および複数のスイッチ１９０２が同じ機能セットをサポートすると判断することができる。複数のホストおよび複数のスイッチが同じ機能セットをサポートすると判断すると、サブネットマネージャは、フラグＡ（図ではフラグＡを含む円として表示）などのＳＭＡフラグを設定する。このフラグはある状態をホストチャネルアダプタポートごとに設定することができることを示す。フラグＡは、上述の同種のファブリック属性などの１つ以上の属性を含むことができる。フラグＡのデフォルト値は偽にセットされることができ、それは、さまざまなポートが同じ機能セットをサポートすると判断されると、ＳＡ／ＳＭによって真に変更することができる。

【0169】

一実施形態によれば、ＳＡ／ＳＭは、ＩＢファブリック内の異なるポート間およびＨＣＡポートで同じである機能セットを判断することができる。この機能セットは、サポートされるデータレート、ＭＴＵ（最大伝送単位）、サポートされるリンク幅、サポートされるリンク速度、およびサポートされる拡張リンク速度のセットで構成されるが、これらに限定されない。（実施形態では、異なるリンク速度および幅の組み合わせが同じデータレートを表してもよいことに留意されたい。したがって、パス情報の観点からは、レートのみが関係する。ただし、ＳＭはすべての速度と幅との組み合わせを相関させて、関係するレートセットを判断する必要がある。)
一実施形態によれば、フラグＡは、「Homogenous Fabric Attributes」をサポートするためにポート機能を反映／含むことができ、サポートされることができる。そのような状況におけるフラグＡのデフォルト値は偽である。それは、リンクアップでサポートＳＭＡにより真にセットされることができる。真にセットされると、サポートマスターＳＭが、関連するＳＭＡプロパティを更新してもよい。

【0170】

一実施形態によれば、フラグＡは「HomogeneousSubnet」フラグを反映／含むことがで
きる。このフラグのデフォルト値は偽とすることができる。このフラグは、ローカルポートから潜在的に見えるローカルサブネット内のすべてのエンドポートが同じパスプロパティ（たとえば、ＭＴＵ、サポートされるデータレート）を有し、すべての中間リンクが同じプロパティをサポートする場合に、サポートマスターＳＭによって設定されることができる。真にセットされると、ローカルＩＢクライアントは、従来のＩＢファブリックよりもＳＡへの要求が少ない状態で、ローカルポートプロパティから関連するパスプロパティを安全に導出することができる。

【0171】

一実施形態によれば、フラグＡは、「SemiHomogeneousSubnet」フラグを反映／含むこ
とができる。このフラグのデフォルト値は偽である。このフラグは、エンドノード（ローカルポートおよびリモートポート）間の中間リンクが、ローカルポートがサポートする値とローカルポートサポートから見えるローカルサブネット内のピアポートがサポートする値との間の最小値と同じパスプロパティをサポートする場合に、サポートマスターＳＭによって設定されることができる。フラグの値が真にセットされると、ローカルポートは、直接、関連するリモートポートと、ネゴシエーションに基づいて、パスプロパティを判断することができる。

【0172】

一実施形態によれば、フラグＡは、有効フラグ（真／偽）、ＭＴＵ（法的ＭＴＵ値）、レート（法的レート値）の「SubnetGlobalMinimalPathParameters」レコードを反映／含
み、サポートされることができる。これは、サポートマスターＳＭによって、このローカルポートから潜在的に見えるローカルサブネット内の任意のエンドポートおよび任意の中間リンクによってサポートされる最小値に設定することができる。真にセットされると、ローカルＩＢクライアントは、ローカルサブネット内の通信にこれらのパスプロパティを用いることを選択することができる。

【0173】

一実施形態によれば、フラグＡは、「HomogeneousFabric」フラグを反映／含むことが
でき：このフラグのデフォルト値は偽とすることができる。このフラグは、ローカルポートから潜在的に見えるすべてのエンドポート（ローカルポートのサブネット外のものを含む）が同じパスプロパティを有し、すべての中間リンクが同じプロパティをサポートする場合に、サポートマスターＳＭによって設定されることができる。真にセットされると、ローカルＩＢクライアントはローカルポートプロパティからすべてのパスプロパティを安全に導出することができる。

【0174】

一実施形態によれば、フラグＡは、「SemiHomogeneousFabric」フラグを反映／含むこ
とができる。このフラグのデフォルト値は偽とすることができる。このフラグは、中間リ
ンクが、常に、ローカルポートがサポートする値とローカルポートから見えるピアポートがサポートする値との間の最小値と同じパスプロパティをサポートする場合に、サポートマスターＳＭによって設定されることができる。真にセットされると、ローカルＩＢクライアントは、直接、関連するピアポートと、ネゴシエーションに基づいて、パスプロパティを判断することができる。

【0175】

一実施形態によれば、フラグＡは、「FabricGlobalMinimalPathParameters」フラグを
反映／含むことができる。このフラグは、有効フラグ（真／偽）、ＭＴＵ（法的ＭＴＵ値）、レート（法的レート値）のレコードを含むことができ、サポートされることができる。これは、サポートマスターＳＭによって、このローカルポートから潜在的に見える任意のエンドポートおよび任意の中間リンクによってサポートされる最小値に設定することができる。真にセットされると、ローカルＩＢクライアントは、通信にこれらのパスプロパティを用いることを選択することができる。

【0176】

図２０は、一実施形態による、高性能コンピューティング環境においてＳＡアクセスの必要性を低減するために同種のファブリック属性をサポートするシステムを示す。

【0177】

より詳細には、この図は、ノード１ ２０１０、ノード２ ２０２０、およびノード３
２０３０を含むいくつかのノードを備える例示的なサブネットを示し、各ノードはホストチャネルアダプタ、すなわちＨＣＡ１ ２０１１、ＨＣＡ２ ２０２１、およびＨＣＡ３ ２０３１を介して、切り換えられたファブリックに接続される。ノードは、それぞれのＨＣＡを介して、スイッチ１ ２０４０やスイッチ２ ２０４１などの多数のスイッチを介して相互接続される。

【0178】

一実施形態によれば、サブネットの各メンバー（ＨＣＡおよびスイッチ）はすべて同じ「タイプ」を含むことができ、これらのサブネットメンバーの各々上の各ポートは、同じ機能、例えばサポートされるデータレート、ＭＴＵ（最大伝送単位）、サポートされるリンク幅、サポートされるリンク速度、およびサポートされる拡張リンク速度などをサポートすることを意味する。

【0179】

図２１は、一実施形態による、高性能コンピューティング環境においてＳＡアクセスの必要性を低減するために同種のファブリック属性をサポートするシステムを示す。

【0180】

より詳細には、この図は、ノード１ ２１１０、ノード２ ２１２０、およびノード３
２１３０を含むいくつかのノードを備える例示的なサブネットを示し、各ノードはホストチャネルアダプタ、すなわちＨＣＡ１ ２１１１、ＨＣＡ２ ２１２１およびＨＣＡ３
２１３１を介して、切り替えられたファブリックに接続される。ノードは、それぞれのＨＣＡを介して、スイッチ１ ２１４０やスイッチ２ ２１４１などの多数のスイッチを介して相互接続される。

【0181】

一実施形態によれば、サブネットの異なるメンバー（ＨＣＡおよびスイッチ）は異なる「タイプ」を含むことができ、同じタイプのサブネットのメンバーは同じ機能セットをサポートするが、異なるタイプのメンバーは同じ機能セットをサポートしないことを意味する。

【0182】

たとえば、図のタイプＡのスイッチのホストチャネルアダプタは第１の最大データレートおよび第１の最大伝送単位をサポートし、タイプＢのホストチャネルアダプタおよびスイッチは同じ第１の最大データレートおよび異なる第２の最大伝送単位をサポートする。このような状況では、フラグ、「SemiHomogeneousSubnet」フラグは、エンドノード（ロ
ーカルポートおよびリモートポート）間の中間リンクが、ローカルポートがサポートする
値とローカルポートから見えるローカルサブネット内のピアポートがサポートする値との間の最小値と同じパスプロパティをサポートする場合に、サブネットマネージャによって設定されることができる。フラグの値が真にセットされると、ローカルポートは、直接、関連するリモートポートと、ネゴシエーションに基づいて、パスプロパティを判断することができる。

【0183】

図２２は、一実施形態による、高性能コンピューティング環境においてＳＡアクセスの必要性を低減するために同種のファブリック属性をサポートするシステムを示す。

【0184】

より具体的には、この図は、ノード１ ２２１０、ノード２ ２２２０、ノード３ ２２３０、ノード４ ２２１５、ノード５ ２２２５、およびノード６ ２２３５を含む複数のノードを備える例示的なサブネットを示しており、各ノードは、ホストチャネルアダプタ、つまりＨＣＡ１ ２２１１、ＨＣＡ２ ２２２１、およびＨＣＡ３ ２２３１、ＨＣＡ４ ２２１６、ＨＣＡ５ ２２２６、およびＨＣＡ６ ２２３６を介して、切り替えられたファブリックに接続される。ノードは、それぞれのＨＣＡを介して、スイッチ１ ２２４０、スイッチ２ ２２４１、スイッチ３ ２２４２、スイッチ４ ２２４３、スイッチ５ ２２４４、スイッチ６ ２２４５などの多数のスイッチを介して相互接続される。

【0185】

一実施形態によれば、スイッチは、いくつかのレベルで配置することができる。ここでは、スイッチは２つのレベルに配置され、レベル０はスイッチ１～４を含み、レベル１はスイッチ５～６を含む。

【0186】

一実施形態によれば、サブネットの異なるメンバー（ＨＣＡおよびスイッチ）は異なる「タイプ」を含むことができ、同じタイプのサブネットのメンバーは同じ機能セットをサポートするが、異なるタイプのメンバーは同じ機能セットをサポートしないことを意味する。たとえば、「タイプＢ」のスイッチおよびＨＣＡは、「タイプＡ」のスイッチおよびＨＣＡよりも高い能力であることができる（つまり、より大きなＭＴＵ、最大データレート、リンク幅などをサポートすることができる）。

【0187】

一実施形態によれば、次に、サブネットマネージャは、いくつかの異なるパスに沿って進むことができる。

【0188】

一実施形態では、サブネットマネージャは、「タイプＢ」のすべてのスイッチおよびＨＣＡが単一のサブネットに属し、「タイプＡ」に属するスイッチおよびＨＣＡが異なるサブネットに属すると判断することができる。次に、ＳＭは「サブネットＢ」内の各ポートにHomogenousSubnetフラグでフラグを立て、「サブネットＡ」内の各ポートに同様にフラグを立てることができる。

【0189】

ある実施形態では、サブネットマネージャは、「SemiHomogeneousSubnet」フラグを設
定することができる。これは、エンドノード（ローカルポートおよびリモートポート）間の中間リンクが、ローカルポートがサポートする値とローカルポートから見えるローカルサブネット内のピアポートがサポートする値との間の最小値と同じパスプロパティをサポートするからである。フラグの値が真にセットされると、ローカルポートは、直接、関連するリモートポートと、ネゴシエーションに基づいて、パスプロパティを判断することができる。

【0190】

一実施形態によれば、サブネットマネージャは、有効フラグ（真／偽）、ＭＴＵ（法的ＭＴＵ値）、レート（法的レート値）の「SubnetGlobalMinimalPathParameters」レコー
ドを設定することができ、サポートされることができる。これは、サポートマスターＳＭ
によって、ローカルポートから潜在的に見えるローカルサブネット内の任意のエンドポートと任意の中間リンクとでサポートされる最小値に設定されることができる。真にセットされると、ローカルＩＢクライアントは、ローカルサブネット内の通信にこれらのパスプロパティを用いることを選択することができる。

【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】

一実施形態によれば、様々なPortInfo（ポート情報）属性を定義することができる。
一実施形態によれば、そのような属性の１つは、「AllSubnetLocalChannelAdapterLIDsUsable（すべてのサブセットローカルチャネルアダプタＬＩＤ使用可能）」フラグとすることができる。このフラグは真／偽フラグにすることができ、デフォルトで偽にセットされる。このフラグは、ローカルポートから潜在的に見えるローカルサブネット内のＣＡ（チャネルアダプタ）ポートに関連付けられるすべてのＬＩＤが有効なＤＬＩＤを表す場合に、サポートマスターＳＭによって設定されることができる。真の場合、ローカルＩＢクライアントは、ローカルサブネットのリモートＣＡポートと通信するときに、リモートＣＡポートから受信した任意のソースＬＩＤを宛先ＬＩＤとして用いることができる。

【0216】

一実施形態によれば、そのような属性の１つは、「RouterSourceLIDsReversible（ルータソースＬＩＤ可逆）」フラグであることができる。このフラグは真／偽フラグにすることができ、デフォルトで偽にセットされる。このフラグは、リモートサブネットのエンドポートからパケットを転送するときにローカルサブネットのルータポートによって生成されるすべてのソースＬＩＤを用いてリモートサブネットの関連のエンドポートに到達することができる場合に、サポートマスターＳＭによって、設定されることができる。真の場合、ローカルＩＢクライアントは、リモートサブネットのリモートＣＡポートと通信するときに、ＣＡポートから受信した任意のパケットのソースＬＩＤを宛先ＬＩＤとして用いることができる。

【0217】

一実施形態によれば、新たに定義された様々な通信管理プロトコルの追加を提供することができる。

【0218】

一実施形態によれば、そのような方法の１つは、新たな通信管理（ＣＭ）方法（メッセージタイプ）である「PortAndNodeAttributeRequestMessage（ポートおよびノード属性要求メッセージ）」とすることができる。メッセージには、送信ポートが表す最大パスパラ
メータ（レート、ＭＴＵなど）、および送信ポートに関する追加情報（プラットフォーム固有の情報も含めることができる）が含まれる。この方法は、ＬＩＤが既知であるリモートポートへの他の通信を開始する前に、ＳＡパス要求のピアツーピアベースの置換として用いることができる。ＳＡへのパスクエリと同様に、リモートポートが依然として利用可能な限り、受信した情報をキャッシュし、複数の接続にわたって再利用することができる。

【0219】

一実施形態によれば、そのような方法の１つは、新たなＣＭメソッド（メッセージタイプ）である「PortAndNodeAttributeResponseMessage（ポートおよびノード属性応答メッ
セージ）」とすることができる。メッセージには、応答ポートが表す最大パスパラメータ（レート、ＭＴＵなど）、および応答ポートに関する追加情報（プラットフォーム固有の情報も含めることができる）が含まれる。ＳＡへのパスクエリと同様に、リモートポートが依然として利用可能な限り、受信した情報をキャッシュし、複数の接続にわたって再利用することができる。

【0220】

図２５は、高性能コンピューティング環境で同種のファブリック属性に関するアドレス解決プロトコル（ＡＲＰ）応答およびピアツーピアネゴシエーションから導出されたパスレコードを提供するシステムを示す。

【0221】

一実施形態によれば、この図は、複数のノード、ノードＡ～ノードＥ、２５１０～２５１４を含む簡略化されたＩｎｆｉｎｉＢａｎｄファブリックを示し、複数のノードは、多数のスイッチ２５０２およびサブネットマネージャ２５０１を備えるＩｎｆｉｎｉＢａｎｄファブリック２５００を通って（それぞれ）ホストチャネルアダプタ２５２０～２５２４を介して相互接続される。

【0222】

一実施形態によれば、サブネットマネージャ２５０１は、複数のホスト（例えば、ノードＡ～Ｅ）および複数のスイッチ２５０２が同じ機能セットをサポートすることを判断するように構成され得る。複数のホストおよび複数のスイッチが同じ機能セットをサポートすると判断すると、サブネットマネージャは、フラグＡ（図ではフラグＡを含む円として表示）などのＳＭＡフラグを設定する。このフラグはある状態をホストチャネルアダプタポートごとに設定することができることを示す。フラグＡは、上述の同種のファブリック属性などの１つ以上の属性を含むことができる。

【0223】

一実施形態では、パケット２５３０をリモートポートから受信することができ、そのパケットはソースＬＩＤおよびソースＧＩＤを含む。リモートポートアドレス情報を同種のファブリック属性と組み合わせて、完全なパスレコード２５３５を判断することができる。

【0224】

一実施形態によれば、マルチサブネットファブリックの場合（すなわち、パケットがリモートサブネットから到着する場合）、ＧＩＤ情報は依然としてＩＰｏＩＢ ＡＲＰプロトコルによって十分に定義される。ただし、カプセル化ＩＢパケットのＳＬＩＤ情報は、元の送信元を定義しなくなり、パケットをローカルサブネットへの入力パスで転送したＩＢ‐ＩＢルータポートのＬＩＤを定義する。‐これは、元のマルチキャスト要求と後のユニキャスト応答との両方に適用される。

【0225】

実施形態によれば、依然として、全体的なサブネット間ルーティングがサブネット境界を越えた可逆的パスを許可する限り、ユニキャストトラフィックのＤＬＩＤとしてルータＳＬＩＤを用いると、依然として、完全なパスレコード情報が、同種のファブリックフラグからの情報との組み合わせで、提供される。次に、接続されているさまざまなサブネットにおいてＳＭ間で同種のファブリックフラグを同期させる必要があるであろう。

【0226】

図２６は、同種のファブリック属性に基づいてＡＲＰ応答およびピアツーピアネゴシエーションからパスレコードを導出する方法のフローチャートである。

【0227】

より具体的には、この図は、一実施形態による、リモートノードからの、ファブリックの最小／最大値との相関を含む、着信ＡＲＰ要求および応答からＧＩＤおよびＬＩＤを判断する方法のフローチャートを示す。

【0228】

一実施形態によれば、ステップ２６０１で、方法を開始することができる。
一実施形態によれば、ステップ２６０２で、この方法は、着信ＡＲＰ要求または応答からソースＧＩＤ（グローバル識別子）およびソースＬＩＤ（ＳＬＩＤまたはソースローカル識別子）を取得することができる。

【0229】

一実施形態によれば、ステップ２６０３で、この方法は、ソースＧＩＤがローカルサブネットからのものであるかどうかを判断することができる。

【0230】

ソースＧＩＤがローカルサブネットからのものである場合、この方法は、ステップ２６０４で、ローカルポートから潜在的に見えるローカルサブネット内のＣＡ（チャネルアダプタ）ポートに関連付けられたすべてのＬＩＤが有効なＤＬＩＤ（上記の「AllSubnetLocalChannelAdapterLIDsUsable」フラグ）を表わす旨を、ローカルマスターＳＭによって設定されたフラグが示す、とローカル拡張ポート情報が示すかどうかを判断することができる。

【0231】

そのような判断が行われた場合、一実施形態によれば、ステップ２６０６で、この方法は、そのような判断が受信したソースＬＩＤをリモートノードの宛先ＬＩＤとして用いることができる旨を記録することができることを、記録することができる。

【0232】

そのような判断が行われない場合、一実施形態によれば、ステップＵ０５で、この方法は、リモートノードの宛先ＬＩＤを判断するためにＳＡアクセスまたは他の追加情報が必要であることを記録することができる。

【0233】

ソースＧＩＤがローカルサブネットからのものではないと判断された場合、実施形態によれば、ステップ２６０７で、この方法は、拡張PortInfoがRouterSourceLIDsReversibleフラグ（またはリモートサブネットのエンドポートからパケットを転送するときにローカルサブネットのルータポートによって生成されるすべてのソースＬＩＤを、リモートサブネットの関連するエンドポートに到達するために用いることができることを表す、別のフラグ）が真であることを示すかどうかを判断することができる。

【0234】

そのような判断が行われる場合、実施形態によれば、ステップで２６０８で、この方法は、受信したソースＬＩＤをリモートノードの宛先ＬＩＤとして用いることができることを記録することができる。

【0235】

そのような判断が行われない場合、実施形態に従って、ステップ２６０９で、この方法は、リモートノードの宛先ＬＩＤを判断するためにＳＡアクセスまたはその他の追加情報が必要であることを記録することができる。

【0236】

図２７は、同種のファブリック属性に基づいて、ＡＲＰ応答およびピアツーピアネゴシエーションからパスレコードを導出する方法のフローチャートである。

【0237】

より具体的には、この図は、一実施形態による、ファブリックの最小値／最大値との相
関を含む、新たなＣＭタイプのメッセージ交換に基づくパス情報を構築する方法のフローチャートを示す。

【0238】

一実施形態によれば、ステップ２７０１で、方法を開始することができる。
一実施形態によれば、ステップ２７０２で、この方法は、同種ファブリックフラグが真にセットされていることをローカル拡張PortInfoが示すかどうかを判断することができる。

【0239】

一実施形態によれば、ステップ２７０３で、同種ファブリックフラグが真にセットされている場合、この方法は、ローカルPortInfo情報に基づいてパス情報属性を構築することができる。

【0240】

一実施形態によれば、ステップ２７０４で、同種ファブリックフラグが真にセットされていない場合、この方法は、準同種ファブリックフラグが真にセットされていることをローカル拡張PortInfoが示すかどうかを判断することができる。

【0241】

一実施形態によれば、ステップ２７０５で、準同種ファブリックフラグが真にセットされている場合、この方法は「PortandNodeAttributeReqeustMessage（ポートおよびノード属性要求メッセージ）」または「PortandNodeAttributeResponseMessage（ポートおよび
ノード属性応答メッセージ）」のいずれかを受信する。

【0242】

一実施形態によれば、PortandNodeAttributeRequestMessageは、送信ポートが表す最大パスパラメータ（レート、ＭＴＵなど）および送信ポートに関する追加情報（プラットフォーム固有の情報も含むことができる）を含むことができる。この方法は、ＬＩＤが既知であるリモートポートへの他の通信を開始する前に、ＳＡパス要求のピアツーピアベースの置換として用いることができる。ＳＡへのパスクエリと同様に、リモートポートが依然として利用可能な限り、受信した情報をキャッシュし、複数の接続にわたって再利用することができる。

【0243】

一実施形態によれば、「PortAndNodeAttributeResponseMessage」はＣＭメソッド（メ
ッセージタイプ）である。メッセージには、応答ポートが表す最大パスパラメータ（レート、ＭＴＵなど）、および応答ポートに関する追加情報（プラットフォーム固有の情報も含めることができる）が含まれる。ＳＡへのパスクエリと同様に、リモートポートが依然として利用可能な限り、受信した情報をキャッシュし、複数の接続にわたって再利用することができる。

【0244】

一実施形態によれば、ステップ２７０５でメッセージの一方または両方を受信した後、この方法は、ステップ２７０６で、ローカルPortInfo情報とリモートノードからメッセージで受信した情報との間の最小値に基づいてパス情報を構築することができる。

【0245】

一実施形態によれば、ローカル拡張PortInfoが、準同種ファブリックフラグが真であることを示さない場合、この方法は、ステップ２７０７で、ＳＡクエリまたは他の手段（例えば、ローカルPortInfoからの「FabricGlobalMinimalPathParameters」）を用いて、リ
モートノードの情報属性を取得することができる。

【0246】

図２８は、一実施形態による、パスレコードを導出する方法のフローチャートである。
実施形態によれば、ステップ２８１０で、この方法は、１つ以上のマイクロプロセッサにおいて、第１のサブネットを提供することができ、第１のサブネットは複数のスイッチを含み、複数のスイッチは少なくともリーフスイッチを含み、複数のスイッチの各々は、複数のスイッチポートのうちの少なくとも１つのスイッチポートを含み、第１のサブネッ
トは、さらに、複数のホストチャネルアダプタを含み、各ホストチャネルアダプタは、複数のホストチャネルアダプタポートのうちの少なくとも１つのホストチャネルアダプタポートを含み、複数のホストチャネルアダプタは１つ以上のスイッチを介して相互接続され、第１のサブネットは、さらに、複数のホストと、サブネットマネージャとを含み、サブネットマネージャは、複数のスイッチおよび複数のホストチャネルアダプタの一方で実行される。

【0247】

一実施形態によれば、ステップ２８２０で、この方法は、サブネットマネージャが、複数のホストチャネルアダプタポートのセットおよび複数のスイッチポートのセットが同じ機能セットをサポートすると判断することができる。

【0248】

一実施形態によれば、ステップ２８３０で、サブネットマネージャが複数のホストチャネルアダプタポートのセットおよび複数のスイッチポートのセットが同じ機能セットをサポートすると判断すると、サブネットマネージャはＳＭＡフラグを構成することができ、このフラグは、複数のホストチャネルアダプタポートおよび複数のスイッチポートの各々に、ある条件を設定することができることを示す。

【0249】

一実施形態によれば、ステップ２８４０で、リモートポートから、第１のサブネット内のスイッチ上のポートでソースＬＩＤおよびソースＧＩＤを含むパケットを受信することができる。

【0250】

一実施形態によれば、ステップ２８５０で、ソースＬＩＤおよびソースＧＩＤをＳＭＡフラグと組み合わせて完全なパスレコードを判断することができる。

【0251】

マルチキャストグループの作成および参加
マルチキャストグループは、管理ポリシー／アクションに基づいてファブリックアドミニストレータによって作成することができる。ファブリックアドミニストレータは、管理インターフェイスを用いて、マルチキャストグループの作成を促すことができる。このようなインターフェイスは、マルチキャストグループの定義に必要なパラメータを受け入れることができる。多くの場合、マルチキャストグループは上位プロトコル（ＵＬＰ）が用いるために作成される。これらのＵＬＰの一部は、ＩＢパーティションのコンテキストで作成されるマルチキャストグループを用い、ＩＢパーティションはＵＬＰのリンク境界を表す。一部の管理インターフェイスでは、ＩＢパーティションとの関連でマルチキャストグループを作成できるため、マルチキャストグループを特定のＩＢパーティションに関連付ける場合の管理オーバーヘッドが軽減される。たとえば、ＩＢパーティションが作成されると、作成されたＩＢパーティションのコンテキストでマルチキャストグループの自動作成を容易にするフラグを設定することができる（たとえば、Internet Protocol over InfiniBand （インフィニバンドを介するインターネットプロトコル(IPoIB) フラグ）。

【0252】

一実施形態によれば、リスティング１は、対応するＩＢパーティションのコンテキストで（およびそれを作成するための同じコマンド内で）ＩＰｏＩＢマルチキャストグループを作成するための管理インターフェイスコマンドを示す。リスティング１に示すように、「ｉｐｏｉｂ」フラグを用いると、作成中の「partition_name」パーティションのコンテキストでマルチキャストグループが作成される。

【0253】

【数1】

【0254】

上記のように、ＩＢパーティションに関連付けられるマルチキャストグループを用いるＵＬＰの１つの例は、 Internet Protocol over InfiniBand（ＩＰｏＩＢ）である。ＩＰｏＩＢは、特定のＩＢパーティションのコンテキストで作成されたＩＢマルチキャストグループであるブロードキャストグループを用いる。ブロードキャストグループはレガシーインターネットプロトコル（ＩＰ）サブネットでブロードキャストトラフィックをシミュレートするために用いられ、なぜならば、ＩＢアーキテクチャはブロードキャストトラフィックをサポートしていないからである。

【0255】

ＩＰｏＩＢは、ＩＢパーティションを用いてＩＰサブネットをシミュレートする（つまり、ＩＢパーティションは、ＩＰｏＩＢプロトコルからブロードキャストトラフィックのリンク境界を定義およびシミュレートする）。ブロードキャストグループに関連付けられるＩＢパーティションの各メンバーエンドポートは、ＩＰサブネットのシミュレートされたメンバーである。トラフィックは、ブロードキャスト（マルチキャスト）グループを介して、シミュレートされたＩＰサブネットの各メンバー（つまり、ＩＢパーティションメンバー）に「ブロードキャスト」される。パーティションのメンバーである各エンドポートは、そのパーティションのコンテキストにおいて定義されるブロードキャストグループのメンバーでもある。これにより、ＩＰプロトコルを用いるレガシーアプリケーションは、ＩＢサブネットを介してブロードキャストされるパケット（アドレス解決プロトコル（ＡＲＰ）パケットなど）を受信できる。

【0256】

マルチキャストグループがＩＢパーティションのコンテキストで定義される場合、マルチキャストグループのＭＧＩＤは、既知の規則に従ってアルゴリズムで作成することができる。マルチキャストグループが作成されるコンテキストのパーティションのＰ＿Ｋｅｙは、マルチキャストグループのＭＧＩＤに埋め込むことができる。ＭＧＩＤの作成時に、追加の規則に従うこともできる。たとえば、ブロードキャストＩＰｏＩＢマルチキャストグループの場合、特別な署名もＭＧＩＤに埋め込まれる。このような規則に従うことにより、ＩＢクライアントは、マルチキャストグループを定義するＭＧＩＤを導出するためにマルチキャストグループを定義するコンテキストのパーティションのＰ＿Ｋｅｙを知るだけで済む。

【0257】

マルチキャストグループは、エンドポートがＭＡＤをＳＭに送信して、新たなマルチキャストグループの作成を要求するときに、動的に作成することもできる。ＭＡＤは、新たなマルチキャストグループの定義／作成に用いる特定のパラメータを指定することができる。たとえば、ＭＡＤは有効なＭＧＩＤを指定することができる。代替的に、ＭＡＤはＭＧＩＤを未指定のままにすることができ、その場合、ＳＭは有効なＭＧＩＤを生成し、生成されたＭＧＩＤを新たに作成されたマルチキャストグループに割り当てることができる。新たなマルチキャストグループを作成する要求で指定することができるその他のパラメータには、P_Key、Q_Key、 Service Level（サービスレベル） (SL), FlowLabel（フローレベル）, TClass, JoinState（参加状態）およびPortGID（ポートＧＩＤ）が含まれる。

【0258】

新たなマルチキャストグループの作成を要求するＭＡＤは、ＩＢ仕様で定義されているサブネット管理クラスによって提供されるSubnAdmSet() メソッドを指定することができ
る。ＭＡＤは、MCMemberRecord（ＭＣメンバーレコード）属性をさらに指定することがで
き、上記のパラメータ（MGID、P_Key、Q_KEYなど）を指定することができる。

【0259】

一般に、新たなマルチキャストグループを作成する要求は、要求元のエンドポート（つまり、新たなマルチキャストグループの作成を要求するＭＡＤを送信するエンドポート）による、新たに作成されるマルチキャストグループに参加する暗黙的な要求として扱われ、ＳＭは、新たに作成されたマルチキャストグループに要求元のポートを含ませる。つまり、ＳＭは要求元のポートのＬＩＤを、要求元のポートと新たに作成されたマルチキャストグループのＭＧＩＤとの間の関連付けを作成する方法として用いる（つまり、ポートのＬＩＤはマルチキャスト処理にとって重要性はない）。

【0260】

従来は、既存のマルチキャストグループに参加するために、エンドポートはＳＭに参加要求を送信する。参加要求は、既存のマルチキャストグループの構成が既存のマルチキャストグループへの参加を要求しているポートの構成と互換性があるかどうかをＳＭが判断できるようにする他のパラメータとともに、既存のマルチキャストグループのＭＧＩＤを指定する。ＳＭは、要求元のポートの構成が既存のマルチキャストグループの構成と互換性があると判断した場合、要求元のポートのＬＩＤを既存のマルチキャストグループに追加する。つまり、ＳＭは、要求元のポートのＬＩＤを（たとえば、図１５に示すようなＳＡデータストアにおいて）既存のマルチキャストグループのＭＧＩＤと関連付ける。さらに、ＳＭは、マルチキャストパケットを送信するときにエンドポートで用いるためにＭＣＧに割り当てられたＭＬＩＤで要求元のエンドポートに応答する。

【0261】

エンドポートが既存のＭＣＧに参加した後、ＳＭは、マルチキャストグループに関連付けられている要求元のポートを含む、関連付けられたスパニングツリーを再生成する。さらに、更新されたＭＦＴ（新たに生成されたスパニングツリーによって更新される）は、要求元のポートのマルチキャストグループへの追加によって既存のＭＦＴが廃止されたスイッチに送信することができる。したがって、パケットのＤＬＩＤフィールドに既存のマルチキャストグループのＭＬＩＤを有するマルチキャストパケットが送信されると、要求元のポートは関連するマルチキャストグループのメンバーとして認識され、マルチキャストパケットのコピーが要求元のポートに配信される。

【0262】

図２９は、一実施形態による、マルチキャストグループ（ＭＣＧ）の作成および参加のためのフローチャートを示す。ステップ２９１０で、ＳＭは新たなＭＣＧを作成する要求を受信することができる。ステップ２９３０で、ＳＭは、第１のエンドポートから新たなＭＣＧに参加する要求を受信することができる。ステップ２９４０で、ＳＭは、第１のエンドポートのＬＩＤを新たなＭＣＧのＭＧＩＤと関連付けることができる。ステップ２９５０で、ＳＭは、新たなＭＣＧにおける第１のエンドポートのメンバーシップに基づいてスパニングツリーおよびＭ２９Ｔを生成することができる。ステップ２９６０で、ＳＭは、第２のエンドポートから新たなＭＣＧに参加する別の要求を受信することができる。ステップ２９７０で、ＳＭは、第２のエンドポートのＬＩＤを新たなＭＣＧのＭＧＩＤと関連付けることができる。ステップ２９８０で、ＳＭは新たなＭＣＧにおける第２のエンドポートのメンバーシップに基づいてスパニングツリーおよびＭＦＴを生成することができる。

【0263】

図２９からわかるように、エンドポートがＭＣＧに参加するたびに、ＳＭはＭＡＤを受信して処理し、関連付けを更新し、スパニングツリーを判断し、新たなＭＦＴを判断する。これは、多くのエンドポートが参加要求を送信する大規模なサブネットでは、特にサブネットの初期化時に、ＳＭ／ＳＡに対して多大なオーバーヘッドを生じる可能性がある。

【0264】

マルチキャストグループの作成および参加に関する上記のプロセスからわかるように、マルチキャストグループに含まれることになるすべてのエンドポートは、マルチキャスト
グループに参加するために、ＳＭ／ＳＡと対話する必要がある。さらに、新たなマスターＳＭがサブネットで選択されるたびに、どのエンドポートも、そのエンドポートがメンバーであるマルチキャストグループに再参加するという内在的な必要性があり、なぜならば、新たなＳＭが新たなＭＧＩＤをＭＬＩＤマッピングに割り当て得るからである。サブネット上のＳＲ‐ＩＯＶベースの仮想マシン展開の場合、複数のｖＰｏｒｔが各々同じタイプのＳＭ／ＳＡ要求（例えば、マルチキャストグループ参加要求）を物理的なエンドポートとして実行することになるため、ＳＭ／ＳＡが処理する必要がある要求トラフィックの量が増加する。

【0265】

その結果、サブネットの管理要件がこれらの要件を処理するＳＭの能力を超えて拡大する場合、（物理エンドポートおよび仮想エンドポートの両方で）密集したサブネットで問題が発生する可能性がある。特に、能力の低いＳＭ／ＳＡ実装例（たとえば、スイッチ管理インターフェイスに接続された低パフォーマンスプロセッサモジュールに基づく実装例）の場合、中程度のＳＡ要求負荷でも、ＳＭおよび全体としてシステムの両方について深刻なオーバーヘッドと効率の低下と遅延の増加とを引き起こし得る。

【0266】

高速フェールオーバーと復旧とが重要な高可用性（ＨＡ）システムの場合、遅延は問題を表す。特に、１秒未満のフェールオーバー時間が必要な場合、（ノード間の物理的な接続が失われない限り、）ファブリックノードが通常の動作および他の動作可能なノードとの通信を中断なく継続することができることが重要である。したがって、すべてのノードがＳＭ／ＳＡと対話する必要なくユニキャストトラフィックとマルチキャストトラフィックとの両方に対して既存のアドレスおよびパス情報を引き続き用いることができること、およびＳＭがファブリック内の障害のあるリンク（またはスイッチ）のために再ルーティングまたは再初期化を実行する必要がある場合に接続性の中断のみが生ずることが、望ましい。

【0267】

さらに、完全に機能するＨＣＡを有するハイエンドサーバに基づくＳＭ／ＳＡ実装例でも、ＳＡ通信に２５６バイトのＭＡＤを用いると、パフォーマンスおよびスケーラビリティが大幅に制限される。そのため、ＳＡ要求処理に対して最適なキャッシングおよび高性能ハードウェアを用いる場合でも、新たなマスターＳＭが選出されたときにマルチキャストメンバーシップを再登録（つまり、それに対する新たな参加要求を処理）する必要性は、動作可能なスイッチおよびリンクによって接続される動作可能なノード間の接続が中断する結果となり得る。

【0268】

したがって、ＩＢクライアントとＳＭ／ＳＡインフラストラクチャとの間の対話を最適化する必要がある。ローエンドの、スイッチが埋め込まれたＳＭ／ＳＡ実装を伴う小規中規模のシステムでは、ＳＡ要求を処理したり、またはそうでなければＩＢクライアントと（つまり、ディスカバリをこえて）通信したりする必要性を回避しながら（つまり、ＳＭＡレベルでのディスカバリおよび初期化動作を越えて）、サブネットの高速ディスカバリおよび初期化が必要である。よりハイエンドのＳＭ／ＳＡ実装を有するシステムの場合、最適なＩＢ通信メカニズムを利用し、‐非常に大規模なクラスタドメインでも‐スケーラビリティを提供し、大規模なマルチキャストストームを防止する階層実現例を有する能力を提供もする方法で関連情報をＳＭ／ＳＡ実装によってＩＢクライアントに配信するための処理が必要とされる。

【0269】

マルチキャストグループの作成、参加、削除、および参加解除の管理に関する既存の技術プロセスの改善は、ＳＭ／ＳＡのオーバーヘッドを克服し、ＳＭ／ＳＡ実装の効率を強化するのに役立ち得る。

【0270】

ＭＣＧに対するデュアルＭＬＩＤ割り当て
上記のように、ＩＢパーティションのコンテキストでマルチキャストグループを作成することができる。さらに、各パーティションメンバーは、制限付きメンバーまたは正規メンバーの２種類のうちの１つであることができる。ただし、マルチキャストグループメンバーシップを定義する場合、ＩＢ仕様では、正規パーティションメンバーと制限付きパーティションメンバーとを区別しない。したがって、ＭＬＩＤごとにわずか１つのルート（たとえば、わずか１つのスパニングツリー）しか判断されないため、所与のポートがどのようなタイプのパーティションメンバーであるかに関係なく、判断されたルートは、マルチキャストグループの各メンバーポートにマルチキャストパケットを配信しなければならない。

【0271】

ＭＬＩＤごとに１つのルートという制限があると問題が発生する可能性があり、なぜならば、ＩＢ仕様によれば、制限付きパーティションメンバーは他の制限付きパーティションメンバーからパケットを受け入れない場合があるためである。したがって、制限付きパーティションメンバーがマルチキャストパケットを送信すると、マルチキャストパケットは、パーティションの制限付きメンバーでもあるパーティション内の各受信ポートについてＰ＿Ｋｅｙアクセス違反を表わす。このようなＰ＿Ｋｅｙアクセス違反は、ＳＭに送信されるＰ＿Ｋｅｙ違反トラップの生成につながる可能性がある。

【0272】

ＩＢ仕様は、ここで、マルチキャストパケットが１つの制限付きパーティションメンバーから別のパーティションメンバーに転送される結果であるＰ＿Ｋｅｙアクセス違反は、Ｐ＿Ｋｅｙアクセス違反として（トラップ経由でＳＭに）報告する必要がないことを反映するが、一方で、この現代的な機能を提供しないレガシー実装例の重要なセットが依然として存在する。さらに、リンク容量がマルチキャストパケット自体で浪費され、それは、宛先ポートに転送されるべくサブネットリソースを使用した後、宛先ポートでドロップされるだけとなる。

【0273】

一実施形態によれば、Ｐ＿Ｋｅｙアクセス違反の上記の特別な処理の必要性を回避し、マルチキャストトラフィックに関して制限付きパーティションメンバー間の完全な分離を保証するために、２つのＭＬＩＤを単一のＭＣＧに割り当てることができる。第１のＭＬＩＤは、正規パーティションメンバーから正規パーティションメンバーおよび制限付きパーティションメンバーの両方に送信するために、割り当てられ、エンドポートによって用いられる（ここでは「正規パーティションメンバーＭＬＩＤ」と呼ぶ）。さらに、第２のＭＬＩＤは、制限付きパーティションメンバーから正規パーティションメンバーに送信するために、割り当てられ、エンドポートによって用いられる（ここでは「制限付きパーティションメンバーＭＬＩＤ」と呼ぶ）。このスキームを用いると、制限付きパーティションメンバーは、ＭＣＧ内の他の制限付きパーティションメンバーにマルチキャストパケットを送信することを回避することができる。

【0274】

一実施形態によれば、ＳＭは、マルチキャストグループのメンバーシップを要求したエンドポートにマルチキャストグループのＭＬＩＤを提供することを担う。エンドポートは、マルチキャストグループにマルチキャストパケットを送信するときに、ＳＭによって提供されるＭＬＩＤを用いる。さらに、要求元のエンドポートは、エンドポートがＳＭに参加を要求しているマルチキャストグループに関連付けられるＰ＿Ｋｅｙを提供することができる。Ｐ＿Ｋｅｙは、ＭＣＧ参加要求でＳＭに送信されるMCMemberRecord（MCメンバーレコード）の一部である。したがって、ＳＭは、エンドポートの参加要求からンドポートが参加を要求しているＭＣＧに関連付けられるＰ＿Ｋｅｙを判断することができる。ＳＭは、どのエンドポートがどのパーティションのメンバーであるか、およびポートが関連するパーティションの制限付きメンバーであるかまたは正規メンバーであるかについて、それの独自のポリシー情報を維持することもできる。

【0275】

ＳＭは、エンドポートが参加を要求しているＭＣＧに関連付けられるＰ＿ｋｅｙを判断すると、ＳＭは、要求元のエンドポートが、それが参加を要求しているＭＣＧに関連付けられるパーティションの正規メンバーであるかまたは制限付きメンバーであるかどうかを（判断されたＰ＿Ｋｅｙの上位ビットから）判断することができる。要求元のエンドポートがパーティションの正規メンバーであると判断された場合、ＳＭは正規パーティションメンバーＭＬＩＤをエンドポートに提供することができる。要求元のエンドポートがパーティションの制限付きメンバーである場合、ＳＭはエンドポートに制限付きパーティションメンバーＭＬＩＤを提供することができる。

【0276】

リスティング１の擬似コードは、一実施形態による、エンドポートによるＭＬＩＤの要求（ＭＣＧへの参加要求など）に応答するためのアルゴリズムを示す。

【0277】

【数2】

【0278】

図３０は、一実施形態による、エンドポートによるＭＬＩＤに対する要求（例えば、ＭＣＧへの参加の要求）に応答するためのフローチャートを示す。開始３００２で、エンドポートから参加要求を受信する。ステップ３００４で、要求元エンドポートのパーティションメンバータイプが判断される。判断３００６で、参加要求が正規パーティションメンバーからのものかどうかが判断される。参加要求が正規パーティションメンバーからのものであると判断された場合、制御はステップ３０１０に進み、応答ＭＬＩＤは、要求元のエンドポートが参加を要求したＭＣＧグループに割り当てられる正規パーティションメンバーＭＬＩＤの値にセットされる。参加要求が正規パーティションメンバーからのものではないと判断された場合、制御はステップ３００８に進み、応答ＭＬＩＤは、要求元のエンドポートが参加を要求したＭＣＧに割り当てられる制限付きパーティションメンバーＭＬＩＤの値にセットされる。ステップ３０１０または３００８のいずれかから、制御はステップ３０１２に進み、応答ＭＬＩＤは応答メッセージで要求元のエンドポートに送信される。

【0279】

図３０およびリスティング１に示すように、一実施形態によれば、ＳＭは、ＭＣＧに関連付けられたパーティションについての要求元エンドノードのパーティションメンバーシップに基づいてＭＣＧの正規パーティションメンバーＭＬＩＤまたは制限付きパーティションメンバーＭＬＩＤのいずれかをＭＣＧのメンバーシップを要求したエンドポートに提供することができる。このプロセスはエンドノードに対して完全に透過的であり、要求元のエンドノードのＳＭＡにおいてレガシーコードまたは属性を変更する必要はない。さらに、制限付きパーティションメンバーが正規ＭＬＩＤを用いて他の制限付きメンバーにパケットを転送しようとすると、それは有効なＰ＿Ｋｅｙアクセス違反となり、そのように報告する必要がある。このような違反は、一般に、エンドノードがパケットを生成して任意の宛先ＬＩＤ‐任意のユニキャストＤＬＩＤまたはマルチキャストＤＬＩＤ（つまりＭＬＩＤ）を含む‐に送信した結果である。ただし、送信されたパケットは送信元ポートに
対して有効なＰ＿Ｋｅｙ値しか表すことができず、送信Ｐ＿Ｋｅｙが宛先ポートに対して有効でない場合、パケットはＰ＿Ｋｅｙチェック後に破棄される。

【0280】

一実施形態によれば、ＳＭは、２つのＭＬＩＤ‐正規パーティションメンバーＭＬＩＤおよび制限付きパーティションメンバーＭＬＩＤ‐をＭＣＧに割り当てることができる。さらに、ＳＭ／ＳＡによって保存されるＭＣＧレコードは、正規パーティションメンバーＭＬＩＤ、制限付きパーティションメンバーＭＬＩＤ、正規パーティションメンバーＭＬＩＤのスパニングツリールート、制限付きパーティションのスパニングツリールート、両方のＭＬＩＤのメンバーノードのリスト、ＭＧＩＤ、関連するＰ＿Ｋｅｙなどのメタデータを含むことができる。

【0281】

ＭＣＧの正規パーティションメンバーＭＬＩＤおよび制限付きパーティションメンバーＭＬＩＤの両方を正しくルーティングするために、ＳＭは、正規パーティションメンバーＭＬＩＤ用に１つ、および制限付きパーティションメンバーＭＬＩＤ用に１つ、の２つのスパニングツリーを計算することができる。さらに、ＳＭは、判断された各スパニングツリーごとにすべての影響を受けたスイッチに対する関連のＭＬＩＤについてＭＦＴエントリの内容を判断し、更新されたＭＦＴを任意の影響を受けたサブネットスイッチに転送することができる。

【0282】

図３１は、一実施形態による、サブネット３１００内の制限付きパーティションメンバーＭＬＩＤについてスパニングツリーアルゴリズムを介して判断され得る例示的なマルチキャストパケットルートを示す。サブネット３１００には、ノード３１０１～３１０８が含まれる。ノード３１０１～３１０８には、それぞれＨＣＡ３１０９～３１１６が含まれる。さらに、ＨＣＡ ３１０９～３１１６は各々、ポート、すなわちポート３１１７～３１２４を含む。サブネット３１００のすべてのポートは、パーティション３１７０のメンバーである。同様に、サブネット３１００のすべてのポートはＭＣＧ３１６５のメンバーである。

【0283】

サブネット３１００では、マルチキャストグループ（ＭＣＧ）３１６５はＳＭ／ＳＡ３１６０によって定義される。デュアルＭＬＩＤがＭＣＧ３１６５に割り当てられている。正規パーティションメンバーＭＬＩＤ３１７２は、実線のブロック図形式で示される。制限付きパーティションメンバーＭＬＩＤ３１７４は、一点鎖線のブロック図形式で示される。ポート３１１８～３１１９ならびにポート３１２１および３１２３は、それらがＳＭ／ＳＡ３１６０から制限付きパーティションメンバーＭＬＩＤ３１７４を受信したこと（およびしたがって、パーティション３１７０の制限付きメンバーであること）を示すために、一点鎖線で描かれている。さらに、ポート３１１７、３１２０、３１２２、および３１２４は実線で示されており、それらがＳＭ／ＳＡ３１６０から正規パーティションメンバーＭＬＩＤ３１７２を受け取ったこと（したがって、パーティション３１７０の正規メンバーであること）を示す。

【0284】

図３１では、制限付きパーティションメンバーＭＬＩＤ３１７４のマルチキャストトラフィックの配信を処理するスパニングツリーに含まれるリンクが実線で示される。これは、パケットのＤＬＩＤとして制限付きパーティションメンバーＭＬＩＤを有するマルチキャストパケットの配信用に生成されたスパニングツリーがパーティションの正規メンバーにのみマルチキャストパケットを配信するからである。一実施形態によれば、ＳＭ／ＳＡ３１６０は、制限付きパーティションメンバーＭＬＩＤ３１７４のスパニングツリーを生成するときに、パーティション３１７０の各メンバー（ＭＣＧ３１６５のメンバーでもある）を判断し、ＤＬＩＤとして制限付きパーティションメンバーＭＬＩＤ３１７４を有するパケットをパーティション３１７０の判断された正規メンバーにのみ配信するスパニングツリーを判断することができる。このようにして、制限付きメンバーＰ＿Ｋｅｙを有す
るマルチキャストパケットは、パーティション３１７０の制限付きメンバーである他のポートに配信されない。したがって、Ｐ＿Ｋｅｙアクセス違反が引き起こされてＳＭ／ＳＡに送信されることはなく、リンクリソースは、最終的に配信ポートでドロップされるパケットで無駄にされない。

【0285】

さらに図３１を参照すると、制限付きパーティションメンバーＭＬＩＤ３１７４に対して判断されたスパニングツリーにリンク３１４２、３１４１、３１４３を含めることができる。さらに、それぞれエンドポート３１１７、３１２０、３１２２、および３１２４にサービスを提供するリンク３１２５、３１２８、３１３０、および３１３２も、制限付きパーティションメンバーＭＬＩＤ３１７４のスパニングツリーに含めることができる。したがって、制限付きパーティションメンバーＭＬＩＤ３１７４のスパニングツリーは、ＤＬＩＤとして制限付きパーティションメンバーＭＬＩＤ３１７４を有するマルチキャストパケットが、ＭＣＧ３１６５のメンバーおよびパーティション３１７０の正規メンバーの両方である各エンドポートにのみ配信されることを保証することができる。

【0286】

たとえば、ポート３１２１がマルチキャストパケットをサブネットに注入すると、スイッチ３１５２がそれを受信する。次に、スイッチ３１５２は、マルチキャストパケットのコピーをスパニングツリーで指定された各リンクに転送することができる。したがって、スイッチ３１５２は、受信したマルチキャストパケットのコピーをリンク３１４２、３１４１、および３１３０に転送することができる。この場合では、ポート３１２２はリンク３１３０を介してマルチキャストパケットのコピーを受信し、スイッチ３１５０はリンク３１４２を介してコピーを受信し、スイッチ３１５１はリンク３１４１を介してコピーを受信する。ここから、スイッチ３１５０もリンク３１４２から受信したマルチキャストパケットのコピーをリンク３１２５に転送することができる（ただし、スパニングツリーの一部ではないため、リンク３１２６には転送できない）。このパターンは、すべての正規パーティションメンバーポートがマルチキャストパケットのコピーを受信するまで、サブネット全体を通してスパニングツリーをたどって続行することができる。

【0287】

正規メンバーＭＬＩＤ３１７２のスパニングツリールートは、図３１には示されてはいない。これは、サブネット３１００のすべてのノードが（上記のとおり）ＭＣＧ３１６５のメンバーおよびパーティション３１７０のメンバーであるため、一実施形態によれば、ルートにはすべてのポート３１１７～３１２４が含まれるであろうからである。そうではあるが、ＳＭ／ＳＡ３１６０は、各ポート３１１７～３１２４が正規メンバーＭＬＩＤ３１７２のスパニングツリーに含まれるであろうことを除いて、上記と同じ方法で正規メンバーＭＬＩＤ３１７２のスパニングツリーを生成することができる。

【0288】

一実施形態によれば、ＳＭ／ＳＡ３１６０は、図３１に示されるスパニングツリーに基づいて、影響を受ける各スイッチ３１５０～３１５３のＭＦＴを生成することができる。生成されると、ＳＭ／ＳＡ３１６０はＭＦＴをスイッチ３１５０～３１５３に送信して、それぞれのスイッチで実装することができる。さらに、正規メンバーＭＬＩＤ３１７２用に生成されたスパニングツリーのＭＦＴを生成し、それぞれのスイッチによる実装のためにスイッチ３１５０～３１５３に送信することができる。これらのＭＦＴのそれぞれのセットは、図１７に関して上で説明したプロセスに従って生成することができる。

【0289】

一実施形態によれば、エンドポートは、ＳＭがデュアルＭＧＩＤをＭＣＧに割り当てたことを認識することができる。ＳＭがＭＣＧにデュアルＭＬＩＤを割り当てたことをエンドポートが認識すると、エンドポートはデュアルＭＬＩＤ間の区別を行うことができる。このような認識により、エンドポートは、エンドポートが対応するパーティションの正規メンバーであっても、マルチキャストパケットを関連するＭＣＧ内の他の正規パーティションメンバーにのみ転送するために、限定付きパーティションメンバーＭＬＩＤを用いる
ことができる。

【0290】

追加のプロパティを、たとえばPortInfo属性に追加して、ＭＣＧに割り当てられたデュアルＭＬＩＤを、エンドポートが認識し、利用できるようにすることができる。一実施形態によれば、そのようなプロパティの１つは、エンドポートが正規メンバーＭＬＩＤと制限付きメンバーＭＬＩＤとの区別をサポートするかどうかを示すことができる。たとえば、PortInfo属性に「DualMLIDAllocation（デュアルＭＬＩＤ割り当て）」インジケータを追加することができる。DualMLIDAllocationインジケータは、たとえば、ビットとすることができ、ハイにセットされると、エンドポートが正規メンバーＭＬＩＤと制限付きメンバーＭＬＩＤとの区別をサポートすることを示す、とすることができる。DualMLIDAllocationインジケータは、デフォルトで偽にセットすることができる（たとえば、ビットをローに設定することができる）。サポートするＨＣＡのＳＭＡは、リンクアップ／初期化中にDualMLIDAllocationインジケータを真にセットすることができる。真にセットした場合（たとえば、ハイにセットした場合）、サポートするＳＭは関連付けられるＳＭＡプロパティを更新することができる。

【0291】

別のそのようなプロパティは、実施形態に従って、サブネット内のＭＣＧにデュアルＭＬＩＤが割り当てられているかどうかを示すことができる。例示的なプロパティは、「DualMLIDAllocationInUse（デュアルＭＬＩＤ割り当て使用中）」インジケータである。DualMLIDAllocationInUseインジケータは、たとえば、ビットとすることができ、ビットをハイにセットすると、サポートするＳＭがサブネットにおいて定義されたマルチキャストグループにデュアルＭＬＩＤ（正規パーティションメンバー用に１つ、および制限付きパーティションメンバー用に１つ）を割り当てたことを示す、とすることができる。DualMLIDAllocationInUseインジケータは、デフォルトで偽にセットすることができる（たとえば
、ビットをローにセットすることができる）。ＳＭがサブネット内のＭＣＧにデュアルＭＬＩＤを割り当てている場合、サポートするＳＭはDualMLIDAllocationInUseインジケー
タを真にセットすることができる。

【0292】

一実施形態によれば、制限付きパーティションメンバーによる使用のための第２のＭＬＩＤの割り当ては、サブネットオーバーヘッドおよびトラフィックを低減するために、ある規則に従うことができる。たとえば、制限付きパーティションメンバーが用いる第２のＭＬＩＤは、正規パーティションメンバーが用いるために割り当てられたＭＬＩＤ値の（数値的に）後の次のＭＬＩＤ値として定義することができる。このようにして、サポートするエンドポートは、第２のＭＬＩＤの値を、ＳＭから実際に受信することなく、判断することができる。

【0293】

一実施形態によれば、たとえば、PortInfo属性のプロパティは、制限付きパーティションメンバーが使用する第２のＭＬＩＤの割り当てに関して、ＳＭがある規則に従うことを示すことができる。例示的なインジケータは、「ConsecutiveDualMLIDs（連続デュアルＭＬＩＤ）」インジケータであることができる。インジケータ（例：ConsecutiveDualMLIDs）は、たとえば、ビットとすることができ、ビットをハイにセットすると、制限付きパーティションメンバーが用いる第２のＭＬＩＤが正規パーティションメンバーが用いるために割り当てられたＭＬＩＤ値の（数値的に）後の次のＭＬＩＤ値として定義されることを示す、とすることができる。ConsecutiveDualMLIDsインジケータは、デフォルトで偽にセットすることができる（たとえば、ビットをローにセットすることができる）。サポートするＳＭが、正規パーティションメンバーが用いるために割り当てられたＭＬＩＤ値の（数値的に）後の次のＭＬＩＤ値として制限付きパーティションメンバーが用いるために第２のＭＬＩＤを割り当てる場合、サポートＳＭはConsecutiveDualMLIDsインジケータを真にセットすることができる。

【0294】

一実施形態によれば、サブネット内のＭＣＧへのデュアルＭＬＩＤ割り当てを認識し、かつデュアルＭＬＩＤが割り当てられたＭＣＧに関連付けられるパーティションの正規メンバーであるエンドポートは、ＳＭへの参加要求で、ＳＭから制限付きパーティションメンバーＭＬＩＤが返されることを要求することができる。ＳＭは、エンドポートが、参加を要求しているＭＣＧに関連付けられるパーティションの正規メンバーであることを確認することができ、ＳＭによって、エンドポートがそのパーティションの正規メンバーであると判断された場合、ＳＭは制限付きパーティションメンバーＭＬＩＤを要求元のエンドポートに返すことができる。この方法は、関連するＭＣＧのメンバーでもある他の正規パーティションメンバーエンドポートにのみマルチキャストパケットを転送するために、正規パーティションメンバーエンドポートによって用いることができる。

【0295】

一実施形態によれば、送信元エンドポートをメッセージで指定される（すなわち、メッセージで指定されたＭＧＩＤに関連付けられる）ＭＣＧに参加させること、および制限付きパーティションメンバーＭＬＩＤを要求元のエンドポートに返すことの両方を要求するメッセージタイプを定義することができる。このメッセージタイプには、（デフォルトの）正規パーティションメンバーＭＬＩＤではなく、制限付きパーティションメンバーＭＬＩＤが要求元のエンドポートに返されることを除き、通常の参加操作と同じパラメータを含めることができる。このメッセージタイプは、たとえば、MCMemberRecord属性のプロパティ（GetLimitedMLID （制限付きＭＧＩＤ取得）プロパティなど）として、または新た
なＳＡメソッドとして実装することができる。

【0296】

一実施形態によれば、ＭＣＧへのデュアルＭＬＩＤ割り当ての使用、構成、および／または管理をサポートするＩＢ実装例は、ＭＣＧへのデュアルＭＬＩＤ割り当ての使用、構成、および／または管理（たとえば、上記のDualMLIDAllocationおよびDualMLIDAllocationInUse）で用いられるプロパティの状態変更イベントを含むことができる。さらに、Ｍ
ＣＧへのデュアルＭＬＩＤ割り当ての使用、構成、および／または管理をサポートするＩＢ実装例には、ＭＣＧへのデュアルＭＬＩＤ割り当て（たとえば、上記のようなDualMLIDAllocation、およびDualMLIDAllocationInUse）の使用、構成、および／または管理で用
いられるプロパティの値を照会するための動詞インターフェイスを含めることができる。

【0297】

図３２は、一実施形態による、デュアルＭＬＩＤがＭＣＧに割り当てられた状態での使用のためにエンドポートを構成するためのフローチャートを示す。ステップ３２０２で、ＳＭはデュアルＭＬＩＤをＭＣＧに割り当てる。ステップ３２０４で、ＳＭは、サブネットに接続されたエンドポートがＭＣＧへのデュアルＭＬＩＤ割り当てをサポートするという指示を受信する。ステップ３２０６で、ＳＭは、ＳＭがデュアルＭＬＩＤをＭＣＧに割り当てたことを示すインジケータをエンドポートに設定する。ステップ３２０８で、ＳＭはＭＣＧに参加するための要求をエンドポートから受信する。ステップ３２１０で、ＳＭはＭＣＧに割り当てられたデュアルＭＬＩＤの１つをエンドポートに提供する。ステップ３２１２で、この方法は終了することができる。

【0298】

図３３は、一実施形態による、マルチキャストグループごとにデュアルマルチキャストローカル識別子（ＭＬＩＤ）を提供して、高性能コンピューティング環境において正規および制限付きパーティションメンバーの両方を容易にするフローチャートを示す。ステップ３３１０で、第１のマルチキャストローカル識別子および第２のマルチキャストローカル識別子が、サブネット内においてマルチキャストグループを定義するマルチキャストグローバル識別子に関連付けられる。ステップ３３３０で、マルチキャストグループのメンバーであり、サブネットで定義された第１のパーティションのメンバーである、サブネットにおけるある数のエンドポートが判断される。ステップ３３４０で、ある数のエンドポートのうち、パーティションの正規メンバーであるエンドポートからなる第１のサブセットが判断される。ステップ３３５０で、ある数のエンドポートのうち、パーティションの
制限付きメンバーであるエンドポートからなる第２のサブセットが判断される。ステップ３３６０で、第１のマルチキャストローカル識別子は、ある数のエンドポートのうちの第１のサブセットの各エンドポートに関連付けられる。ステップ３３７０で、第２のマルチキャストローカル識別子は、ある数のエンドポートのうちの第２のサブセットの各エンドポートに関連付けられる。ステップ３３８０で、第１のマルチキャストローカル識別子を含むマルチキャストパケットを、マルチキャストグループのメンバーであり、サブネットにおいて定義される第１のパーティションのメンバーである、サブネットの、判断された数のエンドポートの各々に配信する、サブネットトポロジーを通る第１のルートが判断される。ステップ３３９０で、第２のマルチキャストローカル識別子を含むマルチキャストパケットを、ある数のエンドポートのうち、パーティションの正規メンバーである、判断された第１のサブセットの各エンドポートのみに配信する、サブネットトポロジーを通る第２のルートが判断される。

【0299】

パーティションメンバーシップに関連して定義されるマルチキャストグループ（ＭＣＧ）メンバーシップ
一実施形態によれば、特定のＩＢパーティションのメンバーであるすべてのエンドポートが特定のＩＢマルチキャストグループのすべてのメンバーでもあることは珍しくない。たとえば、上記のように、ＩＰｏＩＢブロードキャストグループは、ＩＢパーティションのコンテキストで定義されたマルチキャストグループである。パーティションのメンバーである各エンドポートは、そのパーティションのコンテキストで定義されたブロードキャストグループのメンバーでもある。これにより、ＩＰプロトコルを用いるレガシーアプリケーションは、ＩＢサブネットを介してブロードキャストパケットを受信できる。

【0300】

ただし、上記でさらに論じたように、ブロードキャストグループが対応するＩＢパーティションの各エンドポートメンバーは、ブロードキャスト（マルチキャスト）グループのメンバーになるために、ＳＭ／ＳＡに参加要求を送信する必要がある。ＭＣＧ参加要求に応答して、要求元エンドポートのＬＩＤをブロードキャストグループのＭＧＩＤに関連付けることに加えて、ＳＭは単一のスパニングツリーを再作成し（上記を参照）、影響を受ける任意のスイッチのＭＦＴを再作成して送信する必要がある。この場合のオーバーヘッドおよび非効率性を回避するために、ある実施形態に従って、特定のパーティションのコンテキストで定義されるマルチキャストグループをそのように示すことができる。さらに、ＳＭは、パーティションがこの態様でいつマルチキャストグループに関連付けられるかを判断することができ、次いで、パーティションの各メンバーからＭＣＧ参加要求を受信する必要なく、パーティションメンバーをマルチキャストグループに自動的に追加することができる。

【0301】

一実施形態によれば、ＳＭが新たなマルチキャストグループ（ＭＣＧ）を作成する要求を受信すると、サブネットマネージャは要求を調べて、マルチキャストグループを定義するために必要な従来のパラメータ（例えば、ＩＢ仕様で指定されるパラメータ）を判断することができる。上記のように、Ｐ＿Ｋｅｙは、マルチキャストグループを定義するために要求に必要なパラメータの１つである。さらに、要求に含まれるＰ＿Ｋｅｙに対応するパーティションの各メンバーを新たなマルチキャストグループのメンバーとしても追加するかどうかを示すパラメータ（またはインジケータ）を要求に含めることができる（たとえば、「JoinAllPartitionMembers（すべてのパーティションメンバーを参加させる）」
パラメータ）。ＳＭは、指定されたパーティションの各エンドポートメンバーも新たなマルチキャストグループに追加されることをパラメータが示すと判断すると、ＳＭは指定されたパーティションの各メンバーのＬＩＤを新たなマルチキャストグループのＭＧＩＤに関連付けることができる。

【0302】

この方法は、ＭＣＧ作成要求で指定されたパーティションの各エンドポートメンバー（
ＭＣＧが動的に作成される場合は作成エンドポートメンバーを除く）が、新たに作成されたＭＣＧのＳＭに参加要求を伝達する必要性を取り除き、なぜならば、これらのパーティションメンバーは、ＭＣＧ作成要求に含まれる追加パラメータの指示の結果として追加することができるからである。したがって、この方法は、クライアント／エンドポートとＳＭ／ＳＡ実装例と間の通信を、特に、そのような通信の大部分が通常行われているファブリックの初期化の重要な時間中に、大幅に削減する。

【0303】

さらに、この方法により、ＳＭ／ＳＡが、各参加要求の後にスパニングツリーを生成し、ＭＦＴを更新して、各個々の参加要求の影響を受けるスイッチに送信する必要がなくなる。そうではなく、ＳＭは、パーティションメンバーのすべてのＬＩＤを新たに作成されたＭＣＧのＭＧＩＤに関連付けることができる。次に、ＳＭは、ＭＣＧに追加された各ＬＩＤを考慮に入れた単一のスパニングツリーを作成することができる。このスパニングツリーから、ＳＭはＭＣＧに追加されたすべてのＬＩＤを説明するＭＦＴのセットを生成し、このＭＦＴのセットをサブネットスイッチに送信することができる。その結果、ＳＭの作業負荷を、初期化中およびその他のときに大幅に低減することができる。

【0304】

図３４は、一実施形態による、高性能コンピューティング環境においてパーティションメンバーシップに関して定義されたマルチキャストグループメンバーシップを提供するためのフローチャートを示す。ステップ３４１０で、サブネットのサブネットマネージャは、マルチキャストグループを作成する要求を受信し、要求はインジケータを含み、インジケータは、サブネットで定義されたパーティションの各メンバーがマルチキャストグループに関連付けられることを示す。ステップ３４２０で、サブネットマネージャは、サブネットで定義されたパーティションのメンバーである、ある数の追加のエンドポートを判断する。ステップ３４３０で、サブネットマネージャは、パーティションのメンバーである、ある数の追加のエンドポートを、マルチキャストグループを定義する識別子に関連付ける。ステップ３４４０で、サブネットマネージャは、マルチキャストグループを定義する識別子を含むマルチキャストパケットを、マルチキャストグループを定義する識別子に関連付けられた各エンドポートに配信するためのルートを定義する。

【0305】

図３５は、一実施形態による、高性能コンピューティング環境においてパーティションメンバーシップに関して定義されたマルチキャストグループメンバーシップを提供する方法のフローチャートを示す。より具体的には、図３５は、マルチキャストルーティングを設定し、対応するパーティションの各メンバーを作成されたマルチキャストグループに追加すべきであることを示すマルチキャストグループ作成要求に基づいてマルチキャスト転送テーブルを更新するフローチャートを示す。

【0306】

図３５を参照すると、ステップ３５０５で、すべてのパーティションメンバーが関連のＭＣＧのメンバーであるべきであることを示すＭＣＧ参加要求またはＭＣＧ作成命令を受信することができる。判断ステップ３５１０で、要求がＭＣＧに関する最初の要求であるかどうかを判断することができる。ＭＣＧに関して最初の要求ではないと判断された場合、ステップ３５１５で、要求が関連するＭＣＧに参加するための参加要求であるかどうかをさらに判断することができる。要求が参加要求であると判断された場合、ステップ３５２０で、ＭＣＧレコードを、更新されたＭＬＩＤとともに返すことができる。ただし、ステップ３５１０で、要求がＭＣＧに関する最初の要求であると判断された場合、制御はステップ３５２５に進むことができる。ステップ３５２５で、ＭＣＧに対してＭＬＩＤを割り当てることができる。次に、ステップ３５３０で、キャッシュされたトポロジー情報から関連するすべてのパーティションメンバーを取得することができる。ステップ３５３５で、すべてのパーティションメンバーエンドノードを含むスパニングツリーを生成することができる。ステップ３５４０で、影響を受けるスイッチのＭＦＴを更新してスパニングツリーを反映することができ、更新されたＭＦＴをそれらのそれぞれのスイッチに送信す
ることができる。

【0307】

表１は、対応するパーティションの各メンバーも新たに作成されたマルチキャストグループのメンバーとして追加する必要があるかどうかを示すために ＳＭ／ＳＡによって使
用されるパラメータを含むマルチキャストグループを作成するための例示的なサブネット管理属性（MCMemberRecord属性など）を示す。表１の属性には、新しいＭＣＧを作成するためにＩＢ仕様で指定された従来のパラメータが含まれる。表１で指定された属性には、さらに、対応するパーティションの各メンバーを作成されたマルチキャストグループのメンバーとしても追加する必要があるかどうかを示すJoinAllPartitionMembers（すべての
パーティションのメンバー参加）パラメータまたはインジケータが含まれる。対応するパーティションは、属性で指定されたパーティションとすることができる。

【0308】

【表1】

【0309】

一実施形態によれば、表１の属性などの属性（属性は、新たなＭＣＧを作成するための管理要求または動的要求のいずれかに含まれる）を受信すると、ＳＭ／ＳＡのロジックは、JoinAllPartitionMembersパラメータの値を判断することができる。ＳＭは、判断され
たJoinAllPartitionMembersパラメータの値に基づいて、対応するパーティションの各メ
ンバーを新たなＭＣＧグループに追加するべきであると判断することができる。つまり、パーティションの各エンドポートメンバーのＬＩＤは、新たなＭＣＧを定義するＭＧＩＤに関連付ける必要がある。これらの関連付けは、ＳＡデータストアなどに保存することができる。

【0310】

たとえば、ＳＭは新たなマルチキャストグループの作成を要求するＭＡＤを受信するこ
とができる。ＭＡＤは、ＩＢ仕様で定義されているサブネット管理クラスによって提供されるSubnAdmSet()メソッドを指定することができる。ＭＡＤは、MCMemberRecord属性をさらに指定することができ、上記のパラメータ（ＭＧＩＤ、Ｐ＿Ｋｅｙ、Ｑ＿ＫＥＹなど）を指定することができる。さらに、MCMemberRecord属性にはJoinAllPartitionMembersパ
ラメータを含めることができる。一実施形態によれば、JoinAllPartitionMembersパラメ
ータは単一ビットとすることができる。

【0311】

JoinAllPartitionMembersパラメータを有するMCMemberRecord属性を含むＭＡＤを受信
すると、ＳＭ／ＳＡはJoinAllPartitionMembersパラメータの値を判断することができる
。たとえば、JoinAllPartitionMembersパラメータビットを１にセットして、MCMemberRecordのP_Keyパラメータで指定されたパーティションの各メンバーが新たなＭＣＧグループに参加するべきであることを示してもよい。JoinAllPartitionMembersパラメータビット
が１（または設計に応じて０）にセットされていると判断すると、サブネットマネージャのロジックは、MCMemberRecord属性で指定されたP_Keyで表されるパーティションのすべ
てのメンバーを新たに作成されたＭＣＧに追加することができる。

【0312】

図３６は、一実施形態による、高性能コンピューティング環境においてパーティションメンバーシップに関して定義されたマルチキャストグループメンバーシップを提供する方法のフローチャートを示す。ステップ３６００で、パーティションＡなどのパーティションのメンバーである、あるエンドノードは、ＭＣＧ ＡなどのＭＣＧに参加するマルチキャストグループ（ＭＣＧ）参加要求を開始することができる。ステップ３６０５で、サブネットマネージャはＭＣＧ参加要求を受信することができる。示された方法では、参加要求が向けられたＭＣＧにはすでにサブネット内においてマルチキャストローカル識別子（ＭＬＩＤ）が割り当てられている。ステップ３６１０で、（たとえば、エンドノードがサブネットへの新規追加であり、ＭＣＧ Ａへの追加を要求している場合）ＳＭマネージャはパーティションＡの他のメンバーがすでにＭＣＧ Ａのメンバーでもあるかどうかを判断することができる。そのような場合、ＭＣＧ参加要求は通常通りに処理され（３６１５）、この方法は終了する。ただし、パーティションＡの他のメンバー（一部またはすべてのメンバー）がＭＣＧ Ａのメンバーではない場合、ＳＭは、ステップ３６２０で、ＳＭが最初のエンドノードから受信したＭＣＧ参加要求にのみ基づいて、パーティションＡの他のすべてのメンバーをＭＣＧ Ａに自動的に追加することができる。パーティションＡの他のメンバーがＭＣＧ Ａに追加されると、ＳＭは３６２５でＭＣＧ ＡのＭＬＩＤを更新して、ＭＣＧ Ａ宛てのＭＣパケットの宛先としてパーティションＡの他のメンバーを含めることができる。この方法は３６３０で終了することができる。

【0313】

ＳＭＡ属性としてのパーティションごとのデフォルトＭＬＩＤ値
一実施形態によれば、上述のように、複数のＭＣＧが同じＭＬＩＤを共有することが可能である。つまり、（マルチキャストグループを定義する）複数のＭＧＩＤを１つの同じＭＬＩＤに関連付けることができる。さらに、マルチキャストパケットルーティングはマルチキャストパケットのＤＬＩＤとして指定されるＭＬＩＤに基づいているため、同じＭＬＩＤを共有するＭＣＧは、サブネットを介するそれぞれのマルチキャストパケットの同じルーティングを共有する。したがって、サブネットマネージャは、パーティションごとに専用のＭＬＩＤを割り当てることができ、パーティションには、パーティションのコンテキストで１つ以上のＭＣＧが定義される。パーティションに関連付けられた、またはパーティションのコンテキストで定義されたすべてのＭＣＧは、同じＭＬＩＤを共有することができる。これにより、サブネット内のＬＩＤの数を増やすことができ、なぜならば、有限数のＬＩＤのうち、より少ないＬＩＤがマルチキャストグループに用いられるからである。これにより、サブネットのＳＭは単一のスパニングツリーを作成し、同じパーティションに関連付けられた複数のＭＣＧに対して単一のＭＦＴセットを作成できるため、ＳＭ／ＳＡオーバーヘッドが低減される。

【0314】

一実施形態によれば、ＳＭポリシーは、パーティションに対してデフォルトＭＬＩＤが定義されることを指定することができる。このポリシーは、サブネット内の各パーティションにデフォルトのＭＬＩＤを割り当てること、またはマルチキャスト通信用に定義されたパーティション（つまり、ＭＣＧがコンテキストに定義されているパーティション）にのみデフォルトのＭＬＩＤを割り当てることを指定することができる。さらに、関連するパーティションのエンドポートメンバーに、関連するパーティションにおけるエンドポートのメンバーシップによって、デフォルトのＭＬＩＤを知らせることができる。

【0315】

一実施形態によれば、デフォルトのＭＬＩＤ値は、サブネットの初期化中にＳＭが各ポートに配信するＰ＿Ｋｅｙテーブルコンテンツに関連するメタデータとして提供され得る。このようにして、特定のパーティションのエンドポートメンバーに対して、エンドポートが特定のパーティションのメンバーである限り、特定のパーティションのコンテキストにおいて設定されている任意のＭＣＧのＭＬＩＤを、認識させることができる。したがって、エンドポートは、事前にエンドポートがメンバーであるＭＣＧグループのＭＬＩＤを学習することができるため、ＳＭによって処理されるＭＣＧ参加要求の送信を回避することができる。

【0316】

デフォルト（つまり、「パーティション固有」）ＭＬＩＤが、パーティションに関連付けられた１つ以上のＭＣＧに割り当てられる場合、一実施形態によれば、パーティション固有のＭＬＩＤは、エンドポートのＰ＿Ｋｅｙテーブルに配置される各Ｐ＿Ｋｅｙとともに、ＳＭＡ属性としてエンドポートに提供することができる。Ｐ＿Ｋｅｙテーブルの情報は、Ｐ＿ＫｅｙテーブルのエントリとデフォルトのＭＬＩＤテーブルのエントリとの間に関連付けまたは関係を含めることにより、論理的に拡張することができる。

【0317】

Ｐ＿Ｋｅｙテーブルのサイズは、ＩＢ仕様に従って、サブネットの各ノード（たとえば、各ＨＣＡ）によって実装されるNodeInfo（ノード情報）属性のPartitionCap（パーティションキャップ）コンポーネントによって指定することができる。Ｐ＿Ｋｅｙテーブルのサイズは一般にベンダー固有であるが、PartitionCapコンポーネントは各ノードについて少なくとも１の値にセットされて、Ｐ＿Ｋｅｙテーブルが少なくとも１つの１６ビットＰ＿Ｋｅｙを格納することができることを示し、なぜならば、各エンドポートは、少なくともデフォルトパーティションのメンバーであるからである。ただし、より大きなＰ＿Ｋｅｙテーブルが一般的である。一実施形態によれば、従来のＰ＿Ｋｅｙテーブルは、配列の要素の数がノードのPartitionCapコンポーネントで指定された数に等しい配列を含むことができる。

【0318】

一実施形態によれば、ＨＣＡは、エンドポートがメンバーである任意のパーティションのパーティション固有のＭＬＩＤ（割り当てられている場合）を含むデフォルトのＭＬＩＤテーブルを格納するように構成することができる。エンドポートのデフォルトのＭＬＩＤテーブルは、Ｐ＿Ｋｅｙテーブルの各エントリがデフォルトのＭＬＩＤテーブルのエントリにマッピングされるように、エンドポートのＰ＿Ｋｅｙテーブルに関連付けることができる。

【0319】

例えば、Ｐ＿Ｋｅｙテーブルが配列である実施形態では、デフォルトのＭＬＩＤテーブルも配列であり得る。デフォルトのＭＬＩＤテーブル配列は、Ｐ＿Ｋｅｙテーブル配列と同じ数の要素を有することができる。さらに、Ｐ＿Ｋｅｙテーブル配列の所与の要素のインデックス値は、Ｐ＿Ｋｅｙテーブル配列の所与の要素に保持されるＰ＿Ｋｅｙによって表されるパーティションに対して割り当てられるデフォルトのＭＬＩＤを保持するデフォルトのＭＬＩＤテーブル配列の要素のインデックス値と等しくすることができる。つまり、Ｐ＿ＫｅｙテーブルおよびデフォルトのＭＬＩＤテーブルは並列配列にすることができ
る。この方法では、Ｐ＿Ｋｅｙテーブルの各要素をデフォルトのＭＬＩＤテーブルの要素に直接マッピングすることができ、エンドポートノードは、Ｐ＿ＫｅｙテーブルからデフォルトのＭＬＩＤテーブルへのマッピングを用いて、（存在する場合には）パーティションに割り当てられるデフォルトＭＬＩＤを判断することができる。

【0320】

リスティング２は、一実施形態による、例示的な並列配列としてＰ＿ＫｅｙテーブルおよびデフォルトのＭＬＩＤテーブルを表す。リスティング２に見られるように、Ｐ＿ＫｅｙテーブルはデフォルトのＭＬＩＤテーブル配列と並列な配列であるため、Ｐ＿Ｋｅｙ配列要素ＮのＰ＿Ｋｅｙの場合、そのＰ＿Ｋｅｙに関連付けられるデフォルトのＭＬＩＤはデフォルトのＭＬＩＤ配列要素Ｎに見出されることになる。

【0321】

【数3】

【0322】

Ｐ＿ＫｅｙテーブルからデフォルトのＭＬＩＤテーブルへのマッピングの他の例示的な実施形態は、例えば、プライマリキーおよび外部キーならびに／またはマッピングテーブルを利用するリレーショナルデータベース構造を含み、Ｐ＿ｋｅｙテーブルにおけるＰ＿ＫｅｙとデフォルトのＭＬＩＤテーブルにおけるそれの割り当てられたデフォルトＭＬＩＤとの間の関係を形成する。さらに別の実施形態では、記述されるマッピング関係をパーティションキーとデフォルトＭＬＩＤとの間に形成するために、２次元配列（または、デュアルデフォルトＭＬＩＤがパーティションに割り当てられる場合は多次元配列）を用いることができる。さらに他の実施形態は、コンマ区切り値などのファイルアーキテクチャを含むことができる。適切なマッピング手法を用いて、記述される関係をパーティションのＰ＿Ｋｅｙとパーティションに割り当てられたデフォルトのＭＬＩＤの間に形成することができる。

【0323】

（上記で詳細に説明したように）デフォルトパーティション固有のデュアルＭＬＩＤがＭＣＧに割り当てられている場合、２つの独立した値がデフォルトのＭＬＩＤテーブルで表され、‐１つの値は、正規パーティションメンバーシップを有するＭＣＧメンバーに割り当てられるＭＬＩＤに対してであり、１つの値は、限定付きパーティションメンバーシップを有するＭＣＧメンバーに割り当てられるＭＬＩＤに対してである。代替的に、デフォルトのＭＬＩＤテーブルで、対応する値（正規のまたは制限付きメンバーＭＬＩＤ値）を簡単に導出できるように定義された規則を用いて、単一の値を表すことができる。たとえば、正規パーティションメンバーシップを有するＭＣＧメンバーに割り当てられたＭＬＩＤがデフォルトのＭＬＩＤテーブルで表される場合、その規則は、正規パーティションメンバーシップを有するＭＣＧメンバーに割り当てられたＭＬＩＤは、正規メンバーシップＭＬＩＤのそれ＋１（つまり、正規パーティションメンバーＭＬＩＤ＋１＝制限付きパーティションメンバーＭＬＩＤ）であることを明記し得る。したがって、デュアルＭＬＩＤの１つを、エンドポートに明示的に知られるようにしたり、通信したりする必要はない。

【0324】

一実施形態によれば、パーティションにデフォルトＭＬＩＤが割り当てられていない場合、そのパーティションを表すＰ＿Ｋｅｙを保持するＰ＿Ｋｅｙテーブル内の要素は、（
Ｐ＿Ｋｅｙテーブルを収容するノードによって）既知の値にマッピングされて、そのパーティションにはデフォルトのＭＬＩＤは割り当てられていないことを示すことができる。たとえば、特定のパーティションにデフォルトのＭＬＩＤが割り当てられていない場合、特定のパーティションのＰ＿Ｋｅｙを保持するパーティションテーブルの要素にマッピングされるデフォルトのＭＬＩＤテーブルの要素は、ゼロ（０）の値を格納することができ、０の値は、対応するパーティションにデフォルトのＭＬＩＤが割り当てられていないことを示す。

【0325】

一実施形態によれば、ＩＢコンポーネントは、ノードのエンドポートのデフォルトのＭＬＩＤテーブルをサポートすることができる。たとえば、ＨＣＡはデフォルトのＭＬＩＤテーブルを含むことができるだけでなく、その構成および使用を属性を通してサポートすることもできる。さらに、サブネットマネージャはノードと連携して、このような属性の使用を通してデフォルトのＭＬＩＤテーブルの構成および管理をサポートすることもできる。

【0326】

そのような属性の１つは、ノード（ＨＣＡなど）がデフォルトのＭＬＩＤテーブルをサポートすることを示すフラグまたはインジケータである。このようなインジケータは、「偽」のデフォルト値を有することができる。たとえば、デフォルトのＭＬＩＤテーブルの使用／構成／管理をサポートするＳＭは、デフォルトのＭＬＩＤテーブルサポート属性（たとえば、「HasDefaultMLIDsTable（デフォルトのＭＬＩＤテーブルを有する）」属性）を「偽」にセットすることができる。したがって、ＳＭが、デフォルトのＭＬＩＤテーブルをサポートしないＨＣＡを発見した場合、ＳＭは、サポートされていない、またはそのサポートしていないＨＣＡにおいて含まれていないデフォルトのＭＬＩＤテーブルを構成しようとしてそのサポートしていないＨＣＡにサポートのない属性修飾子を送信しない。

【0327】

初期化中に、ＳＭはサブネットに接続されたＨＣＡを発見し、発見されたＨＣＡに構成情報を送信することができる。ＨＣＡは、サポートされているＨＣＡの機能について、ＳＭと通信したり、ＳＭからの要求に応答したりすることもできる。一実施形態によれば、発見されたＨＣＡがデフォルトのＭＬＩＤテーブルをサポートすることを明示的に通信しないとき、ＳＭは、例えば、HasDefaultMLIDsTable属性のデフォルト設定を偽として単純に残すことができる。逆に、ＨＣＡがデフォルトのＭＬＩＤテーブルをサポートする場合、サポートするＨＣＡは初期化ＳＭへの通信で属性を「真」にセットすることができる。このような通信は、ＳＭへの直接通信、または情報の要求に対する応答（SubnGet() SMP
などであり、応答はＳＭに戻るSubnGetResp() SMPの形式である）とすることができる。

【0328】

ノードのエンドポートがデフォルトのＭＬＩＤテーブルをサポートする旨をノードが（サポートしている）ＳＭに通信すると、ＳＭはエンドポートのデフォルトのＭＬＩＤテーブルを設定することができる。ＳＭは、デフォルトのＭＬＩＤのレコードを維持することができる。デフォルトのＭＬＩＤの各々は、それぞれのパーティションに関連付けることができる。これらのＭＬＩＤは、サブネットポリシーによって、それらのそれぞれのパーティションに関連付けられ得る（つまり、それらのそれぞれのパーティションのデフォルトＭＬＩＤとして割り当てられ得る）。サブネットマネージャは、サポートするエンドポートがどのパーティションのメンバーであるかを判断し、エンドポートのＰ＿Ｋｅｙテーブルを更新し、更新されたＰ＿Ｋｅｙテーブルに基づいてデフォルトのＭＬＩＤテーブルを更新することができる。

【0329】

一実施形態によれば、エンドポートとともに用いるためのデフォルトのＭＬＩＤテーブルをサポートするＨＣＡは、デフォルトのＭＬＩＤテーブルが使用中であるかどうかを示す属性を含むことができる。たとえば、デフォルトのＭＬＩＤテーブルを含み、その使用をサポートするＨＣＡは、DefaultMLIDTableInUse（デフォルトのＭＬＩＤテーブル使用
中）属性を含むこともできる。ＳＭが、サポートするエンドポートのＭＬＩＤテーブルを更新すると、この属性は、ＳＭによって「真」にセットされることができる。ＩＢクライアントは、この属性を用いて、クライアントに関連するＭＬＩＤ値を、サポートするエンドポートのデフォルトのＭＬＩＤテーブルから学習／取得することができるかどうかを判断することができる。

【0330】

一実施形態によれば、以下のリスティング３に示される擬似コードは、エンドポートのパーティションテーブルに従ってエンドポートのデフォルトのＭＬＩＤテーブルを更新する方法を示す。

【0331】

【数4】

【0332】

図３７は、一実施形態による、エンドポートのパーティションテーブルに従ってエンドポートのデフォルトのＭＬＩＤテーブルを更新する方法のフローチャートである。図３７を参照して、（およびリスティング３の擬似コードに反映されるように、）エンドポートのＰ＿Ｋｅｙテーブルを更新する際、ＳＭは、最初に、エンドポートがデフォルトのＭＬＩＤテーブルをサポートするかどうかの判断を、そのように示す属性（例えば、HasDefaultMLIDsTable属性）を確認することにより行なうことができる。エンドポートがデフォルトのＭＬＩＤテーブルをサポートしていない場合（例：エンドポートのHasDefaultMLIDsTable属性が偽の場合）、ＳＭは、エンドポートのパーティションテーブルを更新する必要がある場合には、エンドポートのパーティションテーブルを更新し続けることができる。ただし、エンドポートがデフォルトのＭＬＩＤテーブルをサポートする（したがって、含む）場合（たとえば、エンドポートのHasDefaultMLIDsTable属性が真の場合）、ＳＭは、エンドポートのデフォルトのＭＬＩＤテーブルが使用中であるかどうか示すエンドポートの属性の値を確認することができる。

【0333】

引き続き図３７を参照し、エンドポートのデフォルトのＭＬＩＤテーブルが使用中であるかどうかを示すエンドポートの属性（たとえば、エンドポートのDefaultMLIDTableInUse属性）が真にセットされている場合、およびエンドポートのパーティションテーブルの
更新が必要な場合、ＳＭはこの属性を真にセットされるままにし、エンドポートのデフォルトのＭＬＩＤテーブルをクリアし、エンドポートのパーティションテーブルを更新してから、エンドポートの更新されたパーティションテーブルに基づいてエンドポートのデフォルトのＭＬＩＤテーブルを更新することができる。

【0334】

逆に、エンドポートのデフォルトのＭＬＩＤテーブルが使用中であるかどうかを示すエンドポートの属性（たとえば、エンドポートの DefaultMLIDTableInUse属性）が偽にセットされている場合、ＳＭは、エンドポートのデフォルトのＭＬＩＤテーブルをクリアして、この属性を真にセットすることができる。次いで、エンドポートのパーティションテーブルが更新を必要とする場合、ＳＭはパーティションテーブルを更新することができる。最後に、ＳＭは、更新されたエンドポートのパーティションテーブルに基づいて、エンドポートのデフォルトのＭＬＩＤテーブルを更新することができる。

【0335】

図３８は、一実施形態による、ＩＢクライアントにより、サポートするエンドポートのデフォルトのＭＬＩＤテーブルからデフォルトのＭＬＩＤ値を判断するための方法のフローチャートである。図３８を参照すると、サポートするエンドポートのデフォルトのＭＬＩＤテーブルからデフォルトのＭＬＩＤを取得／学習する際に、ＩＢクライアントはまず、関連するローカルエンドポートのＰ＿Ｋｅｙテーブルの内容が変更または更新されたかどうかを判断することができる。これは、たとえば、ＩＢクライアントが認識しているローカルポートイベントによって判断することができる。ローカルエンドポートのＰ＿Ｋｅｙテーブルの内容に変更があると判断されると、Ｐ＿Ｋｅｙテーブルの内容をローカルキャッシュにコピーすることができる。ＩＢクライアントは、ローカルエンドポートがデフォルトのＭＬＩＤテーブルをサポートしていること（例：エンドポートのHasDefaultMLIDsTable属性が真であること）およびＭＬＩＤテーブルが使用中であること（例：エンドポートのDefaultMLIDTableInUse属性が真であること）をチェックすることができる。両方
の属性が真にセットされている場合、エンドポートのＰ＿Ｋｅｙテーブル内の各有効なエントリについて、ＩＢクライアントは、エンドポートのデフォルトのＭＬＩＤテーブル内の対応するエントリがデフォルトのＭＬＩＤを示すまで（たとえば、エントリが非零になるまで）待機し、次いで、ＭＬＩＤテーブルの内容をローカルキャッシュにコピーすることができる。

【0336】

実施形態に従って、以下のリスティング４に示す疑似コードは、ＩＢクライアントが、サポートしているエンドポートのデフォルトのＭＬＩＤテーブルからデフォルトのＭＬＩＤ値を判断する方法を示す。

【0337】

【数5】

【0338】

一実施形態によれば、デフォルトのＭＬＩＤテーブルの使用、構成、および／または管理をサポートするＩＢ実装例は、デフォルトのＭＬＩＤテーブルの使用、構成、および／または管理で用いられる属性（例えば、上記の属性）についての状態変更イベントを含むことができる。さらに、デフォルトのＭＬＩＤテーブルの使用、構成、および／または管理をサポートするＩＢ実装例は、デフォルトのＭＬＩＤテーブルの使用、構成、および／または管理で用いられる属性（たとえば、上記の属性）の値を問い合わせるための動詞インターフェイスを含むことができる。

【0339】

図３９は、一実施形態による、高性能コンピューティング環境において追加のサブネット管理エージェント（ＳＭＡ）属性としてパーティションごとにデフォルトのマルチキャストローカル識別子（ＭＬＩＤ）値を提供する方法のフローチャートを示す。ステップ３９００で、パーティションキーを格納するためのテーブルがサブネットのノードに提供され、パーティションキーはサブネットのパーティションを定義する。ステップ３９１０で、マルチキャストローカル識別子を格納するためのテーブルがサブネットのノードに提供される。ステップ３９２０で、パーティションキーを格納するためのテーブルの要素とマルチキャストローカル識別子を格納するためのテーブルの要素との関係が構成され、この関係は、パーティションキーを格納するためのテーブルの要素を、マルチキャストローカル識別子を格納するためのテーブルの要素にマッピングする。ステップ３９３０で、サブネットのサブネットマネージャへの通信がノードから送信され、この通信は、ノードがマルチキャストローカル識別子を格納するためのテーブルをサポートすることを示す。ステップ３９４０で、パーティションキーがノードで受信される。ステップ３９５０で、マルチキャストローカル識別子がノードで受信される。ステップ３９６０で、パーティションキーは、パーティションキーを格納するためのテーブルに格納される。ステップ３９７０で、マルチキャストローカル識別子は、マルチキャストローカル識別子を格納するためのテーブルに格納される。ステップ３９８０で、パーティションキーを格納するためのテーブルの要素とマルチキャストローカル識別子を格納するためのテーブルの要素との間の関係を用いて、マルチキャストローカル識別子を格納するためのテーブルからマルチキャストローカル識別子を検索する。ステップ３９９０で、ノードのマルチキャストグループレコード内のマルチキャストローカル識別子フィールドに、マルチキャストローカル識別子を格納するためのテーブルから検索されたマルチキャストローカル識別子がポピュレートされる。

【0340】

エンドポートによるＭＬＩＤのダイナミックディスカバリ
ＩＢ仕様によれば、ＩＢマルチキャストメッセージを受信するには、ＱＰをマルチキャストグループにアタッチする（つまり、マルチキャストグループを表すＭＧＩＤに関連付ける）必要がある。ＱＰは、ＩＢ動詞を用いてマルチキャストグループに対してアタッチまたはデタッチされる。ＩＢ動詞は、セマンティクスのセットを含むサービスインターフェイスであり、ＨＣＡの必要な動作を、ＨＣＡが提供するＩ／Ｏサービスの消費者（ＩＢクライアント）に公開する。動詞は、作業要求をＨＣＡに提出し、完了ステータスを返すための特定のキューイングモデルに基づいてＨＣＡとＩＢクライアントの間で行われる操作を記述する。動詞は、チャネルアダプタの構成および管理、キューペアの割り当て（作成および破棄）、ＱＰ操作の構成、ＱＰへの作業要求のポスティング、完了キューからの完了ステータスの取得に必要なパラメータを記述する。

【0341】

ＩＢクライアントが、それが参加したいＭＣＧのＭＧＩＤを知っていることが、ＩＢ仕様の要件である。従来の参加要求では、ＩＢクライアントに関連付けられたエンドポートは既知のＭＧＩＤをＳＭに渡し、ＳＭはエンドポートを参加させるＭＣＧを認識する。さらに、上記のように、ＩＢマルチキャストメッセージを受信するために、ＱＰをマルチキャストグループにアタッチする（つまり、マルチキャストグループを表すＭＧＩＤに関連付ける）必要がある。したがって、一実施形態によれば、ＨＣＡは、参加要求をＳＭに送信することなく、ローカルＱＰを関連するマルチキャストグループ（ＭＣＧ）のＭＧＩＤと関連付けるＩＢクライアントをサポートすることができる。したがって、このようなサポートするＨＣＡのエンドポートは、ＳＭに、パケットの受信元であるＭＣＧにおいてメンバーシップを要求する参加要求を送信することなく、ＭＣＧのマルチキャストパケットを受信し始めることができる。

【0342】

図４０は、一実施形態による、高性能コンピューティング環境において、関連するＭＧＩＤ（マルチキャストグローバル識別子）について受信マルチキャストメッセージにおいてマルチキャストグループマルチキャストローカル識別子（ＭＬＩＤ）ダイナミックディスカバリを提供する方法のフローチャートを示す。ステップ４０００で、ローカルの信頼できないデータグラム（ＵＤ）ＱＰをＭＣＧのＭＧＩＤに関連付けることができる。ステップ４００５で、ＭＣＧからのマルチキャストパケットをＵＬＰで受信することができる。ステップ４０１０で、ＵＬＰは、マルチキャストパケットからＭＣＧのＭＬＩＤを判断することができる。ステップ４０１５で、ＵＬＰは、ＭＣＧのＭＬＩＤを別のＵＤ ＱＰに関連付けることができる。ステップ４０２０で、ローカルＭＣＧアドレスキャッシュを更新して、ＭＬＩＤとＭＣＧ／ＭＧＩＤとの関連付けを反映することができる。

【0343】

一実施形態によれば、ＨＣＡは、ＭＬＩＤが知られていない状態でＭＧＩＤ（すなわち、ＭＣＧ）とのＱＰ関連付けをサポートするかどうかを判断するために評価することができるクエリパラメータをサポートすることができる。例えば、「NoMLIDRequiredForQPMCGAttach（ＱＰＭＣＧアタッチのためにＭＬＩＤを必要としない）」パラメータが、サポートするＨＣＡにおいて照会可能パラメータとして含まれてもよい。このようなパラメータのデフォルト値は「偽」である。ＨＣＡインターフェイスプロバイダは、ＨＣＡ実装例がＱＰ対ＭＣＧ関連付け操作中にＭＬＩＤ（例：ＭＬＩＤパラメータにおける０の値など）をサポートする場合、パラメータを「真」にセットすることができる。そのようなパラメータは、ＩＢクライアントによって照会されて、ＱＰ対ＭＣＧ関連付け操作中に、ＨＣＡが未知のＭＬＩＤ（例：ＭＬＩＤパラメータにおける０の値）をサポートするかどうかを判断してもよい。パラメータの照会のため、および未知のＭＬＩＤでのＱＰ対ＭＣＧ関連付けのために、インターフェイスプロバイダによって、適切な動詞を提供することもできる。

【0344】

一実施形態によれば、リスティング５は、照会されたＨＣＡがＱＰ対ＭＣＧ関連付け操作中に未知のＭＬＩＤをサポートするかどうかに応じて、ＱＰをＭＣＧに関連付けるため
の例示的な擬似コードを示す。

【0345】

【数6】

【0346】

図４１は、一実施形態による、高性能コンピューティング環境において、関連するＭＧＩＤ（マルチキャストグローバル識別子）について受信マルチキャストメッセージ上においてマルチキャストグループマルチキャストローカル識別子（ＭＬＩＤ）ダイナミックディスカバリを提供する方法のフローチャートである。より具体的には、この図は、ＭＬＩＤの有無にかかわらずＭＣＧとのローカルＱＰ関連付けを判断するためのフローチャートを示す。

【0347】

この方法は、ステップ４１０５でローカルＱＰを作成することから開始することができる。ＱＰをＭＣＧに、ＭＬＩＤが指定されない状態でアタッチすることができる旨を、ローカルＨＣＡ情報が示す場合（ステップ４１１０）、ステップ４１１５で、関連するＭＧＩＤを指定する操作を介してＱＰをＭＣＧにアタッチすることができるが、ＭＬＩＤ＝０である。そうでない場合、ステップ４１２５で、関連するＭＣＧに参加し、関連するＭＬＩＤで応答を取得する、従来のＳＡ要求を実行することができる。次に、ステップ４１３０で、関連のＭＧＩＤおよびＳＡから応答で受信されるＭＬＩＤ値を指定する、ＱＰをＭＣＧにアタッチする操作を実行することができる。

【0348】

エンドポートからのＭＣＧへの参加要求により、通常、マルチキャストパケット配信の２つの必要な側面が確実に実行される。まず、正常な参加要求は、ＳＭが、要求元エンドポートを、要求元エンドポートが参加を要求したＭＣＧのマルチキャストルートに組み込むことを含む。次に、１つ以上のＱＰが、エンドポートが参加を要求したＭＣＧのＭＧＩＤに関連付けられる。上述のように、第２の局面を実行するための情報は、例えば、ＩＢクライアントまたはＵＬＰに既知であるので、第２の局面は、エンドポートがＳＭに参加要求を送信することなく実行することができる。さらに、これも前述のように、ＳＭは管理／サブネットポリシーの問題として、またはＭＣＧの「作成参加」操作の副作用として、ＭＣＧのマルチキャストルートに適切なエンドポートを暗黙的に組み込むことができ、‐たとえば、関連するエンドポートは、前述のように、パーティションメンバーシップに関連して定義されたＭＣＧメンバーシップのプロダクトとして、ＭＣＧのスパニングツリールートに含めることができる。したがって、一実施形態によれば、エンドノードが従来の参加要求をＳＭに送信することなく、マルチキャストパケットをエンドノードで受信することができる。

【0349】

ただし、マルチキャストパケットを送信するには、エンドポートはＭＣＧに関連付けられたＭＬＩＤを知っている必要がある。ＩＢ仕様では、ＭＣＧに参加するためにエンドノードがＭＣＧのＭＬＩＤを認識する必要はなく、なぜならば、従来、ＭＬＩＤは、ＳＭに
よって、エンドポートに、ＳＭが参加要求に応答してエンドポートに返すMCMemberRecord属性において提供されるためである。ただし、エンドポートがＭＣＧのマルチキャストルートに組み込まれ、ＱＰが同じＭＣＧのＭＧＩＤに関連付けられている、と想定できる場合、エンドポートには、従来の参加要求の送信およびそれに対する応答の受信を超えてＭＣＧのＭＬＩＤを学習する、他のオプションがある。

【0350】

一実施形態によれば、ＩＢクライアント／ＵＬＰは、ＩＢクライアント／ＵＬＰに関連付けられたエンドポートで受信されたマルチキャストパケットのＭＬＩＤフィールドを検査することからＭＣＧのＭＬＩＤを学習することができる。各マルチキャストパケットには、パケットが関連付けられているＭＣＧのＭＧＩＤも含まれる。したがって、ＩＢクライアント／ＵＬＰは、受信したマルチキャストパケットに含まれるＭＧＩＤを判断し、ＭＬＩＤ（つまり、受信したマルチキャストパケットのＤＬＩＤ）を検査し、検出されたＭＬＩＤを、受信したパケットから判断されるＭＧＩＤによって表されるＭＣＧのＭＬＩＤとして保存する。したがって、ＩＢクライアント／ＵＬＰは、従来のＭＣＧ参加要求を送信およびそれに対する応答を受信することなく、ＭＣＧのＭＬＩＤを動的に学習することができる。

【0351】

ＭＧＩＤを判断し、マルチキャストパケットのＭＬＩＤフィールドを検査して、ＭＣＧのＭＬＩＤを学習する際の課題の１つは、関連するＭＧＩＤを含む最初のマルチキャストパケットが送信されなければならないことである。一実施形態によれば、作成／参加操作を実行するエンドポートによって動的に作成されるＭＣＧに関して、作成するエンドポートに関連付けられるＩＢクライアント／ＵＬＰは、最初のマルチキャストパケット（例えば、無償ＡＲＰ）を送信するように構成することができる。ＭＣＧメンバーエンドポートは、この配信されたパケットで検査を実行することができる。

【0352】

ただし、ＳＭが作成したＭＣＧの場合、マルチキャストグループの作成後に最初のマルチキャストパケットを送信することを担う、作成するＭＣＧメンバーエンドポートはない。一実施形態によれば、そのような場合、ＳＭ／ＳＡ（または関連する特別なサービス‐例えば、ＳＭと協調して実行するデーモン）は、最初のマルチキャストパケットの生成を担い得る。ただし、ＭＣＧについて最初のマルチキャストパケットを生成する場合、ＳＭ（またはデーモン）は、パケットが生成されるべきマルチキャストパケットプロトコルを認識しなくてもよい。一実施形態によれば、任意のＭＣＧメンバーエンドポートに配信され、ＵＬＰ／ＩＢクライアントによって一様に処理されることができる汎用マルチキャストパケットタイプを定義する規則が、最初のマルチキャストパケットを送信する際に、ＳＭによって使用されることができる。このような規則に従って、関連するＩＢクライアント／ＵＬＰは、この規則に準拠するマルチキャストパケットを、パケットに含まれるＭＬＩＤおよびパケットに含まれるその他のＭＬＩＤ関連情報の検査／学習を除き、無視することができる。

【0353】

実施形態によれば、関連するＭＬＩＤおよびＭＧＩＤ（すべてのマルチキャストパケットにデフォルトで含まれる）に加えて、最初のマルチキャストパケットは、含まれるＭＬＩＤがパーティション固有のＭＬＩＤ（つまり、上記のように、関連するパーティションのコンテキストにおいて作成されるすべてのＭＣＧに対するデフォルトＭＬＩＤ）であるかどうかを示す情報を含むことができる。たとえば、最初のマルチキャストパケットの規則またはプロトコルは、最初のマルチキャストパケットが、（たとえば、特別な最初のマルチキャストパケットペイロードおよび／または最初のマルチキャストパケットヘッダ内において、）パーティション固有のＭＬＩＤ、または専用ＭＬＩＤ、を識別するかどうかを示す情報を含んでもよい。最初のマルチキャストパケットがパーティション固有のＭＬＩＤを識別する場合、最初のマルチキャストパケットは、パケットのＭＬＩＤがデフォルトのＭＬＩＤであるパーティションのＰ＿Ｋｅｙを含むこともできる。

【0354】

一実施形態によれば、パーティション固有のデフォルトＭＬＩＤ（上で詳細に説明した）がサブネットで用いられる場合、任意のエンドポートが、特定のパーティションのコンテキストにおいて定義される任意のＭＣＧのＭＬＩＤを、特定のパーティションに関連付けられた任意のマルチキャストパケットのＭＬＩＤを検査することによって、学習することが可能である。これは、別の専用（つまり、パーティション固有ではない）ＭＬＩＤ（または専用ＭＬＩＤのペア）がＭＣＧに関連付けられる場合でも当てはまり、なぜならば、ＩＢには、エンドノードついて、任意のＭＧＩＤとともに用いられるよう特定のＭＬＩＤを実施する要件はなく、ＩＢ仕様では、複数のＭＧＩＤを単一のＭＬＩＤに明示的に関連付けることが許可されるからである。

【0355】

一実施形態によれば、リスティング６は、着信マルチキャストパケットから学習されたＭＬＩＤを既知のＭＧＩＤと関連付け、（必要な場合には）デフォルトのＭＬＩＤテーブルを更新するための例示的な擬似コードを示す。

【0356】

【数7】

【0357】

図４２は、一実施形態による、高性能コンピューティング環境において、関連するＭＧＩＤ（マルチキャストグローバル識別子）について受信マルチキャストメッセージ上でマルチキャストグループマルチキャストローカル識別子（ＭＬＩＤ）ダイナミックディスカバリを提供する方法のフローチャートである。より具体的には、この図は、最初のマルチキャストパケット規則に準拠し、（たとえば、特別な最初のマルチキャストパケットペイロードおよび／または最初のマルチキャストパケットヘッダ内において）最初のマルチキャストパケットがパーティション固有のＭＬＩＤ、または専用ＭＬＩＤ、を識別するかどうかを示す情報を含むパケットを含む着信ＭＣパケットの結果としてＭＬＩＤを登録するためのフローチャートを示す。

【0358】

この方法は、着信マルチキャストパケットを受信するステップ４２０５で開始することができる。マルチキャストパケットが最初のマルチキャストパケット（たとえば、最初のマルチキャスト規則またはプロトコルに準拠するパケット）であり、最初のマルチキャストパケットが専用（非パーティション固有）ＭＬＩＤを示す場合（ステップ４２１０）、
受信パケットからＭＣＧ ＭＬＩＤを反映するローカルＭＣＧ情報を、ステップ４２１５で更新することができる。そうではなく、ステップ４２２５で、マルチキャストパケットが最初のマルチキャストパケットであり、最初のマルチキャストパケットがパーティション固有のＭＬＩＤを示す場合には、ステップ４２３０で、ローカルパーティション情報を更新して、受信したマルチキャストパケットからパーティション固有のＭＬＩＤを反映することができる。そうでない場合には、ステップ４２４５で、この方法は、受信したＭＧＩＤに関連付けられるローカルＭＣＧ情報を見つけることができる。ＭＬＩＤがＭＣＧに関連付けられていないか、またはＭＣＧ ＭＬＩＤがパーティションＭＬＩＤと同じである場合、この方法は、ステップ４２５５で、ローカルＭＣＧ情報を更新して、受信したマルチキャストパケットからＭＬＩＤを反映することができる。

【0359】

一実施形態によれば、リスティング７は、パーティション固有のＭＬＩＤと発信パケットのための専用のＭＬＩＤとの両方を追跡するための例示的な擬似コードを示す。

【0360】

【数8】

【0361】

図４３は、一実施形態による、パーティション固有のＭＬＩＤおよび発信マルチキャストパケット用の専用ＭＣＧ ＭＬＩＤの両方のレコードを維持するためのフローチャートを示す。ステップ４３０５で、発信ＭＣパケットからＭＧＩＤが検索される。ステップ４３１０で、検索されたＭＧＩＤのＭＣＧレコードが探索される。判断４３１５で、ＭＣＧレコードが専用ＭＣＧ ＭＬＩＤを反映する場合、ステップ４３２０でパケット宛先ＬＩＤがＭＣＧレコードからの専用ＭＣＧ ＭＬＩＤに設定され、ＭＣパケットはステップ４３５０で送信される。そうではなく、ＭＣＧに関連付けられるパーティションが、関連付けられたデフォルト（パーティション固有）ＭＬＩＤを有する場合には（ステップ４３２５）、パケット宛先ＬＩＤはＭＣＧのパーティションに関連付けられたデフォルトＭＬＩＤに設定され、ＭＣパケットはステップ４３５０で送信される。そうでなければ（ステップ４３３５で）、この方法は、マルチキャストパケットを送信することができる前にＭＬＩＤを判断しなければならないことを記録することができ、ステップ４３３５でタイムアウト期間を開始することができる。関連するＭＧＩＤのＭＬＩＤが判断されたかどうかは
、タイム期間が終了するまで引き続きチェックされることができる。ＭＬＩＤがタイムアウト期間の満了までに判断されていない場合、この方法はタイムアウトして終了することができる（ステップ４３５５）。ただし、タイムアウト期間内に（たとえば、ステップ４３１５または４３２５のいずれかで）ＭＬＩＤが判断される場合、正しいＭＬＩＤでパケットを送信することができる。

【0362】

含まれるＭＬＩＤの検査／学習のための最初のマルチキャストパケットの配信に関連するさらに別の課題は、ホストノードおよび関連付けられるエンドノードがサブネットの開始／初期化においてだけでなく、いつでも開始／初期化できることである。したがって、このような遅延到着ノード／ＵＬＰ／エンドポートが関連するＭＬＩＤを効果的に学習できるようにすることを保証するために、「最初の」ＭＣパケット（たとえば、上記のように、ＭＬＩＤ学習パケット規則に準拠する最初のマルチキャストパケット）の、定期的な、時間を設定された送信は、遅延開始／初期化ノード／エンドポートによるＭＬＩＤ学習が妥当な遅延内でＭＬＩＤを学習することができるように実行されなければならない。

【0363】

一実施形態によれば、リスティング８は、特別な最初のマルチキャストパケットプロトコルの使用と、ＩＰｏＩＢが有効にされた状態でのパーティションにおける逆アドレス解決プロトコル（ＲＡＲＰ）などのプロトコルの利用との両方で、最初のマルチキャストパケットを送信するための例示的な擬似コードを示す。このコードは、たとえば、関連するＭＣＧの作成を担当するコンポーネントに関連付けられたＳＭ共存デーモンから実行することができる。関連するパーティションごとに１つのデーモンコンテキストが存在することができる。

【0364】

【数9】

【0365】

図４４は、一実施形態による、高性能コンピューティング環境においてマルチキャストローカル識別子のエンドノードダイナミックディスカバリを提供する方法のフローチャートを示す。ステップ４４１０で、サブネットのマルチキャストグループを定義するマルチキャストグローバル識別子が、サブネットのノードでマルチキャストグループレコードに含まれる。ステップ４４２０で、ノードのポートに関連付けられるキューペアが、サブネット内のマルチキャストグループを定義するマルチキャストグローバル識別子に関連付けられ、それにより、キューペアをマルチキャストグローバル識別子に関連付けることにより、ポートが、マルチキャストグローバル識別子を含むマルチキャストパケットを受信することを可能にする。ステップ４４３０で、マルチキャストグローバル識別子およびマルチキャストローカル識別子を含むマルチキャストパケットがノードで受信される。ステップ４４４０で、マルチキャストパケットは、マルチキャストローカル識別子を学習するために検査される。ステップ４４５０で、学習されたマルチキャストローカル識別子は、サブネットのノードでマルチキャストグループレコードに含まれる。

【0366】

デフォルトおよび専用ＭＬＩＤの明示的なＭＬＩＤ割り当て
従来の実装例では、異なるマスターＳＭインスタンスが、ローカル状態情報に基づいて、およびＩＢクライアントが新たなマルチキャストグループが定義されるよう要求した結果として、ＭＬＩＤ値を割り当てる。このような場合では、どのようなマスターＳＭの再
起動もしくはフェールオーバー、またはどのようなサブネットマージ操作も、異なるＭＬＩＤが異なるＭＧＩＤに用いられる（つまり、ことなるＭＧＩＤからＭＬＩＤへのマッピング）に至る可能性があり、それによって、マルチキャスト通信が関連するエンドポート間で再び完全に動作可能になる前に些細ならぬ遅延を生じる可能性がある。

【0367】

一実施形態によれば、（上記のような）パーティション固有のデフォルトＭＬＩＤ値が使用中である実装例において、どのＭＬＩＤがどのパーティションに用いられるかを明示的に定義する明示的なＭＬＩＤ割り当てポリシーを（例えば管理入力として）提供することができる。さらに、ＭＬＩＤ割り当てポリシーは、どの専用ＭＬＩＤを所与のＭＧＩＤに関連付けるかを定義することもできる（たとえば、パーティションに依存しないＭＬＩＤ）。このようなＭＬＩＤ割り当てポリシーを採用することにより、新たなまたは再起動されたマスターＳＭは、新たなＭＧＩＤからＭＬＩＤへのマッピングを生成する代わりに、既存のＩＢパーティションに用いられるＭＬＩＤを観察（および検証）することができる。このようにして、対応するＭＧＩＤに対するＭＬＩＤ関連付けにおける変更を、マスターＳＭの再起動もしくはフェールオーバーまたはサブネットマージ操作の結果として、回避することができる。

【0368】

図４５は、一実施形態による、ＳＭポリシー入力として定義されるパーティション固有のデフォルトＭＬＩＤについて明示的なマルチキャストローカル識別子（ＭＬＩＤ）割り当てを提供する方法のフローチャートを示す。ステップ４５００で、この方法は、サブネットのサブネットマネージャに、複数のパーティションのうちのあるパーティションについてデフォルトＭＬＩＤ値を提供することができる。ステップ４５０５で、この方法は、サブネットへのアクセスおよび制御を有するマスターサブネットマネージャをオフラインにすることができる。ステップ４５１０で、この方法は、サブネットへのアクセスおよび制御を有する新たなマスターサブネットマネージャを起動することができる。ステップ４５１５で、この方法は、複数のパーティションのうちのあるパーティションのデフォルトＭＬＩＤ値を新たなマスターサブネットマネージャに提供することができる。ステップ４５２０で、この方法は終了することができる。

【0369】

図４６は、一実施形態による、ＳＭポリシー入力として定義されるパーティションごとのデフォルトＭＬＩＤについて明示的なマルチキャストローカル識別子（ＭＬＩＤ）割り当てを提供する方法のフローチャートを示す。特に、図４６は、サブネット再ディスカバリ中に既存のＭＬＩＤ／Ｐ＿Ｋｅｙインデックス（たとえば、前述のＰ＿ＫｅｙテーブルからデフォルトのＭＬＩＤテーブルへのマッピング）関連付けを検証する方法のフローチャートである。この方法は、サブネットディスカバリを実行し、発見されたＨＣＡポートについてＰ＿Ｋｅｙテーブルの内容および任意の定義済みのＭＬＩＤテーブルの両方をキャッシュすることができる。発見された各ＨＣＡポートについて、キャッシュされたＰ＿Ｋｅｙテーブルの内容が現在のメンバーシップポリシーと同期していない場合、この方法はＣＡポートがパーティションテーブルの更新を必要とすることを記録することができる。それ以外の場合、ＨＣＡポートがＭＬＩＤテーブルをサポートし、かつＭＬＩＤテーブルが現在のＰ＿Ｋｅｙテーブルと同期していないか、またはＭＬＩＤテーブルの内容が現在のＰ＿ＫｅｙごとのＭＬＩＤ割り当てと同期していない場合には、この方法はＨＣＡポートがＭＬＩＤテーブルの更新を必要とすることを記録することができる。次に、この方法は、サブネットの再ルーティングを実行し、パーティションメンバーシップが変更されたパーティションごとのＭＬＩＤに新たなスパニングツリーを生成することができる。この方法は、次いで、Ｐ＿Ｋｅｙテーブルおよび／またはＭＬＩＤテーブルの更新に対する記録されたニーズに従って、サブネットの再初期化を実行し、各ＣＡポートを更新することができる。

【0370】

一実施形態によれば、ＭＬＩＤ割り当てポリシーは、４つのポリシー変数の値を指定す
ることができる。ＭＬＩＤ割り当てポリシーは、（たとえば、管理入力を介して）サブネットにおいて明示的に定義されるＭＣＧに割り当てられるＭＬＩＤの範囲の開始値と終了値とを指定することができる。さらに、ＭＬＩＤ割り当てポリシーは、エンドポートによって動的に作成されるＭＣＧに割り当てられるＭＬＩＤの範囲の開始値と終了値とを指定することができる。ＭＬＩＤは各タイプのＭＣＧに割り当てられるので、割り当ては、たとえば不揮発性フォーマットで保存することができ、現在のマスターＳＭおよび将来のＳＭは、ＭＬＩＤからＭＧＩＤ（つまり、ＭＣＧ）へのマッピングを判断することができ、新たなＭＬＩＤからＭＧＩＤへのマッピングを作成する代わりに、これらのマッピングを再利用することができる。

【0371】

従来の実装例では、サブネット内のすべてのパーティション定義は、ＳＭへの明示的なポリシー入力に基づいている。一実施形態によれば、従来のパーティションポリシー入力規則を拡張して、明示的なＭＬＩＤ割り当てポリシーを含めることができる。たとえば、ＳＭは、パーティションを作成するためのサブネットパーティションポリシー入力を受信することができる。ポリシー入力には、パーティション番号（つまりＰ＿Ｋｅｙ）、パーティション名、ＩＰｏＩＢフラグ（ＩＰｏＩＢがパーティションメンバーに対して有効にされることを示す）、およびサブネット内のポートのメンバーシップ仕様を含めることができる。さらに、ポリシー入力には、ポリシー入力の結果としてパーティションのコンテキストにおいて作成されるＭＣＧに割り当てられるＭＬＩＤの値であるＭＬＩＤ値を含めることができる。一実施形態によれば、ポリシー入力に含まれるＭＬＩＤ値は、正規パーティションメンバーＭＬＩＤの値を示し、制限付きパーティションＭＬＩＤ値を導出することができる（またはその逆）（上述の）規則に準拠するベース値とすることができる。

【0372】

一実施形態によれば、例えば上記の明示的なポリシー入力を用いて、パーティションのコンテキストにおいてＭＣＧが作成される場合、ＭＬＩＤ値は、サブネットにおいて明示的に定義されるＭＣＧについて割り当てられるＭＬＩＤの範囲からのＭＬＩＤ値であることができる。一実施形態によれば、ＭＬＩＤ値は、ポリシー入力で明示的に定義されなくてもよく、サブネットにおいて明示的に定義されるＭＣＧについて割り当てられるＭＬＩＤの範囲から、ＳＭによって、割り当てられることができる。

【0373】

一実施形態によれば、ＭＬＩＤ割り当てポリシーを採用するサブネットでは、ＭＬＩＤからＭＧＩＤへのマッピングを変更することなく、サブネットのマージおよび分割を行うことができる。独立したサブネット間のスイッチ間クロスリンクは、ＭＬＩＤからＭＧＩＤへの再マッピングを必要とせずに、ＭＣパケットの選択的な転送に用いることができる。さらに、グローバルルートヘッダからローカルルートヘッダへのマッピングを実行するべくヘッダマッピングリソースを割り当てる必要なく、異なるＩＢサブネット間のＩＢ間ルータベースの接続を実現することができる。

【0374】

図４７は、一実施形態による、サブネットマージ操作前において、ＳＭポリシー入力として定義されるパーティション固有のデフォルトＭＬＩＤに対する明示的なマルチキャストローカル識別子（ＭＬＩＤ）割り当てを各々が有する２つの独立したファットツリーベースのサブネットを示す。図４７に示すように、各サブネット、サブネット４７０２および４７０４には、各サブネットのスパニングツリーのルートとして単一のスパインスイッチを有する、関連するＭＣＧ／ＭＬＩＤのためのスパニングツリーが含まれる。サブネット４７０２では、スパインスイッチ４７３０は、（スイッチ４７３０を定義する太線で示されているように）サブネット４７０２のスパニングツリーのルートである。同様に、スイッチ４７３３は、サブネット４７０４のスパニングツリーのルートである。一実施形態に従って（例えば、上記のように）、スパニングツリーが生成され、対応するＭＦＴがスイッチに配布されている。

【0375】

引き続き図４７を参照すると、一実施形態によれば、サブネット４７０２のスパニングツリーは、スイッチ４７３０をサブネット４７０２のスパニングツリーのルートとして示すことができる。この場合、スパニングツリーには、スイッチ４７３１への／からのリンクは含まれない。同様に、サブネット４７０４のスパニングツリーは、スイッチ４７３３をサブネット４７０４のスパニングツリーのルートとして示すことができ、スイッチ４７３２への／からのリンクは含まない。

【0376】

図４８は、サブネットマージ操作後において、ＳＭポリシー入力として定義されるパーティション固有のデフォルトＭＬＩＤに対する明示的なマルチキャストローカル識別子（ＭＬＩＤ）割り当てを有する単一のファットツリーベースのサブネットを示す。図４８に示すように、サブネットマージ操作は、元の各サブネット（つまり、図４７のサブネット４７０２および４７０４）からスパインを相互接続することによって実現される。一実施形態によれば、各元のサブネットで同じポリシーベースのＭＬＩＤを採用しながら、マージ後に必要な唯一の再構成は、相互転送を実行するようスパインスイッチ４８３０および４８３３のＭＦＴを更新することにより２つの元のスパニングツリーを論理的に接続することである。したがって、スイッチ４８３０に到着し、スイッチ４８３３の下流で接続されているエンドポートに向かうすべてのマルチキャストトラフィックをスイッチ４８３３に転送する、スイッチ４８３０のＭＦＴにおけるエントリを作成することができる。このようなパケット（スイッチ４８３０から転送される）がスイッチ４８３３に到着すると、ＭＬＩＤ割り当てポリシーの結果として生成された元のＭＦＴは、パケットをＭＣＧメンバーのエンドポートに転送する。したがって、スパインスイッチ４８３０のＭＦＴのみをサブネットマージの結果として更新する必要がある。同様に、スパインスイッチ４８３３のＭＦＴのみを更新して、スイッチ４８３３で受信されスパインスイッチ４８３０の下流のエンドポートに向かうパケットをスイッチ４８３０に転送する必要がある。スパインスイッチの「下流」エンドポートは、たとえばＨＣＡ４８０１～４８１２となるであろう。

【0377】

アナウンスメントおよびディスカバリのためのデフォルトマルチキャストグループ（ＭＣＧ）
一実施形態によれば、ＩＢ仕様は、ＳＡ要求に用いられるＬＩＤおよびＳＬ（サービスレベル）値を指定するPortInfo要素を定義することにより、および各ポートがデフォルトパーティションの少なくとも限定付きメンバーであることを指定することにより、ノードからのＩＢ通信のブートストラップの問題を解決する。

【0378】

一実施形態によれば、同様に、ＩＰ‐ｏｖｅｒ‐ＩＢ仕様（ＩｎｆｉｎｉＢａｎｄ仕様の一部ではない）は、ＩＰからＩＢへのアドレス解決に用いることができるデフォルトマルチキャストグループ（ＭＣＧ）を定義する。ただし、ＩＰ‐ｏｖｅｒ‐ＩＢはＩＢ仕様の一部ではないため、汎用ＩＢのディスカバリ、アナウンスメント、およびアドレス解決スキームに関して依存することができる機能ではない。

【0379】

したがって、実施形態によれば、ＳＡアクセスに依存せずに充分に定義された方法でＩＢマルチキャスト動作を可能にするために、少なくとも１つのＩＢマルチキャストグループ（ＭＣＧ）をサブネットマネージャによって定義し、拡張ＳＭＡ属性を介してＩＢクライアントに通信することができる。

【0380】

一実施形態によれば、ＭＣＧ定義を追加のＳＭＡレベル情報として含めることにより、異なるＩＢクライアントバージョンが関連付けられるＭＧＩＤに関して同期していることに対する依存性はない。また、サブネットマネージャは、現在予約されていない１つ以上のＭＧＩＤ値を予約し、ＳＭが自身の使用のために予約するよう意図するＭＧＩＤ値を伴うＭＣＧの作成を防ぐこともできる。

【0381】

一実施形態によれば、ＳＭＡレベルで定義される専用ＭＣＧの追加的局面は、それが関連するポートに対して定義される任意のパーティションとともに用いることができるように指定することができることであり、その場合、ＩＢクライアントは、ＭＣメッセージを送信するときに、そのパーティションに定義されたパーティション固有のＭＬＩＤを用いることができる。

【0382】

一実施形態によれば、基本的なアナウンスメントプロトコルを実装するために、ポートおよびノード属性のピアツーピア交換に用いられるものと同じメッセージフォーマットを用いることができる。ただし、この場合、送信元のアドレス情報のみが指定され、ターゲットは指定されず、応答も期待されない。

【0383】

一実施形態によれば、アドレス解決およびディスカバリも実施するために、１つの特定のノードからの期待される応答とともにターゲットＧＩＤまたはＧＵＩＤを指定する１つの要求メッセージフォーマットを用いることができる。また、利用可能なピアノードの一般的なディスカバリを可能にするために、完全または部分的にワイルドカード化されたターゲットを指定し、すべての関連する受信者がユニキャスト応答をそれらのローカル情報とともに送信することができる。‐このスキームは、送信されるマルチキャストメッセージが少ないことを意味するため、ＩＢファブリックを介して転送され、異なるノードで受信される「無関係な」マルチキャストメッセージの数に関して全体のオーバーヘッドが削減される。

【0384】

一実施形態によれば、上記の開示により、様々なＩｎｆｉｎｉＢａｎｄ仕様の強化／追加が企図される。このような追加のＳＭＡ属性の１つは、デフォルト値が偽の「DefaultMCG（デフォルトＭＣＧ）」をサポートするポート機能である。この属性は、リンクアップ時に、サポートするＳＭＡによって真にセットすることができる。真にセットすると、ＳＭまたはマスターＳＭは関連するＳＭＡプロパティを更新することができる。

【0385】

一実施形態によれば、１２８ビット整数である「DefaultMCGMGID（デフォルトＭＣＧＭＧＩＤ）」を設定することができる（デフォルト０‐すなわち、DefautlMCGポート機能が偽の場合）。

【0386】

一実施形態によれば、３２ビット整数である「DefaultMCGMQ_Key」を設定することができる（デフォルト０‐すなわち、DefautlMCGポート機能が偽の場合）。

【0387】

一実施形態によれば、ＩＢ仕様は、従来のＭＣＧメタデータを、ＭＧＩＤ、Ｐ＿Ｋｅｙ、ＭＬＩＤ、および他の属性を含むものとして定義する。上記で企図されることは、新たなＭＣＧ対複数のＭＬＩＤ（またはＭＬＩＤペア）値の関連付けを定義する。特別なＭＣＧメタデータは、（たとえば、拡張PortInfoのからの「FabricGlobalMinimalPathParameters」に基づいて、）（拡張PortInfoからの）ＭＧＩＤ、パーティショングローバルフラ
グ、およびその他の属性を含むことができる。PartitionGlobalFlagは、ＭＣＧを、ロー
カルで定義されたＰ＿Ｋｅｙ値および対応するＰ＿Ｋｅｙ固有のＭＬＩＤとともに、送信時の宛先ＭＬＩＤとして用いることができることを意味する。

【0388】

一実施形態によれば、アナウンスメントマルチキャストメッセージを提供することができる。アナウンスメントＭＣメッセージは、ＭＣメッセージのＧＲＨおよびＬＲＨの一部として送信元ＧＵＩＤおよび送信元ＬＩＤを含むことができる。アナウンスメントメッセージの受信者は、送信元に関するキャッシュされた情報を更新することができる。

【0389】

一実施形態によれば、ターゲット固有のディスカバリ要求ＭＣメッセージを提供することができる。このメッセージは、ＭＣメッセージのＧＲＨおよびＬＲＨの一部として、送
信元ＧＵＩＤおよび送信元ＬＩＤを含むことができる。メッセージタイプは、ターゲットディスカバリメッセージであってもよい。このアナウンスメントメッセージの受信者は、指定されたターゲット情報がローカル情報の完全一致またはワイルドカード一致を表すかどうかを確認し、該当する場合はユニキャスト応答を関連するローカル情報とともに送信することができる。

【0390】

一実施形態によれば、上記の開示により、様々なＩｎｆｉｎｉＢａｎｄ仕様の強化／追加が企図される。そのような拡張機能の１つは、新たなクラスのアナウンスメントおよびディスカバリプロトコルメッセージである。これらには、アナウンスメントマルチキャストメッセージ、ターゲット固有のディスカバリ要求マルチキャストメッセージ、およびディスカバリ応答ユニキャストメッセージを含めることができる。

【0391】

図４９は、一実施形態による、高性能コンピューティング環境において拡張ポート情報としてアナウンスメントおよびディスカバリのためにデフォルトマルチキャストグループ（ＭＣＧ）を提供する方法のフローチャートを示す。

【0392】

一実施形態によれば、ステップ４９００で、この方法はサブネットを提供することができ、サブネットは２つ以上のノードを含み、２つ以上のノードの第１のノードは第１のバージョンの仕様を含み、第２のノードは第２のバージョンの仕様を含む。

【0393】

一実施形態によれば、ステップ４９０５で、この方法は、サブネットマネージャによって、デフォルトＭＧＩＤとして用いられるマルチキャストグローバル識別子を予約する。

【0394】

一実施形態によれば、ステップ４９１０で、この方法は、サブネット管理エージェントで、デフォルトＭＧＩＤを含むマルチキャストグループ定義を提供する。

【0395】

一実施形態によれば、ステップ４９１５で、この方法はサブネットの他の要素を発見することができ、このディスカバリは少なくともマルチキャストグループ定義に基づいている。

【0396】

図５０は、一実施形態による、高性能コンピューティング環境において拡張ポート情報としてアナウンスメントおよびディスカバリのためにデフォルトマルチキャストグループ（ＭＣＧ）を提供する方法のフローチャートを示す。

【0397】

実施形態によれば、ステップ５０１０で、この方法は、１つ以上のマイクロプロセッサにおいて、第１のサブネットを提供することができ、第１のサブネットは複数のスイッチを含み、複数のスイッチは少なくともリーフスイッチを含み、複数のスイッチの各々は、複数のスイッチポートのうちの少なくとも１つのスイッチポートを含み、第１のサブネットは、さらに、複数のホストチャネルアダプタを含み、各ホストチャネルアダプタは、複数のホストチャネルアダプタポートのうちの少なくとも１つのホストチャネルアダプタポートを含み、複数のホストチャネルアダプタは複数のスイッチを介して相互接続され、第１のサブネットは、さらに、サブネットマネージャを含み、サブネットマネージャは、複数のスイッチおよび複数のホストチャネルアダプタの一方で実行される。

【0398】

一実施形態によれば、ステップ５０２０で、この方法は、サブネットマネージャによって、少なくともマルチキャストグローバル識別子（ＭＧＩＤ）によって定義されるマルチキャストグループを定義することができる。

【0399】

一実施形態によれば、ステップ５０３０で、この方法は、定義されたＭＣＧを、複数のホストチャネルアダプタに対して、ＭＧＩＤとともに、サブネット管理エージェント（Ｓ
ＭＡ）属性を介して、通信することができる。

【0400】

一実施形態によれば、ステップ５０４０で、この方法は、複数のエンドノードのうちの送信側エンドノードを介して、定義されたＭＣＧを利用するアナウンスメントメッセージを複数のエンドノードに送信することができ、このアナウンスメントメッセージは少なくとも送信側エンドノードのローカル識別子を含む。

【0401】

スケーラブル転送用のデフォルトマルチキャストグループプロキシ（５８３６）
一実施形態によれば、情報を交換する必要があるノードの数が増加すると、すべてのＮ個のノードが他のすべてのノードに対してアドレス解決を実行するようマルチキャストメッセージを送信する際に基本的な複雑さがＮ乗されるため、ブロードキャストベースのアナウンスメントおよびディスカバリ／アドレス解決プロトコルのスケーラビリティが低下する。

【0402】

一実施形態によれば、単一の要求マルチキャストメッセージにおける複数のターゲットノードのアドレス解決の要求の集約により、スケーラビリティを高めることができるが、大きなノードセットの場合、これは依然として限られたスケーラビリティを有する。

【0403】

一実施形態によれば、任意の数のノードをカバーするようにプロトコルをスケーリングするために、システム全体が複数のドメインに分割され、各ドメインが関連プロトコルのＭＣＧプロキシインスタンスによって表される階層スキームを導入することができる。

【0404】

一実施形態によれば、そのような各プロキシインスタンスは、それのドメイン内のノードからＭＣベースのアナウンスメントおよび要求を受信することができるが、そのようなＭＣ要求はローカルドメインの境界を越えて直接送信されないであろう。代わりに、さまざまなプロキシは、プロキシ間のＭＣベースのプロトコルの組み合わせ、およびプロキシのペア間のピアツーピアトラフィックとしてのデータのバルク転送を介して、情報を交換することができる。

【0405】

一実施形態によれば、プロキシは、サブネット／ファブリック内のＳＭと協働することもでき、ＳＭに代わって、利用可能なノードのためにＭＣベースのアナウンスメントを送信することができる（すなわち、ユニキャストベースのＳＡイベント通知と同様）。

【0406】

一実施形態によれば、特権プロキシは、関与するクライアントノードに対してプロキシの存在を透過的にする態様で、他のノードに代わってメッセージを送信することができるモードで動作することを許可されてもよい。この場合、プロキシは、要求または応答を転送するときに、関連するノードのソースアドレス情報を用いることができるであろう。

【0407】

一実施形態によれば、このようにして、デフォルトパーティション（参照管理パーティション）において正規メンバーとして動作するプロキシは、制限付きメンバークライアントノードからのディスカバリ要求に応答することができ、それにより、関与するクライアントノードの実際のパーティションメンバーシップに基づく可視性ルールを実施することができるであろう。

【0408】

一実施形態によれば、プロキシにより転送または生成される要求、応答、およびアナウンスメントは、プロキシインスタンスを含むものとして明示的に識別されてもよい。この場合、そのようなメッセージを受信するクライアントノードは、メッセージのＩＢソースアドレスが、メッセージが関係する関連のピアノードにではなく、プロキシに関連付けられていることを知っているだろう。

【0409】

単一のサブネット内のドメイン間で必要な分離を提供するために、ＳＭはドメイン境界およびさまざまなプロキシインスタンスを識別することができる必要があり、単一の論理ＭＣＧでも、マルチキャストルーティングが設定され、非プロキシにより送信されるＭＣパケットは、ドメインから外に転送されない。

【0410】

一実施形態によれば、異なるＩＢスイッチ間にドメイン境界が存在する限り、同じＭＬＩＤを、異なるドメインにおいて、ドメイン間の「偶発的な転送」なしに用いることができる。ただし、１つのＩＢスイッチを２つの異なるドメインで共有する場合、同じ論理ＭＣＧについて２つのＭＬＩＤを割り当てなければならないであろう。したがって、実際には、単一のスイッチ内にドメイン境界があることは意味をなさないであろう。

【0411】

一実施形態によれば、ファットツリーベースのトポロジーでは、個々のリーフスイッチを単一のドメインとして有することは意味をなすであろうと考えられるか、または、独自のスイッチのセットを有するが、関与するすべてのリーフスイッチ間に完全に冗長な物理接続を有するサブツリーが、ドメインを表し得る。

【0412】

一実施形態によれば、様々なＩＢ仕様の拡張が想定される。１つのそのような拡張は、アナウンスメントおよびディスカバリプロトコルメッセージの拡張であり得る。このような拡張により、プロキシの生成および転送の明示的な表現が可能になるであろう。

【0413】

一実施形態によれば、別のそのような拡張は、プロキシ間通信用の特定のプロトコルを可能にすることができるが、ベンダー、コンソーシアム、またはディストリビューション固有の革新および付加価値のための領域として残すこともできる。

【0414】

一実施形態によれば、ドメインおよびプロキシ対応のマルチキャストルーティングを提供するために、ＳＭは、ドメイン境界および個々のプロキシポートの両方を認識しなければならない。これは、ＳＭ実装固有の構成ポリシーを介して実現することができるか、または、プロキシの存在およびドメイン境界の両方がノードローカル構成情報を表す場合には、インバンドディスカバリを介して実現することができるかもしれない。

【0415】

図５１は、一実施形態による、高性能コンピューティング環境においてアナウンスメントのスケーラブルな転送および情報要求インターセプトのためにデフォルトマルチキャストグループ（ＭＣＧ）プロキシを提供する方法のフローチャートを示す。

【0416】

一実施形態によれば、ステップ５１００で、この方法は、階層を複数のドメインに分割することができ、複数のドメインの各々は、マルチキャストグループプロキシインスタンスを含む。

【0417】

一実施形態によれば、ステップ５１０５で、この方法は、ＭＣＧプロキシインスタンスで、ＭＣＧプロキシインスタンスのドメイン内のノードからＭＣベースのアナウンスメントを受信することができる。

【0418】

一実施形態によれば、ステップ５１１０において、この方法は、ＭＣＧプロキシインスタンスにより、別のドメイン内の別のＭＣＧプロキシインスタンスに、ＭＣベースのアナウンスメントに含まれる情報を送信することができる。

【0419】

一実施形態によれば、ステップ５１１５で、この方法は、ＭＣＧプロキシインスタンスにより、ＭＣベースのアナウンスメントに含まれる情報をサブネットマネージャに送信することができる。

【0420】

一実施形態によれば、ステップ５１２０で、この方法は終了することができる。
図５２は、一実施形態による、高性能コンピューティング環境においてアナウンスメントのスケーラブルな転送および情報要求インターセプトのためにデフォルトマルチキャストグループ（ＭＣＧ）プロキシを提供するシステムを示す。

【0421】

より具体的には、この図は、プロキシインスタンスが各リーフスイッチに関連付けられる任意のファブリックのシステムを示す。システム５２００は、ドメインＡ ５２５０、ドメインＢ ５２５１、ドメインＣ ５２５２など、いくつかの任意のドメインに分割することができる。このシステムは、ＨＣＡ１～ＨＣＡ９ ５２１０～５２１８などの多数のホストチャネルアダプタ、およびスイッチ１～スイッチ６ ５２４０～５２４５などのＨＣＡを相互接続する多数のスイッチを含むことができる。ＨＣＡは、１つの以上のホスト／エンドノード（図示せず）をシステム５２００に接続した。

【0422】

一実施形態によれば、特定のスイッチ（例えば、定義された各ドメイン内の１つのスイッチ）をプロキシとして定義することができる。図示の実施形態では、スイッチ１ ５２４０、スイッチ３ ５２４２、およびスイッチ５ ５２４４がプロキシとして定義される。特定の実施形態では、これらのスイッチは、特定のプロトコルのマルチキャストグループプロキシインスタンスとして定義することができる。

【0423】

一実施形態によれば、そのような各プロキシインスタンスは、それのドメイン内のノードからＭＣベースのアナウンスメントおよび要求を受信することができるが、そのようなＭＣ要求はローカルドメインの境界を越えて直接送信はされないであろう。代わりに、さまざまなプロキシは、情報を、他のプロキシとの間で、ＭＣベースのプロトコルを組み合わせを介して交換したり、プロキシのペア間で、ピアツーピアトラフィックとして、データのバルク転送を介して交換したりすることができる。

【0424】

一実施形態によれば、プロキシは、サブネット／ファブリック内のＳＭと協働することもでき、ＳＭに代わって、利用可能なノードのためにＭＣベースのアナウンスメントを送信することができる（すなわち、ユニキャストベースのＳＡイベント通知と同様）。

【0425】

図５３は、一実施形態による、高性能コンピューティング環境においてアナウンスメントのスケーラブルな転送および情報要求インターセプトのためにデフォルトマルチキャストグループ（ＭＣＧ）プロキシを提供するシステムを示す。

【0426】

より具体的には、この図は、プロキシが特定のサイズ‐単一レベル‐の各サブツリーに関連付けられる中規模のファットツリーベースのファブリックを示す。スイッチプロキシ１ ５３０１は、左サブツリーまたはサブツリー１ ５３３０を処理し、サブツリー１ ５３３０は、スイッチ１ ５３１０およびスイッチ２ ５３１１と、ＨＣＡ１～ＨＣＡ３
５３２０～５３２２とを含む。同様に、スイッチプロキシ２ ５３０２は、右サブツリーまたはサブツリー２ ５３３１を処理し、サブツリー２ ５３３１は、スイッチ３ ５３１２およびスイッチ４ ５３１３と、ＨＣＡ４～ＨＣＡ６ ５３２３～５３２５とを含む。

【0427】

図５４は、一実施形態による、高性能コンピューティング環境においてアナウンスメントのスケーラブルな転送および情報要求インターセプトのためにデフォルトマルチキャストグループ（ＭＣＧ）プロキシを提供するシステムを示す。

【0428】

より具体的には、この図は、プロキシが階層的なサブツリー、複数のレベルに関連付けられる、大きなファットツリーベースのファブリックを示す。太字の境界線を有するスイッチはプロキシインスタンスを表し、１つは各スパインベースのサブツリーにあり、１つ
はスパインレベルプロキシ間の集約を提供するルートスイッチレベルにある。

【0429】

一実施形態によれば、ファブリックは、ＨＣＡ ５４０１～ＨＣＡ ５４１２などのいくつかのＨＣＡ、およびツリートポロジーの様々なレベルにおけるいくつかのスイッチを含むことができる。図示の実施形態では、スイッチ５４２０～５４２７はリーフレベルスイッチであり、スイッチ５４４０～５４４３はルートレベルスイッチである。スイッチ５４３０～５４３３は中間レベルのスイッチである。

【0430】

一実施形態によれば、太字の境界線を有するスイッチ、すなわち、スイッチ５４３０、スイッチ５４３２、およびスイッチ５４４０は、プロキシインスタンスを表す。スイッチ５４３０は左端のサブツリーのプロキシインスタンスであり、スイッチ５４３２は右端のサブツリーのプロキシインスタンスである。スイッチ５４４０は、サブツリープロキシインスタンス間の集約を提供するルートレベルのプロキシインスタンスである。

【0431】

図５５は、一実施形態による、高性能コンピューティング環境においてアナウンスメントのスケーラブルな転送および情報要求インターセプトのためにデフォルトマルチキャストグループ（ＭＣＧ）プロキシを提供する方法のフローチャートを示す。

【0432】

一実施形態によれば、ある方法では、プロキシは、他のプロキシに転送するか、または他のプロキシと相談する必要があってもよい。

【0433】

一実施形態によれば、この方法は、ステップ５５０１でメッセージを受信することができる。この方法は、ステップ５５０２でメッセージの内容に基づいてローカル情報を更新することができる。受信したメッセージがローカルドメイン内のノードからの情報要求であり、関連情報がローカルにキャッシュされている場合、この方法はステップ５５０４で応答メッセージを関連情報とともに送信することができる。関連情報がローカルにキャッシュされていない場合、この方法は、ステップ５５０５で関連のピアプロキシのセットに情報要求を送信することができる。

【0434】

一実施形態によれば、受信したメッセージが異なるドメイン内のプロキシからの情報要求である場合、この方法は現在キャッシュされているローカル情報に基づいて応答を送信することができる。

【0435】

一実施形態によれば、受信したメッセージが別のドメイン内のプロキシからの応答または更新である場合、この方法は、受信した情報を待っていた保留中の要求を完了することができる。この方法は、ローカルドメインの関連ノードに更新通知を送信し、他のドメインの関連プロキシに更新通知を送信することができる。

【0436】

図５６は、一実施形態による、高性能コンピューティング環境においてアナウンスメントのスケーラブルな転送および情報要求インターセプトのためにデフォルトマルチキャストグループ（ＭＣＧ）プロキシを提供する方法のフローチャートを示す。

【0437】

ステップ５６０１で、この方法はプロキシでメッセージを受信することができる。
ステップ５６０２で、この方法は、メッセージの内容に基づいてローカル情報を更新することができる。

【0438】

ステップ５６０３で、この方法は、受信したメッセージがローカルドメイン内のノードからの情報要求メッセージであったかどうかを判断することができる。

【0439】

ステップ５６０４で、メッセージがローカルドメイン内のノードからの情報要求メッセ
ージである場合、この方法は、関連情報がローカルにキャッシュされているかどうかを判断することができる。

【0440】

ステップ５６０５で、関連情報がローカルにキャッシュされている場合、プロキシは応答メッセージを関連情報とともに送信することができる。

【0441】

ステップ５６０６で、関連情報がローカルにキャッシュされていない場合、プロキシは関連のピアプロキシのセットに情報要求を送信することができる。

【0442】

ステップ５６０７で、受信したメッセージが別のドメインのプロキシからのものであった場合、この方法は、受信したメッセージが別のドメインのプロキシからの情報要求であったかどうかを判断することができる。

【0443】

ステップ５６０８で、受信したメッセージが別のドメインのプロキシからの情報要求であった場合、プロキシは現在キャッシュされているローカル情報に基づいて応答を送信することができる。

【0444】

ステップ５６０９で、メッセージが別のドメインのプロキシからの情報要求でなかった場合、プロキシはメッセージが別のドメインのプロキシからの応答または更新であったかどうかを判断することができる。

【0445】

ステップ５６１０で、メッセージが別のドメインのプロキシからの応答または更新であったという判断で、プロキシは、受信した情報を待っていた保留中の要求を完了することができる。

【0446】

ステップ５６１１で、プロキシは、更新通知をローカルドメイン内の関連するノードに送信することができる。

【0447】

ステップ５６１２で、プロキシは更新通知を他のドメイン内の関連するプロキシに送信することができる。

【0448】

図５７は、一実施形態による、高性能コンピューティング環境においてアナウンスメントのスケーラブルな転送および情報要求インターセプトのためにデフォルトマルチキャストグループ（ＭＣＧ）プロキシを提供する方法のフローチャートを示す。

【0449】

実施形態によれば、ステップ５７１０で、この方法は、１つ以上のマイクロプロセッサにおいて、第１のサブネットを提供することができ、第１のサブネットは複数のスイッチを含み、複数のスイッチは少なくともリーフスイッチを含み、複数のスイッチの各々は、複数のスイッチポートのうちの少なくとも１つのスイッチポートを含み、第１のサブネットは、さらに、複数のホストチャネルアダプタを含み、各ホストチャネルアダプタは、複数のホストチャネルアダプタポートのうちの少なくとも１つのホストチャネルアダプタポートを含み、複数のホストチャネルアダプタは複数のスイッチを介して相互接続され、第１のサブネットは、さらに、サブネットマネージャを含み、サブネットマネージャは、複数のスイッチおよび複数のホストチャネルアダプタの一方で実行される。

【0450】

一実施形態によれば、ステップ５７２０で、この方法は、サブネットアドミニストレータによって、第１のサブネットを２つ以上の論理ドメインに分割することができ、各論理ドメインは、複数のスイッチの少なくとも１つのスイッチおよび複数のホストチャネルアダプタの少なくとも１つのホストチャネルアダプタを含む。

【0451】

一実施形態によれば、ステップ５７３０で、この方法は、サブネットマネージャによって、２つ以上の論理ドメインの各々内にデフォルトマルチキャストグループプロキシを定義することができ、各デフォルトマルチキャストグループプロキシはキャッシュに関連付けられる。

【0452】

一実施形態によれば、ステップ５７４０で、この方法は、２つ以上の論理ドメインの第１の論理ドメイン内の第１のマルチキャストグループプロキシで、２つ以上の論理ドメインの第２の論理ドメイン内の第２のマルチキャストグループプロキシから、情報に対する要求を受信することができる。

【0453】

一実施形態によれば、ステップ５７５０で、この方法は、第１のＭＣＧプロキシによって、第１のＭＣＧプロキシに関連付けられた第１のキャッシュ内で、受信した要求に応答する情報をチェックすることができる。

【0454】

一実施形態によれば、ステップ５７６０で、この方法は、第１のＭＣＧプロキシによって、第２のＭＣＧプロキシに、要求に応答する情報を含む応答メッセージを送信する。

【0455】

複数のパーティションでＭＣベースのアナウンスメントを受信するためのＱＰ１の使用
一実施形態によれば、一般管理パケット（ＧＭＰ）のために充分に定義された宛先として用いられるキューペア１（ＱＰ１）を伴うある独自の機能は、通常のＱＰとは異なり、単一のパーティションに関連付けられるだけでなく、代わりに、関連するポートに現在関連付けられているすべてのパーティションに代わって送信および受信の両方に対して動作することができることである。

【0456】

一実施形態によれば、ＱＰ１の範囲を拡張して、ポートに対して定義された任意のパーティションでマルチキャストパケットを送受信することも含めることにより、個々のパーティションに対する独自のＱＰの複雑さも、パーティションメンバーシップの変更の結果としてのＱＰ構成の更新も必要とせずに、汎用なＭＣベースのアナウンスメントおよびディスカバリを実現することができる。

【0457】

一実施形態によれば、ポートのデフォルトＭＧＩＤは、ＳＭＡレベルで定義されているため、この機能をサポートするポートに対しては本質的に充分に定義される。したがって、おそらくはこのようなＭＣトラフィックに対してＱＰ１の使用を有効または無効にするためのサポートを除き、特別な初期化手順は必要ない。

【0458】

一実施形態によれば、ＩＢクライアントは、いずれにせよ、関連するパーティションに対して特に割り当てられる他のＱＰを介して、関連するＭＣトラフィックを処理することを許可されるであろう。任意のＱＰ ＭＣＧ関連付けと同様に、同じＭＣＧに関連付けられる複数のローカルＱＰが存在することができ、したがって、異なるパーティションにおけるデフォルトＭＣＧトラフィックに対する専用ＱＰの使用を、同じパーティションに対するＱＰ１の使用の代わりに、またはそれに加えて、用いることができる。

【0459】

一実施形態によれば、プロキシを含むリモートノードに対して、異なるパーティションでのデフォルトＭＣＧトラフィックに対するＱＰ１または専用ＱＰの使用は、一般に、ＧＭＰトラフィックの場合のそれを除き、完全に透過的であることができ、着信要求のソースＱＰを対応する（ユニキャスト）応答の宛先ＱＰとして用いることが可能であるはずである。ただし、この方式は、ソースＱＰがＱＰ１であるかまたは他のＱＰ番号であるかに関係なく、同じ態様で当てはまる。

【0460】

一実施形態によれば、パーティションごとに専用のＭＬＩＤを利用することにより、Ｉ
Ｂクライアントは、任意のローカルパーティションでアナウンスメントおよびディスカバリメッセージを送信し、それを追加の初期化なしに関連するすべてのピアノードに受信してもらうことができる。

【0461】

一実施形態によれば、プロキシベースの動作の場合、関連するドメインプロキシがドメインごとのデフォルトパーティションで通知を送信することも可能であろうが、異なるパーティションのＭＬＩＤを用い、関連するノードのみが対応するメッセージを受信するであろう。パーティション固有のＭＬＩＤは、関連する実際のメンバーのルーティングを有するであろうが、プロキシが用いるポートは依然として送信専用メンバーとして含まれ得る。

【0462】

一実施形態によれば、プロキシがすべての関連するパーティションでポートメンバーシップを有する場合、デフォルトパーティションを用いる代わりに特定のパーティションでそのようなＭＣメッセージを送信することを選択することができる。

【0463】

一実施形態によれば、ＩＢ仕様は、ＱＰ１を介するＭＣトラフィックのためにＨＣＡサポートを照会する動詞インターフェイス、およびサポートされる場合にこの機能を有効化および無効化するポート固有の動作を含むように拡張することができる。

【0464】

図５８は、一実施形態による、高性能コンピューティング環境において複数のパーティションでマルチキャストベースのアナウンスメントを受信するためにキューペア１（ＱＰ１）を用いる方法のフローチャートを示す。

【0465】

一実施形態によれば、ステップ５８００で、この方法は、ＩｎｆｉｎｉＢａｎｄサブネットにおいて、各パーティションが１つ以上のエンドノードを含む複数のパーティションを提供することができる。

【0466】

一実施形態によれば、ステップ５８０５で、この方法は、２つ以上のパーティションからのマルチキャストパケットの送信および受信を含むよう、キューペア１を拡張した。

【0467】

一実施形態によれば、ステップ５８１０で、この方法は、キューペア１を介した汎用なマルチキャストベースのアナウンスメントを実現することができる。

【0468】

一実施形態によれば、ステップ５８１５で、この方法は終了することができる。
図５９は、一実施形態による、高性能コンピューティング環境において複数のパーティションでマルチキャストベースのアナウンスメントを受信するためにキューペア１（ＱＰ１）を用いるシステムを示す。

【0469】

より具体的には、この図は、各パーティションに対して専用のアナウンスメントＱＰを備えたデフォルトスキームを示す。

【0470】

一実施形態によれば、インフィニバンドファブリックなどのファブリック内のＨＣＡの、ポート１ ５９０１などのポートは、パーティションテーブルと、キューペアＡ ５９０２、キューペアＢ ５９０３、キューペアＣ ５９０４、キューペアＤ ５９０５、キューペアＥ ５９０６などのマルチキャストアナウンスメント用の専用キューペアとを備えるようにセットアップすることができる。関連付けられたマルチキャストグループに従って、各キューペアを、異なるパーティションキーに関連付けることができる。

【0471】

図６０は、一実施形態による、高性能コンピューティング環境において複数のパーティションでマルチキャストベースのアナウンスメントを受信するためにキューペア１（ＱＰ
１）を用いるシステムを示す。

【0472】

より具体的には、この図は、パーティションメンバーシップ処理の結果としてのアナウンスメントＱＰポピュレーションの再構成を示す。

【0473】

一実施形態によれば、インフィニバンドファブリックなどのファブリック内のＨＣＡの、ポート１ ６００１などのポートは、パーティションテーブルと、キューペアＡ ６００２、キューペアＢ ６００３、キューペアＣ ６００４、キューペアＥ ６００５、およびキューペアＦ ６００６などの、マルチキャストアナウンスメントのための専用キューペアとを備えるようにセットアップすることができる。関連付けられたマルチキャストグループに従って、各キューペアを異なるパーティションキーに関連付けることができる。

【0474】

一実施形態によれば、図６０は、図５９に示されるシステムのパーティションメンバーシップの変更後の再構成を示す。

【0475】

図６１は、一実施形態による、高性能コンピューティング環境において複数のパーティションでマルチキャストベースのアナウンスメントを受信するためにキューペア１（ＱＰ１）を用いるシステムを示す。

【0476】

より具体的には、この図は、アナウンスメントが行われたときに新たなＱＰが配置されていないためにアナウンスメントが失われる特別な競合状態を示す。

【0477】

一実施形態によれば、インフィニバンドファブリックなどのファブリック内のＨＣＡのポート１ ６１０１などのポートは、パーティションテーブルと、キューペアＡ ６１０２、キューペアＢ ６１０３、キューペアＣ ６１０４、キューペアＤ ６１０５、キューペアＥ ６１０６などのマルチキャストアナウンスメント用の専用キューペアとを備えるようにセットアップすることができる。関連付けられたマルチキャストグループに従って、各キューペアを、異なるパーティションキーに関連付けることができる。

【0478】

一実施形態によれば、図６１は、マルチキャストグループＦからのマルチキャストアナウンスメントを処理するために新たなキューペア（ＱＰ Ｆ）をセットアップすることができる前の、図６０のシステムを示す。ＭＣ情報メッセージ６１１０がポート１で受信される状況において、ポート１は、キューペアＦがＰ＿ＫｅｙＦおよび／またはマルチキャストグループＦに対して確立されていないため、ＭＣ情報メッセージを処理できない。

【0479】

図６２は、一実施形態による、高性能コンピューティング環境において複数のパーティションでマルチキャストベースのアナウンスメントを受信するためにキューペア１（ＱＰ１）を用いるシステムを示す。

【0480】

より具体的には、この図は、ＱＰ１が拡張された接続管理ユニキャストメッセージとマルチキャストベースのアナウンスメントメッセージとの両方を受信する簡略化されたスキームを示す。

【0481】

一実施形態によれば、インフィニバンドファブリックなどのファブリック内のＨＣＡの、ポート１ ６２０１などのポートは、パーティションテーブルを含むようにセットアップすることができる。同様に、ポートは、キューペア１ ６２０２が６２２０などの拡張された接続管理ユニキャストメッセージおよび６２１０などのマルチキャスト情報メッセージの両方に用いられる単純化されたスキームを利用することができる。

【0482】

一実施形態によれば、ユニキャスト管理メッセージおよびマルチキャスト情報メッセージの両方にキューペア１を採用することにより、システムは図６１に示される競合状態を回避することができる。

【0483】

一実施形態によれば、ＱＰ１の範囲を拡張して、ポートのために定義された任意のパーティションでマルチキャストパケットを送受信することも含めることにより、 個々のパ
ーティションに対する独自のＱＰの複雑さも、パーティションメンバーシップの変更の結果としてのＱＰ構成の更新も必要とせずに、汎用なＭＣベースのアナウンスメントおよびディスカバリを実現することができる。

【0484】

一実施形態によれば、ポートのデフォルトＭＧＩＤは、ＳＭＡレベルで定義されているため、それは、この機能をサポートするポートに対しては本質的に充分に定義される。したがって、おそらくはこのようなＭＣトラフィックに対してＱＰ１の使用を有効または無効にするためのサポートを除き、特別な初期化手順は必要ない。

【0485】

一実施形態によれば、ＩＢクライアントは、いずれにせよ、関連するパーティションに対して特に割り当てられる他のＱＰを介して、関連するＭＣトラフィックを処理することを許可されるであろう。 任意のＱＰ ＭＣＧ関連付けと同様に、同じＭＣＧに関連付け
られる複数のローカルＱＰが存在することができ、したがって、異なるパーティションにおけるデフォルトＭＣＧトラフィックに対する専用ＱＰの使用を、同じパーティションに対するＱＰ１の使用の代わりに、またはそれに加えて、用いることができる。

【0486】

図６３は、一実施形態による、高性能コンピューティング環境において複数のパーティションでマルチキャストベースのアナウンスメントを受信するためにキューペア１（ＱＰ１）を用いるシステムを示す。

【0487】

より具体的には、この図は、デフォルトのＭＣＧ／ＭＧＩＤに関連付けられるＱＰの存在が、ＱＰの確立とアナウンスメントＭＣパケット６３１０の受信との間の競合状態を除去することを示す。

【0488】

一実施形態によれば、ＱＰ１ ６３０２は、ポート１ ６３０１によって使用されるように、ＭＣＧ‐Ｓｐｅに永久的に関連付けることができ、ＳＭが関連付けられたポートに対してセットアップしたどのようなＰ＿Ｋｅｙ値のセットにも常に関連付けられる。

【0489】

図６４は、一実施形態による、高性能コンピューティング環境において複数のパーティションでマルチキャストベースのアナウンスメントを受信するためにキューペア１（ＱＰ１）を用いる方法のフローチャートを示す。

【0490】

実施形態によれば、ステップ６４１０で、この方法は、１つ以上のマイクロプロセッサにおいて、第１のサブネットを提供することができ、第１のサブネットは複数のスイッチを含み、複数のスイッチは少なくともリーフスイッチを含み、複数のスイッチの各々は、複数のスイッチポートのうちの少なくとも１つのスイッチポートを含み、第１のサブネットは、さらに、複数のホストチャネルアダプタを含み、各ホストチャネルアダプタは、複数のホストチャネルアダプタポートのうちの少なくとも１つのホストチャネルアダプタポートを含み、複数のホストチャネルアダプタは複数のスイッチを介して相互接続され、第１のサブネットは、さらに、サブネットマネージャを含み、サブネットマネージャは、複数のスイッチおよび複数のホストチャネルアダプタの一方で実行される。

【0491】

一実施形態によれば、ステップ６４２０で、この方法は、複数のパーティションのすべてのパーティションからマルチキャストパケットを受信するようにキューペア１をセット
アップすることができる。

【0492】

一実施形態によれば、ステップ６４３０で、この方法は、複数のホストチャネルアダプタのうちのあるホストチャネルアダプタに関連付けられたローカルノードから、アナウンスメントマルチキャストパケットを通信することができる。

【0493】

一実施形態によれば、ステップ６４４０で、この方法は、キューペア１を利用して第１のサブネット内でアナウンスメントマルチキャストパケットを転送することができる。

【0494】

ＧＵＩＤ／ＧＩＤからＬＩＤへのキャッシュコンテンツの基礎として着信ＭＣパケットを用いる（５８３８）
一実施形態によれば、すべてのマルチキャストパケットはグローバルルートヘッダ（ＧＲＨ）を有するため、着信マルチキャストパケットに対して定義されるソースＧＩＤおよびソースＬＩＤの両方が常に存在する。これは、一般に、ＨＣＡ実装例が、すべての着信ＭＣパケットに基づいて、送信元ノードについてＧＩＤおよびＧＵＩＤからＬＩＤへのマッピングに関する情報を収集することが可能であることを意味する。

【0495】

一実施形態によれば、「AllSubnetLocalChannelAdapterLIDsUsable」フラグ値および「RouterSourceLIDsReversible」フラグ値が真または偽であるかどうかについてローカルＳＭＡレベルのプロパティと相関させることにより、およびローカルデフォルトＭＣＧについて着信する明示的なプロキシＭＣメッセージを識別できることに基づいて、ローカルポートロジックは、ＧＩＤおよび／またはＧＵＩＤと対応するＬＩＤとの間のマッピングを含む動的キャッシュを構築および維持することができる。

【0496】

一実施形態によれば、着信作業要求処理を処理するためにＨＣＡ固有の機能が存在する限り、この種のキャッシングロジックをＨＣＡのＣＩ（チャネルインターフェイス）インターフェイスの下に維持することが可能である。

【0497】

一実施形態によれば、そのようなキャッシュ保守の実行は大きなオーバーヘッドを表さないが、それはゼロではなく、したがってこの理由から、この機能の有効化はポートおよび個々のＱＰレベルの両方で明示的に制御可能でなければならない。

【0498】

一実施形態によれば、本開示により、様々なＩＢ仕様の拡張が企図される。第１の拡張機能は、ＭＣベースのアドレスマップキャッシングのＨＣＡサポートを照会するための新たな動詞インターフェイス、ならびにこれをポートごとおよびＱＰ（ＱＰ１を含む）ごとレベルの両方で有効および無効にする制御操作を含むことができる。キャッシュがサポートされて有効になっている場合、キャッシュの内容を監視および制御するための動詞インターフェイスが存在する必要がある。

【0499】

図６５は、一実施形態による、高性能コンピューティング環境においてグローバル一意識別子（ＧＵＩＤ）からローカル識別子（ＬＩＤ）へのキャッシュコンテンツの基礎としてすべての着信マルチキャスト（ＭＣ）パケットを用いる方法のフローチャートを示す。

【0500】

一実施形態によれば、ステップ６５００で、この方法は、複数のマルチキャストグループを含むサブネットを提供することができる。

【0501】

一実施形態によれば、ステップ６５０５で、この方法はマルチキャストパケットを受信することができ、マルチキャストパケットは、ソースグローバル識別子（ＧＩＤ）およびソースローカル識別子（ＬＩＤ）を定義するグローバルルータヘッダ（ＧＲＨ）を含む。

【0502】

一実施形態によれば、ステップ６５１０で、この方法は、ＧＲＨならびにソースＧＩＤおよびソースＬＩＤをローカルサブネット管理エージェント（ＳＭＡ）レベルプロパティと相関させることができる。

【0503】

一実施形態によれば、ステップ６５１５で、この方法は動的キャッシュを構築することができ、キャッシュはソースＧＩＤまたはソースＧＵＩＤと対応するＬＩＤとの間のマッピングを含む。

【0504】

一実施形態によれば、ステップ６５２０で、この方法は終了することができる。
図６６は、一実施形態による、高性能コンピューティング環境においてグローバル一意識別子（ＧＵＩＤ）からローカル識別子（ＬＩＤ）へのキャッシュコンテンツの基礎としてすべての着信マルチキャスト（ＭＣ）パケットを用いるシステムを示す。

【0505】

一実施形態によれば、この図は、ＣＩインターフェイス、およびＣＩインターフェイスの下のＧＵＩＤからＬＩＤへのキャッシュの存在の図を示す。

【0506】

一実施形態によれば、汎用な動詞インターフェイス６６０１およびチャネルプロバイダインターフェイス６６０２（ＣＩ）を備えるホストチャネルアダプタでは、動詞インターフェイスのプラットフォーム固有の実装６６０３およびＧＩＤまたはＧＵＩＤからＬＩＤへのマッピングキャッシュ６６０４を、ＣＩレベルの下に提供することができる。

【0507】

図６７は、高性能コンピューティング環境においてグローバル一意識別子（ＧＵＩＤ）からローカル識別子（ＬＩＤ）へのキャッシュコンテンツの基礎としてすべての着信マルチキャスト（ＭＣ）パケットを用いるシステムを示す図である。

【0508】

一実施形態によれば、この図は、ＣＩインターフェイス上の標準の受信機能およびＩＢクライアントが着信ＭＣパケットの結果としてキャッシュ更新を認識していない図を示す。

【0509】

一実施形態によれば、次いで、ＭＣパケットを受信すると、ＨＣＡはプラットフォーム固有の受信機能６７０３を実行し、ＧＩＤ／ＧＵＩＤからＬＩＤへのキャッシュ６７０４においてＭＣパケットのＧＲＨに基づいてＧＩＤ／ＧＵＩＤからＬＩＤへのマッピングをキャッシュするが、受信機能６７０１など、ＣＩ６７０２の上の何も、そのようなキャッシュを認識しない。次に、たとえば、ＭＣメッセージ完了メッセージを汎用受信機能に送信することができる。

【0510】

一実施形態によれば、メッセージ交換の数を低減するために、接続管理動作を実行する前に、ローカルキャッシュを用いて「相談」する。

【0511】

一実施形態によれば、宛先ノードへの新たな接続をセットアップするときに、ローカルＧＩＤ／ＧＵＩＤからＬＩＤへのキャッシュマッピングを用いることができる。宛先ノードに既知／（キャッシュに）保存されたＧＵＩＤ／ＧＩＤがない場合、ローカルノードは典型的なＡＲＰタイプの操作を用いて宛先ノードのＧＵＩＤ／ＧＩＤを取得することができる。一方、宛先ノードのＧＩＤ／ＧＵＩＤが（以前のＭＣメッセージから）キャッシュに保存されている場合、宛先ノードのＧＩＤ／ＧＵＩＤからＬＩＤへのマッピングを用いて、メッセージのアドレスを作成することができる。

【0512】

図６８は、一実施形態による、高性能コンピューティング環境においてグローバル一意識別子（ＧＵＩＤ）からローカル識別子（ＬＩＤ）のキャッシュコンテンツの基礎としてすべての着信マルチキャスト（ＭＣ）パケットを用いる方法のフローチャートを示す。

【0513】

実施形態によれば、ステップ６８１０で、この方法は、１つ以上のマイクロプロセッサにおいて、第１のサブネットを提供することができ、第１のサブネットは複数のスイッチを含み、複数のスイッチは少なくともリーフスイッチを含み、複数のスイッチの各々は、複数のスイッチポートのうちの少なくとも１つのスイッチポートを含み、第１のサブネットは、さらに、複数のホストチャネルアダプタを含み、各ホストチャネルアダプタは、複数のホストチャネルアダプタポートのうちの少なくとも１つのホストチャネルアダプタポートを含み、複数のホストチャネルアダプタは複数のスイッチを介して相互接続され、第１のサブネットは、さらに、サブネットマネージャを含み、サブネットマネージャは、複数のスイッチおよび複数のホストチャネルアダプタの一方で実行される。

【0514】

一実施形態によれば、ステップ６８２０で、この方法は、第１のサブネット内において複数のマルチキャストグループを定義することができる。

【0515】

一実施形態によれば、ステップ６８３０において、この方法は、第１のサブネット内のノードで、ソースグローバル識別子（ＧＩＤ）およびソースローカル識別子（ＬＩＤ）を定義するグローバルルートヘッダ（ＧＲＨ）を含むマルチキャストパケットを受信することができる。

【0516】

一実施形態によれば、ステップ６８４０で、この方法は、サブネットマネージャによって、少なくともソースグローバル識別子と対応するソースローカル識別子との間のマッピングを含む動的キャッシュを構築することができる。

【0517】

デフォルトＩＢ ＭＣＧを介してＩＢおよびＩＰアドレスならびに名前解決を組み合わせる（５８３９）
一実施形態によれば、ＩＢファブリックにおけるノード／ポートのほとんどのアドレス指定およびノード識別スキームは、ＲＤＭＡ‐ＣＭおよび通信するエンドノードのアプリケーションレベル識別としてのＩＰアドレスの使用に基づいているため、ＩＰアドレスからＩＢアドレスへのマッピング、ならびにノードおよびインターフェイスとの記号名関連付けを解決することが必要である。

【0518】

一実施形態によれば、デフォルトＩＢ ＭＣＧを活用するアナウンスメントおよびディスカバリプロトコルに基づいてＩＢアドレスを解決するための効率的でスケーラブルなスキームに基づいて、プロトコルを拡張して、ＩＰアドレスおよび記号名情報を含める機能を含めることもできる。

【0519】

一実施形態によれば、より具体的には、プロトコルは、ＴＬＶ（タイプ‐長さ‐値）スタイルの汎用表現を用いてアプリケーション固有の値を提供するためのオプションを含むことができる。このようにして、ＩＢアドレスマッピングが要求される、アプリケーション固有の引数（例：ＩＰアドレス）を有する要求を発行でき、そのようなＴＬＶの任意のセットを含む応答およびアナウンスメントメッセージを有することも可能であろう。

【0520】

一実施形態によれば、コアＩＢアドレスキャッシュに基づいて、様々なＴＬＶをキャッシュ内のＩＢアドレスに関連付けることができ、探索基準として用いることもできる。このようにして、両方のさまざまなＩＰアドレス、記号名、ＭＡＣアドレスなどをすべて、関連するＩＢアドレス情報に関連付け、各ノードの単一キャッシュで維持し、ＩＢファブリック上で単一のメッセージで伝達することもできる。

【0521】

図６９は、一実施形態による、高性能コンピューティング環境において、デフォルトのＩＢマルチキャストグループを介して、組み合わされたＩＢおよびＩＰアドレスならびに
名前解決スキームを提供する方法のフローチャートを示す。

【0522】

一実施形態によれば、ステップ６９００で、この方法は、複数のマルチキャストグループを含むサブネットを提供することができる。

【0523】

一実施形態によれば、ステップ６９０５で、この方法は、インフィニバンドアドレスマッピングを求める、アプリケーション固有の引数を有する要求を発行することができる。

【0524】

一実施形態によれば、ステップ６９１０で、この方法は、要求に応答して、アプリケーション固有の引数に対応するＩＢアドレスマッピングを発行することができる。

【0525】

一実施形態によれば、６９１５で、アプリケーション固有の引数は、ＩＰアドレス、ＴＬＶ、記号名、およびＭＡＣアドレスのうちの１つである。

【0526】

一実施形態によれば、ステップ６９２０で、この方法は終了することができる。
図７０は、一実施形態による、高性能コンピューティング環境において、デフォルトのＩＢマルチキャストグループを介して、組み合わせられたＩＢおよびＩＰアドレスならびに名前解決のスキームを提供するシステムを示す。より具体的には、この図は、従来のＧＵＩＤからＬＩＤへのキャッシュを示す。

【0527】

一実施形態によれば、従来のＧＵＩＤからＬＩＤへのキャッシュは、ＧＵＩＤのためのハッシュ関数７００１と、バケット１ ７００２からバケットＮ ７００４などのＮ個のバケットと、ＧＵＩＤ７００５をＬＩＤ７００６に関係付けるいくつかのバケットエントリとを含むことができる。

【0528】

一実施形態によれば、ＧＵＩＤからＬＩＤへのキャッシュは、固定された機能として利用することができる。ＴＬＶベースのノード情報レコードを用いると、そのようなレコードの動的リストを、関連付けられたインデックス付けスキームで維持することができる。

【0529】

一実施形態によれば、サポートされる各情報タイプ（例えば、ＩＰ、ＭＡＣアドレスなど）について、ハッシュベースのＧＵＩＤからＬＩＤへのキャッシュに類似した専用の探索インフラストラクチャを提供することができる。ただし、この場合、探索される値は、ノード情報レコードリストのメインインデックスにアクセスするためのインデックス値である。

【0530】

一実施形態によれば、探索機能は、サポートされるＴＬＶを入力として取り、一致する場合には、関連するレコードを返す。追加のパラメータは、探索の範囲を制限することができる（たとえば、名前の探索を特定のパーティションに制限することができる）。

【0531】

一実施形態によれば、任意の情報のための汎用ＴＬＶを備えた拡張通知マルチキャストパケットプロトコルを用いることができる。送信元ＧＵＩＤと送信元ＬＩＤは、マルチキャストパケットおよびユニキャストパケットのＧＲＨおよびＬＲＨの一部であり、‐ＧＲＨは両方に必要である。

【0532】

一実施形態によれば、複数のメッセージを用いて、単一のメッセージが含むことができるものよりも多くのＴＬＶベースの情報を表すことができる。

【0533】

図７１は、一実施形態による、高性能コンピューティング環境においてデフォルトのＩＢマルチキャストグループを介して組み合わされたＩＢおよびＩＰアドレスならびに名前解決スキームを提供する方法のフローチャートを示す。

【0534】

より具体的には、このフローチャートは、ＩＢアドレス（ＧＩＤおよびＬＩＤ）をマッピングするため、または追加のＴＬＶでキャッシュレコードを完成するために、ＴＬＶ（タイプ‐長さ値）タイプおよび値を入力できる汎用キャッシュ探索スキームを示す。

【0535】

一実施形態によれば、ステップ７１０１で、この方法を開始することができる。
一実施形態によれば、ステップ７１０２で、この方法は、指定されたタイプがキャッシュインスタンスによってサポートされることを保証することができる。つまり、この方法は、受信メッセージの、指定されたタイプが、当該メッセージが受信されるノード内で実行されているキャッシュインスタンスによってサポートされていることを保証することができる。

【0536】

一実施形態によれば、ステップ７１０３で、この方法は、関連するタイプに対するハッシュ構造を用いて、関連するインデックス（すなわち、受信メッセージの、指定されたタイプをサポートするインデックス）を探索することができる。

【0537】

一実施形態によれば、ステップ７１０４で、インデックスが見つかった場合、この方法は、見つかったインデックス（すなわち、見つかったインデックスを意味する、関連するタイプをサポートする正しい見つかったインデックス）を用いて、関連するレコード（すなわち、ＧＲＨまたはＧＵＩＤ／ＬＩＤおよびＬＩＤマッピング）を探索することができる。

【0538】

一実施形態によれば、ステップ７１０５で、この方法は、探索されたレコードから要求された情報を返すことができる。

【0539】

一実施形態によれば、ステップ７１０６で、インデックスが見つからない／位置を突き止められない場合、この方法は、インデックスが見つからない、および／または指定されたタイプがサポートされていない、というメッセージを返すことができる。

【0540】

図７２は、一実施形態による、高性能コンピューティング環境において、デフォルトのＩＢマルチキャストグループを介して、組み合わされたＩＢおよびＩＰアドレスならびに名前解決スキームを提供する方法のフローチャートを示す。

【0541】

実施形態によれば、ステップ７２１０で、この方法は、１つ以上のマイクロプロセッサにおいて、第１のサブネットを提供することができ、第１のサブネットは複数のスイッチを含み、複数のスイッチは少なくともリーフスイッチを含み、複数のスイッチの各々は、複数のスイッチポートのうちの少なくとも１つのスイッチポートを含み、第１のサブネットは、さらに、複数のホストチャネルアダプタを含み、各ホストチャネルアダプタは、複数のホストチャネルアダプタポートのうちの少なくとも１つのホストチャネルアダプタポートを含み、複数のホストチャネルアダプタは複数のスイッチを介して相互接続され、第１のサブネットは、さらに、サブネットマネージャを含み、サブネットマネージャは、複数のスイッチおよび複数のホストチャネルアダプタの一方で実行される。

【0542】

一実施形態によれば、ステップ７２２０で、この方法は、第１のサブネットに関連して、ハッシュ関数を提供することができる。

【0543】

一実施形態によれば、ステップ７２３０で、この方法は、インフィニバンドアドレスマッピングを求める、アプリケーション固有の引数を含む要求を受信することができる。

【0544】

一実施形態によれば、ステップ７２４０で、この方法は、ハッシュ関数との関連におい
てアプリケーション固有の引数に基づいてＩＢアドレスマッピングを発行することができ、アプリケーション固有の引数は、ＩＰアドレス、ＴＬＶ、記号名、またはＭＡＣアドレスの１つである。

【0545】

本発明の様々な実施形態を説明してきたが、上記実施形態が限定ではなく例示として提示されていることが理解されるべきである。上記実施形態は、本発明の原理およびその実際の適用例を説明するために選択され記載されたものである。上記実施形態は、新たな特徴および／もしくは改善された特徴を提供することによって、ならびに／または、リソース利用の低減、容量の増加、効率の向上および待ち時間の低下などの利点を提供することによって、システムおよび方法の性能を向上させるために本発明が利用されているシステムおよび方法を例示している。

【0546】

いくつかの実施形態においては、本発明の特徴は、全体的または部分的に、プロセッサ、メモリなどの記憶媒体、および他のコンピュータと通信するためのネットワークカードを含むコンピュータにおいて実現される。いくつかの実施形態においては、本発明の特徴は、コンピュータの１つ以上のクラスタがローカルエリアネットワーク（Local Area Network：ＬＡＮ）、スイッチファブリックネットワーク（例えば、インフィニバンド）、またはワイドエリアネットワーク（Wide Area Network：ＷＡＮ）などのネットワークによ
って接続されている分散コンピューティング環境において実現される。分散コンピューティング環境は、一箇所において全てのコンピュータを有していてもよく、または、ＷＡＮによって接続されているさまざまな遠隔地理位置においてコンピュータのクラスタを有していてもよい。

【0547】

いくつかの実施形態においては、本発明の特徴は、全体的または部分的に、ウェブ技術を用いたセルフサービスの調整された態様でユーザに送達される共有型で融通性のあるリソースに基づいて、クラウド・コンピューティング・システムの一部またはサービスとしてクラウドにおいて実現される。（米国標準技術局（National Institute of Standards and Technology）よって定義される）クラウドの５つの特徴がある。すなわち、オン・デマンドのセルフサービス、広域ネットワークアクセス、リソースプール化、高速伸縮性、およびメジャードサービスである。例えば、本明細書に引用によって援用されている「クラウドコンピューティングのＮＩＳＴ定義（The NIST Definition of Cloud Computing）」（特殊出版（Special Publication）８００～１４５（２０１１））を参照されたい。
クラウド展開モデルは、パブリック、プライベートおよびハイブリッドを含む。クラウドサービスモデルは、ソフトウェア・アズ・ア・サービス（Software as a Service：Ｓａ
ａＳ）、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）
、データベース・アズ・ア・サービス（Database as a Service：ＤＢａａＳ）およびイ
ンフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）
を含む。本明細書で使用するとき、クラウドは、セルフサービスの調整された態様で、共有される融通性のあるリソースをユーザに対して配信する、ハードウェア技術とソフトウェア技術とネットワーク技術とウェブ技術とを組合せたものである。特に指定がなければ、クラウドは、本明細書で使用するとき、パブリッククラウド、プライベートクラウドおよびハイブリッドクラウドの実施形態を包含しており、全てのクラウド展開モデルは、クラウドＳａａＳ、クラウドＤＢａａＳ、クラウドＰａａＳおよびクラウドＩａａＳを含むもののこれらに限定されない。

【0548】

いくつかの実施形態においては、本発明の特徴が、ハードウェア、ソフトウェア、ファームウェアまたはそれらの組合せを用いて、またはそれらの組合せの助けを借りて実現される。いくつかの実施形態においては、本発明の特徴は、本発明の１つ以上の機能を実行するように構成されたかまたはプログラムされたプロセッサを用いて実現される。プロセッサは、いくつかの実施形態においては、シングルプロセッサもしくはマルチチッププロ
セッサ、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、システム・オン・ア・チップ（system on a chip：ＳＯＣ）、特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（field programmable gate array：ＦＰＧＡ）もしくは他のプログラマブルロジックデバイス、ステートマシン、離散的なゲートもしくはトランジスタ論理、離散的なハードウェアコンポーネント、または、本明細書に記載される機能を実行するように設計されたそれらのいずれかの組合せである。いくつかの実現例においては、本発明の特徴が、特定の機能に特化した回路類によって実現され得る。他の実現例においては、これらの特徴は、例えば、コンピュータ可読記憶媒体上に格納された命令を用いて特定の機能を実行するように構成されたプロセッサにおいて実現され得る。

【0549】

いくつかの実施形態においては、本発明の特徴は、処理システムおよび／またはネットワーキングシステムのハードウェアを制御するために、かつ、プロセッサおよび／またはネットワークが本発明の特徴を利用する他のシステムと対話することを可能にするために、ソフトウェアおよび／またはファームウェアに組込まれている。このようなソフトウェアまたはファームウェアは、アプリケーションコード、デバイスドライバ、オペレーティングシステム、仮想マシン、ハイパーバイザ、アプリケーションプログラミングインターフェイス、プログラミング言語、および実行環境／コンテナを含み得るがこれらに限定されない。適切なソフトウェアコーディングは、ソフトウェア技術に精通した当業者にとって明らかになるように、熟練したプログラマであれば本開示の教示に基づいて容易に準備することができる。

【0550】

いくつかの実施形態においては、本発明は、命令が格納された記憶媒体またはコンピュータ可読媒体であるコンピュータプログラムプロダクトを含む。これらの命令を用いて、本発明の処理または機能のいずれかを実行するように、コンピュータなどのシステムをプログラムするか、または他の方法で構成することができる。記憶媒体またはコンピュータ可読媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、マイクロドライブ、および磁気光ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気または光カード、ナノシステム（分子メモリＩＣを含む）、ならびに、命令および／またはデータを格納するのに適した任意のタイプの媒体または装置、を含み得るが、これらには限定されない。特定の実施形態においては、記憶媒体またはコンピュータ可読媒体は、非一時的な記憶媒体または非一時的なコンピュータ可読媒体である。

【0551】

上述の記載は、網羅的となるように意図されたものではなく、または、本発明を開示通りの形態に限定するように意図されたものではない。また、本発明の実施形態を特定の一連のトランザクションおよびステップを用いて説明したが、本発明の範囲が上述の一連のトランザクションおよびステップに限定されないことは、当業者にとって明らかであろう。さらに、本発明の実施形態をハードウェアとソフトウェアとの特定の組合せを用いて説明したが、ハードウェアとソフトウェアとの他の組合せが本発明の範囲内にあることも認識すべきである。さらに、さまざまな実施形態で本発明の特徴の特定の組合せを記載したが、一実施形態の特徴が別の実施形態に組込まれ得るというように、これらの特徴の異なる組合せが本発明の範囲内にあることは当業者にとって明らかであることを理解すべきである。さらに、本発明の精神および範囲から逸脱することなく、形態、詳細、実施および用途のさまざまな追加、削減、削除、変形および他の変更がなされ得ることも、当業者にとっては明らかであろう。より広い本発明の精神および範囲を添付の特許請求の範囲およびその均等物によって規定することを意図している。

【図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】

【図64】

【図65】

【図66】

【図67】

【図68】

【図69】

【図70】

【図71】

【図72】