(57)【要約】パケットの第１のヘッダが、第１のプロトコルを得るために処理される。この第１のプロトコルをキーとして使用して、データ構造からレコードを読み取る。このデータ構造では、第１のプロトコルがパケットの第２のヘッダ内のオフセットに関連付けられている。パケットの第２のヘッダは第２のヘッダ内のオフセットに基づいて処理されて、第２のプロトコルを得る。パケットの第２のヘッダ内のプロトコルフィールドの位置を、データ構造内に記憶されたオフセットと位置的に関連付けることによって、寸法及び／又はレイアウトが変わる場合、データ構造内のオフセット情報は、パケットプロセッサ内のハードウェア及び／又はソフトウェアを再設計及び／又は再構成する必要なく更新することができる。
2005522948.tif 000002
【特許請求の範囲】
【請求項１】
パケットの第１のヘッダを処理して第１のプロトコルを得るステップと、
前記第１のプロトコルをキーとして使用して、前記第１のプロトコルをそのパケットの第２のヘッダ内のオフセットと関連付けるレコードをデータ構造から読み取るステップと、
前記パケットの第２のヘッダを、前記第２のヘッダ内のオフセットに基づいて処理して、第２のプロトコルを得るステップと
を含むパケットの処理方法。
【請求項２】
前記レコードが前記第１のプロトコルをエネイブルフラグと関連付け、かつ前記パケットの第２のヘッダを処理することが、
前記エネイブルフラグが設定されている場合は、前記第２のプロトコルを得るために前記第２のヘッダ内のオフセットに基づいて、前記パケットの第２のヘッダを処理することを含む請求項１に記載の方法。
【請求項３】
前記レコードが前記第１のプロトコルをパケットのペイロードに対するオフセットに関連付けるものであり、
前記エネイブルフラグが設定されている場合は、前記ペイロードに対するオフセットに基づいて前記パケットのペイロードを処理するステップをさらに含む請求項２に記載の方法。
【請求項４】
前記第２のプロトコルに関連した動作に基づいて前記パケットを処理するステップをさらに含む請求項１に記載の方法。
【請求項５】
前記第２のプロトコルに関連した動作がパケット変換動作を含む請求項４に記載の方法。
【請求項６】
前記レコードが前記第１のプロトコルを動作フラグと関連付け、前記方法が、
前記動作フラグに関連した動作に基づいて前記パケットを処理するステップをさらに含む請求項１に記載の方法。
【請求項７】
前記レコードが第１のレコードであって、
前記第２のプロトコルをキーとして使用して、前記第２のプロトコルを動作フラグと関連付ける第２のレコードを前記データ構造から読み取るステップと、
前記動作フラグに関連した動作に基づいて前記パケットを処理するステップと
をさらに含む請求項１に記載の方法。
【請求項８】
前記パケットが暗号パケットである請求項１に記載の方法。
【請求項９】
前記パケットが、パイプライン処理システムの中で前記パケットを処理する情報を含むパケットオブジェクトヘッダを含む請求項１に記載の方法。
【請求項１０】
データ構造の中のパケット用ヘッダを関連付ける方法であって、
パケットの第１のヘッダからのプロトコルをパケットの第２のヘッダ内のオフセットに関連付けるステップを含む方法。
【請求項１１】
前記パケットの第１のヘッダからのプロトコルを前記パケットのペイロードに対するオフセットに関連付けるステップをさらに含む請求項１０に記載の方法。
【請求項１２】
前記パケットの第２のヘッダが内部ヘッダであり、前記パケットの第１のヘッダが前記内部ヘッダをカプセル化する外部ヘッダである請求項１１に記載の方法。
【請求項１３】
前記プロトコルを前記パケット上で実行される動作を規定する動作フラグと関連付けるステップをさらに含む請求項１０に記載の方法。
【請求項１４】
前記プロトコルは第１のプロトコルであって、
前記パケットの第２のヘッダからの第２のプロトコルをパケット上で実行される動作を規定する動作フラグと関連させるステップをさらに含む請求項１０に記載の方法。
【請求項１５】
前記プロトコルは第１のプロトコルであり、前記方法が、
前記第１のプロトコルを前記パケットの第２のヘッダからの第２のプロトコルを決定するかどうかを規定するエネイブルフラグと関連付けるステップをさらに含む請求項１０に記載の方法。
【請求項１６】
第１のプロトコルを得るために、パケットの第１のヘッダを処理する手段と、
前記第１のプロトコルをキーとして使用して、前記第１のプロトコルをパケットの第２のヘッダ内のオフセットと関連付けるレコードをデータ構造から読み取る手段と、
前記パケットの第２のヘッダを第２のプロトコルを得るために前記第２のヘッダ内のオフセットに基づいて処理する手段と
を備えるパケットの処理システム。
【請求項１７】
前記レコードが前記第１のプロトコルをエネイブルフラグと関連付け、かつ前記パケットの第２のヘッダを処理する手段が、
前記エネイブルフラグが設定されている場合は、前記第２のプロトコルを得るために前記第２のヘッダ内のオフセットに基づいて、前記パケットの第２のヘッダを処理する手段を備える請求項１６に記載のシステム。
【請求項１８】
前記レコードが前記第１のプロトコルをパケットのペイロードに対するオフセットに関連付け、
前記エネイブルフラグが設定されている場合は、前記ペイロードに対するオフセットに基づいて前記パケットのペイロードを処理する手段をさらに含む請求項１７に記載のシステム。
【請求項１９】
前記第２のプロトコルに関連した動作に基づいて前記パケットを処理する手段をさらに含む請求項１６に記載のシステム。
【請求項２０】
前記第２のプロトコルに関連した動作がパケット変換動作を含む請求項１９に記載のシステム。
【請求項２１】
前記レコードが前記第１のプロトコルを動作フラグと関連付けており、
前記動作フラグに関連した動作に基づいて前記パケットを処理する手段をさらに含む請求項１６に記載のシステム。
【請求項２２】
前記レコードが第１のレコードであって、
前記第２のプロトコルをキーとして使用して、前記第２のプロトコルを動作フラグと関連付ける第２のレコードを前記データ構造から読み取る手段と、
前記動作フラグに関連した動作に基づいて前記パケットを処理する手段と
をさらに含む請求項１６に記載のシステム。
【請求項２３】
前記パケットが暗号パケットである、請求項１６に記載のシステム。
【請求項２４】
前記パケットがパイプライン処理システムの中で前記パケットを処理する情報を含むパケットオブジェクトヘッダを含む請求項１６に記載のシステム。
【請求項２５】
前記コンピュータが読取り可能なプログラムコードが、
第１のプロトコルを得るために、パケットの第１のヘッダを処理するように構成されたコンピュータが読取り可能なプログラムコードと、
前記第１のプロトコルをキーとして使用して、前記第１のプロトコルをパケットの第２のヘッダ内のオフセットと関連付けるレコードをデータ構造から読み取るように構成されたコンピュータが読取り可能なプログラムコードと、
前記パケットの第２のヘッダを第２のプロトコルを得るために前記第２のヘッダ内のオフセットに基づいて処理するように構成されたコンピュータが読取り可能なプログラムコードと
を含む、媒体の中に組み込まれたコンピュータが読取り可能なプログラムコードを有するコンピュータが読取り可能なプログラム媒体を含むパケットを処理するためのコンピュータプログラム製品。
【請求項２６】
前記レコードが前記第１のプロトコルをエネイブルフラグと関連付け、かつ前記パケットの第２のヘッダを処理するように構成された前記コンピュータが読取り可能なプログラムコードが、
前記エネイブルフラグが設定されている場合は、前記第２のプロトコルを得るために前記第２のヘッダ内のオフセットに基づいて、前記パケットの第２のヘッダを処理するように構成されたコンピュータが読取り可能なプログラムコードを含む請求項２５に記載のコンピュータプログラム製品。
【請求項２７】
前記レコードが前記第１のプロトコルをパケットのペイロードに対するオフセットに関連付けるものであって、
前記エネイブルフラグが設定されている場合は、前記ペイロードに対するオフセットに基づいて前記パケットのペイロードを処理するように構成されたコンピュータが読取り可能なプログラムコードを含む請求項２６に記載のコンピュータプログラム製品。
【請求項２８】
前記第２のプロトコルに関連した動作に基づいて前記パケットを処理するように構成されたコンピュータが読取り可能なプログラムコードをさらに含む請求項２５に記載のコンピュータプログラム製品。
【請求項２９】
前記第２のプロトコルに関連した動作がパケット変換動作を含む請求項２８に記載のコンピュータプログラム製品。
【請求項３０】
前記レコードが前記第１のプロトコルを動作フラグと関連付け、前記コンピュータプログラム製品が、
前記動作フラグに関連した動作に基づいて前記パケットを処理するように構成されたコンピュータが読取り可能なプログラムコードをさらに含む請求項２５に記載のコンピュータプログラム製品。
【請求項３１】
前記レコードが第１のレコードであり、前記コンピュータプログラム製品が、
前記第２のプロトコルをキーとして使用して、前記第２のプロトコルを動作フラグと関連付ける第２のレコードを前記データ構造から読み取るように構成されたコンピュータが読取り可能なプログラムコードと、
前記動作フラグに関連した動作に基づいて前記パケットを処理するように構成されたコンピュータが読取り可能なプログラムコードと
をさらに含む請求項２５に記載のコンピュータプログラム製品。
【請求項３２】
前記パケットが暗号パケットである、請求項２５に記載のコンピュータプログラム製品。
【請求項３３】
前記パケットがパイプライン処理システムの中で前記パケットを処理する情報を含むパケットオブジェクトヘッダを含む請求項２５に記載のコンピュータプログラム製品。
【請求項３４】
前記コンピュータが読取り可能なデータ構造が、
パケットの第１のヘッダからのプロトコルをパケットの第２のヘッダ内のオフセットに関連付けるテーブルを含む、媒体の中に組み込まれたコンピュータが読取り可能なデータ構造を有するコンピュータが読取り可能なプログラム媒体を含むコンピュータプログラム製品。
【請求項３５】
前記テーブルが前記パケットの第１のヘッダからのプロトコルを前記パケットのペイロードに対するオフセットにさらに関連付ける請求項３４に記載のコンピュータプログラム製品。
【請求項３６】
前記パケットの第２のヘッダが内部ヘッダであり、前記パケットの第１のヘッダが前記内部ヘッダをカプセル化する外部ヘッダである請求項３５に記載のコンピュータプログラム製品。
【請求項３７】
前記テーブルが前記プロトコルを前記パケット上で実行される動作を規定する動作フラグとさらに関連付ける請求項３４に記載のコンピュータプログラム製品。
【請求項３８】
前記プロトコルは第１のプロトコルであり、前記テーブルが、前記パケットの第２のヘッダからの第２のプロトコルをパケット上で実行される動作を規定する動作フラグとさらに関連付ける請求項３４に記載のコンピュータプログラム製品。
【請求項３９】
前記プロトコルは第１のプロトコルであり、前記テーブルが、前記第１のプロトコルを前記パケットの第２のヘッダからの第２のプロトコルを決定するかどうかを規定するエネイブルフラグとさらに関連付ける請求項３４に記載のコンピュータプログラム製品。
【請求項４０】
インターネットプロトコルのセキュリティ（ＩＰＳｅｃ）のパケットを処理する方法であって、
パケットの第１のヘッダを処理して、第１のＩＰＳｅｃプロトコルを得るステップと、
前記第１のプロトコルをキーとして使用して、前記第１のＩＰＳｅｃプロトコルをパケットの第２のヘッダ内のオフセット及びパケットのペイロードに対するオフセットと関連付けるレコードをデータ構造から読み取るステップと、
前記パケットの第２のヘッダを前記第２のヘッダ内のオフセットに基づいて処理して、第２のＩＰＳｅｃプロトコルを得るステップと、
前記パケットのペイロードに対するオフセットに基づいて前記パケットを処理して、少なくとも１つのソース及び宛先ポートのアドレスを得るステップと
を含む方法。
【請求項４１】
前記ＩＰＳｅｃパケットがＩＰバージョン４のパケットであり、前記第１のＩＰＳｅｃプロトコルがＩＰのモビリティ、認証用ヘッダ、ＩＰ内のＩＰ、及びＩＰペイロード用圧縮プロトコルの中の１つである請求項４０に記載の方法。
【請求項４２】
前記ＩＰＳｅｃパケットがＩＰバージョン６のパケットであり、前記第１のＩＰＳｅｃプロトコルがホップオプションによるＩＰｖ６ホップ、ＩＰｖ６用ルーティングヘッダ、ＩＰｖ６用宛先オプション、及び認証用ヘッダの中の１つである請求項４０に記載の方法。
【請求項４３】
インターネットプロトコルのセキュリティ（ＩＰＳｅｃ）のパケットを処理するシステムであって、
第１のＩＰＳｅｃプロトコルを得るためにパケットの第１のヘッダを処理する手段と、
前記第１のプロトコルをキーとして使用して、前記第１のＩＰＳｅｃプロトコルをパケットの第２のヘッダ内のオフセット及びパケットのペイロードに対するオフセットと関連付けるレコードをデータ構造から読み取る手段と、
前記パケットの第２のヘッダを第２のＩＰＳｅｃプロトコルを得るために前記第２のヘッダ内のオフセットに基づいて処理する手段と、
少なくとも１つのソース及び宛先ポートのアドレスを得るために、前記パケットのペイロードに対するオフセットに基づいて前記パケットを処理する手段と
を含むシステム。
【請求項４４】
前記ＩＰＳｅｃパケットがＩＰバージョン４のパケットであり、前記第１のＩＰＳｅｃプロトコルがＩＰのモビリティ、認証用ヘッダ、ＩＰ内のＩＰ、及びＩＰペイロード用圧縮プロトコルの中の１つである請求項４３に記載のシステム。
【請求項４５】
前記ＩＰＳｅｃパケットがＩＰバージョン６のパケットであり、前記第１のＩＰＳｅｃプロトコルがホップオプションによるＩＰｖ６ホップ、ＩＰｖ６用ルーティングヘッダ、ＩＰｖ６用宛先オプション、及び認証用ヘッダの中の１つである請求項４３に記載のシステム。
【請求項４６】
前記コンピュータが読取り可能なプログラムコードが、
パケットの第１のヘッダを処理して、第１のＩＰＳｅｃプロトコルを得るように構成されたコンピュータが読取り可能なプログラムコードと、
前記第１のプロトコルをキーとして使用して、前記第１のＩＰＳｅｃプロトコルをパケットの第２のヘッダ内のオフセット及びパケットのペイロードに対するオフセットと関連付けるレコードをデータ構造から読み取るように構成されたコンピュータが読取り可能なプログラムコードと、
前記パケットの第２のヘッダを前記第２のヘッダ内のオフセットに基づいて処理して、第２のＩＰＳｅｃプロトコルを得るように構成されたコンピュータが読取り可能なプログラムコードと、
前記パケットのペイロードに対するオフセットに基づいて前記パケットを処理して、少なくとも１つのソース及び宛先ポートのアドレスを得るように構成されたコンピュータが読取り可能なプログラムコードと
を含む、媒体の中に組み込まれたコンピュータが読取り可能なプログラムコードを有するコンピュータが読取り可能なプログラム媒体を含むコンピュータプログラム製品。
【請求項４７】
前記ＩＰＳｅｃパケットがＩＰバージョン４のパケットであり、前記第１のＩＰＳｅｃプロトコルがＩＰのモビリティ、認証用ヘッダ、ＩＰ内のＩＰ、及びＩＰペイロード用圧縮プロトコルの中の１つである請求項４７に記載のコンピュータプログラム製品。
【請求項４８】
前記ＩＰＳｅｃパケットがＩＰバージョン６のパケットであり、前記第１のＩＰＳｅｃプロトコルがホップオプションによるＩＰｖ６ホップ、ＩＰｖ６用ルーティングヘッダ、ＩＰｖ６用宛先オプション、及び認証用ヘッダの中の１つである請求項４７に記載のコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はパケットを処理する方法、そのためのシステム及びコンピュータプログラム製品に関し、より具体的には、階層化ヘッダが付いたパケットの処理方法、システム及びコンピュータプログラム製品に関する。
【背景技術】
【０００２】
インターネットプロトコル（ＩＰ）は、解放形システム相互接続（ＯＳＩ）モデルの第３層（ネットワーク層）の中に存在する。ＩＰは、ネットワーク内のノード間の接続すなわちデータグラムサービスを提供する。ＩＰホストはＩＰヘッダ付きのデータをカプセル化し、このデータは次にデータリンク層に送られる。データリンクプロトコルはＩＰヘッダ及びデータをそれ自身のヘッダを用いてカプセル化し、次にカプセル化されたパケットを物理層に送る。物理層でこのパケットはさらに別のヘッダを用いてカプセル化され、シリアルのビットストリームとしてネットワークに送信される。
【０００３】
ＩＰバージョン４用のＩＰヘッダ内で使用されるフィールドを図１に示す。第１のフィールドは、ヘッダを作るために使用されるＩＰのバージョンである。古いＩＰバージョンで動作するネットワークは、新しいＩＰバージョンに関連したヘッダによりカプセル化されたパケットを処理することはできない。インターネットヘッダ長（ＩＨＬ）フィールドがバージョンフィールドに続き、ＩＰヘッダの長さを３２ビットワードに規定する。サービス形式フィールド（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）に関連したパケットを拒絶するが、イーメールのトラフィックに関連したパケットは受け入れる。このため、階層化ヘッダ付きのパケットを構文解析して、パケットに関連した下側のプロトコルを評価することが望ましい。
【００２８】
本発明のいくつかの実施形態では、第１のプロトコルをブロック４０５においてプロトコルのデータ構造２２０からレコードを読み取るキーとして使用し、第２のパケット用ヘッダ（例えば、図３の第２のＩＰヘッダ３１０）に対するオフセットを得る。これは例えば図５に示されている。この図５では、本発明のいくつかの実施形態による、プロトコルのデータ構造２２０として使用される具体例としてのデータ構造５００が示されている。図５に示すように、データ構造５００は、各レコードがプロトコルフィールド、エネイブルフィールド、及び次ヘッダ内オフセット用フィールド、対ペイロードオフセット用フィールド、及びフラグフィールドから成るレコードのテーブルから構成する。このプロトコルフィールドは、パケット用ヘッダ内のプロトコルフィールドに該当する。エネイブルフィールドは、カプセル化されたヘッダ／プロトコルに対してパケットを構文解析するかどうかを示す２進の「肯定」又は「否定」フィールドとして実現される。次ヘッダ内オフセット用フィールドは、カプセル化されたヘッダ内のプロトコルフィールドの位置を示す。対ペイロードオフセット用フィールドは、パケットのペイロード／データ部分（例えば、図３のＩＰペイロード／データ）の位置を示す。フラグフィールドは、特定のプロトコルに対してパケット上で実行される動作を示す。例えば、そのような動作には、ソース及び／又は宛先ポートのアドレスを引き出すパケット処理動作が含まれる。プロトコルのデータ構造２２０はこれらのフィールドに限定されることはなく、本発明の各種の実施形態に基づいて、別のフィールドを含んだり、図５に示した１つ以上のフィールドを取り除くことができる。さらに、テーブルを図５に示したが、他の種類のデータ構造も本発明の原理から逸脱することなく使用できる。
【００２９】
図４の説明に戻ると、プロトコルのデータ構造からのレコードが第２の（内部の）パケット用ヘッダ内のオフセットを得るためのキーとして第１のプロトコルを使用して、ブロック４０５で読み取られる。図５に示した実施例によると、第１の（外部の）パケット用ヘッダのプロトコルとしてプロトコル４についての第２のパケット用ヘッダ内のプロトコルフィールドに対するオフセットは９バイトである。このため、ブロック４１０において、第２のパケット用ヘッダは、第２のプロトコルを得るためにプロトコルのデータ構造２２０から取得した次ヘッダ内オフセットに基づいて処理される。次にこのパケットは、パケット変換動作及び／又はソース及び／又は宛先ポートのアドレスの抽出など、第１および／または第２のプロトコルに関連した１つ以上の動作に基づいて処理される。
【００３０】
ここで図６を参照すると、本発明のいくつかの実施形態による階層化ヘッダ付きのパケットを処理する具体例としての動作が説明される。動作はブロック６００で開始する。ここでは、第１の（外部の）パケット用ヘッダ（例えば、図３の第１のＩＰヘッダ３０５）に対するベースポインタが取得される。いくつかの実施形態では、パケットを別個のＩＰバージョンのような特定のプロトコルのバージョンに基づいて、別個に処理することが望ましい。このため、ブロック６０５において、パケットがＩＰバージョン６のパケットであるかどうかの決定がなされる。パケットがＩＰバージョン６のパケットである場合、動作はブロック６１０へと続く。このブロック６１０では、第１のパケット用ヘッダから第１のプロトコルを得るように、パケットは処理される。ＩＰＳｅｃとの関連で、「選択子」の組が処理するためにパケットから抽出される。これらの選択子は、「トランスポート」プロトコル及びＴＣＰ／ＵＤＰのソース及び／又は宛先ポートのアドレスを含む。このため、ブロック６１０では、ポインタは第１のパケット用ヘッダ内のソース及び宛先ポートのアドレスに対して設定される。最後に、第１のパケット用ヘッダの大きさ（例えば、図１のＩＨＬフィールド）に基づいて、ベースポインタは第１のパケット用ヘッダの端部を指すように設定される（すなわち、第１のパケット用ヘッダに続く情報の先頭）。パケットがＩＰバージョン６のパケットでない場合、ブロック６１０の動作は非ＩＰｖ６パケット用のブロック６１５で実行される。
【００３１】
ブロック６２０において、第１のプロトコルがプロトコルのデータ構造２２０（例えば、図５のテーブル）の中にあるかどうかの決定がなされる。本発明の各種の実施形態では、別個のプロトコルのデータ構造２２０は、異なったパケットのプロトコルのバージョン又は形式に対して定義される。例えば、異なったプロトコルのデータ構造２２０は、ＩＰバージョン６の環境及びＩＰバージョン４の環境に対して定義される。図５はＩＰバージョン４の環境に対する具体例としてのプロトコルのデータ構造２２０を示し、一方図７はＩＰバージョン６の環境に対する具体例としてのプロトコルのデータ構造２２０を示す。第１のプロトコルがプロトコルのデータ構造２２０内に存在しない場合は、プロトコル、ソースポートのアドレス、及び／又は宛先ポートのアドレスはブロック６３０で戻される。しかしながら、第１のプロトコルがプロトコルのデータ構造２２０に存在する場合は、動作はブロック６４０で継続する。このブロック６４０では、エネイブルフラグが第１のプロトコルに対してプロトコルのデータ構造２２０の中で設定されているかどうかの決定がなされる。都合がよいことに、エネイブルフラグはプロトコルの「基本」設定を非揮発性の記憶装置の中に記憶し、システムの初期化時に揮発性記憶装置にコピーできるようにする。この後、特定のプロトコルがエネイブルビットを使用することによってディセーブルにされる。エネイブルフラグが設定されていない場合は、カプセル化されたヘッダは処理されず、前述したように、動作はブロック６３０で終了する。
【００３２】
しかしながら、エネイブルフラグが設定されている場合（例えば、エネイブルフラグが図５のプロトコル５５，５１及び１０８に対して設定されている場合）、プロトコルのデータ構造２２０からのフラグフィールドがブロック６５０で調査されて、パケット処理動作のどの組を実行するかを決定する。図５に示すように、各プロトコルは異なったフラグ値に関連している。しかしながら、いくつかの実施形態では、これらのプロトコルに対してカプセル化されたヘッダが同じように処理されるように、プロトコルは共通のフラグ値を共有することができる。ブロック６６０では、プロトコルのデータ構造２２０からの次ヘッダ内オフセットに基づいて第２のプロトコルを得るために、第２の（内部の）パケット用ヘッダが処理される。実施例のように第１のプロトコルの値５１を用いると、図５は第２のパケット用ヘッダ内のプロトコルフィールドに対するオフセットがゼロバイトであると示す。さらに、プロトコルのデータ構造２２０を使用して、第２のパケット用ヘッダ内のペイロード／データフィールド及び／又は他のフィールドを処理することもできる。再度、実施例のように第１のプロトコルの値５１を用いると、図５はペイロードに対するオフセットが２４バイトであると示す。いくつかの実施形態では、プロトコルのデータ構造２２０内の対ペイロードオフセット用フィールドは、ソース及び／又は宛先ポートのアドレスを抽出することを容易にするオフセットを含むことができる。このため、ブロック６６０では、ポインタをソース及び／又は宛先ポートのアドレスに対して設定することができる。最後に、いくつかの実施形態では、１つ以上の別のカプセル化されたヘッダを有することができる場合は、ベースポインタは第２のパケット用ヘッダの端部を指すように設定される（すなわち、第２のパケット用ヘッダに続く情報の先頭）。
【００３３】
動作はブロック６２０において継続する。このブロック６２０では、プロトコルのデータ構造の中に別のカプセル化されたプロトコルが存在するかどうかの決定がなされる。プロトコルのデータ構造２２０内にある全てのカプセル化されたヘッダが処理されるまで、ループが繰り返される。図５に示されたプロトコルで、ＩＰのモビリティ（５５）、認証用ヘッダ（５１）、ＩＰ内のＩＰ（４）、及びＩＰペイロード用圧縮プロトコル（１０８）、図６に示されたプロトコルで、ホップオプションによるＩＰｖ６ホップ（０）、ＩＰｖ６用ルーティングヘッダ（４３）、ＩＰｖ６用宛先オプション（６０）、及び認証用ヘッダ（５１）は、単に例示的なものであり、本発明の様々な実施形態に基づいて他のプロトコルも使用できることは理解されよう。
【００３４】
図４及び図６のフローチャートは、パケット処理システム２００の幾つかの実施形態のアーキテクチャ、機能性、及び動作を示している。これに関連して、指定された論理機能を実行する１つ以上の実行可能な命令を含む各ブロックは、モジュール、セグメント、又はコードの部分を示す。他の実施形態では、ブロックの中で言及された機能が図４及び図６で示された順序から外れることがあることにも注意されたい。例えば、連続して示された２つのブロックが、事実上、ほぼ同時に実行される、又は必要とされる機能に応じて、逆の順序で実行されるブロックもある。
【００３５】
本発明の原理からほとんど逸脱することなく、多くの変形例及び修正例を好ましい実施形態に対して作ることができる。そのような変形例及び修正例の全ては、以下の特許請求の範囲の中に記載するような本発明の範囲の中に含まれるものとする。
【図面の簡単な説明】
【００３６】
【図１】従来のインターネットプロトコル（ＩＰ）によるパケット用ヘッダの構造を説明する図である。
【図２】本発明のいくつかの実施形態によるパケット処理システムを説明する図である。
【図３】本発明のいくつかの実施形態による階層化ヘッダが付いたパケットを説明する図である。
【図４】本発明のいくつかの実施形態による階層化ヘッダが付いたパケットを処理する具体例としての動作を説明するフローチャートである。
【図５】本発明のいくつかの実施形態によるＩＰバージョン４用プロトコルのデータ構造を説明する図である。
【図６】本発明のいくつかの実施形態による階層化ヘッダ付きのパケットを処理するさらに別の具体例としての動作を説明するフローチャートである。
【図７】本発明のいくつかの実施形態によるＩＰバージョン６のプロトコルのデータ構造を説明する図である。
【図１】
2005522948.tif 000003
【図２】
2005522948.tif 000004
【図３】
2005522948.tif 000005
【図４】
2005522948.tif 000006
【図５】
2005522948.tif 000007
【図６】
2005522948.tif 000008
【図７】
2005522948.tif 000009
【国際調査報告】
2005522948.tif 000010
2005522948.tif 000011
2005522948.tif 000012