JP6594672B2 - 汎用的な変更の指示を用いて、パケットの柔軟な変更を可能にする方法およびその装置 - Google Patents

Description

本発明は、パケットのヘッダの変更（modification）技術に関する。詳細には、本発明は、汎用的な変更の指示を用いて、パケットの柔軟な変更を可能にする方法およびその装置に関する。

ネットワークパケット（ネットワーク上のパケット）は、伝送制御プロトコル／インターネットプロトコル／イーサネットプロトコル（ＴＣＰ／ＩＰ／Ethernet（イーサネット））等のインターネットが用いるプロトコルを用いてデータを伝達する。典型的なスイッチは、受信したパケットに対し、そのパケットにおける様々なフィールドに変更を施してから、当該パケットをその宛先や別のスイッチに送出する。受信したパケットに変更を施す理由としては、当該パケットの転送先、宛先がサポートするプロトコル、パケットの優先度、受信時のプロトコルヘッダのフォーマット等がある。ネットワークプロトコルの進化にともない、プロトコルヘッダにおける１つ以上のフィールドが、任意のフィールド（オプションフィールド）とされる場合がある。したがって、プロトコルヘッダ内のフィールドのオフセットが常に一定であるとは限らないため、スイッチのハードウェアの複雑化につながる。

また、従来のスイッチは、パケットの変更時に、そのパケット内の各プロトコルレイヤを順次に処理する。しかし、このような処理構成では、レイテンシも含め、ネットワーク関連の様々なパフォーマンス問題が生じる可能性がある。その場合、大量の処理リソースの消費に繋がりかねない。

各実施形態において、パケットのヘッダを変更する装置は、汎用化後のプロトコルヘッダに命令を適用することにより、パケットのプログラマブルな変更を可能にする技術に関する。具体的に述べると、受信パケットにおける各プロトコルヘッダを、そのプロトコルに特有である汎用フォーマットで表現することにより、当該パケットのヘッダを変更可能にする。詳細には、プロトコルヘッダから、欠けているフィールドを検出し、この欠けているフィールドも含め、想定されるフィールド全て（存在し得るフィールド全て）を備える最大サイズに、そのプロトコルヘッダを拡張する。この各フィールドのオフセットは、そのプロトコルヘッダのプロトコルの変種にかかわらず同一である。変更は、拡張後のプロトコルヘッダに適用され得る命令のセットを用いる。このように、これらの命令は受信時のヘッダ（例えば、サイズ、プロトコルなど）に影響されないことから、いずれも汎用的な命令であると言える。

一態様では、ネットワークスイッチのリライトエンジンの動作方法が提供される。この方法は、パケットの各プロトコルヘッダを、当該プロトコルヘッダ用の汎用フォーマットに従って汎用化する過程を含む。この汎用フォーマットは、前記プロトコルについて想定されるフィールド全て（前記プロトコルにおいて存在し得るフィールド全て）を備える。よって、それら各フィールドのオフセットは、そのプロトコルヘッダのプロトコルの変種にかかわらず同一であり得る。汎用化後の各プロトコルヘッダは、ビットベクトルを備える。このビットベクトルは、汎用化後のプロトコルヘッダの各バイトに対して１ビットを有し得る。このビットベクトルは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされる。ここで、無効フィールドとは、受信時のパケットの前記プロトコルヘッダ内に存在しないフィールドであり、有効フィールドとは、受信時のパケットの前記プロトコルヘッダ内に存在するフィールドである。

前記方法は、さらに、前記ネットワークスイッチのメモリに記憶された汎用的な命令のセットから、少なくとも１つの命令を用いて、汎用化後の少なくとも１つのプロトコルヘッダを変更する過程を含む。汎用化後の前記少なくとも１つのプロトコルヘッダを、前記ネットワークスイッチの送信ポートの出口側ポートタイプ（egress portType）に基づいて変更し得る。汎用化後の前記少なくとも１つのプロトコルヘッダを変更すると、前記ビットベクトルが更新され得る。一部の実施形態において、前記方法は、さらに、前記ビットベクトルと更新後の当該ビットベクトルとにＸＯＲ演算を実行することにより、変更のあったビット数を求める過程を含む。

汎用的な命令の前記セットは、受信時のパケットのヘッダにかかわらずヘッダを変更することができる。したがって、汎用的な命令の前記セットは、あるプロトコルの第１の変種のパケットヘッダを変更するために、かつ、当該プロトコルの第２の変種のパケットヘッダを変更するために使用可能である。同様に、汎用的な命令の前記セットは、第１のプロトコルのパケットヘッダを変更するために、かつ、第２のプロトコルのパケットヘッダを変更するために使用可能である。

他の態様では、ネットワークスイッチの動作方法が提供される。この方法は、前記ネットワークスイッチのメモリ内に、汎用的な命令のセットを保持する過程を含む。一部の実施形態では、汎用的な命令の前記セットにおける各命令が、ソフトウェアによりプログラム可能なマイクロコードとして実現される（マイクロコードとして機能する）。

一部の実施形態では、汎用的な命令の前記セットが、開始（Ｓｔａｒｔ）およびサイズ（Ｓｉｚｅ）をパラメータとして有するデリート（Ｄｅｌｅｔｅ）命令を含む。前記デリート（Ｄｅｌｅｔｅ）命令は、汎用化後のプロトコルヘッダ内において開始（Ｓｔａｒｔ）位置からサイズ（Ｓｉｚｅ）分のバイトを、前記ビットベクトルにおける当該サイズ（Ｓｉｚｅ）分のバイトに対応するビットを０にマークすることによりデリート（無効化）し得る。

一部の実施形態では、汎用的な命令の前記セットが、ソース（Ｓｏｕｒｃｅ）、ソースオフセット（ＳｏｕｒｃｅＯｆｆｓｅｔ）、サイズ（Ｓｉｚｅ）、宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）、ビットマスク（Ｂｉｔｍａｓｋ）、コピー一定ビットマスク（ｃｏｐｙＣｏｎｓｔａｎｔＢｉｔＭａｓｋ）およびコピー一定データ（ｃｏｐｙＣｏｎｓｔａｎｔＤａｔａ）をパラメータとして有するコピー（Ｃｏｐｙ）命令を含む。前記コピー（Ｃｏｐｙ）命令は、ソース（Ｓｏｕｒｃｅ）のソースオフセット（ＳｏｕｒｃｅＯｆｆｓｅｔ）から、サイズ（Ｓｉｚｅ）分のバイトのデータを、汎用化後のプロトコルヘッダの宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）にコピーし得る。一部の実施形態では、前記コピー（Ｃｏｐｙ）命令が、ビットマスク（Ｂｉｔｍａｓｋ）を用いてビットマスク演算を実行する。一部の実施形態では、コピー一定ビットマスク（ｃｏｐｙＣｏｎｓｔａｎｔＢｉｔＭａｓｋ）が所与のビット位置に「１」を有するとき、コピー一定データ（ｃｏｐｙＣｏｎｓｔａｎｔＤａｔａ）における対応する位置のバイトを、汎用化後のプロトコルヘッダにおける対応する位置にコピーする。一部の実施形態では、コピー一定データ（ｃｏｐｙＣｏｎｓｔａｎｔＤａｔａ）が、前記メモリに記憶され、かつ、ソフトウェアで定義される。対応するコピー先のバイトの有効性がソース（Ｓｏｕｒｃｅ）のデータの有効性に依存し得る。前記ビットベクトルにおいて無効なバイトを表すビットは０にマークされ得て有効なバイトを表すビットは１にマークされ得る。

一部の実施形態では、汎用的な命令の前記セットが、開始オフセット（ＳｔａｒｔＯｆｆｓｅｔ）、宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）およびサイズ（Ｓｉｚｅ）をパラメータとして有する移動（Ｍｏｖｅ）命令を含む。前記移動（Ｍｏｖｅ）命令は、汎用化後のプロトコルヘッダ内において開始オフセット（ＳｔａｒｔＯｆｆｓｅｔ）からサイズ（Ｓｉｚｅ）分のバイトを、宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）に移動し得る。対応する移動先のバイトの有効性がソース（Ｓｏｕｒｃｅ）のデータの有効性に依存し得る。前記ビットベクトルにおいて無効なバイトを表すビットは０にマークされ得て有効なバイトを表すビットは１にマークされ得る。

前記方法は、さらに、前記ネットワークスイッチの受信ポートでパケットを受信する過程と、前記パケットの各プロトコルヘッダを、当該プロトコルヘッダ用の汎用フォーマットに従って汎用化する過程とを含む。この各プロトコルヘッダを汎用化する過程は、前記パケットの前記プロトコルヘッダから、欠けているフィールドを検出すること、およびそのプロトコルヘッダを、前記検出の結果に基づいて、前記欠けているフィールドを含めることにより、前記汎用フォーマットに拡張することを含み得る。汎用化後の各プロトコルヘッダは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされたビットベクトルを備え得る。

前記方法は、さらに、汎用的な命令の前記セットから、少なくとも１つの命令を、汎用化後のプロトコルヘッダに適用することにより、汎用化後の少なくとも１つのプロトコルヘッダを変更する過程であって、これにより、前記ビットベクトルが更新される過程を含む。

前記方法は、さらに、更新後のビットベクトルに基づいて、新しいプロトコルヘッダを形成する過程と、前記パケットを、前記新しいプロトコルヘッダ付きで、前記ネットワークスイッチの送信ポートから送信する過程とを含む。一部の実施形態では、前記パケットを前記新しいプロトコルヘッダ付きで送信する過程に先立って、実行された全てのオペレーション（演算）について、追加された又はデリートされたバイト数を計数する。

さらなる他の態様では、ネットワークスイッチが提供される。このネットワークスイッチは、パケットを送受信する入力ポートおよび出力ポートを備える。

前記ネットワークスイッチは、さらに、汎用的な命令のセットを記憶するメモリを備える。この汎用的な命令のセットは、受信時のヘッダにかかわらずヘッダの変更を行うために用いられる。一部の実施形態では、汎用的な命令の前記セットが、デリート（Ｄｅｌｅｔｅ）命令、コピー（Ｃｏｐｙ）命令および移動（Ｍｏｖｅ）命令を含む。

前記ネットワークスイッチは、さらに、前記パケットを処理するリライトエンジンであって、汎用的な命令の前記セットから、少なくとも１つの命令を用いることにより、当該パケットのそれぞれにおける各プロトコルヘッダを変更用に汎用化するリライトエンジンを備える。

一部の実施形態では、各プロトコルヘッダが、ソフトウェア定義のマッピングのうち、そのプロトコルに特有であるマッピングに従って汎用化される。一部の実施形態では、汎用化後の各プロトコルヘッダが、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされたビットベクトルを備える。

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

パケット内のプロトコルレイヤ組合せの複数例を示す図である。 本発明の一部の実施形態での、ローカルなプロトコルテーブルの構造の一例を示す図である。 本発明の一部の実施形態での、ネットワークスイッチの動作方法の一例を示すフローチャートである。 本発明の一部の実施形態での、ネットワークスイッチの動作方法の他の例を示すフローチャートである。 本発明の一部の実施形態において、受信パケットにおける様々なレイヤのヘッダを汎用フォーマットに拡張する様子を示す図である。 本発明の一部の実施形態での、プロトコルヘッダの汎用化の一例を示す図である。 本発明の一部の実施形態での、プロトコルヘッダの汎用化の一例を示す他の図である。 本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示す図である。 本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示す他の図である。 本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示すさらなる他の図である。 本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示す図である。 本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示す他の図である。 本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示すさらなる他の図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示す図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示す他の図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示すさらなる他の図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示すさらなる他の図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示すさらなる他の図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示すさらなる他の図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の他の例を示す図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の他の例を示す他の図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の他の例を示すさらなる他の図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の他の例を示すさらなる他の図である。 本発明の一部の実施形態での、プロトコルヘッダの変更の他の例を示すさらなる他の図である。 本発明の一部の実施形態での、リライトエンジンの動作方法のフローチャートである。 本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。 本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。 本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。 本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。 本発明の一部の実施形態での、リライトエンジンの他の動作方法のフローチャートである。 本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。 本発明の一部の実施形態での、リライトエンジンのさらなる他の動作方法のフローチャートである。 本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。 本発明の一部の実施形態での、レイヤ構造の一例を示す図である。 本発明の一部の実施形態での、リライトエンジンのさらなる他の動作方法を示すフローチャートである。 本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。

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

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

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

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

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

［パケットの固有の識別子（固有のパケット識別子）］
一部の実施形態において、上記ネットワークスイッチは、１７種類のプロトコルおよび８層のプロトコルレイヤをサポートする。すなわち、８^１７通りのプロトコルレイヤ組合せが想定され得る。図１に、パケット内のプロトコルレイヤ組合せの複数例を示す。一例として、パケットは、イーサネット，ＩＰｖ４，ＩＣＭＰのような３層プロトコルレイヤ組合せを有し得る。他の例として、パケットは、イーサネット，ＩＰｖ４，ＵＤＰ，ＶｘＬＡＮ，イーサネット，ＡＲＰのような７層プロトコルレイヤ組合せを有し得る。

８^１７通りのプロトコルレイヤ組合せが想定されるものの、周知のレイヤ組合せはごく一部である。既知の全てのプロトコルレイヤ組合せが、一意的に特定され、パケット識別子（ＰｋｔＩＤ）と称される固有の番号に翻訳（変換）され得る。上記ネットワークスイッチのメモリに記憶されたプロトコルテーブルは、既知の各プロトコルレイヤ組合せにおける各レイヤのレイヤ情報を含むようにプログラムされ得る。実際的には、ローカルなプロトコルテーブルに含まれるプロトコルレイヤ組合せの数は、２５６未満になり得る。一部の実施形態において、このローカルなプロトコルテーブルに含まれる既知のプロトコルレイヤ組合せの数は、２１２である。しかしながら、このローカルなテーブルは、これを上回る数の又はこれを下回る数のプロトコルレイヤ組合せを含むようにプログラムされてもよい。

図２に、本発明の一部の実施形態での、ローカルなプロトコルテーブル２００の構造の一例を示す。ローカルなテーブル２００内のプロトコルレイヤ組合せのそれぞれは、ＰｋｔＩＤによって索引付けられ、そのプロトコルレイヤ組合せにおける各プロトコルレイヤのレイヤ情報を含み得る。図２では、これらの情報は、レイヤ０情報、レイヤ１情報およびレイヤＮ情報と称されている。このようにＰｋｔＩＤで索引付けすることにより、パケット内のＮ個の全てのレイヤの、どのレイヤについてのレイヤ情報にもアクセス又は取り出すことが可能である。

各プロトコルレイヤのレイヤ情報は、少なくとも：レイヤタイプ（ＬａｙｅｒＴｙｐｅ）；レイヤデータオフセット（ＬａｙｅｒＤａｔａＯｆｆｓｅｔ）；および付帯情報（ＭｉｓｃｅｌｌａｎｅｏｕｓＩｎｆｏｒｍａｔｉｏｎ）；を含む。しかしながら、ローカルなテーブル２００には、より多くの種類の情報が記憶されてもよい。簡単に述べると、レイヤタイプ（ＬａｙｅｒＴｙｐｅ）は、そのプロトコルレイヤのプロトコル（例えば、ＩＰ、ＴＣＰ、ＵＤＰまたはイーサネット）を指す。レイヤデータオフセット（ＬａｙｅｒＤａｔａＯｆｆｓｅｔ）は、そのプロトコルレイヤ内においてレイヤデータが開始する位置（開始位置）を供与する。付帯情報（ＭｉｓｃｅｌｌａｎｅｏｕｓＩｎｆｏｒｍａｔｉｏｎ）は、チェックサム、長さデータ等のデータを含む。

典型的に、上記パーサエンジンは、ネットワークスイッチが受信した受信パケットのＰｋｔＩＤを特定することができる。上記リライトエンジンが、そのＰｋｔＩＤを上記プロトコルテーブルのキーとして用いることにより、そのパケットにおける各プロトコルレイヤを変更用に汎用化するのに必要な全ての情報を、このプロトコルテーブルが当該リライトエンジンに供給し得る。すなわち、上記リライトエンジンは、上記パーサエンジンがパース処理した結果を受け取るのではなく、ＰｋｔＩＤを用いることにより、上記プロトコルテーブル内に存在する、そのパケットの各プロトコルレイヤのレイヤ情報にアクセスし得るか又はそのような情報を上記プロトコルテーブルから取り出し得る。

＜レイヤタイプ＞
レイヤタイプ（ＬａｙｅｒＴｙｐｅ）と、パケットの１つ以上のフィールドについてのハッシュとの固有の組合せにより、上記リライトエンジンに、各プロトコルレイヤの汎用フォーマットが供与され得る。一部の実施形態において、この固有の組合せにより、上記メモリに記憶された、プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングのうちの１つが指定され得る。上記リライトエンジンは、この汎用フォーマットを使用して、プロトコルレイヤの拡張、さらには、ソフトウェア命令を用いてのプロトコルレイヤの変更を行い得る。このレイヤタイプ（ＬａｙｅｒＴｙｐｅ）が、さらに、パケット内においてそのプロトコルレイヤが開始する位置（開始位置）を、上記リライトエンジンに教示し得る。

＜レイヤデータオフセット＞
上記リライトエンジンは、パケット内の所与のデータを用いて、受信ヘッダにおけるレイヤを変更するが、そのパケット内における当該データの位置はどこであってもよい。レイヤのサイズは様々に変化し得るため、上記リライトエンジンによる変更時に必要な、データのオフセット自体も、様々に変化し得る。このことは、リライトエンジンがどのデータをどこから選択できるのかに関してのハードウェア面での柔軟性を低下させる原因となり得る。

受信パケットのヘッダから抽出されるデータは、レイヤ単位で配置される。具体的に述べると、抽出されるデータ構造内において各レイヤデータ構造が開始するオフセット（開始位置）は、ＰｋｔＩＤ毎に固有である。各レイヤのレイヤデータオフセット（ＬａｙｅｒＤａｔａＯｆｆｓｅｔ）は、抽出されるデータについて、その変更時に用いる位置を特定するのに使用され得る。パケット内のレイヤ構造も、レイヤから抽出するデータの位置も、そのパケットのＰｋｔＩＤで特定され得る。このように、ソフトウェアもハードウェアも、抽出されるデータを同じ固有の識別子を用いて管理するので、リライトエンジンの命令を簡略化することが可能になる。

＜付帯情報＞
チェックサム、長さデータ等の付帯情報（ＭｉｓｃｅｌｌａｎｅｏｕｓＩｎｆｏｒｍａｔｉｏｎ）は、チェックサムの再計算およびヘッダの長さの更新などといった、そのプロトコルレイヤの特殊な取扱い要件を、上記リライトエンジンに教示し得る。

パケット汎用化手法は、少数のセットの汎用的な命令を定義することを可能にする。この汎用的な命令のセットは、所与のプロトコルに単に基づくものであり、そのプロトコルレイヤの前後のプロトコルレイヤの影響を受けない。このパケット汎用化手法は、さらに、将来起こり得るプロトコルの改変や追加の影響を受け難い、ハードウェア面での柔軟性をもたらすことができる。

図３に、本発明の一部の実施形態での、ネットワークスイッチの動作方法の一例３００を示す。典型的に、このネットワークスイッチは、前記パーサエンジンおよび前記リライトエンジンを備える。

過程３０５で、前記パーサエンジンが、受信パケットを調べて当該受信パケットのＰｋｔＩＤを特定する。一部の実施形態では、前記パーサエンジンが、そのパケットをパース処理したデータではなく前記ＰｋｔＩＤを前記リライトエンジンに入力する。

過程３１０で、前記リライトエンジンが、前記ネットワークスイッチが受け取る複数のパケットの互いに異なるパケット構造を定義するプロトコルテーブルを参照する。前記リライトエンジンが、前記ＰｋｔＩＤを前記プロトコルテーブルのキーとして用いて、変更に必要な、パケットの各プロトコルレイヤのレイヤ情報を取り出し得る。

過程３１５で、前記リライトエンジンが、前記プロトコルテーブルに記憶されたデータに基づいてパケットを変更する。典型的には、パケットを変更するのに先立って、前記リライトエンジンが、そのパケットの各プロトコルレイヤを拡張する。プロトコルレイヤの拡張および変更の詳細については、後で説明する。

図４に、本発明の一部の実施形態での、ネットワークスイッチの動作方法の他の例４００を示す。典型的に、このネットワークスイッチは、メモリおよび少なくとも１つの受信ポートを備える。

過程４０５で、前記メモリに、プロトコルテーブルを記憶する。このプロトコルテーブルは、複数のパケットの互いに異なるパケット構造を定義する。これらパケット構造のそれぞれは、ＰｋｔＩＤによって索引付けられる。また、これらパケット構造は、プロトコルレイヤ組合せを表し、かつ、そのプロトコルレイヤ組合せにおける各プロトコルレイヤのレイヤ情報を含む。前記プロトコルテーブルは、新しいプロトコルを表した新しいパケット構造を追加するために更新され得る。また、前記プロトコルテーブルは、プロトコルの改変に応答して、パケット構造を変更するために更新され得る。

過程４１０で、前記受信ポートにおいてパケットを受信する。

過程４１５で、そのパケットのＰｋｔＩＤを特定する。一部の実施形態では、前記パーサエンジンが、そのパケットのＰｋｔＩＤを特定する。

過程４２０で、そのパケットの各プロトコルレイヤのレイヤ情報にアクセスする。典型的に、このレイヤ情報は、前記プロトコルテーブル内に存在する。一部の実施形態では、このレイヤ情報を用いることにより、そのパケットのプロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する。この汎用フォーマットは、前記メモリ内にソフトウェアで定義され得る。

既述したように、少なくとも１つの命令を汎用化後のプロトコルヘッダに適用することにより、その汎用化後のプロトコルヘッダを変更することができる。一部の実施形態では、その汎用化後のプロトコルヘッダを変更するのに使用する、データの位置を、前記レイヤ情報を用いて決定する。典型的には、前記ネットワークスイッチの前記リライトエンジンにより、プロトコルヘッダの汎用化、さらには、汎用化後のプロトコルヘッダの変更を行う。

［汎用フォーマット］
略述したように、前記リライトエンジンが、パケットの各プロトコルヘッダを、そのプロトコルに特有である汎用フォーマットで表現することにより、パケットにプログラマブルな変更を可能にする。これにより、パケットのヘッダを変更する際のハードウェア面およびソフトウェア面での柔軟性が向上する。

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

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

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

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

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

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

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

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

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

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

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

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

［仮定１］（受信パケットは単一タグ付きイーサネットパケットであり、送信パケットはタグなしイーサネットパケットであると仮定）
ネットワークスイッチの入力イーサネットポートで受信した、カスタマＶＬＡＮタグ付きのパケットを、タグがない状態で、出力イーサネットポートに送信する場合を考える。図９Ａに、その受信イーサネットポートで受信するパケット内の、イーサネットパケットヘッダのフォーマットの一例９００を示す。その受信イーサネットポートで受信するパケットに対して、ソフトウェアにより、イーサネットヘッダの汎用フォーマットが、｛２２’ｂ１１１１１１＿１１１１１１＿００００＿１１１１＿１１｝であるとプログラムされる。リライトエンジンは、そのヘッダ内のプロトコルレイヤを受け取って前記メモリを参照し、このメモリは、当該ヘッダのプロトコルの汎用フォーマットが｛２２’ｂ１１１１１１＿１１１１１１＿００００＿１１１１＿１１｝であることをハードウェアに認識させる。この場合、ハードウェアでは、先頭から連続する１２個の（いずれも「１」にマークされた）バイトと、４バイト分シフトして後に続く６個の（いずれも「１」にマークされた）バイトとの内容について待ち受ける。前記４バイト分は、ビットベクトルにおいて「０」にマークされた４個のビットに対応する、無効なバイトである。

リライトエンジンは、上記の｛２２’ｂ１１１１１１＿１１１１１１＿００００＿１１１１＿１１｝という汎用フォーマットに基づき、受信されたヘッダにおける前記プロトコルレイヤを、図９Ｂに示す拡張後のヘッダ９０５に拡張し、拡張後のレイヤ９０５の各バイトに対して１ビットを管理する。図９Ｃに、この拡張後のヘッダ９０５に対応するビットベクトル９１０を示す。ビットベクトル９１０は、どのバイトが有効でどのバイトが無効であるかを、前記ハードウェアに認識させる。

本仮定１の送信方針（中継決定）によると、パケットは、タグがない状態で送信することが求められる。前記ハードウェアは、前記送信イーサネットポートの出口側ポートタイプ（egress portType）に基づいて命令テーブルを参照し、当該命令テーブルが、そのハードウェアに、カスタマＶＬＡＮタグをデリート（消去）するように認識させる。カスタマＶＬＡＮタグは、常に決まったオフセット（すなわち、１６）で開始する。命令は汎用フォーマットに適用されるため、カスタマＶＬＡＮタグをデリートする命令は、「位置１６から開始する（カスタマＶＬＡＮタグの）４バイト分をデリートする」という命令になる。前記ハードウェアは、単にその４バイト分を無効であるとマークして、これらをデリートする。図９Ｄに、汎用フォーマットで、タグがない状態のイーサネットヘッダ９１５を示す。図９Ｅに、このタグがない状態のイーサネットヘッダ９１５に対するビットベクトル９２０を示す。前記ハードウェアは、無効なバイトを全て除外することにより、図９Ｆに示すような新しいヘッダ９２５を形成する。そして、パケットが、その新しいヘッダ９２５付きで、前記送信イーサネットポートから送出される。

［仮定２］（受信パケットは二重タグ付きイーサネットパケットであり、送信パケットはタグなしイーサネットパケットであると仮定）
ネットワークスイッチの入力イーサネットポートで受信した、サービスＶＬＡＮタグおよびカスタマＶＬＡＮタグ付きのパケットを、タグがない状態で、出力イーサネットポートに送信する場合を考える。図１０Ａに、その受信イーサネットポートで受信するパケット内の、イーサネットパケットヘッダのフォーマットの一例１０００を示す。その受信イーサネットポートで受信するパケットに対して、ソフトウェアにより、イーサネットヘッダの汎用フォーマットが、｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿１１１１＿１１｝であるとプログラムされる。リライトエンジンは、そのヘッダ内のプロトコルレイヤを受け取って前記メモリを参照し、このメモリは、当該ヘッダのプロトコルの汎用フォーマットが｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿１１１１＿１１｝であることをハードウェアに認識させる。この場合、ハードウェアは、連続する２２個の（いずれも「１」にマークされた）バイトの内容について待ち受ける。

リライトエンジンは、上記の｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿１１１１＿１１｝という汎用フォーマットからみて、このプロトコルヘッダが既に最大サイズを有していることから、受信されたヘッダにおける前記プロトコルレイヤを拡張する必要がない。図１０Ｂに、このヘッダ１０００に対応するビットベクトル１００５を示す。ビットベクトル１００５は、どのバイトが有効でどのバイトが無効であるかを、前記ハードウェアに認識させる。

本仮定２の送信方針によると、パケットは、タグがない状態で送信することが求められる。前記ハードウェアは、前記送信イーサネットポートの出口側ポートタイプに基づいて命令テーブルを参照し、当該命令テーブルが、そのハードウェアに、カスタマＶＬＡＮタグおよびサービスＶＬＡＮタグをデリートするように認識させる。カスタマＶＬＡＮタグは、常に決まったオフセット（具体的には、１６）で開始する。同様に、サービスＶＬＡＮタグは、常に決まったオフセット（具体的には、１２）で開始する。命令は汎用フォーマットに適用されるため、カスタマＶＬＡＮタグおよびサービスＶＬＡＮタグをデリートする命令は、それぞれ、「位置１６から開始する（カスタマＶＬＡＮタグの）４バイト分をデリートする」という命令と、「位置１２から開始する（サービスＶＬＡＮタグの）４バイト分をデリートする」という命令になる。前記ハードウェアは、単にこれら８バイト分を無効であるとマークして、これらをデリートする。図１０Ｃに、汎用フォーマットで、タグがない状態のイーサネットヘッダ１０１０を示す。図１０Ｄに、このタグがない状態のイーサネットヘッダ１０１０に対するビットベクトル１０１５を示す。前記ハードウェアは、無効なバイトを全て除外することにより、図１０Ｅに示すような新しいヘッダ１０２０を形成する。そして、、パケットが、その新しいヘッダ１０２０付きで、前記送信イーサネットポートから送出される。

［仮定３］（受信パケットはタグなしイーサネットパケット、単一タグ付きイーサネットパケットまたは二重タグ付きイーサネットパケットであり、送信パケットは二重タグ付きイーサネットパケットであると仮定）
ネットワークスイッチの入力イーサネットポートで受信した、タグが付いていないパケット、またはサービスＶＬＡＮタグ、カスタマＶＬＡＮタグもしくは両方のタグが付いたパケットを、（別の）二重タグ付きの状態で、出力イーサネットポートに送信する場合を考える。前記受信パケットが二重タグ付きのパケットである場合、ソフトウェアにより、イーサネットヘッダの汎用フォーマットが、、｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿１１１１＿１１｝であるとプログラムされる。前記受信パケットがタグの付いていないパケットである場合、ソフトウェアにより、イーサネットヘッダの汎用フォーマットが、｛２２’ｂ１１１１１１＿１１１１１１＿００００＿００００＿１１｝であるとプログラムされる。前記受信パケットが単一タグ付きのパケットである場合、ソフトウェアにより、イーサネットヘッダの汎用フォーマットが、｛２２’ｂ１１１１１１＿１１１１１１＿００００＿１１１１＿１１｝又は｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿００００＿１１｝であるとプログラムされる。

本仮定３の送信方針によると、パケットは、二重タグ付きで送信することが求められる。前記ハードウェアは、前記送信イーサネットポートの出口側ポートタイプに基づいて命令テーブルを参照し、当該命令テーブルは、そのハードウェアに、カスタマＶＬＡＮタグおよびサービスＶＬＡＮタグをそれぞれ別のものに置き換えるように認識させる。カスタマＶＬＡＮタグは、常に決まったオフセット（具体的には、１６）で開始する。同様に、サービスＶＬＡＮタグは、常に決まったオフセット（具体的には、１２）で開始する。どちらのタグについても、同様の命令が使用される。汎用フォーマットに適用される命令を用いることから、それぞれの命令は「レイヤデータ位置Ｘ（ｌａｙｅｒＤａｔａ．ｌｏｃａｔｉｏｎＸ）から（サービスＶＬＡＮタグの）４バイト分を開始位置（ｓｔａｒｔＬｏｃａｔｉｏｎ）＝１２にコピーする」という命令と「レイヤデータ位置Ｙ（ｌａｙｅｒＤａｔａ．ｌｏｃａｔｉｏｎＹ）から（サービスＶＬＡＮタグの）４バイト分を開始位置（ｓｔａｒｔＬｏｃａｔｉｏｎ）＝１６にコピーする」という命令になる。このとき、レイヤデータ位置Ｘ（ｌａｙｅｒＤａｔａ．ｌｏｃａｔｉｏｎＸ）およびレイヤデータ位置Ｙ（ｌａｙｅｒＤａｔａ．ｌｏｃａｔｉｏｎＹ）によって指定される位置から、それぞれのコンテンツがコピーされる。

以上の仮定１〜３によって示されたとおり、ハードウェア内のリライトエンジンを簡略化することができると共に、メモリ内に設定されるソフトウェア命令を小規模に抑えることができる。これにより、命令を保持するために必要なハードウェアメモリを浅く（小容量）にすることができる。

図１１に、本発明の一部の実施形態での、リライトエンジンの動作方法１１００を示す。過程１１０５で、リライトエンジンにより、受信パケットのプロトコルヘッダから、欠けているフィールドを検出する。

過程１１１０で、リライトエンジンにより、前記プロトコルヘッダを、前記検出の結果に基づいて、そのプロトコルの汎用フォーマットに拡張する。前記汎用フォーマットは、前記プロトコルについて想定されるフィールドを全て備えている。それら各フィールドのオフセットは、前記プロトコルヘッダのプロトコルの変種にかかわらず同一である。リライトエンジンは、拡張後のプロトコルヘッダに対するビットベクトルを保持し、当該ビットベクトルは、その拡張後のプロトコルヘッダの各バイトに対して１ビットを有する。リライトエンジンにより、有効フィールドにおける全てのバイトに対する各ビットを、有効であるとマークする。有効フィールドは、前記受信パケットの前記プロトコルヘッダ内に存在するフィールドである。リライトエンジンにより、無効フィールドにおける全てのバイトに対する各ビットを、無効であるとマークする。無効フィールドは、前記受信パケットの前記プロトコルヘッダ内に存在しないフィールドである。

一部の実施形態では、過程１１０５および過程１１１０を、前記受信パケットの各プロトコルレイヤに対して実行する。

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

過程１２１０で、パケットのプロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する。具体的に説明すると、既述したように、そのプロトコルヘッダが、前記ネットワークスイッチの前記メモリに記憶された前記マッピングのうちの１つに従ってハードウェアにより拡張される。拡張後のプロトコルヘッダに対するビットベクトルが、どのバイトが有効でどのバイトが無効であるかを、そのハードウェアに認識させる。

過程１２１５で、少なくとも１つの命令を、汎用化後のプロトコルヘッダに適用することにより、当該汎用化後のプロトコルヘッダを変更する。具体的に説明すると、既述したように、ハードウェアが、送信イーサネットポートの出口側ポートタイプに基づいて命令テーブルを参照することにより、そのプロトコルヘッダに適用すべき前記少なくとも１つの命令を決定する。

過程１２２０で、変更後のプロトコルヘッダにおける無効なバイトを全て除外することにより、新しいヘッダを形成する。

過程１２２５で、前記パケットを、前記新しいヘッダ付きで、前記ネットワークスイッチの送信ポートから送出する。

図１３に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１３００を示す。過程１３０５で、プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングを有するように、このネットワークスイッチを構成する。具体的に述べると、前記ソフトウェア定義のマッピングを、そのネットワークスイッチのメモリに記憶する。

過程１３１０で、前記ネットワークスイッチの受信ポートでパケットを受信する。

過程１３１５で、前記パケットのプロトコルヘッダを、前記ソフトウェア定義のマッピングのうちの１つに基づいて汎用化する。

過程１３２０で、汎用化後のプロトコルヘッダに対するビットベクトルを保持する。このビットベクトルは、その汎用化後のプロトコルヘッダの各バイトに対して１ビットを有する。

［汎用化後のプロトコルヘッダの最適な表現様式］
受信時の各レイヤに含まれるバイト数は、例えば６４バイトであったり、１２８バイトであったり、あるいは、それ以上にもなり得る。なお、これまでの例における拡張後のイーサネットヘッダのバイト数は、２２バイトであった。プロトコルレイヤ内の全てのバイトをビットベクトルで表そうとすると、プロトコルによっては最悪の場合、メモリを大量に消費することになり、効率が良いとは言えないことがある。現代のシステムオンチップ（ＳＯＣ）設計では、通常、組み込まれるメモリの面積および電力予算がチップ全体の予算を大きく占める。そのため、限られたメモリリソースを効率的に利用することが重要となる。

「ホール」すなわち無効なバイトが少ないプロトコルが大半を占める場合、ヘッダの汎用フォーマットを、連続するバイトの計数値と、それ以降の連続しないバイトを表した小規模のビットベクトルと、で表現するほうが低コストになる。一部の実施形態において、この小規模のビットベクトルのサイズは、プログラマブルであるが、典型的には一定とされる。このサイズは、１つのプロトコルのこのような表現において記憶する必要がある非連続バイトの個数の最大値を、複数のプロトコルの統計から求めて調節可能であり得る。

一部の実施形態において、パケットの汎用フォーマットは、連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ）フィールドとビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドとの２つのフィールドを有するデータ構造を用いた表現により、最適に表現することができる。連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ）フィールドは、そのプロトコルレイヤ内において先頭から連続する有効なバイトの個数を表す。ビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドは、そのプロトコルレイヤの各バイトをビットで表したものである。詳細には、このビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドは、「ホール」すなわち無効なバイトを示す。ビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドは、全てのプロトコルとは言わないが、ほぼ全てのプロトコルに対処することができる。このように、最適な表現とは、｛連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ），ビットベクトル（ｂｉｔｖｅｃｔｏｒ）｝による表現である。このデータ構造は、プロトコルヘッダのサイズにに影響されない。

一例として、図６Ｂのビットベクトル６０５は｛２２，００００＿００００＿００００＿００００｝とコンパクトに表現することができる。これは、図６Ａのイーサネットパケットヘッダ６００の先頭から連続するバイト数が２２であることを表している。そのビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドは、無効なバイトがないので全て「０」である。

他の例として、図７Ｃのビットベクトル７０５は｛１２，００００＿１１１１＿１１００＿００００｝とコンパクトに表現することができる。これは、図７Ｂの拡張後のイーサネットパケットヘッダ７００’の先頭から連続するバイト数が１２であり、その次に無効なバイトが４個続いてから、有効なバイトが６個続くことを表している。

さらなる他の例として、図８Ｃのビットベクトル８０５は｛１２，００００＿００００＿１１００＿００００｝とコンパクトに表現することができる。これは、図８Ｂの拡張後のイーサネットパケットヘッダ８００’の先頭から連続するバイト数が１２であり、その次に無効なバイトが８個続いてから、有効なバイトが２個続くことを表している。

図１４に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１４００を示す。過程１４０５で、拡張後のプロトコルヘッダを得る。既述したように、拡張後のプロトコルヘッダとは、受信パケットのプロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化したものである。典型的に、プロトコルヘッダの汎用化は、リライトエンジンが、そのプロトコルヘッダから欠けているフィールドを検出し、さらに、そのプロトコルヘッダを、当該検出の結果に基づいて汎用フォーマットに従って拡張することで実行される。汎用フォーマットは、そのプロトコルについて想定される全てのフィールドを備えている。それら各フィールドのオフセットは、そのプロトコルヘッダのプロトコルの変種にかかわらず同一である。

過程１４１０で、拡張後のプロトコルヘッダの表現を保持する。この表現は、連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ）フィールドとビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドとを有するデータ構造である。

過程１４１５で、連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ）フィールドを、拡張後のプロトコルヘッダの先頭から連続する有効なバイト数に設定する。

過程１４２０で、ビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドについて、前記連続する有効なバイトの後の、無効フィールドにおける全てのバイトに対する各ビットを、無効であるとマークする。無効フィールドのそれぞれは、前記受信パケットのプロトコルヘッダ内に存在しないフィールドである。

過程１４２５で、ビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドについて、前記連続する有効なバイトの後の、有効フィールドにおける全てのバイトに対する各ビットを、有効であるとマークする。有効フィールドのそれぞれは、前記受信パケットのプロトコルヘッダ内に存在するフィールドである。

図１５に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１５００を示す。過程１５０５で、このネットワークスイッチの受信ポートでパケットを受信する。

過程１５１０で、そのパケットのプロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する。典型的に、プロトコルの汎用化は、リライトエンジンにより実行される。

過程１５１５で、汎用化後のプロトコルヘッダを、そのプロトコルヘッダのサイズに影響されないデータ構造で表現する。一部の実施形態において、このデータ構造は、プロトコルレイヤの先頭から連続する有効なバイト数を表した連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ）フィールドと、そのプロトコルヘッダの各バイトをビットで表したビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドとを有する。

このようなデータ構造を用いることにより、各種プロトコルレイヤを表す汎用的な表現を、プロトコルレイヤヘッダのサイズに影響されない表現とすることができる。また、ビットベクトルをコンパクトに表現するので、ハードウェアコストを削減することができて有利である。

［ヘッダの変更に用いる汎用的な命令］
変更は、拡張後のプロトコルヘッダに適用され得る汎用的な命令のセットを用いる。これら命令は、受信時のヘッダ（例えば、サイズ、プロトコルなど）に影響されないので、いずれも汎用的な命令であると言える。

以下の表１に、リライトエンジンがプロトコルヘッダの変更のために使用する、汎用的な命令の一覧を示す。このように、少数セットの汎用的な命令を、受信時のパケットのヘッダ（例えば、サイズ、プロトコルなど）にかかわらずヘッダの変更に用いることができるのは、その変更対象のパケットのヘッダが変更に先立って汎用化されているからである。典型的に、これら汎用的な命令は、ソフトウェアによりプログラム可能なマイクロコードのように機能する。

デリート（ＤＥＬＥＴＥ）命令は、汎用化後のプロトコルレイヤ内において開始（Ｓｔａｒｔ）位置からサイズ（Ｓｉｚｅ）分のバイトを、無効なバイトとすることによりデリートし得る。具体的に述べると、ビットベクトルのうち、これらのバイトに対応するビットが０にマークされ得る。

コピー（ＣＯＰＹ）命令は、ソース（Ｓｏｕｒｃｅ）のソースオフセット（ＳｏｕｒｃｅＯｆｆｓｅｔ）から、サイズ（Ｓｉｚｅ）分のバイトのデータを、汎用化後のプロトコルレイヤの宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）にコピーし得る。また、コピー（ＣＯＰＹ）命令は、ソース（Ｓｏｕｒｃｅ）のデータの有効性に応じて、対応するコピー先のバイトを有効なバイト又は無効なバイトにし得る。具体的に述べると、ビットベクトルにおいて無効なバイトを表すビットが０にマークされ得る。ビットベクトルにおいて有効なバイトを表すビットが１にマークされ得る。また、コピー（ＣＯＰＹ）命令は、ビットマスク（Ｂｉｔｍａｓｋ）を用いてビットマスク演算を実行可能であり得る。また、コピー（ＣＯＰＹ）命令は、コピー一定ビットマスク（ｃｏｐｙＣｏｎｓｔａｎｔＢｉｔＭａｓｋ）およびコピー一定データ（ｃｏｐｙＣｏｎｓｔａｎｔＤａｔａ）を使用可能であり得る。具体的に述べると、コピー一定ビットマスク（ｃｏｐｙＣｏｎｓｔａｎｔＢｉｔＭａｓｋ）が所与のビット位置に「１」を有するとき、コピー一定データ（ｃｏｐｙＣｏｎｓｔａｎｔＤａｔａ）における対応する位置のバイトを、汎用化後のヘッダレイヤにおける対応する位置にコピーし得る。一部の実施形態では、一定データはテーブルに記憶されている。一部の実施形態では、一定データが、ソフトウェアで定義される。

移動（ＭＯＶＥ）命令は、汎用化後のプロトコルレイヤ内において開始オフセット（ＳｔａｒｔＯｆｆｓｅｔ）からサイズ（Ｓｉｚｅ）分のバイトを、宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）に移動し得る。また、移動（ＭＯＶＥ）命令は、ソース（Ｓｏｕｒｃｅ）のデータの有効性に応じて、対応する移動先のバイトを有効なバイト又は無効なバイトにし得る。具体的に述べると、ビットベクトルにおいて無効なバイトを表すビットが０にマークされ得る。ビットベクトルにおいて有効なバイトを表すビットが１にマークされ得る。

少なくとも１つのカウンタ（計数手段）を用いることにより、実行された全ての演算についての追加された又はデリートされたバイト数が計数され得る。この少なくとも１つのカウンタは、ハードウェアカウンタであり得る。あるいは、この少なくとも１つのカウンタは、ソフトウェアカウンタであり得る。この少なくとも１つのカウンタは、統計目的およびその他の目的で、その計数値を監視し得る。一部の実施形態では、リライトエンジンが、変更前のビットベクトルと変更後のビットベクトルとの２つのビットベクトルにＸＯＲ演算を実行することにより、変更のあったビット数をハードウェアに認識させる。この情報は、デリートされた又は追加されたバイトの数の計算に利用され得る。

図１６に、本発明の一部の実施形態での、リライトエンジンの他の動作方法１６００を示す。このリライトエンジンは、ネットワークスイッチの一部であり、パケットをネットワークスイッチから送出される前に変更する。過程１６０５で、パケットの各プロトコルヘッダを、当該プロトコルヘッダの汎用フォーマットに従って汎用化する。この汎用フォーマットは、そのプロトコルについて想定されるフィールド全てを備える。よって、それら各フィールドのオフセットは、そのプロトコルヘッダのプロトコルの変種にかかわらず同一であり得る。汎用化後の各プロトコルヘッダは、ビットベクトルを備え得る。このビットベクトルは、汎用化後のプロトコルヘッダの各バイトに対して１ビットを有し得る。このビットベクトルは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされる。ここで、無効フィールドとは、受信時のパケットのプロトコルヘッダ内に存在しないフィールドであり、有効フィールドとは、受信時のパケットのプロトコルヘッダ内に存在するフィールドである。

過程１６１０で、前記ネットワークスイッチのメモリに記憶された汎用的な命令のセットから、少なくとも１つの命令を用いることにより、汎用化後の少なくとも１つのプロトコルヘッダを変更する。汎用化後の少なくとも１つのプロトコルヘッダを、前記ネットワークスイッチの送信ポートの出口側ポートタイプに基づいて変更し得る。汎用化後の少なくとも１つのプロトコルヘッダを変更すると、ビットベクトルが更新され得る。

汎用的な命令の前記セットは、受信時のパケットのヘッダにかかわらず、ヘッダを変更することができる。したがって、汎用的な命令の前記セットは、あるプロトコルの、第１の変種のパケットヘッダを変更するのにも第２の変種のパケットヘッダを変更するのにも使用され得る。同様に、汎用的な命令の前記セットは、第１のプロトコルのパケットヘッダを変更するのにも第２のプロトコルのパケットヘッダを変更するのにも使用され得る。

図１７に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１７００を示す。過程１７０５で、ネットワークスイッチのメモリ内に、汎用的な命令のセットを保持する。

過程１７１０で、前記ネットワークスイッチの受信ポートでパケットを受信する。

過程１７１５で、前記パケットの各プロトコルヘッダを、当該プロトコルヘッダの汎用フォーマットに従って汎用化する。前記パケットの前記プロトコルヘッダから、欠けているフィールドを検出し得る。そのプロトコルヘッダを、前記検出の結果に基づいて、前記欠けているフィールドを含めることにより、前記汎用フォーマットに拡張し得る。汎用化後の各プロトコルヘッダは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされたビットベクトルを備える。ここで、無効フィールドとは、受信時のパケットのプロトコルヘッダ内に存在しないフィールドであり、有効フィールドとは、受信時のパケットのプロトコルヘッダ内に存在するフィールドである。

過程１７２０で、汎用的な命令の前記セットから、少なくとも１つの命令を、汎用化後のプロトコルヘッダに適用することにより、汎用化後の少なくとも１つのプロトコルヘッダを変更する。これにより、前記ビットベクトルが更新される。

過程１７２５で、更新後のビットベクトルに基づいて、新しいプロトコルヘッダを形成する。

過程１７３０で、前記パケットを、前記新しいプロトコルヘッダ付きで、前記ネットワークスイッチの送信ポートから送信する。一部の実施形態では、前記パケットを前記新しいプロトコルヘッダ付きで送信するのに先立って、実行された全てのオペレーション（演算）について、追加された又はデリートされたバイト数を計数する。

［変更後のプロトコルヘッダの、ビットベクトルを用いての減縮（縮小）］
リライトエンジンは、プロトコルヘッダを変更用の汎用フォーマットに基づいて拡張するためだけに限らず、そのプロトコルヘッダを当該汎用フォーマットから「通常の」フォーマットに減縮するためにも、各プロトコルヘッダに対するビットベクトルを用い得る。典型的に、ビットベクトルの各ビットは、汎用化後のプロトコルヘッダ内の１バイトを表している。ビットベクトルにおいて０にマークされたビットは無効なバイトに対応し、１にマークされたビットは有効なバイトに対応する。汎用化後のプロトコルヘッダに対して全ての命令が実行された後、リライトエンジンが、ビットベクトルを用いて無効なバイトを全て除外することにより、新しいプロトコルヘッダを形成し得る。このように、リライトエンジンは、ビットベクトルを用いて、パケット内のプロトコルヘッダを拡張することも減縮することも可能であり得る。つまり、汎用的な命令のセットを用いることにより、パケットの柔軟な変更が実施可能になり得る。

一例として仮定１を参照すると、図９Ｅのビットベクトル９２０は、図９Ｂの汎用化後のプロトコルヘッダ９０５にデリート（Ｄｅｌｅｔｅ）命令を適用してなる、図９Ｄの変更後のプロトコルヘッダ９１５を表している。この仮定１では、カスタマＶＬＡＮタグがデリートされることで、そのカスタマＶＬＡＮタグの４バイト分が無効にされる。すなわち、ビットベクトル９２０において、カスタマＶＬＡＮタグに対応するビットが０にマークされる。全ての命令（仮定１ではデリート（Ｄｅｌｅｔｅ）命令）が実行された後、リライトエンジンが、ビットベクトル９２０を用いて無効なバイトを全て除外する。これにより、ビットベクトル９２０が減縮される。減縮後のビットベクトルに基づいて、新しいプロトコルヘッダが形成される。図９Ｆには、無効なバイトが全て除外されてなる新しいプロトコルヘッダ９２５が示されている。仮定１のパケットは、この新しいヘッダ９２５付きで送信イーサネットポートから送出される。

他の例として仮定２を参照すると、図１０Ｄのビットベクトル１０１５は、図１０Ａのプロトコルヘッダ１０００にデリート（Ｄｅｌｅｔｅ）命令を適用してなる、図１０Ｃの変更後のプロトコルヘッダ９１５を表している。この仮定２では、サービスＶＬＡＮタグおよびカスタマＶＬＡＮタグがデリートされることで、それらサービスＶＬＡＮタグの４バイト分およびカスタマＶＬＡＮタグの４バイト分が無効にされる。すなわち、ビットベクトル１０１５において、サービスＶＬＡＮタグに対応するビットおよびカスタマＶＬＡＮタグに対応するビットが０にマークされる。全ての命令（仮定２では２回のデリート（Ｄｅｌｅｔｅ）命令）が実行された後、リライトエンジンが、ビットベクトル１０１５を用いて無効なバイトを全て除外する。これにより、ビットベクトル１０１５が減縮される。減縮後のビットベクトルに基づいて、新しいプロトコルヘッダが形成される。図１０Ｅには、無効なバイトが全て除外されてなる新しいプロトコルヘッダ１０２０が示されている。仮定２のパケットは、この新しいヘッダ１０２０付きで送信イーサネットポートから送出される。

図１８に、本発明の一部の実施形態での、リライトエンジンのさらなる他の動作方法１８００を示す。このリライトエンジンは、ネットワークスイッチの一部であり、パケットをネットワークスイッチから送出される前に変更する。過程１８０５で、汎用化後の各プロトコルヘッダに対するビットベクトルを保持する。汎用化後のプロトコルヘッダとは、パケットのうち、汎用フォーマットに拡張されたプロトコルヘッダのことである。この汎用フォーマットは、そのプロトコルについて想定される全てのフィールドを備えている。それら各フィールドのオフセットは、そのプロトコルヘッダのプロトコルの変種にかかわらず同一であり得る。前記ビットベクトルは、汎用化後のプロトコルヘッダの各バイトに対して１ビットを有し得る。

過程１８１０で、汎用化後の少なくとも１つのプロトコルヘッダの前記変更に基づいて、前記ビットベクトルを更新する。その変更過程は、ネットワークスイッチのメモリに記憶された汎用的な命令のセットから、少なくとも１つの命令を用いることにより、汎用化後の少なくとも１つのプロトコルヘッダを変更することを含み得る。

過程１８１５で、更新後のビットベクトルを用いて、汎用化後の少なくとも１つのプロトコルヘッダを圧縮する。一部の実施形態では、過程１８１５に先立って、前記ビットベクトルと更新後の当該ビットベクトルとにＸＯＲ演算を実行することにより、変更のあったビット数を求める。これにより、リライトエンジンは、デリートされたバイトおよび追加されたバイトの数を計算することができる。

図１９に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１９００を示す。過程１９０５で、このネットワークスイッチの受信ポートでパケットを受信する。

過程１９１０で、前記パケットにおける各プロトコルヘッダを、そのプロトコルヘッダの汎用フォーマットに従って汎用化する。前記パケットにおけるそのプロトコルヘッダから、欠けているフィールドを検出し得る。具体的に述べると、そのプロトコルヘッダを、前記検出の結果に基づいて、欠けているフィールドを含めることにより、汎用フォーマットに拡張し得る。

過程１９１５で、汎用化後の各プロトコルヘッダに対するビットベクトルを保持する。このビットベクトルは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされる。

過程１９２０で、汎用化後の少なくとも１つのプロトコルヘッダを変更することにより、前記ビットベクトルが更新される。その変更過程は、ネットワークスイッチのメモリに記憶された汎用的な命令のセットから、少なくとも１つの命令を用いて、汎用化後の少なくとも１つのプロトコルヘッダを変更することを含み得る。具体的に述べると、汎用化後の少なくとも１つのプロトコルヘッダを、ネットワークスイッチの送信ポートの出口側ポートタイプに基づいて変更し得る。

過程１９２５で、更新後のビットベクトルについて、そのビットベクトルにおいて０にマークされたビットを全て除外するようにシフトすることにより、当該更新後のビットベクトルを減縮する。

過程１９３０で、減縮後のビットベクトルに基づいて、コンパクトなプロトコルヘッダを形成する。前記パケットは、少なくともこのコンパクトなプロトコルヘッダ付きで、前記ネットワークスイッチの送信ポートから送出され得る。一部の実施形態では、パケットを送出する過程に先立って、実行された全てのオペレーション（演算）について、追加された又はデリートされたバイト数を計数する。

［ポインタ構造］
受信パケットから、複数の互いに異なるプロトコルレイヤを汎用化のためにそれぞれ抽出したり、これらのプロトコルレイヤの変更後にパケットを再構築したりするのに、ポインタ構造（ポインタ構造体）が使用され得る。このポインタ構造は、Ｎ＋１個のレイヤポインタおよびそのパケット内の全てのヘッダの合計サイズを含み得る。典型的に、このポインタ構造は、パーサエンジンにより供給されるデータを用いて予め更新（初期化）され、リライトエンジンが、そのポインタ構造を用いてパケットを個々のレイヤに分割し、さらに、そのポインタ構造を用いてこれら個々のレイヤを情報処理で（知的に（intelligently））継合する。具体的に述べると、リライトエンジンは、パケットを個々のレイヤに分割した後、プロトコルヘッダを汎用化し、汎用化後のプロトコルヘッダを変更し、さらに、無効なバイトを全て除外することによって汎用化後のプロトコルヘッダを圧縮し得る。リライトエンジンは、レイヤを変更すると、前記レイヤポインタを更新し得る。パケットをネットワークスイッチから送信するのに先立って、更新後のレイヤポインタを用いて、互いに異なるプロトコルレイヤを互いに継合し得る。このようにプロトコルレイヤを互いに継合するため、複数のプロトコルレイヤを実体的には連続させずとも、レイヤポインタによってあたかもプロコルレイヤが連続するかのように扱う（仮想的に連続させる）ことが可能となる。

図２０に、本発明の一部の実施形態での、レイヤ構造の一例２０００を示す。ここでは、受信パケットが、独自ヘッダ（独自プロトコルのヘッダ）、イーサネット、ＩＰｖ４、ＵＤＰ、ＶｘＬＡＮおよびイーサネットの各プロトコルレイヤを有していると仮定する。さらに、ネットワークスイッチのパーサエンジンが最大で８層のレイヤをパース処理可能な一方で、それと並行してリライトエンジンにより変更可能なプロトコルレイヤの層数が、（ソフトウェア要求および／またはハードウェア能力のために）先頭からＮ層（ここでは、Ｎ＝４とする）のプロトコルレイヤに限られるものと仮定する。一部の実施形態において、パーサエンジンは、パケット内における各プロトコルヘッダの開始位置等のデータをリライトエンジンに供給する。

この例におけるリライトエンジンは、パケットの先頭から４層のプロトコルレイヤしか変更できないので、パーサエンジンからの関連データのみを、すなわち、パーサエンジンから独自ヘッダ、イーサネット、ＩＰｖ４およびＵＤＰからなる先頭から４層のプロトコルレイヤに関するデータのみを用い得る。このデータを用いて、そのパケットに対するポインタ構造が初期化され得る。具体的に述べると、レイヤポインタ０（ＬａｙｅｒＰｏｉｎｔｅｒ０）が、そのパケット内における独自ヘッダ（すなわち、レイヤ０）の開始位置である０に設定され、レイヤポインタ１（ＬａｙｅｒＰｏｉｎｔｅｒ１）が、そのパケット内におけるイーサネットヘッダ（すなわち、レイヤ１）の開始位置である１６に設定され、レイヤポインタ２（ＬａｙｅｒＰｏｉｎｔｅｒ２）が、そのパケット内におけるＩＰｖ４ヘッダ（すなわち、レイヤ２）の開始位置である３６に設定され、レイヤポインタ３（ＬａｙｅｒＰｏｉｎｔｅｒ３）が、そのパケット内におけるＵＤＰヘッダ（すなわち、レイヤ３）の開始位置である４８に設定され、レイヤポインタ４（ＬａｙｅｒＰｏｉｎｔｅｒ４）が、リライトエンジンにより変更されない、ヘッダの残りの部分の開始位置である５６に設定され得る。一部の実施形態において、リライトエンジンは、ヘッダのサイズを算出してヘッダサイズ（ＨｅａｄｅｒＳｉｚｅ）（すなわち、全てのヘッダの合計サイズ）を２２３に設定する。

リライトエンジンは、これらのレイヤポインタを用いて、先頭から４層のプロトコルレイヤ（すなわち、独自ヘッダ、イーサネット、ＩＰｖ４およびＵＤＰ）を変更用に汎用化し得る。そして、リライトエンジンは、変更を実施した後、無効なバイトを全て除外することにより、変更後のプロトコルヘッダを圧縮し得る。典型的に、プロトコルヘッダが変更されると、前記レイヤポインタが更新される。

また、これらのレイヤポインタは終点ポインタを形成し得る。前記ヘッダサイズ（ＨｅａｄｅｒＳｉｚｅ）を伴ったこの終点ポインタは、ヘッダのボディに関連付けられる。ヘッダのボディとは、そのヘッダにおいて変更されない部分であって、後で継合するために伝達される部分のことである。全ての変更が実行されて、変更されたヘッダが圧縮されると、同じく変更された前記レイヤポインタを用いて、これら変更後のヘッダ同士がそれらのボディと一緒に継合され得る。

リライトエンジンが変更できるレイヤの層数は限られ得る。一部の実施形態では、リライトエンジンが任意のプロトコルレイヤを拡張できる程度（大きさ）も限られ得る。この実施形態では、リライトエンジンが、２つの隣り合うレイヤポインタ同士を減算することにより、プロトコルレイヤのサイズを抽出する。そのレイヤのサイズがリライトエンジンのハードウェア能力を超えている場合、当該リライトエンジンは、１つ前のレイヤポインタを用いて情報処理でボディを形成し得る。

１つのプロトコルレイヤを拡張できる大きさが最大４０バイトであるにもかかわらず、そのプロトコルのなかで最も大きい変種が６４バイトであると仮定する。一部の実施形態において、リライトエンジンは、変更のためにプロトコルヘッダを最大４０バイトまで拡張する。リライトエンジンは、変更を実施した後、レイヤポインタを用いて、未変更のバイトを変更されたバイトに継合し得る。

レイヤポインタを使用することにより、プロトコルレイヤを１つずつ取り扱うことになるので、ハードウェアのロジックや複雑性を大幅に軽減することができる。具体的に述べると、ハードウェアの命令の範囲を、所与のプロトコルレイヤに絞ることができる。すなわち、命令エンジンが前後のレイヤに影響されないので、各層に必要な命令を増やしたい場合には、命令ハードウェア（命令を含むハードウェア）をマルチパスで利用すればよい。換言すれば、命令の内部状態に命令間で相関性がないことから、複数の命令を並行して利用することができる。同様に、複数層のレイヤを並行して変更することも可能である。

図２１に、本発明の一部の実施形態での、リライトエンジンのさらなる他の動作方法２１００を示す。このリライトエンジンは、ネットワークスイッチの一部であり、パケットをネットワークスイッチから送出される前に変更する。過程２１０５で、各パケットに対するポインタ構造を保持する。このポインタ構造は、レイヤポインタおよびそのパケット内の全てのヘッダの合計サイズを含む。これらレイヤポインタのそれぞれは、パケット内の関連レイヤの開始位置に対応する。

前記ポインタ構造はＮ＋１個のレイヤポインタを含み得る。リライトエンジンにより、パケット内のＮ層のレイヤを変更し得る。前記レイヤポインタは終点を形成し得る。この終点は、前記合計サイズを伴って、ヘッダのボディを示し得る。ヘッダのボディとは、リライトエンジンにより変更されないヘッダ部分である。

過程２１１０で、パケットを、レイヤの変更のために、前記レイヤポインタに基づいてレイヤに分割する。そのパケットのプロトコルヘッダから、欠けているフィールドを検出し得る。このプロトコルヘッダを、前記検出の結果に基づいて、そのプロトコルの汎用フォーマットに拡張し得る。この汎用フォーマットは、そのプロトコルについて想定されるフィールド全てを備えている。それら各フィールドのオフセットは、そのプロトコルヘッダのプロトコルの変種にかかわらず同一であり得る。汎用化後の各プロトコルヘッダは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされたビットベクトルを備え得る。汎用的な命令のセットから、少なくとも１つの命令を用いることにより、汎用化後のプロトコルヘッダを変更し得る。典型的に変更後に前記ビットベクトルを更新する。

過程２１１５で、レイヤポインタを、レイヤの変更の結果に基づいて更新する。

過程２１２０で、複数のレイヤを、更新後のレイヤポインタに基づいて互いに継合する。

図２２に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法２２００を示す。過程２２０５で、このネットワークスイッチの受信ポートでパケットを受信する。

過程２２１０で、ポインタ構造を用いることにより、そのパケットのプロトコルレイヤを互いに分離する。このポインタ構造は、そのパケット内のＮ＋１個の位置へのＮ＋１個のレイヤポインタ、および当該パケット内の全てのヘッダの合計サイズを含み得る。前記位置は、プロトコルレイヤの開始位置であり得る。そのパケットをパース処理したデータに基づいて、前記ポインタ構造を初期化し得る。

過程２２１５で、分離後のプロトコルレイヤを、変更用に汎用化する。各レイヤについて、当該レイヤのサイズを抽出することにより、そのサイズが当該レイヤを変更するためのハードウェア能力を超えているか否かを判断し得る。前記ポインタ構造における２つの隣り合うレイヤポインタ同士を減算することにより、前記サイズを抽出し得る。前記判断の結果に基づいて、前記２つの隣り合うレイヤポインタのうちの先のレイヤポインタを用いてボディを形成し得る。

過程２２２０で、前記ポインタ構造を、変更に基づいて更新する。

過程２２２５で、更新後のポインタ構造を用いることにより、変更後のプロトコルレイヤを情報処理で継合する。これにより、新しいプロトコルヘッダスタックを形成する。

過程２２３０で、前記パケットを、その新しいプロトコルヘッダスタック付きで、ネットワークスイッチの送信ポートから送出する。

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

Claims (25)

1. ネットワークスイッチのリライトエンジンの動作方法であって、
   パケットの各プロトコルヘッダを、当該プロトコルヘッダ用の汎用フォーマットに従って汎用化する過程であって、汎用化後の各プロトコルヘッダは、無効フィールドについてはビットが第１の値にマークされて有効フィールドについてはビットが第２の値にマークされたビットベクトルに対応し、前記汎用フォーマットは、前記プロトコルヘッダのプロトコルによってサポートされる全てのフィールドを含むフォーマットである、過程と、
   当該ネットワークスイッチのメモリに記憶された汎用的な命令のセットから、少なくとも１つの命令を用いて、汎用化後の少なくとも１つのプロトコルヘッダを変更する過程と、
   を含む、方法。
2. 請求項１に記載の方法において、前記フィールドの各々は、前記プロトコルヘッダのプロトコルの変種にかかわらず同一のオフセットを有する、方法。
3. 請求項１に記載の方法において、前記ビットベクトルが、汎用化後のプロトコルヘッダの各バイトに対して１ビットを有する、方法。
4. 請求項１に記載の方法において、汎用化後の前記少なくとも１つのプロトコルヘッダを、当該ネットワークスイッチの送信ポートの出口側ポートタイプ（egress portType）に基づいて変更する、方法。
5. 請求項１に記載の方法において、汎用化後の前記少なくとも１つのプロトコルヘッダを変更すると、前記ビットベクトルが更新される、方法。
6. 請求項１に記載の方法において、汎用的な命令の前記セットが、あるプロトコルの第１の変種のパケットヘッダを変更するために、かつ、当該プロトコルの第２の変種のパケットヘッダを変更するために使用される、方法。
7. 請求項１に記載の方法において、汎用的な命令の前記セットが、第１のプロトコルのパケットヘッダを変更するために、かつ、第２のプロトコルのパケットヘッダを変更するために使用される、方法。
8. ネットワークスイッチの動作方法であって、
   前記ネットワークスイッチのメモリ内に、汎用的な命令のセットを保持する過程と、
   前記ネットワークスイッチの受信ポートでパケットを受信する過程と、
   前記パケットの各プロトコルヘッダを、当該プロトコルヘッダ用の汎用フォーマットに従って汎用化する過程であって、汎用化後の各プロトコルヘッダが、無効フィールドについてはビットが第１の値にマークされて有効フィールドについてはビットが第２の値にマークされたビットベクトルに対応し、前記汎用フォーマットは、前記プロトコルヘッダのプロトコルによってサポートされる全てのフィールドを含むフォーマットである、過程と、
   汎用的な命令の前記セットから、少なくとも１つの命令を、汎用化後のプロトコルヘッダに適用することにより、汎用化後の少なくとも１つのプロトコルヘッダを変更する過程であって、これにより、前記ビットベクトルが更新される過程と、
   更新後のビットベクトルに基づいて、新しいプロトコルヘッダを形成する過程と、
   前記パケットを、前記新しいプロトコルヘッダ付きで、前記ネットワークスイッチの送信ポートから送信する過程と、
   を含む、方法。
9. 請求項８に記載の方法において、汎用的な命令の前記セットにおける各命令が、ソフトウェアによりプログラム可能なマイクロコードとして実現される、方法。
10. 請求項８に記載の方法において、汎用的な命令の前記セットが、開始（Ｓｔａｒｔ）およびサイズ（Ｓｉｚｅ）をパラメータとして有するデリート（Ｄｅｌｅｔｅ）命令を含む、方法。
11. 請求項８に記載の方法において、汎用的な命令の前記セットが、ソース（Ｓｏｕｒｃｅ）、ソースオフセット（ＳｏｕｒｃｅＯｆｆｓｅｔ）、サイズ（Ｓｉｚｅ）、宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）、ビットマスク（Ｂｉｔｍａｓｋ）、コピー一定ビットマスク（ｃｏｐｙＣｏｎｓｔａｎｔＢｉｔＭａｓｋ）およびコピー一定データ（ｃｏｐｙＣｏｎｓｔａｎｔＤａｔａ）をパラメータとして有するコピー（Ｃｏｐｙ）命令を含む、方法。
12. 請求項１１に記載の方法において、前記コピー（Ｃｏｐｙ）命令が、ソース（Ｓｏｕｒｃｅ）のソースオフセット（ＳｏｕｒｃｅＯｆｆｓｅｔ）から、サイズ（Ｓｉｚｅ）分のバイトのデータを、汎用化後のプロトコルヘッダの宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）にコピーする、方法。
13. 請求項１１に記載の方法において、前記コピー（Ｃｏｐｙ）命令が、ビットマスク（Ｂｉｔｍａｓｋ）を用いてビットマスク演算を実行する、方法。
14. 請求項１１に記載の方法において、コピー一定ビットマスク（ｃｏｐｙＣｏｎｓｔａｎｔＢｉｔＭａｓｋ）が所与のビット位置に第３の値を有するとき、コピー一定データ（ｃｏｐｙＣｏｎｓｔａｎｔＤａｔａ）における対応する位置のバイトを、汎用化後のプロトコルヘッダにおける対応する位置にコピーする、方法。
15. 請求項１１に記載の方法において、コピー一定データ（ｃｏｐｙＣｏｎｓｔａｎｔＤａｔａ）が、前記メモリに記憶され、かつ、ソフトウェアで定義される、方法。
16. 請求項１１に記載の方法において、対応する宛先のバイトの有効性がソース（Ｓｏｕｒｃｅ）のデータの有効性に依存し、前記ビットベクトルにおいて無効なバイトを表すビットは前記第１の値にマークされて有効なバイトを表すビットは前記第２の値にマークされる、方法。
17. 請求項８に記載の方法において、汎用的な命令の前記セットが、開始オフセット（ＳｔａｒｔＯｆｆｓｅｔ）、宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）およびサイズ（Ｓｉｚｅ）をパラメータとして有する移動（Ｍｏｖｅ）命令を含む、方法。
18. 請求項１７に記載の方法において、前記移動（Ｍｏｖｅ）命令が、汎用化後のプロトコルヘッダ内において開始オフセット（ＳｔａｒｔＯｆｆｓｅｔ）からサイズ（Ｓｉｚｅ）分のバイトを、宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）に移動する、方法。
19. 請求項１７に記載の方法において、対応する宛先のバイトの有効性がソース（Ｓｏｕｒｃｅ）のデータの有効性に依存し、前記ビットベクトルにおいて無効なバイトを表すビットは前記第１の値にマークされて有効なバイトを表すビットは前記第２の値にマークされる、方法。
20. 請求項８に記載の方法において、各プロトコルヘッダを汎用化する過程が、
    前記パケットのプロトコルヘッダから、欠けているフィールドを検出すること、および
    そのプロトコルヘッダを、前記検出の結果に基づいて、前記欠けているフィールドを含めることにより、前記汎用フォーマットに拡張すること、
    を含む、方法。
21. 請求項２０に記載の方法において、さらに、前記パケットを前記新しいプロトコルヘッダ付きで送信する過程に先立って、
    実行された全てのオペレーションについて、追加された又はデリートされたバイト数を計数する過程、
    を含む、方法。
22. 複数のプロトコルの異なる１つにそれぞれ対応する１つ以上のプロトコルレイヤと共にヘッダをそれぞれ有するパケットを送受信する入力ポートおよび出力ポートであって、前記プロトコルの各々は、フィールドの異なる組合せを有する複数のプロトコルレイヤ変種をサポートし、さらに、前記パケットの前記プロトコルレイヤの各々は、前記プロトコルレイヤが対応する前記プロトコルによってサポートされた前記プロトコルレイヤ変種のうちの１つである、入力ポートおよび出力ポートと、
    前記プロトコルのうちの１つにそれぞれ関連付けられ、ヘッダの変更を行うために用いられる汎用的な命令のセットを記憶するメモリと、
    前記プロトコルレイヤがどの前記プロトコルレイヤ変種を含むかに関わらず、前記プロトコルレイヤの前記プロトコルに関連する前記汎用的な命令の少なくとも１つを適用することによって、前記プロトコルレイヤの各々を変更するリライトエンジンと、
    を備える、ネットワークスイッチ。
23. 請求項２２に記載のネットワークスイッチにおいて、ソフトウェア定義のマッピングのうち、前記プロトコルレイヤを前記プロトコルレイヤの前記プロトコルによってサポートされた全てのフィールドを含む汎用フォーマットに変換することで前記プロトコルレイヤに対応する前記プロトコルのうちの１つに特有であるマッピングに従って、前記ヘッダの各プロトコルレイヤが、前記リライトエンジンによって汎用後のプロトコルレイヤに汎用化される、ネットワークスイッチ。
24. 請求項２２に記載のネットワークスイッチにおいて、汎用化後の各プロトコルレイヤが、無効フィールドについてはビットが第１の値にマークされて有効フィールドについてはビットが第２の値にマークされたビットベクトルを備える、ネットワークスイッチ。
25. 請求項２２に記載のネットワークスイッチにおいて、前記汎用的な命令のセットが、デリート（Ｄｅｌｅｔｅ）命令、コピー（Ｃｏｐｙ）命令および移動（Ｍｏｖｅ）命令を含む、ネットワークスイッチ。

Images