(57)【要約】【課題】高ネットワーク通信速度を扱うためのコンパクトなハードウェア解を備え、モジュールの構築および設計を介して複数の通信プロトコルを適合させるギガビット・イーサネット・アダプタを提供すること。【解決手段】ギガビット・イーサネット・アダプタが、低メモリ要請しか持たず、かつ、高度に効率的なプロトコルデコードを供給する、低価格で、低電力で、容易に製造可能で、小フォーム・ファクタのネットワーク・アクセス・モジュールを提供する。本発明は、複数のネットワーク・プロトコルを同時にバイト・ストリーム態様でデコードもし、また、パケット・データを1つのパスで処理もし、それによって、システム・メモリおよびフォーム・ファクタの要求条件を減少させ、また、ソフトウェアCPUオーバーヘッドを排除する、ハードウェア統合システムを有する。本発明の好適な1実施例は、TCP, IP, ユーザデータグラムプロトコル(UDP), PPP, ローソケット, RARP, ICMP, IGMP, Iscsi, RDMA, FCIPのようなネットワーク・プロトコルを、各バイトが受信されたときに同時にデコードする、複数のプロトコル・ステートマシンを有している。各プロトコル・ハンドラは、中間メモリを要求せずに、パケットからヘッダー情報を直接に構文解析し、インタプリトし、剥ぎ取る。本発明は、インターネット・チューナ・コア、周辺装置、および、外部インターフェイスを提供する。ネットワーク・スタックは、ネットワーク・パケットを処理し、生成し、受信する。プログラム可能な内部プロセッサは、ネットワーク・スタックを制御し、任意の他のタイプのICMPパケット、IGMPパケット、あるいは、専用ハードウェアによって直接サポートされていない他のプロトコルに対応するパケットをハンドルする。バーチャル・メモリ・マネージャが、最適化されたハード・ワイヤード・ロジックにインプリメントされる。そのバーチャル・メモリ・マネージャは、利用可能な内部メモリ量および外部メモリ量によってしか制限されないバーチャル・ナンバのネットワーク・コネクションの使用を可能にする。
2005502225.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク・プロトコルをデコードおよびエンコードして、データを処理するための装置であって、
パケットを受信および送信し、また、パケットをエンコードおよびデコードするためのネットワーク・スタックと、
複数の専用ハード・ワイヤード・ロジック・プロトコル・モジュールと、を有する装置において、
各プロトコル・モジュールが、特定のネットワーク・プロトコルに対して最適化されており、そして、
当該プロトコル・モジュールが、並列実行を行う装置。
【請求項２】
請求項1に記載の装置において、
プログラム可能な内部プロセッサをさらに有する装置であって、
当該内部プロセッサが、当該ネットワーク・スタックを制御する装置。
【請求項３】
専用ハードウェアによって直接サポートされていない他のプロトコルに対応する他のタイプのパケットが、当該内部プロセッサによって処理される、請求項2に記載の装置。
【請求項４】
当該プロトコル・モジュールに、TCPプロトコル・モジュールが含まれている、請求項1に記載の装置。
【請求項５】
当該TCPモジュールが、TCPネットワーク・トラフィックおよびUDPネットワーク・トラフィックを処理する、請求項4に記載の装置。
【請求項６】
当該TCPモジュールが、メモリ管理ハードウェアを用いることによってバーチャル・ナンバのコネクションをサポートする、請求項4に記載の装置。
【請求項７】
当該TCPモジュールが、内部プロセッサまたは専用ハード・ワイヤード・ロジックのいずれかを用いて、アウト・オブ・オーダ・パケットの再アセンブリをサポートする、請求項4に記載の装置。
【請求項８】
当該TCPモジュールが、専用の最適化されたハード・ワイヤード・ロジックを用いて、周回シーケンス番号に対するTCP保護(PAWS)をサポートする、請求項4に記載の装置。
【請求項９】
当該TCPモジュールが、専用の最適化されたハード・ワイヤード・ロジックを用いて、TCPキープ・アライブ・タイマをサポートする、請求項4に記載の装置。
【請求項１０】
当該TCPモジュールが、TCPスロー・スタート・アルゴリズムをサポートしている、請求項4に記載の装置。
【請求項１１】
当該TCPモジュールが、TCP高速再送アルゴリズムおよび高速回復アルゴリズムをサポートしている、請求項4に記載の装置。
【請求項１２】
当該TCPモジュールが、内部プロセッサまたは専用ハード・ワイヤード・ロジックのいずれかを用いて、TCP Nagleアルゴリズムをサポートしている、請求項4に記載の装置。
【請求項１３】
当該TCPモジュールが、TCP選択確認応答(SACK)オプションをサポートしている、請求項4に記載の装置。
【請求項１４】
当該TCPモジュールが、パケット往復遅延時間(round-trip time)を測定する、請求項4に記載の装置。
【請求項１５】
当該TCPモジュールが、輻輳回避アルゴリズムを遂行する、請求項4に記載の装置。
【請求項１６】
当該TCPモジュールが、専用の最適化されたハード・ワイヤード・ロジックを用いて、TCPスケーリング・ウィンドウをサポートする、請求項4に記載の装置。
【請求項１７】
当該TCPモジュールが、専用の最適化されたハード・ワイヤード・ロジックを用いて、最大セグメントサイズ(MSS)探索をサポートする、請求項4に記載の装置。
【請求項１８】
当該TCPモジュールが、専用の最適化されたハード・ワイヤード・ロジックを用いて、タイム−ウェイト  アセシネーション(time-wait assassination)をサポートする、請求項4に記載の装置。
【請求項１９】
当該TCPモジュールが、専用の最適化されたハード・ワイヤード・ロジックを用いて、ポート・フォワーディングをサポートする、請求項4に記載の装置。
【請求項２０】
請求項1に記載の装置において、
IPルータ・モジュールをさらに有する装置であって、
当該IPルータ・モジュールが、
ネットワーク・アドレス中継のためのハードウェアを含むデフォルトIP経路制御能力と、
複数のホストIPアドレスに対する経路制御と、
ホスト指定経路およびネットワーク指定経路に対する経路制御と、
ICMPリダイレクト・パケット・メッセージ受信後の経路制御情報の動的な更新と、
リミテッド・ブロードキャスト、サブネット・ディレクテッド・ブロードキャストおよびネットワーク・ディレクテッド・ブロードキャストを含むが、それらに制限されないIPブロードキャスト・アドレスを伴う経路制御と、
ループ・バックIPアドレスを伴う経路制御と、
IPマルチ・キャスト・アドレスを伴う経路制御と、のうちの任意の1つ以上を遂行する装置。
【請求項２１】
当該プロトコル・モジュールが、IPプロトコル・モジュールを具備し、そして、当該IPモジュールが、IPネットワーク・パケットを処理し、生成し、応える、請求項1に記載の装置。
【請求項２２】
当該IPモジュールが、IPネットワーク・パケットを再構築するための専用の最適化されたハード・ワイヤード・ロジックを有する、請求項21に記載の装置。
【請求項２３】
当該プロトコル・モジュールが、ICMPネットワーク・メッセージまたはIGMPネットワーク・メッセージを処理し、生成し、応えるための専用の最適化されたハード・ワイヤード・ロジックを有するICMPモジュールを具備する、請求項1に記載の装置。
【請求項２４】
当該プロトコル・モジュールが、一定のICMP機能またはIGMP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムできる最適化されたハード・ワイヤード・ロジックから成るICMPモジュールを具備する、請求項1に記載の装置。
【請求項２５】
専用の最適化されたハード・ワイヤード・ロジックを用いて、真のランダム分布を持つIPパケットの識別フィールドを生成し、そして、前記識別フィールドの将来値を予測する試みを防止するIP識別ジェネレータ・モジュールをさらに有する、請求項1に記載の装置。
【請求項２６】
当該プロトコル・モジュールが、バーチャル・ナンバのネットワーク・コネクションの使用を可能にするバーチャル・ソケット・モジュールを具備する、請求項1に記載の装置。
【請求項２７】
当該プロトコル・モジュールが、受信状態ハンドラ・モジュールを具備し、当該受信状態ハンドラ・モジュールが、自動的にTCPネットワーク・パケットに応える請求項1に記載の装置であって、
リセット(RST)パケットの生成と、
確認応答パケットとの同期(SYN/ACK)の生成と、
確認応答パケット(ACK)の生成と、
同期パケット(SYN)の生成と、
終了パケット(FIN)の生成と、
終了／確認応答パケット(FIN/ACK)の生成と、
リセット／確認応答パケット(RST/ACK)の生成と、のうちの任意の1つ以上を含む装置。
【請求項２８】
当該プロトコル・モジュールが、ARPプロトコル・モジュールを具備し、そして、当該ARPモジュールが、ネットワークARP応答を生成することによって、ネットワークARP要求に応える、請求項1に記載の装置。
【請求項２９】
当該ARPモジュールが、
ハードウェアARPアドレス・キャッシュと組み合ったARP要求と、
複数のIPアドレスに対するARP要求と、
ユニキャストARP要求と、
gratuitous ARP要求と、のうちの任意の1つ以上を生成する、請求項28に記載の装置。
【請求項３０】
当該ARPモジュールが、一定のARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項28に記載の装置。
【請求項３１】
当該ARPモジュールが、優先順位を変化できるようにプログラムされている、請求項28に記載の装置。
【請求項３２】
最適化されたハード・ワイヤード・ロジックを用いて構築されたARPアドレスのためのキャッシュをさらに有する、請求項28に記載の装置であって、
当該ARPキャッシュが、専用ハードウェアによって制御される、動的に分類されるテーブルを用い、
当該ARPキャッシュが、ARPプロキシとして働く能力をサポートし、そして、
当該ARPキャッシュが、専用ハード・ワイヤード・ロジックを用いて、ARPキャッシュ・エントリの満了時間を制御する、装置。
【請求項３３】
当該プロトコル・モジュールが、RARPプロトコル・モジュールを具備し、そして、当該RARPモジュールが、IPアドレスを要求するか、または、供給することができる、請求項1に記載の装置。
【請求項３４】
当該RARPモジュールが、一定のRARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項33に記載の装置。
【請求項３５】
ハード・ワイヤード・バーチャル・メモリ管理を可能にするメモリ構造をさらに有する、請求項1に記載の装置であって、
当該メモリ構造が、
各々が自らの目的に対して最適化された、様々に分類された制御ブロックのセットと、
各制御ブロックに記憶されたポインタを用いて、制御ブロックをリンクするメカニズムと、を有する装置。
【請求項３６】
当該ハード・ワイヤード・バーチャル・メモリ管理が、制御ブロックを割り付け、制御ブロックを更新し、そして、制御ブロックの割り付けを解放する、請求項35に記載の装置。
【請求項３７】
プログラム可能な優先順位にしたがって送信するためにパケットをスケジュール化する優先順位キューをさらに有する、請求項1に記載の装置。
【請求項３８】
ネットワーク・パケットが処理されるべき優先順位を計算して、割り当てるシーケンサをさらに有する、請求項1に記載の装置。
【請求項３９】
ネットワーク・サービス不能攻撃から保護するように、各ネットワーク・コネクションの状態についてのネットワーク情報を記憶するメモリ・アーキテクチャをさらに有する、請求項1に記載の装置。
【請求項４０】
当該ネットワーク・スタックが、TCPパケットおよびIPパケットを処理し、生成し、受信し、そして、当該ネットワーク・スタックが、一定のIPパケット処理機能またはTCPパケット処理機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項1に記載の装置。
【請求項４１】
当該ネットワーク・スタックが、iSCSIまたはRDMAのような、より上位レベルのプロトコルをカプセル化するIPパケットを処理し、生成し、受信する、請求項1に記載の装置。
【請求項４２】
ハード・ワイヤード・ロジック中にインプリメントされたバーチャル・メモリ・マネージャをさらに有する、請求項1に記載の装置。
【請求項４３】
当該バーチャル・メモリ・マネージャが、バーチャル・ナンバのネットワーク・コネクションの使用を可能にし、そして、当該ネットワーク・コネクションのバーチャル・ナンバが、利用可能な内部メモリ量または外部メモリ量によってしか制限されない、請求項42に記載の装置。
【請求項４４】
当該バーチャル・メモリ・マネージャが、ハード・ワイヤード・ロッキング・メカニズムを用いて、メモリ位置間の干渉を防止する、請求項42に記載の装置。
【請求項４５】
当該バーチャル・メモリ・マネージャが、一続きのメモリ構造を用いて、メモリにネットワーク・コネクション情報を記憶する、請求項42に記載の装置。
【請求項４６】
当該バーチャル・メモリ・マネージャが、専用ハード・ワイヤード回路を用いて、リンクリストまたは一続きのメモリ構造にエントリの探索、更新、挿入、削除を行う、請求項42に記載の装置。
【請求項４７】
当該バーチャル・メモリ・マネージャが、いくつかの相異なるタイプの制御ブロックを用いて、ネットワーク・コネクション情報を、前記ネットワーク・コネクションの状態に依存して記憶する、請求項42に記載の装置。
【請求項４８】
ネットワーク・プロトコルをデコードおよびエンコードして、データを処理するためのプロセスであって、
パケットを受信および送信し、また、パケットをデコードおよびエンコードするためのネットワーク・スタックを備える過程と、
複数の専用プロトコル・ステートマシンを備える過程と、を有するプロセスにおいて、
各プロトコル・ステートマシンが、特定のネットワーク・プロトコルに対して最適化されており、そして、
当該プロトコル・ステートマシンが、並列実行を行うプロセス。
【請求項４９】
請求項48に記載のプロセスにおいて、
プログラム可能な内部プロセッサを備える過程をさらに有するプロセスであって、
当該内部プロセッサが、当該ネットワーク・スタックを制御するプロセス。
【請求項５０】
専用ハードウェアによって直接サポートされていない他のプロトコルに対応する他のタイプのパケットが、当該内部プロセッサによって処理される、請求項49に記載のプロセス。
【請求項５１】
当該プロトコル・ステートマシンに、TCPプロトコル・ステートマシンが含まれている、請求項48に記載のプロセス。
【請求項５２】
当該TCPステートマシンが、TCPネットワーク・トラフィックおよびUDPネットワーク・トラフィックを処理する、請求項51に記載のプロセス。
【請求項５３】
当該TCPステートマシンが、メモリ管理ハードウェアを用いることによってバーチャル・ナンバのコネクションをサポートする、請求項51に記載のプロセス。
【請求項５４】
当該TCPステートマシンが、内部プロセッサまたは専用ハード・ワイヤード・ロジックのいずれかを用いて、アウト・オブ・オーダ・パケットの再アセンブリをサポートする、請求項51に記載のプロセス。
【請求項５５】
当該TCPステートマシンが、専用の最適化されたハード・ワイヤード・ロジックを用いて、周回シーケンス番号に対するTCP保護(PAWS)をサポートする、請求項51に記載のプロセス。
【請求項５６】
当該TCPステートマシンが、専用の最適化されたハード・ワイヤード・ロジックを用いて、TCPキープ・アライブ・タイマをサポートする、請求項51に記載のプロセス。
【請求項５７】
当該TCPステートマシンが、TCPスロー・スタート・アルゴリズムをサポートしている、請求項51に記載のプロセス。
【請求項５８】
当該TCPステートマシンが、TCP高速再送アルゴリズムおよび高速回復アルゴリズムをサポートしている、請求項51に記載のプロセス。
【請求項５９】
当該TCPステートマシンが、内部プロセッサまたは専用ハード・ワイヤード・ロジックのいずれかを用いて、TCP Nagleアルゴリズムをサポートしている、請求項51に記載のプロセス。
【請求項６０】
当該TCPステートマシンが、TCP選択確認応答(SACK)オプションをサポートしている、請求項51に記載のプロセス。
【請求項６１】
当該TCPステートマシンが、パケット往復遅延時間を測定する、請求項51に記載のプロセス。
【請求項６２】
当該TCPステートマシンが、輻輳回避アルゴリズムを遂行する、請求項51に記載のプロセス。
【請求項６３】
当該TCPステートマシンが、専用の最適化されたハード・ワイヤード・ロジックを用いて、TCPスケーリング・ウィンドウをサポートする、請求項51に記載のプロセス。
【請求項６４】
当該TCPステートマシンが、専用の最適化されたハード・ワイヤード・ロジックを用いて、最大セグメントサイズ(MSS)探索をサポートする、請求項51に記載のプロセス。
【請求項６５】
当該TCPステートマシンが、専用の最適化されたハード・ワイヤード・ロジックを用いて、タイム−ウェイト  アセシネーション(time-wait assassination)をサポートする、請求項51に記載のプロセス。
【請求項６６】
当該TCPステートマシンが、専用の最適化されたハード・ワイヤード・ロジックを用いて、ポート・フォワーディングをサポートする、請求項51に記載のプロセス。
【請求項６７】
請求項48に記載のプロセスにおいて、
IPルータ・モジュールを備える過程をさらに有するプロセスであって、
当該IPルータ・モジュールが、
ネットワーク・アドレス中継のためのハードウェアを含むデフォルトIP経路制御能力と、
複数のホストIPアドレスに対する経路制御と、
ホスト指定経路およびネットワーク指定経路に対する経路制御と、
ICMPリダイレクト・パケット・メッセージ受信後の経路制御情報の動的な更新と、
リミテッド・ブロードキャスト、サブネット・ディレクテッド・ブロードキャストおよびネットワーク・ディレクテッド・ブロードキャストを含むが、それらに制限されないIPブロードキャスト・アドレスを伴う経路制御と、
ループ・バックIPアドレスを伴う経路制御と、
IPマルチ・キャスト・アドレスを伴う経路制御と、のうちの任意の1つ以上を遂行するプロセス。
【請求項６８】
当該プロトコル・ステートマシンが、IPプロトコル・ステートマシンを具備し、そして、当該IPステートマシンが、IPネットワーク・パケットを処理し、生成し、応える、請求項48に記載のプロセス。
【請求項６９】
当該IPモジュールが、IPネットワーク・パケットを再構築するための専用の最適化されたハード・ワイヤード・ロジックを有する、請求項68に記載のプロセス。
【請求項７０】
当該プロトコル・モジュールが、ICMPネットワーク・メッセージまたはIGMPネットワーク・メッセージを処理し、生成し、応えるための専用の最適化されたハード・ワイヤード・ロジックを有するICMPモジュールを具備する、請求項48に記載のプロセス。
【請求項７１】
当該プロトコル・モジュールが、一定のICMP機能またはIGMP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムできる最適化されたハード・ワイヤード・ロジックから成るICMPモジュールを具備する、請求項48に記載のプロセス。
【請求項７２】
専用の最適化されたハード・ワイヤード・ロジックを用いて、真のランダム分布を持つIPパケットの識別フィールドを生成し、そして、前記識別フィールドの将来値を予測する試みを防止するIP識別ジェネレータ・モジュールをさらに有する、請求項48に記載のプロセス。
【請求項７３】
当該プロトコル・ステートマシンが、バーチャル・ナンバのネットワーク・コネクションの使用を可能にするバーチャル・ソケットステートマシンを具備する、請求項48に記載のプロセス。
【請求項７４】
当該プロトコル・ステートマシンが、受信状態ハンドラステートマシンを具備し、当該受信状態ハンドラステートマシンが、自動的にIPネットワーク・パケットに応える請求項48に記載のプロセスであって、
リセット(RST)パケットの生成と、
確認応答パケットとの同期(SYN/ACK)の生成と、
確認応答パケット(ACK)の生成と、
同期パケット(SYN)の生成と、
終了パケット(FIN)の生成と、
終了／確認応答パケット(FIN/ACK)の生成と、
リセット／確認応答パケット(RST/ACK)の生成と、のうちの任意の1つ以上を含むプロセス。
【請求項７５】
当該プロトコル・ステートマシンが、ARPプロトコル・ステートマシンを具備し、そして、当該ARPステートマシンが、ネットワークARP応答を生成することによって、ネットワークARP要求に応える、請求項48に記載のプロセス。
【請求項７６】
当該ARPモジュールが、
ハードウェアARPアドレス・キャッシュと組み合ったARP要求と、
複数のIPアドレスに対するARP要求と、
ユニキャストARP要求と、
gratuitous ARP要求と、のうちの任意の1つ以上を生成する、請求項75に記載のプロセス。
【請求項７７】
当該ARPステートマシンが、一定のARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項75に記載のプロセス。
【請求項７８】
当該ARPステートマシンが、優先順位を変化できるようにプログラムされている、請求項75に記載のプロセス。
【請求項７９】
最適化されたハード・ワイヤード・ロジックを用いて構築されたARPアドレスのためのキャッシュを備える過程をさらに有する、請求項75に記載のプロセスであって、
当該ARPキャッシュが、専用ハードウェアによって制御される、動的に分類されるテーブルを用い、
当該ARPキャッシュが、ARPプロキシとして働く能力をサポートし、そして、
当該ARPキャッシュが、専用ハード・ワイヤード・ロジックを用いて、ARPキャッシュ・エントリの満了時間を制御する、プロセス。
【請求項８０】
当該プロトコル・ステートマシンが、RARPプロトコル・ステートマシンを具備し、そして、当該RARPステートマシンが、IPアドレスを要求するか、または、供給することができる、請求項48に記載のプロセス。
【請求項８１】
当該RARPステートマシンが、一定のRARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項80に記載のプロセス。
【請求項８２】
ハード・ワイヤード・バーチャル・メモリ管理を可能にするメモリ構造を備える過程をさらに有する、請求項48に記載のプロセスであって、
当該メモリ構造が、
各々が自らの目的に対して最適化された、様々に分類された制御ブロックのセットと、
各制御ブロックに記憶されたポインタを用いて、制御ブロックをリンクするメカニズムと、を有するプロセス。
【請求項８３】
当該ハード・ワイヤード・バーチャル・メモリ管理が、制御ブロックを割り付け、制御ブロックを更新し、そして、制御ブロックの割り付けを解放する、請求項82に記載のプロセス。
【請求項８４】
プログラム可能な優先順位にしたがって送信するためにパケットをスケジュール化する優先順位キューを備える過程をさらに有する、請求項48に記載のプロセス。
【請求項８５】
ネットワーク・パケットが処理されるべき優先順位を計算して、割り当てるシーケンサを備える過程をさらに有する、請求項48に記載のプロセス。
【請求項８６】
ネットワーク・サービス不能攻撃から保護するように、各ネットワーク・コネクションの状態についてのネットワーク情報を記憶するメモリ・アーキテクチャを備える過程をさらに有する、請求項48に記載のプロセス。
【請求項８７】
当該ネットワーク・スタックが、TCPパケットおよびIPパケットを処理し、生成し、受信し、そして、当該ネットワーク・スタックが、一定のIPパケット処理機能またはTCPパケット処理機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項48に記載のプロセス。
【請求項８８】
当該ネットワーク・スタックが、iSCSIまたはRDMAのような、より上位レベルのプロトコルをカプセル化するIPパケットを処理し、生成し、受信する、請求項48に記載のプロセス。
【請求項８９】
ハード・ワイヤード・ロジック中にインプリメントされたバーチャル・メモリ・マネージャを備える過程をさらに有する、請求項48に記載のプロセス。
【請求項９０】
当該バーチャル・メモリ・マネージャが、バーチャル・ナンバのネットワーク・コネクションの使用を可能にし、そして、当該ネットワーク・コネクションのバーチャル・ナンバが、利用可能な内部メモリ量または外部メモリ量によってしか制限されない、請求項89に記載のプロセス。
【請求項９１】
当該バーチャル・メモリ・マネージャが、ハード・ワイヤード・ロッキング・メカニズムを用いて、メモリ位置間の干渉を防止する、請求項89に記載のプロセス。
【請求項９２】
当該バーチャル・メモリ・マネージャが、一続きのメモリ構造を用いて、メモリにネットワーク・コネクション情報を記憶する、請求項89に記載のプロセス。
【請求項９３】
当該バーチャル・メモリ・マネージャが、専用ハード・ワイヤード回路を用いて、リンクリストまたは一続きのメモリ構造にエントリの探索、更新、挿入、削除を行う、請求項89に記載のプロセス。
【請求項９４】
当該バーチャル・メモリ・マネージャが、いくつかの相異なるタイプの制御ブロックを用いて、ネットワーク・コネクション情報を、前記ネットワーク・コネクションの状態に依存して記憶する、請求項89に記載のプロセス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電気通信に関するものである。より特定的には、本発明は、データを送受信するために用いられる通信プロトコルに関連するデータを処理するための方法および装置に関するものである。
【背景技術】
【０００２】
コンピュータ・ネットワークは、データを送受信するために、種々の通信プロトコルの設置を必要とする。通常、コンピュータ・ネットワークは、互いに通信し合うように接続されたコンピュータ、プリンタ、および、他のコンピュータ周辺装置のようなデバイスのシステムを有している。データは、通信プロトコル標準を用いてネットワーク中を伝わるデータ・パケットを通して、それらのデバイスの各々の間を転送される。多くの相異なるプロトコル標準が、今日、用いられている。一般的なプロトコルの例としては、インターネット・プロトコル(IP)、インターネット・ワーク・パケット交換(IPX)、シーケンス・パケット交換(SPX)、トランスミッション・コントロール・プロトコル(TCP)、ポイント・ツー・ポイント・プロトコル(PPP)がある。各ネットワーク・デバイスには、プロトコルとプロセスデータとを中継するハードウェアとソフトウェアとのコンビネーションが含まれている。
【０００３】
一例は、ローカル・エリア・ネットワーク(LAN)システムに配されたコンピュータであり、そこでは、ネットワーク・デバイスが、ハードウェアを用いて、リンク層プロトコルをハンドルし、ソフトウェアを用いて、ネットワーク・プロトコル、トランスポート・プロトコル、通信プロトコル、および、通信データ・ハンドリングをハンドルしている。ネットワーク・デバイスは、通常、ハードウェア内にただ1つのリンク層プロトコルをインプリメントしており、配されているコンピュータを、その特定のLANプロトコルのみに制限している。データ・ハンドラとともに、より高位のプロトコル、例えば、ネットワーク・プロトコル、トランスポート・プロトコル、通信プロトコルは、データがネットワーク・デバイス・ハードウェアを通ってシステム・メモリに渡されるとすぐに、それらのデータを処理するソフトウェアプログラムとしてインプリメントされている。このインプリメンテーションの利点は、それが、コンピュータのような多目的デバイスを、多くの相異なるネットワークセットアップに用い、また、必要とされるどんな任意のネットワークアプリケーションをもサポートさせることを可能にするということである。しかしながら、このインプリメンテーションの結果として、そのシステムは、高いプロセッサ・オーバーヘッド、大量のシステム・メモリ、相異なるソフトウェア・プロトコルを協働させるためのコンピュータユーザ側の複雑な構成セットアップ、および、コンピュータのオペレーティング・システム(O.S.)とコンピュータとネットワーク・ハードウェアとを通信させ合うデータ・ハンドラを必要とする。
【０００４】
処理時間に必要とされるこの高いオーバーヘッドは、1つのデバイス上で同一のプロトコルをインプリメントしている複数のソフトウェア・プロトコル・スタックを動作させる方法を教示している、1996年1月16日にSchrier等に公告された米国特許番号5,485,460に明示されている。このタイプのインプリメンテーションは、マイクロソフト・ウィンドウズを走らせている、ディスク・オペレーティング・システム(DOS)ベースのマシンで用いられている。通常動作中、ハードウェアが、トランスポート・プロトコルまたはリンク層プロトコルを確認すると、結果として生じるデータ・パケットが、パケットフレームフォーマットを決定して、任意の特定のフレーム・ヘッダを取り除くソフトウェアレイヤに送られる。そのパケットは、次に、さまざまなプロトコル・スタックに送られ、そこで、特定のプロトコルに対して評価される。しかしながら、そのパケットは、いくつかのプロトコルのスタックに送られた後で、受け入れられる、または、拒絶されるかもしれない。ソフトウェア・プロトコル・スタックによって作り出される時間遅れは、オーディオおよびビデオ伝送をリアルタイムに処理することを妨げる。即ち、それらのデータを、再生の前にバッファしなければならない。1つのプロトコルを処理するために必要な処理オーバーヘッドの総計は、非常に高く、極端にかさばって扱いにくく、強力な中央処理装置(CPU)と大量のメモリとを用いるアプリケーションに向くことが、明白である。
【０００５】
ネットワーク・デバイスの従来のモデルにはまらないコンシューマ製品が、市場に参入してきている。それらの製品の新しい例は、ページャ（ポケベル）、携帯電話、ゲームマシン、スマート電話、テレビジョンである。それらの製品の大多数は、小さなフットプリント、8ビットコントローラ、限られたメモリを持っており、あるいは、非常に限定されたフォーム・ファクタを必要とする。それらのようなコンシューマ製品は、単純であり、低価格および低電力消費を必要とする。上述のプロトコル・インプリメンテーションは、それらの必要条件をかなえるには、あまりにも大きなハードウェアおよびプロセッサ能力を必要とする。そのようなインプリメンテーションの複雑さは、費用効率を高く、コンシューマ製品に組み込むことを困難にする。ネットワーク・アクセスが、低価格、低電力、小フォーム・ファクタのデバイス上に容易につくりあげられるほどに単純化できるようになれば、それらの製品は、インターネットのようなネットワーク・サービスにアクセスできるようになる。
【０００６】
通信ネットワークは、データを送受信するためにプロトコルを用いる。通常、通信ネットワークは、互いに通信し合うように接続されたコンピュータ、プリンタ、記憶デバイス、および、他のコンピュータ周辺装置のような、ノードとも呼ばれるネットワーク・デバイスの集合を有している。データは、プロトコルを用いて通信ネットワーク中を伝わるデータ・パケットを用いて、それらのネットワーク・デバイスの各々の間を転送する。多くの相異なるプロトコルが、今日、用いられている。一般的なプロトコルの例としては、インターネット・プロトコル(IP)、インターネット・ワーク・パケット交換(IPX) プロトコル、シーケンス・パケット交換(SPX) プロトコル、トランスミッション・コントロール・プロトコル(TCP)、ポイント・ツー・ポイント・プロトコル(PPP)、および、開発中の他の同様の新しいプロトコルがある。ネットワーク・デバイスには、プロトコルとデータ・パケットとを処理するハードウェアとソフトウェアとのコンビネーションが含まれている。
【０００７】
1978年に、標準設定母体である国際標準化機構(ISO)が、オープン・システム・インターコネクション(OSI)モデルとして知られるネットワーク参照モデルを作り出した。OSIモデルは、7つの概念層：1）ネットワーク・デバイスをネットワークに接続する物理的な構成要素を決定する物理(PHY)層、2）データ・パケットを含むフレームとして知られている離散形状にデータの動きを制御するデータリンク層、3）特定のプロトコルにしたがってデータ・パケットを組み立てるネットワーク層、4）データ・パケットの信頼性の高い送付を確実にするトランスポート層、5）ネットワーク・デバイス間の双方向通信を可能にするセッション層、6）データを表現する態様を制御し、そのデータが正しい形式にあることを確実にするプレゼンテーション層、7）ファイル共有、メッセージ・ハンドリング、プリンティング等を供給するアプリケーション層、を含有している。セッション層およびプレゼンテーション層は、このモデルから除外されることもある。最新の通信ネットワークおよびインターネットがどのようにISOの7層モデルに関係しているかに関する説明については、例えば、Douglas E. Comerによるテキスト“Internetworking with TCP/IP”（第1巻、第4版、国際標準図書コード0201633469）の第11章、および、W. Richard Stevensによるテキスト“TCP/IP Illustrated” （第1巻、国際標準図書コード0130183806）の第1章を参照されたい。
【０００８】
ネットワーク・デバイスの一例は、ローカル・エリア・ネットワーク(LAN)に配されたコンピュータであり、そこでは、ネットワーク・デバイスが、ホスト・コンピュータ内のハードウェアを用いて物理層およびデータリンク層をハンドルし、ホスト・コンピュータ上を走るソフトウェアを用いてネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層をハンドルする。ネットワーク層、トランスポート層、セッション層、プレゼンテーション層は、プロトコル・スタックとも呼ばれるプロトコル処理ソフトウェアを用いてインプリメントされる。アプリケーション層は、データがネットワーク・デバイス・ハードウェアおよびプロトコル処理ソフトウェアを通ったときに、そのデータを処理するアプリケーション・ソフトウェアを用いてインプリメントされる。このソフトウェアベースのプロトコル処理インプリメンテーションの利点は、それが、多目的コンピュータを、多くの相異なるタイプの通信ネットワークに用い、また、必要とされるどんなアプリケーションをもサポートさせることを可能にするということである。しかしながら、このソフトウェアベースのプロトコル処理インプリメンテーションの結果として、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層を処理するために、ホスト・コンピュータの中央処理装置(CPU)上を走るプロトコル処理ソフトウェアのオーバーヘッドが、非常に高いものになる。ソフトウェアベースのプロトコル処理インプリメンテーションは、また、データが、ソフトウェアによって処理されるときにコピーされ、そして、移動されなければならないから、ホスト・コンピュータ上に大量のメモリをも必要とする。プロトコル処理ソフトウェアによって必要とされる高いオーバーヘッドは、複数のソフトウェア・プロトコル・スタックの動作方法を教示している、1996年1月16日にSchrier等に公告された米国特許番号5,485,460に明示されている。このタイプのソフトウェアベースのプロトコル処理インプリメンテーションは、例えば、マイクロソフト・ウィンドウズを走らせているコンピュータで用いられている。
【０００９】
ネットワーク・デバイスの通常動作中、ネットワーク・デバイス・ハードウェアは、その後にホスト・コンピュータ内のプロトコル処理ソフトウェアに送られることになるデータ・パケットを抽出する。プロトコル処理ソフトウェアは、ホスト・コンピュータ上で走り、このホスト・コンピュータは、そのタスクがプロトコル処理ソフトウェアによって遂行されるように最適化されてはいない。プロトコル処理ソフトウェアと多目的ホスト・コンピュータとのコンビネーションは、プロトコル処理に対して最適化されておらず、それは、遂行能力限界に導く。プロトコル処理ソフトウェアの実行によって作り出される時間遅れのような、プロトコル処理中の遂行能力限界は有害で、例えば、オーディオおよびビデオ伝送のリアルタイム処理を妨げるであろうし、また、通信ネットワークの最大速度、最大容量での使用を妨げるであろう。1つのプロトコルを処理するために必要なホスト・コンピュータCPUオーバーヘッドの総計は、非常に高く、極端にかさばって扱いにくく、そして、ホスト・コンピュータ内にCPUと大量のメモリとの使用を必要とすることが明白である。
【００１０】
ネットワーク・デバイスの従来のモデルにはまらない新しいコンシューマ製品および工業製品が、市場に参入してきており、同時に、ネットワーク速度が、上昇し続けている。それらのコンシューマ製品の例には、インターネット接続可能なセルフォン、インターネット接続可能なTV、インターネットアプライアンスが含まれる。工業製品の例には、ネットワーク・インターフェイス・カード(NIC)、インターネット・ルータ、インターネット・スイッチ、インターネット・ストレージ・サーバが含まれる。ソフトウェアベースのプロトコル処理インプリメンテーションは、それらの新しいコンシューマ製品および工業製品の必要条件をかなえるには、あまりにも非能率的である。ソフトウェアベースのプロトコル処理インプリメンテーションは、その複雑さのために、費用効率を高くコンシューマ製品に組み込むことが困難である。ソフトウェアベースのプロトコル処理インプリメンテーションは、必要とされる処理電力のために、高速の工業製品にインプリメントすることが困難である。プロトコル処理が、低価格、低電力、高性能、集積化、小フォーム・ファクタのデバイス上に容易につくりだされるように単純化でき、最適化できれば、それらのコンシューマ製品および工業製品は、インターネットのような任意の通信ネットワーク上のデータを読み込んだり、書き込んだりできるようになる。
【００１１】
ソフトウェアベースのプロトコル処理インプリメンテーションとは対照的に、ハードウェアベースのプロトコル処理インプリメンテーション、即ち、インターネット・チューナが、J. Minami, R. Koyama, M. Johnson, M. Shinohara, T. Poff, D. Burkes,“Multiple network protocol encoder/decoder and data processor”, 米国特許番号6,034,963（2000年3月7日）（ ‘963特許）に記述されている。このインターネット・チューナは、プロトコルを処理するためのコア技術を提供する。
【００１２】
高いネットワーク通信速度に対するハードウェア解を備えたギガビット・イーサネット・アダプタを提供することは、有益なことである。さらに、複数の通信プロトコルを適合させるギガビット・イーサネット・アダプタを提供することも、有益なことである。
【００１３】
【特許文献１】
米国特許番号5,485,460
【特許文献２】
米国特許番号6,034,963
【非特許文献１】
Douglas E. Comer 著  「TCP/IPとのインターネットワーキング（Internetworking with TCP/IP）」第1巻、第11章
【非特許文献２】
W. Richard Stevens著  「図解TCP/IP（TCP/IP Illustrated）」 第1巻 第1章
【発明の開示】
【課題を解決するための手段】
【００１４】
本発明は、ギガビット・イーサネット・アダプタを提供する。そのシステムは、高ネットワーク通信速度を扱うためのコンパクトなハードウェア解を提供する。さらに、本発明は、モジュールの構築および設計を介して、複数の通信プロトコルに適合する。
【００１５】
本発明の好適な一実施例は、低メモリ要請しか持たず、かつ、高度に効率的なプロトコルデコードを供給する、低価格で、低電力で、容易に製造可能で、小フォーム・ファクタのネットワーク・アクセス・モジュールを提供する。本発明は、複数のネットワーク・プロトコルを同時にバイト・ストリーム態様でデコードもし、また、パケット・データを1つのパスで処理もし、それによって、システム・メモリおよびフォーム・ファクタの要求条件を減少させ、また、ソフトウェアCPUオーバーヘッドを排除する、ハードウェア統合システムを有する。
【００１６】
本発明の好適な一実施例は、TCP, IP, ユーザ・データグラム・プロトコル(UDP), PPP, ローソケット, RARP, ICMP, IGMP, Iscsi, RDMA, FCIPのようなネットワーク・プロトコルを、各バイトが受信されたときに同時にデコードする、複数のプロトコル・ステートマシンを有している。各プロトコル・ハンドラは、中間メモリを要求せずに、パケットからヘッダー情報を直接に構文解析し、インタプリトし、剥ぎ取る。
【００１７】
本発明は、インターネット・チューナ・コア、周辺装置、および、外部インターフェイスを提供する。ネットワーク・スタックは、ネットワーク・パケットを処理し、生成し、受信する。プログラム可能な内部プロセッサは、ネットワーク・スタックを制御し、任意の他のタイプのICMPパケット、IGMPパケット、あるいは、専用ハードウェアによって直接サポートされていない他のプロトコルに対応するパケットをハンドルする。
【００１８】
バーチャル・メモリ・マネージャが、最適化されたハード・ワイヤード・ロジックにインプリメントされる。そのバーチャル・メモリ・マネージャは、バーチャル・ナンバのネットワーク・コネクションの使用を可能にする。ネットワーク・コネクションのバーチャル・ナンバは、利用可能な内部メモリ量および外部メモリ量によってしか制限されない
どの出ていくネットワーク・パケットも、データ・ステートマシンによって作り出され、そして、そのパケットにフォーマットを付加して、ヘッダ情報のチェックサムを行い、その結果生じたネットワーク・パケットを物理的な輸送レベルメカニズムを介して配布するネットワーク・プロトコル・ステートマシンを通る。
【００１９】
ハードウェア・ゲートレベル・インプリメンテーションは、設計者が、特定の応用に必要とされる機能を精選しながら、なおかつ、低価格で低電力で小フォーム・ファクタを維持することができる、モジュール性で嵌め込み可能な設計を提供する。
【００２０】
本発明の他の観点および利点は、添付の図面と組み合わせて、例として本発明の原理を例証する、以下の詳細な記述から明白になる。
【発明を実施するための最良の形態】
【００２１】
本発明は、ギガビット・イーサネット・アダプタで具体的に表現される。本発明による1システムは、高ネットワーク通信速度をハンドリングするためのコンパクトなハードウェア解を提供する。さらに、本発明は、モジュール構造および設計を介して複数の通信プロトコルを適合させる。
【００２２】
図1を参照すると、本発明は、ネットワーク・プロトコル層101、データ・ハンドラ102、メモリ制御モジュール103、オペレーティング・システム(O.S.)ステートマシン・モジュール104を有し、その各々が、ハードウェア・ゲートレベルでインプリメントされている。ネットワーク・プロトコル層101は、入ってくるネットワーク・パケットをデコードし、出て行くネットワーク・パケットをエンコードする。ネットワーク・プロトコル層101は、入ってくるネットワーク・パケットを同時にデコードする種々のネットワーク・プロトコル・スタック（即ち、PPP, TCP, IP, UDP, ローソケット）を表わす複数のステートマシンを有している。ゲートレベルロジックでのプロトコル・スタックのインプリメンテーションは、ネットワーク・パケットを受信しながら、そのパケットをリアルタイムにデコーディングすることを可能にし、それによって、一時メモリ記憶を全く不要にする。パケット・ヘッダ情報の全てが、はがされ、そして、ステートマシンによって確認された後、その結果として得られたデータが、データ・ハンドラ102に渡される。データ・ハンドラ102は、複数のステートマシンを有し、それらの各々は、特定のデータタイプ（即ち、HTTP、eメール・フォーマット（ポスト・オフィス・プロトコル(POP3)、インターネット・メッセージ・アクセス・プロトコル(IMAP4)、シンプル・メール・トランスファ・プロトコル(SMTP)）、グラフィックス標準（ジョイント・フォトグラフィック・エキスパーツ・グループ(JPEG)、グラフィックス・インターチェンジ・フォーマット(GIF)）、Java、HTML）を処理する。データ・ハンドラのゲートレベル・インプリメンテーションは、本発明が受信データをリアルタイムで同時に処理することを可能にし、特に、データ・ストリームを受信しながら、それらのデータ・ストリームをハンドルする応用、即ち、Java, HTML, POP3 eメール、および、オーディオ応用、ビデオ応用に適している。2つ以上のデータ・ステートマシンによって必要とされるどのデータも、同時に供給される。特定のデータ・ステートマシンによって2回以上必要とされるどのデータも、それらのデータを指定するポインタをつけて、特定のメモリ位置に置かれる。全てのメモリアクセスは、メモリ制御モジュール103によって調停される（アービトレーションを行われる）。その結果、どのディスプレイデータも、メモリ制御モジュール103によって発送される。O.S.ステートマシン104は、リソース制御、システム、ユーザインターフェイスのためのステートマシン全体の間のアービトレータ（アービタ）として働く。どのユーザ入力も、O.S.ステートマシンによってインタプリトされ、データ・ハンドラ102に発送される。
【００２３】
一例として、HTMLフォーマットをインタプリトするデータ・ハンドラは、サイクリック・リダンダンシ・チェック(CRC)計算を用いてHTMLタグをデコードできる。HTMLフォーマットには、タグとして知られているキャラクタ・ストリングが含まれており、それは、後に続くテキストブロックが、ビデオ出力デバイス上に表示されるときに、そのフォーマティングを制御する。それらのタグは、1つの与えられたタグに対して1つのCRCナンバーを生成し、当該ナンバーを用いてフォーマティング命令をイネーブルにすることによって、効率的にデコードすることができる。そのようなデコーディングアルゴリズムは、ゲートレベル・インプリメンテーションに適しており、HTMLエンコードされたドキュメントを、今日可能であるよりもずっと敏速にビデオ出力デバイス上に表示させる。
【００２４】
本発明は、ハードウェア・ゲートレベルであるとして記述されるが、当業者であれば、それらの機能は、プログラマブル・アレイ・ロジック(PAL)、ジェネラル・アレイ・ロジック(GAL)、読み出し専用メモリ(ROM)、ソフトウェアのような多くの他の仕方でインプリメントできるということを、容易に認識できる。さらに、特定のプロトコルおよびデータタイプが指示されてきたが、当業者であれば、本発明のモジュール性は、本発明を、それらの特定のプロトコルあるいはデータタイプに限定させないということを、容易に認識できる。
【００２５】
図2を参照すると、本発明が、ハイレベル・ブロック・ダイアグラムで表現されている。このダイアグラムは、本発明の完全なインプリメンテーションにおける各モジュールの動作タスクを記述している。O.S.ステートマシン208は、システム“グルー”ロジック、および、デバイス制御インターフェイスを具備し、他のモジュールのステートマシン間の“トラフィックコップ”として働く。ネットワーク・プロトコル層207は，TCP/IPプロトコル, UDPプロトコル, ローソケット・プロトコル、PPPプロトコルに対するステートマシンを具備している。メモリ制御モジュール206は、システム・メモリとビデオ・ディスプレイ・メモリとが、同一のメモリエリアに存在することを可能にするユニファイド・メモリ・アーキテクチャ(UMA)のためのロジックを具備している。ディスプレイ・コントローラ205は、テレビジョン標準であるVGA、あるいは、他のタイプのディスプレイの制御を提供する。4つのデータ・ハンドラが、このインプリメンテーションに用いられている。Eメール・データ・ハンドラ201は、POP3フォーマットとIMAP4フォーマットとの両方をインタプリトする。JPEGフォーマットおよびGIFフォーマットをデコードする（商業標準および電話通信標準もデコードできる）インタプリタ202が、インプリメントされている。Java言語をバイトコード（中間言語）にインタプリトするJavaマシン203も、含まれている。ワールド・ワイド・ウェブ(WWW)ブラウザ204は、HTMLデコーダ／アクセラレータ、HTTPデータ・ハンドラ、および、集積されたeメール・ステート・マシンを具備している。
【００２６】
一例として、モデム物理トランスポートを想定して、入ってくるJPEG映像パケットが、システムによって追跡される。その要求は、ユーザが、定められたJPEG映像をダウンロードするという願望を、キーボード321をタイピングすることによって指示するとともに開始する。この入力は、キーボード・インターフェイス316によってインタプリトされ、O.S.ステートマシン315に渡される。O.S.ステートマシン315は、その入力を処理し、それを、1つのコマンドとして、HTTPクライアント311に渡す。HTTPクライアントは、要求されたパケットを生成し、それを、ポート・デコーダ309を介してTCP層308に渡す。TCP層は、適切なTCPヘッダをプリペンド（前方に追加）し、それを、IP層307に渡す。IP層は、次いで、適切なIPヘッダをプリペンドし、そのパケットを、PPP層306に渡す。PPP層は、適切なヘッダをプリペンドし、FCSをアペンド（後方に追加）し、そして、そのデータを物理トランスポート・インターフェイス305に渡す。物理トランスポート・インターフェイスは、そのデータをビットストリームに連続化し、そのパケットをモデム・ユニット304に送る。要求がホストサーバによって受け入れられると、ホストサーバは、要求されたJPEG映像をクライアント・システムに送り返す。そのデータは、最初に、データが存在することを物理トランスポート・インターフェイス305に指示するモデム 304によって受信される。物理トランスポート・インターフェイスは、次に、そのモデムからビット・シリアル・データを読み出し、それを、パラレル・バイト・データに変換し、そして、データが存在することをPPP層306に指示する。PPP層は、受信されたバイトを読み出す。PPP層が、有効なスタート・バイトを検出すると、そのPPP層は、入ってくるバイトを構文解析する。バイト・ストリームが、PPPプロトコル・フィールドに達すると、PPP層は、それをデコードし、そして、この例においては、埋め込まれているパケットを、タイプIPであるとしてデコードする。このプロトコルバイトに応えて、PPP層は、IP層307をイネーブルにし、そして、それに、IPデータが受信されていることを指示する。全てのそれ以降の受信データ・バイトは、今や、IP層に直接渡される。IP層は、次いで、入ってくるデータ・バイトの構文解析を始める。それが、IPヘッダ・プロトコル・フィールドまで来ると、それは、どのより高位のプロトコルがイネーブルにされるかを決定する。この例においては、IP層は、そのプロトコル・フィールドを、タイプTCPであるとしてデコードする。この時点で、IP層は、TCP層308をイネーブルにし、そして、TCPデータが受信されているときはいつでも、それに指示する。このインジケータがアクティブになると、全てのそれ以降の受信パケット内のデータ・バイトは、IP層とTCP層との両方に渡される（IP層は、チェックサム計算を完成させるためにデータ・バイトを必要とする）。TCP層は、その後、入ってくるデータ・バイトの構文解析を始める。それが、TCPヘッダ送信先ポート・フィールドまで来ると、それは、どのデータ・ハンドラがイネーブルにされるかを決定する。この例においては、そのポート・フィールドは、HTTPクライアント311をデコードする。この時点で、ポート・デコーダは、HTTPクライアントをイネーブルにし、そして、それに、HTTP要求データ���受信されていることを指示する。HTTPクライアントは、次に、受信されたデータ・バイトの構文解析を始める。HTTPクライアントが、そのパケットがタイプJPEG映像であると決定すると、HTTPクライアントは、JPEGデコーダ313をイネーブルにする。この時点で、全てのデータ・バイトが、JPEGデコーダに発送される。JPEGデコーダは、次いで、全てのそれ以降に入ってくるデータ・バイトを受信し、したがって、それらを処理する。結果としてデコードされた映像が、メモリ・コントローラ312を介してディスプレイ・メモリに送られ、そして、ディスプレイデバイス326に出力するために、ディスプレイ・コントローラ324によって処理される。
【００２７】
図3に、また、示されているように、様々な層が、共有メモリリソースへのアクセスを必要とする。全てのメモリアクセスは、単一のメモリ・コントローラによって調停される。このメモリ・コントローラは、どの層あるいはどのハンドラが、任意の定められたサイクルでユニファイド・メモリ・バッファにアクセスを持つかを決定する。このメモリ・コントローラは、全てのシステム・メモリ・バッファおよびディスプレイ・メモリ・バッファが、単一のメモリ・バッファ・ユニットの内部に共有されるという事実のために必要とされる。ユニファイド・メモリ・コントローラ312は、様々な層からの読み出し要求および書き込み要求を取り上げ、一定の優先順位重み付けをなした動的循環アービトレーションスキームに基づいて、それらの要求を調停する。このアルゴリズムが、図3Aに描かれている。図示されている構成において、デバイスD2 302AとデバイスD3 303Aとの両方が、同時にメモリアクセスを要求すると、アービタ307Aが、最も最近にメモリアクセスを持たなかったデバイスにサイクルを振る。アービタ307Aは、次に、そのメモリ要求を、アービタ309AのA入力に渡す。アービタ309AのB入力がアイドル状態であれば、その要求は、アービタ310AのB入力に登る。アービタ310AのA入力がアイドル状態であれば、その要求は、メモリユニットに進む。全てのアービトレーション決定は、組み合わせ論理を用いて遂行され、それによって、どのデバイスに対しても、他のメモリ要求が全くなされていなければ、どんな待ち時間もなくしてしまう。優先順位重みは、アービトレーション樹構造を構成することによって割り当てられる。図3Aにおいて、デバイスDO 300AとデバイスD1 301Aとは、全てのデバイスが、不断のメモリ使用を要求した場合、それら2つのデバイスが、各々、25％時間アービトレーションを得ることのできる25％優先順位重み効力を、各々、持っている。デバイスD2 302A, D3 303A, D4 304A, D5 305Aは、各々、12.5％優先順位重みを持っている。メモリ・コントローラ設計は、個々のアービトレーション・ユニットの各々に同一の論理構造を持たせることによって、簡単になる。この仕組みにおいては、要求を出すデバイスの数、および、それらの優先順位重みは、アービタユニットを加え、そして、それらを配置することによって、簡単に構成できる。
【００２８】
図4を参照すると、本発明が提示している速度的な優位性は、現在用いられている従来のアーキテクチャよりもずっと高い。図は、各タスクを完了するのに必要な時間を示している。HTMLダウンロード401、HTMLのデコード402、JPEGダウンロード403、JPEGのデコード404、JAVAダウンロード405、JAVAバイトのデコード406、および、ストリーミングオーディオ407を要求する一連のパケットに対して、それらのタスクに要する総時間が、従来のアーキテクチャ408と本発明（iReadyアーキテクチャ）409とにおいて示されている。本発明409は、それらのタスクにおいて、従来のアーキテクチャ408よりもはるかに速い。
【００２９】
図5を参照すると、このタイプのネットワーク・アクセスの応用の発展が、示されている。現在、ネットワーク・クライアントの従来のモデル、即ち、コンピュータ501が、用いられている。ネットワークPC 502、ハンド・ヘルド・デバイス503、スマート電話504、セット・トップ・アプライアンス505、スマートテレビジョン506のコンシューマアプライアンス概念が、今や、現実となってきている。本発明は、コスト効率が高く、空間、速度、電力を重視したネットワーク・アクセスを備えた、それらの製品を供給する。
【００３０】
図6を参照すると、本発明は、テレビジョンチューナ602あるいはラジオチューナ611とほとんど同じように動作する…信号（パケット）は、遅延なく即座に処理され、そして、ディスプレイ出力あるいはオーディオ出力に送られる。用語「インターネット・チューナ」608は、そのような信号処理デバイスとの類似性として、本発明を記述するために用いられる。インターネット・チューナ608は、インターネット信号609と、スマートテレビジョン604、セット・トップ・アプライアンス605、スマート電話606、ハンド・ヘルド・デバイス607のような応用製品との間のインターフェイスとして働く。それは、テレビジョンチューナ602やラジオチューナ611のように、リアルタイムでインターネット信号609を処理する。
【００３１】
図7は、O.S.ステートマシン701、ネットワーク・プロトコル層702、メモリコントロール703、ディスプレイ・コントローラ704、eメール・データ・ハンドラ708、インタプリタ707、JAVAマシン706、WWWブラウザ705を用いた本発明の完全インプリメンテーションが、2つの分離したモジュールに分離されてもよいということを図解している。本発明のモジュール性は、データ・ハンドラ713（eメール・データ・ハンドラ717、インタプリタ716、JAVAマシン715、WWWブラウザ714）のような機能が、いくつかの応用において、1つの高水準ROMコード内に分離して置かれることを可能にする。
【００３２】
以下の応用例は、本発明のモジュール設計の万能性をさらに図解する。
【００３３】
図8は、ネットワークPC用として可能な本発明の構成を明示している。1つの変形例は、O.S.ステートマシン801、ネットワーク・プロトコル層802、メモリコントロール803、ディスプレイ・コントローラ804、eメール・データ・ハンドラ808、インタプリタ807、JAVAマシン806、WWWブラウザ805を含んでいる。これは、eメール817、インタプリタ816、JAVAマシン815、WWWブラウザ814コードに対するデータ・ハンドラを、1つのマイクロプロセッサ813上を走る高水準ROM（コード）内に置くことによって変形できる。マイクロプロセッサ813は、O.S.ステートマシン809を通じて、ネットワーク機能およびディスプレイ機能に対して交信する。第3の変形は、サードパーティROM 823を使うマイクロプロセッサ822が、ネットワーク・プロトコル層819およびO.S.ステートマシン818から入ってくるデータをインタプリトすることを可能にする。マイクロプロセッサ822は、ディスプレイ・コントローラ821を通してデータを表示する。
【００３４】
図9を参照すると、ハンド・ヘルド・デバイスは、ネットワーク・プロトコル層901しか用いず、それを、カスタム・トランスポート・メカニズム902および現行マイクロコントローラ904にインターフェイス接続するのであってもよい。Eメール機能が、この構成にeメール・データ・ハンドラ905を含ませることによって、付加されてもよい。本発明のモジュール性をさらに明示すると、ネットワーク・プロトコル層911およびJAVAマシン910を、ハンド・ヘルド・デバイスに加えてもよく、それによって、ハンド・ヘルド・デバイスは、JAVAアプレットを処理することが可能になる。
【００３５】
図10を参照すると、スマート電話は、O.S.ステートマシン1001、ネットワーク・プロトコル層1002、メモリコントロール1003、eメール・データ・ハンドラ1006、ディスプレイ・コントローラ1004をインプリメントすることによって、eメール能力を付加されてもよい。ディスプレイ・コントローラ1004は、発光ダイオード(LED) ディスプレイ、液晶ディスプレイ(LCD)、あるいは、ビッグ・マップ・ディスプレイ(big-mapped display)を制御することができる。物理トランスポート・コントロール1005は、スマート電話の接続要件に応じて、オプション的に付加されてもよい。O.S.ステートマシン1007、ネットワーク・プロトコル層1008、メモリ・コントローラ1009が、現行マイクロコントローラ1010と一緒にスマート電話に付加されてもよい。マイクロコントローラ1010は、サードパーティeメール・クライアント・コード1011を用いて、eメール機能を遂行する。
【００３６】
最後に図11を参照すると、スマートテレビジョン、ケーブルボックス、ビデオ・カセット・レコーダ(VCR)、デジタルビデオディスク(DVD)プレーヤ、ゲームマシンが、本発明によって提示されるネットワーク・アクセス可能性を利用することができる。O.S.ステートマシン1102、ネットワーク・プロトコル層1103、メモリ・コントローラ1104、WWWブラウザ1107、JAVAマシン1106、および、（オプション的に）ディスプレイ・コントローラ1105が、現行コントローラ1101にインターフェイス接続されている。コントローラ1101が存在しないとき、ディスプレイ・コントローラ1105が、用いられる。eメール1115機能は、本発明のモジュール性の故に、容易に付加される。前述のように、eメール1124、インタプリタ1123、JAVAマシン1122、WWWブラウザ1121コードに対するデータ・ハンドラが、マイクロプロセッサ1120上を走る高水準ROM（コード）内にオプション的に置かれる。マイクロプロセッサ1120は、O.S.ステートマシン1116を通じて、ネットワーク機能およびディスプレイ機能に対して交信する。
【００３７】
パケット受信の例
図12は、受信されたネットワーク・パケットを描いている。そのパケットには、以下のアイテムが、左から右に示すように含まれている。
【００３８】
PPPヘッダ
IPヘッダ
TCPヘッダ
JPEGデータ
PPP FCS（フィールド・チェックサム）
PPPレイヤイネーブルと表わされているラインが、有効なスタート・バイトが検出されたときにアクティブになり、図13のPPPブロックの内部に生成される。このラインがハイレベルになると、PPPブロックの残りの部分がアクティブになる。PPPヘッダ内には、PPPパケットがカプセル化されているプロトコルのタイプを指示するフィールドが存在する。圧縮されていないPPPヘッダでは、それらは、4バイトであり、（スタート・バイト0x7Eを含めて合計すると）5バイトである。図12において、それらのバイトは、カプセル化されているデータがIPパケットであることを指示する、0x00および0x21である。このフィールドをデコードした後、PPPブロックは、IPレイヤイネーブル信号およびPPPデータフィールド信号をアクティブにし、そして、それら両方が、図13のIPブロックをイネーブルにする。IPレイヤ・イネーブル・ラインは、PPPプロトコル・タイプ・フィールドによってデコードされ、PPPデータ・フィールド・ラインは、入ってくるデータ・バイト・ストリームがネットワーク・パケットのデータフィールド部にあることを指示する。これら2ラインは、IPブロックがイネーブルになるためには、アクティブでなければならない。IPブロックがイネーブルになると、それは、入ってくるデータ・バイトの構文解析を開始する。図12を参照し直すと、PPPヘッダの直ぐ後に続くデータは、IPヘッダである。IPヘッダ内には、IPパケットの内部にカプセル化されているデータタイプを指示するフィールドが存在する。図12において、このフィールドは、カプセル化されているデータがTCPパケットであることを指示する0x06であることが示されている。TCPレイヤ・イネーブル・ラインは、このフィールドをデコードするIPブロックに応えてアクティブになる。IPヘッダ・プロトコル・フィールドとIPデータフィールドの先頭との間にくるいくつかのバイトが存在するから、IPデータ・フィールド・ラインは、数バイトの後にアクティブになる。IPデータフィールド信号は、入ってくるデータ・バイト・ストリームがネットワーク・パケットのデータフィールド部にあることを指示する。図13のTCPブロックがイネーブルになるためには、TCPレイヤ・イネーブル・ラインとIPデータ・フィールド・ラインの両方ともが、アクティブでなければならない。TCPブロックがイネーブルになると、それは、入ってくるデータ・バイトの構文解析を開始する。図12を参照し直すと、IPヘッダの直ぐ後に続くデータは、TCPヘッダである。TCPヘッダ内には、送信先ポートに対する2バイトフィールドが、存在する。このフィールドは、カプセル化されたデータが、どのアプリケーションあるいはデータ・ハンドラに充てられているかを指示する。図12において、このフィールドは、ポート0x0003に対してデコードする。図13において、ポート3が、HTTPポートとして指定されている。TCPヘッダ内部の送信先ポート・フィールドをデコードした後、HTTPイネーブルラインが、アクティブになる。送信先ポート・フィールドとTCPデータフィールドの開始との間にいくつかの中間バイトが存在するから、TCPデータ・フィールド・ラインは、数バイトの後にアクティブになる。HTTPイネーブルラインとTCPデータ・フィールド・ラインの両方は、図13のHTTP/ポート3ブロックがイネーブルになるためには、アクティ��でなければならない。HTTPブロックがイネーブルになると、それは、入ってくるデータ・バイトの構文解析を開始する。それが、JPEGヘッダをデコードすると、それは、図13のJPEGデコーダブロックをイネーブルにする。JPEGデコーダがイネーブルになると、それは、入ってくるデータ・バイトの処理を開始する。JPEGイネーブルラインは、JPEGブロックをイネーブルにするのに必要な唯一のラインである。
【００３９】
この詳細な記述は、TCP/IP処理の分野で十分に理解されている用語を用いている。これらの用語の詳細な記述を含む参照文献は、W. Richard Stevensによるテキストブック “TCP/IP Illustrated” 第1巻（国際標準図書コード0201633469）、第20刷であり、それは、ここで引用により援用される。適切な場所で、このテキストブックで説明されている、本記述に用いられる用語あるいは概念の説明が、適切なセクション番号あるいは図番によって示される。例えば、Stevens 2.2のような参照は、このテキストブックのセクション2.2のことを言っている。
【００４０】
頭字語
以下の定義が、本明細書で、以下の頭字語に対して用いられる。
ADPCM                              適応的差分パルス符号変調
ARP                      アドレス解決プロトコル
CPU                      中央処理装置
DHCP                  動的ホスト構成プロトコル
HATR                   ハードウェア・アシステッド・テキスト・ラスタライゼーション
ICMP                    インターネット制御メッセージプロトコル
IP                            インターネット・プロトコル
IPV4                      インターネット・プロトコル・バージョン4
MAC                     メディア・アクセス・コントローラ
MDIO                    マネージメントデータ入力／出力
MII                           メディア・インデペンデント・インターフェイス
MIME                    多目的インターネット・メール・エクステンション
PPP                      ポイント・ツー・ポイント・プロトコル
QoS                      クォリティ・オブ・サービス
RARP                   逆アドレス解決プロトコル
SPI                         シリアル・ペリフェラル・インターフェイス
TCP                      トランスポート・コントロール・プロトコル
TTL                        タイム・ツー・ライブ（生存時間）
ToS                       タイプ・オブ・サービス
UDP                      ユーザ・データグラム・プロトコル
UI                            ユーザインターフェイス
【００４１】
モジュールリスト
以下の名称は、本明細書に記述されるモジュールに対して用いられ、参照のためにここにまとめられている。
【００４２】
アドレス・フィルータ・モジュール
ARPキャッシュモジュール
ARPモジュール
データ・アライナ・モジュール
DMAエンジン・モジュール
イーサネット・フレーム・タイプ・パーザ・モジュール
イーサネット・インターフェイス・モジュール
イーサネットMACインターフェイス・モジュール
例外ハンドラ・モジュール
ICMPエコー応答モジュール
ICMPエコー応答プロセッサ・モジュール
ICMPエコー応答受信モジュール
インターナルプロセッサ
IP分割コントローラ・モジュール
IP分割モジュール
IPヘッダ・パーザ・モジュール
IP IDジェネレータ・モジュール
IPモジュール
IPパーザ・モジュール
IPルータ・モジュール
malloc1モジュール
メモリ・アロケータ・モジュール
NATとIPマスカレーディング・モジュール
パケット・スケジューラ・モジュール
パケット・タイプ・パーザ・モジュール
受信データ・メモリ・コントローラ・モジュール
受信DMAエンジン・モジュール
受信TCPパーザ・モジュール
受信器インターフェイス・モジュール
受信状態ハンドラ・モジュール
RSTジェネレータ・モジュール
ソケット受信インターフェイス・モジュール
ソケット受信モジュール
ソケット送信インターフェイス・モジュール
ソケット送信モジュール
TCPモジュール
TCPパーザ・モジュール
TCP受信インターフェイス・モジュール
TCP状態モジュール
TCP送信インターフェイス・モジュール
TCP送信モジュール
送信スケジューラ・モジュール
送信DMAエンジン・モジュール
送信器インターフェイス・モジュール
VSOCKメモリ・アロケータ・モジュール
VSOCKモジュール
【００４３】
バンド幅が増加し続けるにつれて、TCP/IP通信を処理する能力は、システムプロセッサに対するオーバヘッドがますます大きくなる。イーサネット・データ・レートは、秒当り10ギガビットのレートに達するから、TCP/IPプロトコル処理は、ホストCPUの処理パワーの100％近くを消費する。イーサネット・データ・レートが、秒当り10ギガビットまで増加すると、全TCP/IPプロトコル処理は、専用のハードウェアにおろされなければならない。インターネット・チューナ10Gは、一連のステートマシンとして、ARP, RARP, IP ホストルーティングのような関連プロトコルとともに、TCP/IPをインプリメントしている。インターネット・チューナ10Gコアは、インターネット・チューナ10Gネットワーク・スタックの特徴を拡張するためにプロセッサを用いることができるような接続が設けられるが、なんらのプロセッサもソフトウェアも用いない。
【００４４】
図14を参照すると、インターネット・チューナ10G 1404 コアの使用の一例は、ギガビット・イーサネット・アダプタ・カード用に意図されたギガビット・イーサネット・アダプタ・チップにある。応用の一例として、ギガビット・イーサネット・アダプタは、サーバ内にプラグインされ、TCP/UDP/IPパケットあるいは他のパケットに、同様のプロトコルを用いて、固有の処理を行う。
【００４５】
インターネット・チューナ10Gコア 1404は、単一のギガビット・イーサネット・アダプタ・チップ内で、内部プロセッサ1406、システムペリフェラル1412、システムバスインターフェイス1414と連結している。このギガビット・イーサネット・アダプタ・チップは、イーサネット物理(PHY)デバイス1418、コンフィギュレーションEEPROM（コンフィギュレータ） 1410、インターネット・チューナ10Gコア 1404のためのオプションの外部メモリ1400と連結しており、ギガビット・イーサネット・アダプタを形成している。内部プロセッサ用のメモリ（ROMおよびRAMとも）は、ギガビット・イーサネット・アダプタ・チップ上（内部）にあってもよいし、ギガビット・イーサネット・アダプタ・チップの外側（外部）にあってもよい。
【００４６】
図15に関すると、インターネット・チューナ10G 1546は、例えば、ネットワークに配されたデバイス（記憶ユニット、プリンタ、カメラ等々のような）へのインターフェイスとして用いることができる。そのような応用において、カスタム・アプリケーション・ソケット1542が、第6層および第7層のプロトコルを処理し、そして、応用に特定のデータ移動を容易にするために、インターネット・チューナ10G 1546に付加されてもよい。このタイプの使用の例としては、ストリーミングメディアのためのカスタム・データ・パス、バルクデータ移動、および、iSCSI, RDMA, FCIPのようなプロトコルのためのサポートが、含まれる。
【００４７】
インターネット・チューナ10Gは、秒当り10ギガビットレートで処理する回線速度をサポートするように設計されているが、それと同じアーキテクチャおよび論理を、より低い速度においても同様に用いることができる。そのような場合には、イーサネット・メディア・アクセス・コントローラ(MAC)およびPHYのみが異なるのみである。より低い回線速度でインターネット・チューナ10Gアーキテクチャを用いる利点には、より低い電力消費が含まれる。
【００４８】
高速バンド幅に対する課題は、無線回線速度でTCP/IPパケットを処理することにある。秒当り1ギガビットレベルで始めると、TCP/IPの処理オーバーヘッドがシステムの主要な消耗源となり、したがって、他の解が必要なことは、明らかである。インターネット・チューナ10Gは、種々のアーキテクチャ・インプリメンテーションによって、これに取り組む。それらには、以下の特徴が含まれる。
【００４９】
・  入ってくるデータのストリーム処理
・  広いデータ・パス
・  プロトコル・ステートマシンの並列実行
・  共有リソースのインテリジェント・スケジューリング
・  最小のメモリコピー
インターネット・チューナ10Gは、インターネット・チューナ中にインプリメントされた、それらのアーキテクチャ概念を取り付けており、上述のエンハンスメントを付加している。
【００５０】
以下のセクションは、さまざまなデータ・パスおよび転送タイプにおける動作の理論の説明とともに、システムのブロックレベルの記述を提供する。
【００５１】
ギガビット・イーサネット・アダプタ・チップは、インターネット・チューナ10G、内部プロセッサ、および、他の部品を具備する。ネットワーク・スタックが、プロトコル処理の大多数を遂行する。
【００５２】
図16を参照すると、ギガビット・イーサネット・アダプタ・チップのブロックレベルダイアグラムが、示されている。
【００５３】
このセクションは、内部プロセッサの使用の概要を提供する。ギガビット・イーサネット・アダプタ・チップは、プログラム組み込みを可能にすることが要求されるところでは、プログラム組み込みを可能にするために内部プロセッサ1688を利用する。この内部プロセッサ1688は、周辺装置にも配されている。通常の動作条件では、内部プロセッサ1688は、ネットワーク・スタック1610を制御する。
【００５４】
内部プロセッサ1688は、メモリ（RAM、ROM、あるいは、その両方のいずれでも）の可変量にアクセスする能力を持っている。メモリは、インターネット・チューナ10Gチップと同じチップ上にあってもよいし、外部メモリであってもよい。内部プロセッサ周辺装置の全て、即ち、RAM、ROM、および、インターネット・チューナ10Gネットワーク・スタック1610は、内部プロセッサメモリのアドレス空間の内部に位置している。内部プロセッサRAM空間のうちの64キロバイトが、インターネット・チューナ10Gネットワーク・スタック1610に対するユニファイド・メモリとして構成されている。このユニファイド・メモリは、例外ハンドリングのために、また、内部プロセッサが、インターネット・チューナ10Gネットワーク・スタック1610によって送信または受信されるロー・イーサネット・パケットを組み立てるために、用いられる。このセクションは、インターネット・チューナ10Gアーキテクチャの概要を提供し、次いで、それに続くセクションは、個々のインターネット・チューナ10Gモジュールを記述する。インターネット・チューナ10Gは、上述のインターネット・チューナの元々のハードウェア・プロトコル処理のアイディアを採用しており、インターネット・チューナ10Gが、秒当り10ギガビット、および、それ以上のデータレートをハンドルすることをイネーブルにするエンハンスメントを付加している。
【００５５】
元々のインターネット・チューナに対する最も重要な付加は、増大されたデータ・パス幅、ステートマシンの並列実行、および、共有ハードウェアリソースのインテリジェント・スケジューリングである。さらに、インターネット・チューナ10Gは、RARP, ICMP, IGMP、および、iSCSIやRDMAのような新しい、より上位のプロトコルに対する直接のサポートを含めて、元々のインターネット・チューナよりも、プロトコルに対するさらなるサポートを供給する。
【００５６】
以下のセクションは、インターネット・チューナ10Gの基本的な構成要素の概要を提供する。その後のセクションは、インターネット・チューナ10Gの構成要素の全ての詳細な記述を提供する。
【００５７】
このセクションは、ソケット初期化を記述する。インターネット・チューナ10Gへの／からの任意のデータ転送に先立って、ソケットは、初期化されなければならない。ソケット初期化は、コマンド・ブロックを用いることによって遂行してもよいし、ソケットレジスタを直接プログラムすることによって遂行してもよい。全てのソケットに対してプログラムされなければならないパラメータには、送信先IPアドレス、送信先ポート番号、および、コネクションタイプ（TCPかUDPか、および、サーバかクライアントか）が含まれる。オプションのパラメータには、クォリティ・オブ・サービス(QoS)レベル、送信元ポート、タイム・ツー・ライブ(TTL)、および、タイプ・オブ・サービス(ToS)のセッティングが、含まれる。適切なパラメータがプログラムされると、そのソケットは、アクティブにされてもよいし、必要であれば、パケットを送受信するための接続が、確立されてもよい。UDPソケットの場合には、パケットは、即座に送信あるいは受信されてもよい。TCPクライアントにおいては、接続が、最初に確立されなければならない。TCPサーバにおいては、SYNパケットが、クライアントから受信されなければならず、そして、その後、接続が、確立されなければならない。
【００５８】
このセクションは、ホスト・コンピュータに接続されたインターネット・チューナ10Gによるパケットの送信の概要を提供する。
【００５９】
図17に関すると、インターネット・チューナ10Gがパケットを送信するために、ホスト・コンピュータ上を走るソフトウェア・アプリケーションが、最初に、インターネット・チューナ10Gに接続されているソケット・バッファ・メモリ1742内のソケット・バッファに、そのパケット・データを書き込む。そのパケット・データは、ソケット・バッファ・メモリ1742内のソケット・バッファに書き込まれているパケット・データとして察知され（あるいは、モニタされ）、そのパケット・データの部分チェックサムが、保存される。この部分チェックサムの計算は、さらなるチェックサムの計算に対する開始シードとして用いられる。この部分チェックサムの計算は、パケットの送信に先立って、再度パケット・データを読み出す必要を取り除く。ソフトウェア・アプリケーションは、32ビット単位あるいは64ビット単位で、ソケット・バッファ・メモリ内のソケット・バッファにパケット・データを書き込むことができる。32ビット単位あるいは64ビット単位のパケット・データのどのビットが有効であるかを指示する信号が、用いられる。
【００６０】
ソフトウェア・アプリケーションが、ソケット・バッファ・メモリ1742内のソケット・バッファにパケットを書き込むと、ソフトウェア・アプリケーションは、インターネット・チューナ10Gに、送信コマンドを配給することができる。ソフトウェア・アプリケーションが、送信コマンドを配給すると、TCPモジュール1752が、パケット長を計算し、TCPチェックサムおよびIPチェックサムを計算し、そして、TCPヘッダおよびIPヘッダを組み立てる。TCP/UDPモジュールが、次に、それらのヘッダを、ソケット・バッファ1746内のパケットのデータ部の前面に挿入して、送信の準備のできた完全なパケットを形成する。次いで、TCPモジュール1752が、送信優先順位キューに基づいて、ソケット・バッファ・メモリ内のその完全なパケットに、ソケットQoSレベルといっしょに、ポインタを置く。
【００６１】
送信スケジューラ・モジュールは、送信優先順位キューをモニタしている。送信スケジューラ・モジュールは、送信を待っているパケットを持つ全てのソケットを調べて、最も高いソケットQoSレベルを備えたパケットを選択する。送信スケジューラ・モジュールは、TCP, UDP, ICMP, ARP, RARP、および、ロー・イーサネット・パケットを含む、送信を待っている全てのパケットを調べる。送信スケジューラ・モジュールは、最小バンド幅アルゴリズム(minimum-bandwidth algorithm)を用いて、どのソケットも、完全にはスターブされないことを確保する（後のセクションにおいて、最小バンド幅アルゴリズムが、記述される）。送信スケジューラ・モジュールは、送信のための1つのパケットを選択して、そのパケットのソケット・バッファ・メモリ・ポインタを、MAC TXインターフェイス・モジュールに渡す。MAC TXインターフェイス・モジュールは、そのソケット・バッファ・メモリ・ポインタを用いて、ソケット・バッファ・メモリからそのパケットを読み出して、そのパケットをMACモジュール1770に渡す。パケットが再送信の必要のある（イーサネット衝突のため、あるいは、他の理由のために）場合には、そのパケットは、MAC TXインターフェイス・モジュール・スニファ・バッファ1764にも記憶される。パケットが、ソケット・バッファ・メモリから送信されると、そのソケット・バッファ・メモリは、解放される。有効な送信ステータス信号が、MACモジュールから受信されると、MAC TXインターフェイス・モジュール・スニファ・バッファは、クリアされ、MACモジュールは、次のパケットを送信することができる。無効な送信ステータスが、MACモジュールから受信されると、その後、MAC TXインターフェイス・モジュール・スニファ・バッファに記憶された最後のパケットが、再送信される。
【００６２】
以下のセクションは、インターネット・チューナ10Gによるパケットの受信の概要を提供する。
【００６３】
1つのパケットが、MACモジュールから受信されると、MACアドレス・フィルータ・モジュールが、イーサネット・ヘッダを調べて、そのパケットがハードウェア・インターフェイスに向けて送信されているかどうかを決定する。MACアドレス・フィルータ・モジュールは、ユニ・キャスト・アドレス、プログラムされたマスクの範囲内に収まるユニ・キャスト・アドレス、ブロードキャスト（一斉同報通信）アドレス、あるいは、マルチ・キャスト・アドレスを受信するようにプログラムできる。
【００６４】
受信されたパケットが、ARPパケットあるいはRARPパケットであれば、その受信されたパケットは、ARPモジュール1762に渡される。ARPモジュールは、受信されたパケットのOPフィールドを調べて、受信されたパケットがARP応答か（OPフィールドが1）、ARP要求か（OPフィールドが2）、RARP要求か（OPフィールドが3）、RARP応答か（OPフィールドが4）を決定する。受信されたパケットが、ARP要求パケットまたはRARP要求パケットであれば、ネットワーク上のあるデバイスが、そのARP要求パケットまたはRARP要求パケットに指定されているターゲットIPアドレスを持つネットワーク・デバイスからの情報を要求している。ARP要求パケットまたはRARP要求パケットのターゲットIPアドレスが、インターネット・チューナ10Gに属していれば、ARPモジュールが、ARP/RARP応答モジュールに、応答要求を渡す。受信されたパケットが、ARP応答パケットまたはRARP応答パケットであれば、受信されたパケットからの送り手のイーサネット・アドレスおよび受信されたパケットからの送り手のIPアドレスが、ARP/RARP要求モジュールに渡される。
【００６５】
受信されたパケットが、IPパケットであれば、そのパケットは、IPモジュールに渡される。IPモジュールは、受信されたIPパケットのIPヘッダの最初の4ビットにある4ビットIPバージョン・フィールドを調べて、そのパケットが、どのようにハンドルされなければならないかを決定する。パケットは、１度に64ビットずつ処理されるから、最初の64ビットが受信されただけでは、IPモジュールは、IPバージョン（IPv4かIPv6か）に関して、何らの想定もなすことができない。IPパケットの最初の64ビットが受信され、そして、処理されたときに、IPバージョンが、既知となる。この時点で、IPモジュールは、不用のIPバージョンデコードを中止し、そのIPバージョンデコーダをデフォルト状態にリセットする。
【００６６】
IPバージョンが既知になれば、IPモジュールは、IPヘッダの8ビット・プロトコル・フィールドをデコードする。デコードされたプロトコルに応じて、受信されたIPパケットが、さらなる処理のために、適切なモジュールに送られる。専用ハードウェア回路によって現在、直接的にサポートされているプロトコルには、TCP, UDP, ICMPが含まれる。
【００６７】
インターネット・チューナ10Gの現在のバージョンでは、各ICMPエコー要求パケットが、専用ハードウェアによって直接的にハンドルされる。受信されたパケットが、ICMPエコー要求パケットであれば、そのICMPエコー要求パケットは、記憶され、そして、通知が、ICMP応答モジュールに渡される。ICMP応答モジュールは、ICMPエコー要求パケットのICMPコード・フィールドを、ICMPエコー応答パケットに対応する値に変更し、ICMPエコー応答パケットチェックサムを調整し、そして、送信のためにICMPエコー応答パケットをスケジュール化する。
【００６８】
インターネット・チューナ10Gの現在のバージョンでは、各ICMPリダイレクト・パケットが、専用ハードウェアによって直接的にハンドルされる。受信されたパケットが、ICMPリダイレクト・パケットであれば、そのICMPリダイレクト・パケットは、構文解析され、そして、IPルートテーブルの適切なエントリが更新できるように、情報がIPルータ・モジュールに送られる。
【００６９】
他のタイプのICMPパケット、IGMPパケット、あるいは、専用ハードウェアによって直接的にサポートされていない他のプロトコルに対応するパケットは、内部プロセッサがそれらをハンドルできるIPバッファにコピーされる。タイム・クリティカル・データを携行しないプロトコルは、しばしば、ハウス・キーピング・プロトコルと呼ばれる。どのハウス・キーピング・プロトコルが専用ハードウェア回路によって処理されるかの決定は、インターネット・チューナ10Gのインプリメンテーションに依存する。インターネット・チューナ10Gのアーキテクチャは、さまざまなインプリメンテーションが、ハウス・キーピング・プロトコルを処理するために、専用ハードウェア回路と内部プロセッサとのどちらをも用いることができるほどに、十分にフレキシブルである。
【００７０】
受信されたパケットが、オ−プン・ソケットに対応するTCPパケットである場合には、そのソケット情報が構文解析され、そのソケットの状態情報が検索され、そして、受信されたTCPパケットのタイプに基づいて、そのソケット状態情報が更新される。受信されたTCPパケットのデータ・セクション（それが当てはまる場合には）が、そのソケットの受信データ・バッファに記憶される。ACKパケットが、TCPパケットを受信した結果として生成される必要のある場合には、TCP状態モジュールが、ACKパケットを生成し、そして、そのACKパケットを、送信のためにスケジュール化する。オ−プン・ソケットに対応していないTCPパケットが受信された場合には、TCP状態モジュールが、RSTパケットを生成し、そして、そのRSTパケットが、送信のためにスケジュール化される。
【００７１】
受信されたパケットが、UDPパケットである場合には、そのソケット情報が構文解析され、そのUDPパケット・データが、そのソケットの受信データ・バッファに記憶される。オ−プン・ソケットが、そのUDPパケットに全く存在しない場合には、そのUDPパケットは黙って放棄され、そして、ICMP送信先到達不能あるいは他のメッセージが生成される。
【００７２】
インターネット・チューナ10Gネットワーク・スタックは、内部プロセッサに対する周辺装置であるようにみえる。インターネット・チューナ10Gネットワーク・スタックに対する基準アドレスは、レジスタを介してプログラムされる。全てのレジスタアドレスは、この基準アドレス・レジスタに対するオフセットである。このアーキテクチャは、内部プロセッサが、インターネット・チューナ10Gネットワーク・スタックを、内部プロセッサメモリあるいはI/O空間の任意の位置に置くことを可能にする。
【００７３】
以下のセクションは、インターネット・チューナ10Gの構成要素の詳細な記述を提供する。
【００７４】
このセクションは、イーサネット・インターフェイス・モジュール1766を詳述する。イーサネット・インターフェイス・モジュールは、イーサネットMACインターフェイス・モジュール1770、ARPモジュール1762、および、IPモジュール1758と通信する。イーサネット・インターフェイス・モジュールは、受信パスおよび送信パスの両方のデータをハンドルする。
【００７５】
送信パス上では、イーサネット・インターフェイス・モジュールは、以下のことに責を負っている。
【００７６】
・  送信のためにパケットをスケジュール化すること。
【００７７】
・  送信のためにDMAチャネルをセットアップすること。
【００７８】
・  イーサネットMACインターフェイス送信信号をハンドルすること。
【００７９】
受信パス上では、イーサネット・インターフェイス・モジュールは、以下のことに責を負っている。
【００８０】
・  イーサネット・ヘッダを構文解析すること。
・  アドレスフィルタセッティングに基づいて、受信されたパケットを受け入れるべきか排除すべきかを決定すること。
・  受信されたパケットのフレーム・ヘッダのイーサネット・フレームタイプ・フィールドに基づいて、適切なプロトコル・モジュールをイネーブルにすること。
・  受信されたパケットのデータ・セクションが、64ビット境界から始まるように、受信されたパケット・データを境界整列させること。
【００８１】
このセクションは、送信スケジューラ・モジュールを扱う。送信スケジューラ・モジュールは、ARPモジュール, IPモジュール, TCPモジュール、および、ロー送信モジュールからパケット送信要求を受け取り、どのパケットが次に送信されるべきかを決定することに責を負っている。送信スケジューラ・モジュールは、各パケット送信要求のQoSレベルを比較することによって、次に送信されるべきパケットを決定する。QoSレベルとともに、各パケット送信要求には、そのパケットの開始メモリ・ブロックに対するポインタが、パケット長とともに含まれている。送信スケジューラ・モジュールは、コネクション型に属するパケットの送信に優先順位をつけるようにプログラムされる適応性を持っている。例えば、TCPモジュールからのQoSレベル5を持つパケット送信要求は、IPモジュールからのQoSレベル5を持つパケット送信要求よりも高い優先順位を持つようにすることができる。以下は、パケット送信優先順位を決定するために送信スケジューラ・モジュールによって用いられるアルゴリズムである。
【００８２】
・  何らのパケットチャネルも、スターブされた状態に達していないことを確かめるためにチェックする。これは、送信スケジューラ・モジュールがQoSレベルに応じないで、パケットを送信する以前に、そのパケットが見過ごされる回数に対応する、プログラムに組めるレベル（パケット型にしたがって、あるいは、コネクション型にしたがって）である。2つ以上のパケットが、同時にスターブされた状態に達している場合には、より高いQoSレベルを持つチャネルに属するパケットが、優先される。より低いQoSレベルを持つチャネルに属するパケットは、次に送信されるようにスケジュール化される。2つ以上のパケットが、同一のQoSレベルを持っている場合には、それらは、次の順番；TCPまたはUDPパケット、その次にARPパケット、その次にIPパケット、その次にロー・イーサネット・パケット、にしたがって、順に送り出される。
【００８３】
・  スターブされた状態のパケットを持つチャネルが、何ら存在しない場合には、最も高くQoSレベルとチャネル重みとが結合されたチャネルが、送信される。
【００８４】
・  ただ1つのチャネルしか、送信されるべき1つのパケットを持たない場合には、そのパケットは、直ちに送信される。
【００８５】
1つのチャネルに属する1つのパケットが、送信のために選択されると、そのチャネルのメモリ・ポインタ、パケット長、および、パケット・タイプが、DMAエンジン・モジュールに転送される。転送が完了すると、そのDMAエンジン・モジュールは、送信スケジューラ・モジュールに信号を送る。この時点で、送信スケジューラ・モジュールは、DMAエンジン・モジュールに、次のパケットのパラメータを転送する。
【００８６】
このセクションは、DMAエンジン・モジュールについて記述する。送信スケジューラ・モジュールは、DMAエンジン・モジュールに、パケットパラメータ情報を渡す。パケットパラメータ情報には、パケット・タイプ、パケット長、および、パケット・データの開始に対するメモリ・ポインタが含まれる。DMAエンジン・モジュールは、パケット長を用いて、どれくらい多くのデータが、メモリ・バッファから転送されるかを決定する。パケット・タイプは、DMAエンジン・モジュールに、どのメモリ・バッファからパケット・データを検索するかを指示し、また、メモリ・ポインタは、どこからパケット・データの読み出しを開始するかを指示する。1つのパケットが、複数のメモリ・ブロックに渡ることができるから、DMAエンジン・モジュールは、そのチャネルのパケットに用いられているメモリ・ブロックの各々が、どのくらいの大きさであるかを理解する必要がある。DMAエンジン・モジュールは、メモリ・コントローラから、一度にデータ64ビットずつを受け取り、送信器インターフェイス・モジュールに、一度にデータ64ビットずつを渡す。
【００８７】
このセクションは、送信器インターフェイス・モジュールを扱う。送信器インターフェイス・モジュールは、DMAエンジン・モジュールからの出力を受け取り、イーサネットMACインターフェイス・モジュールに対する信号を生成する。64ビット・データ・バスが、DMAエンジン・モジュールとイーサネットMACインターフェイス・モジュールとを接続する。
【００８８】
このセクションは、受信器インターフェイス・モジュールを扱う。受信器インターフェイス・モジュールは、イーサネットMACインターフェイス・モジュールとインターフェイスしている。受信器インターフェイス・モジュールは、イーサネット・フレームを受け取り、そして、それらを、状態カウント情報とともに、アドレス・フィルータ・モジュールおよびイーサネット・フレームタイプ・パーザ（構文解析プログラム）モジュールに提出する。
【００８９】
このセクションは、アドレス・フィルータ・モジュールおよびイーサネット・フレーム・タイプ・パーザ・モジュールを扱う。アドレス・フィルータ・モジュールおよびイーサネット・タイプ・パーザ・モジュールは、イーサネット・ヘッダを構文解析し、以下の2つの機能を遂行する。
【００９０】
・  そのイーサネット・フレームが、インターネット・チューナ10Gに属するハードウェア・インターフェイスに対するものであるかどうかを決定する。
・  イーサネット・フレームタイプを構文解析して、イーサネット・フレームの残りを渡す場所を決定する。
アドレス・フィルータ・モジュールおよびイーサネット・フレーム・タイプ・パーザ・モジュールは、以下のフィルタオプションを用いてプログラムできる。
・  プログラムされたユニ・キャスト・アドレスを受け入れる。
・  ブロードキャスト・アドレスを受け入れる。
・  マルチ・キャスト・アドレスを受け入れる。
・  ネットマスクによって指定される範囲内のアドレスを受け入れる。
・  無差別モード（全てのイーサネット・フレームを受け入れる）。
【００９１】
これらのフィルタオプションを制御するパラメータは、ホスト・システムのソフトウェアによって設定される。
【００９２】
以下のイーサネット・フレームタイプが、イーサネット・フレーム・タイプ・パーザ・モジュールによってサポートされている。
【００９３】
・  イーサネット・フレームタイプ = 0x8000を持つIPv4パケット
・  イーサネット・フレームタイプ = 0x86DDを持つIPv6パケット
・  イーサネット・フレームタイプ = 0x0806を持つARPパケット
・  イーサネット・フレームタイプ = 0x8035を持つRARPパケット
イーサネット・フレームタイプ・パーザは、他のイーサネット・フレームタイプを、例外ハンドラ・モジュールに渡す。
【００９４】
イーサネット・フレームタイプ・パーザは、また、802.2/802.3フォーマット・イーサネット・フレームとDIXフォーマット・イーサネット・フレームとの両方もハンドルする。802.2/802.3フォーマット・イーサネット・フレームでは、DIXフォーマット・イーサネット・フレームに存在するイーサネット・フレームタイプ・フィールドに替わって、長さパラメータが存在する。802.2/802.3イーサネット・フレームは、イーサネット・フレームタイプ・フィールドの値が、1500（10進）以下になったときに検出される。この事例が検出されると、イーサネット・フレームタイプ・パーザは、ARPモジュールとIP受信モジュールとの両方に、そのイーサネット・フレームに含まれるパケットを送るとともに、以後の各モジュールが、パケットがそのモジュール用ではないこともあるということを認識しながら、パケットをデコードしなければならないということを知るような信号をアサートする（アクテイブにする）。0x8000と0x86DDとのどちらのイーサネット・フレームタイプが受信されても、IPパケット信号がアサートされる。そうすると、IPヘッダ・パーザ・モジュールは、そのパケットがIPv4パケットであるか、IPv6パケットであるかを決定する。IPヘッダのプロトコル・バージョン・フィールドは、インターネット・チューナ10Gがパケットのプロトコルを決定する場合には、イーサネットパケット・タイプ・フィールドに優先する。
【００９５】
このセクションは、データ・アライナ・モジュールを扱う。データ・アライナ・モジュールは、データ・アライナ・モジュールに続くプロトコル処理モジュールのためにデータ・バイトを境界整列させる。データ・アライナ・モジュールは、イーサネット・ヘッダが64ビットのちょうど倍数でないために必要とされる。VLAN（バーチャルLAN）タグが、イーサネット・ヘッダに存在するか否かに依存して、データライナが、イーサネット・ヘッダに64ビット・データを再整列させて、イーサネット・ヘッダが、データ・アライナ・モジュールに続くプロトコル処理モジュールに対して長さのそろったMSBで現れるようにする。そうすると、イーサネット・フレームのデータ・セクションが、常に、ちょうど64ビット境界に境界整列する。データ・アライナ・モジュールは、また、データ・アライナ・モジュールに続くプロトコル処理モジュールに対する準備信号も生成する。
【００９６】
このセクションは、ARPモジュール1762およびARPキャッシュモジュール1750について記述する。ARPモジュールは、RARPプロトコルもサポートするが、ARPキャッシュを含まない。パケットを送信できる各モジュールは、それに先立ってARPキャッシュに照会を行うから、ARPキャッシュは、ARPモジュールから分離しておかれる。ARPモジュールは、受信されたイーサネット・フレームタイプに基づいて、ARPキャッシュに更新を送ることができる。
【００９７】
ARPモジュールの能力は、以下の通りである。
【００９８】
・  ARP応答を生成することによってARP要求に応えることができる。
・  ARPキャッシュに応えてARP要求を生成することができる。
・  複数のIPアドレス（マルチホームホストの場合に、あるいは、ARPプロキシの機能を遂行するために用いられる）にARP応答を提供することができる。
・  ターゲットされた（ユニキャスト）ARP要求を生成することができる。
・  不法なイーサネット・アドレスおよび不法なIPアドレスを取り除く。
・  整列されたARPデータを内部プロセッサに渡す。
・  gratuitous ARPを遂行することができる。
・  内部プロセッサは、ARPデータを例外ハンドラにコピーして、自動的なARP応答の生成を回避することができる。
・  内部プロセッサは、カスタムARP応答を生成することができる（回避モードにおいて）。
【００９９】
ネットワーク状態に依存してのARPパケットの可変優先順位。
【０１００】
RARPモジュールの能力は、以下の通りである。
【０１０１】
・  IPアドレスを要求する。
・  特定のIPアドレスを要求する。
・  はいってくるRARP要求が、例外ハンドラに渡される。
・  イレギュラーRARP応答（ARP OPフィールドを持つRARPイーサネット・フレームタイプ、または、その逆）をハンドルする。
・  整列したRARPデータを内部プロセッサに渡す。
・  内部プロセッサは、カスタムRARP要求および応答を生成することができる。
【０１０２】
ARPキャッシュモジュールの能力は、以下のようである。
【０１０３】
・  動的なARPテーブルサイズ。
・  自動的に更新されるARPエントリ情報。
・  送り手のハードウェアアドレスが変化したときに、ステータス・メッセージを生成する。
・  ARPデータを無差別に収集できる。
・  ARPモジュールを介するARP要求能力。
・  静的なARPエントリをサポートする。
・  静的なARPエントリを、動的なARPデータによって置き換えることをイネーブルにするためのオプション。
・  ARPプロキシをサポートする。
・  ARPキャッシュ・エントリに対して構成可能な終了時。
【０１０４】
以下のセクションは、ARPモジュールの動作の理論を説明する。
【０１０５】
このセクションは、ARPモジュールによるパケットの受信および構文解析を扱う。図18を参照すると、ARPモジュールは、ARPパケットとRARPパケットとの両方を処理する。ARPモジュールは、イーサネット受信モジュール1896から受信される、データに利用可能な信号を待っている。データに利用可能な信号が受信されると、入ってくるイーサネット・フレームのイーサネット・フレームタイプが、チェックされる。そのイーサネット・フレームタイプが、ARPまたはRARPに対応していなければ、ARPモジュールは、そのイーサネット・フレームに含まれているパケットを無視する。そうでなければ（対応していれば）、ARPモジュールは、そのイーサネット・フレームに含まれているパケット1898の構文解析を始める。
【０１０６】
パケットは、イーサネット・インターフェイス・モジュールから、64ビット・ワードで読み出される。28バイトARPパケット（イーサネット・ヘッダを除いて）は、3.5個の64ビット・ワードを占める。
【０１０７】
ARPパケットの最初の64ビット・ワードの最初の48ビットには、ハードウェアアドレスのタイプ、プロトコルアドレスのタイプ、バイト単位でのハードウェアアドレス長、および、バイト単位でのプロトコルアドレス長が、含まれる。ARPパケットのアドレスタイプ、および、長さフィールドの値が、イーサネット上でIPv4におけるARP要求に対して期待される値と比較される。それらの値が一致しなければ、そのARPパケットは、例外ハンドラ1894に渡される。そうでない場合には（一致していれば）、ARPモジュールが、ARPパケットの構文解析を続ける。ARPパケットの最初の64ビット・ワードの最後の16ビットには、ARP OPフィールドが、含まれる。ARPモジュールは、ARP OPフィールドを記憶し、そのARP OPフィールドが有効であるかどうかを確かめるためにチェックする。有効なARPパケットは、1, 2, 3または4に等しいARP OPフィールドを持つ。ARP OPフィールドが有効でない場合には、そのARPパケットは、例外ハンドラに渡される。そうでない場合には、ARPモジュールは、ARPパケットの構文解析を続ける。
【０１０８】
ARPパケットの2番目の64ビット・ワードには、送り手ハードウェアアドレス、および、送り手プロトコルアドレスの半分が含まれなくてはならない。ARPモジュールは、、送り手ハードウェアアドレス・レジスタに、ARPパケットの2番目の64ビット・ワードの最初の48ビットを記憶する。次に、ARPモジュールは、送り手ハードウェアアドレスが有効かどうかをチェックする。送り手ハードウェアアドレスは、それがインターフェイスのイーサネット・アドレスと同様であるか、あるいは、それがブロードキャスト・アドレスであれば、無効である。送り手ハードウェアアドレスが無効であれば、そのパケットは、破棄される。ARPパケットの2番目の64ビット・ワードの最後の16ビットは、送り手プロトコルアドレス・レジスタの上部半分に記憶される。
【０１０９】
ARPパケットの3番目の64ビット・ワードには、送り手プロトコルアドレスの後半が含まれており、また、ターゲットハードウェアアドレスも含まれている。ARPモジュールは、ARPパケットの3番目の64ビット・ワードの最初の16ビットを、送り手プロトコルアドレス・レジスタの下部の16ビットに記憶し、そして、送り手プロトコルアドレスが有効なことをチェックする。送り手プロトコルアドレスは、それがハードウェア・インターフェイスのIPアドレスと同様であるか、あるいは、その送り手プロトコルアドレスがブロードキャスト・アドレスであれば、無効である。送り手プロトコルアドレスが無効であれば、ARPモジュールは、そのARPパケットを破棄する。
【０１１０】
ARPモジュールは、ターゲットハードウェアアドレスとインターフェイスのイーサネット・アドレスとを比較する。ターゲットハードウェアアドレスが、そのインターフェイスに属するイーサネット・アドレスと一致しなければ、ARPモジュールは、そのARPパケットを破棄する。ターゲットハードウェアアドレスが、インターネット・チューナ10Gのインターフェイスのイーサネット・アドレスと同様であれば、ARPモジュールは、そのARPパケットの処理を続ける。
【０１１１】
ARPパケットの4番目（最後）の64ビット・ワードの最初の32ビットには、ターゲットプロトコルアドレスが含まれている。ARPパケットは、長さが、3.5ワード即ち28バイト（224ビット）でなければならないので、この4番目の64ビット・ワードの最初の32ビットだけしか有効でない。ARPモジュールは、ターゲットプロトコルアドレスを、ターゲットプロトコルアドレス・レジスタに記憶する。ARPモジュールは、ターゲットプロトコルアドレスと、インターフェイスのIPアドレスとを比較する。ターゲットプロトコルアドレスが、インターフェイスのIPアドレスと一致しなければ、ARPモジュールは、そのARPパケットを破棄する。ターゲットプロトコルアドレスがインターフェイスのIPアドレスに一致し、また、ARPパケットがARP要求であれば、ARPモジュールは、ARP応答を生成する。ターゲットプロトコルアドレスがインターフェイスのIPアドレスに一致し、また、ARPパケットがRARP応答であれば、ARPモジュールは、割り当てられたIPアドレスを、RARPハンドラ・モジュールに渡す。
【０１１２】
ターゲットプロトコルアドレスが、インターネット・チューナ10GのインターフェイスのIPアドレスと一致すれば、ARPモジュールは、いずれもARPパケットから受け取られた送り手イーサネット・アドレスと送り手IPアドレスとを、ARPキャッシュモジュールに渡す。
【０１１３】
このセクションは、ARPモジュールによるARPパケットの送信を扱う。ARPモジュールは、3つのソース；ARPキャッシュモジュール（ARP要求パケットおよびARPプロキシ応答のためのソース）、および、ARP応答FIFOを介してARPパーザから内部的に（ARP応答パケットのためのソース）、および、内部プロセッサから(カスタムARPパケットおよび全てのRARPパケットのためのソース)、からARPパケットを送信するための要求を受け取ることができる。ARPパケットおよびRARPパケットの複数のソースをハンドルするために、ARP送信スケジューラ1890は、ARPパケットおよびRARPパケットの送信をスケジュール化するために、送信優先順位キューを用いる。
【０１１４】
送信要求は、2つ以上のソースが送信を望むときを除いて、先着順にARP送信優先順位キューに置かれる。その場合（2つ以上のソースが送信を望むとき）には、ARP送信優先順位キューに置かれる次の送信要求は、送信要求の優先順位に依存する。RARP要求送信要求が、一般に最も高い優先順位を持ち、その後に、ARP要求送信要求が続く。ARP応答送信要求が、最も低い送信優先順位を持っている。
【０１１５】
ARP応答送信要求が最も高い送信優先順位を持つ1つの状況がある。これは、ARP応答FIFO 1892が一杯なときに起こる。ARP応答FIFOが一杯なとき、入ってくるARP要求送信要求が無視される。これが起こると、ARP応答送信要求は、ARP要求の再送信を余儀なくされることを回避するために、最も高い送信優先順位を与えられる。
【０１１６】
ARP送信優先順位キューが一杯になると、ARP送信スケジューラ1890は、1つ以上の送信要求が完了するまで(そして、その送信要求がARP送信キューから取り除かれてしまうまで)、さらなる送信要求を受け入れない。ARPモジュールが、一杯になったARP送信キューを検出すると、ARPモジュールは、イーサネット送信スケジューラに、送信優先順位を増やすことを要求する。
【０１１７】
イーサネット送信スケジューラが、ARPモジュールが送信することを許可すると、ARPパケットあるいはRARPパケットが、送信されるARPパケットのタイプに依存して生成される。ARP OPフィールドが、ARPパケット・タイプを決定する。ARP OPフィールドは、ARP送信優先順位キューに、各送信要求とともに記憶される。
【０１１８】
このセクションは、入ってくるARPパケットの自動的な処理を回避する、ARPモジュールのARP回避モードの動作を扱う。ARPバイパスフラグがセットされ、そして、例外がイネーブルになると、入ってくるARPパケットおよびRARPパケットが、例外ハンドラバッファにコピーされる。次に、内部プロセッサが、例外ハンドラバッファにアクセスし、ARPパケットおよびRARPパケットを処理する。ARPバイパスモード中の場合、内部プロセッサは、ARP送信スケジューラに、ARP応答パケットを要求することができる。出て行くARPパケットおよびRARPパケットにカスタマイズできるフィールドは、送り手プロトコルアドレス、送信元ハードウェアアドレス、ターゲットプロトコルアドレス、および、ARP OPフィールドである。ARPパケットあるいはRARPパケットの他の全てのフィールドは、イーサネット上のIPv4におけるARPパケットおよびRARPパケットに使用される標準値にセットされる。送信元ハードウェアアドレスは、インターネット・チューナ10Gのインターフェイスのイーサネット・アドレスにセットされる。ARPパケットあるいはRARPパケットの他のフィールドを修正することが必要な場合には、内部プロセッサが、ローイーサネット・フレームを生成しなければならない。
【０１１９】
以下のセクションは、ARPキャッシュモジュールの動作について説明する。
【０１２０】
このセクションは、ARPキャッシュモジュール1750によるARPキャッシュへのARPキャッシュ・エントリの付加を扱う。ARPモジュール1762が、インターネット・チューナ10Gのイーサネット・インターフェイスに属するIPアドレスのうちの1つに対するARP要求あるいはARP応答を受け取ったとき、ARPキャッシュモジュールは、ARPキャッシュに動的なARPキャッシュ・エントリを作り出す。内部プロセッサが、ARPキャッシュモジュールがARPキャッシュ・エントリを作り出すことを要求したとき、静的なARPキャッシュ・エントリが、ARPキャッシュに作り出される。内部プロセッサは、また、動的なARPキャッシュ・エントリを作り出すこともできる。動的なARPキャッシュ・エントリがユーザによって指定された時間だけ存在してから、そのARPキャッシュ・エントリは満了し、また、ARPキャッシュモジュールが、そのキャッシュ・エントリを除去する。動的なARPキャッシュ・エントリの満了時間は、通常、5〜15分である。静的なARPキャッシュ・エントリは、一般に満了しない。ARPキャッシュに入力されることになる新しいARPデータは、2つの可能なソース：ARPレジスタを介しての内部プロセッサあるいはARPパケットパーザからARPキャッシュモジュールに渡される。両方の可能なソースが、ARPキャッシュモジュールに、ARPキャッシュ・エントリを加えることを同時に要求したときには、ARPパケットパーザからの動的なARPキャッシュ・エントリ要求の方が、優先順位を持っている。ARPパケットパーザからの動的なARPキャッシュ・エントリ要求は、入ってくるARPパケットをできるだけ速く処理することができるように、また、イーサネット・インターフェイスが動かなくなることを防ぐことができるように、優先順位を与えられる。
【０１２１】
ARPキャッシュモジュールが、新しいARPキャッシュ・エントリのソースを選択すると、ARPキャッシュモジュールは、そのARPキャッシュ・エントリを、ARPモジュールメモリのどこに記憶するかを決定する。ARPキャッシュモジュールは、ARPルックアップテーブル(LUT)を用いて、ARPモジュールメモリ内の1つの位置に1つのIPアドレスをマップする。ARP LUTには、256個のARP LUTエントリが含まれる。各ARP LUTエントリは、広さ16ビットで、ARPコードによって割り付けられたm1メモリの位置に対するポインタ、および、ARPポインタ有効(PV)ビットを含んでいる。ARPキャッシュモジュールは、ARP PVビットを用いて、m1メモリ・ポインタが、ARPキャッシュによって割り付けられたm1メモリ内の有効なアドレスを指しているかどうかを決定する。m1アドレスは、それが、ARPキャッシュモジュールによって割り付けられたm1メモリのブロックの開始アドレスと等しければ、有効である。
【０１２２】
ARPキャッシュモジュールは、ARP LUT内の8ビットインデックスを用いて、ARP LUTからm1メモリ・ポインタを検索する。ARPキャッシュモジュールは、8ビットARP LUTインデックスとして、32ビットIPアドレスの最後の8個を用いる。32ビットIPアドレスの最後の8個を用いる理由は、ローカル・エリア・ネットワークにおいては、最後の8個が、ホスト間で最も大きく変化するIPアドレスの部分であるということである。
【０１２３】
ARPキャッシュモジュールが、ARP LUT中のどのARP LUTエントリを用いるかを決定すると、ARPキャッシュモジュールは、そのARP LUTエントリが、有効なm1メモリ・ポインタを含有しているかどうかを確かめるためにチェックする。そのm1メモリ・ポインタが有効であると、ARPキャッシュモジュールは、そのm1メモリ・ポインタを用いて、ターゲットIPアドレスのためのARP情報を検索するためにm1メモリにアドレス指定する。ARP LUTエントリが、有効なm1メモリ・ポインタを含有していなければ、ARPキャッシュモジュールは、メモリ・アロケータ・モジュールを用いて、m1メモリ・ブロックを割り付ける。ARPキャッシュモジュールが、m1メモリ・ブロックを割り付けると、ARPキャッシュモジュールは、ARP LUTエントリのm1メモリ・ポインタ・フィールドに割り付けられたm1メモリ・ブロックの最初の128ビット・ワードのアドレスを記憶する。
【０１２４】
メモリ・アロケータ・モジュールを用いてm1メモリを割り付け、そして、ARP LUTにm1メモリ・ポインタを記憶した後、ARPキャッシュモジュールは、ARPキャッシュ内のARPデータをm1メモリに記憶する。m1メモリに記憶されたARPデータには、ARPモジュールが、ARPキャッシュルックアップ中に用いるのに必要である送り手IPアドレスが含まれている。ARPキャッシュモジュールは、ARPキャッシュ・エントリの一連のARP制御フィールドを用いる。ARPモジュールは、リトライ（再試行）カウンタARP制御フィールドを用いて、与えられたIPアドレスに対して遂行されるARP要求試みの回数を記録する。ARPモジュールは、エントリタイプ制御フィールドを用いて、ARPキャッシュ・エントリのタイプを指示する（000=動的なエントリ；001=静的なエントリ；010=プロキシエントリ；011=ARPチェックエントリ）。ARPモジュールは、解決フラグ制御フィールドを用いて、現在のARPキャッシュ・エントリのIPアドレスが、イーサネット・アドレスに成功のうちに解決されて（IPアドレスがイーサネット・アドレスに置き換えられて）しまっていることを指示する。ARPモジュールは、有効フラグ制御フィールドを用いて、このARPキャッシュ・エントリが有効なデータを含有することを指示する。一番最初のARP要求が遂行されている間は、ARPキャッシュ・エントリは、有効で、かつ、解決されていないことに注意されたい。ARPモジュールは、ソース制御フィールドを用いて、ARPキャッシュ・エントリのソースを指示する（00=動的に加えられた、01=システム・インターフェイス・モジュール、10=IPルータ・モジュール、11=システム・インターフェイス・モジュールとIPルータ・モジュールとの両方）。ARPキャッシュモジュールは、インターフェイス制御フィールドを用いて、インターネット・チューナ10Gに接続された複数のイーサネット・インターフェイスの使用を可能にする。ARP制御フィールドのセットに続いて、以後のARPキャッシュ・エントリのm1メモリ位置を指すARPキャッシュリンク・アドレスが存在する。ARPキャッシュリンク・アドレスの最上位ビットは、リンク有効フラグである。リンク有効フラグは、現在のARPキャッシュ・エントリに続いて、別のARPキャッシュ・エントリが存在することを指示する。ARPキャッシュ・エントリの最後の2つのフィールドは、IPアドレスが解決されてしまったイーサネット・アドレスおよびタイム・スタンプである。タイム・スタンプは、ARPキャッシュ・エントリがいつ作られたかを指示し、そのARPキャッシュ・エントリが満了したかどうかを決定するために用いられる。
【０１２５】
256以上のホストを備えた、あるいは、複数のサブネットを備えたネットワークでは、異なるIPアドレス間での衝突が、ARP LUTに起きることがある。2つ以上のIPアドレスが、同一のARP LUTインデックスにマップしていると、ARP LUT内での衝突が起きる。この衝突は、2つ以上のホストが、IPアドレスの最後の8個において同じ値を持っていることによる。衝突に対処するために、ARPキャッシュモジュールは、ARP LUT中でエントリをチェーン状につなぐ。
【０１２６】
ARPキャッシュモジュールが、ARP LUTのルックアップを遂行し、そして、有効なARP LUTエントリが、そのスロットに既に存在することが見出されたときには、ARPキャッシュモジュールは、m1メモリによって指し示されているARPエントリを検索する。ARPキャッシュモジュールは、ARPキャッシュ・エントリに記憶されているIPアドレスを検査し、そして、それを、ターゲットIPアドレスと比較する。IPアドレスが一致すれば、ARPキャッシュモジュールは、単純にARPキャッシュ・エントリを更新することができる。しかしながら、アドレスが一致しなければ、ARPキャッシュモジュールは、ARPキャッシュ・エントリのリンク有効フラグおよびリンク・アドレスを検査する。ARPキャッシュ・エントリの最後の16ビットには、同一のLUTエントリにマップする別のARPエントリを指すARPキャッシュリンク・アドレスが含まれている。リンク有効フラグがセットされていると、ARPキャッシュモジュールは、ARPキャッシュリンク・アドレスが指しているARPキャッシュ・エントリを検索する。この第2のARPキャッシュ・エントリのIPアドレスが、ターゲットIPアドレスと比較される。一致すれば、ARPキャッシュモジュールは、ARPキャッシュ・エントリを更新する。そうでない場合には、一致が見出されるか、あるいは、ARPキャッシュモジュールが、リンク有効フラグのセットされていないARPキャッシュ・エントリに到達するまで、ARPキャッシュルックアップ処理が、継続する(ARPキャッシュ・エントリのチェーンのリンクをたどって)。
【０１２７】
ARPキャッシュモジュールが、一連のARPキャッシュ・エントリの端に到達し、そして、一致が見つからなかった場合には、ARPキャッシュモジュールが、新しいARPキャッシュ・エントリを作り出す。新しいARPキャッシュ・エントリを作り出すために、メモリ・コントローラ・モジュールに、m1メモリの割り付けを要求できる。m1メモリの各ブロックは、サイズが128バイトである。m1メモリの各ブロックは、8つのARPキャッシュ・エントリを収容することができる。ARPキャッシュモジュールが、m1メモリ・ブロックを、ARPキャッシュ・エントリで満たしてしまうと、ARPキャッシュモジュールは、メモリ・コントローラ・モジュールに、新しいメモリ・ブロックを要求する。
【０１２８】
ユーザは、静的なARPキャッシュ・エントリを作り出すことができる。静的なARPキャッシュ・エントリは、一般に永続し、満了しない。ユーザは、動的なARPデータが、静的なARPキャッシュ・エントリと置き換わることを可能にするオプションを持っている。言い換えれば、ARPデータが、既に静的なARPキャッシュ・エントリを持っているIPアドレスに対して受信されたときには、その静的なARPキャッシュ・エントリを、受信された動的なARPキャッシュデータで置き換えることができる。この静的なARPキャッシュ・エントリの置き換えの利益は、これが、静的なARPキャッシュ・エントリが陳腐になるのを防ぐことができるということである。ARPキャッシュ・エントリ置き換えは、動的なARPキャッシュデータを、静的なARPキャッシュデータに重ね書きすることを可能にし、それによって、より最新のARPキャッシュに帰着する。ユーザが、IPアドレスのイーサネット・アドレスへのマッピングが不断に繰り返されていると確信している場合（例えば、IPアドレスとルータインターフェイスのイーサネット・アドレスとを記憶している場合)には、このARPキャッシュ・エントリ置き換え能力は、デセーブルにすることもできる。ユーザは、ネットワーク上のARPブロードキャストの数を最小限にするために、静的なARPキャッシュ・エントリを保存することを選ぶこともできる。注：ARPキャッシュプロキシエントリが、動的なARPキャッシュ・エントリによって重ね書きされることは決してない。
【０１２９】
このセクションは、ARPキャッシュにおけるARPキャッシュ・エントリのルックアップを扱う。ARPキャッシュにおけるARPキャッシュ・エントリのルックアップは、ARPエントリの創出に対するそれと同様の処理に従う。図19に関して、ARPキャッシュルックアップは、ARP LUT 1920をチェックして、m1メモリが、与えられたARP LUTエントリに対して割り付けられているかどうかを決定することによって始まる。その通りであれば、ARPキャッシュ・エントリが見つかる（その場合には、ARPキャッシュヒットがある）か、あるいは、アサートされていないリンク有効フラグを持つARPキャッシュ・エントリが見つかる（その場合には、ARPキャッシュミスがある）まで、そのARP LUTエントリに連係したm1メモリが、探索される 1922。
【０１３０】
ARPキャッシュミスが起こった場合には、ARPキャッシュモジュールは、ARP要求を生成する 1934。ARP要求には、ARPキャッシュによって割り付けられるm1メモリ内への新しいARPエントリの創出、および、必要であれば、新しいARP LUTエントリの創出が含まれる。ターゲットIPアドレスが、新しいARPキャッシュ・エントリに記憶され、新しいARPキャッシュ・エントリの解決ビットは、0にセットされ、そして、新しいARPキャッシュ・エントリの有効ビットは、1にセットされる。新しいARPエントリの要求カウンタも、0にセットされる。次に、ARPキャッシュ・エントリが、タイム・スタンプされ、また、ARP要求が、ARPモジュールに渡される。ARP応答が、1秒の間隔の後にARPモジュールから受信されない場合には、ARPキャッシュ・エントリの要求カウンタが、インクリメントされて、別のARP要求が送信される。3度のARP要求が、ARP応答なく送信されたら、ターゲットIPアドレスを解決する試みは、中断される。注：ユーザは、ARP再試行間隔およびARP要求再試行の最大数を指定することができる。
【０１３１】
ARPキャッシュルックアップを要求しているモジュールは、ARPキャッシュミスが起こったとき、ARPキャッシュミスの通知を受ける。このARPキャッシュミスの通知は、内部プロセッサあるいはIPルータ・モジュールに、現在のターゲットIPアドレスに対するARP返答を待つことを決めるか、または、別のIPアドレスのための新しいARPキャッシュルックアップを始めて、現在のIPアドレスを送信優先順位キューの奥（最後）に置くかする機会を与える。この処理は、複数の接続を確立するときに、ARPキャッシュミスの衝撃を最小限にするのに役立つ。
【０１３２】
一致するARPキャッシュ・エントリが、ARPキャッシュに見出されると、解決されたイーサネット・アドレスが、ARPキャッシュルックアップを要求したモジュールに返される。そうではなくて、ターゲットIPアドレスが、ARPキャッシュに見出されず、そして、全てのARP要求試行が、時間切れになった場合には、ARPキャッシュルックアップを要求したモジュールは、ターゲットIPアドレスが解決できなかったことを通知される。
【０１３３】
注：IPルータ・モジュールからのARPキャッシュルックアップ要求が、イーサネット・アドレスに解決できなかった場合には、IPルータ・モジュールは、そのターゲットIPアドレスのための別のARPキャッシュルックアップを始める前に、最小20秒間待たなければならない。
【０１３４】
このセクションは、ARPキャッシュ・エントリの満了を扱う。動的なARPキャッシュ・エントリは、限定された時間量においてしか、ARPキャッシュに存在できない。これは、IPアドレスのイーサネット・アドレスへのマッピングが陳腐になる（古臭くなる、としても知られている）のを防ぐためである。例えば、ネットワークが、複数のホスト間で一溜まりのIPアドレスを共有するためにDHCPを用いている場合、あるいは、デバイスのイーサネット・インターフェイスが、接続の間に変更される場合に、陳腐なアドレスマッピングが起こり得る。
【０１３５】
キャッシュ・エントリの創出からの経過時間を記録するために、ARPキャッシュモジュールは、ARPキャッシュ満了タイマとして、16ビットARPキャッシュモジュールカウンタを用いる。ARPキャッシュ満了タイマは、2ヘルツの周波数で動作し、ARPキャッシュモジュールが創出してから経過した秒数を追跡するために用いられる。各ARPキャッシュ・エントリは、ARPキャッシュ満了タイマによって用いられる16ビットARPキャッシュモジュールカウンタから受け取られる16ビットARPキャッシュモジュールタイム・スタンプを含んでいる。この16ビットARPキャッシュモジュールタイム・スタンプは、IPアドレスが成功のうちに解決された時刻を示している。
【０１３６】
ARPキャッシュ・エントリは、ARPキャッシュモジュールがアイドル状態の間に、満了することができる。ARPキャッシュモジュールは、ARPキャッシュモジュールによって現在処理されているARP要求またはARPキャッシュルックアップが全く存在しないときには、アイドル状態にある。ARPキャッシュモジュールがアイドル状態にある間、8ビットARPキャッシュモジュールカウンタが、ARP LUTの間をサイクル動作して、それを探索するために用いられる。ARP LUTの各エントリが、有効なm1メモリ・ポインタを含んでいるかどうかを確かめるためにチェックされる。m1メモリ・ポインタが有効であれば、対応するm1メモリ位置が、m1モジュールメモリ・ポインタを用いて検索される。次に、そのm1メモリ位置のARPキャッシュ・エントリは、ARPキャッシュ満了タイマから受け取られた、そのARPキャッシュ・エントリのタイム・スタンプと現在の時刻との間の差が、ARPキャッシュ・エントリの最大寿命以上であるかどうかを確かめるためにチェックされる。ARP LUTエントリに連係する第1のARPキャッシュ・エントリが、静的なARPキャッシュ・エントリであり、また、他のm1メモリ位置が、第1のm1メモリ位置と遮断されている場合には、それらのm1メモリ・ブロックに含まれるARPキャッシュ・エントリも、チェックされる。動的なARPキャッシュ・エントリが見出されるか、あるいは、与えられたARP LUTエントリに連係する全てのARPキャッシュ・エントリがチェックされれば、続いて、次のARP LUTエントリがチェックされる。
【０１３７】
ARPキャッシュ・エントリが満了したことが見出されると、そのARPキャッシュ・エントリの有効ビットが、0にセットされる。同一のm1メモリ・ブロック内に他の有効なARPキャッシュ・エントリが全く存在しなければ、そのm1メモリ・ブロックは、割り付けを解放され、メモリ・コントローラ・モジュールに返される。割り付けを解放されているm1メモリ・ブロックが、与えられたARP LUTエントリに連係するただ一つのARPモジュールメモリ・ブロックである場合には、そのARP LUTエントリのPVビットも0にセットされ、それによって、そのポインタが無効になる。
【０１３８】
このセクションは、ARP プロキシィングを遂行するARPキャッシュを扱う。そのARPキャッシュは、ARPプロキシキャッシュ・エントリをサポートしている。ARP プロキシィングは、インターネット・チューナ10Gがルータとして働くか、あるいは、ARP照会に応えることができないネットワーク上のデバイスがあるときに、用いられる。
【０１３９】
ARP プロキシィングがイネーブルのとき、ARPモジュールは、ARPキャッシュモジュールに、インターネット・チューナ10Gのハードウェア・インターフェイスに属さないIPアドレスに対するARP要求を渡す。そうすると、ARPキャッシュモジュールは、ターゲットIPアドレスを探索するためにARPプロキシキャッシュ・エントリルックアップを遂行する。ARPキャッシュモジュールが、一致するIPアドレスを備えたARPキャッシュ・エントリを見出すと、ARPキャッシュモジュールは、そのARPキャッシュ・エントリのタイプ・フィールドをチェックして、そのARPキャッシュ・エントリが、ARPプロキシキャッシュ・エントリであるかどうかを決定する。そのARPキャッシュ・エントリが、ARPキャッシュプロキシエントリであれば、ARPキャッシュモジュールは、ARPモジュールに、そのARPプロキシキャッシュ・エントリからの対応するイーサネット・アドレスを渡し返す。次に、ARPモジュールは、送信元イーサネット・アドレスとしてARPプロキシキャッシュ・エントリに見出されたイーサネット・アドレスを用いて、ARP応答を生成する。ARPプロキシルックアップは、ARPモジュールによって受信されたARP要求に対してしか起こらない。
【０１４０】
このセクションは、ARPキャッシュモジュールアクセス優先順位を扱う。相異なるARPタスクが、ARPキャッシュモジュールメモリへのアクセスに関して、相異なる優先順位を持つ。入ってくるARPパケットは、非常に高レートで受信されることもあり、再送信を回避するために、できるだけ速く処理されなければならない。ARPキャッシュプロキシエントリルックアップは、最高の優先順位を持っている。ARPモジュールからのデータを用いるARPキャッシュへの動的なARPキャッシュ・エントリの付加は、2番目の優先順位にある。IPルータ・モジュールからのARPキャッシュルックアップは、3番目の優先順位にある。内部プロセッサからのARPキャッシュルックアップは、4番目の優先順位にある。ARPキャッシュ・エントリの手動創出は、5番目の優先順位にある。ARPキャッシュ・エントリの満了は、最低の優先順位にある。
【０１４１】
以下のセクションは、IPモジュール1758を扱う。IPモジュールは、イーサネットモジュール1766、TCPモジュール1752、メモリ・アロケータ・モジュール、例外ハンドラ1768、および、内部プロセッサとインターフェイスで接続している。
【０１４２】
以下のセクションは、IPモジュールを有するモジュールについて記述する。
【０１４３】
図20に関して、このセクションは、IPヘッダ・フィールド構文解析モジュール2062を扱う。IPヘッダの以下のフィールドは、IPヘッダ・フィールド構文解析モジュールによって構文解析される。
【０１４４】
プロトコル・バージョン・フィールドIPヘッダ・フィールド構文解析モジュールは、IPv4とIPv6とのどちらの IPパケットも検出する。プロトコル・バージョン・フィールドは、プロトコル・バージョンを決めるために用いられる。0x4または0x6のプロトコル・バージョン・フィールドを備えたIPパケットしか、デコードされない。サポートされていないIPバージョン・フィーチャがイネーブルであると、受信された他の全てのプロトコル・バージョンが、ホスト・システムに送られる。サポートされていないIPバージョン・フィーチャがイネーブルでないと、そのIPパケットは、黙って捨てられる。
【０１４５】
タイプ・オブ・サービス(ToS)フィールドは、構文解析されずに、受信されるIPパケットのために、使わないでおかれる。
【０１４６】
IPパケット全長フィールド−IPヘッダ・フィールド構文解析モジュールは、受信されたIPパケット内のバイトの全数を決定するために、IPパケット全長フィールドを用いる。そうすると、IPヘッダ・フィールド構文解析モジュールは、以後のプロトコル・プロセッサ・モジュールに、IPパケットのデータ・セクションの端部の位置を指示することができる。指示されたバイト数を超えるIPパケット内のデータで、IPパケット信号がディアサートする（非アクティブになる）前に受信されたIPパケット内のデータは全て、パディング・バイトとみなされる。IPパケット内のパディング・バイトは、黙って破棄される。
【０１４７】
識別フィールド、フラグフィールド、および、分割オフセット・フィールド・インターネット・チューナ10Gは、IPパケットを再構築するために、これらのフィールドを用いる。IP分割についてのセクションは、これらのフィールドがどのように用いられるかを記述する。
【０１４８】
TTL（タイム・ツー・ライブ）フィールド−タイム・ツー・ライブ・フィールドは、構文解析されず、受信されるIPパケットのために、使わないでおかれる。
【０１４９】
プロトコル・フィールドIPヘッダ・フィールド構文解析モジュールが、IPパケットにカプセル化されているプロトコルを決定するためにプロトコル・フィールドを用いる。表1は、インターネット・チューナ10Gにサポートされているプロトコル・フィールド値を示す。
【表１】
2005502225.tif 000003
サポートされているプロトコル・フィールドデコード
【０１５０】
IPパケットが、サポートされていないプロトコル・フィールド値を持って受信されたとき、そして、そのサポートされていないプロトコル・フィーチャがイネーブルであるとき、IPモジュールは、そのIPパケットを、ホスト・システムに渡す。サポートされていないプロトコル・フィーチャがイネーブルでないとき、IPモジュールは、そのIPパケットを、黙って破棄する。
【０１５１】
ヘッダ・チェックサム・フィールドIPヘッダ・フィールド構文解析モジュールは、IPヘッダ・チェックサム・フィールドを、黙って破棄して解析しないか、そうでなければ、使わないでおく。IPモジュールは、IPヘッダ・チェックサム・フィールドを用いて、IPヘッダ・チェックサムが正しいことを確かめる。IPチェックサムが正しくなければ、IPモジュールは、以後の全てのプロトコル処理モジュールに届く不良チェックサム信号をアサートする。IPモジュールは、不良チェックサム信号が確認応答されるまで、不良チェックサム信号をアサートし続ける。
【０１５２】
送信元IPアドレス・フィールドIPヘッダ・フィールド構文解析モジュールは、送信元IPアドレスを構文解析して、それを以後のTCPプロトコル処理モジュールおよびUDPプロトコル処理モジュールに送る。ICMPエコー要求パケットが受信された場合には、送信元IPアドレス・フィールドは、ICMPエコー応答パケットの送信に先立って、送信先IPアドレス・フィールドと交換される。
【０１５３】
送信先IPアドレス・フィールドIPヘッダ・フィールド構文解析モジュールは、送信先IPアドレス・フィールドを構文解析して、それを、インターネット・チューナ10Gネットワーク・スタックが応えるべき有効IPアドレスのリストと比較する。このIPアドレス比較は、2クロック周期以上取ってもよいが、受信されたIPパケットの構文解析は、継続する。その後、IPアドレス比較の結果、受信されたIPパケットが、誤った宛名を書かれているということが判明した場合には、IPモジュールは、不良IPアドレス信号をアサートする。IPモジュールは、不良IPアドレス信号が確認応答されるまで、不良IPアドレス信号をアサートし続ける。
【０１５４】
IPオプション・フィールド・セーブ・オプション・フィーチャがイネーブルであると、IPモジュールは、IPオプション・フィールドをホスト・システムに渡す。セーブ・オプション・フィーチャがイネーブルであると、IPモジュールは、また、受信されたIPパケット・ヘッダも、ホスト・システムに渡す。セーブ・オプション・フィーチャがイネーブルでなければ、受信されたIPパケットのオプション・フィールドは、黙って破棄される。
【０１５５】
このセクションは、ローIP受信モジュール2066を扱う。ローIP受信モジュールは、内部プロセッサ1688が、インターネット・チューナ10Gネットワーク・スタック1610に、任意のIPパケットを送ることをイネーブルにする。ローIP受信モジュールは、診断の目的のために用いてもよいし、あるいは、例えば、内部プロセッサが、IPパケットデフラグやIPsec解読のような機能を遂行することを可能にするために用いてもよい。ローIP受信モジュール・フィーチャを用いるために、内部プロセッサは、最初に、メモリ・バッファにIPパケット・データを書き込む。次に、内部プロセッサは、ロー受信アドレス・レジスタに、このメモリ・バッファの開始アドレスを書き込む。次いで、内部プロセッサは、ロー受信コマンドレジスタの受信ビットをアサートし、それによって、IPパケット・データの転送が起きる。IPパケット・データの転送が完了すると、IPステータスレジスタにロー受信ビットが、セットされる。IP割り込みイネーブル・レジスタの一部であるロー受信割り込みイネーブル・ビットがセットされると、ローIP受信モジュールが、内部プロセッサに割り込みを渡す。次に、ローIP受信モジュールが、ロー受信割り込みイネーブル・ビットに1を書き込むことによって、その受信ステータス・ビットをクリアする。
【０１５６】
このセクションは、ICMPエコー応答生成2060を扱う。ICMPエコー応答モジュールが、ICMPエコー応答パケットの生成をハンドルする。ICMPエコー応答モジュールは、全ての受信されるICMPパケットをハンドルする。ICMPエコー応答モジュールは、最初に、ICMPパケットの8ビットICMPタイプ・フィールドおよび8ビットICMPコード・フィールドを構文解析して、受信されたICMPパケットのメッセージタイプを決定する。受信されたICMPパケットのICMPメッセージタイプがエコー要求であれば、ユーザは、ホスト・システムを通じて、ICMPエコー応答モジュールが、エコー応答で、これらのエコー要求に自動的に応えるようにプログラムすることができる。この自動ICMPエコー応答フィーチャがイネーブルであると、受信されたICMPパケットのデータ・セクションが、メモリ・バッファに記憶される。ICMPエコー応答モジュールは、受信されたICMPパケット全体を確認する。受信されたICMPパケットが誤りのないものであれば、ICMPエコー応答モジュールは、メモリ・バッファに記憶されている受信されたICMPパケットのデータ・セクションに、イーサネット・ヘッダ、IPヘッダ、および、ICMPヘッダを加える。ICMPエコー応答モジュールは、メモリ・バッファに記憶されているICMPパケットのタイプ・フィールドを、0x00に変更する。次に、ICMPエコー応答モジュールは、1の補数演算を用いて、0x08を加えることによりICMPチェックサム・フィールドを修正する。次いで、ICMPエコー応答モジュールは、メモリ・バッファに記憶されているICMPパケットのIPヘッダの送信元IPアドレス・フィールドと送信先IPアドレス・フィールドとを交換する。ICMPエコー応答モジュールは、また、メモリ・バッファに記憶されているICMPパケットのイーサネット・ヘッダの送信元イーサネット・アドレス・フィールドと送信先イーサネット・アドレス・フィールドとを交換する。新しいIPヘッダおよびイーサネット・ヘッダが生成されると、ICMPエコー応答モジュールは、ICMPエコー応答パケットを送信するために、送信アービトレータに対して送信要求をアサートする。
【０１５７】
受信されたICMPパケットのメッセージタイプは、エコー要求でないこともある。受信されたICMPパケットのメッセージタイプがエコー要求でなければ、そのパケットは、例外ICMPパケットである。ユーザは、ホスト・システムを通じて、ICMPエコー応答モジュールが、次の2つの方法のうちの1つで例外ICMPパケットを処理するようにプログラムすることができる。ICMPエコー応答モジュールは、例外ICMPパケットを内部プロセッサに渡してもよく、あるいは、ICMPエコー応答モジュールは、例外ICMPパケットを黙って破棄してもよい。ICMP例外パケットが内部プロセッサに渡されることになる場合には、ICMPエコー応答モジュールは、IPヘッダを含む、受信されたICMPパケット全体を内部プロセッサに渡す。ICMP例外パケットは、IP例外ハンドラ・モジュールを介して内部プロセッサに送られる。
【０１５８】
図21および22に関して、ICMPエコー応答モジュール2060は、ICMPエコー応答受信モジュール2180、および、ICMPエコー応答プロセッサ・モジュール2182から成っている。ICMPエコー応答受信モジュールは、ICMPパケットを受信し、ICMPパケットのコンテンツをm1メモリに記憶する。ICMPエコー応答受信モジュールは、受信されたICMPパケットが、誤りのないものであることを確認する 2206。受信されたICMPパケットが、誤りのないものであれば、ICMPエコー応答受信モジュールは、受信されたICMPパケットからのIPヘッダ情報を、受信されたICMPパケット2202を含んでいるm1メモリ・ブロック2200のアドレスとともに、ICMPエコー応答プロセッサ・モジュール2182に渡す。
【０１５９】
図23を参照すると、ICMPエコー応答プロセッサ・モジュールは、エコー応答パケット2322に対するイーサネット・ヘッダおよびIPヘッダを生成する。次に、ICMPエコー応答プロセッサ・モジュールは、アドレスがICMPエコー応答受信モジュールから受け取られたm1バッファブロックに、ICMPエコー応答パケットをアセンブルする。ICMPエコー応答プロセッサ・モジュールは、受信されたICMPエコー要求のICMPチェックサムに0x08を加えることによって、ICMPチェックサムを生成する 2326。ICMPチェックサムに影響するエコー要求とエコー応答との間の唯一の相違は、ICMPコード・フィールドの相違（それは、0x08から0x00に変わる）だけであるので、この付加は、エコー応答に対する正しいICMPチェックサムを作り出す。
【０１６０】
ICMPエコー応答プロセッサ・モジュールは、m1メモリ2322に、ICMPエコー応答パケットをアセンブルする。ICMPエコー応答パケットのアセンブリが完了すると、ICMPエコー応答プロセッサ・モジュールは、ICMPエコー応答パケット送信キュー2324に、ICMPエコー応答パケットの開始アドレスを置く。ICMPエコー応答パケット送信キューは、8つのエントリのための空きを持っている。ICMPエコー応答パケット送信キューが一杯になると、そのあと受信されるどのICMPパケットも、破棄される。ICMPエコー応答パケットが送信の準備を整えると、ICMPエコー応答プロセッサ・モジュールが、イーサネット送信器モジュール1766に合図を送る。その後、ICMPエコー応答パケットが、成功のうちに送信されると、イーサネット送信器モジュールは、ICMPエコー応答プロセッサ・モジュールに合図を送り返す。次に、ICMPエコー応答プロセッサ・モジュールが、ICMPエコー応答パケットを含有しているm1メモリ・ブロックを解放する 2328。ICMPエコー応答プロセッサは、複数のm1ブロックにまたがる大きなICMPエコー応答パケットをサポートする。
【０１６１】
ICMPエコー応答受信モジュールは、ICMPエコー要求パケットの受信の間にエラーを検出することができる（エラーには、不良チェックサム、無効IPアドレスなどを含むことができる）。ICMPエコー応答受信モジュールがエラーを検出すると、それは、現在書き込まれているm1メモリ・ブロック（および、同じICMPエコー要求パケットに用いられた全ての以前のm1メモリ・ブロック）を解放する。ICMPエコー応答プロセッサ・モジュールは、ICMPエコー応答受信モジュールとICMPエコー応答プロセッサ・モジュールとの間で渡されるパケット中断信号によって、このエラー状態をハンドルする。
【０１６２】
このセクションは、IP分割を扱う。インターネット・チューナ10Gは、IP分割を、直接ハードウェアにおいてハンドルすることもできるし、あるいは、内部プロセッサを用いてハンドルすることもでき、IPパケットを再構築して、次に、その再構築されたIP データグラムを、インターネット・チューナ10Gネットワーク・スタックに注入し返す。インターネット・チューナ10Gは、識別フィールド、送信元フィールド、送信先フィールド、および、プロトコル・フィールドにおいて同一の値を持つフラグメント（断片）を組み合わせることによって、IPデータグラムのフラグメントをアセンブルする。インターネット・チューナ10Gは、各フラグメントの各データ・セクションを、そのフラグメントのIPヘッダの分割オフセットによって指示される相対位置に置く。最初のフラグメントは、0にセットされた分割オフセットを持ち、また、最後のフラグメントは、0にセットされたmore-fragmentフラグを持つ。
【０１６３】
このセクションは、分割されたIPパケットを、ハードウェアで直接的にハンドルするIP分割モジュール2064を扱う。図24に関して、IPパケットが、分割されたIPデータグラムに属するときには、そのIPパケットは、IPパケット・ヘッダにセットされたフラグメントフラグを持つ。そのとき、IP分割モジュールは、次のステップを実行する。
【０１６４】
・  IP分割モジュールは、IPパケット・ヘッダの16ビット識別フィールド、および、IPパケット・ヘッダの32ビット送信元IPアドレスを用いて、8ビットのハッシュ値を生成する 2456。
【０１６５】
・  エントリ使用中フラグとともに、32ビットメモリ・アドレスをルックアップするために、8ビット・ハッシュ値を用いる 2450。エントリ使用中フラグがセットされていなければ、それは、これが、この受信されたIPパケットの最初に受信されたIPフラグメントであることを指示している。
【０１６６】
・  次に、エントリ使用中フラグがセットされ、IPパケット・データベースが、初期化される。IPパケット・データベース2454, 2458は、VSOCKモジュール・オーバーフロー・ソケット・データベース・メモリ・エリアに存在する。IPパケット・データベースの内部には、IPパケット・データを保持するメモリ(ソケット受信データ・メモリ空間の)に対するポインタが、ある。このIPパケットセグメントが、どれくらい長く保持されているかがわかるように、タイム・スタンプも、IPパケットCBに含まれている。タイマが満了すると、全ての受信されたIPパケットセグメントが、破棄される。
【０１６７】
・  分割オフセットが、IPパケット・ヘッダにセットされていれば、その分割オフセットを用いて、メモリ・バッファ内をどれくらい下った位置で、受信されたIPパケット・データを書き込み始められるかを決定する 2452。
【０１６８】
・  カウンタが、受信されたバイトの総数を記録し、IPパケット2462, 2460, 2464とともに保持される。このカウンタに受け取られた総バイトが、最後のIPパケット・フラグメント（IPヘッダの制御フラグフィールドのmore fragmentフラグが0にセットされるという事実によって指示される）のデータ量と、最後のIPパケット・フラグメントの分割オフセットとの和と比較される。分割されたIPデータグラムの全データが届いていると計算されると、そのソケット情報が、TCP/UDPプロトコル処理層に渡される。
【０１６９】
図25を参照すると、IPパケット・データベースに記憶されるさらなる情報に、IPパケット衝突テーブル2590、および、IPパケット・ポインタ・テーブル2588が含まれる。使用中の各ルックアップテーブルエントリ2580は、IP送信元アドレス、および、IPパケット識別ペアと連係している。そのペアは、衝突テーブルに記憶されている。ハッシング（ハッシュ法）2598が、既に使用中のルックアップテーブル中のエントリをヒットした場合、以下の2つの可能性がある。
【０１７０】
・  受信されたIPパケット・フラグメントが、既に考慮にはいっているIPデータグラムに属している。受信されたIPパケット・フラグメントのIP送信元アドレス・フィールドおよびIPパケット識別フィールドが、衝突テーブルエントリに記憶されている値と一致する。
【０１７１】
・  受信されたIPパケット・フラグメントが、未知のIPデータグラムに属している。受信されたIPパケット・フラグメントのIP送信元アドレス・フィールドおよびIPパケット識別フィールドが、衝突テーブルエントリに記憶されている値と一致しない。それは、衝突が起こり、したがって、その受信されたIPパケット・フラグメントが棄てられるということを意味する。
【０１７２】
使用中のフラグのほかに、LUT 2580の各エントリは、パケットが受信データ・バッファ・メモリに収まるために振り当てられる開始アドレスを記憶する。ハッシング2598が、まだ使用されていないLUTのエントリをヒットしたら、メモリ要求が、開始アドレスを計算するVSOCKモジュール・メモリ・アロケータ・モジュール2500に送られる。メモリ・アロケータ・モジュールによって分割ブロックに配給されるメモリ・ブロックのサイズは、固定されている（2キロバイト）。再構築されるべきIPパケットが、1ブロックのメモリにぴったり合う場合には、IPパケット・フラグメントが、切れ目なく記憶され、そして、メモリ・ブロック内の正確な位置が、開始アドレスおよびIP分割オフセットから計算できる。メモリ・アロケータ・モジュールは、メモリ・ブロックを、切れ目なく割り当てない。再構築されるべきIPデータグラムが、2つ以上のメモリ・ブロックを必要とする場合には、受信データ・バッファ・メモリへのパケット・フラグメントのマッピングは、より難しくなる。開始アドレス、IP分割オフセット、および、IP長フィールドに基づいて、ユーザは、メモリ・ブロック境界が、再構築されたIPデータグラムによって交差されようとするときを計算することができる。最初にメモリ・ブロック境界が交差されるとき毎に、メモリ要求が、次に利用可能なブロックの開始アドレスをその後に配給するVSOCKメモリ・アロケータ・モジュールに送られなければならない。さらなるブロックの開始アドレスが、有効フラグとともに、ポインタテーブルに記憶される。イーサネット・ジャンボ・フレーム（最大9キロバイト）に収容されたパケットをハンドルできることが望ましいから、8メモリ・ブロックまで必要となることもある。これは、LUT内の各エントリに対して、ポインタテーブルに7つのポインタを記憶できるようにする必要があるということを意味する（256 x 7=1792 ポインタ）。
【０１７３】
IP分割モジュールは、IP分割モジュールコントローラ2594を必要とする。IP分割モジュールコントローラのタスクは、以下の通りである。
【０１７４】
・  ポインタテーブルおよび受信データ・メモリ・バッファに対するアドレス信号、書き込み信号、および、読み出し信号の生成。
【０１７５】
・  VSOCKメモリ・アロケータ・モジュール2500に、メモリ・ブロックを要求する（メモリ・アロケータ・モジュールが、配るべき、さらなるメモリ・ブロックを何ら持たない場合には、パケット・アセンブリ・タイマが満了し、それによって、IPパケットが棄てられるのを待たなければならない）。
【０１７６】
・  IPデータグラムの再構築が完了したことを、TCP層に合図する。
【０１７７】
・  IPデータグラムの再構築が完了すると、LUT中の全ての使用中のフラグ、および、ポインタテーブル中の有効フラグが、クリアされる。
【０１７８】
・  タイムアウトの管理
・  IPパケットのために受信されたバイトの総数をモニタする。
【０１７９】
・  入ってくるIPデータ・ストリームから、必要とされるフィールドを抽出する。
【０１８０】
このセクションは、IP再構築をハンドルする別の方法を扱う。インターネット・チューナ10Gは、内部プロセッサおよびローIP受信モジュールを用いることによっても、IP再構築をハンドルすることができる。受信されたIPパケットが分割されていると、受信されたIPパケットは、内部プロセッサに渡される。そうすると、内部プロセッサは、そのパケット・フラグメントを完全なIPデータグラムにアセンブルするステップをハンドルする。IPデータグラムが完成すると、それは、ローIP受信モジュールを介してネットワーク・スタックの最後尾に注入し返される。
【０１８１】
このセクションは、IP識別フィールド生成アルゴリズムを扱う。内部プロセッサは、IP識別フィールド・スタート・レジスタ2682に任意の16ビット値を書き込むことによって、IP識別フィールドシード値をセットすることができる。IP識別フィールド・ジェネレータ・モジュールは、この16ビット値を受け取り、そして、16ビットのマッピングを遂行して、IP識別フィールドを生成する 2686。次に、IP識別フィールドは、要求モジュールによって用いられる。内部プロセッサ、TCPモジュール、および、ICMPエコー応答ジェネレータ・モジュールは全て、IP識別フィールドを要求できる。
【０１８２】
IP識別フィールド・ジェネレータ・モジュール・シード・レジスタは、新しいIP識別フィールドが要求される度毎にインクリメントされる 2684。識別フィールド・ジェネレータ・モジュール・ビット・マッパ2686は、IP識別フィールド・レジスタ値IP_ID_Regを、識別フィールド・ジェネレータ・モジュールバスIP_ID_Outが各要求に対して単純に値をインクリメントしないように再配置する。
【０１８３】
以下のセクションは、TCPトランスポート・プロトコルおよびUDPトランスポート・プロトコルの両方をハンドルするTCPモジュール1752を扱う。図27を参照すると、TCPモジュールは、4つのより小さな主要モジュール；ソケット送信インターフェイス2700、TCP送信インターフェイス2704、TCP受信インターフェイス2708、および、ソケット受信インターフェイス2702に分かれる。
【０１８４】
以下のリストは、インターネット・チューナ10GアーキテクチャにサポートされているTCP能力について記述している。
【０１８５】
・  64,000ソケットまでのサポート
・  TCPアウト・オブ・オーダ・パケットのサポート
・  スロー・スタート・アルゴリズム
・  高速再送アルゴリズムおよび高速回復アルゴリズム
・  選択可能なNagle（ナグル）アルゴリズム
・  スケーリング・ウィンドウサポート
・  セレクティブACK（SACK：選択確認応答）サポート
・  周回シーケンス番号に対する保護(PAWS) サポート
・  タイム・スタンプ・サポート
・  キープ・アライブ・タイマ
ソケット制御ブロック(CB)2706には、各接続に特有であり、インターネット・チューナ10Gにおけるバーチャル・ソケット即ちVSOCKアーキテクチャの重要な構成要素である情報、状態およびパラメータのセッティングが含まれている。
【０１８６】
このセクションは、TCP受信モジュール2708を扱う。図28は、TCP受信データ・フローを示している。
【０１８７】
標準のIPトラフィックにおいては、IPパケットは、64ビットTCP受信データ・パスを介して受信される。IPパケット・ヘッダは、TCPパーザ・モジュール2846に渡され、また、パケット・データは、受信データ・メモリ・コントローラ2848に渡される。分割されたIPパケットにおいては、パケット・データは、メモリ・ブロックを介して渡され、一方、パケット・ヘッダ情報は、標準の受信パスを介して渡される。これは、IP分割からのメモリ・ブロックが、受信データ・メモリ・コントローラによって書き込まれたデータブロックと同じフォーマットを持つことを可能にする。内部プロセッサも、受信データ・メモリ・コントローラを介して受信されたパケット・データを注入するために、メモリ・ブロックを用いる。
【０１８８】
受信TCPパーザは、TCPヘッダー情報を構文解析し、パラメータを、VSOCKモジュール2834および受信状態ハンドラ・モジュール2832に渡す責を負っている。受信TCPパーザが、パケット・データに関して何を行うべきか知らない場合には、それは、そのパケット・データを例外ハンドラ・モジュール2838に渡す。さらに、受信TCPパーザ・モジュールは、全てのパケット・データを、例外ハンドラ・モジュールに送るようにプログラムすることもできる。
【０１８９】
VSOCKモジュール（他で詳細に記述される）は、ローカルIPアドレス、リモートIPアドレス、および、ポート・アドレスを受け取り、CBにポインタを返す。
【０１９０】
NATとIPマスカレーディング・モジュール2842（他で詳細に記述される）は、受信されたパケットが、NATパケットまたはIPマスカレーディング・パケットであるかどうかを決定する。受信されたパケットが、NATパケットまたはIPマスカレーディング・パケットであれば、そのNATパケットまたはIPマスカレーディング・パケットが、ロー・パケットとして内部プロセッサに渡される。
【０１９１】
受信状態ハンドラ・モジュール（他で詳細に記述される）は、各接続の状態を追跡し、その接続に対応するCBを更新する。
【０１９２】
このセクションは、受信TCPパーザ・モジュール2846を扱う。受信TCPパーザ・モジュールは、TCPパケット・ヘッダ情報を、他のTCP受信モジュールに渡す。TCPパーザ・モジュールには、内部プロセッサから、インターネット・チューナ10Gネットワーク・スタックの受信データ・パスにデータを注入するために必要とされる内部プロセッサレジスタが含まれている。内部プロセッサは、メモリ・ブロックをセットアップし、そして、必要な情報を用いて受信TCPパーザ・レジスタをプログラムしなければならない。受信TCPパーザ・モジュールは、TCPヘッダの部分チェックサムを遂行し、受信データ・メモリ・コントローラからの部分チェックサムにこの部分チェックサムを加えて、このチェックサム足し算の結果と、TCPヘッダのチェックサムとを比較する。分割されたIPパケットにおいては、受信TCPパーザ・モジュールが、送られてきた最後のIPパケット・フラグメント中のチェックサムに対して、TCPヘッダのチェックサムをチェックする。
【０１９３】
IPモジュールは、IP分割ビットをセットし、適切なパケット・フラグメントのデータ・パスに最初のメモリ・ブロック・ポインタ、最後のメモリ・ブロック・ポインタ、インデックス、および、部分チェックサムを挿入しなければならない。また、TCP受信モジュールは、TCP擬似ヘッダを計算するために、IPプロトコル・フィールドを必要とする。
【０１９４】
このセクションは、受信データ・メモリ・コントローラ・モジュール2848を扱う。受信データ・メモリ・コントローラ・モジュールは、IPモジュールとTCPモジュールとの間の64ビットバスから、受信データ・メモリのデータ・メモリ・ブロックにデータを転送する。データ転送の2つのモードがある。データ転送の標準モードが、メモリ・ブロックにTCPデータを記憶するために用いられる。データ転送のロー・モードが、メモリ・ブロックにパケット全体を記憶するために用いられる。データ転送のロー・モードが、NATとIPマスカレーディングのために用いられる。
【０１９５】
このセクションは、VSOCKモジュール2834を扱う。VSOCKモジュールは、バーチャル・メモリ管理に等価な最適化されたハード・ワイヤード・ロジックをインプリメントしている。それに匹敵する機能が、プログラム可能なプロセッサ上で走る複雑なソフトウェアによって標準的に実行される。VSOCKモジュールを用いる結果として、インターネット・チューナ10Gが、仮想数(virtual number)のソケットを利用できる。ソケットの数は、オンチップに接続された、あるいは、外部的に接続された、あるいは、オンチップと外部的との両方で接続されたメモリ量によってしか制限されない。ソケットは、常設のコネクションである。コネクションは、以下の3つのステージ：ハーフ・オ−プン(HO)2858、オープン2840、タイム・ウェイト(TW)2850を通る。各コネクションに関する情報は、制御ブロック(CB)に記憶される。
【０１９６】
図29は、VSOCKおよび受信状態ハンドラ制御ブロックの探索解決フローを示している。VSOCKモジュール2834は、受信されたパケットから、送信元IPアドレス、送信先IPアドレス、および、ポート・アドレスを渡される。VSOCKモジュールは、受信状態ハンドラ・モジュールに、ソケット・オープンCBポインタまたはTW CBポインタを返す。ロッキング機構が、1つのモジュールがある1つのソケットCB上で動作している間、他のどのモジュールもそのソケットCB上で動作できないことを確実にする。VSOCKは、送信元IPアドレス、送信先IPアドレス、送信元ポート・アドレス、送信先ポート・アドレス上でハッシュを実行する。ハッシュ関数2980は、オープン/TW CBルックアップテーブル(LUT)2986のインデックスとしての役割をする17ビット値を生成する。そのインデックスが付けられた位置のオープン/TW CB LUTエントリが、オープンCB 2988あるいはTW CB 2994に対するポインタを保持する。
【０１９７】
HO CBのハンドリングの説明に対しては、受信状態ハンドラ・モジュールについて記述しているセクションを参照されたい。
【０１９８】
オープン/TW CB LUTからのポインタは、各々異なるIPアドレスおよびポート・アドレスを持つが、同一のハッシュ番号に帰着する(ハッシュ衝突に起因して)、ゼロ以上のソケットCBのリンクされたリストの最初のCBを指し示す。VSOCKは、受信されたパケットのIPアドレスおよびポート・アドレスと、チェーン状につながれたソケットCB中のエントリとを比較しながら、一致が見つかるか、または、チェーンの終点に到達するまで、このチェーンを下っていく。一致が見つかれば、そのソケットCBに対するポインタが、受信状態ハンドラ・モジュールに渡される。VSOCKモジュールが、このチェーンの終点に到達すれば、それは、エラーである。そのときには、VSOCKモジュールは、TCPパーザ・モジュールにエラーを通知する。
【０１９９】
オープン/TWソケットCB LUTエントリに接続されたソケットCBのチェーンには、オープンCBおよびTW CBが、含まれている。オープンCBは、チェーンの上位にある。オープンCBには最大数が存在し、チェーン・セッティング当りの受信TCPの最大オープンCBによって決定される。TW CBは、オープンCBの後にチェーン状につながれている。チェーン当たりのTW CBにも、最大数が存在する。オープンCBは、3ウェイTCPハンドシェークが完成したときに生成され、また、HO CBは、受信状態ハンドラ・モジュールによってオープンCBに移動される。TW CBは、最後のACKがFINシーケンスに送られたときに、受信状態ハンドラ・モジュールによって、オープンCBから生成される。いずれの場合にも、もはや空きがないときには、エラーが、受信状態ハンドラ・モジュールに返される。
【０２００】
オープンCBのためのCBキャッシュが、LUTエントリからのリンクのセット番号と違うオープンCBにインプリメントされる。オープンCBがCBキャッシュ内にあるとき、そのオープンCBに1ビットがセットされる。そのCBキャッシュが、17ビット・ハッシュおよびLUT動作と同時に探索される。
【０２０１】
このセクションは、受信状態ハンドラ・モジュール2832を扱う。SYNパケットが受信されると、12ビット・ハッシュが、VSOCKの起動（17ビット・ハッシュを遂行して、オープンCBまたはTW CBを探索する）に加えて作動し、送信先ポートが、認証されたポートリストと照合される。そのポートが、認証されたポートリストに載っており、VSOCK 2834が、一致するオープンCBまたはTW CBを見出さなかった場合には、その12ビット・ハッシュの結果が、HO CBテーブル2858のインデックスとして用いられる。VSOCKが、一致するオープンCBまたはTW CBを見出した場合には、重複CBエラーが、内部プロセッサに送られ、そして、そのSYNパケットは、棄てられる。異なるIPアドレスおよびポート・アドレスを持つHO CBテーブル中のエントリが、既に存在する場合には、受信されたパケット情報が、古い情報に重ね書きされる。この重ね書き動作は、リソースを、SYNパケット・フラッド攻撃あるいはサービス不能(DOS)攻撃に対して保護することを可能にする。重ね書き動作は、また、HO CBテーブルをエージする(age)必要も除去する。1つの側面の結果は、既にSYN/ACKされていたコネクションを、黙って棄てることができるということである。HO CBに対するポインタが、受信状態ハンドラ・モジュールに渡される。ローカル側によってオープンされたコネクション（ローカル側は、SYN/ACKパケットではなく、SYNパケットを受信する）しか、HO CBテーブルに入力されない。
【０２０２】
ACKパケットが受信されると、12ビット・ハッシュが作動し、また、VSOCKが起動する。12ビット・ハッシュを介してHO CBにヒットが存在するが、VSOCKが、オープンCBまたはTW CBを見出さず、また、シーケンス番号およびACKパケット番号が有効であれば、そのコネクションの3ウェイ・ハンドシェークが完成し、そして、そのCBが、受信状態ハンドラ・モジュールによってオープンCBテーブルに転送される。VSOCKが、オープンCBまたはTW CBを見出すが、12ビット・ハッシュによるヒットが存在しなければ、そのACKパケットが、重複ACKパケットでないかだけではなく、受信状態ハンドラ・モジュールによって、有効なシーケンス番号およびACK番号でないかチェックされる。
【０２０３】
VSOCKモジュールが、正しいソケットCBを見出すと、他の関連する情報が、受信状態ハンドラ・モジュールによって読み出されて、更新される。TCPデータは、大きな（2 キロバイト）メモリ・バッファか、小さな（128バイト）メモリ・バッファかのいずれにでも記憶される。単一のセグメントが、メモリ・バッファ間にまたがることができる。1つのサイズのメモリ・バッファが尽きると、別のサイズのメモリ・バッファが用いられる。データが、与えられたソケットに対して受信されると、ソケット・ハッシュLUTにも、そのData_Availビットがセットされる。
【０２０４】
受信状態ハンドラ・モジュールは、スティーブンズによって記述されているようなステートマシンを用いる（スティーブンズのセクション18.6の図18.12を参照のこと）。
【０２０５】
受信状態ハンドラ・モジュールが、RSTパケットが必要であると決定すると、それは、RSTパケット・ジェネレータ・モジュール2830に適切なパラメータを配布する。SYN/ACKパケットまたはACKパケットが必要なときには、それはRX-TX FIFO 2860にCBハンドルを送る。
【０２０６】
このセクションは、RSTパケット・ジェネレータ・モジュール2830を扱う。図30を参照すると、RSTパケット・ジェネレータ・モジュールは、RSTパケット応答を必要とするパケット中に受信されるMACアドレス、4つのソケット・パラメータ、および、シーケンス番号を受け取って、RSTパケットを組み立てる。それは、最初に、MTXメモリ3014にパケットを構築するためのブロックを要求する。RSTパケットは、常に40バイト長であるから、RSTパケットは、どんなサイズのMTXブロックにもはまる。RSTパケット・ジェネレータ・モジュールは、常に、利用可能な最小のブロック（標準的に128バイト・ブロック）を要求する。RSTパケットは、0x0000に固定されたIP識別フィールドを持ち、それらのdon't fragmentビットが、IPヘッダに1とセットされる。
【０２０７】
RSTパケット・ジェネレータ・モジュールが、RSTパケットを組み立てた後、RSTパケット・ジェネレータ・モジュールは、RSTパケット送信キューに、RSTパケットを含有しているMTXブロックの開始アドレスを記憶する。RSTパケット送信キューは、m1メモリに組み立てられる 3010。m1メモリの1ブロックが要求され 3016、それが一杯になるまで用いられる。各m1ブロックの最後のエントリが、用いられる次のm1ブロックのアドレスを指し示す。したがって、RSTパケット・キューは、動的に成長することができる。RSTパケット・ジェネレータ・モジュールは、m1メモリに一度に32ビットアクセスする（MTXブロック・アドレスが26ビットでしかないから）。RSTパケット送信キュー長は、m1メモリが利用可能な限り、成長することができる。最早、これ以上のm1メモリが、RSTパケット送信キューに利用可能でなくなれば、RSTパケット・ジェネレータ・モジュールは、受信状態ハンドラ・モジュールからのRSTパケット要求3018を黙って破棄する。RSTパケットの破棄は、送信中にRSTパケットを棄てるのと同等のネットワーク上の効果を持つ。コネクションが全く存在しないから、この状況においてRSTパケットを棄てることは、遂行に深刻な影響を持たない。
【０２０８】
RSTパケット送信キューの出力が、TCP送信パケット・スケジューラ・モジュールに渡される。TCP送信パケット・スケジューラ・モジュールが、RSTパケットが送られてしまったことを、RSTパケット・ジェネレータ・モジュールに指示すると、そのRSTパケットのために使用されていたMTXブロックは、解放される。1つのm1メモリ・ブロック中の全てのエントリが送られ、次のm1ブロックに対するリンク・アドレスが読み出されると、そのm1メモリ・ブロックは、解放される。
【０２０９】
このセクションは、RX to TX FIFO 2860を扱う。このFIFOは、受信状態ハンドラ・モジュール2832が、受信されたパケットに応えて送る必要があると決定したSYN/ACKパケットおよびACKパケットのキューをつくるに用いられる。受信状態ハンドラ・モジュールは、RX to TX FIFOに、以下の情報を渡す。
【０２１０】
・  ソケット情報を含有しているCBアドレス（16ビット）
・  CBタイプ（2ビット；00 = HO、 01 = オープン、 10 = TW）
・  送られるべきパケット（1ビット；0 = SYN/ACK, 1 = ACK）
各RX to TX FIFOエントリは、4バイト長で、雑メモリに記憶される。一般に、RX to TX FIFOは、1,000エントリのFIFO深さを供給する4キロバイトを割り付けられる。RX to TX FIFOの出力は、SYN/ACKパケット・ジェネレータ・モジュールに流れ込む。
【０２１１】
このセクションは、SYN/ACKパケット・ジェネレータ・モジュール2841を扱う。SYN/ACKパケット・ジェネレータ・モジュールは、RX to TX FIFO 2860から情報出力を受け取り、そして、指定されたCB（HO CB 2858、オープンCB 2840、TW CB 2850のいずれか）から別の関連する情報をルックアップして、望みのパケット(SYN/ACKパケット、ACKパケットのいずれか)を組み立てる。RSTパケット・ジェネレータ・モジュール2830のように、SYN/ACKパケット・ジェネレータ・モジュールは、最初に、MTXメモリにパケットを構築するためのブロックを要求する。SYN/ACKパケットおよびACKパケットは、常に40バイト長であるから、そのパケットは、どんなサイズのMTXブロックにもはまる。SYN/ACKパケット・ジェネレータ・モジュールは、常に、利用可能な最小のブロック（標準的に128バイト・ブロック）を要求する。
【０２１２】
SYN/ACKパケットまたはACKパケットを組み立てた後、SYN/ACKパケット・ジェネレータ・モジュールは、開始MTXブロック・アドレスを、深さ16のキューに置き、それは、その後、TCP送信パケット・スケジューラ・モジュールに流れ込む。RX to TX FIFOが、プログラム可能な高いウォーター・マークを渡すと、送信パケット・スケジューラ・モジュールが、その状況を通知されて、これらのパケットの送信優先順位を増加させる。
【０２１３】
このセクションは、NATとIPマスカレーディングを扱う。NATとIPマスカレーディング・モジュール2842は、VSOCKモジュールと並列に働く。NATとIPマスカレーディング・モジュールは、入ってくるパケットをデコードして、そのパケットが、あらかじめ指定されたNATかIPマスカレーディングのポート範囲にあるかどうか確かめる。そのパケットが、NATかIPマスカレーディングのポート範囲にあれば、信号通知メカニズムを用いて、そのパケットがNATパケットであることをVSOCKブロックに指示する。これが起こると、パケット全体が、受信メモリ・バッファに記憶される。次に、そのパケットが、どこかのポイントでホスト・システムに転送される。ホスト・システムのドライバが、経路制御機能を遂行し、ヘッダパラメータを置き換え、そして、適切なネットワーク・インターフェイスにパケットを送る責を負う。
【０２１４】
このセクションは、例外ハンドラ・モジュール2838を扱う。例外ハンドラ・モジュールは、インターネット・チューナ10Gネットワーク・スタックによってハンドルできないパケットを、インターネット・チューナ10G内部プロセッサに送る。
【０２１５】
このセクションは、メモリ・ブロック制御回路を扱い、以下の機能について説明する。
【０２１６】
リザーブ・メモリ・ブロックメモリ・ブロック制御回路は、1つの小さなメモリ・ブロックおよび1つの大きなメモリ・ブロックを蓄えとして常に使用可能にしておく。この蓄えは、データがメモリ・ブロックに書かれなければならないとき、遅れがほとんど出ないことを保証する。メモリ・ブロック制御回路は、また、できるだけ並列に、ブロック要求とデータ書き込みとを処理する。リザーブ・メモリ・ブロックは、リセットによって初期化される。
【０２１７】
初期化とメモリ・ブロックサイズ選択−TCPセグメントまたはUDPセグメントのパラメータが、初期化される。用いられるメモリ・ブロックのサイズは、IPパーザ・モジュールからのTCP長情報およびTCPヘッダ長情報によって決定される。データ・セクションのサイズ（TCPヘッダ長を引いたTCP長）が、小さなメモリ・ブロックにはまれば、そのリザーブ・メモリ・ブロックが、用いられ、そして、他の1つの小さなメモリ・ブロックが要求されて、リザーブ・メモリ・ブロックが補充される。そうでない場合には、蓄えられている大きなメモリ・ブロックが用いられ、そして、他の1つの大きなメモリ・ブロックが要求されて、リザーブ・メモリ・ブロックが補充される。小さなブロックが利用可能でない場合に、大きなブロックが用いられる。しかしながら、大きなブロックが、必要であるが利用可能でない場合、小さなブロックは、用いられない。上記のtcp_in_rd生成を参照されたい。
【０２１８】
境界整列したTCPデータのメモリ・ブロックへの書き込み−ヘッダに奇数個のオプション半ワード（各32ビット幅）が存在すれば、TCPパケット内のデータは境界整列し、64ビット境界で開始するデータに帰着する。データが境界整列すると、それがIPから出たときに、それをメモリ・ブロックに直接入れることができる。そのセグメントのための最初のブロックのアドレスが、ステートマシンに送られる。TCPセグメントに残されているデータだけではなく、そのブロックの残りの空間に対するカウントが、維持される。メモリ・ブロックが既に一杯でないかどうかの記録も、維持されていなければならない。TCPセグメントの終端に到達するとき、その前のブロックが一杯であったならば、それは、現在のブロックにリンクされなければならない。さらに、現在のブロック・ヘッダのリンクがクリアされ、また、データのデータ長およびランニング・チェックサムが、そのブロック・ヘッダに書き込まれる。その長さは、ip_in_bytes_val中のビットによって決定されるから、最後の64ビット・ワード中のバイト数の関数である。そのブロックが、セグメントの終端の前で空きを使い果たした場合には、データ長およびランニング・チェックサムが、ブロック・ヘッダに書き込まれ、そして1つのブロックが終了したことを指示するフラグがセットされる。セグメントの残りのデータを用いて、大きいリザーブ・メモリ・ブロックと小さいリザーブ・メモリ・ブロックとのどちらを用いるかが決定される。ブロックサイズが尽きた場合には、前のパラグラフと同じ規則が用いられる。最後のメモリ・ブロックのアドレスが、ステートマシンに送られなければならない。
【０２１９】
境界整列していないTCPデータのメモリ・ブロックへの書き込み−セグメントのデータが、境界整列していない場合には（ip_in_data[63:0]は、2つの異なるメモリ・ブロックの書き込みとなるデータを含んでいる）、そのメモリ・ブロックに、IPからの最初のロー32ビット半ワードを、ハイ32ビット半ワードとして書き込むことができるように、初めに、その最初のロー32ビット半ワードを記憶する余分のサイクルが存在しなければならない。IPからの次のバス・サイクルにおけるハイ32ビット半ワードは、記憶された半ワードと同じサイクルにおけるロー32ビット半ワードとして書き込まれる。カウントおよびチェックサム計算も、これをハンドルするために適合されなければならない。そうでなければ、境界整列していないデータは、境界整列しているデータと同じようにハンドルされ、同じ結末状態となる。
【０２２０】
UDPデータのメモリ・ブロックへの書き込み−UDPデータは、常に境界整列しており、したがって、UDPデータは、境界整列しているTCPデータと同じようにハンドルされる。同じ結末状態が、当てはまる。
【０２２１】
チェックサム計算-チェックサムは、RFC 1071に記載されているように計算される。このブロックでは、チェックサムは、データ上でしか計算されない。パーザ・モジュールが、ヘッダ・チェックサムを計算し、そして、ステートマシンが、2つを組み合わせて、チェックサムエラーを持つパケットを、どう処理すべきか決定する。
【０２２２】
このセクションは、ソケット受信モジュール2702を扱う。ソケット受信モジュールは、インターネット・チューナ10Gとホスト・システムとの間の受信されたデータのインターフェイスをハンドルする。
【０２２３】
図31を参照すると、その処理は、受信ロジック3140が、ソケット受信DAVビット・マップ・テーブル3142にビットをセットすることから始まる。これは、64K個のソケットの各々に連係して1ビットを持つテーブルである（したがって、このテーブルは、8キロバイトである）。CBの位置を知ることによって、適切なビットが、セットされる。
【０２２４】
Socket_DAV照会モジュール3146は、バックグラウンドにおいて、このビット・マップ・テーブルを連続的に走査しているブロックである。それが、セットされているビットに遭遇したとき、それは、対応するCBアドレスを生成し、そして、CB構造3148をチェックして、それが有効なlink_listブロックを含むかどうかを確かめる 3144。このブロックは、64ビットのメモリ・アドレスから構成され、16ビット長である。CBが有効なlink_listブロックを持っていれば、CBアドレスおよびlink_list情報が、DMA準備モジュール3152に渡される（2段パイプラインレジスタペアを介して）。Socket_DAVモジュール3144は、また、その時、CBの対応するビットをクリアする。CBが有効なlink_listブロックを含んでいなければ、そのソケットでデータは利用可能であるが、そのソケットに有効な転送ブロック情報は存在しないということをホストに通知するステータス・メッセージが、そのソケットに対して生成される 3162。この場合には、ビット・マップ・テーブル中の対応するビットは、まだクリアされない。link_listブロックを求めているホストに既にステータス・メッセージを送り出したことが認識されているこの場合には、CBも、更新することができる（これは、同じCBに対するステータス・メッセージを重複して送ることに陥らないために必要である)。
【０２２５】
有効なlink_listブロックが存在したときには、次のステップは、CBおよび転送情報が、DMA準備モジュール3152に送られることである。このモジュールは、ソケット・データ・バッファからデータを読み出して、それを、DMAエンジンのための2つのピンポン転送FIFO 3160, 3156のうちの1つに入れる責を負っている。これが完了すると、それは、転送されるべきデータが存在するという要求を、送信DMAエンジン3164に送る。link_list情報も、送信DMAエンジン3164に渡される。
【０２２６】
送信DMAエンジンがこの要求を得ると、それは、ホストへのDMA転送を行うことを求められているということを主DMAエンジンに合図する。バスが与えられると、DMAエンジンは、ピンポン・バッファからデータを読み出して、それらを、ホストに送る。転送が完了すると、そのソケットのCBが更新され、そして、データがホストに送られたことを指示するステータス・メッセージが生成される。
【０２２７】
ステータス・メッセージ・ジェネレータ3162は、メッセージを実際に生成して、それらを、メモリ3154（1キロバイト）のステータス・メッセージ・ブロックに書き込む責を負っているモジュールである。ステータス・メッセージ生成要求は、送信DMAエンジン、ソケットDAV照会モジュール、あるいは、CPUから来ることができる。
【０２２８】
このセクションは、ソケット送信モジュール2700を扱う。次のモジュールは、インターネット・チューナ10Gとホスト・システムとの間にデータを送信するためのインターフェイスをハンドルする。
【０２２９】
図32を参照すると、フローが、ホストからのコマンド・ブロック・リストの受け取りで始まる。これは、DMA転送を介して受信され、コマンドリスト3202に置かれる。ここから、ブロックが、コマンド・パーザ・モジュール3204によって抽出されて、解析される。パーザによって認識されたコマンドは実行され、認識されなかったコマンドは、ローカルプロセッサに送られる。
【０２３０】
そのコマンドが、データを転送するためのものである場合には、link_list情報が、CBアドレスとともに、コマンド・ブロックから抽出されて、転送キュー3206に置かれる。
【０２３１】
受信DMAエンジン・モジュール3208が、このキューからエントリを受け取り、ホストメモリからのデータ転送を実行する。データは、1対のピンポンFIFOバッファ3296, 3298に置かれる。ちょうど受信されたデータに連係するCBアドレスが、ソケット送信データ制御モジュール3294に渡される。
【０２３２】
ソケット送信データ制御モジュールは、FIFOからデータを受け取って、それらを、送信ソケット・データ・メモリ3292に置く。それは、malloctxメモリ・アロケータ3200から、ブロック・アドレスを得る。制御モジュールは、また、ソケットCBに、そのソケットの優先順位レベルに関して照会を行う。全てのデータが、データ・バッファに転送されてしまうと、そのモジュールは、そのCBアドレスを、4つの優先順位キュー3280, 3282, 3284, 3286のうちの1つに入れる。ソケット送信制御モジュールは、また、ソケットCB 3290を、新しいデータ送信カウント情報で更新する。
【０２３３】
データが、DMA受信FIFOからソケット・データ・メモリに転送されると、ランニング・チェックサムが、そのときに遂行される。そのチェックサムは、ブロックごとに計算される。これは、その後、データが再度通読される必要がないから、送信待ち時間を縮小するのに役立つ。
【０２３４】
以下のセクションは、TCP送信モジュール2704を扱う。TCP送信モジュールは、どのソケットが、データ送信のために次に情報を提供されなければならないかを決定し、そして、それにしたがってソケットCBブロックを更新する責を負っている。
【０２３５】
図33を参照すると、TCP送信データ・フローは、ソケット照会モジュールが、XMT_DAVビット・テーブルを通過して、送信データに利用可能なビット・セットを持つエントリを捜すことでスタートする。それが、1つのエントリを見つけると、それは、その後、そのエントリを、ソケットのUser_Priorityレベルにしたがって、4つのキュー3330, 3332, 3334, 3336のうちの1つに入れる。優先順位レベル7または6のソケットは、キューリスト3 3336に入れられ、レベル5および4のソケットは、キューリスト2 3334に入れられ、レベル3および2のソケットは、キューリスト1 3332に入れられ、レベル1および0のソケットは、キューリスト0 3330に入れられる。
【０２３６】
これらのリストはすべて、パケット・スケジューラ3350に流れ込む。このスケジューラは、スターブしないように優先順位キューからパケットを抜き取る責を負っている。実際のアービトレーション・パターンはプログラム可能で、次のセクションで扱われる。このスケジューラは、また、HOサポートモジュールから生成されるSYN_ACKパケット間およびRSTパケット間のほかに、送信データ・パケット間も調停する。
【０２３７】
パケット・スケジューラが、どのパケットを次に送り出すかを決定すると、それは、この情報を、ソケット送信ハンドラ・モジュール3352に配布する。ソケット送信ハンドラ・モジュールは、ソケットCB情報3338, 3342, 3344を読み出し、パケット・ヘッダを生成し、CBを更新し、そして、パケット送信情報を送信キュー3354に渡す。パケット・ヘッダは全て、別個のメモリ・バッファ3340, 3346内で生成され、それは、その後、データ・バッファにプリペンドされる。これは、また、送られるべきデータが、データ・バッファの中央でスタートする場合に当てはまる。この場合には、パケット・ヘッダデータ・バッファからのポイントが、送られるデータの最初のバイトを指す。このモジュールが、同時に別のモジュールが動作させているかもしれない同様のソケットCBを修正してしまわないようなロッキング機構が用いられる。
【０２３８】
送信キュー・モジュールは、マスタ送信アービトレータに送られるデータ・パケットのキューをつくる責を負っている。
【０２３９】
このセクションは、パケット・スケジューラ・モジュール3350を扱う。パケット・スケジューラ・モジュールは、どのパケットが次に送信されるかを決定する責を負っている。図34は、パケット・スケジューラ・モジュールのブロック図を示している。
【０２４０】
そのプロセスは、コンパレータ3482が、現在の状態にあるキュー番号を受け取って、そのキューに、送られるべき何かがあるかどうかを確かめることでスタートする。そのキュー番号は、キューリスト3480のうちの1つ、あるいは、TCP受信パケットを表わすことができる。待機している、そのタイプのパケットが存在すれば、そのエントリは、次に送信されるパケット3484として抜き取られて、スケジュール化される。そのキューに何らのパケットも存在しなければ、状態カウンタがインクリメントされて、次のキュー状態がチェックされる。これは、キュー#が、送信の準備ができているパケットを持っているキューリスト(あるいはTCP受信パケット)と一致するまで、または、状態エントリのエンドビットがセットされるまで、継続する。エンドビットがセットされると、状態カウンタは、0にリセットバックされる。キュー・アービトレーション・シーケンスは、プログラム可能である。アプリケーションが、最初に、Queue_Stateレジスタを0x00にセットし、次に、キュー番号およびエンドビットをQueue _Entryレジスタに書き込むことによって、これをセットすることができる。Queue_Stateレジスタのフラット・ビットとステープビットとのどちらかをアサートすることによってセットすることができる2つの内蔵アービトレーション・シーケンスがある。これらの内蔵シーケンスが、以下に記述される。
【０２４１】
・  フラット・シーケンス。これは、スケジューラが任意のリセットの後に用いるデフォルト・シーケンス状態である。これは、また、Tシーケンス・レジスタのseq_progフィールドを、01に書き込むことによってセットすることができる。
【０２４２】
・  ステープ・シーケンス。前もってプログラムされたフラット・シーケンスに換わるものが、ステープ・シーケンスである。このシーケンスは、優先順位の高いキューほど大きな重みを与え、多くの優先順位の高いアプリケーションが同時に走っている場合に有用である。これは、Tシーケンス・レジスタのseq_progフィールドを、10に書き込むことによってセットされる。
【０２４３】
このセクションは、ハッシュ・アルゴリズムを扱う。インターネット・チューナ10Gで用いられているハッシュ・アルゴリズムは、ソケットの送信元ポートと送信先ポート、および、送信元IPアドレスと送信先IPアドレスを組み合わせて、単一の17ビット・ハッシュ値を形成する。そのアルゴリズムは、極度に単純化するように設計されており、それによって、ハッシュLUT衝突を最小限にするのに十分な広がりの分布範囲を持つと同時に、単一クロック・サイクル結果を生じる。
【０２４４】
このセクションは、ISNアルゴリズムを扱う。インターネット・チューナ10Gで用いられているISNアルゴリズムは、RFC1948に記載されているそれと同様であり、4つのマイクロ秒をベースとしたタイマ、本システムによってセットできる任意のブート（起動）値、および、4つのソケット・パラメータ（送信元と送信先とのポートおよびIPアドレス）を組み込んでいる。
【０２４５】
このセクションは、TCP送信データ・バッファ・ヘッダ定義を扱う。TCPデータが記憶される各MTXブロック内に、128ビット・ヘッダが保持される。このヘッダのフォーマットは、以下のように定義される。
【０２４６】
最初のビット・ワード
[63:62]       tcp_block_size（01= 2K、00 = 128）
[61:59]       tcp_block_type（000 = データ、001 = RST）
[58]   有効な次のリンク・フィールド
[57:32]       次のブロック・リンク
[31:28]       使用未定の4ビット
[27:16]       ブロック・データ長（ヘッダ・ワードを含まない）
[15:0] tcp_block_checksum
2番目の６４ビット・ワード
[63:32]       使用未定の32ビット
[31:0] ブロックのシーケンス番号
このセクションは、ソケット特定iAPIレジスタ・マップを扱う。これらのレジスタは、与えられたソケットに特定のものである。これらのレジスタは、以下の2通りのうちの1つでアクセスされる。第1の方法は、新しいソケットが初期化されるべきときに用いられる。この場合には、Socket_Controlレジスタ(0x46)のNew_Sckビットが、アサートされる。このビットがアサートされると、TCP_Statレジスタのsck_reg_valビットがディアサートする。次に、システムが、これらのレジスタに新しいソケット情報を書き込むことができる。ソケットを確立するために、システムは、最初に、Socket_Handleレジスタを書き込む。これは、sck_reg_valビットおよびNew_Sckビットをクリアする。ソケットの制御ブロック(CB)情報が検索されると、TCP_Statusレジスタのsck_reg_valビットが、再アサートする。
【０２４７】
このセクションは、確立したソケットCB構造を扱う。表2は、確立したソケットに対するメモリのCB構造の全フィールドをリストしている。
【０２４８】
表2.  確立されたソケット制御ブロック構造
表3は、HOソケットのためのメモリ内のメインCB構造を定義している。さらに、次のセクションで記述されるアネックスCBが存在する。
【０２４９】
表3.  ハーフ・オ−プン・ソケットのメインCB構造
表4は、HOソケットのためのメモリ内のアネックスCB構造を定義している。メインCB構造は、前のセクションで定義されている。アネックスHO CBは、メイン・セクションにはまらないオーバーフロー情報を記憶する。各HO CBは、1つのメイン・セクションおよび1つのアネックス・セクションを持っている。
【０２５０】
表4.  ハーフ・オ−プン・ソケットのアネックスCB構造
表5は、TW状態のソケットのためのメモリ内のCB構造を定義している。
【０２５１】
表5.  タイム・ウェイト制御ブロック構造
このセクションは、TCP輻輳制御サポートを扱う。インターネット・チューナ10Gは、スロー・スタート、輻輳回避、高速再送、高速回復のアルゴリズムをインプリメントしている。
【０２５２】
さらに、そのチューナは、同時に2つ以上のセグメントの時間を測定することをイネーブルにする往復遅延時間(round-trip time)TCPオプションをサポートしている。この特徴は、高バンド域環境のために必要である。
【０２５３】
このセクションは、往復遅延時間測定を扱う。インターネット・チューナ10Gは、2通りに往復遅延時間(RTT)を測定することができる。在来の方法では、時間測定は、PSHパケットのためのACKが受信されるときのTCP PSHパケットから受け取られた。時間測定されるパケットのシーケンス番号が、CBの時間測定されるパケットフィールドのシーケンス番号に記憶され、また、そのパケットのタイム・スタンプが、CBの最後の送信フィールドのタイム・スタンプに記憶される。時間測定されるパケットのACKが受信されたとき、現在（そのとき）のタイム・スタンプと記憶されているタイム・スタンプとの間の差が、RTTである。ACKが受信されると、そのソケットCBのRTO[1]ビットがクリアされて、次のパケットの時間が測定できることを指示する。
【０２５４】
RTTオプションが、TCPハンドシェークの開始している状態においてネゴシエートされているときには、RTT測定は、受信された各ACKから受け取ることができる。
【０２５５】
RTT測定を得るために用いられる方法がどうであっても、その値を受け取って、再送タイムアウト(RTO)値を決定する論理フローは、同じである。
【０２５６】
計量化されて平滑化されたRTT、平均偏差、および、RTOはすべて、ソケットCBに記憶される。
【０２５７】
このセクションは、スロー・スタート・アルゴリズムを扱う。ネットワーク・スタックは、すべてのTCPコネクションにスロー・スタート・アルゴリズムをサポートしている。このアルゴリズムは、ソケットが最初に確立されるときに1 MSSに初期化される輻輳ウィンドウ・パラメータ(cwnd)を用いる。
【０２５８】
スロー・スタート・アルゴリズムは、ソケットが最初に確立されたとき、1つのパケットしか送り出すことができず、そのパケットのACKが受信されるまでは、それ以上のデータを送信することができないことを命令する。ACKが受信されると、cwndは、1 MSSだけ増加する。それは、2つのパケットまで送信されることを可能にする。ACKが受信される毎に、cwndは、1 MSSだけ増加する。
【０２５９】
これは、cwndが、ピアから通知されるウィンドウ・サイズを越えるまで継続する。これは、cwndが、ピアから通知されるウィンドウ・サイズを越えるまで継続する。ネットワーク・スタックは、常に、cwndの最小値および通知されるウィンドウを送る。
【０２６０】
ネットワーク・スタックが、ICMP送信元喪失メッセージを受け取った場合には、それは、cwndを、1 MSSにリセットし直す。しかしながら、スロー・スタートしきい変数(ssthresh)は、その同じ値に維持される（ssthreshについてのより詳細な情報に関しては次のセクションを参照のこと）。
【０２６１】
このセクションは、輻輳回避アルゴリズムを扱う。ネットワーク・スタックは、cwndの最小値およびピアから通知されるウィンドウを送り出し続ける。輻輳回避アルゴリズムは、また、0xFFFFに初期化されるスロー・スタートしきい変数(ssthresh)を用いる。
【０２６２】
輻輳が、タイムアウトを介して検出されると、ssthreshは、現在の送信ウィンドウ（cwndの最小値およびピアから通知されるウィンドウ）の2分の1にセットされる。この値が、そのとき、MSSの2倍よりも小さければ、この値が、替わって用いられる。また、cwndは、1 MSSにセットされる。
【０２６３】
新しいデータが確認応答されると、cwndは、それがssthreshより大きくなるまで、1 MSSだけ増加する（それで、この名前がついている）。その後は、cwndが、1/cwndだけずつ増加する。これは、輻輳回避フェーズである。
【０２６４】
このセクションは、高速再送アルゴリズムおよび高速回復アルゴリズムを扱う。ネットワーク・スタックが、ACKを二重に受信した場合には、それは、パケットが失われたという強い徴候である。n重に重複したパケットが受信されたら、失われたセグメントは、たとえその再送タイマがまだ満了していなかったとしても、直ちに再送される。これが、高速再送アルゴリズムである。再送信が起きる前に受信されなければならない重複ACKの数は、TCP_Dup_ACKレジスタ(0x36)を介してセットでき、3つまで不履行とされる。
【０２６５】
指定された数の重複ACKパケットが受信されると、ssthreshは、輻輳回避アルゴリズムの場合がそうであったように、この場合にも、現在のウィンドウ・サイズの2分の1にセットされるが、このとき、cwndは、ssthresh + (3 * MSS)にセットされる。これは、重複ACKパケットを受信した後、スロー・スタート・アルゴリズムではなく、輻輳回避アルゴリズムに戻ることを確実にする。他の重複ACKパケットが受信されるごとに、cwndは、1 MSSずつ増加する。これが、高速回復アルゴリズムである。
【０２６６】
新しいデータに対するACKパケットが受信されると、cwndは、ssthreshにセットされる。
【０２６７】
このセクションは、どのようにMSSオプションが導出されるかを概説する。TCP処置をイネーブルにするに先立って、ホスト・システムは、以下のパラメータおよびセッティングをセットアップしなければならない。
【０２６８】
・  レジスタ0x1A4A-0x1A4Bで用いられるデフォルト非ローカルMSS
・  レジスタ0x1A4C-0x1A4Dで用いられるデフォルトローカルMSS
このセクションは、MSS選択アルゴリズムを扱う。任意のコネクションに用いるために、2つのMSS値のどちらかを選択する時、TCPエンジン・モジュールは、IPルータ・モジュール照会を行う。送信先経路がゲートウェイを通る場合には、非ローカルMSSが用いられる。
【０２６９】
このセクションは、サポートされているTCPオプションおよびそれらのフォーマットを概説する。サポートされている4つのオプションは、次の通りである。
【０２７０】
・  MSS
・  ウィンドウ・スケーリング
・  タイム・スタンプ
SACK
【０２７１】
このセクションは、MSSオプションを扱う。このオプションは、常に組み入れられている。用いられるMSS値は、前のセクションで説明されたアルゴリズムを通じて決定される。このオプションのフォーマットは、以下の通りである。
【０２７２】
このセクションは、ウィンドウ・スケーリング・オプションを扱う。ウィンドウ・スケーリング・オプションは、Sl_Win_EnビットがTCP_Controlレジスタにセットされている限り、SYNパケットに常に組み入れられる。それは、そのオプションが、SYN/ACKパケット応答を生成したSYNパケットに含まれていた場合しか、SYN/ACKパケットに組み入れられない。そのオプションのフォーマットは、以下の通りである。そのオプションが4バイト境界上にならぶように、1つのNOPバイトが、常に、それに先行することに注意されたい。
【０２７３】
このセクションは、タイム・スタンプ・オプションを扱う。このオプションは、SYNパケットに常に組み入れられ、また、そのオプションが、SYN/ACK応答を生成したSYNパケットに含まれていた場合しか、SYN/ACKパケットには組み入れられない。それは、そのオプションが4バイト境界上にならぶように、2つのNOPバイトに常に先行されることに注意してされたい。タイム・スタンプ・オプションのフォーマットは、以下の通りである。
【０２７４】
このセクションは、選択ACK(SACK)オプションを扱う。このオプションは、SACK_EnビットがTCP_Controlレジスタにセットされている限り、SYNパケットおよびSYN/ACKパケットに常に組み入れられる。SACKは、2つの相異なるTCPオプション種類を用いる。1つは、SYNパケットで用いられ、他の1つは、データ・パケットで用いられる。それらのオプションのフォーマットが、以下に示される。
【０２７５】
2005502225.tif 000004
SACK可能
SACKオプション
SACKオプションは、1穴報告(one-hole reporting)に制限されている。
【０２７６】
以下のセクションは、IPルータ・モジュールを扱う。IPルータ・モジュールの特徴は、以下の通りである。
【０２７７】
・  デフォルトルーティング（経路制御）能力を備える。
・  複数のホストIPアドレスに対するルーティングを備える。
・  ホスト指定経路およびネットワーク指定経路を供給する。
・  ICMPがリダイレクトした後、動的に経路を更新する。
・  IPブロードキャスト（リミテッド・ブロードキャスト、サブネット・ディレクテッド・ブロードキャストおよびネットワーク・ディレクテッド・ブロードキャスト）アドレスをハンドルする。
・  IPループ・バック・アドレスをハンドルする。
・  IPマルチ・キャスト・アドレスをハンドルする。
【０２７８】
このセクションは、IPルータ・モジュールがどのように経路を要求するか説明する。図35に関すると、ローカル・ホスト・システムが、IPパケットを送信したいとき、それは、そのパケットをどこに送るべきであるか−そのローカル・エリア・ネットワーク上の他のホストにか、外部ネットワークにか、それとも、そのローカル・ホスト・システム自体に戻すのかのいずれかに−決めなければならない。出ていくIPパケットを適切なホストに宛てるのが、IPルータ・モジュールのタスクである。
【０２７９】
送信モジュールが、経路を要求するとき、その送信モジュールは、パケットの送信先IPアドレスをIPルータに渡す。次に、IPルータは、ターゲットとされたIPアドレスを、IP経路リスト3520に記憶されている送信先のリストと比較する。一致が見出されると、IPルータは、適切なイーサネット・アドレスに解決しようとする。そのルータは、この解決を、ARPキャッシュ中の送信先IPアドレスに対するARPルックアップを要求することによって遂行する。送信先イーサネット・アドレスが解決されると、それは、このイーサネット・アドレスを、出ていくイーサネット・フレームの送信先として用いる送信モジュールに渡される。
【０２８０】
経路情報は、3つの別々の構成要素：デフォルト経路レジスタ3522、カスタム経路リスト3520、アンルータブル・アドレス・キャッシュ3526、によって供給される。これらの構成要素は全て、経路要求が出されたとき、同時に照会される。
【０２８１】
このセクションは、IPルータ・モジュールがどのようにデフォルト経路を決定するかを説明する。パケット送信先は、ローカルか外部かのどちらかであるとして記述される。ローカル送信先は、送信しているホストと同じローカル・エリア・ネットワークに配されている。外部送信先は、送信しているホストのローカル・エリア・ネットワークと別個のネットワークに属している。
【０２８２】
出ていくパケットの送信先IPアドレスが、ローカル・エリア・ネットワークに配されたホストに属することが見出されると、IPルータは、ARPを用いて、送信先IPアドレスを、その対応するイーサネット・アドレスに解決しようとする。送信先IPアドレスが、外部ネットワークに属すると決定されると、IPルータは、出ていくパケットを、その外部ネットワークに伝えるために、どのゲートウエイ・ホストを用いるべきであるか決めなければならない。ゲートウエイ・ホストが選択されれば、出ていくIPパケットは、それらの送信先イーサネット・アドレスとして、そのゲートウエイ・ホストのイーサネット・アドレスを用いる。IPルータ・モジュールが、パケットの送信先IPアドレスに対する経路を見出すことができない場合には、そのパケットは、デフォルト経路によって指定されるゲートウエイ・ホストを用いなければならない。デフォルト経路は、他のどんな経路も、与えられた送信先IPアドレスに対して見出すことができないときしか、用いられない。
【０２８３】
ARPキャッシュへのアクセス数を最小限にするために、デフォルト経路がセットされたとき、IPルータ・モジュールは、デフォルト・ゲートウェイのイーサネット・アドレスをキャッシュする。デフォルト・ゲートウェイのイーサネット・アドレスは、最大で、エントリがARPキャッシュに動的にキャッシュされていることを許される時間に等しい時間量の間、キャッシュされる。
【０２８４】
このセクションは、IPルータ・モジュールが、どのようにブロードキャスト送信先とマルチ・キャスト送信先とをハンドルするかを説明する。送信先IPアドレスが、ブロードキャストIPアドレスまたはマルチ・キャストIPアドレスである場合には、ARPルックアップは、必要ではない。その代りに、IPルータ・モジュールは、IPアドレスのタイプに依存して、動的に送信先イーサネット・アドレスを生成する。IPブロードキャスト・アドレス(255.255.255.255)にセットされた送信先IPアドレスを持つパケットは、イーサネット・ブロードキャスト・アドレス(FF:FF: FF:FF)に送られる。マルチ・キャストIPアドレス(224.x.x.x)にセットされた送信先IPアドレスを持つパケットは、そのマルチ・キャストIPアドレスから計算される送信先イーサネット・アドレスを持つ。
【０２８５】
このセクションは、IPルータ・モジュールがどのように静的経路を扱うかを説明する。デフォルト経路に加えて、IPルータ・モジュールは、送信先IPアドレスを、特定のイーサネット・インターフェイスあるいはゲートウエイ・ホストにマップするために、静的経路を生ぜしめることを可能にする。IP経路エントリには、送信先IPアドレス、ネットマスク、および、ゲートウェイIPアドレスが含まれる。ネットマスクは、一連の送信先IPアドレスを、IP経路エントリの内部に記憶された送信先IPアドレスと一致させるために用いられる。ネットマスクは、また、特定のホストの経路とネットワークの経路の区別を可能にする。ゲートウェイIPアドレスは、ARPを介して送信先イーサネット・アドレスを解決するときに用いられる。
【０２８６】
IP経路リストには、多数の経路を持つことが可能であるから、IP経路エントリは、動的に割り付けられたm1メモリに記憶される。各IP経路エントリは、128ビットを用いる。各エントリの最後の32ビットは、何らのデータも記憶しないで、64ビット境界に沿ってIP経路エントリを整列させるためのパディングとして用いられる。
【０２８７】
各IP経路エントリのフォーマットは、以下の通りである。
【０２８８】
IP経路エントリ・フォーマット
IP経路リストは、ソートされたリンクリストとしてインプリメントされる。IP経路が、IP経路リストに加えられると、それらは、最上位に特定的なIP経路がIP経路リストの最前に現われ、最下位に特定的なIP経路がIP経路リストの最後になるように、それらのネットマスクにしたがって順序づけられる。IP経路エントリの経路ポインタ・フィールドには、次のIP経路エントリをm1メモリで見出すことができるm1メモリ・アドレスが含まれている。経路ポインタ・フィールドの最初の（最上位の）ビットは、そのm1メモリ・アドレスが有効で、かつ、現在の経路に続く経路が存在するかどうかを決定するためのフラグとして用いられる。経路ポインタ・フィールドのポインタ有効ビットが、アサートされていなければ、IP経路リストに、それ以上のIP経路が全く存在せず、IP経路リストの終端に達している。
【０２８９】
送信先IPアドレスがブロードキャストIPアドレスまたはマルチ・キャストIPアドレスであると決定されない場合には、そのIP経路リストが、一致するIP経路エントリを求めて探索される。一致が、IP経路リストで見つからない場合には、デフォルト経路が、ゲートウェイ情報を供給するために用いられる。
【０２９０】
IPルータ・モジュールは、また、複数の物理インターフェイスおよびループ・バックインターフェイスの使用を可能にする。IP経路エントリのインターフェイス識別フィールドを用いて、IPルータは、出ていくパケットを、インターネット・チューナ10Gの特定のイーサネット・インターフェイスに向けることができる。インターフェイス識別フィールドは、また、ARP要求を、適切なイーサネット・インターフェイスに向けるためにも使用される。
【０２９１】
このセクションは、IPルータ・モジュールが、どのようにループ・バック・アドレスをハンドルするかを説明する。送信先IPアドレスが、ローカル・ホスト・システムのIPアドレスの1つ即ちループ・バック・アドレス(127.x.x.x)と同じであれば、出ていくパケットは、ホスト・システムにフィードバックされることになっている。ループ・バック送信先の経路は、静的経路リストに記憶されている。ホスト・システムに割り当てられないIPアドレスも、ループ・バック・アドレスとして構成してもよい。このローカルリダイレクションをイネーブルにするために、インターフェイス識別は、0x0000(ループ・バック)にセットされなければならない。そうでなければ、インターフェイス識別は、イーサネット・インターフェイス(0x0001, 0x0002など)のうちの1つにセットされなければならない。
【０２９２】
このセクションは、IPルータ・モジュールがどのように経路を作り出すかを説明する。新しいIP経路は、内部プロセッサから来ることができる。内部プロセッサによって作り出されるIP経路は、それらが、内部プロセッサによって削除されるまでテーブルに存続しているということを意味する、静的経路である。内部プロセッサは、IPルータ・モジュールのレジスタインターフェイスを介して経路を加え、また、除去する。
【０２９３】
IPパケットが、間違ったゲートウエイ・ホストに送られているとき、ICMPリダイレクト・メッセージが、送信される。ICMPリダイレクト・メッセージは、普通、間違った経路のIPパケットに対して使用するために、正しいゲートウエイ・ホストの情報を含んでいる。ICMPリダイレクト・メッセージが受信されると、そのメッセージは、システム・インターフェイスによって処理される。IPルータのレジスタインターフェイスを介して経路リストを更新することは、システム・インターフェイスの責任であり、そのときに存在しているIP経路を更新し、あるいは、新しいIP経路を作り出す。
【０２９４】
このセクションは、IPルータ・モジュールが、どのようにローカル・ネットワーク上のホストに対するルーティングをハンドルするかを説明する。ローカルイーサネットネットワーク上の他のホストにパケットを直接発送するために、インターネット・チューナ10GのサブネットマスクによってIP経路が、作り出されなければならない。この経路に対するゲートウェイとして、もう1つのホストを指定する代わりに、ゲートウェイIPアドレスは、この経路が、ローカル・ネットワークを通る直接接続に帰することを指示する0.0.0.0にセットされなければならない。
【０２９５】
このセクションは、IPルータ・モジュールが、どのように経路要求信号制御をハンドルするかを説明する。各送信モジュールは、IPルータ内に、経路要求のためのそれ自身のインターフェイスを持っている。
【０２９６】
図36は、経路を要求し、また、受信するために用いられる信号制御を図解している。
【０２９７】
モジュールが、経路を要求しているとき、それは、経路要求信号(例えば、TCP_Route_Req)をアサートし、そして、ルータに送信先IPアドレス(TCP_Trgt_IP)を供給する。ルータが、経路を見出すと、それは、経路完了信号をアサートし、そして、送信先イーサネット・アドレスを出力する。経路が成功のうちに見出されると、route_valid信号が、それを送信モジュールに指示するために用いられる。経路完了信号がアサートされたときに、それがアサートされると、有効な経路が、見出されたことになる。route_validビットがアサートされないと、それは、ルーティングが、失敗だったことを意味する。これは、デフォルト・ルートやゲートウェイをダウンさせないで、かつ、ARP要求に応えないような、いくつかの原因によるものであり得る。経路失敗の場合において、その後再度、経路を待ち受け、そして、解決しようとする、あるいは、現在の接続試みを終了させることは、送信モジュールの責任である。
【０２９８】
経路が、ホストまたはゲートウェイのイーサネット・アドレスを解決するために、ARPルックアップを必要とする場合、そのイーサネット・アドレスがARPキャッシュ内に見出されなければ、遅延を起こすことは可能である。キャッシュミスがあったとき、そのキャッシュは、IPルータに通知する。その後、ルータは、キャッシュミスが生じたことを、適切な送信器(IP TX, TCP TX, ローTX)に合図する。この時点で、送信モジュールは、現在の接続を遅らせ、キュー中の次の接続を出し、別の経路を要求することを選ぶことができる。送信構成要素が、その経路要求を取り消したとしても、ARPルックアップは継続し、そのゲートウェイが、アクティブであれば、そのイーサネット・アドレスは、後の使用を可能にするために、ARPキャッシュに加えられる。注：IPルータは、複数の出ていくARP要求を持つことができる。
【０２９９】
このセクションは、IPルータ・モジュールが、どのように個々の経路の表示をハンドルするかを説明する。静的経路を作り出した後、ユーザは、経路テーブルに記憶されたエントリを、2通りに読み返すことができる。ユーザが、与えられた経路のターゲットIPアドレスを知っていれば、Show_Routeコマンドコードを用いて、その経路のネットマスクおよびゲートウェイを表示することができる。
【０３００】
経路テーブル内の全てのエントリを表示するために、Show_Indexコマンドを用いることができる。Route_Indexレジスタを用いて、システム・インターフェイスは、特定性の順に経路にアクセスすることができる。特定性の大きい（ホスト）経路が、最初に表示され、特定性の小さい（ネットワーク）経路が、その後に続く。例えば、route_index 0x0001を備えたIP経路エントリは、IP経路リストで最も特定性の大きい経路である。注：デフォルトは、インデックス0(0x0000)に記憶される。経路が、成功のうちに見出されると、Route_Foundレジスタが、アサートされ、そして、経路データが、Route_Trgtレジスタ、Route_Maskレジスタ、および、Route_Gwレジスタに記憶される。
【０３０１】
このセクションは、IPルータ・モジュールが、どのようにして解決不能の送信先のキャッシングをハンドルするかを説明する。IPルータ・モジュールが、送信先ホストまたは送信先ゲートウェイに対するイーサネット・アドレスを解決することができないとき、そのIPルータ・モジュールは、その送信先IPアドレスを20秒間キャッシュしておく。その時間の間に、IPルータ・モジュールが、それらのキャッシュされている解決不能の送信先のうちの1つに対する要求を受信すると、そのIPルータ・モジュールは、直ちに、経路を要求しているモジュールに、経路失敗で応答する。この解決不能の送信先のキャッシングは、ARPキャッシュ・エントリが記憶されている共有m1メモリへのアクセス回数を減少させるためのものである。解決不能の送信先のキャッシングは、また、冗長なARP要求を回避するのに役立つ。解決されないアドレスをキャッシュできる時間量は、Unres_Cache_Timeレジスタを介して、ユーザが構成可能である。
【０３０２】
以下のセクションは、システム例外ハンドラ・モジュール1768を扱う。図37を参照すると、システム例外ハンドラ・モジュールは、インターネット・チューナ10Gの専用の処理ハードウェアが直接ハンドルすることができないデータが存在するときにはいつでも、呼び出される。このデータは、未知のイーサネット・タイプパケット、IGMPパケット、TCPオプション、あるいは、IPオプションなどであり得る。これらの場合の各々において、初期パーザが、例外の場合を検知したときに、このモジュールをイネーブルにする。その後、システム例外ハンドラ・モジュールは、データを記憶し 3742, 3746、ハンドルされるべき例外データが存在することをシステムに通信し 3744、そして、そのデータをホスト・システムに渡す 3740、責を負う。
【０３０３】
このセクションは、システム・インターフェイス・モジュールを扱う。システム・インターフェイス・モジュールは、システム・コントローラとインターフェイス接続している。システムに利用可能な何らかの例外データが存在するとき、それは、割り込みを介してシステムに信号で知らせる。システム・インターフェイスは、利用可能な例外データのタイプを、利用可能なデータ量とともに指示する。次に、システム・コントローラは、このモジュールを通して、そのデータを読み出すこともできるし、あるいは、このモジュールから、そのデータに対するメモリ・ポインタを得ることもできる。後者の場合には、次いで、システム・コントローラは、そのデータを直接読み出すことができる。この場合、システムは、メモリ・バッファを自由に使えるようにするために、全てのデータを読み出したときに、例外ハンドラに通信しなければならない。
【０３０４】
このセクションは、Mem_Blockリクエスタを扱う。このモジュールは、メモリ・アロケータにメモリ・ブロックを要求する責を負っている。それは、また、メモリアクセス中のアドレス生成もハンドルする。ブロックが自由に使えるようになると、このモジュールは、また、それらのブロックをメモリ・アロケータに戻して渡す責も負う。このモジュールは、任意の与えられた時間に利用可能な、少なくとも1つの予備メモリ・ブロックを常に持っている。
【０３０５】
このセクションは、制御信号ジェネレータ・モジュールを扱う。制御信号ジェネレータ・モジュールは、メモリ・コントローラ・モジュールとインターフェイス接続して、メモリ制御信号を生成する責を負っている。このインターフェイスは、要求/授与ハンドシェークプロトコルを用いる。
【０３０６】
全ての入力信号および出力信号は、クロックの立ち上がりエッジに同期している。
【０３０７】
これは、メモリ書き込みを制御するためのFIFOである。このFIFOは、16ワード深さ（即ち、16 x 64 ビット)である。
【０３０８】
以下のセクションは、IPモジュール、ARPキャッシュ、経路テーブル、および、内部プロセッサのために用いられるメモリ・アロケータ・モジュールを詳述する。メモリ・アロケータ・モジュールは、最初にm1メモリを個別のブロックに分け、それらを要求に割り付け、そして、自由に使えるようになったブロックをスタックに戻す責を負っている。メモリ・アロケータ・モジュールは、その動作を始めるに先立って、2つのパラメータを入力される必要がある。それらは、m1メモリ・ブロックの総サイズ、および、各メモリ・ブロックのサイズである。1つのメモリサイズしか、メモリ・アロケータ・モジュールのこのインプリメンテーションにはサポートされていない。
【０３０９】
それら2つの必要とされるパラメータが入力された後、システムは、m1_Controlレジスタのm1_Enableビットをアサートする。これが起こると、メモリ・アロケータ・モジュールは、m1メモリ・ブロックのトップからスタートして、ブロック・アドレスを書き込み始める。例えば、m1メモリ・ブロックが、総計4キロバイト深さであり、 ブロックサイズが、512バイトであれば、m1メモリ・マップは、図38に示されるようになる。
【０３１０】
m1ブロック・アドレスのm1アドレス位置当り、4つのアドレスが、保持される。メモリに開始ブロック・アドレスを保持することに加えて、メモリ・アロケータ・モジュールは、また、16-エントリキャッシュも含有する。初期化に際して、最初の16アドレスが、キャッシュに保持される。ブロックが要求されたとき、それらは、キャッシュから受け取られる。キャッシュ数が0に達したとき、4つのアドレス（1メモリ読み出し）が、メモリから読み出される。さらに、キャッシュが、アドレスで一杯になったときには常に、4つのアドレスが、メモリに書き戻される（これは、メモリ・アロケータ・モジュールが、一番初めにm1メモリからアドレスを読み出した後でしか作用しない）。
【０３１１】
このセクションは、TX, RX, CBメモリ・アロケータ・モジュールを扱う。これらのメモリ・アロケータ・モジュールは、ソケット送信メモリ(malloctx)、ソケット受信メモリ(mallocrx)、および、CB(malloccb)メモリに対して用いられるメモリ・アロケータである。これらのメモリ・アロケータ・モジュールは、メモリ・ブロックを要求に割り付け、自由に使えるようになったブロックをスタックに戻し、そして、メモリの使用を調停する責を負っている。
【０３１２】
メモリ・アロケータ・モジュールは、動作を開始するに先立って、いくつかのパラメータを入力される必要がある。これらのパラメータは、MPメモリ空間内の開始アドレス・ポインタ位置および終了アドレス・ポインタ位置、および、各メモリ空間内の利用可能な各ブロックを表わすビット・マップである。2つのサイズのブロックが、ソケット・データ・メモリに利用可能である：128バイトおよび2キロバイト。CBメモリは、128バイトに固定したブロックを持っている。全てのアロケータは、また、ブロック・アドレス（各メモリサイズに対する）に対して8-エントリキャッシュを利用する。
【０３１３】
これらのパラメータが入力された後、システムは、制御レジスタにイネーブル・ビットをアサートする。そうすると、アロケータは、メモリ・ブロックの割り付け、および、割り付けの解放を開始することができる。
【０３１４】
このセクションは、TX SDRAMインターフェイスおよびデータ・フローを扱う。コアロジックのアービトレータは、TX SDRAMへの読み出しサイクルか、書き込みサイクルか、どちらかに決める。1つのサイクルが始まれば、それは、完結させられる。TX SDRAMに書き込まれているデータは、PCIバスとデータ・メモリとの間にある128 x 128ビットFIFOペアから来る。TXデータ・メモリから読み出されたデータが、MACモジュールとインターフェイス接続している64 x 128ビットFIFOに入れられる。
【０３１５】
このセクションは、512キロバイト雑メモリバンクを詳述する。雑メモリバンクは、以下にリストされた目的のために使用される。それらの特徴は、他のところで詳細に記述されている。
【０３１６】
・  ハーフ・オ−プンCB（メイン）
・  ハーフ・オ−プンCB（アネックス）
・  TCPポート許可テーブル
・  UDPポート許可テーブル
・  送信元ポート使用テーブル
・  タイム・ウェイトCB割り付けテーブル
・  確立されたCB割り付けテーブル
・  TXメモリ・ブロック割り付けテーブル（128バイト・ブロックと2キロバイト・ブロックとの両方に対する）
・  RXメモリ・ブロック割り付けテーブル（128バイト・ブロックと2キロバイト・ブロックとの両方に対する）
・  TCP RXからTCP TXへのパケットに対するFIFO
・  ソケット・データ使用可能ビット・マップ
・  サーバ・ポート情報
【０３１７】
このセクションは、雑メモリの編成および性能を扱う。図39を参照すると、この雑メモリは、物理的に256k x 16ビットとして編成されているが、この雑メモリを用いるモジュールの大部分は、この雑メモリを、あたかも、それが512k x 8ビットメモリであるかのように載せる。これは、全ての許可テーブルおよびアロケーションテーブルが、一度に1バイトしかメモリにアクセスする必要がないからである。HO CBデータ・パス、および、TCP RXからTCP TXに対するFIFO、および、サーバ・ポート情報は、フル16ビット・データ・パスを利用するリソースである。16ビット・データ・パスの必要性は、非常にわずかのクロック・サイクル内でデータにアクセスしなければならないHO CBから生じる。雑メモリは、単一サイクルメモリを用いてインプリメントされなければならない。性能要求は高くないが、アービトレーション・オーバヘッドのために、アクセス時間は、できるだけ短く保たれるべきである（ここでも、HO CBのために）。
【０３１８】
・  HO CB（メイン）3902。これらは、HO TCPコネクションのCBである。各CBは、サイズとして32バイトであり、合計4,000のCBがある。したがって、それらのHO CBに必要なバイトの合計数は、4キロバイト x 32 = 128キロバイトである。このリソースは、フル16ビット・データ・バスを用いる。
【０３１９】
・  HO CB（アネックス）3984。これらは、HO TCPコネクションのCBで、CBのメイン部にはまらなかった、補足情報を含んでいる。各アネックスCBは、サイズとして16バイトであり、合計4,000のアネックスCBがある。したがって、それらのHO CBに必要なバイトの合計数は、4,000 x 16バイト = 64キロバイトである。このリソースは、フル16ビット・データ・バスを用いる。
【０３２０】
・  TCPポート許可テーブル3900。このテーブルは、どのTCPポートが、コネクションをを受け取ることを許可されるかを追跡する。64,000の可能なポートの各々の1ビットが、保持されている。したがって、このテーブルは、64,000ビット/8 = 8キロバイトを用いる。
【０３２１】
・  UDPポート許可テーブル3998。このテーブルは、どのUDPポートが、コネクションを受け取ることを許可されるかを追跡する。64,000の可能なポートの各々の1ビットが、保持されている。したがって、このテーブルは、64,000ビット/8 = 8 キロバイトを用いる。
【０３２２】
・  送信元ポート使用テーブル3996。このテーブルは、どのポート番号が、ローカルに着手されるコネクションに用いられる送信元ポートに利用可能であるかを追跡する。64,000の可能なポートの各々の1ビットが、保持されている。したがって、このテーブルは、64,000ビット/8 = 8キロバイトを用いる。
【０３２３】
・  TW CB割り付けテーブル3988。これは、TW CBのための割り付けテーブルである。32,000のTW CBの各々に対して1ビットが、保持されている。したがって、この割り付けテーブルは、32,000ビット/8 = 4 キロバイトを用いる。このテーブルは、フル16ビット・データ・バスを用いる。
【０３２４】
・  確立されたCB割り付けテーブル3994。これは、確立されたCBのための割り付けテーブルである。64,000のCBの各々に対して1ビットが、保持されている。したがって、この割り付けテーブルは、64,000ビット/8 = 8キロバイトを用いる。
【０３２５】
・  TXソケット・データ・バッファブロック割リ付けテーブル3982。このテーブルは、2キロバイト・ブロック割リ付けテーブルと128バイトブロック割り付けテーブルとから構成され、動的に割り付けられる送信データ・バッファ・メモリに使用される。各タイプのブロック数は、構成可変であるが、組み合わされた両方の割り付けテーブルのサイズは、72 キロバイトに固定される。これには、最大で475,000の128バイト・ブロックを充てることが許可されている。このレベルで、2キロバイト・ブロックの数は、98,000である。
【０３２６】
・  RXソケット・データ・バッファブロック割リ付けテーブル3980。このテーブルは、2キロバイト・ブロック割リ付けテーブルと128バイトブロック割り付けテーブルとから構成され、動的に割り付けられる受信データ・バッファ・メモリに使用される。各タイプのブロック数は、構成可変であるが、組み合わされた両方の割り付けテーブルのサイズは、72 キロバイトに固定される。これには、最大で475,000の128バイト・ブロックを充てることが許可されている。このレベルで、2キロバイト・ブロックの数は、98,000である。
【０３２７】
・  TCP RX FIFO 3990。このFIFOは、TCP受信ロジックからTCP送信ロジックへのパケット送信要求を追跡するために用いられる。各FIFOエントリは、いくつかの制御フラグおよび1つのCBアドレスから構成され、合計4バイト(4つのフラグ、26ビットのアドレス、および、未使用の2ビット)である。このFIFOは、1024ワード深さで、したがって、1024 x 4バイト = 4キロバイトを必要とする。
【０３２８】
・  ソケット・データ利用可能ビット・マップ 3992。このビット・マップは、64,000のソケットのどれが、ホスト・システムに送られる準備ができているデータを持っているかを表わす。ソケットの各々に対して1ビットが、保持されている。したがって、このビット・マップは、64,000ビット/8 = 8 キロバイトを必要とする。
【０３２９】
・  サーバ・ポート情報3986。このデータベースは、待機状態にオープンされているTCPポートのパラメータ情報を記憶するために用いられる。それらのサーバ・ポートは、それらがオープンされるまで、それらに連係するCBを持たないから、ポートに特定のパラメータが、このエリアに保持される。各ポートエントリは、2バイトから構成され、64,000の可能なポートがある。したがって、このデータベースは、64,000 x 2バイト = 128 キロバイトを必要とする。
【０３３０】
このセクションは、雑メモリ・マップを扱う。雑メモリに使用されるメモリ・マップは、構成可変である。
【０３３１】
このセクションは、雑メモリ（即ちmiscmem）アービトレーションスキームを扱う。雑メモリ・アロケータは、さまざまな送信元からメモリ要求を受け取り、メモリ・ブロックへのアクセスについて、それらのメモリ要求間の調停をする。すべての要求のうち、HO CBへのアクセスに対するメモリサイクルが、最優先順位を与えられる。他のすべての送信元は、ラウンドロビン態様で、等しい優先順位に調停される。
【０３３２】
雑メモリアービトレータをアクティブにするのに先立って、内部プロセッサが初期化する必要のあることは、ほとんどない。デフォルト・メモリ・マップが、用いられるべきときには、内部プロセッサは、MiscMem_ControlレジスタのMM_Enableビットをアサートすることによって、アービトレータを簡単にイネーブルにすることができる。
【０３３３】
非デフォルト・メモリ・マップが、用いられるべきときには、基準アドレス・レジスタはすべて、アービトレータをイネーブルにするに先立って、初期化されなければならない。プログラムされた基準アドレスが、何らの重複するメモリエリアを引き起こさないことを保証するのは、ソフトウェアの責任である。これをチェックするどんなハードウェアも、用意されない。
【０３３４】
内部プロセッサは、雑メモリ内のどの位置にもアクセスすることができる。最初に、MM_CPU_Addレジスタ(0x1870―0x1872)内の1つのアドレスにプログラムし、次に、MM_CPU_Dataレジスタ(0x1874)に1バイトを読み出すか、または、書き込むことによって、これがなされる。アドレス・レジスタは、データ・レジスタがアクセスされる度毎に、自動的にインクリメントする。
【０３３５】
このセクションは、シリアル・ポート、SPI、および、テスト・インターフェイスを扱う。AUXシリアル・ポートは全て、標準の8ビット・シリアル・データ・フォーマットを用いる。シリアル・ポートは、16バイト受信FIFOおよびハードウェアフローの制御をサポートする。内部プロセッサが、全てのポート上で用いられるボーレートを制御し、それによって、全てのポートが、独立したボーレートをサポートすることができる。シリアル・ポート・テストモードは、内部プロセッサのテストモード・レジスタ(0x0000f0)にser_tstビットをセットすることにより、イネーブルとされる。オンチップ・プロトコル・プロセッサが、スレーブ（従）SPIデバイスを制御することができるように、マスター（主）SPIポートが設けられる。
【０３３６】
このセクションは、システムで用いられる割り込みコントローラ(INTC) 1688の概要を提供する。INTCは、全システム割り込みを集めて、それらを、内部プロセッサに流し込む。各割り込み元を、内部プロセッサ上でnFIQ割り込みかnIRQ割り込みかの一方に独立に導くことができる。
【０３３７】
このセクションは、インターネット・チューナ10Gで用いられる多目的タイマおよび監視タイマの概要を提供する。前のタイマと縦続接続されていてもよいし、あるいは、独立に用いられてもよい、8つの多目的32ビットタイマが、設けられる。全てのタイマが、単発モードか、あるいは、ループ（繰り返し）モードで動作することができる。さらに、メインのコアクロックを、それが各々のタイマによって用いられるのに先だって、分周できるクロック・プレスケーラが、設けられる。これは、異なるコアクロック周波数の変化を最小にする。
【０３３８】
このセクションは、コマンド・ブロック構造を詳述する。ホスト・システムは、コマンド・ブロックを用いて、コマンドをインターネット・チューナ10Gに渡す。コマンドは、ステータスを要求したり、ソケットを制御したり、データを送ったり、ホスト状態を報告したりすることを、含むことができる。コマンド・ブロックは、通例、DMAを用いてホスト・システムから転送される。インターネット・チューナ10Gが、コマンドを受信すると、それらのコマンドは、コマンドリストに入れられる。次に、コマンドは、コマンド・パーザ・モジュールによって、一度に1つ、構文解析される。次いで、コマンド・パーザ・モジュールが理解したコマンド・ブロックのどれをも、コマンド・パーザ・モジュールが、実行する。コマンド・パーザ・モジュールが、どのようにデコードするのか分からないコマンド・ブロックのどれをも、コマンド・パーザ・モジュールは、内部プロセッサに送る。
【０３３９】
コマンド・ブロックは、長さが可変である。コマンドのタイプにかかわらず、各コマンド・ブロックは、偶数のバイトから構成されなければならない。奇数バイト・コマンド・ブロックには全て、パディング・バイトが、用いられなければならない。
【０３４０】
ホストとインターネット・チューナ10Gとの間にコマンド・ブロック通信をインプリメントするときには、特別の注意を払わなくてはならない。コマンド・ブロックは、ホストメモリ内に循環キューで作り出される。その後、周期的に、あるいは、ホストの手引きによって、これらのコマンド・ブロックは、DMAを用いてインターネット・チューナ10Gに転送される。ホスト・システムとインターネット・チューナ10Gとの間の信頼できる通信を確実にするために、いくつかの手続きが続く必要がある。
【０３４１】
このセクションは、受信コマンド・ブロックについて説明し、また、内部プロセッサが、ホスト・システムからコマンド・ブロックを受け取るために通過しなければならないステップの要点を述べる。
【０３４２】
・  内部プロセッサは、受け取ったコマンド・ブロックをハードウェアに記憶させたいメモリ領域を割り付けなければならない。
【０３４３】
・  このメモリの開始アドレスが、Cmd_Addレジスタにプログラムされなければならない。
【０３４４】
・  このバッファの長さが、Cmd_FIFO_Lenレジスタにプログラムされなければならない。
【０３４５】
・  コマンド・ブロックが利用可能なときに、内部プロセッサが、割り込みを介して通知してもらいたければ、それは、Cmd_Stat_ControlレジスタにCmd_Int_Enビットをセットしなければならない。
【０３４６】
・  これがすべて入力されたとき、内部プロセッサは、Cmd_Stat_ControlレジスタにCmd_Enビットをアサートする。このビットのセッティングは、ハードウェア・コマンド・パーザが、コマンドを内部プロセッサに渡し始めることをイネーブルにする。このビットがアサートされる前に、ハードウェアパーザがコマンド・ブロックを受け取ったら、そのハードウェアパーザは、そのコマンド・ブロックを黙って破棄する。
【０３４７】
・  ハードウェアが、コマンド・ブロックを受信すると、そのハードウェアは、Cmd_Addレジスタによって指定されたバッファに、それらを記憶し始める。ハードウェアが、内部プロセッサメモリへのコマンド・ブロックの書き込みを完了した後、そのハードウェアは、Cmd_Stat_StatレジスタにCmd_Recビットをアサートする。Cmd_Recビットがアサートされてしまった後、さらなるコマンド・ブロックが受け取られたら、ハードウェアは、内部プロセッサによって指定されたFIFOに、それらの書き込みを継続する。
【０３４８】
・  それがFIFOの終端まで達したら、アドレスは、始点（Cmd_Addレジスタによって指定される）に周回する。
【０３４９】
・  内部プロセッサは、それが、提出される全てのコマンド（Cmd_Rec_Lenレジスタによって指定される）を読み出して処理したときでなければ、Cmd_Recビットをクリアしてはいけない。Cmd_Recビットがクリアされるまで、ハードウェアは、それらのFIFO位置に重ね書きしない。したがって、Cmd_Recビットをクリアすることは、新しいコマンドのためにそれらのメモリ位置を再使用することができるハードウェアパーザに対するACKとして働く。
【０３５０】
このセクションは、ステータス・ブロック構造を詳述する。インターネット・チューナ10Gは、ステータス・ブロックを用いて、システムに情報を戻し渡す。ステータスは、受信されたデータの報告から、例外事例、エラー状態、あるいは、接続統計に及ぶことができる。ステータス・ブロックは、通例、DMAを用いてホスト・システムに転送される。インターネット・チューナ10Gは、最初に、ステータスコマンド・ブロックのリストを生成する。さまざまな元がステータス・メッセージを生成することができ、また、それらのステータス・メッセージは全て、1つのマスターステータス・メッセージ・ジェネレータに流し込まれる。これらのメッセージは、メッセージリストに入れられ、その後、送信DMAエンジン・モジュールに利用可能になる。
【０３５１】
ステータス・メッセージ・ブロックは、長さが可変で、以下のようなフィールド構造を持っている。ステータスのタイプにかかわらず、各ブロックは、偶数バイトから構成されなければならない。奇数バイト・ステータス・メッセージ・ブロックには、全て、パディング・バイトが、用いられなければならない。
【０３５２】
ステータス・ブロックハンドリングのホスト側インプリメントは、コマンド・ブロックメカニズムを補完する。適切なインプリメントが、正しい動作のために付けられなければならない。不適当なインプリメントは、行き詰まった状況に導くことがある。
【０３５３】
ステータス・ブロック循環キューは、ホストメモリ内に作り出され、また、インターネット・チューナ10Gは、その開始(statqstart)アドレスおよびその終了(statqend)アドレスを付けて構成される。したがって、ステータス・ブロックは、周期的に、あるいは、要求に応じて、DMAを用いて、インターネット・チューナ10Gハードウェアから、このキューに転送される。
【０３５４】
このセクションは、ステータス・メッセージを送る動作について説明し、内部プロセッサが、ステータス・メッセージをホスト・システムに送り返すために通過しなければならないステップを詳述する。
【０３５５】
・  内部プロセッサは、メッセージ・ブロックを作り出して、それらのメッセージ・ブロックを、メモリ空間の連続的なセクションに入れなければならない。
【０３５６】
・  このメモリ空間の開始アドレスが、Stat_Addレジスタ内にプログラムされる。
【０３５７】
・  ステータス・メッセージの全長が、Stat_Lengthレジスタ内にプログラムされる。
【０３５８】
・  内部プロセッサは、ステータス・メッセージがホスト・システムに転送され終わったときについて、割り込みを介して通知してもらいたい場合には、Cmd_Stat_Int_EnレジスタにStat_Int_Enビットをセットしなければならない。
【０３５９】
・  これが全て、初期化されたときに、内部プロセッサは、Cmd_Stat_ControlレジスタにSend_Statビットをアサートする。このビットのセッティングによって、ホスト・システムに渡すために内部プロセッサによって生成されたステータス・メッセージが存在するということが、ハードウェアに通知される。
【０３６０】
・  ハードウェアは、内部プロセッサ状態メッセージの送信を完了したとき、Cmd_Stat_ControlレジスタのSend_Statビットをクリアし、Cmd_Stat_StatレジスタにStat_Sentビットをセットする。
【０３６１】
・  Stat_Int_Enビットもセットされていたら、ステップ番号6は、また、内部プロセッサ割り込みのトリガもする。
【０３６２】
ここから、もし望めば、内部プロセッサが、新しいステータス・メッセージを入力する。
【０３６３】
本明細書において、本発明が、好適な実施例に関して記述されているが、当業者であれば、他の応用が、本発明の精神および範囲から逸脱することなく、本明細書に説明されている応用に置き換えることのできるものであることが容易に認識される。したがって、本発明は、以下に含まれる請求項によってしか制限されるべきではない。
【図面の簡単な説明】
【０３６４】
【図１】本発明によるコアシステムのハイレベルデータ・フロー図である。
【図２】本発明によるシステムのハイレベルブロック図である。
【図３】本発明による完全システムインプリメンテーション、および、UMAメモリコンントローラ(3A)の機能ブロック図である。
【図４】従来のアーキテクチャと本発明で必要とされるデータタスク時間を例証する時間比較チャートである。
【図５】本発明による応用の可能な発展を例証している。
【図６】本発明によるインターネット・チューナの概念を例証している。
【図７】本発明による2つのインプリメンテーションを例証している。
【図８】本発明によるネットワークPCインプリメンテーションを例証している。
【図９】本発明によるハンドヘルドデバイスインプリメンテーションを例証している。
【図１０】本発明による電話インプリメンテーションを例証している。
【図１１】本発明によるスマートテレビジョン、ケーブルボックス、ビデオ・カセット・レコーダ(VCR)、デジタルビデオディスク(DVD)、ゲームマシンのインプリメンテーションを例証している。
【図１２】本発明による受信パケットを分配するタイミング図である。
【図１３】本発明による図12のパケットの信号フローを示すブロック線図である。
【図１４】本発明による、内部プロセッサと組み合わせた本発明のインターネット・チューナ10Gを用いたアダプタ・インプリメンテーションのブロック線図である。
【図１５】本発明によるインターネット・チューナ10Gを用いた、ネットワークに配されたデバイスのブロック線図である。
【図１６】本発明によるギガビット・イーサネット・アダプタ・チップのブロック線図である。
【図１７】本発明によるインターネット・チューナ10Gのブロック線図である。
【図１８】本発明によるARPモジュールのブロック線図である。
【図１９】本発明によるARPキャッシュルックアップ処理のブロック線図である。
【図２０】本発明によるIPモジュールのブロック線図である。
【図２１】本発明によるICMPエコー応答モジュールのブロック線図である。
【図２２】本発明によるICMPエコー応答受信モジュールのブロック線図である。
【図２３】本発明によるICMPエコー応答プロセッサのブロック線図である。
【図２４】本発明による、再構築がハードウェアで遂行されるときの、IP再構築中の情報フローのブロック線図である。
【図２５】本発明によるIP分割モジュールのブロック線図である。
【図２６】本発明によるIP識別フィールド・ジェネレータ・モジュールのブロック線図である。
【図２７】本発明によるTCPモジュールの先頭図のブロック線図である。
【図２８】本発明によるTCP受信データ・フローのブロック線図である。
【図２９】本発明によるVSOCKおよび受信状態ハンドラ制御ブロックの探索解決フローのブロック線図である。
【図３０】本発明によるRSTパケット生成データ・フローのブロック線図である。
【図３１】本発明によるソケット受信データ・フローのブロック線図である。
【図３２】本発明によるソケット送信データ・フローのブロック線図である。
【図３３】本発明によるTCP送信モジュールデータ・フローのブロック線図である。
【図３４】本発明によるパケット・スケジューラ・モジュールのブロック線図である。
【図３５】本発明によるIPルータのブロック線図である。
【図３６】本発明によるIPルータ要求信号制御のブロック線図である。
【図３７】本発明によるシステム例外ハンドラのブロック線図である。
【図３８】本発明による典型的なm1メモリ・マップのブロック線図である。
【図３９】本発明による雑メモリ・マップのブロック線図である。
【符号の説明】
【０３６５】
1752  TCPモジュール
1758  IPモジュール
1762  ARPモジュール
1766  イーサネット・インターフェイス・モジュール
1770  イーサネットMACインターフェイス・モジュール
1890  ARP送信スケジューラ
1896  イーサネット受信モジュール
2062  IPヘッダ・フィールド構文解析モジュール
2064  IP分割モジュール
2180  ICMPエコー応答受信モジュール
2182  ICMPエコー応答プロセッサ・モジュール
2500  VSOCKモジュール・メモリ・アロケータ・モジュール
2830   RSTパケット・ジェネレータ・モジュール
2832  受信状態ハンドラ・モジュール
2834  VSOCKモジュール
2841  SYN/ACKパケット・ジェネレータ・モジュール
2842  NATとIPマスカレーディング・モジュール
3350  パケット・スケジューラ
3352  ソケット送信ハンドラ・モジュール
【図１】
2005502225.tif 000005
【図２】
2005502225.tif 000006
【図３】
2005502225.tif 000007
【図３Ａ】
2005502225.tif 000008
【図４】
2005502225.tif 000009
【図５】
2005502225.tif 000010
【図６】
2005502225.tif 000011
【図７】
2005502225.tif 000012
【図８】
2005502225.tif 000013
【図９】
2005502225.tif 000014
【図１０】
2005502225.tif 000015
【図１１】
2005502225.tif 000016
【図１２】
2005502225.tif 000017
【図１３】
2005502225.tif 000018
【図１４】
2005502225.tif 000019
【図１５】
2005502225.tif 000020
【図１６】
2005502225.tif 000021
【図１７】
2005502225.tif 000022
【図１８】
2005502225.tif 000023
【図１９】
2005502225.tif 000024
【図２０】
2005502225.tif 000025
【図２１】
2005502225.tif 000026
【図２２】
2005502225.tif 000027
【図２３】
2005502225.tif 000028
【図２４】
2005502225.tif 000029
【図２５】
2005502225.tif 000030
【図２６】
2005502225.tif 000031
【図２７】
2005502225.tif 000032
【図２８】
2005502225.tif 000033
【図２９】
2005502225.tif 000034
【図３０】
2005502225.tif 000035
【図３１】
2005502225.tif 000036
【図３２】
2005502225.tif 000037
【図３３】
2005502225.tif 000038
【図３４】
2005502225.tif 000039
【図３５】
2005502225.tif 000040
【図３６】
2005502225.tif 000041
【図３７】
2005502225.tif 000042
【図３８】
2005502225.tif 000043
【図３９】
2005502225.tif 000044
【国際公開パンフレット】
2005502225.tif 000045
2005502225.tif 000046
2005502225.tif 000047
2005502225.tif 000048
2005502225.tif 000049
2005502225.tif 000050
2005502225.tif 000051
2005502225.tif 000052
2005502225.tif 000053
2005502225.tif 000054
2005502225.tif 000055
2005502225.tif 000056
2005502225.tif 000057
2005502225.tif 000058
2005502225.tif 000059
2005502225.tif 000060
2005502225.tif 000061
2005502225.tif 000062
2005502225.tif 000063
2005502225.tif 000064
2005502225.tif 000065
2005502225.tif 000066
2005502225.tif 000067
2005502225.tif 000068
2005502225.tif 000069
2005502225.tif 000070
2005502225.tif 000071
2005502225.tif 000072
2005502225.tif 000073
2005502225.tif 000074
2005502225.tif 000075
2005502225.tif 000076
2005502225.tif 000077
2005502225.tif 000078
2005502225.tif 000079
2005502225.tif 000080
2005502225.tif 000081
2005502225.tif 000082
2005502225.tif 000083
2005502225.tif 000084
2005502225.tif 000085
2005502225.tif 000086
2005502225.tif 000087
2005502225.tif 000088
2005502225.tif 000089
2005502225.tif 000090
2005502225.tif 000091
2005502225.tif 000092
2005502225.tif 000093
2005502225.tif 000094
2005502225.tif 000095
2005502225.tif 000096
2005502225.tif 000097
2005502225.tif 000098
2005502225.tif 000099
2005502225.tif 000100
2005502225.tif 000101
2005502225.tif 000102
2005502225.tif 000103
2005502225.tif 000104
2005502225.tif 000105
2005502225.tif 000106
2005502225.tif 000107
2005502225.tif 000108
2005502225.tif 000109
2005502225.tif 000110
2005502225.tif 000111
2005502225.tif 000112
2005502225.tif 000113
2005502225.tif 000114
2005502225.tif 000115
2005502225.tif 000116
2005502225.tif 000117
2005502225.tif 000118
2005502225.tif 000119
2005502225.tif 000120
2005502225.tif 000121
2005502225.tif 000122
2005502225.tif 000123
2005502225.tif 000124
2005502225.tif 000125
2005502225.tif 000126
2005502225.tif 000127
2005502225.tif 000128
2005502225.tif 000129
2005502225.tif 000130
2005502225.tif 000131
2005502225.tif 000132
2005502225.tif 000133
2005502225.tif 000134
2005502225.tif 000135
2005502225.tif 000136
2005502225.tif 000137
2005502225.tif 000138
2005502225.tif 000139
2005502225.tif 000140
2005502225.tif 000141
2005502225.tif 000142
2005502225.tif 000143
2005502225.tif 000144
2005502225.tif 000145
2005502225.tif 000146
2005502225.tif 000147
2005502225.tif 000148
2005502225.tif 000149
2005502225.tif 000150
2005502225.tif 000151
2005502225.tif 000152
2005502225.tif 000153
2005502225.tif 000154
2005502225.tif 000155
2005502225.tif 000156
2005502225.tif 000157
2005502225.tif 000158
2005502225.tif 000159
2005502225.tif 000160
2005502225.tif 000161
2005502225.tif 000162
2005502225.tif 000163
2005502225.tif 000164
2005502225.tif 000165
2005502225.tif 000166
2005502225.tif 000167
2005502225.tif 000168
2005502225.tif 000169
2005502225.tif 000170
2005502225.tif 000171
2005502225.tif 000172
2005502225.tif 000173
2005502225.tif 000174
2005502225.tif 000175
2005502225.tif 000176
2005502225.tif 000177
2005502225.tif 000178
【国際公開パンフレット（コレクトバージョン）】
2005502225.tif 000179
2005502225.tif 000180
【手続補正書】
【提出日】平成15年6月30日(2003.6.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークプロトコルをデコードおよびエンコードして、データを処理するための装置であって、
パケットを受信および送信し、また、パケットをエンコードおよびデコードするためのネットワークスタックと、
複数の専用ハードワイヤードロジックプロトコルモジュールと、を有する装置において、
各プロトコルモジュールが、特定のネットワークプロトコルに対して最適化されており、そして、
当該プロトコルモジュール、および、各プロトコルモジュール内部の構成要素が、並列実行を行う装置。
【請求項２】
請求項1に記載の装置において、
プログラム可能な内部プロセッサをさらに有する装置であって、
当該内部プロセッサが、当該ネットワークスタックを制御する装置。
【請求項３】
専用ハードウェアによって直接サポートされていない他のプロトコルに対応する他のタイプのパケットが、当該内部プロセッサによって処理される、請求項2に記載の装置。
【請求項４】
当該プロトコルモジュールに、TCPプロトコルモジュールが含まれている、請求項1に記載の装置。
【請求項５】
当該TCPモジュールが、TCPネットワークトラフィックおよびUDPネットワークトラフィックを処理する、請求項4に記載の装置。
【請求項６】
当該TCPモジュールが、メモリ管理ハードウェアを用いることによってバーチャルナンバのコネクションをサポートする、請求項4に記載の装置。
【請求項７】
当該TCPモジュールが、内部プロセッサまたは専用ハードワイヤードロジックのいずれかを用いて、アウトオブオーダパケットの再アセンブリをサポートする、請求項4に記載の装置。
【請求項８】
当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、周回シーケンス番号に対するTCP保護(PAWS)をサポートする、請求項4に記載の装置。
【請求項９】
当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、TCPキープアライブタイマをサポートする、請求項4に記載の装置。
【請求項１０】
当該TCPモジュールが、TCPスロースタートアルゴリズムをサポートしている、請求項4に記載の装置。
【請求項１１】
当該TCPモジュールが、TCP高速再送アルゴリズムおよび高速回復アルゴリズムをサポートしている、請求項4に記載の装置。
【請求項１２】
当該TCPモジュールが、内部プロセッサまたは専用ハードワイヤードロジックのいずれかを用いて、TCP Nagleアルゴリズムをサポートしている、請求項4に記載の装置。
【請求項１３】
当該TCPモジュールが、TCP選択確認応答(SACK)オプションをサポートしている、請求項4に記載の装置。
【請求項１４】
当該TCPモジュールが、パケット往復遅延時間(round-trip time)を測定する、請求項4に記載の装置。
【請求項１５】
当該TCPモジュールが、輻輳回避アルゴリズムを遂行する、請求項4に記載の装置。
【請求項１６】
当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、TCPスケーリングウィンドウをサポートする、請求項4に記載の装置。
【請求項１７】
当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、最大セグメントサイズ(MSS)探索(MSS discovery)をサポートする、請求項4に記載の装置。
【請求項１８】
当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、タイムーウェイト  アセシネーション(time-wait assassination)をサポートする、請求項4に記載の装置。
【請求項１９】
当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、ポートフォワーディングをサポートする、請求項4に記載の装置。
【請求項２０】
請求項1に記載の装置において、
IPルータモジュールをさらに有する装置であって、
当該IPルータモジュールが、
ネットワークアドレス中継のためのハードウェアを含むデフォルトIP経路制御能力と、
複数のホストIPアドレスに対する経路制御と、
ホスト指定経路およびネットワーク指定経路に対する経路制御と、
ICMPリダイレクトパケットメッセージ受信後の経路制御情報の動的な更新と、
リミテッドブロードキャスト、サブネットディレクテッドブロードキャストおよびネットワークディレクテッドブロードキャストを含むが、それらに制限されないIPブロードキャストアドレスを伴う経路制御と、
ループバックIPアドレスを伴う経路制御と、
IPマルチキャストアドレスを伴う経路制御と、のうちの任意の1つ以上を遂行する装置。
【請求項２１】
当該プロトコルモジュールが、IPプロトコルモジュールを具備し、そして、当該IPモジュールが、IPネットワークパケットを処理し、生成し、応える、請求項1に記載の装置。
【請求項２２】
当該IPモジュールが、IPネットワークパケットを再構築するための専用の最適化されたハードワイヤードロジックを有する、請求項21に記載の装置。
【請求項２３】
当該プロトコルモジュールが、ICMPネットワークメッセージまたはIGMPネットワークメッセージを処理し、生成し、応えるための専用の最適化されたハードワイヤードロジックを有するICMPモジュールを具備する、請求項1に記載の装置。
【請求項２４】
当該プロトコルモジュールが、一定のICMP機能またはIGMP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムできる最適化されたハードワイヤードロジックから成るICMPモジュールを具備する、請求項1に記載の装置。
【請求項２５】
専用の最適化されたハードワイヤードロジックを用いて、真のランダム分布を持つIPパケットの識別フィールドを生成し、そして、前記識別フィールドの将来値を予測する試みを防止するIP識別ジェネレータモジュールをさらに有する、請求項1に記載の装置。
【請求項２６】
当該プロトコルモジュールが、バーチャルナンバのネットワークコネクションの使用を可能にするバーチャルソケットモジュールを具備する、請求項1に記載の装置。
【請求項２７】
当該プロトコルモジュールが、受信状態ハンドラモジュールを具備し、当該受信状態ハンドラモジュールが、自動的にTCPネットワークパケットに応える請求項1に記載の装置であって、
リセット(RST)パケットの生成と、
確認応答パケットに同期したパケット(SYN/ACK)の生成と、
確認応答パケット(ACK)の生成と、
同期パケット(SYN)の生成と、
終了パケット(FIN)の生成と、
終了／確認応答パケット(FIN/ACK)の生成と、
リセット／確認応答パケット(RST/ACK)の生成と、のうちの任意の1つ以上を含む装置。
【請求項２８】
当該プロトコルモジュールが、ARPプロトコルモジュールを具備し、そして、当該ARPモジュールが、ネットワークARP応答を生成することによって、ネットワークARP要求に応える、請求項1に記載の装置。
【請求項２９】
当該ARPモジュールが、
ハードウェアARPアドレスキャッシュと組み合ったARP要求と、
複数のIPアドレスに対するARP要求と、
ユニキャストARP要求と、
gratuitous ARP要求と、のうちの任意の1つ以上を生成する、請求項28に記載の装置。
【請求項３０】
当該ARPモジュールが、一定のARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項28に記載の装置。
【請求項３１】
当該ARPモジュールが、優先順位を変化できるようにプログラムされている、請求項28に記載の装置。
【請求項３２】
最適化されたハードワイヤードロジックを用いて構築されたARPアドレスのためのキャッシュをさらに有する、請求項28に記載の装置であって、
当該ARPキャッシュが、専用ハードウェアによって制御される、動的に分類されるテーブルを用い、
当該ARPキャッシュが、ARPプロキシとして働く能力をサポートし、そして、
当該ARPキャッシュが、専用ハードワイヤードロジックを用いて、ARPキャッシュエントリの満了時間を制御する、装置。
【請求項３３】
当該プロトコルモジュールが、RARPプロトコルモジュールを具備し、そして、当該RARPモジュールが、IPアドレスを要求するか、または、供給することができる、請求項1に記載の装置。
【請求項３４】
当該RARPモジュールが、一定のRARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項33に記載の装置。
【請求項３５】
ハードワイヤードバーチャルメモリ管理を可能にするメモリ構造をさらに有する、請求項1に記載の装置であって、
当該メモリ構造が、
各々が自らの目的に対して最適化された、様々に分類された制御ブロックのセットと、
各制御ブロックに記憶されたポインタを用いて、制御ブロックをリンクするメカニズムと、を有する装置。
【請求項３６】
当該ハードワイヤードバーチャルメモリ管理が、制御ブロックを割り付け、制御ブロックを更新し、そして、制御ブロックの割り付けを解放する、請求項35に記載の装置。
【請求項３７】
プログラム可能な優先順位にしたがって送信するためにパケットをスケジュール化する優先順位キューをさらに有する、請求項1に記載の装置。
【請求項３８】
ネットワークパケットが処理されるべき優先順位を計算して、割り当てるシーケンサをさらに有する、請求項1に記載の装置。
【請求項３９】
ネットワークサービス不能攻撃から保護するように、各ネットワークコネクションの状態についてのネットワーク情報を記憶するメモリアーキテクチャをさらに有する、請求項1に記載の装置。
【請求項４０】
当該ネットワークスタックが、TCPパケットおよびIPパケットを処理し、生成し、受信し、そして、当該ネットワークスタックが、一定のIPパケット処理機能またはTCPパケット処理機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項1に記載の装置。
【請求項４１】
当該ネットワークスタックが、iSCSIまたはRDMAのような、より上位レベルのプロトコルをカプセル化するIPパケットを処理し、生成し、受信する、請求項1に記載の装置。
【請求項４２】
ハードワイヤードロジック中にインプリメントされたバーチャルメモリマネージャをさらに有する、請求項1に記載の装置。
【請求項４３】
当該バーチャルメモリマネージャが、バーチャルナンバのネットワークコネクションの使用を可能にし、そして、当該ネットワークコネクションのバーチャルナンバが、利用可能な内部メモリ量または外部メモリ量によってしか制限されない、請求項42に記載の装置。
【請求項４４】
当該バーチャルメモリマネージャが、ハードワイヤードロッキングメカニズムを用いて、メモリ位置間の干渉を防止する、請求項42に記載の装置。
【請求項４５】
当該バーチャルメモリマネージャが、一続きのメモリ構造を用いて、メモリにネットワークコネクション情報を記憶する、請求項42に記載の装置。
【請求項４６】
当該バーチャルメモリマネージャが、専用ハードワイヤード回路を用いて、リンクリストまたは一続きのメモリ構造にエントリの探索、更新、挿入、削除を行う、請求項42に記載の装置。
【請求項４７】
当該バーチャルメモリマネージャが、いくつかの相異なるタイプの制御ブロックを用いて、ネットワークコネクション情報を、前記ネットワークコネクションの状態に依存して記憶する、請求項42に記載の装置。
【請求項４８】
ネットワークプロトコルをデコードおよびエンコードして、データを処理するためのプロセスであって、
パケットを受信および送信し、また、パケットをエンコードおよびデコードするためのネットワークスタックを備える過程と、
複数の専用プロトコルステートマシンを備える過程と、を有するプロセスにおいて、
各プロトコルステートマシンが、特定のネットワークプロトコルに対して最適化されており、そして、
当該プロトコルステートマシン、および、各プロトコルステートマシン内部の構成要素が、並列実行を行うプロセス。
【請求項４９】
請求項48に記載のプロセスにおいて、
プログラム可能な内部プロセッサを備える過程をさらに有するプロセスであって、
当該内部プロセッサが、当該ネットワークスタックを制御するプロセス。
【請求項５０】
専用ハードウェアによって直接サポートされていない他のプロトコルに対応する他のタイプのパケットが、当該内部プロセッサによって処理される、請求項49に記載のプロセス。
【請求項５１】
当該プロトコルステートマシンに、TCPプロトコルステートマシンが含まれている、請求項48に記載のプロセス。
【請求項５２】
当該TCPステートマシンが、TCPネットワークトラフィックおよびUDPネットワークトラフィックを処理する、請求項51に記載のプロセス。
【請求項５３】
当該TCPステートマシンが、メモリ管理ハードウェアを用いることによってバーチャルナンバのコネクションをサポートする、請求項51に記載のプロセス。
【請求項５４】
当該TCPステートマシンが、内部プロセッサまたは専用ハードワイヤードロジックのいずれかを用いて、アウトオブオーダパケットの再アセンブリをサポートする、請求項51に記載のプロセス。
【請求項５５】
当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、周回シーケンス番号に対するTCP保護(PAWS)をサポートする、請求項51に記載のプロセス。
【請求項５６】
当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、TCPキープアライブタイマをサポートする、請求項51に記載のプロセス。
【請求項５７】
当該TCPステートマシンが、TCPスロースタートアルゴリズムをサポートしている、請求項51に記載のプロセス。
【請求項５８】
当該TCPステートマシンが、TCP高速再送アルゴリズムおよび高速回復アルゴリズムをサポートしている、請求項51に記載のプロセス。
【請求項５９】
当該TCPステートマシンが、内部プロセッサまたは専用ハードワイヤードロジックのいずれかを用いて、TCP Nagleアルゴリズムをサポートしている、請求項51に記載のプロセス。
【請求項６０】
当該TCPステートマシンが、TCP選択確認応答(SACK)オプションをサポートしている、請求項51に記載のプロセス。
【請求項６１】
当該TCPステートマシンが、パケット往復遅延時間を測定する、請求項51に記載のプロセス。
【請求項６２】
当該TCPステートマシンが、輻輳回避アルゴリズムを遂行する、請求項51に記載のプロセス。
【請求項６３】
当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、TCPスケーリングウィンドウをサポートする、請求項51に記載のプロセス。
【請求項６４】
当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、最大セグメントサイズ(MSS)探索をサポートする、請求項51に記載のプロセス。
【請求項６５】
当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、タイムーウェイト  アセシネーション(time-wait assassination)をサポートする、請求項51に記載のプロセス。
【請求項６６】
当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、ポートフォワーディングをサポートする、請求項51に記載のプロセス。
【請求項６７】
請求項48に記載のプロセスにおいて、
IPルータモジュールを備える過程をさらに有するプロセスであって、
当該IPルータモジュールが、
ネットワークアドレス中継のためのハードウェアを含むデフォルトIP経路制御能力と、
複数のホストIPアドレスに対する経路制御と、
ホスト指定経路およびネットワーク指定経路に対する経路制御と、
ICMPリダイレクトパケットメッセージ受信後の経路制御情報の動的な更新と、
リミテッドブロードキャスト、サブネットディレクテッドブロードキャストおよびネットワークディレクテッドブロードキャストを含むが、それらに制限されないIPブロードキャストアドレスを伴う経路制御と、
ループバックIPアドレスを伴う経路制御と、
IPマルチキャストアドレスを伴う経路制御と、のうちの任意の1つ以上を遂行するプロセス。
【請求項６８】
当該プロトコルステートマシンが、IPプロトコルステートマシンを具備し、そして、当該IPステートマシンが、IPネットワークパケットを処理し、生成し、応える、請求項48に記載のプロセス。
【請求項６９】
当該IPモジュールが、IPネットワークパケットを再構築するための専用の最適化されたハードワイヤードロジックを有する、請求項68に記載のプロセス。
【請求項７０】
当該プロトコルモジュールが、ICMPネットワークメッセージまたはIGMPネットワークメッセージを処理し、生成し、応えるための専用の最適化されたハードワイヤードロジックを有するICMPモジュールを具備する、請求項48に記載のプロセス。
【請求項７１】
当該プロトコルモジュールが、一定のICMP機能またはIGMP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムできる最適化されたハードワイヤードロジックから成るICMPモジュールを具備する、請求項48に記載のプロセス。
【請求項７２】
専用の最適化されたハードワイヤードロジックを用いて、真のランダム分布を持つIPパケットの識別フィールドを生成し、そして、前記識別フィールドの将来値を予測する試みを防止するIP識別ジェネレータモジュールをさらに有する、請求項48に記載のプロセス。
【請求項７３】
当該プロトコルステートマシンが、バーチャルナンバのネットワークコネクションの使用を可能にするバーチャルソケットステートマシンを具備する、請求項48に記載のプロセス。
【請求項７４】
当該プロトコルステートマシンが、受信状態ハンドラステートマシンを具備し、当該受信状態ハンドラステートマシンが、自動的にIPネットワークパケットに応える請求項48に記載のプロセスであって、
リセット(RST)パケットの生成と、
確認応答パケットに同期したパケット(SYN/ACK)の生成と、
確認応答パケット(ACK)の生成と、
同期パケット(SYN)の生成と、
終了パケット(FIN)の生成と、
終了／確認応答パケット(FIN/ACK)の生成と、
リセット／確認応答パケット(RST/ACK)の生成と、のうちの任意の1つ以上を含むプロセス。
【請求項７５】
当該プロトコルステートマシンが、ARPプロトコルステートマシンを具備し、そして、当該ARPステートマシンが、ネットワークARP応答を生成することによって、ネットワークARP要求に応える、請求項48に記載のプロセス。
【請求項７６】
当該ARPモジュールが、
ハードウェアARPアドレスキャッシュと組み合ったARP要求と、
複数のIPアドレスに対するARP要求と、
ユニキャストARP要求と、
gratuitous ARP要求と、のうちの任意の1つ以上を生成する、請求項75に記載のプロセス。
【請求項７７】
当該ARPステートマシンが、一定のARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項75に記載のプロセス。
【請求項７８】
当該ARPステートマシンが、優先順位を変化できるようにプログラムされている、請求項75に記載のプロセス。
【請求項７９】
最適化されたハードワイヤードロジックを用いて構築されたARPアドレスのためのキャッシュを備える過程をさらに有する、請求項75に記載のプロセスであって、
当該ARPキャッシュが、専用ハードウェアによって制御される、動的に分類されるテーブルを用い、
当該ARPキャッシュが、ARPプロキシとして働く能力をサポートし、そして、
当該ARPキャッシュが、専用ハードワイヤードロジックを用いて、ARPキャッシュエントリの満了時間を制御する、プロセス。
【請求項８０】
当該プロトコルステートマシンが、RARPプロトコルステートマシンを具備し、そして、当該RARPステートマシンが、IPアドレスを要求するか、または、供給することができる、請求項48に記載のプロセス。
【請求項８１】
当該RARPステートマシンが、一定のRARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項80に記載のプロセス。
【請求項８２】
ハードワイヤードバーチャルメモリ管理を可能にするメモリ構造を備える過程をさらに有する、請求項48に記載のプロセスであって、
当該メモリ構造が、
各々が自らの目的に対して最適化された、様々に分類された制御ブロックのセットと、
各制御ブロックに記憶されたポインタを用いて、制御ブロックをリンクするメカニズムと、を有するプロセス。
【請求項８３】
当該ハードワイヤードバーチャルメモリ管理が、制御ブロックを割り付け、制御ブロックを更新し、そして、制御ブロックの割り付けを解放する、請求項82に記載のプロセス。
【請求項８４】
プログラム可能な優先順位にしたがって送信するためにパケットをスケジュール化する優先順位キューを備える過程をさらに有する、請求項48に記載のプロセス。
【請求項８５】
ネットワークパケットが処理されるべき優先順位を計算して、割り当てるシーケンサを備える過程をさらに有する、請求項48に記載のプロセス。
【請求項８６】
ネットワークサービス不能攻撃から保護するように、各ネットワークコネクションの状態についてのネットワーク情報を記憶するメモリアーキテクチャを備える過程をさらに有する、請求項48に記載のプロセス。
【請求項８７】
当該ネットワークスタックが、TCPパケットおよびIPパケットを処理し、生成し、受信し、そして、当該ネットワークスタックが、一定のIPパケット処理機能またはTCPパケット処理機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項48に記載のプロセス。
【請求項８８】
当該ネットワークスタックが、iSCSIまたはRDMAのような、より上位レベルのプロトコルをカプセル化するIPパケットを処理し、生成し、受信する、請求項48に記載のプロセス。
【請求項８９】
ハードワイヤードロジック中にインプリメントされたバーチャルメモリマネージャを備える過程をさらに有する、請求項48に記載のプロセス。
【請求項９０】
当該バーチャルメモリマネージャが、バーチャルナンバのネットワークコネクションの使用を可能にし、そして、当該ネットワークコネクションのバーチャルナンバが、利用可能な内部メモリ量または外部メモリ量によってしか制限されない、請求項89に記載のプロセス。
【請求項９１】
当該バーチャルメモリマネージャが、ハードワイヤードロッキングメカニズムを用いて、メモリ位置間の干渉を防止する、請求項89に記載のプロセス。
【請求項９２】
当該バーチャルメモリマネージャが、一続きのメモリ構造を用いて、メモリにネットワークコネクション情報を記憶する、請求項89に記載のプロセス。
【請求項９３】
当該バーチャルメモリマネージャが、専用ハードワイヤード回路を用いて、リンクリストまたは一続きのメモリ構造にエントリの探索、更新、挿入、削除を行う、請求項89に記載のプロセス。
【請求項９４】
当該バーチャルメモリマネージャが、いくつかの相異なるタイプの制御ブロックを用いて、ネットワークコネクション情報を、前記ネットワークコネクションの状態に依存して記憶する、請求項89に記載のプロセス。
【国際調査報告】
2005502225.tif 000181
2005502225.tif 000182