JP2016005285A

JP2016005285A - パケットからデータを抽出する方法およびその装置

Info

Publication number: JP2016005285A
Application number: JP2015122563A
Authority: JP
Inventors: ヴィシャル・アナンド; Anand Vishal; ツァヒ・ダニエル; Daniel Tsahi; ジェラルド・シュミット; Schmidt Gerald
Original assignee: Xpliant Inc
Current assignee: Xpliant Inc
Priority date: 2014-06-19
Filing date: 2015-06-18
Publication date: 2016-01-12
Anticipated expiration: 2035-06-18
Also published as: EP2958285A2; US9516145B2; HK1220831A1; US20150373163A1; CN105282134A; CN105282134B; KR102337516B1; TW201607274A; EP2958285A3; JP6590545B2; KR20150145728A

Abstract

【課題】パケットからデータを抽出する方法およびその装置を提供する。【解決手段】パーサエンジンを実現する方法は、パケット内のプロトコルレイヤを特定する過程と、プロトコルレイヤのそれぞれを、そのプロトコルレイヤの特定したことの結果に基づいて、汎用フォーマットに拡張する過程と、拡張後のプロトコルレイヤからコンテンツを選択する過程であって、これにより、最終的なトークンを形成する、過程とを含む。【選択図】図６

Description

本発明は、ネットワークパケット（ネットワーク上のパケット）に関する。詳細には、本発明は、パケットからデータを抽出する方法およびその装置に関する。

例えばイーサネット（Ethernet）パケットなどのネットワークパケットを処理する際には、そのネットワークパケットからフィールドを抽出する必要がある。抽出したフィールド内に含まれる数値から、パケットをどのように取り扱うのかを決定することができる。一例として、スイッチング時には、イーサネットヘッダ内の４８ビットのＭＡＣ宛先アドレスを利用することにより、パケットをどのポートに送信するのかを決定することができる。同様に、ルーティング時には、ＩＰｖ４レイヤ内に含まれる３２ビットの宛先ＩＰアドレスを利用する。今日のハードウェアソリューションでは、これらの情報をパケットから抽出するのに、決まった抽出メカニズムを利用する。抽出すべき必要な情報がパケット内のどこに存在するのかについては、実装時に判断される。このようなハードウェアソリューションでは、進化し続けるネットワークプロトコルに対処しきれなくなる。

各実施形態において、パケットからデータを抽出する装置は、パケットからフィールドを抽出することを可能にするプログラマブルな（設定可能な）レイヤ命令に関する。具体的に述べると、パケットを、個々のレイヤに分割する。個々のレイヤには、そのレイヤを特定する固有のレイヤタイプ番号が供与される。個々のレイヤは、そのレイヤタイプに基づいて汎用フォーマットに拡張される。個々のレイヤには、そのレイヤに対する汎用的なレイヤ命令のセットがある。各レイヤ命令におけるフィールドは、レイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、およびその指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）である。上記レイヤ命令を用いることにより、パケット内の情報をプログラマブルに抽出することができる。各プロトコルレイヤについて、そのプロトコルレイヤから抽出したフィールドを互いに連結することにより、トークンレイヤを形成する。全てのトークンレイヤを連結することにより、最終的なトークンを形成する。そして、この最終的なトークンを、パケットのさらなる処理に用いる。

一態様では、パーサエンジンを実現する方法が提供される。このパーサエンジンは、ネットワークスイッチに含まれてもよい。この方法は、パケット内のプロトコルレイヤを特定する過程と、前記プロトコルレイヤのそれぞれを、そのプロトコルレイヤの前記特定したことの結果に基づいて、汎用フォーマットに拡張する過程と、拡張後のプロトコルレイヤからコンテンツを選択する過程であって、これにより、最終的なトークンを形成する、過程とを含む。

一部の実施形態では、前記パケット内の前記プロトコルレイヤのそれぞれを、そのプロトコルレイヤの固有のレイヤタイプ番号に基づいて特定する。

一部の実施形態では、前記汎用フォーマットが、前記プロトコルレイヤが有する可能性のある全てのフィールドを含む最高セットを規定している。

一部の実施形態では、前記プロトコルレイヤのそれぞれを拡張する前記過程が、拡張後のプロトコルレイヤに対するビットベクトルを保持することであって、当該ビットベクトルが、その拡張後のプロトコルレイヤの各バイトに対して１ビットを有すること、有効フィールドのそれぞれにおける全てのバイトに対する各ビットを、有効である（利用可能である（available））とマークすることであって、有効フィールドは、前記パケットのプロトコルレイヤ内に存在するフィールドであること、および無効フィールドのそれぞれにおける全てのバイトに対する各ビットを、無効である（利用不可能である（unavailable））とマークすることであって、無効フィールドは、前記パケットのプロトコルレイヤ内に存在しないフィールドであることを含む。

一部の実施形態において、前記方法は、さらに、圧縮フォーマットを用いる過程であって、拡張後のプロトコルレイヤを当該圧縮フォーマットにより表現する、過程を含む。

一部の実施形態において、前記方法は、さらに、汎用的なレイヤ命令のセットから、少なくとも１つのレイヤ命令を、拡張後のプロトコルレイヤに適用することにより、その拡張後のプロトコルレイヤからフィールドを抽出する、過程を含む。前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドは、拡張後のレイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、およびその指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）であり得る。一部の実施形態では、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドを、ソフトウェアで定義することを含む。

一部の実施形態において、前記方法は、さらに、少なくとも前記抽出されたフィールドに基づいて、トークンレイヤを形成する過程と、少なくとも前記トークンレイヤに基づいて、前記最終的なトークンを形成する過程とを含む。前記抽出されたフィールドを、その拡張後のプロトコルレイヤから抽出された他のフィールドと共に間隙を設けずに配置することにより、前記トークンレイヤを形成し得る。前記トークンレイヤを、他のトークンレイヤと共に間隙を設けずに配置することにより、前記最終的なトークンを形成し得る。この最終的なトークンは、前記パケットのさらなる処理に用いられ得る。

他の態様では、ネットワークスイッチを実現する方法が提供される。この方法は、前記ネットワークスイッチの受信ポートでパケットを受信する過程と、前記パケットの各プロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する過程と、汎用化後の各プロトコルヘッダについて、その汎用化後のプロトコルヘッダから、１つ以上のフィールドを抽出する過程と、汎用化後の各プロトコルヘッダについて、その汎用化後のプロトコルヘッダから抽出された前記１つ以上のフィールドを連結することにより、トークンレイヤを形成する、過程と、全てのトークンレイヤを連結することにより、最終的なトークンを形成する、過程とを含む。

一部の実施形態では、前記ネットワークスイッチがパーサエンジンを備えており、当該パーサエンジンが、各プロトコルヘッダの汎用化、汎用化後のプロトコルヘッダからの１つ以上のフィールドの抽出、汎用化後のプロトコルヘッダから抽出された前記１つ以上のフィールドを連結することによるトークンレイヤの形成、および全てのトークンレイヤを連結することによる最終的なトークンの形成を実行する。

一部の実施形態では、各プロトコルヘッダを汎用化する過程が、前記パーサエンジンが、そのプロトコルヘッダのレイヤタイプおよび当該レイヤタイプの変種を判定すること、前記パーサエンジンが、それらレイヤタイプおよび変種に基づいて、そのプロトコルヘッダから、欠けているフィールドを検出すること、および前記パーサエンジンが、前記検出の結果に基づいて、そのプロトコルヘッダを前記汎用フォーマットに拡張することを含む。

一部の実施形態では、１つ以上のフィールドを抽出する過程が、１つ以上の汎用的なレイヤ命令を、汎用化後のプロトコルヘッダに適用することを含む。前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドは、拡張後のレイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、およびその指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）であり得る。

一部の実施形態において、前記方法は、さらに、パケットを受信する過程に先立って、前記１つ以上の汎用的なレイヤ命令の各レイヤ命令におけるフィールドを、ソフトウェアによりプログラムする過程を含む。

一部の実施形態において、前記方法は、さらに、パケットを受信する過程に先立って、プロトコルの汎用フォーマットについての、ソフトウェア定義のマッピングを可能にする過程と、前記ソフトウェア定義のマッピングを、前記ネットワークスイッチのメモリに記憶する過程とを含む。

さらなる他の態様では、ネットワークスイッチが提供される。このネットワークスイッチは、パケットを送受信する入力ポートおよび出力ポートを備える。このネットワークスイッチは、さらに、プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングのセット、およびフィールドを抽出するための汎用的なレイヤ命令の複数のセットを記憶するメモリを備える。このネットワークスイッチは、さらに、前記パケットにヘッダ汎用化プロセスを実行するパーサエンジンであって、当該パケットにおける各プロトコルヘッダを、前記ソフトウェア定義のマッピングのうち、そのプロトコルに特有であるマッピングに従って汎用化し、汎用化後のプロトコルヘッダからコンテンツを選択することにより、最終的なトークンを形成するパーサエンジンを備える。前記ヘッダ汎用化プロセスは、あるプロトコルの、互いに異なる変種、あるいは、互いに異なるプロトコル、あるいは、両方に適用され得る。

一部の実施形態において、前記パケットは、前記パーサエンジンにより処理された後に、正準化されたプロトコルレイヤを有する。正準化後のプロトコルレイヤのそれぞれは、そのプロトコルの汎用フォーマットに従って拡張されたプロトコルレイヤであり得る。

一部の実施形態において、前記パーサエンジンは、さらに、汎用的なレイヤ命令の前記複数のセットのうちの１つのセットからの少なくとも１つのレイヤ命令を、汎用化後の各プロトコルレイヤに適用することにより、その汎用化後のプロトコルレイヤからフィールドを抽出する。一部の実施形態では、前記汎用的なレイヤ命令の前記複数のセットのうちの前記１つのセットが、前記対応するプロトコルに特有である。一部の実施形態では、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドが、ソフトウェアで定義される。

一部の実施形態では、前記抽出されたフィールドが、その汎用化後のプロトコルレイヤから抽出された他のフィールドと連結されることにより、トークンレイヤが形成される。一部の実施形態では、前記トークンレイヤが、他のトークンレイヤと互いに連結されることにより、最終的なトークンが形成される。一部の実施形態では、前記最終的なトークンが、前記パケットのさらなる処理に用いられる。

さらなる他の態様では、パーサエンジンが提供される。このパーサエンジンは回路を備えているか、または、回路から構成されている。その回路が、パケット内のプロトコルレイヤを特定し、前記プロトコルレイヤのそれぞれを、そのプロトコルレイヤの前記特定したことの結果に基づいて、汎用フォーマットに拡張し、拡張後のプロトコルレイヤからコンテンツを選択することにより、最終的なトークンを形成する。

一部の実施形態では、前記パケット内の前記プロトコルレイヤのそれぞれが、そのプロトコルレイヤの固有のレイヤタイプ番号に基づいて特定される。一部の実施形態では、前記汎用フォーマットが、そのプロトコルレイヤが有する可能性のある全てのフィールドを含む、最大のセットを規定している。すなわち、前記汎用フォーマットは、そのプロトコルレイヤが有する可能性のある全てのフィールドの集合を含む。

一部の実施形態では、前記回路が、さらに、汎用的なレイヤ命令のセットからの少なくとも１つのレイヤ命令を、拡張後のプロトコルレイヤに適用することにより、その拡張後のプロトコルレイヤからフィールドを抽出する。一部の実施形態では、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドが、拡張後のレイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、およびその指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）である。一部の実施形態では、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドが、ソフトウェアで定義される。

一部の実施形態では、前記回路が、さらに、少なくとも前記抽出されたフィールドに基づいて、トークンレイヤを形成し、少なくとも前記トークンレイヤに基づいて、前記最終的なトークンを形成する。一部の実施形態では、前記抽出されたフィールドを、その拡張後のプロトコルレイヤから抽出された他のフィールドと共に間隙を設けずに配置することにより、前記トークンレイヤが形成される。一部の実施形態では、前記トークンレイヤを、他のトークンレイヤと共に間隙を設けずに配置することにより、前記最終的なトークンが形成される。

前述の内容は、添付の図面に示す本発明の例示的な実施形態についての以下の詳細な説明から明らかになる。図面において同一の符号は、異なる図をとおして同一の構成要素を指す。図面は必ずしも縮尺どおりではなく、本発明の実施形態を示すことに重点を置いている。

本発明の一部の実施形態において、受信パケットにおける様々なレイヤのヘッダを汎用フォーマットに拡張する様子を示す図である。本発明の一部の実施形態での、プロトコルヘッダの汎用化の一例を示す図である。本発明の一部の実施形態での、プロトコルヘッダの汎用化の一例を示す他の図である。本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示す図である。本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示す他の図である。本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示すさらなる他の図である。本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示す図である。本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示す他の図である。本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示すさらなる他の図である。本発明の一部の実施形態において、拡張後のレイヤからデータを抽出する様子を示すブロック図である。本発明の一部の実施形態において、全てのレイヤから抽出された情報を連結することにより、１つのバスデータを形成する様子を示すブロック図である。本発明の一部の実施形態での、パーサエンジンの動作方法のフローチャートである。本発明の一部の実施形態での、パーサエンジンの他の動作方法のフローチャートである。本発明の一部の実施形態での、ネットワークスイッチの動作方法を示すフローチャートである。

以降では、説明目的の具体例を幾つか述べる。当業者であれば、それらの具体例以外でも本発明を実施できることを理解するであろう。すなわち、本発明は図示の実施形態に必ずしも限定されず、本明細書で述べる原理及び特徴に沿った最大限の範囲を包含する。

ネットワークスイッチ等のネットワークデバイスは、ネットワーク上のトラフィックのスイッチングつまりルーティングを行うことができる。ネットワークスイッチは、パケットを受信する少なくとも１つの入力ポートつまり受信ポート、およびパケットを送信する少なくとも１つの出力ポートつまり送信ポートを備える。一部の実施形態において、ネットワークスイッチは、さらに、パーサ（パース処理手段）およびリライタ（書き換え手段）を備える。パーサ（解析手段）は、ネットワーク上のパケット（ネットワークパケット）のコンテンツを特定する少なくとも１つのパーサエンジンを含み得る。リライタ（再書込手段）は、パケットを、ネットワークスイッチから送出する前に変更する少なくとも１つのリライトエンジンを含み得る。これら少なくとも１つのパーサエンジンおよび少なくとも１つのリライトエンジンは、自由に変更可能であり、プログラマブル（設定可能）に動作し得る。

上記ネットワークスイッチは、さらに、当該ネットワークスイッチが使用するデータを記憶するメモリを備える。一例において、このメモリは、汎用的なレイヤ命令のセットを記憶する。簡単に述べると、これら汎用的なレイヤ命令は、プロトコルヘッダからフィールドを抽出するために典型的に使用される。他の例において、そのメモリは、さらに、プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングのセットを記憶する。簡単に述べると、各プロトコルヘッダは、そのソフトウェア定義のマッピングのうち、そのプロトコルに特有であるマッピングに従った表現に変換され得る。後で詳述するように、これらのマッピングは、あるプロトコルの、互いに異なる変種にも、互いに異なるプロトコルにも適用可能であると共に、将来の新しいプロトコルにも適用（対応）可能である。さらなる他の例において、上記メモリは、さらに、計数値（counter）および統計量（statistic）を記憶する。

イーサネット（登録商標）では、パケットが複数のプロトコルレイヤを含む。各プロトコルレイヤは、互いに異なる情報を伝達する。そのようなレイヤとして、例えば：イーサネット；ＰＢＢイーサネット；ＡＲＰ；ＩＰｖ４；ＩＰｖ６；ＭＰＬＳ；ＦＣｏＥ；ＴＣＰ；ＵＤＰ；ＩＣＭＰ；ＩＧＭＰ；ＧＲＥ；ＩＣＭＰｖ６；ＶｘＬＡＮ；ＴＲＩＬＬ；ＣＮＭ；等が周知である。

理論的に言えば、プロトコルレイヤは任意の順番であってもよい。しかし実際には周知のレイヤ組合せとなる。有効なレイヤ組合せとして、例えば：イーサネット；イーサネット，ＡＲＰ；イーサネット，ＣＮＭ；イーサネット，ＦＣｏＥ；イーサネット，ＩＰｖ４；イーサネット，ＩＰｖ４，ＩＣＭＰ；イーサネット，ＩＰｖ４，ＩＧＭＰ；等がある。

パケットのパース処理（及びリライト処理）にあたって、パケットをレイヤに分解する。このような分割過程は、上記のような周知のレイヤに基づいて実行される。パケット内に含まれる各レイヤ内のフィールドの組合せには、多くの場合、様々な組合せが存在する。このような様々なフィールド組合せを効率的に取り扱えるように、これらのレイヤを汎用フォーマットに拡張する。汎用フォーマットを用いることにより、レイヤ内の特定のフィールドに依存しない例えばレイヤ命令などの命令を使用することが可能になる。汎用フォーマットは、所与の既知のレイヤが有し得る全てのフィールドを含む、最大のセットを規定している。

図１は、本発明の一部の実施形態において、受信パケットにおける様々なレイヤのヘッダを汎用フォーマットに拡張する様子を示す概略構成１００である。図１の受信パケットは、８層のプロトコルレイヤを含む。典型的に、各プロトコルレイヤは、そのプロトコルに対応したヘッダ（プロトコルヘッダ）を有する。なお、プロトコルレイヤの層数は、８層を超える場合も８層未満の場合もあり得る。パーサエンジンは、各レイヤおよびその変種を特定することができる。また、パーサエンジンは、各プロトコルレイヤを、そのレイヤの特定の結果および当該レイヤの変種に基づいて、図１に示すように拡張することができる。「正準レイヤ」つまり「正準化されたレイヤ」とは、汎用フォーマットに拡張されたプロトコルレイヤのことを指す。手短に言って、正準レイヤのそれぞれは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされたビットベクトルを備える。

以下の説明では、パーサエンジンが所与のレイヤをイーサネットパケットヘッダであると特定した場合を考える。図２Ａ〜図４Ｃに、本発明の一部の実施形態において、パーサエンジンがイーサネットプロトコルを扱う各種例を示す。図２Ａ〜図４Ｃに示された各種例は、本発明にかかるパーサエンジンにより、あるプロトコル（これらの例では、イーサネットプロトコル）の、互いに異なる変種を扱うことができることを証明している。各例には、イーサネットプロトコルの受信時のヘッダと、その汎用フォーマットとが描かれている。他種のプロトコルの場合の説明は省略するが、本発明にかかるパーサエンジンは、他種のプロトコル合も同様に扱うことができる。

図２Ａに、受信パケット内のイーサネットパケットヘッダのフォーマットの一例２００を示す。このイーサネットパケットヘッダ２００は、２２バイトであり、送信元アドレス（ＳＡ）フィールド、宛先アドレス（ＤＡ）フィールド、サービスＶＬＡＮタグフィールド、カスタマＶＬＡＮタグフィールドおよびイーサタイプフィールドの、５つのフィールドを有する。ＳＡフィールドおよびＤＡフィールドは、いずれも６バイトである。サービスＶＬＡＮタグフィールドおよびカスタマＶＬＡＮタグフィールドは、いずれも４バイトである。イーサタイプフィールドは、２バイトである。このイーサネットパケットヘッダ１００を含むパケットは、イーサネットパケットの変種のなかでも最も大きい変種であり、そのサイズは最大２２バイトであり得る。

パーサエンジンは、イーサネットパケットヘッダ２００を処理して、当該イーサネットパケットヘッダ２００には欠けているフィールドがないと判断する。このように、イーサネットパケットヘッダ２００は想定されるフィールド全てを備えていることから、このイーサネットパケットヘッダ２００の汎用フォーマットは、イーサネットパケットヘッダ２００と全く同一になる。図２Ｂに、図２Ａのイーサネットパケットヘッダ２００を表したビットベクトル２０５を示す。ビットベクトル２０５の各ビットは、イーサネットパケットヘッダ２００の２２バイトのうちの１バイトにそれぞれ対応する。イーサネットパケットヘッダ２００には、フィールド全てが存在していることから、当該イーサネットパケットヘッダ２００のフィールド全てが有効フィールドとなる（すなわち、数値を有する）。したがって、ビットベクトル２０５のビットは全て「１」である。つまり、イーサネットパケットヘッダ２００は、｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿１１１１＿１１｝という汎用フォーマットで表現することができる。

図３Ａに、受信パケットのイーサネットパケットヘッダのフォーマットの他の例３００を示す。このイーサネットパケットヘッダ３００は、１８バイトであり、ＳＡフィールド、ＤＡフィールド、カスタマＶＬＡＮタグフィールドおよびイーサタイプフィールドの、４つのフィールドしか有していない。すなわち、イーサネットパケットヘッダ３００には、サービスＶＬＡＮタグフィールドが欠けている。このイーサネットパケットヘッダ３００を含むパケットも、イーサネットパケットの変種である。

パーサエンジンは、イーサネットパケットヘッダ３００を処理して、当該イーサネットパケットヘッダ３００にはサービスＶＬＡＮタグフィールドが欠けていると判断し、当該イーサネットパケットヘッダ３００の汎用フォーマットにおける適切な位置に、欠けているサービスＶＬＡＮタグフィールドを含めることにより、そのイーサネットパケットヘッダ３００を最大サイズである２２バイトに拡張する。図３Ｂに、拡張後のイーサネットパケットヘッダの汎用フォーマット３００’を示す。拡張後のイーサネットパケットヘッダ３００’は、欠けていたサービスＶＬＡＮタグフィールドも含め、イーサネットプロトコルについて想定されるフィールド全てを備えている。拡張後のイーサネットパケットヘッダ３００’内の有効フィールドは、拡張前のイーサネットパケットヘッダ３００から存在していたＳＡフィールド、ＤＡフィールド、カスタマＶＬＡＮタグフィールドおよびイーサタイプフィールドである。拡張後のイーサネットパケットヘッダ３００’内の無効フィールドは、拡張前のイーサネットパケットヘッダ３００内には存在せずに拡張後のイーサネットパケットヘッダ３００’で追加された、サービスＶＬＡＮタグフィールドである。

図３Ｃに、図３Ｂの拡張後のイーサネットパケットヘッダ３００’を表したビットベクトル３０５を示す。ビットベクトル３０５の各ビットは、拡張後のイーサネットパケットヘッダ３００’の２２バイトのうちの１バイトにそれぞれ対応する。ビットベクトル３０５は、ＳＡフィールド、ＤＡフィールド、カスタマＶＬＡＮタグフィールドおよびイーサタイプフィールドからなる有効フィールド全てについて「１」である。また、ビットベクトル３０５は、サービスＶＬＡＮタグフィールドのみからなる無効フィールド全てについて「０」である。つまり、イーサネットパケットヘッダ３００は、｛２２’ｂ１１１１１１＿１１１１１１＿００００＿１１１１＿１１｝という汎用フォーマットで表現することができる。

図４Ａに、受信パケットのイーサネットパケットヘッダのフォーマットのさらなる他の例４００を示す。このイーサネットパケットヘッダ４００は、１４バイトであり、ＳＡフィールド、ＤＡフィールドおよびイーサタイプフィールドの、３つのフィールドしか有していない。すなわち、イーサネットパケットヘッダ４００には、サービスＶＬＡＮタグフィールドとカスタマＶＬＡＮタグフィールドとが欠けている。このイーサネットパケットヘッダ４００を含むパケットは、イーサネットパケットの変種のなかでも最も小さい変種である。

パーサエンジンは、イーサネットパケットヘッダ４００を処理して、当該イーサネットパケットヘッダ４００にはサービスＶＬＡＮタグフィールドとカスタマＶＬＡＮタグフィールドとが欠けていると判断し、当該イーサネットパケットヘッダ４００の汎用フォーマットにおける適切な位置に、欠けているサービスＶＬＡＮタグフィールドとカスタマＶＬＡＮタグフィールドとを含めることにより、そのイーサネットパケットヘッダ４００を最大サイズである２２バイトに拡張する。図４Ｂに、拡張後のイーサネットパケットヘッダの汎用フォーマット４００’を示す。拡張後のイーサネットパケットヘッダ４００’は、欠けていたサービスＶＬＡＮタグフィールドおよびカスタマＶＬＡＮタグフィールドも含め、イーサネットプロトコルについて想定される全てのフィールドを備えている。拡張後のイーサネットパケットヘッダ４００’内の有効フィールドは、拡張前のイーサネットパケットヘッダ４００から存在していたＳＡフィールド、ＤＡフィールドおよびイーサタイプフィールドである。拡張後のイーサネットパケットヘッダ４００’内の無効フィールドは、拡張前のイーサネットパケットヘッダ４００内に存在せずに拡張後のイーサネットパケットヘッダ４００’で追加された、サービスＶＬＡＮタグフィールドおよびカスタマＶＬＡＮタグフィールドである。

図４Ｃに、図４Ｂの拡張後のイーサネットパケットヘッダ４００’を表したビットベクトル４０５を示す。ビットベクトル４０５の各ビットは、拡張後のイーサネットパケットヘッダ４００’の２２バイトのうちの１バイトにそれぞれ対応する。ビットベクトル４０５は、ＳＡフィールド、ＤＡフィールドおよびイーサタイプフィールドからなる有効フィールド全てについて「１」である。また、ビットベクトル４０５は、サービスＶＬＡＮタグフィールドおよびカスタマＶＬＡＮタグフィールドからなる無効フィールド全てについて「０」である。つまり、イーサネットパケットヘッダ４００は、｛２２’ｂ１１１１１１＿１１１１１１＿００００＿００００＿１１｝という汎用フォーマットで表現することができる。

図２Ａ〜図４Ｃから分かるように、イーサネットヘッダを汎用フォーマットに拡張することにより、フィールドのオフセットは、受信時のイーサネットヘッダの変種にかかわらず、最大サイズを有するイーサネットヘッダ（これらの例では、図２Ａのイーサネットパケットヘッダ２００）のオフセットと同一になる。このようにイーサネットヘッダを、最大サイズを有するイーサネットヘッダに拡張することにより、受信時のイーサネットヘッダにかかわらず、同一のセットのソフトウェア命令での処理が可能になるので有利である。よって、例えばイーサタイプフィールドを抽出するレイヤ命令は、どのようなイーサネットヘッダを受信したのかにかかわらず常に同一のオフセットを指すことができる。

一部の実施形態では、受信時の所与のヘッダ内に存在するフィールドを、圧縮フォーマットをにより表現する。このコンパクトなフォーマットは、連続バイト（ｃｏｎｔＢｙｔｅｓ）フィールドと有効バイト（ｖａｌｉｄＢｙｔｅｓ）との２つのフィールドの組合せで構成される。連続バイト（ｃｏｎｔＢｙｔｅｓ）は、そのレイヤの先頭からの有効なバイト数を示す。有効バイト（ｖａｌｉｄＢｙｔｅｓ）は、そのレイヤの各バイトの有効性を示すビットベクトルである。

例えば、連続バイト（ｃｏｎｔＢｙｔｅｓ）が８であり、かつ、有効バイト（ｖａｌｉｄＢｙｔｅｓ）が４ｈ’０１１１である場合、そのレイヤは、０〜７番目のバイトが有効で、その後に、１個のヌルバイトと３個の有効なバイトが続くことを意味する。このような圧縮フォーマットを用いることにより、レイヤを表現するのに必要なビット数を節約することができる。総バイト数（バイトの総数）を算出したい場合、以下の表１に示すような疑似コードを使用することが考えられる。

パケットヘッダの汎用フォーマットを用いることにより、そのパケットヘッダからフィールドを抽出する際のハードウェア面およびソフトウェア面での柔軟性が向上する。ハードウェアは、そのパケットヘッダからのフィールドの抽出を、当該パケットヘッダ内におけるフィールドの位置に関係なく実施することができる。ソフトウェアにより、新しいプロトコルを支援するようにハードウェアをプログラムすることができる。また、ソフトウェアにより、ハードウェアのテーブル内に、ヘッダの各種プロトコルに用いる汎用フォーマットをプログラムすることができる。

プロトコルヘッダが拡張された後は、プログラマブルなレイヤ命令を用いることにより、パケットからフィールドを抽出することができる。個々のレイヤにはＮ個のレイヤ命令のセットがあり、Ｎはプロトコルに特有の数である。一部の実施形態では、個々のレイヤに、８つのプログラマブルなレイヤ命令がある。以下の表２に、各レイヤ命令のフィールドを示す。これらのフィールドは、ソフトウェアで定義される。

このような汎用的なレイヤ命令を用いることにより、パケット内の情報をプログラマブルに抽出することができる。一例としてイーサネットの場合を考えるが、従来の方法とは異なり、ＭＡＣＤＡ（ＭＡＣ宛先アドレス）を抽出したいときには、レイヤ命令によりオフセット＝０および長さ＝６バイトを指定すればよい。これにより、このレイヤから、ＭＡＣＤＡを保持する先頭から６バイト分を抽出することができる。同様に、ＩＰＤＡを抽出したいときには、レイヤ命令によりオフセット＝１６および長さ＝４バイトを指定すればよい。これにより、このレイヤから、ＩＰＤＡを保持するオフセット＝１６から開始する４バイト分を抽出することができる。

図５は、本発明の一部の実施形態において、拡張後のレイヤからデータを抽出する様子を示すブロック概略構成５００である。図中では、拡張後のレイヤのことを「レイヤＮヘッダ（正準ヘッダ）」と記載している。パーサエンジンによりレイヤタイプが判定されて、このレイヤタイプについてメモリが参照される。このメモリは、その拡張後のレイヤからフィールドを抽出するためのＮ個のレイヤ命令のうち、１つ以上のレイヤ命令を指定する。各レイヤ命令には、フィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）とフィールド長さ（ｆｉｅｌｄＬｅｎ）の２つのフィールドが含まれる。図５では、第１のレイヤ命令によりフィールド０が抽出され、第２のレイヤ命令によりフィールド１が抽出され、第３のレイヤ命令によりフィールド１５が抽出される。これらの抽出された情報は、図５に「トークンレイヤＮ」と記載されたバス内に記憶される。抽出されたフィールドは、互いに間隙なく隣り合わせで順次配置されることにより、トークンレイヤを形成する。すなわち、抽出されたフィールドが互いに連結されることにより、トークンレイヤが形成される。レイヤから抽出された情報の長さの合計は、そのレイヤに対して適用された各レイヤ命令におけるフィールド長さ（ｆｉｅｌｄＬｅｎ）の合計に等しい。

図６は、本発明の一部の実施形態において、全てのレイヤから抽出された情報を連結することにより、１つのバスデータを形成する様子を示すブロック概略構成６００である。図中では、レイヤ０からフィールドを抽出してトークンレイヤ０を形成するのに、２つのレイヤ命令（すなわち、命令０および命令１）が用いられている。また、レイヤ１からフィールドを抽出してトークンレイヤ１を形成するのに、３つのレイヤ命令（すなわち、命令０、命令１および命令２）が用いられている。その他のトークンレイヤについても同様である。これら全てのトークンレイヤが互いに間隙なく隣り合わせで順次配置されることにより、最終的なトークンが形成される。すなわち、トークンレイヤ０からトークンレイヤ７が連結されることにより、最終的なトークンが形成される。典型的に、この最終的なトークンは、パケットのさらなる処理に用いられる。

図７Ａに、本発明の一部の実施形態での、パーサエンジンの動作方法７００を示す。このパーサエンジンは、ネットワークスイッチの一部であり、ネットワークパケットのコンテンツを特定する。典型的に、このパーサエンジンは、そのパケットを最初にプロトコルレイヤ単位に分割する。過程７０５で、パケット内のプロトコルレイヤを特定する。具体的に述べると、プロトコルレイヤのそれぞれを、そのプロトコルレイヤの固有のレイヤタイプ番号に基づいて特定し得る。

過程７１０で、これらプロトコルレイヤのそれぞれを、その特定したことに基づいて、汎用フォーマットに拡張する。この汎用フォーマットは、プロトコルレイヤが有する可能性のある全てのフィールドを含む、最大のセットを規定している。拡張後のプロトコルレイヤに対するビットベクトルを保持し得る。このビットベクトルは、その拡張後のプロトコルレイヤの各バイトに対して１ビットを有し得る。有効フィールドのそれぞれにおける全てのバイトに対する各ビットを、有効であるとマークし得る。有効フィールドは、パケットのそのプロトコルレイヤ内に存在するフィールドであり得る。無効フィールドのそれぞれにおける全てのバイトに対する各ビットを、無効であるとマークし得る。無効フィールドのそれぞれは、パケットのそのプロトコルレイヤ内に存在しないフィールドであり得る。一部の実施形態では、拡張後のプロトコルレイヤを、圧縮フォーマットにより表現する。

過程７１５で、拡張後のプロトコルレイヤからコンテンツを選択することにより、最終的なトークンを形成する。

図７Ｂに、本発明の一部の実施形態での、パーサエンジンの他の動作方法７５０を示す。典型的に、このパーサエンジンは、前述した方法７００に続いてこの方法７５０を実行する。過程７５５で、汎用的なレイヤ命令のセットから、少なくとも１つのレイヤ命令を、拡張後のプロトコルレイヤに適用することにより、その拡張後のプロトコルレイヤからフィールドを抽出する。汎用的なレイヤ命令の各レイヤ命令におけるフィールドは、拡張後のレイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、およびその指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）であり得る。汎用的なレイヤ命令の各レイヤ命令におけるフィールドを、ソフトウェアで定義し得る。

過程７６０で、少なくとも前記抽出されたフィールドに基づいて、トークンレイヤを形成する。抽出されたフィールドを、その拡張後のプロトコルレイヤから抽出された他のフィールドと共に間隙を設けずに配置することにより、前記トークンレイヤを形成し得る。

過程７６５で、前記トークンレイヤに基づいて、前記最終的なトークンを形成する。前記トークンレイヤを、他のトークンレイヤと共に間隙を設けずに配置することにより、前記最終的なトークンを形成し得る。典型的に、この最終的なトークンは、パケットのさらなる処理に用いられる。

図８に、本発明の一部の実施形態での、ネットワークスイッチの動作方法８００を示す。一部の実施形態において、このネットワークスイッチは、プロトコルの汎用フォーマットについての、ソフトウェア定義のマッピングを可能にし、これらソフトウェア定義のマッピングを、当該ネットワークスイッチのメモリに記憶する。過程８０５で、当該ネットワークスイッチの受信ポートでパケットを受信する。

過程８１０で、そのパケットの各プロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する。パーサエンジンが、そのプロトコルヘッダのレイヤタイプおよび当該レイヤタイプの変種を判定し得る。パーサエンジンが、それらレイヤタイプおよび変種に基づいて、そのプロトコルヘッダから、欠けているフィールドを検出し得る。パーサエンジンが、前記検出の結果に基づいて、そのプロトコルヘッダを前記汎用フォーマットに拡張し得る。

過程８１５で、汎用化後の各プロトコルヘッダについて、その汎用化後のプロトコルヘッダから、１つ以上のフィールドを抽出する。この１つ以上のフィールドを抽出するために、１つ以上の汎用的なレイヤ命令を、汎用化後のプロトコルヘッダに適用し得る。汎用的なレイヤ命令の各レイヤ命令におけるフィールドは、拡張後のレイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、およびその指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）であり得る。典型的には、過程８０５に先立って、汎用的なレイヤ命令の各レイヤ命令におけるフィールドを、ソフトウェアによりプログラムする。

過程８２０で、汎用化後の各プロトコルヘッダについて、その汎用化後のプロトコルヘッダから抽出された前記１つ以上のフィールドを連結することにより、トークンレイヤを形成する。具体的に述べると、抽出された前記１つ以上のフィールド同士を、間隙を設けずに配置することにより、前記トークンレイヤを形成し得る。

過程８２５で、全てのトークンレイヤを連結することにより、最終的なトークンを形成する。具体的に述べると、前記トークンレイヤを、他のトークンレイヤと共に間隙を設けずに配置することにより、前記最終的なトークンを形成し得る。典型的に、この最終的なトークンは、パケットのさらなる処理に用いられる。

以上のように、パケットからのデータはレイヤ命令を用いて抽出される。この抽出過程は、その各レイヤを汎用フォーマットに拡張してから実行する。ヘッダの汎用フォーマットを用いるのに加えて、パケットのレイヤ内の特定のフィールドに依存しないレイヤ命令を使用するので、パケットヘッダからフィールドを抽出する際のハードウェア面およびソフトウェア面での柔軟性が向上する。さらに、抽出すべき必要な情報がパケット内のどこに存在するのかについて、実装時に判断する必要性がなくなる。

当業者であれば、上記以外にも用途や利点が存在することが理解できるであろう。これまでの本発明の説明は幾つかの具体例に基づいたものであったが、当業者であれば、本発明の精神を逸脱することなく本発明をその他の具体的な形態でも実施可能であることを理解できるであろう。すなわち、当業者であれば、本発明が前述の具体例に限定されるものではなく、添付の特許請求の範囲により規定されるものであることを理解するであろう。

Claims

パーサエンジンを実現する方法であって、
パケット内のプロトコルレイヤを特定する過程と、
前記プロトコルレイヤのそれぞれを、そのプロトコルレイヤの前記特定したことの結果に基づいて、汎用フォーマットに拡張する過程と、
拡張後のプロトコルレイヤからコンテンツを選択する過程であって、これにより、最終的なトークンを形成する、過程と、
を含む、方法。
請求項１に記載の方法において、前記パケット内の前記プロトコルレイヤのそれぞれを、そのプロトコルレイヤの固有のレイヤタイプ番号に基づいて特定する、方法。
請求項１に記載の方法において、前記汎用フォーマットが、前記プロトコルレイヤが有する可能性のある全てのフィールドを含む、最大のセットを規定している、方法。
請求項１に記載の方法において、前記プロトコルレイヤのそれぞれを拡張する前記過程が、
拡張後のプロトコルレイヤに対するビットベクトルを保持することであって、当該ビットベクトルが、その拡張後のプロトコルレイヤの各バイトに対して１ビットを有すること、
有効フィールドのそれぞれにおける全てのバイトに対する各ビットを、有効であるとマークすることであって、有効フィールドのそれぞれは、前記パケットの前記プロトコルレイヤ内に存在するフィールドであること、および
無効フィールドのそれぞれにおける全てのバイトに対する各ビットを、無効であるとマークすることであって、無効フィールドのそれぞれは、前記パケットの前記プロトコルレイヤ内に存在しないフィールドであること、
を含む、方法。
請求項４に記載の方法において、さらに、
圧縮フォーマットを用いる過程であって、拡張後のプロトコルレイヤを当該圧縮フォーマットにより表現する、過程、
を含む、方法。
請求項１に記載の方法において、さらに、
汎用的なレイヤ命令のセットから、少なくとも１つのレイヤ命令を、拡張後のプロトコルレイヤに適用することにより、その拡張後のプロトコルレイヤからフィールドを抽出する、過程、
を含む、方法。
請求項６に記載の方法において、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドが、拡張後のレイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、およびその指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）である、方法。
請求項６に記載の方法において、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドを、ソフトウェアで定義することを含む、方法。
請求項６に記載の方法において、さらに、
少なくとも前記抽出されたフィールドに基づいて、トークンレイヤを形成する過程と、
少なくとも前記トークンレイヤに基づいて、前記最終的なトークンを形成する過程と、
を含む、方法。
請求項９に記載の方法において、前記抽出されたフィールドを、その拡張後のプロトコルレイヤから抽出された他のフィールドと共に間隙を設けずに配置することにより、前記トークンレイヤを形成する、方法。
請求項９に記載の方法において、前記トークンレイヤを、他のトークンレイヤと共に間隙を設けずに配置することにより、前記最終的なトークンを形成する、方法。
ネットワークスイッチを実現する方法であって、
前記ネットワークスイッチの受信ポートでパケットを受信する過程と、
前記パケットの各プロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する過程と、
汎用化後の各プロトコルヘッダについて、その汎用化後のプロトコルヘッダから、１つ以上のフィールドを抽出する過程と、
汎用化後の各プロトコルヘッダについて、その汎用化後のプロトコルヘッダから抽出された前記１つ以上のフィールドを連結することにより、トークンレイヤを形成する、過程と、
全てのトークンレイヤを連結することにより、最終的なトークンを形成する、過程と、
を含む、方法。
請求項１２に記載の方法において、前記ネットワークスイッチがパーサエンジンを備えており、当該パーサエンジンが、各プロトコルヘッダの汎用化、汎用化後のプロトコルヘッダからの１つ以上のフィールドの抽出、汎用化後のプロトコルヘッダから抽出された前記１つ以上のフィールドを連結することによるトークンレイヤの形成、および全てのトークンレイヤを連結することによる最終的なトークンの形成を実行する、方法。
請求項１３に記載の方法において、各プロトコルヘッダを汎用化する過程が、
前記パーサエンジンが、そのプロトコルヘッダのレイヤタイプおよび当該レイヤタイプの変種を判定すること、
前記パーサエンジンが、それらレイヤタイプおよび変種に基づいて、そのプロトコルヘッダから、欠けているフィールドを検出すること、および
前記パーサエンジンが、前記検出の結果に基づいて、そのプロトコルヘッダを前記汎用フォーマットに拡張すること、
を含む、方法。
請求項１２に記載の方法において、１つ以上のフィールドを抽出する過程が、１つ以上の汎用的なレイヤ命令を、汎用化後のプロトコルヘッダに適用することを含む、方法。
請求項１５に記載の方法において、前記１つ以上の汎用的なレイヤ命令の各レイヤ命令におけるフィールドが、拡張後のレイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、およびその指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）である、方法。
請求項１５に記載の方法において、さらに、パケットを受信する過程に先立って、
前記１つ以上の汎用的なレイヤ命令の各レイヤ命令におけるフィールドを、ソフトウェアによりプログラムする過程、
を含む、方法。
請求項１２に記載の方法において、さらに、パケットを受信する過程に先立って、
プロトコルの汎用フォーマットについての、ソフトウェア定義のマッピングを可能にする過程と、
前記ソフトウェア定義のマッピングを、前記ネットワークスイッチのメモリに記憶する過程と、
を含む、方法。
パケットを送受信する入力ポートおよび出力ポートと、
プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングのセット、およびフィールドを抽出するための汎用的なレイヤ命令の複数のセットを記憶するメモリと、
前記パケットにヘッダ汎用化プロセスを実行するパーサエンジンであって、当該パケットにおける各プロトコルヘッダを、前記ソフトウェア定義のマッピングのうち、そのプロトコルに特有であるマッピングに従って汎用化し、汎用化後のプロトコルヘッダからコンテンツを選択することにより、最終的なトークンを形成するパーサエンジンと、
を備える、ネットワークスイッチ。
請求項１９に記載のネットワークスイッチにおいて、前記ヘッダ汎用化プロセスが、あるプロトコルの、互いに異なる変種に適用される、ネットワークスイッチ。
請求項１９に記載のネットワークスイッチにおいて、前記ヘッダ汎用化プロセスが、互いに異なるプロトコルに適用される、ネットワークスイッチ。
請求項１９に記載のネットワークスイッチにおいて、前記パケットは、前記パーサエンジンにより処理された後に、正準化されたプロトコルレイヤを有する、ネットワークスイッチ。
請求項２２に記載のネットワークスイッチにおいて、正準化後のプロトコルレイヤのそれぞれは、そのプロトコルの汎用フォーマットに従って拡張されたプロトコルレイヤである、ネットワークスイッチ。
請求項１９に記載のネットワークスイッチにおいて、前記パーサエンジンは、さらに、汎用的なレイヤ命令の前記複数のセットのうちの１つのセットからの少なくとも１つのレイヤ命令を、汎用化後の各プロトコルレイヤに適用することにより、その汎用化後のプロトコルレイヤからフィールドを抽出する、ネットワークスイッチ。
請求項２４に記載のネットワークスイッチにおいて、前記汎用的なレイヤ命令の前記複数のセットのうちの前記１つのセットが、前記対応するプロトコルに特有である、ネットワークスイッチ。
請求項２４に記載のネットワークスイッチにおいて、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドが、ソフトウェアで定義される、ネットワークスイッチ。
請求項２４に記載のネットワークスイッチにおいて、前記抽出されたフィールドが、その汎用化後のプロトコルレイヤから抽出された他のフィールドと連結されることにより、トークンレイヤが形成される、ネットワークスイッチ。
請求項２７に記載のネットワークスイッチにおいて、前記トークンレイヤが、他のトークンレイヤと互いに連結されることにより、最終的なトークンを形成する、ネットワークスイッチ。
請求項２８に記載のネットワークスイッチにおいて、前記最終的なトークンが、前記パケットのさらなる処理に用いられる、ネットワークスイッチ。
回路を備えるパーサエンジンであって、前記回路が、
パケット内のプロトコルレイヤを特定し、
前記プロトコルレイヤのそれぞれを、そのプロトコルレイヤの前記特定したことの結果に基づいて、汎用フォーマットに拡張し、
拡張後のプロトコルレイヤからコンテンツを選択することにより、最終的なトークンを形成する、パーサエンジン。
請求項３０に記載のパーサエンジンにおいて、前記パケット内の前記プロトコルレイヤのそれぞれが、そのプロトコルレイヤの固有のレイヤタイプ番号に基づいて特定される、パーサエンジン。
請求項３０に記載のパーサエンジンにおいて、前記汎用フォーマットが、そのプロトコルレイヤが有する可能性のある全てのフィールドを含む、最大のセットを規定している、パーサエンジン。
請求項３０に記載のパーサエンジンにおいて、前記回路が、さらに、汎用的なレイヤ命令のセットからの少なくとも１つのレイヤ命令を、拡張後のプロトコルレイヤに適用することにより、その拡張後のプロトコルレイヤからフィールドを抽出する、パーサエンジン。
請求項３３に記載のパーサエンジンにおいて、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドが、拡張後のレイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、およびその指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）である、パーサエンジン。
請求項３３に記載のパーサエンジンにおいて、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドが、ソフトウェアで定義される、パーサエンジン。
請求項３３に記載のパーサエンジンにおいて、前記回路が、さらに、少なくとも前記抽出されたフィールドに基づいて、トークンレイヤを形成し、少なくとも前記トークンレイヤに基づいて、前記最終的なトークンを形成する、パーサエンジン。
請求項３６に記載のパーサエンジンにおいて、前記抽出されたフィールドを、その拡張後のプロトコルレイヤから抽出された他のフィールドと共に間隙を設けずに配置することにより、前記トークンレイヤが形成される、パーサエンジン。
請求項３６に記載のパーサエンジンにおいて、前記トークンレイヤを、他のトークンレイヤと共に間隙を設けずに配置することにより、前記最終的なトークンが形成される、パーサエンジン。