JP2009130853A - パケットリアセンブル装置およびプログラム - Google Patents

Abstract

【課題】ＭＴＵの制約により断片化されたパケットのリアセンブル処理に必要なリソースの再配分を適切かつ迅速に行う。
【解決手段】リアセンブル中のパケットのデータを一時的に格納するバッファのアドレス等をそれぞれが有するリアセンブル管理テーブル２０内の複数の登録エントリを、パケットの断片が最後に受信された順にポインタ２８，３０で連結し、この連結を維持する。リソース再配分のためにデータを廃棄する必要が生じたとき、先頭エントリポインタ３６がポイントするエントリが示すデータを廃棄する。
【選択図】図３

Description

本発明は、通信路を通過するパケットの最大サイズ（ＭＴＵ：Maximum Transmission Unit）の制約等により複数の断片に断片化されたパケットをリアセンブルするパケットリアセンブル装置およびそれをコンピュータに実現させるプログラムに関する。

近年のインターネット普及に伴う通信量の著しい増加により、通信機器（例えば移動通信システムの基地局および移動機）でのデータ受信において、受信バッファ等のリソース不足が懸念される。

特に通信路を通過するパケットの最大サイズの制約等により、複数の断片に断片化されたパケットのリアセンブル処理では、断片が全て揃いリアセンブルが完了するまでリアセンブル処理用リソース（メモリ領域）を確保したままであり、リソース不足に陥りやすい。また、通信路の途中で断片が欠落した場合は、リアセンブル完了待ち期限を経過し処理を中止するまでリアセンブル処理用リソースを解放しないため、無意味なリソース保持が生じる。

リアセンブル処理用リソースを使いきった状態から、さらに断片を受信した場合、通常、新しく到着した断片を廃棄することになるが、前述したような断片欠落などのためにリアセンブルを完了することができないパケットのための無意味なリソース保持が生じ得ることを考えると、効率的な通信とは言えない。

下記特許文献１，２には、パケットのリアセンブル処理に関するものではないが、到着時刻の古いパケットを廃棄することが記載されている。

特開２００３−１３４１５６号公報 特開２０００−１６５４４７号公報 特開２００３−２２９９００号公報

したがって本発明の目的は、パケットのリアセンブル処理におけるリソースの管理を適切に行うことにある。

上記の課題は、リアセンブル中のパケットの断片のデータをパケットごとに格納して結合するデータ結合バッファと、リアセンブル中のパケットにそれぞれ対応する複数のエントリを格納するリアセンブル管理テーブルと、該データ結合バッファと該リアセンブル管理テーブルを用いてパケットの断片を結合し、データ結合バッファ内のデータのいずれかをリアセンブル途中で廃棄すべきとき、最後に断片を受け取った時刻が最も古いパケットのデータを廃棄するリアセンブル処理ブロックとを具備するパケットリアセンブル装置により達成される。

最後に断片を受信した時刻が最も古いパケットについては、長時間、断片を受信していないことから、断片欠落によりリアセンブルを完了することができないパケットであるものと推測することができる。したがってそのようなパケットのリアセンブル処理を中止し、当該リソースを解放したうえで、新しく到着した断片のリアセンブル処理にリソースを再配分することで、パケットのリアセンブル処理におけるリソースの管理を適切に行うことができる。

前述の装置において、前記リアセンブル処理ブロックは、前記リアセンブル管理テーブル内の複数のエントリを、対応するパケットの断片が最後に受け取られた順に連結し、かつ、この連結を維持し、データ結合バッファ内のデータのいずれかをリアセンブル途中で廃棄すべきとき、連結の先頭のエントリが示すデータを廃棄するように構成することが好ましい。

最後に断片を受け取った時刻が最も古いパケットを決定するには、パケット毎に最後に断片を受け取った時刻を記憶し、それらを比較することになる。しかしながら、リアセンブル処理中のパケットが多量である場合、それらのそれぞれについて最後に断片を受け取った時刻を取得し、相互に比較して廃棄すべきパケットを決定する処理に時間を要することになり、これは伝送遅延につながる可能性がある。そこで、上記のように、リアセンブル管理テーブル内の各エントリをパケットの断片が最後に受け取られた時刻の順に連結し、連結の先頭のエントリが示すデータを廃棄するように構成することでリソース再配分の処理を短時間で完了することができる。

図１は本発明の一実施形態に係るパケットリアセンブル装置の構成の一例を示す。このパケットリアセンブル装置は、例えば、移動通信システムの基地局および移動機において、無線区間のＭＴＵ（Maximum Transmission Unit）の制限のために断片化されたパケットの断片を結合して元のパケットを復元するために設けられる。

図１において、受信部１０から出力されるパケットはＡ₁，Ａ₂，・・・；Ｂ₁，Ｂ₂・・・のように分割（断片化）されており、リアセンブル処理ブロック１２がこれらを結合（リアセンブル）してパケットＡ，Ｂ・・・を復元し、アプリケーション１４へ渡す。リアセンブル処理ブロック１２は、リアセンブルが完了するまで、受信されたパケットの断片のデータをメモリ１６上のデータ結合用バッファ領域１８に格納し、その格納アドレス、受信済バイト数等は、同じくメモリ１６上のリアセンブル管理テーブル２０に格納される。

図２は本発明の第１の実施形態に係るパケットリアセンブル装置における、メモリ１６上のリアセンブル管理テーブル２０とデータ結合用バッファ領域１８の構成の一例を示す。

データ結合用バッファ領域１８には、矢印１９で示すようにリアセンブル処理中のパケット毎に受信済のパケットのデータが順次格納され、元のパケットが復元される。データ結合用バッファ領域１８に必要なメモリ領域はパケットの断片が受信されるごとに必要に応じてハントされる。

リアセンブル管理テーブル２０には、予め定められた数のエントリ（図示した例ではエントリ０〜エントリ９９の１００個のエントリ）が用意されている。各エントリは、矢印２３で示すように、それに対応するリアセンブル処理中パケットのデータが格納されているバッファのアドレス２２と、リアセンブル処理用の情報（パケット長、受信済バイト数）２４と、断片最終受信時刻２６を保持する。リアセンブル管理テーブル２０の各エントリへのアクセスは、矢印２５で示すように、受信パケットに含まれる、各パケットにユニークな要素（例えば、ＩＰプロトコルが使用されている場合、発信元および宛先のＩＰアドレス、パケットの識別子など）から０〜９９のハッシュ値を計算することにより行なわれる。

すなわち、リアセンブル管理テーブル２０は一種のハッシュテーブルである。異なるパケットから計算されるハッシュ値が同じ値である場合、すなわちハッシュ値の衝突が発生した場合には、二重ハッシュ法などの周知の手法でこれを回避することができる。

リアセンブル管理テーブル２０については、上記の構成に限られず、例えば、新たなパケットのリアセンブルが開始されるごとにテーブルの先頭から順に空き領域を見付け出してエントリを登録する構成も可能である。しかしながら、エントリの数が多量にある場合に、アクセスに時間を要することになる。

図２に示した第１の実施形態においては、リアセンブル管理テーブル２０の各エントリが断片最終受信時刻２６を保持しているので、リソースを再配分する必要が生じた時には、これらを比較することにより最後に断片を受信した時刻が最も古いものを決定してそのデータを廃棄することができる。

しかしながら、リアセンブル処理中のパケットが多量にある場合、それらのそれぞれについて断片最終受信時刻を取得し、相互に比較する処理には時間を要することになり、伝送遅延につながる可能性がある。

図３は、この点を解決した、本発明の第２の実施形態に係るパケットリアセンブル装置における、リアセンブル管理テーブル２０の構成の一例を示す。データ結合用バッファ領域１８については図示が省略されている。

図３に示したリアセンブル管理テーブル２０の各エントリは、図２の断片最終受信時刻２６を保持する代わりに、前エントリポインタ２８および次エントリポインタ３０を保持することでチェーンで連結されている。新たに設けられるチェーン管理テーブル３２はチェーンの先頭を示す先頭エントリポインタ３４とチェーンの末尾を示す末尾エントリポインタ３６を保持している。リアセンブル管理テーブル２０のすべての登録エントリは、断片最終受信時刻の順にチェーンで連結されており、チェーン管理テーブル３２の先頭エントリポインタ３４はチェーンの先頭を示している。したがって、先頭エントリポインタ３４が示すエントリが断片最終受信時刻が最も古いエントリとなるので、リソースを再配分する必要が生じた際には、先頭エントリポインタ３４が示すチェーンの先頭のエントリが示すリアセンブル中パケットのデータを廃棄してリソースを再配分することにより、適切なリソース管理を短時間で達成することができる。

なお、図３では、図を簡潔にするため、リアセンブル管理テーブル２０のエントリ０がチェーン先頭のエントリ、エントリ９９がチェーン末尾のエントリになっているが、実際には、エントリの格納装置（０〜９９の番号）は、ＩＰアドレス、識別番号などの、パケットに含まれるユニークな要素から計算され、各エントリはパケットの断片最終受信時刻の順に連結されるので、必ずしもこのようになるとは限らない。

以下、上記のようなチェーンを維持しつつエントリを追加・更新・削除する操作手順を具体的に説明する。

図４は、リアセンブル中のパケットがない状態（初期状態）において、断片を受信したときのチェーン操作を説明する図である。パケットに含まれるユニークな要素から計算される０〜９９のハッシュ値をＩとすると、前エントリポインタ２８および次エントリポインタ３０がいずれもＮｕｌｌに設定されたエントリＩが登録され、チェーン管理テーブル３２の先頭エントリポインタ３４と末尾エントリポインタ３６はいずれもこのエントリＩをポイントするように変更される。

図５は、図４の状態において、ハッシュ値Ｊのパケットの断片を新たに受信したときのチェーン操作を示す。この場合、エントリＪが新たに登録され、これをチェーンの末尾とするため、エントリＪの前エントリポインタは以前チェーンの末尾であったエントリＩをポイントするように設定され、次エントリポインタはＮｕｌｌと設定される。以前チェーンの末尾であったエントリＩの次エントリポインタはＮｕｌｌからＪに変更され、チェーン管理テーブル３２の末尾エントリポインタ３６はＩからＪに変更される。

図６は、図３に示す状態において、新たな断片の受信により、チェーンの途中に位置するエントリＮが示すパケットのリアセンブルが完了したときのチェーン操作を示す。この場合には、エントリＮをチェーンから外すために、エントリＮの前エントリポインタが示すエントリＮ−１の次エントリポインタをＮからエントリＮの次エントリポインタであるＮ＋１に変更し、エントリＮの次エントリポインタが示すエントリＮ＋１の前エントリポインタをＮからエントリＮの前エントリポインタであるＮ−１に変更する。チェーン管理テーブル３２の先頭エントリポインタ３４と末尾エントリポインタ３６は変更されない。

図７は、図３の状態において、チェーンの先頭に位置するエントリ０が示すパケットのリアセンブルが完了したときのチェーン操作を示す。この場合には、先頭エントリポインタ３４が０からエントリ０の次エントリであった１に変更され、エントリ１の前エントリポインタが０からＮｕｌｌに変更される。

図８は、図３の状態において、チェーンの末尾に位置するエントリ９９が示すパケットのリアセンブルが完了したときのチェーン操作を示す。この場合には、チェーン管理テーブルの末尾エントリポインタ３６が９９からエントリ９９の前エントリであった９８に変更され、エントリ９８の次エントリポインタが９９からＮｕｌｌに変更される。

図９は、図３に示す状態において、チェーンの途中に位置するエントリＮが示すパケットの断片を受信したが、それによってもリアセンブルが完了しない場合のチェーン操作を示す。この場合には、エントリＮをいったんチェーンから外してチェーン末尾に再接続するチェーン操作が行なわれる。すなわち図９において、エントリＮをいったんチェーンから外すために、エントリＮの前エントリであったエントリＮ−１の次エントリポインタが、Ｎから、エントリＮの次エントリであったＮ＋１に変更され、エントリＮの次エントリであったエントリＮ＋１の前エントリポインタが、Ｎから、エントリＮの前エントリであったＮ−１に変更される、次に、エントリＮをチェーンの末尾に再接続するため、末尾エントリであったエントリ９９の次エントリポインタがＮｕｌｌからＮに変更され、エントリＮの前エントリポインタがＮ−１から９９に変更され、次エントリポインタがＮ＋１からＮｕｌｌに変更される。そして、チェーン管理テーブル３２の末尾エントリポインタ３６は９９からＮに変更される。

図１０は、図３に示す状態において、チェーン先頭のエントリ０が示すパケットの断片を受信したが、それによってもリアセンブルが完了しない場合のチェーン操作を示す。この場合にも同様にエントリ０をいったんチェーンから外し、チェーン末尾に再接続する。チェーン管理テーブル３２の先頭エントリポインタ３４は０から１に変更され、末尾エントリポインタ３６は９９から０に変更される。

チェーン末尾のエントリのパケットの断片が受信され、それによってもリアセンブルが完了しない場合には、チェーン操作は行なわれない。

以上の操作により、リアセンブル管理テーブル内の各登録エントリは、断片が最後に受信された時刻（断片最終受信時刻）の順に連結され、この連結は常に維持されるので、チェーン管理テーブルの先頭エントリポインタは断片最終受信時刻が最も古いエントリを常にポイントしており、このようなエントリを廃棄の対象とするリソース再配分処理を迅速に達成することができる。

上記のような処理とそれに用いるデータの構造は、コンピュータと、コンピュータにこれらを実現させるべくプログラムされたソフトウェアにより実現することができる。

本発明の一実施形態に係るパケットリアセンブル装置の構成を示すブロック図である。 本発明の第１の実施形態に係るパケットリアセンブル装置におけるメモリ上のデータの構成の一例を示す図である。 本発明の第２の実施形態におけるリアセンブル管理テーブル２０の構成の一例を示す図である。 パケット断片を最初に受信したときのチェーン操作を説明する図である。 ２つ目のパケット断片を受信したときのチェーン操作を説明する図である。 図３の状態において、新たな断片の受信によりチェーン途中のエントリＮのパケットのリアセンブルが完了したときのチェーン操作を説明する図である。 チェーンの先頭に位置するエントリのパケットのリアセンブルが完了したときのチェーン操作を説明する図である。 チェーンの末尾に位置するエントリのパケットのリアセンブルが完了したときのチェーン操作を説明する図である。 チェーン途中のエントリＮのパケット断片が受信され、それによってもリアセンブルが完了しないときのチェーン操作を説明する図である。 チェーン先頭のエントリ０のパケット断片が受信され、それによってもリアセンブルが完了しないときのチェーン操作を説明する図である。

Claims (5)

1. リアセンブル中のパケットの断片のデータをパケットごとに格納して結合するデータ結合バッファと、
   リアセンブル中のパケットにそれぞれ対応する複数のエントリを格納するリアセンブル管理テーブルと、
   該データ結合バッファと該リアセンブル管理テーブルを用いてパケットの断片を結合し、データ結合バッファ内のデータのいずれかをリアセンブル途中で廃棄すべきとき、最後に断片を受け取った時刻が最も古いパケットのデータを廃棄するリアセンブル処理ブロックとを具備するパケットリアセンブル装置。
2. 前記リアセンブル処理ブロックは、前記リアセンブル管理テーブル内の複数のエントリを、対応するパケットの断片が最後に受け取られた順に連結し、かつ、この連結を維持し、データ結合バッファ内のデータのいずれかをリアセンブル途中で廃棄すべきとき、連結の先頭のエントリが示すデータを廃棄する請求項１記載の装置。
3. 前記リアセンブル管理テーブル内の各エントリの格納位置は、パケットに含まれるパケット毎にユニークな要素から決定される請求項１または２記載の装置。
4. 前記リアセンブル管理テーブル内の各エントリは、対応するリアセンブル中パケットについての全データ長および格納済データ長を含む請求項１〜３のいずれか１項記載の装置。
5. コンピュータに請求項１〜４のいずれか１項記載の装置を実現させるプログラム。

Images