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

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

Info

Publication number
JP2002538725A
JP2002538725A JP2000603198A JP2000603198A JP2002538725A JP 2002538725 A JP2002538725 A JP 2002538725A JP 2000603198 A JP2000603198 A JP 2000603198A JP 2000603198 A JP2000603198 A JP 2000603198A JP 2002538725 A JP2002538725 A JP 2002538725A
Authority
JP
Japan
Prior art keywords
packet
flow
indicator
packets
probability
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2000603198A
Other languages
English (en)
Inventor
シモン ムラー,
リンダ チェン,
デントン ジェントリー,
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of JP2002538725A publication Critical patent/JP2002538725A/ja
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/901Buffering arrangements using storage descriptor, e.g. read or write pointers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9047Buffering arrangements including multiple buffers, e.g. buffer pools
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9063Intermediate storage in different physical parts of a node or terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9063Intermediate storage in different physical parts of a node or terminal
    • H04L49/9068Intermediate storage in different physical parts of a node or terminal in the network interface card
    • H04L49/9073Early interruption upon arrival of a fraction of a packet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9084Reactions to storage capacity overflow

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

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

Description

【発明の詳細な説明】
【0001】 (背景) 本発明は、コンピュータシステムおよびコンピュータネットワークの分野に関
する。特に、本発明は、コンピュータネットワークとホストコンピュータシステ
ムとの間で交換される通信パケットを処理するためのネットワークインターフェ
ース回路(NIC)に関する。
【0002】 コンピュータとネットワークとの間のインターフェースはしばしば、そのコン
ピュータとネットワークとの間を通過する通信についてボトルネックとなる。コ
ンピュータ性能(例えば、プロセッサ速度)が、年月を経て指数関数的に向上し
、コンピュータネットワーク伝送速度も同じような向上を経験してきたが、ネッ
トワークインターフェース回路が通信を処理する際の非効率性が次第に明らかに
なってきた。コンピュータまたはネットワークの速度がそれぞれ増加すると、コ
ンピュータとネットワークとの間のインターフェースがついていけないことがさ
らに明らかになった。これらの非効率性は、ネットワークとコンピュータとの間
の通信が処理されるという点でいくつかの基本的な問題を含んでいる。
【0003】 今日の最もポピュラーなネットワークの形態は、パケットベースとなる傾向が
ある。これらのネットワークのタイプには、インターネットおよび多くのローカ
ルエリアネットワークが挙げられ、パケットの形態で情報を伝送する。各パケッ
トは、発信元のエンドステーション(endstation)により別々に作成
され、伝送される。そして、宛先のエンドステーションにより別々に受け取られ
、処理される。さらに、各パケットは、例えばバストポロジネットワークにおい
て、発信元エンドステーションと受信先エンドステーションとの間に配置された
多数のステーションにより受け取られ処理され得る。
【0004】 パケットネットワークに関する1つの基本的な問題は、各パケットが、発信元
エンドステーションおよび受信先エンドステーションの両方において、複数のプ
ロトコルまたはプロトコルレベル(「プロトコルスタック」として総称されて公
知である)により処理される必要があることである。ステーション間で伝送され
るデータが、ある最小長よりも長いと、このデータは複数の部分へと分割され、
そして各部分は別々のパケットによって運ばれる。パケットが運ぶことができる
データの量は、一般にそのパケットを運搬するネットワークにより限定され、し
ばしば最大伝送単位(MTU)として表現される。データの元の集合はしばしば
、「データグラム」として知られており、1つのデータグラムの一部を運ぶ各パ
ケットは、そのデータグラムの別のパケットと非常に類似して処理される。
【0005】 通信パケットは、一般に以下のように処理される。発信元エンドステーション
において、データグラムの別々のデータ部分のそれぞれは、プロトコルスタック
により処理される。この処理の間、複数のプロトコルヘッダー(例えば、TCP
、IP、イーサネット(登録商標))がこのデータ部分に加えられ、ネットワー
クにわたって伝送され得るパケットを形成する。このパケットはネットワークイ
ンターフェース回路により受け取られ、このネットワークインターフェース回路
は受け取ったパケットを宛先エンドステーションまたは宛先エンドステーション
の機能をするホストコンピュータへ伝送する。宛先エンドステーションでは、こ
のパケットは、発信元エンドステーションとは反対の方向のプロトコルスタック
により処理される。この処理の間、プロトコルヘッダーが、それらが付与される
反対の順序で取り除かれる。従って、このデータ部分は復元され、ユーザ、アプ
リケーションプログラム等に利用可能にされ得る。
【0006】 従って、いくつかの関連のパケット(例えば、1つのデータグラムからデータ
を運ぶパケット)は、連続的な態様(すなわち、一度に1つのパケット)で、実
質的に同じプロセスを受ける。伝送されるべきデータがより多くなると、より多
くのパケットが送信される必要がある。これらの各パケットは、各方向でプロト
コルスタックにより、別々に扱われ、処理される。当然、処理されるべきパケッ
トがより多くなると、エンドステーションのプロセッサに課せられる要求も大き
くなる。処理されるべき多くのパケットは、データグラムで送信されているデー
タの量以外のファクターに影響を受ける。例えば、パケットに包まれ得るデータ
の量が増加するにつれて、送信される必要のあるパケットは少なくなっていく。
しかし、上記のように、パケットは最大許容サイズを有してもよく、これは使用
時のネットワークのタイプによる(例えば、標準イーサネット(登録商標)トラ
フィックについての最大伝送単位は、約1,500バイトである)。ネットワー
クの速度はまた、所定の期間においてNICが処理し得るパケットの数に影響を
与える。例えば、最大能力で動作しているギガビットイーサネット(登録商標)
ネットワークは、NICが約148万パケット/秒を受信することを要求し得る
。従って、プロトコルスタックにより処理されるべき多くのパケットは、コンピ
ュータのプロセッサに顕著な負担となり得る。この状況は、各パケットが実質的
に同じように処理されたとしても、別々に各パケットを処理する必要性により悪
化する。
【0007】 パケットの別々の処理に関する問題は、データ伝送および受信の間に「ユーザ
スペース」(例えば、アプリケーションプログラムのデータ格納装置)と「シス
テムスペース」(例えば、システムメモリ)との間で、データが移動するのと同
様である。現在、データは、ユーザまたはアプリケーションプログラムに割り当
てられたメモリのある領域からプロセッサの使用専用のメモリの別の領域へ単に
コピーされる。パケットで伝送されるデータグラムの各部分は別々にコピーされ
得るので(例えば、一度に1バイト)、必要とされるプロセッサ時間の量は重要
であり、頻繁な伝送により大量のメモリバスの帯域幅が使われ得る。例示的に、
ネットワークから受け取られるパケットのデータの各バイトは、システムスペー
スから読み取ることができ、別々のコピーオペレーションでユーザスペースへ書
き込まれ得る。ネットワーク中に伝送されるデータについて逆も同じである。シ
ステムスペースは、一般にプロテクトされたメモリ領域(例えば、ユーザプログ
ラムによるオペレーションから保護された)を提供するが、コピー動作は、ネッ
トワークインターフェース回路の点から考慮すると、全く有用でない。代わりに
、ホストプロセッサに過剰な負荷をかけ、NICからのさらなるネットワークト
ラフィックを迅速に受け入れる能力を低くするリスクがある。それ故、各パケッ
トのデータを別々にコピーすることは非常に非効率的であり得、特に高速ネット
ワーク環境では非効率的である。
【0008】 データの非効率的伝送(例えば、一度に1つのパケットデータ)に加えて、ネ
ットワークから受け取ったパケットからのヘッダーの処理もまた非効率的である
。1つのデータグラムの部分を運ぶ各パケットは、一般に同じプロトコルヘッダ
ー(イーサネット(登録商標)、IPおよびTCP)を有するが、特定のプロト
コルについてのパケットのヘッダー内の値に幾分変動があり得る。しかし、各パ
ケットは同じプロトコルスタックにより個々に処理され、従って、関連のパケッ
トについて同じオペレーションを複数繰り返すことが必要である。異なるプロト
コルスタックにより関連しないパケットを連続的に処理することは、一度に1つ
のプロトコルスタックによる多数の関連するパケットを順次処理することよりも
あまり効率的でないようである。
【0009】 現在のネットワークインターフェース回路とホストコンピュータシステムとの
間の相互作用に関する別の基本的な問題は、しばしばその組み合わせが、マルチ
プロセッサコンピュータシステムで利用可能な向上したプロセッサリソースを十
分に利用できないことである。言い換えると、多数のプロトコルの間でネットワ
ークパケットの処理(例えば、プロトコルスタックによる)を効率的な態様で分
散する現在の試行は、一般に非効率的である。特に、現在のNICの性能は、複
数のプロセッサの利用可能性から実現されることが期待され得る期待のまたは所
望のリニア性能利得に及ばない。いくつかのマルチプロセッサシステムにおいて
、ネットワークトラフィックの処理においての向上は、例えば4〜6個より多く
のプロセッサを使用しても実現されることはほとんどない。
【0010】 さらに、パケットがネットワークインターフェース回路からホストコンピュー
タまたは他の通信デバイスへ伝送される速度は、ネットワークインターフェース
に到達するパケットの速度と同じペースにできない。ホストコンピュータのある
要素または別の要素(例えば、メモリバス、プロセッサ)は、過剰な負荷がかけ
られ得、そうでない場合は十分に素早くパケットを受信することはできない。こ
の場合に、1つ以上のパケットがドロップされるか廃棄され得る。パケットをド
ロップすると、ネットワークエンティティがいくらかの通信を再伝送させ得、非
常に多くのパケットがドロップされると、ネットワーク接続は再初期化を必要と
し得る。さらに、1つのパケットまたはパケットのタイプを別のパケットの代わ
りにドロップすると、ネットワークトラフィック全体において顕著な差が生じ得
る。例えば、制御パケットがドロップされると、対応するネットワーク接続は深
刻な影響を受け、制御パケットのサイズは典型的には小さいためにネットワーク
インターフェース回路のパケット飽和を緩和することはほとんどできない。従っ
て、パケットのドロップが、多くのネットワーク接続の間での影響を分散するか
、またはあるタイプのパケットを許可するように実行されない限り、ネットワー
クトラフィックは必要以上に低下され得る。
【0011】 従って、現在のNICは、今日のハイエンドコンピュータシステムと高速ネッ
トワークとを相互接続する十分な性能を提供することができない。さらに、過剰
に負荷をかけたホストコンピュータを許容できないネットワークインターフェー
ス回路は、コンピュータの性能を低下し得る。
【0012】 (要旨) 本発明の1実施形態において、パケットはネットワークから受け取られ、ホス
トコンピュータに転送されるより先にパケットキューに格納される。ホストコン
ピュータへのパケットの転送率が、キューでのパケットの到達率と同じペースで
あり得ない場合、1以上のパケットがドロップされ得る。従って、ランダムな方
法でパケットを廃棄するシステムおよび方法が提供され、それにより損失パケッ
トの効果が、ネットワーク通信間で公平に分配される。
【0013】 本発明の1実施形態において、ネットワークから受け取られたパケットを格納
するために使用されるパケットキューが、複数の領域に分割される。各領域は異
なるが、境界を隣接する領域と共有する。代替の実施形態では、領域は重なって
いてもよい。フルネスゲージまたはインジケータが、パケットキューがどの程度
フルであるかを示すために利用される。特に、パケットキューを更新するために
使用される読み出しおよび書き込みポインタがまた、キューがどの程度フルであ
るかを判定するために使用され得る。従って、このフルネスインジケータは、パ
ケットキューに格納されるネットワークトラフィックのレベルが増減するにつれ
て変動する。
【0014】 複数のパケットキューの領域のうち1つ以上の領域について、プログラマブル
確率インジケータが割り当てられる。キューに格納されたトラフィックのレベル
が、確率インジケータの関連領域以内であることをフルネスインジケータが示す
場合、各確率インジケータはパケットをドロップする確率を示す。確率インジケ
ータは、パケットキューのトラフィックのレベルが変化すると、プログラムおよ
び再プログラムされ得る。廃棄されるパケットをランダムに選択するために構成
される確率インジケータは、割合または比の形式を取り得る。
【0015】 本発明の特定の1実施形態において、確率インジケータはビットまたはフラグ
マスクの形式を取る。各ビットまたはフラグは、2つの可能な値(例えば、0お
よび1)のうち1つを取り得る。この実施形態において、カウンタは、0からN
のような制限された範囲の数まで繰り返しカウントすることにより、パケットキ
ューで受け取られるパケット数を追跡する。ビットまたはフラグマスクは同様に
、N+1個のビットまたはフラグを含む。従って、各カウンタ値について、マス
クの対応するビットまたはフラグは、そのカウンタ値がドロップされる間にパケ
ットが受け取られたかどうかを示す。
【0016】 代替の実施形態において、パケットが受け取られると、ランダム数が生成され
る。ランダム数は閾値と比較され、受け取られたパケットがドロップされるかど
うかを判定し得る。各領域は、パケットがドロップされるかどうかを判定する個
別の閾値を有し得る。
【0017】 本発明のさらなる他の実施形態において、パケットは、特定の特性または状態
を示すので無効にされるか、または廃棄されることを免除され得る。例えば、制
御パケットは、ドロップされないあるタイプのパケットであり得る。この実施形
態において、廃棄不可能なパケットが受け取られる場合、カウンタはインクリメ
ントされない。廃棄対象から免除され得る他のパケットは、特定のネットワーク
接続またはフロー内のパケット、特定アプリケーションに関連付けられたパケッ
ト、特定プロトコルに従いフォーマットされたパケット等であり得る。パケット
の関連特性または詳細は、パケットヘッダのうち1つ以上が構文解析するプロセ
スの間に抽出され得る。
【0018】 本発明の1実施形態において、確率インジケータがパケットがドロップされる
べきであることを示す場合、ドロップされるパケットはパケットキューでまさに
受け取られたキューであり得る。しかしながら、他の実施形態において、すでに
パケットキューに格納されたパケットはドロップされてもよい。
【0019】 (詳細な説明) 以下の説明は、いかなる当業者でも本発明を生産および使用することができる
ように示され、本発明の特定の用途およびそれらの用途の要求のコンテクストで
提供される。開示される実施形態の種々の改変が当業者には容易に明らかであり
、本明細書中に規定される一般的原理は、他の実施形態および用途にも本発明の
精神および範囲を逸脱することなく適用し得る。従って、本発明は、示される実
施形態に限定されることを意図するものではなく、本明細書中に開示される原理
および特徴に整合する最も広い範囲を与えられるべきである。
【0020】 特に、本発明の実施形態は、インターネットと互換性のある特定の通信プロト
コルに従ってフォーマットされた通信パケットを受け取るネットワークインタフ
ェース回路(NIC)の形態で記述される。しかしながら、本発明はインターネ
ットと互換性のある通信プロトコルに限定されず、他のプロトコルとの使用およ
びNIC以外の通信デバイスにおける使用に容易に適合させ得ることを当業者は
理解する。
【0021】 本発明の実施形態が実行されるプログラム環境は、例示的に、汎用コンピュー
タまたは携帯型コンピュータなどの特定目的のデバイスを組み込む。そのような
デバイス(例えば、プロセッサ、メモリ、データ格納部、入出力ポートおよびデ
ィスプレイ)の詳細は周知であり、明瞭化の目的のために省略される。
【0022】 本発明の技術が種々のテクノロジーを使用して実現され得ることが理解される
べきである。例えば、本明細書に記載される方法は、プログラム可能なマイクロ
プロセッサ上で実行されるソフトウェアにおいて実現され得、あるいは、マイク
ロプロセッサの組み合わせまたは他の特別に設計された特定用途向け集積回路、
プログラマブルロジックデバイスもしくは種々のそれらの組み合わせを使用した
ハードウェアにおいて実現され得る。特に、本明細書に記載される方法は、搬送
波、ディスクドライブ、または他のコンピュータ読み取り可能な媒体といった格
納媒体上に存在するコンピュータ実行可能な一連の命令によって実現され得る。
【0023】 (導入) 本発明の1つの実施形態では、ネットワークインタフェース回路(NIC)が
、ホストコンピュータシステムとインターネットなどのネットワークとの間で交
換される通信パケットを受け取り、処理するように構成される。特に、NICは
、そのNICが結合されているネットワークによってサポートされるプロトコル
スタック(例えば、通信プロトコルの組み合わせ)に従ってフォーマットされた
パケットを受け取り、操作するように構成される。
【0024】 プロトコルスタックは、ISO−OSI(国際標準化機構−開放型システム間
相互接続)モデルフレームワークを参照して記載され得る。従って、1つの例示
的なプロトコルスタックは、レイヤー4の伝送制御プロトコル(TCP)、レイ
ヤー3のインターネットプロトコル(IP)、およびレイヤー2のイーサネット
(R)を含む。議論の目的のために、用語「イーサネット(R)」は、本明細書
中で、標準化されたIEEE(米国電気電子技術者協会)802.3仕様および
そのプロトコルの非標準の形式のバージョン2を集約的に指すものとして使用さ
れることがある。このプロトコルの異なる形式が区別される必要がある場合には
、標準化された形式は、「802.3」の指定を伴って特定することがある。
【0025】 本発明の他の実施形態は、現時点で既知(例えば、AppleTalk、IP
X(Internetwork Packet Exchange)等)および
未知の両方の他のプロトコルに従う通信とともに動作するように構成される。当
業者は、本発明により提供される方法が、新規な通信プロトコルに容易に適合可
能であることを理解する。
【0026】 さらに、以下に述べるパケット処理は、NIC以外の通信デバイス上でも実行
され得る。例えば、モデム、スイッチ、ルータまたは他の通信ポートもしくはデ
バイス(例えば、シリアル、パラレル、USB、SCSI)が、同様に構成され
、動作させられ得る。
【0027】 以下に述べる実施形態において、NICは、ネットワークから、ホストコンピ
ュータシステムまたは他の通信デバイスのためにパケットを受け取る。NICは
、(例えば、そのパケットの1以上のプロトコルヘッダーからの特定のフィール
ドを取り出すことにより)パケットを解析し、パケットが伝送され、または宛先
エンティティに提供される効率を高めるための動作を行う。以下に議論される、
ネットワークから受け取ったパケットを処理し、あるいは伝送する効率を高める
ための装置および方法は、逆方向(すなわち、NICからネットワークに)に移
動するパケットにも使用され得る。
【0028】 入来ネットワークトラフィックに適用され得る1つの技術は、入来パケットの
1つ以上のヘッダー(例えば、レイヤー2、3および4のプロトコルためのヘッ
ダー)を検査または構文解析することを伴う。これは、そのパケットのソースエ
ンティティおよび宛先エンティティを識別するためであり、場合によっては、特
定の他の情報を取り出すためである。通信しているエンティティの識別子をキー
として使用して、複数のパケットからのデータが集められ、あるいはリアセンブ
ルされ得る。通常、1つのソースエンティティから1つの宛先エンティティに送
られるデータグラムは、複数のパケットを介して送信される。このようにして、
複数の関連するパケット(例えば、同じデータグラムからのデータを搬送するパ
ケット)からデータを集めることにより、データグラムをリアセンブルし、全体
としてホストコンピュータに伝送することが可能になる。次いで、データグラム
は、宛先エンティティに高効率な態様で提供され得る。例えば、別々の「コピー
」動作により、一度に1つのパケットからのデータ(および一度に1バイト)を
提供するのではなく、「ページフリップ」動作が実行され得る。ページフリップ
では、全メモリページのデータが宛先エンティティに提供され得、場合によって
は、空の、すなわち、未使用のページと交換される。
【0029】 他の技術では、ネットワークから受け取ったパケットは、ホストコンピュータ
への伝送を待つキューに配置される。伝送を待つ間、ホストコンピュータに関連
する複数のパケットが識別され得る。それらのパケットは、伝送された後、ホス
トプロセッサによって、(例えば、一度に1つずつ)逐次的に処理されるのでは
なくグループとして処理され得る。
【0030】 さらに他の技術は、いくつかの関連するパケットをマルチプロセッサのホスト
コンピュータシステムの1つのプロセッサに発信することを伴う。異なるプロセ
ッサの中のソースエンティティと宛先エンティティとの異なる組の間で搬送され
るパケットを分散することによって、それぞれのプロトコルスタックを通じたパ
ケットの処理は、パケットを正しい順序に保ったまま、分散することができる。
【0031】 上記で議論した、パケットが処理される効率を高める技術は、ネットワークイ
ンタフェースおよび/またはホストコンピュータシステム上に位置するハードウ
ェアまたはソフトウェアの組み合わせを伴い得る。1つの特定の実施形態では、
ホストコンピュータのNIC上の構文解析モジュールが、パケットのヘッダー部
の構文解析を行う。例示的には、構文解析モジュールは、マイクロコードとして
格納された置き換え可能な命令セットに従って動作するマイクロシーケンサを含
む。パケットから抽出された情報を使用して、1つのソースエンティティから1
つの宛先エンティティへの複数のパケットが識別され得る。NIC上のハードウ
ェアのリアセンブリモジュールは、次いで、複数のパケットからデータを集め得
る。NIC上の他のハードウェアモジュールが、ホストコンピュータへの伝送を
待つ関連したパケットを認識するように構成され、これにより、それらのパケッ
トが適切なプロトコルスタックを通じて、逐次的にではなく、集約的に処理され
得る。リアセンブルされたデータおよびパケットのヘッダーは、次いで、ホスト
コンピュータに提供され得、これにより、適切なソフトウェア(例えば、NIC
のためのデバイスドライバ)がそのヘッダーを処理し得、そのデータを宛先エン
ティティに配送し得る。
【0032】 ホストコンピュータが複数のプロセッサを含む場合には、ロードディストリビ
ュータ(これもまた、NIC上のハードウェアに実現され得る)が、プロトコル
スタックを通じて複数のパケットのヘッダーを処理するプロセッサを選択し得る
【0033】 本発明の他の実施形態では、NICがホストコンピュータへの伝送を待つパケ
ットで飽和したか、またはほとんど飽和しそうになった場合に、NICからのパ
ケットをランダムに廃棄するシステムが提供される。
【0034】 (高性能ネットワークインタフェース回路の1つの実施形態) 図1Aは、本発明の例示的な実施形態に従うNIC100の構成を示す。この
実施形態におけるNIC100の種々のモジュールの動作および相互作用を以下
に簡潔に述べる。
【0035】 通信パケットは、NIC100において、メディアアクセス制御(MAC)モ
ジュール(図1Aには示されていない)によってネットワーク102から受け取
られる。MACモジュールは、ネットワークからのパケットの読み出し、何らか
の誤り検査の実行、パケットフラグメントの検出、サイズ超過のパケットの検出
、レイヤー1のプリアンブルの除去等の、パケットの低レベルな処理を実行する
【0036】 入力ポート処理(IPP)モジュール104は、次いで、そのパケットを受け
取る。IPPモジュールは、パケットキュー116に、MACモジュールまたは
ネットワークから受け取った状態のパケットの全体を格納し、パケットの一部は
、ヘッダーパーサ106にコピーされる。本発明の1つの実施形態では、IPP
モジュール104は、パケットをホストコンピュータシステムへの伝送のために
備える、ある種の調整役として機能し得る。このような役割において、IPPモ
ジュール104は、NIC100の種々のモジュールからのパケットに関する情
報を受け取り得、そのような情報を他のモジュールにディスパッチし得る。
【0037】 ヘッダーパーサ106は、パケットのヘッダー部を構文解析し、関連するパケ
ット(例えば、1つの宛先エンティティについて、1つの同じソースエンティテ
ィからの複数のパケット)を識別するために使用される種々の情報および引き続
いて行われるパケットの処理に影響を及ぼす種々の情報を取り出す。例示される
実施形態では、ヘッダーパーサ106は、フローデータベース(FDB)110
を管理するフローデータベースマネージャ(FDBM)108と通信する。特に
、ヘッダーパーサ106は、FDBM108にクエリを発信し、パケットを送信
したソースエンティティと宛先エンティティとの間に有効な通信フロー(後述)
が存在するかどうかを判定する。宛先エンティティは、パケットを受け取るべき
アプリケーションプログラム、通信モジュールまたはホストコンピュータシステ
ムの何らかの他の要素を含み得る。
【0038】 本発明の例示される実施形態では、通信フローは、1つのソースエンティティ
から1つの宛先エンティティへの1以上のデータグラムパケットを含む。フロー
は、ヘッダーパーサ106によってパケットから取り出されたソース識別子およ
び宛先識別子からアセンブルされたフローキーによって識別される。本発明の1
つの実施形態では、フローキーは、パケットのレイヤー3(例えば、IP)およ
び/またはレイヤー4(例えば、TCP)のプロトコルヘッダーからの、ソース
エンティティおよび宛先エンティティについてのアドレスおよび/またはポート
情報を含む。
【0039】 本発明の例示される実施形態の目的のために、通信フローは、TCPエンドト
ゥエンド接続と類似しているが、一般に、持続期間はより短い。特に、この実施
形態では、フローの持続時間は、ソースエンティティから宛先エンティティへと
通過する1つのデータグラムに関連付けられた全てのパケットを受け取るのに要
する時間に制限される。
【0040】 従って、フロー管理の目的のために、ヘッダーパーサ106は、パケットのフ
ローキーをフローデータベースマネージャ108に渡す。ヘッダーパーサは、パ
ケットから取り出された、パケットに関する他の情報(例えば、パケットの長さ
)をもフローデータベースマネージャに提供する。
【0041】 フローデータベースマネージャ108は、ヘッダーパーサ106から受け取っ
たクエリに応答してFDB110を検索する。例示的には、フローデータベース
110は、NIC100が扱う宛先エンティティを伴う各有効な通信フローに関
する情報を格納する。従って、FDBM108は、ヘッダーパーサ106から受
け取った情報に依存して、必要に応じてFDB110を更新する。さらに、本発
明のこの実施形態では、FDBM108は、オペレーションコードまたはアクシ
ョンコードを受け取ったパケットに関連付ける。オペレーションコードは、パケ
ットが新しいフローの一部であるのか既存のフローの一部であるのか、パケット
はデータを含むのか制御情報を含むだけなのか、パケットの中のデータの量はい
くらか、パケットデータは関連するデータ(例えば、そのソースエンティティか
らその宛先エンティティへ送られるデータグラムの中の他のデータ)とリアセン
ブルされ得るか、等を識別するために使用され得る。FDBM108は、パケッ
トから取り出され、ヘッダーパーサ106によって適切なオペレーションコード
を選択するために提供された情報を使用し得る。パケットのオペレーションコー
ドは、次いで、FDB110の中でのパケットのフローのインデックスとともに
、ヘッダーパーサに返送される。
【0042】 本発明の1つの実施形態では、ヘッダーパーサ106、FDBM108および
FDB110の組み合わせ、またはこれらのモジュールの部分集合は、NIC1
00において受け取ったネットワークトラフィックを分類または識別するという
役割に起因して、トラフィック分類器として理解され得る。
【0043】 例示される実施形態では、ヘッダーパーサ106はまた、パケットのフローキ
ーをロードディストリビュータ112に渡す。複数のプロセッサを有するホスト
コンピュータシステムでは、ロードディストリビュータ112は、どのプロセッ
サに入来パケットが適切なプロトコルスタックを通じて処理されるためにルーテ
ィングされるべきかを決定し得る。ロードディストリビュータ112は、例えば
、関連するパケットが1つのプロセッサにルーティングされることを確実にし得
る。1つの通信フローまたはエンドトゥエンド接続の中の全てのパケットを1つ
のプロセッサに送ることによって、パケットの正しい順序が強制され得る。ロー
ドディストリビュータ112は、本発明の代替的な実施形態では、省略され得る
。代替的な実施形態では、ロードディストリビュータおよびフローデータベース
マネージャに加えて、ヘッダーパーサ106もまた、NIC100の他のモジュ
ールと直接通信し得る。
【0044】 従って、ヘッダーパーサ106がパケットを構文解析した後に、FDBM10
8は、FDB110を改変または更新し、ロードディストリビュータ112は、
ホストコンピュータシステムの中の、そのパケットを処理すべきプロセッサを識
別する。これらの動作の後で、ヘッダーパーサは、種々の情報をIPPモジュー
ル104に返送する。例示的には、この情報は、パケットのフローキー、フロー
データベース110の中のパケットのフローのインデックス、ホストコンピュー
タシステムの中のプロセッサの識別子、およびパケットに関する種々の他のデー
タ(例えば、パケットの長さ、パケットヘッダーの長さ)を含み得る。
【0045】 今度は、パケットはパケットキュー116に格納され得る。パケットキュー1
16は、DMA(ダイレクトメモリアクセス)エンジン120によるオペレーシ
ョンおよびホストコンピュータへの伝送のためにパケットを保持する。パケット
をパケットキューの中に格納することに加えて、そのパケットについての対応す
るエントリが制御キュー118の中で作成され、そのパケットのフローに関する
情報はまた、動的パケットバッチモジュール122に渡され得る。制御キュー1
18は、パケットキュー116の中の各パケットについて、関連する制御情報を
格納している。
【0046】 パケットバッチモジュール122は、パケットキュー116の中のパケットに
関する、複数の関連するパケットからのヘッダーのバッチ(すなわち、集約的な
)処理を可能にする情報を利用する。本発明の1つの実施形態では、パケットバ
ッチモジュール122は、関連するパケットからのヘッダーの利用可能性をホス
トコンピュータに知らせ、これにより、関連するパケットが一緒に処理され得る
【0047】 本発明の1つの実施形態では、パケットのプロトコルヘッダーの処理はホスト
コンピュータシステム上のプロセッサによって実行されるが、他の実施形態では
、プロトコルヘッダーは、NIC100上に位置するプロセッサによって処理さ
れ得る。前者の実施形態では、ホストコンピュータ上のソフトウェア(例えば、
NIC100のためのデバイスドライバ)は、追加のメモリおよび置き換え可能
またはアップグレード可能なプロセッサ(例えば、メモリが追加され得、プロセ
ッサがより高速なモデルで置き換えられ得る)の利点を享受し得る。
【0048】 パケットキュー116にパケットを格納する間、チェックサムジェネレータ1
14は、チェックサム動作を実行し得る。チェックサムは、パケットキューに、
パケットへのトレーラとして追加され得る。例示的には、チェックサムジェネレ
ータ114は、ネットワーク102から受け取ったパケットの一部分からチェッ
クサムを生成する。本発明の1つの実施形態では、チェックサムは、パケットの
TCP部分(例えば、TCPヘッダーおよびデータ)から生成される。パケット
がTCPプロトコルに従ってフォーマットされていない場合には、チェックサム
はパケットの他の部分に基づいて生成され、結果は、必要に応じて後の処理にお
いて調整され得る。例えば、チェックサムジェネレータ114によって計算され
たチェックサムがパケットの正しい部分に基づいて計算されなかった場合、チェ
ックサムは、正しい部分を捕獲するように調整され得る。この調整は、ホストコ
ンピュータシステム上で動作するソフトウェア(例えば、デバイスドライバ)に
よってなされ得る。チェックサムジェネレータ114は、省略され得るか、また
は、本発明の代替的な実施形態のNIC100の他のモジュールに併合され得る
【0049】 ヘッダーパーサ106によって得られた情報およびフローデータベースマネー
ジャ108によって管理されるフロー情報から、本発明の1つの実施形態のNI
C100が扱うホストコンピュータシステムは、非常に効率的にネットワークト
ラフィックを処理することができる。例えば、関連するパケットのデータ部分は
、DMAエンジン120によってリアセンブルされ得、より効率的に操作され得
る集合体を形成する。そして、データをメモリページのサイズのバッファ中にリ
アセンブルすることにより、データは、「ページフリップ」を通じて、より効率
的に宛先エンティティに伝送され得る。「ページフリップ」では、DMAエンジ
ン120によって満たされたメモリページの全体が一度に供給される。従って、
1つのページフリップは、複数のコピー動作の代わりをし得る。一方、リアセン
ブルされたパケットのヘッダー部は、適切なプロトコルスタックを通じて同様に
グループとして処理され得る。
【0050】 既に述べたように、本発明の他の実施形態では、適切なプロトコルスタックを
通じたネットワークトラフィックの処理は、マルチプロセッサのホストコンピュ
ータシステムにおいて効率的に分散され得る。この実施形態では、ロードディス
トリビュータ112は、関連するパケット(例えば、同じ通信フローの中のパケ
ット)を同じプロセッサに割り当てる、すなわち、分散する。特に、レイヤー3
(例えば、IP)のプロトコルヘッダー中に同一のソースアドレスおよび宛先ア
ドレスを有するパケットおよび/またはレイヤー4(例えば、TCP)のプロト
コルヘッダー中に同一のソースポートおよび宛先ポートを有するパケットは、1
つのプロセッサに送られ得る。
【0051】 図1Aに示されるNICでは、上記で議論した処理の向上(例えば、データの
リアセンブル、パケットヘッダーのバッチ処理、プロトコルスタック処理の分散
)は、ネットワーク102が受け取った、1つ以上の予め選択されたプロトコル
スタックに従ってフォーマットされたパケットについて可能である。本発明のこ
の実施形態では、ネットワーク102は、インターネットであり、それゆえ、N
IC100は、インターネットと互換性のあるいくつかのプロトコルスタックの
1つを用いてパケットを処理するために構成される。予め選択されたプロトコル
に従って構成されないパケットもまた処理されるが、予め選択されたプロトコル
に適合するパケットに提供される処理効率の利益を完全には享受しない場合があ
る。
【0052】 例えば、予め選択されたプロトコルスタックの1つに合わないパケットは、レ
イヤー3またはレイヤー4のアドレスではなく、レイヤー2(例えば、メディア
アクセス制御)のソースアドレスおよび宛先アドレスに基づいて、マルチプロセ
ッサシステムにおける処理のために分散され得る。レイヤー2の識別子を使用す
ることによって、負荷分散手順における粒度が低下し、従って、レイヤー3/4
の識別子が使用された場合よりも、パケットの処理をより不均一に分散する場合
がある。
【0053】 図1Bは、図1AのNIC100を使用してネットワーク102から1つのパ
ケットを受け取り、そのパケットをホストコンピュータに伝送する1つの方法を
示す。状態130は、開始状態であり、NIC100の初期化またはリセットに
よって特徴付けられる場合がある。
【0054】 状態132において、パケットはNIC100によってネットワーク102か
ら受け取られる。既に述べたように、パケットは種々の通信プロトコルに従って
フォーマットされ得る。パケットは、IPPモジュールに渡される前に、MAC
モジュールによって受け取られ、最初に操作される。
【0055】 状態134において、パケットの一部分がコピーされ、ヘッダーパーサ106
に渡される。ヘッダーパーサ106は、次いで、そのパケットを構文解析し、そ
のヘッダーおよび/またはデータのうち1つ以上から値を抽出する。フローキー
が、そのパケットを含む通信フローを識別するために、取り出された情報のいく
つかから生成される。ヘッダーパーサが、異なるプロトコルのヘッダーを異なる
深さまで構文解析するように構成され得るという点において、パケットが構文解
析される度合いまたは程度は、パケットのプロトコルに依存し得る。特に、ヘッ
ダーパーサ106は、特定のプロトコルまたはプロトコルスタックの集合につい
て最適化され得る(例えば、その動作命令が構成され得る)。パケットが1以上
の特定のプロトコルに従う場合、そのパケットは、プロトコルのいずれにも従わ
ないパケットよりもより詳細に構文解析され得る。
【0056】 状態136において、パケットヘッダーから抽出された情報は、フローデータ
ベースマネージャ108および/またはロードディストリビュータ112に転送
される。FDBMは、フローデータベース110の中のフローがこの通信フロー
についてまだ存在しない場合、フローデータベース110の中のフローを設定す
るための情報を使用する。パケットのフローについてエントリが既に存在する場
合には、新しいフローパケットを受け取ったことを反映するために、そのエント
リは更新され得る。さらに、FDBM108は、パケットの1つ以上の特徴また
は条件を要約するオペレーションコードを生成する。オペレーションコードは、
以降のセクションで述べるように、パケットを適切な態様で取り扱うために、N
IC100の他のモジュールによって使用され得る。オペレーションコードは、
フローデータベースの中のパケットのフローのインデックス(例えば、フロー番
号)とともに、ヘッダーパーサに返される。
【0057】 状態138において、ロードディストリビュータ112は、ホストコンピュー
タが複数のプロセッサを含む場合、パケットにプロセッサ番号を割り当て、ヘッ
ダープロセッサにプロセッサ番号を返す。例示的には、プロセッサ番号は、どの
プロセッサが、ホストコンピュータ上でそのプロトコルスタックを通じてパケッ
トを管理するかを識別する。状態138は、本発明の代替的な実施形態では、特
にホストコンピュータがただ1つのプロセッサから構成される場合には、省略さ
れ得る。
【0058】 状態140において、パケットはパケットキュー116に格納される。パケッ
トの内容がパケットキューに配置されると、チェックサムジェネレータ114は
、チェックサムを計算し得る。チェックサムジェネレータ114は、IPPモジ
ュール104によって、パケットのどの部分に基づいてチェックサムを計算すべ
きかについて知らされ得る。計算されたチェックサムは、パケットキューにその
パケットのトレーラとして付加される。本発明の1つの実施形態では、パケット
は、パケットのヘッダー部のコピーがヘッダーパーサ106に提供されるのと実
質的に同時にパケットキューに格納される。
【0059】 状態140において、また、パケットについての制御情報が制御キュー118
に格納され、パケットのフローに関する情報(例えば、フロー番号、フローキー
)が、動的パケットバッチモジュール122に提供され得る。
【0060】 状態142において、NIC100は、パケットが、ホストコンピュータのメ
モリに伝送される準備ができているかどうかを判定する。例示される手順は、伝
送される準備ができるまで待つ。
【0061】 パケットが、伝送される準備ができる(例えば、パケットがパケットキューの
先頭にあるか、ホストコンピュータが、パケットキューの中の、このパケットの
前のパケットを受け取る)と、状態144において、動的パケットバッチモジュ
ール122は、関連するパケットがすぐに伝送されるかどうかを判定する。もし
そうであるなら、現在のパケットがホストのメモリに伝送される時に、ホストコ
ンピュータは、関連するパケットがすぐに続くことを知らされる。その場合、ホ
ストコンピュータは、パケットをグループとして(例えば、パケットのプロトコ
ルスタックを通じて)処理し得る。
【0062】 状態146において、パケットは、ホストコンピュータのメモリに(例えば、
ダイレクトメモリアクセス動作によって)伝送される。そして、状態148にお
いて、ホストコンピュータは、パケットが伝送されたことを通知される。例示さ
れる手順は、次いで、状態150で終了する。
【0063】 コンピュータシステムおよびネットワークの当業者は、上述した手順が、NI
C100のモジュールを採用して、ネットワークから1つのパケットを受け取り
、そのパケットをホストコンピュータシステムに伝送するための1つの方法に過
ぎないことを理解する。他の適切な方法もまた、本発明の範囲内で考えられる。
【0064】 (例示的なパケット) 図2は、NIC100によってネットワーク102から受け取られる例示的な
パケットの図である。パケット200は、データ部202とヘッダー部204と
を含み、また、トレーラ部206をも含み得る。パケット200がやりとりされ
るネットワーク環境に依存して、パケット200の最大サイズは、(例えば、そ
の最大伝送単位すなわちMTUに)制限され得る。
【0065】 例示される実施形態では、データ部202は、コンピュータシステムの中の宛
先、すなわち受け手エンティティ(例えば、ユーザ、アプリケーションプログラ
ム、オペレーティングシステム)またはコンピュータの通信サブシステムに提供
されるデータを含む。ヘッダー部204は、ソースすなわち発信元エンティティ
またはソースエンティティを含むコンピュータシステムによってデータ部の前に
冠された1以上のヘッダーを含む。各ヘッダーは、通常、異なる通信プロトコル
に対応している。
【0066】 インターネットのような通常のネットワーク環境では、ヘッダー部204の中
の個々のヘッダーは、送信コンピュータシステム上で、プロトコルスタック(例
えば、エンティティ間で通信するためのプロトコルの集合)の異なるレイヤーを
通じてパケットが処理される際に、付加される(例えば、プリペンドされる)。
例えば、図2は、それぞれ適切なプロトコルスタックのレイヤー1〜4に対応す
るプロトコルヘッダー210、212、214および216を示す。各プロトコ
ルヘッダーは、パケットが受け取られ、プロトコルスタックを通じて処理される
際に受け手のコンピュータシステムによって使用されるべき情報を格納している
。最終的に、各プロトコルヘッダーは除去され、データ部202が取り出される
【0067】 本発明の1つの実施形態では、パケット200を構文解析して種々の情報のビ
ットを取り出すためのシステムおよび方法が提供される。この実施形態では、パ
ケット200は、データ部202の始まりを識別するため、および、ヘッダー部
204の中のフィールドについての1以上の値を取り出すために構文解析される
。しかしながら、例示的には、レイヤー1のプロトコルヘッダーまたはプリアン
ブル210は、個々のビットのコーディングに関するハードウェアレベルの仕様
に対応する。レイヤー1のプロトコルは、一般に、導線にわたるパケットの送信
または受信の物理的な処理のためだけに必要とされる。従って、本発明のこの実
施形態では、レイヤー1のプリアンブル210は、NIC100によって受け取
られた直後にパケット200から取り除かれ、それゆえ、構文解析されない。
【0068】 ヘッダー部204が構文解析される程度は、ヘッダー部に示されるプロトコル
のうちのいくつが予め選択されたプロトコルに(もし合うものがあるなら)合う
かに依存する。例えば、パケットヘッダーの1つがサポートされないプロトコル
に対応すると一旦判定されると、構文解析処理は、省略されるかまたは中止され
得る。
【0069】 特に、本発明の1つの実施形態では、NIC100は、主にインターネットト
ラフィックのために構成される。従って、この実施形態では、パケット200は
、レイヤー2のプロトコルがイーサネット(R)(従来のイーサネット(R)ま
たは802.3イーサネット(R)、仮想ローカルエリアネットワークのための
タグありまたはなし)であり、レイヤー3のプロトコルがIP(インターネット
プロトコル)であり、レイヤー4のプロトコルがTCP(伝送制御プロトコル)
である場合にのみ、詳細に構文解析される。他のプロトコルに従うパケットは、
何らかの(例えば、より低い)程度で構文解析され得る。しかしながら、NIC
100は、実質的にいかなる通信プロトコルのヘッダーをもサポートし、構文解
析するように構成され得る。例示的には、構文解析されるプロトコルヘッダーお
よびプロトコルヘッダーが構文解析される程度は、ヘッダーパーサ106を動作
させるための命令セットの構成によって決定される。
【0070】 上述したように、ヘッダー212、214および216に対応するプロトコル
は、パケットが送られるネットワーク環境に依存する。プロトコルはまた、通信
するエンティティに依存する。例えば、ネットワークインタフェースによって受
け取られるパケットは、ソースおよび宛先コンピュータシステムについてのメデ
ィアアクセスコントローラの間で交換される制御パケットであり得る。この場合
、パケットは、最小限のデータを含むか、データを含まないことがありがちであ
り、レイヤー3のプロトコルヘッダー214またはレイヤー4のプロトコルヘッ
ダー216を含まないことがあり得る。制御パケットは、通常、個々の接続の管
理に関連する種々の目的のために使用される。
【0071】 他の制御フローまたは接続は、2つのアプリケーションプログラムを含み得る
。この場合、パケットは、図2に示されるように、ヘッダー212、214およ
び216を含み得、プロトコルスタックのより高いレイヤー(例えば、ISO−
OSIモデルにおけセッション層、プレゼンテーション層およびアプリケーショ
ン層)に関連する追加のヘッダーをも含み得る。さらに、いくつかのアプリケー
ションは、ヘッダーまたはヘッダーに類似の情報をデータ部202の中に含み得
る。例えば、ネットワークファイルシステム(NFS)用途では、データ部20
2は、個々のNFSデータグラムに関連するNFSヘッダーを含み得る。データ
グラムは、1つのエンティティから他のエンティティへ送られるデータの集合と
して定義され得、複数のパケットで送信されるデータを含み得る。換言すれば、
データグラムを構成するデータの量は、1つのパケットに含まれ得るデータの量
よりも大きくあり得る。
【0072】 (ヘッダーパーサの1つの実施形態) 図3は、本発明の実施形態に従う図1Aのヘッダーパーサ106を示す。例示
されたように、ヘッダーパーサ106は、ヘッダーメモリ302およびパーサ3
04を備え、パーサ304は、命令メモリ306を備える。図3に別個のモジュ
ールとして示されるが、本発明の代替的な実施形態において、ヘッダーメモリ3
02および命令メモリ306は、連結さていれる。
【0073】 示された実施形態において、パーサ304は、命令メモリ306に格納された
命令に従って、ヘッダーメモリ302に格納されたヘッダーを構文解析する。こ
の命令は、上述されたような特定のプロトコルまたは特定のプロトコルスタック
の構文解析用として設計される。本発明の1つの実施形態において、命令メモリ
306は、変更可能であり(例えば、メモリは、RAM、EPROM、EEPR
OMまたはその同等物としてインプリメントされる)、それにより、新しいまた
は変更された構文解析命令が、ダウンロードされ得るか、そうでなければインス
トールされ得る。パケットを構文解析するための命令は、以降のセクションでよ
り詳細に議論される。
【0074】 図3において、IPPモジュール104(図1Aに示す)に格納されたパケッ
トのヘッダー部は、ヘッダーメモリ302にコピーされる。例示されたように、
パケットの先頭の特定のバイト数(例えば、114)がコピーされる。本発明の
代替的な実施形態において、コピーされたパケットの部分は、異なるサイズを有
し得る。ヘッダーメモリ302にコピーされたパケットの特定の量は、1つ以上
のプロトコルヘッダー、または以下に説明される情報を取り出すために少なくと
も十分な情報(例えば、パケットのヘッダー部またはデータ部に含まれるかどう
か)をキャプチャするために十分でなければならない。ヘッダーメモリ302に
格納されたヘッダー部は、レイヤー1ヘッダーを含み得ず、このヘッダーは、I
PPモジュール104により処理されるパケットより前に、または同時に取り除
かれ得る。
【0075】 パケットのヘッダー部がヘッダーメモリ302に格納された後、パーサ304
は、命令メモリ306に格納された命令に従ってヘッダー部を構文解析する。こ
こで説明された実施形態のパーサ304を動作する命令は、ヘッダーメモリ30
2のコンテンツを介して進むために、かつ特定の情報を取り出すために選択され
たプロトコルのフォーマットを適用する。特に、通信プロトコルの仕様は周知で
あり、広範に利用される。従って、プロトコルヘッダーは、バイト単位で、また
はプロトコル仕様を参照することにより、その他のある方式で移動し得る。従っ
て、本発明のこの実施形態において、構文解析アルゴリズムはダイナミックであ
り、それによってヘッダーの1つのフィールドから取り出された情報は別の部分
が構文解析される方式をしばしば変更する。
【0076】 例えば、従来のイーサネット(登録商標)の形式(例えば、バージョン2)に
従うパケットのタイプフィールドは、(レイヤー2)ヘッダーの13番目のバイ
トで始まるということが知られている。比較すると、イーサネット(登録商標)
のIEEE 802.3バージョンに従うパケットのタイプフィールドは、ヘッ
ダーの21番目のバイトで始まるということが知られている。タイプフィールド
は、パケットが(イーサネット(登録商標)ヘッダーをタグ付けするまたはカプ
セル化することを例示的に含む)バーチャルローカルエリアネットワーク(VL
AN)通信の一部を形成する場合に、さらに他の位置にある。従って、本発明の
この実施形態において、あるフィールドにおける値は、ベッダーから必要とされ
る情報がヘッダーの正しい位置から引き出されることを保証するために、取り出
され、テストされる。VLANパケット形式に関する詳細は、イーサネット(登
録商標)プロトコルのIEEE 802.3p形式およびIEEE 802.3
q形式用の仕様で見い出され得る。
【0077】 ヘッダーパーサ106のオペレーションはまた、プロトコル間の他の差異(例
えば、パケットがインターネットプロトコル等のバージョン4またはバージョン
6を使用するかどうか)に依存する。IPのバージョン4および6用の仕様は、
それぞれ、IETF(インターネット通信技術作業部会)RFC(コメント要請
)791および2460に位置づけられ得る。
【0078】 パーサ304として「公知の」プロトコルが増えれば増えるほど、パケットを
テストし得るプロトコルが増え、そしてパケットのヘッダー部の構文解析がより
複雑になり得る。当業者は、パーサ304によって構文解析され得るプロトコル
がパーサの動作に従う命令によってのみ制限されることを理解する。従って、命
令メモリ306に格納された構文解析命令を増やすまたは置換することにより、
実質的に既知の全てのプロトコルがヘッダーパーサ106により処理され得、実
質的に任意の情報がパケットのヘッダーから取り出され得る。
【0079】 もちろん、パケットヘッダーが予想されプロトコルまたは予測されたプロトコ
ルに適合しない場合、構文解析オペレーションは、終了され得る。この場合にお
いて、パケットは、NIC100によって与えられる1以上の効率強化(例えば
、データアセンブリ、パケットバッチング、負荷分散に対して適切であり得ない
【0080】 例示されたように、パケットのヘッダーから取り出された情報は、そのパケッ
トを処理する際に、NIC100の他の部分により使用される。例えば、パーサ
304によって実行されたパケット構文解析の結果として、フローキーが、パケ
ットを含む通信フローまたは通信接続を識別するために生成される。例示された
ように、このフローキーは、1つ以上の通信エンティティに対応する1つ以上の
アドレスを連結することによりアセンブルされる。この実施形態において、フロ
ーキーはIPヘッダーから引き出されたおよび宛先アドレスならびにTCPヘッ
ダーから取り出されたソースおよび宛先部分の組み合せから形成される。通信エ
ンティティの他の印(indicia)は、例えば、(レイヤー2ヘッダーから
引き出される)イーサネット(登録商標)ソースおよび宛先アドレス、NFSフ
ァイルハンドルあるいはパケットのデータ部から引き出される他のアプケーショ
ンデータグラム用のソース識別子および宛先識別子が使用され得る。
【0081】 当業者は、通信エンティティがパケットに関連したプロトコルスタックより高
いレイヤーから引き出される印を用いることにより、より大きな分解能で識別さ
れ得る。従って、IPおよびTCPの印の組合せは、レイヤー2の情報より大き
な特徴を有するエンティティを識別し得る。
【0082】 フローキーに加えて、パーサ304はまた、パケットに関する付加的な情報を
要約するために、制御インジケータまたはステータスインジケータを生成する。
本発明の1つの実施形態において、制御インジケータは、シーケンス番号(例え
ば、TCPヘッダーから引き出されるTCPのシーケンス番号)を含むため、そ
れらのデータをリアセンブリする際のパケットの正確な順番を保証する。制御イ
ンジケータはまた、パケットのヘッダーの所定のフラグが設定またはクリアされ
ているかどうか、パケットが任意のデータを含んでいるかどうか、そしてパケッ
トがデータを含んでいる場合、そのデータが所定のサイズを越えるかどうかも明
らかにし得る。他のデータはまた、制御インジケータに挿入するために適切であ
り得、パーサ304によって構文解析されたパケット部で利用可能な情報によっ
てのみ制限される。
【0083】 本発明の1つの実施形態において、ヘッダーパーサ106は、フローキーと、
フローデータベースマネージャ108に対する制御インジケータの全てまたは一
部を提供する。以下のセクションで議論されるように、FDBM108はNIC
100を介して送る通信フローに関連する情報を含むデータベースまたは他のデ
ータ構造を管理する。
【0084】 本発明の他の実施形態において、パーサ304は、NIC100の他のモジュ
ールによって使用するためのパケットのヘッダーから得られた付加的な情報を生
成する。例えば、ヘッダーパーサ106は、パケットの先頭からまたは他のある
ポイントからの、ネットワークから受け取ったパケットのデータまたはペイロー
ド部のオフセットを報告し得る。上記で説明されたように、パケットのデータ部
は、典型的に、ヘッダー部に続き、トレーラ部の後に続き得る。ヘッダパーサ1
06が報告し得る他のデータは、チェックサムオペレーションが始まるべきパケ
ットの位置、レイヤー3ヘッダーおよび/またはレイヤー4ヘッダーが始まるパ
ケットの位置、診断データ、ペイロード情報等を含む。用語「ペイロード」は、
パケットのデータ部を参照するためによく使用される。特に、本発明の1つの実
施形態において、ヘッダーパーサ106は、ペイロードオフセットおよびペロー
ドサイズを提供して、キュー118を制御する。
【0085】 適切な環境において、ヘッダーパーサ106はまた、パーサ304が操作する
ように構成されるプロトコルに従ってパケットがフォーマットされないことを(
例えば、IPPモジュール104および/または制御キュー118に)報告し得
る。この報告は、信号(例えば、以下に説明されるNo_Assist信号)、
警告、フラグまたは他のインジケータの形式でとられてもよい。上記で説明され
た処理強化(例えば、データリアセンブリ、パケットヘッダーのバッチ処理、負
荷分散)と互換性のある予め選択されたプロトコルを以外のプロトコルを反映し
てパケットが発見されるときにいつでも、この信号は生じ得るか、発行され得る
。例えば、本発明の1つの実施形態において、パーサ304は、レイヤー4のT
CP、レイヤー3のIP、レイヤー2のイーサネット(登録商標)を用いてパケ
ットを構文解析するためにかつ効果的に処理するために構成され得る。この実施
形態において、IPX(インターネットワークパケット交換)パケットは、互換
性のあるものと考慮されず、従って、IPXパケットは、データリアセンブリお
よびバッチ処理用に集められない。
【0086】 本発明の1つの実施形態の構文解析の結果において、上記で説明された情報の
種々の構成要素(piece)は、NIC100の適切なモジュールに広められ
る。この後(かつ以下のセクションで説明されるように)、フローデータベース
マネージャ108は、アクティブフローがパケットから得られる、フローキーに
関連するかどうかを判定し、後に続く処理で使用されるオペレーションコードを
設定する。加えて、IPPモジュール104は、パケットキュー116にパケッ
トを伝送する。IPPモジュール104はまた、ヘッダーパーサ106により抽
出されたいくつかの情報を受け取り得、NIC100の別のモジュールにその情
報を送り得る。
【0087】 図3に示された本発明の1つの実施形態において、構文解析されるべき受け取
られたパケットのヘッダー部の全体は、コピーされ、続いて、1つの展開で構文
解析される。その後、ヘッダーパーサが、その注意を別のパケットに向ける。し
かしながら、代替的な実施形態において、複数のコピーおよび/または構文解析
オペレーションは、単一のパケットに関して実行され得る。特に、パケットの初
期ヘッダー部は、初めの展開でヘッダーパーサ106にコピーされ得、ヘッダー
パーサ106により構文解析され得る。その後、別のヘッダー部が、ヘッダーパ
ーサ106にコピーされ得、第2展開で構文解析され得る。1つの展開における
ヘッダー部は、別の展開のヘッダー部と部分的にまたは完全にオーバーラップし
得る。このように、広範囲にわたるヘッダーは、たとえヘッダーメモリ302が
制限されたサイズの大きさであっても、構文解析され得る。同様に、命令メモリ
306にパケットを構文解析するための完全な命令セットをロードするための1
つより多いオペレーションを必要とし得る。例示されたように、命令の第1の部
分は、ロードされ得、実行され得る。その後、他の命令が、ロードされる。
【0088】 ここで、図4A〜4Bを参照して、ヘッダーパーサがネットワークインターフ
ェース回路においてネットワークから受け取られるパケットのヘッダー部を構文
解析し得る1つの方法を例示するフローチャートが示される。このインプリメン
テーションにおいて、ヘッダーパーサは、一組の予め選択されたプロトコル(ま
たはプロトコルスタック)に適合するパケットを構文解析するように構成される
か、または最適化される。これらの判定基準を満足するパケットに対して、様々
な情報が関連するパケット(例えば、単一データグラムからのデータを含むパケ
ット)のデータ部のリアセンブリに役立つように、ヘッダー部から取り出される
。ネットワークインターフェース回路の他の強化した機能はまた、イネーブルさ
れ得る。
【0089】 ヘッダーパーサにより生成された情報は、特に、受け取ったパケットを含む通
信フローまたは通信接続を識別するためのフローキーを含む。本発明の1つの実
施形態において、同じフローキーを有するパケットからのデータは、データグラ
ムを形成するために識別され得、リアセンブリされ得る。加えて、同じフローキ
ーを有するパケットのヘッダーは、そのプロトコルスタックを(例えば、連続的
にというよりも)集合的に処理され得る。
【0090】 本発明の別の実施形態において、ヘッダーパーサにより取り出された情報はま
た、ネットワークから受け取られたネットワークトラフィックの処理を分散する
ために使用される。例えば、同じフローキーを有する複数のパケットは、マルチ
プロセッサホストコンピュータシステムの単一プロセッサに発信され得る。
【0091】 図4A〜4Bに示される方法において、一組の予め決められたプロトコルは、
インターネットを介してたびだび伝送される通信プロトコルと対応する。特に、
この方法において大規模に構文解析され得る一組のプロトコルは、以下を含む。
レイヤー2において:イーサネット(登録商標)(従来のバージョン)、802
.3 イーサネット(登録商標)、イーサネット(登録商標) VLAN(バー
チャルローカルエリアネットワーク)および802.3 イーサネット(登録商
標)VLAN。レイヤー3において:IPv4(オプションなし)およびIPv
6(オプションなし)。最後に、レイヤー4において、TCPプロトコルヘッダ
ー(オプションありまたはオプションなし)のみが、例示した方法で構文解析さ
れる。本発明の代替的な実施形態におけるヘッダーパーサは、他のプロトコルス
タックを介してフォーマットされたパケットを構文解析する。特に、NICは、
所与のネットワークで使用する最も一般的なプロトコルスタックに従って構成さ
れ得る。このNICは、図4A〜4Bに示されるヘッダーパーサ方法と互換性の
あるプロトコルを含んでもよいし、含まなくてもよい。
【0092】 以下に例示されるように、所与の方法により構文解析されたプロトコルと対応
しない受け取られたパケットはフラグされ得、構文解析アルゴリズムは、そのパ
ケットを終端処理し得る。パケットがフォーマットされた条件下でのプロトコル
が唯一判定され得るため、本発明の方法において、あるヘッダーフィールド値を
検査することにより、パケットが選択されたプロトコルのセットに適合しないと
いう判定が、そのプロシージャの間実質的に任意の時点でなされ得る。従って、
示された構文解析方法は、データのリアセンブリ用のフォーマット基準に合致し
ないパケットの識別子を1つの目標としている。
【0093】 選択されたプロトコルのヘッダーに現れる種々のプロトコルヘッダーフィール
ドが、以下で議論される。本発明の実施形態(例えば、ヘッダーパーサにより構
文解析され得るプロトコル)と互換性があり得る通信プロトコルは、当業者に周
知であり、多くの文献で非常に詳細に説明される。従って、この通信プロトコル
については、本明細書中で詳細に説明する必要はない。加えて、選択されたプロ
トコルに対するパケットのヘッダー部を構文解析する例示された方法は、以下で
説明される情報を集める1つの方法に過ぎない。情報を集めることの可能な他の
構文解析プロシージャは、同様に適切である。
【0094】 本発明のこの実施形態において、例示されたプロシージャは、ハードウェアお
よびソフトウェアの組合せとしてインプリメントされる。例えば、プロシージャ
を実行する更新可能なマイクロコード命令は、マイクロシーケンサーにより実行
され得る。あるいは、このような命令は、固定(例えば、読み出し専用メモリで
格納されてもよい)されてもよいし、あるいは、プロセッサまたはマイクロプロ
セッサにより実行されてもよい。
【0095】 図4A〜4Bにおいて、状態400は、パケットがNIC100(図1Aに図
示)により受け取られ、かつ初期処理が実行される間の開始状態である。NIC
100は、このプロシージャの目的のため、インターネットに接続される。初期
処理は、基本的なエラーチェックとレイヤー1プリアンブル除去とを含み得る。
初期処理の後、パケットは、IPPモジュール104(図1Aにも図示)より保
持される。本発明の1つの実施形態において、状態400は、パケットが受け取
られるまでヘッダーパーサがアイドル状態または待ち状態を保つ論理ループを含
む。
【0096】 状態402において、パケットのヘッダー部は、メモリ(例えば、図3のヘッ
ダーメモリ302)内にコピーされる。本発明のこの実施形態において、パケッ
トの先頭の所定数のバイト(例えば、114バイト)がコピーされる。異なるサ
イズのパケット部は、本発明の代替的な実施形態においてコピーされ、パケット
部のサイズは、必要なヘッダー情報をキャプチャするかつ/または識別するため
の十分なパケットをコピーする目標により導出される。例示されたように、完全
なパケットは、以下の構文解析オペレーションが実行される間、IPPモジュー
ル104により保持されるが、代替的にパケットは、構文解析が完了する前にパ
ケットキュー116に格納され得る。
【0097】 状態402においても、パケットを構文解析する際に使用されるポインタが初
期化され得る。レイヤー1プリアンブルが取り除かれたので、メモリにコピーさ
れるヘッダー部は、レイヤー2プロトコルヘッダーで開始しなければならない。
従って、例示されたように、このポインタは、最初に、レイヤー2プロトコルヘ
ッダーの12番目のバイトを指定するように設定され、ポンイタ部の2バイト値
が読み出される。当業者に認識されているように、これらの2バイトは、多くの
異なるフィールドの一部であり得、どのプロトコルがパケットのプロトコルスタ
ックのレイヤー2を構成するかに依存する。例えば、これらの2バイトは、従来
のイーサネット(登録商標)ヘッダーのタイプフィールド、802.3 イーサ
ネット(登録商標)ヘッダーの長さフィールド、またはVLANのタグ付けされ
たヘッダーのTPID(タグプロトコル識別子)フィールドを含み得る。
【0098】 状態404において、第1の検査は、VLANのタグ付けされたレイヤー2プ
ロトコルヘッダーを含むかどうかを判定するためにレイヤー2ヘッダーについて
行われる。例示されたように、この判定は、ポインタ位置で2バイトが16進数
値8100を格納するかどうかに依存する。そのような場合、このポインタは、
VLANのタグ付けされたヘッダーのTPIDフィールドでおそらく位置付けさ
れる。VLANヘッダーでない場合、そのプロシージャは状態408に進む。
【0099】 しかしながら、レイヤー2ヘッダーがVLANのタグ付けされたヘッダーであ
る場合、状態406においてCFI(標準形インジケータ)ビットが検査される
。CFIビットが設定される(例えば、1に等しい)場合、示されたプロシージ
ャは、状態430にジャンプし、その後、プロシージャは終了する。本発明のこ
の実施形態において、設定する際のCFIビットは、パケットのフォーマットが
予め選択されたプロトコル(例えば、レイヤー2プロトコルはイーサネット(登
録商標)または802.3イーサネット(登録商標)でない)と互換性がない(
すなわち、完全に適合しない)。CFIビットがクリアにされる(例えば、0に
等しい)場合、ポインタは、検査されるべき次のフィールドでポインタを位置付
けるように(例えば、4バイトだけ)インクリメントされる。
【0100】 状態408において、レイヤー2ヘッダーがさらにテストされる。状態408
がそれぞれ、状態406を介して到達したか、または状態404から直接到達し
たかに依存してレイヤー2ヘッダーがVLANのタグ付けされたヘッダーか、ま
たはそうでないかは分からないが、ヘッダーは、従来のイーサネット(登録商標
)フォーマットまたは802.3イーサネット(登録商標)フォーマットのどち
らかを反映し得る。状態408のはじまりにおいてポインタは、ヘッダーの12
番目バイトまたはヘッダーの16番目バイトのいずれかにあり、このヘッダーの
どちらかが長さフィールドまたはタイプフィールドに対応し得る。特に、ポイン
タにより識別された位置での2バイト値が0600(16進数)未満である場合
、パケットが802.3イーサネット(登録商標)に対応し、ポインタが長さフ
ィールドを識別すると理解される。そうでなければ、このパケットは、従来の(
例えば、バージョン2)イーサネット(登録商標)パケットポインタは、タイプ
フィールドを識別する。
【0101】 レイヤー2プロトコルが802.3イーサネット(登録商標)である場合、プ
ロシージャは状態410に続く。レイヤー2プロトコルが従来のイーサネット(
登録商標)である場合、タイプフィールドは、0800および08DDの16進
数値に対してテストされる。テストされたフィールドがこれらの値のうちの1つ
である場合、パケットのレイヤー3プロトコルがインターネットプロトコルであ
るということも決定されてきた。この場合において、示されたプロシージャが、
状態412に続く。最後に、このフィールドが0800および86DD(16進
数)以外の値を有するタイプフィールドである場合、パケットのレイヤー3プロ
トコルは、どのヘッダーパーサが構成されたかに従って予め選択されたプロトコ
ルと一致しない。従って、このプロシージャは状態430に続き、その後、終了
する。
【0102】 本発明の1つの実施形態において、パケットは、パケットがジャンボイーサネ
ット(登録商標)フレームであるかどうかを判定するために、状態408で検査
される。レイヤー2ヘッダーがイーサネット(登録商標)または802.3イー
サネット(登録商標)に適合するかどうかを決定する前に、この判定がおそらく
なされる。例示されたように、ジャンボフレームの判定は、パケットのサイズに
基づいてなされ得、このパケットはIPPモジュール104またはMACモジュ
ールにより報告され得る。このパケットがジャンボフレームである場合、プロシ
ージャは状態410に続き得る。このパケットがジャンボフレームでない場合、
プロシージャは状態412で再開され得る。
【0103】 状態410において、プロシージャは、レイヤー2プロトコルがLLC SN
APカプセル化を有する802.3イーサネット(登録商標)であることを検証
する。特に、ポインタは(例えば、2バイト毎に)進み、レイヤー2ヘッダーの
長さフィールドに続く6バイト値が取り出され、検査される。ヘッダーが802
.3イーサネット(登録商標)ヘッダーである場合、フィールドはLLC_SN
APフィールドあり、AAAA03000000(16進数)の値を有さなけれ
ばならない。LLC SNAPヘッダーに関する最初の仕様が、IEEE 80
2.2の仕様で見出され得る。パケットのLLC_SNAPフィールドの値が予
想した値と一致する場合、ポインタは、さらに6バイトだけインクリメントされ
、2バイトの802.3イーサネット(登録商標)タイプフィールドが読み出さ
れ、プロシージャは状態412で継続する。この値が一致しない場合、パケット
は特定のプロトコルと適合せず、プロシージャが状態430に入り、その後、終
了する。
【0104】 状態412において、ポインタは(例えば、さらに2バイト)進められ、それ
により、レイヤー3プロトコルヘッダーの先頭を位置付ける。このポインタの位
置は、このヘッダーの先頭を素早く識別する際に、後で使用するために保存され
得る。次いでパケットは、承認されたレイヤー2プロトコル(例えば従来のイー
サネット(登録商標)、VLANタグ付けを有するイーサネット(登録商標)、
またはLLC SNAPを有する802.3イーサネット(登録商標))に適合
すると分かっており、次にパケットのレイヤー3プロトコルがIPであると保証
するするようにチェックされる。上記で議論されたように、例示された実施形態
において、IPプロトコルに適合するパケットのみが、ヘッダーパーサにより広
範囲に処理される。
【0105】 例示するように、(状態402または状態410で取り出された)レイヤー2
ヘッダーのタイプフィールドの値が0800(16進数)である場合、レイヤー
3プロトコルは、バージョン4のIPだと予想される。この値が86DD(16
進数)である場合、レイヤー3プロトコルは、バージョン6のIPだと予想され
る。従って、タイプフィールドが状態412でテストされ、プロシージャは、こ
の16進数値がそれぞれ0800または86DDであるかどうかに依存して、状
態414または状態418で継続する。
【0106】 状態414において、バージョン4のIPとのレイヤー3ヘッダーの適合が検
証される。本発明の1つの実施形態において、レイヤー3ヘッダーのバージョン
フィールドは、バージョンフィールドが16進数値の4(バージョン4のIPと
対応する)を含むことを保証するためにテストされる。状態414において、レ
イヤー3ヘッダーがIPバージョン4だと確認された場合、プロシージャは状態
416で継続する。レイヤー3ヘッダーがIPバージョン4だと確認されない場
合、プロシージャは状態430に進み、その後、状態432で終了する。
【0107】 状態416において、IPヘッダーからの情報の種々の構成要素が保存される
。この情報は、IHL(IPヘッダー長)フィールド、合計長さフィールド、プ
ロトコルフィールドおよび/またはフラグメントオフセットフィールドを含む。
IPソースアドレスおよびIP宛先アドレスも格納され得る。このソースアドレ
ス値および宛先アドレス値は、バージョン4のIP内でそれぞれ4バイト長であ
る。上記で説明されたように、これらのアドレスは、このパケットが送信された
通信フローを識別するフローキーを生成するために使用される。合計長さフィー
ルドは、このパケットのIPセグメントのサイズを格納し、このパケットは、I
Pヘッダー、TCPヘッダーおよびパケットのデータ部を例示的に含む。このパ
ケットのTCPセグメントサイズ(例えば、TCPヘッダーサイズにパケットの
データ部のサイズを加えたサイズ)は、合計長さ値から20バイト(IPバージ
ョン4のヘッダーのサイズ)を差し引くことにより計算され得る。状態416の
後には、例示したプロシージャは状態422に進む。
【0108】 状態418において、バージョン6のIPとレイヤー3ヘッダーの適合が、1
6進数値の6のバージョンフィールドをテストすることにより検証される。バー
ジョンフィールドがこの値を含まない場合、例示したプロシージャは状態430
に進む。
【0109】 状態420において、IPソースアドレスおよび宛先アドレスに加えて、ペイ
ロード長(例えば、TCPセグメントのサイズ)および次のヘッダーフィールド
の値が保存される。ソースアドレスおよび宛先アドレスは、バージョン6のIP
内でそれぞれ16バイト長である。
【0110】 例示したプロシージャの状態422において、レイヤー4ヘッダーがTCPで
あることをIPヘッダー(バージョン4またはバージョン6)が示すかどうかが
判定される。例示したように、バージョン4のIPヘッダーのプロトコルフィー
ルドがテストされ、一方、バージョン6のヘッダーの次のフィールドがテストさ
れる。いずれの場合でも、この値は、6(16進数)でなければならない。続い
て、ポインタは、必要に応じて(例えば、IPバージョン4については20バイ
ト、IPバージョン6については40バイト)インクリメントされ、それにより
、TCPヘッダーの先頭に到達する。状態422において、レイヤー4ヘッダー
がTCPでないことが判定される場合、プロシージャは状態430に進み、終了
状態432で終了する。
【0111】 本発明の1つの実施形態において、バージョン4のIPヘッダーの他のフィー
ルドは、パケットがNIC100により強化処理の基準を満たすことを保証する
ために、状態422でテストされ得る。例えば、5(16進数)以外のIHLフ
ィールド値は、IPオプションがこのパケットについてセットされることを示し
、この場合において、構文解析オペレーションがアボートされる。0以外の細分
化フィールド値は、パケットのIPセグメントがフラグメントであることを示し
、この場合において、構文解析もアボートされる。いずれの場合も、プロシージ
ャは状態430にジャンプし、その後、終了状態432で終了する。
【0112】 状態424において、パケットのTCPヘッダーは構文解析され、様々なデー
タがヘッダーから収集される。特に、TCPソースポート値および宛先ポート値
が保存される。複数のパケットからのデータを正しくリアセンブリすることを確
実にするのため用いられるTCPシーケンス番号も保存される。さらに、Fla
gsフィールドのいくつかの構成要素の値(例示されたように、URG(緊急)
ビット、PSH(プッシュ)ビット、RST(リセット)ビット、SYN(同期
)ビットおよびFIN(終了)ビット)が保存される。本発明の1つの実施形態
において、これらのフラグは、実行されるべき種々のアクション、またはパケッ
トを処理する際に考慮されるべき状態を信号として送る。
【0113】 他の信号または状態は、状態424で生成され得、それにより、TCPヘッダ
ーから取り出された情報を反映する。例えば、チェックサムオペレーションが開
始するポイント(例示したように、TCPヘッダーの始まり)が保存され得、チ
ェックサムオペレーション終了ポイント(例示したように、パケットのデータ部
の終端)も保存され得る。パケットのデータ部のオフセットは、TCPヘッダー
のヘッダー長フィールドの値を4倍することによって識別され得る。続いて、デ
ータ部のサイズは、TCPセグメント全体のサイズからデータ部に対するオフセ
ットを差し引くことにより計算され得る。
【0114】 状態426において、フローキーは、IPソースアドレスおよび宛先アドレス
、ならびにTCPソースポートおよび宛先ポートを連結することによりアセンブ
ルされる。既に説明されたように、フローキーは、通信フローまたは通信接続を
識別するために使用されてもよいし、かつNIC100の他のモジュールによっ
てより効果的にネットワークトラフィックを処理するために使用されてもよい。
ソースアドレスおよび宛先アドレスのサイズは、IPバージョン4とIPバージ
ョン6の場合では異なる(例えば、IPバージョン4では各4バイト、IPバー
ジョン6では16バイト)が、ここで記載された本発明の実施形態では、全ての
フローキーが同一サイズである。特に、この実施形態において、これらは、2バ
イトTCPソースポートおよび2バイトTCP宛先ポートを含む36バイト長で
ある。IP(パージョン4)パケットヘッダーから生成されたフローキーは、必
要に応じて(例えば、24クリアバイト(clear bytes)で)パッデ
ィングされ、これにより、フローキーの割り当てられたスペースを満たす。
【0115】 状態428において、制御インジケータまたはステータスインジケータは、N
IC100の1つ以上のモジュールに種々の情報を提供するためにアセンブルさ
れる。本発明の1つの実施形態において、制御インジケータは、パケットのTC
Pシーケンス番号、パケットがデータを含むかどうか(例えば、TCPペイロー
ドサイズが0より大きいかどうか)を示すフラグまたは識別子(例えば、1つ以
上のビット)、パケットのデータ部が所定のサイズを超えるかどうかを示すフラ
グ、およびTCPフラグフィールドのあるエントリが所定の値と等しいかどうか
を示すフラグを含む。例えば、後者のフラグは、Flagsフィールドの構成要
素が特定の構造を有するまたは有さないことをNIC100の別のモジュールに
知らせるために使用され得る。状態428の後、例示されたプロシージャは、状
態432で終了する。
【0116】 状態430には、例示されたプロシージャのいくつか異なるポイントで入るこ
とができる。例えば、ヘッダーパーサにより構文解析されるヘッダー部が上記で
識別された予め選択されたプロトコルスタックに適合しないことが判定された場
合、この状態に入る。結果として、上記で説明された多くの情報が取り出されな
い。この情報を取り出すことが不可能という実際の結果は、NIC100の他の
モジュールに提供することができず、本明細書に記載された強化処理をこのパケ
ットに対して実行することができないということである。特に、すでに説明され
たように、本発明のこの実施形態において、1つ以上の強化オペレーションは、
パケットが処理される効率を増すように、構文解析されたパケットに関して実行
され得る。適用され得る例示のオペレーションは、関連するパケット(例えば、
単一データグラムからのデータを含むパケット)からのデータのリアセンブリ、
プロトコルスタックによるパケットヘッダーのバッチ処理、プロトコルスタック
処理の負荷分散または負荷共有、宛先エンティティへのパケットデータの効率的
な伝送等を含む。
【0117】 例示されたプロシージャにおいて、状態430ではフラグまたは(例示的に、
No_Assistと称される)信号は、(例えば、ヘッダーパーサよってちょ
うど処理された)IPPモジュール104により現在保持されるパケットが、予
め決められたプロトコルスタックのいずれにも適合しないことを示すように、設
定されるか、またはクリアされる。このフラグまたは信号は、強化オペレーショ
ンの1つを実行するかどうかを決定する際に、NIC100の別のモジュールに
よって依存し得る。
【0118】 別のフラグまたは信号は、チェックサムオペレーションが実行された場合、そ
のオペレーションが(例えば、パケット内にオフセットを有さない)パケットの
先頭で開始すべきということを示すチェックサムパラメータを初期化するために
、状態430において、設定され得るか、またはクリアされ得る。例示したよう
に、互換性のないパケットは、チェックサムオペレーションを開始するより適切
なポイントを決定するために構文解析され得ない。状態430の後、プロシージ
ャは終了状態432で終了する。
【0119】 パケットを構文解析した後、ヘッダーパーサは、パケットからNIC100の
1つ以上のモジュールに生成された情報を分散し得る。例えば、本発明の1つの
実施形態において、フローキーは、フローデータベースマネージャ108、ロー
ドディストリビュータ112、ならびに制御キュー118およびパケットキュー
116のどちらか一方またはその両方に提供される。例示されたように、制御イ
ンジケータは、フローデータベースマネージャ108に提供される。この制御情
報および他の制御情報(例えば、TCPペイロードサイズ、TCPペイロードオ
フセットおよびNo_Assist信号)は、IPPモジュール104に戻され
得、かつ制御キュー118に提供され得る。なおさらなる制御情報および/また
は診断情報(レイヤー3ヘッダーおよび/またはレイヤー4ヘッダーに対するオ
フセット)は、IPPモジュール104、パケットキュー116および/または
制御キュー118に提供され得る。チェックサム情報(例えば、開始ポイント、
および終了ポイントまたはチェックサムを計算するパケット部を識別する他の手
段のどちらか一方)は、チェックサムジェネレータ114に提供され得る。
【0120】 受け取られたパケットが、NIC100で(例えば、ヘッダーパーサ106に
より)構文解析された後に、そのパケットは、本発明の例示された実施形態にお
いて、ホストコンピュータシステムで(例えば、それぞれのプロトコルスタック
を介して)なおも処理される。しかしながら、本発明の代替的な実施形態におい
て、パケットを構文解析した後、NIC100はまた、1つ以上の後に続く処理
工程を実行する。例えば、NIC100は、1つ以上のパケットのプロトコルヘ
ッダーを処理する1つ以上のプロトコルプロセッサを含み得る。
【0121】 (発明の1つの実施形態におけるダイナミックヘッダー構文解析命令) 本発明の1つの実施形態において、ヘッダーパーサ106は、命令のダイナミ
ックシーケンスに従って、ネットワークから受け取ったパケットを構文解析する
。この命令は、ヘッダーパーサの命令メモリ(例えば、RAM、SRAM、DR
AM、フラッシュ)に格納され得、この命令メモリは、再プログラム可能である
か、またはそうでなければ、新規の命令または追加の命令で更新され得る。本発
明の1つの実施形態において、ホストコンピュータ(例えば、デバイスドライバ
)上で動作するソフトウェアは、ヘッダーパーサメモリに格納する一組の構文解
析命令をダウンロードし得る。 ヘッダーパーサの命令メモリに格納された命令の数およびフォーマットは、1
つ以上の特定のプロトコルまたはプロトコルスタックに変更され得る。従って、
プロトコルを1つに収集するように構成された命令セット、またはその命令セッ
トから構成されたプログラムは、異なる命令セットまたはプログラムによって更
新され得るか、または置換され得る。選択されたプロトコルに従ってフォーマッ
トされるネットワークインターフェースで受け取られたパケット(例えば、「互
換性のある」パケット)について、パケットを解析するまたは構文解析すること
により判定される際、本明細書に記載されるように、ネットワークトラフィック
の処理における種々の強化が可能となる。特に、選択されたプロトコルに従って
構成される1つのデータグラムからのパケットは、ホストコンピュータにおいて
効果的に伝送するようにリアセンブリされ得る。加えて、このようなパケットの
ヘッダー部は、連続的というよりもむしろ集合的に処理され得る。そして、マル
チプロセッサホストコンピュータによる異なるデータグラムからのパケットの処
理は、プロセッサ間で共有され得るか、または分散され得る。従って、ダイナミ
ックヘッダー構文解析オペレーションの1つの目的は、受け取ったパケットのフ
ォーマットに従って、パケットを識別すること、またはパケットヘッダーが特定
のプロトコルに適合するかどうかを判定することである。
【0122】 手短に詳細に議論された図12は、ヘッダーがそれぞれ、イーサネット(登録
商標)、IP、TCPであるかどうかを判定するパケットのレイヤー2、3、お
よび4のヘッダーを構文解析する例示的な一連の命令を示す。例示された命令は
、構文解析オペレーションを実行する1つの可能なプログラムまたはマイクロコ
ードを含む。当業者に認識されるように、構文解析命令の特定の組がパーサメモ
リにロードされた後、多くの異なるプログラムがアセンブルされ得る。従って、
図12は、格納された命令から生成され得る多数のプログラムのうちのただ1つ
のみを示す。図12に示される命令は、マイクロシーケンサ、プロセッサ、マイ
クロプロセッサまたはネットワークインターフェース回路内に配置されるその他
の同様なモジュールにより実行され得るか、または動作され得る。
【0123】 特に、他の命令セットおよび他のプログラムは、異なる通信プロトコルに対し
て得られ得、かつプロトコルスタックの他のレイヤーに強化され得る。例えば、
一組の命令は、NFS(ネットワークファイルシステム)パケットを構文解析す
るために生成され得る。例示されたように、これらの命令は、ヘッダーがそれぞ
れ、リモートプロシージャコール(RPC)および外部データ表示(XDR)で
あるかどうかを判定するレイヤー5ヘッダーおよびレイヤー6プロトコルヘッダ
ーを構文解析するように構成され得る。他の命令は、(レイヤー7と考えられ得
る)パケットのデータ部を構文解析するように構成され得る。NFSヘッダーは
、パケットのレイヤー6プロトコルヘッダーの一部またはパケットのデータの一
部と考えられ得る。
【0124】 マイクロシーケンサによって実行される命令の1つのタイプは、(例えば、パ
ケット内の特定のオフセットで)パケットの特定のフィールドを位置付けるよう
に設計され得、かつそのオフセットで格納された値と特定の通信プロトコルのそ
のフィールドに関連する値とを比較し得る。例えば、1つの命令は、イーサネッ
ト(登録商標)ヘッダーのタイプフィールドに対応するオフセットでのパケット
ヘッダーの値を検査するためのマイクロプロセッサを必要とし得る。パケットに
実際に格納された値とプロトコルについて予測された値を比較することにより、
マイクロシーケンサは、パケットがイーサネット(登録商標)プロトコルに適合
するかどうかを判定し得る。例示されたように、構文解析プログラムにおいて適
用された次の命令は、以前の比較が成功したかどうかに依存する。従って、マイ
クロシーケンサによって適用された特定の命令および適用されたシーケンスは、
どのプロトコルがパケットヘッダーによって示されるかに依存する。
【0125】 マイクロシーケンサは、パケットに含まれる各ヘッダー内の1つ以上のフィー
ルド値をテストし得る。テストされかつ既知のプロトコルのフォーマットと適合
すると分かったフィールドが増せば増すほど、パケットがそのプロトコルと適合
するという確実性は大きくなる。当業者に理解されるように、1つの通信プロト
コルは別のプロトコルと全く異なり得るので、そのため、異なるプロトコルにつ
いてのパケットヘッダーの異なる部分の検査が必要となる。例示されたように、
1つのパケットを構文解析することにより、エラーが発生する場合、または構文
解析されるパケットが命令が指定されるプロトコル(単数または複数)と適合す
るか否かを判定するため終了し得る。
【0126】 図12の各命令は、番号および/または名前によって識別され得る。特定の命
令は、ヘッダーフィールドを期待値と比較する以外に、種々のタスクを実行する
ことができる。例えば、命令は、他の命令を呼び出して、パケットヘッダーの他
の部分の調査、レジスタまたは他のデータ構造を初期化、ロード、またはアセン
ブル、他のパケットの到着および構文解析の準備等をすることができる。特に、
レジスタまたは他の格納構造は、パケットが構文解析された後で、ネットワーク
インターフェースにおいて実行されるオペレーションを予想して構成され得る。
例えば、図12のプログラム命令は、パケットから抽出された値と期待値との比
較の成功または失敗に応じて、行われてもよいし、または行われなくてもよい出
力オペレーションを識別することができる。出力オペレーションは、レジスタに
値を格納し、構文解析後のオペレーション用にレジスタを構成し(例えば引数ま
たはオペレータをロードする)、新たなパケットを待つようにレジスタをクリア
にする等し得る。
【0127】 ポインタは、オフセットを識別してパケットを構文解析させるために利用され
得る。1実施形態においてこのようなポインタは、最初に、レイヤー2のプロト
コルヘッダーの先頭に位置される。しかしながら別の実施形態では、構文解析が
開始する場合、ポインタは特定のヘッダー内の特定の位置(例えば、直後のレイ
ヤー2の宛先および/またはソースアドレス)に位置付けられる。例示的、ポイ
ンタは、構文解析プロシージャが実行されるにしたがって、パケットによってイ
ンクリメントされる。しかしながら、別の1実施形態において、パケットの対象
となる領域へのオフセットは、1以上の既知または計算された位置から計算され
得る。
【0128】 図12に示される構文解析プログラムでは、ヘッダーは、2バイト(例えば1
6ビットワード)ずつインクリメントして進められる(例えばポインタが進めら
れる)。さらに、ヘッダーの特定のフィールドが、既知の値または期待値と比較
される場合、そのフィールドから2バイトまでが同時に抽出される。さらに、値
またはヘッダーフィールドが、レジスタまたは他のデータ構造に格納するために
コピーされる場合には、1つのオペレーションでコピーされ得るデータ量は、複
数の2バイト単位または完全に他の単位(例えば個々のバイト)として表され得
る。本発明の別の実施形態では、この大きさの単位(例えば2バイト)を大きく
してもよいし、または小さくしてもよい。大きさの単位を変更することによって
、その単位を用いてヘッダーが構文解析され得るか、またはヘッダー値が抽出さ
れ得る精度を変更することができる。
【0129】 図12に示す本発明の実施形態において、ヘッダーパーサの命令メモリにロー
ドされる命令のセットは、選択されたプロトコルとの互換性についてパケットを
テストする一方で、複数の実行可能なオペレーションを含む。プログラム120
0は、命令セットから生成される。従って、プログラム1200は、利用可能な
命令セットから生成され得る、単なる1つの可能なプログラム、マイクロコード
、または命令シーケンスにすぎない。
【0130】 本実施形態において、ロードされた命令セットによって、構文解析されている
パケット上で実行され得る次の16のオペレーションをイネーブルする。プログ
ラム1200におけるこれらのオペレーションの特定のインプリメンテーション
は、以下でさらに詳細に議論される。これらの命令は、本質的には例示目的であ
ると理解され、本発明の他の実施形態における命令の構成を制限しない。さらに
、これらのオペレーションの任意のサブセットが、特定の構文解析プログラムま
たはマイクロコードで利用され得る。さらに、複数の命令が、同じオペレーショ
ンを利用して、異なる効果を達成することができる。
【0131】 CLR_REGオペレーションは、プログラム1200で用いられるレジスタ
または他のデータ構造、可能な場合にはパケットを構文解析した後に実行される
機能で用いられるデータ構造の選択的な初期化を可能にする。初期化は、値0を
格納する工程を含み得る。CLR_REGオペレーションによって初期化され得
る複数の例示的なレジスタは、残りのオペレーションにおいて識別される。
【0132】 LD_FIDオペレーションは、パケット内の特定のオフセットからパケット
のフローキーまたは他のフロー識別子を格納するように構成されたレジスタへと
データ量を可変にしてコピーする。このレジスタは、FLOWIDレジスタと呼
ばれ得る。LD_FIDオペレーションの効果は、累積型である。すなわち、1
つのパケットについて呼び出されるたびに、生成されたデータは、予め格納され
たフローキーデータにアペンドされる。
【0133】 LD_SEQオペレーションは、パケットの内の特定のオフセットからパケッ
トのシーケンス番号(例えばTCPシーケンス番号)を格納するように構成され
たレジスタへとデータ量を可変にしてコピーする。このレジスタは、ラベルSE
QNOを割り当てられ得る。このオペレーションもまた累積型である―そのパケ
ットについてのこのオペレーションの第2の呼び出し、そしてそれに続く呼び出
しによって、識別されたデータは予め格納されたデータにアペンドされる。
【0134】 LD_CTLオペレーションは、パケット内の特定のオフセットからCONT
ROLレジスタ内へ値をロードする。CONTROLレジスタは、パケットがデ
ータリアセンブリ、パケットバッチング、負荷分散、またはNIC100の他の
機能強化した機能に適切であるかどうかを識別するために、制御インジケータを
含み得る。特に、制御インジケータは、No_Assistフラグがパケットを
引き上げるべきかどうか、パケットが任意のデータを含むかどうか、パケットの
データ量が所定の閾値より多いかどうか等を示し得る。従って、LD_CTLオ
ペレーションにおいてCONTROLレジスタにロードされた値は、パケットの
構文解析後の処理に影響し得る。
【0135】 LD_SAPオペレーションは、パケットの内の可変オフセットからCONT
ROLレジスタ内へ値をロードする。ロードされた値は、パケットのイーサタイ
プ(ethertype)を含み得る。LD_SAPオペレーションに関連付け
られ得る1つのオプションとして、パケットのレイヤー3のヘッダーのオフセッ
トはまた、CONTROLレジスタまたは他のどこかに格納され得る。当業者で
あれば認識するように、パケットがイーサネット(登録商標)およびIPプロト
コルに適合する場合、パケットのレイヤー3のヘッダーは、レイヤー2のイーサ
タイプのフィールドに直ちに続き得る。
【0136】 LD_R1オペレーションは、パケット内の可変オフセットから(例えばR1
と称される)一時レジスタ内へ値をロードするために用いられ得る。一時レジス
タは、ヘッダーまたはパケットの他の部分の長さを判定するために値を累積する
等の種々のタスクに用いられ得る。LD_R1オペレーションはまた、他の可変
オフセットからの値を(例えばR2と称される)第2の一時レジスタに格納させ
得る。パケットの構文解析中に、R1レジスタおよび/またはR2レジスタに格
納された値は、累積型であってもよいし、または累積型でなくてもよい。
【0137】 LD_L3オペレーションは、パケットからパケットのレイヤー3のヘッダー
の位置を格納するように構成されたレジスタに値をロードし得る。このレジスタ
は、L3OFFSETと称され得る。このオペレーションを呼び出す1方法とし
て、固定値をL3OFFSETレジスタへロードすることが用いられ得る。別の
オプションとしてLD_L3オペレーションが、一時レジスタ(例えばR1)に
格納された値をL3OFFSETレジスタに格納されている値に付加することが
できる。
【0138】 LD_SUMオペレーションは、チェックサムが計算される必要がある開始位
置をパケット内に格納する。この値が格納されたレジスタは、CSUMSTAR
Tレジスタと称され得る。このオペレーションの別の1呼び出しにおいて、固定
値または所定値がレジスタに格納される。別のオプションとして、LD_SUM
オペレーションは、一時レジスタ(例えばR1)に格納された値をCSUMST
ARTレジスタに格納されている値に付加することができる。
【0139】 LD_HDRオペレーションは、ヘッダー部が分割され得るパケット内の位置
を格納するように構成されたレジスタに値をロードする。格納される値は、例え
ば、パケットのホストコンピュータへの伝送中に、ヘッダー部以外に別の位置に
パケットのデータ部を格納するために用いられ得る。従って、ロードされた値は
パケットデータの先頭または特定のヘッダーの先頭を識別することができる。L
D_HDRオペレーションのある呼び出しで、格納された値は、上述の構文解析
ポインタの現在の位置から計算され得る。別の呼び出しでは、固定値または所定
値が格納され得る。さらに別の代替例として、一時レジスタ(例えばR1)に格
納された値および/または定数が、ロードされた値に付加され得る。
【0140】 LD_LENオペレーションは、レジスタ(例えばPAYLOADLENレジ
スタ)にパケットのペイロード長を格納する。
【0141】 IM_FIDオペレーションは、固定値または所定値を上述のFLOWIDレ
ジスタの既存のコンテンツにアペンドするか、または付加する。
【0142】 IM_SEQオペレーションは、固定値または所定値を上述のSEQNOレジ
スタのコンテンツにアペンドするか、または付加する。
【0143】 IM_SAPオペレーションは、固定値または所定値を上述のCSUMSTA
RTレジスタにロードするか、または格納する。
【0144】 IM_R1オペレーションは、所定値を1つ以上の一時レジスタ(例えばR1
、R2)に付加し得るか、またはアペンド得る。
【0145】 IM_CTLオペレーションは、固定値または所定値を上述のCONTROL
レジスタにロードするか、または格納する。
【0146】 ST_FLAGオペレーションは、パケット内の特定のオフセットからFLA
GSレジスタに値をロードする。ロードされた値は、パケットヘッダーからの1
つ以上のフィールドまたはフラグを含み得る。
【0147】 当業者であれば、オペレーションおよび本セクションにおいて上述したレジス
タならびにその他に割り当てられるラベルは、本質的には単なる例示にすぎず、
本発明の他の実施形態で利用され得るオペレーションおよび構文解析命令を何ら
制限しないということを理解する。
【0148】 プログラム1200における命令は、プログラム内に複数の命令を含む命令番
号フィールド1202、および命令の名前を含む命令名フィールド1204を含
む。本発明の別の実施形態において、命令番号フィールドおよび命令名フィール
ドは、マージされてもよいし、またはそれらのうちの一方を省いてもよい。
【0149】 命令コンテンツフィールド1206は、命令を実行するための複数の部分を含
む。命令の「抽出マスク」部は、16進法の2バイトマスクである。抽出マスク
は、現在のパケットオフセット(例えば、構文解析ポインタの現在の位置)から
開始する際に、コピーまたは抽出されるパケットヘッダー部を識別する。例示的
に、16進法の値のうちの1つに対応するパケットのヘッダーの各ビットは、比
較値またはテスト値と比較するためにコピーされる。例えば、命令の抽出マスク
部における0xFF00値は、現在のパケットオプセットの第1のバイト全体を
コピーして、第2のバイトのコンテンツが関係ないことを示す。同様に0x3F
FFの抽出マスクは、第1のバイトの2つの最上位ビットを除く全てがコピーさ
れるということを示す。2バイト値は、パケットからコピーされるものは何でも
用いて、抽出されたコンテンツから構成される。例示的に、値の残りが0でパデ
ィングされる。当業者であれば、抽出マスク(または以下で述べる出力マスク)
のフォーマットは、必要に応じて、小さなエンディアン(endian)または
大きなエンディアン表示を反映するように準備され得ることを理解する。
【0150】 構文解析プログラムにおける1つ以上の命令は、出力オペレーションを行うこ
とができるように、ポインタ位置でパケットから抽出される任意のデータを必要
とし得ない。これらの命令は、0x0000の抽出マスク値を有し、それにより
2バイト値がやはりポインタ位置から取り出されるが、全てのビット値がマスキ
ングによって除去されるということを示し得る。従って、このような抽出マスク
は、0の一定値を生成する。このタイプの命令は、例えば、ヘッダーデータの他
の実質的な部分が0x0000以外の抽出マスクで抽出される前に、出力オペレ
ーションが行われる必要がある場合に用いられ得る。
【0151】 命令の「比較値」部は、2バイトの16進数値であり、この値を用いて抽出さ
れたパケットのコンテンツが比較される。比較値は、特定のプロトコルヘッダー
の特定のフィールドに格納されることが分かっている値であり得る。比較値は、
ヘッダーの抽出部が一致する必要があるか、または特定の関係にある値を含み、
それによりパケットが予め選択されたプロトコルと互換性があるとみなされ得る
【0152】 命令の「オペレータ」部は、どのように抽出したか、そして比較値がどのよう
に比較されるかを示すオペレータを識別する。例示的に、EQは、等式でテスト
されることを示し、NEは不等式でテストされることを示し、LTは、比較がう
まくいくためには抽出された値が比較値よりも小さくある必要があるということ
を示し、GEは、抽出された値が、比較値より大きいか、または等しくある必要
があるということを示す等である。構文解析される新たなパケットの到着を待つ
命令は、NPオペレーションを利用し得る。他の機能の他のオペレータを付加す
ることができ、既存のオペレータに他の名前を割り当てることができる。
【0153】 命令の「成功オフセット」部は、抽出された値とテスト値との間の比較が成功
した場合に、ポインタが進む2バイト単位数を示す。命令の「成功命令」部は、
比較がうまくいった場合に実行するために、プログラム1200内の次の命令を
識別する。
【0154】 同様に、「失敗オフセット」部および「失敗命令」部は、比較がうまくいかな
かった場合に、それぞれ、ポインタを進めるための2バイト単位数および実行す
るための次の命令を示す。本発明の本実施形態において、オフセットは、2バイ
ト単位(例えば16ビットワード)で表されるが、本発明の別の実施形態におい
て、それらオフセットはより小さな単位であってもよいし、またはより大きな単
位であってもよい。さらに、上述したように、命令は番号または名前によって識
別されてもよい。
【0155】 プログラム内の必ずしも全ての命令が、構文解析される各パケットに対して用
いられる必要はない。例えば、プログラムは、特定の層のプロトコルの1つより
多くのタイプまたはプロトコルのバージョンについてテストを行う命令を含み得
る。特に、プログラム1200は、レイヤー3のIPプロトコルのバージョン4
またはバージョン6のいずれかについてテストする。従って、所与のパケットに
ついて実際に実行される命令は、パケットのフォーマットに依存する。パケット
が所与のプログラムによって可能な限り多く構文解析されると、またはパケット
が選択されたプロトコルに適合するかどうかが判定されると、構文解析を停止し
得るか、または構文解析プロシージャを停止する命令が実効され得る。例示的に
、値「DONE」を有する命令の次の命令部(例えば「成功命令」または「失敗
命令」)は、パケットの構文解析の完了を示す。DONEまたは同様の命令は、
ダミー命令であり得る。すなわち、「DONE」は、単に、現在のパケットにつ
いて構文解析を停止させることを示し得る。または、プログラム1200の命令
18のように、DONE命令は、新たなパケットを待つように(例えばレジスタ
を初期化することによって)何らかのアクションをとることができる。
【0156】 命令コンテンツフィールド1206の残りの部分は、出力または他のデータ格
納オペレーションを特定し、完了するために用いられる。特に、本実施形態にお
いて、命令の「出力オペレーション」部は、ロードされた命令セットに含まれる
命令に対応する。従って、プログラム1200の場合、命令の出力命令部は、上
述の16のオペレーションのうちの1つを識別する。プログラム1200で利用
される出力オペレーションについては、個々の命令とともに以下でさらに説明す
る。
【0157】 命令の「オペレーション引数」部は、格納され、ロードされ、そうでない場合
には命令の出力オペレーションとともに用いられる1つ以上の引数またはフィー
ルドを含む。例示的に、オペレーション引数部は、マルチビット16進数値の形
式をとる。プログラム1200の場合、オペレーション引数のサイズは11ビッ
トである。引数または引数の一部は、出力オペレーションに応じて種々の意味を
有し得る。例えば、オペレーション引数は、レジスタに格納されるか、またはヘ
ッダー部を見つけるまたは定めるために用いられる1つ以上の数値を含み得る。
あるいは、引数ビットは、アクションまたは状態を信号で送るためのフラグを含
み得る。特に、1つの引数ビットは、特定のレジスタがリセットされる、引数ビ
ットのセットが、レジスタに格納される値に対するオフセットをパケットヘッダ
ー内に含み得る等を特定し得る。例示的に、オペレーション引数によって特定さ
れたオフセットが、適用可能な成功オフセットまたは失敗オフセットによってポ
インタを特定し、そのポインタを進める前に、構文解析を行うポインタ位置を位
置付けるために適用される。プログラム1200で用いられるオペレーション引
数は以下でさらに詳細に説明される。
【0158】 命令コンテンツフィールドの「オペレーションイネーブラ」部は、命令の出力
オペレーションが実行されるかどうか、またはいつ実行されるかを特定する。特
に、本発明の例示的な実施形態において、命令の出力オペレーションは、ヘッダ
ーから抽出された値と比較値との間の比較結果に応じて、実行されてもよいし、
または実行されなくてもよい。例えば、出力イネーブラは、出力オペレーション
が全く実行されない場合に、第1の値(例えば0)に設定され得る。比較がオペ
レータを満たす場合にのみ実行される際には、出力イネーブラは異なる値(例え
ば1)を取ることができ、また比較がオペレータを満たさない場合にのみ実行わ
される際には、出力イネーブラは異なる値(例えば2)を取ることができる。常
に実行される際には、オペレーションイネーブラは、さらに別の値(例えば3)
をとることができる。
【0159】 命令の「シフト」部は、出力値がどれだけシフトすべきかを示す値を含む。異
なるプロトコルは、異なってフォーマットされる値を近いうちに必要とするので
、シフトが必要であり得る。さらに、ヘッダーまたはヘッダーフィールドの長さ
あるいは位置を示す値は、その値が表す適切な大きなを反映するために、シフト
を必要とし得る。例えば、プログラム1200は、2バイト単位を用いて設計さ
れるので、他の単位(例えばバイト)を反映する場合には、値をシフトする必要
があるかもしれない。本実施形態におけるシフト値は、出力値を右へシフトさせ
る位置数(例えばビット)を示す。本発明の別の実施形態において、シフト値は
、異なるシフトタイプまたは方向を表し得る。
【0160】 最後に、「出力マスク」は、レジスタまたは他のデータ構造に格納されている
値がどのようにフォーマットされるべきかを特定する。上述のように、出力オペ
レーションは、抽出され、計算され、または格納されるようにアセンブルされた
値を必要とし得る。抽出マスクと同様に、出力マスクは2バイト16進数値であ
る。本発明の本実施形態において、1を含む出力マスクのすべての位置について
、出力オペレーションおよび/またはオペレーション引数によって識別される、
2バイト値における対応するビットが格納される。例えば、0xFFFF値は、
特定される2バイト値がそのまま格納されるということを示す。例示的に、0を
含む出力マスクにおけるすべての位置について、0が格納される。従って、0x
F000値は、第1のバイトの最上位4ビット格納されるが、格納された値の残
りは関係なく、0でパディングされてもよいということを示す。
【0161】 「NONE」の出力オペレーションは、実行されるかまたは格納される出力オ
ペレーションがないことを示すために用いられ得る。この場合、出力に関係する
他の命令部は無視されてもよいし、または特定の値(例えばすべて0)を含んで
もよい。しかしながら図12に示されるプログラムでは、レジスタの選択的な再
初期化を可能にするCLR_REG出力オペレーションを、オペレーション引数
0とともに用いて、効果的な出力を実行することはできない。特に、CLR_R
EGオペレーションのオペレーション引数0は、リセットされるレジスタがない
ことを示す。本発明の別の実施形態において、命令のオペレーションイネーブラ
部が、出力オペレーションが全く実行されないことを示す値(例えば0)に設定
され得る。
【0162】 図12の命令のフォーマットおよびシーケンスは、パケットを構文解析してパ
ケットが特定の通信プロトコルに適合しているかどうかを判定する単なる1つの
手段を表すにすぎないことが理解される。特に、命令は、既知の値または期待値
と比較するために、1つ以上のパケットの1つ以上のヘッダー部を検査し、必要
に応じて、レジスタまたは他の格納位置を構成またはロードするように設計され
る。当業者であれば、パケットを構文解析する命令は、多数の形式のうちの任意
の形式を取り得、本発明の範囲を逸脱することなく、様々なシーケンスで実行さ
れ得ることを理解する。
【0163】 図12を参照して、プログラム1200の命令を詳細に説明し得る。図12に
示されるプログラムを実行する前に、構文解析ポインタが、レイヤー2のヘッダ
ーの先頭に置かれる。構文解析ポインタの位置は、構文解析プロシージャ時に容
易に参照し、更新するためにレジスタに格納され得る。特に、(例えば、レイヤ
ー2のヘッダーの先頭からの)オフセットとしての構文解析ポインタの位置は、
ヘッダー内の特定の位置の位置を計算する際に使用され得る。
【0164】 プログラム1200は、WAIT命令(例えば、命令0)で始まる。そのWA
IT命令は、(例えば、オペレータNPで示される)新しいパケットを待ち、パ
ケットが受け取られると、構文解析ポインタをレイヤー2のヘッダーの12バイ
トに設定する。この12バイトのオフセットは、命令の成功オフセット部によっ
て示される。パケットが受け取られるまで、WAIT命令は、それ自身上でルー
プする。さらに、CLR_REGオペレーションが実行されるが、CLR_RE
Gオペレーションイネーブラ設定は、比較が成功する場合(例えば、新しいパケ
ットが受け取られる場合のみ、そのCLR_REGオペレーションが実行される
ことを示す。
【0165】 特定のCLR_REGオペレーションは、WAIT命令のオペレーション引数
(すなわち、0x3FF)に従って、動作する。この実施形態において、引数の
各ビットは、レジスタまたは他のデータ構造に対応する。このオペレーションに
おいて初期化されるレジスタは、以下のことを含み得る:ADDR(例えば、構
文解析アドレスポインタまたは位置を格納する)、FLOWID(例えば、パケ
ットのフローキーを格納する)、SEQNO(例えば、TCPシーケンス番号を
格納する)、SAP(例えば、パケットイーサタイプ)およびPAYLOADL
EN(例えば、ペイロード長)。一定のオフセットを格納するように構成される
次のレジスタがまた、再設定され得る。このようなレジスタには、FLOWOF
F(例えば、FLOWIDレジスタ内のオフセット)、SEQOFF(例えば、
SEQNOレジスタ内のオフセット)、L3OFFSET(例えば、パケットの
レイヤー3のヘッダーのオフセット)、HDRSPLIT(例えば、パケットを
分離するための位置)およびCSUMSTART(例えば、チェックサムを計算
する開始位置)が挙げられる。また、パケットの1つ以上のフラグの状態を報告
する1つ以上の状態または制御インジケータ(例えば、CONTROLまたはF
LAGSレジスタ)が再設定され得る。さらには、1つ以上の一時レジスタ(例
えば、R1、R2)または他のデータ構造もまた、初期化され得る。上記のレジ
スタは、本発明の1実施形態に用いられ得るデータ構造について示しているに過
ぎない。他のデータ構造は、同じまたは異なる出力オペレーションについて他の
実施形態で用いることができる。
【0166】 R1および/またはR2等の一時レジスタは、様々なヘッダーおよびヘッダー
フィールドを追跡するために、プログラム1200で用いられ得る。当業者は、
通信プロトコルの可能な組み合せの数およびパケットヘッダーの構造およびフォ
ーマットにおける通信プロトコルの様々な組み合せの効果を認識する。別のプロ
トコルまたはプロトコルのセットに適合するパケットから以外にも1つのプロト
コルまたはプロトコルのセットに適合するパケットから、さらなる情報が検査さ
れ、集められる必要があり得る。例えば、拡張ヘッダーが、インターネットプロ
トコルヘッダーで用いられる場合、それらの拡張ヘッダーおよび/またはその長
さから得られる値を格納する必要があり得、拡張ヘッダーが用いられない場合、
その値は必要とされない。例えばパケットデータ部の先頭に対するオフセット等
の特定のオフセットを計算する場合、複数のレジスタを維持する必要があり得、
それらの値は組み合わされるかまたは加えられる。この例では、一方のレジスタ
または一時レジスタは拡張ヘッダーのサイズまたはフォーマットを追跡し得、他
方のレジスタはベースIPヘッダーを追跡する。
【0167】 命令VLAN(例えば、命令1)は、VLANタグ(tagged)ヘッダー
(例えば、16進数での8100)を示す値について、構文解析ポインタ位置(
おそらく、タイプ、長さまたはTPIDフィールド)にある2バイトフィールド
を検査する。ヘッダーが、VLANタグである場合、ポインタは、数バイト(例
えば、1つの2バイト単位)でインクリメントされ、命令CFIを実行し続ける
;ヘッダーがVLANタグでない場合、命令802.3を実行し続ける。いずれ
のイベントでも、命令のオペレーションイネーブラは、IM_CTLオペレーシ
ョンが常に実行されることになることを示す。
【0168】 上述されたように、IM_CTLオペレーションにより、制御レジスタまたは
他のデータ構造が1つ以上のフラグでポピュレートされ、パケットの状態または
状況を報告する。制御インジケータは、パケットが強化処理に適切であるかどう
か(例えば、パケットのためにNo_Assist信号が生成されるかどうか)
、パケットが任意のデータを含むかどうか、そうである場合、データ部のサイズ
は特定の閾値を超えるかどうかを示し得る。命令VLANに用いるオペレーショ
ン引数0x00Aは、制御レジスタに格納される値を含み、引数の個々のビット
は特定のフラグに対応する。例示的に、上述の条件に関連するフラグは、このI
M_CTLオペレーションでは、1または真に設定され得る。
【0169】 命令CFI(例えば、命令2)は、レイヤー2のヘッダーの、CFIビットま
たはフラグを検査する。CFIビットが設定される場合、パケットは、本発明の
本実施形態の処理強化に適切でなく、構文解析プロシージャは、命令DONE(
例えば、命令18)を呼び出すことによって終了する。CFIビットが設定され
ていない場合、ポインタは、別の数バイト分インクリメントされ、命令802.
3が実行し続ける。上述のように、ヌル出力オペレーション(例えば、「NON
E」)は、実行される出力オペレーションがないことを示す。さらには、その出
力イネーブラ値(例えば、0)は、出力オペレーションが実行されないことをさ
らに確実にする。
【0170】 命令802.3(例えば、命令3)で(パケットのポインタの位置およびフォ
ーマットに依存する)タイプまたは長さフィールドを調べて、パケットレイヤー
2のフォーマットが従来のイーサネット(登録商標)または802.3イーサネ
ット(登録商標)であるかどうかを判定する。ヘッダーフィールドの値が802
.3イーサネット(登録商標)を示す(例えば、0600未満の16進法の値を
含む)ような場合、ポインタは(LLCS NAPフィールドであるべき値まで
)2バイト分インクリメントされ、命令LLC_1が実行され続ける。そうでな
い場合、レイヤー2のプロトコルは従来のイーサネット(登録商標)とみなされ
得、命令IPV4_1が実行され続ける。本発明のこの実施形態において命令8
02.3は、出力オペレーションを含まない。
【0171】 命令LLC_1およびLLC_2(例えば、命令4および5)では、疑わしい
レイヤー2のLLC SNAPフィールドは検査され、パケットが802.3イ
ーサネット(登録商標)プロトコルに適合することを確実にする。命令LLC_
1において、フィールドの第1の部分はテストされ、このテストが成功である場
合、ポインタは2バイト分インクリメントされ、命令LLC_2において、第2
部がテストされる。命令LLC_2が成功である場合、構文解析ポインタは4バ
イト分増加し、タイプフィールドになるべき値に到達し、命令IPV4_1が実
行され続ける。しかし、いずれのテストが失敗しても、構文解析プロシージャは
終了する。本発明の図示される実施形態において、LLC SNAPフィールド
をテストしながら実行される出力オペレーションはない。
【0172】 命令IPV4_1(例えば、6)において、構文解析ポインタは、イーサネッ
ト(登録商標)タイプフィールドにあるべきである。このフィールドは検査され
、レイヤー3のプロトコルはインターネットプロトコルのバージョン4に対応す
るかどうかを判定する。このテストが成功である(例えば、タイプフィールドが
16進法で0800の値を含む)場合、ポインタは、レイヤー3のヘッダーの先
頭まで2バイト分進み、プログラム1200の実行は命令IPV4_2に続く。
テストが失敗である場合、命令IPV6_1が実行され続ける。テスト結果に関
わらず、オペレーションイネーブラの値(例えば、3)は特定のLD_SAP出
力オペレーションが常に実行されることを示す。
【0173】 上述したように、LD_SAPオペレーションにおいて、パケットのイーサタ
イプ(またはサービスアクセスポイント)はレジスタに格納される。オペレーシ
ョン引数0x100の一部、特に最右の6ビット(例えば、0)は、イーサタイ
プを含む2バイトの値へのオフセットを構成する。本コンテクストでは、構文解
析ポインタが既にタイプフィールドにあり、イーサタイプを含むので、この例の
オフセットは0である。ここで説明される実施形態において、オペレーション引
数の残りは、レイヤー3のヘッダーの開始位置(例えば、パケットの先頭からの
オフセット)もまた、(例えば、L3OFFSETレジスタに)保存されること
を示すフラグを構成する。特に、レイヤー3のヘッダーの先頭は、2バイトタイ
プフィールドのすぐ後に位置することが分かっている。
【0174】 命令IPV4_2(例えば、命令7)は、疑わしいレイヤー3のバージョンフ
ィールドをテストし、レイヤー3のプロトコルがIPのバージョン4であること
を確実にする。特に、IPのバージョン4についての仕様は、レイヤー3のヘッ
ダーの最初の4ビットが、0x4の値を含むという条件をつける。テストが失敗
である場合、構文解析プロシージャは、命令DONEにより終了する。テストが
成功である場合、ポインタは6バイト進み、命令IPV4_3が呼び出される。
【0175】 特定されたLD_SUMオペレーションは(それは命令IPV4_2での比較
が成功である場合にのみ実行されるが)、チェックサムが計算され得るポインタ
の先頭についてのオフセットが格納されるべきであることを示す。特に、記載さ
れる本発明の実施形態で、チェックサムはTCPのヘッダーから計算されるべき
である(この場合、レイヤー4のヘッダーはTCPであると仮定する)。オペレ
ーションの引数値(例えば、0x00A)は、チェックサムが現在のポインタか
ら20バイト(例えば2バイトのインクリメントを10回)の位置にあることを
示す。従って、20バイトの値が構文解析ポインタの位置に加えられ、その結果
がレジスタまたは他のデータ構造(例えば、CSUMSTARTレジスタ)に格
納される。
【0176】 命令IPV4_3(例えば、命令8)は、パケットのIPヘッダーがIP断片
化を示しているかどうかを判定するように設計される。抽出マスクに従ってヘッ
ダーから抽出される値が比較値と等しくない場合、パケットは断片化を示す。断
片化が検出される場合、パケットは、本明細書に記載される処理強化に不適切で
あるとみなされ、プロシージャ(例えば、命令DONEによって)は終了する。
断片化が検出されない場合、ポインタは、2バイト分インクリメントされ、命令
IPV4_4は、LD_LENオペレーションの実行後に呼び出される。
【0177】 LD_LENオペレーションに従って、IPセグメントの長さが保存される。
図示されたオペレーション引数(例えば、0x03E)は、この値が位置付けさ
れる合計長フィールドのオフセットを含む。特に、最下位の6ビットはオフセッ
トを構成する。ポインタは、既にこのフィールドを越えて進行してるので、オペ
レーション引数は負の値を含む。当業者であれば、この2進法での値(例えば、
111110)が10進法での−2の値を表すのに使用され得ることを理解する
。従って、ポインタの現在のオフセット、つまり−4バイト(例えば、2つの2
バイト単位)が、レジスタまたは他のデータ構造(例えば、PAYLOADLE
Nレジスタ)に保存される。負のオフセットを表す任意の他の適切な方法が使用
され得る。または、ポインタが合計長フィールド(例えば、以前の命令時の)よ
り前の位置にある間に、IPセグメント長を保存することができる。
【0178】 命令IPV4_4(例えば、命令9)において、1バイトのプロトコルフィー
ルドは、レイヤー4のプロトコルがTCPであるかどうかを判定するために検査
される。レイヤー4のプロトコルがTCPである場合、ポインタは、14バイト
分進められ、命令TCP_1は実行され続ける。レイヤー4のプロトコルがTC
Pでない場合、プロシージャは終了する。
【0179】 命令IPV4_4での比較がうまくいく場合にのみ実行される特定のLD_F
IDオペレーションは、パケットのフローキーを取り出す工程、および取り出し
たフローキーをレジスタまたは他の位置(例えば、FLOWIDレジスタ)に格
納する工程を含む。当業者であれば、命令IPV4_4がうまくいくためには、
パケットのレイヤー3およびレイヤー4のヘッダーは、それぞれIP(バージョ
ン4)およびTCPに適合する必要があることを理解する。そうである場合、フ
ローキー全体(例えば、IPソースおよび宛先のアドレスに加えてTCPソース
および宛先ポート番号)が、パケットのヘッダー部に連続して格納される。特に
、フローキーは、IPヘッダーの最後部およびTCPヘッダーの先頭部を含み、
1つのオペレーションで抽出され得る。従って、オペレーション引数(例えば、
0x182)は、フローキーを位置付けし、境界を定めるために必要な2つの値
を含む。例示的に、引数の最右の6ビット(例えば、0x02)は、ポインタ部
からフローキーの先頭まで、オフセットを2バイト単位で識別する。引数の他の
5ビット(例えば、0x06)は、格納されるフローキーのサイズを2ビット単
位で識別する。
【0180】 命令IPV4_1によって実行される比較が失敗した後に行われるIPV6_
1(例えば、命令10)で、構文解析ポインタはレイヤー2のタイプフィールド
にあるべきである。このテストが成功する(例えば、タイプフィールドは86D
Dの16進法の値を保持する)場合、命令IPV6_2は、LD_SUMオペレ
ーションが実行された後に実行され、ポインタがレイヤー3のプロトコルの先頭
に2バイト分インクリメントされる。テストが失敗である場合、プロシージャは
終了する。
【0181】 命令IPV6_1において示されるLD_SUMオペレーションは、命令IP
V4_2において実行されるオペレーションに類似してるが、異なる引数を利用
する。ここでもやはり、(レイヤー4のヘッダーはTCPであると仮定すると)
チェックサムはTCPヘッダーの先頭から計算されることになる。従って、特定
されたオペレーション引数(例えば、0x015)は、TCPヘッダーの先頭つ
まり21の2バイトステップ前へのオフセットを含む。示されるオフセットは、
現在のポインタ位置に加えられ、レジスタまたは他のデータ構造(例えば、CS
UMSTARTレジスタ)に保存される。
【0182】 命令IPV6_2(例えば、命令11)はさらに、疑わしいレイヤー3のバー
ジョンフィールドをテストし、レイヤー3のプロトコルがIPのバージョン6で
あることを確実にする。その比較が失敗すると、構文解析プロシージャは、命令
DONEを呼び出して終了する。その比較が成功すると、命令IPV6_3が呼
び出される。この実施形態において比較が成功である場合のみに実行されるオペ
レーションIM_R1は、ペイロード長フィールドからのIPヘッダーを保存す
る。当業者が理解するように、IP(バージョン4)ヘッダーは、合計長フィー
ルド(例えば、IPセグメントサイズ)は、バージョン4のヘッダーサイズを含
む。しかし、IP(バージョン6)ヘッダーのペイロード長フィールド(例えば
、IPセグメントサイズ)は、バージョン6のサイズを含まない。従って、出力
引数の最右8ビット(例えば、0x14、これは20の2バイト単位を示す)に
よって識別されるバージョン6ヘッダーのサイズが、保存される。例示的に、残
りの引数は、ヘッダー長を格納するデータ構造(例えば、一時レジスタR1)を
識別する。プロトコル間のレイヤー3のヘッダーのサイズが変化するために、本
発明の1実施形態において、ヘッダーサイズを異なる単位で識別して、より高い
精度を可能にする。特に、本発明の1実施形態において、ヘッダーのサイズは、
命令IPV6_2において、バイトで特定される。この場合、出力引数は0x1
28である。
【0183】 この実施形態において、命令IPV6_3(例えば、命令12)はヘッダー値
を検査しない。この実施形態において、0x0000の抽出マスクと0x000
0の比較値との組み合せは、ヘッダー部の次の検査の前に出力オペレーションが
望まれることを示す。LD_FIDオペレーションが実行された後に、構文解析
ポインタが、バージョン6のIPヘッダーの次のヘッダーフィールドに6バイト
進められる。抽出マスクおよび比較値が両方とも0x0000であるので、比較
は必ず成功し、命令の失敗ブランチは決して呼び出されない。
【0184】 上述のように、LD_FIDオペレーションは、フローキーを適切なレジスタ
または他のデータ構造(例えば、FLOWIDレジスタ)に格納する。例として
、0x484であるオペレーション引数は、フローキーを識別し、その境界を定
める2つの値を含む。特に、最右の6ビット(例えば、0x04)は、フローキ
ー部が、現在のポインタの位置から8バイト(例えば、2バイトインクリメント
を4回)のオフセットに位置付けされることを示す。残りのオペレーション引数
(例えば、0x12)は、36バイト(例えば、0x12の2バイト単位に相当
する10進法)が計算されるオフセットからコピーされることを示す。本発明の
例示的な実施形態において、フローキー全体がそのままコピーされ、これはレイ
ヤー3のソースおよび宛先のアドレスおよびレイヤー4のソースおよび宛先ポー
トを含む。
【0185】 命令IPV6_4(例えば、命令13)で、疑わしい次のヘッダーフィールド
が検査され、パケットのプロトコルスタックのレイヤー4のプロトコルがTCP
であるかどうかを判定する。レイヤー4のプロトコルがTCPである場合、プロ
シージャは36バイト(例えば、18の2バイト単位)進み、命令TCP_1が
呼び出される。レイヤー4のプロトコルがTCPでない場合、プロシージャは(
例えば、命令DONEによって)終了する。次のヘッダーフィールドの値が0x
06である場合、オペレーションLD_LENが実行される。上述したように、
このオペレーションはIPセグメントサイズを格納する。ここでもやはり、引数
(例えば、0x03F)は、負のオフセット(この場合、−1)を含む。このオ
フセットは、望まれるペイロード長フィールドがポインタの現在の位置の2バイ
ト前に位置することを示す。従って、負のオフセットは現在のポインタオフセッ
トに加えられ、その結果が適切なレジスタまたは他のデータ構造(例えば、PA
YLOADLENレジスタ)に保存される。
【0186】 命令TCP_1、TCP_2、TCP_3およびTCP_4(例えば、命令1
4〜17)には、命令の出力オペレーションで特定される一定のフラグを除いて
検査されるヘッダー値はないが、パケットのTCPヘッダーからの様々なデータ
が保存される。例示的な実施形態において、保存されるデータはTCPシーケン
ス番号、TCPヘッダー長および1以上のフラグを含む。各命令に対して、特定
されたオペレーションが実行され、次の命令が呼び出される。上述したように、
これらの命令の各々で用いられる0x0000の比較値とヌル抽出値の間の比較
は、必ず成功する。命令TCP_4の後、構文解析プロシージャは、新しいパケ
ットを待つ命令WAITに戻る。
【0187】 命令TCP_1におけるオペレーションLD_SEQの場合、オペレーション
引数(例えば、0x081)は、TCPシーケンス番号を識別し、抽出する2つ
の値を含む。最右の6ビット(例えば、0x01)は、シーケンス番号が、ポイ
ンタの現在位置から2バイトに位置することを示す。残りの引数(例えば、0x
2)は、その位置からコピーされなければならない2バイト単位の数を示し、シ
ーケンス番号を取り込む。例として、シーケンス番号は、SEQNOレジスタに
格納される。
【0188】 命令TCP_2のオペレーションST_FLAGの場合、オペレーション引数
(例えば、0x145)を用いて、構文解析後のタスクで使用されるレジスタ(
例えば、フラグレジスタ)をフラグで構成する。最右6ビット(例えば、0x0
5)は、パケットが、本発明の実施形態の構文解析後の強化に適切であるかどう
かに影響し得るフラグを含むTCPヘッダーの2バイト部に2バイト単位でオフ
セットを構成する。例えば、URG、PSH、RST、SYNおよびFINフラ
グはオフセット位置に位置し得、レジスタを構成するのに使用され得る。出力マ
スク(例えば、0x002F)は、TCPヘッダーのフラグフィールドの特定部
(例えば、ビット)のみが格納されることを示す。
【0189】 命令TCP_3のオペレーションLD_R1は、命令IPV6_2で実行され
るオペレーションに類似する。ここでは、0x205のオペレーション引数は、
現在のポインタの位置からの5つの2バイト単位のオフセットを識別する値(例
えば、最下位の6ビット)を示す。その位置には、残りの引数によって識別され
るデータ構造(例えば、レジスタR1)に格納されるヘッダー長フィールドが含
まれるべきである。出力マスク(例えば、0xF000)は、最初の4ビットの
みが保存される(例えば、ヘッダー長フィールドのサイズはわずか4ビットであ
る)ということを示す。
【0190】 当業者が認識するように、ヘッダー長フィールドから抽出される値は、例示さ
れた実施形態において2バイト単位(例えば、16ビットワード)の使用を反映
するように調整される必要があり得る。それゆえ、命令TCP_3のシフト部に
従って、フィールドから抽出され、出力マスク(例えば、0xF000)によっ
て構成される値が、計算を容易にするために格納される場合、右に11の位置だ
けシフトされる。
【0191】 命令TCP_4のオペレーションLD_HDRは、TCPヘッダーに続いてパ
ケットデータの第1のバイトのオフセットのローディングを引き起こす。例示的
に、予め選択されたプロトコルスタックに適合するパケットは、いくつかの点で
ヘッダー部およびデータ部に分離され得る。次にオフセットをデータ部に保存す
ることによって、パケットを後で分けることを容易にする。例として、0x0F
Fオペレーション引数の最右の7ビットは、データについてのオフセットの第1
の要素を含む。当業者は、ビットパターン(例えば、1111111)を−1と
等価であるとみなす。従って、現在の構文解析ポインタに等しいオフセット値か
ら(例えば、ADDRレジスタの値)2バイト引いた(TCPヘッダーの先頭を
位置付ける)値が、保存される。残りの引数は、一時的なデータ構造(例えば、
一時レジスタR1)の値がこのオフセットに加えられる予定であることを示す。
この特定のコンテクストでは、前の命令で保存される値(例えば、TCPヘッダ
ーの長さ)が加えられる。これらの2つの値が組み合わさって、パケットデータ
の先頭のオフセットを形成する。形成されたオフセットは適切なレジスタまたは
他のデータ構造(例えば、HDRSPLITレジスタ)に格納される。
【0192】 最後に、上述されるように、命令DONE(例えば、命令18)は、パケット
が、例示された命令に関連する1つ以上のプロトコルに適合しないと判定すると
、パケットの構文解析の終了を示す。これは、「クリーンアップ」命令とみなさ
れ得る。特に、オペレーション引数0x001を有する出力オペレーションLD
_CTLは、命令VLANと関係して上記された制御レジスタでNo_Assi
stフラグが(例えば、1に)設定されることを示す。他で説明されているよう
に、No_Assistフラグは、ネットワークインターフェースの他のモジュ
ールに、現在のパケットが他で説明される1つ以上の処理強化に不適切であるこ
とを知らせるのに、使用され得る。
【0193】 例示されるプログラムまたはマイクロコードが、パケットを構文解析する1方
法を提供してるに過ぎない。異なるシーケンスで同じ命令または異なる命令を共
に含む他のプログラムは、ヘッダー部を検査し、格納し、レジスタおよび他のデ
ータ構造を構成するのに使用され得る。
【0194】 本発明の本実施形態の強化処理を適用することによって効率が増し、このこと
は例示されるプログラムを用いたパケットの構文解析に必要な時間を相殺する。
さらに、ヘッダーパーサが、本発明の本実施形態のNIC上のパケットを構文解
析する場合でさえ、パケットは、ホストコンピュータ上のプロセッサによって(
例えば、プロトコルヘッダーを取り除くために)そのプロトコルスタックを通じ
てまだ処理される必要がある。そうすることによって、そのようなタスクによる
通信デバイス(例えば、ネットワークインターフェース)への負荷を防ぐ。
【0195】 (フローデータベースの1実施形態) 図5は、本発明の1実施形態に従って、フローデータベース(FDB)110
を示す。例として、FDB110は、再書き込み可能メモリ構成要素(例えば、
RAM、SRAM、DRAM)を用いてCAM(内容指定メモリ)として実行さ
れる。この実施形態において、FDB110は連想部502および関連部504
を含み、フロー番号506によってインデックスを与えら得れる。
【0196】 本発明の範囲は、フローデータベース110の形式または構造を限定しない。
本発明の代替的な実施形態において、実質的にデータ構造の任意の形式(例えば
、データベース、テーブル、キュー、リスト、アレイ)が用いられ得、モノリシ
ックまたはセグメントのいずれであってもよく、ハードウェアまたはソフトウェ
アで実行され得る。FDB110の例示された形式は、NIC100を通る通信
フローについての有用な情報を維持する1つの手段に過ぎない。当業者には、C
AMの構造は連想検索を非常に効率よく、かつ迅速に実行することを可能にする
ことが明らかである。
【0197】 本発明の例示的な実施形態において、FDB110に格納される情報および(
以下で説明される)フローデータベースマネージャ(FDBM)108のオペレ
ーションにより、データのリアセンブリ、パケットヘッダーのバッチ処理、およ
び他の強化等の機能を可能する。これらの機能は簡潔に以下で説明され得る。
【0198】 データリアセンブリの1形式は、複数の関連付けられたパケット(例えば、1
つの通信フローまたは1つのデータグラムからのパケット)からのデータのリア
センブリまたは組み合せを含む。パケットヘッダーのバッチ処理の1方法は、1
度に1パケットではなく、集約的に複数の関連付けられたパケットからプロトコ
ルスタックまでプロトコルヘッダーを処理することを伴う。NIC100の別の
例示的な機能は、マルチプロセッサホストコンピュータシステムのプロセッサ間
でそのようなプロトコルスタック処理(および/または他の機能)の分散または
共有を含む。NIC100のさらに別の可能な機能は、リアセンブリされたデー
タを、よくまとめて(例えば、メモリページ)、宛先エンティティー(例えば、
アプリケーションプログラム)に伝送することを可能にし、それにより1度に1
パケットデータの断片的で、非常に非効率な伝送を避ける。従って、本発明のこ
の実施形態において、FDB110およびFDBM108の1目的は、これらの
1つ以上の機能をイネーブルするか、ディセーブルするかまたは実行する際に、
NIC100および/またはホストコンピュータの使用のための情報を生成する
ことである。
【0199】 図5のFDB110の連想部502は、NIC100が扱うエンティティに向
けられる各有効なフローのフローキーを格納する。従って、本発明の1実施形態
において、連想部502は、IPソースアドレス510、IP宛先アドレス51
2、TCPソースポート514およびTCP宛先ポート516を含む。前のセク
ションに説明されるように、これらのフィールドは、ヘッダーパーサ106によ
って、パケットから抽出され得、FDBM108に提供され得る。
【0200】 NIC100が扱う各宛先エンティティは、複数の通信フローまたはエンドト
ゥエンド(end to end)TCP接続に関係するが、1度に1フローだ
けが特定のソースエンティティと特定の宛先エンティティとの間に存在する。そ
れゆえ、有効なフローに対応する連想部502の各フローキーは、全ての他の有
効なフローに対して一意的であるはずである。本発明の代替的な実施形態におい
て、連想部502は、異なるフィールドで構成され、代替的なフローキー形式を
反映する。これら異なるフィールドは、ヘッダーパーサによって構文解析された
プロトコルおよび通信フローを識別するのに用いられる情報によって判定され得
る。
【0201】 例示された実施形態において関連部504は、フロー有効インジケータ520
、フローシーケンス番号522およびフロー活動インジケータ524を含む。こ
れらのフィールドは、連想部502における対応するエントリに格納されるフロ
ーキーによって識別されるフローに関する情報を提供する。関連部504のフィ
ールドは、次のセクションで説明されるようにFDBM108によって、取り出
され得るおよび/または更新され得る。
【0202】 この実施形態において、フロー有効インジケータ520は関連付けられたフロ
ーが有効であるか、または無効であるかを示す。例示的に、フローのデータの第
1のパケットが受け取られる場合、フロー有効インジケータは有効なフローを示
すように設定され、フローのデータグラム部(例えば、パケット)が正確に受け
取られる度に、フロー有効インジケータがフローの有効性を再アサートするよう
に再設定され得る。
【0203】 フローのデータの最後のパケットが受け取られた後で、フロー有効インジケー
タ520は無効であるとマーキングされ得る。フロー有効インジケータはまた、
最終データパケットの受信以外に何らかの理由のためにフローが壊される(例え
ば、終了されるまたはアボートされる)場合は常に、無効なフローを示すように
設定され得る。例えば、パケットは、データグラムの他のパケットから無秩序に
受け取られてもよいし、データ伝送またはフローがアボートされることを示す制
御パケットを受け取ってもよいし、(元のフローが終了する場合に)フローを再
確立または再同期をとる試みがなされ得る等である。本発明の1実施形態におい
て、フロー有効インジケータ520は、1つのビット、フラグまたは値である。
【0204】 例示的な実施形態において、フローシーケンス番号522は、関連付けられた
フローに待機する次のデータ部のシーケンス番号を含む。フローで送られるデー
タグラムが一般に複数のパケットを介して受け取られるので、フローシーケンス
番号は、パケットが正確な順番で受け取られるのを確実にする機構を提供する。
例えば、本発明の1実施形態において、NIC100はデータグラムの複数のパ
ケットからデータをリアセンブルする。最も効率的な様態でこのリアセンブリを
行うためには、パケットが正しい順番で受け取られる必要がある。従って、フロ
ーシーケンス番号522は、受け取られるべき次のパケットまたはデータ部を識
別する識別子を格納する。
【0205】 本発明の1実施形態において、フローシーケンス番号522はTCPプロトコ
ルヘッダーにあるTCPシーケンス番号フィールドに対応する。当業者が認識す
るように、パケットのTCPシーケンス番号は、データグラムで送られる他のデ
ータに関連するパケットデータの位置を識別する。TCP以外のプロトコルを含
むパケットおよびフローに対して、正確な順番でデータを受け取ったかを確認す
るか、または正確な順番でデータを受け取ることを確実にする別の方法が使用さ
れ得る。
【0206】 例示的な実施形態におけるフロー活動インジケータ524は、フローの活動の
新しさ、言い換えれば、フローの年齢を反映する。本発明のこの実施形態におい
て、フロー活動インジケータ524は、フロー活動カウンタ(図5に図示せず)
等のカウンタに関連する。フロー活動カウンタは、パケットが、既にフローデー
タベース110に格納されるフローの一部として受け取られる度に更新される(
例えばインクリメントされる)。次いで、更新されたカウンタ値は、パケットの
フローのフロー活動インジケータフィールドに格納される。フロー活動カウンタ
はまた、データベースに加えられる新しいフローの第1のパケットが受け取られ
る度にインクリメントされ得る。別の実施形態において、フロー活動カウンタは
、データを含むパケットについて更新されるのみである(例えば、制御パケット
については更新されない)。さらに別の代替的な実施形態において、複数のカウ
ンタは、異なるフローについてのフロー活動インジケータを更新するために用い
られる。
【0207】 通信フローが終了する(例えば、最終パケットが失われ得る)時点を常に判定
され得るとは限らないので、フロー活動インジケータは、古いまたは何らかの他
の理由で壊されるべきフローを識別するのに使用され得る。例えば、新しいフロ
ーの第1のパケットが受け取られる時にフローデータベース110は完全にポピ
ュレートされる(例えば、フロー有効インジケータ520が各フロー番号に対し
て設定される)ようである場合、最下位のフロー活動インジケータを有するフロ
ーが、新しいフローによって取り替えられ得る。
【0208】 本発明の例示的な実施形態において、FDB110のフィールドのサイズは、
エントリごとに異なり得る。例えば、IPソースおよび宛先アドレスは、プロト
コルのバージョン4で4バイトの大きさであるが、バージョン6では16バイト
である。本発明の別の1実施形態において、特定のフィールドのエントリのサイ
ズは均一であり得、必要に応じてより小さなエントリがパディングされる。
【0209】 本発明の別の代替的な実施形態において、FDB110内のフィールドがマー
ジされ得る。特に、フローのフローキーは、図5に示されるように多数の個別の
フィールドとして格納される代わりに、1つのエンティティまたは1つのフィー
ルドとして格納され得る。同様に、フロー有効インジケータ520、フローシー
ケンス番号522およびフロー活動インジケータ524は、図5で個別のエント
リとして示される。しかし、本発明の別の実施形態において、1つ以上のこれら
のエントリは、組み合わせられ得る。特に、別の1実施形態において、フロー有
効インジケータ520およびフロー活動インジケータ524は、エントリ関連フ
ローが無効である場合、第1の値(例えば0)を有する1つのエントリを含む。
しかし、フローが有効である限り、組み合わされるエントリは、パケットが受け
取られるにつれてインクリメントされ、フローが終了すると第1の値に再設定さ
れる。
【0210】 本発明の1実施形態において、FDB110は、フロー番号506とインデッ
クスを付けられた最大64のエントリを含み、これによりデータベースが1度に
64の有効フローを追跡することを可能にする。本発明の別の実施形態において
、フローデータベース110に割り当てられるメモリのサイズに依存して、より
多いエントリまたはより少ないエントリが可能になり得る。フロー番号506に
加えて、フローは(連想部502に格納される)フローキーによって識別され得
る。
【0211】 本発明の例示的な実施形態において、NIC100が初期化される場合、フロ
ーデータベース110は空である(例えば、全てのフィールドは0で満たされる
)。フローの第1のパケットが受け取られる場合、ヘッダーパーサ106はパケ
ットのヘッダー部を構文解析する。以前のセクションで説明されたように、ヘッ
ダーパーサはフローキーをアセンブルして、フローを識別し、パケットおよび/
またはフローに関する他の情報を抽出する。フローキー、および他の情報は、デ
ータベースマネージャ108に通される。FDBM108は、次いでフローキー
に関連するアクティブフローを求めてFDB110を検索する。データベースは
空なので、一致するものはない。
【0212】 それゆえ、この実施例では、フローキーは、IPソースアドレス、IP宛先ア
ドレス、TCPソースポートおよびTCP宛先ポートを対応するフィールド内へ
コピーすることによって、(例えば、フロー番号0として)格納される。次いで
フロー有効インジケータ520は、有効フローを示すように設定され、フローシ
ーケンス番号522は、(例示的には、ヘッダーパーサによって提供される)T
CPシーケンス番号から得られ、フロー活動インジケータ524は、カウンタか
ら得られ得る初期値(例えば、1)に設定される。適切なフローシーケンス番号
を生成する1つの方法は、TCPシーケンス番号とパケットデータのサイズとを
加えることである。このような方法は、フローで受け取られる次のデータ部が順
番に受け取られることを確認するために使用され得る。しかし、パケットの構成
(例えば、パケットのTCPヘッダーのフラグフィールドにSYNビットが設定
されるかどうか)に依存するので、その和は、正確に次に待機されるデータ部を
識別するように(例えば1を加えることによって)調整される必要があり得る。
【0213】 上述したように、フロー活動インジケータの適切な初期値を生成する1方法は
、フローの一部として受け取られる各パケットについてインクリメントされるカ
ウンタ値をコピーすることである。例えば、NIC100が初期化される後で受
け取られる第1のパケットに対して、フロー活動カウンタは、1の値にインクリ
メントされ得る。次いで、この値が、関連するフローのフロー活動インジケータ
524に格納され得る。同じ(または新しい)フローの一部として受け取られる
次のパケットにより、カウンタは2にインクリメントされる。その値2は、関連
付けられたフローのフロー活動インジケータに格納される。この実施例では、2
つのフローは、それらが等しく0または何らかの所定の値であり得る場合、初期
化時を除いて同じフロー活動インジケータを有す必要はない。
【0214】 NIC100で受け取られる新しい(later)パケットを受信し、構文解
析を行うと、フローデータベースは、そのパケットのフローキーに一致する有効
なフローを求めて検索される。例示的には、アクティブフロー(例えば、フロー
有効インジケータ520が設定されるそれらのフロー)のフローキーのみが検索
される。あるいは、全てのフローキー(例えば、連想部502のすべてのエント
リ)が検索され得るが、フロー有効インジケータが有効フローを示す場合に一致
するかどうかのみが報告される。図5のFDB110等のCAMを用いて、フロ
ーキーおよびフロー有効インジケータは平行して検索され得る。
【0215】 新しいパケットが、前のフロー(例えば、フロー番号0)についての次のデー
タ部を含む場合、そのフローは適切に更新される。本発明の1実施形態において
、これは、最新のフローの活動を反映するためにフローシーケンス番号522の
更新およびフロー活動インジケータ524のインクリメントを必要とする。既に
フローが有効であることを示すべきであるが、フロー有効インジケータ520は
また、フローの有効性を示すように設定され得る。
【0216】 新しいフローが識別される場合、それらは、第1のフローと同じようにFDB
110に加えられる。フローが終了されるまたは壊される場合、FDB110の
関連付けられたエントリは無効になる。本発明の1実施形態において、フロー有
効インジケータ520は、終了したフローについてクリアに(例えば0に設定)
されるだけである。別の実施形態において、終了したフローの1つ以上のフィー
ルドはクリアにされるかまたは任意のまたは所定の値に設定される。ネットワー
クパケットトラフィックのバースト可能性(busrty nature)のた
めに、データグラムからの全てまたはほとんどのデータは、一般に、短時間で受
け取られる。従って、FDB110の各有効フローのみが、一般に短時間の間維
持される必要があり、次いでそのエントリは異なるフローを格納するように使用
され得る。
【0217】 本発明の1実施形態においてフローデータベース110に利用可能なメモリの
制限量によって、各フィールドのサイズは制限され得る。この実施形態において
、16バイトがIPソースアドレス510に割り当てられ、16バイトがIP宛
先アドレス512に割り当てられる。16バイトより短い長さのIPアドレスに
対して、余剰スペースが0でパディングされ得る。さらに、TCPソースポート
514およびTCP宛先ポート516にはそれぞれ2バイトが割り当てられる。
また、この実施形態において、フロー有効インジケータ520は1ビットを含み
、フローシーケンス番号522には4バイトが割り当てられ、フロー活動インジ
ケータ524にもまた、4バイトが割り当てられる。
【0218】 当業者であれば上記の実施形態から認識するように、フローは同じであるが、
エンドトゥエンドTCP接続に関して一致してない。TCP接続は、ソースエン
ティティから宛先エンティティまで複数のデータグラムを伝送するのに十分な比
較的長い期間の間、存在し得る。フローは、しかし、1データグラムについての
み存在し得る。従って、1つのエンドトゥエンドTCP接続の間に、複数のフロ
ーが、(例えば、各データグラムに対して1回)設定され、壊され得る。これま
でに説明されたように、フローは、NIC100がデータグラムにおけるデータ
の第1の部分を検出する場合、設定され得(例えば、FDB110に加えられ、
有効であるとマーキングされ)、データの最後の部分が受け取られる場合、壊さ
れ得る(例えば、FDB110に無効と示される)。例示的に、1つのエンドト
ゥエンドTCP接続の間に設定される各フローは、同じフローキーを有する。こ
れは、フローキーを形成するのに使用されるレイヤー3およびレイヤー4のアド
レスおよびポート識別子は、同じままであるためである。
【0219】 例示的な実施形態において、フローデータベース110のサイズ(例えば、フ
ローエントリの数)は、データのリアセンブリ機能およびプロトコルヘッダーの
バッチ処理をイネーブルにしながら、1度にインタリーブされ得る(例えば、同
時にアクティブである)最大フロー数を決定する。すなわち、図5に示される実
施形態において、NIC100が64のフローを設定し得、フローを壊すことな
く最大64の異なるデータグラムからパケットを受け取り得る(すなわち、64
のフローがアクティブとなり得る)。NIC100による最大フロー数が既知で
ある場合、フローデータベース110は対応するエントリ数に制限さ得る。
【0220】 現在、説明される実施形態において、フローは1データグラムに対して続くだ
けなので、フローデータベースは小さいままであり得る。パケットトラフィック
のバースト可能性のため、データグラムパケットは、一般に短期間内で受け取ら
れる。短期間のフローによって、フローデータベースにおいて制限されたエント
リ数が補償される。本発明の1実施形態において、FDB110はアクティブフ
ローで満たされ、新しいフロー(すなわち、新しいデータグラムでデータの第1
の部分)が開始される場合、最古の(例えば、最近アクティブとなっていない)
フローは新しいフローに置き換えられる。
【0221】 本発明の別の実施形態において、フローは、任意の数のデータグラム(または
ネットワーックトラフィックの他の量)または特定の長さまたは時間範囲につい
てアクティブなままであり得る。例えば、データベースがフルでない場合(例え
ば、フローのエントリが異なるフローに必要とされない場合)、1データグラム
が終了する時点で、FDB110内のフローは「オープン」(すなわち、壊され
ない)なままであり得る。このスキームは、同じフローキーを有する別のデータ
グラムが受け取られる場合、NIC100の効率の良い動作をさらに強化し得る
。特に、別のフローの設定に関わるオーバーヘッドは避けられ、(以下に説明さ
れるような)より多くのデータリアセンブリおよびパケットバッチングが実行さ
れ得る。利点として、フローは、フローを囲むエンドトゥエンドTCP接続が終
了するまで、フローデータベース110でオープンなままであり得る。
【0222】 (フローデータベースマネージャの1実施形態) 図6A〜6Eは、図1Aの、フローデータベース(FDB)110を管理する
フローデータベースマネージャ108を例とするフローデータベースマネージャ
(FDBM)を操作する1方法を示す。例示的には、FDBM108は、フロー
データベース110に格納されるフロー情報を格納および更新し、NIC100
によって受け取られるパケットのオペレーションコードを生成する。FDBM1
08はまた、フローが終了されるまたはアボートされる場合、フローを壊す(例
えば、FDB110において、エントリを取替え、除去し、またはさもなければ
、無効にする)。
【0223】 本発明の1実施形態において、パケットオペレーションコードは、NIC10
0の1つ以上の機能(例えば、データのリアセンブリ、パケットヘッダーのバッ
チ処理、負荷分散)を実行するための所定の判定基準とのパケットの互換性を反
映する。すなわち、パケットのオペレーションコードに依存して、NIC100
の他のモジュールが、これらの機能の内の1つを実行してもよいし、実行しなく
てもよい。
【0224】 本発明の別の実施形態において、オペレーションコードはパケット状態を示す
。例えば、オペレーションコードは、以下のようなパケットを示し得る:データ
を含まない、制御パケットである、特定量より多いデータを含む、新しいフロー
の第1パケットである、現存するフローの最後のパケットである、無秩序である
、予想される値を有さない(従って、多分、例外的な状況を示す)一定のフラグ
を(例えば、プロトコルヘッダー内に)含むパケットなど。
【0225】 フローデータベースマネージャ108の動作は、ヘッダーパーサ106に提供
されるパケット情報およびフローデータベース110から引き出されるデータに
依存する。FDBM108がパケット情報および/またはデータを処理した後で
、制御情報(例えば、パケットオペレーションコード)が制御キュー118に格
納され、FDB110が変更され得る(例えば、新しいフローが入力され得る、
または現存するフローが更新され、もしくは壊される)。
【0226】 図6A〜6Eを参考にして、状態600は、FDBM108がネットワーク1
02からNIC100によって受け取られるパケットから引き出される情報を待
つ開始状態である。状態602では、ヘッダーパーサ106またはNIC100
の別のモジュールは、パケットのフローキーおよびいくつかの制御情報を提供す
ることによって、FDBM108に新しいパケットを知らせる。このデータの受
信は、FDB110を検索して、このフローキーを有するフローが既に存在する
かどうかを判定するためのリクエストとして、解釈され得る。
【0227】 本発明の1実施形態において、FDBM108に通される制御情報は、パケッ
トヘッダーから引き出されるシーケンス番号(例えば、TCPシーケンス番号)
を含む。制御情報はまた、パケットヘッダーの一定のフラグの状態、パケットが
データを含むかどうか、パケットがデータを含む場合、データ量が一定のサイズ
を超えるかどうかを示し得る。この実施形態において、ヘッダーパーサが、予め
選択されたプロトコルスタックの1つに従ってパケットがフォーマットされてい
ない(すなわち、パケットが「互換性」がない)ことを判定する場合、これまで
のセクションで議論されたように、FDBM108はまた、パケットのNo_A
ssist信号を受け取る。例示的に、No_Assist信号は、NIC10
0の1つ以上の機能(例えば、データリアセンブリ、バッチ処理、負荷バランシ
ング)がパケットに提供され得ないことを示す。
【0228】 状態604において、FDBM108は、No_Assist信号が、パケッ
トに対してアサートされるかどうかを判定する。パケットに対してアサートされ
る場合、プロシージャは状態668(図6E)に進む。そうでない場合、状態6
06において、FDBM108はFDB110を検索して、パケットのフローキ
ーを捜す。本発明の1実施形態において、フローデータベースの有効なフローエ
ントリのみが検索される。これまでで議論されたように、フローの有効性は、フ
ロー有効性インジケータ520(図5に示される)を例とする有効性インジケー
タによって反映され得る。状態608において、パケットフローキーがデータベ
ースで見つけられない、または一致はするが、関連付けられたフローが無効であ
ることを判定する場合、プロシージャは状態646(図6D)に進む。
【0229】 有効な一致が、フローデータベースで見つけられる場合、状態610において
、一致するフローのフロー番号(例えば、一致するエントリのフローデータベー
スインデックス)が記され、FDB110に格納されるフロー情報が読まれる。
例示的に、この情報はフロー有効インジケータ520、フローシーケンス番号5
22およびフロー活動インジケータ524(図5に示される)を含む。
【0230】 状態612において、FDBM108は、ヘッダーパーサ106から受け取ら
れる情報からパケットがTCPペイロードデータを含むかどうかを判定する。パ
ケットがTCPペイロードデータを含まない場合、示されるプロシージャは状態
638(図6C)に進む;そうでなければ、プロシージャは状態614に続く。
【0231】 状態614において、フローデータベースマネージャは、パケットが通信接続
またはフローを再設定する試行を構成するかどうかを判定する。例示的には、こ
れは、パケットプロトコルヘッダー(例えば、TCPヘッダー)の1つにおける
SYNビットの状態を検査することによって判定され得る。本発明の1実施形態
において、1つ以上の制御またはフラグビット(例えば、SYNビット)の値が
、ヘッダーパーサによってFDBMに提供される。当業者が認識するように、1
TCPエンティティは別のエンティティとの通信フローまたは接続を再設定し(
例えば、エンティティのホストコンピュータの1つの問題のため)、再接続リク
エストと共に第1のデータ部を送ることを試み得る。これは、状態614におい
て、フローデータベースマネージャが識別しようとする状況である。パケットが
負R−または接続の再接続または再設定の試行の一部である場合、プロシージャ
は状態630で続行する(図6C)。
【0232】 状態616において、フローデータベースマネージャ108は、パケットヘッ
ダーから取り出されるシーケンス番号(例えば、TCPシーケンス番号)とこの
フローに対して予想される次のデータ部のシーケンス番号(例えば、図5のフロ
ーシーケンス番号522)とを比較する。前のセクションで議論されるように、
パケットがフローの次のデータ部を含む場合、これらのシーケンス番号は相関が
あるべきである。シーケンス番号が一致しない場合、プロシージャは状態628
で続く。
【0233】 状態618において、FDBM108は、1つ以上のパケットプロトコルヘッ
ダーから抽出される一定のフラグが予想された値と一致するかどうかを判定する
。例えば、本発明の1実施形態において、パケットのTCPヘッダーからのUR
G、PSH、RSTおよびFINフラグはクリアされる(すなわち、0に等しい
)と予想される。任意のこれらのフラグが設定される(例えば、1に等しい)場
合、例外的な条件が存在し得る。従って、NIC100によって提出される1つ
以上の機能(例えば、データリアセンブリ、バッチ処理、負荷分散)はこのパケ
ットについては実行されるべきでないようにすることが可能になる。フラグがク
リアである限り、プロシージャは、状態620で続く;フラグがクリアでない場
合、プロシージャは、状態626で続く。
【0234】 状態620において、フローデータベースマネージャは、より多くのデータが
、このフローの間、予想されるかどうかを判定する。これまでに議論したように
、フローは、期間が1つのデータグラムに制限され得る。それゆえ、状態620
で、FDBMは、このパケットがこのフローデータグラムにとって最終のデータ
部であるように見えるかどうかを判定する。例示的には、この判定は、現在のパ
ケットに含まれるデータ量を基礎にして為される。当業者が理解するように、1
パケットで運ばれ得るより多くのデータを含むデータグラムは、複数のパケット
により送られる。複数のパケットの間にデータグラムを配置する(dissem
inate)一般的な方式は、各パケットに可能な限り多くのデータを置くこと
である。従って、最後のパケットを除く各パケットは、パケットが送られるネッ
トワークに許容される最大伝送単位(MTU)に常に等しい、またはほぼ等しい
。最後のパケットは残りを保持し、これによって通常、そのサイズはMTUより
小さくなる。
【0235】 それゆえ、フローのデータグラムにおける最終データ部を識別する1つの方式
は、各パケットのサイズを検査し、それを最後のデータ部を運ぶ場合以外にはパ
ケットが超えると予想される数量(例えば、MTU)と比較することである。制
御情報はヘッダーパーサ106からFDBM108によって受け取られることが
これまでに説明された。パケットにより運ばれたデータのサイズの表示は、この
情報に含まれ得る。特に、本発明の1実施形態において、ヘッダーパーサ106
は、各パケットのデータ部のサイズを予め選択された値と比較するように構成さ
れる。本発明の1実施形態において、この値はプログラム可能である。この値は
、本発明の例示的な実施形態において、MTUを超えずにパケットが運ぶことが
可能であるデータ最大量に設定される。別の1実施形態において、その値は、運
び得るデータ最大量より幾分少ない量に設定される。
【0236】 従って、状態620において、フローデータベースマネージャ108は、受け
取られたパケットが、フローのデータグラムについて、最終データ部を運ぶよう
に見えるかどうかを判定する。最終データを運ぶように見えない場合、プロシー
ジャは状態626に続く。
【0237】 状態622において、パケットは予め選択されたプロトコルと互換性があり、
NIC100によって提供される1つ以上の機能に適切であることが確認される
。特に、パケットは、これまで議論された1つ以上の機能に適切にフォーマット
されている。FDBM108は、受け取られるパケットは現存してるフローの一
部であるか、予め選択されたプロトコルと互換性があるか、フローについて次の
データ部(最終部ではない)を含むかを判定した。その上、パケットがフロー/
接続を再設定する試行の一部でなく、重要なフラグは予想された値を有する。従
って、フローデータベース110は以下のように更新され得る。
【0238】 このフローに対する活動インジケータ(例えば、図5のフロー活動インジケー
タ524)は、最新のフロー活動を反映するように変更される。本発明の1実施
形態において、フロー活動インジケータ524は、カウンタとして実行されるか
、カウンタと関連する。カウンタはデータがフローで受け取られる毎にインクリ
メントされる。本発明の別の実施形態において、活動インジケータまたはカウン
タは、有効なフローに一致する(例えば、パケットがデータを含むかどうか)フ
ローキーを有するパケットが受け取られる毎に、更新される。
【0239】 例示的な実施形態において、フロー活動インジケータまたはカウンタがインク
リメントされた後、0に「ローリングオーバー(rolled over)」し
たかどうか(すなわち、その最大値を超えてインクリメントされたかどうか)の
判定が検査される。ゼロにローリングオーバーした場合、フローデータベース1
10の各エントリに対するカウンタおよび/またはフロー活動インジケータは0
に設定され、現在のフローの活動インジケータは、再度インクリメントされる。
従って、本発明の1実施形態において、フロー活動カウンタまたはインジケータ
のローリングオーバーにより、フローデータベース110についてフロー活動機
構の再初期化が引き起こされる。その後、カウンタはインクリメントされ、フロ
ー活動インジケータは、前に説明したように再度更新される。当業者は、一つの
フローが他のフローより、より最近にアクティブであったことを示すために本発
明の実施形態で適用され得る多くの他の適切な方法があることを認識する。
【0240】 さらに状態622において、フローシーケンス番号522は更新される。例示
的には、新しいフローシーケンス番号は、新しく受け取られたデータのサイズを
既存のフローシーケンス番号に加えることによって決定される。パケットの構成
(例えば、そのヘッダーの値)に依存して、この合計は調整される必要がある。
例えば、この合計は、フローデータグラムについて、それまでに受け取られたデ
ータ量全体を単に示し得る。それゆえ、値は、データグラムについてのデータの
次のバイトのシーケンス番号を示すように(例えば、1バイトが)加えられる必
要があり得る。当業者が理解するように、データが順番に受け取られることを確
実にする他の適切な方法は、このコンテクストで説明されるスキームの代わりに
使用され得る。
【0241】 最後に、状態622で、本発明の1実施形態において、フロー有効インジケー
タ520はフロー有効性を示すように設定または再設定される。
【0242】 次いで、状態624では、オペレーションコードはパケットに関連する。本発
明の例示的な実施形態において、オペレーションコードは、フローデータベース
マネージャ108によって生成され、制御キュー118に格納されるコードを含
む。この実施形態において、オペレーションコードは、サイズにして3ビットで
あり、これによって8つのオペレーションコードを許容する。オペレーションコ
ードは、別の実施形態において様々な他の形式および範囲を有し得る。本発明の
例示的な実施形態に対して、表1は、各コード選択およびその選択の分岐に導く
判定基準という点で、各オペレーションコードを説明する。表1の目的に対して
、フローの設定は、フローデータベース110にフローを挿入することを含む。
フローを壊すことは、フローデータベース110のフローを除去または無効にす
ることを含む。データのリアセンブリは、DMAエンジン120により実行され
得る。
【0243】 本発明の例示的な実施形態において、オペレーションコード4は、本明細書中
のプロシージャで、パケット(例えば、次の最後ではないフローのデータ部を運
ぶ互換性のあるパケット)について状態624で選択される。従って、既存のフ
ローは壊されず、新しいフローを設定する必要はない。前に説明されたように、
この実施形態において互換性のあるパケットは、1つ以上の予め選択されたプロ
トコルに適合するパケットである。予め選択されたプロトコルを変えるまたは強
化することによって、実際、任意のパケットは、本発明の別の実施形態において
互換性があり得る。
【0244】 図6A〜6Eを参考にして、状態624の後で、示されたプロシージャは、状
態670で終了する。
【0245】 状態626(状態618または状態620から達する)で、オペレーションコ
ード3はパケットに対して選択される。例示的には、オペレーションコード3は
パケットが互換性があり、有効なフローと一致する(例えば、パケットのフロー
キーは、FDB110の有効なフローのフローキーと一致する)ことを示す。オ
ペレーションコード3はまた、パケットがデータを含み、通信フロー/接続を再
同期または再設定する試行を構成せず、パケットのシーケンス番号が(フローデ
ータベース110からの)予想されたシーケンス番号に一致することを示し得る
。しかし、重要なフラグ(例えば、TCPフラグのURG、PSH、RSTまた
はFINのうちの1つ)が設定される(状態618で判定される)、またはパケ
ットのデータが(状態620で)前に説明された閾値より少ないかのどちらかで
あり、これによって、これ以上のデータは、多分このフロー中のこのパケットに
続きそうにないことを示す。それゆえ、既存のフローは壊されるが、新しいフロ
ーは作成されない。例示的に、フローはフローの有効性インジケータをクリアす
る(例えば、0へ設定する)ことによって壊され得る。状態626の後、例示的
なプロシージャは状態670で終了する。
【0246】 状態628(状態616から達する)において、オペレーションコード2はパ
ケットに対して選択される。このコンテクストにおいて、オペレーションコード
2は、パケットが互換性があり、有効なフローに一致し(例えば、パケットのフ
ローキーはFDB110の有効フローのフローキーと一致する)、データを含み
、通信フロー/接続を再同期または再設定する試行を構成しないことを示し得る
。しかし、(状態616において)パケットから抽出されるシーケンス番号は、
フローデータベース110からの予想されたシーケンス番号に一致しない。これ
は、例えば、パケットが無秩序に受け取られる場合に生じ得る。従って、既存の
フローは壊されるが、新しいフローは確立されない。例示的に、フローは、フロ
ーの有効性インジケータをクリアする(例えば、0へ設定する)ことによって壊
され得る。状態628の後で、例示的なプロシージャが状態670で終了する。
【0247】 状態630には、受け取られるパケットが通信フローまたは接続を再設定する
(例えば、TCP SYNビットが設定される)試行を構成することが判定され
る場合、状態614から入ってくる。状態630で、フローデータベースマネー
ジャ108はさらに多くのデータが続くと予想されるかどうかを判定する。状態
620に関連して説明されるように、この判定は、ヘッダーパーサからのフロー
データベースマネージャによって受け取られる制御情報に基づいて、為され得る
。さらに多くのデータが予想される(例えば、パケットのデータ量が閾値に等し
いかまたは超える)場合、プロシージャは状態634で続く。
【0248】 状態632で、オペレーションコード2はパケットに選択される。オペレーシ
ョンコード2はまた、別のコンテクストにおいて状態628で選択された。現在
のコンテクストにおいて、オペレーションコード2は、パケットは互換性があり
、有効なフローに一致し、データを含むことを示し得る。オペレーションコード
2はまた、このコンテクストにおいてパケットが通信フローまたは接続を再同期
または再設定する試行を構成することを示し得るが、一旦、フロー/接続が再設
定されると、さらに多くのデータが予想されないことを示し得る。それゆえ、既
存のフローは壊され、新しいフローは確立されない。例として、フローは、フロ
ーの有効性インジケータをクリアにする(例えば、0に設定する)ことによって
壊され得る。状態632の後で、示されたプロシージャは状態670で終了する
【0249】 状態634で、フローデータベースマネージャ108は、通信フロー/接続を
再設定または再同期する試行に応答し、それにより付加的なデータが予想される
。従って、既存のフローは、以下のように壊され、取り替えられる。既存のフロ
ーは状態610で取り出されるフロー番号またはパケットのフローキーによって
識別され得る。フローのシーケンス番号(例えば、図5のフローシーケンス番号
522)は次の予想された値に設定される。例示的には、この値は、パケットか
ら(例えば、ヘッダーパーサ106によって)取り出されたシーケンス番号(例
えば、TCPシーケンス番号)およびパケットに含まれるデータ量に依存する。
本発明の1実施形態において、これらの2つの値は加えられ、新しいフローシー
ケンス番号を判定する。以前に議論したように、この合計は(例えば、1を加え
ることによって)調整される必要があり得る。状態634においてまた、フロー
活動インジケータは更新される(例えば、インクリメントされる)。状態622
に関連して説明されるように、フロー活動インジケータがローリングオーバーす
る場合、データベースにある全てのフローについての活動インジケータは0に設
定され、現在のフローは再度インクリメントされる。最後に、フロー有効インジ
ケータは、フローが有効であると示すように設定される。
【0250】 状態636で、オペレーションコード7はパケットに対して選択される。この
コンテクストにおいて、オペレーションコード7はパケットが互換性を有し、有
効フローに一致し、データを含むことを示す。オペレーションコード7は、この
コンテクストにおいて、パケットが通信フロー/接続を再同期または再設定する
試行を構成し、フロー/接続が一旦再設定されると、付加的なデータは予想され
ることをさらに示し得る。事実上、それゆえ、既存のフローは壊され、(同じフ
ローキーを備える)新しいフローは、その場所に格納される。状態636の後で
、示されたプロシージャは終了状態670で終了する。
【0251】 受け取られたパケットがデータを含まないと判定される場合、状態612の後
で状態638に入る。これは、パケットが制御パケットであることをしばしば示
す。状態638で、フローデータベースマネージャ108は、ヘッダーパーサに
よってパケットから抽出された1つ以上のフラグが予想されたまたは望まれた値
に一致するかどうかを判定する。例えば、本発明の1実施形態において、DMA
エンジン120が複数の関連付けられたパケット(例えば、同一のフローキーを
有するパケット)からデータをリアセンブルするために、TCPフラグのURG
、PSH、RST、FINはクリアである必要がある。前に議論されたように、
TCP SYNビットもまた、検査され得る。このコンテクスト(例えば、デー
タのないパケット)において、SYNビットもまた、クリアである(例えば、0
の値を格納する)と予想され得る。フラグ(およびSYNビット)が予想された
値を有する場合、プロシージャは、状態642で続く。しかし、これらのフラグ
のうち任意のものが設定されている場合、例外的な条件が存在し得、従ってNI
C100により提供される1つ以上の機能(例えば、データリアセンブリ、バッ
チ処理、負荷分散)はこのパケットに不適切であり、その場合は、プロシージャ
が状態640に進むことが可能になる。
【0252】 状態640において、オペレーションコード1が、パケットについて選択され
る。例示的に、オペレーションコード1は、パケットが互換性を有し、有効フロ
ーと一致するが、任意のデータを含まないこと、およびパケットヘッダー(単数
または複数)の1以上の重要なフラグまたはビットが設定されることを示す。従
って、既存のフローは壊され、新規のフローは構築されない。例示的に、フロー
の有効インジケータをクリアにすること(例えば、有効インジケータを0に設定
すること)により、フローは壊され得る。状態640の後、図示されたプロシー
ジャは、終了状態670で終了する。
【0253】 状態642において、パケットがデータを含まなくとも、フローの活動インジ
ケータが更新(例えば、インクリメント)される。状態622と共に上記したよ
うに、活動インジケータがロールオーバする場合、本発明の本実施形態において
、データベースのフロー活動インジケータ全てが0に設定され、現在のフローが
再びインクリメントされる。フローの有効インジケータおよびフローのシーケン
ス番号はまた、リセットされ得る。
【0254】 状態644において、オペレーションコード0が、パケットについて選択され
る。例示的に、オペレーションオード0は、パケットが互換性を有し、有効フロ
ーと一致すること、およびパケットが任意のデータを含まないことを示す。例え
ば、パケットは制御パケットであり得る。オペレーションコード0はさらに、ヘ
ッダーパーサ106によりチェックされ、上記された(例えば、URG、PSH
、RST、およびFIN)のようなフラグのいずれもが設定されないことを示す
。従って、既存のフローは壊されず、新規のフローは構築されない。状態644
の後、図示されたプロシージャは、終了状態670で終了する。
【0255】 パケットフローキーが、フローデータベースの有効フローのフローキーのうち
のいずれとも一致しない場合、状態646には状態608から入る。状態646
において、FDBM108は、フローデーベース110がフルであるかどうかを
判定し、データベースがフルであるかどうかを示す何らかの指示情報を保存し得
る。本発明の1実施形態において、有効インジケータ(例えば、図5のフロー有
効インジケータ520)が、あらゆるフロー番号について(例えば、データベー
スのあらゆるフローについて)設定される場合に、フローデータベースがフルで
あるとみなされる。データベースがフルであると、プロシージャは状態650へ
続き、さもなければ状態648へ続く。
【0256】 状態648において、無効フローの最も低いフロー番号(例えば、関連フロー
有効インジケータが0に等しいフロー)が判定される。例示的に、このフロー番
号は、受け取られたパケットが新規のフローの作成を許可する場合、新規のフロ
ーが格納され得る場所である。
【0257】 状態650において、最も古いアクティブフローのフロー番号が決定される。
上記のように、本発明の例示的実施形態において、データがフローについて受け
取られるごとにフロー活動インジケータ(例えば、図5のフロー活動インジケー
タ524)が更新される(例えば、インクリメントされる)。従って、この実施
形態において、最も古いアクティブフローは、最古く更新された(例えば、最も
低い)フロー活動インジケータを有するフローとして識別され得る。例示的に、
複数のフローが共通値(例えば、0)に設定されるフロー活動インジケータを有
する場合、1つのフロー番号がランダムに選択され得るか、または他の何らかの
基準により複数のフローから選択され得る。状態650後、このプロシージャは
状態652に続く。
【0258】 状態652において、フローデータベースマネージャ108は、パケットがデ
ータを含むかどうかを判定する。例示的に、ヘッダーパーサがFDBM108に
提供する制御情報は、パケットがデータを有するかどうかを示す。パケットがデ
ータを含まない場合(例えば、パケットが制御パケットの場合)、例示的プロシ
ージャは、状態668に続く。
【0259】 状態654において、フローデータベースマネージャ108は、現在のパケッ
トとともに受け取られたデータが、関連データグラム/フローについてデータの
最終部を含むことが明らかかどうかを判定する。状態620と共に記載されたよ
うに、この判定はパケットとともに含まれるデータ量に基づいて為され得る。デ
ータ量が閾値(図示された実施形態のプログラマブル値)よりも少ない場合デー
タが全く期待されず、このことはこのフローについてのデータのみであり得る。
この場合、プロシージャは状態668に続く。しかしながら、データが閾値に到
達するか、または閾値を超えた場合(この場合、より多くのデータが期待され得
る)、プロシージャは状態656に進む。
【0260】 状態656において、特定のフラグの値が調べられる。例えば、これらのフラ
グは、TCPヘッダーのURG、PSH、RST、FINビットを含み得る。調
べられたフラグのいずれもが、それらの期待値、または所望の値を有さない場合
(例えば、フラグのいずれもが設定される場合)、このパケットについて、NI
C100の1以上の機能(例えば、データアセンブリ、バッチ処理、負荷分散)
を不適切にする例外的な状態が存在し得る。この場合、プロシージャは状態66
8に続き、さもなければ、プロシージャは状態658に進む。
【0261】 状態658において、フローデータベースマネージャは、フローデータベース
110がフルであるかどうかに関する、状態646に格納された情報を取り出す
。データベースがフルである場合、プロシージャは状態664に続き、さもなけ
れば、プロシージャは状態660に進む。
【0262】 状態660において、新規のフローが、現在のパケット用にフローデータベー
ス110に付加される。例示的に、新規のフローは、状態648で識別されたか
、または取り出されたフロー番号に格納される。新規のフローの付加は、シーケ
ンス番号(例えば、図5からのフローシーケンス番号522)を設定することを
含み得る。フローシーケンス番号522は、パケットから取り出されたシーケン
ス番号(例えば、TCPシーケンス番号)とパケットに含まれるデータ量とを付
加することにより生成され得る。上述されたように、この和は(例えば、1を加
えることによって)調整される必要があるかもしれない。
【0263】 新規のフローの格納は、活動インジケータ(例えば、図5のフロー活動インジ
ケータ524)を初期化する工程もまた包含し得る。本発明の1実施形態におい
て、この初期化は、データがフローについて受け取られるごとにインクリメント
されるカウンタから取り出される値を格納する工程を包含する。例示的に、カウ
ンタまたはフロー活動インジケータが格納可能な最大値を過ぎてインクリメント
される場合、カウンタおよびフロー活動インジケータ全体はクリアにされるか、
またはリセットされる。また、状態660において、有効インジケータ(例えば
、図5のフロー有効インジケータ520)は、フローが有効であることを示すた
めに設定される。最後に、パケットフローキーはまた、フローデータベース内の
、割り当てられたフロー番号に対応するエントリに格納される。
【0264】 状態662において、オペレーションコード6は、パケットについて選択され
る。例示的に、オペレーションコード6は、パケットが互換性を有し、いずれの
有効フローとも一致せず、新規のフローについてデータの先頭部を含むことを示
す。さらに、パケットのフラグが、それらの期待値、または必要とする値を有し
、追加のデータがフローで期待され、フローデータベースはフルにならない。従
って、オペレーションコード6は、壊すような既存のフローが存在しないこと、
および新規のフローがフローデータベースに格納されていることを示す。状態6
62後、図示されたプロシージャは状態670で終了する。
【0265】 状態664において、フローデータベースの既存のエントリが置き換えられ、
それにより、現在のパケットによって開始される新規のフローが格納され得る。
従って、状態650で識別される最も古いアクティブフローのフロー番号が取り
出される。このフローは以下のように置き換えられ得る。既存のフローのフロー
シーケンス番号(例えば、図5のフローシーケンス番号522)は、パケットか
ら抽出されたシーケンス番号(例えば、TCPシーケンス番号)を、パケットの
データ部のサイズと結合することで得られる値と置き換えられる。この合計は、
(例えば、1を付加することにより)調節される必要があり得る。次いで、既存
のフローの活動インジケータ(例えば、フロー活動インジケータ524)が置き
換えられる。例えば、フロー活動カウンタの値は、上記のようにフロー活動イン
ジケータにコピーされ得る。次いで、フロー有効インジケータ(例えば、図5の
フロー有効インジケータ520)は、フローが有効であることを示すように設定
される。最後に、新規のフローのフローキーが格納される。
【0266】 状態666において、オペレーションコード7がパケットについて選択される
。オペレーションコード7はまた、状態636で選択された。この文脈において
、オペレーションコード7は、パケットが互換性を有し、いずれの有効フローの
フローキーとも一致せず、新規のフローについてデータの第1の部分を含むこと
を示し得る。さらに、パケットのフラグが互換可能な値を有し、追加のデータが
フローで期待される。しかしながら、最後に、この文脈において、オペレーショ
ンコード7は、フローデータベースがフルであること、それにより既存のエント
リが壊されること、および新規のエントリをその場所に格納したことを示す。状
態666後、図示されたプロシージャは、終了状態670で終了する。
【0267】 状態668において、オペレーションコード5は、パケットについて選択され
る。状態668には、種々の状態から入り、従って、オペレーションコード5は
、多様な可能な状態または状況を表す。例えば、オペレーションコード5は、N
o_Assist信号がパケットについて検出される(状態604において)場
合に選択され得る。上記のように、No_Assist信号は、対応するパケッ
トが先に選択されたプロトコルのセットと互換性がないことを示し得る。本発明
のこの実施形態において、非互換性パケットは、NIC100の種々の機能のう
ち1以上の機能(例えば、データリアセンブリ、バッチ処理、負荷分散)に対し
て不適格である。
【0268】 状態668はまた状態652から入ることができ、オペレーションコード5は
選択される。この場合、コードは、受け取られたパケットがいずれの有効フロー
キーとも一致せず、さらに、データを全く含まないこと(例えば、受け取られた
パケットが制御パケットであり得ること)を示し得る。
【0269】 状態668はまた、状態654から入ることができる。この文脈において、オ
ペレーションコード5は、パケットがいずれの有効フローキーとも一致しないこ
とを示し得る。さらに、オペレーションコード5は、パケットがデータを含むが
、データ部のサイズが、状態654と共に記載された閾値よりも小さいことを示
し得る。この文脈において、パケットデータが完全である(例えば、データグラ
ムに対するデータ全てを含む)ことが明らかであり、これは、このパケットのデ
ータを用いてリアセンブルする他のデータがないことを意味し、従って、この1
パケットフローについてのデータベースに新規のエントリを作成する理由がない
【0270】 最後に、状態668はまた、状態656から入ることができる。この文脈にお
いて、オペレーションコード5は、パケットがいずれの有効フローキーとも一致
せず、データを含むこと、およびより多くのデータが期待されるが、1以上のパ
ケットプロトコルヘッダーの少なくとも1つのフラグはその期待値を有さないこ
とを示し得る。例えば、本発明の1実施形態において、TCPフラグURG、P
SH、RST、およびFINがクリアにされると予想される。これらフラグのう
ち任意のフラグが設定される場合、例外的な状況が存在し得る。従って、そのよ
うな例外的な状況によって、NIC100が提供する機能のうちの1つがこのパ
ケットについて不適切であることがおこり得る。
【0271】 表1が示すように、オペレーションコード5が選択される場合、壊すフローが
存在せず、新規のフローは構築されない。状態668の後、図示されたプロシー
ジャは状態670で終了する。
【0272】 当業者であれば、図6A〜図6Eに示し、上記したプロシージャは、フローデ
ータベースを維持および更新するため、ならびに特定の処理機能についてパケッ
トの適合性を判定するための単なる1つの適切なプロシージャにすぎないことを
理解する。特に、異なるオペレーションコードが利用され得るか、または異なる
方法でインプリメントされ得、目的は、パケットのNIC100を介した後の処
理のための情報を生成することである。
【0273】 図示されたプロシージャのフローデータベースマネージャは、オペレーション
コードを全てのパケットについて割り当てるが、代替のプロシージャにおいて、
FDBMが割り当てるオペレーションコードは、NIC100の他のモジュール
により、置き換えられ得るか、または変更され得る。これはあるタイプのパケッ
トの特定の処理方法を保証するために、為され得る。例えば、本発明の1実施形
態において、IPPモジュール104は所定のオペレーションコード(例えば、
表1のオペレーションコード2)をジャンボパケット(例えば、MTUより大き
なサイズのパケット)に割り当て、それにより、DMAエンジン120はこれら
のパケットをリアセンブルし得ない。特に、IPPモジュールは、パケットがジ
ャンボパケットであることを独立して(例えば、MACモジュールが提供する情
報から)判定し得、従って、所定のコードに割り当て得る。例示的に、ヘッダー
パーサ106およびFDBM108は、ジャンボパケットについての標準機能を
実行し、IPPモジュール104は、FDBMが割り当てる第1のオペレーショ
ンコードを受け取る。しかしながら、IPPモジュールは、ジャンボパケットお
よびパケットに関する情報を格納する前に、このコードを置き換える。代替の1
実施形態において、ヘッダーパーサ106および/またはフローデータベースマ
ネージャ108は、特定タイプの(例えば、ジャンボ)パケットを認識し、所定
のオペレーションコードを割り当てるように構成され得る。
【0274】 図6A〜図6Eに図示された本発明の実施形態に適用されるオペレーションコ
ードが以下の表1に示され、説明される。表1は、各オペレーションコードを選
択するために使用された例示的基準、および各コードの例示的結果または効果を
含む。
【0275】
【表1】 (ロードディストリビュータの1実施形態) 本発明の1実施形態において、ロードディストリビュータ112は、それらの
プロトコルスタックを介してパケットの処理が多数のプロセッサの間に分散され
ることをイネーブルにする。例示的に、ロードディストリビュータ112は、パ
ケットが発信されるプロセッサの識別子(例えば、プロセッサ番号)を生成する
。複数のプロセッサは、NIC100が扱うホストコンピュータシステム内に位
置し得る。代替の1実施形態において、プロトコルスタックを介してパケットを
マニピュレートする1以上のプロセッサが、NIC100に位置付けされる。
【0276】 処理バードンを共有するか、または分散する効果的な方法を用いずに、NIC
100で受け取られる全てのまたは多くのネットワークトラフィックの処理が特
に高速ネットワーク環境において必要な場合、あるプロセッサはオーバローディ
ングとなり得る。ネットワークトラフィックの処理の結果として生じる遅延は、
ホストコンピュータシステムおよびネットワークを介しホストシステムと通信を
行う他のコンピュータシステム上のオペレーションを劣化させ得る。
【0277】 当業者が理解し得るように、(例えば、ラウンドロビンスキームのような)プ
ロセッサのセットのプロセッサ間で、単にパケットを分散させることが、効率の
良い方式であり得ない。このような方式は、パケットが無秩序に処理されること
を容易に引き起こし得る。例えば、ネットワークインターフェースにて正しい順
番で受け取られる1つの通信フローまたは接続からの2つのパケットが、2つの
異なるプロセッサに発信された場合、第2のパケットは第1のパケットより前に
処理され得る。例えば、第1のパケットを受け取るプロセッサが他のタスクでビ
ジーな状態であるという理由で、そのプロセッサが、直ちにパケットを処理し得
ない場合、このことが発生し得る。パケットが無秩序に処理される場合、回復ス
キームは概して初期化されなければならず、従って、なおさら非効率的となり、
さらなる遅れをもたらす。
【0278】 従って、本発明の本実施形態において、パケットは、自身のフロー指示情報に
基づく複数のプロセッサ間に分散される。上記のように、ヘッダーパーサは、レ
イヤー3(例えば、IPレイヤー)およびレイヤー4(例えば、TCPレイヤー
)ソースからフローキーを生成し得、パケットヘッダーから受け取られる宛先識
別子を生成し得る。フローキーは、パケットが属する通信フローを識別するため
に使用され得る。従って、本発明のこの実施形態において、同一のフローキーを
有するパケット全てが、単一のプロセッサに発信される。NIC100により順
番にパケットが受け取られる限り、それらのパケットは、ホストコンピュータに
供給され、パケットに割り当てられたプロセッサにより順番に処理されるはずで
ある。
【0279】 例示的に、パケットのレイヤー3およびレイヤー4の識別子が同一のフローキ
ーを維持する限り、たとえパケットが別のデータグラムの一部であっても、ある
ソースエンティティからある宛先エンティティに送られる複数のパケットは、同
一のフローキーを有し得る。上記のように、あるTCPエンドゥエンド接続内で
、個々のフローがセットアップされ、各データグラムについて壊される。従って
、あるフロー内の全パケットがあるプロセッサに送られるとすぐに、TCPエン
ドゥエンド接続内の全パケットもまた、同一のプロセッサに送られ得る。このこ
とが、データグラム間でさえパケットの正しい順番を全接続に対して保証する助
けとなる。
【0280】 NIC100が動作するネットワーク環境(例えば、ネットワーク102によ
りサポートされるプロトコル)に依存して、フローキーは大きすぎてプロセッサ
の識別子として使用出来ない。例えば、上記の発明の1実施形態において、例え
ばフローキーは288ビットである。一方、ロードバランススキームに加わるプ
ロセッサ数は非常に小さくなり得る。例えば、図7と共に以下に記載される発明
の実施形態において、最大64のプロセッサがサポートされる。従って、この実
施形態において、6ビット数のみが選択されたプロセッサを識別するために必要
とされる。従って、より大きなフローキーが、より小さな範囲の値中にマッピン
グされ得るか、またはハッシュされ得る。
【0281】 パケットフローキーに基づき、NIC100が受け取るパケットを処理するプ
ロセッサを特定する識別子(例えば、プロセッサ番号)を生成する1つの方法を
、図7に示す。本発明のこの実施形態において、ネットワーク102はインター
ネットであり、受け取られたパケットは、互換性を有するプロトコルスタック(
例えば、レイヤー2のイーサネット(登録商標)、レイヤー3のIP、およびレ
イヤー4のTCP)に従い、フォーマットされる。
【0282】 状態700は開始状態である。状態702において、パケットはNIC100
により受けとられ、パケットのヘッダー部は、ヘッダーパーサ106により構文
解析される(パケット解析方法は先のセクションに記載されている)。状態70
4において、ロードディストリビュータ112はヘッダーパーサ106により生
成されたパケットフローキーを受け取る。
【0283】 パケットフローキーは、この実施形態において288ビット長であるので、状
態706において、ハッシング機能が、大きさのより小さな値を生成するために
実行される。例えば、ハッシュオペレーションは、ATM(非同期伝送モード)
アダプテーションレイヤー5(AAL5)のような32ビットのCRC(反復冗
長性チェック)機能を含み得る。AAL5は、232の可能な値の間にかなり均一
に分散された32ビット数を生成する。ハッシングの他の適切な方法は、標準イ
ーサネット(登録商標)CRC32機能である。比較的小さな数を比較的大きな
フローキーから生成することが可能な他のハッシュ機能はまた、生成した数が値
の範囲間に良好に分散される場合には、適切である。
【0284】 結果として生成されたハッシュ値を用いて、状態708において、モジュール
オペレーションは、処理を分散させるか、または共有させることに利用可能なプ
ロセッサの数に対して実行される。例示的に、ホストコンピュータ(例えば、N
IC100に関するデバイスドライバ)で実行するソフトウェアはプロセッサ数
をプログラムするか、または格納し、それにより、ソフトウェアは、(例えば、
レジスタにおいて)ロードディストリビュータ112により読み出すか、または
取り出され得る。ロードバランシングについて利用可能なプロセッサの数は、ホ
ストコンピュータシステムに組込まれたプロセッサの数の全てか、またはそのサ
ブセットであり得る。図示された実施形態において、ホストコンピュータシステ
ムで利用可能なプロセッサの数は、最大値の64を用いて、プログラマブルであ
る。従って、この実施形態のモジュラスオペレーションの結果は、パケットが処
理のために発信されるプロセッサの数(例えば、0〜63)である。本発明のこ
の実施形態において、ロードディストリビュータ112は、ハードウェア上で実
行され、従って、ハッシュ関数およびモジュラス関数の高速実行を可能にする。
本発明の代替の実施形態において、実質的に任意の数のプロセッサが適応され得
る。
【0285】 状態710において、プロトコルスタックを介してパケットを処理するプロセ
ッサの数は、ホストコンピュータのメモリに格納される。例示的に、状態710
は、ホストメモリバッファのパケットの格納と平行して実行される。本発明の1
実施形態において、ホストコンピュータメモリ内の記述子リングは、プロセッサ
番号および可能ならばパケットに関する他の情報(例えば、パケットへのポイン
タ、パケットサイズ、パケットのTCPチェックサム)を保持するために構築さ
れる。
【0286】 この実施形態において記述子リングは、ネットワークインターフェース回路の
ホストコンピュータシステムが使用する情報を格納するための複数のエントリ、
または「記述子」の数を含むデータ構造である。図示された実施形態において、
パケットがNIC100により受け取られた後であるが、パケットがホストコン
ピュータシステムにより処理される前に、記述子は一時的にパケット情報を格納
する。例えば、記述子に格納される情報は、NIC100に関するデバイスドラ
イバにより、またはプロトコルスタックを介してパケットを処理するために使用
され得る。
【0287】 状態712において、新規のパケットがNIC100から送達されたことをホ
ストコンピュータに知らせるために、割り込みまたは他の警告がホストコンピュ
ータに発行される。NIC100がPCI(周辺部品相互接続)バスによりホス
トコンピュータに接続される本発明の実施形態において、INTA信号がバスを
介してアサートされ得る。ホストのPCIコントローラは信号を受け取り、ホス
トオペレーティングシステムが(割り込みによって)警告される。
【0288】 状態714において、ホストコンピュータ上で動作するソフトウェア(例えば
、NIC100に関するデバイスドライバ)が(例えば、ホストコンピュータの
オペレーティングシステムの割り込みハンドラにより)呼び出され、新規に受け
取られたパケットに作用する。ソフトウェアは、記述子リングの1以上の記述子
から情報を収集し、各新規のパケットの処理を達成するために必要とされる情報
を、(すなわち、パケットの記述子に格納されたプロセッサ番号に従い)特定プ
ロセッサのキューに配置する。例示的に、各記述子は別個のパケットに対応する
。各パケットについて、プロセッサのキューに格納された情報は、パケット、パ
ケットのTCPチェックサム、1以上のプロトコルヘッダーのオフセット等を含
むバッファへのポインタを含み得る。さらに、負荷分散スキームに関与する各プ
ロセッサは、ネットワークパケットを処理するための関連するキューを有し得る
。本発明の代替の実施形態において、複数のキューが(例えば、複数の優先レベ
ルまたは異なるプロトコルスタックに対して)使用され得る。
【0289】 例示的に、ホストコンピュータシステムの1プロセッサは、NIC100から
のネットワークパケットの受け取りに関連する全警告および/または割り込みを
受け取るため、および適切なソフトウェアルーチンまたはデバイスドライバに警
告を出すために構成される。あるいは、この最初の処理は複数のプロセッサの間
で分散される。さらに、本発明の1実施形態において、記述子コンテンツの取り
出しおよびマニピュレーション部は、新規のパケットが記述子リングに格納され
る時に発生される割り込みの処理の一部として実行される。パケットを処理する
ために選択されるプロセッサは、残りの取り出し/マニピュレーションプロシー
ジャを実行し得る。
【0290】 状態716において、新規のパケットを処理するために設計されるプロセッサ
は警告されるか、または呼び起こされる。SolarisTMワークステーション
で動作する本発明の実施形態において、プロセッサにより実行される各プロセス
は、「スレッド」として構成される。ワークステーション上で実行する他のプロ
セスへのインパクトが最小となるように、スレッドは(例えば、割り込みレベル
ではなく)標準モードで実行するプロセスである。しかしながら、標準モードプ
ロセスは高い優先度で実行し得る。あるいは、スレッドは比較的低い割り込みレ
ベルにおいて実行し得る。
【0291】 入来するパケットを処理する原因となるスレッドは、処理するパケットが存在
しない場合にスレッド自身をブロックし得、すべき作業がある場合、呼び起こさ
れ得る。「状態変数」はスレッドが処理するパケットを有するかどうかを示すた
めに使用され得る。例示的に、スレッドがパケットを処理する場合(例えば、プ
ロセッサが処理するためのパケットを受け取る場合)、状態変数は第1の値に設
定され、処理するパケットがもはや存在しない場合、第2の値に設定される。本
発明の図示された実施形態において、ある状態変数は、各プロセッサのキューと
関連し得る。
【0292】 代替の実施形態において、示されるプロセッサは、「クロスプロセッサコール
」により状態716で警告される。クロスプロセッサコールは、プロセッサの間
の通信の1方法であり、これにより、あるプロセッサは他のプロセッサにより、
遠隔的に割り込まれる。あるプロセッサが他のプロセッサに警告するか、または
他のプロセッサへの処理をディスパッチする他の方法が、スレッドおよびクロス
プロセッサコールの代わりに使用され得る。
【0293】 状態718において、選択されたプロセッサ上のスレッドまたは他のプロセス
は、プロセッサのキューに格納されたパケットを処理し始める。パケットのプロ
トコルスタックを介してパケットを処理する方法は、当業者に公知であり、詳細
に記載する必要はない。次いで、図示されたプロシージャは終了状態720で終
了する。
【0294】 本発明の代替の1実施形態において、高速ネットワークインターフェースが、
ATM(非同期伝送モード)トラフィックを受け取るため、および処理するため
に構成される。この実施形態において、ロードディストリビュータがハードウェ
アモジュールとしてよりも、命令のセット(例えば、ソフトウェア)として実行
される。当業者が理解するように、ATMトラフィックは接続元であり、パケッ
トのソースエンティティと宛先エンティティとの間で構築される仮想回路に対応
する仮想接続識別子(VCI)により識別され得る。仮想回路部の一部である各
パケットはVCIをヘッダーに含む。
【0295】 利点として、VCIは比較的小さなサイズ(例えば、16ビット)を有する。
従って、この代替の実施形態においてパケットのVCIは、パケットのプロトコ
ルスタックを介してパケットを処理する負荷を分散させるか、または共有させる
目的のために、フローキーの代わりに使用され得る。例示的に、異なるVCIか
らのトラフィックは異なるプロセッサに送られるが、パケットの正しい順番を保
証するために、同様のVCIを有する全パケットが同様のプロセッサに送られる
。ATMパケットがネットワークインターフェースで受け取られる場合、VCI
はATMパケットのヘッダーから取り出され、ロードディストリビュータに提供
される。次いで、負荷分散に利用可能なプロセッサの数に対してVCIのモジュ
ールが計算される。次いで、図示された実施形態と同様に、パケットおよびその
関連プロセッサ番号がホストコンピュータに提供される。
【0296】 上記のように、本発明の本実施形態の負荷分散は、パケットのレイヤー3およ
び/またはレイヤー4のソースおよび宛先エンティティ識別子に基づき実行され
る。しかしながら、本発明の代替の実施形態において、負荷分散は、レイヤー2
のアドレスに基づいて行われ得る。この代替の実施形態において、同様のイーサ
ネット(登録商標)ソースおよび宛先アドレスを有するパケットは、例えば、単
一のプロセッサに送られる。
【0297】 しかしながら、当業者が認識するように、このことは結果として、プロセッサ
は、レイヤー3および/またはレイヤー4の識別子が使用される場合よりも非常
に多くのパケットを受け取る。例えば、多量のトラフィックが、ホストコンピュ
ータ近傍に位置する(ロジックセンスにある)ルータを介して受け取られる場合
、トラフィックが多数の異なるエンドユーザおよび/またはコンピュータである
場合でさえ、トラフィックの全てについてのソースイーサネット(登録商標)ア
ドレスはルータのアドレスであり得る。対照的にホストコンピュータが、エンド
ユーザ/コンピュータの全てと同じイーサネット(登録商標)上にある場合、レ
イヤー2ソースアドレスはより多くの多様性を示し、より効果的な負荷共有を可
能にする。
【0298】 ネットワークから受け取るパケットの処理を分散する他の方法は、本発明の範
囲を逸脱することなく図7に図示された実施形態と異なり得る。特に、当業者で
あれば、フローのパケットをプロセッサに割り当て、割り当てたパケットをプロ
セッサに送達する多くの代替プロシージャが使用され得ることを理解する。
【0299】 (パケットキューの1実施形態) 上述のように、パケットキュー116は、DMAエンジン120によってリア
センブルされ、ホストコンピュータシステムに伝送する前に、IPPモジュール
104から受け取られたパケットを格納する。図8は、本発明の1実施形態によ
るパケットキュー116を示す。
【0300】 例示的な実施形態において、パケットキュー116は、256のエントリまで
含むFIFO(先入れ先出し)キューとしてインプリメントされる。この実施形
態における各パケットキューエントリは、1つのパケットに加えてそのパケット
に関する種々の情報を格納する。例えば、エントリ800は、パケット部802
に加えてパケット状態部を含む。種々のサイズのパケットがパケットキュー11
6に格納されるので、パケット部802は、パケット部が適切な境界(例えばバ
イト、ワード、二重ワード)で終了するように、パケットを補充するためのフィ
ラー802aを含み得る。
【0301】 フィラー802aは、ランダムデータまたは特定のパターンを有するデータを
含み得る。フィラー802aは、フィラーデータのパターンによってまたはタグ
フィールドによって格納されたパケットと区別され得る。
【0302】 例示的に、パケット状態情報は、TCPチェックサム値804およびパケット
長806(例えば、パケット部802に格納されたパケットの長さ)を含む。パ
ケット長を格納することによって、そのパケットは容易に識別され、パケット部
802から容易に取り出され得る。パケット状態情報はまた、診断/状態情報8
08を含み得る。診断/状態情報808は、パケットが不正(例えば、エラーに
伴って不完全に受け取られたパケット)であることを示すフラグ、チェックサム
がパケットについて計算されたかどうかを示すインジケータ、チェックサムが特
定の値を有することを示すインジケータ、チェックサムが計算したパケット部に
対するオフセット等を含み得る。別のフラグまたは別のインジケータもまた、診
断、フィルタリング、または他の目的のために含まれ得る。本発明の1実施形態
において、(上述され、パケットを含むフローを識別するために用いられる)パ
ケットのフローキーおよび/またはフロー番号(例えば、フローデータベース1
10のパケットフローの対応するインデックス)が、診断/状態情報808に含
まれる。他の実施形態において、フィラー802aを識別子するか、または範囲
を定めるタグフィールドが、診断/状態情報808に含まれる。
【0303】 本発明の別の1実施形態において、上述のパケット状態情報のうちの任意また
は全てが、パケットキュー116ではなくて制御キュー118に格納される。
【0304】 本発明の例示的な実施形態において、パケットキュー116は、(例えばラン
ダムアクセスメモリとして)ハードウェアにインプリメントされる。この実施形
態において、チェックサム値804のサイズは、16ビットであり、チェックサ
ム発生器114によって格納され得る。パケット長806の大きさは、14ビッ
トであり、ヘッダーパーサ106によって格納され得る。最後に、診断/状態情
報808の一部が、IPPモジュール104、ヘッダーパーサ106、フローデ
ータベースマネージャ108、ロードディストリビュータ112、およびチェッ
クサム発生器114のうちの1つ以上によって格納され得る。
【0305】 図8のパケットキュー116は、2つのポインタでインデックス付けされる。
読み出しポインタ810は、そのキューから読み出されるべき次のエントリを識
別し、一方書き込みポインタ812は、次に受け取られるパケットおよび関連す
る情報が格納されるべきエントリを識別する。本発明の本実施形態において、エ
ントリのパケット部802に格納されたパケットは、そのデータがDMAエンジ
ン120によってリアセンブルされ、および/またはホストコンピュータシステ
ムに伝送される場合に、パケットキュー116から抽出される。
【0306】 (制御キューの1実施形態) 本発明の1実施形態において、制御キュー118は、NIC100が受け取っ
たパケットに関する制御情報および状態情報を格納する。この実施形態において
、制御キュー118は、プロトコルヘッダーのバッチ処理および/または複数の
関連するパケットからのデータのリアセンブリを可能にするために用いられる情
報を保持する。制御キューはまた、ホストコンピュータによって用いられる情報
またはホストコンピュータ(例えばNIC100用のデバイスドライバ)上で動
作する一連の命令を格納し得る。制御キュー118に格納された情報は、パケッ
トキュー116に格納された情報を補充するか、または複製し得る。
【0307】 図9は、本発明の1実施形態における制御キュー118を示す。例示的な制御
キューは、パケットキュー116に(例えば256のエントリまで)格納される
各パケットに対して1つのエントリを含む。本発明の1実施形態において、制御
キュー118の各エントリは、同じ番号を有するパケットキュー116のエント
リ(例えばパケット)に対応する。図9は、CPU番号902、No_Assi
st信号904、オペレーションコード906、ペイロードオフセット908、
ペイロードサイズ910、および他の状態情報912のような種々のフィールド
を有するエントリ900を示す。エントリはまた、他の状態情報または制御情報
(図9に図示せず)を含むことができる。本発明の別の実施形態における制御キ
ュー118のエントリは、異なる情報を含み得る。
【0308】 前セクションで述べたCPU(またはプロセッサ)番号902は、ホストコン
ピュータシステム上の複数のプロセッサのうちどのプロセッサがパケットのプロ
トコルヘッダーを処理すべきかを示す。例示的に、CPU番号902のサイズは
6ビットである。前セクションで述べたようにNo_Assist信号904も
また、パケットがヘッダーパーサ106によって構文解析され得る予め選択され
たプロトコルの任意のセットと互換性があるかどうか(例えばパケットがそのプ
ロトコルのセットに従ってフォーマットされたかどうか)を示す。No_Ass
ist信号904は1つのフラグ(例えば1ビット)を含み得る。本発明の1実
施形態において、No_Assist信号904の状態または値をフローデータ
ベースマネージャ108が用いて、パケットのデータがリアセンブル可能である
かどうか、および/またはそのヘッダーが関連するパケットのヘッダーで処理さ
れ得るかどうかが判定され得る。特に、FDBMは、どのオペレーションコード
をパケットに割り当てるかを決定する際にそのNo_Assist信号を用いる
ことができる。
【0309】 オペレーションコード906は、DMAエンジン120に情報を供給し、それ
によりパケットデータのリアセンブリを助ける。前セクションで述べたように、
オペレーションコードは、パケットがデータを含むかどうか、またはパケットデ
ータがリアセンブリに適切であるかどうかを示し得る。例示的に、オペレーショ
ンコード906のサイズは3ビットである。ペイロードオフセット908および
ペイロードサイズ910は、それぞれパケットのTCPペイロード(例えばTC
Pデータ)のオフセットおよびサイズに対応する。これらのフィールドの大きさ
は、それぞれ7ビットおよび14ビットである。
【0310】 例示的な実施形態において、他の状態情報912はパケットに関する診断およ
び/または状態情報を含む。状態情報912は、チェックサム計算の開始位置(
このサイズは7ビットであり得る)、レイヤー3(例えばIP)のプロトコルヘ
ッダーのオフセット(このサイズもまた7ビットであり得る)等を含み得る。状
態情報912はまた、パケットのサイズが第1の閾値を越える(例えばそのパケ
ットが1522バイトより大きい)かどうか、またはパケットのサイズが第2の
閾値を下まわる(例えばそのパケットが256バイト以下である)かどうかにつ
いてのインジケータを含み得る。この情報は、パケットデータをリアセンブルす
る際に有用であり得る。例示的に、これらのインジケータは1ビットのフラグを
含む。
【0311】 本発明の別の1実施形態において、状態情報912は、パケットのフローキー
および/またはフロー番号(例えばフローデータベース110におけるパケット
フローのインデックス)を含む。例えば、フローキーまたはフロー番号は、デバ
ッグまたは他の診断目的のために用いられ得る。本発明の1実施形態において、
パケットのフロー番号は、1つのフロー内の複数のパケットが識別され得るよう
に、状態情報912に格納され得る。次いで、このような関連するパケットはホ
ストコンピュータに集約的に伝送され得るか、および/またはホストコンピュー
タによって処理され得る。
【0312】 図9は、制御キュー118をインデックス付けするための、読み出しポインタ
および書き込みポインタを示す。読み出しポインタ914は、DMAエンジン1
20によって読み出されるエントリを示す。書き込みポインタ916は、パケッ
トキュー116に格納された次のパケットに関する情報を格納するエントリを示
す。
【0313】 本発明の別の実施形態において、第2の読み出しポインタ(図9に図示せず)
を制御キュー118のインデックス付けに用いることができる。後のセクション
で述べるように、パケットがホストコンピュータに伝送される場合に、制御キュ
ーのエントリから引き出された情報を検索して、関連するパケット(例えば伝送
されるパケットと同じフロー内のパケット)もまた伝送予定であるかどうかを判
定する。関連するパケットが伝送予定の場合、ホストコンピュータは、関連する
パケットからプロトコルヘッダーを集約的に処理できるように警告される。本発
明のこの別の実施形態において、関連するパケットは、状態情報912のフロー
番号(またはフローキー)を整合させることによって識別される。第2の読み出
しポインタは、制御キューにおいて先取りを行うために用いられ、それによりパ
ケットをフロー番号と整合させ得る。
【0314】 本発明の1実施形態において、CPU番号902は、ロードディストリビュー
タ112によって制御キューに格納され得、No_Assist信号904はヘ
ッダーパーサ106によって格納され得る。オペレーションコード906はフロ
ーデータベースマネージャ108によって格納され得、ペイロードオフセット9
08およびペイロードサイズ910は、ヘッダーパーサ106によって格納され
得る。他の状態情報の部分が、先のモジュールおよび/またはIPPモジュール
104およびチェックサム発生器144のような他のモジュールによって書き込
まれ得る。しかしながら、本発明の特定の1実施形態において、情報のこれらの
項目の多くが、IPPモジュール104またはいくらか調整する役目を果たす何
らかの他のモジュールによって格納される。
【0315】 (本発明の1つの実施形態における初期ランダムパケット廃棄) パケットが、ホストコンピュータに伝送され得る速度よりも高速に、ネットワ
ークからネットワークインターフェースに到着し得る。このような状況である場
合、ネットワークインターフェースは、1つ以上のパケットをドロップまたは廃
棄しなければならない。従って、本発明の1つの実施形態において、パケットを
ランダムに廃棄するシステムおよび方法が提供される。このセクションにおいて
説明するシステムおよび方法は、他の通信デバイス(ゲートウェイ、ルータ、ブ
リッジ、モデム等)にも適用可能である。
【0316】 当業者であれば認識するように、パケットがドロップされ得る1つの理由は、
ネットワークインターフェースは、自身がホストコンピュータへの伝送のために
格納し得るパケットの最大数を既に格納しているからである。詳細には、ホスト
コンピュータに伝送されるパケットを収容するキュー(例えば、(図1A中の)
パケットキュー116)は、別のパケットがネットワークから受け取られた場合
、完全にポピュレートされ得る。新規パケットまたはキュー中に既に格納された
パケットのいずれかが、ドロップされ得る。
【0317】 大部分のネットワークトラフィックのバースト特性の理由で、ネットワークイ
ンターフェースが混雑している場合、複数のパケットをドロップし得ることがし
ばしばある。また、いくつかのネットワークインターフェースにおいて、連続的
なパケットがドロップされた場合、1つの特定のネットワーク接続またはフロー
がパケットが高速で到着した事態の原因でなくとも、当該接続部またはフロー(
例えば、ドロップされたパケットを全て含む接続部またはフロー)にペナルティ
ーを科す(penalized)ことが可能である。ネットワーク接続またはフ
ローへのペナルティが余りにも重い場合、その接続部またはフロー中にトラフィ
ックを生成するネットワークエンティティは、「壊されたパイプ」に遭遇したと
考えて、それを壊し得る。当業者であれば認識するように、壊されたパイプが発
生するのは、ネットワークエンティティが、通信問題を接続困難であることを示
すものとして解釈した場合である。
【0318】 特定のネットワークトラフィック(例えば、TCPトラフィック)の場合、パ
ケットのドロップは、ネットワークエンティティのウィンドウ(例えば、ネット
ワークトラフィックが承認を待機する前に伝送するパケット数)が収縮するかま
たは非常に低い数字に再設定するフロー制御方法を開始し得る。従って、ネット
ワークインターフェースが受取りエンティティにおいてTCP通信路(comm
unicant)からパケットをドロップするたびに、その通信は、受け取り側
のエンティティとの自身の接続部を再同期しなければならない。通信路の1つま
たは一部が、エンティティにおいて受け取られたネットワークトラフィックの大
きなパーセンテージについて責任を負う場合、これらの通信路に、当該通信路が
責任を負うトラフィックの量に比例してペナルティを科すことが正しいように見
える。
【0319】 加えて、特定のパケットまたは特定の種類のパケットを廃棄することを防ぐこ
とが賢明である場合もあり得る。例えば、少量の制御パケットを廃棄することは
、ネットワークインターフェース中の混雑を軽減することには殆ど役に立たず、
それどころか、ネットワーク接続またはフローに対して大きなマイナスの影響を
与え得る。さらに、特定のプロトコルに付着するパケットについてネットワーク
インターフェースを最適化する場合、このようなパケットをドロップさせること
を回避する方がより効率的であり得る。さらに、特定の接続部、フローまたはア
プリケーションを優先順位付けすることもでき、その場合、優先順位が高いトラ
フィックほどドロップすべきではない。
【0320】 従って、本発明によるネットワークインターフェースの1つの実施形態におい
て、通信デバイスのパケットキューがフルであるかまたは特定の閾値レベルまで
満たされている場合にパケットをランダムに廃棄する方法を提供する。特定の種
類のパケット(例えば、特定のフロー接続部あるいはアプリケーションからのパ
ケット)を廃棄対象として選択するか、または、特定の種類のパケット(例えば
、制御パケット、特定のプロトコルあるいは1組のプロトコルに適合するパケッ
ト)を廃棄対象から除外することにより、このような方法にインテリジェンスを
付加することができる。
【0321】 提供される方法は、廃棄対象パケットを廃棄可能と考えられるパケットからラ
ンダムに選択する点において、ランダムである。ランダムに廃棄する方針の適用
は、複数の接続部またはフローの間にパケットをドロップすることにより影響を
分散することにより、壊されたパイプを回避するのに十分であり得る。加えて、
少数の伝送エンティティがネットワークインターフェースにおいて受け取られる
トラフィックの大部分に対して責任を負う場合、パケットをランダムにドロップ
すると、反則しているエンティティに相応のペナルティを科すことを確実にする
ことができる。以下に記載される本発明の別の実施形態は、ランダム性およびイ
ンテリジェンスの様々な組み合わせを提供し、これらの属性の1つは、1つ以上
の実施形態において省略可能である。
【0322】 図10は、本発明のこの実施形態においてパケットをランダムに廃棄するシス
テムおよび方法を示す。この実施形態において、パケットキュー1000は、サ
イズが16KBのハードウェアFIFO(例えば、先入れ先出し)キューである
。本発明の別の実施形態において、パケットキューは、それよりも小さいかある
いは大きく、または、ハードウェアまたはソフトウェアとしてインプリメントさ
れる別の種類のデータ構造(例えば、リスト、アレイ、表、ヒープ)を含み得る
【0323】 前セクションにおいて説明したパケットキュー116と同様に、パケットキュ
ー1000は、ネットワークからパケットを受け取り、これらのパケットを、ホ
ストコンピュータへの伝送対象として収容する。ネットワークから到着するパケ
ットは、ネットワークから高速で到着し、パケットキュー1000中に格納され
る前に、1つ以上のモジュール(例えば、ヘッダーパーサ106、フローデータ
ベースマネージャ108)によって処理または調査され得る。例えば、ネットワ
ークが1秒あたり1ギガビットのトラフィックを伝送することが可能な場合、1
組のプロトコル(例えば、イーサネット(登録商標)、IPおよびTCP)に適
合するパケットを、約1,480,000パケット/秒の速度で受け取ることが
できる。パケットは、パケットキュー1000に格納された後、ホストコンピュ
ータ内部のイベントおよび条件に部分的に依存する速度で、ホストコンピュータ
に伝送される。従って、ネットワークインターフェースは、ホストコンピュータ
へのパケット伝送速度を制御することはできない。
【0324】 図示の実施形態において、パケットキュー1000を、複数のゾーンまたは領
域に分割し、これらのゾーンまたは領域のうち任意のものは、重複するかまたは
共通の境界部分を共有し得る。パケットキュー1000は、任意の数の領域に分
割され得、本発明は、図10に示す3つの領域に限定されない。例示として、領
域0(参照符号1002で図示)は、0KB(例えば、キュー中に格納されてい
るパケットが無い状態)から8KB(例えば、キューが半分満たされている状態
)までのパケットキュー1000の一部を包含する。領域1(参照符号1004
で図示)は、8KB〜12KBのパケットキューの一部を包含する。領域2(参
照符号1006で図示)は、12KB〜16KBのパケットキューの残りの部分
を包含する。別の実施形態において、パケットキュー1000の一部のみについ
て、領域が分割され得る。例えば、上半分部分(例えば、8KBよりも上)のみ
が、1つ以上の領域に分割され得る。
【0325】 異なる領域の数およびサイズならびに領域間の境界の位置は、複数の要因に応
じて変化し得る。これらの要因としては、ネットワークインターフェースにおい
て受け取られる。パケットの種類(例えば、パケットの構成の基本となるプロト
コル)、パケットのサイズ、パケットの到着速度(例えば、予測速度、平均速度
、最高速度)、ホストコンピュータへのパケット伝送速度、パケットキューのサ
イズ等がある。例えば、本発明の別の実施形態において、パケットキュー100
0を5つの領域に分割する。第1の領域は0KB〜8KBに延在し、第2の領域
は8KB〜10KBに延在し、第3の領域は10KB〜12KBに延在し、第4
の領域は12KB〜14KBに延在し、最終領域は14KB〜16KBに延在す
る。
【0326】 本発明によるネットワークインターフェースが動作している間、トラフィック
インジケータ1008は、パケットキュー1000の空き状態を示す。トラフィ
ックインジケータ1008は、本発明の1つの実施形態において、読出しポイン
タ810および/または書込みポインタ812(図8に図示)を含む。現在説明
している実施形態において、パケットキュー1000は完全に分割されており、
トラフィックインジケータ1008は概して、パケットキューが分割される領域
の1つまたは分割境界部分に配置される。従って、ネットワークインターフェー
スの動作中、以下に説明するように、パケットキューの空き状態に応じて(例え
ば、トラフィックインジケータ1008によって識別される領域に応じて)、適
切なアクションが取られ得る。
【0327】 図10において、パケットがパケットキュー1000に到着すると、カウンタ
1010がインクリメントされる。図示の実施形態において、カウンタ1010
は、限られた範囲の値(例えば、0〜7)を連続的にサイクルする。本発明の1
つの実施形態において、新規パケットが受け取られるたびに、カウンタが1だけ
インクリメントされる。別の実施形態において、特定の「廃棄不可能な」パケッ
トが受け取られた場合、カウンタ1010はインクリメントされ得ない。廃棄不
可能なパケットを識別する様々な例示的基準について、以下に説明する。
【0328】 パケットキュー1000の1つ以上の領域について、関連付けられたプログラ
ム可能な確率インジケータは、トラフィックインジケータ1008がパケットキ
ュー中のトラフィックレベルが関連領域に達したことを示した場合にパケットが
ドロップされる確率を示す。従って、図示の実施形態において、確率インジケー
タ1012は、パケットキューの半分よりも多くが空である場合(例えば、トラ
フィックインジケータ1008が領域0内に配置されている場合)に、パケット
がドロップされる確率を示す。同様に、確率インジケータ1014および101
6は、トラフィックインジケータ1008が領域1および2をそれぞれ識別する
場合に新規パケットがドロップされる確率を特定する。
【0329】 図示の実施形態において、確率インジケータ1012、1014および101
6はそれぞれ、サブインジケータのセットまたはマスク(例えば、ビットまたは
フラグ)を含む。例示として、確率インジケータ中のサブインジケータ数は、カ
ウンタ値の範囲(この場合は8)にマッチングする。本発明の1つの実施形態に
おいて、各サブインジケータは、パケットがドロップされるか否かを示す2つの
値(例えば、0または1)の1つを有する。従って、確率インジケータのサブ要
素は、カウンタ1010の8つの可能な値に対応するよう、0〜7(例示として
、右から左)に番号付けされ得る。第1の値(例えば、1)を格納する確率イン
ジケータ中の各位置について、カウンタ1010の値が当該ビット数とマッチン
グする場合、パケットキュー1000から受け取られた次の廃棄可能なパケット
がドロップされる。上述したように、特定の種類のパケット(例えば、制御パケ
ット)はドロップ不可能である。例示として、廃棄可能なパケットの場合、カウ
ンタ1010のみがインクリメントされる。
【0330】 図10において、パケットキューが半分よりも多く空いている限り(例えば、
トラフィックインジケータ1008が領域0中にある限り)、確率インジケータ
1012(例えば、00000000)は、ドロップされるパケットは無いこと
を示す。パケットキュー中に少なくとも8KBが格納されている場合、確率イン
ジケータ1014(例えば、00000001)は、パケットが8個巡回するた
びに1つのパケットがドロップされることを示す。言い換えれば、トラフィック
インジケータ1008が領域1内に配置された場合、廃棄可能なパケットがドロ
ップされる確率は12.5%である。詳細には、カウンタ1010が0に等しい
場合、次の廃棄可能なパケットまたはパケットキュー中に既に格納されているパ
ケットが廃棄される。確率インジケータ1016(例えば、01010101)
は、他の廃棄可能なパケットもそれぞれ廃棄されることえを指定する。従って、
キューの3/4よりも多くが満たされている場合に廃棄可能なパケットがドロッ
プされる確率は50%である。例示として、パケットがドロップされると、カウ
ンタ1010は未だインクリメントされる。
【0331】 別の実施例として、パケットキューを5つの領域に分割する上述した別の実施
形態において、適切な確率インジケータは、領域0および1の場合に00000
000を、領域2の場合に00000001を、領域3の場合に0000010
1を、そして領域4の場合に01111111を含み得る。従って、この別の実
施形態において、領域1は、領域0への拡張子(extension)として扱
われる。さらに、パケットがドロップされる確率は、0%から87.5%へと広
がる。
【0332】 上述した1つの別の実施形態において、パケットキューの一部のみが、複数の
領域に分割される。この別の実施形態において、パケットがドロップされるデフ
ォルトの確率またはヌルの確率(例えば、00000000)は、未分割部分と
関連付けられ得る。例示として、これは、キュー中に格納されているトラフィッ
クのレベルが第1の閾値に達するまではパケットがドロップされないことを確実
にする。キュー全体が分割される実施形態においても、デフォルトの確率または
ヌルの確率が、0KBの閾値を包含または0KBの閾値に接する領域と関連付け
られ得る。
【0333】 本発明の目的のためにパケットキューを任意の数の領域に分割することが可能
であるのと同様に、確率インジケータは、任意のサイズまたは大きさのビットマ
スクを含み得、互いに等しいサイズまたは大きさでなくてもよい。さらに、確率
インジケータは本発明においてプログラム可能であり、これにより、ネットワー
クインターフェースの動作中にも確率インジケータを変更することが可能となる
【0334】 確率インジケータを基本としてパケットを廃棄する場合、廃棄プロセスにラン
ダム性が注入される。早期にランダムに廃棄する方針は、上述した壊されたパイ
プの問題を回避するには十分であり得る。詳細には、本発明の1つの実施形態に
おいて、全パケットを廃棄可能であると見なし、これにより、全パケットを、カ
ウンタ1010によってカウントし、ドロップ対象とする。しかし、上述したよ
うに、本発明の別の実施形態において、特定の種類のパケットを廃棄対象から除
外するプロセスにインテリジェンスを付加する。
【0335】 確率インジケータおよびカウンタは、単に、ネットワークインターフェース中
のパケットをランダムに廃棄することをイネーブルする1つのシステムを構成す
ること、が理解される。他のメカニズムも適切である。別の1つの実施形態にお
いて、カウンタおよび/または確率インジケータの代わりに乱数発生器を用いて
、ランダムな廃棄方針をイネーブルすることが可能である。例えば、乱数(例え
ば、M)が生成された場合、M番目のパケット(またはM番目毎のパケット)は
、当該番号が生成された後、ドロップされ得る。または、乱数は、パケットがド
ロップされる確率を指定し得る。従って、乱数は、特定の範囲の値または確率に
限定(例えばハッシュ)され得る。別の代替例として、乱数発生器を、複数の領
域またはパケットキュー中の閾値と連係して用いることもできる。この別の実施
形態において、プログラム可能な値(この実施形態ではNとして示す)を、領域
またはキュー閾値と関連付けることが可能である。次いで、トラフィックインジ
ケータがその閾値または領域に達した場合、別の閾値または境界に到達するまで
、N番目のパケット(またはN番目毎のパケット)がドロップされ得る。
【0336】 本発明のさらに別の実施形態において、パケットがドロップされる確率は、バ
イナリフラクションとして表され得る。バイナリフラクションは、一連のビット
からなり、この一連のビットにおいて、各ビットは、自身のより上位の隣接ビッ
トの大きさの半分を表す。例えば、本発明の1つの実施形態において、バイナリ
フラクションは、4桁を用い得る。左から右に向かって、これらのビットは、0
.5、0.25、0.125および0.0625をそれぞれ示し得る。従って、
1010のバイナリフラクションは、パケットがドロップする確率が62.5%
(例えば、50%+12.5%)であることを示すものとして解釈される。バイ
ナリフラクション中において用いられる状態(例えば、ビット)が多いほど、正
確度も増す。
【0337】 この別の実施形態の1つの実現例において、別のパケットカウンタが、各桁と
関連付けられる。左端ビット用のカウンタは、次のカウンタの速度の2倍でイン
クリメントされ、次のカウンタは、自身の次のカウンタの2倍速度でインクリメ
ントされるといった具合である。言い換えれば、最上位(例えば、左の)ビット
用のカウンタが0から1にインクリメントした場合、残りのカウンタは変化しな
い。最上位カウンタが1から0に再度インクリメントした場合、次のカウンタは
、0から1にインクリメントする。同様に、第3のビット用のカウンタは、第2
のカウンタが0に戻るまでは、0から1にインクリメントしない。以上をまとめ
ると、最上位ビット用のカウンタは、パケットが受け取られるたびに変化する(
すなわち、インクリメントされる)。次の最上位ビット用のカウンタは、インク
リメントされるまで、2つのパケットについて各値(すなわち、0または1)を
保持する。同様に、3番目の上位ビット用のカウンタは、インクリメントされる
まで4つのパケットについて各カウンタ値を保持し、最下位ビット用のカウンタ
は、インクリメントされるまで8つのパケットについて自身の値を保持する。
【0338】 パケットが受け取られるたびまたはカウンタがインクリメントされるたびに、
カウンタを、確率インジケータ(例えば、指定されたバイナリフラクション)と
比較する。1つの実施形態において、パケットがドロップされるか否かの判定は
、1に等しいフラクションのビットによる。例示として、各フラクションビット
が1に等しい場合において、対応するカウンタが1に等しく、より上位の任意の
ビット用のカウンタが0に等しい場合、ランダムなパケットがドロップされる。
従って、実施例のフラクション1010の場合、最上位ビットのカウンタが1に
等しくなるたびに、ランダムなパケットがドロップされる。加えて、第3のビッ
トが1に等しくなるたびおよび最初の2つのビットのカウンタが0に等しくなる
たびにも、ランダムなパケットがドロップされる。
【0339】 ネットワークにおいて受け取られたパケットをドロップする確率を特定および
実現(enforce)するための他の適切なメカニズムが、本発明の範囲を越
えることなく導出され得る。
【0340】 前述したように、ランダムに廃棄を行う方針にインテリジェンスを付加して,
特定の種類のパケットが廃棄される事態を回避することが可能である。前セクシ
ョンにおいて、ネットワークから受け取られたパケットを構文解析する方法につ
いて説明した。詳細には、本発明のこの実施形態において、ネットワークから受
け取られたパケットは構文解析され、その後、パケットキュー(例えば、パケッ
トキュー1000)中に配置される。構文解析プロシージャの間、パケットに関
する様々な情報が、少量ずつ収集され得る。この情報を用いて、ランダムな廃棄
方針にインテリジェンスを注入することが可能である。詳細には、パケットヘッ
ダーの1つ以上のフィールドのコピー、パケットの発信元エンティティまたは宛
先エンティティの識別、またはプロトコルの識別などが可能である。
【0341】 従って、本発明の様々な実施形態において、特定のパケットまたは種類のパケ
ットを、廃棄対象から免除することが可能である。図10に図示の実施形態にお
いて、例えば、制御パケットが免除される。当業者であれば理解するように、制
御パケットは、通信接続の確立、再確立または維持に必要な情報を含む場合が多
い。従って、制御パケットがドロップされると、制御パケットではないパケット
がドロップされる場合よりもより深刻かつ損害が大きくなり得る。加えて、制御
パケットは一般的にはデータを含まない場合が多いため、制御パケットをドロッ
プしても、パケットキュー中のごく僅かなスペースしか節約できない。
【0342】 パケットを免除するための他の多くの基準が可能である。例えば、前セクショ
ンで説明したプロシージャに従ってパケットを構文解析する場合、No_Ass
istフラグまたは信号をそのパケットと関連付けて、そのパケットが一連の予
め選択された通信プロトコルと適合するか否かを示すことが可能である。例示と
して、フラグが第1の値(例えば、1)に設定された場合または信号が生成(r
aised)された場合、そのパケットは不適合であり、ゆえに特定の処理強化
(例えば、パケットデータのリアセンブリ、パケットヘッダーのバッチ処理、付
加分散)に対して不適格であると見なされる。No_Assistフラグが第1
の値に設定されるパケットは予期されていないプロトコルまたは独自の形式に適
合するパケットであり得るため、このようなパケットはドロップさせないほうが
良い場合がある。例えば、ネットワークマネージャは、このようなパケット全て
の受け取りを確認して、構文解析プロシージャをさらなるプロトコルを構文解析
する能力で強化すべきか否かを判定することを欲し得る。
【0343】 No_Assistパケット(例えば、一連の選択されたプロトコルに適合し
ないパケット)を廃棄対象から免除する別の理由は、パケットをドロップさせる
ことに対する応答に関する。パケットのプロトコルは識別されないため、パケッ
トが無くなることに対するパケットのプロトコルの応答は未知であり得る。詳細
には、パケットの伝送者は、パケットのドロップに応答して(例えば、混雑制御
の一形態として)自身の伝送速度を降下させない場合、パケットをドロップさせ
ることにより得られる利点(benefit)は無くなる。
【0344】 本発明の別の実施形態において、パケットのフロー番号を用いて、特定のパケ
ットを免除することが可能である。前セクションにおいて説明したように、ネッ
トワークインターフェースは、フローデータベースおよびフローデータベースマ
ネージャを含み、これにより、ネットワークインターフェースによって受け取ら
れる複数の通信フローの記録を維持することが可能である。パケットを1つ以上
の特定のフローから廃棄される事態を回避できれば、効果的であり得る。免除さ
れるフローは、優先度の高いネットワークエンティティを含むフロー、特定のア
プリケーションを含むフロー等を含み得る。例えば、1個のパケットまたは数個
のパケットが無くなっても宛先エンティティに深刻な影響を与えず、パケットを
再伝送する必要さえ無いアニメーションまたはストリーミンググラフィックスア
プリケーションからパケットを廃棄する方が比較的損害が少ないと考えられ得る
。それとは対照的に、ファイル伝送接続部から数個のパケットがドロップされた
場合、その結果はより深刻であり得、パケットを再伝送する必要が出てくる確率
があり、その結果、伝送側エンティティのウィンドウは収縮し得、そのため、フ
ァイル伝送速度が低下し得る。
【0345】 本発明のさらに別の実施形態において、確率インジケータは、各ビットがネッ
トワークインターフェースを通じてセパレートな特定のフローに対応するビット
マスクを含み得る。詳細には、これらのビットは、前セクションにおいて説明し
たフローデータベースにおいて維持されるフローに対応し得る。
【0346】 このセクションにおいて、今まで説明してきた本発明の実施形態は、パケット
がパケットキューに到着した際にパケットを廃棄する工程を含むが、別の実施形
態において、パケットは、パケットキュー内から廃棄され得る。詳細には、パケ
ットキューがフルになる(例えば、トラフィックインジケータが所定の領域また
は閾値に達する)と、当該キューに既に格納されているパケットは、1つ以上の
確率インジケータに従ってランダムに廃棄され得る。図10に図示の実施形態に
おいて、例えば、トラフィックインジケータ1008が特定の閾値(例えば、領
域1と領域2との間の境界またはキューの終端部分)に達すると、関連する確率
インジケータに従って、1つ以上の領域においてパケットが廃棄され得る。この
ような確率インジケータは、図10に示すものよりも、異なる値を有する確率が
高い。
【0347】 本発明のこの実施形態において、パケットキューが分割される確率インジケー
タおよび/またはその詳細(specifications)(例えば、境界)
は、プログラム可能であり、ホストコンピュータ(例えば、デバイスドライバ)
上で動作するソフトウェアによって調節され得る。パケットを免除する基準もプ
ログラム可能である。従って、ネットワークインターフェースまたは他の通信デ
バイスにおいてパケットを廃棄する方法は、このようなデバイスが連続的に動作
している場合であっても、このセクションにおいて説明する実施形態に従って改
変可能である。パケットをランダムに廃棄し、かつ/またはパケットをインテリ
ジェントに廃棄するための基準を適用するための様々な他の実施形態および基準
が、当業者にとって明らかである。
【0348】 図11A〜11Bは、図10に示す実施形態と実質的の同様の本発明の実施形
態に従って、ネットワークインターフェースにおいてパケットをランダムに廃棄
する方針をインプリメントする1つの方法を示すフローチャートを含む。この実
施形態において、パケットキュー1000がまだフルでない間、パケットが受け
取られる。当業者であれば理解するように、この実施形態は、パケットを廃棄す
るか否かを判定する方法を提供する。パケットキュー1000がフルになった後
は、別のパケットが受け取られると、ネットワークインターフェースは概して、
直前に受け取られたパケットまたはキュー中に既に格納されているパケットのい
ずれかをドロップさせなければならない。この場合、ドロップ対象パケットのみ
が決定される。
【0349】 図11Aにおいて、状態1100は開始状態である。状態1100は、ネット
ワークインターフェース(およびパケットキュー1000)の初期設定を反映す
るか、または、パケットキューおよびランダムな廃棄方針に関する1つ以上のパ
ラメータまたは局面が変更される場所であるネットワークインターフェースのオ
ペレーションにおけるポイントを反映し得る。
【0350】 状態1102において、恐らくは境界(例えば、図10に示す8KBの境界お
よび12KBの境界)を特定することにより、パケットキュー1000において
1つ以上の領域を識別する。図10に示す領域は、同時に見ればパケットキュー
1000を完全に包含するが、本発明の別の実施形態における領域は、キューを
部分的に包含し得る。
【0351】 状態1104において、1つ以上の確率インジケータを割り当て、構成する。
図示の実施形態において、1つの確率インジケータに各領域を関連付ける。ある
いは、複数の領域を1つの確率インジケータと関連付けてもよい。さらには、1
つ以上の領域を1つの確率インジケータと明示的に関連付けることが不可能な場
合もあり、その場合、デフォルトの確率インジケータまたはヌルの確率インジケ
ータが取られ得る。上述したように、確率インジケータは、マルチビットマスク
の形態をとり得、これにより、マルチビットマスク中のビット数は、パケットカ
ウンタが保持し得る範囲の値を反映する。本発明の別の実施形態において、確率
インジケータは、乱数または閾値の形態をとり得、これらの値は、パケットを廃
棄すべきか否かの決断が必要な際にランダムに生成された数字の比較対象となる
【0352】 状態1106において、特定の種類のパケットを廃棄対象から外す場合、免除
されるパケットを識別するための基準が示される。免除され得るパケットとして
は、制御パケット、未知のプロトコルあるいは特定の公知のプロトコルに適合す
るパケット、特定のネットワーク接続あるいはフローに所属するパケットなどが
ある。本発明の1つの実施形態において、免除されるパケットは無い。
【0353】 状態1108において、パケットまたはトラフィックカウンタが初期設定され
る。上述したように、廃棄可能なパケットが格納対象としてパケットキュー10
00において受け取られた場合、恐らくは限定された範囲の値を通じて、カウン
タがインクリメントされ得る。限定された範囲のカウンタ値は、マスク形式の確
率インジケータ中のビット数に対応し得る。あるいは、カウンタは、より広範囲
にインクリメントされるようにも構成され得、その場合、カウンタ値をモジュラ
ス関数またはハッシュ関数を通じてフィルタリングし、その後、以下に説明する
ように確率インジケータと比較してもよい。
【0354】 状態1110において、ネットワークからパケットが受け取られ、1つ以上の
モジュール(例えば、ヘッダーパーサ、IPPモジュール)を通じて処理され、
その後、パケットは、パケットキュー1000に到着し得る。従って、状態11
10において、パケットは、パケットキューへ格納される準備ができている。1
つ以上のパケットがパケットキュー中に既に格納されており、トラフィックイン
ジケータ(例えば、ポインタまたはインデックス)は、(例えば、格納位置およ
び/またはキュー中の領域を用いて)キュー中に格納されているトラフィックの
レベルを識別し得る。
【0355】 状態1112において、受け取られたパケットが廃棄可能か否かが判定され得
る。例えば、ランダムな廃棄方針が特定のパケットを廃棄対象から免除すること
を実際に可能にする場合、状態1112において、受け取られたパケットがその
免除基準の1つ1つを満たすか否かが判定される。受け取られたパケットがその
免除基準の1つ1つを満たす場合、図示のプロシージャは状態1122に進む。
受け取られたパケットがその免除基準の1つ1つを満たさない場合、プロシージ
ャは状態1114に進む。
【0356】 状態1114において、パケットキュー1000のアクティブ領域を識別する
。詳細には、現在トラフィックでパケットキューがポピュレートされているパケ
ットキューの領域を判定する。キュー中に格納されるトラフィックのレベルは、
ホストコンピュータへの伝送対象としてキュー中に格納され待機しているパケッ
トの数およびサイズに依存する。伝送プロセスが遅いほど、キュー中でトラフィ
ックが到達し得るレベルも高くなる。キュー中に格納されているトラフィックの
レベルは、パケットの格納および伝送が行なわれる際に上下するが、このレベル
は、トラフィックインジケータを調査することにより所与の時期に識別され得る
。トラフィックインジケータは、キュー中の最後のパケットの位置または次に格
納されるパケットを識別するポインタを含み得る。このようなポインタは、ホス
トコンピュータに伝送される予定の次のパケットを識別する別のポインタと比較
され得、これにより、キュー中に格納されるトラフィック量を明らかにすること
ができる。
【0357】 状態1116において、カウンタ値(例えば、図10の実施形態における0〜
7の値)を、アクティブな領域と関連付けられた確率インジケータと比較する。
上述したように、廃棄可能なパケットがキューにおいて受け取られたときに、こ
のカウンタをインクリメントする。この比較は、受け取られたパケットを廃棄す
べきか否かを判定するために行なわれる。上記にて説明したように、図10の実
施形態において、カウンタ値に対応する確率インジケータビットの設定を調査す
る。例えば、カウンタの値がNである場合、確率インジケータマスクのビット数
Nを調査する。ビットが第1の状態(例えば、1)に設定されている場合、その
パケットを廃棄し、そうでない場合、そのパケットは廃棄しない。
【0358】 状態1118において、パケットを廃棄するか否かに関わらず、カウンタをイ
ンクリメントして、廃棄可能なパケットの受取りを反映する。本発明のここで説
明している実施形態において、カウンタがインクリメントされる前の時点で自身
の最大値(例えば、7)を含む場合、そのカウンタをインクリメントすると、そ
のカウンタは自身の最小値(例えば、0)に再設定される。
【0359】 状態1120において、パケットを廃棄する場合、図示のプロシージャは状態
1124に進む。パケットを廃棄しない場合、プロシージャは状態1122に進
む。状態1122において、そのパケットをパケットキュー1000中に格納し
、図示のプロシージャは終了状態1126と共に終了する。状態1124におい
て、パケットを廃棄し、図示のプロシージャは終了状態1126と共に終了する
【0360】 1999年3月1日に出願され、「A High Performance
Network Interface」と題する、米国特許出願第09/259
,765号は、本発明の本実施形態が為され得るネットワークインターフェース
のさらなる詳細を提供し、同出願は参考として本明細書中で援用される。
【0361】 Sun、Sun Microsystems、SPARCおよびSolari
sは、米国および他の国々にあるSun Microsystems,Inco
rporatedの商標または登録商標である。
【0362】 本発明の上記の実施形態の説明は、例示および説明目的のみのために提示され
ている。これらの説明は、完全なものとして意図されておらず、また開示されて
いる形態に本発明を限定するものとしても意図されていない。従って、上記の開
示内容は、本発明を限定するように意図されたものではなく、本発明の範囲は、
本明細書中の特許請求の範囲によって規定される。
【図面の簡単な説明】
【図1A】 図1Aは、本発明の実施形態に従う、ネットワークからパケットを受け取るた
めのネットワークインターフェース回路(NIC)を示すブロック図である。
【図1B】 図1Bは、本発明の実施形態に従う、ネットワークから受け取られたパケット
をホストコンピュータへ伝送するための図1AのNICを操作する1つの方法を
示すフローチャートである。
【図2】 図2は、ネットワークを介して伝送され、本発明の1実施形態におけるネット
ワークインターフェース回路で受け取られたパケットの図である。
【図3】 図3は、本発明の実施形態に従う、パケットを構文解析するためのネットワー
クインターフェース回路のヘッダーパーサを示すブロック図である。
【図4A】 図4Aは、本発明の実施形態に従う、ネットワークインターフェース回路でネ
ットワークから受け取ったパケットを構文解析する1つの方法を示すフローチャ
ートである。
【図4B】 図4Bは、本発明の実施形態に従う、ネットワークインターフェース回路でネ
ットワークから受け取ったパケットを構文解析する1つの方法を示すフローチャ
ートである。
【図5】 図5は、本発明の実施形態に従う、ネットワークインターフェース回路フロー
データベースを示すブロック図である。
【図6A】 図6Aは、本発明の実施形態に従う、ネットワークインターフェース回路フロ
ーデータベースを管理する1つの方法を示すフローチャートである。
【図6B】 図6Bは、本発明の実施形態に従う、ネットワークインターフェース回路フロ
ーデータベースを管理する1つの方法を示すフローチャートである。
【図6C】 図6Cは、本発明の実施形態に従う、ネットワークインターフェース回路フロ
ーデータベースを管理する1つの方法を示すフローチャートである。
【図6D】 図6Dは、本発明の実施形態に従う、ネットワークインターフェース回路フロ
ーデータベースを管理する1つの方法を示すフローチャートである。
【図6E】 図6Eは、本発明の実施形態に従う、ネットワークインターフェース回路フロ
ーデータベースを管理する1つの方法を示すフローチャートである。
【図7】 図7は、本発明の実施形態に従う、ホストコンピュータの複数のプロセッサ間
のネットワークパケットの処理を分散する1つの方法を示すフローチャートであ
る。
【図8】 図8は、本発明の実施形態に従う、ネットワークインターフェース回路に関す
るパケットキューの図である。
【図9】 図9は、本発明の実施形態に従う、ネットワークインターフェース回路に関す
る制御キューの図である。
【図10】 図10は、本発明の実施形態に従う、ネットワークインターフェースからパケ
ットをランダムに廃棄するシステムを示す図である。
【図11A】 図11Aは、本発明の実施形態に従う、ネットワークインターフェースからパ
ケットを廃棄する1方法を示すフローチャートである。
【図11B】 図11Bは、本発明の実施形態に従う、ネットワークインターフェースからパ
ケットを廃棄する1方法を示すフローチャートである。
【図12】 図12は、本発明の実施形態に従う、パケットを構文解析するための動的な命
令の1セットを示す図である。
【手続補正書】
【提出日】平成13年9月13日(2001.9.13)
【手続補正1】
【補正対象書類名】明細書
【補正対象項目名】0019
【補正方法】変更
【補正の内容】
【0019】 (詳細な説明) 以下の説明は、いかなる当業者でも本発明を生産および使用することができる
ように示され、本発明の特定の用途およびそれらの用途の要求のコンテクストで
提供される。開示される実施形態の種々の改変が当業者には容易に明らかであり
、本明細書中に規定される一般的原理は、他の実施形態および用途にも本発明の
範囲を逸脱することなく適用し得る。従って、本発明は、示される実施形態に限
定されることを意図するものではなく、本明細書中に開示される原理および特徴
に整合する最も広い範囲を与えられるべきである。
───────────────────────────────────────────────────── フロントページの続き (81)指定国 EP(AT,BE,CH,CY, DE,DK,ES,FI,FR,GB,GR,IE,I T,LU,MC,NL,PT,SE),OA(BF,BJ ,CF,CG,CI,CM,GA,GN,GW,ML, MR,NE,SN,TD,TG),AP(GH,GM,K E,LS,MW,SD,SL,SZ,TZ,UG,ZW ),EA(AM,AZ,BY,KG,KZ,MD,RU, TJ,TM),AE,AL,AM,AT,AU,AZ, BA,BB,BG,BR,BY,CA,CH,CN,C R,CU,CZ,DE,DK,DM,EE,ES,FI ,GB,GD,GE,GH,GM,HR,HU,ID, IL,IN,IS,JP,KE,KG,KP,KR,K Z,LC,LK,LR,LS,LT,LU,LV,MA ,MD,MG,MK,MN,MW,MX,NO,NZ, PL,PT,RO,RU,SD,SE,SG,SI,S K,SL,TJ,TM,TR,TT,TZ,UA,UG ,UZ,VN,YU,ZA,ZW (72)発明者 チェン, リンダ アメリカ合衆国 カリフォルニア 95129, サン ノゼ, バーケット ドライブ 1318 (72)発明者 ジェントリー, デントン アメリカ合衆国 カリフォルニア 94555, フレモント, シー クリフ テラス 34892 Fターム(参考) 5K030 HA08 KA01 KA02 LC18 MB09

Claims (42)

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

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/258,952 US6606301B1 (en) 1999-03-01 1999-03-01 Method and apparatus for early random discard of packets
US09/258,952 1999-03-01
PCT/US2000/005343 WO2000052882A2 (en) 1999-03-01 2000-02-29 Method and apparatus for early random discard of packets

Publications (1)

Publication Number Publication Date
JP2002538725A true JP2002538725A (ja) 2002-11-12

Family

ID=22982829

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000603198A Withdrawn JP2002538725A (ja) 1999-03-01 2000-02-29 初期のランダムなパケット廃棄方法および装置

Country Status (6)

Country Link
US (1) US6606301B1 (ja)
EP (1) EP1157502B1 (ja)
JP (1) JP2002538725A (ja)
AU (1) AU3508900A (ja)
DE (1) DE60021174D1 (ja)
WO (1) WO2000052882A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010514313A (ja) * 2006-12-19 2010-04-30 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワーク・フローを解析する装置および方法

Families Citing this family (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6434116B1 (en) * 1997-11-07 2002-08-13 Telcordia Technologies, Inc. Method and system for stabilized random early detection using connection sampling
JP2000332817A (ja) * 1999-05-18 2000-11-30 Fujitsu Ltd パケット処理装置
US7149664B1 (en) * 1999-06-02 2006-12-12 Nortel Networks Limited Method and apparatus for queue modeling
US7324442B1 (en) * 2000-02-28 2008-01-29 The Board Of Trustees Of The Leland Stanford Junior University Active queue management toward fair bandwidth allocation
US6741594B1 (en) * 2000-06-15 2004-05-25 Advanced Micro Devices, Inc. Arrangement for identifying data packet types from multiple protocol formats on a network switch port
US7366755B1 (en) * 2000-07-28 2008-04-29 International Business Machines Corporation Method and apparatus for affinity of users to application servers
US6904015B1 (en) * 2000-09-01 2005-06-07 Force10 Networks, Inc. Congestion avoidance profiles in a packet switching system
US20020107974A1 (en) * 2000-10-06 2002-08-08 Janoska Mark William Data traffic manager
US6856596B2 (en) * 2000-12-01 2005-02-15 Marconi Communications, Inc. Approximation of the weighted random early detection buffer admittance algorithm
US7512686B2 (en) * 2000-12-21 2009-03-31 Berg Mitchell T Method and system for establishing a data structure of a connection with a client
US7421505B2 (en) * 2000-12-21 2008-09-02 Noatak Software Llc Method and system for executing protocol stack instructions to form a packet for causing a computing device to perform an operation
US7546369B2 (en) * 2000-12-21 2009-06-09 Berg Mitchell T Method and system for communicating a request packet in response to a state
US7287090B1 (en) 2000-12-21 2007-10-23 Noatak Software, Llc Method and system for identifying a computing device in response to a request packet
US20020116605A1 (en) * 2000-12-21 2002-08-22 Berg Mitchell T. Method and system for initiating execution of software in response to a state
US7418522B2 (en) * 2000-12-21 2008-08-26 Noatak Software Llc Method and system for communicating an information packet through multiple networks
US20020116532A1 (en) * 2000-12-21 2002-08-22 Berg Mitchell T. Method and system for communicating an information packet and identifying a data structure
US20020116397A1 (en) 2000-12-21 2002-08-22 Berg Mitchell T. Method and system for communicating an information packet through multiple router devices
US20020124102A1 (en) * 2001-03-01 2002-09-05 International Business Machines Corporation Non-zero credit management to avoid message loss
US6996833B1 (en) * 2001-03-27 2006-02-07 Microsoft Corporation Protocol agnostic request response pattern
US20040260829A1 (en) * 2001-04-13 2004-12-23 Husak David J. Manipulating data streams in data stream processors
US20020165957A1 (en) * 2001-05-02 2002-11-07 Devoe Jiva Gandhara Intelligent dynamic route selection based on active probing of network operational characteristics
WO2002103966A1 (en) * 2001-06-15 2002-12-27 British Telecommunications Public Limited Company Communications network with congestion avoidance
US7068604B2 (en) * 2001-08-23 2006-06-27 International Business Machines Corporation Managing memory resident queues to control resources of the systems using the queues
DE50107065D1 (de) 2001-08-29 2005-09-15 Alcatel Sa Router
EP1313268B1 (de) 2001-08-29 2005-02-09 Alcatel Router
US7787370B1 (en) * 2001-09-06 2010-08-31 Nortel Networks Limited Technique for adaptively load balancing connections in multi-link trunks
US7359325B1 (en) * 2001-10-18 2008-04-15 Network Equipment Technologies, Inc. Method and apparatus for inserting empty memory cells into a data flow of network connections of a computer network
US7239612B1 (en) 2001-10-18 2007-07-03 Network Equipment Technologies, Inc Method and apparatus for discarding a prioritized fair share of traffic of network connections
US7283470B1 (en) 2002-01-25 2007-10-16 Juniper Networks, Inc. Systems and methods for dropping data using a drop profile
US7424496B1 (en) * 2002-03-20 2008-09-09 Applied Micro Circuits Corporation Asymmetric coherency protection
US20040044765A1 (en) * 2002-08-30 2004-03-04 Microsoft Corporation Method and system for identifying lossy links in a computer network
US7421510B2 (en) * 2002-08-30 2008-09-02 Microsoft Corporation Method and system for identifying lossy links in a computer network
US7346679B2 (en) * 2002-08-30 2008-03-18 Microsoft Corporation Method and system for identifying lossy links in a computer network
US7496035B1 (en) * 2003-01-31 2009-02-24 Cisco Technology, Inc. Methods and apparatus for defining flow types and instances thereof such as for identifying packets corresponding to instances of the flow types
US7400581B2 (en) * 2003-03-03 2008-07-15 Sun Microsystems, Inc. Load-balancing utilizing one or more threads of execution for implementing a protocol stack
US8543672B2 (en) * 2003-06-02 2013-09-24 Alcatel Lucent Method for reconfiguring a ring network, a network node, and a computer program product
US7573872B2 (en) * 2003-10-01 2009-08-11 Nortel Networks Limited Selective forwarding of damaged packets
FI114598B (fi) * 2003-10-17 2004-11-15 Tellabs Oy Menetelmä ja laitteisto palvelunlaadun säilyttävän vuonmuokkauksen tekemiseksi pakettikytkentäisessä tietoliikenteessä
US8717868B2 (en) * 2003-12-19 2014-05-06 Rockstar Consortium Us Lp Selective processing of damaged packets
JP3840480B2 (ja) * 2004-04-28 2006-11-01 松下電器産業株式会社 制御局装置及び基地局装置
US7953000B2 (en) * 2004-09-10 2011-05-31 Cisco Technology, Inc. Mechanism to improve preemption behavior of resource reservations
US8353003B2 (en) 2004-10-01 2013-01-08 Exelis Inc. System and method for controlling a flow of data a network interface controller to a host processor
RU2419226C2 (ru) * 2006-03-31 2011-05-20 Квэлкомм Инкорпорейтед Управление памятью для высокоскоростного управления доступом к среде
US8208474B2 (en) * 2006-07-31 2012-06-26 Samsung Electronics Co., Ltd Method and apparatus for transmitting/receiving packet in a mobile communication system
US7697519B2 (en) * 2006-10-31 2010-04-13 Hewlett-Packard Development Company, L.P. Packet processing
US7675918B2 (en) 2006-11-13 2010-03-09 Cisco Technology, Inc Hash-based preemption
US8127113B1 (en) 2006-12-01 2012-02-28 Synopsys, Inc. Generating hardware accelerators and processor offloads
US8706987B1 (en) 2006-12-01 2014-04-22 Synopsys, Inc. Structured block transfer module, system architecture, and method for transferring
US8289966B1 (en) * 2006-12-01 2012-10-16 Synopsys, Inc. Packet ingress/egress block and system and method for receiving, transmitting, and managing packetized data
US7724684B2 (en) * 2007-05-24 2010-05-25 Modelware, Inc. System and method for designing and implementing packet processing products
KR101421054B1 (ko) * 2007-08-06 2014-07-18 삼성전자주식회사 버퍼를 이용한 연산 분산 방법 및 이를 이용한 연산 분산시스템
JP2009239435A (ja) * 2008-03-26 2009-10-15 Oki Semiconductor Co Ltd パケット中継装置
US8345680B2 (en) * 2009-05-07 2013-01-01 Alcatel Lucent Handling out-of-sequence packets in a circuit emulation service
US8429291B2 (en) 2009-11-18 2013-04-23 Cisco Technology, Inc. Protection of network flows during congestion in a communications network
US8867529B2 (en) 2010-09-20 2014-10-21 Cisco Technology, Inc. System and method for providing a fate sharing identifier in a network environment
US8824290B2 (en) * 2011-01-07 2014-09-02 Qualcomm Incorporated Downlink flow control using packet dropping to control transmission control protocol (TCP) layer throughput
US9071499B2 (en) * 2011-03-28 2015-06-30 Citrix Systems, Inc. Systems and methods for emulating a NIC for packet transmission on hardware RSS unaware NICs in a multi-core system
US9445363B2 (en) * 2012-02-15 2016-09-13 Acer Incorporated Method of handling transmission configuration of a communication device and related communication device
US9331915B1 (en) * 2013-01-25 2016-05-03 Amazon Technologies, Inc. Dynamic network traffic mirroring
CN103560923B (zh) * 2013-11-20 2016-08-17 烽火通信科技股份有限公司 分组传送网的网络故障快速定位方法
CN104717152B (zh) * 2013-12-17 2019-07-19 深圳市中兴微电子技术有限公司 一种实现接口缓存动态分配的方法和装置
US9825884B2 (en) 2013-12-30 2017-11-21 Cavium, Inc. Protocol independent programmable switch (PIPS) software defined data center networks
US10050833B2 (en) 2014-06-19 2018-08-14 Cavium, Inc. Method of reducing latency in a flexible parser and an apparatus thereof
US9628385B2 (en) 2014-06-19 2017-04-18 Cavium, Inc. Method of identifying internal destinations of networks packets and an apparatus thereof
US9531849B2 (en) * 2014-06-19 2016-12-27 Cavium, Inc. Method of splitting a packet into individual layers for modification and intelligently stitching layers back together after modification and an apparatus thereof
US9635146B2 (en) 2014-06-19 2017-04-25 Cavium, Inc. Method of using bit vectors to allow expansion and collapse of header layers within packets for enabling flexible modifications and an apparatus thereof
US9742694B2 (en) 2014-06-19 2017-08-22 Cavium, Inc. Method of dynamically renumbering ports and an apparatus thereof
US9961167B2 (en) 2014-06-19 2018-05-01 Cavium, Inc. Method of modifying packets to a generic format for enabling programmable modifications and an apparatus thereof
US10616380B2 (en) 2014-06-19 2020-04-07 Cavium, Llc Method of handling large protocol layers for configurable extraction of layer information and an apparatus thereof
US9606781B2 (en) 2014-11-14 2017-03-28 Cavium, Inc. Parser engine programming tool for programmable network devices
US10439952B1 (en) * 2016-07-07 2019-10-08 Cisco Technology, Inc. Providing source fairness on congested queues using random noise
US10089339B2 (en) * 2016-07-18 2018-10-02 Arm Limited Datagram reassembly
US10069745B2 (en) * 2016-09-12 2018-09-04 Hewlett Packard Enterprise Development Lp Lossy fabric transmitting device
US11082540B2 (en) * 2018-11-05 2021-08-03 Cisco Technology, Inc. Network operations including protocol processing of a packet updating an operations data field of a different protocol
US10785098B1 (en) * 2019-04-30 2020-09-22 Alibaba Group Holding Limited Network configuration using multicast address modulation

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5128926A (en) 1990-03-21 1992-07-07 Digital Equipment Corporation Updating link state information in networks
US5231633A (en) * 1990-07-11 1993-07-27 Codex Corporation Method for prioritizing, selectively discarding, and multiplexing differing traffic type fast packets
JP3241716B2 (ja) * 1990-08-31 2001-12-25 株式会社東芝 Atm交換方法
FR2686755A1 (fr) 1992-01-28 1993-07-30 Electricite De France Procede de chiffrement de messages transmis entre reseaux interconnectes, appareil de chiffrement et dispositif de communication de donnees chiffrees mettant en óoeuvre un tel procede.
GB2268372B (en) 1992-06-11 1995-11-01 Roke Manor Research Improvements in or relating to data transmission systems
EP0594196B1 (en) 1992-10-22 1999-03-31 Cabletron Systems, Inc. Address lookup in packet data communications link, using hashing and content-addressable memory
DE69321145T2 (de) 1993-03-20 1999-06-02 Ibm Verfahren und vorrichtung zur herausarbeitung der vermittlungsinformation aus dem kopfteil eines protokolls
WO1995014269A1 (en) 1993-11-19 1995-05-26 The Trustees Of The University Of Pennsylvania A high-performance host interface for networks carrying connectionless traffic
JP3162975B2 (ja) * 1995-10-16 2001-05-08 株式会社日立製作所 廃棄優先制御管理方式によるatm交換機
US5758089A (en) 1995-11-02 1998-05-26 Sun Microsystems, Inc. Method and apparatus for burst transferring ATM packet header and data to a host computer system
US5778180A (en) 1995-11-06 1998-07-07 Sun Microsystems, Inc. Mechanism for reducing data copying overhead in protected memory operating systems
US5793954A (en) 1995-12-20 1998-08-11 Nb Networks System and method for general purpose network analysis
CA2243359A1 (en) 1996-01-31 1997-08-07 Ipsilon Networks, Inc. Improved method and apparatus for dynamically shifting between routing and switching packets in a transmission network
US5787255A (en) 1996-04-12 1998-07-28 Cisco Systems, Inc. Internetworking device with enhanced protocol translation circuit
US5778414A (en) 1996-06-13 1998-07-07 Racal-Datacom, Inc. Performance enhancing memory interleaver for data frame processing
US5870394A (en) 1996-07-23 1999-02-09 Northern Telecom Limited Method and apparatus for reassembly of data packets into messages in an asynchronous transfer mode communications system
US5748905A (en) 1996-08-30 1998-05-05 Fujitsu Network Communications, Inc. Frame classification using classification keys
US6011803A (en) 1997-01-13 2000-01-04 Lucent Technologies Inc. Distributed-protocol server
US6092115A (en) * 1997-02-07 2000-07-18 Lucent Technologies Inc. Method for supporting per-connection queuing for feedback-controlled traffic
US6470389B1 (en) 1997-03-14 2002-10-22 Lucent Technologies Inc. Hosting a network service on a cluster of servers using a single-address image
US6088356A (en) 1997-06-30 2000-07-11 Sun Microsystems, Inc. System and method for a multi-layer network element
US6128666A (en) 1997-06-30 2000-10-03 Sun Microsystems, Inc. Distributed VLAN mechanism for packet field replacement in a multi-layered switched network element using a control field/signal for indicating modification of a packet with a database search engine
US6094435A (en) 1997-06-30 2000-07-25 Sun Microsystems, Inc. System and method for a quality of service in a multi-layer network element
US6115378A (en) 1997-06-30 2000-09-05 Sun Microsystems, Inc. Multi-layer distributed network element
US6363069B1 (en) * 1998-06-30 2002-03-26 At&T Corp. Complete packet discarding
US6333917B1 (en) * 1998-08-19 2001-12-25 Nortel Networks Limited Method and apparatus for red (random early detection) and enhancements.
US6167445A (en) * 1998-10-26 2000-12-26 Cisco Technology, Inc. Method and apparatus for defining and implementing high-level quality of service policies in computer networks

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010514313A (ja) * 2006-12-19 2010-04-30 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワーク・フローを解析する装置および方法
US8861397B2 (en) 2006-12-19 2014-10-14 International Business Machines Corporation Apparatus and method for analyzing a network

Also Published As

Publication number Publication date
EP1157502A2 (en) 2001-11-28
WO2000052882A2 (en) 2000-09-08
US6606301B1 (en) 2003-08-12
DE60021174D1 (de) 2005-08-11
EP1157502B1 (en) 2005-07-06
AU3508900A (en) 2000-09-21
WO2000052882A3 (en) 2001-01-04

Similar Documents

Publication Publication Date Title
JP2002538725A (ja) 初期のランダムなパケット廃棄方法および装置
JP2002538733A (ja) 高性能ネットワークインターフェース
US6483804B1 (en) Method and apparatus for dynamic packet batching with a high performance network interface
JP2002538730A (ja) 高性能ネットワークインターフェースにおけるネットワークフローを管理する方法および装置
JP2002538724A (ja) マルチプロセッサコンピュータでネットワークトラフィック処理を分散する方法および装置
US6356951B1 (en) System for parsing a packet for conformity with a predetermined protocol using mask and comparison values included in a parsing instruction
US6480489B1 (en) Method and apparatus for data re-assembly with a high performance network interface
EP1754349B1 (en) Hardware filtering support for denial-of-service attacks
US9485178B2 (en) Packet coalescing
US7787442B2 (en) Communication statistic information collection apparatus
JP2002538721A (ja) 高性能ネットワークインターフェースにおけるネットワークトラフィックを分類するための方法および装置

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20070501