説明

ネットワーク・プロトコル・スタック隔離のためのネットワーク・アーキテクチャ、方法、およびコンピュータ・プログラム(ネットワーク・プロトコル・スタック隔離)

【課題】オペレーティング・システムからネットワーク・プロトコル・スタックを隔離するための方法およびネットワーク・アーキテクチャを提供すること。
【解決手段】本ネットワーク・アーキテクチャは、コンシューマ・アプリケーションとメッセージを授受するように編成された入出力インターフェースを含む。このメッセージは、特定のプロトコル層による実行を対象とする高レベルの一般的なネットワーク装置コマンドを搬送し、当該プロトコルは、メッセージに関係する。本ネットワーク・アーキテクチャは、高レベルのコマンドを処理して実行するとともに、高レベルのコマンドから装置固有のコマンドを生成するように編成された隔離ネットワーク・プロトコル・スタックと、装置固有のコマンドを実行するように編成された入出力要素とをさらに含む。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般的には、コンピュータおよびプロセッサ・アーキテクチャの分野に関し、特に、オペレーティング・システムからネットワーク・プロトコル・スタックを隔離するための方法およびシステムに関する。
【背景技術】
【0002】
従来のネットワーキング・スタックにおいて、アプリケーションは、典型的には、システム・コールを呼び出すことによって、オペレーティング・システム(OS)からデータを転送することを要求する。OSは、典型的には、簡単なパケット・ベースのインターフェースを使用するネットワーク・アダプタと相互に作用する。このモデルは、例えば、コンテキスト切り替え、割り込み処理、メモリ・コピー、およびOSの内部構造管理などに関して高いオーバヘッドを課す。高速ネットワークに関して、全体的なネットワーキング・オーバヘッドは、典型的には、中央処理装置(CPU)によるアプリケーション処理のための時間よりも遥かに高い。
【0003】
他の問題は、現在のコンピュータ・システムの頑強さに関する。典型的には、各デバイス・ドライバは、OSカーネルにおいて信頼できるエンティティとして実行される。OSカーネル、スタック、およびデバイス・ドライバはすべて、同一の保護およびリソース・ドメインにおいて実行される。したがって、ドライバの品質がシステムの信頼性に影響を与え、その結果、システムは多少複雑となり、試験および調整が難しくなる。
【0004】
iSCSI(インターネット小型コンピュータ・システム・インターフェース)アダプタおよびRDMA(リモート・ダイレクト・メモリ・アクセス)アダプタなどのオフロード・アダプタは、上述の問題に対処しようとするものであって、データ・パスについてのTCP/IPプロトコルの処理(すなわち、他のIP関連のプロトコルまたはTCPコネクションの確立を含まない)をアダプタへ移動させることによって、コンピュータ・システムのパフォーマンスを改善しようとしている。しかしながら、そのようなオフロード・アダプタは、典型的には、上述のネットワーク・アダプタの簡単なパケット・ベースのインターフェースとは異なるアプリケーション・データ転送インターフェースに対して直接さらされる。例えば、RDMAアダプタであるRNICは、コンシューマ・アプリケーションに対してRDMAサービスを提供するネットワーク・インターフェース・カードであり、アプリケーションがOSを迂回してハードウェア構成要素とデータを直接的に授受することを可能にする非同期のインターフェースを提供することにより、上述のオーバヘッドの問題をいくらか解消する。
【発明の開示】
【発明が解決しようとする課題】
【0005】
このアプローチに伴う問題の1つは、そのようなオフロード・アダプタは、典型的には、カスタム・ハードウェアまたは埋め込みマイクロコードのいずれにおいても、トランスポート制御プロトコル(TCP)処理の全てまたはそのほとんどをアダプタ上で行うということである。したがって、ハードウェア・ベースでの解決のためには、このプロトコルの実装は十分に柔軟性があるわけではない。なぜなら、例えば、TCP輻輳制御アルゴリズムは、絶えず進化しており、一般的に、OSに関し提供されたTCP実装は頻繁に変更されるからである。さらに、マイクロコード・ベースでの解決のためには、パフォーマンスは、典型的には、埋め込みプロセッサの性能によって限定され、典型的には、ホストCPUに後れを取る。
【0006】
このアプローチに伴う他の問題は、新しい種類の装置機能が導入されるために、入出力スタックの構造がさらに複雑化することである。例えば、新規の装置は、ソフトウェアおよびハードウェア間でTCP処理を分割する互いに異なるモデルを使用することがあり、その結果、入出力スタックによって異なる処理が必要となる。
【0007】
上述の問題を容易にする他の試みは、複数のOSイメージ間で単一の物理アダプタを共有することである。このアプローチは、典型的には、仮想化または区画化されたシステム(例えば、物理マシンが、メモリなどのリソースの区画化を使用して複数のオペレーティング・システムの外観と機能とを提供するもの)において必要である。また、典型的には、別個のノードを介してイーサネット接続性が提供される高速ローカル・エリア・ネットワーキング・システムによって接続されたマシンのクラスタや、入出力ノードを共有するブレード・サーバのようなマシンのクラスタにおいて必要となることもある。
【0008】
従来技術によれば、アダプタの共有は、上述の共有アダプタの両方の種類については困難である。なぜなら、ハードウェアおよびソフトウェアが複雑となるばかりか、またはパフォーマンスのオーバヘッドが増加するからである。複数のOSをサポートするためには、共有アダプタは、典型的には、各OSが別個の仮想アダプタを使用できるように、複数の仮想アダプタ・インターフェースを提供しなければならない(すなわち、単一の物理アダプタが、複数の独立したアダプタとして見えるように振舞う)。このアプローチによれば、例えば、レジスタ/キュー/などがさらに必要となり、仮想インターフェース間のアービトレーションが複雑となるなど、アダプタの実装が複雑となる。
【0009】
他のアプローチは、ソフトウェア仲介構成要素を通じて既存のアダプタを「仮想化」することにより、OSに対して別個のアダプタ・インターフェースの幻影を提供することである。この場合、各動作がこの仲介を通じて行われるため、パフォーマンス・オーバヘッドが増加する。
【課題を解決するための手段】
【0010】
本発明は、少なくとも1つのコンシューマ・アプリケーションと少なくとも1つのオペレーティング・システムによって使用されるネットワーク・アーキテクチャを提供する。
【0011】
本ネットワーク・アーキテクチャは、コンシューマ・アプリケーションとメッセージを授受するように編成された入出力インターフェースを含む。これらのメッセージは、当該メッセージに関係する特定のプロトコル層による実行を対象とする高レベルの一般的なネットワーク装置コマンドを搬送する。本ネットワーク・アーキテクチャは、高レベルのコマンドを処理して実行するとともに、高レベルのコマンドから装置固有のコマンドを生成するように編成された隔離(isolated)ネットワーク・プロトコル・スタックと、装置固有のコマンドを実行するように編成された入出力要素とをさらに含む。
【0012】
また、本発明の他の実施形態に従って提供されるのは、隔離ネットワーク・プロトコル・スタックを使用してコンシューマの入出力要求を実行するためのコンピュータで実施される方法である。
【0013】
本方法は、入出力要求を入出力インターフェースに書き込むステップと、入出力要求を入出力インターフェースから読み出すステップと、入出力要求に基づいて動作を開始するステップとを含む。動作が完了すると、入出力インターフェース上に応答が書き込まれ、そして、その応答を読み出すことができる。
【0014】
また、本発明の他の実施形態に従って提供されるのは、上述の方法を実施するように編成された、コンピュータ上で実行されるコンピュータ・プログラムである。
【発明を実施するための最良の形態】
【0015】
本発明の実施形態を、添付の図面を参照して説明する。
【0016】
概要
以下の詳細な説明において、本発明の完全な理解を提供するために、数多くの具体的な詳細を述べる。しかしながら、これらの具体的な詳細がなくても、本発明を実施できるは、当業者によって理解されるだろう。周知の方法、手順、および構成要素は、本発明を不明瞭にしないために、詳細には説明していない。
【0017】
本発明者は、「背景技術」の項で上述した問題に対処し、かつ現在の技術を改良するためには、以下に詳細に説明するように、ネットワーク・プロトコル・スタックを例えばオペレーティング・システム(OS)などのアプリケーション実行環境から切り離せばよいことに着目した。さらに、本発明者は、ネットワーク・プロトコル・スタック・サービスに対するアプリケーション/コンシューマのアクセスを可能にするために、命令セット・アーキテクチャ、入出力接続の種類および装置の詳細から独立していてもよい一般的な非同期要求‐応答プロトコルを定義した。本明細書を通じて使用される「ネットワーク」という用語は、ソフトウェアまたはハードウェアの形態で実現され、かつ使用される特定の種類のデータ・リンクとは独立した、アプリケーション・ソフトウェアに対する汎用ネットワーキング・サービスを提供するパッケージのことをいう。このプロトコルは、スタックの実際の位置に依存して、広範囲のトランスポートに渡って、広範囲のプラットフォーム上で使用することができる。上述のプロトコルを通じて提供されるネットワーク・サービスは、ネットワーク・プロトコル・スタックの互いに異なる層に対するアクセスを含み、パケット・ベースの媒体アクセス制御(MAC)インターフェースから始まって、例えばトランスポート制御プロトコル(TCP)またはユーザ・データグラム・プロトコル(UDP)などの互いに異なる種類のトランスポート・インターフェースから、例えばファイル・トランスポート・プロトコル(FTP)などの上層プロトコル・インターフェースまでを含む。
【0018】
システムの論理説明
まず、図1を参照して説明する。図1は、本発明の一実施形態に係るネットワーク・アーキテクチャの概略論理ブロック図である。
【0019】
本ネットワーク・アーキテクチャは、主CPU複合体上で実行可能なコンシューマ・アプリケーション10を含む。これらのコンシューマ・アプリケーション10は、OSサービスを介して、要求/応答メッセージ・セマンティックスを使用することにより、隔離ネットワーク・プロトコル・スタック20と相互に作用することができる。要求/応答メッセージング機構は、互いに異なる相互接続を使用して実現することができる。、例えば、コンシューマ・アプリケーション10およびスタック20が共にアクセス可能な共有メモリ内のメッセージ・キューを使用して実現することができる。要求/応答メッセージの形式および内容は、互いに異なる相互接続に依存しない。
【0020】
コンシューマ・アプリケーション10およびOSサービスからの太い矢印によって示す要求は、入出力インターフェース12を通して、ネットワーク・プロトコル・スタック20の互いに異なる層に関連する。例えば、これらの要求は、MAC層(例えば、イーサネット)、ネットワーク層(例えば、IPv4)、トランスポート層(例えば、TCP)、およびセッション層(例えば、iSCSI)の一部または全てに関連する。入出力インターフェース12は、例えば、どの層に要求が適用可能かを判断する。したがって、入出力インターフェース12は、以下に説明するように、コンシューマ・アプリケーション10からの入力要求を、スタック20へ転送すべき要求に変換する。また、入出力インターフェース12は、1つ以上のマシン上で実行可能な互いに異なる種類またはバージョンのOSからの入力要求を変換する。したがって、スタック20は、複数の異種コンシューマ・アプリケーション10およびOSによって共有することができる。
【0021】
これらの要求は、入出力インターフェース12を通じて隔離ネットワーク・プロトコル・スタック20へ転送され、その後、入出力機能30を介して、例えばネットワーク、ストレージ、周辺または他の構成要素などの各構成要素32が当該要求を処理する。その後、要求は、実行のために、入出力要素34へさらに転送される。スタック20に渡されうる要求は、入出力要素に独立であることに注意すべきである。
【0022】
MAC層に対するアクセスは任意であり、入力要求からの特殊な特権を必要とすることがある。
【0023】
各層について、サポートされている要求の例を以下に示す。
【0024】
データ転送要求:データ転送要求は、データ・バッファ位置および長さと、データ転送方向の指示に関する情報をとを提供する。言い換えれば、コンシューマ・アプリケーション10は、バッファ送信またはバッファ受信を書き込む。バッファ内のデータは、対応するスタック層のペイロードを保持することができる。MAC層については、MACヘッダを含むことができる。例えばIPなどのコネクションレス・プロトコルについては、送信要求は、受信者のアドレスを指定し、同様に、遠隔アドレス情報は、書き込まれた受信要求について受信されるデータと共に供給される。コネクション型のプロトコルについては、送信および受信要求は共に、データを転送すべきコネクションを指定する。追加の制御情報を各プロトコルについて指定することもできる。
【0025】
制御要求:例えば、
・MAC層においてサポートされたフレーム・フォーマットをget/set、
・TCPコネクションの開放および構成など
【0026】
各要求は、該当する「論理アダプタ」構成要素32を識別するための情報と、スタック20に対してトランスペアレントであってもよい要求IDとを含む。この要求IDは、対応する応答と共にコンシューマに渡し戻される。
【0027】
各要求が完了すると、その応答がコンシューマ・アプリケーション10に渡し戻される。各応答は、例えばワーク要求識別子などの元の要求を識別するのに必要な情報と、例えばエラー・コード、転送データの実際量などの該当ステータス情報とを含む。
【0028】
隔離ネットワーク・プロトコル・スタック20は、互いに異なるレベルのハードウェア的なサポートを使用して実現できることに注意すべきである。内部実装は、隔離ネットワーク・プロトコル・スタック20のサービスを使用する、アプリケーションまたはOSに対してトランスペアレントとすることができる。特に、例えば、互いに異なる種類のOSを搭載した、異種ネットワーク・システム上で、新しい種類のオフロード装置をサポートするためには、全てのOSの種類についてプロトコル変更を行う必要はない。
【0029】
システムの説明
図2を参照して説明する。図2は、本発明の実施形態に係るネットワーク・アーキテクチャの概略ブロック図である。上記のように、本ネットワーク・アーキテクチャは、主CPU複合体上で実行可能なコンシューマ・アプリケーション10を含む。コンシューマ・アプリケーション10は、要求/応答メッセージ・セマンティックスを使用して、隔離ネットワーク・プロトコル・スタック20と相互に作用する。要求/応答メッセージング機構は、例えばコンシューマ・アプリケーション10およびスタック20によってアクセス可能な共有メモリ内のメッセージ・キューを使用して実現することができる。コンシューマ・アプリケーション10は、入出力インターフェース12の一部であってもよい非同期キュー・ベースのインターフェース(ReqQ/RespQ)120を使用して、ネットワーク・プロトコル・スタック20と要求を授受することができる。1つ以上のReqQ/RespQインターフェース120は、複数のスタック20をアクセスするため、または各スタック20によって管理される複数のコネクションをアクセスするため、あるいはその両方をアクセスするために特定のコンシューマ・アプリケーション10によって使用することができる。ReqQ/RespQインターフェース120についてのさらなる詳細は、以下に詳述する。
【0030】
隔離ネットワーク・プロトコル・スタック20は、例えば、トランスポート制御エンジン(TCE)16と、上述の隔離ネットワーク・プロトコル・スタックのハードウェア的なサポートの一例であるストリーマ18要素とを含む。隔離ネットワーク・プロトコル・スタック20のこの実施例の機能を、まず簡単に説明する。
【0031】
TCE16は、汎用中央処理装置(CPU)上で実行されるソフトウェア・エンティティとすることができる。TCE16は、ネットワーク・プロトコル・スタック20を制御するが、データ移動を実質的に行わない。ストリーマ18は、データ移動タスクを加速させ、最小のトランスポート・プロトコル処理のみを行う、ハードウェア・エンティティとすることができる。ストリーマ18は、そのタスクを実行するために、埋め込みファームウェアを含むことができる。データの移動は、コンシューマ・アプリケーション10のために、TCE16によって構成される。ストリーマ18は、TCE16と非同期的に相互に作用する。例えば、TCE16の決定を待ってその動作を停止する必要はない。この機能により、スタック・プロトコルは、例えば、ホストまたはアプリケーションのCPUなどの主CPUに適合するように、スタック・プロトコルのスケーリングを行うことができる。なぜなら、当該機能を支援するハードウェアは、主CPUがより高速になった場合にボトルネックとなるような複雑な処理を含まないからである。
【0032】
ReqQ/RespQの非同期キュー・ベースのインターフェース120に戻って、実施例を以下に説明する。本発明の実施形態によれば、コンシューマ10は、隔離ネットワーク・プロトコル・スタック20と通信することができる。図2に示す例において、特定のコンシューマ10と、隔離ネットワーク・プロトコル・スタック20との間に単一の要求キュー120があってもよい。この要求キュー120は、例えば、コンシューマ10と通信するために(任意のアーキテクチャの)自身のネットワーク・スタックおよびこれらのスタックを使用するアプリケーションを有する他のコンピュータ・システムなどの遠隔ホストへの複数のコネクションにサービスするために使用することができる。キュー120を介して、隔離ネットワーク・プロトコル・スタック20に渡すことができるコマンドのフォーマットの例は、上記に定義されており、例えば、データ転送要求および制御要求である。ストリーマ18は、TCE16と協働して、ネットワーク加速セマンティックスをコンシューマ・アプリケーション10に対して提供することができる。ストリーマ18は、以下により詳細に説明するように、すべてのデータ集中動作を扱う役割を担う。
【0033】
簡単に上述したように、TCE16は、隔離ネットワーク・プロトコル・スタック20のプロトコル処理部分を実現するソフトウェア要素とすることができる。TCE16は、TCPプロトコルの判断部を実現する。例えば、TCE16は、主CPU、専用CPU、または専用仮想ホスト(区画)上で実行することができる。ストリーマ18およびTCE16は、非同期の二重キュー・インターフェース24を使用して、スタック20の2つの部分間で情報を交換する。二重キュー・インターフェース24は、2つの単方向キューを含むことができる。コマンド・キュー(CmdQ)を使用して、情報をTCE16からストリーマ18へ渡す一方、イベント・キュー(EvQ)を使用して、情報をストリーマ18からTCE16へ渡すことができる。ストリーマ18およびTCE16は、その間の動作をシリアル化または同期化する必要なく、非同期で動作することができる。本アーキテクチャは、ストリーマ18とTCE16との間の処理/インターフェース遅延に関して制限を課すことも、前提を設けることもしない。
【0034】
上記のように、隔離ネットワーク・プロトコル・スタック20と相互に作用するアプリケーションまたはコンシューマ10について、プロトコル処理を、専用かつ論理的に別個のTCE16のCPU上で行うことができる。TCE16は、対称型マルチプロセッサ・システム(SMP)上の物理的に別個のCPU、区画化されたマシン上の別個の区画、またはクラスタ内の別個のノードとすることができる。
【0035】
本実施形態によれば、データ転送のためのアプリケーション要求を、TCE16がコンシューマ・アプリケーション10に代わって処理した後(例えば、TCE16が、入出力インターフェース12の要求キュー120を介してストリーマ特有のインターフェースに受信されたアプリケーション要求を変換した後に)、当該アプリケーション要求をストリーマ18が処理することができる。加えて、TCE16は、セグメント損失または再要求されたセグメントのような、例外の発生時に要求の処理に関与することができる。送信側では、TCE16は、ストリーマ18に対して、データを再送信するように指示し、受信側では、TCE16は、ストリーマ18に対して、リアセンブリ・バッファ28からのデータを、入出力インターフェース12の要求キュー120におけるエントリによってポイントされたアプリケーション・バッファへ移動するように指示する。
【0036】
本発明のある実施形態によれば、隔離ネットワーク・プロトコル・スタック20は、アプリケーション・データ・バッファをアクセスを許可され、したがって、当該データは、スタック20と授受されるときにこれをコピーする必要がない。メモリ・アクセスを保護するための一方法は、本出願人に譲渡され且つ同日に出願された、「A METOD AND SYSTEM FOR MEMORY PROTECTION AND SECURITY USING CREDENTIALS」と題する米国特許出願(代理人整理番号IL920050027US1)に説明されている。
【0037】
図2に示すように、隔離ネットワーク・プロトコル・スタック20は、ネットワーキング・サービスを複数のOSイメージに対して提供することができる。これにより、OSの構成が簡素化され、従来技術のシステムによる各OSインスタンスに含まれる複数のネットワーク・プロトコル・スタックに関連するリソースを節約することができる。
【0038】
本発明のある実施形態によれば、隔離ネットワーク・プロトコル・スタック20は、互いの異なるレベルのアダプタ共有を提供することができる。例えば、スタック20が初期化される場合に、「仮想TCP装置」のような複数のコネクション型のプロトコル装置を確立または設定することができる。従って、スタック20は、互いに異なるプロトコル・レベルにおいて複数の仮想装置として見えることになる。システム特有のポリシーによれば、特定の装置に対する排他的なアクセスをいくつかのOSイメージに許可することができ、その結果、ある仮想TCP装置が得られることになる。他の場合には、単一の物理装置が複数の論理アダプタとして抽出され、仮想装置としての1つの論理アダプタに対する排他的なアクセスが、1つのOSに許可される。
【0039】
互いに異なるコネクション・オブジェクトおよび論理アダプタへの分離には、いくつかの方法がある。例えば、仮想LAN(VLAN)環境ではVLANタグを使用して、単一の物理アダプタを複数の仮想MAC装置として表わすことができる各MAC装置は、仮想的または物理的のいずれであろうと、当該MAC装置にバインドされた複数の仮想IP装置に関連付けることができるい。
【0040】
すべてのコネクション・オブジェクトおよび仮想装置は、例えば、本出願人に譲渡された「A METOD AND SYSTEM FOR PROTECTION AND SECURITY OF IO DEVICE USING CREDENTIALS」と題する米国特許出願(代理人整理番号IL920050028US1)に記載されたような入出力装置の保護のための方法およびシステムを使用することによって、他のオブジェクトから保護されることに注意すべきである。
【0041】
データ・フロー
図3を参照して説明する。図3は、本発明の一実施形態に係る入出力要求を実行するための方法のフローチャートである。本方法は、コンシューマ・アプリケーション10から入出力装置34へのデータ・フローに関連している図示されている。本方法は、例えば複数の動作要求が共に渡されるように修正することができる。
【0042】
最初に、アプリケーション10は、入出力要求を入出力インターフェース12に書き込む(ステップ300)。この要求は、プロトコル・インスタンス(すなわち、仮想ネットワーク装置)、要求された動作、および、この動作がデータ転送に関わる場合はデータ・バッファを識別するための情報を含む。
【0043】
隔離ネットワーク・プロトコル・スタック20は、コンシューマ10の要求キュー120から要求を読み出す(ステップ302)。さらに、この要求を解釈して、どの動作をどの装置に対して行うかを決定して、利用可能なハードウェア、プロトコル、コネクションの種類などに依存して、適切な装置固有の動作を開始する(ステップ304)。
【0044】
例えば、TCP送信動作について、隔離ネットワーク・プロトコル・スタック20は、コンシューマ・データを読み出して、これを遠隔ホストへ送信する。TCPデータは、典型的には即座に送信することができないので、スタック20は、例えば、まず、(送信前に正しく読み出すために)コンシューマ・データをポイントする内部データ構造を構築するか、または、中間バッファへ(TCP「規則」によって認められる場合には、これらのバッファから直接送信されるべき)データをコピーしてもよい。
【0045】
動作が完了すると、隔離ネットワーク・プロトコル・スタック20は、入出力インターフェース12の応答キュー120上に応答エントリを生成する(ステップ306)。コンシューマ10は、この応答エントリを読み出す(ステップ308)。この点で、コンシューマ10は、そのデータ・バッファを再度使用することができる。
【0046】
上述の説明では、本発明の完全な理解を提供するために、数多くの特定の詳細を述べた。しかしながら、これらの具体的な詳細がなくても本発明は実施可能であることは、当業者には明らかであろう。周知の回路、制御論理、および従来のアルゴリズムおよび処理についてのコンピュータ・プログラム命令の詳細は、本発明を不必要に不明瞭にしないために、詳細には説明していない。
【0047】
本発明の局面を実施するプログラミング・コードは、典型的には、コンピュータ読み取り可能な媒体などの永久ストレージに保持される。クライアント‐サーバ環境において、そのようなプログラミング・コードは、クライアントまたはサーバ上に記憶することができる。かかるプログラミング・コードは、データ処理システムと共に使用される様々な既知の媒体上に記録することができる。これには、ディスク装置、磁気テープ、コンパクト・ディスク(CD)、デジタル・ビデオ・ディスク(DVD)などの磁気および光学ストレージ装置、ならびに信号が変調される搬送波のあるなしに関わらず送信媒体に記録されたコンピュータ命令信号が含まれるが、これに限定されない。例えば、送信媒体は、インターネットなどの通信ネットワークを含むことができる。加えて、本発明はコンピュータ・プログラムの形態で実施することができるが、その代わりに、本発明を実施するのに必要な機能を、アプリケーション専用集積回路または他のハードウェアなどのハードウェア要素、またはハードウェア要素とソフトウェアとの何らかの組み合わせを部分的または全体的に使用して実施することができる。例えば、ストリーマ18は、コンピュータ・プログラムの形態で実施することができるが、その代わりに、ハードウェア要素を部分的または全体的に使用して実施することもできる。
【0048】
本発明は、典型的には、コンピュータまたは同様の装置を制御するためのプログラム命令のセットを備えるコンピュータ・プログラムとして実施される。これらの命令は、システムにあらかじめロードされるか、CD‐ROMなどのストレージ媒体上に記録されるか、またはインターネットまたは移動電話ネットワークなどのネットワーク上でダウンロード可能であるようにして、供給することができる。
【0049】
本発明は、本明細書において特に図示し、かつ説明したものに限定されないことは、当業者によって理解されるだろう。むしろ、本発明の範囲は、本明細書において説明した様々な特徴の組み合わせおよび副次的な組み合わせの両方を含み、当業者が上記の説明を読むと想起するような、従来技術にはなかった変形および変更も含む。
【図面の簡単な説明】
【0050】
【図1】本発明の実施形態に係るネットワーク・アーキテクチャの概略論理ブロック図である。
【図2】本発明の実施形態に係るネットワーク・アーキテクチャの概略ブロック図である。
【図3】本発明の実施形態に係る入出力要求を実行するための方法のフローチャートである。
【符号の説明】
【0051】
10 コンシューマ・アプリケーション、OSサービス
12 入出力インターフェース
20 隔離ネットワーク・プロトコル・スタック
30 入出力機能
32 ネットワーク、ストレージ、周辺装置、その他
34 入出力要素

【特許請求の範囲】
【請求項1】
少なくとも1つのコンシューマ・アプリケーションと、少なくとも1つのオペレーティング・システムとによって使用されるネットワーク・アーキテクチャであって、
前記コンシューマ・アプリケーションとメッセージを授受するように編成された入出力インターフェースを備え、前記メッセージは、当該メッセージに関係する特定のプロトコル層による実行を対象とする高レベルの一般的なネットワーク装置コマンドを搬送し、
前記高レベルのコマンドを処理して実行するとともに、前記高レベルのコマンドから装置固有のコマンドを生成するように編成された隔離ネットワーク・プロトコル・スタックと、
前記装置固有のコマンドを実行するように編成された入出力要素と
を備える、ネットワーク・アーキテクチャ。
【請求項2】
前記入出力インターフェースは、要求/応答メッセージ・セマンティクスを授受するように編成された非同期のインターフェースであり、前記コンシューマ・アプリケーションと前記入出力インターフェースとの間で渡される前記要求/応答は、第1の種類のものであり、前記入出力インターフェースと前記隔離ネットワーク・プロトコル・スタックとの間で渡される前記メッセージは、第2の種類のものである、請求項1に記載のネットワーク・アーキテクチャ。
【請求項3】
前記入出力インターフェースは、前記コンシューマ・アプリケーションと前記オペレーティングシステムと前記隔離ネットワーク・プロトコル・スタックとの間の通信に使用され、複数のオペレーティング・システムがある場合には、前記オペレーティング・システムは、少なくとも1つの種類またはバージョンのものである、請求項2に記載のネットワーク・アーキテクチャ。
【請求項4】
前記入出力インターフェースは、複数の要求/応答インターフェースからなり、各要求/応答インターフェースは、1つまたは複数のスタックをアクセスするために前記コンシューマ・アプリケーションによって使用される、請求項3に記載のネットワーク・アーキテクチャ。
【請求項5】
前記要求は、データ転送要求または制御要求である、請求項1に記載のネットワーク・アーキテクチャ。
【請求項6】
前記隔離ネットワーク・プロトコル・スタックは、前記隔離ネットワーク・プロトコル・スタックを制御するように編成されたトランスポート制御エンジン(TCE)と、データ移動タスクを加速させるとともに、前記高レベルのコマンドを処理して実行するように編成されたストリーマとをさらに備える、請求項1に記載のネットワーク・アーキテクチャ。
【請求項7】
前記ストリーマおよび前記TCEは、制御情報を交換するために二重キュー・インターフェースを介して通信するように編成される、請求項6に記載のネットワーク・アーキテクチャ。
【請求項8】
前記隔離ネットワーク・プロトコル・スタックは、少なくとも1つの相互接続を通して、前記コンシューマ・アプリケーションおよび前記オペレーティング・システムに結合される、請求項1に記載のネットワーク・アーキテクチャ。
【請求項9】
前記データ転送要求または前記制御要求は、前記隔離ネットワーク・プロトコル・スタックの互いに異なる層に対するアクセスを提供するために、前記隔離ネットワーク・プロトコル・スタックによって使用され、前記データ転送要求または前記制御要求は、前記隔離ネットワーク・プロトコル・スタック内の特定の仮想装置を対象としており、前記データ転送要求または前記制御要求は、前記特定の仮想装置に適用可能な特定のネットワーク・プロトコルをインスタンス化する、請求項5に記載のネットワーク・アーキテクチャ。
【請求項10】
前記互いに異なる層は、パケット・ベースの媒体アクセス制御(MAC)インターフェース、トランスポート制御プロトコル(TCP)またはユーザ・データグラム・プロトコル(UDP)トランスポート・インターフェース、およびファイル・トランスポート・プロトコル(FTP)上層プロトコル・インターフェースからなる、請求項9に記載のネットワーク・アーキテクチャ。
【請求項11】
隔離ネットワーク・プロトコル・スタックを使用してコンシューマの入出力要求を実行するためのコンピュータで実施される方法であって、
入出力要求を入出力インターフェースに書き込むステップと、
前記入出力要求を前記入出力インターフェースから読み出すステップと、
前記入出力要求に基づいて動作を開始するステップと、
データをホスト・コンピュータと授受するステップと、
前記ホスト・コンピュータ内の前記動作が完了すると、前記入出力インターフェースに対して応答を書き込むステップと、
前記応答を読み出すステップと
を含む、方法。
【請求項12】
前記要求は、プロトコル・インスタンス、要求された動作、および前記動作がデータ転送を含む場合には前記データ・バッファのうちのいずれかを識別する情報を含む、請求項11に記載の方法。
【請求項13】
前記入出力要求を書き込む前記ステップは、前記コンシューマの要求キュー上に前記入出力要求を書き込むステップをさらに含む、請求項11に記載の方法。
【請求項14】
前記入出力応答を書き込む前記ステップは、前記入出力インターフェースの応答キュー上に応答エントリを生成するステップをさらに含む、請求項11に記載の方法。
【請求項15】
前記入出力要求は、データ転送要求または制御要求である、請求項11に記載の方法。
【請求項16】
請求項11ないし15のいずれかに記載の方法を実施するように編成された、コンピュータ上で実行されるコンピュータ・プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate


【公開番号】特開2007−193786(P2007−193786A)
【公開日】平成19年8月2日(2007.8.2)
【国際特許分類】
【出願番号】特願2006−341850(P2006−341850)
【出願日】平成18年12月19日(2006.12.19)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.イーサネット
【出願人】(390009531)インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】INTERNATIONAL BUSINESS MASCHINES CORPORATION
【Fターム(参考)】