(57)【要約】本発明は、ホストシステム（６）をネットワーク（８）にインタフェースするためのネットワークインタフェースシステム（２）に関する。このネットワークインタフェースシステム（２）は、バスインタフェースシステム（６）、メディアアクセスコントロールシステム（１０）およびセキュリティシステム（１４）を有する。ネットワークインタフェース（２）は、ホストシステム（６）のＩＰｓｅｃ処理の負荷を軽減する。本発明によれば、セキュリティシステム（１４）は、発信データを暗号化するための２つのプロセッサ（２０，２１）を有する。発信データパケットは、プロセッサ（２０，２１）の一方ずつに交互に送信され、これにより、送信処理が受信処理からみて高速化される。
2007526718.tif 000002
【特許請求の範囲】
【請求項１】
ホストシステム（６）からネットワーク（８）に発信データを提供すると共に、前記ネットワーク（８）から前記ホストシステム（６）に着信データを提供するため、前記ホストシステム（６）を前記ネットワーク（８）にインタフェースするネットワークインタフェースシステム（２）であって、
前記ホストシステム（６）のホストバス（１０６）に結合され、前記ネットワークインタフェースシステム（８）と前記ホストシステム（６）の間でデータを転送するように適合されたバスインタフェースシステム（４）と、
前記ネットワーク（８）に結合され、前記ネットワークインタフェースシステム（２）と前記ネットワーク（８）との間でデータを転送するように適合されたメディアアクセスコントロールシステム（１０）と、
前記バスインタフェースシステム（４）および前記メディアアクセスコントロールシステム（１０）に結合され、前記ネットワーク（８）と前記ホストシステム（６）との間で転送中の着信データおよび発信データを記憶するように適合されたメモリシステム（１２）と、
前記メモリシステム（１２）に結合され、発信データを選択的に暗号化すると共に、着信データを選択的に復号化するように適合されたセキュリティシステム（１４）と、を有し、
前記セキュリティシステム（１４）は、前記発信データを暗号化するための２つのプロセッサ（２０，２１）を有し、前記２つのプロセッサ（２０，２１）は、それぞれ前記発信データを暗号化するために相互に独立して動作可能であり、前記セキュリティシステム（１４）は暗号化のために発信データパケットを前記プロセッサ（２０，２１）の一方ずつに交互に送るように構成されているか構成可能であるネットワークインタフェースシステム。
【請求項２】
前記２つのプロセッサ（２０，２１）は、前記発信データを認証するために動作可能である請求項１記載のネットワークインタフェースシステム。
【請求項３】
前記２つのプロセッサ（２０，２１）は機能的に同一である請求項１記載のネットワークインタフェースシステム。
【請求項４】
前記セキュリティシステム（１４）は、前記メモリシステム（１２）に結合された２つの入力バッファ（２６，２７）を更に有し、前記入力バッファ（２６，２７）はそれぞれ前記プロセッサ（２０，２１）の１つに結合されており、前記セキュリティシステム（１４）は、前記メモリシステム（１２）から読み出した発信データパケットを前記入力バッファ（２６，２７）の一方ずつに交互に送る請求項１記載のネットワークインタフェースシステム。
【請求項５】
前記セキュリティシステム（１４）は、前記メモリシステム（１２）に結合された２つの出力バッファ（２４，２５）を更に有し、前記出力バッファ（２４，２５）はそれぞれ前記プロセッサ（２０，２１）の１つに結合されており、前記プロセッサ（２０，２１）は、処理されたデータパケットを前記出力バッファ（２４，２５）に書き込むように構成されており、前記セキュリティシステム（１４）は、処理前に前記メモリシステム（１２）から前記データパケットが読み出されたのと同じ順序で、前記出力バッファ（２４，２５）から前記メモリシステム（１２）に前記処理データパケットを転送するように構成されている請求項１記載のネットワークインタフェースシステム。
【請求項６】
前記セキュリティシステム（１４）は、着信データを選択的に復号化するためのプロセッサ（２０）を更に有し、前記セキュリティシステム（１４）は、発信データを復号化するためのプロセッサよりも着信データを暗号化するためのプロセッサのほうを多く有する請求項１記載のネットワークインタフェースシステム。
【請求項７】
単一集積回路であって、
ネットワーク（８）への送信のためにデータに対して送信ＩＰｓｅｃ処理を実行するように適合されたセキュリティシステム（１４）を有し、前記セキュリティシステム（１４）は、前記送信ＩＰｓｅｃ処理を実行するための２つのプロセッサ（２０，２１）を並列に備える単一集積回路。
【請求項８】
前記２つのプロセッサ（２０，２１）は機能的に同一である請求項７記載の単一集積回路。
【請求項９】
前記セキュリティシステム（１４）は、それぞれが前記プロセッサの１つに結合された２つの入力バッファ（２６，２７）を更に有し、前記セキュリティシステム（１４）は、発信データパケットを前記入力バッファ（２６，２７）の一方ずつに交互に送るように構成されている請求項７記載の単一集積回路。
【請求項１０】
前記セキュリティシステム（１４）は、２つの出力バッファ（２４，２５）を更に有し、前記出力バッファ（２４，２５）はそれぞれプロセッサ（２０，２１）の１つに結合されており、前記プロセッサは、処理されたデータパケットを前記出力バッファ（２４，２５）に書き込むように構成されており、前記セキュリティシステム（１４）は、処理前に前記データパケットが前記セキュリティシステム（１４）に読み出されたのと同じ順序で、前記出力バッファ（２４，２５）から前記処理されたデータパケットを送信するように構成されている請求項７記載の単一集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピュータデバイスの分野に関し、より詳細には、ホストデバイスまたはシステムをネットワークにインタフェースするための方法およびシステムに関する。
【背景技術】
【０００２】
パーソナルコンピュータなどのホストコンピューティングシステムは、多くの場合、通信ネットワーク上のノードとして動作し、各ノードは、ネットワークからデータを受信したり、ネットワークにデータを送信することができる。データは、グループまたはセグメントの形でネットワーク上を転送されるが、その際、データの編成とセグメント化はネットワークオペレーティングシステムのプロトコルによって決められており、多くの異種のプロトコルが存在する。事実、同じ通信ネットワーク上で、異種のプロトコルに対応する複数のデータセグメントが共存することができる。ノードが情報パケットを送受信するために、ノードは、通信ネットワークとホストシステムとの間で情報を転送する役目を担うネットワークインタフェース周辺装置を備えている。送信のために、ホストシステムのプロセッサユニットは、ネットワークオペレーティングシステムのプロトコルに従って、データまたは情報パケットを組み立てて、これをネットワーク周辺装置に渡す。受信時には、プロセッサユニットは、ネットワーク周辺装置が受信したパケットを取得してデコードする。プロセッサユニットは、その送受信機能の多くを、ネットワーク周辺装置に関連する割込みサービスルーチンからの命令に応えて実行する。受信パケットに処理が必要な場合、ネットワーク周辺装置によって、ホストシステムに対して割込みが発行されうる。従来、ネットワーク周辺装置が、パケットの全バイトを受信したか、パケットの一定のバイト数を受信した後に、割込みが発行される。
【０００３】
ネットワークは、通常、レイヤまたはレベルの連続体またはスタックとして動作し、各レイヤは、すぐ上層のレイヤにサービスを提供している。多くの階層ネットワークアーキテクチャが可能であり、レイヤの数や、各レイヤの機能および内容は、ネットワーク毎に異なっている可能性がある。国際標準化機構（international standards organization：ＩＳＯ）は、アプリケーション層（レイヤ７等）、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、および物理層（レイヤ１等）の７層からなるプロトコルスタックを規定する開放形システム相互接続（Open Systems Interconnection：ＯＳＩ）モデルを開発しており、このモデルでは、制御が、ある局のアプリケーション層を始点として、次のレイヤに渡されて最下層まで到達し、チャネルを介して次局に送られて、次局の階層構造を昇っていく。ホストシステムのユーザは、通常、最上層（例えばアプリケーション層）で実行されているソフトウェアプログラムと対話し、最下層（例えば物理層）においてネットワーク上を信号が送信される。
【０００４】
広く用いられるネットワークアーキテクチャの１つに、時としてＴＣＰ／ＩＰスタックと呼ばれるものがあり、このスタックでは、アプリケーション層が、ＦＴＰ（file transfer protocol：ファイル転送プロトコル）、ＨＴＴＰ（ハイパーテキスト転送プロトコル：hyper text transfer protocol）またはＳＳＨ（セキュアシェル：secure shell）のいずれかである。このようなネットワークでは、トランスポート層のプロトコルは、通常、ＴＣＰ（伝送制御プロトコル：transmission control protocol）またはＵＤＰ（ユーザデータグラムプロトコル：user datagram protocol）として実装され、ネットワーク層は、ＩＰ（インターネットプロトコル：internet protocol）、ＡＲＰ（アドレス解決プロトコル：address resolution protocol）、ＲＡＲＰ（逆アドレス解決プロトコル：reverse address resolution protocol）、またはＩＣＭＰ（ネットワーク間制御メッセージプロトコル）などのプロトコルを使用する。データリンク層は、通常、ネットワーク上のコンピュータが、データへのアクセスを取得し、それを送信するための権限を取得する方法を制御しているＭＡＣ（メディアアクセス制御：media access control）サブレイヤと、フレーム同期、フロー制御およびエラー検査を制御しているＬＬＣ（ロジカルリンク制御：logical link control）サブレイヤの２つのサブレイヤに分けられる。物理層は、物理的な（電気的および機械的など）レベルにおいて、データを、電気的インパルス、光信号および／または無線信号のビットストリームとしてネットワークを介して伝達する。物理層は、イーサネット、ＲＳ２３２、ＡＴＭ（非同期転送モード：asynchronous transfer mode）または物理層コンポーネントを有するその他のプロトコルを実装しており、イーサネットは、ＩＥＥＥ８０２．３に規定され、広く用いられているローカルエリアネットワーク（ＬＡＮ）である。
【０００５】
ネットワークプロトコルスタック内のレイヤの１つ以上は、多くの場合、チェックサム処理など、誤り検出のための機構を提供しており、送信されるメッセージには、通常、メッセージ内の一定の（set）ビットの数によって決まる数値のチェックサム値が含まれる。受信側のネットワークノードは、送信側と同じアルゴリズムを使用してチェックサムを計算し、この結果を、受信メッセージ内のチェックサムデータと比較することでチェックサム値を検証する。値が一致しない場合、受信側は、ネットワークでの送信中に誤りが発生したとみなすことができる。１つの例では、ＴＣＰレイヤ（レイヤ４）とＩＰレイヤ（レイヤ３）は、通常、ネットワークアプリケーションにおける誤り検出にチェックサムを使用している。
【０００６】
また、ネットワークプロトコルスタック内のレイヤの１つ以上において、データが分割またはセグメント化されることがある。例えば、ＴＣＰプロトコルでは、アプリケーション層から受信したデータを、それぞれにヘッダが付加されたセグメントに分割することができる。セグメントヘッダには、送信側ポートと受信側ポート、セグメントの順序に関する情報、およびチェックサムが含まれる。セグメント化は、例えば、下層のレイヤでは、データメッセージのサイズが、上層のレイヤから受け取るメッセージよりも小さいサイズに制限されている場合に使用される。一例を挙げると、ＴＣＰフレームは最大６４キロバイトであるが、イーサネットネットワークでは、物理層においてこれよりも遙かに小さいサイズのフレームしか許容されない場合がある。この場合、ＴＣＰレイヤは、イーサネットのサイズ制限に対応するために、大きなＴＣＰフレームを、セグメント化された小さいフレームに分割しうる。
【０００７】
ネットワークプロトコルレイヤの１つ以上が、権限を持たないシステムまたはユーザが、データを読み出すのを防ぐため、および／またはデータが予想された供給元からのものであることを保証するために、暗号化および認証などのセキュリティ機構を使用することがある。例えば、データの安全な交換を促進するように、ＩＰレイヤ（例えばＯＳＩモデルのレイヤ３）のためのＩＰセキュリティ（ＩＰｓｅｃ）規格が採用されており、ＶＰＮ（仮想専用ネットワーク：virtual private network）の実装に広く使われている。ＩＰｓｅｃは、トランスポートモードとトンネルモードの２つの動作モードに対応している。トランスポートモードでは、送信側がＩＰメッセージのデータペイロード部分を暗号化するが、ＩＰヘッダは暗号化されないのに対し、トンネルモードでは、ヘッダとペイロードの両方が暗号化される。受信側のシステムでは、メッセージがＩＰレイヤで復号化され、送信側のシステムと受信側のシステムは、ＳＡ（セキュリティアソシエーション：security association）を介してパブリックキーを共有している。キーの共有は、通常、受信側が、パブリックキーを取得して、デジタル証明書を使用して送信側を認証できるようにするＩＳＡＫＭＰ（ネットワーク間セキュリティアソシエーションおよび鍵管理プロトコル：internet security association and key management protocol）によって実現される。
【０００８】
従来のネットワークでは、上位層および中位層のレイヤのタスクは、ホストシステムのソフトウェア内で実行される。ホストコンピュータのアプリケーションソフトウェアプログラムが、ネットワーク上の別のデバイスにデータを転送する必要がある場合、アプリケーションは、このデータを、ホストのオペレーティングシステム（ＯＳ）のＴＣＰレイヤソフトウェアにパケットとして渡す。ＴＣＰレイヤソフトウェアは、このデータパケットとＴＣＰヘッダを含むＴＣＰフレームを作成して、必要なＴＣＰのセグメント化を行い、チェックサムを生成する。次に、ホストのＩＰレイヤソフトウェアは、ＩＰヘッダとＩＰトレーラ、およびイーサネット（ＭＡＣ）ヘッダを作成し、選択されているＩＰｓｅｃセキュリティ処理を実行する。次に、生成されたＩＰフレームが、ネットワークに送信するため、ネットワークネットワークインタフェースに提供される。受信側のホストでは、受信したフレームが、受信側ホストＣＰＵ内でＩＰソフトウェアによって復号化および／または認証され、ＩＰチェックサムが検証される。次に、受信側のＴＣＰレイヤソフトウェアは、ＴＣＰチェックサムを検証し、セグメント化されたＴＣＰフレームを組み立て直して、上層のレイヤのソフトウェアアプリケーション宛のメッセージにする。しかし、このような従来のシステムでは、ホストのソフトウェアが、レイヤ３とレイヤ４（ＩＰおよびＴＣＰ／ＵＤＰなど）の機能（セグメント化、チェックサム処理、セキュリティ処理など）のすべてとまではいかないが多くを実装する必要がある。これらの機能は通常、多大な演算を必要とし、ホストの処理のオーバーヘッドのかなりの量を要求する。この為、ネットワーク化されたホストシステムの処理負荷を軽減させる改良されたネットワークシステムおよびそのための方法が求められている。
【発明の開示】
【０００９】
以下では、本発明の一部の態様の基本を理解できるように、発明の概要を説明する。この概要は、本発明を広く概観するものではない。また、本発明の主要または重要な要素を特定したり、本発明の範囲を詳細に記載することを意図するものでもない。本概要の主な目的は、後述する詳細な説明に先立ち、本発明の現在の概念の一部を簡潔な形で示すことにある。本発明は、ホストシステムをネットワークにインタフェースするための方法およびシステムに関する。
【００１０】
本発明の一態様は、ホストシステムをネットワークにインタフェースするネットワークインタフェースシステムに関する。このネットワークインタフェースシステムは、バスインタフェースシステム、メディアアクセスコントロールシステム、およびセキュリティシステムを有する。セキュリティシステムは、発信データを選択的に暗号化および認証するように動作可能である。本発明によれば、セキュリティシステムは、発信データの暗号化および認証のためのプロセッサを２つ有する。発信データパケットがプロセッサの一方ずつに交互に送られる。
【００１１】
本発明は、ホストプロセッサのセキュリティ処理の負荷を軽減する際に発生する潜在的なボトルネックを取り除く。従来のセキュリティ処理では、暗号化の後に認証が実行される。このため、受信側では認証と復号化を同時に実行できるのに対し、送信側では認証と暗号化を同時に実行することができない。送信側に複数の並列プロセッサを設けることにより、送信が受信に遅れるのを防ぐ。
【００１２】
本発明の別の態様は、ＩＰｓｅｃ処理を実行するように適合されたセキュリティシステムを有する単一集積回路に関する。このセキュリティシステムは、少なくとも２つの送信ＩＰｓｅｃプロセッサを有する。
【００１３】
上記の目的およびこれに関連する目的を達成するために、以下の詳細な説明および添付の図面では、本発明の特定の例示的な態様および実装を詳細に記載する。これらは、本発明の原理が用いられ得る様々な方法のほんの一部に過ぎない。本発明の他の目的、効果および新しい特徴は、図面を参照して考察すれば、以下の発明の詳細な説明から明らとなるであろう。
【発明を実施するための最良の形態】
【００１４】
図面を参照して本発明の一以上の実装を記載する。図面全体にわたり、同じ参照符号は同じ要素を参照している。
【００１５】
図１Ａは、ホストシステム６をネットワーク８にインタフェースする代表的なネットワークインタフェースシステム２を示しており、ネットワークインタフェースシステム２は、ホストシステム６からネットワーク８に発信データを提供すると共に、ネットワーク８からホストシステム６に着信データを提供するように動作可能である。ネットワークインタフェースシステム２は、ホストシステムのバスを介するなど、ホストシステム６に動作可能に結合できるバスインタフェースシステム４を有しており、バスインタフェースシステム４は、ネットワークインタフェースシステム２とホストシステム６との間でデータを転送するように適合されている。ネットワークインタフェース２のメディアアクセス制御（ＭＡＣ）システム１０は、メディア非依存インタフェース（例えば、ＭＩＩ、ＧＭＩＩなど）対応のトランシーバ（図示せず）を介するなど、ネットワーク８に動作可能に結合でき、ＭＡＣシステム１０は、ネットワークインタフェースシステム２とネットワーク８との間でデータを転送するように動作可能である。バスインタフェースシステム４とＭＡＣシステム１０は、ネットワークインタフェースシステム２との間でデータを転送するように構成されるか構成可能な任意の電気的な回路または部品を使用して作製されうる。より詳細には、システム４，１０は論理素子、アナログ回路、電気コネクタなどのハードウェアの任意の組合せを有することができ、インタフェースシステム２内のソフトウェアおよび／またはファームウェアによってプログラム可能または構成可能である。
【００１６】
ネットワークインタフェース２は、バスインタフェースシステム４およびＭＡＣシステム１０に結合されたメモリシステム１２と、メモリシステム１２に結合されたセキュリティシステム１４とを更に有する。メモリシステム１２は、ネットワーク８とホストシステム６との間で転送される着信データと発信データを記憶する。メモリシステム１２は、第１のメモリであるＭＥＭＯＲＹ  Ａ  １６と第２のメモリであるＭＥＭＯＲＹ  Ｂ  １８を有する。第１のメモリ１６は、セキュリティ処理前の発信データを記憶すると共に、セキュリティ処理後の着信データを記憶するために、バスインタフェースシステム４とセキュリティシステム１４に結合されている。第２のメモリ１８は、セキュリティ処理前の着信データを記憶すると共に、セキュリティ処理後の発信データを記憶するために、ＭＡＣシステム１０とセキュリティシステム１４に結合されている。メモリシステム１２と、その第１のメモリ１６および第２のメモリ１８は、揮発性または不揮発性の任意の形式のメモリ回路であってよく、適切な制御回路を有する先入れ先出し（ＦＩＦＯ）のメモリとして構成されるランダムアクセスメモリ（ＲＡＭ）などであるが、これに限定されない。メモリシステム１２は、第１のメモリ１６と第２のメモリ１８として図示されているが、別個のメモリであっても、第１の記憶領域１６と第２の記憶領域１８に仕切られた一体型のメモリシステムであってもよい。更に、メモリ１６，１８の一方または両方は、着信データと発信データを処理するための別個のメモリ回路を有しても、あるいは着信データと発信データを記憶して、情報を制御するために（例えば静的または動的に）分割された１つのメモリ回路であってもよい。
【００１７】
セキュリティシステム１４は、ネットワークインタフェースシステム２における着信データおよび／または発信データに対するセキュリティ処理を選択的に実行するように構成されているか構成可能である。セキュリティシステム１４は、アナログおよび論理回路など、インタフェースシステム２において着信データおよび／または発信データに対するセキュリティ処理を実行するように構成されているか構成可能な、任意の適切な電子デバイスを使用して作製されうる。一実装形態では、以下により詳細に図示および記載するように、セキュリティシステム１４は、着信データと発信データの認証、暗号化および復号化の各機能を選択的に提供するように適合されたＩＰｓｅｃシステムである。しかし、本発明の範囲内で、ほかの形態のセキュリティシステムやほかの種類のセキュリティ処理も考察される。
【００１８】
ネットワークインタフェースシステム２のシステム４，１０，１２，１４は、任意選択で、ソフトウェアおよび／またはファームウェアによって構成可能またはプログラム可能でありえる。例えば、ネットワークインタフェース２のシステム４，１０，１２，１４の１つ、一部またはすべては、ホストシステム６のソフトウェア、および／またはシステム２中のプログラム済みＥＥＰＲＯＭ、またはＥＥＰＲＯＭインタフェースを介した外部のＥＥＰＲＯＭやシステム２の外部にあるほかのメモリデバイスなどのファームウェアを介して構成されうる。
【００１９】
システム４，１０，１２，１４のそれぞれは、ホストシステム６からの制御またはホストシステム６から取得したその他の種類の情報に従って選択的に動作可能であり、このような情報は、ホストシステム６とネットワーク８との間で処理および／または転送されている１つ以上のデータ部分に関連しうる。例えば、ネットワークインタフェースシステム２は、ネットワーク８に送信しようとしている発信データフレームに関連する制御情報を、ホストシステム６から取得しうる。更に、システム４，１０，１２，１４は、制御、状態またはほかの種類の情報をホストシステム６に提供しうる。
【００２０】
セキュリティシステム１４は、受信ＩＰｓｅｃプロセッサ２２、送信ＩＰｓｅｃ入力データフローコントローラ２８、２つの送信ＩＰｓｅｃプロセッサ２０，２１およびこれらに対応する入力バッファ２６，２７と出力バッファ２４，２５、ならびに送信ＩＰｓｅｃ出力データフローコントローラ３０を有する。入力データフローコントローラ２８は、メモリ１６からデータを読み出し、データパケットを入力バッファ２６，２７に交互に送信する。送信ＩＰｓｅｃプロセッサ２０，２１は、基本的には並列に動作し、各々の対応する入力バッファ２６，２７からデータを読み出し、このデータに対してセキュリティ処理を実行し、処理したデータを各々の対応する出力バッファ２４，２５に書き込む。出力フローコントローラ３０は、処理されたデータを出力バッファ２４，２５から交互に読み出し、メモリ１６から読み出したのと同じ順序で、この処理されたデータを、パケットによりメモリ１８に書き込む。
【００２１】
代表的なネットワークインタフェースシステム２では、データが暗号化されたときに、規則によってこの暗号化されたデータに対して認証が実行されるため、１つの受信ＩＰｓｅｃプロセッサに対し、２つの送信ＩＰｓｅｃプロセッサが使用される。これにより、受信時に、復号化と認証を並列で実行できるようになる。しかし、送信時には、認証が開始できる前に、暗号化されたデータが利用可能となっている必要がある。以下に挙げる例のように、従来の認証アルゴリズムと暗号化アルゴリズムは、再帰的である。この再帰的な性質のため、各データパケットの認証と暗号化にそれぞれ関連するオーバーヘッドと、バイト毎の処理時間を加えたオーバーヘッドが存在する。認証処理と暗号化処理をパイプライン化したとしても、送信側では暗号化と認証のオーバーヘッドが付加される。これらのオーバーヘッドは、特に小さなデータパケットでは処理時間を著しく増大させる。本発明は、並列に動作する送信ＩＰｓｅｃプロセッサを２つ以上用いることにより、受信側の処理速度と釣り合うように、送信側のＩＰｓｅｃ処理時間を短縮する。
【００２２】
図１Ｂは、代表的な送信ＩＰｓｅｃプロセッサ５０の概略図である。代表的なＩＰｓｅｃプロセッサ５０は、送信セキュリティ処理制御モジュール５４、ＥＳＰ認証エンジン５６、ＡＨ認証エンジン５８、およびＥＳＰ暗号化エンジン６０を有する。送信セキュリティ処理制御モジュール５４は、入力バッファ５２からのデータパケットを選択的に、ＥＳＰ認証エンジン５６、ＡＨ認証エンジン５８、およびＥＳＰ暗号化エンジン６０のいずれにも渡さないか、あるいはこれらの１つ以上に渡す。暗号化と認証が要求されている場合、ＥＳＰ暗号化エンジンの出力は認証エンジンの１つ以上に送られる。代表的なＩＰｓｅｃプロセッサ５０は、パケットに対してＥＳＰ認証とＡＨ認証を実行することができ、両者を実行する場合は並列に実行する。処理が終了すると、処理されたデータは出力バッファ６２に置かれる。
【００２３】
各エンジンは、それぞれの機能のための専用のハードウェアを有する。更に、各エンジンは、それぞれが同じ速度でデータを処理する複数の直列のステージを有する。エンジンに供給される一連のデータは、エンジンの先頭から終わりまで一連のステージを通過していくため、ある意味において、パイプラインとみなすことができる。直列のステージの全てが、別のデータブロックに対して同時に動作中の可能性がある。パイプラインでは、集中処理装置を使用する場合と比べて遙かに高速のデータ処理が可能となる。
【００２４】
図１Ａの入力バッファ２６，２７と出力バッファ２４，２５のサイズおよび構成は、適切であればどのようなサイズおよび構成であってもよい。例えば、バッファサイズは約３２バイト〜約１０２４バイトであってよく、好ましいサイズは２５６バイトである。バッファは、２つの別個のメモリであっても、パーティション化された１つのメモリであってもよい。好ましくは、バッファは、十分なサイズを有しており、これにより、ネットワークインタフェースシステム１２が、ＩＰｓｅｃ処理のオーバーヘッドが大きな一連の短いデータパケットを送信中の場合に、送信ＩＰｓｅｃプロセッサ２０，２１の両方が、連続動作を続けることができる。
【００２５】
入力データフローコントローラ２８は、送信するデータパケットをメモリ１６から読み出し、このパケットを、２つのＩＰｓｅｃプロセッサ２０，２１の入力バッファ２６，２７に交互に送る。図１Ｃは、入力データフローコントローラ２８の例示的な処理手順７０を示すフローチャートである。フローコントローラ２８は、入力バッファ２６と２７とを切り替えるため、ある時点において、“カレントの”バッファが１つしか存在しない。手順はブロック７１で始まり、フローコントローラ２８が、送信すべきデータがメモリ１６にあるかを確認する。データがない場合、コントローラ２８はブロック７２において待機してから、再度確認する。あるいは、データが送信待機中のときは、別のプロセッサまたは回路がコントローラ２８に対してこれを通知する。
【００２６】
大きなデータパケットを送信する際には、入力バッファが一杯になる可能性がある。このため、ブロック７３において、コントローラ２８は、カレントバッファに空きがあるかを確認してから、ブロック７５で、メモリ１６からデータブロックを読み出し、ブロック７６で、このデータをカレントバッファに書き込む。入力バッファが一杯になっている場合、コントローラ２８はブロック７４で待機してから、ブロック７３で再度空きがあるかを確認する。ブロック７６でカレントバッファにデータを書き込んだら、ブロック７７において、コントローラ２８は、パケットの最後に達しているかどうかを確認する。パケットの最後に達している場合、ブロック７８においてカレントバッファが切り換えられ、コントローラ２８はブロック７１に進んで、次のデータパケットを探す。最後に達していない場合、コントローラはブロック７３に戻り、メモリ１６から別のデータブロックを読み出す準備をする。例示的な処理手順７０では、パケット全体がカレントバッファに送られてから、別のバッファへの切り替えが行われる。
【００２７】
出力データフローコントローラ３０は、処理されたデータを出力バッファ２４，２５から読み出して、この処理済みデータをメモリ１８に書き込む。図１Ｄは、出力データフローコントローラ３０の例示的な処理手順８０を示すフローチャートである。フローコントローラ３０は、出力バッファ２４と２５とを切り替えるため、ある時点において、“カレントの”バッファが１つしか存在しない。
【００２８】
出力フローコントローラ３０は、送信ＩＰｓｅｃプロセッサ２４，２５より高速に動作することができ、このため、ブロック８１において、出力フローコントローラ３０は、カレント出力バッファにデータがあるかを確認することで処理を開始する。データがある場合、コントローラ３０は、ブロック８３でカレント出力バッファからデータブロックを読み出して、ブロック８４でこのデータをメモリ１８に書き込む。ブロック８５において、コントローラ３０は、パケットの最後に達しているかどうかを確認する。パケットの最後に達している場合、コントローラ３０はブロック８６でカレント出力バッファを切り換え、ブロック８１で更にデータを読み出す準備をする。最後に達していない場合、ブロック８１において、コントローラ３０はカレント出力バッファからのデータの読み出しを続ける。処理手順８０では、パケット全体が一方の出力バッファから読み出されて、メモリ１８に書き込まれてから、もう一方の出力バッファから次のパケットが読み出される。
【００２９】
このため、本発明は、セキュリティ処理の負荷を軽減することによって、ネットワーク８とホストシステム６との間で、着信データと発信データの迅速な転送および処理を可能にする。更に、送信ＩＰｓｅｃプロセッサを２つ設けることによって、ＩＰｓｅｃ処理を高速化する。本発明を完全に理解できるように、図２〜４を参照して、本発明の代表的なネットワークコントローラの構造／機能および動作の概要を以下に説明する。本発明の代表的な一態様によれば、上記の特徴により、ギガビットのワイヤスピードおけるセキュリティ処理とのネットワークインタフェースの動作が容易となり有利である。
【００３０】
図２は、本発明の１つ以上の態様によるネットワークインタフェース周辺装置またはネットワークコントローラ１０２を示し、図３，４は、ネットワークコントローラ１０２の代表的なシングルチップの実装１０２ａを示す。代表的なシングルチップネットワークコントローラ１０２ａは、ネットワークインタフェースシステム１０２に関してここに記載した機能および構成要素をすべて備えている。ここに記載した様々なブロック、システム、モジュール、エンジン等は、適切なアナログおよび／またはデジタル回路であればどのようなものを使用しても実装することができ、ここに記載したブロックなどの１つ以上が、本発明に従ってほかの回路と組み合わされてもよい。
【００３１】
ネットワークコントローラ１０２は、ホストＰＣＩバスまたはＰＣＩ−Ｘバス１０６に接続するため、ＰＣＩ−Ｘモードで最大１３３ＭＨｚまたは標準ＰＣＩモードで最大６６ＭＨｚのクロックスピードで動作する６４ビットＰＣＩ−Ｘバスインタフェース１０４を有する。ネットワークコントローラ１０２は、バスマスタまたはスレーブとして動作することができる。初期化の多くは、ネットワークコントローラ１０２が、例えばＥＥＰＲＯＭインタフェース１１４（図３）を介して、任意選択のＥＥＰＲＯＭ（図示せず）を読み出したときに、ネットワークコントローラ１０２によって自動的に実行されうる。ネットワークコントローラ１０２は、外部トランシーバデバイス１１１を介してコントローラ１０２をネットワーク１０８にインタフェースするために、ＩＥＥＥ８０２．３に準拠したＭＩＩ（Media Independent Interface）またはＧＭＩＩ（Gigabit Media Independent Interface）１１０を介して、ＩＥＥＥ８０２．３または専用ネットワーク１０８に接続されうる。コントローラ１０２は、１０００Ｍｂ／秒での動作を実現するために、１０００ＢＡＳＥ−Ｔ  ＰＨＹデバイス１１１のためにバイト幅ＩＥＥＥ８０２．３  ＧＭＩＩ（Gigabit Media Independent Interface）に、または１０００ＢＡＳＥ−Ｘデバイス１１１のためにＩＥＥＥ８０２．３  ＴＢＩ（Ten-Bit Interface）に対応している。ネットワークコントローラ１０２は、１０Ｍｂ／秒および１００Ｍｂ／秒の速度で全二重通信と半二重通信に、１０００Ｍｂ／秒の速度で全二重通信に対応している。
【００３２】
ホストシステム１８０のホストＰＣＩ−Ｘバス１０６のホストプロセッサ１１２などのホストデバイスは、バス１０６とホストブリッジ１１７を介してネットワークコントローラ１０２とインタフェースしうる。ホストプロセッサ１１２は、１つ以上のプロセッサを有し、これらは連係して動作することができる。図４も参照すると、ネットワークのシングルチップネットワークコントローラ１０２ａはＰＨＹトランシーバ１１１と共にネットワークインタフェースカードまたは回路基板１８２に設けられてもよく、ホストブリッジ１１７、ホストバス１０６およびトランシーバ１１１を介してホストプロセッサ１１２をネットワーク１０８にインタフェースする。ＰＣＩ−Ｘバスインタフェース１０４は、ＰＣＩバス上の他のデバイスに対してネットワークコントローラ１０２ａを識別させたり、同デバイスを構成するために使用するＰＣＩ構成レジスタを有する。初期化が終了すると、ホストプロセッサ１１２は、性能のチューニング、オプションの選択、統計値の収集、ホストブリッジ１１７およびバス１０６を介した送信の開始のために、ネットワークコントローラ１０２の入出力レジスタにダイレクトアクセスすることができる。ホストプロセッサ１１２は、メモリ／キャッシュコントローラ１１３を介して、ホストシステムメモリ１２８とキャッシュメモリ１１５とに動作可能に結合されている。ホストプロセッサ１１２で実行されている１つ以上のアプリケーションソフトウェアプログラム１８４は、同様にホストプロセッサ１１２で実行されている、レイヤ４（例えばトランスポート層）のソフトウェア（伝送制御プロトコル（ＴＣＰ）レイヤソフトウェア１８６等）と、レイヤ３（例えばネットワーク層）のソフトウェア１８８（インターネットプロトコル（ＩＰ）ソフトウェア１８８等）、およびソフトウェアネットワークドライバ１９０を介して、ネットワークサービスを提供されうる。後述するように、ネットワークドライバソフトウェア１９０は、アプリケーションソフトウェア１８４とネットワーク１０８との間のデータ転送を容易にするために、ホストメモリ１２８およびネットワークコントローラ１０２と対話する。
【００３３】
図２に示すように、代表的なネットワークコントローラ１０２は、フレームを記憶するために先入れ先出し方式（ＦＩＦＯ）のメモリとして構成された第１および第２の内部ランダムアクセスメモリＭＥＭＯＲＹ  Ａ  １１６，ＭＥＭＯＲＹ  Ｂ  １１８を有する。メモリ１１６，１１８の制御および操作のため、メモリ制御ユニット１２０が提供されている。ネットワークコントローラ１０２は、イーサネット／ＩＥＥＥ８０２．３準拠のノードとして動作するための要件を満たし、メモリ１１８とＧＭＩＩ  １１０の間をインタフェースするためのメディアアクセス制御（ＭＡＣ）エンジン１２２も有する。ＭＡＣエンジン１２２は、全二重モードで動作しても半二重モードで動作してもよい。メモリ１１６，１１８に結合されたインターネットプロトコルセキュリティ（ＩＰｓｅｃ）エンジン１２４は、認証機能および／または暗号化機能を提供する。
【００３４】
ＰＣＩ−Ｘバスインタフェース１０４は、ホストバス１０６を介してネットワークコントローラ１０２とホストシステムメモリ１２８のバッファとの間でネットワークフレームデータを自動的に転送するダイレクトメモリアクセス（ＤＭＡ）コントローラ１２６を有する。ＤＭＡコントローラ１２６の動作は、記述子管理ユニット１３０によって、記述子１９２と呼ばれるデータ構造に従って指示され、記述子１９２は、制御情報のほかに、システムメモリ１２８内の１つ以上のデータバッファ１９４へのポインタを有している。記述子１９２は、ホストシステムメモリ１２８内の、記述子リングと呼ばれるキューに記憶される。フレームの送信用に４つの送信記述子リングが、フレームの受信用に４つの受信記述子リングが設けられており、これらは、図中のコントローラ１０２におけるネットワークトラフィックの４つの優先度に対応している。更に、ネットワークコントローラ１０２とホストシステムとの間の同期を容易にするために４つの受信状態リングが設けられており、その各々が各優先レベルに対応している。送信記述子１９２は、システムメモリ１２８からコントローラ１０２へのフレームデータの転送を制御し、受信記述子１９２は、フレームデータの逆方向の転送を制御する。代表的なコントローラ１０２では、送信記述子１９２の各々が１つのネットワークフレームに対応しているのに対し、受信記述子１９２の各々は、ネットワーク１０８から受信したフレームを記憶可能な１つ以上のホストメモリバッファに対応している。
【００３５】
ソフトウェアインタフェースが、記述子１９２、受信側状態およびデータバッファ１９４に対して、隣接するメモリブロックを割り当てる。これらのメモリブロックは、通常のネットワーク操作中は、ソフトウェア（ネットワークドライバ１９０など）とネットワークコントローラ１０２によって共有されている。記述子空間は、バッファ１９４にあるネットワークフレームデータへのポインタを記憶しており、受信側状態空間はコントローラ１０２からホスト１１２のソフトウェアに渡された情報を記憶しており、データバッファ領域１９４は、送信すべきフレームデータ（発信データなど）および受信されたフレームデータ（着信データなど）を記憶する。
【００３６】
コントローラ１０２とホストプロセッサ１１２との間の同期は、コントローラ１０２のハードウェアレジスタ１３２に記憶されたポインタ、ホストシステムメモリ１２８のコントローラ状態ブロック（ＣＳＢ）１９６に記憶されたポインタ、および割込みによって維持される。ＣＳＢ１９６は、記述子および状態リングへのポインタと、コントローラの割込みレジスタの内容のコピーとを記憶しているホストシステムメモリ１２８のブロックである。ＣＳＢ１９６は、ネットワークコントローラ１０２によって書き込まれ、ホストプロセッサ１１２によって読み出される。ホスト１１２のソフトウェアドライバ１９０が記述子または記述子の組１９２を記述子リングに書き込むたびに、ソフトウェアドライバ１９０は、コントローラ１０２の記述子書込みポインタレジスタにも書き込む。このレジスタに書き込むことで、送信が既に実行中でなければ、コントローラ１０２に対して、送信プロセスを開始させることができる。コントローラは、送信記述子１９２の処理を完了すると、ＣＳＢ１９６にその情報を書き込む。コントローラ１０２は、ネットワークフレームを受信して、ホストシステムメモリ１２８の受信バッファ１９４にそれを記憶したら、受信状態リングおよび書込みポインタに書き込むが、これらは、どの受信バッファ１９４が一杯になっているかを判定するためにドライバソフトウェア１９０によって使用される。受信フレーム中の誤りは、状態ジェネレータ１３４を介してホストメモリ１２８に報告される。
【００３７】
ＩＰｓｅｃモジュールまたはエンジン１２４は、送信フレームと受信フレームに対し、標準の認証、暗号化および復号化の機能を提供する。認証については、ＩＰｓｅｃモジュール１２４は、ＲＦＣ２４０３（インターネットエンジニアリングタスクフォースが策定した仕様の組）に規定されているＨＭＡＣ−ＭＤ５−９６アルゴリズム、およびＲＦＣ２４０４に規定されているＨＭＡＣ−ＳＨＡ−１−９６アルゴリズムを実装している。暗号化については、ＩＰｓｅｃモジュールは、ＥＳＰ  ＤＥＳ−ＣＢＣ（ＲＦＣ２４０６）、３ＤＥＳ−ＣＢＣおよびＡＥＳ−ＣＢＣの暗号化アルゴリズムを実装している。コントローラ１０２は、送信フレームに対し、プライベートなローカルＳＡメモリ１４０に記憶されているセキュリティアソシエーション（ＳＡ）によって指定されているように、ＩＰｓｅｃ認証および／または暗号化を適用するが、このＳＡメモリ１４０には、ＩＰｓｅｃシステム１２４はＳＡメモリインタフェース１４２を介してアクセスする。ＳＡは、ホストプロセッサ１１２によってネゴシエートおよび設定される。ＳＡは、認証、暗号化および復号化の各種アルゴリズムが要求するＩＰｓｅｃキーを有しており、ＩＰｓｅｃキー交換処理がホストプロセッサ１１２によって実行される。ホスト１１２は、遠隔局とＳＡをネゴシエートし、ＳＡのデータをＳＡメモリ１４０に書き込む。また、ホスト１１２は、ホストシステムメモリ１２８に、ＩＰｓｅｃセキュリティポリシーデータベース（ＳＰＤ）も維持管理している。
【００３８】
受信（ＲＸ）パーサ１４４は、ＭＡＣエンジン１２２に結合されており、受信フレームのヘッダを調べて、実行が必要な処理を決定する。受信パーサ１４４は、ＩＰｓｅｃヘッダを見つけると、セキュリティパラメータインデックス（ＳＰＩ）、ＩＰｓｅｃプロトコルタイプ、およびＩＰ宛先アドレスなど、ヘッダに格納されている情報によって、ＳＡルックアップロジック１４６を使用してＳＡメモリ１４０を検索し、適用可能なセキュリティアソシエーションを取得する。この結果が、ＳＡメモリインタフェース１４２を介してルックアップロジック１４６に結合されたＳＡポインタＦＩＦＯメモリ１４８に書き出される。このＳＡに対応するキーが取得されて、受信キーＦＩＦＯ１５２に記憶される。受信（ＲＸ）ＩＰｓｅｃプロセッサ１５０は、このキーを使用して、適用可能なＳＡによって要求されている処理を実行する。コントローラ１０２は、実行したセキュリティ処理を報告し、これにより、ホスト１１２は、ＳＰＤを確認して、フレームがポリシーに適合していることを検証することができる。処理されたフレームは、メモリ１１６に記憶される。
【００３９】
受信ＩＰｓｅｃパーサ１５４は、ＩＰｓｅｃプロセッサ１５０に結合されており、パケットを復号化する前に実行することができない構文解析を実行する。この情報の一部は、受信（Ｒｘ）チェックサムおよびパッドチェックシステム１５６によって使用され、システム１５６は、暗号化されている可能性のあるヘッダによって指定されているチェックサムを計算し、暗号化されている可能性のあるパッドビットを確認して、これらが、パッドビットの所定のシーケンスに従っていることを検証する。これらの操作は、受信フレームがＦＩＦＯ１５８を介してＰＣＩ−Ｘバス１０４に渡される間に行われる。チェックサムとパッドのチェックの結果は、状態ジェネレータ１３４に報告される。
【００４０】
送信経路において、システムメモリ１２８からフレームデータを受け取ると共に、メモリ１１６にデータを渡すため、組立ＲＡＭ１６０が設けられている。送信フレームの内容は、ホストメモリ１２８の複数のデータバッファ１９４に散らばっている可能性があり、その場合、フレームの取得の際に、記述子管理ユニット１３０によって、システムメモリ１２８に対して複数の要求が発行されうる。これらの要求は、必ずしも発行された順序で応答が得られるわけではない。組立ＲＡＭ１６０を設けることで、受信したデータの塊が、メモリ１１６内で適切な位置に確実に置かれるようになる。ホスト１１２は、送信されたフレームについて、ＳＰＤ（ＩＰｓｅｃセキュリティポリシーデータベース）をチェックして、必要なセキュリティ処理を決定し、この情報を、フレームの記述子１９２において、ＳＡメモリ１４０内の適切なＳＡへのポインタとして、コントローラ１０２に渡す。ホストシステムメモリ１２８にあるフレームデータは、認証データ用にＩＰｓｅｃヘッダおよびトレーラ内の空間を提供し、これは、コントローラ１０２によって生成される。同様に、フレームがホストシステムメモリのバッファ１９４に記憶されている場合、パディング（ペイロードを整数個のブロックにするために用いられる）のための空間が提供されるが、パッドビットはコントローラ１０２によって書き込まれる。
【００４１】
データが組立ＲＡＭ１６０から送られる際に、このデータは、第１の送信（ＴＸ）パーサ１６２にも入り、送信パーサ１６２は、ＭＡＣヘッダ、ＩＰヘッダ（存在する場合）、ＴＣＰまたはＵＤＰヘッダを読み出して、フレームの種類を決定し、関連する記述子内の制御ビットを調べる。更に、組立ＲＡＭ１６０からのデータは、ＩＰヘッダおよび／またはＴＣＰのチェックサムを計算するために、送信チェックサムシステム１６４に提供され、このチェックサムの値はメモリ１１６の適切な位置に挿入される。記述子管理ユニット１３０は、ＳＡキーを取得するためにＳＡメモリインタフェース１４２に要求を送り、ＳＡキーが、送信ＩＰｓｅｃプロセッサの対１７４ａ，１７４ｂに出力しているキーＦＩＦＯ１７２に提供される。フレームが、暗号化および認証のために、送信ＩＰｓｅｃプロセッサの対１７４ａ，１７４ｂのいずれかに、それぞれ送信ＩＰｓｅｃ  ＦＩＦＯ１７６ａまたは１７６ｂを介して選択的に供給され、その際、送信ＩＰｓｅｃパーサ１７０は、選択されたほうのプロセッサ１７４にメモリ１１６からフレームデータを選択的に供給する。暗号化処理が実行中になるまで、認証処理を開始できないため、２つの送信ＩＰｓｅｃプロセッサ１７４が並列に設けられている。２つのプロセッサ１７４を使用することにより、この２つの処理が同時に実行可能なときは、処理速度が受信側と同程度となる。
【００４２】
認証は、ＩＰヘッダに存在するような可変のフィールドには適用されない。したがって、送信ＩＰｓｅｃパーサ１７０は、フレームデータ中で可変フィールドを探し、これらのフィールドをプロセッサ１７４ａ，１７４ｂに特定する。プロセッサ１７４ａ，１７４ｂの出力は、ＦＩＦＯ１７８ａ，１７８ｂをそれぞれ介して第２のメモリ１１８に供給される。ネットワーク１０８に送信するために、フレームデータが、メモリ１１８からＭＡＣエンジン１２２に渡される際に、認証処理で得られた整合性確認値（Integrity Check Value：ＩＣＶ）が、挿入ユニット１７９によって適切なＩＰｓｅｃヘッダに挿入される。
【００４３】
図３のシングルチップの実装では、コントローラ１０２ａは、ネットワークポートマネージャ１８２を有し、ネットワークポートマネージャ１８２は、管理データクロック（ＭＤＣ）信号および管理データＩ／Ｏ（ＭＤＩＯ）信号によって、外部の物理（ＰＨＹ）トランシーバと自動的にネゴシエートしうる。また、ネットワークポートマネージャ１７５は、ネゴシエートされた構成に従うようにＭＡＣエンジン１２２を設定しうる。ＬＥＤコントローラ１７１によってＬＥＤインジケータ用の回路基板インタフェースが提供され、ＬＥＤコントローラ１７１は、アクティブリンク接続、ネットワーク上の送信または受信の活動、ネットワークのビットレート、およびネットワーク衝突などの、様々なネットワーク状態情報を示すＬＥＤドライバ信号ＬＥＤＯ’〜ＬＥＤ３’を生成する。クロック制御ロジック１７３は、タイミング基準として自走１２５ＭＨｚ入力クロック信号を受け取り、様々なクロック信号をコントローラ１０２ａの内部のロジックに供給する。
【００４４】
電力管理ユニット１８８が、記述子管理ユニット１３０とＭＡＣエンジン１２２に結合されており、デバイスが非活動状態にある場合に電力を節約するために使用されうる。電力管理ユニット１８８は、ＭＡＣエンジン１２２を介したリンクの変化など、電力レベルを変更する必要がある事象が検出されると、電力管理事象が発生したことを示す信号ＰＭＥ’を供給する。外部シリアルＥＥＰＲＯＭインタフェース１１４は、９３Ｃｘｘ  ＥＥＰＲＯＭインタフェースプロトコルなどの標準的なＥＥＰＲＯＭインタフェースを実装している。外部シリアルＥＥＰＲＯＭインタフェース１１４のリードは、ＥＥＰＲＯＭチップ選択（ＥＥＣＳ）ピン、ＥＥＰＲＯＭデータイン（ＥＥＤＩ）とデータアウト（ＥＥＤＯ）ピン、およびＥＥＰＲＯＭシリアルクロック（ＥＥＳＫ）ピンを有する。
【００４５】
バスインタフェースユニット１０４では、アドレスとデータが、バスインタフェースピンＡＤ［６３:０］上に多重化されている。リセット入力ＲＳＴ’は、ネットワークコントローラ１０２ａに、内部システムのリセットを実行させる際にアサートされうる。サイクルフレームＩ／Ｏ信号ＦＲＡＭＥ’は、ネットワークコントローラがバスマスタである場合に、トランザクションが開始されたこと、およびトランザクション中であることを示すため、ネットワークコントローラによって駆動され、ＰＣＩクロック入力ＰＣＩ＿ＣＬＫは、ＰＣＩバス（例えばホストバス１０６）上で１５〜１３３ＭＨｚの周波数範囲でシステムバスインタフェースを駆動するために使用される。ネットワークコントローラ１０２ａは、６４ビットアドレッシングシステムのためのデュアルアドレスサイクル（ＤＡＣ）に対応しており、第１のクロックサイクル中に下位アドレスビットがＡＤ［３１:０］バスに出力され、第２のクロックサイクル中に上位ビットがＡＤ［６３:３２］に出力される。ＲＥＱ６４’信号は、バスマスタとして動作しているデバイスが６４ビットでのデータ転送の開始を要求する場合にアサートし、ターゲットデバイスは、６４ビット転送アクノレッジ信号ＡＣＫ６４’をアサートし、６４ビットでデータを転送可能なことを示す。パリティ信号ＰＡＲ６４は、ＡＤ［６３:３２］を保護する８バイトの偶数パリティ信号である。バスマスタは、アドレスおよびデータ書込みフェーズ中にＰＡＲ６４を駆動し、ターゲットデバイスは、データ読出しフェーズ中にＰＡＲ６４を駆動する。
【００４６】
ネットワークコントローラ１０２ａは、バスマスタになることを要求していることを示すためにバス要求信号ＲＥＱ’をアサートし、バス許可入力信号ＧＮＴ’は、ネットワークコントローラに、バスへのアクセスが許可されたことを示す。初期化デバイス選択入力信号ＩＤＳＥＬは、構成の読出しおよび書込みのトランザクション中に、ネットワークコントローラのためのチップ選択として使用される。バスコマンドおよびバイトイネーブル信号Ｃ／ＢＥ［７:０］は、バスコマンドを転送し、データラインＡＤ［６３:０］のどの物理バイトに意味のある（meaningful）データが出力されているかを示すために使用される。パリティＩ／Ｏ信号ＰＡＲは、ＡＤ［３１:０］とＣ／ＢＥ［３:０］の全体の偶数パリティを示し検証する。
【００４７】
ネットワークコントローラは、ネットワークコントローラ１０２ａをターゲットとして選択しているトランザクションを検出すると、ドライブセレクトＩ／Ｏ信号ＤＥＶＳＥＬ’を駆動する。ネットワークコントローラ１０２ａは、ＤＥＶＳＥＬ’をチェックして、ネットワークコントローラが開始したトランザクションをターゲットが要求しているかどうかを調べる。ＴＲＤＹ’は、トランザクションのターゲットが、現在のデータフェーズを完了できることを示すために使用され、ＩＲＤＹ’は、トランザクションのイニシエータが現在のデータフェーズを完了できることを示す。割込み要求出力信号ＩＮＴＡ’は、有効な割込みフラグビットが１つ以上セットされていることを示す。ネットワークコントローラ１０２ａは、データパリティエラーを検出するとパリティエラーＩ／Ｏ信号ＰＥＲＲ’をアサートし、アドレスパリティエラーを検出するとシステムエラー出力信号ＳＥＲＲ’をアサートする。更に、コントローラ１０２ａは、停止Ｉ／Ｏ信号ＳＴＯＰ’をアサートして、現在のトランザクションを中止するようにバスマスタに通知する。
【００４８】
ＭＡＣエンジン１２２において、物理インタフェースリセット信号ＰＨＹ＿ＲＳＴは、外部ＰＨＹ１１１（ＭＩＩ、ＧＭＩＩ、ＴＢＩ）をリセットするために使用され、ＰＨＹループバック出力ＰＨＹ＿ＬＰＢＫは、システムテストのため、外部のＰＨＹデバイス１１１を強制的にループバックモードに移行させるために使用され、フロー制御入力信号ＦＣは、ＭＡＣがフロー制御フレームを送信するタイミングを制御する。ネットワークコントローラ１０２ａは、ＩＥＥＥ規格８０２．３のＭＩＩ（Media Independent Interface）、ＧＭＩＩ（Gigabit Media Independent Interface）またはＴＢＩ（Ten Bit Interface）と互換の外部ＰＨＹインタフェース１１０を提供している。受信データ入力信号ＲＸＤ［７:０］および出力信号ＴＸＤ［７:０］は、それぞれ受信および送信のデータ交換に用いられる。ＴＸ＿ＥＮ／ＴＸＤ［８］は、ネットワークコントローラ１０２ａがＧＭＩＩモードまたはＭＩＩモードで動作しているときに、送信イネーブルとして使用される。ＴＢＩモードでは、この信号は送信データバスのビット８である。ＲＸ＿ＤＶ／ＲＸＤ［８］は、有効な受信データがＲＸピンに出力されていることを示すのに用いられる入力である。ＴＢＩモードでは、この信号は、受信データバスのビット８である。
【００４９】
ＲＸ＿ＥＲ／ＲＸＤ［９］は、ネットワークコントローラ１０２ａがＧＭＩＩモードまたはＭＩＩモードで動作しているときに、ＲＸＤピンに現在転送中の受信フレーム内に、外部トランシーバデバイスが符号化エラーを検出したことを示す入力である。ＴＢＩモードでは、この信号は、受信データバスのビット９である。ＭＩＩ送信クロック入力ＴＸ＿ＣＬＫは、ＭＩＩモードにおいて、ネットワークコントローラ１０２ａからのＴＸ＿ＥＮ信号とＴＸＤ［３:０］信号の転送のためのタイミング基準を提供する連続クロック入力である。ＧＴＸ＿ＣＬＫは、デバイスがＧＭＩＩモードまたはＴＢＩモードで動作しているときに、ネットワークコントローラからのＴＸ＿ＥＮ信号およびＴＸＤ信号のタイミング参照を提供する１２５ＭＨｚの連続クロック出力である。ＲＸ＿ＣＬＫは、デバイスがＭＩＩモードまたはＧＭＩＩモードで動作しているときに、ネットワークコントローラへの信号の転送のためのタイミング基準を提供するクロック入力である。ＣＯＬは、ネットワーク媒体上で衝突が検出されたことを示す入力であり、キャリア検知入力信号ＣＲＳは、送信または受信の活動により、非アイドルの媒体が検出されたことを示す（デバイスが全二重モードで動作している場合ＣＲＳは無視される）。ＴＢＩモードでは、１０ビットの符号群が８ビットのデータパケットを表す。１０ビット符号群の一部は、コマンドを表すために使用される。偶数の符号群と奇数の符号群、およびコンマと呼ばれる特別なシーケンスの出現は、全てＰＨＹ１１０と同期をとり、同期を維持するために使用される。ＲＢＣＬＫ［０］はＰＨＹデバイスからの奇数の符号群をラッチするために使用される６２．５ＭＨｚのクロック入力であり、ＲＢＣＬＫ［１］は偶数の符号群をラッチするために使用される。ＲＢＣＬＫ［１］は、ＲＢＣＬＫ［０］に対して常に１８０度位相がずれている。ＣＯＭ＿ＤＥＴは、ＲＸＤ［９:０］入力の符号群に有効なコンマが含まれることを示すために、外部ＰＨＹ１１１によってアサートされる。
【００５０】
ＩＰｓｅｃモジュール１２４は、メモリ１１６，１１８への外部ＲＡＭインタフェースを有する。ＣＫＥがｈｉｇｈ（ハイ）に駆動されている場合は、内部ＲＡＭクロックが同期をとるのに使用され、そうではない場合、差動クロック入力ＣＫおよびＣＫ＿Ｌが使用される。ＲＡＭは命令デコーダを有しており、チップ選択出力ＣＳ＿Ｌがｌｏｗ（ロー）に駆動されると命令デコーダが起動される。ＷＥ＿Ｌ、ＲＡＳ＿ＬおよびＣＡＳ＿Ｌの各ピンのパターンにより、ＲＡＭに発行中のコマンドが定義される。バンクアドレスは出力信号ＢＡ［１:０］は、コマンドを適用するメモリを選択するために使用され、ＲＡＭアドレス出力ピンＡ［１０:０］によって供給されるアドレスは、ＲＡＭのアクセス対象のワードを選択している。ＲＡＭデータストローブＩ／Ｏ信号ＤＱＳは、データの読出しまたは書込みが可能なタイミングを示し、ＲＡＭデータ入出力ピンＤＱ［３１:０］上のデータが、メモリ１１６または１１８との間で書込みまたは読出しが行われる。
【００５１】
図２に戻り、ネットワークコントローラの受信操作と送信操作の操作について以下に説明する。ネットワーク媒体１０８（光ファイバ等）からデータフレームを受信すると、フレームが、例えば、並列に一連のバイトまたはワードとして、ＧＭＩＩ  １１０（Gigabit Media−Independent Interface）に伝達される。ＧＭＩＩ  １１０はインタフェースプロトコルに従ってフレームをＭＡＣ１２２に渡し、ＭＡＣ１２２は、フレーム管理機能の一部を行う。例えば、ＭＡＣ１２２は、フレーム間の間隔を特定したり、半二重の問題や衝突、再試行を処理したり、その他の標準のイーサネット機能（例えばアドレスの比較およびチェックサム計算の一部）を実行する。また、ＭＡＣ１２２は、フレームをフィルタリングして、その宛先アドレスを確認し、確立された規則セットに従ってフレームを受け付けるかあるいは拒否する。
【００５２】
ＭＡＣ１２２は、ＩＰｖ４およびＩＰｖ６のヘッダなど、幾つかのヘッダフォーマットを受け付けて、構文解析しうる。ＭＡＣ１２２は、フレームヘッダから特定の情報を取り出す。ＭＡＣ１２２は、取り出した情報に基づいて、幾つかの優先度キュー（図示せず）のうちの、どのキューにフレームを入れるかを決定する。ＭＡＣは、フレーム長、および優先度情報などの一部の情報をフレームの前方の制御ワードに入れ、チェックサムの合否などのその他の情報をフレームの後方の状態ワードに入れる。フレームはＭＡＣ１２２を通り、メモリ１１８（３２ＫＢのＲＡＭなど）に記憶される。本例では、フレームの全体がメモリ１１８に記憶される。その後、フレームは、システムメモリ１２８内の所定の位置（この位置は、記述子管理ユニット１３０によって、ホストメモリ１２８内の記述子１９２（図４）に従って決定される）にダウンロードされ、その際、受信記述子１９２はそれぞれ、システムメモリ１２８内のデータバッファ１９４へのポインタを有している。送信記述子は、上記に詳しく記載するように、ポインタまたはポインタのリストを有している。記述子管理ユニット１３０は、ＤＭＡ１２６を使用して受信記述子１９２を読み出し、バッファ１９４へのポインタを取得する。フレームがシステムメモリ１２８に書き込まれると、状態ジェネレータ１３４は、状態ワードを作成して、その状態ワードをシステムメモリ１２８の別の領域に書き込むが、その領域は本例では状態リングである。次に、状態ジェネレータ１３４は、プロセッサ１１２に割込みをかける。これにより、システムソフトウェア（図４のネットワークドライバ１９０など）は、既にシステムメモリ１２８に存在している状態情報を確認することができる。この状態情報には、例えば、フレーム長、実行された処理、各種チェックサムの合否の情報が含まれる。
【００５３】
送信操作では、ホストプロセッサ１１２は、まず、ネットワーク１０８を介したフレームの送信を指示し、ホストプロセッサ１１２のオペレーティングシステム（ＯＳ）のＴＣＰレイヤ１８６が起動されて、宛先との接続を確立する。次に、ＴＣＰレイヤ１８６は、ＴＣＰフレームを作成するが、これは非常に大きいものである可能性があり、データパケットとＴＣＰヘッダを含む。ＩＰレイヤ１８８によってＩＰヘッダが作成されて、イーサネット（ＭＡＣ）ヘッダも作成され、その際、データパケットと、ＴＣＰヘッダ、ＩＰヘッダおよびＭＡＣヘッダとが、ホストメモリ１２８の様々な位置に記憶されうる。次に、ホストプロセッサ１１２のネットワークドライバ１９０は、データパケットとヘッダから送信フレームを作成し、このフレームが、ホストメモリ１２８の１つ以上のデータバッファ１９４に記憶される。例えば、代表的な送信フレームは４つのバッファ１９４に存在しており、１番目のバッファはイーサネットヘッダまたはＭＡＣヘッダを記憶し、２番目のバッファはＩＰヘッダを記憶し、３番目のバッファはＴＣＰヘッダを記憶し、４番目のバッファはデータを記憶しうる。ネットワークドライバ１９０は、これらのデータバッファ１９４の全てへのポインタのリストを含む送信記述子１９２を生成する。
【００５４】
フレームデータが、バッファ１９４からコントローラ１０２に読み出される。この読出しを実行するために、記述子管理ユニット１３０は送信記述子１９２を読み出し、ＤＭＡコントローラ１２６を使用して、ホストバス１０６に対して、一連の読出し要求を発行する。しかし、要求したデータの一部分が、要求された順序で到着するとは限らず、ＰＣＩ−Ｘインタフェース１０４は、データに関連している要求をＤＭＵ１３０に示す。組立ＲＡＭロジック１６０は、その情報を使用することによって、データを編成して、適切な順序に並べてフレームを復元し、データの様々な断片をつなぎ合わせて、隙間を除去するために、ある種のパッキング処理を実行することもある。フレームが組立ＲＡＭ１６０において組み立てられると、メモリ１１６（例えば、図示した例では３２ＫＢのＲＡＭ）に渡される。データは、組立ＲＡＭ１６０から渡される際に、送信パーサ１６２にも渡される。送信パーサ１６２は、ＭＡＣヘッダ、ＩＰヘッダ（存在する場合）ＴＣＰまたはＵＤＰヘッダなどのヘッダを読んで、フレームの種類を決定し、更には、関連する送信記述子１９２に存在していた制御ビットを調べる。データフレームは、ＴＣＰレイヤおよび／またはＩＰレイヤのチェックサムを計算するため、送信チェックサムシステム１６４にも渡される。
【００５５】
送信記述子１９２は、ＩＰヘッダチェックサムおよび／またはＴＣＰチェックサムを計算すべきかどうかを、送信チェックサムシステム１６４に対して指示するビットを含む制御情報を有しうる。これらの制御ビットがセットされている場合、パーサ１６２はヘッダを識別または認識して、チェックサムの計算を実行するように送信チェックサムシステム１６４に対して指示し、この計算結果が、メモリ１１６にあるフレームの適切な位置に格納される。フレーム全体がメモリ１１６にロードされると、ＭＡＣ１２２はフレームの送信を開始することができる。あるいは、ネットワーク１０８への送信前に、ＩＰｓｅｃシステム１２４において、発信セキュリティ処理（暗号化および／または認証など）が実行されうる。
【００５６】
送信チェックサム処理機能の負荷を、本発明のネットワークコントローラ１０２に移すことによって、ホストプロセッサ１１２はその作業から有利に解放される。ホストプロセッサ１１２がチェックサム計算を実行するには、かなりの資源を消費しなければならない。チェックサムの計算は比較的単純であるが、チェックサムはフレーム全体が対象となり、フレームの先頭に挿入する必要がある。従来のアーキテクチャでは、ホストコンピュータは、チェックサムを計算するために、フレームを先頭から最後まで処理し、その後、フレームの先頭にチェックサムを挿入する。このデータは、コントローラにロードされる別の時点で読み出される。ネットワークコントローラ１０２は、記述子１９２とＤＭＡコントローラ１２６により、システムメモリ１２８へのダイレクトアクセスを使用してフレームを組み立てることによって、ホストプロセッサ１１２の負荷を更に軽減させる。このように、ネットワークコントローラ１０２は、時間がかかる幾つかのメモリアクセス処理から、ホストプロセッサ１１２を解放する。
【００５７】
上記に記載した受信および送信の各機能のほかに、ネットワークコントローラ１０２は、送信処理中に、様々なセグメント化機能を実行するようにプログラムされてもよい。例えば、ＴＣＰプロトコルでは、最大６４，０００バイトのＴＣＰフレームが許容される。しかし、イーサネットプロトコルではこれほど大きなデータの転送を許容しておらず、ネットワークフレームを、約１５００バイトにヘッダの一部を加えたサイズに制限されている。１６，０００バイトのネットワークフレームを許容するジャンボフレームオプションの例でも、イーサネットプロトコルは６４ＫＢのフレーム長をサポートしていない。一般に、送信フレームは、最初はシステムメモリ１２８のデータバッファ１９４の１つ以上に存在しており、ＭＡＣヘッダ、ＩＰヘッダおよびＴＣＰヘッダのほかに、最大６４ＫＢのデータを有している。記述子管理ユニット１３０を使用することにより、フレームヘッダが読まれて、（イーサネットまたはネットワークプロトコルによって許容される）適切なサイズのデータが取り出されて、送信される。記述子管理ユニット１３０は、大きなＴＣＰフレーム内での現在の位置をトラッキングしており、データを、それぞれがヘッダの組を有するブロック毎に送信する。
【００５８】
例えば、データの送信をしようとする場合、ホストプロセッサ１１２は記述子１９２を書き込んで、コントローラ１０２に知らせる。記述子管理ユニット１３０は、データバッファ１９４を特定するポインタの完全なリストを受け取り、ＴＣＰセグメント化が必要かどうかを決定する。次に、記述子管理ユニット１３０は、ヘッダバッファを読み出し、読み出すことができるデータサイズを決定する。ヘッダと適切なサイズのデータが組立ＲＡＭ１６０に読み出され、フレームが組み立てられて送信される。次に、コントローラ１０２は、ヘッダと、次のブロック（または未送信データの一部）を再び読み出して、ヘッダを適宜変更して、シーケンス中の次のフレームを形成する。この処理が、フレームの全体が送信されるまで繰り返され、その際、送信される部分のそれぞれに対して、ＩＰｓｅｃシステム１２４において、選択されているセキュリティ処理が実行される。
【００５９】
また、本発明のネットワークコントローラ１０２は、ＩＰｓｅｃ処理を内部に取り込んでおり、有利である。ＩＰｓｅｃ処理の負荷を軽減する従来のシステムとは対照的に、本発明はオンボードＩＰｓｅｃ処理を使用しており、これは、シングルチップデバイス１０２ａ（図３）として実装されうる。従来のシステムでは、ホストプロセッサがＩＰｓｅｃ処理を行うか、あるいはネットワークコントローラとは独立したコプロセッサが使用されている。ホストプロセッサを使用する場合は非常に低速であり、いずれの場合も、フレームが少なくとも３回メモリバスを通過することになる。例えば、コプロセッサを使用する場合には、フレームは、メモリから読み出されるときに一度バスを通過してコプロセッサに送られ、システムメモリに戻されるときに再度バスを通り、ネットワークコントローラに送られるときにも通過し、３度目となる。この処理は、ＰＣＩバスの帯域幅のかなりの部分を消費して、システムの性能に悪影響を与えてしまう。同様の性能のロスは、受信方向の場合にも生じてしまう。
【００６０】
ＩＰｓｅｃ処理は、２つの主な目的をもっており、第１の目的は、権限を持たない人物またはシステムがデータを読み出すことができないように、そのデータを暗号化する、あるいはスクランブルをかけることにある。第２の目的は認証であり、これは、パケットが改ざんされていないこと、およびパケットが期待した人物またはシステムから送られたものであることを保証する。以下に、オンボードＩＰｓｅｃ処理について簡単に説明する。本発明のネットワークコントローラ１０２は、ＳＡメモリインタフェース１４２、ＳＡルックアップ１４６およびＳＡメモリ１４０を使用して、セキュリティアソシエーション（security association：ＳＡ）の利点を利用する。上で簡単に説明したように、セキュリティアソシエーションとは、特定のセキュリティプロトコルを記述しているビットの集まりであり、これには、例えば、ＩＰｓｅｃ部分１２４が暗号化と認証のどちらを実行すべきか、あるいは両方を実行すべきかなどが含まれ、このほかに、使用するアルゴリズムについても記述している。標準の暗号化アルゴリズムや認証アルゴリズムは複数存在するため、ＳＡインタフェース１４２およびＳＡルックアップ１４６は、特定のフレームに対して使用するアルゴリズムを指定する。本例のＳＡメモリ１４０はプライベートメモリであり、暗号化キーを記憶している。ＩＰｓｅｃプロトコルに従ってＳＡが得られることにより、使用するアルゴリズムを決定するのに十分な情報が、ネットワーク上のユーザまたはシステムと交換され、双方が同じキーを生成することが可能となる。情報の交換が完了したら、ソフトウェアはドライバ１９０を呼び出し、ドライバがＳＡメモリ１４０に結果を書き込む。
【００６１】
キー交換が完了すると、実際のキーと共に、使用すべきキーと使用すべきアルゴリズムとを示す適切なビットが、ＳＡメモリ１４０に記憶されている。送信モードでは、所定の発信フレームに関連する記述子１９２の一部に、ＳＡメモリ１４０へのポインタが含まれる。記述子管理ユニット１３０は、記述子１９２を読み出すと、キーを取得するために、ＳＡメモリインタフェース１４２に要求を送信し、ＳＡメモリインタフェース１４２は、送信ＩＰｓｅｃ処理モジュール１７４ａ，１７４ｂのそれぞれに出力しているキーＦＩＦＯ１７２にキーを送信する。送信時に暗号化と認証の両方が実行される場合、これらのタスクは並列に実行されないため、処理がわずかに異なる。認証は、暗号化されたデータのハッシュであり、そのため、暗号化が少なくとも部分的に実行されるまで、認証処理は待機する。暗号化は、一連のデータブロックに対する反復的な処理でありうるため、暗号化プロセスが開始されてから、最初の暗号化データが利用可能となるまでに遅延が発生することがある。この遅延によるデバイス性能への影響を回避するために、代表的なネットワークインタフェース１０２は、２つの送信ＩＰｓｅｃ処理エンジン１７４ａ，１７４ｂを使用しており、図示した例では、そのうちの一方が奇数番号のフレームを処理し、もう一方が偶数番号のフレームを処理している。
【００６２】
ＩＰｓｅｃ処理の実行前に、送信ＩＰｓｅｃパーサ１７０は、フレームヘッダを構文解析して、ヘッダ内で可変フィールド（mutable field）を検索する。可変フィールドとは、ヘッダ中のフィールドであり、フレームがネットワーク１０８内を移動していく間に変更されるため、認証を受けない。例えば、フレームがインターネットを通ってルータからルータに移動すると、ＩＰヘッダ中の宛先アドレスが変更される。送信ＩＰｓｅｃパーサ１７０は可変フィールドを特定して、この情報を送信ＩＰｓｅｃプロセッサ１７４に渡し、送信ＩＰｓｅｃプロセッサ１７４はフレームの可変フィールドの部分を選択的にスキップする。処理されたフレームは、ＦＩＦＯ１７８ａ，１７８ｂに送信されて、その後メモリ１１８に蓄積される。認証処理の結果は、整合性確認値（ＩＣＶ）であり、ＩＣＶは、フレームがメモリ１１８からネットワーク媒体１０８に送られる際に、挿入ブロック１７９によって適切なＩＰｓｅｃヘッダに挿入される。
【００６３】
受信モードでは、受信されたフレームが、ＭＡＣ１２２と受信パーサ１４４に着信する。受信パーサ１４４は、着信フレームをＩＰｓｅｃヘッダの箇所まで構文解析して、情報を取り出す。受信パーサ１４４にとって意味のあるフィールドには、例えば、ＩＰヘッダ中の宛先ＩＰアドレス、ＳＰＩ（Security Protocol Index：セキュリティプロトコルインデックス）、およびＩＰｓｅｃヘッダが認証ヘッダ（authentication header：ＡＨ）か、カプセル化セキュリティプロトコル（encapsulation security protocol：ＥＳＰ）ヘッダのいずれであるかを示すプロトコルビットがある。取り出された情報は、一部がＳＡルックアップブロック１４６に渡される。ＳＡルックアップブロック１４６は、適切なＳＡを特定して、この情報をＳＡメモリインタフェース１４２に伝え、ＳＡメモリインタフェース１４２は、ＳＡを取得して、キーをキーＦＩＦＯ１５２に入れる。
【００６４】
ＳＡルックアップブロック１４６は、オンチップのＳＰＩテーブルとオフチップのＳＡメモリ１４０を使用する。ＳＰＩテーブルは、それぞれが４つのエントリを有する４０９６個のビンに編成されている。エントリには、３２ビットＳＰＩ、宛先アドレス（destination address：ＤＡ）のハッシュ、プロトコルを示すビット、およびそのエントリが使用済みであるかどうかを示すビットが含まれる。ＳＡメモリにある対応するエントリには、完全なＤＡとＳＡ（認証と暗号化が行われる場合にはＳＡは２つ）が含まれる。各エントリに対するビンは、ＳＰＩのハッシュによって決定される。ＳＡを参照するには、受信フレームから得たＳＰＩのハッシュが使用され、検索対象のビンが決定される。ＳＡルックアップブロック１４６は、ビン内で、エントリの中から、完全なＳＰＩ、宛先アドレスのハッシュ、およびプロトコルビットが完全に一致するものを検索する。検索後、ＳＡルックアップブロックは、ＳＡポインタＦＩＦＯ１４８にエントリを書き込むが、このエントリは、一致したエントリを特定しているか、あるいは一致するものがなかったことを示している。ＳＡメモリから取得したＤＡアドレスのチェックは、セキュリティ処理の直前に行われる。一致するエントリがみつからなかった場合、対象のフレーム（frame in question）にセキュリティ処理が実行されない。ＳＡポインタＦＩＦＯ１４８にあるエントリに基づいて、キーが外部ＳＡメモリ１４０から取得されて、キーＦＩＦＯ１５２に格納される。受信ＩＰｓｅｃプロセッサ１５０は、ＦＩＦＯ１５２からキーを取得して、対応するフレームデータをメモリ１１８から読み出し、要求されているフレームの処理を開始する。受信処理では、復号化と認証が並列に実行される（受信時には、復号化と認証は逐次的なプロセスでない）ため、本例では１台の受信ＩＰｓｅｃプロセッサのみが使用される。
【００６５】
受信ＩＰｓｅｃパーサ１５４は、ＥＳＰヘッダに続くヘッダを構文解析する。ＥＳＰヘッダに続くヘッダは暗号化されるため、復号化が実行されるまで構文解析することができない。構文解析は、ＴＣＰ／ＵＤＰチェックサムの計算が可能になるまで、およびパッドビットのチェックが可能となるまでに完了していなければならない。復号化されたデータは、メモリ１１６に記憶される。フレームデータを再び記憶することなく、ＴＣＰ／ＵＤＰチェックサムとパッドチェックを実行するために、これらの機能は、データがメモリ１１６からホストメモリ１２８に転送されている間に、チェックサムおよびパッドチェックシステム１５６によって実行される。上で説明したオンボードＩＰｓｅｃ処理とＴＣＰのセグメント化に加えて、ネットワークコントローラ１０２は、割込みの実行の性能も改善する。ホストプロセッサがネットワークデバイスからレジスタを読み出さなければならない場合、読出しレイテンシ（latency）が大きくなる。このレイテンシはシステム性能に悪影響を及ぼす。より詳細には、ホストプロセッサのクロックスピードが上がるにつれて、クロックスピードと、ホストプロセッサが、ＰＣＩやその他のホストバスを介してネットワークコントローラから応答を得るまでの時間との差が拡がってしまう。したがって、ホストプロセッサがネットワークデバイスの読出しを必要とする場合、ホストプロセッサが待機しなければならないクロックサイクルが増え、この結果、機会損失が発生してしまう。
【００６６】
ネットワークインタフェース１０２は、読出し操作の代わりに書込み操作を使用することによって、読出しレイテンシの多くを回避する。書込み操作は、プロセッサ１１２を使用せずに行うことができるため、さほど問題を生じさせることはない。このため、書き込む情報がＦＩＦＯに送信された場合、書込みが小さいバーストであれば、ネットワークコントローラ１０２は、プロセッサに負荷を与えることなく、書込みの実行に必要な時間をとることができる。送信操作中の読出し操作を回避するために、ドライバは、システムメモリ１２８内に記述子１９２を作成し、その記述子へのポインタをネットワークコントローラ１０２のレジスタ１３２に書き込む。コントローラ１０２のＤＭＵ１３０は、レジスタ１３２の内容を参照して、プロセッサ１１２のそれ以上の介入を必要とすることなく、必要なデータをシステムメモリ１２８から直接読み出す。受信操作については、ドライバソフトウェア１９０は、システムメモリ１２８内で空のバッファ１９４を特定して、対応するエントリをレジスタ１３２に書き込む。記述子管理ユニット１３０は、処理した送信記述子１９２を示すポインタを送信記述子リングに、使用した受信バッファ１９４を示すポインタを状態リングにそれぞれ書き込む。
【００６７】
ホストプロセッサが、ネットワークコントローラの割込みレジスタを読み出さなければならない従来のアーキテクチャとは異なり、本発明は、システムメモリ１２８内の所定の領域（例えば初期化時に決定される場所）に置かれる制御状態ブロック（control status block：ＣＳＢ）１９６を生成してこれを使用する。ネットワークコントローラ１０２は、システムが必要とするあらゆるレジスタ値をＣＳＢ１９６に書き込む。より詳細には、フレームの処理が完了したら、ネットワークコントローラ１０２は、割込みを発生させる前に、割込みレジスタのコピーをＣＳＢ１９６に書き込む。その後コントローラ１０２が割込みをアサートする。このため、ホストプロセッサ１１２がレジスタ１３２にある割込みを参照した時点で、受信されたデータが、受信データバッファ１９４に既に存在しているようになる。
【００６８】
以下、図面を参照して、代表的なネットワークインタフェースコントローラ１０２の様々な動作および構造の詳細について説明する。より詳細には、代表的なコントローラ１０２に関して、本発明を容易に理解できるように、記述子の管理に関する特徴、送信データフレームのセグメント化、およびチェックサム処理のほかに、セキュリティ処理の詳細を詳しく図示および説明する。
【００６９】
記述子の管理
【００７０】
図２，４，５Ａ〜５Ｊを参照して、記述子１９２と代表的なコントローラ１０２の動作について、以下に詳しく図示および説明する。図５Ａはホストメモリ１２８を示しており、ここには、コントローラ状態ブロック（controller status block：ＣＳＢ）１９６、フレームデータバッファ１９４、送受信記述子１９２に対する整数ｎ個の記述子リングＤＲ１、...、ＤＲｎ、および整数ｍ個の受信状態リング１９９  ＲＳＲ１、...、ＲＳＲｍが含まれる。送受信記述子１９２は、ここでは記述子リングＤＲと呼ばれるキューに記憶されており、ＣＳＢ１９６は、記述子リングＤＲをポイントしている記述子リングポインタＤＲ＿ＰＮＴＲ１、...、ＤＲ＿ＰＮＴＲｎを有する。例示したコントローラ１０２では、ネットワークトラフィックの４種類の優先度に対応して、送信フレーム用に４つの送信記述子リングが設けられ、受信フレーム用に４つの受信記述子リングが設けられている。この実装では記述子リングＤＲのそれぞれは連続するリング構造として扱われ、リングの先頭のメモリ位置は、最後のメモリ位置の直後に位置するとみなされる。図５Ｂは、代表的なＣＳＢ１９６のポインタとほかの内容を示し、図５Ｃは、コントローラ１０２の各種のポインタおよび長さレジスタ１３２を示す。図５Ｄは、代表的な送信記述子リングの更に詳細を示し、図５Ｈ，図５Ｉは、それぞれ、代表的な受信記述子および受信状態リングに関する詳細を示す。図５Ｅ，５Ｆは代表的な送信記述子を示し、図５Ｇは代表的な受信記述子を示し、図５Ｊは代表的な受信状態リングのエントリを示す。
【００７１】
図５Ａに示すように、記述子１９２は、システムメモリ１２８の１つ以上のデータバッファ１９４に対するポインタと、図５Ｅ〜５Ｇに示す制御情報を含む。コントローラ１０２とソフトウェアドライバ１９０と間の同期は、コントローラレジスタ１３２に記憶されているポインタ、システムメモリ１２８のＣＳＢ１９６に記憶されているポインタ、および割込みによって行われる。動作時に、コントローラ１０２の記述子管理ユニット１３０は、送信しようとしている発信フレームのメモリ位置を（例えば、データバッファ１９４内で）特定したり、ネットワーク１０８から受信した着信フレームを記憶する位置を決定するために、バスインタフェース１０４のＤＭＡコントローラ１２６を介して記述子１９２を読み出す。ＣＳＢ１９６は、ネットワークコントローラ１０２によって書き込まれ、ホストプロセッサ１１２のドライバ１９０によって読み出され、記述子管理レジスタ１３２は、ドライバ１９０によって書き込まれ、コントローラ１０２の記述子管理ユニット１３０によって読み出される。代表的な記述子システムは、一般に、送信操作および受信操作に関して、ソフトウェアドライバ１９０とコントローラ１０２との間の情報の交換を容易にする。
【００７２】
次に図５Ｂを参照すると、代表的なＣＳＢ１９６は、記述子へのポインタと状態リングへのポインタのほかに、コントローラの割込みレジスタの内容のコピーを有する。送信ポインタＴＸ＿ＲＤ＿ＰＴＲ０〜ＴＸ＿ＲＤ＿ＰＴＲ３は、それぞれ送信優先度３〜０に対応する記述子読出しポインタであり、これらは、コントローラ１０２が、対応する優先度の送信記述子リングから読み出した最後の６４ビットのカッド語（ＱＷＯＲＤ）の直後をポイントしている。受信状態ポインタＳＴＡＴ＿ＷＲ＿ＰＴＲ０〜ＳＴＡＴ＿ＷＲ＿ＰＴＲ３は、それぞれ送信優先度３〜０に対応する記述子書込みポインタであり、これらは、コントローラ１０２が、対応する優先度の受信状態リングに書き込んだ最後のＱＷＯＲＤの直後をポイントしている。ＣＳＢ１９６は、割込みゼロレジスタコピーＩＮＴ０＿ＣＯＰＹも有しており、これは、コントローラ１０２の割込み０レジスタの内容のコピーである。
【００７３】
図５Ｃは、コントローラ１０２の記述子管理ユニット１３０に関連するレジスタ１３２を示している。送信記述子ベースポインタＴＸ＿ＲＩＮＧ［３:０］＿ＢＡＳＥは、対応する優先度の送信記述子リングの先頭のメモリアドレスを有し、送信記述子リングの長さがＴＸ＿ＲＩＮＧ［３:０］＿ＬＥＮレジスタに記憶されている。送信記述子書込みポインタは、レジスタＴＸ＿ＷＲ＿ＰＴＲ［３:０］に記憶されており、ドライバソフトウェア１９０は、ドライバが対応する送信記述子リングに書き込んだ最後のＱＷＯＲＤの直後を指すように、これらのレジスタを更新する。受信記述子ベースポインタＲＸ＿ＲＩＮＧ［３:０］＿ＢＡＳＥは対応する優先度の受信記述子リングの先頭の（例えば、ホストメモリ１２８における）メモリアドレスを有し、受信記述子リングの長さがＲＸ＿ＲＩＮＧ［３：０］＿ＬＥＮレジスタに記憶されている。受信記述子書込みポインタＲＸ＿ＷＲ＿ＰＴＲ［３:０］は、ドライバ１９０が対応する受信記述子リングに書き込んだ最後のＱＷＯＲＤの直後を指すように、このドライバによって更新される。受信状態リングベースポインタレジスタＳＴＡＴ＿ＲＩＮＧ［３:０］＿ＢＡＳＥは、受信状態リングのメモリアドレスを示し、ＳＴＡＴ＿ＲＩＮＧ［３:０］＿ＢＡＳＥは、メモリ１２８内の対応する受信状態リング１９９の長さを示す。ＲＸ＿ＢＵＦ＿ＬＥＮは、受信データバッファ１９４に含まれるＱＷＯＲＤの数を示しており（受信データバッファ１９４は長さが全て同じ）、ＣＳＢ＿ＡＤＤＲはホストメモリ１２８内のＣＳＢ１９６のアドレスを示している。
【００７４】
データ送信時の記述子管理処理を更に詳しく示すために、図５Ｄは、ホストメモリ１２８および記述子管理ユニット１３０を示し、ホストメモリ１２８内の代表的な送信記述子リングと、対応するコントローラ１０２の記述子管理ユニット１３０内の記述子レジスタ１３２とを示している。更に、図５Ｅおよび５Ｆは、代表的な送信記述子１９２ａとその制御フラグとをそれぞれ示す。図５Ｅの送信記述子１０２において、ＢＵＦ１＿ＡＤＲ［３９:０］は、記述子１９２ａに関連付けられている、第１のデータバッファ１９４のホストメモリ１２８内でのアドレスを記憶している。記述子１９２ａは、送信フラグ１９３（図５Ｅ，５ＦのＴＦＬＡＧＳ１）も有しており、このフラグは、仮想ローカルエリアネットワーク（ＶＬＡＮ）操作とＴＣＰセグメント化操作に関する情報を有する第２の６４ビットの制御ワードを含むことを示すＭＯＲＥ＿ＣＴＲＬビットを有する。ＡＤＤ＿ＦＣＳ／ＩＶＬＥＮ１ビットとＩＶＬＥＮ０ビットは、ＩＰｓｅｃ処理がない場合はＦＣＳ生成を制御するために、またはＩＰｓｅｃセキュリティとレイヤ４の処理が選択されている場合は、カプセル化セキュリティプロトコル（ＥＳＰ）の初期化ベクトル（ＩＶ）の長さを示すために用いられる。ＩＰＣＫビットは、コントローラ１０２が、送信フレームに対してレイヤ３（ＩＰレイヤ）のチェックサムを生成するかどうかを示すために使用され、Ｌ４ＣＫフラグビットは、コントローラ１０２がレイヤ４（例えばＴＣＰ、ＵＤＰ等）のチェックサムを生成するかどうかを示す。３ビットのバッファカウントビットＢＬＴＦ＿ＣＮＴは、８未満の場合、記述子１９２ａに関連するデータバッファ１９４の数を示す。８つ以上のデータバッファ１９４が記述子１９２ａに関連している場合、このバッファカウントは、記述子１９２ａのＢＵＦ＿ＣＮＴ［７:０］フィールドに示されている。
【００７５】
記述子１９２ａのＢＹＴＥＣＯＵＮＴ１［１５:０］フィールドは、第１のデータバッファ１９４の長さをバイト単位で示す。ＰＡＤ＿ＬＥＮフィールドは、フレームに関連するＥＳＰトレーラからのパッド長の値を記憶し、ＮＸＴ＿ＨＤＲフィールドは、ＭＯＲＥ＿ＣＴＲＬビットがセットされている場合に、このＥＳＰトレーラからの次ヘッダ情報（ＩＰｖ４のプロトコルデータ）を示す。ＮＸＴ＿ＨＤＲフィールドの後のＥＳＰ＿ＡＵＴＨビット１９５は、フレームがＥＳＰトレーラ内に認証データフィールドを含んでいるかどうかを示し、セキュリティアソシエーション（ＳＡ）ポインタフィールドＳＡ＿ＰＴＲ［１４:０］は、フレームに対応する外部ＳＡメモリ１４０（図２）内のエントリを示す。２ビットのＶＬＡＮタグ制御命令フィールドＴＣＣ［１:０］１９７は、コントローラ１０２に対して、ＶＬＡＮタグを追加、変更または削除させるか、または未変更のフレームを送信させる命令を含んでおり、最大セグメントサイズフィールドＭＳＳ［１３:０］は、記述子１９２ａに関連するフレームに対して、コントローラ１０２のＴＣＰセグメント化ハードウェアが生成するセグメントの最大のサイズを指定している。ＴＣＣフィールドの内容が１０または１１の場合、コントローラ１０２は、タグ制御情報フィールドＴＣＩ［１５:０］の内容を、発信フレームのバイト１５および１６として送信する。フレームデータが１つ以上のデータバッファ１９４を占めている場合、これらのバッファのアドレスを示すために、１つ以上の追加のバッファアドレスフィールドＢＵＦ＿ＡＤＲ［３９:０］が使用され、追加のフレームバッファ１９４内のバイト数を示すために、関連するＢＹＴＥＣＯＵＮＴ［１５:０］フィールドが使用される。
【００７６】
ネットワークソフトウェアドライバ１９０は、記述子１９２を記述子リングに書き込む際に、記述子管理ユニットレジスタ１３２の記述子書込みポインタレジスタ１３２にも書き込み、その新しい記述子１９２が利用可能となったことをコントローラ１０２に知らせる。ドライバが所定の記述子管理レジスタ１３２に書き込む値は、ホストメモリ１２８内の、ドライバが書き込んだ記述子１９２の直後の６４ビットワード（ＱＷＯＲＤ）に対するポインタであり、このポインタは、記述子リングの先頭からのＱＷＯＲＤ単位でのオフセットである。コントローラ１０２は、このオフセットから読み出したり、このオフセットを越える位置から読み出すことはない。送信記述子書込みポインタレジスタ（例えば、図５ＤのＴＸ＿ＷＲ＿ＰＴＲ１などのＤＭＵレジスタ１３２）が書き込まれていれば、コントローラ１０２は、送信が既に実行中でなければ、送信プロセスを開始する。送信プロセスが開始されると、未処理の送信記述子１９２が送信記述子リングからなくなるまで、送信が続けられる。コントローラ１０２が所定の送信記述子１９２に対する処理を終了すると、コントローラ１０２は、記述子読出しポインタ（例えば図５ＤのポインタＴＸ＿ＲＤ＿ＰＴＲ１）をＣＳＢ１９６に書き込む。
【００７７】
この時点で、読出記述子ポインタＴＸ＿ＲＤ＿ＰＴＲ１は記述子１９２の先頭を示しており、これをコントローラ１０２が次に読み出す。記述子１９２の値は、読み出された最後の記述子の直後のＱＷＯＲＤのＱＷＯＲＤ単位でのオフセットである。このため、ポインタＴＸ＿ＲＤ＿ＰＴＲ１は、記述子空間内で再利用可能な部分を、ドライバ１９０に対して示すことになる。ドライバ１９０は、読出しポインタが指している記述子空間内の位置に書き込むことはなく、またはその位置と、記述子書込みポインタＴＸ＿ＷＲ＿ＰＴＲ１が指している位置の１ＱＷＯＲＤ前の位置との間に書き込むこともない。記述子読出しポインタＴＸ＿ＲＤ＿ＰＴＲ１と、対応する記述子書込みポインタＴＸ＿ＷＲ＿ＰＴＲ１とが同じ場合、記述子リングは空である。リングが空の場合と、およびリングが一杯になっている場合とを区別するために、ドライバ１９０は、リング内に、少なくとも１つの未使用のＱＷＯＲＤが常に存在するようにしている。このため、ＴＸ＿ＷＲ＿ＰＴＲ１が、リングサイズをモジューロとした読取りポインタＴＸ＿ＲＤ＿ＰＴＲ１よりも１つ小さい場合、送信記述子リングが一杯になっている。
【００７８】
図５Ｇも参照すると、代表的な受信記述子１９２ｂが示されており、受信記述子１９２ｂは、ホストシステムメモリ１２８内の受信バッファ１９４の一ブロックへのポインタＢＵＦ＿ＡＤＲ［３９:０］およびこのブロック内のバッファ１９４の数を示すカウントフィールドＢＵＦ＿ＭＵＬＴ［７:０］とを有し、受信バッファ１９４はすべて長さが同じであり、図示した例では、各受信フレームに対して１つのバッファのみが使用される。受信されたフレームが大きすぎてバッファ１０４に入らない場合、フレームが切り捨てられ、対応する受信状態リングのエントリ１９９のＴＲＵＮＣビットがセットされる。図５Ｈは、代表的な受信記述子リングを示しており、このリングは整数ｎ個の受信記述子１９２ｂを有し、ホストメモリ１２８内のｎ個の受信データバッファ１９４をポイントするアドレスを記憶している。コントローラ１０２の記述子管理ユニット１３０内のレジスタ１３２は、受信記述子リングに対応するリングベースおよび長さレジスタ（ＲＸ＿ＲＩＮＧ１＿ＢＡＳＥおよびＲＸ＿ＲＩＮＧ１＿ＬＥＮ）のほかに、図中の記述子リングにおいて次の未使用の受信記述子１９２ｂのアドレスを記憶している受信書込みポインタレジスタ（ＲＸ＿ＷＲ＿ＰＴＲ１）および全バッファ１９４の長さを記憶している受信バッファ長レジスタ（ＲＸ＿ＢＵＦ＿ＬＥＮ）を有する。また、記述子管理ユニット１３０は、１つ以上のバッファ１９４にある受信データに対応するエントリ１９９を記憶している受信状態リングの位置に関するレジスタ１３２（ＳＴＡＴ＿ＲＩＮＧ１＿ＢＡＳＥおよびＳＴＡＴ＿ＲＩＮＧ１＿ＬＥＮ）も有する。また、ホストメモリの制御状態ブロック１９６は、受信状態リング内での次の未使用の状態リング位置のアドレスを示すレジスタＳＴＡＴ＿ＷＲ＿ＰＴＲ１も有し、ＳＴＡＴ＿ＷＲ＿ＰＴＲ１とＲＸ＿ＷＲ＿ＰＴＲ１が等しい場合、受信状態リングは空であるとみなされる。
【００７９】
図５Ｉ，５Ｊは、代表的な受信状態リング１９９とそのエントリの詳細をそれぞれ示す。図５Ｊの代表的な受信状態リングのエントリは、受信フレームからコピーしたＶＬＡＮタグ制御情報ＴＣＩ［１５:０］と、受信されて受信データバッファ１９４にコピーされたバイト数を示すメッセージカウントフィールドＭＣＮＴ［１５:０］を有する。３ビットのＩＰＳＥＣ＿ＳＴＡＴ１［２:０］フィールドは、ＩＰｓｅｃセキュリティシステム１２４からのエンコード状態を示し、ＴＵＮＮＥＬ＿ＦＯＵＮＤビットは、受信データフレームで第２のＩＰヘッダが見つかったことを示す。ＡＨ＿ＥＲＲビットは、受信フレームにおける認証ヘッダ（ＡＨ）の失敗を示し、ＥＳＰＡＨ＿ＥＲＲビットは、ＥＳＰ認証の失敗を示し、ＰＡＤ＿ＥＲＲビットは、ＥＳＰパディングの誤りを示す。ＣＲＣビットは、ＦＣＳまたはアライメントエラーを示し、ＴＲＵＮＣビットは、受信フレームがＲＸ＿ＢＵＦ＿ＬＥＮレジスタ１３２（前述の図５Ｃ）の値よりも長く、切り捨てられていることを示す。ＶＬＡＮタグタイプフィールドＴＴ［１:０］は、受信されたフレームにタグが付けられていないか、優先度タグまたはＶＬＡＮタグが付けられているかを示し、ＲＸ＿ＭＡＴＣＨ［２:０］フィールドは、受信アドレス一致タイプを示す。ＩＰ＿ＣＫ＿ＥＲＲビットは、ＩＰｖ４ヘッダのチェックサムエラーを示し、ＩＰヘッダ検出フィールドＩＰ＿ＨＥＡＤＥＲ［１:０］は、ＩＰヘッダが検出されているかどうかを示し、検出されている場合はそのタイプ（例えばＩＰｖ４またはＩＰｖ６）を示す。Ｌ４＿ＣＫ＿ＥＲＲビットは、受信フレームにおけるレイヤ４（例えばＴＣＰまたはＵＤＰ）のチェックサムエラーを示し、レイヤ４ヘッダ検出フィールドＬ４＿ＨＥＡＤＥＲは、レイヤ４ヘッダが検出されている場合にそのタイプを示す。更に、受信アライメント長フィールドＲＣＶ＿ＡＬＩＧＮ＿ＬＥＮ［５:０］は、アライメントのため、ＭＡＣヘッダの先頭の前に挿入されるパディングの長さを示す。
【００８０】
図５Ｈ，５Ｉに示すように、受信操作では、コントローラ１０２は、受信状態リング書込みポインタＳＴＡＴ＿ＷＲ＿ＰＴＲ［３:０］（図５Ｂ）をＣＳＢ１９６に書き込む。ネットワークドライバソフトウェア１９０は、この書込みポインタを使用して、ホストメモリ１２８内で、どの受信バッファ１９４が一杯になっているかを特定する。受信状態リング１９９は、受信フレームに関する状態情報（例えば受信バイト数およびエラー情報）の転送に使用され、例示したシステムでは、４つの受信状態リング１９９が、各優先度について１つずつ設けられている。コントローラ１０２がネットワーク１０８から着信フレームを受信すると、コントローラ１０２は、適切な受信記述子リングにある次の受信記述子１９２を使用して、フレームを記憶すべきホストメモリ１２８内の位置を決定する。受信フレームがシステムメモリ１２８へコピーされると、コントローラ１０２は、対応する受信状態リング１９９に、受信側状態情報（reicever status information）を書き込む。コントローラ１０２とドライバソフトウェア１９０の間の同期は、ＣＳＢ１９６内の受信状態書込みポインタ（ＳＴＡＴ＿ＷＲ＿ＰＴＲ［３:０］）によってとられる。このポインタＳＴＡＴ＿ＷＲ＿ＰＴＲ［３:０］は、対応するリングの先頭からのＱＷＯＲＤ単位でのオフセットである。
【００８１】
コントローラ１０２は、ネットワーク１０８からのフレームの受信を完了したら、適切な受信状態リング１９９内の次の使用可能な位置に状態情報を書き込み、対応する受信状態書込みポインタＳＴＡＴ＿ＷＲ＿ＰＴＲを更新する。コントローラ１０２がこの位置に書き込む値は、リング中の、コントローラ１０２が次に書き込む状態エントリへのポインタである。ソフトウェアドライバ１９０は、このエントリを読み出すことはなく、このエントリより後のエントリを読み出すこともしない。代表的なコントローラ１０２は、各リング内で、最初の未処理の受信状態エントリを指しているレジスタを有していない。その代わりに、この情報は、受信記述子ポインタＲＸ＿ＷＲ＿ＰＴＲから間接的に導き出される。このため、ソフトウェアドライバ１９０が、コントローラ１０２のＲＸ＿ＷＲ＿ＰＴＲレジスタ１３２の１つ（図５Ｃ）に書き込む際に、ドライバ１９０は、このバッファ１０４に対応するエントリのための十分な空間が、受信状態リング１９９に存在することを保証する。
【００８２】
送信データフレーム
【００８３】
ここで図２〜４，６Ａ〜６Ｅを参照すると、コントローラ１０２は、上記の送信記述子１９２を使用して、ホストメモリ１２８のデータバッファ１９４から、フレーム２００を送信する。ホストプロセッサ１１２で実行されているアプリケーションソフトウェアプログラム１８４が、データのパケットまたは情報をネットワーク１０８上の別のコンピュータまたはデバイスに送信する必要がある場合、このパケットが、オペレーティングシステムのレイヤ４とレイヤ３のソフトウェア（例えば図４のＴＣＰレイヤソフトウェア１８６、およびＩＰソフトウェア１８８）に供給される。これらのソフトウェアレイヤは、フレーム２００を送信するために、各種のヘッダおよびトレーラを作成する。次に、ネットワークインタフェースドライバソフトウェア１９０は、１つ以上のヘッダおよびデータパケットを含むフレーム２００を組み立てて、これをホストメモリのデータバッファ１９４に入れ、それに応じて、コントローラ１０２の記述子と記述子管理ユニットレジスタ１３２を更新する。データバッファ１９４中の組み立てられたフレームは、図７Ａ，７Ｂに示すように、レイヤ３およびレイヤ４のヘッダと対応するチェックサム（例えばＩＰヘッダおよびＴＣＰヘッダとチェックサム）のほかにＭＡＣヘッダを有する。図６Ａ，６Ｃは、それぞれトランスポートモードおよびトンネルモードにおいて、レイヤ４のＴＣＰおよびレイヤ３のインターネットプロトコルバージョン４（ＩＰｖ４）を使用して送信フレーム２００ａ，２００ｃを作成する方法を概略的に示し、図６Ｂ，６Ｄは、それぞれトランスポートモードおよびトンネルモードにおいて、ＩＰｖ６を使用して送信フレーム２００ｂ，２００ｄを作成する方法を概略的に示す。しかし、本発明は、ＴＣＰ／ＩＰの実装に限られず、他のプロトコルを使用してもよい。例えば、代表的なコントローラ１０２は、ユーザデータグラムプロトコル（ＵＤＰ）レイヤ４ソフトウェアを使用して、データを送受信してもよい。
【００８４】
図６Ａ〜６Ｄにおいて、アプリケーションソフトウェア１８４からの原データパケットが、ＴＣＰデータ２０２としてＴＣＰレイヤ１８６に提供される。ＴＣＰレイヤ１８６は、ＴＣＰデータ２０２をホストメモリ１２８に記憶して、ＴＣＰヘッダ２０４を作成する。ＴＣＰの例示的なＴＣＰヘッダについては、図７Ａ，７Ｂを参照して後述する。ＴＣＰデータ２０２とＴＣＰヘッダ（これらへのポインタなど）が、レイヤ３のソフトウェア（例えば本例ではＩＰレイヤ１８８）に提供される。ＩＰレイヤ１８８は、ＩＰヘッダ２０６（例えば図６Ａ，６ＣのＩＰｖ４ヘッダ２０６ａ、または図６Ｂ，６ＤのＩＰｖ６ヘッダ２０６ｂ）を作成する。ＩＰｖ６（図６Ｂ，６Ｄ）ではＩＰレイヤ１８８は、任意選択の拡張ヘッダ２０８も作成してもよい。
【００８５】
ＥＳＰ暗号化および認証などの送信セキュリティ処理が使用される場合、ＩＰレイヤ１８８は、ＩＰｖ４（図６Ａ，６Ｃ）では、ＥＳＰヘッダ２１０、ＥＳＰトレーラ２１２およびＥＳＰ認証フィールド２１４を作成する。ＩＰｖ６のトランスポートモード（図６Ｂ）の場合、ホップバイホップ宛先ルーティングフィールド２１６および宛先オプションフィールド２１８が、ＩＰレイヤ１８８によって作成される。トンネルモードのＩＰｖ４の場合、ＩＰレイヤ１８８は、新しいＩＰｖ４ヘッダ２２０も作成する。トンネルモードのＩＰｖ６（図６Ｄ）の場合、ＩＰレイヤ１８８は、更に、ＥＳＰヘッダ２１０の前に新しいＩＰｖ６ヘッダ２２２と新しい拡張ヘッダ２２４を作成する。
【００８６】
図６Ａのフレーム２００ａの場合、ＴＣＰヘッダ２０４、ＴＣＰデータ２０２およびＥＳＰトレーラ２１２が暗号化されており、この場合、ホストのソフトウェアが暗号化を実行しても、あるいは代表的なネットワークインタフェースコントローラ１０２が暗号化を実行するように構成されてもよい。認証は、ＥＳＰヘッダ２１０と、暗号化されているＴＣＰヘッダ２０４、ＴＣＰデータ２０２およびＥＳＰトレーラ２１２の全体に実行される。図６ＢのトランスポートモードＩＰｖ６フレーム２００ｂの場合、宛先オプション２１８、ＴＣＰヘッダ２０４、ＴＣＰデータ２０２、およびＥＳＰトレーラ２１２が暗号化されており、ＥＳＰヘッダ２１０が、暗号化されているＴＣＰヘッダ２０４、ＴＣＰデータ２０２およびＥＳＰトレーラ２１２と共に認証される。図６ＣのトンネルモードＩＰｖ４の例では、ＴＣＰヘッダ２０４、ＴＣＰデータ２０２、元のＩＰｖ４ヘッダ２０６ａ、およびＥＳＰトレーラ２１２が暗号化され、その後、これらに加えてＥＳＰヘッダ２１０が認証されうる。図６ＤのＩＰｖ６トンネルモードの例では、ＴＣＰヘッダ２０４、ＴＣＰデータ２０２、ＥＳＰトレーラ２１２、元の拡張ヘッダ２０８および元のＩＰｖ６ヘッダ２０６ｂが暗号化され、これらに加えてＥＳＰヘッダ２１０が認証される。
【００８７】
図６Ｅは、ＥＳＰヘッダ２１０とトレーラ２１２を作成した後の代表的な送信フレーム２００ａを示し、代表的なＥＳＰヘッダ２１０を更に詳しく示す。ＥＳＰヘッダ２１０は、セキュリティパラメータインデックス（ＳＰＩ）を有しており、ＳＰＩは、ＩＰヘッダ２０６ａの宛先ＩＰアドレスおよびＥＳＰセキュリティプロトコルと組み合わされると、フレーム２００ａのセキュリティアソシエーション（ＳＡ）を一意に特定する。ＥＳＰヘッダ２１０は、個々のフレームを特定するために送信側と受信側によって用いられるカウンタ値を示すシーケンス番号フィールドを更に有し、この送信側および受信側のカウンタ値は、セキュリティアソシエーションが確立されたときにゼロに初期化される。フレーム２００ａのペイロードデータには、暗号化アルゴリズムが暗号同期データを必要とする場合に、初期化ベクトル（ＩＶ）２２６が、ＴＣＰデータ２０２、およびＴＣＰまたはその他レイヤ４のヘッダ２０４と共に含まれる。
【００８８】
パディングバイト２３０は、暗号化アルゴリズムのために、暗号ブロックのバイト数の倍数となるように平文データを埋めるために、および／または後続のＰＡＤ  ＬＥＮＧＴＨフィールド２３２およびＮＥＸＴ  ＨＥＡＤＥＲフィールド２３４をＥＳＰトレーラ２１２において４バイトワード内で右側に揃えるために必要に応じて追加され、これによって、トレーラ２１２に続くＥＳＰ認証データ２１４が４バイトの境界に揃うことが保証される。ＥＳＰトレーラ２１２において、ＰＡＤ  ＬＥＮＧＴＨフィールド２３２は、ＰＡＤバイト２３０のバイト数を示し、ＮＥＸＴ  ＨＥＡＤＥＲフィールド２３４は、ＩＰｖ６の拡張ヘッダなどの保護されたペイロードデータ中のデータのタイプ、または上層のプロトコル識別子（例えばＴＣＰ、ＵＤＰ等）など、を特定している。フレーム２００ａに対してセキュリティ処理が選択されている場合、ＩＰレイヤ１８８は、ＥＳＰヘッダ２１０（例えば図面に示したフレーム２００ａ中のＩＰｖ４ヘッダ２０６ａ）の直前のプロトコルヘッダを変更して、その際、ＰＲＯＴＯＣＯＬフィールド（例えばＩＰｖ６ではＮＥＸＴ  ＨＥＡＤＥＲフィールド）の値を、後続のヘッダ２１０がＥＳＰヘッダであることを示す値（例えば５０）に変更する。
【００８９】
図７Ａ，Ｂは、それぞれＩＰｖ４およびＩＰｖ６の代表的なＴＣＰフレームのフォーマット２００ｅ，２００ｆを示し、各種ヘッダの内容を示している。図７Ａにおいて、代表的なフレーム２００ｅは、ＴＣＰデータパケット２０２、ＴＣＰヘッダ２０４、ＩＰｖ４ヘッダ２０６ａ、およびＭＡＣヘッダ２４０のほかに、フレームチェックシーケンスのための４バイトのＦＣＳフィールドを有する。図７Ｂにおいて、フレーム２００ｆは、同様に、ＴＣＰデータパケット２０２、ＴＣＰヘッダ２０４、およびＭＡＣヘッダ２４０のほかに、４バイトのＦＣＳフィールドとＩＰｖ６ヘッダ２０６ｂを有する。いずれの場合も、ＴＣＰチェックサムは、ＴＣＰデータ２０２とＴＣＰヘッダ２０４の全体に対して計算される。ＩＰｖ４の例２００ｅでは、ＩＰｖ４ヘッダのチェックサムは、ＩＰｖ４ヘッダ２０６ａ全体に対して計算され（ＩＰｖ４ヘッダ２０６ａのＨＥＡＤＥＲ  ＣＨＥＣＫＳＵＭフィールド）、ＩＰ全長は、ＩＰｖ４ヘッダ２０６ａ、ＴＣＰヘッダ２０４、およびＴＣＰデータ２０２の全体の長さ（ＩＰｖ４ヘッダ２０６ａのＴＯＴＡＬ  ＬＥＮＧＴＨフィールド）であり、ＩＥＥＥ８０２．３長は、ＩＰ全長に、ＭＡＣヘッダ２４０のＯＰＴＩＯＮ  ＬＬＣ  ＆  ＳＮＡＰフィールドの０〜８バイトを加えた値である（ＭＡＣヘッダの８０２．３  ＬＥＮＧＴＨ／ＴＹＰＥフィールド）。図７ＢのＩＰｖ６の例２００６では、ＩＥＥＥ８０２．３長は、ＴＣＰデータ２０２に、ＴＣＰヘッダ２０４と任意選択の拡張ヘッダ（図７ＢのＩＰｖ６ヘッダの最後のフィールドとして示される）を加えた値（この値は、ＭＡＣヘッダ２４０のＬＥＮＧＴＨ／ＴＹＰＥフィールドに記憶される）であり、ＩＰペイロード長は、ＴＣＰデータ２０２に、ＴＣＰヘッダ２０４と任意選択の拡張ヘッダを加えた値（ＩＰｖ６ヘッダ２０６ｂのＰＡＹＬＯＡＤ  ＬＥＮＧＴＨフィールド）である。
【００９０】
ＴＣＰセグメント化
【００９１】
次に図８Ａ〜８Ｄ，９を参照すると、コントローラ１０２は、発信ＴＣＰおよび／またはＩＰレイヤのチェックサム処理、ＴＣＰセグメント化および／またはＩＰｓｅｃセキュリティ処理を任意選択で実行することができる。これらの機能の１つ以上の負荷がホストプロセッサ１１２からコントローラ１０２に移ると、レイヤ３のソフトウェア１８６は、フレーム２００のフィールドのうちの特定のフィールド（例えばチェックサム、長さなど）に擬似値を付与しうる。ＴＣＰレイヤセグメント化についていえば、コントローラ１０２は、ホストメモリ１２８から送信フレームを自動的に取得して、フレームのサイズが大きい場合、ＴＣＰセグメント化システム２６０を使用して、この大きなフレームを、ネットワーク１０８の最大伝送単位（maximum transmission unit：ＭＴＵ）の要件を満たす小さなフレーム（またはフレームセグメント）に分割するようにプログラムされうる。セグメント化システム２６０は、記述子管理ユニット１３０に動作可能に結合された任意の回路を有し、ここに記述したセグメント化タスクを実行するように構成されている。次に、コントローラ１０２は、適切なＭＡＣ、ＩＰ、およびＴＣＰの各ヘッダを付けてこれらのセグメントを送信する。図示した例では、ホストシステムメモリ１２８にある元のＴＣＰフレーム２００は、ＭＡＣ、ＩＰ、およびＴＣＰの各ヘッダをすべて備えたＩＥＥＥ８０２．３またはイーサネットのフレーム（サイズが大きすぎる可能性のある）の形をとっている。代表的なコントローラ１０２では、ＩＰヘッダ２０６はバージョン４またはバージョン６のいずれであってもよく、ＩＰヘッダとＴＣＰヘッダはオプションフィールドまたは拡張ヘッダを有していてもよい。ネットワークコントローラ１０２は、自動的に生成するセグメント化されたフレームのそれぞれについて、これらのヘッダを適切に変更したものを使用する。代表的なデバイス１０２では、元のＴＣＰフレームは、ホストシステムメモリ１２８内の幾つのバッファ１９４に記憶されていてもよく、フレームの先頭からＴＣＰヘッダ２０４までの全ヘッダが最初のバッファ１９４に記憶される。
【００９２】
図７Ａ，７Ｂも参照すると、ＩＰｖ４フレーム２００ｅ（図７Ａ）のフレームフィールド８０２．３  ＬＥＮＧＴＨ／ＴＹＰＥ、ＴＯＴＡＬ  ＬＥＮＧＴＨ、ＩＤＥＮＴＩＦＩＣＡＴＩＯＮ、ＨＥＡＤＥＲ  ＣＨＥＣＫＳＵＭ、ＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲ、ＰＳＨ、ＦＩＮ、およびＴＣＰ  ＣＨＥＣＫＳＵＭの各フィールドは、コントローラ１０２において変更され、それ以外は元のフレームから直接コピーされる。図７Ｂにおいて、フレーム２００ｆのＬＥＮＧＴＨ／ＴＹＰＥ、ＰＡＹＬＯＡＤ  ＬＥＮＧＴＨ、ＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲ、ＰＳＨ、ＦＩＮ、およびＴＣＰ  ＣＨＥＣＫＳＵＭの各フィールドは、フレームが生成される（例えば、セグメント化される）都度、コントローラ１０２において変更される。コントローラ１０２によるフレーム２００の自動ＴＣＰセグメント化を有効にするために、ホスト１１２のドライバ１９０は、対応する送信記述子１９２のＭＯＲＥ＿ＣＴＲＬフィールド（図５Ｆ）のビットをセットし、記述子１９２の最大セグメントサイズ（ＭＳＳ［１３:０］）フィールドも有効な値にする。最後のフレーム以外の、すべての対応する生成されるフレームでは、長さが、ＭＳＳ［１３:０］フィールドの値に、ＭＡＣ、ＩＰ、およびＴＣＰの各ヘッダ２４０，２０６，２０４のそれぞれの長さと、ＦＣＳの４バイトとを加えた値となる。生成される最後のフレームの長さは、元のセグメント化されていないデータの長さによっては短くなることもある。
【００９３】
図８Ａは、発信ＥＳＰ処理によって変更されるフレームフィールドを示すテーブル２５０を示し、図８Ｂは認証ヘッダ（ＡＨ）処理によって変更されるフレームフィールドを示すテーブル２５２を示し、テーブル２５０，２５２は、ホストプロセッサソフトウェアによって作成されるフレームフィールドと、コントローラ１０２によって追加されるフレームフィールドを示している。送信フレームを、自動ＴＣＰセグメント化のためコントローラ１０２に送る前に、ＩＰレイヤ１８８は、ＴＣＰヘッダ２０４のＴＣＰチェックサムフィールドに、調整された擬似ヘッダチェックサムを付与する。図８Ｃ，８Ｄは、送信フレーム２００の生成時に、ＩＰレイヤソフトウェア１８８によって実行される、それぞれＩＰｖ４およびＩＰｖ６用の疑似ヘッダチェックサムの計算を示すテーブル２５４，２５６である。このチェックサムの値は、ＩＰｖ４フレームについては、伝送制御プロトコル機能仕様書（ＲＦＣ  ７９３）セクション３．１に、ＩＰｖ６フレームについては、インターネットプロトコルバージョン６仕様書（ＲＦＣ  ２４６０）セクション８．１に記載されている標準ＴＣＰ擬似ヘッダチェックサムであり、例外は、計算の際に、ＴＣＰ長に値０が使用される点である。コントローラ１０２は、生成されたそれぞれのセグメントに適切なＴＣＰ長を追加する。
【００９４】
ＩＰｖ４フレームの場合、図８Ｃの疑似ヘッダ２５４は、３２ビットのＩＰ発信元アドレス、３２ビットのＩＰ宛先アドレス、ＩＰヘッダからの８ビットのプロトコルフィールドにゼロを左にパディングした１６ビットのワード、およびＴＣＰ長（本例では０とみなされる）を有する。ＩＰｖ６フレームの場合、図８Ｄの疑似ヘッダ２５６は、１２８ビットのＩＰｖ６発信元アドレス、１２８ビットＩＰｖ６宛先アドレス、１６ビットのＴＣＰ長（０とみなされる）、８ビットのプロトコル識別子にゼロを左にパディングした１６ビットのワードを有する。８ビットのプロトコル識別子は、ＩＰｖ６ヘッダのＮＥＸＴ  ＨＥＡＤＥＲフィールドの内容か、あるいは拡張ヘッダが存在する場合、最後のＩＰｖ６拡張ヘッダの内容であり、ＴＣＰでは値は６となる。ＴＣＰセグメント化を実行せずに、ＴＣＰまたはＵＤＰのチェックサム生成が有効な場合、疑似ヘッダチェックサムに使用されるＴＣＰ長には、ＴＣＰヘッダとＴＣＰデータフィールドとが含まれる。しかし、ＴＣＰセグメント化が有効な場合、コントローラ１０２は、生成されたフレームのそれぞれに対して、適切な長さを有するように、疑似ヘッダチェックサムを自動的に調整する。
【００９５】
コントローラ１０２がＴＣＰセグメント化を実行するようにプログラムされている場合、様々な変更されるフィールドの値が、以下に記載するように計算される。ＭＡＣヘッダ２４０のＬＥＮＧＴＨ／ＴＹＰＥフィールドは、その値が６００ｈ未満であるか否かによって、長さか、イーサネットタイプのいずれかであると解釈される。このフィールドの値が６００ｈ以上の場合、このフィールドはイーサネットタイプであるとみなされ、その場合、生成される全フレームのＬＥＮＧＴＨ／ＴＹＰＥフィールドにこの値が使用される。しかし、値が６００ｈ未満の場合、このフィールドはＩＥＥＥ８０２．３の長さフィールドであると解釈され、その場合、生成されたフレームのそれぞれについて、適切な長さの値がコントローラ１０２において計算される。長さフィールドのために生成される値は、ＬＥＮＧＴＨ／ＴＹＰＥフィールドに続くＦＣＳ以外の全バイトを含む、送信フレームのＬＬＣデータ部分のバイト単位での長さを示すが、フレームを最小フレームサイズまで増やすために追加されるパッドバイトは含まない。コントローラ１０２の送信パーサ１６２は、送信フレーム２００のヘッダを構文解析して、ＩＰバージョン（ＩＰｖ４またはＩＰｖ６）と各種ヘッダの位置を決定する。ＩＰｖ４  ＴＯＴＡＬ  ＬＥＮＧＴＨはＩＰｖ４データグラムのバイト単位の長さであり、ＩＰｖ４ヘッダ２０６ａ（図７Ａ）、ＴＣＰヘッダ２０４、およびＴＣＰデータ２０２を含むが、ＭＡＣヘッダ２４０やＦＣＳは含まない。ＩＰのバージョンが４である場合、ハードウェアは、この情報を使用して、生成された各フレームの正しいＴＯＴＡＬ  ＬＥＮＧＴＨフィールドを生成する。ＩＰｖ６の場合、ＰＡＹＬＯＡＤ  ＬＥＮＧＴＨフィールドは、フレーム２００ｆの、第１のＩＰｖ６ヘッダとＦＣＳ間のバイト数として計算され、これにはＩＰｖ６拡張ヘッダが含まれる。ＩＰｖ４とＩＰｖ６の両方について、送信パーサ１６２は、ＴＣＰセグメント化が有効である場合に、生成された送信フレームのそれぞれに対して、ＴＯＴＡＬ  ＬＥＮＧＴＨまたはＰＡＹＬＯＡＤ  ＬＥＮＧＴＨのフィールド値を生成する。
【００９６】
生成されたＴＣＰセグメントはそれぞれ別個のＩＰフレームとして送信されるため、各セグメントフレームのＩＰｖ４ヘッダのＩＤＥＮＴＩＦＩＣＡＴＩＯＮフィールドは一意である。このようなセグメントフレームの先頭のセグメントフレームでは、その先頭のセグメントフレームを組み立てる際に、送信パーサ１６２によって、ＩＤＥＮＴＩＦＩＣＡＴＩＯＮフィールドが、入力フレームから第１のメモリ１１６の適切な位置にコピーされる。パーサ１６２は、前のフレームに使用した値を１つインクリメントして、後続のセグメントフレームのＩＤＥＮＴＩＦＩＣＡＴＩＯＮフィールドを生成する。ＴＣＰヘッダ２０４のＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲフィールドについては、ＴＣＰプロトコルソフトウェア１８６は、２つのネットワークノード間の論理接続を確立して、この接続を介して一方向に送信されるすべてのＴＣＰユーザデータを、バイトの連続するストリームとして処理し、これらのフレームのそれぞれに、シーケンス番号が割り当てられる。先頭のＴＣＰパケットのＴＣＰ  ＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲフィールドには、ＴＣＰデータフィールド２０２の先頭バイトのシーケンス番号が格納される。この同じ論理接続を介して送信される次のＴＣＰパケットのＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲフィールドは、前のパケットのシーケンス番号に、前のパケットのＴＣＰデータフィールド２０２のバイト長を加算した値となる。自動ＴＣＰセグメント化が有効な場合、コントローラ１０２の送信パーサ１６２は、元のフレームのＴＣＰ  ＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲフィールドを、先頭のセグメントフレーム２００のシーケンス番号に使用し、後続のフレーム２００のＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲは、前のセグメントフレーム２００のＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲフィールド値に、その前のフレーム２００のＴＣＰデータフィールド２０２の長さを加算して得る。
【００９７】
ＴＣＰプッシュ（ＰＳＨ）フラグは、例えば、入力バッファに、複数の受信フレームのための空間が存在しうる場合に、受信側に対し、受信側の入力バッファが一杯になるのを待たずに、受信側が受信フレームを直ちに処理しなければならないことを示す。自動ＴＣＰセグメント化が要求されている場合、コントローラ１０２のパーサ１６２は、生成された全フレーム２００のＰＳＨビットを０にセットするが、最後のフレーム２００は例外で、元の入力フレームのＰＳＨビットの値（ＴＣＰレイヤソフトウェア１８６によって設定された値）がセットされる。ＴＣＰフィニッシュ（ＦＩＮ）フラグは、受信側に対し、送信側に送信すべきデータがもはや存在しないことを示す。自動ＴＣＰセグメント化が要求されている場合、パーサ１６２は、最後のフレーム２００を除く、生成された全フレーム２００のＦＩＮビットを０にセットする。パーサ１６２は、最後に生成されたセグメントフレーム２００のＦＩＮビットの値に、元の入力フレーム（例えば、ＴＣＰレイヤソフトウェア１８６から等）のＦＩＮビットの値を挿入する。
【００９８】
チェックサムの生成および検証
【００９９】
代表的なコントローラ１０２は、送信されるフレーム２００について、レイヤ３（例えばＩＰ）および／またはレイヤ４（例えばＴＣＰ、ＵＤＰ等）のチェックサムを生成すると共に、着信（例えば、受信された）フレーム２００について、このようなチェックサムを自動的に検証するようにプログラムまたは構成されうる。代表的なコントローラ１０２は、ＩＰｖ４フレーム２００ｅのために、ＲＦＣ  ７９１（インターネットプロトコル）に規定されているＩＰチェックサムと、ＲＦＣ  ７９３（伝送制御プロトコル）に規定されているＴＣＰチェックサム、ＩＰｖ４フレームのためにＲＦＣ  ７６８（ユーザデータグラムプロトコル）に規定されているＵＤＰチェックサムのほか、ＩＰｖ６フレーム２００ｆのためにＲＦＣ  ２４６０（インターネットプロトコル、バーション６仕様）に記載されているＴＣＰチェックサムおよびＵＤＰチェックサムに対応している。ＩＰチェックサムについていえば、ＩＰｖ４ヘッダ２０６ａのＨＥＡＤＥＲ  ＣＨＥＣＫＳＵＭフィールドの値は、送信チェックサムシステム１６４において、ＩＰヘッダ２０６ａの全データの１の補数和の１６ビットの１の補数として計算され、一連の１６ビットのワードとして扱われる。ＴＯＴＡＬ  ＬＥＮＧＴＨフィールドとＩＤＥＮＴＩＦＩＣＡＴＩＯＮフィールドは、生成されたセグメントフレーム２００ｅのそれぞれについて異なっているため、送信チェックサムシステム１６４は、コントローラ１０２が生成する各セグメントフレームについてＨＥＡＤＥＲ  ＣＨＥＣＫＳＵＭフィールド値を計算する。
【０１００】
また、送信チェックサムシステム１６４は、発信フレーム２００のＴＣＰレイヤチェックサムも計算しうる。ＴＣＰヘッダ２０４のＴＣＰ  ＣＨＥＣＫＳＵＭフィールドの値は、ＴＣＰヘッダ２０４、ＴＣＰデータ２０２、およびＩＰヘッダの情報を格納している疑似ヘッダの各内容の１の補数和の１６ビットの１の補数として計算される。ヘッダとデータフィールドは一連の１６ビット数として処理される。チェックサムの計算中は、チェックサムフィールド自体はゼロで置き換えられる。また、チェックサムは、概念上ＴＣＰヘッダの前に置かれる９６ビットの擬似ヘッダ（図８Ｃまたは８Ｄ）もカバーしている。この疑似ヘッダは、発信元アドレス、宛先アドレス、プロトコルおよびＴＣＰ長を格納している。ＴＣＰデータフィールドに含まれるバイト数が奇数の場合、チェックサムの計算のため、最終バイトの右側にゼロがパディングされる。（このパッドバイトは送信されない）。セグメントフレーム２００のＴＣＰチェックサムを生成するために、送信チェックサムシステム１６４は、ＴＣＰヘッダ２０４のＴＣＰ  ＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲフィールド、およびＰＳＨビットとＦＩＮビットを更新し、ＴＣＰ  ＣＨＥＣＫＳＵＭフィールドを、元の入力フレーム２００のＴＣＰ  ＣＨＥＣＫＳＵＭフィールドの値に設定する。更に、送信チェックサムシステム１６４は、ＴＣＰヘッダ２０４にＴＣＰデータフィールド２０２を加えたバイト単位の長さで、内部の１６ビットのチェックサムアキュムレータを初期化して、このセグメントの変更されたＴＣＰヘッダ２０４と後続するＴＣＰデータ２０２を構成している１６ビットの全ワードの１の補数和をアキュムレータに加えて、得られた結果の１の補数を、セグメントフレーム２００のＴＣＰ  ＣＨＥＣＫＳＵＭフィールドに記憶する。
【０１０１】
送信記述子１９２ａのＩＰＣＫビットとＬ４ＣＫビット（図５Ｆ）は、コントローラ１０２における送信フレーム２００のチェックサムの自動生成を制御する。ＩＰＣＫビットがセットされていると、ＩＰチェックサムヘッダが生成されて、図７ＡのＩＰｖ４フレーム２００ｅの適切な位置に挿入される。同様に、Ｌ４ＣＫがセットされていると、発信フレーム２００に存在するレイヤ４ヘッダの種類に応じて、ＴＣＰチェックサムかＵＤＰチェックサムのいずれかが生成される。ＩＰｖ６ヘッダ２０６ｂ（図７Ｂ）はヘッダチェックサムフィールドを有さないため、ＩＰｖ６フレーム２００ｆでは、記述子のＩＰＣＫビットが無視される。発信フレーム２００に対してＴＣＰまたはＵＤＰのチェックサムの生成が要求されている場合、レイヤ４ソフトウェア１８６は、疑似ヘッダチェックサムをＴＣＰまたはＵＤＰのチェックサムフィールドにも入れる。次に、コントローラ１０２は、この値を、ＴＣＰまたはＵＤＰのセグメント全体に対して計算したチェックサムと置き換えるが、ＴＣＰセグメント化が有効になっている場合、生成されたＴＣＰまたはＵＤＰのチェックサムの値は変わる。ＴＣＰセグメント化の場合は、疑似ヘッダチェックサム計算の際にＴＣＰ  ＴＯＴＡＬ  ＬＥＮＧＴＨに値０が使用される。ＴＣＰまたはＵＤＰのチェックサム生成の場合、上記で参照したＲＦＣに記載されているように、ＴＣＰ  ＴＯＴＡＬ  ＬＥＮＧＴＨの値は、ＴＣＰヘッダ２０４の長さの値にＴＣＰデータ２０２の長さを加えた値となる。
【０１０２】
コントローラ１０２は、受信したフレームについても、チェックサムおよびパッドチェックシステム１５６によって、チェックサムを検証するように、ホスト１１２によってプログラムまたは構成されうる。チェックサム検証が有効になっているか、またはセキュリティ（例えばＩＰｓｅｃ）処理が要求されている場合、コントローラ１０２は、着信（例えば受信された）フレームを調べて、ＩＰｖ４、ＩＰｖ６、ＴＣＰ、およびＵＤＰの各ヘッダを特定して、受信状態リング１９９（図５Ｊ）のエントリのＩＰ＿ＨＥＡＤＥＲフィールドとＬ４＿ＨＥＡＤＥＲフィールドに対応するコードを書き込んで、認識したレイヤ３および／またはレイヤ４のヘッダを示す。デバイスが、チェックサムを有するヘッダを認識した場合、受信チェックサムおよびパッドチェックシステム１５６は、ＲＦＣ  ７９１、ＲＦＣ  ７９３、ＲＦＣ  ７６８またはＲＦＣ  ２４６０に記載の通りに適切なチェックサムを計算して、この結果を、受信フレームに含まれるチェックサムと比較する。チェックサムが一致しない場合、デバイスは、対応する受信状態リングのエントリ１９９のＩＰ＿ＣＫ＿ＥＲＲビットおよび／またはＬ４＿ＣＫ＿ＥＲＲビットをセットする。
【０１０３】
次に図１２，１３Ａ，１３Ｂを参照して、送信チェックサムの生成を詳細に図示および説明する。図１２に、ＥＳＰセキュリティヘッダ２１０を有する発信データフレーム２００のＴＣＰチェックサム値２９０の生成に関して、コントローラ１０２の一部分が示されている。図１３Ａ，１３Ｂは、代表的なネットワークインタフェースコントローラ１０２において実装されうる送信チェックサムの処理方法３００を示す。発信データのＴＣＰチェックサム処理は、図１３Ａの３０２から開始し、３０３において、後続のヘッダタイプを決定するためにレイヤ３ヘッダ（例えばＩＰヘッダ）が構文解析され、３０４において、発信データフレームにセキュリティヘッダが存在するかどうかが判定される。図１２に示すように、組立ＲＡＭ１６０内の代表的なフレーム２００は、ＩＰヘッダ２０６と、これに続くＥＳＰセキュリティヘッダ２１０を有する。この場合、ＩＰヘッダ２０６は、そのＰＲＯＴＯＣＯＬ（ＩＰｖ４）フィールドまたはＮＥＸＴ  ＨＥＡＤＥＲ（ＩＰｖ６）フィールドの値が、後続のヘッダ２１０がＥＳＰセキュリティヘッダであることを示す５０となっている。コントローラ１０２において、送信チェックサムパーサ１６２はＩＰヘッダ２０６を構文解析し、ＩＰヘッダ２０６は同時に、このフィールドの値を確認するために、送信チェックサムシステム１６４と第１のメモリ２１６に送られる。ＩＰヘッダのＰＲＯＴＯＣＯＬ／ＮＥＸＴ  ＨＥＡＤＥＲフィールドの値が５０の場合、フレーム２００はセキュリティヘッダを有しており（３０４のＹＥＳ）、方法３００は３０６に進む。値が５０ではない場合、後述するように、方法は図１３Ｂの３４０に進む。
【０１０４】
３０６において、記述子管理ユニット１３０は、（例えば、ホストメモリ１０６を介して）ホストドライバ１９０から送信記述子１９２ａを取得し、３０８においてこの記述子から送信チェックサム情報を取得する。フレーム２００のＴＣＰチェックサム範囲にわたってＴＣＰチェックサム値２９０を計算するために、送信パーサ１６２は、ＴＣＰチェックサム範囲（例えば、ＴＣＰヘッダ２０４とＴＣＰデータパケット２０２を含む範囲）の先頭２９２と終わり２９４を決定する必要がある。これは、送信記述子１９２ａに与えられているチェックサム情報を使用して行うことができ、この情報には、ＴＦＬＡＧＳ１、ＰＡＤ＿ＬＥＮおよびＮＸＴ＿ＨＤＲの各フィールドがある（図５Ｅ，５Ｆ）。３１０において、ＴＦＬＡＧＳ１フィールドのＬ４ＣＫビットがチェックされる。この値が０の場合（３１０のＮＯ）、このフレーム２００にＴＣＰチェックサム処理が不要であることを示しているため、方法３００は３１２に進む。例えば、ホストシステム１８０がレイヤ４のチェックサムを計算する役割を果たしてもよく、その場合、フレーム２００が送信のためにコントローラ１０２に送られる前に、ＴＣＰヘッダ２１４が適切なチェックサム値を有している。
【０１０５】
Ｌ４ＣＫビットが１の場合（３１０のＹＥＳ）、方法３００は３１３に進み、送信パーサ１６２は、構文解析を行って、セキュリティヘッダに続くヘッダのヘッダタイプを決定する。次に、３１４において、セキュリティヘッダに続くヘッダが、レイヤ４ヘッダ（例えばこの例ではＴＣＰヘッダ）かどうかが決定される。レイヤ４ヘッダではない場合（３１４のＮＯ）、送信パーサ１６２は、レイヤ４のヘッダがみつかるまで、間に存在するヘッダ（例えば、図６Ｄに示すような拡張ヘッダ）の構文解析を続ける。レイヤ４のヘッダがみつかった場合、３１６および３１８において、記述子１９２ａから得たレイヤ４のヘッダタイプ情報がＴＣＰかＵＤＰのいずれであるかが判定される。図示した例では、記述子１９２ａから得た次ヘッダ情報がＴＣＰでもＵＤＰでもない場合（３１６および３１８のＮＯ）、コントローラ１０２は矛盾が存在するとみなして、方法３００は３１２に進む（レイヤ４のチェックサム値が計算されない）。記述子１９２ａから得た次ヘッダ情報により、セキュリティヘッダのあとにＵＤＰヘッダまたはＴＣＰヘッダがくることが示される場合（３１６または３１８のＹＥＳ）、方法３００は３２０および３２２に進み、送信チェックサム情報と構文解析されたレイヤ３のヘッダ情報に従って、レイヤ４のチェックサムの計算がそれぞれ開始および終了される。
【０１０６】
より詳細には、送信記述子１９２ａから得た次ヘッダ情報ＮＸＴ＿ＨＤＲが３２０において使用されて、レイヤ４のチェックサム計算の開始点が決定され、記述子１９２ａから得たパッド長ＰＡＤ＿ＬＥＮとＩＶ長の情報が３２２において使用される。パーサ１６２は、構文解析されたレイヤ３ヘッダ（図７Ａおよび７ＢのＩＰｖ４またはＩＰｖ６）からＩＰ全長またはペイロード長の情報を取得して、セキュリティヘッダ（３０３で構文解析済み）と間に存在するほかの全ヘッダ（３１５において構文解析済み）の長さの合計を減算し、更に、ＥＳＰトレーラ２１２とＥＳＰ認証フィールド２１４の長さを減算することによって、ＴＣＰデータフィールド２０２の終点の位置を確認する。ＥＳＰトレーラ２１２は、パディングバイト２３０（図６Ｅ）を含んでおり、その長さは送信記述子１９２ａのＰＡＤ＿ＬＥＮ情報からわかり、ＥＳＰ認証フィールド２１４の長さは、送信記述子１９２ａのＴＦＬＡＧＳ１部分１９３のＩＶＬＥＮ１ビットとＩＶＬＥＮ０ビットからわかる。この計算から得られる値は、ＴＣＰヘッダ２０４とＴＣＰデータ２０２の長さであり、これらは、３２２においてＴＣＰチェックサム計算の終了に使用される。
【０１０７】
送信パーサ１６２は、開始点２９２と終了点２９４に従ってチェックサム計算を開始するように送信チェックサムシステム１６２を制御し、システム１６４は、これに従ってチェックサム値２９０（例えば本例ではＴＣＰチェックサム値）を生成する。チェックサム値の計算が終了すると、方法３００は３２４に進み、送信チェックサムシステム１６４は、チェックサム値２９０を、第１のメモリ１１６の適切な位置（例えば、ＴＣＰヘッダ２０４内に）に挿入し、その後、３２６においてレイヤ４のチェックサム操作が終了する。その後、３２８において、選択された任意のセキュリティ処理が（例えば、ＩＰｓｅｃシステム１２４を使用して）実行され、３３０において、発信フレームがネットワーク１０８に送信される。レイヤ４のチェックサム生成が実行されない場合、方法３００は要求された任意のセキュリティ処理を実行するために３１２から３２８に直接に進み、その後、３３０においてフレームが送信される。
【０１０８】
図１３Ｂも参照すると、セキュリティヘッダが発信データフレーム２００に存在しない場合（３０４のＮＯ）、方法３００は図１３Ｂの３４０に進み、送信記述子１９２ａのＬ４ＣＫビットが１であるかどうかが判定される。Ｌ４ＣＫビットが１ではない場合（３４０のＮＯ）、方法３００は３４２に進み、フレーム２００に対してレイヤ４のチェックサム計算が実行されない。Ｌ４ＣＫビットが１の場合（３４０のＹＥＳ）、３４６および３４８において、レイヤ４のヘッダタイプがＴＣＰかＵＤＰかが判定される。記述子１９２ａから得た次ヘッダ情報がＴＣＰでもＵＤＰでもない場合（３４６および３４８のＮＯ）、コントローラ１０２は矛盾が存在するとみなして、方法３００は３４２に進む（レイヤ４のチェックサム値が計算されない）。次ヘッダ情報により、ＩＰヘッダ２０６の後にＵＤＰヘッダまたはＴＣＰヘッダがくることが示される場合（３４６または３４８のＹＥＳ）、３５０および３５２において構文解析された情報に従って、チェックサムの計算がそれぞれ開始および終了される。レイヤ４のチェックサム値の計算が３５２において終了すると、チェックサム値２９０がメモリ１１６にあるフレーム２００に挿入され、３５６において送信チェックサム操作が完了し、ＩＰｓｅｃシステム１２４は、フレーム２００を第２のメモリ１１８に渡す（例えばこの場合、セキュリティ処理は実行されない）。次に、方法３００は３３０（図１３Ａ）に戻り、フレーム２００がネットワーク１０８に送信される。
【０１０９】
セキュリティ処理
【０１１０】
ここで図２〜４，９，１０，１１Ａ〜１１Ｅを参照すると、代表的なＩＰｓｅｃセキュリティシステム１２４は、送信フレームおよび受信フレーム２００に対して、ＲＦＣ  ２４０１に準拠したインターネットプロトコルセキュリティ（ＩＰｓｅｃ）認証および／または暗号化／復号化サービスを提供するように構成可能である。認証ヘッダ（ＡＨ）処理については、このモジュールは、ＲＦＣ  ２４０４に規定されているＨＭＡＣ−ＭＤ５−９６アルゴリズム、およびＲＦＣ  ２４０４に規定されているＨＭＡＣ−ＳＨＡ−１−９６を実装している。ＨＭＡＣ−ＭＤ５−９６の実装は、１２８ビットキー、５１２ビットのブロックサイズ、および９６ビットに切り詰められた１２８ビットのメッセージ認証コード（message authentication：ＭＡＣ）に対応している。ＨＭＡＣ−ＳＨＡ−１−９６アルゴリズムの実装は、ｎ個の１６０ビットキー、５１２ビットのブロックサイズ、および９６ビットに切り詰められた１６０ビットのメッセージ認証コード（ＭＡＣ）に対応している。また、カプセル化セキュリティペイロード（ＥＳＰ）処理のために、ＩＰｓｅｃモジュール１２４は、認証用のＨＭＡＣ−ＭＤ５−９６およびＨＭＡＣ−ＳＨＡ−１−９６アルゴリズムと、ＥＳＰ  ＤＥＳ−ＣＢＣ（ＲＦＣ  ２４０６）、３ＤＥＳ−ＣＢＣ、およびＡＥＳ−ＣＢＣ（ｄｒａｆｔ−ｉｅｔｆ−ｉｐｓｅｃ−ｃｉｐｈ−ａｅｓ−ｃｂｃ−０１）暗号化アルゴリズムを実装している。ＩＰｓｅｃモジュール１２４のＤＥＳ−ＣＢＣアルゴリズムは、６４ビットキー（８つのパリティビットを含む）、６４ビットのブロックサイズ、および明示的な（explicit）初期化ベクトル（ＩＶ）による暗号ブロック連鎖方式（cipher block chaining：ＣＢＣ）に対応している。３ＤＥＳ−ＣＢＣアルゴリズムは、１９２ビットキー（２４のパリティビットを含む）、６４ビットのブロックサイズ、および明示的なＩＶによるＣＢＣに対応している。ＡＥＳ−ＣＢＣアルゴリズムは、１２８ビット、１９２ビットまたは２５６ビットのキー、１０ラウンド、１２ラウンドまたは１４ラウンド（キーサイズによって異なる）、１２８ビットのブロックサイズ、および明示的なＩＶによるＣＢＣに対応している。
【０１１１】
代表的なセキュリティシステム１２４は、ＩＰｖ４およびＩＰｖ６に対して、暗号に基づいたＩＰｓｅｃセキュリティサービスを提供しており、これには、アクセス制御、コネクションレス整合性、データ起源認証、再実行（replay）に対する保護（部分的なシーケンスの整合性の一種）、機密性（暗号化）および制限されたトラフィックフローの機密性が含まれる。これらのサービスはレイヤ３（ＩＰレイヤ）において提供され、これによって、認証ヘッダ（ＡＨ）およびカプセル化セキュリティペイロード（ＥＳＰ）の２種類のトラフィックセキュリティプロトコルを用いることにより、および暗号化キー管理の手順およびプロトコルを用いることにより、ＩＰプロトコルおよび／または上位層のプロトコルに対する保護が提供される。ＩＰ認証ヘッダ（ＡＨ）は、コネクションレス整合性、データ起源認証、および任意選択の対再実行（anti-replay）サービスを提供し、ＥＳＰプロトコルは機密性（暗号化）および制限されたトラフィックフロー機密性を提供し、コネクションレス整合性、データ起源認証、および対再実行サービスを提供してもよい。ＡＨとＥＳＰの様々なセキュリティ機能は、ＩＰｖ４およびＩＰｖ６におけるセキュリティサービスの所望の組み合わせを提供するために、単独で用いられても併用されてもよく、この２つのプロトコルは、トランスポートモードとトンネルモードに対応している。トランスポートモードでは、プロトコルは主に上位層のプロトコルに対する保護を提供しており、トンネルモードでは、プロトコルがトンネルされたＩＰパケットに適用される。
【０１１２】
発信フレーム２００の場合、コントローラ１０２は、ＳＡメモリ１４０に記憶されているセキュリティアソシエーション（ＳＡ）に従って、ＩＰｓｅｃ認証処理および／または暗号化処理を選択的に提供する。発信フレーム２００にＩＰｓｅｃ認証が要求されている場合、ＩＰｓｅｃユニット１２４は整合性確認値（ＩＣＶ）を計算して、このＩＣＶをＡＨヘッダまたはＥＳＰトレーラ２１２（図６Ａ〜６Ｄ）に挿入する。フレーム２００に暗号化が要求されている場合、ユニット１２４は平文のペイロードを、暗号化されたペイロードで置き換える。着信（例えば、受信された）フレームの場合、ＩＰｓｅｃユニット１２４は、実行が必要な処理を決定するために、ＩＰｓｅｃヘッダを構文解析する。ＩＰｓｅｃヘッダがみつかった場合、ＩＰｓｅｃシステム１２４は、このヘッダから得たセキュリティパラメータインデックス（ＳＰＩ）のほかに、ＩＰｓｅｃプロトコルタイプおよびＩＰ宛先アドレスを使用して、ＳＡメモリ１４０を検索し、受信フレームに対応するセキュリティアソシエーションを取得する。代表的なコントローラ１０２のためのＩＰｓｅｃヘッダの可能な組合せには、ＡＨヘッダ、ＥＳＰヘッダ、およびＥＳＰヘッダに続くＡＨヘッダが含まれる。
【０１１３】
ＩＰｓｅｃキー交換のために、ホスト１１２は、遠隔局との間でＳＡをネゴシエートし、ＳＡデータをＳＡメモリ１４０に書き込む。更に、ホスト１１２は、システムメモリ１２８に、ＩＰｓｅｃセキュリティポリシーデータベース（security policy database：ＳＰＤ）を維持管理している。送信するフレーム２００のそれぞれについては、ホストプロセッサ１１２は、ＳＰＤをチェックして、必要なセキュリティ処理を決定し、この情報を、送信記述子１９２ａにおいて、ＳＡメモリ１４０内の適切なＳＡへのポインタＳＡ＿ＰＴＲ［１４:０］としてコントローラ１０２（図５Ｅ）に渡す。着信する受信フレーム２００については、コントローラ１０２は、実行したセキュリティ処理を受信状態リングのエントリ１９９（図５Ｊ）に書込み、ホストプロセッサ１１２は、フレーム２００がネゴシエートされたポリシーに適合していることを検証するために、ＳＰＤを調べる。ＳＡには、実行すべきセキュリティ処理のタイプと、使用する暗号化キーのタイプを規定している情報が含まれる。個々のセキュリティアソシエーションは、２つのネットワークエンティティ間の一方向の接続について規定しており、双方向接続では、着信トラフィック用と発信トラフィック用の２つのＳＡが必要となる。着信トラフィック用のＳＡは、一部が内部のＳＰＩテーブルまたはメモリ２７０（図１０）に記憶され、一部が外部ＳＡメモリ１４０に記憶されている。これらのＳＡテーブルは、ホストプロセッサ１１２によって維持管理されており、ホストプロセッサ１１２は、最初に、ホストメモリ１２８のＳＡデータバッファに書き込み、次に、ＳＡアドレスレジスタに命令を書き込むことによって、ＳＰＩテーブル２７０とＳＡメモリ１４０に間接的に書き込む。これを受けて、コントローラ１０２が、外部ＳＡメモリ１４０と内蔵ＳＰＩテーブルメモリ２７０にデータをコピーする。
【０１１４】
ＳＰＩテーブルのエントリのフィールドのうちの１つは、ＩＰ宛先アドレスに従ってホスト１１２によって計算されたハッシュコードである。更に、ホスト１１２は、ＳＰＩに基づいてハッシュコードを計算して、ＳＰＩテーブルの書き込み先を決定する。着信ＳＡまたは発信ＳＡが認証を要求している場合、ホストＣＰＵはＲＦＣ  ２１０４  ＨＭＡＣ：Keyed-Hashing for Message Authenticationに規定されている値Ｈ（Ｋ  ＸＯＲ  ｉｐａｄ）および値Ｈ（Ｋ  ＸＯＲ  ｏｐａｄ）を計算して、ホスト１１２が、得られた２つの１２８ビットまたは１６０ビットの値をＳＡメモリ１４０に記憶する。初期化時に、必要に応じて、ホストＣＰＵは、ＩＰｓｅｃシステム１２４の４つの暗号化エンジンの各々において、暗号ブロック連鎖方式に使用する初期化ベクトル（ＩＶ）レジスタを間接的に初期化してもよい。
【０１１５】
図２，９を参照すると、送信プロセスを開始するために、ホストプロセッサ１１２は、ホストメモリ１２８の１つ以上のデータバッファ１９４内に送信フレーム２００を作成し、送信記述子リングの１つに送信記述子１９２ａ（例えば図５Ｅ）を書き込んで、対応する送信記述子書込みポインタ（ＴＸ＿ＷＲ＿ＰＴＲ［ｘ］）を更新する。データバッファ１９４にあるフレームデータは、認証データ２１４、初期化ベクトル（ＩＶ）２２６、および必要な場合はＥＳＰトレーラ２１２（例えば図６Ｅ）のための空間をＩＰｓｅｃヘッダ内に有する。これらのフィールドの内容は、コントローラ１０２のＩＰｓｅｃシステム１２４によって生成される。同様に、パディングが必要な（例えば、アライメントのため、またはＥＳＰペイロードを暗号化ブロックの整数倍にするために）場合、ホストメモリバッファ１９４にパディングが含まれ、ＡＨフィールドとＥＳＰ  ＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲフィールドのためのシーケンス番号が、ホスト１１２によってデータバッファ１９４に提供される。自動ＴＣＰセグメント化も選択されている場合を除き、ＩＰｓｅｃシステム１２４がこれらのフィールドを変更することはないが、自動ＴＣＰセグメント化が選択されている場合には、ＩＰｓｅｃシステム１２４は、生成される先頭フレーム２００には、バッファ１９４内のシーケンス番号を使用し、以降生成されるセグメントフレームには、これらの数を適宜インクリメントする。特定の発信フレーム２００にＩＰｓｅｃ処理が要求されている場合、対応する送信記述子１９２ａは、外部ＳＡメモリ１４０内の適切なＳＡエントリをポイントしているポインタをＳＡ＿ＰＴＲフィールドに有しており、ＩＰｓｅｃシステム１２４は、フレーム２００の処理方法を決定するために、ＳＡの情報を使用する。送信パーサ１６２は、フレーム２００を調べて、必要であれば認証および／または暗号化の開始点と終了点、ならびに認証データ２１４の挿入位置を決定する。
【０１１６】
ＥＳＰ暗号化が要求されている場合、ＩＰｓｅｃシステム１２４は、ＳＡに指定されているアルゴリズムとキーを使用して、ペイロードデータを暗号化する。ＥＳＰ認証が要求されている場合、システム１２４は、ＳＡに指定されている認証アルゴリズムとＩＰＡＤ／ＯＰＡＤ情報を使用して認証データ整合性確認値（ＩＣＶ）を計算し、この結果を認証データフィールド２１４に記憶する。ＥＳＰ暗号化と認証の両方が要求されている場合、最初に暗号化が行われ、次に暗号化されたペイロードデータが認証の計算に使用される。一方のＩＰｓｅｃプロセッサ１７４の暗号化エンジンが、あるデータブロックを処理している間に、認証エンジンがその前のブロックを処理するように、暗号化プロセスと認証プロセスがパイプライン化される。自動ＴＣＰセグメント化も有効になっている場合を除き、ＩＰｓｅｃシステム１２４がペイロードデータフィールドにパディングを追加することはない。ホストプロセッサ１１２は、システムメモリ１２８内のフレームデータバッファ１９４に適切にパディングを行ってＥＳＰトレーラ２１２を提供し、更に、ＥＳＰヘッダ２１０（図６Ｅ）のＥＳＰ  ＳＥＱＵＥＮＣＥ  ＮＵＭＢＥＲフィールドに適切な値を提供する。
【０１１７】
ＥＳＰ処理が自動ＴＣＰセグメント化と併用される場合、ＩＰｓｅｃシステム１２４は、暗号化されたデータの長さを、指定された暗号化アルゴリズムに指定されているブロック長の倍数にするために、必要なパッドバイトを追加するＥＳＰ処理が、ＴＣＰまたはＵＤＰチェックサムの生成と併用される場合、ホスト１１２はＥＳＰトレーラ２１２と送信記述子１９２ａ（図５Ｅ）のために、ＮＥＸＴ  ＨＥＡＤＥＲとＰＡＤ  ＬＥＮＧＴＨの適切な値を提供する。ＥＳＰ処理が自動ＴＣＰセグメント化と併用される場合、ホスト１１２は、対応するフレームデータバッファ１９４と整合する値を、送信記述子１９２ａのＮＥＸＴ  ＨＥＡＤＥＲフィールドおよびＰＡＤ  ＬＥＮＧＴＨフィールドのために提供する。この組合せでは、コントローラ１０２は、送信記述子１９２ａのＮＥＸＴ  ＨＥＡＤＥＲフィールドを、生成されたフレーム２００のそれぞれのＥＳＰトレーラ２１２にコピーし、記述子１９２ａのＰＡＤ  ＬＥＮＧＴＨフィールドを使用して、フレームデータバッファ１９４内でＴＣＰデータフィールド２０２の終点をみつける。更に、送信記述子１９２ａの最大セグメントサイズフィールドＭＳＳ［１３:０］が、ＩＰｓｅｃヘッダ、ＥＳＰパディングおよびＩＣＶに対応して減算される。
【０１１８】
ＥＳＰ処理が、ＴＣＰセグメント化またはＴＣＰまたはＵＤＰのチェックサム生成と併用される場合、ソフトウェアドライバ１９０は、送信記述子１９２ａのＥＳＰ＿ＡＨ、ＩＶＬＥＮ０、およびＩＶＬＥＮ１の各ビットを適宜セットする。送信パーサ１６２は、この情報を使用して、ＴＣＰヘッダまたはＵＤＰヘッダ２０４を特定し、ＴＣＰまたはＵＤＰの処理が不要な場合はこれらのビットが無視される。ＥＳＰ処理を要求しているフレーム２００について、図８Ａは、ホスト１１２によって作成されバッファ１９４に含まれるフィールド、セキュリティシステム１２４のＥＳＰ処理ハードウェアによって変更されるフィールドを示す。
【０１１９】
ＩＰｓｅｃシステム１２４がサポートしている暗号化アルゴリズムは、明示的な初期化ベクトル（図６ＥのＩＶ２２６）による暗号ブロック連鎖（ＣＢＣ）モードを使用する。一定量のパラレル処理が行われるように、ＩＰｓｅｃシステム１２４は、２つの送信ＩＰｓｅｃプロセッサシステム１７４ａ，１７４ｂを有し、これらはそれぞれ、ＤＥＳ／３ＤＥＳ（データ暗号化標準）暗号化システム、およびＡＥＳ（advanced encryption standard）暗号化エンジンを有する。送信ＩＰｓｅｃプロセッサ１７４の４つの暗号化エンジンはそれぞれＩＶレジスタを有し、これはリセット時にゼロにクリアされる。コントローラ１０２が有効な場合、暗号化エンジンに関連するＩＶレジスタの内容が、そのエンジンによって暗号化される最初の送信フレーム２００に対する初期化ベクトル２２６として使用される。その後、あるフレーム２００で最後に暗号化されたデータブロックが、後続のフレーム２００のＩＶ２２６として使用される。ホストプロセッサ１１２は、例えば、ペイロードフィールドにランダムなデータを有するフレーム２００を送信することによって、ＩＰｓｅｃシステム１２４のＩＶレジスタをランダムなデータで初期化しうる。１つの例では、ホスト１１２は、外部のＰＨＹデバイスを隔離モードにして、これらのランダムデータフレーム２００が、ネットワーク１０８に送られないようにしうる。ＩＰｓｅｃシステム１２４は、ペイロードフィールドの先頭にＩＶ値２２６を挿入する。ホスト１１２は、このフィールド２２６用に、フレームデータバッファ１９４内の空間を提供する。ＩＶ２２６の長さは、送信ＩＰｓｅｃプロセッサ１７４で使用される暗号化ブロックのサイズと同じであり、例えばＤＥＳおよび３ＤＥＳアルゴリズムでは６４ビット、ＡＥＳアルゴリズムでは１２８ビットである。
【０１２０】
認証ヘッダ（ＡＨ）処理が選択されている場合、セキュリティシステム１２４は、ＳＡに指定されている認証アルゴリズムと認証ｉｐａｄおよびｏｐａｄデータを使用して認証データ整合性確認値（ＩＣＶ）を計算し、その結果を認証データフィールド２１４に記憶する。送信ＩＰｓｅｃパーサ１７０は、可変フィールド（ＡＨ仕様、ＲＦＣ  ２４０２に規定されている）を検出し、ＩＣＶの計算のために、これらのフィールドと認証データフィールド２１４の内容がゼロで扱われることを保証する。ＩＣＶの計算において、ＩＰｓｅｃシステム１２４は、パケットのＩＰヘッダ２０６にある宛先アドレスではなく、ＳＡにある宛先アドレスを使用して、ソースルーティングオプションまたは拡張がある場合、最終的な宛先アドレスが計算に確実に使用されるようにする。ＡＨ処理を要求している送信フレーム２００に関し、図８Ｂは、ホスト１１２によって作成され、バッファ１９４に含まれるフィールドと、ＩＰｓｅｃシステム１２４のＡＨ処理ハードウェアによって変更されるフィールドとを示す。
【０１２１】
ここで図２，１０を参照すると、ＩＰｓｅｃシステム１２４は、ネットワーク１０８から着信した（例えば、受信した）フレーム２００に対するセキュリティ処理を提供する。受信パーサ１４４は、着信フレーム２００を調べてＩＰｓｅｃヘッダを特定し、対応するＳＡをＳＡメモリ１４０内で検索する。次に、受信ＩＰｓｅｃプロセッサ１５０は、このＳＡに従って、要求されているＩＰｓｅｃ認証および／または復号化を実行する。復号化が要求されている場合、プロセッサ１５０は、フレーム２００内の元の暗号文を、メモリ１１６内の平文で置き換える。記述子管理ユニット１３０は、実行された処理と発生したエラーを示すために、対応する受信状態リングのエントリ１９９（図５Ｊ）の状態ビットをセットする。
【０１２２】
図１０は、ＩＰｓｅｃシステム１２４による着信データのフローを示す。受信パーサ１４４は、ネットワーク１０８から着信フレーム２００を受信中に、ＭＡＣエンジン１２２から得た着信フレーム２００のヘッダを調べる。パーサ１４４は、その分析結果をＳＡルックアップロジック１４６に渡す。この情報は、フレーム２００間に挿入される制御ブロックの形でメモリ１１８にも提供される。この制御ブロックは、ヘッダのタイプと、着信フレーム２００内でのその位置に関する情報を含む。パーサ１４４が、フレーム２００にＩＰパケットのフラグメントが含まれていることを発見した場合、ＩＰｓｅｃ処理がバイパスされて、フレーム２００が、ホストメモリ１２８に渡され、その際、対応する受信状態リングのエントリ１９９のＩＰＳＥＣ＿ＳＴＡＴ１フィールドのＩＰ  Ｆｒａｇｍｅｎｔビットがセットされる。ＩＰｖ４フレームの場合、ＩＰｖ４ヘッダのＦｒａｇｍｅｎｔ  ｏｆｆｓｅｔフィールドがゼロ以外の値に設定されているか、またはｍｏｒｅ  ｆｒａｇｍｅｎｔｓビットがゼロ以外の値に設定されていれば、フラグメント化されている。ＩＰｖ６パケットの場合、フラグメント拡張ヘッダがあれば、フラグメント化されている。
【０１２３】
パーサ１４４がＩＰｓｅｃヘッダまたは許容されるヘッダの組合せを特定した場合、パーサ１４４は、ＳＰＩ、ＩＰ宛先アドレス、およびＩＰｓｅｃプロトコル（ＡＨまたはＥＳＰ）を示すビットをＳＡルックアップエンジン１４６に渡す。ＳＡルックアップエンジン１４６は、ＳＰＩ、プロトコルビットおよび宛先アドレスのハッシュを使用して、内部ＳＰＩメモリ２７０（図１０）を検索する。この検索の結果は、ＳＡポインタＦＩＦＯ１４８に書き込まれ、これには、外部ＳＡメモリ１４０にあるエントリへのポインタ、ＩＰｓｅｃ処理の要否を示すビット、ＳＡ検索の成否を示す２ビットが含まれる。ＳＡポインタＦＩＦＯ１４８は、メモリ１１８にある着信フレーム２００のそれぞれに対応するエントリを有する。ネットワーク１０８から着信フレーム２００が到着した時点でＳＡポインタＦＩＦＯ１４８に新しいエントリのための空きがない場合、または受信したフレーム２００によってメモリ１１８の受信部分がオーバーフローしてしまう場合、フレーム２００は破棄されて、受信ミスパケットカウンタ（図示せず）がインクリメントされる。
【０１２４】
受信キー取得ステートマシン２６２（図１０）は、ＳＡポインタＦＩＦＯ１４８から、対応するエントリを取得して、要求されている処理があればそれを決定する。制御ビットにより、処理が要求されていることが示される場合、ステートマシン２６２は、ポインタフィールドの内容を使用して、外部ＳＡメモリ１４０からＳＡ情報を取得する。ＳＡのＤＡフィールドがフレーム２００のＩＰヘッダのＤＡフィールドと一致しない場合、ＩＰｓｅｃプロセッサ１５０は、受信状態リング１９９にエラーコードを書き込ませて、フレーム２００を変更せずにメモリ１１８に渡す。ＳＡのＤＡフィールドがＩＰヘッダのＤＡフィールドと一致する場合、プロセッサ１５０は、ＳＡが要求しているように、受信フレーム２００のペイロード部分を復号化するか、認証データを検証するか、この両方を行う。
【０１２５】
図１１Ａ〜１１Ｄも参照して、代表的なコントローラ１０２の発信ＩＰｓｅｃ処理に使用されるセキュリティアソシエーションシステムについて以下に記載する。図１１Ａは、代表的なセキュリティアソシエーションテーブルの書込みアクセスを示し、図１１Ｂは、代表的なＳＡアドレスレジスタのフォーマットを示し、図１１Ｃは、ＳＰＩメモリ２７０内の代表的なＳＰＩテーブルエントリを示し、図１１Ｄは、ＳＡメモリ１４０内の代表的なＳＡメモリエントリを示す。ＳＡルックアップエンジン１４６はＳＰＩメモリ２７０と外部ＳＡメモリ１４０を使用するが、この両者はホストプロセッサ１１２によって維持管理されており、代表的なＳＰＩメモリ２７０は、それぞれが最大４つのエントリを有する４０９６個のビンの集まりとして編成されている。ＳＰＩメモリ２７０内のエントリのアドレスは１４ビット長であり、そのうちの上位１２ビットはビン番号を示す。図１１Ｃに示すように、ＳＰＩメモリ２７０内のＳＰＩテーブルの各エントリ２７２は、それぞれ、３２ビットのセキュリティパラメータインデックスＳＰＩ［３１:０］、宛先アドレスのハッシュＤＡ＿ＨＡＳＨ［３９:３２］、セキュリティプロトコル（例えばＡＨまたはＥＳＰ）を示すプロトコルビットＰＲＯＴＯ、およびこのエントリが有効であるか未使用かを示すＶＡＬＩＤビットを有する。
【０１２６】
図１１Ｄは、ＳＡメモリ１４０内の代表的なエントリ２７４を示しており、ＳＡメモリ１４０は、ＳＰＩメモリ２７０内の各エントリ２７２に対応したエントリを有し、２つのメモリ１４０，２７０に存在するエントリ２７４，２７２の順序は同じである。エントリ２７４は、ＥＳＰ暗号化の要否と、要求されている場合は使用するアルゴリズム（例えば、ＤＥＳ；３ＤＥＳ；ＡＥＳ−１２８、１０ラウンド；ＡＥＳ−１９２、１２ラウンド；ＡＥＳ−２５６、１４ラウンドなど）を示す３ビットのＥＳＰ暗号化アルゴリズムフィールドＥＳＰ＿ＡＬＧを有する。電子コードブックビットＥＣＢは、暗号化にＥＣＢモードが使用されるかどうかを示し、２ビットのＥＳＰ認証フィールドＥＳＰＡＨ＿ＡＬＧは、ＥＳＰ認証の要否と、要求されている場合は使用するアルゴリズム（例えばＭＤ５、ＳＨＡ−１など）を示している。２ビットのＡＨフィールドＡＨ＿ＡＬＧは、ＡＨ処理の要否と、要求されている場合は使用するアルゴリズム（例えばＭＤ５、ＳＨＡ−１など）を示している。プロトコルビットＰＲＯＴＯＣＯＬは、最初のＩＰｓｅｃヘッダがＥＳＰヘッダ、ＡＨヘッダのいずれであるかを示し、ＩＰｖ６ビットは、ＳＡがＩＰｖ４フレームかＩＰｖ６フレームのいずれに対して定義されているかを示している。
【０１２７】
ＢＵＮＤＬＥビットは、ＡＨとその後に続くＥＳＰを指定している２つのＳＡのバンドルを示し、３２ビットのＳＰＩフィールドは、２つのＳＡのバンドルのうちの第２のＳＡ（例えばＥＳＰ）と関連するＳＰＩを指定しており、これは、バンドルに属していないＳＡでは無視される。ＩＰ宛先アドレスフィールドＩＰＤＡ［１２７:０］は、ＳＡが適用可能なアドレスを示しており、ＳＡはこの宛先アドレスを含むパケットのみに適用される。ＡＨ＿ＩＰＡＤフィールドは、ＲＦＣ  ２１０４に規定されているＡＨ認証キーとＨＭＡＣ  ｉｐａｄ文字列の排他的ＯＲに適切な認証ハッシュ関数（例えばＭＤ５またはＳＨＡ−１）を適用することによって得られる値を含む。認証関数がＭＤ５の場合、結果は１６バイトであり、オフセット２４から始まる連続するバイトに記憶される。認証関数がＳＨＡ−１の場合、結果は２０バイトであり、ＡＨ＿ＩＰＡＤフィールドの全体を占める。ＡＨ＿ＯＰＡＤフィールドは、ＲＦＣ  ２１０４に規定されているＡＨ認証キーとＨＭＡＣ  ｏｐａｄ文字列の排他的ＯＲに適切な認証ハッシュ関数（例えばＭＤ５またはＳＨＡ−１）を適用することによって得られる値を含む。認証関数がＭＤ５の場合、結果は１６バイトであり、オフセット４４から始まる連続するバイトに記憶される。認証関数がＳＨＡ−１の場合、結果は２０バイトであり、ＡＨ＿ＯＰＡＤフィールドの全体を占める。また、ＳＡメモリエントリ２７４は、ＲＦＣ  ２１０４に規定されているＥＳＰ認証キーとＨＭＡＣ  ｉｐａｄ文字列の排他的ＯＲに認証ハッシュ関数（例えばＭＤ５またはＳＨＡ−１）を適用することによって得られる値を含むＥＳＰ＿ＩＰＡＤフィールドと、ＲＦＣ  ２１０４に規定されているＥＳＰ認証キーとＨＭＡＣ  ｏｐａｄ文字列の排他的ＯＲに認証ハッシュ関数（例えばＭＤ５またはＳＨＡ−１）を適用することによって得られる値を含むＥＳＰ＿ＯＰＡＤフィールドとを含む。暗号化キーフィールドＥＮＣ＿ＫＥＹは、ＥＳＰ処理に使用される暗号化／復号化キーを含む。
【０１２８】
ＩＰｓｅｃシステム１２４は、ＳＡメモリ１４０およびＳＰＩメモリ２７０を読み出すものの、これらに書き込むことはしない。ＳＰＩメモリ２７０は、探索時間をできる限り短縮するためにハッシュテーブルとして構成されており、エントリ２７２のビン番号は、ＳＰＩのハッシュ関数によって決定される。ルックアップロジック１４６は、ＳＰＩプロトコルとＩＰｓｅｃプロトコル（ＡＨまたはＥＳＰ）を使用してＳＰＩメモリ２７０を検索し、その際、ＳＰＩに基づいてハッシュ値を計算して、この結果を使用して、ＳＰＩメモリ２７０内のビンのアドレスを指定する。ＩＰ宛先アドレスの第２のハッシュ値が計算され、ルックアップロジック１４６は、ＳＰＩ、プロトコルおよび宛先アドレスのハッシュを、選択されたビンのエントリと、一致するエントリがみつかるかビンにエントリがなくなるまで比較する。次に、ルックアップロジック１４６は、ＳＡポインタＦＩＦＯ１４８に、エントリを書き込み、これには、ＳＰＩメモリ２７０にある一致するエントリのアドレス、ＩＰｓｅｃ処理の要否と、ＳＡ探索の成否を示す内部状態コードが含まれる。受信キー取得ロジック２６２は、ＳＡメモリ１４０からＤＡを取得して、ＩＰパケットヘッダのＤＡと比較する。ＳＡメモリ１４０から得たＤＡが受信フレーム２００のＤＡと一致しない場合、フレーム２００が、ＩＰｓｅｃ処理を行わずに、メモリ１１６およびバスインタフェース１０６を介してホストメモリ１２８に渡され、対応する受信状態リングのエントリ１９９が、ＩＰｓｅｃ処理が実行されなかったことを示すように更新される。
【０１２９】
図１１Ａも参照すると、ＳＡメモリ１４０とＳＰＩメモリ２７０は、ホストプロセッサ１１２によって維持管理される。通常動作中に、ホスト１１２は書込みアクセスと削除アクセスを使用して、テーブルにエントリ２７４，２７２を追加し、除去する。代表的なＳＡメモリ１４０は、着信ＳＡ用と発信ＳＡ用の２つの領域に分けられており、各領域は、１６Ｋのエントリのための空間を提供している。ホスト１１２によるＳＡメモリ１４０およびＳＰＩメモリ２７０へのアクセスは、ＳＡアドレスレジスタＳＡ＿ＡＤＤＲ２８０と、１４４バイトのＳＡバッファ２８２を使用して行われる。ＳＡバッファ２８２は、１３６バイトのＳＡメモリエントリ２７４を１つ格納しており、これに、対応する８バイトのＳＰＩテーブルのエントリ２７２が続く。発信ＳＡでは、バッファ２８２のＳＰＩテーブルエントリ部分２７２は使用されない。ＳＡテーブルのエントリを書き込むために、ホスト１１２は、ホストメモリ１２８に１３６バイトまたは１４４バイトのエントリを作成して、ＳＡメモリ１４０内の対象アドレスをＳＡ＿ＡＤＤＲレジスタ２８０に書き込む。コントローラ１０２は、ＤＭＡを使用して、ＳＡ情報をまず内部ＳＡバッファ２８２に、次にＳＡメモリ１４０とＳＰＩメモリ２７０の適切な位置にコピーする。ホスト１１２は、ホストメモリ１２８内のＳＡエントリバッファ２８４の物理アドレスをＳＡ＿ＤＭＡ＿ＡＤＤＲレジスタ２８６に書き込む。ソフトウェアドライバ１９０が、ＳＡテーブルの全エントリをロードするために、ホストメモリ１２８の同じバッファ２８４を使用する場合、ＳＡ＿ＤＭＡ＿ＡＤＤＲレジスタ２８６に一度書き込むだけで済む。
【０１３０】
着信セキュリティアソシエーションは、ハッシュアルゴリズムによって決定される位置に記憶される。発信（送信）フレーム２００に対して、ドライバソフトウェア１９０は、送信記述子１９２ａ内の適切なＳＡへのポインタ（例えば図５ＥのＳＡ＿ＰＴＲフィールド）を有する。これにより、コントローラ１０２が、発信ＳＡのためにＳＡメモリ１４０を検索する必要がなくなり、送信ＳＡを任意の順序で記憶できるようになる。記述子１９２ａのＳＡ＿ＰＴＲフィールドの値が０の場合は、ＩＰｓｅｃ処理が不要であることを示しているため、オフセット０に発信ＳＡが記憶されることはない。
【０１３１】
図１１Ｂも参照すると、ＳＡアドレスレジスタ２８０は、アクセス対象のＳＡテーブルのエントリ２７４のアドレスと、６つのＳＡアクセスコマンドビットを有する。これらの命令ビットには、ＳＡの読出し、書込み、削除およびクリアの各ビット（ＳＡ＿ＲＤ、ＳＡ＿ＷＲ、ＳＡ＿ＤＥＬ、およびＳＡ＿ＣＬＥＡＲ）と、ＳＡ方向ビットＳＡ＿ＤＩＲ、ならびに命令アクティブビットＳＡ＿ＡＣＴＩＶＥがある。内部ステートマシン２６２がＳＡバッファ２８２との間でデータをコピーしている間は、読取り専用のＳＡ＿ＡＣＴＩＶＥビットが１にセットされ、この間は、ホスト１１２はＳＡバッファ２８２にアクセスすることができない。外部ＳＡメモリ１４０の着信領域と発信領域の選択はＳＡ＿ＤＩＲビットによって制御され、このビットは上位アドレスビットとして機能する。このビットは、着信ＳＡの場合は１に、発信ＳＡの場合は０にセットされる。このビットが１にセットされている場合、外部ＳＡメモリ１４０との間で、あるいは内部ＳＰＩメモリ２７０との間でデータが転送される。発信ＳＡテーブルへのアクセスは、外部ＳＡメモリ１４０にのみ影響する。ホスト１１２がＳＡアドレスレジスタ２８０のＳＡ＿ＲＤをセットしている場合、ステートマシンは外部ＳＡメモリ１４０からＳＡバッファ２８２にデータをコピーする。方向ビットＳＡ＿ＤＩＲが１の場合、内部ＳＰＩメモリ２７０の対応するエントリ２７２が、ＳＡバッファ２８２にもコピーされる。ＳＡアドレスレジスタ２８０のＳＡアドレスフィールドＳＡ＿ＡＤＲ［１３:０］は、コピーすべきエントリ２７２および／またはエントリ２７４を示す。
【０１３２】
ホスト１１２がＳＡ＿ＡＤＤＲレジスタ２８０のＳＡ＿ＷＲビットをセットしている場合、行われるアクションはＳＡ＿ＤＩＲビットの値によって決まる。このビットが１（例えば着信ＳＡを示す）の場合、ステートマシンは、まず、ホストメモリ１２８内のバッファ２８４から内部ＳＡバッファ２８２にデータをコピーして、このデータを、ＳＡバッファ２８２から外部ＳＡメモリ１４０に、更に対応する内部ＳＰＩメモリ２７０にコピーする。ＳＡ＿ＤＩＲビットが０（例えば、送信ＳＡを示す）の場合、アクセス命令が“書込み”のときに、ＳＡバッファ２８２のＳＡフィールドのみが、ＳＡアドレスレジスタ２８０によって選択されるＳＡメモリ１４０のエントリにコピーされ、ＳＰＩフィールドはコピーされない。バンドル処理のため、フレーム２００にＡＨヘッダに続いてＥＳＰヘッダが含まれることが予想されることを示すために、フレーム２００の最初のＩＰｓｅｃヘッダに対応するＳＡのＢＵＮＤＬＥビットがセットされる。外部ＳＡメモリ１４０内の対応するエントリには、第２のＩＰｓｅｃヘッダの予想されるＳＰＩなど、この２つのヘッダの情報が含まれる。
【０１３３】
ＡＨ受信処理では、ＳＡメモリエントリ２７４のＡＨ＿ＡＬＧフィールドの値がゼロ以外の値をとり、受信フレーム２００に対してＡＨ処理が要求されていることを示す。受信パーサ１４４は、フレームのＩＰヘッダ（存在する場合はＩＰｖ６拡張ヘッダなど）をスキャンして、ＲＦＣ  ２４０２に規定されている可変フィールドの位置を特定する。パーサ１４４は、これらの可変フィールド位置のリストを、メモリ１１８内の制御ブロックに挿入する。ＡＨ処理が有効の場合、ＩＰｓｅｃプロセッサ１５０は、予想されるＩＣＶを計算するために、ＡＨヘッダのＩＣＶフィールドと可変フィールドをゼロで置き換える（ホストメモリ１２８にコピーされるフレームデータは変更されない）。ＩＰヘッダの宛先アドレスフィールドは、ソースルーティングが使用される場合には、間に介在するルータがこのフィールドを変更する可能性があるため、可変であるが、予測可能であると考えられる。しかし、発信ノードはＩＣＶ計算に最終的な宛先アドレスを使用するため、受信側は、そのＩＣＶチェックのためフィールドが不変であるとみなす。
【０１３４】
メモリ１１８内の制御ブロックは、受信フレーム２００の、ＡＨ認証が適用される部分の開始点へのポインタと終了点へのポインタを有している。ＩＰｓｅｃプロセッサ１５０は、この制御ブロック情報を使用して、認証の計算の開始点と終了点を決定する。ＳＡメモリエントリ２７４ｖのＡＨ＿ＡＬＧフィールドは、使用すべき認証アルゴリズムを示す。代表的なＩＰｓｅｃシステム１２４は、ＡＨ処理のため、ＲＦＣ  ２４０４に規定されているＨＭＡＣ−ＳＨＡ−１−９６と、ＲＦＣ  ２４０３に規定されているＨＭＡＣ−ＭＤ５−９６を提供する。いずれの場合も、受信ＩＰｓｅｃプロセッサ１５０は、フレームデータと共に、ＳＡエントリ２７４のＡＨ＿ＩＰＡＤフィールドおよびＡＨ＿ＯＰＡＤフィールドから前処理したデータを使用して、ＲＦＣ  ２１０４に規定されているＨＭＡＣキー付きハッシュアルゴリズムを実行する。この計算の結果が、ＡＨヘッダの認証データフィールドの内容と一致しない場合、対応する受信状態リングのエントリ１９９のＡＨ＿ＥＲＲビット（図５Ｊ）がセットされる。
【０１３５】
受信ＥＳＰ処理の場合、ＳＡメモリエントリ２７４のＥＳＰＡＨ＿ＡＬＧフィールドが、ＥＳＰ認証が要求されていることを示すゼロ以外の値をとり、このゼロ以外の値は、使用する認証アルゴリズム（例えばＭＤ５、ＳＨＡ−１など）を示している。受信ＩＰｓｅｃプロセッサ１５０は、フレームデータと共に、ＳＡエントリ２７４のＥＳＰ＿ＩＰＡＤフィールドおよびＥＳＰ＿ＯＰＡＤフィールドから前処理したデータを使用して、ＲＦＣ  ２１０４に規定されているＨＭＡＣキー付きハッシュアルゴリズムを実行する。受信ＩＰｓｅｃプロセッサ１５０は、メモリ１１８の制御ブロックから取り出したポインタを使用して、ＩＣＶ計算に使用するフレーム部分を決定する。計算で使用されるデータは、ＥＳＰヘッダから始まり、ＥＳＰトレーラの認証データフィールドの直前で終わるが、この範囲にあるフィールドに可変フィールドはない。このＩＣＶの計算の結果が、ＥＰＳトレーラの認証データフィールドの内容と一致しない場合、対応する受信状態リングのエントリ１９９のＥＳＰ＿ＩＣＶ＿ＥＲＲビットがセットされる。
【０１３６】
ＳＡメモリエントリ２７４のＥＳＰ＿ＡＬＧフィールドがゼロ以外の値の場合、ＥＳＰ復号化が必要な要求されていることを示し、受信ＩＰｓｅｃプロセッサ１５０はエントリ２７４のＥＳＰ＿ＡＬＧフィールドとＥＣＢフィールドを使用して、使用する復号化アルゴリズムおよびモード（例えば、ＤＥＳ；３ＤＥＳ；ＡＥＳ−１２８、１０ラウンド；ＡＥＳ−１９２、１２ラウンド；ＡＥＳ２５６、１４ラウンドなど）を決定する。受信ＩＰｓｅｃプロセッサ１５０は、エントリ２７４のＥＮＣ＿ＫＥＹフィールドから復号化キーを取得し、メモリ１１８内の制御ブロックにある情報を使用して、フレームの暗号化されている部分（例えば、ＥＳＰヘッダの直後から始まり、ＥＳＰトレーラの認証データフィールドの直前で終わる部分など）を決定する。ＳＡによって、ＥＳＰ認証を実行しないことが示される場合、認証データフィールドの長さはゼロとなり、暗号化されたデータはＦＣＳフィールドの直前で終わる。
【０１３７】
ペイロードが復号化されると、ＩＰｓｅｃプロセッサ１５０は、ＥＳＰトレーラのパッド長フィールドを調べて、チェックパッドバイトの有無を調べる。パッド長フィールドの値がゼロでない場合、プロセッサ１５０は、パッドバイトを調べ、パッドバイトが１を始点として増加していく一連の整数（１、２、３、...など）ではない場合、受信状態リングのエントリ１９９のＰＡＤ＿ＥＲＲビットを１にセットする。ＩＰｓｅｃプロセッサ１５０は、メモリ１１８内で暗号化されたフレームデータを（復号化された）平文で置き換える。代表的なプロセッサ１５０は、元のＩＰパケットを復元することはしない（例えば、プロセッサ１５０は、ＥＳＰヘッダとＥＳＰトレーラを除去したり、前の暗号化されていないヘッダのＮｅｘｔ  Ｈｅａｄｅｒフィールドに置き換えたりすることはしない）。暗号化がＣＢＣモードを使用する場合、ＥＳＰペイロードフィールドの先頭の８バイトまたは１６バイトは暗号化されていないＩＶを有し、ＩＰｓｅｃプロセッサ１５０はこれを変更することはしない。ＩＶに続く暗号化されたデータが、復号化されたデータに置き換えられる。
【０１３８】
代表的なＩＰｓｅｃシステム１２４では、ＳＰＩテーブルのビン番号とＩＰ宛先アドレスのハッシュコードは、いずれも、１つの１２ビットハッシュアルゴリズムを使用して計算される。ビン番号は、ＩＰｓｅｃプロセッサ１５０のハッシュロジックによってＳＰＩをシフトすることによって計算される。宛先アドレス（ＤＡ）のハッシュでは、３２ビットのＩＰｖ４宛先アドレスまたは１２８ビットのＩＰｖ６宛先アドレスが、ハッシュロジックによってシフトされ、これがビン番号に使用される１２の出力ビットとなり、そのうちの最下位の８ビットのみがＤＡハッシュに使用される。ハッシュ関数は、コントローラ１０２の構成レジスタに格納されているプログラム可能な１２ビットの多項式によって定義され、多項式の各ビットは、プロセッサ１５０のハッシュロジックのＡＮＤ／ＸＯＲタップを定義している。着信ビットストリームが、ハッシュ関数の最後のフリップフロップの出力と排他的ＯＲ演算される。この結果が多項式とビット単位でＡＮＤ演算され、前のレジスタの出力と排他的ＯＲ演算されて、シフトされる。ハッシュ関数のビットはゼロで初期化される。次に、探索キーをハッシュ関数で処理させる。入力ビットストリームをハッシュ関数ロジックにシフトさせると、得られる１２ビットの出力がハッシュキーである。
【０１３９】
本発明を１つ以上の実装に関して図示および記載したが、添付の請求の範囲の趣旨および範囲から逸脱することなく、図示した例を変更および／または変形することができる。特に上記した構成要素または構造（ブロック、ユニット、エンジン、アセンブリ、デバイス、回路、システムなど）によって実行される各種機能に関して、特に明記しない限り、このような構成要素の説明に使用された文言（「手段（means）」を含む）は、ここに説明した、本発明の代表的な実装における機能を実行する構造とは構造的に同等でなくとも、記載した構成要素の指定の機能を実行する任意の構成要素または構造（すなわち、機能的に同等である）に相当することが意図される。更に、本発明の特定の特徴を、幾つかの実装のうちの１つのみに関して開示したが、任意の用途または特定の用途に望ましくかつ有利な場合には、このような特徴が、別の実装の１つ以上の別の特徴と組み合わされてもよい。また、詳細な説明または特許請求の範囲で「備える（including, includes）」、「有する（having, has）」、「と共に（with）」との文言やその変形が使用される限り、この用語は「備える（comprising）」との用語と同じように用いられることが意図される。
【産業上の利用可能性】
【０１４０】
本発明は、ネットワークとコンピュータとの間に安全な高速インタフェースを作成するために使用できる。
【図面の簡単な説明】
【０１４１】
【図１Ａ】本発明の１つ以上の態様による代表的なネットワークインタフェースシステムを示す模式図である。
【図１Ｂ】代表的な送信セキュリティプロセッサを示す模式図である。
【図１Ｃ】本発明の別の態様による、代表的な送信ＩＰｓｅｃ入力データフローコントローラの動作を示すフローチャートである。
【図１Ｄ】本発明の更に別の態様による、代表的な送信ＩＰｓｅｃ出力データフローコントローラの動作を示すフローチャートである。
【図２】本発明の様々な態様が実施されうる別の代表的なネットワークインタフェースシステムを示す模式図である。
【図３】図２のネットワークインタフェースシステムの代表的なシングルチップネットワークコントローラの実装を示す模式図である。
【図４】図３の代表的なネットワークコントローラを使用してネットワークとインタフェースするホストシステムを示す模式図である。
【図５Ａ】ホストシステムメモリの制御状態ブロックと、図２のホストシステムの記述子リングおよび受信状態リングへのポインタを示す模式図である。
【図５Ｂ】図２のホストシステムのホストメモリのコントローラ状態ブロックを示す模式図である。
【図５Ｃ】図２のネットワークインタフェースシステムの記述子管理ユニットレジスタを示す模式図である。
【図５Ｄ】ホストシステムメモリの代表的な送信記述子リングと、図２のネットワークインタフェースシステムの記述子管理ユニットのポインタレジスタを示す模式図である。
【図５Ｅ】図２のネットワークインタフェースシステムの代表的な送信記述子を示す模式図である。
【図５Ｆ】図５Ｅの送信記述子の送信フラグバイトを示す模式図である。
【図５Ｇ】図２のネットワークインタフェースシステムの代表的な受信記述子を示す模式図である。
【図５Ｈ】ホストシステムメモリの代表的な受信記述子リングおよび受信状態リングと、図２のネットワークインタフェースシステムの記述子管理ユニット内のポインタレジスタを示す模式図である。
【図５Ｉ】ホストシステムメモリの代表的な受信状態リングと、図２のネットワークインタフェースシステムの記述子管理ユニット内のポインタレジスタを示す模式図である。
【図５Ｊ】ホストシステムメモリの代表的な受信状態リングのエントリを示す模式図である。
【図６Ａ】ＩＰｖ４のトランスポートモードＥＳＰ処理を介したＴＣＰからの発信データを示す模式図である。
【図６Ｂ】ＩＰｖ６のトランスポートモードＥＳＰ処理を介したＴＣＰからの発信データを示す模式図である。
【図６Ｃ】ＩＰｖ４のトンネルモードＥＳＰ処理を介したＴＣＰからの発信データを示す模式図である。
【図６Ｄ】ＩＰｖ６のトンネルモードＥＳＰ処理を介したＴＣＰからの発信データを示す模式図である。
【図６Ｅ】代表的なＥＳＰヘッダ、ＥＳＰトレーラ、認証データおよび保護されたデータを示す模式図である。
【図７Ａ】ＩＰｖ４の代表的なＴＣＰフレームのフォーマットを示す模式図である。
【図７Ｂ】ＩＰｖ６の代表的なＴＣＰフレームのフォーマットを示す模式図である。
【図８Ａ】図２のネットワークインタフェースシステムにおいて、発信ＥＳＰ処理によって変更されるフレームフィールドを示すテーブルである。
【図８Ｂ】図２のネットワークインタフェースシステムにおいて、発信ＡＨ処理によって変更されるフレームフィールドを示すテーブルである。
【図８Ｃ】図３のネットワークインタフェースシステムにおける、ＩＰｖ４の疑似ヘッダチェックサムの計算を示す模式図である。
【図８Ｄ】図３のネットワークインタフェースシステムにおける、ＩＰｖ６の疑似ヘッダチェックサムの計算を示す模式図である。
【図９】図３のネットワークインタフェースシステムの発信データのセキュリティ処理を示す模式図である。
【図１０】図３のネットワークインタフェースシステムの着信ネットワークデータのセキュリティ処理を示す模式図である。
【図１１Ａ】図３のネットワークインタフェースシステムの代表的なセキュリティアソシエーションのテーブル書込みアクセスを示す模式図である。
【図１１Ｂ】図３のネットワークインタフェースシステムの代表的なＳＡアドレスレジスタのフォーマットを示す模式図である。
【図１１Ｃ】図３のネットワークインタフェースシステムの代表的なＳＰＩテーブルのエントリのフォーマットを示す模式図である。
【図１１Ｄ】図３のネットワークインタフェースシステムの代表的なＳＡメモリのエントリのフォーマットを示す模式図である。
【図１２】図３のネットワークインタフェースシステムにおける、発信する送信フレームに対するレイヤ４のチェックサム計算を更に詳細に示す模式図である。
【図１３Ａ】本発明の別の態様による、図３のネットワークインタフェースシステムにおけるレイヤ４のチェックサム処理のフロー図である。
【図１３Ｂ】本発明の別の態様による、図３のネットワークインタフェースシステムにおけるレイヤ４のチェックサム処理のフロー図である。
【図１Ａ】
2007526718.tif 000003
【図１Ｂ】
2007526718.tif 000004
【図１Ｃ】
2007526718.tif 000005
【図１Ｄ】
2007526718.tif 000006
【図２】
2007526718.tif 000007
【図３】
2007526718.tif 000008
【図４】
2007526718.tif 000009
【図５Ａ】
2007526718.tif 000010
【図５Ｂ】
2007526718.tif 000011
【図５Ｃ】
2007526718.tif 000012
【図５Ｄ】
2007526718.tif 000013
【図５Ｅ】
2007526718.tif 000014
【図５Ｆ】
2007526718.tif 000015
【図５Ｇ】
2007526718.tif 000016
【図５Ｈ】
2007526718.tif 000017
【図５Ｉ】
2007526718.tif 000018
【図５Ｊ】
2007526718.tif 000019
【図６Ａ】
2007526718.tif 000020
【図６Ｂ】
2007526718.tif 000021
【図６Ｃ】
2007526718.tif 000022
【図６Ｄ】
2007526718.tif 000023
【図６Ｅ】
2007526718.tif 000024
【図７Ａ】
2007526718.tif 000025
【図７Ｂ】
2007526718.tif 000026
【図８Ａ】
2007526718.tif 000027
【図８Ｂ】
2007526718.tif 000028
【図８Ｃ】
2007526718.tif 000029
【図８Ｄ】
2007526718.tif 000030
【図９】
2007526718.tif 000031
【図１０】
2007526718.tif 000032
【図１１Ａ】
2007526718.tif 000033
【図１１Ｂ】
2007526718.tif 000034
【図１１Ｃ】
2007526718.tif 000035
【図１１Ｄ】
2007526718.tif 000036
【図１２】
2007526718.tif 000037
【図１３Ａ】
2007526718.tif 000038
【図１３Ｂ】
2007526718.tif 000039
【手続補正書】
【提出日】平成17年12月2日(2005.12.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ホストシステム（６）からネットワーク（８）に発信データを提供すると共に、前記ネットワーク（８）から前記ホストシステム（６）に着信データを提供するため、前記ホストシステム（６）を前記ネットワーク（８）にインタフェースするネットワークインタフェースシステム（２）であって、
前記ホストシステム（６）のホストバス（１０６）に結合され、前記ネットワークインタフェースシステム（８）と前記ホストシステム（６）の間でデータを転送するように適合されたバスインタフェースシステム（４）と、
前記ネットワーク（８）に結合され、前記ネットワークインタフェースシステム（２）と前記ネットワーク（８）との間でデータを転送するように適合されたメディアアクセスコントロールシステム（１０）と、
前記バスインタフェースシステム（４）および前記メディアアクセスコントロールシステム（１０）に結合され、前記ネットワーク（８）と前記ホストシステム（６）との間で転送中の着信データおよび発信データを記憶するように適合されたメモリシステム（１２）と、
前記メモリシステム（１２）に結合され、発信データを選択的に暗号化すると共に、着信データを選択的に復号化するように適合されたセキュリティシステム（１４）と、を有し、
前記セキュリティシステム（１４）は、前記発信データを暗号化するための２つのプロセッサ（２０，２１）を有し、前記２つのプロセッサ（２０，２１）は、それぞれ前記発信データを暗号化するために相互に独立して動作可能であり、前記セキュリティシステム（１４）は暗号化のために発信データパケットを前記プロセッサ（２０，２１）の一方ずつに交互に送るように構成されているか構成可能であり、
前記セキュリティシステム（１４）は、着信データを選択的に復号化するための別のプロセッサ（２２）を更に有し、前記セキュリティシステム（１４）は、発信データを復号化するためのプロセッサよりも着信データを暗号化するためのプロセッサのほうを多く有するネットワークインタフェースシステム。
【請求項２】
前記２つのプロセッサ（２０，２１）は、前記発信データを認証するようにも動作可能である請求項１に記載のネットワークインタフェースシステム。
【請求項３】
前記２つのプロセッサ（２０，２１）は機能的に同一である請求項１に記載のネットワークインタフェースシステム。
【請求項４】
前記セキュリティシステム（１４）は、前記メモリシステム（１２）に結合された２つの入力バッファ（２６，２７）を更に有し、前記入力バッファ（２６，２７）はそれぞれ前記２つのプロセッサ（２０，２１）のうちの１つに結合されており、前記セキュリティシステム（１４）は、前記メモリシステム（１２）から読み出した発信データパケットを前記入力バッファ（２６，２７）の一方ずつに交互に送る請求項１に記載のネットワークインタフェースシステム。
【請求項５】
前記セキュリティシステム（１４）は、前記メモリシステム（１２）に結合された２つの出力バッファ（２４，２５）を更に有し、前記出力バッファ（２４，２５）はそれぞれ前記２つのプロセッサ（２０，２１）の１つに結合されており、前記２つのプロセッサ（２０，２１）は、処理されたデータパケットを前記出力バッファ（２４，２５）に書き込むように構成されており、前記セキュリティシステム（１４）は、処理前に前記メモリシステム（１２）から前記データパケットが読み出されたのと同じ順序で、前記出力バッファ（２４，２５）から前記メモリシステム（１２）に前記処理データパケットを転送するように構成されている請求項１に記載のネットワークインタフェースシステム。
【請求項６】
前記２つのプロセッサ（２０，２１）と前記別のプロセッサ（２２）とがデータパケットを同時に暗号化および復号化するために動作するように前記セキュリティシステム（１４）が適合されている請求項１に記載のネットワークインタフェースシステム。
【請求項７】
単一集積回路であって、
ネットワーク（８）への送信のためにデータに対して送信ＩＰｓｅｃ処理を実行するように適合されたセキュリティシステム（１４）を有し、前記セキュリティシステム（１４）は、前記送信ＩＰｓｅｃ処理を実行するための２つのプロセッサ（２０，２１）を並列に有し、
前記セキュリティシステム（１４）は、着信データを選択的に復号化するための別のプロセッサ（２２）を更に有し、前記セキュリティシステム（１４）は、送信ＩＰｓｅｃ処理のためのプロセッサよりも着信データを暗号化するためのプロセッサのほうを多く有する単一集積回路。
【請求項８】
前記２つのプロセッサ（２０，２１）は機能的に同一である請求項７に記載の単一集積回路。
【請求項９】
前記セキュリティシステム（１４）は、それぞれが前記２つのプロセッサの１つに結合された２つの入力バッファ（２６，２７）を更に有し、前記セキュリティシステム（１４）は、発信データパケットを前記入力バッファ（２６，２７）の一方ずつに交互に送るように構成されている請求項７に記載の単一集積回路。
【請求項１０】
前記セキュリティシステム（１４）は、２つの出力バッファ（２４，２５）を更に有し、前記出力バッファ（２４，２５）はそれぞれ前記２つのプロセッサ（２０，２１）の１つに結合されており、前記２つのプロセッサは、処理されたデータパケットを前記出力バッファ（２４，２５）に書き込むように構成されており、前記セキュリティシステム（１４）は、処理前に前記データパケットが前記セキュリティシステム（１４）に読み出されたのと同じ順序で、前記出力バッファ（２４，２５）から前記処理されたデータパケットを送信するように構成されている請求項７に記載の単一集積回路。
【国際調査報告】
2007526718.tif 000040
2007526718.tif 000041
2007526718.tif 000042