JP2007215013A - プロトコル処理装置及びプロトコル処理方法 - Google Patents

Abstract

【課題】定常的なパケット、及び否定常的なパケット（フラグメントパケット）を小さな回路規模で高速に処理することを目的とする。
【解決手段】断片化されたパケットの再組み立て処理、及びチェックサム記憶手段に格納されているチェックサム値と、再組み立てされたパケットのパケットヘッダに格納されているチェックサム値とを使用して再組み立てされたパケットのデータチェックサム検査処理を実行する制御手段を有し、フラグメント検査手段において受信パケットが断片化されたパケットであると判断された場合は、制御手段においてチェックサム検査を行い、フラグメント検査手段において受信パケットが断片化されたパケットでないと判断された場合は、チェックサム検査手段においてチェックサム検査を行うことによって上記課題を解決する。
【選択図】図４

Description

本発明は、プロトコル処理装置及びプロトコル処理方法に関する。

ネットワークを利用したデータ通信においては、ＴＣＰ／ＩＰをはじめとしたプロトコルを用いた手法が用いられる。このＴＣＰ／ＩＰによる通信では、データを小単位に分割して、送受信に関連する各種情報をヘッダとして付加することにより、パケットと呼ばれるデータのかたまりで送受信を行っている。

また、ネットワークプロトコルにおいては、ＯＳＩ参照モデルに代表されるように、その処理単位が階層的に行われており、これに従ってパケットのデータ構造においてもそれぞれの処理単位に応じたヘッダ情報が階層的に付加されている。

図１は、イーサネット（登録商標）におけるＴＣＰ／ＩＰパケットのデータ構造を示す図である。図１においては、データの先頭からそれぞれ、イーサネット（登録商標）ヘッダ２０１、ＩＰヘッダ２０２、ＴＣＰヘッダ２０３が順次付加されており、その後アプリケーションデータであるペイロードデータ２０４が続いている。

図２は、ＩＰパケットのデータ構造を示す図である。図２において、３０１はＩＰヘッダ部、３０２はデータ部を示している。ＩＰヘッダ部３０１には、ヘッダサイズやパケットサイズ、サービスタイプや識別子、また、送信元と送信先とのＩＰアドレス、及び３０３に示すヘッダチェックサム値、更に３０４に示すフラグ、３０５に示すフラグメントオフセット値等が格納されている。ヘッダチェックサム３０３は、ＩＰヘッダ部３０１と、データ部３０２とが壊れていないことを保証するための１６ビットのデータである。ＩＰパケット受信処理においては、装置は、受信したパケットのＩＰヘッダ部３０１のチェックサム値を演算し、その結果と、ヘッダに格納されているヘッダチェックサム３０３との比較を行う。

フラグ３０４には、ＩＰデータグラムのフラグメント処理を制御する３ビットのデータが格納されている。フラグメントオフセット３０５には、フラグメントされたデータが、オリジナルのＩＰデータグラムのどこに位置しているかを意味する１３ビットのデータが格納されている。

図３は、ＴＣＰパケットのデータ構造を示す図である。図３において、４０１はＴＣＰヘッダ部、４０２はデータ部を示している。ＴＣＰヘッダ部４０１には、送信元と送信先とのポート番号、シーケンス番号、各種フラグ、ヘッダ部とデータ部とを含む、４０３に示すチェックサム値等が格納されている。

チェックサム４０３は、ＴＣＰヘッダ部４０１とデータ部４０２とが壊れていないことを保証するための１６ビットのデータである。ＴＣＰパケット受信処理においては、装置は、受信したパケットのＴＣＰヘッダ部４０１と、データ部４０２とのチェックサム値を演算し、その結果と、ヘッダに格納されているチェックサム４０３との比較を行う。

これらＴＣＰ／ＩＰのプロトコル処理は従来ソフトウェアによって実装されてきた。しかしながら、例えばチェックサム値の演算等においては、パケット処理ごとに１５００バイト程度の加算処理が必要となり、ソフトウェアでは演算に時間がかかるため通信のスループットを上げるのが困難になってくる。

これを解決する手段として、特許文献１において、ハードウェアを利用してチェックサム値を短時間で生成するための回路が提案されている。

特開平９−１３４２９５号公報

ＩＰパケット処理を高速に実行する手段として、上述した特許文献１で提案されているようにハードウェアを用いる方法は、特に定常的なパケットの処理を行わせるだけにおいては、比較的簡単に実現させることができ、有効である。しかしながら、非定常的なパケットの処理までハードウェアに行わせようとすると、ハードウェアの回路規模が大きくなってしまう問題があった。

例えば、ＴＣＰ／ＩＰプロトコルにおいては、ＩＰパケットがデータリンクで転送できる最大値（ＭＴＵ）を超えたサイズのデータについては、必要に応じてフラグメンテーションと呼ばれるパケット分割を行う機能が決められている。ネットワークの中継を行うルーター等の機器では、受け取ったＩＰパケットが送り先のＭＴＵより大きなサイズのパケットである場合には、フラグメント処理によってパケットを分割して送信する機能を持っている。

このフラグメンテーションされたＩＰパケットを受信した場合は、全ての分割パケットが到着するのを待って、パケットの再組み立てを行い、上位のプロトコルに渡すことになる。

このフラグメントされたパケットの待ち合わせと再組み立てをハードウェアで実現する場合は、複雑なメモリ管理を行わなければならず回路構成が複雑になってしまう。また、ソフトウェアで処理される上位プロトコルが使用するメモリとは独立した専用のメモリも必要となるため、回路規模も大きくなる。

本発明は上記の問題点に鑑みなされたもので、定常的なパケット、及び否定常的なパケット（フラグメントパケット）を小さな回路規模で高速に処理することを目的とする。

そこで、上記問題を解決するため、本発明は、受信パケットのデータチェックサム計算を行うチェックサム演算手段と、前記チェックサム演算手段で求めたチェックサム値と、受信パケットのパケットヘッダに格納されているチェックサム値とを使用してデータチェックサム検査を行うチェックサム検査手段と、前記受信パケットが断片化されたパケットか否かを判断するフラグメント検査手段と、前記チェックサム演算手段で求めたチェックサム値を一時的に格納するチェックサム記憶手段と、断片化されたパケットの再組み立て処理、及び前記チェックサム記憶手段に格納されているチェックサム値と、前記再組み立てされたパケットのパケットヘッダに格納されているチェックサム値とを使用して再組み立てされたパケットのデータチェックサム検査処理を実行する制御手段と、を有し、前記フラグメント検査手段において前記受信パケットが断片化されたパケットであると判断された場合は、前記制御手段においてチェックサム検査を行い、前記フラグメント検査手段において前記受信パケットが断片化されたパケットでないと判断された場合は、前記チェックサム検査手段においてチェックサム検査を行うことを特徴とする。

係る構成とすることにより、非定常的なパケットの処理は、制御手段が行い、定常的なパケットの処理は例えばハードウェアであるチェックサム演算手段や、フラグメント検査手段等が行う。よって、定常的なパケット、及び否定常的なパケットを小さな回路規模で高速に処理することができる。

また、上記問題を解決するため、本発明は、プロトコル処理方法及びプログラムとしてもよい。

本発明によれば、定常的なパケット、及び否定常的なパケットを小さな回路規模で高速に処理することができる。

以下、本発明の実施形態について図面に基づいて説明する。

（実施形態１）
図４は、実施形態１に係る装置の全体構成を表すブロック図である。実施形態１では、ネットワークの物理層、データリンク層としてＩＥＥＥ８０２．３に代表される有線ＬＡＮの規格であるイーサネット（登録商標）を用いて説明する。また、ネットワーク層、トランスポート層としてＴＣＰ／ＩＰプロトコルを用いて説明する。

図４において、１０１はＭＡＣ（メディアアクセスコントロール）を示しており、ネットワーク上のイーサネット（登録商標）フレームは、まずＭＡＣ１０１で受信される。ＭＡＣ１０１は、ＭＡＣヘッダの情報に従って、物理層、データリンク層で提供されるプロトコル処理を実行し、ＭＡＣヘッダを取り除いた後パケットデータを上位層へ受け渡す処理を行う。１０２はＴＣＰ（ＵＤＰ）／ＩＰデフレーマであり、ＭＡＣ１０１によりＭＡＣヘッダが取り除かれたＴＣＰ／ＩＰパケットを、ＭＡＣ１０１より受け取り、ＩＰヘッダ及びＴＣＰヘッダデータを抽出する。

抽出するＩＰヘッダ、ＴＣＰヘッダはそれぞれ図１、図２で説明した構造である。ＴＣＰ（ＵＤＰ）／ＩＰデフレーマ１０２は、抽出したヘッダデータを後述するヘッダ情報解析部１０６へ送る。また、ＴＣＰ（ＵＤＰ）／ＩＰデフレーマ１０２は、抽出したパケットデータを後述するチェックサム演算部１０３へ送る。

チェックサム演算部１０３は、ＴＣＰ（ＵＤＰ）／ＩＰデフレーマ１０２からデータを受け取ると、ＴＣＰパケットのチェックサム値の計算を行う。

チェックサム演算部１０３は、ＴＣＰパケットのチェックサム値の計算として、まず、送信先ＩＰアドレス、送信元ＩＰアドレス、パケット長、プロトコル番号から構成される擬似ヘッダを生成する。次に、チェックサム演算部１０３は、ＴＣＰヘッダ中のチェックサム領域に０を入れた後、擬似ヘッダ、ＴＣＰヘッダ、データ部分を全て１６ビット単位で１の補数で足し合わせる。それから、チェックサム演算部１０３は、受信パケットバッファ１０４へデータを送り出す。受信パケットバッファ１０４は、受信したパケットデータを１パケット分格納する領域であり、受信パケットが正常なパケットでなかった場合にはデータを破棄する処理を行う。

受信パケットバッファ１０４に格納されたデータが正常なパケットデータである場合には、前記データは、受信バッファ１０５中のデータバッファ１０５ｂへ書き込まれる。

受信バッファ１０５は、ＲＡＭ（ランダムアクセスメモリ）から構成されており、後述のＣＰＵ１１０によって管理されているメモリ領域である。そのため、パケットデータが書き込まれるメモリアドレスはＣＰＵ１１０によって予め指定される。受信バッファ１０５は、パケットディスクリプタ１０５ａ、データバッファ１０５ｂによって構成されている。

データバッファ１０５ｂは、断片化されたメモリ領域の集合体であり、キュー構造となっている。パケットディスクリプタ１０５ａは、データ領域を構成する断片化されたメモリ領域を、チェーンされたキュー構造として管理するための情報を格納する領域であり、より詳細なデータ構造については後述する。

ＴＣＰ（ＵＤＰ）／ＩＰデフレーマ１０２において抽出されたＩＰヘッダ、ＴＣＰヘッダデータは、ヘッダ情報解析部１０６によって、各種ヘッダの内容が解析された後、ＣＰＵ１１０で処理される上位プトロコルであるＴＣＰプロトコル制御へ渡される。解析されるヘッダの内容として、ＩＰヘッダにおいては、パケット長、送信先及び送信元ＩＰアドレス、識別子、フラグ、フラグメントオフセット、プロトコル番号、各種オプション等がある。また、解析されるヘッダの内容として、ＴＣＰヘッダにおいては、送信先及び送信元ポート番号、シーケンス番号、確認応答番号、コードビット、ウインドウサイズ、チェックサム値、各種オプション情報等がある。

また、ヘッダ情報解析部１０６においてはＩＰヘッダのチェックサム値の演算も行い、演算結果がＩＰヘッダ中に書き込まれているチェックサム値と一致するか否かの検査を行い、検査結果についてもＣＰＵ１０１及び受信パケットバッファ１０４へ伝える。受信パケットバッファ１０４ではヘッダチェックサム値の不一致を検出すると受信パケットを破棄する処理を行う。

ヘッダ情報解析部１０６は、ＩＰヘッダのチェックサム値の計算として、ＩＰヘッダ中のチェックサム領域に０を入れた後、ＩＰヘッダ部を全て１６ビット単位で１の補数で足し合わせる。

１０６ａで示すチェックサム情報は、ヘッダ情報解析部１０６で解析されたＴＣＰヘッダ情報の一つであり、送信先で計算し埋め込まれたパケットデータのチェックサム値である。また、１０６ｂで示すフラグ情報は、ヘッダ情報解析部１０６で解析されたＩＰヘッダ情報の一つであり、ＩＰパケットのフラグメント処理を制御する情報（フラグメント制御情報）である。フラグ情報１０６ｂには、ＩＰパケットをフラグメントしてもよいか否かを指示するための識別情報が含まれている。また、フラグ情報１０６ｂには、このＩＰパケットがフラグメントされているパケットか否か、またフラグメントされているパケットの場合、最後のフラグメントパケットか途中のフラグメントパケットかを識別する情報が含まれている。

フラグメント検査部１０７は、ヘッダ情報解析部１０６で解析されたフラグ情報１０６ｂを読み出し、ＩＰパケットがフラグメントされたパケットか否かを判定する。また、フラグメント検査部１０７は、ＩＰパケットがフラグメントされたパケットの場合、最後のフラグメントパケットか途中のフラグメントパケットかを検査する。フラグメント検査部１０７は、検査結果をＣＰＵ１１０及びセレクタ１１１へ伝える。

セレクタ１１１は、パケットが、フラグメントパケットの場合には、チェックサム演算部１０３で演算されたパケットのチェックサム値をチェックサム値一時記憶部１０８へ送り、フラグメントパケットでない場合には、チェックサム検査部１０９へ送る。

チェックサム値一時記憶部１０８は、同一の識別子を持つフラグメントパケットが全て到着するまで、各パケットのチェックサム値を一時的に格納しておくメモリである。全てのパケットの到着が終了したら、記憶されているチェックサム値がＣＰＵ１１０によって読み出され、ＣＰＵ１１０によるパケットの再組み立て処理と、チェックサム検査処理とに使用される。

また、チェックサム検査部１０９は、チェックサム演算部１０３から送られた演算チェックサム値と、ヘッダ情報解析部１０６のチェックサム情報１０６ａから送られたチェックサム値とを比較する。そして、チェックサム検査部１０９は、検査結果（比較結果）をＣＰＵ１１０及び受信パケットバッファ１０４へ伝える。

受信パケットバッファ１０４は、チェックサム値が不一致であることを示す検査結果を受け取ると、保持している受信パケットを破棄する処理を行う。

ＣＰＵ１１０は、ヘッダ情報解析部１０６で解析されたＩＰヘッダ、ＴＣＰヘッダの各種情報、フラグメント検査部１０７の検査結果、チェックサム検査部１０９の検査結果を受け、これらの情報に基づいて、各種制御を行う。また、ＣＰＵ１１０は、チェックサム値一時記憶部１０８に格納されているチェックサム値等の情報受け、この情報等にも基づいて、各種制御を行う。なお、制御としては、例えば、受信バッファ１０５中のパケットディスクリプタ１０５ａの制御や、データ領域１０５ｂへのデータの読み出し、書き込み制御等がある。また、制御として、受信パケットバッファ１０４がパケットデータを書き込む際のメモリアドレスの指定制御、フラグメントされたパケットの再組み立て処理制御、上位プロトコルであるＴＣＰプロトコル処理制御等がある。但し、ＣＰＵ１１０の制御処理手順等の詳細については後述するフローチャートを使用して説明する。

図５は、受信バッファ１０５の詳細なデータ構造を説明するための図である。なお、図５では、ある一つのパケットデータが受信バッファ１０５に格納されている場合のデータ構造を表している。

図５において、５０１、５０２は１０５ａで示されたパケットディスクリプタ、５０３、５０４は１０５ｂで示されたデータバッファである。データバッファ１０５ｂは、メモリ領域がある大きさの単位ごとに分割されており、受信バッファ１０５は、これら複数の分割領域の関連付けをパケットディスクリプタ１０５ａ中に記述されているデータによって管理するキュー構造となっている。

５０１には、ｐ＿ｎｅｘｔ１（５０１ａ）、ｐ＿ｄａｔａ１（５０１ｂ）、ｌｅｎ１（５０１ｃ）、ｐｋｔｌｅｎ１（５０１ｄ）、ｐ＿ｂｕｆ１（５０１ｅ）、ｓｉｚｅ１（５０１ｆ）、その他の情報１（５０１ｇ）等のデータがそれぞれ含まれている。同様に、５０２には、ｐ＿ｎｅｘｔ２（５０２ａ）、ｐ＿ｄａｔａ２（５０２ｂ）、ｌｅｎ２（５０２ｃ）、ｐｋｔｌｅｎ２（５０２ｄ）、ｐ＿ｂｕｆ２（５０２ｅ）、ｓｉｚｅ２（５０２ｆ）、その他の情報２（５０２ｇ）等のデータがそれぞれ含まれている。

また、５０３にはｈｅａｄｅｒ１（５０３ａ）、ｄａｔａ１（５０３ｂ）、５０４にはｄａｔａ２（５０４ａ）がそれぞれ含まれており、これら５０３、５０４はそれぞれパケットデータを格納する分割領域の一つである。

５０３はパケットデータの先頭ブロックが格納されているデータバッファとして、５０３ａで示すＴＣＰヘッダ及びＩＰヘッダのデータ、及び５０３ｂで示すペイロードデータが含まれている。また５０４はパケットデータの続きのブロックが格納されているデータバッファであり、５０４ａ出示す続きのペイロードデータが含まれている。

なお、図５では、一つのパケットが複数のデータバッファ（５０３，５０４）に分割して格納されている例を示しているが、通常は一つのパケットは一つのデータバッファに収められる場合が多い。但し、フラグメントされたパケットを受信した場合には、それぞれの分割パケットは異なる時間に到着するために、到着ごとに分割したブロックに格納して管理される。

次に、パケットディスクリプタ５０１には、データバッファ５０３や、パケットデータ５０３ａ、５０３ｂに関連する各種情報及びパケットディスクリプタのキュー構造管理のための情報等が格納されている。

ｐ＿ｎｅｘｔ１（５０１ａ）は、次のブロックのパケットディスクリプタが存在する場合に次のパケットディスクリプタの先頭アドレスを示すポインタ情報であり、図５の例では５０２の領域の先頭アドレスが格納されている。次のパケットディスクリプタが存在しない、つまり、最後のブロックに対するパケットディスクリプタの場合は、ＮＵＬＬが格納される。

ｐ＿ｄａｔａ（５０１ｂ）には、データバッファにおいて、このパケットディスクリプタの対象となるデータバッファ５０３において、実際に格納されているパケットデータ５０３ａ、５０３ｂの先頭を示すポインタであるアドレスが格納されている。またｌｅｎ１（５０１ｃ）には、パケットデータ５０３ａ、５０３ｂを合わせたデータ長が格納されている。ｐｋｔｌｅｎ１（５０１ｄ）にはパケット全体のデータ長、つまり、５０３ａ、５０３ｂ、５０４ａの合計サイズが格納されている。この合計サイズは一つのパケットが複数ブロックで構成される場合には、先頭ブロックのパケットディスクリプタにのみ格納されるものである。

次にｐ＿ｂｕｆ１（５０１ｅ）には、データバッファにおいて、このパケットディスクリプタの対象となるデータバッファ５０３の先頭を示すポインタであるアドレスが格納されている。またｓｉｚｅ１（５０１ｆ）には、データバッファ５０３のサイズが格納されている。

その他の情報１（５０１ｇ）には、その他パケットデータを管理するための情報、例えばデータバッファが複数の分割サイズをもって管理される場合にはそのブロックタイプ、次の識別子を持つパケットへのポインタ情報等が格納されている。

パケットディスクリプタ５０２には、データバッファ５０４や、パケットデータ５０４ａに関連する各種情報及びパケットディスクリプタのキュー構造管理のための情報等が格納されている。

５０２に格納されている情報の構成は５０１で説明した構成と同様であるが、ｐｋｔｌｅｎ２（５０２ｄ）に示されるパケット全体のデータ長の情報は、５０２がパケットの先頭ブロックのパケットディスクリプタではないので、ＮＵＬＬが格納される。

図６は、実施形態１のＣＰＵ１１０が実行するソフトウェアの制御を示すフローチャートである。なお、ＣＰＵ１１０は、図６に示す処理を常に繰り返し、実行している。

ステップＳ６０１において、ＣＰＵ１１０は、パケットが受信されるのを待つ処理を行う。ステップＳ６０２において、ＣＰＵ１１０は、パケットを受信したか否かを判定する。ＣＰＵ１１０は、パケットを受信したと判定すると、ステップＳ６０３に進み、パケットを受信していないと判定すると、ステップＳ６０２の処理を繰り返す。

ステップＳ６０３において、ＣＰＵ１１０は、ヘッダ情報解析部１０６において算出されたパケットのＩＰヘッダのチェックサム検査結果（演算チェックサム値）を取得する。ステップＳ６０４において、ＣＰＵ１１０は、ステップＳ６０３において取得した演算チェックサム値と、パケットのＩＰヘッダ中のチェックサム値とを比較して、受信したパケットが正常なパケットか否かを判定する。

つまり、ＣＰＵ１１０は、ステップＳ６０３において取得した演算チェックサム値と、パケットのＩＰヘッダ中のチェックサム値とが一致する場合は、正常なパケットであると判定し、ステップＳ６０５に進む。一方、ＣＰＵ１１０は、ステップＳ６０３において取得した演算チェックサム値と、パケットのＩＰヘッダ中のチェックサム値とが一致しない場合は、正常なパケットでないと判定し、受信パケットバッファ１０４中に格納されたパケットデータを破棄する。そして、ＣＰＵ１１０は、図６に示す処理を終了する。

ステップＳ６０５において、ＣＰＵ１１０は、受信バッファ１０５のデータバッファ１０５ｂ中に受信パケット用のデータバッファを確保する。そして、ＣＰＵ１１０は、このデータバッファを受信パケットバッファ１０４からの書き込み用に割り当てる処理、及びこのデータバッファを管理する等のためのパケットディスクリプタ１０５ａを生成する処理を行う。これらのデータバッファ、パケットディスクリプタは図５で説明したようなキュー構造で管理されるものである。

続いて、ステップＳ６０６において、ＣＰＵ１１０は、ヘッダ情報解析部１０６より、ＴＣＰヘッダに埋め込まれているチェックサム値等を含むパケットヘッダ情報を取得する。なお、このチェックサム値は、後述するチェックサム検査処理、或いはＴＣＰ制御等の上位プロトコル処理において利用される。

続いて、ステップＳ６０７において、ＣＰＵ１１０は、フラグメント検査部１０７より、検査結果、つまり、受信したＩＰパケットがフラグメントされているパケット（ＩＰフラグメントパケット）か否かの情報を取得する。

続いて、ステップＳ６０８において、ＣＰＵ１１０は、ステップＳ６０７において取得した検査結果に基づいて、受信したＩＰパケットがＩＰフラグメントパケットか否かを判定する。ＣＰＵ１１０は、受信したＩＰパケットがＩＰフラグメントパケットであると判定すると、ステップＳ６１４に進み、受信したＩＰパケットがＩＰフラグメントパケットでないと判定すると、ステップＳ６０９に進む。

ステップＳ６０９において、ＣＰＵ１１０は、チェックサム検査部１０９より、ＴＣＰパケットのチェックサムの検査結果を取得する。ここで、ＴＣＰパケットのチェックサムの検索結果とは、チェックサム演算部１０３で計算されたＴＣＰパケットのチェックサム値と、ヘッダ情報解析部１０６でＴＣＰヘッダから読み出されたチェックサム値とが一致するか否かの情報である。

ステップＳ６１０において、ＣＰＵ１１０は、ステップＳ６０９において取得したＴＣＰパケットのチェックサムの検査結果に基づいて、正常なパケットか否かを判定する。ＣＰＵ１１０は、正常なパケットであると判定すると、ステップＳ６１１に進み、正常なパケットでないと判定すると、ステップＳ６１３に進む。ＣＰＵ１１０は、チェックサム演算部１０３で計算されたＴＣＰパケットのチェックサム値と、ヘッダ情報解析部１０６でＴＣＰヘッダから読み出されたチェックサム値とが一致していると、正常なパケットであると判定する。一方、ＣＰＵ１１０は、チェックサム演算部１０３で計算されたＴＣＰパケットのチェックサム値と、ヘッダ情報解析部１０６でＴＣＰヘッダから読み出されたチェックサム値とが一致していないと、正常なパケットでないと判定する。

受信パケットバッファ１０４中に格納されたパケットデータが破棄されるのに伴い、ステップＳ６１３において、ＣＰＵ１１０は、ステップＳ６０５で受信パケット用に確保した受信バッファ１０５中のデータバッファやパケットディスクリプタをメモリ開放する。

ステップＳ６１１において、ＣＰＵ１１０は、受信バッファ１０５のコントロール処理を実行する。このコントロール処理は、受信バッファ１０５中のメモリブロックに書き込まれたパケットデータに対応して、パケットディスクリプタ中の各項目に数値を書き込む処理である。なお、この数値とは、受信したパケットのサイズや、メモリブロック中のアドレス、ヘッダ情報を参照して取得したパケット全体のデータ長等の情報、更に次のパケットのディスクリプタへのポインタアドレス等である。

続いて、ステップＳ６１２において、ＣＰＵ１１０は、上位プロトコルであるＴＣＰの制御処理を実行する。ＴＣＰの制御処理の詳細な説明は割愛するが、コネクション管理、フロー制御、輻輳制御等が含まれる。

一方、ステップＳ６１４において、ＣＰＵ１１０は、全てのフラグメントパケットが到着したか否か判定する。ＣＰＵ１１０は、同一の識別子を持つＩＰパケットのフラグ３０４、及びフラグメントオフセット３０５に基づいて、全てのフラグメントパケットが到着したか否か判定する。

ＣＰＵ１１０は、全てのフラグメントパケットが到着したと判定すると、ステップＳ６１５に進み、全てのフラグメントパケットが到着していないと判定すると、ステップＳ６１９に進む。

ステップＳ６１９において、ＣＰＵ１１０は、ステップＳ６１１と同様に、受信バッファ１０５のコントロール処理として、受信したパケットのサイズや、メモリブロック中のアドレスの書き込みを行う。また、ＣＰＵ１１０は、先頭ブロックの受信の場合は、パケット全体のデータ長の書き込み、次のパケットのディスクリプタへのポインタアドレスの書き込み等を実行する。

この受信バッファ１０５のコントロール処理をフラグメントパケットが到着する度に実行することにより、各データバッファ１０５ｂに格納されたフラグメントパケットを連続したデータとして扱うことができ、パケットの再組み立て処理を実行することができる。

ステップＳ６１５において、ＣＰＵ１１０は、チェックサム値一時記憶部１０８に記憶されている全てのパケットの演算チェックサム値を加算する処理を行う。この加算処理により再組み立て処理されたパケットのチェックサム値（データチェックサム）を求めることができる。

続いて、ステップＳ６１６において、ＣＰＵ１１０は、ステップＳ６１５において求めた再組み立て処理されたパケットのチェックサム値と、ＴＣＰヘッダ中のチェックサム値と、を比較し、一致するか否かを判定する。ＣＰＵ１１０は、ステップＳ６１５において求めた再組み立て処理されたパケットのチェックサム値と、ＴＣＰヘッダ中のチェックサム値と、が一致すると判定すると、ステップＳ６１１に進む。一方、ＣＰＵ１１０は、ステップＳ６１５において求めた再組み立て処理されたパケットのチェックサム値と、ＴＣＰヘッダ中のチェックサム値と、が一致しないと判定すると、ステップＳ６１８に進む。

ステップＳ６１８において、ＣＰＵ１１０は、ステップＳ６１３と同様に、ステップＳ６０５で受信パケット用に確保した受信バッファ１０５中のデータバッファやパケットディスクリプタをメモリ開放する。

（実施形態２）
実施形態１では、フラグメントされたパケットを検出した場合には、常にその再組み立て処理をＣＰＵ１１０で実行する例を用いて説明を行った。しかしながら、ＴＣＰ／ＩＰを用いたネットワークプロトコルにおいては、フラグメントされたパケットの到着順序は保証されていないが、送信されたパケットが複雑なネットワーク経路を通らなければ比較的先頭パケットから順番に到着する場合が多い。

フラグメントされたパケットを先頭から順次受信する場合においては、受信データをメモリ上に連続的に書き込むことができるため、この書き込み処理においては複雑なメモリ管理は必要なく、単純なアドレスのインクリメントだけでよい。よって、回路規模も大きくなることはない。

従って、実施形態２においては、フラグメントされたパケットを受信した場合にも、そのパケットが先頭ブロックから順番に到着している間は、ハードウェアにより自動的に受信バッファメモリに書き込む制御を行う。そして、到着順序が入れ替わったことを検出した時点で再組み立て処理をＣＰＵ１００によって行う例を説明する。

図７は、実施形態２に係る装置の全体構成を表すブロック図である。実施形態２においても、ネットワークの物理層、データリンク層としてＩＥＥＥ８０２．３に代表される有線ＬＡＮの規格であるイーサネット（登録商標）を用いて説明する。また、ネットワーク層、トランスポート層としてＴＣＰ／ＩＰプロトコルを用いて説明する。

図７において、１０１のＭＡＣ（メディアアクセスコントロール）、１０２のＴＣＰ（ＵＤＰ）／ＩＰデフレーマは実施形態１と同様の制御を行う。ＴＣＰ（ＵＤＰ）／ＩＰデフレーマ１０２によって抽出されたヘッダデータは、ヘッダ情報解析部１０６へ送られ、またパケットデータは、チェックサム演算部１０３へ送られる。ヘッダ情報解析部１０６、チェックサム演算部１０３もそれぞれ実施形態１と同様の制御を行う。

受信パケットバッファ１０４及び受信バッファ１０５も実施形態１と同様にパケットデータを格納するメモリであり、受信バッファ１０５は図５で説明したようなキュー構造として管理されている。

ＴＣＰ（ＵＤＰ）／ＩＰデフレーマ１０２において抽出されたＩＰヘッダ、ＴＣＰヘッダデータは、ヘッダ情報解析部１０６によって、各種ヘッダの内容が解析された後、ＣＰＵ１１０で処理される上位プトロコルであるＴＣＰプロトコル制御へ渡される。実施形態２におけるＣＰＵ１１０の処理手順等については後述のフローチャートで詳細に説明する。

フラグメント検査部７０７は、ヘッダ情報解析部１０６で解析されたフラグ情報１０６ｂを読み出し、ＩＰパケットがフラグメントされたパケットか否かを判定する。また、フラグメント検査部７０７は、ＩＰパケットがフラグメントされたパケットの場合、最後のフラグメントパケットか、途中のフラグメントパケットかを検査する。また、フラグメント検査部７０７は、ＩＰパケットがフラグメントされたパケットの場合、フラグメントパケットが先頭から連続した順序で到着したフラグメントパケットか否か、連続した順序で到着していた場合、最後のフラグメントパケットか否かを検査する。フラグメント検査部７０７は、これらの検査結果をＣＰＵ１１０、又はセレクタ７１１へ伝える。

セレクタ７１１は、ＩＰパケットが不連続に到着したフラグメントパケットであると判断された場合には、チェックサム演算部１０３において演算されたパケットのチェックサム値をチェックサム値一時記憶部７０８へ送る。また、セレクタ７１１は、ＩＰパケットがフラグメントパケットでないと判断された場合には、チェックサム演算部１０３において演算されたパケットのチェックサム値を、セレクタ７１３を介してチェックサム検査部７０９へ送る。

また、セレクタ７１１は、先頭から連続した順序で到着したフラグメントパケットであると判断された場合には、チェックサム演算部１０３において演算されたパケットのチェックサム値をチェックサム加算部７１２へ送る。

チェックサム値一時記憶部７０８は、同一の識別子を持つフラグメントパケットが全て到着するまで、各パケットのチェックサム値を一時的に格納しておくメモリである。全てのパケットの到着が終了したら、記憶されているチェックサム値がＣＰＵ１１０によって読み出され、ＣＰＵ１１０によるパケットの再組み立て処理と、チェックサム検査処理とに使用される。

連続したフラグメントパケットを受信した場合、チェックサム加算部７１２は、チェックサム値一時記憶部７０８に格納されているチェックサム値の内、同一の識別子を持つフラグメントパケットのチェックサム値を読み出す。そして、チェックサム加算部７１２は、チェックサム値を加算した後、再びチェックサム値一時記憶部７０８に書き込む制御を行う。つまり、連続したフラグメントパケットを受信している間は、これまで到着した同一識別子のパケットのチェックサム値の総和がチェックサム値一時記憶部７０８に記憶される。

また、フラグメント検査部７０７において、連続したフラグメントパケットとして到着したパケットの内、最後のパケットであると検出された場合、セレクタ７１１は、その検出結果をセレクタ７１３に伝える。セレクタ７１３は、前記検出結果を受け取ると、チェックサム値一時記憶部７０８に格納されているチェックサム値をチェックサム検査部７０９に送り出す。また、セレクタ７１３は、前記検出結果以外の検出結果（又は前記検出結果以外の制御信号）を受け取ると、チェックサム演算部１０３で計算されたチェックサム値をチェックサム検査部７０９に送り出す。

このような処理によって、チェックサム値一時記憶部７０８から送り出されるチェックサム値は、最終的にパケット全体のチェックサム値となり、このチェックサム値に対してチェックサム検査が行われる。

フラグメント検査部７０７において、フラグメントされていないパケットであると判断された場合には、上述したようにチェックサム演算部１０３で演算されたチェックサム値がチェックサム検査部７０９に送られる。

チェックサム検査部７０９は、チェックサム演算部１０３から送られたチェックサム値と、ヘッダ情報解析部１０６のチェックサム情報１０６ａから送られたチェックサム値とを比較し、検査結果をＣＰＵ１１０及び受信パケットバッファ１０４へ伝える。

受信パケットバッファ１０４はチェックサム値の不一致を検出すると受信パケットを破棄する処理を行う。

ＣＰＵ１１０は、ヘッダ情報解析部１０６で解析されたＩＰヘッダ、ＴＣＰヘッダの各種情報、フラグメント検査部７０７の検査結果、チェックサム検査部７０９の検査結果を受け、これらの情報に基づいて、各種制御を行う。また、ＣＰＵ１１０は、チェックサム値一時記憶部７０８に格納されているチェックサム値等の情報受け、この情報等にも基づいて、各種制御を行う。なお、制御としては、例えば、受信バッファ１０５中のパケットディスクリプタ１０５ａの制御や、データ領域１０５ｂへのデータの読み出し、書き込み制御等がある。また、制御として、受信パケットバッファ１０４がパケットデータを書き込む際のメモリアドレスの指定制御、フラグメントされたパケットの再組み立て処理制御、上位プロトコルであるＴＣＰプロトコル処理制御等がある。但し、ＣＰＵ１１０の制御処理手順等の詳細については後述するフローチャートを使用して説明する。

図８は、連続したフラグメントパケットを受信した場合に、データバッファ１０５ｂ中のメモリブロックに書き込まれるデータの構造を示す図である。図８において、８０１はヘッダデータ部でありＩＰヘッダ情報が格納されている。８０２は、フラグメントされた最初のデータ部であり、ＴＣＰヘッダ等の上位プロトコルのヘッダ及びペイロードの一部が含まれる。８０１のデータと、８０２のデータとを合わせた部分が先頭のフラグメントパケットとして受信される。

８０３は２番目のデータ部、８０４は３番目のデータ部を表わしており、８０３のデータと、８０４のデータとをそれぞれ受信する度に前のデータの後ろに追加されてデータバッファ１０５ｂ中のメモリブロックに書き込まれる。

図９は、実施形態２のＣＰＵ１１０が実行するソフトウェアの制御を示すフローチャートである。なお、ＣＰＵ１１０は、図９に示す処理を常に繰り返し、実行している。

ステップＳ９０１からステップＳ９０７までの処理は、実施形態１の図６に示したステップＳ６０１からステップＳ６０７までの処理と同様である。

ステップＳ９０８において、ＣＰＵ１１０は、ステップＳ９０７において取得した検査結果に基づいて、受信したＩＰパケットがＩＰフラグメントパケットか否かを判定する。ＣＰＵ１１０は、受信したＩＰパケットがＩＰフラグメントパケットであると判定すると、ステップＳ９２０に進み、受信したＩＰパケットがＩＰフラグメントパケットでないと判定すると、ステップＳ９０９に進む。

ステップＳ９０９からステップＳ９１３までの処理は、実施形態１の図６に示したステップＳ６０９からステップＳ６１３までの処理と同様である。

ステップＳ９２０において、ＣＰＵ１１０は、ハードウェアによる再組み立て制御を行っているパケットデータか否か、つまり、連続して到着しているフラグメントパケットか否かを判定する。ＣＰＵ１１０は、ハードウェアによる再組み立て制御を行っているパケットデータであると判定すると、ステップＳ９２１に進み、ハードウェアによる再組み立て制御を行っているパケットデータでないと判定すると、ステップＳ９１４に進む。

ステップＳ９２１において、ＣＰＵ１１０は、再組み立てが終了しているか否か、つまり、同一識別子パケットの最後のデータを受信して完成したパケットデータとして図８に示されるようなメモリブロックに書き込まれているパケットか否かを判定する。ＣＰＵ１１０は、再組み立てが終了していると判定すると、ステップＳ９０９に進み、再組み立てが終了していないと判定すると、ステップＳ９２２に進む。ＣＰＵ１１０は、フラグメント検査部７０７より出力された検査結果等に基づいて再組み立てが終了しているか否かを判定する。

ステップＳ９２２において、ＣＰＵ１１０は、ＣＰＵ１１０は、受信バッファ１０５のコントロール処理として、パケットのサイズやメモリブロック中のアドレスの更新処理を実行する。

ステップＳ９１４からステップＳ９１９までの処理は、実施形態１の図６に示したステップＳ６１４からステップＳ６１９までの処理と同様である。

（実施形態３）
上述した実施形態では、全てのフラグメントパケットに重複領域がない場合を例に説明を行った。このような場合では、ＣＰＵ１１０が処理するチェックサム演算は、チェックサム値一時記憶部１０８に記憶されている各フラグメントパケットのチェックサム値を加算するだけで、再組み立てされたパケット全体のチェックサム値を求めることができた。

しかしながら、複数のセグメントにまたがるネットワークにおいては、同じ識別子のフラグメントパケットが別の経路を経由し、装置に到着する場合や、再送によって同一のペイロードデータが異なるサイズのフラグメントパケットとして生成される場合も存在する。その結果、重複領域を持ったフラグメントパケットが装置に到着することになり、フラグメントパケットごとのチェックサム値を単純に加算するだけではパケット全体のチェックサム値を求めることができない場合も出てくる。

実施形態３では、重複領域が存在するフラグメントパケットを受信した場合でも、ＣＰＵ１１０において、チェックサム値の全ての再計算を行わないですむよう、処理を行う例を説明する。このような処理を行うことで、高速にチェックサム検査を行うことができる。

図１０は、再送処理によって重複が発生しているフラグメントパケットの構成例を示す図である。図１０において、１００１ａは送信時における元のパケットデータにおけるＩＰヘッダ部、１００１ｂはペイロード部を表わしている。

また、１００２ａ、１００２ｂ、１００３ａ、１００３ｂ、１００４ａ、１００４ｂはそれぞれ、送信後に３分割としてフラグメントされたパケットの構成例であり、それぞれＩＰヘッダ及びペイロードを示している。

更に、１００５ａ、１００５ｂ、１００６ａ、１００６ｂ、１００７ａ、１００７ｂ、１００８ａ、１００８ｂはそれぞれ、受信側からのＴＣＰ再送要求により再送されたパケットの構成例で、それぞれＩＰヘッダ及びペイロードを示している。最初に送信したパケットとは違うネットワーク経路を経由したことにより、４分割としてフラグメントされたパケットとなっている。

図１１は、重複したフラグメントパケットが生成された場合の受信パケットの構成例を示す図（その１）である。図１１において、フラグメントパケットのうち「１１０１で示すパケット」、「１１０２で示すパケット」の順で受信した場合、ペイロードの重複領域は１１０３に示す範囲となり、重複領域は受信パケット１１０２の半分のサイズより小さい。

図１２は、重複したフラグメントパケットが生成された場合の受信パケットの構成例を示す図（その２）である。図１２において、フラグメントパケットのうち「１２０１で示すパケット」、「１２０２で示すパケット」、「１２０３で示すパケット」の順で受信した場合は、ペイロードの重複領域は１２０４に示す範囲となる。この重複領域は受信パケット１２０３の半分のサイズより大きい。

図１３は、実施形態３のＣＰＵ１１０が実行するソフトウェアの制御を示すフローチャートである。なお、ＣＰＵ１１０は、図１３に示す処理を常に繰り返し、実行している。

ステップＳ１３０１からステップＳ１３０７までの処理は、実施形態１の図６に示したステップＳ６０１からステップＳ６０７までの処理と同様である。

ステップＳ１３０８において、ＣＰＵ１１０は、ステップＳ１３０７において取得した検査結果に基づいて、受信したＩＰパケットがＩＰフラグメントパケットか否かを判定する。ＣＰＵ１１０は、受信したＩＰパケットがＩＰフラグメントパケットであると判定すると、ステップＳ１３２０に進み、受信したＩＰパケットがＩＰフラグメントパケットでないと判定すると、ステップＳ１３０９に進む。

ステップＳ１３０９からステップＳ１３１３までの処理は、実施形態１の図６に示したステップＳ６０９からステップＳ６１３までの処理と同様である。

ステップＳ１３２０において、ＣＰＵ１１０は、受信したフラグメントパケットのデータと、既に受信している同一識別子のフラグメントパケットのデータとに重複領域があるか否かを判定する。ＣＰＵ１１０は、重複領域があると判定すると、ステップＳ１３２１に進み、重複領域がないと判定すると、ステップＳ１３１４に進む。

ステップＳ１３２１において、ＣＰＵ１１０は、チェックサム値一時記憶部１０８に格納されているチェックサム値の補正処理を実行し、ステップＳ１３１４に進む。ステップＳ１３２１の処理の詳細は、後述する図１４に示す。

ステップＳ１３１４からステップＳ１３１９までの処理は、実施形態１の図６に示したステップＳ６１４からステップＳ６１９までの処理と同様である。

図１４は、チェックサム値の補正処理を示すフローチャートである。ステップＳ１４０１において、ＣＰＵ１１０は、フラグメントパケットの重複領域のサイズを算出する処理を行う。このサイズの算出は、受信バッファ１０５中のパケットディスクリプタ１０５ａに記述されている、受信したフラグメントパケットのパケット情報、及び受信したフラグメントパケットと同一識別子を持つフラグメントパケットのパケット情報を用いて行われる。

続いて、ステップＳ１４０２において、ＣＰＵ１１０は、算出したサイズが受信したフラグメントパケットのサイズの１／２以下か否かを判定する。ＣＰＵ１１０は、算出したサイズが受信したフラグメントパケットのサイズの１／２以下であると判定すると、ステップＳ１４０３に進み、算出したサイズが受信したフラグメントパケットのサイズの１／２以下でないと判定すると、ステップＳ１４０７に進む。

ステップＳ１４０３において、ＣＰＵ１１０は、受信したフラグメントパケットの内、重複している領域のデータのチェックサム値を算出する。続いて、ステップＳ１４０４において、ＣＰＵ１１０は、チェックサム値一時記憶部１０８に格納されている受信したフラグメントパケットのチェックサム値を読み出す。

続いて、ステップＳ１４０５において、ＣＰＵ１１０は、ステップＳ１４０４において読み出したチェックサム値から、ステップＳ１４０３において算出したチェックサム値を減算した値を求める。この処理によって、重複していない領域のデータのチェックサム値を求めることができる。続いて、ステップＳ１４０６において、ＣＰＵ１１０は、ステップＳ１４０５において求めた値（チェックサム値）を再びチェックサム値一時記憶部１０８に書き戻す。

一方、ステップＳ１４０７において、ＣＰＵ１１０は、受信したフラグメントパケットの内、重複していない領域のデータのチェックサム値を算出する。続いて、ステップＳ１４０８において、ＣＰＵ１１０は、チェックサム値一時記憶部１０８に格納されている受信したフラグ面とパケットのチェックサム値を、ステップＳ１４０７において算出したチェックサム値に置き換える。

上述したように、フラグメントパケットの重複領域が発生した場合にも、重複領域のみの演算処理と、非重複領域のみの演算処理とを切り替えると共に、チェックサム演算部１０３で演算されたチェックサム値を利用する。よって、ソフトウェアによりパケット領域全てのチェックサム値の再演算を行うことなく、高速にチェックサム検査を行うことができる。つまり、ＣＰＵ１１０の演算量を削減することができる。

定常的なパケット、及び否定常的なパケット（フラグメントパケット）を小さな回路規模で高速に処理することができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

イーサネット（登録商標）におけるＴＣＰ／ＩＰパケットのデータ構造を示す図である。 ＩＰパケットのデータ構造を示す図である。 ＴＣＰパケットのデータ構造を示す図である。 実施形態１に係る装置の全体構成を表すブロック図である。 受信バッファ１０５の詳細なデータ構造を説明するための図である。 実施形態１のＣＰＵ１１０が実行するソフトウェアの制御を示すフローチャートである。 実施形態２に係る装置の全体構成を表すブロック図である。 連続したフラグメントパケットを受信した場合に、データバッファ１０５ｂ中のメモリブロックに書き込まれるデータの構造を示す図である。 実施形態２のＣＰＵ１１０が実行するソフトウェアの制御を示すフローチャートである。 再送処理によって重複が発生しているフラグメントパケットの構成例を示す図である。 重複したフラグメントパケットが生成された場合の受信パケットの構成例を示す図（その１）である。 重複したフラグメントパケットが生成された場合の受信パケットの構成例を示す図（その２）である。 実施形態３のＣＰＵ１１０が実行するソフトウェアの制御を示すフローチャートである。 チェックサム値の補正処理を示すフローチャートである。

符号の説明

１１０ ＣＰＵ
１０３ チェックサム演算部
１０５ 受信バッファ
１０７ フラグメント検査部
１０９ チェックサム検査部

Claims (11)

1. 受信パケットのデータチェックサム計算を行うチェックサム演算手段と、
   前記チェックサム演算手段で求めたチェックサム値と、受信パケットのパケットヘッダに格納されているチェックサム値とを使用してデータチェックサム検査を行うチェックサム検査手段と、
   前記受信パケットが断片化されたパケットか否かを判断するフラグメント検査手段と、
   前記チェックサム演算手段で求めたチェックサム値を一時的に格納するチェックサム記憶手段と、
   断片化されたパケットの再組み立て処理、及び前記チェックサム記憶手段に格納されているチェックサム値と、前記再組み立てされたパケットのパケットヘッダに格納されているチェックサム値とを使用して再組み立てされたパケットのデータチェックサム検査処理を実行する制御手段と、
   を有し、
   前記フラグメント検査手段において前記受信パケットが断片化されたパケットであると判断された場合は、前記制御手段においてチェックサム検査を行い、前記フラグメント検査手段において前記受信パケットが断片化されたパケットでないと判断された場合は、前記チェックサム検査手段においてチェックサム検査を行うことを特徴とするプロトコル処理装置。
2. 少なくとも前記チェックサム演算手段、及び前記チェックサム検査手段は、専用の回路で構成されていることを特徴とする請求項１記載のプロトコル処理装置。
3. 前記受信パケットを格納するデータバッファと、複数の前記データバッファの連結に係る連結情報を格納する管理バッファと、を有する受信バッファ手段を更に有し、
   断片化されたパケットを受信した場合、前記制御手段は、前記連結情報を用いて、同一の識別子を有するパケットが格納された前記データバッファを連結するように制御し、断片化されたパケットの再組み立て処理を行うことを特徴とする請求項１又は２記載のプロトコル処理装置。
4. 断片化されたパケットを、先頭から連続した順序で受信している間は、パケットを受信するごとに、パケットのデータチェックサム計算を行い、チェックサム値を積算していくチェックサム加算手段を更に有し、
   断片化されたパケットを、先頭から後尾まで連続した順序で受信した場合、前記チェックサム検査手段は、前記チェックサム加算手段で求めたチェックサム値と、前記断片化されたパケットのパケットヘッダに格納されているチェックサム値とを使用してデータチェックサム検査を行い、
   最初に受信した断片化されたパケットが先頭ではなかった場合、又は断片化されたパケットが連続した順序ではなくなった場合、前記制御手段は、断片化されたパケットの再組み立て処理を行うことを特徴とする請求項１乃至３何れか１項記載のプロトコル処理装置。
5. 前記制御手段は、断片化されたパケットの内、各パケットに重複する領域がある場合、重複する領域のデータ又は重複していない領域のデータを用いて、データチェックサム計算を行い、チェックサム値を求め、前記チェックサム値を用いて、前記チェックサム演算手段で求められたチェックサム値の補正を行うことを特徴とする請求項１乃至４何れか１項記載のプロトコル処理装置。
6. 前記制御手段は、前記重複する領域がパケット長の１／２より小さい場合には、重複する領域のデータを用いて、データチェックサム計算を行うことを特徴とする請求項５記載のプロトコル処理装置。
7. 前記制御手段は、前記重複する領域がパケット長の１／２より大きい場合には、重複していない領域のデータを用いて、データチェックサム計算を行うことを特徴とする請求項５記載のプロトコル処理装置。
8. 前記制御手段は、前記チェックサム記憶手段に格納されている、前記チェックサム演算手段で求められたチェックサム値から、前記重複する領域のデータを用いてデータチェックサム計算を行い、求めたチェックサム値を減算し、前記チェックサム記憶手段に書き戻すことにより、重複していない領域のチェックサム値を求めることを特徴とする請求項６記載のプロトコル処理装置。
9. 前記制御手段は、前記チェックサム記憶手段に格納されている、前記チェックサム演算手段で求められたチェックサム値を、前記重複していない領域のデータを用いてデータチェックサム計算を行い、求めたチェックサム値に書き換えることにより、重複していない領域のチェックサム値を求めることを特徴とする請求項７記載のプロトコル処理装置。
10. プロトコル処理装置におけるプロトコル処理方法であって、
    受信パケットのデータチェックサム計算を行うチェックサム演算ステップと、
    前記チェックサム演算ステップにおいて求められたチェックサム値と、受信パケットのパケットヘッダに格納されているチェックサム値とを使用してデータチェックサム検査を行うチェックサム検査ステップと、
    前記受信パケットが断片化されたパケットか否かを判断するフラグメント検査ステップと、
    前記チェックサム演算ステップで求めたチェックサム値を一時的にチェックサム記憶手段に格納する格納ステップと、
    断片化されたパケットの再組み立て処理、及び前記チェックサム記憶手段に格納されているチェックサム値と、前記再組み立てされたパケットのパケットヘッダに格納されているチェックサム値とを使用して再組み立てされたパケットのデータチェックサム検査処理を実行する制御ステップと、
    を有し、
    前記フラグメント検査ステップにおいて前記受信パケットが断片化されたパケットであると判断された場合は、前記制御ステップにおいてチェックサム検査を行い、前記フラグメント検査ステップにおいて前記受信パケットが断片化されたパケットでないと判断された場合は、前記チェックサム検査ステップにおいてチェックサム検査を行うことを特徴とするプロトコル処理方法。
11. 請求項１０記載のプロトコル処理方法をコンピュータに実行させることを特徴とするプログラム。

Images