(57)【特許請求の範囲】
【請求項１】
第１のコンピュータシステム（１００）で動作し、それに関連した第１のネットワークアドレスを有する第１のネットワークプロトコルプロバイダ（４４）と、第２のコンピュータシステム（１０２）で動作し、それに関連した第２のネットワークアドレスを有する第２のネットワークプロトコルプロバイダ（５８）との両方が、第２のシステムに取付けられた同一のネットワークインタフェースカード（５０）を介してネットワーク（１５）にアクセスできるようにする装置であって、
第１のコンピュータシステムの入力／出力（Ｉ／Ｏ）サブシステムと第２のコンピュータシステムのＩ／Ｏサブシステムとの間の相互接続（６２，６４，６６，７０）（６５，６７，７０’）（６３，７０″）と、前記相互接続を介してデータがシステム間で伝送され、
データとともに受信されたネットワークアドレスが第１のネットワークアドレスと一致する場合には、前記相互接続を介して、前記ネットワークインタフェースカードによって受信されたデータを前記第１のネットワークプロトコルプロバイダに送り、前記データとともに受信されたネットワークアドレスが第２のネットワークアドレスと一致する場合には、前記受信されたデータを前記第２のネットワークプロトコルプロバイダに送る、前記第２のコンピュータシステムで動作するルータ（８０）とを含む、装置。
【請求項２】
前記ルータが、前記第１のネットワークプロトコルプロバイダおよび前記第２のネットワークプロトコルプロバイダの両方からのデータを、前記第１のネットワークプロバイダおよび前記第２のネットワークプロバイダの両方に透過的な態様で、前記同一のネットワークインタフェースカードを介して前記ネットワークに向けて送信するようさらに動作する、請求項１に記載の装置。
【請求項３】
前記第１および第２のネットワークプロトコルプロバイダのうち一方が他方のものにデータを与えるときに、前記ルータが、前記ネットワークプロトコルプロバイダの両方に透過的な態様で、前記ネットワークインタフェースカードを迂回して、前記他方のネットワークプロトコルプロバイダに前記データを直接送る、請求項１に記載の装置。
【請求項４】
前記ネットワークインタフェースカードを介して前記第１のネットワークプロトコルプロバイダおよび前記第２のネットワークプロトコルプロバイダにブロードキャストされるように意図されたデータが受信されるときに、前記ルータが、当該データを検出し、かつそれを前記第１および第２のネットワークプロトコルプロバイダの両方に送る、請求項１に記載の装置。
【請求項５】
前記第１および第２のネットワークプロトコルプロバイダの一方が、ブロードキャストアドレスを有する出力されるべきデータを送信し、前記ルータは、前記同じネットワークインタフェースを介して前記ネットワークにデータを経路制御し、かつ前記相互接続を介して前記他方のネットワークプロトコルプロバイダに前記データを経路制御するよう動作する、請求項１に記載の装置。
【請求項６】
前記ルータが、前記ネットワークインタフェースカードのデバイスドライバ（５４）とインタフェースするときに前記ネットワークプロトコルプロバイダの動作をシミュレートし、前記ルータは、前記第１および第２のネットワークプロトコルプロバイダとインタフェースするときに前記ネットワークインタフェースカードのデバイスドライバの動作をシミュレートし、このため、前記ルータの機能は前記ネットワークインタフェースカードおよび前記第１および第２のネットワークプロトコルプロバイダに透過的である、請求項１に記載の装置。
【請求項７】
前記第２のシステムがＮＴサーバを含み、前記ネットワークインタフェースカードは、前記ネットワークインタフェースカードへのアクセスを制御する第２のシステムに取付けられたデバイスドライバ（５４）を有し、さらに、前記ＮＴサーバの前記ネットワークインタフェースカードのデバイスドライバおよび前記ネットワークプロトコルプロバイダは、ネットワークドライバインタフェース仕様（ＮＤＩＳ）を介して前記ルータとインタフェースする、請求項１に記載の装置。
【請求項８】
前記ルータが、前記第１および第２のネットワークプロトコルプロバイダのネットワークアドレスを含むテーブルを作成して維持する、請求項１に記載の装置。
【請求項９】
前記第１のネットワークプロトコルプロバイダが、前記第１のコンピュータシステムのＴＣＰ／ＩＰプロトコルの実装を含み、前記第２のネットワークプロトコルプロバイダが、前記第２のコンピュータシステムのＴＣＰ／ＩＰプロトコルの実装を含む、請求項１に記載の装置。
【請求項１０】
前記第１のネットワークプロトコルプロバイダが、各々がそれに関連したネットワークアドレスを有する、複数のネットワークプロトコルプロバイダを含む、請求項１に記載の装置。
【請求項１１】
前記第１のネットワークプロトコルプロバイダが、ＴＣＰ／ＩＰネットワークプロトコルプロバイダ（４４）およびＢＮＡｖ２ネットワークプロトコルプロバイダ（４２）を含む、請求項１０に記載の装置。
【請求項１２】
前記第１のコンピュータシステムと前記第２のコンピュータシステムとの間の相互接続が、
前記第１のコンピュータシステムのＩ／Ｏサブシステムと前記第２のコンピュータシステムのＩ／Ｏサブシステムとの間の物理的接続（６２，６４，６６）（６５，６７）（６３）と、前記物理的接続を介して前記システム間でデータが送信され、
前記第２のコンピュータシステムの他のモジュール（７６，７８，８０，８２，８６，８８）による前記物理的接続へのアクセスを制御する第２のコンピュータシステムの相互接続デバイスドライバ（７０）（７０’）（７０″）とを含む、請求項１に記載の装置。
【請求項１３】
前記第１および第２のコンピュータシステム間の相互接続が、前記物理的接続を介してシステム間の複数の交信を多重化する、前記第２のコンピュータシステムのキューサービスプロバイダ（７６）をさらに含む、請求項１２に記載の装置。
【請求項１４】
前記第１のコンピュータシステムが、ユニシスのＡシリーズサーバを含み、前記第２のコンピュータシステムがＮＴサーバを含み、前記物理的接続は前記ＡシリーズサーバのＩ／ＯサブシステムのＣＳバスインタフェースと前記ＮＴサーバの前記Ｉ／ＯサブシステムのＩ／Ｏバスとの間の接続（６２，６４，６６）を含む、請求項１２に記載の装置。
【請求項１５】
前記ＮＴサーバの前記Ｉ／ＯサブシステムのＩ／ＯバスがＥＩＳＡバスを含む、請求項１４に記載の装置。
【請求項１６】
前記第１のコンピュータシステムがユニシスのＡシリーズサーバを含み、前記第２のコンピュータシステムがＮＴサーバを含み、前記物理的接続は、前記ＡシリーズサーバのＩ／Ｏサブシステムのチャネルマネージャユニット（ＣＭＵ）（１８ｂ）のポートと、前記ＮＴサーバのＩ／ＯサブシステムのＩ／Ｏバスとの間の接続（６５，６７）を含む、請求項１２に記載の装置。
【請求項１７】
前記ＮＴサーバのＩ／ＯサブシステムのＩ／ＯバスがＰＣＩバスを含む、請求項１６に記載の装置。
【請求項１８】
前記第１のコンピュータシステムのメモリシステムを含む前記第１のコンピュータシステムと、そのＩ／Ｏサブシステム（１４’）とが、前記第２のコンピュータシステム内でエミュレートされ、前記物理的接続（６３）は、前記エミュレートされた第１のコンピュータシステムのメモリスペースと、前記第２のコンピュータシステムのメモリスペースとの間のメモリ間接続としてエミュレートされる、請求項１２に記載の装置。
【請求項１９】
前記相互接続デバイスドライバ（７０，７０’，７０″）が、手順インタフェースを介して前記第２のコンピュータシステムの別のモジュール（７６）とインタフェースし、前記相互接続デバイスドライバの手順および前記他のモジュールの手順は、前記相互接続デバイスドライバの機能を前記他のモジュールから孤立させるように登録されて、前記他のモジュールに透過的な態様で、これに応じて異なった相互接続デバイスドライバに種々の物理的接続が採用されるようにする、請求項１２に記載の装置。
【請求項２０】
第１のコンピュータシステム（１００）と第２のコンピュータシステム（１０２）とを含むシステムにおいて、第１のネットワークプロトコルプロバイダ（４４）は前記第１のコンピュータシステムで動作し、それに関連した第１のネットワークアドレスを有し、第２のネットワークプロトコルプロバイダ（５８）は前記第２のコンピュータシステムで動作し、それに関連した第２のネットワークアドレスを有し、さらに、前記第１および第２のコンピュータシステム間の相互接続（６２，６４，６６，７０）（６５，６７，７０’）（６３，７０″）により、それらの間でデータが転送されるようになり、前記第１および第２のネットワークプロトコルプロバイダの両方が、前記第２のシステムにインストールされた同一のネットワークインタフェースを介してネットワークにアクセスできるようにするための方法は、
データとともに受信されたネットワークアドレスが前記第１のネットワークアドレスと一致する場合に、前記相互接続を介して、前記ネットワークインタフェースによって受信されたデータを前記第１のネットワークをプロトコルプロバイダに経路制御するステップと、
前記データとともに受信されたネットワークアドレスが前記第２のネットワークアドレスと一致する場合に、前記受信されたデータを前記第２のネットワークプロトコルプロバイダに経路制御するステップとを含む、方法。
【請求項２１】
前記両方のネットワークプロトコルプロバイダに透過的な態様で、前記同じネットワークインタフェースカードを介して、前記第１のネットワークプロトコルプロバイダおよび前記第２のネットワークプロバイダの両方からのデータを前記ネットワークに経路付けるステップをさらに含む、請求項２０に記載の方法。
【請求項２２】
前記第１および第２のネットワークプロトコルプロバイダのうち一方が前記第１および第２のネットワークプロトコルプロバイダのうち他方のものにデータを与えるときに、前記方法は、前記相互接続を介して直接前記データを前記他方のネットワークプロトコルプロバイダに経路制御し、それにより、前記ネットワークプロトコルプロバイダの両方に透過的な態様で、前記ネットワークインタフェースカードを迂回するステップをさらに含む、請求項２０に記載の方法。
【請求項２３】
前記同一のネットワークインタフェースカードを介して前記ネットワークへのすべてのネットワークプロトコルプロバイダにブロードキャストされるよう意図されたデータが受信されるときに、前記方法は、前記相互接続を介して前記第１のネットワークプロトコルプロバイダおよび前記第２のネットワークプロトコルプロバイダの両方に当該データを経路制御するステップをさらに含む、請求項２０に記載の方法。
【請求項２４】
前記第１および第２のネットワークプロトコルプロバイダの一方が、ブロードキャストアドレスを有する出力されるべきデータを送信し、前記方法は、前記同一のネットワークインタフェースカードを介して前記ネットワークに前記データを経路制御し、かつ前記相互接続を介して前記他方のネットワークプロトコルプロバイダに前記データを経路制御するステップをさらに含む、請求項２０に記載の方法。
【発明の詳細な説明】
著作権に関する注意
この特許書類の開示の一部分には、著作権の保護に関わる内容が含まれる。著作権の保有者は、米国特許商標庁の特許ファイルまたは記録にある特許書類または特許開示が何者によって複製されても異議を唱えないが、それ以外に関するすべての著作権を保有する。
背景
発明の分野
この発明は、コンピュータネットワーキングの分野に関し、特に、２つのコンピュータシステムが、それらのうち一方に取付けられた共有ネットワークインタフェースカードを介してネットワークにアクセスできるようにするための装置および方法に関する。
先行技術の説明
異種コンピュータシステムの、規格および／または私的所有にかかるネットワーキングプロトコルを用いてネットワークを介して互いに通信できる能力は公知である。多くのコンピュータシステムは、これらのプロトコルに従ってコンピュータシステムがネットワーキングを行なうことができるようにする何らかの形態のネットワーキングアーキテクチャを有する。典型的にこのようなネットワーキングアーキテクチャには、システムソフトウェアおよびハードウェアの両方が含まれる。図１は、ネットワーク１５上の他のホストまたはノードと通信するための、ユニシスのＡシリーズエンタープライズサーバ１０によって採用されているネットワーキングアーキテクチャの構成要素を示すブロック図である。
Ａシリーズエンタープライズサーバ１０はユニシスのＭＣＰオペレーティングシステム１２を実行し、Ａシリーズシャシ内に収められた１つまたはそれ以上のＩ／Ｏモジュール（ＩＯＭ）１４を含むＩ／Ｏサブシステムを有する。ＩＯＭ１４はＣＳ−バスＩＩまたはＣＳ−バスＩＩＩ（以下「ＣＳバス」と称する）と呼ばれるユニシスの私的所有にかかるＩ／Ｏバスアーキテクチャを実現する。複数のカードスロット、たとえばスロット１６ａから１６ｄが、「チャネルアダプタ」と呼ばれるインタフェースカードを接続するためにＣＳバスに設けられる。チャネルアダプタスロットの種々のグループまたはラックの各々は、チャネルマネージャユニット（ＣＭＵ）（たとえばＣＭＵ１８ａ、１８ｂ）によって制御される。ＩＯＭはいくつかのＣＭＵを含むことができ、それらの各々は、ＣＳバスを介してチャネルアダプタカードスロットのそれぞれのラックを制御する。ＣＭＵはＩ／Ｏプロセスの物理層およびデータ層を管理する。
各々がＩＯＭ１４内で１つまたはそれ以上のチャネルアダプタカードスロットを占有し得るチャネルアダプタカードにより、Ａシリーズエンタープライズサーバ１０の接続に関する問題のさまざまな解決策が提供される。たとえば、ユニシスは、ＳＣＳＩ周辺機器をエンタープライズサーバに接続するためのスモールコンピュータシステムインタフェース（ＳＣＳＩ）プロトコルを実装するチャネルアダプタカードを提供する。
ネットワークの接続に関し、ユニシスはさまざまな物理ネットワーキングプロトコルをサポートするいくつかのチャネルアダプタを提供する。これらのチャネルアダプタは一般にネットワークプロセッサ（ＮＰ）と呼ばれる。たとえば、ユニシスのＩＣＰ２２およびＩＣＰ２６ネットワークプロセッサは、イーサネットネットワークプロトコルを実装するチャネルアダプタカードであり、Ａシリーズエンタープライズサーバをイーサネットネットワークに接続するために用いられ得る。ユニシスはまた、ＦＤＤＩおよびＡＴＭネットワークへの接続のためのネットワークプロセッサを提供する。図１に示されるように、種々の多くのネットワークプロセッサ（たとえばＮＰ２０ａ、２０ｂおよび２０ｃ）が、ＩＯＭ１４のそれぞれのチャネルアダプタスロット（たとえばスロット１６ｂ、１６ｃおよび１６ｄ）に取付けられて、ネットワークの接続に関する問題の様々な解決策を提供し得る。
ネットワークプロセッサ２０ｃ（チャネルアダプタスロット１６ｄに取付けられた状態）のより詳細な図に示されるように、ネットワークプロセッサは複数の異なった線、たとえば線０、線１、…、線Ｎを含み得る。線はネットワーク内の物理的端点を表わす。たとえば、ユニシスのＩＣＰ２２ネットワークプロセッサは２本の線を有し、これらの線の各々は別個のイーサネット接続を含み、すなわち一方の線が一方のイーサネットネットワークに接続され、他方の線が別のイーサネットネットワークに接続される。
ネットワークプロセッサの各線はその線に規定された１つのステーショングループを有し得る。ステーショングループは１つまたはそれ以上のステーションを含む。ステーションはその線上での論理的ダイアログを表わす論理的端点である。したがって、ネットワークプロセッサの所与の線上には１より多い論理的ダイアログが生じ得る。これは多重化によって達成される。たとえば、バロースネットワークアーキテクチャバージョン２プロトコル（ＢＮＡｖ２）などのコネクション指向ネットワーキングプロトコル内では、１つのステーションがネットワーク上の１つの他のＢＮＡｖ２ホスト内との論理的ダイアログを表わすことができ、別のステーションが、異なったＢＮＡｖ２ホストに対する論理的ダイアログを表わすことができる。図１に示されるように、たとえば線Ｎのステーション０はＢＮＡｖ２ホスト２２との論理的ダイアログを表わし得、線Ｎのステーション１はＢＮＡｖ２ホスト２４との論理的ダイアログを表わし得る。インターネットプロトコル（ＩＰ）などのコネクション指向でないネットワーキングプロトコルの場合、そのプロトコルスタックに関するすべての通信を扱うために１つのステーションしか規定される必要がない。たとえば、図１に示されるように、線ＮのステーションＮが線Ｎを介するすべてのＩＰトラヒックに関する論理的端点として規定され得る。ネットワークプロセッサ２０ｃで動作するソフトウェアを含むローカルエリアネットワークステーショングループ（ＬＡＮＳＧ）モジュール２６は、ネットワークプロセッサ２０ｄのさまざまな線上のステーションおよびステーショングループを生成および維持し、かつそれらを介してデータの送受信を行なうための呼び出し可能な手順を提供する。
ネットワークプロセッサ２０ｄで動作する他のソフトウェア構成要素はキューサービスプロバイダ（ＱＳＰ）モジュール２８を含み、これは所与のＮＰに規定されたすべてのステーションに関するデータの多重化および非多重化を扱い、このソフトウェア構成要素はさらに２つのスタブモジュール、すなわちネットワークサービスマネージャスタブ（ＮＳＭスタブ）３０およびリンク層マネージャスタブ（ＬＬＭスタブ）３２を含み、これらはＭＣＰ環境内のモジュールに対して、コアネットワークサービス（ＣＮＳ）ソフトウェア構成要素３４の対応のモジュールとインタフェースする。
一般に、ネットワークプロセッサ（たとえばＮＰ２０ａ、２０ｂまたは２０ｃ）は７層ＯＳＩ参照モデルのデータリンク層および物理層を実装する。ＢＮＡｖ２およびＴＣＰ／ＩＰネットワーキングプロトコルなどの、ネットワーク１５の種々のホストで動作するアプリケーションとの通信のためにクライアントアプリケーション４６が採用を希望し得る、より高いレベルのネットワーキングプロトコルが、Ａシリーズシステム１０上にネットワークプロトコルプロバイダとして実装される。ネットワークプロトコルプロバイダは、これらの高いレベルのネットワーキングプロトコルを実装するソフトウェアモジュールである。たとえば、ユニシスはＢＮＡｖ２ホストレジデントネットワークプロバイダ（ＨＲＨＰ）モジュールおよびＴＣＰ／ＩＰ  ＨＲＮＰモジュールの両方を提供する。図１の例では、ＢＮＡｖ２  ＨＲＮＰ４２およびＴＣＰ／ＩＰ  ＨＲＮＰ４４が示される。
コアネットワークサービス（ＣＮＳ）ソフトウェア３４はネットワークプロトコルプロバイダ４２および４４のためのサポートを提供し、ネットワークプロセッサおよびそれに規定されたステーショングループの初期化およびメンテナンスを扱う。具体的には、ＣＮＳ３４は、システムに取付けられたネットワークプロセッサ（たとえば２０ａ、２０ｂおよび２０ｃ）の初期化および管理を行なうネットワークサービスマネージャ（ＮＳＭ）３６と、所与のネットワークプロセッサに規定された各ステーショングループのアイデンティティーおよび属性の初期化および維持を行なうリンク層マネージャ（ＬＬＭ）３８とを含む。ＣＮＳ３４の別の構成要素（図示せず）はネットワークプロセッサで生成されたステーショングループおよびステーションに関連した属性を確認する。これらの属性は、ステーションが規定されると制御ダイアログによってネットワークプロセッサとＣＮＳ３４との間に送られる。ＮＳＭおよびＬＬＭモジュール３６および３８のスタブ手順と同様に、ネットワークプロセッサはＣＮＳ３４の属性ハンドラに対応するスタブ手順（ＬＬＡＨ、図示せず）も有する。ＮＰＳＵＰＰＯＲＴソフトウェアライブラリ４０およびＭＣＰオペレーティングシステム１２の一部分により、ネットワークプロセッサならびにＣＮＳ３４およびネットワークプロトコルプロバイダ４２，４４の間のインタフェースとしての役割を果たし、ＮＰへのソフトウェアのロードおよびそれらの状態のダンプを制御する、ルーチンおよび手順の呼び出しが提供される。
各ネットワークプロセッサは、システム１０内のネットワークプロセッサを一意に識別する関連の識別子を有する。ネットワークプロセッサが初期化されてライン接続されると、ネットワークプロセッサのＮＳＭスタブ３０が制御ダイアログによってＣＮＳ３４のＮＳＭ３６とインタフェースし、その識別子をＮＳＭ３６に送るようにする。ＮＳＭ３６はアクティブなネットワークプロセッサすべての識別子を管理する。
所与のネットワークプロセッサに規定された各ステーショングループおよびステーションもまた、それに関連する一意の識別子を有する。ネットワークプロセッサ上のＬＬＭスタブ３２とＣＮＳ３４のＬＬＭ３８との間に確立された制御ダイアログによって、初期化時にステーションおよびステーショングループ識別子がＬＬＭ３８に送られる。ＬＬＭ３８内ではステーションがコネクションに対応し、ステーショングループがコネクショングループに対応する。
上述のとおり、ネットワークプロセッサの単一の物理的ライン上に多数のステーション（すなわちステーショングループ）を規定する能力は、多重化によって達成される。具体的には、ネットワークプロセッサのＱＳＰ２８は所与の線上の多数のステーションに関する内へ向かうデータおよび外へ向かうデータを多重化する。さらに、ＱＳＰはＮＳＭ３６をＮＳＭスタブ３０との間およびＬＬＭ３８とＬＬＭスタブ３２との間に要求および応答データを分配する責任を持つ。そのために、すべてのステーション、ＮＳＭスタブ３０およびＬＬＭスタブ３２を含む、ＭＣＰからの外に向かうデータを受けるネットワークプロセッサ上の各エンティティーには、ＱＳＰによって一意のリモートキューリファレンス（ＲＱＲ）が割当てられる。ＮＳＭスタブＲＱＲは、ＮＰがロードされるとＮＰＳＵＰＰＯＲＴによってＣＮＳ３４内のＮＳＭ３６に報告される。ＬＬＭスタブＲＱＲは、ＮＰが初期化されるとＮＳＭスタブ３０によってＮＳＭ３６を介してＬＬＭ３８に報告される。ステーションＲＱＲはすべてステーションがオープンするとＨＲＮＰに報告される。
別のＢＮＡｖ２ホストまたは別のＴＣＰ／ＩＰホストなどの、ネットワーク１５上の何らかの他のホストまたはノードに、ネットワーク１５を介してデータを送ることがクライアントアプリケーションに要求される場合、それは、たとえば４２および４４である適切なネットワークプロトコルプロバイダのサービスを呼び出す。ネットワークプロトコルプロバイダ４２および４４は、データが出力されるべき適切なネットワークプロセッサおよびステーションを決定し、プロトコルヘッダを追加し、ネットワークプロセッサの識別子およびステーションのＲＱＲを含むＭＣＰ１２への対応の要求を作成する。データおよび関連のＲＱＲがネットワークプロセッサ（たとえばネットワークプロセッサ２０ｃ）上のＱＳＰ２８にＭＣＰ１２から送られ、これは、ＬＡＮＳＧモジュール２６と組合せられて、指定されたステーションによって表わされる論理的ダイアログの一部分として、適切な線（たとえば線０、線１、…、または線Ｎ）を介してネットワーク１５にデータを送信する。
所与の線上にネットワーク１５からのデータが受信されると、ＬＡＮＳＧモジュール２６は、データに関連したヘッダ情報から、データが意図されるステーション（すなわち理論的ダイアログ）を決定する。ＬＡＮＳＧおよびＱＳＰモジュール２６および２８は、ＭＣＰ１２およびＮＰＳＵＰＰＯＲＴライブラリ４０の一部分と組合せられて、受信データを、どのステーションがデータを受信したかを示すものとともに、そのステーションに関連した適切なネットワークプロトコルプロバイダ４２および４４に送る。たとえば、図１のネットワークプロセッサ２０ｃの線Ｎ上のステーションの１つ（たとえばステーション０）がＢＮＡｖ２ＨＲＮＰ４２の論理的端点として規定でき、異なったステーション（たとえばステーション１）が、線Ｎ上のすべてのＩＰトラヒックがＴＣＰ／ＩＰ  ＨＲＮＰ４４について受信された論理的端点として規定され得る。一フレームのデータがネットワークから線Ｎ上に受信されると、ＬＡＮＳＧモジュール２６は、ヘッダ情報から、どのネットワークプロトコルプロバイダ（すなわちステーション）がデータを受信するよう意図されているかを決定する。この決定は、「ワークステーションを複数のコンピュータプラットフォームにインタフェースするための方法および装置（Method and Apparatus for Interfacing a Workstation to a Plurality of Computer Platforms）」（Johnson et al.）と題された同一人に譲渡された米国特許第５，３７９，２９６号に記載されている方法によって行なわれる。
Ａシリーズコンピュータにおける使用の他に、上述のネットワーキングアーキテクチャはユニシスのClearPath  ＨＭＰ  ＮＸエンタープライズサーバにも採用されている。ClearPath  ＨＭＰ  ＮＸは、マイクロソフトウィンドウズＮＴを動作させているサーバと密に統合されたＡシリーズエンタープライズサーバを含む。「マイクロソフト」、「ウィンドウズ」および「ウィンドウズＮＴ」はマイクロソフト社の登録商標であることに留意されたい。上述のネットワーキングアーキテクチャに関するさらなる情報は下記の文献において見出すことができ、これらの文献の各々は、この発明の譲受人であるユニシス社から入手可能であり、その全体が引用によって援用される。
ClearPath  HMP  NX  Series  with  Windows  NT  Network  Services  Implementation Guide (Part No.4198 6670);
BNA/CNS Network Implementation Guide, Volume 2:Configuration (Part No.3789 7014);
ClearPath  HMP  NX  Series  with  Windows  NT  Implementations and Operations Guide (Part No.8807 6542);
ClearPath  HMP  NX  Series  with  Windows  NT  Migration Guide (Part No.8807 7730);
Networking Capabilities Overview (Part No.3789 7139)
Networking Operations Reference Manual, Volumes 1 and 2:Commands and Inquiries (Part No.3787 7917);and
Networking Products Installation Guide (Part No.4198 4840).
イーサネットベースのチャネルアダプタであるユニシスのＩＣＰ２２ネットワークプロセッサを用いると、過去には、ネットワークを介してワークステーションまたはパーソナルコンピュータ（ＰＣ）と通信することがユニシスのＡシリーズエンタープライズサーバには可能であった。この能力の一例が図２に示される。この例では、Ａシリーズエンタープライズサーバ１０はマイクロソフトのウィンドウズＮＴオペレーティングシステム（以下「ＮＴサーバ」と称する）を動作させているインテルベースのワークステーション４８と通信する。Ａシリーズエンタープライズサーバはネットワークプロセッサ２０ａを介してネットワークに接続され、これはたとえばユニシスのＩＣＰ２２イーサネットベースのネットワークプロセッサであり得る。
ＮＴサーバ４８のＩ／ＯサブシステムはＮＴオペレーティングシステムカーネルの部分と、ＥＩＳＡまたはＰＣＩバス５２と、適切なデバイスドライバソフトウェアとを含む。ネットワーク接続を提供するために、ＮＴサーバ４８上の利用可能なバススロットにネットワークインタフェースカード（ＮＩＣ）５０が取付けられる。ＮＴサーバはＰＣＩおよびＥＩＳＡバス規格のうち一方またはそれらの両方をサポートし得る。ＮＩＣは両方のバス規格に対して利用可能である。
典型的にはＮＩＣカード５０とともに販売されているＮＩＣデバイスドライバ５４が、ＮＴオペレーティングシステムのカーネルスペースに取付けられる。ＮＩＣデバイスドライバ５４はＴＣＰ／ＩＰプロトコルの実装などといった高レベルのネットワークプロトコルプロバイダとインタフェースする。マイクロソフト社は、トランスポートプロトコルドライバとも呼ばれる、ＴＣＰＩＰ．ＳＹＳ５８という名称の、カーネルレベルデバイスドライバの形態でＴＣＰ／ＩＰプロトコルを実装している。ＴＣＰＩＰ．ＳＹＳ５８は、マイクロソフト社および３Ｃｏｍによって共同開発された工業規格ネットワークドライバインタフェース仕様である、ＮＤＩＳを介してＮＩＣデバイスドライバ５４とインタフェースする。ＮＤＩＳはＴＣＰＩＰ．ＳＹＳなどのハードウェアから独立したプロトコルドライバ間での通信のためのインタフェースを規定し、これは、ＯＳＩモデルのデータリンク、ネットワークおよびトランスポート層と、ＮＩＣハードウェアへのインタフェースを提供し、ＯＳＩモデルの物理層に対応する、ハードウェア依存型ＮＩＣドライバとを実装する。ＮＴサーバ上のクライアントプログラム６０はＮＴオペレーティングシステムによって適切な呼び出しをＴＣＰＩＰ．ＳＹＳプログラムドライバに発行することにより、ＴＣＰ／ＩＰプロトコルに従ってネットワーク１５を介して通信し得る。
ＮＴサーバのためのネットワークインタフェースカードおよび関連のデバイスドライバは多くの相手先ブランドによる生産（ＯＥＭ）から入手可能である。ＯＥＭ  ＮＩＣは、イーサネットおよび高速イーサネットなどを含むさまざまなネットワーク媒体規格として比較的低コストで入手可能である。新たなネットワーク規格が出現するにつれ、ＯＥＭにより、これらの規格をサポートするようＮＩＣが迅速に設計および生産される。今日多くのコンピュータシステムに見られるＥＩＳＡおよびＰＣＩなどの工業規格Ｉ／Ｏバスアーキテクチャ用にこれらのＮＩＣは開発されているため、規模の経済により、サイクル開発時間が短くなり、消費者には極度に低い値段で利用できるようになる。
この一方で、ユニシスのＡシリーズエンタープライズサーバのＣＳバスＩＩアーキテクチャなどの、私的所有にかかるバスアーキテクチャ用の新しいネットワークプロセッサの設計および生産にはかなり長い時間がかかり、かなり高いコストがかかる。私的所有にかかるシステムの販売者はオープンシステムのＮＩＣ販売者と同レベルの規模の経済を達成することはできず、このため私的所有にかかるシステム用のネットワークプロセッサまたはＮＩＣカードは典型的に、それらのオープンシステムの同等物よりもかなり高いコストを伴う。私的所有にかかるシステムのＮＩＣカードの開発コストを回避するために、２つのコンピュータシステムの各々が、これらのシステムのうち一方に取付けられた共有ネットワークインタフェースカードを介して、ネットワークにアクセスできるようにすることが望ましい。この発明はこのような能力を提供する。
ＷＯ  ９７  ０１９４４には、ホストコンピュータ内のエミュレートされた環境がホストシステムと１つのＴＣＰ／ＩＰプロトコルスタックを共有できるようにする機構が記載されているが、それは、各々がそれ自体のプロトコルスタックを有する２つのホスト環境が、一方のシステムにある１つのネットワークインタフェースカードを共有できるようにする機構を教示も示唆もしていない。ＷＯ  ９７  ０１９４４に記載されている機構は、この発明と同じ問題を扱うものではない。
発明の概要
この発明は、第１のコンピュータシステムで動作し、それに関連した第１のネットワークアドレスを有する第１のネットワークプロトコルプロバイダと、第２のコンピュータシステムで動作し、それに関連した第２のネットワークアドレスを有する第２のネットワークプロトコルプロバイダとが、第２のコンピュータシステムに取付けられた同じネットワークインタフェースカードによってネットワークを介してデータの送受信の両方を行なうことができるようにする、方法および装置に向けられる。その好ましい実施例によると、この発明は、第１のコンピュータシステムの入力／出力（Ｉ／Ｏ）サブシステムを第２のコンピュータシステムのＩ／Ｏサブシステムに結合し、それを介してシステム間でデータが伝達され得る相互接続と、ネットワークインタフェースカードが第１および第２のネットワークプロトコルプロバイダ間で共有されるようにする態様で、第１のネットワークプロトコルプロバイダ（相互接続を介する）、第２のネットワークプロトコルプロバイダおよびネットワークインタフェースカード間でデータを経路制御する、第２のコンピュータシステムで動作するルータとを含む。具体的には、ネットワークインタフェースカードによってネットワークからデータが受信されると、ルータは、データとともに受信されたネットワークアドレスが第１のネットワークアドレスと一致する場合には相互接続を介して第１のネットワークプロトコルプロバイダにデータを経路制御するが、データとともに受信されたネットワークアドレスが第２のネットワークアドレスと一致する場合には受信データを第２のネットワークプロトコルプロバイダに送る。ブロードキャストアドレスとともにネットワークから受信されたデータは、第１（相互接続を介する）および第２のネットワークプロトコルプロバイダの両方に経路制御される。各ネットワークプロトコルプロバイダからの外に向かうデータは、同じネットワークインタフェースカードを介してネットワークに経路制御される。しかしながら、第１および第２のネットワークプロトコルプロバイダのうちの一方からの外へ向かうデータが他のネットワークプロトコルプロバイダにアドレス指定される場合、「ループバック」能力により、ルータが一方のネットワークプロトコルプロバイダから他方のものに直接データを経路制御し、ネットワークインタフェースカードを迂回するようにされる。また、ブロードキャストアドレスを有する第１および第２のネットワークプロトコルプロバイダのうちの一方からの外に向かうデータは、ネットワークインタフェースカードを介してネットワークに経路制御され、さらにはループバック経路（ネットワークインタフェースカードを迂回する）を介して他方のネットワークプロトコルプロバイダに経路制御される。すべての場合において、第１および第２のコンピュータシステム間で経路制御されたデータは相互接続を介して伝送される。さらに、この発明は、同じネットワークインタフェースカードを介して第１のコンピュータシステム上の複数のネットワークプロトコルプロバイダおよび／または第２のシステム上の複数のネットワークプロトコルプロバイダに対してデータを経路制御するためにも用いられ得ることを理解されたい。
好ましくは、ルータは、ネットワークインタフェースカードのデバイスドライバにインタフェースするときにはネットワークプロトコルプロバイダの動作をシミュレートし、第１および第２のネットワークプロトコルプロバイダにインタフェースするときにはネットワークインタフェースカードのデバイスドライバの動作をシミュレートし、このためルータの機能はネットワークインタフェースカードならびに第１および第２のネットワークプロトコルプロバイダに対して透過的である。
第１のコンピュータシステムのＩ／Ｏサブシステムと第２のコンピュータシステムのＩ／Ｏサブシステムとの間の相互接続は好ましくは、それを介してＩ／Ｏサブシステム間にデータが伝送され得る、Ｉ／Ｏサブシステム間の物理的接続と、第２のコンピュータシステムによる物理的接続へのアクセスを制御する第２のコンピュータシステム上の相互接続デバイスドライバとを含む。相互接続デバイスドライバと第２のコンピュータシステム上の他の構成要素との間のインタフェースは好ましくは、手順登録機構の形態で実装される。この態様で、この発明の他の構成要素に透過的な態様で、種々の物理的接続に対して種々の相互接続デバイスドライバが第２のコンピュータシステムに取付けられ得る。たとえば、第１および第２のコンピュータシステムが別個の物理的ユニットである場合、物理的接続は各システムのＩ／Ｏバスの、利用可能なスロットに取付けられた適切なハードウェア（たとえばインタフェースボード）と、それらの間の接続を提供するケーブルとを含み得る。これに代えて、第１のコンピュータシステムが第２のシステム内にエミュレートされる場合、物理的接続はメモリ間接続の形態で第２のサブシステム内にエミュレートされてもよい。
この発明の１つの利点は、マイクロソフト社のウィンドウズＮＴオペレーティングシステムをサポートするシステムに見られるものの、よりオープンであるか、または広く用いられているＩ／Ｏサブシステム用に開発された規格ネットワークインタフェースカードを介して、私的所有にかかるＩ／Ｏサブシステムを有するコンピュータシステムがネットワークにアクセスできるようにするために用いられ得ることである。これは、新しいネットワーキングプロトコルおよび規格が出現する度に、私的所有にかかるシステム用のネットワークインタフェースカードを開発する必要をなくす。その代わりに、この発明は、オープンシステム用に設計されたネットワークインタフェースカードを私的所有にかかるシステムが共有するようにする。
この発明のさらなる特徴および利点は以下に明らかとなるであろう。
【図面の簡単な説明】
上記の概要およびこの実施例の以下の詳細な説明は、添付の図面と関連して読まれるとより良く理解される。発明を例示する目的のために、図面には現在の好ましい実施例が示されるが、この発明が開示された特定的な方法および手段に限定されないことを理解されたい。図面において、
図１は、ネットワーク上の他のホストまたはノードと通信するためにユニシスのＡシリーズエンタープライズサーバによって採用されている先行技術のネットワーキングアーキテクチャの構成要素を示すブロック図である。
図２は、それによってユニシスのＡシリーズエンタープライズサーバが、マイクロソフト社のウィンドウズＮＴを動作させているサーバとネットワークを介して通信し得る、先行技術の方法を示すブロック図である。
図３は、この発明に従う、それらのうちの１つに取付けられ得る単一のネットワークインタフェースを２つのコンピュータシステムが共有できるようにする装置の１つの実施例を示すブロック図である。
図４は、図３の装置の相互接続の代替的な実施例を示すブロック図である。
図５は、図３の装置の相互接続のさらに別の実施例を示すブロック図である。
図６Ａから図６Ｆは、図３から図５に示される相互接続の動作をさらに示すフロー図である。
図７は、それを介してこの発明のルータが、入来するネットワークデータおよび外に向かうネットワークデータを経路制御できる、種々のデータ経路を示す図である。
図８は、好ましい実施例に従う、この発明のルータの実現例をさらに詳細に示すブロック図である。
図９Ａから図９Ｃは、この発明のルータの経路制御機能の１つの実施例と、この発明の方法の１つの実施例とをさらに示す、擬似コードリストを含む図である。
図１０Ａから図１０Ｄは、この発明のルータの経路制御機能の別の実施例と、この発明の方法の別の実施例とをさらに詳細に示すフロー図である。
好ましい実施例の詳細な説明
この発明は、第１のコンピュータシステムで動作し、それに関連した第１のネットワークアドレスを有する第１のネットワークプロトコルプロバイダと、第２のコンピュータシステムで動作し、それに関連した第２のネットワークアドレスを有する第２のネットワークプロトコルプロバイダとが、第２のコンピュータシステムに取付けられた同じネットワークインタフェースカードによってネットワークを介してデータの送受信の両方を行なうことができるようにする、方法および装置に向けられる。その好ましい実施例によると、この発明は、第１のコンピュータシステムの入力／出力（Ｉ／Ｏ）サブシステムを第２のコンピュータシステムのＩ／Ｏサブシステムに結合し、それを介してシステム間でデータが伝達され得る相互接続と、ネットワークインタフェースカードが第１および第２のネットワークプロトコルプロバイダ間で共有されるようにする態様で、第１のネットワークプロトコルプロバイダ（相互接続を介する）、第２のネットワークプロトコルプロバイダおよびネットワークインタフェースカード間でデータを経路制御する、第２のコンピュータシステムで動作するルータとを含む。
以下により十分に説明する１つの実施例において、この発明の方法および装置はユニシスのClearPath  ＨＭＰ  ＮＸエンタープライズサーバの一特徴として提供されたコオペラティブネットワークプラットフォーム（ＣＮＰ）（「ＮＸ／ネットワークサービス」または「ＮＮＳ」と呼ばれることもある）の一部分として実装され、ここでは、上述のとおり、ユニシスのＡシリーズエンタープライズサーバはマイクロソフトのウィンドウズＮＴを動作させているインテルベースのサーバと密に統合される。この実施例において、Ａシリーズエンタープライズサーバは第１のコンピュータシステムを含み、ＮＴサーバは第２のコンピュータシステムを含む。その環境に実装されるように、この発明によりＡシリーズサーバ上のネットワークプロトコルプロバイダ（たとえばＢＮＡｖ２  ＨＲＮＰまたはＴＣＰ／ＩＰ  ＨＲＮＰ）が、ＮＴサーバに取付けられた規格ネットワークインタフェースによって、ネットワークを介してデータの送受信を行なうことができるようになる。ＮＴサーバのネットワークプロトコルプロバイダ（たとえばＴＣＰＩＰ．ＳＹＳ）はまた、そのＮＩＣを介してネットワークにアクセスできるため、ＮＩＣが両方のシステムによって共有される。この能力は、ＮＴサーバのＮＩＣが比較的低コストで広く入手可能であるため、有利である。Ａシリーズサーバの私的所有にかかるＮＩＣ（すなわちネットワークプロセッサ）を開発する必要およびそれに関連したかなりのコストが回避され得る。
この発明の方法および装置、またはそのいくつかの局面または部分は、フロッピーディスク、ＣＤ−ＲＯＭ、ハードドライブ、または何らかの機械で読取可能な他の記録媒体などの有形媒体の形態で実現されたプログラムコード（すなわち命令）の形態をとり得、コンピュータなどの機械によってプログラムコードがロードされて実行されるとき、機械は発明を実施するための装置となる。この発明の方法および装置はさらに、光ファイバを介する電気ワイヤまたはケーブルといったある伝送媒体を介して、または何らかの他の形態の伝送手段によって伝送され、コンピュータなどの機械によってプログラムコードが受信され、ロードされて実行されたときに、機械は発明を実施するための装置となる。汎用プロセッサに実装される場合、プログラムコードはプロセッサと結合されて、同様に動作する独特な装置を特定の論理回路をもたらす。
次に図面を参照して、図面では同じ参照番号は同じ要素を表わしており、図３は、この発明の１つの実施例を示すブロック図であり、ここではこの発明の方法および装置が、ユニシスのClearPath  ＨＭＰ  ＮＸコンピュータシステム（「ClearPathシステム」）に配備されたコオペラティブネットワークプラットフォーム（ＣＮＰ）の一部分として実装されている。示されるように、ClearPathシステムはユニシスのＡシリーズエンタープライズサーバ１００と、ウィンドウズＮＴ１０２（「ＮＴサーバ」）を動作させるインテルベースのサーバ１０２とを含む。この実施例において、Ａシリーズエンタープライズサーバ１００は第１のコンピュータシステムを規定し、ＮＴサーバ１０２は第２のコンピュータシステムを規定する。第１のネットワークプロトコルプロバイダ４４は、この場合ＴＣＰ／ＩＰ  ＨＲＮＰであるＡシリーズシステム１００に設けられ、それに関連したネットワークアドレス（すなわちＩＰアドレス）を有する。第２のネットワークプロトコルプロバイダ５８はこの場合ＴＣＰＩＰ．ＳＹＳ（マイクロソフト社から入手可能である）ＮＴサーバ１０２に設けられ、この実施例における第２のネットワークアドレスを規定する、それに関連した独自のネットワークアドレス（すなわちＩＰアドレス）を有する。ＡシリーズおよびＮＴサーバに他のネットワークプロトコルプロバイダを取付けてもよい。たとえば、ＡシリーズサーバにはＢＮＡｖ２  ＨＲＮＰ４２が設けられてもよい。しかしながら、ＢＮＡｖ２プロトコルはユニシスの私的所有にかかるプロトコルであるため、ＢＮＡｖ２  ＨＲＮＰ４２はそれに関連したＩＰアドレスを有する必要はないことに留意されたい。ネットワークインタフェースカード（ＮＩＣ）５０がＮＴサーバ１０２のＩ／Ｏバス（たとえばＥＩＳＡまたはＰＣＩ）のスロットに取付けられる。この実施例においては、ウィンドウズＮＴとコンパチブルなＬＡＮタイプのいかなるＮＩＣを採用してもよい。好ましくは、ＮＩＣは高速イーサネットネットワーキングプロトコル（たとえば１００ベース−Ｔ）をサポートする。このタイプのＮＩＣは多くの販売者および相手先ブランドによる生産（ＯＥＭ）から入手可能である。これに代えて、イーサネット／８０２．３、ＦＤＤＩまたはギガビットイーサネットなどの他の物理媒体のタイプをサポートするＮＩＣを採用してもよい。典型的には、ＮＩＣの販売者はＮＩＣにデバイスドライバを添付して供給するであろう。このデバイスドライバはオペレーティングシステムのカーネルスペースにインストールされるため、システムの他のエンティティーがＮＩＣのネットワーキングファンクションにアクセスすることができる。図３の例示的なシステムのＮＩＣ５０は、示されるように、ウィンドウズＮＴカーネルスペースにインストールされたデバイスドライバ５４（<nicdrv>.sys）を有する。
この発明によると、第１および第２のネットワークプロトコルプロバイダ４４および５８の両方が、第２のコンピュータシステム１０２に取付けられた同じＮＩＣ５０を介してネットワーク１５にアクセスできるようにする装置および方法が提供される。すなわち、この発明は、ＮＩＣ５０が２つのシステム１００および１０２間で共有されるようにする。
この発明の装置は、Ａシリーズサーバ１００のＩ／ＯサブシステムをＮＴサーバ１０２のＩ／Ｏサブシステムに結合して、２つのサーバ間でデータが伝送され得るようにする相互接続と、第２のコンピュータシステム（すなわちＮＴサーバ１０２）で動作するルータ８０とを含む。ルータ８０は、第１のネットワークプロトコルプロバイダ（相互接続を介して）、第２のネットワークプロトコルプロバイダおよびＮＩＣ５０間でデータを経路制御し、ＮＩＣ５０が両方のネットワークプロトコルプロバイダによって共有されるようにする。より特定的には、ＮＩＣ５０によってネットワーク１５からデータが受信されると、ルータ８０は、データとともに受信されたネットワークアドレスが第１のネットワークアドレスと一致する場合には相互接続を介してデータを第１のネットワークプロトコルプロバイダ（たとえばＴＣＰ／ＩＰ  ＨＲＮＰ４４）に経路制御し、データとともに受信されたネットワークアドレスが第２のネットワークアドレスと一致する場合には受信データを第２のネットワークプロトコルプロバイダ（たとえばＴＣＰＩＰ．ＳＹＳ５８）に送る。ブロードキャストアドレスとともにネットワーク１５から受信されたデータは、第１（相互接続を介して）および第２のネットワークプロトコルプロバイダの両方に経路制御される。各ネットワークプロトコルプロバイダからの外に向かうデータは、同じＮＩＣ５０を介してネットワーク１５に経路制御される。しかしながら、第１および第２のネットワークプロトコルプロバイダのうちの一方からの外に向かうデータが他方のネットワークプロトコルプロバイダにアドレス指定される場合には、「ループバック」能力により、ルータ８０が、ＮＩＣ５０を迂回して、一方のネットワークプロトコルプロバイダから他方のものに直接データを経路制御する。さらに、ブロードキャストアドレスを有する、第１および第２のネットワークプロトコルプロバイダのうちの一方からの外に向かうデータは、共有のＮＩＣ５０を介してネットワーク１５に、さらにはループバック経路（ＮＩＣ５０を迂回する）を介して他方のネットワークプロトコルプロバイダに経路制御される。
この発明は各システムの一つのみのネットワークプロトコルプロバイダとの使用に限定されない。むしろこの発明は、各ネットワークプロトコルプロバイダが独自のネットワークアドレスを有するものとして、各システムの多数のネットワークプロトコルプロバイダに対してデータを経路制御するために用いることができる。入来データは、受信されたネットワークアドレスに基づいて、適切なネットワークプロトコルプロバイダに経路制御される。さらに、この実施例では、Ａシリーズサーバ１００のＴＣＰ／ＩＰネットワークプロトコルプロバイダ（たとえばＴＣＰ／ＩＰ  ＨＲＮＰ４４）にデータを経路制御できる他に、後にさらに説明するように、ルータ８０はＢＮＡｖ２ネットワーキングプロトコル（たとえばＢＮＡｖ２  ＨＲＮＰ  ４２）をサポートするネットワークプロトコルプロバイダにアドレス指定された入来データを経路制御できる。
以下に相互接続およびルータ８０をさらに詳細に説明する。
Ｉ．相互接続
上述のとおり、この発明の装置の相互接続はＡシリーズサーバ１００のＩ／ＯサブシステムをＮＴサーバ１０２のＩ／Ｏサブシステムに結合し、システム間に比較的高速なデータ経路を提供する。好ましくは、相互接続は第１および第２のコンピュータのＩ／Ｏサブシステム間の物理的接続と、ＮＴサーバの他のソフトウェアモジュールによる物理的接続へのアクセスを制御する相互接続デバイスドライバ７０とを含む。
Ａ．１つの実施例
図３の実施例では、物理的接続は、Ａシリーズサーバ１００のチャネルアダプタスロットに取付けられたフィードスルーカード６２と、ＮＴサーバ１０２のＩ／ＯバスのＥＩＳＡに取付けられたＥＩＳＡパーソナルコンピュータチャネルアダプタ（ＥＰＣＣＡ）カード６６と、ＡシリーズシステムのＣＳバスＩＩをフィードスルーカード６２を介してＥＰＣＣＡカード６６に接続するＣＳバスＩＩケーブルとを含む。相互接続デバイスドライバ（ＩＣＤ）７０はＮＴオペレーティングシステムのカーネルスペースにインストールされる。それはＮＴサーバの他のモジュールによる物理的接続（特定的にはＥＰＣＣＡカード６６）へのアクセスを制御する。
この発明のすべての実施例に必要なわけではないが、図３に示される実施例では、相互接続は、図１に示され、この明細書の背景の部分で説明した伝統的なユニシスのネットワーキングアーキテクチャにおける、似た名称の構成要素に類似するいくつかのモジュールをさらに含む。これらのモジュールは、図１のＱＳＰ２８と同様に機能するキューサービスプロバイダモジュール７６と、図１のＬＡＮＳＧモジュール２６と同様に機能するＬＡＮＳＧモジュール７８と、図１の対応の構成要素３０および３２と同様に機能するＮＳＭスタブおよびＬＬＭスタブモジュール８４および８６とを含む。さらに、ＬＤＭおよびＬＬＡＨモジュール８２および８８が設けられ、これらは伝統的なユニシスのネットワーキングアーキテクチャにおける、似た名称の構成要素（図示せず）と同様に機能する。物理的接続（すなわちフィードスルーカード６２、ケーブル６４およびＥＰＣＣＡカード６６）ならびに相互接続デバイスドライバ７０と組合せられて、これらのモジュールは、先に説明し図１に示されるタイプの伝統的なチャネルアダプタベースのネットワークプロセッサをシミュレートする。この態様で、この発明の特徴および利点は、Ａシリーズサーバ１００のネットワーキング構成要素（たとえばＣＮＳ３４、ＮＰＳＵＰＰＯＲＴ４０およびＭＣＰ１２など）を比較的少し変形しただけで達成できる。ＬＤＭ８２、ＮＳＭスタブ８４、ＬＬＭスタブ８６およびＬＬＡＨ８８モジュールの例外を除いて、相互接続の主な構成要素は、ウィンドウズＮＴカーネルレベルのデバイスドライバとして実装され、ＮＴカーネルスペースからユーザスペースにデータを転送する際に起こり得る不必要なデータの複製を回避する。相互接続の前述の構成要素およびモジュールの各々を以下により詳細に説明する。
１．ＥＰＣＣＡカード６６
ＥＩＳＡパーソナルコンピュータチャネルアダプタ（ＥＰＣＣＡ）カード６６が、ＮＴサーバ１０２内の利用可能なＥＩＳＡバススロットに差し込まれる。ＥＰＣＣＡカード６６は、ＮＴサーバ１０２のＥＩＳＡバスをケーブル６４およびフィードスルーカード６２を介してＡシリーズサーバ１００のＣＳバスＩＩにブリッジ接続する。フィードスルーカード６２はＩＯＭ１４内の利用可能なチャネルアダプタスロットに差し込まれ、ＣＳバスＩＩのデータおよび制御線に直接接続される。ＥＰＣＣＡカード６６のマイクロコードはＡシリーズチャネルアダプタをエミュレートする。
２．相互接続デバイスドライバ７０（ＰＣＣＡ７２およびＯＰＥＮＣＡ７４）
この実施例において、相互接続デバイスドライバ７０はＰＣＣＡデバイスドライバ７２とＯＰＥＮＣＡデバイスドライバ７４とを含む。ＰＣＣＡドライバ７２はＥＰＣＣＡハードウェア／マイクロコード６６を初期化したり、終了処理を行なったり、設定したり、それと通信したりする。ＰＣＣＡドライバ７２は手順インタフェースを介してＯＰＥＮＣＡドライバ７４と相互に作用する。この手順インタフェースはＥＰＣＣＡボード６６とＯＰＥＮＣＡ７４との間に３２バイトのＩ／Ｏメッセージ（ＩＯＭ）を送る。
ＯＰＥＮＣＡドライバ７４はＰＣＣＡ７２と相互接続の残りの構成要素との間の媒介物として作用し、データ経路のためのコントローラの機能を提供する。それはＰＣＣＡドライバ７２およびＥＰＣＣＡカード６６を介してＡシリーズサーバ１００から受信されたコマンドを解釈し、結果を作成し、ＮＴサーバ１０２とＡシリーズサーバ１００との間にデータを移動させるためのメモリディスクリプタをセットアップする。ＯＰＥＮＣＡは手順インタフェースを介してＱＳＰモジュール７６とインタフェースし、ＰＣＣＡドライバ６６によって使用されるＩＯＭベースのＡＰＩはＱＳＰ７６および相互接続の他のモジュールから隠蔽される。
３．キューサービスプロバイダ（ＱＳＰ）７６
ＱＳＰ７６は、ＮＳＭおよびＬＳＭスタブ８４および８６ならびにＬＡＮＳＧモジュール７８をＮＰＳＵＰＰＯＲＴ４０を介してＡシリーズサーバ１００の同類のものにインタフェースするために必要な、メッセージキュー機能を提供する。先に説明し図１に示したように、ＱＳＰ７６は伝統的なネットワークプロセッサのＱＳＰ２８と同様に機能する。特定的には、ＱＳＰ７６およびＮＰＳＵＰＰＯＲＴ４０は制御メッセージを交換して、パイプを初期化したり、確立したり、終了処理を行なったり、エラーを設定し報告する。それらはまた、データメッセージの最初におかれたヘッダを構築したり解析したりする。これらのヘッダはメッセージのブロック化、メッセージ長およびリモートキューリファレンス（ＲＯＲ）を特定する。上述のとおり、ＲＱＲはＬＡＮＳＧモジュールによって管理される線を介して多くのポイントツーポイントダイアログを多重化するために用いられる。ＬＡＮＳＧモジュールによって管理されるステーションに対応するＡシリーズサーバ１００のエンティティーは、それらが対応するステーションと同様に、一意のＲＱＲを割当てられる。これらのＲＱＲは後にＮＳＭ／ＮＳＭスタブおよびＬＬＭ／ＬＬＭスタブコントロールダイアログによって帯域外で交換される。ＲＱＲが交換されると、メッセージ発生側がヘッダに他方の側のＲＱＲを挿入し、これにより受信機は適切なキューにそのメッセージを割当てることができる。したがって、ＱＳＰ７６はＡシリーズサーバとＮＴサーバとの間の物理的接続を介して多数のダイアログが多重化されるようにする。
４．ＬＡＮステーショングループ（ＬＡＮＳＧ）７８
ＱＳＰ７６と同様に、ＬＡＮＳＧ７８は、先に説明し図１に示したように、伝統的なネットワークプロセッサにおけるＬＡＮＳＧ２６と同様に機能する。ＬＡＮＳＧ７８は特定の線上のステーショングループおよび各グループの個々のステーションの初期化および終了処理を制御する。それはまた、これらのグループの属性の設定および検索、非同期表示の報告およびその上へのデータメッセージの送信を制御する。この実施例において、ＬＡＮＳＧ７８はＳＴＲＥＡＭＳインタフェースを介してＱＳＰ７６と通信する。ＳＴＲＥＡＭＳはＵＮＩＸシステム上で普及した工業規格のデバイスドライバインタフェースであるが、ウィンドウズＮＴシステム用のものも入手可能である。この実施例では、ＳＴＲＥＡＭＳインタフェースは1145 Gayley Ave. Suite 315, Los Angeles, CA 90024 USAにあるMentat社から入手可能であるウィンドウズＮＴ（ＭＰＳ）用のMentatポータブルストリームという製品を用いてＮＴサーバ１０２上に実現される。
Ａシリーズサーバ１００上のネットワークプロトコルプロバイダ宛てのＮＴサーバからのデータ（たとえば共有ＮＩＣ５０を介してネットワーク１５から受信されたデータ）はＬＡＮＳＧ７８に送られ、その後ＱＳＰ７６、相互接続デバイスドライバ（ＩＣＤ）７０および物理的接続を介してＡシリーズサーバ１００のＮＰＳＵＰＰＯＲＴ４０に送られる。この実施例では、ＬＡＮＳＧモジュール７８は伝統的なユニシスのネットワークプロセッサのＬＡＮＳＧモジュール２６と似た態様で物理線を管理する。しかしながらこの実施例では、ＬＡＮＳＧモジュール７８が管理する線はＮＴサーバ１０２に取付けられたネットワークインタフェースカードによって実装される。たとえば、ＮＴサーバ１０２に取付けられた共有ＮＩＣ５０はＬＡＮＳＧモジュール７８によって管理される１つの線を規定する。２以上の共有ＮＩＣ５０がＮＴサーバ１０２にインストールされてもよく、各々はユニシスのネットワーキングアーキテクチャの、異なった線を規定する。さらに、「異種コンピュータシステム間の高速通信に関するバーチャルＬａｎインタフェース（A Virtual Lan Interface For High-Speed Communications Between Heterogeneous Computer Systems）」と題された同時係属中の出願連続番号第＿＿＿＿＿（事件番号：ＵＳＹＳ−００３８／ＴＮ０８６に記載されているように、ＮＴサーバのメモリスペース内のシミュレーテッドＦＤＤＩローカルエリアネットワークにより、ＬＡＮＳＧモジュール７８内に別の線が規定される。同時係属中の出願に記載されているように、シミュレートされたＦＤＤＩネットワークはここに説明される相互接続と組合せられて、各サーバのＴＣＰ／ＩＰネットワークプロトコルプロバイダ４４および５８間に接続に関する問題の別の解決策を提供する。この実施例では、シミュレートされたＦＤＤＩローカルエリアネットワークは常に線０として規定される。
ＬＡＮＳＧモジュール７８は、アダプタ名に対する線番号のマッピングを維持する。線番号はＡシリーズサーバ１００に入力された設定コマンドによってステーショングループに割当てられる。ＬＬＭはこれらの線番号をＬＬＭスタブ８６に送る。アダプタ名はＮＩＣがＮＴサーバ１０２に組込まれるとウィンドウズＮＴによって割当てられ、ウィンドウズＮＴレジストリにストアされる。ＬＡＮＳＧ７８はレジストリ内でＬＡＮＳＧ７８と組み合わされたこれらのＮＩＣのアダプタ名を得て、関連の線番号および他の情報へのマッピングを維持できる。下記の表は使用中の各線番号について維持される情報を示す。
0003694532.tif 000002
５．ロード／ダンプモジュール（ＬＤＭ）８２
ＬＤＭ８２はネットワークプロセッサファームウェアファイル（従来のネットワークプロセッサの初期化時に行なわれるプロセス）の、ＮＴサーバ１０２のＣＮＰプラットホームへのロードをシミュレートし、ＣＮＰ状態ダンプを初期化するための機構を提供する。ＬＤＭはＮＴサーバ１０２がブートアップするときにＮＴサービスとして初期化される、実行可能なファイルＣＮＰ．ＥＸＥの内部にある。シミュレートされたファームウェアのロードの一部分として、ＬＤＭ８２はＮＳＭスタブプロセス８４を初期化し、これによりＬＬＭスタブプロセス８６およびＱＳＰ７６が初期化される。
６．ネットワークサービスモジュールスタブ（ＮＳＭスタブ）８４
ＮＳＭスタブモジュール８４もまた、実行可能なＣＮＰ．ＥＸＥの一部分であり、Ａシリーズサーバ１００のＮＳＭ３６（ＣＮＳ３４の構成要素）によってそれに送信されたコマンド／応答を実行する責任を持つ。基本的に、それは典型的なユニシスのネットワークプロセッサのＮＳＭスタブ３０の機能を果たす。この実施例では、ＮＳＭスタブ８４は規格ＳＴＲＥＡＭＳ呼び出し（すなわちopen, colse, ioctl, putmsg, getmsg）を用いてＳＴＲＥＡＭＳインタフェースを介してＱＳＰモジュール７６とインタフェースする。
７．リンク層マネージャスタブ（ＬＬＭスタブ）８６
ＣＮＰ．ＥＸＥの一部分でもあるＬＬＭスタブモジュール８６は、Ａシリーズサーバ１００のＬＬＭ３８（ＣＮＳ３４の構成要素）によってそれに送られたコマンド／応答を実行する責任を持つ。基本的に、それは典型的なユニシスのネットワークプロセッサのＬＬＭスタブ３２の機能を果たす。この実施例において、ＬＬＭスタブ８６も同様に、規格ＳＴＲＥＡＭＳ呼び出し（すなわちopen, colse, ioctl, putmsg, getmsg）を用いてＳＴＲＥＡＭＳインタフェースを介してＱＳＰモジュール７６とインタフェースする。
８．リンク層属性ハンドラ（ＬＬＡＨ）８８
ＣＮＰ．ＥＸＥ内の別のモジュールであるＬＬＡＨモジュール８８は、従来のユニシスのネットワークプロセッサにおけるその同等物と同様に機能する。特定的には、ＬＬＡＨモジュール８８は属性リストの解析、確認および構築に関連した詳細な処理を行なう責任を持つ。ＬＬＡＨは属性範囲の妥当性ルールを適用し、属性間の一貫性をチェックする。ＬＬＭスタブ８６はＬＬＡＨとインタフェースする唯一のモジュールである。
Ｂ．ホストインタフェースファンクション（ＨＩＦ）−代替的な実施例
依然として図３を参照して、この実施例におけるＰＣＣＡおよびＯＰＥＮＣＡドライバ７２および７４を含む相互接続デバイスドライバ７０と、フィードスルーカード６２、ケーブル６４およびＥＰＣＣＡカード６６によって形成される物理的接続とによって、ホストインタフェースファンクション（ＨＩＦ）が規定される。この発明の別の特徴によると、ＨＩＦのＱＳＰ７６と相互接続デバイスドライバ７０との間の手順インタフェースはＨＩＦからＱＳＰ７６を分離させるように設計される。これにより、ＨＩＦの種々の実現例にこの発明を採用することが可能になる。具体的には、ＱＳＰ７６と相互接続デバイスドライバ７０との間の手順インタフェースは、あるプロセスにより確立され、そのプロセスによって各モジュールはその機能を実現させる手順へのエントリポイント（すなわちポインタ）を、所要の任意の変数値とともに、公開する。ＮＮＳＤＲＬＯＧ．ＳＹＳ（図示せず）と呼ばれる別のデバイスドライバが、これらのエントリポイントの記録を維持する。
ＨＩＦの相互接続デバイスドライバ７０は下記のエントリポイントおよび属性を登録する。
HifSendBlockToHost()−−データのブロックをＭＣＰに送るためにＱＳＰによって呼び出される関数。
HifOpenUnit()−−ＬＡＮＳＧモジュール７８から受信されたデータがそれを介してＡシリーズサーバ１００上の適切なエンティティーに伝送され得るいくつかのパイプ（ユニット）のうち１つを初期化するためにＱＳＰによって呼び出される関数。
HifCloseUnit()−−パイプ（ユニット）のうち１つに終了処理が行なわれたことを示すＱＳＰによって呼び出される関数。
maxQueuesSupported−−Ａシリーズサーバ１００のＭＣＰ１２にメッセージを送信するためにいくつのパイプ（キュー／ユニット）を使用することができるかを決定するためにＱＳＰが参照し得る、ＨＩＦによって初期化される変数。
プラットホーム−−ＨＩＦの特定の実現例（２つの代替的なＨＩＦの実現例が以下に説明され、図４および図５にそれぞれ示される）を特定する、ＨＩＦによって初期化される変数。この実施例において、これらのファンクションおよび変数は相互接続デバイスドライバ７０のＯＰＥＮＣＡドライバ７４によって実装される。
同様に、ＱＳＰ７８は以下のエントリポイントを登録する。
QspAckBlockToHost()−−メッセージの特定のブロックがＭＣＰ１２にうまく送られたことをＱＳＰ７８に示すためにＩＣＤによって呼び出される関数。
QspReset()−−相互接続を介するＭＣＰ１２との通信が途絶え、かつ処理中メッセージをフラッシュする必要があることをＱＳＰ７８に示すために、ＩＣＤによって呼び出される関数。
QspLRPut()−−ＡシリーズサーバからデータのブロックをＱＳＰ７８に送るためにＩＣＤによって呼び出される関数。
これらの関数のうち１つを呼び出すためには、その関数に関して登録されているエントリポイントの呼び出しが行なわれる。この間接性の結果、種々のＨＩＦの実装に対する種々の相互接続デバイスドライバのインストールがＱＳＰ７６にとって完全に透過的な態様で行なえる。
図４および図５はＨＩＦの２つの代替的な実施例を示し、これらは上述の手順インタフェース設計によってもたらされるモジュール方式を示す。図４において、物理接続（すなわちフィードスルーカード６２、ケーブル６４およびＥＰＣＣＡカード６６）が、Ａシリーズサーバ１００のＩＯＭ１４のＣＭＵ１８ｂのうち１つにあるポートにケーブル６５を介して接続されるＰＣＩブリッジカード６７と置換されている。ＣＭＵに直接接続することにより、ＣＳバスＩＩプロトコルの持つ特有のレイテンシがいくぶん回避される。これにより、２つのサーバ１００および１０２のＩ／Ｏサブシステム間に、より直接的で高速な接続がもたらされる。物理的接続が変更されたことにより、変形された相互接続デバイスドライバ７０′がもたらされる。変形された相互接続デバイスドライバ７０′はＱＳＰ７６とＰＣＩブリッジカード６７上のハードウェアとの間にインタフェースをもたらす単一のデバイスドライバモジュールＰＸＮ７３を含む。しかしながら、手順インタフェースと、それによってＱＳＰ７６および相互接続デバイスドライバ７０′がそのインタフェースのそれぞれの手順にエントリポイントを登録する機構とは変更されない。したがって、ＨＩＦに加えた変更はコオペラティブネットワークプラットフォーム（ＣＮＰ）を成すこの発明のＱＳＰ７６および他のモジュールに対して透過的である。
図５は、ＮＴサーバ１０２のソフトウェアによってＡシリーズシステムがエミュレートされる実施例である。ユニシスはClearPath ＨＭＰ ＮＸ４２００シリーズエンタープライズサーバにおいてこのようなエミュレートされたシステムを提供する。この実施例では、物理的接続が、エミュレートされたＩ／Ｏサブシステム１４′のメモリスペースとＮＴシステムのメモリスペースとの間のメモリ間接続６３となるようにエミュレートされる。エミュレートされた接続６３は図３のハードウェア実装のフィードスルーカード６２、ケーブル６４、ＥＰＰＣＡカード６６およびＰＣＣＡ７２に類似した態様で機能する。この実施例における相互接続デバイスドライバ７０″は図３の実現例のＯＰＥＮＣＡモジュール７４の変形例７４′を含む。しかしながらここでもまた、変形されたＯＰＥＮＣＡモジュール７４′とＱＳＰ７６との間の手順インタフェースは変更されないため、エミュレートされたＡシリーズサーバと、ＮＴサーバへの、そのエミュレートされた接続６３とは、コオペラティブネットワークプラットフォーム（ＣＮＰ）を成すこの発明のＱＳＰ７６および他のモジュールに透過的である。
Ｃ．動作
図６Ａから図６Ｆは、ＨＩＦの相互接続デバイスドライバおよびＱＳＰモジュール７６を介してＡシリーズサーバ１００とＮＴサーバ１０２との間にいかにしてデータが転送されるかをさらに詳細に示す。図６Ａから図６Ｅに示される詳細は、図３、図４および図５に示されるＨＩＦの３つの実施例すべてに適用可能である。したがって、以下の説明に用いられるように、相互接続デバイスドライバ（ＩＣＤ）という用語は上述の３つの相互接続デバイスドライバの実施例すべてを意味する。
ＱＳＰ７６は１つまたはそれ以上の転送ユニットを介して多数のクライアントダイアログ（たとえばＮＳＭスタブおよびＬＬＭスタブモジュール８４および８６ならびにＬＡＮＳＧ７８によって規定される種々のステーションとのダイアログ）を多重化する。ユニットは相互接続デバイスドライバ（ＩＣＤ）によってサポートされた通信経路の抽象物である。ユニットは論理的ダイアログであっても物理的デバイスであってもよい。ユニット資源をより十分に利用するために、ＱＳＰ７６は同じユニットを介して転送されるメッセージを集めて、単一の動作で転送され得るブロックを作成してもよい。ＱＳＰ７６は、そのメッセージヘッダにメッセージカウントフィールドを設けることにより、このようなブロック化をサポートする。ブロック内の最初のメッセージヘッダは、ブロックが含むメッセージ数をそのメッセージカウントフィールドに含む。ブロック内の後のメッセージヘッダはそのフィールド内に０の値を有する。
その後ＩＣＤは各ブロックを取出し、そのブロックをＡシリーズサーバに転送するために物理的接続（すなわち、実装に依存して、ＥＰＰＣＡボード６６、ＰＣＩブリッジカード６７またはエミュレートされたメモリ間接続６３）をプログラミングする。逆方向に、割込（図３および図４のハードウェア接続の場合）または関数コール（図５のエミュレートされた接続６３の場合）のいずれかによって、ＮＴサーバ１０２のメモリに、物理的接続を介してメッセージが転送されると、ＩＣＤは動作状態になる。ＩＣＤは受信したメッセージをＱＳＰ７６に送り、これは、メッセージに関連したＲＱＲに基づいて、適切なクライアントダイアログ（たとえばＮＳＭスタブ８４、ＬＬＭスタブ８６、またはＬＡＮＳＧ７８によって規定される所与のステーション）にそれを分配する。
図６Ａから図６Ｄは物理的接続を介してＡシリーズサーバ１００にＮＴサーバ１０２（たとえばＮＳＭスタブ８４、ＬＬＭスタブ８６またはＬＡＮＳＧ７８によって規定されステーション）のクライアントからのメッセージを転送するにあたり、ＱＳＰ７６によって行なわれるステップに関するさらなる情報を提供する。この転送プロセスは、ＮＩＣ５０から受信したデータをＡシリーズサーバ１００に送る必要があると思われるクライアント、たとえばＬＡＮＳＧモジュール７８が、ＱＳＰ７６を呼び出してメッセージ（たとえばネットワークから受信したデータ）をＡシリーズサーバ１００に転送することを要求する際に、開始する。要求とともにメッセージ全体を構成する隣接していないメッセージセグメントをポイントするパラメータが送られる。ステップ１１２において、ＱＳＰ７６はどのユニットにメッセージが転送されるべきかを決定する。次に、ステップ１１４において、ＱＳＰ７６はメッセージにおける隣接していない各セグメントを検証することにより、メッセージの全サイズを計算する。ステップ１１６において、メッセージの初めにヘッダが付与され、ヘッダおよびメッセージの各セグメントをポイントするディスクリプタリストが構築される。次に、ステップ１１８においてＱＳＰ７６はこのユニットに関してブロック化（上述）がサポートされているか否かを決定する。そうであれば、ステップ１２０において、ＱＳＰ７６は現在転送を待機しているブロックがあるか否かを判断する。そうであれば、ステップ１２１において、ＱＳＰ７６はメッセージが処理中の最新のブロックにうまく挿入できるか否かを判断する。そうであれば、ステップ１２２において、ＱＳＰ７６は処理中の最新のブロックにディスクリプタリストを付与する。その後制御はステップ１２７に移行する（図６Ｂ）。
ステップ１１８においてこのユニットに関してブロック化がサポートされていない場合、またはステップ１２０において、現在転送待ちであるブロックがないと判断された場合、またはステップ１２１において、処理中の最新のブロックにメッセージが挿入できないと判断された場合、制御はこれらの３つの場合すべてにおいてステップ１２４に移行する。ステップ１２４において、ＱＳＰ７６はステップ１１６において構築されたディスクリプタリストのみを含むブロックを構築する。次に、ステップ１２６において、処理中ブロックのリストに新たに作成されたブロックが付与される。その後制御はステップ１２７に移行する（図６Ｂ）。
次に図６Ｂを参照して、ステップ１２７において、ＱＳＰ７６は処理中ブロックがあるか否かを判断する。なければ、ＱＳＰ７６は単にクライアントに戻る。しかしながら、転送されるべき処理中ブロックがあれば、制御はステップ１２８に移行する。
ステップ１２８において、ＱＳＰ７６は、ＩＣＤのHifSendBlockToHost()手順を呼び出すことにより処理中ブロックのリストの第１のブロックをＩＣＤに送信することを試みる。「Ａ」と明示された矢印によって示されるように、ＩＣＤはその時点で要求の処理を開始する。ＩＣＤによって行なわれるステップは図６Ｃに示される。しかしながら、依然として図６Ｂを参照して、ＱＳＰの処理はステップ１３０へと続き、ここでＱＳＰ７６はＩＣＤが転送用のブロックを受入れたかどうかを判断する。そうであれば、そのブロックがステップ１３２において処理中リストから除去され、制御ループはステップ１２７に戻り、ここでＱＳＰ７６は転送されるべき処理中ブロックがあるかどうかを再度チェックし、処理はこのような後続のブロックに関してさらに続いて行なわれる。しかしながら、ステップ１３０において、ＩＣＤが転送用の所与のブロックを受入れていないと判断された場合、送信されるべきメッセージを含むブロックを処理中リストに残してＱＳＰ７６はクライアントに戻る。
次に図６Ｃを参照して、ＩＣＤはステップ１３４においてＱＳＰからのHifSendBlockToHost()要求の処理を開始し、ここで物理的接続がフロー制御モードであるか否かを判断する。フロー制御モードはＡシリーズサーバ１００のＭＣＰオペレーティングシステムが、たとえば利用可能なバッファがないために、特定のユニット上のデータを受信する準備ができていないモードである。物理的接続がフロー制御モードである場合、ＩＣＤは「False」の値をＱＳＰ７６に戻し、この時点で転送の処理を停止する。物理的接続がフロー制御モードでない場合、制御はステップ１３６に移行し、ここでＩＣＤは、物理的接続がGatherファンクションをサポートするか否かを判断する。Gatherとは、隣接していないメモリ領域からのデータを１回の動作で転送できる能力である。物理的接続がGather能力をサポートしない場合、制御はステップ１３８に移行し、ここでＩＣＤは、ディスクリプタリスト（ＱＳＰ７６によってそれに送られている）によってポイントされたデータを、隣接したバッファに複製する。次に、ステップ１４０において、ＩＣＤは隣接した単一のバッファをポイントする擬似ディスクリプタリストを構築する。その後制御はステップ１４２に移行する。
ステップ１３６（Gatherサポートあり）またはステップ１４０（Gatherサポートなし）から直接入ったステップ１４２において、ＩＣＤは、ＱＳＰ７６（Gather）から受信したディスクリプタリストまたはステップ１４０（Gatherなし）において作成された擬似ディスクリプタリストのいずれかによってポイントされたデータを転送するために、物理的接続（すなわち、特定の実施例に依存して、ＥＰＣＣＡボード６６、ＰＣＩブリッジカード６７またはエミュレートされたメモリ間接続６３）をプログラミングする。その後ＩＣＤは「True」の値をＱＳＰ７６に戻す。
図６Ｄは、転送が完了したときにＩＣＤおよびＱＳＰ７６によって行なわれるステップを示す。示されるように、転送が完了するとＩＣＤが動作状態になる。ステップ１４４において、ＩＣＤは、転送がうまく完了したか否かを示す表示を受ける。そうでなければ制御はステップ１４６に移行し、ここでＩＣＤは、たとえば問題となっているブロックの再転送および物理的接続のリセットなどによって、エラーの回復を試みる。転送がうまく完了している場合、制御はステップ１４８に移行する。ステップ１４８において、ＩＣＤは物理的接続のフロー制御状態を調整する。これは上述の物理的接続の実施例においては相互接続がポーリングされるために行なわれる。転送が完了すると、相互接続は、それが再度ポーリングされるまで別の転送を開始することができず、これを反映するためにフロー制御状態が調整される。次にステップ１５０において、ＩＣＤは転送が完了したことをＱＳＰに知らせ、どのディスクリプタリストが転送されたかを示すためにQspAckBlockToHost()手順を呼び出す。ステップ１５２において、ＩＣＤはクリーンアップ手順を行ない、その後リターンする。
ポイント「Ｂ］に示されるように、ＱＳＰ７６が、転送がうまく完了したことをそれに知らせる、ＩＣＤからのQspAckBlockToHost()表示を受信すると、ＱＳＰ７６はステップ１５４に入り、ここで転送されたブロックのすべてのメッセージが解放され、それらを送信したクライアントに対して、それらがうまく転送されたことを知らせるようにする。ステップ１５６において、メッセージヘッダおよびディスクリプタリストを含むブロック構造がリサイクルされ、後の転送に利用できるようにされる。その後制御は図６Ｂのステップ１２７に戻り、後のブロックを処理する。
図６Ｅおよび図６Ｆは、ＮＴサーバ１０２を介してＡシリーズサーバ１００からのメッセージを伝送するにあたり、ＩＣＤおよびＱＳＰ７６によって行なわれるステップを示す。示されるように、物理的接続を介してＡシリーズサーバからメッセージを受信する前に、ＩＣＤは空の受信バッファが接続に利用できるようにする。物理的接続を介して（たとえば図３の実施例におけるフィードスルーカード６２、アクロスケーブル６４およびＥＰＣＣＡカード６６を介して）ＮＴサーバにＡシリーズサーバ１００からメッセージが転送されると、ＩＣＤはそれが準備した空の受信バッファのうち１つにメッセージが受信されたことを示す表示によって動作状態となる。ステップ１５８において、ＩＣＤはQspLRPut()関数を用いてＱＳＰ７６にメッセージを送り、リターンする。
ステップ１６０において、ＱＳＰ７６は、メッセージが制御メッセージであるか否かを判断する。制御メッセージであれば、ステップ１６４において、ＱＳＰ７６はそこで制御メッセージを処理し、その後ステップ１６６においてメッセージを解放し、リターンする。メッセージが制御メッセージでない場合、制御はステップ１６２に移行する。ステップ１６２において、ＱＳＰ７６はどのステーションがメッセージを受信するかをメッセージヘッダにおけるＲＱＲから判断する。次に、ステップ１６８において、メッセージが適切なステーションに送られる。
次に図６Ｆを参照して，ＱＳＰ７６またはそのクライアントのうち１つがメッセージバッファを解放する際に、ＩＣＤのフリーメッセージコールバックファンクションが呼び出される。ステップ１７０において、ＩＣＤは解放されたバッファを、上述の態様で、後のメッセージを受信するために物理的接続が後に使用し得る利用可能なバッファのリストに付与する。
II．ルータ８０
例示の目的で図３を再度参照して、上述のとおり、ルータ８０は第１のコンピュータシステム（相互接続を介する）の第１のネットワークプロトコルプロバイダ（たとえばＢＮＡｖ２  ＨＲＮＰ４２またはＴＣＰ／ＩＰ  ＨＲＮＰ４４）、第２のコンピュータシステムの第２のネットワークプロトコルプロバイダ（たとえばＴＣＰＩＰ．ＳＹＳ５８）および第２のコンピュータシステム上のＮＩＣ５０の間でデータを経路制御し、ＮＩＣ５０が両方のネットワークプロトコルプロバイダによって共有できるようにする。
図７は、この発明の好ましい実施例に従ってルータ８０が提供するさまざまなデータ経路を示す。ＮＩＣ５０によってネットワーク１５からデータが受信されると、ルータ８０は、経路１７４によって示されるように、データと共に受信されたネットワークアドレスが第１のネットワークアドレスと一致する場合には、相互接続を介してデータを第１のネットワークプロトコルプロバイダ（たとえばＴＣＰ／ＩＰ  ＨＲＮＰ４４またはＢＮＡｖ２  ＨＲＮＰ４２）に経路制御する。受信データのアドレスが第２のネットワークプロトコルプロバイダ（たとえばＴＣＰＩＰ．ＳＹＳ５８）のものと一致する場合には、経路１７２で示されるように、データはネットワークプロトコルプロバイダに経路制御される。ネットワーク１５から受信されたブロードキャストアドレスを持つデータは第１（相互接続を介する）および第２のネットワークプロトコルプロバイダの両方に経路１７２および１７４を介して経路制御される。各ネットワークプロトコルプロバイダからの外に向うデータは、それぞれの経路１７２および１７４を介してＮＩＣ５０に経路制御される。しかしながら、第１および第２のネットワークプロトコルプロバイダのうち一方からの外に向うデータが、他方のネットワークプロトコルプロバイダにアドレス指定される場合、「ループバック」能力により、ルータ８０が、経路１７６で示されるようにＮＩＣ５０を迂回して、一方のネットワークプロトコルプロバイダから他方のものに直接データを経路制御できるようになる。さらに、ブロードキャストアドレスを有する第１および第２のネットワークプロトコルプロバイダのうち一方からの外に向うデータは、それぞれの経路１７２または１７４を介して共有のＮＩＣ５０に経路制御され、さらには、ＮＩＣ５０を迂回してループバック経路１７６を介して他方のネットワークプロトコルプロバイダに経路制御される。この実施例では、「ループバック」経路１７６はＴＣＰ／ＩＰ間での転送に関してのみ実現される。
図３および図７にさらに示されるように、この発明は各システムの一方のネットワークプロトコルプロバイダのみに対する使用に限定されない。むしろこの発明は、各ネットワークプロトコルプロバイダがそれ自体のネットワークアドレスを有するものとして、各システムの多数のネットワークプロトコルプロバイダ間でデータを経路制御するために用いることができる。さらに、この実施例において、Ａシリーズサーバ１００のネットワークプロトコルプロバイダはＴＣＰ／ＩＰネットワークプロトコルプロバイダ（たとえばＴＣＰ／ＩＰ  ＨＲＮＰ４４）およびＢＮＡｖ２ネットワークプロトコルプロバイダ（たとえばＢＮＡｖ２  ＨＲＮＰ４２）の両方を含んでもよい。この実施例において、ルータ８０は同一人に譲渡された「複数のコンピュータプラットホームにワークステーションをインタフェースするための方法および装置（“Method and Apparatus for Interfacing a Workstation to a Plurality of Computer Platforms”）」（Johnson et al.）と題された米国特許第５，３７９，２９６号に記載されている方法に従って、ＢＮＡｖ２フレームとＴＣＰ−ＩＰフレームとを区別し、この文献ほ全体は引用によって援用される。
図８は、好ましい実施例に従うルータ８０の実現例をさらに詳細に示すブロック図である。この実施例において、ＬＡＮＳＧ７８およびＱＳＰ７６の両方が、ＮＴオペレーティングシステムのカーネルスペース内のカーネルレベルデバイスドライバとして実装される。ＬＡＮＳＧ７８とＱＳＰ７６との間のインタフェースはウィンドウズＮＴランタイム環境でMentatポータブルストリーム（ＭＰＳ）を用いて実装されたＳＴＲＥＡＭＳインタフェースである。この実施例では、ルータ８０の機能は２つの構成要素、すなわちトランスポートドライバ構成要素（ＪＴＤ）１８２およびＮＩＣドライバ構成要素（ＪＮＤ）１８４において実現される。ＪＮＤ構成要素１８４はここにおいてＪＡＮＵＳ．ＳＹＳと呼ばれるＮＤＩＳミニポートＮＩＣドライバの形態で実装される。「Janus」は、反対方向を向く２つの顔で描かれた門および戸口の古代の神として、ローマ神話から由来する。ＪＴＤ構成要素はＬＡＮＳＧ．Ｃモジュール（ＬＡＮＳＧ機能を含む）から別個にコンパイルされるが、ＬＡＮＳＧ．ＳＹＳの部分としてリンクされたモジュール（ＪＴＤ．Ｃ）として実装される。
ルータ８０のＪＴＤ構成要素１８２は、この発明に従って入来データを経路制御する必要がある、Ａシリーズサーバ１００およびＮＴサーバ１０２上のネットワークプロトコルプロバイダのＩＰアドレスを含む、それが責任を持つ各ＮＩＣの状態によってアダプタテーブルを維持する。以下に、アダプタテーブルのＣ言語構造体を示す。
0003694532.tif 000003
構造体の「adapter_name」フィールドはエントリが表わす特定の共有ＮＩＣ（たとえばＮＩＣ５０）に割当てられたアダプタ名を含む。「jtd_adapter_handle」および「medium」フィールドはＮＤＩＳ仕様のNdisOpenAdapter関の戻り値を含む。「packet_pool_handle」および「buffer_pool_handle」フィールドはＮＤＩＳ仕様のNdisAllocatePacketPoolおよびNdisAllocateBufferPool関数の戻り値を含む。「jnd_adapter_handle」フィールドはＪＮＤ構成要素１８４から得られた値を含む。この値はアダプタを識別するためにＪＮＤによって使用される一意のハンドルを表わす。「mcp_ip_addr」フィールドはこの特定のＮＩＣを共有するＡシリーズドライバのネットワークプロトコルプロバイダ（たとえばＴＣＰ／ＩＰ  ＨＲＮＰ４４）のＩＰアドレスを含み、「nt_ip_addr」フィールドはこのＮＩＣを共有するＮＴサーバ１０２上のネットワークプロトコルプロバイダ（たとえばＴＣＰＩＰ．ＳＹＳ５８）のＩＰアドレスを含む。これに代えて、他の実施例では、所与のネットワークプロトコルプロバイダに対して単一のアダプタ線上に多数のＩＰアドレスをサポートしてもよい。
ＪＴＤ．ＣはＬＡＮＳＧ．ＣによってＬＡＮＳＧ．ＳＹＳにリンクされこの情報がＬＡＮＳＧのステーショングループテーブルにストアされるが、この設計において、別個の（しかしリンクされた）アダプタテーブルを選択して、ＪＴＤ．ＣにおいてＮＤＩＳインタフェースを分離して、ステーショングループテーブルのサイズを最小にする（ステーショングループの属性をセットするためのＬＬＭスタグおよびＬＡＮＳＧ．Ｃからのインタフェースにステーショングループテーブルサイズの「マスク」が使用される）。アダプタテーブルはアダプタテーブルの所与のエントリをポイントするステーショングループテーブルにおける下記の付加的なエントリによって、ＬＡＮＳＧ７８のステーショングループテーブルにリンクされる。
0003694532.tif 000004
ＪＴＤ構成要素１８２は下記のように入来データを経路制御する必要があるサーバ１００および１０２の各々のＴＣＰ／ＩＰネットワークプロトコルプロバイダのＩＰアドレスを得る。ＮＴサーバ１０２において、ＴＣＰＩＰ．ＳＹＳ５８が特定のＮＩＣ（たとえばＮＩＣ５０）上のＩＰアドレスを使用するよう構成される場合、それは下記の場所において、ウィンドウズＮＴレジストリにＩＰアドレスを含むエントリをストアする。
0003694532.tif 000005
ＪＴＤ構成要素１８２は「共有される」ように設定されたＮＩＣのすべてに関するレジストリのこの場所にアクセスし、そのローカルテーブルに、各共有ＮＩＣに関するレジストリから検索されたＩＰアドレスをストアし得る。
Ａシリーズサーバ１０２において、ＩＰアドレスはＮＷ  ＴＣＰＩＰ  ＴＣＰＩＰＩＤコマンドを用いて設定される。このコマンドは、Ａシリーズサーバ１００上のＴＣＰ／ＩＰ  ＨＲＮＰが、ネットワークプロセッサおよびそのネットワークプロセッサ上の線に、単一のＩＰアドレスを関連付けるようにする。上述のとおり、この実施例では、相互接続は、Ａシリーズサーバの観点から従来のネットワークプロセッサをシミュレートする。上述の「異種コンピュータシステム間の高速通信に関するバーチャルＬａｎインタフェース（″A Virtual Lan Interface For High-Speed Communications Between Heterogeneous Computer Systems″）」と題された同時係属中の出願連続番号第＿＿＿＿＿（事件番号：ＵＳＹＳ−００３８／ＴＮ０８６）に記載されているシミュレートテッドＦＤＤＩネットワークのために線０が予約される。この発明に従って共有されるＮＩＣには線０より上の線番号が使用され得る。ＬＡＮＳＧは先に説明したとおり特定のアダプタに線番号をマッピングする。ＴＣＰＩＰ  ＨＲＮＰ４４が特定のＩＰアドレスによって設定される場合、それは他のさまざまなデータとともに、セットステーションインタフェース（ＳＳＩ）コマンドを用いて、設定されたＩＰアドレスをＬＬＭスタブ８６に送信する。ＬＡＮＳＧ７８はＬＬＭスタブ８６からＳＳＩコマンドを受信し、そのテーブルに付与するために、ルータ８０のＪＴＤ構成要素１８２にＩＰアドレスを送る。
ＬＡＮＳＧ７８はさらに、そのテーブルにおける特定の共有ＮＩＣに関連したＩＰアドレスのマッピングを維持する。下記のテーブルはこのマッピングに関して維持された情報を示す。
0003694532.tif 000006
示されるように、各共有ＮＩＣ（そのアダプタハンドルによって識別される）について、特定のＮＩＣを共有するＡシリーズサーバ１００上のネットワークプロトコルプロバイダのＩＰアドレスと、ＮＩＣを共有するＮＴサーバ上のネットワークプロトコルプロバイダのＩＰアドレスとの両方に、マッピングが維持される。
ＮＩＣ５０およびそのデバイスドライバ（<nicdrv>.sys）５４が、ＮＩＣベンダによって供給される指示書に従って通常の態様で取付けられる。しかしながら、ＮＩＣ５０（および他の任意の共有ＮＩＣ）のウィンドウズＮＴのバインディングの設定は、ＮＩＣおよびそのドライバが取付けられるときに、元の設定から変更される必要がある。特定的には、Janus ＮＩＣドライバ（ＪＮＤ）およびルータ８０のJanusトランスポートドライバ（ＪＴＤ）構成要素をバインディングに挿入する必要がある。すべてのＮＴトランスポートドライバ（たとえばＴＣＰＩＰ．ＳＹＳ）がＪＮＤにおける「アダプタ」に再バインドされる必要がある。さらに、ＪＴＤはトランスポートドライバとしてＮＩＣドライバ５４に再バインドする必要がある。ＪＴＤはＬＡＮＳＧ．ＳＹＳにリンクされるモジュールとして実装されるため、ＬＡＮＳＧ．ＳＹＳは実際にはトランスポートドライバとしてインストールされる。
上述のものの他に、ウィンドウズＮＴレジストリには新たなエントリ−EnableIPRoutingInMCPが必要である。このレジストリエントリは、「未知の」ＩＰアドレスを有するフレームのためのＩＰルータとしてＡシリーズサーバ１００上のＴＣＰ／ＩＰ  ＨＲＮＰ４４を指定し、Ａシリーズサーバ１００のＩＰルータとＮＴサーバ１０２のＩＰルータとの関係を指定する（能動化されている場合）ために、ＪＴＤ構成要素によって用いられる。EnableIPRoutingInMCPは３つの値をとり得る。すなわち、「Primary」、「Secondary」および「Disabled」である。「Primary」にセットされた場合、ＪＴＤは未知のＩＰアドレスを有する内に向うＩＰまたはＡＲＰフレームすべてを相互接続を介してＡシリーズサーバ１００のＴＣＰ／ＩＰ  ＨＲＮＰ４４に与える。EnableIPRoutingInMCPが「Secondary」にセットされた場合、ＪＴＤはEnableIPRouting（既存のＮＴレジストリエントリ）がセットされていないならば、未知のＩＰアドレスを有する内に向うＩＰまたはＡＲＰフレームすべてをＡシリーズサーバ１００のＴＣＰ／ＩＰ  ＨＲＮＰ４４に与えるだけである。EnableIPRoutingがセットされている場合、それが優先され、未知のＩＰアドレスを有するＩＰまたはＡＲＰフレームはＮＴサーバ１０２のＴＣＰＩＰ．ＳＹＳ５８に送信される。EnableIPRoutingInMCPが「Disabled」にセットされた場合、ＪＴＤは未知のＩＰアドレスを有する内に向うＩＰまたはＡＲＰフレームすべてをＴＣＰ／ＩＰ  ＨＲＮＰ４４に与えるのではなく、このようなフレームをＴＣＰＩＰ．ＳＹＳ５８に送信する。
ＡシリーズサーバではＣＮＳ３４ソフトウェアに変更が加えられる。まず、下記のようにＬＡＮタイプの接続グループに対して２つの新しい属性が規定されている。
１．ＡＤＡＰＴＥＲＮＡＭＥ−これは１７文字の最大長を有する「ストリング」タイプの、設定可能／読出可能な属性である。この属性は、それが表わす特定の共有ＮＩＣ（たとえばＮＩＣ５０）に、ＣＮＳ３４内に規定された所与の接続グループをマッピングするために用いられる。
２．ＡＤＡＰＴＥＲＴＹＰＥ−これは、ＡＤＡＰＴＥＲＮＡＭＥ属性が意味するアダプタのタイプを特定する設定可能／読出可能な属性である。この実施例では、ＡＤＡＰＴＥＲＴＹＰＥ属性はＶＬＡＮ（上述の同時係属中の出願に記載されているシミュレートされたＦＤＤＩネットワークを意味する）またはＦＡＳＴＥＴＨＥＲＮＥＴ（この実施例においてサポートされるＮＩＣのタイプを意味する）に設定され得る。
共有ＮＩＣでは、ルータ８０はＡシリーズサーバ１００のＮＴ  ＴＣＰＩＰ．ＳＹＳ５８およびＴＣＰ／ＩＰ  ＨＲＮＰ４４の両方に対して透過的である。ＮＴ  ＴＣＰ．ＳＹＳは、通常のようにＮＤＩＳインタフェースを介してＮＩＣドライバとインタフェースする場合と同様に、ルータ８０とインタフェースする。Ａシリーズサーバ１００のＴＣＰ／ＩＰ  ＨＲＮＰ４４もまた、通常のようにＬＡＮＳＧ７８を介してネットワークインタフェースする場合と同様に、ルータ８０とインタフェースする。ＮＴ  ＴＣＰＩＰ．ＳＹＳ５８もＡシリーズＴＣＰ／ＩＰ  ＨＲＮＰ４４も、それらが同じＮＩＣを共有していることを認識しない。さらにＮＩＣドライバ５４は、通常のようにＮＴ  ＴＣＰＩＰ．ＳＹＳなどのＮＤＩＳプロトコルドライバとインタフェースする場合と同様に、ルータ８０とインタフェースする。
図９Ａから図９Ｃは、その１つの実施例に従う、ルータ８０の内に向う経路制御機能をさらに詳細に説明し、この発明の方法の１つの実施例をさらに例示する。しかしながら、図９Ａから図９Ｃに示される実施例は、上述の「ループバック」経路をサポートしない。関数は擬似コードの形態で与えられている。
図９Ａを参照して、行２００において、ルータ８０はネットワークから受信したデータのフレームのＭＡＣヘッダの長さフィールドにより、フレームの長さが１５００バイト以下であるか否かを判断し、その場合にはフレームは８０２．３ＭＡＣヘッダと、８０２．２ＬＬＣヘッダと、８０２．１ａＳＮＡＰ（サブネットワークアタッチメントポイント）ヘッダとを含む８０２．３フレームであると推定される。この場合、行２０２において、ルータ８０はフレームのＬＬＣヘッダのＤＳＡＰフィールドから、フレームがＳＮＡＰフレームであるか否かを判断する。そうであれば、行２０４においてルータは、ＬＬＣヘッダの制御フィールドから、フレームが、番号の付けられていない情報（ＵＩ）タイプのフレーム（すなわち８０２．２ＬＬＣプロトコルでの「情報」（データ）フレームに使用されるフレームタイプ）でもあるかを判断する。フレームがＵＩフレームでない場合、ＵＮＫＮＯＷＮタイプのものであるとされ、ＵＮＫＮＯＷＮタイプを示すため行２０８においてtyp_of_frame_rcvd変数に対応の値がストアされる。行２０４においてフレームがＵＩフレームであると判断された場合、行２０６において、ルータ８０はさらにフレームがＩＰフレーム、ＡＲＰフレームまたはＵＮＫＮＯＷＮタイプであるか否かを判断し、type_of_frame_rcvd変数に、特定されたタイプをストアする。
行２０２において、フレームがＳＮＡＰフレームであると判断されない場合、行２１０においてルータ８０はＬＬＣヘッダのＤＳＡＰフィールドと、ＬＡＮＳＧ７８のlookup_source_addr()関数（これはステーションテーブルエントリのリモートアドレスとフレームのソースＭＡＣアドレスとの一致を探してＬＡＮＳＧステーションのリストを探索する）とから、フレームがＡシリーズサーバ１００のＢＮＡｖ２  ＨＲＮＰ４２に対するものであるか否かを判断する。そうであれば、行２１２において、フレームはtype_of_frame_rcvd変数に対応の値をストアすることなどによってその旨識別される。フレームがＢＮＡｖ２フレームであると識別されない場合、フレームには行２１４のうち１つにおいてＵＮＫＮＯＷＮのタイプが割当てられる。
ステップ２００において、入来するフレームの長さが１５００バイト未満でない場合、それはイーサネットフレームまたは大きなＢＮＡｖ２フレームのいずれかであると推定される。行２１６において、ルータ８０は、ＢＮＡｖ２フレームであるかを判断するためにフレームのＬＬＣヘッダのＤＳＡＰフィールドをチェックする。もしそうならば、行２１８において、ルータ８０はlookup_source_addr()関数を呼び出し、それをフレームのＭＡＣヘッダのsource_addrフィールドに送り、これは、その情報より、フレームがＡシリーズサーバ１００のＢＮＡｖ２  ＨＲＮＰ４２にアドレス指定されたか否かを判断する。もしそうならば、lookup_source_addr()関数はそのＢＮＡｖ２  ＨＲＮＰへの接続を表わすステーションへのポインタを戻す。その後、行２２０において、typ_of_frame_rcvd変数が「ＢＮＡ」にセットされる。しかしながら行２１８においてＢＮＡｖ２  ＨＲＮＰが特定されない場合、フレームには行２２２においてＵＮＫＮＯＷＮタイプが割当てられる。
行２１６においてフレームがＢＮＡｖ２フレームの特性を有さないと判断されれば、それはＩＰフレームまたはＡＲＰフレームのいずれかのはずである。行２２４においてルータ８０は、実際にこれらのフレームのタイプのうちいずれが受信されたかを、イーサネットＭＡＣヘッダのタイプフィールドより判断する。タイプを判断することができない場合、フレームは単にＵＮＫＮＯＷＮタイプであるとされる。
受信フレームのタイプが決定すると、フレームは適切なネットワークプロトコルプロバイダに経路制御される必要がある。ＩＰまたはＡＲＰフレームの場合、フレームのＩＰヘッダのdest_addrフィールドがまず検証されて、フレームがネットワーク（行２２６）のすべてのＩＰアドレスに「ブロードキャスト」されるか否かを判断する。そうであれば、ip_addr_owner変数がセットされて、Ａシリーズサーバ１００（たとえばＴＣＰ／ＩＰ  ＨＲＮＰ４４）のネットワークプロトコルプロバイダおよびＮＴサーバ１０２（たとえばＴＣＰＩＰ．ＳＹＳ５８）上のネットワークプロトコルプロバイダの両方がそのフレームを受信することを示す。フレームがブロードキャストフレームでない場合、それはまずネットワークプロトコルプロバイダ４４および５８（行２２８）のいずれにもアドレス指定されないものと推定される。行２３０において、ルータ８０はネットワークプロトコルプロバイダ４４および５８のうちいずれがフレームを受信するかを判断し、ip_addr_owner変数をこれに応じてセットする。行２３２においてフレームがip_addr_ownerの値に基づいて適切なネットワークプロトコルプロバイダに経路制御される。たとえば、フレームがＡシリーズサーバのＴＣＰ／ＩＰ  ＨＲＮＰ４４に経路制御される場合、ルータ８０はフレームをＬＡＮＳＧ７８モジュールに送り、これは相互接続の他の構成要素と組合せられて、物理的接続を介してＡシリーズサーバ１００にフレームを送り、さらにネットワークプロトコルプロバイダに送る。これに代えて、フレームがＮＴサーバ１０２のネットワークプロトコルプロバイダ（ＴＣＰＩＰ．ＳＹＳ５８）によって受信される場合には、ルータ８０はＮＤＩＳインタフェースに適切な呼び出しを行なうことにより、そのネットワークプロトコルプロバイダにフレームを送る。ip_addr_ownerが、いずれのネットワークプロトコルプロバイダのフレームの宛先でもないと判断すれば、ルータ８０はウィンドウズＮＴレジストリ（上述）のEnableIPRoutingInMCPおよびEnableIPRoutingエントリの値に基づいてフレームを経路制御する。
ＢＮＡｖ２フレームの場合（行２３４）、ルータ８０は、フレームを受信するＢＮＡｖ２  ＨＲＮＰへの接続を表わすステーションのポインタとともに、ＬＡＮＳＧモジュール７８にフレームを送る。ＵＮＫＮＯＷＮフレームタイプの場合（行２３６）、フレームは未知のフレームタイプを扱うためのＮＤＩＳインタフェースに送られる。
図１０Ａから図１０Ｄは、ルータ８０の経路制御機能の別の好ましい実施例と、この発明の方法の好ましい実施例とを示すフロー図を含む。この実施例において、「ループバック」という特徴がサポートされる。図１０Ａおよび図１０Ｂは、共有ＮＩＣ５０を介してネットワーク１５から１フレームのデータが受信される場合にルータ８０によって行なわれるステップを示す。図１０Ｃは、Ａシリーズサーバ１００のネットワークプロトコルプロバイダによって１フレームのデータが送信されて、共有のＮＩＣ５０を介してネットワーク１５に出力される際に、ルータ８０によって行なわれるステップを示す。図１０Ｄは、ＮＴサーバ１０２のネットワークプロトコルプロバイダによって１フレームのデータが送信されて共有ＮＩＧ５０を介してネットワーク１５に出力される際に行なわれるステップを示す。
図１０Ａおよび図１０Ｂを参照して、ステップ２４０においてＮＩＣ５０はネットワーク１５から入来フレームを受信する。ステップ２４２において、ＮＩＣドライバ５４はＮＤＩＳインタフェースを呼び出し、フレームが受信されたことを知らせる。ステップ２４４において、ＮＤＩＳは共有ＮＩＣ５０に「バインドされた」すべてのプロトコルドライバを呼び出す。この実施例では、ルータ８０のＪＴＤ構成要素１８２はこのようにバインドされたプロトコルドライバである。先に説明したとおり、ＪＴＤ構成要素１８２はＮＤＩＳには典型的なプロトコルドライバとして認識される。
ステップ２４６において、フレームはＬＡＮＳＧモジュール７８によって所有されるバッファ内に複製される。次にステップ２５２において、ルータ８０はフレームの宛先のＭＩＣアドレスをチェックして、それがブロードキャストアドレスと一致するか否かを判断する。もしそうならば、制御はステップ２５８に移行する（図１０Ｂ）。宛先のＭＡＣアドレスがブロードキャストアドレスでない場合（ステップ２５２）、ステップ２５４においてルータ８０は、宛先のＭＡＣアドレスがＮＩＣ５０のＭＡＣアドレスと一致するか否かを判断する。そうでなければ、ステップ２５５においてルータ８０は、宛先のＭＡＣアドレスがＮＩＣのマルチキャストアドレスリストにあるか否かをチェックする。そうでなければ、フレームはステップ２５６において破棄される。ＮＩＣのマルチキャストアドレスリストに宛先のＭＡＣアドレスがある場合、制御はステップ２５８に移行する（図１０Ｂ）。
ステップ２５４において宛先のＭＡＣアドレスがＮＩＣのＭＡＣアドレスと一致することがわかれば、制御はステップ２４８に移行し、ルータ８０（特定的には図８に示される実施例のＪＴＤ構成要素１８２）は、それがＡシリーズシステムのＢＮＡｖ２  ＨＲＮＰ４２へのものか否かをフレームから判断する。そうであればステップ２５０においてフレームは、ＨＩＦを介してそのＢＮＡｖ２  ＨＲＮＰにＬＡＮＳＧ７８によって送られる。フレームがＢＮＡｖ２  ＨＲＮＰ４２へのものではない場合、制御は図１０Ｂのステップ２５８に移行する。
次に図１０Ｂを参照して、ステップ２５８において、ルータ８０はフレームがＡＲＰフレームであるかを判断する。そうであれば、それはＡＲＰ要求またはＡＲＰ返答（それぞれステップ２６０および２６２で判断される）のいずれかであるとされる。フレームがＡＲＰ要求である場合、フレームの複製がステップ２６８においてＮＴサーバ１０２のＴＣＰＩＰ．ＳＹＳ５８に経路制御され、ステップ２７０においてフレーム自体がＨＩＦを介してＡシリーズシステムのＴＣＰ／ＩＰ  ＨＲＮＰ４４に経路制御される。ＡＲＤフレームがＡＲＰ返答である場合、ステップ２６４においてルータ８０は、ターゲットプロトコルアドレスがＡシリーズサーバ１０２のＴＣＰ／ＩＰ  ＨＲＮＰ４４のＩＰアドレスと一致するか否かを判断する。そうであれば、フレームはステップ２７０において、ＨＩＦを介してそのネットワークプロトコルプロバイダに経路制御される。そうでなければ、フレームはステップ２６６において、ＮＴサーバ１０２のＴＣＰＩＰ．ＳＹＳドライバ５８にＮＤＩＳを介して経路制御される。
フレームがＡＲＰフレームではなくＩＰフレームである場合（ステップ２７２）、ＩＰフレームの宛先のＩＰアドレスがブロードキャストアドレス（ステップ２７４）、ネットワークＩＰアドレス（ステップ２７６）またはクラスＤマルチキャストアドレス（ステップ２７８）のいずれであるかを判断するために、ステップ２７４から２７８が行なわれる。ＩＰフレームの宛先のＩＰアドレスがこれらのうちいずれかである場合、フレームの複製がＮＤＩＳを介してＮＴサーバ１０２のＴＣＰＩＰ．ＳＹＳドライバ５８に（ステップ２６８）、およびＨＩＦ（ステップ２７０）を介してＡシリーズサーバ１００のＴＣＰ／ＩＰ  ＨＲＮＰ４４に、経路制御される。ステップ２７２においてフレームがＩＰフレームではないと判断されれば、制御はステップ２６６に移行し、フレームはＮＴ  ＴＣＰＩＰ．ＳＹＳ５８にのみ経路制御される。
宛先のＩＰアドレスがステップ２７４から２７８においてチェックされたタイプのものでない場合、制御はステップ２８０に移行し、ルータ８０は宛先のＩＰアドレスがＡシリーズシステムのＴＣＰ／ＩＰ  ＨＲＮＰ４４のものと一致するか否かを判断する。そうであれば、ステップ２７０においてＨＩＦを介してそのネットワークプロトコルプロバイダにフレームが経路制御される。そうでない場合、ステップ２８２において、ルータ８０はウィンドウズＮＴレジストリのEnableIPRoutingInMCPエントリをチェックする。そのエントリが「Primary」にセットされる場合、フレームは、ステップ２７０において、ＨＩＦを介してＡシリーズシステムのＴＣＰ／ＩＰ  ＨＲＮＰ４４に経路制御される。エントリが「Disabled」にセットされている場合、フレームはステップ２６６において、ＮＤＩＳを介してＮＴサーバ１０２のＴＣＰＩＰ．ＳＹＳドライバに経路制御される。EnableIPRoutingInMCPエントリが「Secondary」にセットされている場合、制御はステップ２８４に移行し、ルータ８０はレジストリにおけるEnableIPRoutingエントリをチェックする。EnableIPRoutingエントリが「True」にセットされている場合、フレームはステップ２６６において、ＮＤＩＳを介してＮＴサーバ１０２のＴＣＰＩＰ．ＳＹＳドライバ５８に経路制御される。EnableIPRoutingエントリが「False」にセットされている場合、フレームはステップ２７０においてＨＩＦを介してＡシリーズサーバ１００のＴＣＰ／ＩＰ  ＨＲＮＰ４４に経路制御される。
図１０Ｃは、ＮＩＣ５０を介して出力されるべきフレームを含むデータのブロックが、Ａシリーズサーバ１００のネットワークプロトコルプロバイダ（たとえばＢＮＡｖ２  ＨＲＮＰまたはＴＣＰ／ＩＰ  ＨＲＮＰのいずれかである）からＨＩＦを介して送信されるときにルータ８０によって行なわれるステップを示す。ステップ２９０において、ネットワークプロトコルプロバイダからのデータのブロックがＨＩＦを介してＮＴサーバ１０２に受信される。ステップ２９２において、データのブロックがＬＡＮＳＧモジュール７８への待ち行列に入れられる。ステップ２９４に示されるように、ステップ２９６から３０８は受信ブロックの各フレームに対して適用される。
所与のフレームに対して、ステップ２９６において、ＬＡＮＳＧモジュール７８は、そのフレームがＢＮＡｖ２  ＨＲＮＰまたはＴＣＰ／ＩＰ  ＨＲＮＰからのものであるか否かを判断する。フレームがＢＮＡｖ２フレームである場合、ステップ２９８においてＬＡＮＳＧモジュール７８は、ＢＮＡｖ２プロトコルに従ってフレームの前にＢＮＡヘッダを付加し、リンクレベルヘッダを前に付加し、ＮＤＩＳにフレームを送りＮＩＣ５０を介して出力する（ステップ３０８）。
これに代えて、フレームがＴＣＰ／ＩＰ  ＨＲＮＰからのものである場合、ステップ２９９においてＬＡＮＳＧモジュール７８は、ＴＣＰ／ＩＰおよびリンクレベルヘッダをフレームの前に付加する。次にステップ３００においてルータ８０は、宛先のＭＡＣアドレスがブロードキャストアドレスであるか否かを判断する。そうであればステップ３０２において、ルータ８０は、あたかもフレームがＮＩＣ５０によって受信されたかのごとく、ＮＤＩＳを介してＮＴサーバ１０２のＴＣＰＩＰ．ＳＹＳドライバ５８にフレームの複製を経路制御する。次にステップ３０８において、共有ＮＩＣ５０を介してネットワーク１５にフレームがさらに経路制御される。
フレームの宛先のＭＡＣアドレスがブロードキャストアドレスでなくソースＭＡＣアドレスと一致する場合、ステップ３０６においてルータ８０は、あたかもフレームがＮＩＣ５０によって受信されたかのごとく、ＮＤＩＳを介してＮＴサーバ１０２のＴＣＰＩＰ．ＳＹＳドライバ５８にフレームを経路制御する。フレームの宛先のＭＡＣアドレスがブロードキャストアドレスまたはソースＭＡＣアドレスのいずれにも一致しない場合、フレームは単に、ステップ３０８において共有ＮＩＣ５０を介してネットワーク１５に経路制御される。以上の記述では、ステップ３０２および３０６がこの発明のルータ８０の「ループバック」能力を表わすことに留意されたい。
図１０Ｄは、フレームがＮＴサーバ１０２のネットワークプロトコルプロバイダ（たとえばＴＣＰＩＰ．ＳＹＳ５８）によって出力されるよう送信される場合に行なわれるステップを示す。外に向うフレームはステップ３２０において、呼び出しによってＮＤＩＳインタフェースに送られる。ステップ３２２においてＮＤＩＳはルータ８０（特定的には図８の実施例のＪＮＤ構成要素１８４）にフレームを送る。ステップ３２４においてＪＮＤ構成要素１８４は、ＪＴＤ構成要素１８２にフレームを送り、ＪＴＤ構成要素１８２はこの発明ではＬＡＮＳＧモジュール７８の一部分である。次にステップ３２６においてフレームは、ＬＡＮＳＧ７８によって与えられたバッファ内に複製される。
次にステップ３２７において、リンクレベルヘッダがフレームから除去される。ステップ３２８においてルータ８０は、ＨＩＦを介するＡシリーズサーバ１００のＴＣＰ／ＩＰ  ＨＲＮＰへの接続がオープンであるか否かを判断する。そうでなければ、ルータ８０（特定的にはＪＴＤ構成要素１８２）はステップ３３８においてＮＤＩＳを介してフレームをＮＩＣ５０に単に経路制御する。
ステップ３２８においてＡシリーズサーバ１００のＴＣＰ／ＩＰ  ＨＲＮＰへの接続が特定される場合、ステップ３３０においてルータ８０は、フレームの宛先のＭＡＣアドレスがブロードキャストアドレスと一致するか否かを判断する。そうであれば、ステップ３３２において、フレームの複製がＨＩＦを介して（あたかもＮＩＣ５０によって受信されたかのごとく）Ａシリーズサーバ１００のＴＣＰ／ＩＰ  ＨＲＮＰに経路制御され、ステップ３３８においてフレーム自体がＮＤＩＳを介してＮＩＣ５０に経路制御される。フレームの宛先のＭＡＣアドレスがブロードキャストアドレスと一致しない場合、ステップ３３８においてルータ８０は宛先ＭＡＣアドレスがソースＭＡＣアドレスと一致するか否かを判断する。そうであればステップ３３６においてフレームはＨＩＦを介してＡシリーズサーバ１００のＴＣＰ／ＩＰ  ＨＲＮＰに経路制御されるだけである。フレームの宛先のＭＡＣアドレスがブロードキャストアドレスにもソースＭＡＣアドレスにも一致しない場合、フレームはステップ３３８においてＮＤＩＳを介してＮＩＣ５０に経路制御されるだけである。ここでもまた、前掲の記述において、ステップ３３２および３３６がこの発明のルータ８０の「ループバック」能力を表わすことに注目されたい。
上述のとおり、この発明は、第１のコンピュータシステムで動作し、それに関連した第１のネットワークアドレスを有する第１のネットワークプロトコルプロバイダと、第２のコンピュータシステムで動作し、それに関連した第２のネットワークアドレスを有する第２のネットワークプロトコルプロバイダとが、第２のコンピュータシステムに取付けられた同じネットワークインタフェースカードによってネットワークを介してデータの送受信の両方を行なうことができるようにする、方法および装置に向けられる。その広い発明の概念から逸脱することなく上記の実施例には変更がなされ得ることを理解されたい。たとえば、この発明はＡシリーズサーバとＮＴサーバとを含むシステムの状況において説明されたが、この発明の方法および装置は、同じまたは異なったタイプの２つのコンピュータシステムに採用され得ることを理解されたい。また、最も好ましい実施例ではルータ８０はＪＴＤ構成要素とＪＮＤ構成要素とを含むものとして説明されたが、他の実施例では別の構成要素の組合せまたは単一の構成要素としてルータの機能を実現してもよい。さらに、この発明の相互接続は、開示した特定の実施例に限定されない。むしろ、「相互接続」という用語は、第１および第２のコンピュータシステムのＩ／Ｏサブシステム間でデータの転送を行なうための他の方法および装置も包含することが意図される。たとえば、他の実施例ではＱＳＰおよびＬＡＮＳＧ構成要素の機能は要求されないこともある。むしろ、相互接続デバイスドライバ（ＩＣＤ）とルータとの間にはより直接的なインタフェースが採用され得る。したがって、この発明は開示された特定の実施例に限定されない。
【図１】
0003694532.tif 000007
【図２】
0003694532.tif 000008
【図３】
0003694532.tif 000009
【図４】
0003694532.tif 000010
【図５】
0003694532.tif 000011
【図６Ａ】
0003694532.tif 000012
【図６Ｂ】
0003694532.tif 000013
【図６Ｃ】
0003694532.tif 000014
【図６Ｄ】
0003694532.tif 000015
【図６Ｅ】
0003694532.tif 000016
【図６Ｆ】
0003694532.tif 000017
【図７】
0003694532.tif 000018
【図８】
0003694532.tif 000019
【図９Ａ】
0003694532.tif 000020
【図９Ｂ】
0003694532.tif 000021
【図９Ｃ】
0003694532.tif 000022
【図１０Ａ】
0003694532.tif 000023
【図１０Ｂ】
0003694532.tif 000024
【図１０Ｃ】
0003694532.tif 000025
【図１０Ｄ】
0003694532.tif 000026