JP5805879B2

JP5805879B2 - 拡張ヘッダを用いたパケット送信

Info

Publication number: JP5805879B2
Application number: JP2014531974A
Authority: JP
Inventors: ラクシュマナムルティ，シュリハール; シー．ハンセイカー，ミカル; ティー．クリングルスミス，マイケル; ファニング，ブレイズ; アール．ヴァーマ，ロヒート; ピー．アドラー，ロバート
Original assignee: インテルコーポレイション
Priority date: 2011-09-29
Filing date: 2012-09-20
Publication date: 2015-11-10
Anticipated expiration: 2032-09-20
Also published as: CN103843294A; CN103843294B; US20150092779A1; EP2761831A1; EP2966810A1; CN104536940A; US20130083798A1; EP2761831A4; JP2015109679A; CN104536940B; JP2014526859A; US10164880B2; JP5922268B2; EP2761831B1; US8929373B2; WO2013048882A1

Description

本願は、拡張ヘッダを用いたパケット送信に関する。

高い性能及び低消費電力のセグメントの両方において、プロセッサチップの主流は、グラフィックス、ディスプレイエンジン、セキュリティエンジン、ＰＣＩｅ（商標）ポート（すなわち、（２００２年公開の）周辺機器相互接続（PCI）のローカルバス仕様、バージョン３．０（これ以降、PCI仕様と呼ぶ）等のPCI仕様に準拠したデバイス用の従来のサポートを維持したまま、（２００７年公開の）周辺機器相互接続エクスプレス（PCI Express^TM（PCIe^TM））仕様書ベースの仕様バージョン２．０（これ以降、PCIe^TM仕様と呼ぶ）及びその他のPCIe^TMベースの周辺機器に従ったポート）等の追加の機能をますます統合するようになっている。

このような設計は、サーバ、デスクトップ、モバイル、組込み式のウルトラモバイル及びモバイルインターネット装置セグメントからの様々な要件によってセグメント化される。様々な市場は、プロセッサコア、メモリコントローラ、入力／出力コントローラ、及び他の特定の加速セグメント要素のうちの少なくともいくつかを単一チップ上の組み合わせるような単一チップのシステムオンチップ（ＳｏＣ）を用いた解決策を求めてきた。しかしながら、これらの機能を蓄積するような設計は、様々なＩＰ（知的財産）ブロックを単一のダイ上に統合することの困難性に直面して停滞していた。これは、ＩＰブロックが様々な要件及び設計の独自性を有しており、多くの特殊なワイヤーや、通信プロトコルを必要とするとき、それらをＳｏＣ内に組込み可能にするときにとりわけ停滞していた。結果として、各ＳｏＣ又は開発される他の最新の半導体デバイスは、様々なＩＰブロックを単一のデバイスに組み込むために、膨大な量の設計の複雑さ及びカスタマイズを必要とする。所与のＩＰブロックは、典型的には、所与のＳｏＣのインターフェイス及びシグナリング要件に適応するように再設計する必要があるときに、とりわけ停滞していた。

システムを介したパケットのルーティングを可能にするために、典型的には、情報を含むヘッダが、パケットに設けられており、パケットのルーティング及びデコードを支援する。様々な通信プロトコルが、様々なヘッダ配列のために提供される。しかしながら、これらのヘッダフォーマットは、典型的には固定されており、ヘッダを用いて追加情報を提供するような柔軟性を阻止している。様々なエージェントが複数の通信プロトコルを用いて通信するようなプロトコルをトンネリングする際に、元のパケットを、プロトコルをトンネリングさせるために、追加のヘッダを含むパケットタイプ内でカプセル化することができる。次に、各エージェントは、包含されるパケットヘッダにアクセスできる。しかしながら、この技術は、パケットサイズ及びデコードの複雑性を増大させる。

本発明の実施形態による基本的な相互接続アーキテクチャのブロック図である。本発明の実施形態による相互接続アーキテクチャのさらに詳細なブロック図である。本発明の実施形態によるＳｏＣの高レベルのブロック図である。本発明の別の実施形態によるシステムのブロック図である。本発明の実施形態によるサイドバンド相互接続のブロック図である。本発明の実施形態によるサイドバンド・インターフェイス用の使用可能なシグナリングの詳細なブロック図である。本発明の実施形態によるヘッダ部及びデータ部を有するメッセージを示す図である。本発明の実施形態によるパケットを生成する方法のフロー図である。本発明の実施形態による拡張ヘッダを有するパケットをルータで処理する方法のフロー図である。本発明の実施形態による拡張ヘッダを含むパケットを標的エージェントで処理する方法のフロー図である。本発明の実施形態によるＳｏＣの一部のより詳細なブロック図である。本発明の実施形態による別のＳｏＣのブロック図である。

エージェントと呼ばれる様々なコンポーネントを接続するサイドバンド・インターフェイスは、ルーティングファブリックがこの情報に不確か性(agnostic)を完全に留めており、且つ特定の標的エージェントのみがこのような拡張ヘッダを理解することができるように、サイドバンド・メッセージ内の追加のヘッダ情報を送信する能力を有するように構成してもよい。所与のメッセージについて拡張ヘッダを送信する機能を追加することによって、インターフェイス仕様の標準ヘッダ、例えば１ダブルワード（ＤＷ）の任意の長さの拡張を実現することができる。同時に、ルータ、スイッチ、又は他のインターフェイス部品は、（例えばヘッダの第１のＤＷを検査することにより、）標準ヘッダに基づいて、入力メッセージを処理することができる。また、実施形態は、簡素化したパケットレイアウト及びデコードスキームを提供することによって、受信エージェントが、拡張ヘッダが受信エージェントによってこのエージェント内のメッセージストリームとしてサポートされていない（例えば拡張ヘッダを気にせず処理する）場合に、拡張ヘッダを破棄する又はストリップする。

本発明の実施形態による拡張ヘッダの仕組みを提供することにより、このような情報をサポートしない受信エージェントは、受信メッセージのその情報を無視することができる。これによって、マスター及び標的エージェントにおける設計の複雑さを低減することが可能になる。例として、セキュリティ属性情報（ＳＡＩ）を拡張ヘッダで送信する場合を考える。マスターエージェントは、全てのトランザクションでＳＡＩを常に送信する構成を実現することができる。ＳＡＩの送信をハードコード化することができ、構成可能なＳＡＩヘッダの挿入によるセキュリティ上の脆弱性を回避することができるので、このようなマスターエージェントはより安全になる。ＳＡＩ拡張ヘッダを有するトランザクションが、アクセス制御ポリシーを実施するように構成された標的エージェントを宛先とした場合には、標的エージェントは、そのヘッダ内のＳＡＩ情報を使用することができる。代わりに、トランザクションがアクセス制御保護のために構成されたリソースを有さない標的エージェントを宛先とした場合には、そのエージェントは、拡張ヘッダを無視して、標準メッセージヘッダ及び対応するメッセージペイロードを処理することができる。

実施形態は、多くの様々なタイプのシステムで用いることができる。例として、本明細書で説明される実装形態では、単一の半導体ダイ上に製造されるようなプロセッサ等の半導体デバイス又は他の半導体デバイスに関して用いることができる。特定の実施形態では、デバイスは、システムオンチップ（ＳｏＣ）又は種々の同種及び／又は異種の処理エージェントを含む他の最新のプロセッサ又はチップセット、及び例えば、ルータ、コントローラ、ブリッジデバイス、デバイス、メモリ等のネットワークコンポーネントのような追加のコンポーネントであってもよい。

いくつかの実装形態は、ＳｏＣを含むチップ内に知的財産（ＩＰ）ブロックを取り付けるための標準化されたオンチップ相互接続プロトコルを提供するために、半導体製造業者によって発行された、集積化オンチップシステム・ファブリック（ＩＯＳＦ）仕様として所与の仕様に従って設計された半導体デバイスとして用いることができる。このようなＩＰブロックは、他の多くのプロセッサの中でインオーダー（順次の）又はアウトオブオーダー（非順次の）コア、固定機能ユニット、グラフィックプロセッサ、ＩＯコントローラ、ディスプレイコントローラ、メディアプロセッサ等の汎用プロセッサを含む様々なタイプのものであり得る。相互接続プロトコルを標準化することにより、フレームワークは、こうして、様々なタイプのチップにおいてＩＰエージェントの広範な使用のために実現される。従って、多様な顧客セグメントに亘って又仕様を経由して、様々なタイプのチップを効率的に設計する半導体メーカーだけでなく、第三者が、ＩＰエージェント等のロジックをこのようなチップに組込むことを可能にする。さらに、相互接続プロトコルの多くのファセット用の複数のオプションを提供することによって、再設計が効率的に提供される。実施形態は、このＩＯＳＦ仕様に関連して本明細書に説明されるが、本発明の範囲はこの点に限定されるものではなく、実施形態は、多くの様々なタイプのシステムで用いることができることを理解されたい。

ここで図１を参照すると、本発明の実施形態による基本的な相互接続アーキテクチャのブロック図が示されている。図１に示されるように、システム１０は、システムオンチップ又は高集積プロセッサ複合体又は統合されたＩＯハブ等の他の半導体装置の一部であってもよく、様々なコンポーネント間の相互接続として機能するファブリック２０を含むことができる。示された実施形態では、これらのコンポーネントは、計算機能、グラフィックス機能、メディア処理能力等の種々の機能を提供するための独立したＩＰブロックとすることができるようなＩＰエージェント３０及び４０を含む。これらのＩＰエージェントは、一実施形態では、ＩＯＳＦ仕様に準拠したインターフェイスを有するＩＰブロック又論理デバイスである。さらに確認されるように、ファブリック２０は、ブリッジ５０にもインターフェイス接続する。図１の実施形態では説明を簡易にするために図示されていないが、ブリッジ５０は、例えば同じチップ上又は１つ以上の異なるチップ上で他のシステムコンポーネントへのインターフェイスとして機能し得ることを理解されたい。

さらに後述するように、図１に示される要素の各々、すなわちファブリック、ＩＰエージェント、及びブリッジは、各種信号の通信を処理するための１つ以上のインターフェイスを含んでもよい。これらのインターフェイスは、エージェント間での情報交換に用いるこれらのインターフェイス、プロトコルの通信の信号を規定するようなＩＯＳＦ仕様や、情報交換、サポートされたアドレスのデコード化及び変換機能、インバンド又はアウトオブバンド通信用のメッセージング、電源管理、テスト、検証、及びデバッグサポートを開始し、管理するために使用される調停及びフロー制御機構、に従って規定される。

ＩＯＳＦ仕様は、各エージェントに提供される３つの独立したインターフェイス、すなわちプライマリ・インターフェイス、サイドバンド・メッセージインターフェイス、可試験性及びデバッグ用インターフェイス（テスト用に設計された（ＤＦＴ）、デバッグ用に設計された（ＤＦＤ）インターフェイス）が含まれる。ＩＯＳＦ仕様に従って、エージェントは、これらのインターフェイスの任意の組合せをサポートすることができる。具体的には、エージェントは、０〜Ｎのプライマリ・インターフェイス、０〜Ｎのサイドバンド・メッセージインターフェイス、及び随意のＤＦｘインターフェイスをサポートすることができる。しかしながら、この仕様によれば、エージェントは、これらの３つのインターフェイスのうちの少なくとも１つをサポートしなければならない。

ファブリック２０は、異なるエージェント間でデータを移動させるようなハードウェア要素であってもよい。ファブリック２０のトポロジ（接続形態）は、製品に固有なものであることに留意されたい。例として、ファブリックは、バス、階層バス、カスケード接続されたハブ等として実施することができる。ここで図２を参照すると、本発明の実施形態による相互接続アーキテクチャのさらに詳細なブロック図が示されている。図２に示されるように、ＩＯＳＦ仕様は、３つの異なるファブリック、すなわち、プライマリ・インターフェイスファブリック１１２、ＤＦｘファブリック１１４、及びサイドバンドファブリック１１６を規定する。プライマリ・インターフェイスファブリック１１２は、エージェントとメモリとの間の、例えば中央処理装置（ＣＰＵ）等のホストプロセッサ又は他のプロセッサとエージェントとの間の全ての帯域内通信に使用される。プライマリ・インターフェイスファブリック１１２は、エージェントとサポートされるファブリックとの間にピア・トランザクション通信をさらに可能にする。メモリ、入出力（ＩＯ）、構成、及び帯域内メッセージングを含む全てのトランザクション・タイプは、プライマリ・インターフェイスファブリック１１２を介して配信することができる。こうして、プライマリ・インターフェイスファブリックは、ピア及び／又は上流側のコンポーネントを含む通信の間で転送されるデータに対して高性能インターフェイスとして機能することができる。

様々な実装形態では、プライマリ・インターフェイスファブリック１１２は、最大同時並行処理を実現するために分割トランザクションプロトコルを実装している。すなわち、このプロトコルは、要求フェーズ、許可フェーズ、命令及びデータフェーズを提供する。様々な実施形態では、プライマリ・インターフェイスファブリック１１２は、３つの基本的な要求タイプ、ポステッド(posted)、ノンポステッド(non-posted)、及びコンプリージョン(completion)（完了）：をサポートしている。一般的には、ポステッド・トランザクションは、ソースから送信されたときに、このソースだけで完了したと見なされるトランザクションであり、ソースは、トランザクションについて完了又は他の確認メッセージを受信しない。ポステッド・トランザクションの一例は、書き込みトランザクションであってもよい。対照的に、ノンポステッド・トランザクションは、返信メッセージを受信するまで、すなわち完了するまで、ソースによって完了したとは見なされない。ノンポステッド・トランザクションの一例は、ソース側エージェントがデータの読み出しを要求するような読み出しトランザクションである。従って、完了メッセージは、要求されたデータを提供する。

また、プライマリ・インターフェイスファブリック１１２は、個別のチャネルの概念をサポートして、システム全体に流れるような独立したデータのメカニズムを提供する。さらに説明するように、プライマリ・インターフェイスファブリック１１２は、それ自体、トランザクション開始するマスター・インターフェイス及びトランザクションを受け取る標的インターフェイスを含むことができる。マスター側プライマリ・インターフェイスを、さらに、要求インターフェイス、命令インターフェイス、及びデータインターフェイスに細分化することができる。要求インターフェイスは、トランザクションの命令及びデータの移動を制御するために使用することができる。様々な実施形態では、プライマリ・インターフェイスファブリック１１２は、ＰＣＩ順序付け規則及び列挙をサポートすることができる。

次に、サイドバンド・インターフェイスファブリック１１６は、全ての帯域外情報を通信するための標準的なメカニズムであってもよい。このように、所与の実装形態のために設計された特殊目的のワイヤの使用を回避することができ、多様なチップに亘ってＩＰ再利用の能力を高める。従って、ステータス、割り込み、消費電力管理、ヒューズ分布、構成シャドーイング、テストモード等の帯域外通信を処理するための専用のワイヤを用いるＩＰブロックとは対照的に、ＩＯＳＦ仕様に従ったサイドバンド・インターフェイスファブリック１１６は、全ての帯域外通信を標準化して、モジュール性を促進し、様々なデザインに亘ってＩＰ再利用のための検証要件を削減する。一般に、サイドバンド・インターフェイスファブリック１１６は、典型的には、プライマリ・インターフェイスファブリック１１２を介して通信することができるような重要なデータを転送する性能というよりも、むしろ、重要でない情報を通信するために使用されてもよい。

図２にさらに示されるように、ＩＰエージェント１３０，１４０，１５０は、それぞれ、対応するプライマリ・インターフェイス、サイドバンド・インターフェイス、ＤＦｘインターフェイスを含むことができる。しかしながら、上述したように、各エージェントは、これらのインターフェイスの全てを含む必要はなく、所与のＩＰエージェントは、いくつかの実施形態において、単一のインターフェイスのみを含んでもよい。

ＩＯＳＦ仕様を用いて、種々の異なる機能性を有するような多種多様のチップを設計することができる。ここで図３を参照すると、本発明の一実施形態によるＳｏＣの高レベルのブロック図が示されている。図３に示されるように、ＳｏＣ２００は、様々なコンポーネントを含んでもよく、これらコンポーネントの全ては、単一の半導体ダイ上に集積されて、高速且つ現状よりも消費量の少ない低電力で種々の処理機能を提供する。図３に確認されるように、ＳｏＣ２００は、複数のコア２０５_０〜２０５_ｎを有する。様々な実施形態では、コア２０５は、比較的単純な順次処理(in-order)コア又はより複雑な非順次処理(out of order)コアとすることができる。又は順序及び非順次の組合せのコアを、単一のＳｏＣに存在させてもよい。確認されるように、コア２０５は、コヒーレント相互接続２１５を介して相互接続され、さらにキャッシュメモリ２１０、例えば共有ラストレベルキャッシュ（ＬＬＣ）に接続される。本発明の範囲は、この点に限定されるものではないが、一実施形態では、コヒーレント相互接続２１５を、カリフォルニア州、サンタクララにあるインテル社から入手可能な仕様クイックパス相互接続（ＱＰＩ）（商標）に従ってもよい。

図３にさらに確認されるように、コヒーレント相互接続２１５は、ブリッジ２２０を介してＩＯＳＦファブリックとすることができるファブリック２５０に通信することができる。コヒーレント相互接続２１５は、集積メモリコントローラ２１５を介して外部メモリ（図３の実施形態の例を簡易にするために図示せず）に、さらに、ブリッジ２３０を介してファブリック２５０に通信してもよい。

さらに図３に確認されるように、様々なコンポーネントは、セキュリティ処理、暗号化機能等の各種操作を行うために使用することができるコンテンツ処理モジュール（ＣＰＭ）２４０を含むファブリック２５０に接続される。また、関連する表示用映像をレンダリングするディスプレイ・プロセッサ２４５は、メディア処理パイプラインの一部であってもよい。

さらに確認されるように、ファブリック２５０は、ＩＰエージェント２５５にさらに接続されてもよい。単一のエージェントが、図３の実施形態では例示を簡易にするために示されているが、複数のこのようなエージェントを、様々な実施形態に存在させることが可能であることを理解されたい。加えて、他のオンチップ・デバイスとの通信を可能にするために、ファブリック２５０は、ＰＣＩｅ（商標）コントローラ２６０と、ユニバーサル・シリアルバス（ＵＳＢ）２６５と通信することができ、これらが両方とも、これらのプロトコルに従って様々なデバイスと通信することができる。最後に、図３の実施形態には、オープンコア・プロトコル（ＯＣＰ）又はＡＲＭアドバンストマイクロコントローラ・バスアーキテクチャ（ＡＭＢＡ）プロトコル等の他のプロトコルからなる追加のコンポーネントと通信するために使用することができるブリッジ２７０が示されている。図３の実施形態のこれらの特定のコンポーネントに示されているが、本発明の範囲はこのような態様に限定されるものではなく、別の実施形態では、追加の又は異なるコンポーネントが存在してもよいことを理解されたい。

さらに、図３では単一ダイのＳｏＣ実装形態として示されているが、実施形態は、複数のチップが非ＩＯＳＦインターフェイスを介して互いに通信するようなシステムにおいてさらに実装することができることを理解されたい。ここで図４を参照すると、本発明の別の実施形態によるシステムのブロック図が示されている。図４に示されるように、システムは、図３に関して上述したコンポーネントと同様の多数のコンポーネントと、追加のオフダイ・インターフェイス２７５とを含むようなＳｏＣ２００’を含むことができる。従って、ＳｏＣの２００’は、様々な機能を含む別のチップ２８０と通信することができ、これら二つのチップ同士の間の通信だけでなく、１つ又は複数の異なる仕様に従った異なる周辺装置等の様々なオフチップ・デバイスとの通信を可能にする。具体的には、第２チップ２８０は、ＳｏＣ２００’と通信し、次に、本発明の実施形態によるＩＯＳＦファブリックであるファブリック２９０との通信を可能にするようなオフダイ・インターフェイス２８２を含むように示されている。確認されるように、ファブリック２９０は、ＰＣＩｅ（商標）コントローラ２９２、ＵＳＢコントローラ２９４、ブリッジ２９６を含むオフチップ・デバイスと通信するような、各種コントローラにさらに接続されてもよい。

上述したように、様々な実施形態では、全ての帯域外通信は、サイドバンド・メッセージインターフェイスを介して行うことができる。ここで図５を参照すると、本発明の実施形態によるサイドバンド相互接続のブロック図が示されている。図５に示されるように、サイドバンド・インターフェイスシステム１７５は、図５の実施形態においてポイント・ツー・ポイント（ＰＴＰ）相互接続１８５を介して接続されるように示される複数のルータ１８０及び１９０を含む。次に、各ルータは、例えばＩＰエージェント又は所与のシステムの他のコンポーネントである様々なエンドポイントに接続することができる。具体的には、ルータ１８０は、複数のエンドポイント１８６ａ〜１８６ｅに接続され、ルータ１９０は、複数のエンドポイント１９６ｘ〜１９６ｚに接続される。

ここで図６を参照すると、本発明の実施形態によるサイドバンド・インターフェイスに使用可能なシグナリング（信号方式）の詳細を示すブロック図が示されている。図６に示されるように、ルータ１８０とエンドポイント１８６との間の相互接続が示されている。確認されるように、ルータ１８０は、標的インターフェイス１８１とマスター・インターフェイス１８２とを含むことができる。一般に、マスター・インターフェイス１８２は、入力信号を受信するように構成されており、標的インターフェイス１８１は、出力信号を送信するように構成することができる。確認されるように、エンドポイント１８６も、マスター・インターフェイス１８７と標的インターフェイス１８８とを含む。

図６は、さらに、クレジット情報、プット(put)情報、メッセージ・シグナリングの終了、及びデータを含むサイドバンド・インターフェイスに利用可能な様々なシグナリング（信号方式）の詳細を示している。具体的には、クレジット更新が、ノンポステッド・クレジット更新信号（ＮＰＣＵＰ）及びポステッド・クレジット更新信号（ＰＣＣＵＰ）等のサイドバンド・インターフェイスを介して通信することができる。また、プット(put)信号（ＮＰＰＵＴ及びＰＣＰＵＴ）を設けてもよい。さらに、メッセージ（ＥＯＭ）信号の終了を通信することができる。最終的に、データは、一実施形態では、１バイト長の通信チャネルを介して実施されるペイロードパケットを介して通信することができる。図６の実施形態におけるこの特定の実装形態に示されているが、本発明の範囲はこの点に限定されるものではない。クレジット・プット信号がハイであるときは、これは、クレジットが返されることを意味する。プット信号がハイであるときは、ペイロード（例えば、データ）信号が有効であることを意味する。プット(PUT)及びＥＯＭが同時にハイであるときは、現在のペイロードがメッセージの最後のペイロードであることを意味する。インターフェイスは、データペイロードを「プット」とともに、同じクロックサイクルでクレジットを「プット」することもできることに留意されたい。

様々な実装形態では、サイドバンド・メッセージは、追加のヘッダ情報を１つ又は複数の拡張ヘッダで搬送することができる。本明細書で使用されるように、用語「追加のヘッダ情報」は、「（潜在的に異なるタイプの）より大きな情報量及び／又は所与のインターフェイス仕様に従って標準ヘッダに存在する情報とは異なる配列を指すために使用される。一実施形態では、各拡張ヘッダは、本明細書に説明される実施形態では、１ＤＷ長の従来ヘッダの長さとすることができる。メッセージ内の拡張ヘッダの数は、固有のものである。システム内の異なるエージェントは、様々な数の拡張ヘッダで拡張されたメッセージを開始することができる。拡張ヘッダの存在を識別するために、いくつかの実施形態では、拡張ヘッダ（ＥＨ）インジケータ、例えば単一のビットは、随意の拡張ヘッダの存在を示すために全てのメッセージの標準ヘッダに存在させる、すなわち標準ヘッダ長の別のヘッダの追加（ヘッダ）に存在させることができる。次に、全ての拡張ヘッダ内のＥＨインジケータは、標準ヘッダ長のその後の拡張ヘッダの存在を示している。存在する場合には、１つ以上の拡張ヘッダが、標準ヘッダの後に（例えば、１ＤＷ標準ヘッダ長を有するシステムの最初のＤＷの後に）追加することができる。

図７は、ヘッダ部３１０及びデータ部３４０を有するメッセージ３００を示しており、ここで、ヘッダ部３１０は、Ｎ個の拡張ヘッダまで含むことができる。他の全てのサイドバンド・メッセージは、同じ拡張ヘッダ・フォーマットに従う。

図７の例に示されるように、ＥＨインジケータ３１４は、第１の拡張ヘッダ（（ＥｘｐＨｄｒ１））３２０の存在を示すためのＩＯＳＦ仕様の標準ヘッダとすることができる第１のヘッダ３１２に設定される。図７に確認されるように、第１のヘッダ３１２は、宛先フィールド３１１、ソース・フィールド３１３、命令コード・フィールド３１５、タグ・フィールド３１８及び応答フィールド３１９を含むような様々な追加フィールドを含む。図７の実施形態に確認されるように、ＥＨインジケータ３１４は、ヘッダの最後のフロー制御ユニット（フリット）に、すなわちこのフリットの最上位ビット（ＭＳＢ）に存在してもよいが、本発明の範囲はこの点に限定されるものではない。

種々の実施形態では、第１のヘッダの後に続く各拡張ヘッダについて、そのＥＨインジケータは、代わりに、対応する拡張ヘッダの最初のフリット内に存在してもよい。従って、図７に確認されるように、第１の拡張ヘッダ３２０は、ヘッダ識別子フィールド（例えば、ヘッダＩＤ）３２４と一緒に、ヘッダ３２０の第１のフリットに存在するＥＨインジケータ３２２を含む。拡張ヘッダＩＤフィールド３２４、ＥｘｐＨｄｒＩＤ［６：０］は、特定のヘッダ拡張ＩＤを識別することができる。様々な実施形態では、識別子は、ヘッダを生成するエージェントに固有のものであるというよりも、ＩＯＳＦ仕様に従って決定された特定のタイプの拡張ヘッダを示してもよい。一例として、ＩＯＳＦ仕様は、ＳＡＩを提供する目的の拡張ヘッダ識別子を現時点で規定しており、一実施形態では、拡張ヘッダ・フィールドは、０００００００のバイナリ値を有することができる。エージェントが、０００００００のＩＤを含む拡張ヘッダを受信する場合に、エージェントは、その拡張ヘッダ内に含まれるデータがＳＡＩであることを知っている。

ＥＨインジケータを第１の拡張ヘッダ（ＥｘｐＨｄｒ１）に設定することは、第２の拡張ヘッダ等の存在を示す。最後の拡張ヘッダ（ＥｘｐＨｄｒＮ）３３０におけるＥＨインジケータ３３２は、設定されておらず、現在の拡張ヘッダが最後の拡張ヘッダであることを示している。図７に確認されるように、データペイロード・フリットは、最後の拡張ヘッダ３３０の後に開始する。

全ての標的エージェントは、それら標的エージェントがいずれかの拡張ヘッダの内容を解釈しているか否かに関係なく、現在の拡張ヘッダでフォーマットされるメッセージを把握するとともに、メッセージ及びデータペイロードから拡張ヘッダを区別する能力をさらにサポートするように構成することができる。標的エージェントによってサポートされていないＥｘｐＨｄｒＩＤフィールドを含む任意の拡張ヘッダは、ドロップされ、サポートされるＥｘｐＨｄｒＩＤにエイリアスをせず、受信メッセージのエージェントの処理に影響を与えない。様々な実施形態では、ルータは、標準ヘッダ（例えば、第１のヘッダＤＷ）のみを使用して、メッセージの種類を判定し、そのメッセージをその標的エージェントへルーティングするように構成することができる。システム内の正確性を維持するために、ルータは、拡張ヘッダの属性を変更することなく、拡張ヘッダを含むメッセージを転送するようにさらに構成されてもよい。

ここで図８を参照すると、本発明の実施形態によるパケットを生成する方法のフロー図が示されている。より具体的には、図８の方法４００は、エージェントによって拡張ヘッダを有するサイドバンド・パケットを生成するために使用されてもよい。確認されるように、方法４００は、パケットのヘッダ部に追加データが含まれるか否かを判定する（ダイヤモンド４１０）ことによって開始することができる。含まれない場合には、標準パケットヘッダは、リセット値を有する拡張ヘッダ・インジケータとともに生成される（ブロック４１５）。こうして、このリセット値は、パケットが標準ヘッダ長さであることを示している。従って、ブロック４２０において、パケットは、標準ヘッダで送信することができる。

代わりに、ダイヤモンド４１０で、追加のデータがそのヘッダに含まれると判定された場合には、制御がブロック４３０に移り、ここで標準ヘッダが生成され、さらに、このヘッダは、設定値を含む拡張ヘッダインジケータを有するように生成される。この設定値によって、追加のヘッダ情報がパケットに存在することを、パケットの受信側に示す。次に、制御は、ダイヤモンド４４０に移り、この追加のヘッダ情報が生成された最後の拡張ヘッダに存在するか否かを判定することができる。もし最後の拡張ヘッダであれば、制御は、ブロック４５０に移り、ここで単一の追加のヘッダが生成され、且つメッセージに追加することができる。より具体的には、この追加のヘッダは、例えば拡張ヘッダ内に存在するデータのタイプを識別するために、追加データ及び拡張ヘッダ識別子を含んでもよい。また、この追加のヘッダは、リセット拡張ヘッダインジケータを含むことができ、こうして、さらなる拡張ヘッダが、このパケットのために通信されるべきでないことを示す。従って、制御はブロック４６０に移り、ここでパケットを、（その標準パケット及びペイロードデータに加えて）拡張ヘッダと共に送信することができる。

代わりに、ダイヤモンド４４０で、この追加のヘッダ情報が最後の拡張ヘッダでないと判断された場合には、制御は、ブロック４５５に移る。そこでは、ヘッダが、追加データ及び拡張ヘッダ識別子を含むように生成することができる。さらに、追加のヘッダは、拡張ヘッダインジケータのセットを有することができ、メッセージに追加することができる。上述したように、制御は、その後、ダイヤモンド４４０に移る。図８の実施形態では、この特定の実装形態に示されているが、本発明の範囲はこの点に限定されるものではないことを理解されたい。

上述したように、拡張ヘッダを含むパケットを受信したルータは、必ずしも拡張ヘッダ内の情報を処理する又はサポートする必要はなく、代わりに、パケットの標準ヘッダ部分に存在する情報に単に基づいて標的宛先に向けてパケットを転送することができる。ここで図９を参照すると、本発明の実施形態による拡張ヘッダを含むパケットをルータで処理する方法のフロー図が示されている。図９に示されるように、方法５００は、拡張ヘッダを含むパケットを受信すること（ブロック５１０）によって開始することができる。ルータは、次に、例えば標準ヘッダ内に存在する情報に基づいてメッセージタイプを判定してもよく、さらに、標準ヘッダの宛先識別子フィールド等の標準ヘッダに存在する情報に基づいてルーティングを決定する（ブロック５２０）ことができる。従って、ブロック５３０において、パケットを、拡張ヘッダと共に判定されたエージェントに転送することができる。ルータは、拡張ヘッダ部分に存在する情報を考慮しない又はサポートしていないにもかかわらず、標準ヘッダに存在する情報を依然として処理して、その適切な宛先にパケットを転送することができる。

また上述したように、多くの実施形態では、拡張ヘッダを含むパケットの受信側は、必ずしも拡張ヘッダに存在する情報をサポートする必要はなく、様々なＩＰのエージェントのより効率的な再利用を可能にする。ここで図１０を参照すると、拡張ヘッダを含むパケットを標的エージェントで処理する方法のフロー図が示されている。図１０に確認されるように、方法６００は、拡張ヘッダを含むパケットを標的エージェントで受信すること（ブロック６１０）によって開始することができる。次に、標的エージェントが拡張ヘッダに存在する情報をサポートしているか否かを判定することができる。より具体的には、ダイヤモンド６２０で、標的エージェントが、１つ又は複数の拡張ヘッダに存在する情報をサポートしているか否かを、拡張ヘッダ識別子フィールド内の情報に基づいて判定することができる。情報をサポートしている場合には、制御はブロック６３０に移り、ここで、パケットは、標的エージェントによって拡張ヘッダ及び標準ヘッダに存在する情報を少なくとも部分的に用いて処理される。代わりに、ダイヤモンド６２０で、標的エージェントが拡張ヘッダ内の情報をサポートしていないと判定された場合には、制御はブロック６４０に移る。そこで、ヘッダの拡張部分（１つ又は複数の拡張ヘッダ部であるか否かによらず）をドロップすることができ、従って、制御はブロック６５０に移り、ここでパケットは、標準ヘッダ内の情報を用いて処理することができる。

いくつかの実装形態では、複数の拡張ヘッダが単一のパケットで送信され、標的エージェントは、拡張ヘッダのうちの少なくとも１つに存在する情報をサポートできるが、他の拡張ヘッダに存在する情報をサポートできないことに留意されたい。従って、このような状況では、標的エージェントは、例えば拡張ヘッダの拡張ヘッダ識別子フィールドに基づいてサポートされるような、あらゆる拡張ヘッダに存在する情報を用いることができる。図１０の実施形態のこの特定の実装形態に示されているが、本発明の範囲は、この点に限定されるものではないことを理解されたい。

カプセル化メカニズムを介して追加のヘッダ情報を提供するというよりもむしろ、実施形態は、全てのパケットの同じ場所に常にあるが、依然として任意の長さの拡張ヘッダ長を可能にするような拡張ヘッダを提供することができる。

実施形態は、こうして、ルーティングファブリックが拡張ヘッダに依存しないすることを可能にするとともに、標的エージェントがメッセージの受信処理中に拡張ヘッダを完全に無視することをさらに可能にする。これは、インターネットプロトコル（ＩＰ）に対比されるが、ＩＰスティックの各層が、追加のヘッダを既存のヘッダの内部に挿入し、それによって、各層は、プロトコルスタックの任意のレイヤでパケットを処理するために、「その各層を処理し(peel the onion)」なければならない。対照的に、本発明の実施形態による拡張ヘッダ機構を用して、ルータは、標準パケットヘッダ（例えば、第１ＤＷ）のみを処理することが保証され、拡張ヘッダは、所定の位置で開始する（例えば、第２ＤＷから始まる）ことが保証される。このように、ハードウェアは、オンダイ(on-die)の、メッセージベースの相互接続を促進するために供給することができる。

図３及び図４のＳＯＣは、ハイレベルであるが、追加の機能が存在し得ることを理解されたい。ここで図１１を参照すると、本発明の実施形態によるＳｏＣの一部のより詳細なブロック図が示されている。図１１に示されるように、システムメモリに関しても同様である。

確認されるように、オフダイ・インターフェイス７１０（一実施形態では、直接メディアインターフェイス（ＤＭＩ）とすることができる）は、ハブ７１５、例えば様々な周辺機器の間での通信を順次提供する入力／出力ハブに接続される。図中の説明を簡易にするために図示していないが、管理エンジン及び仮想エンジン等の様々なエンジンは、ハブ７１５に直接的に接続することができることを理解されたい。

ＩＯＳＦ仕様に従ったマルチポイント又は共用バスであるマルチバスに接続を提供するために、ＩＯＳＦコントローラ７２０は、ハブ７１５及びバス７３０の間に接続されてもよく、こうしてファブリックの要素だけでなくルータを組み込むようなＩＯＳＦバスであってもよい。図７に示される実施形態では、第１のＩＯＳＦバス７３０は、オフチップ・デバイスの制御を提供するために、各種コントローラに接続させてもよい。具体的には、ＰＣＩコントローラ７２２、ＳＡＴＡコントローラ７２４、ＵＳＢコントローラ７２６が示されている。次に、第２のＩＯＳＦバス７５０は、システム管理バス７５２に及びリアルタイムクロック７５４に接続される。

図１１にさらに確認されるように、第１のＩＯＳＦバス７３０は、プライマリ情報及びサイドバンド情報の両方のためのＩＯＳＦブリッジ７３５に接続することができ、このＩＯＳＦブリッジは、各種コントローラ及びコンポーネントが取り付けられるような、例えば異なるプロトコルの第３のバス７４０に相互接続を提供する。図１１に示される実施形態では、このようなコンポーネントは、不揮発性メモリへのインターフェイスを提供するためのフラッシュ・コントローラ７４１や、例えばＰＣＩ仕様により種々の従来の機能を実現することができるレガシーデバイス７４２を含み、割り込みコントローラ及びタイマをさらに含むことができる。また、オーディオ７４３、ＵＳＢ７４４、ギガバイト・イーサネット（登録商標）（ＧｂＥ）７４５、シリアル周辺機器インターフェイス（ＳＰＩ）７４６及びＰＣＩ７４７用のインターフェイスを全て提供してもよい。図１１の実施形態におけるこの特定の実装形態に示されているが、本発明の範囲は、この点に限定されるものではないことを理解されたい。

依然として他の実装形態が可能である。ここで図１２を参照すると、本発明の実施形態による他のＳｏＣのブロック図が示されている。図１２に示されるように、ＳｏＣ８００は、例えばサーバシステムで用いるために構成されてもよい。図１２に確認されるように、ＳｏＣは、一般に、図１１の実施形態に確認されるようなコンポーネントを含むようなプラットフォーム・コントローラハブ（ＰＣＨ）８４０を含むことができる。つまり、複数のＩＯＳＦバス７３０及び７４０は、これらのバスに接続するためのブリッジ７３５と一緒に存在しててもよい。バス７３０は、ＰＣＩｅコントローラ７２２、ＳＡＴＡコントローラ７２４、ＵＳＢコントローラ７２６を含むバスに接続された様々なエージェントを含んでもよい。次に、ＩＯＳＦ制御ユニット７２０を介して、通信は、追加のバス７１８を介して行うことができ、コア又は他の処理ユニット等の（図１２の実施形態では説明を簡易にするために示されていない）上流側デバイスと通信することができる。

さらに図１２に確認されるように、他のサーバベースのコンポーネントとの通信を提供するために、追加のＩＯＳＦバス８２０を提供してもよく、次にＩＯＳＦコントローラ８２２と、上流側のバス８２５に接続される上流側スイッチポート８２４（例えば、Ｘ１６ポート）と通信することができる。また、下流側マルチスイッチポート８２６及び８２８をバス８２０に接続してもよい。

さらに、例えばサーバベースのシステムの記憶装置と通信を可能にするために、スイッチポート８３０をバス８２０及び別のＩＯＳＦバス８５０の間に接続してもよく、次に様々な記憶装置と接続するための多機能デバイスである記憶コントローラユニット（ＳＣＵ）８５５に接続することができる。

実施形態は、コードで実装されてもよく、システムをプログラムして命令を実行させるような命令が内部に記憶された非一時的記憶媒体に格納されてもよい。記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、半導体ドライブ（ＳＳＤ）、読み出し専用コンパクトディスクメモリ（ＣＤ−ＲＯＭ）、書き換え可能なコンパクトディスク（ＣＤ−ＲＷ）、及び光磁気ディスクや、例えば読み出し専用メモリ（ＲＯＭ）等の半導体デバイス、ダイナミック・ランダムアクセスメモリ（ＤＲＡＭ）等のランダムアクセスメモリ（ＲＡＭ）、スタティック・ランダムアクセスメモリ（ＳＲＡＭ）、消去可能なプログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、フラッシュメモリ、電気的に消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、磁気又は光カード、又は電子命令を記憶するのに適した任意の他のタイプの媒体を含むことができるが、これらに限定されるものではない。

本発明は、限られた数の実施形態に関して説明してきたが、当業者は、それらの説明から多数の修正及び変更を認識するであろう。添付の特許請求の範囲は、このような修正及び変更の全てが、本発明の真の精神及び範囲内にあることを包含することが意図される。

Claims

方法であって、当該方法は：
第１のエージェントでパケットを受信するステップであって、前記パケットが、拡張ヘッダインジケータを含む第１のパケットヘッダを有する、受信するステップと；
前記第１のパケットヘッダの前記拡張ヘッダインジケータに基づいて、前記パケットが、少なくとも１つの追加のパケットヘッダを含むか否かを判定するステップと；
追加のパケットヘッダを含む場合に、前記少なくとも１つの追加のヘッダのヘッダ識別子に基づいて、前記第１のエージェントが、前記少なくとも１つの追加のパケットヘッダ内の情報をサポートしているか否かを判定するステップと；
前記第１のエージェントが前記情報をサポートしている場合には、前記少なくとも１つの追加のパケットヘッダを処理し、サポートしていない場合には、前記少なくとも１つの追加のパケットヘッダをドロップするステップを含む、
方法。
前記第１のエージェントが前記情報をサポートしていない場合には、前記第１のパケットヘッダを用いて前記パケットを処理するステップをさらに含む、
請求項１に記載の方法。
Ｎ−１番目の追加のパケットヘッダの拡張ヘッダインジケータに基づいて、前記パケットがＮ番目の追加のパケットヘッダを含むか否かを判定するステップをさらに含む、
請求項１に記載の方法。
前記少なくとも１つの追加のパケットヘッダのセキュリティ属性情報を含むデータを前記第１のエージェントで使用するステップをさらに含む、
請求項１に記載の方法。
第２のエージェントにおいて受信したセキュリティ属性情報を、第２のパケットヘッダ用の追加のパケットヘッダとして使用しないステップをさらに含み、前記第２のエージェントは、前記セキュリティ属性情報をサポートしていない、
請求項４に記載の方法。
ソースエージェントに接続されたルータで前記パケットを受信するとともに、前記第１のパケットヘッダに基づいて前記第１のエージェントに前記パケットをルーティングするステップをさらに含み、前記ルータは、前記少なくとも１つの追加のパケットヘッダの情報をサポートするように構成されていない、
請求項１に記載の方法。
前記ヘッダ識別子は、前記少なくとも１つの追加ヘッダのヘッダ識別子フィールドに存在する、
請求項１に記載の方法。
前記第１のエージェントのサイドバンド・インターフェイスで前記パケットを受信するステップをさらに含み、前記サイドバンド・インターフェイスは、第２のエージェントから前記パケットを受信するルータに接続されており、前記第１及び第２のエージェント及び前記ルータが、システムオンチップ（ＳｏＣ）に存在する、
請求項１に記載の方法。
前記第１及び第２のエージェントのうちの少なくとも一方は、第三者の知的財産（ＩＰ）ブロックである、
請求項８に記載の方法。
前記少なくとも１つの追加のヘッダの情報を変更することなく、前記ルータから前記第１のエージェントに前記パケットを転送するステップをさらに含む、
請求項８に記載の方法。
命令を含む機械的にアクセス可能な記憶媒体を含む物品であって、前記命令は、実行されたときに、システムオンチップ（ＳｏＣ）に：
第１のエージェントから送信されたパケットに追加のヘッダ情報が含まれるか否かを判定する；
前記追加のヘッダ情報が含まれる場合には、前記パケットの第１のヘッダの拡張ヘッダインジケータを第１の状態に設定して、前記パケットの第２のヘッダの存在を示す；
前記追加のヘッダ情報の少なくとも一部を前記第２のヘッダに含める；
前記第１及び第２のヘッダ及びデータ部を含む前記パケットを前記第１のエージェントから送信する；ようにし、
前記追加のヘッダ情報が前記第２のヘッダ内に収まるようにサイズ決めされている場合には、前記第２のヘッダの拡張ヘッダインジケータを第２の状態に設定して、さらなるヘッダが前記パケット内に含まれないことを示すような命令を含む、
物品。
実行されたときに、前記追加のヘッダ情報が前記第２のヘッダ内に収まるようにサイズ決めされていない場合には、システムが、前記第２のヘッダの前記拡張ヘッダインジケータを前記第１の状態に設定して、前記パケットに第３のヘッダの存在を示すような命令をさらに含む、
請求項１１に記載の物品。
実行されたときに、システムが、前記第１のエージェントのサイドバンド・インターフェイスを介して前記第１のエージェントに接続されたルータに、該ルータに接続された第２のエージェント宛の前記パケットを送信させるような命令をさらに含んでおり、前記第１のヘッダには、前記第２のエージェント用の宛先識別子を含んでおり、前記第１及び第２のエージェント及び前記ルータが、前記ＳｏＣに存在する、
請求項１１に記載の物品。
実行されたときに、システムが、前記拡張ヘッダインジケータ及び拡張ヘッダ識別子を前記第２のヘッダの第１のフロー制御ユニットに含めるとともに、前記追加のヘッダ情報を、前記第１のフロー制御ユニットに続く前記第２のヘッダの複数のフロー制御ユニットに含めるような命令をさらに含む、
請求項１１に記載の物品。
前記追加のヘッダ情報は、セキュリティ属性情報を含む、
請求項１４に記載の物品。
装置であって、当該装置は：
追加のヘッダ情報を含むパケットを送信する第１のエージェントであって、該第１のエージェントは、前記パケットの第１のヘッダの拡張ヘッダインジケータを設定して、前記パケットの第２のヘッダの存在を示すとともに、前記追加のヘッダ情報の少なくとも一部を前記第２のヘッダに含めて、前記第１及び第２のヘッダ及びデータ部を含む前記パケットを送信する、第１のエージェントと；
前記パケットを受信するとともに、前記第１のヘッダに基づいて第２のエージェントに前記パケットをルーティングするような前記第１のエージェントに接続されたルータと；
該ルータに接続された第２のエージェントと；を備えており、
前記第２のエージェントは、該第２のエージェントがセキュリティ属性情報を処理するように構成されている場合には、前記追加のヘッダ情報の前記セキュリティ属性情報を含むデータを使用し、処理するように構成されていない場合には、前記セキュリティ属性情報をドロップする、
装置。
前記第１のエージェントは、前記追加のヘッダ情報が前記第２のヘッダ内に収まるようにサイズ決めされた場合に、前記第２のヘッダの拡張ヘッダインジケータをリセットし、収まらないようにサイズ決めされた場合に、前記第２のヘッダの前記拡張ヘッダインジケータを設定して、前記追加のヘッダ情報の少なくとも一部を含む前記パケットの第３のヘッダの存在を示す、
請求項１６に記載の装置。