JP2014524688A - ルックアップ・フロントエンド・パケット出力プロセッサ - Google Patents

Abstract

【課題】ネットワークアーキテクチャにおいてパケットのルールマッチングを実現するパケットプロセッサを提供する。
【解決手段】パケットプロセッサは、複数のルックアップエンジンおよびそれぞれのオンチップメモリユニットを有するルックアップクラスタコンプレックスを備える。オンチップメモリは、パケットデータに対してマッチングを行うためのルールを格納する。ルックアップフロントエンドは、ホストからルックアップ要求を受信し、これらのルックアップ要求を処理して、ルックアップエンジンに転送するためのキー要求を生成する。ルールマッチングの結果、ルックアップエンジンは、一致が見つかったか否かを示す応答メッセージを返す。ルックアップ フロントエンドは、応答メッセージをさらに処理し、対応する応答をホストに提供する。
【選択図】図１７

Description

関連出願

本願は、2011年8月2日に出願された米国仮特許出願第61/514,344号、2011年8月2日に出願された米国仮特許出願第61/514,382号、2011年8月2日に出願された米国仮特許出願第61/514,379号、2011年8月2日に出願された米国仮特許出願第61/514,400号、2011年8月2日に出願された米国仮特許出願第61/514,406号、2011年8月2日に出願された米国仮特許出願第61/514,407号、2011年8月2日に出願された米国仮特許出願第61/514,438号、2011年8月2日に出願された米国仮特許出願第61/514,447号、2011年8月2日に出願された米国仮特許出願第61/514,450号、2011年8月2日に出願された米国仮特許出願第61/514,459号、および2011年8月2日に出願された米国仮特許出願第61/514,463号の利益を主張する。これらの出願の教示の内容の全てを本明細書に引用して援用する。

開放型システム間相互接続（ＯＳＩ）参照モデルは、伝送媒体を介した通信に使用される７つのネットワークプロトコル層（Ｌ１〜Ｌ７）を規定する。上位層（Ｌ４〜Ｌ７）は、エンド・ツー・エンド通信を表現し、下位層（Ｌ１〜Ｌ３）はローカル通信を表現する。

ネットワーキングアプリケーションアウェア型（アプリケーションが自動的にネットワークを制御する）システムは、Ｌ３からＬ７までの範囲のネットワークプロトコル層（例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）およびシンプルメール転送プロトコル（ＳＭＴＰ）などのＬ７ネットワークプロトコル層、および伝送制御プロトコル（ＴＣＰ）などのＬ４ネットワークプロトコル層）を処理し、フィルタリングし、かつ切り換える必要がある。ネットワークプロトコル層の処理に加えて、ネットワーキングアプリケーションアウェア型システムは、ファイアウォール、仮想プライベートネットワーク（ＶＰＮ）、セキュアソケットレイヤ（ＳＳＬ）、侵入検知システム（ＩＤＳ）、インターネットプロトコルセキュリティ（ＩＰＳｅｃ）、アンチウィルス（ＡＶ）およびアンチスパム機能を含むＬ４〜Ｌ７のネットワークプロトコル層を介した、アクセスベースおよびコンテンツベースのセキュリティによって、これらのプロトコルの安全性を同時にワイヤスピードで保証する必要がある。

現代のインターネット社会において、ネットワーク運用の効率と安全性の向上は、依然としてインターネットユーザの究極的な目標である。アクセス制御、トラフィックエンジニアリングおよび侵入検出などの多くのネットワークサービスでは、パケットヘッダの複数のフィールドに基づいてパケットを分別する必要がある。これは、パケット分類と呼ばれる。

インターネットルータは、パケットを分類して、ルーティング、レート制限、ファイアウォールにおけるアクセス制御、仮想帯域幅割当、ポリシ・ルーティング、サービス差別化、負荷分散、トラフィックシェーピング、およびトラフィック課金などの数多くの高度なインターネットサービスを実現する。これらのサービスはルータを必要とし、そのようなルータは、受信パケットを異なるフローに分類した後、この分類に応じて適切な動作を行う。

分類器は、フィルタまたはルールのセットを用いて、これらのフロー、すなわちクラスを指定する。例えば、ファイアウォールにおける各ルールは、発信元アドレスおよび宛先アドレスのセットを指定し、対応する拒否動作または許可動作をそのアドレスセットに関連付ける場合がある。あるいは、このルールは、ＯＳＩモデルの第２、第３、第４、および第５層を含む、パケットヘッダのいくつかのフィールドに基づく場合があり、この場合、これらフィールドは、アドレス指定およびプロトコルの情報を含む。

一部の種類の独自開発のハードウェアでは、アクセス制御リスト（ＡＣＬ）が、ホストまたは第３層装置で利用できるポート番号またはネットワークデーモン名に適用されるルールを参照する。各ルールは、サービスの利用が許可されたホストおよび／またはネットワークのリストを有する。個々のサーバおよびルータはいずれも、ネットワークＡＣＬを有することができる。ＡＣＬは、両方向のトラフィックを制御するように構成可能である。

本開示の例示的な実施形態は、パケットを処理する方法を提供する。この方法は、パケットヘッダデータによりルックアップ要求を提供するホストと、パケットデータのルールマッチングを提供する探索クラスタとをインタフェース接続するルックアップフロントエンド（ＬＵＦ）プロセッサによって運用される。パケットのパケットヘッダおよびグループ識別子（ＧＩＤ）を含むルックアップ要求を最初に受信する。そして、パケットヘッダのデータに基づいて少なくとも１つのキーを生成する。ＧＩＤを大域定義テーブルと比較し、少なくとも１つのテーブル識別子（ＴＩＤ）を決定する。ＴＩＤに基づいて、当該パケットのルールマッチングを行うことが可能な処理クラスタのサブセットを決定する。そして、複数の処理クラスタのうちの１つを利用可能性（availability）に基づいて選択する。その後、キー、およびキーを用いてルールマッチングを開始するＴＩＤを含むキー要求を、選択した処理クラスタに転送する。

別の実施形態では、ＧＩＤを大域定義テーブルと比較してパケットヘッダインデックス（ＰＨＩＤＸ）を決定し、キーはＰＨＩＤＸに従って生成する。ＰＨＩＤＸは、パケットヘッダからデータを抽出してキーを生成するためのルールを示すエントリをパケットヘッダテーブル（ＰＨＴ）に索引付けする。

さらに別の実施形態では、ＧＩＤを大域定義テーブルと比較してキーフォーマットテーブルインデックス（ＫＦＴＩＤＸ）を決定し、ＫＦＴＩＤＸは、処理クラスタにおけるキーからフィールドを抽出するための命令を示すエントリをキーフォーマットテーブルに索引付けする。キー要求がＫＦＴＩＤＸを含んでもよい。

さらに別の実施形態では、キー要求ごとにそれぞれ実現される複数のキーをパケットデータから生成し、各キーは、パケットヘッダから抽出した個別のデータをそれぞれ含む。さらに、処理クラスタを、複数の処理クラスタのサブセットのそれぞれにおける保留中要求の数に対する、その処理クラスタにおける保留中要求の数に基づいて選択する。この処理クラスタにおける保留中要求の数は、処理クラスタのサブセットのうちの最少のものであり、「アクセス頻度が最も低い（すいている)」クラスタを示す。これを判定するために、複数の処理クラスタのサブセットのそれぞれの保留中要求数のカウントを維持する。選択したクラスタが利用不可能であることを検出すると、キー要求を再試行待ち行列に転送する。この再試行待ち行列は、選択したクラスタにキー要求を再び転送するために、後にアクセスされるものである。

さらに別の実施形態では、キー要求は、複数のサブツリー要求に分割される。ここで、サブツリー要求は、サブツリー、またはクラスタに格納されたルールのさらなるサブセットに対応する。その後、キー要求は、選択した処理クラスタ（または複数の選択したクラスタ）にサブツリー要求として転送される。

またさらに別の実施形態では、装置は、パケット分類のためのルールのセットを表現する、コンパイルされた、ルールのデータ構造（ＲＣＤＳ）を格納したメモリを備える。この装置は、また、ＲＣＤＳの増分更新のための１つまたは複数のホストコマンドを受信するホストコマンドインタフェースを備える。さらに、メモリおよびホストコマンドインタフェースに結合されたプロセッサが、受信したパケットを分類するためにＲＣＤＳのアクティブな探索を実行する。ここで、ＲＣＤＳは、受信した１つまたは複数のホストコマンドに基づいて更新され、実行中のアクティブな探索の観点からアトミックに（不可分に）更新される。

上記の事項は、添付図面に示す以下の本発明の例示的な実施形態のさらに詳細な説明から明らかになるであろう。添付図面において、異なる図全体にわたり、同一の部品は同一の参照符号で示す。図面は必ずしも原寸に比例しておらず、本発明の実施形態の説明に重点が置かれている。

本願に記載の探索プロセッサの例示的な実施形態を採用したネットワーク要素を含む典型的なネットワークトポロジのブロック図である。 ルータにおいて用いられる探索プロセッサの例示的な実施形態を示すブロック図である。 ルータにおいて用いられる探索プロセッサの例示的な実施形態を示すブロック図である。 ルータにおいて用いられる探索プロセッサの例示的な実施形態を示すブロック図である。 ルータアーキテクチャの例示的な実施形態の図である。 探索プロセッサを採用したルータの例示的な実施形態を示すブロック図である。 スイッチバックプレーンを含むルータの別の実施形態のブロック図である。 探索プロセッサを採用したルータの例示的な実施形態を示すブロック図である。 探索プロセッサの例示的な実施形態のブロック図である。 探索プロセッサの例示的な実施形態のブロック図である。 一実施形態のルックアップクラスタコンプレックス（ＬＣＣ）のブロック図である。 一実施形態のＬＣＣにおける入出力データを示すブロック図である。 １つのパケットヘッダからの複数のルックアップ要求の生成を示すブロック図である。 一実施形態のルックアップエンジン（ＬＵＥ）および対応するオンチップメモリ（ＯＣＭ）のブロック図である。 メモリ構造へのコンパイラローディングルールの例示的な実施形態を示すブロック図である。 探索ブロックまたは探索クラスタの例示的な実施形態を示すブロック図である。 パケットにおける所与のキーについてのルールをロードするために用いられるメモリ構造の例示的な実施形態を示すブロック図である。 キーを受信し、メモリ構造からルールのセットをロードするツリーウォークエンジン（ＴＷＥ）によって採用されたメモリ構造の例示的な実施形態を示す図であって、当該ルールは外部メモリに格納されている図である。 探索プロセッサによって用いた例示的な処理を示すフローチャートである。 バケットポストプロセッサ（ＢＰＰ）によりルールのセットを用いてキーに対して探索を行う例示的な処理を示すフローチャートである。 図１１Ａおよび図１１Ｂの位置関係を示す図である。 例示的なＬＵＦ入力プロセッサ（ＬＩＰ）のブロック図の一部である。 例示的なＬＵＦ入力プロセッサ（ＬＩＰ）のブロック図の他部である。 例示的なペイロードヘッダ抽出部（ＰＨＥ）のブロック図である。 ＬＩＰによって選択可能な異なるバイトスワッピングモードを示すパケット図である。 通常キー拡張モードにおいて動作するＰＨＥを示すパケット図である。 ＬＩＰの例示的なスケジューラ出力マネージャのブロック図である。 要求およびコマンドを構文解析し、それらを内部リソースにスケジューリングする例示的な手順のデータフローチャートである。 例示的なＬＵＦ出力プロセッサ（ＬＯＰ）のブロック図である。 例示的なＬＵＦ応答処理フロントエンド（ＬＯＰ＿ＦＥ）のブロック図である。 例示的なルックアップ応答処理バックエンド（ＬＯＰ＿ＢＥ）のブロック図である。 例示的なＬＯＰ出力プロセッサ（ＬＯＰ＿ＯＰ）のブロック図である。 図２１Ａおよび図２１Ｂの位置関係を示す図である。 本開示の例示的な実施形態を実現する例示的なデータ構造のブロック図の一部である。 本開示の例示的な実施形態を実現する例示的なデータ構造のブロック図の他部である。 内部リソースから受信した応答を順序付けして合体する例示的な手順のフローチャートである。 内部リソースから受信した応答を順序付けして合体する例示的な手順のフローチャートである。 本開示の様々な実施形態が実施され得るコンピュータのブロック図である。

パケット分類は長い間幅広く研究されてきているが、研究者はパケット分類のための新規かつ効率的な解決策を意欲的に探し続けている。その理由は、i）ネットワーク帯域幅の継続的成長、ii）ネットワークアプリケーションの複雑性の増大、およびii）ネットワークシステムの技術革新による。

ネットワーク帯域幅に対する需要の急増は、概してデータトラフィックの増大による。主要サービスプロバイダの報告によれば、およそ６カ月から９カ月ごとにプロバイダのバックボーンネットワーク上の帯域幅が倍増している。そのため、端末装置および基幹装置の両方で、指数関数的に増加するトラフィックを処理するパケット分類の新規な解決策が必要とされる。

ネットワークアプリケーションの複雑性は、ネットワークデバイスにおいて実装されるネットワークアプリケーション数の増大によって増加している。パケット分類は、サービスアウェアルーティング、侵入防止およびトラフィックシェーピングといった様々な種類のアプリケーションに広く使用される。したがって、パケット分類の新規な解決策は、著しい性能低下をもたらすことなく多様な種類のルールセットを処理できるインテリジェンス性を有する必要がある。

加えて、マルチコアプロセッサのような新たな技術により、今までにない計算機能力および高度に集積されたリソースが提供されている。このため、パケット分類の新規な解決策は、高度なハードウェアおよびソフトウェア技術に適合していなければならない。

既存のパケット分類アルゴリズムは、メモリのために時間を犠牲にしている。このトレードオフは常に改善され続けているものの、妥当な量のメモリに要する時間は、今なお概して遅い。

既存のアルゴリズム方式が有する問題のため、ベンダーは、総当たり並列ハードウェアを用いて全てのルールに対してパケットを同時にチェックする、三値連想メモリ（ＴＣＡＭ）を使用する。アルゴリズムによる解決策に対するＴＣＡＭの主な利点は、スピードおよび決定性である（ＴＣＡＭは、全てのデータベースに有効である）。

ＴＣＡＭは、完全連想型メモリとして機能するハードウェアデバイスである。ＴＣＡＭのセルは、３つの値、すなわち、０、１、またはドントケア（気にしない）ビットを表す「Ｘ」を格納しており、クリーネスター「＊」のようなワイルドカードを含むルールをＴＣＡＭがマッチングすることを可能にするセルごとのマスクとして動作する。動作において、パケットヘッダ全体をＴＣＡＭに提示し、そのパケットがいずれのエントリ（ルール）に一致するかを判定してもよい。しかし、ＴＣＡＭの複雑性は、多量の電力を消費するにもかかわらず、小規模で柔軟性に欠けた実装であって、比較的遅い実装しか可能にしていない。したがって、特殊なデータ構造に作用する効率的なアルゴリズム的解決策が依然として必要とされる。

現在のアルゴリズム的方法は、数学的解析および／またはソフトウェアシミュレーション（観測に基づく解決法）の段階に留まっている。

提案されている数学的解決策は、優れた時間／空間複雑性を有すると報告されている。しかし、この種の方法は、現実のネットワークデバイスへの実装が認められていない。なぜなら、数学的解決策は、問題を単純化し、かつ／または、明示的な最悪限界を隠し得る大きい定数因子を除外するために、特殊な条件を追加する場合が多いからである。

提案されている観測に基づく解決法は、現実のアプリケーションに対して効率的な解決法を実現するために、ルールにおいて観測される統計的特性を採用する。しかし、これらのアルゴリズム的方法は、一般に、特定のタイプのルールセットのみに有効である。異なるアプリケーションのためのパケット分類ルールは多様な特徴を有するため、観測に基づく方法のうち、異なるタイプのルールセットにおける冗長性を十分に活用して様々な条件下で安定した性能を得ることができる方法は、ほとんどない。

パケット分類は、ポリシデータベース、フロー分類器、または単に分類器ともよばれるパケット分類器を用いて行われる。分類器は、ルールまたはポリシの集合である。受受信したパケットは、一致したパケットに対する動作を決定するルールとマッチングされる。包括的なパケット分類は、パケットを当該パケットのヘッダにおける複数のフィールドに基づいて分類するルータを必要とする。分類器の各ルールは、パケットヘッダの「Ｆ」フィールドの基準に従ってパケットが属し得るクラスを指定し、各クラスに識別子（例えば、クラスＩＤ）を関連付ける。例えば、フロー分類器における各ルールはフロー仕様であり、フロー仕様において各フローは別のクラスに存在する。識別子は、各ルールに対応した動作を一意に指定する。各ルールは、「Ｆ」フィールドを有する。ルールＲの第ｉ番目のフィールドは、Ｒ［ｉ］と呼ばれ、パケットヘッダの第ｉ番目のフィールドの正規表現である。全てのｉについて、パケットＰのヘッダの第ｉ番目のフィールドが正規表現Ｒ［ｉ］を満たす場合、パケットＰは特定のルールＲに一致する（マッチングする）。

ルールによって指定されるクラスは、重複してもよい。例えば、１つのパケットがいくつかのルールに一致する場合がある。この場合、いくつかのルールが重複すると、これらのルールが分類器に出現する順序により、ルールの相対的優先度が決まる。換言すると、複数のルールに一致するパケットは、これらのルールのうち、分類器において最初に出現するルールの識別子（クラスＩＤ）によって識別されるクラスに属する。

パケット分類器は、分類器テーブルのルールを解析および類別してもよく、さらに、受信したパケットを分類器テーブルのルールとマッチングするために使用される決定木を生成してもよい。決定木は、決定のツリー状グラフまたはモデルおよびそれらの考えられる結果（偶発イベント結果、リソースコスト、および実用性を含む結果）を用いる決定支援ツールである。決定木は、目標に最も到達しやすい戦略の特定に役立てるために、オペレーションズ・リサーチ、とりわけ、決定解析において一般的に用いられる。決定木の別の用途としては、条件付き確率を計算するための記述手段がある。決定木を使用して、受信したパケットと分類器テーブルのルールとのマッチングを選択させ、受信したパケットの処理方法を決定してもよい。

図１は、探索プロセッサの例示的な実施形態を用いたネットワーク要素を含む典型的なネットワークトポロジ１００のブロックである。ネットワークトポロジは、複数のコアルータ（基幹ルータ）１０４ａ〜ｈを有するインターネットコア１０２を含む。複数のコアルータ１０４ａ〜ｈのそれぞれは、複数のコアルータ１０４ａ〜ｈのうちの少なくとも１１つの他のコアルータに接続される。インターネットコア１０２の境界上のコアルータ１０４ａ〜ｈ（すなわち、コアルータ１０４ｂ〜ｅおよび１０４ｈ）は、少なくとも１つのエッジルータ（境界上ルータ）１０６ａ〜ｆに接続される。各エッジルータ１０６ａ〜ｆは、少なくとも１つのアクセスルータ１０８ａ〜ｅに接続される。

コアルータ１０４ａ〜ｈは、インターネットコア１０２またはインターネットバックボーンにおいて動作する。コアルータ１０４ａ〜ｈは、インターネットコア１０２の複数の電気通信インタフェースをサポートし、さらに、複数の電気通信プロトコルそれぞれの最高速度でパケットを転送する。

エッジルータ１０６ａ〜ｆは、インターネットコア１０２の境界上に配置される。エッジルータ１０６ａ〜ｆは、インターネットコア１０２の外部のアクセスルータ１０８ａ〜ｅと、インターネットコア１０２の内部のコアルータ１０４ａ〜ｈとをブリッジする。エッジルータ１０６ａ〜ｆは、ブリッジプロトコルを用いてアクセスルータ１０８ａ〜ｅからコアルータ１０４ａ〜ｈへの方向、およびその逆方向にパケットを転送する。

アクセスルータ１０８ａ〜ｅは、エンドユーザ（ホームユーザやオフィスなど）が使用するルータであり、エッジルータ１０６ａ〜ｆのうち１つと接続するルータであってもよく、当該エッジルータは、コアルータ１０４ａ〜ｈのうち１つに接続することによりインターネットコア１０２に接続する。このようにして、エッジルータ１０６ａ〜ｆは、エッジルータ１０６ａ〜ｆおよび相互接続されたコアルータ１０４ａ〜ｈを介して任意の他のエッジルータ１０６ａに接続できる。

本明細書に記載の探索プロセッサは、コアルータ１０４ａ〜ｈ、エッジルータ１０６ａ〜ｆ、およびアクセスルータ１０８ａ〜ｅのうちいずれに存在してもよい。これらルータのそれぞれにおいて、本明細書に記載の探索プロセッサは、ルールのセットに基づいてインターネットプロトコル（ＩＰ）パケットを解析し、このＩＰパケットを適切なネットワーク経路に沿って転送する。

図２Ａは、エッジルータ１０６において用いた探索プロセッサ２０２の例示的な実施形態２００を示すブロック図である。プロバイダエッジルータのようなエッジルータ１０６は、探索プロセッサ２０２、第１のホストプロセッサ２０４、および第２のホストプロセッサ２１４を含む。第１のホストプロセッサ２０４は、入力ホストプロセッサである。第１のホストプロセッサ２０４は、入力パケット２０６をネットワークから受信する。第１のホストプロセッサ２０４は、入力パケット２０６からのパケットヘッダ（すなわちフィールド）を含むルックアップ要求をインタラーケン（Interlaken）インタフェース２０８を用いて探索プロセッサ２０２に転送する。次に、探索プロセッサ２０２は、複数のルールを採用する複数のルール処理エンジンを用いてパケットヘッダを処理し、ネットワーク上で入力パケット２０６を転送する経路を決定する。パケットヘッダを伴うルックアップ要求を処理した後、探索プロセッサ２０２は、経路の情報を第１のホストプロセッサ２０４に転送する。第１のホストプロセッサ２０４は、処理された入力パケット２１０をネットワーク内の別のネットワーク要素に転送する。

同様に、第２のホストプロセッサ２１４は、出力ホストプロセッサである。第２のホストプロセッサ２１４は、ネットワーク２１６から送信用の出力パケットを受信する。第２のホストプロセッサ２１４は、パケットヘッダ（すなわちフィールド）を含むルックアップ要求を出力パケット２１６から探索プロセッサ２０２に第２のインタラーケンインタフェース２１８を介して転送する。次に、探索プロセッサ２０２は、複数のルールを採用する複数のルール処理エンジンを用いてパケットヘッダを処理し、ネットワーク上で当該パケットを転送する経路を決定する。第２のホストプロセッサ２１４は、処理された出力パケット２２０をネットワーク内の別のネットワーク要素に転送する。

図２Ｂは、探索プロセッサ２０２を用いるように構成されたエッジルータ１０６の別の例示的な実施形態２２０を示すブロック図である。本実施形態において、エッジルータ１０６は、複数の探索プロセッサ２０２、例えば、第１の探索プロセッサ２０２ａおよび第２の探索プロセッサ２０２ｂを含む。複数の探索プロセッサ２０２ａ〜ｂは、複数のインタラーケンインタフェース２２６ａ〜ｂをそれぞれ用いてパケットプロセッサ２２８に結合される。複数の探索プロセッサ２０２ａ〜ｂは、１つのインタラーケンおよびインタフェースを介してパケットプロセッサ２２８に結合されてもよい。エッジルータ１０６は、前処理されたパケット２２２のパケットヘッダ（すなわちフィールド）を伴うルックアップ要求をパケットプロセッサ２２８にて受信する。探索プロセッサ２０２ａ〜ｂのうちの一方は、ルールのセットとパケットヘッダ内のデータとに基づいて、前処理されたパケット２２２の適切な転送先をパケットヘッダから探索し、パケットプロセッサ２２８に対してルックアップ要求に応答する。次に、パケットプロセッサ２２８は、探索プロセッサ２０２ａ〜ｂによって実行されたルックアップ要求に基づいて、後処理されたパケット２２４をネットワークに送る。

図２Ｃは、探索プロセッサ２０２を用いたアクセスルータ２４６の例示的な実施形態２４０を示すブロック図である。アクセスルータ２４６は、入力パケットプロセッサ２４２において入力パケット２５０を受信する。次に、入力パケットプロセッサ２４２は、入力パケット２５０のパケットヘッダを伴うルックアップ要求を探索プロセッサ２０２に転送する。探索プロセッサ２０２は、ルックアップ要求のパケットヘッダに基づいて入力パケット２５０の転送経路を決定し、インタラーケンインタフェース２５２を介して出力パケットプロセッサ２４４に対してルックアップ要求に応答する。次に、出力パケットプロセッサ２４４は、転送されたパケット２４８をネットワークに出力する。

図３Ａは、ルータアーキテクチャの例示的な実施形態３００の図である。ルータアーキテクチャは、プロセッサ３０８およびメモリ３０４を含むプロセッサカード３０３に結合されたスイッチバックプレーン３０２を含む。スイッチバックプレーン３０２は、複数のラインカード３０６ａ〜ｈにさらに結合される。各ラインカード３０６ａ〜ｈは、本明細書に記載の探索プロセッサを含む。

図３Ｂは、探索プロセッサ２０２を用いたルータの例示的な実施形態３２０を示すブロック図である。ルータは、ラインカード３０６ａ〜ｂに結合されたスイッチバックプレーン３０２と、プロセッサカード３０３とを含む。プロセッサカード３０３は、プロセッサ３０８と、プロセッサカード３０３のメモリ３０４に格納されるルーティングテーブル３２８とを含む。各ラインカード３０６ａ〜ｂは、それぞれ、ローカルバッファメモリ３２２ａ〜ｂと、転送テーブル３２４ａ〜ｂと、媒体アクセス制御（ＭＡＣ）層３２６ａ〜ｂとを含む。探索プロセッサ２０２は、ラインカード３０６ａ〜ｂの転送テーブル３２４ａ〜ｂ内に存在する。

一例として、ラインカード３０６ａにより、ＭＡＣ層３２６ａにおいてパケットを受信する。ＭＡＣ層３２６ａは、パケットを転送テーブル３２４ａに送る。次に、パケットおよび適切な転送テーブル情報をローカルバッファメモリ３２２ａに格納する。次に、プロセッサカード３０３は、そのルーティングテーブル３２８にアクセスし、受信したパケットの転送先を決定する。この決定に基づいて、ルータは、適切なラインカード３０６ｂを選択し、適切なラインカードのローカルバッファメモリ３２２ｂにパケットおよび転送情報を格納し、パケットをネットワークに転送する。

図３Ｃは、スイッチバックプレーン３０２を含むルータの別の実施形態３４０を示すブロック図である。スイッチバックプレーン３０２は、プロセッサカード３０３、ラインカード３４２ｂ〜ｈ、およびサービスカード３４２ａに結合される。プロセッサカード３０３は、メモリ３０４およびプロセッサ３０８を含む。サービスカード３４２ａは、ラインカード３４２ａ〜ｈの一種である。さらに、本明細書に記載の探索プロセッサは、サービスカード３４２ａ上に存在してもよい。

図３Ｄは、スイッチバックプレーン３０２を備えたルータの例示的な実施形態３６０を示すブロック図である。スイッチバックプレーン３０２は、プロセッサカード３０３および、サービスカード３４２ａまたはラインカード３４２ｂ〜ｈに結合される。ラインカード３４２ａ〜ｂは、サービスカード３４２ａまたはラインカード３４２ｂ〜ｈのいずれかであってもよい。ラインカード３４２ａ〜ｂは、転送テーブル・対応ポリシモジュール３４４ａ〜ｂおよびＭＡＣ層３２６ａ〜ｂを含む。探索プロセッサ２０２は、ラインカード３４２ａ〜ｂに含まれる。ラインカード３４２ａは、ネットワークからＭＡＣ層３２６ａを介して転送テーブル・ポリシモジュール３４４ａにおいてパケットを受信する。探索プロセッサ２０２は、プロセッサカード３０３のルーティングテーブル３２８に従い、転送テーブル・ポリシモジュール３４４ａに応じてパケットを処理し、ネットワーク内に転送されることになる適切なラインカード３４２ｂにパケットを転送する。

図４Ａは、探索プロセッサ２０２の例示的な実施形態４００でのブロック図ある。探索プロセッサ２０２は、シリアライザ／デシリアライザ（ＳｅｒＤｅｓ）インタフェース４０２に結合される。一実施形態において、ＳｅｒＤｅｓインタフェース４０２は、少なくとも最大１０Ｇｂ／秒のデータ転送速度が可能な８個の伝送レーンを含む。探索プロセッサ２０２は、ＳｅｒＤｅｓインタフェース４０２に結合された２組の４レーンインタフェース４０４ａ〜ｂを含む。４レーンインタフェース４０４ａ〜ｂは、それぞれ、第１のインタラーケンインタフェース４０６ａおよび第２のインタラーケンインタフェース４０６ｂに結合される。そして、インタラーケンインタフェース４０６ａ〜ｂは、第１のルックアップフロントエンド（ＬＵＦ）４０８ａおよび第２のルックアップフロントエンド（ＬＵＦ）４０８ｂに結合される。ＬＵＦ４０８ａ〜ｂは、クロスバー４１２（インテリジェントファブリックまたは「Ｘ−ｂａｒ」とも示す）に結合される。

クロスバー４１２は、第１のスーパークラスタ４１０ａおよび第２のスーパークラスタ４１０ｂに結合される。各スーパークラスタ４１０ａ〜ｂ内には複数の探索ブロック４１２ａ〜ｂが存在する。各探索ブロック４１２、すなわち探索クラスタは、受信パケットからキーを受け取り、当該キーを処理するルールのセットを判定およびロードし、これらのルールを用いて実行した探索の結果を出力する。クロスバー４１２およびスーパークラスタ４１０ａ〜ｂは、ルックアップクラスタコンプレックス（ルックアップクラスタの複合部）（ＬＣＣ）４１４の一部である。

図４Ｂは、本明細書に記載の探索プロセッサの例示的な実施形態４２０のブロック図である。探索プロセッサは、ＬＵＦ入力プロセッサ（ＬＩＰ）４２４として示すＬＵＦ４０８およびＬＵＦ出力プロセッサ（ＬＯＰ）４４０を含む。このプロセッサは、ＬＣＣ４１４をさらに含み、ＬＣＣ４１４は、スーパークラスタ４１０ａ〜ｂを含む。ＬＩＰ４２４は、インタラーケン入力４２２ａおよびインタラーケン入力４２２ｂを受信する。ＬＩＰ４２４は、スケジューラ４２８ａ〜ｂ、パケットヘッダテーブル４３０ａ〜ｂ、ルールデータベースロケーションテーブル４３２ａ〜ｂおよびグループ定義テーブル４２６を含む。ＬＩＰ４２４は、ＬＣＣ４１４に対して、テーブル、ＣＳＲおよび要求４３４ａ〜ｂを生成する。ＬＣＣ４１４は、スーパークラスタ４１０ａ〜ｂおよびその中の探索クラスタ（図示せず）に基づき応答４３６ａ〜ｂを生成する。そして、ＬＯＰ４４０は、応答を受信し、インタラーケン出力４４２ａおよびインタラーケン出力４４２ｂを介してこれらを出力する。

本明細書に記載のプロセッサは、あるパケットに一致する１つまたは複数のルール（例えば、マッチングルール）をロードする。一般に、パケットは、ヘッダ、ペイロード、およびトレーラといった部分に分けることができる。パケットのヘッダ（すなわちパケットヘッダ）は、例えば、フィールドにさらに分けることができる。そのため、プロセッサは、パケットの１つまたは複数の部分（すなわちフィールド）に一致する１つまたは複数のルールをさらに検出してもよい。

プロセッサは、パケットまたはパケットの一部に一致する１つまたは複数のルールを発見する「ルックアップ要求」を実行できる。ルックアップ要求により、まず、１つまたは複数のマッチングルールの発見が誘導される。

本明細書に記載のプロセッサの観点によると、ルックアップ要求の実行は、１）ホストプロセッサからルックアップ要求を受信することから始まる。ルックアップ要求は、パケットヘッダおよびグループ識別子（ＧＩＤ）を含む。

２）ＧＩＤは、大域定義／説明テーブル（ＧＤＴ）のエントリを索引付けする。各ＧＤＴエントリは、（ａ）ｎ個のテーブル識別子（ＴＩＤ）、（ｂ）パケットヘッダインデックス（ＰＨＩＤＸ）、および（ｃ）キーフォーマットテーブルインデックス（ＫＦＴＩＤＸ）を含む。

３）各ＴＩＤは、ツリーロケーションテーブル（ＴＬＴ）のエントリを索引付けする。各ＴＬＴエントリは、いずれのルックアップエンジンまたはプロセッサコアが上記１つまたは複数のマッチングルールを探しているのかを識別する。このように、各ＴＩＤは、いずれのルックアップエンジンまたはプロセッサコアが１つまたは複数のマッチングルールを探しているのかと、この特定の１つまたは複数のマッチングルールが格納されている場所との両方を指定する。

４）各ＴＩＤはまた、ツリーアクセステーブル（ＴＡＴ）のエントリを索引付けする。各ＴＡＴエントリは、ルールのテーブルまたはツリーと呼ばれるルール（またはルールを指すポインタ）の集合のメモリにおける開始アドレス（例えば、ルートノード）を提供する。ルールのテーブル、ルールのツリー、テーブル、またはツリーという用語は、本願を通して同義で用いられる。全体として、ＴＩＤはＴＡＴを識別し、ＴＡＴは、１つまたは複数のマッチングルールを探す、ルールの集合またはセットを識別する。

５）ＧＤＴエントリのＰＨＩＤＸは、パケットヘッダテーブル（ＰＨＴ）のエントリを索引付けする。ＰＨＴの各エントリは、パケットヘッダからｎ個のキーを抽出する方法をプロセッサに指示する。

６）ＧＤＴエントリのＫＦＴＩＤＸは、キーフォーマットテーブル（ＫＦＴ）のエントリを索引付けする。ＫＦＴの各エントリは、パケットヘッダから抽出したｎ個のキーのそれぞれから１つまたは複数のフィールド（すなわち、パケットヘッダの部分）を抽出するための命令を提供する。

７）プロセッサは、ＴＩＤのそれぞれと共に、パケットから抽出した各フィールドを用いて上記ルールのサブセットを探す。各サブセットは、抽出したフィールドのそれぞれに一致する可能性のあるルールを含む。

８）次に、プロセッサは、各サブセットの各ルールを、抽出したフィールドと比較する。プロセッサは、応答またはルックアップ応答に一致するルールを提供する。

ルックアップ要求およびその列挙された段階についての上記説明は、ルックアップ要求の概念を提示するためのものである。これらの概念は、多くの方法で実現できる。例えば、本発明の例示的な実施形態によると、これらの概念は探索プロセッサによって実現できる。

上述のように、探索プロセッサは、１つのパケットに対してルックアップ要求を処理する。ルックアップ要求の処理にあたり、プロセッサは、１つまたは複数のルールが適用されるパケットからヘッダまたはフィールドを抽出してもよい。ヘッダまたはフィールドをキーと称する場合がある。

探索プロセッサは、ルールの少なくとも１つのツリーを格納する。一実施形態において、ルールのツリーは、所与のキーについてのルールのセットを絞り込むためにプロセッサが使用するメモリ構造であり、ルールはキーの値のテストである。ツリーはルートノード、すなわち開始アドレスを有する。探索プロセッサは、ツリーウォークエンジン（ＴＷＥ）を用いて特定のキーについてツリーをトラバースする。最終的に、ＴＷＥはツリーのメモリアドレスを指すポインタに達する。このポインタは、ルールのバケットを指してもよく、あるいは直接的にメモリのルールを指すポインタであってもよい。

ルールのバケットは、ルールを指すポインタのセットである。ポインタがルールのバケットを指す場合、バケットウォークエンジン（ＢＷＥ）は、キーおよびバケットに基づいて、オンチップメモリのようなメモリ内のルールを指すポインタを決定する。メモリ内のルールのグループは、チャンクと呼ばれる。チャンクは、連続的にアドレス指定されたルール、または別の方式でグループ化されたルールであり得る。ポインタが直接的にメモリのルールを指す場合、ポインタは、チャンクを直接指してもよい。

プロセッサがメモリからルールのチャンクをロードすると、プロセッサは、キーおよびルールのチャンクをルールマッチエンジン（ＲＭＥ）に送る。ルールマッチエンジンは、キーがチャンク内のルールに一致するか否かを判定する。次に、ＲＭＥおよび探索プロセッサが、選択されたルールおよび一致結果でルックアップ要求に応答してもよい。

図４Ｃは、２つのスーパークラスタ４１０ａ〜ｂを含むルックアップクラスタコンプレックス（ＬＣＣ）４１４のさらに詳細なブロック図である。各スーパークラスタは、複数の（例えば、８個の）クラスタを含み、各クラスタ（例えば、クラスタ４１２ａ）は、ＬＵＥ４５２ａ〜ｈ、４５３ａ〜ｈおよび関連付けられたオンチップメモリ４５４ａ〜ｈ、４５５ａ〜ｈ、ならびにクロスバーデバイス４１２を含む。例示的な探索プロセッサは、パケットデータを処理するためにこのようなスーパークラスタ４１０ａ〜ｂを２つ以上有してもよい。

図４Ｄは、一実施形態のＬＣＣ４１４における入出力データを示すブロック図である。ＬＣＣ４１４は、ルックアップ要求または他の通信において、以下の情報を受信するように構成されてもよい。
１）Ｌｅａｓｔ Ｆｕｌｌ（最も空きのある）クラスタマスク（ＬＦＴＷＣＬＭＳＫ）は、所与の探索に対して１つのスーパークラスタにつき、いずれのクラスタを使用可能にするかを選択するために使用されるビットマスクである。
２）キー・クラスタ・マスク（ＫＣＬＭＳＫ）は、ＬＣＣ中のいずれのクラスタがキー要求データを受け付けるべきかを示す。ＫＣＬＭＳＫは、探索の開始時には関与しない場合があるクラスタが処理の最終部分を実行することを可能にする。スーパークラスタ中のクロスバーセグメントにより、１つのクラスタから別のクラスタへ探索を移動させることが可能となる。ＫＣＬＭＳＫは、潜在的に関与する可能性のある全てのクラスタに通知を行う。
３）ツリーＩＤ（ＴＩＤ）およびキーフォーマットインデックス（ＫＦＴＩＤＸ）は、上記マスクと共に、実行（ルールのセットを表すツリーまたはＲＣＤＳのウォーキング）を開始する場所であるツリーのルートを選択する。
４）キーＩＤ（ＫＩＤ）は、ＬＵＦが、実行中のインベントリおよび要求に対する一致の返答を追跡できるように維持される。
５）キーは、ツリーまたはＲＣＤＳを探索するためにヘッダタプルから抽出されるデータである。

探索プロセッサは、１つのパケットヘッダから１〜４回の探索を開始する方法を提供する。これらの要求は、それぞれ、ヘッダ中の完全に異なりかつ完全に独立したフィールドセットを探索してもよい。これらの探索は、同一のパケットヘッダに関連してはいるが、あらゆる意味において独立した探索である。探索構造（探索ファブリック）（ＬＣＣ）は、これらを完全に異なる探索として扱い、最初の要求の拡張についての知識を有さない。（入出力されるサブキーＩＤの受け渡しを除く）。

さらに、ＬＣＣ４１４は、ルックアップ要求または他の通信に対する応答として、以下の情報を出力してもよい。
１） ＫＩＤは、返ってきたキーＩＤである。
２） ＲｕｌｅＤａｔａは、ホストに返される応答の一部である。
３） ＲｕｌｅＰｒｉｏｒｉｔｙは、ＬＵＦが複数のクラスタ返答から１つの最良の応答を選択することを可能にするサブツリー（すなわちサブＲＣＤＳ）応答に関連付けられた尺度である。ＭｉｎＲｕｌｅもまた、ホストに返される応答の一部である。

共通のパケットに対応する複数の応答メッセージが、ホストに返される際、共通のＩＤが共有されてもよく、合体されれば、１クロックにつき複数の応答を生成して所望のスループットを得る。応答は、合体されなくてもよいが、応答を合体した場合、インタフェース帯域幅をより効率的に利用することができる。例示的な実施形態において、１〜４個の応答を１個の応答メッセージに合体し、発信元の探索要求の数に一致させてもよい。

図５は、１つのルックアップ要求５５０からの複数のキー要求生成を示すブロック図である。パケットヘッダ５５２を含むルックアップ要求５５０が、命令インタフェースを通ってＬＵＦ４０８に到達する。グループＩＤ（ＧＩＤ）５５４のフィールドは、様々な内部ＬＵＦ４０８テーブルを索引付けし、それぞれ別個のキー（「サブキー」ともいう）を有する最大４個の異なるキー要求５６０ａ〜ｄ（４つの独立した探索を開始するのに使用され得る）をＬＵＦ４０８が生成するのを可能にする。例示的な実施形態において、キー要求５６０ａのキーは最大４７６ビットのビット幅であってもよく、一方、パケットヘッダ５５２は、最大５１２ビットのビット幅であってもよい。キーは、ニブルの粒度で再構築でき、また、カスタマーアプリケーション層によって再び順序付けることができる。例示的な実施形態において、探索プロセッサは、最大１６通りのキー再構築法を予め格納できる。

ＬＵＦ４０８のサブキー拡張インデックスモジュールは、それぞれのキー要求５６０ａ〜ｄについてパケットヘッダ５５２をどのように複数のサブキーに分割するかを決定する。パケットヘッダ５５２を複数のサブキーに拡張した後、ＬＵＦ４０８のサブツリー拡張・スケジューリングモジュールは、キー要求５６０ａ〜ｄのそれぞれを探索プロセッサの適切な部分に方向付ける。

サブキー拡張の下流において、ＬＵＦ４０８のスケジューラは、例えば、１つのサブキーにつき複数のサブＲＣＤＳウォークを実行するクラスタを選択する。サブキーのそれぞれは、最終的にホストに返され内部では使用されない、共通のＸＩＤ５５６を共有する個別の探索であると考えられる。このため、ＬＵＦ４０８は、１つの要求に対して４個のサブキーを拡張および追跡する。

図６は、ルックアップエンジン（ＬＵＥ）６５０のブロック図であり、一実施形態においてオンチップメモリ（ＯＣＭ）６９０に接続されている。ＬＵＥ６５０は、図４Ａ〜図４Ｄを参照して上記で説明した探索プロセッサおよびＬＣＣ構成において実現され得る。一実施形態によると、ルール処理のために、ＬＵＥ６５０は、１つまたは複数のツリーウォークエンジン（ＴＷＥ）６６０のコンプレックス（複合部）、１つまたは複数のバケットウォークエンジン（ＢＷＥ）６７０のコンプレックス、およびルールマッチエンジン（ＲＭＥ）６８０ａ〜ｃを含む。ルール処理が外部メモリ（後述）に拡張される別の実施形態において、ＬＵＥ６５０は、追加のＲＭＥを有するバケットポストプロセッサ（ＢＰＰ）を含んでもよい。ＬＵＥ６５０に関連付けられたＯＣＭ６９０は、ＬＵＥ６５０によるルールマッチングのためのルールを格納する。

例示的な探索プロセッサの動作において、ホストインタフェース（図４Ａ）は、ホストからルックアップ要求を受信する。ＬＵＦ（例えば、図４ＡのＬＵＦ４０８ａ）は、ルックアップ要求を処理して、それぞれがキーを有する（図５）１つまたは複数のキー要求にする。ＬＵＦは、スーパークラスタに対する要求をスケジュールし、ルックアップ要求を処理するクラスタのセットを選択する。

図６を参照して、選択されたクラスタのＬＵＥ６５０構成要素は、ルックアップ要求を処理する。ここで、ＴＷＥ６６０は、キー（キー要求に含まれる）を用いて、当該キーに一致し得るルールのセットを表すツリーをウォークする。ＴＷＥ６６０が当該ツリーのリーフに達すると、ＴＷＥ６６０は、ルールのバケット（またはバケット）と呼ばれるルールのサブセットをＢＷＥ６７０に渡す。ツリーという用語およびルールのコンパイルされたデータ構造（ＲＣＤＳ）という用語は、本明細書において同義で用いられる。ＢＷＥ６７０は、ルールのバケットを処理し、次に、ＲＭＥ６８０ａ〜ｃに結び付ける。ＲＭＥ６８０ａ〜ｃは、キーを、ＴＷＥ６６０が識別したルールと比較する。探索プロセッサは、「一致あり」または「一致なし」を応答としてホストに提供する。

ＬＵＥ６５０に対するルックアップ要求の受信の前に、ＬＵＦ（例えば、図４ＡのＬＵＦ４０８ａ）は、ホストプロセッサからルックアップ要求を受信する。このルックアップ要求は、パケットヘッダおよびグループ識別子（ＧＩＤ）を含む。ＧＩＤは、大域定義／説明テーブル（ＧＤＴ）のエントリを索引付けする。各ＧＤＴエントリは、（ａ）ｎ個のテーブル識別子（ＴＩＤ）、（ｂ）パケットヘッダインデックス（ＰＨＩＤＸ）、および（ｃ）キーフォーマットテーブルインデックス（ＫＦＴＩＤＸ）を含む。そして、各ＴＩＤは、ツリーロケーションテーブル（ＴＬＴ）にエントリを索引付けする。各ＴＬＴエントリは、いずれのルックアップエンジンまたはプロセッサコアが１つまたは複数のマッチングルールを探しているのかを識別する。このように、各ＴＩＤは、いずれのルックアップエンジンまたはプロセッサコアが１つまたは複数のマッチングルールを探しているのかと、その特定の１つまたは複数のマッチングルールがどこに格納されているのかの両方を指定する。

各ＴＩＤはまた、ＬＵＥ６５０におけるツリーアクセステーブル（ＴＡＴ）６６５のエントリを索引付けする。（例えば、メモリに格納された）ＬＵＥ上には、ルールの２つ以上の集合またはセットが存在し得るため、ＴＩＤは、これらのうちどれにおいて１つまたは複数のマッチングルールを探すべきかを識別する。各ＴＡＴ６６５エントリは、ルールのテーブルまたはツリーと呼ばれる、ルール（またはルールを指すポインタ）の集合のメモリにおける開始アドレス（例えば、ルートノード）を提供する。（ルールのテーブル、ルールのツリー、テーブル、またはツリーという用語は、本願を通して同義で用いられる。）よって、ＴＩＤは、ＴＡＴ６６５を識別し、ＴＡＴ６６５は、１つまたは複数のマッチングルールを探すべきルールの集合またはセットを識別する。

ＧＤＴエントリのＰＨＩＤＸは、パケットヘッダテーブル（ＰＨＴ）のエントリを索引付けする。ＰＨＴの各エントリは、いかにパケットヘッダからｎ個のキーを抽出するかをプロセッサに命令する。ＧＤＴエントリのＫＦＴＩＤＸは、キーフォーマットテーブル（ＫＦＴ）のエントリを索引付けする。ＫＦＴの各エントリは、パケットヘッダから抽出したｎ個のキーのそれぞれから１つまたは複数のフィールド（すなわち、パケットヘッダの部分）を抽出するための命令を提供する。例えば、ＫＦＴのエントリ（またはキーフォーマットタイプ）は、１００ビットのキーのうちどのビットがＩＰパケットヘッダのソースＩＰアドレスに対応するかを指定する。

ＬＵＦは、図５の例に示すように、ルックアップ要求から１つまたは複数のキー要求をアセンブルし、キー要求をＬＵＥ６５０に転送する。

動作中、ＬＵＥ６５０は、ＬＵＦ（図４ＡのＬＵＦ４０８ａなど）からキー要求（ＫＲＱ）を受信する。ＫＲＱは、キー（ＫＥＹＤＡＴＡ）、キーフォーマットテーブルインデックス（ＫＦＴＩＤＸ）、およびテーブル識別子（ＴＩＤ）を含み、図５を参照して上記で説明したキー要求５６０ａ〜ｄによって示されるような、ルックアップに関連付けられた付加データを含み得る。

キーは、ＫＦＴから提供された命令に従って構文解析され（、かつＫＦＴＩＤＸによって索引付けられ）る。次に、ＴＷＥ６６０は、構文解析されたキーを用いて、構文解析されたキーに一致し得るルールのセットを表すツリーをウォークする。ＴＷＥ６６０によってウォークされたツリーは、ノードおよびリーフを含む。ＴＷＥ６６０は、当該ツリーのルートノードにおいて上記ウォークを開始する。ルートノードの位置は、ＴＡＴ６６５によって提供され（かつＴＩＤによって索引付けされ）る。ＴＷＥ６６０は、リーフに到達するまで上記ツリーをウォークする。ツリーの各リーフは、ルールのバケット（または、単にバケット）と呼ばれるルールのサブセットを表す。リーフに到達すると、ＴＷＥ６６０は、対応するバケットを、処理のためにＢＷＥ６７０に渡す。

ＢＷＥ６７０は、１つまたは複数のルールを含み得るバケットをフェッチする。便宜的な実施形態において、このバケットは、メモリに格納されたルールへの１つまたは複数のポインタ（またはアドレス）を含む。ルールは、オンチップメモリ（ＯＣＭ）に格納されてもよく、その場合、ＢＷＥ６７０は、ルールをＯＣＭからフェッチし、そのルールをＲＭＥ（ローカルなＲＭＥ）に方向付ける。ＯＣＭバンクスロッタ（ＯＢＳ）６９５は、ＯＣＭ６９０に対する要求のためのスケジューリングを実現し、これにより、関連付けられたアクセスポートｐ０〜ｐ３が、複数のＴＷＥ６６０、ＢＷＥ６７０およびＲＭＥ６８０ａ〜ｃによって占有されかつ共有されることを保証する。

ルールは、ＬＵＥ６５０（およびＬＵＥを含む探索プロセッサ）の外部に位置するメモリに格納してもよい。この場合、ＢＷＥ６７０は、後述する「ルール拡張」と呼ばれる手順で、外部メモリからルールをフェッチし、そのルールをバケットポストプロセッサ（およびその関連付けられたＲＭＥ）に方向付ける。

図６に戻り、ＫＦＴＩＤＸはまた、ルールフォーマットテーブル（ＲＦＴ）６６７のエントリを索引付けする。ＲＦＴ６６７の各エントリは、フェッチしたルールのビットを構文解析するための命令を提供し、ルールから１つまたは複数のフィールドを抽出する。ルールは、ＲＦＴ６６７が提供する命令に従って構文解析され（かつＫＦＴＩＤＸによって索引付けされ）る。次に、ＲＭＥ６８０ａ〜ｃは、構文解析されたルールを構文解析されたキーと比較して一致を検出する。ＲＭＥは、サブツリー応答（ＳＴＲＳＰ）と呼ばれる応答において、「一致あり」または「一致なし」をＬＵＦに提供する。

一実施形態によると、各スーパークラスタは、配布されたオンチップメモリ（ＯＣＭ）および「ｎ」個のＨＷ-補助スレッドエンジンの「ｍ」個のプールを含む。ここで、「ｎ」は、各スレッド繰返しの待ち時間よって決まる（ｎ＝１０サイクル）。各クラスタの性能を最大限に活用するために、最小スレッド繰返し待ち時間＝「ｎ」サイクルで、かつ各ＨＷスレッドが１つのサイクルＯＣＭアクセスを必要とする場合、「ｎ」個のスレッドエンジンは、シングルポート型ＳＲＡＭの使用の時分割多重化（ＴＤＭ）を行うことができる。これにより、例えば、サイクルごとの完全パイプライン型ＯＣＭアクセスが可能となる。

例示的な実施形態において、各クラスタのＬＵＥは、１０個のツリーウォークエンジン（ＴＷＥ）、１０個のバケットウォークエンジン（ＢＷＥ）および３個のルールマッチエンジン（ＲＭＥ）含んでもよい。これらは、受信ホストルックアップ／キー要求を処理するために使用される。各ＴＷＥ／ＢＷＥ／ＲＭＥエンジンは、各キー要求が処理される際の状態を記録する、各自のＨＷコンテキスト状態（またはＨＷスレッド）を含む。各クラスタのＬＵＥにおいて、１０サイクルであるＴＷＥ最小スレッド繰返し待ち時間により、最大１０個のアクティブなＴＷＥスレッドがＯＣＭシングルポート型ＳＲＡＭのＴＤＭ（時分割多重化）を、干渉なしに行うことが可能となる（すなわち、ＯＣＭは、サイクルごとの完全パイプライン型アクセスである）。

図６を参照して、ＬＵＥ６５０のより詳細な例示的動作において、キー要求（ＫＲＱ）バスを介してＬＵＦから新たなホスト要求およびキー要求が受信される。各ＬＵＥ６５０は、最大１６個の未処理ＫＲＱ要求（キー要求またはホスト要求のいずれか）を受信するように構成されてもよい。ホスト要求（ＣＳＲ／テーブル／ＯＣＭについてのホストＲ／Ｗアクセス）は、ホスト要求（ＨＲＦ）ＦＩＦＯを入力し、ホスト書込データが共有書込データバッファ（ＷＤＢ）に書き込まれる。ホスト要求（Ｒ／Ｗ）は、各ＬＵＥ６５０クラスタに対して「順番通りに」処理されてもよい。ホスト応答がＨＲＱ／ＨＲＤ ＦＩＦＯに返され、ホスト応答はそこで中央リソースブロック（ＣＲＢ）を経由したＳＴＲＳＰバスを介した転送を待ち、最終的に、インタラーケンパケットを介してホストに返される。

新たなキー要求がキー要求ＦＩＦＯ（ＫＲＦ）を入力し、これら要求のキーデータが共有書込データバッファ（ＷＤＢ）に書き込まれる。移送されたツリーウォーク要求（ＴＷＭＩＧ）は、ＸＢＲ４１２バスを介して、発信元ＬＵＥ６５０クラスタから宛先ＬＵＥクラスタに転送される。新たなＴＷＭＩＧがＴＭＱ／ＴＭＤにエンキューされ、処理のために保留中ＴＷＥ６６０を待つ。

新たなキー要求（ＫＲＦ）および移送されたツリー要求（ＴＭＱ）は、ツリーＩＤ（ＴＩＤ）を用いてＴＩＣ／ＴＡＴ６６５アクセスの調停を行う。ＴＩＣ／ＴＡＴ６６５構造は、ＴＷＥ６６０のうちの割り当てられたＴＷＥ６６０へのサブツリーウォークの際に用いられるツリーアクセステーブル情報を含む。新たなキー要求の場合、ソフトウェアによってロードされたルールフォーマットテーブル情報を取得するためにＲＩＣ／ＲＦＴ６６７にもアクセスする。ツリー移送要求はＲＩＣ／ＲＦＴテーブルを再びフェッチしなくてもよいが、その代わり、発信元クラスタからの移送要求自体がＲＩＣ／ＲＦＴ情報を保持してもよい。また、ツリー移送要求についてのキーデータは、ツリー移送データ（ＴＭＤ）に格納してもよい。

ＴＡＴ６６５および／またはＲＦＴ６６７情報がフェッチされると、新たなキー要求が（ｎ個のうちの）１つのＴＷＥ６６０に割り当てられる。（ＨＷ並行処理を実現する）新たなキー要求探索を促進するため、キー要求は、（ソフトウェア動作により）最大８個の固有のサブツリーウォークに分割することができ、各サブツリーウォークスレッドは、ＴＷＥ６６０の個々に割り当てられる。ＴＷ移送要求は、常に、ただ１つのＴＷＥに割り当てられてもよい。

ＴＷＥのサブツリーウォークがリーフノードを検出すると、処理のための制御がバケットウォークエンジンＢＷＥ６７０のプールに転送される。ＢＷＥ６７０は、リーフノードからのバケット情報記述子を用いてバケットエントリをフェッチする。次に、バケットエントリ（ＢＥ）は、ルールウォークエンジン（ＲＷＥ）６８０ａ〜ｃにより処理される。ＲＷＥ６８０ａ〜ｃは、ルールチャンクを指すポインタ（ＲｕｌＣｈｋＰｔｒ）を含むバケットエントリ（ＢＥ）を処理する。ＲＷＥ６８０ａ〜ｃは、ルールデータをフェッチし、ＲＭＥ６８０ａ〜ｃの保留中プールに引き渡す。ＲＭＥ６８０ａ〜ｃは、フェッチしたＯＣＭルールチャンクデータを、対応するルールフォーマットデータ（ＲＦＴ６６７からのデータ）と共に使用し、各バケットエントリ（ＢＥ）によって指定されたルールのチャンクを処理する。ＲＷＥ６８０ａ〜ｃは、バケット全体内のすべてのバケットエントリ（ＢＥ）についての各ルールチャンクの部分ＲＭＥ一致結果を総計する。一致あり／一致なし結果が取得されると、ルックアップ応答（ＬＵＲＳＰ）がＬＲＱ／ＬＲＤに戻され、ルックアップ応答（ＬＵＲＳＰ）は、ＳＴＲＳＰバスを介してルックアップフロントエンド（ＬＵＦ）に戻される。

ルールマッチング動作中の任意の時点で、ＢＷＥ６７０は、遠隔バケットエントリ（ＢＥ）要求を作成してもよく、あるいは、ＲＷＥ６８０ａ〜ｃは、遠隔出力待ち行列（ＲＯＱ）を介して別のクラスタに対して遠隔ルールチャンク要求を作成してもよい。ＯＣＭバンク選択（ＯＢＳ）６９５のアービタは、全てのツリーバケットおよびルールデータ構造を収容する共通ＯＣＭに対する全てのアクセスを担当する。遠隔クラスタは、遠隔入力待ち行列（ＲＩＱ）にエンキューされたＸＢＲ４１２を介して遠隔ＯＣＭ要求を行うことにより別のクラスタのＯＣＭにアクセスしてもよい。ＴＷＥプール、ＢＷＥプール、ＲＩＱおよびＨＲＦはすべて、共通ＯＣＭ内に要求を作成することができる。共通ＯＣＭは、最適な全体的な探索性能を実現するためにＯＣＭ総待ち時間を最小化し、ＯＣＭ帯域幅（バンクコンフリクト回避）を最大化する複雑な動的アービトレレイション方式を有する。

上述の通り、ルールは、オンチップメモリ（ＯＣＭ）に存在してもよい。この場合、ＢＷＥ６７０によって連結されたＲＭＥ６８０ａ〜ｃは、ＢＷＥ６７０と同様に、ＬＵＥ６５０の一部をなす。このため、ＢＷＥ６７０は「ローカルな」ＲＭＥ６８０ａ〜ｃを連結するといえる。ルールはまた、プロセッサの外部のメモリ、すなわち、オフチップに存在してもよい。この場合、外部メモリに拡張したルール処理、あるいは「ルール拡張」とも呼ぶ場合があるが、ＢＷＥ６７０は、そのローカルなＲＭＥ６８０ａ〜ｃを連結しない。代わりに、ＢＷＥ６７０は、「チャンク」と呼ばれるルールのバケットの部分を読み出す要求メッセージをメモリコントローラに送る。ＢＷＥ６７０はまた、「側波帯」メッセージをＢＰＰに送り、（所与のキーに関連付けられた）チャンクが外部メモリから送られることを期待するようＢＰＰに通知する。

ＢＰＰは、外部メモリから受信したルールのチャンクの処理を開始する。この処理の一部として、ＢＰＰは、一致を検出した場合、ルックアップ応答と呼ばれる（サブツリー応答とも呼ばれる）応答をＬＵＦに送る。ＢＰＰはまた、ＬＵＥにメッセージを送り、ＢＰＰがチャンクの処理を完了し、ＬＵＥが別の要求に移行することができるようになった旨をＬＵＥに通知する。

ＢＰＰが一致を検出せず、かつＢＰＰがチャンクの処理を完了した場合、ＢＰＰは、ＢＰＰが処理を完了したことを通知し、処理すべきさらなるチャンクをＢＰＰに送るようにＬＵＥにメッセージを送る。次に、ＬＵＥは、ＭＷＡおよびＭＢＣを通じて、ルールのバケットの次のチャンクをＢＰＰなどに送るための「側波帯」メッセージを送る。

ルールのバケットの最後のチャンクの場合、ＬＵＥ６５０は、「側波帯」メッセージをＢＰＰに送り、ＢＰＰによって処理されるべきチャンクが最後のチャンクであることを、ＢＰＰに通知する。ＬＵＥはバケット全体のサイズを把握しているので、ＬＵＥはチャンクが最後のチャンクであることが分かる。最後のチャンクが与えられると、ＢＰＰが一致を検出しなかった場合、ＢＰＰは、ＬＵＦに「一致なし」応答を送り、ＢＰＰが当該バケットの処理を完了したことをＬＵＦに通知する。次に、ＬＵＥ６５０は、コンテキスト（すなわち、完了した作業（ワーク）の詳細）を開放し、別の要求に移る。

さらなる実施形態において、複数のクラスタは、ルールがコンパイルされた同一のデータ構造（ＲＣＤＳ）またはサブＲＣＤＳを含むように構成されてもよい。このような構成において、ＬＵＦは、アクセス頻度が最も低いクラスタを探索することを選択することにより、作業の負荷分散を行ってもよい。

図７は、メモリ構造へのコンパイラローディングルールの例示的な実施形態７００を示すブロック図である。ソフトウェアコンパイラ７０４は、ルールセット７０２を受信する。ソフトウェアコンパイラ７０４は、コンパイルされたルール７１０のバイナリフォーマットを生成する。コンパイルされたルール７１０のバイナリフォーマットは、ツリー７１２、バケット７１４、およびルール７１６を含む。ツリー７１２は、ノード７１１ａ〜ｄ、リーフノード７１３ａ〜ｂ、およびルートノード７３２を含む。ツリー７１２の各リーフノード７１３ａ〜ｂは、バケット７１４のセットのうちの１つを指す。各バケット内にはバケットエントリが存在する。バケットエントリは、ルールまたはチャンクのポインタ７１８を含む。ルール７１６は、ルールのチャンク７２０を含む。（ルールの）チャンク７２０は、複数のポインタによって、あるいは分散したチャンク７２０を（例えば、ハッシュ関数を用いて）再構成（recollect）することによって編成されたルールの連続グループ、またはメモリ全体に分散したルールのグループであってもよい。

図８は、探索ブロックすなわち探索クラスタ４１０の例示的な実施形態５００を示すブロック図である。探索クラスタ４１０は、オンチップメモリ（ＯＣＭ）５０８、ツリーウォークエンジン（ＴＷＥ）５０４、バケットウォークエンジン（ＢＷＥ）５１４、および複数のルールマッチエンジン（ＲＭＥ）５２０ａ〜ｃを含む。ＯＣＭ５０８は、ツリーデータ構造、バケット記憶データ構造、ならびにチャンクおよび／またはルールデータ構造を格納する。

探索クラスタ４１０は、ＴＷＥ５０４においてＬＵＦ４０８（図４Ａ）からのキー５０２を受信する。ＴＷＥ５０４は、ＯＣＭ５０８に対する複数のツリー入力／出力（Ｉ／Ｏ）アクセス５０６を発行して受信する。キー５０２に基づき、ＴＷＥ５０４は、ルートノードから可能性のあるリーフノードまでツリーをウォークする。ＴＷＥ５０４が適切なリーフノードを検出しなかった場合、ＴＷＥ５０４は、一致なし５１２（例えば、ｎｏ ｍａｔｃｈ）を発行する。そして、ＴＷＥ５０４が適切なリーフノードを検出した場合、リーフノードは、バケットを指すポインタ５１０を示してもよい。ＴＷＥ５０４は、バケットを指すポインタ５１０をＢＷＥ５１４に提供する。ＢＷＥ５１４は、バケットＩ／Ｏアクセス５１６をＯＣＭ５０８に発行することにより、ＯＣＭ５０８にアクセスする。バケットＩ／Ｏアクセス５１６は、チャンクを指す少なくとも１つのポインタ５１８を、ＢＷＥ５１４に対し取り出す。ＢＷＥ５１４は、チャンクを指すポインタ５１８を複数のＲＭＥ５２０ａ〜ｃのうちの１つに提供する。選択されたＲＭＥ５２０ａ〜ｃのうちの１つはまた、キー５０２を受信する。複数のＲＭＥ５２０ａ〜ｃのそれぞれは、チャンクを指すポインタ５１８を用いて、ルールおよび／またはチャンクＩ／Ｏアクセス５２４をＯＣＭ５０８に発行し、キー５０２を解析するための適切なルールをＯＣＭのチャンクからダウンロードするように構成されている。次に、ＲＭＥ５２０ａ〜ｃは、ＯＣＭ５０８がアクセスしたルールを用いてキーを解析し、ＯＣＭ５０８に格納されたツリーおよびバケットが示すルールまたはチャンクにキーが一致したか否かに応じて、応答または一致なし５２２ａ〜ｃを発行する。

図９Ａは、１つのパケットにおける所与のキーのルールをロードするために用いられるメモリ構造の例示的な実施形態７３０を示すブロック図である。ＴＷＥ（例えば、図６のＴＷＥ６６０）は、特定のキーについてツリー７１２のウォークを開始する。ウォークは、ツリー７１２のルートノード７３２から始まり、ツリー経路７３４に沿って行われる。ＴＷＥは、受信した各キーについて、ツリー経路７３４をツリー７１２全体にわたってウォークする。最終的にツリー経路７３４は、ヌルつまり一致なしのいずれかを含むか（その場合、ＴＷＥは一致なしを返す）、またはバケット７３８を指すポインタを含むリーフノード７３６に到達する。この場合、ＴＷＥは、ＢＷＥにバケット７３８を送り、ＢＷＥは、この特定のバケットをバケットのセット７１４からロードする。この特定のバケットは、ルールまたはルールのチャンクを指す少なくとも１つのポインタ７１８を含んでもよい。ＢＷＥは、ルール７４６を指すポインタ７１８に基づいて、ルールをＯＣＭから探索クラスタのＲＭＥのうちの１つへロードする。

図９Ｂは、キーを受信してメモリ構造からルールのセットをロードするＴＷＥによって用いられるメモリ構造の例示的な実施形態７４０を示す図であり、この実施形態では、ルールはオンチップメモリではなく、外部メモリに格納される。ここでもまた、ＴＷＥは、キーを受信し、そして、ルートノード７３２からヌル値を格納するか（その場合、ＴＷＥは一致なしを返す）か、またはルールを指すポインタ７４２を格納するリーフノード７３６に到達するまで、ツリー７１２をツリー経路７３４に沿ってウォークする。この外部メモリの実施形態において、リーフノード７３６は、外部メモリにおけるルールおよび／またはチャンク７４６を直接指す。ルールがＯＣＭに格納されている場合、リーフノード７３６は、バケットを指して、バケットは、ルールおよび／またはチャンクを指す。これに対して、ルールが外部メモリに格納されている場合、ＴＷＥは、ルールを指すポインタ７４２に基づいて外部メモリからルールをロードし、ルール７４６をバケットポストプロセッサ（ＢＰＰＰ）に送る。ＢＰＰは、外部メモリ７４６からのルールを処理するために用いられる。同じツリー構造が、外部メモリのバケットまたはルールの両方を指してもよい。例えば、各リーフノード７３６は、メモリのアドレス（またはヌル）を指してもよい。システムは、アドレスが外部メモリのルールまたはＯＣＭのバケットのいずれを指すかを判定できる。この判定に基づき、システムは、適切なメモリにアクセスし、一実施形態においては、同じツリーを外部メモリおよびＯＣＭの両方に同時に用いることができる。ただし、探索プロセッサは、外部メモリの実施形態のみ、またはＯＣＭの実施形態のみを別々に使用するように構成されてもよい。

図１０Ａは、探索プロセッサによって使用される例示的な処理を示すフローチャート６００である。まず、探索プロセッサは、受信したパケットのヘッダ領域からキーを受信する（６０２）。次に、探索プロセッサは、ＴＷＥを用いてツリーデータ構造をウォークし、ツリーのリーフノード上のルールまたはバケットを指すポインタを検出する（６０４）。リーフノードは、存在しない、つまりヌルである場合があり、その場合、受信したキーの一致なしが自動的に生じる。

次に、探索プロセッサの探索クラスタは、ヌルではないリーフノードを探索することにより、ルールまたはバケットがツリーに存在するか否かを判定する（６０６）。存在しない場合、例えば、当該リーフノードが存在しない、つまりヌルである場合、探索クラスタは、一致なしを返す（６０８）。当該リーフノードがルールまたはバケットを格納している場合、探索クラスタは、リーフノードがルールを指しているかまたはバケットを指しているかを判定する（６１０）。リーフノードがルールを直接指している場合、探索クラスタは、外部メモリからルールをロードする（６１２）。次に、システムは、当該ルールをＢＰＰに提供する（６１４）。システムは、（ｉ）ＢＰＰがリーフノードからのポインタを用いて外部メモリからルールを抜き出すか、または（ｉｉ）探索クラスタ内のナビゲーション部が、要求されたメモリアドレスをＢＰＰに転送する旨のコマンドを外部メモリに送ることにより、ルールをＢＰＰに提供する。

ＢＰＰは、ルールのチャンクを処理し、ルールをキーと比較するように構成されたＲＭＥに類似したプロセッサであるが、ＢＰＰは、外部メモリからのルールを処理するようにさらに構成されている。外部メモリからのルールをロードすること（６１０、６１２、６１４）は、探索プロセッサおよび対応する探索クラスタの実施形態のオプションである。探索プロセッサは、ＯＣＭ上に、ルールおよび／またはルールのチャンクの全てを格納することができる。したがって、ツリーデータ構造は、ルールを直接指すポインタの代わりに、バケットを指すポインタを格納してもよい。ルールおよび／またはルールのチャンクがＯＣＭにのみ格納されている実施形態であっても、リーフノードは、ＯＣＭのルールおよび／またはルールのチャンクを、バケットを用いることなく直接指すことができる。

リーフノードがバケットを指す場合（６１０）、探索プロセッサは、バケットに格納されたポインタをロードする（６１６）。次に、探索プロセッサは、バケットからのポインタが指しているＯＣＭに格納されたルールをロードする（６１８）。次に、システムは、当該ルールをＲＭＥ（６２０）に提供する。

図１０Ｂは、ルールのセットを用いてＢＰＰがキーで探索を実行する例示的な処理を示すフローチャート８００である。まず、パケット処理エンジンが、ＢＰＰにキーを送る（８０２）。ＢＷＥは、外部メモリ（ＥＭ）からルールを受信することを期待する旨のメッセージをＢＰＰに送る。次に、ＢＷＥは、ルールまたはルールのブロックをＢＰＰに押し付ける（８０６）。次に、ＢＰＰは、さらなるルールを処理する必要があるか否かを判定する（８０８）。さらなるルールを処理する必要がない場合、ＢＰＰは、処理されたルールの一致または一致なしを返す（８１０）。さらなるルールを処理する必要がある場合、例えば、チャンクの部分のみが処理される場合、ＢＰＰは、次のルールのブロックを要求する（８１２）。次いでＢＷＥは、ＢＰＰに送られるべき次のルールのブロックを要求する（８１４）。次いでＢＷＥは、当該次のルールのブロックをＢＰＰに送る（８１６）。ＢＰＰは、さらなるルールを処理する必要があるか否かを再び判定する（８０８）。必要がない場合、ＢＰＰは、一致または一致なしを返す（８１０）。しかし、さらなるルールを処理する必要がある場合、ＢＰＰは、次のルールのブロックを要求する（８１２）。

図４Ａ〜４Ｂに戻って、ルックアップフロントエンド（ＬＵＦ）４０８は、ルックアップクラスタコンプレックス（ＬＣＣ）４１４にインタフェースを提供し、ルックアップ要求に関連するいくつかの動作を行う。ＬＵＦ４０８は、ホストからルックアップ要求を受信し、これらを処理してＬＣＣ４１４に転送し、ＬＣＣ４１４から受け取った応答を返す。ＬＵＦ４０８はまた、読取／書込要求（またはコマンド）をホストから受信し、これらが処理される。次に、ＬＵＦ４０８からホストへ応答が返される。

ＬＵＦ４０８のアーキテクチャおよび動作について、その構成要素であるＬＵＦ入力プロセッサ（ＬＩＰ）４２４およびＬＵＦ出力プロセッサ（ＬＯＰ）４４６を含めて、図１１〜図２２Ｂを参照してより詳細に説明する。ＬＵＦの全般的な機能には、各クラスタにおける保留中要求の数を追跡することが含まれる。この追跡を用いて、ルックアップクラスタに対するルックアップ要求の割当を通知してもよい。なぜなら、「最も」空きのあるクラスタの１つ（ｍ個のうちの１つ）は、全「ｍ個」の可能性のあるクラスタの中で保留クラスタ要求の数が最も小さいクラスタを選択することにより決定できるからである。（追跡されるクラスタ要求は、ＫｅｙＲｅｑ、ＨｏｓｔＯＣＭＲｅｑ、ＨｏｓｔＴＡＢＲｅｑ、またはＨｏｓｔＣＳＲＲｅｑであってもよい。）さらに、ＬＵＦ４０８は、両方のスーパークラスタに同じルールテーブル画像をロードすること（すなわち、スーパークラスタ冗長性）により、スーパークラスタの負荷分散を使用することを選択してもよい。次に、新たなルックアップ要求のそれぞれが、プログラム上で「最も空きのある」スーパークラスタに誘導されてもよい。

いくつかのパケット分類アプリケーションにおいて、ＬＵＦ４０８は、図２の探索プロセッサ２０２のようなプロセッサまたはプロセッサの一部であってもよい。他のパケット分類アプリケーションにおいて、ＬＵＦは、他のノードのネットワークにおけるスイッチまたはルータといった物理ネットワークノード（または装置）であってもよい。さらに他のパケット分類アプリケーションにおいて、ＬＵＦは、部品、モジュール、ブレードまたはカードとして、物理ネットワークノード（すなわち装置）の一部であってもよい。さらに他のパケット分類アプリケーションにおいて、ＬＵＦ４０８は、ソフトウェアおよびハードウェアの構成要素またはブロックを有してもよい。

図１１は、例示的なＬＵＦ入力プロセッサ（ＬＩＰ）４２４のブロック図である。ＬＩＰ４２４は、インタラーケンまたはＩ２Ｃインタフェース４８５ａ〜ｄからルックアップ要求（ＬＵＲＥＱ）およびホストコマンドを受信する。ＬＩＰ４２４は、これらの要求およびコマンドを構文解析し、次にこれらを、ルックアップクラスタ、ダブルデータレート（ＤＤＲ）メモリ、ＢＰＰまたは大域制御ステータス用レジスタ（ＣＳＲ）およびテーブルなどの内部リソースにスケジュールする。

ＬＩＰ４２４は、インタラーケンまたはＩ２Ｃインタフェース４８５ａ〜ｄから上記ルックアップ要求およびホストコマンドを受信する１つまたは複数のディストリビュータ４６０ａ〜ｂを有する。ディストリビュータ４６０ａ〜ｂは、スーパークラスタ間または１つのスーパークラスタ内で負荷分散を実現できる。次に、ディストリビュータ４６０ａ〜ｂは、ルックアップ要求をスケジューラ４２８ａ〜ｂに転送し、ルックアップ要求はルックアップクラスタ（例えば、図４ＢのＬＣＣ４１４）に出力される。

ディストリビュータ４６０ａ〜ｂおよびスケジューラ４２８ａ〜ｂは、負荷分散、クラスタ割当、キー抽出、キー要求の生成、サブツリー要求へのキー要求の分割、およびルックアップクラスタへのキー要求およびサブツリー要求のスケジューリング出力を含む、いくつかの機能を共に提供してもよい。これらの機能を促進し、かつ関連付けられたルックアップクラスタにおいて探索が行われる方法を制御するために、ＬＩＰ４２４は、いくつかのテーブルを使用してもよい。グループ定義／説明テーブル（ＧＤＴ）４２６は、他のテーブルに対するインデックスを提供する。パケットヘッダテーブル（ＰＨＴ）４３３ａ〜ｂは、パケットを構文解析する方法についての命令を提供する。ツリーロケーションテーブル（ＴＬＴ）４３０ａ〜ｂは、いずれのクラスタが探索を行うべきかについての情報を提供する。

ＴＬＴテーブル４３０ａ〜ｂは、いずれのｍ個（ｎ個のうちのｍ個）の可能性のあるクラスタが特定のツリーＩＤ（ルールのセット）を引き受けることができるかについての情報を含む。ホストルックアップ要求がその特定のツリーＩＤに対するものである場合、ＬＵＦの最も空きのあるクラスタのハードウェアロジックは、キー要求を担う（ｍ個の）クラスタのうち「最も空きのある」１つのクラスタを選択する。このように、ＬＵＦは、可能性のあるクラスタ間でホストルックアップ要求の負荷を等しく分散し、最小限の総ルックアップ待ち時間を実現する。これにより、プロセッサ全体にわたる総ルックアップ速度が増加する。

スケジューラ４２８ａ〜ｂのそれぞれは、各ルックアップ要求（ＬＵＲＥＱ）を処理し、キーを有するキー要求（ＫＲＱ）を最大４個生成する。このキー抽出の一例については、図５を参照して上述されており、また、図１４を参照してさらに詳しく後述する。ＫＲＱ（キーを含む）は、ルックアップクラスタコンプレックス（ＬＣＣ）にスケジュールされかつ送られ、処理に供される。１つまたは複数のクラスタにおけるツリーがいくつかの「サブツリー」に分割されるさらなる実施形態において、当該キー要求は、それぞれが特定のサブツリーに関連付けられたいくつかの「サブツリー要求」に「分割（split）」されてもよい。そして、サブツリーは、ＬＣＣ内の異なるクラスタに関連付けされてもよく、または、共通のクラスタに関連付けられてもよい。このように、１つのツリーによって指定されるルールのサブセットをサブツリーによって指定されるルールのより小さいサブセットにさらに絞り込んでもよい。これにより、探索の精度が高まる。

キー要求生成に続いて、スケジューラ４２８ａ〜ｂは、ＬＩＰ４２４からのＫＲＱをスケジュールする。スケジューラ４２８ａ〜ｂは、ペイロードヘッダ抽出部（ＰＨＥ）（図１２を参照して後述）およびスケジューラ出力マネージャ（図１５を参照して後述）を有する。

ルールテーブル画像を増分更新するために用いられるホスト読取／書込要求に対するホストルックアップ要求の順序をサポートするために、スケジューラ４２８ａ〜ｂにおいて専用ＨＷ機構を使用してもよい。ホストＲ／Ｗ要求（ホストルックアップを除く）は、ルックアップ／キー要求処理の際に必要なＣＳＲ、テーブル、ＯＣＭおよびＤＤＲのＲＣＤＳ画像データ構造に対するアクセスを含む。

全てのホストＲ／Ｗコマンドについて、ホストＳＷは、制御ヘッダ内に含まれる３つの「順序付け」フラグを使用してもよい。

１）ＨＯＳＴ＿ＲＳＰが設定された場合、探索プロセッサは、コマンドが完了した際に明示的なコマンド応答をホストに送る。これは読取コマンドには影響しないが、ホスト書込要求（ＨＯＳＴ＿ＲＳＰ＝１のフラグが設定された）については、ホスト書込応答パケットがホストＣＰＵに再び転送されることになり、これもまた、ホスト要求パケットと共に送られた同じＨＸＩＤ（ホストトランザクションＩＤ）を含む。

２）ＬＯＣＡＬ＿ＲＳＰが設定された場合、探索プロセッサは、ホストＲ／Ｗ要求がバス順で実行されることを保証する。換言すると、ホスト書込要求（ツリー更新）は、後続のホストルックアップ要求が出される前に強制的に「完了」させられるか、実行される。（ＲＡＷコンフリクト回避が必要とされる場合に使用される＝書き込み後のルックアップ読み取りというＨＷの順序を維持しなければならない）

３）ＡＴＯＭＩＣが設定された場合、ＮＳＰ ＨＷは、以前に発行された全てのホストルックアップ要求（同一のＴＩＤ＝ＴｒｅｅＩＤを有する要求）が、ホストＲ／Ｗ要求が発行される前に完了することを保証する。このＨＷは、増分ＳＷ更新（同じツリーＩＤについての）に対するホスト書込要求が、前のホストルックアップ要求に対して順番通りではなく実行されないことを保証するために使用される。（同じＴＩＤに対するＷＡＲコンフリクト回避が必要とされる場合に使用される＝ルックアップ読み取り後の書き込みというＨＷの順序付けが維持されなければならない）。特殊なＨＷは、再試行待ち行列を検出／排出し、次いで、同じＴＩＤ（＝ツリーＩＤ）を用いた以前の全てのホストルックアップ要求が実行されるかまたは完了するまで、この命令のスケジューリングをブロックしなければならない。これにより、当該ＴＩＤの全てのホストルックアップ要求が排出されるまで、チャンネル０の一時的なＨＯＬブロッキングが生じる。チャンネル１のコマンド（ホストＲ／Ｗ要求）は、この影響を受けない。

図１２は、例示的なペイロードヘッダ抽出部（ＰＨＥ）４７０のブロック図であり、ＰＨＥ４７０は、図１１を参照して上述したＬＩＰ４２４のスケジューラ４２８ａ〜ｂの構成要素であってもよい。ＰＨＥ４７０は、以下のブロックのうちの１つまたは複数を含む。すなわち、新規待ち行列４７２、ツリーロケーションテーブル（ＴＬＴ）４３３、ペイロードヘッダテーブル（ＰＨＴ）４３０、ＴＬＴテーブルマネージャ４７４、ＰＨＴテーブルマネージャ４７６、新規待ち行列・ペイロードマネージャ４７８、ＰＨＴバイトスワッパ４８０、ビットパッカ４８４、およびペイロード／パケットヘッダ抽出部の有限状態機械（４８２）であり、これらのそれぞれについて以下に説明する。

ＰＨＥ４７０は、一般に、以下の機能のうちの１つまたは複数を実行するように構成されてもよい。
●新規待ち行列からのルックアップ要求（ＬＵＲＥＱ）および読取／書込要求を受信する。
●選択されたエンディアンモードについて必要に応じてバイトスワッピングを行う。
●各ＬＵＲＥＱの全ての有効ＴＩＤについてＴＬＴテーブルルックアップを実行する。
●各ＬＵＲＥＱの全ての有効ＴＩＤについてＰＨＴテーブルルックアップを実行する。
●ヘッダデータを抽出および処理し、ＬＵＲＥＱおよび読取／書込要求をキー要求（ＫＲＱ）に変換する。
●ＬＯＰのＬＲＴおよびＬＲＴ情報テーブルのデータを初期化する。

概要としては、動作中、ＰＨＥ４７０は、新規待ち行列の３つの部分から要求を引き出し、バイトスワッピングおよびテーブルルックアップを必要に応じて行い、データを処理してキー要求（ＫＲＱ）とし、ＫＲＱをテーブルデータと共にスケジューラ出力マネージャ（図１５を参照して後述）に送る。

各スケジューラ４２８ａ〜ｂは、フロントエンドにおいて新規待ち行列４７２（または「新規作業待ち行列」）を有する。これらの新規待ち行列のサイズが十分に大きい場合、１つのスケジューラの短期的なオーバーローディングがシステム全体の行頭（ＨＯＬ）ブロッキングを起こすことはなく、スケジューラのバックログは待ち行列によって吸収されることになり、新規作業が他のスケジューラ４２８ａ〜ｂに流れる。

新規待ち行列４７２は、パケットヘッダを受信する、１６個の格納場所であってもよい。パケットヘッダは、このＦＩＦＯの１２８ビット幅のスライスにおいてバッファされる。各ヘッダは、サイズに関わらず、ＦＩＦＯの少なくとも１×１２８ビットを占めるため、パケットヘッダは、待ち行列が保持するルックアップパケットの数を制限してもよい。新規待ち行列４７２は、パケットが装置に流入する際にロードされる。待ち行列は、ＬＵＦディストリビュータ０（ＬＤ０）からのルックアップ要求およびＩＬチャンネル０のＤＤＲ／ＯＣＭ／テーブル要求を含む。ビットパッカ４８４は受信したルックアップのそれぞれについて１〜４個のＫＲＱを生成できるため、新規待ち行列４７２は、スケジューラ４２８ａ〜ｂに順応性を提供する。ホスト読取／書込コマンドは、ホストから送られたフォーマットと同一のフォーマットで、新規待ち行列に、構文解析されることなく配置される。

スケジューラ４２８ａ〜ｂがより効率的に各パケットの処理を管理できるように、新規待ち行列は、３つのセクション（ペイロード、ＨＩＤ、およびＴＩＤ）に分割されてもよい。ＬＤ０は、３つのセクション全てを同時にパケット開始位置（ＳＯＰ）に書き込まれてもよい。新規待ち行列４７２のＨＩＤセクションおよびＴＩＤセクションは、１つのパケットにつき１つのエントリを有してもよい。パケットペイロードは、１２８ビットのエントリにおいて新規待ち行列４７２のペイロードセクションに格納されている。ＦＩＦＯの最大５個のエントリが１つのパケットに対して要求され得る。ＬＤ０は、新規待ち行列全体にわたってパリティを計算し、その値を共通エントリ（ＮＱ＿ｐａｒ）として新規待ち行列の３つのセクション全てに書き込み、データ割当の監視においてＰＨＥを補助する。

ＰＨＥ４７０は、新規待ち行列４７２の各セクションから個別に引き出しを行ってもよい。これにより、ＰＨＥ４７０は、ペイロードデータの複数のクロックを同時に引き出しながら、テーブルデータのパイプラインおよび前処理を行うことができる。ＮＱ＿ｐａｒエントリを３つのセクション全てにわたって比較してデータ割当を監視し、この確認ができなかった場合、状態レジスタにエラー表示のフラグが立てられる。

ＰＨＴ新規待ち行列ペイロードマネージャ４７８は、新規待ち行列４７２のペイロードセクションからデータを引き出し、これをバイトスワッパ４８０と、最大５１２ビットのビット長の１つのデータフィールドに形成されるペイロードヘッダ抽出部ブロックとに提示する。バイトスワッパの動作については、図１３を参照してより詳細に後述する。

ツリーロケーションテーブル（ＴＬＴ）４３３は、いずれのクラスタが所与のジョブを実行することができるかを判定するために、スケジューラ４２８ａ〜ｂのリーストフルクラスタジェネレータ（最も空きのあるクラスタのジェネレータ）（ＬＦＣＧ）によって使用される。ツリー識別子（ＴＩＤ）は、ＴＬＴ４３３へのインデックスとして使用される。ＴＬＴ４３３は、ホストによりロード可能であってもよく、また、以下のフィールドのうちの１つまたは複数を含んでもよい。
●ＫＦＴＩＤＸ（キーフォーマットインデックス） ペイロードとしてＫＥＹＲＥＱと共にクラスタに送られる。クラスタは、これを用いて１つ（６４個のうちの１つ）のキーフォーマットを参照する。キーフォーマットは、クラスタが２８個まで（最大）のＤＩＭＥＮＳＩＯＮをＫＥＹＤＡＴＡ内で各ＫＥＹについて抽出する方法を定義し、ＲＦＴ（ルールフォーマットテーブル）を索引付けするためにも使用される。すべてのＫＥＹＲＥＱコマンドと共に送られ、各クラスタのＫＤＴテーブルに（ＫＥＹＤＡＴＡと共に）格納される。
●ＴＷＲＳＰＣＮＴ（期待される応答数）。これは、ＬＲＴのＴＷＲＳＰＣＮＴフィールドに書き込まれる。値３’ｂ０００は、８個の応答が期待されることを示す。
●ＴＷＣＬＭＳＫ（ツリーウォーククラスタマスク）［ＳＴにつき１個＝最大8個のサブツリー（最大数）］：（スーパークラスタ内の）いずれのクラスタがツリーウォーク要求（ＴＷＲｅｑ）を受け付けることができるかを指定する。ＬＵＦ０の場合、これらはＳＣ０に関連し、ＬＵＦ１の場合、これらはＳＣ１に関連する。新規ツリーウォーク要求をクラスタコンプレックス（クラスタの複合部）にスケジュールする際に「最も空きのあるクラスタ」を決定するためにＨＷによって使用される。ＳＷは、マスクの指定されたクラスタにツリー（Ｎ＋Ｌ）画像を予めロードしていてもよい。
●ＴＷＣＬＭＳＫ＿ＡＬＴ（代替ツリーウォーククラスタマスク）［ＳＴにつき１個＝最大８個の（最大数）サブツリー］：上記ＴＷＣＬＫＳＫと同様であるが、反対のスーパークラスタ内のいずれのクラスタがツリーウォーク要求（ＴＷＲｅｑ）を受け付けることができるかを指定する。シングルＬＵＦモードにおいてのみ有効。ＬＵＦ０の場合、これらはＳＣ１に関連する。ＬＵＦ１の場合、これらは無効である。使用例は以下の通りである：
○DUAL LUF MODE(LUF0 or LUF1) : Each TWCL Mask = {8'h00, TWCLMSK} （デュアルＬＵＦモード（ＬＵＦ０またはＬＦＵ１：各ＴＷＣＬマスク＝｛８’ｈ０００，ＴＷＣＬＭＳＫ｝））
○SINGLE LUF MODE(LUF0 Only) : Each TWCL Mask = {TWCLMSK_ALT, BWCLMSK} （シングルＬＵＦモード（ＬＵＦ０のみ：各ＴＷＣＬマスク＝｛ＴＷＣＬＭＳＫ＿ＡＬＴ，ＢＷＣＬＭＳＫ｝））
●ＢＷＣＬＭＳＫ（バケットウォーククラスタマスク）：いずれのクラスタがバケットウォークを担当するのかを指定する。ＳＷは、いずれのクラスタがＬＵＣＴＮＡ．ｒｕｌｃｌｎｕｍフィールドに使用されるのかを知らなければならない。このフィールドは、ＬＵＦ−＞クラスタコンプレックス（ＫＲＱバス）から送られたマルチキャストＫＥＹＲＥＱコマンド中に、いずれのクラスタがＫＥＹＤＡＴＡを 「取得」すべきかをＨＷが判定するのを助ける。ＫＥＹＤＡＴＡは、アクティブなＴＷＥまたはＢＷＥスレッドを有する全てのクラスタにおいてローカルで利用可能（冗長）である必要がある。ＴＷＥは、ツリーウォーク処理の際にＫＥＹＤＡＴＡを使用し、ＢＷＥは、ＲＭＥによるルールマッチングの際にＫＥＹＤＡＴＡを使用する。
●ＢＷＣＬＭＳＫ＿ＡＬＴ（代替バケットウォーククラスタマスク）：上記ＢＷＣＬＭＳＫと同様であるが、反対のスーパークラスタ内のいずれのクラスタがバケットウォークを担当するかを指定する。シングルＬＵＦモードのみにおいて有効。ＬＵＦ０の場合、これらはＳＣ１に関連する。ＬＵＦ１の場合、これらは無効である。使用例は以下の通りである：
○DUAL LUF MODE(LUF0 or LUF1) : Full Bucket mask = {8'h00, BWCLMSK} （デュアルＬＵＦモード（ＬＵＦ０またはＬＦＵ１：全バケットマスク＝｛８’ｈ０００，ＢＷＣＬＭＳＫ｝））
○SINGLE LUF MODE(LUF0 Only): Full Bucket mask = {BWCLMSK_ALT, BWCLMSK} （シングルＬＵＦモード（ＬＵＦ０のみ：全バケットマスク＝｛ＢＷＣＬＭＳＫ＿ＡＬＴ，ＢＷＣＬＭＳＫ｝））

ＰＨＥ４７０のＴＬＴテーブルマネージャ４７４は、新規待ち行列ＴＩＤセクションの各エントリについて、最大４個のルックアップをツリーロケーションテーブル（ＴＬＴ）４３３に生成する。このデータは、ＰＨＥ４７０において処理しなくてもよいが、代わりに、スケジューラ出力マネージャ（以下の図１５）に送られて、そこでリーストフルクラスタジェネレータ（ＬＦＣＧ）において使用されてもよい。

パケットヘッダテーブル（ＰＨＴ）４３０は、最大５１２ビットのヘッダを最大３８４ビットのキーにマスクおよび多重化する方法を指定するための６４個のエントリのテーブルとして構成されてもよい。各ＨＩＤは、４つのＰＨＴライン（またはエントリ）のグループを選択してもよい。ＰＨＴ４３０の各ラインは、以下のＧＤＴにおける４つのＴＩＤのうちの１つに対応してもよい。
PHT Index for TID0 = HID+0
PHT Index for TID1 = HID+1
PHT Index for TID2 = HID+2
PHT Index for TID3 = HID+3

ＰＨＴ４３０の各ラインは、ヘッダデータをマスクおよび多重化する方法を指定する９個のディメンジョン（要素）を含む。これらのディメンジョンのそれぞれは、以下を指定する。
●発信元フィールド開始ビット位置
●発信元フィールド終了ビット位置
●宛先フィールド開始ビット位置
●宛先フィールドサイズ（ビット単位）

この情報を用いて、ＰＨＴ４３０は、ビット分解により、９つのチャンクをヘッダからキーにマッピングできる。

ＰＨＴテーブルマネージャ４７６は、新規待ち行列４７２のＨＩＤセクションの各エントリについて、ルックアップをパケットヘッダテーブル（ＰＨＴ）４３０内に生成する。ルックアップは、各キーについて生成される。したがって、１つの新規待ち行列ＨＩＤエントリは、最大４つのルックアップを生成することができる。このデータは、ヘッダのペイロードデータを抽出し、結果として生じるキー要求（ＫＲＱ）を生成するためにビットパッカ４８４によって使用される。

ホストルックアップ要求パケットのバイトエンディアンネスを調整するために、プログラム可能バイトスワッパ４８０が設けられている。ホスト読取／書込要求パケットは、影響を受けない。ＰＨＴバイトスワッパは、各ユーザパケットのインタラーケン制御ワードの後に送信される最初の６４ビットである探索プロセッサヘッダ上では動作しない。ＰＨＴバイトスワッパは、ルックアップ要求パケット内の探索プロセッサヘッダに続く全てのデータ上で動作する。異なるバイトスワッピングモードを示す図については、図１３を参照して後述する。

ペイロード／パケットヘッダ抽出部の有限状態機械（ＰＨＥ ＦＳＭ）４８２は、バイトスワッパ４８０からのデータ、ビットパッカ４８４の出力、ＰＨＴ４３０のデータ（パケットヘッダから抽出されたディメンジョンがパックされたキーを含む）、およびＴＬＴ４３３のデータ（所与のルックアップ要求を処理するクラスタのＩＤを含む）からのデータをまとめる。ＰＨＥ ＦＳＭ４８２は、後にスケジューラ出力マネージャ（図１５）に送られるＫＲＱを検索または生成するために、これらの入力を使用してもよい。

検索または生成されたＫＲＱのそれぞれについて、２ビットのＳＸＩＤが生成される。ＬＲＴおよびＬＲＴ ＩＮＦＯエントリが、フリープールからＫＩＤを引き出すことにより、各キーのために確保される。ＫＩＤは、予め引き出され、キャッシュされる必要がある。システムがＫＩＤを使い切った場合、スケジューラＨＯＬは、探索完了によってＫＩＤが利用可能となるまでブロックされる。

ＰＨＥ ＦＳＭ４８２は、ペイロードヘッダデータからのＣＭＤフィールドをチェックして、形成すべきＫＲＱのタイプを判定する。それがＬＵＲＥＱであって、かつ１対１モードではない場合、ＰＨＥは、ビットパッカ４８４からＫＲＱを取り出し、そうでない場合、そのＫＲＱタイプの必要なヘッダフィールドを抽出するためのペイロードヘッダデータを構文解析することによりＫＲＱを生成する。

ＫＲＱは、対応するＴＬＴ４３３のデータと共に、スケジューラ出力マネージャ（図１５）に送られる。ＫＲＱデータは、１２８ビットの増分で送信されてもよい。ＴＬＴ４３３のデータは、ＫＲＱのパケット開始位置（ＳＯＰ）と共に１回の送信で送ってもよい。

図１３は、ＰＨＥ４７０の構成要素であるバイトスワッパ４８０によって選択可能な異なるバイトスワッピングモードを示すパケット図である。プログラム可能なバイトスワッパ４８０は、ホストルックアップ要求パケットのバイトエンディアンネスを調整する。ホスト読取／書込要求パケットは、影響を受けない場合がある。バイトスワッパ４８０は、各ユーザパケットについてインタラーケン制御ワードの後に送信される最初の６４ビットである探索プロセッサヘッダ上では動作しない。ＰＨＴバイトスワッパは、ルックアップ要求パケット内の探索プロセッサヘッダに続く全てのデータ上で動作する。

バイトスワッパ４８０のエンディアンモードは、本発明の便宜的な実施形態に係る構成レジスタにおいて設定される。場合によっては、スワッピングの最小粒度はバイトであり、ビットミラーリングはサポートされていない。図１３に示すのは、相互排他的な例示のスワップモードであり、
●スワップなしでは、何もしない
●６４ビットでバイトをスワップする場合、各６４ビットワード内でバイトを反転させる。
●６４ビットの３２ビットワードの場合、６４ビットワード内で３２ビットワードを反転させる。
●３２ビットでバイトをスワップする場合、各３２ビットワード内でバイトを反転させる。

図１４は、通常キー拡張モードで動作するＰＨＥ４７０を示すパケット図である。この例示的な実施形態において、ＰＨＥ４７０は、キー拡張またはパケットヘッダ抽出というＬＵＦ手順において、ヘッダデータを抽出および処理してＬＵＲＥＱに変換するとともに、読取／書込要求をキー要求（ＫＲＱ）に変換する。ＬＵＲＥＱのためのキー拡張には２つのモードがある。すなわち、通常キー拡張モード（ＧＩＤ＞０の場合、ビットパッカブロックを使用する）および１対１モード（ＧＩＤ＝０の場合）である。

通常キー拡張モードにおいて、各ＬＵＲＥＱは、図５を参照して上述したように、最大４個のキー要求（ＫＲＱ）を生成することができる。パケットヘッダテーブル（ＰＨＴ）に格納されたプログラム可能テーブルを用いて、ＬＵＲＥＱをキー要求に構文解析してもよい。図５に示すように、ＬＵＲＥＱは、以下のフィールドを含んでいてもよい。
●ホストからのＸＩＤ（３２ビット）ＩＤ。探索プロセッサによっては使用されず、応答と共にホストに返されるだけである。
●ＧＩＤ（８ビット）（グループＩＤ）。このパケットがいずれのクラスであるかを示す識別子であり、パケットが処理される方法を制御する。

ルックアップデータ（最大５１２ビット）。キーはこのデータから形成される

図１４に戻って、通常キー拡張モードで動作するＰＨＥの例において、４つのチャンクがパケットヘッダから抽出されている。チャンク０（ＣＨＵＮＫ０）の抽出は、図示のフィールド０のＳＲＣ＿ＳＴＰＯＳ、ＳＲＣ＿ＥＮＤＰＯＳによって詳細に示されている。なお、ヘッダのディメンジョンは順番通りである必要はないが、キー（ＫＲＱ）にパックされている場合、ＣＨＵＮＫ０は、左端フィールドでなければならない。また、ビットオフセットが左端ビットを始点とすることにも留意されたい。

ＰＨＴ４３０（図１２）を用いて、最大４つのキー（ＫＲＱ）が各ＬＵＲＥＱから生成される。生成されたキー（ＫＲＱ）は、次に、ＰＨＥ ＦＳＭ４８２（図１２）に渡され、ＰＨＥ ＦＳＭ４８２は、それらをＫＲＱとして１２８ビットの増分でスケジューラ出力マネージャ（図１５）に送る。

反対に、１対１モードにおいては、ＧＩＤ＝０の場合、ヘッダは、ビットパッカを迂回することになり、１つのキーとしてそのまま使用されることになる。インタラーケンのＬＡコンパクトモードにおいて、ヘッダを１つのキーとしてそのまま使用することにより、３８４ビットよりも大きいヘッダの１サイクルによる待ち時間が減少する。

図１５は、例示的なスケジューラ出力マネージャ４９０のブロック図であり、スケジューラ出力マネージャ４９０は、ＬＩＰ４２４のスケジューラ４２８ａ〜ｂの構成要素であってもよい。スケジューラ出力マネージャは、スケジューラ４２８ａ〜ｂの「バックエンド」として動作してもよい。スケジューラ出力マネージャは、以下のブロックのうちの１つまたは複数を含む。すなわち、これらブロックとしては、リーストフルクラスタジェネレータ（ＬＦＣＧ）４９２、再試行待ち行列４９３、発信元セレクタ４９４、およびスケジューラ出力マネージャの有限状態機械（ＦＳＭ）４９５であり、これらのそれぞれについて以下に説明する。

例示的な実施形態において、スケジューラ出力マネージャ４９０は、以下の機能のうちの１つまたは複数を実行してもよい。
●スケジューラＰＨＥおよびＬＵＦディストリビュータ１（ＬＤ１）からＫＲＱを受信する。
●再試行待ち行列４９３においてＫＲＱを管理する。
●コマンドフラグであるアトミックおよびローカルの応答に必要な行頭ブロッキング（ＨＯＬＢ）を強制的に行う。
●リーストフルクラスタジェネレータ（ＬＦＣＧ）４９２を用いて、いずれのＬＵＥクラスタが各ＬＵＲＥＱ ＫＲＱを処理すべきかを判定する。
●優先性方式およびクレジットカウンタを用いてＫＲＱをスケジュールし、次のＫＲＱ発信元（ＰＨＥ、ＬＤ１、再試行待ち行列）を選択する。
●スケジュールされたＫＲＱを６つの可能性のあるＫＲＱバスのうちの１つまたは複数に方向付ける。

スケジューラ出力マネージャ４９０は、可能性のある３つのソースである、ＰＨＥ、ＬＤ１、および再試行待ち行列から一度に１つのＫＲＱを選択する。スケジューラ出力マネージャ４９０は、可能性のある６つのＫＲＱバス（ＳＣ０、ＳＣ１、ＢＰＰ０、ＢＰＰ１、ＭＷＱ（ＤＤＲ）、大域ＣＳＲ／テーブル）のうちの１つまたは複数に、送信対象の各ＫＲＱをスケジュールする。代わりに、スケジューラ出力マネージャ４９０は、ＬＵＲＥＱ ＫＲＱをＰＨＥから再試行待ち行列に移動させるか、またはＫＲＱを再試行待ち行列の先頭か当該待ち行列の最後尾に再循環させてもよい。スケジューラ出力マネージャ４９０は、これらの決定を、各ＫＲＱ宛先から利用可能なクレジットに注目し、かつＬＵＲＥＱ ＫＲＱについてリーストフルクラスタジェネレータ（ＬＦＣＧ）を実行しながら、ＫＲＱ ＣＭＤに基づいて行う。

ホスト読取／書込要求は、これらがＫＲＱバス上に成功するルックアップ要求と共に順番にスケジュールされるように、スケジューラパイプラインをルックアップ要求と直列に通過する。スケジュールできずに再試行待ち行列に進んだルックアップ要求は、順番通りではなくなる。アトミックまたはローカルの応答フラグの使用を、ある順序付け条件（さらなる詳細については後述）を強制するために用いてもよい。

リーストフルクラスタジェネレータ（ＬＦＣＧ）４９２のブロックは、いずれのエンジンが所与のルックアップ要求を処理するかを決定する。ＬＦＣＧ４９２は、ツリーロケーションテーブル（ＴＬＴ）４３３（図１２）からのデータを使用し、作業を実行することができるクラスタを探し出すのに必要な情報を検索する。

例示的な実施形態において、ＬＣＣは、２つのスーパークラスタを含み、各スーパークラスタは、８つのクラスタを含み得る。各クラスタにおける探索エンジンのアクティビティレベルは、各クラスタについて１つのクレジット／デビットカウンタを用いてＬＦＣＧ４９２により監視される。シングルＬＵＦモードにおいては、１つのＳＣＨ０が、両方のスーパークラスタをカバーする１６個のカウンタを全て維持する。デュアルＬＵＦモードにおいては、上記２つのスケジューラが、それぞれ８個のカウンタを維持する。各クレジットは、クラスタ入力待ち行列における１つのＦＩＦＯ位置を表す。クレジット／デビットカウンタは、ＦＩＦＯの深さにリセットされる。ジョブがクラスタにスケジュールされると、これらのカウンタはＬＦＣＧによってデクリメントされる。クラスタが１つのエントリをＦＩＦＯから除去したことをクラスタが示すと、カウンタはインクリメントされる。

ＬＦＣＧ４９２は、以下のフィールドを生成してもよい。
●ＬＦＴＷＣＬＭＳＫ（リーストフルツリーウォーククラスタマスク）。１つのクラスタにつき１ビット存在する。このマスクに設定された各ビットは、対応するクラスタが作業を開始することを示す。デュアルＬＵＦモードにおいては、各スケジューラからＬＦＴＷＣＬＭＳＫ［７：０］のみが使用される。
●ＫＣＬＭＳＫ（キークラスタマスク）１つのクラスタにつき１ビット存在する。このマスクに設定された各ビットは、対応するクラスタが、同報通信されるとＫＥＹＲＥＱをラッチすることを示す。これは、クラスタがこのデータを利用する必要がある場合があるからである。デュアルＬＵＦモードにおいては、各スケジューラからＫＣＬＭＳＫ［７：０］のみが使用される。

ＬＦＣＧブロックは、以下を用いてスケジューラに応答する。
●ＳＣＬ
●ＬＦＴＷＣＬＭＫＳ
●ＫＣＬＭＳＫ
●ＡＣＫ／ＮＡＫ ＬＦＴＷＣＬＭＳＫの生成について、成功＝１、失敗＝０。

ＬＦＣＧ４９２は、ＴＬＴ４３３から読み取った情報およびそれ自身のクレジットに基づいて、ＬＦＴＷＣＬＭＳＫを生成する。このマスクにおける各ビットは、スレッドに作業を開始させる。ルックアップクラスタコンプレックス（ＬＣＣ）内の詳細により、これはＬＵＦが再び受信した応答数に必ずしも一致しなくてもよい。このため、ＴＬＴからのＴＷＲＳＰＣＮＴは、ＬＵＦが期待すべき応答の実際の数を含む。

１つのキーについてのスケジュールの試みが失敗すると、要求は再試行待ち行列４９３に移され、行頭（ＨＯＬ）ブロッキングが回避される。ＨＯＬブロッキングは、ＴＷＣＬＭＳＫに一致するクラスタがあまりにもビジーでジョブを受け付けることができないときに起こる。

再試行待ち行列４９３は、最大８個のＫＲＱビートを保持するようなサイズを有する。ルックアップ要求のみが再試行待ち行列４９３に進む。ホスト読取／書込コマンドは、再試行待ち行列に進まず、これらのコマンドが成功しなかった場合にＨＯＬブロッキングを起こす。

再試行待ち行列４９３に配置されたルックアップ要求は、順番ホストＲ／Ｗコマンドに対して順番通りではなくなる。所与のアプリケーションについてこれが許容されない場合、再試行待ち行列４９３を無効にしてもよく、または、ホストが、提供されたアトミックコマンドを用いて介入してもよい。

再試行待ち行列４９３エントリは、ＰＨＥ４７０（図１２）からのインタフェースと同じフォーマットのものであってもよい 。これには、完全に形成されたＫＲＱ（１２８ビットのデータ増分で）および当該キーについてのＴＬＴデータ全体の両方が含まれる。ＫＲＱデータ全体を格納するために、最大３個のＦＩＦＯエントリ（３クロック）が必要となる場合がある。スケジューラ４２８ａ〜ｂ（図１１）は、データをＰＨＥ４７０から再試行待ち行列４９３に移動させると同時に、ＫＲＱバスにＩＤＬＥを出力する。

スケジューラ出力マネージャ４９０は、再試行待ち行列４９３が排出される（空にされる）前にいくつのホストコマンドが新規待ち行列４７２から引き出されるかを判定する、プログラム可能ＲＥＴＲＹ＿ＬＯＣＫＯＵＴ＿ＣＯＵＮＴＥＲを含んでもよい。カウンタは、ＲＥＴＲＹ＿ＬＯＣＫＯＵＴ＿ＣＦＧレジスタにおける値にリセットされ、ＰＨＥが新規待ち行列ペイロードＦＩＦＯからＳＯＰを読み取る（複数のＫＲＱが生成される前に）たびにデクリメントされる。また、ＲＥＴＲＹ＿ＬＯＣＫＯＵＴ＿ＣＦＧは、再試行待ち行列４９３を無効にするように設定されてもよい。

さらに、プログラム可能ＲＥＴＲＹ＿ＨＩＧＨ＿ＷＡＴＥＲＭＡＲＫは、 再試行待ち行列が排出される前の再試行待ち行列の最大充填レベルを決定する。ＲＥＴＲＹ＿ＨＩＧＨ＿ＷＡＴＥＲＭＡＲＫの最小設定は、０ｘ３である。設定「Ｎ」は、Ｎ＋１個のＫＲＱビートがそこに書き込まれたときに再試行待ち行列が排出されることを意味する。ＲＥＴＲＹ＿ＨＩＧＨ＿ＷＡＴＥＲＭＡＲＫがＲＥＴＲＹ＿ＱＵＥＵＥのサイズより大きく設定された場合、再試行待ち行列４９３は、メモリの最大充填レベルに達するならば排出される。

また、再試行待ち行列４９３は、アトミックコマンドを処理する前に排出される。（アトミックコマンドは、指定されたＴＩＤを処理前に全て排出する。）排出は、指定されたＴＩＤが再試行待ち行列にある場合を扱うのに必要となる。

再試行待ち行列４９３が排出のために選択されると、ＰＨＥ４７０からの新規待ち行列データは、当該再試行待ち行列が空になる（すなわち、排出される）まで再び選択されることはない。これにより、ロックアウト状態が防止される。再試行待ち行列４９３の排出中、成功しなかったためにＬＦＣＧ４９２からスケジュールすることができないＫＲＱは、再試行待ち行列４９３の最後尾に再循環される。スケジューラ４２８ａ〜ｂは、ＫＲＱが待ち行列の最後尾に再循環され、新規データが再試行待ち行列の先頭に進められる間に、ＩＤＬＥ（最大３クロックサイクル）を出力する。

要約すると、再試行待ち行列は、３つの条件、すなわち、ＲＥＴＲＹ＿ＬＯＣＫＯＵＴ＿ＣＯＵＮＴＥＲ、アトミックコマンド、およびＲＥＴＲＹ＿ＨＩＧＨ＿ＷＡＴＥＲＭＡＲＫの下で完全に排出され得る（すなわち、要求が空になり得る）。

また、再試行待ち行列４９３は、別の条件下では、アクセスはされるが完全には排出されない場合がある。再試行待ち行列４９３が選択されていないが、ＰＨＥ４７０からのデータの流れにアイドル状態のサイクルが存在する場合、および再試行からのＬＦＣＧ４９２が成功した場合、１つのＫＲＱが再試行待ち行列４９３から引き出され、スケジュールされる。これらのアイドル状態のサイクルは、空の新規待ち行列４７２が原因で、あるいは大きいヘッダから小さいキー、例えば、５１２ビットのヘッダ（４サイクル）から３８４ビットのキー（３サイクル）を生成することによって生じる偶発的なバブルにより発生する。ＬＦＣＧ４９２は、完全に排出されることになる再試行待ち行列が選択されておらず、したがってエントリがスケジュールに成功するか否かを判定するためにエントリをポップする必要がない場合であっても、再試行待ち行列の先頭のエントリに対して常に計算してもよい。

全てのチャンネル０のホスト読取／書込要求は、以下のフラグを含んでいてもよい。アトミック、Ｈｏｓｔ−Ｒｅｓｐ、およびＬｏｃａｌ−Ｒｅｓｐ。これらのフラグは、チャンネル１の要求およびルックアップ要求について有効でなくてもよい。これらのフラグについて、以下に説明する。

アトミックアクセスは、１つのテーブル識別子（ＴＩＤ）についての全てのアクティビティが完全に排出されるまで、システム内への全てのトラフィックを停止する機構である。アトミックアクセスは、テーブル更新に有用であり得る。なぜなら、これにより、書き込みが発生可能になる前に、これらのテーブルを用いて進行中の全ての探索が終了することが保証されるからである。アトミックアクセスにより、全ての探索は、更新の途中ではなく、更新前または更新後にアトミックデータ上で作業することが可能となる。

アトミックアクセスを実現するために、ＴＩＤ毎の２５６個のカウンタのアレイが設けられ、各ＴＩＤの実行中のジョブ数を追跡する。これらのカウンタは、ＬＵＦが実際にＳＣＨキー／ＳＸＩＤをスケジュールするとインクリメントされ、当該キー／ＳＸＩＤの全ての応答が返されるとデクリメントされる。再試行待ち行列上にあるキー要求は、これらのキーが実際にスケジュールされるまでこれらのカウンタをインクリメントしなくてもよい。

アトミックビットセットを用いてコマンドが処理される場合、スケジューラ出力マネージャ４９０は、以下を実行する。
●再試行待ち行列を排出する
●コマンドのＴＩＤフィールドに一致するＴＩＤカウンタがゼロになるのを待つ間、ＨＯＬブロックを実行する。
●ホスト読込コマンドまたはホスト書込コマンドを発行する。

Ｈｏｓｔ−Ｒｅｓｐフラグは、探索プロセッサに応答をホストに送り返させる。Ｈｏｓｔ−Ｒｅｓｐフラグは、ホスト書込にとってのみ意味を有する（ホスト読取は常に応答を送る）。Ｈｏｓｔ−Ｒｅｓｐフラグにより、 ホストは、書き込みがいつ終わったのかを判断することができる。

Ｈｏｓｔ−Ｒｅｓｐフラグを実現するために、スケジューラは、下流へ送るコマンドの一部としての信号を設定する。応答ブロックは、応答の返送を取り扱う。

Ｌｏｃａｌ−Ｒｅｓｐフラグは、探索プロセッサにホスト読込コマンドまたはホスト書込コマンドを発行させ、次に、コマンドが回収されるまで全てのトラフィックをＨＯＬブロックする。その後、応答が送られてもよい。

スケジューラ出力マネージャ４９０は、ＫＲＱバスへのアクセスが許容されるか否かを判断するために以下のクレジット／デビットカウンタを維持する。

クラスタクレジット（１つのエンジンにつき１つのカウンタ）。ＳＣＨ０は、シングルＬＵＦモードの場合には１６個のクラスタを必要とし、デュアルＬＵＦモードの場合には８個のカウンタを必要とする。ＳＣＨ１は、デュアルＬＵＦモードにおいてのみ動作するので、８個のカウンタのみを必要とする。各カウンタは、１つのクラスタにつき最大１６個のクレジットを保持する。各クレジットは、１個のＫＲＱビートを表す。これらは、以下のためにデビットされる。
●ルックアップ要求
●ＯＣＭＥＭ ＲＤ／ＷＲＴ
●ＬＣＣテーブルＲＤ／ＷＲＴ

大域インタフェースクレジットは、ＳＣＨ０およびＳＣＨ１はいずれも大域ブロックにおける小さいＦＩＦＯに提供され、大域ブロックもまた、チャンネル１のディストリビュータによって提供される。これらソースの３つ全ては、これらがＦＩＦＯをオーバーランさせないことを保証するためにクレジット／デビットを保持しており、少なくとも３つのクレジットが残っていることを保証しなければならない。

ＤＤＲ書込クレジットは、ＳＣＨ１はＤＤＲコマンドを取得しないため、ＳＣＨ０によってのみ保持される。ＭＢＣは、１６個のホスト書込を受け付けることができる。

ＤＤＲ読取クレジットは、ＳＣＨ０によってのみ保持される。ＢＰＰは、最大４個のホスト読取をバッファすることができる。クレジット／デビットにより、ＢＰＰがオーバーランしないことが保証される。

ＢＰＰホスト・テーブル・クレジットは、ＳＣＨ０によってのみ保持される。クレジット／デビットにより、ＢＰＰがオーバーランしないことが保証される。クレジットは、応答を含むＢＰＰ読取および書込の間で共有される。ＬＯＰが無制限の数の応答をバッファすることができるため、クレジットは、応答を含まない書き込みについては調整されない。

スケジューラ発信元セレクタ４９４は、ＳＯＭ ＦＳＭ ４９５の出力を転送するための接続出力における選択を可能にする。スケジュールアウトプットマネージャ４９０は、スケジューラ（ＳＣＨ）４２８ａ〜ｂから送られることになる次のＫＲＱの発信元を以下の状態に基づいて選択するようにセレクタ４９４を制御する。
●ＰＨＥを選択（ＳＣＨは、次のクロックで新規待ち行列データを出力する）
●ＲｅｔｒｙＱを選択（ＳＣＨは、次のクロックで再試行待ち行列データを出力する）
●ＬＤ１を選択（ＳＣＨは、次のクロックでＩＬＫＮチャンネル１のデータを出力する）
●ＲｅｔｒｙＱへのＰＨＥ（ＳＣＨは、新規待ち行列データをＰＨＥから再試行待ち行列へプッシュし、次のクロックでｉｄｌｅを出力する）
●ＲｅｔｒｙＱを再循環（ＳＣＨは、再試行待ち行列上のデータを再循環させ、次のクロックでｉｄｌｅを出力する）

発信元が選択されると、次のＳＯＰについての発信元が選択される前に、ＫＲＱパケット全体が送られる（ＳＯＰからＥＯＰまで）。

図１６は、要求およびコマンドを構文解析し、それらをパケット分類のために内部リソースにスケジュールする例示的な手順を示すデータフローチャートである。この手順は、図１１〜図１５を参照して上述した各処理から導き出されたものである。この手順は、ＬＩＰ（例えば、図１１のＬＩＰ４２４）によって実行されてもよい。また。この手順は、以下に説明する例示的な手順を表す命令をロードおよび実行することによりＬＩＰに変形されたコンピュータ（またはプロセッサ）によって実行されてもよい。

本発明の実施形態によると、ＬＵＦ入力プロセッサ（ＬＩＰ）は、他のノードのネットワークにおける、スイッチまたはルータなどの物理ネットワークノード（すなわち装置）であってもよい。ＬＩＰは、当該ノードの構成要素、モジュール、ブレードまたはカードとしての物理ネットワークノード（すなわち装置）の一部であってもよい。

本発明の別の実施形態によると、ＬＩＰは、プロセッサ、メモリ、通信インタフェースなどを有する汎用コンピュータである（図２３を参照してより詳細に後述）。汎用コンピュータは例えば、コンピュータに、ホストから受信したルックアップ要求を処理して最良の一致を判定させ、応答をホストに返させるプロセッサに命令をロードすることにより、ＬＵＦとその構成要素とに変換される。

図１７は、図４Ｂを参照して上述したルックアップフロントエンド（ＬＵＦ）４０８の構成要素である、例示的なＬＵＦ出力プロセッサ（ＬＯＰ）４４６のブロック図である。ＬＯＰ４４６は、ＬＩＰ（例えば、ＬＩＰ４２４、図１１）によって開始された内部チップリソース（例えば、ルックアップクラスタ４１３ａ〜ｄ、図４Ａ）からの応答を受信する。これらの応答は、処理され、インタラーケンまたはＩ２Ｃモジュールを介してホストプロセッサに返信される。応答は、ＤＤＲ、クラスタ、ＢＰＰまたは大域テーブル、およびＣＳＲなどのリソースからのホスト読取応答または書込応答を含んでもよい。また、応答は、ホストプロセッサに返信される前にＬＯＰによって最良の一致について評価されるルックアップ応答も含んでもよい。

ＬＯＰ４４６は、応答−処理フロントエンドブロック（ＬＯＰ＿ＦＥ）７５０ａ〜ｂ、応答―処理バックエンドブロック（ＬＯＰ＿ＢＥ）７６０、および出力処理ブロック（ＬＯＰ＿ＯＰ）７７０を含む。

さらに、ＬＯＰ４４６は、ＬＩＰ４２４（図１１）によって初期化された２個のテーブルおよびルックアップクラスタを維持する。これらのテーブルは、進行中の探索についてのコンテキストを保持し、クラスタによって現在実行されている探索を追跡するルックアップ応答テーブル（ＬＲＴ）７６５ａ〜ｂ、およびクラスタが完了した探索の結果をバッファする伝送バッファ（ＴＸＢＵＦＦ）７７５を含む。以下に説明するように、結果は、随意的に、要求順に格納および返送されるか、または、合体される。

一般的な動作において、ＬＯＰ＿ＦＥ７５０ａ〜ｂは、ＬＵＥのクラスタまたはバケットパケットプロセッサ（ＢＰＰＰ）から作業を受信する。応答が受信されると、当該応答はＬＲＴ７６５ａ〜ｂに配置され、随意的に、詳細については後述する動作において、同じパケットからの他のキーと合体される。１つのＬＯＰ＿ＦＥ７５０ａは、１つの対応するスーパークラスタ（例えば、図４Ａのスーパークラスタ４１０ａ）とのインタフェースを有するように構成されるか、複数のスーパークラスタとのインタフェースを有するか、または別のＬＯＰ＿ＦＥ７５０ｂと共通のスーパークラスタを共有してもよい。

ＬＯＰ＿ＢＥ７６０は、ＬＵＦ＿ＦＥ７５０ａ〜ｂとのインタフェースを有する。ＬＯＰ＿ＢＥ７６０は、応答のバッファリングおよび再順序付けを実現してもよい。応答のバッファリングおよび再順序付けは、ルックアップ順序を保存することによって行われ、また、応答を合体グループにグループ化するために行われる。ＬＯＰ＿ＢＥ７６０は、応答を集めて、探索の開始前にＬＩＰ４２４（図１１）によって確保されたＴＸＢＵＦＦ７７５スロットにそれらを配置する。応答が送信可能になると、ＬＯＰ＿ＢＥ７６０は、出力処理ブロックＬＯＰ＿ＯＰ７７０用のＴＸ＿ＬＩＳＴレジスタにＴＸＢＵＦＦ７７５のインデックスを配置する。

ＬＯＰ＿ＯＰ７７０は、ＴＸのインタラーケンコントローラに対するインタフェースを管理する。ＬＯＰ＿ＯＰ７７０は、ホスト読取／書込応答の出力待ち行列、およびＴＸ＿ＬＩＳＴに従ってＴＸＢＵＦＦからルックアップ応答を引き出す直接メモリアクセス（ＤＭＡ）エンジン７７２を含む。ＬＯＰ＿ＯＰ７７０は、内部待ち行列データを、ホストに出力するパケットにフォーマットする。

ルックアップ応答は、ＬＩＰ４２４とＬＯＰ４４６との連携動作により追跡および処理される。上述のように、応答の追跡は、ＬＩＰ４２４のディストリビュータ（例えば、４６０ａ〜ｂ、図１１）により、当該ＬＩＰのディストリビュータがＴＸＢＵＦＦにおけるフィールドを初期化したときに開始される。この動作は、ＬＩＰ４２４のスケジューラ（例えば、４２８ａ〜ｂ、図１１）により、当該ＬＩＰのスケジューラがＬＲＴおよびＬＲＴ＿ＩＮＦＯテーブルを初期化したときに継続される。ＬＯＰ＿ＦＥ７５０ａ〜ｂは、この情報を使用して、所与のＫＥＹ／ＳＸＩＤについての全てのツリーウォークの最良の応答を判定するための応答を処理する。次に、制御がＬＯＰ＿ＢＥ７６０に渡され、終了済みのＫＥＹ／ＳＸＩＤが処理される。ＬＲＴ７６５ａの合体ビットに基づき、ＬＯＰ＿ＢＥ７６０は、所与のＸＩＤについての全てのＳＸＩＤを１つの応答に合体するか、または、応答が利用可能となり次第ホストに送る。ＴＸＩＤの範囲に基づき、ＬＯＰ＿ＢＥ７６０は、この応答を再順序付けするか、または、対応する要求が受信された順序で応答を返す。

ＬＯＰの構成要素ブロックおよびそれらの動作については、図１８〜図２２Ｂを参照してさらに詳しく後述する。

図１８は、例示的なＬＵＦの応答処理フロントエンド（ＬＯＰ＿ＦＥ）７５０のブロック図である。ＬＯＰ＿ＦＥ７５０は、種々の構成要素のうち、ＬＵＦルール計算部（ＬＲＣ）７５２ａ〜ｃ、ＬＵＦルール計算部のプリプロセッサ（ＬＲＣＰ）７５３、およびＬＵＦ応答ＦＩＦＯ（ＬＲＦ）７５４を含む。これらについては、詳しく後述する。

動作中、ＬＯＰ＿ＦＥ７５０は、サブツリー応答（ＳＴＲＳＰ）バス７５６を介して返されたクラスタおよびＢＰＰからの応答を受信する。クラスタは、ルックアップ応答およびホスト読取／書込コマンドの応答の両方をＳＴＲＳＰバス７５６において返す。ＢＰＰは、ＳＴＲＳＰバスにおいてルックアップ応答のみを返す。ＢＰＰホスト読取／書込コマンドは、別のバスで返されてもよい。

ＳＴＲＳＰバス７５６がルックアップ応答を搬送する場合、ルックアップ応答のそれぞれは、以下を含む。
●ＲＳＰＴＹＰＥ−ルックアップ応答、ＯＣＭ応答、テーブルまたはＣＳＲ応答を示す。
●ＫＩＤ（キーＩＤ）
●ＤＡＴＡ−いずれのルールが一致したかを示す（ＳＣ Ｎｕｍ、ＤＤＲ／ＣＯＭアドレス、および他の情報）。
●ＳＴＭＩＮ−結果の品質であり、ＬＵＦが最小値を選択する。同点の場合、最初に返された応答が勝つ。

一般に、ＬＯＰ＿ＦＥ７５０は、クロック毎に１つの新規応答を受け付ける。ＬＯＰ＿ＦＥ７５０は、性能に影響を与えずにクラスタにバックプレッシャーを行うように構成されなくてもよい。多数のサブツリーがバック・ツー・バック（連続パケット処理）のクロックでそれらの最終応答を返す場合、ＲＥＳＰＯＮＳＥ_ＦＩＦＯ７５４はフルになる場合がある。これを防ぐため、ＲＥＳＰＯＮＳＥ_ＦＩＦＯ７５４は、プログラム可能なウォーターマークＣＳＲに基づいて、ＢＰＰおよびスーパークラスタの両方にストール信号を送ってもよい。

また、クラスタからのホスト読取／書込応答は、ＳＴＲＳＰバス７５６を越えて送信されてもよい。このような応答は、その充填レベルをスーパークラスタによって管理することが可能な別のＦＩＦＯ（図示せず）に流れてもよい。

ＬＵＦのルール計算部（ＬＲＣ）７５２ａ〜ｃは、クラスタからのサブツリー応答（ＳＴＲＳＰ）をＳＴＲＳＰバス７５６を介して受信する。ＬＲＣのうちの１つ（例えば、７５２ｃ）は、ＢＰＰからの応答だけを受信してもよい。

各サブツリー応答（ＳＴＲＳＰ）は、以下を含んでいてもよい。
●ＳＴＭＩＮ−ＬＯＰ４４６によって消費される
●ＳＴＤＡＴＡ−ＬＯＰ４４６によって以下のように調整され、その後ホストに返される。
○応答がＢＰＰからの場合、ＳＴＤＡＴＡ［３２］は、ＤＤＲポート番号を含み、ＳＴＤＡＴＡ［３１：０］は、１６ビットの粒度を有するＤＤＲアドレスを含む。
○応答がＬＣＣからの場合、ＳＴＤＡＴＡ［２３：０］は、ＯＣＭＥＭにおけるルールアドレス＝｛ＳＣＬ，ＣＬＮＵＭ，ＣＬＡＤＲ，ＲＵＬＥＯＦＦ｝を含む。この場合、ＬＲＣは、ＳＴＤＡＴＡ［３２］を常に０に設定しなければならない。ＳＴＤＡＴＡ［３１：２４］は、ＬＣＣからゼロとして返されることが期待されるが、ＬＲＣは、返された全てのビットを使用しなければならない（ゼロのＳＴＤＡＴＡ［３２］のみ）。

返された各ＳＴＭＩＮ応答について、ＬＲＣ７５２ａ〜ｃは以下を実行する。
●ＬＲＴ［ＶＡＬＩＤ］＝＝０の場合、返されたＳＴＭＩＮをＬＲＴに書き込む。ＬＲＴ［ＶＡＬＩＤ］＝＝１の場合、返されるＳＴＭＩＮをＬＲＴのＳＴＭＩＮと比較し、２つの値のうちの最小値をＬＲＴに再び書き込む。
●ＴＷＲＳＰＣＮＴをデクリメントする（ツリーウォーク応答カウント）。ＴＷＲＳＰＣＮＴがゼロになった場合、これは当該ＳＸＩＤの応答が全て受信されたことを示す。その場合、ＫＩＤを応答ＦＩＦＯ（ＬＲＦ）に書き込む。
●書き込み中のＳＴＭＩＮに関連付けられたＳＴＤＡＴＡフィールドにＬＲＴ［ＳＴＤＡＴＡ］を設定する。
●応答がＢＰＰからの場合、ＬＲＴ［ＯＣＲＦ］をクリアし、そうでない場合は、ＬＲＴ［ＯＣＲＦ］を設定する。
●応答にエラービットが設定されている場合、ＬＲＣは、これを「勝利」応答であるとみなし、当該応答と共に返されたデータを維持する。ＬＲＴ［Ｅ］が既に設定されている場合は、新規応答を無視する。

ＬＲＣ７５２ａ〜ｃのそれぞれは、同じＫＩＤについての応答を同じクロックで受信してもよい。この結果、各ＬＲＣ７５２ａ〜ｃが同じＨＰＭルールおよびＴＷＲＳＰＣＮＴを同じクロックで更新しようとした場合に問題が生じる。これを回避するため、プリプロセッシングブロック７５３は、最小値を保持してそれ以外を廃棄することにより、一致するキーのＳＴＲＳＰ応答を１つの応答に結合する。「勝利」応答は、ＬＲＣ７５２ａ〜ｃに対しては継続される一方、その他は削除される。ＬＲＣ＿ＴＷＲＳＰＣＮＴ＿ＤＥＣ［１：０］信号が生成されてＬＲＣ０に渡され、これにより、ＴＷＲＳＰＣＮＴは、典型的なケースのように１ずつだけではなく、返された応答の数だけデクリメントされる。一致しないＫＩＤの応答は、ＬＲＣ＿ＴＷＲＳＰＣＮＴ＿ＤＥＣ＝＝１によって修正されることなく通過する。

ＯＣＭＥＭのホスト読込／書込応答ならびにスーパークラスタおよびＢＰＰテーブルもまた、各自のクラスタおよびＢＰＰ応答バス７５６を介してＬＲＣＰ７５３に流れる。このような応答は、ＬＵＦ出力処理ブロック（ＬＯＰ＿ＯＰ７７０、図２０）にリダイレクトされ、送信のためにバッファされる。これらは、ＬＲＣ７５２ａ〜ｃに流れない場合もある。

また、ＬＲＣＰ７５３は、ルックアップクラスタコンプレックス（ＬＣＣ）がデータを送ることを可能にする要求／承認機能を実現できる。

６４個のエントリを有するＬＵＦ ＲＥＳＰＯＮＳＥ_ＦＩＦＯ（ＬＲＦ）７５４は、そのキーの応答を全て受信した（ＳＴＲＳＰ（サブツリー応答）が決定されたことを意味する）キー／ＳＸＩＤについてのＫＩＤを保持する。このように、キー要求がＬＩＰ４２４によって複数のサブツリー要求に分割された場合（図１１を参照して上述）、対応する結果は、ＬＲＦ７５４において１つの応答にマージされる。ＬＯＰ＿ＯＰ７７０（図１７、図２０）は、ＬＲＴ７６５ａ〜ｂからＴＸＢＵＦＦ７７５に転送可能なエントリを判定するためにＬＲＦ７５４を読み取る。

ＬＲＦ７５４には、ＬＲＣ７５２ａ〜ｃの出力に接続されたバスとＢＰＰバスとによって提供がなされる。例示的な実施形態においては、各クロックサイクル中に、クロック毎に最大３個のＫＩＤをＬＲＦ（ＦＩＦＯ）に書き込んでもよい。クロック毎に１つのエントリがＬＲＦから読み取られる。一般に、読み取りは、書き込みよりも素早く行われる。１つのＫＩＤ書き込みについて複数のＳＴＲＳＰが必要であるためである。

連続クロックサイクルにおいてバック・ツー・バックで終了する個々のキーが整列するため、ＬＲＦ（ＦＩＦＯ）７５４は、場合によっては、フルになり（空きがなくなり）始めることがある。プログラム可能なウォーターマーク（閾値）が、ＬＲＦ７５４が間もなくフルになろうとしている時点を判定できる。ウォーターマークは、ＬＲＣＰ７５３（ＬＵＦルール計算部プリプロセッサ）がＳＴＲＳＰバス７５６で応答を受け付けることを停止させてもよい。

図１９は、例示的な実施形態における例示的なルックアップ応答処理バックエンド（ＬＯＰ＿ＢＥ）のブロック図である。ＬＯＰ＿ＢＥ７６０は、ＬＯＰ＿ＦＥ７５０において応答ＦＩＦＯ７５４（図１８）から作業を引き出す。ＬＯＰ＿ＢＥ７６０は、アクセスされているＴＸＩＤの順序グループによって決定される順番応答（順番通りの応答）および順番外応答（順番に従わない応答）の両方で作業を行う。グループ０の範囲のＴＸＩＤは、順番通りではない。他の全てのＴＸＩＤは、順番通りであってもよい。ＬＯＰ＿ＢＥ７６０は、以下の順番応答および順番外応答に適応する２つのモードのうちの一方で動作する。
●順番応答（ポーリングモード）：１つのポインタがＬＲＴの最も古い要求（ＴＸＩＤをその順序グループ範囲内で循環的にウォークすることにより決定される）に対応するＴＸＢＵＦＦエントリを追跡する。そのＸＩＤについての最後のＳＴＲＳＰが受信されると、全てのＳＸＩＤは、ホストへの送信のためにエンキューされ、ＬＲＴから除去される。このポインタは、その後、２番目に古いＴＸＩＤを指すようにインクリメントされる。これにより、次の順番応答が返されるまでＨＯＬブロッキングが生じる。
●順番外応答（割込モード）：ＸＩＤについての最後のＳＴＲＳＰが返されることにより、全てのＳＸＩＤがホストへの送信のためにエンキューされ、ＬＲＴから除去される。

加えて、ＬＯＰ＿ＢＥ７６０は、複数のルックアップ応答（ＬＵＲＳＰ）を１つのパケットに合体するか、またはそれらを個別に送ることができる。全ての順番応答を合体してもよい。順番外（ＯＯＯ）応答は、合体されるか、または、入手するとすぐにホストに返されてもよい。上記動作の詳細について、以下に説明する。

順番処理および順番外処理の両方の最初のステップとして、ＬＯＰ＿ＢＥ７６０は、非空（空きのない状態）になりつつある応答ＦＩＦＯに応答して割込モードで作業を行う。順番外応答を完全に処理するとともに、順番応答を処理する最初のステップを行う。順番応答の最後の処理は、以下に説明する順番マシンが行う。

順序付けおよび合体の全ての場合において、１つのエントリがＦＩＦＯ読取ブロック７６７によって応答ＦＩＦＯ７５４から読み取られると、ＬＯＰ７６０は、以下を行う。
●ルックアップ応答テーブル（ＬＲＴ）７６５、次に、ＬＲＴ＿ＩＮＦＯ７６６を読み取る。
●ＬＲＴ７６５およびＬＲＴ＿ＩＮＦＯ７６６が読み取られる際に、応答は、以下の利用可能な情報を有する。
○ＫＩＤ
○ＴＸＩＤ＿ＦＩＲＳＴ
○ＴＸＩＤ＿ＬＡＳＴ
○ＳＸＩＤ−いずれのＳＸＩＤがこのＳＸＩＤであるか
○ＳＸＩＤ＿ＮＵＭ−この要求にいくつのＳＸＩＤが存在するか
○ＤＯＮＥ＿ＣＮＴ−合体するＳＸＩＤはいくつ残っているか
●ＬＲＴデータをＴＸＢＵＦＦ７７５に移動
○ＳＸＩＤ０またはＳＸＩＤ１データをＬＲＴからＴＸＢＵＦＦに移動する際、ＴＸＢＵＦＦへのＴＸＩＤインデックスとしてＴＸＩＤ＿ＦＩＲＳＴが使用される。
○ＳＸＩＤ２またはＳＸＩＤ３を移動する際、ＴＸＩＤインデックスとしてＴＸＩＤ＿ＬＡＳＴが使用される。
○ＳＸＩＤ０またはＳＸＩＤ２データをＳＴＤＡＴＡ＿ＥＶＥＮに移動させる。
○ＳＸＩＤ１またはＳＸＩＤ３データをＳＴＤＡＴＡ＿ＯＤＤに移動させる。
●ＫＩＤを、ＳＸＩＤ０でない場合は、フリープールに返す。以下のテーブルによって示されるまで、ＳＸＩＤ０のためにＫＩＤを保持する。
●ＬＯＰは、表１に示す以下の追加の動作を行う。

順番マシン７６８ａ〜ｂは、応答が最終処理順ではなく、要求順で返されるように応答を再順序付けすることを提供する。順番マシン７６８ａ〜ｂは、ＩＮ＿ＯＲＤＥＲ＿ＭＩＮ＿ＮからＩＮ＿ＯＲＤＥＲ＿ＭＡＸ ＣＳＲの値によって規定される１つの領域における第１の無効ＴＸＢＵＦＦ位置にて待機する。ＬＯＰ＿ＦＥが当該位置についての有効フラグを設定して、全ての必要な情報がＬＲＴ７６５からＴＸＢＵＦＦ７７５に移動したことを示す。そして、順番マシン７６８ａ〜ｂは、ＴＸＢＵＦＦ７７５のこのラインを処理し、次に、処理の繰り返しを待つＴＸＢＵＦＦ７７５の次の位置にインクリメントする。ＴＸＢＵＦＦ７７５のエントリは、受信パケットが到着する際に、連続的に増加する順序で割り当てられているため、順番マシン７６８ａ〜ｂは、ＴＸＢＵＦＦ７７５に到着した順に関係なく、リストから順にエントリを引き出す。１つの合体されたパケットに必要な全てのＴＸＩＤを処理することを決定した場合、順番マシン７６８ａ〜ｂは、これらのＴＸＩＤをＴＸＬＩＳＴ７６９に書き込む。

順番マシン７６８ａ〜ｂは、一度に最大２つのＴＸＢＵＦＦラインをＴＸＬＩＳＴ７６９に配置してもよい。下流の出力プロセッサは、これらのラインをＦＩＦＯからバック・ツー・バックで読み取ってもよい。このモードでは、キーが３つまたは４つの場合、マシン７６８ａ〜ｂは、ＴＸＩＤ＿ＦＩＲＳＴをＴＸＩＤ＿ＦＩＲＳＴ＿ＲＥＧＩＳＴＥＲに格納し、ＴＸＩＤ＿ＦＩＲＳＴおよびＴＸＩＤ＿ＬＡＳＴを１つのサイクル中にＴＸＬＩＳＴ７６９に書き込まなければならない。順番外マシンと同様、いずれのＳＸＩＤで作業を行っているかを追跡するためにＳＸＩＤ＿ＣＯＵＮＴＥＲを保持する。順番マシン７６８ａ〜ｂの動作については、表２に詳細に示す。

ＴＸＬＩＳＴ７６９は、ＴＸＩＤのＦＩＦＯである。ＴＸＬＩＳＴ７６９は、ＬＯＰによって書き込みされ、ＴＸ待ち行列ＤＭＡエンジン（図２０を参照して後述）によって使用されて、ホストへの返信のためにいずれのＴＸＢＵＦＦをインタラーケンＳＨＩＭに転送するかが決定される。順番処理の場合、リスト上のＴＸＩＤの順序が、一般に、ホストへの送信順序を決定する。

ＴＸＬＩＳＴ７６９は、１クロックにつき１つまたは２つのエントリを受け付けてもよい。各エントリは、ＴＸＢＵＦＦ７７５におけるラインを表し、ＴＸＢＵＦＦ７７５は、１つまたは２つのＨＰＲＵＬＥエントリ（１つまたは２つのＳＸＩＤを表す）を保持する。このため、ＴＸＬＩＳＴ７６９に書き込まれた各ラインは、所与のＸＩＤの応答の全てを表すことができる。

ＴＸＬＩＳＴ７６９は、ＤＭＡエンジン（図２０）によって一度に１つのエントリずつ読み取られる。ＴＸＩＤがこのリストに配置される順序が、一般に、送信順序を決定し得る。例示的な実施形態において、ＴＸＬＩＳＴ７６９は、以下の情報を含む。これらは、対応するエントリに１つまたは複数のビットとして格納することができる。

Ｃ−合体
●Ｃ＝＝１の場合、最大４つのキーを用いて応答をキー応答に形成する。
●Ｃ＝＝０の場合、１つのキーを用いてルックアップ応答を返す。
ＳＸＩＤ＿ＩＮＦＯ−定義は合体に依存する。
●Ｃ＝＝１の場合、ＳＸＩＤ＿ＩＮＦＯは合体するキーの数である。ＳＸＩＤ＿ＩＮＦＯ＝＝０の場合、４つのキーを合体する。
●Ｃ＝＝０の場合、ＳＸＩＤ＿ＩＮＦＯは、このキーのＳＸＩＤである。ＳＸＩＤ＿ＩＮＦＯ＝＝０の場合、これは、ＳＸＩＤ０である。
ＦＲＥＥ＿ＴＸＩＤ−パケット形成後に、有効データを有するＴＸＩＤを開放してもよいことを示す。
開放されるＴＸＩＤは、以下のように決定される。
●Ｃ＝＝０の場合、
○ＳＸＩＤ＿ＩＮＦＯが、これがＳＸＩＤ０またはＳＸＩＤ１であることを示す場合、ＴＸＩＤ＿ＦＩＲＳＴを開放する。
○ＳＸＩＤ＿ＩＮＦＯが、これがＳＸＩＤ２またはＳＸＩＤ３であることを示す場合、ＴＸＩＤ＿ＬＡＳＴを開放する。
●Ｃ＝＝１の場合
○ＳＸＩＤ＿ＩＮＦＯがライン上の１つまたは２つの有効なＳＸＩＤを示す場合、ＴＸＩＤ＿ＦＩＲＳＴのみを開放する。
○ＳＸＩＤ＿ＩＮＦＯがライン上の３つまたは４つの有効なＳＸＩＤを示す場合、ＴＸＩＤ＿ＦＩＲＳＴおよびＴＸＩＤ＿ＬＡＳＴの両方を開放する。
ＴＸＩＤ＿ＦＩＲＳＴ−ＳＸＩＤ０およびＳＸＩＤ１を保持するＴＸＩＤ。
ＴＸＩＤ＿ＬＡＳＴ−ＳＸＩＤ２およびＳＸＩＤ３を保持するＴＸＩＤ。
●Ｃ＝＝０の場合、ＳＸＩＤ＿ＩＮＦＯが示すＳＸＩＤの値に応じて、ＴＸＩＤ＿ＦＩＲＳＴまたはＴＸＩＤ＿ＬＡＳＴのうちの一方のみが有効データを有する。
●Ｃ＝＝１の場合、ＳＸＩＤ＿ＩＮＦＯが示すＳＸＩＤのカウントに応じて、有効データは、ＴＸＩＤ＿ＦＩＲＳＴのみに存在するか、またはＴＸＩＤ＿ＦＩＲＳＴおよびＴＸＩＤ＿ＬＡＳＴに存在する。

図２０は、例示的な実施形態における例示的なＬＯＰ出力プロセッサ（ＬＯＰ＿ＯＰ）７７０のブロック図である。ＴＸＱ ＤＭＡエンジン７７２は、ＴＸ＿ＬＩＳＴ ＦＩＦＯからＴＸＩＤを引き出す。次に、ＴＸＢＵＦＦ７７５の対応する位置が、インタラーケンを介した送信のためにＴＸ ＦＩＦＯ７７８に配置される前に、読み取られて応答パケットに形成される。

ＬＯＰ＿ＯＰ７７０は、２つの異なるモード、すなわち合体モードおよび非合体モードで動作してもよい。合体モードは、ＴＸＬＩＳＴ７６９ ＦＩＦＯ（上述）におけるＣビットによって決定される。パケットが合体される場合、ＬＯＰ＿ＯＰ７７０は、ＳＸＩＤ＿ＩＮＦＯを用いて、上記最大４つのキーに必要な全てのＴＸＩＤを指すポインタを取得するためにＴＸＬＩＳＴ７６９の１つまたは２つのラインを読み出す必要があるか否かを判定する。次に、これら４つのキーは、１つのパケットに結合（合体）される。パケットが合体されない場合、ＴＸＬＩＳＴ７６９は、１つのラインにつき１つのＳＸＩＤを有する。パケットが合体されない場合、ＳＸＩＤ＿ＩＮＦＯは、ＳＸＩＤを指定し、適切なＴＸＩＤは以下のように配置される。
●ＳＸＩＤ０−ＴＸＩＤ＿ＦＩＲＳＴのみを使用してＴＸＢＵＦＦを索引付けする、ＤＡＴＡ＿ＥＶＥＮフィールドが有効である
●ＳＸＩＤ１−ＴＸＩＤ＿ＦＩＲＳＴのみを使用してＴＸＢＵＦＦを索引付けする、ＤＡＴＡ＿ＯＤＤフィールドが有効である
●ＳＸＩＤ２−ＴＸＩＤ＿ＬＡＳＴのみを使用してＴＸＢＵＦＦを索引付けする、ＤＡＴＡ＿ＥＶＥＮフィールドが有効である
●ＳＸＩＤ３−ＴＸＩＤ＿ＬＡＳＴのみを使用してＴＸＢＵＦＦを索引付けする、ＤＡＴＡ＿ＯＤＤフィールドが有効である

ＬＯＰ＿ＯＰは、順番通りモードと順番外（順番通りでない）（ＯＯＯ）モードとを区別しない。なぜなら、ＴＸＬＩＳＴのエントリは、必要とされる場合は、既に順番通りで配置されていると考えられるからである。ＬＯＰ＿ＢＥ７６０は、パケットが順番通りである場合、Ｃに設定されてもよい。

パケットフォーマッタ７７９は、インタラーケンを介してホストに返信されるパケットをフォーマットする。ルックアップ応答は、１つのＳＸＩＤまたは複数の合体ＳＸＩＤであってもよい。ＯＳＩ インタラーケンコアに対するインタフェースは、１２８ビットであってもよい。したがって、各サイクルは、２つのインタラーケンワードを搬送する。フォーマッタ７７９は、複数のＳＸＩＤ応答をインタラーケンコアのための１２８ビットのパケットにパックする。

図２１は、本発明の実施形態を実現するための例示的なデータ構造のブロック図である。具体的には、ＬＲＴ７６５、ＬＲＴ＿ＩＮＦＯ７６６、およびＴＸＢＵＦＦ７７５のテーブルのエントリをＲＡＭまたはフロップのアレイなどのメモリにおいて編成できるものとして示す。テーブルのそれぞれにおいて、ビットを、必要とされる同時アクセスの数によって編成してもよい。例えば、ＬＲＴ７６５のＴＷＲＳＰＣＮＴのビットは、クロック毎に読み取りおよび書き込みアクセスを行い、１つのクロックにつき最大３つの応答を処理してもよく、同時に、スケジュールされている新規キーのための書き込みを処理してもよい。便宜的な実施形態において、ＴＷＲＥＳＰＣＮＴおよび類似した複数のアクセスフィールドは、フロップのアレイに編成してもよい。

ＬＲＴ７６５およびＬＲＴ＿ＩＮＦＯ７６６のテーブルは、ルックアップ要求がクラスタに送られる際に、ＬＩＰ４２４（図１１）のスケジューラ４２８ａ〜ｂによって初期化される。ＬＲＴ７６５およびＬＲＴ＿ＩＮＦＯ７６６のテーブルは、ＬＵＦの応答プロセッサＬＲＣ７５２ａ〜ｃによって使用され、各キーの最小の最優先ルール（ＨＰルール）を決定し、キーの全ての応答が返されたことを判定する。各ＬＲＴ７６５エントリは、進行中の１つのキー探索（１つのＳＸＩＤ）に対応する。ＬＲＴ７６５は、ＫＩＤによって索引付け／参照され、ＫＩＤは、ＫＩＤフリープール（後述）から配布される。スケジューリングの後、ＬＲＴ７６５のフィールドがＬＵＦ出力プロセッサフロントエンド（ＬＯＰ＿ＦＥ）７６５ａ〜ｂによって更新される。

便宜的な実施形態によると、ＬＲＴ７６５は、以下のように編成されてもよい（図２１を参照）。
●Ｅ（エラー）、なし、修正可能エラー、修正不可能エラーまたは致命的エラー。スケジューラよってクリアまたは設定され、ＬＯＰ＿ＦＥによって更新される。
●ＴＷＲＳＰＣＮＴ（ツリーウォーク応答カウント）ＬＯＰ＿ＦＥは、応答が受信されるたびにデクリメントされる。ＴＬＴから読み取った数にスケジューラにより初期化される。ゼロの場合、このＳＸＩＤの全ての応答は返されている。
●ＶＡＬＩＤ−スケジューラによってクリアされ、ＬＯＰ＿ＦＥは、これを読み取り、更新する応答データフィールドのバンクに対して常に１を設定する。ＬＯＰ＿ＦＥがゼロを読み取った場合、ＬＯＰ＿ＦＥは、対応するバンクについてのＬＲＴからの応答データフィールドがまだ有効ではないことを認識する。
○Ｖａｌｉｄ＝３’ｂ１ｘｘ−ＲＳＰ０バンクは有効である
○Ｖａｌｉｄ＝３’ｂｘ１ｘ−ＲＳＰ１バンクは有効である
○Ｖａｌｉｄ＝３’ｂｘｘ１＝ＢＰＰバンクは有効である
●応答データフィールド−フロップのアレイ、または、有効に管理されたデュアルポートの３つのバンクによって実現される
○ＳＴＭＩＮ（最小ルール）、有効＝＝１の場合、ＬＯＰ＿ＦＥは、ＬＣＣから返された値をＬＲＴから読み取られた値と比較し、２つのうちの最小の値を保持する。
○ＰＯＲＴ−ＢＰＰからの場合、これはＢＰＰ応答から返されたＳＴＤＡＴＡ［３２］である。ＬＣＣからの場合、これはゼロである。
○ＯＣＲＦ（オンチップルールフラグ）。応答がＢＰＰからの場合、ＬＯＰ＿ＦＥは、これを０に設定する。応答ＬＣＣからの場合、ＬＯＰ＿ＦＥは、これを１に設定する。
○ＳＴＤＡＴＡ−応答としてホストに返されるデータ。ＬＣＣが「ＮＯ ＭＡＴＣＨ」を示すＳＴＭＩＮを返した場合、ＬＯＰ＿ＦＥは、これを強制的に０ｘＦＦＦＦＦＦＦＦにする。そうでない場合、ＬＯＰ＿ＦＥは、最小ＳＴＭＩＮに対応するＳＴＤＡＴＡ値を使用する。
●ＬＲＴＩＤ−ＬＲＴ＿ＩＮＦＯテーブルに索引付けされる。ＬＲＴ＿ＩＮＦＯは、グループ全体についての情報を保持するので、各ＫＩＤエントリによって指し示される。
●ＳＸＩＤ−このキーのサブ転送ＩＤ。０＝ＳＸＩＤ０、１＝ＳＸＩＤ１、２＝ＳＸＩＤ２、３＝ＳＸＩＤ３。
●Ｃ−この応答を合体する。この情報は、ＧＤＴから読み取られる。
●ＴＩＤ−この転送のツリーＩＤ。このＳＸＩＤの全ての応答が返されたときに、対応するＴＩＤカウンタをデクリメントする（ＴＷＲＳＰＣＮＴ＝＝０）。

各ＬＲＴ＿ＩＮＦＯ７６６エントリは、同じルックアップ要求についての全てのキーに対応する（上述の通り、１つのルックアップ要求は、それぞれが複数のＳＸＩＤを有するキーを最大４つ生成できる）。ＬＲＴ＿ＩＮＦＯ７６６のテーブルは、キーのグループを合体するために必要な情報を含む。ＬＲＴ＿ＩＮＦＯ７６６のテーブルは、ＬＲＴＩＤフリープール（後述）から配布されるＬＲＴＩＤによって索引付け／参照される。一実施形態において、ＬＲＴ＿ＩＮＦＯは、ＬＲＴと同じ深さを有する。

便宜的な実施形態によると、ＬＲＴ＿ＩＮＦＯ７６６は、以下のように編成されてもよい（図２１を参照）。
●ＤＯＮＥ＿ＣＯＵＮＴ−まだ合体する必要があるこのグループのキーの数のカウンタ。これは、スケジューラによって設定され、ＳＸＩＤが全ての応答を受信するたびにデクリメントされる（すなわち、ＴＷＲＳＰＣＮＴがゼロになる）。
●ＴＸＩＤ＿ＦＩＲＳＴ−ＳＸＩＤ０およびＳＸＩＤ１に対応するＴＸＩＤを指すポインタ。（順番外モード（ＯＯＯ）の際に合体を行う場合に、１つのクロックでＴＸ ＬＩＳＴの両方のＴＸＩＤを転送するために使用される。）。
●ＴＸＩＤ＿ＬＡＳＴ−ＳＸＩＤ２およびＳＸＩＤ３に対応するＴＸＩＤを指すポインタ。（順番外モード（ＯＯＯ）の際に合体を行う場合に、１つのクロックでＴＸ ＬＩＳＴの両方のＴＸＩＤを転送するために使用される）。
●ＮＵＭ＿ＯＦ＿ＳＸＩＤＳ−この要求のＳＸＩＤの合計数。２’ｂ００は、４つのＳＸＩＤを示す。

ＴＸＢＵＦＦ７７５のテーブルは、要求がホストから到着した際にＬＩＰのディストリビュータ４６０ａ〜ｂ（図１１）によって初期化される。ＴＸＢＵＦＦ７７５のテーブルは、ＬＯＰ出力プロセッサ（ＬＯＰ＿ＯＰ）７７０（図２０）によって使用され、要求が受信された順と同じ順番で応答がホストに送り返されるように、必要に応じて応答は再順序付けされる。また、ＴＸＢＵＦＦ７７５のテーブルは、ルックアップ応答がクラスタによって返される速さが、ホストインタフェースがそれらを排出しうる速さを超えた場合に、時間のバッファリングを可能にする。ＴＸＢＵＦＦ７７５のテーブルは、ＴＸＩＤフリープール（より詳細には後述）から配布されるＴＸＩＤによって索引付け／参照される。

ＧＤＴテーブル４２６（図１１）のＯＲＤＥＲ＿ＧＲＯＵＰフィールドは、応答が要求順で返されるか、あるいは応答が順番通りではなく返されるか（応答が返送可能になり次第返されることを意味する）を定義する。

便宜的な実施形態によると、ＴＸＢＵＦＦ７７５は、以下のように編成されてもよい（図２１Ｂを参照）。
●Ｅ（エラー）、なし、修正可能エラー、修正不可能エラーまたは致命的エラー。
●ＤＡＴＡ ＯＤＤ−ＳＸＩＤ１またはＳＸＩＤ３の最小ルール
○ＯＣＲＦ（オンチップルールフラグ）ＬＣＣからの結果の場合に設定し、ＢＰＰについてはクリアされる
○ＰＯＲＴ−ＢＰＰからの結果の場合はＤＤＲポート、ＬＣＣの場合はクリアされる
○ＳＴＤＡＴＡ−ＢＰＰの場合はＤＤＲのアドレス、ＬＣＣの場合はクラスタのアドレス
●ＤＡＴＡ ＥＶＥＮ−ＳＸＩＤ０またはＳＸＩＤ２の最小ルール
○上記ＤＡＴＡ＿ＯＤＤと同じサブフィールド定義。
●ＸＩＤ−転送ＩＤ
●ＶＡＬＩＤ＿ＥＶＥＮ，ｖａｌｉｄ＿ｏｄｄ−対応するＤＡＴＡエントリが有効である場合、１に設定される−順番エンジンによってのみ使用される
●Ｃ−この応答を合体する。この情報は、ＧＤＴから読み取られる。
●ＬＡＳＴ−このＴＸＢＵＦＦラインがグループの最後のＳＸＩＤを含むことを示す 。
●Ｎｅｅｄ ｂｏｔｈ−０は、偶数データ／有効のみが必要であることを示す。１は、偶数および奇数の両方が必要であることを示す。

ＫＩＤフリープールは、スケジューラにＫＩＤを配布する。各ＫＩＤは、ルックアップ応答テーブル（ＬＲＴ）７６５の１つのラインを表す。ＫＩＤは、任意の順でスケジューラに配布される。ＫＩＤは、ＬＲＴ７６５データがＴＸＢＵＦＦ７７５に移動するとすぐに、ＬＵＲＳＰエンジンによって一度に１つずつ任意の順でフリープールに返される。ＫＩＤフリープールは、ＦＩＦＯとして実現してもよく、各位置を自身のアドレスに設定することによって初期化してもよい。例示的な実施形態において、１つのスーパークラスタにつき１つのＫＩＤフリープールが存在してもよい。

ＬＲＴＩＤフリープールは、ＬＲＴＩＤをスケジューラに配布する。各ＬＲＴＩＤは、ルックアップ応答情報テーブル（ＬＲＴ＿ＩＮＦＯ）７６６の１つのラインを表す。ＬＲＴＩＤは、任意の順でスケジューラに配布される。ＬＲＴＩＤは、キーが合体し終わると、ＬＵＲＳＰエンジンによって一度に１つずつ任意の順でフリープールに返される。ＬＲＴＩＤフリープールは、ＦＩＦＯとして実現してもよく、各位置を自身のアドレスに設定することによって初期化してもよい。例示的な実施形態において、１つのスーパークラスタにつき１つのＬＲＴＩＤフリープールが存在してもよい。

ＴＸＩＤフリープールは、スケジューラ４２８ａ〜ｂ（図１１）にＴＸＩＤを配布する。各ＴＸＩＤは、ＴＸＢＵＦＦ７７５のアレイの１つのラインを表す。ＴＸＩＤフリープールは、メモリなしのＦＩＦＯで構成され、フルに初期化されてもよい。ＴＸＩＤフリープールは、順番通りの動作のために用いてもよく、その場合エントリが昇順で配布され、同じ順で返される。したがって、ＴＸＢＵＦＦ７７５を索引付けするために増加するＴＸＩＤを使用する場合、エントリは、順番通りに引き出される。

返されたＴＸＩＤは、最後尾のポインタと比較されてもよい。エラー出力（ＦＩＦＯエラー）は、これらの値が常に、ＴＸＢＵＦＦにおける何らかのエラーを示すミスマッチとなり、最後尾ポインタがインクリメントされない場合に設定することができる。先頭ポインタが最後尾ポインタに到達すると、動作が最終的にストールする場合がある。ＦＩＦＯがフルのときにプッシュしようとした場合は、別のエラー出力（オーバーフローエラー）が設定され、これもまた、ＴＸＢＵＦＦ７７５におけるエラーを示す。ポップ出力インタフェース上のＴＸＩＤ出力は、そのサイクルにおけるｅｍｐｔｙ信号（空き信号）が低（ロー）の場合にのみ有効としてもよい。

順番通りのフリープールの最小値および最大値は、６４の位置粒度でＣＳＲを介してホストによりプログラム可能である。このＣＳＲは、最大値のビット［１１：６］を設定する。最小値のビット［１１：６］は、前のグループの最大値に１を加算することによって決定される。最大値のビット［５：０］は全て１に設定され、最小値のビット［５：０］は全てゼロに設定される。これらの値の変更後、変更を有効にするには、ｔｘｉｄ＿ｒｅｓｅｔ＿ｐｏｉｎｔｅｒｓ ＣＳＲが１から０に遷移しなければならない。例示的な実施形態において、２つのイン・オーダーフリープールがそれぞれの順序グループ１および２について実現されてもよい。

順番通りではないＴＸＩＤフリープールは、スケジューラにＴＸＩＤを配布する。この配布は、順序グループ０に対応する。各ＴＸＩＤは、ＴＸＢＵＦＦ７７５のアレイの１つのラインを表してもよい。このアレイは、ＦＩＦＯであってもよく、各エントリが自身のアドレスを含むように初期化されてもよい。

順番通りの動作の際、エントリは、昇順で配布され、同じ順で返される。したがって、ＴＸＢＵＦＦ７７５を索引付けするために増加するＴＸＩＤが使用されると、当該エントリは、順番に引き出される。これに対し、順番通りではない（ＯＯＯ）動作の際、エントリは任意の順で返される。このため、リストは、順番通りではなくなる場合がある。このような動作において順序は無視されるため、順序の欠如が不利になることはない。例示的な実施形態において、順序グループ０に１つの順番外プールを実現してもよい。アウト・オブ・オーダーフリープールからのＴＸＩＤの最大値は、ＣＳＲを介して、６４の位置粒度でホストによりプログラム可能である。これらの値の変更後、変更を有効にするために、ｔｘｉｄ＿ｒｅｓｅｔ＿ｐｏｉｎｔｅｒｓ ＣＳＲは、１から０に遷移されてもよい。

図２２Ａは、１つのＳＸＩＤに属する複数のサブツリー応答から最優先応答を選択する例示的な手順のフローチャートである。この処理を「マージング」と呼ぶ。 図２２Ｂは、例示的な実施形態による、内部リソースから受信された応答の順序付けおよび合体を行うための例示的な手順のフローチャートである。この手順は、図１７〜図２１を参照して上述の各処理から導き出されたものである。この手順は、ＬＯＰ（例えば、図１７のＬＯＰ４４６）によって実行されてもよい。また、この手順は、以下に説明する例示的な手順を表す命令をロードし実行することによってＬＯＰに変形されたコンピュータ（またはプロセッサ）によって実行されてもよい。

本発明の実施形態によると、ＬＵＦ出力プロセッサ（ＬＯＰ）は、他のノードのネットワークにおける、スイッチまたはルータなどの物理ネットワークノード（すなわち装置）であってもよい。ＬＯＰは、当該ノードの構成要素、モジュール、ブレードまたはカードとしての物理ネットワークノード（すなわち装置）の一部であってもよい。

本発明の別の実施形態によると、ＬＯＰは、プロセッサ、メモリ、通信インタフェースなどを有する汎用コンピュータである。（図２３を参照してより詳細に後述）。汎用コンピュータは、例えば、コンピュータにホストから受信したルックアップ要求を処理して最良の一致を判定させ、応答をホストに返させる命令をプロセッサにロードすることにより、ＬＯＰとその構成要素とに変換される。

図２３は、本発明の様々な実施形態を実現できるコンピュータ５００の内部構造のブロック図である。コンピュータ５００は、バスがコンピュータまたは処理システムの構成要素間のデータ転送に使用されるハードウェアラインのセットであるシステムバス５７９を含む。バス５７９は、本質的には、コンピュータシステムの異なる要素（例えば、プロセッサ、ディスク記憶、メモリ、入出力ポート、ネットワークポートなど）を接続し、これらの要素間での情報の転送を可能にする共有コンジットである。システムバス５７９には、様々な入出力装置（例えば、キーボード、マウス、ディスプレイ、プリンタ、スピーカなど）をコンピュータ５００に接続するためのＩ／Ｏデバイスインタフェース５８２が取り付けられている。ネットワークインタフェース５８６により、コンピュータ５００は、ネットワークに取付けられた様々な他の装置に接続することができる。メモリ５９０は、本発明の実施形態（例えば、図８の手順）を実現するために使用されるコンピュータソフトウェア命令５９２およびデータ５９４のための揮発性記憶装置を提供する。ディスク記憶５９５は、本発明の実施形態を実現するために使用されるコンピュータソフトウェア命令５９２およびデータ５９４のための不揮発性記憶装置を提供する。また、中央処理装置５８４もシステムバス５７９に取り付けられており、コンピュータ命令の実行を行う。

一実施形態において、プロセッサのルーチン５９２およびデータ５９４は、本発明のシステムのためのソフトウェア命令の少なくとも一部を提供する、コンピュータ可読媒体（例えば、１つまたは複数のＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ、ディスケット、テープなどの取り外し可能な記憶媒体）を含むコンピュータプログラム製品（総じて５９２で示す）である。コンピュータプログラム製品５９２は、当該技術分野で周知である任意の適切なソフトウェアインストール手順によってインストールできる。別の実施形態において、ソフトウェア命令の少なくとも一部を、ケーブル、通信および／または無線接続を介してダウンロードしてもよい。

さらに、本発明の実施形態は、各種コンピュータアーキテクチャにおいて実現することができる。図２３の汎用コンピュータは、本発明の実施形態を説明するためのものであって、限定するものではない。

本発明をその例示的な実施形態を参照しながら詳細に説明したが、本発明は、添付の請求の範囲により包含される本発明の範囲から逸脱することなく、形態および細部において種々の変更が可能であることが当業者には理解される。

実施形態は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせによって実現してもよい。また、実施形態は、非一時的な機械可読媒体に格納された命令として実現してもよく、これらの命令は、１つまたは複数の手順によって読み取られ、実行されてもよい。非一時的な機械可読媒体は、機械（例えば、計算装置）によって読み取り可能な形式で情報を格納および送信するための任意の機構を含んでもよい。例えば、非一時的な機械可読媒体は、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリ装置等を含んでいてもよい。さらに、本明細書において、ファームウェア、ソフトウェア、ルーチン、または命令は、ある特定の動作を実行するものとして説明されている場合がある。しかし、かかる説明は便宜上のものに過ぎず、また、かかる動作は、実際には上記ファームウェア、ソフトウェア、ルーチン、命令等を実行する計算装置、プロセッサ、コントローラ、または他の装置による結果であることが理解される。

なお、ブロック図およびフローチャート（例えば、図６）は、より多いまたはより少ない要素を含んでいたり、配置が異なっていたり、表現が異なる場合がある。本発明の実施形態の実行を説明するブロック図およびフローチャートならびにブロック図およびフローチャートの数は、実装において規定されることが理解される。

Claims (29)

1. パケットを処理する方法であって、
   パケットに対するルールマッチングを行う処理クラスタから複数の応答を受信するステップであって、前記複数の応答が、前記パケットに関連するルックアップ要求に応じたものである、ステップと、
   前記複数の応答が合体されるべきか否かを、前記パケットの合体ビットに基づいて判定するステップと、
   ルックアップ結果をホストプロセッサに出力するステップであって、前記ルックアップ結果が、前記複数の応答が合体されるべきか否かに基づいて選ばれた前記複数の応答を含む、ステップとを備えた、パケット処理方法。
2. 請求項１に記載のパケット処理方法において、さらに、
   前記複数の応答に基づいてルックアップ応答テーブルを更新するステップであって、前記ルックアップ応答テーブルが、複数の処理クラスタにおける処理中のルックアップ要求を示す、ステップを備えた、パケット処理方法。
3. 請求項２に記載のパケット処理方法において、前記合体ビットが前記ルックアップ応答テーブルに格納される、パケット処理方法。
4. 請求項１に記載のパケット処理方法において、さらに、
   前記複数の応答を伝送バッファに転送するステップを備えた、パケット処理方法。
5. 請求項４に記載のパケット処理方法において、さらに、
   前記複数の応答の受信よりも前に前記複数の応答を配置するための前記伝送バッファのスロットを設定するステップを備えた、パケット処理方法。
6. 請求項５に記載のパケット処理方法において、前記選ばれた複数の応答が、前記スロットに配置される、パケット処理方法。
7. 請求項５に記載のパケット処理方法において、前記スロットが、他のスロットに対して所定の順序を有し、前記ルックアップ結果が前記所定の順序で出力されるように設定されている、パケット処理方法。
8. 請求項４に記載のパケット処理方法において、さらに、
   複数のグループを設定するステップであって、各グループが、前記複数の応答の受信よりも前に前記複数の応答を配置するための前記伝送バッファの複数のスロットを有する、ステップを備えた、パケット処理方法。
9. 請求項８に記載のパケット処理方法において、前記複数のグループのうちの第１のグループにおける応答が、前記第１のグループにおける他の応答に対して所定の順序で出力される、パケット処理方法。
10. 請求項９に記載のパケット処理方法において、前記複数のグループのうちの第２のグループにおける応答が、前記第２のグループにおける他の応答に対する順序に関係なく出力される、パケット処理方法。
11. 請求項１０に記載のパケット処理方法において、さらに、
    前記複数のスロットのルックアップ結果に関連するパケットのデータに基づいて、前記第１および第２のグループのいずれか一方に、前記複数の応答を配置するステップを備えた、パケット処理方法。
12. 請求項１に記載のパケット処理方法において、さらに、
    前記ルックアップ結果が割り込み設定を含むか否かを検出するステップと、
    割り込み設定に応答して、ルックアップ結果の所定の順序に関係なく、前記ルックアップ結果を前記ホストプロセッサに出力するステップとを備えた、パケット処理方法。
13. 請求項１２に記載のパケット処理方法において、前記ルックアップ結果は、前記複数の応答のうちの１つを含み、前記複数の応答のうちの前記１つは、最初に受信された応答である、パケット処理方法。
14. 請求項１に記載のパケット処理方法において、前記複数の応答は複数のサブツリー応答を含み、当該方法は、さらに、
    前記複数のサブツリー応答をマージするステップを備えた、パケット処理方法。
15. 請求項１４に記載のパケット処理方法において、前記複数のサブツリー応答をマージするステップが、前記サブツリー応答のうちの、最優先ルールの一致を有する１つのサブツリー応答を選択することと、前記最優先ルールの一致がないサブツリー応答を削除することとを含む、パケット処理方法。
16. パケットを処理する装置であって、
    パケットに対するルールマッチングを行う処理クラスタから複数の応答を受信するフロントエンドであって、前記複数の応答が、前記パケットに関連するルックアップ要求に応じたものである、フロントエンドと、
    前記複数の応答を合体すべきか否かを、前記パケットの合体ビットに基づいて判定するバックエンドと、
    ルックアップ結果をホストプロセッサに出力する出力モジュールであって、前記ルックアップ結果が、前記複数の応答が合体されるべきか否かに基づいて選ばれた前記複数の応答を含む、モジュールとを備えた、パケット処理装置。
17. 請求項１６に記載のパケット処理装置において、さらに、
    ルックアップ応答テーブルを備え、
    前記フロントエンドは、前記複数の応答に基づいて前記ルックアップ応答テーブルを更新し、前記ＬＲＴは、複数の処理クラスタにおける処理中のルックアップ要求を示す、パケット処理装置。
18. 請求項１７に記載のパケット処理装置において、前記合体ビットが前記ルックアップ応答テーブルに格納される、パケット処理装置。
19. 請求項１６に記載のパケット処理装置において、さらに、
    前記複数の応答を受信する伝送バッファを備えた、パケット処理装置。
20. 請求項１９に記載のパケット処理装置において、前記バックエンドが、前記複数の応答の受信よりも前に前記複数の応答を配置するための前記伝送バッファのスロットを設定する、パケット処理装置。
21. 請求項２０に記載のパケット処理装置において、前記選ばれた複数の応答が、前記スロットに配置される、パケット処理装置。
22. 請求項２０に記載のパケット処理装置において、前記スロットが、他のスロットに対して所定の順序を有し、前記ルックアップ結果が前記所定の順序で出力されるように設定されている、パケット処理装置。
23. 請求項１６に記載のパケット処理装置において、前記アウトプットブロックが、さらに、前記ルックアップ結果が割り込み設定を含むことを示す信号に応答して、ルックアップ結果の所定の順序に関係なく、前記ルックアップ結果を前記ホストプロセッサに出力する、パケット処理装置。
24. 請求項２３に記載のパケット処理装置において、前記ルックアップ結果が、前記複数の応答のうちの１つを含み、前記複数の応答のうちの前記１つは、最初に受信された応答である、パケット処理装置。
25. 請求項１６に記載のパケット処理装置において、前記複数の応答は複数のサブツリー応答を含み、前記フロントエンドが、前記複数のサブツリー応答をマージする、パケット処理装置。
26. パケットを処理する方法であって、
    複数の応答を配置するための伝送バッファのスロットを設定するステップであって、前記スロットが、他のスロットに対して所定の順序を有するステップと、
    パケットに対するルールマッチングを行う処理クラスタから前記複数の応答を受信するステップであって、前記複数の応答が、前記パケットに関連するルックアップ要求に応じたものである、ステップと、
    前記複数の応答を、順番通りに送信するか、または順番通りではなく送信するかを決定するステップと、
    前記決定に従ってルックアップ結果をホストプロセッサに出力するステップであって、前記ルックアップ結果が、選ばれた前記複数の応答を含む、ステップとを備えた、パケット処理方法。
27. 請求項２６に記載のパケット処理方法において、さらに、
    前記複数の応答に基づいてルックアップ応答テーブルを更新するステップであって、前記ルックアップ応答テーブルが、複数の処理クラスタにおける処理中のルックアップ要求を示す、ステップを備えた、パケット処理方法。
28. 請求項２７に記載のパケット処理方法において、前記複数の応答を、順番通りに送信するか、または順番通りではなく送信するかを決定する前記ステップは、前記パケットに対して順番か順番外かの状態を示すグループ定義テーブルを照会することを含む、パケット処理方法。
29. 請求項２６に記載のパケット処理方法において、さらに、
    前記複数の応答を前記伝送バッファの前記スロットに転送するステップを備えた、パケット処理方法。

Images