(57)【要約】【課題】ＩＰパケットのフラグメント受信による性能低下を低減するデータ受信装置を提供する。【解決手段】データ受信装置１００は、ＭＡＣ受信装置１０１と、ＭＡＣ／Ｄｅ−Ｆｒａｍｅｒ１０２と、ＴＣＰ（ＵＤＰ）／ＩＰ／Ｄｅ−Ｆｒａｍｅｒ１０４と、チェックサム算出装置１１０と、デリミタチェッカ１１３と、アドレス生成装置１１５と、受信パケットバッファ１１７と、受信バッファ１１８とを備える。デリミタチェッカ１１３は、シフトレジスタ２０１と、デリミタ入力レジスタ２０２と、比較器２０３と、重複受信領域出力レジスタ２０４と、最終受信ポインタ保存メモリ２０５と、受信開始ポインタレジスタ２０６と、受信終了ポインタレジスタ２０７と、比較器２０８と、フラグメント受信完了判断装置２０９とを備える。【選択図】図１
2008092082.tif 000002
【特許請求の範囲】
【請求項１】
メディアアクセスコントロール層より上位のプロトコルを受信するデータ受信装置であって、
データリンク層の処理を行うデータリンク層処理手段と、
ネットワーク層及びトランスポート層のプロトコル解析を行うプロトコル解析手段と、
受信したパケットを保存する受信バッファと、
前記受信バッファの前段にパケットのチェックサムを算出するチェックサム算出手段と、
前記データリンク層処理手段からの処理情報と前記プロトコル解析手段からの解析情報とから前記断片化されたＩＰパケットの書き込みアドレス情報を生成するアドレス情報生成手段と、
断片化されたＩＰパケットの受信済領域を管理する管理手段と、
断片化されたＩＰパケットの受信処理において、前記アドレス生成装置が生成したアドレスに基づき前記受信バッファにパケットを書き込む書き込み手段と、を有し、
前記チェックサム算出手段は、前記チェックサムの算出を前記管理手段により管理される重複受信済領域を除外して行うことを特徴とするデータ受信装置。
【請求項２】
さらに、前記断片化されたＩＰパケットの内、先端若しくは後端のＩＰパケットから再組立ＩＰパケットの長さを算出する再組立ＩＰパケット長算出手段を備え、
前記書き込み手段は、前記受信バッファに保存されるＩＰパケットのＩＰヘッダの全長フィールドに当該算出された再組立ＩＰパケットの長さを書き込むことを特徴とする請求項１記載のデータ受信装置。
【請求項３】
さらに、前記断片化されたＩＰパケットの内、先端若しくは後端のＩＰパケットからペイロード部分の長さを算出するペイロード長算出手段を備え、
前記書き込み手段は、前記受信バッファに保存されるＩＰヘッダのペイロード長フィールドに当該算出されたペイロード部分の長さを書き込むことを特徴とする請求項１記載のデータ受信装置。
【請求項４】
前記管理手段は、前記断片化されたＩＰパケットの受信完了を通知する通知手段を備え、
該通知手段が当該受信完了を通知する場合、前記プロトコル解析手段は当該断片化されたＩＰパケットを再組立したＩＰパケットの内、ＩＰヘッダ又はＴＣＰヘッダ若しくはＵＤＰヘッダのチェックサム整合性検証を行うことを特徴とする請求項１乃至３のいずれか１項に記載のデータ受信装置。
【請求項５】
前記チェックサム算出手段は、前記算出したチェックサムの内、ペイロード部のチェックサムを用いて前記トランスポート層のチェックサムの算出を行うことを特徴とする請求項１乃至４のいずれか１項に記載のデータ受信装置。
【請求項６】
前記チェックサム算出格納手段は前記チェックサムの算出をＩＰヘッダの領域を除外して行うことを特徴とする請求項１乃至５のいずれか１項に記載のデータ受信装置。
【請求項７】
メディアアクセスコントロール層より上位のプロトコルを受信するデータ受信方法であって、
データリンク層の処理を行うデータリンク層処理ステップと、
ネットワーク層及びトランスポート層のプロトコル解析を行うプロトコル解析ステップと、
受信したＩＰパケットを保存する保存ステップと、
前記断片化されたＩＰパケットのチェックサムを算出するチェックサム算出ステップと、
前記データリンク層処理ステップの処理情報と前記プロトコル解析ステップの解析情報とから前記断片化されたＩＰパケットの書き込みアドレス情報を生成するアドレス情報生成ステップと、
前記断片化されたＩＰパケットの受信済領域を管理する管理ステップと、
受信した断片化されたＩＰパケットを前記アドレス情報生成ステップで生成した書き込みアドレス情報に基づいて書き込む書き込みステップとを有し、
前記チェックサム算出ステップは、前記チェックサムの算出を前記管理ステップにより管理される重複受信済領域を除外して行うことを特徴とするデータ受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ受信装置及びデータ受信方法に関し、ＩＰフラグメントされた複数のＩＰパケットを受信し再組立するデータ受信装置に関する。
【背景技術】
【０００２】
従来、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protcol）やＵＤＰ／ＩＰ（User Datagram Protocol/Internet Protcol）等のプロトコルを用いたネットワークが利用されている。当該ネットワークの場合、ＲＦＣ７９１ではＩＰレイヤにおける１パケット（Packet）あたりのペイロードを６５５３５オクテット（１オクテット（Octet）＝８ビット（bit））まで定義できる仕様となっている。また、ＩＰ層の下位層にあたるＩＥＥＥ８０２．３で定義されているイーサネット(登録商標)では、１パケットとして送出できる最大送信ユニット（Maximum Transfer Unit：MTU）は１５００オクテットとされている。
【０００３】
有限のネットワーク帯域をネットワークに接続されたステーション間で公平にシェアして使用するためには、１パケットのサイズを制限して特定のステーションによる帯域圧迫の影響を避けることが一般的である。
【０００４】
上述したようにＩＥＥＥ８０２．３イーサネット(登録商標)においてはＭＴＵは１５００オクテット、電話回線によるダイアルアップ接続においてはＭＴＵは５７６オクテットに設定される場合が多い。また、ＦＤＤＩにおいてはＭＴＵは４３５２オクテットに設定され、１Ｇｂｐｓ〜１０Ｇｂｐｓのイーサネット(登録商標)においてはＭＴＵを大きく設定して広帯域の優位性を引き出す場合がある。このようにＭＴＵは実装される物理層等によって異なっている。
【０００５】
ＭＴＵが１５００オクテットのイーサネット(登録商標)ネットワークに属しているステーションＡが、ステーションＢに１５００オクテットのパケットを送出する経路上にＭＴＵが５７６オクテットのネットワークを介する図９に示すようなパスを構成する。この場合、ネットワークＣにデータグラムを送出する際にネットワークを相互に接続するルータがＩＰパケットを断片化（フラグメント）することにより相互のネットワーク接続を確保する。
【０００６】
図１２及び図１３は、ＩＰフラグメントを説明する図である。
【０００７】
図９に示すように、ネットワークＡに属するホストＡとネットワークＢに属するホストＢとがネットワークＣを介して接続され、ネットワークＡ及びネットワークＢのＭＴＵを１５００オクテット、ネットワークＣのＭＴＵを５７６オクテットとする。ホストＡ及びホストＢはそれぞれの属するネットワークのＭＴＵが１５００オクテットであるため、ＭＴＵが１５００オクテットのＵＤＰ／ＩＰデータグラムを発行している。ホストＡがホストＢに対してＭＴＵが１５００オクテットのＴＣＰ（ＵＤＰ）／ＩＰデータグラムを送出した場合、ルータＡはネットワークＣにＭＴＵが１５００オクテットのＩＰデータグラムをネットワークＣに送付することはできない。このため、図１２に示すように３つのＩＰデータグラムに分割する。
【０００８】
最初にルータＡから送出されるＩＰパケットはＵＤＰヘッダ付のＩＰ長５７６オクテットである。このＩＰフラグメントパケットには、後続のＩＰフラグメントパケットの存在を示すフラグがあり、ルータＡはこのフラグの値により、後続フラグメントパケットの存在を示すことができる。ＩＰｖ４の場合は、Ｍｏｒｅフラグメントフラグ（ＭＦフラグ）を‘１’に、ＩＰｖ６の場合は、Ｍフラグを‘０’とすることで後続パケットの存在を示すことができる。なお、図１２では、ＩＰｖ４を例にしている。また、ＩＰｖ４パケットのヘッダには、ＩＰデータグラムに与えられるユニークな識別子（ＩＤ：Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を格納するフィールドがある。ネットワークの途中でＩＰデータグラムが断片化、すなわちフラグメントされた場合には、同一のＩＤをもつフラグメントパケットを再構成することで元のＩＰデータグラムを再組立することができる。ＩＰｖ６パケットがフラグメントされる場合は別のフラグメントヘッダがＩＰｖ６ヘッダの後に付与される。フラグメント前のＩＰｖ６パケットのヘッダには、ＩＰｖ４ヘッダのようなＩＤは付与されないが、パケットの断片化を行う装置が元のＩＰｖ６パケットにＩＤを付与し、フラグメントヘッダにＩＤを格納する。ＩＰｖ４と同様に、同一のＩＤをもつフラグメントパケットを再構成することで元のＩＰデータグラムを再組立することができる。
【０００９】
２番目に送出されるＩＰパケットは最初に送出されたＩＰパケットと同じＩＤが付与され、ＩＰ長は同じく最大の５７６オクテットであり、ＭＦフラグが‘１’で、オフセット値に５７６という値が付与されている。このオフセット値はフラグメントされたＩＰパケットの元のＩＰパケットにおけるアドレスを示している。３番目に送出されるＩＰパケットはＭＦフラグを‘０’とすることで、これより後続のＩＰフラグメントパケットがないことを示しており、オフセット値が１１５２、ＩＰ長は３４８オクテットとなっている。
【００１０】
上述したように最初から３番目のＩＰフラグメントパケットは全て同じＩＤを持っているため元は同一のＩＰパケットであることが受信側で判定することが可能である。このようにしてルータＡにより３つに断片化したＩＰパケットはネットワークＣによりルータＢに伝送され、ルータＢはホストＢにフラグメントされたままの状態のＩＰパケットを送る。ホストＢではフラグメントされたＩＰパケットをメモリ上に受信し、Ｍｏｒｅフラグメントフラグとオフセット値により元のＩＰパケットを組立てる。ネットワークの状態によっては図１３に示すように最終フラグメント（ＭＦフラグが０）のパケットが先に到着したり、データグラムの領域が重複している場合がある。これらのことを考慮してホストＢはデータグラムを組み立てなければいけないため、一旦全ての受信フレームをメモリ上に展開し、受信フレーム単位でオフセットアドレスが昇順になるようにソートを実行する。
【００１１】
次に、オフセットが０となっているデータグラムの先頭から、とぎれることなく最終フレームまで組み立てられれば受信完了となる。途中、フラグメントフレームでデータ領域が重複することがあるが、重複領域はどちらかのフレームのデータを無視することで１つのデータグラムを作成する。ＩＰｖ４においては、このように重複領域が生じるフラグメントを許容しているために、フラグメントオフセットとデータ長の値を検証して再組立する必要がある。ＩＰｖ６においても経路中でパケットの複製が生じて、複数回同一のフラグメントパケットを受信する可能性もある。
【００１２】
また、ＩＰの上位層であるＵＤＰ、ＴＣＰ、及びＩＣＭＰではデータグラム全体にわたるチェックサムが求められているので、再組立後にデータグラムを読み込んでインターネットチェックサムの算出を行う。そして、チェックサムによる検証に整合すると全フラグメントパケットによる再組立されたＩＰデータグラムの受信が完了する。
【特許文献１】特開平５−３２７７７１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、上記ＩＰフラグメント受信方法では以下のような問題点があった。すなわち、複数のＩＰフラグメントパケットから構成されるＴＣＰ又はＵＤＰパケットはヘッダ情報としてチェックサムフィールドを有しており、ＴＣＰ（ＵＤＰ）チェックサムの整合性を以て当該パケットの有効性の判定を行っている。このチェックサムを算出するためにはＩＰヘッダの一部から構成されるＩＰ擬似ヘッダと、ＴＣＰ（ＵＤＰ）ヘッダ、そしてペイロードを４オクテット単位での１の補数和、即ちＲＦＣ１０７１で定義されるインターネットチェックサムを算出する必要がある。この算出のために再組立を行ったメモリ上からヘッダ、ペイロード情報を再度読み出して算出していた。また、フラグメントを再組立するために一旦全てのフラグメントパケットを受信して蓄積し、並べ替えを行い、データグラムを再組立するという工程を経るため、ＩＰフラグメントパケットを生じるネットワークにおいては受信性能が著しく劣ってしまう。
【００１４】
本発明の目的は、ＩＰパケットのフラグメント受信による性能低下を低減することにある。
【課題を解決するための手段】
【００１５】
上記目的を達成するために、請求項１記載のデータ受信装置は、メディアアクセスコントロール層より上位のプロトコルを受信するデータ受信装置であって、データリンク層の処理を行うデータリンク層処理手段と、ネットワーク層及びトランスポート層のプロトコル解析を行うプロトコル解析手段と、受信したパケットを保存する受信バッファと、前記受信バッファの前段にパケットのチェックサムを算出するチェックサム算出手段と、前記データリンク層処理手段からの処理情報と前記プロトコル解析手段からの解析情報とから前記断片化されたＩＰパケットの書き込みアドレス情報を生成するアドレス情報生成手段と、断片化されたＩＰパケットの受信済領域を管理する管理手段と、断片化されたＩＰパケットの受信処理において、前記アドレス生成装置が生成したアドレスに基づき前記受信バッファにパケットを書き込む書き込み手段と、を有し、前記チェックサム算出手段は、前記チェックサムの算出を前記管理手段により管理される重複受信済領域を除外して行うことを特徴とする。
【００１６】
請求項７記載のデータ受信方法は、メディアアクセスコントロール層より上位のプロトコルを受信するデータ受信方法であって、データリンク層の処理を行うデータリンク層処理ステップと、ネットワーク層及びトランスポート層のプロトコル解析を行うプロトコル解析ステップと、受信したＩＰパケットを保存する保存ステップと、前記断片化されたＩＰパケットのチェックサムを算出するとチェックサム算出ステップと、前記データリンク層処理ステップの処理情報と前記プロトコル解析ステップの解析情報とから前記断片化されたＩＰパケットの書き込みアドレス情報を生成するアドレス情報生成ステップと、前記断片化されたＩＰパケットの受信済領域を管理する管理ステップと、受信した断片化されたＩＰパケットを前記アドレス情報生成ステップで生成した書き込みアドレス情報に基づいて書き込む書き込みステップを有し、前記チェックサム算出ステップは、前記チェックサムの算出を前記管理ステップにより管理される重複受信済領域を除外して行うことを特徴とする。
【発明の効果】
【００１７】
本発明によれば、ＩＰパケットのフラグメント受信による性能低下を低減することができる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施の形態について図面を参照しながら説明する。
【００１９】
まず、本発明の実施の形態に係るＩＰフラグメントパケット受信装置を含むデータ受信装置について説明する。
【００２０】
図１は、本発明の実施の形態に係るＩＰフラグメントパケット受信装置を含むデータ受信装置１００の構成を概略的に示すブロック図である。
【００２１】
ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｌｅｒ）受信装置１０１は、ＰＨＹ（図示しない）からの信号を受信し、イーサネット(登録商標)パケットを送出する。ＭＡＣ／Ｄｅ−Ｆｒａｍｅｒ１０２は、ＭＡＣ受信装置１０１からイーサネット(登録商標)パケットを受信し、ＭＡＣヘッダのタイプフィールドを解析し、ＭＡＣヘッダを取り除く。ＡＲＰ受信キュー１０３は、ＡＲＰ（アドレス解決プロトコル）の受信時にＡＲＰパケットを蓄積し且つコマンドの解析を行う。ＴＣＰ（ＵＤＰ）／ＩＰ／Ｄｅ−Ｆｒａｍｅｒ１０４は、ＴＣＰ（ＵＤＰ）／ＩＰパケットのフレームを受信し、ヘッダ情報を各プロトコルの解析装置に送出すると共に、パケット情報を送出する。
【００２２】
チェックサム算出装置１１０は、複数のＩＰ識別に対応する。タイマ装置１１１は、各ＩＰ／ＩＤに対応する。デリミタチェッカ１１３は、ＩＰフラグメントパケットを受信した場合、フラグメントされた受信領域を確認し且つフラグメントパケットの受信終了を検出する。タイマ装置１１４は、複数のＩＰ／ＩＤが異なるフラグメントに対応する。アドレス生成装置１１５は、受信したパケットの書き込みアドレスを生成する。受信パケットフィルタ１１６は、受信したパケットバッファ上のパケットを受信バッファに書き込み、判定を行う。ＭＡＣヘッダ受信解析装置１０５は、ＭＡＣ／Ｄｅ−Ｆｒａｍｅｒ１０２から送られたＭＡＣヘッダを解析する。ＩＰｖ４ヘッダ受信解析装置１０６、ＩＰｖ６ヘッダ受信解析装置１０７、ＵＤＰヘッダ受信解析装置１０８、ＴＣＰヘッダ受信解析装置１０９は、夫々、ＩＰｖ４ヘッダ、ＩＰｖ６ヘッダ、ＵＤＰヘッダ、ＴＣＰヘッダを解析する。ＴＣＰ（ＵＤＰ）チェックサム算出装置１１２は、ペイロード部と疑似ヘッダ部のチェックサム判定を行う。受信パケットバッファ１１７は、チェックサム算出装置１１０を通過したパケットを蓄積する。受信バッファ１１８は、フラグメントされた複数のパケットを組み立てたパケットが書き込まれる。
【００２３】
まず、フラグメントされていないパケットの受信の際の動作について説明する。
【００２４】
ＰＨＹ（図示しない）で受信したイーサネット(登録商標)パケットはＭＡＣ受信装置１０１に入力され、ＦＣＳ（Frame Check Sequence）によりフレームが検証される。ＭＡＣ受信装置１０１では算出したＦＣＳとパケットの末尾について送られてきたＦＣＳとを比較し、同じ値であれば後段のＭＡＣ／Ｄｅ−Ｆｒａｍｅｒ１０２に入力され、異なる値であれば受信パケットは壊れたものとして廃棄する。
【００２５】
ＭＡＣ／Ｄｅ−Ｆｒａｍｅｒ１０２は図４に示すイーサネット(登録商標)ヘッダについて解析を行う。イーサネット(登録商標)ヘッダではデータリンク層における解析を行うことができる。
【００２６】
図４は、ＩＥＥＥ８０２．３のイーサネット(登録商標)におけるＭＡＣフレームフォーマットを説明する図である。
【００２７】
図４に示すフォーマットにおいて、ＭＴＵが定義している長さとはＭＡＣヘッダが示すペイロードであるＭＡＣクライアントデータにＰＡＤ（パディング）を加えたものであり、その長さは最小で４６オクテット、最大で１５００オクテットとしている。ペイロードにはＭＡＣヘッダがその先頭に付与され、さらにその先頭にキャリア検出用のプリアンブルとＳＦＤ（フレーム開始検出用のスタートフレームデリミタ）が付き、末端にＦＣＳ（Frame Check Sequence）が４オクテット付与される。ＦＣＳはプリアンブル、ＳＦＤ、ＦＣＳ、及びＥＸＴＥＮＳＩＯＮを除いたソースアドレスからパディングまでを対象に４オクテットの巡回助長検査を施した符号で、算出の対象となった領域における誤り検出を行うことができる。
【００２８】
ＭＡＣヘッダは、宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、Ｌｅｎｇｔｈ／Ｔｙｐｅの３つのフィールドから構成されている。ＭＡＣアドレスは先頭の３オクテットはベンダコードと呼ばれ、製造元を認識するコードで、末尾３オクテットは製品毎に固有の番号として割り振られる。
【００２９】
続いてＬｅｎｇｔｈ／Ｔｙｐｅフィールドは、図４に示したように値によってＬｅｎｇｔｈとして使用される場合と、Ｔｙｐｅとして用いられる場合がある。ＭＡＣ／Ｄｅ−Ｆｒａｍｅｒ１０２は、Ｌｅｎｇｔｈとして用いられるパケットを受信した場合は、後続のデータグラムのプロトコルの解析を停止し、そのまま受信バッファに送る処理を行う。この動作の詳細は後述する。Ｔｙｐｅ＝０ｘ０８０６の場合はＡＲＰ（Address Resolution Protocol）であるため、受信したパケットはＡＲＰ受信キュー１０３に送られる。ＡＲＰ受信キュー１０３に送られたパケットはａｒｐパケット内のコマンドを解析し、“ｒｅｐｌｙ”コマンド或いは“ｒｅｓｐｏｎｓｅ”コマンドを受信した旨を通知する。
【００３０】
一方、ＭＡＣ／Ｄｅ−Ｆｒａｍｅｒ１０２に送られたパケットが０ｘ０８００＝ＩＰｖ４或いは０ｘ８６ｄｄ＝ＩＰｖ６のＴｙｐｅフィールドであった場合はイーサネット(登録商標)ヘッダの上位層がＩＰｖ４ヘッダ、ＩＰｖ６ヘッダであることを示している。この場合、ＭＡＣ／Ｄｅ−Ｆｒａｍｅｒ１０２は、受信したパケットのイーサネット(登録商標)ヘッダを取り除いた上で後段のＴＣＰ（ＵＤＰ）／ＩＰ／Ｄｅ−Ｆｒａｍｅｒ１０４に送出し、取り除いたイーサネット(登録商標)ヘッダはＭＡＣヘッダ受信解析装置１０５に送出する。
【００３１】
ＴＣＰ（ＵＤＰ）／ＩＰ／Ｄｅ−Ｆｒａｍｅｒ１０４ではＩＰヘッダ以降の各層のヘッダを各ヘッダ解析器に入力し、ＩＰヘッダ以降のパケットを後段のチェックサム算出装置１１０に送出する。まず、ＴＣＰ（ＵＤＰ）／ＩＰ／Ｄｅ−Ｆｒａｍｅｒ１０４はＭＡＣヘッダ受信解析装置１０５が解析した結果に基づき、ＩＰｖ４パケット、ＩＰｖ６パケット若しくはそれ以外のパケットであるかを判定する。ＩＰパケットでない場合はそれ以上の解析は行わずに後段に送出される。
【００３２】
ＴＣＰ（ＵＤＰ）／ＩＰ／Ｄｅ−Ｆｒａｍｅｒ１０４は受信したパケットがＩＰｖ４パケットの場合は、ＩＰｖ４ヘッダ受信解析装置１０６にヘッダ部分を送出する。
【００３３】
図５は、ＭＡＣ層の上位層に位置するＩＰ層におけるＩＰｖ４ヘッダフォーマットを説明する図である。
【００３４】
ＩＰｖ４ヘッダは最小で２０オクテットで構成され、必要に応じてオプションが付加される。オプションが３２オクテット単位にならなければパディングが加えられて３２オクテット単位に揃えられる。ＩＰヘッダの先頭にはバージョンを示す４ビットのフィールドがあり、ＩＰｖ４の場合は“０１００＝４”が示される。続いて４ビットのヘッダ長が４オクテット単位で示される。一般的にＩＰｖ４ではオプションが用いられることは少ないためここでは最小のヘッダ長である２０オクテットが示される。４オクテット単位で表現するため“０１０１”が与えられる。オプションが付加された場合ＩＰｖ４の最大ヘッダ長はヘッダ長フィールドが“１１１１”になった場合の６０オクテットとなる。
【００３５】
続いて、Type Of ServiceフィールドにはＩＥＴＦのＲＦＣ１３４０やＲＦＣ１３４９等で示されるようにそのパケットがネットワーク上でどのようなサービスを受けるべきかが示される。次に、全データ長には自身のＩＰヘッダを含んだＩＰパケットの全長が示される。当該全データ長は１６ビットで表現されていることからＩＰデータグラムの最大長は６５５３５オクテットということになる。IdentificationはＩＰデータグラムに与えられるユニークなＩＤである。ネットワークの途中でＩＰデータグラムが断片化、すなわちフラグメントされた場合に同一のＩＤをもつフラグメントパケットを再構成することで元のＩＰデータグラムを再組立することができる。フラグ、及びフラグメントオフセットは経路上においてＩＰをフラグメントする場合に用いるフィールドである。Ｔｉｍｅ Ｔｏ Ｌｉｖｅフィールドはデータが通過することができるルータ数の限界を示す。プロトコルフィールドはＩＰパケットの上層に位置するプロトコル種別を示している。また、ヘッダチェックサムにはＩＰヘッダ部分のみのインターネットチェックサムが与えられる。そして、送出元ＩＰアドレス、宛先ＩＰアドレスが各々示され、ＩＰヘッダが構成される。
【００３６】
また、ＴＣＰ（ＵＤＰ）／ＩＰ／Ｄｅ−Ｆｒａｍｅｒ１０４は受信したパケットがＩＰｖ６パケットの場合はＩＰＶ６ヘッダが３２オクテットであることが予め決められているので３２オクテットのみをＩＰｖ６ヘッダ受信解析装置１０７に送出する。
【００３７】
図６のＩＰｖ６ヘッダフォーマットを示す。図６（Ａ）は、ＩＰｖ６ヘッダフォーマットを説明する図であり、図６（Ｂ）は、フラグメントヘッダフォーマットを説明する図である。
【００３８】
図６（Ａ）に示すように、ＩＰｖ６のヘッダフォーマットは上述したＩＰｖ４のヘッダフォーマットと比較するといくらか単純化されている。先頭に４ビットのバージョン番号があり、バージョンは‘６’なので“０１１０＝６”が与えられる。トラフィッククラスはＱｏＳ（Quality of Service）のための優先度の識別に用いられる。フローラベルはルータ制御を要求するラベル付けのためのフィールドである。
【００３９】
ペイロード長は、ＩＰｖ４と異なりペイロード長がＩＰヘッダを含まずＩＰｖ６の拡張ヘッダ長さを含む。Next Headerは、ＩＰｖ６ヘッダに続くヘッダのタイプを示している。ＩＰｖ６における拡張ヘッダの他、ＵＤＰやＴＣＰが続く場合においても、このNext Headerで識別することができる。Hop Limitは、ＩＰｖ４におけるＴｉｍｅ Ｔｏ Ｌｉｖｅに相当し、ルータ越えの制限を示す。但し、Hop Limitの値としての２５５は特別な値でルータ越えが禁止されていることを示す。そして、送信元のアドレスと宛先のアドレスとが各々１２８ビットで与えられる。
【００４０】
フラグメントされる場合は別のフラグメントヘッダがＩＰｖ６ヘッダの後に付与される。ＩＰｖ４の場合と同様にフラグメントオフセットは断片化データのオフセット値を示しており、Ｍフラグはフラグメントされた最後のデータグラムであるかを示している。Ｍフラグが‘０’であれば後続のフラグメントデータがあることを示しており、‘１’であれば最終のフラグメントデータグラムであることを示している。そして、フラグメントヘッダの最後にＩＤ（Identification）が付与される。使用方法はＩＰｖ４の場合と同一であるが、元のＩＰｖ６ヘッダにＩＤが付与されていないので断片化を行う送信元、若しくはルータが使用されていないＩＤを選択して決定する必要がある。
【００４１】
ＩＰパケットのペイロードの構成はＩＰｖ４であればプロトコルフィールド、ＩＰｖ６の場合はＮｅｘｔ ＨｅａｄｅｒフィールドにＴＣＰ若しくはＵＤＰプロトコルであることが記されている。ＴＣＰ（ＵＤＰ）／ＩＰ／Ｄｅ−Ｆｒａｍｅｒ１０４は、ＴＣＰが続く場合はＴＣＰヘッダ（図７（Ｂ））のヘッダデータ長フィールドからヘッダ長を読み出し、ＴＣＰヘッダをＴＣＰヘッダ受信解析装置１０９に入力する。ＵＤＰの場合はＵＤＰヘッダが８オクテットに限定されているので（図７（Ａ））ＩＰヘッダに続く８オクテットをＵＤＰヘッダ受信解析装置１０８に入力する。
【００４２】
一方、ＩＰヘッダ以降のペイロードはチェックサム算出装置１１０でペイロードチェックサムの算出を行うとともに受信パケットバッファ１１７に蓄積される。ＩＰヘッダの部分はペイロードチェックサムから除外されるため、ＴＣＰ、若しくはＵＤＰヘッダ以降のペイロードを含む全パケットに渡り４オクテット毎のチェックサムが算出される。ＩＰヘッダ部のチェックサムはＩＰｖ４で用いるヘッダチェックサムの他、ＴＣＰ（ＵＤＰ）等のトランスポート層のチェックサムの算出に必要な擬似ヘッダを作成してチェックサムを算出する必要がある。
【００４３】
図８（Ａ）は、ＩＰｖ４における疑似ヘッダのフォーマットを説明する図であり、図８（Ｂ）は、ＩＰｖ６における疑似ヘッダのフォーマットを説明する図である。
【００４４】
ＩＰｖ４、ＩＰｖ６の疑似ヘッダはネットワーク層であるＩＰｖ４ヘッダ、ＩＰｖ６ヘッダの情報を元に作成される。そのため、各受信解析装置にヘッダが入力される際にこれらの疑似ヘッダのチェックサムを算出し、トランスポート層のチェックサムであるＴＣＰ（ＵＤＰ）チェックサム算出装置１１２へ入力する。ＴＣＰ（ＵＤＰ）チェックサム算出装置１１２においてペイロード部と疑似ヘッダ部のチェックサムがＯＫ／ＮＧの判定を受信パケットフィルタ１１６に入力する。受信パケットフィルタ１１６には他にもＩＰｖ４のヘッダチェックサム等の情報が集められ、受信バッファに送出するパケットかどうかの判断を行う。一方、ＩＰｖ４ヘッダの全データ長、又はＩＰｖ６ヘッダのペイロード長フィールドより受信パケット全体の長さが算出され、アドレス生成装置１１５に入力される。また、アドレス生成装置１１５には事前に受信バッファエリア情報としてパケットが受信されるバッファのアドレス情報が入力されている。アドレス生成装置１１５は、この受信パケット長とアドレス情報を元に受信バッファ１１８に書き込みアドレスを出力する。それに同期して受信パケットバッファから受信パケット情報を受信バッファに書き込むことができる。以上のように動作することでネットワーク層とトランスポート層とからなるパケットの受信が行われる。
【００４５】
次に、ＩＰフラグメントされた複数のパケット受信の際の動作について説明する。
【００４６】
上記のようにＩＰフラグメントされていた場合はＩＰヘッダのフィールドの内、ＩＰｖ４であれば“フラグ（Ｆｌａｇｓ）”フィールド、ＩＰｖ６の場合は“Next Header”がフラグメントを示していた場合ＩＰフラグメントであることが判断される。ＩＰフラグメントパケットであるときは、ＩＰｖ４ヘッダ受信解析装置１０６或いはＩＰｖ６ヘッダ受信解析装置１０７においてフラグメント情報としてオフセットアドレスとデータ長情報がデリミタチェッカ１１３にＩＰヘッダの識別情報と共に入力される。オフセットアドレスはＩＰｖ４のフラグメントオフセットフィールドから、ＩＰｖ６であればフラグメントヘッダのフラグメントオフセットフィールドから参照される。データ長情報はＩＰｖ４であれば全データ長、ＩＰｖ６であればペイロード長から参照される。このようにして入力されたデリミタ情報はフラグメントパケットの受信領域が示されている。
【００４７】
図２は、図１におけるデリミタチェッカ１１３の構成を概略的に示すブロック図である。
【００４８】
図２において、デリミタチェッカ１１３は、シフトレジスタ２０１と、デリミタ入力レジスタ２０２と、比較器２０３と、重複受信領域出力レジスタ２０４と、最終受信ポインタ保存メモリ２０５とを備える。また、デリミタチェッカ１１３は、受信開始ポインタレジスタ２０６と、受信終了ポインタレジスタ２０７と、比較器２０８と、フラグメント受信完了判断装置２０９とを備える。
【００４９】
次に、上述したデリミタチェッカ１１３の詳細な動作について説明する。
【００５０】
まず、ＩＰヘッダにおける全データ長（又はＩＰｖ６におけるペイロード長＋ＩＰヘッダ長）とフラグメントオフセット情報に基づいて、フラグメント全体におけるフラグメントパケットの位置情報を算出する。デリミタの下位（図２におけるＰｏｉｎｔｅｒ−ｉ）はフラグメントオフセットフィールドを参照することにより与えられる。他方のデリミタの上位（図２におけるＰｏｉｎｔｅｒ−ｊ）はフラグメントオフセット＋ペイロード長を算出することにより与えられる。このようにして第１のデリミタがデリミタ入力レジスタ２０２に入力されると、まず、シフトレジスタ２０１にデリミタが入力される。入力されたデリミタは比較器２０８で比較されるが、フラグメント受信が完了していないのでフラグメント受信完了判断装置２０９からはフラグメント受信完了通知は出力されない。
【００５１】
続いて、第２のフラグメントパケットを受信し、次いで第２のデリミタがデリミタ入力レジスタ２０２に入力されると、同じＩＰＩＤであることを検知した上で先に入力した第１のデリミタとの比較が比較器２０３において実行される。この比較において、受信領域の重複が検出された場合（図３（Ｅ）〜（Ｉ））は重複受信領域出力レジスタ２０４より重複領域が出力される。また、受信領域の書き込み結合が行われ、受信開始ポインタレジスタ２０６及び受信終了ポインタレジスタ２０７の比較が行われフラグメント受信完了の通知が行われる。
【００５２】
一方、入力したデリミタのうち、Ｍｏｒｅフラグメントフラグが立っておらず、フラグメントオフセットに有意の値が入っているフラグメントパケットから算出したＰｏｉｎｔｅｒ−ｊの値をＥｎｄ−Ｐｏｉｎｔｅｒとして最終受信ポインタ保存メモリ２０５に入力する。以降、複数のフラグメントパケットを受信し、シフトレジスタ２０１の値が図３（Ｊ）に示すような最終状態になった場合にフラグメント受信完了判断装置２０９よりフラグメント受信完了通知が出力される。また、この際に受信終了ポインタレジスタ２０７にある値がフラグメント再組立後のＩＰパケット長となるため、このレジスタ値も同時に出力する。
【００５３】
デリミタチェッカ１１３がフラグメント受信の際に上述のように動作することにより重複受信領域があるフラグメントパケットを受信するとチェックサム算出装置１１０に重複領域を通知する。そのため、フラグメントを再組立した状態におけるペイロード部のチェックサムの算出が可能となる。チェックサム算出装置１１０は複数備えられ、同時にいくつものＩＰフラグメントの組立が可能となっている。もし、ネットワーク経路上で一部のフラグメントパケットが大きく遅延した場合、タイマ装置１１１、１１４により時間を監視し、一定以上の時間遅延に関してはパケットを喪失したものとして同じＩＰ識別を持つパケットを全て放棄する。これは受信バッファ１１８、チェックサム算出器、デリミタチェッカ等のリソースを長期間使用させないようにするためである。
【００５４】
フラグメント組立用のタイマを６０秒に設定したとすると、最後のＩＰフラグメントパケットを受信してから６０秒を経過するとそれまで受信したフラグメントパケットを全て廃棄する。チェックサム算出装置１１０を通過したパケットは受信パケットバッファ１１７に蓄積され、ＩＰヘッダチェックサムの可否判断を行い整合性があれば受信バッファ１１８へ蓄積される。このときのアドレス情報は予め設定された受信バッファ領域情報をアドレス生成装置１１５に入力し、さらにデリミタチェッカ１１３に与えられたデリミタ情報を元に書き込みアドレスを決定する。このようにして決められたアドレスにＩＰフラグメントパケットを書き込むことにより受信バッファ１１８にはペイロードが直接組み立てられる。
【００５５】
このようにして全てのフラグメントの受信が完了すると、デリミタチェッカ１１３によりフラグメント受信完了通知が出力され、受信バッファ１１８にはＴＣＰヘッダ以降の全てのペイロード、そして先頭フラグメントにおけるＩＰヘッダが書き込まれている。このときのＩＰヘッダのフィールド内の全データ長のみが再組立後のＩＰパケットに対するヘッダ値として誤っている。従って、デリミタチェッカ１１３より出力されたペイロード長からＩＰｖ４であれば全データ長を算出し、ＩＰｖ６であればそのままペイロード長として全データ長として書き換える。このようにして再組立されたパケットの内、ＴＣＰ（ＵＤＰ）ヘッダにおけるチェックサムの検証を行うためにＩＰヘッダとＴＣＰ（ＵＤＰ）ヘッダのみを再度ヘッダ解析装置に送出する。この際に再送出されるのはＩＰヘッダ部のみであるのでパケット全体と比較するとごく少量であることを類推することは難しくない。再送出されたヘッダ情報はＩＰヘッダ解析装置においては疑似ヘッダ部のチェックサムの算出を行い、ＴＣＰ（ＵＤＰ）チェックサム装置１１２に入力される。それと同時に同じＩＰ識別から算出されたチェックサムをチェックサム算出装置１１０からＴＣＰ（ＵＤＰ）チェックサム装置１１２に入力し、ヘッダ部とペイロード部の最終的なチェックサムの検査が終了する。この結果は受信パケットフィルタ１１６を通して受信されたＩＰフラグメントパケットの整合性の結果として出力される。
【００５６】
上述したように、本実施の形態によれば、フラグメントされたＩＰパケットの受信において、ＩＰフラグメントパケットの受信と同時に受信領域を確認しながらペイロード部のチェックサム及びＩＰパケットの再組立を行う。そして、全てのフラグメントパケット受信完了を検出するとＩＰヘッダによる疑似ヘッダを作成し、疑似ヘッダのチェックサムを算出し、先のペイロード部のチェックサムと疑似ヘッダのチェックサムからトランスポート層のチェックサムによる検証を行う。このようにすることで、フラグメントパケット受信から再組立パケットの検証まで完了する時間を短縮でき、高速に処理することができる。
【００５７】
また、本発明の目的は、以下の処理を実行することによって達成される。即ち、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。
【００５８】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００５９】
また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等である。または、プログラムコードをネットワークを介してダウンロードしてもよい。
【００６０】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれる。
【００６１】
更に、前述した実施の形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行う場合である。
【図面の簡単な説明】
【００６２】
【図１】本発明の実施の形態に係るＩＰフラグメントパケット受信装置を含むデータ受信装置の構成を概略的に示すブロック図である。
【図２】図１におけるデリミタチェッカの構成を概略的に示すブロック図である。
【図３】図２のデリミタチェッカの動作を説明する図である。
【図４】ＩＥＥＥ８０２．３のイーサネット(登録商標)におけるＭＡＣフレームフォーマットを説明する図である。
【図５】ＭＡＣ層の上位層に位置するＩＰ層におけるＩＰｖ４ヘッダフォーマットを説明する図である。
【図６】（Ａ）は、ＩＰｖ６ヘッダフォーマットを説明する図であり、（Ｂ）は、フラグメントヘッダフォーマットを説明する図である。
【図７】（Ａ）は、ＵＤＰヘッダフォーマットを説明する図であり、（Ｂ）は、ＴＣＰヘッダフォーマットを説明する図である。
【図８】（Ａ）は、ＩＰｖ４における疑似ヘッダのフォーマットを説明する図であり、（Ｂ）は、ＩＰｖ６における疑似ヘッダのフォーマットを説明する図である。
【図９】ＩＰフラグメントが発生するネットワークの構成の一例を概略的に示すブロック図である。
【図１０】メモリ上に展開された受信フレームを説明する図である。
【図１１】メモリ上に展開され、ソートが実行された受信フレームを説明する図である。
【図１２】ＩＰフラグメントを説明する図である。
【図１３】ＩＰフラグメントを説明する図である。
【符号の説明】
【００６３】
１００  データ受信装置
１０１  ＭＡＣ受信装置
１０２  ＭＡＣ／Ｄｅ−Ｆｒａｍｅｒ
１０３  ＡＲＰ受信キュー
１０４  ＴＣＰ（ＵＤＰ）／ＩＰ／Ｄｅ−Ｆｒａｍｅｒ
１０５  ＭＡＣヘッダ受信解析装置
１０６  ＩＰｖ４ヘッダ受信解析装置
１０７  ＩＰｖ６ヘッダ受信解析装置
１０８  ＵＤＰヘッダ受信解析装置
１０９  ＴＣＰヘッダ受信解析装置
１１０  チェックサム算出装置
１１１，１１４  タイマ装置
１１２  ＴＣＰ（ＵＤＰ）チェックサム算出装置
１１３  デリミタチェッカ
１１５  アドレス生成装置
１１６  受信パケットフィルタ
１１７  受信パケットバッファ
１１８  受信バッファ
２０１  シフトレジスタ
２０２  デリミタ入力レジスタ
２０３，２０８  比較器
２０４  重複受信領域出力レジスタ
２０５  最終受信ポインタ保存メモリ
２０６  受信開始ポインタレジスタ
２０７  受信終了ポインタレジスタ
２０９  フラグメント受信完了判断装置
【図１】
2008092082.tif 000003
【図２】
2008092082.tif 000004
【図３】
2008092082.tif 000005
【図４】
2008092082.tif 000006
【図５】
2008092082.tif 000007
【図６】
2008092082.tif 000008
【図７】
2008092082.tif 000009
【図８】
2008092082.tif 000010
【図９】
2008092082.tif 000011
【図１０】
2008092082.tif 000012
【図１１】
2008092082.tif 000013
【図１２】
2008092082.tif 000014
【図１３】
2008092082.tif 000015