JP2002538725A - 初期のランダムなパケット廃棄方法および装置 - Google Patents

Abstract

(57)【要約】 パケット転送率がパケット到達率と同じペースであり得ない場合、高性能ネットワークインターフェースで受け取られるパケットをランダムに廃棄するためのシステムおよび方法が提供される。選択されたパケットは、パケットキューに到達してドロップされ得るか、または上記キューにすでに存在するパケットが廃棄され得る。上記キューは複数の規定領域を有し、この規定領域のうち任意の境界は、重なってもよいし、または共通の境界を共有してもよい。上記キューのトラフィックのレベルが上記領域内である場合、確率インジケータは、パケットの廃棄される確率を特定するために、領域と関連付けられる。確率インジケータは領域ごとに異なり、それにより、パケットを廃棄する確率が、上記キューに格納されるトラフィックのレベルが変更するにつれて変動する。

Description

【発明の詳細な説明】

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

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

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

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

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

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

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

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

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

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

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

【００１２】 （要旨） 本発明の１実施形態において、パケットはネットワークから受け取られ、ホス
トコンピュータに転送されるより先にパケットキューに格納される。ホストコン
ピュータへのパケットの転送率が、キューでのパケットの到達率と同じペースで
あり得ない場合、１以上のパケットがドロップされ得る。従って、ランダムな方
法でパケットを廃棄するシステムおよび方法が提供され、それにより損失パケッ
トの効果が、ネットワーク通信間で公平に分配される。

【００１３】 本発明の１実施形態において、ネットワークから受け取られたパケットを格納
するために使用されるパケットキューが、複数の領域に分割される。各領域は異
なるが、境界を隣接する領域と共有する。代替の実施形態では、領域は重なって
いてもよい。フルネスゲージまたはインジケータが、パケットキューがどの程度
フルであるかを示すために利用される。特に、パケットキューを更新するために
使用される読み出しおよび書き込みポインタがまた、キューがどの程度フルであ
るかを判定するために使用され得る。従って、このフルネスインジケータは、パ
ケットキューに格納されるネットワークトラフィックのレベルが増減するにつれ
て変動する。

【００１４】 複数のパケットキューの領域のうち１つ以上の領域について、プログラマブル
確率インジケータが割り当てられる。キューに格納されたトラフィックのレベル
が、確率インジケータの関連領域以内であることをフルネスインジケータが示す
場合、各確率インジケータはパケットをドロップする確率を示す。確率インジケ
ータは、パケットキューのトラフィックのレベルが変化すると、プログラムおよ
び再プログラムされ得る。廃棄されるパケットをランダムに選択するために構成
される確率インジケータは、割合または比の形式を取り得る。

【００１５】 本発明の特定の１実施形態において、確率インジケータはビットまたはフラグ
マスクの形式を取る。各ビットまたはフラグは、２つの可能な値（例えば、０お
よび１）のうち１つを取り得る。この実施形態において、カウンタは、０からＮ
のような制限された範囲の数まで繰り返しカウントすることにより、パケットキ
ューで受け取られるパケット数を追跡する。ビットまたはフラグマスクは同様に
、Ｎ＋１個のビットまたはフラグを含む。従って、各カウンタ値について、マス
クの対応するビットまたはフラグは、そのカウンタ値がドロップされる間にパケ
ットが受け取られたかどうかを示す。

【００１６】 代替の実施形態において、パケットが受け取られると、ランダム数が生成され
る。ランダム数は閾値と比較され、受け取られたパケットがドロップされるかど
うかを判定し得る。各領域は、パケットがドロップされるかどうかを判定する個
別の閾値を有し得る。

【００１７】 本発明のさらなる他の実施形態において、パケットは、特定の特性または状態
を示すので無効にされるか、または廃棄されることを免除され得る。例えば、制
御パケットは、ドロップされないあるタイプのパケットであり得る。この実施形
態において、廃棄不可能なパケットが受け取られる場合、カウンタはインクリメ
ントされない。廃棄対象から免除され得る他のパケットは、特定のネットワーク
接続またはフロー内のパケット、特定アプリケーションに関連付けられたパケッ
ト、特定プロトコルに従いフォーマットされたパケット等であり得る。パケット
の関連特性または詳細は、パケットヘッダのうち１つ以上が構文解析するプロセ
スの間に抽出され得る。

【００１８】 本発明の１実施形態において、確率インジケータがパケットがドロップされる
べきであることを示す場合、ドロップされるパケットはパケットキューでまさに
受け取られたキューであり得る。しかしながら、他の実施形態において、すでに
パケットキューに格納されたパケットはドロップされてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０２７５】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０２９８】 ネットワークから受け取るパケットの処理を分散する他の方法は、本発明の範
囲を逸脱することなく図７に図示された実施形態と異なり得る。特に、当業者で
あれば、フローのパケットをプロセッサに割り当て、割り当てたパケットをプロ
セッサに送達する多くの代替プロシージャが使用され得ることを理解する。

【０２９９】 （パケットキューの１実施形態） 上述のように、パケットキュー１１６は、ＤＭＡエンジン１２０によってリア
センブルされ、ホストコンピュータシステムに伝送する前に、ＩＰＰモジュール
１０４から受け取られたパケットを格納する。図８は、本発明の１実施形態によ
るパケットキュー１１６を示す。

【０３００】 例示的な実施形態において、パケットキュー１１６は、２５６のエントリまで
含むＦＩＦＯ（先入れ先出し）キューとしてインプリメントされる。この実施形
態における各パケットキューエントリは、１つのパケットに加えてそのパケット
に関する種々の情報を格納する。例えば、エントリ８００は、パケット部８０２
に加えてパケット状態部を含む。種々のサイズのパケットがパケットキュー１１
６に格納されるので、パケット部８０２は、パケット部が適切な境界（例えばバ
イト、ワード、二重ワード）で終了するように、パケットを補充するためのフィ
ラー８０２ａを含み得る。

【０３０１】 フィラー８０２ａは、ランダムデータまたは特定のパターンを有するデータを
含み得る。フィラー８０２ａは、フィラーデータのパターンによってまたはタグ
フィールドによって格納されたパケットと区別され得る。

【０３０２】 例示的に、パケット状態情報は、ＴＣＰチェックサム値８０４およびパケット
長８０６（例えば、パケット部８０２に格納されたパケットの長さ）を含む。パ
ケット長を格納することによって、そのパケットは容易に識別され、パケット部
８０２から容易に取り出され得る。パケット状態情報はまた、診断／状態情報８
０８を含み得る。診断／状態情報８０８は、パケットが不正（例えば、エラーに
伴って不完全に受け取られたパケット）であることを示すフラグ、チェックサム
がパケットについて計算されたかどうかを示すインジケータ、チェックサムが特
定の値を有することを示すインジケータ、チェックサムが計算したパケット部に
対するオフセット等を含み得る。別のフラグまたは別のインジケータもまた、診
断、フィルタリング、または他の目的のために含まれ得る。本発明の１実施形態
において、（上述され、パケットを含むフローを識別するために用いられる）パ
ケットのフローキーおよび／またはフロー番号（例えば、フローデータベース１
１０のパケットフローの対応するインデックス）が、診断／状態情報８０８に含
まれる。他の実施形態において、フィラー８０２ａを識別子するか、または範囲
を定めるタグフィールドが、診断／状態情報８０８に含まれる。

【０３０３】 本発明の別の１実施形態において、上述のパケット状態情報のうちの任意また
は全てが、パケットキュー１１６ではなくて制御キュー１１８に格納される。

【０３０４】 本発明の例示的な実施形態において、パケットキュー１１６は、（例えばラン
ダムアクセスメモリとして）ハードウェアにインプリメントされる。この実施形
態において、チェックサム値８０４のサイズは、１６ビットであり、チェックサ
ム発生器１１４によって格納され得る。パケット長８０６の大きさは、１４ビッ
トであり、ヘッダーパーサ１０６によって格納され得る。最後に、診断／状態情
報８０８の一部が、ＩＰＰモジュール１０４、ヘッダーパーサ１０６、フローデ
ータベースマネージャ１０８、ロードディストリビュータ１１２、およびチェッ
クサム発生器１１４のうちの１つ以上によって格納され得る。

【０３０５】 図８のパケットキュー１１６は、２つのポインタでインデックス付けされる。
読み出しポインタ８１０は、そのキューから読み出されるべき次のエントリを識
別し、一方書き込みポインタ８１２は、次に受け取られるパケットおよび関連す
る情報が格納されるべきエントリを識別する。本発明の本実施形態において、エ
ントリのパケット部８０２に格納されたパケットは、そのデータがＤＭＡエンジ
ン１２０によってリアセンブルされ、および／またはホストコンピュータシステ
ムに伝送される場合に、パケットキュー１１６から抽出される。

【０３０６】 （制御キューの１実施形態） 本発明の１実施形態において、制御キュー１１８は、ＮＩＣ１００が受け取っ
たパケットに関する制御情報および状態情報を格納する。この実施形態において
、制御キュー１１８は、プロトコルヘッダーのバッチ処理および／または複数の
関連するパケットからのデータのリアセンブリを可能にするために用いられる情
報を保持する。制御キューはまた、ホストコンピュータによって用いられる情報
またはホストコンピュータ（例えばＮＩＣ１００用のデバイスドライバ）上で動
作する一連の命令を格納し得る。制御キュー１１８に格納された情報は、パケッ
トキュー１１６に格納された情報を補充するか、または複製し得る。

【０３０７】 図９は、本発明の１実施形態における制御キュー１１８を示す。例示的な制御
キューは、パケットキュー１１６に（例えば２５６のエントリまで）格納される
各パケットに対して１つのエントリを含む。本発明の１実施形態において、制御
キュー１１８の各エントリは、同じ番号を有するパケットキュー１１６のエント
リ（例えばパケット）に対応する。図９は、ＣＰＵ番号９０２、Ｎｏ＿Ａｓｓｉ
ｓｔ信号９０４、オペレーションコード９０６、ペイロードオフセット９０８、
ペイロードサイズ９１０、および他の状態情報９１２のような種々のフィールド
を有するエントリ９００を示す。エントリはまた、他の状態情報または制御情報
（図９に図示せず）を含むことができる。本発明の別の実施形態における制御キ
ュー１１８のエントリは、異なる情報を含み得る。

【０３０８】 前セクションで述べたＣＰＵ（またはプロセッサ）番号９０２は、ホストコン
ピュータシステム上の複数のプロセッサのうちどのプロセッサがパケットのプロ
トコルヘッダーを処理すべきかを示す。例示的に、ＣＰＵ番号９０２のサイズは
６ビットである。前セクションで述べたようにＮｏ＿Ａｓｓｉｓｔ信号９０４も
また、パケットがヘッダーパーサ１０６によって構文解析され得る予め選択され
たプロトコルの任意のセットと互換性があるかどうか（例えばパケットがそのプ
ロトコルのセットに従ってフォーマットされたかどうか）を示す。Ｎｏ＿Ａｓｓ
ｉｓｔ信号９０４は１つのフラグ（例えば１ビット）を含み得る。本発明の１実
施形態において、Ｎｏ＿Ａｓｓｉｓｔ信号９０４の状態または値をフローデータ
ベースマネージャ１０８が用いて、パケットのデータがリアセンブル可能である
かどうか、および／またはそのヘッダーが関連するパケットのヘッダーで処理さ
れ得るかどうかが判定され得る。特に、ＦＤＢＭは、どのオペレーションコード
をパケットに割り当てるかを決定する際にそのＮｏ＿Ａｓｓｉｓｔ信号を用いる
ことができる。

【０３０９】 オペレーションコード９０６は、ＤＭＡエンジン１２０に情報を供給し、それ
によりパケットデータのリアセンブリを助ける。前セクションで述べたように、
オペレーションコードは、パケットがデータを含むかどうか、またはパケットデ
ータがリアセンブリに適切であるかどうかを示し得る。例示的に、オペレーショ
ンコード９０６のサイズは３ビットである。ペイロードオフセット９０８および
ペイロードサイズ９１０は、それぞれパケットのＴＣＰペイロード（例えばＴＣ
Ｐデータ）のオフセットおよびサイズに対応する。これらのフィールドの大きさ
は、それぞれ７ビットおよび１４ビットである。

【０３１０】 例示的な実施形態において、他の状態情報９１２はパケットに関する診断およ
び／または状態情報を含む。状態情報９１２は、チェックサム計算の開始位置（
このサイズは７ビットであり得る）、レイヤー３（例えばＩＰ）のプロトコルヘ
ッダーのオフセット（このサイズもまた７ビットであり得る）等を含み得る。状
態情報９１２はまた、パケットのサイズが第１の閾値を越える（例えばそのパケ
ットが１５２２バイトより大きい）かどうか、またはパケットのサイズが第２の
閾値を下まわる（例えばそのパケットが２５６バイト以下である）かどうかにつ
いてのインジケータを含み得る。この情報は、パケットデータをリアセンブルす
る際に有用であり得る。例示的に、これらのインジケータは１ビットのフラグを
含む。

【０３１１】 本発明の別の１実施形態において、状態情報９１２は、パケットのフローキー
および／またはフロー番号（例えばフローデータベース１１０におけるパケット
フローのインデックス）を含む。例えば、フローキーまたはフロー番号は、デバ
ッグまたは他の診断目的のために用いられ得る。本発明の１実施形態において、
パケットのフロー番号は、１つのフロー内の複数のパケットが識別され得るよう
に、状態情報９１２に格納され得る。次いで、このような関連するパケットはホ
ストコンピュータに集約的に伝送され得るか、および／またはホストコンピュー
タによって処理され得る。

【０３１２】 図９は、制御キュー１１８をインデックス付けするための、読み出しポインタ
および書き込みポインタを示す。読み出しポインタ９１４は、ＤＭＡエンジン１
２０によって読み出されるエントリを示す。書き込みポインタ９１６は、パケッ
トキュー１１６に格納された次のパケットに関する情報を格納するエントリを示
す。

【０３１３】 本発明の別の実施形態において、第２の読み出しポインタ（図９に図示せず）
を制御キュー１１８のインデックス付けに用いることができる。後のセクション
で述べるように、パケットがホストコンピュータに伝送される場合に、制御キュ
ーのエントリから引き出された情報を検索して、関連するパケット（例えば伝送
されるパケットと同じフロー内のパケット）もまた伝送予定であるかどうかを判
定する。関連するパケットが伝送予定の場合、ホストコンピュータは、関連する
パケットからプロトコルヘッダーを集約的に処理できるように警告される。本発
明のこの別の実施形態において、関連するパケットは、状態情報９１２のフロー
番号（またはフローキー）を整合させることによって識別される。第２の読み出
しポインタは、制御キューにおいて先取りを行うために用いられ、それによりパ
ケットをフロー番号と整合させ得る。

【０３１４】 本発明の１実施形態において、ＣＰＵ番号９０２は、ロードディストリビュー
タ１１２によって制御キューに格納され得、Ｎｏ＿Ａｓｓｉｓｔ信号９０４はヘ
ッダーパーサ１０６によって格納され得る。オペレーションコード９０６はフロ
ーデータベースマネージャ１０８によって格納され得、ペイロードオフセット９
０８およびペイロードサイズ９１０は、ヘッダーパーサ１０６によって格納され
得る。他の状態情報の部分が、先のモジュールおよび／またはＩＰＰモジュール
１０４およびチェックサム発生器１４４のような他のモジュールによって書き込
まれ得る。しかしながら、本発明の特定の１実施形態において、情報のこれらの
項目の多くが、ＩＰＰモジュール１０４またはいくらか調整する役目を果たす何
らかの他のモジュールによって格納される。

【０３１５】 （本発明の１つの実施形態における初期ランダムパケット廃棄） パケットが、ホストコンピュータに伝送され得る速度よりも高速に、ネットワ
ークからネットワークインターフェースに到着し得る。このような状況である場
合、ネットワークインターフェースは、１つ以上のパケットをドロップまたは廃
棄しなければならない。従って、本発明の１つの実施形態において、パケットを
ランダムに廃棄するシステムおよび方法が提供される。このセクションにおいて
説明するシステムおよび方法は、他の通信デバイス（ゲートウェイ、ルータ、ブ
リッジ、モデム等）にも適用可能である。

【０３１６】 当業者であれば認識するように、パケットがドロップされ得る１つの理由は、
ネットワークインターフェースは、自身がホストコンピュータへの伝送のために
格納し得るパケットの最大数を既に格納しているからである。詳細には、ホスト
コンピュータに伝送されるパケットを収容するキュー（例えば、（図１Ａ中の）
パケットキュー１１６）は、別のパケットがネットワークから受け取られた場合
、完全にポピュレートされ得る。新規パケットまたはキュー中に既に格納された
パケットのいずれかが、ドロップされ得る。

【０３１７】 大部分のネットワークトラフィックのバースト特性の理由で、ネットワークイ
ンターフェースが混雑している場合、複数のパケットをドロップし得ることがし
ばしばある。また、いくつかのネットワークインターフェースにおいて、連続的
なパケットがドロップされた場合、１つの特定のネットワーク接続またはフロー
がパケットが高速で到着した事態の原因でなくとも、当該接続部またはフロー（
例えば、ドロップされたパケットを全て含む接続部またはフロー）にペナルティ
ーを科す（ｐｅｎａｌｉｚｅｄ）ことが可能である。ネットワーク接続またはフ
ローへのペナルティが余りにも重い場合、その接続部またはフロー中にトラフィ
ックを生成するネットワークエンティティは、「壊されたパイプ」に遭遇したと
考えて、それを壊し得る。当業者であれば認識するように、壊されたパイプが発
生するのは、ネットワークエンティティが、通信問題を接続困難であることを示
すものとして解釈した場合である。

【０３１８】 特定のネットワークトラフィック（例えば、ＴＣＰトラフィック）の場合、パ
ケットのドロップは、ネットワークエンティティのウィンドウ（例えば、ネット
ワークトラフィックが承認を待機する前に伝送するパケット数）が収縮するかま
たは非常に低い数字に再設定するフロー制御方法を開始し得る。従って、ネット
ワークインターフェースが受取りエンティティにおいてＴＣＰ通信路（ｃｏｍｍ
ｕｎｉｃａｎｔ）からパケットをドロップするたびに、その通信は、受け取り側
のエンティティとの自身の接続部を再同期しなければならない。通信路の１つま
たは一部が、エンティティにおいて受け取られたネットワークトラフィックの大
きなパーセンテージについて責任を負う場合、これらの通信路に、当該通信路が
責任を負うトラフィックの量に比例してペナルティを科すことが正しいように見
える。

【０３１９】 加えて、特定のパケットまたは特定の種類のパケットを廃棄することを防ぐこ
とが賢明である場合もあり得る。例えば、少量の制御パケットを廃棄することは
、ネットワークインターフェース中の混雑を軽減することには殆ど役に立たず、
それどころか、ネットワーク接続またはフローに対して大きなマイナスの影響を
与え得る。さらに、特定のプロトコルに付着するパケットについてネットワーク
インターフェースを最適化する場合、このようなパケットをドロップさせること
を回避する方がより効率的であり得る。さらに、特定の接続部、フローまたはア
プリケーションを優先順位付けすることもでき、その場合、優先順位が高いトラ
フィックほどドロップすべきではない。

【０３２０】 従って、本発明によるネットワークインターフェースの１つの実施形態におい
て、通信デバイスのパケットキューがフルであるかまたは特定の閾値レベルまで
満たされている場合にパケットをランダムに廃棄する方法を提供する。特定の種
類のパケット（例えば、特定のフロー接続部あるいはアプリケーションからのパ
ケット）を廃棄対象として選択するか、または、特定の種類のパケット（例えば
、制御パケット、特定のプロトコルあるいは１組のプロトコルに適合するパケッ
ト）を廃棄対象から除外することにより、このような方法にインテリジェンスを
付加することができる。

【０３２１】 提供される方法は、廃棄対象パケットを廃棄可能と考えられるパケットからラ
ンダムに選択する点において、ランダムである。ランダムに廃棄する方針の適用
は、複数の接続部またはフローの間にパケットをドロップすることにより影響を
分散することにより、壊されたパイプを回避するのに十分であり得る。加えて、
少数の伝送エンティティがネットワークインターフェースにおいて受け取られる
トラフィックの大部分に対して責任を負う場合、パケットをランダムにドロップ
すると、反則しているエンティティに相応のペナルティを科すことを確実にする
ことができる。以下に記載される本発明の別の実施形態は、ランダム性およびイ
ンテリジェンスの様々な組み合わせを提供し、これらの属性の１つは、１つ以上
の実施形態において省略可能である。

【０３２２】 図１０は、本発明のこの実施形態においてパケットをランダムに廃棄するシス
テムおよび方法を示す。この実施形態において、パケットキュー１０００は、サ
イズが１６ＫＢのハードウェアＦＩＦＯ（例えば、先入れ先出し）キューである
。本発明の別の実施形態において、パケットキューは、それよりも小さいかある
いは大きく、または、ハードウェアまたはソフトウェアとしてインプリメントさ
れる別の種類のデータ構造（例えば、リスト、アレイ、表、ヒープ）を含み得る
。

【０３２３】 前セクションにおいて説明したパケットキュー１１６と同様に、パケットキュ
ー１０００は、ネットワークからパケットを受け取り、これらのパケットを、ホ
ストコンピュータへの伝送対象として収容する。ネットワークから到着するパケ
ットは、ネットワークから高速で到着し、パケットキュー１０００中に格納され
る前に、１つ以上のモジュール（例えば、ヘッダーパーサ１０６、フローデータ
ベースマネージャ１０８）によって処理または調査され得る。例えば、ネットワ
ークが１秒あたり１ギガビットのトラフィックを伝送することが可能な場合、１
組のプロトコル（例えば、イーサネット（登録商標）、ＩＰおよびＴＣＰ）に適
合するパケットを、約１，４８０，０００パケット／秒の速度で受け取ることが
できる。パケットは、パケットキュー１０００に格納された後、ホストコンピュ
ータ内部のイベントおよび条件に部分的に依存する速度で、ホストコンピュータ
に伝送される。従って、ネットワークインターフェースは、ホストコンピュータ
へのパケット伝送速度を制御することはできない。

【０３２４】 図示の実施形態において、パケットキュー１０００を、複数のゾーンまたは領
域に分割し、これらのゾーンまたは領域のうち任意のものは、重複するかまたは
共通の境界部分を共有し得る。パケットキュー１０００は、任意の数の領域に分
割され得、本発明は、図１０に示す３つの領域に限定されない。例示として、領
域０（参照符号１００２で図示）は、０ＫＢ（例えば、キュー中に格納されてい
るパケットが無い状態）から８ＫＢ（例えば、キューが半分満たされている状態
）までのパケットキュー１０００の一部を包含する。領域１（参照符号１００４
で図示）は、８ＫＢ〜１２ＫＢのパケットキューの一部を包含する。領域２（参
照符号１００６で図示）は、１２ＫＢ〜１６ＫＢのパケットキューの残りの部分
を包含する。別の実施形態において、パケットキュー１０００の一部のみについ
て、領域が分割され得る。例えば、上半分部分（例えば、８ＫＢよりも上）のみ
が、１つ以上の領域に分割され得る。

【０３２５】 異なる領域の数およびサイズならびに領域間の境界の位置は、複数の要因に応
じて変化し得る。これらの要因としては、ネットワークインターフェースにおい
て受け取られる。パケットの種類（例えば、パケットの構成の基本となるプロト
コル）、パケットのサイズ、パケットの到着速度（例えば、予測速度、平均速度
、最高速度）、ホストコンピュータへのパケット伝送速度、パケットキューのサ
イズ等がある。例えば、本発明の別の実施形態において、パケットキュー１００
０を５つの領域に分割する。第１の領域は０ＫＢ〜８ＫＢに延在し、第２の領域
は８ＫＢ〜１０ＫＢに延在し、第３の領域は１０ＫＢ〜１２ＫＢに延在し、第４
の領域は１２ＫＢ〜１４ＫＢに延在し、最終領域は１４ＫＢ〜１６ＫＢに延在す
る。

【０３２６】 本発明によるネットワークインターフェースが動作している間、トラフィック
インジケータ１００８は、パケットキュー１０００の空き状態を示す。トラフィ
ックインジケータ１００８は、本発明の１つの実施形態において、読出しポイン
タ８１０および／または書込みポインタ８１２（図８に図示）を含む。現在説明
している実施形態において、パケットキュー１０００は完全に分割されており、
トラフィックインジケータ１００８は概して、パケットキューが分割される領域
の１つまたは分割境界部分に配置される。従って、ネットワークインターフェー
スの動作中、以下に説明するように、パケットキューの空き状態に応じて（例え
ば、トラフィックインジケータ１００８によって識別される領域に応じて）、適
切なアクションが取られ得る。

【０３２７】 図１０において、パケットがパケットキュー１０００に到着すると、カウンタ
１０１０がインクリメントされる。図示の実施形態において、カウンタ１０１０
は、限られた範囲の値（例えば、０〜７）を連続的にサイクルする。本発明の１
つの実施形態において、新規パケットが受け取られるたびに、カウンタが１だけ
インクリメントされる。別の実施形態において、特定の「廃棄不可能な」パケッ
トが受け取られた場合、カウンタ１０１０はインクリメントされ得ない。廃棄不
可能なパケットを識別する様々な例示的基準について、以下に説明する。

【０３２８】 パケットキュー１０００の１つ以上の領域について、関連付けられたプログラ
ム可能な確率インジケータは、トラフィックインジケータ１００８がパケットキ
ュー中のトラフィックレベルが関連領域に達したことを示した場合にパケットが
ドロップされる確率を示す。従って、図示の実施形態において、確率インジケー
タ１０１２は、パケットキューの半分よりも多くが空である場合（例えば、トラ
フィックインジケータ１００８が領域０内に配置されている場合）に、パケット
がドロップされる確率を示す。同様に、確率インジケータ１０１４および１０１
６は、トラフィックインジケータ１００８が領域１および２をそれぞれ識別する
場合に新規パケットがドロップされる確率を特定する。

【０３２９】 図示の実施形態において、確率インジケータ１０１２、１０１４および１０１
６はそれぞれ、サブインジケータのセットまたはマスク（例えば、ビットまたは
フラグ）を含む。例示として、確率インジケータ中のサブインジケータ数は、カ
ウンタ値の範囲（この場合は８）にマッチングする。本発明の１つの実施形態に
おいて、各サブインジケータは、パケットがドロップされるか否かを示す２つの
値（例えば、０または１）の１つを有する。従って、確率インジケータのサブ要
素は、カウンタ１０１０の８つの可能な値に対応するよう、０〜７（例示として
、右から左）に番号付けされ得る。第１の値（例えば、１）を格納する確率イン
ジケータ中の各位置について、カウンタ１０１０の値が当該ビット数とマッチン
グする場合、パケットキュー１０００から受け取られた次の廃棄可能なパケット
がドロップされる。上述したように、特定の種類のパケット（例えば、制御パケ
ット）はドロップ不可能である。例示として、廃棄可能なパケットの場合、カウ
ンタ１０１０のみがインクリメントされる。

【０３３０】 図１０において、パケットキューが半分よりも多く空いている限り（例えば、
トラフィックインジケータ１００８が領域０中にある限り）、確率インジケータ
１０１２（例えば、００００００００）は、ドロップされるパケットは無いこと
を示す。パケットキュー中に少なくとも８ＫＢが格納されている場合、確率イン
ジケータ１０１４（例えば、０００００００１）は、パケットが８個巡回するた
びに１つのパケットがドロップされることを示す。言い換えれば、トラフィック
インジケータ１００８が領域１内に配置された場合、廃棄可能なパケットがドロ
ップされる確率は１２．５％である。詳細には、カウンタ１０１０が０に等しい
場合、次の廃棄可能なパケットまたはパケットキュー中に既に格納されているパ
ケットが廃棄される。確率インジケータ１０１６（例えば、０１０１０１０１）
は、他の廃棄可能なパケットもそれぞれ廃棄されることえを指定する。従って、
キューの３／４よりも多くが満たされている場合に廃棄可能なパケットがドロッ
プされる確率は５０％である。例示として、パケットがドロップされると、カウ
ンタ１０１０は未だインクリメントされる。

【０３３１】 別の実施例として、パケットキューを５つの領域に分割する上述した別の実施
形態において、適切な確率インジケータは、領域０および１の場合に０００００
０００を、領域２の場合に０００００００１を、領域３の場合に０００００１０
１を、そして領域４の場合に０１１１１１１１を含み得る。従って、この別の実
施形態において、領域１は、領域０への拡張子（ｅｘｔｅｎｓｉｏｎ）として扱
われる。さらに、パケットがドロップされる確率は、０％から８７．５％へと広
がる。

【０３３２】 上述した１つの別の実施形態において、パケットキューの一部のみが、複数の
領域に分割される。この別の実施形態において、パケットがドロップされるデフ
ォルトの確率またはヌルの確率（例えば、００００００００）は、未分割部分と
関連付けられ得る。例示として、これは、キュー中に格納されているトラフィッ
クのレベルが第１の閾値に達するまではパケットがドロップされないことを確実
にする。キュー全体が分割される実施形態においても、デフォルトの確率または
ヌルの確率が、０ＫＢの閾値を包含または０ＫＢの閾値に接する領域と関連付け
られ得る。

【０３３３】 本発明の目的のためにパケットキューを任意の数の領域に分割することが可能
であるのと同様に、確率インジケータは、任意のサイズまたは大きさのビットマ
スクを含み得、互いに等しいサイズまたは大きさでなくてもよい。さらに、確率
インジケータは本発明においてプログラム可能であり、これにより、ネットワー
クインターフェースの動作中にも確率インジケータを変更することが可能となる
。

【０３３４】 確率インジケータを基本としてパケットを廃棄する場合、廃棄プロセスにラン
ダム性が注入される。早期にランダムに廃棄する方針は、上述した壊されたパイ
プの問題を回避するには十分であり得る。詳細には、本発明の１つの実施形態に
おいて、全パケットを廃棄可能であると見なし、これにより、全パケットを、カ
ウンタ１０１０によってカウントし、ドロップ対象とする。しかし、上述したよ
うに、本発明の別の実施形態において、特定の種類のパケットを廃棄対象から除
外するプロセスにインテリジェンスを付加する。

【０３３５】 確率インジケータおよびカウンタは、単に、ネットワークインターフェース中
のパケットをランダムに廃棄することをイネーブルする１つのシステムを構成す
ること、が理解される。他のメカニズムも適切である。別の１つの実施形態にお
いて、カウンタおよび／または確率インジケータの代わりに乱数発生器を用いて
、ランダムな廃棄方針をイネーブルすることが可能である。例えば、乱数（例え
ば、Ｍ）が生成された場合、Ｍ番目のパケット（またはＭ番目毎のパケット）は
、当該番号が生成された後、ドロップされ得る。または、乱数は、パケットがド
ロップされる確率を指定し得る。従って、乱数は、特定の範囲の値または確率に
限定（例えばハッシュ）され得る。別の代替例として、乱数発生器を、複数の領
域またはパケットキュー中の閾値と連係して用いることもできる。この別の実施
形態において、プログラム可能な値（この実施形態ではＮとして示す）を、領域
またはキュー閾値と関連付けることが可能である。次いで、トラフィックインジ
ケータがその閾値または領域に達した場合、別の閾値または境界に到達するまで
、Ｎ番目のパケット（またはＮ番目毎のパケット）がドロップされ得る。

【０３３６】 本発明のさらに別の実施形態において、パケットがドロップされる確率は、バ
イナリフラクションとして表され得る。バイナリフラクションは、一連のビット
からなり、この一連のビットにおいて、各ビットは、自身のより上位の隣接ビッ
トの大きさの半分を表す。例えば、本発明の１つの実施形態において、バイナリ
フラクションは、４桁を用い得る。左から右に向かって、これらのビットは、０
．５、０．２５、０．１２５および０．０６２５をそれぞれ示し得る。従って、
１０１０のバイナリフラクションは、パケットがドロップする確率が６２．５％
（例えば、５０％＋１２．５％）であることを示すものとして解釈される。バイ
ナリフラクション中において用いられる状態（例えば、ビット）が多いほど、正
確度も増す。

【０３３７】 この別の実施形態の１つの実現例において、別のパケットカウンタが、各桁と
関連付けられる。左端ビット用のカウンタは、次のカウンタの速度の２倍でイン
クリメントされ、次のカウンタは、自身の次のカウンタの２倍速度でインクリメ
ントされるといった具合である。言い換えれば、最上位（例えば、左の）ビット
用のカウンタが０から１にインクリメントした場合、残りのカウンタは変化しな
い。最上位カウンタが１から０に再度インクリメントした場合、次のカウンタは
、０から１にインクリメントする。同様に、第３のビット用のカウンタは、第２
のカウンタが０に戻るまでは、０から１にインクリメントしない。以上をまとめ
ると、最上位ビット用のカウンタは、パケットが受け取られるたびに変化する（
すなわち、インクリメントされる）。次の最上位ビット用のカウンタは、インク
リメントされるまで、２つのパケットについて各値（すなわち、０または１）を
保持する。同様に、３番目の上位ビット用のカウンタは、インクリメントされる
まで４つのパケットについて各カウンタ値を保持し、最下位ビット用のカウンタ
は、インクリメントされるまで８つのパケットについて自身の値を保持する。

【０３３８】 パケットが受け取られるたびまたはカウンタがインクリメントされるたびに、
カウンタを、確率インジケータ（例えば、指定されたバイナリフラクション）と
比較する。１つの実施形態において、パケットがドロップされるか否かの判定は
、１に等しいフラクションのビットによる。例示として、各フラクションビット
が１に等しい場合において、対応するカウンタが１に等しく、より上位の任意の
ビット用のカウンタが０に等しい場合、ランダムなパケットがドロップされる。
従って、実施例のフラクション１０１０の場合、最上位ビットのカウンタが１に
等しくなるたびに、ランダムなパケットがドロップされる。加えて、第３のビッ
トが１に等しくなるたびおよび最初の２つのビットのカウンタが０に等しくなる
たびにも、ランダムなパケットがドロップされる。

【０３３９】 ネットワークにおいて受け取られたパケットをドロップする確率を特定および
実現（ｅｎｆｏｒｃｅ）するための他の適切なメカニズムが、本発明の範囲を越
えることなく導出され得る。

【０３４０】 前述したように、ランダムに廃棄を行う方針にインテリジェンスを付加して，
特定の種類のパケットが廃棄される事態を回避することが可能である。前セクシ
ョンにおいて、ネットワークから受け取られたパケットを構文解析する方法につ
いて説明した。詳細には、本発明のこの実施形態において、ネットワークから受
け取られたパケットは構文解析され、その後、パケットキュー（例えば、パケッ
トキュー１０００）中に配置される。構文解析プロシージャの間、パケットに関
する様々な情報が、少量ずつ収集され得る。この情報を用いて、ランダムな廃棄
方針にインテリジェンスを注入することが可能である。詳細には、パケットヘッ
ダーの１つ以上のフィールドのコピー、パケットの発信元エンティティまたは宛
先エンティティの識別、またはプロトコルの識別などが可能である。

【０３４１】 従って、本発明の様々な実施形態において、特定のパケットまたは種類のパケ
ットを、廃棄対象から免除することが可能である。図１０に図示の実施形態にお
いて、例えば、制御パケットが免除される。当業者であれば理解するように、制
御パケットは、通信接続の確立、再確立または維持に必要な情報を含む場合が多
い。従って、制御パケットがドロップされると、制御パケットではないパケット
がドロップされる場合よりもより深刻かつ損害が大きくなり得る。加えて、制御
パケットは一般的にはデータを含まない場合が多いため、制御パケットをドロッ
プしても、パケットキュー中のごく僅かなスペースしか節約できない。

【０３４２】 パケットを免除するための他の多くの基準が可能である。例えば、前セクショ
ンで説明したプロシージャに従ってパケットを構文解析する場合、Ｎｏ＿Ａｓｓ
ｉｓｔフラグまたは信号をそのパケットと関連付けて、そのパケットが一連の予
め選択された通信プロトコルと適合するか否かを示すことが可能である。例示と
して、フラグが第１の値（例えば、１）に設定された場合または信号が生成（ｒ
ａｉｓｅｄ）された場合、そのパケットは不適合であり、ゆえに特定の処理強化
（例えば、パケットデータのリアセンブリ、パケットヘッダーのバッチ処理、付
加分散）に対して不適格であると見なされる。Ｎｏ＿Ａｓｓｉｓｔフラグが第１
の値に設定されるパケットは予期されていないプロトコルまたは独自の形式に適
合するパケットであり得るため、このようなパケットはドロップさせないほうが
良い場合がある。例えば、ネットワークマネージャは、このようなパケット全て
の受け取りを確認して、構文解析プロシージャをさらなるプロトコルを構文解析
する能力で強化すべきか否かを判定することを欲し得る。

【０３４３】 Ｎｏ＿Ａｓｓｉｓｔパケット（例えば、一連の選択されたプロトコルに適合し
ないパケット）を廃棄対象から免除する別の理由は、パケットをドロップさせる
ことに対する応答に関する。パケットのプロトコルは識別されないため、パケッ
トが無くなることに対するパケットのプロトコルの応答は未知であり得る。詳細
には、パケットの伝送者は、パケットのドロップに応答して（例えば、混雑制御
の一形態として）自身の伝送速度を降下させない場合、パケットをドロップさせ
ることにより得られる利点（ｂｅｎｅｆｉｔ）は無くなる。

【０３４４】 本発明の別の実施形態において、パケットのフロー番号を用いて、特定のパケ
ットを免除することが可能である。前セクションにおいて説明したように、ネッ
トワークインターフェースは、フローデータベースおよびフローデータベースマ
ネージャを含み、これにより、ネットワークインターフェースによって受け取ら
れる複数の通信フローの記録を維持することが可能である。パケットを１つ以上
の特定のフローから廃棄される事態を回避できれば、効果的であり得る。免除さ
れるフローは、優先度の高いネットワークエンティティを含むフロー、特定のア
プリケーションを含むフロー等を含み得る。例えば、１個のパケットまたは数個
のパケットが無くなっても宛先エンティティに深刻な影響を与えず、パケットを
再伝送する必要さえ無いアニメーションまたはストリーミンググラフィックスア
プリケーションからパケットを廃棄する方が比較的損害が少ないと考えられ得る
。それとは対照的に、ファイル伝送接続部から数個のパケットがドロップされた
場合、その結果はより深刻であり得、パケットを再伝送する必要が出てくる確率
があり、その結果、伝送側エンティティのウィンドウは収縮し得、そのため、フ
ァイル伝送速度が低下し得る。

【０３４５】 本発明のさらに別の実施形態において、確率インジケータは、各ビットがネッ
トワークインターフェースを通じてセパレートな特定のフローに対応するビット
マスクを含み得る。詳細には、これらのビットは、前セクションにおいて説明し
たフローデータベースにおいて維持されるフローに対応し得る。

【０３４６】 このセクションにおいて、今まで説明してきた本発明の実施形態は、パケット
がパケットキューに到着した際にパケットを廃棄する工程を含むが、別の実施形
態において、パケットは、パケットキュー内から廃棄され得る。詳細には、パケ
ットキューがフルになる（例えば、トラフィックインジケータが所定の領域また
は閾値に達する）と、当該キューに既に格納されているパケットは、１つ以上の
確率インジケータに従ってランダムに廃棄され得る。図１０に図示の実施形態に
おいて、例えば、トラフィックインジケータ１００８が特定の閾値（例えば、領
域１と領域２との間の境界またはキューの終端部分）に達すると、関連する確率
インジケータに従って、１つ以上の領域においてパケットが廃棄され得る。この
ような確率インジケータは、図１０に示すものよりも、異なる値を有する確率が
高い。

【０３４７】 本発明のこの実施形態において、パケットキューが分割される確率インジケー
タおよび／またはその詳細（ｓｐｅｃｉｆｉｃａｔｉｏｎｓ）（例えば、境界）
は、プログラム可能であり、ホストコンピュータ（例えば、デバイスドライバ）
上で動作するソフトウェアによって調節され得る。パケットを免除する基準もプ
ログラム可能である。従って、ネットワークインターフェースまたは他の通信デ
バイスにおいてパケットを廃棄する方法は、このようなデバイスが連続的に動作
している場合であっても、このセクションにおいて説明する実施形態に従って改
変可能である。パケットをランダムに廃棄し、かつ／またはパケットをインテリ
ジェントに廃棄するための基準を適用するための様々な他の実施形態および基準
が、当業者にとって明らかである。

【０３４８】 図１１Ａ〜１１Ｂは、図１０に示す実施形態と実質的の同様の本発明の実施形
態に従って、ネットワークインターフェースにおいてパケットをランダムに廃棄
する方針をインプリメントする１つの方法を示すフローチャートを含む。この実
施形態において、パケットキュー１０００がまだフルでない間、パケットが受け
取られる。当業者であれば理解するように、この実施形態は、パケットを廃棄す
るか否かを判定する方法を提供する。パケットキュー１０００がフルになった後
は、別のパケットが受け取られると、ネットワークインターフェースは概して、
直前に受け取られたパケットまたはキュー中に既に格納されているパケットのい
ずれかをドロップさせなければならない。この場合、ドロップ対象パケットのみ
が決定される。

【０３４９】 図１１Ａにおいて、状態１１００は開始状態である。状態１１００は、ネット
ワークインターフェース（およびパケットキュー１０００）の初期設定を反映す
るか、または、パケットキューおよびランダムな廃棄方針に関する１つ以上のパ
ラメータまたは局面が変更される場所であるネットワークインターフェースのオ
ペレーションにおけるポイントを反映し得る。

【０３５０】 状態１１０２において、恐らくは境界（例えば、図１０に示す８ＫＢの境界お
よび１２ＫＢの境界）を特定することにより、パケットキュー１０００において
１つ以上の領域を識別する。図１０に示す領域は、同時に見ればパケットキュー
１０００を完全に包含するが、本発明の別の実施形態における領域は、キューを
部分的に包含し得る。

【０３５１】 状態１１０４において、１つ以上の確率インジケータを割り当て、構成する。
図示の実施形態において、１つの確率インジケータに各領域を関連付ける。ある
いは、複数の領域を１つの確率インジケータと関連付けてもよい。さらには、１
つ以上の領域を１つの確率インジケータと明示的に関連付けることが不可能な場
合もあり、その場合、デフォルトの確率インジケータまたはヌルの確率インジケ
ータが取られ得る。上述したように、確率インジケータは、マルチビットマスク
の形態をとり得、これにより、マルチビットマスク中のビット数は、パケットカ
ウンタが保持し得る範囲の値を反映する。本発明の別の実施形態において、確率
インジケータは、乱数または閾値の形態をとり得、これらの値は、パケットを廃
棄すべきか否かの決断が必要な際にランダムに生成された数字の比較対象となる
。

【０３５２】 状態１１０６において、特定の種類のパケットを廃棄対象から外す場合、免除
されるパケットを識別するための基準が示される。免除され得るパケットとして
は、制御パケット、未知のプロトコルあるいは特定の公知のプロトコルに適合す
るパケット、特定のネットワーク接続あるいはフローに所属するパケットなどが
ある。本発明の１つの実施形態において、免除されるパケットは無い。

【０３５３】 状態１１０８において、パケットまたはトラフィックカウンタが初期設定され
る。上述したように、廃棄可能なパケットが格納対象としてパケットキュー１０
００において受け取られた場合、恐らくは限定された範囲の値を通じて、カウン
タがインクリメントされ得る。限定された範囲のカウンタ値は、マスク形式の確
率インジケータ中のビット数に対応し得る。あるいは、カウンタは、より広範囲
にインクリメントされるようにも構成され得、その場合、カウンタ値をモジュラ
ス関数またはハッシュ関数を通じてフィルタリングし、その後、以下に説明する
ように確率インジケータと比較してもよい。

【０３５４】 状態１１１０において、ネットワークからパケットが受け取られ、１つ以上の
モジュール（例えば、ヘッダーパーサ、ＩＰＰモジュール）を通じて処理され、
その後、パケットは、パケットキュー１０００に到着し得る。従って、状態１１
１０において、パケットは、パケットキューへ格納される準備ができている。１
つ以上のパケットがパケットキュー中に既に格納されており、トラフィックイン
ジケータ（例えば、ポインタまたはインデックス）は、（例えば、格納位置およ
び／またはキュー中の領域を用いて）キュー中に格納されているトラフィックの
レベルを識別し得る。

【０３５５】 状態１１１２において、受け取られたパケットが廃棄可能か否かが判定され得
る。例えば、ランダムな廃棄方針が特定のパケットを廃棄対象から免除すること
を実際に可能にする場合、状態１１１２において、受け取られたパケットがその
免除基準の１つ１つを満たすか否かが判定される。受け取られたパケットがその
免除基準の１つ１つを満たす場合、図示のプロシージャは状態１１２２に進む。
受け取られたパケットがその免除基準の１つ１つを満たさない場合、プロシージ
ャは状態１１１４に進む。

【０３５６】 状態１１１４において、パケットキュー１０００のアクティブ領域を識別する
。詳細には、現在トラフィックでパケットキューがポピュレートされているパケ
ットキューの領域を判定する。キュー中に格納されるトラフィックのレベルは、
ホストコンピュータへの伝送対象としてキュー中に格納され待機しているパケッ
トの数およびサイズに依存する。伝送プロセスが遅いほど、キュー中でトラフィ
ックが到達し得るレベルも高くなる。キュー中に格納されているトラフィックの
レベルは、パケットの格納および伝送が行なわれる際に上下するが、このレベル
は、トラフィックインジケータを調査することにより所与の時期に識別され得る
。トラフィックインジケータは、キュー中の最後のパケットの位置または次に格
納されるパケットを識別するポインタを含み得る。このようなポインタは、ホス
トコンピュータに伝送される予定の次のパケットを識別する別のポインタと比較
され得、これにより、キュー中に格納されるトラフィック量を明らかにすること
ができる。

【０３５７】 状態１１１６において、カウンタ値（例えば、図１０の実施形態における０〜
７の値）を、アクティブな領域と関連付けられた確率インジケータと比較する。
上述したように、廃棄可能なパケットがキューにおいて受け取られたときに、こ
のカウンタをインクリメントする。この比較は、受け取られたパケットを廃棄す
べきか否かを判定するために行なわれる。上記にて説明したように、図１０の実
施形態において、カウンタ値に対応する確率インジケータビットの設定を調査す
る。例えば、カウンタの値がＮである場合、確率インジケータマスクのビット数
Ｎを調査する。ビットが第１の状態（例えば、１）に設定されている場合、その
パケットを廃棄し、そうでない場合、そのパケットは廃棄しない。

【０３５８】 状態１１１８において、パケットを廃棄するか否かに関わらず、カウンタをイ
ンクリメントして、廃棄可能なパケットの受取りを反映する。本発明のここで説
明している実施形態において、カウンタがインクリメントされる前の時点で自身
の最大値（例えば、７）を含む場合、そのカウンタをインクリメントすると、そ
のカウンタは自身の最小値（例えば、０）に再設定される。

【０３５９】 状態１１２０において、パケットを廃棄する場合、図示のプロシージャは状態
１１２４に進む。パケットを廃棄しない場合、プロシージャは状態１１２２に進
む。状態１１２２において、そのパケットをパケットキュー１０００中に格納し
、図示のプロシージャは終了状態１１２６と共に終了する。状態１１２４におい
て、パケットを廃棄し、図示のプロシージャは終了状態１１２６と共に終了する
。

【０３６０】 １９９９年３月１日に出願され、「Ａ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ
Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ」と題する、米国特許出願第０９／２５９
，７６５号は、本発明の本実施形態が為され得るネットワークインターフェース
のさらなる詳細を提供し、同出願は参考として本明細書中で援用される。

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

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

【図８】 図８は、本発明の実施形態に従う、ネットワークインターフェース回路に関す
るパケットキューの図である。

【図９】 図９は、本発明の実施形態に従う、ネットワークインターフェース回路に関す
る制御キューの図である。

【図１０】 図１０は、本発明の実施形態に従う、ネットワークインターフェースからパケ
ットをランダムに廃棄するシステムを示す図である。

【図１１Ａ】 図１１Ａは、本発明の実施形態に従う、ネットワークインターフェースからパ
ケットを廃棄する１方法を示すフローチャートである。

【図１１Ｂ】 図１１Ｂは、本発明の実施形態に従う、ネットワークインターフェースからパ
ケットを廃棄する１方法を示すフローチャートである。

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

【手続補正書】

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

【手続補正１】

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

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

【補正方法】変更

【補正の内容】

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

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ， ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，Ｓ Ｋ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 チェン， リンダ アメリカ合衆国 カリフォルニア 95129， サン ノゼ， バーケット ドライブ 1318 (72)発明者 ジェントリー， デントン アメリカ合衆国 カリフォルニア 94555， フレモント， シー クリフ テラス 34892 Ｆターム(参考） 5K030 HA08 KA01 KA02 LC18 MB09

Claims (42)

【特許請求の範囲】
1. 【請求項１】 ネットワークから受け取られたパケットをランダムに廃棄す
   る方法であって、 ネットワークから受け取られたパケットを格納するために構成されたパケット
   格納デバイス内の複数の領域を識別する工程と、 該複数の領域の各々について、該ネットワークから受け取られたパケットを廃
   棄する確率を維持する工程と、 第１のパケットをネットワークから受け取る工程と、 該パケット格納デバイスが、該複数の領域のうちどれについて満たされるかを
   識別する工程と、 パケットを廃棄するかどうかを判定するために、該識別された領域と関連のあ
   る該確率を適用する工程と を包含する方法。
2. 【請求項２】 パケットカウントを維持する工程であって、廃棄可能なパケ
   ットが前記ネットワークから受け取られる場合、該パケットカウントがインクリ
   メントされる工程、をさらに包含する、請求項１に記載の方法。
3. 【請求項３】 廃棄可能なパケットが制御パケット以外のパケットである、
   請求項２に記載の方法。
4. 【請求項４】 前記パケット格納デバイスに格納するために受け取られた全
   パケットが廃棄可能である、請求項２に記載の方法。
5. 【請求項５】 前記パケットカウントが、Ｎ値まで繰り返しインクリメント
   される、請求項２に記載の方法。
6. 【請求項６】 前記確率を維持する工程が、Ｎ個のサブインジケータを備え
   る確率インジケータを維持する工程を包含し、 前記適用する工程が、該確率インジケータのＭ番目のサブインジケータを調べ
   、前記パケットカウントがＭ（Ｍ≦Ｎ）である場合、前記第１のパケットを廃棄
   するかどうかを判定する工程を包含する、請求項５に記載の方法。
7. 【請求項７】 前記確率を維持する工程が、Ｎ個のサブインジケータを備え
   る確率インジケータを維持する工程を包含し、 前記適用する工程が、該確率インジケータのＭ番目のサブインジケータを調べ
   、前記パケットカウントがＭ（Ｍ≦Ｎ）である場合、前記受け取る工程の前に前
   記パケット格納デバイスに格納されたパケットが廃棄されるかどうかを判定する
   工程を包含する、請求項５に記載の方法。
8. 【請求項８】 前記第１のパケットが廃棄される場合、前記Ｍ番目のサブイ
   ンジケータが第１の値を含み、該第１のパケットが廃棄されない場合、該Ｍ番目
   のサブインジケータが第２の値を含む、請求項６に記載の方法。
9. 【請求項９】 前記確率がランダムに生成される値を含む、請求項１に記載
   の方法。
10. 【請求項１０】 前記パケットが、前記パケット格納デバイスに格納するた
    めに受け取られる場合、前記確率がランダムに生成される第２の値と比較するた
    めの第１の値を含む、請求項１に記載の方法。
11. 【請求項１１】 前記パケット格納デバイスが、どの程度フルであるかを示
    すために構成された、トラフィックインジケータを維持する工程をさらに包含す
    る、請求項１に記載の方法。
12. 【請求項１２】 前記トラフィックインジケータが、前記パケット格納デバ
    イスに関連する１以上のポインタを調べるために構成される、請求項１１に記載
    の方法。
13. 【請求項１３】 前記トラフィックインジケータが前記複数の領域のうち１
    つを識別する、請求項１１に記載の方法。
14. 【請求項１４】 前記複数の領域を識別する工程が、前記パケット格納デバ
    イスの第１の領域を、該パケット格納デバイスの第２の領域から分離させるパケ
    ット格納デバイス閾値を識別する工程を包含する、請求項１に記載の方法。
15. 【請求項１５】 前記確率を維持する工程が、 前記第１の領域に第１の確率を割り当てる工程と、 前記第２の領域に第２の確率を割り当てる工程と を包含する、請求項１４に記載の方法。
16. 【請求項１６】 前記第１のパケットをネットワークから受け取る工程が、
    ネットワークから受け取られた第１のパケットの１以上のヘッダを調べる工程を
    包含する、請求項１に記載の方法。
17. 【請求項１７】 前記調べる工程が、前記ヘッダのうちの１つにおけるフィ
    ールドを取り出すことにより、前記パケットの特性を判定する工程を包含する、
    請求項１６に記載の方法。
18. 【請求項１８】 前記確率を適用する工程が、前記確率をパケットカウント
    と比較する工程を包含する、請求項１に記載の方法。
19. 【請求項１９】 前記確率がインジケータのセットを含み、前記適用する工
    程が、 該インジケータのセットのうち第１のインジケータが第１の状態にある場合、
    前記パケットを廃棄する工程であって、該第１のインジケータが該パケットカウ
    ントに関連付けられる、工程と、 該第１のインジケータが第２の状態にある場合、該パケットを前記パケット格
    納デバイスに格納する工程と をさらに包含する、請求項１８に記載の方法。
20. 【請求項２０】 前記第１のインジケータが、第１の値を前記第１の状態に
    格納し、該第１のインジケータが、第２の値を前記第２の状態に格納する、請求
    項１９に記載の方法。
21. 【請求項２１】 通信デバイスで、ネットワークから受け取られたパケット
    をランダムに廃棄する方法であって、 パケットキューにおける複数の領域を判定する工程であって、該パケットキュ
    ーが、ネットワークから受け取られたパケットを格納するために構成される、工
    程と、 確率インジケータを前記複数の領域のうちの各々と関連付ける工程と、 パケットカウントを格納するために構成されるカウンタを維持する工程であっ
    て、該パケットカウントがパケットカウントの所定の範囲まで繰り返しインクリ
    メントされ、廃棄可能なパケットが該パケットキューに格納するために受け取ら
    れる場合、該パケットカウントがインクリメントされる、工程と、 該パケットキューに格納されたトラフィックのレベルを識別するためにトラフ
    ィックインジケータを維持する工程と、 該パケットキューに格納するために、ネットワークからパケットを受け取る工
    程と、 該パケットが廃棄可能かどうかを判定する工程と、 前記複数の領域の第１の領域を識別する工程であって、該第１の領域が、該パ
    ケットキューに格納された該識別されたトラフィックのレベルを含む、工程と、 該パケットを廃棄するかどうかを判定するために該確率インジケータを調べる
    工程と、 該確率インジケータが第１の値を含む場合、該パケットを廃棄する工程と を包含する、方法。
22. 【請求項２２】 前記通信デバイスがネットワークインターフェースである
    、請求項２１に記載の方法。
23. 【請求項２３】 前記複数の領域を識別する工程が、１以上の境界を選択す
    る工程を包含し、該１以上の境界の各々が前記複数の領域のうちの１つの領域を
    、該複数の領域のうち他の領域から分離させる、請求項２１に記載の方法。
24. 【請求項２４】 前記確率インジケータを関連付ける工程が、別個の確率イ
    ンジケータを前記複数の領域の各々と関連付ける工程を包含する、請求項２１に
    記載の方法。
25. 【請求項２５】 前記確率インジケータを関連付ける工程が、別個の確率イ
    ンジケータを初期領域以外の前記複数の領域のうちの各々と関連付ける、請求項
    ２１に記載の方法。
26. 【請求項２６】 前記パケットが廃棄可能かどうかを判定する工程が、前記
    パケットが廃棄されることを免除するために、該パケットが基準のセットのうち
    の任意の基準を満たすかどうかを判定する工程を包含する、請求項２１に記載の
    方法。
27. 【請求項２７】 前記確率インジケータを調べる工程が、 前記パケットカウントを前記カウントから取り出す工程であって、該パケット
    カウントがＮである、工程と、 該パケットカウントに対応する該確率インジケータの一部を調べる工程と を包含する、請求項２１に記載の方法。
28. 【請求項２８】 前記一部がＮ番目のサブインジケータを前記確率インジケ
    ータに含み、前記Ｎ番目のインジケータが第１の状態にある場合、前記パケット
    が廃棄される、請求項２７に記載の方法。
29. 【請求項２９】 前記確率インジケータが第２の値を含む場合、前記パケッ
    トを前記パケットキューに格納する工程をさらに包含する、請求項２１に記載の
    方法。
30. 【請求項３０】 ネットワークから受け取られたパケットをランダムに廃棄
    する通信デバイスであって、 ネットワークから受け取られたパケットを格納するために構成されたパケット
    格納デバイスであって、該パケット格納デバイスが複数の領域を備える、パケッ
    ト格納デバイスと、 該パケット格納デバイスに格納されたパケットのレベル識別するために構成さ
    れたトラフィックインジケータと、 該トラフィックインジケータが、該複数の領域の第１の領域内のパケットのレ
    ベルを識別する場合、ランダムにパケットをドロップする確率を示すために構成
    された第１の確率インジケータと、 該トラフィックインジケータが、該複数の領域の第２の領域内のパケットのレ
    ベルを識別する場合、ランダムにパケットをドロップする確率を示すために構成
    された第２の確率インジケータと を備える通信デバイス。
31. 【請求項３１】 前記通信デバイスがネットワークインターフェースである
    、請求項３０に記載の通信デバイス。
32. 【請求項３２】 パケットカウントを格納するために構成されたカウンタで
    あって、該パケットカウントは、パケットが前記ネットワークから受け取られた
    後、インクリメントするために構成される、カウンタをさらに備える、請求項３
    ０に記載の通信デバイス。
33. 【請求項３３】 前記パケット格納デバイスが、ホストコンピュータへの転
    送用のパケットを格納するためにさらに構成される、請求項３０に記載の通信デ
    バイス。
34. 【請求項３４】 前記第１の確率インジケータが、パケットをドロップする
    かどうかを判定するためにランダムに生成された数を含む、請求項３０に記載の
    通信デバイス。
35. 【請求項３５】 パケットが前記ネットワークから受け取られる場合、前記
    第１の確率インジケータがランダムに生成される第２の値と比較するための第１
    の値を含む、請求項３０に記載の通信デバイス。
36. 【請求項３６】 前記第１の確率インジケータが、サブインジケータのセッ
    トを備え、第１のサブインジケータが、前記ネットワークから受け取られる第１
    のパケットがドロップされることを示す第１の値、または該第１のパケットがド
    ロップされないことを示す第２の値のいずれかを含む、請求項３０に記載の通信
    デバイス。
37. 【請求項３７】 パケットカウントを格納するために構成されたカウンタで
    あって、パケットが前記ネットワークから受け取られる場合、前記パケットカウ
    ントがインクリメントされる、カウンタをさらに備え、 前記第１のパケットが受け取られる場合、該カウンタに格納されるパケットが
    前記第１のサブインジケータを識別する、請求項３６に記載の通信デバイス。
38. 【請求項３８】 命令を格納するコンピュータ読み出し可能格納媒体であっ
    て、コンピュータが該命令を実行する場合、該コンピュータがネットワークから
    パケットをランダムに廃棄する方法を実行し、該方法は、 ネットワークから受け取られたパケットを格納するために構成されたパケット
    格納デバイス内の複数の領域を識別する工程と、 該複数の領域の各々について、該ネットワークから受け取られたパケットを廃
    棄する確率を維持する工程と、 第１のパケットをネットワークから受け取る工程と、 パケットを廃棄するかどうかを判定するために、該識別された領域と関連のあ
    る該確率を適用する工程と を包含する、コンピュータ読み出し可能格納媒体。
39. 【請求項３９】 前記パケット格納デバイスが、前記識別された領域内のレ
    ベルまで満たされる限り、パケットを廃棄する確率が適用されると、該識別され
    た領域に関連付けられた該確率が適用される、請求項１に記載の方法。
40. 【請求項４０】 前記識別された領域と関連付けられた前記確率が、置換確
    率と置換されるまで、パケットを廃棄する確率が適用されると、該識別された領
    域に関連付けられた該確率が適用される、請求項１に記載の方法。
41. 【請求項４１】 前記識別された領域に関連付けられた前記確率が、バイナ
    リフラクションとして表現される、請求項１に記載の方法。
42. 【請求項４２】 前記トラフィックインジケータが前記第１の領域を識別す
    る間、後続のパケットが前記パケットキューに格納するために受け取られるたび
    に、該後続のパケットを廃棄するかどうかを判定するために、前記確率インジケ
    ータを適用する工程をさらに包含する、請求項２１に記載の方法。