JP2007329730A - 通信プロトコル処理装置 - Google Patents

Abstract

【課題】小規模で動作スピードが遅くても、低消費電力で安価なオフロードエンジンを使用して充分なネットワークパフォーマンスを実現できる通信プロトコル処理装置を提供する。
【解決手段】本発明の通信プロトコル処理装置は、各層でのソフトウェアによる処理と並列に動作し、プロトコル階層の処理順序の上流側の第１の層での少なくとも一部の処理をハードウェアで代行し、その処理結果を、下流側の第２の層に転送するオフロードエンジンと、第１の層において、オフロードエンジンでの処理に必要となる情報を含むオフロード用ディスクリプタを作成し、オフロードエンジンへ転送した後、オフロードエンジンを起動する手段と、オフロード用ディスクリプタを指し示すポインタを含むパケット用ディスクリプタを作成し、各層の間で順次転送する手段と、第２の層において、オフロードエンジンによる処理結果を受け取り、オフロードエンジンによる処理の終了を確認する手段とを備える。
【選択図】図１

Description

本発明は、複数の層からなる階層構造の通信プロトコルの各層において、ソフトウェアで所定の処理を順次行うとともに、所定の層の所定の処理をオフロードエンジンに転送してハードウェアで処理を代行させる通信プロトコル処理装置に関するものである。

ネットワーク通信では、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）などの通信プロトコルが標準になっており、複雑な処理が要求されている。さらに、近年では、セキュリティへの要請も強く、ＩＰＳＥＣ（IP security protocol）、ＳＳＬ（secure sockets layer）、ＴＬＳ（transport layer security）などの暗号処理を含むプロトコルも追加され、ますます処理の負荷が増えている。

従来、ネットワーク通信の通信プロトコルの処理は、ＣＰＵ（Central Processing Unit：中央処理装置）によって、ソフトウェア（プログラム）で実行されるのが普通であった。

ここで、図４の概念図を参照しながら、ＳＳＬ層でのソフトウェアによる暗号処理を含む場合を例に挙げて、従来の通信プロトコル処理装置の各層における処理について説明する。

図４に示す通信プロトコルは、上から順に、アプリケーション層、ＳＳＬ層、ＴＣＰ層、ＩＰ層、Ｅｔｈｅｒｎｅｔ層の５層からなる階層構造になっている。図４は、送信データを順次処理する場合の例である。送信データは、アプリケーション層から、下位側の層（図４中、上側から下側）に向かって順次所定の処理をされながら、Ｅｔｈｅｒｎｅｔ層まで受け渡される。

図４に示すように、様々な長さ（バイト長）の送信データが、アプリケーション層からＳＳＬ層に受け渡される。

ＳＳＬ層では、送信データが、所定ビット長ないしバイト長のパケットデータに分割ないし合成される。各々のパケットデータは、ＳＳＬ層で暗号処理（パケットデータの暗号化）が行われる。暗号化後のパケットデータ（暗号化データ）は、図４中斜線で示す格納領域に格納され、その格納領域の前にＳＳＬ層のヘッダが付加される。ＳＳＬ層のデータ（ＳＳＬ層のヘッダ＋暗号化データ）はＴＣＰ層に受け渡される。

ＴＣＰ層では、ＩＰ層との間で、暗号化データを含む、各種のデータの送受信の確認応答の処理や、再送等の処理が行われる。また、ＴＣＰ層では、ＳＳＬ層から受け渡されたデータの前にＴＣＰ層のヘッダが付加される。ＴＣＰ層のデータ（ＴＣＰ層のヘッダ＋ＳＳＬ層のヘッダ＋暗号化データ）はＩＰ層に受け渡される。

ＩＰ層では、ＴＣＰ層から受け渡されたデータの前にＩＰ層のヘッダが付加される。ＩＰ層のデータ（ＩＰ層のヘッダ＋ＴＣＰ層のヘッダ＋ＳＳＬ層のヘッダ＋暗号化データ）はＥｔｈｅｒｎｅｔ層に受け渡される。

Ｅｔｈｅｒｎｅｔ層では、ＩＰ層から受け渡されたデータの前にＥｔｈｅｒｎｅｔ層のヘッダが付加され、そのデータの後ろにＥｔｈｅｒｎｅｔ層のトレイラが付加される。Ｅｔｈｅｒｎｅｔ層のデータ（Ｅｔｈｅｒｎｅｔ層のヘッダ＋ＩＰ層のヘッダ＋ＴＣＰ層のヘッダ＋ＳＳＬ層のヘッダ＋暗号化データ＋Ｅｔｈｅｒｎｅｔ層のトレイラ）は、ネットワークを介して目的地まで送信される。

これに対し、通信プロトコルの処理の複雑化に対応するために、専用のハードウェア（オフロードエンジン）を追加し、ＣＰＵによるソフトウェアでの処理を代行させて、その負荷軽減させる（オフロードする）手法が各種開発されている。

例えば、Ｅｔｈｅｒｎｅｔ（イーサネット）（登録商標）のインタフェースチップにＴＣＰやＵＤＰ（User Datagram Protocol）のチェックサムを計算するハードウェアのオフロードエンジンを追加して、ソフトウェアによるＴＣＰやＵＤＰのプロトコル処理の負荷を軽減する製品がある。このような製品の１つは、例えばインターネット＜ＵＲＬ：http://www.intel.com/design/network/products/lan/controllers/82559.htm＞、［平成１８年６月７日検索］において公開されている。

また、例えば特許文献１において、汎用的なオフロードのインタフェース機構を持たせる手法や、特許文献２において、ＴＣＰプロトコル以下のプロトコル階層全体を別のサブシステムに実装する手法などが提案されている。

ＴＣＰ／ＩＰなどの通信プロトコルは階層構造になっており、データが送信される場合、送信データに各層固有の処理が加えられ、直下の層に受け渡す、という処理が、最上位層から最下位層まで順に繰り返される。一方、データが受信される場合、受信データに各層固有の処理が加えられ、直上の層に受け渡す、という処理が、最下位層から最上位層まで順に繰り返される。

各層における処理は個別に実装されることが多く、各層は逐次的に処理されるのが普通である。そのため、処理にかかる総所要時間は、各層の処理時間の総和となる。ハードウェアによるオフロードが行われる場合でも、各層の処理が逐次処理されるのは同様である。従って、オフロードの対象となる層の処理時間だけが短縮され、その結果として、総所要時間は、オフロード対象の層における高速化分だけしか削減されない。

次に、図５に示す概念図を参照しながら、従来の通信プロトコル処理装置において、オフロードなしとありの場合の処理時間の違いを説明する。

図５に示す概念図は、図４に示す従来の通信プロトコル処理装置において、オフロードなしの場合と、オフロードありの場合の処理時間の違いを表す。図５中、上側がオフロードなし、下側がオフロードありの場合であり、左側から右側へ向かって時間が経過することを表す。図５から分かるように、オフロードによる処理時間の短縮は、オフロードの対象であるＳＳＬ層の暗号処理に関わる処理時間だけである。

従って、オフロードによる処理時間の短縮時間は、全ての層における処理時間の総和に対する割合からすると、あまり効果が大きくないことが多い。さらに、ソフトウェアからハードウェアを呼び出すためのオーバーヘッドもあるため、オフロードには、高性能のハードウェアを使用しないと効果が出にくい。しかし、そのようなハードウェアは、回路規模や消費電力が大きく、コストも高い。

例えば、パーソナルコンピュータなどの汎用的なシステムにおいては、ＣＰＵの性能向上が目覚ましい。従って、ソフトウェアによる通信プロトコルの処理の負荷が問題にならず、オフロードしてハードウェアによる処理をする必要がないことも多い。また、通信が主要な機能であるような装置においては、専用のハードウェアを装備してオフロードすることによって大きな効果が得られる。

しかし、情報家電や携帯電子機器、事務機器などの組込みシステムの分野では、低消費電力や低コストへの要求が強く、通信プロトコル処理に多くのリソースを割けない場合が多い。すなわち、小規模で動作スピードが遅くても、低消費電力で安価なＣＰＵとオフロード用ハードウェアを用いて、要求されるネットワークパフォーマンスを実現したい。しかし、いずれの従来技術も、そのような要求を満足するものは存在しない。

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

本発明の目的は、前記従来技術に基づく問題点を解消し、小規模で動作スピードが遅くても、低消費電力で安価なオフロードエンジンを使用して充分なネットワークパフォーマンスを実現することができる通信プロトコル処理装置を提供することにある。

上記目的を達成するために、本発明は、複数の層からなる通信プロトコルの各層における処理を順次行い、転送データを送受信する通信プロトコル処理装置であって、
前記各層でのソフトウェアによる処理と並列に動作し、プロトコル階層における処理順序の上流側の第１の層における処理の少なくとも一部の処理をハードウェアで代行し、その処理結果を、前記第１の層よりも下流側の第２の層に転送するオフロードエンジンと、
前記第１の層において、前記オフロードエンジンでの処理に必要となる情報を含むオフロード用ディスクリプタを作成し、該オフロード用ディスクリプタを前記オフロードエンジンへ転送した後、該オフロードエンジンを起動する第１の手段と、
前記オフロード用ディスクリプタを指し示すポインタを含むパケット用ディスクリプタを作成し、該パケット用ディスクリプタを前記各層の間で順次転送する第２の手段と、
前記第２の層において、前記オフロードエンジンによる処理結果を受け取り、該オフロードエンジンによる処理の終了を確認する第３の手段とを備えることを特徴とする通信プロトコル処理装置を提供するものである。

ここで、前記オフロードエンジンは、前記転送データの暗号処理を行う暗号処理エンジンであることが好ましい。

本発明の通信プロトコル処理装置によれば、オフロードのためのハードウェアによる処理は、小規模で動作スピードが遅い、すなわち、低消費電力で安価なオフロードエンジンを採用して、充分なネットワークパフォーマンスを実現でき、全体としては要求される転送性能が実現できる。また、オフロードを行うことによって、ＣＰＵによるソフトウェアでの処理時間にも充分な余裕ができる。

以下に、添付の図面に示す好適実施形態に基づいて、本発明の通信プロトコル処理装置を詳細に説明する。

複数の層（レイヤー）からなる階層構造の通信プロトコルの処理において、ある層の処理結果の全てが、転送データ（送信データないし受信データ）の処理順序の下流側の層で直ちに必要となるわけではない。

例えば、暗号処理を含むセキュリティプロトコルを使用する場合、ヘッダ等の制御情報は直下の層で必要となる。しかし、暗号処理された転送データ（暗号化後の送信データまたは復号化後の受信データ）自体は、さらに下流側の層に受け渡される（転送される）だけであり、その内容は参照されない。つまり、このようなデータに関しては、その処理結果が実際に必要となる層の直前の層までに処理が完了していれば問題はない。

本発明では、上記のように、所定の層で所定の処理を完了させ、その処理結果を処理順序の下流側の層に順次転送していく直列構造を採用するのではなく、所定の層から、その処理結果を実際に必要とする下流側の所定の層の直前の層までの間にわたって、ある層における処理の少なくとも一部をオフロードエンジンによるハードウェアで代行し、その処理結果を前述の直前の層までの間の層に転送する。

これにより、ＣＰＵでのソフトウェアによる処理時間に余裕ができるとともに、ハードウェアによる処理は、小規模で動作スピードが遅くても、低消費電力で安価なオフロードエンジンを採用して、全体としては要求される転送性能が実現できるようになる。

以下、本発明の通信プロトコル処理装置について順次説明を行う。

本発明の通信プロトコル処理装置は、上記の通り、通信プロトコルの各層における処理をソフトウェアで順次行うとともに、所定の層における所定の処理の少なくとも一部をオフロードエンジンによるハードウェアで代行して転送データを送受信する。

本発明の通信プロトコル処理装置は、各層でのソフトウェアによる処理と並列に動作し、プロトコル階層における処理順序の上流側の第１の層における処理の少なくとも一部の処理をハードウェアで代行し、その処理結果を、第１の層よりも下流側の第２の層に転送するオフロードエンジンと、第１の層において、オフロードエンジンでの処理に必要となる情報を含むオフロード用ディスクリプタを作成し、そのオフロード用ディスクリプタをオフロードエンジンへ転送した後、オフロードエンジンを起動する第１の手段と、オフロード用ディスクリプタを指し示すポインタを含むパケット用ディスクリプタを作成し、そのパケット用ディスクリプタを各層の間で順次転送する第２の手段と、第２の層において、オフロードエンジンによる処理結果を受け取り、オフロードエンジンによる処理の終了を確認する第３の手段とを備えている。

まず、図１の概念図を参照しながら、ＳＳＬ層でのソフトウェアによる暗号処理を、暗号処理エンジン（オフロードエンジン）によるハードウェアで代行して暗号処理する場合を例に挙げて、本発明の通信プロトコル処理装置の各層における処理について説明する。

図１に示す本実施形態の通信プロトコルは、図４の場合と同様、上から順に、アプリケーション層、ＳＳＬ層、ＴＣＰ層、ＩＰ層、Ｅｔｈｅｒｎｅｔ層の５層からなる階層構造になっている。図１は、送信データを順次処理する場合の例である。送信データは、アプリケーション層から、下位側の層に向かって順次所定の処理をされながら、Ｅｔｈｅｒｎｅｔ層まで受け渡される。

ここで、従来、ＳＳＬ層で暗号処理された暗号化後の送信データ（暗号化データ）は、下位側の層に順次受け渡されるが、最終的にＥｔｈｅｒｎｅｔ層に受け渡されるまで何ら加工されない。従って、暗号処理の完了時期は、Ｅｔｈｅｒｎｅｔ層の直前のＩＰ層まで延期できる。すなわち、例えばＳＳＬ層からＴＣＰ層に送信データ（パケットデータ）が受け渡される時点で、暗号処理は完了していなくても問題はない。

なお、既に述べた通り、ＴＣＰ層では、暗号化データ全体のチェックサムが計算され、その計算結果がＴＣＰ層のヘッダの中に格納される。従って、送信データの暗号処理は、本来であれば、このチェックサムの計算が開始されるまでに完了していなければならない。しかし、これも前述の通り、ＴＣＰ層におけるチェックサムの計算をオフロードするハードウェアは既に市販されている。

このＴＣＰ層におけるチェックサムの計算をオフロードするハードウェアを利用すれば、ＴＣＰ層でソフトウェアによる暗号化データのチェックサムを計算する必要はない。従って、この場合には、暗号処理の完了時期を延期することができ、送信データをＩＰ層からＥｔｈｅｒｎｅｔ層に受け渡す時点までに暗号処理が完了していれば良い。つまり、暗号処理は、ＳＳＬ層からＩＰ層までの間に完了していれば良い。

図１に示すように、様々な長さ（バイト長）の送信データが、アプリケーション層からＳＳＬ層に受け渡される。

ＳＳＬ層では、送信データが、所定ビット長ないしバイト長のパケットデータに分割ないし合成される。各々のパケットデータは、ＳＳＬ層から暗号処理エンジンに順次転送される。また、ＳＳＬ層では、図１中点線で示すように、各々の暗号化後のパケットデータ（暗号化データ）が格納される領域が確保され、その領域の前にＳＳＬ層のヘッダが付加される。ＳＳＬ層のデータ（ＳＳＬ層のヘッダ＋暗号化データの格納領域）はＴＣＰ層に受け渡される。

ここで、暗号処理エンジンでは、ＳＳＬ層から転送されてきたパケットデータに対して暗号処理（送信データの暗号化）が行われる。暗号処理エンジンは、各層でのソフトウェアによる処理と並列に動作し、ＳＳＬ層でのソフトウェアによる暗号処理を代行して、ハードウェアによる暗号処理を行う。その処理結果（暗号化データ）は、実際に暗号化データを必要とするＥｔｈｅｒｎｅｔ層の直前のＩＰ層の処理が終了するまでに、暗号化データの格納領域内に転送される（書き込まれる）。

一方、ＴＣＰ層では、前述の通り、ＩＰ層との間で、各種データの送受信の確認応答の処理や、再送等の処理が行われる。また、ＴＣＰ層では、ＳＳＬ層から受け渡されたデータの前にＴＣＰ層のヘッダが付加される。ＴＣＰ層のデータ（ＴＣＰ層のヘッダ＋ＳＳＬ層のヘッダ＋暗号化データの格納領域）はＩＰ層に受け渡される。

ＩＰ層では、前述の通り、暗号処理エンジンから、暗号化データが転送されてきて、暗号化データの格納領域内に格納されていることを確認する。また、ＩＰ層では、ＴＣＰ層から受け渡されたデータの前にＩＰ層のヘッダが付加される。ＩＰ層のデータ（ＩＰ層のヘッダ＋ＴＣＰ層のヘッダ＋ＳＳＬ層のヘッダ＋暗号化データ）はＥｔｈｅｒｎｅｔ層に受け渡される。

Ｅｔｈｅｒｎｅｔ層では、ＩＰ層から受け渡されたデータの前にＥｔｈｅｒｎｅｔ層のヘッダが付加され、そのデータの後ろにＥｔｈｅｒｎｅｔ層のトレイラが付加される。Ｅｔｈｅｒｎｅｔ層のデータ（Ｅｔｈｅｒｎｅｔ層のヘッダ＋ＩＰ層のヘッダ＋ＴＣＰ層のヘッダ＋ＳＳＬ層のヘッダ＋暗号化データ＋Ｅｔｈｅｒｎｅｔ層のトレイラ）は、ネットワークを介して送信される。

次に、図２に示す概念図を参照しながら、図１に示す通信プロトコル処理装置の各層における具体的な処理について説明する。

図２に示す概念図は、図１に示す概念図を具体的に表示したものである。従って、図１の場合と同様に、アプリケーション層からＥｔｈｅｒｎｅｔ層まで、送信データ（パケットデータ）を順次処理する場合の例である。

図２に示すように、アプリケーション層では、送信データの格納位置を指し示すｄａｔａポインタと、処理対象の送信データに対応する暗号処理ディスクリプタ（オフロード用ディスクリプタ）を指し示す暗号処理ポインタとを含む、パケット用ディスクリプタが作成される。このパケット用ディスクリプタとともに、様々な長さ（バイト長）の送信データが、アプリケーション層からＳＳＬ層に受け渡される（転送される）。

ここで、送信データは、例えば所定の長さ（バイト数）のデータが、半導体メモリの所定のアドレスに格納されている。ｄａｔａポインタは、送信データが格納されている半導体メモリのアドレスとその長さを表す。ｄａｔａポインタを用いることで、送信データを各層間で転送する時に、送信データ自体をコピーすることなく（コピーするための時間を必要とせずに）、ｄａｔａポインタを各層間で転送するだけで送信データの受け渡しができる。

ＳＳＬ層では、アプリケーション層から転送されてきたパケット用ディスクリプタのｄａｔａポインタを参照して処理対象の送信データが認識される。送信データは、所定ビット長ないしバイト長のパケットデータに分割ないし合成される。なお、図２では、その煩雑さを避けるために、パケットデータの図示は省略してある。

また、ＳＳＬ層では、図２中点線で示す、暗号化後の送信データ（暗号化データ）が格納される領域（半導体メモリのアドレス）が確保（準備）される。また、ＳＳＬ層のヘッダが作成され、暗号化データの格納領域の前にＳＳＬ層のヘッダが付加される。そして、ｄａｔａポインタの指し示すアドレスが、ＳＳＬ層のヘッダの先頭アドレスに更新される。ＳＳＬ層のデータ（ＳＳＬ層のヘッダ＋暗号化データの格納領域）と更新されたパケット用ディスクリプタはＴＣＰ層に受け渡される。

なお、図１中、ＳＳＬ層のヘッダの左側に点線で示すヘッダ予約領域と、暗号化データの格納領域の右側に示すトレイラ予約領域（図１中では、単に予約と表記している）は、後述するＴＣＰ層、ＩＰ層、Ｅｔｈｅｒｎｅｔ層において、各々のヘッダおよびトレイラが付加される領域である。これらの予約領域も、暗号化データの格納領域と同様に、ＳＳＬ層において確保される。

また、ＳＳＬ層では、暗号処理パラメータが準備される。暗号処理パラメータには、暗号処理のために必要となる鍵などの情報が含まれている。暗号処理パラメータは、半導体メモリの所定のアドレスに格納されている。

また、ＳＳＬ層では、暗号処理ディスクリプタが作成され、暗号処理エンジンに転送される。暗号処理ディスクリプタには、暗号処理エンジンでの処理に必要となる情報、本実施形態の場合、ｓｔａｔｅ、ｓｒｃ、ｄｓｔ、ｐａｒａｍの情報が含まれている。暗号処理ポインタは、前述の通り、暗号処理エンジンに転送された処理対象の送信データに対応する暗号処理ディスクリプタを指し示す。

ここで、ｓｔａｔｅは、暗号処理の状態を表すフラグである。ｓｔａｔｅがＢＵＳＹの時は暗号処理中であり、ＲＥＡＤＹの時は処理完了を意味する。また、ｓｒｃは、暗号処理の対象となる送信データの格納位置を指し示すポインタ、ｄｓｔは、暗号化データを格納するための格納領域の位置を指し示すポインタ、ｐａｒａｍは、暗号処理パラメータの格納位置を指し示すポインタである。

暗号処理エンジンでは、ＳＳＬ層から、暗号処理エンジンの起動を指示する信号が与えられると、暗号処理ディスクリプタに基づいて暗号処理（送信データの暗号化）が開始される。その処理結果（暗号化データ）は、本実施形態の場合、実際に暗号化データを必要とするＥｔｈｅｒｎｅｔ層の直前のＩＰ層の処理が終了するまでに、暗号化データの格納領域内に転送される。

暗号処理エンジンでは、ｓｒｃによって、処理対象の転送データの格納位置（半導体メモリのアドレス）が認識され、ｄｓｔによって、暗号化データの転送先となる格納領域が認識され、ｐａｒａｍによって、暗号処理パラメータの格納位置が認識される。ｓｔａｔｅの初期値は、ｓｔａｔｅ＝ＢＵＳＹであり、暗号処理が完了すると、ｓｔａｔｅ＝ＲＥＡＤＹとされる。

一方、ＴＣＰ層では、前述の通り、ＩＰ層との間で各種の処理が行われるが、図２では、煩雑さを避けるために省略してある。ＴＣＰ層では、ＴＣＰ層のヘッダが作成され、ＳＳＬ層から受け渡されたデータの前にＴＣＰ層のヘッダが付加される。そして、ｄａｔａポインタの指し示すアドレスが、ＴＣＰ層のヘッダの先頭アドレスに更新される。ＴＣＰ層のデータ（ＴＣＰ層のヘッダ＋ＳＳＬ層のヘッダ＋暗号化データの格納領域）と更新されたパケット用ディスクリプタはＩＰ層に受け渡される。

前述の通り、暗号処理エンジンにおいて、処理対象の送信データの暗号処理が完了すると、暗号化データは、暗号化データの格納領域内に書き込まれるとともに、ｓｔａｔｅ＝ＲＥＡＤＹとなる。ＩＰ層では、暗号処理ポインタで指定される暗号処理ディスクリプタ内のｓｔａｔｅ情報を確認することによって、暗号処理エンジンによる暗号処理の終了確認が行われる。すなわち、ＩＰ層では、ｓｔａｔｅ＝ＲＥＡＤＹであれば、暗号処理が終了していると判断される。

ＩＰ層では、ＩＰ層のヘッダが作成され、ＴＣＰ層から受け渡されたデータの前にＩＰ層のヘッダが付加される。そして、ｄａｔａポインタの指し示すアドレスが、ＩＰ層のヘッダの先頭アドレスに更新される。また、ＩＰ層では、前述の暗号処理の終了が確認されると、ＩＰ層のデータ（ＩＰ層のヘッダ＋ＴＣＰ層のヘッダ＋ＳＳＬ層のヘッダ＋暗号化データ）と更新されたパケット用ディスクリプタはＥｔｈｅｒｎｅｔ層に受け渡される。

Ｅｔｈｅｒｎｅｔ層では、Ｅｔｈｅｒｎｅｔ層のヘッダとトレイラが作成され、ＩＰ層から受け渡されたデータの前にＥｔｈｅｒｎｅｔ層のヘッダが付加され、そのデータの後ろにトレイラが付加される。そして、ｄａｔａポインタの指し示すアドレスが、Ｅｔｈｅｒｎｅｔ層のヘッダの先頭アドレスに更新される。Ｅｔｈｅｒｎｅｔ層のデータ（Ｅｔｈｅｒｎｅｔ層のヘッダ＋ＩＰ層のヘッダ＋ＴＣＰ層のヘッダ＋ＳＳＬ層のヘッダ＋暗号化データ＋Ｅｔｈｅｒｎｅｔ層のトレイラ）はネットワークを介して送信される。

次に、図３に示す概念図を参照しながら、図１および図２に示す本実施形態の通信プロトコル装置と、図４に示す従来の通信プロトコル処理装置の処理時間の違いを説明する。

図３に示す概念図において、上２つのオフロードなしと従来型オフロードありは、図５に示す概念図と全く同じである。一番下が本実施形態の通信プロトコル装置による処理時間を表す。

この図３から分かるように、従来型オフロードありの場合の通信プロトコル処理装置では、ＳＳＬ層内において、オフロードエンジンを使用してハードウェアによる暗号処理を短時間で高速に行う。このため、大規模で動作スピードが速い、すなわち、消費電力が大きく、高価なオフロードエンジンを採用することによって始めて、充分なネットワークパフォーマンスを実現でき、全体として要求される転送性能が実現できる。

これに対し、本実施形態の通信プロトコル処理装置では、従来型オフロードありの場合の通信プロトコル処理装置と比べても、暗号処理に使うことができる時間が長く、しかも全体としての処理時間も短くなっている。

すなわち、本実施形態の通信プロトコル処理装置では、オフロードのためのハードウェアによる処理は、小規模で動作スピードが遅い、すなわち、低消費電力で安価なオフロードエンジンを採用して、充分なネットワークパフォーマンスを実現でき、全体としては要求される転送性能が実現できる。また、オフロードを行うことによって、ＣＰＵによるソフトウェアでの処理時間にも充分な余裕ができる。

なお、実施形態では、５つの層からなる階層構造の通信プロトコルを例に挙げて説明したが、通信プロトコルに含まれる層数は何ら限定されないし、各層が何であるかも何ら限定されない。例えば、ＴＣＰ層では、転送データのチェックサムを計算し、その計算結果をＴＣＰ層のヘッダの中に格納されると述べたが、この制限は、通信プロトコルの中にＴＣＰ層が存在しなければ関係のない制限である。

また、実施形態では、ＳＳＬ層におけるソフトウェアによる暗号処理を、ハードウェアの暗号処理エンジンにオフロードする場合を例に挙げて説明したが、オフロードする処理は暗号処理に限定されないし、オフロードする数も１つだけに限定されない。また、実施形態では、送信データを送信する場合を例に挙げて説明したが、受信データを受信する場合の動作は、送信データを送信する場合の逆の動作になる。

本発明は、基本的に以上のようなものである。
以上、本発明の通信プロトコル処理装置について詳細に説明したが、本発明は上記実施形態に限定されず、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのはもちろんである。

本発明の通信プロトコル処理装置における処理を表す一実施形態の概念図である。 図１に示す通信プロトコル処理装置における処理の詳細を表す概念図である。 本発明の通信プロトコル処理装置による処理時間と従来の通信プロトコル処理装置による処理時間との違いを表す概念図である。 従来の通信プロトコル処理装置における処理を表す一例の概念図である。 従来の通信プロトコル処理装置において、オフロードなしの場合とありの場合との処理時間の違いを表す一例の概念図である。

Claims (2)

1. 複数の層からなる通信プロトコルの各層における処理を順次行い、転送データを送受信する通信プロトコル処理装置であって、
   前記各層でのソフトウェアによる処理と並列に動作し、プロトコル階層における処理順序の上流側の第１の層における処理の少なくとも一部の処理をハードウェアで代行し、その処理結果を、前記第１の層よりも下流側の第２の層に転送するオフロードエンジンと、
   前記第１の層において、前記オフロードエンジンでの処理に必要となる情報を含むオフロード用ディスクリプタを作成し、該オフロード用ディスクリプタを前記オフロードエンジンへ転送した後、該オフロードエンジンを起動する第１の手段と、
   前記オフロード用ディスクリプタを指し示すポインタを含むパケット用ディスクリプタを作成し、該パケット用ディスクリプタを前記各層の間で順次転送する第２の手段と、
   前記第２の層において、前記オフロードエンジンによる処理結果を受け取り、該オフロードエンジンによる処理の終了を確認する第３の手段とを備えることを特徴とする通信プロトコル処理装置。
2. 前記オフロードエンジンは、前記転送データの暗号処理を行う暗号処理エンジンであることを特徴とする請求項１に記載の通信プロトコル処理装置。

Images