JP2008509484A - セマンティックプロセッサ内のデータコンテキスト切り替え - Google Patents

Abstract

多数の解析コンテキスト用パーサとセマンティックプロセッサの実施例が図示されかつ記載されている。記載された実施例は、パーサが入力データストリームの指示するように多数のコンテキスト間で切り替えを行うことで、入力データストリームを多数のコンテキストで解析することを可能にする。例えば、ある実施例は、一回のパスにおいて文法とコンテキスト間での行き来を制御することで、多数の文法を用いてSONET入力データストリーム（多数のインターリーブされたペイロードとSONET転送オーバーヘッドを含む）を解析することを可能にする。このアプローチにより、再構成可能なセマンティックプロセッサは、複雑な多重化されたSONETストリームに関する異なるペイロードの配列を扱うことができる。
【選択図】図７

Description

関連する出願

本出願は、2004年8月5日に出願されたアメリカ仮特許出願No.60/599,830、2005年7月14日に出願された「セマンティックプロセッサTCP状態マシンを用いたTCPの隔離（TCP ISOLATION WITH SEMANTIC PROCESSOR TCP STATE MACHINE）」という題名のアメリカ特許出願No.11/181,528、2005年7月19日に出願された「パーサエラー対処のためのデバッグ非終端シンボル」という題名のアメリカ特許出願No.11/185,223及び2005年7月20日に出願された「セマンティックプロセッサ用パケット出力バッファ」という題名のアメリカ特許出願No.11/186,144に基づく優先権を主張している。また、2003年1月24日に、Somsubhra Sikdarにより出願された「再構成可能なセマンティックプロセッサ」という題名の同時係属のアメリカ特許出願No. 10/351,030を引用することにより、その内容が本出願に組み入れられているものとする。

本発明は、デジタルセマンティックプロセッサに関し、より詳しくはデータストリーム解析中の解析コンテキスト切り替えの方法と切り替えのための装置に関する。

発明の背景

データ通信の分野では、サーバーのようなネットワーク接続されている装置は、一般に、ネットワーク上で通信する場合、パケットを使用する。パケットは、一つまたは複数のヘッダー領域と一つのデータ領域を有する有限の長さ（一般的に数十から数千オクテット）のデジタル通信ユニットである。このデータフィールドは、実際はいかなる種類のデジタルデータも含むことができる。このヘッダーフィールドは、このパケットのコンテンツの配信（delivery）と解釈に関する情報を（オプションとヘッダーの種類で異なるフォーマットによって）伝える。この情報は、例えば、このパケットの送信元や宛先を識別したり、このパケットを解釈するために使用されるプロトコルを識別したり、このパケットのパケットシーケンス内の位置を識別したり、エラー修正チェックサムを提供したり、パケットフローの制御を助けたりする。パケットの有限の長さは、パケットが転送されるネットワークの種類やデータを転送するために使用されるアプリケーションの種類によって変わることがある。

一般的に、パケットのヘッダーとそれらの機能は、開放型システム間相互接続（OSI）参照モデルに従って、順序正しいやり方で構成されている。このモデルは、パケット通信の機能を複数のレイヤーへと分割する。これらのレイヤーはそれぞれ、その他のレイヤーの機能とほとんど独立したやり方で独自の機能を実行する。例えば、ネットワークレイヤーは、通常、周知のインターネットプロトコル（IP）を用いて実施され、ネットワーク規模のパケット配信及び切り替え機能を提供する。一方、上位転送レイヤーは、パケットのエンド・ツー・エンド配信のための機構を提供することができる。そのようにして、各レイヤーは、パケットの先頭に自身のヘッダーを追加することができ、かつ上位レイヤーのヘッダーをすべて、単に転送されるデータの一部として捉えることができる。

転送制御プロトコル（TCP）は、TCPセッションが確立される間、高い信頼性のあるエンド・ツー・エンド配信を用いてパケットストリームを配信するための機構を提供するのに用いられるトランスポート層のプロトコルである。従来、TCPセッションの確立には、通信エンドポイント間で、三方向ハンドシェイクが必要である。この三方向ハンドシェイクは、TCPエンドポイントが、確立されるTCPセッションを一意的に識別するためのソケット情報をやり取りする（exchange）ことを可能にするとともに、このTCPエンドポイントが、パケットシーケンスで使用される初期シーケンス番号及びウインドサイズと、エラー回復と、フロー制御と、をやり取りする（exchange）ことを可能にする。典型的な三方向ハンドシェイクの例には、第一TCPエンドポイントが同期化（synchronize）SYNパケットを第二エンドポイントに送り、そのSYNパケットに第二TCPエンドポイントが同期化（synchronize）及び承認（acknowledgment）SYN-ACKパケットで応答し、さらに第一TCPエンドポイントがそのSYN-ACKパケットに応答して承認（acknowledge）ACKパケットを送ることなども含まれる。さらに、TCPは、現在のTCPセッションを終了するときに、終端FINパケットとこのFINパケットに対する承認に関して同様のやり取りを必要とする。そのため、データ交換においてTCPを用いるためには、TCPエンドポイントは、各々のTCPセッションの状態に関する情報（例えば、TCPセッションの開始中、承認の待機中、データのやり取り中、TCPセッションの終了中など）を保持することができなければならない。

一般に悪用されるTCPの脆弱性は、この状態情報の保持から生じる。例えば、SYNフラッドサービス拒否攻撃では、複数のSYNパケットがTCPエンドポイントにより受信され、それらのパケットそれぞれが異なるTCPセッションの確立を要求する。しかし、この攻撃の実行者は、対応する三方向ハンドシェイクを完了するという意図を持たず、かつ多くの場合ハンドシェイクの障害を確実にするために仮想の送信元ポートを提供する。このSYNパケットのフラッド(flood)への対応として、各セッションの開始に対する状態情報の保持を要求することで、到着することはない承認を待っている間に、TCPエンドポイントの限られた処理リソースを割り当てる。別の攻撃には、処理リソースを誤って割り当てさせる攻撃がある。これは、保持されている状態情報とコンフリクトするセッションに対するパケットを受信させることを伴う。例えば、すでに確立されたセッションに対してSYNパケットを送ることや、まだ確立されてないセッションに対してFINパケットを送ることなどがこれにあたる。

いったんTCPセッションが適切に確立されると、TCPエンドポイントは、TCPパケットストリームでデータをやり取りすることができる。通信中、パケットは、喪失したり順序が狂って到着する可能性があるので、TCPは、喪失したパケットや遅れたパケットを再送信するとともに、到着時にパケットストリームを再順序付けするメカニズムを提供する（複製されたパケットを廃棄することも含まれる）。TCPエンドポイントは、TCP再順序付けより前にその他の例外処理を実行するように要求されることもある。この例外処理の例としては、IPフラグメントのような下位レイヤーのフラグメント化されたパケットを再構築するか、一つまたは複数のインターネットプロトコルセキュリティ（IPSec）ヘッダーなどに従って暗号演算を実行するか、またはその両方を行うことなどが挙げられる。そのため、信頼性を確保してパケットストリームのやり取りを行うためにTCPを用いると、TCPエンドポイント処理における効率を犠牲にすることになる上に、TCPをベースとした攻撃に対する脆弱性を増すことになる。

SONET（同期式光ファイバーネットワークSynchronous Optical NETwork）は、光ファイバーケーブルを介したデジタル通信のために広く用いられている標準であり、いくつかの異なるラインレートのヒエラルキーを用いている。SONET標準（ANSI T1.105.x）はラインレートをSTS-Nと既定している。ここで言う「STS」は同期転送信号(Synchronous Transport Signal)の頭文字であり、「N」は通常1, 3, 12, 24, 48, 192, 768のうちの一つである。STS‐N信号のラインレートは、N×51.84 Mbps（百万ビット毎秒）であり、8000フレーム毎秒で転送される。このフレームサイズはNと比例して大きくなる。以下の背景説明は、後で説明される本出願の実施例を理解するのに役立つSONETの概念に関する簡潔な説明と専門用語の簡潔な説明を含んでいる。

図１は、代表的なSONETネットワーク100の一部を図示している。STS終端マルチプレクサ110は、イーサーネットリンクや、回路交換方式の音声ネットワークデータリンクや、非同期性転送モード（ATM）データリンクなどの、一つまたは複数の非SONETのトリビュタリ（tributary）上でデータを受信する。STS終端MUX110は、トリビュタリからのデータをSONET STS-Nフレームへ変換する。その後、これらフレームはSONETパスを介して、パス終端装置Path-Terminating Equipment（PTE）120へ送られる（direct）。このパス終端装置は、別のSTS終端MUXであっても、STS‐N信号からトリビュタリデータを抽出する他の何らかの装置であってよい。

他のSONET装置がSTS終端MUX110とPTE120間のパスに沿って設けられている。例えば、図示されているように、二つのアドドロップマルチプレクサー（ADMs）130と140及び二つのリピータ150と160がSTS終端MUXとPTE120の間のパス上に設けられている。

ADMs 130と140は、低レートSTS-N信号を高レートSTS-N信号へ多重化する（multiplex）。またこの逆も行う。例えば、ADM 130は、４つのSTS-3ラインを１つのSTS-12ラインへ多重化したり、入力される（incoming）STS-12ラインからいくつかのSTS-3ラインを抜き取った（extract）（切り離した（drop））後、別のSTS-3ラインで置き換え（replace）（別のSTS-3ラインを加え（add））て出力されるSTS-12ラインを生成したりすることができる。

150と160のようなリピータは、確実にSONET信号をエンドポイントへ運ぶように単一の長いファイバーには長すぎるラインへ挿入される。このリピータは、SONETペイロードを変更することはできないが、単にそれを送信する時刻を決めなおし（retime）、それを再送信することはできる。

図１には異なる3つのレイヤーの専門用語も示されている。所定のデータストリームに対して、データが最初にSONETフレームに収納される（place）される位置からデータがSONETフレームから取り出される（remove）位置の間に、STSパスレイヤーが存在する。このペイロードが変更されていないSONETパスセグメントの上に、ラインレイヤーが存在している。同一のファイバーを共有するSONETレシーバーとSONETトランスミッタのペアの間にはすべてセクションレイヤーが存在する。

SONET回線は、パスと、ラインと、セクションレイヤーと、に対応するオーバーヘッドビットを運ぶ。これらのオーバーヘッドビットはそれぞれ、パスに対応するものはパスオーバーヘッド（POH）、ラインに対応するものはラインオーバーヘッド（LOH）、セクションレイヤーに対応するものはセクションオーバーヘッド（SOH）と呼ばれる。SONETエンドポイントは、セクションのみに関するエンドポイントであるので、SOHを生成したり、それに変更を加えたりすることはできるが、LOHやPOHに変更を加えることはできない。さらに、ラインエンドポイントでもあるエンドポイントは、付加的にLOHを生成したり、それに変更を加えたりすることはできるが、POHに変更を加えることはできない。パスエンドポイントだけがPOHを生成することができるエンドポイントである。

オーバーヘッドとペイロードは、SONETフレーム内の特定の位置を占める。SONETフレーム200の一般的な構造が図２に示されている。すべてのSTS-Nフレームは、９０N列９行のバイトデータを含み、左から右へ、上から下へと、一定のやり方で送られる。最初の３N列はオーバヘッドデータを含み、残りの８７N列は、同期ペイロードエンベロープ（SPE）230と呼ばれるものになる。最初の３N列内では、最初の３行はSOH 210を含み、残りの６行はLOH 220を含む。以下において簡単に説明するが、POHは同期ペイロードエンベロープ内に存在する。

図３は、二つの連続STS-1フレームK及びK+1に関する、追加のSONETフレーム300の詳細図を示している。STS-1フレーム内のPOHは、SPEの１列を占め、残りの８６列は入力データの送信に利用可能のままにする。しかしPOH は、SOHとLOHのようにフレーム内で特定の位置を占めるのではなく、SPE内の行列のどこかの位置から開始される最初の１バイトで定義されてもよい。この機能は主に、回線交換データをSONETペイロードとしてより簡単に運ぶことを可能にするために存在している。この回線交換データも8000フレーム毎秒のフォーマットを持つが、SONETフレームのタイミングと完全に同期化する必要はない。

実際のところは、POHの開始位置は、LOHの最初の２バイトに格納されるオフセット（以下「H1H2ポインタ」とする）により特定される。パス終端装置Path-Terminating Equipment（PTE）は、H1H2ポインタの値を読み取り（interpret）、H1H2ポインタの後に続く次のPOHの最初のバイトの開始位置を見つける。例えば、H1H2ポインタのオフセットが０であることは、フレームのオーバーヘッドが、H1H2ポインタのすぐ右隣である、４行４列目において開始されることを示すことになる。

図３に示されているように、フレームKのH1H2ポインタは、SPE内で、５行目の、大体７列目か８列目の位置に対するオフセットを持つ。フレームKに対するPOHの最初のバイトはここで見つかることとなる。SPE Kのデータペイロードは、フレームKのPOHの最初の１バイトのすぐ後ろから始まり、この場合には、フレームK+1の行５の最初の部分まで続く。図示したように、フレームK+1のPOHの最初の１バイトは、SPE Kの終わりの１バイトのすぐ後ろに続く。しかし、H1H2ポインタで表されているように、フレームKが、フレームK-1のPOHとフレームKのPOHの間にわずかなずれを示している場合は、上述したとおりでなければならないということはない。

SONET SPE内で運ぶことができるデータタイプの一つはパケットデータである。このパケットデータは通常、周知のコンピュータネットワーク上で運ばれる。SONETフレームシークエンスで運ばれるパケットは、SONETフレームと同期するように設定される必要はない。例えば、図４は、説明目的のSPE Kを示している。このSPE Kは、パケット1_ペイロードの終端で始まるデータペイロードを有している。このデータペイロードには、パケット_2IP（インターネットプロトコル）ヘッダー、TCP（転送制御プロトコル）ヘッダーが続く。さらに続くペイロードには、パケット_3IPヘッダー、ARP（アドレス解決プロトコル）ヘッダーが続く。そして、これに続くペイロードには、パケット_４IPヘッダー、UDP（ユーザーデータグラムプロトコル）ヘッダー、ペイロードの開始部分が続く。SPE Kを運ぶフレームまたは連続フレーム内では、SOHバイトとLOHバイト（図４では示していない）と同様にPOHバイトが各行で、パケットデータストリームを遮る。このSONETストリームを受信するPTEは、SONETのオーバーヘッドバイトを取り除き、SPEからヘッダーとペイロードだけを出力することを期待される。

SONETヒエラルキーのさらなる複雑化の原因は、異なる低レベルのSONETフレームストリームの組み合わせから高レベルSONETフレームストリームを生成するSONETフレームワークの機能にある。例えば、図５に示されているSONETネットワーク500のセグメントは、STS-12ストリームを、6つのSTS-1ストリームと２つのSTS-3cを連結したストリームから構築するというやり方を示している。（SONETネットワークの専門家には周知のことであるが、連結されたSTS-Ncフレームは、「c」接頭辞に指定されるが、列の数が多いことを除きSTS-１フレームと同様のSPE構造を持ち、またLOHにわずかな違いを持つ。）
SONETネットワークセグメント500では、第一のSTS-3マルチプレクサ（MUX）510は、３つのSTS-1ストリームA、B及びCを組み合わせ、STS-3ストリームAAを生成する。第二のSTS-3マルチプレクサ520は、３つのSTS-1ストリームD、E及びFを組み合わせ、別のSTS-3ストリームDDを生成する。STS-12MUX 530は、STS-3ストリームAA及びSTS-3ストリームDDを、2つの連結されたSTS-3ストリームBB及びCCと組み合わせ、STS-12ストリームAAAを生成する。

図６には、STS-3ストリームAA内のフレームの全体のフレーム構造600が示されている。最初の９列は、SOHバイトとLOHバイトを含み、フレーム内で多重化されている個々の低レートSPEそれぞれに対するH1H2バイトを含んでいる。STS-1A、B及びCからのH1H2ポインタは、フレーム構造のLOHセクションにあるバイトインターリーブされた３つの連続したH1H2フィールドへとコピーされる。各H1H2ポインタは、自身のPOHの最初のバイトに対して個別のオフセットを示す。３つのSTS-1 POH列に対する開始ポイントの配列は、それらの開始ポイントが、正確なSTS-1ストリームに対応するSTS-3 SPEの８７列の範囲内にあれば、どのような配列でもよい。

フレーム構造600内の次の２６１列には、STS-3ペイロードが含まれる。このSTS-3ペイロードは、受信した３つのSTS-1 SPEからのバイトインターリーブされたコンテンツから構成される。例えば、フレーム構造600の列１０は、STS-1ストリームAフレームからの列４を含んでおり、列１１は、STS-1ストリームBフレームからの列４を含んでおり、列１２は、STS-1ストリームCフレームからの列４を含んでいる。その後、このバイトインターリーブのパターンは、３つのSTS-1ストリームA、B及びCそれぞれの列５に関しても繰り返される。その後も、この繰り返しは３つのSTS-1ストリームA、B及びCの列８７まで続く。３つのSTS-1ストリームA、B及びCの列87は、それぞれSTS-3フレームの列268、269及び270に現れる。

STS-12ストリームAAAのフレーム構造は図示されていないが、STS-12マルチプレクサ530は、複数の入力STS-3ストリームと入力STS-3cストリームを合わせて4つ取り、それらを今説明したのと同様のやり方でバイトインターリーブする。この例において、STS-12 SPEの出力パターンでは、４つのSTS-3入力ストリームは、AA, BB, CC, DD, AA, BB,...,CC, DDというパターンで繰り返しバイトインターリーブされる。図６のように組み込まれているSTS-1のパターンを複数含むようにこのパターンを拡張すると、STS-12 SPEのバイトインターリーブのパターンは、A, BB, CC, D, B, BB, CC, E, C, BB, CC, Fのようになり、これがそれぞれの行において繰り返される。

従来、図５に示されているマルチプレクサを正確にミラーリングするデマルチプレクサのセットは、パスをSTS-12フレーム構造で終端させるように要求される。図５、図６及びこれまでの説明から、STS-1、STS-3、STS-3cの別の組み合わせからもSTS-12フレームを形成することができるし、STS-12フレーム自身もSTS-12cフレームとなることができるということが理解できるであろう。

STS-48フレームは、図５の４：１マルチプレクサ530の代わりに１６：１マルチプレクサを用いて、STS-3フレームとSTS-3cフレームを合わせて１６個取りそれらをバイトインターリーブすることを除き、STS-12フレームと同様に生成することができる。他の低レベル（lower-order）STSストリームの組み合わせも可能である。

以下の添付図面に基づいて本件出願の開示内容を読むことにより、本発明を最もよく理解できるだろう。

図４〜図６の例において、８つの別々のパケットペイロードは、SONETフレーム化されており、単一のSTS-12ラインに多重化される。従来は、図５に示されているネットワーク接続されている構成要素により生成されるパスを終端させるために、STS-12デマルチプレクサ、二つのSTS-3デマルチプレクサ及び８つのパケットプロセッサが必要とされた。また、STS-12フレーミングを別のやり方で形成するには、異なる終端ハードウェアの異なる構成が必要であった。例えば、STS-48フレーミングの形成には、終端ハードウェアの別の構成が必要であった。

単一の装置が異なるSTS-3、STS-12、STS-48などを処理することができるか、またはSTSデータストリームに対するSTS分離(STS demultiplexing)とペイロード処理の両方を行うことができるか、あるいはその両方ができるのが好ましい。今では、ある程度高性能化すれば、直接実行パーサを有するセマンティックプロセッサがこのようなタスクを扱うように構成することが可能であるということがわかっている。例えば、以下の説明は、前述したようなバイトインターリーブされたSTSフレーム構造を受信し、その構造（この構造は必要な場合はSPE内で運ばれるパケットデータを含んでいる）を完全に解釈し処理することができるセマンティックプロセッサの実施例と実施方式を含んでいる。説明される実施例の少なくともいくつかは、異なる解析文法をロードすることにより、別のSTSフレーム構造やペイロードコンテンツを制御するように再構成することができ、それによりさらなる効果を有することができる。

受信したSONETフレーム構造を直接解析する際の困難の一つは、バイトストリームが多くの異なる解析コンテキストからのデータを含んでいることである。これらの異なる解析コンテキストからのデータは、通常、受信したバイトごとに解析コンテキストを変更するような形で混ざり合っている。SONET処理は少なくとも一つのコンテキストで行われるが、この処理は、セクション、回線、パス及びフレームのコンテキストへ分割して行ってもよい。アトミックなSTS-1またはSTS-Ncペイロードストリームもまた、それぞれ異なるコンテキストを用いる。

また、コンテキストの構成は、STS-Nストリームがどのようにして生成されたかに依拠し、またPOHの列の入れ替えが許可されると時間の経過とともに変わる。従って、通常のSONET処理では、受信したコンテキストに関する情報の順番についてフレーム以上のことは簡単には予測することはできない。

単一のデータストリーム内に多数の解析コンテキストが存在することによる問題は、SONET解析に特有のものではない。解析が単一で線形のものに限定されない場合、より簡単に解析できる別のネットワークストリームが存在する。SONETはこのようなストリームの難しい例であると考えられるので、記載されている実施例ではSONETの実施例に焦点を当てている。当業者であれば、多数のコンテキスト解析(multiple-context parsing)が解析上の別の問題にどのように適用できるか理解できるであろう。また、当業者であれば、SONETに特有な一部の機能（例えばバイトインターリーブ解除装置(byte de-interleaver)とPOHカウンター）がすべての多数のコンテキストを解析するパーサに必要なわけではないと理解できるであろう。

図７〜図９に示されているセマンティックプロセッサの実施例は、多数の同時解析コンテキストを用いて、図６で示すようなSONETデータを適切に解析するように構成することができる。

まず、図７において、セマンティックプロセッサの実施例700が図示されている。OC-N PHY (Optical Carrier STS-N physical interface) 710は、セマンティックプロセッサ700をSONETの光ファイバーのキャリヤのペア（carrier）(図示せず)と接続させる。入力される（inbound）STS-Nストリームは、PHY 710により光学的に検知され、その後、電気的にパケット入力バッファ (PIB) 800へ送信される。出力される（outbound）STS-Nストリームは、出力（outbound）SONETファイバー上でレーザー変調するために電気的にパケット出力バッファ(POB) 720からPHY 710へ送信される。

パーサ900は、PIB 800からデータ入力を受け取るように接続される。パーサテーブル（PT）740は、セマンティックプロセッサが解析する入力に特有な解析データを格納する。生成規則テーブル（PRT）750は、セマンティックプロセッサが解析する入力に特有な文法生成規則を格納する。セマンティックコードテーブル（SCT）770は、SPUクラスタ760に対するマイクロコードセグメントを格納する。このSPUクラスタ760は、例えばパーサ900や別のSPUにこのマイクロコードセグメントを実行するように命令された場合、このマイクロコードセグメントを実行することができる複数のセマンティックプロセッシングユニットを含んでいるのが好ましい。SPU 780メモリ780は、SPUに要求されるデータ（例えば、セッションコンテキストや現在処理されているパケットデータなど）を格納する。PT 740、PRT 750及びSCT 770は、プログラム可能な内部メモリとともに使用され、SPUメモリ780はキャッシュ用DRAM外部メモリとともに使用される。

動作する際、PIB 800は、図７に示されているOC-N PHY710のような適当なPHYから、イーサネット（「イーサネット」は登録商標）フレームやSONETフレームやFibre Channelフレームのシークエンスのような入力データを受信する。これらのフレームデータは、文法生成規則及びSCTマイクロコードに命令されると、パーサ900またはSPUクラスタ760によりあるいはその両方によりPIB 800から読み出される。

パーサ900がPIB 800から入力データを受信すると、パーサ900は、入力データに対して以下の二つのうち一つを実行することができる。一つ目は、入力データシンボルを生成規則の中に格納されている文字のシンボル（終端シンボル）と文字通りに一致させることである。二つ目(こちらの方が通常はより一般的である)は、パーサ900は、現在のデータ入力シンボル及び現在の生成シンボル（非終端シンボルすなわちNTシンボル）に基づいて、データ入力シンボルに対するさらに別の生成規則を「検索する」ことである。なお、一般的には、終端シンボルの一致確認は、生成規則終端シンボルとパーサテーブル終端一致値のどちらか一方を用いて実行することができる。

パーサ900が文法によりさらに別の生成規則を検索するように命令されると、パーサ900は、一つまたは複数の現在のデータ入力（DI）シンボル及び非終端（NT）文法シンボルをパーサテーブル740へ供給する。このパーサによって供給された（NT、DI）のペアリングに基づいて、パーサテーブル740は、対応するPRコードを生成規則テーブル（PRT）750へ発する（issue）。いくつかの実施例では、パーサテーブル740は、メモリの内容が（NT、DI_一致）形式の入力(entries)から構成される三重コンテント・アドレッサブル・メモリ（TCAM）とともに利用される。同一のNTシンボル及び異なるDI_一致値に対して複数の（NT、DI一致）入力が存在する。TCAMは、正しいNT値及び供給されたデータ入力DIと一致するDI_一致値を持った入力のアドレスをPRコードとして送り返す。TCAMは、各TCAM入力中の個々のビットまたはバイトを「無視」値に設定することを可能にするので、各TCAM入力は、現在の生成規則に重要なDI中のビットまたはバイトに対応するように調整することができる。

パーサテーブル740が正しいPRコードを見つけると、そのコードは生成規則テーブル750へ送られる。PRT 750は、このPRコードに対応する生成規則を検索し、そこで見つかった生成規則を出力する。この生成規則は必要とされるものは何でも含むことができるが、図７では、この生成規則はM列以下の非終端シンボル（か終端シンボルまたはその両方）NT [ ]の配列と、R列以下のセマンティックコード入力ポイントSEP [ ]の配列と、スキップバイト値と、を含んでいる。シンボルの配列NT [ ]は、一番新しい解析サイクルに基づいて、パーサにどのインプットが現在期待されているのかを示す。スキップバイト値は、パーサに対して、一番新しい解析サイクルでDIバイトがどれだけ消費されたのかを示す（消費があった場合）。このスキップバイト値はこの後廃棄することができる。セマンティックコード入力ポイントの配列SEP [ ]は、SPUクラスタ760に一番新しい解析サイクルに基づいて実行されるべきプロセッサのタスクを示す。

PRT 750から供給されるSEPに基づいて、SPUクラスタ760はコードセグメントをロードしかつ実行し、タスクを実行する。例えば、SPUは、入力パケットのペイロード部分をPIB 800からSPUメモリ780へ移すように命令されてもよく、同様のやり方でこのペイロード部分を制御するように命令されてもよい。また、SPUクラスタ760は、出力パケットやフレームを生成し、その後PHY 710における出力転送（outbound transmission）のためにそれらをPOB 720に供給することもできる。

前述したセマンティックプロセッサの実施例の動作の説明は、PIB 800及びパーサ900と代表的なセマンティックプロセッサのそれら以外のブロックとの相互の動作（interoperation）を理解するためには十分なものである。この相互運用については、多数のコンテキストのSONET処理（multi-context SONET processing）に関して、後で詳細に論じることとする。図７の他のブロックのさらなる例については、同時係属のアメリカ特許出願No.10/351,030を参照されたし。この出願の内容は、それを引用することにより本出願に組み入れられているものとする。

おそらく、パーサ900はバイトインターリーブされたSONETストリームに対して直接演算（オペレーション）を実行することができると考えられるが、高速演算中にすべてのバイトの境界でコンテキスト切り替えを実行すると、パーササイクルの制限回数（prohibitive number）を無駄に消費することに繋がる可能性がある。そのため、図８は、受信したSONETフレームを部分的にインターリーブ解除（デインタリーブ／deinterleave）することができるPIB 800の一実施例を示している。

この入力バッファの実施例の目標は、行ごとに、STS-Nストリーム内に存在するバイトインターリーブされたSPEをインターリーブ解除することである。図１０を参考されたし。図１０は、3つのバイトインターリーブされたSTS-1A、B及びC（図６を参照）から構成されるSTS-3フレームに関する好ましいPIB 800の出力を図示している。他のやり方としては、SOH列及びLOH列もこのような構造を予期するように書かれたパーサ文法を用いて同様にインターリーブ解除することができる。また、H1H２ポインタのような特定のオーバーヘッドセクションもインターリーブ解除することができる。

図１０のフレーム構造1000は、図５のラインSTS-3AAに適用してもよい。フレーム構造1000内には、図６のフレーム構造600と同様に９列のSOH及びLOHと、２６１列のSTS-3 SPEが存在する。しかし、バイトインターリーブの解除後は、２６１列のSTS-3 SPEは、それぞれが図５のSTS-1A、B及びCに対応する3つの連続した８７列のセクションへ分割される。なお、各行に対するSTS-1Aペイロードセクションは、最後のSTS-1Aバイトが受信される時には、その行の最後から3バイトまでは完成することができないので、フレーム構造1000は、約三分の二の行がインターリーブ解除待ちの状態で生成されてもよい。

図8に戻り、PIB 800のブロックについて、より詳しくは図６のフレーム構造を図１０のフレーム構造へ変換するPIB 800のブロックの機能について説明する。しかし、PIB 800は、インターリーブ解除を実行しないようにあるいは異なるインターリーブが行われた構造に対してインターリーブ解除を実行するように再構成可能となっていることが好ましい。

入力FIFO 810は、OC-N PHYからSTS-Nデータストリームを受信する。入力FIFO 810は、フレーム同期化を行うために、STS-Nデータストリーム内のフレーム化されたバイト（framing byte）を検出する。入力FIFO 810は、その後、通常のSONETデスクランブラ820と連携して、転送前にスクランブルされた各SONETフレームの一部をデスクランブルする。入力FIFO 810のDQI出力は、それがVIB（Virtual Input Buffer）ステージ830からデータクロック信号D_CLKを受信する度に、デスクランブルされたSONETフレームデータのバイトDQIを出力する。

VIBステージ830には、プログラム可能であるバイトデインターリーバパターン（BDIP）レジスタ834からの対応するVIBアドレス入力（エントリー）とDQIの各バイトの一致確認をするタスクがある。VIBステージ830がアドレスクロック信号A_CLKをアサートするたびに、VIBステージ830はBDIPレジスタ834からVIBアドレス入力（エントリー）を取得し、その後BDIPレジスタはインクリメントする。

BDIPレジスタ834は、SONETフレームデータの一つの行を入力バッファ850内のVIB入力バッファのグループへマッピングする機能を有している。例えば、図６のフレーム構造600のパターンは、以下のパターンを持つ２７５の入力（エントリー）でよい。
&,1,2,3,1,2,3,1,2,3,…,1,2,3,1,2,3,1,&,2,&,3,&@,
ここでは、「&」及び「@」は、特別な制御キャラクターを意味する。この例では、VIB 0は何らかのバイトを保持するようには割り当てられておらず、VIB 1はSTS-1Aのバイトを保持するように割り当てられており、VIB 2はSTS-1Bのバイトを保持するように割り当てられており、VIB 3はSTS-1Cのバイトを保持するように割り当てられている。制御キャラクター「&」は、VIBステージ830によりDQIと一致されるのではなく、同一のVIBに最終DQIとして書き込まれる。この最終DQIは、この特定のVIBに対して「行の終わり」を示す。制御キャラクター「＠」は、BDIPレジスタ834にフレームの行が最終行に到達したことを伝える。その後このキャラクターは、BDIPレジスタ834に、自身の読み込みポインタをレジスタの先頭へリセットするさせるとともに、出力制御装置860に、完全なフレームの行はすでにインターリーブ解除が終わっており（または数クロックサイクル中にインターリーブ解除が終わり）、出力準備は完了しているということを知らせるようにS_Wrap信号をアサートする。

アドレスデコードステージ832は、DQIとVIBのアドレスのペア及び&とVIBのアドレスのペアをVIBステージ830から受信する。アドレスデコードステージ832は、VIBアドレスをVIBポインタレジスタブロック840へ供給する。このVIBポインタレジスタブロック840は、このVIBアドレスに対応する物理バッファアドレスを送り返す。アドレスデコードステージ832は、DQIまたは「&」を入力バッファ850内の物理バッファアドレスへ書き込む。

VIBポインタレジスタ840は、各々が、物理開始アドレス、物理終端アドレス、書き込みポインタ及び読み込みポインタを格納する複数の環状バッファポインタレジスタとして動作するように構成されている。アドレスデコードステージ832がVIBアドレスをVIBポインタレジスタ840へ供給すると、正しい書き込みポインタが読み出され（検索され）、このポインタがアドレスデコードステージ832に物理バッファアドレスとして送り返される。この書き込みポインタはその後インクリメントされる。そして、書き込みポインタが終端アドレスに到達すると開始アドレスへリセットされる。

PIB 800の出力側では、出力制御装置860は、フレーム行準備（Frame Row Ready）出力信号と、パーサ出力FIFO 862と、データリクエスト入力と、を介してパーサと通信（interface）する。また、出力制御装置860は、SPU出力FIFO 864及びSPU_IN FIFO 866を介してSPUまたはSPUクラスタと通信（interface）する。両インターフェイスの動作を順に説明する。

出力制御装置860がBDIPレジスタ834からS_Wrap信号を受信すると、制御装置860は、フレーム行準備（Frame Row Ready）をパーサへアサートする。出力制御装置860はその後、パーサFIFO 862を介してDQO（DQ Output）値をこのパーサへ転送することでこのパーサからのデータリクエスト入力に応答する。

出力制御装置860は、D_REQ(data request)信号をアドレスデコードステージ870へ送ることでパーサFIFO 862をロードする。アドレスデコードステージ870は最初、内部でVIB0から読み込むように設定される。このアドレスデコードステージ870がD_REQ信号を受信する度に、アドレスデコードステージは、VIB 0に対する現在の読み込みポインタをVIBポインタレジスタ840からリクエストする。アドレスデコードステージ870は、この読み込みポインタをバッファ読み込みアドレスとしてインプットバッファ850に供給し、DQOを受信する。一方、VIBポインタレジスタ840は、読み込みポインタをインクリメントする。そして、読み込みポインタが終端アドレスに到達すると開始アドレスにリセットする。

アドレスデコードステージ870が、入力バッファ850から「&」制御キャラクターを含むDQOを受信すると、アドレスデコードステージは、現在のSONET行に対し仮想バッファの入力の終端に到達したことを認識する。それに応じて、アドレスデコードステージ870は、自身の内部VIBアドレスをVIB 0からVIB 1へインクリメントするとともに次のD_REQに対してVIB 1から読み込みを開始する。「&」が各VIB内に到達すると、最後に割り当てられたVIB内の「&」が到達するまで、これと同様の動作が繰り返される。この時点で、内部VIBアドレスは、フレームの次の行の読み込みに備えてVIB 0へリセットされる。

DQO値は、SPUからSPU_IN FIFO 866で受信されたコマンドに基づいて、SPU FIFO 864を介し、同様のやり方でSPUへ読み出される。なお、VIBポインタレジスタ内の各VIB内に次のいくつかの「&」キャラクターに対するポインタを格納することで、以前のコマンドの「バースト（burst）」読み込みまたはスキップフォワードコマンドを効率よく実行することもできる。その後で、多数の連続したDQO値がそれ以前に（past）現在のVIB内の次の「&」を読み込んでいない場合に限り、これらのDQO値が一度に読み込まれる。

SPU_IN FIFO 866も、実行時のPIB 800の動作をプログラムするのに用いることができる。適切なCMD_INを発することで、SPUは、出力制御装置860に、パターンを受信し、その受信したパターンをレジスタプログラム信号インターフェイスを介してBDIPレジスタ834へロードするように命令することができる。また、SPUは、出力制御装置860に、VIBポインタレジスタ840内の動作中の各VIBに対してVIB開始アドレス値及びVIB終端アドレス値を設定し（configure）、その後読み込みポインタ値と書き込みポインタ値を初期化するように命令することができる。また、SPUは、出力制御装置860に、適切なフレームサイズとキャラクターシークエンスのアライメントに対して入力FIFOを設定するとともにシードをデスクランブラ820へロードするように命令することができる。

VIBステージ830やアドレスデコードステージ832は、設計されたSTS-Nデータレートに対して適切な回線容量を達成するため、必要に応じてパイプライン接続することができる。BDIPレジスタ834は、関連のある最大のSTS-Nに対する行マッピングを保持するのに十分なサイズに設計される。また、入力バッファ850は、関連のある最大のSTS-Nの内少なくとも2行を保持するのに十分なサイズに設計される。VIBポインタレジスタ840は、関連のある最大のSTS-N（このSTS-Nは、全体が複数のSTS-1で構成されている）をインターリーブ解除するのに十分なポインタレジスタのセットを有するように設計される（例えば、なんらかのSTS-48のインターリーブ解除を制御するために４９個のポインタレジスタのセットを有してもよい）。

バイトインターリーブされていない入力に関して、前述した機能の大半は、単純なシングル循環バッファインターフェイスを用いて入力バッファ850へバイパスすることができる。他のやり方としては、説明したハードウェアは、BDIPレジスタ834内の連続したVIB 0のパターンとVIB 0のレジスタのセットを用いて構成されてもよい。このレジスタは、入力バッファ850の（VIB 0ブロックの）左端へ設定された開始アドレス及び入力バッファ850の（VIB 0ブロックの）右端へ設定された終端アドレスを有する。

図６のSTS-3の例とPIB 800の動作の説明から分るように、PIB 800は、３つの仮想入力バッファ及びBDIPレジスタ834内に格納された代表的なパターンを用いて、図１０に示されている変更されたSONETフレーム構造1000をパーサ900に渡す。バイトインターリーブされたSTS-3フレーム構造とは異なり、フレーム構造1000は、STS-1AのTOHとSPE列に対応する90列をフレームの最初の90列へ配置するように再構成される。このフレームに列91から始まるSTS-1Bのすべての列が続き、その後に列181から始まるSTS-Cすべての列が続く。解析文法が、何が受信されるのか予期するように構成されている限り、その他の列を再構成することも可能である。

図１０に示す再構成されたSTS-3フレーム構造1000によれば、パーサ900は、フレーム構造1000を処理するために、依然として少なくとも４つの異なるコンテキストを用いることになる。図１１に示されているように、７つのコンテキストが用いられる。コンテキスト０は、入力ストリームに対するルートコンテキストである。コンテキスト１、３、５は、それぞれSTS-1 A、B、CのTOHバイトを解析するのに用いられる。コンテキスト２、４、６は、それぞれSTS-1 A、B、Cのペイロードを解析するのに用いられる。

図１１は、再構成された図１０のSTS-3の例のうちフレームK＋1の一行目だけを再度示している。最初の３バイトはコンテキスト１を用いて解析される。このコンテキスト1は、SOHの一行目に現れる配置及びJ0キャラクターを認識するように設計された文法を有するSTS-1解析コンテキストである。

次の８７バイトはSTS-1 Aペイロードのコンテキストの一部であり、POHバイトと８６バイトのペイロードを含んでいる。この例では、このPOHバイトと８６バイトのペイロードは、パケットデータ（ヘッダーやパケットペイロード）であると考えられる。これらの８７バイト内におけるPOHバイトの実際の位置は、コンテキスト１の一部にあり、この位置は前に解析されたH1H2 LOHフィールドから読み出されなければならない。そして残りの86バイトは、ほとんど確実に（in all likelihood）、パケットの最初のバイトからは開始されず、再び用いらなければならない以前の未完了の解析コンテキストの続きとなりうる。

それぞれがSTS-1 B (コンテキスト３と４)とSTS-1 C (コンテキスト５と６)に対応する（represent）真ん中の９０バイトと最後の９０バイトについても、これと同様の結果が起こる。この例では、最後の２バイトのセグメント内のパケットデータは、SPEデータの最初の８７バイト内のパケットデータと異なる解析コンテキストを表すことになる。その後、この最後の２バイトのセグメントに対するH1H2値は、９０バイトのセグメント内でこれらの２バイトのセグメントに固有なPOHの位置を示すことになる。

図１１に示されている行の最後で、コンテキストは、ルートSTS-3コンテキストであるコンテキスト０に再び切り替わる。したがって、図１１に示されている代表的な変更されたSTS-3の行の処理の間に、本発明の実施例に係る直接実行パーサは、解析コンテキストを１３回切り替えることができる。切り替え自身は、変更されたSTS-3コンテキストが「動作中」でないときでさえ、このコンテキストにより制御される。

パーサの実施例900のブロック図が、PIB 800と、パーサテーブル740と、生成規則テーブル750と、とともに図９に示されている。パーサ900は、入力データインターフェイス910と、コンテキストシンボルレジスタ920用バンクと、パーサ状態マシン930と、パーサスタックマネージャー940と、コンテキスト ヘッド/テイル レジスタ950用バンクと、パーサスタックメモリ960と、を有している。

入力データインターフェイス910はPIB 800と通信する。PIB 800がD_RDYをインターフェイス910にアサートすると、インターフェイス910は、SONETフレームの行の終端が信号で送られてD_RDYがアサート停止されるまで、PIB 800にロードリクエストやスキップリクエストを送ることができるようになる。ロードのリクエストに応じて、PIB 800はバスDINを介してインターフェイス910に入力データを供給する。

入力データインターフェイス910は、パーサ状態マシン930からのリクエストに応じて、PIB 800からデータをリクエストする（ただし、インターフェイス910は、それが外部リクエストに対し正確に応答する限り、まだリクエストされていないデータをキャッシュしてもよい）。パーサ状態マシン930は、CTSバス上の現在のコンテキストに対してIDを保持する。パーサ状態マシン930が、入力データインターフェイスに、入力データをコンテキストシンボルレジスタ920へロードするよう指示したときはいつでも、入力データインターフェイス910の内部にあるPOHレジスタ/カウンター912のブロック内の行バイトカウンターは、当該コンテキストへ読み込まれたバイトの数を追跡する。

レジスタ/カウンター912のブロック内では、2つのカウンターレジスタが各コンテキストに対して割り当てられている。第一のカウンターは、前に説明した行_バイト_カウンターである。このカウンターは、現在のフレームの行における現在のコンテキストに読み込まれたバイトの数をカウントする。第二のカウンターは、SPEバイトカウンターである。このカウンターは、現在のSPE内で用いられている現在のコンテキストに読み込まれたバイトの数をカウントする。SPEバイトカウンターのカウントは、各SPEが読み込まれた後にリセットされる。

４つの比較用レジスタも同様に、レジスタ/カウンターブロック912内で、各コンテキストに対して割り当てられている。行_カウント_最大レジスタ（row_count_max register）は、現在の行に用いられているコンテキストに読み込まれるべきシンボルの最大数を、例えばSTS-1行に対して８６（この値はオーバーヘッドバイトの分を除いたものである）と決める。SPE_カウント_最大レジスタは、現在のSPE用のコンテキストに読み込まれるべきシンボルの最大数を、例えばSTS-1 SPEに対して７７４（この値はオーバーヘッドバイトの分を除いたものである）とする。現在のPOHポインタ（current_POH_pointer）は、現在のSPE内のPOHの列位置に対応する値を保持する。また、次のPOHポインタ（current_POH_pointer）は、次のSPE内のPOHの列位置に対応する値を保持する。パーサテーブル740及び生成規則テーブル750が現在の入力ストリームに対して設定されると、行_カウント_最大レジスタ及びSPE_カウント_最大レジスタがロードされる。現在のPOHポインタ（current_POH_pointer）及び次のPOHポインタ（next_POH_pointer）は、動的（dynamic）であり、パーサ状態マシン930からのロード_POH_レジスタ（load_POH_register）信号により設定される。

各コンテキストに対しては、有効フラグレジスタ（enable flag register）も存在している。有効フラグレジスタの値は、特定のコンテキストに対するレジスタとカウンターが有効になっているかどうか判定する。特定のコンテキストに対するレジスタとカウンターが有効なっており、このコンテキストが動作中である場合、データがこのコンテキストシンボルレジスタ920に送られると行バイトとSPEバイトがインクリメントする。行バイトカウンター値が行_カウント_最大レジスタ値に到達すると、入力データインターフェイス910は、レベル-デクリメント文法コンテキスト切り替え信号をパーサ状態マシン930に送り、現在のコンテキストに対する処理中のデータの転送をすべてやめさせる。行バイトカウンター値が現在のPOHポインタ（current_POH_pointer）値に到達すると、入力データインターフェイス910は、レベル-デクリメント文法コンテキスト切り替え信号をパーサ状態マシン930に送り、現在のコンテキストに対する処理中のデータの転送をすべてやめさせる。同様に、SPEバイトカウンター値がSPE_カウント_最大値に到達すると、次のPOHポインタ（next_POH_pointer）が現在のPOHポインタ（current_POH_pointer）へロードされるとともに、入力データインターフェイス910は必要ならば、（行バイトカウンター値が）次のPOHポインタ（next_POH_pointer）に到達するまで、現在の行においてバイトをスキップする。

レジスタ/カウンター912の最終タスクの一つは、いつトランスミッタ（transmitter）が正バイトスタッフまたは負バイトスタッフを信号で送ったのかを判定することである。正バイトスタッフは、POHポインタの７、９、１１、１３、１５のビットをトランスミッタが反転させて信号で送られ、負バイトスタッフは、POHポインタの8、10、12、14、16のビットをトランスミッタ（transmitter）が反転させて信号で送られる。パーサ状態マシン930がコンテキストに対し次のPOHポインタ（next_POH_pointer）をロードすると、レジスタ/カウンター912は、次のPOHポインタ（next_POH_pointer）値を現在のPOHポインタ（current_POH_pointer）値と比較し、その後、上述したように、パーサ状態マシン930に正バイトスタッフ状態または負バイトスタッフ状態を信号で送る。また、行バイトカウンターは、正バイトスタッフでは１インクリメントされ、負バイトスタッフでは、１デクリメントされる。

コンテキストシンボルレジスタ920は、N個の潜在的なコンテキストそれぞれに対してコンテキストシンボルを格納する。例えば、コンテキスト２がIPパケットコンテキストである場合、パケットの解析が完了するまでは、パケットごとに数回コンテキスト２の終了と再入力を行うことができる。コンテキストシンボルレジスタ920は、その間、保留されたコンテキストに対する現在のシンボルの状態を保持する。レジスタ920が入力データインターフェイス910から入力バイトを受信すると、レジスタ920は、それらの入力バイトをCTSバス上で示されるコンテキストレジスタへ格納する。また、DIバス上でパーサ状態マシン930及びパーサテーブル740に対して出力される値は、CTSバス上で示されるコンテキストレジスタ内に含まれる値である。また、コンテキストシンボルレジスタ920は、各コンテキストシンボルレジスタに対して二つの値を保持するのが好ましい。これらの値は、それぞれ、入力バイトの内何バイトが有効であるかと、何バイトの入力バイトがリクエストされ解決されていないかと、を示す。

パーサ状態マシン930は、パーサ900のその他の構成要素の動作（オペレーション）をコーディネートし、かつすべてのコンテキスト切り替えに対する信号を送る。先に述べたように、場合によっては、バイトカウンターによる比較結果に基づいて、パーサ状態マシンにコンテキストを切り替えるための信号を送ることができる。以下の例で、パーサ状態マシンにコンテキストを切り替えるように命令する特別な非終端をパーサ状態マシンが受信したときに、コンテキスト切り替えが文法自身によりどのように開始されるのかを実際に示す。いくつかの実施例においては、パーサ状態マシン930は、ここで説明されるコンテキスト切り替え機能以外にも、同時係属のアメリカ特許出願No.10/351,030で説明されているパーサ状態マシンと同様の動作をすることができる。

パーサスタックマネージャー940は、パーサスタックメモリ960に対してパーサスタックシンボルのプッシュ(pushes)及びポップ(pops)（転送及び取り出し）を実行する。図示した実施例では、CTSバス値は、パーサスタックマネージャー940が各コンテキストに対するヘッド/テイルレジスタ950のセットにアクセスするために用いられる。ヘッド/テイルレジスタ950は、各コンテキストに対して二つのポインタを備えている。一つ目は、ヘッドポインタであり、このポインタは、このコンテキストに対するスタックの一番上のシンボル（top-of-stack symbol）に対応するパーサスタックメモリ960内のアドレスを有している。二つ目は、テイルポインタであり、このポインタは、このコンテキストに対するスタックの一番下のシンボル（bottom-of-stack symbol）に対応するパーサスタックメモリ960内のアドレスを有している。シンボルがコンテキストにプッシュされる(pushed to a context)と、ヘッドポインタはインクリメントされる。シンボルがコンテキストにポップされる(popped to a context)と、ヘッドポインタはデクリメントされる。

パーサ900の構成要素間におけるandcooperationの演算を、図１０のインターレース解除された(de-interlaced) STS-3フレームに基づいて、例を用いて説明することにする。

パーサ900がSTS-Nストリームからの入力の処理を開始するまでは、STS-Nストリームを当該ストリームに対して適切な数の解析コンテキスト用に特別に構成することができる。しかしながら、その場合、コンテキストが利用可能でありかつ「ルート」文法(“root”grammer)であるSTS-3文法と入力ポートに対して必要とされる個数の「ブランチ」文法(“branch”grammars)とともに使用される準備がすでにできていることが好ましい。この場合、それらのコンテキスト間の動き（movement）が文法により指示されるようになっていることが好ましい。

例えば、図示した実施例のSTS-3ルートフレーム文法（STS-3ストリームに対するルート文法）は、以下のように定義される。

上述した文法では、STS-3ストリームは、フレームの一番上の（top of frame(TOF)）シンボルとして定義される（後にインターレース解除されたSTS-3フレームが続く）。このTOF文法は、「SKIP_1_BYTE」を行えという命令、言い換えると、コンテキスト0に対するシンボルレジスタ920からCTL_New Frameシンボルを消費しろという命令を含んでいる。

インターレース解除されたSTS-3の定義は、共通のパターン「@@L+1CTS@@L+3CTS@@L+5CTS」の繰り返しを9回含んでいる。CTS文法は、CTL_ContextShiftキャラクターを検索し、その後それを消費する。このCTL_ContextShiftキャラクターは、PIBにより、仮想入力バッファセグメントの間で入力データストリーム中に挿入されたものである。この＠＠L+n文法は、コンテキストを現在のコンテキストとの関係でn個上のコンテキストにシフトしろという特別なパーサの命令を意味する。このように、インターレース解除されたフレームの各行において、ルート文法のSTS-1文法への切り替えは三度行われる。これは以下のように定義される。

STS-1文法は、インターレース解除されたSTS-1入力を、９行において、例えば以下のように処理する。

STS-1フレームの各行は別々に定義される（STS-1コンテキストが呼び出される度にSTS-1コンテキストが適切な位置で再入力（re-enter）されるように、STS-1フレームの各行は別々に定義される）。以下で説明するが、各行はTOH処理を実行し、その後STS-1_SPE_行処理を実行する。このSTS-1_SPE_行処理は、IPコンテキストやATMコンテキストなどである次のコンテキストへインクリメントする。入力データインターフェイス910は、POH列に到達すると、コンテキストに、STS-1_SPE_行文法へ戻るように信号を送る。この時点でPOHバイトは消費される。SPE行の最終行に到達し、入力データインターフェイス910がコンテキストにSTS-1_SPE_行文法へ戻るように信号を送るまで、STS-1_SPE_行文法はインクリメントし次のコンテキストへ戻る。STS-1_SPE_行文法は、その後、@@Lrootコマンドを用いて、パーサ状態マシンにルート文法に戻るように命令する。

定義された転送オーバーヘッドバイトの各セットは、適切な行の範囲内で解析される。図示されていないが、転送オーバーヘッドバイトの一部は、必要であれば、このオーバーヘッドバイト自身のサブ文法で処理されてよい。例えば、D1〜D12バイトは、別のデータチャンネルとして使用することができる。これらは適切な文法で解析される。

一つの実行可能性のあるTOHの行４に対するアプローチが示されている。この行は次のSPEに対するPOHポインタを含んでいる。特別な@@Xfer指示ポインタは、適切な次のPOHポインタ（next_POH_pointer）レジスタに二つのポインタのバイトを送り、入力データインターフェイス910に、Pos_Shift、Neg_ShiftまたはNo_Shiftをパーサ状態マシン930に戻すようにアサートする。アサートされた変数（variable）の状態に応じて、2バイトか3バイトか4バイトの入力バイトがその後消費される。

特別な目的の実行エンジンを図示し、説明したが、他の実施例（implementation）でも、上述したマルチシンボルパーサを、通常目的のプロセッサ用のフロントエンドデータグラムプロセッサとして用いることができる。上述したSTS-3の例は、簡単にするために用いられたが、ここで説明された概念は、STS-1ストリーム、STS-3ストリーム、STS-3cストリーム、STS-12ストリーム、STS-12cストリーム及びSTS-48cストリームのどのような組み合わせからなるSTS-12ストリームやSTS-48ストリームを解析するのにも応用することができる。

転送制御プロトコル（TCP）を用いた直接ネットワーク通信は、ネットワークされた装置のTCPベースの攻撃に対する脆弱性を増大させ、パケット到着時のパケットへの追加処理を必要とするかもしれない。直接TCPベースのネットワーク通信を特別に実行するように設計されたプロキシTCPエンドポイントを追加することで、起こり得る攻撃からネットワーク接続されている装置を守り、それらの装置の処理効率をあげることができる。以下において、本発明の実施例をより詳しく説明することにする。

図１２は、本発明の実施例に利用可能なネットワーク通信システム2100のブロック図である。図１２に関して、このネットワーク通信システム2100は、プロキシ2200を介してネットワーク2120上で通信を行うネットワーク接続されている装置2140を含んでいる。このネットワーク2120は、パケット切り替えを提供する限りどのようなWide Area Network（WAN）でもよい。このネットワーク接続されている装置2140は、サーバーやネットワーク通信可能なそれ以外の装置でよい。

このプロキシ2200は、ネットワーク2120上に少なくとも一つのTCPセッションと、ネットワーク接続されている装置2140に対応するローカルセッションと、を保持している。いくつかの実施例では、このローカルセッションは、私的なネットワーク（例えば、企業内ネットワーク（company enterprise network）やインターネットサービスプロバイダー（ISP）ネットワークや家庭内ネットワークなど）を介してネットワーク接続されている装置2140とともに確立されるTCPセッションでもよい。このプロキシ2200は、ローカルセッションとTCPセッション間でデータを変換することで、ネットワーク接続されている装置2140に対するネットワーク通信中継媒体(intermediary)として動作することができる。例えば、TCPセッション内のネットワーク2120からパケット化されたデータを受信すると、このプロキシ2200は、そのデータをローカルセッション内のネットワーク接続されている装置2140に送る前に、データに順序付けとパケット化解除を行ってもよい。このパケット化解除には、例えば、インターネットプロトコルセキュリティ（IPSec）ヘッダーに従って、インターネットプロトコル（IP）フラグメントを再構築することや暗号演算を実行することなどが含まれる。このプロキシ2200による順序付け及び処理により、ネットワーク接続されている装置2140はローカルセッション内で均一のデータストリームを受信することができ、それによりネットワーク接続されている装置2140に対するサービスの質（QOS）と、ネットワーク上のバンド幅の使用の制御と、を保障することができる。

プロキシ2200は、ネットワーク接続されている装置2140に対するエンドポイントではなく、ネットワーク通信に対するエンドポイントなので、TCPセッションは、プロキシ2200のTCPシグネチャー（signature）を有している。このようにしてネットワーク接続されている装置2140の存在（identity）をネットワーク2120から隠すことができる。このようにネットワーク接続されている装置2140を隠すことで、ネットワークベースの攻撃にそれらの装置が晒されるのを防ぐことができる。プロキシ2200は、宛先IPアドレスと送信元IPアドレスのネットワークアドレス変換（NAT）を実行し、ネットワーク接続されている装置2140の存在（identity）を隠すのに役立つこともある。プロキシ2200は、どのネットワークインターフェイス（例えばファイアーウォールなど）において実施されてもよい。

いくつかの実施例において、プロキシ2200は、複数のネットワーク接続されている装置2140に、ネットワーク通信と処理を提供することができる。これらの実施例においては、単一のネットワークインターフェイスポイントにおいてネットワーク通信を管理（management）することで、プロキシ2200は、ネットワーク管理及びパケット処理の効率を向上させるための追加の機能を提供することができる。例えば、プロキシ2200が複数のTCPセッションの内の一つにおいてネットワーク変更（例えば、next hop変更や、インターネット制御メッセージプロトコル（ICMP）フラグメントや、パケット喪失など）を見つけた場合、その変更がすべてのTCPセッションに適用されるようにしてもよい。これは、ボーダーゲートウェイプロトコル（Border Gateway Protocol）やネットワーク2120のトポロジー（topology）全体を認識している別のリンク状態ルーティングプロトコルを十分に隣接した状態で実施することと組み合わせることで、特に効果を発揮する。さらに、プロキシ2200は複数のセッションを保持するので、単一のネットワークインターフェイスポイントにおいてこれらのセッションの状態と統計値にアクセスすることができる。

以下において、本発明のいくつかの実施例におけるプロキシ2200の構造と動作（オペレーション）を、図１３Ａ〜１５に基づいて説明する。図１３Ａは、図１２に示されているプロキシ2200の実施例をブロック図で示している。図１３Ａに示すように、プロキシ2200は、ネットワーク2120上の一つまたは複数のTCPセッションを管理するためのネットワークインターフェイスプロキシ2210と、ネットワーク接続されている装置2140との一つまたは複数のローカルセッションを管理するためのデバイスインターフェイスプロキシ2220と、を備えている。このネットワークインターフェイスプロキシ2210とデバイスインターフェイスプロキシ2220は、それら各自のセッションで転送されるデータの交換を行う。例えば、ネットワークインターフェイスプロキシ2210がTCPセッションからのペイロードデータをデバイスインターフェイスプロキシ2220に提供する場合、該デバイスインターフェイスプロキシ2220は、このデータをローカルセッション内のネットワーク接続されている装置2140へ転送する。逆に、デバイスインターフェイスプロキシ2220がネットワーク接続されている装置2140からのペイロードデータをネットワークインターフェイスプロキシ2210に提供する場合、該ネットワークインターフェイスプロキシ2210は、このデータをTCPセッション内のネットワーク2120上へ転送する。

このネットワークインターフェイスプロキシ2210は、ネットワーク2120上にTCPセッションを確立するとともにそれを管理するためのTCP状態マシン2212を有している。この管理には、各TCPセッションの状態情報を保持することと、パケット順序付け、エラー回復及びフロー制御メカニズムを実行することと、が含まれる。TCP状態マシン2212は、TCPセッション上で受信されたパケットストリームを順序付けして処理し、その後順序付けしたペイロードデータをデバイスインターフェイスプロキシ2220へ提供する。TCP状態マシンが前もってペイロードデータを順序付けしかつ処理しているので、デバイスインターフェイスプロキシ2220は、ローカルセッション内のネットワーク接続されている装置2140に均一のデータストリームを提供することができる。TCP状態マシン2212は、さらに、デバイスインターフェイスプロキシ2220から受信したペイロードデータをパケット化し、その後それを対応するTCPセッションを介して送信する。

デバイスインターフェイスプロキシ2220は、ネットワーク接続されている装置2140とのローカルTCPセッションを確立とともにそれを管理するためのTCP状態マシン2222を有している。TCP状態マシン2222は、ローカルTCPセッション上のパケットストリームに対して、TCP状態マシン2212と同様に動作する。

図１３Ｂは、図１２及び１３Ａに示されているプロキシ2200を通過するパケットフローの例をブロック図で示している。図１３Ｂでは、ネットワークインターフェイスプロキシ2210は、TCPセッション2122内のパケットストリームを受信する。この実施例においては、パケットストリームは、３つのTCPデータペイロード1、2A、2B、2C及び3を含んでいる。これらのペイロードは、ネットワークインターフェイスプロキシ2210に到達したとき、様々なレートであったり、順序がばらばらであったり、IPフラグメント化されていたりする。例えば、ペイロード2は2A、2B、2Cへフラグメント化されかつ複製されていたりする。このネットワークインターフェイスプロキシ2210は、フラグメント化されたパケットを再構築し（フラグメント2A、2B、2CをTCPペイロード2に再構築し）かつTCPペイロードを再順序付けし、その後複製されたパケットをそれらが着き次第破棄する。この順序付けされかつ再構築されたTCPペイロードデータは、その後デバイスインターフェイスプロキシ2220へ提供される。そして、このペイロードデータは、ローカルTCPセッション2124内において均一のレートで転送される。TCPパケットの受信時にそれらが複合化や認証を必要とする場合、このネットワークインターフェイスプロキシ2210もまた、それらに対し、再構築と再順序付の前に暗号演算を行うことができる。このプロキシ2200による処理と均一転送により、ネットワーク接続されている装置2140は、均一の順序付けされたパケットストリームを受信することができ、それにより処理における当該装置の負担を減らすことができる。

図１４は、図１２、１３Ａ及び１３Ｂに示されているプロキシ2200を動作させる方法の実施例を示すフローチャートの例2300である。ブロック2310では、プロキシ2200は、ネットワーク2120上のTCPセッション及びネットワーク接続されている装置2140とのローカルセッションを確立する。このプロキシ2200は、遠隔TCPエンドポイントと三重ハンドシェイクを行ってTCPセッション2122を確立してもよい。このプロキシ2200は、その後、遠隔TCPセッション2122の確立に応じて、ネットワーク接続されている装置2140とのローカルセッション2124を確立することができる。このローカルセッション2124は、データ交換の待ち時間（latency）を短縮するためにTCPセッション2122と同時に確立されてもよい。他のやり方としては、このセッション2124は、SYNフラッドやその他のTCPベースの攻撃に関連する問題を避けるためにTCPセッション2122の確立後に確立されてもよい。いくつかの実施例においては、ローカルセッション2124は、プロキシ2200とネットワーク接続された装置2140間の三重ハンドシェイクを行って確立されるTCPセッションであってもよい。

次のブロック2320では、プロキシ2200は、ネットワーク2120上のTCPセッション2122内のパケットストリームを受信する。このプロキシ2200は、喪失または遅延したパケットに対してエラー回復を行ったり、TCPウィンドウのサイズ調整によるフローレート制御を行ったりすることで、TCPセッション2122を管理する。

次のブロック2330では、プロキシ2200は、パケットストリームからのデータをローカルセッションへ転送する（translate）。この転送には、データの順序付けとパケット化解除を行うことと、ローカルセッション2124内のネットワーク接続されている装置2140にこのデータを提供することと、が含まれる。前者の順序付けとパケット化解除は、例えば、ネットワークインターフェイスプロキシ2210で行われる。この順序付けには、受信した順序がばらばらなパケットを再順序付けすることや複製されたパケットを廃棄することが含まれることがある。一方、このパケット化解除には、例えば、IPフラグメント化されたパケットの再構築やIPSecヘッダーに従った暗号演算の実行などの必要とされるなんらかの追加処理を行うことが含まれることがある。このフローチャート2300は、ネットワーク2120からネットワーク接続されている装置2140へのデータ転送を示しているが、プロキシ2200は、逆方向にデータ転送することもできる。このプロキシ2200は、一般的には、ファイアーウォール内では提供されない動作(オペレーション)を提供する。しかし、このプロキシ2200は、TCPプロキシの動作に加え、他の従来のファイアーウォールの動作(オペレーション)を行うこともできる。

図１５は、図１３Ａと図１３Ｂに示されているネットワークインターフェイスプロキシ2210の実施例及びデバイスインターフェイスプロキシ2220の実施例に利用できるセマンティックプロセッサ2400をブロック図で示している。図１５に関して、セマンティックプロセッサ2400は、入力ポート2410を介して受信されるデータストリームをバッファするための入力バッファ2430と、出力ポート2420を介して送信されるデータストリームをバッファするための出力バッファ2440と、を有している。入力ポート2410及び出力ポート2420は、ネットワーク2120（図１２、１３Ａ及び１３Ｂのネットワーク）に対する物理インターフェイスを有してもよい。この物理インターフェイスの例としては、イーサーネット（登録商標）や、Fibre Channelや、802.11xや、ユニバーサル・シリアル・バス（USB）や、ファイヤーワイヤーや、SONETや、その他の物理レイヤーインターフェイスなどに対する光学的なあるいは電気的なもしくは無線によるドライバーとレシーバーのペアなどが挙げられる。

PCI-Xインターフェイス2480は、入力バッファ2430と、出力バッファ2440と、外部PCIバス2482に接続される。このPCIバス2482は、ディスクドライブや、追加のネットワークポート用のインターフェイスや、別のセマンティックプロセッサなどのようなその他のPCI可能な周辺機器と接続することができる。このPCI-Xインターフェイス2480は、PCIバス2482からのデータストリームまたはパケットを入力バッファ2430に送るとともに、PCIバス2482を介して出力バッファ2440からデータストリームまたはパケットを送る。

セマンティックプロセッサ2400は、入力バッファ2430内のパケットの処理を制御する直接実行パーサ（DXP）2450と、パケットのセグメントを処理したり、その他の演算を実行したりするためのセマンティック処理ユニット（SPU）2460を備えている。DXP 2450は、現在の入力シンボルまでの現在の入力フレームまたはパケットの解析に基づいた非終端の（及び場合によっては終端の）シンボルを有する内部パーサスタック（図示せず）を保持する。このパーサスタックの一番上に位置する単一のシンボル（または複数のシンボル）が終端シンボルである場合、DXP 2450は、入力ストリームの先頭の部分にあるデータDIを終端シンボルと比較し、作業を継続するためにそれらが一致することを期待する。このパーサスタックの一番上に位置するシンボルが非終端（NT）シンボルである場合、DXP 2450は非末端シンボルNT及び現在の入力データDIを用い、このスタックの文法生成物(grammar production)を拡張する。解析が継続している間、DXP 2450は、SPU 2460に、入力データのセグメントを処理するか、その他のオペレーションを実行するように指示する。

セマンティックプロセッサ2400は少なくとも３つのテーブルを使用する。SPU 2460に対するコードセグメントは、セマンティックコードテーブル2456内に格納される。複雑な文法生成規則は、生成規則テーブル（PRT）2454内に格納される。これらの生成規則を検索するための生成規則（PR）コード2453はパーサテーブル（PT）2452内に格納される。また、パーサテーブル2452内のPRコード2453は、DXP 2450が、所定の生成規則に対して、セマンティックコードテーブル2456からのコードセグメントがSPU 2460によってロードされ実行されるべきかを検出することをも可能にする。

パーサテーブル2452内の生成規則（PR）コード2453は、生成規則テーブル2454内の生成規則を指している。生成規則（PR）コードは、例えば行列（row-column）フォーマットまたはコンテント・アドレッサブル（content addressable）フォーマットで格納される。行列（row-column）フォーマットでは、テーブルの行は、内部パーサスタック2430の一番上にある非終端シンボルＮＴによりインデックス付けされ、テーブルの列は、入力の先頭にある単一（または複数）の入力データ値DIによりインデックス付けされる。コンテント・アドレッサブル（content addressable）フォーマットでは、非終端シンボルNTと単一（または複数）の入力データ値DIを連結したものが、パーサテーブル2452に対する入力をなす。セマンティックプロセッサ2400は、コンテント・アドレッサブル（content addressable）フォーマットを使用し（implement）、DXP 2450が、非終端シンボルNTを現在の入力データDI中の8バイトと連結させ、パーサテーブル2452に対する入力をなすようにすることが好ましい。他のやり方としては、パーサテーブル2452は、非終端シンボルNTとDXP 2450から受け取った現在の入力データDI中の8バイトを連結させてもよい。

入力バッファ2430は、DXP2450を通過するための追加のパスを要求するデータストリームをバッファするための再循環バッファ2432を備えている。DXP2450は、再循環バッファ2432からのデータストリームを、入力ポート2410やPCIバス2482を介して受け取ったデータストリームと同様に解析する。

セマンティックプロセッサ2400は、パケットのセグメントを格納したり、増大させたりするためのメモリサブシステム2470を備えている。パケットのヘッダーの解析に応じてDXP 2450に指示されると、SPU 2460は、TCPパケットを順序付けしたり、メモリサブシステム2470内のIPフラグメント化されたパケットを収集し、それらを再構築したりする。このメモリサブシステム2470は、SPU 2460に指示された場合、データストリームに対して暗号演算を実行してもよい。この暗号演算は、暗号化と、複合化と、認証を含む。メモリサブシステム2470内で再構築されるか処理されると、特別化されたNTシンボルを有するパケットまたはそれらのヘッダーは、DXP 2450でさらに解析するために再循環バッファ2432へ送られてもよい。

TCPのような状態依存型のプロトコルでは、パケットを受け取った順番は、このセマンティック処理構造により有効利用される意味を持つ。例えば、TCP SYNパケットを受け取ると、DXP 2450に、TCPセッションを確立しようとする試みがあることを示すこととなる。しかし、セッションがすでに確立している場合は、パケットの処理を完了するためにリソースを割り当てたり、このTCP SYNパケットの到着を知らせたり、対応する状態情報を保持したりする必要はもはやない。このため、TCPパケットは、構文的には正しいが、TCPセッションの状態に関しては順序がばらばらであるかもしれない。セマンティックプロセッサ2400は、これらのパケット順序の意味を理解し、その後、必要とされるTCP相互関係を管理しかつTCPセッションに対する状態情報を保持するために、図１３Ａの2212や2222のようなTCP状態マシンを作動させる。

図１６は、図１５に示されているセマンティックプロセッサ2400をTCP状態マシンとして動作させるための方法の実施例を説明するフローチャート2500の例を示している。図１６では、このセマンティックプロセッサ2400は、入力バッファ2430においてパケットを受け取り（ブロック2510）、当該パケットがTCPヘッダーを含んでいることを確認する（ブロック2520）。このセマンティックプロセッサ2400は、DXP 2450で受け取ったパケットの下位レベルヘッダーを解析することで、TCPヘッダーの存在を判定する。

次の判定ブロック2530では、セマンティックプロセッサ2400は、受け取ったTCPパケットがセマンティックプロセッサ2400により保持されるTCPセッションに対応するかどうかを判定する。メモリサブシステム2470は、動作中の各TCPセッションの情報をセマンティックプロセッサとともに保持する。この情報には、このセッションの現在の状態、パケットシーケンシング及びウィンドウのサイズ調整が含まれる。SPU 2460は、DXP 2450に指示されると、受け取ったTCPパケットに対応する保持されたTCPセッションの検索をメモリサブシステム2470内で実行する。

受け取ったTCPパケットに対応するTCPセッションがセマンティックプロセッサ2400内に保持されている場合、次の判定ブロック2540では、セマンティックプロセッサ2400は、このTCPパケットがTCPセッションの現在の状態と適合するかどうか判定する。SPU 2460は、保持されたTCPセッションの状態（例えば、一つまたは複数の非終端（NT）シンボルなど）をDXP 2450のために検索してもよい。これらのNTシンボルは、各々のTCP状態に対応する特別な生成規則を指し、DXP 2450によるパケットの解析方式を制御する。

例えば、TCPパケットがSYNパケットであり、それに対応するTCPセッションがすでに確立されている場合、このTCP SYNパケットは、TCPセッションの状態とは合致しない。そのため、このTCP SYNパケットは、（ブロック2580において）さらに解析されることなく廃棄される。また、このTCPパケットが、すでに確立されているTCPセッションに対応する（in）TCPデータパケットまたはTCP FINパケットである場合、次のブロック2550で、DXP 2450は、TCPセッションの状態に従ってこのパケットを解析する。

DXP 2450による解析が終了するとすぐに、SPU 2460は、このTCPパケットをネットワーク接続されている装置2140の宛先アドレスへ送るか、あるいはこのパケットのペイロード部分をローカルセッション2124内のネットワーク接続されている装置2140に設けられている別のセマンティックプロセッサ2400に送ることができる。このSPU 2460は、TCPセッションに対応するパケットをネットワーク接続されている装置2140に送る前に、複合化や認証を含むあらゆる再構築演算や暗号演算を実行する。SPU 2460による処理演算が完了された後、この処理されたパケットは、出力バッファ2440へ送られるか、PCI-Xインターフェイス2480を介してPCIバス2482へ送られる。

判定ブロック2530でTCPパケットに対応するTCPセッションがセマンティックプロセッサ2400内に保持されていない場合、次の判定ブロック2560では、セマンティックプロセッサ2400は、このTCPパケットが、セマンティックプロセッサ2400とのTCPセッションの確立を試みているSYNパケットであるかどうかを判定する。DXP 2450は、TCPヘッダー内のSYNフラグを解析することで、このTCPパケットがSYNパケットであるかどうかを判定する。

TCPパケットがSYNパケットでない場合、次のブロック2580では、セマンティックプロセッサ2400は、入力バッファ2430からパケットを廃棄する。DXP 2450に指示されれば、SPU 2460も入力バッファ2430からパケットを廃棄することができる。

TCPパケットがSYNパケットである場合、次のブロック2570では、セマンティックプロセッサ2400は、TCP SYNパケットに従って、TCPセッションを開始する（open）。DXP 2450に指示されると、SPU 2460は、SPU 2460にTCPセッションを開始させるセマンティックコードテーブル2456からのマイクロ命令を実行する。SPU2460は、TCP ACKメッセージをTCP SYNパケットにより識別できる送信元アドレスへ送り返すとともに、メモリサブシステム2470内のコンテキスト制御ブロックを、セッションの状態、パケットシーケンシング及びウィンドウのサイズ調整の情報などを含む情報の保持に割り当てることで、TCPセッションを開始（open）してもよい。その後実行プログラムは、ブロック2510へと戻り、そこで、セマンティックプロセッサ2400は、入力バッファ2430において続きのパケットを受け取り、DXP 2450は、この確立されたTCPセッションに対応する続きのパケットを解析する。

多くのデバイスは、ネットワーク上またはバックプレーン上で、ブロードキャストまたはポイント・トゥ・ポイントにより、パケットと呼ばれるデータの塊を用いて通信を行う。
パケットは、パケット内のデータの性質に関する情報を提供するヘッダーを持ち、またそれと同様に、通常はパケットのセグメント内に存在し、ペイロードと呼ばれるデータそのものを持つ。セマンティック処理は、ヘッダーの意味が必要に応じてペイロードの処理を行うのに使われるので、パケット処理に特に適している。

図１７は、セマンティックプロセッサ3010のブロック図である。このセマンティックプロセッサ3010は、入力ポート3012を介して受け取る入力ストリームをバッファするための入力バッファ3014と、直接実行パーサとも呼ばれる、入力バッファ3014内のパケットの処理を制御するためのパーサ3018と、パケットのセグメントの処理またはその他の演算の実行のためのセマンティック処理ユニット3016と、パケットのセグメントを格納したり、増大させたりする（augment）ためのメモリサブシステム3026と、を備えている。

パーサ3018は、現在の入力シンボルまでの現在のフレームまたはパケットの解析に基づいて、複数のシンボルを有する内部パーサスタック3032（図20に示されている）を保持する。例えば、パーサスタック3032の各シンボルは、現在の入力フレームまたはパケットに対する解析状態をパーサ3018に示すことができる。これらのシンボルは通常非終端シンボルであるが、このパーサスタック内には同様に終端シンボルが含まれることもある。

パーサスタック3032の一番上にあるシンボルが終端シンボルである場合、このパーサ3018は、入力ストリームの先頭にあるデータを終端シンボルと比較し、作業を続けるために一致を期待する。このデータはData Inとして識別され、通常は、数バイトからなる部分に取り込まれる。例えば、終端シンボルは1バイトのデータであるDIと比較されてもよい。パーサスタック3032の一番上にあるシンボルが非終端（NT）シンボルである場合、パーサ3018は、非終端シンボルNTと現在の入力データDIを用いて、生成規則コードメモリ3220内で一致を検出し、続いてスタック3032上の文法生成を拡張する追加の（more）非終端（NT）シンボルを生成することができる生成規則テーブル（PRT）3022内で一致を検出する。

さらに、非終端シンボルがある場合、解析が継続している間、パーサ3018はSPU 3016に入力ストリームのセグメントを処理するか、あるいはその他の演算を実行するように指示してもよい。入力ストリームのセグメントは、DI[n]として識別される次の「n」バイトのデータであってもよい。このパーサ3018は、セマンティックプロセッサ3010により処理されるデータをすべて受信し終わる前に、入力ストリーム内のデータを解析してもよい。例えば、データがパケット化されている場合、セマンティックプロセッサ3010は、パケットの全て（entire packet）が入力ポート3012において受信され終わる前に、パケットのヘッダーの解析を開始してもよい。

通常、セマンティックプロセッサ3010は、少なくとも３つのテーブルを使用する。SPU 3016に対するコードセグメントは、セマンティックコードテーブル（SCT）3024内に格納される。複雑な文法生成規則は、生成規則テーブル（PRT）3022内に格納される。これらの生成規則を検索するための生成規則（PR）コードは、パーサテーブル(PT)3020内に格納される。また、パーサテーブル3020内のPRコードは、所定の生成規則に対してSPU 3016がセマンティックコードテーブル3024からのコードセグメントをロードしかつ実行すべきかどうかを、パーサ3018が検出することを可能にする。

パーサテーブル3200内の生成規則（PR）コードは、生成規則テーブル3220内の生成規則を指す。PRコードは、行列（row-column）フォーマットやコンテント・アドレッサブル（content addressable）フォーマットなどのやり方で格納される。行列（row-column）フォーマットでは、テーブル3020の行は、図２０の内部パーサスタック3032の一番上にある非終端シンボルＮＴによりインデックス付けされ、このテーブルの列は、入力バッファ3012内の入力データストリームの先頭にある単一（または複数）の入力データ値DIによりインデックス付けされる。コンテント・アドレッサブル（content addressable）フォーマットでは、非終端シンボルNTと単一（または複数）の入力データ値DIを連結したものが、このテーブル3020に対する入力をなす。セマンティックプロセッサ3010は通常、コンテント・アドレッサブル（content addressable）フォーマットを使用（implement）する。この場合、パーサ3018は、非終端シンボルNTを現在の入力データDI中の8バイトと連結させ、該パーサテーブル3020に対する入力を提供する。他のやり方としては、パーサテーブル3020は、非終端シンボルNTとパーサ3018内に格納されている前の入力データDI中の8バイトを連結させてもよい。

なお、図１７に示されているよりも多くの構成要素を含む実施例もあるということに留意しなければならない。しかし、実施例を説明する目的及び実施例の適用という見地からすると、これらの構成要素は周辺機器にすぎない。

まず、本発明のいくつかの実施例に関する一般的なパーサの演算について、図１７−２０0に基づいて説明する。図１８は、パーサテーブル3020の一つの実行可能性がある実施例を示している。パーサテーブル3020は、生成規則（PR）コードメモリ3220で構成される。PRコードメモリ3200は、生成規則テーブル（PRT）3022内に格納されている対応する生成規則にアクセスするために用いられる多数のPRコードを保持している。実際には、生成規則コードメモリ3200内に、多くの異なる文法に対するコードが同時に存在することができる。特定の検索の実行において必要とされない限り、現在の入力値DI[n]（nはバイトで選択された一致幅）と連結される上述した入力値（例えば非終端（NT）シンボル）は、PRコードメモリ3200内でなんらかの特定の順番で割り当てられる必要はない。

ある実施例では、パーサテーブル3200は、図１７に示しているパーサ3018からデータ値DI[n]とNTシンボルを受け取るアドレッサー3202も備えている。アドレッサー3202は、NTシンボルをデータ値DI[n]と連結させ、この連結した値をPRコードメモリ3200へと送る。他のやり方としては、パーサ3018は、NTシンボルとデータ値DI[n]を、パーサテーブル3020へ送る前に連結させてもよい。

概念的には、生成規則コードメモリ3200の構造を、NTコードとデータ値の特有な組み合わせのそれぞれに対して一つのPRコードを持ったマトリックスとして見ることが有用であることが多いが、本発明の実施例に関してはそのようには限定されない。異なるアプリケーションに対しては、異なるタイプのメモリ及びメモリ構成が適当である場合もある。

例えば、ある実施例では、パーサテーブル3020はコンテント・アドレッサブル・メモリ（CAM）として実施され、アドレッサー3202は、CAMがPRT3022内の生成規則に対応するPRコードを検索するための鍵としてNTコード及び入力データ値DI[n]を使用する。CAMは、TCAMエントリー（entry）に属する三重（ternary）CAM（TCAM）であるのが好ましい。各TCAMエントリー（entry）は、NTコードとDI[n]一致値（DI[n] match value）を含む。各NTコードは、複数のTCAMエントリーを保持することができる。DI[n] 一致値（DI[n] match value）の各ビットは、「0」、「1」または「X」に設定される。この「X」は「無視（Don't Care）」を表す。この機能により、PRコードは、パーサテーブル3020が一致を見つけるために、数（certain）ビットまたは数（certain）バイトのDI[n]とコード化されたパターンとが一致することだけを必要とするようになる。例えば、TCAMの一行は、宛先IPアドレスフィールドに対するNTコードNT_IPを有しており、その後にセマンティックプロセッサ3010を組み込んでいるデバイスに対応する宛先IPアドレスを表す4バイトが続く。このTCAM行の残りの４バイトは「無視（Don't Care）」に設定される。こうして、NT_IP及び8バイトのDI[8]がパーサテーブル3020に提示された場合、DI[8]の内の最初の4バイトが正しいIPアドレスを含んでいれば、DI[8]の残りの4バイトが何を含んでいても一致が生じることとなる。

TCAMは、「無視（Don't Care）」機能を採用しており、一つのNTに対し複数のTCAMエントリーがあってよいので、TCAMは所定のNTコード及びDI[n]一致値に対して、複数の一致する（matching）TCAMエントリーを見つけることができる。TCAMは、そのハードウェア全体でこれらの一致（match）に優先順位をつけ（prioritize）、そこで最優先された一致（match）のみ出力する。さらに、NTコード及びDI[n] 一致値（DI[n] match value）がTCAMに提示された場合、TCAMは、並列処理的にTCAMエントリー（entry）毎に受け取ったNTコード及びDI[n]一致値と一致させることを試みる。そのため、TCAMは、セマンティックプロセッサ3010の一回のクロックサイクルにおいて、パーサテーブル3020内に一致が見つかったかどうかを判定する機能を持つ。

このアーキテクチャ（構造）の他の見方には、「可変予見（variable look-ahead）」パーサとして見る見方がある。TCAMには固定データ入力セグメント（例えば8バイト）が入力されるが、TCAMのコード化により、続く生成規則が現在の8バイトの入力のいずれかの部分に基づいて生成されることを可能にする。入力ストリームの先頭の部分にある現在の8バイト内のいずれかの部分にあるちょうど（only）１ビットまたは１バイトが現在の規則に対して関係を持つ場合、TCAMエントリー（entry）は、照合作業の間、残りを無視するようにコード化してもよい。本質的に、現在の「シンボル」は、所定の生成規則に対して、入力ストリームの先頭の部分の64ビットの何らかの組み合わせで定義することができる。一般的に、賢く（intelligent）コード化を行うことで、解析サイクルの回数と、NTコード数と、テーブルエントリーの数は、所定の解析タスクに関して減らすことができる。

パーサテーブル3020内のTCAMは、上述したように、NT及びDI[n]と一致するTCAMエントリー3204に対応するPRコードを生成する。PRコードはパーサ3018に送り返されるか、直接PRテーブル3022に送り返されるか、またはその両方に送り返されてもよい。ある実施例では、PRコードは、一致状態を作り出すTCAMエントリーの行インデックスとなる。

NT及びDI[n]と一致するTCAMエントリー3204が存在しない場合、いくつかのオプションが存在する。ある実施例では、PRコードは、「有効（valid）」ビットを伴う。このビットは、現在の入力と一致するTCAMエントリーが存在しない場合は設定されないままとなる。別の実施例では、パーサテーブル3020は、このパーサテーブルへ供給されるNTに対応するデフォルトPRコードを構築する。正当なビットやデフォルトのPRコードの用途は、以下において図１９と関連して説明する。

パーサテーブル3020は、パーサ3018及びSPU 3016が一つの回路に一体に組み込まれる場合、内蔵して配置されるか、外部に配置されるか、またはその両方で配置される。例えば、内蔵されたスタティックRAM（SRAM）またはTCAMは、パーサテーブル3020として動作可能である。他のやり方として、外部DRAMストレージまたはTCAMストレージがパーサテーブル3020を格納することもできる。この場合、パーサテーブル3020は、外部メモリに対するメモリ制御装置として動作するか、外部メモリに対するメモリ制御装置と通信するアドレッサー3202を備えている。ある実施例では、パーサテーブル3020は、パーサテーブル3020の一部を保持することができる内蔵キャッシュを備えている外部メモリ内に配置することができる。

図１９は、生成規則テーブル3022の実行可能性のある実施例を示している。PRテーブル3022は、生成規則メモリ3220と、一致全パーサエントリーテーブル（Match All Parser entries Table: MAPT）メモリ3228と、アドレッサー3222と、を備えている。

ある実施例では、アドレッサー3222は、パーサ3018かパーサテーブル3020のいずれか一方からPRコードを受け取り、パーサ3018からNTシンボルを受け取る。好ましくは、受け取ったNTシンボルは、パーサテーブル3020へ送られるNTシンボルと同一のNTシンボルであり、受け取ったPRコードを配置するのに用いられる。アドレッサー3222は、これらの受け取ったPRコード及びNTシンボルを使用して対応する生成規則及びデフォルト生成規則にそれぞれアクセスする。ある実施例では、受け取ったPRコードは生成規則を生成規則メモリ3220内にアドレスする。そして、受け取ったNTコードはデフォルト生成規則をMAPT 3228内にアドレスする。アドレッサー3222はいくつかの実施例においては必ずしも必要ではないが、使用される場合は、パーサ3018の一部やPRT 3022の一部として設けることができ、また中間の（intermediate）機能ブロックとして設けることができる。例えば、パーサテーブル3020またはパーサ3018がアドレスを直接作る場合、アドレッサーは必要とされない。

生成規則メモリ3220は、３つのデータセグメントを含む生成規則3224を格納する。これらのデータセグメントは、シンボルセグメントと、SPUエントリーポイント（SEP）セグメントと、スキップバイトセグメントと、を含む。これらのセグメントは、長さ固定のセグメントでも長さ可変のセグメントであってもよく、ヌル終端化されている（null-terminal）のが好ましい。シンボルセグメントは、図２０に示されているパーサスタック3032上へ転送される（プッシュされる）終端シンボルか非終端シンボルを有している。SEPセグメントは、データセグメントの処理中にSPU 3016によって使用されるSPUエントリーポイント（SEP）を有している。スキップバイトセグメントは、入力バッファ3014により自身のバッファポインターをインクリメントし、入力ストリームの処理を進めるために使用されるスキップバイトデータを有している。また、生成規則の処理において有用なその他の情報も生成規則3224の一部として格納することができる。

MAPT 3228はデフォルト生成規則3226を格納する。この生成規則は、本実施例では、生成規則メモリ3220内のPRと同じ構造を持ち、パーサテーブルの検索中にPRコードが見つからない場合にアクセスされる。

生成規則メモリ3220とMAPT 3228は2つの別々のメモリブロックとして図示されているが、本発明はこれに限定されるわけではない。ある実施例では、生成規則メモリ3220及びMAPT 3228は、内蔵SRAMとして実施され、各生成規則及び各デフォルト生成規則は複数のヌル終端化されたセグメントを保持する。

生成規則及びデフォルトの生成規則は様々な長さを持つことがあるので、それらの個別のメモリ3220及び3228内へと簡単にインデックス付けして入れることを可能にするアプローチを取るのが好ましい。あるアプローチでは、各PRは、固定最大数のシンボルと、SEPと、スキップバイトフィールドのような補助のデータと、を含むことができる固定長さを持つ。所定のPRコードが、許容された最大数のシンボルまたはSEPを必要としない場合、シーケンスは、NULLシンボルまたはSEPで終端される。所定のPRが最大数以上の数を必要とする場合、それは分割して二つのPRへ入れることができる。その後、これらのPRは、第一のPRにゼロのスキップバイト値を出させるとともに、続く解析サイクルにおいて第二のPRがアクセスさせられるスタックへNTを転送（プッシュ）することで、アクセスされる。このアプローチでは、TCAMから得られる行アドレスがPRテーブル3022内の対応する生成規則の行アドレスと一致するように、TCAMエントリーとPRテーブルエントリーとの間で一対一の対応を維持することができる。

PRT 3022のMAPT 3228セクションは、NTコードの代わりにPRコードを使用することを除いて同様にインデックス化される。例えば、PRコードに有効なビットが設定されていない場合、アドレッサー3222は、現在のNTに対応する行をPRテーブルのアドレスとして選択することができる。例えば、２５６個のNTが許容された場合、MAPT 3228は、各々がNTの一つに対してインデックス化された２５６個の入力（エントリー）を含むことができる。パーサテーブル3020が現在のNT及びデータ入力DI[n]に対応する入力（エントリー）を一つも持たない場合、MAPT 3228からの対応するデフォルト生成規則がアクセスされる。

例として再び宛先IPアドレスを考えると、パーサテーブル3020は、適切な解析サイクルの間に期待される二つの宛先アドレスの内一つに応答するように構成することができる。その他のすべての宛先アドレスに対しては、パーサテーブルエントリーは見つからないであろう。アドレッサー3222はその後、パーサ3018かSPU 3016もしくはその両方に現在のパケットを関係のないパケットとして消去するように命令する現在のNTに対するデフォルト規則を検索するであろう。

上述した生成規則テーブルをインデックス化するアプローチは、比較的簡単でかつすばやいルールアクセスを提供するが、その他のインデックス化スキームも実行可能性がある。複数の可変長さPRテーブルエントリーに関して、PRコードを演算的に制御して、生成規則の物理的メモリの開始アドレスを決定することができる（これは、例えば生成規則が拡張された長さでソートされ、その後規則がソートされた位置に従ってPRコードが割り当てられれば、実行可能である）。その他のアプローチでは、中間ポインターテーブルを使用することで、PRT 3022内で生成規則のアドレスをPRコードから決めたり、MAPT 3228内のデフォルト生成規則のアドレスをNTシンボルから決めることができる。

図２０は、パーサ3018の一つの実行可能性のある具体例のブロック図を示している。パーサ制御有限状態マシン（FSM）3030は、図２０に示すその他の論理ブロックからの入力に基づいて、全体的なパーサ3018の動作（オペレーション）を制御し、順序付ける。パーサスタック3032は、パーサ3018により実行されるシンボルを格納する。入力ストリームシーケンス制御部3028は、パーサ3018により処理されることとなる入力データ値を入力バッファ3014から読み出す（検索する）。SPUインターフェイス3034はパーサ3018に代わって、タスクをSPU3016へと送る。これらのブロックの特定の機能は、以下でさらに詳細に説明する。

図１７〜図２０に示すブロック図の基本的な動作（オペレーション）について、以下において、図２１に示すデータストリーム解析の実施方式のフローチャートに基づいて説明する。ブロック3040では、セマンティックプロセッサ3010は、パケットが入力ポート3012を介して入力バッファ3014において受信されるのを待つ。

パケットが入力バッファ3014において受信されている場合、入力バッファ3014は、パーサ3018にポートID信号を送る。この信号は、ブロック3042で、NTシンボルとしてパーサスタック3032上へ転送（プッシュ）される。このポートID信号は、パーサ 3018に、パケットが入力バッファ3014に到着したことを告知する。ある実施例では、ポートID信号は、入力ストリームシーケンス制御部3028で受信され、FSM 3030へと転送される。この信号は、パーサスタック3032上へ転送（プッシュ）される。1ビットのステータスフラグは、ポートIDに先行させて送られるか、ポートIDと並列な関係で送られる。この1ビットのステータスフラグは、ポートIDをNTシンボルで表す。

次のブロック3044では、パーサ3018は、入力バッファ3014からNバイトの入力ストリームデータを受信する。これは、パーサ3018がさらなる入力を待っておらず、パーサスタック3032の一番上のシンボルがスタックの一番下のシンボルでないと判定した後実行される。パーサ3018は、入力ストリームシーケンス制御部3028と入力バッファ3014間のデータ／制御信号を介してデータをリクエストし、それを受信する。

ブロック3046では、パーサスタック3032上のシンボルが終端シンボルとNTシンボルのどちらであるかを判定する。この判定は、FSM 3030がパーサスタック3032上のシンボルのステータスフラグを読み込むことにより実行される。

ブロック3046でこのシンボルが終端シンボルであると判定されると、ブロック3048で、パーサ3018は、受信したNバイトのデータの次のバイトとTシンボルの間に一致があるかどうか確認する。FSM 3030は、入力ストリームシーケンス制御部3028により受信されたデータの次のバイトをパーサスタック3032上のTシンボルと比較することで、一致があるかどうか確認する。確認が完了した後、FSM 3030は、スタックポインターをデクリメントすることにより、Tシンボルをパーサスタック3032から取り除く（ポップする）。

ブロック3046及び3048で一致がなかった場合、NTシンボルの一致と終端シンボルの一致がないので、現在のデータセグメントの残りセグメントが状況次第で解析不能であると推測される。ブロック3050では、パーサ3018は、パーサスタック3032をリセットし、SEPを起動して入力バッファ3014から現在のパケットの残りを取り除く。ある実施例では、FSM 3030は、残りのシンボルを取り除く（ポップオフする）か、スタックの一番上のポインタがスタックの一番下のシンボルを指し示すように設定することにより（こちらの方が好ましい）、パーサスタック3032をリセットする。パーサ3018は、SPUインターフェイス3034を介してSPU 3016にコマンドを送ることにより、SEPを起動する。このコマンドは、SPU 3016にSCT 3024からマイクロ命令をロードすることを要求する。このマイクロ命令は実行されると、SPU 3016が、解析できないデータセグメントの残りを入力バッファ3014から取り除くことを可能にする。実行プログラムは、その後、ブロック3040へと戻る。

なお、データストリーム内の解析できない入力の例のすべてが、現在のデータセグメントの解析の中止をもたらす可能性がある訳ではない。例えば、パーサは、直接文法を用いることで、通常のヘッダーオプションを扱うように構成されてもよい。他のやり方としては、解析のためにヘッダーオプションをSPUへと送るデフォルト文法規則を使用することで、あまり一般的ではないもしくは扱いにくいヘッダーオプションに対処することができる。

ブロック3046へ戻ると、一致があった場合実行プログラムはブロック3044へと戻り、そこで、パーサ3018が入力バッファ3014からさらなる入力ストリームデータをリクエストし、それを受信する。ある実施例では、パーサ3018は、Tシンボルの一致があった場合、１バイトの入力ストリームデータをリクエストし、それを受信し、入力シンボルが一つ消費される分DIバッファを補充する。

ブロック3050でこのシンボルがNTシンボルであると判定されると、パーサ3018は、パーサスタック3032から受け取ったNTシンボルと入力ストリームシーケンス制御部3028内の受信したNバイトDI[N]とをパーサテーブル3020へ送る。そこで、パーサテーブル3020は、前述したように、一致があるかどうか確認する。図示した実施例では、パーサテーブル3020は、受信したNバイトとNTシンボルを連結させる。別のやり方としては、受信したNバイトとNTシンボルを、パーサテーブル3020へ送られる前に連結させてもよい。受信したNバイトは、SPUインターフェイス3034とパーサテーブル3020の両方へと同時に送られる。また、NTシンボルは、パーサテーブル3020とPRT 3022の両方へと同時に送られる。一致確認が完了したあと、FSM 3030は、パーサスタック3032からNTシンボルを取り除く（ポップする）。これはスタックポインターをデクリメントすることにより実行される場合がある。

ブロック3050で一致がある場合、ブロック3052においてそのシンボルがデバッグシンボルであるかどうか判定される。ブロック3052でこのシンボルがデバッグシンボルであった場合、プロセスは、図２２に示されているようなデバッグプロセスへ移行する。ブロック3052でこのシンボルがデバッグシンボルでない場合、ブロック3056で、生成規則コードの一致が判定される。これにより、生成規則テーブル3022から一致した生成規則を提供する。他のやり方としては、PRコードは、パーサ3018を介してパーサテーブル3200からPRT3250へ送ってもよい。

ブロック3056でNTシンボルが生成規則コードの一致を持たない場合、パーサ3018は、ブロック3058で、受信したNTシンボルを用いて、PRT 3022内でデフォルト生成規則を検索する。ある実施例では、デフォルト生成規則はPRT 3022内に配置されたMAPT 3228メモリ内で検索される。その他のやり方としては、MAPT 3228メモリは、PRT 3022以外のメモリブロック内に配置されてもよい。ある実施例では、デフォルト生成規則は、パーサに、ルールを持たないシンボルに遭遇したことを認識させデバッグモードに移行させるデバッグ規則であってもよい。

ある実施例では、PRT 3022がPRコードを受け取ると、ブロック3060で、PRT 3022は、パーサ3018に見つかった生成規則とデフォルト生成規則のどちらか一方に対応するPRのみを返す。その他のやり方としては、ブロック3060で、PRとデフォルトPRがともにパーサ3018へ送り返され、パーサ3018がどちらを使うか決定してもよい。

ブロック3062で、パーサ3018はPRT 3250から受信した規則を処理する。パーサ3018に受信される規則は、生成規則とデフォルト生成規則のどちらでもよい。ある実施例では、FSM 3030は、規則を以下の３つのセグメントに分割する。ここで言う３つのセグメントとは、シンボルセグメントと、SEPセグメントと、スキップバイトセグメントのことである。規則の各セグメントは、簡単で正確な分割ができるように、固定された長さを持つかあるいはヌル終端化されているのが好ましい。

図示している実施例では、FSM 3030はTシンボルか、またはNTシンボルか、あるいはその両方をパーサスタック3032に送る（プッシュする）。これらのシンボルは、生成規則のシンボルセグメント内に含まれるものである。FSM 3030は、生成規則のSEPセグメント内に含まれるSEPを、SPUインターフェイス3034に送る。各SEPは、SCT 3024内に配置されたマイクロ命令に対するアドレスを備えている。これらのSEPを受け取るとすぐに、SPUインターフェイス3034は、SEPにより指定されたマイクロ命令を取り込み、それらを実行するように、SPU3016を割り当てる。多くの場合、SPUにより完了されるタスクはさらなる入力データを必要としないので、SPUインターフェイス3034はまた、現在のDI[N]値をSPU 3016へと送る。他のやり方としては、SPUインターフェイス3034は、SPU 3016により実行されるマイクロ命令を取り込み、SPUを割り当てるのと同時にそれらのマイクロ命令をSPU 3016へ送る。

FSM 3030は、入力ストリームシーケンス制御部3028を介して、生成規則のスキップバイトセグメントを入力バッファ3014に送る。入力バッファ3014は、スキップバイトデータを使用して、入力ストリーム内の配置を指し示す自身のバッファポインターをインクリメントする。そのため、各解析サイクルは、0から8までの範囲ならば何個の入力シンボルでも消費することができる。

パーサ3018がPRT 3022から受信した規則を処理したあと、ブロック3064で、パーサスタック3032上の次のシンボルはスタックの一番下のシンボルであるかどうか判定される。言い換えると、パーサスタック 3032がさらなる解析を必要としているのかどうか判定される。ブロック 3064で、パーサ 3018は、選択されたバッファ内の入力データがさらなる解析を必要としているかどうか判定する。ある実施例では、パーサスタック3032のスタックポインターが、スタックの一番下のシンボル以外のシンボルを指し示している場合、入力バッファ 3014内の入力データはさらなる解析を必要とする。いくつかの実施例では、パーサスタック3032の（for）スタックポインターが、スタックの一番下のシンボルを指し示している場合、FSM 3030は、空スタック信号(stack empty signal: SE)を受信する。

ブロック3064で、選択されたバッファ内の入力データがさらに解析されることを必要としない場合（通常パーサスタックの一番上の特定のNTシンボルによって判定される）、実行プログラムはブロック 3040へと戻る。選択されたバッファ内の入力バッファが解析される必要がある場合、パーサ3018は、ブロック3066で、選択されたバッファ内でこの入力データの解析を継続できるかどうか判定する。ある実施例では、まだ解析が必要であっても、いくつかの理由により所定のバッファからの入力データで解析を中止することがある。この理由としては、未解決または実行中のSPU演算によるものや、入力データの不足や、その他の入力バッファが解析において優先権を持っていること、などが挙げられる。パーサ 3018は、SEPディスパッチャ3036により、ステータス信号を介してSPU処理の遅れについて告知される。また、パーサ 3018は、FSM 3030内に格納されているステータス値により、優先して解析するタスクについて告知される。

パーサ3018が現在の解析用コンテキストで解析を継続することができる場合、実行プログラムはブロック3044へと戻り、そこで、パーサ3018は、選択されたバッファ内の入力データからのNバイト以下のデータをリクエストし、それを受信する。

ブロック3066でパーサ 3018が解析を継続することができない場合、ブロック3068では、パーサ 3018は選択されたパーサスタックを格納し、続いて、選択されたパーサスタックと、選択された入力バッファと、を選択解除する。FSM 3030から切り替え制御信号を受信すると、入力ストリームシーケンス制御部3028は、入力ポート（入力ポートブロック）3012の中で受信した入力データを有する他のポート選択することで、入力ポート3012の中のある入力ポートを選択解除する。入力ポート3012の中の選択されたポートとパーサスタック3032内で選択されたスタックは、解析されるのを待っている新しいデータを有する別のポートがない場合、動作中のままとなることがある。

典型的な解析動作（オペレーション）を見てきたので、デバッグ動作（オペレーション）を指定する（designate）NTシンボルがどのように役立つのかを理解することができる。パーサ3018が図２１のブロック3054で示されているようなデバッグNTシンボルに遭遇すると、このパーサはデバッグ状態となる。デバッグシンボルは明らかなデバッグシンボルであったり、解析されているデータ中にあり、それまで不明なシンボルであったりしてもよいことを留意しなければいけない。こられはともにデバッグシンボルと呼ぶことにする。例えば、対応する一致がないどんなNTシンボルでも、パーサをデバッグ状態にすることができる。この最後の実施例では、図２１のデフォルト生成規則はデバッグ規則である。他の場合には、予期されるシンボルまたはそれに対する規則のないシンボルに遭遇すると、パーサはデバッグ状態となる。不明なシンボルに対するデフォルト生成規則は、デバッグ生成規則となる。

図２２では、パーサは、ブロック3070においてデバッグ状態となる。このデバッグ状態は、パーサがデバッグ状態となった後かまたはなると同時にエラーメッセージを発する。このエラーメッセージは、SPUディスパッチャに送られるインタラプトであってもよい。このインタラプトは、エラー状態またはインタラプトが起こり、SPUがこの状況に対処する必要があることを示す。ディスパッチャはその後、このエラーに対処するためにSPUを起動する。

こうしてエラーに対処することには、パーサをデバッグ状態にさせる状況に関連する情報を収集することも含まれることがある。この情報は、CAM内でシンボルを検索するのに用いられる最終キーを含むことがある。この場合、最終キーは、上述したようにNバイトのデータと連結された最終NTシンボルであってもよい。この情報は、このシンボルと、現在処理されているパケットの識別子と、FSMの状態と、システム内で用いられているエラー及びインタラプトのレジスタの何らかの状態と、より前に読み出される最終生成規則コードを含むこともある。さらに、このデバッグは、SPUによって検査したり、観察するために、パーサにパーサスタックのコンテンツを保存させてもよい。

情報はいったん収集されると、格納されるか、ユーザーに提示されるか、メーカーに送り返される。例えば、現在のパーサが実験室で動作中である場合、パーサは、後でユーザーが確認するためにエラーログを保存するか、ユーザーのディスプレー上にエラーメッセージを作成する。これにより、プログラマーは、パーサがパーサをデバッグ状態に入らせるどのような原因に遭遇したのかを判定し、その後、PRT 3022内のこの状況のための規則を供給することができる。この規則には、パーサが設置されるテストステーション（例えばコンピューターワークステーション）を介してアクセス可能である。

その他のやり方としては、ログは顧客側（customer site）で動作中のデバイスにより生成され、その後、このログは、サービス提供者によりメンテナンス中にアクセスされる。また別のやり方では、ログまたはエラーメッセージは、メーカーが問題を解決（remedy）できるようにするために顧客側からメーカーに送り返されてもよい。

このやり方では、メーカーが、パケットの解析に用いられる文法を識別し、それを拡張する能力は向上する。デバッグ状態によりシステムは、パーサが遭遇して解析することができなかった状況に関連するデータを収集することができる。このデータは、文法に加えられるべき新しい生成規則コードを必要とする新しいヘッダーまたは以前には不明だったヘッダーが存在するかどうかを判定するのに用いることができる。

図２３は、本発明の実施例に係るセマンティックプロセッサ4100のブロック図を示している。このセマンティックプロセッサ4100は、入力ポート4120を介して受信するパケットデータストリーム（例えば入力ストリーム）のバッファ用の入力バッファ4140と、入力バッファ4140において受信するパケットデータの処理を制御する直接実行パーサ（DXP）4180と、再循環バッファ4160と、パケットのセグメントを処理したり、その他の演算を実行したりするためのセマンティック処理ユニット（SPU）4200と、パケットのセグメントを格納したり、増大させたりするためのメモリサブシステム4240と、SPU4200から受信したデータストリーム（例えば、出力ストリーム）をバッファするための出力バッファ4750と、を備えている。

DXP 4180は、現在のシンボルまでの現在のフレームの解析に基づいて、終端シンボル及び非終端シンボルを有する内部パーサスタック（図示せず）を保持する。例えば、内部パーサスタック上の各シンボルは、DXP 4180に現在の入力フレームまたはパケットの解析状態を示すことができる。パーサスタックの一番上にあるシンボルが終端シンボルである場合、DXP 4180は、入力ストリームの先頭にあるデータを終端シンボルと比較し、作業を続けるために一致を期待する。パーサスタックの一番上にあるシンボルが非終端シンボルである場合、DXP 4180は、この非終端シンボル及び現在の入力データを使用しスタック上の文法生成物を拡大する。解析が続いている間、DXP 4180は、SPU 4200に、入力ストリームのセグメントを処理するか、その他の動作（オペレーション）を実行するように指示を送る。DXP 4180は、セマンティックプロセッサ4100により処理されるデータをすべて受信する前に、入力ストリーム内のデータを解析してもよい。例えば、データがパケット化されている場合、セマンティックプロセッサ4100は、パケット全体が入力ポート4120において受信される前に、パケットのヘッダーの解析を開始してもよい。

セマンティックプロセッサ 4100は、少なくとも３つのテーブルを使用する。SPU 4200に対するコードセグメントは、セマンティックコードテーブル（SCT）4150内に格納される。複雑な文法生成規則は、生成規則テーブル（PRT）4190内に格納される。これらの生成規則を検索するための生成規則コードはパーサテーブル（PT）4170内に格納される。パーサテーブル4170内の生成規則コードは、DXP 4180が、所定の生成規則に対して、SCT 4150からのコードセグメントがSPU 4200によってロードされ実行されるべきかを検出することを可能にする。

本発明のいくつかの実施例では、図２３に示されているより多くの構成要素を含んでいるが、これらの構成要素は、あらゆるシステムやソフトウェアの実施例で現れる可能性がある。従って、より複雑な実施例を扱う前に、図２３に示されているセマンティックプロセッサ4100内のパケットフローの説明を行うことにする。

図２４は、受信したパケットの、図２３に示されているセマンティックプロセッサ 4100内での処理に関するフローチャート4300である。このフローチャート4300は、本発明の実施方法を説明するのに使用される。

ブロック4310では、パケットは、入力ポート4120を介して、入力バッファ4140において受信される。次のブロック 4320では、DXP 4180は、入力バッファ4140のパケットのヘッダーの解析を開始する。判定ブロック4330では、DXP 4180が完全にヘッダーを解析することができたか判定される。パケットが、パケットのペイロードの処理を可能にするために追加の操作か追加のパケットを必要としない場合、DXP 4180はヘッダーを完全に解析する。パケットが、パケットのペイロードの処理を可能にするために追加の操作か追加のパケットを必要とする場合、DXP 4180はヘッダーの解析をやめる。

DXP 4180が完全にヘッダーの解析を行うことができた場合、次のブロック4370では、DXP 4180はSPU 4200内のルーチンを呼び出し、パケットのペイロードを処理する。その後、セマンティックプロセッサ4100は、次のパケットが入力ポート4120を介して、入力バッファ4140において受信されるのを待つ。

DXP 4180がヘッダーの解析をやめなければならない場合、次のブロック4340では、DXP 4180は、SPU 4200内のルーチンを呼び出して、パケットを制御するか、追加のパケットを待つ。制御が完了するかあるいは追加のパケットが到着するとすぐに、SPU 4200は調整された（解決された）パケットを作成する。

次のブロック4350では、SPU 4200は調整された（解決された）パケット（またはその一部）を再循環バッファ4160に書き込む。これは、直接メモリを有する再循環バッファ 4160がメモリサブシステム4240に対してアクセスすることを可能にすることにより達成することができる。もしくは、SPU 4200に、メモリサブシステム4240から調節されたパケットを読み込ませ、その後再循環バッファ4160に調節されたパケットを書き込ませることによって達成することができる。その他のやり方として、SPU 4200内での処理時間を節約する（短くする）ためには、完全に調節されたパケットの代わりに、特別なヘッダーが再循環バッファ4160に書き込まれてもよい。この特別なヘッダーは、完全なパケットをメモリサブシステム4240から転送すること必要とせずに、SPU 4200に、調節されたパケットを処理するように指示する。

次のブロック4360では、DXP 4180は、再循環バッファ4160内のデータのヘッダーの解析を開始する。その後、実行プログラムはブロック4330へと戻り、そこで、DXP 4180がヘッダーを完全に解析することができたかどうか判定される。DXP 4180がヘッダーを完全に解析することができた場合、その後次のブロック4370では、DXP 4180はSPU 4200内のルーチンを呼び出し、パケットのペイロードを処理する。その後、セマンティックプロセッサ4100は、新しいパケットが、入力ポート4120を介して入力バッファ4140において受信されるのを待つ。

DXP 4180がヘッダーの解析をやめなければならない場合、実行プログラムはブロック 4340へと戻り、そこで、DXP 4180が、SPU 4200内のルーチンを呼び出し、パケットを制御するか、追加のパケットを待ち、その後、調節されたパケットを作成する。SPU 4200は、その後、調節されたパケットを再循環バッファ 4160に書き込む。そして、DXP 4180は、再循環バッファ 4160内のパケットのヘッダーの解析を開始する。

図２５は、セマンティックプロセッサ4400の他の実施例を示している。セマンティックプロセッサ4400はメモリサブシステム4240を備えている。このメモリサブシステム4240は、以下の要素を含む。
ハッシュ機能（ハッシング関数）またはコンテント・アドレッサブル・メモリ（CAM）検索を介して動的ランダムアクセスメモリ（DRAM）4480内のデータにアクセスするためのアレイマシンコンテキストデータメモリ（AMCD）4430
データの暗号化や、複合化や、認証のための暗号処理ブロック4440
DRAM 4480へコンテキスト制御ブロックをキャッシュするとともに、DRAM 4480からコンテキスト制御ブロックをキャッシュするためのコンテキスト制御ブロック（CCB）キャッシュ 4450
基本演算において使用されるデータをキャッシュするための通常キャッシュ4460
データストリームがDRAM 4480へと書き込まれている間と、データストリームがDRAM 4480から書き込まれている間に、これらのデータストリームをキャッシュするためのストリーミングキャッシュ 4470
このコンテキスト制御ブロックキャッシュ 4450は、ソフトウェア制御のキャッシュであるのが好ましい。すなわち、いつキャッシュラインが使用され、いつ使用されないのかをSPU 4410が決定するのが好ましい。

SPU 4410は、AMCD 4430と、暗号処理ブロック4440と、CCBキャッシュ4450と、通常キャッシュ 4460と、ストリーミングキャッシュ4470と、接続されている。メモリサブシステム4240内のデータのセグメントか、入力バッファ4120（図２３）で受信されたデータのセグメントを処理するようにDXP 4180に信号で伝えられると、SPU 4410は、セマンティックコードテーブル（SCT）4150からマイクロ命令をロードする。このロードされたマイクロ命令は、その後SPU 4410内で実行され、パケットのセグメントはそれに従って処理される。

図２６は、受信したインターネットプロトコル（IP）フラグメント化されたパケットに対する図２５に示されているセマンティックプロセッサ4400内での処理に関するフローチャート4500である。このフローチャート 4500は、本発明の実施例に係る実施方式を説明するために使用される。

パケットが入力ポート 4120を介して入力バッファ4140において受信され、それに伴いDXP 4180が入力バッファ4140内のパケットのヘッダーの解析を開始すると、ブロック 4510では、DXP 4180は、受信したパケットがIPフラグメント化されたパケットであると判定されたため、受信したパケットのヘッダーの解析をやめる。DXP 4180は、IPヘッダーを完全に解析し、続く層（TCP、UDP、iSCSIなど）に属するヘッダーについてはどのヘッダーに対しても解析を行わないのが好ましい。

次のブロック 4520では、DXP 4180は、SPU 4410にSCT 4150から適切なマイクロ命令をロードし、入力バッファ4140から受信したパケットを読み込むように信号を送る。次のブロック 4530では、SPU 4410は、受信したパケットをストリーミングキャッシュ4470を介してDRAM 4480へ書き込む。ブロック4520とブロック4530は二つの個別のステップとして示されているが、他のやり方としては、これらは、SPU 4410がパケットの読み込みと書き込みを同時に行うことで一つのステップとして実行されてもよい。このSPU 4410が同時に読み込みと書き込みを実行する動作（オペレーション）は、SPUパイプライン方式として知られている。この演算では、SPU 4410は、セマンティックプロセッサ4400内の二つのブロック間で転送されるストリーミングデータ用のコンジット(conduit)またはパイプラインとして動作する。

次の判定ブロック4540では、SPU 4410は、コンテキスト制御ブロック（CCB）が正しいIPパケットフラグメントの収集や順序付けのために割り当てられているかどうか判定する。IPフラグメント化されたパケットに対応するフラグメントを収集しかつ順序付けするためのCCBは、DRAM 4480内に格納されるのが好ましい。CCBは、DRAM 4480内のIPフラグメントに対するポインタと、まだ到着していないIPフラグメント化されたパケットに対するビットマスクと、割り当てられた期間が過ぎたらセマンティックプロセッサ4400にさらなるIPフラグメント化されたパケットを待つことをやめさせ、その後、DRAM 4480内のCCBに保存されたデータを開放させるためのタイマー値と、を含んでいる。

SPU 4410は、受信したIPパケットフラグメントのヘッダーからのID（identification）及びプロトコルと組み合わされている、受信したIPフラグメント化されたパケットの送信元IPアドレスを鍵として使用して、AMCD 4430のコンテント・アドレッサブル・メモリ（CAM）の検索機能にアクセスすることで、CCBが割り当てられているかどうか判定するのが好ましい。その他のやり方としては、このIPフラグメント鍵は、DRAM 4480内の別々のCCBテーブル内に格納される。そして、このやり方では、これらの鍵は、受信したIPパケットフラグメントのヘッダーからのID（identification）及びプロトコルと組み合わされている、受信したIPフラグメント化されたパケットの送信元IPアドレスを使用することでCAMとアクセスさせられる。このようにIPフラグメント鍵のアドレス化することで、鍵の重複と鍵の大きさの問題を回避する。

SPU 4410が、特定のIPフラグメント化されたパケットに関するフラグメントの収集と順序付けのためにCCBがまだ割り当てられていないと判定した場合、実行プログラムはブロック4550へと進み、そこでSPU 4410がCCBを割り当てる。SPU 4410は、割り当てられたCCBに対応する鍵を、AMCD 4430内のIPフラグメントCCBテーブルへ入力し、CCB内に配置されたタイマーを開始する。ここで言う鍵は、受信したIPフラグメント化されたパケットのヘッダーからのID（identification）及びプロトコルと、受信したIPフラグメントの送信元IPアドレスと、から構成されるものである。与えられたフラグメント化されたパケットに関する最初のフラグメントが受信されると後の再循環のために、IPヘッダーもCCBへ格納される。以後のフラグメントに関しては、IPヘッダーは格納される必要はない。

CCBがIPフラグメント化されたパケットの収集と順序付けのために割り当てられるとすぐに、次のブロック4560では、SPU 4410はIPフラグメント化されたパケット（からIPヘッダーを除いたもの）に対するポインタをCCB内のDRAM 4480に格納する。フラグメントに対するポインタは、例えばリンクされたリストとしてCCB内に設けることができる。好ましくは、SPU 4410は、受信されたフラグメントに対応するマスクの一部を受信されたものとしてマーキングすることで、新たに割り当てられたCCB内のビットマスクをアップデートしてよい。

次の判定ブロック4570では、SPU 4410は、パケットからのIPフラグメントのすべてが受信されたかどうか判定する。この判定は、CCB内でビットマスクを使用して達成されるのが好ましい。当業者であれば、本発明とともに利用可能なビットマスク（すなわち均等にトラッキングを行う機構）を実施するのに容易に利用可能な多数の技術があることを理解するであろう。

IPフラグメント化されたパケットに関するフラグメントのすべてが受信され終わっていない場合、セマンティックプロセッサ4400は、次のフラグメントが受信されるまで、このフラグメント化されたパケットに関するさらなる処理を保留する。

IPフラグメントのすべてが受信され終わっている場合、次のブロック 4580では、SPU 4410は、タイマーをリセットするとともに、DRAM 4480からIPフラグメントを正しい順序で読み込み、その後、さらなる解析と処理のために、それらを再循環バッファ 4160へ書き込む。SPU 4410は、特別なヘッダーと、再構築されたIPパケット（フラグメント化ビットは設定されていないまま）の最初（first）の部分と、だけを再循環バッファ4160へ書き込むのが好ましい。特別なヘッダーは、DXP 4180が、IPフラグメント化されたパケットのすべてを再循環バッファ4160へと転送する必要なく、DRAM 4480内に格納されている再構築されたIPフラグメント化されたパケットの処理を指示することを可能にする。特別なヘッダーは、IPに対するパーサ文法をロードするとともにCCBに対するポインタをロードするように指定された非終端シンボルから構成してもよい。こうして、パーサは通常、IPヘッダーを解析することができ、その後上位層（例えばTCP）のヘッダーの解析へと進むことができる。

本発明の実施例では、DXP 4180は、総当り方式の調停（arbitration）を介して、再循環バッファ4160と入力バッファ4140のどちらか一方で受信されたデータを解析することを決定する。総当り方式の調停（arbitration）に関する高度な記述は、パケットデータストリームを受信するための第一と第二のバッファに関連して以下において説明する。DXP 4180は、第一のバッファ内のパケットの解析を完了すると、第二のバッファを見て、データが解析可能かどうか判定する。解析可能である場合、第二のバッファからのデータが解析される。解析可能でない場合、DXP 4180は、第一のバッファを再び見て、データが解析可能かどうか判定する。DXP 4180は、第一のバッファか第二のバッファのどちらかでデータが解析可能となるまで、この総当り方式の調停（arbitration）を続ける。

図２７は、受信したパケットで、複合化か、認証か、またはその両方が必要なパケットの、図２５に示されているセマンティックプロセッサ 4400内での処理に関するフローチャート4600である。このフローチャート4600は、本発明の実施例に係るその他の実施方式を説明するのに使用される。

パケットが入力バッファ4140または再循環バッファ4160において受信され、それに伴いDXP 4180が受信したパケットのヘッダーの解析を開始すると、ブロック4610では、DXP 4180は、受信したパケットが複合化か、認証か、またはその両方が必要であると判定されたため、受信したパケットのヘッダーの解析をやめる。DXP 4180が再循環バッファ4160からのパケットのヘッダーの解析を開始した場合、再循環バッファ4160は、好ましくは、前述した特別なヘッダー及び再構築されたIPパケットの最初の部分だけを保持する。

次のブロック4620では、DXP 4180は、SPU 4410に、SCT 4150から適切なマイクロ命令をロードし、入力バッファ4140または再循環バッファ4160から受信したパケットを読み込むように指示する信号を送る。SPU 4410は、再循環バッファ4160内にまだ配置されていないデータに関しては、再循環バッファ4160の代わりにDRAM 4480からパケットフラグメントを読み込むのが好ましい。

次のブロック4630では、SPU 4410は、受信したパケットを暗号処理ブロック4440へ書き込む。そして、パケットはそこで認証されるか、複合化されるか、またはその両方を実行される。好ましい実施例では、複合化及び認証は暗号処理ブロック4440内で平行して実行される。暗号処理ブロック4440は、Triple Data Encryption Standard (T-DES)、Advanced Encryption Standard（AES）、Message Digest 5 (MD-5)、Secure Hash Algorithm 1 (SHA-1)、Rivest Cipher 4 (RC-4)アルゴリズムなどを使用することで、パケットの認証や、暗号化や、複合化を、可能にする。ブロック4620とブロック4630は二つの別々のステップとして図示されているが、他のやり方では、SPU 4410がパケットの読み込みと書き込みを同時に行うことで、これらは一つのステップとして実行することができる。

複合化されたパケットや認証されたパケットはその後、SPU 4410へと書き込まれ、次のブロック4640では、SPU 4410は、さらなる処理のために、パケットを再循環バッファ4160へ書き込む。好ましい実施例では、暗号処理ブロック4440は、データをDRAM 4480から読み込むことができ、かつデータをDRAM 4480へと書き込むことができる直接メモリアクセスエンジンを備えている。複合化されたパケットや認証されたパケットをDRAM 4480へ戻して書き込むことで、SPU 4410は、DRAM 4480から複合化されたパケットや認証されたパケットのヘッダーだけを読み込むことができ、続いて、それらを再循環バッファ4160へと書き込むことができる。パケットのペイロードはDRAM 4480内に残っているので、セマンティックプロセッサ4400は、処理時間を保存する。IPフラグメントの時と同様（like with IP fragmentation）、特別なヘッダーは再循環バッファへ書き込まれ、パーサを方向付けるとともに、CCB情報をSPU 4410へと送り返す。

IPのフラグメント化や、IPの暗号化や、IPの認証が、セマンティックプロセッサ4400により受信された単一のパケット内で行われている場合、再循環バッファ4160を何回も通過することが必要となることがある。

図２８は、セマンティックプロセッサの別の実施例を示している。セマンティックプロセッサ4700は、複数のセマンティック処理ユニット(SPU) 4410_ 1、4410_ 2、4410_ Nを含んでいるセマンティック処理ユニット（SPU）クラスタ4410を備えている。各SPU 4410_ 1〜SPU 4410_ Nは、同質であり、同一の機能を持つのが好ましい。SPUクラスタ4410は、メモリサブシステム4240と、SPUエントリーポイント（SEP）ディスパッチャ（dispatcher）4720と、SCT 4150と、ポート入力バッファ（PIB）4730と、ポート出力バッファ（POB）4750と、マシン中央演算処理装置（MCPU）4771と、にと接続されている。

DXP 4180が、解析の特定の時点でSPUタスクを開始すると決定すると、DXP 4180は、SEPディスパッチャ4720に、SCT 4150からマイクロ命令をロードするとともに、SPUクラスタ4410内の複数のSPU 4410_1〜4410_NからSPUを割り当てて、タスクを実行ように指示する信号を送る。このロードされたマイクロ命令と実行されるタスクは、その後、割り当てられたSPUへ送られる。割り当てられたSPUは、その後、マイクロ命令を実行し、データパケットはそれに従って処理される。SPUは、その他のやり方として、SEPディスパッチャ4720に命令された場合、SCT 4150からマイクロ命令を直接ロードすることができる。

MCPU 4771は、SPUクラスタ4410と、メモリサブシステム4240と、に接続されている。MCPU 4771は、セマンティックプロセッサ4700にとって望ましい機能の中で、通常のハードウェア上で従来のソフトウェアを起動することで無理なく遂行できるものを実行する。これらの機能は、通常、あまり使われずかつ時間的に重要でない機能であり、その機能の複雑性から、SCT 4150内に含まれることを保障しない。MCPU 4771は、SPUがMCPUの代わりにタスクを実行するようにリクエストするためにSPUクラスタ4410内のディスパッチャ（dispatcher）と通信する機能も持つ。

本発明のある実施例では、メモリサブシステム4240は、さらに、暗号処理ブロック4440と、コンテキスト制御ブロックキャッシュ4450と、通常キャッシュ4460と、ストリーミングキャッシュ4470と、をDRAM 4480及び外部DRAM 4791と接続させるDRAMインターフェイス4790を備えている。この実施例では、AMCD 4430は、外部TCAM 4793と直接接続されており、この外部TCAM 4793は、一方で、外部SRAM 4795（静的ランダムアクセスメモリ）と接続されている。

PIB 4730は、少なくとも一つのネットワークインターフェイス入力バッファと、再循環バッファと、周辺機器構成要素相互通信（PCI-X）入力バッファと、を備えている。POB 4750は、少なくとも一つのネットワークインターフェイス出力バッファと、周辺機器構成要素相互通信（PCI-X）出力バッファと、を備えている。ポートブロック4740は、一つまたは複数のポートを備えている。これらの各ポートは、物理的インターフェイスを備えている。この物理的インターフェイスの例としては、イーサーネット（登録商標）や、Fibre Channelや、802.11xや、ユニバーサル・シリアル・バス（USB）や、ファイヤーワイヤーや、その他の物理レイヤーインターフェイスなどに対する光学的なあるいは電気的なもしくは無線によるドライバーとレシーバーのペアなどが挙げられる。ポートブロック4740内のポートの数は、PIB 4730内のネットワークインターフェイス入力バッファの数と、POB 4750内の出力バッファの数と、一致する（対応する）のが好ましい。

PCI-Xインターフェイス4760は、PIB 4730内のPCI-X入力バッファと、POB 4750内のPCI-X出力バッファと、外部PCIバス4780と、接続される。PCIバス4780は、ディスクドライブや、追加のネットワークポートに対するインターフェイスなどのような、その他のPCIケーブル構成要素と接続することができる。

図２９は、POB 4750の実施例を詳細に示している。このPOB 4750は、RAM内で使用される二つのFIFO制御部と二つのバッファを備えている。各FIFO制御部に対して、POB 4750は、アドレスデコーダーを有するパッカー（パケット作成部）を備えている。POB 4750の出力は、egress状態マシン（egress state machine）と接続される。そしてこのegress状態マシン（egress state machine）は、インターフェイスと接続される。

図３０に示すように、各バッファは６９バイト幅である。バッファの下位の６４ビットは、データを保持する。その６４ビットに３ビットのエンコードされた情報が付け加えられる。この情報は、その64ビット中の何バイトのデータが有効であるかどうか示すものである。端の２ビットは、追加の情報を提供するために用いられる。例えば、この情報では、０はデータを示し、１はパケットの終わり（EOP）を示し、２は循環冗長コード（CRC）を示し、３は留保される。

バッファは８バイトのデータを保持する。しかし、このバッファに送られるデータのパケットは、「スキャッタ・ギャザー（scatter-gather）」フォーマットで形成されてもよい。すなわち、パケットのヘッダーがメモリ内のある場所に置かれ、パケットの残りは別の場所に置かれてもよい。だからSPUがPOB 4750に書き込むとき、SPUは例えば、最初に３バイトのデータを書き込み、その後で別の３バイトのデータを書き込んでもよい。不完全なバイトをRAMに書き込んでしまう事態を避けるために、POB 4750は、バッファに送られるのに十分なバイトが蓄積されるまで、データのバイトを保持レジスタ内に保持するためのパッカー（パケット作成部）を備えている。

図２９に戻るが、SPUクラスタ4710内のSPUは、アドレスバス及びデータバスを介してPOB 4750にアクセスする。SPUから送られるデータの内何バイトが有効なのかを判定するために、POB 4750内のパッカーは、アドレスの下位の３ビットをデコードする。すなわちアドレスのビット[2:0]をデコードする。ある実施例では、実施されるアドレスデコーディングスキームは、以下の表１で示されるもののようになる。

表１

パッカーがアドレスをデコードし終わったとき、このパッカーは、自身がRAMに記憶させるのに十分なデータを持っているかどうか判定する。パッカーが、自身が十分なデータを持っていないと判定した場合、このパッカーはこのデータを保持レジスタに送る。保持レジスタ内に十分なデータが蓄積された場合、データはFIFOへ入れられ（プッシュされ）、その後RAMへ送られる。場合によっては、SPUクラスタ 4710内のSPUは、EOPをパッカーに書き込んでもよい。この実施例では、パッカーは、データのすべてをRAMへ送る。ある実施例では、パッカーは、フリップ・フロップレジスタを用いて実施されてもよい。

POB 4750は、さらにegress状態マシン（egress state machine）を有している。このegress状態マシンは、各FIFOの状態を追跡する。このegress状態マシンは、FIFOがデータを有していることを感知しかつこのインターフェイスに対してFIFOをアンロードする。その後、この状態マシンは、別のFIFOに切り着替え、インターフェイスに対してこの別のFIFOをアンロードする。これらのFIFOがともに空であった場合、この状態マシンは、最初のFIFOがデータを有していると仮定し、FIFO間で切り替えを実行し、これらをインターフェイスに対して順次アンロードする。このように、パッカー内のデータは、パッカーに書き込まれた順番で送られる。

POB 4750は、バッファされたデータのエラー状態を検知するためのCRCエンジンを備えている。遭遇する可能性があるエラー状態には、アンダーランと無効EOPが含まれる。アンダーラン状態では、SPUはデータをPOB 4750に十分早く送ることができないので、POB 4750内には処理するのに十分なパケットが存在しないこととなる。無効EOPがある場合、EOPは、送信中のパケットがない間にパッカーに書き込まれる。これらの2つの状態は、POB 4750を停止させるエラーのフラグを立て、それにより、SPUがバッファにアクセスするのを避ける。

ある実施例では、いつパケットをバッファに送るのかを示すプログラム可能なスレッショルドを設定することで、アンダーランを避けることができる。例えば、スレッショルドがパケットの終端に設定されている場合、アンダーランは完全に回避できる。この場合、パケットは、パケットの終端が送り終わるまでは送られないので、アンダーランは起こらないこととなる。しかし、このスレッショルドでは、最善のパフォーマンスは得られない。

SPUクラスタ内の各SPUは、POB 4750にアクセスすることができる。しかし、POB 4750に送られるパケットの衝突を避けるためには、FIFOに書き込むことができるSPUは一つだけでなくてはならない。ある実施例では、外部メモリ内で保持されているフラグのようなトークン機構を用いて、どのSPUがPOB 4750にアクセスすることができるかを示すことができる。他のSPUは、最初のSPUがバッファを開放するまでそのバッファにアクセスすることができない。

当業者であればここで教示された概念が多くの他の有効な方法で独特な用途に適用できるということを理解するであろう。互いに協働するパーサと入力バッファのハードウェアと文法機能との一つのセットについて説明したが、その他の例も可能である。また、多数のコンテキスト解析のアプローチが必ずしもすべてハードウェアから構成されるカウンターを必要とするわけではない。いくつかの解析の問題は、入力データ自身から生じるコンテキスト切り替えのポイントだけを含んでいれば解決できる。

当業者であれば、本発明の範囲内で他の機能的なパーティションが可能であることを理解するであろう。また、どんな機能が共通の集積回路で実行されるか実行されないかは、アプリケーションによって変わることに留意されたい。

最後に、本明細書では、いくつかの箇所で、「ある実施例では・・・」、「一つの実施例では・・・」、「他の実施例では・・・」、「いくつかの実施例では」といった表現があるが、これは必ずしも特定な同じ実施例を意味しているものではなく、またそこで記載された特徴が特定の一つの実施例だけに適用されることを意味しているわけではないことに留意されたい。

SONETネットワークの代表的なパスのブロック図を示している。 一般化されたSONETフレームの構造を示している。 SONET STS-1 フレームの詳細を示している。 STS-1 SPEを示しており、SONET STS-1パスを介してパケットデータが転送される様式を示している。 STS-12フレームの作成に利用可能であるSONETマルチプレクサの一つの実行可能性のある構成を示している。 図５に示されているSTS-3マルチプレクサにより作成されるSTS-3フレームの通常のペイロードの分割方式を示している。 本発明の実施例に係るセマンティックプロセッサの実施例の一般的な見取り図を示している。 本発明のSONETの実施例に利用できる再構成可能な入力バッファの一つの実行可能性のある実施例を示している。 パーサと図７に示されているセマンティックプロセッサのそれに関連する構成要素のブロック図である。 図８の入力バッファとともにバイトインターリーブを解除した後のSTS-3フレームのフォーマットを示している。 図１０から引用されたインターリーブ解除されたSTS-3フレームの一行を含んでおり、この行におけるバイトストリーム内でのコンテキストの切り替えを示している。 本発明の実施例に利用可能なネットワーク通信システムをブロック図で示している。 図１に示されているプロキシの実施例をブロック図で示している。 図１２及び図１３Aに示されているプロキシ2200を介したパケットフローの例をブロック図で示している。 図１２、図１３A及び図１３Bに示されているプロキシの制御に関する実施例を説明するフローチャートの例を示している。 図１３A及び図１３Bに示されているネットワークインターフェイスプロキシとデバイスインターフェイスプロキシの実施例に利用できるセマンティックプロセッサをブロック図で示している。 図１５に示されているセマンティックプロセッサをTCP状態マシンとして動作させることに関する実施例を説明するフローチャートの例を示している。 本発明の実施例に利用できるセマンティックプロセッサの実施例をブロック図で示している。 受信したパケットの図１７の再循環バッファを備えたセマンティックプロセッサ内での処理に関するフローチャートである。 本発明の実施例に利用できるセマンティックプロセッサのより詳細な実施例を示している。 受信したIPフラグメント化されたパケットの図１９のセマンティックプロセッサ内での処理に関するフローチャートである。 受信した暗号化されているか認証されていないかまたはその両方であるパケットの図１９のセマンティックプロセッサ内での処理に関するフローチャートである。 本発明の実施例に利用できる別のセマンティックプロセッサの実施例を示している。 図２２のセマンティックプロセッサ内のパケット出力バッファの実施例を示している。 図２３のバッファが有する情報を示している。 セマンティックプロセッサの実施例をブロック図で示している。 パーサテーブルの実施例を示している。 生成規則テーブルの構成の実施例を示している。 パーサの実施例をブロック図で示している。 データの処理に関する実施例のフローチャートを示している。 セマンティックプロセッサ内でのデバッグ生成規則の処理に関する実施例のフローチャートを示している。

Claims (19)

1. 複数の解析コンテキストに従ってデータストリームを解析するように構成されたパーサを有し、前記パーサが前記データストリームの意味に応じて解析コンテキストを切り替えることを特徴とする装置。
2. 前記パーサは、前記データストリームの第一のセグメントを第一解析コンテキストに従って解析し、前記データストリームの第二のセグメントを第二解析コンテキストに従って解析する請求項１に記載の装置。
3. 前記パーサは、前記データストリームのセグメントを受信しかつ受信したセグメントの数をカウントするように構成されたデータインターフェイスを有し、前記パーサは、カウントされた数に応じて解析コンテキストを切り替えるようになっている請求項２に記載の装置。
4. 前記パーサは、前記データストリームを解析している間に識別された切り替えシンボルに従って解析コンテキストを切り替えるようになっており、各切替シンボルは、前記パーサに、前記データストリームを解析するための次の解析コンテキストを知らせるシンボルである請求項１に記載の装置。
5. 少なくとも一つの転送制御プロトコル（TCP）セッションを含む複数のセッションを管理するように構成されたプロキシを有し、該プロキシが前記転送制御プロトコルセッションとローカルセッションの間でデータを変換することを特徴とするシステム。
6. ネットワーク接続されている装置を含むローカルセッションを管理するように構成されたデバイスインターフェイスプロキシと、公共ネットワーク上で転送制御プロトコルセッションを管理するように構成されたネットワークインターフェイスプロキシと、を有し、前記プロキシがこれらのデバイスインターフェイスプロキシとネットワークインターフェイスプロキシを制御するようになっており、
   前記ネットワークインターフェイスプロキシは、前記転送制御プロトコルセッション上で受信した前記データを前記デバイスインターフェイスプロキシに提供する前に、該データをパケット化解除するとともに順序付けする請求項１記載のシステム。
7. 前記プロキシは、格納された文法に従って前記転送制御プロトコルセッションを識別するための直接実行パーサを備えた少なくとも一つのセマンティックプロセッサを有する請求項３に記載のシステム。
8. 前記セマンティックプロセッサは、転送制御プロトコル状態マシンを使用して、前記格納された文法内でコンテキスト切り替えを行うことで前記転送制御プロトコルセッションを管理する請求項３に記載のシステム。
9. 前記システムは、各々が前記ネットワークからのデータを処理するように構成された複数のネットワーク接続されている装置を含んでおり、前記プロキシは、前記ネットワークと前記ネットワーク接続されている装置の間に接続されており、ネットワーク接続されている装置一つ一つに対し少なくとも一つのローカルセッションを管理しかつ各ローカルセッションとそれに対応する前記転送制御プロトコルセッションの間でデータを変換するように構成されている請求項１に記載のシステム。
10. プロセッサがデータを受信することを可能にするための少なくとも一つの入力ポートと、
    パーサスタック内のシンボルに応じて前記該データを解析し、シンボルがデバッグ非終端シンボルであるかどうか判定し、当該装置にインタラプトを知らせるためのパーサと、を備えている装置。
11. さらに、セマンティック処理ユニットのアレイを有している請求項１に記載の装置。
12. さらに、前記インタラプトの通知を受け取り、セマンティック処理ユニットのアレイの一つのユニットに該インタラプトをディスパッチして、前記インタラプトに対処するディスパッチャを有している請求項２に記載の装置。
13. 前記セマンティック処理ユニットは、さらに、前記インタラプトに関連するデータを収集し、それを格納する機能を有する請求項３に記載の装置。
14. 前記データを収集するセマンティック処理ユニットは、さらに、前記最終データの判定、前記データがそれからアクセスされたパケット識別子、前記パーサ有限状態マシン内の最終状態及び前記パーサスタックの最終コンテンツの内の少なくとも一つを判定するようになっている請求項４に記載の装置。
15. 意味的にデータを解析することでデジタルデータの処理を制御するように構成されている直接実行パーサと、
    前記直接実行パーサに指示されるとデータ演算を実行するように構成されている複数のセマンティック処理ユニットと、
    前記複数のセマンティック処理ユニットから受信したデータをバッファするための複数の出力バッファと、を有しているプロセッサ。
16. 前記複数の出力バッファのそれぞれが、常に、複数のセマンティック処理ユニットの内の一つのユニットのみによってアクセスされるように構成されている請求項１４に記載のプロセッサ。
17. さらに、どのセマンティック処理ユニットが前記複数の出力バッファにアクセスすることができるかを示すためのトークンメカニズムを有する請求項１４に記載のプロセッサ。
18. 前記複数の出力バッファが前記複数のセマンティック処理ユニットから受信したデータをネットワークインターフェイスポートに送るようになっている請求項１４に記載のプロセッサ。
19. 前記複数の出力バッファが前記複数のセマンティック処理ユニットから受信したデータを周辺構成機器に送るようになっている請求項１４に記載のプロセッサ。

Images