特表2016-530764IP Force 特許公報全文掲載

ホーム > 特許ランキング > インテル　コーポレイション > 特表2016-530764

(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】特表2016-530764(P2016-530764A)
(43)【公表日】2016年9月29日
(54)【発明の名称】リンクファブリックパケットとは非同期なフリットバンドルを用いたリンク転送、ビットエラー検出、及びリンクリトライ
(51)【国際特許分類】
   H04L 29/00 20060101AFI20160902BHJP
   G06F 3/00 20060101ALI20160902BHJP
   G06F 15/173 20060101ALI20160902BHJP
【ＦＩ】
   H04L13/00 S
   G06F3/00 E
   G06F15/173 685A
【審査請求】有
【予備審査請求】未請求
【全頁数】62
(21)【出願番号】特願2016-524398(P2016-524398)
(86)(22)【出願日】2014年12月5日
(85)【翻訳文提出日】2015年12月24日
(86)【国際出願番号】US2014068889
(87)【国際公開番号】WO2015085231
(87)【国際公開日】20150611
(31)【優先権主張番号】14/099,291
(32)【優先日】2013年12月6日
(33)【優先権主張国】US
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US
(71)【出願人】
【識別番号】593096712
【氏名又は名称】インテル コーポレイション
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100091214
【弁理士】
【氏名又は名称】大貫 進介
(72)【発明者】
【氏名】ビリッテルラ，マーク エス．
【テーマコード（参考）】
5B045
5K034
【Ｆターム（参考）】
5B045BB15
5B045BB38
5B045JJ07
5B045JJ38
5K034AA07
5K034DD03
5K034FF02
5K034HH09
5K034HH12
5K034HH63
5K034HH64
5K034MM01
5K034MM14
5K034MM25
(57)【要約】
リンクファブリックパケットとは非同期なフリットバンドルを用いたリンク転送、ビットエラー検出、及びリンクリトライのための方法、装置、及びシステム。ファブリックパケットを含む第１のタイプのパケットが生成され、そのデータコンテンツが「フリット」と呼ばれる複数のデータユニットに分割される。次いで、フリットが、リンク転送パケット（ＬＴＰ）を含む第２のタイプのパケットにまとめられる。次いで、ＬＴＰが、多数のポイントツーポイントリンクを含むファブリックにおいて、単一リンクセグメントを介して送信される。各ＬＴＰは、各リンクセグメントを介して送信されるデータがエラーを有さないことを確実にするために使用されるＣＲＣを含み、再送信のユニットを含む。ファブリックパケットのサイズは変わり得るものであり、ファブリックパケットは、ＬＴＰより大きいこともあるし小さいこともある。転送スキームは、複数のファブリックパケットからのフリットを１つのＬＴＰにまとめることを可能にした。ファブリックエンドポイントにおける受信時に、ＬＴＰからフリットが抽出されて再組み立てされ、ファブリックパケットが再生成される。
【特許請求の範囲】
【請求項1】
リンクインタフェースであって、
受信ポートと、
複数のファブリックパケットを生成し、
各ファブリックパケットを複数のデータユニットに分割し、
前記データユニットをグループにまとめて、複数のリンクパケットを形成し、
前記複数のリンクパケットを、リンクを介して受信機に向けて送信する、
ための回路及びロジックを有する送信ポートと、
を含むリンクインタフェース
を備え、
前記複数のリンクパケットのうちの少なくとも１つは、少なくとも２つのファブリックパケットからのデータユニットを含む、装置。
【請求項2】
各リンクパケットは、予め定められた数の固定サイズのフリットを含む、請求項１記載の装置。
【請求項3】
前記複数のファブリックパケットのうちの少なくとも１つは、各リンクパケットのフリットの前記予め定められた数よりも少ない第１の数のフリットを含み、前記複数のファブリックパケットのうちの少なくとも１つは、各リンクパケットのフリットの前記予め定められた数よりも多い第２の数のフリットを含む、請求項２記載の装置。
【請求項4】
前記送信ポートは、各リンクパケットに含まれるデータに対するデータインテグリティチェック値を計算して、前記データインテグリティチェック値を前記リンクパケットに含めるための回路及びロジックを有する、請求項１乃至３いずれか一項記載の装置。
【請求項5】
各ファブリックパケットは、ヘッドフリットを含む最初のデータユニットと、前記最初のデータユニットに続く複数のボディフリットと、最後にテールフリットを含む最後のデータユニットと、を含む複数の異なるタイプのデータユニットに分割される、請求項１乃至４いずれか一項記載の装置。
【請求項6】
リンクパケット内の各データユニットは、フリットタイプビットを含む、請求項５記載の装置。
【請求項7】
リンクパケット内のどこにでも、任意のタイプのデータユニットを配置することができる、請求項５又は６記載の装置。
【請求項8】
前記複数のリンクパケットのうちの１つは、制御データユニットを含む少なくとも１つのタイプのデータユニットを含み、
前記リンクインタフェースは、
前記受信ポートにおいて受信されたリンクパケット内の制御データユニットを検出し、
前記制御データユニットにより特定される制御オペレーションを実行する、
ためのさらなる回路及びロジックを含む、請求項１乃至７いずれか一項記載の装置。
【請求項9】
前記送信ポートから送信される前記複数のリンクパケットは、第１の複数のパケットを含み、
前記受信ポートは、
第２の複数のファブリックパケットから分割されたデータを含むデータユニットを含む第２の複数のリンクパケットを受信し、
前記第２の複数のリンクパケットからデータユニットを抽出し、
該データユニットを再組み立てして、前記第２の複数のファブリックパケットを再生成する、
ための回路及びロジックを有し、
前記第２の複数のリンクパケットのうちの少なくとも１つは、少なくとも２つのファブリックパケットからのデータユニットを含む、請求項１乃至８いずれか一項記載の装置。
【請求項10】
各リンクパケットは、送信されたとき、前記リンクパケットに含まれるデータに対して計算された送信側データインテグリティチェック値を含み、
前記受信ポートは、
各リンクパケット内の受信されたデータに対する受信側データインテグリティチェック値を計算し、
前記受信側データインテグリティチェック値を前記送信側データインテグリティチェック値と比較して、前記リンクパケットがエラーを有するかどうかを検出し、
前記リンクパケットがエラーを有する場合、前記リンクパケットの送信元のリンクピアに再送信リクエストを送信する、
ためのさらなる回路及びロジックを有する、請求項１乃至９いずれか一項記載の装置。
【請求項11】
前記リンクインタフェースは、
リンクピアから再送信リクエストを受信したことに応答して、
前記再送信リクエストがなされた前記リンクパケットを特定し、
前記リンクパケットを再送信する、
ためのさらなる回路及びロジックを含む、請求項１０記載の装置。
【請求項12】
複数の第１のタイプのパケットを生成するステップと、
各第１のタイプのパケットを複数のデータユニットに分割するステップと、
前記データユニットをグループにまとめて、複数の第２のタイプのパケットを形成するステップと、
前記複数の第２のタイプのパケットを、リンクを介して受信機に向けて送信するステップと、
を含み、
前記複数の第２のタイプのパケットのうちの少なくとも１つは、少なくとも２つの第１のタイプのパケットからのデータユニットを含む、方法。
【請求項13】
各第２のタイプのパケットは、予め定められた数のデータユニットを含む、請求項１２記載の方法。
【請求項14】
前記複数の第１のタイプのパケットのうちの少なくとも１つは、各第２のタイプのパケットのデータユニットの前記予め定められた数よりも少ない第１の数のデータユニットを含み、前記複数の第１のタイプのパケットのうちの少なくとも１つは、各第２のタイプのパケットのデータユニットの前記予め定められた数よりも多い第２の数のデータユニットを含む、請求項１３記載の方法。
【請求項15】
当該方法は、複数のリンクを含むファブリックにおいて第１のリンクを介してファブリックスイッチの受信ポートに結合されている第１のファブリックエンドポイントの送信ポートにより実行され、少なくとも１つの第１のタイプのパケットは、前記第１のリンクを含む複数のリンクを含む転送パスを介して、第２のファブリックエンドポイントに送信され、前記第２のタイプのパケットは、前記第１のリンクを介して、前記受信ポートに送信され、さらに転送されることはない、請求項１２乃至１４いずれか一項記載の方法。
【請求項16】
各第２のタイプのパケットは、前記受信機により受信された第２のタイプのパケット内のデータがエラーを有さないことを確認するために使用されるデータインテグリティチェック値を含み、各第２のタイプのパケットは、前記第２のタイプのパケットの元の送信においてエラーが検出されたときに再送信される再送信ユニットを含む、請求項１２乃至１５いずれか一項記載の方法。
【請求項17】
各第１のタイプのパケットは、ヘッドデータユニットを含む最初のデータユニットと、前記最初のデータユニットに続く複数のボディデータユニットと、最後にテールデータユニットを含む最後のデータユニットと、を含む複数の異なるタイプのデータユニットに分割される、請求項１２乃至１６いずれか一項記載の方法。
【請求項18】
前記複数の第２のタイプのパケットのうちの１つは、制御データユニットを含む少なくとも１つのタイプのデータユニットを含む、請求項１２乃至１７いずれか一項記載の方法。
【請求項19】
第２の複数のファブリックパケットから分割されたデータを含むデータユニットを含む第２の複数のリンクパケットを受信するステップと、
前記第２の複数のリンクパケットからデータユニットを抽出するステップと、
該データユニットを再組み立てして、前記第２の複数のファブリックパケットを再生成するステップと、
をさらに含み、
前記第２の複数のリンクパケットのうちの少なくとも１つは、少なくとも２つのファブリックパケットからのデータユニットを含む、請求項１２乃至１８いずれか一項記載の方法。
【請求項20】
第１のコンポーネント及び第２のコンポーネントを備えたシステムであって、前記第１のコンポーネント及び前記第２のコンポーネントの各々は、リンクに結合されるよう構成されているリンクインタフェースであって、他方のリンクインタフェースとのリンクピアとして動作するよう構成されているリンクインタフェースを含み、各リンクインタフェースは、
第１の複数のファブリックパケットを生成し、
各ファブリックパケットを複数のフリットに分割し、
前記フリットをグループにまとめて、第１の複数のリンクパケットを形成し、
前記第１の複数のリンクパケットを、前記リンクを介して、各リンクインタフェースのリンクピアの前記リンクインタフェースに向けて送信し、
各リンクインタフェースのリンクピアから前記リンクを介して送信された第２の複数のリンクパケットを受信し、ここで、前記第２の複数のリンクパケットは、第２の複数のファブリックパケットから分割されたフリットを含み、
前記第２の複数のリンクパケットからフリットを抽出し、
該フリットを再組み立てして、前記第２の複数のファブリックパケットを再生成する、
よう構成されており、
前記第１の複数のリンクパケット及び前記第２の複数のリンクパケットの各々の少なくとも一部は、少なくとも２つのファブリックパケットからのフリットを含む、システム。
【請求項21】
各フリットは、固定サイズを有し、各リンクパケットは、固定数のフリットを有し、前記第１の複数のファブリックパケット及び前記第２の複数のファブリックパケットのサイズは変わる、請求項２０記載のシステム。
【請求項22】
各リンクインタフェースは、
送信される各リンクパケットに含まれるデータに対する送信側データインテグリティチェック値を計算して、前記送信側データインテグリティチェック値を前記リンクパケットに含めるための回路及びロジックを有する送信ポートと、
受信された各リンクパケット内の受信されたデータに対する受信側データインテグリティチェック値を計算し、前記受信側データインテグリティチェック値を前記送信側データインテグリティチェック値と比較して、前記リンクパケットがエラーを有するかどうかを検出するための回路及びロジックを有する受信ポートと、
を含む、請求項２０又は２１記載のシステム。
【請求項23】
前記第１のコンポーネント及び前記第２のコンポーネントのうちの少なくとも１つは、リンクインタフェースを含むホストファブリックインタフェースであって、
送信される各ファブリックパケットに含まれるデータに対する送信側巡回冗長チェックサム（ＣＲＣ）を計算し、
再生成された各ファブリックパケットに含まれるデータに対する受信側ＣＲＣを計算し、
前記送信側ＣＲＣと前記受信側ＣＲＣとを比較して、前記の再生成されたファブリックパケットがエラーを含むかどうかを判定する、
ための回路及びロジックをさらに含むホストファブリックインタフェースを含む、請求項２０乃至２２いずれか一項記載のシステム。
【請求項24】
前記第１のコンポーネント及び前記第２のコンポーネントのうちの少なくとも１つは、リンクインタフェースが集積されているホストインタフェースチップを含み、
前記ホストインタフェースチップは、
少なくとも１つの送信バッファを含む、前記リンクインタフェースの送信ポートに結合されている送信エンジンと、
少なくとも１つの受信バッファを含む、前記リンクインタフェースの受信ポートに結合されている受信エンジンと、
前記送信エンジン及び前記受信エンジンの各々に結合されている周辺コンポーネント相互接続エクスプレス（ＰＣＩｅ）インタフェースと、
を含む、請求項２０乃至２３いずれか一項記載のシステム。
【請求項25】
前記第１のコンポーネント及び前記第２のコンポーネントのうちの少なくとも１つは、
システムオンチップ（ＳｏＣ）であって、
リンクインタフェースが集積されているホストファブリックインタフェースであって、
少なくとも１つの送信バッファを含む、前記リンクインタフェースの送信ポートに結合されている送信エンジンと、
少なくとも１つの受信バッファを含む、前記リンクインタフェースの受信ポートに結合されている受信エンジンと、
前記送信エンジン及び前記受信エンジンの各々に結合されている周辺コンポーネント相互接続エクスプレス（ＰＣＩｅ）インタフェースと、
を含むホストファブリックインタフェース
を含むＳｏＣと、
前記ホストファブリックインタフェースの前記ＰＣＩｅインタフェースに結合されているＰＣＩｅインタフェースを含むプロセッサと、
を含む、請求項２０乃至２４いずれか一項記載のシステム。
【発明の詳細な説明】
【背景技術】
【0001】
高性能計算（ＨＰＣ）は、ここ数年、使用及び関心の大幅な増加が見られている。歴史的には、ＨＰＣは、一般に、いわゆる「スーパーコンピュータ」に関するものであった。スーパーコンピュータは、１９６０年代に導入され、コントロール・データ・コーポレーション（ＣＤＣ）においてシーモア・クレイにより最初に作られ、数十年にわたって、ＣＤＣ、クレイ・リサーチ、及びクレイの名前又はモノグラムを有するその後の会社においてシーモア・クレイにより主に作られてきた。１９７０年代のスーパーコンピュータは、数個のプロセッサしか使用しなかったが、１９９０年代には、数千個のプロセッサを有するマシンが出現し始め、より最近では、数十万個の「市販」プロセッサを有する超並列スーパーコンピュータが実現されている。
【0002】
実現型及び研究指向型の両方で、様々なレベルの規模及び性能を有する多くのタイプのＨＰＣアーキテクチャが存在する。しかしながら、一般的なスレッド（thread）は、プロセッサ及び／又はプロセッサコア等の、協調して並列にタスクを実行する多数のコンピュートユニットの相互接続である。最近のシステムオンチップ（ＳｏＣ）設計及び提案の下では、多数のプロセッサコア又は同様のものが、２次元（２Ｄ）アレイ、トーラス、リング、又は他の構成を用いて、単一のＳｏＣ上に実装されている。さらに、研究者達は、数百個のプロセッサコア又はさらには数千個のプロセッサコアが３Ｄアレイにおいて相互接続される３Ｄ ＳｏＣを提案している。別々のマルチコアプロセッサ及びＳｏＣはまた、サーバボード上に密集していることがあり、サーバボードが、今度は、バックプレーン又は同様のものを介する通信において相互接続される。別の一般的なアプローチは、通常は２Ｄアレイにおいて構成されるサーバ（例えば、ブレードサーバ及びモジュール）のラック内でコンピュートユニットを相互接続することである。世界の最速スーパーコンピュータと思われるＩＢＭ（登録商標）のセコイアは、２Ｄアレイの、計１５７２８６４個のコアを有するサーバブレード／モジュールの９６個のラックを備え、最高性能下で動作するときには実に７．９メガワットもの電力を消費する。
【0003】
ＨＰＣの性能ボトルネックのうちの１つは、コンピュートノード間においてインターコネクトを介してデータを転送することから生じる遅延である。通常、インターコネクトは、インターコネクト階層で構造化され、階層の最上位には、プロセッサ／ＳｏＣ内に最高速度で最短のインターコネクトが存在するのに対し、階層レベルが下がるにつれ遅延が増大する。例えば、プロセッサ／ＳｏＣレベルの後に、インターコネクト階層は、プロセッサ間インターコネクトレベル、ボード間インターコネクトレベル、及び、個々のサーバ群又は個々のサーバ群の集合体群（aggregations）を他のラック内のサーバ群／集合体群に接続する１以上のさらなるレベルを含み得る。
【0004】
インターコネクト階層の１以上のレベルは、異なるプロトコルを使用することが一般的である。例えば、ＳｏＣ内のインターコネクトは、通常、専用であるのに対し、階層におけるより下位のレベルは、専用インターコネクト又は標準インターコネクトを使用し得る。異なるインターコネクトレベルはまた、通常、異なる物理（ＰＨＹ）レイヤを実装する。結果として、インターコネクトレベル間をブリッジする何らかのタイプのインターコネクトを使用する必要がある。加えて、異種のコンピュート環境が実装される場合には、所与のインターコネクトレベルにおいてブリッジングが必要なこともある。
【0005】
インターコネクト階層のより下位のレベルでは、（様々なＩＥＥＥ８０２．３規格において規定されている）イーサネット（登録商標）及びインフィニバンド等の標準インターコネクトが使用される。ＰＨＹレイヤでは、これら規格の各々は、ワイヤケーブルやバックプレーンを介するもの等の有線接続に加えて、光リンクをサポートしている。イーサネット（登録商標）は、ＯＳＩ７レイヤモデルにおけるリンクレイヤ（レイヤ２）で実装され、基本的にリンクレイヤプロトコルとみなされる。インフィニバンド規格は、ＯＳＩレイヤ１〜４をカバーする、インフィニバンドのための様々なＯＳＩレイヤの態様を規定している。
【0006】
現在のイーサネット（登録商標）プロトコルは、イーサネット（登録商標）リンクを介するデータの高信頼性送信（reliable transmission）をサポートするための固有の機能を有していない。これは、インフィニバンドのリンクレイヤ実装にも同じことが言える。各々は、ＴＣＰ／ＩＰ等のより上位のレイヤで高信頼性送信に対処する。ＴＣＰ下では、データの高信頼性配信（reliable delivery）は、センダ（sender）からＩＰパケットを受信したことに応答して、（ＩＰ宛先アドレスにおける）レシーバ（receiver）から（ＩＰ送信元アドレスにおける）センダに返される明示的アクノレッジメント（ＡＣＫ）により実現される。パケットは、センダとレシーバとの間のルートに沿った複数のノードのうちの１つのノードにおいてドロップされる可能性があるので（あるいは、レシーバが十分なバッファスペースを有していない場合には、パケットは、レシーバにおいてもドロップされる可能性があるので）、明示的ＡＣＫが、各パケットの配信の成功を確認するために使用される（１つのＡＣＫ応答により、複数のＩＰパケットの配信を確認することができることに留意されたい）。送信ＡＣＫスキームは、送信元デバイス及び宛先デバイスの各々において大きなバッファスペースが保持されることを必要とし（ドロップされた１以上のパケットが再送信される必要がある場合）、また、さらなる処理及び複雑さをネットワークスタックに加える。例えば、ＡＣＫはドロップされる可能性があるので、センダはまた、タイマを使用する。タイマは、タイマのタイムアウト期間内にＡＣＫが受信されなかったパケットの再送信をトリガするために使用される。各ＡＣＫは、貴重なリンク帯域幅を消費し、さらなる処理オーバーヘッドを発生させる。加えて、タイマの使用は、リンクラウンドトリップ遅延に対する上限を設定する。
【図面の簡単な説明】
【0007】
添付の図面と併せて以下の詳細な説明を参照することにより、前述の態様及び本発明の付随する利点の多くが、より良く理解されるとともに、より容易に理解されるであろう。図面において、同様の参照符号は、別途明示されない限り、様々な図面を通して、同様の部分を指す。
【図1】一実施形態に従った、ファブリックアーキテクチャの様々なコンポーネント及びインターコネクトを含むシステムの高レベルビューを示す概略図。
【図2】一実施形態に従った、ファブリックリンクを介してデータを転送するためのアーキテクチャのレイヤを示す概略図。
【図3】バンドルにグループ化された複数のフリットを示す概略図。
【図4】一実施形態に従った、ファブリックパケットの構造を示す概略図。
【図5】一実施形態に従った、標準型検出ＬＴＰのデータ構造を示す図。
【図6】一実施形態に従った、１４ビットＣＲＣ ＬＴＰのデータ構造を示す図。
【図7】一実施形態に従った、拡張型検出ＬＴＰのデータ構造を示す図。
【図8】一実施形態に従った、標準型検出ヌルＬＴＰのデータ構造を示す図。
【図9a】一実施形態に従った、リンクファブリックサブレイヤとリンク転送サブレイヤとの間のインタフェースにおいて標準型検出ＬＴＰのフリットが同時に２つ並列に処理される、４レーンリンクのための送信スキームの実施形態を示す図。
【図9b】一実施形態に従った、リンクファブリックサブレイヤとリンク転送サブレイヤとの間のインタフェースにおいて拡張型検出ＬＴＰのフリットが同時に２つ並列に処理される、４レーンリンクのための送信スキームの実施形態を示す図。
【図10】一実施形態に従った、リンクファブリックサブレイヤとリンク転送サブレイヤとの間のインタフェースにおいて２つのフリットが同時に２つ並列に処理される、４レーンリンクを介する２つの制御ビットを含む１つの１４ビットＣＲＣ ＬＴＰの送信を示す概略図。
【図11】一実施形態に従った、一緒にグループ化された２つの４レーンリンクを含む８レーンデータパスを介する、それぞれ２つの制御ビットを含む２つの１４ビットＣＲＣ ＬＴＰの並列送信を示す概略図。
【図12】一実施形態に従った、４つのレーンを使用する２つのリンクポート間における双方向データ送信の一例を示す概略図。
【図13】別々の仮想レーンを介して送信される２つのファブリックパケットからのファブリックパケットフリットをインターリーブする実施形態の一例を示す図。
【図14】一実施形態に従った、プッシュ及びポップインターリービングの使用を示す図。
【図15】一実施形態に従った、プッシュ及びポップインターリービングとＶＬマーカインターリービングとの組合せの使用を示す図。
【図16】一実施形態に従った、別々の優先度レベルを有するＶＬに対応する３つの別々のＶＬ ＦＩＦＯにバッファされた３つのファブリックパケットからのフリットのプリエンプティブインターリービングの一例を示す、構成及び時間フローの組合せ図。
【図17】一実施形態に従った、２つのＶＬが１つの優先度レベルを共有し、他のＶＬがより高い優先度レベルを有する、３つの別々のＶＬ ＦＩＦＯにバッファされた３つのファブリックパケットからのフリットのバブルインターリービング及びプリエンプティブインターリービングの一例を示す、構成及び時間フローの組合せ図。
【図18a】一実施形態に従った、ＬＴＰレーン及び不良レーンを検出するための、ＬＴＰ送信スキームの送信と、レーン毎ＣＲＣ及びＬＴＰ ＣＲＣの使用と、を示す概略図であって、ＬＴＰ送信スキームにおけるＬＴＰの元の送信を示す概略図。
【図18b】一実施形態に従った、ＬＴＰレーン及び不良レーンを検出するための、ＬＴＰ送信スキームの送信と、レーン毎ＣＲＣ及びＬＴＰ ＣＲＣの使用と、を示す概略図であって、リプレイバッファを用いたＬＴＰ送信ストリームにおけるＬＴＰの再送信を示す概略図。
【図18c】一実施形態に従った、リプレイバッファＬＴＰが上書きされることを防止するためのリトライマーカ及びラウンドトリップマーカの使用を示す概略図。
【図19】一実施形態に従った、３３個の転送グループ（ＸＦＲ）を用いた標準型検出ＬＴＰの送信を示す図。
【図20】一実施形態に従った、３３個の３２ビットＸＦＲ及び４つのＬＴＰシーケンス状態を用いた４レーンリンクを介するＬＴＰの送信を示す図。
【図21】一実施形態に従った、３３個の３２ビットＸＦＲを用いて、８バイトのデータ及び６５番目のビットを含むフリットデータが４レーンリンクを介してどのように転送されるかを示す図。
【図22a】一実施形態に従った、リプレイバッファとともに暗示的ＡＣＫを用いてリンクレベルでの高信頼性ＬＴＰ送信を円滑にするためのオペレーション及びロジックを示すとともに、不良レーンを検出するためのオペレーション及びロジックを示すフローチャート。
【図22b】一実施形態に従った、リプレイバッファとともに暗示的ＡＣＫを用いてリンクレベルでの高信頼性ＬＴＰ送信を円滑にするためのオペレーション及びロジックを示すとともに、不良レーンを検出するためのオペレーション及びロジックを示すフローチャート。
【図22c】一実施形態に従った、リプレイバッファとともに暗示的ＡＣＫを用いてリンクレベルでの高信頼性ＬＴＰ送信を円滑にするためのオペレーション及びロジックを示すとともに、不良レーンを検出するためのオペレーション及びロジックを示すフローチャート。
【図22d】一実施形態に従った、リプレイバッファとともに暗示的ＡＣＫを用いてリンクレベルでの高信頼性ＬＴＰ送信を円滑にするためのオペレーション及びロジックを示すとともに、不良レーンを検出するためのオペレーション及びロジックを示すフローチャート。
【図22e】一実施形態に従った、リプレイバッファとともに暗示的ＡＣＫを用いてリンクレベルでの高信頼性ＬＴＰ送信を円滑にするためのオペレーション及びロジックを示すとともに、不良レーンを検出するためのオペレーション及びロジックを示すフローチャート。
【図23a】一実施形態に従った、送信機の状態図。
【図23b】一実施形態に従った、受信機の状態図。
【図24】一実施形態に従った、ＸＦＲグループ単位で計算されて記憶されるレーン毎ＣＲＣを示す図。
【図25】第１のＬＴＰシーケンス状態下で不良ＬＴＰが元々送信されるときにレーン毎ＣＲＣが計算され、第３のＬＴＰシーケンス状態下でリプレイバッファからの不良ＬＴＰが再送信されるときにレーン毎ＣＲＣが計算された、図１８ａ及び図１８ｂの例についてのＸＦＲグループ単位で記憶されている例示的なレーン毎ＣＲＣ計算値を示す図。
【図26】一実施形態に従った、１レーン当たり１１個のＸＦＲが並列に転送される、３つのレーンを介する標準型検出ＬＴＰの転送を示す図。
【図27】一実施形態に従った、２つのレーンを介する標準型検出ＬＴＰの転送であって、１７個のＸＦＲは２つのレーンのうちの一方を介して転送され、１６個のＸＦＲは他方のレーンを介して転送され、２つのＬＴＰシーケンス状態が使用される転送を示す図。
【図28】一実施形態に従った、３３個の３２ビットＸＦＲを用いた１つのレーンを介する標準型検出ＬＴＰの送信を示す図。
【図29】一実施形態に従った、ＨＦＩを含むシステムの概略図。
【発明を実施するための形態】
【0008】
リンクファブリックパケットとは非同期なフリットバンドル（flit bundle、フリット束）を用いたリンク転送、ビットエラー検出、及びリンクリトライのための方法、装置、及びシステムの実施形態について、本明細書で説明する。以下の説明において、本発明の実施形態の完全な理解を提供するために、多数の具体的な詳細が記載されている。しかしながら、当業者は、それら具体的な詳細のうちの１以上がなくても、あるいは、他の方法、コンポーネント、材料等を用いて、本発明を実施できることが理解されよう。他の例においては、周知の構造、材料、又はオペレーションは、本発明の態様を曖昧にするのを避けるために、詳細には図示又は説明されない。
【0009】
本明細書全体を通じた「一実施形態」又は「ある実施形態」との言及は、その実施形態に関連して説明される特定の特徴、構造、又は特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書全体を通じた様々な箇所における「一実施形態において」又は「ある実施形態において」という語句の出現は、必ずしも全て同じ実施形態を指すとは限らない。さらに、それら特定の特徴、構造、又は特性は、１以上の実施形態において、任意の適切な態様で組み合わされてよい。
【0010】
明瞭さのために、図中の個々のコンポーネントは、本明細書において、特定の参照符号ではなく、図中のそのラベルにより参照されることもある。さらに、特定のタイプのコンポーネント（特定のコンポーネントではない）を参照する参照符号は、その後に「典型的、代表的（typical）」を意味する「（ＴＹＰ）」が続いて図示されていることがある。そのようなコンポーネントの構成は、存在し得るが簡潔さ及び明瞭さのために図中には示されていない類似するコンポーネントの典型例である。反対に、「（ＴＹＰ）」は、そのようなコンポーネント、要素等が、開示する機能、実装、目的等のために典型的に使用されることを意味するものとして解釈されるべきではない。
【0011】
本明細書で説明する実施形態の態様に従うと、メッセージ通過交換サーバ相互接続ネットワークを規定するアーキテクチャが提供される。アーキテクチャは、ＯＳＩネットワークモデルレイヤ１及び２に及び、レイヤ３のＩＥＴＦインターネットプロトコルを利用し、アーキテクチャのレイヤ４のための新たな仕様及び修正仕様の組合せを含む。
【0012】
アーキテクチャは、スーパーコンピュータ等、公式に規定することにより、あるいは、クラウドコンピューティングにおいてよく見受けられるように、サーバ群が実行するメッセージ交換アプリケーションに起因して何がしか協調するよう機能するそれらサーバ群のグループ又はクラスタ等、単に関連付けることにより、ＣＰＵと論理メッセージ交換構成を含む他のサブシステムとを相互接続するために実装され得る。相互接続されるコンポーネントはノードと呼ばれる。アーキテクチャはまた、プロセッサノードを、ＳｏＣ、マルチチップモジュール、又は同様のものと相互接続するために実装され得る。ホストと呼ばれるノードの一タイプは、ユーザモードソフトウェアが実行されるタイプである。一実施形態において、ホストは、１つのキャッシュコヒーレントメモリ領域を含み（コヒーレント領域におけるコア又はＣＰＵの数とは関係なく）、様々なローカルＩ／Ｏサブシステム及び記憶サブシステムを含み得る。ホストが実行するタイプのソフトウェアは、ユーザアプリケーションノード又は記憶サーバ若しくはファイルサーバ等、より特殊化された機能を規定することができ、より詳細なシステムアーキテクチャを表すよう機能する。
【0013】
最上位レベルにおいて、アーキテクチャは、以下のコンポーネントを規定する：
・ホストファブリックインタフェース（ＨＦＩ：Host Fabric Interface）；
・リンク；
・スイッチ；
・ゲートウェイ；及び
・包括的管理モデル（comprehensive management model）。
【0014】
ノードが、ファブリック（fabric）に接続して、他のサーバ又はデバイスとの間でパケットを送受信することができるように、ホストファブリックインタフェースは、アーキテクチャの物理レイヤ及びリンクレイヤを実装するためのロジックを少なくとも含む。ＨＦＩは、オペレーティングシステム及びＶＭＭ（仮想マシンマネージャ）のサポートのための適切なハードウェアインタフェース及びドライバを含む。ＨＦＩはまた、上位レイヤプロトコル、及び／又は、トランスポートプロトコルのオフロードを実行又は促進するための特殊化されたロジックを含み得る。ＨＦＩはまた、ネットワーク管理コンポーネントからのメッセージに応答するためのロジックを含む。各ホストは、ＨＦＩを介してアーキテクチャファブリックに接続される。
【0015】
リンクは、ＨＦＩをスイッチに接続し、スイッチを他のスイッチに接続し、あるいは、スイッチをゲートウェイに接続する全二重ポイントツーポイントインターコネクトである。リンクは、回路基板トレース、銅ケーブル、又は光ケーブルにおいて、様々な物理的構成を有することができる。一実施形態において、ＰＨＹ（物理レイヤ）、ケーブル、及びコネクタの方策（strategy）の実装は、イーサネット（登録商標）用のもの、特に、１００ＧｂＥ（ＩＥＥＥ８０２．３ｂｊドラフト規格（現ドラフト２．２）において規定されているイーサネット（登録商標）リンク等の、毎秒１００ギガビットイーサネット（登録商標））に従う。アーキテクチャは、柔軟性があり、１００ＧｂＥ帯域幅を超えるであろう将来のイーサネット（登録商標）技術又は他のリンク技術の使用をサポートしている。ハイエンドスーパーコンピュータ製品は、特殊目的（はるかに高い帯域幅）のＰＨＹを使用し得るものであり、そのような構成に関して、アーキテクチャ製品との相互運用性は、異なるＰＨＹを有するポートを備えたスイッチに基づくことになる。
【0016】
スイッチは、ＯＳＩレイヤ２コンポーネントであり、アーキテクチャの管理インフラストラクチャにより管理される。アーキテクチャは、そのＯＳＩレイヤ３又はインターネットワーキングレイヤとしてインターネットプロトコルを規定するが、アーキテクチャは、ＩＰドメインにおいて何も指定しないし、ＩＰ関連デバイスを管理しない。アーキテクチャファブリックと、外部ネットワーク、特にイーサネット（登録商標）と、の間の接続をサポートするデバイスは、ゲートウェイと呼ばれる。軽量ゲートウェイ（lightweight gateway）は、限定された機能を提供し、イーサネット（登録商標）のレイヤ２において正確に動作することができる。フル機能を備えたゲートウェイは、レイヤ３及びこれより上位のレイヤにおいて動作することができ、したがって、ルータとして動作することができる。アーキテクチャにより提供されるゲートウェイ仕様は、イーサネット（登録商標）カプセル化のためのメカニズムと、アーキテクチャの残りの部分（rest）と整合するイーサネット（登録商標）データセンタネットワークに対する柔軟性のある接続を可能にするためにゲートウェイがファブリック上でどのように動作できるかと、を含む。インターネットワーキングプトロコルとしてＩＰを使用することにより、ＩＥＴＦ承認トランスポート、すなわち、ＴＣＰ、ＵＤＰ、及びＳＣＴＰを使用して、アーキテクチャのファブリックを超えるメッセージの送受信が可能になる。
【0017】
図１は、一実施形態に従った、アーキテクチャの様々なコンポーネント及びインターコネクトを含むシステム１００の高レベルビューを示している。アーキテクチャの中心機能は、ファブリック１０２であり、ファブリック１０２は、アーキテクチャのリンク及びスイッチを介して相互接続されるＨＦＩ及びゲートウェイの集合を含む。図１に示されるように、ファブリック１０２のコンポーネントは、それぞれのディスクリート型シングルノードプラットフォーム１０６により各々ホストされる複数のＨＦＩ１０４（１つが図示されている）と、仮想プラットフォーム１１０によりホストされるＨＦＩ１０８と、マルチノードプラットフォーム１１６のそれぞれのノード１１４１及び１１４ｎによりホストされるＨＦＩ１１２１及び１１２ｎと、集積型シングルノードプラットフォーム１２０のＨＦＩ１１８１及び１１８ｎと、高ラディックススイッチ（high radix switch）１２２と、スイッチ１２４及び１２６と、１以上のファブリックマネージャ１２８と、ゲートウェイ１３０と、リンク１３２、１３４、１３６１、１３６ｎ、１３８、１４０１、１４０ｎ、１４２、１４４、及び１４８、並びに、クラウド１５０として集合的に図示されているさらなるリンク及びスイッチと、を含む。
【0018】
上述したように、スイッチは、レイヤ２デバイスであり、ファブリックにおいてパケット転送メカニズムとして動作する。スイッチは、ファブリック管理ソフトウェアにより、集中プロビジョニング及び集中管理され、各スイッチは、管理トランザクションに応答するための管理エージェントを含む。集中プロビジョニングとは、適応的ルーティングのための代替ルート等、転送テーブルが、特定のファブリックトポロジ及び転送機能を実装するためにファブリック管理ソフトウェアによりプログラムされることを意味する。スイッチは、適応的ルーティング及び負荷バランシング等のＱｏＳ機能を実行する役割を担い、また、輻輳管理機能を実装している。
【0019】
図２は、ファブリックリンクを介してデータを転送するためのアーキテクチャのレイヤを示している。本レイヤは、物理（ＰＨＹ）レイヤ、リンク転送サブレイヤ、リンクファブリックサブレイヤ、及びトランスポートレイヤを含む。図２の左側には、ＯＳＩ参照モデルと本レイヤとの対応が示されており、本ＰＨＹレイヤは、レイヤ１（ＰＨＹレイヤ）に対応し、本リンク転送サブレイヤ及び本リンクファブリックサブレイヤは集合的に、レイヤ２（リンクレイヤ）に対応し、本トランスポートレイヤは、レイヤ４（トランスポートレイヤ）に対応する。
【0020】
アーキテクチャにおいて、信号が、物理レイヤにおいて一緒にグループ化され、制御可能なように振る舞いモノリシックエンティティ（monolithic entity）としてレポートされるポートに向けられる。ポートは、１以上の物理レーンを含み、各レーンは、物理的伝送媒体において実装される２つの差動ペア又はファイバからなり、２つの差動ペア又はファイバのそれぞれは、通信の各方向のためのものである。ポートを含むレーンの数は、実装に依存する。しかしながら、リンク転送サブレイヤのアーキテクチャは、有限のセットのポート幅をサポートする。特定のポート幅は、基本ポート幅としてサポートされ、ケーブル及びチップ設計の共通ターゲットを可能にする。ポート幅は、１ｘ、４ｘ、８ｘ、１２ｘ、及び１６ｘを含み、「ｘ」は、物理レーンの数を特定する。いくつかの状況下では、不良レーンの検出等、リンクは、低減されたレーン幅で動作し得る。リンク転送サブレイヤは、物理レイヤとリンクファブリックサブレイヤとの間のインタフェースとして機能する。（リンクファブリックサブレイヤにおける）リンクファブリックパケットは、６４ビットフロー制御デジット（フリット、ＦＬＩＴ、Ｆｌｉｔ等と呼ばれ、フロー制御デジットの適切なコントラクション（contraction）である）に分割される。図３は、バンドル３０２にグループ化された複数のフリット３００の一例を示している。各フリット３００は、８バイトのデータからなる６４データビットを含む。
【0021】
リンク転送サブレイヤは、複数のレーンを、リンクを介して、フリットと、フリットに関連付けられたクレジットリターン情報と、を高信頼性で転送することができる群（team）に形成する。これは、リンクファブリックサブレイヤに関連付けられるリンク転送パケット（ＬＴＰ：link transfer packet）と呼ばれる１０５６ビットバンドルを用いて実現される。図３はまた、１６個のフリットのデータを含むＬＴＰのデータ部分を示している。加えて、ＬＴＰは、フリットタイプ情報、ＣＲＣデータ、及びオプションデータ（図３には示されていない）を含む。ＬＴＰの例が、様々な図（例えば、図５〜図１１）に示されており、以下でさらに詳細に説明される。
【0022】
ファブリックパケットは、６４ビットフリットと、フリット毎のフリットタイプビットと、を含む。ファブリックパケットの最初のデータフリットは、ヘッドフリット（head flit）と呼ばれる。ファブリックパケットの最後のデータフリットは、テールフリット（tail flit）と呼ばれる。ファブリックパケット内の任意の他のデータフリットは、ボディフリット（body flit）と呼ばれる。ファブリックパケット４００の一例が、図４に示されている。
【0023】
ボディフリットと他のフリットタイプとを区別するために、フリットタイプビットが、各フリットに提供される。一実施形態において、ボディフリットは、フリットタイプビットが１に設定されて符号化され、６４ビットのデータを含む。全ての他のフリットは、フリットタイプビットが０に設定されてマークされる。ヘッドフリットは、フリット［６３］が１に設定されて符号化される。全ての他の（ボディフリットではない）フリットは、フリット［６３］が０に設定されて符号化される。テールフリットは、フリット［６２］が１に設定されて符号化される。全ての他の（ボディフリット／ヘッドフリットではない）フリットは、フリット［６２］が０に設定されて符号化される。フリットの符号化が、以下の表１にまとめられている。
【0024】
【表1】
【0025】
制御フリットが、表２にまとめられている。リンク転送レイヤのみにより使用される７つの制御フリット（ＬＴ制御フリット）は、ヌルＬＴＰにおいて送信される。残りの制御フリットは、２つのグループに分けられる。ファブリックパケット（ＦＰ）フリットは、ＨｅａｄＢａｄＰｋｔ制御フリット、ＢｏｄｙＢａｄＰｋｔ制御フリット、及びＴａｉｌＢａｄＰｋｔ制御フリットに加えて、通常パケットのヘッドフリット、ボディフリット、及びテールフリットを含む。リンクファブリック（ＬＦ）コマンドフリットは、Ｉｄｌｅフリット、ＶＬＭｒｋｒフリット、及びＣｒｄｔＲｅｔフリットを含む。ＦＰフリット及びＬＦコマンドフリットは、リンクを介する伝送のために、高信頼性ＬＴＰ（reliable LTP）内に一緒に混合される。
【0026】
【表2】
【0027】
アイドルコマンドフリットは、データストリームに挿入するファブリックパケットフリットが存在しない場合に、リンクファブリックレイヤにより使用される。データパスの全幅が、アイドルフリットを含む場合、リンク転送レイヤは、入力バッファに挿入されるフリットストリームからそれらアイドルフリットを除去する。データパスが、アイドルフリット及び非アイドルフリットの両方を含む場合、アイドルフリットは除去されない。これは、リンク転送レイヤが、リンクの反対側（far end）のリンクファブリックレイヤに同一のデータパス構成を提示するために実施される。リンク転送レイヤが、リンクファブリックレイヤからの仕掛かり中の（pending）フリットを有さない場合、リンク転送レイヤは、オリジナルフリットがリンクを介して送信されるように、アイドルフリットを挿入する。オリジナルフリットとは、リプレイバッファから送信される再送信フリット又はリプレイフリットを含むフリットではない、リンクを介して初めて送信されるフリットである。
【0028】
リンク転送パケットは、リンクを介して伝送される１６個のフリットを保持する。再送信リクエストの欠如が、ＬＴＰがリンクピアにより無事に受信されたことを示すことを確実にするのに十分長い時間期間の間、高信頼性ＬＴＰが、リプレイバッファに保持される。リプレイバッファ位置ポインタが、送信機における各ＬＴＰ（ＮｘｔＴｘＬＴＰ）及び受受信機における各ＬＴＰ（ＮｘｔＲｘＬＴＰ）に対して保持されるが、ＬＴＰの一部として交換されるものではない。伝送エラーが受信機により検出された場合、受信機は、ＮｘｔＲｘＬＴＰリプレイバッファ位置ポインタを含むＲｅｔｒｙＲｅｑＬＴＰを送信機に送信する。ＲｅｔｒｙＲｅｑＬＴＰを受信したことに応答して、リプレイバッファ内のＬＴＰが、ＲｅｔｒｙＲｅｑＬＴＰ（ピアＮｘｔＲｘＬＴＰ）リプレイバッファ位置で始まり、書き込まれた最後のリプレイバッファ位置（ＮｘｔＷｒＬＴＰ−１）で終わる元の順番で再送信される。ヌルＬＴＰは、リプレイバッファに保持されず、再送信されない。
【0029】
リンクファブリックコマンドフリットは、ＬＴＰ内で、ＦＰフリットと混合され得る。しかしながら、ＬＦコマンドフリットは、ファブリックパケットの一部ではない。ＬＦコマンドフリットは、リンクの一方の端におけるリンクファブリックサブレイヤから、リンクの他方の端におけるリンクファブリックサブレイヤに制御情報を伝える。
【0030】
一実施形態において、標準型検出ＬＴＰ（standard detection LTP）、１４ビットＣＲＣ ＬＴＰ、及び拡張型検出ＬＴＰ（enhanced detection LTP）を含む３つのＬＴＰフォーマットが存在する。標準型検出ＬＴＰの一実施形態が、図５に示されている。１６個のフリットに加えて、各標準型検出ＬＴＰは、ＬＴＰコンテンツをカバーする１６ビットＣＲＣを有する。例示の目的のために、図５におけるフリットは、ビット６４がフリットタイプビットである６５ビットとして示されている。
【0031】
１４ビットＣＲＣ ＬＴＰの一実施形態が、図６に示されている。１６個のフリットに加えて、各１４ビットＣＲＣ ＬＴＰは、ＬＴＰコンテンツをカバーする１４ビットＣＲＣ及び２ビットクレジットサイドバンドチャネルを有する。フロー制御クレジットが、特別なＬＦコマンドフリット又はＬＴＰクレジットサイドバンドチャネルのいずれかの中に含まれて、ＬＴＰにおいて送信される。
【0032】
標準型検出ＬＴＰに加えて、リンクはまた、１６個のフリット及び４つの１２ビットＣＲＣフィールドを有するオプションの拡張型検出ＬＴＰをサポートすることができる。図７は、拡張型検出ＬＴＰの一実施形態のフォーマットを示している。４つのＣＲＣフィールドの各々は、１６個のフリット全てをカバーする。４つのＣＲＣのうちいずれかが不良である場合、ＬＴＰが再送信される。４つの１２ビットＣＲＣについて、２つのＣＲＣ計算オプションが存在する。第１の計算オプション（４８ｂオーバーラッピング）は、４つのオーバーラッピング計算（overlapping calculation）を使用し、各計算は、ＬＴＰ内の全ビットをカバーする。第２の計算オプション（レーン毎の１２ｂ−１６ｂ ＣＲＣ）は、４つの非オーバーラッピング計算（non-overlapping calculation）を使用し、各計算は、４つのレーンのうちの１つのレーン上でフローする全ビットに限定される。
【0033】
上述したように、リンク転送レイヤにより使用されるＬＴ制御フリットは、ヌルＬＴＰにおいて送信される。ヌルＬＴＰは、リプレイバッファ内のスペースを消費せず、再送信されない。ヌルＬＴＰは、の表２にまとめられているＬＴ制御フリットのうちの１つを用いて識別される。ヌルＬＴＰタイプのほとんどは、シーケンシャルペアで送信され、ペアのうちの少なくとも１つがエラーなくリンクピアにより受信されること又はペアの両方がエラーを有する場合にＲｅｔｒａｉｎＲｅｔｒｙＲｅｑが自動的に生成されることのいずれかを確実にする。標準型検出ヌルＬＴＰの一例が、図８に示されている。
【0034】
標準型検出ヌルＬＴＰは、１つの識別制御フリット、９７５の予約ビット、及び標準型検出１６ビットＣＲＣフィールドを含む。拡張型検出ヌルＬＴＰは、１つの識別制御フリット、９７５の予約ビット、及び４つの拡張型検出１２ビットＣＲＣフィールドを含む。１４ビットＣＲＣが使用される場合、２サイドバンドビットは、ヌルＬＴＰにおいて無視される。
【0035】
４つのレーンを有するリンクに接続されている４ｘ可能ポート及び８ｘ可能ポートの両方について、ＬＴＰが、１度に１つずつ、リンクを介して送信される。このことが、図９ａ及び図９ｂのそれぞれにおいて、標準型検出ＬＴＰ及び拡張型検出ＬＴＰの両方の観点で、リンクファブリックデータパスを用いて示されている（ＣＲＣフィールドはスケーリングされていないことに留意されたい）一方、対応する信号処理及び転送パスの実施形態が、図１０に示されている。１４ビットＣＲＣ ＬＴＰは、ＬＣＲＣ［１５：０］フィールドが、ＬＣＲＣ［１３：０］フィールドとＣ［１：０］フィールドとの組合せにより置換されることを除いて、図８に示される標準型検出ＬＴＰに類似している。フリット送信順序は、フリット０で始まりフリット１５で終わる。
【0036】
一実施形態において、各レーンを介するデータの物理的伝送では、シリアル２レベルビット非ゼロ復帰（ＮＲＺ）符号化ビットパターンが使用され、各レーンに対応するこのデータは、復号され、デシリアライズされ、１サイクル当たり１レーン当たり４バイトにグループ化される。これは、１サイクル当たり２個のフリットを含む１６バイトの転送をもたらす。例えば、図９ａ及び図１０の例示は、２フリット幅の実装固有のデータパスを仮定しており、この仮定の下では、フリット０及びフリット１が同時に伝送され、フリット２及びフリット３が同時に伝送される、等である。ＬＣＲＣは、リンク転送サブレイヤにより計算される。
【0037】
図１１は、８つのレーンを介してデータが伝送される８ｘデータパスをサポートするために２つの４レーンリンクがグループ化されるＬＴＰ送信スキームを示している。図示されるように、このスキームの下では、２つのＬＴＰからの４つのフリットが、リンクファブリックサブレイヤとリンク転送サブレイヤとの間のインタフェースにおいて、並列に処理される。
【0038】
上述したように、アーキテクチャは、データ転送をサポートするために、３つのレベルのデータユニット粒度、すなわち、ファブリックパケット、フリット、及びリンク転送パケットを使用する。リンク転送レイヤにおける送信のユニットはＬＴＰである。図示されるように、各ＬＴＰは、名目上１６フリット長であるが、上述したように、ＬＴＰの実際のサイズは、使用される特定のＣＲＣスキームに応じて変わり得るものであり、１６フリット長を有するとしてＬＴＰを参照することは、ＣＲＣビット及び１６個のビット６５を除くＬＴＰに含まれる６４ビットフリットのデータの数に対応する。
【0039】
４つの物理レーンを有するリンクの一実施形態の（「ＰＨＹ」とも呼ばれる）物理レイヤの構造が、図１２に示されている。ＰＨＹは、リンクインターコネクトの物理構造を規定し、コンポーネントＡ及びコンポーネントＢにより示されるような２つのリンクピアの間の特定のリンク上における信号のオペレーションの詳細を扱う役割を担う。このレイヤは、パラレルレーンを介する情報の各ビットを送受信する際に伴う電気レベル、タイミング面、及び論理問題を含む、信号線上のデータ転送を管理する。図１２に示されるように、各インターコネクトリンクの物理的接続は、各方向のレーン０〜３を含む、信号の４つの差動ペア１２００から構成される。各ポートは、２つのピアコンポーネント間の接続を完了するための２つの一方向リンクからなるリンクペアをサポートする。これは、双方向の同時のトラフィックをサポートする。例示及び理解のしやすさのために、図１０に示されるリンクの「スイズル（swizzle）」は、図１２には示されていない。しかしながら、いくつかの実施形態においては、送信レーン及び受信レーンは、スイズルされることを理解されたい。
【0040】
リンクポートを有するコンポーネントは、図１２に示されるように、一方向ポイントツーポイントリンクのペアを用いて通信し、リンクピアとして定められる。各ポートは、送信（Ｔｘ）リンクインタフェース及び受信（Ｒｘ）リンクインタフェースを含む。図示される例において、コンポーネントＡは、コンポーネントＢのＲｘポート１２０４に接続されるＴｘポート１２０２を有する。一方、コンポーネントＢは、コンポーネントＡのＲｘポート１２０８に接続されるＴｘポート１２０６を有する。一方の一方向リンクは、コンポーネントＡからコンポーネントＢに伝送するものである、他方のリンクは、コンポーネントＢからコンポーネントＡに伝送するものである。「送信」リンク及び「受信」リンクは、どのコンポーネントポートがデータを送信し、どのコンポーネントポートがデータを受信するかに関して定められる。図１２に示される構成において、コンポーネントＡの送信リンクは、コンポーネントＡのＴｘポート１２０２からコンポーネントＢのＲｘポート１２０４にデータを送信する。これと同じコンポーネントＡの送信リンクが、コンポーネントＢの受信リンクである。前述したように、リンクポート間におけるデータの転送のための基本ユニットがＬＴＰである。
【0041】
各ＬＴＰは、送信ポートと、特定のリンクの反対側の受信ポートと、により定められる特定のリンクを介する一方向の送信に固有である。ＬＴＰは、単一のリンク転送のライフタイム（lifetime）を有し、ＬＴＰは、適用可能なＶＬバッファからフリットをプルし、フリットを１度に１６個組み立ててそれぞれのＬＴＰにすることにより、動的に生成される。ＬＴＰ送信ストリーム１２１０及び１２１２により示されるように、ＬＴＰは、図４を参照して上述したように、ヘッドフリットビット及びテールフリットビットにより表される、個々のＬＴＰの最初のフリット及び最後のフリットを含むフリットのストリームとして送信される。
【0042】
上述したように、アーキテクチャは、０バイトから１０２４０バイトのサイズのレイヤ４ペイロードを有する、宛先にルーティングされるファブリックパケット（すなわちＦＰ）を主として含むパケット配信メカニズムを規定する。これは、単純なＵＬＰアクノレッジメントから、カプセル化されたイーサネット（登録商標）ジャンボフレームに至る範囲のメッセージの送信に対する効果的なサポートを提供する。ファブリックパケットは、ＨＦＩとの間の入出力のためのペイロードの論理ユニットを表す。ファブリックパケットは、ファブリック内でエンドツーエンドであるライフタイムを有するので、そのように命名されている。より詳細には、ファブリックパケットのライフタイムは、ＦＰの送信元アドレス及び宛先アドレスにより定められるファブリックエンドポイントの間でＦＰコンテンツを転送するのに要する時間である。ＦＰの各転送パスは、少なくとも１つのリンクを介する転送を含み、転送パスが１以上のスイッチをまたがる場合には、複数のリンクを介する転送を含むこともある。
【0043】
ＦＰとＬＴＰとを組み合わせたフリットの使用は、アーキテクチャに固有であるデータ転送機能を円滑にする。詳細には、ＦＰ、フリット、及びＬＴＰの分離は、仮想レーンの使用に加えて、様々な態様のＱｏＳ及びファブリックのロバスト性をサポートする。
【0044】
上述したように、フリットは、単一では伝送されず、代わりに、１６個のフリットのグループが、リンク転送パケットにパックされる（まとめられる（バンドルされる、束にされる））。これは、フリットが、共通リンクＣＲＣを共有することを可能にする。ＬＴＰ内のフリットは、多くの異なるファブリックパケットから生じることがあり、これは、他のファブリックと比較すると、リンクプロトコルにいくつかの興味深い特徴を与える。効果的なパケットプリエンプション及びインターリービングメカニズムを使用することにより、アーキテクチャは、異なるストリームに対するデータ転送のインターリービング、行頭ブロッキングの影響の実質的な除去、さらには、大きな単一パケットが物理リンク上で物理的に転送されるブロッキングの影響の実質的な除去をサポートする。ファブリックパケットとフリットとＬＴＰとの間の関係についての例示が、図１５及び図１６に示されており、これらの図についてのさらなる説明が、以下に記載される。
【0045】
アーキテクチャは、クレジットベースフロー制御を使用して、リンクの受信機側のバッファリソースを管理し、送信機がフリットを送信し得る時間を制御する。このアプローチの下では、ファブリックポートがフリットを送信するために、受信ポートにおいて必要とされるバッファスペースのために利用可能な十分なフロー制御クレジットを必要とする。一実施形態において、受信機は、リンク上でサポートされる仮想レーン（ＶＬ）のために受信バッファ群の単一のプールを提供する。バッファプールの割り当ては、リンクの送信機側のロジックにより管理される。サポートされる各ＶＬに対して、専用バッファが割り当てられる。加えて、送信機は、このスペースの一部を、ＶＬ間で動的に割り当てられる共用プールとして管理することができる。クレジットベースフロー制御とは、リンク上のデータ転送が、厳格に管理されることを意味する。未許可のデータ転送は存在せず、これはまた、ファブリックが、いわゆる「無損失」ファブリックであることを意味する。この場合、無損失とは、単に、通常のオペレーション中、フリット、したがって、パケットが、輻輳に起因して決してドロップされないことを意味する。
【0046】
フロー制御クレジット等の制御情報は、リンクファブリック（ＬＦ）コマンドフリット及びリンク転送（ＬＴ）制御フリットにおいて伝送される。ＬＦコマンドフリット及びＬＴ制御フリットは、任意の時点で、送信機のフリットストリームに挿入されてよい。加えて、いくつかのＬＴＰフォーマットにおけるサイドバンド情報を使用して、ほんの少しのオーバーヘッドを伴うだけでクレジットを転送することができる。ＬＦコマンドフリット及びＬＴ制御フリットは、リンク送信機により生成され、リンク受信機により使用される。
【0047】
アーキテクチャは、データインテグリティを確実にするために、リンク転送パケット及びファブリックパケットのＣＲＣを含む。アーキテクチャはまた、正しく受信されなかったＬＴＰのために、リンクレベルリトライを提供する。ＬＴＰリトライは、リンクの実効ビットエラー率を著しく改善させ、物理的ＢＥＲのわずかな劣化と引き換えに、より低い電力消費を提供することができるＰＨＹ方策の使用を可能にする。許容可能なシステムレベルエラー率を維持するために、ファブリック内の多数のリンクがはるかに良いリンク当たりＢＥＲ特性を必要とする大型ファブリックにとっても、ＬＴＰリトライは有用である。
【0048】
インターリービング、並びに、プリエンプション及びインターリービング
Ｌ２リンクレイヤは、異なるパケットからのフリットが、それらパケットが異なるＶＬにおいて存在する限りは、リンクを介して送信されるときにインターリーブされることを可能にする。インターリービングの１つの動機づけは、所与のリンクの使用を最大化することである。どのような理由であれ、送信パケットが、バブル（bubble）により遮断される場合、第２のパケットが、その後、アイドル状態にされることなく、チャネルにインターリーブされ得る。プリエンプションと呼ばれるインターリービングの第２の理由は、より高優先度のパケットを、転送されているより低優先度のパケットに割り込ませて、より高優先度のパケットの遅延を低減させることである。インターリービング下では、ファブリックパケットのフリットの全て又は一部が、リンクを介して伝送されるフリットのストリームにおいて、他のＦＰからのフリットによりインターリーブされる。送信機は、ポートの出力キューにおいて送信するのに利用可能なＦＰの中から、送信のためのフリットを選択する。一実施形態において、単一のＶＬにおけるＦＰは、順番に配信されるので、仮想レーンにおいて、１つのパケットからのフリットの全てが、（そのＶＬにおける）後続のパケットからの任意のパケットが送信される前に、送信される。異なるＶＬにわたっては、指定された順番は存在しないので、異なるＶＬにおけるパケットからのフリットが、フリットストリーム内で（加えて、フリットの順番が各ＶＬにおいて維持される限りは、所与のＬＴＰ内で）任意にインターリーブされ得る。いくつかの送信機実装は、パケット間のインターリービングの量を制限するよう選択することができる。
【0049】
プリエンプション下では、より高優先度のレベルを有するファブリックパケットからのフリットが、より低優先度のレベルを有するＦＰからのフリットをプリエンプトする（preempt）。一実施形態において、各仮想レーンは、それぞれの優先度レベルに関連付けられる。送信機は、より低優先度のＶＬからのフリットの前に、より高優先度のＶＬからのフリットをリンクＬＴＰに挿入するよう構成される。送信機は、単一のフリットよりも大きな、境界部分におけるより高優先度のフリットを挿入するよう選択することができる。さらに、送信機は、同じ優先度のＶＬからのフリットをインターリーブすることもできるし、同じ優先度の異なるＶＬにおける異なるパケットからのフリットを送信する前に、１つのパケットからのフリットの全てをリンクに送出する（inject）こともできる。リンク上の受信機は、キューに挿入するため、及び、（スイッチ内の受信機のために）次のホップに転送するために、到来するフリットストリームをＶＬ別に分離する。一般に、少なくとも所与のリンクに関して、受信機実装は、送信機により発生され得るインターリービングのフルスコープ（full scope）をサポートする。いくつかの実施形態において、インターリービングの同様のスコープが、ファブリックにわたって実装される。任意的に、異なるリンクが、異なるレベルのインターリービングをサポートしてもよい。
【0050】
パケットプリエンプションの諸態様に従うと、第１の優先度レベル（例えば、高優先度）を有するＶＬにおけるパケットＢからのフリットは、より低優先度のＶＬ（すなわち、第１の優先度レベルよりも低い優先度レベルを有するＶＬ）におけるパケットＡからのフリットのストリームをプリエンプトすることができる。この場合、パケットＢからのヘッドフリットは、パケットＡのヘッドフリット及びパケットＡからの０以上のボディフリットの後に続くことができる。このヘッドフリットは、新たなパケットが開始しており、受信機がＶＬ識別子を判別するためにＬ２ヘッダ内のＳＣフィールドを探すことになることを示す。０以上のボディフリットが、パケットＢのヘッドフリットの後に続き、最後にパケットＢを終了させるテールフリットが続く。パケットＢの完了後、パケットＡの送信が、０以上のフリットにより再開され、その後にテールフリットが続く。
【0051】
パケットは、連続的なより高優先度のパケット（連続的な高優先度のＶＬにおけるパケット）によりプリエンプトされるので、パケットプリエンプションはネスト化され得る。一実施形態において、これは、リストの先頭にアクティブパケットを有するリンク型リスト（linked list）としてモデル化される。現在のパケットがプリエンプトされるときに、新たなパケットがリストの先頭に追加される。プリエンプトしたパケットが終了するときに、そのパケットがリストから除去され、再開すべき次の予想パケットが、リストの新たな先頭になる。リストに１度に保持できるパケットの最大数は、サポートされるＶＬの数に等しい。
【0052】
先の説明では、プリエンプションを説明するために優先度レベルが使用されたが、より高優先度のパケットに対してのみプリエンプションが使用される必要はない。送信のために利用可能な現在のパケットからのフリットが存在しない（これは「バブル」をもたらす）が、より低優先度のパケットから利用可能なヘッドフリットが存在する場合があり得る。より低優先度のパケットからのヘッドフリット及びそれに続くボディフリットが送信され得る。新たなヘッドフリットは、そのパケットをリストの先頭に追加させることになり、受信機は、新たなパケットを正確に追跡するようになる。
【0053】
第１のパケットのテールフリットの前に第２のパケットのヘッドフリットが送信される場合、第１のパケットは、第２のパケットによりインターリーブされるとみなされる。インターリービングの最も単純な場合において、第２のパケットに属する割り込んだヘッドフリットの後に第２のパケットのテールフリットまで全てのボディフリットが続き、その後、第１のパケットの残りのパケットフリットが再開する。この単純な場合が、図１３に図式的に示されている。
【0054】
フリットのグループは、フリットストリーム内のフリットの順番（最上部から最下部）に対応する。グループ内の最初のフリットは、ＶＬ０とラベル付けされている仮想レーン０を介して転送されているファブリックパケットのヘッドフリットである。ＶＬ０ヘッドフリットは、このＦＰが４フリット長（１つのヘッドフリット、２つのボディフリット、及び１つのテールフリット）であることを識別する。２番目のフリットは、ＦＰ ＶＬ０の最初のボディフリットである。次のフリットは、ＶＬ１ヘッドフリットとラベル付けされており、これは、ＶＬ１とラベル付けされている仮想レーン１を介して送信されるＦＰのヘッドフリットである。ＶＬ１ヘッドフリットもまた、このＦＰが４フリット長であることを識別する。一アプローチ下では、新たなＶＬからのＦＰのフリットが、現在のＶＬからのフリットをインターリーブすべきときに、新たなＶＬが、リンクを介してフリットを送信するためのアクティブ仮想レーンになる。これが、ＶＬ１のヘッドフリットをフリットストリームに追加することにより示される。結果として、ＦＰ ＶＬ１は、ＦＰ ＶＬ０をインターリーブし、これが、１つのＶＬ１ヘッドフリット、２つのＶＬ１ボディフリット、及び１つのＶＬ１テールフリットを最初に追加することにより示される。ＶＬ１テールフリットは、ＦＰ ＶＬ１のフリットの最後を識別し、また、ＦＰ ＶＬ１のインターリービングを完了させる。次いで、ロジックは、ＶＬ１インターリーブの前のＦＰフリットに戻り、残りのＦＰ ＶＬ０ボディフリット及びテールフリットがリンクを介して送出されることをもたらす。
【0055】
リンクファブリックサブレイヤが、複数のファブリックパケットからのフリットのインターリービングをどのようにサポートするかをさらに示すために、図１４が、プッシュ及びポップインターリービング（push and pop interleaving）の一例を示している。リンクファブリックサブレイヤにおけるインターリービングは、プッシュ及びポップスキームを利用し、このスキームでは、割り込んだヘッドフリットは、割り込まれているＶＬのプッシュと、テールフリットに遭遇したときのスタックへのＶＬのポップと、を生じさせる。スタックがどのように動作するかを可視化するために、現在の書類に取り組むために使用されるデスク領域とともに、書類箱内の書類の層を想像されたい。プッシュ及びポップインターリービングのコンテキストにおいて、書類の層は、「スタック」と呼ばれ、デスク領域は、どのフリットからのアクティブ仮想レーンを識別するデータが記憶されているアクティブＶＬレジスタに対応する。送信中のＶＬが、インターリーブに応じて切り替えられるときに、インターリーブしたＶＬは、新たなアクティブＶＬになる一方で、前のアクティブＶＬは、デスクから層の最上部に押し出される（プッシュされる）（pushed）、したがって、「プッシュ」という用語が使用される。ＦＰのＶＬフリットが完了すると（例えば、ＶＬ ＦＰのテールフリットがＬＴＰ送信ＦＩＦＯに追加されたとき）、そのＶＬが、デスク領域から除去されて、層の最上部のＶＬが、層からデスク領域に「置かれ（ポップされ）（popped）」、したがって、新たなアクティブＶＬになる。ＶＬのこのプッシュ及びポップは、ネスト化されて続き得る。ｎ個のＶＬをサポートするリンクファブリックサブレイヤでは、同時に割り込まれ得るパケットの最大数は、（ｎ−１）個である。
【0056】
図１４の例において、フリットの順番リスト１４００は、様々なＶＬに記憶されているファブリックパケットからのフリットが、フリットの送信ストリームに追加される順番を表している（あるいは、任意的に、受信ポートにおいて受信されるフリットストリーム内のフリットの順番を示している）。以下の説明は、フリットが、ＬＴＰ（すなわち、ファブリックに「送出される」ＬＴＰ）にまとめられるアウトバウンドストリームに追加される、フリットストリームの生成に関する。アクティブＶＬを識別するしるし（indicia）が、アクティブＶＬレジスタ１４０２内において様々な状態で示される。初期状態下では、ＶＬ０に対応するしるしが、アクティブＶＬレジスタ１４０２に記憶されており、これは、仮想レーンＶＬ０のためにバッファされている次のファブリックパケット（ＶＬ０ ＦＰと呼ぶ）からフリットが追加されることを示す。したがって、ＶＬ０ ＦＰの最初の２つのフリットが、フリット送信ストリームに追加され、その時点において、ＶＬ１がＶＬ０をインターリーブすることを開始するインターリービングイベントが検出される。このインターリービングオペレーションを実現するために、アクティブＶＬレジスタ内で、ＶＬ１のためのしるしが、ＶＬ０に取って代わり、ＶＬ０をスタックにプッシュする。これは、アクティブ仮想レーンをＶＬ１に切り替え、ＶＬ１ ＦＰのヘッドフリット及び最初のボディフリットをフリット送信ストリームに追加させる。次いで、第２のインターリービングイベントに応答して、ＶＬ２がＶＬ１をインターリーブすることが開始され、ＶＬ２がアクティブＬＶレジスタ１４０２にロードされ、ＶＬ１がスタックにプッシュされる。これは、ＦＰ ＶＬ２の全ての３つのフリットをフリット送信ストリームに追加することをもたらす。ＦＰ ＶＬ２テールフリットを追加して、ＶＬ２がＶＬ１をインターリーブすることを完了すると、ＶＬ１が、スタックからアクティブＶＬレジスタ１４０２にポップされる。ＶＬ１の別のボディフリットが追加された後、ＶＬ７がＶＬ１をインターリーブすることを開始するが、これは、ＶＬ７のためのしるしをアクティブＶＬレジスタ１４０２に追加し、ＶＬ１をスタックに再度プッシュすることにより実行される。ＶＬ７ ＦＰ全体に対応する３つのフリットがフリット送信ストリームに追加され、ＶＬ２がＶＬ１をインターリーブすることが完了し、ＶＬ１がスタックからアクティブＶＬレジスタ１４０２に再度ポップされる。ＶＬ１ ＦＰのテールフリットが追加され、ＶＬ１のインターリービングが完了し、ＶＬ０がスタックからアクティブＶＬレジスタ１４０２にポップされる。これは、ＶＬ０をアクティブＶＬに戻し、ＶＬ０ ＦＰの最後の２つのパケットが、ＬＴＰ送信ＦＩＦＯに追加される。
【0057】
割り込まれている暗示的ＶＬに戻るためのポップに依拠する代わりに、リンクファブリックサブレイヤは、デバイスが、「ＶＬマーカ」と呼ばれる特別なＬＦコマンドフリットを使用して、どのＶＬをリストの先頭に移動させるかを明示的に指定することを可能にする。ＶＬマーカの使用は、この追加のマーカフリットに起因して、少々効率的ではないが、インターリービングにさらなる柔軟性を提供する。図１５における図が、このコンセプトを示している。
【0058】
実際、ＶＬマーカは、ＶＬが、デフォルトのスタック順番からプルされることを可能にする、あるいは、スタックに存在しない新たなＶＬがスタックの先頭に移動されることを可能にする。スタックに保たれるＶＬは、その後、プッシュ及びポップルールに従い続ける。これら２つの異なるメカニズムの使用は、混合させることができ、排他的ではない。特定のＶＬがスタックからプルされ、その後別のＶＬによりインターリーブされる場合、その特定のスタックは、スタックに再度プッシュされる。
【0059】
図１５に戻ると、一連のオペレーションは、図１４のプッシュ及びポップの例と同様に始まる。ここで、初期アクティブ仮想レーンはＶＬ０であり、ＶＬ０ ＦＰの最初の２つのフリットがフリット送信ストリーム１５００に追加される。と同様、次いで、ＶＬ１が、２つのフリットのＶＬ０をインターリーブし、次いで、ＶＬ２が、ＶＬ１をインターリーブする。しかしながら、ＶＬ２ ＦＰテールフリットに達する前に、ＶＬマーカ１５０２が、フリット送信ストリームに挿入され、これは、ＶＬ０が新たなアクティブＶＬになるべきであることを示す。これは、ＶＬ０が、スタックからプルされ、アクティブＶＬレジスタ１４０２にロードされることをもたらし、ＶＬ２をスタックの先頭にプッシュする。ＶＬ０の残りの２つのフリットがフリット送信ストリーム１５００に追加され、ＶＬ０が完了すると、ＶＬ２が、スタックからアクティブＶＬレジスタ１４０２にポップされる。これは、ＶＬ２のテールフリットを追加させ、ＶＬ２が完了すると、ＶＬ１がスタックからアクティブＶＬレジスタ１４０２にポップされる。別のＶＬ１ボディフリットが追加された後、ＶＬ７がＶＬ１をインターリーブすることが開始され、これは、ＶＬ７をアクティブＶＬレジスタ１４０２にロードし、ＶＬ１をアクティブＶＬレジスタ１４０２からスタックにプッシュする。次いで、アクティブ仮想レーンをＶＬ１に再度切り替えるために、第２のＶＬマーカ１５０４がフリット送信ストリーム１５００に追加される。これは、ＶＬ７をスタックにプッシュし、ＶＬ１をアクティブＶＬレジスタ１４０２にプルする。ＶＬ１ ＦＰテールフリットが追加され、ＶＬ１のインターリービングが完了すると、ＶＬ７が、スタックからアクティブＶＬレジスタ１４０２にポップされる。次いで、ＶＬ７ ＦＰの最後の２つのフリットが追加される。
【0060】
図１４及び図１５に示されるインターリービングの例は、プッシュ及びポップインターリービングスキームとＶＬマーカインターリービングスキームとのより容易な理解のために、例示の目的で、誇張したレベルのインターリービングを示している。実際のシステムでは、ほとんどのインターリービングは、（Ａ）プリエンプション及び（Ｂ）パケットストリームにおけるバブル、という２つのタイプのインターリービングイベントのうちの１つから生じる。プリエンプティブインターリービングのさらに詳細な例、及び、プリエンプティブインターリービングと、バブルイベントから生じるインターリービングと、の組合せのさらに詳細な例が、図１６及び図１７にそれぞれ示されている。
【0061】
上述したように、プリエンプション下では、より高優先度の仮想レーンにおけるファブリックパケットのコンテンツ（フリット）は、より低優先度のＶＬにおけるＦＰのフリットのフリット送信ストリームへの追加をプリエンプトすることができる。ＨＦＩ、ゲートウェイ、又は他のタイプのファブリックエンドポイントにおいて、ファブリックパケットが組み立てられる元となるデータは、一般に、ファブリックパケットにカプセル化されるイーサネット（登録商標）フレーム等の何らかの他のタイプのフォーマットで最初にバッファされる。また、ファブリックパケットは、ＩＰパケット及びＵＤＰパケット等のレイヤ３パケットがどのように生成されるかと同様、ネットワーキングスタックの一部として作成され得る可能性が高い。スイッチにおいて、受信コンテンツ及び送信コンテンツの両方は、どのフリットがどのＦＰに関連付けられているかと、どのスイッチポートを介してフリットが次のホップ又はエンドポイント宛先に送出されるべきかと、を判定するために使用されるさらなるメタデータを含んで、フリットにすでにフォーマット化されている。前述の観点から、図１６及び図１７は、ＦＰ下のＦＰコンテンツのフリットフォーマット化とともに、全体としてのファブリックパケットを示している。
【0062】
各ＦＰのフリットコンテンツは、ＦＰが割り当てられる仮想レーン用に割り当てられたバッファに一時的に記憶される。様々なバッファ構成の実施形態下では、別々のバッファが、それぞれのＶＬに割り当てられることもあるし、いくつかのＶＬが、バッファスペースを共用することもあるし、ＶＬバッファ割り当ての第１の部分がＶＬに専用である一方、別の部分が共用バッファスペースであるの両者の組合せであることもある。
【0063】
仮想レーンを使用する基本的な態様は、所与の仮想レーンにおけるコンテンツが、順番に保たれることである。これは、所与の仮想レーンに関して、１つのＦＰは、別のＦＰを通り越すことができないことを意味する。さらに、ＦＰのフリットはまた、フリットが元々生成された順番に保たれる。これと同時に、異なる仮想レーンにおけるコンテンツは、他の仮想レーンに対して順番に保たれる必要はない。これは、より高優先度のトラフィックが、より低優先度のトラフィックをプリエンプトすることを可能にする。仮想レーンはまた、ルーティングデッドロック及びプロトコルデッドロックを除去するためにも、及び、トラフィッククラス間の行頭ブロッキングを回避するためにも使用される。
【0064】
図１６に示されるように、それぞれの仮想レーンＶＬ１、ＶＬ２、及びＶＬ３用の３つのバッファ１６０２、１６０４、及び１６０６が存在する。これら仮想レーンの各々にはまた、それぞれの優先度レベルが割り当てられる、すなわち、ＶＬ１に対しては低優先度が割り当てられ、ＶＬ２に対しては中間優先度が割り当てられ、ＶＬ３に対しては高優先度が割り当てられる。アービタ（調停器、図示せず）を使用して、フリットがＬＴＰ２、３、４、５、６、及び７にまとめられるフリット送信ストリーム１６０８に追加すべきフリットをどのＶＬバッファからプルするかを決定する。図１６は、図示されるウィンドウ時間フレームにわたるＶＬ１、ＶＬ２、及びＶＬ３のＶＬのリンクトラフィックの処理を示す「スライディングウィンドウ」図である。一実施形態において、ＶＬバッファは、ＦＩＦＯ（先入れ先出し）バッファとして実装され、各ＦＩＦＯスロットは、１フリットを記憶するサイズである。
【0065】
上述したように、プリエンプティブインターリービングの一態様下では、より高優先度のＶＬに割り当てられたＦＰコンテンツは、相対的により低優先度のＶＬに割り当てられたＦＰコンテンツをプリエンプトすることができる。一般に、複数のＦＰに対応するＦＰコンテンツが、（ファブリックに送出される）それぞれのＶＬ退出バッファにバッファされている場合、最高優先度を有するＶＬに割り当てられたＦＰコンテンツが、フリット送信ストリームに追加されることになる。しかしながら、これは絶対的ルールではないことに留意されたい。なぜならば、プリエンプションが生じない状況もあり得るからである。これと同時に、ＦＰコンテンツが、１つの所与のＶＬ又は同じ優先度を有する複数のＶＬに対してのみ利用可能である場合、そのＦＰコンテンツが、（バッファされているいかなるＦＰコンテンツも現在は有していない）他のＶＬの優先度レベルに関係なく、フリット送信ストリームに追加されることになる。この状況が、以下のように、図１６に示されている。
【0066】
時間Ｔ１において、パケット１の少なくとも第１の部分が、ＶＬ１バッファ１６０２にバッファされ、送信のために準備される。アーキテクチャ下でのデータ転送のストリーミングの性質に起因して、フリットは、ＶＬバッファにおいて受信され得る（ＶＬバッファに追加され得る）とともに、（送信のために）ＶＬバッファから除去され得る。さらに、フリットをＶＬバッファに追加すること及びフリットをＶＬバッファから除去することは、特にスイッチにおいて、いくらか非同期的であり得る。結果として、任意の所与の時点において、所与のＶＬバッファは、バッファされて送信される準備ができているコンテンツを有していることもあるし、有していないこともある。図１６の例において、時間Ｔ１において、ＶＬ１バッファ１６０２だけが、送信される準備ができているフリットを含む一方、ＶＬ２バッファ１６０４及びＶＬ３バッファ１６０６の両方は空である。ＦＰパケットのフリットをフリット送信ストリームに追加するのを開始するために、少なくとも１以上のヘッドフリット（特定のＦＰフォーマットに依存する）は、ＶＬ ＦＩＦＯバッファの先頭にある必要がある。（以下でさらに詳細に説明するように、一実施形態において、ＶＬバッファは、循環ＦＩＦＯとして実装され、このＦＩＦＯの先頭は、ＦＩＦＯヘッドポインタにより特定される。）図１６において、ヘッドフリット１６１０が、時間Ｔ１において、ＶＬ１バッファ１６０２の先頭にバッファされる。
【0067】
時間Ｔ１において、第１のグループのフリット１６１２が、フリット送信ストリーム１６０８のＬＴＰ２に追加され、フリット１６１２の最初の部分であるヘッドフリット１６１０が、時間Ｔ２において追加される。Ｔ１とＴ２との間の時間差は、アクティブＶＬがＶＬ１バッファ１６０２に変更されることをアービタが認識するのに要する時間量と、フリットデータをバッファからフリット送信ストリームにコピーする時間量と、を表す。図１６におけるＴ１とＴ２との間の時間差は、スケーリングされておらず、代わりに、ＦＰデータがＶＬバッファに到達して送信のための準備がされた時間と、そのデータがフリット送信ストリームに実際に追加される時間と、の間のいくらかの有限の時間が存在することを示すために使用されている。
【0068】
時間Ｔ３において、ヘッドフリット１６１５で始まるパケット２の第１の部分が、ＶＬ２バッファ１６０４において受信される。ＶＬ２は、ＶＬ１よりも高い優先度を有するので、プリエンプションイベントが、アービタ（又は他のロジック、図示せず）により検出される。実装に応じて、プリエンプションイベントは、パケット２の１以上のヘッドフリットがＶＬ２ ＦＩＦＯバッファ１６０４の先頭に達した直後に検出されることもあるし、追加のインターリービングが、他のポートにバブルを生じさせることをもたらし、さらに多くのインターリービングをもたらすことがあるので、何らかのレベルのインターリービングの発生を減らすために、いくらかの遅延が存在することもある。例えば、フリット送信ストリームに追加されるフリットを有する現在のパケットが、ほんの少しのフリットしか残しておらず、プリエンプトするであろうパケットが大きい場合、ロジックは、現在のパケットのプリエンプションが生じないように、現在のパケットが完了するのを待つことができる。プリエンプションイベントに応答して、プッシュ及びポップインターリービングスキームを用いて、アクティブＶＬが、ＶＬ１からＶＬ２に切り替わる。任意的に、ＶＬマーカインターリービングが使用されてもよい。アクティブＶＬがＶＬ１からＶＬ２に切り替わったことに応じて、ＶＬ２のためのしるしが、アクティブＶＬレジスタにロードされ、ＶＬ１が、スタックにプッシュされる。時間Ｔ４において示されるように、第１のグループのフリット１６１６が、ＶＬ２ ＦＩＦＯバッファ１６０４からプルされ、フリット送信ストリーム１６０８に追加される。これは、パケット１の送信のプリエンプションによるパケット２の選択をもたらすとともに、パケット１及びパケット２からのフリットのインターリービングをもたらす。
【0069】
時間Ｔ５において、ヘッドフリット１６１８で始まるパケット３の第１の部分が、ＶＬ３バッファ１６０６において受信される。ＶＬ３は、ＶＬ２よりも高い優先度を有するので、第２のプリエンプションイベントが、アービタ（又は他のロジック、図示せず）により検出される。これは、パケット２の送信がパケット３の送信によりプリエンプトされることをもたらし、これは、ＶＬ３のためのしるしをアクティブＶＬレジスタにロードして、ＶＬ２をスタックにプッシュすることにより実行される。図示されるように、時間Ｔ６において、パケット３のフリット１６２０の全てが、フリット送信ストリーム１６０８に追加されることが開始され、したがって、パケット２のフリットが、パケット３のフリットによりインターリーブされる。
【0070】
テールフリット１６２２をフリット送信ストリーム１６０８に追加することに関連して、アービタ（又は他のロジック）は、パケット３からのフリットの追加が完了したことを検出する。したがって、ＶＬ３が、アクティブＶＬレジスタから除去され、ＶＬ２が、スタックからアクティブＶＬレジスタにポップされ、ＶＬ２がアクティブＶＬに戻される。これは、パケット２の残りのフリット１６２４が、フリット送信ストリーム１６０８に追加されることをもたらす。この追加は、時間Ｔ７において始まり、時間Ｔ８において終わる。時間Ｔ８において、テールフリット１６２６が追加され、したがって、パケット２が完了したことが検出される。これは、ＶＬ１が、スタックからアクティブＶＬレジスタにポップされ、ＶＬ１が、アクティブＶＬとしてＶＬ２に取って代わることをもたらす。次いで、パケット１の残りのフリット１６２８が、フリット送信ストリーム１６０８に追加され、時間Ｔ９において、テールフリット１６３０で完了する。次いで、次のファブリックパケットのヘッドフリットが、ＬＴＰ７の最後のフリットとして追加される（次のファブリックパケットは、簡潔さのために図示されていない）。
【0071】
図１７は、バブルインターリービングイベントと、その後に続くプリエンプションインターリービングイベントと、を示している。ファブリックパケットのフリットが、複数のホップを含むルーティングパスを経由する場合、そのフリットの一部は、１以上のスイッチにおいてプリエンプトされることがある。これは、所与のＦＰのフリットストリームの分断をもたらす。そのような分断されたフリットストリームが、受信ポートにおいて受信されたとき、プリエンプションの前にフリットの一部が送信された時間と、プリエンプションの後にフリットの一部が送信された時間と、の間にはギャップが存在する。これが「バブル」をもたらす。このバブルの例に加えて、バブルはまた、様々な他の理由で生じ得る。このようなバブルの検出に応じて、バブルを伴うＦＰと同じ優先度レベルを有するＦＰ又はバブルを伴うＦＰよりも低い優先度レベルを有するＦＰからのフリットとのインターリービングが実施され得る。
【0072】
図１６の例と同様、時間Ｔ１において、ヘッドフリット１７００を含むパケット１の少なくとも第１の部分が、ＶＬ１ ＦＩＦＯバッファ１６０２において受信され、時間Ｔ２において、フリット１７０２の第１の部分が、フリット送信ストリーム１７０４のＬＴＰ２に追加されることが開始される。時間Ｔ３において、ヘッドフリット１７０６で始まるパケット２の第１の部分が、ＶＬ２ ＦＩＦＯバッファ１６０４において受信される。ＶＬ１及びＶＬ２の両方には、低優先度が割り当てられており、したがって、パケット１及びパケット２の各々には、同じ低優先度レベルが割り当てられる。ＦＰ及び／又はＦＰのフリットは、同じ仮想レーンに割り当てられた場合には、互いを通り越すことができないが、異なる仮想レーンに割り当てられた場合には、互いを通り越すことが可能である。この状況はまた、異なる仮想レーンが同じ優先度レベルを有する場合にも生じ得る。一般に、２つ（又は３つ以上）の仮想レーンにおけるＦＰが、同じ優先度レベルを共有する場合、そのＦＰは、全体が（フリットを介して）フリット送信ストリームに追加される。例えば、第１のＦＰの全てのフリットが追加され、第２のＦＰの全てのフリットが追加される、等である。同じ優先度レベルを共有している複数のＶＬからどのＦＰを次に送出するかの選択は、アービタ選択ロジックの機能であり、これは、一般に、ＶＬにおけるＦＰの送信を等しく（あるいは、公平に等しく）処理するよう設計される。例えば、いくつかの実施形態において、ラウンドロビンスキームが実装され得る。そのようなラウンドロビンスキームはまた、複数のＶＬにわたるバッファ使用レベルが何らかのレベルに対してターゲットされるように、ＦＰの長さを考慮に入れ得る。例えば、２つのＶＬの間におけるラウンドロビンのみのアプローチは、ＶＬにおけるＦＰの送信を交互に行うであろうが、使用レベルのアプローチは、第１のＦＰが、第２のＦＰ及び第３のＦＰよりも著しく大きい場合、ＶＬのうちの１つのＶＬから第１のＦＰを送信した後、他のＶＬから第２のＦＰ及び第３のＦＰを送信し得る。
【0073】
図１７に示される例の下では、通常は、パケット１のフリットの全てが送信された後、パケット２のフリットの全てが送信される（プリエンプションインターリービングイベントがなく、ＶＬ１及びＶＬ２のみが調停（arbitration）のために考慮されると仮定した場合）。しかしながら、図示されるように、時間Ｔ４において、パケット１のフリットの転送においてバブルが始まる。アービタロジックは、バブルの存在と、ＶＬ２ ＦＩＦＯバッファ１６０４内のパケット２のフリットの利用可能性（availability）と、を考慮に入れる。それに応じて、バブルインターリービングイベントが検出され、これは、時間Ｔ５において、パケット１のフリットが、パケット２のフリット１７０８によりインターリーブされることが開始されることをもたらす。プリエンプティブインターリービングと同様に、インターリービングの開始は、ＶＬ２をアクティブＶＬレジスタにロードして、ＶＬ１をスタックにプッシュすることにより始まる。
【0074】
パケット２からのフリットがフリット送信ストリーム１７０４に追加されている間に、時間Ｔ６において、パケット１のフリットの第２の部分（及び残りの部分）が、ＶＬ１ ＦＩＦＯバッファ１６０２において受信されバッファされることが始まる。これらのフリットは、直ちに送信するために利用可能であるが、時間Ｔ６におけるそれらの受信は、インターリービングイベントを発生させない（あるいは、パケット２からのフリットのインターリービングを終了させない）。代わりに、パケット２からのフリットは、ＶＬ３ ＦＩＦＯバッファ１６０６内のヘッドフリット１７１０を含むパケット３のフリットの利用可能性の検出に応じて時間Ｔ７においてプリエンプティブインターリービングイベントが検出されるまで、フリット送信ストリーム１７０４に追加され続ける。図１６の例と同様に、ＶＬ３は、ＶＬ１又はＶＬ２の優先度レベルよりも高い高優先度レベルを有する。結果として、高優先度のパケット３のフリットの利用可能性は、時間Ｔ８において、パケット２のフリットとパケット３のフリット１７１２とのプリエンプティブインターリービングを開始させ、時間Ｔ９において、テールフリット１７１５の追加で完了する。パケット３のインターリービングが完了すると、ＶＬ２が、スタックからポップされ、アクティブＶＬレジスタにロードされる。したがって、ＶＬ２が、アクティブ仮想レーンに戻される。これは、パケット２の残りのフリット１７１６をフリット送信ストリーム１７０４に追加することをもたらす。
【0075】
時間Ｔ１０において、フリット送信ストリーム１７０４へのテールフリット１７１８により特定されるパケット２の完了時に、ＶＬ１が、スタックからポップされ、アクティブＶＬレジスタにロードされ、ＶＬ１が、アクティブＶＬに戻される。これは、パケット１の残りの部分に対応するフリット１７２０をフリット送信ストリーム１７０４に追加することをもたらし、時間Ｔ１１において、テールフリット１７２２が追加されたときに、パケット１のフリットの追加が完了する。
【0076】
リンク信頼性
上述したように、アーキテクチャのファブリックは、「無損失」であり、これは、パケットが、受信時に決して破棄されないこと、又は、パケットが、伝送中に「損失されない」ことを意味する。これは、クレジットベースフロー制御の使用及びリプレイバッファの使用を主として含むメカニズムの組合せにより実現される。クレジットベースのアプローチの下では、送信ユニット（例えば、ＨＦＩ、スイッチ、又はゲートウェイ）は、送信ユニットがフリットを送信するためのクレジットを有さない限り、フリットを受信ユニット（例えば、別のＨＦＩ又はスイッチ）に送信しない。クレジットは、ＶＬ単位であり、受信機が、フリットのために使用されるＶＬのための十分なバッファスペースを有することを示すために使用される。
【0077】
各ＬＴＰは、１以上のＣＲＣを含み、１以上のＣＲＣは、標準型検出ＬＴＰが使用されているか、拡張型検出ＬＴＰが使用されているかに応じて、データインテグリティを検証するために使用される。１以上のＣＲＣは、ＬＴＰのデータコンテンツに対して計算され、結果として生じる１以上のＣＲＣ値が、図５〜図８に示され上述した最後のフリット（フリット１５）に続いてＬＴＰの最後に付加される。受信されると、１以上のＣＲＣは再計算され、データエラーが存在するかどうかを判定するために、再計算された１以上のＣＲＣと受信ＬＴＰと受信データ内の１以上のＣＲＣとの比較がなされる。送信側ＣＲＣと、受信データに対して計算された受信側ＣＲＣと、が一致しない場合、データエラーが検出される。ＣＲＣの不一致の検出に応じて、ＬＴＰは、リプレイバッファの使用を介して再送信される。
【0078】
再送信リクエストの欠如が、ＬＴＰがピアにより無事に受信されたことを示すことを確実にするのに十分長い時間期間の間、「高信頼性」ＬＴＰは、リプレイバッファに保持される。このアプローチ下では、受信機は、パケットが無事に受信されたことを確認するためのＡＣＫを送信しない。代わりに、ラウンドトリップ時間期間内での再送信リクエストの欠如は、ＬＴＰがリンクを介して無事に転送されたという暗示的アクノレッジメントを提供する。用語「高信頼性」ＬＴＰの使用は、リプレイバッファに保持されるＬＴＰと、リプレイバッファに保持されない、ヌルＬＴＰ等のＬＴＰと、を区別するためのものである。したがって、ヌルＬＴＰは、再送信されない。
【0079】
リプレイバッファ位置ポインタが、送信機における各ＬＴＰ（ＮｘｔＴｘＬＴＰ）及び受信機における各ＬＴＰ（ＮｘｔＲｘＬＴＰ）に対して保持されるが、ＬＴＰの一部として交換されるものではない。伝送エラーが、（ＣＲＣの不一致を介して）受信機により検出された場合、受信機は、ＮｘｔＲｘＬＴＰリプレイバッファ位置ポインタを含むＲｅｔｒｙＲｅｑＬＴＰを送信機に送信する。送信機においてＲｅｔｒｙＲｅｑＬＴＰが受信されると、リプレイバッファ内のＬＴＰが、ＲｅｔｒｙＲｅｑＬＴＰ（ピアＮｘｔＲｘＬＴＰ）リプレイバッファ位置で始まり、書き込まれた最後のリプレイバッファ位置で終わる元の順番で再送信される。一実施形態において、ＬＴＰデータを（ＮｘｔＷｒＬＴＰ）に書き込むために次のリプレイバッファスロットが使用され、したがって、書き込まれた最後のリプレイバッファ位置は、（ＮｘｔＷｒＬＴＰ−１）である。
【0080】
ＣＲＣの不一致により示されるリンクエラーの検出に関連して、どのレーンが不良である（errant）かを判定するための第２のメカニズムが実装される。このメカニズムは、受信機においてのみ計算されるレーン毎ＣＲＣ（per-lane CRC）を使用し、送信データ内のレーン毎ＣＲＣ（存在しない）との比較は用いない。代わりに、以下で説明するように、レーン毎ＣＲＣを使用して、レーン単位又は転送グループ単位で、ＣＲＣの不一致を伴うＬＴＰのために計算されるレーン毎ＣＲＣを、リプレイバッファを介して再送信された場合の同じＬＴＰのために再計算された対応するレーン毎ＣＲＣと比較する。
【0081】
不良レーンを検出するための、レーン毎ＣＲＣと組み合わせたリプレイバッファの使用の一例が、図１８ａ及び図１８ｂに示されている。この例において、ＬＴＰ送信ストリーム１６０４のＬＴＰ２、３、４、５、６、及び７を含むＬＴＰ送信ストリームが、デバイスＡのリンクインタフェースＡから、リンクの他方の端におけるピアデバイスＢのリンクインタフェースＢに送信中である。より詳細には、ＬＴＰ送信ストリームは、上述した図１７に示されるものと同様の４レーンリンクインターコネクトを用いて、リンクインタフェースＡの送信ポート１８００から、リンクインタフェースＢの受信ポートに送信される。アーキテクチャのリンクの下では、ＬＴＰコンテンツは、複数のレーンを介して、並列にシリアル送信される。上述したように、レーンの数は、特定のリンク構成に応じて変わり得る。加えて、低減された数のレーンを有するリンク上における転送もサポートされる。限定ではなく例として、単一ビットが、ユニット間隔（ＵＩ：unit interval）と呼ばれる時間期間中、各レーンを介して伝送される。一実施形態において、転送されるＬＴＰデータは、転送ユニット（ＸＦＲ）と呼ばれるデータユニットに分割される。一実施形態において、各ＸＦＲは、３２ビット量である。一実施形態において、ＸＦＲの全ビットが、同じレーンを用いて伝送される。いくつかの実施形態において、いくつかのＸＦＲは、複数のレーンを介して伝送され得る。
【0082】
図１９は、１０５６ビット長を有する標準型検出ＬＴＰに関するＸＦＲのマッピングを示している。各ＸＦＲは、３２ビット長であり、単一のレーンを介して転送される。したがって、各ＬＴＰについて３３個のＸＦＲが存在する。図２０は、一実施形態に従った、４レーンリンクに関するレーン毎ＸＦＲマッピング（per-lane XFR mapping）を示している。名目上、例示の目的及び単純さのために、各フリットは、６４ビットである。しかしながら、図３に示されるように、各フリットは、（ボディフリットのために）全部で使用されるか、あるいは、そのフリットタイプを識別するために（ヘッドフリット、テールフリット、及び制御フリットのために）部分的に使用される追加の６５番目のビットを有する。伝送中、６５番目のビットは、インラインで（in-line）伝送され、これは、複数のレーンを介して並列に伝送されたシリアル転送ビットストリームがデシリアライズされて再組み立てされたときに、６５番目のビットが、１０５６ビット標準型検出ＬＴＰ内に、６５番目のビット位置毎に存在することを意味する。
【0083】
４レーンリンクの一実施形態において、２つのフリットのデータビットは、４つのＸＦＲを含む１２８ビットが（論理的に）一緒に転送されるように、３２ＵＩにわたって、リンクを介して並列に転送される。しかしながら、上述したように、全ての６５番目の位置は、フリットタイプビットにより占有される。結果として、ＸＦＲは、フリットと２：１に正確にマッピングするわけではない。そうではなく、追加の６５番目のビットがインラインで存在することは、図２１に示されるように、ラップ（折り返し）転送（wrapped transfer）をもたらす。
【0084】
さらに詳細には、一実施形態において、追加の２ビットが、１２８ＵＩ毎にラップされ、これは、４レーンＸＦＲの８個のグループが完了した後に、１６ビットの集約をもたらす。これら８個のグループは、最初の３２個のＸＦＲと、フリット１５の最後の１６ビット（及びその６５番目のビット）を含む３３番目のＸＦＲと、を含み、それらの後に、１６ビットＣＲＣ（又は、任意的に、１４ビットＣＲＣ、及びＣＲＣ−１４ ＬＴＰのための２つの制御チャネルビット）を含む。例示の目的及び理解のしやすさのために、フリットは、本明細書において、６４ビットのユニットで転送されるものとして例示され得る。しかしながら、一実施形態においては、フリットは、実際、６５ビットのユニットで転送されることを理解されたい。
【0085】
図２０の４レーンＸＦＲマッピングに戻ると、１つの１０５６ビット標準型検出ＬＴＰ当たり３３個のＸＦＲを使用することは、各ＬＴＰについて１つのＸＦＲのラッピングをもたらす。これが、今度は、ＬＴＰが、レーン０、レーン１、レーン２、レーン３のレーンシーケンスで始まり、レーン０、レーン１．．．等に戻ることに従って、各続くＬＴＰの開始ポイントを次のレーンにシフトさせる。これは、本明細書において、４レーン標準型検出ＬＴＰ「シーケンス」又は単に短くＬＴＰシーケンスと呼ばれる（本明細書で例示及び説明する４つのレーンを介する標準型検出ＬＴＰ転送に適用される）。便宜上、ＬＴＰシーケンス状態が、第１、第２、第３、及び第４として図示されているが、一実施形態においては、これは、２ビットを用いて、０、１、２、３として追跡される。
【0086】
図１８ａに示されるように、ＬＴＰ送信ストリーム１６０４内のフリットのシリアライゼーション及びマッピングは、送信リンク制御ブロック１８０４により実行される（あるいは、このオペレーションの一部は、図示されていない別のブロックにより実行される）。送信リンク制御ブロック１８０４により処理される前に、各高信頼性ＬＴＰのデータコンテンツが、リプレイバッファ１８０６内のＬＴＰスロットのうちの１つにコピーされる。ＬＴＰスロットは、ＮｘｔＷｒＬＴＰポインタ１８０７により特定される。一般に、リプレイバッファは、可変サイズを有することもあるし、予め定められたサイズを有することもある。一実施形態において、リプレイバッファは、複数の予め定められたサイズのうちの１つに選択的に構成され得る。
【0087】
図示されるように、一実施形態において、リプレイバッファは、最後のＦＩＦＯスロットから最初のＦＩＦＯスロットに戻るようラップする（折り返す）（この例では、スロット７からスロット０にラップする）値を有する次の送信ＬＴＰ（ＮｘｔＴｘＬＴＰ）ポインタ１８０８を含む循環ＦＩＦＯとして実装される。循環ＦＩＦＯの使用は、（前に送信されたＬＴＰに対応する）前のＬＴＰデータが、新たな（次に送信される）ＬＴＰデータにより上書きされることをもたらす。しかしながら、以下で詳述するように、ＬＴＰデータが無事に転送されたという暗示的アクノレッジメントが検出されるまでＬＴＰデータが上書きされないことを確実にするための手段が提供される。このスキームは、明示的ＡＣＫを用いる必要なく、リンクを介するデータの高信頼性送信を円滑にし、したがって、ＡＣＫの使用に関連するオーバーヘッドを低減させる。これはまた、リンクレイヤより上位のプロトコル（ＴＣＰ等）のために使用されるＡＣＫベースの高信頼性送信スキームをサポートするのに必要な送信ポートにおけるバッファリングを低減させる。
【0088】
図２２ａ〜図２２ｅのフローチャート２２００ａ〜２２００ｅと、図２３ａ及び図２３ｂの送信機状態機械図２３００及び受信機状態機械図２３５０と、を参照すると、不良リンクレーンの検出を含むリンクエラーのハンドリングは、一実施形態に従って、次のように実施される。リンク初期化プロセス中、様々な情報が、リンクのインタフェースのピア送信ポートとピア受信ポートとの間で交換され、双方向通信リンクが確立される。このプロセス中、リプレイバッファのＮｘｔＴｘＬＴＰポインタ１８０８及び受信側の対応する次の受信ＬＴＰ（ＮｘｔＲｘＬＴＰ）ポインタ１８１０が、０に初期化される。リンクの初期化が成功すると、開始ブロック２２０２により示されるように、リンク転送モードが「通常」に設定され、図２３ａ及び図２３ｂにおいて、送信機及び受信機が、ＬｉｎｋＴｒａｎｓｆｅｒＡｃｔｉｖｅ．ｎｏｒｍａｌ状態になり、ＬＴＰが、リンクを介して転送される準備ができた状態となる。明瞭さのために、以下では、データが一方向に転送されることにフォーカスしている。リンクを介する双方向通信をサポートするために、同様のオペレーションが、（レーンの別のセットを用いる）逆方向においても実行される。
【0089】
ＬＴＰ送信ストリーム１６０４内のＬＴＰは、シーケンシャルに送信されるので、ＬＴＰのデータは、リプレイバッファ１８０６にシーケンシャルにコピーされ、ＮｘｔＴｘＬＴＰポインタ１８０８は、ＬＴＰ毎に１スロット進む（あるいは、最後のスロット（ＭｙＬＴＰｍａｘ）に達すると、０に戻るようラップする）。図１８ａに示される例示的な状態において、ＬＴＰ２〜６は、送信ポート１８００から以前に送信されたものであって、ＬＴＰ２及びＬＴＰ３は、受信ポート１８０２により以前に受信され、Ｒｘリンク制御ブロック１８０５により処理されて、ＬＴＰ ＣＲＣの一致に基づいて、良ＬＴＰ（good LTP）であると判定されたものである。ＬＴＰ４は、受信されているのに対し、ＬＴＰ５及びＬＴＰ６は、伝送中である（これらＬＴＰのデータは、送信ポート１８００から送出されてはいるが、受信ポート１８０２においてまだ受信されていない）。
【0090】
フローチャート２２００ａに戻ると、メインフローチャートループは、ブロック２２０４で始まり、ブロック２２０４において、ＬＴＰが、受信ポートにおいて受信される。図１８ａの例において、このオペレーションは、ＬＴＰ４が受信ポート１８０２において受信されることにより示される。ブロック２２０６に示されるように、レーン毎に、ＣＲＣが、適用可能なＬＴＰシーケンス状態中にレーンを介して受信されたデータに基づいて計算され、そのＣＲＣが、ＣＲＣレーンレジスタＣＲＣ−Ｌ０、ＣＲＣ−Ｌ１、ＣＲＣ−Ｌ２、及びＣＲＣ−Ｌ３により示されるレーン毎ＣＲＣレジスタに書き込まれる。一実施形態において、これらレジスタ内のデータは、ＣＲＣレーンレジスタが最も直近に処理されたＬＴＰ用のデータしか記憶しないように、現在のＬＴＰのＣＲＣ計算結果により上書きされる。一実施形態において、４レーンリンクのためのレーン毎ＣＲＣは、各レーンのビットが受信されたときに動的に計算される１２ビットＣＲＣである。
【0091】
ブロック２２０８において、受信されたＬＴＰデータのＣＲＣ（Ｒｘ ＣＲＣ）が計算され、送信されたＬＴＰ内のＴｘ ＣＲＣと比較される。Ｔｘ ＣＲＣは、受信機に送信されるＬＴＰデータを用いて送信ポート１８００により計算され、本明細書における様々なＬＴＰフォーマットにより示されるように、ＬＴＰの最後に付加される。受信機は、受信されたＬＴＰデータから、Ｔｘ ＣＲＣを抽出し、Ｔｘ ＣＲＣと、受信されたＬＴＰデータに対して計算されたＲｘ ＣＲＣと、を比較する。判定ブロック２２１０において、受信されたＴｘ ＣＲＣと計算されたＲｘ ＣＲＣとが一致するかどうかが判定される。Ｔｘ ＣＲＣとＲｘ ＣＲＣとが一致する場合、ブロック２２１２に示されるように、そのＬＴＰは良ＬＴＰとみなされ、ＬＴＰデータの通常処理が実行され、ロジックは、ブロック２２０４に戻って、次の受信されたＬＴＰを処理する。
【0092】
図１８ａに示される例において、ＬＴＰ４について、Ｔｘ ＣＲＣとＲｘ ＣＲＣとが一致しない場合（ＣＲＣの不一致の場合）、これは、ＬＴＰデータエラーを示す。リンクデータエラーは、様々なリンク状態から生じ得るものであり、この時点においては、エラーを生じさせた特定のリンク状態は未知である。分かることは、受信されたＬＴＰデータが送信されたものとは異なるということであり、したがって、受信されたＬＴＰは不良データを有し、さらに処理されることはない。不一致のＬＴＰ ＣＲＣは、判定ブロック２２１０のＮＯの結果に対応し、これは、ロジックに、ブロック２２１４に進ませ、ブロック２２１４において、ＬＴＰが、不良パケットとして示され、また、受信機状態図２３５０においてＲｃｖＢａｄＬＴＰにより示される。不良ＬＴＰの検出に応じて、（図２２ａにおける）ブロック２２１６、（図２２ｂにおける）ブロック２２１８、及び（図２２ｂにおける）ブロック２２２０の各々におけるオペレーションにより示されるように、複数のオペレーションが開始されて実質的に並列に実行される。
【0093】
ブロック２２１６に示されるように、不良ＬＴＰについて計算されたレーン毎ＣＲＣ値が、レーン単位又はＸＦＲグループ単位で記憶される。１つのＬＴＰ当たりのＸＦＲの数が、レーンの数で割り切れる場合、レーン毎ＣＲＣ値は、レーン単位で記憶され、１つのＬＴＰ当たりのＸＦＲの数が、レーンの数で割り切れない場合、レーン毎ＣＲＣ値は、ＸＦＲグループ単位で記憶される。例えば、３つのアクティブレーンを有するリンク及び３３個のＸＦＲの場合、３３／３＝１１であるので、レーン毎ＣＲＣ値は、レーン単位で記憶される。反対に、４レーン又は２レーンの場合、レーン毎ＣＲＣ値は、ＸＦＲグループ単位で記憶される（３３／４＝７．５であり、３３／２＝１６．５であるので）。ＸＦＲグループ毎ＣＲＣ（per XFR-group CRC）が記憶される場合、受信ＬＴＰシーケンス状態がレジスタ１８１４に記憶される。
【0094】
ＸＦＲグループ毎ＣＲＣの例が、図２４に示されている。図示されるように、レーン毎ＣＲＣが計算される対象のＸＦＲの数は、４つのレーンにわたって等しくない。そうではなく、４つのレーンのうちの１つは、１つの標準型検出ＬＴＰ当たり９個の３２ビットＸＦＲ（したがって２８８ビット）を受信する一方、他の３つのレーンは、８個の３２ビットＸＦＲ（したがって２５６ビット）を受信する。さらに、９個の３２ビットＸＦＲを受信するレーンは、ＬＴＰシーケンス状態に応じて変わる。以下でさらに詳細に説明するように、記憶されているレーン毎ＣＲＣを使用して、ＣＲＣの不一致を伴うＬＴＰのＸＦＲグループ毎ＣＲＣと、同じＬＴＰの後続の再送信と、を比較することにより、どの１以上のレーンがエラーを生じさせたかを検出する。元のＬＴＰ送信のために使用されたＬＴＰシーケンスは、再送信されたＬＴＰのために使用されたＬＴＰシーケンスとは異なることがあるので、ＸＦＲグループ毎ＣＲＣが使用される。ＸＦＲグループ毎ＣＲＣは、同じＸＦＲに対して計算されたＣＲＣの比較をもたらすのに対し、レーン毎ＣＲＣスキームが使用される場合、レーン毎ＣＲＣは、４つのレーンを有するリンクの動作時には同じＸＦＲに対するＣＲＣ計算をもたらすこともあるしもたらさないこともあり（同じである確率は２５％）、２つのレーンを有するリンクの動作時にも同じＸＦＲに対するＣＲＣ計算をもたらすこともあるしもたらさないこともある（同じである確率は５０％）。
【0095】
図２４に示されるように、ＸＦＲグループ毎ＣＲＣは、ＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２、及びＣＲＣ−Ｇ３とラベル付けされている。これらＣＲＣが計算される転送は、レーン及びＬＴＰシーケンス状態の両方に依存する。例えば、第１のＬＴＰシーケンス状態の場合、ＣＲＣ−Ｇ０は、レーン０上で受信された９個のＸＦＲ０、４、８、１２、１６、２０、２４、２８、及び３２から計算される一方、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２、及びＣＲＣ−Ｇ３の計算値は、レーン１、２、及び３のそれぞれに示される８個のＸＦＲに依存する。第２のＬＴＰシーケンス状態下では、ＣＲＣ−Ｇ０は、レーン１上の９個のＸＦＲから計算される一方、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２、及びＣＲＣ−Ｇ３の計算値は、レーン２、３、及び１のそれぞれに示される８個のＸＦＲに依存する。図示されるように、第３のＬＴＰシーケンス状態及び第４のＬＴＰシーケンス状態の両方についても、同様の手法が使用される。
【0096】
図１８ａに示される時間フレーム中、ＬＴＰシーケンス状態は１であり、したがって、ＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２、及びＣＲＣ−Ｇ３はそれぞれ、ＬＴＰ４について、レーン０、レーン１、レーン２、及びレーン３上で受信されたデータから計算される。ＬＴＰのＸＦＲグループ毎のＣＲＣ−Ｇ０値、ＣＲＣ−Ｇ１値、ＣＲＣ−Ｇ２値、及びＣＲＣ−Ｇ３値の例示的な計算値が、図１８ａ及び図２５に示されており、それぞれ、４２８、５５６、２０８、及び８０４である。これらＸＦＲグループ毎ＣＲＣ値は、レジスタＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２、及びＣＲＣ−Ｇ３に記憶される。
【0097】
図２２ｂにおけるフローチャート２２００ｂのブロック２２１８に進み、再送信リクエスト（ＲｅｔｒｙＲｅｑ ＬＴＰ１８１２）が、受信機から送信機に返され、ＮｘｔＲｘＬＴＰポインタ１８１０の現在値により不良ＬＴＰが特定される。一実施形態においては、ＲｅｔｒｙＲｅｑ ＬＴＰのシーケンシャルペアが送信されるのに対し、別の実施形態においては、１つのＲｅｔｒｙＲｅｑ ＬＴＰが送信される。この例においては、ＮｘｔＲｘＬＴＰポインタ値は、不良ＬＴＰであるＬＴＰ４のデータを記憶しているリプレイバッファスロット４を示している。ＲｅｔｒｙＲｅｑ ＬＴＰを受信したことに応答して開始されるリプレイモード時の送信側オペレーションの詳細が、図２２ｃのフローチャート２２００ｃに示されている。
【0098】
また、ブロック２２１４において不良ＬＴＰが検出されると、ブロック２２２０において、ＬＴＰ受信モードが、「ＬＴＰ−トス（LTP-tossing）」に設定され、これは、不良ＬＴＰを含む受信されたＬＴＰがトスされる（破棄される）ことをもたらす。ＬＴＰ−トスモードは、受信機状態図２３５０において、ＬＴＡ．ＲｘＴｏｓｓｉｎｇとして示される。受信機が、ＬＴＰ−トスモードで動作している間、ＬＴＰが受信され、レーン毎ＣＲＣが計算されてレジスタが更新され、シーケンシャルＬＴＰ ＣＲＣエラーを検出するために、ＬＴＰ ＣＲＣエラーチェックが実行され、ＬＴＰが破棄される。これらのオペレーションは、ブロック２２２２においてＬＴＰを受信することで始まるループ状で実行される。前と同様、ブロック２２０６及びブロック２２０８のオペレーションが実行され、次いで、判定ブロック２２２４において、受信されたＬＴＰがＣＲＣエラーを有する（Ｔｘ ＣＲＣとＲｘ ＣＲＣとの不一致を伴う）かどうかが判定される。受信機が、ＬＴＰ−トスモードで動作している間、ロジックは、シーケンシャルＬＴＰ ＣＲＣエラーの発生をチェックするよう構成されている。例えば、ＬＴＰ−トスモードに入った後最初に受信されたＬＴＰがエラーを有していた場合、シーケンシャルエラーが発生したことになる。シーケンシャルエラーを検出する判定が、判定ブロック２２２６により示されており、判定ブロック２２２４の結果がＹＥＳであった場合、ロジックは、判定ブロック２２２６に進む。加えて、ブロック２２２５において、総ＬＴＰ ＣＲＣエラーカウントがインクリメントされる。（総ＬＴＰ ＣＲＣエラーカウントは、通常モードであるかトスモードであるかにかかわらず、各ＬＴＣ ＣＲＣエラーの検出に応じてインクリメントされる。）
【0099】
ＣＲＣは、パケットやフレーム等の送信データユニット内のエラーを検出するよう構成されているデータインテグリティチェックである。ＣＲＣの数学式は、ＣＲＣがビット伝送エラーを検出するように選択され、デジタルデータの２値性を利用して、ＣＲＣがバイナリ量に対して迅速に計算されることを可能にする。しかしながら、ＣＲＣは、１００％確実なものではない。ＣＲＣチェックは、ビットエラーの数が、ＣＲＣのハミング距離以上である場合にはエラーを検出することができない。ネットワークファブリックにおいて使用されるＣＲＣのハミング距離は、通常４であり、これは、エラーが検出されないであろう可能性（極めて低い確率）を広げるために少なくとも４つのビットエラーを要することを意味する。未検出リンクエラーは、「誤パケット許容（false packet acceptance）」と呼ばれるものをもたらし、これは、エラーを有するパケットが（誤って）ＣＲＣチェックを通ってしまい、したがって、さらなる処理が許容されることを意味する。このような未検出エラーは、パケットサイレントデータ破損（packet silent data corruption）をもたらす。
【0100】
ＬＴＰは、およそ１０００ビットのサイズである。所与の平均ビットエラー率（ＢＥＲ）では、検出を見逃す確率は、エラーが複数のＬＴＰにわたって経時的に広がっていく均一な単一リンク転送パケット対エラーパターンにおいて、エラーが相関しており、（４以上の）バーストで生じる場合には、より高くなる。
【0101】
ネットワークファブリックリンクは、非常に低いが０ではないＢＥＲを提供するよう設計される。リンク電力を低減させたいと望むことは、より高いＢＥＲを許容する動機付けを与え、ＢＥＲは、電力が低減されるにつれ増大する傾向にある。ＢＥＲが増大すると、エラー検出を見逃す確率が増大する。何らかのポイントにおいて、この確率は、許容できないほど高くなる。ファブリック内の多くのリンクにわたるＢＥＲは均一ではない。リンクは、通常、複数のレーンを含み、ＢＥＲは、所与のリンクにおけるレーンにわたって広範に変わり得る。従来のアプローチ下では、ファブリック管理ソフトウェアが、何らかの閾ＢＥＲで動作しているリンクを検出したときに、許容できないほど高い確率のデータ破損を避けるために、ファブリックからそのリンクを除去することを余儀なくされる。これは、そのリンクにおけるエラーの広がりを知ることなく行われ、エラーが相関していると想定した保守的なより小さなＢＥＲ閾値の使用を強いる。加えて、リンクのＢＥＲは、時間とともにドリフト及び／又は劣化して、許容できないほど高くなり得る。ファブリックマネージャは、全てのリンクを継続的にリアルタイムで常にモニタリングできるわけではない。結果として、リンクが過度に高いＢＥＲで動作していることを検出するには、いくらかの時間がかかり得る。この時間の間、ファブリックは、データ破損の可能性にさらされる。
【0102】
密接しているビットエラーに対する１つのチェックは、判定ブロック２２２４におけるＬＴＰ ＣＲＣエラーチェックと、判定ブロック２２２６におけるシーケンシャルＬＴＰ ＣＲＣエラーチェックと、を使用することによるものである。ＣＲＣは、少なくとも１つのエラーが検出されたことを識別するために使用することはできるが、どれくらいの数のエラーが存在するかを識別するものではない。しかしながら、シーケンシャルＬＴＰ ＣＲＣエラーは、少なくとも２つのエラーが、シーケンシャルＬＴＰ内に存在することを示す。
【0103】
一実施形態において、ブロック２２２８において、シーケンシャルＬＴＰ ＣＲＣエラーの検出に応じて、ＲｅｔｒａｉｎＲｅｑ ＬＴＰのペアが、送信機に送信され、これは、フローチャートロジックが、出口ブロック２２３２に示される、リンクを再トレーニングすることに抜け出ることをもたらし、送信機状態機械図２３００におけるＲｃｖＲｅｔｒａｉｎＲｅｑをもたらす。
【0104】
一実施形態において、この再トレーニングは、リンクを初期化又は再初期化するときに用いられるリンク（再）トレーニングオペレーションよりも複雑でない軽量再トレーニングである。トレーニング又は再初期化中、リンクの通常アクティブ転送状態はオフラインであり、これは、リンクトレーニング又はリンク再初期化が完了してリンクが通常アクティブ転送状態に戻るまで、通常データ転送オペレーションが一時的に利用できないことを意味する。加えて、受信機は、ブロック２２３０において、ＲｅｔｒａｉｎＲｅｑ ＬＴＰを送信したことを示す何らかの内部的しるしを設定し、ブロック２２３１において、リンクシーケンシャルエラータイマがリセットされる。リンクシーケンシャルエラータイマの使用についてのさらなる詳細が、図２２ｅに示されており、以下で説明される。トレーニングシーケンスが完了すると、ロジックは、フローチャート２２００ｂのブロック２２１８及びブロック２２２０に戻り、１以上のリトライリクエストＬＴＰが、送信側に再度送信され、受信機において、ＬＴＰ−トスモードに再び入る。
【0105】
リトライマーカＬＴＰを受信したことに応答して、ＬＴＰ−トスモードループから抜け出て、受信されたＬＴＰがＣＲＣエラーを有さない場合、それに応じて、ロジックは、判定ブロック２２３４に進み、判定ブロック２２３４において、ＬＴＰ−トスモードの間に受信された各良ＬＴＰがリトライマーカであるかどうかが判定される。再送信リクエストを受信する前に、送信機は、ＬＴＰを順に送信し続けており、これらのＬＴＰが、（もしあれば）すでに伝送中のＬＴＰとともに受信される。図２２ｃのフローチャート２２００ｃにおけるブロック２２３８、ブロック２２４０、及びブロック２２４２に示されるように、再送信リクエスト（ＲｅｔｒｙＲｅｑ ＬＴＰ）を受信すると、送信機は、リトライマーカを送出し、続いて、再送信リクエストを介して返されたＮｘｔＲｘＬＴＰポインタ値により示されるスロット内のＬＴＰで始まる、リプレイバッファ１８０６内のＬＴＰを再送信する。一実施形態においては、１つのリトライマーカが送信されるが、別の実施形態においては、リトライマーカのペアが連続して送信される。一実施形態において、リトライマーカのペアは、それらが送信される順番により特定される（例えば、ＲｅｔｒｙＭｒｋｒ０、ＲｅｔｒｙＭｒｋｒ１）。一実施形態において、リトライマーカの各々は、ヌルＬＴＰを含む。ＲｅｔｒｙＭｒｋｒ ＬＴＰ１８１６により示される１つのリトライマーカの使用の一例が、図１８ｂに示されている。リトライマーカのペアが送信されるときには、第２のリトライマーカ（ＲｅｔｒｙＭｒｋｒ１）は、ＲｅｔｒｙＭｒｋｒ ＬＴＰ１８１６（ＲｅｔｒｙＭｒｋｒ０）に直ちに続くことを理解されたい。
【0106】
図１８ａの例において、再送信リクエストを受信する前にＬＴＰの送信をこのように続けることは、ＬＴＰ５及びＬＴＰ６（伝送中）、ＬＴＰ７（次に送信された）、並びにＬＴＰ０及びＬＴＰ１を順番に受信することをもたらす。ＬＴＰ５、６、７、０、及び１の各々はリトライマーカではないので、判定ブロック２２３４の結果はそれぞれＮＯであり、ロジックは、ブロック２２３６に進み、ＬＴＰを破棄し、次いで、ブロック２２２２にループバックして、次のＬＴＰを受信する（ＬＴＰ−トスモードであり続ける間は）。判定ブロック２２３４において、リトライマーカＬＴＰが受信されて検出されるまで、後続の受信されるＬＴＰの処理が同様に続けられる。
【0107】
図１８ｂは、ＲｅｔｒｙＭｒｋｒ ＬＴＰ１８１６が送信され、受信ポート１８０２により受信されて処理され、ＬＴＰ４が再送信され、受信ポート１８０２により受信されており、その後に、再送信されたＬＴＰ５及びＬＴＰ６（伝送中）が続き、ＬＴＰ７が再送信されようとしている時間フレームを示している。ＬＴＰ４、５、及び６の各々は、「リプレイ」ＬＴＰを含む。また、図１８ｂに示されるように、（図１８ａに示される）スロット０及びスロット１内のリプレイバッファデータは、ＲｅｔｒｙＲｅｑ ＬＴＰ１８１２の受信及びＲｅｔｒｙＭｒｋｒ ＬＴＰ１８１６の送信の前に生じたそれらの元の送信に関連するＬＴＰ０及びＬＴＰ１の対応するフリットデータで上書きされている。
【0108】
前と同様に、各高信頼性ＬＴＰ送信について、ＬＴＰのデータが、ＮｘｔＴｘＬＴＰポインタ１８０８により特定される、リプレイバッファ１８０６内のスロットにコピーされる。ＮｘｔＴｘＬＴＰポインタ１８０８は、高信頼性ＬＴＰ毎にインクリメントされる。したがって、ＮｘｔＴｘＬＴＰポインタ１８０８は、ＬＴＰ７、０、及び１の各々を送信することに関連してインクリメントされる（ＮｘｔＴｘＬＴＰポインタは、７から０に戻るようにラップすることに留意されたい）。ＬＴＰ１が送信されている間に（あるいは、ＬＴＰ１が送信される直前に）、送信ポート１８００が、ＲｅｔｒｙＲｅｑ ＬＴＰ１８１２を受信する。それに応答して、送信ポート１８００は、ＲｅｔｒｙＭｒｋｒ ＬＴＰ１８１６（又は、ＲｅｔｒｙＭｒｋｒ０ ＬＴＰ及びこれに続くＲｅｔｒｙＭｒｋｒ１ ＬＴＰを含むリトライマーカのペア）を返す。ＲｅｔｒｙＭｒｋｒ ＬＴＰ１８１６はヌルＬＴＰであるので、そのデータコンテンツは、リプレイバッファ１８０６にコピーされず、ＮｘｔＴｘＬＴＰポインタ１８０８は進められない。反対に、Ｔｘ ＬＴＰシーケンス状態は、高信頼性ＬＴＰであるかヌルＬＴＰであるかにかかわらず、送信されるＬＴＰ毎に進められる。
【0109】
判定ブロック２２３４に戻って、ＲｅｔｒｙＭｒｋｒ ＬＴＰ１８１６が受信されると、リトライマーカとして識別され、フローチャートロジックは、図２２ｄにおけるフローチャート２２００ｄに進む。ブロック２２５２に示されるように、リトライマーカが処理され、受信機は、到来するリプレイ不良ＬＴＰの受信に備えるために、カウントダウン値を設定する。一実施形態において、不良ＬＴＰの再送信が、リトライマーカ後のｋ個のＬＴＰを開始することを示すために、不良ＬＴＰリプレイオフセットが、リトライマーカに対して使用される。リトライマーカのペアを使用する一実施形態において、不良ＬＴＰリプレイオフセットは、第２のリトライマーカの場合、１だけ小さい。また、ブロック２２４０に示されるように、不良ＬＴＰリプレイオフセットを考慮して、受信機は、ＬＴＰオフセットに基づいて、不良ＬＴＰリプレイカウントダウンを開始する。ブロック２２５６において、これを用いて不良ＬＴＰのリプレイを検出する。加えて、受信機は、ブロック２２５４において、１つのラウンドトリップマーカＬＴＰ（又は、ラウンドトリップマーカＬＴＰのペア）を返し、ブロック２２５４において、ＬＴＰ受信モード（受信状態）が通常に戻され、フローチャートロジックは、ブロック２２０４に戻って、次のパケットを受信する。これが、受信機状態図２３５０における「ＲｎｄＴｒｉｐＭｒｋｒペアを送信」状態と、ＬｉｎｋＴｒａｎｓｆｅｒＡｃｔｉｖｅ．ｎｏｒｍａｌ状態への戻りと、により示される。図１８ｃを参照して以下で説明するように、１以上のラウンドトリップマーカＬＴＰは、リプレイバッファＬＴＰを上書きできるかどうかの判定を容易にするために、１以上のリトライマーカＬＴＰに応答して返される。
【0110】
ＲｅｔｒｙＭｒｋｒ ＬＴＰ１８１６（又は、ＲｅｔｒｙＭｒｋｒ０ ＬＴＰ及びＲｅｔｒｙＭｒｋｒ１ ＬＴＰ）の送信に続いて、ＲｅｔｒｙＲｅｑ ＬＴＰ１８１２において返されたＮｘｔＲｘＬＴＰポインタにより特定される不良ＬＴＰ（この例ではＬＴＰ４）の再送信で始まるＬＴＰのリプレイ（再送信）が開始される。送信機がリプレイモードにある間、送信されるデータは、リプレイバッファ１８０６に記憶されている、再送信されるＬＴＰを含む。再送信されるＬＴＰは、リプレイバッファのＦＩＦＯにおける順番に基づいて、送信ポート１８００から、ＮｘｔＲｘＬＴＰポインタにより示されるＬＴＰで始まってシーケンシャルに送出される。
【0111】
再送信される各ＬＴＰについて、送信されるデータは、ＬＴＰが元々送信されたときのデータと同じである。不良ＬＴＰリプレイカウントダウン（及びリプレイ不良ＬＴＰを受信することに関連するオペレーション）以外は、受信側ロジックは、受信されたＬＴＰデータが元々送信されたＬＴＰに対応するか再送信されたＬＴＰに対応するかは知らない。したがって、ブロック２２０４、ブロック２２０６、ブロック２２０８、及び判定ブロック２２１０が実行され、レーン毎ＣＲＣの計算、受信されたＬＴＰデータに対するＲｘ ＬＴＰ ＣＲＣの計算、及びＲｘ ＬＴＰ ＣＲＣとＴｘ ＬＴＰ ＣＲＣとの比較がもたらされる。エラーが存在する場合、判定ブロック２２１０におけるＮＯの結果に示されるように、ロジックはブロック２２１４に戻り、不良再送信ＬＴＰは、不良ＬＴＰが再度再送信される新たなリプレイシーケンスを開始する。これは、リプレイバッファ１８０６からの不良ＬＴＰ４及びそれに続くＬＴＰの再送信に関連して上述したオペレーションを実質的に繰り返す。
【0112】
再送信された不良ＬＴＰ４が良ＬＴＰであるとみなされると、ロジックは、ブロック２２５８に進む。このブロックにおいて、レジスタＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、ＣＲＣ−Ｇ２、及びＣＲＣ−Ｇ３に以前に記憶されたレーン毎ＣＲＣ値が、再送信されたＬＴＰ４について、各レーンを介して受信されたデータに対して計算されたレーン毎ＣＲＣと比較される。この比較は、動作レーンの数に応じて、レーン単位又はＸＦＲグループ単位で行われる（レーン単位での比較及びＸＦＲグループ単位での比較は、ＸＦＲグループ単位での比較が常に実行され得るように、転送グループの数が同じであるときには同等であることに留意されたい）。から、レーン毎ＣＲＣは、４レーンリンクに関して、ＸＦＲグループ単位で比較される。
【0113】
送信されたＬＴＰ毎にＴｘ ＬＴＰシーケンス状態及びＲｘ ＬＴＰシーケンス状態をインクリメントすることを続けることに関連して、ＬＴＰ４が再送信されるとき、ＬＴＰシーケンス状態は３であるのに対して、ＬＴＰが元々送信されたときにはＬＴＰシーケンス状態は１であった。結果として、各レーンを介して送信されたＸＦＲグループは、変わっている。レーン−ＸＦＲグループのこの再マッピングが、図２５に示されており、これはまた、図１８ａにおいて各レーンを介して送信されたＸＦＲと図１８ｂにおいて各レーンを介して送信されたＸＦＲとを比較することにより、確認することもできる。上述したように、ＬＴＰ４が元々送信されたときには、ＬＴＰシーケンス状態は１であったのに対し、ＬＴＰ４が再送信されるときには（図２５における４Ｒにより示される）、ＬＴＰシーケンス状態は３である。
【0114】
図１８ｂに戻ると、再送信されたＬＴＰ４のレーン毎ＣＲＣが、レーン０、１、２、及び３について計算され、次いで、フローチャート２２００ｄのブロック２２５８において、ＸＦＲグループ毎ＣＲＣの比較が実行され、ブロック２２６０において、必要に応じて、不一致のレーン毎ＣＲＣ又はＸＦＲグループ毎ＣＲＣを識別することにより、不良レーンが識別される。図１８ａ及び図１８ｂの例において、ＸＦＲグループ毎ＣＲＣの比較結果は、ＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、及びＣＲＣ−Ｇ３のＣＲＣが一致していることを示しているのに対し、ＣＲＣ−Ｇ２のＣＲＣが一致していないことを示している。これは、レーン２が不良レーンであることを示す。なぜならば、ＬＴＰ４が元々送信されたときには、レーン２が、不良ＬＴＰ４についてＣＲＣ−Ｇ２値が計算されたＸＦＲグループに対応していたからである。再送信されたＬＴＰ４においてＬＴＰ ＣＲＣエラーが検出されなかったので、リプレイＬＴＰ４について、レーン２を介して送信されたデータ内にもエラーが存在しない（と想定される）ことに留意されたい。ブロック２２６１において、識別された不良レーンのエラーカウントがインクリメントされる。
【0115】
レーンが間欠的に不良であるシナリオを検討する。上述したように、判定ブロック２２２６及び関連する論理ブロックのシーケンシャルＬＴＰ ＣＲＣエラーチェックが、リンクを介して送信されたデータ内の密接しているエラーを検出するための１つのメカニズムである。このメカニズムは、（シーケンシャルＬＴＰ内のエラーを要求する）非常に密接しているエラーを検出するが、どのレーンが不良であるかを識別することはできないし、個々のレーン上でシーケンシャルエラーがどれくらいの頻度で発生しているかを識別することもできない。
【0116】
第２のＢＥＲチェックメカニズムの実施形態に従うと、所与のレーンのエラー頻度（ＢＥＲ）がレーン毎ＢＥＲ閾値を超えるかどうかを判定するために、レーン毎エラー頻度がモニタリングされる。一実施形態において、これは、（フローチャート２２００ｄ及びフローチャート２２００ｅに示される並列に実行される他のオペレーション及びロジックに関連して）レーン毎シーケンシャルエラーカウンタ及びタイマを使用することにより実現される。
【0117】
判定ブロック２２６２において、受信機状態が、受信機により開始されたリンク再トレーニング状態から生じたかどうかが判定される。フローチャート２２００ｂにおけるロジックに示され上述したように、シーケンシャルＬＴＰ ＣＲＣエラーの検出は、受信機がエラーを検出したことにより開始されるリンク再トレーニングをもたらす。反対に、１つのＬＴＰ ＣＲＣエラーも同様にリトライリクエスト・リトライマーカ受信シーケンスを開始させるが、リンク再トレーニングの開始はもたらさない。リプレイＬＴＰが良ＬＴＰであり、受信状態が、リンク再トレーニングから生じたものではない（すなわち、１つのＬＴＰ ＣＲＣエラーしか検出されなかった）場合、判定ブロック２２６２の結果はＮＯであり、これは、ロジックに、ブロック２２６４に進ませ、ブロック２２６４において、ＬＴＰが、あたかも元々送信されたＬＴＰであるかのように処理される。次いで、ロジックは、フローチャート２２００ａに戻り、（受信機の観点から）後続のリプレイＬＴＰが元々送信されているように後続のリプレイＬＴＰを処理する。
【0118】
ここで、２つのシーケンシャルＬＴＰ ＣＲＣエラーが受信機により検出されたと仮定すると、リンク再トレーニングが受信機により開始され、判定ブロック２２６２の結果がＹＥＳとなり、ロジックはブロック２２６６に進む。このブロックにおいて、ブロック２２６０において判別された不良レーンのシーケンシャルエラーカウンタがインクリメントされる。判定ブロック２２６８において、レーンのシーケンシャルエラーカウントが閾値に達したかどうかが判定される。一般に、この閾値は、１、２等の整数である。一実施形態において、この閾値は２であり、１回のタイマ期間内での１つのレーン上の２つのシーケンシャルエラーが、レーンＢＥＲ閾検出を始動させる。それに応答して、一実施形態において、ロジックは、出口ブロック２２７０に進み、不良レーンとして検出されたレーンが除去されてリンクが再初期化される。結果として、リンクのアクティブレーンの数が、１つのレーンだけ減り、例えば、４レーンリンクの場合は、３つのアクティブレーンに減る。
【0119】
レーン毎シーケンシャルエラーカウントが閾値に達していない場合、判定ブロック２２６８の結果はＮＯであり、ロジックはブロック２２０４に進み、受信機が通常受信状態で動作するとともに送信機が依然としてリプレイモードで動作して、次のＬＴＰを受信する。
【0120】
上述したように、一実施形態において、レーン毎シーケンシャルエラーの頻度を検出するために、タイムスキームが使用される。から、シーケンシャル不良ＬＴＰの検出に応じて、ロジックはブロック２２３１に進み、図２２ｅのフローチャート２２００ｅに示されるように、タイマスキームを実施するための並列オペレーションのセットが開始される。ブロック２２７２において、必要に応じて、タイマが開始されるか（最初の場合）、再開される（リセット時）。判定ブロック２２７４及び自身へのループバックにより示されるように、タイマが満了したかどうかを判定するために、タイマが定期的にチェックされる、あるいは、任意的に、タイマロジックは、タイマが満了したことを示す割り込み又は他のしるしを生成するよう構成されてもよい。タイマが満了すると、ブロック２２７６に示されるように、各レーンの不良シーケンシャルエラーカウンタがデクリメントされる。一実施形態において、最小の不良エラーカウントは０であるので、すでに０であるレーンエラーカウントに関しては、そのカウントはデクリメントされない。
【0121】
並列プロセスの組合せは、次のようにして、個々のレーン上のエラーが、頻度閾値を超えたことを検出する（例えば、密接しているエラーを示すレーンを識別する）。フローチャートオペレーションが、ロジックをブロック２２５８、ブロック２２６０、及び判定ブロック２２６４の結果のＹＥＳに進ませるたびに、不良レーンのシーケンシャルエラーカウントがインクリメントされる。その一方で、並列タイマオペレーションを考慮して、タイマが、再開されないで、レーン毎エラーがなくタイマの時間期間が経過したことを示すたびに、各レーンのレーン毎シーケンシャルエラーカウントが１だけデクリメントされる（最小０まで）。一実施形態において、２になると（two strikes）そのレーンは機能しなくなり（out）、これが、タイマ期間内に２つのシーケンシャルエラーを有するレーンに対応する。
【0122】
１つのタイマに加えて、異なる時間期間を有し、異なるカウント閾値に関連付けられる複数のタイマが並列に使用されてもよい。例えば、これは、レーン毎オペレーションのより長期のビュー（view）が観測されることを可能にしながら、より短いレーン毎ＢＥＲ閾検出も容易にする。時間期間内に必要とされるシーケンシャルエラーの数の閾値は、変更されてもよい。
【0123】
フローチャート２２００ａ〜２２００ｅに示される実施形態の下では、不良レーンの除去と組み合わせたリンクの再初期化は、密接しているエラーを示すレーンの検出から生じる。しかしながら、これに限定される意図はない。なぜならば、レーンは、シーケンシャルＬＴＰ ＣＲＣエラーの検出に続いて出口ブロック２２３２を介して抜け出るとき等の他の条件下で、リンクを再初期化すること及び／又はリンクを再トレーニングすることに関連して、除去されてもよいからである。例えば、リンクが再初期化されるときに、エラーカウントが何らかの閾値を超えたかどうかを確認するために、レーン毎エラーカウンタがチェックされる。そうであれば、そのレーンは、不良とマークされ、リンクがアクティブオペレーションに戻ったときアクティブでない。
【0124】
暗示的ＡＣＫを用いた高信頼性ＬＴＰ送信の別の態様は、ＬＴＰがエラーなく受信されたことの暗示的確認の前にはリプレイバッファ内のＬＴＰが上書きされないことを確実にするためのメカニズムである。一実施形態において、これは、リトライリクエスト及びラウンドトリップマーカを使用することにより容易にされる。上述したように、いくつかの実施形態において、リプレイバッファは、固定サイズを有する、あるいは、複数の固定サイズのうちの１つを用いて動作するために設定されるよう構成され得る。加えて、リンクピアのペアは、異なるサイズのリプレイバッファを使用することもある。
【0125】
固定サイズのリプレイバッファの使用下では、リプレイバッファは、一般に、様々な処理遅延をさらに考慮して、リンクのラウンドトリップ移動（roundtrip traversal）中に転送され得るＬＴＰの数よりも多い数のＬＴＰを保持するサイズとされる。これが、図１８ａ及び図１８ｂに示される場合であり、これらの図において、リプレイバッファは、８つのスロットを有し、リンク及び反対方向のリンクパスを介してラウンドトリップを同時に移動し得るＬＴＰの数は、およそ６又は７個のＬＴＰである。結果として、受信機において検出されたエラーが存在する場合、送信機は、リプレイバッファ内の不良ＬＴＰのコピーが上書きされる前に、リトライリクエストを受信する。
【0126】
しかしながら、実用上の理由で、固定サイズのリプレイバッファは、全ての可能性のあるリンク長に対処するようなサイズにはされない。リンクの長さが長くなると、リトライリクエストを受信する前にリプレイバッファから送出され得るＬＴＰの数は増える。何らかのポイントにおいて、リンク長は、リトライリクエストスキーム単独の使用が、リプレイバッファ内の不良ＬＴＰのコピーがその不良ＬＴＰのリトライリクエストを受信する前に上書きされないことを確実にしないものにする。
【0127】
これが、ラウンドトリップマーカの使用が適合する場合である。フローチャート２２００ｃに戻ると、判定ブロック２２４４において、ラウンドトリップマーカを受信することなくＬＴＰの全てのリプレイが完了したかどうかが判定される。図１８ｃに示される構成下では、再度、リプレイバッファ１８０６内に８個のＦＩＦＯスロットが存在するが、リンク長は、５個のＬＴＰが同時に「ワイヤ上」に存在できる程度である。これは、少なくとも１０個のＬＴＰが、ラウンドトリップト中であり得る、且つ／あるいは、受信機において処理中であり得ることを意味する。結果として、リプレイバッファ内のＬＴＰコピーの全てが、ＬＴＰのいずれかに対するリトライリクエストを受信する前に再送信され得る。これは、可能性のある不良ＬＴＰのコピーが上書きされることをもたらす。これは、不良ＬＴＰが再送信されることを妨げ、リプレイバッファの目的を無にする。
【0128】
このシナリオに対処するために、送信機は、判定ブロック２２４４に示されるように、ラウンドトリップマーカを受信する前にリプレイＬＴＰの最後に達したかどうかを検出するためのロジックを含む。要するに、これは、リプレイバッファの深さ（depth）が、ラウンドトリップ継続時間（roundtrip duration）よりも小さいか大きいかを判定する。リプレイＬＴＰの最後に達することは、リプレイポインタが最初のリプレイＬＴＰの開始（ＦＩＦＯスロット）に戻るようラップしたことにより検出される。
【0129】
図１８ｃにおいて、最初のリプレイＬＴＰスロットはスロット４であり、スロット４、５、６、７、０、１、２、及び３内のＬＴＰが順に再送信され、ラウンドトリップマーカ１８２２ａ及び１８２２ｂのペアのうちの最初のラウンドトリップマーカを受信する前に、リプレイＬＴＰポインタは、スロット４に戻っている。これは、ラウンドトリップマーカを受信する前にリプレイＬＴＰの最後に達している例を示しており、ラウンドトリップ継続時間がリプレイバッファの深さよりも大きいことを示す。これは、判定ブロック２２４４の結果をＹＥＳにさせ、ロジックは、ブロック２２４５ａに進み、ブロック２２４５ａにおいて、送信機のヌルカウンタ（Ｎｕｌｌｃｏｕｎｔ）ｎが、整数ｋにリセットされる。ブロック２２４６ａ及び判定ブロック２２４８のＮＯの結果がブロック２２４６ａにループバックすることにより示されるように、次いで、送信機は、ラウンドトリップマーカ又はリトライリクエストが受信されるまで、１以上のヌルＬＴＰを受信機に送信することに進む。加えて、送信されたヌルＬＴＰ毎に、Ｎｕｌｌｃｏｕｎｔ ｎが、１だけインクリメントされる。上述したように、ヌルＬＴＰは高信頼性ＬＴＰではなく、したがって、送信されるＬＴＰのコピーは、リプレイバッファに追加されない。結果として、リトライリクエストをもたらした不良ＬＴＰのコピーが、リトライリクエストを受信する前に上書きされないことが確実になる。
【0130】
判定ブロック２２４８において、ラウンドトリップマーカが受信されたと判定されると、ロジックは、ブロック２２５０に進み、ブロック２２５０において、送信機は、図２３ａの送信機状態機械図２３００におけるＬｉｎｋＴｒａｎｓｆｅｒＡｃｔｉｖｅ．ｎｏｒｍａｌへの戻りにより示されるように、通常転送モードに戻るとともに、リプレイバッファの最後に達すると、リプレイバッファを通じたサイクル毎に、Ｎｕｌｌｃｏｕｎｔ ｎ値を使用して、どれくらいの数のヌルＬＴＰを送信するかを決定する。例えば、Ｎｕｌｌｃｏｕｎｔ ｎが４に達したとする。結果として、リプレイバッファＦＩＦＯスロットがスロット７に達するたびに、送信機は、４つのヌルＬＴＰを送出する。一実施形態下では、リトライリクエスト及びラウンドトリップマーカは、最高優先度を有し、決してプリエンプトされない。したがって、Ｎｕｌｌｃｏｕｎｔ ｎにより定められる数のヌルＬＴＰの送信を用いることは、不良ＬＴＰのコピーが、その不良ＬＴＰのリトライリクエストを受信する前に上書きされないことを確実にする。オプションとして、安全マージンを提供するために、ブロック２２４５ａにおいて、Ｎｕｌｌｃｏｕｎｔ ｎは、値ｋ＞０にリセットされてもよく、ｋ個の追加のヌルＬＴＰが、リプレイバッファを通じた各サイクルの最後で送信されるようになる。Ｎｕｌｌｃｏｕｎｔスキームの固有の利点は、実質的に任意の長さのリンクをサポートするために実装できることである（物理リンクの長さには実用上の制限が存在し、この制限を超える長さを有するリンクの製造及び／又は実装は、可能ではないか、あるいは現実的ではないことを認識されたい）。
【0131】
判定ブロック２２４４に戻って、ラウンドトリップマーカが、最初のＦＩＦＯスロットに達する前に受信された場合、判定ブロック２２４４の結果はＮＯであり、ロジックは、ブロック２２４５ｂに進む。ブロック２２４５ｂにおいて、Ｎｕｌｌｃｏｕｎｔ ｎが整数ｍにリセットされる。ブロック２２４６ｂ及び判定ブロック２２４９のＮＯの結果がブロック２２４６ｂにループバックすることにより示されるように、次いで、送信機は、バッファポインタがラップしてその開始スロットに戻るまで、あるいは、Ｎｕｌｌｃｏｕｎｔ ｎが０に達するまで、ＬＴＰを受信機にリプレイし続けることに進む。ここで、Ｎｕｌｌｃｏｕｎｔカウントダウンが、ｍから始まって、再送信された高信頼性ＬＴＰ毎に１だけデクリメントされる。判定ブロック２２４９のＹＥＳの結果に応じて、ロジックは、このＮｕｌｌｃｏｕｎｔカウントダウンループから抜け出て、ブロック２２５０に進む。Ｎｕｌｌｃｏｕｎｔカウントダウンの使用は、バッファ深さが、ラウンドトリップ継続時間のｍ個のＬＴＰの転送サイクル内である構成のおよそｍ個のＬＴＰの転送サイクルの安全マージンをもたらす。例えば、バッファ深さが３２スロットであり、ラウンドトリップ継続時間が、３０個のＬＴＰの転送サイクルに等しく、ｍ＝５であると仮定する。この場合、ロジックがカウントダウンループから抜け出たときにはｍは３であろう。これは、リプレイバッファがその開始（スロット０）に戻るようラップするたびに、３個の追加のヌルＬＴＰが、スロット０内のＬＴＰを上書きする前に送信される。バッファ深さは３２スロットであるので、上書きされるリプレイバッファスロット間のＬＴＰサイクルの数は、３５である、すなわち、ラウンドトリップ継続時間よりも５大きい。
【0132】
不良レーンの検出に応じて、リンクは、低減された数のアクティブレーンの劣化状態で動作し得る。さらに、リンクが、例えば、４つのアクティブレーンで始まり、第１の不良レーンを検出して第１の不良レーンを除去し、３つのアクティブレーンによるリンクオペレーションをもたらし、第２の不良レーンを検出して第２の不良レーンを除去し、２つのアクティブレーンによるリンクオペレーションをもたらすといったシーケンスで動作し得るように、このリンク劣化状態はカスケードし得る。このカスケードは、第３の不良レーンの検出に続いて、１つの残りの良レーンを介するリンクオペレーションをもたらし得る。リンクは、一方の送信方向では、他方の送信方向とは異なる数のアクティブレーンが使用され得るように、非対称構成においても動作し得ることにも留意されたい。
【0133】
図２６は、一実施形態に従った、３つのアクティブレーンを有するリンクを動作させるためのＸＦＲグループを示している。この例において、３つのＸＦＲグループＧ０、Ｇ１、及びＧ２が存在し、対応するＣＲＣは、ＣＲＣ−Ｇ０、ＣＲＣ−Ｇ１、及びＣＲＣ−Ｇ２である。ＬＴＰシーケンスは、ＸＦＲパターンがレーン変更なく繰り返される１つの状態しか有さないので、同じＸＦＲグループが、同じそれぞれのレーンを介して送信される。結果として、レーン毎ＣＲＣの比較は、レーン単位で行われ得る、あるいは、ＸＦＲグループ単位では、ＬＴＰシーケンス状態が考慮されない。３つのレーンの下では、各レーンについて、１１個の３２ビット転送グループが存在し、これは、１つの標準型検出ＬＴＰ当たり、各レーンを介して３５２ビットが送信されることをもたらす。一実施形態において、３つのアクティブレーンの下で動作する場合、１６ビットのレーン毎ＣＲＣが使用される。
【0134】
図２７は、一実施形態に従った、２つのアクティブレーンを有するリンクを動作させるためのＸＦＲグループを示している。１つのＬＴＰ当たり３３個の３２ビット転送グループが存在するので、ＬＴＰ送信ストリームのためにレーン０及びレーン１の各々を介して転送されるビットの数は、５１２ビットと５４４ビットとで交互に変わる。結果として、ＸＦＲグループ単位のレーン毎ＣＲＣ比較スキームが、２つのＬＴＰシーケンス状態を用いて実施される。加えて、一実施形態において、１６ビットのレーン毎ＣＲＣが使用される。
【0135】
図２８は、一実施形態に従った、１つのアクティブレーンを有するリンクを動作させるためのＸＦＲグループを示している。ＬＴＰデータが送信される１つのレーンしか存在しないので、このレーンが、不良である可能性がある唯一のレーンである。結果として、レーン毎ＣＲＣの比較を実行する必要はない。しかしながら、２以上のレーンを有するリンクが１つのレーン下で動作するよう劣化するレーン劣化シナリオ下では、レーン毎ＣＲＣ計算値が、その１つのレーンに対して依然として計算され得る。なぜならば、これは、常に実行されるようにハードウェアで実装され得るからである。この例において、レーン毎ＣＲＣ計算値は、単に無視される。
【0136】
上述したように、開示した実施形態の下では、リンクは、明示的ＡＣＫを使用することのない高信頼性データ送信をサポートする。ＬＴＰは、リンクを介して伝送されているときに損失され得ないが（ケーブルの切断等の事象がない場合）、エラーを含むことがある。暗示的アクノレッジメントスキームは、送信機から受信機へ、そして再度送信機に戻るラウンドトリップを完了するのに要する時間を少なくとも含む時間期間内に送信機においてリトライリクエストを受信しないことにより実現されることを思い出されたい。リトライリクエストは、送信されたデータとは異なるレーンのセットを介して送信されるので、１つのリトライリクエストは（ＣＲＣチェックにより識別される）エラーを有することがあり、したがって、トスされることがある可能性がある。結果として、受信側リンクインタフェースは、不良ＬＴＰが受信されたことを送信側リンクインタフェースに通知しようと試み得るが、（リトライリクエストにより示される）その通知は、トスされる可能性がある。これが、ＲｅｔｒｙＲｅｑＬＴＰのシーケンシャルペア及び他のヌルＬＴＰのペア（例えば、ＲｅｔｒｙＭｒｋｒ０、ＲｅｔｒｙＭｒｋｒ１）の送信が暗示的ＡＣＫスキームを促進するのに役立つ場合である。
【0137】
まず、これらはヌルＬＴＰであるので、リプレイバッファに記憶されず、したがって、再送信のために利用できない。しかしながら、ヌルＬＴＰのシーケンシャルペアを送信することにより、次の２つのイベントのうちの１つが生じることが確実になる：１）エラーなく少なくとも１つのヌルＬＴＰ又は２つのヌルＬＴＰの受信の成功；又は、２）両ＬＴＰがエラーを有する場合、これがシーケンシャルＬＴＰエラーとして検出され、リンクの再トレーニングをトリガすること。（再）トレーニング中、トレーニングシーケンスは、リンクパートナの送信機−受信機ペアの両方により実行され、したがって、両方向におけるリンクの適切なオペレーションが、リンクをアクティブオペレーションに戻す前に検証される。再トレーニングが完了すると、送信側は、１以上のリトライマーカを送信した後であって、新たなＬＴＰの送信を開始する前に（あるいは、ＬＴＰのリプレイを続ける前に）、受信側からの保証されたリトライリクエストを待つ（途中ヌルＬＴＰを送信しながら）。別の利点は、これらヌルパケットのペアを送信することが、ＬＴＰのうちの少なくとも１つが良ＬＴＰである可能性を増大させることである。
【0138】
図２９は、メモリ２９０８に結合されているプロセッサ２９０６に結合されているファブリックポート２９０４を含むホストファブリックインタフェース２９０２を有する例示的な構成を備えるノード２９００を示している。図１に示されるように、システムノードは、ディスクリート型シングルノードプラットフォーム１０６、仮想プラットフォーム１１０、マルチノードプラットフォーム１１６、及び集積型シングルノードプラットフォーム１２０により示されるもの等であるがこれらには限定されない様々な構成を有することができる。一般に、各ノード構成は、少なくとも１つのプロセッサ、メモリ、及び図２９に示される同様のコンポーネントを有する少なくとも１つのＨＦＩを備える。
【0139】
ファブリックポート２９０４は、図１８ａ〜図１８ｃに示されるものと同様の構成を有する送信ポート１８００及び受信ポート１８０２に加えて、以下で説明する、図２９に示される他の回路及びロジック、並びに、図２９に示されていない他の回路及びロジックを含む。送信ポート１８００は、複数の送信ＶＬバッファに分割された送信バッファ（Ｔｂｕｆ）を含むＴｘリンクファブリックサブレイヤ回路及びロジック２９１０と、Ｔｘリンク転送サブレイヤ回路及びロジック２９１２と、４つの送信機２９１６を含むＴｘ ＰＨＹ回路及びロジック２９１４と、Ｔｘリンク制御ブロック１８０４と、を含む。受信ポート１８０２は、複数の受信ＶＬバッファに分割された受信バッファ（Ｒｂｕｆ）を含むＲｘリンクファブリックサブレイヤ回路及びロジック２９１８と、Ｒｘリンク転送サブレイヤ回路及びロジック２９２０と、４つの受信機２９２４を含むＲｘ ＰＨＹ回路及びロジック２９２２と、Ｒｘリンク制御ブロック１８０５と、を含む。
【0140】
Ｔｘリンクファブリックサブレイヤ回路及びロジック２９１０は、本明細書で説明したリンクファブリックサブレイヤオペレーションの送信側態様を実装するよう構成される。図２９に示される送信バッファ及び送信ＶＬバッファに加えて、これらのオペレーションを円滑にするための図示されていないコンポーネント及びブロックは、イーサネット（登録商標）パケット、インフィニバンドパケット、及びネイティブアーキテクチャパケットのＬ４カプセル化、調停ロジック、及びクレジットマネージャを実行するよう構成されるＬ４カプセル化サブブロックを含むファブリックパケット組み立てブロックを含む。さらに、ＱｏＳオペレーションを円滑にするためのロジックの一部が、リンクファブリックサブレイヤで実装される（これも図示されていない）。
【0141】
Ｔｘリンク転送サブレイヤ回路及びロジック２９１２は、本明細書で説明したリンク転送サブレイヤオペレーションの送信側態様を実装するよう構成される。これらは、リトライロジック、ＬＴＰバンドリングブロック、リプレイバッファ、ＮｘｔＷｒＬＴＰポインタ、及びＮｘｔＴｘＬＴＰポインタを含む、ＬＴＰをまとめるためのコンポーネント及び論理ブロック、Ｔｘ ＰＨＹへのハンドオフのためにＬＴＰストリームを準備するためのコンポーネント及び論理ブロック、及び、ＲｅｔｒｙＲｅｑに応答したＬＴＰのリプレイをサポートするためのコンポーネント及び論理ブロック等の様々なコンポーネント及び論理ブロックを含む（全て図示されていない）。加えて、ＱｏＳ機能及びＴｘリンク制御ブロック１８０４の一部は、Ｔｘリンク転送サブレイヤに対して実装される。
【0142】
Ｔｘ ＰＨＹ回路及びロジック２９１４は、４つの送信機２９１６及びＴｘリンク制御ブロック１８０４の一部を含む単純化された形態で示されている。一般に、送信機２９１６は、リンクのＰＨＹレイヤ構成に応じて、電気的送信機を備えてもよいし、光学的送信機を備えてもよい。ネットワーキング分野の当業者であれば、Ｔｘ ＰＨＹ回路及びロジックは、明瞭さのために図示されていない送信側ＰＨＹレイヤオペレーションを実装するためのさらなる回路及びロジックを含むことが理解されよう。これは、エラーを低減させ伝送特性を向上させるために、高速インターコネクトに関連して実装される様々な機能を円滑にするために使用される、ＰＨＹレイヤ内の様々なサブレイヤを含む。
【0143】
Ｒｘリンクファブリックサブレイヤ回路及びロジック２９１８は、本明細書で説明したリンクファブリックサブレイヤオペレーションの受信側態様を実装するよう構成される。図示される受信バッファ及び受信ＶＬバッファに加えて、これらのオペレーションを円滑にするための図示されていないコンポーネント及びブロックは、Ｌ４パケットカプセル化解除サブブロック、クレジットリターンブロック、及びＱｏＳ受信側ロジックの一部を含むファブリックパケット再組み立てブロックを含む。
【0144】
Ｒｘリンク転送サブレイヤ回路及びロジック２９２０は、本明細書で説明したリンク転送サブレイヤオペレーションの受信側態様を実装するよう構成される。これらは、図１８ａ〜図１８ｃに示され上述したもの等の、ＬＴＰを別々にする（アンバンドルする、バンドル解除する）ためのコンポーネント及び論理ブロック、ＬＴＰ ＣＲＣエラー及びレーン毎ＣＲＣエラーを検出するためのコンポーネント及び論理ブロック、受信機トスモードオペレーション及び関連オペレーションのためのコンポーネント及び論理ブロック、並びに、ＱｏＳオペレーションのためのコンポーネント及び論理ブロック等の様々なコンポーネント及び論理ブロックを含む。
【0145】
Ｒｘ ＰＨＹ回路及びロジック２９２２は、４つの受信機２９２４及びＲｘリンク制御ブロック１８０５の一部を含む単純化された形態で示されている。一般に、受信機２９２４は、リンクのＰＨＹレイヤ構成に応じて、電気的受信機を備えてもよいし、光学的受信機を備えてもよく、送信機２９１６からリンクを介して送信された信号を受信するよう構成される。ネットワーキング分野の当業者であれば、Ｒｘ ＰＨＹ回路及びロジックは、明瞭さのために図示されていない受信側ＰＨＹレイヤオペレーションを実装するためのさらなる回路及びロジックを含むことが理解されよう。これは、エラーを低減させ伝送特性を向上させるために、高速インターコネクトに関連して実装される様々な機能を円滑にするために使用される、ＰＨＹレイヤ内の様々なサブレイヤを含む。
【0146】
ＨＦＩ２９０２は、ＰＣＩｅ（周辺コンポーネント相互接続エクスプレス）インタフェース（Ｉ／Ｆ）２９３０に結合されている送信エンジン２９２６及び受信エンジン２９２８をさらに含む。送信エンジン２９２６は、Ｌ４パケット（例えば、カプセル化されたＴＣＰ／ＩＰパケットを含むイーサネット（登録商標）パケット、インフィニバンドパケット）及び／又はファブリックパケットがバッファされる送信バッファ２９３２を含む。一実施形態において、送信バッファ２９３２用のメモリの全て又は一部は、プログラムド入力／出力（ＰＩＯ）空間とも呼ばれるメモリマップド入力／出力（ＭＭＩＯ）アドレス空間を含む。ＭＭＩＯは、プロセッサ２９０６が、例えば、直接メモリアクセス（ＤＭＡ書き込み）を介して、送信バッファ２９３２への直接書き込みを実行することを可能にする。
【0147】
受信エンジン２９２８は、受信バッファ２９３４及びＤＭＡエンジン２９３６を含む。受信バッファは、ファブリックパケット及び／又はＬ４パケットを含み得る、受信ポート１８０２の出力をバッファするために使用される。ＤＭＡエンジン２９３６は、受信バッファ２９３４から、メモリ２９０８及び／又はプロセッサ２９０６内のメモリキャッシュレベルのうちの１つにパケットデータをコピーするためにＤＭＡ書き込みを実行するよう構成される。例えば、いくつかの実施形態において、パケットヘッダデータは、キャッシュに直接メモリアクセスされるのに対し、パケットペイロードデータは、メモリに直接メモリアクセスされる。
【0148】
プロセッサ２９０６は、複数のプロセッサコア２９４０を有するＣＰＵ２９３８を含む。複数のプロセッサコア２９４０の各々は、集積されたレベル１キャッシュ及びレベル２キャッシュ（Ｌ１／Ｌ２キャッシュ）を含み、コヒーレントインターコネクト２９４２に結合されている。また、コヒーレントインターコネクト２９４２には、メモリ２９０８に結合されているメモリインタフェース２９４４、集積入力／出力ブロック（ＩＩＯ）２９４６、及び最終レベルキャッシュ（ＬＬＣ）２９４８も結合されている。ＩＩＯ２９４６は、プロセッサコア、メモリ、及びキャッシュにより使用されるコヒーレント領域と、ＰＣＩｅルートコンプレックス（ＲＣ）２９５０及び２９５２のペアを含むＩＯコンポーネント及びＩＯインタフェースのために使用される非コヒーレント領域と、の間のインタフェースを提供する。当分野では周知のように、ＰＣＩｅ ＲＣは、ＰＣＩｅインターコネクト階層の最上位に位置し、ＰＣＩｅ ＲＣには、ＰＣＩｅインタフェース２９５４、２９５６、２９５８、及び２９６０により示されるような複数のＰＣＩｅインタフェース及びＰＣＩｅデバイスが結合され得る。図示されるように、ＰＣＩｅインタフェース２９５６は、ＨＦＩ２９０２のＰＣＩｅインタフェース２９３０に結合されている。
【0149】
図２９に示されるようないくつかの実施形態においては、プロセッサ２９１２は、ＳｏＣアーキテクチャを使用する。他の実施形態においては、ＰＣＩｅ関連コンポーネントが、プロセッサに結合されるＩＯチップセット又は同様のものに集積される。さらに他の実施形態においては、プロセッサ２９１２及び１以上のＨＦＩ２９０２が、ＳｏＣ２９６２の破線により示されるもの等のＳｏＣに集積される。
【0150】
図２９にさらに示されるように、ソフトウェアアプリケーション２９６４及びファブリックｖＮＩＣ２９６６は、プロセッサコア２９４０のうちの１以上又はプロセッサ２９０６上で実行されるオペレーティングシステムによりホストされる１以上の仮想マシン上で実行されるソフトウェアコンポーネントを含む。このようなソフトウェアコンポーネントに加えて、メモリ２９０８（適用可能なキャッシュレベルを含む）と送信エンジン２９２６と受信エンジン２９３４との間のデータ転送を円滑にするための、メモリ２９０８内に実装されるさらなるバッファ及びソフトウェアコンポーネントが存在する。
【0151】
一般に、図示される回路、ロジック、及びコンポーネントは、ディスクリート型チップ、ＳｏＣ、マルチチップモジュール、及び、複数のネットワークインタフェースのためのサポートを含むネットワーキング／リンクインタフェースチップを含む様々なタイプの集積回路（例えば、半導体チップ）及びモジュールにより実装されてもよい。また、本明細書で使用されている、様々なオペレーションを実行するための回路及びロジックは、組み込みロジック、組み込みプロセッサ、コントローラ、マイクロエンジンのうちの１以上を用いて、あるいは、ハードウェア、ソフトウェア、及び／又はファームウェアの任意の組合せを用いて実装されてもよい。例えば、様々な論理ブロック及び／又は回路により表されるオペレーションは、ＡＳＩＣ、ＦＰＧＡ、ＩＰブロックライブラリを含むがこれらに限定されるものではないプログラムされた論理ゲート及び同様のものを用いて、あるいは、プロセッサ、プロセッサコア、コントローラ、マイクロコントローラ、マイクロエンジン等を含む１以上の処理要素上で実行されるソフトウェア命令又はファームウェア命令のうちの１以上を介して実行されてもよい。
【0152】
加えて、本記載の実施形態の態様は、半導体チップ、ＳｏＣ、マルチチップモジュール等において実装されるだけでなく、非一時的なマシン読み取り可能な媒体において実装されてもよい。例えば、上述した設計は、半導体デバイスを設計するために使用される設計ツールに関連付けられた非一時的なマシン読み取り可能な媒体に記憶されてもよいし、且つ／あるいは、そのようなマシン読み取り可能な媒体に組み込まれてもよい。例は、ＶＨＳＩＣハードウェア記述言語（ＶＨＤＬ）言語、Ｖｅｒｉｌｏｇ言語若しくはＳＰＩＣＥ言語、又は他のハードウェア記述言語でフォーマット化されたネットリストを含む。いくつかのネットリスト例は、挙動レベルネットリスト、レジスタ転送レベル（ＲＴＬ）ネットリスト、ゲートレベルネットリスト、及びトランジスタレベルネットリストを含む。マシン読み取り可能な媒体はまた、ＧＤＳ−ＩＩファイル等のレイアウト情報を有する媒体を含む。
【0153】
さらに、半導体チップ設計のためのネットリストファイル又は他のマシン読み取り可能な媒体は、上述した教示の方法を実行するために、シミュレーション環境において使用され得る。
【0154】
特定の実装例を参照していくつかの実施形態について説明したが、他の実装例も、いくつかの実施形態に従って可能である。さらに、図示及び／又は説明した要素又は他の特徴の配置及び／又は順序は、図示及び説明した特定の形で構成される必要はない。多くの他の構成も、いくつかの実施形態に従って可能である。
【0155】
図示した各システムにおいて、いくつかの場合における要素は、表された要素が、異なっていることもあるし、且つ／あるいは、類似していることもあることを示すために、それぞれ異なる参照符号を有することもあるし、同じ参照符号を有することもある。しかしながら、要素は、異なる実装を有するのに十分柔軟であり得、図示又は説明したシステムの一部又は全てとともに機能する。図示した様々な要素は、同じであることもあるし、異なることもある。どれが第１の要素と呼ばれ、どれが第２の要素と呼ばれるかは任意である。
【0156】
前述の詳細な説明及び特許請求の範囲における「ｎ（斜体）」、「ｍ（斜体）」、「ｋ（斜体）」等のイタリック文字は、整数を表すために使用され、特定の文字の使用は、特定の実施形態に限定されるものではない。さらに、別の整数を表すために、同じ文字が、別の請求項において使用されることもあるし、異なる文字が使用されることもある。加えて、詳細な説明における特定の文字の使用は、詳細な説明における同じ主題に関連する請求項において使用される文字と一致することもあるし一致しないこともある。
【0157】
詳細な説明及び特許請求の範囲において、「結合されている」及び「接続されている」という用語、並びにそれらの派生語が、使用されているかもしれない。これらの用語は、互いの同義語として意図されるものではないことを理解すべきである。そうではなく、特定の実施形態において、「接続されている」は、２以上の要素が、互いに直接的に物理的に接触している、あるいは互いに直接的に電気的に接触していることを示すために使用され得る。「結合されている」は、２以上の要素が、直接的に物理的に接触している、あるいは直接的に電気的に接触していることを意味し得る。しかしながら、「結合されている」はまた、２以上の要素が、互いに直接的に接触してはいないが、それでも互いと協働している、あるいは互いとインタラクトしていることも意味し得る。
【0158】
一本発明のうちの一実装例又は一例である。本明細書における「ある実施形態」、「一実施形態」、「いくつかの実施形態」、又は「他の実施形態」との言及は、その実施形態に関連して説明される特定の特徴、構造、又は特性が、少なくともいくつかの実施形態に含まれることを意味するものであり、必ずしも本発明の全ての実施形態に含まれるとは限らない。本明細書の様々な箇所における「ある実施形態」、「一実施形態」、又は「いくつかの実施形態」の出現は、必ずしも全て同じ実施形態を指しているとは限らない。
【0159】
説明及び図示した全てのコンポーネント、特徴、構造、特性等が、特定の１以上の実施形態に含まれる必要はない。本明細書が、コンポーネント、特徴、構造、又は特性が含まれてもよいと記載している場合、例えば、その特定のコンポーネント、特徴、構造、又は特性が含まれる必要はない。本明細書又は特許請求の範囲が、「ａ」又は「ａｎ」の要素に言及している場合、これは、１つのみの要素が存在することを意味するものではない。本明細書又は特許請求の範囲が、「さらなる」要素に言及している場合、これは、２以上のさらなる要素が存在することを排除するものではない。
【0160】
要約書に記載しているものを含め、本発明の例示的な実施形態の説明は、網羅的であることを意図するものでもないし、開示した正確な形態に本発明を限定することを意図するものでもない。本発明の特定の実施形態及び例が、例示の目的のために、本明細書で説明されているが、当業者は、本発明の範囲内で様々な均等の変更形態も可能であることを認識されよう。
【0161】
詳細な説明に鑑みて、そのような変更形態が、本発明に対して可能である。特許請求の範囲において使用される用語は、本明細書及び図面で開示した特定の実施形態に本発明を限定するよう解釈されるべきでない。そうではなく、本発明の範囲は、特許請求の範囲により完全に定められるべきであり、特許請求の範囲は、特許請求の範囲の解釈の確立された原則に従って解釈されるべきである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9a】
【図9b】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18a】
【図18b】
【図18c】
【図19】
【図20】
【図21】
【図22a】
【図22b】
【図22c】
【図22d】
【図22e】
【図23a】
【図23b】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【手続補正書】
【提出日】2016年4月25日
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
リンクインタフェースであって、
複数のファブリックパケットを生成し、
各ファブリックパケットを複数のデータユニットに分割し、
前記データユニットをまとめて、複数のリンクパケットを形成する、
ための回路及びロジック
を含むリンクインタフェース
を備え、
前記複数のリンクパケットのうちの少なくとも１つは、少なくとも２つのファブリックパケットからのデータユニットを含む、装置。
【請求項2】
前記複数のデータユニットのうちの１以上のデータユニットは、固定サイズを有するフリットを含む、請求項１記載の装置。
【請求項3】
前記複数のリンクパケットの１以上のデータユニットは、予め定められた数のフリットを含む固定サイズを有する、請求項２記載の装置。
【請求項4】
前記ファブリックパケットのうちの少なくとも１つは、可変サイズを有する、請求項３記載の装置。
【請求項5】
前記複数のファブリックパケットのうちの少なくとも１つは、前記予め定められた数のフリットよりも少ない第１の数のフリットを含み、前記複数のファブリックパケットのうちの少なくとも１つは、前記予め定められた数のフリットよりも多い第２の数のフリットを含む、請求項３記載の装置。
【請求項6】
前記リンクインタフェースは、前記複数のリンクパケットのうちの少なくとも１つのリンクパケットに含まれるデータに対するデータインテグリティチェック値を計算して、前記データインテグリティチェック値を前記少なくとも１つのリンクパケットに含めるための回路及びロジックをさらに含む、請求項１記載の装置。
【請求項7】
前記複数のファブリックパケットのうちの少なくとも１つは、ヘッドフリットを含む最初のデータユニットと、前記最初のデータユニットに続く複数のボディフリットと、最後にテールフリットを含む最後のデータユニットと、を含む複数の異なるタイプのデータユニットに分割される、請求項１記載の装置。
【請求項8】
リンクパケット内の前記データユニットのうちの少なくとも１つは、フリットタイプビットを含む、請求項７記載の装置。
【請求項9】
リンクパケット内のいずれかの場所に、前記複数の異なるタイプのデータユニットのうちのいずれかを配置することができる、請求項７記載の装置。
【請求項10】
前記複数のリンクパケットのうちの１つは、アイドルデータユニットを含む少なくとも１つのタイプのデータユニットを含む、請求項１記載の装置。
【請求項11】
前記複数のリンクパケットのうちの１つは、制御データユニットを含む少なくとも１つのタイプのデータユニットを含み、
前記リンクインタフェースは、
受信されたリンクパケット内の制御データユニットを検出し、
前記制御データユニットにより特定される制御オペレーションを実行する、
ためのさらなる回路及びロジックを含む、請求項１０記載の装置。
【請求項12】
前記装置は、送信ポートを含み、前記送信ポートから送信される前記複数のリンクパケットは、第１の複数のパケットを含み、
前記リンクインタフェースは、
第２の複数のファブリックパケットから分割されたデータを含むデータユニットを含む第２の複数のリンクパケットを受信し、
前記第２の複数のリンクパケットからデータユニットを抽出し、
該データユニットを再組み立てして、前記第２の複数のファブリックパケットを再生成する、
ための回路及びロジックを含み、
前記第２の複数のリンクパケットのうちの少なくとも１つは、少なくとも２つのファブリックパケットからのデータユニットを含む、請求項１記載の装置。
【請求項13】
各リンクパケットは、送信されたとき、該リンクパケットに含まれるデータに対して計算された送信側データインテグリティチェック値を含み、
前記リンクインタフェースは、
各リンクパケット内の受信されたデータに対する受信側データインテグリティチェック値を計算し、
前記受信側データインテグリティチェック値を前記送信側データインテグリティチェック値と比較して、該リンクパケットがエラーを有するかどうかを検出し、
該リンクパケットがエラーを有する場合、該リンクパケットの送信元のリンクピアに再送信リクエストを送信する、
ためのさらなる回路及びロジックを含む、請求項１記載の装置。
【請求項14】
前記リンクインタフェースは、
リンクピアから再送信リクエストを受信したことに応答して、
該再送信リクエストがなされたリンクパケットを特定し、
該リンクパケットを再送信する、
ためのさらなる回路及びロジックを含む、請求項１３記載の装置。
【請求項15】
前記リンクインタフェースの前記回路及びロジックは、さらに、前記複数のリンクパケットを、リンクを介して受信機に向けて送信する、請求項１記載の装置。
【請求項16】
前記リンクインタフェースは、送信ポート及び受信ポートをさらに含む、請求項１記載の装置。
【請求項17】
前記装置は、メモリ及び少なくとも１つのプロセッサコアをさらに備える、請求項１記載の装置。
【請求項18】
前記リンクインタフェース、前記少なくとも１つのプロセッサコア、及び前記メモリは、同じチップパッケージ内に配置されている、請求項１７記載の装置。
【請求項19】
前記リンクインタフェース、前記少なくとも１つのプロセッサコア、及び前記メモリは、同じ集積チップ上に集積されている、請求項１７記載の装置。
【請求項20】
複数の第１のタイプのパケットを生成するステップと、
前記複数の第１のタイプのパケットを複数のデータユニットに分割するステップと、
受信機に向けた送信のために、前記データユニットを複数の第２のタイプのパケットにまとめるステップと、
を含み、
前記複数の第２のタイプのパケットのうちの少なくとも１つは、少なくとも２つの第１のタイプのパケットからのデータユニットを含む、方法。
【請求項21】
前記複数のデータユニットのうちの１以上のデータユニットは、固定サイズを有する、請求項２０記載の方法。
【請求項22】
前記複数の第２のタイプのパケットのうちの１以上の第２のタイプのパケットは、予め定められた数のデータユニットを含む、請求項２１記載の方法。
【請求項23】
前記複数の第１のタイプのパケットのうちの少なくとも１つは、前記予め定められた数のデータユニットよりも少ない第１の数のデータユニットを含み、前記複数の第１のタイプのパケットのうちの少なくとも１つは、前記予め定められた数のデータユニットよりも多い第２の数のデータユニットを含む、請求項２２記載の方法。
【請求項24】
前記方法は、複数のリンクを含むファブリックにおいて第１のリンクを介してファブリックスイッチの受信ポートに結合されている第１のファブリックエンドポイントの送信ポートにより実行され、少なくとも１つの第１のタイプのパケットは、前記第１のリンクを含む複数のリンクを含む転送パスを介して、第２のファブリックエンドポイントに送信され、前記第２のタイプのパケットは、前記第１のリンクを介して、前記受信ポートに送信され、さらに転送されることはない、請求項２０記載の方法。
【請求項25】
前記複数の第２のタイプのパケットのうちの１以上の第２のタイプのパケットは、前記受信機により受信された第２のタイプのパケット内のデータがエラーを有さないことを確認するために使用されるデータインテグリティチェック値を含み、前記複数の第２のタイプのパケットのうちの１以上の第２のタイプのパケットは、前記第２のタイプのパケットの元の送信においてエラーが検出されたときに再送信される再送信ユニットを含む、請求項２０記載の方法。
【請求項26】
前記複数の第１のタイプのパケットのうちの１以上は、ヘッドデータユニットを含む最初のデータユニットと、前記最初のデータユニットに続く複数のボディデータユニットと、最後にテールデータユニットを含む最後のデータユニットと、を含む複数の異なるタイプのデータユニットに分割される、請求項２０記載の方法。
【請求項27】
第２のタイプのパケット内のいずれかの場所に、前記複数の異なるタイプのデータユニットのうちのいずれかを配置することができる、請求項２６記載の方法。
【請求項28】
前記第２のタイプのパケットのうちの１つは、制御データユニットを含む少なくとも１つのタイプのデータユニットを含む、請求項２０記載の方法。
【請求項29】
第２の複数のファブリックパケットから分割されたデータを含むデータユニットを含む第２の複数のリンクパケットを受信するステップと、
前記第２の複数のリンクパケットからデータユニットを抽出するステップと、
該データユニットを再組み立てして、前記第２の複数のファブリックパケットを再生成するステップと、
をさらに含み、
前記第２の複数のリンクパケットのうちの少なくとも１つは、少なくとも２つのファブリックパケットからのデータユニットを含む、請求項２０記載の方法。
【請求項30】
前記方法は、前記複数の第２のタイプのパケットを、リンクを介して前記受信機に向けて送信するステップをさらに含む、請求項２０記載の方法。
【請求項31】
第１のコンポーネント及び第２のコンポーネントを備えたシステムであって、前記第１のコンポーネント及び前記第２のコンポーネントは、リンクに結合されるよう構成されているリンクインタフェースであって、他方のリンクインタフェースとのリンクピアとして動作するよう構成されているリンクインタフェースを含み、前記第１のコンポーネント及び前記第２のコンポーネントの各リンクインタフェースは、
第１の複数のファブリックパケットを生成し、
前記第１の複数のファブリックパケットのうちの１以上を複数のフリットに分割し、
各リンクインタフェースのリンクピアのリンクインタフェースに向けた前記リンクを介する送信のために、前記フリットを第１の複数のリンクパケットにまとめ、
各リンクインタフェースのリンクピアから前記リンクを介して送信された第２の複数のリンクパケットを受信し、ここで、前記第２の複数のリンクパケットは、第２の複数のファブリックパケットから分割されたフリットを含み、
前記第２の複数のリンクパケットからフリットを抽出し、
該フリットを再組み立てして、前記第２の複数のファブリックパケットを再生成する、
よう構成されており、
前記第１の複数のリンクパケット及び前記第２の複数のリンクパケットの少なくとも一部は、少なくとも２つのファブリックパケットからのフリットを含む、システム。
【請求項32】
前記複数のフリットのうちの１以上のフリットは、固定サイズを有し、前記リンクパケットのうちの１以上のリンクパケットの各々は、固定数のフリットを有し、前記第１の複数のファブリックパケット及び前記第２の複数のファブリックパケットのサイズは変わる、請求項３１記載のシステム。
【請求項33】
前記第１のコンポーネント及び前記第２のコンポーネントの各リンクインタフェースは、
送信される少なくとも１つのリンクパケットに含まれるデータに対する送信側データインテグリティチェック値を計算して、前記送信側データインテグリティチェック値を前記少なくとも１つのリンクパケットに含めるための回路及びロジックを有する送信ポートと、
受信された少なくとも１つのリンクパケット内の受信されたデータに対する受信側データインテグリティチェック値を計算し、前記受信側データインテグリティチェック値を前記送信側データインテグリティチェック値と比較して、前記少なくとも１つのリンクパケットがエラーを有するかどうかを検出するための回路及びロジックを有する受信ポートと、
を含む、請求項３１記載のシステム。
【請求項34】
前記第１のコンポーネント及び前記第２のコンポーネントのうちの少なくとも１つは、リンクインタフェースを含むホストファブリックインタフェースであって、
送信される前記複数のファブリックパケットのうちの少なくとも１つのファブリックパケットに含まれるデータに対する送信側巡回冗長チェックサム（ＣＲＣ）を計算し、
前記の再生成された複数のファブリックパケットのうちの少なくとも１つの再生成されたファブリックパケットに含まれるデータに対する受信側ＣＲＣを計算し、
前記送信側ＣＲＣと前記受信側ＣＲＣとを比較して、前記少なくとも１つの再生成されたファブリックパケットがエラーを含むかどうかを判定する、
ための回路及びロジックをさらに含むホストファブリックインタフェースを含む、請求項３１記載のシステム。
【請求項35】
前記第１のコンポーネント及び前記第２のコンポーネントのうちの少なくとも１つは、リンクインタフェースが集積されているホストインタフェースチップを含み、
前記ホストインタフェースチップは、
少なくとも１つの送信バッファを含む、前記リンクインタフェースの前記送信ポートに結合されている送信エンジンと、
少なくとも１つの受信バッファを含む、前記リンクインタフェースの前記受信ポートに結合されている受信エンジンと、
前記送信エンジン及び前記受信エンジンの各々に結合されている周辺コンポーネント相互接続エクスプレス（ＰＣＩｅ）インタフェースと、
を含む、請求項３３記載のシステム。
【請求項36】
前記第１のコンポーネント及び前記第２のコンポーネントのうちの少なくとも１つは、
システムオンチップ（ＳｏＣ）であって、
リンクインタフェースが集積されているホストファブリックインタフェースであって、
少なくとも１つの送信バッファを含む、前記リンクインタフェースの前記送信ポートに結合されている送信エンジンと、
少なくとも１つの受信バッファを含む、前記リンクインタフェースの前記受信ポートに結合されている受信エンジンと、
前記送信エンジン及び前記受信エンジンの各々に結合されている周辺コンポーネント相互接続エクスプレス（ＰＣＩｅ）インタフェースと、
を含むホストファブリックインタフェース
を含むＳｏＣと、
前記ホストファブリックインタフェースの前記ＰＣＩｅインタフェースに結合されているＰＣＩｅインタフェースを含むプロセッサと、
を含む、請求項３３記載のシステム。
【請求項37】
リンクインタフェースを含む装置内のプロセッサ及び組み込みロジックのうちの少なくとも１つの上で実行されたときに、前記装置に、
複数のファブリックパケットを生成させ、
各ファブリックパケットを複数のデータユニットに分割させ、
前記データユニットをまとめさせて、複数のリンクパケットを形成させる、
プログラムであって、
前記複数のリンクパケットのうちの少なくとも１つは、少なくとも２つのファブリックパケットからのデータユニットを含む、プログラム。
【請求項38】
前記複数のデータユニットのうちの１以上のデータユニットは、固定サイズを有するフリットを含む、請求項３７記載のプログラム。
【請求項39】
前記複数のリンクパケットの１以上のデータユニットは、予め定められた数のフリットを含む固定サイズを有する、請求項３８記載のプログラム。
【請求項40】
前記ファブリックパケットのうちの少なくとも１つは、可変サイズを有する、請求項３９記載のプログラム。
【請求項41】
前記複数のファブリックパケットのうちの少なくとも１つは、前記予め定められた数のフリットよりも少ない第１の数のフリットを含み、前記複数のファブリックパケットのうちの少なくとも１つは、前記予め定められた数のフリットよりも多い第２の数のフリットを含む、請求項３９記載のプログラム。
【請求項42】
前記プログラムは、前記装置に、さらに、前記複数のリンクパケットのうちの少なくとも１つのリンクパケットに含まれるデータに対するデータインテグリティチェック値を計算させて、前記データインテグリティチェック値を前記少なくとも１つのリンクパケットに含めさせる、請求項３７記載のプログラム。
【請求項43】
前記複数のファブリックパケットのうちの少なくとも１つは、ヘッドフリットを含む最初のデータユニットと、前記最初のデータユニットに続く複数のボディフリットと、最後にテールフリットを含む最後のデータユニットと、を含む複数の異なるタイプのデータユニットに分割される、請求項３７記載のプログラム。
【請求項44】
リンクパケット内の前記データユニットのうちの少なくとも１つは、フリットタイプビットを含む、請求項４３記載のプログラム。
【請求項45】
リンクパケット内のいずれかの場所に、前記複数の異なるタイプのデータユニットのうちのいずれかを配置することができる、請求項４３記載のプログラム。
【請求項46】
前記複数のリンクパケットのうちの１つは、アイドルデータユニットを含む少なくとも１つのタイプのデータユニットを含む、請求項３７記載のプログラム。
【請求項47】
前記複数のリンクパケットのうちの１つは、制御データユニットを含む少なくとも１つのタイプのデータユニットを含み、
前記プログラムは、前記装置に、さらに、
受信されたリンクパケット内の制御データユニットを検出させ、
前記制御データユニットにより特定される制御オペレーションを実行させる、請求項４６記載のプログラム。
【請求項48】
前記装置は、送信ポートを含み、前記送信ポートから送信される複数のリンクパケットは、第１の複数のパケットを含み、
前記プログラムは、前記装置に、さらに、
第２の複数のファブリックパケットから分割されたデータを含むデータユニットを含む第２の複数のリンクパケットを受信させ、
前記第２の複数のリンクパケットからデータユニットを抽出させ、
該データユニットを再組み立てさせて、前記第２の複数のファブリックパケットを再生成させ、
前記第２の複数のリンクパケットのうちの少なくとも１つは、少なくとも２つのファブリックパケットからのデータユニットを含む、請求項３７記載のプログラム。
【請求項49】
各リンクパケットは、送信されたとき、該リンクパケットに含まれるデータに対して計算された送信側データインテグリティチェック値を含み、
前記プログラムは、前記装置に、さらに、
各リンクパケット内の受信されたデータに対する受信側データインテグリティチェック値を計算させ、
前記受信側データインテグリティチェック値を前記送信側データインテグリティチェック値と比較させて、該リンクパケットがエラーを有するかどうかを検出させ、
該リンクパケットがエラーを有する場合、該リンクパケットの送信元のリンクピアに再送信リクエストを送信させる、請求項３７記載のプログラム。
【請求項50】
前記プログラムは、前記装置に、さらに、
リンクピアから再送信リクエストを受信したことに応答して、
該再送信リクエストがなされたリンクパケットを特定させ、
該リンクパケットを再送信させる、請求項４９記載のプログラム。
【請求項51】
請求項３７乃至５０いずれか一項記載のプログラムを記憶したマシン読み取り可能な記憶媒体。
【国際調査報告】

［広告欄］

ログインすれば広告は減ります

ログインすれば広告は減ります

Copyright © Science Impact Inc. All Rights Reserved.