ネットワークアダプタ及び通信装置
【課題】 汎用ネットワーク機能及びＤＲＭ機能を発揮し、ホスト機器の負担を軽減させる。
【解決手段】 ホスト機器２とＮＦＥ１との間のバス通信を行うためのデバイスドライバを、両アプリケーション用の専用ドライバのかわりに、ネットワークデバイスドライバの形式で実装し、両アプリケーションは、中間層として、ソケットインターフェース、ＮＡＰＩなどを利用する。
【解決手段】 ホスト機器２とＮＦＥ１との間のバス通信を行うためのデバイスドライバを、両アプリケーション用の専用ドライバのかわりに、ネットワークデバイスドライバの形式で実装し、両アプリケーションは、中間層として、ソケットインターフェース、ＮＡＰＩなどを利用する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＰＣＩ（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、 ２４ ＩＰ、 ２５ ＴＣＰ、 ２６ ソケットインターフェース、 ２７ ＩＰテーブル、 ２８ 仮想デバイスドライバ、 ２９ ＤＲＭドライバ、 ３０ アプリケーション、 ３１ デバイス接続部、 ３２ ＡＶデコーダ、 ３４ 光ディスク、 ４１ イーサネットドライバ、 ４４ ソケットインターフェース、 ４５ ウェブブラウザ、 ４６ ライティングソフト
【技術分野】
【０００１】
本発明は、ＰＣＩ（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、 ２４ ＩＰ、 ２５ ＴＣＰ、 ２６ ソケットインターフェース、 ２７ ＩＰテーブル、 ２８ 仮想デバイスドライバ、 ２９ ＤＲＭドライバ、 ３０ アプリケーション、 ３１ デバイス接続部、 ３２ ＡＶデコーダ、 ３４ 光ディスク、 ４１ イーサネットドライバ、 ４４ ソケットインターフェース、 ４５ ウェブブラウザ、 ４６ ライティングソフト
【特許請求の範囲】
【請求項１】
ネットワークに接続し、パケットデータを送受信するネットワーク接続部と、
バスに接続し、データ及び制御情報をホスト機器に送受信するバス接続部と、
コンテンツを暗号化し、又は暗号化コンテンツを復号する暗号復号アプリケーションを実行する暗号復号処理部と、
ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行する制御部とを備え、
上記暗号復号アプリケーションは、上記ソケットインターフェースを介して上記ネットワーク接続部又は上記バス接続部と通信し、
上記制御部は、上記デバイスドライバとしてネットワークデバイスドライバを用いて、上記バス接続部のデータ及び制御情報の送受信を制御するネットワークアダプタ。
【請求項２】
上記ソケットインターフェースと上記暗号復号アプリケーションとの間には、上記ソケットインターフェースを隠蔽する仮想デバイスドライバが介在する請求項１記載のネットワークアダプタ。
【請求項３】
上記ネットワークデバイスドライバは、送信データをセグメント化して上記ホスト機器へ送信する請求項１記載のネットワークアダプタ。
【請求項４】
上記ネットワークドライバは、ＴＳＯ（TCP Segmentation offloading）をサポートするとの宣言を行い、送信データをセグメント化せずに上記ホスト機器へ送信する請求項１記載のネットワークアダプタ。
【請求項５】
上記ネットワークドライバは、１５００バイト以上のＭＴＵ（Maximum Transmission Unit）値を用いて上記ホスト機器と通信を行う請求項１記載のネットワークアダプタ。
【請求項６】
ネットワークに接続し、パケットデータを送受信するネットワーク接続部と、バスに接続し、データ及び制御情報をホスト機器に送受信するバス接続部と、コンテンツを暗号化し、又は暗号化コンテンツを復号する暗号復号アプリケーションを実行する暗号復号処理部と、ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行するネットワーク制御部とを備えるネットワークアダプタと、
上記バスを介して上記ネットワークアダプタに接続するデバイス接続部と、ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行するホスト制御部とを備えるホスト機器とを有し、
上記暗号復号アプリケーションは、上記ソケットインターフェースを介して上記ネットワーク接続部又は上記バス接続部と通信し、
上記ネットワーク制御部及び上記ホスト制御部は、上記デバイスドライバとしてネットワークデバイスドライバを用いて、上記バス接続部と上記デバイス接続部との間のデータ及び制御情報の送受信を制御する通信装置。
【請求項７】
上記ネットワーク制御部及び上記ホスト制御部は、それぞれ上記ネットワークデバイスドライバとして上記ネットワークに接続された外部機器通信用の第１のドライバと、上記暗号復号アプリケーション通信用の第２のドライバとを実装し、
上記ホスト制御部は、上記ネットワーク制御部に実装された第１のドライバ及び第２のドライバに割り当てられたネットワークＩＰアドレスを指定して上記外部機器の通信と上記暗号復号アプリケーションの通信とを選択する請求項６記載の通信装置。
【請求項１】
ネットワークに接続し、パケットデータを送受信するネットワーク接続部と、
バスに接続し、データ及び制御情報をホスト機器に送受信するバス接続部と、
コンテンツを暗号化し、又は暗号化コンテンツを復号する暗号復号アプリケーションを実行する暗号復号処理部と、
ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行する制御部とを備え、
上記暗号復号アプリケーションは、上記ソケットインターフェースを介して上記ネットワーク接続部又は上記バス接続部と通信し、
上記制御部は、上記デバイスドライバとしてネットワークデバイスドライバを用いて、上記バス接続部のデータ及び制御情報の送受信を制御するネットワークアダプタ。
【請求項２】
上記ソケットインターフェースと上記暗号復号アプリケーションとの間には、上記ソケットインターフェースを隠蔽する仮想デバイスドライバが介在する請求項１記載のネットワークアダプタ。
【請求項３】
上記ネットワークデバイスドライバは、送信データをセグメント化して上記ホスト機器へ送信する請求項１記載のネットワークアダプタ。
【請求項４】
上記ネットワークドライバは、ＴＳＯ（TCP Segmentation offloading）をサポートするとの宣言を行い、送信データをセグメント化せずに上記ホスト機器へ送信する請求項１記載のネットワークアダプタ。
【請求項５】
上記ネットワークドライバは、１５００バイト以上のＭＴＵ（Maximum Transmission Unit）値を用いて上記ホスト機器と通信を行う請求項１記載のネットワークアダプタ。
【請求項６】
ネットワークに接続し、パケットデータを送受信するネットワーク接続部と、バスに接続し、データ及び制御情報をホスト機器に送受信するバス接続部と、コンテンツを暗号化し、又は暗号化コンテンツを復号する暗号復号アプリケーションを実行する暗号復号処理部と、ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行するネットワーク制御部とを備えるネットワークアダプタと、
上記バスを介して上記ネットワークアダプタに接続するデバイス接続部と、ソケットインターフェース、プロトコルスタック、及びデバイスドライバの各階層をなすソフトウェアを実行するホスト制御部とを備えるホスト機器とを有し、
上記暗号復号アプリケーションは、上記ソケットインターフェースを介して上記ネットワーク接続部又は上記バス接続部と通信し、
上記ネットワーク制御部及び上記ホスト制御部は、上記デバイスドライバとしてネットワークデバイスドライバを用いて、上記バス接続部と上記デバイス接続部との間のデータ及び制御情報の送受信を制御する通信装置。
【請求項７】
上記ネットワーク制御部及び上記ホスト制御部は、それぞれ上記ネットワークデバイスドライバとして上記ネットワークに接続された外部機器通信用の第１のドライバと、上記暗号復号アプリケーション通信用の第２のドライバとを実装し、
上記ホスト制御部は、上記ネットワーク制御部に実装された第１のドライバ及び第２のドライバに割り当てられたネットワークＩＰアドレスを指定して上記外部機器の通信と上記暗号復号アプリケーションの通信とを選択する請求項６記載の通信装置。
【図１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１０−６８１５５（Ｐ２０１０−６８１５５Ａ）
【公開日】平成２２年３月２５日（２０１０．３．２５）
【国際特許分類】
【出願番号】特願２００８−２３１５４６（Ｐ２００８−２３１５４６）
【出願日】平成２０年９月９日（２００８．９．９）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２２年３月２５日（２０１０．３．２５）
【国際特許分類】
【出願日】平成２０年９月９日（２００８．９．９）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]