(57)【要約】【課題】パケットフローの上位層ヘッダにアクセスする方法を提供すること。【解決手段】ＩＰｖ６は、ＩＰｖ４の進化的前進として開発された。ＩＰｖ６は、アドレッシングやルーティングなど、特定の領域で大きな改善をもたらすが、インターネットヘッダ長フィールドを排除している。その結果、拡張ヘッダが追加された上位層ヘッダ情報を得るためにパケットを処理することが、処理速度の低速化の結果となる場合がある。本発明は、拡張ヘッダとしても知られるヘッダオプションフィールドの長さに関する情報をキャッシュすることによって、この問題に対処する。ＩＰｖ６パケットのフローが受け取られたときに、パケットヘッダが拡張ヘッダを含む場合、キャッシュされた情報のレビューは、処理ステップを回避することができ、したがってパケット処理を加速させることができる。【選択図】      図２
2005130502.tif 000002
【特許請求の範囲】
【請求項１】
ａ）拡張ヘッダを含むパケットヘッダに応答して、キャッシュキーを作成し、キャッシュエントリについてキャッシュ参照を実行するステップと、
ｂ）上位層ヘッダに到達し、その上位層ヘッダ内のフィールドを読み取るために、対応するキャッシュエントリの発見に応答して、キャッシュエントリを使用して拡張ヘッダを並列に読み取るステップとを含む、パケットフローの上位層ヘッダにアクセスする方法。
【請求項２】
パケットフローがＩＰｖ６パケットを含む請求項１に記載の方法。
【請求項３】
キャッシュ参照が、ＩＰｖ６ヘッダ内に存在するフィールドに基づいて構成するタプルを使用して、拡張ヘッダの長さを含むテーブルで実行される請求項２に記載の方法。
【請求項４】
パケット処理時間をさらに短縮するために、キャッシュ参照が実行されている間に拡張ヘッダのグループ内の第１拡張ヘッダを読み取るステップを含む請求項３に記載の方法。
【請求項５】
キャッシュエントリが発見されない場合、拡張ヘッダの直列読取りを実行し、同一フローの後続パケットを処理するためにこれらの拡張ヘッダの長さに関する情報をキャッシュする請求項１に記載の方法。
【請求項６】
ホップバイホップおよびルーティング拡張ヘッダを備えたパケットを検出し、これらのパケットのオプション処理が必要かどうか決定するステップを含む請求項１に記載の方法。
【請求項７】
拡張ヘッダを含まないパケットに応答して、キャッシュ参照を実行せずに上位層ヘッダを読み取る請求項６に記載の方法。
【請求項８】
拡張ヘッダが常に変化していて、誤りのあるキャッシュされたデータとなる場合には、拡張ヘッダが直列にトラバースされる請求項１に記載の方法。
【請求項９】
常に変化している拡張ヘッダが、手動設定を使用して検出される請求項８に記載の方法。
【請求項１０】
常に変化している拡張ヘッダが、パケットフローの監視に基づいて動的に決定される請求項８に記載の方法。
【請求項１１】
キャッシュされたデータがパケットに一致しない場合には、キャッシュエントリが更新されない請求項１に記載の方法。
【請求項１２】
キャッシュがパケットに一致しないことの検出が、手動でイネーブルにされる請求項１１に記載の方法。
【請求項１３】
キャッシュがパケットに一致しないことの検出が、フロー監視に基づいてイネーブルにされる請求項１１に記載の方法。
【請求項１４】
上位層ヘッダからの情報がキャッシュされる請求項１に記載の方法。
【請求項１５】
キャッシュされる情報が、プロトコルならびに送信元および宛先ポート識別を含む請求項１４に記載の方法。
【請求項１６】
通常のパケット処理の間に実行される分類および参照の結果がキャッシュされる請求項１に記載の方法。
【請求項１７】
拡張ヘッダを含むパケットヘッダに応答して、キャッシュキーを作成し、キャッシュエントリについてキャッシュ参照を実行する手段と、
上位層ヘッダに到達し、その上位層ヘッダ内のフィールドを読み取るために、対応するキャッシュエントリの発見に応答して、キャッシュエントリを使用して拡張ヘッダを並列に読み取る手段とを含む、パケットフローの上位層ヘッダにアクセスするシステム。
【請求項１８】
パケットフローがＩＰｖ６パケットを含む請求項１７に記載のシステム。
【請求項１９】
キャッシュ参照を実行する手段が、第１拡張ヘッダを読み取る際に使用するためにヘッダからの情報を並列に検査する請求項１８に記載のシステム。
【請求項２０】
キャッシュエントリが発見されない場合、拡張ヘッダを読み取る手段がヘッダを直列にトラバースする請求項１９に記載のシステム。
【請求項２１】
特定の状況で、パケット処理の加速を試行するのにキャッシュされたデータを使用すべきでないことを指定する手段を含む請求項１７に記載のシステム。
【請求項２２】
上位層ヘッダ情報をキャッシュする手段をさらに含む請求項１７に記載のシステム。
【請求項２３】
上位層ヘッダ情報が、プロトコル及び送信元及び宛先ポートを含む請求項２２に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムに関し、特に、キャッシュを使用してパケットフローの上位層ヘッダに迅速にアクセスするパケット処理スキームに関する。
【背景技術】
【０００２】
以下の議論では、特にインターネットプロトコルバージョン６（ＩＰｖ６：Ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ６）およびマルチフィールド分類（ＭＦＣ：ｍｕｌｔｉ−ｆｉｅｌｄ  ｃｌａｓｓｉｆｉｃａｔｉｏｎ）に言及する。しかし、本発明の概念がＩＰｖ６およびＭＦＣだけに制限されず、記載されるインプリメンテーションが単に例示を目的としたものにすぎないことを理解すべきである。
【０００３】
ＩＰｖ６は、ＩＰｖ４のいくつかの制限を克服するための進化的発展を表す。特に、ＩＰｖ４のルーティングおよびアドレッシングの制限が、３２ビットのフィールド制限に基づいて利用可能なアドレス構成を現実的に制限している。ＩＰｖ６は、アドレスフィールドを１２８ビットに増加させた。これは、より多くのレベルのアドレッシング階層、ならびに非常に多数のアドレス可能ノードをサポートする。さらに、パケットハンドリングの処理コストを削減し、ＩＰｖ６ヘッダの帯域幅コストを制限するために、いくつかのＩＰｖ４ヘッダフィールドが廃止された。ＩＰｖ６には、送信側がサービス品質またはリアルタイムハンドリングに基づいて特別なハンドリングを要求する特定のトラフィックフローに属するパケットのラベリングを可能にする、新しい機能が追加された。さらに、パケットにオプションのインターネット層情報を追加するメカニズムが変更された。ＩＰｖ４では、これは、ＩＰｖ４ヘッダの一部であるオプションフィールドを通じて達成される。ＩＰｖ４ヘッダ内のインターネットヘッダ長（ＩＨＬ）フィールドは、これら追加のフィールドと基本ヘッダとの長さを示す。しかし、ＩＨＬフィールドの長さの理由から、パケットには限られた数のオプションのみ追加することができる。ＩＰｖ６では、インターネット層情報は、拡張ヘッダを使用して追加される。これらのヘッダは、ＩＰｖ６ヘッダと上位層ヘッダとの間でＩＰｖ６パケットに追加される。各拡張ヘッダは、次ヘッダのタイプを識別するフィールドを含んでおり、ＩＰｖ６は、ＩＰｖ４のＩＨＬに類似したフィールドを使用する代わりに、拡張ヘッダ自体の中で各拡張ヘッダの長さを規定する。これで、無限の数の拡張ヘッダをＩＰｖ６パケットに加えることが可能になる。
【０００４】
図１は、フローラベルフィールドを含めたＩＰｖ６ヘッダ形式を示す。
【０００５】
通常のパケット処理は、典型的には、上位層ヘッダからフィールドを要求する。マルチフィールド分類（ＭＦＣ）は、そのようなデータを処理する多数の例のうちの１つであるが、通常、５−タプル＜送信元ＩＰ、宛先ＩＰ、送信元ポート、宛先ポート、プロトコル＞に基づいてパケットを分類する。オプションまたは拡張ヘッダが使用されるときには、パケット処理に必要なデータを検索するために上位層ヘッダに到達するのが困難でコストのかかるものになる場合がある。
【０００６】
ＩＰｖ４の場合、前述のＩＨＬフィールドを使用して、任意の付加オプションを含めたＩＰｖ４ヘッダ全体をスキップオーバーして上位層ヘッダに到達できるので、オプションを備えたパケットの処理が単純である。
【０００７】
ＩＰｖ６の場合、ＩＰｖ６ヘッダが上位層ヘッダに即時に到達するために使用できるＩＰｖ４のＩＨＬのようなフィールドをもたないので、拡張ヘッダを含むパケットでは、上位層ヘッダに到達するのが著しく困難である。先行技術の一解決策は、拡張ヘッダを直列にトラバース（ｔｒａｖｅｒｓｅ）することである。各拡張ヘッダの長さが拡張ヘッダ自体に格納されているので、これが最も自明の解決策であるように思われる。このように、上位層ヘッダに到達して通常のパケット処理を実行できる前に、いくつかの拡張ヘッダをトラバースする必要がある場合、ＩＰｖ６パケット処理は、コストのかかるものになる。ＩＰｖ６拡張ヘッダの存在は、特別なハンドリングがノードから必要とされることを必ずしも示さないので、このコストは、さらに不要に思われる。幾つかの拡張ヘッダは、宛先ノードだけに関する情報を含み、宛先に行く途中のすべてのノードが完全に無視できるものがある。実際、ホップバイホップ（ｈｏｐ−ｂｙ−ｈｏｐ）およびルータ拡張ヘッダだけがすべてのノードに関係があり、このルータ拡張ヘッダは、到達するパケットがノードに向かっているときにだけ利用可能である。幸いなことに、ＲＦＣ２４６０は、ホップバイホップ拡張ヘッダをＩＰｖ６ヘッダの後の第１拡張ヘッダに指定している。したがって、ノードは、単純にＩＰｖ６ヘッダの宛先アドレスおよび次ヘッダフィールドを調査することによって、パケットに特別なハンドリングが必要かどうか迅速に判定することができる。
【０００８】
従来のアプローチに代わる代替方法は、上位層ヘッダを調査する必要がないように、パケット分類で使用されるフィールドをＩＰヘッダからのフィールドだけに単純に制限することである。ＭＦＣの場合、このことが、標準の５−タプル分類を３−タプル分類に低減する。ＩＰｖ６のためのＭＦＣキーで使用されるフィールドを制限することは、ノードのセキュリティが制御される方式を変更することを意味するので、これは、あまり好評な選択肢ではない。この場合、ＩＰｖ６について新しいセットのルールを開発しなければならないが、これは単純に、上位層ヘッダからすべてのフィールドを読み取るのが不都合な場合があるからである。この理由から、パケット分類で使用されるフィールドを制限することは、対抗する解決策とは見なされない。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
簡潔に言えば、本発明は、フローの後続パケットのハンドリングを加速させるための、パケットフロー内で使用される拡張ヘッダの長さに関する情報のキャッシュに関する。例示的な一実施形態では、パケットフローがＩＰｖ６パケットを含む。
【課題を解決するための手段】
【００１０】
したがって、本発明の第１の態様によれば、拡張ヘッダを含むパケットに応答して、ヘッダ内に存在するフィールドに基づいてキャッシュキーを作成し、キャッシュエントリについてキャッシュ参照を実行するステップと、上位層ヘッダに到達し、その上位層ヘッダ内のフィールドを読み取るために、対応するキャッシュエントリの発見に応答して、キャッシュエントリを使用して拡張ヘッダを並列に読み取るステップとを含む、パケットフローの上位層ヘッダにアクセスする方法が提供される。
【００１１】
本発明の第２の態様によれば、拡張ヘッダを含むＩＰｖ６パケットヘッダに応答して、ヘッダ内に存在するフィールドに基づいてキャッシュキーを作成し、キャッシュエントリについてキャッシュ参照を実行する手段と、上位層ヘッダに到達し、その上位層ヘッダ内のフィールドを読み取るために、対応するキャッシュエントリの発見に応答して、キャッシュエントリを使用して拡張ヘッダを並列に読み取る手段とを含む、パケットフローをフィルタリングするためのＭＦＣを実行するシステムが提供される。
【００１２】
ここで、本発明について、添付図面に即してさらに詳細に説明する。
【発明を実施するための最良の形態】
【００１３】
ノードがパケットを受け取ると、ＩＰｖ６ヘッダが検査される。拡張ヘッダをもたないパケットは、通常のパケットハンドリング技術を使用してハンドリングされる。これは、これらのパケットを処理するための唯一の追加コストが、拡張ヘッダの検査であることを意味する。ホップバイホップ拡張ヘッダを備えたパケット、またはルーティングヘッダを含むノードに向かうパケットの場合、ヘッダによって指定される特別なハンドリングをこの時点で起動することができる。
【００１４】
拡張ヘッダを備えたパケットの場合、ノードが、ＩＰｖ６ヘッダに含まれる情報を使用して、キャッシュ参照を実行するためのキーを作成する。このキーの形式は、すべてのパケットについて同一にすることができ、またはＩＰｖ６ヘッダ内のフィールドの存在もしくは値に基づいたものにすることができる。例えば、非ゼロのフローラベルを備えたパケットの場合、タプル＜ＩＰｖ６．送信元ＩＰ、ＩＰｖ６．フローラベル＞、または＜ＩＰｖ６．送信元ＩＰ、ＩＰｖ６．フローラベル、ＩＰｖ６．次ヘッダ＞を使用することができる。ゼロのフローラベルを備えたパケットの場合、タプル＜ＩＰｖ６．送信元ＩＰ、ＩＰｖ６．宛先ＩＰ＞または＜ＩＰｖ６．送信元ＩＰ、ＩＰｖ６．宛先ＩＰ、ＩＰｖ６．次ヘッダ＞を使用することができる。
【００１５】
キャッシュ参照を実行している間、ヘッダからの情報を使用して、リスト内の第１拡張ヘッダを読み取ることができる。キャッシュ内にエントリが発見されない場合、ノードは、拡張ヘッダの拡張ヘッダ長および次ヘッダのフィールドを使用して、直列に拡張ヘッダのリストのトラバースを進める。直列トラバーサルの後、拡張ヘッダをトラバースするのに使用されたデータは、類似の拡張ヘッダを備えた同一フローの他のパケットを予想してキャッシュに置かれる。しかし、キャッシュされたエントリが発見された場合、ノードは、第１拡張ヘッダおよびキャッシュされたデータからの情報を使用して、残りの各拡張ヘッダを並列に読み取る。これで、ノードが拡張ヘッダを迅速にトラバースできるようになり、ノードは、上位層ヘッダに到達し、または十分なデータがキャッシュされていない場合、最後の拡張ヘッダの直列トラバーサルを継続する。拡張ヘッダの並列トラバーサルのいずれかのポイントで、キャッシュされたデータが誤りであることがわかった場合、ノードは、データが誤りであったポイントから、残りの拡張ヘッダを直列にトラバースしなければならない。この場合、類似の形式を備えた同一フローの他のパケットを予想して、現在のパケット内の拡張ヘッダを反映するようにキャッシュが更新される。
【００１６】
図２は、前述のアルゴリズムを要約している。ＩＰｖ６ヘッダを読み取った後にパケット内に拡張ヘッダが存在しないことがわかった場合、キャッシュ参照が実行されないことに留意すべきである。したがって、拡張ヘッダを使用するパケットが存在しない場合、これらの最適化をインプリメントするペナルティは、たとえあったとしてもわずかである。
【００１７】
図３は、拡張ヘッダ連結リストのトラバースと、加速されたアルゴリズム使用との間の、メモリアクセスの相違を示す。図示した事例では、パケット処理待ち時間が、１つのメモリアクセスの分だけ短縮される。図３Ａは、ヘッダの直列トラバーサルで使用されるメモリアクセスを示す。図３Ｂに示したように、並列処理は、第１拡張ヘッダのレビューと並列にステップ２Ｂでキャッシュを検査するものである。
【００１８】
本発明にはいくつか代替的な実施形態がある。第１の実施形態は、「予測不能」フローを識別して、それに対処する能力である。これは、常に拡張ヘッダが変化しているフローを検出するために使用される。そのようなフローが識別された場合、キャッシュされたデータが誤りの可能性があり、そして、並列トラバーサルを試行するのでなく拡張ヘッダを直列にトラバースすることがより効率的であることが明らかである。さらに、そのようなフローについては、現在のパケットの形式を反映するようにキャッシュを更新する必要がない。フローを「予測不能」としてマーキングすることは、手動設定によって達成することができ、またはフローの監視に基づいて動的に決定することができる。
【００１９】
第２の実施形態は、キャッシュエントリを「動かない（スティッキー）」として指定する能力である。これは、フロー内の大部分のパケットがキャッシュされたデータを使用して正しく解釈されるべきであり、また、キャッシュされたデータがパケットと一致しない場合には、キャッシュが更新されるべきでないことを示す。このことが、単一パケットがキャッシュされたデータを変更するのを防ぐ。前述した拡張機能のように、この機能は、手動でイネーブルにすることができ、またはフロー監視の結果としてイネーブルにすることができる。この拡張機能は、キャッシュ障害の場合に、キャッシュ内のデータが特定数の障害の後にだけ更新されることを指定することによって、向上させることができる。
【００２０】
第３の実施形態は、やはり、プロトコルや送信元及び宛先ポートなどの、いくつかの上位層ヘッダ情報をキャッシュすることである。キャッシュされた情報が受け取られると、プロトコル情報をＩＰｖ６ヘッダに含まれる情報と組み合わせて使用して、ＭＦＣなどのパケット分類を即時に開始することができる。分類が完了するときに、キャッシュされた残りの情報を使用して、拡張ヘッダを迅速にトラバースすることができ、そして、キャッシュされたプロトコル情報がパケットの情報と一致することを確認することができる。２セットの情報が一致する場合、分類が有効である。しかし、キャッシュからの情報が誤りの場合、上位層ヘッダからの正しい情報を用いて分類を繰り返す必要がある。最悪の場合、さらにもう１つ分類コストが存在するが、最良の場合、これで、パケット分類を拡張ヘッダのトラバーサルと並列に実施できるようになり、パケット分類に必要な待ち時間の分、パケット処理の合計待ち時間を短縮することができる。
【００２１】
他の実施形態は、通常のパケット処理の間に実行された他の分類および参照の結果をキャッシュする能力である。例えば、ＭＦＣおよび転送参照（ｆｏｒｗａｒｄｉｎｇ  ｌｏｏｋｕｐｓ）の結果を、キャッシュに追加することができる。この実施形態を使用すると、フローの第１パケットだけを完全に分類することのみが必要であり、これは、フローの後続パケットが、キャッシュからのこの分類の結果を使用できるからである。
【００２２】
本発明は、前述した先行技術の解決策に勝る利点を提供する。拡張ヘッダの大部分がほとんどのノードによる特別処理を必要としないので、本発明は、拡張ヘッダを含むＩＰｖ６パケットの処理に関連するコストを削減する。これで、パケット処理を継続できるように、上位層ヘッダに迅速に到達することを可能とする。
【００２３】
既存のＭＦＣタプルの使用に関して、上位層ヘッダの場所を迅速に見つけ出すことができるので、パケット分類で使用されるフィールドを、ＩＰｖ４に使用されたフィールドに対して変更せずにおくことができる。これは、既存のセキュリティポリシーを、ＩＰｖ４の場合と同一の方式でＩＰｖ６に適用できることを意味する。
【００２４】
拡張ヘッダ情報を並列にロードするコストは、キャッシュからデータを読み取る必要があるので、全メモリ帯域幅の少々の増加をもたらす場合があるが、この増加は、拡張ヘッダを含むパケットについてのみ発生する。
【００２５】
図４は、６個までの拡張ヘッダを並列にロードするタイムラインを示す。実線のバーは、拡張ヘッダのトラバーサルが最良の場合を示す。破線のバーは、キャッシュされた情報が誤りのときの、拡張ヘッダのトラバーサルが絶対的に最悪の場合を示す。図４Ａ〜図４Ｇから、拡張ヘッダのトラバーサルが最良の場合、破線によって示される直列ヘッダ参照に関わる処理よりも、かなりの時間が節約されることがわかる。
【００２６】
キャッシュは、任意の数の方法でインプリメントすることができる。可能なインプリメンテーションには、コンテキストアドレス可能なメモリ（ＣＡＭ：ｃｏｎｔｅｘｔ  ａｄｄｒｅｓｓａｂｌｅ  ｍｅｍｏｒｙ）の使用、またはハッシュテーブルの使用を通じた方法が含まれる。おそらく最も明らかな方法は、既存のＣＡＭを使用することである。キャッシュとしてＣＡＭを使用することには、利点と欠点とがある。主な利点は、ＣＡＭを用いた場合、キーからのビットをすべてではなくてもほとんど使用して、正確なインプリメンテーションに応じて、キーを一致させるときに衝突が起こる可能性をほとんどまたは全くもたらさない参照を実行できることである。これは、ＣＡＭから間違った情報を取得することに起因した不一致がほとんどないことを意味する。ＣＡＭのインプリメンテーションのマイナス面は、ＣＡＭが高価でスペースに制約されるという事実を別にして、ＣＡＭ参照が、キャッシュ参照を実施するのに２回のメモリアクセスを必要とする場合があることである。第１のアクセスである書込みは、ＣＡＭにキーおよび参照を実行する命令を提供する。第２のアクセスである読取りは、ＣＡＭから結果を検索する。
【００２７】
ＣＡＭの使用に代わる代替方法として、ハッシュテーブルを使用してキャッシュをインプリメントすることができる。貴重でコストのかかるＣＡＭスペースを消費しないので、このインプリメンテーションには特定の利点がある。ハッシュ参照を実行できる速度の理由から、このインプリメンテーションは、恐らくは少なくともＣＡＭインプリメンテーションと同程度に速く、確実にＣＡＭインプリメンテーションよりもコストがかからない。ハッシュインプリメンテーションのマイナス面は、ＣＡＭインプリメンテーションに比べ、キーを一致させるときに衝突が起こる可能性が大きいことである。
【００２８】
正確にキャッシュがどのようにインプリメントされるかに応じて、キーを一致させるときに衝突が起こる可能性がある。これは、キャッシュへの索引としてとしてキーのビットすべてを使用しなかった結果である。結果として、この衝突を解決するためにさらなる処理が必要になる場合がある。特定のインプリメンテーションでは、これらの衝突を解決するコストが、キャッシュ情報の誤りが原因で拡張ヘッダを直列にトラバースするコストよりも大きくなることがある。これらの場合、単純に衝突が起こらないと仮定することが有益である。最終的には、キャッシュとパケットデータとの不一致の頻度を増加させるが、処理を全体的に削減することになる。ハッシュインプリメンテーションの場合、衝突を解決するのに必要であった情報がもはや必要ないので、ハッシュテーブルエントリのサイズが縮小されるという追加的な利益がある。ハッシュテーブルエントリサイズの縮小は、テーブル内のエントリ数を効果的に増加させ、またはメモリの節約を可能にする。
【００２９】
前述したように、キャッシュする方法は、キャッシュへの索引を付けるためのキーを作成するために、ヘッダからのフィールドを使用する。キャッシュに格納される情報は、パケット内に存在すると思われる情報の複製である。この複製の理由から、キャッシュされたデータがパケット内のデータと確実に一致するように注意しなければならない。この目的で、拡張ヘッダがキャッシュされたデータと一致することを確認するためにロードされることが可能なように、最低でも拡張ヘッダの長さをキャッシュしなければならない。この検証が実行されなければ、悪意のあるホストが有効なフローを確立することが可能であるが、いくつかのセキュリティメカニズムを迂回するためにフローの後続パケットを修正することが可能である。一例として、単純にすべての拡張ヘッダの全長をキャッシュするインプリメンテーションを仮定する。多くの拡張ヘッダを含む、フローの第１パケットが到達すると、拡張ヘッダが直列にトラバースされ、エントリがキャッシュに加えられる。ＭＦＣは、パケットに関して実行され、パケットが受け入れられる。フローの別のパケットが到達し、キャッシュされたデータが読み取られる。拡張ヘッダの合計オフセットが使用されて、上位層ヘッダであると思われるものが読み取られるが、これは、実際には第１パケットのヘッダと同一の偽のヘッダである。ＭＦＣが実行され、パケットが受け入れられる。拡張ヘッダが直列的に読み取られたので、明らかに、この第２パケットは、第１パケットよりも拡張ヘッダ数が少なく、実際の上位層ヘッダは、キャッシュされたデータによって指される場所よりもパケット内の早い場所で見付かる。
【００３０】
本発明の特定の実施形態について記載し説明したが、本発明の基本概念から逸脱することなく多くの変更を実施できることが当業者には明らかであろう。しかしながら、そのような変更が、特許請求の範囲によって定義される本発明の全範囲内に入ることを理解すべきである。
【図面の簡単な説明】
【００３１】
【図１】ＩＰｖ６ヘッダ形式を示す図である。
【図２】ＩＰｖ６パケットの上位層ヘッダに到達するのに必要な動作シーケンスを示す図である。
【図３】直列処理および複数の処理を使用するメモリアクセスの比較を示す図である。
【図４】オプションを使用する拡張ヘッダ参照のタイムラインを示す図である。
【図１】
2005130502.tif 000003
【図２】
2005130502.tif 000004
【図３】
2005130502.tif 000005
【図４】
2005130502.tif 000006
【外国語明細書】
2005130502.tif 000007
2005130502.tif 000008
2005130502.tif 000009
2005130502.tif 000010
2005130502.tif 000011
2005130502.tif 000012
2005130502.tif 000013
2005130502.tif 000014
2005130502.tif 000015
2005130502.tif 000016
2005130502.tif 000017
2005130502.tif 000018
2005130502.tif 000019
2005130502.tif 000020
2005130502.tif 000021
2005130502.tif 000022
2005130502.tif 000023
2005130502.tif 000024
2005130502.tif 000025
2005130502.tif 000026