JP6678401B2 - 変更のためにパケットを個々のレイヤに分割し、変更後のレイヤを情報処理で継合する方法およびその装置 - Google Patents

Description

本発明は、パケットのヘッダの変更（modification）技術に関する。詳細には、本発明は、変更のためにパケットを個々のレイヤに分割し、変更後のレイヤを情報処理で（知的に）継合する方法およびその装置に関する。

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

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

各実施形態において、パケットのヘッダを変更する装置は、パケットを個々のレイヤに分割すると共にこれらのレイヤを情報処理で継合するのに用いられるポインタ構造に関する。なお、情報処理とは、情報を含むデータに対して、コンピューターにより計算・分類・照合その他の処理を行うことをいう。上記ポインタ構造は、Ｎ＋１個のプロトコルヘッダに対するＮ＋１個のレイヤポインタを含む。このポインタ構造は、さらに、全てのヘッダの合計サイズを含む。リライトエンジンが、これらレイヤポインタを用いて、パケット内の各対応する先頭からＮ個のプロトコルレイヤを、変更用に抽出する。リライトエンジンは、さらに、これらレイヤポインタを用いて、上記全てのヘッダの合計サイズと共にそのヘッダのボディと関連付けられる終点を形成する。ヘッダのボディとは、そのヘッダにおいて上記リライトエンジンにより変更されない部分のことである。全ての変更が実行されて、変更されたヘッダが圧縮されると、同じく変更された上記レイヤポインタを用いて、それら変更後のヘッダ同士がそれらのボディと一緒に継合される。

一態様では、リライトエンジンの動作方法が提供される。このリライトエンジンは、ネットワークスイッチに含まれてもよい。この方法は、各パケットに対するポインタ構造を保持する過程を含む。このポインタ構造は、レイヤポインタおよびそのパケット内の全てのヘッダの合計サイズを含む。レイヤポインタは、パケット内のそのレイヤの開始位置に一致する。

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

前記方法は、さらに、パケットを、レイヤの変更のために、前記レイヤポインタに基づいてレイヤに分割する過程を含む。一部の実施形態では、パケットをレイヤに分割する過程が、そのパケットのプロトコルヘッダから、欠けているフィールドを検出すること、前記プロトコルヘッダを、前記検出の結果に基づいて、そのプロトコルの汎用フォーマットに拡張すること、および汎用的な命令のセットから、少なくとも１つの命令を用いることであって、これにより、汎用化後のプロトコルヘッダを変更することを含む。

一部の実施形態では、前記汎用フォーマットが、前記プロトコルについて想定される全てのフィールド（前記プロトコルにおいて存在し得るフィールド全て）を備えている。それら各フィールドのオフセットは、前記プロトコルヘッダのプロトコルの変種にかかわらず同一であり得る。

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

一部の実施形態では、少なくとも１つの命令を用いることが、前記変更後に前記ビットベクトルを更新することを含む。

前記方法は、さらに、前記レイヤポインタを、レイヤの変更に基づいて更新する過程を含む。

前記方法は、さらに、複数のレイヤを、更新後のレイヤポインタに基づいて互いに継合する過程を含む。

他の態様では、ネットワークスイッチの動作方法が提供される。この方法は、前記ネットワークスイッチの受信ポートでパケットを受信する過程と、ポインタ構造を用いることにより、前記パケットのプロトコルレイヤを互いに分離する、過程とを含む。一部の実施形態では、ポインタ構造を用いる過程に先立って、前記パケットをパース処理したデータに基づいて、前記ポインタ構造を初期化する。

一部の実施形態では、前記ポインタ構造が、前記パケット内のＮ＋１個の位置へのＮ＋１個のレイヤポインタ、および当該パケット内の全てのヘッダの合計サイズを含む。前記位置は、プロトコルレイヤの開始位置であり得る。

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

前記方法は、さらに、前記ポインタ構造を、前記変更の結果に基づいて更新する過程と、更新後のポインタ構造を用いることにより、変更後のプロトコルレイヤを情報処理で継合し、新しいプロトコルヘッダスタックを形成する、過程と、前記パケットを、前記新しいプロトコルヘッダスタック付きで、前記ネットワークスイッチの送信ポートから送出する過程とを含む。

さらなる他の態様では、ネットワークスイッチが提供される。このネットワークスイッチは、パケットを送受信する入力ポートおよび出力ポートと、パケットをパース処理するパーサエンジンと、前記パケットに対するポインタ構造とを備える。このポインタ構造は、前記パーサエンジンによりパース処理されたデータを用いて初期化される。

一部の実施形態では、前記ポインタ構造が、レイヤポインタおよび前記パケット内のプロトコルヘッダスタックの合計サイズを含む。前記レイヤポインタのそれぞれが、前記パケット内のあるレイヤを指示し得る。

前記ネットワークスイッチは、さらに、前記ポインタ構造を用いて、前記パケットを、汎用化後のプロトコルレイヤの変更のために個々のレイヤに分割し、さらに、変更後のレイヤを互いに継合することにより新しいプロトコルヘッダスタックを形成するリライトエンジンを備える。

一部の実施形態では、前記リライトエンジンが、前記変更後に前記ポインタ構造を更新する。一部の実施形態では、前記新しいプロトコルヘッダスタックが、更新後のポインタ構造に基づいて形成される。

一部の実施形態において、前記ネットワークスイッチは、さらに、メモリを備える。一部の実施形態では、前記メモリが、前記個々のレイヤを汎用化するための、プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングのセットを記憶する。一部の実施形態では、前記メモリが、受信時のヘッダにかかわらずヘッダの変更を行うための汎用的な命令のセットを記憶する。

さらなる他の態様では、ネットワークスイッチが提供される。このネットワークスイッチは、ボディおよびプロトコルスタックを有するパケットを受信する入力ポートを備える。前記ネットワークスイッチは、さらに、変更後のパケットを送信する出力ポートを備える。

前記ネットワークスイッチは、さらに、プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングのセット、および受信時のヘッダにかかわらずヘッダの変更を行うための汎用的な変更命令のセットを記憶するメモリを備える。

前記ネットワークスイッチは、さらに、パケットをパース処理するパーサエンジンと、前記パケットに対するポインタ構造とを備える。典型的に、このポインタ構造は、前記パーサエンジンによりパース処理されたデータを用いて初期化される。

前記ネットワークスイッチは、さらに、リライトエンジンを備える。このリライトエンジンは、前記ポインタ構造を用いて、前記パケットをプロトコルレイヤに基づいて分割することにより、当該パケットの各プロトコルレイヤを互いに分離する。一部の実施形態では、前記ポインタ構造が、前記パケット内のＮ＋１個の位置へのＮ＋１個のレイヤポインタ、および当該パケット内の全てのヘッダの合計サイズを含む。一部の実施形態では、前記位置が、プロトコルレイヤの開始位置である。

前記リライトエンジンは、各プロトコルヘッダを、ソフトウェア定義のマッピングの前記セットのうちの１つに基づいて、汎用フォーマットに変換する。一部の実施形態では、前記リライトエンジンが、さらに、変換後の各プロトコルヘッダに対するビットベクトルを保持する。前記ビットベクトルは、変換後のプロトコルヘッダの各バイトに対して１ビットを有し得る。

前記リライトエンジンは、汎用的な変更命令の前記セットを用いて、変換後のプロトコルヘッダを変更し、変更後のプロトコルヘッダを互いに継合して、新しいプロトコルヘッダスタックを形成する。一部の実施形態では、前記リライトエンジンが、前記新しいプロトコルヘッダスタックを、前記出力ポートから送信される前記ボディに付加する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (27)

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. 請求項２２に記載のネットワークスイッチにおいて、前記リライトエンジンが、前記新しいプロトコルヘッダスタックを、前記出力ポートから送信される前記ボディに付加する、ネットワークスイッチ。

Images