JP5300355B2 - ネットワークプロトコル処理装置及びその処理方法 - Google Patents

Description

本発明は、フラグメント化されたＩＰデータグラムを受信してリアセンブル処理を行うネットワークプロトコル処理装置及びその処理方法に関する。

従来より、ネットワークプロトコル処理の一環として、フラグメント化されたＩＰデータグラムのリアセンブル処理が行われている。尚、ＩＰデータグラムのフラグメント処理方法及びリアセンブル処理方法に関しては、RFC791 Internet Protocolに記載されている。このRFC791では、リアセンブル処理の例として、フラグメントブロックビットテーブル（以下、ビットテーブルと称す）によるリアセンブル処理方法が紹介されている。ここで、ビットテーブルを利用したリアセンブル処理では、8192ビットサイズのビットテーブルが必要となる。

これは、フラグメント処理前のＩＰデータグラムの最大ペイロードサイズが６４Ｋバイトであること、及びＩＰデータグラムが８バイト単位でフラグメント化が可能であることに起因する。つまり、６４Ｋバイトのペイロードを持つＩＰデータグラムを最小のペイロードサイズである８バイトのペイロードを持つＩＰデータグラムに分割して送信する場合、8192（＝６４Ｋバイト÷８バイト）個のＩＰデータグラムに分割される。

従って、フラグメント化されたＩＰデータグラムの受信状況を管理するためには、8192ビットサイズのビットテーブルが必要となる。

そこで、予めフラグメント処理前のＩＰデータグラムのペイロードサイズが明らかであれば、ＩＰデータグラムの最大ペイロードサイズである６４Ｋバイト分のビットテーブルを準備する必要がないと考えられる。しかしながら、RFC791で規定されているＩＰデータグラムのヘッダには、フラグメントに関連する情報として以下の２つのフィールドが付随されているだけである。
（１）ＦＯ（Fragment Offset）：フラグメント処理前のＩＰデータグラムのペイロードのオフセット。
（２）ＭＦ（More Fragment flag）：後続のフラグメントパケットが存在するか否かを示すフラグ。

よって、フラグメント化された終端のＩＰデータグラムのＩＰヘッダのＭＦはセットされていないが、それ以外の全てのフラグメント化されたＩＰデータグラムのＩＰヘッダのＭＦはセットされている。つまり、フラグメント化された終端のＩＰデータグラムを受信しない限り、フラグメント前のＩＰデータグラムのペイロードサイズを判別することはできない。そのため、ビットテーブルは、ＩＰデータグラムの最大ペイロードサイズである６４Ｋバイト分準備しなければならない。

一方、予めフラグメント処理時に分割されるペイロードサイズが明らかであれば、８バイト単位のビットテーブルを準備する必要がないと考えられる。しかしながら、ＩＰデータグラムの送信機器と受信機器の間には、様々なルータとルータを接続する通信網が存在しており、その中のどの経路を使用してＩＰデータグラムが送信されるかは不明であり、またそれを制御することもできない。つまり、何れのルータでもフラグメント処理される可能性のあるＩＰデータグラムは、受信機器にどのようなサイズにフラグメント化されて到着するかを知る術はない。従って、ビットテーブルは、フラグメント処理で分割される最小ペイロードサイズである８バイト単位で準備しなければならない。

尚、特許文献１に、フラグメントパケットの順番で番号を振り、その番号とビット位置を対応つけたビットマップで再組立て状態を管理することが記載されている。
特開2007-274056号公報

上記従来のビットテーブルは、ペイロードサイズが６４Ｋバイトに満たないＩＰデータグラムを受信する場合でも、8192ビットサイズ分確保しなければならない。また、フラグメント化されたＩＰデータグラムのペイロードサイズが、例えば１Ｋバイトで統一されている場合でも、８バイト単位のビットテーブルを確保しなければならない。

この制約は、ペイロードサイズが６４Ｋバイトより小さいＩＰデータグラムや、フラグメント処理時のペイロードサイズが固定であるＩＰデータグラムを受信する場合、ビットテーブルの領域が無駄に確保されてしまう。特に、組み込みシステムなどのメモリサイズが限られているプラットフォームでは、システム全体のパフォーマンス低下や、システム構築時のコストの増加が懸念される。特に、リアセンブル処理はネットワークプロトコル処理において処理負荷の重いものに数えられる。そのため、ビットテーブルの領域は高価であるが高速なＳＲＡＭ等で実装されることもある。この場合には、コストの増加の問題はより甚大なものとなることが想定される。

本発明は、リアセンブル処理に必要なビットマップテーブルのサイズを削減することを目的とする。

本発明は、フラグメント化されたＩＰデータグラムを受信してリアセンブル処理するネットワークプロトコル処理装置であって、
受信したフラグメント化されたＩＰデータグラムのサイズに基づいて前記リアセンブル処理に用いるビットマップテーブルの単位サイズを決定する決定手段と、
前記決定手段によって決定された単位サイズに応じてビットマップテーブルを生成する生成手段と、
前記生成手段によって生成されたビットマップテーブルを用いて前記ＩＰデータグラムをリアセンブル処理する処理手段と、
を有することを特徴とする。

また、本発明は、フラグメント化されたＩＰデータグラムを受信してリアセンブル処理するネットワークプロトコル処理装置の処理方法であって、
決定手段が、受信したフラグメント化されたＩＰデータグラムのサイズに基づいて前記リアセンブル処理に用いるビットマップテーブルの単位サイズを決定する決定工程と、
生成手段が、前記決定工程において決定された単位サイズに応じてビットマップテーブルを生成する生成工程と、
処理手段が、前記生成工程において生成されたビットマップテーブルを用いて前記ＩＰデータグラムをリアセンブル処理する処理工程と、
を有することを特徴とする。

本発明によれば、リアセンブル処理に必要なビットマップテーブルのサイズを削減することが可能となる。

以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。

図１は、本実施形態におけるネットワークプロトコル処理装置の構成の一例を示すブロック図である。図１において、１０１はＣＰＵであり、後述するＲＯＭに格納された制御プログラム（ソフトウェア）に従ってＴＣＰ／ＩＰネットワークのプロトコル処理を実行する。１０２はＲＯＭであり、ＣＰＵ１０１が実行するソフトウェアが格納されている。１０３はＲＡＭであり、ＣＰＵ１０１がプロトコル処理を実行時に、ワークエリアとして使用される。

１０４はＭＡＣ（メディアアクセス制御）であり、ＯＳＩ参照モデルの第２層に相当するデータリンク層の一部である通信プロトコルである。１０５はＰＨＹ（物理層）であり、ＯＳＩ参照モデルの第１層に相当するプロトコル処理及び電気信号を扱うハードウェアである。１０６はＤＭＡＣ（Direct Memory Access Controller）であり、ＴＣＰ／ＩＰネットワーク通信で送受信するデータのＲＡＭ１０３とＭＡＣ１０４との間の転送を管轄する。１０７はバスであり、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、ＭＡＣ１０４、ＤＭＡＣ１０６を相互接続する。

尚、ＲＡＭ１０３は安価なＤＲＡＭ（オフチップ）で実現される場合が一般的であるが、より高速なオンチップＳＲＡＭで実現しても良い。しかし、オンチップＳＲＡＭは高価である。そのため、本実施形態で想定しているＲＡＭ１０３に格納するデータ全てを格納可能なサイズ分を搭載するのは難しい可能性もある。このような場合には、安価であるが低速なＤＲＡＭと、高価であるが高速なオンチップＳＲＡＭとの組み合わせで実現するのが適切である。

即ち、頻繁にアクセスするデータやネットワークプロトコル処理性能に大きく影響するデータなどを高速なオンチップＳＲＡＭに配置し、その他のデータをＤＲＡＭに配置するという形態である。本実施形態は、ＤＲＡＭ及びオンチップＳＲＡＭ、その他の記憶媒体の何れで実現されても良く、全てを包含しＲＡＭ１０３と呼ぶこととする。

ここで、ＲＡＭ１０３は、ＣＰＵ１０１のワークエリアとして使用されるだけでなく、ＴＣＰ／ＩＰネットワークプロトコル処理の実行時に必要となるデータの格納領域としても使用される。そのデータには、ＴＣＰ／ＩＰネットワーク通信で送受信されるデータ、フラグメントブロックビットテーブル、フラグメントブロックビットテーブル管理情報のテーブルなどが含まれる。

尚、このフラグメントブロックビットテーブルをビットテーブルと呼び、フラグメントブロックビットテーブル管理情報のテーブルを管理テーブルと呼ぶ。また、管理テーブルに格納される各ビットテーブルの管理情報を管理エントリと呼ぶ。このビットテーブルはビットマップテーブルとも呼ばれる。

図２は、ＲＡＭ１０３内のデータを模式的に表した図である。図２では、本発明を説明するために必要なデータのみを示し、ネットワークプロトコル処理を実現するために必要なデータは他にも存在するが、図示していない。不図示のデータは、例えばＣＰＵ１０１が処理するワークデータや送信ＩＰデータグラム本体などのデータである。

図２において、２０１は受信データ領域であり、受信したＩＰデータグラムは一旦この領域２０１に格納される。２０２は管理テーブルであり、各ビットテーブルの管理情報である管理エントリが格納される。管理エントリは、関連付けられたビットテーブルと共に、主にリアセンブル処理の開始時に生成され、リアセンブル処理終了まで、リアセンブル処理対象のＩＰデータグラムの情報を保持する。

２０３はビットテーブル領域であり、ビットテーブル本体が格納される。全てのビットテーブルは、所定の管理エントリに１対１で関連付けられている。２０４はリアセンブルバッファであり、リアセンブル処理中のＩＰデータグラムのペイロードデータが格納される。

尚、このリアセンブルバッファ２０４には、リアセンブル処理中のＩＰデータグラムのペイロードデータが格納されるが、その格納方法には様々な選択肢がある。リアセンブル処理中のペイロードデータは、フラグメント前のペイロードデータに対して先頭から順番に到着する訳ではない。また、既に到着しているペイロードデータに重複したペイロードデータが後から到着することも考えられる。

そのため、一般的な格納方法としては、フラグメント前の最大ペイロードデータサイズである６４Ｋバイト分のデータ領域をリアセンブル処理開始時に確保する。そして、受信したＩＰデータグラムのペイロードデータを適宜対応する部分に格納していくという方法がある。

また、他の格納方法としては、リンクリストを活用する方法もある。このリンクリストとは、細切れで格納されているデータに対し、所定のデータの後に続くデータの格納場所を示すリスト情報を別途管理することで、仮想的に一続きのデータに見せるという方法である。この方法のメリットは、予め６４Ｋバイトという大きいデータ領域を確保することなく、到着したＩＰデータグラムを順番に関係なく空いている領域に格納していけば良いということである。この方法によれば、例えばフラグメント前のペイロードサイズが１Ｋバイトであった場合などは、６４Ｋバイトものデータ領域を確保する必要が無く、メモリ領域を有効に活用できる。

一般的に、前者の方法は主にハードウェアでリアセンブル処理を行う場合に用いられ、後者の方法はソフトウェアでリアセンブル処理を行う場合に用いられている。

尚、リアセンブルバッファの管理方法は本発明には直接関係しないため、何れの方法でも、上述の方法以外でも最終的にフラグメント前のペイロードデータを再生成可能な方法であれば良く、その詳細は割愛する。

次に、管理テーブル２０２内の管理エントリと、ビットテーブル領域２０３内のビットテーブルの関係を、図３及び図４を用いて説明する。

図３は、管理テーブル２０２に格納されている管理エントリを詳細に示した図である。図３において、３０１は送信元アドレスであり、受信されたＩＰヘッダに格納されている送信元アドレス（Source Address）フィールドの値に一致する。３０２は宛先アドレスであり、同じくＩＰヘッダの宛先アドレス（Destination Address）に一致する。３０３は識別子であり、同じくＩＰヘッダの識別子（Identification）に一致する。

送信元アドレス３０１、宛先アドレス３０２、識別子３０３の各情報は、リアセンブル処理対象のＩＰデータグラムを特定するために使用される。これは、ＩＰデータグラムが送信元の機器やルータによってフラグメント化される場合、フラグメント前のＩＰデータグラムの３フィールドがフラグメント後のＩＰデータグラムのＩＰヘッダの３フィールドにコピーされるためである。

そのため、受信機器では、上述の３フィールドが同一であるＩＰデータグラムに対してリアセンブル処理を行わなければならず、３フィールドが一致しないＩＰデータグラムのリアセンブル処理は、別々の処理として実施しなければならない。

本実施形態では、複数のＩＰデータグラムに対するリアセンブル処理を並列に行うことを想定している。そこで、管理エントリは、関連付けられたビットテーブルが何れのＩＰデータグラムのリアセンブル処理に使用されているかを特定するために、３フィールドの情報を保持している。

３０４はビットテーブル単位サイズであり、関連付けられたビットテーブルの１ビットが何バイトに相当しているかを示す情報である。３０５はビットテーブルポインタであり、この管理エントリに関連付けられたビットテーブル領域２０３の格納先アドレスを示す情報である。

図４は、ビットテーブル領域２０３に格納されているビットテーブルを詳細に示した図である。図４において、４０１は初期化時のビットテーブル本体であり、４０２は所定のリアセンブル処理中のビットテーブル本体である。ビットテーブルのビット４０１−１〜４０１−５、４０２−１〜４０２−５は、それぞれペイロードデータが受信済みか否かを示し、“１”がセットされている場合は受信済みを示す。これに対して、“０”がセットされている場合は未受信であることを示す。また、ビットテーブルの初期化時は、全てのペイロードデータが未受信であるため、全ビットが“０”にセットされている。

以下、ビットテーブル単位サイズ３０４とビットテーブルの関係を説明する。尚、管理エントリのビットテーブル単位サイズ３０４を１Ｋバイト（＝１０２４バイト）とする。また、管理エントリに関連付けられたビットテーブル（ビットテーブルポインタ３０５が示す格納先アドレスのビットテーブル）を図４に示す４０２の処理中とする。この処理中４０２における４０２−１〜４０２−５は、それぞれ１Ｋバイト分のペイロードデータに対応する。

処理中４０２において、４０２−１は“１”がセットされているので、フラグメント前のＩＰデータグラムのペイロードの内、先頭から１Ｋバイト分のデータが既に受信されていることを示す。また、４０２−４も“１”がセットされているので、フラグメント前のＩＰデータグラムのペイロードの内、先頭からのオフセット３Ｋバイトからの１Ｋバイト分のデータが既に受信されていることを示す。

一方、４０２−２は“０”がセットされているので、フラグメント前のＩＰデータグラムのペイロードの内、先頭からのオフセット１Ｋバイトの１Ｋバイト分のデータが未受信であることを示す。４０２−３、４０２−５も４０２−２と同様に、該当するオフセットの１Ｋバイト分のデータがまだ受信されていないことを示す。

次に、管理エントリ及びビットテーブルに対する処理内容を、図５〜図８を用いて説明する。管理エントリ及びビットテーブルに対して行う処理は、以下の４つである。また、これらの処理は、ＣＰＵ１０１によって実行される。
＜リアセンブルリセット処理＞リアセンブル処理開始時と、ビットテーブルの単位サイズの変更時に、管理エントリ及びビットテーブルを初期化する
＜リアセンブル通常処理＞フラグメント化されたＩＰデータグラムの受信時に、当該ＩＰデータグラムのペイロードに基づいてビットテーブルの状態を更新する
＜リアセンブルターミネート処理＞リアセンブル処理終了時に、管理エントリ及びビットテーブルを解放する
＜ビットテーブル移行処理＞ビットテーブルの単位サイズ変更時に、旧ビットテーブルの受信状況の情報を新規ビットテーブルに反映する。

図５は、リアセンブルリセット処理の処理手順を示すフローチャートである。尚、この処理は、リアセンブル処理開始時とビットテーブルの単位サイズの変更時に行われるが、何れもフラグメント化されたＩＰデータグラム受信が前提となる。また、ビットテーブル単位サイズ３０４も、この処理の実行前に決定されており、受信したＩＰデータグラムのＩＰヘッダ情報、ビットテーブル単位サイズが引数（Header、Size）として渡される。

まず、ステップＳ５０１で、ＣＰＵ１０１は管理テーブル２０２に対して、新規の管理エントリを作成する。次に、ステップＳ５０２で、新規に作成した管理エントリの送信元アドレス３０１、宛先アドレス３０２、識別子３０３に、引数のHeaderの対象情報（送信元アドレス、宛先アドレス、識別子）を設定する。そして、ステップＳ５０３で、新規に作成した管理エントリのビットテーブル単位サイズ３０４に引数のSizeを設定する。

次に、ステップＳ５０４で、設定されたビットテーブル単位サイズ３０４から、ビットテーブルサイズを取得する。具体的には、ＩＰデータグラムの最大ペイロードサイズ６４Ｋバイトを単位サイズで除算することで算出する。

例えば、設定されたビットテーブル単位サイズ３０４が１Ｋバイトであるなら、以下の計算式からビットテーブルサイズは６４ビットと算出される。

６４Ｋバイト÷１Ｋバイト＝６４ビット
また、別の例として６４ＫバイトがSize（ビットテーブル単位サイズ）で割り切れない場合もある。その場合は、小数点以下を切り上げることでビットテーブルサイズを算出する。例えば、単位サイズが３Ｋバイトであれば、除算の解は２１．３３３３…であるため、小数点以下を切り上げ２２ビットと算出される。

次に、ステップＳ５０５で、ステップＳ５０４で取得したビットテーブルサイズを基に、ビットテーブル領域２０３にビットテーブルを生成する。そして、ステップＳ５０６で、生成したビットテーブルを初期化する。ビットテーブルの初期化は、図２に示すビットテーブル領域２０３の全てのビットを“０”にセットすることで行う。

最後に、ステップＳ５０７で、ステップＳ５０１で新規作成した管理エントリのビットテーブルポインタ３０５に生成したビットテーブルの格納先アドレスを設定し、リアセンブルリセット処理を完了となる。

図６は、リアセンブル通常処理の処理手順を示すフローチャートである。尚、この処理は、フラグメント化されたＩＰデータグラムの受信時に行われる。また、詳細は後述するが、ＩＰデータグラム受信時に、受信したＩＰデータグラムのＩＰヘッダ情報と合致する管理エントリが存在するか否かを確認するため、管理テーブル２０２の検索が行われる。検索の結果、合致する管理エントリが存在する場合は、受信したＩＰデータグラムのＩＰヘッダ情報、合致する管理エントリが引数（Header、Entry）として渡される。合致する管理エントリが存在しない場合には、上述のリアセンブルリセット処理（図５）により新規に管理エントリが作成され、その管理エントリが引数（Entry）として渡される。

また、Headerの解析は予め行われており、受信したＩＰデータグラムのペイロードデータがビットテーブルの単位サイズに合っており、ビットテーブルに受信状況を正確に反映できることを前提とする。具体的には、以下の２点の条件に合致していることである。

１点目は、受信したＩＰデータグラムのペイロードサイズがビットテーブルの単位サイズと、整数比Ｎ：１（ペイロードサイズ：単位サイズ）の関係が保たれている。但し、受信したＩＰデータグラムがフラグメント前のペイロードデータにおける終端のペイロードデータを持つＩＰデータグラム（以下、終端ＩＰデータグラムと呼ぶ）である場合は対象外とする。

２点目は、受信したＩＰデータグラムのフラグメント前のペイロードデータにおけるオフセット（開始位置）が、同じようにビットテーブルの単位サイズと、整数比Ｎ：１（オフセット：単位サイズ）の関係が保たれていることである。

上記２点の条件を満足することで、ペイロードデータの受信状況をビットテーブルに反映する際に、対応するビットが存在しないという状況に陥らない。

まず、ステップＳ６０１で、ＣＰＵ１０１は、引数のEntryのビットテーブルポインタ３０５から、関連付けられたビットテーブルの格納場所を特定する。そして、ステップＳ６０２で、引数のHeaderから受信したＩＰデータグラムのペイロードデータが、全ペイロードデータのどこに位置するデータであるかを示すオフセットとペイロードサイズを取得する。

ここで、オフセットは、Headerにおけるフラグメントオフセット（Fragment Offset）フィールドが示す値そのものである。また、ペイロードサイズは、HeaderにおけるIHLフィールド、全パケット長（Total Length）フィールドから算出する。IHLフィールドはＩＰデータグラムにおけるヘッダのワード数（１ワード＝４バイト）であり、全パケット長フィールドはＩＰデータグラム全体の長さ（バイト数）である。即ち、ペイロードサイズは、以下の計算式で算出することができる。

ペイロードサイズ（バイト）＝全パケット長フィールド−（IHLフィールド×４）
例えば、全パケット長フィールドが１０４４バイトであり、IHLフィールドが５である場合には、以下の計算式からペイロードサイズは１Ｋバイトと算出される。

１０４４−（５×４）＝１０２４バイト＝１Ｋバイト
上述の方法でオフセットとペイロードサイズを取得した後、ステップＳ６０３で、特定したビットテーブルに対し、フラグメント前のペイロードデータ内の受信した部分に対応するビットに“１”をセットする。

例えば、ビットテーブルの単位サイズが１Ｋバイトであり、オフセットが０（ゼロ）、ペイロードサイズが３Ｋバイトであったとする。この場合は、ビットテーブルの先頭から３ビット分に“１”がセットされる。

また、別の例として、ビットテーブルの単位サイズが５１２バイトであり、オフセットが２Ｋバイト、ペイロードサイズが１Ｋバイトであったとする。この場合は、ビットテーブルの５ビット目から２ビット分に“１”がセットされる。

ステップＳ６０３の処理において注意すべき点がある。それは、受信したＩＰデータグラムのペイロードサイズがビットテーブルの単位サイズの整数倍ではない場合、つまり、端数（余り）を持つ場合である。リアセンブル通常処理の前では、ビットテーブルの単位サイズに合わないペイロードデータサイズ及びオフセットではないことが前提となっているため、通常ペイロードサイズはビットテーブルの単位サイズの整数倍となる。

しかしながら、受信したＩＰデータグラムが終端ＩＰデータグラムである場合は、端数を持つ可能性がある。この端数の処理に関しては、ステップＳ６０５の終端処理で行うため、ステップＳ６０３では端数の処理は行わない。

よって、ビットテーブルの単位サイズが５１２バイト、オフセットが２Ｋバイト、ペイロードサイズが１０２５バイト（＝１Ｋバイト＋１バイト）の場合、上述の例と同様に、ビットテーブルの５ビット目から２ビット分に“１”がセットされる。そして、端数の１バイトの処理はステップＳ６０５で行う。

ステップＳ６０３でビットテーブルの更新を行った後、ステップＳ６０４で、受信したＩＰデータグラムが終端ＩＰデータグラムであるか否かを確認する。具体的には、HeaderのＭＦ（More Fragment）フラグが“１”であれば後続のデータグラムが存在するため、終端ＩＰデータグラムではないと判断する。また、“０”であれば後続のデータグラムが存在しない、つまり、終端ＩＰデータグラムであると判断する。

ここで、終端ＩＰデータグラムであると判断した場合は、ステップＳ６０５で、ビットテーブルの終端処理を行う。具体的には、ビットテーブルにおける受信したＩＰデータグラムに対応する部分以降のビットを全て“１”にセットする。こうすることで、ビットテーブルは全てのビットが１にセットされたときに全てのフラグメントされたＩＰデータグラムを受信した、つまり、リアセンブル処理が完了したと判断できる。

尚、ビットテーブルの終端処理方法は、上述の方法に限られるわけではなく、他の方法で実現しても良い。即ち、リアセンブル処理が完了したと明確に判断可能な方法であれば、何れの実現方法であっても本発明を適用できる。

また、ステップＳ６０３において、無視した終端ＩＰデータグラムにおける端数の処理も、ステップＳ６０５で併せて行う。特に、特殊な処理を行うわけではなく、上述の終端処理と同様に、ビットテーブルにおける受信したＩＰデータグラムの端数が含まれる部分以降のビットを全て“１”にセットする。こうすることで、端数の有無に関係なく終端処理を行うことができる。

このステップＳ６０５でビットテーブルの終端処理を行った場合、ステップＳ６０４で終端ＩＰデータグラムではないと判断した場合の何れにおいても、リアセンブル通常処理は完了となる。

図７は、リアセンブルターミネート処理の処理手順を示すフローチャートである。尚、この処理は、リアセンブル処理終了時に行われる。この処理の実行前には、リアセンブル通常処理（図６）が実行され、更にリアセンブル処理が完了したか否かの判定が行われ、完了したと判定されていることを前提とする。リアセンブル処理が完了したか否かはリアセンブル通常処理を実行した管理エントリに基づいて判定する。そのため、この処理の実行前にはリアセンブル処理が完了した管理エントリが特定されている。また、この処理には、当該管理エントリが引数のEntryとして渡される。

まず、ステップＳ７０１で、ＣＰＵ１０１は、引数（Entry）として渡された管理エントリのビットテーブルポインタ３０５から、関連付けられたビットテーブルの格納場所を特定する。そして、ステップＳ７０２で、特定したビットテーブルをビットテーブル領域２０３から解放する。ここで、解放とは、解放対象のビットテーブルの格納場所をその後、自由に使用可能にすることを意味する。より具体的には、リアセンブルリセット処理のステップＳ５０５で、ビットテーブルを生成する際に、解放したビットテーブルの領域を使用可能にするという意味である。

最後に、ステップＳ７０３で、引数（Entry）の管理エントリを管理テーブル２０２から解放する。この処理でリアセンブルターミネート処理は完了となる。

図８は、ビットテーブル移行処理の処理手順を示すフローチャートである。尚、この処理は、ビットテーブルの単位サイズ変更時に行われる。尚、この処理の実行前には、単位サイズ変更前のビットテーブルの管理情報が格納された管理エントリ（以下、旧管理エントリと呼ぶ）が特定されている。また、単位サイズ変更後のビットテーブルの管理情報が格納された管理エントリ（以下、新管理エントリと呼ぶ）も特定されている。

また、上述の旧管理エントリのビットテーブルポインタ３０５に関連付けられたビットテーブルを旧ビットテーブルと呼び、ビットテーブル単位サイズ３０４を旧単位サイズと呼ぶ。同様に、新管理エントリのビットテーブルポインタ３０５に関連付けられたビットテーブルを新ビットテーブルと呼び、ビットテーブル単位サイズ３０４を新単位サイズと呼ぶ。

詳細は後述するが、新単位サイズは旧単位サイズに対して、整数比の１：Ｎ、もしくはＮ：１の関係が成り立つように設定される。例えば、Ｎ：１（旧単位サイズ：新単位サイズ）の場合、旧単位サイズが１Ｋバイトであれば、新単位サイズは５１２、２５６、１２８、６４、３２、１６、８バイトの何れかとなる。

ビットテーブルの単位サイズは、フラグメント化されたＩＰデータグラムのペイロードの最小値８バイトに依存するため、８バイト未満の値が設定されることはない。

一方、１：Ｎ（旧単位サイズ：新単位サイズ）の場合、旧ビットテーブルの受信状況を新ビットテーブルに移行できない可能性がある。例えば、旧単位サイズが５１２バイト、新単位サイズが１Ｋバイトであり、受信状況として先頭の５１２バイト分のペイロードデータのみ受信していた場合を考える。この場合、先頭の５１２バイト分のペイロードデータは、新ビットテーブルの先頭の１ビットに対応させることができない。即ち、当該ビットを“１”にセットすると単位サイズの１Ｋバイト分のペイロードデータを受信していることを意味してしまうからである。

また、“０”をセットした場合は、未受信となり５１２バイト分のペイロードデータを受信していないことになってしまう。

本実施形態では、上述のように旧ビットテーブルが示す受信状況が、新ビットテーブルに移行できないような旧単位サイズ及び新単位サイズは、本ビットテーブル移行処理には与えられないものとする。つまり、上述したように旧単位サイズが５１２バイト、新単位サイズが１Ｋバイトである場合、旧ビットテーブルが示す受信状況は受信済み部分が１Ｋバイト単位であること、かつ未受信部分が１Ｋバイト単位であることが前提となる。

また、新管理エントリは、この処理の前にリアセンブルリセット処理のステップＳ５０１で作成され、新ビットテーブルはリアセンブルリセット処理のステップＳ５０６で初期化されている。

尚、このビットテーブル移行処理は、上述のように、新単位サイズと旧単位サイズとが整数比の関係を持ち、旧管理エントリ、新管理エントリが引数のOldEntry、NewEntryとして渡される。

まず、ステップＳ８０１で、ＣＰＵ１０１は、引数（OldEntry）として渡された旧管理エントリのビットテーブルポインタ３０５から、旧ビットテーブルの格納場所を特定する。次に、ステップＳ８０２で、引数（NewEntry）として渡された新管理エントリのビットテーブルポインタ３０５から、新ビットテーブルの格納場所を特定する。

最後に、ステップＳ８０３で、旧ビットテーブルのペイロードデータの受信状況を新ビットテーブルに移行する。受信状況の移行は、旧ビットテーブル内で“１”がセットされている、つまりフラグメント前のペイロードデータの内受信済みの部分の情報に基づいて新ビットテーブル内の該当ビットに“１”をセットすることで行う。

このステップＳ８０３の処理を具体例を挙げて説明する。まず、旧単位サイズと新単位サイズがＮ：１（旧単位サイズ：新単位サイズ）の関係の場合を説明する。

ここで、旧単位サイズが１Ｋバイトであり、新単位サイズが５１２バイトであったとする。また、旧ビットテーブルは、先頭から３ビット分に“１”がセットされていたとする。この場合、ペイロードデータは先頭から３Ｋバイト分のデータが受信済みであることを意味する。よって、新ビットテーブルへの移行は、先頭から６ビット分（３Ｋバイト＝５１２バイト×６）に“１”をセットする。

また、別の例として、旧単位サイズが１Ｋバイトであり、新単位サイズが５１２バイト、旧ビットテーブルは５ビット目から２ビット分に“１”がセットされていたとする。この場合、ペイロードデータは先頭からのオフセット４Ｋバイトから２Ｋバイト分のデータが受信済みであることを意味する。よって、新ビットテーブルへの移行は、９ビット目から４ビット分（２Ｋバイト＝５１２バイト×４）に“１”をセットする。

次に、旧単位サイズと新単位サイズが１：Ｎ（旧単位サイズ：新単位サイズ）の関係の場合を説明する。ここで、旧単位サイズが５１２バイトであり、新単位サイズが１Ｋバイトであったとする。また、旧ビットテーブルは先頭から４ビット分に“１”がセットされていたとする。この場合、ペイロードデータは先頭から２Ｋバイト分のデータが受信済みであることを意味する。

よって、新ビットテーブルへの移行は、先頭から２ビット分（２Ｋバイト＝１Ｋバイト×２）に“１”をセットする。上述の前提から“１”がセットされているビットが連続する場合、２ビット単位での連続ビットとなる。また、“０”がセットされているビットが連続する場合も同様に、２ビット単位での連続ビットとなり、新ビットテーブルへの移行の際に所定のビットにマッピング不可になることはない。

このステップＳ８０３でビットテーブル情報の移行を行うことで、ビットテーブル移行処理は完了となる。

ここで、ネットワークプロトコル処理装置におけるＩＰデータグラムを受信した場合の処理手順を、図９を用いて説明する。尚、この処理は、ＩＰデータグラムを受信したことをトリガーとしてＣＰＵ１０１によって実行される。また、受信したＩＰデータグラムがフラグメント化されていた場合、リアセンブル処理を実行すべく、上述した４つの処理が実行される。即ち、上述のリアセンブルリセット処理（図５）、リアセンブル通常処理（図６）、リアセンブルターミネート処理（図７）、及びビットテーブル移行処理（図８）が実行される。

図９は、本実施形態におけるＩＰデータグラムの受信処理を示すフローチャートである。まず、ステップＳ９０１で、ＩＰデータグラムを受信する。ＩＰデータグラムは、外部からＰＨＹ１０５を通して一旦ＭＡＣ１０４に受信される。その後、ＤＭＡＣ１０６によりＲＡＭ１０３内の受信データ領域２０１にバス１０７を介して転送される。このとき、受信データの転送はＤＭＡＣ１０６を用いずに、ＣＰＵ１０１が受信データ領域２０１に転送しても良い。

次に、ステップＳ９０２で、ＣＰＵ１０１は、受信したＩＰデータグラムのＩＰヘッダを解析する。尚、ステップＳ９０１で受信したＩＰデータグラムを受信ＩＰデータグラムと呼び、受信ＩＰデータグラムのＩＰヘッダを受信ＩＰヘッダ、受信ＩＰデータグラムのペイロードデータを受信ペイロードと呼ぶ。また、リアセンブル通常処理の説明と同じく、フラグメント前のペイロードにおける終端部分のペイロードを持つＩＰデータグラムを終端ＩＰデータグラムと呼ぶ。

次に、ステップＳ９０３では、ステップＳ９０２で行った受信ＩＰヘッダの解析結果に基づいて受信ＩＰデータグラムがフラグメント化されているか否かを判定する。ここでは、受信ＩＰヘッダのＭＦ（More Fragment）フラグ、フラグメントオフセット（Fragment Offset）フィールドにより判定する。

具体的には、まずＭＦフラグがセット（“１”の場合）されているか否かを確認する。ＭＦフラグがセットされている場合は、受信ＩＰデータグラムは終端ＩＰデータグラムではないことを意味する。ＭＦフラグがセットされていない場合、受信ＩＰデータグラムはフラグメント化されていないか、或いは終端ＩＰデータグラムであることを意味する。

このＭＦフラグがセットされていない場合は、更にフラグメントオフセットフィールドを確認する。このフラグメントオフセットフィールドが“０”の場合は、受信ＩＰデータグラムはフラグメント化されていないことを意味する。しかし、フラグメントオフセットフィールドが“０”以外の値の場合には、受信ＩＰデータグラムは終端ＩＰデータグラムであることを意味する。

よって、ＭＦフラグがセットされている場合は、受信したＩＰデータグラムはフラグメント化されていると判断する。また、ＭＦフラグがセットされておらず、かつフラグメントオフセットフィールドが“０”以外の値である場合は、受信したＩＰデータグラムはフラグメント化されていると判断する。そして、ＭＦフラグがセットされておらず、かつフラグメントオフセットフィールドが“０”である場合、受信ＩＰデータグラムはフラグメント化されていない通常のＩＰデータグラムであると判断する。

上述のステップＳ９０３で、受信ＩＰデータグラムがフラグメント化されていると判断した場合は、ステップＳ９０４へ処理を進め、管理テーブル２０２を検索し、受信ＩＰヘッダに合致する管理エントリが存在するか否かを確認する。この処理は、受信ＩＰヘッダ内の送信元アドレス、宛先アドレス、識別子が、それぞれ管理エントリの送信元アドレス３０１、宛先アドレス３０２、及び識別子３０３と一致するかを確認する処理である。

ここで、上記３項目が一致する管理エントリが存在しない場合、受信ＩＰデータグラムに対するリアセンブル処理はまだ開始していない、つまり受信ＩＰヘッダを持つＩＰデータグラムのリアセンブル処理を開始する必要があることを意味する。そのため、ステップＳ９０５で、リアセンブルリセット処理に与えるためのビットテーブル単位サイズを決定する。

次に、ステップＳ９０５のビットテーブル単位サイズの決定方法を説明する。ビットテーブル単位サイズは、ステップＳ９０１で受信したＩＰデータグラムのペイロードサイズと、ペイロードデータのオフセットの公約数の内、何れかに決定する。即ち、最初に受信したフラグメントIPデータグラムのペイロードサイズと、そのペイロードのフラグメント前のペイロードデータにおけるオフセットの公約数の内、何れかを単位サイズに決定する。例えば、ペイロードサイズが５１２バイトであり、オフセットが３Ｋバイトであった場合、５１２、２５６、１２８、６４、３２、１６、８バイトの何れかである。ビットテーブルの単位サイズは、フラグメント化されたＩＰデータグラムのペイロードの最小値８バイトに依存するため、８バイト未満の値が設定されることはない。当然、ビットテーブルの単位サイズは、大きければ大きいほどビットテーブル本体のサイズを小さく抑えることができるため、上記の例では最大公約数である５１２バイトを選択した場合が最もメモリ使用量を削減することができる。

尚、受信ＩＰデータグラムが終端ＩＰデータグラムであった場合は、別の処理を行うという構成にしても良い。終端ＩＰデータグラムが持つペイロードサイズは、フラグメント前のペイロードデータを所定のサイズで分割した端数（余り）である。そこで、終端ＩＰデータグラムのペイロードサイズを単位サイズとしてビットテーブルを生成してしまうと、後続のＩＰデータグラムを受信した際にビットテーブルの単位サイズを変更しなければならないという状況に陥ることが容易に想定される。

よって、例えば終端ＩＰデータグラムのペイロードサイズに関わらず、そのオフセット（開始位置）から他のＩＰデータグラムが持つペイロードサイズを予測して単位サイズを決定するという方法を取っても良い。

また、例えば終端ＩＰデータグラムである場合には、処理を保留にするという方法を取っても良い。つまり、後続の終端ではないＩＰデータグラムを受信したときに、そのペイロードサイズを単位サイズとしてビットテーブルを構成した後、改めて終端ＩＰデータグラムの処理を再開するという方法である。上記何れの方法、またその他の方法であっても、ステップＳ９０５で単位サイズを決定できれば、本発明を適用可能である。

次に、ビットテーブル単位サイズを決定した後に、ステップＳ９０６で、リアセンブルリセット処理を実行する。このとき、引数のSizeに、ステップＳ９０５で決定したビットテーブル単位サイズを与える。また、引数のHeaderには、受信したＩＰヘッダを与える。このステップＳ９０６、リアセンブルリセット処理を実行した後、リアセンブル通常処理へ進む。

一方、ステップＳ９０４で、受信ＩＰヘッダに合致する管理エントリが存在した場合は、ステップＳ９０７へ処理を進める。この場合、受信ＩＰデータグラムに対するリアセンブル処理は既に開始されていることを意味する。そこで、ステップＳ９０７では、既存のビットテーブルの単位サイズを変更する必要があるか否かをチェックし、必要がある場合は、ステップＳ９０８へ処理を進め、変更するビットテーブル単位サイズを取得する。

尚、ステップＳ９０４で合致した管理エントリを既存管理エントリ、既存管理エントリに関連付けられたビットテーブルを既存ビットテーブル、既存ビットテーブルの単位サイズを既存単位サイズと呼ぶ。また、ステップＳ９０９でリアセンブルリセット処理を行うビットテーブルを新ビットテーブル、ステップＳ９０８で決定するビットテーブルの単位サイズを新単位サイズと呼ぶ。

ここで、上述のステップＳ９０７の既存単位サイズ変更の必要性判断方法、ステップＳ９０８の既存単位サイズの決定方法を説明する。

ステップＳ９０７では、受信ＩＰヘッダのＭＦビットがセットされていない、つまり、終端ＩＰデータグラムである場合は、既存の単位サイズを変更する必要性はないと判断する。一方、受信ＩＰデータグラムが終端ＩＰデータグラムではない場合で、かつ、以下の何れかの条件に合致する場合、既存の単位サイズを変更する必要があると判断する。
＜条件Ａ＞受信ペイロードのデータサイズか、オフセット（フラグメント前のペイロードデータにおける開始位置）の何れか一つが、既存単位サイズの整数倍ではない場合。即ち、受信したフラグメントＩＰデータグラムのペイロードサイズと、フラグメント前のペイロードデータにおけるオフセットの両方が、既存単位サイズの整数倍でない場合。これは、受信したフラグメントIPデータグラムのペイロードデータが、所定の単位サイズで生成された既存のビットマップテーブルへ受信状況を設定不可能な場合である。
＜条件Ｂ＞既存ビットテーブルの“１”が連続する部分の連続ビット数を、先頭から順にN1_1、N1_2、N1_3、…とし、これらの整数の最大公約数をN1_GCDとする。また、“０”が連続する部分の連続ビット数を、先頭から順にN0_1、N0_2、N0_3、…とし、これらの整数の最大公約数をN0_GCDとする。更に、N1_GCD及びN0_GCDの二つの整数の最大公約数をN01_GCDとする。このとき、N01_GCDの１以外の所定の約数をＭとし、受信ペイロードのデータサイズとオフセットが次の条件を満たすＭが存在する。受信ペイロードのデータサイズが（Ｍ×変更前のビットテーブル単位サイズ）の整数倍であり、かつ受信ペイロードのオフセットが（Ｍ×変更前のビットテーブル単位サイズ）の整数倍である場合。

次に、上記条件Ａ、条件Ｂに合致する具体的な例を用いてステップＳ９０８での新単位サイズの決定方法を説明する。

上記条件Ａに合致する場合の例として、既存単位サイズが１Ｋバイトであり、受信ペイロードのデータサイズが５１２バイトという場合が考えられる。この場合、受信ペイロードデータが既存単位サイズより小さいため、受信ペイロードデータを既存ビットテーブルの所定のビットに対応させることができない。

また、この例で更に、受信ペイロードのオフセットが７６８バイトという場合が考えられる。この場合、受信ペイロードデータが既存ビットテーブルの所定のビットに対応するデータ領域の途中から開始することになり、受信ペイロードデータを既存ビットテーブルの所定のビットに対応させることができない。

よって、何れの例においても、ステップＳ９０８で決定する新単位サイズは、既存単位サイズより小さく設定する必要がある。上記条件Ａに合致する場合のステップＳ９０８における新単位サイズの決定方法は、受信ペイロードのデータサイズ、受信ペイロードのオフセット、既存単位サイズの３つの整数の公約数を求めることである。即ち、受信したフラグメントＩＰデータグラムのペイロードサイズと、そのペイロードデータのフラグメント前のペイロードデータにおけるオフセットと、既存単位サイズに基づき、ビットマップテーブルの単位サイズを決定することである。受信ペイロードのデータサイズと変更前のビットテーブルの単位サイズの公約数を単位サイズとするビットテーブルであれば、受信ペイロードデータをビットテーブルの所定のビットに対応させることができる。

また、受信ペイロードのオフセットと変更前のビットテーブルの単位サイズの公約数を単位サイズとするビットテーブルであれば、受信ペイロードデータがビットテーブルの所定のビットに対応するデータ領域の途中から開始されることはなくなる。従って、所定のビットに対応されることができる。更に、既存単位サイズが新単位サイズの整数倍であるため、既存ビットテーブルの受信状況は新ビットテーブルに正確に移行することができる。

上述した例では、受信ペイロードサイズ５１２バイトと、受信ペイロードのオフセット７６８バイト、変更前のビットテーブルの単位サイズ１Ｋバイトの３つの整数の公約数である。つまり、２５６バイト、１２８バイト、６４バイト、３２バイト、１６バイト、８バイトの何れかである。ビットテーブルの単位サイズは、フラグメントされたＩＰデータグラムのペイロードの最小値８バイトに依存するため、８バイト未満の値が設定されることはない。当然、ビットテーブルの単位サイズは、大きければ大きいほどビットテーブル本体のサイズを小さく抑えることができるため、上述した例では最大公約数である２５６バイトを選択した場合が最もメモリ使用量を削減することができる。

次に、上記条件Ｂに合致する場合の例として、既存単位サイズが１Ｋバイトで、図１０に示す受信状況で、受信ペイロードのデータサイズが４Ｋバイト、受信ペイロードのオフセットが６Ｋバイトである場合が考えられる。

図１０において、１００１は既存ビットテーブル本体であり、単位サイズが１Ｋバイトであるため、６４ビットから構成されている。ビットテーブル１００１の左端がペイロードデータの先頭を意味し、右端が終端を意味する。このビットテーブル１００１において、“１”（受信済み）がセットされているビットが連続する部分は１０１０及び１０１２の２箇所である。１０１０は“１”が連続した８ビットであり、１０１２は“１”が連続した１６ビットである。

一方、“０”（未受信）がセットされているビットが連続する部分は１０１１及び１０１３の、２箇所である。１０１１は“０”が連続した４ビットであり、１０１３は“０”が連続した３６ビットである。上記条件Ｂにおいて、N1_1=8、N1_2=16となり、N1_GCD=8（８と１６の最大公約数）となる。一方、N0_1=4、N0_2=32となり、N0_GCD=4（４と３２の最大公約数）となる。そして、N1_GCD（=8）とN0_GCD（=4）から、N01_GCD=4（４と８の最大公約数）となる。

ここで、N01_GCD（=4）の約数Ｍを考えると、Ｍ＝４、２、１の何れかであることが分かる。これは、ビットテーブル１００１は、単位サイズをＭ倍に変更することが可能であることを意味している。Ｍ＝１の場合は、単位サイズが変更されないため、成り立つことは自明である。

Ｍ＝４及び２の場合に、仮にビットテーブル１００１の単位サイズを変更した場合の変更後のビットテーブルを図１１に示す。図１１において、１１０１はＭ＝４とした場合、つまり単位サイズを４Ｋバイトに変更した場合のビットテーブル本体を示している。１１０２はＭ＝２とした場合（単位サイズ＝２Ｋバイト）のビットテーブル本体である。

図１１において、１１１０及び１１１２は“１”（受信済み）がセットされているビットが連続する部分である。１１１０は先頭からの連続した２ビットであり、変更前のビットテーブル１００１の同じく先頭から連続した８ビット１０１０に対応する。つまり、ビットテーブル単位サイズが４倍になっているため、連続したビット数は４分の１になっているが、受信状況は何れも先頭からの８Ｋバイト分のペイロードデータが受信済みであることを示している。また、１１１２（図１１におけるＭ＝４の場合の“１”が連続した４ビット）と１０１２（図１０における“１”が連続した１６ビット）にも同じことが言える。

一方、１１１１及び１１１２は“０”（未受信）がセットされているビットが連続する部分である。１１１１は３ビット目からの連続した１ビットであり、変更前のビットテーブル１００１の９ビット目からの連続した４ビット１０１１に対応する。つまり、ビットテーブル単位サイズが４倍になっているため、連続したビット数は４分の１になっているが、受信状況は何れもオフセット８Ｋバイトからの４Ｋバイト分のペイロードデータが未受信であることを示している。また、１１１３（図１１におけるＭ＝４の場合の“０”が連続した８ビット）と１０１３（図１０における“０”が連続した３２ビット）にも同じことが言える。

よって、ビットテーブル１００１と、単位サイズを４倍として仮に変更した場合のビットテーブル１１０１は、同じ受信状況を示していることとなる。同様に、ビットテーブル１００１と、単位サイズを２倍として仮に変更した場合のビットテーブル１１０２も同じ受信状況を示していると言える。即ち、ビットテーブル１００１はN01_GCD（=4）の約数Ｍに対し、単位サイズをＭ倍に変更しても、受信状況を移行できることが言える。

尚、受信状況だけが移行できても、受信ペイロードデータが新ビットテーブルの所定のビットにマッピングできなければ意味がない。受信したＩＰデータグラムのペイロードデータを所定のビットにマッピングするには、上記条件Ａで説明したように、新単位サイズが受信ペイロードのデータサイズ、受信ペイロードのオフセット、既存単位サイズの３つの整数の公約数となっている必要がある。そのため、条件ＢではN01_GCDの約数Ｍの内、受信ペイロードのデータサイズが（Ｍ×既存単位サイズ）の整数倍であり、かつ受信ペイロードのオフセットが（Ｍ×既存単位サイズ）の整数倍であるという二つの条件を満たすことが必要となる。ここで、（Ｍ×既存単位サイズ）は新単位サイズを示しており、ステップ５０８における新単位サイズの決定方法は、上記条件を満たすＭを求め、Ｍ×既存単位サイズを算出することであると言い換えることができる。

更に、上述の例で、受信ペイロードサイズが４Ｋバイト、受信ペイロードのオフセットが６Ｋバイトであったとする。この場合、Ｍ＝４とすると新単位サイズは４Ｋバイトとなり、受信ペイロードのオフセットが４Ｋバイトの整数倍ではないことから上記条件に合致しない。Ｍ＝２とすると新単位サイズは２Ｋバイトとなり、受信ペイロードサイズ及び受信ペイロードのオフセットが何れも２Ｋバイトの整数倍で上記条件に合致する。よって、ステップＳ９０８では新単位サイズとして２Ｋバイトが算出される。

ここで、ステップＳ９０７の判定において、受信したＩＰデータグラムが終端ＩＰデータグラムではない場合で、かつ、上記条件Ｂに合致した場合でも、変更の必要性はないと判断しても良い。受信ペイロードデータの受信状況は、既存ビットテーブルで正常に管理可能であるが、ビットテーブルサイズの縮小を目的として、より大きい単位サイズへ変更する処理を行うことができる状況にあるか否かを示している。よって、上記条件に合致した場合にビットテーブル単位サイズを変更し、ビットテーブルサイズを縮小することによるメモリ使用量削減効果と、ビットテーブル変更によるＣＰＵ１０１に対する負荷増大の２つに鑑みて、何れの判断を行っても良い。

上述したように、ステップＳ９０７で、既存単位サイズを変更する必要があるか否かをチェックし、必要がある場合にはステップＳ９０８で新単位サイズを取得する。そして、ステップＳ９０９で、リアセンブルリセット処理を実行する。このとき、引数のSize（ビットテーブル単位サイズ）にはステップＳ９０８で決定した新単位サイズを与える。また、引数のHeader（ＩＰヘッダ）には、受信ＩＰヘッダを与える。このステップＳ９０９でリアセンブルリセット処理を実行することにより、単位サイズが新単位サイズに設定された新ビットテーブルと新ビットテーブルが関連付けられた管理エントリが生成される。

その後、ステップＳ９１０で、ビットテーブル移行処理を実行する。このとき、引数のOldEntryには既存管理エントリを与え、引数のNewEntryにはステップＳ９０９で生成された管理エントリを与える。このステップＳ９１０でビットテーブル移行処理を実行することにより、既存ビットテーブルのペイロードデータ受信状況が、新ビットテーブルに移行される。

続くステップＳ９１１で、リアセンブルターミネート処理を実行し、既存管理エントリ、既存管理エントリに関連付けられた既存ビットテーブルを解放する。尚、リアセンブルターミネート処理は、引数のEntryに既存管理エントリを与えることで実行する。

次に、ステップＳ９１２でリアセンブル通常処理を実行する。このとき、引数のEntryには受信ＩＰデータグラムの管理エントリを与える。ここで、ステップＳ９０６から処理を進めてきた場合は、ステップＳ９０４で合致した管理エントリを意味する。ステップＳ９０７で既存単位サイズを変更する必要はないと判断した場合も同様に、ステップＳ９０４で合致した管理エントリを与える。一方、ステップＳ９１１から処理を進めてきた場合は、ステップＳ９１０で生成した管理エントリを与える。また、引数のHeaderには、受信ＩＰヘッダを与える。

続くステップＳ９１３で、リアセンブル処理が完了したか、つまりフラグメントされたＩＰデータグラムのペイロードデータを全て受信したか否かを確認する。リアセンブル処理完了は、現在の管理エントリに関連付けられたビットテーブルのビットが全て“１”であるか否かを確認することで行う。

但し、リアセンブル通常処理のステップＳ９０６（ビットテーブルに対する終端処理）において、上述した方法で終端処理を行っていなかった場合は、この限りではない。上述した終端処理とは、受信したＩＰデータグラムに対応する部分以降のビットを全て“１”にセットするというものである。何れにしても、リアセンブル通常処理で行った終端処理に応じてリアセンブル処理が完了したか否かを確認すれば良い。

ステップＳ９１３でリアセンブル処理は未完了と判断した場合は、この処理を完了し、次のＩＰデータグラムの受信で再度処理を行う。しかし、リアセンブル処理を完了したと判断した場合は、ステップＳ９１４へ処理を進め、リアセンブルターミネート処理を実行する。このとき、引数のEntryには現在の管理エントリを与える。このリアセンブルターミネート処理により管理エントリ、管理エントリに関連付けられたビットテーブルが解放される。その後、ステップＳ９１５では、リアセンブル処理が完了したフラグメント前のペイロードデータを上位層に受け渡す。

一方、上述のステップＳ９０３で受信したＩＰデータグラムがフラグメントされていないと判断した場合は、ステップＳ９１５へ処理を進め、ペイロードデータを上位層に受け渡す。この上位層は、通常はＴＣＰ処理を行うソフトウェアであるが、本実施形態では、特に限定はしない。

また、リアセンブル処理されたペイロードデータは、複数のＩＰデータグラムのペイロードデータを合わせたものであるため、ペイロードデータ自体の合成を行う処理モジュールも必要である。この処理は、ソフトウェアで行う場合が一般的であるが、本実施形態では、この処理を行うモジュールを特に限定はしない。

本実施形態によれば、リアセンブル処理時のペイロードデータ受信状況をビットテーブルで管理する際に、リアセンブル処理が対象とするＩＰデータグラム毎に８１９２ビット必要であったビットテーブルデータサイズを縮小することができる。これにより、ビットテーブルにより使用されるＲＡＭ１０３内のデータ量を削減することができる。

尚、本実施形態では、ネットワークプロトコルのリアセンブル処理をＩＰデータグラムの受信時に行うことを前提に説明したが、必ずしもＩＰデータグラムの受信をトリガーにして行わなければならないわけではない。ネットワークプロトコル処理装置の実装によっては、例えばある程度受信済みＩＰデータグラムがたまった時点で処理を開始するという実装形態も考えられる。本発明は、ＩＰデータグラムを受信し、ＲＡＭ１０３の受信データ領域２０１に格納されている状態であれば実施可能であり、上述のような構成であっても本発明が適用できることは言うまでもない。

また、本実施形態では、管理エントリ及びビットテーブルの生成において、管理テーブル２０２及びビットテーブル領域２０３の容量が不足し、生成できなかった場合も本発明の適用範囲を何ら減じることはない。例えば、生成できなかった場合には、リアセンブル処理をその時点で放棄し、ＩＰデータグラムを破棄しても構わない。

通常のネットワークプロトコル処理装置では、リアセンブル処理を並列に実行可能な数を制限しているため、制限数を超えてリアセンブル処理を行うことはない。また、本発明は、ＴＣＰ／ＩＰプロトコルのＩＰ層に適用される内容であり、上位層のＴＣＰ層では、一定時間内に受信できなかったＴＣＰパケットは再送を促す仕組みが定義されている。

これにより、ＩＰ層で一度リアセンブル処理を放棄した場合でも、ＴＣＰ層レベルの再送要求により、再度当該データが送信機器から到着することとなる。

また、本実施形態では、リアセンブル処理中にビットテーブルの単位サイズを変更する必要性が生じた場合には、関連するパラメータの公約数で再度ビットテーブルを構成している。また、その際、最大公約数を使用することでメモリ使用量を削減できるとしているが、ここにはＣＰＵ１０１にかかる処理負荷とのトレードオフの関係が存在する。

つまり、フラグメントされたＩＰデータグラムのペイロードサイズが一律ではない場合は、送信機器とネットワークプロトコル処理装置間の経路がＷＡＮ等を経由している場合が多い。その後、受信するＩＰデータグラムのペイロードサイズも異なる可能性が容易に推測される。後続のＩＰデータグラムのペイロードサイズがそれぞれ異なる場合には、受信する度にリアセンブルリセット処理とビットテーブル移行処理を行わなければならない可能性がある。これは、ＣＰＵ１０１にかかる負荷が増大する可能性につながり、ネットワークプロトコル処理全体の処理性能低下につながる。

従って、一旦リアセンブル処理中にビットテーブルの単位サイズを変更する必要性が生じた場合、二度と変更しなくてもよいように、関連するパラメータ値に関わらず、ビットテーブルの単位サイズを８バイト（最小単位）で再構成しても良い。このような構成を取った場合でも、通信経路がＬＡＮ等でＩＰデータグラムのペイロードサイズが一定である場合のリアセンブル処理において本発明の効果が期待できる。

また、本実施形態では、管理エントリやビットテーブルのＲＡＭ１０３内での割り当て方法、及び解放方法に関して明記していないが、何れの方法であっても本発明を適用できることは言うまでもない。例えば、通常の処理装置では、固定長のデータ領域を確保する場合は、予め所定の個数分のデータ領域を確保しておき、それぞれのデータ領域に対する使用状態を示すフラグ等を準備し、当該フラグにより確保及び解放を管理することが多い。

また、可変長のデータ領域を確保する場合は、ファイルシステム等のソフトウェアにより所定サイズのデータ領域の確保及び解放を管理することが多い。何れにおいても、またその他何れの方法でも、管理エントリ及びビットテーブルの確保、解放が行える限り、本発明の適用範囲である。

また、本実施形態では、ビットテーブル移行処理において、旧単位サイズと新単位サイズが、１：ＮもしくはＮ：１であることを前提として説明した。しかし、Ｎ：Ｍ（Ｎ、Ｍは整数かつ互いに素）の関係であっても、受信状況が新ビットテーブルのビットに適切にマッピング可能である。つまり、受信状況の移行が可能であれば、本発明を適用できる。即ち、旧ビットテーブルにおいて、“１”が連続するビット数が全てＭの整数倍であり、かつ“０”が連続するビット数が全てMの整数倍であるという条件を満たしている場合である。

また、本実施形態では、ビットテーブル移行処理を呼び出すときの旧単位サイズと新単位サイズの決定方法（図９に示すステップＳ９０８）では、旧単位サイズと新単位サイズが１：ＮもしくはＮ：１となるように決定することを前提として説明した。しかし、上述のビットテーブル移行処理がＮ：Ｍ（旧単位サイズ：新単位サイズ、Ｎ、Ｍは整数かつ互いに素）である旧単位サイズと新単位サイズを受けられることを前提とすれば、本発明を適用できる。この場合、ステップＳ９０８でもＮ：Ｍの関係となる旧単位サイズ、及び新単位サイズを決定すれば良い。ステップＳ９０８でＮ：Ｍの関係となる旧単位サイズ、及び新単位サイズを決定可能であれば、ステップＳ９０７の条件Ｂを以下の条件Ｂ１に変更できる。
＜条件Ｂ１＞現在のビットテーブルにおける“１”が連続する部分の連続ビット数を先頭から順にN1_1、N1_2、N1_3、…とする。更に、各々に現在のビットテーブルの単位サイズを掛け合わせたN1_1_MULTI、N1_2_MULTI、N1_3_MULTI、…とする。そして、単位サイズを掛け合わせた後の整数の最大公約数をN1_MULTI_GCDとする。また、“０”が連続する部分の連続ビット数を先頭から順にN0_1、N0_2、N0_3、…とする。更に、各々に現在のビットテーブルの単位サイズを掛け合わせたN0_1_MULTI、N0_2_MULTI、N0_3_MULTI、…とする。そして、単位サイズを掛け合わせた後の整数の最大公約数をN0_MULTI_GCDとする。更に、N1_MULTI_GCDとN0_MULTI_GCDの二つの整数の最大公約数をN01_MULTI_GCDとする。このとき、N01_MULTI_GCDの１以外の所定の約数をＭとして、次の条件を満たすＭが存在する。受信ペイロードのデータサイズが（Ｍ×変更前のビットテーブル単位サイズ）の整数倍であり、かつ受信ペイロードのオフセットが（Ｍ×変更前のビットテーブル単位サイズ）の整数倍である場合。

この条件Ｂ１を適用した場合のステップＳ９０８では、上述の条件Ｂの場合と同様に、Ｍ×既存のビットテーブルの単位サイズが取得対象の新規ビットテーブルの単位サイズの候補となる。

本実施形態によれば、ネットワークプロトコル処理におけるリアセンブル処理時に、ビットテーブルを８バイト以上の単位サイズで構成することにより、ビットテーブルサイズを縮小することができる。これにより、リアセンブル処理に必要となるメモリ領域を削減することができ、ネットワークプロトコル処理のパフォーマンス低下を抑制、及びシステム構築時のコストを低減することができる。特にメモリ領域が限られている組み込みシステム等では大きな効果が期待できる。

また、ＷＡＮを経由しないＬＡＮ内通信では、ルータを経由しないため、フラグメントされたＩＰデータグラムのペイロードサイズが固定であり、本発明による効果は大きい。ＷＡＮとは、ワイドエリアネットワークの略であり、ＬＡＮとは、ローカルエリアネットワークの略である。

更に、ＷＡＮを経由した場合でも、通信経路が複数に渡る可能性は低いため、同じくフラグメントされたＩＰデータグラムのペイロードサイズは固定である場合が多く、本発明による効果が期待できる。

尚、本発明は複数の機器（例えば、ホストコンピュータ、インターフェース機器、リーダ、プリンタなど）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用しても良い。

また、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵ若しくはＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行する。これによっても、本発明の目的が達成されることは言うまでもない。

この場合、コンピュータ読み取り可能な記録媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

このプログラムコードを供給するための記録媒体として、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、次の場合も含まれることは言うまでもない。即ち、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合である。

更に、記録媒体から読出されたプログラムコードがコンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込む。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本実施形態におけるネットワークプロトコル処理装置の構成の一例を示すブロック図である。 ＲＡＭ１０３内のデータを模式的に表した図である。 管理テーブル２０２に格納されている管理エントリを詳細に示した図である。 ビットテーブル領域２０３に格納されているビットテーブルを詳細に示した図である。 リアセンブルリセット処理の処理手順を示すフローチャートである。 リアセンブル通常処理の処理手順を示すフローチャートである。 リアセンブルターミネート処理の処理手順を示すフローチャートである。 ビットテーブル移行処理の処理手順を示すフローチャートである。 本実施形態におけるＩＰデータグラムの受信処理を示すフローチャートである。 本実施形態における条件Ｂに合致する場合の一例を示す図である。 単位サイズを約数倍に変更した場合の一例を示す図である。

符号の説明

１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ ＭＡＣ
１０５ ＰＨＹ
１０６ ＤＭＡＣ
１０７ バス
２０１ 受信データ領域
２０２ 管理テーブル
２０３ ビットテーブル領域
２０４ リアセンブルバッファ

Claims (5)

1. フラグメント化されたＩＰデータグラムを受信してリアセンブル処理するネットワークプロトコル処理装置であって、
   受信したフラグメント化されたＩＰデータグラムのペイロードデータのサイズに基づいて前記リアセンブル処理に用いるビットマップテーブルの単位サイズを決定する決定手段と、
   前記決定手段によって決定された単位サイズに応じてビットマップテーブルを生成する生成手段と、
   前記生成手段によって生成されたビットマップテーブルを用いて前記ＩＰデータグラムをリアセンブル処理する処理手段と、を有し、
   前記生成手段は、前記決定手段によって決定された単位サイズが、既存のビットマップテーブルの単位サイズの整数倍である場合にはビットマップテーブルを生成せず、整数倍でない場合には前記ＩＰデータグラムのペイロードデータのサイズと前記既存のビットマップテーブルの単位サイズとの公約数を単位サイズとするビットマップテーブルを生成する
   ことを特徴とするネットワークプロトコル処理装置。
2. 前記ＩＰデータグラムのペイロードデータのサイズは、前記受信したフラグメント化されたＩＰデータグラムのペイロードデータに含まれるＩＰデータグラムのペイロードデータの先頭からのオフセットを示す値とＩＰデータグラム全体の長さとから算出される
   ことを特徴とする請求項１に記載のネットワークプロトコル処理装置。
3. フラグメント化されたＩＰデータグラムを受信してリアセンブル処理するネットワークプロトコル処理装置の処理方法であって、
   決定手段が、受信したフラグメント化されたＩＰデータグラムのペイロードデータのサイズに基づいて前記リアセンブル処理に用いるビットマップテーブルの単位サイズを決定する決定工程と、
   生成手段が、前記決定工程において決定された単位サイズに応じてビットマップテーブルを生成する生成工程と、
   処理手段が、前記生成工程において生成されたビットマップテーブルを用いて前記ＩＰデータグラムをリアセンブル処理する処理工程と、を有し、
   前記生成工程は、前記決定工程において決定された単位サイズが、既存のビットマップテーブルの単位サイズの整数倍である場合にはビットマップテーブルを生成せず、整数倍でない場合には前記ＩＰデータグラムのペイロードデータのサイズと前記既存のビットマップテーブルの単位サイズとの公約数を単位サイズとするビットマップテーブルを生成する
   ことを特徴とするネットワークプロトコル処理装置の処理方法。
4. コンピュータを請求項１または２に記載のネットワークプロトコル処理装置の各手段として機能させるためのプログラム。
5. 請求項４に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images