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

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6590545

(24)【登録日】2019年9月27日

(45)【発行日】2019年10月16日

(54)【発明の名称】パケットからデータを抽出する方法およびその装置

(51)【国際特許分類】

   H04L 12/951 20130101AFI20191007BHJP

   H04L 29/06 20060101ALI20191007BHJP

【ＦＩ】

   H04L12/951

   H04L13/00 305Z

【請求項の数】37

【全頁数】20

(21)【出願番号】特願2015-122563(P2015-122563)

(22)【出願日】2015年6月18日

(65)【公開番号】特開2016-5285(P2016-5285A)

(43)【公開日】2016年1月12日

【審査請求日】2018年6月15日

(31)【優先権主張番号】14/309,726

(32)【優先日】2014年6月19日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】508002601

【氏名又は名称】カビウム・エルエルシー

(74)【代理人】

【識別番号】100094569

【弁理士】

【氏名又は名称】田中 伸一郎

(74)【代理人】

【識別番号】100088694

【弁理士】

【氏名又は名称】弟子丸 健

(74)【代理人】

【識別番号】100103610

【弁理士】

【氏名又は名称】▲吉▼田 和彦

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100086771

【弁理士】

【氏名又は名称】西島 孝喜

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100109335

【弁理士】

【氏名又は名称】上杉 浩

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100196612

【弁理士】

【氏名又は名称】鎌田 慎也

(72)【発明者】

【氏名】ヴィシャル・アナンド

(72)【発明者】

【氏名】ツァヒ・ダニエル

(72)【発明者】

【氏名】ジェラルド・シュミット

【審査官】 鈴木 肇

(56)【参考文献】

【文献】 米国特許出願公開第２０１２／０２８１７１４（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１３／００３９２７８（ＵＳ，Ａ１）

【文献】 国際公開第２００５／０３６８３４（ＷＯ，Ａ１）

【文献】 特開２００６−０２０３１７（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１３／０１６３４２７（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／００−１２／９５５

Ｈ０４Ｌ １３／００−１３／１８

Ｈ０４Ｌ ２９／００−２９／１２

(57)【特許請求の範囲】

【請求項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】

回路を備えるパーサエンジンであって、
前記回路は、パケットの１つ以上のプロトコルレイヤを特定するように構成され、該プロトコルレイヤのそれぞれは１つ以上のフィールドを有し、
前記プロトコルレイヤの各プロトコルレイヤについて、前記回路は、前記プロトコルレイヤを、該プロトコルレイヤの前記特定に基づいて、所定数のフィールドを有するフォーマットに拡張し、それによって拡張後のプロトコルレイヤを形成するように構成され、
前記回路は、前記拡張後のプロトコルレイヤのそれぞれからコンテンツを選択することにより、最終的なトークンを形成するように構成される、
パーサエンジン。

【請求項30】

請求項２９に記載のパーサエンジンにおいて、前記プロトコルレイヤのそれぞれは、固有のレイヤタイプ番号を有し、該固有のレイヤタイプ番号に基づいて特定される、パーサエンジン。

【請求項31】

請求項２９に記載のパーサエンジンにおいて、前記フォーマットが、そのプロトコルレイヤが有する可能性のある全てのフィールドを含む、最大のセットを規定している、パーサエンジン。

【請求項32】

請求項２９に記載のパーサエンジンにおいて、前記回路が、さらに、汎用的なレイヤ命令のセットからの少なくとも１つのレイヤ命令を、前記拡張後のプロトコルレイヤに適用することにより、該拡張後のプロトコルレイヤから１つ以上のフィールドを抽出するように構成される、パーサエンジン。

【請求項33】

請求項３２に記載のパーサエンジンにおいて、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドが、前記拡張後のプロトコルレイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、およびその指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）である、パーサエンジン。

【請求項34】

請求項３２に記載のパーサエンジンにおいて、前記汎用的なレイヤ命令の各レイヤ命令におけるフィールドが、ソフトウェアで定義される、パーサエンジン。

【請求項35】

請求項３２に記載のパーサエンジンにおいて、前記回路が、さらに、少なくとも前記抽出されたフィールドに基づいて、トークンレイヤを形成し、少なくとも前記トークンレイヤに基づいて、前記最終的なトークンを形成するように構成される、パーサエンジン。

【請求項36】

請求項３５に記載のパーサエンジンにおいて、前記抽出されたフィールドを、共に間隙を設けずに配置することにより、前記トークンレイヤが形成される、パーサエンジン。

【請求項37】

請求項３５に記載のパーサエンジンにおいて、前記トークンレイヤを、他のトークンレイヤと共に間隙を設けずに配置することにより、前記最終的なトークンが形成される、パーサエンジン。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【発明の概要】

【発明が解決しようとする課題】

【0003】

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

【課題を解決するための手段】

【0004】

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

【0005】

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

【0006】

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

【0007】

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

【0008】

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

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【図面の簡単な説明】

【0026】

【図1】本発明の一部の実施形態において、受信パケットにおける様々なレイヤのヘッダを汎用フォーマットに拡張する様子を示す図である。

【図2A】本発明の一部の実施形態での、プロトコルヘッダの汎用化の一例を示す図である。

【図2B】本発明の一部の実施形態での、プロトコルヘッダの汎用化の一例を示す他の図である。

【図3A】本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示す図である。

【図3B】本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示す他の図である。

【図3C】本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示すさらなる他の図である。

【図4A】本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示す図である。

【図4B】本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示す他の図である。

【図4C】本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示すさらなる他の図である。

【図5】本発明の一部の実施形態において、拡張後のレイヤからデータを抽出する様子を示すブロック図である。

【図6】本発明の一部の実施形態において、全てのレイヤから抽出された情報を連結することにより、１つのバスデータを形成する様子を示すブロック図である。

【図7A】本発明の一部の実施形態での、パーサエンジンの動作方法のフローチャートである。

【図7B】本発明の一部の実施形態での、パーサエンジンの他の動作方法のフローチャートである。

【図8】本発明の一部の実施形態での、ネットワークスイッチの動作方法を示すフローチャートである。

【発明を実施するための形態】

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

【表1】

【0048】

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

【0049】

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

【0050】

【表2】

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【図1】

【図2A】

【図2B】

【図3A】

【図3B】

【図3C】

【図4A】

【図4B】

【図4C】

【図5】

【図6】

【図7A】

【図7B】

【図8】