JP2002538724A - マルチプロセッサコンピュータでネットワークトラフィック処理を分散する方法および装置 - Google Patents

Abstract

(57)【要約】 マルチプロセッサコンピュータで受け取られるネットワークトラフィックの処理を分散させる、システムおよび方法が提供される。パケットはネットワークインターフェース回路で、ネットワークエンティティから受け取られる。パケットのヘッダー部は、１以上のプロトコルヘッダに格納された情報（例えば、ソース識別子および宛先識別子、または仮想通信接続識別子）を取り出すために構文解析される。ソース識別子および宛先識別子は、フローキーを形成するために結合され、ついでフローキーにハッシュ機能を行い得る。ついで、マルチプロセッサコンピュータのプロセッサ番号にわたり、ハッシュ機能の結果に基づいてモジュラスが計算される。上記結果は、パケットが処理のために発信されるホストプロセッサを識別する。

Description

【発明の詳細な説明】

【０００１】 （背景） 本発明は、コンピュータシステムおよびコンピュータネットワークの分野に関
する。特に、本発明は、コンピュータネットワークとホストコンピュータシステ
ムとの間で交換される通信パケットを処理するためのネットワークインターフェ
ース回路（ＮＩＣ）に関する。

【０００２】 コンピュータとネットワークとの間のインターフェースはしばしば、そのコン
ピュータとネットワークとの間を通過する通信についてボトルネックとなる。コ
ンピュータ性能（例えば、プロセッサ速度）が、年月を経て指数関数的に向上し
、コンピュータネットワーク伝送速度も同じような向上を経験してきたが、ネッ
トワークインターフェース回路が通信を処理する際の非効率性が次第に明らかに
なってきた。コンピュータまたはネットワークの速度がそれぞれ増加すると、コ
ンピュータとネットワークとの間のインターフェースがついていけないことがさ
らに明らかになった。これらの非効率性は、ネットワークとコンピュータとの間
の通信が処理されるという点でいくつかの基本的な問題を含んでいる。

【０００３】 今日の最もポピュラーなネットワークの形態は、パケットベースとなる傾向が
ある。これらのネットワークのタイプには、インターネットおよび多くのローカ
ルエリアネットワークが挙げられ、パケットの形態で情報を伝送する。各パケッ
トは、発信元のエンドステーション（ｅｎｄｓｔａｔｉｏｎ）により別々に作成
され、伝送される。そして、宛先のエンドステーションにより別々に受け取られ
、処理される。さらに、各パケットは、例えばバストポロジネットワークにおい
て、発信元エンドステーションと受信先エンドステーションとの間に配置された
多数のステーションにより受け取られ処理され得る。

【０００４】 パケットネットワークに関する１つの基本的な問題は、各パケットが、発信元
エンドステーションおよび受信先エンドステーションの両方において、複数のプ
ロトコルまたはプロトコルレベル（「プロトコルスタック」として総称されて公
知である）により処理される必要があることである。ステーション間で伝送され
るデータが、ある最小長よりも長いと、このデータは複数の部分へと分割され、
そして各部分は別々のパケットによって運ばれる。パケットが運ぶことができる
データの量は、一般にそのパケットを運搬するネットワークにより限定され、し
ばしば最大伝送単位（ＭＴＵ）として表現される。データの元の集合はしばしば
、「データグラム」として知られており、１つのデータグラムの一部を運ぶ各パ
ケットは、そのデータグラムの別のパケットと非常に類似して処理される。

【０００５】 通信パケットは、一般に以下のように処理される。発信元エンドステーション
において、データグラムの別々のデータ部分のそれぞれは、プロトコルスタック
により処理される。この処理の間、複数のプロトコルヘッダー（例えば、ＴＣＰ
、ＩＰ、イーサネット（登録商標））がこのデータ部分に加えられ、ネットワー
クにわたって伝送され得るパケットを形成する。このパケットはネットワークイ
ンターフェース回路により受け取られ、このネットワークインターフェース回路
は受け取ったパケットを宛先エンドステーションまたは宛先エンドステーション
の機能をするホストコンピュータへ伝送する。宛先エンドステーションでは、こ
のパケットは、発信元エンドステーションとは反対の方向のプロトコルスタック
により処理される。この処理の間、プロトコルヘッダーが、それらが付与される
反対の順序で取り除かれる。従って、このデータ部分は復元され、ユーザ、アプ
リケーションプログラム等に利用可能にされ得る。

【０００６】 従って、いくつかの関連のパケット（例えば、１つのデータグラムからデータ
を運ぶパケット）は、連続的な態様（すなわち、一度に１つのパケット）で、実
質的に同じプロセスを受ける。伝送されるべきデータがより多くなると、より多
くのパケットが送信される必要がある。これらの各パケットは、各方向でプロト
コルスタックにより、別々に扱われ、処理される。当然、処理されるべきパケッ
トがより多くなると、エンドステーションのプロセッサに課せられる要求も大き
くなる。処理されるべき多くのパケットは、データグラムで送信されているデー
タの量以外のファクターに影響を受ける。例えば、パケットに包まれ得るデータ
の量が増加するにつれて、送信される必要のあるパケットは少なくなっていく。
しかし、上記のように、パケットは最大許容サイズを有してもよく、これは使用
時のネットワークのタイプによる（例えば、標準イーサネット（登録商標）トラ
フィックについての最大伝送単位は、約１，５００バイトである）。ネットワー
クの速度はまた、所定の期間においてＮＩＣが処理し得るパケットの数に影響を
与える。例えば、最大能力で動作しているギガビットイーサネット（登録商標）
ネットワークは、ＮＩＣが約１４８万パケット／秒を受信することを要求し得る
。従って、プロトコルスタックにより処理されるべき多くのパケットは、コンピ
ュータのプロセッサに顕著な負担となり得る。この状況は、各パケットが実質的
に同じように処理されたとしても、別々に各パケットを処理する必要性により悪
化する。

【０００７】 パケットの別々の処理に関する問題は、データ伝送および受信の間に「ユーザ
スペース」（例えば、アプリケーションプログラムのデータ格納装置）と「シス
テムスペース」（例えば、システムメモリ）との間で、データが移動するのと同
様である。現在、データは、ユーザまたはアプリケーションプログラムに割り当
てられたメモリのある領域からプロセッサの使用専用のメモリの別の領域へ単に
コピーされる。パケットで伝送されるデータグラムの各部分は別々にコピーされ
得るので（例えば、一度に１バイト）、必要とされるプロセッサ時間の量は重要
であり、頻繁な伝送により大量のメモリバスの帯域幅が使われ得る。例示的に、
ネットワークから受け取られるパケットのデータの各バイトは、システムスペー
スから読み取ることができ、別々のコピーオペレーションでユーザスペースへ書
き込まれ得る。ネットワーク中に伝送されるデータについて逆も同じである。シ
ステムスペースは、一般にプロテクトされたメモリ領域（例えば、ユーザプログ
ラムによるオペレーションから保護された）を提供するが、コピー動作は、ネッ
トワークインターフェース回路の点から考慮すると、全く有用でない。代わりに
、ホストプロセッサに過剰な負荷をかけ、ＮＩＣからのさらなるネットワークト
ラフィックを迅速に受け入れる能力を低くするリスクがある。それ故、各パケッ
トのデータを別々にコピーすることは非常に非効率的であり得、特に高速ネット
ワーク環境では非効率的である。

【０００８】 データの非効率的伝送（例えば、一度に１つのパケットデータ）に加えて、ネ
ットワークから受け取ったパケットからのヘッダーの処理もまた非効率的である
。１つのデータグラムの部分を運ぶ各パケットは、一般に同じプロトコルヘッダ
ー（イーサネット（登録商標）、ＩＰおよびＴＣＰ）を有するが、特定のプロト
コルについてのパケットのヘッダー内の値に幾分変動があり得る。しかし、各パ
ケットは同じプロトコルスタックにより個々に処理され、従って、関連のパケッ
トについて同じオペレーションを複数繰り返すことが必要である。異なるプロト
コルスタックにより関連しないパケットを連続的に処理することは、一度に１つ
のプロトコルスタックによる多数の関連するパケットを順次処理することよりも
あまり効率的でないようである。

【０００９】 現在のネットワークインターフェース回路とホストコンピュータシステムとの
間の相互作用に関する別の基本的な問題は、しばしばその組み合わせが、マルチ
プロセッサコンピュータシステムで利用可能な向上したプロセッサリソースを十
分に利用できないことである。言い換えると、多数のプロトコルの間でネットワ
ークパケットの処理（例えば、プロトコルスタックによる）を効率的な態様で分
散する現在の試行は、一般に非効率的である。特に、現在のＮＩＣの性能は、複
数のプロセッサの利用可能性から実現されることが期待され得る期待のまたは所
望のリニア性能利得に及ばない。いくつかのマルチプロセッサシステムにおいて
、ネットワークトラフィックの処理においての向上は、例えば４〜６個より多く
のプロセッサを使用しても実現されることはほとんどない。

【００１０】 さらに、パケットがネットワークインターフェース回路からホストコンピュー
タまたは他の通信デバイスへ伝送される速度は、ネットワークインターフェース
に到達するパケットの速度と同じペースにできない。ホストコンピュータのある
要素または別の要素（例えば、メモリバス、プロセッサ）は、過剰な負荷がかけ
られ得、そうでない場合は十分に素早くパケットを受信することはできない。こ
の場合に、１つ以上のパケットがドロップされるか廃棄され得る。パケットをド
ロップすると、ネットワークエンティティがいくらかの通信を再伝送させ得、非
常に多くのパケットがドロップされると、ネットワーク接続は再初期化を必要と
し得る。さらに、１つのパケットまたはパケットのタイプを別のパケットの代わ
りにドロップすると、ネットワークトラフィック全体において顕著な差が生じ得
る。例えば、制御パケットがドロップされると、対応するネットワーク接続は深
刻な影響を受け、制御パケットのサイズは典型的には小さいためにネットワーク
インターフェース回路のパケット飽和を緩和することはほとんどできない。従っ
て、パケットのドロップが、多くのネットワーク接続の間での影響を分散するか
、またはあるタイプのパケットを許可するように実行されない限り、ネットワー
クトラフィックは必要以上に低下され得る。

【００１１】 従って、現在のＮＩＣは、今日のハイエンドコンピュータシステムと高速ネッ
トワークとを相互接続する十分な性能を提供することができない。さらに、過剰
に負荷をかけたホストコンピュータを許容できないネットワークインターフェー
ス回路は、コンピュータの性能を低下し得る。

【００１２】 （要旨） 本発明の１実施形態において、マルチプロセッサコンピュータの複数のコンピ
ュータ間でネットワークパケットの処理を分散させるシステムおよび方法を提供
する。このような分散された処理の間、パケットを構成し転送するために使用さ
れる通信プロトコルと関連する１以上のヘッダは、削除され得る。

【００１３】 高性能ネットワークインターフェースのような通信デバイスは、ネットワーク
からパケットを受け取る。パケットのソースエンティティおよび宛先エンティテ
ィの識別子は、フローキーを形成するために生成されるか、またはアセンブルさ
れる。フローキーは、通信フロー、接続、またはパケットを含む回路を識別する
。

【００１４】 この実施形態において、ハッシング機能がフローキーで実行されフローキーの
番号よりも小さな番号を生成し、可能な値の範囲の間で比較的に均等に分散され
る。ついで、ハッシュ機能の結果を用いて、モジュラス機能はホストコンピュー
タのプロセッサ番号にわたり実行される。モジュラス機能の結果は、このパケッ
トを処理するプロセッサを識別する番号である。同一のフローキーを生成する同
一の通信フローにおける他のパケットは、同一のプロセッサに発信される。しか
しながら、例示的に、異なるソースエンティティから受け取られるパケットか、
または異なる宛先エンティティ用に受け取られるパケットは、異なるフローキー
を生成し、異なるプロセッサに発信される。

【００１５】 ホストコンピュータのプロセッサ番号は、ホストコンピュータ上で動作するソ
フトウェア（例えば、通信デバイス用のデバイスドライバ）により格納され得る
。ソフトウェアがパケットをデバイスから受け取ると、パケットがどのようにフ
ォーマットされたかに従って、１以上のプロトコルを介して処理するために、パ
ケットを指定されたプロセッサに発信する。

【００１６】 本発明の他の実施形態において、モジュラス機能はフローキーで直接実行され
る。

【００１７】 本発明のさらに他の実施形態において、負荷分散は、予め選択されたプロトコ
ルのセットのうち１以上のプロトコルに従いフォーマットされないパケットにつ
いて、無効にされ得る。例えば、パケットを搬送するネットワークがインターネ
ットである場合、予め選択されたプロトコルは、インターネットプロトコルおよ
び伝送制御プロトコルを含んでもよい。本実施形態の通信デバイスは、他のオペ
レーション（例えば、１つの通信フローにおける、データのリアセンブリまたは
複数のパケットの集約的な処理）を有効にするために、これらのプロトコルに従
いフォーマットされたパケットを解析または構文解析するために構成されるヘッ
ダパーサモジュールを備えてもよい。通信デバイスはまた、デバイスで受け取ら
れた通信フローを管理するために、フローデータベースまたはフローデータベー
スマネージャを備えてもよい。

【００１８】 （詳細な説明） 以下の説明は、いかなる当業者でも本発明を生産および使用することができる
ように示され、本発明の特定の用途およびそれらの用途の要求のコンテクストで
提供される。開示される実施形態の種々の改変が当業者には容易に明らかであり
、本明細書中に規定される一般的原理は、他の実施形態および用途にも本発明の
精神および範囲を逸脱することなく適用し得る。従って、本発明は、示される実
施形態に限定されることを意図するものではなく、本明細書中に開示される原理
および特徴に整合する最も広い範囲を与えられるべきである。

【００１９】 特に、本発明の実施形態は、インターネットと互換性のある特定の通信プロト
コルに従ってフォーマットされた通信パケットを受け取るネットワークインタフ
ェース回路（ＮＩＣ）の形態で記述される。しかしながら、本発明はインターネ
ットと互換性のある通信プロトコルに限定されず、他のプロトコルとの使用およ
びＮＩＣ以外の通信デバイスにおける使用に容易に適合させ得ることを当業者は
理解する。

【００２０】 本発明の実施形態が実行されるプログラム環境は、例示的に、汎用コンピュー
タまたは携帯型コンピュータなどの特定目的のデバイスを組み込む。そのような
デバイス（例えば、プロセッサ、メモリ、データ格納部、入出力ポートおよびデ
ィスプレイ）の詳細は周知であり、明瞭化の目的のために省略される。

【００２１】 本発明の技術が種々のテクノロジーを使用して実現され得ることが理解される
べきである。例えば、本明細書に記載される方法は、プログラム可能なマイクロ
プロセッサ上で実行されるソフトウェアにおいて実現され得、あるいは、マイク
ロプロセッサの組み合わせまたは他の特別に設計された特定用途向け集積回路、
プログラマブルロジックデバイスもしくは種々のそれらの組み合わせを使用した
ハードウェアにおいて実現され得る。特に、本明細書に記載される方法は、搬送
波、ディスクドライブ、または他のコンピュータ読み取り可能な媒体といった格
納媒体上に存在するコンピュータ実行可能な一連の命令によって実現され得る。

【００２２】 （導入） 本発明の１つの実施形態では、ネットワークインタフェース回路（ＮＩＣ）が
、ホストコンピュータシステムとインターネットなどのネットワークとの間で交
換される通信パケットを受け取り、処理するように構成される。特に、ＮＩＣは
、そのＮＩＣが結合されているネットワークによってサポートされるプロトコル
スタック（例えば、通信プロトコルの組み合わせ）に従ってフォーマットされた
パケットを受け取り、操作するように構成される。

【００２３】 プロトコルスタックは、ＩＳＯ−ＯＳＩ（国際標準化機構−開放型システム間
相互接続）モデルフレームワークを参照して記載され得る。従って、１つの例示
的なプロトコルスタックは、レイヤー４の伝送制御プロトコル（ＴＣＰ）、レイ
ヤー３のインターネットプロトコル（ＩＰ）、およびレイヤー２のイーサネット
（Ｒ）を含む。議論の目的のために、用語「イーサネット（Ｒ）」は、本明細書
中で、標準化されたＩＥＥＥ（米国電気電子技術者協会）８０２．３仕様および
そのプロトコルの非標準の形式のバージョン２を集約的に指すものとして使用さ
れることがある。このプロトコルの異なる形式が区別される必要がある場合には
、標準化された形式は、「８０２．３」の指定を伴って特定することがある。

【００２４】 本発明の他の実施形態は、現時点で既知（例えば、ＡｐｐｌｅＴａｌｋ、ＩＰ
Ｘ（Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｐａｃｋｅｔ Ｅｘｃｈａｎｇｅ）等）および
未知の両方の他のプロトコルに従う通信とともに動作するように構成される。当
業者は、本発明により提供される方法が、新規な通信プロトコルに容易に適合可
能であることを理解する。

【００２５】 さらに、以下に述べるパケット処理は、ＮＩＣ以外の通信デバイス上でも実行
され得る。例えば、モデム、スイッチ、ルータまたは他の通信ポートもしくはデ
バイス（例えば、シリアル、パラレル、ＵＳＢ、ＳＣＳＩ）が、同様に構成され
、動作させられ得る。

【００２６】 以下に述べる実施形態において、ＮＩＣは、ネットワークから、ホストコンピ
ュータシステムまたは他の通信デバイスのためにパケットを受け取る。ＮＩＣは
、（例えば、そのパケットの１以上のプロトコルヘッダーからの特定のフィール
ドを取り出すことにより）パケットを解析し、パケットが伝送され、または宛先
エンティティに提供される効率を高めるための動作を行う。以下に議論される、
ネットワークから受け取ったパケットを処理し、あるいは伝送する効率を高める
ための装置および方法は、逆方向（すなわち、ＮＩＣからネットワークに）に移
動するパケットにも使用され得る。

【００２７】 入来ネットワークトラフィックに適用され得る１つの技術は、入来パケットの
１つ以上のヘッダー（例えば、レイヤー２、３および４のプロトコルためのヘッ
ダー）を検査または構文解析することを伴う。これは、そのパケットのソースエ
ンティティおよび宛先エンティティを識別するためであり、場合によっては、特
定の他の情報を取り出すためである。通信しているエンティティの識別子をキー
として使用して、複数のパケットからのデータが集められ、あるいはリアセンブ
ルされ得る。通常、１つのソースエンティティから１つの宛先エンティティに送
られるデータグラムは、複数のパケットを介して送信される。このようにして、
複数の関連するパケット（例えば、同じデータグラムからのデータを搬送するパ
ケット）からデータを集めることにより、データグラムをリアセンブルし、全体
としてホストコンピュータに伝送することが可能になる。次いで、データグラム
は、宛先エンティティに高効率な態様で提供され得る。例えば、別々の「コピー
」動作により、一度に１つのパケットからのデータ（および一度に１バイト）を
提供するのではなく、「ページフリップ」動作が実行され得る。ページフリップ
では、全メモリページのデータが宛先エンティティに提供され得、場合によって
は、空の、すなわち、未使用のページと交換される。

【００２８】 他の技術では、ネットワークから受け取ったパケットは、ホストコンピュータ
への伝送を待つキューに配置される。伝送を待つ間、ホストコンピュータに関連
する複数のパケットが識別され得る。それらのパケットは、伝送された後、ホス
トプロセッサによって、（例えば、一度に１つずつ）逐次的に処理されるのでは
なくグループとして処理され得る。

【００２９】 さらに他の技術は、いくつかの関連するパケットをマルチプロセッサのホスト
コンピュータシステムの１つのプロセッサに発信することを伴う。異なるプロセ
ッサの中のソースエンティティと宛先エンティティとの異なる組の間で搬送され
るパケットを分散することによって、それぞれのプロトコルスタックを通じたパ
ケットの処理は、パケットを正しい順序に保ったまま、分散することができる。

【００３０】 上記で議論した、パケットが処理される効率を高める技術は、ネットワークイ
ンタフェースおよび／またはホストコンピュータシステム上に位置するハードウ
ェアまたはソフトウェアの組み合わせを伴い得る。１つの特定の実施形態では、
ホストコンピュータのＮＩＣ上の構文解析モジュールが、パケットのヘッダー部
の構文解析を行う。例示的には、構文解析モジュールは、マイクロコードとして
格納された置き換え可能な命令セットに従って動作するマイクロシーケンサを含
む。パケットから抽出された情報を使用して、１つのソースエンティティから１
つの宛先エンティティへの複数のパケットが識別され得る。ＮＩＣ上のハードウ
ェアのリアセンブリモジュールは、次いで、複数のパケットからデータを集め得
る。ＮＩＣ上の他のハードウェアモジュールが、ホストコンピュータへの伝送を
待つ関連したパケットを認識するように構成され、これにより、それらのパケッ
トが適切なプロトコルスタックを通じて、逐次的にではなく、集約的に処理され
得る。リアセンブルされたデータおよびパケットのヘッダーは、次いで、ホスト
コンピュータに提供され得、これにより、適切なソフトウェア（例えば、ＮＩＣ
のためのデバイスドライバ）がそのヘッダーを処理し得、そのデータを宛先エン
ティティに配送し得る。

【００３１】 ホストコンピュータが複数のプロセッサを含む場合には、ロードディストリビ
ュータ（これもまた、ＮＩＣ上のハードウェアに実現され得る）が、プロトコル
スタックを通じて複数のパケットのヘッダーを処理するプロセッサを選択し得る
。

【００３２】 本発明の他の実施形態では、ＮＩＣがホストコンピュータへの伝送を待つパケ
ットで飽和したか、またはほとんど飽和しそうになった場合に、ＮＩＣからのパ
ケットをランダムに廃棄するシステムが提供される。

【００３３】 （高性能ネットワークインタフェース回路の１つの実施形態） 図１Ａは、本発明の例示的な実施形態に従うＮＩＣ１００の構成を示す。この
実施形態におけるＮＩＣ１００の種々のモジュールの動作および相互作用を以下
に簡潔に述べる。

【００３４】 通信パケットは、ＮＩＣ１００において、メディアアクセス制御（ＭＡＣ）モ
ジュール（図１Ａには示されていない）によってネットワーク１０２から受け取
られる。ＭＡＣモジュールは、ネットワークからのパケットの読み出し、何らか
の誤り検査の実行、パケットフラグメントの検出、サイズ超過のパケットの検出
、レイヤー１のプリアンブルの除去等の、パケットの低レベルな処理を実行する
。

【００３５】 入力ポート処理（ＩＰＰ）モジュール１０４は、次いで、そのパケットを受け
取る。ＩＰＰモジュールは、パケットキュー１１６に、ＭＡＣモジュールまたは
ネットワークから受け取った状態のパケットの全体を格納し、パケットの一部は
、ヘッダーパーサ１０６にコピーされる。本発明の１つの実施形態では、ＩＰＰ
モジュール１０４は、パケットをホストコンピュータシステムへの伝送のために
備える、ある種の調整役として機能し得る。このような役割において、ＩＰＰモ
ジュール１０４は、ＮＩＣ１００の種々のモジュールからのパケットに関する情
報を受け取り得、そのような情報を他のモジュールにディスパッチし得る。

【００３６】 ヘッダーパーサ１０６は、パケットのヘッダー部を構文解析し、関連するパケ
ット（例えば、１つの宛先エンティティについて、１つの同じソースエンティテ
ィからの複数のパケット）を識別するために使用される種々の情報および引き続
いて行われるパケットの処理に影響を及ぼす種々の情報を取り出す。例示される
実施形態では、ヘッダーパーサ１０６は、フローデータベース（ＦＤＢ）１１０
を管理するフローデータベースマネージャ（ＦＤＢＭ）１０８と通信する。特に
、ヘッダーパーサ１０６は、ＦＤＢＭ１０８にクエリを発信し、パケットを送信
したソースエンティティと宛先エンティティとの間に有効な通信フロー（後述）
が存在するかどうかを判定する。宛先エンティティは、パケットを受け取るべき
アプリケーションプログラム、通信モジュールまたはホストコンピュータシステ
ムの何らかの他の要素を含み得る。

【００３７】 本発明の例示される実施形態では、通信フローは、１つのソースエンティティ
から１つの宛先エンティティへの１以上のデータグラムパケットを含む。フロー
は、ヘッダーパーサ１０６によってパケットから取り出されたソース識別子およ
び宛先識別子からアセンブルされたフローキーによって識別される。本発明の１
つの実施形態では、フローキーは、パケットのレイヤー３（例えば、ＩＰ）およ
び／またはレイヤー４（例えば、ＴＣＰ）のプロトコルヘッダーからの、ソース
エンティティおよび宛先エンティティについてのアドレスおよび／またはポート
情報を含む。

【００３８】 本発明の例示される実施形態の目的のために、通信フローは、ＴＣＰエンドト
ゥエンド接続と類似しているが、一般に、持続期間はより短い。特に、この実施
形態では、フローの持続時間は、ソースエンティティから宛先エンティティへと
通過する１つのデータグラムに関連付けられた全てのパケットを受け取るのに要
する時間に制限される。

【００３９】 従って、フロー管理の目的のために、ヘッダーパーサ１０６は、パケットのフ
ローキーをフローデータベースマネージャ１０８に渡す。ヘッダーパーサは、パ
ケットから取り出された、パケットに関する他の情報（例えば、パケットの長さ
）をもフローデータベースマネージャに提供する。

【００４０】 フローデータベースマネージャ１０８は、ヘッダーパーサ１０６から受け取っ
たクエリに応答してＦＤＢ１１０を検索する。例示的には、フローデータベース
１１０は、ＮＩＣ１００が扱う宛先エンティティを伴う各有効な通信フローに関
する情報を格納する。従って、ＦＤＢＭ１０８は、ヘッダーパーサ１０６から受
け取った情報に依存して、必要に応じてＦＤＢ１１０を更新する。さらに、本発
明のこの実施形態では、ＦＤＢＭ１０８は、オペレーションコードまたはアクシ
ョンコードを受け取ったパケットに関連付ける。オペレーションコードは、パケ
ットが新しいフローの一部であるのか既存のフローの一部であるのか、パケット
はデータを含むのか制御情報を含むだけなのか、パケットの中のデータの量はい
くらか、パケットデータは関連するデータ（例えば、そのソースエンティティか
らその宛先エンティティへ送られるデータグラムの中の他のデータ）とリアセン
ブルされ得るか、等を識別するために使用され得る。ＦＤＢＭ１０８は、パケッ
トから取り出され、ヘッダーパーサ１０６によって適切なオペレーションコード
を選択するために提供された情報を使用し得る。パケットのオペレーションコー
ドは、次いで、ＦＤＢ１１０の中でのパケットのフローのインデックスとともに
、ヘッダーパーサに返送される。

【００４１】 本発明の１つの実施形態では、ヘッダーパーサ１０６、ＦＤＢＭ１０８および
ＦＤＢ１１０の組み合わせ、またはこれらのモジュールの部分集合は、ＮＩＣ１
００において受け取ったネットワークトラフィックを分類または識別するという
役割に起因して、トラフィック分類器として理解され得る。

【００４２】 例示される実施形態では、ヘッダーパーサ１０６はまた、パケットのフローキ
ーをロードディストリビュータ１１２に渡す。複数のプロセッサを有するホスト
コンピュータシステムでは、ロードディストリビュータ１１２は、どのプロセッ
サに入来パケットが適切なプロトコルスタックを通じて処理されるためにルーテ
ィングされるべきかを決定し得る。ロードディストリビュータ１１２は、例えば
、関連するパケットが１つのプロセッサにルーティングされることを確実にし得
る。１つの通信フローまたはエンドトゥエンド接続の中の全てのパケットを１つ
のプロセッサに送ることによって、パケットの正しい順序が強制され得る。ロー
ドディストリビュータ１１２は、本発明の代替的な実施形態では、省略され得る
。代替的な実施形態では、ロードディストリビュータおよびフローデータベース
マネージャに加えて、ヘッダーパーサ１０６もまた、ＮＩＣ１００の他のモジュ
ールと直接通信し得る。

【００４３】 従って、ヘッダーパーサ１０６がパケットを構文解析した後に、ＦＤＢＭ１０
８は、ＦＤＢ１１０を改変または更新し、ロードディストリビュータ１１２は、
ホストコンピュータシステムの中の、そのパケットを処理すべきプロセッサを識
別する。これらの動作の後で、ヘッダーパーサは、種々の情報をＩＰＰモジュー
ル１０４に返送する。例示的には、この情報は、パケットのフローキー、フロー
データベース１１０の中のパケットのフローのインデックス、ホストコンピュー
タシステムの中のプロセッサの識別子、およびパケットに関する種々の他のデー
タ（例えば、パケットの長さ、パケットヘッダーの長さ）を含み得る。

【００４４】 今度は、パケットはパケットキュー１１６に格納され得る。パケットキュー１
１６は、ＤＭＡ（ダイレクトメモリアクセス）エンジン１２０によるオペレーシ
ョンおよびホストコンピュータへの伝送のためにパケットを保持する。パケット
をパケットキューの中に格納することに加えて、そのパケットについての対応す
るエントリが制御キュー１１８の中で作成され、そのパケットのフローに関する
情報はまた、動的パケットバッチモジュール１２２に渡され得る。制御キュー１
１８は、パケットキュー１１６の中の各パケットについて、関連する制御情報を
格納している。

【００４５】 パケットバッチモジュール１２２は、パケットキュー１１６の中のパケットに
関する、複数の関連するパケットからのヘッダーのバッチ（すなわち、集約的な
）処理を可能にする情報を利用する。本発明の１つの実施形態では、パケットバ
ッチモジュール１２２は、関連するパケットからのヘッダーの利用可能性をホス
トコンピュータに知らせ、これにより、関連するパケットが一緒に処理され得る
。

【００４６】 本発明の１つの実施形態では、パケットのプロトコルヘッダーの処理はホスト
コンピュータシステム上のプロセッサによって実行されるが、他の実施形態では
、プロトコルヘッダーは、ＮＩＣ１００上に位置するプロセッサによって処理さ
れ得る。前者の実施形態では、ホストコンピュータ上のソフトウェア（例えば、
ＮＩＣ１００のためのデバイスドライバ）は、追加のメモリおよび置き換え可能
またはアップグレード可能なプロセッサ（例えば、メモリが追加され得、プロセ
ッサがより高速なモデルで置き換えられ得る）の利点を享受し得る。

【００４７】 パケットキュー１１６にパケットを格納する間、チェックサムジェネレータ１
１４は、チェックサム動作を実行し得る。チェックサムは、パケットキューに、
パケットへのトレーラとして追加され得る。例示的には、チェックサムジェネレ
ータ１１４は、ネットワーク１０２から受け取ったパケットの一部分からチェッ
クサムを生成する。本発明の１つの実施形態では、チェックサムは、パケットの
ＴＣＰ部分（例えば、ＴＣＰヘッダーおよびデータ）から生成される。パケット
がＴＣＰプロトコルに従ってフォーマットされていない場合には、チェックサム
はパケットの他の部分に基づいて生成され、結果は、必要に応じて後の処理にお
いて調整され得る。例えば、チェックサムジェネレータ１１４によって計算され
たチェックサムがパケットの正しい部分に基づいて計算されなかった場合、チェ
ックサムは、正しい部分を捕獲するように調整され得る。この調整は、ホストコ
ンピュータシステム上で動作するソフトウェア（例えば、デバイスドライバ）に
よってなされ得る。チェックサムジェネレータ１１４は、省略され得るか、また
は、本発明の代替的な実施形態のＮＩＣ１００の他のモジュールに併合され得る
。

【００４８】 ヘッダーパーサ１０６によって得られた情報およびフローデータベースマネー
ジャ１０８によって管理されるフロー情報から、本発明の１つの実施形態のＮＩ
Ｃ１００が扱うホストコンピュータシステムは、非常に効率的にネットワークト
ラフィックを処理することができる。例えば、関連するパケットのデータ部分は
、ＤＭＡエンジン１２０によってリアセンブルされ得、より効率的に操作され得
る集合体を形成する。そして、データをメモリページのサイズのバッファ中にリ
アセンブルすることにより、データは、「ページフリップ」を通じて、より効率
的に宛先エンティティに伝送され得る。「ページフリップ」では、ＤＭＡエンジ
ン１２０によって満たされたメモリページの全体が一度に供給される。従って、
１つのページフリップは、複数のコピー動作の代わりをし得る。一方、リアセン
ブルされたパケットのヘッダー部は、適切なプロトコルスタックを通じて同様に
グループとして処理され得る。

【００４９】 既に述べたように、本発明の他の実施形態では、適切なプロトコルスタックを
通じたネットワークトラフィックの処理は、マルチプロセッサのホストコンピュ
ータシステムにおいて効率的に分散され得る。この実施形態では、ロードディス
トリビュータ１１２は、関連するパケット（例えば、同じ通信フローの中のパケ
ット）を同じプロセッサに割り当てる、すなわち、分散する。特に、レイヤー３
（例えば、ＩＰ）のプロトコルヘッダー中に同一のソースアドレスおよび宛先ア
ドレスを有するパケットおよび／またはレイヤー４（例えば、ＴＣＰ）のプロト
コルヘッダー中に同一のソースポートおよび宛先ポートを有するパケットは、１
つのプロセッサに送られ得る。

【００５０】 図１Ａに示されるＮＩＣでは、上記で議論した処理の向上（例えば、データの
リアセンブル、パケットヘッダーのバッチ処理、プロトコルスタック処理の分散
）は、ネットワーク１０２が受け取った、１つ以上の予め選択されたプロトコル
スタックに従ってフォーマットされたパケットについて可能である。本発明のこ
の実施形態では、ネットワーク１０２は、インターネットであり、それゆえ、Ｎ
ＩＣ１００は、インターネットと互換性のあるいくつかのプロトコルスタックの
１つを用いてパケットを処理するために構成される。予め選択されたプロトコル
に従って構成されないパケットもまた処理されるが、予め選択されたプロトコル
に適合するパケットに提供される処理効率の利益を完全には享受しない場合があ
る。

【００５１】 例えば、予め選択されたプロトコルスタックの１つに合わないパケットは、レ
イヤー３またはレイヤー４のアドレスではなく、レイヤー２（例えば、メディア
アクセス制御）のソースアドレスおよび宛先アドレスに基づいて、マルチプロセ
ッサシステムにおける処理のために分散され得る。レイヤー２の識別子を使用す
ることによって、負荷分散手順における粒度が低下し、従って、レイヤー３／４
の識別子が使用された場合よりも、パケットの処理をより不均一に分散する場合
がある。

【００５２】 図１Ｂは、図１ＡのＮＩＣ１００を使用してネットワーク１０２から１つのパ
ケットを受け取り、そのパケットをホストコンピュータに伝送する１つの方法を
示す。状態１３０は、開始状態であり、ＮＩＣ１００の初期化またはリセットに
よって特徴付けられる場合がある。

【００５３】 状態１３２において、パケットはＮＩＣ１００によってネットワーク１０２か
ら受け取られる。既に述べたように、パケットは種々の通信プロトコルに従って
フォーマットされ得る。パケットは、ＩＰＰモジュールに渡される前に、ＭＡＣ
モジュールによって受け取られ、最初に操作される。

【００５４】 状態１３４において、パケットの一部分がコピーされ、ヘッダーパーサ１０６
に渡される。ヘッダーパーサ１０６は、次いで、そのパケットを構文解析し、そ
のヘッダーおよび／またはデータのうち１つ以上から値を抽出する。フローキー
が、そのパケットを含む通信フローを識別するために、取り出された情報のいく
つかから生成される。ヘッダーパーサが、異なるプロトコルのヘッダーを異なる
深さまで構文解析するように構成され得るという点において、パケットが構文解
析される度合いまたは程度は、パケットのプロトコルに依存し得る。特に、ヘッ
ダーパーサ１０６は、特定のプロトコルまたはプロトコルスタックの集合につい
て最適化され得る（例えば、その動作命令が構成され得る）。パケットが１以上
の特定のプロトコルに従う場合、そのパケットは、プロトコルのいずれにも従わ
ないパケットよりもより詳細に構文解析され得る。

【００５５】 状態１３６において、パケットヘッダーから抽出された情報は、フローデータ
ベースマネージャ１０８および／またはロードディストリビュータ１１２に転送
される。ＦＤＢＭは、フローデータベース１１０の中のフローがこの通信フロー
についてまだ存在しない場合、フローデータベース１１０の中のフローを設定す
るための情報を使用する。パケットのフローについてエントリが既に存在する場
合には、新しいフローパケットを受け取ったことを反映するために、そのエント
リは更新され得る。さらに、ＦＤＢＭ１０８は、パケットの１つ以上の特徴また
は条件を要約するオペレーションコードを生成する。オペレーションコードは、
以降のセクションで述べるように、パケットを適切な態様で取り扱うために、Ｎ
ＩＣ１００の他のモジュールによって使用され得る。オペレーションコードは、
フローデータベースの中のパケットのフローのインデックス（例えば、フロー番
号）とともに、ヘッダーパーサに返される。

【００５６】 状態１３８において、ロードディストリビュータ１１２は、ホストコンピュー
タが複数のプロセッサを含む場合、パケットにプロセッサ番号を割り当て、ヘッ
ダープロセッサにプロセッサ番号を返す。例示的には、プロセッサ番号は、どの
プロセッサが、ホストコンピュータ上でそのプロトコルスタックを通じてパケッ
トを管理するかを識別する。状態１３８は、本発明の代替的な実施形態では、特
にホストコンピュータがただ１つのプロセッサから構成される場合には、省略さ
れ得る。

【００５７】 状態１４０において、パケットはパケットキュー１１６に格納される。パケッ
トの内容がパケットキューに配置されると、チェックサムジェネレータ１１４は
、チェックサムを計算し得る。チェックサムジェネレータ１１４は、ＩＰＰモジ
ュール１０４によって、パケットのどの部分に基づいてチェックサムを計算すべ
きかについて知らされ得る。計算されたチェックサムは、パケットキューにその
パケットのトレーラとして付加される。本発明の１つの実施形態では、パケット
は、パケットのヘッダー部のコピーがヘッダーパーサ１０６に提供されるのと実
質的に同時にパケットキューに格納される。

【００５８】 状態１４０において、また、パケットについての制御情報が制御キュー１１８
に格納され、パケットのフローに関する情報（例えば、フロー番号、フローキー
）が、動的パケットバッチモジュール１２２に提供され得る。

【００５９】 状態１４２において、ＮＩＣ１００は、パケットが、ホストコンピュータのメ
モリに伝送される準備ができているかどうかを判定する。例示される手順は、伝
送される準備ができるまで待つ。

【００６０】 パケットが、伝送される準備ができる（例えば、パケットがパケットキューの
先頭にあるか、ホストコンピュータが、パケットキューの中の、このパケットの
前のパケットを受け取る）と、状態１４４において、動的パケットバッチモジュ
ール１２２は、関連するパケットがすぐに伝送されるかどうかを判定する。もし
そうであるなら、現在のパケットがホストのメモリに伝送される時に、ホストコ
ンピュータは、関連するパケットがすぐに続くことを知らされる。その場合、ホ
ストコンピュータは、パケットをグループとして（例えば、パケットのプロトコ
ルスタックを通じて）処理し得る。

【００６１】 状態１４６において、パケットは、ホストコンピュータのメモリに（例えば、
ダイレクトメモリアクセス動作によって）伝送される。そして、状態１４８にお
いて、ホストコンピュータは、パケットが伝送されたことを通知される。例示さ
れる手順は、次いで、状態１５０で終了する。

【００６２】 コンピュータシステムおよびネットワークの当業者は、上述した手順が、ＮＩ
Ｃ１００のモジュールを採用して、ネットワークから１つのパケットを受け取り
、そのパケットをホストコンピュータシステムに伝送するための１つの方法に過
ぎないことを理解する。他の適切な方法もまた、本発明の範囲内で考えられる。

【００６３】 （例示的なパケット） 図２は、ＮＩＣ１００によってネットワーク１０２から受け取られる例示的な
パケットの図である。パケット２００は、データ部２０２とヘッダー部２０４と
を含み、また、トレーラ部２０６をも含み得る。パケット２００がやりとりされ
るネットワーク環境に依存して、パケット２００の最大サイズは、（例えば、そ
の最大伝送単位すなわちＭＴＵに）制限され得る。

【００６４】 例示される実施形態では、データ部２０２は、コンピュータシステムの中の宛
先、すなわち受け手エンティティ（例えば、ユーザ、アプリケーションプログラ
ム、オペレーティングシステム）またはコンピュータの通信サブシステムに提供
されるデータを含む。ヘッダー部２０４は、ソースすなわち発信元エンティティ
またはソースエンティティを含むコンピュータシステムによってデータ部の前に
冠された１以上のヘッダーを含む。各ヘッダーは、通常、異なる通信プロトコル
に対応している。

【００６５】 インターネットのような通常のネットワーク環境では、ヘッダー部２０４の中
の個々のヘッダーは、送信コンピュータシステム上で、プロトコルスタック（例
えば、エンティティ間で通信するためのプロトコルの集合）の異なるレイヤーを
通じてパケットが処理される際に、付加される（例えば、プリペンドされる）。
例えば、図２は、それぞれ適切なプロトコルスタックのレイヤー１〜４に対応す
るプロトコルヘッダー２１０、２１２、２１４および２１６を示す。各プロトコ
ルヘッダーは、パケットが受け取られ、プロトコルスタックを通じて処理される
際に受け手のコンピュータシステムによって使用されるべき情報を格納している
。最終的に、各プロトコルヘッダーは除去され、データ部２０２が取り出される
。

【００６６】 他のセクションに記載されるように、本発明の１つの実施形態では、パケット
２００を構文解析して種々の情報のビットを取り出すためのシステムおよび方法
が提供される。この実施形態では、パケット２００は、データ部２０２の始まり
を識別するため、および、ヘッダー部２０４の中のフィールドについての１以上
の値を取り出すために構文解析される。しかしながら、例示的には、レイヤー１
のプロトコルヘッダーまたはプリアンブル２１０は、個々のビットのコーディン
グに関するハードウェアレベルの仕様に対応する。レイヤー１のプロトコルは、
一般に、導線にわたるパケットの送信または受信の物理的な処理のためだけに必
要とされる。従って、本発明のこの実施形態では、レイヤー１のプリアンブル２
１０は、ＮＩＣ１００によって受け取られた直後にパケット２００から取り除か
れ、それゆえ、構文解析されない。

【００６７】 ヘッダー部２０４が構文解析される程度は、ヘッダー部に示されるプロトコル
のうちのいくつが予め選択されたプロトコルに（もし合うものがあるなら）合う
かに依存する。例えば、パケットヘッダーの１つがサポートされないプロトコル
に対応すると一旦判定されると、構文解析処理は、省略されるかまたは中止され
得る。

【００６８】 特に、本発明の１つの実施形態では、ＮＩＣ１００は、主にインターネットト
ラフィックのために構成される。従って、この実施形態では、パケット２００は
、レイヤー２のプロトコルがイーサネット（Ｒ）（従来のイーサネット（Ｒ）ま
たは８０２．３イーサネット（Ｒ）、仮想ローカルエリアネットワークのための
タグありまたはなし）であり、レイヤー３のプロトコルがＩＰ（インターネット
プロトコル）であり、レイヤー４のプロトコルがＴＣＰ（伝送制御プロトコル）
である場合にのみ、詳細に構文解析される。他のプロトコルに従うパケットは、
何らかの（例えば、より低い）程度で構文解析され得る。しかしながら、ＮＩＣ
１００は、実質的にいかなる通信プロトコルのヘッダーをもサポートし、構文解
析するように構成され得る。例示的には、構文解析されるプロトコルヘッダーお
よびプロトコルヘッダーが構文解析される程度は、ヘッダーパーサ１０６を動作
させるための命令セットの構成によって決定される。

【００６９】 上述したように、ヘッダー２１２、２１４および２１６に対応するプロトコル
は、パケットが送られるネットワーク環境に依存する。プロトコルはまた、通信
するエンティティに依存する。例えば、ネットワークインタフェースによって受
け取られるパケットは、ソースおよび宛先コンピュータシステムについてのメデ
ィアアクセスコントローラの間で交換される制御パケットであり得る。この場合
、パケットは、最小限のデータを含むか、データを含まないことがありがちであ
り、レイヤー３のプロトコルヘッダー２１４またはレイヤー４のプロトコルヘッ
ダー２１６を含まないことがあり得る。制御パケットは、通常、個々の接続の管
理に関連する種々の目的のために使用される。

【００７０】 他の通信フローまたは接続は、２つのアプリケーションプログラムを含み得る
。この場合、パケットは、図２に示されるように、ヘッダー２１２、２１４およ
び２１６を含み得、プロトコルスタックのより高いレイヤー（例えば、ＩＳＯ−
ＯＳＩモデルにおけセッション層、プレゼンテーション層およびアプリケーショ
ン層）に関連する追加のヘッダーをも含み得る。さらに、いくつかのアプリケー
ションは、ヘッダーまたはヘッダーに類似の情報をデータ部２０２の中に含み得
る。例えば、ネットワークファイルシステム（ＮＦＳ）用途では、データ部２０
２は、個々のＮＦＳデータグラムに関連するＮＦＳヘッダーを含み得る。データ
グラムは、１つのエンティティから他のエンティティへ送られるデータの集合と
して定義され得、複数のパケットで送信されるデータを含み得る。換言すれば、
データグラムを構成するデータの量は、１つのパケットに含まれ得るデータの量
よりも大きくあり得る。

【００７１】 （ヘッダーパーサの１つの実施形態） 図３は、本発明の実施形態に従う図１Ａのヘッダーパーサ１０６を示す。例示
されたように、ヘッダーパーサ１０６は、ヘッダーメモリ３０２およびパーサ３
０４を備え、パーサ３０４は、命令メモリ３０６を備える。図３に別個のモジュ
ールとして示されるが、本発明の代替的な実施形態において、ヘッダーメモリ３
０２および命令メモリ３０６は、連結さていれる。

【００７２】 示された実施形態において、パーサ３０４は、命令メモリ３０６に格納された
命令に従って、ヘッダーメモリ３０２に格納されたヘッダーを構文解析する。こ
の命令は、上述されたような特定のプロトコルまたは特定のプロトコルスタック
の構文解析用として設計される。本発明の１つの実施形態において、命令メモリ
３０６は、変更可能であり（例えば、メモリは、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲ
ＯＭまたはその同等物としてインプリメントされる）、それにより、新しいまた
は変更された構文解析命令が、ダウンロードされ得るか、そうでなければインス
トールされ得る。パケットを構文解析するための命令は、以降のセクションでよ
り詳細に議論される。

【００７３】 図３において、ＩＰＰモジュール１０４（図１Ａに示す）に格納されたパケッ
トのヘッダー部は、ヘッダーメモリ３０２にコピーされる。例示されたように、
パケットの先頭の特定のバイト数（例えば、１１４）がコピーされる。本発明の
代替的な実施形態において、コピーされたパケットの部分は、異なるサイズを有
し得る。ヘッダーメモリ３０２にコピーされたパケットの特定の量は、１つ以上
のプロトコルヘッダー、または以下に説明される情報を取り出すために少なくと
も十分な情報（例えば、パケットのヘッダー部またはデータ部に含まれるかどう
か）をキャプチャするために十分でなければならない。ヘッダーメモリ３０２に
格納されたヘッダー部は、レイヤー１ヘッダーを含み得ず、このヘッダーは、Ｉ
ＰＰモジュール１０４により処理されるパケットより前に、または同時に取り除
かれ得る。

【００７４】 パケットのヘッダー部がヘッダーメモリ３０２に格納された後、パーサ３０４
は、命令メモリ３０６に格納された命令に従ってヘッダー部を構文解析する。こ
こで説明された実施形態のパーサ３０４を動作する命令は、ヘッダーメモリ３０
２のコンテンツを介して進むために、かつ特定の情報を取り出すために選択され
たプロトコルのフォーマットを適用する。特に、通信プロトコルの仕様は周知で
あり、広範に利用される。従って、プロトコルヘッダーは、バイト単位で、また
はプロトコル仕様を参照することにより、その他のある方式で移動し得る。従っ
て、本発明のこの実施形態において、構文解析アルゴリズムはダイナミックであ
り、それによってヘッダーの１つのフィールドから取り出された情報は別の部分
が構文解析される方式をしばしば変更する。

【００７５】 例えば、従来のイーサネット（登録商標）の形式（例えば、バージョン２）に
従うパケットのタイプフィールドは、（レイヤー２）ヘッダーの１３番目のバイ
トで始まるということが知られている。比較すると、イーサネット（登録商標）
のＩＥＥＥ ８０２．３バージョンに従うパケットのタイプフィールドは、ヘッ
ダーの２１番目のバイトで始まるということが知られている。タイプフィールド
は、パケットが（イーサネット（登録商標）ヘッダーをタグ付けするまたはカプ
セル化することを例示的に含む）バーチャルローカルエリアネットワーク（ＶＬ
ＡＮ）通信の一部を形成する場合に、さらに他の位置にある。従って、本発明の
この実施形態において、あるフィールドにおける値は、ベッダーから必要とされ
る情報がヘッダーの正しい位置から引き出されることを保証するために、取り出
され、テストされる。ＶＬＡＮパケット形式に関する詳細は、イーサネット（登
録商標）プロトコルのＩＥＥＥ ８０２．３ｐ形式およびＩＥＥＥ ８０２．３
ｑ形式用の仕様で見い出され得る。

【００７６】 ヘッダーパーサ１０６のオペレーションはまた、プロトコル間の他の差異（例
えば、パケットがインターネットプロトコル等のバージョン４またはバージョン
６を使用するかどうか）に依存する。ＩＰのバージョン４および６用の仕様は、
それぞれ、ＩＥＴＦ（インターネット通信技術作業部会）ＲＦＣ（コメント要請
）７９１および２４６０に位置づけられ得る。

【００７７】 パーサ３０４として「公知の」プロトコルが増えれば増えるほど、パケットを
テストし得るプロトコルが増え、そしてパケットのヘッダー部の構文解析がより
複雑になり得る。当業者は、パーサ３０４によって構文解析され得るプロトコル
がパーサの動作に従う命令によってのみ制限されることを理解する。従って、命
令メモリ３０６に格納された構文解析命令を増やすまたは置換することにより、
実質的に既知の全てのプロトコルがヘッダーパーサ１０６により処理され得、実
質的に任意の情報がパケットのヘッダーから取り出され得る。

【００７８】 もちろん、パケットヘッダーが予想されプロトコルまたは予測されたプロトコ
ルに適合しない場合、構文解析オペレーションは、終了され得る。この場合にお
いて、パケットは、ＮＩＣ１００によって与えられる１以上の効率強化（例えば
、データアセンブリ、パケットバッチング、負荷分散に対して適切であり得ない
。

【００７９】 例示されたように、パケットのヘッダーから取り出された情報は、そのパケッ
トを処理する際に、ＮＩＣ１００の他の部分により使用される。例えば、パーサ
３０４によって実行されたパケット構文解析の結果として、フローキーが、パケ
ットを含む通信フローまたは通信接続を識別するために生成される。例示された
ように、このフローキーは、１つ以上の通信エンティティに対応する１つ以上の
アドレスを連結することによりアセンブルされる。この実施形態において、フロ
ーキーはＩＰヘッダーから引き出されたおよび宛先アドレスならびにＴＣＰヘッ
ダーから取り出されたソースおよび宛先部分の組み合せから形成される。通信エ
ンティティの他の印（ｉｎｄｉｃｉａ）は、例えば、（レイヤー２ヘッダーから
引き出される）イーサネット（登録商標）ソースおよび宛先アドレス、ＮＦＳフ
ァイルハンドルあるいはパケットのデータ部から引き出される他のアプケーショ
ンデータグラム用のソース識別子および宛先識別子が使用され得る。

【００８０】 当業者は、通信エンティティがパケットに関連したプロトコルスタックより高
いレイヤーから引き出される印を用いることにより、より大きな分解能で識別さ
れ得る。従って、ＩＰおよびＴＣＰの印の組合せは、レイヤー２の情報より大き
な特徴を有するエンティティを識別し得る。

【００８１】 フローキーに加えて、パーサ３０４はまた、パケットに関する付加的な情報を
要約するために、制御インジケータまたはステータスインジケータを生成する。
本発明の１つの実施形態において、制御インジケータは、シーケンス番号（例え
ば、ＴＣＰヘッダーから引き出されるＴＣＰのシーケンス番号）を含むため、そ
れらのデータをリアセンブリする際のパケットの正確な順番を保証する。制御イ
ンジケータはまた、パケットのヘッダーの所定のフラグが設定またはクリアされ
ているかどうか、パケットが任意のデータを含んでいるかどうか、そしてパケッ
トがデータを含んでいる場合、そのデータが所定のサイズを越えるかどうかも明
らかにし得る。他のデータはまた、制御インジケータに挿入するために適切であ
り得、パーサ３０４によって構文解析されたパケット部で利用可能な情報によっ
てのみ制限される。

【００８２】 本発明の１つの実施形態において、ヘッダーパーサ１０６は、フローキーと、
フローデータベースマネージャ１０８に対する制御インジケータの全てまたは一
部を提供する。以下のセクションで議論されるように、ＦＤＢＭ１０８はＮＩＣ
１００を介して送る通信フローに関連する情報を含むデータベースまたは他のデ
ータ構造を管理する。

【００８３】 本発明の他の実施形態において、パーサ３０４は、ＮＩＣ１００の他のモジュ
ールによって使用するためのパケットのヘッダーから得られた付加的な情報を生
成する。例えば、ヘッダーパーサ１０６は、パケットの先頭からまたは他のある
ポイントからの、ネットワークから受け取ったパケットのデータまたはペイロー
ド部のオフセットを報告し得る。上記で説明されたように、パケットのデータ部
は、典型的に、ヘッダー部に続き、トレーラ部の後に続き得る。ヘッダパーサ１
０６が報告し得る他のデータは、チェックサムオペレーションが始まるべきパケ
ットの位置、レイヤー３ヘッダーおよび／またはレイヤー４ヘッダーが始まるパ
ケットの位置、診断データ、ペイロード情報等を含む。用語「ペイロード」は、
パケットのデータ部を参照するためによく使用される。特に、本発明の１つの実
施形態において、ヘッダーパーサ１０６は、ペイロードオフセットおよびペロー
ドサイズを提供して、キュー１１８を制御する。

【００８４】 適切な環境において、ヘッダーパーサ１０６はまた、パーサ３０４が操作する
ように構成されるプロトコルに従ってパケットがフォーマットされないことを（
例えば、ＩＰＰモジュール１０４および／または制御キュー１１８に）報告し得
る。この報告は、信号（例えば、以下に説明されるＮｏ＿Ａｓｓｉｓｔ信号）、
警告、フラグまたは他のインジケータの形式でとられてもよい。上記で説明され
た処理強化（例えば、データリアセンブリ、パケットヘッダーのバッチ処理、負
荷分散）と互換性のある予め選択されたプロトコルを以外のプロトコルを反映し
てパケットが発見されるときにいつでも、この信号は生じ得るか、発行され得る
。例えば、本発明の１つの実施形態において、パーサ３０４は、レイヤー４のＴ
ＣＰ、レイヤー３のＩＰ、レイヤー２のイーサネット（登録商標）を用いてパケ
ットを構文解析するためにかつ効果的に処理するために構成され得る。この実施
形態において、ＩＰＸ（インターネットワークパケット交換）パケットは、互換
性のあるものと考慮されず、従って、ＩＰＸパケットは、データリアセンブリお
よびバッチ処理用に集められない。

【００８５】 本発明の１つの実施形態の構文解析の結果において、上記で説明された情報の
種々の構成要素（ｐｉｅｃｅ）は、ＮＩＣ１００の適切なモジュールに広められ
る。この後（かつ以下のセクションで説明されるように）、フローデータベース
マネージャ１０８は、アクティブフローがパケットから得られる、フローキーに
関連するかどうかを判定し、後に続く処理で使用されるオペレーションコードを
設定する。加えて、ＩＰＰモジュール１０４は、パケットキュー１１６にパケッ
トを伝送する。ＩＰＰモジュール１０４はまた、ヘッダーパーサ１０６により抽
出されたいくつかの情報を受け取り得、ＮＩＣ１００の別のモジュールにその情
報を送り得る。

【００８６】 図３に示された本発明の１つの実施形態において、構文解析されるべき受け取
られたパケットのヘッダー部の全体は、コピーされ、続いて、１つの展開で構文
解析される。その後、ヘッダーパーサが、その注意を別のパケットに向ける。し
かしながら、代替的な実施形態において、複数のコピーおよび／または構文解析
オペレーションは、単一のパケットに関して実行され得る。特に、パケットの初
期ヘッダー部は、初めの展開でヘッダーパーサ１０６にコピーされ得、ヘッダー
パーサ１０６により構文解析され得る。その後、別のヘッダー部が、ヘッダーパ
ーサ１０６にコピーされ得、第２展開で構文解析され得る。１つの展開における
ヘッダー部は、別の展開のヘッダー部と部分的にまたは完全にオーバーラップし
得る。このように、広範囲にわたるヘッダーは、たとえヘッダーメモリ３０２が
制限されたサイズの大きさであっても、構文解析され得る。同様に、命令メモリ
３０６にパケットを構文解析するための完全な命令セットをロードするための１
つより多いオペレーションを必要とし得る。例示されたように、命令の第１の部
分は、ロードされ得、実行され得る。その後、他の命令が、ロードされる。

【００８７】 ここで、図４Ａ〜４Ｂを参照して、ヘッダーパーサがネットワークインターフ
ェース回路においてネットワークから受け取られるパケットのヘッダー部を構文
解析し得る１つの方法を例示するフローチャートが示される。このインプリメン
テーションにおいて、ヘッダーパーサは、一組の予め選択されたプロトコル（ま
たはプロトコルスタック）に適合するパケットを構文解析するように構成される
か、または最適化される。これらの判定基準を満足するパケットに対して、様々
な情報が関連するパケット（例えば、単一データグラムからのデータを含むパケ
ット）のデータ部のリアセンブリに役立つように、ヘッダー部から取り出される
。ネットワークインターフェース回路の他の強化した機能はまた、イネーブルさ
れ得る。

【００８８】 ヘッダーパーサにより生成された情報は、特に、受け取ったパケットを含む通
信フローまたは通信接続を識別するためのフローキーを含む。本発明の１つの実
施形態において、同じフローキーを有するパケットからのデータは、データグラ
ムを形成するために識別され得、リアセンブリされ得る。加えて、同じフローキ
ーを有するパケットのヘッダーは、そのプロトコルスタックを（例えば、連続的
にというよりも）集合的に処理され得る。

【００８９】 本発明の別の実施形態において、ヘッダーパーサにより取り出された情報はま
た、ネットワークから受け取られたネットワークトラフィックの処理を分散する
ために使用される。例えば、同じフローキーを有する複数のパケットは、マルチ
プロセッサホストコンピュータシステムの単一プロセッサに発信され得る。

【００９０】 図４Ａ〜４Ｂに示される方法において、一組の予め決められたプロトコルは、
インターネットを介してたびだび伝送される通信プロトコルと対応する。特に、
この方法において大規模に構文解析され得る一組のプロトコルは、以下を含む。
レイヤー２において：イーサネット（登録商標）（従来のバージョン）、８０２
．３ イーサネット（登録商標）、イーサネット（登録商標） ＶＬＡＮ（バー
チャルローカルエリアネットワーク）および８０２．３ イーサネット（登録商
標）ＶＬＡＮ。レイヤー３において：ＩＰｖ４（オプションなし）およびＩＰｖ
６（オプションなし）。最後に、レイヤー４において、ＴＣＰプロトコルヘッダ
ー（オプションありまたはオプションなし）のみが、例示した方法で構文解析さ
れる。本発明の代替的な実施形態におけるヘッダーパーサは、他のプロトコルス
タックを介してフォーマットされたパケットを構文解析する。特に、ＮＩＣは、
所与のネットワークで使用する最も一般的なプロトコルスタックに従って構成さ
れ得る。このＮＩＣは、図４Ａ〜４Ｂに示されるヘッダーパーサ方法と互換性の
あるプロトコルを含んでもよいし、含まなくてもよい。

【００９１】 以下に例示されるように、所与の方法により構文解析されたプロトコルと対応
しない受け取られたパケットはフラグされ得、構文解析アルゴリズムは、そのパ
ケットを終端処理し得る。パケットがフォーマットされた条件下でのプロトコル
が唯一判定され得るため、本発明の方法において、あるヘッダーフィールド値を
検査することにより、パケットが選択されたプロトコルのセットに適合しないと
いう判定が、そのプロシージャの間実質的に任意の時点でなされ得る。従って、
示された構文解析方法は、データのリアセンブリ用のフォーマット基準に合致し
ないパケットの識別子を１つの目標としている。

【００９２】 選択されたプロトコルのヘッダーに現れる種々のプロトコルヘッダーフィール
ドが、以下で議論される。本発明の実施形態（例えば、ヘッダーパーサにより構
文解析され得るプロトコル）と互換性があり得る通信プロトコルは、当業者に周
知であり、多くの文献で非常に詳細に説明される。従って、この通信プロトコル
については、本明細書中で詳細に説明する必要はない。加えて、選択されたプロ
トコルに対するパケットのヘッダー部を構文解析する例示された方法は、以下で
説明される情報を集める１つの方法に過ぎない。情報を集めることの可能な他の
構文解析プロシージャは、同様に適切である。

【００９３】 本発明のこの実施形態において、例示されたプロシージャは、ハードウェアお
よびソフトウェアの組合せとしてインプリメントされる。例えば、プロシージャ
を実行する更新可能なマイクロコード命令は、マイクロシーケンサーにより実行
され得る。あるいは、このような命令は、固定（例えば、読み出し専用メモリで
格納されてもよい）されてもよいし、あるいは、プロセッサまたはマイクロプロ
セッサにより実行されてもよい。

【００９４】 図４Ａ〜４Ｂにおいて、状態４００は、パケットがＮＩＣ１００（図１Ａに図
示）により受け取られ、かつ初期処理が実行される間の開始状態である。ＮＩＣ
１００は、このプロシージャの目的のため、インターネットに接続される。初期
処理は、基本的なエラーチェックとレイヤー１プリアンブル除去とを含み得る。
初期処理の後、パケットは、ＩＰＰモジュール１０４（図１Ａにも図示）より保
持される。本発明の１つの実施形態において、状態４００は、パケットが受け取
られるまでヘッダーパーサがアイドル状態または待ち状態を保つ論理ループを含
む。

【００９５】 状態４０２において、パケットのヘッダー部は、メモリ（例えば、図３のヘッ
ダーメモリ３０２）内にコピーされる。本発明のこの実施形態において、パケッ
トの先頭の所定数のバイト（例えば、１１４バイト）がコピーされる。異なるサ
イズのパケット部は、本発明の代替的な実施形態においてコピーされ、パケット
部のサイズは、必要なヘッダー情報をキャプチャするかつ／または識別するため
の十分なパケットをコピーする目標により導出される。例示されたように、完全
なパケットは、以下の構文解析オペレーションが実行される間、ＩＰＰモジュー
ル１０４により保持されるが、代替的にパケットは、構文解析が完了する前にパ
ケットキュー１１６に格納され得る。

【００９６】 状態４０２においても、パケットを構文解析する際に使用されるポインタが初
期化され得る。レイヤー１プリアンブルが取り除かれたので、メモリにコピーさ
れるヘッダー部は、レイヤー２プロトコルヘッダーで開始しなければならない。
従って、例示されたように、このポインタは、最初に、レイヤー２プロトコルヘ
ッダーの１２番目のバイトを指定するように設定され、ポンイタ部の２バイト値
が読み出される。当業者に認識されているように、これらの２バイトは、多くの
異なるフィールドの一部であり得、どのプロトコルがパケットのプロトコルスタ
ックのレイヤー２を構成するかに依存する。例えば、これらの２バイトは、従来
のイーサネット（登録商標）ヘッダーのタイプフィールド、８０２．３ イーサ
ネット（登録商標）ヘッダーの長さフィールド、またはＶＬＡＮのタグ付けされ
たヘッダーのＴＰＩＤ（タグプロトコル識別子）フィールドを含み得る。

【００９７】 状態４０４において、第１の検査は、ＶＬＡＮのタグ付けされたレイヤー２プ
ロトコルヘッダーを含むかどうかを判定するためにレイヤー２ヘッダーについて
行われる。例示されたように、この判定は、ポインタ位置で２バイトが１６進数
値８１００を格納するかどうかに依存する。そのような場合、このポインタは、
ＶＬＡＮのタグ付けされたヘッダーのＴＰＩＤフィールドでおそらく位置付けさ
れる。ＶＬＡＮヘッダーでない場合、そのプロシージャは状態４０８に進む。

【００９８】 しかしながら、レイヤー２ヘッダーがＶＬＡＮのタグ付けされたヘッダーであ
る場合、状態４０６においてＣＦＩ（標準形インジケータ）ビットが検査される
。ＣＦＩビットが設定される（例えば、１に等しい）場合、示されたプロシージ
ャは、状態４３０にジャンプし、その後、プロシージャは終了する。本発明のこ
の実施形態において、設定する際のＣＦＩビットは、パケットのフォーマットが
予め選択されたプロトコル（例えば、レイヤー２プロトコルはイーサネット（登
録商標）または８０２．３イーサネット（登録商標）でない）と互換性がない（
すなわち、完全に適合しない）。ＣＦＩビットがクリアにされる（例えば、０に
等しい）場合、ポインタは、検査されるべき次のフィールドでポインタを位置付
けるように（例えば、４バイトだけ）インクリメントされる。

【００９９】 状態４０８において、レイヤー２ヘッダーがさらにテストされる。状態４０８
がそれぞれ、状態４０６を介して到達したか、または状態４０４から直接到達し
たかに依存してレイヤー２ヘッダーがＶＬＡＮのタグ付けされたヘッダーか、ま
たはそうでないかは分からないが、ヘッダーは、従来のイーサネット（登録商標
）フォーマットまたは８０２．３イーサネット（登録商標）フォーマットのどち
らかを反映し得る。状態４０８のはじまりにおいてポインタは、ヘッダーの１２
番目バイトまたはヘッダーの１６番目バイトのいずれかにあり、このヘッダーの
どちらかが長さフィールドまたはタイプフィールドに対応し得る。特に、ポイン
タにより識別された位置での２バイト値が０６００（１６進数）未満である場合
、パケットが８０２．３イーサネット（登録商標）に対応し、ポインタが長さフ
ィールドを識別すると理解される。そうでなければ、このパケットは、従来の（
例えば、バージョン２）イーサネット（登録商標）パケットポインタは、タイプ
フィールドを識別する。

【０１００】 レイヤー２プロトコルが８０２．３イーサネット（登録商標）である場合、プ
ロシージャは状態４１０に続く。レイヤー２プロトコルが従来のイーサネット（
登録商標）である場合、タイプフィールドは、０８００および０８ＤＤの１６進
数値に対してテストされる。テストされたフィールドがこれらの値のうちの１つ
である場合、パケットのレイヤー３プロトコルがインターネットプロトコルであ
るということも決定されてきた。この場合において、示されたプロシージャが、
状態４１２に続く。最後に、このフィールドが０８００および８６ＤＤ（１６進
数）以外の値を有するタイプフィールドである場合、パケットのレイヤー３プロ
トコルは、どのヘッダーパーサが構成されたかに従って予め選択されたプロトコ
ルと一致しない。従って、このプロシージャは状態４３０に続き、その後、終了
する。

【０１０１】 本発明の１つの実施形態において、パケットは、パケットがジャンボイーサネ
ット（登録商標）フレームであるかどうかを判定するために、状態４０８で検査
される。レイヤー２ヘッダーがイーサネット（登録商標）または８０２．３イー
サネット（登録商標）に適合するかどうかを決定する前に、この判定がおそらく
なされる。例示されたように、ジャンボフレームの判定は、パケットのサイズに
基づいてなされ得、このパケットはＩＰＰモジュール１０４またはＭＡＣモジュ
ールにより報告され得る。このパケットがジャンボフレームである場合、プロシ
ージャは状態４１０に続き得る。このパケットがジャンボフレームでない場合、
プロシージャは状態４１２で再開され得る。

【０１０２】 状態４１０において、プロシージャは、レイヤー２プロトコルがＬＬＣ ＳＮ
ＡＰカプセル化を有する８０２．３イーサネット（登録商標）であることを検証
する。特に、ポインタは（例えば、２バイト毎に）進み、レイヤー２ヘッダーの
長さフィールドに続く６バイト値が取り出され、検査される。ヘッダーが８０２
．３イーサネット（登録商標）ヘッダーである場合、フィールドはＬＬＣ＿ＳＮ
ＡＰフィールドあり、ＡＡＡＡ０３００００００（１６進数）の値を有さなけれ
ばならない。ＬＬＣ ＳＮＡＰヘッダーに関する最初の仕様が、ＩＥＥＥ ８０
２．２の仕様で見出され得る。パケットのＬＬＣ＿ＳＮＡＰフィールドの値が予
想した値と一致する場合、ポインタは、さらに６バイトだけインクリメントされ
、２バイトの８０２．３イーサネット（登録商標）タイプフィールドが読み出さ
れ、プロシージャは状態４１２で継続する。この値が一致しない場合、パケット
は特定のプロトコルと適合せず、プロシージャが状態４３０に入り、その後、終
了する。

【０１０３】 状態４１２において、ポインタは（例えば、さらに２バイト）進められ、それ
により、レイヤー３プロトコルヘッダーの先頭を位置付ける。このポインタの位
置は、このヘッダーの先頭を素早く識別する際に、後で使用するために保存され
得る。次いでパケットは、承認されたレイヤー２プロトコル（例えば従来のイー
サネット（登録商標）、ＶＬＡＮタグ付けを有するイーサネット（登録商標）、
またはＬＬＣ ＳＮＡＰを有する８０２．３イーサネット（登録商標））に適合
すると分かっており、次にパケットのレイヤー３プロトコルがＩＰであると保証
するするようにチェックされる。上記で議論されたように、例示された実施形態
において、ＩＰプロトコルに適合するパケットのみが、ヘッダーパーサにより広
範囲に処理される。

【０１０４】 例示するように、（状態４０２または状態４１０で取り出された）レイヤー２
ヘッダーのタイプフィールドの値が０８００（１６進数）である場合、レイヤー
３プロトコルは、バージョン４のＩＰだと予想される。この値が８６ＤＤ（１６
進数）である場合、レイヤー３プロトコルは、バージョン６のＩＰだと予想され
る。従って、タイプフィールドが状態４１２でテストされ、プロシージャは、こ
の１６進数値がそれぞれ０８００または８６ＤＤであるかどうかに依存して、状
態４１４または状態４１８で継続する。

【０１０５】 状態４１４において、バージョン４のＩＰとのレイヤー３ヘッダーの適合が検
証される。本発明の１つの実施形態において、レイヤー３ヘッダーのバージョン
フィールドは、バージョンフィールドが１６進数値の４（バージョン４のＩＰと
対応する）を含むことを保証するためにテストされる。状態４１４において、レ
イヤー３ヘッダーがＩＰバージョン４だと確認された場合、プロシージャは状態
４１６で継続する。レイヤー３ヘッダーがＩＰバージョン４だと確認されない場
合、プロシージャは状態４３０に進み、その後、状態４３２で終了する。

【０１０６】 状態４１６において、ＩＰヘッダーからの情報の種々の構成要素が保存される
。この情報は、ＩＨＬ（ＩＰヘッダー長）フィールド、合計長さフィールド、プ
ロトコルフィールドおよび／またはフラグメントオフセットフィールドを含む。
ＩＰソースアドレスおよびＩＰ宛先アドレスも格納され得る。このソースアドレ
ス値および宛先アドレス値は、バージョン４のＩＰ内でそれぞれ４バイト長であ
る。上記で説明されたように、これらのアドレスは、このパケットが送信された
通信フローを識別するフローキーを生成するために使用される。合計長さフィー
ルドは、このパケットのＩＰセグメントのサイズを格納し、このパケットは、Ｉ
Ｐヘッダー、ＴＣＰヘッダーおよびパケットのデータ部を例示的に含む。このパ
ケットのＴＣＰセグメントサイズ（例えば、ＴＣＰヘッダーサイズにパケットの
データ部のサイズを加えたサイズ）は、合計長さ値から２０バイト（ＩＰバージ
ョン４のヘッダーのサイズ）を差し引くことにより計算され得る。状態４１６の
後には、例示したプロシージャは状態４２２に進む。

【０１０７】 状態４１８において、バージョン６のＩＰとレイヤー３ヘッダーの適合が、１
６進数値の６のバージョンフィールドをテストすることにより検証される。バー
ジョンフィールドがこの値を含まない場合、例示したプロシージャは状態４３０
に進む。

【０１０８】 状態４２０において、ＩＰソースアドレスおよび宛先アドレスに加えて、ペイ
ロード長（例えば、ＴＣＰセグメントのサイズ）および次のヘッダーフィールド
の値が保存される。ソースアドレスおよび宛先アドレスは、バージョン６のＩＰ
内でそれぞれ１６バイト長である。

【０１０９】 例示したプロシージャの状態４２２において、レイヤー４ヘッダーがＴＣＰで
あることをＩＰヘッダー（バージョン４またはバージョン６）が示すかどうかが
判定される。例示したように、バージョン４のＩＰヘッダーのプロトコルフィー
ルドがテストされ、一方、バージョン６のヘッダーの次のフィールドがテストさ
れる。いずれの場合でも、この値は、６（１６進数）でなければならない。続い
て、ポインタは、必要に応じて（例えば、ＩＰバージョン４については２０バイ
ト、ＩＰバージョン６については４０バイト）インクリメントされ、それにより
、ＴＣＰヘッダーの先頭に到達する。状態４２２において、レイヤー４ヘッダー
がＴＣＰでないことが判定される場合、プロシージャは状態４３０に進み、終了
状態４３２で終了する。

【０１１０】 本発明の１つの実施形態において、バージョン４のＩＰヘッダーの他のフィー
ルドは、パケットがＮＩＣ１００により強化処理の基準を満たすことを保証する
ために、状態４２２でテストされ得る。例えば、５（１６進数）以外のＩＨＬフ
ィールド値は、ＩＰオプションがこのパケットについてセットされることを示し
、この場合において、構文解析オペレーションがアボートされる。０以外の細分
化フィールド値は、パケットのＩＰセグメントがフラグメントであることを示し
、この場合において、構文解析もアボートされる。いずれの場合も、プロシージ
ャは状態４３０にジャンプし、その後、終了状態４３２で終了する。

【０１１１】 状態４２４において、パケットのＴＣＰヘッダーは構文解析され、様々なデー
タがヘッダーから収集される。特に、ＴＣＰソースポート値および宛先ポート値
が保存される。複数のパケットからのデータを正しくリアセンブリすることを確
実にするのため用いられるＴＣＰシーケンス番号も保存される。さらに、Ｆｌａ
ｇｓフィールドのいくつかの構成要素の値（例示されたように、ＵＲＧ（緊急）
ビット、ＰＳＨ（プッシュ）ビット、ＲＳＴ（リセット）ビット、ＳＹＮ（同期
）ビットおよびＦＩＮ（終了）ビット）が保存される。本発明の１つの実施形態
において、これらのフラグは、実行されるべき種々のアクション、またはパケッ
トを処理する際に考慮されるべき状態を信号として送る。

【０１１２】 他の信号または状態は、状態４２４で生成され得、それにより、ＴＣＰヘッダ
ーから取り出された情報を反映する。例えば、チェックサムオペレーションが開
始するポイント（例示したように、ＴＣＰヘッダーの始まり）が保存され得、チ
ェックサムオペレーション終了ポイント（例示したように、パケットのデータ部
の終端）も保存され得る。パケットのデータ部のオフセットは、ＴＣＰヘッダー
のヘッダー長フィールドの値を４倍することによって識別され得る。続いて、デ
ータ部のサイズは、ＴＣＰセグメント全体のサイズからデータ部に対するオフセ
ットを差し引くことにより計算され得る。

【０１１３】 状態４２６において、フローキーは、ＩＰソースアドレスおよび宛先アドレス
、ならびにＴＣＰソースポートおよび宛先ポートを連結することによりアセンブ
ルされる。既に説明されたように、フローキーは、通信フローまたは通信接続を
識別するために使用されてもよいし、かつＮＩＣ１００の他のモジュールによっ
てより効果的にネットワークトラフィックを処理するために使用されてもよい。
ソースアドレスおよび宛先アドレスのサイズは、ＩＰバージョン４とＩＰバージ
ョン６の場合では異なる（例えば、ＩＰバージョン４では各４バイト、ＩＰバー
ジョン６では１６バイト）が、ここで記載された本発明の実施形態では、全ての
フローキーが同一サイズである。特に、この実施形態において、これらは、２バ
イトＴＣＰソースポートおよび２バイトＴＣＰ宛先ポートを含む３６バイト長で
ある。ＩＰ（パージョン４）パケットヘッダーから生成されたフローキーは、必
要に応じて（例えば、２４クリアバイト（ｃｌｅａｒ ｂｙｔｅｓ）で）パッデ
ィングされ、これにより、フローキーの割り当てられたスペースを満たす。

【０１１４】 状態４２８において、制御インジケータまたはステータスインジケータは、Ｎ
ＩＣ１００の１つ以上のモジュールに種々の情報を提供するためにアセンブルさ
れる。本発明の１つの実施形態において、制御インジケータは、パケットのＴＣ
Ｐシーケンス番号、パケットがデータを含むかどうか（例えば、ＴＣＰペイロー
ドサイズが０より大きいかどうか）を示すフラグまたは識別子（例えば、１つ以
上のビット）、パケットのデータ部が所定のサイズを超えるかどうかを示すフラ
グ、およびＴＣＰフラグフィールドのあるエントリが所定の値と等しいかどうか
を示すフラグを含む。例えば、後者のフラグは、Ｆｌａｇｓフィールドの構成要
素が特定の構造を有するまたは有さないことをＮＩＣ１００の別のモジュールに
知らせるために使用され得る。状態４２８の後、例示されたプロシージャは、状
態４３２で終了する。

【０１１５】 状態４３０には、例示されたプロシージャのいくつか異なるポイントで入るこ
とができる。例えば、ヘッダーパーサにより構文解析されるヘッダー部が上記で
識別された予め選択されたプロトコルスタックに適合しないことが判定された場
合、この状態に入る。結果として、上記で説明された多くの情報が取り出されな
い。この情報を取り出すことが不可能という実際の結果は、ＮＩＣ１００の他の
モジュールおよび本明細書に記載された強化処理に提供することができず、この
パケットに対して実行され得ないことである。特に、すでに説明されたように、
本発明のこの実施形態において、１つ以上の強化オペレーションは、パケットが
処理される効率を増すように、構文解析されたパケットに関して実行され得る。
適用され得る例示のオペレーションは、関連するパケット（例えば、単一データ
グラムからのデータを含むパケット）からのデータのリアセンブリ、プロトコル
スタックによるパケットヘッダーのバッチ処理、プロトコルスタック処理の負荷
分散または負荷共有、宛先エンティティへのパケットデータの効率的な伝送等を
含む。

【０１１６】 例示されたプロシージャにおいて、状態４３０ではフラグまたは（例示的に、
Ｎｏ＿Ａｓｓｉｓｔと称される）信号は、（例えば、ヘッダーパーサよってちょ
うど処理された）ＩＰＰモジュール１０４により現在保持されるパケットが、予
め決められたプロトコルスタックのいずれにも適合しないことを示すように、設
定されるか、またはクリアされる。このフラグまたは信号は、強化オペレーショ
ンの１つを実行するかどうかを決定する際に、ＮＩＣ１００の別のモジュールに
よって依存し得る。

【０１１７】 別のフラグまたは信号は、チェックサムオペレーションが実行された場合、そ
のオペレーションが（例えば、パケット内にオフセットを有さない）パケットの
先頭で開始すべきということを示すチェックサムパラメータを初期化するために
、状態４３０において、設定され得るか、またはクリアされ得る。例示したよう
に、互換性のないパケットは、チェックサムオペレーションを開始するより適切
なポイントを決定するために構文解析され得ない。状態４３０の後、プロシージ
ャは終了状態４３２で終了する。

【０１１８】 パケットを構文解析した後、ヘッダーパーサは、パケットからＮＩＣ１００の
１つ以上のモジュールに生成された情報を分散し得る。例えば、本発明の１つの
実施形態において、フローキーは、フローデータベースマネージャ１０８、ロー
ドディストリビュータ１１２、ならびに制御キュー１１８およびパケットキュー
１１６のどちらか一方またはその両方に提供される。例示されたように、制御イ
ンジケータは、フローデータベースマネージャ１０８に提供される。この制御情
報および他の制御情報（例えば、ＴＣＰペイロードサイズ、ＴＣＰペイロードオ
フセットおよびＮｏ＿Ａｓｓｉｓｔ信号）は、ＩＰＰモジュール１０４に戻され
得、かつ制御キュー１１８に提供され得る。なおさらなる制御情報および／また
は診断情報（レイヤー３ヘッダーおよび／またはレイヤー４ヘッダーに対するオ
フセット）は、ＩＰＰモジュール１０４、パケットキュー１１６および／または
制御キュー１１８に提供され得る。チェックサム情報（例えば、開始ポイント、
および終了ポイントまたはチェックサムを計算するパケット部を識別する他の手
段のどちらか一方）は、チェックサムジェネレータ１１４に提供され得る。

【０１１９】 受け取られたパケットが、ＮＩＣ１００で（例えば、ヘッダーパーサ１０６に
より）構文解析された後、そのパケットは、本発明の例示された実施形態におい
て、ホストコンピュータシステムで（例えば、それぞれのプロトコルスタックを
介して）なおも処理される。しかしながら、本発明の代替的な実施形態において
、パケットを構文解析した後、ＮＩＣ１００はまた、１つ以上の後に続く処理工
程を実行する。例えば、ＮＩＣ１００は、１つ以上のパケットのプロトコルヘッ
ダーを処理する１つ以上のプロトコルプロセッサを含み得る。

【０１２０】 （発明の１つの実施形態におけるダイナミックヘッダー構文解析命令） 本発明の１つの実施形態において、ヘッダーパーサ１０６は、命令のダイナミ
ックシーケンスに従って、ネットワークから受け取ったパケットを構文解析する
。この命令は、ヘッダーパーサの命令メモリ（例えば、ＲＡＭ、ＳＲＡＭ、ＤＲ
ＡＭ、フラッシュ）に格納され得、この命令メモリは、再プログラム可能である
か、またはそうでなければ、新規の命令または追加の命令で更新され得る。本発
明の１つの実施形態において、ホストコンピュータ（例えば、デバイスドライバ
）上で動作するソフトウェアは、ヘッダーパーサメモリに格納する一組の構文解
析命令をダウンロードし得る。

【０１２１】 ヘッダーパーサの命令メモリに格納された命令の数およびフォーマットは、１
つ以上の特定のプロトコルまたはプロトコルスタックに変更され得る。従って、
プロトコルを１つに収集するように構成された命令セット、またはその命令セッ
トから構成されたプログラムは、異なる命令セットまたはプログラムによって更
新され得るか、または置換され得る。選択されたプロトコルに従ってフォーマッ
トされるネットワークインターフェースで受け取られたパケット（例えば、「互
換性のある」パケット）について、パケットを解析するまたは構文解析すること
により判定される際、他の箇所で説明されるように、ネットワークトラフィック
の処理における種々の強化が可能となる。特に、選択されたプロトコルに従って
構成される１つのデータグラムからのパケットは、ホストコンピュータにおいて
効果的に伝送するようにリアセンブリされ得る。加えて、このようなパケットの
ヘッダー部は、連続的というよりもむしろ集合的に処理され得る。そして、マル
チプロセッサホストコンピュータによる異なるデータグラムからのパケットの処
理は、プロセッサ間で共有され得るか、または分散され得る。従って、ダイナミ
ックヘッダー構文解析オペレーションの１つの目的は、受け取ったパケットのフ
ォーマットに従って、パケットを識別すること、またはパケットヘッダーが特定
のプロトコルに適合するかどうかを判定することである。

【０１２２】 手短に詳細に議論された図８は、ヘッダーがそれぞれ、イーサネット（登録商
標）、ＩＰ、ＴＣＰであるかどうかを判定するパケットのレイヤー２、３、およ
び４のヘッダーを構文解析する例示的な一連の命令を示す。例示された命令は、
構文解析オペレーションを実行する１つの可能なプログラムまたはマイクロコー
ドを含む。当業者に認識されるように、構文解析命令の特定の組がパーサメモリ
にロードされた後、多くの異なるプログラムがアセンブルされ得る。従って、図
８は、格納された命令から生成され得る多数のプログラムのうちのただ１つのみ
を示す。図８に示される命令は、マイクロシーケンサ、プロセッサ、マイクロプ
ロセッサまたはネットワークインターフェース回路内に配置されるその他の同様
なモジュールにより実行され得るか、または動作され得る。

【０１２３】 特に、他の命令セットおよび他のプログラムは、異なる通信プロトコルに対し
て得られ得、かつプロトコルスタックの他のレイヤーに強化され得る。例えば、
一組の命令は、ＮＦＳ（ネットワークファイルシステム）パケットを構文解析す
るために生成され得る。例示されたように、これらの命令は、ヘッダーがそれぞ
れ、リモートプロシージャコール（ＲＰＣ）および外部データ表示（ＸＤＲ）で
あるかどうかを判定するレイヤー５ヘッダーおよびレイヤー６プロトコルヘッダ
ーを構文解析するように構成され得る。他の命令は、（レイヤー７と考えられ得
る）パケットのデータ部を構文解析するように構成され得る。ＮＦＳヘッダーは
、パケットのレイヤー６プロトコルヘッダーの一部またはパケットのデータの一
部と考えられ得る。

【０１２４】 マイクロシーケンサによって実行される命令の１つのタイプは、（例えば、パ
ケット内の特定のオフセットで）パケットの特定のフィールドを位置付けるよう
に設計され得、かつそのオフセットで格納された値と特定の通信プロトコルのそ
のフィールドに関連する値とを比較し得る。例えば、１つの命令は、イーサネッ
ト（登録商標）ヘッダーのタイプフィールドに対応するオフセットでのパケット
ヘッダーの値を検査するためのマイクロプロセッサを必要とし得る。パケットに
実際に格納された値とプロトコルについて予測された値を比較することにより、
マイクロシーケンサは、パケットがイーサネット（登録商標）プロトコルに適合
するかどうかを判定し得る。例示されたように、構文解析プログラムにおいて適
用された次の命令は、以前の比較が成功したかどうかに依存する。従って、マイ
クロシーケンサによって適用された特定の命令および適用されたシーケンスは、
どのプロトコルがパケットヘッダーによって示されるかに依存する。

【０１２５】 マイクロシーケンサは、パケットに含まれる各ヘッダー内の１つ以上のフィー
ルド値をテストし得る。テストされかつ既知のプロトコルのフォーマットと適合
すると分かったフィールドが増せば増すほど、パケットがそのプロトコルと適合
するという確実性は大きくなる。当業者に理解されるように、１つの通信プロト
コルは別のプロトコルと全く異なり得るので、そのため、異なるプロトコルにつ
いてのパケットヘッダーの異なる部分の検査が必要となる。例示されたように、
１つのパケットを構文解析することにより、エラーが発生する場合、または構文
解析されるパケットが命令が指定されるプロトコル（単数または複数）と適合す
るか否かを判定するため終了し得る。

【０１２６】 図８の各命令は、番号および／または名前によって識別され得る。特定の命令
は、ヘッダーフィールドを期待値と比較する以外に、種々のタスクを実行するこ
とができる。例えば、命令は、他の命令を呼び出して、パケットヘッダーの他の
部分の調査、レジスタまたは他のデータ構造を初期化、ロード、またはアセンブ
ル、他のパケットの到着および構文解析の準備等をすることができる。特に、レ
ジスタまたは他の格納構造は、パケットが構文解析された後で、ネットワークイ
ンターフェースにおいて実行されるオペレーションを予想して構成され得る。例
えば、図８のプログラム命令は、パケットから抽出された値と期待値との比較の
成功または失敗に応じて、行われてもよいし、または行われなくてもよい出力オ
ペレーションを識別することができる。出力オペレーションは、レジスタに値を
格納し、構文解析後のオペレーション用にレジスタを構成し（例えば引数または
オペレータをロードする）、新たなパケットを待つようにレジスタをクリアにす
る等し得る。

【０１２７】 ポインタは、オフセットを識別してパケットを構文解析させるために利用され
得る。１実施形態においてこのようなポインタは、最初に、レイヤー２のプロト
コルヘッダーの先頭に位置される。しかしながら別の実施形態では、構文解析が
開始する場合、ポインタは特定のヘッダー内の特定の位置（例えば、直後のレイ
ヤー２の宛先および／またはソースアドレス）に位置付けられる。例示的、ポイ
ンタは、構文解析プロシージャが実行されるにしたがって、パケットによってイ
ンクリメントされる。しかしながら、別の１実施形態において、パケットの対象
となる領域へのオフセットは、１以上の既知または計算された位置から計算され
得る。

【０１２８】 図８に示される構文解析プログラムでは、ヘッダーは、２バイト（例えば１６
ビットワード）ずつインクリメントして進められる（例えばポインタが進められ
る）。さらに、ヘッダーの特定のフィールドが、既知の値または期待値と比較さ
れる場合、そのフィールドから２バイトまでが同時に抽出される。さらに、値ま
たはヘッダーフィールドが、レジスタまたは他のデータ構造に格納するためにコ
ピーされる場合には、１つのオペレーションでコピーされ得るデータ量は、複数
の２バイト単位または完全に他の単位（例えば個々のバイト）として表され得る
。本発明の別の実施形態では、この大きさの単位（例えば２バイト）を大きくし
てもよいし、または小さくしてもよい。大きさの単位を変更することによって、
その単位を用いてヘッダーが構文解析され得るか、またはヘッダー値が抽出され
得る精度を変更することができる。

【０１２９】 図８に示す本発明の実施形態において、ヘッダーパーサの命令メモリにロード
される命令のセットは、選択されたプロトコルとの互換性についてパケットをテ
ストする一方で、複数の実行可能なオペレーションを含む。プログラム８００は
、命令セットから生成される。従って、プログラム８００は、利用可能な命令セ
ットから生成され得る、単なる１つの可能なプログラム、マイクロコード、また
は命令シーケンスにすぎない。

【０１３０】 本実施形態において、ロードされた命令セットによって、構文解析されている
パケット上で実行され得る次の１６のオペレーションをイネーブルする。プログ
ラム８００におけるこれらのオペレーションの特定のインプリメンテーションは
、以下でさらに詳細に議論される。これらの命令は、本質的には例示目的である
と理解され、本発明の他の実施形態における命令の構成を制限しない。さらに、
これらのオペレーションの任意のサブセットが、特定の構文解析プログラムまた
はマイクロコードで利用され得る。さらに、複数の命令が、同じオペレーション
を利用して、異なる効果を達成することができる。

【０１３１】 ＣＬＲ＿ＲＥＧオペレーションは、プログラム８００で用いられるレジスタま
たは他のデータ構造、可能な場合にはパケットを構文解析した後に実行される機
能で用いられるデータ構造の選択的な初期化を可能にする。初期化は、値０を格
納する工程を含み得る。ＣＬＲ＿ＲＥＧオペレーションによって初期化され得る
複数の例示的なレジスタは、残りのオペレーションにおいて識別される。

【０１３２】 ＬＤ＿ＦＩＤオペレーションは、パケット内の特定のオフセットからパケット
のフローキーまたは他のフロー識別子を格納するように構成されたレジスタへと
データ量を可変にしてコピーする。このレジスタは、ＦＬＯＷＩＤレジスタと呼
ばれ得る。ＬＤ＿ＦＩＤオペレーションの効果は、累積型である。すなわち、１
つのパケットについて呼び出されるたびに、生成されたデータは、予め格納され
たフローキーデータにアペンドされる。

【０１３３】 ＬＤ＿ＳＥＱオペレーションは、パケットの内の特定のオフセットからパケッ
トのシーケンス番号（例えばＴＣＰシーケンス番号）を格納するように構成され
たレジスタへとデータ量を可変にしてコピーする。このレジスタは、ラベルＳＥ
ＱＮＯを割り当てられ得る。このオペレーションもまた累積型である―そのパケ
ットについてのこのオペレーションの第２の呼び出し、そしてそれに続く呼び出
しによって、識別されたデータは予め格納されたデータにアペンドされる。

【０１３４】 ＬＤ＿ＣＴＬオペレーションは、パケット内の特定のオフセットからＣＯＮＴ
ＲＯＬレジスタ内へ値をロードする。ＣＯＮＴＲＯＬレジスタは、パケットがデ
ータリアセンブリ、パケットバッチング、負荷分散、またはＮＩＣ１００の他の
機能強化した機能に適切であるかどうかを識別するために、制御インジケータを
含み得る。特に、制御インジケータは、Ｎｏ＿Ａｓｓｉｓｔフラグがパケットを
引き上げるべきかどうか、パケットが任意のデータを含むかどうか、パケットの
データ量が所定の閾値より多いかどうか等を示し得る。従って、ＬＤ＿ＣＴＬオ
ペレーションにおいてＣＯＮＴＲＯＬレジスタにロードされた値は、パケットの
構文解析後の処理に影響し得る。

【０１３５】 ＬＤ＿ＳＡＰオペレーションは、パケットの内の可変オフセットからＣＯＮＴ
ＲＯＬレジスタ内へ値をロードする。ロードされた値は、パケットのイーサタイ
プ（ｅｔｈｅｒｔｙｐｅ）を含み得る。ＬＤ＿ＳＡＰオペレーションに関連付け
られ得る１つのオプションとして、パケットのレイヤー３のヘッダーのオフセッ
トはまた、ＣＯＮＴＲＯＬレジスタまたは他のどこかに格納され得る。当業者で
あれば認識するように、パケットがイーサネット（登録商標）およびＩＰプロト
コルに適合する場合、パケットのレイヤー３のヘッダーは、レイヤー２のイーサ
タイプのフィールドに直ちに続き得る。

【０１３６】 ＬＤ＿Ｒ１オペレーションは、パケット内の可変オフセットから（例えばＲ１
と称される）一時レジスタ内へ値をロードするために用いられ得る。一時レジス
タは、ヘッダーまたはパケットの他の部分の長さを判定するために値を累積する
等の種々のタスクに用いられ得る。ＬＤ＿Ｒ１オペレーションはまた、他の可変
オフセットからの値を（例えばＲ２と称される）第２の一時レジスタに格納させ
得る。パケットの構文解析中に、Ｒ１レジスタおよび／またはＲ２レジスタに格
納された値は、累積型であってもよいし、または累積型でなくてもよい。

【０１３７】 ＬＤ＿Ｌ３オペレーションは、パケットからパケットのレイヤー３のヘッダー
の位置を格納するように構成されたレジスタに値をロードし得る。このレジスタ
は、Ｌ３ＯＦＦＳＥＴと称され得る。このオペレーションを呼び出す１方法とし
て、固定値をL３ＯＦＦＳＥＴレジスタへロードすることが用いられ得る。別の
オプションとしてＬＤ＿Ｌ３オペレーションが、一時レジスタ（例えばＲ１）に
格納された値をＬ３ＯＦＦＳＥＴレジスタに格納されている値に付加することが
できる。

【０１３８】 ＬＤ＿ＳＵＭオペレーションは、チェックサムが計算される必要がある開始位
置をパケット内に格納する。この値が格納されたレジスタは、ＣＳＵＭＳＴＡＲ
Ｔレジスタと称され得る。このオペレーションの別の１呼び出しにおいて、固定
値または所定値がレジスタに格納される。別のオプションとして、ＬＤ＿ＳＵＭ
オペレーションは、一時レジスタ（例えばＲ１）に格納された値をＣＳＵＭＳＴ
ＡＲＴレジスタに格納されている値に付加することができる。

【０１３９】 ＬＤ＿ＨＤＲオペレーションは、ヘッダー部が分割され得るパケット内の位置
を格納するように構成されたレジスタに値をロードする。格納される値は、例え
ば、パケットのホストコンピュータへの伝送中に、ヘッダー部以外に別の位置に
パケットのデータ部を格納するために用いられ得る。従って、ロードされた値は
パケットデータの先頭または特定のヘッダーの先頭を識別することができる。Ｌ
Ｄ＿ＨＤＲオペレーションのある呼び出しで、格納された値は、上述の構文解析
ポインタの現在の位置から計算され得る。別の呼び出しでは、固定値または所定
値が格納され得る。さらに別の代替例として、一時レジスタ（例えばＲ１）に格
納された値および/または定数が、ロードされた値に付加され得る。

【０１４０】 ＬＤ＿ＬＥＮオペレーションは、レジスタ（例えばＰＡＹＬＯＡＤＬＥＮレジ
スタ）にパケットのペイロード長を格納する。

【０１４１】 ＩＭ＿ＦＩＤオペレーションは、固定値または所定値を上述のＦＬＯＷＩＤレ
ジスタの既存のコンテンツにアペンドするか、または付加する。

【０１４２】 ＩＭ＿ＳＥＱオペレーションは、固定値または所定値を上述のＳＥＱＮＯレジ
スタのコンテンツにアペンドするか、または付加する。

【０１４３】 ＩＭ＿ＳＡＰオペレーションは、固定値または所定値を上述のＣＳＵＭＳＴＡ
ＲＴレジスタにロードするか、または格納する。

【０１４４】 ＩＭ＿Ｒ１オペレーションは、所定値を１つ以上の一時レジスタ（例えばＲ１
、Ｒ２）に付加し得るか、またはアペンド得る。

【０１４５】 ＩＭ＿ＣＴＬオペレーションは、固定値または所定値を上述のＣＯＮＴＲＯＬ
レジスタにロードするか、または格納する。

【０１４６】 ＳＴ＿ＦＬＡＧオペレーションは、パケット内の特定のオフセットからＦＬＡ
ＧＳレジスタに値をロードする。ロードされた値は、パケットヘッダーからの１
つ以上のフィールドまたはフラグを含み得る。

【０１４７】 当業者であれば、オペレーションおよび本セクションにおいて上述したレジス
タならびにその他に割り当てられるラベルは、本質的には単なる例示にすぎず、
本発明の他の実施形態で利用され得るオペレーションおよび構文解析命令を何ら
制限しないということを理解する。

【０１４８】 プログラム８００における命令は、プログラム内に複数の命令を含む命令番号
フィールド８０２、および命令の名前を含む命令名フィールド８０４を含む。本
発明の別の実施形態において、命令番号フィールドおよび命令名フィールドは、
マージされてもよいし、またはそれらのうちの一方を省いてもよい。

【０１４９】 命令コンテンツフィールド８０６は、命令を実行するための複数の部分を含む
。命令の「抽出マスク」部は、１６進法の２バイトマスクである。抽出マスクは
、現在のパケットオフセット（例えば、構文解析ポインタの現在の位置）から開
始する際に、コピーまたは抽出されるパケットヘッダー部を識別する。例示的に
、１６進法の値のうちの１つに対応するパケットのヘッダーの各ビットは、比較
値またはテスト値と比較するためにコピーされる。例えば、命令の抽出マスク部
における０ｘＦＦ００値は、現在のパケットオプセットの第１のバイト全体をコ
ピーして、第２のバイトのコンテンツが関係ないことを示す。同様に０ｘ３ＦＦ
Ｆの抽出マスクは、第１のバイトの２つの最上位ビットを除く全てがコピーされ
るということを示す。２バイト値は、パケットからコピーされるものは何でも用
いて、抽出されたコンテンツから構成される。例示的に、値の残りが０でパディ
ングされる。当業者であれば、抽出マスク（または以下で述べる出力マスク）の
フォーマットは、必要に応じて、小さなエンディアン（ｅｎｄｉａｎ）または大
きなエンディアン表示を反映するように準備され得ることを理解する。

【０１５０】 構文解析プログラムにおける１つ以上の命令は、出力オペレーションを行うこ
とができるように、ポインタ位置でパケットから抽出される任意のデータを必要
とし得ない。これらの命令は、０ｘ００００の抽出マスク値を有し、それにより
２バイト値がやはりポインタ位置から取り出されるが、全てのビット値がマスキ
ングによって除去されるということを示し得る。従って、このような抽出マスク
は、０の一定値を生成する。このタイプの命令は、例えば、ヘッダーデータの他
の実質的な部分が０ｘ００００以外の抽出マスクで抽出される前に、出力オペレ
ーションが行われる必要がある場合に用いられ得る。

【０１５１】 命令の「比較値」部は、２バイトの１６進数値であり、この値を用いて抽出さ
れたパケットのコンテンツが比較される。比較値は、特定のプロトコルヘッダー
の特定のフィールドに格納されることが分かっている値であり得る。比較値は、
ヘッダーの抽出部が一致する必要があるか、または特定の関係にある値を含み、
それによりパケットが予め選択されたプロトコルと互換性があるとみなされ得る
。

【０１５２】 命令の「オペレータ」部は、どのように抽出したか、そして比較値がどのよう
に比較されるかを示すオペレータを識別する。例示的に、ＥＱは、等式でテスト
されることを示し、ＮＥは不等式でテストされることを示し、ＬＴは、比較がう
まくいくためには抽出された値が比較値よりも小さくある必要があるということ
を示し、ＧＥは、抽出された値が、比較値より大きいか、または等しくある必要
があるということを示す等である。構文解析される新たなパケットの到着を待つ
命令は、ＮＰオペレーションを利用し得る。他の機能の他のオペレータを付加す
ることができ、既存のオペレータに他の名前を割り当てることができる。

【０１５３】 命令の「成功オフセット」部は、抽出された値とテスト値との間の比較が成功
した場合に、ポインタが進む２バイト単位数を示す。命令の「成功命令」部は、
比較がうまくいった場合に実行するために、プログラム８００内の次の命令を識
別する。

【０１５４】 同様に、「失敗オフセット」部および「失敗命令」部は、比較がうまくいかな
かった場合に、それぞれ、ポインタを進めるための２バイト単位数および実行す
るための次の命令を示す。本発明の本実施形態において、オフセットは、２バイ
ト単位（例えば１６ビットワード）で表されるが、本発明の別の実施形態におい
て、それらオフセットはより小さな単位であってもよいし、またはより大きな単
位であってもよい。さらに、上述したように、命令は番号または名前によって識
別されてもよい。

【０１５５】 プログラム内の必ずしも全ての命令が、構文解析される各パケットに対して用
いられる必要はない。例えば、プログラムは、特定の層のプロトコルの１つより
多くのタイプまたはプロトコルのバージョンについてテストを行う命令を含み得
る。特に、プログラム８００は、レイヤー３のＩＰプロトコルのバージョン４ま
たはバージョン６のいずれかについてテストする。従って、所与のパケットにつ
いて実際に実行される命令は、パケットのフォーマットに依存する。パケットが
所与のプログラムによって可能な限り多く構文解析されると、またはパケットが
選択されたプロトコルに適合するかどうかが判定されると、構文解析を停止し得
るか、または構文解析プロシージャを停止する命令が実効され得る。例示的に、
値「ＤＯＮＥ」を有する命令の次の命令部（例えば「成功命令」または「失敗命
令」）は、パケットの構文解析の完了を示す。ＤＯＮＥまたは同様の命令は、ダ
ミー命令であり得る。すなわち、「ＤＯＮＥ」は、単に、現在のパケットについ
て構文解析を停止させることを示し得る。または、プログラム８００の命令１８
のように、ＤＯＮＥ命令は、新たなパケットを待つように（例えばレジスタを初
期化することによって）何らかのアクションをとることができる。

【０１５６】 命令コンテンツフィールド８０６の残りの部分は、出力または他のデータ格納
オペレーションを特定し、完了するために用いられる。特に、本実施形態におい
て、命令の「出力オペレーション」部は、ロードされた命令セットに含まれる命
令に対応する。従って、プログラム８００の場合、命令の出力命令部は、上述の
１６のオペレーションのうちの１つを識別する。プログラム８００で利用される
出力オペレーションについては、個々の命令とともに以下でさらに説明する。

【０１５７】 命令の「オペレーション引数」部は、格納され、ロードされ、そうでない場合
には命令の出力オペレーションとともに用いられる１つ以上の引数またはフィー
ルドを含む。例示的に、オペレーション引数部は、マルチビット１６進数値の形
式をとる。プログラム８００の場合、オペレーション引数のサイズは１１ビット
である。引数または引数の一部は、出力オペレーションに応じて種々の意味を有
し得る。例えば、オペレーション引数は、レジスタに格納されるか、またはヘッ
ダー部を見つけるまたは定めるために用いられる１つ以上の数値を含み得る。あ
るいは、引数ビットは、アクションまたは状態を信号で送るためのフラグを含み
得る。特に、１つの引数ビットは、特定のレジスタがリセットされる、引数ビッ
トのセットが、レジスタに格納される値に対するオフセットをパケットヘッダー
内に含み得る等を特定し得る。例示的に、オペレーション引数によって特定され
たオフセットが、適用可能な成功オフセットまたは失敗オフセットによってポイ
ンタを特定し、そのポインタを進める前に、構文解析を行うポインタ位置を位置
付けるために適用される。プログラム８００で用いられるオペレーション引数は
以下でさらに詳細に説明される。

【０１５８】 命令コンテンツフィールドの「オペレーションイネーブラ」部は、命令の出力
オペレーションが実行されるかどうか、またはいつ実行されるかを特定する。特
に、本発明の例示的な実施形態において、命令の出力オペレーションは、ヘッダ
ーから抽出された値と比較値との間の比較結果に応じて、実行されてもよいし、
または実行されなくてもよい。例えば、出力イネーブラは、出力オペレーション
が全く実行されない場合に、第１の値（例えば０）に設定され得る。比較がオペ
レータを満たす場合にのみ実行される際には、出力イネーブラは異なる値（例え
ば１）を取ることができ、また比較がオペレータを満たさない場合にのみ実行わ
される際には、出力イネーブラは異なる値（例えば２）を取ることができる。常
に実行される際には、オペレーションイネーブラは、さらに別の値（例えば３）
をとることができる。

【０１５９】 命令の「シフト」部は、出力値がどれだけシフトすべきかを示す値を含む。異
なるプロトコルは、異なってフォーマットされる値を近いうちに必要とするので
、シフトが必要であり得る。さらに、ヘッダーまたはヘッダーフィールドの長さ
あるいは位置を示す値は、その値が表す適切な大きなを反映するために、シフト
を必要とし得る。例えば、プログラム８００は、２バイト単位を用いて設計され
るので、他の単位（例えばバイト）を反映する場合には、値をシフトする必要が
あるかもしれない。本実施形態におけるシフト値は、出力値を右へシフトさせる
位置数（例えばビット）を示す。本発明の別の実施形態において、シフト値は、
異なるシフトタイプまたは方向を表し得る。

【０１６０】 最後に、「出力マスク」は、レジスタまたは他のデータ構造に格納されている
値がどのようにフォーマットされるべきかを特定する。上述のように、出力オペ
レーションは、抽出され、計算され、または格納されるようにアセンブルされた
値を必要とし得る。抽出マスクと同様に、出力マスクは２バイト１６進数値であ
る。本発明の本実施形態において、１を含む出力マスクのすべての位置について
、出力オペレーションおよび/またはオペレーション引数によって識別される、
２バイト値における対応するビットが格納される。例えば、０ｘＦＦＦＦ値は、
特定される２バイト値がそのまま格納されるということを示す。例示的に、０を
含む出力マスクにおけるすべての位置について、０が格納される。従って、０ｘ
Ｆ０００値は、第１のバイトの最上位４ビット格納されるが、格納された値の残
りは関係なく、０でパディングされてもよいということを示す。

【０１６１】 「ＮＯＮＥ」の出力オペレーションは、実行されるかまたは格納される出力オ
ペレーションがないことを示すために用いられ得る。この場合、出力に関係する
他の命令部は無視されてもよいし、または特定の値（例えばすべて０）を含んで
もよい。しかしながら図８に示されるプログラムでは、レジスタの選択的な再初
期化を可能にするＣＬＲ＿ＲＥＧ出力オペレーションを、オペレーション引数０
とともに用いて、効果的な出力を実行することはできない。特に、ＣＬＲ＿ＲＥ
Ｇオペレーションのオペレーション引数０は、リセットされるレジスタがないこ
とを示す。本発明の別の実施形態において、命令のオペレーションイネーブラ部
が、出力オペレーションが全く実行されないことを示す値（例えば０）に設定さ
れ得る。

【０１６２】 図８の命令のフォーマットおよびシーケンスは、パケットを構文解析してパケ
ットが特定の通信プロトコルに適合しているかどうかを判定する単なる１つの手
段を表すにすぎないことが理解される。特に、命令は、既知の値または期待値と
比較するために、１つ以上のパケットの１つ以上のヘッダー部を検査し、必要に
応じて、レジスタまたは他の格納位置を構成またはロードするように設計される
。当業者であれば、パケットを構文解析する命令は、多数の形式のうちの任意の
形式を取り得、本発明の範囲を逸脱することなく、様々なシーケンスで実行され
得ることを理解する。

【０１６３】 図８を参照して、プログラム８００の命令を詳細に説明し得る。図８に示され
るプログラムを実行する前に、構文解析ポインタが、レイヤー２のヘッダーの先
頭に置かれる。構文解析ポインタの位置は、構文解析プロシージャ時に容易に参
照し、更新するためにレジスタに格納され得る。特に、（例えば、レイヤー２の
ヘッダーの先頭からの）オフセットとしての構文解析ポインタの位置は、ヘッダ
ー内の特定の位置の位置を計算する際に使用され得る。

【０１６４】 プログラム８００は、ＷＡＩＴ命令（例えば、命令０）で始まる。そのＷＡＩ
Ｔ命令は、（例えば、オペレータＮＰで示される）新しいパケットを待ち、パケ
ットが受け取られると、構文解析ポインタをレイヤー２のヘッダーの１２バイト
に設定する。この１２バイトのオフセットは、命令の成功オフセット部によって
示される。パケットが受け取られるまで、ＷＡＩＴ命令は、それ自身上でループ
する。さらに、ＣＬＲ＿ＲＥＧオペレーションが実行されるが、ＣＬＲ＿ＲＥＧ
オペレーションイネーブラ設定は、比較が成功する場合（例えば、新しいパケッ
トが受け取られる場合のみ、そのＣＬＲ＿ＲＥＧオペレーションが実行されるこ
とを示す。

【０１６５】 特定のＣＬＲ＿ＲＥＧオペレーションは、ＷＡＩＴ命令のオペレーション引数
（すなわち、０ｘ３ＦＦ）に従って、動作する。この実施形態において、引数の
各ビットは、レジスタまたは他のデータ構造に対応する。このオペレーションに
おいて初期化されるレジスタは、以下のことを含み得る：ＡＤＤＲ（例えば、構
文解析アドレスポインタまたは位置を格納する）、ＦＬＯＷＩＤ（例えば、パケ
ットのフローキーを格納する）、ＳＥＱＮＯ（例えば、ＴＣＰシーケンス番号を
格納する）、ＳＡＰ（例えば、パケットイーサタイプ）およびＰＡＹＬＯＡＤＬ
ＥＮ（例えば、ペイロード長）。一定のオフセットを格納するように構成される
次のレジスタがまた、再設定され得る。このようなレジスタには、ＦＬＯＷＯＦ
Ｆ（例えば、ＦＬＯＷＩＤレジスタ内のオフセット）、ＳＥＱＯＦＦ（例えば、
ＳＥＱＮＯレジスタ内のオフセット）、Ｌ３ＯＦＦＳＥＴ（例えば、パケットの
レイヤー３のヘッダーのオフセット）、ＨＤＲＳＰＬＩＴ（例えば、パケットを
分離するための位置）およびＣＳＵＭＳＴＡＲＴ（例えば、チェックサムを計算
する開始位置）が挙げられる。また、パケットの１つ以上のフラグの状態を報告
する１つ以上の状態または制御インジケータ（例えば、ＣＯＮＴＲＯＬまたはＦ
ＬＡＧＳレジスタ）が再設定され得る。さらには、１つ以上の一時レジスタ（例
えば、Ｒ１、Ｒ２）または他のデータ構造もまた、初期化され得る。上記のレジ
スタは、本発明の１実施形態に用いられ得るデータ構造について示しているに過
ぎない。他のデータ構造は、同じまたは異なる出力オペレーションについて他の
実施形態で用いることができる。

【０１６６】 Ｒ１および／またはＲ２等の一時レジスタは、様々なヘッダーおよびヘッダー
フィールドを追跡するために、プログラム８００で用いられ得る。当業者は、通
信プロトコルの可能な組み合せの数およびパケットヘッダーの構造およびフォー
マットにおける通信プロトコルの様々な組み合せの効果を認識する。別のプロト
コルまたはプロトコルのセットに適合するパケットから以外にも１つのプロトコ
ルまたはプロトコルのセットに適合するパケットから、さらなる情報が検査され
、集められる必要があり得る。例えば、拡張ヘッダーが、インターネットプロト
コルヘッダーで用いられる場合、それらの拡張ヘッダーおよび／またはその長さ
から得られる値を格納する必要があり得、拡張ヘッダーが用いられない場合、そ
の値は必要とされない。例えばパケットデータ部の先頭に対するオフセット等の
特定のオフセットを計算する場合、複数のレジスタを維持する必要があり得、そ
れらの値は組み合わされるかまたは加えられる。この例では、一方のレジスタま
たは一時レジスタは拡張ヘッダーのサイズまたはフォーマットを追跡し得、他方
のレジスタはベースＩＰヘッダーを追跡する。

【０１６７】 命令ＶＬＡＮ（例えば、命令１）は、ＶＬＡＮタグ（ｔａｇｇｅｄ）ヘッダー
（例えば、１６進数での８１００）を示す値について、構文解析ポインタ位置（
おそらく、タイプ、長さまたはＴＰＩＤフィールド）にある２バイトフィールド
を検査する。ヘッダーが、ＶＬＡＮタグである場合、ポインタは、数バイト（例
えば、１つの２バイト単位）でインクリメントされ、命令ＣＦＩを実行し続ける
；ヘッダーがＶＬＡＮタグでない場合、命令８０２．３を実行し続ける。いずれ
のイベントでも、命令のオペレーションイネーブラは、ＩＭ＿ＣＴＬオペレーシ
ョンが常に実行されることになることを示す。

【０１６８】 上述されたように、ＩＭ＿ＣＴＬオペレーションにより、制御レジスタまたは
他のデータ構造が１つ以上のフラグでポピュレートされ、パケットの状態または
状況を報告する。前セクションで説明されているように、制御インジケータは、
パケットが強化処理に適切であるかどうか（例えば、パケットのためにＮｏ＿Ａ
ｓｓｉｓｔ信号が生成されるかどうか）、パケットが任意のデータを含むかどう
か、そうである場合、データ部のサイズは特定の閾値を超えるかどうかを示し得
る。命令ＶＬＡＮに用いるオペレーション引数０ｘ００Ａは、制御レジスタに格
納される値を含み、引数の個々のビットは特定のフラグに対応する。例示的に、
上述の条件に関連するフラグは、このＩＭ＿ＣＴＬオペレーションでは、１また
は真に設定され得る。

【０１６９】 命令ＣＦＩ（例えば、命令２）は、レイヤー２のヘッダーの、ＣＦＩビットま
たはフラグを検査する。ＣＦＩビットが設定される場合、パケットは、本発明の
本実施形態の処理強化に適切でなく、構文解析プロシージャは、命令ＤＯＮＥ（
例えば、命令１８）を呼び出すことによって終了する。ＣＦＩビットが設定され
ていない場合、ポインタは、別の数バイト分インクリメントされ、命令８０２．
３が実行し続ける。上述のように、ヌル出力オペレーション（例えば、「ＮＯＮ
Ｅ」）は、実行される出力オペレーションがないことを示す。さらには、その出
力イネーブラ値（例えば、０）は、出力オペレーションが実行されないことをさ
らに確実にする。

【０１７０】 命令８０２．３（例えば、命令３）で（パケットのポインタの位置およびフォ
ーマットに依存する）タイプまたは長さフィールドを調べて、パケットレイヤー
２のフォーマットが従来のイーサネット（登録商標）または８０２．３イーサネ
ット（登録商標）であるかどうかを判定する。ヘッダーフィールドの値が８０２
．３イーサネット（登録商標）を示す（例えば、０６００未満の１６進法の値を
含む）ような場合、ポインタは（ＬＬＣＳ ＮＡＰフィールドであるべき値まで
）２バイト分インクリメントされ、命令ＬＬＣ＿１が実行され続ける。そうでな
い場合、レイヤー２のプロトコルは従来のイーサネット（登録商標）とみなされ
得、命令ＩＰＶ４＿１が実行され続ける。本発明のこの実施形態において命令８
０２．３は、出力オペレーションを含まない。

【０１７１】 命令ＬＬＣ＿１およびＬＬＣ＿２（例えば、命令４および５）では、疑わしい
レイヤー２のＬＬＣ ＳＮＡＰフィールドは検査され、パケットが８０２．３イ
ーサネット（登録商標）プロトコルに適合することを確実にする。命令ＬＬＣ＿
１において、フィールドの第１の部分はテストされ、このテストが成功である場
合、ポインタは２バイト分インクリメントされ、命令ＬＬＣ＿２において、第２
部がテストされる。命令ＬＬＣ＿２が成功である場合、構文解析ポインタは４バ
イト分増加し、タイプフィールドになるべき値に到達し、命令ＩＰＶ４＿１が実
行され続ける。しかし、いずれのテストが失敗しても、構文解析プロシージャは
終了する。本発明の図示される実施形態において、ＬＬＣ ＳＮＡＰフィールド
をテストしながら実行される出力オペレーションはない。

【０１７２】 命令ＩＰＶ４＿１（例えば、６）において、構文解析ポインタは、イーサネッ
ト（登録商標）タイプフィールドにあるべきである。このフィールドは検査され
、レイヤー３のプロトコルはインターネットプロトコルのバージョン４に対応す
るかどうかを判定する。このテストが成功である（例えば、タイプフィールドが
１６進法で０８００の値を含む）場合、ポインタは、レイヤー３のヘッダーの先
頭まで２バイト分進み、プログラム８００の実行は命令ＩＰＶ４＿２に続く。テ
ストが失敗である場合、命令ＩＰＶ６＿１が実行され続ける。テスト結果に関わ
らず、オペレーションイネーブラの値（例えば、３）は特定のＬＤ＿ＳＡＰ出力
オペレーションが常に実行されることを示す。

【０１７３】 上述したように、ＬＤ＿ＳＡＰオペレーションにおいて、パケットのイーサタ
イプ（またはサービスアクセスポイント）はレジスタに格納される。オペレーシ
ョン引数０ｘ１００の一部、特に最右の６ビット（例えば、０）は、イーサタイ
プを含む２バイトの値へのオフセットを構成する。本コンテクストでは、構文解
析ポインタが既にタイプフィールドにあり、イーサタイプを含むので、この例の
オフセットは０である。ここで説明される実施形態において、オペレーション引
数の残りは、レイヤー３のヘッダーの開始位置（例えば、パケットの先頭からの
オフセット）もまた、（例えば、Ｌ３ＯＦＦＳＥＴレジスタに）保存されること
を示すフラグを構成する。特に、レイヤー３のヘッダーの先頭は、２バイトタイ
プフィールドのすぐ後に位置することが分かっている。

【０１７４】 命令ＩＰＶ４＿２（例えば、命令７）は、疑わしいレイヤー３のバージョンフ
ィールドをテストし、レイヤー３のプロトコルがＩＰのバージョン４であること
を確実にする。特に、ＩＰのバージョン４についての仕様は、レイヤー３のヘッ
ダーの最初の４ビットが、０ｘ４の値を含むという条件をつける。テストが失敗
である場合、構文解析プロシージャは、命令ＤＯＮＥにより終了する。テストが
成功である場合、ポインタは６バイト進み、命令ＩＰＶ４＿３が呼び出される。

【０１７５】 特定されたＬＤ＿ＳＵＭオペレーションは（それは命令ＩＰＶ４＿２での比較
が成功である場合にのみ実行されるが）、チェックサムが計算され得るポインタ
の先頭についてのオフセットが格納されるべきであることを示す。特に、記載さ
れる本発明の実施形態で、チェックサムはＴＣＰのヘッダーから計算されるべき
である（この場合、レイヤー４のヘッダーはＴＣＰであると仮定する）。オペレ
ーションの引数値（例えば、０ｘ００Ａ）は、チェックサムが現在のポインタか
ら２０バイト（例えば２バイトのインクリメントを１０回）の位置にあることを
示す。従って、２０バイトの値が構文解析ポインタの位置に加えられ、その結果
がレジスタまたは他のデータ構造（例えば、ＣＳＵＭＳＴＡＲＴレジスタ）に格
納される。

【０１７６】 命令ＩＰＶ４＿３（例えば、命令８）は、パケットのＩＰヘッダーがＩＰ断片
化を示しているかどうかを判定するように設計される。抽出マスクに従ってヘッ
ダーから抽出される値が比較値と等しくない場合、パケットは断片化を示す。断
片化が検出される場合、パケットは、本明細書で議論された処理強化に不適切で
あるとみなされ、プロシージャ（例えば、命令ＤＯＮＥによって）は終了する。
断片化が検出されない場合、ポインタは、２バイト分インクリメントされ、命令
ＩＰＶ４＿４は、ＬＤ＿ＬＥＮオペレーションの実行後に呼び出される。

【０１７７】 ＬＤ＿ＬＥＮオペレーションに従って、ＩＰセグメントの長さが保存される。
図示されたオペレーション引数（例えば、０ｘ０３Ｅ）は、この値が位置付けさ
れる合計長フィールドのオフセットを含む。特に、最下位の６ビットはオフセッ
トを構成する。ポインタは、既にこのフィールドを越えて進行してるので、オペ
レーション引数は負の値を含む。当業者であれば、この２進法での値（例えば、
１１１１１０）が１０進法での−２の値を表すのに使用され得ることを理解する
。従って、ポインタの現在のオフセット、つまり−４バイト（例えば、２つの２
バイト単位）が、レジスタまたは他のデータ構造（例えば、ＰＡＹＬＯＡＤＬＥ
Ｎレジスタ）に保存される。負のオフセットを表す任意の他の適切な方法が使用
され得る。または、ポインタが合計長フィールド（例えば、以前の命令時の）よ
り前の位置にある間に、ＩＰセグメント長を保存することができる。

【０１７８】 命令ＩＰＶ４＿４（例えば、命令９）において、１バイトのプロトコルフィー
ルドは、レイヤー４のプロトコルがＴＣＰであるかどうかを判定するために検査
される。レイヤー４のプロトコルがＴＣＰである場合、ポインタは、１４バイト
分進められ、命令ＴＣＰ＿１は実行され続ける。レイヤー４のプロトコルがＴＣ
Ｐでない場合、プロシージャは終了する。

【０１７９】 命令ＩＰＶ４＿４での比較がうまくいく場合にのみ実行される特定のＬＤ＿Ｆ
ＩＤオペレーションは、パケットのフローキーを取り出す工程、および取り出し
たフローキーをレジスタまたは他の位置（例えば、ＦＬＯＷＩＤレジスタ）に格
納する工程を含む。当業者であれば、命令ＩＰＶ４＿４がうまくいくためには、
パケットのレイヤー３およびレイヤー４のヘッダーは、それぞれＩＰ（バージョ
ン４）およびＴＣＰに適合する必要があることを理解する。そうである場合、フ
ローキー全体（例えば、ＩＰソースおよび宛先のアドレスに加えてＴＣＰソース
および宛先ポート番号）が、パケットのヘッダー部に連続して格納される。特に
、フローキーは、ＩＰヘッダーの最後部およびＴＣＰヘッダーの先頭部を含み、
１つのオペレーションで抽出され得る。従って、オペレーション引数（例えば、
０ｘ１８２）は、フローキーを位置付けし、境界を定めるために必要な２つの値
を含む。例示的に、引数の最右の６ビット（例えば、０ｘ０２）は、ポインタ部
からフローキーの先頭まで、オフセットを２バイト単位で識別する。引数の他の
５ビット（例えば、０ｘ０６）は、格納されるフローキーのサイズを２ビット単
位で識別する。

【０１８０】 命令ＩＰＶ４＿１によって実行される比較が失敗した後に行われるＩＰＶ６＿
１（例えば、命令１０）で、構文解析ポインタはレイヤー２のタイプフィールド
にあるべきである。このテストが成功する（例えば、タイプフィールドは８６Ｄ
Ｄの１６進法の値を保持する）場合、命令ＩＰＶ６＿２は、ＬＤ＿ＳＵＭオペレ
ーションが実行された後に実行され、ポインタがレイヤー３のプロトコルの先頭
に２バイト分インクリメントされる。テストが失敗である場合、プロシージャは
終了する。

【０１８１】 命令ＩＰＶ６＿１において示されるＬＤ＿ＳＵＭオペレーションは、命令ＩＰ
Ｖ４＿２において実行されるオペレーションに類似してるが、異なる引数を利用
する。ここでもやはり、（レイヤー４のヘッダーはＴＣＰであると仮定すると）
チェックサムはＴＣＰヘッダーの先頭から計算されることになる。従って、特定
されたオペレーション引数（例えば、０ｘ０１５）は、ＴＣＰヘッダーの先頭つ
まり２１の２バイトステップ前へのオフセットを含む。示されるオフセットは、
現在のポインタ位置に加えられ、レジスタまたは他のデータ構造（例えば、ＣＳ
ＵＭＳＴＡＲＴレジスタ）に保存される。

【０１８２】 命令ＩＰＶ６＿２（例えば、命令１１）はさらに、疑わしいレイヤー３のバー
ジョンフィールドをテストし、レイヤー３のプロトコルがＩＰのバージョン６で
あることを確実にする。その比較が失敗すると、構文解析プロシージャは、命令
ＤＯＮＥを呼び出して終了する。その比較が成功すると、命令ＩＰＶ６＿３が呼
び出される。この実施形態において比較が成功である場合のみに実行されるオペ
レーションＩＭ＿Ｒ１は、ペイロード長フィールドからのＩＰヘッダーを保存す
る。当業者が理解するように、ＩＰ（バージョン４）ヘッダーは、合計長フィー
ルド（例えば、ＩＰセグメントサイズ）は、バージョン４のヘッダーサイズを含
む。しかし、ＩＰ（バージョン６）ヘッダーのペイロード長フィールド（例えば
、ＩＰセグメントサイズ）は、バージョン６のサイズを含まない。従って、出力
引数の最右８ビット（例えば、０ｘ１４、これは２０の２バイト単位を示す）に
よって識別されるバージョン６ヘッダーのサイズが、保存される。例示的に、残
りの引数は、ヘッダー長を格納するデータ構造（例えば、一時レジスタＲ１）を
識別する。プロトコル間のレイヤー３のヘッダーのサイズが変化するために、本
発明の１実施形態において、ヘッダーサイズを異なる単位で識別して、より高い
精度を可能にする。特に、本発明の１実施形態において、ヘッダーのサイズは、
命令ＩＰＶ６＿２において、バイトで特定される。この場合、出力引数は０ｘ１
２８である。

【０１８３】 この実施形態において、命令ＩＰＶ６＿３（例えば、命令１２）はヘッダー値
を検査しない。この実施形態において、０ｘ００００の抽出マスクと０ｘ０００
０の比較値との組み合せは、ヘッダー部の次の検査の前に出力オペレーションが
望まれることを示す。ＬＤ＿ＦＩＤオペレーションが実行された後に、構文解析
ポインタが、バージョン６のＩＰヘッダーの次のヘッダーフィールドに６バイト
進められる。抽出マスクおよび比較値が両方とも０ｘ００００であるので、比較
は必ず成功し、命令の失敗ブランチは決して呼び出されない。

【０１８４】 上述のように、ＬＤ＿ＦＩＤオペレーションは、フローキーを適切なレジスタ
または他のデータ構造（例えば、ＦＬＯＷＩＤレジスタ）に格納する。例として
、０ｘ４８４であるオペレーション引数は、フローキーを識別し、その境界を定
める２つの値を含む。特に、最右の６ビット（例えば、０ｘ０４）は、フローキ
ー部が、現在のポインタの位置から８バイト（例えば、２バイトインクリメント
を４回）のオフセットに位置付けされることを示す。残りのオペレーション引数
（例えば、０ｘ１２）は、３６バイト（例えば、０ｘ１２の２バイト単位に相当
する１０進法）が計算されるオフセットからコピーされることを示す。本発明の
例示的な実施形態において、フローキー全体がそのままコピーされ、これはレイ
ヤー３のソースおよび宛先のアドレスおよびレイヤー４のソースおよび宛先ポー
トを含む。

【０１８５】 命令ＩＰＶ６＿４（例えば、命令１３）で、疑わしい次のヘッダーフィールド
が検査され、パケットのプロトコルスタックのレイヤー４のプロトコルがＴＣＰ
であるかどうかを判定する。レイヤー４のプロトコルがＴＣＰである場合、プロ
シージャは３６バイト（例えば、１８の２バイト単位）進み、命令ＴＣＰ＿１が
呼び出される。レイヤー４のプロトコルがＴＣＰでない場合、プロシージャは（
例えば、命令ＤＯＮＥによって）終了する。次のヘッダーフィールドの値が０ｘ
０６である場合、オペレーションＬＤ＿ＬＥＮが実行される。上述したように、
このオペレーションはＩＰセグメントサイズを格納する。ここでもやはり、引数
（例えば、０ｘ０３Ｆ）は、負のオフセット（この場合、−１）を含む。このオ
フセットは、望まれるペイロード長フィールドがポインタの現在の位置の２バイ
ト前に位置することを示す。従って、負のオフセットは現在のポインタオフセッ
トに加えられ、その結果が適切なレジスタまたは他のデータ構造（例えば、ＰＡ
ＹＬＯＡＤＬＥＮレジスタ）に保存される。

【０１８６】 命令ＴＣＰ＿１、ＴＣＰ＿２、ＴＣＰ＿３およびＴＣＰ＿４（例えば、命令１
４〜１７）には、命令の出力オペレーションで特定される一定のフラグを除いて
検査されるヘッダー値はないが、パケットのＴＣＰヘッダーからの様々なデータ
が保存される。例示的な実施形態において、保存されるデータはＴＣＰシーケン
ス番号、ＴＣＰヘッダー長および１以上のフラグを含む。各命令に対して、特定
されたオペレーションが実行され、次の命令が呼び出される。上述したように、
これらの命令の各々で用いられる０ｘ００００の比較値とヌル抽出値の間の比較
は、必ず成功する。命令ＴＣＰ＿４の後、構文解析プロシージャは、新しいパケ
ットを待つ命令ＷＡＩＴに戻る。

【０１８７】 命令ＴＣＰ＿１におけるオペレーションＬＤ＿ＳＥＱの場合、オペレーション
引数（例えば、０ｘ０８１）は、ＴＣＰシーケンス番号を識別し、抽出する２つ
の値を含む。最右の６ビット（例えば、０ｘ０１）は、シーケンス番号が、ポイ
ンタの現在位置から２バイトに位置することを示す。残りの引数（例えば、０ｘ
２）は、その位置からコピーされなければならない２バイト単位の数を示し、シ
ーケンス番号を取り込む。例として、シーケンス番号は、ＳＥＱＮＯレジスタに
格納される。

【０１８８】 命令ＴＣＰ＿２のオペレーションＳＴ＿ＦＬＡＧの場合、オペレーション引数
（例えば、０ｘ１４５）を用いて、構文解析後のタスクで使用されるレジスタ（
例えば、フラグレジスタ）をフラグで構成する。最右６ビット（例えば、０ｘ０
５）は、パケットが、本発明の構文解析後の強化に適切であるかどうかに影響し
得るフラグを含むＴＣＰヘッダーの２バイト部に２バイト単位でオフセットを構
成する。例えば、ＵＲＧ、ＰＳＨ、ＲＳＴ、ＳＹＮおよびＦＩＮフラグはオフセ
ット位置に位置し得、レジスタを構成するのに使用され得る。出力マスク（例え
ば、０ｘ００２Ｆ）は、ＴＣＰヘッダーのフラグフィールドの特定部（例えば、
ビット）のみが格納されることを示す。

【０１８９】 命令ＴＣＰ＿３のオペレーションＬＤ＿Ｒ１は、命令ＩＰＶ６＿２で実行され
るオペレーションに類似する。ここでは、０ｘ２０５のオペレーション引数は、
現在のポインタの位置からの５つの２バイト単位のオフセットを識別する値（例
えば、最下位の６ビット）を示す。その位置には、残りの引数によって識別され
るデータ構造（例えば、レジスタＲ１）に格納されるヘッダー長フィールドが含
まれるべきである。出力マスク（例えば、０ｘＦ０００）は、最初の４ビットの
みが保存される（例えば、ヘッダー長フィールドのサイズはわずか４ビットであ
る）ということを示す。

【０１９０】 当業者が認識するように、ヘッダー長フィールドから抽出される値は、例示さ
れた実施形態において２バイト単位（例えば、１６ビットワード）の使用を反映
するように調整される必要があり得る。それゆえ、命令ＴＣＰ＿３のシフト部に
従って、フィールドから抽出され、出力マスク（例えば、０ｘＦ０００）によっ
て構成される値が、計算を容易にするために格納される場合、右に１１の位置だ
けシフトされる。

【０１９１】 命令ＴＣＰ＿４のオペレーションＬＤ＿ＨＤＲは、ＴＣＰヘッダーに続いてパ
ケットデータの第１のバイトのオフセットのローディングを引き起こす。例示的
に、予め選択されたプロトコルスタックに適合するパケットは、いくつかの点で
ヘッダー部およびデータ部に分離され得る。次にオフセットをデータ部に保存す
ることによって、パケットを後で分けることを容易にする。例として、０ｘ０Ｆ
Ｆオペレーション引数の最右の７ビットは、データについてのオフセットの第１
の要素を含む。当業者は、ビットパターン（例えば、１１１１１１１）を−１と
等価であるとみなす。従って、現在の構文解析ポインタに等しいオフセット値か
ら（例えば、ＡＤＤＲレジスタの値）２バイト引いた（ＴＣＰヘッダーの先頭を
位置付ける）値が、保存される。残りの引数は、一時的なデータ構造（例えば、
一時レジスタＲ１）の値がこのオフセットに加えられる予定であることを示す。
この特定のコンテクストでは、前の命令で保存される値（例えば、ＴＣＰヘッダ
ーの長さ）が加えられる。これらの２つの値が組み合わさって、パケットデータ
の先頭のオフセットを形成する。形成されたオフセットは適切なレジスタまたは
他のデータ構造（例えば、ＨＤＲＳＰＬＩＴレジスタ）に格納される。

【０１９２】 最後に、上述されるように、命令ＤＯＮＥ（例えば、命令１８）は、パケット
が、例示された命令に関連する１つ以上のプロトコルに適合しないと判定すると
、パケットの構文解析の終了を示す。これは、「クリーンアップ」命令とみなさ
れ得る。特に、オペレーション引数０ｘ００１を有する出力オペレーションＬＤ
＿ＣＴＬは、命令ＶＬＡＮと関係して上記された制御レジスタでＮｏ＿Ａｓｓｉ
ｓｔフラグが（例えば、１に）設定されることを示す。他で説明されているよう
に、Ｎｏ＿Ａｓｓｉｓｔフラグは、ネットワークインターフェースの他のモジュ
ールに、現在のパケットが他で説明される１つ以上の処理強化に不適切であるこ
とを知らせるのに、使用され得る。

【０１９３】 例示されるプログラムまたはマイクロコードは、パケットを構文解析する１方
法を提供してるに過ぎない。異なるシーケンスで同じ命令または異なる命令を共
に含む他のプログラムは、フォーマットが同じであっても、または異なっていて
もヘッダー部を検査し、格納し、レジスタおよび他のデータ構造を構成するのに
使用され得る。

【０１９４】 本発明の本実施形態の強化処理を適用することによって効率が増し、このこと
は例示されるプログラムを用いたパケットの構文解析に必要な時間を相殺する。
さらに、ヘッダーパーサが、本発明の本実施形態のＮＩＣ上のパケットを構文解
析する場合でさえ、パケットは、ホストコンピュータ上のプロセッサによって（
例えば、プロトコルヘッダーを取り除くために）そのプロトコルスタックを通じ
てまだ処理される必要がある。そうすることによって、そのようなタスクによる
通信デバイス（例えば、ネットワークインターフェース）への負荷を防ぐ。

【０１９５】 （フローデータベースの１実施形態） 図５は、本発明の１実施形態に従って、フローデータベース（ＦＤＢ）１１０
を示す。例として、ＦＤＢ１１０は、再書き込み可能メモリ構成要素（例えば、
ＲＡＭ、ＳＲＡＭ、ＤＲＡＭ）を用いてＣＡＭ（内容指定メモリ）として実行さ
れる。この実施形態において、ＦＤＢ１１０は連想部５０２および関連部５０４
を含み、フロー番号５０６によってインデックスを与えら得れる。

【０１９６】 本発明の範囲は、フローデータベース１１０の形式または構造を限定しない。
本発明の代替的な実施形態において、実質的にデータ構造の任意の形式（例えば
、データベース、テーブル、キュー、リスト、アレイ）が用いられ得、モノリシ
ックまたはセグメントのいずれであってもよく、ハードウェアまたはソフトウェ
アで実行され得る。ＦＤＢ１１０の例示された形式は、ＮＩＣ１００を通る通信
フローについての有用な情報を維持する１つの手段に過ぎない。当業者には、Ｃ
ＡＭの構造は連想検索を非常に効率よく、かつ迅速に実行することを可能にする
ことが明らかである。

【０１９７】 本発明の例示的な実施形態において、ＦＤＢ１１０に格納される情報および（
以下で説明される）フローデータベースマネージャ（ＦＤＢＭ）１０８のオペレ
ーションにより、データのリアセンブリ、パケットヘッダーのバッチ処理、およ
び他の強化等の機能を可能する。これらの機能は、簡潔に以下で説明され得る。

【０１９８】 データリアセンブリの１形式は、複数の関連付けられたパケット（例えば、１
つの通信フローまたは１つのデータグラムからのパケット）からのデータのリア
センブリまたは組み合せを含む。パケットヘッダーのバッチ処理の１方法は、１
度に１パケットではなく、集約的に複数の関連付けられたパケットからプロトコ
ルスタックまでプロトコルヘッダーを処理することを伴う。ＮＩＣ１００の別の
例示的な機能は、マルチプロセッサホストコンピュータシステムのプロセッサ間
でそのようなプロトコルスタック処理（および／または他の機能）の分散または
共有を含む。ＮＩＣ１００のさらに別の可能な機能は、リアセンブリされたデー
タを、よくまとめて（例えば、メモリページ）、宛先エンティティー（例えば、
アプリケーションプログラム）に伝送することを可能にし、それにより１度に１
パケットデータの断片的で、非常に非効率な伝送を避ける。従って、本発明のこ
の実施形態において、ＦＤＢ１１０およびＦＤＢＭ１０８の１目的は、これらの
１つ以上の機能をイネーブルするか、ディセーブルするかまたは実行する際に、
ＮＩＣ１００および／またはホストコンピュータの使用のための情報を生成する
ことである。

【０１９９】 図５のＦＤＢ１１０の連想部５０２は、ＮＩＣ１００が扱うエンティティに向
けられる各有効なフローのフローキーを格納する。従って、本発明の１実施形態
において、連想部５０２は、ＩＰソースアドレス５１０、ＩＰ宛先アドレス５１
２、ＴＣＰソースポート５１４およびＴＣＰ宛先ポート５１６を含む。前のセク
ションに説明されるように、これらのフィールドは、ヘッダーパーサ１０６によ
って、パケットから抽出され得、ＦＤＢＭ１０８に提供され得る。

【０２００】 ＮＩＣ１００が扱う各宛先エンティティは、複数の通信フローまたはエンドト
ゥエンド（ｅｎｄ ｔｏ ｅｎｄ）ＴＣＰ接続に関係するが、１度に１フローだ
けが特定のソースエンティティと特定の宛先エンティティとの間に存在する。そ
れゆえ、有効なフローに対応する連想部５０２の各フローキーは、全ての他の有
効なフローに対して一意的であるはずである。本発明の代替的な実施形態におい
て、連想部５０２は、異なるフィールドで構成され、代替的なフローキー形式を
反映する。これら異なるフィールドは、ヘッダーパーサによって構文解析された
プロトコルおよび通信フローを識別するのに用いられる情報によって判定され得
る。

【０２０１】 例示された実施形態において関連部５０４は、フロー有効インジケータ５２０
、フローシーケンス番号５２２およびフロー活動インジケータ５２４を含む。こ
れらのフィールドは、連想部５０２における対応するエントリに格納されるフロ
ーキーによって識別されるフローに関する情報を提供する。関連部５０４のフィ
ールドは、次のセクションで説明されるようにＦＤＢＭ１０８によって、取り出
され得るおよび／または更新され得る。

【０２０２】 この実施形態において、フロー有効インジケータ５２０は関連付けられたフロ
ーが有効であるか、または無効であるかを示す。例示的に、フローのデータの第
１のパケットが受け取られる場合、フロー有効インジケータは有効なフローを示
すように設定され、フローのデータグラム部（例えば、パケット）が正確に受け
取られる度に、フロー有効インジケータがフローの有効性を再アサートするよう
に再設定され得る。

【０２０３】 フローのデータの最後のパケットが受け取られた後で、フロー有効インジケー
タ５２０は無効であるとマーキングされ得る。フロー有効インジケータはまた、
最終データパケットの受信以外に何らかの理由のためにフローが壊される（例え
ば、終了されるまたはアボートされる）場合は常に、無効なフローを示すように
設定され得る。例えば、パケットは、データグラムの他のパケットから無秩序に
受け取られてもよいし、データ伝送またはフローがアボートされることを示す制
御パケットを受け取ってもよいし、（元のフローが終了する場合に）フローを再
確立または再同期をとる試みがなされ得る等である。本発明の１実施形態におい
て、フロー有効インジケータ５２０は、１つのビット、フラグまたは値である。

【０２０４】 例示的な実施形態において、フローシーケンス番号５２２は、関連付けられた
フローに待機する次のデータ部のシーケンス番号を含む。フローで送られるデー
タグラムが一般に複数のパケットを介して受け取られるので、フローシーケンス
番号は、パケットが正確な順番で受け取られるのを確実にする機構を提供する。
例えば、本発明の１実施形態において、ＮＩＣ１００はデータグラムの複数のパ
ケットからデータをリアセンブルする。最も効率的な様態でこのリアセンブリを
行うためには、パケットが正しい順番で受け取られる必要がある。従って、フロ
ーシーケンス番号５２２は、受け取られるべき次のパケットまたはデータ部を識
別する識別子を格納する。

【０２０５】 本発明の１実施形態において、フローシーケンス番号５２２はＴＣＰプロトコ
ルヘッダーにあるＴＣＰシーケンス番号フィールドに対応する。当業者が認識す
るように、パケットのＴＣＰシーケンス番号は、データグラムで送られる他のデ
ータに関連するパケットデータの位置を識別する。ＴＣＰ以外のプロトコルを含
むパケットおよびフローに対して、正確な順番でデータを受け取ったかを確認す
るか、または正確な順番でデータを受け取ることを確実にする別の方法が使用さ
れ得る。

【０２０６】 例示的な実施形態におけるフロー活動インジケータ５２４は、フローの活動の
新しさ、言い換えれば、フローの年齢を反映する。本発明のこの実施形態におい
て、フロー活動インジケータ５２４は、フロー活動カウンタ（図５に図示せず）
等のカウンタに関連する。フロー活動カウンタは、パケットが、既にフローデー
タベース１１０に格納されるフローの一部として受け取られる度に更新される（
例えばインクリメントされる）。次いで、更新されたカウンタ値は、パケットの
フローのフロー活動インジケータフィールドに格納される。フロー活動カウンタ
はまた、データベースに加えられる新しいフローの第１のパケットが受け取られ
る度にインクリメントされ得る。別の実施形態において、フロー活動カウンタは
、データを含むパケットについて更新されるのみである（例えば、制御パケット
については更新されない）。さらに別の代替的な実施形態において、複数のカウ
ンタは、異なるフローについてのフロー活動インジケータを更新するために用い
られる。

【０２０７】 通信フローが終了する（例えば、最終パケットが失われ得る）時点を常に判定
され得るとは限らないので、フロー活動インジケータは、古いまたは何らかの他
の理由で壊されるべきフローを識別するのに使用され得る。例えば、新しいフロ
ーの第１のパケットが受け取られる時にフローデータベース１１０は完全にポピ
ュレートされる（例えば、フロー有効インジケータ５２０が各フロー番号に対し
て設定される）ようである場合、最下位のフロー活動インジケータを有するフロ
ーが、新しいフローによって取り替えられ得る。

【０２０８】 本発明の例示的な実施形態において、ＦＤＢ１１０のフィールドのサイズは、
エントリごとに異なり得る。例えば、ＩＰソースおよび宛先アドレスは、プロト
コルのバージョン４で４バイトの大きさであるが、バージョン６では１６バイト
である。本発明の別の１実施形態において、特定のフィールドのエントリのサイ
ズは均一であり得、必要に応じてより小さなエントリがパディングされる。

【０２０９】 本発明の別の代替的な実施形態において、ＦＤＢ１１０内のフィールドがマー
ジされ得る。特に、フローのフローキーは、図５に示されるように多数の個別の
フィールドとして格納される代わりに、１つのエンティティまたは１つのフィー
ルドとして格納され得る。同様に、フロー有効インジケータ５２０、フローシー
ケンス番号５２２およびフロー活動インジケータ５２４は、図５で個別のエント
リとして示される。しかし、本発明の別の実施形態において、１つ以上のこれら
のエントリは、組み合わせられ得る。特に、別の１実施形態において、フロー有
効インジケータ５２０およびフロー活動インジケータ５２４は、エントリ関連フ
ローが無効である場合、第１の値（例えば０）を有する１つのエントリを含む。
しかし、フローが有効である限り、組み合わされるエントリは、パケットが受け
取られるにつれてインクリメントされ、フローが終了すると第１の値に再設定さ
れる。

【０２１０】 本発明の１実施形態において、ＦＤＢ１１０は、フロー番号５０６とインデッ
クスを付けられた最大６４のエントリを含み、これによりデータベースが１度に
６４の有効フローを追跡することを可能にする。本発明の別の実施形態において
、フローデータベース１１０に割り当てられるメモリのサイズに依存して、より
多いエントリまたはより少ないエントリが可能になり得る。フロー番号５０６に
加えて、フローは（連想部５０２に格納される）フローキーによって識別され得
る。

【０２１１】 本発明の例示的な実施形態において、ＮＩＣ１００が初期化される場合、フロ
ーデータベース１１０は空である（例えば、全てのフィールドは０で満たされる
）。フローの第１のパケットが受け取られる場合、ヘッダーパーサ１０６はパケ
ットのヘッダー部を構文解析する。以前のセクションで説明されたように、ヘッ
ダーパーサはフローキーをアセンブルして、フローを識別し、パケットおよび／
またはフローに関する他の情報を抽出する。フローキー、および他の情報は、デ
ータベースマネージャ１０８に通される。ＦＤＢＭ１０８は、次いでフローキー
に関連するアクティブフローを求めてＦＤＢ１１０を検索する。データベースは
空なので、一致するものはない。

【０２１２】 それゆえ、この実施例では、フローキーは、ＩＰソースアドレス、ＩＰ宛先ア
ドレス、ＴＣＰソースポートおよびＴＣＰ宛先ポートを対応するフィールド内へ
コピーすることによって、（例えば、フロー番号０として）格納される。次いで
フロー有効インジケータ５２０は、有効フローを示すように設定され、フローシ
ーケンス番号５２２は、（例示的には、ヘッダーパーサによって提供される）Ｔ
ＣＰシーケンス番号から得られ、フロー活動インジケータ５２４は、カウンタか
ら得られ得る初期値（例えば、１）に設定される。適切なフローシーケンス番号
を生成する１つの方法は、ＴＣＰシーケンス番号とパケットデータのサイズとを
加えることである。このような方法は、フローで受け取られる次のデータ部が順
番に受け取られることを確認するために使用され得る。しかし、パケットの構成
（例えば、パケットのＴＣＰヘッダーのフラグフィールドにＳＹＮビットが設定
されるかどうか）に依存するので、その和は、正確に次に待機されるデータ部を
識別するように（例えば１を加えることによって）調整される必要があり得る。

【０２１３】 上述したように、フロー活動インジケータの適切な初期値を生成する１方法は
、フローの一部として受け取られる各パケットについてインクリメントされるカ
ウンタ値をコピーすることである。例えば、ＮＩＣ１００が初期化される後で受
け取られる第１のパケットに対して、フロー活動カウンタは、１の値にインクリ
メントされ得る。次いで、この値が、関連するフローのフロー活動インジケータ
５２４に格納され得る。同じ（または新しい）フローの一部として受け取られる
次のパケットにより、カウンタは２にインクリメントされる。その値２は、関連
付けられたフローのフロー活動インジケータに格納される。この実施例では、２
つのフローは、それらが等しく０または何らかの所定の値であり得る場合、初期
化時を除いて同じフロー活動インジケータを有す必要はない。

【０２１４】 ＮＩＣ１００で受け取られる新しい（ｌａｔｅｒ）パケットを受信し、構文解
析を行うと、フローデータベースは、そのパケットのフローキーに一致する有効
なフローを求めて検索される。例示的には、アクティブフロー（例えば、フロー
有効インジケータ５２０が設定されるそれらのフロー）のフローキーのみが検索
される。あるいは、全てのフローキー（例えば、連想部５０２のすべてのエント
リ）が検索され得るが、フロー有効インジケータが有効フローを示す場合に一致
するかどうかのみが報告される。図５のＦＤＢ１１０等のＣＡＭを用いて、フロ
ーキーおよびフロー有効インジケータは平行して検索され得る。

【０２１５】 新しいパケットが、前のフロー（例えば、フロー番号０）についての次のデー
タ部を含む場合、そのフローは適切に更新される。本発明の１実施形態において
、これは、最新のフローの活動を反映するためにフローシーケンス番号５２２の
更新およびフロー活動インジケータ５２４のインクリメントを必要とする。既に
フローが有効であることを示すべきであるが、フロー有効インジケータ５２０は
また、フローの有効性を示すように設定され得る。

【０２１６】 新しいフローが識別される場合、それらは、第１のフローと同じようにＦＤＢ
１１０に加えられる。フローが終了されるまたは壊される場合、ＦＤＢ１１０の
関連付けられたエントリは無効になる。本発明の１実施形態において、フロー有
効インジケータ５２０は、終了したフローについてクリアに（例えば０に設定）
されるだけである。別の実施形態において、終了したフローの１つ以上のフィー
ルドはクリアにされるかまたは任意のまたは所定の値に設定される。ネットワー
クパケットトラフィックのバースト可能性（ｂｕｓｒｔｙ ｎａｔｕｒｅ）のた
めに、データグラムからの全てまたはほとんどのデータは、一般に、短時間で受
け取られる。従って、ＦＤＢ１１０の各有効フローのみが、一般に短時間の間維
持される必要があり、次いでそのエントリは異なるフローを格納するように使用
され得る。

【０２１７】 本発明の１実施形態においてフローデータベース１１０に利用可能なメモリの
制限量によって、各フィールドのサイズは制限され得る。この実施形態において
、１６バイトがＩＰソースアドレス５１０に割り当てられ、１６バイトがＩＰ宛
先アドレス５１２に割り当てられる。１６バイトより短い長さのＩＰアドレスに
対して、余剰スペースが０でパディングされ得る。さらに、ＴＣＰソースポート
５１４およびＴＣＰ宛先ポート５１６にはそれぞれ２バイトが割り当てられる。
また、この実施形態において、フロー有効インジケータ５２０は１ビットを含み
、フローシーケンス番号５２２には４バイトが割り当てられ、フロー活動インジ
ケータ５２４にもまた、４バイトが割り当てられる。

【０２１８】 当業者であれば上記の実施形態から認識するように、フローは同じであるが、
エンドトゥエンドＴＣＰ接続に関して一致してない。ＴＣＰ接続は、ソースエン
ティティから宛先エンティティまで複数のデータグラムを伝送するのに十分な比
較的長い期間の間、存在し得る。フローは、しかし、１データグラムについての
み存在し得る。従って、１つのエンドトゥエンドＴＣＰ接続の間に、複数のフロ
ーが、（例えば、各データグラムに対して１回）設定され、壊され得る。これま
でに説明されたように、フローは、ＮＩＣ１００がデータグラムにおけるデータ
の第１の部分を検出する場合、設定され得（例えば、ＦＤＢ１１０に加えられ、
有効であるとマーキングされ）、データの最後の部分が受け取られる場合、壊さ
れ得る（例えば、ＦＤＢ１１０に無効と示される）。例示的に、１つのエンドト
ゥエンドＴＣＰ接続の間に設定される各フローは、同じフローキーを有する。こ
れは、フローキーを形成するのに使用されるレイヤー３およびレイヤー４のアド
レスおよびポート識別子は、同じままであるためである。

【０２１９】 例示的な実施形態において、フローデータベース１１０のサイズ（例えば、フ
ローエントリの数）は、データのリアセンブリ機能およびプロトコルヘッダーの
バッチ処理をイネーブルにしながら、１度にインタリーブされ得る（例えば、同
時にアクティブである）最大フロー数を決定する。すなわち、図５に示される実
施形態において、ＮＩＣ１００が６４のフローを設定し得、フローを壊すことな
く最大６４の異なるデータグラムからパケットを受け取り得る（すなわち、６４
のフローがアクティブとなり得る）。ＮＩＣ１００による最大フロー数が既知で
ある場合、フローデータベース１１０は対応するエントリ数に制限さ得る。

【０２２０】 現在、説明される実施形態において、フローは１データグラムに対して続くだ
けなので、フローデータベースは小さいままであり得る。パケットトラフィック
のバースト可能性のため、データグラムパケットは、一般に短期間内で受け取ら
れる。短期間のフローによって、フローデータベースにおいて制限されたエント
リ数が補償される。本発明の１実施形態において、ＦＤＢ１１０はアクティブフ
ローで満たされ、新しいフロー（すなわち、新しいデータグラムでデータの第１
の部分）が開始される場合、最古の（例えば、最近アクティブとなっていない）
フローは新しいフローに置き換えられる。

【０２２１】 本発明の別の実施形態において、フローは、任意の数のデータグラム（または
ネットワーックトラフィックの他の量）または特定の長さまたは時間範囲につい
てアクティブなままであり得る。例えば、データベースがフルでない場合（例え
ば、フローのエントリが異なるフローに必要とされない場合）、１データグラム
が終了する時点で、ＦＤＢ１１０内のフローは「オープン」（すなわち、壊され
ない）なままであり得る。このスキームは、同じフローキーを有する別のデータ
グラムが受け取られる場合、ＮＩＣ１００の効率の良い動作をさらに強化し得る
。特に、別のフローの設定に関わるオーバーヘッドは避けられ、（以下に説明さ
れるような）より多くのデータリアセンブリおよびパケットバッチングが実行さ
れ得る。利点として、フローは、フローを囲むエンドトゥエンドＴＣＰ接続が終
了するまで、フローデータベース１１０でオープンなままであり得る。

【０２２２】 （フローデータベースマネージャの１実施形態） 図６Ａ〜６Ｅは、図１Ａの、フローデータベース（ＦＤＢ）１１０を管理する
フローデータベースマネージャ１０８を例とするフローデータベースマネージャ
（ＦＤＢＭ）を操作する１方法を示す。例示的には、ＦＤＢＭ１０８は、フロー
データベース１１０に格納されるフロー情報を格納および更新し、ＮＩＣ１００
によって受け取られるパケットのオペレーションコードを生成する。ＦＤＢＭ１
０８はまた、フローが終了されるまたはアボートされる場合、フローを壊す（例
えば、ＦＤＢ１１０において、エントリを取替え、除去し、またはさもなければ
、無効にする）。

【０２２３】 本発明の１実施形態において、パケットオペレーションコードは、ＮＩＣ１０
０の１つ以上の機能（例えば、データのリアセンブリ、パケットヘッダーのバッ
チ処理、負荷分散）を実行するための所定の判定基準とのパケットの互換性を反
映する。すなわち、パケットのオペレーションコードに依存して、ＮＩＣ１００
の他のモジュールが、これらの機能の内の１つを実行してもよいし、実行しなく
てもよい。

【０２２４】 本発明の別の実施形態において、オペレーションコードはパケット状態を示す
。例えば、オペレーションコードは、以下のようなパケットを示し得る：データ
を含まない、制御パケットである、特定量より多いデータを含む、新しいフロー
の第１パケットである、現存するフローの最後のパケットである、無秩序である
、予想される値を有さない（従って、多分、例外的な状況を示す）一定のフラグ
を（例えば、プロトコルヘッダー内に）含むパケットなど。

【０２２５】 フローデータベースマネージャ１０８の動作は、ヘッダーパーサ１０６に提供
されるパケット情報およびフローデータベース１１０から引き出されるデータに
依存する。ＦＤＢＭ１０８がパケット情報および／またはデータを処理した後で
、制御情報（例えば、パケットオペレーションコード）が制御キュー１１８に格
納され、ＦＤＢ１１０が変更され得る（例えば、新しいフローが入力され得る、
または現存するフローが更新され、もしくは壊される）。

【０２２６】 図６Ａ〜６Ｅを参考にして、状態６００は、ＦＤＢＭ１０８がネットワーク１
０２からＮＩＣ１００によって受け取られるパケットから引き出される情報を待
つ開始状態である。状態６０２では、ヘッダーパーサ１０６またはＮＩＣ１００
の別のモジュールは、パケットのフローキーおよびいくつかの制御情報を提供す
ることによって、ＦＤＢＭ１０８に新しいパケットを知らせる。このデータの受
信は、ＦＤＢ１１０を検索して、このフローキーを有するフローが既に存在する
かどうかを判定するためのリクエストとして、解釈され得る。

【０２２７】 本発明の１実施形態において、ＦＤＢＭ１０８に通される制御情報は、パケッ
トヘッダーから引き出されるシーケンス番号（例えば、ＴＣＰシーケンス番号）
を含む。制御情報はまた、パケットヘッダーの一定のフラグの状態、パケットが
データを含むかどうか、パケットがデータを含む場合、データ量が一定のサイズ
を超えるかどうかを示し得る。この実施形態において、ヘッダーパーサが、予め
選択されたプロトコルスタックの１つに従ってパケットがフォーマットされてい
ない（すなわち、パケットが「互換性」がない）ことを判定する場合、これまで
のセクションで議論されたように、ＦＤＢＭ１０８はまた、パケットのＮｏ＿Ａ
ｓｓｉｓｔ信号を受け取る。例示的に、Ｎｏ＿Ａｓｓｉｓｔ信号は、ＮＩＣ１０
０の１つ以上の機能（例えば、データリアセンブリ、バッチ処理、負荷バランシ
ング）がパケットに提供され得ないことを示す。

【０２２８】 状態６０４において、ＦＤＢＭ１０８は、Ｎｏ＿Ａｓｓｉｓｔ信号が、パケッ
トに対してアサートされるかどうかを判定する。パケットに対してアサートされ
る場合、プロシージャは状態６６８（図６Ｅ）に進む。そうでない場合、状態６
０６において、ＦＤＢＭ１０８はＦＤＢ１１０を検索して、パケットのフローキ
ーを捜す。本発明の１実施形態において、フローデータベースの有効なフローエ
ントリのみが検索される。これまでで議論されたように、フローの有効性は、フ
ロー有効性インジケータ５２０（図５に示される）を例とする有効性インジケー
タによって反映され得る。状態６０８において、パケットフローキーがデータベ
ースで見つけられない、または一致はするが、関連付けられたフローが無効であ
ることを判定する場合、プロシージャは状態６４６（図６Ｄ）に進む。

【０２２９】 有効な一致が、フローデータベースで見つけられる場合、状態６１０において
、一致するフローのフロー番号（例えば、一致するエントリのフローデータベー
スインデックス）が記され、ＦＤＢ１１０に格納されるフロー情報が読まれる。
例示的に、この情報はフロー有効インジケータ５２０、フローシーケンス番号５
２２およびフロー活動インジケータ５２４（図５に示される）を含む。

【０２３０】 状態６１２において、ＦＤＢＭ１０８は、ヘッダーパーサ１０６から受け取ら
れる情報からパケットがＴＣＰペイロードデータを含むかどうかを判定する。パ
ケットがＴＣＰペイロードデータを含まない場合、示されるプロシージャは状態
６３８（図６Ｃ）に進む；そうでなければ、プロシージャは状態６１４に続く。

【０２３１】 状態６１４において、フローデータベースマネージャは、パケットが通信接続
またはフローを再設定する試行を構成するかどうかを判定する。例示的には、こ
れは、パケットプロトコルヘッダー（例えば、ＴＣＰヘッダー）の１つにおける
ＳＹＮビットの状態を検査することによって判定され得る。本発明の１実施形態
において、１つ以上の制御またはフラグビット（例えば、ＳＹＮビット）の値が
、ヘッダーパーサによってＦＤＢＭに提供される。当業者が認識するように、１
ＴＣＰエンティティは別のエンティティとの通信フローまたは接続を再設定し（
例えば、エンティティのホストコンピュータの１つの問題のため）、再接続リク
エストと共に第１のデータ部を送ることを試み得る。これは、状態６１４におい
て、フローデータベースマネージャが識別しようとする状況である。パケットが
負Ｒ−または接続の再接続または再設定の試行の一部である場合、プロシージャ
は状態６３０で続行する（図６Ｃ）。

【０２３２】 状態６１６において、フローデータベースマネージャ１０８は、パケットヘッ
ダーから取り出されるシーケンス番号（例えば、ＴＣＰシーケンス番号）とこの
フローに対して予想される次のデータ部のシーケンス番号（例えば、図５のフロ
ーシーケンス番号５２２）とを比較する。例示的に、パケットがフローの次のデ
ータ部を含む場合、これらのシーケンス番号は相関があるべきである。シーケン
ス番号が一致しない場合、プロシージャは状態６２８で続く。

【０２３３】 状態６１８において、ＦＤＢＭ１０８は、１つ以上のパケットプロトコルヘッ
ダーから抽出される一定のフラグが予想された値と一致するかどうかを判定する
。例えば、本発明の１実施形態において、パケットのＴＣＰヘッダーからのＵＲ
Ｇ、ＰＳＨ、ＲＳＴおよびＦＩＮフラグはクリアされる（すなわち、０に等しい
）と予想される。任意のこれらのフラグが設定される（例えば、１に等しい）場
合、例外的な条件が存在し得る。従って、ＮＩＣ１００によって提出される１つ
以上の機能（例えば、データリアセンブリ、バッチ処理、負荷分散）はこのパケ
ットについては実行されるべきでないようにすることが可能になる。フラグがク
リアである限り、プロシージャは、状態６２０で続く；フラグがクリアでない場
合、プロシージャは、状態６２６で続く。

【０２３４】 状態６２０において、フローデータベースマネージャは、より多くのデータが
、このフローの間、予想されるかどうかを判定する。これまでに議論したように
、フローは、期間が１つのデータグラムに制限され得る。それゆえ、状態６２０
で、ＦＤＢＭは、このパケットがこのフローデータグラムにとって最終のデータ
部であるように見えるかどうかを判定する。例示的には、この判定は、現在のパ
ケットに含まれるデータ量を基礎にして為される。当業者が理解するように、１
パケットで運ばれ得るより多くのデータを含むデータグラムは、複数のパケット
により送られる。複数のパケットの間にデータグラムを配置する（ｄｉｓｓｅｍ
ｉｎａｔｅ）一般的な方式は、各パケットに可能な限り多くのデータを置くこと
である。従って、最後のパケットを除く各パケットは、パケットが送られるネッ
トワークに許容される最大伝送単位（ＭＴＵ）に常に等しい、またはほぼ等しい
。最後のパケットは残りを保持し、これによって通常、そのサイズはＭＴＵより
小さくなる。

【０２３５】 それゆえ、フローのデータグラムにおける最終データ部を識別する１つの方式
は、各パケットのサイズを検査し、それを最後のデータ部を運ぶ場合以外にはパ
ケットが超えると予想される数量（例えば、ＭＴＵ）と比較することである。制
御情報はヘッダーパーサ１０６からＦＤＢＭ１０８によって受け取られることが
これまでに説明された。パケットにより運ばれたデータのサイズの表示は、この
情報に含まれ得る。特に、本発明の１実施形態において、ヘッダーパーサ１０６
は、各パケットのデータ部のサイズを予め選択された値と比較するように構成さ
れる。本発明の１実施形態において、この値はプログラム可能である。この値は
、本発明の例示的な実施形態において、ＭＴＵを超えずにパケットが運ぶことが
可能であるデータ最大量に設定される。別の１実施形態において、その値は、運
び得るデータ最大量より幾分少ない量に設定される。

【０２３６】 従って、状態６２０において、フローデータベースマネージャ１０８は、受け
取られたパケットが、フローのデータグラムについて、最終データ部を運ぶよう
に見えるかどうかを判定する。最終データを運ぶように見えない場合、プロシー
ジャは状態６２６に続く。

【０２３７】 状態６２２において、パケットは予め選択されたプロトコルと互換性があり、
ＮＩＣ１００によって提供される１つ以上の機能に適切であることが確認される
。特に、パケットは、これまで議論された１つ以上の機能に適切にフォーマット
されている。ＦＤＢＭ１０８は、受け取られるパケットは現存してるフローの一
部であるか、予め選択されたプロトコルと互換性があるか、フローについて次の
データ部（最終部ではない）を含むかを判定した。その上、パケットがフロー／
接続を再設定する試行の一部でなく、重要なフラグは予想された値を有する。従
って、フローデータベース１１０は以下のように更新され得る。

【０２３８】 このフローに対する活動インジケータ（例えば、図５のフロー活動インジケー
タ５２４）は、最新のフロー活動を反映するように変更される。本発明の１実施
形態において、フロー活動インジケータ５２４は、カウンタとして実行されるか
、カウンタと関連する。カウンタはデータがフローで受け取られる毎にインクリ
メントされる。本発明の別の実施形態において、活動インジケータまたはカウン
タは、有効なフローに一致する（例えば、パケットがデータを含むかどうか）フ
ローキーを有するパケットが受け取られる毎に、更新される。

【０２３９】 例示的な実施形態において、フロー活動インジケータまたはカウンタがインク
リメントされた後、０に「ローリングオーバー（ｒｏｌｌｅｄ ｏｖｅｒ）」し
たかどうか（すなわち、その最大値を超えてインクリメントされたかどうか）の
判定が検査される。ゼロにローリングオーバーした場合、フローデータベース１
１０の各エントリに対するカウンタおよび／またはフロー活動インジケータは０
に設定され、現在のフローの活動インジケータは、再度インクリメントされる。
従って、本発明の１実施形態において、フロー活動カウンタまたはインジケータ
のローリングオーバーにより、フローデータベース１１０についてフロー活動機
構の再初期化が引き起こされる。その後、カウンタはインクリメントされ、フロ
ー活動インジケータは、前に説明したように再度更新される。当業者は、一つの
フローが他のフローより、より最近にアクティブであったことを示すために本発
明の実施形態で適用され得る多くの他の適切な方法があることを認識する。

【０２４０】 さらに状態６２２において、フローシーケンス番号５２２は更新される。例示
的には、新しいフローシーケンス番号は、新しく受け取られたデータのサイズを
既存のフローシーケンス番号に加えることによって決定される。パケットの構成
（例えば、そのヘッダーの値）に依存して、この合計は調整される必要がある。
例えば、この合計は、フローデータグラムについて、それまでに受け取られたデ
ータ量全体を単に示し得る。それゆえ、値は、データグラムについてのデータの
次のバイトのシーケンス番号を示すように（例えば、１バイトが）加えられる必
要があり得る。当業者が理解するように、データが順番に受け取られることを確
実にする他の適切な方法は、このコンテクストで説明されるスキームの代わりに
使用され得る。

【０２４１】 最後に、状態６２２で、本発明の１実施形態において、フロー有効インジケー
タ５２０はフロー有効性を示すように設定または再設定される。

【０２４２】 次いで、状態６２４では、オペレーションコードはパケットに関連する。本発
明の例示的な実施形態において、オペレーションコードは、フローデータベース
マネージャ１０８によって生成され、制御キュー１１８に格納されるコードを含
む。この実施形態において、オペレーションコードは、サイズにして３ビットで
あり、これによって８つのオペレーションコードを許容する。オペレーションコ
ードは、別の実施形態において様々な他の形式および範囲を有し得る。本発明の
例示的な実施形態に対して、表１は、各コード選択およびその選択の分岐に導く
判定基準という点で、各オペレーションコードを説明する。表１の目的に対して
、フローの設定は、フローデータベース１１０にフローを挿入することを含む。
フローを壊すことは、フローデータベース１１０のフローを除去または無効にす
ることを含む。データのリアセンブリは、ＤＭＡエンジン１２０を説明する次の
セクションで議論される。

【０２４３】 本発明の例示的な実施形態において、オペレーションコード４は、本明細書中
のプロシージャで、パケット（例えば、次の最後ではないフローのデータ部を運
ぶ互換性のあるパケット）について状態６２４で選択される。従って、既存のフ
ローは壊されず、新しいフローを設定する必要はない。前に説明されたように、
この実施形態において互換性のあるパケットは、１つ以上の予め選択されたプロ
トコルに適合するパケットである。予め選択されたプロトコルを変えるまたは強
化することによって、実際、任意のパケットは、本発明の別の実施形態において
互換性があり得る。

【０２４４】 図６Ａ〜６Ｅを参考にして、状態６２４の後で、示されたプロシージャは、状
態６７０で終了する。

【０２４５】 状態６２６（状態６１８または状態６２０から達する）で、オペレーションコ
ード３はパケットに対して選択される。例示的には、オペレーションコード３は
パケットが互換性があり、有効なフローと一致する（例えば、パケットのフロー
キーは、ＦＤＢ１１０の有効なフローのフローキーと一致する）ことを示す。オ
ペレーションコード３はまた、パケットがデータを含み、通信フロー／接続を再
同期または再設定する試行を構成せず、パケットのシーケンス番号が（フローデ
ータベース１１０からの）予想されたシーケンス番号に一致することを示し得る
。しかし、重要なフラグ（例えば、ＴＣＰフラグのＵＲＧ、ＰＳＨ、ＲＳＴまた
はＦＩＮのうちの１つ）が設定される（状態６１８で判定される）、またはパケ
ットのデータが（状態６２０で）前に説明された閾値より少ないかのどちらかで
あり、これによって、これ以上のデータは、多分このフロー中のこのパケットに
続きそうにないことを示す。それゆえ、既存のフローは壊されるが、新しいフロ
ーは作成されない。例示的に、フローはフローの有効性インジケータをクリアす
る（例えば、０へ設定する）ことによって壊され得る。状態６２６の後、例示的
なプロシージャは状態６７０で終了する。

【０２４６】 状態６２８（状態６１６から達する）において、オペレーションコード２はパ
ケットに対して選択される。このコンテクストにおいて、オペレーションコード
２は、パケットが互換性があり、有効なフローに一致し（例えば、パケットのフ
ローキーはＦＤＢ１１０の有効フローのフローキーと一致する）、データを含み
、通信フロー／接続を再同期または再設定する試行を構成しないことを示し得る
。しかし、（状態６１６において）パケットから抽出されるシーケンス番号は、
フローデータベース１１０からの予想されたシーケンス番号に一致しない。これ
は、例えば、パケットが無秩序に受け取られる場合に生じ得る。従って、既存の
フローは壊されるが、新しいフローは確立されない。例示的に、フローは、フロ
ーの有効性インジケータをクリアする（例えば、０へ設定する）ことによって壊
され得る。状態６２８の後で、例示的なプロシージャが状態６７０で終了する。

【０２４７】 状態６３０には、受け取られるパケットが通信フローまたは接続を再設定する
（例えば、ＴＣＰ ＳＹＮビットが設定される）試行を構成することが判定され
る場合、状態６１４から入ってくる。状態６３０で、フローデータベースマネー
ジャ１０８はさらに多くのデータが続くと予想されるかどうかを判定する。状態
６２０に関連して説明されるように、この判定は、ヘッダーパーサからのフロー
データベースマネージャによって受け取られる制御情報に基づいて、為され得る
。さらに多くのデータが予想される（例えば、パケットのデータ量が閾値に等し
いかまたは超える）場合、プロシージャは状態６３４で続く。

【０２４８】 状態６３２で、オペレーションコード２はパケットに選択される。オペレーシ
ョンコード２はまた、別のコンテクストにおいて状態６２８で選択された。現在
のコンテクストにおいて、オペレーションコード２は、パケットは互換性があり
、有効なフローに一致し、データを含むことを示し得る。オペレーションコード
２はまた、このコンテクストにおいてパケットが通信フローまたは接続を再同期
または再設定する試行を構成することを示し得るが、一旦、フロー／接続が再設
定されると、さらに多くのデータが予想されないことを示し得る。それゆえ、既
存のフローは壊され、新しいフローは確立されない。例として、フローは、フロ
ーの有効性インジケータをクリアにする（例えば、０に設定する）ことによって
壊され得る。状態６３２の後で、示されたプロシージャは状態６７０で終了する
。

【０２４９】 状態６３４で、フローデータベースマネージャ１０８は、通信フロー／接続を
再設定または再同期する試行に応答し、それにより付加的なデータが予想される
。従って、既存のフローは、以下のように壊され、取り替えられる。既存のフロ
ーは状態６１０で取り出されるフロー番号またはパケットのフローキーによって
識別され得る。フローのシーケンス番号（例えば、図５のフローシーケンス番号
５２２）は次の予想された値に設定される。例示的には、この値は、パケットか
ら（例えば、ヘッダーパーサ１０６によって）取り出されたシーケンス番号（例
えば、ＴＣＰシーケンス番号）およびパケットに含まれるデータ量に依存する。
本発明の１実施形態において、これらの２つの値は加えられ、新しいフローシー
ケンス番号を判定する。以前に議論したように、この合計は（例えば、１を加え
ることによって）調整される必要があり得る。状態６３４においてまた、フロー
活動インジケータは更新される（例えば、インクリメントされる）。状態６２２
に関連して説明されるように、フロー活動インジケータがローリングオーバーす
る場合、データベースにある全てのフローについての活動インジケータは０に設
定され、現在のフローは再度インクリメントされる。最後に、フロー有効インジ
ケータは、フローが有効であると示すように設定される。

【０２５０】 状態６３６で、オペレーションコード７はパケットに対して選択される。この
コンテクストにおいて、オペレーションコード７はパケットが互換性を有し、有
効フローに一致し、データを含むことを示す。オペレーションコード７は、この
コンテクストにおいて、パケットが通信フロー／接続を再同期または再設定する
試行を構成し、フロー／接続が一旦再設定されると、付加的なデータは予想され
ることをさらに示し得る。事実上、それゆえ、既存のフローは壊され、（同じフ
ローキーを備える）新しいフローは、その場所に格納される。状態６３６の後で
、示されたプロシージャは終了状態６７０で終了する。

【０２５１】 受け取られたパケットがデータを含まないと判定される場合、状態６１２の後
で状態６３８に入る。これは、パケットが制御パケットであることをしばしば示
す。状態６３８で、フローデータベースマネージャ１０８は、ヘッダーパーサに
よってパケットから抽出された１つ以上のフラグが予想されたまたは望まれた値
に一致するかどうかを判定する。例えば、本発明の１実施形態において、ＤＭＡ
エンジン１２０が複数の関連付けられたパケット（例えば、同一のフローキーを
有するパケット）からデータをリアセンブルするために、ＴＣＰフラグのＵＲＧ
、ＰＳＨ、ＲＳＴ、ＦＩＮはクリアである必要がある。前に議論されたように、
ＴＣＰ ＳＹＮビットもまた、検査され得る。このコンテクスト（例えば、デー
タのないパケット）において、ＳＹＮビットもまた、クリアである（例えば、０
の値を格納する）と予想され得る。フラグ（およびＳＹＮビット）が予想された
値を有する場合、プロシージャは、状態６４２で続く。しかし、これらのフラグ
のうち任意のものが設定されている場合、例外的な条件が存在し得、従ってＮＩ
Ｃ１００により提供される１つ以上の機能（例えば、データリアセンブリ、バッ
チ処理、負荷分散）はこのパケットに不適切であり、その場合は、プロシージャ
が状態６４０に進むことが可能になる。

【０２５２】 状態６４０において、オペレーションコード１が、パケットについて選択され
る。例示的に、オペレーションコード１は、パケットが互換性を有し、有効フロ
ーと一致するが、任意のデータを含まないこと、およびパケットヘッダー（単数
または複数）の１以上の重要なフラグまたはビットが設定されることを示す。従
って、既存のフローは壊され、新規のフローは構築されない。例示的に、フロー
の有効インジケータをクリアにすること（例えば、有効インジケータを０に設定
すること）により、フローは壊され得る。状態６４０の後、図示されたプロシー
ジャは、終了状態６７０で終了する。

【０２５３】 状態６４２において、パケットがデータを含まなくとも、フローの活動インジ
ケータが更新（例えば、インクリメント）される。状態６２２と共に上記したよ
うに、活動インジケータがロールオーバする場合、本発明の本実施形態において
、データベースのフロー活動インジケータ全てが０に設定され、現在のフローが
再びインクリメントされる。フローの有効インジケータおよびフローのシーケン
ス番号はまた、リセットされ得る。

【０２５４】 状態６４４において、オペレーションコード０が、パケットについて選択され
る。例示的に、オペレーションオード０は、パケットが互換性を有し、有効フロ
ーと一致すること、およびパケットが任意のデータを含まないことを示す。例え
ば、パケットは制御パケットであり得る。オペレーションコード０はさらに、ヘ
ッダーパーサ１０６によりチェックされ、上記された（例えば、ＵＲＧ、ＰＳＨ
、ＲＳＴ、およびＦＩＮ）のようなフラグのいずれもが設定されないことを示す
。従って、既存のフローは壊されず、新規のフローは構築されない。状態６４４
の後、図示されたプロシージャは、終了状態６７０で終了する。

【０２５５】 パケットフローキーが、フローデータベースの有効フローのフローキーのうち
のいずれとも一致しない場合、状態６４６には状態６０８から入る。状態６４６
において、ＦＤＢＭ１０８は、フローデーベース１１０がフルであるかどうかを
判定し、データベースがフルであるかどうかを示す何らかの指示情報を保存し得
る。本発明の１実施形態において、有効インジケータ（例えば、図５のフロー有
効インジケータ５２０）が、あらゆるフロー番号について（例えば、データベー
スのあらゆるフローについて）設定される場合に、フローデータベースがフルで
あるとみなされる。データベースがフルであると、プロシージャは状態６５０へ
続き、さもなければ状態６４８へ続く。

【０２５６】 状態６４８において、無効フローの最も低いフロー番号（例えば、関連フロー
有効インジケータが０に等しいフロー）が判定される。例示的に、このフロー番
号は、受け取られたパケットが新規のフローの作成を許可する場合、新規のフロ
ーが格納され得る場所である。

【０２５７】 状態６５０において、最も古いアクティブフローのフロー番号が決定される。
上記のように、本発明の例示的実施形態において、データがフローについて受け
取られるごとにフロー活動インジケータ（例えば、図５のフロー活動インジケー
タ５２４）が更新される（例えば、インクリメントされる）。従って、この実施
形態において、最も古いアクティブフローは、最古く更新された（例えば、最も
低い）フロー活動インジケータを有するフローとして識別され得る。例示的に、
複数のフローが共通値（例えば、０）に設定されるフロー活動インジケータを有
する場合、１つのフロー番号がランダムに選択され得るか、または他の何らかの
基準により複数のフローから選択され得る。状態６５０後、このプロシージャは
状態６５２に続く。

【０２５８】 状態６５２において、フローデータベースマネージャ１０８は、パケットがデ
ータを含むかどうかを判定する。例示的に、ヘッダーパーサがＦＤＢＭ１０８に
提供する制御情報は、パケットがデータを有するかどうかを示す。パケットがデ
ータを含まない場合（例えば、パケットが制御パケットの場合）、例示的プロシ
ージャは、状態６６８に続く。

【０２５９】 状態６５４において、フローデータベースマネージャ１０８は、現在のパケッ
トとともに受け取られたデータが、関連データグラム／フローについてデータの
最終部を含むことが明らかかどうかを判定する。状態６２０と共に記載されたよ
うに、この判定はパケットとともに含まれるデータ量に基づいて為され得る。デ
ータ量が閾値（図示された実施形態のプログラマブル値）よりも少ない場合デー
タが全く期待されず、このことはこのフローについてのデータのみであり得る。
この場合、プロシージャは状態６６８に続く。しかしながら、データが閾値に到
達するか、または閾値を超えた場合（この場合、より多くのデータが期待され得
る）、プロシージャは状態６５６に進む。

【０２６０】 状態６５６において、特定のフラグの値が調べられる。例えば、これらのフラ
グは、ＴＣＰヘッダーのＵＲＧ、ＰＳＨ、ＲＳＴ、ＦＩＮビットを含み得る。調
べられたフラグのいずれもが、それらの期待値、または所望の値を有さない場合
（例えば、フラグのいずれもが設定される場合）、このパケットについて、ＮＩ
Ｃ１００の１以上の機能（例えば、データアセンブリ、バッチ処理、負荷分散）
を不適切にする例外的な状態が存在し得る。この場合、プロシージャは状態６６
８に続き、さもなければ、プロシージャは状態６５８に進む。

【０２６１】 状態６５８において、フローデータベースマネージャは、フローデータベース
１１０がフルであるかどうかに関する、状態６４６に格納された情報を取り出す
。データベースがフルである場合、プロシージャは状態６６４に続き、さもなけ
れば、プロシージャは状態６６０に進む。

【０２６２】 状態６６０において、新規のフローが、現在のパケット用にフローデータベー
ス１１０に付加される。例示的に、新規のフローは、状態６４８で識別されたか
、または取り出されたフロー番号に格納される。新規のフローの付加は、シーケ
ンス番号（例えば、図５からのフローシーケンス番号５２２）を設定することを
含み得る。フローシーケンス番号５２２は、パケットから取り出されたシーケン
ス番号（例えば、ＴＣＰシーケンス番号）とパケットに含まれるデータ量とを付
加することにより生成され得る。上述されたように、この和は（例えば、１を加
えることによって）調整される必要があるかもしれない。

【０２６３】 新規のフローの格納は、活動インジケータ（例えば、図５のフロー活動インジ
ケータ５２４）を初期化する工程もまた包含し得る。本発明の１実施形態におい
て、この初期化は、データがフローについて受け取られるごとにインクリメント
されるカウンタから取り出される値を格納する工程を包含する。例示的に、カウ
ンタまたはフロー活動インジケータが格納可能な最大値を過ぎてインクリメント
される場合、カウンタおよびフロー活動インジケータ全体はクリアにされるか、
またはリセットされる。また、状態６６０において、有効インジケータ（例えば
、図５のフロー有効インジケータ５２０）は、フローが有効であることを示すた
めに設定される。最後に、パケットフローキーはまた、フローデータベース内の
、割り当てられたフロー番号に対応するエントリに格納される。

【０２６４】 状態６６２において、オペレーションコード６は、パケットについて選択され
る。例示的に、オペレーションコード６は、パケットが互換性を有し、いずれの
有効フローとも一致せず、新規のフローについてデータの先頭部を含むことを示
す。さらに、パケットのフラグが、それらの期待値、または必要とする値を有し
、追加のデータがフローで期待され、フローデータベースはフルにならない。従
って、オペレーションコード６は、壊すような既存のフローが存在しないこと、
および新規のフローがフローデータベースに格納されていることを示す。状態６
６２後、図示されたプロシージャは状態６７０で終了する。

【０２６５】 状態６６４において、フローデータベースの既存のエントリが置き換えられ、
それにより、現在のパケットによって開始される新規のフローが格納され得る。
従って、状態６５０で識別される最も古いアクティブフローのフロー番号が取り
出される。このフローは以下のように置き換えられ得る。既存のフローのフロー
シーケンス番号（例えば、図５のフローシーケンス番号５２２）は、パケットか
ら抽出されたシーケンス番号（例えば、ＴＣＰシーケンス番号）を、パケットの
データ部のサイズと結合することで得られる値と置き換えられる。この合計は、
（例えば、１を付加することにより）調節される必要があり得る。次いで、既存
のフローの活動インジケータ（例えば、フロー活動インジケータ５２４）が置き
換えられる。例えば、フロー活動カウンタの値は、上記のようにフロー活動イン
ジケータにコピーされ得る。次いで、フロー有効インジケータ（例えば、図５の
フロー有効インジケータ５２０）は、フローが有効であることを示すように設定
される。最後に、新規のフローのフローキーが格納される。

【０２６６】 状態６６６において、オペレーションコード７がパケットについて選択される
。オペレーションコード７はまた、状態６３６で選択された。この文脈において
、オペレーションコード７は、パケットが互換性を有し、いずれの有効フローの
フローキーとも一致せず、新規のフローについてデータの第１の部分を含むこと
を示し得る。さらに、パケットのフラグが互換可能な値を有し、追加のデータが
フローで期待される。しかしながら、最後に、この文脈において、オペレーショ
ンコード７は、フローデータベースがフルであること、それにより既存のエント
リが壊されること、および新規のエントリをその場所に格納したことを示す。状
態６６６後、図示されたプロシージャは、終了状態６７０で終了する。

【０２６７】 状態６６８において、オペレーションコード５は、パケットについて選択され
る。状態６６８には、種々の状態から入り、従って、オペレーションコード５は
、多様な可能な状態または状況を表す。例えば、オペレーションコード５は、Ｎ
ｏ＿Ａｓｓｉｓｔ信号がパケットについて検出される（状態６０４において）場
合に選択され得る。上記のように、Ｎｏ＿Ａｓｓｉｓｔ信号は、対応するパケッ
トが先に選択されたプロトコルのセットと互換性がないことを示し得る。本発明
のこの実施形態において、非互換性パケットは、ＮＩＣ１００の種々の機能のう
ち１以上の機能（例えば、データリアセンブリ、バッチ処理、負荷分散）に対し
て不適格である。

【０２６８】 状態６６８はまた状態６５２から入ることができ、オペレーションコード５は
選択される。この場合、コードは、受け取られたパケットがいずれの有効フロー
キーとも一致せず、さらに、データを全く含まないこと（例えば、受け取られた
パケットが制御パケットであり得ること）を示し得る。

【０２６９】 状態６６８はまた、状態６５４から入ることができる。この文脈において、オ
ペレーションコード５は、パケットがいずれの有効フローキーとも一致しないこ
とを示し得る。さらに、オペレーションコード５は、パケットがデータを含むが
、データ部のサイズが、状態６５４と共に記載された閾値よりも小さいことを示
し得る。この文脈において、パケットデータが完全である（例えば、データグラ
ムに対するデータ全てを含む）ことが明らかであり、これは、このパケットのデ
ータを用いてリアセンブルする他のデータがないことを意味し、従って、この１
パケットフローについてのデータベースに新規のエントリを作成する理由がない
。

【０２７０】 最後に、状態６６８はまた、状態６５６から入ることができる。この文脈にお
いて、オペレーションコード５は、パケットがいずれの有効フローキーとも一致
せず、データを含むこと、およびより多くのデータが期待されるが、１以上のパ
ケットプロトコルヘッダーの少なくとも１つのフラグはその期待値を有さないこ
とを示し得る。例えば、本発明の１実施形態において、ＴＣＰフラグＵＲＧ、Ｐ
ＳＨ、ＲＳＴ、およびＦＩＮがクリアにされると予想される。これらフラグのう
ち任意のフラグが設定される場合、例外的な状況が存在し得る。従って、そのよ
うな例外的な状況によって、ＮＩＣ１００が提供する機能のうちの１つがこのパ
ケットについて不適切であることがおこり得る。

【０２７１】 表１が示すように、オペレーションコード５が選択される場合、壊すフローが
存在せず、新規のフローは構築されない。状態６６８の後、図示されたプロシー
ジャは状態６７０で終了する。

【０２７２】 当業者であれば、図６Ａ〜図６Ｅに示し、上記したプロシージャは、フローデ
ータベースを維持および更新するため、ならびに特定の処理機能についてパケッ
トの適合性を判定するための単なる１つの適切なプロシージャにすぎないことを
理解する。特に、異なるオペレーションコードが利用され得るか、または異なる
方法でインプリメントされ得、目的は、パケットのＮＩＣ１００を介した後の処
理のための情報を生成することである。

【０２７３】 図示されたプロシージャのフローデータベースマネージャは、オペレーション
コードを全てのパケットについて割り当てるが、代替のプロシージャにおいて、
ＦＤＢＭが割り当てるオペレーションコードは、ＮＩＣ１００の他のモジュール
により、置き換えられ得るか、または変更され得る。これはあるタイプのパケッ
トの特定の処理方法を保証するために、為され得る。例えば、本発明の１実施形
態において、ＩＰＰモジュール１０４は所定のオペレーションコード（例えば、
表１のオペレーションコード２）をジャンボパケット（例えば、ＭＴＵより大き
なサイズのパケット）に割り当て、それにより、ＤＭＡエンジン１２０はこれら
のパケットをリアセンブルし得ない。特に、ＩＰＰモジュールは、パケットがジ
ャンボパケットであることを独立して（例えば、ＭＡＣモジュールが提供する情
報から）判定し得、従って、所定のコードに割り当て得る。例示的に、ヘッダー
パーサ１０６およびＦＤＢＭ１０８は、ジャンボパケットについての標準機能を
実行し、ＩＰＰモジュール１０４は、ＦＤＢＭが割り当てる第１のオペレーショ
ンコードを受け取る。しかしながら、ＩＰＰモジュールは、ジャンボパケットお
よびパケットに関する情報を格納する前に、このコードを置き換える。代替の１
実施形態において、ヘッダーパーサ１０６および／またはフローデータベースマ
ネージャ１０８は、特定タイプの（例えば、ジャンボ）パケットを認識し、所定
のオペレーションコードを割り当てるように構成され得る。

【０２７４】 図６Ａ〜図６Ｅに図示された本発明の実施形態に適用されるオペレーションコ
ードが以下の表１に示され、説明される。表１は、各オペレーションコードを選
択するために使用された例示的基準、および各コードの例示的結果または効果を
含む。

【０２７５】

【表１】 （ロードディストリビュータの１実施形態） 本発明の１実施形態において、ロードディストリビュータ１１２は、それらの
プロトコルスタックを介してパケットの処理が多数のプロセッサの間に分散され
ることをイネーブルにする。例示的に、ロードディストリビュータ１１２は、パ
ケットが発信されるプロセッサの識別子（例えば、プロセッサ番号）を生成する
。複数のプロセッサは、ＮＩＣ１００が扱うホストコンピュータシステム内に位
置し得る。代替の１実施形態において、プロトコルスタックを介してパケットを
マニピュレートする１以上のプロセッサが、ＮＩＣ１００に位置付けされる。

【０２７６】 処理バードンを共有するか、または分散する効果的な方法を用いずに、ＮＩＣ
１００で受け取られる全てのまたは多くのネットワークトラフィックの処理が特
に高速ネットワーク環境において必要な場合、あるプロセッサはオーバローディ
ングとなり得る。ネットワークトラフィックの処理の結果として生じる遅延は、
ホストコンピュータシステムおよびネットワークを介しホストシステムと通信を
行う他のコンピュータシステム上のオペレーションを劣化させ得る。

【０２７７】 当業者が理解し得るように、（例えば、ラウンドロビンスキームのような）プ
ロセッサのセットのプロセッサ間で、単にパケットを分散させることが、効率の
良い方式であり得ない。このような方式は、パケットが無秩序に処理されること
を容易に引き起こし得る。例えば、ネットワークインターフェースにて正しい順
番で受け取られる１つの通信フローまたは接続からの２つのパケットが、２つの
異なるプロセッサに発信された場合、第２のパケットは第１のパケットより前に
処理され得る。例えば、第１のパケットを受け取るプロセッサが他のタスクでビ
ジーな状態であるという理由で、そのプロセッサが、直ちにパケットを処理し得
ない場合、このことが発生し得る。パケットが無秩序に処理される場合、回復ス
キームは概して初期化されなければならず、従って、なおさら非効率的となり、
さらなる遅れをもたらす。

【０２７８】 従って、本発明の本実施形態において、パケットは、自身のフロー指示情報に
基づく複数のプロセッサ間に分散される。上記のように、ヘッダーパーサは、レ
イヤー３（例えば、ＩＰレイヤー）およびレイヤー４（例えば、ＴＣＰレイヤー
）ソースからフローキーを生成し得、パケットヘッダーから受け取られる宛先識
別子を生成し得る。フローキーは、パケットが属する通信フローを識別するため
に使用され得る。従って、本発明のこの実施形態において、同一のフローキーを
有するパケット全てが、単一のプロセッサに発信される。ＮＩＣ１００により順
番にパケットが受け取られる限り、それらのパケットは、ホストコンピュータに
供給され、パケットに割り当てられたプロセッサにより順番に処理されるはずで
ある。

【０２７９】 例示的に、パケットのレイヤー３およびレイヤー４の識別子が同一のフローキ
ーを維持する限り、たとえパケットが別のデータグラムの一部であっても、ある
ソースエンティティからある宛先エンティティに送られる複数のパケットは、同
一のフローキーを有し得る。上記のように、あるＴＣＰエンドゥエンド接続内で
、個々のフローがセットアップされ、各データグラムについて壊される。従って
、あるフロー内の全パケットがあるプロセッサに送られるとすぐに、ＴＣＰエン
ドゥエンド接続内の全パケットもまた、同一のプロセッサに送られ得る。このこ
とが、データグラム間でさえパケットの正しい順番を全接続に対して保証する助
けとなる。

【０２８０】 ＮＩＣ１００が動作するネットワーク環境（例えば、ネットワーク１０２によ
りサポートされるプロトコル）に依存して、フローキーは大きすぎてプロセッサ
の識別子として使用出来ない。例えば、上記の発明の１実施形態において、例え
ばフローキーは２８８ビットである。一方、ロードバランススキームに加わるプ
ロセッサ数は非常に小さくなり得る。例えば、図７と共に以下に記載される発明
の実施形態において、最大６４のプロセッサがサポートされる。従って、この実
施形態において、６ビット数のみが選択されたプロセッサを識別するために必要
とされる。従って、より大きなフローキーが、より小さな範囲の値中にマッピン
グされ得るか、またはハッシュされ得る。

【０２８１】 パケットフローキーに基づき、ＮＩＣ１００が受け取るパケットを処理するプ
ロセッサを特定する識別子（例えば、プロセッサ番号）を生成する１つの方法を
、図７に示す。本発明のこの実施形態において、ネットワーク１０２はインター
ネットであり、受け取られたパケットは、互換性を有するプロトコルスタック（
例えば、レイヤー２のイーサネット（登録商標）、レイヤー３のＩＰ、およびレ
イヤー４のＴＣＰ）に従い、フォーマットされる。

【０２８２】 状態７００は開始状態である。状態７０２において、パケットはＮＩＣ１００
により受けとられ、パケットのヘッダー部は、ヘッダーパーサ１０６により構文
解析される（パケット解析方法は先のセクションに記載されている）。状態７０
４において、ロードディストリビュータ１１２はヘッダーパーサ１０６により生
成されたパケットフローキーを受け取る。

【０２８３】 パケットフローキーは、この実施形態において２８８ビット長であるので、状
態７０６において、ハッシング機能が、大きさのより小さな値を生成するために
実行される。例えば、ハッシュオペレーションは、ＡＴＭ（非同期伝送モード）
アダプテーションレイヤー５（ＡＡＬ５）のような３２ビットのＣＲＣ（反復冗
長性チェック）機能を含み得る。ＡＡＬ５は、２³²の可能な値の間にかなり均一
に分散された３２ビット数を生成する。ハッシングの他の適切な方法は、標準イ
ーサネット（登録商標）ＣＲＣ３２機能である。比較的小さな数を比較的大きな
フローキーから生成することが可能な他のハッシュ機能はまた、生成した数が値
の範囲間に良好に分散される場合には、適切である。

【０２８４】 結果として生成されたハッシュ値を用いて、状態７０８において、モジュール
オペレーションは、処理を分散させるか、または共有させることに利用可能なプ
ロセッサの数に対して実行される。例示的に、ホストコンピュータ（例えば、Ｎ
ＩＣ１００に関するデバイスドライバ）で実行するソフトウェアはプロセッサ数
をプログラムするか、または格納し、それにより、ソフトウェアは、（例えば、
レジスタにおいて）ロードディストリビュータ１１２により読み出すか、または
取り出され得る。ロードバランシングについて利用可能なプロセッサの数は、ホ
ストコンピュータシステムに組込まれたプロセッサの数の全てか、またはそのサ
ブセットであり得る。図示された実施形態において、ホストコンピュータシステ
ムで利用可能なプロセッサの数は、最大値の６４を用いて、プログラマブルであ
る。従って、この実施形態のモジュラスオペレーションの結果は、パケットが処
理のために発信されるプロセッサの数（例えば、０〜６３）である。本発明のこ
の実施形態において、ロードディストリビュータ１１２は、ハードウェア上で実
行され、従って、ハッシュ関数およびモジュラス関数の高速実行を可能にする。
本発明の代替の実施形態において、実質的に任意の数のプロセッサが適応され得
る。

【０２８５】 状態７１０において、プロトコルスタックを介してパケットを処理するプロセ
ッサの数は、ホストコンピュータのメモリに格納される。例示的に、状態７１０
は、ホストメモリバッファのパケットの格納と平行して実行される。本発明の１
実施形態において、ホストコンピュータメモリ内の記述子リングは、プロセッサ
番号および可能ならばパケットに関する他の情報（例えば、サイズ、ＴＣＰチェ
ックサム、パケットへのポインタ）を保持するために構築される。

【０２８６】 この実施形態において記述子リングは、ネットワークインターフェース回路の
ホストコンピュータシステムが使用する情報を格納するための複数のエントリ、
または「記述子」の数を含むデータ構造である。図示された実施形態において、
パケットがＮＩＣ１００により受け取られた後であるが、パケットがホストコン
ピュータシステムにより処理される前に、記述子は一時的にパケット情報を格納
する。例えば、記述子に格納される情報は、ＮＩＣ１００に関するデバイスドラ
イバにより、またはプロトコルスタックを介してパケットを処理するために使用
され得る。

【０２８７】 状態７１２において、新規のパケットがＮＩＣ１００から送達されたことをホ
ストコンピュータに知らせるために、割り込みまたは他の警告がホストコンピュ
ータに発行される。ＮＩＣ１００がＰＣＩ（周辺部品相互接続）バスによりホス
トコンピュータに接続される本発明の実施形態において、ＩＮＴＡ信号がバスを
介してアサートされ得る。ホストのＰＣＩコントローラは信号を受け取り、ホス
トオペレーティングシステムが（割り込みによって）警告される。

【０２８８】 状態７１４において、ホストコンピュータ上で動作するソフトウェア（例えば
、ＮＩＣ１００に関するデバイスドライバ）が（例えば、ホストコンピュータの
オペレーティングシステムの割り込みハンドラにより）呼び出され、新規に受け
取られたパケットに作用する。ソフトウェアは、記述子リングの１以上の記述子
から情報を収集し、各新規のパケットの処理を達成するために必要とされる情報
を、（すなわち、パケットの記述子に格納されたプロセッサ番号に従い）特定プ
ロセッサのキューに配置する。例示的に、各記述子は別個のパケットに対応する
。各パケットについて、プロセッサのキューに格納された情報は、パケット、パ
ケットのＴＣＰチェックサム、１以上のプロトコルヘッダーのオフセット等を含
むバッファへのポインタを含み得る。さらに、負荷分散スキームに関与する各プ
ロセッサは、ネットワークパケットを処理するための関連するキューを有し得る
。本発明の代替の実施形態において、複数のキューが（例えば、複数の優先レベ
ルまたは異なるプロトコルスタックに対して）使用され得る。

【０２８９】 例示的に、ホストコンピュータシステムの１プロセッサは、ＮＩＣ１００から
のネットワークパケットの受け取りに関連する全警告および／または割り込みを
受け取るため、および適切なソフトウェアルーチンまたはデバイスドライバに警
告を出すために構成される。あるいは、この最初の処理は複数のプロセッサの間
で分散される。さらに、本発明の１実施形態において、記述子コンテンツの取り
出しおよびマニピュレーション部は、新規のパケットが記述子リングに格納され
る時に発生される割り込みの処理の一部として実行される。パケットを処理する
ために選択されるプロセッサは、残りの取り出し／マニピュレーションプロシー
ジャを実行し得る。

【０２９０】 状態７１６において、新規のパケットを処理するために設計されるプロセッサ
は警告されるか、または呼び起こされる。Ｓｏｌａｒｉｓ^TMワークステーション
で動作する本発明の実施形態において、プロセッサにより実行される各プロセス
は、「スレッド」として構成される。ワークステーション上で実行する他のプロ
セスへのインパクトが最小となるように、スレッドは（例えば、割り込みレベル
ではなく）標準モードで実行するプロセスである。しかしながら、標準モードプ
ロセスは高い優先度で実行し得る。あるいは、スレッドは比較的低い割り込みレ
ベルにおいて実行し得る。

【０２９１】 入来するパケットを処理する原因となるスレッドは、処理するパケットが存在
しない場合にスレッド自身をブロックし得、すべき作業がある場合、呼び起こさ
れ得る。「状態変数」はスレッドが処理するパケットを有するかどうかを示すた
めに使用され得る。例示的に、スレッドがパケットを処理する場合（例えば、プ
ロセッサが処理するためのパケットを受け取る場合）、状態変数は第１の値に設
定され、処理するパケットがもはや存在しない場合、第２の値に設定される。本
発明の図示された実施形態において、ある状態変数は、各プロセッサのキューと
関連し得る。

【０２９２】 代替の実施形態において、示されるプロセッサは、「クロスプロセッサコール
」により状態７１６で警告される。クロスプロセッサコールは、プロセッサの間
の通信の１方法であり、これにより、あるプロセッサは他のプロセッサにより、
遠隔的に割り込まれる。あるプロセッサが他のプロセッサに警告するか、または
他のプロセッサへの処理をディスパッチする他の方法が、スレッドおよびクロス
プロセッサコールの代わりに使用され得る。

【０２９３】 状態７１８において、選択されたプロセッサ上のスレッドまたは他のプロセス
は、プロセッサのキューに格納されたパケットを処理し始める。パケットのプロ
トコルスタックを介してパケットを処理する方法は、当業者に公知であり、詳細
に記載する必要はない。次いで、図示されたプロシージャは終了状態７２０で終
了する。

【０２９４】 本発明の代替の１実施形態において、高速ネットワークインターフェースが、
ＡＴＭ（非同期伝送モード）トラフィックを受け取るため、および処理するため
に構成される。この実施形態において、ロードディストリビュータがハードウェ
アモジュールとしてよりも、命令のセット（例えば、ソフトウェア）として実行
される。当業者が理解するように、ＡＴＭトラフィックは接続元であり、パケッ
トのソースエンティティと宛先エンティティとの間で構築される仮想回路に対応
する仮想接続識別子（ＶＣＩ）により識別され得る。仮想回路部の一部である各
パケットはＶＣＩをヘッダーに含む。

【０２９５】 利点として、ＶＣＩは比較的小さなサイズ（例えば、１６ビット）を有する。
従って、この代替の実施形態においてパケットのＶＣＩは、パケットのプロトコ
ルスタックを介してパケットを処理する負荷を分散させるか、または共有させる
目的のために、フローキーの代わりに使用され得る。例示的に、異なるＶＣＩか
らのトラフィックは異なるプロセッサに送られるが、パケットの正しい順番を保
証するために、同様のＶＣＩを有する全パケットが同様のプロセッサに送られる
。ＡＴＭパケットがネットワークインターフェースで受け取られる場合、ＶＣＩ
はＡＴＭパケットのヘッダーから取り出され、ロードディストリビュータに提供
される。次いで、負荷分散に利用可能なプロセッサの数に対してＶＣＩのモジュ
ールが計算される。次いで、図示された実施形態と同様に、パケットおよびその
関連プロセッサ番号がホストコンピュータに提供される。

【０２９６】 上記のように、本発明の本実施形態の負荷分散は、パケットのレイヤー３およ
び／またはレイヤー４のソースおよび宛先エンティティ識別子に基づき実行され
る。しかしながら、本発明の代替の実施形態において、負荷分散は、レイヤー２
のアドレスに基づいて行われ得る。この代替の実施形態において、同様のイーサ
ネット（登録商標）ソースおよび宛先アドレスを有するパケットは、例えば、単
一のプロセッサに送られる。

【０２９７】 しかしながら、当業者が認識するように、このことは結果として、プロセッサ
は、レイヤー３および／またはレイヤー４の識別子が使用される場合よりも非常
に多くのパケットを受け取る。例えば、多量のトラフィックが、ホストコンピュ
ータ近傍に位置する（ロジックセンスにある）ルータを介して受け取られる場合
、トラフィックが多数の異なるエンドユーザおよび／またはコンピュータである
場合でさえ、トラフィックの全てについてのソースイーサネット（登録商標）ア
ドレスはルータのアドレスであり得る。対照的にホストコンピュータが、エンド
ユーザ／コンピュータの全てと同じイーサネット（登録商標）上にある場合、レ
イヤー２ソースアドレスはより多くの多様性を示し、より効果的な負荷共有を可
能にする。

【０２９８】 ネットワークから受け取るパケットの処理を分散する他の方法は、本発明の範
囲を逸脱することなく図７に図示された実施形態と異なり得る。１９９９年３月
１日に出願され、「Ａ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｎｅｔｗｏｒｋ
Ｉｎｔｅｒｆａｃｅ」と題する、米国特許出願第０９／２５９，７６５号は、本
発明の実施形態が為され得るネットワークインターフェースのさらなる詳細を提
供し、同出願は参考として本明細書中で援用される。

【０２９９】 Ｓｕｎ、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ、ＳＰＡＲＣおよびＳｏｌａｒｉ
ｓは、米国および他の国々にあるＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃｏ
ｒｐｏｒａｔｅｄの商標または登録商標である。

【０３００】 本発明の上記の実施形態の説明は、例示および説明目的のみのために提示され
ている。これらの説明は、完全なものとして意図されておらず、また開示されて
いる形態に本発明を限定するものとしても意図されていない。従って、上記の開
示内容は、本発明を限定するように意図されたものではなく、本発明の範囲は、
本明細書中の特許請求の範囲によって規定される。

【図面の簡単な説明】

【図１Ａ】 図１Ａは、本発明の実施形態に従う、ネットワークからパケットを受け取るた
めのネットワークインターフェース回路（ＮＩＣ）を示すブロック図である。

【図１Ｂ】 図１Ｂは、本発明の実施形態に従う、ネットワークから受け取られたパケット
をホストコンピュータへ伝送するための図１ＡのＮＩＣを操作する１つの方法を
示すフローチャートである。

【図２】 図２は、ネットワークを介して伝送され、本発明の１実施形態におけるネット
ワークインターフェース回路で受け取られたパケットの図である。

【図３】 図３は、本発明の実施形態に従う、パケットを構文解析するためのネットワー
クインターフェース回路のヘッダーパーサを示すブロック図である。

【図４Ａ】 図４Ａは、本発明の実施形態に従う、ネットワークインターフェース回路でネ
ットワークから受け取ったパケットを構文解析する１つの方法を示すフローチャ
ートである。

【図４Ｂ】 図４Ｂは、本発明の実施形態に従う、ネットワークインターフェース回路でネ
ットワークから受け取ったパケットを構文解析する１つの方法を示すフローチャ
ートである。

【図５】 図５は、本発明の実施形態に従う、ネットワークインターフェース回路フロー
データベースを示すブロック図である。

【図６Ａ】 図６Ａは、本発明の実施形態に従う、ネットワークインターフェース回路フロ
ーデータベースを管理する１つの方法を示すフローチャートである。

【図６Ｂ】 図６Ｂは、本発明の実施形態に従う、ネットワークインターフェース回路フロ
ーデータベースを管理する１つの方法を示すフローチャートである。

【図６Ｃ】 図６Ｃは、本発明の実施形態に従う、ネットワークインターフェース回路フロ
ーデータベースを管理する１つの方法を示すフローチャートである。

【図６Ｄ】 図６Ｄは、本発明の実施形態に従う、ネットワークインターフェース回路フロ
ーデータベースを管理する１つの方法を示すフローチャートである。

【図６Ｅ】 図６Ｅは、本発明の実施形態に従う、ネットワークインターフェース回路フロ
ーデータベースを管理する１つの方法を示すフローチャートである。

【図７】 図７は、本発明の実施形態に従う、ホストコンピュータの複数のプロセッサ間
のネットワークパケットの処理を分散する１つの方法を示すフローチャートであ
る。

【図８】 図８は、本発明の実施形態に従う、パケットを構文解析するための動的な命令
の１つのセットを示す図である。

【手続補正書】

【提出日】平成１３年９月１３日（２００１．９．１３）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】００１８

【補正方法】変更

【補正の内容】

【００１８】 （詳細な説明） 以下の説明は、いかなる当業者でも本発明を生産および使用することができる
ように示され、本発明の特定の用途およびそれらの用途の要求のコンテクストで
提供される。開示される実施形態の種々の改変が当業者には容易に明らかであり
、本明細書中に規定される一般的原理は、他の実施形態および用途にも本発明の
範囲を逸脱することなく適用し得る。従って、本発明は、示される実施形態に限
定されることを意図するものではなく、本明細書中に開示される原理および特徴
に整合する最も広い範囲を与えられるべきである。

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０２９８

【補正方法】変更

【補正の内容】

【０２９８】 ネットワークから受け取るパケットの処理を分散する他の方法は、本発明の範
囲を逸脱することなく図７に図示された実施形態と異なり得る。２０００年９月
８日に公開され、米国特許出願第０９／２５９，７６５号に対応する国際公開第
ＷＯ００／５２９０４号は、本発明の理解に有用な高性能ネットワークインター
フェースのさらなる詳細（例えば、ネットワークインターフェースからホストコ
ンピュータプロセッサへパケットを搬送すること）を提供する。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ， ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，Ｓ Ｋ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 ジェントリー， デントン アメリカ合衆国 カリフォルニア 94555， フレモント， シー クリフ テラス 34892 Ｆターム(参考） 5B089 GA02 JA11 5K030 GA13 HA08 KA01 KA02 LB05 LC01 LE01 MB09

Claims (26)

【特許請求の範囲】
1. 【請求項１】 ネットワークトラフィック処理をマルチプロセッサコンピュ
   ータの複数のプロセッサ間に分散させる方法であって、 第１のパケットを、マルチプロセッサコンピュータのネットワークインターフ
   ェースで受け取る工程であって、該マルチプロセッサコンピュータで動作する宛
   先エンティティに該第１のパケットをアドレス指定する、工程と、 該第１のパケットを構文解析し、ソースエンティティと該宛先エンティティと
   の間の第１の通信フローの第１のフロー識別子を確定する工程であって、該第１
   の通信フローが該第１のパケットを含む、工程と、 該マルチプロセッサコンピュータの複数のプロセッサのうち１つのプロセッサ
   を識別するために構成される第１のプロセッサ識別子を、該第１のフロー識別子
   から生成する工程と、 該第１のプロセッサ識別子を該第１のパケットと関連付ける工程と、 該第１のプロセッサが処理するために、該第１のパケットを該ネットワークイ
   ンターフェースから発信する工程と を包含する方法。
2. 【請求項２】 前記第１の通信フローの第２のパケットを前記ネットワーク
   インターフェースにおいて、前記ソースエンティティから受け取る工程と、 前記第１のプロセッサ識別子を該第２のパケットと関連付ける工程と、 前記第１のプロセッサが処理するために、該第２のパケットを該ネットワーク
   インターフェースから発信する工程と をさらに包含する、請求項１に記載の方法。
3. 【請求項３】 第２のパケットを前記ネットワークインターフェースで受け
   取る工程と、 該第２のパケットを構文解析し、前記マルチプロセッサコンピュータで動作す
   る第２のソースエンティティと第２の宛先エンティティとの間の第２の通信フロ
   ーを識別するために第２のフロー識別子を確定する工程であって、該第２の通信
   フローが該第２のパケットを含む、工程と、 前記複数のプロセッサのうち１つのプロセッサを識別するために構成される第
   ２のプロセッサ識別子を、該第２のフロー識別子から生成する工程と、 該第２のプロセッサ識別子を該第２のパケットと関連付ける工程と、 該第２のプロセッサが処理するために、該第２のパケットを該ネットワークイ
   ンターフェースから発信する工程と をさらに包含する、請求項１に記載の方法。
4. 【請求項４】 前記構文解析する工程が、 前記ソースエンティティ識別子を前記第１のパケットから受け取る工程と、 前記宛先エンティティ識別子を該第１のパケットから受け取る工程と を包含する、請求項１に記載の方法。
5. 【請求項５】 前記構文解析する工程が、前記ソースエンティティ識別子と
   前記宛先エンティティ識別子を結合させ、フローキーを形成する工程をさらに包
   含し、前記フロー識別子が該フローキーを含む、請求項４に記載の方法。
6. 【請求項６】 前記構文解析する工程が、仮想接続識別子を前記第１のパケ
   ットから受け取る工程を包含する、請求項１に記載の方法。
7. 【請求項７】 前記第１のプロセッサ識別子を第１のフロー識別子から生成
   する工程が、 ハッシュ値を生成するために前記第１のフロー識別子をハッシュする工程と、 ネットワークトラフィック処理が分散される間に、プロセッサ数を識別する工
   程と、 該ハッシュ値のモジュラスを該プロセッサ数にわたり計算する工程と を包含する、請求項１に記載の方法。
8. 【請求項８】 前記識別する工程が、前記プロセッサ数を表す値をプログラ
   ム可能な格納デバイスから受け取る工程を包含する、請求項７に記載の方法。
9. 【請求項９】 前記第１のプロセッサ識別子を第１のフロー識別子から生成
   する工程が、 ネットワークトラフィック処理が分散される間に、プロセッサ数を識別する工
   程と、 該第１のフロー識別子のモジュラスを該プロセッサ数にわたり計算する工程と を包含する、請求項１に記載の方法。
10. 【請求項１０】 前記発信する工程が、前記第１のパケットを前記マルチプ
    ロセッサコンピュータの第１のメモリに格納する工程と、 前記第１のプロセッサ識別子を第２のメモリに格納する工程と を包含する、請求項１に記載の方法。
11. 【請求項１１】 前記発信する工程が、前記ネットワークインターフェース
    から前記マルチプロセッサコンピュータへ警告を発行し、前記第１のパケットを
    格納したことをマルチプロセッサコンピュータに通知する工程をさらに包含する
    、請求項１０に記載の方法。
12. 【請求項１２】 前記受け取る工程、前記構文解析する工程、前記生成する
    工程、前記関連付ける工程、および前記発信する工程の各々が、前記ネットワー
    クインターフェースで実行される、請求項１に記載の方法。
13. 【請求項１３】 ネットワークからパケットを受け取り、処理するためのマ
    ルチプロセッサコンピュータであって、 複数のプロセッサと、 パケットをネットワークから受け取り、該パケットを該複数のプロセッサに発
    信するために構成されるネットワークインターフェースとを備え、該ネットワー
    クインターフェースが、 該マルチプロセッサコンピュータで実行するエンティティを含む通信フローの
    状況を格納するために構成されるフローデータベースであって、該通信フローが
    フローキーにより識別され、該状況がフローインデックスによりインデックス付
    けされる、フローデータベースと、 該マルチプロセッサコンピュータで実行する第１のエンティティについて、該
    ネットワークインターフェースにおいて受け取られる第１のパケットの１以上の
    プロトコルヘッダを構文解析し、該第１のパケットを含む第１の通信フローの第
    １のフローキーを生成するために構成されるヘッダパーサと、 該第１のパケットを処理するための該複数のプロセッサのうち第１のプロセッ
    サの識別子を、該第１のフローキーおよび該フローデータベースの該第１の通信
    フローの状況の第１のフローインデックスの１つから生成するために構成される
    ロードディストリビュータと を備える、マルチプロセッサコンピュータ。
14. 【請求項１４】 前記ネットワークインターフェースが、前記第１のフロー
    キーを受け取り、前記フローデータベースを前記第１の通信フローの状況を用い
    て更新するために構成されるフローデータベースマネージャをさらに備える、請
    求項１３に記載のマルチプロセッサコンピュータ。
15. 【請求項１５】 前記ネットワークインターフェースが、 前記複数のプロセッサのうち１つへの転送用の前記第１のパケットを格納する
    第１のデータ構造と、 前記第１のプロセッサ識別子を格納する第２のデータ構造 とをさらに備える、請求項１３に記載のマルチプロセッサコンピュータ。
16. 【請求項１６】 コンピュータが実行される場合、複数のプロセッサの間で
    、ネットワークトラフィックの処理を分散する方法を該コンピュータに実行させ
    る命令を格納する、コンピュータ読み出し可能格納媒体であって、該方法は、 マルチプロセッサコンピュータのネットワークインターフェースにおいて、第
    １のパケットを受け取る工程であって、該第１のパケットを、該マルチプロセッ
    サコンピュータで動作する宛先エンティティにアドレス指定する、工程と、 ソースエンティティと該宛先エンティティとの間の第１の通信フローを識別す
    るための第１のフロー識別子を生成する工程であって、該第１の通信フローが該
    第１のパケットを含む、工程と、 該マルチプロセッサコンピュータの複数のプロセッサのうち１つのプロセッサ
    を識別するために構成される第１のプロセッサ識別子を、該第１のフロー識別子
    から生成する、工程と、 該第１のプロセッサ識別子を該第１のパケットと関連付ける工程と、 該第１のプロセッサが処理するために、該第１のパケットを該ネットワークイ
    ンターフェースから発信する工程と を包含する、コンピュータ読み出し可能格納媒体。
17. 【請求項１７】 前記構文解析する工程が、 第１のフローキーを形成するために、前記ソースエンティティ識別子と前記宛
    先エンティティ識別子とを結合する工程と、 該第１のフローキーを求めてフローキーの集合体を検索する工程であって、該
    第１のフローキーが該集合体で見つかると、前記第１のフロー識別子が、該集合
    体に該第１のフローキーを含む、工程と をさらに包含する、請求項４に記載の方法。
18. 【請求項１８】 前記構文解析する工程が、前記第１のフローキーが前記フ
    ローキーの集合体で見つからないと、該第１のフローキーを、該フローキーの集
    合体に格納する工程をさらに包含する、請求項１７に記載の方法。
19. 【請求項１９】 前記構文解析する工程が、前記第１のフローキーが前記フ
    ローキーの集合体で見つかると、該第１のフローキーを含む該集合体内のエント
    リを更新する工程をさらに包含する、請求項１７に記載の方法。
20. 【請求項２０】 前記構文解析する工程が、前記フローキーを、前記マルチ
    プロセッサコンピュータで動作する宛先エンティティを含む通信フローと関連付
    けられたフローキーの集合体に格納する工程をさらに包含する、請求項５に記載
    の方法。
21. 【請求項２１】 前記発信する工程が、前記ネットワークインターフェース
    から前記複数のプロセッサのうち１つのプロセッサへ転送するために、該ネット
    ワークインターフェースと前記マルチプロセッサコンピュータにより共有される
    メモリに前記第１のパケットを格納する工程を包含する、請求項１に記載の方法
    。
22. 【請求項２２】 前記関連付ける工程が、前記ネットワークインターフェー
    スから前記複数のプロセッサのうち１つのプロセッサへ前記第１のパケットとと
    もに転送するために前記第１のプロセッサ識別子を格納する工程を包含する、請
    求項１に記載の方法。
23. 【請求項２３】 前記構文解析する工程が、前記第１のパケットが所定のセ
    ットの通信プロトコルに従い構成されたかどうかを判定するために、該第１のパ
    ケットの１以上のヘッダを構文解析する工程を包含する、請求項１に記載の方法
    。
24. 【請求項２４】 前記第１のパケットが、前記所定のセットの通信プロトコ
    ルに従い構成されたかどうかを示すために、オペレーションコードを該第１のパ
    ケットと関連付ける工程をさらに包含する、請求項２３に記載の方法。
25. 【請求項２５】 前記第１のフローキーが前記第１のパケットのソースの識
    別子および前記第１のエンティティ識別子を含む、請求項１３に記載のマルチプ
    ロセッサコンピュータ。
26. 【請求項２６】 前記第１のパケットの１以上のプロトコルヘッダが、所定
    のセットのプロトコルと対応しない場合、前記ヘッダパーサが所定の信号を生成
    するためにさらに構成される、請求項１３に記載のマルチプロセッサコンピュー
    タ。