(57)【特許請求の範囲】
【請求項１】
複数のフラグメントに分割されて送信されたパケットを送信装置から受信する受信装置であって、
前記複数のフラグメントの到着状況を管理するビットテーブルを記憶する記憶手段と、
前記送信装置から送信されたフラグメントのサイズを検出する検出手段と、
前記検出されたフラグメントのサイズに応じたサイズの前記ビットテーブルを記憶する領域を前記記憶手段に確保すると共に、前記ビットテーブルに含まれる１ビットが、前記検出手段により検出したサイズの１つのフラグメントの到着状況を示すように前記ビットテーブルを管理する管理手段と、
を備えることを特徴とする受信装置。
【請求項２】
前記フラグメントのサイズは、
前記送信装置から当該受信装置までの通信経路の最大転送単位を判定するために前記送信装置から送信された、分割サイズがセットされたパケットにより前記送信装置から通知される
ことを特徴とする請求項１に記載の受信装置。
【請求項３】
前記フラグメントのサイズは、各フラグメントのヘッダに記載して通知される
ことを特徴とする請求項１に記載の受信装置。
【請求項４】
パケットを送信する送信装置と、該パケットを受信する受信装置と、を備える通信システムであって、
前記送信装置は、
送信するパケットを所定の分割サイズで複数のフラグメントに分割する分割手段と、
前記分割サイズを前記受信装置へ通知する通知手段と、
分割した前記複数のフラグメントを前記受信装置へ順次送信する送信手段と、
を備え、
前記受信装置は、
前記複数のフラグメントの到着状況を管理するビットテーブルを記憶する記憶手段と、
前記送信装置から送信されたフラグメントのサイズを検出する検出手段と、
前記検出されたフラグメントのサイズに応じたサイズの前記ビットテーブルを記憶する領域を前記記憶手段に確保すると共に、前記ビットテーブルに含まれる１ビットが、前記検出手段により検出したサイズの１つのフラグメントの到着状況を示すように前記ビットテーブルを管理する管理手段と、
を備える
ことを特徴とする通信システム。
【請求項５】
複数のフラグメントの到着状況を管理するビットテーブルを記憶する記憶手段を備え、前記複数のフラグメントに分割されて送信されたパケットを送信装置から受信する受信装置の受信方法であって、
前記送信装置から送信されたフラグメントのサイズを検出する検出工程と、
前記検出されたフラグメントのサイズに応じたサイズの前記ビットテーブルを記憶する領域を前記記憶手段に確保すると共に、前記ビットテーブルに含まれる１ビットが、前記検出工程において検出したサイズの１つのフラグメントの到着状況を示すように前記ビットテーブルを管理する管理工程と、
を有することを特徴とする受信方法。
【請求項６】
複数のフラグメントに分割してパケットを送信する送信装置と、前記複数のフラグメントの到着状況を管理するビットテーブルを記憶する記憶手段を備え、該パケットを受信する受信装置と、を備える通信システムにおける通信方法であって、
前記送信装置において、
送信するパケットを所定の分割サイズで複数のフラグメントに分割する分割工程と、
前記分割サイズを前記受信装置へ通知する通知工程と、
分割された前記複数のフラグメントを前記受信装置へ順次送信する送信工程と、
前記受信装置において、
前記通知工程において通知されたフラグメントの前記分割サイズを検出する検出工程と、
前記検出されたフラグメントのサイズに応じたサイズの前記ビットテーブルを記憶する領域を前記記憶手段に確保すると共に、ビットテーブルに含まれる１ビットが、前記検出工程において検出したサイズの１つのフラグメントの到着状況を示すように前記ビットテーブルを管理する管理工程と、
を有することを特徴とする通信方法。
【請求項７】
コンピュータを、請求項１から３のいずれか１項に記載の受信装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信装置及びその方法、通信システム及びその方法、並びに、プログラムに関し、特に、フラグメントされたパケットをビットテーブルを利用してリアセンブルする技術に関する。
【背景技術】
【０００２】
コンピュータネットワークのネットワーク層（インターネット層）においてはインターネット・プロトコル（ＩＰ：Internet Protocol）が広く使用されている。そして、インターネット・プロトコルでは、データの送信装置が送信するＩＰデータグラムをフラグメントと呼ばれる断片にフラグメント（分割）し、受信装置で受信したフラグメントをリアセンブル（組み立て）することが規定されている（非特許文献１）。ＩＰデータグラムのフラグメント／リアセンブルは、通信経路に転送可能なパケットサイズが小さい経路が存在する場合でもサイズの大きなパケットを転送可能にするための処理である。
【０００３】
データを送受信するときにＩＰデータグラムをフラグメントおよびリアセンブルする場合、受信装置は、どのフラグメントが受信済みで、どのフラグメントが未受信であるかを区別する必要がある。
【０００４】
受信済みのフラグメントの区別は、一般に、フラグメントブロックビットテーブル（以下、ビットテーブル）を用いて行われている（非特許文献１）。ビットテーブルは、各ビットがＩＰデータグラムを構成する各フラグメントに対応づけられたテーブルである。受信装置は、フラグメントの受信に応じて、ビットテーブル中の対応するビットを（例えば、値１に）セットすることで、受信済みのフラグメントと未受信のフラグメントを区別する。
【０００５】
ビットテーブルを利用したリアセンブルを行う場合、データの受信装置は、８１９２ビットサイズのビットテーブルを確保する必要がある。これは、フラグメント前のＩＰデータグラムの最大ペイロードサイズが６４Ｋバイトで、フラグメントの最小サイズが８バイトであるということの他に、受信装置は、ＩＰデータグラムとフラグメントのサイズについて事前に知ることができないためである。ＩＰデータグラムのペイロードサイズは６４Ｋバイト以下の範囲の値をとることができ、フラグメントのサイズは８バイト以上の範囲の値をとることができる。つまり、６４ＫバイトのＩＰデータグラムが８バイト単位でフラグメントされたときに備えて、受信装置は、８１９２（６４Ｋバイト÷８バイト）ビットサイズのビットテーブルを確保しておく必要があるのである。
【０００６】
なお、非特許文献１には、フラグメントに関連する情報として、ＩＰデータグラムのヘッダに以下の２フィールドが記載されることが規定されている。
（１）ＦＯ（Fragment Offset）：フラグメント処理前のＩＰデータグラムのペイロードのオフセット。
（２）ＭＦ（More Fragment flag）：後続のフラグメントパケットが存在するかを示すフラグ。
【０００７】
フラグメントされた終端のＩＰデータグラムのＩＰヘッダのＭＦはセットされていないが、それ以外のすべてのフラグメントされたＩＰデータグラムのＩＰヘッダのＭＦはセットされていることとなる。したがって、フラグメントされた終端のＩＰデータグラムを受信しない限り、受信装置は、フラグメント前のＩＰデータグラムのペイロードサイズを判別できない。よって、受信装置は、ＩＰデータグラムの最大ペイロードサイズである６４Ｋバイトに対応した８１９２ビットのビットテーブルを予め準備しておかなければならない。
【０００８】
また、ＩＰデータグラムの送信装置と受信装置の間には、様々なルータとルータを接続する通信網が存在するが、いずれのルータも、フラグメント対象のＩＰデータグラムがどのようなサイズにフラグメントされて受信装置に到着するかを知る術はない。よって、受信装置は、８バイト単位でフラグメントされた場合を想定したビットテーブルを準備しておかなければならない。
【非特許文献１】ＲＦＣ７９１「インターネット・プロトコル」、インターネット〈www.ietf.org/rfc/rfc0791.txt〉
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上記のように、従来の構成では、ＩＰデータグラムのサイズが６４Ｋバイトに満たない場合や、フラグメントのサイズが８バイトを超える場合（例えば、１Ｋバイト）でも、受信装置は８１９２ビットサイズ分のビットテーブルを確保しておく必要があった。しかし、このような制約は、ＩＰデータグラムのペイロードサイズが６４Ｋバイトより小さい場合や、各フラグメントのサイズが８バイトよりも大きな値で固定されている場合には、ビットテーブルの領域が無駄に確保されることとなる。
【００１０】
特に、組み込みシステム等のメモリサイズが限られているプラットフォームでは、システム全体のパフォーマンス低下や、システム構築時のコストの増加が懸念される。
【００１１】
また、リアセンブル処理はネットワークプロトコル処理において処理負荷の重い処理として知られているため、ビットテーブル領域は高速だが高価なＳＲＡＭ等で実装する必要がある。したがって、従来の構成では、無駄になる可能性のあるビットテーブルの領域を確保するために高価なＳＲＡＭを無駄に使用する必要があった。
【００１２】
本発明は上記課題に鑑みなされたものであり、フラグメントされたパケットを管理するための回路規模を小型化することを可能にする技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、本発明による受信装置は以下の構成を備える。即ち、
複数のフラグメントに分割されて送信されたパケットを送信装置から受信する受信装置であって、
前記複数のフラグメントの到着状況を管理するビットテーブルを記憶する記憶手段と、
前記送信装置から送信されたフラグメントのサイズを検出する検出手段と、
前記検出されたフラグメントのサイズに応じたサイズの前記ビットテーブルを記憶する領域を前記記憶手段に確保すると共に、前記ビットテーブルに含まれる１ビットが、前記検出手段により検出したサイズの１つのフラグメントの到着状況を示すように前記ビットテーブルを管理する管理手段と、
を備える。
【００１４】
また、本発明による通信システムは以下の構成を備える。即ち、
パケットを送信する送信装置と、該パケットを受信する受信装置と、を備える通信システムであって、
前記送信装置は、
送信するパケットを所定の分割サイズで複数のフラグメントに分割する分割手段と、
前記分割サイズを前記受信装置へ通知する通知手段と、
分割した前記複数のフラグメントを前記受信装置へ順次送信する送信手段と、
を備え、
前記受信装置は、
前記複数のフラグメントの到着状況を管理するビットテーブルを記憶する記憶手段と、
前記送信装置から送信されたフラグメントのサイズを検出する検出手段と、
前記検出されたフラグメントのサイズに応じたサイズの前記ビットテーブルを記憶する領域を前記記憶手段に確保すると共に、前記ビットテーブルに含まれる１ビットが、前記検出手段により検出したサイズの１つのフラグメントの到着状況を示すように前記ビットテーブルを管理する管理手段と、
を備える。
【発明の効果】
【００１６】
本発明によれば、フラグメントされたパケットを管理するための回路規模を小型化することを可能にする技術を提供することができる。
【発明を実施するための最良の形態】
【００１７】
以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。また、本実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。
【００１８】
＜＜第１実施形態＞＞
（ネットワークプロトコル処理装置）
図１は、本発明の第１実施形態に係るネットワークプロトコル処理装置１００を説明する図である。このネットワークプロトコル処理装置１００は、ＩＰデータグラム（パケット）を送信する送信装置と、該ＩＰデータグラムを受信する受信装置とを備える通信システムにおいて、送信装置と受信装置との少なくともいずれかとして動作する。
【００１９】
図１において、１０１はＣＰＵであり、ＴＣＰ／ＩＰに準拠したネットワークプロトコル処理をソフトウェアにより実行して、ネットワークプロトコル処理装置１００の動作を制御する。１０２はＲＯＭであり、ＣＰＵ１０１が実行するソフトウェアが格納されている。１０３はＲＡＭであり専らＣＰＵ１０１の実行ワークエリアとして使用される。
【００２０】
１０４はＭＡＣ（Media Access Controller）、１０５はＰＨＹ（PHYsical layer）であり、メディア層以下の通信制御を行う。１０６はＤＭＡＣ（Direct Memory Access Controller）であり、ＴＣＰ／ＩＰネットワークで送受信するデータのＲＡＭ１０３とＭＡＣ１０４間の転送を管轄する。１０７はバスであり、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、ＭＡＣ１０４、ＤＭＡＣ１０６を相互接続する。
【００２１】
ＲＡＭ１０３は安価なＤＲＡＭ（オフチップ）で実現される場合が一般的であるが、より高速なオンチップＳＲＡＭで実現してもよい。しかし、オンチップＳＲＡＭは高価なため、本実施形態で想定しているＲＡＭ１０３に格納するデータ全てを格納可能なサイズ分を搭載するのは難しい可能性もある。このような場合には、安価であるが低速なＤＲＡＭと高価であるが高速なオンチップＳＲＡＭの組合せで実現してもよい。つまり、頻繁にアクセスするデータやネットワークプロトコル処理性能に大きく影響するデータ等を高速なオンチップＳＲＡＭに配置し、その他のデータをＤＲＡＭに配置する形態である。本実施形態は、ＤＲＡＭ及びオンチップＳＲＡＭ、またその他の記憶媒体のいずれで実施されてもよく、全てを包含してＲＡＭ１０３と呼ぶ。
【００２２】
ところで、ＲＡＭ１０３は、ＣＰＵの実行ワークエリアとして使用されるだけでなく、ＴＣＰ／ＩＰネットワークプロトコル処理を実行するために必要となるデータの格納領域としても使用される。当該データには、ＴＣＰ／ＩＰネットワーク通信において送受信するデータ、後述するビットテーブル、及び当該ビットテーブル管理情報のテーブル等が含まれる。以下、管理情報のテーブルを管理テーブルと呼ぶ。また、管理テーブルに格納される各ビットテーブルの管理情報を管理エントリと呼ぶ。
【００２３】
（データ構造）
図２は、ＲＡＭ１０３内のデータの構造を模式的に表した図である。図２には本実施形態を説明するために必要なデータのみ示しているため、図示しないがネットワークプロトコル処理を実現するために必要なデータは他にも存在しうる。例えば、ＣＰＵ１０１が処理するワークデータ等がそれに該当する。
【００２４】
図２において、２０１は送信データ領域であり、送信すべきＩＰデータグラム（パケット）が格納される。２０２は受信データ領域であり、受信したＩＰデータグラムが格納される。２０３はフラグメントサイズテーブルであり、フラグメントサイズ情報が格納される。２０４は管理テーブルであり、ビットテーブルの管理情報である管理エントリが格納される。管理エントリは、関連付けられたビットテーブルとともに、主にリアセンブル処理の開始時に生成され、リアセンブル処理終了まで、リアセンブル処理対象のＩＰデータグラムの情報を保持する。
【００２５】
２０５はビットテーブル領域であり、ビットテーブル本体が格納される。全てのビットテーブルは、所定の管理エントリに１対１で関連付けられている。２０６はリアセンブルバッファであり、リアセンブル処理中のＩＰデータグラムのペイロードデータが格納される。
【００２６】
ここで、リアセンブルバッファ２０６には、リアセンブル処理中のＩＰデータグラムのペイロードデータが格納されるが、その格納方法にはさまざまな選択肢がある。リアセンブル処理中のペイロードデータはフラグメントされているが、フラグメント前のペイロードデータに対して先頭から順番に到着する訳ではない。また、既に到着している部分に重複したペイロードデータが後から到着することも考えられる。そのため、一般的な格納方法としては、フラグメント前の最大ペイロードデータサイズである６４ＫＢ分のデータ領域をリアセンブル処理開始時に確保し、受信したＩＰデータグラムのペイロードデータを適宜対応する部分に格納していくという手法がある。
【００２７】
また他の方法として、リンクリストを活用する方法もある。これは、細切れで格納されているデータに対し、所定のデータの後に続くデータの格納場所を示すリンク情報を別途管理することで、仮想的に一続きのデータに見せるという手法である。この手法のメリットは、予め６４ＫＢという大きいデータ領域を確保することなく、到着したＩＰデータグラムを順番に関係なく空いている領域に格納していけばよいということである。こうすることで、例えばフラグメント前のペイロードサイズが１ＫＢであった場合などは、６４ＫＢものデータ領域を確保する必要が無く、メモリ領域を有効に活用できる。
【００２８】
前者の方法は主にハードウェアでリアセンブル処理を行う場合に用いられ、ソフトウェアでリアセンブル処理を行う場合は後者の手法が用いられることが一般的である。リアセンブルバッファの管理は、上記いずれの方法でも、また他の方法でも、最終的にフラグメント前のペイロードデータを再合成可能な方法であればどのようなものでもよい。
【００２９】
なお、送信データ領域２０１はネットワークプロトコル処理装置１００が送信装置として動作するときに主に使用される。そして、受信データ領域２０２、フラグメントサイズテーブル２０３、管理テーブル２０４、ビットテーブル領域２０５、リアセンブルバッファ２０６は、受信装置として動作するときに主に使用される。
【００３０】
次に、図３、図４及び図５を用いて、フラグメントサイズテーブル２０３内のフラグメントサイズ情報、管理テーブル２０４内の管理エントリと、ビットテーブル領域２０５内のビットテーブルの関係について説明する。図３はフラグメントサイズテーブル２０３に格納されているフラグメントサイズ情報を詳細に示した図である。図４は管理テーブル２０４に格納されている管理エントリを詳細に示した図である。一方、図５はビットテーブル領域２０５に格納されているビットテーブルを詳細に示した図である。
【００３１】
◆フラグメントサイズ情報
図３において、３０１は送信元アドレスであり、これはＩＰヘッダに格納されている送信元アドレス（Source Address）フィールドの値に一致する。３０２は宛先アドレスであり、同じくＩＰヘッダの宛先アドレス（Destination Address）フィールドの値に一致する。３０３はフラグメントサイズであり、ＩＰヘッダ内ＩＰオプションに設定されたフラグメントサイズの値に一致する。フラグメントサイズ３０３はリアセンブル処理に使用するビットテーブルの単位サイズであり、ビットテーブルの１ビットが何バイトに対応するかを示している。
【００３２】
◆管理エントリ
図４において、４０１は送信元アドレスであり、これはＩＰヘッダに格納されている送信元アドレス（Source Address）フィールドの値に一致する。４０２は宛先アドレスであり、同じくＩＰヘッダの宛先アドレス（Destination Address）に一致する。４０３は識別子であり、同じくＩＰヘッダの識別子(Identification)に一致する。送信元アドレス４０１、宛先アドレス４０２、及び識別子４０３はリアセンブル処理対象のＩＰデータグラム（パケット）を特定するために使用される。４０４はビットテーブルポインタであり、当該管理エントリに関連付けられているビットテーブルのＲＡＭ１０３内の格納アドレスを示している。
【００３３】
◆ビットテーブル
図５において、５０１は初期化時のビットテーブル本体を示しており、５０２は所定のリアセンブル処理中のビットテーブル本体を示している。ビットテーブルの各ビット(５０１-１〜５０１-５、５０２-１〜５０２-５等)はペイロードが受信済みか否かを示しており、”１”がセットされている場合は受信済みを示している。逆に、”０”がセットされている場合は未受信であることを示している。ビットテーブル初期化時は、全てのペイロードデータが未受信であるため、全ビットが”０”にセットされている。
【００３４】
ここで例を挙げてフラグメントサイズ３０３とビットテーブルの関係を説明する。所定のフラグメントサイズ情報のフラグメントサイズ３０３が１ＫＢ（=１０２４バイト）であったとする。また、当該フラグメントサイズ情報の送信元アドレス３０１と宛先アドレス３０２が送信元アドレス４０１と宛先アドレス４０２と一致する管理エントリに関連付けられたビットテーブルが、図５における５０２の状態であったとする。ここで、このビットテーブルは、ビットテーブルポインタ４０４が示す格納先アドレスビットテーブルに相当する。
【００３５】
このとき、ビット５０２-１、５０２-２、５０２-３、５０２-４、５０２-５は、それぞれ１ＫＢ分のペイロードデータに対応する。よって、ビット５０２-１に”１”がセットされているのは、フラグメント前のＩＰデータグラムのペイロードの内、先頭から１ＫＢのデータが既に受信されていることを示している。同じように、ビット５０２-４に”１”がセットされているのは、先頭からのオフセット３ＫＢからの１ＫＢ分のデータが既に受信されていることを示す。逆に、”０”がセットされているビット５０２-２、５０２-３、５０２-５は該当部分の１ＫＢ分のデータはまだ受信されていないことを示す。
このようにして、ビットテーブルは、送信装置から通知されたフラグメントのサイズ毎に、フラグメントの到着状況を管理する。
【００３６】
（ＭＴＵ探索処理）
本実施形態では、送信装置が、フラグメントのサイズが埋め込まれた判定用データグラムを送信して、受信装置までの通信経路についてＭＴＵ（Maximum Transmission Unit）探索を行う。そして、受信装置から受信した受信確認に対応する判定用データグラムに埋め込まれたフラグメントサイズでＩＰデータグラムをフラグメントに分割し、各フラグメントを受信装置へ順次送信する。ここで、後述するように、受信装置は、ＭＴＵ探索の処理の途中で、フラグメントのサイズに等しいＭＴＵを知ることができる。このように、本実施形態では、受信装置は、ＩＰデータグラムのフラグメントを受信する前にフラグメントのサイズを知ることができるため、そのフラグメントのサイズに応じて必要最小限のサイズのビットテーブルを確保することができる。
【００３７】
そこで、本実施形態における処理の前提となるＭＴＵ探索処理について説明する。ネットワーク層の通信プロトコルにＩＰを用いるネットワーク通信では、下位層のデータリンク層における最大転送単位（ＭＴＵ）がそのデータリンク層に用いられる通信プロトコルに応じで決まっている。そのため、送信装置は、ＩＰは送信すべきデータを下位層のＭＴＵ以下に分割するフラグメント処理して送信する必要がある。このフラグメント処理を実行するためには大きな負荷がかかるため、他の通信パケットに対する処理に支障が出る場合もある。よって、通信経路の途中でのフラグメント処理を不要にするために、送信装置は、受信装置までの通信経路におけるＭＴＵ（以下、「パスＭＴＵ」）を予め探索し、探索したパスＭＴＵ以下送信すべきデータをフラグメント処理する。なお、ＩＰv４のパスＭＴＵについてはＲＦＣ１１９１に規定されている。このパスＭＴＵの探索はパスＭＴＵ探索と呼ばれる。
【００３８】
パスＭＴＵ探索では、まず、送信元の装置は最初にサイズの大きなＩＰデータグラムの分割禁止フラグを立て送信する。これを受信したルータ装置では、次の中継先の経路におけるＭＴＵを参照し、フラグメント処理の実行が必要であるか判断する。フラグメント処理の実行が必要である場合、分割禁止フラグが立っているため、ルータ装置は受信したＩＰデータグラムを破棄し、ＩＣＭＰ(Internet Control Message Protocol)の到達不能メッセージを送信装置に返信する。この到達不能メッセージには、次の中継先の経路におけるＭＴＵが格納されており、この到達不能メッセージを受信した送信元の装置は、この到達不能メッセージによって通知されたＭＴＵ以下にフラグメント処理を行い送信する。送信元の装置は、これを送信先の装置にＩＰデータグラムが届くまで繰り返すことによって、パスＭＴＵを探索する。
【００３９】
具体的には、例えば、送信したＩＣＭＰｅｃｈｏに対応するＩＣＭＰｒｅｐｌｙの受信可否に基づいてパスＭＴＵを調査することが知られている（例えば、特開２００３−１８２１６号公報）。ここでは、ＤＦ（分割禁止）フラグを設定したＩＣＭＰｅｃｈｏをＩＰパケットサイズを変えながら送信し、このＩＣＭＰｅｃｈｏに対応するＩＣＭＰｒｅｐｌｙを受信装置から受信できたかに基づいてパスＭＴＵを調査する。
【００４０】
（送信処理）
続いて、図１の第１実施形態におけるネットワークプロトコル処理装置１００の動作について説明する。まず送信装置として動作する場合の動作について図６を用いて説明する。図６は送信処理の手順を示すフローチャートである。
【００４１】
ネットワークプロトコル処理装置１００のＣＰＵ１０１はコネクション確立後、ステップＳ６０１においてパスＭＴＵ探索を行う。すなわち、受信装置までの通信経路の最大転送単位（ＭＴＵ）を判定する判定処理を実行する。ＭＴＵの判定では、まず、分割禁止フラグがセットされたＩＰデータグラムを判定用データグラムとして受信装置へ送信する。そして、この判定用データグラムに対応する到達確認データグラムを受信装置から受信するまで、よりサイズの小さい判定用データグラムを受信装置へ送信する処理を繰り返す。受信装置からの到達確認データグラムを受信したら、当該到達確認データグラムに対応する判定用データグラムのサイズをＭＴＵと判定する。
【００４２】
具体的には、例えば、ＤＦ（分割禁止）フラグを設定したＩＣＭＰｅｃｈｏを、ＩＰデータグラムサイズを変えながら送信する。そして、ＩＣＭＰｅｃｈｏに対応する送信先の装置（受信装置）からのＩＣＭＰｒｅｐｌｙを送信元の装置で受信できるかを判定することによりパスＭＴＵを調査する。ＩＰデータグラムサイズの初期値は送信元の装置におけるＭＴＵ値となり、ＩＣＭＰ到達不能メッセージを受信する毎に、ＩＣＭＰ到達不能メッセージ内に格納されたＭＴＵ値を更新する。受信装置からＩＣＭＰｒｅｐｌｙを受信したら、送信装置は、それ以降はそのＩＣＭＰｒｅｐｌｙに対応するＩＣＭＰｅｃｈｏのサイズをフラグメントのサイズと決定する。
【００４３】
ＣＰＵ１０１はパスＭＴＵ探索を行うＩＰデータグラム（パケット）のＩＰヘッダのＩＰオプションに以下の値をセットする。
・パスＭＴＵ探索を行うＩＰデータグラムであることを示すパスＭＴＵ探索識別子（１バイト）
・当該パスＭＴＵ探索ＩＰデータグラムによりパスＭＴＵが判明した場合に、以後に送信されるＩＰデータグラムを何バイトでフラグメントするかを示すフラグメント（分割）サイズ（２バイト）。
ここで、フラグメントサイズは以下のように決定される。
・（ＩＰデータグラムサイズ−２０バイト）以下、かつ、８バイトで割り切れる数。
これにより、送信先の装置（受信装置）はパスＭＴＵ探索識別子が設定されたＩＣＭＰｅｃｈｏを受信すると、以後のＩＰデータグラムが何バイトでフラグメントされるかを予め知ることができる。つまり、本実施形態では、送信装置は、パスＭＴＵ探索識別子と共に分割サイズがセットされたＩＰデータグラムを判定用データグラムとして受信装置へ送信することで、ＩＰデータグラムの分割サイズを受信装置へ通知する通知処理を行っている。
【００４４】
ステップＳ６０２において、ＣＰＵ１０１はＲＡＭ１０３の送信データ領域２０１上に送信すべきデータが存在するかを判定する。ステップＳ６０２で送信すべきデータが存在した場合（ステップＳ６０２でＹＥＳ）はステップＳ６０３へ進み、存在しない場合（ステップＳ６０２でＮＯ）はそのまま待機する。
【００４５】
ステップＳ６０３ではステップＳ６０１で送信先の装置に到着したＩＣＭＰｅｃｈｏに設定したフラグメントサイズとＲＡＭ１０３の送信データ領域２０１上の送信すべきデータのサイズを比較する。ステップＳ６０３で送信すべきデータのサイズがフラグメントサイズ以上であると判定された場合（ステップＳ６０３でＹＥＳ）はステップＳ６０４へ進み、そうでないと判定された場合（ステップＳ６０３でＮＯ）はステップＳ６０６へ進む。
【００４６】
ステップＳ６０４では、ＣＰＵ１０１は送信すべきデータを、ステップＳ６０１で決定したフラグメントサイズ単位にフラグメント（分割）する処理を実行する。すなわち、ステップＳ６０１で決定した分割サイズで、送信するＩＰデータグラムを複数のフラグメントに分割する。次に、ステップＳ６０５でフラグメントされたデータに対してＩＰヘッダを作成し、ＩＰデータグラムを生成する。そして、ステップＳ６０７へ進む。
【００４７】
一方、ステップＳ６０３で送信すべきデータがフラグメントサイズより小さいと判定された場合（ステップＳ６０３でＮＯ）、ステップＳ６０６で送信すべきデータに対してＩＰヘッダを作成し、ＩＰデータグラムを生成する。そして、ステップＳ６０７へ進む。
【００４８】
ステップＳ６０７においては、ＣＰＵ１０１はＤＭＡＣ１０６を起動し、ＤＭＡＣ１０６はＲＡＭ１０３上のフラグメントされたＩＰデータグラムをＭＡＣ１０４、ＰＨＹ１０５へ転送し、ＩＰデータグラムをネットワークへ送信する。すなわち、分割した複数のフラグメントを受信装置へ順次送信する。ステップＳ６０７にてＤＭＡＣ１０６を起動後、ＣＰＵ１０１はステップＳ６０２に戻り、ＲＡＭ１０３の送信データ領域２０１上に送信すべきデータが存在するかを判定し、送信すべきデータが存在する場合は前述した処理を繰り返す。
【００４９】
（受信処理）
次に受信装置として動作する場合の動作について図７を用いて説明する。図７は受信処理の手順を示すフローチャートである。
【００５０】
受信装置は、送信装置から送信された、ＩＰデータグラム（パケット）の複数のフラグメント等を受信する。ＭＡＣ１０４、ＰＨＹ１０５がＩＰデータグラムを受信すると割り込み信号をＣＰＵ１０１へ通知する。割り込みを通知されたＣＰＵ１０１はＤＭＡＣ１０６を起動し、受信したＩＰデータグラムをＭＡＣ１０４、ＰＨＹ１０５からＲＡＭ１０３の受信データ領域２０２へ転送させる。ＲＡＭ１０３上の受信データ領域２０２に処理すべきＩＰデータグラムが存在する場合に、図７のフローチャートに従って受信処理を行う。
【００５１】
ステップＳ７０１ではＩＰヘッダの解析を行う。ステップＳ７０２では、解析結果を基に、ＩＰデータグラムがフラグメントされているかを判定する。フラグメントされているか否かは、ＩＰヘッダにおけるＭＦフラグ及びフラグメントオフセットフィールドにより判定する。ステップＳ７０２において、ＩＰデータグラムがフラグメントされていると判定された場合（ステップＳ７０２でＹＥＳ）はステップＳ７０３へ進み、そうでない場合（ステップＳ７０２でＮＯ）はステップＳ７０９へ進む。
【００５２】
なお、上述のように、本実施形態では、送信装置は、ＭＴＵ探索の後に送信するＩＰデータグラムのフラグメント／送信を開始する。ここで、パスＭＴＵ探索識別子がセットされたＩＰデータグラムは分割禁止のフラグがセットされている。したがって、受信装置は、ＭＴＵ探索のためのＩＰデータグラムを受信すると、まずはステップＳ７０９へ移行することになる。後述のように、受信装置は、ＭＴＵ探索のためのＩＰデータグラムにセットされているフラグメントサイズを元にフラグメントのサイズを判定し、送信元アドレス、宛先アドレス、フラグメントサイズ等をフラグメントサイズ情報に登録する（ステップＳ７１０）。送信装置から通知されたフラグメントのサイズは、ＭＡＣ、ＰＨＹ１０６により受信される。
【００５３】
ステップＳ７０３では管理テーブル２０４を検索し、受信したＩＰデータグラムのＩＰヘッダに合致する管理エントリが存在するかを確認する。管理エントリがＩＰヘッダに合致するか否かの判定は、前述したＩＰヘッダ内の送信元アドレス、宛先アドレス、及び識別子が、それぞれ管理エントリの送信元アドレス４０１、宛先アドレス４０２、及び識別子４０３と一致するかを判定する。
【００５４】
上記３項目が一致する管理エントリが存在しない場合、受信したＩＰデータグラムに対するリアセンブル処理はまだ開始されていない、つまり、当該ＩＰヘッダを持つＩＰデータグラムのリアセンブル処理を開始する必要があることを意味する。そのため、管理エントリがＩＰヘッダに合致しない場合（ステップＳ７０３でＮＯ）は、ステップＳ７０４で、リアセンブル初期化処理を実行する。
【００５５】
リアセンブル初期化処理において、受信装置は、送信装置から分割サイズが通知されたことに応じて、フラグメントの到着状況を管理するためのビットテーブルを該分割サイズに基づいてメモリに確保する。後述するように、このビットマップテーブルを用いて、送信装置から通知された分割サイズ毎にフラグメントの到着状況を管理する。そして、ＣＰＵ１０１は管理テーブル２０４に対し、新規の管理エントリを作成し、作成した管理エントリの送信元アドレス４０１、宛先アドレス４０２、及び識別子４０３にＩＰヘッダ内の対応するデータを格納する。また、フラグメントサイズテーブル２０３を検索し、受信したＩＰデータグラムのＩＰヘッダに合致するフラグメントサイズ情報が存在するかを確認する。
【００５６】
フラグメントサイズ情報がＩＰヘッダに合致するか否かの判定は、前述したＩＰヘッダ内の送信元アドレス、宛先アドレスがフラグメントサイズ情報の送信元アドレス３０１、宛先アドレス３０２と一致するかを判定して行う。一致した場合は当該フラグメントサイズ情報のフラグメントサイズ３０３からビットテーブルサイズを取得する。具体的には、ＩＰデータグラムの最大ペイロードサイズ６４ＫＢをフラグメントサイズ３０３で除算することで算出する。
【００５７】
例えば、フラグメントサイズ３０３が１ＫＢであるなら算出されるビットテーブルサイズは６４（＝６４ＫＢ÷１ＫＢ）ビットとなる。合致するフラグメントサイズ情報が存在しない場合、上記除算においてフラグメントサイズ３０３は８バイトとされる。このビットテーブルサイズを基に、ビットテーブル領域２０５にビットテーブルを生成し、ビットテーブルを初期化する。ビットテーブルの初期化では、全てのビットを”０”（未受信）にセットする。最後に、作成した管理エントリのビットテーブルポインタ４０４に生成したビットテーブルの格納先アドレスを設定し、ステップＳ７０５へ進む。
【００５８】
一方、ステップＳ７０３で受信したＩＰデータグラムのＩＰヘッダにおける送信元アドレス、宛先アドレス、及び識別子が一致する管理エントリが存在した場合（ステップＳ７０３でＹＥＳ）は、ステップＳ７０４を経由しないでステップＳ７０５へ進む。
【００５９】
ステップＳ７０５では受信したフラグメントについてリアセンブル処理を行う。すなわち、受信したフラグメントの到着状況を、送信装置から通知された分割サイズ毎にビットテーブルで管理する。具体的には、リアセンブル処理では、受信したＩＰデータグラムのＩＰヘッダ内の送信元アドレス、宛先アドレスと送信元アドレス３０１、宛先アドレス３０２が一致するフラグメントサイズ情報を検索する。そして、当該フラグメントサイズ情報のフラグメントサイズ３０３を取得する。さらに、取得したフラグメントサイズ３０３とＩＰヘッダ内のフラグメントオフセットを基に、ビットテーブルポインタ４０４の指し示すビットテーブルの対応するビットに”１”を設定する。ここで、受信したＩＰデータグラムにてＭＦフラグが”０”であった場合はビットテーブルの対応するビット以降のビットに”１”を設定する。そして、ステップＳ７０６へ進む。
【００６０】
ステップＳ７０６では、対象のＩＰデータグラムについてリアセンブル処理が完了したか否か判定する。具体的には、ビットテーブルの全てのビットが”１”にセットされた場合に全てのフラグメントされたＩＰデータグラムを受信した、つまりリアセンブル処理が完了したと判定する。なお、リアセンブル処理の完了を判定する具体的な処理手順はこのような手法に限られるわけでなく、他の方法で実現しても良い。すなわち、リアセンブル処理が完了したと明確に判断可能な方法であれば、いずれの実現方法を用いても構わない。
【００６１】
ステップＳ７０６でリアセンブル処理が未完了と判定された場合（ステップＳ７０６でＮＯ）は、ステップＳ７０１へ戻り、次のＩＰデータグラムのフラグメントを受信したときに再度処理を開始する。ステップＳ７０６でリアセンブル処理を完了したと判定された場合（ステップＳ７０６でＹＥＳ）には、ステップＳ７０７へ進む。
【００６２】
ステップＳ７０７では、ＣＰＵ１０１は受信したＩＰデータグラムのＩＰヘッダ内の送信元アドレス、宛先アドレス、及び識別子と送信元アドレス４０１、宛先アドレス４０２、及び識別子４０３が一致する管理エントリを検索する。そして、当該管理エントリ、及び当該管理エントリ内のビットテーブルポインタ４０４の指し示すビットテーブルを解放する。
【００６３】
その後、ステップＳ７０８ではリアセンブル処理の完了したペイロードデータを上位層へ受け渡す。そして処理を終了する。
【００６４】
一方、ステップＳ７０２において、フラグメントされていないと判定された（ステップＳ７０２でＮＯ）ＩＰデータグラムについては、ステップＳ７０９においてＩＰヘッダ内のＩＰオプションにパスＭＴＵ探索識別子がセットされているか判定する。パスＭＴＵ探索識別子がセットされている場合（ステップＳ７０９でＹＥＳ）はステップＳ７１０へ進む。
【００６５】
ステップＳ７１０では、ＣＰＵ１０１はフラグメントサイズ登録処理を実行する。フラグメントサイズ登録処理において、ＣＰＵ１０１はフラグメントサイズテーブル２０３に対し、ＩＰヘッダ内の送信元アドレス、宛先アドレスがフラグメントサイズ情報の送信元アドレス３０１、宛先アドレス３０２と一致するかを判定する。一致した場合は当該フラグメントサイズ情報のフラグメントサイズ３０３をＩＰヘッダ内のＩＰオプションに設定されたフラグメントサイズで更新する。一致するフラグメントサイズ情報がない場合、ＣＰＵ１０１は新規のフラグメントサイズ情報を作成し、作成したフラグメントサイズ情報の送信元アドレス３０１、宛先アドレス３０２、フラグメントサイズ３０３にＩＰヘッダ内の対応するデータを格納する。そして、ステップＳ７０８へ進む。
【００６６】
一方、ステップＳ７０９において、パスＭＴＵ探索識別子がセットされていない場合（ステップＳ７０９でＮＯ）、ステップＳ７０８へ進み、ＩＰデータグラムのペイロードデータを上位層へ受け渡す。上位層は、通常は、ＴＣＰ処理を行うソフトウェアにより実現されるが、ハードウェアで実現しても構わない。
【００６７】
上記のように、本実施形態において受信装置は、送信装置から分割サイズが通知されたことに応じて、フラグメントの到着状況を管理するためのビットテーブルを該分割サイズに基づいてメモリに確保する。このため、受信装置は、不必要に大きなビットテーブルをメモリに確保せず、メモリを効率的に使用することができ、受信装置で確保が必要なビットテーブルのサイズを小さくすることを可能である。
【００６８】
また、本実施形態において受信装置は、パスＭＴＵ探索パケットに設定されたフラグメントサイズにより、分割サイズを検出するため、本実施形態は、ＭＴＵ探索を行う構成において容易に実装することができる。
【００６９】
以上のようにして、第１実施形態においては、パスＭＴＵ探索時にフラグメント処理を行うサイズを送信装置と受信装置間で共有する。これにより、受信装置ではフラグメントされたＩＰデータグラム（パケット）の到着状況を共有しているサイズ単位で管理することが可能になる。したがって、到着状況を管理するビットテーブルが必要とするサイズを削減することが可能になる。
【００７０】
＜＜第２実施形態＞＞
第１実施形態では、送信装置は、ＭＴＵ探索識別子がセットされたパケットにフラグメントのサイズをセットして、フラグメントのサイズを受信装置に通知していた。本実施形態では、送信装置が、ＩＰデータグラム（パケット）の各フラグメントのＩＰヘッダにフラグメントのサイズを記載して、フラグメントのサイズを受信装置に通知する構成を説明する。
【００７１】
本実施形態に係るネットワークプロトコル処理装置１００の構成は、第１実施形態と同様に図１で示されるため説明を省略する。また、受信装置として動作するネットワークプロトコル処理装置１００がメモリに確保するビットテーブルの構成は、第１実施形態と同様に図５で示されるため説明を省略する。
【００７２】
（データ構造）
図８は、本実施形態に係るネットワークプロトコル処理装置１００のＲＡＭ１０３内のデータを模式的に表した図である。図８には本実施形態を説明するために必要なデータのみ示しているため、図示しないがネットワークプロトコル処理を実現するために必要なデータは他にも存在する。例えば、ＣＰＵ１０１が処理するワークデータ等がそれに該当する。図２と図８を比較して分かるように、本実施形態ではフラグメントサイズテーブルを使用しない。
【００７３】
図８において、８０１は送信データ領域であり、送信すべきＩＰデータグラム（パケット）が格納される。８０２は受信データ領域であり、受信したＩＰデータグラムが格納される。８０３は管理テーブルであり、ビットテーブルの管理情報である管理エントリが格納される。管理エントリは、関連付けられたビットテーブルとともに、主にリアセンブル処理の開始時に生成され、リアセンブル処理終了まで、リアセンブル処理対象のＩＰデータグラムの情報を保持する。
【００７４】
８０４はビットテーブル領域であり、ビットテーブル本体が格納される。全てのビットテーブルは、所定の管理エントリに１対１で関連付けられている。ビットテーブルは、第１実施形態と同様に図５で示される。８０５はリアセンブルバッファであり、リアセンブル処理中のＩＰデータグラムのペイロードデータが格納される。リアセンブルバッファ８０５については、第１実施形態において説明したため、ここでは省略する。
【００７５】
◆管理エントリ
次に、図９を用いて、管理テーブル８０３内の管理エントリと、ビットテーブル領域８０４内のビットテーブルの関係について説明する。図９は管理テーブル８０３に格納されている管理エントリを詳細に示した図である。
【００７６】
図９において、９０１は送信元アドレスであり、これはＩＰヘッダに格納されている送信元アドレス（Source Address）フィールドの値に一致する。９０２は宛先アドレスであり、同じくＩＰヘッダの宛先アドレス（Destination Address）に一致する。９０３は識別子であり、同じくＩＰヘッダの識別子(Identification)に一致する。
【００７７】
送信元アドレス９０１、宛先アドレス９０２、及び識別子９０３はリアセンブル処理対象のＩＰデータグラムを特定するために使用される。９０４はビットテーブル単位サイズであり、関連するビットテーブルの１ビットが何バイトに対応するかを示している。９０５はビットテーブルポインタであり、当該管理エントリに関連付けられているビットテーブルのＲＡＭ１０３内の格納アドレスを示している。
【００７８】
以下例を挙げてビットテーブル単位サイズ９０４とビットテーブルの関係を説明する。所定の管理エントリのビットテーブル単位サイズ９０４が１ＫＢ（＝１０２４バイト）であったとする。また、当該管理エントリに関連付けられたビットテーブル（ビットテーブルポインタ９０５が示す格納先アドレスビットテーブル）が、図５における５０２の状態であったとする。
【００７９】
このとき、ビット５０２-１、５０２-２、５０２-３、５０２-４、５０２-５は、それぞれ１ＫＢ分のペイロードデータに対応する。よって、ビット５０２-１に”１”がセットされているのは、フラグメント前のＩＰデータグラムのペイロードの内、先頭から１ＫＢのデータが既に受信されていることを示している。同じように、ビット５０２-４に”１”がセットされているのは、先頭からのオフセット３ＫＢからの１ＫＢ分のデータが既に受信されていることを示す。一方、”０”がセットされているビット５０２-２、５０２-３、５０２-５は該当部分の１ＫＢ分のデータはまだ受信されていないことを示す。
【００８０】
（送信処理）
続いて、送信装置として動作するネットワークプロトコル処理装置１００の動作について説明する。本実施形態に係る送信装置の動作は第１実施形態と同様に図６で示される。このため、第１実施形態と共通の動作は説明済みのため省略し、第１実施形態と異なる動作のみを説明する。
【００８１】
ＣＰＵ１０１はコネクション確立後、ステップＳ６０１においてパスＭＴＵ探索を行う。パスＭＴＵ探索では、ＤＦフラグを設定したＩＣＭＰｅｃｈｏを、ＩＰデータグラムサイズを変えながら送信し、ＩＣＭＰｅｃｈｏに対応する送信先の装置からのＩＣＭＰｒｅｐｌｙを送信元の装置で受信できるかを判定することによりパスＭＴＵを調査する。
【００８２】
ステップＳ６０２では、ＣＰＵ１０１はＲＡＭ１０３の送信データ領域２０１上に送信すべきデータが存在するかを判定する。ステップＳ６０２で送信すべきデータが存在した場合、ステップＳ６０３ではステップＳ６０１で探索したパスＭＴＵサイズからフラグメントサイズを算出する。フラグメントサイズは（パスＭＴＵ−２４バイト）以下、かつ、８バイトで割り切れる最大数として算出される。そして、算出したフラグメントサイズとＲＡＭ１０３の送信データ領域８０１上の送信すべきデータのサイズを比較する。
【００８３】
ステップＳ６０３で送信すべきデータがフラグメントサイズより大きいと判定された場合に、ステップＳ６０４でＣＰＵ１０１は送信すべきデータをフラグメントサイズ単位にフラグメント処理を実行する。
【００８４】
そして、ステップＳ６０５でフラグメントされたデータに対してＩＰヘッダを作成し、ＩＰデータグラムを生成する。ＩＰヘッダを生成する際、ＣＰＵ１０１はＩＰオプションにフラグメントサイズ設定フラグ（１バイト）とフラグメントサイズ（２バイト）をセットする。これにより、送信先の装置がこのフラグメントされたＩＰデータグラムのいずれかを受信すると、以後のＩＰデータグラムが何バイトでフラグメントされるかを知ることができる。
【００８５】
ステップＳ６０６とステップＳ６０７における処理は第１実施形態と同様である。ステップＳ６０７にてＤＭＡＣ１０６を起動後、ＣＰＵ１０１はステップＳ６０２に戻り、ＲＡＭ１０３の送信データ領域８０１上に送信すべきデータが存在するかを判定し、送信すべきデータが存在する場合は前述した処理を繰り返す。
【００８６】
（受信処理）
次に受信装置として動作するネットワークプロトコル処理装置１００の動作について説明する。本実施形態に係る受信装置の動作は、第１実施形態における動作と一部が共通する。このため、第１実施形態と異なる動作のみを図７を参照して説明し、第１実施形態と共通の動作は説明済みのため省略する。なお、本実施形態では、ステップＳ７０２でＮＯの場合はステップＳ７０８へ進み、ステップＳ７０９、ステップＳ７１０の処理は行わない。
【００８７】
ＭＡＣ１０４、ＰＨＹ１０５がＩＰデータグラム（パケット）を受信すると割り込み信号をＣＰＵ１０１へ通知する。割り込みを通知されたＣＰＵ１０１はＤＭＡＣ１０６を起動し、受信したＩＰデータグラムをＭＡＣ１０４、ＰＨＹ１０５からＲＡＭ１０３の受信データ領域８０２へ転送させる。ＲＡＭ１０３上の受信データ領域８０２に処理すべきＩＰデータグラムが存在する場合に、図７のフローチャートに従って受信処理を行う。
【００８８】
ステップＳ７０１ではＩＰヘッダの解析を行う。ステップＳ７０２では、解析結果を基に、ＩＰデータグラムがフラグメントされているかを判定する。この判定は第１実施形態と同様に行うことができる。
【００８９】
ステップＳ７０２において、ＩＰデータグラムがフラグメントされていると判定された場合（ステップＳ７０２でＹＥＳ）、ステップＳ７０３へ進む。一方、ＩＰデータグラムがフラグメントされていないと判定された場合（ステップＳ７０２でＮＯ）、本実施形態では、ステップＳ７０８へ進む。本実施形態では、フラグメントのサイズを、ＭＴＵ探索識別子がセットされたパケットではなく、フラグメントされたパケットのＩＰヘッダの記載から判定するためである。
【００９０】
ステップＳ７０３の処理は第１実施形態と同様である。続くステップＳ７０４で、リアセンブル初期化処理を実行する。リアセンブル初期化処理において、ＣＰＵ１０１は管理テーブル８０３に対し、新規の管理エントリを作成し、作成した管理エントリの送信元アドレス９０１、宛先アドレス９０２、及び識別子９０３にＩＰヘッダ内の対応するデータを格納する。また、ＩＰヘッダ内ＩＰオプションにフラグメント設定フラグがセットされていた場合、同じくＩＰヘッダ内ＩＰオプションに設定されているフラグメントサイズを作成した管理エントリのビットテーブル単位サイズ９０４に格納する。ＩＰヘッダ内オプションにフラグメント設定フラグがセットされていない場合、ビットテーブル単位サイズ９０４には最小のフラグメントサイズに相当する８（バイト）を格納する。
【００９１】
次に、ＣＰＵ１０１はビットテーブル単位サイズ９０４からビットテーブルサイズを取得する。具体的には、ＩＰデータグラムの最大ペイロードサイズ６４ＫＢをビットテーブル単位サイズ９０４で除算して算出する。例えば、ビットテーブル単位サイズ９０４が１ＫＢであるなら算出されるビットテーブルサイズは６４（＝６４ＫＢ÷１ＫＢ）となる。このビットテーブルサイズを基に、ビットテーブル領域８０４にビットテーブルを生成し、ビットテーブルを初期化する。ビットテーブルの初期化は全てのビットを”０”にセットすることで行う。最後に、作成した管理エントリのビットテーブルポインタ９０５に生成したビットテーブルの格納先アドレスを設定する。そして、ステップＳ７０５へ進む。
【００９２】
ステップＳ７０５ではリアセンブル処理を行う。リアセンブル処理においては、受信したＩＰデータグラムのＩＰヘッダ内の送信元アドレス、宛先アドレス、及び識別子と送信元アドレス９０１、宛先アドレス９０２、及び識別子９０３が一致する管理エントリを検索する。そして、当該管理エントリのビットテーブル単位サイズ９０４とＩＰヘッダ内のフラグメントオフセットを基に、ビットテーブルポインタ９０５の指し示すビットテーブルの対応するビットに”１”を設定する。ここで、受信したＩＰデータグラムにてＭＦフラグが”０”であった場合はビットテーブルの対応するビット以降のビットに”１”を設定する。そしてステップＳ７０６へ進む。
【００９３】
ステップＳ７０６〜Ｓ７０８の処理は第１実施形態と同様である。なお、ステップＳ７０２において、フラグメントされていないと判定されたＩＰデータグラムのペイロードデータを上位層へ受け渡す。上位層は通常はＴＣＰ処理を行うソフトウェアであるが、本実施形態では特に限定しない。
【００９４】
上記のように、本実施形態では、送信装置は、複数のフラグメントの各々のヘッダに、その分割サイズを示すサイズ情報を格納することで、分割サイズを受信装置へ通知する。そして、受信装置は、受信したフラグメントのヘッダに格納されているサイズ情報により示される分割サイズに基づいて、ビットテーブルをメモリに確保する。このため、本実施形態によれば、受信装置は、通知される分割サイズに基づいて、必要なだけのサイズのビットテーブルを用意すればよく、したがって、受信装置で確保が必要なビットテーブルのサイズを小さくすることを可能である。
【００９５】
以上のようにして、第２実施形態においては、パスＭＴＵ探索後にフラグメント処理を行うサイズを送信装置と受信装置間で共有する。これにより、受信装置ではフラグメントされたＩＰデータグラム（パケット）の到着状況を共有しているサイズ単位で管理することが可能になる。これにより、到着状況を管理するビットテーブルが必要とするサイズを削減することが可能になる。
【００９６】
＜＜その他の実施形態＞＞
本発明の目的は、前述した実施形態の機能を実現するソフトウエアのプログラムコードをシステムあるいは装置で実行することによっても達成されることは言うまでもない。この場合、プログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードは本発明の技術的範囲に含まれる。
【００９７】
プログラムコードは、例えば、コンピュータ読み取り可能な記録媒体に記録してシステムあるいは装置に供給することができる。そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）は、記録媒体に格納されたプログラムコードを読み出し実行することによっても、本発明の目的を達成することができる。従って、そのプログラムコードを記憶した記録媒体も本発明の技術的範囲に含まれる。
【００９８】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【００９９】
なお、プログラムコードは、コンピュータが当該プログラムコードを読み出し実行することにより前述した実施形態の機能を実現するための、全ての要素を備えたものに限られない。即ち、プログラムコードには、コンピュータに組み込まれたソフトウェア及びハードウェアの少なくともいずれかと協働することにより目的を達成するプログラムコードも含まれる。
【０１００】
例えば、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も、そのプログラムコードは本発明の技術的範囲に含まれる。ただし、ＯＳはオペレーティングシステム（Operating System）の略称である。
【０１０１】
あるいは、例えば、プログラムコードの指示に基づき、コンピュータに挿入又は接続された機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合がある。このような場合も、そのプログラムコードは本発明の技術的範囲に含まれる。なお、機能拡張ボードや機能拡張ユニットは、それらが備えるメモリにプログラムコードを読み込み、実行することでこのような処理を行うことができる。
【０１０２】
以上説明したように、本発明によれば、ネットワークプロトコル処理におけるリアセンブル処理時に、ビットテーブルを８バイト以上の単位サイズで構成することにより、ビットテーブルサイズを縮小することができる。これにより、リアセンブル処理に必要となるメモリ領域を削減することができ、ネットワークプロトコル処理のパフォーマンス低下の抑制、及びシステム構築時のコストを低減することができる。特にメモリ領域が限られている組み込みシステム等では大きな効果が期待できる。
【図面の簡単な説明】
【０１０３】
【図１】ネットワークプロトコル処理装置の構成を示す構成図である。
【図２】ＲＡＭ１０３内のデータ構造の模式図である。
【図３】フラグメントサイズ情報のデータ構造図である。
【図４】管理エントリのデータ構造図である。
【図５】ビットテーブルのデータ構造図である。
【図６】ＩＰデータグラム送信時の処理手順を示すフローチャートである。
【図７】ＩＰデータグラム受信時の処理手順を示すフローチャートである。
【図８】ＲＡＭ１０３内のデータ構造の模式図である。
【図９】管理エントリのデータ構造図である。
【図１】
0005070125.tif 000002
【図２】
0005070125.tif 000003
【図３】
0005070125.tif 000004
【図４】
0005070125.tif 000005
【図５】
0005070125.tif 000006
【図６】
0005070125.tif 000007
【図７】
0005070125.tif 000008
【図８】
0005070125.tif 000009
【図９】
0005070125.tif 000010