JP4038223B2 - パケット転送方法及び装置 - Google Patents

Description

本発明は、パケット転送方法及び装置に関し、特にＩＰｖ６又はＩＰｖ４ネットワークにおいてカプセル化され且つフラグメント化されたパケットを受信して転送するパケット転送方法及びこの方法を実現するノード又はルータなどのパケット転送装置に関するものである。

図１０は、一般的に知られているＩＰｖ６ネットワークを示し、この例では、ノード１０から送信されたパケットが、ノード２０を経由してノード３０に転送される構成例を示している。
この場合、ノード１０とノード２０の間にはカプセル化されたＩＰパケット（ＩＰ−ｉｎ−ＩＰパケット）を使用したＩＰトンネルＴＮが設けられており、このＩＰトンネルＴＮを通過するために、ノード１０ではパケット（インナーヘッダとデータとで構成されたもの）ＰＫＴ１をアウターヘッダでカプセル化したパケットＰＫＴ２を生成してノード２０に送る。
なお、「インナーヘッダ」とはカプセル化前のヘッダを指称し、「アウターヘッダ」とはカプセル化後にさらに付加されるヘッダを指称する。
ノード２０では、この内のアウターヘッダをデカプセル化したパケットＰＫＴ１に戻してノード３０に転送するようにしている。
このような場合、ノード１０から送出されるパケットが所定長を越えたためにフラグメント（断片化）されている場合には、ノード２０では、このフラグメント化されたパケットをデフラグメント（リアセンブル）化してからデカプセル化（ＩＰ−ｉｎ−ＩＰのアウターヘッダを外す処理）が必要となる。
図１１は、図１０に示したようなＩＰｖ６ネットワークにおけるノード間のパケット転送方法を示したものであり、以下、図１１を参照して各ノード、特にノード１０及び２０におけるパケット処理について説明する。
まずノード１０においては、同図（１）に示すように、元のパケットは、ＩＰｖ６ヘッダとデータグラム（Ａ）とで構成されており、この場合、パケット長が１５００バイト又は経路ＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｆｅｒ Ｕｎｉｔ）長を超えているものとする。
このように、元パケットはパケット長が規定の１５００バイト或いは経路ＭＴＵ長を越えているので、同図（２）に示すようにフラグメント化１が実行され、データグラム（Ａ）は、この例では、２つのデータグラム（Ａ１）及び（Ａ２）に分割され、それぞれにＩＰｖ６ヘッダが付与される共に、フラグメントヘッダＦｒｇを生成してＩＰｖ６ヘッダと各データグラム（Ａ１），（Ａ２）との間に挿入する。
この後、同図（３）に示すように、分割した各パケットに対してＩＰｖ６ヘッダをアウターヘッダとして付与し、同図（２）に示したＩＰｖ６ヘッダをインナーＩＰｖ６ヘッダとするカプセル化を行って、ＩＰ−ｉｎ−ＩＰパケットを生成する。
上記のようにフラグメント化した場合でも、さらにカプセル化した場合には、パケットが経路ＭＴＵを越えてしまうことがある。この例では先頭パケットが経路ＭＴＵを越えてしまっている。このような場合には、同図（４）に示すように更にフラグメント化２を行う必要がある。
すなわち、先頭パケットを図示のように更に２つのパケットにフラグメント化し、先頭パケットの長さが経路ＭＴＵ長以下になるようにする必要がある。
この場合、データグラム（Ａ１）は２つのデータグラム（Ａ１−１）及び（Ａ１−２）に分割され、それぞれに対してアウターＩＰｖ６ヘッダとそのアウターフラグメントヘッダＯｕｔ−Ｆｒｇを生成して挿入することになる。なお、同図（２）で示したフラグメント化１におけるフラグメントヘッダＦｒｇは、インナーフラグメントヘッダＩｎ−Ｆｒｇとなる。
このようにしてノード１０においては、フラグメント化１とカプセル化とフラグメント化２とを経由することにより３つのパケットが生成されて同図（５）に示すようにノード２０に送られる。なお、この場合のパケットのノード２０への到着順は不定である。
ノード２０においては、同図（６）に示すようにまず先頭のパケットと２番目のパケットに対してデフラグメント化（前処理）を行う。このデカプセル化は、アウターフラグメントヘッダＯｕｔ−Ｆｒｇに従ってパケットを組み立てるものであり、図示のように先頭パケット及び２番目のパケットに対しアウターフラグメントヘッダＯｕｔ−Ｆｒｇを除去し、２番目のパケットはアウターＩＰｖ６ヘッダも除去する。
そして、同図（７）に示すようにデフラグメント化を完了し、同図（６）に示したデフラグメント化で前処理されたデータグラム（Ａ１−１）及び（Ａ１−２）をデータグラム（Ａ１）に結合する。
そして、同図（８）に示すようにデカプセル化を実行し、同図（７）で結合したパケットのアウターＩＰｖ６ヘッダを除去すると共に、３番目のパケットにおけるアウターＩＰｖ６ヘッダも除去する。
このようにして、ノード２０からは、同図（９）に示すようにデフラグメント化され且つデカプセル化された２つのパケットがノード３０（図１０参照）に送られることになる。
また、アウターＩＰｖ６ヘッダが除去されたことに伴い、インナーＩＰｖ６ヘッダは、ＩＰｖ６ヘッダとなり、インナーフラグメントヘッダＩｎ−Ｆｒｇは同図（２）におけるフラグメント化１に示したフラグメントヘッダＦｒｇとなる。
図１１に示した従来例は、フラグメント化した後にカプセル化したが、再度フラグメント化する必要性が発生しフラグメント化を行ったもの（パターンＩ）であるが、図１２に示す従来例の場合は、ノード１０において先にカプセル化した後にフラグメント化したもの（パターンＩＩ）を扱っている。
まず、同図（１）に示す元パケットは、図１１（１）に示した元パケットと同様のものであるとする。
この後、図１２（２）に示すように、カプセル化を行い、アウターＩＰｖ６ヘッダを付与してＩＰ−ｉｎ−ＩＰパケットとする。なお、これに伴い、元パケットのＩＰｖ６ヘッダはインナーＩＰｖ６ヘッダとなる。
上記の場合、カプセル化したパケット長が１５００バイト或いは経路ＭＴＵ長を越えているとすると、同図（３）に示す例の場合には、３つのパケットにフラグメント化する必要がある。
このため、データグラム（Ａ）をデータグラム（Ａ１）〜（Ａ３）に３分割すると共に、それぞれにアウターＩＰｖ６ヘッダを付与し、且つそのフラグメントヘッダＦｒｇを生成してアウターＩＰｖ６ヘッダとインナーＩＰｖ６ヘッダとの間に挿入する。
このようにして、ノード１０からは、同図（４）に示すように３つのフラグメントパケットが生成されて出力され、ノード２０に送られる。なお、この場合のパケットのノード２０への到着順は不定である。
ノード２０においては、同図（５）に示すようにデフラグメント化（前処理）が実行され、各パケットにおけるフラグメントヘッダＦｒｇに従ってパケットを組み立てる。この場合、先頭パケットはフラグメントヘッダＦｒｇのみを除去し、２番目以降のパケットはアウターＩＰｖ６ヘッダ及びフラグメントヘッダＦｒｇを含む全ヘッダを除去することになる。
そして、同図（６）に示すように、デフラグメント化を完了し、同図（５）に示すデフラグメント化で前処理されたデータグラム（Ａ１）〜（Ａ３）をデータグラム（Ａ）に結合する。
そして、同図（７）に示すようにデカプセル化を実行し、アウターＩＰｖ６ヘッダを除去してノード２０から送出する。
この結果、同図（８）に示すように、ノード２０からノード３０にはＩＰｖ６ヘッダとデータグラム（Ａ）から成るパケットが送られることになる。また同図（７）で示したインナーＩＰｖ６ヘッダは同図（８）に示すようにＩＰｖ６ヘッダとなる。
このように、従来の技術においては、他のノードにおいてカプセル化→フラグメント化という処理を経由したパケットを、自分のノードでデカプセル（脱ＩＰトンネル）化するには、デフラグメント化→デカプセル化という手順で処理を行う必要があり、パケットのフラグメントヘッダの情報（フラグメントオフセット値）を参照してパケットを組み立てるというデフラグメント処理が不可欠であった。
このようなデフラグメント化処理をハードウェアで行う際の最大の問題点は、パケットを組み立てる際に発生する転送遅延時間である。ＩＰネットワークでは、パケットの順序逆転なども発生するため、パケットの組立に際し、先着した後続パケットを先頭パケットが到着するまで一旦バッファリングして待機させることが必須であり、このバッファリングによる滞留時間がそのまま遅延時間になってしまう。
更に、ワイヤースピードの処理を行うネットワーク機器では、一旦バッファリングしたパケットというのは装置内部で発生したパケットと同等であり、受信のトラフィックが高い場合には送出の際に輻輳が発生し、待ち合わせが必要になるなど、さらに遅延時間が加算されることになる。
もう一つの問題点は、このようなバッファリングに伴ってハード規模が増大して大規模になることである。個別バッファ方式でパケットをバッファリングすると巨大なバッファ（メモリ）が必要になり、共通バッファ方式にするとハードウェア構成が複雑になってしまう。また、ネットワークの輻輳などによるパケットの廃棄（フラグメントの一部が廃棄された場合など）に対応するため、組立タイマーを用意する必要もある。
一方、送信元のホストが宛先ホストまでの経路上の最小のＭＴＵを把握して、そのＭＴＵに収まる範囲のパケットを送信できるようにし、ＩＰルータにおいて中継の遅延を招くフラグメント処理を行わずに高速でパケットを中継することができるルータの中継方法及びルータ装置がある（例えば、特許文献１参照。）。
また、ＩＰｖ６やＩＰｖ４などのＩＰパケットのＩＰｖ６カプセル化についてのモデル及び一般的なメカニズムについて記載したものもある。（例えば、非特許文献１参照。）。
特開平１１−１６８４９２号公報（第３頁［００２９］、図１） ″Ｇｅｎｅｒｉｃ Ｐａｃｋｅｔ Ｔｕｎｎｅｌｉｎｇ ｉｎ ＩＰｖ６ Ｓｐｅｃｉｆｉｃａｔｉｏｎ″

Ａ．Ｃｏｎｔａ，Ｌｕｃｅｎｔ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｉｎｃ．；Ｓ．Ｄｅｅｒｉｎｇ，Ｃｉｓｃｏ Ｓｙｓｔｅｍｓ（Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ：２４７３ Ｃａｔｅｇｏｒｙ：Ｓｔａｎｄａｒｄｓ Ｔｒａｃｋ），Ｄｅｃｅｍｂｅｒ １９９８（インターネットＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４６０．ｔｘｔ？ｎｕｍｂｅｒ＝２４６０）
従って本発明は、カプセル化された後にフラグメント化されたパケットを受信したとき、転送遅延を少なくし且つ小規模なハードウェアでパケット転送することのできる方法及び装置を提供することを目的とする。

上記の目的を達成するため、本発に係るパケット転送方法は、カプセル化された後にフラグメント化された受信パケットから先頭パケット及び後続パケットを検出する第１ステップと、該第１ステップで検出した該先頭パケットのインナーヘッダを保存した後にデカプセル化すると共に該インナーヘッダを該デカプセル化に合わせて変更する第２ステップと、該後続パケットをデカプセル化すると共に該第２ステップで変更した該先頭パケットのインナーヘッダ及び該フラグメント化に合わせたフラグメントヘッダを各パケットに付与し出力する第３ステップとを備えたことを特徴としている。
すなわち、本発明では、第１ステップにおいて、カプセル化された後、フラグメント化された受信パケットから先頭パケット及びこれに続くパケット（後続パケット）を検出する。
そして第２ステップでは、上記の第１ステップで検出した先頭パケットのインナーヘッダを保存した後にデカプセル化してアウターヘッダ及びそのフラグメントヘッダを除去する。さらにこの第２ステップでは、保存した該先頭パケットのインナーヘッダを該デカプセル化に合わせて変更しておく。
そして第３ステップでは、まず第１ステップで検出した後続パケットをデカプセル化してそのアウターヘッダ及びフラグメントヘッダを除去すると共に、上記の第２ステップでデカプセル化に合わせて変更した該先頭パケットのインナーヘッダを該後続パケットに付与する。
このとき、各パケット（先頭パケット及び後続パケット）に対応させて生成したフラグメントオフセット値も各パケットに付与し、このようにして生成された各パケットを出力する。
以上のように本発明においては、デフラグメント化処理をスキップしてデカプセル化を行い、パケットを最終的に受信するノードでデフラグメント化を可能にさせている。すなわち、フラグメント化されたパケットのデータグラム部分はそのままで、ヘッダを操作することでデカプセル化を可能にしているので、デフラグメント化に伴うパケット組立時の転送遅延やハード規模の増大を排除することが可能となる。
ここで、上記の第１ステップは、該受信パケットが該先頭パケットであるか否かを問わずにフラグメント識別値をテーブルに登録しておき、該フラグメント識別値の登録が無ければ最初に受信したパケットであると判定するステップを含むことができる。
すなわち、フラグメント識別値がテーブルに登録されていなければそのパケットは最初に受信したパケットであり、テーブルに登録があればその後に受信したパケットであると判定することができる。ただしこの場合、最初に受信したパケットが先頭パケットであるとは限らず、後続パケットを最初に受信した場合も含むものである。
上記のフラグメント識別値は、先頭パケットのアウターヘッダ中の送信元アドレスとフラグメントＩＤとで構成することができる。
また上記の第１ステップは、受信パケットが先頭パケットであるか否かを、先頭パケットのアウターフラグメントヘッダ中のフラグメントオフセット値が所定値であるか否かで判定するステップを含むことができる。
すなわち、先頭パケットのフラグメントオフセット値は一般に該所定値が“０”であり、これに基づいて受信パケットが先頭パケットであるか否かを判定することが可能となる。
また上記の第１ステップは、該先頭パケットより該後続パケットを先に受信したと判定したときには、該後続パケットをバッファに格納して待機させるステップを含み、該第２ステップの後に、該後続パケットを該バッファから読み出して該第３ステップを実行する第４ステップをさらに有することができる。
すなわち、上記のように先頭パケットは後続パケットより必ずしも先に到着するとは限らず、先頭パケットより後続パケットの方が先に受信したと判定した場合には、後続パケットをバッファに一旦格納して待機させておき、第４ステップでは、上記の第２ステップの後に、該後続パケットをバッファから読み出して上記の第３ステップを実行することになる。
更に上記の第１ステップは、該先頭パケットが、該カプセル化の前にフラグメント化したことを示すフラグメントヘッダを含んでいるか否かでパターンＩに該当するか、又はパターンＩＩに該当するかを判定するステップを含み、該パターンＩと判定されたとき、該第２ステップを実行させ、該パターンＩＩと判定されたとき、該先頭パケットに対するフラグメントヘッダを生成してから該第２ステップを実行させる第５ステップをさらに有し、該第３ステップが、該フラグメントヘッダ中のフラグメントオフセット値を、該パターンの種別に応じて該デカプセル化前の値から該後続パケットに対するヘッダ長分だけ減算した値にするステップを含むことができる。
すなわち、パターンＩは、先頭パケットに対しフラグメント化した後にカプセル化し、更にフラグメント化したものであり、パターンＩＩはカプセル化した後にフラグメント化したものである。
従って、第５ステップでは、パターンＩと判定したときには、上記の第２ステップを実行し、パターンＩＩと判定したときには、この第２ステップを実行する前に先頭パケットに対するフラグメントオフセット値を生成するものである。従って、第３ステップにおけるフラグメントオフセット値は、上記のパターンの種別に応じてデカプセル化前の値から該後続パケットに対するヘッダ長分だけ減算した値とすればよい。
また、該第２ステップで該インナーヘッダを保存するとき、該パターンＩであれば、該先頭パケットのフラグメントオフセット値も保存し、該パターンＩＩであれば該生成したフラグメントオフセット値を保存し、いずれのパターンにおいても、これらのフラグメントオフセット値に基づいて該第３ステップで、該フラグメント化に合わせたフラグメントオフセット値を該後続パケットに付与することができる。
すなわち、第２ステップでインナーヘッダを保存するときには、フラグメントオフセット値も何らかの形で保存するか或いは生成する必要があり、パターンＩの場合には先頭パケットのフラグメントオフセット値も同時に保存し、パターンＩＩの場合には先頭パケット用のフラグメントオフセット値を生成して保存しておく。
そして第３ステップでは、いずれのパターンの場合も、これらの保存したフラグメントオフセット値に基づいて上記のフラグメント化に合わせたフラグメントオフセット値を後続パケットに付与すれば良いことになる。
さらに上記の第３ステップは、該パターンが該パターンＩのとき、該先頭パケットのフラグメントオフセット値を、そのアウターフラグメントヘッダ中のフラグメントオフセット値からインナーヘッダ及びそのフラグメントヘッダの各データ長を減算した値に変更し、該パターンＩＩのときは、該アウターフラグメントヘッダ中のフラグメントオフセット値からインナーヘッダのデータ長を減算した値に変更して該後続パケットに付与するステップを含むことができる。
すなわち、フラグメントオフセット値を、フラグメント化した各パケットに対応させる条件を示しており、パターンＩの場合にはインナーフラグメントヘッダはそのまま先頭パケットに残るので、これに基づいて後続パケットのフラグメントオフセット値をインナーヘッダ及びそのフラグメントヘッダの各データ長を減算した値に変更し、パターンＩＩのときは先頭パケットは上記のように新たに生成し、この新たに生成したフラグメントオフセット値からインナーヘッダのデータ長を減算した値に変更して後続パケットに付与すれば良いことになる。
さらに、上記の第３ステップで変更するインナーヘッダは、該パターンＩのときは該アウターヘッダ内のペイロード長から該アウターフラグメントヘッダ及び該インナーヘッダの各データ長を引いた値であり、該パターンＩＩのときは該アウターヘッダ内のペイロード長から該インナーヘッダのデータ長を引いた値とすることができる。
すなわち、第３ステップでインナーヘッダを変更する態様を示しており、上記のパターンＩのときはアウターヘッダ内のペイロード長からアウターフラグメントヘッダ及びインナーヘッダの各データ長を引いた値であり、パターンＩＩのときはアウターヘッダ内のペイロード長からインナーヘッダのデータ長を引いた値とすることが可能となる。
上記の受信パケットは、ＩＰトンネルを経由したＩＰｖ６パケットとすることができる。
以上の本発明に係るパケット転送方法を実現する装置としては、カプセル化された後にフラグメント化された受信パケットから先頭パケット及び後続パケットを検出する第１手段と、該第１手段で検出した該先頭パケットのインナーヘッダを保存した後にデカプセル化すると共に該インナーヘッダを該デカプセル化に合わせて変更する第２手段と、該後続パケットをデカプセル化すると共に該第２手段で変更した該先頭パケットのインナーヘッダ及び該フラグメント化に合わせたフラグメントヘッダを各パケットに付与し出力する第３手段と、を備えている。
ここで、上記の第１手段は、該受信パケットが該先頭パケットであるか否かを問わずにフラグメント識別値をテーブルに登録しておき、該フラグメント識別値の登録が無ければ最初に受信したパケットであると判定する手段を含むことができる。
また上記のフラグメント識別値は、該先頭パケットのアウターヘッダ中の送信元アドレスとフラグメントＩＤとで構成されることができる。
また上記の第１手段は、該受信パケットが該先頭パケットであるか否かを、該先頭パケットのアウターフラグメントヘッダ中のフラグメントオフセット値が所定値であるか否かで判定する手段を含むことができる。
また上記の第１手段は、該先頭パケットより該後続パケットを先に受信したと判定したときには、該後続パケットをバッファに格納して待機させる手段を含み、該第２手段の後に、該後続パケットを該バッファから読み出して該第３手段を実行する第４手段をさらに有することができる。
また上記の第１手段は、該先頭パケットが、該カプセル化の前にフラグメント化したことを示すフラグメントヘッダを含んでいるか否かでパターンＩに該当するか、又はパターンＩＩに該当するかを判定する手段を含み、該パターンＩと判定されたとき、該第２手段を実行させ、該パターンＩＩと判定されたとき、該先頭パケットに対するフラグメントヘッダを生成してから該第２手段を実行させる第５手段をさらに有し、該第３手段が、該フラグメントヘッダ中のフラグメントオフセット値を、該パターンの種別に応じて該デカプセル化前の値から該後続パケットに対するヘッダ長分だけ減算した値にする手段を含むことができる。
また上記の第２手段で該インナーヘッダを保存するとき、該パターンＩであれば、該先頭パケットのフラグメントオフセット値も保存し、該パターンＩＩであれば生成したフラグメントオフセット値を保存し、いずれのパターンにおいても、これらのフラグメントオフセット値に基づいて該第３手段が、該フラグメント化に合わせたフラグメントオフセット値を該後続パケットに付与することができる。
さらに上記の第３手段は、該パターンが該パターンＩのとき、該先頭パケットのフラグメントオフセット値を、そのアウターフラグメントヘッダ中のフラグメントオフセット値からインナーヘッダ及びそのフラグメントヘッダの各データ長を減算した値に変更し、該パターンＩＩのときは、該アウターフラグメントヘッダ中のフラグメントオフセット値からインナーヘッダのデータ長を減算した値に変更して該後続パケットに付与する手段を含むことができる。
さらに上記の第３手段で変更するインナーヘッダは、該パターンＩのときは該アウターヘッダ内のペイロード長から該アウターフラグメントヘッダ及び該インナーヘッダのデータ長を引いた値であり、該パターンＩＩのときは該アウターヘッダ内のペイロード長から該インナーヘッダのデータ長を引いた値とすることができる。
これらのパケット転送装置における受信パケットも、例えばＩＰトンネルを経由したＩＰｖ６パケットである。

図１は、本発明に係るパケット転送方法を実現するパケット転送装置の一実施例を示したブロック図である。
図２は、図１に示した本発明に係るパケット転送装置の各ブロックの機能を表で示した図である。
図３は、本発明に係るパケット転送方法及び装置のパターンＩに関する動作を説明するためのシーケンス図である。
図４は、図３に示したパターンＩに関する処理手順を示したフローチャート図である。
図５は、一般的に知られたＩＰパケット（ＩＰｖ６／ＩＰｖ４パケット）のフレームフォーマット図である。
図６は、図１に示した本発明に用いられるフラグメント検索テーブル及びヘッダ格納テーブルの一実施例を示した図である。
図７は、本発明に係るパケット転送方法及び装置のパターンＩＩに関する動作を説明するためのシーケンス図である。
図８は、図７に示したパターンＩＩに関する処理手順を示したフローチャート図である。
図９は、本発明に係るパケット転送方法及び装置のパターンＩ及びパターンＩＩの双方に対応可能な処理手順を示したフローチャート図である。
図１０は、一般的に知られたＩＰｖ６ネットワークを示した図である。
図１１は、従来のパケット転送方法及び装置に於けるパターンＩに関する動作を説明するためのシーケンス図である。
図１２は、従来のパケット転送方法及び装置に於けるパターンＩＩに関する動作を説明するためのシーケンス図である。

符号の説明

１ パケット受信部
２ 判定・検索部
３ フラグメント検索テーブル
４ ヘッダ格納テーブル
５ パケット処理部
６ パケットバッファ
７ パケット送信部
１０，２０，３０ ノード（ルータ）
ＰＫＴ，ＰＫＴ１，ＰＫＴ２ パケット
図中、同一符号は同一又は相当部分を示す。

図１は、本発明に係るパケット転送方法の実施に使用するパケット転送装置を使用したもので、特に図１０に示したＩＰｖ６ネットワークにおけるノード（又はルータ）２０に相当するものである。
図２は、図１示したパケット転送装置の各ブロックの機能を示しており、パケット受信部１は、例えば図１０に示したノード（ルータ）１０等の外部（装置）からパケットを受信し、判定・検索部２に送信するものである。
また判定・検索部２は、受信したフラグメントパケットを識別し、その種別に合った処理を実行するため、フラグメントテーブル３及びヘッダ格納テーブル４に接続されている。
このフラグメント検索テーブル３は、フラグメントパケットの識別とヘッダ格納テーブル４のインデックスとを対応付けたテーブルであり、ヘッダ格納テーブル４はフラグメントパケット毎のヘッダ等をインテックス毎に格納するものである。
判定・検索部２は更にパケット処理部５に接続されており、このパケット処理部５は、フラグメントパケットのデカプセル化及びＩＰヘッダ及びフラグメントヘッダの付与をヘッダ格納テーブル４及びパケットバッファ６を使用して行うものである。パケットバッファ６はフラグメントパケットを格納するものである。
パケット処理部５は更にパケット送信部７に接続され、このパケット送信部７は、例えば図１０に示したノード（ルータ）３０にパケットを転送するものである。
パターンＩの動作
以下、図１に示したパケット転送装置におけるパターンＩの動作を図３から図６を参照して説明する。
なお、この動作手順は、図１０に示したＩＰｖ６ネットワークを構成するノード１０〜３０間の動作手順を例示したものであり、この内のノード１０における図３（１）〜（４）の動作手順は図１１に示した従来例の動作手順と同様である。すなわち、図３（１）に示す元パケットは、同図（２）に示すフラグメント化１を行い、次に同図（３）に示すカプセル化を行い、そして同図（４）に示すフラグメント化２を行って、同図（５）に示すようなパケットをノード１０からノード２０へ送信するものである。
本発明に係るパケット転送装置に相当するノード２０においては、図３（６）に示すようにまずデカプセル化を行い、アウターＩＰｖ６ヘッダを除去すると共に先頭及び２番目のパケットのアウターフラグメントヘッダＯｕｔ−Ｆｒｇを除去し、同図（７）に示すようにヘッダ生成を行って２番目のパケットに付与し、同図（８）に示すようにノード２０からノード３０へパケットを転送するものである。
このようなノード２０におけるデカプセル化処理及びヘッダ生成処理を図４のフローチャートを参照して以下に具体的に説明する。
まず、ノード１０からノード２０へのパケットの到着順は不定であることを前提にしているため、図３（５）に示すフラグメントパケットをノード２０がパケット受信部１から受信したとき、この受信パケットが先頭のパケットであるか後続のパケットであるかを、フラグメント検索テーブル３を検索することからこの処理が開始される（ステップＳ１：図２の判定・検索部２の機能（１））。
これは、図５（１）に示したアウターＩＰｖ６ヘッダにおけるソース（発信元）ＩＰアドレス（ＳＡ）と、フラグメントヘッダを構成するフラグメントＩＤと、で構成されたフラグメント識別値に基づいて判定・検索部２が受信したパケットの先着順を判定するものである（フラグメント検索テーブル３の機能（１），（２））。
図６には、フラグメント検索テーブル３の実施例が示されており、このフラグメント検索テーブル３は、インデックスＮ，Ｎ＋１，Ｎ＋２，・・・に対してそれぞれ識別値Ｘ，Ｚ，Ｙ，・・・を格納するものであり、同図（１）に示すように、受信したパケットの発信元アドレス（ＳＡ）とフラグメントＩＤとがこのフラグメント検索テーブル３のいずれかのインデックスにあるか否かを検索することになる（フラグメント検索テーブル３の機能（１））。
このようなフラグメント検索テーブル３を検索した結果、ヒットしたとき（フラグメント検索テーブル３に登録されているとき）は既に先着パケットがあることを示しており、ヒットしないときには先着パケットは無いことを示していることになる（同Ｓ２：判定・検索部２の機能（３））。
最初はフラグメントパケットは何も受信していないのでヒットせず、ステップＳ２からステップＳ３の処理に進み、アウターフラグメントヘッダＯｕｔ−Ｆｒｇ内のフラグメントオフセット値（以下、（Ｏｕｔ−Ｆｒｇ）で表わす。）が所定値であるか否かを判定する（判定・検索部２の機能（３））。この場合の所定値とは“０”であり、パケットが先頭パケットである場合にはこのフラグメントオフセット値（Ｏｕｔ−Ｆｒｇ）は“０”に設定されているので、ステップＳ３からＳ４に進むが、フラグメントオフセット値（Ｏｕｔ−Ｆｒｇ）が“０”でない場合には後続パケット（図３の例では２番目のパケット）を受信したことを示すのでステップＳ３からステップＳ８に進む。
先頭パケットが初めて到着したことが分かったとき、ステップＳ４においては、図６に示すフラグメント検索テーブル３の任意のインデックスにフラグメント識別値を登録する（判定・検索部２の機能（２））。そして、ステップＳ５において、フラグメント検索テーブル３のインデックスに対応したヘッダ格納テーブル４のエリアにインナーＩＰｖ６ヘッダとそのフラグメントオフセット値（Ｉｎ−Ｆｒｇ）を保存する（判定・検索部２の機能（４）及びヘッダ格納テーブル４の機能（１））。
なお、図６に示したヘッダ格納テーブル４においてはフラグメントオフセット値（Ｇｅｎ−Ｆｒｇ）及びパターン種別が示されているが、このパターンＩの動作においてはこれらの情報は使用されず、後述するパターンＩＩの処理において使用されるものである。
この後、ステップＳ６においては、デカプセル化処理を行う。これは、まずアウターＩＰｖ６ヘッダ及びそのアウターフラグメントヘッダを除去する（パケット処理部５の機能（１））と共にインナーＩＰｖ６ヘッダのペイロード長の変更を行う（同（２））。
なお、これらのヘッダの除去に際しては、アウターＩＰｖ６ヘッダ内のペイロード長を保存（コピー）しておく必要があり（パケット処理部５の機能（１））、またインナーＩＰｖ６ヘッダのペイロード長の変更は、ステップＳ１００に示す通り、ＩＰｖ６ヘッダ内のペイロード長−フラグメントヘッダＯｕｔ−Ｆｒｇのヘッダ長（８バイト）−インナーＩＰｖ６ヘッダのヘッダ長（４０バイト）という値に変更される。
このようにしてデカプセル化され且つヘッダ生成されたパケットは、パケット送信部７によりノード３０に対して出力される（ステップＳ７）。この場合の先頭パケットは、図３（８）に示すデータグラム（Ａ１−１）を含むフラグメントパケットである。
ステップＳ３に戻り、フラグメントオフセット値が“０”でなかった場合には、上述したように後続パケットであるが、先に到着したパケットであるので、この場合も先頭パケットと同様に、すなわちステップＳ４と同様にフラグメント検索テーブル３の任意のインデックスにフラグメント識別値を登録しておく。
そして、この後続パケットは出力することができないので、パケットバッファ６にその受信した後続パケットを格納しておく（ステップＳ９：パケットバッファ６の機能（１））。これは各フラグメントパケット毎に行われる。
一方、ステップＳ２においてヒットした場合には、既にフラグメント検索テーブル３において識別値の登録が有り、何らかのパケットが受信されていることを示すので、この受信パケットが先頭のパケットであるか後続のパケットであるかをステップＳ１０において判定する（判定・検索部２の機能（３））。
すなわち、このステップＳ１０は上記のステップＳ３と同様にフラグメントヘッダにおけるフラグメントオフセット値が“０”であるか否かによって、後着の先頭パケットであるか後着の後続パケットであるかを判定している。
この結果、フラグメントオフセット値が“０”であることが分かったときには、後着の先頭パケットであるので、ステップＳ１１を実行する。このステップＳ１１は、上記のステップＳ５と同様であり、ヒットしたインデックスに対応したヘッダ格納テーブル４のエリアにインナーＩＰｖ６ヘッダとそのインナーフラグメントヘッダＩｎ−Ｆｒｇを保存しておく（同（４））。
その後、デカプセル化処理を行う（ステップＳ１２）。これは、上記のステップＳ６と同様であり、アウターＩＰｖ６ヘッダ及びアウターフラグメントヘッダを除去し（ペイロード長のみ保存）且つインナーＩＰｖ６ヘッダ長を変更するものである（パケット処理部５の機能（１），（２））。
この後、この先頭パケットをパケット送信部７からノード３０へ出力する（ステップＳ１３）。
ここで、このようなステップＳ１０〜Ｓ１３は、後着の先頭パケットについての処理であり、既に後続パケットが先に到着していることを示しているので、上記のステップＳ９でパケットバッファ６に格納されたパケットをパケットバッファ６からパケット処理部５が読み出す（ステップＳ１４）。これは該当するフラグメントパケット毎に行われる。
このようにしてバッファ６から読み出されたパケットはステップＳ１に戻って、上記と同様にフラグメントパケットの識別を行い、この結果、ステップＳ２において当然ヒットされることになるので、ステップＳ１０に進み、この場合には後続パケットであるからフラグメントオフセット値は“０”ではないので、ステップＳ１５に進むことになる。
なお、このようなステップＳ１，Ｓ２，Ｓ１０，Ｓ１５の流れは後着の後続パケットの場合も同様である。
ステップＳ１５においては、デカプセル化処理を行う。これは、ステップＳ６やＳ１２と同様にアウターＩＰｖ６ヘッダ及びそのアウターフラグメントヘッダを除去するものであるが、この場合、アウターＩＰｖ６ヘッダ中のペイロード長及びアウターフラグメントヘッダ中のオフセット値を保存しておく（パケット処理部５の機能（１））。
ステップＳ１６においては、ステップＳ１１と同様に、ヒットしたインデックスに対応したヘッダ格納テーブル３のエリアからインナーＩＰｖ６ヘッダとそのインナーフラグメントヘッダを取り込む（判定・検索部２の機能（５））。
そしてステップＳ１７においては、インナーＩＰｖ６ヘッダとインナーフラグメントヘッダを付与したパケットをパケット送信部７から出力する。
この場合、インナーＩＰｖ６ヘッダは、上記のステップＳ１０１に示したようにステップＳ１５でコピーしたアウターＩＰｖ６ヘッダ中のペイロード長をインナーＩＰｖ６ヘッダ用のペイロード長に置換すると共に、インナーフラグメントヘッダにおけるオフセット値はアウターフラグメントヘッダ内のオフセット値からインナーＩＰｖ６ヘッダのヘッダ長及びインナーフラグメントヘッダのヘッダ長を引いた値を付与することになる（パケット処理部５の機能（３））。
このようにして、フラグメント化した後にカプセル化したが、フラグメントが再度発生したパターンＩにおいては、受信したフラグメントパケットのデータグラム部分はそのままで、ヘッダ部分のみを変更してパケット転送し、以って後続のノード３０でのデフラグメント化を可能にしている。
パターンＩＩの動作
図７は、本発明に係るパケット転送方法及び装置のパターンＩＩにおける動作シーケンスを示している。このパターンＩＩは、図１２に示した従来例と同様に、カプセル化の後にフラグメント化を行うものであり、図７（１）に示す元パケットを、同図（２）に示すようにカプセル化し、更に同図（３）に示すようにフラグメント化して、同図（４）に示すフラグメントパケットとしてノード１０からノード２０に送るものである。
そして、本発明に係るパケット転送方法及び装置を実現するノード２０においては、まず同図（５）に示すようにデカプセル化を行い、アウターＩＰｖ６ヘッダを除去すると共にそのフラグメントヘッダＦｒｇも除去し、同図（６）に示すように、先頭パケットのインナーＩＰｖ６ヘッダをコピーして後続パケットに付与すると共に新しいフラグメントヘッダＧｅｎ−Ｆｒｇを生成し、これをインナーＩＰｖ６ヘッダと各データグラムとの間に挿入して、同図（７）に示すようなフラグメントパケットとし、ノード装置３０に送るものである。
このようなノード２０のパターンＩＩにおける動作手順を図８に示すフローチャートに沿って以下に説明する。なお、図４のフローチャートと同一符号は同一又は相当部分を示している。従って、以下の説明では、図４と異なるステップのみについて説明する。
まずステップＳ２１が、図４に示したステップＳ１と異なる点はフラグメントＩＤがアウターフラグメントＩＤではなく単なるフラグメントＩＤである点である。これは、図３と図７とを比較すれば分かるように、図７（２）に示すカプセル化においてはフラグメントヘッダは生成する必要が無く、同図（３）に示すフラグメント化において初めてアウターＩＰｖ６ヘッダに対して生成して挿入するものであるからであり、インナーフラグメントヘッダは必要ないので、このフラグメントヘッダはアウターフラグメントヘッダとは言わずに単にフラグメントヘッダＦｒｇと称しているにすぎない。
これは、フラグメントオフセット値（Ｆｒｇ）が“０”であるか否かを判定するステップＳ２２及びＳ２７においても同様である。
ステップＳ２３においては、先着の先頭パケットに対してフラグメントＩＤ、すなわちこのフラグメントＩＤを含むフラグメントヘッダＧｅｎ−Ｆｒｇを生成する（判定・検索部２の機能（６））。これは、図７（６）に示すヘッダ生成処理において、同図（５）に示すデカプセル化により、アウターＩＰｖ６ヘッダとそのフラグメントヘッダＦｒｇが除去されることに伴い、各フラグメントパケットに対するフラグメントヘッダが無くなってしまうので、ここで、まずフラグメントＩＤを生成するのである。この場合のフラグメントＩＤはどのフラグメントパケットにおけるフラグメントヘッダにおいても同一の値である。
ステップＳ２４においては、図４のステップＳ５において、インナーフラグメントヘッダＩｎ−Ｆｒｇを保存する代わりに、ステップＳ２３で生成したフラグメントヘッダＧｅｎ−Ｆｒｇを保存する点が異なっている（判定・検索部２の機能（４））。また、ステップＳ２５においても、アウターフラグメントヘッダＯｕｔ−Ｆｒｇの代わりにフラグメントヘッダＦｒｇを除去している点のみが異なっている。
なお、このステップＳ２５においても、インナーＩＰｖ６ヘッダのペイロード長を変更するが、この場合のペイロード長は、ステップＳ２００に示す通りアウターＩＰｖ６ヘッダ内のペイロード長からインナーＩＰｖ６ヘッダのヘッダ長（４０バイト）を引いたものであり、図４のステップＳ１００のようにアウターフラグメントヘッダ（８バイト）はステップＳ２３で生成したフラグメントヘッダＧｅｎ−Ｆｒｇが対応するのでこれを引く必要はない（パケット処理部５の機能（２））。
そしてステップＳ２６においては、ステップＳ２３で生成したフラグメントヘッダＧｅｎ−Ｆｒｇを付与したパケットをノード２０のパケット送信部７からノード３０へ送出する。
一方、ステップＳ２７においては、図４のステップＳ１０と同様に後着の先頭パケットであるか否かが判別されるが、後着の先頭パケットであることが分かったときにはステップＳ２８に進む。この場合も、ステップＳ２３と同様にフラグメントＩＤを生成しこれをフラグメントヘッダＧｅｎ−Ｆｒｇに挿入する（同）。
ステップＳ２９は、ステップＳ２４に対応するものであり、ステップＳ３０はステップＳ２５に対応するものである。更にステップＳ３１はステップＳ２６に対応している。このようにして後着の先頭パケットをノード３０に送出した後、既にパケットバッファ６に格納されているパケットを読み出して図４の場合と同様にステップＳ２１に戻り同様の処理を実行する。
ステップＳ２７において後着の先頭パケットではないと判定されたとき、すなわち後着の後続パケットであることが分かったときには、既に先頭パケットが到着しているかどうかを判定する（ステップＳ３２：判定・検索部２の機能（７））。
これは、図３に示したパターンＩの場合には同図（４）に示すフラグメント化２では基本的に２つのフラグメントパケットしか発生しないのに対し、図７のパターンＩＩの場合には、同図（３）に示すように２つ以上のフラグメントパケットが発生し得るからであり、後着の後続パケットであっても、その前に到着しているパケットが先頭パケットなのか或いは後続パケットなのかが不明であるのでこのステップＳ３２でその判定を行っているためである。
従って、先頭パケットが到着していないことが分かったとき（これは、ステップＳ２３等のフラグメントＩＤの存在を確認すれば良い。）、ステップＳ９に進んでパケットバッファ６にそのパケットを格納することになるが、先頭パケットが既に到着していることが分かったときにはステップＳ３３に進む。
ステップＳ３３においては、デカプセル化が行われるが、この場合、アウターＩＰｖ６ヘッダ及びそのフラグメントヘッダＦｒｇは、除去に際して、アウターＩＰｖ６ヘッダ中のペイロード長を保存（コピー）すると共に、フラグメントヘッダＦｒｇ中のオフセット値及びＭフラグも保存しておく。この場合のＭフラグはフラグメントパケットの終了を示すものであり、パターンＩの場合は続きがあるから必要ない。
そしてステップＳ３４においては、図４のステップＳ１６と同様にヒットしたインデックスに対応したヘッダ格納テーブル４のエリアからインナーＩＰｖ６ヘッダと、ステップＳ２３又はＳ２８で生成したフラグメントヘッダＧｅｎ−Ｆｒｇを取り込む（ヘッダ格納テーブル４の機能（２））。
そして、ステップＳ３５においては、図４のステップＳ１７と同様にインナーＩＰｖ６ヘッダとフラグメントヘッダＧｅｎ−Ｆｒｇを付与して（パケット処理部５の機能（３））パケットをノード３０に送信するが、この場合のインナーＩＰｖ６ヘッダのペイロード長はステップＳ３３で保存しておいたアウターＩＰｖ６ヘッダ内のペイロード長をインナーＩＰｖ６ヘッダ用に置き換えて用いれば良く、またフラグメントヘッダＧｅｎ−Ｆｒｇ中のフラグメントオフセット値は、ステップＳ２０１に示すように、ステップＳ３３で保存しておいたフラグメントヘッダ内のオフセット値からインナーＩＰｖ６ヘッダのヘッダ長を引いたものである。
このようにしてパターンＩＩの処理においてもデカプセル化とヘッダ生成とでパケット転送を実現しており、パケットのデフラグ化を排除し、後段のノードにおいてそのデフラグメント化が可能なようにしている。
パターンＩ＋ＩＩの動作
図９は、上記のパターンＩとパターンＩＩを同時に処理可能にした場合の処理手順を示しており、以下、同一符号は図４又は図８と同様であり、これらと異なる部分のみ説明する。
まず、ステップＳ４１においては、パターンＩかパターンＩＩかを判定している（判定・検索部２の機能（８））。これは、図３（５）のフラグメントパケットと、図７（４）のフラグメントパケットとを比較すれば分かるように、パターンＩの場合にはインナーＩＰｖ６ヘッダの次にインナーフラグメントヘッダＩｎ−Ｆｒｇが存在しているのに対し、パターンＩＩの場合には存在していない点が異なっていることから、このインナーフラグメントヘッダＩｎ−ＦｒｇにおけるＮｅｘｔフィールドが“２Ｃ”（１６進数）であるか否かを判定し、Ｎｅｘｔ＝“２Ｃ”の場合にはパターンＩであり、そうでない場合にはパターンＩＩであると判定することが可能となる。
このようにステップＳ４１でパターンＩとパターンＩＩを判別した後、パターンＩの場合には、ステップＳ５〜Ｓ７を実行し、パターンＩＩの場合にはステップＳ２３〜Ｓ２６を実行する。
ただし、ステップＳ５及びＳ２４においては、ステップＳ４１で判別したパターンＩかＩＩかを示すパターン種別を、図６に示すように、ヘッダ格納テーブル４に保存しておく。
ステップＳ４１におけるパターンＩとパターンＩＩの判別はステップＳ４２においても同様に行うことができ、パターンＩであることが分かったときにはステップＳ１１〜Ｓ１３を実行し、パターンＩＩであることが分かったときにはステップＳ２８〜Ｓ３１を実行すると共に、いずれのパターンの場合もステップＳ１４に進んでバッファファ６からパケットの読出を行う。
この場合も同様に、ステップＳ１１及びＳ２９においてパターン種別を保存しておく。
一方、ステップＳ３２において後着の後続パケットに関し先頭パケットが到着済である場合の処理は、パターンＩとパターンＩＩがほぼ共通した処理を行う（パケット処理部５の機能（３））。すなわち、パターンＩの場合には、ステップＳ１５〜Ｓ１７を実行するが、ステップＳ１６とステップＳ１７の間には、ステップＳ４３が実行される。これは、ヒットしたインデックスに対応したヘッダ格納テーブル４のエリアからパターン種別を取り込む処理が必要なためである。
すなわち、ステップＳ１５ではデカプセル化を行うため、アウターＩＰｖ６ヘッダ及びアウターフラグメントヘッダＯｕｔ−Ｆｒｇを除去すると共にこの際、アウターＩＰｖ６ヘッダ内のペイロード長をコピーしておき、またパターン種別が分かっていないので、オフセット値は保存するだけにする。
そしてステップＳ１６ではヒットしたインデックスと対応したヘッダ格納テーブル４のエリアからインナーＩＰｖ６ヘッダとインナーフラグメントヘッダＩｎ−Ｆｒｇを取り込む。
そして、ステップＳ４３を実行した後、ステップＳ１７においては、パターン種別に応じてパターンＩの場合にはインナーＩＰｖ６ヘッダと、更新したフラグメントオフセット値を有するインナーフラグメントヘッダＩｎ−Ｆｒｇを付与したパケットを送信することになる。この場合の更新したオフセット値としてはアウターフラグメントヘッダＯｕｔ−Ｆｒｇ内のオフセット値からインナーＩＰｖ６ヘッダ及びインナーフラグメントヘッダＩｎ−Ｆｒｇの各ヘッダ長分を差し引いた値となる。
また、パターンＩＩの場合には、ステップＳ３３において、アウターＩＰｖ６ヘッダ内のペイロード長をコピーすると共に、やはり、パターン種別が分かっていないので、オフセット値は保存するだけにする。
そして、ステップＳ３４においてはステップＳ１６と同様の処理を行い、ステップＳ４３でパターン種別を取り込んだ後、ステップＳ３５において、この種別、すなわちパターンＩＩに応じてインナーＩＰｖ６ヘッダのペイロード長を、ステップＳ３３でコピーしたアウターＩＰｖ６ヘッダのペイロードから置換したものを用いると共に、フラグメントヘッダＧｅｎ−Ｆｒｇのオフセット値を、フラグメントヘッダＦｒｇ内のオフセット値からインナーＩＰｖ６ヘッダのヘッダ長を引いたものに更新した値を用いる。そして、ＭフラグもフラグメントヘッダＦｒｇ内のＭフラグ値をコピーした値を用い、これをパケットに付与してノード３０に送信するようにしている。
このようにして、受信するパケットがどうのようなパターンであっても自動的に判別し且つそれに対応した処理を行うことによりいずれの場合もデフラグメント化を排除した処理を実現することが可能となる。
以上の実施例においては、図５（１）に示したＩＰｖ６フレームを本発明に適用した場合を説明したが、同図（２）に示したＩＰｖ４フレームにおいても同様に適用可能である。
すなわち、ＩＰｖ４のネットワークにおいて本発明を適用する場合は、フラグメントヘッダではなく、ＩＰｖ４ヘッダ内のＩＤ（識別子）、フラグ、フラグメントオフセットを使用する。その際、下記の読み替えを行う。

また、パターンＩかパターンＩＩの判定は、先頭パケットのインナーＩＰｖ４ヘッダ内のＭＦフラグにより行い、
１（継続あり）の場合は、パターンＩ
０（継続なし）の場合は、パターンＩＩ
とすればよい。
以上説明したように本発明に係るパケット転送方法及び装置によれば、カプセル化された後にフラグメント化された受信パケットから先頭パケット及び後続パケットを検出し、この検出した先頭パケットのインナーヘッダを保存した後にデカプセル化すると共に該インナーヘッダを該デカプセル化に合わせて変更し、更に後続パケットをデカプセル化すると共に上記のように変更した先頭パケットのインナーヘッダ及び該フラグメント化に合わせたフラグメントヘッダを各パケットに付与して出力するように構成した。
従って、ギガビットクラスのインタフェースを持つネットワーク装置では、ストリーミングデータを中継するなどの目的から、ワイヤスピードでの処理能力が必須となって来ており、従来では、デフラグメント化については転送速度を犠牲にしてソフトウェアで処理するか、或いは非常に大規模メモリを持つハードウェアを用いて行っているが、本発明によるパケット転送方法及び装置を採用すると、小規模のハードウェアでワイヤスピードのデフラグメント相当処理を行うことが可能になり、今まで必要となっていたパケットの組み立て遅延を通常のパケット並みに抑えることが可能となる。

Claims (20)

1. カプセル化された後にフラグメント化された受信パケットから先頭パケット及び後続パケットを検出する第１ステップと、
   該第１ステップで検出した該先頭パケットのインナーヘッダを保存した後にデカプセル化すると共に該インナーヘッダを該デカプセル化に合わせて変更する第２ステップと、
   該後続パケットをデカプセル化すると共に該第２ステップで変更した該先頭パケットのインナーヘッダ及び該フラグメント化に対応して生成したフラグメントヘッダを各パケットに付与し出力する第３ステップと、
   を備えたことを特徴とするパケット転送方法。
2. 請求の範囲１において、
   該第１ステップは、該受信パケットが該先頭パケットであるか否かを問わずにフラグメント識別値をテーブルに登録しておき、該フラグメント識別値の登録が無ければ最初に受信したパケットであると判定するステップを含むことを特徴とするパケット転送方法。
3. 請求の範囲２において、
   該フラグメント識別値が、該先頭パケットのアウターヘッダ中の送信元アドレスとフラグメントＩＤとで構成されることを特徴とするパケット転送方法。
4. 請求の範囲２又は３において、
   該第１ステップは、該受信パケットが該先頭パケットであるか否かを、該先頭パケットのアウターフラグメントヘッダ中のフラグメントオフセット値が所定値であるか否かで判定するステップを含むことを特徴とするパケット転送方法。
5. 請求の範囲１から４のいずれか１つにおいて、
   該第１ステップが、該先頭パケットより該後続パケットを先に受信したと判定したときには、該後続パケットをバッファに格納して待機させるステップを含み、該第２ステップの後に、該後続パケットを該バッファから読み出して該第３ステップを実行する第４ステップをさらに有することを特徴とするパケット転送方法。
6. 請求の範囲１において、
   該第１ステップは、該先頭パケットが、該カプセル化の前にフラグメント化したことを示すフラグメントヘッダを含んでいるか否かでパターンＩに該当するか、又はパターンＩＩに該当するかを判定するステップを含み、該パターンＩと判定されたとき、該第２ステップを実行させ、該パターンＩＩと判定されたとき、該先頭パケットに対するフラグメントヘッダを生成してから該第２ステップを実行させる第５ステップをさらに有し、該第３ステップが、該フラグメントヘッダ中のフラグメントオフセット値を、該パターンの種別に応じて該デカプセル化前の値から該後続パケットに対するヘッダ長分だけ減算した値にするステップを含むことを特徴とするパケット転送方法。
7. 請求の範囲６において、
   該第２ステップで該インナーヘッダを保存するとき、該パターンＩであれば、該先頭パケットのフラグメントオフセット値も保存し、該パターンＩＩであれば該生成したフラグメントオフセット値を保存し、いずれのパターンにおいても、これらのフラグメントオフセット値に基づいて該第３ステップで、該フラグメント化に合わせたフラグメントオフセット値を該後続パケットに付与することを特徴とするパケット転送方法。
8. 請求の範囲６又は７において、
   該第３ステップは、該パターンが該パターンＩのとき、該先頭パケットのフラグメントオフセット値を、そのアウターフラグメントヘッダ中のフラグメントオフセット値からインナーヘッダ及びそのフラグメントヘッダの各データ長を減算した値に変更し、該パターンＩＩのときは、該アウターフラグメントヘッダ中のフラグメントオフセット値からインナーヘッダのデータ長を減算した値に変更して該後続パケットに付与するステップを含むことを特徴とするパケット転送方法。
9. 請求の範囲８において、
   該第３ステップで変更するインナーヘッダが、該パターンＩのときは該アウターヘッダ内のペイロード長から該アウターフラグメントヘッダ及び該インナーヘッダの各データ長を引いた値であり、該パターンＩＩのときは該アウターヘッダ内のペイロード長から該インナーヘッダのデータ長を引いた値であることを特徴とするパケット転送方法。
10. 請求の範囲１から９のいずれか１つにおいて、
    該受信パケットが、ＩＰトンネルを経由したＩＰｖ６又はＩＰｖ４パケットであることを特徴とするパケット転送方法。
11. カプセル化された後にフラグメント化された受信パケットから先頭パケット及び後続パケットを検出する第１手段と、
    該第１手段で検出した該先頭パケットのインナーヘッダを保存した後にデカプセル化すると共に該インナーヘッダを該デカプセル化に合わせて変更する第２手段と、
    該後続パケットをデカプセル化すると共に該第２手段で変更した該先頭パケットのインナーヘッダ及び該フラグメント化に合わせたフラグメントヘッダを各パケットに付与し出力する第３手段と、
    を備えたことを特徴とするパケット転送装置。
12. 請求の範囲１１において、
    該第１手段は、該受信パケットが該先頭パケットであるか否かを問わずにフラグメント識別値をテーブルに登録しておき、該フラグメント識別値の登録が無ければ最初に受信したパケットであると判定する手段を含むことを特徴とするパケット転送装置。
13. 請求の範囲１２において、
    該フラグメント識別値が、該先頭パケットのアウターヘッダ中の送信元アドレスとフラグメントＩＤとで構成されることを特徴とするパケット転送装置。
14. 請求の範囲１２又は１３において、
    該第１手段は、該受信パケットが該先頭パケットであるか否かを、該先頭パケットのアウターフラグメントヘッダ中のフラグメントオフセット値が所定値であるか否かで判定する手段を含むことを特徴とするパケット転送装置。
15. 請求の範囲１１から１４のいずれか１つにおいて、
    該第１手段が、該先頭パケットより該後続パケットを先に受信したと判定したときには、該後続パケットをバッファに格納して待機させる手段を含み、該第２手段の処理を実行した後に、該後続パケットを該バッファから読み出して該第３手段の処理を実行する第４手段をさらに有することを特徴とするパケット転送装置。
16. 請求の範囲１１において、
    該第１手段は、該先頭パケットが、該カプセル化の前にフラグメント化したことを示すフラグメントヘッダを含んでいるか否かでパターンＩに該当するか、又はパターンＩＩに該当するかを判定する手段を含み、該パターンＩと判定されたとき、該第２手段の処理を実行させ、該パターンＩＩと判定されたとき、該先頭パケットに対するフラグメントヘッダを生成してから該第２手段の処理を実行させる第５手段をさらに有し、該第３手段が、該フラグメントヘッダ中のフラグメントオフセット値を、該パターンの種別に応じて該デカプセル化前の値から該後続パケットに対するヘッダ長分だけ減算した値にする手段を含むことを特徴とするパケット転送装置。
17. 請求の範囲１６において、
    該第２手段で該インナーヘッダを保存するとき、該パターンＩであれば、該先頭パケットのフラグメントオフセット値も保存し、該パターンＩＩであれば該生成したフラグメントオフセット値を保存し、いずれのパターンにおいても、これらのフラグメントオフセット値に基づいて該第３手段で、該フラグメント化に合わせたフラグメントオフセット値を該後続パケットに付与することを特徴とするパケット転送装置。
18. 請求の範囲１６又は１７において、
    該第３手段は、該パターンが該パターンＩのとき、該先頭パケットのフラグメントオフセット値を、そのアウターフラグメントヘッダ中のフラグメントオフセット値からインナーヘッダ及びそのフラグメントヘッダの各データ長を減算した値に変更し、該パターンＩＩのときは、該アウターフラグメントヘッダ中のフラグメントオフセット値からインナーヘッダのデータ長を減算した値に変更して該後続パケットに付与する手段を含むことを特徴とするパケット転送装置。
19. 請求の範囲１８において、
    該第３手段で変更するインナーヘッダが、該パターンＩのときは該アウターヘッダ内のペイロード長から該アウターフラグメントヘッダ及び該インナーヘッダの各データ長を引いた値であり、該パターンＩＩのときは該アウターヘッダ内のペイロード長から該インナーヘッダのデータ長を引いた値であることを特徴とするパケット転送装置。
20. 請求の範囲１１から１９のいずれか１つにおいて、
    該受信パケットが、ＩＰトンネルを経由したＩＰｖ６又はＩＰｖ４パケットであることを特徴とするパケット転送装置。

Images