JP4814489B2 - 階層化ヘッダ付きのパケットの処理方法、システム及びコンピュータ製品 - Google Patents

Description

本発明はパケットを処理する方法、そのためのシステム及びコンピュータプログラム製品に関し、より具体的には、階層化ヘッダが付いたパケットの処理方法、システム及びコンピュータプログラム製品に関する。

インターネットプロトコル（ＩＰ）は、解放形システム相互接続（ＯＳＩ）モデルの第３層（ネットワーク層）の中に存在する。ＩＰは、ネットワーク内のノード間の接続すなわちデータグラムサービスを提供する。ＩＰホストはＩＰヘッダ付きのデータをカプセル化し、このデータは次にデータリンク層に送られる。データリンクプロトコルはＩＰヘッダ及びデータをそれ自身のヘッダを用いてカプセル化し、次にカプセル化されたパケットを物理層に送る。物理層でこのパケットはさらに別のヘッダを用いてカプセル化され、シリアルのビットストリームとしてネットワークに送信される。

ＩＰバージョン４用のＩＰヘッダ内で使用されるフィールドを図１に示す。第１のフィールドは、ヘッダを作るために使用されるＩＰのバージョンである。古いＩＰバージョンで動作するネットワークは、新しいＩＰバージョンに関連したヘッダによりカプセル化されたパケットを処理することはできない。インターネットヘッダ長（ＩＨＬ）フィールドがバージョンフィールドに続き、ＩＰヘッダの長さを３２ビットワードに規定する。サービス形式フィールド（type-of-service field）がＩＨＬフィールドに続き、パケットに適用される遅延、信頼性及びスループットの点からサービスの品質を規定する。全長フィールドはサービス形式フィールドの後に続き、ＩＰヘッダ及びＩＰヘッダの後に続くデータの長さを規定する。データにはユーザのペイロード／データに加えて、ＴＣＰ／ＵＤＰヘッダなどのトランスポート層ヘッダ及び／又はＩＰセキュリティプロトコル（ＩＰＳｅｃ）ヘッダなどのセキュリティヘッダが含まれることに注意されたい。

識別（ＩＤ）フィールドは、データユニットのフラグメントを関連させるために使用される。例えば、データユニットがフラグメントになっている場合、ＩＤ番号が種々のフラグメントに割り当てられて、レシーバがＩＤを突き合わせてパケットを再組立てできるようにする。３つのフラグビットが識別フィールドの後に続く。それらのビットの１つはハードウェアでゼロにコード化されており、１つは断片化が可能であるかどうかを示し、また１つは現在のフラグメントが最後のフラグメントであるかどうかを示す。フラグメントオフセットフィールドがフラグフィールドの後に続き、データグラム内のどこにこの特定のフラグメントが属しているかを示す。第１のフラグメントのオフセットはゼロである。

有効期間フィールド（time-to-live field）は、パケットがシステム内に留まる時間を示す。この有効期間フィールドは、ホップカウンタとして実現される。パケットがルータを横切るたびに、ルータはこのフィールドの値を１だけ減らす。有効期間フィールドがゼロに達すると、このパケットは消滅される。このフィールドは、発送不可のパケットがネットワークを通って無限に循環しないようにする。プロトコルフィールドが有効期間フィールドの後に続き、ユーザのペイロード／データに関連した次のレベルのプロトコルを規定する。Internet Assigned Numbers Authority (IANA)は、認識されたプロトコル及びそれに関連した番号のリストを自身のウェブサイトwww.iana.org.で保持する。ヘッダチェックサム（header checksum）がプロトコルフィールドの後に続き、これはＩＰパケットのヘッダ部分のみに対するチェックサムである。

ネットワーク内のルータ及びゲートウェイはソース及び宛先ＩＰアドレスを使用して、ＩＰパケットを発送する。オプションフィールドが含まれ、ネットワーク制御及び／又はディバッグなどの特定のアプリケーションに対して使用される。パディングフィールドが選択自由のオプションフィールドの後に続いて、ＩＰヘッダが確実に３２ビットの境界で終わるようにする。

パケットがネットワーク内のトラバースノード（traversing node）又はステーションである場合、そのパケットは複数のＩＰヘッダを用いてカプセル化されるようになる。そのようなカプセル化の例は、C. Perkinsによる「IP Encapsulation within IP」という題名の資料Internet Engineering Task Force (IETF) Request for Comment (RFC) document 2003、１９９６年１０月（以後、「RFC 2003」と呼ぶ）、C. Perkinsによる「Minimal Encapsulation Within IP」という題名の資料IETF RFC document 2004、１９９６年１０月（以後、「RFC 2004」と呼ぶ）、S. Kentによる「IP Encapsulating Security Payldoad (ESP)」という題名の資料IETF RFC document 2406、１９９８年１１月（以後、「RFC 2406」と呼ぶ）、及びA. Shachamらによる「IP Payload Compression Protocol (IPComp)」という題名の資料IETF RFC document 3173、２００１年９月（以後、「RFC 3173」と呼ぶ）の中で開示されている。これらの開示内容は、参照することによって本願に組み込まれる。ＩＰパケットを複数の階層化したヘッダを用いて処理する場合、従来のパケットプロセッサシステムは外部ＩＰヘッダから内部ＩＰヘッダまで構文解析して、このＩＰパケットを処理する方法を決定するために、内部ＩＰヘッダ内のプロトコルフィールドを調査する。従来のパケットプロセッサシステムは、複数のＩＰヘッダを用いてＩＰパケットを構文解析するために使用されるオフセットによりハードウェア及び／又はソフトウェアの中でしっかりとコード化されることがある。同様に、ＩＰバージョン６は、パケットの始めに種々のプロトコルのラッパーを構成するネストされたヘッダを用いる同じ戦略に従っている。残念なことに、そのようなパケットプロセッサシステムは、パケットのヘッダ寸法及び／又はレイアウトが変わる場合は、再設計又は再構成する必要がある。

本発明のいくつかの実施形態では、パケットの第１のヘッダは、第１のプロトコルを得るために処理される。この第１のプロトコルは、データ構造からレコードを読み取るためのキーとして使用される。このデータ構造では、この第１のプロトコルはパケットの第２のヘッダ内のオフセットに関連している。パケットのこの第２のヘッダは、第２のヘッダ内のオフセットに基づいて処理されて、第２のプロトコルを取得する。都合がよいことに、パケットの第２のヘッダ内のプロトコルフィールドの位置をデータ構造内に記憶されたオフセットと位置的に関連付けることによって、パケットの寸法及び／又はレイアウトが変わることがあっても、データ構造内のオフセット情報は、パケットプロセッサの中のハードウェア及び／又はソフトウェアを再設計及び／又は再構成する必要なく更新することができる。

本発明の別の実施形態では、データ構造から読み取られたレコードは、第１のプロトコルをエネイブルフラグに関連付ける。パケットの第２のヘッダは第２のヘッダ内のオフセットに基づいて処理されて、エネイブルフラグが設定されている場合は、第２のプロトコルを得ることができる。このエネイブルフラグは、プロトコルの「基本的な」セットを不揮発性の記憶装置に記憶して、システムの初期化時に揮発性記憶装置にコピーできるようにする。この後、幾つかのプロトコルは、エネイブルビットを使用することによって無効にされる。

本発明のさらに別の実施形態では、データ構造から読み取られたレコードは、第１のプロトコルをパケットのペイロード／データ部分に対するオフセットに関連付ける。

本発明のさらに別の実施形態では、パケットはパケット変換動作などの第２のプロトコルに関連した動作に基づいて処理される。

本発明のさらに別の実施形態では、データ構造から読み取られたレコードは、第１のプロトコルを動作フラグに関連付け、パケットは動作フラグに関連した動作に基づいて処理される。

本発明のさらに別の実施形態では、第２のプロトコルは、第２のプロトコルが動作フラグに関連付けられたデータ構造から第２のレコードを読み取るためのキーとして使用される。このパケットは、動作フラグに関連付けられた動作に基づいて処理される。

本発明は上記のように主に本発明の方法の実施形態に関連して説明されたが、本発明は方法、システム及びコンピュータプログラム製品として具体化できることは理解されよう。

本発明の別の特徴は、以下の特定の実施形態の詳細な説明を添付の図面と併せて読めば、一層容易に理解されよう。

本発明については各種の修正や別の形態が可能であるが、その特定の実施形態を図面の中の実施例により示し、本願で詳細に説明する。しかしながら、本発明を開示された特定の形態に限定する意図はなく、逆に、本発明は、特許請求の範囲により定義する本発明の精神及び範囲の中に入る全ての変形例、等価なもの、及び代替例をカバーすることを理解されたい。同じ参照番号は、全ての図面の説明の中で同様の要素を意味する。

本発明の実施形態は、パケットの処理との関連でここに説明される。「パケット」という用語は、１つの装置から他の装置に全体として電子的に送信される情報のユニットを意味することは理解されよう。このため、「パケット」という用語は、本願で使用される場合、送信のユニットに言及するためにも使用される「フレーム」又は「メッセージ」というような技術用語を含む。

本発明は、システム、方法及び／又はコンピュータプログラム製品として具体化される。従って、本発明はハードウェア及び／又はソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）の中で具体化される。さらに、本発明は、命令実行システムが使用する又はそれと関係して使用される媒体の中で具体化されるコンピュータが使用可能又は読取り可能なプログラムコードを有するコンピュータが使用可能又は読取り可能な記憶媒体上で、コンピュータプログラム製品の形態を取ることができる。この資料に照らして、コンピュータが使用可能又は読取り可能な媒体は、命令実行システム、機器、又は装置が使用する又はそれらの関係において使用されるプログラムを含む、記憶する、通信する、伝送する、又は送信することができるどのような媒体であっても良い。

コンピュータが使用可能又は読取り可能な媒体は、例えば、電子的、磁気的、光学的、電磁気的、赤外線による、又は半導体のシステム、機器、装置又は伝搬媒体とすることができるが、これらに限定されることはない。コンピュータが読取り可能な媒体のより具体的な例（完全ではないリスト）には、下記が含まれる、すなわち、１つ以上の電線を有する電気的接続、携帯用のコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、消去可能プログラム可能読出し専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）、光ファイバー、及び携帯用コンパクトディスク読出し専用メモリ（ＣＤ−ＲＯＭ）が含まれる。コンピュータが使用可能又は読取り可能な媒体は、さらに、プログラムがプリントされる紙又は他の適当な媒体であっても良いことに注意されたい。その理由は、プログラムは、例えば、紙又は他の媒体を光学スキャニングすることによって電子的に収集し、次に、編集、解釈、又は必要な場合適当な方法で処理し、その後コンピュータのメモリの中に記憶することができるからである。

本発明の例示的な実施形態による方法、システム、及びコンピュータプログラム製品のフローチャート及び／又はブロック図を参照して、本発明をここで説明する。フローチャート及び／又はブロック図の各ブロック並びにフローチャート及び／又はブロック図内のブロックの組み合わせは、コンピュータプログラムの命令及び／又はハードウェアの動作によって実行することができることは理解されよう。これらのコンピュータプログラムの命令は、汎用コンピュータ、特殊目的のコンピュータ、又は他のプログラム可能なデータ処理装置のプロセッサに与えられて、コンピュータ又は他のプログラム可能なデータ処理装置のプロセッサを介して実行する命令が、フローチャート及び／又はブロック図のブロックの中で指定された機能を実行する手段を作り出すような装置を実現する。

コンピュータ又は他のプログラム可能なデータ処理装置を特定の方法で機能させることができるこれらのコンピュータプログラムの命令を、コンピュータが使用可能又は読取り可能なメモリの中に記憶して、コンピュータが使用可能又は読取り可能なメモリの中に記憶された命令が、フローチャート及び／又はブロック図のブロックの中で指定された機能を実行するような命令を含む製品を作ることもできる。

コンピュータプログラムの命令をコンピュータ又は他のプログラム可能なデータ処理装置にロードし、一連の動作ステップをコンピュータ又は他のプログラム可能な装置上で実行させて、コンピュータの実行による処理を行い、コンピュータ又は他のプログラム可能な装置上で実行される命令がフローチャート及び／又はブロック図のブロックの中で指定された機能を実行するステップを提供することもできる。

ここで図２を参照すると、本発明のいくつかの実施形態による、プロセッサ２０５及びメモリ２１０を備えたパケット処理システム２００が例示されている。プロセッサ２０５は、アドレス／データバス２１５を経由してメモリ２１０と通信する。プロセッサ２０５は、例えば、市販の又は特注のマイクロプロセッサとすることができる。いくつかの実施形態では、プロセッサをパケット処理用状態マシンとして実現できる。メモリ２１０は、本発明のいくつかの実施形態に基づいて、パケットを処理するためにプロセッサ２０５が使用するソフトウェア及びデータを含む１つ以上のメモリ装置を代表する。メモリ２１０は以下の種類の装置を含む、すなわち、キャッシュ、ＲＯＭ，ＰＲＯＭ，ＥＰＲＯＭ，ＥＥＰＲＯＭ、フラッシュ、ＳＲＡＭ、及びＤＲＡＭを含むが、これらに限定されることはない。パケット処理システム２００を新しいソフトウェア及び／又はデータにより更新できるようにするために、特にフィールドの設定の中で、書込み可能なメモリ装置を使用できる。図２に示すように、メモリ２１０は、本発明の幾つかの実施形態に基づいて以後詳細に説明するように、階層化ヘッダが付いたパケットの処理を容易にするプロトコルデータ構造２２０を含む。

図２は、本発明のいくつかの実施形態による階層化ヘッダ付きのパケットの処理を容易にする典型的なパケット処理システムのアーキテクチャを例示するが、本発明はそのような構成に限定されるものではなく、本願で説明される動作を実行できるどのような構成も含む意向であることは理解されよう。さらに、パケット処理システム２００の機能性は、個別のハードウェア要素、１つ以上の特定用途向け集積回路（ＡＳＩＣｓ）、又はプログラムされたディジタル信号プロセッサ又はマイクロコントローラを用いて実現することができるもさらに理解されよう。しかしながら、メモリ２１０に関連して前に説明したように、プログラム可能なパケット処理システム２００は、パケットの寸法及び／又は形式に変更がなされた場合、フィールドの設定の中でさえもプロトコルのデータ構造２２０を更新できるようにする。

本発明のいくつかの実施形態では、パケット処理システム２００は、複数の変換モジュールの全て又は一部から成る１つ以上のパケット変換モジュールを実行するために使用される。これらの変換モジュールは直列に又はパイプライン構成で互いに接続され、例えば、本願と同時出願され「Methods, Systems, and Computer Program Products for Processing a Packet-Object Using Multiple Pipelined Processing Modules」と言う名称の米国特許出願第＿＿＿号の中で開示されているような、ＩＰＳｅｃプロトコルに関連したパケット変換及び／又は暗号動作を実行する。この特許出願の開示内容は、参照することによって本願に組み込まれる。

ここで図３を参照すると、本発明のいくつかの実施形態に基づいた複数の階層化ヘッダから構成するパケット３００が示されている。このパケット３００は、例えば、ＩＰパケットとすることができ、第２の（内部）ＩＰヘッダ３１０及びＩＰペイロード／データ部分３１５をカプセル化する第１の（外部）ＩＰヘッダ３０５を含む。選択的に、パケット３００全体をカプセル化するパケットオブジェクトヘッダ３２０を使用できる。このパケットオブジェクトヘッダ３２０は、「Methods, Systems, and Computer Program Products for Processing a Packet-Object Using Multiple Pipelined Processing Modules」と言う名称の米国特許出願第＿＿＿号の中で開示されているような、パイプライン処理システムの中でパケット３００を処理するための情報を含む。僅か２つの階層化ＩＰヘッダ３０５及び３１０しか示していないが、パケット３００は、RFC 2003、RFC 2004、RFC 2406及び／又はRFC 3173の中で説明されているような別のＩＰヘッダを含むことができる。ＩＰペイロード／データ３１５はＵＤＰ又はＴＣＰペイロードのようなユーザのペイロード／データを含むことができ、いくつかの実施形態では、認証ヘッダ（ＡＨ）、カプセル化セキュリティペイロード（ＥＳＰ）、ＡＨ認証データ、及び／又はＥＳＰ認証データなどのＩＰＳｅｃを処理するための暗号用ヘッダ／情報を含むことができる。

ここで図４を参照すると、本発明のいくつかの実施形態による階層化ヘッダ付きのパケットを処理する具体例としての動作が、ブロック４００で開始する。このブロック４００において、パケットの第１のヘッダ（例えば、図３の第１のＩＰヘッダ）が処理されて、第１のプロトコル（例えば、図１のプロトコルフィールド）を得る。ネットワークによっては、パケットに関連したプロトコルに基づいてパケットを別々に処理することがある。例えば、ネットワークはウェブトラフィック（Web traffic）に関連したパケットを拒絶するが、イーメールのトラフィックに関連したパケットは受け入れる。このため、階層化ヘッダ付きのパケットを構文解析して、パケットに関連した下側のプロトコルを評価することが望ましい。

本発明のいくつかの実施形態では、第１のプロトコルをブロック４０５においてプロトコルのデータ構造２２０からレコードを読み取るキーとして使用し、第２のパケット用ヘッダ（例えば、図３の第２のＩＰヘッダ３１０）に対するオフセットを得る。これは例えば図５に示されている。この図５では、本発明のいくつかの実施形態による、プロトコルのデータ構造２２０として使用される具体例としてのデータ構造５００が示されている。図５に示すように、データ構造５００は、各レコードがプロトコルフィールド、エネイブルフィールド、及び次ヘッダ内オフセット用フィールド、対ペイロードオフセット用フィールド、及びフラグフィールドから成るレコードのテーブルから構成する。このプロトコルフィールドは、パケット用ヘッダ内のプロトコルフィールドに該当する。エネイブルフィールドは、カプセル化されたヘッダ／プロトコルに対してパケットを構文解析するかどうかを示す２進の「肯定」又は「否定」フィールドとして実現される。次ヘッダ内オフセット用フィールドは、カプセル化されたヘッダ内のプロトコルフィールドの位置を示す。対ペイロードオフセット用フィールドは、パケットのペイロード／データ部分（例えば、図３のＩＰペイロード／データ）の位置を示す。フラグフィールドは、特定のプロトコルに対してパケット上で実行される動作を示す。例えば、そのような動作には、ソース及び／又は宛先ポートのアドレスを引き出すパケット処理動作が含まれる。プロトコルのデータ構造２２０はこれらのフィールドに限定されることはなく、本発明の各種の実施形態に基づいて、別のフィールドを含んだり、図５に示した１つ以上のフィールドを取り除くことができる。さらに、テーブルを図５に示したが、他の種類のデータ構造も本発明の原理から逸脱することなく使用できる。

図４の説明に戻ると、プロトコルのデータ構造からのレコードが第２の（内部の）パケット用ヘッダ内のオフセットを得るためのキーとして第１のプロトコルを使用して、ブロック４０５で読み取られる。図５に示した実施例によると、第１の（外部の）パケット用ヘッダのプロトコルとしてプロトコル４についての第２のパケット用ヘッダ内のプロトコルフィールドに対するオフセットは９バイトである。このため、ブロック４１０において、第２のパケット用ヘッダは、第２のプロトコルを得るためにプロトコルのデータ構造２２０から取得した次ヘッダ内オフセットに基づいて処理される。次にこのパケットは、パケット変換動作及び／又はソース及び／又は宛先ポートのアドレスの抽出など、第１および／または第２のプロトコルに関連した１つ以上の動作に基づいて処理される。

ここで図６を参照すると、本発明のいくつかの実施形態による階層化ヘッダ付きのパケットを処理する具体例としての動作が説明される。動作はブロック６００で開始する。ここでは、第１の（外部の）パケット用ヘッダ（例えば、図３の第１のＩＰヘッダ３０５）に対するベースポインタが取得される。いくつかの実施形態では、パケットを別個のＩＰバージョンのような特定のプロトコルのバージョンに基づいて、別個に処理することが望ましい。このため、ブロック６０５において、パケットがＩＰバージョン６のパケットであるかどうかの決定がなされる。パケットがＩＰバージョン６のパケットである場合、動作はブロック６１０へと続く。このブロック６１０では、第１のパケット用ヘッダから第１のプロトコルを得るように、パケットは処理される。ＩＰＳｅｃとの関連で、「選択子」の組が処理するためにパケットから抽出される。これらの選択子は、「トランスポート」プロトコル及びＴＣＰ／ＵＤＰのソース及び／又は宛先ポートのアドレスを含む。このため、ブロック６１０では、ポインタは第１のパケット用ヘッダ内のソース及び宛先ポートのアドレスに対して設定される。最後に、第１のパケット用ヘッダの大きさ（例えば、図１のＩＨＬフィールド）に基づいて、ベースポインタは第１のパケット用ヘッダの端部を指すように設定される（すなわち、第１のパケット用ヘッダに続く情報の先頭）。パケットがＩＰバージョン６のパケットでない場合、ブロック６１０の動作は非ＩＰｖ６パケット用のブロック６１５で実行される。

ブロック６２０において、第１のプロトコルがプロトコルのデータ構造２２０（例えば、図５のテーブル）の中にあるかどうかの決定がなされる。本発明の各種の実施形態では、別個のプロトコルのデータ構造２２０は、異なったパケットのプロトコルのバージョン又は形式に対して定義される。例えば、異なったプロトコルのデータ構造２２０は、ＩＰバージョン６の環境及びＩＰバージョン４の環境に対して定義される。図５はＩＰバージョン４の環境に対する具体例としてのプロトコルのデータ構造２２０を示し、一方図７はＩＰバージョン６の環境に対する具体例としてのプロトコルのデータ構造２２０を示す。第１のプロトコルがプロトコルのデータ構造２２０内に存在しない場合は、プロトコル、ソースポートのアドレス、及び／又は宛先ポートのアドレスはブロック６３０で戻される。しかしながら、第１のプロトコルがプロトコルのデータ構造２２０に存在する場合は、動作はブロック６４０で継続する。このブロック６４０では、エネイブルフラグが第１のプロトコルに対してプロトコルのデータ構造２２０の中で設定されているかどうかの決定がなされる。都合がよいことに、エネイブルフラグはプロトコルの「基本」設定を非揮発性の記憶装置の中に記憶し、システムの初期化時に揮発性記憶装置にコピーできるようにする。この後、特定のプロトコルがエネイブルビットを使用することによってディセーブルにされる。エネイブルフラグが設定されていない場合は、カプセル化されたヘッダは処理されず、前述したように、動作はブロック６３０で終了する。

しかしながら、エネイブルフラグが設定されている場合（例えば、エネイブルフラグが図５のプロトコル５５，５１及び１０８に対して設定されている場合）、プロトコルのデータ構造２２０からのフラグフィールドがブロック６５０で調査されて、パケット処理動作のどの組を実行するかを決定する。図５に示すように、各プロトコルは異なったフラグ値に関連している。しかしながら、いくつかの実施形態では、これらのプロトコルに対してカプセル化されたヘッダが同じように処理されるように、プロトコルは共通のフラグ値を共有することができる。ブロック６６０では、プロトコルのデータ構造２２０からの次ヘッダ内オフセットに基づいて第２のプロトコルを得るために、第２の（内部の）パケット用ヘッダが処理される。実施例のように第１のプロトコルの値５１を用いると、図５は第２のパケット用ヘッダ内のプロトコルフィールドに対するオフセットがゼロバイトであると示す。さらに、プロトコルのデータ構造２２０を使用して、第２のパケット用ヘッダ内のペイロード／データフィールド及び／又は他のフィールドを処理することもできる。再度、実施例のように第１のプロトコルの値５１を用いると、図５はペイロードに対するオフセットが２４バイトであると示す。いくつかの実施形態では、プロトコルのデータ構造２２０内の対ペイロードオフセット用フィールドは、ソース及び／又は宛先ポートのアドレスを抽出することを容易にするオフセットを含むことができる。このため、ブロック６６０では、ポインタをソース及び／又は宛先ポートのアドレスに対して設定することができる。最後に、いくつかの実施形態では、１つ以上の別のカプセル化されたヘッダを有することができる場合は、ベースポインタは第２のパケット用ヘッダの端部を指すように設定される（すなわち、第２のパケット用ヘッダに続く情報の先頭）。

動作はブロック６２０において継続する。このブロック６２０では、プロトコルのデータ構造の中に別のカプセル化されたプロトコルが存在するかどうかの決定がなされる。プロトコルのデータ構造２２０内にある全てのカプセル化されたヘッダが処理されるまで、ループが繰り返される。図５に示されたプロトコルで、ＩＰのモビリティ（５５）、認証用ヘッダ（５１）、ＩＰ内のＩＰ（４）、及びＩＰペイロード用圧縮プロトコル（１０８）、図６に示されたプロトコルで、ホップオプションによるＩＰｖ６ホップ（０）、ＩＰｖ６用ルーティングヘッダ（４３）、ＩＰｖ６用宛先オプション（６０）、及び認証用ヘッダ（５１）は、単に例示的なものであり、本発明の様々な実施形態に基づいて他のプロトコルも使用できることは理解されよう。

図４及び図６のフローチャートは、パケット処理システム２００の幾つかの実施形態のアーキテクチャ、機能性、及び動作を示している。これに関連して、指定された論理機能を実行する１つ以上の実行可能な命令を含む各ブロックは、モジュール、セグメント、又はコードの部分を示す。他の実施形態では、ブロックの中で言及された機能が図４及び図６で示された順序から外れることがあることにも注意されたい。例えば、連続して示された２つのブロックが、事実上、ほぼ同時に実行される、又は必要とされる機能に応じて、逆の順序で実行されるブロックもある。

本発明の原理からほとんど逸脱することなく、多くの変形例及び修正例を好ましい実施形態に対して作ることができる。そのような変形例及び修正例の全ては、以下の特許請求の範囲の中に記載するような本発明の範囲の中に含まれるものとする。

従来のインターネットプロトコル（ＩＰ）によるパケット用ヘッダの構造を説明する図である。 本発明のいくつかの実施形態によるパケット処理システムを説明する図である。 本発明のいくつかの実施形態による階層化ヘッダが付いたパケットを説明する図である。 本発明のいくつかの実施形態による階層化ヘッダが付いたパケットを処理する具体例としての動作を説明するフローチャートである。 本発明のいくつかの実施形態によるＩＰバージョン４用プロトコルのデータ構造を説明する図である。 本発明のいくつかの実施形態による階層化ヘッダ付きのパケットを処理するさらに別の具体例としての動作を説明するフローチャートである。 本発明のいくつかの実施形態によるＩＰバージョン６のプロトコルのデータ構造を説明する図である。

Claims (30)

1. 第１のプロトコルフィールドを得るため、パケットの第１のヘッダを処理するステップと、
   前記第１のプロトコルフィールドをキーとして使用して、前記第１のプロトコルフィールドを前記パケットの第２のヘッダのオフセットと関連付けるレコードを、プロトコルデータ構造から読み取るステップであって、前記プロトコルデータ構造は、メモリ内に含まれ、様々な情報を関連付けるために使用されるものであり、前記レコードは、前記第１のプロトコルフィールドを、エネイブルフラグ及びパケットのペイロードに対するオフセットに関連付ける、ステップと、
   前記エネイブルフラグが設定されている場合、前記パケットのペイロードに対するオフセットに基づいて前記パケットのペイロードを処理するステップと、
   前記エネイブルフラグが設定されている場合、第２のプロトコルフィールドを得るため、前記第２のヘッダのオフセットに基づいて前記パケットの第２のヘッダを処理するステップと
   を含むパケットの処理方法。
2. 前記第２のプロトコルフィールドに関連した動作に基づいて前記パケットを処理するステップをさらに含む請求項１に記載の方法。
3. 前記第２のプロトコルフィールドに関連した動作がパケット変換動作を含む請求項２に記載の方法。
4. 前記レコードが前記第１のプロトコルフィールドを動作フラグと関連付け、前記動作フラグに関連した動作に基づいて前記パケットを処理するステップをさらに含む請求項１に記載の方法。
5. 前記レコードが第１のレコードであり、前記第２のプロトコルフィールドをキーとして使用して、前記第２のプロトコルフィールドを動作フラグと関連付ける第２のレコードを前記データ構造から読み取るステップと、前記動作フラグに関連した動作に基づいて前記パケットを処理するステップとをさらに含む請求項１に記載の方法。
6. 前記パケットが暗号パケットである請求項１に記載の方法。
7. 前記パケットが、パイプライン処理システムの中で前記パケットを処理する情報を有するパケットオブジェクトヘッダを含む請求項１に記載の方法。
8. 第１のプロトコルフィールドを得るため、パケットの第１のヘッダを処理する手段と、
   前記第１のプロトコルフィールドをキーとして使用して、前記第１のプロトコルフィールドを前記パケットの第２のヘッダのオフセットと関連付けるレコードを、プロトコルデータ構造から読み取る手段であって、前記プロトコルデータ構造は、メモリ内に含まれ、様々な情報を関連付けるために使用されるものであり、前記レコードは、前記第１のプロトコルフィールドを、エネイブルフラグ及びパケットのペイロードに対するオフセットに関連付ける、手段と、
   前記エネイブルフラグが設定されている場合、前記パケットのペイロードに対するオフセットに基づいて前記パケットのペイロードを処理するステップと、
   前記エネイブルフラグが設定されている場合、第２のプロトコルフィールドを得るため、前記第２のヘッダのオフセットに基づいて前記パケットの第２のヘッダを処理する手段と
   を備えるパケットの処理システム。
9. 前記第２のプロトコルフィールドに関連した動作に基づいて前記パケットを処理する手段をさらに含む請求項８に記載のシステム。
10. 前記第２のプロトコルフィールドに関連した動作がパケット変換動作を含む請求項９に記載のシステム。
11. 前記レコードが前記第１のプロトコルフィールドを動作フラグと関連付け、前記動作フラグに関連した動作に基づいて前記パケットを処理する手段をさらに含む請求項８に記載のシステム。
12. 前記レコードが第１のレコードであり、前記第２のプロトコルフィールドをキーとして使用して、前記第２のプロトコルフィールドを動作フラグと関連付ける第２のレコードを前記データ構造から読み取る手段と、前記動作フラグに関連した動作に基づいて前記パケットを処理する手段とをさらに含む請求項８に記載のシステム。
13. 前記パケットが暗号パケットである請求項８に記載のシステム。
14. 前記パケットがパイプライン処理システムの中で前記パケットを処理する情報を含むパケットオブジェクトヘッダを含む請求項８に記載のシステム。
15. コンピュータが読み取り可能なプログラムコードを記録する記録媒体であって、
    前記コンピュータが読取り可能なプログラムコードは、
    第１のプロトコルフィールドを得るため、パケットの第１のヘッダを処理するように構成されたコンピュータが読取り可能なプログラムコードと、
    前記第１のプロトコルフィールドをキーとして使用して、前記第１のプロトコルフィールドをパケットの第２のヘッダのオフセットと関連付けるレコードを、プロトコルデータ構造から読み取るように構成されたコンピュータが読取り可能なプログラムコードであって、前記プロトコルデータ構造は、メモリ内に含まれ、様々な情報を関連付けるために使用されるものであり、前記レコードは、前記第１のプロトコルフィールドを、エネイブルフラグ及びパケットのペイロードに対するオフセットに関連付ける、プログラムコードと、
    前記エネイブルフラグが設定されている場合、前記パケットのペイロードに対するオフセットに基づいて前記パケットのペイロードを処理するように構成されたコンピュータが読取り可能なプログラムコードと、
    前記エネイブルフラグが設定されている場合、第２のプロトコルフィールドを得るため、前記第２のヘッダのオフセットに基づいて前記パケットの第２のヘッダを処理するように構成されたコンピュータが読取り可能なプログラムコードと
    を含む、記録媒体。
16. 前記第２のプロトコルフィールドに関連した動作に基づいて前記パケットを処理するように構成されたコンピュータが読取り可能なプログラムコードをさらに含む請求項１５に記載の記録媒体。
17. 前記第２のプロトコルフィールドに関連した動作がパケット変換動作を含む請求項１６に記載の記録媒体。
18. 前記レコードが前記第１のプロトコルフィールドを動作フラグと関連付け、前記動作フラグに関連した動作に基づいて前記パケットを処理するように構成されたコンピュータが読取り可能なプログラムコードをさらに含む請求項１５に記載の記録媒体。
19. 前記レコードが第１のレコードであり、前記第２のプロトコルフィールドをキーとして使用して、前記第２のプロトコルフィールドを動作フラグと関連付ける第２のレコードを前記データ構造から読み取るように構成されたコンピュータが読取り可能なプログラムコードと、前記動作フラグに関連した動作に基づいて前記パケットを処理するように構成されたコンピュータが読取り可能なプログラムコードとをさらに含む請求項１５に記載の記録媒体。
20. 前記パケットが暗号パケットである請求項１５に記載の記録媒体。
21. 前記パケットがパイプライン処理システムの中で前記パケットを処理する情報を有するパケットオブジェクトヘッダを含む請求項１５に記載の記録媒体。
22. 第１のＩＰＳｅｃプロトコルフィールドを得るため、パケットの第１のヘッダを処理するステップと、
    前記第１のＩＰＳｅｃプロトコルフィールドをキーとして使用して、前記第１のＩＰＳｅｃプロトコルフィールドを、パケットの第２のヘッダのオフセット及びパケットのペイロードに対するオフセットと関連付けるレコードを、プロトコルデータ構造から読み取るステップであって、前記プロトコルデータ構造は、メモリ内に含まれ、様々な情報を関連付けるために使用されるものであり、前記レコードは、前記第１のプロトコールフィールドを、エネイブルフラグ及びパケットのペイロードに対するオフセットに関連付ける、ステップと、
    前記エネイブルフラグが設定されている場合、前記パケットのペイロードに対するオフセットに基づいて前記パケットのペイロードを処理するステップと、
    前記エネイブルフラグが設定されている場合、第２のＩＰＳｅｃプロトコルフィールドを得るため、前記第２のヘッダのオフセットに基づいて前記パケットの第２のヘッダを処理するステップと、
    少なくとも１つのソース及び宛先ポートのアドレスを得るため、前記パケットのペイロードに対するオフセットに基づいて前記パケットを処理するステップと
    を含む、インターネットプロトコルのセキュリティ（ＩＰＳｅｃ）のパケットを処理する方法。
23. 前記ＩＰＳｅｃパケットがＩＰバージョン４のパケットであり、前記第１のＩＰＳｅｃプロトコルフィールドがＩＰのモビリティ、認証用ヘッダ、ＩＰ内のＩＰ、及びＩＰペイロード用圧縮プロトコルの中の１つである請求項２２に記載の方法。
24. 前記ＩＰＳｅｃパケットがＩＰバージョン６のパケットであり、前記第１のＩＰＳｅｃプロトコルフィールドがホップオプションによるＩＰｖ６ホップ、ＩＰｖ６用ルーティングヘッダ、ＩＰｖ６用宛先オプション、及び認証用ヘッダの中の１つである請求項２２に記載の方法。
25. 第１のＩＰＳｅｃプロトコルフィールドを得るためにパケットの第１のヘッダを処理する手段と、
    前記第１のＩＰＳｅｃプロトコルフィールドをキーとして使用して、前記第１のＩＰＳｅｃプロトコルフィールドを、パケットの第２のヘッダのオフセット及びパケットのペイロードに対するオフセットと関連付けるレコードをプロトコルデータ構造から読み取る手段であって、前記プロトコルデータ構造は、メモリ内に含まれ、様々な情報を関連付けるために使用されるものであり、前記レコードは、前記第１のプロトコールフィールドを、エネルブルフラグ及びパケットのペイロードに対するオフセットに関連付ける、手段と、
    前記エネイブルフラッグが設定されている場合、前記パケットのペイロードに対するオフセットに基づいて前記パケットのペイロードを処理するステップと、
    前記エネイブルフラッグが設定されている場合、第２のＩＰＳｅｃプロトコルフィールドを得るために前記第２のヘッダのオフセットに基づいて前記パケットの第２のヘッダを処理する手段と、
    少なくとも１つのソース及び宛先ポートのアドレスを得るために前記パケットのペイロードに対するオフセットに基づいて前記パケットを処理する手段と
    を含む、インターネットプロトコルのセキュリティ（ＩＰＳｅｃ）のパケットを処理するシステム。
26. 前記ＩＰＳｅｃパケットがＩＰバージョン４のパケットであり、前記第１のＩＰＳｅｃプロトコルフィールドがＩＰのモビリティ、認証用ヘッダ、ＩＰ内のＩＰ、及びＩＰペイロード用圧縮プロトコルの中の１つである請求項２５に記載のシステム。
27. 前記ＩＰＳｅｃパケットがＩＰバージョン６のパケットであり、前記第１のＩＰＳｅｃプロトコルフィールドがホップオプションによるＩＰｖ６ホップ、ＩＰｖ６用ルーティングヘッダ、ＩＰｖ６用宛先オプション、及び認証用ヘッダの中の１つである請求項２５に記載のシステム。
28. コンピュータが読み取り可能なプログラムコードを記録する記録媒体であって、
    コンピュータが読取り可能なプログラムコードは、
    パケットの第１のヘッダを処理して、第１のＩＰＳｅｃプロトコルフィールドを得るように構成されたコンピュータが読取り可能なプログラムコードと、
    前記第１のＩＰＳｅｃプロトコルフィールドをキーとして使用して、前記第１のＩＰＳｅｃプロトコルフィールドをパケットの第２のヘッダのオフセット及びパケットのペイロードに対するオフセットと関連付けるレコードを、プロトコルデータ構造から読み取るように構成されたコンピュータが読取り可能なプログラムコードであって、前記プロトコルデータ構造は、メモリ内に含まれ、様々な情報を関連付けるために使用されるものであり、前記レコードは、前記第１のプロトコールフィールドを、エネイブルフラグ及びパケットのペイロードに対するオフセットに関連付ける、プログラムコードと、
    前記エネイブルフラッグが設定されている場合、前記パケットのペイロードに対するオフセットに基づいて前記パケットのペイロードを処理するステップと、
    前記エネイブルフラッグが設定されている場合、前記パケットの第２のヘッダを前記第２のヘッダのオフセットに基づいて処理して、第２のＩＰＳｅｃプロトコルフィールドを得るように構成されたコンピュータが読取り可能なプログラムコードと、
    前記パケットのペイロードに対するオフセットに基づいて前記パケットを処理して、少なくとも１つのソース及び宛先ポートのアドレスを得るように構成されたコンピュータが読取り可能なプログラムコードと
    を含む、記録媒体。
29. 前記ＩＰＳｅｃパケットがＩＰバージョン４のパケットであり、前記第１のＩＰＳｅｃプロトコルフィールドがＩＰのモビリティ、認証用ヘッダ、ＩＰ内のＩＰ、及びＩＰペイロード用圧縮プロトコルの中の１つである請求項２８に記載の記録媒体。
30. 前記ＩＰＳｅｃパケットがＩＰバージョン６のパケットであり、前記第１のＩＰＳｅｃプロトコルフィールドがホップオプションによるＩＰｖ６ホップ、ＩＰｖ６用ルーティングヘッダ、ＩＰｖ６用宛先オプション、及び認証用ヘッダの中の１つである請求項２９に記載の記録媒体。

Images