(57)【特許請求の範囲】
【請求項１】
受信ポートと、
送信ポートとを含む、
リンクインタフェースを含む装置であって、
前記受信ポート及び前記送信ポートが、
前記装置が通信状態でリンクされるように構成されるピア装置のピアリンクインタフェースの受信ポートの受信バッファの初期の構成を定義するデータを受信し、ここで、前記受信バッファの前記初期の構成は、それぞれ対応する仮想レーン（ＶＬ）に割り当てられる複数のＶＬバッファを含む複数のバッファに区分化された全体バッファ空間を含み、前記データは、各バッファのクレジットの初期割当てを含み、
各クレジットによって表されるバッファ空間の量を示すクレジット編成情報を受信し、
前記ピアリンクインタフェースの前記受信ポートによって受信されるように、データを前記リンク上に伝送し、
前記送信ポートにおいて、伝送されたデータの量及び前記クレジット編成情報に基づいて前記受信バッファ中の適用可能なバッファについてバッファクレジットを割当て解除し、
前記ピアリンクインタフェースからクレジットリターン確認応答（ＡＣＫ）を受信し、ここで、各クレジットリターンＡＣＫは、ＶＬを識別し、１つ又は複数のクレジットは、前記ＶＬに割り当てられたバッファの空きバッファ空間の量を示し、前記クレジット編成情報に基づいており、
前記送信ポートにおいて、前記割当て解除されたバッファクレジット及び前記クレジットリターンＡＣＫを介して戻されたクレジットに基づいて、前記受信バッファ中の各バッファに利用可能なクレジットをトラッキングする
回路及び論理を含む、装置。
【請求項２】
前記クレジット編成情報が、前記受信バッファのバッファ割当てに使用される最小ブロックサイズに対応する割当て単位（ＡＵ）を含み、各バッファクレジットが、前記ＡＵの倍数であるバッファ空間に対応する、請求項１に記載の装置。
【請求項３】
前記リンクインタフェースが、
前記ＡＵのサイズをそこから決定することができ、クレジットリターンＡＣＫを介して受信機から戻される各クレジットによって表される前記受信機のＡＵの数を定義するクレジットリターンＡＣＫ単位（ＣＵ）をそこから決定することができるクレジット編成情報を、前記ピアリンクインタフェースから受信し、
前記ＡＵ及び前記ＣＵを利用して、各バッファで利用可能な前記バッファ空間の量をトラッキングする
回路及び論理を含む、請求項２に記載の装置。
【請求項４】
前記ピアリンクインタフェースから受信した前記クレジット編成情報が、ＡＵ変数（ｖＡＵ）及びＣＵ変数（ｖＣＵ）を含み、前記ＡＵ変数及び前記ＣＵ変数がそれぞれ、対数スケールを用いて対応するＡＵ及びＣＵを定義するように符号化される、請求項３に記載の装置。
【請求項５】
前記ピアリンクインタフェースが、ピア送信ポート及びピア受信ポートを含み、前記装置が、
複数のバッファに区分化されたバッファ空間を有する、前記受信ポートの受信バッファと、
前記装置の前記受信バッファの第１のクレジット編成情報を、前記ピアリンクインタフェースに送信し、前記第１のクレジット編成情報は、第１のｖＡＵ及び第１のｖＣＵを含み、
前記装置の前記受信ポートにおいて、前記ピアリンクインタフェースの前記受信バッファの第２のクレジット編成情報を受信し、前記第２のクレジット編成情報は、第２のｖＡＵ及び第２のｖＣＵを含み、
前記第１のｖＡＵ及び前記第１のｖＣＵに対応する第１のＡＵ及び第１のＣＵを利用して、前記装置の前記受信ポートの前記受信バッファにおいてバッファ空間が空いたのに応答して前記ピアリンクインタフェースに伝送するリターンクレジットＡＣＫを決定し、
前記第２のｖＡＵ及び前記第２のｖＣＵに対応する第２のＡＵ及び第２のＣＵを利用して、前記ピアリンクインタフェースの前記受信バッファのクレジットを管理及びトラッキングする、
回路及び論理とをさらに含む、請求項４に記載の装置。
【請求項６】
クレジットリターンＡＣＫが、対数スケールを用いて符号化されたマルチビットフィールドを含む、請求項１から５のいずれか一項に記載の装置。
【請求項７】
データが、リンクパケットを介して前記リンク上を転送され、クレジットリターンＡＣＫが、リンクパケットの側波帯フィールドに符号化され、前記リンクインタフェースが、リンクパケットの前記側波帯フィールドからクレジットリターンＡＣＫデータを抽出する回路及び論理を含む、請求項１から６のいずれか一項に記載の装置。
【請求項８】
データが、リンクパケットを介して前記リンク上を転送され、複数のＶＬに対応する複数のクレジットリターンＡＣＫが単一のデータ単位に符号化され、前記リンクインタフェースが、前記単一のデータ単位から前記複数のＶＬのクレジットリターンＡＣＫデータを抽出する回路及び論理を含む、請求項１から７のいずれか一項に記載の装置。
【請求項９】
前記リンクインタフェースが、
前記受信バッファについて実施するバッファ空間の再構成を定義するバッファ再構成情報を受信し、
前記バッファ再構成情報に基づいて、空間が再構成された前記受信バッファ中のそれぞれのバッファについて、前記送信ポートでトラッキングされた利用可能なクレジットを調節する
回路及び論理を含む、請求項１から８のいずれか一項に記載の装置。
【請求項１０】
前記受信バッファが、それぞれ対応するＶＬの専用である複数のＶＬバッファと、複数のＶＬの間で共有される少なくとも１つのバッファとに区分化される、請求項１から９のいずれか一項に記載の装置。
【請求項１１】
前記送信ポートの前記回路及び論理が、クレジットマネージャを実装する回路及び論理を含み、前記受信バッファ中の利用可能なバッファ空間の全てのクレジット管理及びトラッキングが、前記クレジットマネージャによって実行される、請求項１から１０のいずれか一項に記載の装置。
【請求項１２】
送信機において、受信機の受信バッファ中に実装される複数のバッファのそれぞれのクレジットの初期割当てを受信するステップであって、前記受信バッファが、それぞれ対応する仮想レーン（ＶＬ）に割り当てられる複数のＶＬバッファを含む複数のバッファに区分化された全体バッファ空間を有するステップと、
前記送信機において、前記受信機から戻される各クレジットによって表されるバッファ空間の量を示すクレジット編成情報を受信するステップと、
前記受信機によって受信されるように、前記送信機からデータをリンク上に伝送するステップと、
前記伝送されたデータによって消費される前記受信バッファ中のバッファ空間の量及び前記クレジット編成情報に基づいて前記受信バッファ中の適用可能なバッファについてバッファクレジットを割当て解除するステップと、
前記受信機からクレジットリターン確認応答（ＡＣＫ）を受信するステップであって、各クレジットＡＣＫがＶＬを識別し、１つ又は複数のクレジットが前記ＶＬのデータのバッファリングに割り当てられた少なくとも１つのバッファの空きバッファ空間の量を示すステップと、
送信ポートにおいて、前記割当て解除されたバッファクレジット及び前記クレジットリターンＡＣＫを介して戻されたクレジットに基づいて、前記受信バッファ中の各バッファに利用可能なクレジットをトラッキングするステップとを含む、方法。
【請求項１３】
割当て単位（ＡＵ）及びクレジットリターンＡＣＫ単位（ＣＵ）をそこから決定することができるクレジット編成情報を前記受信機から受信するステップであって、前記ＡＵが、前記受信バッファ中のバッファ割当てのための最小ブロックサイズを定義し、前記ＣＵが、前記クレジットリターンＡＣＫを介して前記受信機から戻される各クレジットによって表される受信機のＡＵの数を定義するステップとをさらに含む、請求項１２に記載の方法。
【請求項１４】
割当て単位（ＡＵ）変数（ｖＡＵ）及びクレジットリターンＡＣＫ単位（ＣＵ）変数（ｖＣＵ）を含むクレジット編成情報を前記受信機から受信するステップと、
前記ｖＡＵ及びｖＣＵに基づいて前記ＡＵ及びＣＵを決定するステップとをさらに含む、請求項１３に記載の方法。
【請求項１５】
前記送信機及び前記受信機が、前記リンクを介して結合された近隣デバイスの第１及び第２のリンクインタフェース中にそれぞれ実装されるように構成され、前記送信機が、第１の受信機をさらに含む前記第１のリンクインタフェース中に第１の送信機を含み、前記受信機が、第２の送信機をさらに含む前記第２のリンクインタフェース中に第２の受信機を含み、
前記方法が、
前記第１の受信機の第１のクレジット編成情報を前記第２の送信機に送信するステップであって、前記第１のクレジット編成情報が、第１のｖＡＵ及び第１のｖＣＵを含むステップと、
前記第１の受信機において、前記第２の受信機の第２のクレジット編成情報を受信するステップであって、前記第２のクレジット編成情報が、第２のｖＡＵ及び第２のｖＣＵを含むステップと
をさらに含む、請求項１４に記載の方法。
【請求項１６】
クレジットリターンＡＣＫが、対数スケールを用いて符号化されたマルチビットフィールドを含む、請求項１２から１５のいずれか一項に記載の方法。
【請求項１７】
データが、リンクパケットを介して前記リンク上を転送され、クレジットリターンＡＣＫが、リンクパケットの側波帯フィールドに符号化される、請求項１２から１６のいずれか一項に記載の方法。
【請求項１８】
データが、フリットを含むデータ単位で前記リンク上を転送され、複数のＶＬに対応する複数のクレジットリターンＡＣＫが、単一のフリットに符号化される、請求項１２から１７のいずれか一項に記載の方法。
【請求項１９】
前記送信機において、前記受信バッファについて実施するバッファ空間の再構成を定義する情報を受信するステップと、
前記送信機において、前記受信した情報に基づいて、空間が再構成された前記受信バッファ中のそれぞれのバッファについて利用可能なクレジットを調節するステップとをさらに含み、
前記受信バッファの前記バッファ空間の再構成が、前記受信機で前記再構成を調整する必要なく実施される、請求項１２から１８のいずれか一項に記載の方法。
【請求項２０】
前記受信バッファが、複数のＶＬバッファと、複数のＶＬの間で共有される少なくとも１つのバッファとに区分化される、請求項１２から１９のいずれか一項に記載の方法。
【請求項２１】
受信バッファを含む受信ポート、及び
送信ポートを含む、
リンクインタフェースと、
前記送信ポートに結合された、少なくとも１つの送信バッファを含む送信エンジンと、
前記受信ポートに結合された、少なくとも１つの受信バッファを含む受信エンジンと、
前記送信エンジン及び前記受信エンジンのそれぞれに結合された周辺機器相互接続エクスプレス（ＰＣＩｅ）インタフェースとを含む装置であって、
前記受信ポート及び前記送信ポートが、
前記装置が通信状態でリンクされるように構成されるピア装置のピアリンクインタフェースの受信ポートの受信バッファの初期の構成を定義するデータを受信し、ここで、前記受信バッファの前記初期の構成は、複数の専用仮想レーン（ＶＬ）バッファを含む複数のバッファに区分化されたバッファ空間を含み、前記データは、各バッファのクレジットの初期割当てを含み、
前記ピアリンクインタフェースから、前記ピア装置がクレジットリターン確認応答（ＡＣＫ）を介して戻す各リターンクレジットによって表されるバッファ空間の量を定義するデータを受信し、
前記ピアリンクインタフェースに、前記装置がクレジットリターンＡＣＫを介して前記ピア装置に戻す各リターンクレジットによって表されるバッファ空間の量を定義するデータを伝送し、
前記ピアリンクインタフェースの前記受信ポートによって受信されるようにデータを前記リンク上に伝送し、
伝送されたデータの量及び前記データを伝送するために使用されるＶＬに基づいて、前記ピアリンクインタフェースの前記受信バッファ中の適用可能なバッファのバッファクレジットを割当て解除し、
前記ピアリンクインタフェースからクレジットリターン確認応答（ＡＣＫ）を受信し、ここで、各クレジットリターンＡＣＫは、ＶＬと、前記ピアリンクインタフェースの前記受信バッファ中の前記ＶＬと関連付けられたバッファの１つ又は複数のリターンクレジットとを識別し、
前記受信バッファ中のバッファの利用可能なクレジットをトラッキングし、
前記装置の前記受信バッファ中の空きバッファ空間を決定し、
クレジットリターンＡＣＫを前記ピアリンクインタフェースに戻し、ここで、各クレジットリターンＡＣＫは、ＶＬと、前記装置の前記受信バッファの前記ＶＬと関連付けられたバッファの１つ又は複数のリターンクレジットとを識別する、
回路及び論理を含む、装置。
【請求項２２】
前記送信ポートの前記回路及び論理が、クレジットマネージャを実装する回路及び論理を含み、前記受信バッファ中の利用可能なバッファ空間の全てのクレジット管理及びトラッキングが、前記クレジットマネージャによって実行される、請求項２１に記載の装置。
【請求項２３】
クレジット編成情報が、前記受信バッファのバッファ割当てに使用される最小ブロックサイズに対応する割当て単位（ＡＵ）を含み、各バッファクレジットが、前記ＡＵの倍数であるバッファ空間に対応する、請求項２１又は２２に記載の装置。
【請求項２４】
前記リンクインタフェースが、
前記ＡＵのサイズをそこから決定することができ、前記クレジットリターンＡＣＫを介して受信機から戻される各クレジットによって表される前記受信機のＡＵの数を定義するクレジットリターンＡＣＫ単位（ＣＵ）をそこから決定することができるクレジット編成情報を、前記ピアリンクインタフェースから受信し、
前記ＡＵ及び前記ＣＵを利用して、各バッファで利用可能な前記バッファ空間の量をトラッキングする
回路及び論理を含む、請求項２３に記載の装置。
【請求項２５】
システムオンチップ（ＳｏＣ）を含み、前記送信エンジン及び前記受信エンジンのそれぞれに結合されたＰＣＩｅインタフェースに結合された前記ＰＣＩｅインタフェースを含むプロセッサをさらに含む、請求項２１から２４のいずれか一項に記載の装置。
【発明の詳細な説明】
【背景技術】
【０００１】
ハイパフォーマンスコンピューティング（ＨＰＣ）は、近年、用途及び関心が大幅に拡大している。歴史的に見ると、ＨＰＣは、一般にはいわゆる「スーパーコンピュータ」と関連付けられていた。スーパーコンピュータは、１９６０年代に登場し、当初の数十年間は、主にコントロールデータコーポレーション（ＣＤＣ）のシーモアクレイ、クレイリサーチ社、及びクレイの名前又はモノグラムを冠した後発の企業によって製造されていた。１９７０年代のスーパーコンピュータは数台のプロセッサしか使用していなかったが、１９９０年代には、数千台のプロセッサを備えたマシンが現れるようになり、さらに最近になると、数十万台の「既製」プロセッサを備えた大規模並列スーパーコンピュータが実現している。
【０００２】
ＨＰＣアーキテクチャには、実装型及び研究型ともに多くのタイプがあり、また規模及び性能のレベルも様々である。しかし、共通しているのは、プロセッサ及び／又はプロセッサコアなどの計算ユニットが多数相互接続されて、協働して並列にタスクを実行することである。最近のシステムオンチップ（ＳｏＣ）設計及び提案では、数十個のプロセッサコアなどが、２次元（２Ｄ）のアレイ状、円環状、環状又はその他の構成を用いて、単一のＳｏＣ上に実装される。さらに、研究者等は、数百個、さらには数千個ものプロセッサコアが３Ｄアレイ状に相互接続された３ＤのＳｏＣも提案している。別々のマルチコアプロセッサ及びＳｏＣを、複数のサーバボード上に近接配置して、これらのサーバボードを、バックプレーンなどを介して通信した状態で相互接続することもできる。もう１つの一般的な手法は、通常は２Ｄアレイとして構成される複数のサーバ（例えばブレードサーバ及びモジュールなど）のラックで計算ユニットを相互接続するものである。世界最速のスーパーコンピュータの１つであるＩＢＭ社製のＳｅｑｕｏｉａは、コアの総数が１，５７２，８６４個になる９６個のサーバブレード／モジュールのラックを並べた２Ｄアレイを含み、ピーク性能で動作すると７．９メガワットという大電力を消費する。
【０００３】
ＨＰＣの性能上のネックの１つは、計算ノード間の相互接続を介してデータを転送することにより生じる待ち時間である。通常、相互接続は、階層の最上位で速度が最高となり、プロセッサ／ＳｏＣ内の相互接続が最短となる相互接続階層の構造になっているが、階層レベルが下がるにつれて、待ち時間は長くなる。例えば、プロセッサ／ＳｏＣレベルの後に、この相互接続階層は、プロセッサ内相互接続レベル、ボード内相互接続レベル、及び個々のサーバ又は個々のサーバのアグリゲーションを他のラック内のサーバ／アグリゲーションと接続する１つ又は複数の追加のレベルを含むことがある。
【０００４】
相互接続階層の１つ又は複数のレベルで、異なるプロトコルを利用していることは、よくあることである。例えば、あるＳｏＣ内の相互接続は通常はプロプライエタリであるが、階層内の下位のレベルでは、プロプライエタリ又は標準化相互接続を利用する可能性がある。相互接続レベルが異なると、通常は、異なる物理（ＰＨＹ）レイヤが実装される。その結果として、相互接続レベル間をブリッジする何らかのタイプの相互接続を利用する必要がある。さらに、異種の計算環境が実施されるときには、所与の相互接続レベル内でブリッジが必要になることもある。
【０００５】
相互接続階層の下位レベルでは、イーサネット（登録商標）（様々なＩＥＥＥ８０２．３標準で定義される）及びＩｎｆｉｎｉＢａｎｄなどの標準化相互接続が使用される。ＰＨＹレイヤでは、これらの標準がそれぞれ、ワイヤケーブル及びバックプレーン並びに光学リンクなどを介した有線接続をサポートする。イーサネット（登録商標）は、ＯＳＩ７層モデルのリンクレイヤ（レイヤ２）に実装され、基本的にはリンクレイヤプロトコルと考えられる。ＩｎｆｉｎｉＢａｎｄ標準は、ＯＳＩレイヤ１〜４をカバーするＩｎｆｉｎｉＢａｎｄの様々なＯＳＩレイヤの特徴を定義する。
【０００６】
ＩｎｆｉｎｉＢａｎｄは、信頼性の低いリンク転送レイヤを想定した、絶対的なクレジット交換を使用するフロー制御機構を利用する。このような機構は、クレジット管理の際に協働する送信機及び受信機を両方とも必要とし、トラフィックが流れている間の再構成に対応することができない。送信機においてクレジット管理を実行し、トラフィックフローを混乱させることなくクレジットの再構成をサポートすれば、有利であろう。
【０００７】
本発明の上記の態様及び追加の利点の多くは、以下の詳細な説明を添付の図面と関連付けて参照すればより良く理解され、より容易に理解されるであろう。これらの図面では、特に指定がない限り、全ての図面で、同じ参照番号は同じ部分を指している。
【図面の簡単な説明】
【０００８】
【図１】１実施形態による、ファブリックアーキテクチャの様々な構成要素及び相互接続を含むシステムのハイレベル図を示す概略図である。
【図２】１実施形態による、ファブリックリンクを介してデータを転送するアーキテクチャのレイヤを示す概略図である。
【図３】バンドルにグループ化された複数のフリットを示す概略図である。
【図４】１実施形態による、ファブリックパケットの構造を示す概略図である。
【図５】１実施形態による、標準検出ＬＴＰのデータ構造を示す図である。
【図６】１実施形態による、１４ビットＣＲＣ  ＬＴＰのデータ構造を示す図である。
【図７】１実施形態による、強化検出ＬＴＰのデータ構造を示す図である。
【図８】１実施形態による、標準検出ヌルＬＴＰのデータ構造を示す図である。
【図９ａ】１実施形態による、リンクファブリックサブレイヤとリンク転送サブレイヤの間のインタフェースにおいて標準検出ＬＴＰのフリットが一度に２つずつ並列に処理される４レーンリンクの伝送方式の実施形態を示す図である。
【図９ｂ】１実施形態による、リンクファブリックサブレイヤとリンク転送サブレイヤの間のインタフェースにおいて強化検出ＬＴＰのフリットが一度に２つずつ並列に処理される４レーンリンクの伝送方式の実施形態を示す図である。
【図１０】１実施形態による、リンクファブリックサブレイヤとリンク転送サブレイヤの間のインタフェースにおいて２つのフリットが一度に２つ並列に処理される４レーンリンクを介した２つの制御ビットを有する１４ビットＣＲＣ  ＬＴＰの伝送を示す概略図である。
【図１１】１実施形態による、連結された２つの４レーンリンクからなる８レーンデータ経路を介した、並列な、２つの制御ビットを有する２つの１４ビットＣＲＣ  ＬＴＰの伝送を示す概略図である。
【図１２】１実施形態による、４つのレーンを利用した２つのリンクポートの間の双方向データ伝送の一例を示す概略図である。
【図１３】別個の仮想レーンを介して送信された２つのＦＰのファブリックパケットフリットのインタリーブの実施形態の一例を示す図である。
【図１４】１実施形態による、プッシュ／ポップインタリーブの使用を説明する図である。
【図１５】１実施形態による、プッシュ／ポップインタリーブとＶＬマーカインタリーブの組合せの使用を説明する図である。
【図１６】１実施形態による、別個の優先レベルを有するＶＬに対応する３つの別個のＶＬ  ＦＩＦＯにバッファリングされた３つのファブリックパケットのフリットのプリエンプティブインタリーブの一例を示す概略図とタイムフロー図を組み合わせた図である。
【図１７】１実施形態による、２つのＶＬの優先レベルが同じであり、残り１つのＶＬの優先レベルがそれらより高い３つの別個のＶＬ  ＦＩＦＯにバッファリングされた３つのファブリックパケットのフリットのバブルインタリーブ及びプリエンプティブインタリーブの一例を示す概略図とタイムフロー図を組み合わせた図である。
【図１８ａ】１実施形態による、ＬＴＰ伝送方式の伝送と、ＬＴＰレーン及びエラントなレーンを検出するためのレーンごとのＣＲＣ及びＬＴＰ  ＣＲＣの使用とを説明する概略図であり、図１８ａは、ＬＴＰ伝送方式におけるＬＴＰの最初の伝送を示す図である。
【図１８ｂ】１実施形態による、ＬＴＰ伝送方式の伝送と、ＬＴＰレーン及びエラントなレーンを検出するためのレーンごとのＣＲＣ及びＬＴＰ  ＣＲＣの使用とを説明する概略図であり、図１８ｂは、再現バッファを用いてＬＴＰ伝送ストリーム中のＬＴＰの再伝送を示す図である。
【図１８ｃ】１実施形態による、再試行マーカ及びラウンドトリップマーカを使用して、再現バッファのＬＴＰが上書きされることを防止することを説明する概略図である。
【図１９】１実施形態による、３３個の転送グループ（ＸＦＲ）を用いた標準検出ＬＴＰの伝送を説明する図である。
【図２０】１実施形態による、３３個の３２ビットＸＦＲ及び４つのＬＴＰシーケンス状態を用いた、４レーンリンクを介したＬＴＰの伝送を説明する図である。
【図２１】１実施形態による、８バイトのデータと６５番目のビットとを含むフリットデータが、３３個の３２ビットＸＦＲを用いて４レーンリンクを介してどのように転送されるかを説明する図である。
【図２２ａ】再現バッファとともに暗示的なＡＣＫを用いたリンクレベルでの信頼できるＬＴＰ伝送を容易にする動作及び論理を示す複数ページの流れ図を集合的に含み、１実施形態によるエラントなレーンを検出する動作及び論理も説明する図である。
【図２２ｂ】再現バッファとともに暗示的なＡＣＫを用いたリンクレベルでの信頼できるＬＴＰ伝送を容易にする動作及び論理を示す複数ページの流れ図を集合的に含み、１実施形態によるエラントなレーンを検出する動作及び論理も説明する図である。
【図２２ｃ】再現バッファとともに暗示的なＡＣＫを用いたリンクレベルでの信頼できるＬＴＰ伝送を容易にする動作及び論理を示す複数ページの流れ図を集合的に含み、１実施形態によるエラントなレーンを検出する動作及び論理も説明する図である。
【図２２ｄ】再現バッファとともに暗示的なＡＣＫを用いたリンクレベルでの信頼できるＬＴＰ伝送を容易にする動作及び論理を示す複数ページの流れ図を集合的に含み、１実施形態によるエラントなレーンを検出する動作及び論理も説明する図である。
【図２２ｅ】再現バッファとともに暗示的なＡＣＫを用いたリンクレベルでの信頼できるＬＴＰ伝送を容易にする動作及び論理を示す複数ページの流れ図を集合的に含み、１実施形態によるエラントなレーンを検出する動作及び論理も説明する図である。
【図２３ａ】１実施形態による送信機の状態図である。
【図２３ｂ】１実施形態による受信機の状態図である。
【図２４】１実施形態による、ＸＦＲグループに基づいて計算されて記憶されるレーンごとのＣＲＣを示す図である。
【図２５】第１のＬＴＰシーケンス状態での不良ＬＴＰの最初の伝送中にレーンごとのＣＲＣを計算する、図１８ａ及び図１８ｂの例についてのＸＦＲグループごとに記憶される例示的なレーンごとのＣＲＣ計算と、第３のＬＴＰシーケンス状態での再現バッファからの不良ＬＴＰの再伝送とを示す図である。
【図２６】１実施形態による、１１個のＸＦＲが並列にレーンごとに転送される、３つのレーンを介した標準検出ＬＴＰの転送を示す図である。
【図２７】１実施形態による、２つのレーンを介した標準検出ＬＴＰの転送であって、１７個のＸＦＲが２つのレーンのうちの一方を介して転送され、１６個のＸＦＲが他方のレーンを介して転送される、２つのＬＴＰシーケンス状態を利用する転送を示す図である。
【図２８】１実施形態による、３３個の３２ビットＸＦＲを用いた、単一のレーンを介した標準検出ＬＴＰの伝送を示す図である。
【図２９】１実施形態による、スイッチ及びＨＦＩのポートとアーキテクチャのレイヤ及びサブレイヤとの間の関係を示す図である。
【図３０】送信機と受信機のピアの間でのクレジット編成及びクレジットリターンＡＣＫの交換を示す概略図である。
【図３１ａ】１実施形態による、専用バッファ編成、共有２ティアバッファ編成及び共有３ティアバッファ編成の例を示す図である。
【図３１ｂ】１実施形態による、専用バッファ編成、共有２ティアバッファ編成及び共有３ティアバッファ編成の例を示す図である。
【図３１ｃ】１実施形態による、専用バッファ編成、共有２ティアバッファ編成及び共有３ティアバッファ編成の例を示す図である。
【図３２】１実施形態による、増分クレジットＡＣＫのＬＦコマンドフリットフォーマットの一例を示す図である。
【図３３】それぞれ異なるｖＡＵ及びｖＣＵの値を有する２つの異なるデバイスタイプの一例を示す概略図である。
【図３４】１実施形態による、プリエンプションをサポートするＶＬアービトレーション機構を示す概略図である。
【図３５】５ｘ４プリエンプションマトリクスの一例を示す図である。
【図３６】ファブリックリンクを介して相互接続された異なる構成要素で異なる数のＶＬがサポートされる異質ファブリック構成の一例を示すブロック図である。
【図３７】１実施形態による、ＨＦＩのＬ４レイヤによるファブリックへのパケットの注入に関連するＱｏＳマッピングの一例を示す概略図である。
【図３８】１実施形態による、スイッチの入力ポートで受信され、そのスイッチの出力ポートに伝送されるパケットの内部転送に関連して実行されるＱｏＳマッピングを示す概略図である。
【図３９】１実施形態による、ＨＦＩにおけるファブリックから排出されたパケットの受信に関連するＱｏＳマッピングの一例を示す概略図である。
【図４０】１実施形態による、ＶＬ拡大マッピングの一例を示す概略図である。
【図４１】１実施形態による、ＶＬ縮小マッピングの一例を示す概略図である。
【図４２】１実施形態による、９ＢファブリックパケットをサポートするＳＬ／ＶＬレガシーモードを示す概略ブロック図である。
【図４３】１実施形態による、９Ｂ、１０Ｂ及び１６ＢファブリックパケットをサポートするハイブリッドＳＬ／ＶＬレガシーモードを示す概略ブロック図である。
【図４４】クレジットループ回避を備えたトポロジにおけるＴＣ、ＳＬ及びＳＣの使用の一例を示す図である。
【図４５】１実施形態による、汎用ファブリックパケットフォーマットを示す図である。
【図４６】１実施形態による、ファブリックパケット８Ｂヘッダフォーマットを示す図である。
【図４７】１実施形態による、ファブリックパケット１０Ｂヘッダフォーマットを示す図である。
【図４８】１実施形態による、ファブリックパケット１６Ｂヘッダフォーマットを示す図である。
【図４９】１実施形態による、ファブリックパケット９Ｂヘッダフォーマットを示す図である。
【図５０】送信ポート及び受信ポートを含むポートの実施形態を示す概略図である。
【図５１】１実施形態による、ファブリックスイッチを示す概略図である。
【図５２】１実施形態による、ファブリックスイッチによって実行される動作を示す流れ図である。
【図５３】１実施形態による、ＨＦＩを含むシステムを示す概略図である。
【発明を実施するための形態】
【０００９】
本明細書では、ハイパフォーマンスファブリック内で柔軟なクレジット交換を実施するための方法、装置、及びシステムの実施形態について説明する。以下の説明では、本発明の実施形態が完全に理解されるように、多数の具体的な詳細について述べる。ただし、当業者なら、本発明がこれらの具体的な詳細のうちの１つ又は複数がない状態で実施することもできること、或いは他の方法、構成要素、材料などを用いて実施することもできることを理解するであろう。他に、周知の構造、材料、又は動作については、本発明の特徴を曖昧にすることを避けるために、詳細には図示又は説明しない。
【００１０】
本明細書全体を通じて、「１実施形態」又は「実施形態」と述べるときは、その実施形態に関連して述べられる特定の機能、構造、又は特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書中の様々な箇所で「１実施形態では」又は「実施形態では」という言い回しがあっても、その全てが必ずしも同じ実施形態について言及しているわけではない。さらに、これらの特定の機能、構造、又は特性は、１つ又は複数の実施形態において、任意の適当な形で組み合わせられることもあり得る。
【００１１】
分かりやすいように、本明細書の図面中の個々の構成要素は、特定の参照番号ではなく、図中の標識で呼ぶこともある。さらに、特定の種類の構成要素（特定の構成要素ではなく）を指す参照番号は、参照番号の後に「代表例」を意味する「（ｔｙｐ）」を付して示してあることもある。これらの構成要素の構成は、図面に示す同様の構成要素の代表的なものではあるが、簡潔かつ明瞭にするために、標識は付していないことを理解されたい。逆に、「（ｔｙｐ）」は、その構成要素や要素などが開示した機能や実施態様、目的などのために使用されるのが普通であることを意味していると解釈すべきではない。
【００１２】
本明細書に記載する実施形態の特徴によれば、メッセージパッシング交換サーバ相互接続ネットワークを定義するアーキテクチャが提供される。このアーキテクチャは、ＯＳＩネットワークモデルのレイヤ１及び２にまたがり、レイヤ３についてはＩＥＴＦインターネットプロトコルをレバレッジし、アーキテクチャのレイヤ４については新たな仕様とレバレッジ仕様の組合せを含む。
【００１３】
このアーキテクチャは、スーパーコンピュータなどの形式定義によって、又はクラウドコンピューティングでしばしば見られるようにそれらが実行するメッセージパッシングアプリケーションにより何らかの協調的な方法で機能する複数のサーバのグループ又はクラスタなどの単純な関連付けによって、ＣＰＵと論理メッセージパッシング構成を含むその他のサブシステムとを相互接続するように実装することができる。相互接続された構成要素は、ノードと呼ばれる。ホストと呼ばれる１つのタイプのノードは、ユーザモードソフトウェアが実行されるタイプである。１実施形態では、ホストは、そのコヒーレントな領域内のコア又はＣＰＵの数に関わらず単一のキャッシュコヒーレントメモリ領域を含み、様々なローカルのＩ／Ｏ及び記憶サブシステムを含むことができる。ホストが実行するソフトウェアのタイプが、ユーザアプリケーションノード、或いは記憶又はファイルサーバなど、より詳細な機能を定義することができ、より詳細なシステムアーキテクチャを記述する役割を果たす。
【００１４】
最上位レベルでは、このアーキテクチャは、以下の構成要素を定義する。
・ホストファブリックインタフェース（ＨＦＩ）、
・リンク、
・スイッチ、
・ゲートウェイ、及び
・総合管理モデル。
【００１５】
ホストファブリックインタフェースは、最小では、アーキテクチャの物理レイヤ及びリンクレイヤを実装する論理からなり、ノードをファブリックに接続して、そのノードがパケットを他のサーバ又はデバイスと送受信することができるようになっている。ＨＦＩは、オペレーティングシステム及びＶＭＭ（仮想マシンマネージャ）をサポートする適当なハードウェアインタフェース及びドライバを含む。ＨＦＩは、上位レイヤのプロトコルの実行又は加速及び／或いはトランスポートプロトコルのオフロードのための特殊論理を含むこともできる。ＨＦＩは、ネットワーク管理構成要素からのメッセージに応答する論理も含む。各ホストは、ＨＦＩを介してアーキテクチャファブリックに接続される。
【００１６】
リンクは、ＨＦＩをスイッチに接続する、スイッチをその他のスイッチに接続する、又はスイッチをゲートウェイに接続する、全二重ポイントツーポイント相互接続である。リンクは、回路基板トレース、銅線、又は光ケーブルで、様々な物理的構成を有することができる。１実施形態では、ＰＨＹ（物理レイヤ）、ケーブル、コネクタのストラテジは、イーサネット（登録商標）のもの、具体的には１００ＧｂＥ（ＩＥＥＥ８０２．３ｂｊドラフト標準（現在のドラフト２．２）に定義されるイーサネット（登録商標）リンクなど、１００ギガビット毎秒のイーサネット（登録商標））に従う。このアーキテクチャは柔軟であり、１００ＧｂＥ帯域幅を超える可能性がある将来のイーサネット（登録商標）又はその他のリンク技術の使用に対応している。ハイエンドスーパーコンピュータ製品は、特殊目的（はるかに帯域幅の大きい）ＰＨＹを使用する可能性があり、これらの構成では、アーキテクチャ製品との相互運用性は、異なるＰＨＹを有するポートを有するスイッチに基づくことになる。
【００１７】
スイッチは、ＯＳＩレイヤ２の構成要素であり、このアーキテクチャの管理インフラストラクチャによって管理される。このアーキテクチャは、インターネットプロトコルを、そのＯＳＩレイヤ３又はインターネットワーキングレイヤとして定義するが、アーキテクチャは、ＩＰドメインには何も指定せず、またＩＰ関連デバイスも管理しない。アーキテクチャファブリックと外部ネットワーク、特にイーサネット（登録商標）との間の接続性をサポートするデバイスは、ゲートウェイと呼ばれる。軽量なゲートウェイは、提供する機能が削減され、厳密にイーサネット（登録商標）のレイヤ２のみの挙動になる可能性がある。フル装備のゲートウェイは、レイヤ３以上でも動作することができるので、ルータとして挙動することができる。このアーキテクチャによって提供されるゲートウェイの仕様は、イーサネット（登録商標）のカプセル化のための機構を含み、ゲートウェイがアーキテクチャの残りの部分と整合性のあるイーサネット（登録商標）データセンタネットワークへの柔軟な接続性を可能にするためにファブリック上でどのように挙動するかを含む。インターネットワーキングプロトコルとしてＩＰを使用することにより、ＩＥＴＦで承認されているトランスポート、すなわちＴＣＰ、ＵＤＰ、及びＳＣＴＰを使用して、アーキテクチャのファブリックを超えてメッセージを送受信することができる。
【００１８】
図１は、１実施形態によるアーキテクチャの様々な構成要素及び相互接続を示すシステム１００のハイレベル図である。このアーキテクチャの中心の機能は、ファブリック１０２であり、ファブリック１０２は、アーキテクチャのリンク及びスイッチを介して相互接続されたＨＦＩ及びゲートウェイの集合体を含む。図１に示すように、ファブリック１０２の構成要素は、離散した単ノードプラットフォーム１０６をそれぞれホストとする複数のＨＦＩ１０４（１つのみ示す）と、仮想プラットフォーム１１０をホストとするＨＦＩ１０８と、多ノードプラットフォーム１１６のノード１１４１及び１１４ｎをそれぞれホストとするＨＦＩ１１２１及び１１２ｎと、一体化された単ノードプラットフォーム１２０のＨＦＩ１１８１及び１１８ｎと、高基数スイッチ１２２と、スイッチ１２４及び１２６と、１つ又は複数のファブリックマネージャ１２８と、ゲートウェイ１３０と、リンク１３２、１３４、１３６１、１３６ｎ、１３８、１４０１、１４０ｎ、１４２、１４４、１４８と、クラウド１５０としてまとめて示してある複数の追加のリンク及びスイッチとを含む。
【００１９】
上述のように、スイッチは、レイヤ２のデバイスであり、ファブリック内のパケット転送機構として作用する。スイッチは、中央に設けられ、ファブリック管理ソフトウェアによって管理され、各スイッチは、管理トランザクションに応答する管理エージェントを含む。「中央に設けられる」とは、転送テーブルが、ファブリック管理ソフトウェアによって、適応経路選択を行う代替経路のように、特定のファブリックトポロジ及び転送機能を実施するようにプログラムされることを意味する。スイッチは、適応経路選択及びロードバランシングなどのＱｏＳフィーチャの実行を担当し、また、輻輳管理機能を実施する。
【００２０】
図２は、このアーキテクチャの、ファブリックリンクを介してデータを転送するレイヤを示す図である。これらのレイヤは、物理（ＰＨＹ）レイヤ、リンク転送サブレイヤ、リンクファブリックサブレイヤ、及びトランスポートレイヤを含む。図２の左側は、これらのレイヤのＯＳＩ参照モデルへのマッピングであり、ＰＨＹレイヤは、レイヤ１（ＰＨＹレイヤ）にマッピングされ、リンク転送サブレイヤ及びリンクファブリックサブレイヤは、まとめてレイヤ２（リンクレイヤ）にマッピングされ、トランスポートレイヤは、レイヤ４（トランスポートレイヤ）にマッピングされている。
【００２１】
このアーキテクチャでは、信号は、物理レイヤでポートにグループ化される。これらのポートは、モノリシックなエンティティとして挙動し、モノリシックなエンティティとして制御することができ、モノリシックなエンティティとして報告される。ポートは、１つ又は複数の物理レーンを含み、各レーンは、各通信方向に１対ずつ、物理伝送媒体に実装される２対の差動ファイバ対からなる。１つのポートを構成するレーンの数は、実施態様によって決まる。ただし、リンク転送サブレイヤのアーキテクチャは、有限の組のポート幅をサポートしている。特定のポート幅を基本ポート幅としてサポートして、ケーブル及びチップの設計の共通の目標を見込む。ポート幅は、１ｘ、４ｘ、８ｘ、１２ｘ及び１６ｘを含む。ここで、「ｘ」は、物理レーンの数を示す。欠陥レーンの検出など、いくつかの状況では、リンクは、減少したレーン幅で動作することがある。
【００２２】
リンク転送サブレイヤは、物理レイヤとリンクファブリックサブレイヤとの間のインタフェースとして機能する。（リンクファブリックサブレイヤの）リンクファブリックパケットは、６４ビットフロー制御ディジット（ＦＬＩＴ、Ｆｌｉｔ又はフリット、フロー制御ディジットの近似縮約）にセグメント化される。図３は、バンドル３０２にグループ化された複数のフリット３００の一例を示す図である。各フリット３００は、８バイトのデータを構成する６４データビットを含む。
【００２３】
リンク転送サブレイヤは、複数のレーンを、信頼できる方法で、リンクを介して、フリット及びそれらに関連するクレジットリターン情報を転送することができる複数のチームに形成する。これは、リンク転送パケット（ＬＴＰ）と呼ばれる１０５６ビットバンドルを用いて実施され、リンク転送パケットは、リンクファブリックサブレイヤに関連する。図３は、１６フリットのデータを含むＬＴＰのデータ部分も示している。さらに、ＬＴＰは、フリットタイプ情報、ＣＲＣデータ、及び任意選択データ（図３には図示せず）も含む。ＬＴＰの例については、様々な図（例えば図５〜図１１）に示し、以下でさらに詳細に説明する。
【００２４】
ファブリックパケットは、６４ビットフリットと、各フリットごとのフリットタイプビットとで構成される。ファブリックパケットの最初のデータフリットは、ヘッドフリットと呼ばれる。ファブリックパケットの最後のデータフリットは、テールフリットと呼ばれる。ファブリックパケット中のその他の任意のデータフリットは、ボディフリットと呼ばれる。ファブリックパケット４００の一例を、図４に示す。
【００２５】
フリットタイプビットは、ボディフリットを他のフリットタイプから識別するために各フリットごとに設けられる。１実施形態では、ボディフリットは、１に設定されたフリットタイプビットで符号化され、６４ビットのデータを含む。その他の全てのフリットは、０に設定されたタイプビットでマークされる。ヘッドフリットは、１に設定されたフリット［６３］で符号化される。その他の全ての（非ボディの）フリットは、０に設定されたフリット［６３］で符号化される。テールフリットは、１に設定されたフリット［６２］で符号化される。その他の全ての（非ボディ／ヘッド）のフリットは、０に設定されたフリット［６２］で符号化される。フリットの符号化を、以下の表１に要約する。
【００２６】
【表１】
0006297698.tif 000002
【００２７】
制御フリットは、表２に要約する。リンク転送レイヤのみによって使用される７つの制御フリット（ＬＴ制御フリット）は、ヌルＬＴＰで送信される。残りの制御フリットは、２つのグループに分割される。ファブリックパケット（ＦＰ）フリットは、制御フリットＨｅａｄＢａｄＰｋｔ、ＢｏｄｙＢａｄＰｋｔ、及びＴａｉｌＢａｄＰｋｔ、並びに通常のパケットのフリットＨｅａｄ、Ｂｏｄｙ、及びＴａｉｌを含む。リンクファブリック（ＬＦ）コマンドフリットは、フリットＩｄｌｅ、ＶＬＭｒｋｒ、及びＣｒｄｔＲｅｔを含む。ＦＰフリット及びＬＦコマンドフリットは、リンクを介して伝送するために、信頼できるＬＴＰ内で混合することができる。
【００２８】
【表２】
0006297698.tif 000003
【００２９】
遊休コマンドフリットは、データストリームに挿入するファブリックパケットフリットがないときに、リンクファブリックレイヤによって使用される。データ経路の全幅が遊休を含む場合には、リンク転送レイヤは、入力バッファに挿入されたフリットストリームからこれらを除去する。データ経路が遊休及び非遊休フリットの両方を含む場合には、遊休は除去されない。これは、リンク転送レイヤがリンクの遠端にあるリンクファブリックレイヤに対して同じデータ経路組成を提示するようにするために実施される。リンク転送レイヤが、リンクファブリックレイヤから継続するフリットを有していない場合には、リンク転送レイヤは、元のフリットがリンクを介して送信されるときに、遊休を挿入する。元のフリットとは、再伝送又は再現されたフリットを含む再現バッファから送信されるフリットに対して、リンクを介して最初に送信されるフリットである。
【００３０】
リンク転送パケットは、リンクを介して伝送するために１６個のフリットを保持する。信頼できるＬＴＰは、再伝送要求がないことで、それがリンクピアによって上手く受信されていることが分かることを保証するのに十分に長い期間、再現バッファに保持される。再現バッファ位置ポインタは、送信機（ＮｘｔＴｘＬＴＰ）及び受信機（ＮｘｔＲｘＬＴＰ）の両方で各ＬＴＰごとに維持されるが、ＬＴＰの一部として交換されない。伝送エラーが受信機で検出されると、受信機は、ＮｘｔＲｘＬＴＰ再現バッファ位置ポインタを含むＲｅｔｒｙＲｅｑＬＴＰを送信機に送信する。ＲｅｔｒｙＲｅｑＬＴＰを受信したのに応答して、再現バッファ中のＬＴＰは、ＲｅｔｒｙＲｅｑＬＴＰ（ピアＮｘｔＲｘＬＴＰ）で始まり、最後に書き込まれた再現バッファ位置（ＮｘｔＷｒＬＴＰ−１）で終わる、元の順序で再伝送される。ヌルＬＴＰは、再現バッファに保持されず、再伝送されない。
【００３１】
リンクファブリックコマンドフリットは、ＬＴＰ中のＦＰフリットと混合することができる。ただし、ＬＦコマンドフリットは、ファブリックパケットの一部ではない。ＬＦコマンドフリットは、リンクの一端のリンクファブリックサブレイヤから、リンクの他端のリンクファブリックサブレイヤまで制御情報を搬送する。
【００３２】
１実施形態では、標準検出ＬＴＰ、１４ビットＣＲＣ  ＬＴＰ、及び強化検出ＬＴＰという、３つのＬＴＰのフォーマットがある。標準検出ＬＴＰの実施形態を、図５に示す。１６個のフリットに加えて、各標準検出ＬＴＰは、ＬＴＰのコンテンツをカバーする１６ビットＣＲＣを有する。例示を目的として、図５に示すフリットは、ビット６４がフリットタイプビットである６５ビットとして示してある。
【００３３】
１４ビットＣＲＣ  ＬＴＰの実施形態を、図６に示す。１６個のフリットに加えて、各１４ビットＣＲＣ  ＬＴＰは、２ビットのクレジット側波帯チャネルと、ＬＴＰのコンテンツをカバーする１４ビットＣＲＣとを有する。フロー制御クレジットは、特殊ＬＦコマンドフリット又はＬＴＰクレジット側波帯チャネルのいずれかのＬＴＰ内に含めて伝送される。
【００３４】
標準検出ＬＴＰに加えて、リンクは、１６個のフリットを保持し、４つの１２ビットＣＲＣフィールドを有する、任意選択の強化検出ＬＴＰもサポートすることができる。図７は、強化検出ＬＴＰの実施形態のフォーマットを示す図である。４つのＣＲＣフィールドはそれぞれ、１６個のフリット全てをカバーする。４つのＣＲＣのうちいずれかが不良である場合には、ＬＴＰは再伝送される。４つの１２ビットＣＲＣに対して、２通りのＣＲＣ計算オプションがある。第１のオプション（４８ｂ重複）は、各計算がＬＴＰ内の全てのビットをカバーする、４つの重複計算を使用するものである。第２のオプション（レーンあたり１２ｂ−１６ｂＣＲＣ）は、各計算が４つのレーンのうちの１つを流れる全てのビットに限定された、４つの非重複計算を使用するものである。
【００３５】
上述のように、リンク転送レイヤで使用されるＬＴ制御フリットは、ヌルＬＴＰで送信される。ヌルＬＴＰは、再現バッファ中のスペースを消費せず、再伝送されない。ヌルＬＴＰは、上記の表２に要約したリンク転送ＬＴ制御フリットのうちの１つを用いて識別される。ヌルＬＴＰのタイプのほとんどは、逐次対で送信され、２つのうちの少なくともいずれか１つはエラーなくリンクピアによって受信されること、又はその両方にエラーがあるときにＲｅｔｒａｉｎＲｅｔｒｙＲｅｑが自動的に生成されることを保証するようになっている。標準検出ヌルＬＴＰの一例を、図８に示す。
【００３６】
標準検出ヌルＬＴＰは、単一の識別制御フリットと、９７５個の反転ビットと、標準検出１６ビットＣＲＣフィールドとを含む。強化検出ヌルＬＴＰは、単一の識別制御フリットと、９７５個の反転ビットと、４つの強化検出１２ビットＣＲＣフィールドとを含む。１４ビットＣＲＣを使用するときには、ヌルＬＴＰ中の２つの側波帯ビットは無視する。
【００３７】
４つのレーンを有するリンクに接続された４ｘ対応ポート及び８ｘ対応ポートの両方で、一度に１つのＬＴＰが、リンクを介して伝送される。これを、標準検出ＬＴＰ及び強化検出ＬＴＰの両方について、それぞれ図９ａ及び図９ｂに、リンクファブリックデータ経路図を用いて示し（ＣＲＣフィールドは正しい縮尺ではないことに留意されたい）、対応する信号処理及び転送経路の実施形態は、図１０に示す。１４ビットＣＲＣ  ＬＴＰは、ＬＣＲＣ［１５：０］フィールドがＬＣＲＣ［１３：０］フィールド及びＣ［１：０］フィールドの組合せで置換されることを除けば、図８に示す標準検出ＬＴＰと同様である。フリット伝送順序は、フリット０から開始され、フリット１５で終了する。
【００３８】
１実施形態では、各レーンを介したデータの物理伝送は、各レーンに対応するデータが、サイクルごと、レーンごとに復号され、非直列化され、４バイトにグループ化される、シリアル２レベルビット非ゼロ復帰（ＮＲＺ）符号化ビットパターンを利用する。これにより、サイクルごとに２つのフリットを構成する１６バイトが転送されることになる。例えば、図９ａ及び図１０は、フリット２つ分の幅を有する実施態様に特有のデータ経路を想定しており、この想定では、フリット０及びフリット１が同時に伝送され、フリット２及びフリット３が同時に伝送される、といった具合になる。ＬＣＲＣは、リンク転送サブレイヤによって計算される。
【００３９】
図１１は、２つの４レーンリンクが連動して、８個のレーンを介してデータが伝送される８ｘデータ経路をサポートする、ＬＴＰ伝送方式を示す図である。図示のように、この方式では、２つのＬＴＰの４つのフリットが、リンクファブリックサブレイヤとリンク転送サブレイヤの間のインタフェースで並列に処理される。
【００４０】
上述のように、このアーキテクチャは、ファブリックパケット、フリット、及びリンク転送パケットの、３つのレベルのデータ単位細分性を利用して、データ転送をサポートしている。リンク転送レイヤにおける伝送単位は、ＬＴＰである。図示のように、各ＬＴＰは、名目上はフリット１６個分の長さを有するが、上述のように、ＬＴＰの実際のサイズは、使用される個々のＣＲＣ方式に応じて変化する可能性があり、フリット１６個分の長さを有するＬＴＰという言い方を用いるのは、ＣＲＣビット及び１６個のビット６５を除く、ＬＴＰに含まれるデータの６４ビットフリットの数に対応する。
【００４１】
４つの物理レーンを含むリンクの１実施形態の物理レイヤ（「ＰＨＹ」とも呼ぶ）構造を、図１２に示す。ＰＨＹは、リンク相互接続の物理構造を定義し、構成要素Ａ及びＢで示すものなど、２つのリンクピアの間の特定のリンク上での信号の動作の詳細を扱うことを担当する。このレイヤは、電気的なレベル、タイミングの特徴、及び論理上の問題など、平行レーンを横切る情報の各ビットの送受信に伴う信号線上のデータ転送を管理する。図１２に示すように、各相互接続リンクの物理接続性は、各方向にレーン０〜３を含む、４つの差動信号対１２００で構成される。各ポートは、２つの１方向リンクからなるリンク対をサポートして、２つのピア構成要素の間の接続を完成する。これは、両方向のトラフィックを同時にサポートする。例示のために、また理解を容易にするために、図１０に示すレーンの「スウィズル」は、図１２には示していない。ただし、いくつかの実施形態では、送信レーンと受信レーンがスウィズルされることは理解されるであろう。
【００４２】
リンクポートを備えた構成要素は、図１２に示すように、リンクピアとして定義される１対の１方向ポイントツーポイントリンクを用いて通信する。各ポートは、送信（Ｔｘ）リンクインタフェース及び受信（Ｒｘ）リンクインタフェースを含む。図示の例では、構成要素Ａは、構成要素ＢのＲｘポート１２０４に接続されたＴｘポート１２０２を有する。一方、構成要素Ｂは、構成要素ＢのＲｘポート１２０８に接続されたＴｘポート１２０４を有する。一方の１方向リンクは、構成要素Ａから構成要素Ｂに伝送し、他方のリンクは、構成要素Ｂから構成要素Ａに伝送する。「送信」リンク及び「受信」リンクは、どちらの構成要素のポートがデータを伝送し、どちらが受信しているかに関して定義される。図１２に示す構成では、構成要素Ａの送信リンクは、構成要素ＡのＴｘポート１２０２から構成要素ＢのＲｘポート１２０４にデータを伝送する。この同じ構成要素Ａの送信リンクが、ポートＢの受信リンクである。前述のように、リンクポート間でデータを転送する機能単位は、ＬＴＰである。各ＬＴＰは、リンクの両側の送信ポート及び受信ポートによって定義される特定のリンクを介した１方向の伝送に特有である。ＬＴＰは、１回のリンク転送の分の寿命を有し、ＬＴＰは、適用可能なＶＬバッファからフリットを引き出し、それらを一度に１６個ずつそれぞれのＬＴＰにアセンブルすることによって動的に生成される。ＬＴＰ伝送ストリーム１２１０及び１２１２によって示すように、ＬＴＰは、フリットのストリームとして伝送され、個々のＬＴＰの最初のフリット及び最後のフリットは、図４を参照して上述したように、ヘッドフリットビット及びテールフリットビットによって表される。
【００４３】
上述のように、このアーキテクチャは、主として宛先経路指定されたファブリックパケット又はＦＰを含み、レイヤ４のペイロードサイズが０バイトから１０２４０バイトであるパケット送達機構を定義する。これにより、単純なＵＬＰ確認応答からカプセル化イーサネット（登録商標）ジャンボフレームまでの範囲のメッセージの送信が効率的にサポートされる。ファブリックパケットは、ＨＦＩにイングレスするペイロード及びＨＦＩからエグレスするペイロードの論理単位を表す。ファブリックパケットは、ファブリックのエンドツーエンドの寿命を有することから、そのように名付けられている。さらに詳細には、ファブリックパケットの寿命は、ＦＰの発信元アドレス及び宛先アドレスによって定義されるファブリックのエンドポイント間でそのＦＰのコンテンツを転送するのに必要な時間である。ＦＰの各転送経路は、少なくとも１つのリンクを介した転送を含むことになり、転送経路が１つ又は複数のスイッチを横切るときには、複数のリンクを介した転送を含むこともある。
【００４４】
フリットをＦＰ及びＬＴＰと組み合わせて使用することにより、このアーキテクチャに特有のデータ転送機能性が高められる。特に、ＦＰと、フリットと、ＬＴＰとを分離すると、仮想レーンの使用、並びにＱｏＳ及びファブリックロバストネスの様々な特徴に対応できる。
【００４５】
上述のように、フリットは、単独では伝送されるのではなく、１６個のフリットからなるグループが、リンク転送パケットにパックされる（バンドリングされる）。これにより、これらのフリットは、共通のリンクＣＲＣを共有することができる。１つのＬＴＰ内のフリットは、多くの異なるファブリックパケットに由来するものである可能性があり、このことから、リンクプロトコルに、他のファブリックと比較していくつかの興味深い特性が与えられる。効率的なパケットプリエンプション及びインタリーブ機構を使用することにより、このアーキテクチャは、異なるストリームのデータ転送のインタリーブをサポートして、ヘッドオブラインブロッキング効果を実質的に解消し、さらには物理リンク上で物理的に転送されている大きな単一のパケットのブロッキング効果も解消する。ファブリックパケットと、フリットと、ＬＴＰとの間の関係を、図１５及び図１６に示す。これらの図面については、以下でさらに詳細に説明する。
【００４６】
このアーキテクチャは、クレジットに基づくフロー制御を使用して、リンクの受信機側のバッファ資源を管理し、送信機がいつフリットを送信することができるかを制御する。この手法では、ファブリックポートがフリットを送信するためには、ファブリックポートは、受信側ポートで必要とされるバッファスペースに利用可能な十分なフロー制御クレジットを必要とする。１実施形態では、受信機は、リンク上でサポートされる仮想レーン（ＶＬ）に、単一のプールの受信バッファを提供する。バッファプールの割当ては、リンクの送信機側の論理によって管理される。専用バッファは、サポートされる各ＶＬに割り当てられる。さらに、送信機は、スペースの一部分を、ＶＬ間で動的に割り当てられる共有プールとして管理することができる。クレジットに基づくフロー制御とは、リンク上のデータ転送が、強固に管理されている、すなわち無許可のデータ転送が存在しないことを意味し、また、ファブリックがいわゆる「無損失」ファブリックであることも意味する。この場合、無損失とは、単に、通常の動作中に、フリットと、したがってパケットとが、輻輳によってドロップすることがないことを意味する。
【００４７】
フロー制御クレジットなどの制御情報は、リンクファブリック（ＬＦ）コマンドフリット及びリンク転送（ＬＴ）制御フリットに搬送される。ＬＦコマンドフリット及びＬＴ制御フリットは、送信機のフリットストリームに任意の点で挿入することができる。さらに、いくつかのＬＴＰフォーマットの側波帯情報を使用して、さらに少ないオーバヘッドでクレジットを転送することができる。ＬＦコマンドフリット及びＬＴ制御フリットは、リンク送信機によって生成され、リンク受信機によって消費される。
【００４８】
このアーキテクチャは、リンク転送パケット及びファブリックパケットのＣＲＣを含み、データの完全性を保証している。また、このアーキテクチャは、正しく受信されないＬＴＰについて、リンクレベルの再試行を行う。ＬＴＰの再試行により、リンクの有効ビット誤り率が大幅に改善され、物理ＢＥＲのわずかな劣化と引き替えに電力消費を低下させることができるＰＨＹストラテジを使用することが可能になる。また、ＬＴＰの再試行は、許容可能なシステムレベルの誤り率を維持するためにファブリック中の多数のリンクがはるかに良好なリンク当たりのＢＥＲ特性を必要とする大きなファブリックでも有用である。
【００４９】
プリエンプション及びインタリーブ
Ｌ２リンクレイヤは、様々なパケットのフリットを、それらのパケットが異なるＶＬにある限り、それらのフリットが１つのリンクを介して送信されるときにインタリーブすることを可能にする。インタリーブを行う１つの目的は、所与のリンクの使用率を最大限に高めることである。ある送信パケットが何らかの理由でバブルによって中断される場合には、第２のパケットを遊休のままにしておく代わりに、第２のパケットをチャネルにインタリーブすることができる。プリエンプションと呼ばれるインタリーブを行う第２の理由は、優先順位の高いパケットに、転送中の優先順位の低いパケットを中断させて、優先順位の高いパケットの待ち時間を減少させることである。
【００５０】
インタリーブ時には、ファブリックパケットのフリットの全て又は一部分が、リンクを介して伝送されるフリットストリーム内の他のＦＰのフリットとインタリーブされる。送信機は、ポートの出力待ち行列で送信するために利用可能なＦＰの中から、伝送するフリットを選択する。１実施形態では、単一のＶＬ内のＦＰは順に送達されるので、１つの仮想レーン内では、１つのパケットの全てのフリットが、（当該ＶＬ内の）後続のパケットのどのフリットが伝送されるよりも前に伝送される。
【００５１】
異なるＶＬの間では、順序は指定されないので、異なるＶＬのパケットのフリットは、そのフリットストリーム内で（また各ＶＬ内でフリットの順序が維持される限り、所与のＬＴＰ内で）任意にインタリーブすることができる。いくつかの送信機の実施態様では、パケット間のインタリーブの量を制限することを選択することもできる。
【００５２】
プリエンプション時には、より優先レベルの高いファブリックパケットのフリットは、優先レベルの低いＦＰのパケットをプリエンプトする。１実施形態では、各仮想レーンは、それぞれの優先レベルと関連付けられる。送信機は、優先順位の高いＶＬのフリットを、優先順位の低いＶＬのフリットより前に、そのリンクのＬＴＰに挿入するように構成される。送信機は、優先順位の高いフリットを、フリット１つ分よりも大きい境界に挿入することを選択することもできる。さらに、送信機は、同じ優先順位のＶＬのフリットをインタリーブすることを選択することもでき、或いは、送信機は、１つのパケットの全てのフリットを、同じ優先順位の異なるＶＬ中の異なるパケットのフリットを送信する前に、リンクに注入することもできる。リンク上の受信機は、入来するフリットストリームを、待ち行列に挿入し、（スイッチ内の受信機の）次のホップに転送するために、ＶＬごとに分離する。一般に、少なくとも１つの所与のリンクでは、受信機の実施態様は、送信機が生成することができる全ての範囲のインタリーブをサポートする。いくつかの実施形態では、ファブリックにわたって、同じ範囲のインタリーブが実施される。必要に応じて、リンクごとに異なるレベルのインタリーブをサポートすることもできる。
【００５３】
パケットプリエンプションの特徴によれば、第１の優先レベル（例えば高い優先順位）を有するＶＬ上のパケットＢのフリットは、より低い優先順位のＶＬ（すなわち第１の優先レベルより低い優先レベルを有するＶＬ）上のパケットＡのフリットのストリームをプリエンプトすることができる。この場合には、パケットＡのヘッドフリット及びパケットＡの０個以上のボディフリットの後に、パケットＢのヘッドフリットが続く可能性がある。このヘッドフリットは、新たなパケットが始まっていることを示すので、受信機は、ＶＬ識別子を決定するためにＬ２ヘッダ中のＳＣフィールドを探す。パケットＢのヘッドフリットの後には、０個以上のボディフリットが続き、最後に、パケットＢの終端を成すテールフリットが続く。パケットＢの終端後に、パケットＡの伝送が、０個以上のボディフリットと、それに続くテールフリットとで再開される。
【００５４】
パケットプリエンプションは、連続的に優先順位が高くなるパケット（連続的に優先順位が高くなるＶＬのパケット）によってパケットがプリエンプトされるときに、ネスト化することができる。１実施形態では、これは、リストの先頭にアクティブなパケットを含む連結リストとしてモデル化される。現在のパケットがプリエンプトされるときには、新たなパケットが、リストの先頭に追加される。プリエンプトを行っているパケットが終了すると、そのパケットはリストから除去され、次に再開することが予想されるパケットが、リストの新たな先頭になる。一度にリストに保持することができるパケットの最大数は、サポートされるＶＬの数と等しい。
【００５５】
上記の説明では、優先レベルを使用してプリエンプションを説明したが、プリエンプションは優先順位の高いパケットしか使用してはならないという要件があるわけではない。伝送に利用可能な現在のパケットのフリットがない（その結果として「バブル」を生じる）が、優先順位の低いパケットに利用できるヘッドフリットがある場合もある。この優先順位の低いパケットのヘッドフリット及び連続したボディフリットは、送信することができる。この新たなヘッドフリットによって、このパケットがリストの先頭に追加されることになり、受信機は、この新たなパケットを正確にトラッキングすることになる。
【００５６】
パケットは、第２のパケットのヘッドフリットがその第１のパケットのテールフリットより前に送信されるときには、第２のパケットとインタリーブされていると考えられる。最も単純な場合のインタリーブでは、割り込むヘッドフリットに続く全てのボディフリットは、第２のパケットのテールフリットまで第２のパケットに属するものであり、その後に、第１のパケットの残りのパケットフリットが再開される。この単純な場合を、図１３に図示する。
【００５７】
このフリットのグループは、フリットストリーム中のフリットの順序（上から下）に対応する。このグループ中の第１のフリットは、ＶＬ０と標識されている仮想レーン０を介して転送されているファブリックパケットのヘッドフリットである。ＶＬ０のヘッドフリットは、ＦＰがフリット４つ分（１つのヘッドフリット、２つのボディフリット、及び１つのテールフリット）の長さであることを認識している。第２のフリットは、ＦＰのＶＬ０の第１のボディフリットである。次のフリットは、ＶＬ１ヘッドフリットと標識されており、これは、ＶＬ１と標識されている仮想レーン１を介して送信されるＦＰのヘッドフリットである。ＶＬ１ヘッドフリットも、このＦＰがフリット４つ分の長さであることを認識している。１つの手法では、新たなＶＬのＦＰのフリットが現在のＶＬのフリットとインタリーブされるときには、新たなＶＬが、リンクを介してフリットを送信するためのアクティブな仮想レーンになる。これは、フリットストリームにＶＬ１のヘッドフリットを追加することで表される。その結果として、ＦＰのＶＬ１は、ＦＰのＶＬ０とインタリーブし、これは、最初にＶＬ１のヘッドフリットを追加し、２つのＶＬ１のボディフリットを追加し、ＶＬ１のテールフリットを追加することで表される。テールフリットは、ＦＰのＶＬ１のインタリーブが終了するＦＰのＶＬ１のＦＰのフリットの末端を識別する。次いで、論理は、ＶＬ１のインタリーブの前のＦＰのフリットに戻り、残っているＦＰのＶＬ０のボディフリット及びテールフリットが、リンクを介して送信される。
【００５８】
リンクファブリックサブレイヤが複数のファブリックパケットのフリットのインタリーブをどのようにサポートするかをさらに説明するために、図１４は、プッシュとポップのインタリーブの一例を示す。リンクファブリックサブレイヤにおけるインタリーブでは、ヘッドフリットをインタリーブすることにより、中断されたＶＬがプッシュされ、テールフリットに行き当たったときにスタック中のＶＬがポップされる、プッシュ／ポップ方式を利用する。このスタックがどのように働くかを視覚化するために、書類箱の中に積み重ねられた紙の山と、現在の紙での作業を行うために使用されるデスク領域とを想像されたい。プッシュ／ポップインタリーブの状況では、この紙の山を「スタック」と呼び、デスク領域は、フリットのアクティブな仮想レーンを識別するデータが格納されるアクティブＶＬレジスタに対応する。伝送されているＶＬがインタリーブに応答して切り替えられると、インタリーブされたＶＬが新たなアクティブなＶＬになり、それまでのアクティブなＶＬは、デスクからスタックの最上部に押し出される。このために、「プッシュ」という用語が用いられる。ＦＰのＶＬフリットが終了すると（例えばＶＬのＦＰのテールフリットがＬＴＰの送信ＦＩＦＯに追加されると）、ＶＬはデスク領域から除去され、スタックの最上部のＶＬはスタックからデスク領域に「ポップ」されて、新たなアクティブなＶＬになる。このＶＬのプッシュ及びポップは、ネスト状に継続することができる。ｎ個のＶＬをサポートするリンクファブリックサブレイヤでは、同時に中断することができるパケットの最大数は、ｎ−１である。
【００５９】
図１４の例では、フリットの順序付きリスト１４００は、様々なＶＬに記憶されたファブリックパケットのフリットがフリットの伝送ストリームに追加される順序を表している（又は、任意選択で、受信ポートで受信されたフリットストリーム中のフリットの順序を示している）。以下の説明は、フリットがＬＴＰ（すなわちファブリックに「注入」されるＬＴＰ）にバンドリングされたアウトバウンドストリームに追加される、フリットストリームの生成に関するものである。アクティブなＶＬを識別する指標は、アクティブＶＬレジスタ１４０２中に様々な状態で示してある。最初の状態では、ＶＬ０に対応する指標が、アクティブＶＬレジスタ１４０２中に記憶されており、フリットが、仮想レーンＶＬ０についてバッファリングされる次のファブリックパケット（ＶＬ０  ＦＰと呼ぶ）から追加されることを示している。したがって、ＶＬ０  ＦＰの最初の２つのフリットが、フリット伝送ストリームに追加され、この時点で、ＶＬ１のＶＬ０に対するインタリーブが開始されるインタリーブ事象が検出される。このインタリーブ動作を実施するために、ＶＬ１の指標が、アクティブＶＬレジスタ中のＶＬ０に置き換わり、ＶＬ０をスタックにプッシュする。これにより、アクティブな仮想レーンがＶＬ０に切り替わり、ＶＬ１  ＦＰのヘッドフリット及び第１のボディフリットがフリット伝送ストリームに追加される。次に、第２のインタリーブ事象に応答して、ＶＬ２のＶＬ１に対するインタリーブが開始され、ＶＬ２がアクティブＶＬレジスタ１４０２にロードされ、ＶＬ１がスタックにプッシュされる。これにより、ＦＰ  ＶＬ２の３つのフリットが全て、フリット伝送ストリームに追加される。ＦＰ  ＶＬ２のテールフリットが追加されて、ＶＬ１に対するＶＬ２のインタリーブは終了し、これにより、ＶＬ１がスタックからアクティブＶＬレジスタ１４０２にポップされる。ＶＬ１の別のボディフリットが追加され、その後に、ＶＬ７のＶＬ１に対するインタリーブが開始される。このインタリーブは、ＶＬ７の指標をアクティブＶＬレジスタ１４０２に追加し、ＶＬ１を再びスタックにプッシュすることによって行われる。ＶＬ７  ＦＰの全体に対応する３つのフリットがフリット伝送ストリームに追加され、ＶＬ１に対するＶＬ７のインタリーブが終了し、ＶＬ１が再びスタックからアクティブＶＬレジスタ１４０２にポップされる。ＶＬ１  ＦＰのテールフリットが追加されて、ＶＬ１のインタリーブが終了し、ＶＬ０がスタックからアクティブＶＬレジスタ１４０２にポップされる。これにより、ＶＬ０がアクティブなＶＬに復帰し、ＶＬ０  ＦＰの最後の２つのパケットがＬＴＰ伝送ＦＩＦＯに追加される。
【００６０】
中断されている暗示的なＶＬに復帰するためにポップに依拠する代わりに、リンクファブリックサブレイヤは、デバイスが「ＶＬマーカ」と呼ばれる特殊ＬＦコマンドフリットを利用して、どのＶＬがリストの先頭に移動するかを明示的に指定することを可能にする。ＶＬマーカを使用すると、この余分なマーカのフリットによって効率は低下するが、インタリーブの柔軟性は高くなる。図１５は、この概念を示している。
【００６１】
ＶＬマーカは、実際には、ＶＬをデフォルトのスタック順序付けから引き出すこと、又はスタック中に存在しない新たなＶＬをスタックの最上部に移動させることを可能にする。スタック中に残っているＶＬは、その後も引き続きプッシュ／ポップ規則に従う。これら２つの異なる機構の使用は、混合することができ、排他的なものではない。特定のＶＬをスタックから引き出した後、そのＶＬが別のＶＬによってインタリーブされる場合には、そのＶＬは、再びスタックにプッシュされる。
【００６２】
図１５に戻ると、動作のシーケンスは、図１４のプッシュ／ポップの例と同様に開始され、最初のアクティブな仮想レーンはＶＬ０であり、ＶＬ０  ＦＰの最初の２つのフリットが、フリット伝送ストリーム１５００に追加される。上記と同様に、次のＶＬ１が、２つのフリットについてＶＬ０にインタリーブし、次いで、ＶＬ２がＶＬ１にインタリーブする。ただし、ＶＬ２のＦＰのテールフリットに到達する前に、ＶＬマーカ１５０２がフリット伝送ストリームに挿入され、ＶＬ０が新たなアクティブなＶＬになることを示す。これにより、ＶＬ０がスタックから引き出され、アクティブＶＬレジスタ１４０２にロードされ、ＶＬ２がスタックの最上部にプッシュされる。ＶＬ０の残りの２つのフリットが、フリット伝送ストリーム１５００に追加され、ＶＬ０が終了し、その結果、ＶＬ２がスタックからアクティブＶＬレジスタ１４０２にポップされる。これにより、ＶＬ２のテールフリットが追加され、ＶＬ２が終了し、ＶＬ１がスタックからアクティブＶＬレジスタ１４０２にポップされる。別のＶＬ１のボディフリットが追加され、その後に、ＶＬ７のＶＬ１に対するインタリーブが開始され、ＶＬ７がアクティブＶＬレジスタ１４０２にロードされ、ＶＬ１がアクティブＶＬレジスタ１４０２からスタックにプッシュされる。次に、第２のＶＬマーカ１５０４が、フリット伝送ストリーム１５００に追加されて、アクティブな仮想レーンを再びＶＬ１に切り替える。これにより、ＶＬ７がスタックにプッシュされ、ＶＬ１がアクティブＶＬレジスタ１４０２に引き込まれる。ＶＬ１のＦＰのテールフリットが追加され、これでＶＬ１のインタリーブが終了し、ＶＬ７がスタックからアクティブＶＬレジスタ１４０２にポップされる。その後、ＶＬ７のＦＰの最後の２つのフリットが追加される。
【００６３】
図１４及び図１５に示すインタリーブの例は、例示のために、またプッシュ／ポップインタリーブ方式及びＶＬマーカインタリーブ方式がより容易に理解されるように、誇張してインタリーブを示している。実際のシステムでは、ほとんどのインタリーブは、（Ａ）プリエンプション、及び（Ｂ）パケットストリーム中のバブルという、２種類のインタリーブ事象のうちの一方によって生じる。プリエンプティブインタリーブ、並びにプリエンプティブインタリーブとバブル事象によって生じるインタリーブとの組合せのさらに詳細な例は、それぞれ図１６及び図１７に示してある。
【００６４】
上述のように、プリエンプション時には、高い優先順位を有する仮想レーンのファブリックパケットのコンテンツ（フリット）は、優先順位の低いＶＬのＦＰのフリットのフリット伝送ストリームへの追加をプリエンプトすることができる。ＨＦＩ、ゲートウェイ、又はその他のタイプのファブリックエンドポイントでは、ファブリックパケットを構成するデータは、一般に、ファブリックパケットにカプセル化されるイーサネット（登録商標）フレームなど、何らかの他のタイプのフォーマットで最初にバッファリングされる。また、ファブリックパケットは、ＩＰパケット及びＵＤＰパケットなどのレイヤ３パケットの生成方法と同様に、ネットワーキングスタックの一部として作成されることがある可能性も高い。スイッチでは、受信コンテンツ及び送信コンテンツともに、既にフリットにフォーマット化されており、追加のメタデータを使用して、どのフリットがどのＦＰと関連するかを決定し、どのスイッチポートからフリットが次のホップ又はエンドポイントの宛先に送出されるかを決定する。上記の内容に鑑みて、図１６及び図１７は、ファブリックパケットの全体を示し、ＦＰのコンテンツのフリットフォーマットをＦＰの下に示している。
【００６５】
各ＦＰのフリットコンテンツは、そのＦＰが割り振られた仮想レーンに割り当てられたバッファに一時的に記憶される。様々なバッファ構成実施形態では、別個のバッファをそれぞれのＶＬに割り当てることもできるし、又はいくつかのＶＬがバッファ空間を共有することもできるし、或いは、この２つを組み合わせて、あるＶＬのバッファ割当ての第１の部分はそのＶＬの専用とし、別の部分は共有バッファ空間とすることもできる。受信バッファ（Ｒｂｕｆ）及び送信バッファ（Ｔｂｕｆ）のＶＬ使用の割当てに関するさらなる詳細について、以下で述べる。
【００６６】
仮想レーンの使用の基本的な特徴は、所与の仮想レーン内のコンテンツが順序を維持することである。つまり、所与の仮想レーンで、１つのＦＰは別のＦＰを追い越してはならない。さらに、ＦＰのフリットは、それらが最初に生成された順序を維持する。同時に、異なる仮想レーン内のコンテンツは、他の仮想レーンとの間で順序を維持する必要はない。これにより、優先順位の高いトラフィックが、優先順位の低いトラフィックをプリエンプトすることが可能になる。仮想レーンは、経路指定及びプロトコルのデッドロックを解消し、トラフィッククラス間のヘッドオブラインブロッキングを回避するためにも使用される。
【００６７】
図１６に示すように、仮想レーンＶＬ１、ＶＬ２及びＶＬ３に対して、３つのバッファ１６０２、１６０４及び１６０６がそれぞれある。これらの仮想レーンは、それぞれ優先レベルが割り付けられる。ＶＬ１は優先順位が低く、ＶＬ２は優先順位が中程度で、ＶＬ３は優先順位が高い。アービタ（図示せず）を使用して、どのＶＬバッファから、フリットがＬＴＰ２、３、４、５、６及び７にバンドリングされるフリット伝送ストリーム１６０８に追加するフリットを引き出すかを決定する。図１６は、図示のウィンドウ時間フレームにわたる仮想レーンＶＬ１、ＶＬ２及びＶＬ３のリンクトラフィックの処理を示す「スライディングウィンドウ」図である。１実施形態では、ＶＬバッファは、ＦＩＦＯ（先入れ先出し）バッファとして実装され、各ＦＩＦＯスロットが、１つのフリットを記憶するようなサイズになっている。
【００６８】
上述のように、プリエンプティブインタリーブの１つの特徴では、優先順位の高いＶＬに割り付けられたＦＰのコンテンツは、それより優先順位の低いＶＬに割り付けられたＦＰのコンテンツをプリエンプトすることができる。一般に、複数のＦＰに対応するＦＰのコンテンツがそれぞれのＶＬエグレス（ファブリックに注入される）バッファにバッファリングされる場合には、最高の優先順位のＶＬに割り付けられたＦＰのコンテンツが、フリット伝送ストリームに追加される。ただし、プリエンプションが起きない状況もあり得るので、これは絶対的な規則ではないことに留意されたい。同時に、ＦＰのコンテンツが、所与の１つのＶＬ又は同じ優先順位の複数のＶＬのみで利用可能である場合には、そのＦＰのコンテンツは、他のＶＬ（その時点でバッファリングされたＦＰのコンテンツを有していないＶＬ）の優先レベルに関わらず、フリット伝送ストリームに追加される。この状況は、以下のように図１６に示してある。
【００６９】
時間Ｔ１で、パケット１の少なくとも第１の部分が、ＶＬ１バッファ１６０２にバッファリングされ、伝送の準備ができている。このアーキテクチャのデータ転送のストリーミングの性質上、フリットは、ＶＬバッファで受信する（ＶＬバッファに追加する）こともできるし、ＶＬバッファから（伝送のために）除去することもできる。さらに、ＶＬバッファへのフリットの追加及びＶＬバッファからのフリットの除去は、特にスイッチでは、ある程度非同期になる可能性がある。その結果として、任意の所与の時点で、所与のＶＬバッファは、バッファリングされて伝送の準備ができているコンテンツを有していることもあれば、有していないこともある。図１６の例では、時間Ｔ１では、ＶＬ１バッファ１６０２のみが、伝送の準備ができているフリットを含み、ＶＬ２バッファ１６０４及びＶＬ３バッファ１６０６は、両方とも空である。ＦＰパケットのフリットのフリット伝送ストリームへの追加を開始するためには、少なくとも１つ又は複数のヘッドフリット（個々のＦＰフォーマットによって決まる）が、ＶＬ  ＦＩＦＯバッファの先頭にある必要がある。（以下でさらに詳細に述べるように、１実施形態では、ＶＬバッファは、円形ＦＩＦＯとして実装され、ＦＩＦＯの先頭はＦＩＦＯヘッダポインタによって識別される。）図１６では、ヘッドフリット１６１０が、時間Ｔ１で、ＶＬ１バッファ１６０２の先頭にバッファリングされる。
【００７０】
時間Ｔ１で、第１のグループのフリット１６１２が、フリット伝送ストリーム１６０８のＬＴＰ２に追加され、フリット１６１２の先頭のヘッドフリット１６１０が時間Ｔ２で追加され、Ｔ１とＴ２の時間差が、アービタがアクティブなＶＬがＶＬ１バッファ１６０２に変化することを認識するのに要する時間、及びそのバッファのフリットデータをフリット伝送ストリーム１６０８にコピーするのに要する時間の長さを表す。図１６に示すＴ１とＴ２の間の差は、正しい縮尺ではなく、ＦＰデータがＶＬバッファに到達して伝送の準備ができてから、そのデータが実際のフリット伝送ストリームに追加されるまでに何らかの有限の時間があることを示すためのものである。
【００７１】
時間Ｔ３で、ヘッドフリット１６１４で始まるパケット２の第１の部分が、ＶＬ２バッファ１６０４に受信されている。ＶＬ２はＶＬ１より高い優先順位を有するので、プリエンプション事象が、アービタ（又はその他の論理、図示せず）によって検出される。実施態様によっては、プリエンプション事象は、パケット２の１つ又は複数のヘッドフリットがＶＬ２ＦＩＦＯバッファ１６０４の先頭に到達した直後に検出されることもあるし、余分のインタリーブは他のポートにおいてバブルを引き起こし、さらなるインタリーブをもたらすことになる可能性があることから、何らかのレベルのインタリーブの発生を低減するために、いくらかの遅延があることもある。例えば、フリットがフリット伝送ストリームに追加されている現在のパケットに残っているフリットがわずかであり、プリエンプトを行うことになるパケットが大きい場合には、論理は、現在のパケットが完了するまで待機して、現在のパケットのプリエンプションが起きないようにすることもできる。プリエンプション事象に応答して、アクティブなＶＬは、プッシュ／ポップインタリーブ方式を用いて、ＶＬ１からＶＬ２に切り替えられる。必要に応じて、ＶＬマーカインタリーブ方式を使用することもできる。アクティブなＶＬがＶＬ１からＶＬ２に切り替えられるのに応答して、ＶＬ２の指標がアクティブＶＬレジスタにロードされ、ＶＬ１がスタックにプッシュされる。時間Ｔ４に示すように、第１のグループのフリット１６１６が、ＶＬ２ＦＩＦＯバッファ１６０４から引き出され、フリット伝送ストリーム１６０８に追加される。これにより、パケット２を優先してパケット１の伝送がプリエンプションされ、パケット１及びパケット２のフリットがインタリーブされる。
【００７２】
時間Ｔ５で、ヘッドフリット１６１８で始まるパケット３の第１の部分が、ＶＬ３バッファ１６０６に受信されている。ＶＬ３はＶＬ２より高い優先順位を有するので、第２のプリエンプション事象が、アービタ（又はその他の論理、図示せず）によって検出される。これにより、パケット３の伝送を優先してパケット２の伝送がプリエンプトされる。これは、ＶＬ３の指標をアクティブＶＬレジスタにロードし、ＶＬ２をスタックにプッシュすることで行われる。図示のように、時間Ｔ６から、パケット３のフリット１６２０の全体が、フリット伝送ストリーム１６０８に追加され、これにより、パケット３のフリットがパケット２のフリットとインタリーブされる。
【００７３】
フリット伝送ストリーム１６０８へのテールフリット１６２２の追加に関連して、アービタ（又はその他の論理）は、パケット３のフリットの追加が完了していることを検出する。したがって、ＶＬ３は、アクティブＶＬレジスタから除去され、ＶＬ２が、スタックからアクティブＶＬレジスタにポップされ、ＶＬ２がアクティブなＶＬに復帰する。これにより、パケット２の残りのフリット１６２４がフリット伝送ストリーム１６０８に追加されることになる。この追加は、時間Ｔ７から開始され、時間Ｔ８に終了し、この時点で、テールフリット１６２６が追加され、したがってパケット２が完了したことが検出される。これにより、ＶＬ１は、スタックからアクティブＶＬレジスタにポップされ、ＶＬ１が、ＶＬ２に置き換わってアクティブなＶＬになる。次いで、パケット１の残りのフリット１６２８が、フリット伝送ストリーム１６０８に追加され、時間Ｔ９にテールフリット１６３０で終了する。次いで、次のファブリックパケットのヘッドフリットが、ＬＴＰ７の最後のフリットとして追加される（分かりやすくするために、次のファブリックパケットは、図示していない）。
【００７４】
図１７は、バブルインタリーブ事象と、その後に続くプリエンプションインタリーブ事象とを示す図である。ファブリックパケットのフリットが複数のホップを含む経路指定経路を横切るときには、これらのフリットの一部分が、１つ又は複数のスイッチでプリエンプトされる可能性がある。これにより、所与のＦＰのフリットストリームが混乱することになる。このような混乱したフリットストリームが受信ポートで受信されると、プリエンプションより前に伝送されたフリットの部分と、プリエンプションの後に伝送されたフリットの部分との間にギャップが生じる。これにより、「バブル」が生じる。このバブルの例の他にも、バブルは、その他の様々な理由で生じる可能性がある。このようなバブルの検出に応答して、バブルが生じたＦＰと同じ、又はそれより低い優先レベルを有するＦＰのフリットに対してインタリーブを実施することができる。
【００７５】
図１６の例の場合と同様に、時間Ｔ１で、ヘッドフリット１７００を含むパケット１の少なくとも第１の部分が、ＶＬ１ＦＩＦＯバッファ１６０２で受信され、時間Ｔ２から、第１の部分のフリット１７０２が、フリット伝送ストリーム１７０４のＬＴＰ２に追加される。時間Ｔ３で、ヘッドフリット１７０６で始まるパケット２のフリットの第１の部分が、ＶＬ２ＦＩＦＯバッファ１６０４で受信される。ＶＬ１及びＶＬ２は両方とも低い優先順位が割り付けられているので、パケット１及びパケット２はそれぞれ、同じ低い優先レベルが割り付けられる。ＦＰ及び／又はそのフリットは、それらが同じ仮想レーンに割り付けられているときには互いに追い越すことができないが、ＦＰ及び／又はそのフリットは、それらが異なる仮想レーンに割り付けられているときには、互いに追い越すことができる。この状況は、異なる仮想レーンが同じ優先レベルを有するときに生じる可能性もある。一般に、２つ（又はそれ以上）の仮想レーンのＦＰが同じ優先レベルを共有するときには、それらのＦＰは、例えば第１のＦＰの全てのフリットが追加される、第２のＦＰの全てのフリットが追加されるなど、その全体が（そのフリットを介して）フリット伝送ストリームに追加される。同じ優先レベルを共有する複数のＶＬから次にどのＦＰを送出するかの選択は、一般にこれらのＶＬのＦＰの伝送を平等に（又はかなり平等に）扱うように設計されるアービタの選択論理によって決まる。例えば、いくつかの実施形態では、ラウンドロビン方式を実施することができる。このようなラウンドロビン方式は、ＦＰの長さを考慮して、複数のＶＬの間のバッファ使用レベルが、何らかのレベルの目標とされるようにすることもある。例えば、２つのＶＬの間でラウンドロビンのみの手法を用いると、それらのＶＬのＦＰの送信を交互に行うことになるが、使用レベル手法は、それらのＶＬのうちの一方の第１のＦＰが他方のＶＬの第２及び第３のＦＰよりかなり大きい場合には、第１のＦＰを伝送した後で、第２及び第３のＦＰを伝送することができる。
【００７６】
図１７に示す例では、通常は、パケット１の全てのフリットが送信され、その後に、パケット２の全てのフリットが送信される（プリエンプションインタリーブ事象がなく、ＶＬ１及びＶＬ２のみをアービトレーションのために考慮するものと仮定する）。しかし、図示のように、時間Ｔ４から、パケット１のフリットの転送にバブルが生じる。アービタ論理は、このバブルの存在を、ＶＬ２ＦＩＦＯバッファ１６０４中のパケット２のフリットの可用性と組み合わせて考慮する。これに応答して、バブルインタリーブ事象が検出され、これにより、時間Ｔ５からは、パケット２のフリット１７０８がパケット１のフリットでインタリーブされることになる。プリエンプティブインタリーブと同様に、インタリーブは、ＶＬ２をアクティブＶＬレジスタにロードし、ＶＬ１をスタックにプッシュすることから開始される。
【００７７】
パケット２のフリットがフリット伝送ストリーム１７０４に追加されている間に、時間Ｔ６で、パケット１のフリットの第２の（及び残りの）部分の、ＶＬ１ＦＩＦＯバッファ１６０２における受信及びバッファリングが開始される。これらのフリットは、直ちに伝送に利用することができるが、時間Ｔ６でそれらを受信しても、インタリーブ事象は発生しない（或いは、その他の形でパケット２のフリットのインタリーブを終了させる）。逆に、パケット２のフリットが、ＶＬ３ＦＩＦＯバッファ１６０６内のヘッドフリット１７１０を含むパケット３のフリットが利用可能であることが検出されたのに応答して時間Ｔ７でプリエンプティブインタリーブ事象が検出されるまで、パケット２のフリットが、フリット伝送ストリーム１７０４に追加され続ける。図１６の例の場合と同様に、ＶＬ３は、ＶＬ１又はＶＬ２の優先レベルより高い優先レベルを有する。その結果として、優先順位の高いパケット３のフリットが利用可能になったことで、パケット３のフリット１７１２のパケット２のフリットに対するプリエンプティブインタリーブが開始される。このプリエンプティブインタリーブは、時間Ｔ８から開始され、時間Ｔ９にテールフリット１７１５が追加されて終了する。パケット３のインタリーブの終了時に、ＶＬ２は、スタックからポップされ、アクティブＶＬレジスタにロードされ、これにより、ＶＬ２はアクティブな仮想レーンに復帰する。これにより、パケット２の残りのフリット１７１６がフリット伝送ストリーム１７０４に追加されることになる。
【００７８】
時間Ｔ１０にテールフリット１７１８によってフリット伝送ストリーム１７０４に識別されるパケット２の終了時に、ＶＬ１は、スタックからポップされ、アクティブＶＬレジスタにロードされ、ＶＬ１は、アクティブＶＬに復帰する。これにより、パケット１の残りの部分に対応するフリット１７２０がフリット伝送ストリーム１７０４に追加される。ここで、パケット１のフリットの追加は、時間Ｔ１１でテールフリット１７２２が追加されたときに終了する。
【００７９】
リンク信頼性
上述のように、このアーキテクチャのファブリックは、「無損失（ロスレス：lossless）」である。つまり、パケットは、受信時に破棄されたり、或いは伝送中に「喪失」したりすることがない。これは、クレジットに基づくフロー制御を使用することと、再現バッファを使用することとを主に含む複数の機構を組み合わせることによって実施される。クレジットに基づく手法では、送信側ユニット（例えばＨＦＩ、スイッチ、又はゲートウェイ）は、その送信側ユニットがフリットを伝送するためのクレジットを有していない限り、フリットを受信側ユニット（例えば別のＨＦＩ又はスイッチ）に送信しない。ここで、クレジットは、ＶＬごとのものであり、受信機が、フリットに使用されるＶＬに対して十分なバッファ空間を有していることを示すために使用される。
【００８０】
各ＬＴＰは、標準検出ＬＴＰが使用されているか、強化検出ＬＴＰが使用されているかに応じて、データの完全性を検証するために使用される１つ又は複数のＣＲＣを含む。これらの１つ又は複数のＣＲＣは、ＬＴＰのデータコンテンツにわたって計算され、その結果得られる１つ又は複数のＣＲＣ値は、図５〜図８に示し、上記で説明したように、ＬＴＰの末端に、最後のフリット（フリット１５）の後に添付される。受信時に、これらの１つ又は複数のＣＲＣは再計算され、受信したＬＴＰ中の１つ又は複数のＣＲＣと受信したデータ中の１つ又は複数のＣＲＣとを比較して、データエラーがあるかどうか判定する。伝送されたＣＲＣと受信データについて計算したＣＲＣが一致しない場合には、データエラーが検出される。ＣＲＣの不一致の検出に応答して、ＬＴＰは、再現バッファを使用して再伝送される。
【００８１】
「信頼できる」ＬＴＰは、再伝送要求がないことで、それがピアによって上手く受信されていることが分かることを保証するのに十分に長い期間、再現バッファに保持される。この手法では、受信機は、パケットが上手く受信されていることを確認するためのＡＣＫを送信しない。その代わりに、ラウンドトリップ期間内に再伝送要求がないことで、ＬＴＰがリンクを介して上手く伝送されていることが暗示的に確認される。「信頼できる」ＬＴＰという用語を使用するのは、再現バッファに保持されるＬＴＰを、ヌルＬＴＰなど、再現バッファに保持されない他のＬＴＰと区別するためである。したがって、ヌルＬＴＰは、再伝送されない。
【００８２】
再現バッファ位置ポインタは、送信機（ＮｘｔＴｘＬＴＰ）及び受信機（ＮｘｔＲｘＬＴＰ）で各ＬＴＰごとに維持されるが、ＬＴＰの一部として交換されない。伝送エラーが受信機で（ＣＲＣ不一致を介して）検出されると、受信機は、ＮｘｔＲｘＬＴＰ再現バッファ位置ポインタを含むＲｅｔｒｙＲｅｑＬＴＰを送信機に送信する。送信機がＲｅｔｒｙＲｅｑＬＴＰを受信すると、再現バッファ中のＬＴＰが、ＲｅｔｒｙＲｅｑＬＴＰ（ピアＮｘｔＲｘＬＴＰ）で始まり、最後に書き込まれた再現バッファ位置で終わる、元の順序で再伝送される。１実施形態では、ＬＴＰデータを（ＮｘｔＷｒＬＴＰ）に書き込むための次の再現バッファスロットが使用され、したがって、最後に書き込まれた再現バッファ位置は、ＮｘｔＷｒＬＴＰ−１となる。
【００８３】
ＣＲＣ不一致によって示されるリンクエラーの検出と関連して、第２の機構を実施して、どのレーンがエラントであるか決定する。この機構は、受信機でのみ計算されるレーンごとのＣＲＣを利用し、伝送データ中のレーンごとのＣＲＣとの比較は使用しない（存在しないため）。代わりにレーンごとのＣＲＣは、以下で述べるように、ＣＲＣ不一致のあるＬＴＰについて計算されたレーンごとのＣＲＣを、そのＬＴＰをレーンごと又は転送グループごとに再現バッファを介して再伝送するときに、同じＬＴＰについて再計算した対応するレーンごとのＣＲＣと比較するために使用される。
【００８４】
再現バッファを使用するとともにレーンごとのＣＲＣを使用してエラントなレーンを検出する一例を、図１８ａ及び図１８ｂに示す。この例では、ＬＴＰ伝送ストリーム１６０６のＬＴＰ２、３、４、５、６及び７を含むＬＴＰ伝送ストリームは、デバイスＡのリンクインタフェースＡからリンクの反対側端部のピアデバイスＢのリンクインタフェースＢに伝送されている。さらに詳細には、このＬＴＰ伝送ストリームは、上述の図１７に示すものと同様の４レーンリンク相互接続を用いて、リンクインタフェースＡの送信ポート１８００からリンクインタフェースＢの受信ポートに伝送される。このアーキテクチャのリンクでは、ＬＴＰコンテンツは、複数のレーンを順に介して並列に送信される。上述のように、レーンの数は、個々のリンク構成によって変化する可能性があり、さらに、レーン数を減少させたリンク上の転送もサポートされる。例えば（限定的なものではない）、単位間隔（ＵＩ）と呼ばれる期間の間に、各レーンを介して１ビットが伝送される。１実施形態では、ＬＴＰデータの転送は、転送単位（ＸＦＲ）と呼ばれるデータ単位にセグメント化される。１実施形態では、各ＸＦＲは、３２ビットの量である。１実施形態では、ＸＦＲの全てのビットは、同じレーンを用いて伝送される。いくつかの実施形態では、いくつかのＸＦＲを、複数のレーンを介して伝送することができる。
【００８５】
図１９は、１０５６ビットの長さを有する標準検出ＬＴＰのＸＦＲのマッピングを示す図である。各ＸＦＲは、３２ビットの長さであり、単一のレーンを介して転送される。したがって、各ＬＴＰごとに３３個のＸＦＲがある。図２０は、１実施形態による、４レーンリンクのレーンごとのＸＦＲのマッピングを示す図である。名目上は、例示のために、また明瞭にするために、各フリットは６４ビットである。ただし、図３に示すように、各フリットは、その全体（ボディフリットの場合）又はその一部（ヘッドフリット及びテールフリット並びに制御フリットの場合）がフリットタイプを識別するために使用される、余分の６５番目のビットを有する。伝送中には、この６５番目のビットは、一列に伝送される。つまり、複数のレーンを介して並列に伝送された複数の直列転送ビットストリームの非直列化及び再アセンブリ時に、６５番目のビットは、１０５６ビットの標準検出ＬＴＰの中で、６５ビット位置ごとに存在する。
【００８６】
４レーンリンクの１実施形態では、２つのフリットのデータビットは、３２ＵＩにわたって並列にリンクを介して転送され、４つのＸＦＲを構成する１２８ビットが（論理的には）一緒に転送されるようになっている。しかし、上述のように、６５番目ごとの位置は、必ずフリットタイプビットに占められる。その結果として、ＸＦＲは、フリットに対して正確に２：１でマッピングするわけではない。そうではなく、余分の６５番目のビットが一列に存在することにより、図２１に示すようにラップ式転送が得られる。
【００８７】
さらに詳細には、１実施形態では、余分な２ビットは、各１２８ＵＩごとにラップされ、８グループの４レーンＸＦＲが終了した後で、１６ビットのアグリゲーションが得られる。これらの８つのグループは、最初の３２個のＸＦＲを構成し、３３番目のＸＦＲが、フリット１５の最後の１６ビット（及びその６５番目のビット）を含み、その後に、１６ビットＣＲＣ（又は任意選択で、ＣＲＣ−１４ＬＴＰの場合には、１４ビットＣＲＣ及び２つの制御チャネルビット）が続く。例示を目的として、また理解を容易にするために、本明細書では、フリットを、６４ビットの単位で転送されるものとして示すことがあるが、１実施形態では、フリットは実際には６５ビットの単位で転送されることは理解されるであろう。
【００８８】
図２０の４レーンＸＦＲマッピングに戻ると、１０５６ビットの標準検出ＬＴＰ１つ当たり３３個のＸＦＲを使用することにより、各ＬＴＰで１つのＸＦＲがラップされることになる。これにより、レーン０、レーン１、レーン２、レーン３、レーン０に戻って、レーン１…といったＬＴＰ開始レーンシーケンスに従って、後続の各ＬＴＰの開始点が次のレーンにずれる。これを、本明細書では、４レーン標準検出ＬＴＰ「シーケンス」、又は簡単にＬＴＰシーケンス（本明細書で図示して説明する４つのレーンを介した標準検出ＬＴＰ転送に適用される）と呼ぶ。便宜上、このＬＴＰシーケンスの状態は、第１、第２、第３、及び第４として示すが、１実施形態では、２ビットを使用して０、１、２、３として追跡される。
【００８９】
図１８ａに示すように、ＬＴＰ伝送ストリーム１６０４のフリットの直列化及びマッピングは、伝送リンク制御ブロック１８０４によって実行される（又は、その他の場合には、この動作の一部分は、図示しない別のブロックによって実行される）。各信頼できるＬＴＰのデータコンテンツは、伝送リンク制御ブロック１８０４によって処理される前に、再現バッファ１８０６中のＬＴＰスロットのうちの１つにコピーされる。このスロットは、ＮｘｔＷｘＬＴＰポインタ１８０７によって識別される。一般に、再現バッファは、可変のサイズを有することもあるし、所定のサイズを有することもある。１実施形態では、再現バッファは、複数の所定のサイズのうちの１つに合わせて選択的に構成することができる。
【００９０】
図示のように、１実施形態では、再現バッファは、次の伝送ＬＴＰ（ＮｘｔＴｘＬＴＰ）ポインタ１８０８が最後のＦＩＦＯスロットから最初のＦＩＦＯスロットにラップする（この例ではスロット７からスロット０にラップする）値を有する円形ＦＩＦＯとして実装される。円形ＦＩＦＯを使用することにより、以前のＬＴＰデータ（以前に伝送されたＬＴＰに対応する）は、新たな（次に伝送される）ＬＴＰデータで上書きされることになる。しかし、以下で詳述するように、ＬＴＰデータが上手く伝送されていることを示す暗示的な確認応答が検出されるまで、ＬＴＰデータが上書きされないことを保証するための措置が講じられている。この方式は、明示的なＡＣＫを使用する必要がなく、したがってＡＣＫの使用に伴うオーバヘッドを減少させる、リンクを介したデータの信頼性の高い伝送を容易にする。また、これにより、リンクレイヤより上のプロトコル（ＴＣＰなど）で使用されるＡＣＫに基づく信頼できる伝送方式をサポートするために必要となる送信ポートにおけるバッファリングも減少する。図２２ａ〜図２２ｅの流れ図２２００ａ〜２２００ｅ、並びに図２３ａ及び図２３ｂの送信機及び受信機の状態機械図を参照すると、エラントなリンクレーンの検出を含むリンクエラーの取扱いは、１実施形態では、以下の方法で実施される。リンク初期化プロセス中に、シンクのインタフェースのピアな送信ポートと受信ポートの間で様々な情報を交換して、双方向通信リンクを確立する。このプロセス中に、再現バッファのＮｘｔＴｘＬＴＰポインタ１８０８と、受信側の対応する次の受信ＬＴＰ（ＮｘｔＲｘＬＴＰ）ポインタ１８１０とを、０に初期化する。リンク初期化が成功したら、開始ブロック２２０２、並びに図２３ａ及び図２３ｂの送信機及び受信機のＬｉｎｋＴｒａｎｓｆｅｒＡｃｔｉｖｅ．ｎｏｒｍａｌ状態に示すようにリンク転送モードを「通常」に設定し、ＬＴＰは、リンクを介して転送する準備ができる。分かりやすくするために、以下では、１方向に転送されるデータについて述べるが、逆方向にも（別個のレーンのセットを用いて）同様の動作を実行して、リンクを介した双方向通信をサポートする。
【００９１】
ＬＴＰ伝送ストリーム１６０４中のＬＴＰは順番に伝送されるので、ＬＴＰのデータは、順番に再現バッファ１８０６にコピーされ、ＮｘｔＴｘＬＴＰポインタ１８０８は、ＬＴＰごとにスロットを１つ進める（又は最後のスロット（ＭｙＬＴＰｍａｘ）に到達したら０にラップする）。図１８ａの図示の例の状態では、ＬＴＰ２〜６は、以前に送信ポート１８００から伝送されており、ＬＴＰ２及び３は、以前に受信ポート１８０２で受信されており、Ｒｘリンク制御ブロック１８０５で処理され、ＬＴＰ  ＣＲＣの一致に基づいて良好なＬＴＰであると判定されている。ＬＴＰ４は、受信される直前であり、ＬＴＰ５及び６は、飛行中である（これらのＬＴＰのデータは既に送信ポート１８００から送出されているが、まだ受信ポート１８０２には受信されていない）。
【００９２】
流れ図２２００ａに戻ると、主流れ図ループは、ＬＴＰが受信ポートで受信されるブロック２２０４から開始される。図１８ａの例では、この動作は、ＬＴＰ４が受信ポート１８０２で受信されることで表されている。ブロック２２０６に示すように、各レーンごとに、ＣＲＣは、適用可能なＬＴＰシーケンス状態である間に、そのレーンを介して受信したデータに基づいて計算され、このＣＲＣが、ＣＲＣレーンレジスタＣＲＣ−Ｌ０、ＣＲＣ−Ｌ１、ＣＲＣ−Ｌ２及びＣＲＣ−Ｌ３で示す、レーンごとのＣＲＣレジスタに書き込まれる。１実施形態では、これらのレジスタ中のデータは、現在のＬＴＰのＣＲＣ計算結果で上書きされ、ＣＲＣレーンレジスタが最も最近に処理されたＬＴＰのデータしか記憶しないようになっている。１実施形態では、４レーンリンクのレーンごとのＣＲＣは、各レーンのビットが受信されるときに動的に計算される、１２ビットＣＲＣである。
【００９３】
ブロック２２０８で、受信したＬＴＰデータのＣＲＣ（Ｒｘ  ＣＲＣ）を計算し、伝送されたＬＴＰのＴｘ  ＣＲＣと比較する。Ｔｘ  ＣＲＣは、本明細書では様々なＬＴＰフォーマットで示す、受信機に伝送される、ＬＴＰの末端に添付されたＬＴＰデータを用いて送信ポート１８００で計算される。受信機は、受信したＬＴＰデータからＴＸ  ＣＲＣを抽出して、このＴｘ  ＣＲＣを受信したＬＴＰデータについて計算したＲｘ  ＣＲＣと比較する。判定ブロック２２１０で、受信したＴｘ  ＣＲＣと計算したＲｘ  ＣＲＣとが一致するかどうかを判定する。両者が一致する場合には、ブロック２２１２に示すように、ＬＴＰは良好であると見なされ、ＬＴＰデータの通常の処理が実行され、論理はブロック２２０４に戻って、次の受信ＬＴＰを処理する。
【００９４】
図１８ａに示す例では、ＬＴＰ４についてＴｘ  ＣＲＣとＲｘ  ＣＲＣとが一致しない（ＣＲＣ不一致）場合には、これはＬＴＰデータエラーを示している。リンクデータエラーは、様々なリンク状態から生じる可能性があり、この時点では、エラーを引き起こしている具体的なリンク状態は分かっていない。分かっているのは、受信したＬＴＰデータが、伝送されたデータと異なるものであり、したがって、受信ＬＴＰがエラントなデータであり、それ以上処理しないということである。不一致のＬＴＰ  ＣＲＣは、判定ブロック２２１０の結果「ＮＯ」に対応し、これにより、論理は、ブロック２２１４に進み、このブロックで、ＬＴＰは不良であるものとされる。「不良」は、受信機の状態図２３５０ではＲｃｖＢａｄＬＴＰで表される。不良ＬＴＰの検出に応答して、ブロック２２１６（図２２ａ）、２２１８及び２２２０（図２２ｂ）のそれぞれの動作で表すように、複数の動作が実質的に並列に開始され、実行される。
【００９５】
ブロック２２１６に示すように、不良ＬＴＰについて計算されたレーンごとのＣＲＣの値は、レーンごと、又はＸＦＲグループごとに記憶される。ＬＴＰ１つ当たりのＸＦＲの数がレーンの数で割り切れる場合には、レーンごとのＣＲＣの値は、レーンごとに記憶され、そうでない場合には、レーンごとのＣＲＣの値は、ＸＦＲグループごとに記憶される。例えば、３つのアクティブなレーン及び３３個のＸＦＲを有するリンクでは、３３／３＝１１であるので、レーンごとのＣＲＣの値が記憶される。逆に、４つ又は２つのレーンの場合には、レーンごとのＣＲＣの値は、ＸＦＲグループごとに記憶される（３３／４＝７．５、及び３３／２＝１６．５）。ＸＦＲグループごとのＣＲＣが記憶される場合には、受信ＬＴＰシーケンス状態が、レジスタ１８１４に記憶される。ＸＦＲグループごとのＣＲＣの一例を、図２４に示す。図示のように、レーンごとのＣＲＣが計算されるＸＦＲの数は、４つのレーンにわたって等しくなく、これらのレーンのうちの１つは、標準検出ＬＴＰ１つ当たり９個の３２ビットＸＦＲ（したがって２８８ビット）を受信するが、他の３つのレーンは、８個の３２ビットＸＦＲ（したがって２５６ビット）を受信する。さらに、９個の３２ビットＸＦＲを受信するレーンは、ＬＴＰシーケンス状態によって決まる。以下でさらに詳細に述べるように、記憶されたレーンごとのＣＲＣを使用して、ＣＲＣ不一致を有するＬＴＰのＸＦＲグループごとのＣＲＣと、その後に再伝送された同じＬＴＰとを比較することにより、どの１つ又は複数のレーンがエラーを生じたかを検出する。元のＬＴＰ伝送に使用されたＬＴＰシーケンスは、再伝送されたＬＴＰに使用されたＬＴＰシーケンスと異なる可能性があるので、ＸＦＲグループごとのＣＲＣを利用する。ＸＦＲグループごとのＣＲＣの場合は、同じＸＦＲについて計算されたＣＲＣを比較することになるが、レーンごとのＣＲＣの方式を使用した場合には、４つのレーン又は２つのリンクを有するリンクを運用するときに、ＣＲＣの計算が同じＸＦＲについてのものである場合も、そうでない場合もある（レーンが４つの場合は、同じになる確率は２５％、レーンが２つの場合は、同じになる確率は５０％）。
【００９６】
図２４に示すように、ＸＦＲグループごとのＣＲＣは、ＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２及びＣＲＣ−Ｇ３と標識される。これらのＣＲＣを計算する転送は、レーン及びＬＴＰシーケンス状態の両方によって決まる。例えば、第１のＬＴＰシーケンス状態では、ＣＲＣ−Ｇ０は、レーン０で受信した９個のＸＦＲ０、４、８、１２、１６、２０、２４、２８及び３２から計算されるが、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２及びＣＲＣ−Ｇ３について計算した値は、それぞれレーン１、２及び３について表される８個のＸＦＲによって決まる。第２のＬＴＰシーケンス状態では、ＣＲＣ−Ｇ０は、レーン１の９個のＸＦＲから計算されるが、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２及びＣＲＣ−Ｇ３について計算した値は、それぞれレーン２、３及び１について表される８個のＸＦＲによって決まる。図示のように、第３及び第４のＬＴＰシーケンス状態の両方についても、同様の手法を使用する。
【００９７】
図１８ａに示す時間フレーム中には、ＬＴＰシーケンス状態は１であるので、ＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２及びＣＲＣ−Ｇ３は、それぞれレーン０、１、２及び３のＬＴＰ４について受信したデータから計算される。ＬＴＰのＸＦＲグループごとのＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２及びＣＲＣ−Ｇ３の値についての例示的な計算は、図１８ａ及び図２５に示す通りであり、それぞれ４２８、５５６、２０８及び８０４である。これらのＸＦＲグループごとのＣＲＣの値は、レジスタＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２及びＣＲＣ−Ｇ３に記憶される。
【００９８】
引き続き図２２ｂの流れ図２２００ｂで、ブロック２２１８において、再伝送要求（ＲｅｔｒｙＲｅｑＬＴＰ１８１２）が受信機から送信機に戻され、ＮｘｔＲｘＬＴＰポインタ１８１０の現在の値を介して不良ＬＴＰを識別する。１実施形態では、ＲｅｔｒｙＲｅｑＬＴＰの逐次対が送信されるが、別の実施形態では、単一のＲｅｔｒＲｅｑＬＴＰが送信される。この例では、ＮｘｔＲｘＬＴＰポインタの値は、不良ＬＴＰであるＬＴＰ４のデータを記憶する再現バッファのスロット４を指す。ＲｅｔｒｙＲｅｑＬＴＰを受信したのに応答して開始される再現モードのときの送信機側動作の詳細は、図２２ｃの流れ図２２００ｃに示す。
【００９９】
また、ブロック２２１６の不良ＬＴＰの検出時に、ブロック２２２０で、ＬＴＰ受信モードは「ＬＴＰトス」に設定され、これにより、不良ＬＴＰを含む受信したＬＴＰがトス（破棄）される。ＬＴＰトスモードは、受信機の状態図２３５０では、ＬＴＡ．ＲｘＴｏｓｓｉｎｇ状態として表す。受信機がＬＴＰトスモードで動作している間に、ＬＴＰを受信し、レーンごとのＣＲＣを計算してレジスタを更新し、ＬＴＰ  ＣＲＣのエラーチェックを実行して、逐次ＬＴＰ  ＣＲＣエラーを検出し、ＬＴＰを破棄する。これらの動作は、ブロック２２２２でＬＴＰを受信することから始まるループ的に実行される。上記と同様に、ブロック２２０６及び２２０８の動作が実行され、その後、判定ブロック２２２４で、受信したＬＴＰがＣＲＣエラー（Ｔｘ  ＣＲＣ及びＲｘ  ＣＲＣの不一致）を有するかどうかを判定する。受信機がＬＴＰトスモードで動作している間に、論理は、逐次ＬＴＰ  ＣＲＣエラーの発生をチェックするように構成される。例えば、ＬＴＰトスモードに入った後で最初に受信したＬＴＰがエラーを有する場合には、逐次エラーが発生している。逐次エラーを検出するための判定は、判定ブロック２２２４の結果がＹＥＳである場合に論理が進む先である判定ブロック２２２６で表される。さらに、ブロック２２２５で、ＬＴＰ  ＣＲＣエラーの総カウントが増分される。（また、通常モードであってもトスモードであっても、ＬＴＰ  ＣＲＣエラーを検出するたびにそれに応答して、ＬＴＰ  ＣＲＣエラーの総カウントが増分されることに留意されたい。）
【０１００】
ＣＲＣは、パケットやフレームなど、伝送されたデータ単位のエラーを検出するように構成されたデータ完全性チェックである。ＣＲＣの数式は、そのＣＲＣがビット伝送エラーを検出するように選択され、デジタルデータのバイナリな性質を利用して、ＣＲＣをバイナリ量について素早く計算することを可能にする。しかし、ＣＲＣは１００％フェイルセーフではない。ビットエラーの数がＣＲＣのハミング距離と等しい、又はそれを超えるときには、ＣＲＣチェックは、エラーを検出することができない可能性がある。ネットワークファブリックで使用されるＣＲＣのハミング距離は、通常は４であり、これは、エラーが検出されないままとなる可能性（極めて低い可能性）が生じるのに少なくとも４つのビットエラーを要することを意味する。検出されないリンクエラーがあると、いわゆる「誤りパケット許容」が生じる。つまり、エラーを有するパケットが、ＣＲＣチェックを（誤って）通過し、そのためにさらなる処理のために許容されてしまう。これらの検出されないエラーにより、パケットのサイレントデータ破壊が生じる。
【０１０１】
ＬＴＰのサイズは、約１０００ビットである。所与の平均ビット誤り率（ＢＥＲ）では、検出失敗の確率は、単一のリンク転送パケット内でエラーが相関し、（４個以上の）バーストで発生する場合の方が、エラーが複数のＬＴＰにわたって時間的に分散している一様なエラーパターンの場合より、高くなる。
【０１０２】
ネットワークファブリックリンクは、非常に低いが非ゼロのＢＥＲを提供するように設計される。リンクパワーを低下させるには、パワーが低下するにつれて高くなる傾向があるＢＥＲを高くする。ＢＥＲが増加するにつれて、エラー検出失敗の確率は高くなる。ある点で、この確率は、許容不能なほど高くなる。ファブリック内の多数のリンクにわたるＢＥＲは、不均一である。これらのリンクは、通常は、複数のレーンで構成され、ＢＥＲは、所与のリンク内でレーンごとに大きなばらつきがある可能性がある。従来の手法では、ファブリック管理ソフトウェアが何らかのしきい値ＢＥＲで動作しているリンクを検出すると、ファブリック管理ソフトウェアは、許容不能なほど高いデータ破壊確率を回避するために、そのリンクをファブリックから除去せざるを得ない。これは、リンク内のエラー分布を把握せずに行われ、エラーが相関していることを前提とする、控えめな小さいＢＥＲしきい値を使用しなければならなくなる。さらに、リンクのＢＥＲは、時間とともにドリフト及び／又は劣化して、許容不能なほど高くなる可能性がある。ファブリックマネージャは、全てのリンクを連続的に常に実時間で監視することはできず、その結果として、あるリンクが高すぎるＢＥＲで動作していることを検出するのに、ある程度の時間がかかることがある。この時間の間、ファブリックは、データ破壊の可能性にさらされる。
【０１０３】
近接配置されたビットエラーについての１つのチェックでは、判定ブロック２２２４でＬＴＰ  ＣＲＣエラーチェックを使用し、判定ブロック２２２６で逐次ＬＴＰ  ＣＲＣエラーチェックを使用する。ＣＲＣを使用すると、少なくとも１つのエラーが検出されたことを特定することができるが、ＣＲＣは、エラーがいくつ存在するかは特定しない。しかし、逐次ＬＴＰ  ＣＲＣエラーは、少なくとも２つのエラーが逐次ＬＴＰに存在することを示す。１実施形態では、逐次ＬＴＰ  ＣＲＣエラーの検出に応答して、ブロック２２２８で１対のＲｅｔｒａｉｎＲｅｑ  ＬＴＰが送信機に送信され、出口ブロック２２３２及び送信機状態機械２３００のＲｃｖＲｅｔｒａｉｎＲｅｑに示すように、流れ図の論理を出て、リンクを再訓練する。１実施形態では、この再訓練は、リンクを初期化又は再初期化するときに利用されるリンク（再）訓練動作より複雑でない、軽量な再訓練である。訓練又は再初期化中に、リンクの通常のアクティブな転送状態はオフラインである。つまり、通常のデータ転送動作は、リンクの訓練又はリンクの再初期化の終了時にリンクが通常のアクティブな転送状態に復帰するまで、一時的に利用不能になる。さらに、受信機は、ブロック２２３０で、いくつかの内部指標を設定して、その受信機がＲｅｔｒａｉｎＲｅｑ  ＬＴＰを送信することを示し、リンク逐次エラータイマは、ブロック２２３１でリセットされる。このリンク逐次エラータイマの使用のさらなる詳細については、図２２ｅに示し、以下で説明する。訓練シーケンスが終了すると、論理は、流れ図２２００ｂのブロック２２１８及び２２２０に戻り、これらのブロックで、（ａ）１つ又は複数の再試行要求ＬＴＰが送信側に返送され、受信機では、ＬＴＰトスモードに再び入る。
【０１０４】
再試行マーカＬＴＰを受信したのに応答してＬＴＰトスモードループを出るので、受信したＬＴＰがＣＲＣエラーを有していない場合には、論理は、判定ブロック２２３４に進み、このブロックで、ＬＴＰトスモードである間に受信した良好なＬＴＰのそれぞれが再試行マーカであるかどうかを判定する。送信要求を受信する前に、送信機はＬＴＰを連続的に伝送し続け、これらのＬＴＰは、既に飛行中のＬＴＰ（既に飛行中のＬＴＰがある場合）とともに受信される。図２２ｃの流れ図２２００ｃのブロック２２３８、２２４０及び２２４２に示すように、再伝送要求（ＲｅｔｒｙＲｅｑ  ＬＴＰ）を受信すると、送信機は、再試行マーカを送出し、その後に、再現バッファ１８０６でＬＴＰの再伝送が行われるが、この再伝送は、再伝送要求を介して戻されたＮｘｔＲｘＬＴＰポインタの値で示されるスロットのＬＴＰから開始される。１実施形態では、単一の再試行マーカが送信されるが、別の実施形態では、１対の再試行マーカが順番に送信される。１実施形態では、再試行マーカの対は、それらが送信された順序（例えばＲｅｔｒｙＭｒｋｒ０、ＲｅｔｒｙＭｒｋｒ１）で識別される。１実施形態では、各再試行マーカは、ヌルＬＴＰを含む。ＲｅｔｒｙＭｒｋｒＬＴＰ１８１６で示される単一の再試行マーカの使用の一例を、図１８ｂに示す。１対の再試行マーカが送信されるとき、第２の再試行マーカ（ＲｅｔｒｙＭｒｋｒ１）は、ＲｅｔｒｙＭｒｋｒＬＴＰ１８１６（ＲｅｔｒｙＭｒｋｒ０）の直後に続くことになることは理解されるであろう。
【０１０５】
図１８ａの例では、このように再伝送要求を受信する前に複数のＬＴＰを連続的に伝送すると、ＬＴＰ５及び６（飛行中）、７（次に伝送される）、並びにＬＴＰ０及び１を順番に受信することになる。ＬＴＰ５、６、７、０及び１はそれぞれ再試行マーカではないので、判定ブロック２２３４の結果はそれぞれについてＮＯであり、論理は、ブロック２２３６に進んでＬＴＰを破棄し、次いでブロック２２２２にループバックして、次のＬＴＰを受信するが、ＬＴＰトスモードのまま留まる。その後に受信されるＬＴＰの処理は、判定ブロック２２３４で再試行マーカＬＴＰが受信されて検出されるまで、同様に継続する。
【０１０６】
図１８ｂは、ＲｅｔｒｙＭｒｋｒＬＴＰ１８１６が受信ポート１８０２によって既に伝送され、受信され、処理されており、ＬＴＰ４が既に再伝送され、受信ポート１８０２に受信されている最中であり、その後に再伝送されたＬＴＰ５及び６（飛行中）が続き、ＬＴＰ７が再伝送される直前である、時間フレームを示す図である。図１８ｂにも示すように、（図１８ａに示す）スロット０及び１の再現バッファデータは、ＲｅｔｒｙＲｅｑＬＴＰ１８１２を受信し、ＲｅｔｒｙＭｒｋｒＬＴＰ１８１６を伝送する前に行われた、それらの元の伝送に関連するＬＴＰ０及び１の対応するフリットデータで上書きされる。
【０１０７】
上記と同様に、信頼できる各ＬＴＰ伝送で、ＬＴＰのデータは、信頼できるＬＴＰがあるたびに増分されるＮｘｔＴｘＬＴＰポインタ１８０８によって識別される再現バッファ１８０６中のスロットにコピーされる。したがって、ＮｘｔＴｘＬＴＰポインタ１８０８は、ＬＴＰ７、０及び１のそれぞれの送信に関連して増分されていることになる（ＮｘｔＴｘＬＴＰポインタは７から０にラップすることに留意されたい）。ＬＴＰ１が伝送されている間に（又はその少し前に）、送信ポート１８００は、ＲｅｔｒｙＲｅｑＬＴＰ１８１２を受信する。これに応答して、送信ポート１８００は、ＲｅｔｒｙＭｒｋｒＬＴＰ１８１６（又はＲｅｔｒｙＭｒｋｒ０ＬＴＰ及びそれに続くＲｅｔｒｙＭｒｋｒ１ＬＴＰを含む１対の再試行マーカ）を戻す。ＲｅｔｒｙＭｒｋｒＬＴＰ１８１６はヌルＬＴＰであるので、そのデータコンテンツは再現バッファ１８０６にコピーされず、ＮｘｔＴｘＬＴＰポインタ１８０８も進められない。逆に、ＴｘＬＴＰシーケンス状態は、それが信頼できるＬＴＰであるかヌルＬＴＰであるかに関わらず、ＬＴＰが伝送されるたびに進められる。
【０１０８】
判定ブロック２２３４に戻って、ＲｅｔｒｙＭｒｋｒＬＴＰ１８１６を受信したときに、このＲｅｔｒｙＭｒｋｒＬＴＰ１８１６は再試行マーカであると識別され、流れ図の論理は、図２２ｄの流れ図２２００ｄに進む。ブロック２２５２に示すように、再試行マーカが処理され、受信機は、今後再現される不良ＬＴＰの受信に備えるようにカウントダウン値を設定する。１実施形態では、不良ＬＴＰの再現オフセットを再試行マーカに対して利用して、不良ＬＴＰの再伝送によって再試行マーカの後にｋ個のＬＴＰを開始することを示す。１対の再試行マーカを利用する１実施形態では、不良ＬＴＰ再現オフセットは、第２の再試行マーカに対して１つ少ない。ブロック２２４０に示すように、不良ＬＴＰ再現オフセットに鑑みて、受信機は、ＬＴＰオフセットに基づいて、不良ＬＴＰ再現カウントダウンを開始する。これを使用して、ブロック２２５６で、不良ＬＴＰの再現を検出する。さらに、受信機は、ブロック２２５４でラウンドトリップマーカＬＴＰ（又は１対のラウンドトリップマーカＬＴＰ）を戻し、ブロック２２５４で、ＬＴＰ受信モード（受信状態）が、通常に復帰し、流れ図の論理は、ブロック２２０４に戻って次のパケットを受信する。これは受信機状態図２３５０では「ＲｎｄＴｒｉｐＭｒｋｒ対を送信する」状態及び「ＬｉｎｋＴｒａｎｓｆｅｒＡｃｔｉｖｅ．ｎｏｒｍａｌに戻る」状態で表される。図１８ｃを参照して以下で説明するように、再現バッファＬＴＰが上書きすることができるかどうかの判定を容易にするために、１つ又は複数の再試行マーカＬＴＰに応答して、１つ又は複数のラウンドトリップマーカＬＴＰが戻される。
【０１０９】
ＲｅｔｒｙＭｒｋｒＬＴＰ１８１６（又はＲｅｔｒｙＭｒｋｒ０ＬＴＰ及びＲｅｔｒｙＭｒｋｒ１ＬＴＰ）の伝送に続いて、ＬＴＰの再現（再伝送）が開始される。この再現は、ＲｅｔｒｙＲｅｑＬＴＰ１８１２（この例ではＬＴＰ４）に含めて戻されるＮｘｔＲｘＬＴＰポインタによって識別される不良ＬＴＰの再伝送から開始される。送信機が再現モードである間は、伝送されるデータは、再現バッファ１８０６に記憶される再伝送されたＬＴＰを含むことになる。再伝送されるＬＴＰは、ＮｘｔＲｘＬＴＰポインタによって示されるＬＴＰから開始して、再現バッファのＦＩＦＯにおけるそれらの順序に基づいて、送信ポート１８００から順番に送出される。
【０１１０】
再伝送される各ＬＴＰでは、伝送されるデータは、ＬＴＰが最初に伝送されたときと同じである。不良ＬＴＰ再現カウントダウン（及び再現された不良ＬＴＰの受信に関連する動作）の外部では、受信側の論理は、受信したＬＴＰデータが最初に伝送されたＬＴＰに対応するのか、再伝送されたＬＴＰに対応するのかが曖昧である。したがって、ブロック２２０４、２２０６及び２２０８並びに判定ブロック２２１０の動作が実行されると、レーンごとのＣＲＣ計算、受信したＬＴＰデータについてのＲｘ  ＬＴＰ  ＣＲＣの計算、及びＲｘ  ＬＴＰ  ＣＲＣとＴｘ  ＬＴＰ  ＣＲＣとの比較が行われる。判定ブロック２２１０の結果がＮＯであることによって示されるように、エラーがある場合には、論理はブロック２２１４に戻り、このエラントな再伝送ＬＴＰによって、不良ＬＴＰが再び再伝送される新たな再現シーケンスが開始される。これは、基本的には、再現バッファ１８０６からの不良ＬＴＰ４及びその後に続くＬＴＰの再伝送に関連して上述した動作を繰り返すものである。
【０１１１】
再伝送された不良ＬＴＰ４が良好であると仮定すると、論理はブロック２２５８に流れる。このブロックでは、それまでレジスタＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２及びＣＲＣ−Ｇ３に記憶されていたレーンごとのＣＲＣの値を、再伝送されたＬＴＰ４の各レーンを介して受信したデータについて計算したレーンごとのＣＲＣと比較する。この比較は、動作しているレーンの数に応じて、レーンごと、又はＸＦＲグループごとに行われる（レーンごと及びＸＦＲグループごとの比較は、転送グループの数が同じであるときには等価であり、ＸＦＲグループごとの比較を常に実行することができるようになっていることに留意されたい）。上記より、レーンごとのＣＲＣは、４レーンリンクの場合には、ＸＦＲグループごとに比較される。
【０１１２】
各伝送ＬＴＰのＴｘ  ＬＴＰ及びＲｘ  ＬＴＰシーケンス状態の継続的な増分に関しては、ＬＴＰが最初に伝送されたときにはＬＴＰシーケンス状態が１であったのに対して、ＬＴＰ４が再伝送されるときには、ＬＴＰシーケンス状態は３である。その結果として、各レーンを介して伝送されるＸＦＲグループが変化している。このレーン／ＸＦＲグループの再マッピングを、図２５に示す。この再マッピングは、図１８ａ及び図１８ｂの各レーンを介して送信されるＸＦＲを比較することによっても理解することができる。上述のように、ＬＴＰ４が最初に伝送されたときには、ＬＴＰシーケンス状態は１であったが、ＬＴＰ４が再伝送されるとき（図２５では４Ｒで示す）には、ＬＴＰシーケンス状態は３である。図１８ｂに戻ると、再伝送されたＬＴＰ４のレーンごとのＣＲＣが、レーン０、１、２及び３について計算され、その後、流れ図２２００ｄのブロック２２５８で、ＸＦＲグループのＣＲＣ比較が実行され、ブロック２２６０で、適用可能な不一致のレーンごと又はＸＦＲグループごとのＣＲＣを識別することによって、不良レーンが識別される。図１８ａ及び図１８ｂの例では、ＸＦＲグループごとのＣＲＣ比較の結果は、ＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１及びＣＲＣ−Ｇ３のＣＲＣは一致するが、ＣＲＣ−Ｇ１のＣＲＣは一致しないことを示している。このことは、レーン２が、エラントなＬＴＰ４が最初に伝送されたときにそのＬＴＰ４についてＣＲＣ−Ｇ１の値を計算したＸＦＲグループに対応するので、レーン２がエラントであることを示している。なお、再伝送されたＬＴＰ４ではＬＴＰ  ＣＲＣエラーが検出されなかったので、再現されたＬＴＰ４についてレーン２を介して伝送されたデータには（おそらくは）エラーがないことに留意されたい。ブロック２２６１で、識別された不良レーンのエラーカウントを増分する。レーンが断続的にエラントであるシナリオを考慮されたい。上述のように、判定ブロック２２２６及び関連する論理ブロックの逐次ＬＴＰ  ＣＲＣエラーチェックは、リンクを介して伝送されるデータ中の近接配置されたエラーを検出するための１つの機構である。この機構は、極めて近接して配置されたエラーを検出するが（エラーが逐次ＬＴＰにあることを必要とする）、この機構は、どのレーンがエラントであるかを特定することはできず、また、個々のレーンでどの程度頻繁に逐次エラーが起きているかを特定することもできない。
【０１１３】
第２のＢＥＲチェック機構の実施形態によれば、レーンごとのエラー頻度を監視して、所与のレーンのエラー頻度（ＢＥＲ）がレーンごとのＢＥＲしきい値を超えるかどうかを判定する。１実施形態では、これは、レーンごとの逐次エラーカウンタ及びタイマを（流れ図２２００ｄ及び２２００ｅに示す、並列に実行されるその他の動作及び論理と関連して）使用することによって実施される。
【０１１４】
判定ブロック２２６２では、受信機状態が、その受信機が開始したリンク再訓練状態によって生じたものかどうかを判定する。流れ図２２００ｂの論理が示すように、また上述したように、複数の逐次ＬＴＰ  ＣＲＣエラーが検出されると、それらのエラーを検出している受信機がリンク再訓練を開始することになる。逆に、単一のＬＴＰ  ＣＲＣエラーも同様に再試行要求／再試行マーカ受信シーケンスを開始するが、この場合にはリンク再訓練は開始されない。再現されたＬＴＰが良好であり、受信状態がリンク再訓練から生じたものではない（すなわち単一のＬＴＰ  ＣＲＣエラーしか検出されていない）場合には、判定ブロック２２６２の結果はＮＯとなり、論理はブロック２２６４に流れ、ＬＴＰは、そのＬＴＰが最初に送信されたＬＴＰであるかのように処理される。次いで、論理は、流れ図２２００ａに戻り、その後に再現されたＬＴＰが（受信機から見て）最初に送信されるときに、それらの再現されたＬＴＰを処理する。
【０１１５】
次に、２つの逐次ＬＴＰ  ＣＲＣエラーが受信機によって検出され、その結果として受信機がリンク再訓練を開始し、判定ブロック２２６２の結果がＹＥＳとなり、その結果として論理がブロック２２６６に進むものと仮定されたい。このブロックでは、ブロック２２６０で決定された不良レーンの逐次エラーカウンタが、増分される。判定ブロック２２６８では、このレーンの逐次エラーカウントがしきい値に到達しているかどうかを判定する。一般に、このしきい値は、１や２などの整数である。１実施形態では、しきい値は２であり、タイマの１周期内に１つのレーン上で逐次エラーが２つあると、そのレーンのＢＥＲしきい値検出が失敗する。これに応答して、１実施形態では、論理は、出口ブロック２２７０に進み、このブロックで、不良であるものとして検出されたレーンが除去されて、このリンクが再初期化される。その結果として、４レーンリンクが劣化してアクティブなレーンが３つになるなど、リンクのアクティブなレーンの数は１つ減少する。
【０１１６】
レーンごとの逐次エラーカウントがしきい値に到達していない場合には、判定ブロック２２６８の結果はＮＯとなり、論理はブロック２２０４に進んで、次のＬＴＰを受信し、受信機は、通常受信状態で動作し、送信機は、依然として再現モードで動作する。
【０１１７】
上述のように、１実施形態では、タイマ方式を使用して、レーンごとの逐次エラーの頻度を検出する。上記より、論理は、逐次不良ＬＴＰの検出に応じてブロック２２３１に進み、図２２ｅの流れ図２２００ｅに示すように、タイマ方式を実施する１組の並列動作が開始される。ブロック２２７２で、適用可能であれば、タイマが始動（最初の場合）又は再始動（リセットの場合）される。判定ブロック２２７４及びそれ自体に戻るループが示しているように、タイマは、タイマが満期に達したかどうかを判定するために定期的にチェックされるか、或いは必要に応じて、タイマ論理を、タイマが満了したことを示す割込み又はその他の指標を生成するように構成することができる。ブロック２２７６に示すように、タイマの満了時に、各レーンの不良逐次エラーカウンタは減分される。１実施形態では、最小不良エラーカウントは０であるので、既に０になっているレーンエラーカウントについては、そのカウントは減分されない
【０１１８】
並列プロセスの組合せにより、以下の方法で、個々のレーン上のエラーが頻度しきい値を超えていることを検出する（例えば、近接配置されたエラーを呈するレーンを識別する）。流れ図の動作によって論理がブロック２２５８、２２６０を通り、判定ブロック２２６４の結果がＹＥＳになるたびに、不良レーンの逐次エラーカウントが増分される。一方で、並列タイマ動作について考えると、タイマが再始動されることなく満了するたびに、それがレーンごとのエラーを生じることなくタイマの時間周期が経過したことを示すので、各レーンのレーンごとの逐次エラーカウントが１だけ減分される（最小値０まで）。１実施形態では、２つのエラーがあり、レーンが失格になり、これは、１つのレーンが、時間周期内に２つの逐次エラーを有することに対応する。
【０１１９】
１つのタイマに加えて、異なる時間周期及び異なる関連するカウントしきい値を有する、複数のタイマを並列に使用することもできる。例えば、このようにすると、より長期間にわたるレーンごとの動作を観察することが可能になり、また、より短いレーンごとのＢＥＲしきい値検出も容易になる。この時間周期で必要とされる逐次エラーの数のしきい値も、変更することができる。
【０１２０】
流れ図２２００ａ〜２２００ｅに示す実施形態では、リンクの再初期化を不良レーンの除去と組み合わせることは、近接配置されたエラーを呈するレーンを検出することによってもたらされる。しかし、逐次ＬＴＰ  ＣＲＣエラーの検出に続いて出口ブロック２２３２を介して出るときなど、他の条件下のリンクの再初期化及び／又は再訓練と関連してレーンを除去することができるので、これは限定的なものではない。例えば、リンクが再初期化するときに、レーンごとのエラーカウンタをチェックして、エラーカウントが何らかのしきい値を超えているかどうかを調べる。エラーカウントがしきい値を超えている場合には、そのレーンは、不良としてマークされ、リンクがアクティブな動作に復帰するときにアクティブではない。
【０１２１】
暗示的なＡＣＫを用いる信頼できるＬＴＰ伝送の別の特徴は、再現バッファ中のＬＴＰが、そのＬＴＰがエラーなく受信されていることが暗示的に確認される前に上書きされないことを保証する機構である。１実施形態では、これは、再試行要求及びラウンドトリップマーカを使用することによって容易になる。上述のように、いくつかの実施形態では、再現バッファは固定サイズを有する、又は複数の固定サイズのうちの１つを用いて動作するように設定されるように構成することができる。さらに、１対のリンクピアが、異なるサイズの再現バッファを利用することもできる。
【０１２２】
固定サイズの再現バッファの使用時には、再現バッファは、一般に、そのリンクのラウンドトリップ横断中に転送することができるＬＴＰの数より多いいくつかのＬＴＰを保持するようなサイズとされるが、さらに様々な処理待ち時間も考慮される。これは、図１８ａ及び図１８ｂに示す場合であり、再現バッファは、８個のスロットを有し、そのリンク及び反対方向のリンク経路を介して同時にラウンドトリップ横断することができるＬＴＰの数は、約６又は７である。その結果として、受信機でエラーが検出された場合には、送信機は、再現バッファ中の不良ＬＴＰのコピーが上書きされる前に再試行要求を受信する。
【０１２３】
しかし、実際的な理由から、固定サイズの再現バッファは、全ての可能なリンク長を取り扱うようなサイズにはならない。リンクの長さが大きくなるほど、再試行要求を受信する前に再現バッファから送出することができるＬＴＰの数が大きくなる。ある点で、リンク長は、再試行要求方式を使用するだけでは、再現バッファ中の不良ＬＴＰのコピーが、その不良ＬＴＰについての再試行要求を受信する前に上書きされないことが保証されないような長さになる。
【０１２４】
これは、ラウンドトリップマーカの使用が適合する場合である。流れ図２２００ｃに戻って、判定ブロック２２４４で、全てのＬＴＰの再現が、ラウンドトリップマーカを受信することなく完了したかどうかを判定する。図１８ｃに示す構成でも、再現バッファ１８０６には８個のＦＩＦＯスロットがあるが、リンク長は、一度に５つのＬＴＰしか「回線上にのせる」ことができない。つまり、受信機では、少なくとも１０個のＬＴＰがラウンドトリップ横断する、かつ／又は処理されることができる。その結果として、再現バッファ中の全てのＬＴＰのコピーを、ＬＴＰのいずれかについての再試行要求を受信する前に再伝送することができ、不良である可能性があるＬＴＰのコピーが上書きされることになる。これにより、不良ＬＴＰが再伝送されることが防止され、再現バッファの目的が損なわれる。
【０１２５】
このシナリオに対応するために、送信機は、判定ブロック２２４４に示すように、ラウンドトリップマーカを受信する前に再現ＬＴＰの末端に到達しているかどうかを検出する論理を含む。基本的には、これは、再現バッファの深さがラウンドトリップ持続時間より小さいか、又は大きいかを判定するものである。再現ＬＴＰの末端への到達は、再現ポインタが最初に再現されたＬＴＰの始点（ＦＩＦＯスロット）にラップすることによって検出される。
【０１２６】
図１８ｃでは、最初に再現されたＬＴＰスロットはスロット４であり、スロット４、５、６、７、０、１、２及び３のＬＴＰは、逐次再伝送されており、１対のラウンドトリップマーカ１８２２ａ及び１８２２ｂのうちの第１のラウンドトリップマーカを受信する前に、再現ＬＴＰポインタをスロット４に戻す。これは、ラウンドトリップマーカを受信する前に再現ＬＴＰの末端に到達し、ラウンドトリップ持続時間が再現バッファの深さより大きいことを示す例を示している。これにより、判定ブロック２２４４の結果がＹＥＳになり、論理は、ブロック２２４５ａに進み、このブロックで、送信機のヌルカウンタ（Ｎｕｌｌｃｏｕｎｔ）ｎが整数ｋにリセットされる。ブロック２２４６ａ及び結果がＮＯである場合にブロック２２４６ａにループして戻る判定ブロック２２４８で示すように、次いで、送信機は、ラウンドトリップマーカ又は再試行要求が受信されるまで、１つ又は複数のヌルＬＴＰを受信機に送信するようになる。さらに、ヌルＬＴＰが伝送されるたびに、Ｎｕｌｌｃｏｕｎｔ  ｎは、１だけ増分される。上述のように、ヌルＬＴＰは、信頼できるＬＴＰではないので、伝送されたＬＴＰのコピーは、再現バッファに追加されない、その結果として、再試行要求を生じた不良ＬＴＰのコピーは、再試行要求を受信する前に上書きされないことが保証される。
【０１２７】
判定ブロック２２４８ａでラウンドトリップマーカを受信したと判定されると、論理は、ブロック２２５０に進み、このブロックで、図２３ａの送信機状態機械２３００に「ＬｉｎｋＴｒａｎｓｆｅｒＡｃｔｉｖｅ．ｎｏｒｍａｌに戻る」と示すように、送信機は通常の転送モードに復帰するが、再現バッファの各サイクルのＮｕｌｌｃｏｕｎｔ  ｎの値を使用して、再現バッファの末端に到達した後でいくつのヌルＬＴＰを送信するかを決定する。例えば、Ｎｕｌｌｃｏｕｎｔ  ｎが４に到達したものとする。その結果、再現バッファのＦＩＦＯスロットがスロット７に到達するたびに、送信機は、４つのヌルＬＴＰを送出することになる。１実施形態では、再試行要求及びラウンドトリップマーカは、最高の優先順位を有し、プリエンプトされることはないので、Ｎｕｌｌｃｏｕｎｔ  ｎによって規定されるいくつかのヌルＬＴＰの伝送を用いることで、不良ＬＴＰのコピーが、その不良ＬＴＰについての再試行要求を受信する前に上書きされないことが保証される。任意選択で、ブロック２２４５で、Ｎｕｌｌｃｏｕｎｔ  ｎを値ｋ＞０にリセットして安全性マージンを設けて、ｋ個の余分なヌルＬＴＰが再現バッファの各サイクルの終端で伝送されるようにすることもできる。Ｎｕｌｌｃｏｕｎｔ方式の固有の利点は、Ｎｕｌｌｃｏｕｎｔ方式を実施すると、実質的にいかなる長さのリンクでもサポートすることができる点である（物理リンクの長さに実際的な限界があり、この限界を超える長さを有するリンクの製造及び／又は実装が不可能であるか、非現実的であることは認識されたい）。
【０１２８】
判定ブロック２２４４に戻って、ラウンドトリップマーカが、第１のＦＩＦＯスロットに到達する前に受信されている場合には、判定ブロック２２４４の結果はＮＯとなり、論理はブロック２２４５ｂに進み、このブロックで、Ｎｕｌｌｃｏｕｎｔ  ｎは整数ｍにリセットされる。ブロック２２４６ｂ及び結果がＮＯである場合にブロック２２４６ｂにループして戻る判定ブロック２２４９で示すように、次いで、送信機は、バッファポインタがラップしてその開始スロットに戻る、又はＮｕｌｌｃｏｕｎｔ  ｎが０に到達するまで、ＬＴＰを受信機に対して再現し続けるようになる。ここで、Ｎｕｌｌｃｏｕｎｔのカウントダウンはｍで始まり、信頼できるＬＴＰが再伝送されるたびに１だけ減分される。判定ブロック２２４９の結果がＹＥＳであるのに応答して、論理は、このＮｕｌｌｃｏｕｎｔカウントダウンループを出て、ブロック２２５０に進む。
【０１２９】
Ｎｕｌｌｃｏｕｎｔカウントダウンを使用することにより、バッファの深さがラウンドトリップ持続時間のｍ個のＬＴＰ転送サイクルより大きいが、ラウンドトリップ持続時間のｍ個のＬＴＰ転送サイクル以内である構成では、約ｍ個のＬＴＰ転送サイクルの安全性マージンが得られる。例えば、バッファの深さが３２スロットであり、ラウンドトリップ持続時間が３０個のＬＴＰ転送サイクルに等しく、ｍ＝５であるものと想定する。この場合には、論理がカウントダウンループを出たときには、ｍは３となる。これは、再現バッファがその始点（スロット０）にラップして戻るたびに、スロット０中のＬＴＰが上書きされる前に、３つの余分なヌルＬＴＰが伝送されることを意味する。バッファの深さが３２スロットであるので、上書きされている再現バッファスロットの間のＬＴＰサイクルの数は３５となり、すなわち、ラウンドトリップ持続時間より５多い。
【０１３０】
不良レーンの検出に応答して、リンクは、アクティブなレーンの数を減少させた劣化状態で動作させることができる。さらに、このリンク劣化状態をカスケード状にして、４つのアクティブなレーンから始まって、第１の不良レーンを検出してこの不良レーンを除去し、アクティブなレーンを３つ用いるリンク動作になり、第２の不良レーンを検出してこの第２の不良レーンを除去し、アクティブなレーンを２つ用いるリンク動作になるなどのシーケンスでリンクが動作するようにすることができる。このカスケードは、第３の不良レーンを検出して、残った１つの良好なレーンによるリンク動作になるところまで継続することができる。なお、リンクは、非対称構成で動作させて、一方の伝送方向で、他方の伝送方向とは異なる数のアクティブなレーンを使用することができるようにすることもできることに留意されたい。
【０１３１】
図２６は、１実施形態による、３つのアクティブなレーンを有するリンクを運用するＸＦＲグループを示す図である。この場合には、３つのＸＦＲグループＧ０、Ｇ１及びＧ２があり、対応するＣＲＣはＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１及びＣＲＣ−Ｇ２である。ＬＴＰシーケンスは、レーンを変更せずにＸＦＲパターンが繰り返される単一の状態しか有さないので、同じＸＦＲグループが、それぞれ同じレーンを介して伝送される。その結果として、レーンごとのＣＲＣ比較は、レーンごとに行うことができ、或いは、ＸＦＲグループごとの場合には、ＬＴＰシーケンス状態を考慮しない。レーンが３つの場合には、各レーンごとに１１回の３２ビット転送が行われるので、標準検出ＬＴＰ１つ当たり、各レーンを介して３５２ビットが伝送される。１実施形態では、アクティブなレーンが３つで動作するときには、１６ビットのレーンごとのＣＲＣが使用される。
【０１３２】
図２７は、１実施形態による、２つのアクティブなレーンを有するリンクを運用するＸＦＲグループを示す図である。ＬＴＰあたり３３回の３２ビット転送が行われるので、１つのＬＴＰ伝送ストリームについてレーン０及び１のそれぞれを介して転送されるビットの数は、交互に５１２ビットと５４４ビットとなる。その結果として、ＸＦＲグループごと／レーンごとのＣＲＣ比較方式が、２つのＬＴＰシーケンス状態を用いて実施される。さらに、１実施形態では、１６ビットのレーンごとのＣＲＣが使用される。
【０１３３】
図２８は、１実施形態による、単一のアクティブなレーンを有するリンクを運用するＸＦＲグループを示す図である。ＬＴＰデータが送信されるレーンは１つしかないので、エラントになり得るのは、その唯一のレーンだけである。その結果として、レーンごとのＣＲＣ比較を実行する必要がない。
【０１３４】
しかし、複数のレーンを有するリンクがレーンを１つしか用いない動作に劣化するレーン劣化シナリオでも、依然として、その単一のレーンについてレーンごとのＣＲＣ計算が行われることがある。この計算は、その計算が常に実行されるようにハードウェアで実施されることがあるからである。この場合には、レーンごとのＣＲＣ計算は、単純に無視される。
【０１３５】
上述のように、本明細書に開示する実施形態では、リンクは、明示的なＡＣＫを使用することなく、信頼できるデータ伝送をサポートする。ＬＴＰは、リンクを介して伝送されているときに喪失する可能性はない（ケーブルが切断されるなどの事象がない限り）が、ＬＴＰは、エラーを含む可能性はある。暗示的な確認応答方式は、少なくとも送信機から受信機まで行き、送信機に戻るラウンドトリップを完了するのに要する時間と同じ長さの時間周期内に送信機で再試行要求を受信することなく実施されることを想起されたい。再試行要求が、伝送データとは異なるレーンのセットを介して送信されるので、単一の再試行要求がエラー（ＣＲＣチェックで識別される）を有し、したがってトスされる可能性がある。その結果として、受信側のリンクインタフェースは、送信側のリンクインタフェースに、それがエラントなＬＴＰを受信したことを通知しようとすることはできるが、その通知（再試行要求によって示される）はトスされることになる。これは、ＲｅｔｒｙＲｅｑＬＴＰの逐次対及びその他のヌルＬＴＰの対（例えばＲｅｔｒｙＭｒｋｒ０、ＲｅｔｒｙＭｒｋｒ１）の送信が、暗示的なＡＣＫ方式を容易にする助けになる場合である。
【０１３６】
第１に、これらはヌルＬＴＰであるので、これらは、再現バッファには記憶されず、したがって、再伝送に利用することができない。しかし、ヌルＬＴＰの逐次対を送信することにより、１）２つのヌルＬＴＰのうちの少なくとも１つはエラーなく上手く受信される、又は２）両方のＬＴＰがエラーを有する場合に、そのことが逐次ＬＴＰエラーとして検出され、リンクの再訓練がトリガされる、という２つの事象のうちの一方が生じることが保証される。（再）訓練時には、訓練シーケンスは、リンクパートナの両方の送信機／受信機対によって実行されるので、そのリンクをアクティブな動作に復帰させる前に、両方向のリンクの適当な動作が検証される。再訓練が完了すると、送信側は、受信側からの保証付き再試行要求を待機し（その間にヌルＬＴＰを送信する）、その後で、１つ又は複数の再試行マーカを送信した後に新たなＬＴＰの送信を開始する（又はＬＴＰの再現を引き続き行う）。別の利点は、これらのヌルパケットの対を送信すると、ＬＴＰのうちの少なくとも１つが良好となる可能性が高くなることである。
【０１３７】
ポート、バッファ、及びクレジット管理
図２９は、スイッチ及びＨＦＩのポート間の関係とアーキテクチャのレイヤ及びサブレイヤとを示す図である。スイッチは、パケットをファブリックエンドポイントに向かって転送するものであり、イングレス（受信）ポート及びエグレス（送信）ポートをそれぞれ含む複数の物理ポートを有する。さらに、上述の図２を参照すると、これらの各ポートは、リンクファブリックサブレイヤ（Ｌ２）とインタフェースをとるリンク転送サブレイヤ（Ｌｌ．５）とインタフェースをとる物理サブレイヤ（ＰＨＹ）（Ｌ１）を含む。本節は、ＨＦＩデバイス及びスイッチデバイスの両方のアーキテクチャのリンク転送サブレイヤとリンクファブリックサブレイヤの間でのパケットデータの移動を容易にするポートの特徴に関する節である。ポートの構成要素は、イングレス及びエグレスバッファ管理、ＳＣ及びＶＬ変換機構、経路指定の方法及び定義、クレジット管理、並びにエグレスポートのアービトレーションである。ＨＦＩアプリケーションは、パケットを構築した後で、それらをリンク転送サブレイヤに伝送する前に、経路指定及びスケジューリングのためのポートに転送する。逆方向には、ポートは、パケットを受信バッファに転送し、エグレスポート宛先を選択する。このアーキテクチャは、クレジットに基づくフロー制御方式を利用して、クレジットに基づくフロー制御ポリシーが送信ポート及び受信ポートの対（送信機／受信機ピアとも呼ばれる）の間で実施されるファブリック内のパケットのフローを制御する。パケットは、パケットがファブリックを横断する際に一時的な記憶を行う一連のバッファを介して、デバイス（ＨＦＩ／スイッチ）からデバイス（スイッチ／ＨＦＩ）に流れる。フロー制御は、デバイスＡのパケットをいつデバイスＢのバッファに転送できるかを制御する機構である。以下で詳述するように、これらのバッファは、ＶＬに基づいて割当て及び管理され、各ＶＬには、複数単位のバッファ空間が割り当てられる。クレジットに基づくフロー制御方式は、ＶＬバッファのバッファオーバランを防止し、リンクを求めて競合するＶＬの間に公平性をもたらす。
【０１３８】
フロー制御の１つの特徴によれば、柔軟なクレジット管理機構が提供される。信頼できる増分クレジットリターンを可能にするリンクレイヤ再試行を使用することにより、このアーキテクチャは、クレジット管理を行い、送信機の責任をトラッキングすることができる。これにより、トラフィックが飛行中に、クレジットを動かす柔軟性が高まる。このことは、単純に、所与のＶＬでクレジットが利用可能でないときに送信機がパケットをブロック又は破棄すべきかどうかを送信機に知らせることによって、フロー制御を容易にＶＬごとに使用可能にしたり、使用不能にしたりすることができることを意味している。
【０１３９】
この柔軟なクレジットに基づくフロー制御機構は、以下の特徴を規定する。
・信頼できるリンク転送プロトコルを利用して、多数の仮想レーンの間の効率的な増分クレジット交換を可能にする。
・クレジット割当ての管理を送信機が単独で実行できるようにする。
・リンクを休止させる必要なく、トラフィックが流れている間にＶＬごとにクレジットを再構成できるようにする。
・送信機の構成に応じて、フロー制御を行っても行わなくても動作することができる。
・クレジットの交換及び割当ての単位を受信機が定義することができるようにし、これにより様々なハードウェア設計間の相互運用性を実現する。
・クレジットを単一のＶＬの専用にすること、ＶＬのグループの間で共有すること、かつ／又は全てのＶＬの間で共有することができるようにする。
【０１４０】
クレジットは、対数スケールを用いて増分的に交換される。受信機は、戻されるクレジットの数を、送信機に連絡する。この機構は、全ての交換（クレジット、パケット、その他の制御メッセージ）が高い信頼性で行われることを保証する、信頼できるリンク転送機構が存在することによって可能となる。
【０１４１】
増分クレジット交換を使用することにより、送信機は、クレジットの全てのトラッキングを行うことができる。その結果として、所与のＶＬで利用可能なクレジットを、トラフィックフローに影響を及ぼすことなく、また再構成を受信機と調和させる必要なく、再構成することができる。これにより、この再構成は、飛行中のトラフィックにも送信機で待ち行列に入っているトラフィックにも影響を及ぼすことなく、行うことができる。フロー制御は、複数のＶＬについて独立して使用可能にしたり使用不能にしたりすることもできる。例えば、１実施形態では、所与のＶＬについてフロー制御が使用不能になっている場合に、クレジットマネージャは、現在利用できるクレジットが不十分である場合には、所与のＶＬについてパケットを破棄することになる。フロー制御が使用可能になった場合には、クレジットマネージャは、そのＶＬにバックプレッシャを掛け、十分なクレジットが利用可能になるのを待機した後で、パケット（そのパケットのフリット）を伝送する。フロー制御を使用不能にして、管理プロトコルのトポロジのデッドロックを回避したり、イーサネット（登録商標）のようなリンクレイヤ挙動を実現して輻輳を識別する手段としてパケット損失を使用するＴＰＣ／ＩＰなどのプロトコルを容易にしたりすることもできる。
【０１４２】
図３０は、１対のピアデバイスＡとＢの間のリンクでのクレジットの使用の特徴の一例を示す図である。デバイスＡは、クレジットマネージャ３００２ａを含む送信ポート３０００ａと、初期化ブロック３００６ａ及び複数のＶＬ  ＦＩＦＯバッファ３００８ａを含む受信ポート３００４ａとを含む。デバイスＢは、同じ番号を付された要素で表すように同様に構成されるが、添え字が「ａ」ではなく「ｂ」になっている。
【０１４３】
一般に、各デバイスポートは、バッファ使用に割り当てられたメモリを含む。所与のポートのバッファ空間の全体のサイズは、そのポートのホストデバイスがサポートするＶＬの数、及びそのポートに接続されるリンクの予想ケーブル長など、様々な要因によって決まることがある。ＶＬバッファのサイジングは、その設計の性能に大きな影響を及ぼす可能性がある。バッファリングが小さすぎて、送信機から受信機までのラウンドトリップ時間（ＲＴＴ）をカバーしない場合には、最大帯域幅を実現することができない。バッファが大きすぎる場合には、ＡＳＩＣの面積及びパワーに影響を及ぼす可能性がある。１実施形態では、ファブリックパケットのフリットは、ＦＰ全体に十分なバッファ空間があるときに、次のホップまでしか伝送できない。別の実施形態では、あるパケットの一部分を記憶するために利用可能なある程度のバッファ空間がある場合には、そのＦＰのフリットの初期転送は許可される。１実施形態では、ＶＬバッファをサイジングするときに、１）チャネルレート、２）ケーブル長、３）伝搬遅延、及び４）最大ファブリックパケット長（最大転送単位又はＭＴＵ）といった要因を考慮する。１実施形態では、ＭＴＵは、ＶＬごとに構成可能である。クレジットリターン遅延及びクレジットリターン処理の処理待ち時間など、追加の要因を考慮することもある。
【０１４４】
図３１ａ、図３１ｂ及び図３１ｃは、専用バッファ編成、共有２ティアバッファ編成、及び共有３ティアバッファ編成の例を示す図である。専用バッファ編成では、各ＶＬに、メモリのそれぞれの部分が割り当てられる。異なるＶＬに異なるメモリ部分を割り当てることができることが分かる。１実施形態では、各ＶＬ用のメモリ部分は、ＦＩＦＯとして実装される。１実施形態では、これらのＦＩＦＯは、ヘッドポインタ及びテールポインタを有する円形ＦＩＦＯとして実装される。
【０１４５】
共有２ティアバッファ編成では、バッファ空間の第１の部分は、ＶＬに専用として割り当て、残りの第２の部分は、ＶＬの間で共有されるように割り当てる。図３１ｂでは、第２の部分は、全てのＶＬの間で使用される共有プールを構成している。ただし、これは単なる例示であり、共有プールは、全てのＶＬのではなく一部のＶＬの間で共有することもできる。例えば、所与のＶＬを管理のために使用して、このＶＬが、第２のティアのバッファプールを共有するＶＬとは共有されない、他のＶＬとは異なるサイズの専用ＶＬ  ＦＩＦＯ空間を利用するようにすることもできる。
【０１４６】
３ティア共有バッファ編成方式では、メモリの第１の部分は、個々のＶＬに専用空間として割り当てられ、メモリの第２の部分は、ＶＬの各サブセットの間でそれぞれ共有される２つ以上の共有プールの間で分割され、第３の部分は、全てのＶＬ又はＶＬのサブセットの間で使用される共有プールに使用される。図３１ｃに示す構成では、ティア２は、２つの共有プールを含むが、ティア３は、全てのＶＬの間で共有される１つのバッファプールを含む。これらの共有プールのサイズは、同じである必要はなく、同様に、各サブセットに含まれるＶＬの数も異なっていてもよい。
【０１４７】
リンク動作の進行中には、各送信機は、バッファ構成並びに「近隣」デバイスにおけるピア受信機の受信バッファにおけるＶＬバッファ及び１つ又は複数の共有バッファ空間（適用可能な場合）の充填レベル（利用可能空間）の「ビュー」を維持する。ここで、近隣デバイスは、リンクの反対側端部にある。これは、以下の手法を用いることによって容易になる。最初に、リンクデータ転送動作を開始する前に、近隣デバイスピア送信ポート及びピア受信ポートのそれぞれに、初期受信バッファ構成と、受信ポートの受信バッファのＶＬ割当てとを通知する。１実施形態では、ファブリックマネージャは、受信機のバッファ編成の指定又は識別のうちの１つ又は複数を担当する。次いで、ファブリックマネージャは、送信機のクレジットマネージャを、バッファ編成及びサポートされるデータＶＬの数を反映するようにプログラムすることができる。１実施形態では、ファブリックマネージャは、リンクネゴシエーション及び初期化手続き呼出しＬＮＩと関連して、この動作を実行する。
【０１４８】
データがリンクを介して流れ始めると、様々な受信ポートにおけるバッファ可用性は、各受信機で受信されるフリット、及び次のホップへのフリットの転送に関連して受信機のバッファから除去されるフリットに応じて、動的に変化する。これらの変化に関連して、受信ポートは、クレジットＡＣＫをそのピア送信ポートに送信する。ここで、これらのクレジットは、送信ポートのクレジットマネージャによって処理されて、送信ポートが有する受信ポートの現在のバッファ構成のビューを更新する。リンクラウンドトリップ転送時間及びクレジット処理待ち時間を含む待ち時間により、送信ポートにおける受信ポートバッファ構成のビューは、受信ポートにおける実際の現在のバッファ構成より遅れるので、これらの待ち時間を見込むために、追加のバッファ空間が設けられる。
【０１４９】
リンクが初期化された後、パケットがそのリンクを横断することができるようになる前に、各１方向リンクの両端の受信機及び送信機のピアを、受信機のバッファ編成及び受信機で実施される所望のクレジット編成を基準として、一致させる。上述のように、１実施形態では、バッファ編成情報は、ファブリックマネージャによって受信機及び送信機のピアに提供される。１実施形態では、クレジット編成は、受信機で実施され、対応するクレジット編成情報は、受信機からそのピア送信機に送信される。
【０１５０】
さらに詳細には、受信機で実施されるクレジット編成は、その受信機のクレジットＡＣＫのリターンに関連して利用されるバッファ割当て単位（ＡＵ）及びクレジットリターンＡＣＫ単位（ＣＵ）の両方を使用するものである。ＡＵは、受信機におけるバッファ割当てに使用される最小ブロックサイズである。クレジットＡＣＫ単位（ＣＵ）は、受信機によって戻される各クレジットによって表される受信機ＡＵの数である。１実施形態では、受信機は、それが使用しているＡＵ及びＣＵを指定する対応する変数ｖＡＵ及びｖＣＵを、そのピア送信機に送信する。１実施形態では、変数ｖＡＵ及びｖＣＵは、対数スケールを使用する。その例を、以下の表５及び表６に示す。
【０１５１】
図３０に示すように、受信機３００４ａ及び３００４ｂはそれぞれ、バッファ割当て単位変数（ｖＡＵ）及びクレジットＡＣＫ単位変数（ｖＣＵ）を含むクレジット編成情報を、それぞれの送信機３０００ａ及び３０００ｂに通信し、そこで、それらは、図３０に破線で示すように、クレジットマネージャ３００２ａ及び３００２ｂによって受信される。各送信機のクレジットマネージャには、その送信機のピア受信機によって実施されるバッファ編成を定義する情報も提供される。各送信機のクレジットマネージャ３０００は、そのピアの受信ポートから受信した現在利用可能なクレジットを把握しており、それに応じてそのピアへのパケットのフローを制御する。パケットが受信機３００４によって処理されるにつれて、バッファ空間が解放され、受信機は、実線で示すように、クレジットＡＣＫをその送信機ピアのクレジットマネージャ３００２に戻す。ファブリックの動作上の必要に基づいて、中央ファブリックマネージャが実行時動作中に様々なＶＬの間の相対的なクレジット割当てに変更を加えることもできる。
【０１５２】
クレジットマネージャが初期化された後で、クレジットマネージャは、受信側のバッファ空間の量のトラッキングを担う。１実施形態では、専用クレジット及び共有クレジットの配分は、表４に示す以下の１組の構成レジスタのセットを用いて構成される。これらのレジスタは、全て、ピアの割当て単位（ＡＵ）の値を単位としている。
【０１５３】
【表３】
0006297698.tif 000004
【０１５４】
Ｄｅｄｉｃａｔｅｄ＿Ｌｉｍｉｔ［ＶＬ］構成レジスタは、特定のＶＬのために受信機のバッファの専用部分を確保するために使用される。ＶＬ間でのＱｏＳ分離を保証するために、ファブリックマネージャは、アクティブな各ＶＬごとに何らかの専用空間を構成することが推奨される。
【０１５５】
Ｇｌｏｂａｌ＿Ｓｈａｒｅｄ＿Ｌｉｍｉｔ構成レジスタは、共有プール型編成で使用される。この構成レジスタは、受信機のバッファのどの程度が、全てのＶＬによって共有されるかを示す。専用限界及び大域共有限界の合計は、総バッファ空間を超えることはできない。さらに、大域共有空間が使用されない場合には、このレジスタの値は０に設定される。
【０１５６】
Ｓｈａｒｅｄ＿Ｌｉｍｉｔ［ＶＬ］構成レジスタは、共有空間のうち、個々のＶＬが消費することができる空間の量の限界を指定する。このレジスタが０に設定されると、その所与のＶＬは、共有空間にアクセスできなくなる。ファブリックマネージャは、個々のＶＬが共有空間をあまり多く消費しすぎないようにこのレジスタを構成することにより、１つのＶＬ上のトラフィックの輻輳又はバーストによって、他のＶＬが共有バッファ空間の不足に苦しむことを防止することができる。個々のＶＬについての限界は、Ｇｌｏｂａｌ＿Ｓｈａｒｅｄ＿Ｌｉｍｉｔを超えることはできないが、全てのＶＬの限界の合計は、Ｇｌｏｂａｌ＿Ｓｈａｒｅｄ＿Ｌｉｍｉｔを超えてもよい。例えば、Ｇｌｏｂａｌ＿Ｓｈａｒｅｄ＿Ｌｉｍｉｔを１０とし、４つのＶＬそれぞれのＳｈａｒｅｄ＿Ｌｉｍｉｔを５とすることは有効であり、この場合には、１つのＶＬが５単位以下の共有空間を使用することはない。
【０１５７】
送信機でクレジットを消費するときには、クレジットは、ＶＬの専用クレジットプールから先に消費される。所与のＶＬについて、全てのＶＬ専用クレジットが消費された後で、その所与のＶＬが利用できる共有プールから、クレジットが消費される。１つのパケットが、残りの専用クレジットより大きいときには、そのパケットは、専用プール及び共有プールの両方からクレジットを消費することができる。
【０１５８】
送信機においてクレジットを補充するときには、クレジットは、先に共有プールに補充される。所与のＶＬによって消費された全ての共有クレジットが補充された後で、その所与のＶＬの専用プールにクレジットが補充される。
【０１５９】
２ティア共有バッファ構成に適用される上記の内容は、３ティア共有バッファ構成にも拡張することができる。この場合には、クレジットは、所与のＶＬ、その後にその所与のＶＬを含むＶＬのサブセットの間で使用される共有プール、その後に大域共有プールという順序で消費される。補充は、逆方向に行われる。すなわち、大域共有プール、その後にＶＬのサブセットの間で使用される共有プール、最後に所与のＶＬの専用プールの順に行われる。
【０１６０】
パケットがリンクを介して流れることを可能にする変数の１つは、受信側で利用可能なバッファ空間の量である。上述のように、各送信機は、（１実施形態ではそのクレジットマネージャを介して）バッファ構成及びその受信機ピアの使用のビューを維持するが、これは、（部分的には）クレジットＡＣＫを使用することにより実施される。１実施形態では、各ＶＬのクレジットを管理するのは、クレジットマネージャの責任である。仮想カットスルーポリシーを用いるときには、パケットは、受信側バッファにパケット全体を受けるのに十分な利用可能な空間がない限り、アービトレーションのために完了することができない。ワームホール経路指定を使用するときには、パケットは、利用可能な空間が＞０であれば、アービトレーションのために完了する。ハイブリッドな手法では、フリットの「チャンク」は、受信機がそのチャンクを受信するのに十分なクレジットを有する場合には、送信することができる。この実施形態では、チャンクのサイズは構成可能であり、そのサイズは、リンクがアクティブである間に動的に再構成することができる。
【０１６１】
パケットがアービトレーションを得ると、その個別のＶＬのクレジットのプールから、又はそのＶＬに適用可能な共有プールから、いくつかのクレジットが割り当てられる。クレジットプールは、受信側からクレジットＡＣＫを受信したときに補充される。このクレジットＡＣＫは、受信側がそのバッファからフリットの特定の数を取り除くときに発生する。クレジットＡＣＫは、クレジットリターン（ＣｒｄＲｅｔ）ＬＦコマンドフリットに応じて、又はＬＴＰに含めて搬送される側波帯情報によって、戻される。クレジットＡＣＫに含まれる情報は、ＶＬ及び確認応答されたクレジットの数を含むが、以下で述べるように、単一のクレジットＬＦコマンドフリットが、複数のＶＬのクレジットＡＣＫを含むこともある。デバイスは、ＣｒｄＲｅｔＬＦコマンドフリットを介してクレジットリターンを受け入れる。１４ｂ  ＣＲＣ  ＬＴＰフォーマットを選択した場合には、デバイスは、ＬＴＰ側波帯情報も介して、クレジットリターンを受け入れる。１４ｂ  ＣＲＣ  ＬＴＰフォーマットを使用するときには、デバイスは、ＬＴＰ側波帯機構を使用してクレジットを戻さなければならないが、必要に応じて、ＣｒｄＲｅｔＬＦコマンドフリットを使用することもできる。
【０１６２】
図３０に示して上述したように、バッファ割当て単位変数（ｖＡＵ）及びクレジットリターンＡＣＫ単位変数（ｖＣＵ）は、リンクデータ転送動作が開始される前に（例えばＬＮＩプロセス中に）、近隣デバイス同士で交換される。１実施形態では、これらの変数は、以下の表５及び表６に示すように実装される。ここに示すように、ＡＵ及びＣＵは両方とも、対数スケールを使用する。
【０１６３】
【表４】
0006297698.tif 000005
【０１６４】
【表５】
0006297698.tif 000006
【０１６５】
リンクの両側の近隣デバイス同士が、ＬＮＩ中に異なる変数ｖＡＵ及び／又はｖＣＵを報告する場合には、１実施形態では、各ポートの送信機は、クレジットを管理するときに、その近隣デバイスのＡＵを使用する。さらに、各送信ポートは、イングレスクレジットＡＣＫを処理するときに、その近隣デバイスのＣＵを使用する。
【０１６６】
この状況の一例を、図３３に示す。図３３は、それぞれがｖＡＵ及びｖＣＵについて異なる値を有する２つの異なるデバイスタイプ（デバイスＡ及びデバイスＢなど）の一例を示す図である。この例では、デバイスＡは、ｖＡＵ＝４及びｖＣＵ＝１でブートする。ｖＡＵは、１２８Ｂ割当て単位用に設計されたデバイスＡの受信バッファ（Ｒｂｕｆ）のハードウェア設計と一致している。デバイスＢは、ｖＡＵ＝３及びｖＣＵ＝０でブートする。ここで、ｖＡＵは、６４Ｂ割当て単位用に設計されたデバイスＢのＲｂｕｆと一致している。ＬＮＩ中に、各デバイスは、そのｖＡＵ及びｖＣＵの変数を送信する。近隣デバイスのｖＡＵ及びｖＣＵを受信したら、各デバイスは、それ自体の送信機を、クレジットを管理するときに近隣デバイスのＡＵの値を使用し、近隣デバイスのＣＵの値を使用して近隣デバイスからのクレジットリターンを処理するようにプログラムする。一方、各デバイスの受信機（ＲＸ）及びクレジットリターン単位は、それ自体のＡＵ及びＣＵの値を使用する。
【０１６７】
１実施形態では、戻されたクレジット単位は、マルチビットフィールド及び対数スケールを使用して符号化される。戻されたクレジット単位（ＣＲ）の１つの符号化の一例を、以下の表７に示す。
【０１６８】
【表６】
0006297698.tif 000007
【０１６９】
確認応答されたクレジットの数を決定するアルゴリズムは、ＬＦ側波帯を使用するかＬＦコマンドフリットを使用するかに関わらず、同じである。違いは、ＬＦコマンドフリットを介してクレジットＡＣＫを戻すときに、ＶＬが暗示されることである。１実施形態による、増分クレジットＡＣＫのＬＦコマンドフリットフォーマット３２００の一例を、図３２に示す。図示のように、下位の６バイトは、１６個の３ビットフィールドに区分され、各３ビットフィールドは、（ビット５５の乗数「ｉ」と組み合わせて考慮した場合に）それらが関連付けられているＶＬを識別するオフセット（ビット０に対する）を有する。例えば、「ｉ」が０である場合には、ＬＦコマンドフリットフォーマット３２００を利用して、ＶＬ０〜１５のリターンクレジットを指定することができるが、「ｉ」が１である場合には、ＶＬ１６〜３１のリターンクレジットが指定される。対数スケールを使用することにより、３ビットで、クレジット値０、１、２、４、８、１６、３２及び６４を符号化することができる。したがって、３２個のＶＬを有するシステムでは、全てのＶＬのクレジットを、１６バイトしか使用せずに戻すことができる。
【０１７０】
表８は、ｖＡＵ＝３（ＡＵ＝６４）及びｖＣＵ＝０（ＣＵ＝１）であるときに戻されるクレジットの一例を示している。戻される総クレジットは、ＣＲ＊ＡＵ＊ＣＵである。ここで、ＣＲは、クレジットの数であり、ＡＵは、割当て単位のサイズであり、ＣＵは、クレジット単位の値である。６４バイトのＡＵでは、符号「１１１」で、４０９６バイトのクレジットが戻されていることを指定する。
【０１７１】
【表７】
0006297698.tif 000008
【０１７２】
このアーキテクチャのクレジットに基づくフロー制御機構は、従来の手法に優る有意な利点を提供する。例えば、ファブリックの効率の観点から、この機構は、１６個のＶＬのクレジットを、単一の８バイトメッセージで戻すことを可能にする。各ＶＬのクレジットは、３ビットしか必要とせず、０から１２８クレジット交換単位が戻されることを示すことができる。さらに、クレジット交換単位の合図は、構成可能である。これに対して、ＩｎｆｉｎｉＢａｎｄなどのファブリックでは、それに匹敵する量のクレジットを交換するために、１２８バイト（１６個の８バイトメッセージ）を必要とすることになる。
【０１７３】
クレジットトラッキングを送信機に行わせることにより、利用可能なクレジットの再割り付けは、単に送信機でカウンタを調節することによって行うことができる。送信機は、クレジットが戻されるときに、それらのクレジットを異なるＶＬに再割り付けすることもできる。この柔軟性により、アプリケーションの必要、ＱｏＳ要件、及びその他のファブリック上のワークロードの変化に応答して、ＶＬの性能を調整することができる。これに対して、絶対的なクレジットを使用する従来の解決策は、トラフィックを休止させ、送信機と受信機の間の変化を調整することなく、高い信頼性でクレジットを動かすことはできない。
【０１７４】
ＶＬアービトレーション
各エグレスポートは、異なるＶＬのパケットを出力リンクに向かって送信するために使用されるアービトレーションを提供する。初期化中にファブリックマネージャによってプログラムされるＶＬアービトレーションテーブルは、このアービトレーションプロセスを規制するための１組の規則を含む。これらの規則は、各ＶＬの帯域幅の量を規制し、ＶＬ間のプリエンプションの優先順位も定義する。
【０１７５】
ＶＬの優先順位及びスケジューリングは、送信機によって決まるので、このアーキテクチャの様々な実施態様は、相互運用性に影響を及ぼすことなく、この機能に大幅に異なるアーキテクチャを提供することができる。例えば、本明細書に開示する実施形態の他に、ＶＬの使用についてさらに大きな制御及び改善されたスケジューリングを行うことを可能にする、さらに強力で柔軟な機構が定義されることが考えられる。
【０１７６】
このアーキテクチャは、リンクレベルの再試行及びプリエンプションなどの機能をサポートする。これらの機能は、パケットフロー中に「バブル」を引き起こす可能性がある（パケット断片化）。（例えば以前のプリエンプション、リンク再試行などによって）現在のＶＬに関連するパケットバブルがあり、現在のＶＬをプリエンプトすることができるＶＬについては待ち行列に入っている他のパケットがない場合には、ＶＬパケットデータの代わりに遊休がフローに挿入される。デバイスのエグレスポートでは、流れているＶＬは、プリエンプトＶＬとして指定されているＶＬが待ち行列に入っているパケットを有さない限り、中断されない。
【０１７７】
図３４は、プリエンプションをサポートするＶＬアービトレーション機構３４００の１実施形態を示す図である。この機構は、ＶＬアービトレーションテーブル３４０２と、プリエンプション構成レジスタ３４０３と、プリエンプションマトリクス３４０４と、遠隔デバイスのＶＬごとのクレジット３４０６と、ＶＬごとのエグレスＦＩＦＯ３４０８と、送信パケットアービトレーション論理３４１０とを含む。ＶＬアービトレーションテーブル３４０２は、低優先順位テーブル３４１２と、高優先順位テーブル３４１４と、プリエンプションテーブル３４１６と、高優先順位限界ブロック３４１８と、プリエンプト限界ブロック３４２０とを含む。
【０１７８】
１実施形態では、３レベルアービトレーション方式を、データＶＬに使用する。プリエンプトＶＬは、他のプリエンプトＶＬの間で重み付き公平ラウンドロビンを利用し、残りの２つの優先順位レベルより優先される。これらの残りのＶＬは、最低レベルの優先順位を占め、以下のように定義される。つまり、残りのＶＬについては、重み付き公平方式の最上部に積層された２重レベルスケジューリングを用いて、２レベル方式が利用される。さらに、この方式は、優先順位の低いＶＬの順方向進行を補償する方法を提供する。１実施形態では、重み付け、優先順位付け、及び最小順方向進行帯域幅は、ファブリックマネージャによってプログラム可能である。
【０１７９】
ＶＬアービトレーションは、ＶＬアービトレーションテーブル３４０２によって制御される。図示の実施形態では、このテーブルは、５つの構成要素、すなわちプリエンプトテーブル３４１６、高優先順位テーブル３４１４、低優先順位テーブル３４１２、プリエンプト限界ブロック３４２０、及び高優先順位限界ブロック３４１８からなる。プリエンプトテーブル３４１６、高優先順位テーブル３４１４及び低優先順位テーブル３４１２はそれぞれ、ＶＬ／重み対のリストを含む。１実施形態では、プリエンプションリストは、最小の長さが１、最大の長さが３２であり、高優先順位リストは、最小の長さが１であり、最大の長さが１２８であり、低優先順位リストは、最小の長さがサポートされるデータＶＬの数と等しく、最大の長さが１２８である。高優先順位テーブルリスト及び低優先順位テーブルリストは、異なる長さにすることができる。各リストエントリは、ＶＬ番号（０〜３１の値）と、重み付け値（０〜２５５の値）とを含み、アービトレーションサイクル中にそのＶＬの順番が回ってきたときにそのＶＬから伝送することができる６４バイト単位の数を示す。パケットヘッダ中の長さフィールドを使用して、パケット中の単位の数を決定する。１実施形態では、この計算は、４バイトの増分に維持されるが、他の実施形態では、８バイト及び１６バイトなど、その他の細分性を利用することもできる。重み０は、このエントリをスキップすべきであることを示している。
【０１８０】
プリエンプトテーブルリスト、高優先順位テーブルリスト及び／又は低優先順位テーブルリスト並びに２つ又は３つ全てのリストでは、同じデータＶＬを複数回リストすることもできる。構成されたデータＶＬは、これらのテーブルのうちの少なくとも１つにリストされなければならない。例えば、１実施形態では、低優先順位テーブル３４１２は、各データＶＬが少なくとも１つのエントリを有することができるようなサイズになっている。構成されたデータＶＬがどのリストにもリストされていない場合には、このデータＶＬのパケットを直ちにドロップすることもできるし、アービタが送信すべきパケットを有していなければ送信することもできるし、送信しないこともできる。プリエンプト限界ブロック３４２０及び高優先順位限界ブロック３４１８は、それぞれ、高優先順位パケット又は低優先順位パケットを送信する機会がなくても伝送することができるプリエンプトパケット又は高優先順位パケットのバイト数を示す。１実施形態では、バイト数は、限界値（限界フィールドに記憶された値）に１６バイト、３２バイト、６４バイトなどの複数バイトを乗算した値である。１実施形態では、カウントは、重みについて上述したのと同様の方法で行われる（例えば、この計算は、４バイトの増分に行われ、プリエンプト／高優先順位パケットは、現在のバイトカウントがプリエンプト限界／高優先順位限界の値を超えていない場合に送信することができる）。１実施形態では、各限界フィールドは、１４ビットのサイズであるが、その他のサイズを使用することもできる。１４ビットフィールドを利用する実施形態では、最大値１６３８３は、バイト限界が無限であることを示す。（無限のバイト限界では、低優先順位パケットの順方向進行がこのアービトレーション方式では保証されないことに留意されたい。）１実施形態では、プリエンプト／高優先順位限界値０は、それぞれ高優先順位／低優先順位テーブルに機会が与えられる前に、プリエンプト／高優先順位テーブルのパケットを１つしか送信することができないことを示している。
【０１８１】
１実施形態では、ＶＬアービトレーションテーブル３４０２ａは、ポートがアクティブであるときに修正することができる。さらに、このような修正は、移行中の任意のパケットの断片化を生じない。ただし、この変更中には、アービトレーション規則は保証されない。
【０１８２】
プリエンプションマトリクス３４０４は、どのＶＬが他のＶＬをプリエンプトすることができるかについての規則を提供する、柔軟な制御機構をサポートする。１実施形態では、ＶＬ１５が、ファブリック管理用に確保されており、別のＶＬによってプリエンプトすることができない。１実施形態では、このマトリクスは、最大Ｎ個のデータＶＬをサポートする（Ｎ＋１）ｘＮ構造であり、ＶＬ１５は、最大Ｎ個のデータＶＬをプリエンプトする。必要に応じて、プリエンプトすることができないＶＬが予め定義されていない場合には、ＮｘＮマトリクスを使用することができる。好ましくは、所与の実施態様で、その実施態様がサポートしているデータＶＬの最大数に基づいて、プリエンプションマトリクスをサイジングするものとする。どのＶＬがプリエンプトを行うことができるかを制御するために、行ごとに１つ又は複数のビットをアサート（「１」）する。図３５は、４個のデータＶＬを有する例示的なデバイスの場合の５ｘ４プリエンプションマトリクス３５００を示す図である。
【０１８３】
それ自体をプリエンプトするＶＬについてのプリエンプションマトリクス中のエントリは、無視する。プリエンプションマトリクス３５００については、プリエンプション規則は、以下の通りである。
・ＶＬ３は、ＶＬ２、ＶＬ１及びＶＬ０をプリエンプトすることができる。
・ＶＬ２は、ＶＬ１及びＶＬ０をプリエンプトすることができる。
・ＶＬ１は、ＶＬ２及びＶＬ０をプリエンプトすることができる。
【０１８４】
各優先順位テーブル内で、重み付き公平アービトレーションを使用する。各テーブル中のエントリの順序は、ＶＬスケジューリングの順序を指定し、重み付け値は、そのエントリに割り当てられる帯域幅の量を指定している。アービトレーションは、テーブル中の各エントリが順番に処理される、サイクルに基づくものである。
【０１８５】
「現在の」重み以外の各優先順位テーブル内のエントリの残りの重み、及び優先レベル間の遷移があるときに保存されるＶＬのための記憶領域はない。これにより、プリエンプトの現在の重み／ＶＬ、高い現在の重み／ＶＬ、及び低い現在の重み／ＶＬという、３組の残りの重み及び保存されたＶＬの値が得られる。優先レベル間の遷移がある場合には、現在の値が中断されて保存され、新たな優先レベルに遷移し、新たな現在の重み／ＶＬの値がロードされた後で、アービトレーションサイクルに入る。元の優先レベルに遷移して戻ると、保存された現在の重み及びＶＬがリロードされ、アービトレーションは中断したところから再開される。
【０１８６】
これら３つのテーブルのそれぞれについて、別個のポインタ及び利用可能重みカウントのテーブルが維持される。これらのポインタは、テーブル中の現在のエントリを識別し、利用可能な重みカウントは、データパケット伝送に利用可能な、現在のエントリが有する重みの量を示す。テーブルがアクティブであるときには、そのテーブル中の現在のエントリを検査する。以下の条件が全て真である場合には、このエントリに対応するパケットが、伝送のために出力ポートに送られ、パケットサイズ（４バイトずつ増分される）が、現在のエントリの利用可能な重みカウントから推測される。その条件とは、
１．リストエントリの利用可能な重みが正である。
２．そのエントリのＶＬに利用可能なパケットがある。
３．このパケットについて、バッファクレジットが利用可能である。
【０１８７】
なお、新たなパケットの開始時の利用可能な重みが正である場合には、そのパケットが利用可能な重みより大きい場合でも、上記の条件１は満たされる。
【０１８８】
これらの条件のうちのいずれかが真でないときには、テーブル中の次のエントリを検査する。現在のポインタは、テーブル中の次のエントリに移動し、利用可能な重みカウントがこの新たなエントリの重み付け値に設定され、上記のテストが繰り返される。これは、伝送するためにそのポートに送ることができるパケットが見つかるまで繰り返される。テーブル全体をチェックしても、上記の基準を満たすエントリが見つからない場合には、次の低優先順位テーブルがアクティブになる。
【０１８９】
サービス品質（ＱｏＳ）
このアーキテクチャは、
・ジョブ分離／資源割当て、
・サービス分離／資源割当て、
・所与のジョブ内のアプリケーショントラフィック分離、
・プロトコル（例えば要求／応答）のデッドロック回避、
・ファブリックのデッドロック回避、
・トラフィック優先順位付け及び帯域幅割当て、及び
・トラフィックのプリエンプションを許可することによる待ち時間ジッタ最適化、
など、いくつかの機能を提供するＱｏＳフィーチャをサポートする。
【０１９０】
このアーキテクチャは、仮想ファブリック（ｖＦａｂｒｉｃ）、トラフィッククラス（ＴＣｓ）、サービスレベル（ＳＬｓ）、サービスチャネル（ＳＣｓ）及び仮想レーン（ＶＬｓ）を介して、ＱｏＳの非常に柔軟な機能を提供する。ＱｏＳの中心には、ファブリック内のパケットを区別するために使用されるＳＣ機構がある。１実施形態では、幅広く様々なファブリックのトポロジ及び構成をサポートするために、ＳＣ割り付けは、ファブリックマネージャによって管理され、所与のパケットのＳＣは、それがファブリックを横断する際に、デッドロックを回避することができるように変化することができる。
【０１９１】
アプリケーション及びシステムアドミニストレータの動作は、ｖＦａｂｒｉｃを中心にしている。ｖＦａｂｒｉｃは、１組のファブリックポートと１つ又は複数のアプリケーションプロトコルの交差点である。各ｖＦａｂｒｉｃごとに、１組のＱｏＳ及びセキュリティポリシーが、システムアドミニストレータによって確立される。所与のｖＦａｂｒｉｃは、ＱｏＳのトラフィッククラス及びセキュリティのためのパーティションと関連付けられる。
【０１９２】
トラフィッククラスは、所与のトランスポートレイヤ又はアプリケーションが使用する一群のサービスレベルのグループを表す。一部のトランスポートレイヤは、デッドロックを回避するために複数のＱｏＳレベルを使用することができる（要求トラフィックと応答トラフィックを分離するなど）が、一部のトランスポートレイヤは、優先順位の高い制御トラフィックを優先順位の低いデータトラフィックから分離するために複数のＱｏＳレベルを利用することができる。より単純なトランスポートレイヤであれば、単純に、トラフィッククラスを１つのＳＬと関連付けることができる。１実施形態では、このアーキテクチャは、最大で３２個のトラフィッククラスをサポートするが、４個から８個が、より可能性の高い代表的な構成である。
【０１９３】
トラフィッククラスは、サービスレベルのエンドツーエンドの概念によって実現する。１実施形態では、トラフィッククラスは、複数のサービスレベルにまたがることができるが、１つのサービスレベルは、１つのトラフィッククラスにしか割り付けることができない。１実施形態では、最大で３２個のサービスレベルがサポートされる。サービスレベルは、ファブリックを通るパケットフローに優先順位付けすることによって機能する。サービスレベルは、アーキテクチャのレイヤ４のプロトコル及びアプリケーションに見える最下位層のＱｏＳ概念である。
【０１９４】
その下にあるサービスレベルが、異なるサービスレベルのパケットを、それらがファブリックを通過するときに区別する、サービスチャネル（ＳＣ）である。ＳＣは、ファブリックパケットに含まれる唯一のＱｏＳ識別子であるので、他のネットワークより密なパケットフォーマットを可能にする。いくつかのファブリックトポロジでは、サービスレベルは、複数のサービスチャネルにまたがることができるが、サービスチャネルは、１つのサービスレベルにしか割り付けることができない。１実施形態では、このアーキテクチャは、３２個のＳＣをサポートする。１実施形態では、ＳＣのうちの１つ又は複数は、帯域内ファブリック管理の専用である。
【０１９５】
１実施形態では、ファブリックマネージャは、各エンドポイントに、各サービスレベルから単一のＳＣへのマッピングを提供するＳＬ２ＳＣテーブルを構成する。ある点では、ＳＬは、ＱｏＳレベルのカノニカルなＩＤであり、各ＱｏＳレベルが、ファブリック幅にわたって正確に１つのＳＬ値を有するようになっている。ＳＬ２ＳＣテーブルの目的は、トポロジを経路指定するためにいくつのＳＣが必要であるか、並びにその経路指定の正確な割り付け及び有効なランチＳＣはどんなものであるかについての詳細を、トランスポートレイヤから隠すことである。さらに複雑な構成では、所与のＱｏＳレベルに対して使用する有効なランチＳＣは、送信者ごとに変化する可能性もあるが、全ての送信者が依然として、ＱｏＳレベルについて同じカノニカルＩＤを有することができる。いくつかのＡＰＩ（オープンファブリック及びＰＳＭなど）は、明示的にＳＩを必要とすることもある。
【０１９６】
いくつかの受信機は、所与のパケットがどのＱｏＳレベルで受信されたかを識別する必要があることがある。このような受信機では、ＳＣ／ＳＬテーブルも、各エンドポイントで構成される。このテーブルは、カノニカルな翻訳を提供し、複数のＳＣを使用する経路指定アルゴリズムの複雑化を解消する。
【０１９７】
受信機は、受信したＱｏＳレベルを完全に無視してもよいし、それをＡＰＩ（オープンファブリックなど）に渡してもよいし、それを検証してもよいし（何らかのＳＬＡ検証などのため）、或いはさらに洗練された処理（ＱｏＳレベルを使用してゲートウェイにおけるＥ番目の優先レベルの選択を助けるなど）を行ってもよい。いくつかの受信機は、受信パケット中のＱｏＳレベルを使用して、適当な応答を生成することができる。例えば、１つの簡単なサービスが、応答としてＱｏＳレベルを模倣する（そして上記の送信側処理を行ってその応答のための適当なランチＳＣを保証する）こともできる。他の受信機は、応答パケットを、同じトラフィッククラスの中で異なるＱｏＳレベルにすることもできる。いずれの場合も、受信したときと同じＳＣを使用して単純に応答パケットを送信することは、経路指定のアルゴリズム及びトポロジによっては問題を生じる恐れがあるので、有効ではない。したがって、この問題を取り除くためのカノニカルなマッピングがある。
【０１９８】
図４４は、クレジットループ回避を備えたトポロジにおけるＴＣ、ＳＬ及びＳＣの使用の一例を示す図である。この例では、ファブリックを通る２つのＨＦＩエンドポイントが、８スイッチホップ経路を介して接続される。２つのＴＣが使用され、１つは、２つのＳＬ（要求ＳＬ及び応答ＳＬ：ＳＬ０、ＳＬ１）を必要とするＰＧＡＳ用（ＴＣ０）であり、１つは、１つのＳＬ（ＳＬ２）しか必要としない記憶用（ＴＣ１）である。各ＳＬは、ファブリック内のデッドロック回避のために１対のＳＣ（ＳＣ０／ＳＣ１、ＳＣ２／ＳＣ３、又はＳＣ４／ＳＣ５）に割り付けられる。パケットがファブリックを横断するときに、ＳＣは、リンクごとに変化する可能性があるが、レイヤ４及びアプリケーションから見えるＳＬ及びＴＣは、エンドツーエンドで一貫している。
【０１９９】
所与のリンク内で、サービスチャネルは、仮想レーン（ＶＬ）に割り付けられる。ＶＬは、入来するファブリックパケットに専用の受信バッファを提供する。ＶＬは、経路指定デッドロックを解決するためにも使用される。１実施形態では、このアーキテクチャは、最大で３２個のＶＬをサポートするが、実際にサポートされる数は、一般に実施態様によって決まる。このアーキテクチャは、ＳＣのＶＬへのマッピングをサポートして、異種ファブリック構成をサポートすることができるようにしている。個々の実施態様は、３２個未満のＶＬをサポートすることを選択することもできるし、利用可能なＶＬの全体数を減少させることによってＶＬ当たりのバッファリングの量を最適化するように構成することもできる。
【０２００】
複数のサービスチャネルを独立した複数のＶＬにマッピングすることによって、ＳＣは、ファブリック内の独立したチャネルを提供して、１つのＳＣ内のコンテンション及びブロッキングによって、異なるＳＣのトラフィックの進行が妨げられないことを保証することができる。サービスチャネルを使用して、経路指定及びプロトコルのデッドロックを回避し、トラフィッククラス間のヘッドオブラインブロッキングを回避する。
【０２０１】
各ＳＣは、１つのトラフィッククラスの１つのサービスレベルのトラフィックを搬送する。ファブリックマネージャは、各エグレスポートにおいて、同じポートを使用している可能性がある複数のＳＣの間でＶＬ資源がどのように分割又は共有されるかを設定する。ＦＭは、以下のようなＳＣの所望のＱｏＳ特性を使用して、そのＳＣに割り付けられたＶＬの適当な設定を選択する。
・仮想レーンを介したパケットの伝送は、複数のＶＬが所与のリンクについて待ち行列に入っているトラフィックを有するときにそのリンクをどのように共有してスケジューリングするかをファブリックマネージャが構成することを可能にする、構成可能なＶＬアービトレーションアルゴリズムを介してスケジューリングされる。
・パケットのプリエンプションは、優先順位の高いトラフィックが優先順位の低いパケットをプリエンプトできるようにすることができる。これにより、優先順位の高いトラフィックのヘッドオブラインブロッキングがさらに削減される。
・ＶＬのクレジットリターンレートを設定することによって利用可能な出力ポートの帯域幅を共有する。
・ポートごとの構成可能なＶＬバッファリングにして、各スイッチホップで許される待ち行列の深さをＶＬごとに制御できるようにする。
【０２０２】
このファブリックのアーキテクチャは、複数のデバイスの混合体が様々な数のＶＬをサポートする異質環境の実施を容易にする。例としては、限られた数のＶＬをサポートすることによってバッファ空間を保存するスイッチ、ファブリック内のトポロジデッドロックを回避するための余分のＶＬを必要としないＨＦＩエンドポイント、又は限られた数のＶＬについてのみ大量のバッファリングを実現することによって超長リンクをサポートするいくつかの特殊デバイスなどが挙げられる。
【０２０３】
例示的な異質環境を、図３６に示す。図示のように、スイッチ、ＨＦＩ、ゲートウェイ、及びファブリックインタフェースを有する記憶装置などの相互接続された構成要素を実装して、異なる数の仮想レーンをサポートすることができる。ＶＬ／ＶＬアップマッピングかＶＬ／ＶＬダウンマッピングかは、どちらの構成要素の方がＶＬの数が多いかによって決まる。
【０２０４】
一般に、ＦＰフォーマットが、いくつかのＩｎｆｉｎｉＢａｎｄフォーマットなど他のプロトコルとの相互運用性をサポートするためのものなどのＳＬフィールドを含む場合もあるが、サービスレベル（ＳＬ）は、Ｌ２リンクファブリックパケットフォーマットの別個のフィールドで明示的に識別する必要はない。その代わりに、このＱｏＳ情報は、ファブリックパケットのＳＣフィールドによって暗示される。１実施形態では、このＱｏＳレベルは、各パケットがエンドツーエンドでファブリックを横断するときに、ＳＣ／ＳＣマッピングによって保存される。異種ファブリックでは、全てのトラフィックが異なる機能を有するデバイスによってサポートされる最低限の共通するＶＬを通って進行することを要求することによってファブリック全体を制限する代わりに、このアーキテクチャは、ヘッドオブラインブロッキング可能性を低下させる助けとなるようにパケットがＶＬ資源の利用を拡大及び縮小することを可能にし、同時に暗示されたＳＬ情報を保存する方法を提供する。
【０２０５】
図３７は、１実施形態による、ＨＦＩのＬ４レイヤによるパケットのファブリックへの注入の一例を示す図である。ＨＦＩのＬ４レイヤがファブリックにパケットを注入するときには、ＨＦＩのＬ４レイヤは、最初に、ＳＬ／ＳＣマッピング３７００によってＬ４インタフェースから提供されたＳＬを初期ＳＣにマッピングし（動作「Ａ」で示される）、パケットのＳＣフィールドにこの値を設定する。生成されたＳＣの値は、ＳＬと、ファブリックのトポロジに関する情報との両方を埋め込むことができる。次いで、動作「Ｂ」で、ＳＣに、このパケットを伝送する出力ＶＬ資源を選択するために、ＳＣ／ＶＬｔマッピング３７０２を施す。出力資源とは、通常は、出力ＦＩＦＯと、それと関連するクレジットマネージャとを指す。図３７では、例示を目的として、４つのＶＬ  ＦＩＦＯ３７０４があるが、実際のＦＩＦＯの数は、デバイスがサポートする仮想レーンの数によって決まる。さらに、この出力ステージにおけるＳＣ／ＶＬｔマッピング３７０２は、そのローカルデバイスがサポートするＶＬの数によって決まるだけでなく、遠隔のデバイスがサポートするＶＬの数によっても決まる。動作「Ｃ」に示すように、クレジットは、遠隔の受信側デバイスによって、このローカルなデバイスのＶＬｔに基づいて確認応答され、対応するカウンタが増分される。ＳＬがどのようにＳＣにマッピングされるか、ＳＣがどのようにＶＬｔにマッピングされるか、及びクレジットがどのようにＶＬｔを用いてマッピングされるかについての詳細については、以下でさらに詳細に説明する。
【０２０６】
入来パケットのＳＣフィールドに埋め込まれたＱｏＳレベルを保存しながら、同時にＶＬ資源の使用を最大限に高めるために、各スイッチは、入力資源及び出力資源の両方を選択するためのマッピングをパイプラインで実行する。スイッチ３８００の選択的な詳細を示す例示的な実施形態を、図３８に示す。各スイッチは、複数の入力ポート３８０２及び出力ポート３８０４を含み、入力ポートの出力は、クロスバー相互接続３８０６によって出力ポートの入力に結合されている。入力ポート３８０２は、転送経路指定テーブル３８０８、ＳＣ／ＳＣマッピングテーブル３８１０など、様々な入力ポート動作を実行する回路及び論理を含む。各入力ポートは、デマルチプレクサ（ｄｅｍｕｘ）３８１４及びマルチプレクサ（ｍｕｘ）３８１６の動作を実施する関連する回路及び論理を有する複数のＶＬ入力ＦＩＦＯ３８１２も含む。出力ポート３８０４は、ｄｅｍｕｘ３８１５及びｍｕｘ３８１７の動作を実施する関連する回路及び論理を有する複数のＶＬ出力ＦＩＦＯ３８１３を含む。
【０２０７】
図３８に示すように、パケット３８１８が入来すると、パケット３８１８は、（動作「Ｄ」で）ＳＣ／ＶＬｔマッピング３８２０を通過して、このパケットを受け入れる入力ＶＬ資源のうちの１つを選択する。入力資源とは、通常は、入力ステージにおけるＶＬに特定のＦＩＦＯを指す。このマッピングは、以下でさらに詳細に説明するように、このローカルデバイスがサポートするＶＬの数によって決まる。１実施形態では、入力ステージにおいて各ＶＬごとに別個の資源がないので、ＳＣ／ＶＬｔマッピング３８２０は不要である。平行して、転送経路指定テーブル３８０８が、動作「Ｅ」で示すように、パケット３８１８の宛先ローカル識別子（ＤＬＩＤ）を使用して、このパケットの出力ポートを決定する。経路指定判定の結果及びパケットのＳＣに応じて、ＳＣ／ＳＣマッピングテーブル３８１０に基づいて、新たな既存のＳＣ’が決定される。Ｆａｔ−Ｔｒｅｅなどのトポロジでは、この新たなＳＣ’は、通常は、元のＳＣと同じである。Ｔｏｒｕｓなどのトポロジでは、この新たなＳＣ’は、出力ポートがたまたま「デートライン」と交差した場合のデッドロックの可能性を防止するための、元のＳＣの増分とすることができる。パケットのＳＣフィールドは、この新たなＳＣ’で置換される。次いで、この新たなＳＣ’は、動作「Ｆ」で、別の出力ポートに特有のＳＣ／ＶＬｔマッピング３８２２を通過して、パケット３８１８を伝送するための宛先ポートにおける出力資源を選択するためのエグレスＶＬｔを導出する。この出力資源を選択するためのマッピングは、以下で説明するように、ローカルデバイスがサポートするＶＬの数によって決まるだけでなく、遠隔デバイスがサポートするＶＬの数によって決まることもある。
【０２０８】
パケットが特定のＶＬ入力ＦＩＦＯ３８１２から引き出されるときに、このＶＬを用いてクレジットを送信機に対して確認応答する代わりに、スイッチは、送信端部からのクレジット管理に一致するように、送信側デバイスのＶＬすなわちＶＬｎｔに基づいてクレジットを確認応答する。これは、動作「Ｈ」により、入力ＦＩＦＯから引き出されているパケットのＳＣをマッピングし、ＳＣを送信側のＶＬに基づいてファブリックマネージャによってプログラムされたＳＣ／ＶＬｎｔテーブル３８２４によってマッピングすることによって実現する。同様に、イングレスパケット及びイングレスＶＬＭａｒｋｅｒ  ＬＦコマンドフリットを処理するときには、ＳＣ／ＶＬｎｔテーブル３８２４を使用して、送信機によって定義される各パケットのＶＬインタリーブを適切にトラッキングするためにインバウンドＳＣ値をマッピングする。このローカルデバイス及び送信デバイスが同数のＶＬをサポートする場合には、動作「Ｄ」及び「Ｈ」の両方のマッピングテーブルも同じになる。動作「Ｇ」に示すように、出力ポートでは、クレジットがこのローカルデバイスのＶＬに基づいて遠隔の受信側デバイスによって確認応答され、対応するクレジットカウンタが増分される。
【０２０９】
図３９に示すように、パケットがＨＦＩ３９００に到着すると、ＳＣは、動作「Ｉ」で第１のＳＣ／ＶＬｔマッピング３９０２を通過して、このパケットを受信するための入力資源のうちの１つを選択するためのＶＬを生成する。このマッピングは、スイッチの入力ステージのマッピング（図３８の動作「Ｄ」）と非常に似ている。入力ステージで各ＶＬごとに別個の資源を有していない実施態様では、動作「Ｉ」におけるこのマッピングは、不要である。動作「Ｊ」における第２のステージのＳＣ／ＳＬマッピング３９０４で、ＳＣ値を復号し、この値をこのパケットの元のＳＬにマッピングした後で、これをＬ４レイヤに戻す。動作「Ｋ」に示すように、パケットが特定のＶＬ入力ＦＩＦＯ３９０６から引き出されるときに、クレジットは、スイッチの場合と同様に（図３８の動作「Ｈ」と同様）、送信側デバイスのＶＬｎｔに基づいて送信機に対して確認応答される。同様に、イングレスパケット及びイングレスＶＬＭａｒｋｅｒ  ＬＦコマンドフリットを処理するときには、ＳＣ／ＶＬｎｔテーブル３９０８を使用して、送信機によって定義される各パケットのＶＬインタリーブを適切にトラッキングするためにインバウンドＳＣ値をマッピングする。
【０２１０】
ＨＦＩによってパケットをファブリックに注入するときには、初期ＳＣ値を生成するために、Ｌ４レイヤがＳＬを提供する。１実施形態では、このアーキテクチャは、３２個のＱｏＳレベル及び３２個のＳＣをサポートし、このマッピングプロセスは、ソフトウェアで、又はＨＦＩ内部で、行うことができる。ファブリックのトポロジによっては、ファブリック内のデッドロックを回避するために、ＱｏＳレベル当たり複数のＳＣが必要になることもある。一例として、Ｔｏｒｕｓトポロジの場合には、各ＱｏＳレベルは、パケットが「デートライン」と交差する場合をカバーするために２つのＳＣを必要とすることになる。この場合には、１６個のＳＬが、ＱｏＳレベルを搬送するだけでなく、所与のトポロジ内のデッドロックを防止するための適当なＳＣ設定を提供する、３２ＳＣ空間にマッピングされることになる。残りの１６個のＳＬは、Ｌ４が使用しなくてもよいし、或いは３２個のＳＣに冗長的にマッピングしてもよい。ＱｏＳレベル当たり１つしかＳＣが必要でないＦａｔ−Ｔｒｅｅなどのトポロジでは、３２個のＳＬは、３２個のＳＣに一対一でマッピングされる。
【０２１１】
一般に、実際のＳＬ／ＳＣマッピングの値は、それがファブリックトポロジのデッドロック回避規則に準拠する限り、ソフトウェア次第である。
【０２１２】
ＨＦＩへの入来パケットのＳＣは、ＳＬにマッピングされる。この逆マッピングプロセスは、ソフトウェアで、又はＨＦＩ内部で、行うことができる。デッドロック回避のために、ＱｏＳレベル当たり複数のＳＣを使用するトポロジでは、１実施形態では、これらのＳＣは、アプリケーションがパケットを処理するために使用する可能性がある単一のＳＬ値につぶされる。一例を挙げると、Ｔｏｒｕｓファブリックでは、各ＱｏＳレベルごとに２つのＳＣを使用してトポロジのデッドロックを防止するので、３２個のＳＣが１６個のＳＬ値にダウンマッピングされる。ここのＬ４は、提供されたＳＬを無視することを選択してもよいし、それを使用して応答トラフィックで使用するＳＬを選択してもよいし、或いは与えられたＳＬ値に基づいて追加のＬ４検証又はＬ４トラフィック分離を実行してもよい。
【０２１３】
パケットがスイッチに入来した後で、転送経路指定テーブルによって経路指定判定を行って、そのパケットがどの出力ポートに送達されるかを判定する。ＳＣがエンドツーエンドで持続するＦａｔ−Ｔｒｅｅなどのトポロジでは、ＳＣは、ＳＣがどの出力ポートをとるかに関わらず、不変のままである。ただし、Ｔｏｒｕｓなど、特定のトポロジでは、デッドロックを回避するために出力ポートが「デートライン」とたまたま交差した場合に、入来パケットのＳＣを増分する必要がある。したがって、イングレスＳＣ及び出力ポートに基づいてエグレスＳＣ’を生成するために、ＳＣ／ＳＣマッピングテーブル（図３８のＳＣ／ＳＣマッピングテーブル３８１０など）が設けられる。次いで、デッドロックを防止するために、入来パケットのＳＣフィールドを、この新たなＳＣ’で置換する。出力ポートでこのパケットを送出するための出力資源を選択するときには、図３８の動作「Ｆ」に示すように、ＶＬ選択は、この新たなＳＣ’に基づく。
【０２１４】
ＳＣ／ＶＬマッピングは、パケットが入来するときに入力資源を選択するために実施され、パケットが出て行くための出力資源を選択するには別のマッピングが必要である。ＨＦＩにおいて（図３７の動作「Ｂ」）出力資源を選択するためのマッピング機構と、スイッチにおいて（図３８の動作「Ｆ」）出力資源を選択するためのマッピング機構とは同じであり、ＨＦＩにおいて（図３９の動作「Ｉ」）入力資源を選択するためのマッピング機構と、スイッチにおいて（図３８の動作「Ｄ」）入力資源を選択するためのマッピング機構とは等価である。最大数の３２個のＶＬをサポートするデバイスでは、入力資源を選択するためのマッピングは、省略することができる。出力資源を選択するためのマッピングは、近隣デバイスの能力によって決まるので、依然として必要である。
【０２１５】
ファブリック内の全てのデバイスが同数のＶＬをサポートする同質環境では、全てのＳＣ／ＶＬマッピングを、単純に３２個のＳＣを利用可能なＶＬにダウンマッピングするように、同じように設定することができる。デバイスによって異なる数のＶＬをサポートする異質環境では、ＳＣ／ＶＬ機構は、マッピングが「拡大」か「縮小」かによって異なる。以下、これら２つの概念について説明する。
【０２１６】
拡大マッピングとは、受信側デバイスが送信側デバイスよりも多いＶＬをサポートする、送受信対のためのマッピング機構を指す。図４０は、送信側デバイスとして動作する、４つのＶＬを含むスイッチ４０００Ｔと、受信側デバイスとして動作する、８個のＶＬを含むスイッチ４０００Ｒとの間の拡大マッピングの一例を示す図である。スイッチ４０００Ｔの内部では、あるパケットのＳＣは、動作「Ｆ」で出力ポートに特有のＳＣ／ＶＬｔマッピング３８２２を通過して、出力資源を選択するためのエグレスＶＬｔを導出する。マッピング構成は、受信側デバイスの入力バッファタイプに応じて異なる可能性がある。受信側デバイスの入力バッファが離散ＦＩＦＯである場合には、動作「Ｆ」における出力マッピングは、送信側で利用可能な４つのＶＬ全てへのマッピングである。これら４つのＶＬのクレジットカウンタのそれぞれを、受信側の入力ＦＩＦＯのうちの１つのサイズに設定する。ＳＣ／ＶＬｔマッピング結果は、１：４ｄｅｍｕｘ３８１５への制御入力を生成して、エグレスＶＬｔに関連する適用可能なＶＬ出力ＦＩＦＯ３８１３を選択する。パケットの関連するフリットをアウトバウンドに伝送するとともに、入力制御（図示しないアービタによって実施される）を４：１ｍｕｘ３８１７に適用して、フリットをどのＶＬ出力ＦＩＦＯ３８１３から引き出すかを選択する。
【０２１７】
パケットデータは、スイッチ４０００Ｔから伝送されてスイッチ４０００Ｒで受信され、このときに、ＳＣ／ＶＬｔマッピング３８２０（動作「Ｄ」）を実行して、このパケットを受け入れるための入力ＶＬ資源のうちの１つ（ＶＬ入力ＦＩＦＯ３８１２ａのうちの１つ）を選択する。「Ｄ」における入力マッピングは、入力ＦＩＦＯの使用を最大にするために８個のＶＬ全てにマッピングするものであり、ヘッドオブラインブロッキングを減少させるのに役立つ。この構成では、バッファクレジットの半分は利用されない。ＶＬ入力ＦＩＦＯの選択は、入力として１：８ｄｅｍｕｘ３８１４ａに提供される動作「Ｄ」で生成された制御入力によって実施される。８：１ｍｕｘ３８１６ａは、さらなる処理の間にＶＬ入力ＦＩＦＯ３８１２ａからフリットを引き出すときに実施される。また、図４０に示すように、ＳＣ／ＶＬｎｔテーブル３８２４を、動作「Ｈ」で使用して、送信機が定義する各パケットのＶＬインタリーブを適切にトラッキングするためにインバウンドＳＣ値をマッピングする。
【０２１８】
受信側デバイスの入力バッファが共有バッファ又は再構成可能バッファのプールである場合には、動作「Ｆ」における出力マッピングは、送信側で利用可能な４つのＶＬ全てへのマッピングである。この４つのＶＬのクレジットカウンタは、受信バッファ空間全体が利用されるように構成される。各ＶＬは、順方向進行を保証するために少なくともフルサイズパケットを送信することができるだけのクレジットが与えられる。動作「Ｄ」における入力マッピングは、入力ＦＩＦＯの使用を最大限に高めるための８個のＶＬ全てへのマッピングであり、ヘッドオブラインブロッキングを低減するのに役立つ。
【０２１９】
縮小マッピングは、受信側デバイスが送信側デバイスよりも少ないＶＬをサポートする、送受信対のためのマッピング機構を指す。図４１は、送信側デバイスとして動作する、８つのＶＬを含むスイッチ４１００Ｔと、受信側デバイスとして動作する、４個のＶＬを含むスイッチ４１００Ｒとの間の縮小マッピングの一例を示す図である。拡大マッピングと同様に、縮小マッピング構成は、受信側デバイスにおける入力バッファタイプに応じて異なる可能性がある。受信側デバイスの入力バッファが離散ＦＩＦＯである場合には、動作「Ｆ」における出力マッピングは、受信側のＶＬと一致する送信側の４つのＶＬのみへのマッピングである。これら４つのＶＬのクレジットカウンタのそれぞれを、受信側の入力ＦＩＦＯのうちの１つのサイズに設定する。動作「Ｄ」における入力マッピングは、これに応じる４つのＶＬ全てへのマッピングである。この構成では、８個の利用可能な出力資源のうちの４つだけが使用されている。受信側デバイスの入力バッファが共有バッファ又は再構成可能バッファのプールである場合には、動作「Ｆ」における出力マッピングは、送信側で利用可能な８つのＶＬ全てへのマッピングである。この８つのＶＬのクレジットカウンタは、受信バッファ空間全体が利用されるように構成される。各ＶＬは、順方向進行を保証するために１つのフルサイズパケットを少なくとも送信することができるだけのクレジットが与えられる。動作「Ｄ」における入力マッピングは、４つのＶＬ全てへのマッピングである。この場合には、８個の利用可能な出力資源は全て使用されている。
【０２２０】
受信側端部の入力バッファがラウンドトリップ待ち時間をカバーするほど十分に大きくない、又はそれをぎりぎりカバーする程度しかない、ということがある。この状況では、受信側バッファが共有構造又は構成可能構造である場合には、意図的に全ての資源を利用しないことにより、バッファクレジットを保存することが可能である。図４０に示す構成を考慮されたい。受信側端部の共有バッファがリンクのラウンドトリップ待ち時間をぎりぎりカバーできる程度の場合には、動作「Ｆ」で送信側の４つのＶＬ全てにマッピングする代わりに、２つだけ（又はプロトコル又はトポロジのデッドロック要件がない場合には、１つ）にマッピングするように構成することができる。この構成では、特にＭＴＵが大きい場合には、４つではなく２つのＶＬの間で、より効率的にクレジットを共有することができる。ただし、この方法では、ＱｏＳの送達が損なわれる。
【０２２１】
ＳＣをＶＬにダウンマッピングするようにＳＣ／ＶＬテーブルを構成するときには、上位レイヤのプロトコルと交差せず、ファブリックトポロジのデッドロック回避規則を破らないことが重要である。ＰＧＡＳ（区分化大域アドレス空間）などのレイヤ４プロトコルでは、特定のＳＣが要求クラス用に指定され、他のＳＣが応答クラストラフィック用に指定される。これら２つのクラスが偶発的に同じＶＬバッファにダウンマッピングされた場合には、プロトコルのデッドロックが起こる可能性がある。
【０２２２】
同様に、ＳＣは、ファブリックトポロジのデッドロック回避のために割り付けることもできる。一例を挙げると、Ｔｏｒｕｓトポロジでは、クレジットループ依存性を防止するために、奇数番号のＳＣが全て「デートライン」と交差するパケットに割り付けられる。この状況では、偶数番号のＳＣと奇数番号のＳＣは、いずれのＶＬ資源でも混合することが許されず、さもなければファブリックでトポロジのデッドロックが起こる恐れがある。ＳＣをＶＬにダウンマッピングする際に、残念なことは、ＱｏＳが損なわれることである。異なるＱｏＳレベルに属する複数のＳＣがダウンマッピングされて、同じＶＬ資源を共有する。
【０２２３】
パケットが入力バッファから引き出されるときに、クレジットは、受信機から送信機に対して確認応答される。図４０及び図４１の場合のように、ＳＣ／ＶＬマッピングは２つの端部の間で異なる可能性があるので、クレジットの確認応答は、送信側のＶＬｎｔに基づく。これは、入力ＦＩＦＯから引き出されているパケットのＳＣをマッピングし、それをＳＣ／ＶＬｎｔテーブル３８２４によってマッピングすることによって実現する（図４０及び図４１の動作「Ｈ」）。この生成したＶＬｎｔのクレジットは、次いで、Ｌ２リンク転送サブレイヤによって提供されるフロー制御機構によって確認応答される。図４０及び図４１に示す場合のどちらでも、動作「Ｆ」及び「Ｈ」のマッピングテーブルは一致する。
【０２２４】
このアーキテクチャでは、スイッチの入力ポートのＳＣ／ＳＣマッピングテーブル３８１０のインスタンス（例えば図３８の動作Ｅ）を、その代わりにＳＬ／ＳＣマッピングテーブルとして構成することができる。この機能により、ＩＢ  ＨＣＡ又はＩＢスイッチを、このアーキテクチャのファブリックに直接接続することが可能になる。また、これにより、ＳＬフィールドを含むＬ２パケットヘッダのみが使用されるファブリックのレガシー経路指定及び構成管理ソフトウェアを使用することが可能になる。
【０２２５】
このアーキテクチャは、レガシーマッピングモードもサポートする。例えば、ＳＬ／ＶＬマッピングは、ＩＢＴＡと同様の働きをするレガシーマッピングモードである。このモードでは、ＶＬとＳＣの間に差はない、つまり、これらが等価である。ファブリック全体の全てのＳＣ／ＶＬｔマッピング及びＳＣ／ＶＬｎｔマッピングは、１：１としてプログラムされる、或いはバイパスすることができる。スイッチの入力ポートのＳＣ／ＳＣマッピングテーブル（例えば図３８の動作「Ｅ」のＳＣ／ＳＣマッピングテーブル３８１０）は、ＳＬ／ＶＬマッピングテーブルに変更される。入来パケットのＳＣ及び宛先出力ポートに基づいてエグレスＳＣを生成する代わりに、入来パケットのＳＬ及び宛先出力ポートに基づいて、エグレスＶＬを決定する。パケットのＳＣフィールドは、スイッチを出る前に、このＶＬ値がタグ付けされる。トポロジデッドロック回避のためのもので、デバイスがサポートするＶＬ資源の数を把握していないＳＣ／ＳＣマッピングとは異なり、ＳＬ／ＶＬマッピングは、両方を把握している。したがって、後続のＳＣ／ＶＬマッピングが不要になる。
【０２２６】
ＳＬ／ＶＬマッピングモードは、ＳＬフィールドを含むＬ２リンクファブリックパケットフォーマットで作用し、このフォーマットのみを使用するファブリック環境に適している。このことは、全てのＨＦＩが、このフォーマットを用いなければ互いに通信することができないことを意味する。ＳＬがパケット内に明示的に含まれるので、ＳＬは自動的にエンドツーエンドで保存される。異質環境の縮小マッピング及び拡大マッピングは、様々なＳＣ／ＶＬテーブルに依拠してタスクを実行する代わりに、ＳＬ／ＶＬテーブルに組み込まれる。このレガシーモードでは、ＩＢ  ＨＣＡは、アーキテクチャのファブリックに直接接続することができる。このモードの等価な見方は、このモードを、ＳＣ／ＶＬｔ及びＳＣ／ＶＬｎｔの１：１マッピングとともにＳＬ／ＳＣテーブルと見なすことである。
【０２２７】
図４２は、このＳＬ／ＶＬレガシーマッピングモードのハイレベルな例を示す図である。この図は、２つのＩｎｆｉｎｉＢａｎｄホストチャネルアダプタ（ＩＢ  ＨＣＡ）４２００及び４２０２と、２つのＨＦＩ４２０４及び４２０６と、２つのスイッチ４２０８及び４２１０とを含む。Ｌ２リンクファブリック９Ｂパケットフォーマットは、図４９に示し、以下で説明する、ＳＬフィールドを含む。これにより、ＳＬフィールドの値を変更する必要なく、これらの９Ｂパケットを、任意の組合せのＩＢ  ＨＣＡとＨＦＩとの間でエンドツーエンドで転送することが可能になる。
【０２２８】
ＳＬ／ＶＬハイブリッドレガシーモードは、ＩＢ  ＨＣＡとＨＦＩの混合体を有し、９Ｂパケットフォーマットの他に複数のパケットフォーマットを使用する環境をサポートする。このような環境の一例を、図４３に示す。この環境は、９Ｂ、１０Ｂ及び１６Ｂパケットフォーマットをサポートし、２つのＩＢ  ＨＣＡ４３００及び４３０２と、２つのＨＦＩ４３０４及び４３０６と、２つのスイッチ４３０８及び４３１０とを含む。図４３も、図３７〜図３２に示す様々な動作を、動作に関連する文字を括弧内に含めて示す図である。このようなファブリックでは、ＩＢ  ＨＣＡデバイスに接続されたスイッチポートを除けば、全てのポートは、通常モードで接続される。これらのポートについては、ＳＣ／ＳＣマッピングテーブル３８１０（図３８の動作「Ｅ」）のインスタンスがＳＬ／ＳＣマッピングを実施するように構成された、ハイブリッドモードが使用される。パケットがＩＢポートから入来すると、そのＳＬフィールドは、このアーキテクチャがサポートしている３２個のＳＣのうちの１つにマッピングされる。パケットのＳＣフィールドをこの値に設定した後で、パケットは、図３８の動作「Ｆ」に示すものと同様のＳＣ／ＶＬマッピングを通過して、このパケットの出力資源を選択する。これは、上記でＳＬ／ＶＬレガシーモードについて述べたように、ＳＬ／ＶＬとは異なる。マッピングを２つのステップに分割することにより、パケットのＳＬフィールドは、接続スイッチがサポートするＶＬにダウンマッピングされる代わりに、３２個のＳＣの全範囲にマッピングされる。これにより、パケットは、異質ファブリックの拡大及び縮小マッピングを通過して、その過程で全ての資源を利用することができる。なお、９Ｂパケットトラフィックしか含まないファブリックでも、このハイブリッドモードを、ＳＬ／ＶＬレガシーモードの代わりに使用することができることに留意されたい。
【０２２９】
リンクファブリックサブレイヤ
上述のように、情報は、各メッセージが１つ又は複数のリンクファブリックパケットによって搬送されるＬ２リンクレイヤを通ってエンドポイントからエンドポイントまで伝送される。実施形態では、これらのパケットは、小さいものでは１６バイト（２フリット）から大きいものでは１６３７６バイト（２０４７フリット）までのサイズをサポートする。この範囲は、ＰＧＡＳプログラミング言語で一般的な小さなメッセージ及びカプセル化ジャンボ（１０ＫＢ）イーサネット（登録商標）フレームを転送するのに必要な大きなメッセージの両方の必要を満たすことを意図したものである。１実施形態では、最大のＦＰのサイズは、Ｌ４  ＭＴＵ（最大転送単位）、すなわち１０ＫＢまでに制限される。
【０２３０】
図２に示すように、このリンクファブリックサブレイヤは、Ｌ２レイヤ全体の上半分であり、Ｌ２リンク転送サブレイヤを含む下半分は、物理レイヤの近くで動作する。１実施形態では、論理は、ＨＦＩなどのアーキテクチャのデバイスのためにパイプライン化し、トランスポートパケットを上位のリンクファブリックサブレイヤで交換する。ただし、デバイス間のリンクでは、リンクファブリックパケットは、より小さな単位（フリット）にセグメント化され、このより小さな単位が、互いに（ＬＴＰ）にバンドリングされて、リンク転送サブレイヤプロトコルを用いて搬送される。
【０２３１】
図４５に示す汎用ファブリックパケットフォーマットに示すように、ファブリックパケットは、ヘッドフリットから開始され、その後に０から２０４５個のボディフリットが続き、テールフリットで終了する。バブル又は遊休フリット、並びにその他のＬＦコマンドフリットは、ファブリックパケットフリットの中に点在することができる。パケットを宛先エンドポイントに向けて経路指定する助けとなる様々な情報を提供する、複数バイトに及ぶ１組のファブリックパケットヘッダフィールドが、各パケットの先頭に存在する。
【０２３２】
フォーマットタイプに応じて、これらのヘッダフィールドは、ヘッドフリットから開始して、１つ又は複数のフリットに及ぶことがある。ヘッダフィールドの後にはＦＰのデータペイロードが続き、このデータペイロードは、テールフリットで定義されるＦＰの末端まで続く。図４及び表１を参照して上述したように、フリットタイプビット（フリットビット［６４］）とリンクタイプ（ＬＴ）制御ビット（データビット［６３］及び［６２］）とが組み合わさって、フリットがヘッドフリットであるか、ボディフリットであるか、テールフリットであるかを識別する。
【０２３３】
１実施形態では、このアーキテクチャは、４つの異なるヘッダフォーマットをサポートする。各フォーマットは、異なる数のヘッダフィールドを含み、異なる機能セットを提供する。Ｌ２ファブリックパケットフォーマットのうちの１つは、Ｌ２タイプヘッダフィールドが「００」に設定されている８Ｂヘッダフォーマットである。これは、他のフォーマットより小型になり、パケットオーバヘッドが低くなるように設計されている。ヘッダがフリット１つに収まるようにするために、このフォーマットは、縮小した機能セットと、総数でフリット１２７個分の最大パケットサイズを搬送することができる短縮した長さフィールドとを有する。この限界を超える、又は省略された機能を必要とするペイロードについては、他のフォーマットのうちの１つを使用する。ファブリックパケットの８Ｂヘッダフォーマットの実施形態は、図４６に示してある。
【０２３４】
図４７に示すように、１０Ｂヘッダフォーマットは、８Ｂフォーマットより大きな長さフィールドを有し、最大でフリット２０４７個分の最大パケットサイズを搬送することを可能にする。さらに、１０Ｂヘッダフォーマットは、８Ｂが提供しない、縮小したＰ＿Ｋｅｙ（パーティションキー）及びエントロピ機能を提供する。１実施形態では、１０Ｂヘッダパケットは、Ｌ２タイプヘッダフィールドが「０１」に設定されている。
【０２３５】
１実施形態では、１６Ｂヘッダフォーマットは、リンクファブリックサブレイヤがサポートする全ての機能を含む。図４８に示すように、１６Ｂヘッダパケットは、Ｌ２タイプヘッダフィールドが「１０」に設定されている。このフォーマットは、３個から２０４７個のフリットを含むパケットに使用することができる。ヘッダは、正確に１６バイト、又は２フリットを消費し、これは、後続のペイロードに良好な位置合わせを提供する。さらに、このフォーマットは、非常に多数のエンドポイントをサポートする拡張２４ビットアドレッシング空間を提供する。
【０２３６】
９Ｂヘッダフォーマットの１実施形態は、図４９に示す。９Ｂヘッダフォーマットは、ＩｎｆｉｎｉＢａｎｄ（ＩＢ）トラフィックを搬送することを目的としている。このパケットフォーマットのＬ２タイプヘッダフィールドは、「１１」に設定され、その直後にビット［６０：５７］の「００００」が続く。ヘッドフリットのこの最上位バイトの後に、固有のＩＢパケットが直接接続される。ただし、固有の４ビットＩＢ  ＶＬフィールドは、アーキテクチャがサポートする５ビットＳＣフィールドと釣り合わせるために、ヘッドフリットのビット［５６］まで１ビット分だけ拡張されている。ＩＢとこのアーキテクチャの間でファブリックアーキテクチャが一体化されているので、ＩＢのローカル経路指定ヘッダ及びベーストランスポートヘッダのうちの選択されたヘッダフィールドは、このパケットを経路指定するときに、リンクファブリックサブレイヤによってそのまま使用される。これらのフィールドは、図４９に網掛けで示してある、ＳＣ、ＬＶｅｒ、ＳＬ、ＬＮＨ、ＤＬＩＤ、長さ、ＳＬＩＤ、Ｐ＿Ｋｅｙ、（Ｆ）ＥＣＮ、及び（Ｂ）ＥＣＮフィールドを含む。
【０２３７】
Ｌ２ファブリックパケットは、１つ又は複数のフリットに及ぶヘッダから開始する。ヘッダを搬送する第１のフリットは、ヘッドフリットとマークされ、ヘッダの残りの部分は０個以上のボディフリットでマークされる。ヘッダが第１のフリットの全体及び第２のフリットのうちの２バイトを占める１０Ｂヘッダフォーマットで示したように、パケットヘッダは、フリットサイズの倍数である必要はない。各ヘッダは、経路指定指向とパケットに関するその他の情報とを含む様々なフィールドで構成される。以下の表３は、各パケットフォーマットに含まれるフィールドの概要を示している。
【０２３８】
【表８】
0006297698.tif 000009
【０２３９】
Ｌ２タイプ符号化フィールドは、ファブリックパケットのフォーマットを識別するために使用される。このフィールドは、ビット［６２：６１］が「００」、「０１」又は「１０」に設定されているときには、２ビット幅である。ただし、このビットが「１１」に設定されているときには、このフィールドは、６ビット幅に拡張され、ビット［６２：５７］に位置する。この符号化に基づいて、各アーキテクチャデバイスは、パケットフォーマットのタイプ、及びそのヘッダフィールドの位置を検出する。
【０２４０】
各ファブリックパケットは、上位のＬ４プロトコルレイヤのペイロードを搬送する。特定のパケットがどのＬ４プロトコルを搬送しているかをエンドポイントが把握するために、Ｌ４タイプフィールドが、各ヘッダに含まれる。このフィールドは、８Ｂ及び１０Ｂヘッダフォーマットでは４ビット幅であるが、１６Ｂヘッダフォーマットでは８ビットに拡張されて、より多くのＬ４プロトコルによって使用できるようになっている。４ビット幅の場合には、［３：０］として定義される代わりに、このフィールドは、ビット７を搬送し、［７、２：０］として定義される。４ビット及び８ビットのどちらのＬ４タイプフィールドでも、符号化空間のかなりの部分は、アーキテクチャのＬ４固有オフロードプロトコルに割り当てられる。その他の全てのＬ４プロトコルが、残りの符号化空間を共有する。９Ｂヘッダフォーマットは、特にＬ４  ＩＢカプセル化を目的としているものであるので、９Ｂヘッダフォーマットは、Ｌ４タイプフィールドを含まない唯一のフォーマットである。
【０２４１】
各ヘッドフリットのビット［５６：５２］に含まれる５ビットＳＣフィールドは、３２個のサービスチャネルのうちのどれをパケットが使用しているかを識別する。本明細書の他の箇所でさらに詳細に述べるように、各アーキテクチャデバイスは、このフィールドを使用して、どのＳＣ及びＶＬ資源の組がパケットを下流に移動させるために使用されるかを決定する。
【０２４２】
１実施形態では、このアーキテクチャは、３２個のＱｏＳレベルをサポートする。８Ｂ、１０Ｂ、及び１６Ｂパケットフォーマットでは、この情報は、ＳＣフィールドによって示されるので、これらのフォーマットは、明示的なＳＬフィールドを含まない。９Ｂパケットフォーマットでは、カプセル化ＩＢパケットから引き継いだ４ビットの明示ＳＬフィールドを搬送する。レガシーＩＢ  ＨＣＡは、パケットをファブリックに注入するときにそのＶＬフィールド内にＳＬ情報を示さないので、パケットのＱｏＳを指定するために、このＳＬフィールドが必要となる。ＩＢ  ＨＣＡから９Ｂパケットを受信するエッジスイッチは、上述のＳＬ／ＳＣマッピングを使用することによって、このＳＬ情報をＳＣフィールドに示すオプションを有する。この場合には、受信側エンドポイントは、その明示ＳＬフィールドを検査するか、又はＳＣフィールドを復号することによって、パケットのＱｏＳを取り出すことができる。
【０２４３】
宛先ローカルＩＤ（ＤＬＩＤ）フィールドは、各ヘッドフリットに位置して、パケットを送達すべきエンドポイントを示す。このアーキテクチャファブリックの全てのエンドポイントは、ファブリックの領域内で一意的な１つ又は複数のＤＬＩＤによって識別される。８Ｂ及び１０Ｂフォーマットでは、２０ビットＤＬＩＤフィールドが、ヘッドフリットのビット［５１：３２］に位置する。１６Ｂフォーマットでは、２４ビットＤＬＩＤフィールドが、ヘッドフリットのビット［５１：３２］及び第２のヘッダフリットのビット［１５：１２］に位置する。９Ｂフォーマットでは、１６ビットＤＬＩＤが、ヘッドフリットのビット［３９：２４］に位置し、他のフォーマットより小さなアドレッシング空間を提供する。１実施形態では、ＤＬＩＤスペースは、ユニキャスト及びマルチキャスト／コレクティブの両方のアドレッシングをサポートする。ユニキャストアドレスが単一のエンドポイント送達を識別し、マルチキャスト／コレクティブＤＬＩＤが、送達される１組のエンドポイントを識別する。
【０２４４】
発信元ローカルＩＤ（ＳＬＩＤ）フィールドは、パケットが送信された出所のエンドポイントを示すために、各ヘッドフリットに位置する。８Ｂ及び１０Ｂフォーマットでは、２０ビット発信元フィールドが、ヘッドフリットのビット［１９：０］に位置する。１６ビットフォーマットでは、２４ビットＤＬＩＤフィールドが、ヘッドフリットのビット［１９：０］及び第２のヘッダフリットのビット［１１：８］に位置する。９Ｂフォーマットでは、１６ビットＳＬＩＤは、ヘッドフリットのビット［７：０］及び第２のフリットのビット［６３：５６］に及ぶ。ＳＬＩＤの割り付けは、前節で説明したＤＬＩＤと非常に似ているが、パケットを複数のエンドポイントで生成することはできないので、ＳＬＩＤはマルチキャスト／コレクティブアドレスになることはない点が異なる。多くのトポロジが、非輻輳環境で待ち時間を短縮するために最短ルートを通って宛先までパケットを経路指定する、又はファブリック全体にパケットを拡散して、経路指定経路が最短でなかったとしても輻輳を最小限に抑えるなど、複数の経路指定方法を提供する。いくつかのトポロジは、エンドポイント間のパケットを各パケットで生じる輻輳レベルに基づいて経路指定する適応型経路指定も提供する。
【０２４５】
経路指定制御を容易にするために、ＲＣフィールドが、経路指定要件と、ファブリック全体にわたって所与のパケットを経路指定するための好ましい方法とを指定する３ビットフィールドとして符号化される。特定のトラフィックフロー又はアプリケーションに対してどの経路指定方法を使用するかを判定し、それに応じてこのフィールドを設定するのは、Ｌ４トランスポートレイヤの担当である。最上位ビットＲＣ［２］が未設定であるときには、最下位ビットＲＣ［０］が、パケットを順序通りに経路指定するかどうかをファブリックに通知する。順序通りに経路指定しなくてもよいパケットについては、ファブリックの能力に応じて、パケットは、無作為に、又は経路指定選択肢の輻輳レベルに基づいて、経路指定することができる。中央ビットＲＣ［１］は、待ち時間を最適化するようにパケットを経路指定すべきか、又は帯域幅を最適化するようにパケットを経路指定すべきかを指定する。待ち時間を最適化するときには、ファブリックは、宛先に向かうホップカウントを最小限にする。帯域幅を最適化するときには、トラフィックを拡散して輻輳を軽減するために、最短ではない経路指定を利用することもできる。
【０２４６】
ファブリックがサポートするトポロジ及び経路指定方法に応じて、各スイッチは、ＲＣフィールドの設定に何が指定されているかを検査するが、より制限的な方法でパケットを経路指定することを選択することもできる。１実施形態では、このフィールドの設定が順序通りの経路指定を指定している場合には、パケットは、順序を変えて経路指定することはできない。ただし、順序を変えることが指定されていても、パケットを順序通りに経路指定することは許可される。
【０２４７】
９Ｂヘッダフォーマットを除く全てのパケットフォーマットは、このフィールドを、ヘッドフリットのビット［５９：５７］に含む。９Ｂヘッダフォーマットは、ＩＢパケットをカプセル化するために使用されるので、また、既存のＩＢプロトコルはこの経路指定制御フィールドを利用することができないので、このフィールドは、９Ｂフォーマットでは省略される。１実施形態では、９Ｂフォーマットを使用するパケットは、確定０経路指定方法を使用して処理される。
【０２４８】
８Ｂ、１０Ｂ及び１６Ｂヘッダフォーマットでは、長さフィールドは、ヘッドフリット及びテールフリットも含む、パケット内のフリットの総数を指定する。各フリットは６４ビット幅であるので、パケットの全体のサイズは、その長さに８Ｂを乗算したものに等しい。固有のＩＢパケットをカプセル化するために使用される９Ｂヘッダフォーマットでは、長さフィールドは、カプセル化ＩＢパケットの一部であり、したがって、フリット数は示さない。その代わりに、長さフィールドは、カプセル化されているＩＢパケットのサイズを４バイトワード単位で指定する。この追加のヘッドバイト及びテールバイトにより、ＩＢパケットをカプセル化するときには、９Ｂヘッダパケット中の実際のフリット数は、常に「長さ［１１：０］／２＋１」に等しい。
【０２４９】
ＬＶｅｒ（リンクバージョン）フィールドは、特に９Ｂヘッダフォーマットのためのものであり、ビット［５１：４８］に位置する。これは、接続されたＩＢパケットから直接使用されるフィールドである。ＩＢＴＡ１．２．１では、このフィールドの値は０であるものとされる。同様に、リンクネクストヘッダ（ＬＮＨ）フィールドも、特に９Ｂヘッダフォーマット用のものであり、ビット［４１：４０］に位置する。これは、接続されたＩＢパケットから直接使用されるフィールドである。このアーキテクチャは、様々な輻輳管理機能をサポートする。輻輳の拡散を最小限に抑えるエンドツーエンド（Ｅ２Ｅ）輻輳管理方式の一部として、順方向明示輻輳通知（略記はＦＥＣＮ（Forward Explicit Congestion Notification）又はＦ）ビットを使用して、ファブリック内で輻輳に遭遇したパケットにマーキングする。このＦＥＣＮビットは、逆方向明示輻輳通知（略記はＢＥＣＮ（Backward Explicit Congestion Notification）又はＢ）ビットと組み合わせて使用される。８Ｂ、１０Ｂ及び１６Ｂフォーマットでは、このＦビットは、ヘッドフリットのビット［６０］に位置する。ただし、９Ｂヘッダフォーマットでは、このビットは、接続されたＩＢパケット内のＦＥＣＮビットと直接共有される。（Ｂ）ＥＣＮビットは、発信元エンドポイントがファブリック内で輻輳の形成及び拡散を引き起こしている可能性があることを、発信元エンドポイントに通知するためのフィードバック機構として使用される。８Ｂ、１０Ｂ及び１６Ｂフォーマットでは、このＢビットは、ヘッドフリットのビット［３１］に位置する。ただし、９Ｂヘッダフォーマットでは、このビットは、接続されたＩＢパケット内のＢＥＣＮビットと直接共有される。
【０２５０】
この概念は、パケットが発信元からその宛先のエンドポイントに進行する際に、１組の輻輳基準に基づいて輻輳に遭遇したときに、このビットがマーキングされるというものである。このビットが一度設定されると、ファブリック内のこの経路に沿った他のスイッチは、これを設定解除することはできない。宛先に到達したとき、そのエンドポイントは、ＡＣＫパケットのＢビットをマーキングする、又は明示輻輳通知（ＥＣＮ（Explicit Congestion Notification））パケットを発信元エンドポイントに返送することによって、パケットの発信元エンドポイントに通知するオプションを有する。Ｆビットの場合と同様に、ファブリック内のスイッチは、Ｂビットを設定解除することができない。発信元が十分なＢ通知を受信した場合には、発信元は、自分がファブリックに注入しているトラフィックが多すぎることを認識し、注入レートを落として、輻輳が拡散しないようにする。
【０２５１】
パーティションキーフィールド又はＰ＿Ｋｅｙは、Ｌ２リンクレイヤにおけるファブリックのパーティショニングに関する。パーティションは、互いに通信することができるエンドポイントの組を制限するために使用することができる。さらに、複数の重複したパーティションを定義することができ、複数のエンドポイントが複数のパーティションのメンバとなるようにすることができる。このフィールドのＭＳＢは、メンバシップインジケータとして使用することができるので、残りの１５ビットによって最大で３２７６７個のパーティションをサポートする。メンバシップインジケータビット値の「１」は、フルメンバであることを意味し、「０」は、限定メンバであることを意味する。
【０２５２】
エントロピフィールドは、フィールドのコンテンツが上位のＬ４転送レイヤによって制御され、ファブリック内でエンドツーエンドで一定のままである、分散型経路指定に使用される。このフィールドを使用することにより、あるエンドポイントに向かって進行中のパケットは、他の全ての有効な経路を検討し尽くして、トラフィックの拡散を助け、輻輳を緩和することができる。エントロピは、Ｌ４実施態様が使用して、受信側のスケーリングを行うこともできる。この場合には、エンドポイントがエントロピ値を使用して、そのパケットを処理するためにどの受信待ち行列及び／又は受信処理スレッドを使用するかを選択することができる。１６Ｂ及び１０Ｂヘッダフォーマットは、それぞれ第２のヘッダフリットのビット［４７：３２］及びビット［１５：８］に位置する１６ビット及び８ビットのエントロピを提供する。８Ｂ及び９Ｂフォーマットは、この機能を提供しない。
【０２５３】
全ての経路指定モードが、このエントロピフィールドを利用するわけではない。例えば、特定のトポロジ用の適合型経路指定は、経路指定の選択肢を無作為に選択することにして、このフィールドを無視することができる。このフィールドを使用する他の経路指定モードでは、このフィールドの設定は、ＳＬＩＤビットとＤＬＩＤビットの組合せと同程度の粗い細分度であってもよいし、プロセスＩＤより若干細かい程度の細分度であってもよいし、メモリアドレスビットの組合せによる非常に細かい細分度であってもよい。
【０２５４】
８ビット経過時間フィールドは、パケットがファブリックを横断するときのパケットの経過時間を示し、大域的な公平性を実現するための経過時間に基づくアービトレーションのために使用される。Ｔｏｒｕｓ又はＭｅｓｈなど、特定のトポロジは、局所的に公平なアービトレーションを使用したときには周知の公平性の問題があり、これが、特に大規模ネットワークでは、パケットの待ち時間の大きなばらつきにつながる可能性がある。経過時間に基づくアービトレーションは、パケット待ち時間のばらつきを軽減するだけでなく、パケットの平均待ち時間も低下させる。
【０２５５】
経過時間フィールドは、経過時間機能をサポートする唯一のフォーマットである１６Ｂヘッダパケットフォーマットで、第２のヘッダフリットのビット［５５：４８］に位置する。このフィールドの値は、ホップごとに変化し、各デバイスは、パケットがデバイスから出るまでにデバイス内に留まる時間に比例する量ずつ経過時間を累積する。この量が構成可能な飽和値に達すると、この経過時間フィールドは、ホップカウントとして作用し、各ホップで１ずつ増分される。各デバイスは、パケットを下流側に転送するときのアービトレーションプロセス中に、パケットの経過時間を考慮する。あるポートが、ＦＭによって構成可能な最大許容限界を有するパケットを受信した場合には、このパケットは、誤ってプログラムされた経路指定テーブルによる暴走パケットであると見なされ、ドロップされる。このエラー状態は、その後、エラーカウンタを介して報告される。
【０２５６】
「Ｒ」で識別されるフィールドは、将来使用するために確保されたフィールドを含む。１実施形態では、確保フィールドのビットは、エンドポイントによってファブリックに注入されるときには０に設定され、ファブリック内ではスイッチに無視されて不変のまま残り、受信側エンドポイントにも無視される。
【０２５７】
各リンクファブリックパケットは、上位のＬ４レイヤプロトコルのパケットをカプセル化するペイロード部分を搬送する。このペイロードは、数バイトという小さなものからほとんど１６Ｋバイト（又は適用可能であれば１０ＫＢ  ＭＴＵ）という大きなものにまですることができ、全てのフォーマットで、ヘッダフィールドの直後に位置する。カプセル化されたＬ４パケットは、それ自体のヘッダ及びペイロードのセットを含む。Ｌ４パケットのフォーマットは、プロトコル特定である。このアーキテクチャがサポートするＬ４プロトコルの例としては、アーキテクチャの固有のオフロードプロトコル、イーサネット（登録商標）、ＩｎｆｉｎｉＢａｎｄ、及びファブリック管理などが挙げられる。ペイロードが搬送するＬ４プロトコルのタイプは、上述のように、各リンクファブリックパケットヘッダのＬ４タイプフィールドに指定される。このカプセル化されたＬ４パケットの最後のフリットは、Ｌ４パケットを保護するだけでなく、Ｌ２ファブリックパケットの不変ヘッダフィールドもカバーする、不変ＣＲＣ（ＩＣＲＣ）を含むことが多いが、これは必要というわけではない。
【０２５８】
図５０は、１実施形態による、送信ポート５０００及び受信ポート５００２を含むリンクインタフェースポートの選択した特徴を示す図である。図５０に示す様々な要素は、これ以前の図面に示し、本明細書の他の箇所で詳細に説明したものである。図示の要素の他に、送信ポート及び受信ポートはともに、図面の大きさの制限により図示していない追加の構成要素を含む。
【０２５９】
送信ポート５０００及び受信ポート５００２はそれぞれ、本明細書に記載する送信ポート動作を実行するための回路及び論理を含む。上記で提示し、図２に示すように、このアーキテクチャは、リンクファブリックサブレイヤ、リンク転送サブレイヤ、及びＰＨＹレイヤを利用する。したがって、送信ポート５０００及び受信ポート５００２のそれぞれの回路及び論理は、対応するサブレイヤ又はレイヤの動作を容易にする複数のブロックに区分化された状態で示してある。送信ポート５０００では、これらは、Ｔｘリンクファブリックサブレイヤ回路及び論理５００４と、Ｔｘリンク転送サブレイヤ回路及び論理５００６と、Ｔｘ  ＰＨＹ回路及び論理５００８とを含む。同様に、受信ポート５００２は、Ｒｘリンクファブリックサブレイヤ回路及び論理５０１０と、Ｒｘリンク転送サブレイヤ回路及び論理５０１２と、Ｒｘ  ＰＨＹ回路及び論理５０１４とを含む。これらのより大きな回路及び論理のブロックの間の分割は定まったものではなく、所与の回路及び論理のブロックの中に示すいくつかの機能を、複数のブロックにわたって、又は別のブロックで、実施することもでき、図５０に示す構成は、単なる例示であり、これに限定されるわけではなく、他の構成を実施することもできることは理解されるであろう。
【０２６０】
Ｔｘ  ＰＨＹ回路及び論理５００８は、４つの送信機５０１６及びＴｘリンク制御ブロック１８０４の一部分を含む、単純化した形態で示してある。一般に、送信機５０１６は、リンクのＰＨＹレイヤの構成に応じて、電気的送信機又は光学的送信機を含むことができる。ネットワーク技術の当業者なら、Ｔｘ  ＰＨＹ回路及び論理ブロックは、はっきりとは図示していない送信側ＰＨＹレイヤ動作を実施するための追加の回路及び論理を含むことを理解するであろう。これは、ＰＨＹレイヤ内に、エラーを減少させ、送信特性を改善するために高速相互接続と関連付けて実施される様々な機能を容易にするために使用される、様々なサブレイヤを含む。１実施形態では、スクランブル及び６４ｂ／６６ｂ送信側動作は、ＰＨＹレイヤの動作を容易にするＴｘリンク制御ブロック１８０４の一部分によって実行される。
【０２６１】
Ｔｘリンク転送サブレイヤ回路及び論理５００６は、本明細書に記載するリンク転送サブレイヤ動作の送信側の特徴を実施するように構成される。これらは、再試行論理５０１８、ＬＴＰバンドリングブロック５０２０、再現バッファ１８０６、並びにＮｘｔＷｒＬＴＰポインタ及びＮｘｔＴｘＬＴＰポインタなど、ＬＴＰをバンドリングし、Ｔｘ  ＰＨＹに渡すためにＬＴＰストリームを準備し、ＲｅｔｒｙＲｅｑに応答してＬＴＰの再現をサポートするための様々な構成要素及び論理ブロックを含む。さらに、Ｔｘリンク制御ブロック１８０４の一部分及びＱｏＳ機能は、ＱｏＳブロック５０２２で示すように、Ｔｘリンク転送サブレイヤのために実施される。
【０２６２】
Ｔｘリンクファブリックサブレイヤ回路及び論理５００４は、本明細書に記載するリンクファブリックサブレイヤ動作の送信側の特徴を実施するように構成される。これらの動作を容易にするための図示の構成要素及びブロックは、イーサネット（登録商標）、ＩｎｆｉｎｉＢａｎｄ及び固有のアークテクチャパケットのＬ４カプセル化を実行するように構成されたＬ４カプセル化サブブロック５０２６を含むファブリックパケット構築ブロック５０２４と、アービトレーション論理３４００と、クレジットマネージャ３００２と、複数の出力ＦＩＦＯ３７０４とを含む。また、図示のように、ＱｏＳ論理５０２２の一部分は、リンクファブリックサブレイヤで実施されるＱｏＳ動作のために使用される。
【０２６３】
Ｒｘ  ＰＨＹ回路及び論理５０１４は、４つの受信機５０２８及びＲｘリンク制御ブロック１８０５の一部分を含む、単純化した形態で示してある。一般に、受信機５０２８は、リンクのＰＨＹレイヤの構成に応じて、電気的送信機又は光学的送信機を含むことができ、送信機５０１６からリンクを介して送信機信号を受信するように構成される。ネットワーク技術の当業者なら、Ｒｘ  ＰＨＹ回路及び論理ブロックは、はっきりとは図示していない受信側ＰＨＹレイヤ動作を実施するための追加の回路及び論理を含むことを理解するであろう。これは、ＰＨＹレイヤ内に、エラーを減少させ、送信特性を改善するために高速相互接続と関連付けて実施される様々な機能を容易にするために使用される、様々なサブレイヤを含む。１実施形態では、スクランブル解除及び６４ｂ／６６ｂ受信側動作は、ＰＨＹレイヤの動作を容易にするＲｘリンク制御ブロック１８０５の一部分によって実行される。
【０２６４】
Ｒｘリンク転送サブレイヤ回路及び論理５０１２は、本明細書に記載するリンク転送サブレイヤ動作の受信側の特徴を実施するように構成される。これらは、ＬＴＰのバンドリング解除、ＬＴＰ  ＣＲＣ及びレーンごとのＣＲＣエラーの検出、受信機トスモード及び関連する動作、並びにＱｏＳ動作のための様々な構成要素及び論理ブロックを含む。図示の構成要素及びブロックは、ＱｏＳ論理５０３０、Ｒｘトスブロック５０３４、ＬＴＰ／レーンエラー検出ブロック５０３４、ＬＴＰバンドリング解除ブロック５０３５、レーンごと及びＸＦＲグループごとのＣＲＣ、Ｒｘ  ＬＴＰシーケンスレジスタ、並びにＮｘｔＲｘＬＴＰポインタを含む。
【０２６５】
Ｒｘリンクファブリックサブレイヤ回路及び論理５０１０は、本明細書に記載するリンクファブリックサブレイヤ動作の受信側の特徴を実施するように構成される。これらの動作を容易にするための図示の構成要素及びブロックは、Ｌ４パケットカプセル解除サブブロック５０４０を含むファブリックパケット再アセンブリブロック５０３８と、クレジットリターンブロック５０４２と、入力ＦＩＦＯ３９０６と、ＱｏＳ論理の一部分５０３０とを含む。さらに、入力ＦＩＦＯ３９０６のバッファ空間の編成は、３ティア共有バッファ編成方式５０４４を利用するものとして示してあるが、図３１ａ及び図３１ｂに示す他のバッファ編成方式、並びに本明細書に記載する他のバッファ編成方式も同様に使用することができることに留意されたい。
【０２６６】
ＨＦＩ及びその他のエンドポイントデバイスでは、送信ポート及び受信ポートは、他の外部構成要素によって実行される上位レイヤの動作とインタフェースをとる追加のインタフェース論理を含むことができる。例示を目的として、これらのインタフェースは、Ｒｘ  Ｌ４インタフェース５０４６及びＴｘ  Ｌ４インタフェース５０４８で示すが、これらはそれぞれ、ＨＦＩ又はその他のエンドポイントデバイスの受信側及び送信側のレイヤ４論理及び／又は構成要素とインタフェースをとるように構成される。
【０２６７】
図５１は、１実施形態による、マルチポートファブリックスイッチ５１００を示す図である。ファブリックスイッチ５１００は、図５０を参照して上述したＲｘポート５００２及びＴｘポート５０００をそれぞれ含む、１６個のファブリックインタフェースポート５１０２を含む。各Ｒｘポート５００２は、複数の入力ＦＩＦＯ３９０６を含み、各Ｔｘポート５０００は、複数の出力ＦＩＦＯ３７０４を含む。Ｒｘポート５００２及びＴｘポート５０００は、図示のように、受信ポートの出力を送信ポートの入力に選択的に接続するように構成されたクロスバー５１０４に結合される。図５１に示す構成要素に加えて、様々なアービトレーション論理及びＱｏＳ論理を利用して、図３８に示して上述した転送及び経路指定テーブル３８０８と同様に動作する転送及び経路指定テーブル５１０６を使用することを含む、クロスバー５１０４のポートマッピングを制御する。
【０２６８】
図５２は、受信ポートで受信したフリットを取り扱い、それらを入力ＦＩＦＯにバッファリングするための動作及び論理を示す流れ図５２００を示す図である。ブロック５２０２で、ＬＴＰフリットストリームの一部としてフリットを受信し、ＰＨＹレイヤの処理を実行してＬＴＰ及びフリットデータを回復して、個々のフリットを検査できるようにする。判定ブロック５２０４で、このフリットが遊休フリット又はＬＦ制御フリットであるかを判定する。表１を参照して上述したように、「０００」で始まるフリット（フリットタイプビットであるビット６５を含む）は、遊休フリット、ＬＦ制御フリット、又はエラントフリットのいずれかである。このフリットがこれらのうちのいずれでもないと仮定すると、判定ブロック５２０４の結果はＮＯとなり、論理は判定ブロック５２０６に流れ、このブロックで、このフリットがヘッドフリットであるか、テールフリットであるか、又はボディフリットであるかを判定する。ほとんどのフリットはボディフリットであり、ブロック５２０８で、このフリットは、現在のＶＬによって識別されるＦＩＦＯバッファに追加される。現在のＶＬは、１実施形態では、インタリーブ及びプリエンプションに関連して上述したように、現在のＶＬレジスタに記憶されている指標によって識別される。次いで、論理は、ブロック５２０２に戻り、次のフリットを取り扱う。
【０２６９】
上述のように、現在のＶＬは、新たなヘッダフリット、ヘッダフリットを以前に受信したファブリックパケットに対応するテールフリット、又はＶＬマーカ（ＶＬマーカの使用をサポートする実施形態の場合）に応答して変化する可能性がある。ブロック５２１０に示すように、ブロック５２０６でフリットがヘッドフリットであると判定したのに応答して、ファブリックパケットヘッダＳＣ（及びＩＢがカプセル化されたＦＰのＳＬ）フィールドを検査して、そのファブリックパケットに関連する仮想レーンを決定して、適用可能なＱｏＳ論理を適用する。例えば、１実施形態では、これらの動作は、図３９に示し、上述したものである。ブロック５２１２で、識別したＶＬｔに対応する指標を現在のＶＬレジスタに書き込んで、フリットを追加すべき現在のＶＬを更新する。適用可能であれば、ＶＬスタックもプッシュする。論理は、次いで、ブロック５２０２に戻って、次のフリットを取り扱う。
【０２７０】
ヘッドフリットは、現在のＶＬを変更するために使用されるが、テールフリットは、インタリーブ及びプリエンプションに関連して上述したように、スタックをポップすることによって現在のＶＬを以前のＶＬに戻すために使用される。したがって、判定ブロック５２０６でテールフリットを検出すると、これに応答して、論理は、ブロック５２１４に進み、このブロックで、ＶＬスタックがポップされ、現在のＶＬレジスタが更新される。論理は、次いで、ブロック５２０２に戻って、次のフリットを取り扱う。
【０２７１】
判定ブロック５２０４に戻って、フリットが遊休フリット又はＬＦ制御フリットであると識別された場合には、論理は、判定ブロック５２１６に進んで、このフリットがＶＬマーカであるかどうかを判定する。ＶＬマーカでない場合には、ブロック５２２０で、ＬＦ制御フリット又は遊休フリットによって指定される１つ又は複数の適用可能な動作を実行し、論理は、ブロック５２０２に戻って、次のフリットを取り扱う。ただし、フリットが、ＶＬマーカを含むＬＦ制御フリットである場合には、論理は、ブロック５２１８に進んで、このブロックで、そのＶＬマーカによって識別されるＶＬで現在のＶＬレジスタを更新し、ＶＬスタックをプッシュする。次いで、論理はブロック５２０２に戻り、次のフリットを取り扱う。
【０２７２】
図５３は、メモリ５３０８に結合されたプロセッサ５３０６に結合された、ファブリックポート５３０４を含むホストファブリックインタフェース５３０２を含む例示的な構成を有する、ノード５３００を示す図である。図１に示すように、システムノードは、離散独立ノードプラットフォーム１０６、仮想化プラットフォーム１１０、多ノードプラットフォーム１１６、及び一体化独立ノードプラットフォーム１２０で示す構成など（ただしこれらに限定されない）、様々な構成を有することができる。一般に、各ノード構成は、少なくとも１つのプロセッサと、メモリと、図５３に示す同様の構成要素を有する少なくとも１つのＨＦＩとを含む。
【０２７３】
ファブリックポート５３０４は、図５０に示す構成と同様の構成を有する送信ポート５０００及び受信ポート５００２を含む。送信ポート５０００は、複数の送信ＶＬバッファに区分化された送信バッファを含むＴｘリンクファブリックサブレイヤ回路及び論理５００４と、Ｔｘリンク転送サブレイヤ回路及び論理５００６と、４つの送信機５１０６を含むＴｘ  ＰＨＹ回路及び論理５００８と、Ｔｘリンク制御ブロック１８０４とを含む。受信ポート５００２は、複数の受信ＶＬバッファに区分化された受信バッファを含むＲｘリンクファブリックサブレイヤ回路及び論理５０１０と、Ｒｘリンク転送サブレイヤ回路及び論理５０１２と、４つの受信機５０２８を含むＲｘ  ＰＨＹ回路及び論理５０１４と、Ｒｘリンク制御ブロック１８０５とを含む。
【０２７４】
ＨＦＩ５３０２は、ＰＣＩｅ（周辺機器相互接続エクスプレス）インタフェース（Ｉ／Ｆ）５３１４に結合された送信エンジン５３１０及び受信エンジン５３１２をさらに含む。送信エンジン５３１０は、Ｌ４パケット（例えばカプセル化されたＴＣＰ／ＩＰパケットを含むイーサネット（登録商標）パケット、ＩｎｆｉｎｉＢａｎｄパケット）及び／又はファブリックパケットがバッファリングされる送信バッファ５３１６を含む。１実施形態では、送信バッファ５３１６のメモリの全体又は一部分は、プログラムＩＯ（ＰＩＯ）空間とも呼ばれるメモリマップ入出力（ＭＭＩＯ）アドレス空間を構成する。ＭＭＩＯにより、プロセッサ５３０６は、例えば直接メモリアクセス（ＤＭＡ書込み）を介して、送信バッファ５３１４への直接書込みを実行することができる。
【０２７５】
受信エンジン５３１２は、受信バッファ５３１８及びＤＭＡエンジン５３２０を含む。受信バッファは、ファブリックパケット及び／又はＬ４パケットを含むことがある受信ポート５００２の出力をバッファリングするために使用される。ＤＭＡエンジン５３２０は、ＤＭＡ書込みを実行して、受信バッファ５３１８のパケットデータをメモリ５３０８及び／又はプロセッサ５３０６のメモリキャッシュレベルのうちの１つにコピーするように構成される。例えば、いくつかの実施形態では、パケットヘッダデータは、キャッシュにＤＭＡされるが、パケットのペイロードデータは、メモリにＤＭＡされる。
【０２７６】
プロセッサ５３０６は、一体化されたレベル１及びレベル２（Ｌ１／Ｌ２）のキャッシュをそれぞれ含み、コヒーレント相互接続５３２６にそれぞれ結合された、複数のプロセッサコア５３２４を含むＣＰＵ５３２２を含む。また、コヒーレント相互接続５３２６には、メモリ５３０８に結合されたメモリインタフェース５３２８と、一体化入出力ブロック（ＩＩＯ）５３３０と、ラストレベルキャッシュ（ＬＬＣ）５３３２とが結合される。ＩＩＯ５３３０は、プロセッサコア、メモリ及びキャッシュによって利用されるコヒーレント領域と、１対のＰＣＩｅルートコンプレックス（ＲＣ）５３３４及び５３３６などのＩＯ構成要素及びＩＯインタフェースのために利用される非コヒーレント領域との間のインタフェースを提供する。当技術分野では周知のように、ＰＣＩｅ  ＲＣは、ＰＣＩｅインタフェース５３３８、５３４０、５３４２及び５３４４で示すように複数のＰＣＩｅインタフェース及びＰＣＩｅデバイスを結合することができるＰＣＩｅ相互接続階層の最上位に位置する。図示のように、ＰＣＩｅ５３４０は、ＨＦＩ５３０２のＰＣＩｅインタフェース５３１４に結合される。
【０２７７】
図５３に示すような、いくつかの実施形態では、プロセッサ５３１２は、システムオンチップ（ＳｏＣ）アーキテクチャを利用する。他の実施形態では、ＰＣＩｅ関連構成要素が、ＩＯチップセットなどに集積される。さらに他の実施形態では、プロセッサ５３１２及び１つ又は複数のＨＦＩ５３０２が、ＳｏＣ５３４６の破線の輪郭で示すようなＳｏＣ上に一体化される。
【０２７８】
図５３にさらに示すように、ソフトウェアアプリケーション５３４８及びｖＮＩＣ５３５０は、プロセッサコア５３２４のうちの１つ又は複数、或いはプロセッサ５３０６上で動作するオペレーティングシステムをホストとする１つ又は複数の仮想マシン上で実行されるソフトウェア構成要素を含む。これらのソフトウェア構成要素に加えて、メモリ５３０８（適用可能なキャッシュレベルを含む）と送信エンジン５３１０及び受信エンジン５３１２との間のデータ転送を容易にするための追加のソフトウェア構成要素及びメモリ５３０８中に実装されたバッファがある。
【０２７９】
一般に、本明細書の図面に示す回路、論理、及び構成要素は、離散チップ、ＳｏＣ、マルチチップモジュール、及び複数のネットワークインタフェースのサポートを含むネットワーキング／リンクインタフェースチップなど、様々なタイプの集積回路（例えば半導体チップ）及びモジュールで実装することもできる。また、本明細書で使用する様々な動作を実行する回路及び論理は、１つ又は複数の埋込み論理、埋込みプロセッサ、制御装置、マイクロエンジンによって、或いはハードウェア、ソフトウェア及び／又はファームウェアの任意の組合せを用いて、実装することができる。例えば、様々な論理ブロック及び／又は回路によって示す動作は、ＡＳＩＣ、ＦＰＧＡ、ＩＰブロックライブラリなど（ただしこれらに限定されない）のプログラム論理ゲートなどを用いて実行する、或いはプロセッサ、プロセッサコア、制御装置、マイクロコントローラ、マイクロエンジンなどの１つ又は複数の処理要素上で実行されるソフトウェア又はファームウェア命令の１つ又は複数によって実行することもできる。
【０２８０】
さらに、本明細書の実施形態の特徴は、半導体チップ、ＳｏＣ、マルチチップモジュールなどのみでなく、非一時的機械可読媒体でも実施することができる。例えば、上述の設計を、半導体デバイスを設計するために使用される設計ツールと関連付けた非一時的機械可読媒体に記憶する、かつ／又は埋め込むことができる。例としては、ＶＨＳＩＣハードウェア記述言語（ＶＨＤＬ）言語、ベリログ言語又はＳＰＩＣＥ言語、或いはその他のハードウェア記述言語でフォーマットしたネットリストが挙げられる。ネットリストの例をいくつか挙げると、挙動レベルネットリスト、レジスタ転送レベル（ＲＴＬ）ネットリスト、ゲートレベルネットリスト、及びトランジスタレベルネットリストなどがある。機械可読媒体は、ＧＤＳ−ＩＩファイルなどのレイアウト情報を有する媒体も含む。
【０２８１】
さらに、半導体チップ設計用のネットリストファイル又はその他の機械可読媒体をシミュレーション環境で使用して、上述の教示の方法を実行することもできる。具体的な実施態様を参照していくつかの実施形態について説明したが、いくつかの実施形態によれば、その他の実施態様も可能である。さらに、図面に示し、かつ／又は本明細書で説明した要素又はその他の機構の配列及び／又は順序は、図示して説明した特定の方法で配列する必要はない。いくつかの実施形態によれば、その他の多数の配列が可能である。
【０２８２】
図面に示す各システムにおいて、いくつかの場合の要素は、その示されている要素が異なる、かつ／又は同様である可能性があることを示唆するために、同じ参照番号が付されていることも、異なる参照番号が付されていることもある。ただし、要素は、様々な実装態様を有するのに十分に柔軟であり、本明細書に示した、又は説明したシステムの一部又は全体とともに作用することができる。図面に示す様々な要素は、同じであることも、異なることもある。どの要素を第１の要素と呼び、どの要素を第２の要素と呼ぶかは、任意である。
【０２８３】
上記の詳細な説明及び特許請求の範囲における「ｎ」、「ｍ」、「ｋ」などのイタリック体の文字は、整数を表すために用いられており、ある特定の文字の使用が特定の実施形態に限定されることはない。さらに、同じ文字を使用しても、別の請求項では別の整数を表すこともあり、異なる文字を使用することもある。さらに、詳細な説明における特定の文字の使用は、詳細な説明と同じ主題に関連する請求項で用いている文字と一致する場合もあれば、一致しない場合もある。
【０２８４】
本明細書及び特許請求の範囲では、「結合される」及び「接続される」という用語、並びにそれらの派生表現を使用することがある。これらの用語は、互いに同義であると意図したものではないことを理解されたい。特定の実施形態では、「接続される」は、２つ以上の要素が互いに物理的又は電気的に直接接触していることを示すことがある。「結合される」は、２つ以上の要素が物理的又は電気的に直接接触していることを示すことがある。しかしながら、「結合される」は、２つ以上の要素が互いに直接接触していないが、互いに協働又は相互作用することを意味することもある。
【０２８５】
実施形態は、本発明の実施態様又は例である。本明細書において「実施形態」、「１実施形態」、「いくつかの実施形態」又は「他の実施形態」と述べているときには、その実施形態に関連して述べられている特定の機能、構造、又は特性が、少なくともいくつかの実施形態に含まれることを意味しており、必ずしも本発明の全ての実施形態に含まれることを意味しているわけではない。「実施形態」、「１実施形態」、又は「いくつかの実施形態」が様々な箇所で見られるが、これらは必ずしも同じ実施形態を指しているわけではない。
【０２８６】
本明細書に記載して図示した全ての構成要素、機能、構造、特性などが、特定の１つ又は複数の実施形態に含まれる必要はない。本明細書において、ある構成要素、機能、構造又は特性が、例えば「含まれる可能性がある」、「含まれる可能性もある」、「含むことができる」、又は「含むこともできる」などと述べられている場合、その特定の構成要素、機能、構造又は特性は、含まれる必要があるわけではない。本明細書又は特許請求の範囲において、単に「要素（”ａ”  ｏｒ  ”ａｎ”  ｅｌｅｍｅｎｔ）」と述べている場合には、これは、その要素が１つしかないという意味ではない。本明細書又は特許請求の範囲において、「追加の要素（”ａｎ  ａｄｄｉｔｉｏｎａｌ”  ｅｌｅｍｅｎｔ）」と述べている場合には、これは、その追加の要素が複数存在することを排除するものではない。
【０２８７】
要約書に記載したものも含めて、例示した本発明の実施形態の上記の説明には、排他的な意図、又は開示した厳密な形態に本発明を限定する意図はない。例示を目的として、本発明の具体的な実施形態及び例を本明細書に記載したが、当業者なら、本発明の範囲内で、様々な等価な修正形態が可能であることを認識するであろう。
【０２８８】
これらの修正は、上記の詳細な説明に照らして、本発明に加えることができる。以下の特許請求の範囲で使用する用語は、本発明を本明細書及び図面に開示した具体的な実施形態に限定するものとして解釈すべきではない。本発明の範囲は、以下の特許請求の範囲によって完全に決定され、特許請求の範囲は、確立されたクレーム解釈の法理に従って解釈されるものとする。
【図１】
0006297698.tif 000010
【図２】
0006297698.tif 000011
【図３】
0006297698.tif 000012
【図４】
0006297698.tif 000013
【図５】
0006297698.tif 000014
【図６】
0006297698.tif 000015
【図７】
0006297698.tif 000016
【図８】
0006297698.tif 000017
【図９ａ】
0006297698.tif 000018
【図９ｂ】
0006297698.tif 000019
【図１０】
0006297698.tif 000020
【図１１】
0006297698.tif 000021
【図１２】
0006297698.tif 000022
【図１３】
0006297698.tif 000023
【図１４】
0006297698.tif 000024
【図１５】
0006297698.tif 000025
【図１６】
0006297698.tif 000026
【図１７】
0006297698.tif 000027
【図１８ａ】
0006297698.tif 000028
【図１８ｂ】
0006297698.tif 000029
【図１８ｃ】
0006297698.tif 000030
【図１９】
0006297698.tif 000031
【図２０】
0006297698.tif 000032
【図２１】
0006297698.tif 000033
【図２２ａ】
0006297698.tif 000034
【図２２ｂ】
0006297698.tif 000035
【図２２ｃ】
0006297698.tif 000036
【図２２ｄ】
0006297698.tif 000037
【図２２ｅ】
0006297698.tif 000038
【図２３ａ】
0006297698.tif 000039
【図２３ｂ】
0006297698.tif 000040
【図２４】
0006297698.tif 000041
【図２５】
0006297698.tif 000042
【図２６】
0006297698.tif 000043
【図２７】
0006297698.tif 000044
【図２８】
0006297698.tif 000045
【図２９】
0006297698.tif 000046
【図３０】
0006297698.tif 000047
【図３１ａ】
0006297698.tif 000048
【図３１ｂ】
0006297698.tif 000049
【図３１ｃ】
0006297698.tif 000050
【図３２】
0006297698.tif 000051
【図３３】
0006297698.tif 000052
【図３４】
0006297698.tif 000053
【図３５】
0006297698.tif 000054
【図３６】
0006297698.tif 000055
【図３７】
0006297698.tif 000056
【図３８】
0006297698.tif 000057
【図３９】
0006297698.tif 000058
【図４０】
0006297698.tif 000059
【図４１】
0006297698.tif 000060
【図４２】
0006297698.tif 000061
【図４３】
0006297698.tif 000062
【図４４】
0006297698.tif 000063
【図４５】
0006297698.tif 000064
【図４６】
0006297698.tif 000065
【図４７】
0006297698.tif 000066
【図４８】
0006297698.tif 000067
【図４９】
0006297698.tif 000068
【図５０】
0006297698.tif 000069
【図５１】
0006297698.tif 000070
【図５２】
0006297698.tif 000071
【図５３】
0006297698.tif 000072