(57)【要約】【課題】  フラグメント（断片化）パケットの受信からリアセンブル（再組立）パケットの検証が完了するまでの処理を高速に実行可能とする。【解決手段】  受信したパケットのデータを記憶するバッファを有するパケット受信装置であって、パケットのヘッダ部に含まれる情報に基づいて、バッファに記憶されるデータが先に記憶されたデータと重複するか否かを判断する。その結果、重複すると判断された場合には、重複するデータのチェックサムの減算を行い、重複しないと判断された場合には、バッファに記憶するデータのチェックサムの加算を行う。【選択図】      図１
2009278364.tif 000002
【特許請求の範囲】
【請求項１】
受信したパケットのデータを記憶するバッファを有するパケット受信装置であって、
前記パケットのヘッダ部に含まれる情報に基づいて、前記バッファに記憶されるデータが先に記憶されたデータと重複するか否かを判断する判断手段と、
前記判断手段によって重複すると判断された場合、前記重複するデータのチェックサムの減算を行い、前記判断手段によって重複しないと判断された場合、前記バッファに記憶するデータのチェックサムの加算を行う演算手段と、
を有することを特徴とするパケット受信装置。
【請求項２】
断片化されたパケットの受信状況を管理するビットマップメモリに基づいて前記断片化されたパケットを再組立する再組立手段を更に有することを特徴とする請求項１に記載のパケット受信装置。
【請求項３】
前記パケットのヘッダ部に含まれる情報は、少なくともオフセット位置及びパケット長であることを特徴とする請求項１又は２に記載のパケット受信装置。
【請求項４】
前記演算手段は、予め指定された領域におけるデータのチェックサムを算出しないことを特徴とする請求項１乃至３の何れか１項に記載のパケット受信装置。
【請求項５】
受信したパケットからＩＰヘッダを抽出し、疑似ヘッダを組み立てた後に前記演算手段によってチェックサムを算出することを特徴とする請求項１乃至４の何れか１項に記載のパケット受信装置。
【請求項６】
断片化されたパケットから、再組立パケットの全長又はペイロード長を算出し、算出した再組立パケットの全長又はペイロード長を、前記バッファの中のＩＰヘッダの全長記憶領域又はペイロード長記憶領域に書き込むことを特徴とする請求項１乃至５の何れか１項に記載のパケット受信装置。
【請求項７】
断片化されたパケットの受信を完了すると、前記断片化されたパケットを再組立した受信パケットを出力することを特徴とする請求項１乃至６の何れか１項に記載のパケット受信装置。
【請求項８】
受信したパケットのデータを記憶するバッファを有するパケット受信装置の処理方法であって、
前記パケットのヘッダ部に含まれる情報に基づいて、前記バッファに記憶されるデータが先に記憶されたデータと重複するか否かを判断する判断工程と、
前記判断工程において重複すると判断された場合、前記重複するデータのチェックサムの減算を行い、前記判断工程において重複しないと判断された場合、前記バッファに記憶するデータのチェックサムの加算を行う演算工程と、
を有することを特徴とするパケット受信装置の処理方法。
【請求項９】
請求項１乃至７の何れか１項に記載のパケット受信装置としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット受信装置及びその処理方法に関するものである。
【背景技術】
【０００２】
通信ネットワークのプロトコルとしてＴＣＰ／ＩＰやＵＤＰ／ＩＰなどのプロトコルが用いられている。ＴＣＰ／ＩＰはTransmission Control Protocol/Internet Protocolの略で、ＵＤＰ／ＩＰはUser Datagram Protocol/Internet Protocolの略である。
【０００３】
このようなプロトコルを用いるネットワークでは、ＩＰ層における１パケットの全長を65535 Octets（1 Octet=8bit）まで定義できる仕様となっている。しかし、ＩＰ層の下のデータリンク層、例えばIEEE802.3では、１パケットとして送出できる最大送信ユニットは1492 Octetsと制限されている。以下、最大送信ユニットをＭＴＵ（Maximum Transfer Unit）と称す。
【０００４】
また、Ethernet（登録商標）では1500 Octet、電話回線によるダイアルアップ接続では576 Octet、FibreChannelでは4352 Octetなど、ＭＴＵはデータリンク層によって異なる長さが採用されている。
【０００５】
ＩＰ層で取り扱うパケット長がデータリンク層のＭＴＵよりも長い場合や、パケットが今のネットワークのＭＴＵより小さいＭＴＵをもつネットワークに転送される場合など、元のＩＰパケットを分割してからデータリンク層に渡す必要がある。この分割の仕組みはＩＰフラグメントとして知られている。
【０００６】
また、フラグメントパケットの格納位置情報を示すパケットディスクリプタを転送回路に指示することによってパケットの重複がないように所定の転送先へ転送する技術が開示されている（例えば、特許文献１参照）。この特許文献１では、図６に示すように、受信パケットをパケット解析回路６０１がパケットバッファメモリ６０２とパケットディスクリプタメモリ６０３に取り込む。そして、各フラグメントパケットの格納位置情報を示すパケットディスクリプタによって全てのリアセンブルデータが揃うと、制御回路６０９がパケット組立回路６０４に指示し、転送回路６０５を介して重複がないように所定の転送先へと転送する。
【０００７】
また、フラグメントパケットが重複なく順番通りに連続して到達いるか否かに応じて、チェックサム演算方法を切り換える技術が開示されている（例えば、特許文献２参照）。この特許文献２では、重複のない、順番通りに連続した領域が到達しているフラグメントパケットに対してはチェックサム演算装置を用いて高速に演算を行う。一方、フラグメントパケットが順番通りに連続しておらず、重複した領域があった場合にはプロセッサなどでチェックサム演算を行う。
【特許文献１】特開平05-327771号公報
【特許文献２】特開2007-215013号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記従来のＩＰフラグメント処理方法では、次のような問題があった。フラグメントされる前のＩＰパケットの上位プロトコルにＴＣＰ／ＵＤＰやＩＣＭＰなどが用いられ、これらのプロトコルにはヘッダ情報としてチェックサムフィールドを有し、チェックサムの整合性によって当該パケットの有効性の判定を行っている。
【０００９】
このチェックサムを算出するためにはＩＰヘッダの一部から構成されるＩＰ擬似ヘッダと、ＴＣＰ（ＵＤＰ）ヘッダ、ペイロードを2 Octets単位での１の補数和、即ちRFC1071で定義されるインターネットチェックサムを算出する必要があった。この算出のために、再組立を行ったメモリ上からヘッダ、ペイロード情報を再度読み出して算出していた。
【００１０】
また、フラグメントを再組立するために、一旦全ての受信フラグメントパケットを蓄積し、並べ替えを行った後、データグラムを再組立するという工程を経ていた。そのため、ＩＰフラグメントパケットを生じるネットワークにおいては受信性能が低下してしまうという問題もあった。
【００１１】
本発明は、フラグメント（断片化）パケットの受信からリアセンブル（再組立）パケットの検証が完了するまでの処理を高速に実行可能とすることを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、受信したパケットのデータを記憶するバッファを有するパケット受信装置であって、前記パケットのヘッダ部に含まれる情報に基づいて、前記バッファに記憶されるデータが先に記憶されたデータと重複するか否かを判断する判断手段と、前記判断手段によって重複すると判断された場合、前記重複するデータのチェックサムの減算を行い、前記判断手段によって重複しないと判断された場合、前記バッファに記憶するデータのチェックサムの加算を行う演算手段とを有することを特徴とする。
【００１３】
また、本発明は、受信したパケットのデータを記憶するバッファを有するパケット受信装置の処理方法であって、前記パケットのヘッダ部に含まれる情報に基づいて、前記バッファに記憶されるデータが先に記憶されたデータと重複するか否かを判断する判断工程と、前記判断工程において重複すると判断された場合、前記重複するデータのチェックサムの減算を行い、前記判断工程において重複しないと判断された場合、前記バッファに記憶するデータのチェックサムの加算を行う演算工程とを有することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、フラグメント（断片化）パケットの受信からリアセンブル（再組立）パケットの検証が完了するまでの処理を高速に実行することが可能となる。
【発明を実施するための最良の形態】
【００１５】
以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。
【００１６】
図１は、プロトコル処理装置における受信処理部の構成の一例を示す図である。図１において、１０１はＩＰパケットアナライザであり、受信されたＩＰパケットのヘッダ部とペイロード部とを分離する。１０２はＩＰヘッダアナライザであり、ＩＰパケットアナライザ１０１で分離されたＩＰパケットのヘッダ部を解析する。１０３はビットマップ検査器であり、フラグメントパケットの受信状況を管理し、ＩＰパケットアナライザ１０１で分離されたペイロード部を後述するバッファへ書き込む位置を管理する。
【００１７】
１０４は演算器であり、チェックサム演算を行うために、ペイロード部のデータを加算し、或いはリアセンブルバッファからのデータを減算する。１０５はビットマップメモリであり、複数のリアセンブル中のＩＰパケットの受信状況を管理すると同時に、演算中のチェックサム値を記憶する。
【００１８】
１０６はチェックサム演算器であり、演算器１０４での演算結果とビットマップメモリ１０５に記憶された演算途中のチェックサム演算結果とから最終的なチェックサムを算出して出力する。１０７はリアセンブルバッファ・受信バッファであり、リアセンブル中のＩＰパケットやフラグメントされていないＩＰパケットなどが一時記憶される。
【００１９】
以上の構成において、断片化（フラグメント）されていないＩＰパケットを受信した際の動作について説明する。PHY Device（不図示）で受信したフレームはMAC Device（不図示）に入力され、フレーム全体に渡ってＦＣＳ（Frame Check Sequence）によりフレームの検証を行う。MAC Deviceでは算出したＦＣＳとパケットの末尾2 OctetsのＦＣＳを比較し、同じ値であればＩＰパケットをＩＰパケットアナライザ１０１に入力し、異なる値であれば受信パケットはエラーが含まれているパケットとして廃棄する。
【００２０】
ここで、ＩＰパケットアナライザ１０１に入力されるＩＰパケットのフォーマットを、図２を用いて説明する。
【００２１】
図２は、ＩＰ層におけるＩＰｖ４パケットのフォーマットを示す図である。図２に示すように、ＩＰｖ４ヘッダはverフィールドからDest IP Addrまでの最小で20 Octetsで構成される。ＩＰヘッダの先頭にはバージョンを示す４ビットのverフィールドがあり、ＩＰｖ４の場合は“0100=4”が示される。続いて４ビットのヘッダ長がHlenとして４ Octets単位で示される。そのため、オプションが４ Octets単位にならなければPADDING DATAが加えられてヘッダサイズが４ Octets単位になるように揃えられる。例えば、オプションが無い場合、Hlenは“0101”で、ヘッダ長は20 Octets（5×4 Octets）となる。そして、ヘッダ長が判明すれば、入力したＩＰパケットをＩＰヘッダ部とＩＰデータグラム部とに分割することができる。
【００２２】
Total Lengthフィールドは自身のＩＰヘッダを含むＩＰパケットの全長を示す全長記憶領域である。これは、16bitで表現されていることからＩＰパケットの最大長は65535 Octetsということになる。そして、ＩＰパケット長（Total Length）により、ペイロードの終端が判るため、ＩＰヘッダ、ペイロードの分離と同時に、パケット長、ペイロード長のチェックを行うことができる。
【００２３】
IPIDはＩＰデータグラムに与えられるユニークな識別子（ＩＤ）である。ネットワークの途中でＩＰデータグラムがフラグメントされた場合や、ＩＰパケットの複製が発生した場合など、同一のIPIDを持つＩＰデータグラムが別個に処理されるのを防ぐことができる。
【００２４】
Flag及びOffsetは経路上でＩＰフラグメントする場合に用いられるフィールドである。ＩＰパケットアナライザ１０１により、ＩＰヘッダがＩＰヘッダアナライザ１０２に入力され、ＩＰヘッダ中のFlagフィールドに含まれるＭＦビットとOffsetフィールドの値とを確認する。フラグメントされていないＩＰパケットであれば後続のフラグメントパケットの存在を示すＭＦビットと、フラグメントパケットのオフセット位置を示すOffsetフィールドの値が共に“０”である。
【００２５】
ＭＦビットが“１”であれば、後続のフラグメントされたＩＰパケットの存在を示し、Offsetフィールドに値が与えられていれば、ＩＰフラグメントパケットの再組立後のオフセット位置を表す。ここで確認されたＭＦビットの値とOffsetフィールドの値とIPIDの値はビットマップ検査器１０３に渡される。
【００２６】
PTCLフィールドはＩＰパケットの上層に位置するプロトコル種別である。Header ChecksumフィールドはＩＰヘッダ部分のみのRFC1071で定義されているインターネットチェックサムが与えられる。送出元ＩＰアドレスであるSource IP Addr、宛先ＩＰアドレスであるDest IP Addrが示されることでＩＰヘッダが構成される。
【００２７】
一方、ＩＰヘッダアナライザ１０２はチェックサム算出のための疑似ヘッダを組み立てる。疑似ヘッダはＬ４プロトコルであるＴＣＰ／ＵＤＰヘッダや、ＩＣＭＰヘッダにあるチェックサム値を算出する時に使用されるＩＰヘッダのうちの送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル種別、パケット長が含まれる。
【００２８】
パケット長に関しては、ＭＦが“０”となるフラグメントパケットのヘッダに記述しているOffset+Total Lengthによって再組立後のＩＰパケット長を算出する手法がある。また、Offsetが“０”のパケット中のＬ４ヘッダを解析することによって事前に再組立後のＩＰパケット長を類推する手法がある。
【００２９】
後者の手法はＵＤＰ、ＩＣＭＰに対しては有効であるが、ＴＣＰにはパケット長を示すフィールドがないため、その場合はＩＰヘッダから全長を算出する。このようにして抽出された疑似ヘッダは演算器１０４に加えられ、算出すべきチェックサムの一部として加算される。
【００３０】
ビットマップ検査器１０３ではOffsetとＭＦが“０”であるため、フラグメントされていないＩＰパケットとして処理される。フラグメントされていないＩＰパケットの場合、ビットマップメモリ１０５を用いず、ビットマップ検査器１０３はリアセンブルバッファ・受信バッファ１０７の書き込み領域として受信バッファ領域を指定する。リアセンブルはバッファを１つのＩＤ当たり最大で６４ＫＢ用意しておく必要があるが、受信バッファ領域はＭＴＵ分にＭＡＸヘッダを加えた容量、例えばイーサネット（登録商標）であれば、1500+14Byteあれば良い。
【００３１】
このようにして指定された書き込みアドレスに演算器１０４を経由して受信パケットがリアセンブルバッファ・受信バッファ１０７の受信バッファに書き込まれる。ＩＰヘッダ中に記述されているTotal Length分の転送が終了した段階で演算器１０４からの演算結果を受けてチェックサム演算結果を出力すると共に、リアセンブルバッファ・受信バッファ１０７からＩＰパケットが出力される。
【００３２】
従って、フラグメントされていないＩＰパケットの受信に関してはチェックサムによるＩＰパケットの確認と、パケットの出力をほぼ同時に行うことができる。
【００３３】
次に、ＩＰフラグメントされていて且つ重複した受信領域のある複数のＩＰパケットを受信した場合について説明する。
【００３４】
図３は、ＩＰフラグメントが発生するネットワーク構成の一例を示す図である。図３に示すように、ホストＡ、ＢはネットワークＡ、Ｂにそれぞれ接続され、ネットワークＡ、ＢはＭＴＵが1500 Octetsである。そして、ルータＡ、Ｂを経由してＭＴＵが576 OctetsのネットワークＣにより相互に通信できる環境を構築している。
【００３５】
ここで、ホストＡのアプリケーションが自身のＩＰ層からＩＰデータグラム（2000 Octets）をホストＢへ送信する場合を説明する。まず、ホストＡのＩＰ層はネットワークＡのＭＴＵが1500 Octetsであるので、ＩＰパケットを1500 OctetsにするためにＩＰデータグラムを分割する。具体的には、ＩＰヘッダ長の20 Octetsを除いた1480 Octetsのデータグラムで構成するＩＰパケットと、残りの520 Octetsのデータグラムを持つＩＰパケットに分割する。ＩＰパケットは、ネットワークＢに対して送出されるので、このパケットを受け取ったルータＡがネットワークＣに送出するために、ＭＴＵが576 Octetsに合わせたＩＰパケットの転送を行う。
【００３６】
この場合、1480 OctetsのＩＰパケットは552 Octetsのデータグラムを持つ572 OctetsのＩＰパケットが２つと、376 Octetsのデータグラムを持つ396 OctetsのＩＰパケットにＩＰフラグメントされる。続く520 OctetsのＩＰパケットはそのまま転送される。一方、ＭＴＵが576 OctetsのネットワークからＭＴＵが1500 Octetsのネットワークに転送する場合、特にＩＰフラグメント等の処理を行う必要はない。
【００３７】
このように、ホストＡのアプリケーションから送信された2000 OctetsのデータはホストＢに到達するまでに、図４に示すように、４つのＩＰパケットに分割される。そして、ホストＢのアプリケーションはホストＡが送信した2000 Octetsのデータが到着すると、ホストＢのＩＰ層でリアセンブル（再組立）処理が行われる。
【００３８】
ホストＢに到着した４つのＩＰフラグメントされたパケットは、それぞれのＩＰヘッダには同一のIPIDが記述されているので、元は１つのＩＰパケット、つまり、リアセンブル処理を行うＩＰパケットであることが判る。更に、Total Length、Offset、Flagフィールドに記述されたMore Fragment（ＭＦ）ビットからＩＰフラグメントされる前のパケットのどの位置を構成していたかが判明する。従って、元のＩＰパケットにリアセンブルすることができる。
【００３９】
また、フラグメントする前のＩＰパケットにＵＤＰを用いていた場合は、ＵＤＰヘッダの先頭から終端までがＩＰデータグラムとしてフラグメント−リアセンブルされる。そのため、ホストＢではリアセンブルが完了してＩＰデータグラムが完成した後に、ＵＤＰの処理を行うことができる。
【００４０】
図３に示す例では、ホストＡからホストＢにＩＰパケットが到達するまでの経路は１つであるため、フラグメントが発生してもＩＰデータグラムの重複は発生しない。しかし、異なるＭＴＵをもつネットワークインタフェースをリンクアグリゲーションした場合や、複数の経路をもつネットワークでは、異なるＭＴＵでフラグメントされたパケットが到着する場合がある。また、ネットワークアドレスを学習していないスイッチングハブが大量の複製パケットを発生させ、同一パケットが別の時刻に到着することもある。
【００４１】
図５は、時系列で受信したフラグメントパケットが復元中のＩＰデータグラムの受信済み領域に重複される場合を示す図である。まず、ＭＦが“１”、Offsetが1480、Lengthが1500のパケット２を受け取る。ＩＰヘッダアナライザ１０２は、ＭＦ、Offsetが共に零でないので、フラグメントされたＩＰパケットであると解析する。これにより、IPID、ＭＦ、Offset、Length情報が１０３ビットマップ検査器１０３に渡され、ビットマップメモリ１０５の１つのＩＤが割り当てられる。
【００４２】
ビットマップメモリ１０５は、フラグメントパケットの受信済み領域を判断するメモリと、チェックサムの途中演算結果を保持するチェックサムレジスタとを有し、ＩＤで管理される。受信済み領域を管理するメモリは、8 Octets受信単位当たり1Bitのメモリを割り振っており、64KBの最大ＩＰパケットに対応するために、１つのＩＤ当たり8KBの容量を持っている。このＩＤはビットマップ検査器１０３によってIPIDに対応付けられ、複数のIPIDを持つＩＰフラグメントパケットの組立が可能である。更に、ＩＤはリアセンブル・受信バッファのＩＤと対応付けられ、リアセンブル管理にも用いられている。
【００４３】
ここで、受信パケットのLengthはＩＰヘッダ込みのLengthなので、1500から20 Octets分を減算し、再組立するペイロードは1480となる。結果、ビットマップメモリ１０５には1480〜2960までが受信済みであることを示す“１”を立てると共にIPIDが記録される。
【００４４】
次に、ビットマップ検査器１０３は、リアセンブルバッファ・受信バッファ１０７への書き込みアドレスを通知する。そして、演算器１０４からのペイロードが、そのアドレスに従ってリアセンブル・受信バッファ１０７のペイロード長記憶領域に記録される。このようにして、演算器１０４を通してリアセンブルバッファ・受信バッファ１０７にLengthで示されたペイロードの記録が完了すると、演算器１０４はビットマップ検査器１０３に加算結果を通知する。そして、当該ＩＤのビットマップメモリ１０５のチェックサムレジスタに加算結果を保持する。
【００４５】
続いてIPIDが先のパケット２と同一であるパケット１を受信する。パケット１はOffsetが０であることからリアセンブル後に先頭のペイロードになるＩＰパケットである。また、Lengthが1500なので0〜1480までが先のパケット２と同様に受信する。ここで、ビットマップ検査器１０３は重複受信領域を検査するために、ビットマップメモリ１０５からビットマップを読み出し、0〜1480までの受信済み領域の有無を検査する。この場合、全ての受信領域が未受信であることが確認されるので、リアセンブルバッファ・受信バッファ１０７には何も通知せずに書き込みアドレスの指定のみを行う。
【００４６】
パケット１のように、先頭のパケットを受信した場合、ＩＰヘッダアナライザ１０２は疑似ヘッダを生成し、演算器１０４を介してリアセンブルバッファ・受信バッファ１０７に記録する。このようにして疑似ヘッダを含めたチェックサム演算が可能となる。
【００４７】
次に、重複受信領域があった場合の演算方法について説明する。パケット３を受信した後に、パケット４を受信し、ビットマップ検査器１０３がビットマップメモリ１０５から読み出した既受信領域と、今回受信したパケット４の受信領域とを比較する。比較の結果、パケット３はOffsetが4024、Lengthが1500、パケット４はOffsetが2960、Lengthが1500なので、4024〜4440までの416 Octetsが重複していると判断する。尚、ペイロードデータに関しては、後から受信したパケットが上書きされる。
【００４８】
従って、ビットマップ検査器１０３は重複受信領域が4024〜4440で、書き込みアドレスが2960〜4440まであるという２つの情報をリアセンブルバッファ・受信バッファ１０７に出力する。重複受信領域があった場合、ペイロードを書き込む前にリアセンブルバッファ・受信バッファ１０７に記録している重複受信領域に関して演算器１０４にて予め減算を行っておく。減算を行った領域に関しては新規に受信したペイロードデータを上書きすることが可能となる。
【００４９】
次に、パケット５、パケット６のように、完全に受信領域が重複している場合も同様の処理を行う。重複した7000〜8480の領域はリアセンブルバッファ・受信バッファ１０７に通知される。ここで、パケット６のバッファ書き込みに先立ち、以前に読み込んだデータを減算した後に加算処理とリアセンブルバッファ・受信バッファ１０７への書き込み処理を行う。
【００５０】
その後、ＭＦが“０”のパケット７を受信した時点で、そのパケットのTotal LengthとOffsetによってリアセンブル後のＩＰパケットの終端が明らかになる。この位置はビットマップ検査器１０３によって記憶され、終端が判明した場合はフラグメントパケット受信毎に先頭から終端までのビットマップメモリの領域に渡って受信済みであるか否かの検査を行う。そして、先頭から終端までの領域が受信済みとなったことが判明した時点で再組立後のＩＰパケット、もしくはその上位プロトコルのパケットにおける長さ（全長又はペイロード長）が判明する。そして、リアセンブルバッファ・受信バッファ１０７中のＩＰヘッダの全長記憶領域、もしくはペイロード長記憶領域に再組立パケットの長さ（全長、もしくはペイロード長）を書き込む。
【００５１】
全ての領域が受信済みとなった場合、リアセンブル完了となり、途中まで演算した結果であるチェックサムレジスタの値と、最終パケットの演算器１０４からのチェックサムの結果をチェックサム演算器１０６に通知する。そして、チェックサムの演算結果を出力すると同時に、リアセンブルバッファ・受信バッファ１０７から組立済みのＩＰパケットを出力することが可能となる。
【００５２】
また、フラグメントパケットの組立中に、様々なIPIDを持つパケットを受信するため、複数のIPIDのリアセンブルを同時並列的に処理することが求められる。そのため、ビットマップメモリ１０５はそれぞれのIPIDに対応した複数のＩＤに対して処理が可能な容量を持ち、それぞれのチェックサムレジスタを有している。即ち、図１に示す１０５ａ、１０５ｂ、１０５ｃなどを備えている。更に、リアセンブルバッファ・受信バッファ１０７に関してもビットマップメモリ１０５に対応した容量を持つ必要がある。
【００５３】
そして、ビットマップ検査器１０３は、フラグメントパケットのIPIDに対応したビットマップメモリ１０５のＩＤ管理とリアセンブル・受信バッファ１０７のＩＤ管理を行い、再組立が完了するまで保持する。
【００５４】
実施形態では、ＩＰパケットの受信、特に、フラグメントされたＩＰパケットの受信において、ＩＰフラグメントパケットの受信と同時に、受信領域を確認しながらペイロード部のチェックサム及びＩＰパケットの再組立を行う。次に、全てのフラグメントパケット受信完了を検出するとＩＰヘッダによる疑似ヘッダを作成、疑似ヘッダのチェックサムを算出、先のペイロード部のチェックサムと疑似ヘッダのチェックサムからトランスポート層のチェックサムによる検証を行う。
【００５５】
これにより、フラグメントパケット受信から再組立パケットの検証まで完了する時間が従来例と比較して短縮され、高速に処理することが可能となる。
【００５６】
尚、上述の実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵ若しくはＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行する。これによっても、本発明の目的が達成されることは言うまでもない。
【００５７】
この場合、コンピュータ読み取り可能な記録媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【００５８】
このプログラムコードを供給するための記録媒体として、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００５９】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、次の場合も含まれることは言うまでもない。即ち、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合である。
【００６０】
更に、記録媒体から読出されたプログラムコードがコンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込む。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【００６１】
【図１】プロトコル処理装置における受信処理部の構成の一例を示す図である。
【図２】ＩＰ層におけるＩＰｖ４パケットのフォーマットを示す図である。
【図３】ＩＰフラグメントが発生するネットワーク構成の一例を示す図である。
【図４】ＩＰパケットのフラグメント（断片化）処理を説明するための図である。
【図５】時系列で受信したフラグメントパケットが復元中のＩＰデータグラムの受信済み領域に重複される場合を示す図である。
【図６】従来のプロトコル処理装置の構成を示すブロック図である。
【符号の説明】
【００６２】
１０１  ＩＰパケットアナライザ
１０２  ＩＰヘッダアナライザ
１０３  ビットマップ検査器
１０４  演算器
１０５  ビットマップメモリ
１０６  チェックサム演算器
１０７  リアセンブルバッファ・受信バッファ
【図１】
2009278364.tif 000003
【図２】
2009278364.tif 000004
【図３】
2009278364.tif 000005
【図４】
2009278364.tif 000006
【図５】
2009278364.tif 000007
【図６】
2009278364.tif 000008