JP5481485B2 - 通信装置とそれを用いた受信処理方法及び送信処理方法 - Google Patents

Description

本発明は、通信装置に関する。

インターネット等で広く用いられるTCP/IP(Transmission Control Protocol/ Internet Protocol)などのプロトコル処理は、従来、主にCPU(Central Processing Unit)上で動作するソフトウェアにより実現されている。しかしながら、近年のネットワークの高速化に伴い、CPUのTCP/IP処理の負荷が増大している。その対応策として、TCP/IP処理を行う専用のハードウェアを設けることにより、高速な通信を実現する通信装置が提案されている（特許文献１参照。）。

特許文献１に開示される通信装置では、まずデータが高レートかどうかを判別する。次に、高レートの場合には、専用ハードウェアにより各種ヘッダを除去し、アプリケーションデータをメモリ領域に転送する。更に、TCPの場合は、ヘッダのみをネットワーク通信ドライバに引き渡して、ソフトウェアによるTCP/IPスタック処理を行っている。

しかしながら、特許文献１の技術では、高レートと判断されなかったフレームは、データリンク層、ネットワーク層の処理もすべてソフトウェアにより処理されることになる。従って、例えば、TCPのセッション確立のためのセグメントを処理する場合、処理速度が低下するという問題点がある。また、専用ハードウェアに備えられるデータリンク層やネットワーク層の処理部の機能を、ソフトウェアでも二重に備えなければならない。その結果、ソフトウェアのサイズが増大するという問題点がある。

特開２００６−３１１４５号公報

本発明は、上記問題点を解決するためになされたもので、通信のスループットを向上できる通信装置を提供することを目的とする。

本発明の一態様の通信装置は、受信データのフレームに対しハードウェアにより、前記フレームの内容に応じて異なるプロトコル処理を行うハードウェアプロトコル処理部と、前記ハードウェアプロトコル処理部とは異なるハードウェアで実現され、前記受信データのフレームに対しソフトウェアによるプロトコル処理を行うソフトウェアプロトコル処理部と、前記受信データのフレーム毎に、前記ハードウェアプロトコル処理部により処理が完了したプロトコル処理を示す情報又は前記ソフトウェアプロトコル処理部で処理すべきプロトコル処理を示す情報と、前記ハードウェアプロトコル処理部によるプロトコル処理によって得られた値を含むプロトコル処理情報を生成するハードウェアプロトコル処理情報生成部と、前記プロトコル処理情報を用いて、前記ハードウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ソフトウェアプロトコル処理部に行わせるソフトウェアプロトコル処理再開部とを具備することを特徴とする。

本発明によれば、通信のスループットを向上させ、ソフトウェアのサイズを削減できる通信装置を提供することができる。

本発明の実施例１に係る通信装置を示すブロック図。 本発明の実施例１に係るEthernet(R)フレームの構成を示す図。 本発明の実施例１に係るIPヘッダの構成を示す図。 本発明の実施例１に係るUDPヘッダの構成を示す図。 本発明の実施例１に係る通信装置の受信処理を示すフロ-チャート。 本発明の実施例１に係る通信装置の送信処理を示すフローチャート。 本発明の実施例１に係るUDP受信を高速化した通信装置を示すブロック図。 本発明の実施例１に係るUDP送信を高速化した通信装置を示すブロック図。 本発明の実施例２に係る通信装置を示すブロック図。 本発明の実施例２に係るTCPヘッダの構成を示す図。 本発明の実施例２に係るTCPのセッション状態を示す図。 本発明の実施例２に係るUDP受信処理を示すフローチャート。 本発明の実施例２に係るTCP受信処理を示すフローチャート。 本発明の実施例２に係るTCP送信処理を示すフローチャート。

以下、本発明の実施例について図面を参照しながら説明する。

まず、本発明の実施例１に係る通信装置について、図面を参照して説明する。図１は、通信装置を示すブロック図である。図２は、Ethernet(R)フレームの構成を示す図である。図３は、IPヘッダの構成を示す図である。図４は、UDPヘッダの構成を示す図である。本実施例では、受信側にハードウェアプロトコル処理情報生成部とソフトウェアプロトコル情報再開部を設けている。また、送信側にソフトウェアプロトコル処理情報生成部とハードウェアプロトコル処理再開部を設けている。

図１に示す通信装置８０は、例えば映像送受信装置である。通信装置８０は、Ethernet(R)によってネットワーク７０に接続されている。通信装置８０は、映像情報をディスク装置(Hard Disk Drive等)から読み出してUDP(User Datagram Protocol)によってネットワーク７０に接続されているクライアント装置に送信する機能を備える。また、クライアント装置からUDPで受信した映像情報をディスク装置に保存する機能を備える。通信装置８０は、FPGA(Field Programmable Gate Array)やASIC(Application Specific Integrated Circuit)などによって実現されるハードウェア処理部１と、CPU上で動作するソフトウェアにより処理が行われるソフトウェア処理部２により構成される。つまり、ハードウェア処理部１とソフトウェア処理部２は、異なる処理機能で構成される。

ハードウェア処理部１には、ネットワークコントローラ１１、ハードウェアプロトコル処理部１２、ハードウェアプロトコル処理情報生成部１３、及びハードウェアプロトコル処理再開部１４が設けられる。

ネットワークコントローラ１１は、ネットワーク７０からEthernet(R)フレームを受信すると、Ethernet(R)物理層の処理、及びEthernet(R)のデータリンク層の一部の処理を行う。具体的には、Ethernet(R)規格によって規定された信号を復調し、図２に示すEthernet(R)フレームを取り出す。Ethernet(R)フレームは、終点MAC(Media Access Control)アドレス１１１、始点MAC(Media Access Control)アドレス１１２、タイプ１１３、データ１１４、及びＦＣＳ(Frame Check Sequence)１１５から構成される。次に、ネットワークコントローラ１１は、Ethernet(R)フレームに破損がないかを検証するためFCS(Frame Check Sequence)の検算処理を行う。なお、終点MACアドレス１１１は宛先アドレスとも呼称され、始点MACアドレス１１２は送信元アドレスとも呼称される。

Ethernet(R)フレームの場合、例えば、終点MACアドレス１１１が６オクテット(48bit)、始点MACアドレス１１２が６オクテット(48bit)、タイプ１１３が２オクテット(16bit)、データ１１４が４６〜１５００オクテット、ＦＣＳ(Frame Check Sequence)１１５が４オクテット(32bit)で構成されている。タイプ１１３には、IP(Internet Protocol)、ARP(Address Resolution Protocol)、RARP(Reverse Address Resolution Protocol)がある。

ネットワークコントローラ１１は、送信処理のとき、ハードウェアプロトコル処理部１２で処理された送信情報にＦＣＳを付加し、フレーム変調を施してネットワーク７０に送信する。

ハードウェアプロトコル処理部１２には、Ethernet(R)処理部１５、IPv4(Internet Protocol version 4)処理部１６、及びUDP処理部１７が設けられる。ハードウェアプロトコル処理部１２は、受信及び送信のときにハードウェアによるプロトコル処理を実行する。

Ethernet(R)処理部１５は、Ethernet(R)のデータリンク層の一部の処理を行う。IPv4処理部１６は、図３に示すIPv4ヘッダの処理を行う。IPv4ヘッダ（IPヘッダ）は、バージョン２１１、ヘッダ長２１２、サービスタイプ２１３、IPパケット長２１４、識別子２１５、コントロールフラグ２１６、フラグメントオフセット２１７、生存時間２１８、プロトコル番号２１９、ヘッダチャックサム２２０、始点IPアドレス２２１、及び終点IPアドレス２２２から構成される。

例えば、バージョン２１１は４bit、ヘッダ長２１２は４bit、サービスタイプ２１３は８bit、IPパケット長２１４は１６bit、識別子２１５は１６bit、コントロールフラグ２１６は３bit、フラグメントオフセット２１７は１３bit、生存時間２１８は８bit、プロトコル番号２１９は８bit、ヘッダチャックサム２２０は１６bit、始点IPアドレス２２１は３２bit、及び終点IPアドレス２２２は３２bitで構成されている。なお、３２bitの倍数オプションが任意に設けられる。プロトコル番号２１９には、ICMP(Internet Control Message Protocol)、TCP(Transmission Control Protocol)、UDP(User Datagram Protocol)、DCCP(Datagram Congestion Control Protocol)がある。

UDP処理部１７は、図４に示すUDPヘッダの処理を行う。UDPヘッダは、始点ポート番号３１１、終点ポート番号３１２、UDPパケット長３１３、及びUDPチェックサム３１４から構成される。例えば、始点ポート番号３１１は１６bit、終点ポート番号３１２は１６bit、UDPパケット長３１３は１６bit、及びUDPチェックサム３１４は１６bitで構成されている。

ハードウェアプロトコル処理情報生成部１３は、受信のとき、ハードウェアプロトコル処理部１２の処理結果からプロトコル処理情報を生成する。そのプロトコル処理情報は、ソフトウェア処理部２に出力される。ハードウェアプロトコル処理再開部１４は、送信のとき、ソフトウェアプロトコル処理情報生成部２４で生成されたプロトコル処理情報を受信する。ハードウェアプロトコル処理再開部１４からプロトコル処理情報を受信したハードウェアプロトコル処理部１２は、ハードウェアによるプロトコル処理を行う。

ソフトウェア処理部２には、アプリケーション２１、ソフトウェアプロトコル処理部２２、ソフトウェアプロトコル処理再開部２３、及びソフトウェアプロトコル処理情報生成部２４が設けられる。

ソフトウェアプロトコル処理部２２は、受信及び送信のときにソフトウェアによるプロトコル処理を実行する。ソフトウェアプロトコル処理部２２には、ARP(Address Resolution Protocol)処理部２５、IPv6(Internet Protocol version 6)処理部２６、ICMPv4(Internet Control Message Protocol version 4)処理部２７、及びDCCP(Datagram Congestion Control Protocol)処理部２８が設けられる。ARP処理部２５は、ARP処理を行う。IPv6処理部２６は、IPv6処理を行う。DCCP処理部２８は、DCCP処理を行う。

ソフトウェアプロトコル処理再開部２３は、受信のとき、ハードウェアプロトコル処理情報生成部１３で生成されたプロトコル処理情報を受けて、ソフトウェアプロトコル処理部２２を制御する。ソフトウェアプロトコル処理情報生成部２４は、送信のとき、ソフトウェアプロトコル処理部２２の処理結果からプロトコル処理情報を生成する。そのプロトコル処理情報は、ハードウェアプロトコル処理再開部１４へ出力される。ハードウェアプロトコル処理再開部１４は、受信したプロトコル処理情報によりハードウェアプロトコル処理部１２を制御する。

アプリケーション２１は、送信時に映像情報などの送信データを、図示しないディスク装置から読み出す制御をする。また、アプリケーション２１は、受信時に映像情報などの受信データをディスク装置に保存する機能を備えている。

次に、実施例１に係る通信装置の動作について、図５及び図６を参照して説明する。図５は、通信装置の受信処理手順を示すフローチャートである。図６は、通信装置の送信処理手順を示すフローチャートである。

通信装置８０の受信処理について、図５を参照して説明する。まず、ネットワーク７０から伝送されたデータがネットワークコントローラ１１に入力される。ネットワークコントローラ１１は、Ethernet(R)の物理層の処理、及びEthernet(R)のデータリンク層の一部の処理を行う。具体的には、Ethernet(R)規格によって規定された受信信号を復調し、Ethernet(R)フレーム（図２参照）を取り出す。そして、フレームに破損がないかを検証するためＦＣＳ１１５を用いて検算処理を行う。Ethernet(R)フレームの破損を検出した場合には、当該フレームは破棄される（ステップＳ１１）。

次に、Ethernet(R)フレームに破損がないことが検証されたフレームは、ハードウェアプロトコル処理部１２に出力される。ハードウェアプロトコル処理部１２は、プロトコル処理を行う（ステップＳ１２）。具体的には、Ethernet(R)処理部１５は、受信したEthernet(R)フレームの終点MACアドレス１１１から、自ホスト宛のフレームであるか、マルチキャストフレームであるか、ブロードキャストフレームであるか、及び他ホスト宛のフレームであるかの判断を行い、宛先種別を識別する。また、必要に応じて始点MACアドレス１１２、或いは終点MACアドレス１１１によりフィルタリングを行う。Ethernet(R)フレーム中のタイプ１１３には、上位層のプロトコル種別（図２のタイプ表を参照）が記録されている。このタイプ１１３の値がIP(=0800)であれば、ハードウェアプロトコル処理部１２での処理を継続し、IPv4処理部１６での受信処理が開始される。

IPv4処理部１６は、IPv4ヘッダ（図３参照）の処理を行う。Ethernet(R)のタイプ１１３がIPであってもIPv6である場合もあるため、バージョン２１１の値が「６」であればハードウェアプロトコル処理部１２での処理は終了する。そして、Ethernet(R)処理部１５で得られた結果とともに、ネットワーク層のプロトコルがIPv6であることをハードウェアプロトコル処理情報生成部１３に通知される。バージョン２１１の値が「４」であれば、IPv4処理部１６は、ヘッダ長２１２及びIPパケット長２１４の検証や、ヘッダチェックサム２２０を検証する。また、IPパケットがフラグメントしている場合には、デフラグメント処理が行われる。

IPヘッダのプロトコル番号２１９には、上位層のプロトコル種別が記述（図３のプロトコル番号表を参照）されている。このプロトコル番号２１９の値がDCCP(=33)やICMPv4(=1)などを示すものであれば、ハードウェアプロトコル処理部１２での処理は終了する。一方、プロトコル番号２１９がUDP(=17)であれば、ハードウェアプロトコル処理部１２での処理が継続され、UDP処理部１７での受信処理が開始される。

UDP処理部１７は、UDPヘッダ（図４参照）の処理を行う。UDP処理部１７は、UDPパケット長３１３の検証や、ペイロードのUDPチェックサム３１４を計算し、データの破損がないかの検証を行う。データの破損を検出すると、ペイロードが破棄され、処理が終了する。

続いて、ハードウェアプロトコル処理部１２は、ハードウェア処理による全てのプロトコル処理が完了しているかの判定を行う（ステップＳ１３）。

全てのプロトコル処理が完了していないと判定し、且つEthernet(R)フレーム中のタイプ１１３がARP(=0806)であれば、ハードウェアプロトコル処理部１２は、ハードウェアプロトコル処理情報生成部１３に宛先種別と、上位層のプロトコル種別と、データ１１４をプロトコル処理結果として通知する。また、IPヘッダの値がDCCP(=33)やICMPv4(=1)であれば、ハードウェアプロトコル処理部１２は、ハードウェアプロトコル処理情報生成部１３に始点IPアドレス２２１及び終点IPアドレス２２２、IPパケット長２１４、ペイロード等を通知する。ハードウェアプロトコル処理情報生成部１３は、それらの通知された情報からプロトコル情報を生成する（ステップＳ１４）。

次に、ハードウェアプロトコル処理情報生成部１３は、生成したプロトコル情報をソフトウェアプロトコル処理再開部２３に伝達する。ソフトウェアプロトコル処理再開部２３は、ソフトウェアでのプロトコル処理（ARP、DCCP、ICMPv4）の開始部を決定する（ステップＳ１５）。

続いて、ソフトウェアでのプロトコル処理の開始が指示されたソフトウェアプロトコル処理部２２は、ハードウェアプロトコル処理部１２で処理されなかったプロトコル処理を実行する（ステップＳ１６）。例えば、受信したフレームがARPであれば、ハードウェアプロトコル処理部１２でEthernet(R)処理が行われているので、ARPヘッダの解析を行い、必要ならARPキャッシュの更新やARP応答の送信処理を行う。受信したフレームがDCCPおよびICMPv4の場合は、Ethernet(R)処理およびIPv4処理がハードウェアプロトコル処理部１２で行われているため、DCCPのプロトコル処理やICMPv4の処理を行う。

そして、ソフトウェアプロトコル処理部２２は、全てのプロトコル処理が完了していると判定した場合（或いは、ソフトウェアによるプロトコル処理後）、処理する映像情報などのデータがあるかを判定する。処理するデータがないと判定した場合は、受信処理は終了する（ステップＳ１７）。一方、処理するデータがあると判定した場合は、アプリケーション２１は受信データをディスク装置に格納する処理を実行する（ステップＳ１８）。受信したEthernet(R)フレームがハードウェアプロトコル処理部１２全てのプロトコル処理が完了する場合、アプリケーション２１は映像情報などのデータをディスク装置に保存する処理が行われる。

このように、受信したEthernet(R)フレームにハードウェアプロトコル処理部１２では処理できないプロトコル（ARP、DCCP、ICMPv4など）が含まれている場合、ハードウェアプロトコル処理部１２の処理結果から得られたプロトコル処理情報がソフトウェアプロトコル処理部２２に通知される。ソフトウェアプロトコル処理部２２は、ソフトウェアによるプロトコル処理を終了すると、アプリケーションに渡すデータがあればアプリケーション２１にデータを渡し、アプリケーション２１は映像情報などの受信データをディスク装置に保存する。

このとき、上述したプロトコル処理情報には、ハードウェアプロトコル処理部１２にてプロトコル処理が完了した情報や、プロトコル処理によって得られた値などが含まれる。したがって、ソフトウェアプロトコル処理部２２は、ハードウェアプロトコル処理部１２で既に処理を終了したプロトコルについては処理を行わず、処理できなかったプロトコルの処理を行う。

次に、通信装置８０の送信処理について、図６を参照して説明する。送信処理では、ソフトウェアプロトコル処理部２２が送信を行う場合、例えば次の３つのケースがある。第１は、上述した受信処理によりARPやICMPv4が処理された場合に、応答パケットを送信するケース。第２は、相手のMACアドレスを知るために能動的にARP要求パケットを送信するケース。第３は、アプリケーション２１からパケットを送信するケースなどがある。ここでは、アプリケーション２１或いはソフトウェアプロトコル処理部２２によるデータ送信の場合を例にして説明する。

通信装置８０の送信処理について、図６を参照して説明する。まず、アプリケーション２１により映像情報などのデータがディスク装置から読み出される。アプリケーション２１は、プロトコル処理を行うために必要なUDPの始点ポート番号３１１、終点ポート番号３１２、UDPパケット長３１３、IPのバージョン２１１、サービスタイプ２１３、IPパケット長２１４、識別子２１５、コントロールフラグ２１６、生存時間２１８、始点IPアドレス２２１、終点IPアドレス２２２、Ethernet(R)の始点MACアドレス１１２、終点MACアドレス１１１、ネットワークのMTU(Maximum Transmission Unit)を生成する。これらのプロトコル処理情報は、ソフトウェアプロトコル処理部２２に通知される。ソフトウェアプロトコル処理部２２は、送信を行うプロトコル処理が全てハードウェアプロトコル処理部１２で処理が可能か否かの判定を行う（ステップＳ２１）。

ハードウェアプロトコル処理部１２では処理ができないと判定した場合、（例えば、ICMPv4の受信処理を行ったパケットがエコー応答を求めるものであった場合、）ソフトウェアプロトコル処理部２２はICMPv4のエコー応答パケットの生成処理を行う。また、ソフトウェアプロトコル処理部２２は、ARP要求パケットを受信した場合のARP応答パケットを生成して送信する。なお、プロトコル処理情報中の値がアプリケーション２１から指定されなかった場合、ソフトウェアプロトコル処理部２２で保持している固定な値を設定してプロトコル処理情報に含めてもよいし、ARP要求パケットを送信して能動的に解決した結果を用いてもよい（ステップＳ２２）。

次に、ソフトウェアプロトコル処理情報生成部２４は、IPv4より上位のプロトコル処理が完了したことを示す情報、IPv4処理を行うために必要な始点IPアドレス２２１、終点IPアドレス２２２、プロトコル番号２１９、Ethernet(R)処理を行うために必要な始点MACアドレス１１２、終点MACアドレス１１１、ペイロードとペイロードの長さ、を含んだプロトコル処理情報を生成する。また、ソフトウェアプロトコル処理情報生成部２４は、下位層であるEthernet(R)の処理に必要な始点MACアドレス１１２、終点MACアドレス１１１、タイプ１１３、ARPまでのプロトコル処理が完了したこと示す情報、をプロトコル処理情報として生成する（ステップＳ２３）。

続いて、ソフトウェアプロトコル処理情報生成部２４は、生成したプロトコル処理情報をハードウェアプロトコル処理再開部１４に伝達する。ハードウェアプロトコル処理再開部１４は、ハードウェアでのプロトコル処理の開始を決定する（ステップＳ２４）。

そして、ハードウェアプロトコル処理部１２が全てのプロトコル処理が可能と判定した場合（或いは、ハードウェアでのプロトコル処理の開始が決定された後）、UDP処理部１７は、通知されたプロトコル処理情報に含まれる値をUDPヘッダの始点ポート番号３１１、終点ポート番号３１２、UDPパケット長３１３に設定する。また、UDP処理部１７は、ヘッダとデータからUDPチェックサム３１４を計算して、UDPヘッダを作成する。

次に、IPv4処理部１６は、必要に応じてフラグメントの処理を行い、パケット毎の識別子２１５、コントロールフラグ２１６、フラグメントオフセット２１７の値を設定する。また、IPヘッダのヘッダチェックサム２２０以外の値を設定する。最後に、ヘッダチェックサム２２０を計算して、チェックサムフィールドに値を設定する。

次に、Ethernet(R)処理部１５は、Ethernet(R)フレームの始点MACアドレス１１２、終点MACアドレス１１１、タイプ１１３を設定する。また、Ethernet(R)処理部１５は、Ethernet(R)のプロトコル処理を行う（ステップＳ２５）。そして、ネットワークコントローラ１１は、Ethernet(R)フレームにＦＣＳ１１５を付加し、変調されたEthernet(R)フレームをネットワーク７０に送信する（ステップＳ２６）。

このように、アプリケーション２１又はソフトウェアプロトコル処理部２２からパケット送信を行う場合、ソフトウェアプロトコル処理部２２は、送信を行うプロトコル処理が全てハードウェアプロトコル処理部１２で処理が可能か否かを判定する。全て処理可能と判断される場合、送信データはハードウェアプロトコル処理部１２からネットワークコントローラ１１に出力される。ネットワークコントローラ１１は、ネットワーク７０を介して送信先装置に伝送する。

一方、全て処理ができないと判断される場合、ソフトウェアプロトコル処理部２２は、送信プロトコル処理を行う。更に、ソフトウェアプロトコル処理情報生成部２４はプロトコル処理情報を生成し、これらのプロトコル処理情報がハードウェアプロトコル処理再開部１４を介してハードウェアプロトコル処理部１２に送信される。このとき、プロトコル処理情報には、ソフトウェアプロトコル処理部２２にてプロトコル処理が完了した部分を示す情報、プロトコル処理により得られた値などが含まれる。ハードウェアプロトコル処理部１２では、ソフトウェアプロトコル処理部２２で処理できなかったプロトコルのみが処理されることになる。例えば、送信するフレームがARPの場合には、ハードウェアプロトコル処理部１２でEthernet(R)の処理が可能であるため、ソフトウェアプロトコル処理部２２でARPの処理のみを行い、ハードウェアプロトコル処理部１２でEthernet(R)の処理を行う。送信するフレームがDCCPやICMPv4の場合は、ハードウェアプロトコル処理部１２でEthernet(R)およびIPv4の処理が可能であるため、ソフトウェアプロトコル処理部２２でDCCPまたはICMPv4の処理のみを行い、ハードウェアプロトコル処理部１２でIPv4およびEthernet(R)の処理を行う。

図７は、実施例１の第１の変形例を示す。第１の変形例の通信装置８０ａには、ハードウェア処理部１ａとソフトウェア処理部２ａが設けられる。ハードウェア処理部１ａには、ネットワークコントローラ１１ａ、ハードウェアプロトコル処理部１２ａ、及びハードウェアプロトコル処理情報生成部１３ａが設けられる。ハードウェアプロトコル処理部１２ａには、Ethernet(R)受信処理部１５ａ、IPv4受信処理部１６ａ、及びUDP受信処理部１７ａが設けられる。ソフトウェア処理部２ａには、アプリケーション２１ａ、ソフトウェアプロトコル処理部２２ａ、ソフトウェアプロトコル処理再開部２３ａ、及びソフトウェアプロトコル処理部３０が設けられる。ソフトウェアプロトコル処理部２２ａには、ARP処理部２５ａ、IPv6処理部２６ａ、ICMPv4処理部２７ａ、及びDCCP処理部２８ａが設けられる。ソフトウェアプロトコル処理部３０には、IPv4送信処理部３１とEthernet(R)送信処理部３２が設けられる。

この第１変形例では、受信に対応するハードウェアプロトコル処理情報生成部１３ａとソフトウェアプロトコル情報再開部２３ａを通信装置８０ａに設けている。送信に対応するソフトウェアプロトコル処理部３０を通信装置８０ａのソフトウェア処理部２ａに設けている。通信装置８０ａでは、ＵＤＰ受信処理を高速化することができる。

この場合、受信データは、ネットワークコントローラ１１ａ、ハードウェアプロトコル処理部１２ａ、ハードウェアプロトコル処理情報生成部１３ａ、ソフトウェアプロトコル処理再開部２３ａ、ソフトウェアプロトコル処理部２２ａ、アプリケーション２１ａへと順次転送される。送信データは、アプリケーション２１ａ、ソフトウェアプロトコル処理部２２ａ、ソフトウェアプロトコル処理部３０、ネットワークコントローラ１１ａへと順次転送される。

なお、ソフトウェアプロトコル処理部２２ａとソフトウェアプロトコル処理部３０は、同一のCPUによって処理されるものであってもよいし、別々のプロセッサによって処理されるものであってもよい。

図８は、実施例１の第２の変形例を示す。第２の変形例の通信装置８０ｂには、ハードウェア処理部１ｂとソフトウェア処理部２ｂが設けられる。ハードウェア処理部１ｂには、ネットワークコントローラ１１ｂ、ハードウェアプロトコル処理部１２ｂ、及びハードウェアプロトコル処理再開１４ｂが設けられる。ハードウェアプロトコル処理部１２ｂには、Ethernet(R)送信処理部１５ｂ、IPv4送信処理部１６ｂ、及びUDP送信処理部１７ｂが設けられる。ソフトウェア処理部２ｂには、アプリケーション２１ｂ、ソフトウェアプロトコル処理部２２ｂ、ソフトウェアプロトコル処理情報生成部２４ｂ、及びソフトウェアプロトコル処理部４０が設けられる。ソフトウェアプロトコル処理部２２ｂには、ARP処理部２５ｂ、IPv6処理部２６ｂ、ICMPv4処理部２７ｂ、及びDCCP処理部２８ｂが設けられる。ソフトウェアプロトコル処理部４０には、IPv4受信処理部４１とEthernet(R)受信処理部４２が設けられる。

この第２変形例では、送信に対応するソフトウェアプロトコル処理情報生成部２４ｂとハードウェアプロトコル情報再開部１４ｂを通信装置８０ｂに設けている。受信に対応するソフトウェアプロトコル処理部４０を通信装置８０ｂのソフトウェア処理部２ｂに設けている。通信装置８０ｂでは、ＵＤＰ送信処理を高速化することができる。

この場合、送信データは、アプリケーション２１ｂ、ソフトウェアプロトコル処理部２２ｂ、ソフトウェアプロトコル処理情報生成部２４ｂ、ハードウェアプロトコル処理再開部１４ｂ、ハードウェアプロトコル処理部１２ｂ、ネットワークコントローラ１１ｂへと順次転送される。受信データは、ネットワークコントローラ１１ｂ、ソフトウェアプロトコル処理部４０、ソフトウェアプロトコル処理部２２ｂ、アプリケーション２１ｂへと順次転送される。

なお、ソフトウェアプロトコル処理部２２ｂとソフトウェアプロトコル処理部４０は、同一のCPUによって処理されるものであってもよいし、別々のプロセッサによって処理されるものであってもよい。

上述したように、本実施例の通信装置は、フレーム受信処理では、ハードウェアプロトコル処理部１２では処理できないフレームの場合、ハードウェアプロトコル処理部１２で処理可能なプロトコル処理を行い、ソフトウェアプロトコル処理部２２で上位層のプロトコル処理を行う構成としている。また、フレーム送信処理では、ソフトウェアプロトコル処理部２２で処理可能なプロトコル処理を行い、ハードウェアプロトコル処理部１２で下位層のプロトコル処理を行う構成としている。このため、受信時及び送信時において全てのプロトコル処理がハードウェアプロトコル処理部１２で行える場合にも、また一部の処理しかハードウェアプロトコル処理部１２で行えない場合にも、できる限り高速にプロトコル処理を実行することができる。したがって、通信装置８０の送受信のスループットを大幅に向上させることができる。

また、Ethernet(R)処理とIPv4処理はハードウェアプロトコル処理部１２で処理され、ソフトウェアプロトコル処理部２２にはEthernet(R)処理部とIPv4処理部を備える必要がないため、ソフトウェアのサイズを削減することができる。更に、ハードウェアプロトコル処理とソフトウェアプロトコル処理を適宜分割することが可能となる。

なお、本実施例では、物理層及びデータリンク層がEthernet(R)であったが、IEEE802.11で定義される規格であってもよい。IEEE802.11を物理層及びデータリンク層に用いる場合、ハードウェアプロトコル処理部１２に制御フレーム処理部及びデータフレーム処理部を設けても良い。また、ソフトウェアプロトコル処理部２２にマネージメントフレーム処理部を設けてもよい。

また、本実施例ではハードウェアプロトコル処理部１２及びソフトウェアプロトコル処理部２２の割り当てをプロトコル単位で行った。プロトコル処理情報により未完了部分を通知することにより、これに限定される、例えばIPv4のフラグメント及びデフラグメント処理部をソフトウェアプロトコル処理部２２に設けてもよい。また、その他の処理部をハードウェアプロトコル処理部１２に設けてもよい。

また、ハードウェアプロトコル処理部１２に実装するプロトコルは、HTTP(Hypertext Transfer Protocol)、TCP(Transmission Control Protocol)、RTP(Real-time Transport Protocol)、IP sec（Security Architecture for Internet Protocol）、SCTP(Stream Control Transmission Protocol)、DCCPなど他のプロトコルであってもよい。

更に、プロトコル処理情報を生成する際に、ソフトウェアプロトコル処理部２２に固定的な値を保持する構成としたが、ハードウェアプロトコル処理部１２に保持してもよい。

次に、本発明の実施例２に係る通信装置について、図面を参照して説明する。図９は通信装置を示すブロック図である。図１０は、TCPヘッダの構成を示す図である。図１１は、TCPのセッション状態を示す図である。本実施例では、ソケット情報伝達部１９をハードウェアプロトコル処理部１２ｃとソフトウェアプロトコル処理部２２ｃの間に設けている点が、実施例１と違う。よって、実施例１と同一構成部分には、同一符号を付してその部分の説明を省略し、異なる部分のみ説明する。

ハードウェアプロトコル処理部１２ｃには、Ethernet(R)処理部１５、IPv4処理部１６、UDP処理部１７の他にTCPデータ処理部１８が新たに設けられている。ソフトウェアプロトコル処理部２２ｃには、ARP処理部２５、ICMPv4処理部２７の他にTCP制御処理部２９が新たに設けられている。なお、ソフトウェアプロトコル処理部２２ｃには、IPv6処理部が取り除かれている。

通信装置８１は、TCPによりネットワーク７０に設けられる装置からの映像データを受信して図示しないディスク装置に保存する機能と、ディスク装置から映像データを読み出してTCPによりネットワーク７０に設けられる装置へデータを送信する機能を有している。また、実施例１の機能の他に、ソケット情報をアプリケーション２１、ハードウェアプロトコル処理部１２ｃ、及びソフトウェアプロトコル処理部２２ｃに伝達するソケット情報伝達部１９を有している。

通信装置８１では、UDPの送信、或いは受信を行うためにポートが開かれたとき、ソケット情報が作成される。また、TCPの送信、或いは受信を行うためにポートが開かれたとき、ソケット情報が作成される。ソケット情報は、ハードウェアプロトコル処理部１２ｃ、及びソフトウェアプロトコル処理部２２ｃから参照可能なメモリ（図示せず）上に設定されている。

ここで、ソケット情報は、プロトコル毎に異なっている。例えば、UDPの場合、本装置のIPアドレス、相手装置のIPアドレス、本装置のポート番号、相手装置のポート番号、セッションの状態、アプリケーションの指定する送信バッファのアドレスと長さ、アプリケーションの指定する受信バッファのアドレスと長さ、IPのサービスタイプ、生存時間、MTU、本装置のMACアドレス、相手装置のMACアドレス等の値が格納されている。UDPのセッションの状態は、オープン或いはクローズのどちらかの状態をとる。

図１０は、TCPヘッダの一例を示す。TCPヘッダは、例えば始点ポート番号４１１、終点ポート番号４１２、シーケンス番号４１３、確認応答番号４１４、データオフセット４１５、未使用（予約）４１６、コントロールフラグ４１７、ウィンドウサイズ４１８、TCPチェックサム４１９、及び緊急ポインタ４２０から構成されている。

例えば、始点ポート番号４１１は１６bit、終点ポート番号４１２は１６bit、シーケンス番号４１３は３２bit、確認応答番号４１４は３２bit、データオフセット４１５は４bit、未使用（予約）４１６は６bit、コントロールフラグ４１７は６bit、ウィンドウサイズ４１８は１６bit、TCPチェックサム４１９は１６bit、及び緊急ポインタ４２０は１６bitである。なお、３２bit単位で可変長であるオプションやバディング部が任意に設けられる。コントロールフラグ４１７のフラグには、URG(Urgent)、ACK(Acknowledge)、PSH(Push)、RST(Reset)、SYN(Synchronize)、及びFIN(Finish)がある。

TCPのセッション情報の場合、本装置のIPアドレス、相手装置のIPアドレス、本装置のポート番号、相手装置のポート番号、セッションの状態、アプリケーションの指定する送信バッファのアドレスと長さ、アプリケーションの指定する受信バッファのアドレスと長さ、IPのサービスタイプ、生存時間、MTU、本装置のMACアドレス、相手装置のMACアドレス、送信したがACKされていないシーケンス番号(SND.UNA)、次に送信するシーケンス番号(SND.NXT)、送信ウィンドウサイズ(SND.WND)、最新のウィンドウ更新のために使ったセグメントシーケンス番号(SND.WL1)、最新のウィンドウ更新のために使われたセグメント確認番号(SND.WL2)、次に受信するべきシーケンス番号(RCV.NXT)、受信ウィンドウサイズ(RCV.WND)等の値が設定される。

TCPのソケット情報については、セグメント送信時或いはセグメント受信時に、ハードウェアプロトコル処理部１２ｃ或いはソフトウェアプロトコル処理部２２ｃにて値が更新されるものがある。

図１１は、TCPのセッション状態を示す。TCPのセッション状態は、LISTEN、SYN-SENT、SYN-RECEIVED、ESTABLIHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK、TIME-WAIT、及びCLOSEDがある。

次に、実施例２の通信装置の動作について、図１２乃至１４を参照して説明する。図１２は、UDP受信処理を示すフローチャートである。図１３は、TCP受信処理を示すフローチャートである。図１４は、TCP送信処理を示すフローチャートである。

通信装置８１のＵＤＰ受信処理について、図１２を参照して説明する。まず、ネットワークコントローラ１１がネットワーク７０から伝送されてきたEthernet(R)フレームを受信する。そして、ネットワークコントローラ１１によってハードウェアプロトコル処理部１２ｃが動作し、プロトコル処理が行われる。即ち、UDP処理部１７は、UDPヘッダの処理を行い、UDPパケット長３１３、ペイロードのUDPチェックサム３１４を計算する。またUDP処理部１７は、データの破損がないか否かを検証する。データの破損していることを検知すると、ペイロードを破棄して、処理を終了する（ステップＳ３１）。次に、ハードウェアプロトコル処理部１２ｃは、ソケット情報のセッション状態がオープンかどうかの判定を行う（ステップＳ３２）。

ソケット情報のセッション状態が「クローズ」状態と判定された場合、ハードウェアプロトコル処理情報生成部１３はICMPのport unreachableを送信するプロトコル処理情報を生成する（ステップＳ３３）。このプロトコル処理情報はソフトウェアプロトコル処理再開部２３に伝達される。ソフトウェアプロトコル処理再開部２３は、ソフトウェアでのプロトコル処理の開始を決定して、ソフトウェアプロトコル処理部２２ｃに通知する（ステップＳ３４）。ソフトウェアプロトコル処理部２２ｃのICMPv4処理部２７は、port unreachableパケットを作成してアプリケーション２１に送信する（ステップＳ３５）。

一方、セッションの状態が「オープン」状態と判定した場合、ハードウェアプロトコル処理部１２ｃは、アプリケーション２１で処理する受信データがあるか否かの判定を行う（ステップＳ３６）。アプリケーション２１にて処理する受信データがないと判定された場合、受信処理は終了する。

アプリケーション２１にて処理する受信データがあると判定された場合、UDP処理部１７はソケット情報によって指定されているアプリケーション２１の受信バッファに受信データを書き込み、ディスク装置に映像データを格納して、処理を終了する（ステップＳ３７）。

次に、通信装置８１のＴＣＰ受信処理について、図１３を参照して説明する。TCPデータ処理部１８は、以下のＴＣＰ受信処理を実行する。（１）ソケット情報のセッション状態が「ESTABLISHED」であれば、TCPヘッダの一部の処理を行う。（２）TCPセグメントのチェックサム検証と、シーケンス番号順にデータの並べ替え処理を行う。（３）ペイロードをソケット情報から得られるアプリケーション２１の受信バッファに書き込む。（４）TCPセグメントのコントロールフラグ４１７のACKビットが設定されていれば、確認応答された内部送信バッファの解放処理を行う。（５）TCPセグメントを受信した場合、送信する確認応答セグメントの送信処理を行う（ステップＳ４１）。

ここで、TCPデータ処理部１８によって確認応答セグメントが作成されると、ハードウェアプロトコル処理部１２ｃのIPv4処理部１６及びEthernet(R)処理部１５では、それぞれの送信処理を行う。これにより、確認応答セグメントはネットワークコントローラ１１を介してネットワーク１１に接続されるクライアント装置に送信される。

次に、TCPデータ処理部１８は、TCPセグメントのコントロールフラグ４１７（図１０のコントロールフラグ表を参照）にFIN、SYN、或いはRSTのいずれかが設定されているか否かの判定を行う（ステップＳ４２）。

FIN、SYN、或いはRSTが設定されていると判定した場合、ハードウェアプロトコル処理情報生成部１３は、プロトコル処理情報を生成する（ステップＳ４３）。このプロトコル処理情報は、ハードウェアプロトコル処理情報生成部１３からソフトウェアプロトコル処理再開部２３に伝達される。ソフトウェアプロトコル処理再開部２３は、ソフトウェアプロトコル処理部２２ｃに対しソフトウェアでのプロトコル処理の開始を指示する（ステップＳ４４）。ソフトウェアプロトコル処理部２２ｃのTCP制御処理部２９は、TCP制御処理を行う（ステップＳ４５）。TCP制御処理部２９は、例えばRFC793に従い、TCPコントロールフラグのビット処理を行う。例えば、SYNフラグが設定されていて、ソケット情報のセッション状態がLISTENであれば、セッション情報のSND.NXT、RCV.NXT等の値が設定される。このとき、コントロールフラグにSYNビットとACKビットを立てたセグメントが相手装置に送信され、SYN-RECEIVEDにセッション状態を移行するという処理が行われる。ソフトウェアプロトコル処理部２２ｃは、アプリケーション２１にて処理する受信データがあるか否かの判定を行う（ステップＳ４６）。処理する受信データがないと判定した場合は、受信処理を終了する。

処理する受信データがある場合、TCPデータ処理部１８はソケット情報によって指定されているアプリケーション２１の受信バッファに書き込み、アプリケーション２１は受信データをディスク装置に格納する動作を実行する（ステップＳ４７）。

次に、通信装置８１のアプリケーション２１からTCPセグメントを送信する処理を、図１４を参照して説明する。ここでは、アプリケーション２１から送信するとしたが、ソフトウェアプロトコル処理部２２ｃから送信する場合も同じである。

まず、アプリケーション２１は、ソケット情報に送信する映像情報などの送信データを格納したバッファのアドレス及び長さなど、プロトコル処理を行うために必要なソケット情報を設定して、直接ハードウェアプロトコル処理部１２ｃへ通知する。

次に、コントロールフラグ４１７のACKフラグ(=02)のみを設定すべきセグメントの場合は以下の送信処理が実行される。ソフトウェアプロトコル処理部２２ｃは、コントロールフラグのFIN、SYN、或いはRSTビットを設定すべきセグメントか否かの判定を行う（ステップＳ５１）。

FIN、SYN、或いはRSTビットを設定すべきセグメントと判定した場合、ソフトウェアプロトコル処理部２２ｃのTCP制御処理部２９は、TCPシーケンス番号の制御やTCPヘッダの生成など、TCPの制御処理を行う（ステップＳ５２）。この様なケースは、アプリケーション２１からコネクションの確立や切断を要求された場合や、コントロールフラグのSYNビットが設定されたセグメントを受信した場合、TCPセグメントの応答処理を求める場合などで行われる。

次に、ソフトウェアプロトコル処理情報生成部２４は、IPv4よりも上位のプロトコル処理が完了されたことを示す情報と、IPv4処理に必要な情報（始点IPアドレス２２１、終点IPアドレス２２２、及びプロトコル番号２１９）と、Ethernet(R)処理に必要な情報（始点MACアドレス１１２及び終点MACアドレス１１１）と、ペイロードとペイロードの長さの情報を含むプロトコル処理情報を生成する（ステップＳ５３）。

続いて、このプロトコル処理情報がソフトウェアプロトコル処理情報生成部２４からハードウェアプロトコル処理再開部１４に伝達される。そして、ハードウェアプロトコル処理再開部１４は、ハードウェアでのプロトコル処理の開始を決定する（ステップＳ５４）。

一方、FIN、SYN、或いはRSTビットを設定すべきセグメントでないと判定した場合、ハードウェアプロトコル処理部１２ｃはＴＣＰデータ処理を行う。上述したハードウェアプロトコル処理再開部１４から情報が入力された場合も、ハードウェアプロトコル処理部１２ｃはＴＣＰデータ処理を行う(ステップＳ５５)。ハードウェアプロトコル処理部１２ｃは、ソケット情報伝達部１９を介して受信したソケット情報からTCPヘッダの始点ポート番号４１１、終点ポート番号４１２、シーケンス番号４１３、確認応答番号４１４、コントロールフラグ４１７、ウィンドウサイズ４１８を設定する。また、ヘッダ長からデータオフセットを計算する。更に、TCPヘッダとデータからTCPチェックサム４１９を計算する。こうして得られたデータから、TCPヘッダが作成される。

次に、IPv4処理部１６は、IPヘッダ（図３参照）のヘッダチェックサム２２０以外の値を設定する。またIPv4処理部１６は、ヘッダチェックサム２２０を計算して、チェックサムフィールドに設定する。

続いて、Ethernet(R)処理部１５では、Ethernet(R)フレーム（図２参照）の始点MACアドレス１１２、終点MACアドレス１１１、及びタイプ１１３を設定する（ステップＳ５５）。

最後に、ネットワークコントローラ１１はEthernet(R)フレームにＦＣＳ１１５を付加する。こうして作成されたEthernet(R)フレームは変調されて、ネットワーク７０を介して送信先装置に送信データが伝送される（ステップＳ５６）。

このように、アプリケーション２１又はソフトウェアプロトコル処理部２２ｃから送信データをパケット送信する場合、まずTCPセグメントのコントロールフラグにACKビット以外のビットを設定すべきパケットかの判断が行われる。もしも、コントロールフラグのACKビットのみが設定されたセグメントである場合、全てハードウェアプロトコル処理部１２ｃによってプロトコル処理されることになる。よって、ソフトウェアプロトコル処理部２２ｃではプロトコル処理は行わない。

一方、コントロールフラグのACK以外のビットを設定すべきセグメントである場合には、ソフトウェアプロトコル処理部２２ｃで少なくとも一部のプロトコル処理が行われる。この場合、ソフトウェアプロトコル処理情報生成部２４にて生成されたプロトコル処理情報を用いて、ハードウェアプロトコル処理部１２ｃがプロトコル処理を行うものである。このとき、プロトコル処理情報には、ソフトウェアプロトコル処理部２２ｃにてプロトコル処理が完了した部分を示す情報、及び得られた値などが含まれる。ハードウェアプロトコル処理部１２ｃでは、ソフトウェアプロトコル処理部２２ｃによって既に処理されたプロトコル処理については、処理しない。処理されなかったプロトコル処理のみが行われる。

実施例２では、セッション確立に関するTCPの制御処理をソフトウェアプロトコル処理部２２ｃで行っているが、セッション状態がSYN-SENT状態又はSYN-RECEIVED状態からESTABLISHED状態への変更をハードウェアプロトコル処理部１２ｃで行ってもよい。これにより、セッション確立直後にデータが受信された場合にも、データを取りこぼすことなく受信することが可能となる。

また、TCPの確認応答セグメントの送信処理をハードウェアプロトコル処理部１２ｃで行っているが、確認応答セグメントの送信間隔を開け、これをソフトウェアプロトコル処理部２２ｃで行ってもよい。これにより、確認応答セグメントを送信する回路を削減することができる。

また、データの送信処理は、全てハードウェアプロトコル処理部１２ｃで行うとしているが、再送処理をソフトウェアプロトコル処理部２２ｃで行ってもよい。ロス率の低いネットワークでは再送処理の発生頻度が低いので、再送のための必要な回路を削減しながら高速なプロトコル処理を実現することが可能となる。

また、受信処理において、シーケンス番号が連続しているセグメントの受信はハードウェアプロトコル処理部１２ｃで行い、不連続なセグメントの受信はソフトウェアプロトコル処理部２２ｃで行ってもよい。パケット順序の入れ替わりの発生頻度が低いネットワークでは、ハードウェアプロトコル処理部１２ｃの回路を簡単化し、高速なプロトコル処理を実現することが可能となる。

更に、自装置のMACアドレスと相手装置のMACアドレスは、セッション情報を介してハードウェアプロトコル処理部１２ｃとソフトウェアプロトコル処理部２２ｃで共有したが、ハードウェアプロトコル処理部１２ｃが送信処理を行うときにIPアドレスからMACアドレスを参照できるようにしてもよい。この場合、ソフトウェアプロトコル処理部２２ｃにルーティングテーブルを備えることで実現できる。

上述したように、本実施例の通信装置では、ソケット情報を用いてプロトコル処理を行うことでハードウェアプロトコル処理部１２ｃとソフトウェアプロトコル処理部２２ｃの状態が同期できる。これにより、稼働率の高いデータ処理をハードウェアプロトコル処理部１２ｃで行い、稼働率の低い制御処理をソフトウェアプロトコル処理部２２ｃで行うことができる。したがって、ハードウェアプロトコル処理部１２ｃの回路規模を抑え、さらに通信装置の送受信のスループットを大幅に向上させることができる。

また、Ethernet(R)処理とIPv4処理とTCPデータ処理についてはハードウェアプロトコル処理部１２ｃで処理され、ソフトウェアプロトコル処理部２２ｃに同じ処理部を備える必要がないため、ソフトウェアサイズを削減することができる。

本発明は、上記実施例に限定されるものではなく、発明の要旨を逸脱しない範囲で、種々、設計変更してもよい。また実施例１，２を適宜組み合わせてもよい。

実施例の通信装置は、例えば汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することができる。また、実施例の通信装置に内蔵或いは外付けされたメモリ、ハードディスク、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用するのが好ましい。

本発明によれば、ネットワーク関連装置へ適用することができる。

１、１ａ、１ｂ、１ｃ ハードウェア処理部
２、２ａ、２ｂ、２ｃ ソフトウェア処理部
１１、１１ａ、１１ｂ ネットワークコントローラ
１２、１２ａ、１２ｂ ハードウェアプロトコル処理部
１３、１３ａ ハードウェアプロトコル処理情報生成部
１４、１４ｂ ハードウェアプロトコル処理再開部
１５、１５ａ、１５ｂ Ethernet（R）処理部
１６、１６ａ、１６ｂ IPv4処理部
１７、１７ａ、１７ｂ UDP処理部
１９ ソケット情報伝達部
２１、２１ａ、２１ｂ アプリケーション
２２、２２ａ、３０、４０ ソフトウェアプロトコル処理部
２３、２３ａ ソフトウェアプロトコル処理再開部
２４、２４ｂ ソフトウェアプロトコル処理情報生成部
２５、２５ａ、２５ｂ ARP処理部
２６、２６ａ、２６ｂ IPv6処理部
２７、２７ａ、２７ｂ ICMPv4処理部
２８、２８ａ、２８ｂ DCCP処理部
２９ TCP制御処理部
３１ IPv4送信処理部
３２ Ethernet（R）送信処理部
４１ IPv4受信処理部
４２ Ethernet（R）受信処理部
７０ ネットワーク
８０、８０ａ 通信装置
２１１ バージョン
２１２ ヘッダ長
２１３ サービスタイプ
２１４ IPパケット長
２１５ 識別子
２１６ コントロールフラグ
２１７ フラグメントオフセット
２１８ 生存時間
２１９ プロトコル番号
２２０ ヘッダチェックサム
２２１ 始点IPアドレス
２２２ 終点IPアドレス
３１１、４１１ 始点ポート番号
３１２、４１２ 終点ポート番号
３１３ UDPパケット長
３１４ UDPチェックサム
４１３ シーケンス番号
４１４ 確認応答番号
４１５ データオフセット
４１６ 未使用（予約）
４１７ コントロールフラグ
４１８ ウィンドウサイズ
４１９ TCPチェックサム
４２０ 緊急ポインタ

Claims (18)

1. 受信データのフレームに対しハードウェアにより、前記フレームの内容に応じて異なるプロトコル処理を行うハードウェアプロトコル処理部と、
   前記ハードウェアプロトコル処理部とは異なるハードウェアで実現され、前記受信データのフレームに対しソフトウェアによるプロトコル処理を行うソフトウェアプロトコル処理部と、
   前記受信データのフレーム毎に、前記ハードウェアプロトコル処理部により処理が完了したプロトコル処理を示す情報又は前記ソフトウェアプロトコル処理部で処理すべきプロトコル処理を示す情報と、前記ハードウェアプロトコル処理部によるプロトコル処理によって得られた値を含むプロトコル処理情報を生成するハードウェアプロトコル処理情報生成部と、
   前記プロトコル処理情報を用いて、前記ハードウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ソフトウェアプロトコル処理部に行わせるソフトウェアプロトコル処理再開部と、
   を具備することを特徴とする通信装置。
2. 前記ハードウェアプロトコル処理部によるハードウェアプロトコル処理とソフトウェアプロトコル処理部によるソフトウェアプロトコル処理は、トランスポート層以下の階層のプロトコル処理を互いに分担して実行することを特徴とする請求項１に記載の通信装置。
3. 前記ハードウェアプロトコル処理部が実行し、前記フレームの内容に応じて異なるプロトコル処理は、前記フレームの内容に応じて異なる階層のプロトコル処理であることを特徴とする請求項１に記載の通信装置。
4. 前記ソフトウェアプロトコル処理部が実施するプロトコル処理は、前記ハードウェアプロトコル処理部で処理できないプロトコル処理であることを特徴とする請求項１に記載の通信装置。
5. 前記プロトコル処理情報は、前記ハードウェアプロトコル処理部で処理が完了した層の上位層のプロトコル識別子を含み、
   前記ソフトウェアプロトコル処理再開部は、上位層のプロトコル処理を前記ソフトウェアプロトコル処理部に行わせることを特徴とする請求項１に記載の通信装置。
6. 送信データのフレームに対しソフトウェアにより、前記フレームの内容に応じて異なるプロトコル処理を行うソフトウェアプロトコル処理部と、
   前記ソフトウェアプロトコル処理部とは異なるハードウェアで実現され、前記送信データのフレームに対しハードウェアによるプロトコル処理を行うハードウェアプロトコル処理部と、
   前記送信データのフレーム毎に、前記ソフトウェアプロトコル処理部により処理が完了したプロトコル処理を示す情報又は前記ハードウェアプロトコル処理部で処理すべきプロトコル処理を示す情報と、前記ソフトウェアプロトコル処理部によるプロトコル処理で得られた値を含むプロトコル処理情報を生成するソフトウェアプロトコル処理情報生成部と、
   前記プロトコル処理情報を用いて、前記ソフトウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ハードウェアプロトコル処理部に行わせるハードウェアプロトコル処理再開部と、
   を具備することを特徴とする通信装置。
7. 前記ハードウェアプロトコル処理部によるハードウェアプロトコル処理とソフトウェアプロトコル処理部によるソフトウェアプロトコル処理は、トランスポート層以下の階層のプロトコル処理を互いに分担して実行することを特徴とする請求項６に記載の通信装置。
8. 前記ハードウェアプロトコル処理部が実行し、前記フレームの内容に応じて異なるプロトコル処理は、前記フレームの内容に応じて異なる階層のプロトコル処理であることを特徴とする請求項６に記載の通信装置。
9. 前記ソフトウェアプロトコル処理部が実施するプロトコル処理は、前記ハードウェアプロトコル処理部で処理できないプロトコル処理であることを特徴とする請求項６に記載の通信装置。
10. 前記プロトコル処理情報は、前記ソフトウェアプロトコル処理部で処理が完了した層の下位層のプロトコル識別子を含み、
    前記ハードウェアプロトコル処理再開部は、下位層のプロトコル処理を前記ハードウェアプロトコル処理部に行わせることを特徴とする請求項６に記載の通信装置。
11. 受信データのフレーム及び送信データのフレームに対しハードウェアにより、前記フレームの内容に応じて異なるプロトコル処理を行うハードウェアプロトコル処理部と、
    前記ハードウェアプロトコル処理部とは異なるハードウェアで実現され、前記受信データのフレーム及び前記送信データのフレームに対しソフトウェアによるプロトコル処理を行うソフトウェアプロトコル処理部と、
    受信のときに、前記受信データのフレーム毎に、前記ハードウェアプロトコル処理部により処理が完了したプロトコル処理を示す情報又は前記ソフトウェアプロトコル処理部で処理すべきプロトコル処理を示す情報と、前記ハードウェアプロトコル処理部によるプロトコル処理によって得られた値を含むプロトコル処理情報を生成するハードウェアプロトコル処理情報生成部と、
    受信のときに、前記ハードウェアプロトコル処理情報生成部のプロトコル処理情報を用いて、前記ハードウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ソフトウェアプロトコル処理部に行わせるソフトウェアプロトコル処理再開部と、
    送信のときに、前記送信データのフレーム毎に、前記ソフトウェアプロトコル処理部により処理が完了したプロトコル処理を示す情報又は前記ハードウェアプロトコル処理部で処理すべきプロトコル処理を示す情報と、前記ソフトウェアプロトコル処理部によるプロトコル処理によって得られた値を含むプロトコル処理情報を生成するソフトウェアプロトコル処理情報生成部と、
    送信のときに、前記ソフトウェアプロトコル処理情報生成部のプロトコル処理情報を用いて、前記ソフトウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ハードウェアプロトコル処理部に行わせるハードウェアプロトコル処理再開部と、
    を具備することを特徴とする通信装置。
12. 前記ハードウェアプロトコル処理部は、Ethernet（R）処理部、IP処理部、及びUDP処理部を有し、
    前記プロトコル処理情報は、前記ハードウェアプロトコル処理部の各処理の完了の有無、始点MACアドレス、終点MACアドレス、フレームのタイプ値、始点IPアドレス、終点IPアドレス、パケット長、プロトコル番号、ペイロードの内少なくとも１つを含み、
    前記ソフトウェアプロトコル処理部は、通信プロトコルの内、前記Ethernet（R）処理部、前記IP処理部、及び前記UDP処理部以外のプロトコル処理部を備えることを特徴とする請求項１１に記載の通信装置。
13. 前記ハードウェアプロトコル処理部は、Ethernet（R）処理部、IP処理部、UDP処理部、及びTCPデータ処理部を有し、
    前記プロトコル処理情報は、前記ハードウェアプロトコル処理部の各処理の完了の有無、TCPのコントロールフラグ、シーケンス番号、確認応答番号、始点IPアドレス、終点IPアドレス、始点ポート番号、終点ポート番号の内少なくとも１つを含み、
    前記ソフトウェアプロトコル処理部は、TCP処理の内、TCPセグメントのコントロールフラグのSYN、FIN、或いはRSTフラグ処理を行うTCP制御処理部を備えることを特徴とする請求項１１に記載の通信装置。
14. 前記ハードウェアプロトコル処理部と前記ソフトウェアプロトコル処理部の間に、ソケット情報を伝達するソケット情報伝達部を有し、
    前記ハードウェアプロトコル処理部或いは前記ソフトウェアプロトコル処理部は、前記ソケット情報を用いてプロトコル処理を行うことを特徴とする請求項１１に記載の通信装置。
15. 前記TCPデータ処理部は、シーケンス番号が連続なセグメントの受信を行い、
    前記ソフトウェアプロトコル処理部はシーケンス番号が不連続なセグメントの受信処理を行うことを特徴とする請求項１３に記載の通信装置。
16. 前記TCPデータ処理部は、再送以外のデータ送信処理を行い、
    前記ソフトウェアプロトコル処理部は再送のデータ送信処理を行うことを特徴とする請求項１３に記載の通信装置。
17. ハードウェアプロトコル処理部が、入力された受信データのフレームに対し、前記フレーム内容に応じて異なるプロトコル処理を実行し、
    前記ハードウェアプロトコル処理部が、ハードウェア処理による全てのプロトコル処理が完了しているかどうかの判定を行い、
    全てのプロトコル処理が完了していない場合、
    ハードウェアプロトコル処理情報生成部が、前記受信データのフレーム毎に、前記ハードウェアプロトコル処理部により処理が完了したプロトコル処理を示す情報又は前記ソフトウェアプロトコル処理部で処理すべきプロトコル処理を示す情報と、前記ハードウェアプロトコル処理部によるプロトコル処理によって得られた値を含むプロトコル処理情報を生成し、
    ソフトウェアプロトコル処理再開部が、前記プロトコル処理情報を用いて、前記ハードウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ソフトウェアプロトコル処理部に実行させる
    を具備することを特徴とする通信装置の受信処理方法。
18. ソフトウェアプロトコル処理部が、読み出された送信データに対し、全てのプロトコル処理がハードウェアプロトコル処理部で処理を実行できるかどうかの判定を行い、
    前記ハードウェアプロトコル処理部で全てのプロトコル処理を実行できない場合、
    ソフトウェアプロトコル処理情報生成部が、前記送信データのフレーム毎に、前記ソフトウェアプロトコル処理部により処理が完了したプロトコル処理を示す情報又は前記ハードウェアプロトコル処理部で処理すべきプロトコル処理を示す情報と、前記ソフトウェアプロトコル処理部によるプロトコル処理で得られた値を含むプロトコル処理情報を生成し、
    ハードウェアプロトコル処理再開部が、前記プロトコル処理情報を用いて、前記ソフトウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ハードウェアプロトコル処理部に実行させる
    を具備することを特徴とする通信装置の送信処理方法。

Images