JP4591582B2

JP4591582B2 - ネットワークアダプタ及び通信装置

Info

Publication number: JP4591582B2
Application number: JP2008231546A
Authority: JP
Inventors: 良規本庄; 志伸栗屋
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2008-09-09
Filing date: 2008-09-09
Publication date: 2010-12-01
Anticipated expiration: 2028-09-09
Also published as: US20100064129A1; JP2010068155A

Description

本発明は、ＰＣＩ（Peripheral Component Interconnect）等の汎用バスによりホスト機器と結合可能なネットワークアダプタ及び通信装置に関する。

近年、ディジタルコンテンツには、著作権保護のため、「１０回のみ複製可」や「複製不可（視聴可）」等の属性が与えられている。また、家庭内において、ＤＮＬＡ（Digital Living Network Alliance）などの規格に対応した録画機器をホームネットワーク（ＬＡＮ：Local Area Network）に接続し、ディジタルコンテンツを配信することが可能となっている。

このようなネットワークにおいて、著作権保護されたディジタルコンテンツを転送する際には、機器間の認証、コンテンツの暗号化等のディジタル著作権管理（DRM：Digital Rights Management）が必要となる。このＤＲＭ機能は、比較的処理負荷が高いため、ホスト機器に結合されるネットワークフロントエンド（ＮＦＥ：Network Front End）に持たせることが提案されている（例えば、特許文献１参照。）。

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

ところで、上述のようにＮＦＥがＤＲＭ機能を担う場合、一般に、ＰＣＩ（Peripheral Component Interconnect）などの汎用バスを用いてＮＦＥとホスト機器との間の通信を行うための専用ドライバを両者に実装する。この場合、ＮＦＥ側の専用ドライバ及びＤＲＭアプリケーション、並びにホスト機器側の専用ドライバ及びＤＲＭアプリケーションは、それぞれ独自のＡＰＩ（Application Program Interface）を備えるものとなる。

このため、ホスト機器は、ネットワークに接続する場合、ＮＦＥのネットワーク機能を使うのとは別に、汎用ネットワーク機能を用いてアクセスする必要があった。

ホスト機器に独自に汎用ネットワークインターフェースを設けることも可能であるが、物理的コスト、ネットワーク処理に要するホストＣＰＵ（Central Processing Unit）の負荷コストが無視できなかった。

また、ホスト機器において、汎用ネットワークのためのドライバをＤＲＭ機能の専用ドライバとは別に実装することも考えられるが、両者を２重に開発しなくてはならないことや、両者が１つのＰＣＩデバイスを共有するために生じる競合などの問題を解決する必要があった。

本発明は、このような従来の実情に鑑みて提案されたものであり、汎用ネットワーク機能及びＤＲＭ機能を発揮し、ホスト機器の負担を軽減させるネットワークアダプタ及び通信装置を提供する。

本発明に係るネットワークアダプタは、ネットワークに接続し、パケットデータを送受信するネットワーク接続部と、バスに接続し、データ及び制御情報をホスト機器に送受信するバス接続部と、コンテンツを暗号化し、又は暗号化コンテンツを復号する暗号復号アプリケーションを実行する暗号復号処理部と、ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行する制御部とを備え、上記暗号復号アプリケーションは、上記ソケットインターフェースを介して上記ネットワーク接続部又は上記バス接続部と通信し、上記制御部は、上記デバイスドライバとしてネットワークデバイスドライバを用いて、上記バス接続部のデータ及び制御情報の送受信を制御する。

また、本発明に係る通信装置は、ネットワークに接続し、パケットデータを送受信するネットワーク接続部と、バスに接続し、データ及び制御情報をホスト機器に送受信するバス接続部と、コンテンツを暗号化し、又は暗号化コンテンツを復号する暗号復号アプリケーションを実行する暗号復号処理部と、ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行するネットワーク制御部とを備えるネットワークアダプタと、上記バスを介して上記ネットワークアダプタに接続するデバイス接続部と、ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行するホスト制御部とを備えるホスト機器とを有し、上記暗号復号アプリケーションは、上記ソケットインターフェースを介して上記ネットワーク接続部又は上記バス接続部と通信し、上記ネットワーク制御部及び上記ホスト制御部は、上記デバイスドライバとしてネットワークデバイスドライバを用いて、上記バス接続部と上記デバイス接続部との間のデータ及び制御情報の送受信を制御する。

本発明によれば、ネットワークアダプタ及びホスト機器の両側にデバイスドライバとしてネットワークデバイスドライバを実装し、ネットワークアダプタとホスト機器との間のバス通信を制御することにより、ＤＲＭアプリケーション間の通信と汎用ネットワークアクセスとを両立し、ホスト機器の負担を軽減させることができる。

以下、本発明の具体的な実施の形態について、図面を参照しながら下記順序で詳細に説明する。

１．全体構成図１
２．通信方法
２−１．イーサネット通信図２
２−２．ＤＭＡ転送図３〜図１７

［１．全体構成］
図１は、ネットワーク全体の構成例を示す図である。このネットワークには、ネットワークフロントエンド（ＮＦＥ：Network Front End）１が結合されたホスト機器２と、ウェブサーバ３と、ＤＲＭ（Digital Rights Management）サーバ／クライアント４とが接続されている。

ホスト機器２は、ＮＦＥ１を結合し、ＤＲＭサーバ、ＤＲＭクライアント、及びウェブクライアントとして機能する。そして、ホスト機器２は、ウェブサーバ３から情報の提供を受け、また、ＤＲＭサーバ／クライアント４に対しコンテンツを送受信する。

ウェブサーバ３は、ＨＴＴＰ（HyperText Transfer Protocol）に則り、クライアントソフトウェアのウェブブラウザに対して、ＨＴＭＬ（HyperText Markup Language）や画像などのオブジェクトの表示を提供するサービスプログラムを実行する。

ＤＲＭサーバ／クライアント４は、サーバ機能としてクライアントに対してＤＲＭ再生キーを発行し、また、ＤＲＭによる暗号化をＤＴＣＰ−ＩＰ（Digital Transmission Content Protection over Internet Protocol）による暗号化に変換する。

続いて、ＮＦＥ１及びホスト機器２の各構成について説明する。

ＮＦＥ１は、ネットワークに接続するネットワーク接続部１１と、バスに接続し、データ及び制御情報を送受信するバス接続部１２と、コンテンツを暗号化し、又は暗号化コンテンツを復号する暗号復号処理部１３とを備えている。

ネットワーク接続部１１は、例えば、イーサネット（商標）規格のＬＡＮ（Local Area Network）に有線又は無線により接続する。イーサネットは、ＯＳＩ（Open Systems Interconnect）参照モデルにおける物理層及びデータリンク層を規定する。イーサネットでは、元の送信すべき通信データをまず一定の長さ以下に分割して、ＭＡＣフレーム（Media Access Control Frame）を作成し、ＭＡＣフレームの形で情報を伝送路に流す。

バス接続部１２は、例えば、ＰＣＩ（Peripheral Component Interconnect）バス等の汎用バスに接続され、ホスト機器２とデータ及び制御情報を送受信する。バスは、一つ以上の周辺機器（デバイス）を同時に接続することができる線又は線の組で、共有リソースとして扱われる。バスに接続されたデバイスは、いずれも規約に従った行動を強いられる。例えば、ＰＣＩバスに接続されたデバイスは、名称、機能チップの型と番号、優先ＩＲＱ（Interrupt ReQuest）ライン、ＤＭＡ（Direct Memory Access）能力などの情報をバスマスタに示さなければならない。また、ＰＣＩシステムは、一つのマスターと一つのスレーブとの間でだけデータ転送をする。マスターが会話を開始し、スレーブがデータ又はリクエストで応答する。

暗号復号処理部１３は、著作権保護技術(ＤＲＭ)により保護されるコンテンツを暗号復号処理する。例えば、ＤＴＣＰ−ＩＰでは、コンテンツを配信元（ＤＲＭサーバ）からダウンロードした時点で配信元固有のＤＲＭによる暗号化をＤＴＣＰ−ＩＰによる暗号化に変換する。これにより、家庭内ＬＡＮにあるＤＴＣＰ−ＩＰ対応のディジタル機器（ＤＲＭクライアント）に配信可能となる。

また、ＮＦＥ１は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＣＰＵ（Central Processing Unit）等を有する制御部を備え、後述する組み込みソフトウェアを実行する。これにより、ネットワーク接続部１１、バス接続部１２、及び暗号復号処理部１３の各機能の動作が最適化される。

ホスト機器２は、ＮＦＥ１とバスを介して物理的に接続されるデバイス接続部３１と、ＡＶ（Audio Visual）デコーダ３２とを備える。デバイス接続部３１は、例えば、ＰＣＩバス等の汎用バスに接続され、ＮＦＥ１とデータ及び制御情報を送受信する。ＡＶデコーダ３２は、例えば、Ｈ．２６４／ＡＶＣと呼ばれるＭＰＥＧ（Moving Picture Experts Group）方式符号化されたデータを復号する。

また、ホスト機器２は、グラフィカルユーザインタフェース（Graphical User Interface）等のＵＩ（User Interface）３３を提供する表示制御部と、光ディスク３４の情報記録又は情報再生を行う記録再生制御部とを備える。また、ホスト機器２は、ＲＯＭ、ＲＡＭ、ＣＰＵ等を有する制御部を備え、後述する組み込みソフトウェアを実行する。これにより、ウェブサーバ３から情報の提供を受け、また、ＤＲＭにより保護されたコンテンツの記録又は再生を行う。

次に、ＮＦＥ１及びホスト機器２の制御部にて実行されるソフトウェアについて説明する。ここで、ソフトウェアは、上位層から順番にユーザプログラム、ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層で構成されているものとする。なお、以下、ＯＳ（Operating System）としてＬｉｎｕｘ（商標）を想定して説明するが、これに限られるものではなく、Ｗｉｎｄｏｗｓ（商標）などのＯＳを用いても構わない。

ユーザプログラムの階層は、ＤＲＭアプリケーション３０、ウェブブラウザ４５、ＤＲＭ機能付きＢＤ（Blu-ray Disc（登録商標））のライティングソフト４６等で構成される。ユーザプログラムは、送信対象となる元データを用意して下位層へと渡す。元データは、送信側と受信側とで同一プロトコルに従って処理され、そのプロトコルに応じたデータ処理が下位層で実施される。

ソケットインターフェース２６，４４は、論理的な通信口であり、データの送受信を行うための仮想的な経路の確立や解放を行う。

プロトコルスタックの階層は、ＩＰ（Internet Protocol）２４，４２、netfilter２３、ＴＣＰ（Transport Control Protocol）２５，４３等で構成される。プロトコルスタックの階層は、ＴＣＰ／ＩＰ通信を行うための主要部で、相手側とのコネクションの管理、データパケットの生成、タイムアウト、再処理などを行う。また、渡されたデータに対して、ＭＡＣヘッダやＩＰヘッダの付加を行う。

デバイスドライバの階層は、イーサネットドライバ２１，２２，４１、ＤＲＭドライバ２９等で構成される。イーサネットドライバ２１はネットワーク接続部１１を、イーサネットドライバ２２はバス接続部１２を、イーサネットドライバ４１はデバイス接続部３１を、ＤＲＭドライバ２９は暗号復号処理部１３をそれぞれ制御する。

本実施の形態では、ＮＦＥ１とホスト機器２の両側に、両者間の通信を行うイーサネットドライバ２１、４１を実装する。このネットワークデバイスドライバは、カーネルインターフェースを持つデバイスドライバとして実装され、ＮＦＥ１及びホスト機器２のぞれぞれのＩＰ層の下位レイヤとして働く。このようにＮＦＥ１とホスト機器２と間のＰＣＩバスの通信を行うためのデバイスドライバを、両アプリケーション用の専用ドライバの代わりに、イーサネットデバイスドライバの形式で実装することで、両アプリケーションは中間層として、ソケットインターフェース、ＮＡＰＩ（New API）などを利用することができる。ＮＡＰＩは、ネットワークに高負荷が掛かった時点でドライバの動作を割り込み駆動からポーリング駆動に切り替えることで、ネットワーク負荷に伴うシステム全体の応答性能の低下を防ぐことができる。

ホスト機器２のウェブブラウザ４５とウェブサーバ３とが通信する場合、ホスト機器２は、ソケットインターフェース４４、ＴＣＰ４３、ＩＰ４２、イーサネットドライバ４１の各層、及びデバイス接続部３１を介してＰＣＩバス通信を行う。そして、ＮＦＥ１側では、ＰＣＩバス、バス接続部１２、イーサネットドライバ２１、netfilter２３、イーサネットドライバ２２、及びネットワーク接続部１１を介してウェブサーバ３とホスト機器２とが通信する。

ここで、netfilter２３等の機能によりＩＰパケット転送、ＩＰアドレス変換等が行われる。ＩＰパケット転送機能としては、例えばLinuxのnetfilter２３/IPTABLES２７を利用することができる。これによってホスト機器２は、外部のネットワークと通信することができる。また、netfilter２３等のＮＡＴ(Network address transration)機能を利用することで、ホスト機器は、固定のプライベートＩＰアドレスを用いて外部ネットワークと通信することができる。また、外部向けのＩＰアドレスをホスト機器２に通知したり、ホスト機器２からＮＦＥ１側を設定する必要がある場合でも、上述のような仮想ネットワークの通信を通じて簡単に行うことができる。また、ＩＰフィルタリング機能など用いることにより、ＮＦＥ内にセキュリティー機能等を実装することができる。

ホスト機器２のＤＲＭ機能付きＡＶデコーダ３２やライティングソフト４６とＤＲＭサーバ／クライアント４とが通信する場合、ホスト機器２は、ソケットインターフェース４４、ＴＣＰ４３、ＩＰ４２、イーサネットドライバ４１の各層、及びデバイス接続部３１を介してＰＣＩバス通信を行う。ＮＦＥ１側では、ＰＣＩバス、バス接続部１２、イーサネットドライバ２１、ＩＰ２４、ＴＣＰ２５、ソケットインターフェース２６を介してＤＲＭアプリケーション３０とホスト機器２とが通信する。そして、ＤＲＭアプリケーション３０、ＤＲＭドライバ２９、暗号復号処理部１３によってコンテンツデータの暗号化又は復号化が行われる。

ここで、ＤＲＭアプリケーション３０がマルチプロセスアプリケーションであることなどから、ソケットインターフェース２６の使用部分をカーネルモードドライバ内に遮蔽して、ＤＲＭ通信を行う仮想デバイスドライバ２８とすることができる。これにより、カーネルオブジェクトを使った相互排除などが簡単に行うことができる。

また、ＮＦＥ１のＤＲＭアプリケーション３０は、ソケットインターフェース２６、ＴＣＰ２５、ＩＰ２４、netfilter２３、イーサネットドライバ２２、及びネットワーク接続部１１を介してＤＲＭサーバ／クライアント４と通信する。

このようにＰＣＩ等の汎用バスで結合されるＮＦＥ１とホスト機器２の両側に、データリンク層インターフェース用デバイスドライバをイーサネットデバイスドライバとして実装し、ＮＦＥ１内にＩＰ転送、ＮＡＴなどの機能を持たせる。これにより、ＮＦＥ本来のＤＲＭオフロード機能と、汎用ネットワークアクセスを両立し、効率的にホスト機器２に提供することができる。すなわち、ＤＲＭアプリ間の通信と汎用ネットワークアクセスとを簡単に両立することができる。

［２．通信方法］
次に、ネットワークデバイスドライバの通信について説明する。ここでは、先ず、一般的なイーサネット通信について説明し、続いて、ＤＭＡ転送について説明する。

［２−１．イーサネット通信］
ネットワークデバイスドライバは、ネットワーク用のプロトコルスタックの下位レイヤとしてソフトウェアの最下層に位置し、上位のプロトコルレイヤからのデータ、または物理層のデバイスからのデータをその間で受け渡しをする。Ｌｉｎｕｘでは、ソケットバッファ（ＳＫＢ）によりネットワークデバイスドライバと上位のプロトコルレイヤとの間で、データの受け渡しを実現する。

上位のプロトコルから渡される、又は上位に渡すバッファには、Ｌｉｎｕｘ独自のフォーマットがあり、このバッファのことをソケットバッファと呼ぶ。ソケットバッファは構造体で、データ部分と属性を保持するメンバからなる。ドライバで行うデータフローは、このソケットバッファとデバイス間でのデータ移動が主たる仕事になる。

ソケットバッファの保持する情報で、ネットワークデバイスドライバにとって重要なものは、ヘッダポインタ（head）、データポインタ（data）、テイルポインタ（tail）である。ヘッダポインタは、ソケットバッファが保持するフレームヘッダの先頭に当たる。また、データとは、フレームのデータの先頭を指し、テイルとは、ソケットバッファが保持するフレームの最後を指す。これらのポインタを操作することで、送信するデータ又は受信したデータの長さを指定し、シンプルなインターフェースを実現する。

図２Ａ及び図２Ｂは、イーサネットの通信方法を示す図である。送信する際には、図２Ａに示すように上位のＩＰレイヤでイーサネットのフレームが作成される。ネットワークデバイスドライバは、デバイス上の送信バッファに空きがあるか否かを調べ、空きがない場合、そのデータは後で処理することをマークする。空きがある場合、フレームをデバイスにコピーし、送信要求をデバイスに対して出す。ネットワークデバイスは、送信完了、またはエラーのときにドライバへの割り込みを発生させる。

一方、受信の際には、図２Ｂに示すようにデバイス上にフレームが受信されたとすると、デバイスによりネットワークデバイスドライバへの割り込みが発生する。ネットワークデバイスドライバは、その割り込みにより受信ＳＫＢを確保し、ＰＨＹ受信バッファからのフレームを受信ＳＫＢにコピーする。コピーの後、そのフレームを上位のプロトコルへと渡し、受信が完了する。

本実施の形態では、ＮＦＥ１とホスト機器２の両者は近接して直結されており、外来ノイズなどの影響を無視できる環境とすることができる。例えば、ＩＰヘッダ、ＴＣＰなどの各種チェックサム計算を省くことができる。これらはカーネルに対してチェックサムを用いないと宣言することなどで、容易に実現することができる。

また、ＮＦＥ１とホスト機器２の両者は近接して直結されているため、ソケットバッファや、パケットのサイズを可能なかぎり大きくして、単位バイトあたりのネットワーク処理に要するＣＰＵ負荷を低減することができる。一般に、パケットの通過するネットワーク上のハブ、ルーターなどの機器や相手のホスト機器が扱えるサイズの上限を定める必要から、実際の実ネットワークインターフェースには、経験的にＭＴＵ（Maximum Transmission Unit）として１５００バイト等の値が用いられている。しかし、本実施の形態では、外来ノイズなどの影響を無視できる環境とすることができるため、カーネル資源の許す限りＭＴＵを巨大化することができる。

このようにＮＦＥ１とホスト機器とを結合するネットワークデバイスドライバを実装することにより、それ自体がＣＰＵ負荷となることを防止し、さらにホスト機器２のネットワーク処理負荷を軽減させることができる。

［２−２．ＤＭＡ転送］
また、本実施の形態では、ＮＦＥ１とホスト機器２とが直結しているため、ＤＭＡ転送により自ら設定したＭＴＵを超える送受信を行うことが可能である。ＤＭＡ機能とは、ＤＭＡコントローラがバスに付随するメモリ空間上の特定のアドレスから、同じバスに付随するメモリ空間上の特定のアドレスへのデータ移動（データ転送）を、ＣＰＵの介在なしに行うものである。

後述するＤＭＡ処理の際には、データ転送に関する属性情報であるデータ転送アドレスや転送サイズ等のディスクリプタ（descriptor：記述子）を、外部メモリのディスクリプタ格納領域からＤＭＡコントローラ内のＤＭＡレジスタブロックに読み込んで、メモリ領域との間のデータ転送を制御する。ＤＭＡが起動されると、ＤＭＡコントローラは、ＤＭＡレジスタブロックに書き込まれたデータ（メモリアドレス及び転送データサイズ）を読み出し、メモリ領域の転送元アドレスから転送データサイズ分のデータを読み出し制御して、ＰＣＩバスを介し、転送先のメモリに送る。

Ｌｉｎｕｘ等のカーネルには、通常、ＴＳＯ(TCP Segmentation offloading)をサポートするとの宣言を行うフラグ等が用意されている。こうすることで、カーネルは、ＭＴＵサイズを越えるソケットバッファをイーサネットデバイスドライバに渡して、このイーサネットデバイスドライバにそれを分割送信させることができる。

また、ホスト機器２側のイーサネットデバイスドライバは、ＴＳＯをサポートするとカーネルに宣言し、実際のＮＦＥ１への送信時において、ＭＴＵサイズを無視して分割処理（セグメント化）せずに送信を行うことができる。これにより、ＴＣＰチェックサム再計算やＤＭＡディスクリプタの再構築に要する単位バイト当たりのＣＰＵ負荷を軽減することができる。

また、ＮＦＥ１側のイーサネットデバイスドライバも、ＴＳＯをサポートするとカーネルに宣言し、実際のホスト機器２への送信時において、ホスト機器２側の処理と同様に、パケットの分割を行わずに送信することができる。

なお、ホスト機器２への送信時において、「外部ネットワークからnetfilterを経由してくる小さなパケット」を集めて１つの大きなパケットにすることも有効である。しかし、本来ＴＣＰ層の働きが必要なことなどから、現在のところnetfilterには、この機能が実装されていない。将来netfilterやイーサネットデバイスドライバが協調して、スキャッタ／ギャザーＤＭＡを利用して、これを行うときは、ＩＰヘッダ、ＴＣＰチェックサム再計算が必要となるので、ＤＭＡと同時に再計算できるハードウェアを利用する。

また、特にＮＦＥ１側のイーサネットドライバには、セグメント化をＮＦＥ１とホスト機器２との間の通信と同時に一度に行うようにしてもよい。ホスト機器２からの受信時においては、外部向けの実ネットワークインターフェースのＭＴＵに合わせて、パケットの分割を行う。具体的には、ＰＣＩバスを介した受信時に同時に、スキャッタ／ギャザーＤＭＡを使い、ＤＭＡディスクリプタの生成などの簡単な処理で、受信と同時にパケットを分割する。このとき、ＩＰヘッダ、ＴＣＰチェックサム再計算が必要となるので、ＤＭＡと同時に再計算できるハードウェアを利用する。

次に、ＤＭＡ転送について詳細に説明する。図３は、ＮＦＥとホスト機器とのバス通信の構成例を示すブロック図である。この構成例は、ＮＦＥ制御部５０と、ホスト制御部６０とがＰＣＩバスで接続されている。ＮＦＥ制御部５０は、プロセッサ５１と、ローカルメモリ５２とがローカルバスで接続され、プロセッサ５１で実行されたディスクリプタに基づいてローカルメモリ５２にデータを格納する。このようなプロセッサ５１として、例えばFreescale Semiconductor社のPowerPCプロセッサ「MPC8349」を使用することができる。また、ホスト制御部６０も、ＮＦＥ制御部５０と同様に、プロセッサ（ホストＣＰＵ）６１と、ローカルメモリ６２とがローカルバスで接続されている。

また、図４は、ＤＭＡディスクリプタの記述例を示す図である。ホスト制御部６０からＮＦＥ制御部５０へデータを転送する場合、ＣＰＵコア５１ａがＤＭＡコントローラ５１ｂにＤＭＡディスクリプタ５２ａのアドレスを通知し、ＤＭＡ開始を要求する。ＤＭＡコントローラ５１ｂは、ＤＭＡディスクリプタを読み出し、ソースアドレス、及びディスティネーションアドレスに基づいてローカルメモリ６２のデータソース６２ａのデータをローカルメモリ５２のデータディスティネーション５２ｂに移動させる。転送完了後、ＤＭＡコントローラ５１ｂは、ＤＭＡディスクリプタに記述された次のディスクリプタアドレスに基づいて、次のＤＭＡディスクリプタを読み出す。

なお、図３に示す例では、ディスクリプタをＮＦＥ制御部５０側のローカルメモリ５２に持っているが、ホスト制御部６０側のローカルメモリ６２に持ってもよい。この場合、ＤＭＡ開始時にディスクリプタの位置としてローカルメモリ５２のアドレスではなく、ホスト制御部６０側のローカルメモリ６２内のアドレスを指定すればよい。

本実施の形態では、ＰＣＩ通信をネットワーク通信に見せかけるため、ホスト制御部６０側は、ローカルメモリ６２上にＰＣＩ通信用ＤＭＡディスクリプタではなく、ネットワーク通信用ＴｘＢＤ／ＲｘＢＤ（Ｔｘ／Ｒｘバッファディスクリプタ）を作成し、通常のイーサネットデバイスドライバに近い形で実現する。一方、ＮＦＥ制御部５０は、ローカルメモリ５２上にＰＣＩ通信用ＤＭＡディスクリプタを作成し、自分のバッファのアドレスは、自身でそれを書く。ホスト側のローカルメモリ６２のアドレスは、ホスト制御部６０が作成したＴｘＢＤ／ＲｘＢＤを読み出して書く。これによりＮＦＥ側のデバイスドライバは、ホスト側イーサネットデバイスドライバと矛盾なく処理（ＰＨＹの動作を模倣）する一方、ホスト制御部６０のネットワーク層とも整合を取りつつ、ＤＭＡ処理を行うことができる。

ここでは、先ず初期化処理を説明し、続いてシンプルＤＭＡ転送及びマルチプル転送について説明する。

図５Ａ及び図５Ｂは、ＤＭＡ転送の初期化処理を示す図である。ホスト制御部６０側のプロセッサ６１がＰＣＩマスターで、ＮＦＥ制御部５０側のプロセッサ５１がスレーブである。すなわち、ＮＦＥ１のＤＭＡコントローラ５１ｂにＤＭＡを仕掛ける。なお、以下では、ホスト制御部６０側のプロセッサ６１をＩＯＰ（入出力プロセッサ）と呼び、ＮＦＥ制御部５０側のプロセッサ５１をＮＦＥと呼ぶ。

図６は、ＤＭＡディスクリプタ定義の記述例を示す図である。このＤＭＡディスクリプタ定義によれば、「Next desc」を用いることにより、リングバッファを構成することができる。また、ＤＭＡチェーンモードを用いることにより、効率よく転送することができる。

図７（Ａ）〜（Ｃ）は、Ｔｘ／Ｒｘバッファディスクリプタ定義の記述例を示す図である。このＴｘ／Ｒｘバッファディスクリプタ定義によれば、Ｔｘ／ＲｘバッファディスクリプタはＩＯＰ側に構成し、ＮＦＥ側がＰＣＩバス経由で読み書きする。

ここで、ＮＦＥからＩＯＰへは、outbound doorbell -> INTAで通知し、メッセージの種類はdoorbellの番号で区別する。また、ＩＯＰからＮＦＥへは、inbound doorbellで通知し、割り込みの種類はdoorbellの番号で区別する。

また、図８は、ＩＯＰの固有データの一例を示す図であり、図９は、ＮＦＥの固有データの一例を示す図である。初期化時において、ＩＯＰは、図８に示すようなＩＯＰ固有データに基づいてＴｘバッファディスクリプタを確保し、ＮＦＥは、図９に示すようなＮＦＥ固有データに基づいて、受信用固定ＤＭＡディスクリプタリングバッファを確保する。このリングバッファは、ＩＯＰからはアクセスされない。

ＩＯＰは、確保したＴｘバッファディスクリプタのアドレスをＮＦＥに通知し、ＮＦＥがＩＯＰのＴｘバッファディスクリプタを読み出し、これを完成させる。また、ＮＦＥは送信用固定ＤＭＡディスクリプタリングバッファを確保し、割り込みメッセージである初期化要求（out door->INTA）をＩＯＰに通知する。ＩＯＰは、割り込みメッセージの初期化（in msg）をＮＦＥに通知し、Ｒｘバッファディスクリプタを確保する。ＮＦＥは、初期化（in msg）に対して、「Set remote_tx/rx_base」をセットし、初期化完了（out door->INTA）をＩＯＰに通知する。以上により初期化が完了する。

図１０Ａ及び図１０Ｂは、シンプルＤＭＡ転送の処理を示す図である。ここで、ＩＯＰのドライバのfeature設定において、NETIF_F_TSO,NETIF_F_SG,NETIF_F_FRAGLISTをＯＦＦとする。すなわち、カーネルにＴＳＯ（TCP Segmentation offloading）をサポートしないとの宣言を行う。

送信側の上位層のプロトコルは、受信ソケットバッファ（ＳＫＢ）を確保し、送信データを書き込み、ＩＯＰドライバに送信要求する。送信データには、ＳＫＢのdataポインタとサイズを含んでいる。

ＩＯＰドライバは、図１１（Ａ）に示すＩＯＰの固有データ例によりＴｘＢＤバッファを確保している。ＩＯＰドライバは、送信要求に対し、図１２に示すようにＳＫＢのdataポインタをＴｘＢＤバッファポインタとしてセットする。また、ＴｘＢＤにサイズをセットし、ＴｘＢＤのstatusを送信Ready状態にする。そして、ＩＯＰドライバは、ＤＭＡ開始指示を行い、送信要求完了を上位層に通知する。

一方、ＮＦＥのドライバは、図１１（Ｂ）に示すＮＦＥの固有データ例によりＤＭＡディスクリプタバッファを確保している。そして、ＤＭＡ開始指示を受け、ＩＯＰのディスクリプタを読み出し、ソースアドレスを取得する。

具体的には、ＩＯＰのＴｘＢＤstatusの送信Ready状態のものに対して、図１３に示すような設定を行う。ＩＯＰのＴｘＢＤからバッファポインタを読み出し、ＤＭＡディスクリプタのsrc addrにセットする。次に、初期化時に確保したＳＫＢポインタをＤＭＡディスクリプタのdst addrにセットする。次に、ＴｘＢＤから読み出したサイズをＤＭＡディスクリプタのlengthにセットし、次のＤＭＡディスクリプタへのポインタをnext descにセットする。そして、最後のＤＭＡディスクリプタのnext descにEOTD flagを立てる。

次に、ＮＦＥのドライバは、他のＤＭＡ転送が行われていなければＤＭＡ転送が開始される。ここで、remote_tx->ready flag=1 & dirtyrx < cur_rxのすべてのＳＫＢを転送する。

転送終了後、ＩＰＩＣよりＤＭＡ完了がＮＦＥドライバに割り込み通知される。ＮＦＥドライバは、ディスクリプタを更新し(remote_dirtytx->status->ready)、ＩＯＰドライバに送信完了を通知する（remote_dirtytx=+N）。ここで、dirtyrx == cur_rx-1の場合は受信バッファを確保した後に通知する。

ＮＦＥドライバは、上位層のプロトコルにコピー完了通知を行う。ＮＦＥ側の上位層のプロトコルは、コピー完了通知を受け、受信用ソケットバッファからデータを受け取り、その後ソケットバッファを破棄する。ＮＦＥドライバは、破棄した分の受信用ソケットバッファを確保する。これらは、受信済みのすべてのソケットバッファについて繰り返し処理する。

ＩＯＰドライバは、ＮＦＥドライバから送信完了の通知を受けると、送信完了（dirtytx->status->ready = 0）のソケットバッファをすべて破棄する。

このようにシンプルＤＭＡ転送を行うことにより、１パケットのデータを１ＤＭＡディスクリプタとして送信し、ＰＣＩ通信をネットワーク通信に見せかけることができる。

次に、マルチプル転送について説明する。マルチプル転送では、１パケットのデータを複数ＤＭＡディスクリプタのchain modeで送信する。ＴＳＯ（TCP Segmentation offloading）がオンの場合、上位層から渡されるバッファは、１つの大きなバッファではなく、複数のFragmentバッファに分割されている。ただし、ＴＣＰ／ＩＰヘッダはＭＴＵを超える大きなバッファ全体で一つである。

図１４（Ａ）〜（Ｃ）は、Ｔｘ／Ｒｘバッファディスクリプタ定義の記述例を示す図である。このＴｘ／Ｒｘバッファディスクリプタは、ＩＯＰからＮＦＥへの情報伝達として利用するが、一部statusは対応しない。このＴｘ／Ｒｘバッファディスクリプタは、ＩＯＰ側に構成され、ＮＦＥ側がＰＣＩ経由で読み書きする。また、図１４（Ｂ）に示すようにＴｘＢＤにパケット終了フラグ(EOP)が追加される。

先ず、ＩＯＰのドライバのfeature設定において、ＴＳＯ,ＳＧ,ＦＲＡＧＬＩＳＴをＯＮとする。すなわち、カーネルにＴＳＯ（TCP Segmentation offloading）をサポートするとの宣言を行う。

このＴＳＯは、後述するように、例えば、ホスト機器２がＮＦＥ１内のＤＲＭアプリケーション３０と通信する場合（ユースケース１）と、netfilter２３を介してウェブサーバ３等と通信する場合（ユースケース２）とで、ＮＦＥ側のＳＫＢ受信バッファの大きさが異なる。

ユースケース１では、できるだけ大きいままＮＦＥ側のＤＲＭアプリケーションに渡したいので、ＴＳＯで渡されたデータサイズを受信バッファサイズとする。なお、あまりに大きなバッファを一気に確保することは逆にパフォーマンスの低下を招く場合もあるので、固定の上限値を設けてもよい。

また、ユースケース２では、Netfilter２３ではＭＴＵサイズの変更（分割、合体）は行わず、そのまま外部に転送したいので、ＭＴＵサイズを受信バッファサイズとする。すなわち、外部イーサネット通信のＭＴＵサイズとＰＣＩ通信のＭＴＵサイズとを同じ値に設定する。

送信側の上位層のプロトコルは、受信ソケットバッファ（ＳＫＢ）を確保し、送信データを書き込み、ＩＯＰドライバに送信要求する。送信データには、ＳＫＢのdataポインタとサイズを含んでいる。また、図１５に示すように、データは、fragmentに分割されている。

ＩＯＰドライバは、ＳＫＢの全データを転送するため、図１６に示す動作をＴｘＢＤの作成が完了するまで繰り返す。先ず、ＩＯＰドライバは、ヘッダ用ＴｘＢＤを作成する。具体的には、最初のＳＫＢ dataポインタからヘッダ情報を読み出し、別領域（headp）にコピーし、Headpのうちサイズ・チェックサムを分割後のパケットに合わせて書き換える。次に、HeadpをＴｘＢＤバッファポインタとしてセットする。そして、ＴｘＢＤにヘッダサイズをセットし、ＴｘＢＤのstatusを送信Ready状態にする。

次に、ＩＯＰドライバは、payload用ＴｘＢＤを作成する。具体的には、図１６に示すように以下の動作を分割後のパケットサイズ分のＴｘＢＤの作成完了まで繰り返す。先ず、最初のみrest_size=分割後パケットサイズとする。rest_sizeは分割後パケットデータのうち転送未終了分のサイズである。

ここで、fragの残データの方がrest_sizeより小さい場合、つまり、この分割後パケットのデータを完成させるには次のfragのデータが必要）場合、一つ前のＴｘＢＤにしかけたデータの次のアドレスをＴｘＢＤバッファポインタとしてセットする（大半は次のfragの先頭）。fragの残りのデータサイズをＴｘＢＤのlengthにセットし、ＴｘＢＤ statusを送信Ready状態にする。また、Rest_sizeからlengthを引く。

一方、fragの残データの方がrest_sizeより大きい場合、つまり、この分割後パケットの最後のＴｘＢＤの場合、一つ前のＴｘＢＤにしかけたデータの次のアドレスをＴｘＢＤバッファポインタとしてセットする（大半は次のfragの先頭）。そして、このfragの残りのデータサイズをＴｘＢＤのlengthにセットし、ＴｘＢＤ status送信Ready状態にすると共にEOP flagを立てる。また、Rest_sizeからlengthを引く。

このようにして分割後１パケット分の繰り返しが終了する。また、ＳＫＢ全データについて上述した転送を繰り返す。

次に、ＮＦＥの受信動作について説明する。ＮＦＥのドライバは、ＩＯＰのＴｘＢＤ statusの送信Ready状態のものに対して図１７に示すような処理を繰り返す。初回のみoffset=0とする。ここで、offsetは受信用ＳＫＢの使用済サイズである。

先ず、ＩＯＰのＴｘＢＤからバッファポインタを読み出し、ＤＭＡディスクリプタのsrc addrにセットする。また、初期化時などに確保したＳＫＢポインタ+offsetをＤＭＡディスクリプタのdst addrにセットする。次にＴｘＢＤから読み出したサイズをＤＭＡディスクリプタのlengthにセットする。そして、次のＤＭＡディスクリプタへのポインタをnext descにセットする（Offset+=length）。ＴｘＢＤ statusのＥＯＰがセットされていれば、offset=0とし、受信用ＳＫＢポインタを次に進める。このようにして最後のＤＭＡディスクリプタのnext descにEOTD flagを立てる。その後、ＤＭＡ開始指示を行う。

このようにＴＳＯ(TCP Segmentation offloading)をサポートするとの宣言をすることで、カーネルがＭＴＵサイズを越えるソケットバッファをイーサネットデバイスドライバに渡し、イーサネットデバイスドライバがそれを分割送信することができる。

次に、マルチプル転送における２つのユースケースについて説明する。上述したように、ホスト機器２がＮＦＥ１内のＤＲＭアプリケーション３０と通信する場合（ユースケース１）と、netfilter２３を介してウェブサーバ３等と通信する場合（ユースケース２）とで、ＮＦＥ側のＳＫＢ受信バッファの大きさが異なる。

ホスト機器２がＮＦＥ１内のＤＲＭアプリケーション３０と通信する場合（ユースケース１）は、できるだけＤＭＡ単位を大きくして一気に転送することが望まれる。

ＭＴＵサイズ ≦ ＤＭＡ転送サイズ ≦ ＴＳＯデータサイズ

ここで、ＤＭＡ転送サイズはＤＭＡｃｈａｉｎｍｏｄｅで連結された合計の転送サイズである。なお、１つのＤＭＡディスクリプタで転送されるサイズはこれより小さい。

通常、イーサネットデバイスドライバの受信バッファサイズは、ＭＴＵサイズによって決まるが、この場合、転送サイズがＭＴＵサイズを超えるため、通常の方法では十分なサイズの受信バッファを確保できない。そこで、これに対応するためにイーサネットデバイスドライバは、ＭＴＵサイズではなく、ＴＳＯのデータサイズを使って受信バッファを確保する。ただし、あまりに大きなバッファを一気に確保することは逆にパフォーマンスの低下を招く場合もあるので、固定の上限値を置いても構わない。

一方、ホスト機器２がnetfilter２３を介してウェブサーバ３等と通信する場合（ユースケース２）は、外部通信側のイーサネットドライバのＭＴＵサイズに合わせてＴＣＰ／ＩＰヘッダを作成してＤＭＡ転送を行う。この場合、外部通信用イーサネットのＭＴＵサイズと同じＭＴＵサイズをＰＣＩ通信間ドライバにも設定する。これにより、受信側では通常の方法で（ＭＴＵサイズを元に）受信バッファサイズを決定すればよいため、ホスト機器２側で外部通信用イーサネットデバイスドライバまで大きなデータサイズで渡すことができる。なお、ＴＣＰ／ＩＰヘッダは、ＮＦＥ１側で付与してもホスト機器２側で付与してもよい。また、チェックサム計算などを行うハードウェア等を利用して、より高速化させてもよい。

上述した２つのユースケース１、２を同時に実現する場合には、それぞれのユースケースに対応する２組のドライバを実装し、ＮＦＥ１とホスト機器２の両側でそれぞれネットワークインターフェースを２つ持つことで使い分けることができる。

具体的には、下記の４つのドライバを実装する。
ホスト機器側ドライバ iop1(for UseCase1), iop2(for UseCase2)
ＮＦＥ側ドライバ nfe1(for UseCase1), nfe2(for UseCase2)

これらをＬｉｎｕｘにインストールすると、インターフェースが２つ追加される。例えばもともと下記の２つのインターフェースしかないとする。
> ifconfig
eth0 XXXXXXX（通常のetherインターフェース）
lo0 YYYYYY （local loopインターフェース）

これにユースケース１、２用のドライバを実装する。
> insmod iop1.ko
> insmod iop2.ko
> ifconfig eth1 AAA.AAA.AAA.AAA
> ifconfig eth2 BBB.BBB.BBB.BBB
> ifconfig
eth0 XXXXXXX（通常のetherインターフェース）
eth1 AAAAAAA（UseCase1用PCI通信インターフェース）
eth2 BBBBBBB（UseCase2用PCI通信インターフェース）
lo0 YYYYYY （local loopインターフェース）

また、ＮＦＥ側にも同様にユースケース１、２用のドライバを実装する。そして、eth1，eth2にそれぞれ異なるネットワークＩＰアドレスを割り当てることで、ユースケース１、２の使い分けを簡単に実現することができる。

すなわち、ユースケース毎にネットワークデバイスドライバを両側それぞれ実装し、ホスト機器２が各ネットワークデバイスドライバの仮想インターフェースに割り当てられたネットワークＩＰアドレスを指定することで、ネットワークに接続された外部機器との通信と、暗号復号アプリケーションとの通信とを選択することができる。

以上説明したように、ＮＦＥが特定のネットワーク機能、ＤＲＭ機能を代行するため、ホスト機器におけるネットワーク処理やＤＴＣＰ−ＩＰ、ＭａｒｌｉｎなどのＤＲＭ(暗号)の符号化、復号化、変換などに要するメインＣＰＵの負荷を低減させることができる。したがって、高速化処理が実現し、ハイビジョンコンテンツの複数同時処理などを行えるようになる。

また、ホスト機器は、実ネットワークデバイスのためのドライバ等を備えなくても，仮想ネットワークインターフェースを通じて、外部との汎用ネットワーク通信と、ＤＲＭ通信とを同時に行うことができる。

また、ＮＦＥは、ホスト機器から一般的なＮＩＣ(ネットワークカード)に見え、あるいは似ているように、ハードウェア(レジスタ構成等)、及びＮＦＥ側ソフトウェアを構成することができる。これによって、ホスト側のドライバは、通常のネットワークカード用ドライバと似たような構成とすることができ、コード流用が図れるため、開発コストを下げることができる。

以上、実施形態の一例を示したが、上述の実施形態に限定される物ではなく、この発明の技術的思想に基づく各種の変形が可能である。例えば、上述した実施の形態では、汎用バスとしてＰＣＩバスを用いることとして説明したが、例えば、ＩＳＡ（Industry Standard Architecture）バスやＥＩＳＡ（Extended Industry Standard Architecture）バスを用いても構わない。また、ＮＦＥに複数のネットワークＩＦを持ち、ルーティングを行わせるなど、独自の機能を複合的に持たせてもかまわない。

ネットワーク全体の構成例を示す図である。イーサネットの通信方法を示す図である。イーサネットの通信方法を示す図である。ＮＦＥとホスト機器とのバス通信の構成例を示すブロック図である。ＤＭＡディスクリプタの記述例を示す図である。ＤＭＡ転送の初期化処理を示す図である。ＤＭＡ転送の初期化処理を示す図である。ＤＭＡディスクリプタ定義の記述例を示す図である。Ｔｘ／Ｒｘバッファディスクリプタ定義の記述例を示す図である。ＩＯＰの固有データの一例を示す図である。ＮＦＥの固有データの一例を示す図である。シンプルＤＭＡ転送の処理を示す図である。シンプルＤＭＡ転送の処理を示す図である。ＩＯＰ及びＮＦＥの固有データの一部を示す図である。ヘッダ用ＴｘＢＤの作成処理を説明するための図である。ＴｘＢＤの作成処理を説明するための図である。Ｔｘ／Ｒｘバッファディスクリプタ定義の記述例を示す図である。ヘッダ用ＴｘＢＤの作成処理を説明するための図である。ＴｘＢＤの作成処理を説明するための図である。ＮＦＥの受信処理を説明するための図である。

符号の説明

１ＮＦＥ、２ホスト機器、３ウェブサーバ、４クライアント、１１ネットワーク接続部、１２バス接続部、１３暗号復号処理部、２１，２２イーサネットドライバ、２３ netfilter、２４ＩＰ、２５ＴＣＰ、２６ソケットインターフェース、２７ＩＰテーブル、２８仮想デバイスドライバ、２９ＤＲＭドライバ、３０アプリケーション、３１デバイス接続部、３２ＡＶデコーダ、３４光ディスク、４１イーサネットドライバ、４４ソケットインターフェース、４５ウェブブラウザ、４６ライティングソフト

Claims

ネットワークに接続し、パケットデータを送受信するネットワーク接続部と、
バスに接続し、データ及び制御情報をホスト機器に送受信するバス接続部と、
コンテンツを暗号化し、又は暗号化コンテンツを復号する暗号復号アプリケーションを実行する暗号復号処理部と、
ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行する制御部とを備え、
上記暗号復号アプリケーションは、上記ソケットインターフェースを介して上記ネットワーク接続部又は上記バス接続部と通信し、
上記制御部は、上記デバイスドライバとしてネットワークデバイスドライバを用いて、上記バス接続部のデータ及び制御情報の送受信を制御するネットワークアダプタ。
上記ソケットインターフェースと上記暗号復号アプリケーションとの間には、上記ソケットインターフェースを隠蔽する仮想デバイスドライバが介在する請求項１記載のネットワークアダプタ。
上記ネットワークデバイスドライバは、送信データをセグメント化して上記ホスト機器へ送信する請求項１記載のネットワークアダプタ。
上記ネットワークドライバは、ＴＳＯ（TCP Segmentation offloading）をサポートするとの宣言を行い、送信データをセグメント化せずに上記ホスト機器へ送信する請求項１記載のネットワークアダプタ。
上記ネットワークドライバは、１５００バイト以上のＭＴＵ（Maximum Transmission Unit）値を用いて上記ホスト機器と通信を行う請求項１記載のネットワークアダプタ。
ネットワークに接続し、パケットデータを送受信するネットワーク接続部と、バスに接続し、データ及び制御情報をホスト機器に送受信するバス接続部と、コンテンツを暗号化し、又は暗号化コンテンツを復号する暗号復号アプリケーションを実行する暗号復号処理部と、ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行するネットワーク制御部とを備えるネットワークアダプタと、
上記バスを介して上記ネットワークアダプタに接続するデバイス接続部と、ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行するホスト制御部とを備えるホスト機器とを有し、
上記暗号復号アプリケーションは、上記ソケットインターフェースを介して上記ネットワーク接続部又は上記バス接続部と通信し、
上記ネットワーク制御部及び上記ホスト制御部は、上記デバイスドライバとしてネットワークデバイスドライバを用いて、上記バス接続部と上記デバイス接続部との間のデータ及び制御情報の送受信を制御する通信装置。
上記ネットワーク制御部及び上記ホスト制御部は、それぞれ上記ネットワークデバイスドライバとして上記ネットワークに接続された外部機器通信用の第１のドライバと、上記暗号復号アプリケーション通信用の第２のドライバとを実装し、
上記ホスト制御部は、上記ネットワーク制御部に実装された第１のドライバ及び第２のドライバに割り当てられたネットワークＩＰアドレスを指定して上記外部機器の通信と上記暗号復号アプリケーションの通信とを選択する請求項６記載の通信装置。