特許 6590546 パケットのコンテンツからハッシュ入力を形成する方法およびその装置

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

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

(11)【特許番号】6590546

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

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

(54)【発明の名称】パケットのコンテンツからハッシュ入力を形成する方法およびその装置

(51)【国際特許分類】

   H04L 12/743 20130101AFI20191007BHJP

【ＦＩ】

   H04L12/743

【請求項の数】37

【全頁数】22

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

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

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

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

【審査請求日】2018年5月28日

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

(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)【代理人】

【識別番号】100139712

【弁理士】

【氏名又は名称】那須 威夫

(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））とマークすることであって、有効フィールドは、前記パケットのプロトコルレイヤ内に存在するフィールドであること、および無効フィールドのそれぞれにおける全てのバイトに対する各ビットを、無効である（利用不可能である（unavaileble））とマークすることであって、無効フィールドは、前記パケットの前記プロトコルレイヤ内に存在しないフィールドであることを含む。

【0008】

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

【0009】

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

【0010】

一部の実施形態において、前記方法は、さらに、ビットマスクと抽出されたフィールド内の１バイトとで論理ＡＮＤ（論理積）演算を適用する過程であって、当該ビットマスクが、前記少なくとも１つのハッシュ命令によって指定される、過程と、少なくとも前記論理ＡＮＤ演算の結果に基づいて、ハッシュ入力レイヤを形成する過程と、拡張後のプロトコルレイヤからのハッシュ入力レイヤのうち、どのハッシュ入力レイヤを用いて、前記ハッシュ関数に対するハッシュ入力を形成すべきなのかを示すビットベクトルを取り出す（検索して取得する）過程とを含む。一部の実施形態において、前記方法は、さらに、前記ハッシュ入力を、前記ハッシュ関数に対する入力として用いる過程を含む。

【0011】

他の態様では、ネットワークスイッチを実現する方法が提供される。この方法は、前記ネットワークスイッチの受信ポートでパケットを受信する過程と、前記パケットの各プロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する過程と、汎用化後の各プロトコルヘッダについて、その汎用化後のプロトコルヘッダから、１つ以上のフィールドを抽出する過程と、汎用化後の各プロトコルヘッダについて、その汎用化後のプロトコルヘッダから抽出された前記１つ以上のフィールドを連結することにより、ハッシュレイヤを形成する、過程と、ビットベクトルを用いることにより、拡張後の全てのプロトコルヘッダからのハッシュレイヤのうち、どのハッシュレイヤを選択してハッシュ入力を形成すべきなのかを決定する、過程とを含む。

【0012】

一部の実施形態では、前記ネットワークスイッチがパーサエンジンを備えており、当該パーサエンジンが、各プロトコルヘッダの汎用化、汎用化後のプロトコルヘッダからの１つ以上のフィールドの抽出、汎用化後のプロトコルヘッダから抽出された前記１つ以上のフィールドを連結することによるハッシュレイヤの形成、およびビットベクトルを用いて拡張後の全てのプロトコルヘッダからのハッシュレイヤのうちのどのハッシュレイヤを選択してハッシュ入力を形成すべきなのかの決定を実行する。

【0013】

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

【0014】

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

【0015】

一部の実施形態において、前記方法は、さらに、１つ以上のフィールドを抽出する過程以降であって、抽出された前記１つ以上のフィールドを連結する過程以前に、ビットマスクと抽出されたフィールド内の１バイトとの間の論理ＡＮＤ演算を適用する過程であって、当該ビットマスクが、汎用的なハッシュ命令によって指定される、過程を含む。

【0016】

一部の実施形態において、前記方法は、さらに、ビットベクトルを用いる過程に先立って、前記パケットのＰｋｔＩＤを用いてローカルなテーブルを参照する（indexing）過程であって、当該テーブルが、既知のプロトコルレイヤ組合せごとにビットベクトルを記憶している、過程を含む。

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

一部の実施形態では、前記少なくとも１つのハッシュ命令が、ビットマスクおよび抽出されるフィールドにおいて当該ビットマスクを適用すべきバイト位置を指定する。一部の実施形態では、前記パーサエンジンが、さらに、前記ビットマスクと抽出されたフィールドにおける前記バイト位置とで論理ＡＮＤ演算を適用する。一部の実施形態では、前記論理ＡＮＤ演算からの結果が、他のＡＮＤ演算からの他の結果と連結されることにより、ハッシュ入力レイヤが形成される。一部の実施形態では、前記パーサエンジンが、前記テーブルにアクセスして、当該テーブルから、前記ハッシュ関数に対するハッシュ入力を形成するためにハッシュ入力レイヤに適用すべきビットベクトルを取り出す（検索取得する）。

【0023】

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

【0024】

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

【0025】

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

【0026】

一部の実施形態では、前記回路が、さらに、ビットマスクと抽出されたフィールド内の１バイトとの間の論理ＡＮＤ演算を適用し、当該ビットマスクは、少なくとも１つのハッシュ命令によって指定されるものであり、少なくとも前記論理ＡＮＤ演算の結果に基づいて、ハッシュ入力レイヤを形成し、拡張後のプロトコルレイヤからのハッシュ入力レイヤのうち、どのハッシュ入力レイヤを用いて、前記ハッシュ関数に対するハッシュ入力を形成すべきなのかを示すビットベクトルを取り出す。

【0027】

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

【図面の簡単な説明】

【0028】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【0029】

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

【0030】

各実施形態において、パケットのコンテンツからハッシュ入力を形成する装置は、ハッシュ入力をプログラマブルに（設定可能に）形成するという柔軟性に優れたソリューションに関する。このようなソリューションにより、多種多様な要件に応じてハードウェアを変更することが可能になるだけでなく、新しいプロトコルが将来規定された場合に、その新しいプロトコルに対するサポートを追加することも可能になる。具体的に述べると、パケットを、個々のレイヤに分割する。個々のレイヤには、そのレイヤが何であるかを特定するのを可能にする固有のレイヤタイプ番号が供与される。個々のレイヤは、そのレイヤタイプに基づいて汎用フォーマットに拡張される。個々のレイヤには、そのレイヤに対する汎用的なハッシュ命令のセットがある。各ハッシュ命令におけるフィールドは、フィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、フィールド長さ（ｆｉｅｌｄＬｅｎ）、ハッシュマスク（ｈａｓｈＭａｓｋ）およびハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）である。上記ハッシュ命令を用いることにより、パケット内の情報をプログラマブルに抽出することができる。パケットの各プロトコルレイヤについて、そのプロトコルレイヤから抽出したフィールドを、互いに連結することにより、ハッシュレイヤが形成される。ビットベクトルにより、どのハッシュレイヤを用いてハッシュ入力を形成すべきなのかが示される。

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

【表1】

【0050】

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

【0051】

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

【0052】

【表2】

【0053】

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

【0054】

上記の汎用的なハッシュ命令は、ハッシュマスク（ｈａｓｈＭａｓｋ）を用いてビット演算を実行し得る。具体的に述べると、ハッシュマスク（ｈａｓｈＭａｓｋ）は、抽出されるフィールドからの１つ以上のビットをマスクし得る。ハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）が「１」に設定されている場合、抽出されるフィールドの最上位バイトにハッシュマスク（ｈａｓｈＭａｓｋ）が適用され得る。ハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）が「０」に設定されている場合、抽出されるフィールドの最下位バイトにハッシュマスク（ｈａｓｈＭａｓｋ）が適用され得る。

【0055】

図５は、本発明の一部の実施形態において、拡張後のレイヤからデータを抽出する様子を示すブロック概略構成５００である。図中では、拡張後のレイヤのことを「レイヤＮヘッダ（正準ヘッダ）」と記載している。パーサエンジンによりレイヤタイプが判定されて、このレイヤタイプについてメモリが参照される。このメモリは、その拡張後のレイヤからフィールドを抽出するためのＮ個のハッシュ命令のうち、１つ以上のハッシュ命令を指定する。各ハッシュ命令には、フィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）とフィールド長さ（ｆｉｅｌｄＬｅｎ）とハッシュマスク（ｈａｓｈＭａｓｋ）とハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）の４つのフィールドが含まれる。図５では、第１のハッシュ命令により、フィールド０が抽出されると共に、このフィールド０内の１バイト（具体的には、前記ハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）の設定次第で、そのフィールド０の最上位バイト又は最下位バイト）と前記ハッシュマスク（ｈａｓｈＭａｓｋ）とで論理ＡＮＤ演算が実行される（これらハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）およびハッシュマスク（ｈａｓｈＭａｓｋ）は、同じく第１のハッシュ命令によって指定される）。また、第２のハッシュ命令により、フィールド１が抽出されると共に、このフィールド１内の１バイト（具体的には、前記ハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）の設定次第で、そのフィールド１の最上位バイト又は最下位バイト）と前記ハッシュマスク（ｈａｓｈＭａｓｋ）とで論理ＡＮＤ演算が実行される（これらハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）およびハッシュマスク（ｈａｓｈＭａｓｋ）は、同じく第２のハッシュ命令によって指定される）。さらに、第３のハッシュ命令により、フィールド１５が抽出されると共に、このフィールド１５内の１バイト（具体的には、前記ハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）の設定次第で、そのフィールド１５の最上位バイト又は最下位バイト）と前記ハッシュマスク（ｈａｓｈＭａｓｋ）とで論理ＡＮＤ演算が実行される（これらハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）およびハッシュマスク（ｈａｓｈＭａｓｋ）は、同じく第３のハッシュ命令によって指定される）。これらの論理ＡＮＤ演算の結果は、図５に「ハッシュ入力レイヤＮ」と記載されたバス内に記憶される。これらの結果は、互いに間隙なく隣り合わせで順次配置されることにより、ハッシュ入力レイヤを形成する。すなわち、それら論理ＡＮＤ演算の結果が連結されることにより、ハッシュ入力レイヤが形成される。

【0056】

ハッシュ入力の形成には、必ずしも全てのハッシュ入力レイヤが必要ではない。よって、独立した構成により、どのハッシュ入力レイヤを用いてハッシュ入力を形成するのかが指定され得る。具体的に述べると、ネットワークスイッチのメモリ内に記憶されたローカルなテーブルが、既知のプロトコルレイヤ組合せごとのデータを含むようにプログラムされ得る。このテーブルは、ＰｋｔＩＤを用いて索引付けられ得て、プロトコルレイヤ組合せごとにビットベクトルを有し得る。このビットベクトルは、関連付けられたプロトコルレイヤ組合せ（すなわち、プロトコルレイヤスタック）のうち、どのプロトコルレイヤをハッシュ入力の形成に用いるのかを示し得る。

【0057】

ネットワークスイッチがパケットを受信するたびに、パーサエンジンが、そのパケットのＰｋｔＩＤを判定し得る。具体的に述べると、そのパケットのプロトコルレイヤ組合せ（すなわち、プロトコルレイヤスタック）に基づいて、この判定が行われ得る。そのパケットのハッシュ入力レイヤが前述のように形成された後、上記ローカルなテーブルを用いて、対応するＰｋｔＩＤに関連付けられたビットベクトルに基づき、それらのハッシュ入力レイヤから、少なくとも１つのハッシュ入力レイヤが選択され得る。

【0058】

一例として、８’ｂ００００１１１１という数値を有するビットベクトルは、ハッシュ入力レイヤ３からのデータ、ハッシュ入力レイヤ２からのデータ、ハッシュ入力レイヤ１からのデータ、およびハッシュ入力レイヤ０からのデータのみを、ハッシュ入力の形成に用いることを示す。他の例として、８’ｂ１０１０１０１０という数値を有するビットベクトルは、ハッシュ入力レイヤ７からのデータ、ハッシュ入力レイヤ５からのデータ、ハッシュ入力レイヤ３からのデータ、およびハッシュ入力レイヤ１からのデータのみを、ハッシュ入力の形成に用いることを示す。

【0059】

このようなハッシュ命令とビットベクトルとの組合せにより、ハッシュ入力を極めて柔軟に形成することができる。このようにして得られたハッシュ出力は、どの等コストマルチパス経路でパケットを送信するのかを特定するための固有のシグネチャになり得る。

【0060】

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

【0061】

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

【0062】

過程６１５で、拡張後のプロトコルレイヤからコンテンツを選択することにより、当該コンテンツをハッシュ関数に適用する。

【0063】

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

【0064】

過程６６０で、ビットマスクと抽出されたフィールド内の１バイトとの間の論理ＡＮＤ演算を適用する。このビットマスクは、抽出されたフィールドの最上位バイトまたは最下位バイトに適用され得る。また、このビットマスクは、前記少なくとも１つのハッシュ命令によって指定され得る。

【0065】

過程６６５で、少なくとも前記論理ＡＮＤ演算の結果に基づいて、ハッシュ入力レイヤを形成する。

【0066】

過程６７０で、ビットベクトルを取り出す。このビットベクトルは、ローカルなテーブルから取り出す。このビットベクトルは、拡張後のプロトコルレイヤからのハッシュ入力レイヤのうち、どのハッシュ入力レイヤを用いて、ハッシュ関数に対するハッシュ入力を形成すべきなのかを示し得る。このようにして得られたハッシュ入力は、ハッシュ関数に対する入力として用いられ得る。そして、このハッシュ関数の出力は、どのＥＣＭＰ経路でパケットを送信すべきなのかを特定するための固有のシグネチャとなり得る。

【0067】

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

【0068】

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

【0069】

過程７１５で、汎用化後の各プロトコルヘッダについて、その汎用化後のプロトコルヘッダから、１つ以上のフィールドを抽出する。この１つ以上のフィールドを抽出するために、１つ以上の汎用的なハッシュ命令を、汎用化後のプロトコルヘッダに適用し得る。フィールドを抽出するために、１つ以上の汎用的なハッシュ命令を、汎用化後のプロトコルヘッダに適用し得る。汎用的なハッシュ命令の各ハッシュ命令におけるフィールドは、拡張後のレイヤ内において抽出すべきフィールドが開始するオフセットを指定するフィールドオフセット（ｆｉｅｌｄＯｆｆｓｅｔ）、その指定されるオフセットからの抽出すべきバイト数を指定するフィールド長さ（ｆｉｅｌｄＬｅｎ）、ビットマスクであるハッシュマスク（ｈａｓｈＭａｓｋ）、およびこのビットマスクを抽出されるフィールドの最上位バイトに適用すべきか最下位バイトに適用すべきかを示すハッシュマスクＭＳＢ（ｈａｓｈＭａｓｋＭＳＢ）であり得る。

【0070】

過程７２０で、汎用化後の各プロトコルヘッダについて、その汎用化後のプロトコルヘッダから抽出された１つ以上のフィールドを連結することにより、ハッシュレイヤを形成する。一部の実施形態では、過程７１５以降であって過程７２０以前に、ビットマスクと抽出されたフィールド内の１バイトとの間の論理ＡＮＤ演算を適用する。このビットマスクは、汎用的なハッシュ命令によって指定され得る。

【0071】

過程７２５で、ビットベクトルを用いることにより、拡張後の全てのプロトコルヘッダからのハッシュレイヤのうち、どのハッシュレイヤを選択してハッシュ入力を形成すべきなのかを決定する。一部の実施形態では、過程７２５に先立って、パケットのＰｋｔＩＤを用いてローカルなテーブルを参照する。このテーブルは、既知のプロトコルレイヤ組合せごとにビットベクトルを記憶し得る。このようにして得られたハッシュ入力は、ハッシュ関数に対する入力として用いられ得る。そして、このハッシュ関数の出力は、どのＥＣＭＰ経路でパケットを送信すべきなのかを特定するための固有のシグネチャとなり得る。

【0072】

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

【0073】

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

【図1】

【図2A】

【図2B】

【図3A】

【図3B】

【図3C】

【図4A】

【図4B】

【図4C】

【図5】

【図6A】

【図6B】

【図7】