(57)【特許請求の範囲】
【請求項１】
ネットワークスイッチであって、
パケットのヘッダのプロトコルレイヤの複数の組合せにわたるパケット情報を保持するパケットプロトコルレイヤ識別子手段であって、前記情報が、当該ネットワークスイッチのメモリに記憶されたプロトコルテーブル内に保持され、更に、前記プロトコルレイヤの組合せの各々は異なる固有の識別子（ＰｋｔＩＤ）に関連付けられ、前記情報は固有の識別子（ＰｋｔＩＤ）に従って前記プロトコルテーブル内で索引付けられる、パケットプロトコルレイヤ識別子手段と、
リライトエンジンであって、複数のパケットの内の１つのパケットの固有の識別子（ＰｋｔＩＤ）を前記プロトコルテーブルのキーとして用いて、そのパケットの変更時に必要な、当該パケットのヘッダのプロトコルレイヤの組合せの各プロトコルレイヤについての前記情報にアクセスする、リライトエンジンと、
を備える、ネットワークスイッチ。
【請求項２】
請求項１に記載のネットワークスイッチにおいて、前記プロトコルテーブルの各エントリが、互いに異なるプロトコルレイヤ組合せの異なる１つのためにレイヤ情報を有する、ネットワークスイッチ。
【請求項３】
請求項１に記載のネットワークスイッチにおいて、前記パケット情報が、ソフトウェアで定義される、ネットワークスイッチ。
【請求項４】
請求項１に記載のネットワークスイッチにおいて、さらに、
前記リライトエンジンに、前記固有の識別子を供給するパーサエンジン、
を備える、ネットワークスイッチ。
【請求項５】
パケットを受信する入力ポートであって、各パケットは複数のパケット識別子（ＰｋｔＩＤ）の１つ及び異なるプロトコルに各々が関連付けられる１以上のプロトコルレイヤの組合せを有するヘッダを含み、各ＰｋｔＩＤは前記組合せの１つを識別する、入力ポートと、
ＰｋｔＩＤによって索引付けられた複数のエントリを含むプロトコルテーブルを記憶するメモリであって、エントリの各々がエントリが索引付けられるＰｋｔＩＤによって識別される組合せ及び各プロトコルレイヤのレイヤ情報を記述する、メモリと、
前記入力ポートで受信された各パケットのＰｋｔＩＤを特定するパーサエンジンと、
前記ＰｋｔＩＤを前記プロトコルテーブルのキーとして用いて、そのパケットを変更するのに必要な、当該パケットのプロトコルレイヤの組合せを記述するエントリの各プロトコルレイヤの情報にアクセスするリライトエンジンと、
を備える、ネットワークスイッチ。
【請求項６】
請求項５に記載のネットワークスイッチにおいて、前記エントリのそれぞれが、ＰｋｔＩＤによって前記プロトコルテーブル内で索引付けられる、ネットワークスイッチ。
【請求項７】
請求項５に記載のネットワークスイッチにおいて、前記レイヤ情報が、パケット内の１つのレイヤのプロトコルおよびそのパケット内での当該レイヤの開始位置を示すレイヤタイプ（ＬａｙｅｒＴｙｐｅ）を含む、ネットワークスイッチ。
【請求項８】
請求項７に記載のネットワークスイッチにおいて、前記レイヤタイプ（ＬａｙｅｒＴｙｐｅ）と、パケットの１つ以上のフィールドについてのハッシュとの固有の組合せにより、前記リライトエンジンに、そのパケットにおける当該レイヤのフォーマットが供与される、ネットワークスイッチ。
【請求項９】
請求項８に記載のネットワークスイッチにおいて、前記固有の組合せにより、前記メモリに記憶された、プロトコルのフォーマットについてのソフトウェア定義のマッピングのうちの１つが指定される、ネットワークスイッチ。
【請求項１０】
請求項５に記載のネットワークスイッチにおいて、前記レイヤ情報が、レイヤデータの開始位置を与えるレイヤデータオフセット（ＬａｙｅｒＤａｔａＯｆｆｓｅｔ）を含む、
ネットワークスイッチ。
【請求項１１】
請求項５に記載のネットワークスイッチにおいて、前記レイヤ情報が、チェックサムおよび長さデータを有する付帯情報（ＭｉｓｃｅｌｌａｎｅｏｕｓＩｎｆｏｒｍａｔｉｏｎ）を含む、ネットワークスイッチ。
【請求項１２】
請求項１１に記載のネットワークスイッチにおいて、前記チェックサムおよび前記長さデータが、前記リライトエンジンにより、チェックサムを再計算してヘッダの長さを更新する時に使用される、ネットワークスイッチ。
【請求項１３】
受信パケットのためのパーサエンジンおよびリライトエンジンを備えるネットワークスイッチの動作方法であって、各パケットは複数のパケット識別子（ＰｋｔＩＤ）の１つ及び異なるプロトコルに各々関連付けられた１以上のプロトコルレイヤの組合せを含むヘッダを含み、各ＰｋｔＩＤは前記組合せの１つを識別し、前記方法は、
前記パーサエンジンが、受信パケットを調べて当該受信パケットのＰｋｔＩＤを特定する過程と、
前記リライトエンジンが、前記ＰｋｔＩＤによって索引付けられた複数のエントリを含み、各エントリは、エントリが索引付けされるＰｋｔＩＤによって識別される組合せ及び組合せの各プロトコルレイヤのレイヤ情報を記述し、プロトコルテーブルを参照する過程と、
前記リライトエンジンが、前記プロトコルテーブルに記憶されたデータに基づいてパケットを変更する過程と、
を含む、方法。
【請求項１４】
請求項１３に記載の方法において、さらに、
前記パーサエンジンが、パケットをパース処理したデータを前記リライトエンジンに入力する代わりに、前記ＰｋｔＩＤを前記リライトエンジンに入力する過程、
を含む、方法。
【請求項１５】
請求項１３に記載の方法において、さらに、
前記リライトエンジンが、前記ＰｋｔＩＤを前記プロトコルテーブルのキーとして用いて、パケットの各プロトコルレイヤの変更に必要な情報を取り出す過程と、
を含む、方法。
【請求項１６】
請求項１３に記載の方法において、前記リライトエンジンが、パケットを変更する前記過程が、当該パケットのプロトコルレイヤそれぞれを拡張することを含む、方法。
【請求項１７】
請求項１３に記載の方法において、前記パーサエンジンおよび前記リライトエンジンが、自由に変更可能であり、かつプログラマブルに動作する、方法。
【請求項１８】
複数のパケットを受信するためのメモリおよび受信ポートを備えるネットワークスイッチの動作方法であって、各パケットは複数のパケット識別子（ＰｋｔＩＤ）の１つ及び１以上のプロトコルレイヤの組合せを有するヘッダを含み、各ＰｋｔＩＤは組合せの１つを識別し、前記方法は、
前記メモリに、ＰｋｔＩＤによって索引付けられる複数のエントリを含むプロトコルテーブルを記憶する過程であって、各エントリはエントリが索引付けされるＰｋｔＩＤによって識別される組合せ及び組合せの各プロトコルレイヤのレイヤ情報を記述する、過程と、
前記受信ポートで複数のパケットの１つを受信する過程と、
そのパケットの前記ＰｋｔＩＤを特定する過程と、
前記プロトコルテーブル内に存在する、そのパケットのＰｋｔＩＤによって識別される組合せの前記レイヤ情報にアクセスする過程と、
を含む、方法。
【請求項１９】
請求項１８に記載の方法において、前記パケット構造のそれぞれが、プロトコルレイヤ組合せを表し、かつ、当該プロトコルレイヤ組合せにおける各プロトコルレイヤのレイヤ情報を含む、方法。
【請求項２０】
請求項１８に記載の方法において、さらに、
前記情報を用いることにより、パケットのプロトコルヘッダを、そのプロトコルのフォーマットに従って変更する過程、
を含む、方法。
【請求項２１】
請求項２０に記載の方法において、前記フォーマットが、前記メモリ内にソフトウェアで定義される、方法。
【請求項２２】
請求項２０に記載の方法において、さらに、
少なくとも１つの命令を、前記プロトコルヘッダに適用することにより、当該プロトコルヘッダを変更する過程、
を含む、方法。
【請求項２３】
請求項２２に記載の方法において、前記プロトコルヘッダを変更する過程が、前記情報を用いることにより、抽出されるデータの位置であって、当該プロトコルヘッダを変更するのに使用される位置を決定することを含む、方法。
【請求項２４】
請求項１８に記載の方法において、さらに、
新しいプロトコルを表した新しいパケット構造を追加するために前記プロトコルテーブルを更新する過程、
を含む、方法。
【請求項２５】
請求項１８に記載の方法において、さらに、
プロトコル改変に応答して、パケット構造を変更するために前記プロトコルテーブルを更新する過程、
を含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットのヘッダの変更（modification）技術に関する。詳細には、本発明は、パケットの固有の識別子（固有のパケット識別子）を用いて、パケットの構造を特定する方法およびその装置に関する。
【背景技術】
【０００２】
ネットワークパケット（ネットワーク上のパケット）は、伝送制御プロトコル／インターネットプロトコル／イーサネットプロトコル（ＴＣＰ／ＩＰ／Ethernet（イーサネット））等のインターネットが用いるプロトコルを用いてデータを伝達する。典型的なスイッチは、受信したパケットに対し、そのパケットにおける様々なフィールドに変更を施してから、当該パケットをその宛先や別のスイッチに送出する。受信したパケットに変更を施す理由としては、当該パケットの転送先、宛先がサポートするプロトコル、パケットの優先度、受信時のプロトコルヘッダのフォーマット等がある。ネットワークプロトコルの進化にともない、プロトコルヘッダにおける１つ以上のフィールドが、任意のフィールド（オプションフィールド）とされる場合がある。したがって、プロトコルヘッダ内のフィールドのオフセットが常に一定であるとは限らないため、スイッチのハードウェアの複雑化につながる。
【０００３】
また、従来のスイッチは、パケットの変更時に、そのパケット内の各プロトコルレイヤを順次に処理する。しかし、このような処理構成では、レイテンシも含め、ネットワーク関連の様々なパフォーマンス問題が生じる可能性がある。その場合、大量の処理リソースの消費に繋がりかねない。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
各実施形態において、パケットのヘッダを変更する装置は、パケット内のプロトコルレイヤ間にわたる情報を保持するパケット汎用化手法に関する。このパケット汎用化手法は、想定される全てのプロトコルレイヤ組合せ（起こり得る全てのプロトコルレイヤ組合せ）ごとにレイヤ情報を有するプロトコルテーブルを使用する。このプロトコルテーブル内のプロトコルレイヤ組合せは、手入力でソフトウェアを介して設定されてもよい。そのプロトコルテーブル内のプロトコルレイヤ組合せのそれぞれは、ＰｋｔＩＤ（パケットＩＤ、パケット識別子）によって一意的に特定される。ネットワークデバイスのリライトエンジンが、パケットのＰｋｔＩＤを受け取り、この固有の識別子を上記プロトコルテーブルのキーとして用いて、そのパケットの変更時に必要な、当該パケットの各プロトコルレイヤのレイヤ情報にアクセスする。このようなパケット汎用化手法により、ネットワークデバイスのパーサエンジンからパース処理したデータをリライトエンジンに渡さずによくなるので、大量にリソースを消費せずに済む。
【課題を解決するための手段】
【０００５】
一態様では、ネットワークスイッチが提供される。このネットワークスイッチは、パケットの複数のプロトコルレイヤにわたるパケット情報（パケット内の複数のプロトコルレイヤ全てに関する情報を含むパケット情報）を保持するパケット汎用化手段を備える。典型的に、この情報は、前記ネットワークスイッチのメモリに記憶されたプロトコルテーブル内に保持される。
【０００６】
一部の実施形態では、前記プロトコルテーブルが、互いに異なるプロトコルレイヤ組合せごとにレイヤ情報を有する。一部の実施形態では、前記パケット情報が、ソフトウェアで定義される。
【０００７】
前記ネットワークスイッチは、さらに、リライトエンジンであって、パケットの固有の識別子を前記プロトコルテーブルのキーとして用いて、そのパケットの変更時に必要な、当該パケットの各プロトコルレイヤについてのレイヤ情報にアクセスするリライトエンジンを備える。
【０００８】
一部の実施形態では、前記ネットワークスイッチが、さらに、前記リライトエンジンに、前記固有の識別子を供給するパーサエンジンを備える。
【０００９】
他の態様では、ネットワークスイッチが提供される。このネットワークスイッチは、パケットを受信する入力ポートと、複数のパケットの互いに異なるパケット構造を定義するプロトコルテーブルを記憶するメモリとを備える。典型的に、このパケット構造のそれぞれは、プロトコルレイヤ組合せを表し、かつ、当該プロトコルレイヤ組合せにおける各プロトコルレイヤのレイヤ情報を含む。
【００１０】
一部の実施形態では、前記パケット構造のそれぞれが、ＰｋｔＩＤによって索引付けられる。
【００１１】
一部の実施形態では、前記レイヤ情報が、パケット内の１つのレイヤのプロトコルおよびそのパケット内での当該レイヤの開始位置を示すレイヤタイプ（ＬａｙｅｒＴｙｐｅ）を含む。このレイヤタイプ（ＬａｙｅｒＴｙｐｅ）と、パケットの１つ以上のフィールドについてのハッシュとの固有の組合せにより、前記リライトエンジンに、そのパケットにおける当該レイヤの汎用フォーマットが供与され得る。この固有の組合せにより、プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングのうちの１つが指定され得る。これらソフトウェア定義のマッピングは、前記メモリに記憶され得る。
【００１２】
一部の実施形態では、前記レイヤ情報が、さらに、レイヤデータオフセット（ＬａｙｅｒＤａｔａＯｆｆｓｅｔ）を含む。レイヤデータオフセット（ＬａｙｅｒＤａｔａＯｆｆｓｅｔ）は、レイヤデータの開始位置を与える。チェックサムおよび長さデータが、前記リライトエンジンにより、チェックサムを再計算してヘッダの長さを更新する時に使用され得る。
【００１３】
一部の実施形態では、前記レイヤ情報が、さらに、チェックサムおよび長さデータを有する付帯情報（ＭｉｓｃｅｌｌａｎｅｏｕｓＩｎｆｏｒｍａｔｉｏｎ）を含む。
【００１４】
前記ネットワークスイッチは、さらに、前記入力ポートで受信されたパケットのＰｋｔＩＤを特定するパーサエンジンを備える。
【００１５】
前記ネットワークスイッチは、さらに、リライトエンジンであって、前記ＰｋｔＩＤを前記プロトコルテーブルのキーとして用いて、そのパケットを変更するのに必要な、当該パケットの各プロトコルレイヤのレイヤ情報にアクセスするリライトエンジンを備える。
【００１６】
さらなる他の態様では、パーサエンジンおよびリライトエンジンを備えるネットワークスイッチの動作方法が提供される。この方法は、前記パーサエンジンが、受信パケットを調べて当該受信パケットのＰｋｔＩＤを特定する過程を含む。一部の実施形態では、前記パーサエンジンが、そのパケットをパース処理したデータではなく前記ＰｋｔＩＤを前記リライトエンジンに渡す。
【００１７】
前記方法は、さらに、前記リライトエンジンにより、複数のパケットの互いに異なるパケット構造を定義するプロトコルテーブルを参照する過程を含む。一部の実施形態では、前記リライトエンジンにより、前記ＰｋｔＩＤを前記プロトコルテーブルのキーとして用いて、変更に必要な、パケットの各プロトコルレイヤのレイヤ情報を取り出し得る。
【００１８】
前記方法は、さらに、前記リライトエンジンにより、前記プロトコルテーブルに記憶されたデータに基づいてパケットを変更する過程を含む。一部の実施形態では、パケットを変更する前記過程が、当該パケットの各プロトコルレイヤを拡張することを含む。
【００１９】
一部の実施形態では、前記パーサエンジンおよび前記リライトエンジンが、自由に変更可能であり、かつプログラマブル（設定可能）に動作する。
【００２０】
さらなる他の態様では、メモリおよび受信ポートを備えるネットワークスイッチの動作方法が提供される。この方法は、前記メモリに、複数のパケットの互いに異なるパケット構造を定義するプロトコルテーブルを記憶する過程を含む。典型的に、このパケット構造のそれぞれは、ＰｋｔＩＤによって索引付けられる。
【００２１】
一部の実施形態では、前記パケット構造のそれぞれが、プロトコルレイヤ組合せを表し、かつ、当該プロトコルレイヤ組合せにおける各プロトコルレイヤのレイヤ情報を含む。
【００２２】
前記方法は、さらに、前記受信ポートでパケットを受信する過程を含む。
【００２３】
前記方法は、さらに、そのパケットの前記ＰｋｔＩＤを特定する過程を含む。
【００２４】
前記方法は、さらに、そのパケットの各プロトコルレイヤのレイヤ情報にアクセスする過程を含む。典型的に、このレイヤ情報は、前記プロトコルテーブル内に存在する。
【００２５】
一部の実施形態において、前記方法は、さらに、前記レイヤ情報を用いることにより、パケットのプロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する過程を含む。前記汎用フォーマットを、前記メモリ内にソフトウェアで定義し得る。
【００２６】
一部の実施形態において、前記方法は、さらに、少なくとも１つの命令を、汎用化後のプロトコルヘッダに適用することにより、当該汎用化後のプロトコルヘッダを変更する過程を含む。一部の実施形態では、汎用化後のプロトコルヘッダを変更する過程が、前記レイヤ情報を用いることにより、抽出されるデータの位置であって、当該汎用化後のプロトコルヘッダを変更するのに使用される位置を決定することを含む。
【００２７】
一部の実施形態において、前記方法は、さらに、新しいプロトコルを表した新しいパケット構造を追加するように、前記プロトコルテーブルを更新する過程を含む。
【００２８】
一部の実施形態において、前記方法は、さらに、プロトコル改変に応答して、パケット構造を変更するために前記プロトコルテーブルを更新する過程を含む。
【００２９】
前述の内容は、添付の図面に示す本発明の例示的な実施形態についての以下の詳細な説明から明らかになる。図面において同一の符号は、異なる図をとおして同一の構成要素を指す。図面は必ずしも縮尺どおりではなく、本発明の実施形態を示すことに重点を置いている。
【図面の簡単な説明】
【００３０】
【図１】パケット内のプロトコルレイヤ組合せの複数例を示す図である。
【図２】本発明の一部の実施形態での、ローカルなプロトコルテーブルの構造の一例を示す図である。
【図３】本発明の一部の実施形態での、ネットワークスイッチの動作方法の一例を示すフローチャートである。
【図４】本発明の一部の実施形態での、ネットワークスイッチの動作方法の他の例を示すフローチャートである。
【図５】本発明の一部の実施形態において、受信パケットにおける様々なレイヤのヘッダを汎用フォーマットに拡張する様子を示す図である。
【図６Ａ】本発明の一部の実施形態での、プロトコルヘッダの汎用化の一例を示す図である。
【図６Ｂ】本発明の一部の実施形態での、プロトコルヘッダの汎用化の一例を示す他の図である。
【図７Ａ】本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示す図である。
【図７Ｂ】本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示す他の図である。
【図７Ｃ】本発明の一部の実施形態での、プロトコルヘッダの汎用化の他の例を示すさらなる他の図である。
【図８Ａ】本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示す図である。
【図８Ｂ】本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示す他の図である。
【図８Ｃ】本発明の一部の実施形態での、プロトコルヘッダの汎用化のさらなる他の例を示すさらなる他の図である。
【図９Ａ】本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示す図である。
【図９Ｂ】本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示す他の図である。
【図９Ｃ】本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示すさらなる他の図である。
【図９Ｄ】本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示すさらなる他の図である。
【図９Ｅ】本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示すさらなる他の図である。
【図９Ｆ】本発明の一部の実施形態での、プロトコルヘッダの変更の一例を示すさらなる他の図である。
【図１０Ａ】本発明の一部の実施形態での、プロトコルヘッダの変更の他の例を示す図である。
【図１０Ｂ】本発明の一部の実施形態での、プロトコルヘッダの変更の他の例を示す他の図である。
【図１０Ｃ】本発明の一部の実施形態での、プロトコルヘッダの変更の他の例を示すさらなる他の図である。
【図１０Ｄ】本発明の一部の実施形態での、プロトコルヘッダの変更の他の例を示すさらなる他の図である。
【図１０Ｅ】本発明の一部の実施形態での、プロトコルヘッダの変更の他の例を示すさらなる他の図である。
【図１１】本発明の一部の実施形態での、リライトエンジンの動作方法のフローチャートである。
【図１２】本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。
【図１３】本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。
【図１４】本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。
【図１５】本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。
【図１６】本発明の一部の実施形態での、リライトエンジンの他の動作方法のフローチャートである。
【図１７】本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。
【図１８】本発明の一部の実施形態での、リライトエンジンのさらなる他の動作方法のフローチャートである。
【図１９】本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。
【図２０】本発明の一部の実施形態での、レイヤ構造の一例を示す図である。
【図２１】本発明の一部の実施形態での、リライトエンジンのさらなる他の動作方法を示すフローチャートである。
【図２２】本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法を示すフローチャートである。
【発明を実施するための形態】
【００３１】
以降では、説明目的の具体例を幾つか述べる。当業者であれば、それらの具体例以外でも本発明を実施できることを理解するであろう。すなわち、本発明は図示の実施形態に必ずしも限定されず、本明細書で述べる原理及び特徴に沿った最大限の範囲を包含する。
【００３２】
［序論］
ネットワークスイッチ等のネットワークデバイスは、ネットワーク上のトラフィックのスイッチングつまりルーティングを行うことができる。ネットワークスイッチは、パケットを受信する少なくとも１つの入力ポートつまり受信ポート、およびパケットを送信する少なくとも１つの出力ポートつまり送信ポートを備える。一部の実施形態において、ネットワークスイッチは、さらに、パーサ（パース処理手段）およびリライタ（書き換え手段）を備える。パーサ（解析手段）は、ネットワーク上のパケット（ネットワークパケット）のコンテンツを特定する少なくとも１つのパーサエンジンを含み得る。リライタ（再書込手段）は、パケットを、ネットワークスイッチから送出する前に変更する少なくとも１つのリライトエンジンを含み得る。これら少なくとも１つのパーサエンジンおよび少なくとも１つのリライトエンジンは、自由に変更可能であり、プログラマブル（設定可能）に動作し得る。
【００３３】
上記ネットワークスイッチは、さらに、当該ネットワークスイッチが使用するデータを記憶するメモリを備える。一例において、このメモリは、汎用的な命令のセットを記憶する。簡単に述べると、これら汎用的な命令は、プロトコルヘッダを変更するために典型的に使用される。他の例において、そのメモリは、さらに、プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングのセットを記憶する。簡単に述べると、各プロトコルヘッダは、そのソフトウェア定義のマッピングのうち、そのプロトコルに特有であるマッピングに従った表現に変換され得る。後で詳述するように、これらのマッピングは、あるプロトコルの、互いに異なる変種にも、互いに異なるプロトコルにも適用可能であると共に、将来の新しいプロトコルにも適用（対応）可能である。さらなる他の例において、上記メモリは、さらに、プロトコルテーブルを記憶する。簡単に述べると、このプロトコルテーブルは、各プロトコルレイヤ組合せにおける各プロトコルレイヤのレイヤ情報を含む。各プロトコルレイヤ組合せは、そのプロトコルテーブル内にプログラム（書き込まれる）される。さらなる他の例において、上記メモリは、さらに、計数値（counter）および統計量（statistic）を記憶する。
【００３４】
イーサネット（登録商標）では、パケットが複数のプロトコルレイヤを含む。各プロトコルレイヤは、互いに異なる情報を伝達する。そのようなレイヤとして、例えば：イーサネット；ＰＢＢイーサネット；ＡＲＰ；ＩＰｖ４；ＩＰｖ６；ＭＰＬＳ；ＦＣｏＥ；ＴＣＰ；ＵＤＰ；ＩＣＭＰ；ＩＧＭＰ；ＧＲＥ；ＩＣＭＰｖ６；ＶｘＬＡＮ；ＴＲＩＬＬ；ＣＮＭ；等が周知である。
【００３５】
理論的に言えば、プロトコルレイヤは任意の順番であってもよい。しかし実際には周知のレイヤ組合せとなる。有効なレイヤ組合せとして、例えば：イーサネット；イーサネット，ＡＲＰ；イーサネット，ＣＮＭ；イーサネット，ＦＣｏＥ；イーサネット，ＩＰｖ４；イーサネット，ＩＰｖ４，ＩＣＭＰ；イーサネット，ＩＰｖ４，ＩＧＭＰ；等がある。
【００３６】
［パケットの固有の識別子（固有のパケット識別子）］
一部の実施形態において、上記ネットワークスイッチは、１７種類のプロトコルおよび８層のプロトコルレイヤをサポートする。すなわち、８１７通りのプロトコルレイヤ組合せが想定され得る。図１に、パケット内のプロトコルレイヤ組合せの複数例を示す。一例として、パケットは、イーサネット，ＩＰｖ４，ＩＣＭＰのような３層プロトコルレイヤ組合せを有し得る。他の例として、パケットは、イーサネット，ＩＰｖ４，ＵＤＰ，ＶｘＬＡＮ，イーサネット，ＡＲＰのような７層プロトコルレイヤ組合せを有し得る。
【００３７】
８１７通りのプロトコルレイヤ組合せが想定されるものの、周知のレイヤ組合せはごく一部である。既知の全てのプロトコルレイヤ組合せが、一意的に特定され、パケット識別子（ＰｋｔＩＤ）と称される固有の番号に翻訳（変換）され得る。上記ネットワークスイッチのメモリに記憶されたプロトコルテーブルは、既知の各プロトコルレイヤ組合せにおける各レイヤのレイヤ情報を含むようにプログラムされ得る。実際的には、ローカルなプロトコルテーブルに含まれるプロトコルレイヤ組合せの数は、２５６未満になり得る。一部の実施形態において、このローカルなプロトコルテーブルに含まれる既知のプロトコルレイヤ組合せの数は、２１２である。しかしながら、このローカルなテーブルは、これを上回る数の又はこれを下回る数のプロトコルレイヤ組合せを含むようにプログラムされてもよい。
【００３８】
図２に、本発明の一部の実施形態での、ローカルなプロトコルテーブル２００の構造の一例を示す。ローカルなテーブル２００内のプロトコルレイヤ組合せのそれぞれは、ＰｋｔＩＤによって索引付けられ、そのプロトコルレイヤ組合せにおける各プロトコルレイヤのレイヤ情報を含み得る。図２では、これらの情報は、レイヤ０情報、レイヤ１情報およびレイヤＮ情報と称されている。このようにＰｋｔＩＤで索引付けすることにより、パケット内のＮ個の全てのレイヤの、どのレイヤについてのレイヤ情報にもアクセス又は取り出すことが可能である。
【００３９】
各プロトコルレイヤのレイヤ情報は、少なくとも：レイヤタイプ（ＬａｙｅｒＴｙｐｅ）；レイヤデータオフセット（ＬａｙｅｒＤａｔａＯｆｆｓｅｔ）；および付帯情報（ＭｉｓｃｅｌｌａｎｅｏｕｓＩｎｆｏｒｍａｔｉｏｎ）；を含む。しかしながら、ローカルなテーブル２００には、より多くの種類の情報が記憶されてもよい。簡単に述べると、レイヤタイプ（ＬａｙｅｒＴｙｐｅ）は、そのプロトコルレイヤのプロトコル（例えば、ＩＰ、ＴＣＰ、ＵＤＰまたはイーサネット）を指す。レイヤデータオフセット（ＬａｙｅｒＤａｔａＯｆｆｓｅｔ）は、そのプロトコルレイヤ内においてレイヤデータが開始する位置（開始位置）を供与する。付帯情報（ＭｉｓｃｅｌｌａｎｅｏｕｓＩｎｆｏｒｍａｔｉｏｎ）は、チェックサム、長さデータ等のデータを含む。
【００４０】
典型的に、上記パーサエンジンは、ネットワークスイッチが受信した受信パケットのＰｋｔＩＤを特定することができる。上記リライトエンジンが、そのＰｋｔＩＤを上記プロトコルテーブルのキーとして用いることにより、そのパケットにおける各プロトコルレイヤを変更用に汎用化するのに必要な全ての情報を、このプロトコルテーブルが当該リライトエンジンに供給し得る。すなわち、上記リライトエンジンは、上記パーサエンジンがパース処理した結果を受け取るのではなく、ＰｋｔＩＤを用いることにより、上記プロトコルテーブル内に存在する、そのパケットの各プロトコルレイヤのレイヤ情報にアクセスし得るか又はそのような情報を上記プロトコルテーブルから取り出し得る。
【００４１】
＜レイヤタイプ＞
レイヤタイプ（ＬａｙｅｒＴｙｐｅ）と、パケットの１つ以上のフィールドについてのハッシュとの固有の組合せにより、上記リライトエンジンに、各プロトコルレイヤの汎用フォーマットが供与され得る。一部の実施形態において、この固有の組合せにより、上記メモリに記憶された、プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングのうちの１つが指定され得る。上記リライトエンジンは、この汎用フォーマットを使用して、プロトコルレイヤの拡張、さらには、ソフトウェア命令を用いてのプロトコルレイヤの変更を行い得る。このレイヤタイプ（ＬａｙｅｒＴｙｐｅ）が、さらに、パケット内においてそのプロトコルレイヤが開始する位置（開始位置）を、上記リライトエンジンに教示し得る。
【００４２】
＜レイヤデータオフセット＞
上記リライトエンジンは、パケット内の所与のデータを用いて、受信ヘッダにおけるレイヤを変更するが、そのパケット内における当該データの位置はどこであってもよい。レイヤのサイズは様々に変化し得るため、上記リライトエンジンによる変更時に必要な、データのオフセット自体も、様々に変化し得る。このことは、リライトエンジンがどのデータをどこから選択できるのかに関してのハードウェア面での柔軟性を低下させる原因となり得る。
【００４３】
受信パケットのヘッダから抽出されるデータは、レイヤ単位で配置される。具体的に述べると、抽出されるデータ構造内において各レイヤデータ構造が開始するオフセット（開始位置）は、ＰｋｔＩＤ毎に固有である。各レイヤのレイヤデータオフセット（ＬａｙｅｒＤａｔａＯｆｆｓｅｔ）は、抽出されるデータについて、その変更時に用いる位置を特定するのに使用され得る。パケット内のレイヤ構造も、レイヤから抽出するデータの位置も、そのパケットのＰｋｔＩＤで特定され得る。このように、ソフトウェアもハードウェアも、抽出されるデータを同じ固有の識別子を用いて管理するので、リライトエンジンの命令を簡略化することが可能になる。
【００４４】
＜付帯情報＞
チェックサム、長さデータ等の付帯情報（ＭｉｓｃｅｌｌａｎｅｏｕｓＩｎｆｏｒｍａｔｉｏｎ）は、チェックサムの再計算およびヘッダの長さの更新などといった、そのプロトコルレイヤの特殊な取扱い要件を、上記リライトエンジンに教示し得る。
【００４５】
パケット汎用化手法は、少数のセットの汎用的な命令を定義することを可能にする。この汎用的な命令のセットは、所与のプロトコルに単に基づくものであり、そのプロトコルレイヤの前後のプロトコルレイヤの影響を受けない。このパケット汎用化手法は、さらに、将来起こり得るプロトコルの改変や追加の影響を受け難い、ハードウェア面での柔軟性をもたらすことができる。
【００４６】
図３に、本発明の一部の実施形態での、ネットワークスイッチの動作方法の一例３００を示す。典型的に、このネットワークスイッチは、前記パーサエンジンおよび前記リライトエンジンを備える。
【００４７】
過程３０５で、前記パーサエンジンが、受信パケットを調べて当該受信パケットのＰｋｔＩＤを特定する。一部の実施形態では、前記パーサエンジンが、そのパケットをパース処理したデータではなく前記ＰｋｔＩＤを前記リライトエンジンに入力する。
【００４８】
過程３１０で、前記リライトエンジンが、前記ネットワークスイッチが受け取る複数のパケットの互いに異なるパケット構造を定義するプロトコルテーブルを参照する。前記リライトエンジンが、前記ＰｋｔＩＤを前記プロトコルテーブルのキーとして用いて、変更に必要な、パケットの各プロトコルレイヤのレイヤ情報を取り出し得る。
【００４９】
過程３１５で、前記リライトエンジンが、前記プロトコルテーブルに記憶されたデータに基づいてパケットを変更する。典型的には、パケットを変更するのに先立って、前記リライトエンジンが、そのパケットの各プロトコルレイヤを拡張する。プロトコルレイヤの拡張および変更の詳細については、後で説明する。
【００５０】
図４に、本発明の一部の実施形態での、ネットワークスイッチの動作方法の他の例４００を示す。典型的に、このネットワークスイッチは、メモリおよび少なくとも１つの受信ポートを備える。
【００５１】
過程４０５で、前記メモリに、プロトコルテーブルを記憶する。このプロトコルテーブルは、複数のパケットの互いに異なるパケット構造を定義する。これらパケット構造のそれぞれは、ＰｋｔＩＤによって索引付けられる。また、これらパケット構造は、プロトコルレイヤ組合せを表し、かつ、そのプロトコルレイヤ組合せにおける各プロトコルレイヤのレイヤ情報を含む。前記プロトコルテーブルは、新しいプロトコルを表した新しいパケット構造を追加するために更新され得る。また、前記プロトコルテーブルは、プロトコルの改変に応答して、パケット構造を変更するために更新され得る。
【００５２】
過程４１０で、前記受信ポートにおいてパケットを受信する。
【００５３】
過程４１５で、そのパケットのＰｋｔＩＤを特定する。一部の実施形態では、前記パーサエンジンが、そのパケットのＰｋｔＩＤを特定する。
【００５４】
過程４２０で、そのパケットの各プロトコルレイヤのレイヤ情報にアクセスする。典型的に、このレイヤ情報は、前記プロトコルテーブル内に存在する。一部の実施形態では、このレイヤ情報を用いることにより、そのパケットのプロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する。この汎用フォーマットは、前記メモリ内にソフトウェアで定義され得る。
【００５５】
既述したように、少なくとも１つの命令を汎用化後のプロトコルヘッダに適用することにより、その汎用化後のプロトコルヘッダを変更することができる。一部の実施形態では、その汎用化後のプロトコルヘッダを変更するのに使用する、データの位置を、前記レイヤ情報を用いて決定する。典型的には、前記ネットワークスイッチの前記リライトエンジンにより、プロトコルヘッダの汎用化、さらには、汎用化後のプロトコルヘッダの変更を行う。
【００５６】
［汎用フォーマット］
略述したように、前記リライトエンジンが、パケットの各プロトコルヘッダを、そのプロトコルに特有である汎用フォーマットで表現することにより、パケットにプログラマブルな変更を可能にする。これにより、パケットのヘッダを変更する際のハードウェア面およびソフトウェア面での柔軟性が向上する。
【００５７】
図５は、本発明の一部の実施形態において、受信パケットにおける様々なレイヤのヘッダを汎用フォーマットに拡張する様子を示す概略構成５００である。図５の受信パケットは、８層のプロトコルレイヤを含む。そして、各プロトコルレイヤは、そのプロトコルに対応したヘッダ（プロトコルヘッダ）を有する。なお、プロトコルレイヤの層数は、８層を超える場合も８層未満の場合もあり得る。リライトエンジンは、どのプロトコルヘッダからも、欠けているフィールドを検出することができると共に、各プロトコルヘッダを図５に示すような汎用フォーマットに拡張することができる。「正準レイヤ」つまり「正準化されたレイヤ」とは、汎用フォーマットに拡張されたプロトコルレイヤのことを指す。手短に言って、正準レイヤのそれぞれは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされたビットベクトルを備える。
【００５８】
図６Ａ〜図８Ｃに、本発明の一部の実施形態において、リライトエンジンがイーサネットプロトコルを扱う各種例を示す。図６Ａ〜図８Ｃに示された各種例は、本発明にかかるリライトエンジンにより、あるプロトコル（これらの例では、イーサネットプロトコル）の、互いに異なる変種を扱うことができることを証明している。各例には、イーサネットプロトコルの受信時のヘッダと、その汎用フォーマットとが描かれている。他種のプロトコルの場合の説明は省略するが、本発明にかかるリライトエンジンは、他種のプロトコル合も同様に扱うことができる。
【００５９】
図６Ａに、受信パケット内のイーサネットパケットヘッダのフォーマットの一例６００を示す。このイーサネットパケットヘッダ６００は、２２バイトであり、送信元アドレス（ＳＡ）フィールド、宛先アドレス（ＤＡ）フィールド、サービスＶＬＡＮタグフィールド、カスタマＶＬＡＮタグフィールドおよびイーサタイプフィールドの、５つのフィールドを有する。ＳＡフィールドおよびＤＡフィールドは、いずれも６バイトである。サービスＶＬＡＮタグフィールドおよびカスタマＶＬＡＮタグフィールドは、いずれも４バイトである。イーサタイプフィールドは、２バイトである。このイーサネットパケットヘッダ６００を含むパケットは、イーサネットパケットの変種のなかでも最も大きい変種であり、そのサイズは最大２２バイトであり得る。
【００６０】
リライトエンジンは、イーサネットパケットヘッダ６００を処理して、当該イーサネットパケットヘッダ６００には欠けているフィールドがないと判断する。このように、イーサネットパケットヘッダ６００は想定されるフィールド全てを備えていることから、このイーサネットパケットヘッダ６００の汎用フォーマットは、イーサネットパケットヘッダ６００と全く同一になる。図６Ｂに、図６Ａのイーサネットパケットヘッダ６００を表したビットベクトル６０５を示す。ビットベクトル６０５の各ビットは、イーサネットパケットヘッダ６００の２２バイトのうちの１バイトにそれぞれ対応する。イーサネットパケットヘッダ６００には、フィールド全てが存在していることから、当該イーサネットパケットヘッダ６００のフィールド全てが有効フィールドとなる（すなわち、数値を有する）。したがって、ビットベクトル６０５のビットは全て「１」である。つまり、イーサネットパケットヘッダ６００は、｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿１１１１＿１１｝という汎用フォーマットで表現することができる。
【００６１】
図７Ａに、受信パケットのイーサネットパケットヘッダのフォーマットの他の例７００を示す。このイーサネットパケットヘッダ７００は、１８バイトであり、ＳＡフィールド、ＤＡフィールド、カスタマＶＬＡＮタグフィールドおよびイーサタイプフィールドの、４つのフィールドしか有していない。すなわち、イーサネットパケットヘッダ７００には、サービスＶＬＡＮタグフィールドが欠けている。このイーサネットパケットヘッダ７００を含むパケットも、イーサネットパケットの変種である。
【００６２】
リライトエンジンは、イーサネットパケットヘッダ７００を処理して、当該イーサネットパケットヘッダ７００にはサービスＶＬＡＮタグフィールドが欠けていると判断し、当該イーサネットパケットヘッダ７００の汎用フォーマットにおける適切な位置に、欠けているサービスＶＬＡＮタグフィールドを含めることにより、そのイーサネットパケットヘッダ７００を最大サイズである２２バイトに拡張する。図７Ｂに、拡張後のイーサネットパケットヘッダの汎用フォーマット７００’を示す。拡張後のイーサネットパケットヘッダ７００’は、欠けていたサービスＶＬＡＮタグフィールドも含め、イーサネットプロトコルについて想定されるフィールド全てを備えている。拡張後のイーサネットパケットヘッダ７００’内の有効フィールドは、拡張前のイーサネットパケットヘッダ７００から存在していたＳＡフィールド、ＤＡフィールド、カスタマＶＬＡＮタグフィールドおよびイーサタイプフィールドである。拡張後のイーサネットパケットヘッダ７００’内の無効フィールドは、拡張前のイーサネットパケットヘッダ７００内には存在せずに拡張後のイーサネットパケットヘッダ７００’で追加された、サービスＶＬＡＮタグフィールドである。
【００６３】
図７Ｃに、図７Ｂの拡張後のイーサネットパケットヘッダ７００’を表したビットベクトル７０５を示す。ビットベクトル７０５の各ビットは、拡張後のイーサネットパケットヘッダ７００’の２２バイトのうちの１バイトにそれぞれ対応する。ビットベクトル７０５は、ＳＡフィールド、ＤＡフィールド、カスタマＶＬＡＮタグフィールドおよびイーサタイプフィールドからなる有効フィールド全てについて「１」である。また、ビットベクトル７０５は、サービスＶＬＡＮタグフィールドのみからなる無効フィールド全てについて「０」である。つまり、イーサネットパケットヘッダ７００は、｛２２’ｂ１１１１１１＿１１１１１１＿００００＿１１１１＿１１｝という汎用フォーマットで表現することができる。
【００６４】
図８Ａに、受信パケットのイーサネットパケットヘッダのフォーマットのさらなる他の例８００を示す。このイーサネットパケットヘッダ８００は、１４バイトであり、ＳＡフィールド、ＤＡフィールドおよびイーサタイプフィールドの、３つのフィールドしか有していない。すなわち、イーサネットパケットヘッダ８００には、サービスＶＬＡＮタグフィールドとカスタマＶＬＡＮタグフィールドとが欠けている。このイーサネットパケットヘッダ８００を含むパケットは、イーサネットパケットの変種のなかでも最も小さい変種である。
【００６５】
リライトエンジンは、イーサネットパケットヘッダ８００を処理して、当該イーサネットパケットヘッダ８００にはサービスＶＬＡＮタグフィールドとカスタマＶＬＡＮタグフィールドとが欠けていると判断し、当該イーサネットパケットヘッダ８００の汎用フォーマットにおける適切な位置に、欠けているサービスＶＬＡＮタグフィールドとカスタマＶＬＡＮタグフィールドとを含めることにより、そのイーサネットパケットヘッダ８００を最大サイズである２２バイトに拡張する。図８Ｂに、拡張後のイーサネットパケットヘッダの汎用フォーマット８００’を示す。拡張後のイーサネットパケットヘッダ８００’は、欠けていたサービスＶＬＡＮタグフィールドおよびカスタマＶＬＡＮタグフィールドも含め、イーサネットプロトコルについて想定される全てのフィールドを備えている。拡張後のイーサネットパケットヘッダ８００’内の有効フィールドは、拡張前のイーサネットパケットヘッダ８００から存在していたＳＡフィールド、ＤＡフィールドおよびイーサタイプフィールドである。拡張後のイーサネットパケットヘッダ８００’内の無効フィールドは、拡張前のイーサネットパケットヘッダ８００内に存在せずに拡張後のイーサネットパケットヘッダ８００’で追加された、サービスＶＬＡＮタグフィールドおよびカスタマＶＬＡＮタグフィールドである。
【００６６】
図８Ｃに、図８Ｂの拡張後のイーサネットパケットヘッダ８００’を表したビットベクトル８０５を示す。ビットベクトル８０５の各ビットは、拡張後のイーサネットパケットヘッダ８００’の２２バイトのうちの１バイトにそれぞれ対応する。ビットベクトル８０５は、ＳＡフィールド、ＤＡフィールドおよびイーサタイプフィールドからなる有効フィールド全てについて「１」である。また、ビットベクトル８０５は、サービスＶＬＡＮタグフィールドおよびカスタマＶＬＡＮタグフィールドからなる無効フィールド全てについて「０」である。つまり、イーサネットパケットヘッダ８００は、｛２２’ｂ１１１１１１＿１１１１１１＿００００＿００００＿１１｝という汎用フォーマットで表現することができる。
【００６７】
図６Ａ〜図８Ｃから分かるように、イーサネットヘッダを汎用フォーマットに拡張することにより、フィールドのオフセットは、受信時のイーサネットヘッダの変種にかかわらず、最大サイズを有するイーサネットヘッダ（これらの例では、図６Ａのイーサネットパケットヘッダ６００）のオフセットと同一になる。このようにイーサネットヘッダを、最大サイズを有するイーサネットヘッダに拡張することにより、受信時のイーサネットヘッダにかかわらず、同一のセットのソフトウェア命令での処理が可能になるので有利である。よって、例えばイーサタイプフィールドを変更する命令は、どのようなイーサネットヘッダを受信したのかにかかわらず常に同一のオフセットを指すことができる。
【００６８】
パケットヘッダの汎用フォーマットを用いることにより、そのパケットヘッダを変更する際のハードウェア面およびソフトウェア面での柔軟性が向上する。ハードウェアは、そのパケットヘッダの変更を、当該パケットヘッダ内におけるフィールドの位置に関係なく実施することができる。ソフトウェアにより、新しいプロトコルを支援するようにハードウェアをプログラムすることができる。また、ソフトウェアにより、ハードウェアのテーブル内に、ヘッダの各種プロトコルに用いる汎用フォーマットをプログラムすることができる。
【００６９】
［仮定１］（受信パケットは単一タグ付きイーサネットパケットであり、送信パケットはタグなしイーサネットパケットであると仮定）
ネットワークスイッチの入力イーサネットポートで受信した、カスタマＶＬＡＮタグ付きのパケットを、タグがない状態で、出力イーサネットポートに送信する場合を考える。図９Ａに、その受信イーサネットポートで受信するパケット内の、イーサネットパケットヘッダのフォーマットの一例９００を示す。その受信イーサネットポートで受信するパケットに対して、ソフトウェアにより、イーサネットヘッダの汎用フォーマットが、｛２２’ｂ１１１１１１＿１１１１１１＿００００＿１１１１＿１１｝であるとプログラムされる。リライトエンジンは、そのヘッダ内のプロトコルレイヤを受け取って前記メモリを参照し、このメモリは、当該ヘッダのプロトコルの汎用フォーマットが｛２２’ｂ１１１１１１＿１１１１１１＿００００＿１１１１＿１１｝であることをハードウェアに認識させる。この場合、ハードウェアでは、先頭から連続する１２個の（いずれも「１」にマークされた）バイトと、４バイト分シフトして後に続く６個の（いずれも「１」にマークされた）バイトとの内容について待ち受ける。前記４バイト分は、ビットベクトルにおいて「０」にマークされた４個のビットに対応する、無効なバイトである。
【００７０】
リライトエンジンは、上記の｛２２’ｂ１１１１１１＿１１１１１１＿００００＿１１１１＿１１｝という汎用フォーマットに基づき、受信されたヘッダにおける前記プロトコルレイヤを、図９Ｂに示す拡張後のヘッダ９０５に拡張し、拡張後のレイヤ９０５の各バイトに対して１ビットを管理する。図９Ｃに、この拡張後のヘッダ９０５に対応するビットベクトル９１０を示す。ビットベクトル９１０は、どのバイトが有効でどのバイトが無効であるかを、前記ハードウェアに認識させる。
【００７１】
本仮定１の送信方針（中継決定）によると、パケットは、タグがない状態で送信することが求められる。前記ハードウェアは、前記送信イーサネットポートの出口側ポートタイプ（egress portType）に基づいて命令テーブルを参照し、当該命令テーブルが、そのハードウェアに、カスタマＶＬＡＮタグをデリート（消去）するように認識させる。カスタマＶＬＡＮタグは、常に決まったオフセット（すなわち、１６）で開始する。命令は汎用フォーマットに適用されるため、カスタマＶＬＡＮタグをデリートする命令は、「位置１６から開始する（カスタマＶＬＡＮタグの）４バイト分をデリートする」という命令になる。前記ハードウェアは、単にその４バイト分を無効であるとマークして、これらをデリートする。図９Ｄに、汎用フォーマットで、タグがない状態のイーサネットヘッダ９１５を示す。図９Ｅに、このタグがない状態のイーサネットヘッダ９１５に対するビットベクトル９２０を示す。前記ハードウェアは、無効なバイトを全て除外することにより、図９Ｆに示すような新しいヘッダ９２５を形成する。そして、パケットが、その新しいヘッダ９２５付きで、前記送信イーサネットポートから送出される。
【００７２】
［仮定２］（受信パケットは二重タグ付きイーサネットパケットであり、送信パケットはタグなしイーサネットパケットであると仮定）
ネットワークスイッチの入力イーサネットポートで受信した、サービスＶＬＡＮタグおよびカスタマＶＬＡＮタグ付きのパケットを、タグがない状態で、出力イーサネットポートに送信する場合を考える。図１０Ａに、その受信イーサネットポートで受信するパケット内の、イーサネットパケットヘッダのフォーマットの一例１０００を示す。その受信イーサネットポートで受信するパケットに対して、ソフトウェアにより、イーサネットヘッダの汎用フォーマットが、｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿１１１１＿１１｝であるとプログラムされる。リライトエンジンは、そのヘッダ内のプロトコルレイヤを受け取って前記メモリを参照し、このメモリは、当該ヘッダのプロトコルの汎用フォーマットが｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿１１１１＿１１｝であることをハードウェアに認識させる。この場合、ハードウェアは、連続する２２個の（いずれも「１」にマークされた）バイトの内容について待ち受ける。
【００７３】
リライトエンジンは、上記の｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿１１１１＿１１｝という汎用フォーマットからみて、このプロトコルヘッダが既に最大サイズを有していることから、受信されたヘッダにおける前記プロトコルレイヤを拡張する必要がない。図１０Ｂに、このヘッダ１０００に対応するビットベクトル１００５を示す。ビットベクトル１００５は、どのバイトが有効でどのバイトが無効であるかを、前記ハードウェアに認識させる。
【００７４】
本仮定２の送信方針によると、パケットは、タグがない状態で送信することが求められる。前記ハードウェアは、前記送信イーサネットポートの出口側ポートタイプに基づいて命令テーブルを参照し、当該命令テーブルが、そのハードウェアに、カスタマＶＬＡＮタグおよびサービスＶＬＡＮタグをデリートするように認識させる。カスタマＶＬＡＮタグは、常に決まったオフセット（具体的には、１６）で開始する。同様に、サービスＶＬＡＮタグは、常に決まったオフセット（具体的には、１２）で開始する。命令は汎用フォーマットに適用されるため、カスタマＶＬＡＮタグおよびサービスＶＬＡＮタグをデリートする命令は、それぞれ、「位置１６から開始する（カスタマＶＬＡＮタグの）４バイト分をデリートする」という命令と、「位置１２から開始する（サービスＶＬＡＮタグの）４バイト分をデリートする」という命令になる。前記ハードウェアは、単にこれら８バイト分を無効であるとマークして、これらをデリートする。図１０Ｃに、汎用フォーマットで、タグがない状態のイーサネットヘッダ１０１０を示す。図１０Ｄに、このタグがない状態のイーサネットヘッダ１０１０に対するビットベクトル１０１５を示す。前記ハードウェアは、無効なバイトを全て除外することにより、図１０Ｅに示すような新しいヘッダ１０２０を形成する。そして、、パケットが、その新しいヘッダ１０２０付きで、前記送信イーサネットポートから送出される。
【００７５】
［仮定３］（受信パケットはタグなしイーサネットパケット、単一タグ付きイーサネットパケットまたは二重タグ付きイーサネットパケットであり、送信パケットは二重タグ付きイーサネットパケットであると仮定）
ネットワークスイッチの入力イーサネットポートで受信した、タグが付いていないパケット、またはサービスＶＬＡＮタグ、カスタマＶＬＡＮタグもしくは両方のタグが付いたパケットを、（別の）二重タグ付きの状態で、出力イーサネットポートに送信する場合を考える。前記受信パケットが二重タグ付きのパケットである場合、ソフトウェアにより、イーサネットヘッダの汎用フォーマットが、、｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿１１１１＿１１｝であるとプログラムされる。前記受信パケットがタグの付いていないパケットである場合、ソフトウェアにより、イーサネットヘッダの汎用フォーマットが、｛２２’ｂ１１１１１１＿１１１１１１＿００００＿００００＿１１｝であるとプログラムされる。前記受信パケットが単一タグ付きのパケットである場合、ソフトウェアにより、イーサネットヘッダの汎用フォーマットが、｛２２’ｂ１１１１１１＿１１１１１１＿００００＿１１１１＿１１｝又は｛２２’ｂ１１１１１１＿１１１１１１＿１１１１＿００００＿１１｝であるとプログラムされる。
【００７６】
本仮定３の送信方針によると、パケットは、二重タグ付きで送信することが求められる。前記ハードウェアは、前記送信イーサネットポートの出口側ポートタイプに基づいて命令テーブルを参照し、当該命令テーブルは、そのハードウェアに、カスタマＶＬＡＮタグおよびサービスＶＬＡＮタグをそれぞれ別のものに置き換えるように認識させる。カスタマＶＬＡＮタグは、常に決まったオフセット（具体的には、１６）で開始する。同様に、サービスＶＬＡＮタグは、常に決まったオフセット（具体的には、１２）で開始する。どちらのタグについても、同様の命令が使用される。汎用フォーマットに適用される命令を用いることから、それぞれの命令は「レイヤデータ位置Ｘ（ｌａｙｅｒＤａｔａ．ｌｏｃａｔｉｏｎＸ）から（サービスＶＬＡＮタグの）４バイト分を開始位置（ｓｔａｒｔＬｏｃａｔｉｏｎ）＝１２にコピーする」という命令と「レイヤデータ位置Ｙ（ｌａｙｅｒＤａｔａ．ｌｏｃａｔｉｏｎＹ）から（サービスＶＬＡＮタグの）４バイト分を開始位置（ｓｔａｒｔＬｏｃａｔｉｏｎ）＝１６にコピーする」という命令になる。このとき、レイヤデータ位置Ｘ（ｌａｙｅｒＤａｔａ．ｌｏｃａｔｉｏｎＸ）およびレイヤデータ位置Ｙ（ｌａｙｅｒＤａｔａ．ｌｏｃａｔｉｏｎＹ）によって指定される位置から、それぞれのコンテンツがコピーされる。
【００７７】
以上の仮定１〜３によって示されたとおり、ハードウェア内のリライトエンジンを簡略化することができると共に、メモリ内に設定されるソフトウェア命令を小規模に抑えることができる。これにより、命令を保持するために必要なハードウェアメモリを浅く（小容量）にすることができる。
【００７８】
図１１に、本発明の一部の実施形態での、リライトエンジンの動作方法１１００を示す。過程１１０５で、リライトエンジンにより、受信パケットのプロトコルヘッダから、欠けているフィールドを検出する。
【００７９】
過程１１１０で、リライトエンジンにより、前記プロトコルヘッダを、前記検出の結果に基づいて、そのプロトコルの汎用フォーマットに拡張する。前記汎用フォーマットは、前記プロトコルについて想定されるフィールドを全て備えている。それら各フィールドのオフセットは、前記プロトコルヘッダのプロトコルの変種にかかわらず同一である。リライトエンジンは、拡張後のプロトコルヘッダに対するビットベクトルを保持し、当該ビットベクトルは、その拡張後のプロトコルヘッダの各バイトに対して１ビットを有する。リライトエンジンにより、有効フィールドにおける全てのバイトに対する各ビットを、有効であるとマークする。有効フィールドは、前記受信パケットの前記プロトコルヘッダ内に存在するフィールドである。リライトエンジンにより、無効フィールドにおける全てのバイトに対する各ビットを、無効であるとマークする。無効フィールドは、前記受信パケットの前記プロトコルヘッダ内に存在しないフィールドである。
【００８０】
一部の実施形態では、過程１１０５および過程１１１０を、前記受信パケットの各プロトコルレイヤに対して実行する。
【００８１】
図１２に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１２００を示す。一部の実施形態において、このネットワークスイッチは、プロトコルの汎用フォーマットについての、ソフトウェア定義のマッピングを可能にし、そのソフトウェア定義のマッピングを、当該ネットワークスイッチのメモリに記憶する。このネットワークスイッチは、プロトコルヘッダを汎用化するリライトエンジンを備える。過程１２０５で、そのネットワークスイッチの受信ポートでパケットを受信する。
【００８２】
過程１２１０で、パケットのプロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する。具体的に説明すると、既述したように、そのプロトコルヘッダが、前記ネットワークスイッチの前記メモリに記憶された前記マッピングのうちの１つに従ってハードウェアにより拡張される。拡張後のプロトコルヘッダに対するビットベクトルが、どのバイトが有効でどのバイトが無効であるかを、そのハードウェアに認識させる。
【００８３】
過程１２１５で、少なくとも１つの命令を、汎用化後のプロトコルヘッダに適用することにより、当該汎用化後のプロトコルヘッダを変更する。具体的に説明すると、既述したように、ハードウェアが、送信イーサネットポートの出口側ポートタイプに基づいて命令テーブルを参照することにより、そのプロトコルヘッダに適用すべき前記少なくとも１つの命令を決定する。
【００８４】
過程１２２０で、変更後のプロトコルヘッダにおける無効なバイトを全て除外することにより、新しいヘッダを形成する。
【００８５】
過程１２２５で、前記パケットを、前記新しいヘッダ付きで、前記ネットワークスイッチの送信ポートから送出する。
【００８６】
図１３に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１３００を示す。過程１３０５で、プロトコルの汎用フォーマットについてのソフトウェア定義のマッピングを有するように、このネットワークスイッチを構成する。具体的に述べると、前記ソフトウェア定義のマッピングを、そのネットワークスイッチのメモリに記憶する。
【００８７】
過程１３１０で、前記ネットワークスイッチの受信ポートでパケットを受信する。
【００８８】
過程１３１５で、前記パケットのプロトコルヘッダを、前記ソフトウェア定義のマッピングのうちの１つに基づいて汎用化する。
【００８９】
過程１３２０で、汎用化後のプロトコルヘッダに対するビットベクトルを保持する。このビットベクトルは、その汎用化後のプロトコルヘッダの各バイトに対して１ビットを有する。
【００９０】
［汎用化後のプロトコルヘッダの最適な表現様式］
受信時の各レイヤに含まれるバイト数は、例えば６４バイトであったり、１２８バイトであったり、あるいは、それ以上にもなり得る。なお、これまでの例における拡張後のイーサネットヘッダのバイト数は、２２バイトであった。プロトコルレイヤ内の全てのバイトをビットベクトルで表そうとすると、プロトコルによっては最悪の場合、メモリを大量に消費することになり、効率が良いとは言えないことがある。現代のシステムオンチップ（ＳＯＣ）設計では、通常、組み込まれるメモリの面積および電力予算がチップ全体の予算を大きく占める。そのため、限られたメモリリソースを効率的に利用することが重要となる。
【００９１】
「ホール」すなわち無効なバイトが少ないプロトコルが大半を占める場合、ヘッダの汎用フォーマットを、連続するバイトの計数値と、それ以降の連続しないバイトを表した小規模のビットベクトルと、で表現するほうが低コストになる。一部の実施形態において、この小規模のビットベクトルのサイズは、プログラマブルであるが、典型的には一定とされる。このサイズは、１つのプロトコルのこのような表現において記憶する必要がある非連続バイトの個数の最大値を、複数のプロトコルの統計から求めて調節可能であり得る。
【００９２】
一部の実施形態において、パケットの汎用フォーマットは、連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ）フィールドとビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドとの２つのフィールドを有するデータ構造を用いた表現により、最適に表現することができる。連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ）フィールドは、そのプロトコルレイヤ内において先頭から連続する有効なバイトの個数を表す。ビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドは、そのプロトコルレイヤの各バイトをビットで表したものである。詳細には、このビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドは、「ホール」すなわち無効なバイトを示す。ビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドは、全てのプロトコルとは言わないが、ほぼ全てのプロトコルに対処することができる。このように、最適な表現とは、｛連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ），ビットベクトル（ｂｉｔｖｅｃｔｏｒ）｝による表現である。このデータ構造は、プロトコルヘッダのサイズにに影響されない。
【００９３】
一例として、図６Ｂのビットベクトル６０５は｛２２，００００＿００００＿００００＿００００｝とコンパクトに表現することができる。これは、図６Ａのイーサネットパケットヘッダ６００の先頭から連続するバイト数が２２であることを表している。そのビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドは、無効なバイトがないので全て「０」である。
【００９４】
他の例として、図７Ｃのビットベクトル７０５は｛１２，００００＿１１１１＿１１００＿００００｝とコンパクトに表現することができる。これは、図７Ｂの拡張後のイーサネットパケットヘッダ７００’の先頭から連続するバイト数が１２であり、その次に無効なバイトが４個続いてから、有効なバイトが６個続くことを表している。
【００９５】
さらなる他の例として、図８Ｃのビットベクトル８０５は｛１２，００００＿００００＿１１００＿００００｝とコンパクトに表現することができる。これは、図８Ｂの拡張後のイーサネットパケットヘッダ８００’の先頭から連続するバイト数が１２であり、その次に無効なバイトが８個続いてから、有効なバイトが２個続くことを表している。
【００９６】
図１４に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１４００を示す。過程１４０５で、拡張後のプロトコルヘッダを得る。既述したように、拡張後のプロトコルヘッダとは、受信パケットのプロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化したものである。典型的に、プロトコルヘッダの汎用化は、リライトエンジンが、そのプロトコルヘッダから欠けているフィールドを検出し、さらに、そのプロトコルヘッダを、当該検出の結果に基づいて汎用フォーマットに従って拡張することで実行される。汎用フォーマットは、そのプロトコルについて想定される全てのフィールドを備えている。それら各フィールドのオフセットは、そのプロトコルヘッダのプロトコルの変種にかかわらず同一である。
【００９７】
過程１４１０で、拡張後のプロトコルヘッダの表現を保持する。この表現は、連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ）フィールドとビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドとを有するデータ構造である。
【００９８】
過程１４１５で、連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ）フィールドを、拡張後のプロトコルヘッダの先頭から連続する有効なバイト数に設定する。
【００９９】
過程１４２０で、ビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドについて、前記連続する有効なバイトの後の、無効フィールドにおける全てのバイトに対する各ビットを、無効であるとマークする。無効フィールドのそれぞれは、前記受信パケットのプロトコルヘッダ内に存在しないフィールドである。
【０１００】
過程１４２５で、ビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドについて、前記連続する有効なバイトの後の、有効フィールドにおける全てのバイトに対する各ビットを、有効であるとマークする。有効フィールドのそれぞれは、前記受信パケットのプロトコルヘッダ内に存在するフィールドである。
【０１０１】
図１５に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１５００を示す。過程１５０５で、このネットワークスイッチの受信ポートでパケットを受信する。
【０１０２】
過程１５１０で、そのパケットのプロトコルヘッダを、そのプロトコルの汎用フォーマットに従って汎用化する。典型的に、プロトコルの汎用化は、リライトエンジンにより実行される。
【０１０３】
過程１５１５で、汎用化後のプロトコルヘッダを、そのプロトコルヘッダのサイズに影響されないデータ構造で表現する。一部の実施形態において、このデータ構造は、プロトコルレイヤの先頭から連続する有効なバイト数を表した連続バイト（ｃｏｎｔｉｎｕｏｕｓ＿ｂｙｔｅ）フィールドと、そのプロトコルヘッダの各バイトをビットで表したビットベクトル（ｂｉｔｖｅｃｔｏｒ）フィールドとを有する。
【０１０４】
このようなデータ構造を用いることにより、各種プロトコルレイヤを表す汎用的な表現を、プロトコルレイヤヘッダのサイズに影響されない表現とすることができる。また、ビットベクトルをコンパクトに表現するので、ハードウェアコストを削減することができて有利である。
【０１０５】
［ヘッダの変更に用いる汎用的な命令］
変更は、拡張後のプロトコルヘッダに適用され得る汎用的な命令のセットを用いる。これら命令は、受信時のヘッダ（例えば、サイズ、プロトコルなど）に影響されないので、いずれも汎用的な命令であると言える。
【０１０６】
以下の表１に、リライトエンジンがプロトコルヘッダの変更のために使用する、汎用的な命令の一覧を示す。このように、少数セットの汎用的な命令を、受信時のパケットのヘッダ（例えば、サイズ、プロトコルなど）にかかわらずヘッダの変更に用いることができるのは、その変更対象のパケットのヘッダが変更に先立って汎用化されているからである。典型的に、これら汎用的な命令は、ソフトウェアによりプログラム可能なマイクロコードのように機能する。
【０１０７】
【表１】
0006608628.tif 000002
【０１０８】
デリート（ＤＥＬＥＴＥ）命令は、汎用化後のプロトコルレイヤ内において開始（Ｓｔａｒｔ）位置からサイズ（Ｓｉｚｅ）分のバイトを、無効なバイトとすることによりデリートし得る。具体的に述べると、ビットベクトルのうち、これらのバイトに対応するビットが０にマークされ得る。
【０１０９】
コピー（ＣＯＰＹ）命令は、ソース（Ｓｏｕｒｃｅ）のソースオフセット（ＳｏｕｒｃｅＯｆｆｓｅｔ）から、サイズ（Ｓｉｚｅ）分のバイトのデータを、汎用化後のプロトコルレイヤの宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）にコピーし得る。また、コピー（ＣＯＰＹ）命令は、ソース（Ｓｏｕｒｃｅ）のデータの有効性に応じて、対応するコピー先のバイトを有効なバイト又は無効なバイトにし得る。具体的に述べると、ビットベクトルにおいて無効なバイトを表すビットが０にマークされ得る。ビットベクトルにおいて有効なバイトを表すビットが１にマークされ得る。また、コピー（ＣＯＰＹ）命令は、ビットマスク（Ｂｉｔｍａｓｋ）を用いてビットマスク演算を実行可能であり得る。また、コピー（ＣＯＰＹ）命令は、コピー一定ビットマスク（ｃｏｐｙＣｏｎｓｔａｎｔＢｉｔＭａｓｋ）およびコピー一定データ（ｃｏｐｙＣｏｎｓｔａｎｔＤａｔａ）を使用可能であり得る。具体的に述べると、コピー一定ビットマスク（ｃｏｐｙＣｏｎｓｔａｎｔＢｉｔＭａｓｋ）が所与のビット位置に「１」を有するとき、コピー一定データ（ｃｏｐｙＣｏｎｓｔａｎｔＤａｔａ）における対応する位置のバイトを、汎用化後のヘッダレイヤにおける対応する位置にコピーし得る。一部の実施形態では、一定データはテーブルに記憶されている。一部の実施形態では、一定データが、ソフトウェアで定義される。
【０１１０】
移動（ＭＯＶＥ）命令は、汎用化後のプロトコルレイヤ内において開始オフセット（ＳｔａｒｔＯｆｆｓｅｔ）からサイズ（Ｓｉｚｅ）分のバイトを、宛先オフセット（ＤｅｓｔｉｎａｔｉｏｎＯｆｆｓｅｔ）に移動し得る。また、移動（ＭＯＶＥ）命令は、ソース（Ｓｏｕｒｃｅ）のデータの有効性に応じて、対応する移動先のバイトを有効なバイト又は無効なバイトにし得る。具体的に述べると、ビットベクトルにおいて無効なバイトを表すビットが０にマークされ得る。ビットベクトルにおいて有効なバイトを表すビットが１にマークされ得る。
【０１１１】
少なくとも１つのカウンタ（計数手段）を用いることにより、実行された全ての演算についての追加された又はデリートされたバイト数が計数され得る。この少なくとも１つのカウンタは、ハードウェアカウンタであり得る。あるいは、この少なくとも１つのカウンタは、ソフトウェアカウンタであり得る。この少なくとも１つのカウンタは、統計目的およびその他の目的で、その計数値を監視し得る。一部の実施形態では、リライトエンジンが、変更前のビットベクトルと変更後のビットベクトルとの２つのビットベクトルにＸＯＲ演算を実行することにより、変更のあったビット数をハードウェアに認識させる。この情報は、デリートされた又は追加されたバイトの数の計算に利用され得る。
【０１１２】
図１６に、本発明の一部の実施形態での、リライトエンジンの他の動作方法１６００を示す。このリライトエンジンは、ネットワークスイッチの一部であり、パケットをネットワークスイッチから送出される前に変更する。過程１６０５で、パケットの各プロトコルヘッダを、当該プロトコルヘッダの汎用フォーマットに従って汎用化する。この汎用フォーマットは、そのプロトコルについて想定されるフィールド全てを備える。よって、それら各フィールドのオフセットは、そのプロトコルヘッダのプロトコルの変種にかかわらず同一であり得る。汎用化後の各プロトコルヘッダは、ビットベクトルを備え得る。このビットベクトルは、汎用化後のプロトコルヘッダの各バイトに対して１ビットを有し得る。このビットベクトルは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされる。ここで、無効フィールドとは、受信時のパケットのプロトコルヘッダ内に存在しないフィールドであり、有効フィールドとは、受信時のパケットのプロトコルヘッダ内に存在するフィールドである。
【０１１３】
過程１６１０で、前記ネットワークスイッチのメモリに記憶された汎用的な命令のセットから、少なくとも１つの命令を用いることにより、汎用化後の少なくとも１つのプロトコルヘッダを変更する。汎用化後の少なくとも１つのプロトコルヘッダを、前記ネットワークスイッチの送信ポートの出口側ポートタイプに基づいて変更し得る。汎用化後の少なくとも１つのプロトコルヘッダを変更すると、ビットベクトルが更新され得る。
【０１１４】
汎用的な命令の前記セットは、受信時のパケットのヘッダにかかわらず、ヘッダを変更することができる。したがって、汎用的な命令の前記セットは、あるプロトコルの、第１の変種のパケットヘッダを変更するのにも第２の変種のパケットヘッダを変更するのにも使用され得る。同様に、汎用的な命令の前記セットは、第１のプロトコルのパケットヘッダを変更するのにも第２のプロトコルのパケットヘッダを変更するのにも使用され得る。
【０１１５】
図１７に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１７００を示す。過程１７０５で、ネットワークスイッチのメモリ内に、汎用的な命令のセットを保持する。
【０１１６】
過程１７１０で、前記ネットワークスイッチの受信ポートでパケットを受信する。
【０１１７】
過程１７１５で、前記パケットの各プロトコルヘッダを、当該プロトコルヘッダの汎用フォーマットに従って汎用化する。前記パケットの前記プロトコルヘッダから、欠けているフィールドを検出し得る。そのプロトコルヘッダを、前記検出の結果に基づいて、前記欠けているフィールドを含めることにより、前記汎用フォーマットに拡張し得る。汎用化後の各プロトコルヘッダは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされたビットベクトルを備える。ここで、無効フィールドとは、受信時のパケットのプロトコルヘッダ内に存在しないフィールドであり、有効フィールドとは、受信時のパケットのプロトコルヘッダ内に存在するフィールドである。
【０１１８】
過程１７２０で、汎用的な命令の前記セットから、少なくとも１つの命令を、汎用化後のプロトコルヘッダに適用することにより、汎用化後の少なくとも１つのプロトコルヘッダを変更する。これにより、前記ビットベクトルが更新される。
【０１１９】
過程１７２５で、更新後のビットベクトルに基づいて、新しいプロトコルヘッダを形成する。
【０１２０】
過程１７３０で、前記パケットを、前記新しいプロトコルヘッダ付きで、前記ネットワークスイッチの送信ポートから送信する。一部の実施形態では、前記パケットを前記新しいプロトコルヘッダ付きで送信するのに先立って、実行された全てのオペレーション（演算）について、追加された又はデリートされたバイト数を計数する。
【０１２１】
［変更後のプロトコルヘッダの、ビットベクトルを用いての減縮（縮小）］
リライトエンジンは、プロトコルヘッダを変更用の汎用フォーマットに基づいて拡張するためだけに限らず、そのプロトコルヘッダを当該汎用フォーマットから「通常の」フォーマットに減縮するためにも、各プロトコルヘッダに対するビットベクトルを用い得る。典型的に、ビットベクトルの各ビットは、汎用化後のプロトコルヘッダ内の１バイトを表している。ビットベクトルにおいて０にマークされたビットは無効なバイトに対応し、１にマークされたビットは有効なバイトに対応する。汎用化後のプロトコルヘッダに対して全ての命令が実行された後、リライトエンジンが、ビットベクトルを用いて無効なバイトを全て除外することにより、新しいプロトコルヘッダを形成し得る。このように、リライトエンジンは、ビットベクトルを用いて、パケット内のプロトコルヘッダを拡張することも減縮することも可能であり得る。つまり、汎用的な命令のセットを用いることにより、パケットの柔軟な変更が実施可能になり得る。
【０１２２】
一例として仮定１を参照すると、図９Ｅのビットベクトル９２０は、図９Ｂの汎用化後のプロトコルヘッダ９０５にデリート（Ｄｅｌｅｔｅ）命令を適用してなる、図９Ｄの変更後のプロトコルヘッダ９１５を表している。この仮定１では、カスタマＶＬＡＮタグがデリートされることで、そのカスタマＶＬＡＮタグの４バイト分が無効にされる。すなわち、ビットベクトル９２０において、カスタマＶＬＡＮタグに対応するビットが０にマークされる。全ての命令（仮定１ではデリート（Ｄｅｌｅｔｅ）命令）が実行された後、リライトエンジンが、ビットベクトル９２０を用いて無効なバイトを全て除外する。これにより、ビットベクトル９２０が減縮される。減縮後のビットベクトルに基づいて、新しいプロトコルヘッダが形成される。図９Ｆには、無効なバイトが全て除外されてなる新しいプロトコルヘッダ９２５が示されている。仮定１のパケットは、この新しいヘッダ９２５付きで送信イーサネットポートから送出される。
【０１２３】
他の例として仮定２を参照すると、図１０Ｄのビットベクトル１０１５は、図１０Ａのプロトコルヘッダ１０００にデリート（Ｄｅｌｅｔｅ）命令を適用してなる、図１０Ｃの変更後のプロトコルヘッダ９１５を表している。この仮定２では、サービスＶＬＡＮタグおよびカスタマＶＬＡＮタグがデリートされることで、それらサービスＶＬＡＮタグの４バイト分およびカスタマＶＬＡＮタグの４バイト分が無効にされる。すなわち、ビットベクトル１０１５において、サービスＶＬＡＮタグに対応するビットおよびカスタマＶＬＡＮタグに対応するビットが０にマークされる。全ての命令（仮定２では２回のデリート（Ｄｅｌｅｔｅ）命令）が実行された後、リライトエンジンが、ビットベクトル１０１５を用いて無効なバイトを全て除外する。これにより、ビットベクトル１０１５が減縮される。減縮後のビットベクトルに基づいて、新しいプロトコルヘッダが形成される。図１０Ｅには、無効なバイトが全て除外されてなる新しいプロトコルヘッダ１０２０が示されている。仮定２のパケットは、この新しいヘッダ１０２０付きで送信イーサネットポートから送出される。
【０１２４】
図１８に、本発明の一部の実施形態での、リライトエンジンのさらなる他の動作方法１８００を示す。このリライトエンジンは、ネットワークスイッチの一部であり、パケットをネットワークスイッチから送出される前に変更する。過程１８０５で、汎用化後の各プロトコルヘッダに対するビットベクトルを保持する。汎用化後のプロトコルヘッダとは、パケットのうち、汎用フォーマットに拡張されたプロトコルヘッダのことである。この汎用フォーマットは、そのプロトコルについて想定される全てのフィールドを備えている。それら各フィールドのオフセットは、そのプロトコルヘッダのプロトコルの変種にかかわらず同一であり得る。前記ビットベクトルは、汎用化後のプロトコルヘッダの各バイトに対して１ビットを有し得る。
【０１２５】
過程１８１０で、汎用化後の少なくとも１つのプロトコルヘッダの前記変更に基づいて、前記ビットベクトルを更新する。その変更過程は、ネットワークスイッチのメモリに記憶された汎用的な命令のセットから、少なくとも１つの命令を用いることにより、汎用化後の少なくとも１つのプロトコルヘッダを変更することを含み得る。
【０１２６】
過程１８１５で、更新後のビットベクトルを用いて、汎用化後の少なくとも１つのプロトコルヘッダを圧縮する。一部の実施形態では、過程１８１５に先立って、前記ビットベクトルと更新後の当該ビットベクトルとにＸＯＲ演算を実行することにより、変更のあったビット数を求める。これにより、リライトエンジンは、デリートされたバイトおよび追加されたバイトの数を計算することができる。
【０１２７】
図１９に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法１９００を示す。過程１９０５で、このネットワークスイッチの受信ポートでパケットを受信する。
【０１２８】
過程１９１０で、前記パケットにおける各プロトコルヘッダを、そのプロトコルヘッダの汎用フォーマットに従って汎用化する。前記パケットにおけるそのプロトコルヘッダから、欠けているフィールドを検出し得る。具体的に述べると、そのプロトコルヘッダを、前記検出の結果に基づいて、欠けているフィールドを含めることにより、汎用フォーマットに拡張し得る。
【０１２９】
過程１９１５で、汎用化後の各プロトコルヘッダに対するビットベクトルを保持する。このビットベクトルは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされる。
【０１３０】
過程１９２０で、汎用化後の少なくとも１つのプロトコルヘッダを変更することにより、前記ビットベクトルが更新される。その変更過程は、ネットワークスイッチのメモリに記憶された汎用的な命令のセットから、少なくとも１つの命令を用いて、汎用化後の少なくとも１つのプロトコルヘッダを変更することを含み得る。具体的に述べると、汎用化後の少なくとも１つのプロトコルヘッダを、ネットワークスイッチの送信ポートの出口側ポートタイプに基づいて変更し得る。
【０１３１】
過程１９２５で、更新後のビットベクトルについて、そのビットベクトルにおいて０にマークされたビットを全て除外するようにシフトすることにより、当該更新後のビットベクトルを減縮する。
【０１３２】
過程１９３０で、減縮後のビットベクトルに基づいて、コンパクトなプロトコルヘッダを形成する。前記パケットは、少なくともこのコンパクトなプロトコルヘッダ付きで、前記ネットワークスイッチの送信ポートから送出され得る。一部の実施形態では、パケットを送出する過程に先立って、実行された全てのオペレーション（演算）について、追加された又はデリートされたバイト数を計数する。
【０１３３】
［ポインタ構造］
受信パケットから、複数の互いに異なるプロトコルレイヤを汎用化のためにそれぞれ抽出したり、これらのプロトコルレイヤの変更後にパケットを再構築したりするのに、ポインタ構造（ポインタ構造体）が使用され得る。このポインタ構造は、Ｎ＋１個のレイヤポインタおよびそのパケット内の全てのヘッダの合計サイズを含み得る。典型的に、このポインタ構造は、パーサエンジンにより供給されるデータを用いて予め更新（初期化）され、リライトエンジンが、そのポインタ構造を用いてパケットを個々のレイヤに分割し、さらに、そのポインタ構造を用いてこれら個々のレイヤを情報処理で（知的に（intelligently））継合する。具体的に述べると、リライトエンジンは、パケットを個々のレイヤに分割した後、プロトコルヘッダを汎用化し、汎用化後のプロトコルヘッダを変更し、さらに、無効なバイトを全て除外することによって汎用化後のプロトコルヘッダを圧縮し得る。リライトエンジンは、レイヤを変更すると、前記レイヤポインタを更新し得る。パケットをネットワークスイッチから送信するのに先立って、更新後のレイヤポインタを用いて、互いに異なるプロトコルレイヤを互いに継合し得る。このようにプロトコルレイヤを互いに継合するため、複数のプロトコルレイヤを実体的には連続させずとも、レイヤポインタによってあたかもプロコルレイヤが連続するかのように扱う（仮想的に連続させる）ことが可能となる。
【０１３４】
図２０に、本発明の一部の実施形態での、レイヤ構造の一例２０００を示す。ここでは、受信パケットが、独自ヘッダ（独自プロトコルのヘッダ）、イーサネット、ＩＰｖ４、ＵＤＰ、ＶｘＬＡＮおよびイーサネットの各プロトコルレイヤを有していると仮定する。さらに、ネットワークスイッチのパーサエンジンが最大で８層のレイヤをパース処理可能な一方で、それと並行してリライトエンジンにより変更可能なプロトコルレイヤの層数が、（ソフトウェア要求および／またはハードウェア能力のために）先頭からＮ層（ここでは、Ｎ＝４とする）のプロトコルレイヤに限られるものと仮定する。一部の実施形態において、パーサエンジンは、パケット内における各プロトコルヘッダの開始位置等のデータをリライトエンジンに供給する。
【０１３５】
この例におけるリライトエンジンは、パケットの先頭から４層のプロトコルレイヤしか変更できないので、パーサエンジンからの関連データのみを、すなわち、パーサエンジンから独自ヘッダ、イーサネット、ＩＰｖ４およびＵＤＰからなる先頭から４層のプロトコルレイヤに関するデータのみを用い得る。このデータを用いて、そのパケットに対するポインタ構造が初期化され得る。具体的に述べると、レイヤポインタ０（ＬａｙｅｒＰｏｉｎｔｅｒ０）が、そのパケット内における独自ヘッダ（すなわち、レイヤ０）の開始位置である０に設定され、レイヤポインタ１（ＬａｙｅｒＰｏｉｎｔｅｒ１）が、そのパケット内におけるイーサネットヘッダ（すなわち、レイヤ１）の開始位置である１６に設定され、レイヤポインタ２（ＬａｙｅｒＰｏｉｎｔｅｒ２）が、そのパケット内におけるＩＰｖ４ヘッダ（すなわち、レイヤ２）の開始位置である３６に設定され、レイヤポインタ３（ＬａｙｅｒＰｏｉｎｔｅｒ３）が、そのパケット内におけるＵＤＰヘッダ（すなわち、レイヤ３）の開始位置である４８に設定され、レイヤポインタ４（ＬａｙｅｒＰｏｉｎｔｅｒ４）が、リライトエンジンにより変更されない、ヘッダの残りの部分の開始位置である５６に設定され得る。一部の実施形態において、リライトエンジンは、ヘッダのサイズを算出してヘッダサイズ（ＨｅａｄｅｒＳｉｚｅ）（すなわち、全てのヘッダの合計サイズ）を２２３に設定する。
【０１３６】
リライトエンジンは、これらのレイヤポインタを用いて、先頭から４層のプロトコルレイヤ（すなわち、独自ヘッダ、イーサネット、ＩＰｖ４およびＵＤＰ）を変更用に汎用化し得る。そして、リライトエンジンは、変更を実施した後、無効なバイトを全て除外することにより、変更後のプロトコルヘッダを圧縮し得る。典型的に、プロトコルヘッダが変更されると、前記レイヤポインタが更新される。
【０１３７】
また、これらのレイヤポインタは終点ポインタを形成し得る。前記ヘッダサイズ（ＨｅａｄｅｒＳｉｚｅ）を伴ったこの終点ポインタは、ヘッダのボディに関連付けられる。ヘッダのボディとは、そのヘッダにおいて変更されない部分であって、後で継合するために伝達される部分のことである。全ての変更が実行されて、変更されたヘッダが圧縮されると、同じく変更された前記レイヤポインタを用いて、これら変更後のヘッダ同士がそれらのボディと一緒に継合され得る。
【０１３８】
リライトエンジンが変更できるレイヤの層数は限られ得る。一部の実施形態では、リライトエンジンが任意のプロトコルレイヤを拡張できる程度（大きさ）も限られ得る。この実施形態では、リライトエンジンが、２つの隣り合うレイヤポインタ同士を減算することにより、プロトコルレイヤのサイズを抽出する。そのレイヤのサイズがリライトエンジンのハードウェア能力を超えている場合、当該リライトエンジンは、１つ前のレイヤポインタを用いて情報処理でボディを形成し得る。
【０１３９】
１つのプロトコルレイヤを拡張できる大きさが最大４０バイトであるにもかかわらず、そのプロトコルのなかで最も大きい変種が６４バイトであると仮定する。一部の実施形態において、リライトエンジンは、変更のためにプロトコルヘッダを最大４０バイトまで拡張する。リライトエンジンは、変更を実施した後、レイヤポインタを用いて、未変更のバイトを変更されたバイトに継合し得る。
【０１４０】
レイヤポインタを使用することにより、プロトコルレイヤを１つずつ取り扱うことになるので、ハードウェアのロジックや複雑性を大幅に軽減することができる。具体的に述べると、ハードウェアの命令の範囲を、所与のプロトコルレイヤに絞ることができる。すなわち、命令エンジンが前後のレイヤに影響されないので、各層に必要な命令を増やしたい場合には、命令ハードウェア（命令を含むハードウェア）をマルチパスで利用すればよい。換言すれば、命令の内部状態に命令間で相関性がないことから、複数の命令を並行して利用することができる。同様に、複数層のレイヤを並行して変更することも可能である。
【０１４１】
図２１に、本発明の一部の実施形態での、リライトエンジンのさらなる他の動作方法２１００を示す。このリライトエンジンは、ネットワークスイッチの一部であり、パケットをネットワークスイッチから送出される前に変更する。過程２１０５で、各パケットに対するポインタ構造を保持する。このポインタ構造は、レイヤポインタおよびそのパケット内の全てのヘッダの合計サイズを含む。これらレイヤポインタのそれぞれは、パケット内の関連レイヤの開始位置に対応する。
【０１４２】
前記ポインタ構造はＮ＋１個のレイヤポインタを含み得る。リライトエンジンにより、パケット内のＮ層のレイヤを変更し得る。前記レイヤポインタは終点を形成し得る。この終点は、前記合計サイズを伴って、ヘッダのボディを示し得る。ヘッダのボディとは、リライトエンジンにより変更されないヘッダ部分である。
【０１４３】
過程２１１０で、パケットを、レイヤの変更のために、前記レイヤポインタに基づいてレイヤに分割する。そのパケットのプロトコルヘッダから、欠けているフィールドを検出し得る。このプロトコルヘッダを、前記検出の結果に基づいて、そのプロトコルの汎用フォーマットに拡張し得る。この汎用フォーマットは、そのプロトコルについて想定されるフィールド全てを備えている。それら各フィールドのオフセットは、そのプロトコルヘッダのプロトコルの変種にかかわらず同一であり得る。汎用化後の各プロトコルヘッダは、無効フィールドについてはビットが０にマークされて有効フィールドについてはビットが１にマークされたビットベクトルを備え得る。汎用的な命令のセットから、少なくとも１つの命令を用いることにより、汎用化後のプロトコルヘッダを変更し得る。典型的に変更後に前記ビットベクトルを更新する。
【０１４４】
過程２１１５で、レイヤポインタを、レイヤの変更の結果に基づいて更新する。
【０１４５】
過程２１２０で、複数のレイヤを、更新後のレイヤポインタに基づいて互いに継合する。
【０１４６】
図２２に、本発明の一部の実施形態での、ネットワークスイッチのさらなる他の動作方法２２００を示す。過程２２０５で、このネットワークスイッチの受信ポートでパケットを受信する。
【０１４７】
過程２２１０で、ポインタ構造を用いることにより、そのパケットのプロトコルレイヤを互いに分離する。このポインタ構造は、そのパケット内のＮ＋１個の位置へのＮ＋１個のレイヤポインタ、および当該パケット内の全てのヘッダの合計サイズを含み得る。前記位置は、プロトコルレイヤの開始位置であり得る。そのパケットをパース処理したデータに基づいて、前記ポインタ構造を初期化し得る。
【０１４８】
過程２２１５で、分離後のプロトコルレイヤを、変更用に汎用化する。各レイヤについて、当該レイヤのサイズを抽出することにより、そのサイズが当該レイヤを変更するためのハードウェア能力を超えているか否かを判断し得る。前記ポインタ構造における２つの隣り合うレイヤポインタ同士を減算することにより、前記サイズを抽出し得る。前記判断の結果に基づいて、前記２つの隣り合うレイヤポインタのうちの先のレイヤポインタを用いてボディを形成し得る。
【０１４９】
過程２２２０で、前記ポインタ構造を、変更に基づいて更新する。
【０１５０】
過程２２２５で、更新後のポインタ構造を用いることにより、変更後のプロトコルレイヤを情報処理で継合する。これにより、新しいプロトコルヘッダスタックを形成する。
【０１５１】
過程２２３０で、前記パケットを、その新しいプロトコルヘッダスタック付きで、ネットワークスイッチの送信ポートから送出する。
【０１５２】
当業者であれば、上記以外にも用途や利点が存在することが理解できるであろう。これまでの本発明の説明は幾つかの具体例に基づいたものであったが、当業者であれば、本発明の精神を逸脱することなく本発明をその他の具体的な形態でも実施可能であることを理解できるであろう。すなわち、当業者であれば、本発明が前述の具体例に限定されるものではなく、添付の特許請求の範囲により規定されるものであることを理解するであろう。
【図１】
0006608628.tif 000003
【図２】
0006608628.tif 000004
【図３】
0006608628.tif 000005
【図４】
0006608628.tif 000006
【図５】
0006608628.tif 000007
【図６Ａ】
0006608628.tif 000008
【図６Ｂ】
0006608628.tif 000009
【図７Ａ】
0006608628.tif 000010
【図７Ｂ】
0006608628.tif 000011
【図７Ｃ】
0006608628.tif 000012
【図８Ａ】
0006608628.tif 000013
【図８Ｂ】
0006608628.tif 000014
【図８Ｃ】
0006608628.tif 000015
【図９Ａ】
0006608628.tif 000016
【図９Ｂ】
0006608628.tif 000017
【図９Ｃ】
0006608628.tif 000018
【図９Ｄ】
0006608628.tif 000019
【図９Ｅ】
0006608628.tif 000020
【図９Ｆ】
0006608628.tif 000021
【図１０Ａ】
0006608628.tif 000022
【図１０Ｂ】
0006608628.tif 000023
【図１０Ｃ】
0006608628.tif 000024
【図１０Ｄ】
0006608628.tif 000025
【図１０Ｅ】
0006608628.tif 000026
【図１１】
0006608628.tif 000027
【図１２】
0006608628.tif 000028
【図１３】
0006608628.tif 000029
【図１４】
0006608628.tif 000030
【図１５】
0006608628.tif 000031
【図１６】
0006608628.tif 000032
【図１７】
0006608628.tif 000033
【図１８】
0006608628.tif 000034
【図１９】
0006608628.tif 000035
【図２０】
0006608628.tif 000036
【図２１】
0006608628.tif 000037
【図２２】
0006608628.tif 000038