JP2011018343A - 遠隔管理システム - Google Patents

Abstract

【課題】第１のファイバ・チャネル・ポートに結合される第１のホスト・バス・アダプタと、第２のファイバ・チャネル・ポートに結合する第２のホスト・バス・アダプタに付随する遠隔管理者とを含む好適なシステムを提供する。
【解決手段】遠隔管理者は、第２のホスト・バス・アダプタによって第１のホスト・バス・アダプタへ、ファイバ・チャネルの共通トランスポート層を介して送られるべき命令を形成するように、動作可能である。本発明の一態様は、指定された場所におけるアドミニストレータが、ストレージ・エリア・ネットワーク（ＳＡＮ）の複数のサーバ、ＨＢＡ、ならびにポートを管理することができる遠隔管理システムに関する。遠隔管理システムには、遠隔管理者サーバにおけるＲＭＣソフトウェア、および各ターゲット・サーバにおけるＲＭＡソフトウェア、および／または管理すべきＨＢＡが含まれていても良い。
【選択図】図２Ａ

Description

背景
ストレージ・エリア・ネットワーク（ＳＡＮ）には、複数のサーバ、記憶デバイス、およびスイッチが含まれる場合がある。各サーバは、サーバをネットワークに結合するホスト・バス・アダプタ（「ＨＢＡ」または「アダプタ」とも呼ばれる）を有する場合がある。ＳＡＮの全体に渡ってインストールされたＨＢＡは、設定およびメンテナンス作業が必要となる場合がある。従来、これらの作業はＳＡＮの各ノード上で別個に行なわれている。

ＳＡＮが大型化して複雑になるにつれ、所定のＳＡＮ上のホスト・サーバおよびアダプタの数が増加して、それらの場所が物理的に多様化する場合がある。大型で複雑なＳＡＮは、高価であるとともにインストールおよび保守に時間がかかる可能性がある。ＳＡＮアドミニストレータの仕事である、複数サーバ、ＨＢＡ、ポート（ネットワークに対するデバイスのアクセス・ポイント）、スイッチ、および記憶アレイを管理することに対して、要求が厳しくなる場合がある。たとえばＳＡＮアドミニストレータは、ＨＢＡファームウェアを、ＨＢＡがインストールされる各ホスト・サーバにおいて、局所的に更新しなければならない。

概要
本発明の一態様は、指定された場所におけるアドミニストレータが、ストレージ・エリア・ネットワーク（ＳＡＮ）の複数のサーバ、ＨＢＡ（たとえば、ファイバ・チャネルおよび／またはｉＳＣＳＩ）、ならびにポートを管理することができる遠隔管理システムに関する。遠隔管理システムには、遠隔管理者サーバにおける遠隔管理クライアント（ＲＭＣ）ソフトウェア、および各ターゲット・サーバにおける遠隔管理エージェント（ＲＭＡ）ソフトウェア、および／または管理すべきＨＢＡが含まれていても良い。

遠隔管理システムは、遠隔で、ステータス情報を照会し、サーバ、ＨＢＡ、およびポートの活動をモニタし、問題を診断し、ならびにサーバ、ＨＢＡ、および、ＳＡＮのポートの構成、設定、オプション、およびパラメータを設定しても良い。

遠隔管理システムによって、多くの利点が得られる。遠隔管理システムによって、ＳＡＮアドミニストレータの仕事が非常に簡単になり得る。と言うのは、アドミニストレータは各ＨＢＡを、ＨＢＡがインストールされているホスト・サーバにおいて局所的に管理する必要がないからである。ＨＢＡ管理をある地点に集中させることによって、遠隔管理システムは、ＳＡＮおよびそのコンポーネントを所有および管理するコストを下げられ得るため、有利である。

遠隔管理システムは、新しいＨＢＡファームウェアをＳＡＮ内の何れかのＨＢＡに転送すること（「ファームウェア更新」とも呼ばれる）を始めても良い。遠隔管理システムは、ＨＢＡファームウェアの更新を、リアル・タイムで、およびＳＡＮ性能に影響を及ぼすことなく、行ない得る。

遠隔管理システムは、ドライバおよび／またはドライバ更新を、遠隔サーバに分配しても良い。

遠隔管理システムは、ＨＢＡと連絡してこれを制御することを、（ＳＡＮ上の）「帯域内」通信ネットワークを用いて、たとえばファイバ・チャネル共通トランスポート（ＦＣ−ＣＴ）パケットをファイバ・チャネル・ネットワークを介して用いて、またはインターネット・プロトコル（ＩＰ）パケットをｉＳＣＳＩネットワークを介して用いることによって、行なっても良い。

遠隔管理システムは、「帯域内」通信に加えてまたはその代わりに、「帯域外」通信を用いて、たとえばインターネット・プロトコル（ＩＰ）パケットをイーサネット（登録商標）を介して用いて、同じＳＡＮまたは別個のＳＡＮ上のＨＢＡと連絡してこれを制御しても良い。遠隔管理者とＨＢＡとの間の帯域外通信は、ＳＡＮ以外のネットワークを介しても良い。システムは、帯域外通信によって、複数のＳＡＮ上のＨＢＡを管理することができる。複数のＳＡＮは、互いと直接にネットワークされていなくても良い。

遠隔管理クライアントは、堅固で高レベルの遠隔管理アプリケーション・プログラム・インターフェース（ＲＭＡＰＩ）にアクセスするユーザ・インターフェース・アプリケーションを有していても良い。ＲＭＡＰＩを、互いに別個のソフトウェア・ベンダ（ＩＳＶ）に分配して、それら特有の管理アプリケーションおよびユーザ・インターフェースを開発しても良い。ＲＭＡＰＩによって、遠隔管理システムの特徴に対するＩＳＶアプリケーション・アクセスが得られる。

ＲＭＡＰＩは、複数のプラットフォームおよびオペレーティング・システム、たとえばウィンドウズ（登録商標）ＮＴ／２０００、ソラリス、ＡＩＸ、ＨＰ−ＵＸおよびリナックスにわたって、不変であっても良い。ＲＭＡＰＩは、ファイバ・チャネル・アダプタおよびｉＳＣＳＩアダプタの両方を同じＡＰＩを用いて管理できるように、完全に汎用であっても良い。

ＲＭＡＰＩは、ファイバ・チャネルＨＢＡ（ＦＣ−ＲＭＡＰＩ）用のライブラリおよびｉＳＣＳＩＨＢＡ（ＩＳＣＩ−ＲＭＡＰＩ）用のライブラリ内の機能にアクセスしても良い。ＦＣ−ＲＭＡＰＩライブラリは、ＦＣ共通トランスポート（ＣＴ）命令に対応するＦＣＲＭＡＰＩ（ＲＭ）命令を含んでいても良い。ＦＣ共通トランスポート（ＣＴ）命令は、入力出力制御（ＩＯＣＴＬ）機能によって、ファブリックを越えて送られても良い。

遠隔管理システムの他の利益が、ＳＡＮスイッチがインテリジェント・コンピュータへと発展し続ける限り、実現され得る。スイッチおよび他のファブリック・デバイスは、ＩＯＣＴＬインターフェースを介してドライバ・レベルの入力出力制御（ＩＯＣＴＬ）機能にアクセスして、ＨＢＡを遠隔に管理できても良い。たとえば、スイッチおよび他のファブリック・デバイスは、ＨＢＡファームウェア構成およびオプションを遠隔に変更しても良い。

遠隔管理システムは、拡張可能なマークアップ言語（ＸＭＬ）サポートを提供しても良い。

遠隔管理システムは、マイクロソフト管理コンソール（ＭＭＣ）スナップ・インの形態の管理ツールを提供しても良い。

遠隔管理システムの一実施形態は、どのサード・パーティ・ソフトウェア製品とも干渉せず、またどのオペレーティング・システムまたはアプリケーションに対してもわずかな変更も要求しない。帯域内遠隔管理は、ＳＡＮのすべてのハードウェア・デバイスに対して透明であっても良い。

アプリケーションの一態様は、ファイバ・チャネル・ネットワークを有するシステムに関する。システムには、ファイバ・チャネル・ネットワークの第１のポートに結合される第１のホスト・バス・アダプタと、ファイバ・チャネル・ネットワークの第２のポートに結合される第２のホスト・バス・アダプタに付随する遠隔管理者とが含まれる。遠隔管理者は、命令を、第２のホスト・バス・アダプタから第１のホスト・バス・アダプタへ、ファイバ・チャネル・ネットワークの共通トランスポート層を介して送るように動作可能である。

他の態様は、第１のコンピュータにおけるプログラム・インターフェース・モジュールに関する。プログラム・インターフェース・モジュールは、クライアント・ソフトウェア・アプリケーションが遠隔管理機能のライブラリにアクセスできるように、動作可能である。各遠隔管理機能は、ファイバ・チャネル共通トランスポート命令に付随する。各ファイバ・チャネル共通トランスポート命令は、第２のコンピュータのコンポーネントに、機能を実行するように命令するように構成されている。第２のコンピュータは、第１のコンピュータと、ファイバ・チャネル・ネットワークを介して連絡する。

他の態様は、インターネット・システム・インターフェース（ｉＳＣＳＩ）ネットワークを有するシステムに関する。システムには、ｉＳＣＳＩネットワークの第１のポートに結合される第１のホスト・バス・アダプタと、ｉＳＣＳＩネットワークの第２のポートに結合される第２のホスト・バス・アダプタに付随する遠隔管理者とが含まれる。遠隔管理者は、命令を、第２のホスト・バス・アダプタから第１のホスト・バス・アダプタへ、インターネット・プロトコル・パケットで、ｉＳＣＳＩネットワークを介して送るように動作可能である。

他の態様は、属性タイプのフィールド、属性長さのフィールド、および属性データのフィールドを含むデータ構造に関する。データ構造は、ストレージ・エリア・ネットワーク内のコンポーネントの属性を記述する。属性データ構造は、ファイバ・チャネル・ネットワークの第１のノードからから第２のノードへ、ファイバ・チャネル共通トランスポート層を介して送信されるように構成される。

他の態様は、第１のファイバ・チャネル・ポートから第２のファイバ・チャネル・ポートへ送られるように構成されるファイバ・チャネル共通トランスポート命令に関する。ファイバ・チャネル共通トランスポート命令は、第２のファイバ・チャネル・ポートと連絡するコンポーネントに、機能を実行するように指示を出す。

他の態様は、第１のファイバ・チャネル・ポートにおける第１のコンピュータから第２のファイバ・チャネル・ポートにおける第２のコンピュータへ送られるように構成される命令構造に関する。命令構造には、命令を送るべき場所を指定するオブジェクト・ポート・アドレス、命令を送るべきバックアップ・アドレスを指定するプロキシ・ポート・アドレス、ポインタ、および戻り値が含まれる。

他の態様は、ディスク・ベースのディレクトリを含むリポジトリに関する。リポジトリは、第１のコンピュータ・サーバからコンピュータ第２のサーバへ複数のファイバ・チャネル命令トランスポート・パケットを介して転送されるべきファイルを記憶するように、動作可能である。

他の態様は、第２のコンピュータにおけるディスク・ベースのディレクトリを含むリポジトリに関する。リポジトリは、第１のコンピュータから第２のコンピュータへ複数のファイバ・チャネル命令トランスポート・パケットを介して転送されるファイルを記憶する
ように、動作可能である。

他の態様は、サーバ上のホスト・バス・アダプタ・ドライバと連絡するように動作可能であるソフトウェア・モジュールに関する。ソフトウェア・モジュールには、ストレージ・エリア・ネットワークの遠隔ポートから命令を受信するように動作可能である複数の遠隔命令モジュールと、遠隔命令モジュールから受信する命令を複数のプロトコル管理者へディスパッチするように動作可能であるカーネルと、命令を実行するように動作可能である複数の管理サービス・モジュールと、が含まれる。

他の態様は、命令をファイバ・チャネル・ネットワーク内のデバイスへ送る方法に関する。方法には、ファイバ・チャネル・ネットワーク内の第１のデバイスにおいてユーザ命令を受信することと、ファイバ・チャネル共通トランスポート命令ライブラリにアクセスして、ユーザ命令に対応するファイバ・チャネル共通トランスポート命令を同定することと、ファイバ・チャネル共通トランスポート命令を共通トランスポート情報単位リクエスト内に封入することと、共通トランスポート情報単位リクエストを第２のデバイスへファイバ・チャネル・ネットワークを介して送ることと、が含まれる。

他の態様は、命令を、インターネット・インターフェース（ｉＳＣＳＩ）ネットワーク内のデバイスへ送る方法に関する。方法には、ｉＳＣＳＩネットワーク内の第１のデバイスにおいてユーザ命令を受信することと、ｉＳＣＳＩ命令ライブラリにアクセスして、ユーザ命令に対応するｉＳＣＳＩ命令を同定することと、ｉＳＣＳＩ命令を第２のデバイスにｉＳＣＳＩネットワークを介して送ることと、が含まれる。

他の態様は、ファームウェア・ファイルを遠隔ホスト・バス・アダプタに転送する方法に関する。方法には、ファームウェア・ファイルを局所的なリポジトリへインポートすることと、ファームウェア・ファイルが、ファームウェア・ファイルを受信するべき遠隔アダプタと適合することを確認することと、ファームウェア・ファイルを遠隔ホスト・アダプタへファイバ・チャネル共通トランスポート（ＦＣ−ＣＴ）層を介して送ることと、が含まれる。

１つまたは複数の実施形態の詳細を、添付の図面および以下の説明において述べる。他の特徴、オブジェクト、および利点は、説明および図面、ならびに請求項から明らかである。

種々の図面における同様の参照符号は、同様の要素を示す。
（項目１）
ファイバ・チャネル・ネットワークを有するシステムであって、
ファイバ・チャネル・ネットワークの第１のポートに結合される第１のホスト・バス・アダプタと、
ファイバ・チャネル・ネットワークの第２のポートに結合される第２のホスト・バス・アダプタに付随する遠隔管理者であって、命令を、第２のホスト・バス・アダプタから第１のホスト・バス・アダプタへ、ファイバ・チャネル・ネットワークの共通トランスポート層を介して送るように動作可能である遠隔管理者と、を含むシステム。
（項目２）
第１のホスト・バス・アダプタが、サーバ内にインストールされる項目１に記載のシステム。
（項目３）
サーバ内に組み込まれる第３のホスト・バス・アダプタをさらに含み、第３のホスト・アダプタは第３のファイバ・チャネル・ポートに結合され、命令は、第１のホスト・バス・アダプタに対するオブジェクト・ポート・アドレス、および第３のホスト・バス・アダ
プタに対するプロキシ・ポート・アドレスを指定する項目２に記載のシステム。
（項目４）
ファイバ・チャネル・ネットワークの第３のポートに結合される少なくとも１つの記憶デバイスをさらに含む項目１に記載のシステム。
（項目５）
少なくとも１つのネットワーク・スイッチをさらに含む項目１に記載のシステム。
（項目６）
第１のホスト・バス・アダプタが、第１のホスト・バス・アダプタがインストールされるサーバのオペレーティング・システムを伴うことなく、命令を実行するように動作可能である項目１に記載のシステム。
（項目７）
遠隔管理者が、命令を第２のホスト・バス・アダプタへ送るように動作可能であり、および第２のホスト・バス・アダプタが、命令に応答するように動作可能である項目１に記載のシステム。
（項目８）
命令が、第１のホスト・バス・アダプタによって戻されるデータが記憶されるべきメモリ・バッファのアドレスを指定する項目１に記載のシステム。
（項目９）
命令が、ファイバ・チャネル・ネットワークのポートに結合されるすべてのホスト・バス・アダプタの名前およびアドレスを発見する項目１に記載のシステム。
（項目１０）
命令が、第１のホスト・バス・アダプタからのホスト・バス・アダプタ属性をリクエストする項目１に記載のシステム。
（項目１１）
命令が、第１のホスト・バス・アダプタの属性を変更する項目１に記載のシステム。
（項目１２）
命令が、第１のポートからのポート属性をリクエストする項目１に記載のシステム。
（項目１３）
命令が、第１のポートのポート属性を変更する項目１に記載のシステム。
（項目１４）
命令が、第１のポートからのポート統計をリクエストする項目１に記載のシステム。
（項目１５）
命令が、第１のポートのポート統計をリセットする項目１に記載のシステム。
（項目１６）
命令が、第１のホスト・バス・アダプタに結合されるサーバからのサーバ属性をリクエストする項目１に記載のシステム。
（項目１７）
命令が、第１のホスト・バス・アダプタに結合されるサーバのサーバ属性を変更する項目１に記載のシステム。
（項目１８）
命令が、ファイルをリポジトリにコピーし、リポジトリは遠隔管理者によってアクセス可能である項目１に記載のシステム。
（項目１９）
命令が、第１のホスト・バス・アダプタへのファームウェア・ファイルのダウンロードが成功できたかどうかを確認する項目１に記載のシステム。
（項目２０）
命令が、遠隔管理者に付随する第１のリポジトリ内のファイルを、第１のホスト・バス・アダプタに付随する第２のリポジトリへ送る項目１に記載のシステム。
（項目２１）
ファイルにファームウェアが含まれる項目２０に記載のシステム。
（項目２２）
ファイルにドライバが含まれる項目２０に記載のシステム。
（項目２３）
命令が、第１のホスト・バス・アダプタに、第１のホスト・バス・アダプタに付随するリポジトリ内のファームウェアをダウンロードするように指示を出し、ファームウェアは遠隔管理者からロードされる項目１に記載のシステム。
（項目２４）
命令が、
ファームウェア・ファイルを第１のリポジトリへコピーすることであって、第１のリポジトリは遠隔管理者によってアクセス可能である、コピーすることと、
第１のホスト・バス・アダプタへのファームウェア・ファイルのダウンロードが成功できたかどうかを確かめることと、
遠隔管理者に付随する第１のリポジトリ内のファームウェア・ファイルを、第１のホスト・バス・アダプタに付随する第２のリポジトリへ送ることと、
第１のホスト・バス・アダプタに、第１のホスト・バス・アダプタに付随する第２のリポジトリ内のファームウェアをダウンロードするように指示を出すことと、を含む項目１に記載のシステム。
（項目２５）
命令が、第１のホスト・バス・アダプタの動作をリセットする項目１に記載のシステム。
（項目２６）
命令が、第１のホスト・バス・アダプタに付随するサーバ上のリポジトリ内の指定されたファイルの名前を変更する項目１に記載のシステム。
（項目２７）
命令が、第１のホスト・バス・アダプタに付随するサーバ上のリポジトリ内の指定されたファイルを削除する項目１に記載のシステム。
（項目２８）
命令が、第１のホスト・バス・アダプタに付随するリポジトリ内のファイル名のリストを取り出す項目１に記載のシステム。
（項目２９）
命令が、ファイバ・チャネル・プロトコル（ＦＣＰ）ターゲットと小さなコンピュータ・システム・インターフェース（ＳＣＳＩ）情報との間のマッピングを取り出す項目１に記載のシステム。
（項目３０）
命令が、第１のホスト・バス・アダプタに付随するドライバの属性を取り出す項目１に記載のシステム。
（項目３１）
命令が、第１のホスト・バス・アダプタに付随するドライバの属性を変更する項目１に記載のシステム。
（項目３２）
命令が、結合操作するために、第１のホスト・バス・アダプタに付随するすべてのノードの名前を取り出す項目１に記載のシステム。
（項目３３）
命令が、永続的な結合を加える項目１に記載のシステム。
（項目３４）
命令が、永続的な結合を削除する項目１に記載のシステム。
（項目３５）
コンピュータ上で実行可能なソフトウェア・モジュールであって、命令を第１のホスト・バス・アダプタから第２のホスト・バス・アダプタへ、ファイバ・チャネル・ネットワークの共通トランスポート層を介して送るためのソフトウェア・モジュール。
（項目３６）
クライアント・アプリケーション、アプリケーション・プログラミング・インターフェース、および命令機能のライブラリを含み、アプリケーション・プログラミング・インターフェースによって、クライアント・アプリケーションが、命令機能のライブラリにアクセスすることができる項目３５に記載のソフトウェア・モジュール。
（項目３７）
クライアント・アプリケーションに、ユーザがクライアント・アプリケーションを管理することができるように動作可能なグラフィカル・ユーザ・インターフェースが含まれる項目３６に記載のソフトウェア・モジュール。
（項目３８）
クライアント・アプリケーションがウェブ・ブラウザである項目３６に記載のソフトウェア・モジュール。
（項目３９）
クライアント・アプリケーションが、拡張可能マークアップ言語（ＸＭＬ）アプリケーションである項目３６に記載のソフトウェア・モジュール。
（項目４０）
クライアント・アプリケーションがジャバ・アプリケーションである項目３６に記載のソフトウェア・モジュール。
（項目４１）
デバイス・ドライバをさらに含む項目３６に記載のソフトウェア・モジュール。
（項目４２）
単純ネットワーク管理プロトコル（ＳＮＭＰ）アプリケーションをさらに含む項目３６に記載のソフトウェア・モジュール。
（項目４３）
マイクロソフト管理コンソールをさらに含む項目３６に記載のソフトウェア・モジュール。
（項目４４）
拡張可能マークアップ言語（ＸＭＬ）アプリケーションをさらに含む項目３６に記載のソフトウェア・モジュール。
（項目４５）
拡張可能マークアップ言語（ＸＭＬ）パーサ・モジュールをさらに含む項目３６に記載のソフトウェア・モジュール。
（項目４６）
拡張可能マークアップ言語（ＸＭＬ）ページ・サーバ・モジュールをさらに含む項目３６に記載のソフトウェア・モジュール。
（項目４７）
ジャバ・ネイティブ・インターフェースをさらに含む項目３６に記載のソフトウェア・モジュール。
（項目４８）
帯域外インターネット・プロトコル・イーサネット（登録商標）・インターフェースをさらに含む項目３６に記載のソフトウェア・モジュール。
（項目４９）
命令が、ポート属性をリクエストする項目３５に記載のソフトウェア・モジュール。
（項目５０）
命令が、ポート属性を変更する項目３５に記載のソフトウェア・モジュール。
（項目５１）
命令が、ポート統計をリクエストする項目３５に記載のソフトウェア・モジュール。
（項目５２）
命令が、ポート統計を変更する項目３５に記載のソフトウェア・モジュール。
（項目５３）
命令が、ホスト・バス・アダプタ属性をリクエストする項目３５に記載のソフトウェア・モジュール。
（項目５４）
命令が、ホスト・バス・アダプタ属性を変更する項目３５に記載のソフトウェア・モジュール。
（項目５５）
命令が、サーバ属性をリクエストする項目３５に記載のソフトウェア・モジュール。
（項目５６）
命令が、サーバ属性を変更する項目３５に記載のソフトウェア・モジュール。
（項目５７）
命令が、第２のホスト・バス・アダプタに、ファームウェア・ファイルをロードするように指示を出す項目３５に記載のソフトウェア・モジュール。
（項目５８）
命令が、永続的な結合を加える項目３５に記載のソフトウェア・モジュール。
（項目５９）
命令が、永続的な結合を削除する項目３５に記載のソフトウェア・モジュール。
（項目６０）
命令が、ホスト・バス・アダプタのアドレスを送る項目３５に記載のソフトウェア・モジュール。
（項目６１）
命令が、ホスト・バス・アダプタ上で診断テストを実行する項目３５に記載のソフトウェア・モジュール。
（項目６２）
第１のコンピュータにおけるプログラム・インターフェース・モジュールであって、クライアント・ソフトウェア・アプリケーションが遠隔管理機能のライブラリにアクセスできるように動作可能であり、各遠隔管理機能は、ファイバ・チャネル共通トランスポート命令に付随し、各ファイバ・チャネル共通トランスポート命令は、第２のコンピュータのコンポーネントに、機能を実行するように命令するように構成され、第２のコンピュータは、第１のコンピュータと、ファイバ・チャネル・ネットワークを介して連絡するプログラム・インターフェース・モジュール。
（項目６３）
プログラム・インターフェース・モジュールは、クライアント・ソフトウェア・アプリケーションが遠隔管理機能の第２のライブラリにアクセスできるように動作可能であり、第２のライブラリ内の各遠隔管理機能は、インターネット・システム・インターフェース（ｉＳＣＳＩ）命令に付随し、各ｉＳＣＳＩ命令は、第２のコンピュータのコンポーネントに、機能を実行するように命令するように構成されている項目６２に記載のプログラム・インターフェース・モジュール。
（項目６４）
ダイナミック・リンク・ライブラリを含む項目６２に記載のプログラム・インターフェース・モジュール。
（項目６５）
クライアント・ソフトウェア・アプリケーションが、単純ネットワーク管理プロトコル（ＳＮＭＰ）アプリケーションである項目６２に記載のプログラム・インターフェース・モジュール。
（項目６６）
クライアント・ソフトウェア・アプリケーションがネイティブ・アプリケーションである項目６２に記載のプログラム・インターフェース・モジュール。
（項目６７）
クライアント・ソフトウェア・アプリケーションがジャバ・アプリケーションである項目６２に記載のプログラム・インターフェース・モジュール。
（項目６８）
クライアント・ソフトウェア・アプリケーションがウェブ・ブラウザである項目６２に記載のプログラム・インターフェース・モジュール。
（項目６９）
クライアント・ソフトウェア・アプリケーションが、拡張可能マークアップ言語（ＸＭＬ）アプリケーションである項目６２に記載のプログラム・インターフェース・モジュール。
（項目７０）
クライアント・ソフトウェア・アプリケーションが、マイクロソフト管理コンソールである項目６２に記載のプログラム・インターフェース・モジュール。
（項目７１）
命令が、ファイバ・チャネル・ネットワークのポートに結合されるすべてのホスト・バス・アダプタの名前およびアドレスを発見する項目６２に記載のプログラム・インターフェース・モジュール。
（項目７２）
命令が、第２のコンピュータのホスト・バス・アダプタからのホスト・バス・アダプタ属性をリクエストする項目６２に記載のプログラム・インターフェース・モジュール。
（項目７３）
命令が、第２のコンピュータのホスト・バス・アダプタの属性を変更する項目６２に記載のプログラム・インターフェース・モジュール。
（項目７４）
命令が、第２のコンピュータのポートからのポート属性をリクエストする項目６２に記載のプログラム・インターフェース・モジュール。
（項目７５）
命令が、第２のコンピュータのポート属性ポートを変更する項目６２に記載のプログラム・インターフェース・モジュール。
（項目７６）
命令が、第２のコンピュータのポートからのポート統計をリクエストする項目６２に記載のプログラム・インターフェース・モジュール。
（項目７７）
命令が、第２のコンピュータのポートのポート統計をリセットする項目６２に記載のプログラム・インターフェース・モジュール。
（項目７８）
命令が、第２のコンピュータのサーバ属性をリクエストする項目６２に記載のプログラム・インターフェース・モジュール。
（項目７９）
命令が、第２のコンピュータのサーバ属性を変更する項目６２に記載のプログラム・インターフェース・モジュール。
（項目８０）
命令が、第１のコンピュータに付随する第１のリポジトリ内のファームウェア・ファイルを、第２のコンピュータに付随する第２のリポジトリに送る項目６２に記載のプログラム・インターフェース・モジュール。
（項目８１）
命令が、第２のコンピュータのホスト・バス・アダプタに、第１のホスト・バス・アダプタに付随するリポジトリ内のファームウェアをダウンロードするように指示を出し、ファームウェアは、第１のコンピュータからロードされる項目６２に記載のプログラム・インターフェース・モジュール。
（項目８２）
命令が、
ファームウェア・ファイルを第１のリポジトリへコピーすることであって、第１のリポ
ジトリは、第１のコンピュータによってアクセス可能である、コピーすることと、
第２のコンピュータのホスト・バス・アダプタへのファームウェア・ファイルのダウンロードが成功できたかどうかを確かめることと、
第１のコンピュータに付随する第１のリポジトリ内のファームウェア・ファイルを、第２のコンピュータに付随する第２のリポジトリへ送ることと、
ホスト・バス・アダプタに、ホスト・バス・アダプタに付随する第２のリポジトリ内のファームウェアをダウンロードするように指示を出すことと、を含む項目６２に記載のプログラム・インターフェース・モジュール。
（項目８３）
命令が、第２のコンピュータのホスト・バス・アダプタの動作をリセットする項目６２に記載のプログラム・インターフェース・モジュール。
（項目８４）
命令が、第２のコンピュータ内のリポジトリ内の指定されたファイルの名前を変更する項目６２に記載のプログラム・インターフェース・モジュール。
（項目８５）
命令が、第２のコンピュータ内のリポジトリ内の指定されたファイルを削除する項目６２に記載のプログラム・インターフェース・モジュール。
（項目８６）
命令が、第２のコンピュータ内のリポジトリ内のファイル名のリストを取り出す項目６２に記載のプログラム・インターフェース・モジュール。
（項目８７）
命令が、ファイバ・チャネル・プロトコル（ＦＣＰ）ターゲットとシステム・インターフェース（ＳＣＳＩ）情報との間のマッピングを取り出す項目６２に記載のプログラム・インターフェース・モジュール。
（項目８８）
命令が、第２のコンピュータのホスト・バス・アダプタに付随するドライバの属性を取り出す項目６２に記載のプログラム・インターフェース・モジュール。
（項目８９）
命令が、第２のコンピュータのホスト・バス・アダプタに付随するドライバの属性を変更する項目６２に記載のプログラム・インターフェース・モジュール。
（項目９０）
命令が、結合操作するために、第２のコンピュータのホスト・バス・アダプタに付随するすべてのノードの名前を取り出す項目６２に記載のプログラム・インターフェース・モジュール。
（項目９１）
命令が、永続的な結合を加える項目６２に記載のプログラム・インターフェース・モジュール。
（項目９２）
命令が、永続的な結合を削除する項目６２に記載のプログラム・インターフェース・モジュール。
（項目９３）
インターネット・システム・インターフェース（ｉＳＣＳＩ）ネットワークを有するシステムであって、
ｉＳＣＳＩネットワークの第１のポートに結合される第１のホスト・バス・アダプタと、
ｉＳＣＳＩネットワークの第２のポートに結合される第２のホスト・バス・アダプタに付随する遠隔管理者であって、命令を、第２のホスト・バス・アダプタから第１のホスト・バス・アダプタへ、インターネット・プロトコル・パケットで、ｉＳＣＳＩネットワークを介して送るように動作可能である遠隔管理者と、を含むシステム。
（項目９４）
属性タイプのフィールド、属性長さのフィールド、および属性データのフィールドを含むデータ構造であって、ストレージ・エリア・ネットワーク内のコンポーネントの属性を記述し、属性データ構造は、ファイバ・チャネル・ネットワークの第１のノードから第２のノードへファイバ・チャネル共通トランスポート層を介して送信されるように構成される属性データ構造。
（項目９５）
コンポーネントがホスト・バス・アダプタである項目９４に記載の属性データ構造。
（項目９６）
コンポーネントがホスト・バス・アダプタ・ドライバである項目９４に記載の属性データ構造。
（項目９７）
コンポーネントがサーバである項目９４に記載の属性データ構造。
（項目９８）
コンポーネントがポートである項目９４に記載の属性データ構造。
（項目９９）
コンポーネントが記憶デバイスである項目９４に記載の属性データ構造。
（項目１００）
第１のファイバ・チャネル・ポートから第２のファイバ・チャネル・ポートへ送られるように構成されるファイバ・チャネル共通トランスポート命令であって、第２のファイバ・チャネル・ポートと連絡するコンポーネントに、機能を実行するように命令するファイバ・チャネル共通トランスポート。
（項目１０１）
第２のファイバ・チャネル・ポートと連絡するコンポーネントが、ホスト・バス・アダプタである項目１００に記載のファイバ・チャネル共通トランスポート命令。
（項目１０２）
第２のファイバ・チャネル・ポートと連絡するコンポーネントが、サーバである項目１００に記載のファイバ・チャネル共通トランスポート命令。
（項目１０３）
第２のファイバ・チャネル・ポートと連絡するコンポーネントが、記憶デバイスである項目１００に記載のファイバ・チャネル共通トランスポート命令。
（項目１０４）
機能には、ホスト・バス・アダプタ・パラメータを、第２のファイバ・チャネル・ポートから第１のファイバ・チャネル・ポートへ送ることが含まれる項目１００に記載のファイバ・チャネル共通トランスポート命令。
（項目１０５）
第１のファイバ・チャネル・ポートにおける第１のコンピュータから第２のファイバ・チャネル・ポートにおける第２のコンピュータへ送られるように構成される命令構造であって、
命令を送るべき場所を指定するオブジェクト・ポート・アドレスと、
バックアップ・アドレス命令を送るべき場所を指定するプロキシ・ポート・アドレスと、
ポインタと、
戻り値と、を含む命令構造。
（項目１０６）
第１のホスト・バス・アダプタに、ファームウェアを、ファイバ・チャネル・ストレージ・エリア・ネットワーク内の第２のホスト・バス・アダプタへ送るように指示を出すように構成される命令構造。
（項目１０７）
第１のホスト・バス・アダプタに、ファームウェアを、インターネット・システム・インターフェース（ｉＳＣＳＩ）ストレージ・エリア・ネットワーク内の第２のホスト・バ
ス・アダプタへ送るように指示を出すように構成される命令構造。
（項目１０８）
ファイバ・チャネル・ポートに結合されるストレージ・エリア・ネットワーク内のすべてのホスト・バス・アダプタを発見するように構成される命令構造。
（項目１０９）
ディスク・ベースのディレクトリを含むリポジトリであって、第１のコンピュータ・サーバからコンピュータ第２のサーバへ複数のファイバ・チャネル命令トランスポート・パケットを介して転送すべきファイルを記憶するように動作可能であるリポジトリ。
（項目１１０）
ファイルが、ホスト・バス・アダプタ・ファームウェアを含む項目１０９に記載のリポジトリ。
（項目１１１）
ファイルが、デバイス・ドライバを含む項目１０９に記載のリポジトリ。
（項目１１２）
第１のコンピュータ・サーバの記憶デバイスに記憶される項目１０９に記載のリポジトリ。
（項目１１３）
第２のコンピュータにおけるディスク・ベースのディレクトリを含むリポジトリであって、第１のコンピュータから第２のコンピュータへ複数のファイバ・チャネル命令トランスポート・パケットを介して転送されるファイルを記憶するように動作可能であるリポジトリ。
（項目１１４）
サーバ上のホスト・バス・アダプタ・ドライバと連絡するように動作可能であるソフトウェア・モジュールであって、
ストレージ・エリア・ネットワークの遠隔ポートから命令を受信するように動作可能である複数の遠隔命令モジュールと、
遠隔命令モジュールから受信する命令を複数のプロトコル管理者にディスパッチするように動作可能であるカーネルと、
命令を実行するように動作可能である複数の管理サービス・モジュールと、を含む、ソフトウェア・モジュール。
（項目１１５）
遠隔命令モジュールの１つが、ファイバ・チャネル共通トランスポート（ＦＣ−ＣＴ）命令を受信するように動作可能である項目１１４に記載のソフトウェア・モジュール。
（項目１１６）
遠隔命令モジュールの１つが、インターネット・プロトコル・ベースのファイバ・チャネル共通トランスポート（ＦＣ−ＣＴ）命令を受信するように動作可能である項目１１４に記載のソフトウェア・モジュール。
（項目１１７）
遠隔命令モジュールの１つが、インターネット・プロトコル・ベースの単純ネットワーク管理プロトコル（ＳＮＭＰ）命令を受信するように動作可能である項目１１４に記載のソフトウェア・モジュール。
（項目１１８）
管理サービス・モジュールの１つが、ディレクトリ・サーバを含む項目１１４に記載のソフトウェア・モジュール。
（項目１１９）
管理サービス・モジュールの１つが、キー・サーバを含む項目１１４に記載のソフトウェア・モジュール。
（項目１２０）
管理サービス・モジュールの１つが、命令ソースを認証するように動作可能であるモジュールを含む項目１１４に記載のソフトウェア・モジュール。
（項目１２１）
命令を、ファイバ・チャネル・ネットワーク内のデバイスへ送る方法であって、
ファイバ・チャネル・ネットワーク内の第１のデバイスにおいてユーザ命令を受信することと、
ファイバ・チャネル共通トランスポート命令ライブラリにアクセスして、ユーザ命令に対応するファイバ・チャネル共通トランスポート命令を同定することと、
ファイバ・チャネル共通トランスポート命令を共通トランスポート情報単位リクエスト内に封入することと、
共通トランスポート情報単位リクエストを第２のデバイスへ、ファイバ・チャネル・ネットワークを介して送ることと、を含む方法。
（項目１２２）
第２のデバイスがサーバである項目１２１に記載の方法。
（項目１２３）
第２のデバイスがホスト・バス・アダプタである項目１２１に記載の方法。
（項目１２４）
共通トランスポート情報単位リクエストの認証コードをチェックすることをさらに含む項目１２１に記載の方法。
（項目１２５）
命令が、ファイバ・チャネル・ネットワークのポートに結合されるすべてのホスト・バス・アダプタの名前およびアドレスを発見する項目１２１に記載の方法。
（項目１２６）
命令が、第２のデバイスからのホスト・バス・アダプタ属性をリクエストする項目１２１に記載の方法。
（項目１２７）
命令が、第２のデバイスのホスト・バス・アダプタ属性を変更する項目１２１に記載の方法。
（項目１２８）
命令が、第２のデバイスからのポート属性をリクエストする項目１２１に記載の方法。（項目１２９）
命令が、第２のデバイスのポート属性を変更する項目１２１に記載の方法。
（項目１３０）
命令が、第２のデバイスからのポート統計をリクエストする項目１２１に記載の方法。（項目１３１）
命令が、第２のデバイスのポート統計をリセットする項目１２１に記載の方法。
（項目１３２）
命令が、第２のデバイスからのサーバ属性をリクエストする項目１２１に記載の方法。（項目１３３）
命令が、第２のデバイスのサーバ属性を変更する項目１２１に記載の方法。
（項目１３４）
命令がファイルをリポジトリにコピーし、リポジトリは第２のデバイスによってアクセス可能である項目１２１に記載の方法。
（項目１３５）
命令が、第１のデバイスに付随する第１のリポジトリ内のファームウェアを、第２のデバイスに付随する第２のリポジトリに送る項目１２１に記載の方法。
（項目１３６）
命令が、第２のデバイスに、第２のデバイスに付随するリポジトリ内のファームウェアをダウンロードするように指示を出し、ファームウェアは第１のデバイスからロードされる項目１２１に記載の方法。
（項目１３７）
命令が、
ファームウェア・ファイルを第１のリポジトリへコピーすることであって、第１のリポジトリは第１のデバイスによってアクセス可能である、コピーすることと、
第１のデバイスに付随する第１のリポジトリ内のファームウェア・ファイルを、第２のデバイスに付随する第２のリポジトリへ送ることと、
第２のデバイスに、第２のデバイスに付随する第２のリポジトリ内のファームウェアをダウンロードするように指示を出すことと、を含む項目１２１に記載の方法。
（項目１３８）
命令が、第２のデバイスのホスト・バス・アダプタの動作をリセットする項目１２１に記載の方法。
（項目１３９）
命令が、第２のデバイスに付随するサーバ上のリポジトリ内の指定されたファイルの名前を変更する項目１２１に記載の方法。
（項目１４０）
命令が、第２のデバイスに付随するサーバ上のリポジトリ内の指定されたファイルを削除する項目１２１に記載の方法。
（項目１４１）
命令が、第２のデバイスに付随するリポジトリ内のファイル名のリストを取り出す項目１２１に記載の方法。
（項目１４２）
命令が、ファイバ・チャネル・プロトコル（ＦＣＰ）ターゲットとシステム・インターフェース（ＳＣＳＩ）情報との間のマッピングを取り出す項目１２１に記載の方法。
（項目１４３）
命令が、第２のデバイスに付随するドライバの属性を取り出す項目１２１に記載の方法。
（項目１４４）
命令が、第２のデバイスに付随するドライバの属性を変更する項目１２１に記載の方法。
（項目１４５）
命令が、結合操作するために、第２のデバイスに付随するすべてのノードの名前を取り出す項目１２１に記載の方法。
（項目１４６）
命令が、永続的な結合を加える項目１２１に記載の方法。
（項目１４７）
命令が、永続的な結合を削除する項目１２１に記載の方法。
（項目１４８）
命令をインターネット・インターフェース（ｉＳＣＳＩ）ネットワーク内のデバイスに送る方法であって、
ｉＳＣＳＩネットワーク内の第１のデバイスにおいてユーザ命令を受信することと、
ｉＳＣＳＩ命令ライブラリにアクセスして、ユーザ命令に対応するｉＳＣＳＩ命令を同定することと、
ｉＳＣＳＩ命令を第２のデバイスへｉＳＣＳＩネットワークを介して送ることと、を含む方法。
（項目１４９）
ファームウェア・ファイルを遠隔ホスト・バス・アダプタへ転送する方法であって、
ファームウェア・ファイルを局所的なリポジトリへインポートすることと、
ファームウェア・ファイルが、ファームウェア・ファイルを受信するべき遠隔アダプタと適合することを確認することと、
ファームウェア・ファイルを遠隔ホスト・アダプタへファイバ・チャネル共通トランスポート（ＦＣ−ＣＴ）層を介して送ることと、を含む方法。
（項目１５０）
遠隔ホスト・アダプタにおいてファームウェア・ファイルを受信することと、
ファームウェア・ファイルを、遠隔ホスト・バス・アダプタに付随するリポジトリにコピーすることと、をさらに含む項目１４９に記載の方法。
（項目１５１）
ファイル・ダウンロード命令を受信することと、
ファームウェア・ファイルを遠隔ホスト・バス・アダプタ上にインストールすることと、をさらに含む項目１４９に記載の方法。
（項目１５２）
ファームウェア・ファイルが、ファイルを受信するべき遠隔アダプタと適合することを確認することが、ファイルのチェックサムをチェックすることを含む項目１４９に記載の方法。
（項目１５３）
ファームウェア・ファイルが、ファイルを受信するべき遠隔アダプタと適合することを確認することが、ファイルのタイプがホスト・バス・アダプタのタイプとマッチングするかどうかを判定することを含む項目１４９に記載の方法。

図１は、ストレージ・エリア・ネットワーク（ＳＡＮ）の一実施形態を示す。 図２Ａ〜２Ｂは、図１のＳＡＮにおける遠隔管理クライアント（ＲＭＣ）および１つまたは複数の遠隔管理エージェント（ＲＭＡ）の一実施形態を示す。 図２Ａ〜２Ｂは、図１のＳＡＮにおける遠隔管理クライアント（ＲＭＣ）および１つまたは複数の遠隔管理エージェント（ＲＭＡ）の一実施形態を示す。 図３は、図１および２におけるＲＭＣの一実施形態のブロック・ダイアグラムを示す。 図３は、図１および２におけるＲＭＣの一実施形態のブロック・ダイアグラムを示す。 図４は、ファイバ・チャネル、ホスト・バス・アダプタ（ＨＢＡ）、遠隔管理エージェント（ＲＭＡ）、およびイーサネット（登録商標）の一実施形態を示す。 図４は、ファイバ・チャネル、ホスト・バス・アダプタ（ＨＢＡ）、遠隔管理エージェント（ＲＭＡ）、およびイーサネット（登録商標）の一実施形態を示す。 図５は、図４のＲＭＡの使用方法を示す。 図６は、遠隔管理者におけるクライアントによって与えられ得るアプリケーション・ウィンドウの一実施形態のスクリーン場面である。 図７は、遠隔管理者におけるクライアントによって与えられ得る他のアプリケーション・ウィンドウの一実施形態のスクリーン場面である。 図８は、遠隔管理者におけるクライアントによって与えられ得る他のアプリケーション・ウィンドウの一実施形態のスクリーン場面である。 図９は、遠隔管理者におけるクライアントによって与えられ得る他のアプリケーション・ウィンドウの一実施形態のスクリーン場面である。 図１０は、遠隔管理者におけるクライアントによって与えられ得る他のアプリケーション・ウィンドウの一実施形態のスクリーン場面である。 図１１は、遠隔管理者におけるクライアントによって与えられ得る他のアプリケーション・ウィンドウの一実施形態のスクリーン場面である。 図１２は、遠隔管理者におけるクライアントによって与えられ得る他のアプリケーション・ウィンドウの一実施形態のスクリーン場面である。 図１３は、遠隔管理者におけるクライアントによって与えられ得る他のアプリケーション・ウィンドウの一実施形態のスクリーン場面である。 図１４は、遠隔管理者におけるクライアントによって与えられ得る他のアプリケーション・ウィンドウの一実施形態のスクリーン場面である。 図１５Ａは、主要なＲＭＡＰＩ機能カテゴリ、個々のＲＭＡＰＩ機能、およびそれらの関連するＦＣ−ＣＴ命令の一実施形態を示す。 図１５Ａは、主要なＲＭＡＰＩ機能カテゴリ、個々のＲＭＡＰＩ機能、およびそれらの関連するＦＣ−ＣＴ命令の一実施形態を示す。 図１５Ｂは、ＨＢＡＡＰＩ機能およびＲＭＡＰＩ機能の例を示す。 図１５Ｂは、ＨＢＡＡＰＩ機能およびＲＭＡＰＩ機能の例を示す。 図１６Ａ〜１６Ｂは、サーバ属性およびそれらのフォーマットの例を示す。 図１６Ａ〜１６Ｂは、サーバ属性およびそれらのフォーマットの例を示す。 図１７Ａおよび１７Ｂは、ＨＢＡ属性およびそれらのフォーマットの例を示す。 図１７Ａおよび１７Ｂは、ＨＢＡ属性およびそれらのフォーマットの例を示す。 図１７Ａおよび１７Ｂは、ＨＢＡ属性およびそれらのフォーマットの例を示す。 図１７Ａおよび１７Ｂは、ＨＢＡ属性およびそれらのフォーマットの例を示す。 図１８は、ポート属性およびそれらのフォーマットの例を示す。 図１９は、ポート統計およびそれらのフォーマットの例を示す。 図１９は、ポート統計およびそれらのフォーマットの例を示す。 図２０Ａは、ポートＦＣＰ属性の例を示す。 図２０Ｂは、ポートＦＣＰ属性の例を示す。 図２１は、ＦＣ−３管理属性の例を示す。 図２２は、ファームウェアを遠隔サーバへダウンロードする方法を示す。 図２３Ａ〜２３Ｅは、ソフトウェア・リソース属性およびそのフィールドの一実施形態を示す。 図２３Ａ〜２３Ｅは、ソフトウェア・リソース属性およびそのフィールドの一実施形態を示す。 図２３Ａ〜２３Ｅは、ソフトウェア・リソース属性およびそのフィールドの一実施形態を示す。 図２３Ａ〜２３Ｅは、ソフトウェア・リソース属性およびそのフィールドの一実施形態を示す。 図２３Ａ〜２３Ｅは、ソフトウェア・リソース属性およびそのフィールドの一実施形態を示す。 図２４は、ベンダ・ユニークなＦＣ−ＣＴ命令コードの例を示す。 図２４は、ベンダ・ユニークなＦＣ−ＣＴ命令コードの例を示す。 図２５〜２７は、共通トランスポート（ＣＴ）命令ブロック・フォーマットの例を示す。 図２５〜２７は、共通トランスポート（ＣＴ）命令ブロック・フォーマットの例を示す。 図２５〜２７は、共通トランスポート（ＣＴ）命令ブロック・フォーマットの例を示す。 図２８は、ＣＴベンダ・ユニークな拒絶理由コードの例のリストである。 図２８は、ＣＴベンダ・ユニークな拒絶理由コードの例のリストである。 図２９Ａ〜２９Ｂは、命令特有のエラーに対するＣＴベンダ・ユニークな理由コードの例のリストである。 図２９Ａ〜２９Ｂは、命令特有のエラーに対するＣＴベンダ・ユニークな理由コードの例のリストである。 図２９Ａ〜２９Ｂは、命令特有のエラーに対するＣＴベンダ・ユニークな理由コードの例のリストである。 図３０は、ＣＴ拒絶追加情報フィールドの一実施形態を示す。 図３１は、拒絶ＣＴ_ＩＵ追加情報フィールドの一実施形態を示す。 図３２は、すべてのポート統計に対して用いられ得る一般的なフォーマットの一実施形態を示す。 図３３は、ポート統計ブロック・エントリの一実施形態を示す。 図３４は、ソフトウェア・リソース記述子（ＳＲＤ）の一実施形態を示す。 図３５は、ソフトウェア・リソース・ブロック（ＳＲＢ）の一実施形態を示す。 図３６Ａ〜３６Ｂは、サーバ属性取得命令およびサーバ属性取得応答の例を示す。 図３６Ａ〜３６Ｂは、サーバ属性取得命令およびサーバ属性取得応答の例を示す。 図３７Ａ〜３７Ｂは、ＨＢＡ取得属性命令およびＨＢＡ属性取得応答の例を示す。 図３７Ａ〜３７Ｂは、ＨＢＡ取得属性命令およびＨＢＡ属性取得応答の例を示す。 図３８Ａ〜３８Ｂは、ポート属性取得命令およびポート属性取得応答の例を示す。 図３８Ａ〜３８Ｂは、ポート属性取得命令およびポート属性取得応答の例を示す。 図３９Ａ〜３９Ｂは、ドライバ属性取得命令およびドライバ属性取得応答の例を示す。 図３９Ａ〜３９Ｂは、ドライバ属性取得命令およびドライバ属性取得応答の例を示す。 図４０Ａ〜４０Ｂは、ポート統計取得命令およびポート統計取得応答の例を示す。 図４０Ａ〜４０Ｂは、ポート統計取得命令およびポート統計取得応答の例を示す。 図４１Ａ〜４１Ｂは、サーバ属性設定命令およびサーバ属性設定応答の例を示す。 図４１Ａ〜４１Ｂは、サーバ属性設定命令およびサーバ属性設定応答の例を示す。 図４２Ａ〜４２Ｂは、ＨＢＡ属性設定命令およびＨＢＡ属性設定応答の例を示す。 図４２Ａ〜４２Ｂは、ＨＢＡ属性設定命令およびＨＢＡ属性設定応答の例を示す。 図４３Ａ〜４３Ｂは、ポート属性設定命令およびポート属性設定応答の例を示す。 図４３Ａ〜４３Ｂは、ポート属性設定命令およびポート属性設定応答の例を示す。 図４４Ａ〜４４Ｂは、ドライバ属性設定命令およびドライバ属性設定応答の例を示す。 図４４Ａ〜４４Ｂは、ドライバ属性設定命令およびドライバ属性設定応答の例を示す。 図４５Ａ〜４５Ｂは、ポート統計リセット命令およびポート統計リセット応答の例を示す。 図４５Ａ〜４５Ｂは、ポート統計リセット命令およびポート統計リセット応答の例を示す。 図４６Ａ〜４６Ｂは、ファームウェア確認命令およびファームウェア確認応答の例を示す。 図４６Ａ〜４６Ｂは、ファームウェア確認命令およびファームウェア確認応答の例を示す。 図４７Ａ〜４７Ｂは、ファームウェア・ダウンロード命令およびファームウェア・ダウンロード応答の例を示す。 図４７Ａ〜４７Ｂは、ファームウェア・ダウンロード命令およびファームウェア・ダウンロード応答の例を示す。 図４８Ａ〜４８Ｂは、ファームウェア・アップグレード命令およびファームウェア・アップグレード応答の例を示す。 図４８Ａ〜４８Ｂは、ファームウェア・アップグレード命令およびファームウェア・アップグレード応答の例を示す。 図４９Ａ〜４９Ｃは、ＨＢＡリセット命令、ＨＢＡリセット応答およびＨＢＡリセット命令詳細の例を示す。 図４９Ａ〜４９Ｃは、ＨＢＡリセット命令、ＨＢＡリセット応答およびＨＢＡリセット命令詳細の例を示す。 図４９Ａ〜４９Ｃは、ＨＢＡリセット命令、ＨＢＡリセット応答およびＨＢＡリセット命令詳細の例を示す。 図４９Ａ〜４９Ｃは、ＨＢＡリセット命令、ＨＢＡリセット応答およびＨＢＡリセット命令詳細の例を示す。 図５０Ａ〜５０Ｃは、ＨＢＡ診断実行命令、ＨＢＡ診断実行応答、およびＨＢＡ診断実行命令詳細の例を示す。 図５０Ａ〜５０Ｃは、ＨＢＡ診断実行命令、ＨＢＡ診断実行応答、およびＨＢＡ診断実行命令詳細の例を示す。 図５０Ａ〜５０Ｃは、ＨＢＡ診断実行命令、ＨＢＡ診断実行応答、およびＨＢＡ診断実行命令詳細の例を示す。 図５１Ａ〜５１Ｃは、遠隔リソース・リスト取得命令、遠隔リソース・リスト取得応答、および遠隔リソース・リスト取得命令詳細の例を示す。 図５１Ａ〜５１Ｃは、遠隔リソース・リスト取得命令、遠隔リソース・リスト取得応答、および遠隔リソース・リスト取得命令詳細の例を示す。 図５１Ａ〜５１Ｃは、遠隔リソース・リスト取得命令、遠隔リソース・リスト取得応答、および遠隔リソース・リスト取得命令詳細の例を示す。 図５１Ａ〜５１Ｃは、遠隔リソース・リスト取得命令、遠隔リソース・リスト取得応答、および遠隔リソース・リスト取得命令詳細の例を示す。 図５１Ａ〜５１Ｃは、遠隔リソース・リスト取得命令、遠隔リソース・リスト取得応答、および遠隔リソース・リスト取得命令詳細の例を示す。 図５２Ａ〜５２Ｂは、遠隔リソース情報取得命令および遠隔リソース情報取得応答の例を示す。 図５２Ａ〜５２Ｂは、遠隔リソース情報取得命令および遠隔リソース情報取得応答の例を示す。 図５３Ａ〜５３Ｃは、ソフトウェア・リソース送信命令、ソフトウェア・リソース送信応答、およびソフトウェア・リソース送信命令詳細の例を示す。 図５３Ａ〜５３Ｃは、ソフトウェア・リソース送信命令、ソフトウェア・リソース送信応答、およびソフトウェア・リソース送信命令詳細の例を示す。 図５３Ａ〜５３Ｃは、ソフトウェア・リソース送信命令、ソフトウェア・リソース送信応答、およびソフトウェア・リソース送信命令詳細の例を示す。 図５３Ａ〜５３Ｃは、ソフトウェア・リソース送信命令、ソフトウェア・リソース送信応答、およびソフトウェア・リソース送信命令詳細の例を示す。 図５４Ａ〜５４Ｃは、遠隔リソース削除命令、遠隔リソース削除応答、および遠隔リソース削除命令詳細の例を示す。 図５４Ａ〜５４Ｃは、遠隔リソース削除命令、遠隔リソース削除応答、および遠隔リソース削除命令詳細の例を示す。 図５４Ａ〜５４Ｃは、遠隔リソース削除命令、遠隔リソース削除応答、および遠隔リソース削除命令詳細の例を示す。 図５５Ａ〜５５Ｃは、遠隔リソース名変更命令、遠隔リソース名変更応答、および遠隔リソース名変更命令詳細の例を示す。 図５５Ａ〜５５Ｃは、遠隔リソース名変更命令、遠隔リソース名変更応答、および遠隔リソース名変更命令詳細の例を示す。 図５５Ａ〜５５Ｃは、遠隔リソース名変更命令、遠隔リソース名変更応答、および遠隔リソース名変更命令詳細の例を示す。 図５６Ａおよび５６Ｂは、送信および受信テスト命令、ならびに送信および受信テスト応答の例を示す。 図５６Ａおよび５６Ｂは、送信および受信テスト命令、ならびに送信および受信テスト応答の例を示す。 図５７Ａ〜５７Ｃは、ＨＢＡ照会応答詳細、ＨＢＡ照会命令、およびＨＢＡ照会応答の例を示す。 図５７Ａ〜５７Ｃは、ＨＢＡ照会応答詳細、ＨＢＡ照会命令、およびＨＢＡ照会応答の例を示す。 図５７Ａ〜５７Ｃは、ＨＢＡ照会応答詳細、ＨＢＡ照会命令、およびＨＢＡ照会応答の例を示す。 図５７Ａ〜５７Ｃは、ＨＢＡ照会応答詳細、ＨＢＡ照会命令、およびＨＢＡ照会応答の例を示す。

詳細な説明
図１に、ストレージ・エリア・ネットワーク（ＳＡＮ）の一実施形態５０を示す。企業のＳＡＮ５０は普通、大きくて複雑なネットワークであり、１００個のノード、たとえば図１内のノードＡ〜Ｏを含んでいても良い。ＳＡＮ５０のノードＡ〜Ｏは、ファブリック・デバイス１５０Ａ〜１５０Ｃ（たとえば、ファイバ・チャネル（ＦＣ）スイッチ）および１つまたは複数のＦＣハブ１６０によって、互いに結合されていても良い。用語「ファブリック」および「スイッチ」は、本明細書では同意語として用いても良い。ファイバ・チャネル・デバイスの説明においては、用語「スイッチ」は、「ファブリック・デバイス」たとえばブロケード（Ｂｒｏｃａｄｅ）またはマクデータ（ＭｃＤａｔａ）によって製造されたスイッチを、意味する。これらのスイッチは、「ＩＰスイッチ」または「ルータ・デバイス」たとえばシスコ（Ｃｉｓｃｏ）によって製造されたものと、混同してはならない。ファイバ・チャネル・ファブリック・デバイスは、ＳＡＮ５０の一体型コンポーネントである。ＩＰスイッチまたはルータが、別個のイーサネット（登録商標）・ネットワーク上に存在していても良い。しかしＩＰスイッチまたはルータは、ファイバ・チャネルＳＡＮの機能的コンポーネントではない。

ＳＡＮ５０において、ファイバ・チャネルまたはｉＳＣＳＩネットワークが用いられていても良い。他のタイプのネットワークを、実施しても良い。以下の説明では、ファイバ・チャネルを、主な例として用いる場合がある。

ＳＡＮ５０内のノードＡ〜Ｏには、記憶アレイ１４０Ａ、１４０Ｂ、またはコンピュータ・システム／サーバにファイバ・チャネルまたはｉＳＣＳＩＨＢＡ１１２Ａ〜１１２Ｃ（図２Ａ）がインストールされたものが含まれていても良い。これらは、ファブリック・デバイス１５０Ａ〜Ｃに接続されている。ＳＡＮ５０の他の実施形態は、図１におけるコ
ンポーネントに加えてまたはその代わりに、他のコンポーネントを有していても良い。たとえば追加のノード、記憶デバイス、およびファブリック・デバイスである。

サーバおよびＨＢＡ
図２Ａに、遠隔管理者コンピュータ／サーバ１０３、１つまたは複数のホスト／ターゲット・サーバまたはコンピュータ・システム１１０Ａ、１１０Ｂ、および記憶アレイ１４０Ａ、１４０Ｂが、ファブリック１００のポートに結合されたものを示す。ファブリック１００は、１つまたは複数のスイッチ、ハブおよび／またはルータに結合していても良い。図２Ａにおいて、ホスト・サーバ１１０Ａ、１１０Ｂは、ファブリック１００と、ホスト・バス・アダプタ（ＨＢＡ）１１２Ａ、１１２Ｂ、１１２Ｃを介して連絡する。ホスト・バス・アダプタ（ＨＢＡ）は、たとえばエムレックス（Ｅｍｕｌｅｘ）株式会社(コス
タ・メサ（Ｃｏｓｔａ Ｍｅｓａ）、カリフォルニア州）によって作製されたファイバ・チャネルＨＢＡおよびｉＳＣＳＩＨＢＡである。ＨＢＡ１１２Ａ〜１１２Ｃは、遠隔管理エージェント（ＲＭＡ）ソフトウェア１０４Ａ、１０４Ｂ、および１０４Ｃを実行するように動作可能である。

各ホスト・サーバ１１０は、複数のＨＢＡを有していても良い。たとえばホスト・サーバ１１０Ｂは、ターゲット／オブジェクトＨＢＡ１１２Ｂ（共通トランスポート（ＣＴ）管理リクエストの意図されたターゲット）およびプロキシＨＢＡ１１２Ｃを有していても良い。オブジェクトＨＢＡ１１２Ｂが利用できない状況の場合には、ＣＴリクエストを、同じサーバ１１０Ｂ上のプロキシＨＢＡ１１２Ｃに送っても良い。

ＳＡＮ５０の全体に渡ってノードＡ〜Ｏ上にインストールされた各ＨＢＡ１１２（図２Ａ）は、設定およびメンテナンス作業を必要としても良い。

図２Ａ〜２Ｂに、図１のＳＡＮ５０における遠隔管理クライアント（ＲＭＣ）１０２および１つまたは複数の遠隔管理エージェント（ＲＭＡ）１０４Ａ、１０４Ｂの一実施形態を示す。ＲＭＣ１０２およびＲＭＡ１０４は、ＳＡＮ５０内の単一の点（サーバ１０３）がＨＢＡおよび他のコンポーネントを管理できるようにするソフトウェア・コンポーネントの集まりである。この単一点の管理の（サーバ１０３）においてＲＭＣアプリケーション１０２が実行され、その結果、管理機能が得られる。ＨＢＡ１１２Ａ、１１２Ｂ、１１２Ｃがインストールされた他のノードでは、ＲＭＡアプリケーション１０４Ａ、１０４Ｂ、１０４Ｃが実行される。これは、ＲＭＣアプリケーション１０２からの管理リクエストに応答して行なわれる。ＲＭＣアプリケーション１０２から遠隔ＨＢＡ１１２Ａ、１１２Ｂに、ＲＭＣ管理命令が、ファイバ・チャネル・ファブリック１００を介して発行されても良い。

図２Ｂでは、ＲＭＣアプリケーション１０２によって命令が、ファイバ・チャネル・ファブリック１００上に、デバイス・ドライバ２１６Ａによって設けられたインターフェースを介して、発せられる。遠隔ノードＢが命令を受信すると、遠隔ノードＢ上のデバイス・ドライバ２１６Ｂから命令が、ＲＭＡ１０４に送られる。

ＲＭＣ１０２およびＲＭＡ１０４は一緒に、遠隔管理ユーティリティ（ＲＭＵ）と呼んでも良い。ＲＭＣ１０２およびＲＭＡ１０４は、クライアント／サーバ・アーキテクチャ・モデルを形成しても良い。

遠隔管理者
図２Ａでは、遠隔管理者コンピュータ／サーバ１０３は、ＨＢＡ１１２Ｄ、ＲＭＣ１０２、およびＲＭＡ１０４Ｄを有していても良い。遠隔管理者１０３は、ホスト・サーバ１１０Ａ、１１０Ｂのようなコンピュータ・サーバであっても良い。実際には、ＳＡＮ５０
におけるどのサーバ１１０も、ＲＭＣソフトウェア１０２をロードおよび実行し、また遠隔管理者１０３として動作しても良い。

ＲＭＣ１０２が、グラフィカル・ユーザ・インターフェース（ＧＵＩ）を伴うアプリケーション３０２を有することで（図３および図６〜１４）、アドミニストレータが、局所的および遠隔のＨＢＡ１１２Ｄ、１１２Ａ、１１２Ｂ、１１２Ｃをモニタして、命令を発行するようになっていても良い。たとえば遠隔管理者１０３は、新しいＨＢＡファームウェア・バージョンまたは更新を、同じＳＡＮ５０内のＨＢＡ１１２Ｄ、１１２Ａ、１１２Ｂ、１１２Ｃの何れかまたは全てに、転送／コピーしても良い。

遠隔管理クライアント１０２および／またはエージェント１０４は、ユーザによってインストールされても良い。バンドルド遠隔管理パッケージ（適切なドライバを含む）を、エムレックス顧客用のエムレックス・ウェブ・サイト上でのダウンロードに対して利用できるようにしても良い。遠隔管理コンポーネントには、インストール・プロセスが含まれていても良い。インストール・プロセスによって、ＨＢＡドライバおよび要求された全ての遠隔管理者ソフトウェア、ならびにインストール・プロセスおよび動作機能性について説明している「リードミー」ファイルが、インストールされている。ＨＢＡドライバ２１６を、「ＨＢＡニィウェア」クライアント１０２およびエージェント１０４とは別個に、インストールしてもいい。

遠隔管理クライアント（ＲＭＣ）
遠隔管理クライアント（ＲＭＣ）１０２には、ファイバ・チャネルおよび／またはｉＳＣＳＩＨＢＡの両方の遠隔管理を与えても良いソフトウェア・コンポーネントの組が含まれていても良い。ＲＭＣ１０２は、ファイバ・チャネルまたはｉＳＣＳＩＨＢＡを有する任意のマシンまたはシステム上に設けられていても良い。

図３は、図１、２Ａ、および２Ｂにおける遠隔管理クライアント１０２および他の関連するソフトウェアの一実施形態のブロック・ダイアグラムである。たとえば、ウェブ・ブラウザ３１２、マイクロソフト管理コンソール（ＭＭＣ）３０６、ジャバ・ネイティブ・インターフェース（ＪＮＩ）３１９、およびイーサネット（登録商標）・ネットワーク・インターフェース・カード（ＮＩＣ）３３４である。図３の遠隔管理クライアント１０２には、以下の一部または全てが含まれていても良い。シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）アプリケーション３０４、ネイティブ・アプリケーション３１０、ＸＭＬアプリケーション３１４、ジャバ・アプリケーション３０７、ＭＭＣプラグ・イン３０８、ＸＭＬパーサ３１６、ＸＭＬページ・サーバ３２０、ジャバＸＭＬパーサ３１８、遠隔管理アプリケーション・プログラム・インターフェース（ＲＭＡＰＩ）３０４、ＨＢＡＡＰＩ３２４、１つまたは複数のＨＢＡ特有の遠隔管理ライブラリ３０６、ＩＰベースのＦＣ−ＣＴハンドラ３２８、イーサネット（登録商標）ＩＯＣＴＬインターフェース３３０、帯域内ＦＣ−ＣＴハンドラ３０８、およびＦＣドライバ／ＩＯＣＴＬインターフェース３３２。ＨＢＡ特有の遠隔管理ライブラリ３０６には、ＦＣＨＢＡ３２５Ｂに対するＲＭＡＰＩ、および／またはｉＳＣＳＩＨＢＡ３２５Ａに対するＲＭＡＰＩが含まれていても良い。

遠隔管理クライアント１０２の他の実施形態においては、含まれるものが、図３のコンポーネントの全部より少なくても良い。ＲＭＣ１０２の他の実施形態においては、図３に示したコンポーネントに加えてまたはその代わりに、他のコンポーネントが含まれていても良い。

ＲＭＣ１０２（「クライアント１０２」とも呼ばれる）によって、最上位のアプリケーション３０４、３１０、３１２、３１４、３０７が、遠隔管理ライブラリ３２６内の機能
に、コンソール命令プロンプトからアクセス可能となっていても良い。クライアント１０２は、シェル・スクリプト、バッチ・ファイル、または特定のプラットフォーム等価物内からのスクリプト動作において用いるためのものであっても良い。

たとえば、命令ライン・インターフェース（ＣＬＩ）クライアントは、「コンソール・アプリケーション」である。これは、グラフィカル・ユーザ・インターフェース（ＧＵＩ）とは対照的に、テキスト・インターフェースを有している。一実施形態においては、３つのクライアント・アプリケーションが、ＨＢＡニィウェアクライアント１０２によって、与えられる。すなわちウィンドウズ（登録商標）ＧＵＩアプリケーション、ジャバＧＵＩアプリケーション、およびＨＢＡＣＭＤと呼ばれるＣＬＩアプリケーションである。ＣＬＩクライアント命令に対する第１のパラメータは、要求された動作であっても良い。指定された動作が完了したらすぐに、遠隔管理者１０３におけるユーザを、命令プロンプトに戻しても良い。後述するいくつかの動作においては、ＳＡＮ５０上の存在についての情報を取り出して、その情報を管理者コンソール１０３上に表示しても良い（図６〜１４を参照）。

ＣＬＩクライアント命令は、命令の種類を指定する１つまたは複数の追加のパラメータを有していても良い。多くのＨＢＡＣＭＤ命令が用いるパラメータによって、命令のターゲットであるＨＢＡのワールド・ワイド・ノード名が指定される。たとえば、次の命令、
Ｃ：＼＞ＨＢＡＣＭＤ ＰＯＲＴＡＴＴＲＩＢ １０：００：００：００：ｃ９：２０：２０：２０
によって、指定されるワールド・ワイド・ノード名（ＷＷＮＮ）を有するＨＢＡに対するポート属性が表示される
遠隔管理ＡＰＩ（ＲＭＡＰＩ）
サード・パーティの互いに別個のソフトウェア開発者／ベンダ（ＩＳＶ）、たとえばベリタス（Ｖｅｒｉｔａｓ）は、自身の管理アプリケーション（最上位のアプリケーション３０４、３１０、３１２、３１４、３０７の１つによって表わされる）を書いて、外部に見えるＲＭＡＰＩ３２２にアクセスしても良い。ＲＭＡＰＩ３２２によって、局所的および遠隔のホスト・バス・アダプタ１１２Ａ〜１１２Ｄ（図２Ａ）を管理するためのインターフェースが得られる。ＲＭＡＰＩ３２２のことを「遠隔」管理ＡＰＩとは言うけれども、ＡＰＩ３２２も同様に、局所的なアダプタを管理することができても良い。

ＲＭＡＰＩ３２２は、異なるプラットフォームおよびオペレーティング・システム（たとえばウィンドウズ（登録商標）ＮＴ／２０００、ソラリス、ＡＩＸ、ＨＰ−ＵＸ、およびリナックス）の間で、たとえばジャバ・アプリケーション３０７を介して、安定した堅固な遠隔管理インターフェースであっても良く、また任意の環境における任意のＨＢＡに適用可能であっても良い。

ＲＭＡＰＩ３２２は、遠隔管理を希望する遠隔管理者コンピュータ１０３上の何れかのアプリケーション３１０、３１２、３１４または３０７によって、動的にロードしても良い。

マイクロソフト・ウィンドウズ（登録商標）環境では、ＲＭＡＰＩ３２２は、ウィンドウズ（登録商標）・ダイナミック・リンク・ライブラリ（ＤＬＬ）として存在していても良い。種々のユニックス環境の下では、ＲＭＡＰＩ３２２は、共有オブジェクト・ライブラリの形態であっても良い。

ＲＭＡＰＩ３２２は、マルチ・スレッドであっても良い。その結果、複数のアプリケーションが、ライブラリ３２６に同時にアクセスすることができる。

ＲＭＡＰＩ３２２によって、以下の幅広いカテゴリの管理ＲＭＡＰＩ機能が得られる。

指定されるファームウェア画像（ファイル）を、指定されるＷＷＮＮを有する局所的および遠隔のＨＢＡ１１２Ａ〜１１２Ｄへロードする。ファイルは、クライアント１０２（図１３〜１４）にアクセス可能である任意のファイルとすることができる。

局所的および遠隔のＨＢＡ１１２Ａ〜１１２Ｄ（図９〜１０）のドライバ・パラメータを取り出して、見て、変更する。

遠隔ドライバを管理およびロードする。

永続的な結合を管理して、維持して、付加する。永続的な結合は、ＳＡＮアドミニストレータが、ＳＡＮ５０上の物理的なデバイスと、オペレーティング・システムが見る論理デバイスとの間に設ける関係である。本質的には、永続的な結合は、それぞれの物理ＳＡＮデバイスを論理ＯＳデバイスにマッチングさせるデータの表として存在する。

１つまたは複数のＨＢＡ１１２Ａ〜１１２Ｄを、１つまたは複数の指定されるワールド・ワイド・ポート名によってリセットする。

ＨＢＡ１１２Ａ〜１１２ＤのＩＥＥＥアドレスを設定または変更する。

ＲＭＡＰＩ３２２またはクライアント１０２の特有の機能には、以下のものが含まれていても良い。

ＨＢＡ診断を実行する。

発見された管理可能なＨＢＡ１１２Ａ〜１１２Ｄおよびそれらのワールド・ワイド・ノード名のリストを表示する（図６および７を参照）。

それぞれの指定されるワールド・ワイド・ノード名を有する局所的または遠隔のＨＢＡ１１２に対するＨＢＡ属性／パラメータのリストを表示および設定する（図９〜１０を参照）。

指定されるワールド・ワイド・ポート名を有する局所的または遠隔のポートに対するポート属性／パラメータのリストを表示および設定する（図１１を参照）。

指定されるワールド・ワイド・ポート名を有するポートに対するポート統計のリストを表示する（図１２）。

指定されるポートに対するポート統計をゼロにリセットする。

指定されるサーバに対する属性のリストを表示および設定する（図８を参照）。

それぞれの指定されるワールド・ワイド・ポート名を有するポートに対するマッピングされたターゲットのリストを表示する（図６および１１を参照）。

指定されるワールド・ワイド・ポート名を有するポートに対するデバイス・ドライバ属性のリストを表示する（図９〜１０を参照）。

図１５Ａは、主要なＲＭＡＰＩ機能カテゴリ、個々のＲＭＡＰＩ機能、およびそれらの
関連するＦＣ−ＣＴ命令の一実施形態を示す。図１５Ｂは、ＨＢＡＡＰＩ機能およびＲＭＡＰＩ機能の例を示す。

クライアント１０２が行なう機能の多くは、ファイバ・デバイス管理インターフェース（ＦＤＭＩ）機能である。クライアント１０２が、たとえばＨＢＡ属性機能取得を実施する際、クライアント１０２は、ベンダ・ユニークなＧＳ＿タイプ値である０ｘ０Ａを用いても良く、ＦＤＭＩ管理サービスに対するＦＣ−ＧＳ仕様によって指定される標準的ＧＳ値＝０ｘＦＡでなくても良い。ＦＣ−ＧＳとは、ファイバ・チャネル汎用サービスのことであり、これは、ファイバ・チャネル界では良く知られた業界標準仕様である。同様に、ＦＣ−ＣＴ命令コードは、必ずしも０ｘ０１０１でなくても良い。

他の機能がユニークであっても良い。またファイバ・デバイス管理インターフェース（ＦＤＭＩ）または相互接続用ファイバ・チャネル方法論（ＦＣ−ＭＩ）には、実際のモデルは存在しない。一例は、前述したファームウェア・ダウンロード操作である。

ＲＭＡＰＩ機能の属性には、標準的なＨＢＡＡＰＩ機能のすべて（図１５Ｂおよび付録Ｂを参照）とともに、前述した追加機能が含まれていても良い。ＲＭＡＰＩ３２２（付録Ａのページ６〜２５を参照）は、ＨＢＡＡＰＩ（付録Ｂを参照）によって得られる局所的な能力を、局所的および遠隔のアクセスの両方を含むように移動させるためのものである。ＨＢＡＡＰＩ機能は、ＲＭＡＰＩ機能のサブセットを表していても良い。

ＨＢＡ特有のＲＭＡＰＩライブラリ
一実施形態においては、ＲＭＡＰＩ３２２は、ＨＢＡ１１２の特定のタイプに対する別個のＲＭＡＰＩライブラリ３２５Ａ、３２５Ｂを動的にロードしても良い。たとえば図３において、２つのＨＢＡ特有のＲＭＡＰＩライブラリが存在する。すなわち、ファイバ・チャネルＲＭＡＰＩ（ＦＣ−ＲＭＡＰＩ）３２５Ｂ、およびｉＳＣＳＩＲＭＡＰＩ（ＩＳＣＳＩ−ＲＭＡＰＩ）３２５Ａである。ＲＭＡＰＩ３２２は、アプリケーションから受信した汎用管理リクエストを、適切なライブラリ３２５へ転送する。これらのＨＢＡタイプ特有のライブラリ３２５Ａ、３２５Ｂは、リクエストに対する処理の大部分を取り扱っても良い。各ライブラリ３２５によって、管理機能に対するプログラム・アクセスが得られても良い。

ＲＭＡＰＩ３２２は、会社の委員会であるＳＮＩＡによって開発された標準的なＨＢＡＡＰＩアーキテクチャのパラダイム（付録Ｂ参照）のラッパー・ライブラリ・コンポーネントに、意図的に、ある点で同様であっても良い。

ＦＣＨＢＡ（ＦＣ−ＲＭＡＰＩ）に対するＲＭＡＰＩライブラリ
ＦＣ−ＲＭＡＰＩ３２５Ｂは、遠隔管理を希望する任意のアプリケーション、たとえばアプリケーション３１０、３１２、３１４または３０７の１つによって、動的にロードしても良い。ＦＣ−ＲＭＡＰＩ３２５Ｂは、ＳＮＩＡＨＢＡＡＰＩの核となる機能性、エムレックス・ライトパルス（ＬｉｇｈｔＰｕｌｓｅ）ユーティリティと新しい機能の組とを結合して、単一の凝集したアプリケーション・プログラム・インターフェースにしても良い。局所的または遠隔に配置された任意のＨＢＡ１１２を、ＦＣ−ＲＭＡＰＩ３２５Ｂを介して管理可能であっても良い。

ＦＣ−ＲＭＡＰＩライブラリ３２５Ｂは、ＲＭＡＰＩ３２２から管理リクエストを受領し、リクエストを適切な遠隔または局所的なＨＢＡ１１２へ送出するために用意する。ＦＣ−ＲＭＡＰＩ３２５Ｂは、ファイバ・チャネル汎用サービス（ＦＣ−ＧＳ）の共通トランスポート（ＣＴ）プロトコル層を用いて、管理リクエストをＨＢＡ１１２Ａ〜１１２Ｄへ伝達しても良い。

ＦＣ−ＣＴ命令
ＦＣ−ＲＭＡＰＩ３２５Ｂは、ＲＭＡＰＩ管理機能を、対応するＦＣ−ＣＴ命令にマッピングするように動作可能である（図１５Ａに図示する）。場合によっては、１対１の対応関係が、ＲＭＡＰＩ機能とＦＣ−ＣＴ命令との間に存在しても良い。

拡張ＦＣ−ＣＴ命令の特定の組を、ＦＣ−ＲＭＡＰＩ３２５Ｂに対して形成しても良い。図２４に、ベンダ・ユニークなＦＣ−ＣＴ命令コードの例を示す。

標準的なＣＴ命令の組を、以下の幅広いカテゴリの機能を行なう命令によって、拡張しても良い。

ファイル・リソース（たとえば、ファームウェア画像）を、ＨＢＡへ送信／ダウンロードする（図１３〜１４参照）。

遠隔ファイル・リソースを取得する。

起動バイオス状態を設定する。起動バイオスをイネーブル／ディスエーブルする。

ＨＢＡファイル、すなわち、ファームウェア・ファイル、ドライバ・ファイル、ライブラリ・ファイルを管理する。

ＨＢＡ属性、ポート属性統計およびドライバ・パラメータを、取り出して変更する（図９〜１２を参照）。

デバイス特有の動作たとえばファームウェア・ファイルのダウンロード（図１３〜１４参照）、ドライバのインストール、およびＨＢＡのリセットを開始する。

ＨＢＡＡＰＩ適合性の情報を遠隔ＨＢＡから取り出す。

図３のデバイス・ドライバ３３２は、ＦＣ−ＣＴ命令パケットを、ファブリック１００を介して送信されるべき共通トランスポート情報単位（ＣＴ＿ＩＵ）リクエスト内に配置する。ファブリック・デバイスは、ＳＡＮ５０の絶対に必要なコンポーネントというわけではない。ＨＢＡニィウェア命令が遠隔ＨＢＡに送られる。ＨＢＡニィウェア命令は、ルート内のファブリック・デバイスを通過しても良い。共通トランスポート情報単位に対する略語は、ファイバ・チャネル標準では具体的に「ＣＴ_ＩＵ」と呼ばれているが、本明
細書においては「ＣＴ ＩＵ」、「ＣＴＩＵ」、および「ＣＴ−ＩＵ」と呼ぶこともある。こうして、３つのレベルの命令／機能／ルーチンが存在する。（ａ）ＲＭＡＰＩ機能、（ｂ）ＦＣ＿ＣＴ命令、および（ｃ）ＣＴ＿ＩＵリクエスト（ＩＯＣＴＬ機能／ルーチン内に配置される）。

前述したように、ソフトウェア会社は、ＲＭＡＰＩ機能にＲＭＡＰＩ３２２（図３）を介してアクセスするソフトウェア・アプリケーションを開発しても良い。一方でデバイス製造業者は、ハードウェア・デバイス、たとえばスイッチまたはＲＡＩＤ記憶デバイスを、ソフトウェア・ライブラリにアクセスしないがその代わりにＣＴ命令を直接用いるファブリック１００に対して、開発しても良い。したがって、遠隔管理を行なうためにサード・パーティ会社がアクセスしても良い可能なインターフェースが２つ存在する（ＲＭＡＰＩ３２２およびＣＴ命令）。

本明細書で説明したＦＣ−ＣＴプロトコル・アプリケーションに適応するために、既存
のＣＴ標準に対して多少の拡張を行なっても良い。たとえば、ＦＣ−ＣＴリクエストの受取人が、良く知られたファブリック・アドレス、たとえば名前サービスまたは時間サービスなどのサービスであっても良い。ファイバ・チャネル・ファブリック・デバイス１９は、サービスの組をＳＡＮ５０に提供しなければならない。他のＳＡＮデバイスは、これらのサービスの特徴にアクセスすることを、これらのサービスが有するように要求されている良く知られたファイバ・チャネル・アドレスに命令を出すことによって、行なっても良い。ＦＣ−ＲＭＡＰＩ３２５Ｂは、ＦＣ−ＣＴリクエストを、特定のターゲット、たとえばファイバ・チャネル１００上のデバイス・ポートの特定のワールド・ワイド・ポート名（ＷＷＰＮ）に、送っても良い。意図されたターゲット・アドレスを、ＦＣＣＴリクエスト・ヘッダ内に挿入しても良い。

以下、ＦＣ−ＣＴおよびＣＴ＿ＩＵについての詳細な説明を、クライアント１０２およびエージェント１０４の他のコンポーネントについて説明した後で、行なう。

帯域内および／または帯域外トランスポート
ＣＴリクエストは、帯域内でファイバ・チャネルを介して、または帯域外でイーサネット（登録商標）を介してトランスポート可能であっても良い。たとえば、ＦＣ−ＲＭＡＰＩ層３２５Ｂの下に直接、３つのインターフェースがあっても良い。すなわち、帯域外通信用のＩＰベースのＦＣ−ＣＴハンドラ３２８、帯域内ＦＣ−ＣＴハンドラ３３０、およびファイバ・チャネル・デバイス・ドライバ／ＩＯＣＴＬインターフェース３３２である。ＦＣ−ＲＭＡＰＩ層３２５Ｂは、管理リクエストを、帯域内ＦＣ−ＣＴハンドラ３３０または帯域外ＩＰベースのＦＣ−ＣＴハンドラ３２８に転送する。転送先は、どちらのトランスポート媒体を選択するかに依存する。すべての遠隔管理リクエストを、帯域外ＩＰベースのＦＣ−ＣＴハンドラ３２８または帯域内ＦＣＣＴハンドラ３３０を通して、ルーティングしても良い。すべての局所的なＨＢＡ管理リクエストを、デバイス・ドライバ／ＩＯＣＴＬインターフェース３３２まで、ルーティングしても良い。

ハンドラ３２８、３３０およびインターフェース３３０、３３２は、適切なヘッダを命令パケットに付加しても良く、またリクエストが適切な媒体を介して送られていることを確実にしても良い。

ｉＳＣＳＩＨＢＡ（ＩＳＣＳＩ−ＲＭＡＰＩ）に対するＲＭＡＰＩライブラリ
ＩＳＣＳＩ−ＲＭＡＰＩライブラリ３２５Ａは、ＲＭＡＰＩ３２２から管理リクエストを受領し、リクエストをＳＡＮ５０などのＩＰストレージ・ネットワーク上の適切な遠隔の存在に送出するために用意する。

ＩＳＣＳＩ−ＲＭＡＰＩライブラリ３２５Ａは、以下の管理命令をｉＳＣＳＩプロトコルに適した仕方で、パッケージして送ることが可能であっても良い。

ＨＢＡ属性を取り出す。

ファイル・リソースを送る（たとえば、ファームウェア画像をＨＢＡ１１２へ）。

ファームウェアをダウンロードする。

遠隔ファイル・リソースを取得する
起動バイオス状態を設定する。

帯域内ＦＣ−ＣＴハンドラ
帯域内ＦＣ−ＣＴハンドラ３３０は、帯域内ＦＣ−ＣＴＨＢＡ管理リクエストの送信を
担っている。帯域内ＦＣ−ＣＴハンドラ３３０は、完全に指定されたＦＣ−ＣＴＩＵを入力として受信し、必要に応じて、ファイバ・チャネル１００を介してトランスポートするために封入する。帯域内ＦＣ−ＣＴハンドラ３３０は、たった一つのインターフェース・エントリ・ポイント、「管理命令送信」を有していても良い。このポイントを通して、ＲＭＡＰＩ３２２が、管理リクエストを含むＦＣ−ＣＴＩＵ、および応答ＣＴ＿ＩＵを受信するホスト・メモリ内のバッファの場所を送る。これは、応答を受信するかまたはリクエストが時間切れになるまで阻止される同期ルーチンであっても良い。

ＩＰベースのＦＣ−ＣＴハンドラ
ＩＰベースのＦＣ−ＣＴハンドラ３２８は、ＩＰベースのＦＣ−ＣＴリクエストに対する封入層である。ＩＰベースのＦＣ−ＣＴハンドラ３２８は、完全に指定されたＦＣ−ＣＴＩＵを入力として受信し、イーサネット（登録商標）１３０を介してトランスポートするために適切なＩＰヘッダによって封入しても良い。

ジャバ・ネイティブ・インターフェース
一般に、ジャバ・ネイティブ・インターフェース層３１９は、ジャバ・アプリケーション３０７に、「ネイティブ」ルーチンを呼び出す能力を与える。「ネイティブ」ルーチンは、コードが実行されているプラットフォーム・タイプに対して具体的にコーディングされるルーチンである。具体的には、ジャバ・ネイティブ・インターフェース層３１９を用いて、ジャバ遠隔管理アプリケーション３０７と遠隔管理ＡＰＩ（ＲＭＡＰＩ）３２２との間をインターフェースする。遠隔管理ＡＰＩ（ＲＭＡＰＩ）３２２は、ネイティブＣコードで書かれていても良い。

ジャバ・ネイティブ・インターフェース３１９を所定の位置に配置することには、実際のコーディング作業自体は含まれていなくても良い。ＲＭＡＰＩダイナミック・ライブラリ内のルーチン（ウィンドウズ（登録商標）環境におけるＤＬＬ、またはユニックス環境における共有のオブジェクト・ライブラリ）を、対応するジャバ・クラスにマッピングしても良い。これは、利用可能な自動化されたツールに加えて多少の変更を用いることによって、かなり迅速に行なっても良い。

ＸＭＬページ・サーバ
ウェブ・ブラウザおよび他のＸＭＬ適応型アプリケーションには、管理されたコンポーネントから戻った情報を、ＸＭＬ対応のドキュメントに変換するオプションが含まれていても良い。ＸＭＬは、情報交換用に広く使用される標準になりつつある。データをＸＭＬドキュメントの形態で与える利点は、ウェブ・ブラウザおよび他のＸＭＬ適応型アプリケーションによって、容易に統合されて扱われることである。

ＸＭＬページ・サーバ３２０を通して、アプリケーション３１０、３１２、３１４が、たとえば遠隔ＨＢＡのポート統計表（図示せず）を含むＸＭＬドキュメントを、リクエストできても良い。ＸＭＬページ・サーバ３２０は、要求されたデータをＲＭＡＰＩ３２２を介して取り出し、ＲＭＡＰＩ３２２からフェッチされたデータを用いてＸＭＬドキュメントをアセンブルし、およびＸＭＬドキュメントをアプリケーション３１０、３１２または３１４に戻す。

ＸＭＬパーサ
１つまたは複数のＸＭＬパーサ３１６を用いて、ＸＭＬドキュメントを翻訳しても良い。ＸＭＬパーサ３１６は、ＸＭＬドキュメントを走査して、ドキュメントを、アプリケーション３１０、３１２または３１４が利用可能なフォーマットにする。ＸＭＬパーサの多くは、広く入手できる。

ジャバＸＭＬパーサ
ＲＭＣ１０２がジャバおよびＸＭＬの両方をサポートする場合には、ジャバ・アプリケーションに対して具体的にデザインされたＸＭＬパーサ３１８があっても良い。広く入手できるジャバ用のＸＭＬパーサはいくつかある。たとえば「ジャバ用ＸＭＬ」である。

ＸＭＬアプリケーション
ＸＭＬドキュメントに対応できるアプリケーション３１４を「ＸＭＬ適応型」と呼んでも良い。たとえば、ウェブ・ブラウザ（ネットスケープまたはインターネット・エクスプローラ・バージョン５．０以降）は、ＸＭＬ適応型アプリケーションである。

ネイティブ・アプリケーション
エムレックスによって開発される各プラットフォームは、局所的なＨＢＡ管理に対するネイティブ・アプリケーション３１０を有していても良い。遠隔管理に対して設けられる機能の多くは、局所的な管理に対する機能と同様であっても良い。ネイティブ・アプリケーション３１０は、これらの局所的なＨＢＡ管理ルーチンを拡張して、遠隔操作を扱えるようにしても良い。

ジャバ・アプリケーション
ジャバ・アプリケーション３０７は、利点として、コード移植性およびクロス・プラットフォーム保全性を有していても良い。加えて、ジャバ・アプリケーション３０７は、外観および感触が、すべてのプラットフォームに渡って一貫していても良い。「ジャスト・イン・タイム」（ＪＩＴ）コンパイラを用いて、バイトコードを、実行時にマシン・ネイティブ・コードに翻訳しても良い。

リポジトリ
複数のＦＣ−ＲＭＡＰＩ機能が、遠隔サーバ１１０Ａ、１１０Ｂ上に配置されたファイル上で動作しても良い。たとえば、クライアント１０２からのファイル（たとえば、ファームウェア）を遠隔サーバ１１０へ送って、遠隔サーバ１１０上の既存のファイル名を変更し、および遠隔サーバ１１０上で利用可能なファイルのリストを取り出す、という要求があっても良い。このような操作を行なうために、ファイルを、局所的および遠隔のホスト・サーバの両方１０３、１１０Ａ、１１０Ｂ上の予め規定された場所に配置しても良い。

特別なリポジトリ３４０（図３）を用いて、２つのホスト間で転送されるファイルを保持しても良い。リポジトリ３４０には、ホスト・マシンのディスク上のディレクトリが含まれていても良い。これらのファイルは通常は、ＨＢＡにダウンロードすることが意図されるファームウェア画像である。

ＨＢＡファイルを遠隔サーバ１１０へ送ることが可能となる前に、まずファイルを局所的なリポジトリ３４０内へインポートしなければならない。と言うのは、これが、動作に対する暗黙の出発点であるからである。同様に、ＨＢＡファイルを遠隔サーバ１１０へ送った後で、そのファイルが、目標とした遠隔ホスト・サーバ１１０のリポジトリ４５０（図４）内に存在していても良い。

リポジトリ３４０、４５０のさらなる特徴は、そこに含まれるＨＢＡファイルの名前が、ウィンドウズ（登録商標）・ベースであろうとユニックス・ベースであろうと任意のホスト・アプリケーションのファイル・システムによってファイルを管理できるようなものであることである。したがって、ＨＢＡファイルをリポジトリ３４０、４５０内へインポートすることには、ファイル名を、すべてのＯＳプラットフォーム上で構文的に容認できるフォーマットに変換することも含まれていても良い。

リポジトリによる遠隔ダウンロード
図２２に、ファームウェアまたはデバイス・ドライバを遠隔サーバにダウンロードする方法を示す。ファームウェア・ファイルが局所的なホスト１０３上に配置される。局所的なホスト１０３は、そのファイルをコピーして遠隔サーバ１１０上のアダプタ１１２にインストールすることを希望する。

ブロック２２００では、クライアント１０２が、ＨＢＡファイルを、局所的なリポジトリ３４０（図３）へインポートする。ファイルのインポートが、それ以前の操作の代わりに行なわれていた場合には、このステップは不必要である。

ブロック２２０２では、クライアント１０２は、ファームウェア・ファイルが、ファイルを受信するべき遠隔アダプタ１１２と適合することを確認する。ファームウェア・ファイルが適合し得るのは、ファイルが良好なチェックサムを有して、そのタイプがアダプタ・タイプとマッチングする場合である。

ブロック２２０４では、いったん適合性が確認されたら、ファイルを、ターゲット・アダプタ１１２がインストールされる遠隔ホスト１１０へ送る。遠隔ホスト１１０がファイルを受信したら、ファイルをそのホスト１１０のリポジトリ４５０へコピーする。

ブロック２２０６では、遠隔サーバ１１０がファイル・ダウンロード命令を受信する。ファイル・ダウンロード命令は、遠隔サーバ１１０に、そのリポジトリ４５０内にあるファームウェア・ファイルを、指定されるアダプタ１１２上にインストールすることを命令するものである。

ＩＯＣＴＬインターフェースおよびＩＯＣＴＬ機能
ドライバＩＯＣＴＬインターフェース３３２は、ＳＡＮ５０のコンポーネントに対して、同様にＲＭＡＰＩ３２２にアクセスするソフトウェアに対して、透明であっても良い。ＩＯＣＴＬインターフェースは、その性質そのもののために、ベンダー・ユニークで、移植性がなく、またどんな業界標準にも適合しない。ＨＢＡニィウェアクライアント１０２またはエージェント１０４（図２Ｂ）は、ＩＯＣＴＬ命令をドライバ２１６に発行して、クライアント１０２またはエージェント１０４が必要とする情報を得る。しかしＲＭＡＰＩインターフェース３２２および／またはＣＴインターフェース３２５Ｂは、このインターフェース３３２を、任意の外部パーティから取り出す。

図３および４における１つまたは複数のプラットフォーム・デバイス・ドライバ３３２、４００を拡張して、ＩＯＣＴＬ機能の新しい組を得ても良い。これらのＩＯＣＴＬ機能／ルーチンによって、ファイバ・チャネル・ネットワーク上の別個のノード間で管理命令および応答（たとえば、遠隔サーバ１１０に対する応答）を送信すること、および遠隔サーバ１１０から管理応答を受信することに対するメカニズムが得られても良い。たとえば、ＩＯＣＴＬによって得られるメカニズムとして、遠隔管理者クライアント１０２におけるデバイス・ドライバ３３２に通知してＣＴリクエスト（命令）を遠隔サーバ・エージェント１０４に送信し、およびその命令に対する応答を遠隔サーバ・エージェント１０４から受信するためのものであっても良い。

ノードは、ＦＣ共通トランスポート・シーケンスとして送信される命令のベンダ・ユニークなセットを用いて、互いに連絡し合う。これらのＩＯＣＴＬルーチンは、デバイス・ドライバによって、またはデバイス・ドライバに密接に結ばれた診断ライブラリによって、得られる。

以下のＩＯＣＴＬ命令セットによって、ノードは、クライアント・ノード１０３もしくはサーバ・ノード１１０として、またはクライアント・ノードおよびサーバ・ノードの両方として同時に、機能することができる。クライアント・ノードは、管理リクエストをいつ発行しても良い。またサーバ・ノードを、非請求の管理リクエストに応答するように用意しなければならない。

ＦＣ共通トランスポートによって、リクエストおよび応答メカニズムが得られる。クライアント・ノード１０３は、管理リクエストを、共通トランスポート情報単位（ＣＴ＿ＩＵ）の形態で発行する。このＣＴ＿ＩＵには、ファブリックのＤ＿ＩＤ、リクエストを受信するべきノード１１０のＷＷＰＮ（ＨＢＡニィウェア命令が特定のＨＢＡ１１２に、そのＨＢＡ１１２のＷＷＰＮを用いてアドレス指定される）、リクエスト命令コード、リクエストによって要求されるパラメータ、および付随する任意のペイロード・データが、含まれる。各リクエストの結果、遠隔ノード１１０から、ＣＴ＿ＩＵの形態で受領応答または拒絶応答が得られる。受領応答ＩＵには、ステータス・データと命令に付随するペイロード・データとが含まれる。拒絶応答ＩＵには、拒否理由を示すエラー情報が含まれる。

付録Ｃに、ＦＣ−ＣＴ命令をトランスポートするために用いても良いＩＯＣＴＬルーチン／機能の例がリストされている。

ＣＴ事象登録
ＣＴ事象登録（（ボイド＊）（コールバック＿機能）（ＣＴＰＫＴ＊ ｃｔＰｋｔ、ＵＩＮＴ ｃｔサイズ））と呼ばれるＩＯＣＴＬ機能によって、コールバック・ルーチンを登録しても良い。コールバック・ルーチンは、エージェントの遠隔命令モジュール４１０が遠隔管理命令を受信する度に、デバイス・ドライバ４００（図４）によってディスパッチされる。ＦＣ−ＣＴ遠隔命令モジュール４１０Ａは、このコールバック・ルーチンを呼び出して、遠隔命令の受信を可能にする。

ホスト・サーバ１１０が、ＣＴ事象登録ＩＯＣＴＬを用いて、ＦＣ−ＣＴ管理命令を受信したときにサーバ１１０が通知を受けたい旨をデバイス・ドライバ４００に通知しても良く、また機能呼び出し（これにより、デバイス・ドライバ４００がそうしても良い）などのメカニズムを実現しても良い。

帯域内ＦＣ−ＣＴ遠隔命令モジュール４１０Ａは、ドライバ４００に、そのＣＴ事象登録ＩＯＣＴＬを介して登録して、コールバック・ルーチンを実現する。入ってくる命令をドライバ４００が受信すると、このコールバック・ルーチンが命令を帯域内ＦＣ−ＣＴ遠隔命令モジュールに送る。帯域内ＦＣ−ＣＴ遠隔命令モジュールは、命令をＲＭＡカーネル命令ディスパッチャまたはディスパッチ・ルーティング４１２に送る。

ＣＴ事象登録ルーチンによって、管理リクエストが到着したことをサーバ・アプリケーション（エージェント）１０４に知らせるためのデバイス・ドライバ４００（図３）の手段が得られる。サーバ・アプリケーション１０４は、ＣＴ事象登録ルーチンを一度呼んで、将来のリクエストの通知を受信するという自身の希望を登録し、および通知を受信するための手段として呼び出されるコールバック・ルーチンを指定する。

サーバ・アプリケーション１０４がＣＴ事象登録を呼んだ後で、ドライバ４００が、入ってくる各リクエストに対して、コールバック・ルーチンを一度呼び出す。コールバック・ルーチンは、入ってくるＣＴリクエストに対するポインタと、デバイス・ドライバ４００によって割り当てられたユニークなタグ値とを、受信する。このタグをドライバが用いて、この命令をその後の応答に関連付ける。

ＣＴ事象登録解除
ホスト・サーバ１１０は、ＣＴ事象登録解除と呼ばれる他のＩＯＣＴＬ機能を用いて、ＣＴ事象の登録を解除しても良い。ＣＴ事象登録解除ルーチンは、以前のＣＴ事象登録呼び出しのコールバック効果をサーバ・アプリケーション１０４がキャンセルできるように、設けられている。

管理命令送信および管理応答送信
管理命令および管理応答を送信するための２つのＩＯＣＴＬ機能は、管理命令送信（ＵＩＮＴ３２アダプタ、ＵＣＨＡＲ＊ｄｅｓｔＷＷＮ、ＣＴＰＫＴ＊ｃｍｄＰｋｔ、ＵＩＮＴｃｍｄサイズ、ＣＴＰＫＴ＊ｒｓｐＰｋｔ、ＵＩＮＴｒｓｐサイズ、ＵＩＮＴ３２タグ）、および管理応答送信（ＵＩＮＴ３２アダプタ、ＵＣＨＡＲ＊ｄｅｓｔＷＷＮ、ＣＴＰＫＴ＊ｒｓｐＰｋｔ、ＵＩＮＴｒｓｐサイズ、ＵＩＮＴ３２タグ）と呼ばれる。管理命令送信の目的は、クライアント１０２からの管理命令を、エージェント１０４へ送信することである。管理応答送信の目的は、エージェント１０４からの管理応答を、クライアント１０２へ送信することである。これらの命令および応答は、ＦＣ−ＣＴを介して、伝えても良い。

管理命令送信によって、特定のワールド・ワイド・ポート名を対象にすることができる命令を送るためのＨＢＡＡＰＩのＣＴ通過メカニズムの変形が得られても良い。エージェント１０４におけるＦＣ管理サービス１３０Ａが、この機能を用いて、クライアント１０２からの遠隔命令に応答しても良い。

管理命令送信ルーチンは、遠隔宛先ノード１１０にリクエストを送るように要求されるすべてのタスク（たとえば、リクエストを完全にするために要求される何らかのログイン行為）を担っている。管理命令送信ルーチンは、ブロッキング同期機能であっても良い。この機能は、遠隔ノードがリクエストに、受領または拒絶ＣＴ＿ＩＵによって応答するまで、ステータスを戻さない。管理命令送信ルーチンの機能性は、ＨＢＡＡＰＩライブラリによって与えられるＨＢＡＣＴ送信通過ルーチンに非常に似ていても良い。

ＲＭＡＰＩ３２２は、管理リクエストを含むＣＴ＿ＩＵ構造を構築する。管理リクエストのターゲットは、管理命令送信ルーチンのターゲットＷＷＷパラメータによって指定される。命令は、ドライバによって、管理命令送信ルーチンのｄｅｓｔＷＷＮフィールド内で指定されるアダプタ１１２にルーティングされていなければならない。ＣＴ＿ＩＵのＧＳ＿タイプおよびＧＳ＿サブタイプ・フィールドにはどんな値が含まれていても良く、またこのドキュメント内で指定されるルーチンは、これらのフィールドを構文解析しようとしてはならない。

サーバ・アプリケーション１０４は、いったん管理リクエストを受信したら、管理応答送信ルーチンを用いて応答を発行することができる。サーバ・アプリケーション１０４によって、応答を含むＣＴ＿ＩＵ構造が構築される。管理応答送信ルーチンに対するパラメータには、この応答構造に対するポインタ、および応答される管理リクエストのユニークなタグが含まれる。このタグによって、デバイス・ドライバ４００は、入ってくるリクエストのＸＲＩに応答を関連付けて、交換を適切に終了できるようにすることができる。

ユーザ・モード・アプリケーション１０４の関数を呼び出すデバイス・ドライバ４００の能力に関する詳細は、オペレーティング・システムごとに、およびデバイス・ドライバ・モデルごとに、大きく異なっていても良い。コールバック・ルーチンを実際に呼び出すコードは、デバイス・ドライバ４００と別個であっても良い。

ソラリス環境では、ｌｉｂｄｆｃライブラリによって、ユーザ・モードで実行される別
個のコンポーネントがすでに得られるため、コールバック特徴に対するサポートには、このライブラリを拡張することが含まれていても良い。マイクロソフト・ドライバ・プラットフォームは、より複雑となる可能性がある。と言うのは、ポート・ドライバまたはミニポート・ドライバには、標準的なユーザ・モード・コンポーネントがなくても良いからである。ドライバ・レベル・サポートでは、新しいソフトウェア・コンポーネント（たとえばカーネル・モードＤＬＬ、ユーザ・モードＤＬＬ、フィルタ・ドライバなど）を加えることが要求されても良い。これらの詳細は、ＦＣ−ＣＴ命令セットによって与えられる抽象層の背後に隠されていても良い。

ＦＣ−ＣＴ命令セットでは、仮定として、ＣＴ事象登録ルーチンを実現するコードが、入ってくる管理命令に対してバッファを割り当てることができおよびバッファ・ポインタをコールバック・ルーチンに送ることができると、されていても良い。このモデルによって、バッファをコピーすることが最小限に抑えられる。他の実施形態においては、サーバ・アプリケーション１０４がバッファ割り当てを担うように、モデルを変更しても良い。

タグ・メカニズムは、デバイス・ドライバ４００が、入ってくる管理リクエストの交換コンテキストを保存して、その後の応答がこのコンテキストを使用できるように、するためのものである。

効果的な命令タイムアウト・メカニズムが、非常に長い操作（ファームウェア・ダウンロードのような）に適応して、別個のＣＰＵ間のプロセス・デッドロック状況を回避しても良い。

デバイス・ドライバ４００は、複数のクライアント・アプリケーション１０２からの同時の管理リクエストに適応することができても良い。

このＦＣ−ＣＴ命令セットを用いる管理アプリケーションが、セキュリティを目的とする認証されたＣＴシーケンス用いるために、必要とされても良い。ＦＣ−ＧＳ３において指定される８８バイトの拡張プリアンブルを、送信されるすべてのシーケンスに対して用いても良い。

遠隔管理エージェント（ＲＭＡ）
図１における遠隔管理エージェント１０４Ａ〜１０４Ｄを、各サーバ１１０、１０３において局所的にロードしても良い。サーバ１１０Ａ、１１０Ｂにおける既存のホスト・ドライバを、ＨＢＡ１１２Ａ〜１１２Ｄ間の新しい関係をサポートするように変更しても良い。たとえばＳＡＮネットワーク１００上のサーバ１１０は、非請求のメッセージを他のサーバ１０３から受信しても良く、またメッセージがネットワーク１００上の遠隔管理者１０３からであることを決定できなくてはならない。

図４に、ファイバ・チャネル１０２、ホスト・バス・アダプタ（ＨＢＡ）１１２、デバイス・ドライバ／ＩＯＣＴＬインターフェース４００、遠隔管理エージェント（ＲＭＡ）１０４、およびイーサネット（登録商標）１３０の一実施形態を示す。遠隔管理エージェント１０４には、複数の遠隔命令モジュール４１０Ａ〜４１０Ｄ、遠隔管理エージェント・カーネル４１８、複数のプロトコル管理者モジュール（ＰＭＭ）４２０Ａ〜４２０Ｃ、および複数の管理サービス４３０Ａ〜４３０Ｄが、含まれていても良い。エージェント１０４の他の実施形態には、図４に示すコンポーネントの代わりにまたはこれに加えて、他のコンポーネントが含まれていても良い。

一般的に、遠隔管理エージェント（ＲＭＡ）１０４は、遠隔の存在たとえばクライアント１０２から管理命令を受信して、これらの命令を、実行させるために適切な管理サービ
ス１３０に送っても良いソフトウェア・コンポーネントの集まりである。ＲＭＡ１０４は、遠隔管理すべきハードウェア・デバイスを有するどんなホストＣＰＵ上にインストールされていても良い。ＲＭＡ１０４は、ソフトウェア・コンポーネントを継続的に実行していても良い。ＲＭＡ１０４を、ウィンドウズ（登録商標）ＮＴサービスとして、またはユニックス・デーモンとして、実現しても良い。

図５に、図４のＲＭＡ１０４の使用方法を示す。ブロック５００では、初期化時に、ＲＭＡカーネル４１８は、カーネル４１８が管理命令を受信することができる１つまたは複数の通信経路のイネーブルを試みる。これらの経路はそれぞれ、帯域内ファイバ・チャネル共通トランスポート（ＦＣ−ＣＴ）、帯域外ＩＰベースのＦＣ−ＣＴまたはＩＰベースのＳＮＭＰなどの単一の管理プロトコルに対する管理命令を、非請求に受信することをサポートする。ＲＭＡ１０４は、遠隔命令を受信するための任意の数の経路をサポートするために、ＲＭＡ１０４によって、（ａ）複数管理プロトコルを同時に取り扱うこと、または（ｂ）複数供給源からの単一の管理プロトコルを同時に取り扱うことが、可能になる。

遠隔命令モジュール
ＲＭＡ１０４は、管理命令を複数の経路から、動的にロード可能な遠隔命令モジュール（ＲＣＭ）４１０Ａ〜４１０Ｄを通して、受信しても良い。各遠隔命令モジュール４１０は、単一のプロトコルの非請求の遠隔管理命令を、単一の経路から受領しても良い。「経路」は、デバイス・ドライバ４００に対するインターフェース、またはファイバ・チャネル、イーサネット（登録商標）、もしくは何らかの他のトポロジを送信方法として用いるネットワーク・インターフェース・カードであっても良い。「経路」は、他のソフトウェア・コンポーネント、たとえば局所的なアプリケーションに対するインターフェースであっても良い。登録済みのＲＣＭ４１０はそれぞれ、遠隔管理命令を受信するために適切なハードウェアおよび／またはソフトウェアとインターフェースするように、動作可能である。

たとえばあるＲＣＭ４１０Ａが、帯域内ファイバ・チャネル共通トランスポート（ＦＣ−ＣＴ）管理命令を、経路４０２を介して受信しても良い。別個のＲＣＭ４１０Ｂが、帯域外インターネット・プロトコル（ＩＰ）ＦＣ−ＣＴ管理命令を受信しても良い。ＲＭＡアーキテクチャ１０４を非ファイバ・チャネル製品にまで拡張するために、追加のＲＣＭが、異なる管理プロトコルにサポートしおよび／または異なる経路上の命令にアクセスしても良い。

ブロック５０２では、ＲＣＭ４１０が、遠隔管理命令を受信して、命令をＲＭＡカーネル４１８に送る。ＲＭＡ１０４は、複数の管理プロトコルを、複数の動的にロードされるプロトコル管理モジュール（ＰＭＭ）４２０Ａ〜４２０Ｃを用いることによって、サポートする。

ブロック５０４では、ＲＭＡカーネル４１８が、命令をＰＭＭ４２０に送る。概念的には、ＲＭＡカーネル４１８は、命令ディスパッチャであっても良い。

プロトコル管理者
１つまたは複数のＰＭＭ４２０Ａ〜４２０Ｃをロードして、１つまたは複数の所望する管理プロトコルをサポートしても良い。各プロトコル管理者４２０は、単一の遠隔管理プロトコルに対して命令を処理する動的にロード可能なモジュールであっても良い。

各プロトコル管理者４２０によって、プロトコル管理者の特定のプロトコルの遠隔命令設定（パラメータ取り出しなどの遠隔命令を有する）に対する完全なサポートが得られても良い。あるいは、各プロトコル管理者１２０によって、１つまたは複数の管理サービス
４３０へのルーティング・サービスが得られても良い。管理サービス４３０は、プロトコルの管理命令セットのサブセットをサポートするものである。

またプロトコル管理者１２０によって、命令を管理サービス１３０へルーティングする前に、特定のプロトコルのすべての命令に適用される汎用サービス層が得られても良い。このようなサービスには、認証またはデータ圧縮が含まれていても良い。

ＦＣ−ＣＴプロトコル管理者４２０Ａまたは管理サービス４４４の１つが、認証を担い、入ってくる命令の有効性をＣＴヘッダの拡張プリアンブルの内容に基づいて決定し、および無効な命令を廃棄しても良い。ＣＴ命令がホスト・ノード１０３上に形成されると、認証データが、命令を指定するＣＴ＿ＩＵの拡張プリアンブル内に配置される。この命令を受信すると、ＦＣ−ＣＴプロトコル管理者４２０Ａまたは遠隔ＣＴサーバ４３０は、拡張プリアンブルの内容を調べて、認証データの有効性を決定する認証データが無効であると考えられる場合には、命令は無効であると考えられる。認証を、ＣＴキー・サーバ４３０Ｃまたは他のセキュリティ・コンポーネントを用いることによって、拡張しても良い。

ブロック５０６では、各ＰＭＭ４２０は、特定のプロトコルの非請求の管理命令を取得すること、および命令を適切な管理サービス４３０へディスパッチすることを、担っている。比較的単純な管理プロトコルに対するＰＭＭ４２０が、命令自体を実行しても良い。より複雑な管理プロトコルに対するＰＭＭ４２０が、第２層のディスパッチャとして機能する可能性があっても良い。第２層のディスパッチャは、命令を、その下にあるプロトコルについての知識に基づいて解釈して、複数の管理サービス・モジュール（ＭＳＭ）４３０Ａ〜４３０Ｄの１つを呼ぶ。

たとえばＦＣ−ＣＴプロトコルＰＭＭ４２０Ａが、ＦＣ−ＣＴＦＣＭＳＭ４３０Ａ（エムレックス株式会社（コスタ・メサ、カリフォルニア州）製）を呼んでも良い．またＦＣ−ＣＴプロトコルＰＭＭ４２０Ａは、ディレクトリ・サーバ４３０Ｂ、キー・サーバ４３０Ｃ、または何らかの他のＣＴサーバ４３０Ｄを呼んでも良い。

管理サービス
ブロック５０８では、各ＭＳＭ４３０が、管理サービスのサブセットをその特定のプロトコルに対して与える。たとえば、ＦＣ−ＣＴプロトコル管理モジュール４２０Ａは、ＣＴ命令を、複数のＣＴサービス４３０Ａ〜４３０Ｄの１つに対して、ＣＴ命令（エムレックス特有またはＦＣ−ＧＳ標準に従って）内のＧＳ＿タイプおよびＧＳ＿サブタイプ・フィールド（エムレックス特有または標準）にディスパッチする。複数の管理サービス・モジュール４３０が望ましい場合もあるが、一実施形態においては、少なくとも単一のＦＣＭＳＭ４３０Ａが、エムレックス特有の遠隔管理ＣＴ命令をサービスする。一実施形態においては、管理サービス４４４が、ＦＣ−ＧＳ標準のＧＳ＿タイプおよびベンダ・ユニークなＧＳ＿サブタイプによって、実現される。この実施における特定の命令が、ベンダー・ユニークである。他の実施形態においては、標準のＦＣ＿ＧＳサービスを、仕様内の命令セットを用いて実施しても良い（たとえば後述するようにキー・サーバ４３０Ｃまたはディレクトリ・サーバ４３０Ｂ）。他の実施形態では、ベンダー・ユニーク・サービスを、さらなるベンダー・ユニークＧＳ＿サブタイプ値を用いて実施しても良い。

またディレクトリ・サーバＭＳＭ４３０Ｂを、サポート・ファブリック・スイッチがない場合の発見をサポートするために実施しても良い。さらなるプロトコル管理モジュール４２０（およびおそらくはさらなる管理サービス・モジュール４３０）によって、ＲＭＡアーキテクチャ１０４を、非ファイバ・チャネル製品まで拡張することができる。

ＲＭＡカーネル
ＲＭＡカーネル４１８は、非請求の管理命令を遠隔命令モジュール４１０Ａ〜４１０Ｄから受信した後、これらの命令を適切なプロトコル管理者４２０にディスパッチしても良い。ＲＭＡカーネル４１８は、遠隔命令を受信する特定の仕方を知らなくても良い。特定のプロトコルの実施詳細は、ＲＭＡカーネル４１８と関連性がなくても良い。

その代わりに、ＲＭＡカーネル４１８によって、１つまたは複数の遠隔命令モジュール４１０Ａ〜４１０Ｄがそれらの、入ってくる遠隔命令をルーティングする能力を登録するための方法が与えられても良い。またＲＭＡカーネル４１８によって、１つまたは複数のプロトコル管理者４２０Ａ〜４２０Ｃがそれらの、遠隔命令を受領する能力を登録するための方法が与えられても良い。ＲＭＡカーネル４１８には、遠隔命令を少なくとも１つの動作中の遠隔命令モジュール４１０から受信する少なくとも１つの動作中の管理者４２０がなければならない。

各プロトコル管理者４２０は、コールバック・ルーチンをＲＭＡカーネル４１８に与えることによって、ＲＭＡカーネル４１８に登録しても良い。適切なプロトコルの遠隔命令が、ドライバ４００によって受信されて、ＲＭＡカーネル４１８に送られたときに、コールバック・ルーチンは、ＲＭＡカーネル４１８によって呼び出される。カーネル４１８によって、以下のようなルーチンまたは機能が得られても良い。
ＲＭＡ登録プロトコル管理者（ボイド＊（コールバック＿機能）（パラメータ−リスト））
「ルーチン」は一般的に、命名されたコード・ボディとして定義しても良い。「ルーチン」および「機能」は、本明細書で用いる場合、同義語であっても良い。コールバック・ルーチンおよび機能は一般的に、ソフトウェア技術の当業者によって理解され得る。コールバック・ルーチンのコンセプトは、以下の通りである。すなわち、あるコード・ボディ（たとえば、クライアントＧＵＩアプリケーション３０２）は、その命名された機能の１つ（「コールバック・ルーチン」）が、ある将来の事象（デバイス・エラーのような）の発生時に、他のコード・ボディ（たとえば、ＲＭＡカーネル４１８）によって呼び出されることを、リクエストすることができる、ということである。この例では、クライアントＧＵＩアプリケーション３０２は、デバイス・エラーを検出する能力自体は持たないが、エラーの視覚的なインディケータを表示する必要がある。ＲＭＡカーネル４１８は、このようなエラーを検出することができる。したがって、外部のコード・ボディ（クライアントＧＵＩアプリケーション３０２）は、コールバック・ルーチンをＲＭＡカーネル４１８に「登録する」。すなわちクライアント・アプリケーション１０２は、パス・コールバック・ルーチンのアドレスをＲＭＡカーネル４１８へ送る。ＲＭＡカーネル４１８がデバイス・エラーを検出すると、ＲＭＡカーネル４１８はアドレスを用いてコールバック・ルーチンを呼び出す、すなわちクライアント・アプリケーション１０２へ「コール・バック」する。コールバック・ルーチン・コンセプトをこのＲＭＡカーネル４１８の領域で用いることで、プロトコル管理者４２０は、カーネル４１８が命令を受信すると呼び出されるコールバック・ルーチンを登録することができる。

コールバック・ルーチンに対するパラメータによって、入ってくる遠隔命令に対するポインタが与えられても良い（ポインタは、入ってくる遠隔命令を含むメモリ場所のアドレスである）。

各遠隔命令モジュール４１０は、ＲＭＡカーネル４１８に同様の仕方で登録しても良いが、コールバックの役割を反対にしても良い。ＲＭＡカーネル４１８によって、それぞれの登録済み遠隔命令モジュール４１０に対してコールバック・ルーチンが与えられる。ＲＣＭ４１０は、コールバック・ルーチンを、ＲＣＭ４１０が遠隔命令をその経路を介して受信する度に、呼び出しても良い。ＲＭＡカーネル４１８によって、以下のような機能が得られても良い。

ＲＭＡ＿登録遠隔命令モジュール（（ボイド＊）ＲＭＡ＿ＲＣＭコールバック機能（））
ＲＣＭ４１０が遠隔管理命令をその経路を介して受信すると、ＲＣＭ４１０はＲＭＡ＿ＲＣＭコールバック機能を呼んで、入ってくる遠隔管理命令にポインタを送る（ポインタ入ってくる遠隔管理命令を含むメモリ場所のアドレスである）。コールバック・ルーチンは命令を送って、ＲＭＡカーネル４１８のルーチン４１２をディスパッチする。

ディスパッチ・ルーチン４１２は、命令を、登録済みプロトコル管理者４２０と関連付けようと試みる。関連付けられたプロトコル管理者４２０がＲＭＡカーネル４１８に登録されると、ディスパッチ・ルーチン４１２は命令をプロトコル管理者４２０へ、プロトコル管理者の登録済みコールバック・ルーチンを介して送る。

ディスパッチ・ルーチン４１２が、遠隔命令を登録済みプロトコルと関連付けることができない場合には、遠隔命令は廃棄される。

各プロトコル管理者４２０を、ＲＭＡカーネル４１８に、ＲＭＡ＿登録プロトコル管理者ルーチンを介して登録しても良い。また各プロトコル管理者４２０によって、コールバック・ルーチンが、このＲＭＡ＿登録プロトコル管理者ルーチンに与えられても良い。

ＧＵＩ例
図６は、遠隔管理者１０３においてクライアント１０２によって与えられ得るアプリケーション・ウィンドウ６００の一実施形態のスクリーン場面である（「ＨＢＡｎｙｗｈｅｒｅユーティリティ」）。ウィンドウ６００に示されているのは、ファイル・メニュー６０４、ビュー・メニュー６０６、アダプタ・メニュー６０８、ヘルプ・メニュー６１０、再発見ボタン６１２、リセット・ボタン６１４、ホスト・ソート・ボタン６１４、ファブリック・ソート・ボタン６１６、局所的ＨＢＡのみボタン６１８、およびヘルプ・アイコン６２０である。

ユーザが再発見ボタン６１２をクリックすると、クライアント１０２が発見プロセスを開始する。ユーザが局所的ＨＢＡのみボタン６１８をクリックすると、クライアント１０２は、発見を局所的なホストＣＰＵのみに限定する。

ユーザがリセットするボタン６１４をクリックすると、クライアント１０２は、選択されたアダプタ１１２をリセットする。

ユーザがホスト・ソート・ボタン６１４をクリックすると、クライアント１０２は、ノード・リスト６５０内の要素をホスト名によってソートして、「発見された要素」サブ・ウィンドウ６０２を表示する。たとえば、図６内のサブ・ウィンドウ６０２には、４つのホスト・サーバおよび６つのアダプタがリストされている。ウィンドウ６００の左側には、４つのホスト・アイコン６２０Ａ〜６２０Ｄおよび６つのアダプタ６２２Ａ〜６２２Ｆが示されている。この例では、図６内の第１のホスト・サーバ６２０Ａおよび第１の２つのアダプタ６２２Ａ〜６２２Ｂは局所的であり、一方で、残りのサーバ６２０Ｂ〜６２０Ｄおよびアダプタ６２２Ｃ〜６２２は遠隔である。

図７は、遠隔管理者１０３においてクライアント１０２によって与えられ得る他のアプリケーション・ウィンドウ７００の一実施形態のスクリーン場面である。図６内のウィンドウ６００から、ユーザがファブリック・ソート・ボタン６１６をクリックすると、クライアント１０２は、ノード・リスト７５０内の要素をファブリック接続部によってソートして、「発見された要素」サブ・ウィンドウ７０２を表示する。図７の例では、サブ・ウ
ィンドウ７０２は、１つのファブリックおよび６つのアダプタをリストしている。ウィンドウ７００の左側には、６つのアダプタ７２２Ａ〜７２２Ｆが示されている。

図８は、遠隔管理者１０３においてクライアント１０２によって与えられ得る他のアプリケーション・ウィンドウ８００の一実施形態のスクリーン場面である。図６内のウィンドウ６００から、ユーザが第１のサーバ・アイコン６２０Ａをクリックすると、クライアント１０２は、「ホスト属性」サブ・ウィンドウ８０２を表示する。ホスト属性サブ・ウィンドウ８０２は、たとえば、ホスト・サーバの名前およびファームウェアおよびドライバの場所を表示する。ホスト属性サブ・ウィンドウ８０２を、他のホスト・サーバ・パラメータおよび状態を表示するように変更しても良い。

図９は、遠隔管理者１０３においてクライアント１０２によって与えられ得る他のアプリケーション・ウィンドウ９００の一実施形態のスクリーン場面である。図６内のウィンドウ６００から、ユーザが第１のアダプタ・アイコン６２２Ａをクリックすると、クライアント１０２は、「一般的な」情報サブ・ウィンドウ９０２を第１のアダプタ６２２Ａに対して表示する。サブ・ウィンドウ９０２は、以下のようなアダプタ情報をリストしても良い。すなわち、たとえば、モデル・タイプ９１２、アダプタ説明９１４、ワールド・ワイド・ノード名（ＷＷＮＮまたはノードＷＷＮ）９１６、ドライバ・バージョン９１８、ファームウェア・バージョン９２０、ドライバ名９２２、およびリンク・ステータス９２４などである。「一般的な」情報サブ・ウィンドウ９０２を、他のアダプタ・パラメータおよび状態を表示するように変更しても良い。

図１０は、遠隔管理者１０３においてクライアント１０２によって与えられ得る他のアプリケーション・ウィンドウ１０００の一実施形態のスクリーン場面である。図９内のウィンドウ９００から、ユーザが「詳細」タブ９０４をクリックすると、クライアント１０２は、「詳細」情報サブ・ウィンドウ１００２を第１のアダプタ６２２Ａに対して表示する。「詳細」情報サブ・ウィンドウ１００２は、以下のような詳細を表示しても良い。たとえば、ノードＷＷＮ１００４、ノード記号名１００６、説明１００８、ドライバ名１０１０、ドライバ・バージョン１０１２、ハードウェア・バージョン１０１４、オプションＲＯＭバージョン１０１６、シリアル番号１０１８、ポート番号１０２０、デバイスＩＤ１０２２、ＩＥＥＥアドレス１０２４、および起動バイオス・イネーブルド／ディセイブルド１０２６などである。「詳細」情報サブ・ウィンドウ１００２を、他のアダプタ詳細を表示するように変更しても良い。

図１１は、遠隔管理者１０３においてクライアント１０２によって与えられ得る他のアプリケーション・ウィンドウ１１００の一実施形態のスクリーン場面である。図９内のウィンドウ９００から、ユーザが「ポート属性」タブ９０６をクリックすると、クライアント１０２は、「ポート属性」情報サブ・ウィンドウ１１０２を第１のアダプタ６２２Ａに対して表示する。「ポート属性」情報サブ・ウィンドウ１１０２は、以下のようなポート属性を表示しても良い。たとえば、ノードＷＷＮ１１０４、ポートＷＷＮ１１０６、ポート記号名１１０８、ポートＦＣＩＤ１１１０、ポート・タイプ１１１２、ポート状態１１１４、サポートされたサービス・クラス１１１６、サポートされたＦＣタイプ１１１８、サポートされた速度１１２０、現在の速度１１２２、最大のフレーム・サイズ１１２４、オペレーティング・システム・デバイス名１１２６、発見されたポート１１２８、およびファブリック名１１３０などである。「ポート属性」情報サブ・ウィンドウ１１０２を、他のポート属性を表示するように変更しても良い。

図１２は、遠隔管理者１０３においてクライアント１０２によって与えられ得る他のアプリケーション・ウィンドウ１２００の一実施形態のスクリーン場面である。図９内のウィンドウ９００から、ユーザが「ポート統計」タブ９０８をクリックすると、クライアン
ト１０２は「ポート統計」情報サブ・ウィンドウ１２０２を第１のアダプタ６２２Ａに対して表示する。「ポート統計」情報サブ・ウィンドウ１２０２は、以下のような統計を表示しても良い。たとえば、送信フレーム１２０４、送信ワード１２０６、送信ＫＢカウント１２０８、送信シーケンス１２１０、ＬＩＰカウント１２１２、エラー・フレーム１２１４、リンク故障１２１６、信号損失１２１８、無効な送信ワード１２２０、交換カウント発信者１２２２、受信フレーム１２２４、受信ワード１２２６、受信ＫＢカウント１２２８、受信シーケンス１２３０、ＮＯＳカウント１２３２、ダンプされたフレーム１２３４、同期損失１２３６、プリミティブ・シーケンス・プロトコル・エラー１２３８、無効なＣＲＣ１２４０、交換カウント応答者１２４２などである。ポートにおけるデータ・スループット・カウンタおよびエラー・カウンタによって、この情報の一部が与えられても良い。「ポート統計」情報サブ・ウィンドウ１２０２を、他のポート統計を表示するように変更しても良い。

図１３は、遠隔管理者１０３においてクライアント１０２によって与えられ得る他のアプリケーション・ウィンドウ１３００の一実施形態のスクリーン場面である。図９内のウィンドウ９００から、ユーザが「ファームウェア」タブ９１０をクリックすると、クライアント１０２は、「ファームウェア」情報サブ・ウィンドウ１３０２を第１のアダプタ６２２Ａに対して表示する。「ファームウェア」情報サブ・ウィンドウ１３０２は、ファームウェア・バージョン１３０４、ファームウェア名１３０６、ＳＬＩ−１ファームウェア名１３０８、およびＳＬＩ−２ファームウェア名１３１０を表示しても良い。「ファームウェア」情報サブ・ウィンドウ１３０２を、他のファームウェア情報を表示するように変更しても良い。

ファームウェア・ダウンロード
図１３および１４に、ファームウェア・ダウンロード・プロセスを示す。ユーザが「ブラウズ」ボタン１３１２をクリックすると、クライアント１０２は、「ファームウェア・ファイル選択」ウィンドウ１３１４を表示する。ユーザは、「ファームウェア・ファイル選択」ウィンドウ１３１４のファイル選択フィールド１３１６またはファイル・リスト１３１８から、ファイルを選択しても良い。ユーザは、オープン・ボタン１３２０およびダウンロード・ボタン１３２２をクリックして、選択されたファームウェア・ファイルをアダプタ６２２Ａへダウンロードしても良い。

図１４に、ファームウェア（図１３において選択された）のダウンロードが進行している様子を示す。

一実施形態においては、遠隔ＨＢＡ１１２は、意図されたファームウェア画像ファイルがそのＨＢＡ１１２上に存在するまで、フラッシュ・メモリの消去を始めない。

望ましい機能的な特徴の１つは、クライアント１０２および／またはエージェント１０４Ａ〜１０４Ｄが、システム・アドミニストレータが遠隔管理者１０３において遠隔に管理することができるファームウェア画像ファイルのリポジトリを維持しても良いことである。たとえば、特定のファームウェア画像ファイルが遠隔ノードのリポジトリ内にすでに存在している場合には、クライアント１０２は、ファームウェアを遠隔にダウンロードすることが、ファームウェアをリンク１００を介して再送信することなく、行なうことができる。

ＦＣ−ＲＭＡＰＩ情報定義
属性
クライアント１０２およびエージェント１０４は、ＳＡＮ５０のハードウェアの特定の部分、たとえばサーバ１１０、ＨＢＡ１１２、またはポート、に付随する情報の「属性」
を用いる。属性の例としては、バージョンＩＤ、ＷＷＮ、ポート状態、無効なＣＲＣカウント、およびＳＣＳＩバス番号が挙げられる。各属性エントリには、属性タイプ（たとえば、２バイト；サーバ、ＨＢＡまたはポート）、属性長さ（たとえば、２バイト；属性エントリ全体の全長をバイトで同定する）、および属性データ値（可変長；一構成において４〜２５６バイト）が含まれていても良い。属性値に対してＦＣ−ＭＩにおいて指定されるように、フィル・バイトを付加しても良い。

属性内のデータを、二進数またはＡＳＣＩＩ文字列として表しても良い。データがＡＳＣＩＩ文字列の場合には、データは、ヌル・ターミネートされていなければならない。表現（バイナリまたはＡＳＣＩＩ）は、属性タイプ・コードによって示しても良い。

属性ブロック
「属性ブロック」の形成は、１つまたは複数の属性を連結すること、およびその前にカウント・フィールドによって属性ブロック内の属性の数を指定することによって、行なっても良い。ＦＣ−ＭＩ仕様（付録Ｂとして添付）において規定されるように、属性ブロックを、標準の属性ブロック相互接続用ファイバ・チャネル方法論（ＦＣ−ＭＩ）とある程度同じ仕方で構築しても良い。しかし、標準のＦＣ−ＭＩ属性ブロックと多少の違いがあっても良い。たとえば種々のファームウェア名が、標準のＦＤ−ＭＩ属性ブロックと異なる属性ブロック内にあっても良い。

それぞれの属性ブロックは、固定サイズの存在であっても良いし、可変サイズの存在であっても良い。

属性ブロックのタイプには、サーバ属性ブロック・タイプ、ＨＢＡ属性ブロック・タイプ、ポート属性ブロック・タイプ、ポート統計ブロック、ポート・ファイバ・チャネル・プロトコル（ＦＣＰ）マッピング／結合属性ブロック、およびＦＣ−３管理属性ブロックが含まれていても良い。

ブロック内の各属性エントリによって、ブロックに付随する特定の属性が指定される。属性ブロックには、それらの適用可能な属性の何れかまたは全てが、任意の順序で含まれていても良い。

属性ブロックを取り出すために、クライアント１０２におけるアプリケーション呼び出しが行なわれたときには、呼び出し元は最初に、リクエストに対応するための十分なメモリをクライアント１０２において割り当てなければならない。割り当てられたメモリ量が不十分である場合には、エラー・コードが、呼び出しに対して要求される実際のサイズとともに、戻される。アプリケーションがこの状況に遭遇したときには、当初のメモリを開放し、正確なサイズを用いて新しいブロックを割り当て、および呼び出しを再発行しなければならない。最大のブロック・サイズは、次のようにして計算しても良い。

属性カウント・エントリのサイズ＝４
属性の最大サイズ＝１＋４（タイプ・エントリのサイズ＋長さエントリのサイズ＝４）
属性の最大サイズ＝２＋４（タイプ・エントリのサイズ＋長さエントリのサイズ＝４）
属性の最大サイズ＝ｎ＋４（タイプ・エントリのサイズ＋長さエントリのサイズ＝４）。ここで、ｎは、属性ブロック内のエントリの数。

より簡潔な形では、（４＋すべての属性サイズの合計＋４＊属性の数）
「属性表」は、ハードウェアの特定の部分に対するすべての属性を含む構造であり、それぞれの属性は可変長フィールドとして表わされる。属性は、下位レベルのソフトウェア・モジュールの一部においては表形式で表しても良いが、アプリケーション・レベル・ソ
フトウェアに対してはブロック形式で表しても良い。

属性リストの形成は、１つまたは複数の属性ブロックを連結すること、およびその前にカウントによってリスト内のブロックの数を指定することによって、行なっても良い。

図１６Ａ〜１６Ｂに、サーバ属性およびそれらのフォーマットの例を示す。

図１７Ａおよび１７Ｂに、ＨＢＡ属性およびそれらのフォーマットの例を示す。「ファームウェア・バージョン」は、動作中ファームウェア・バージョンと同一であっても良い。エムレックスによって作られるＨＢＡに対して報告されるポートの数は、１であっても良い。エムレックス・デュアル・チャネルＨＢＡは、ＦＣ−ＲＭＡＰＩ３２５Ｂに対しては、それぞれ単一のポートを所有する２つの別個のＨＢＡ１１２として見えても良い。「動作中ファームウェア名」は、エムレックスによって作られるＨＢＡ上の動作ファームウェアである。「ＳＬＩ−１ファームウェア名」は、エムレックスＨＢＡ上のＳＬＩ−１オーバーレイ・ソフトウェアである。「ＳＬＩ−２ファームウェア名」は、エムレックスＨＢＡ上のＳＬＩ−１オーバーレイ・ソフトウェアである。「ＩＥＥＥアドレス」は、ＨＢＡ１１２のアドレスである。「起動バイオス状態」は、起動バイオス・ソフトウェアの（現在ＨＢＡ１１２上にあるならば）、現在の状態（イネーブルド／ディセイブルド）である。「プラットフォーム名」（ホスト名とも言われる）は、ＧＳ−４ＨＢＡ構成サーバを指す。

図１８に、ポート属性およびそれらのフォーマットの例を示す。

図１９に、ポート統計およびそれらのフォーマットの例を示す。

図２０に、ポートＦＣＰ属性の例を示す。

図２１に、ＦＣ−３管理属性の例を示す。

図２３Ａ〜２３Ｅに、ソフトウェア・リソース属性およびそのフィールドの一実施形態を示す。

付録Ａ：ＦＣ−ＲＭＡＰＩ
付録Ａのページ１〜５には、ＦＣ−ＲＭＡＰＩ機能が用いても良いデータ・タイプおよび構造定義がリストされている。

付録Ａのページ６〜２５には、ＲＭＡＰＩ機能／命令、それらの引数、およびそれらの戻り値の例が与えられている。

付録Ｂ：ＦＣ−ＭＩ
付録Ｂは、相互接続用ファイバ・チャネル方法論（ＦＣ−ＭＩ）属性仕様改訂１．８である。

ＣＴ＿ＩＵ
本明細書で説明する転送長さは、バイトであっても良い。すべてのＣＴリクエスト、受領、および拒絶ＣＴ＿ＩＵに対する全体の転送長さは、４バイトの倍数であっても良い。ＦＣ−ＧＳ仕様で規定されるように、基本プリアンブルおよび追加プリアンブルの長さは、４バイトの倍数である。

本明細書で規定するように、すべてのＣＴリクエストの追加情報フィールドの長さは、
４バイトの複数であっても良い。追加情報フィールドを構成するすべての属性ブロック、統計ブロック、および他の存在は、長さが４バイトの倍数であると規定されていても良い。それぞれのＡＳＣＩＩパラメータに対して、文字列はヌル・ターミネートされていても良い。また必要に応じて、「４バイト倍数」の要求を満足するように、追加のパディング・ヌルを加えても良い。

基本プリアンブル
基本プリアンブルでは、説明していないすべてのフィールドおよびビットを未使用にして、０に設定しても良い。

命令（リクエストＣＴ＿ＩＵ）
改訂フィールド：値０ｘ０２を用いて、ＦＣ−ＧＳ−３改訂７．０１との適合を示しても良い。

ＩＮ＿ＩＤ：値０を用いても良い。

ＧＳ＿タイプ ：値０ｘ０Ａを用いて、ベンダ・ユニークな（たとえば、エムレックス）管理サービスを示しても良い。

ＧＳ＿サブタイプ：値０ｘ１０を用いて、ＨＢＡ管理サービスを示しても良い。

オプション・フィールド：
ビット７：交換マッピング：値０を用いて、同期モードを示しても良い。

ビット６：部分的な応答：値０を用いて、「未指定」を示しても良い。

ビット５：拡張プリアンブルの存在：値１を用いて、拡張ＣＴ＿ＩＵプリアンブルが存在することを示しても良い。

命令／応答コード：ベンダ・ユニークなＦＣ−ＣＴ命令コードであっても良い（図２４に示す）。図２４に、ベンダ・ユニークなＦＣ−ＣＴ命令コードの例を示す。

最大サイズ：一実施形態においては、１６−ビット値によって、受領ＣＴ＿ＩＵの最大サイズ（割り当てられた応答バッファのサイズ）を記述する。最大サイズは、基本プリアンブル、拡張プリアンブル、および追加情報を含むＣＴ＿ＩＵの全体のサイズであっても良い。最大サイズは、４バイトの倍数であっても良い。ＩＯＣＴＬシステムは、６４ｋｂの最大転送長さを課しても良い。

応答（受領ＣＴ＿ＩＵ）
すべてのフィールドは、ＦＣ−ＧＳ−３改訂７．０１で説明されている通りであっても良い加えて、ベンダ・ユニークなフィールドが存在しても良い。

拡張プリアンブル
認証されたＣＴを用いて、あるレベルのセキュリティを実現しても良い。このことは、拡張ＣＴ＿ＩＵプリアンブルを用いることを示しても良い。

リクエストＣＴ＿ＩＵ
ＣＴ命令（図１５Ａおよび２４）を、リクエストＣＴ＿ＩＵ追加情報フィールドにおいて伝えても良い。ＣＴ命令を説明する目的で、このフィールドをさらに２つの部分に分割しても良い。すなわち、命令ブロックおよび命令データ・フィールドである。命令ブロッ
クは、以下の原理に従ってデザインしても良い。

命令ブロックは、長さが１〜８ワードであっても良い。

命令ブロック要素を、ロングワード境界上でアライメントしても良い。例外は、８ワード境界でアライメントされたＨＢＡ識別子およびポート識別子であっても良い。

すべての命令ブロックが、ベンダ＿ＯＵＩ（ＩＥＥＥ組織的にユニークな識別子）を、第１のワード（ワード０）内に含んでいても良い。エムレックスに割り当てられたＯＵＩは、０ｘ００００００Ｃ９である。

命令によっては、パラメータを用いていなくても良い。これらの命令では、１ワードの公称命令ブロック形態を用いても良い。これは、ベンダＯＵＩのみを含んでいる。

命令によっては、命令制御ワード（ＣＣＷ）と呼ばれる制御ワードを用いても良い。命令制御ワードは、存在するならば、ワード１である。

命令によっては、命令特有パラメータと呼ばれる制御パラメータに対する追加のワードが必要であっても良い。命令特有パラメータは、存在するならば、ワード２である。

命令によっては、データの可変長ブロックを、命令データ・フィールドと呼ばれるフィールド内のサーバに送っても良い。すべての命令データ・フィールド構造は、タイプ、長さ、およびカウントに対して、自己同定しても良い。したがって命令ブロック内では、データ長さパラメータは必要ではない。

ある特定の命令において、ポート識別子の組を用いても良い。これらのパラメータはそれぞれ、長さが８バイトであっても良い。これらを、８−バイト境界にアライメントされた状態にしておくために、必要に応じて、適切な命令ブロックを、未使用のワードで埋めても良い。ポート識別子は、一部の命令ではワード２〜５で含まれ、および他の命令ではワード４〜７で含まれる。

図２５〜２７に、共通トランスポート（ＣＴ）命令ブロック・フォーマットの例を示す。

プロキシ／オブジェクト・ポート（またはＨＢＡ）識別子
クライアント１０２が、リクエストを所望のＨＢＡ１１２へ送れない場合が、しばしば存在する。このような状況では、クライアント１０２は、プロキシ・ポート（またはＨＢＡ）を、ＣＴリクエストの受取人として用いることができても良い。クライアント１０２は、呼び出し元の代わりにリクエストを受信して実行するために、プロキシ・ポート（またはＨＢＡ）のＷＷＰＮを知っていても良い。この情報を伝えるために、リクエストには２つのパラメータが含まれていても良い。すなわち「プロキシ・ポート識別子」および「オブジェクト・ポート識別子」（または「プロキシＨＢＡ識別子」および「オブジェクトＨＢＡ識別子」）である。

しかしリクエストによっては、たとえば「サーバ属性取得」および「サーバ属性設定」では、２つの識別子は必要ではない。これらの命令の場合には、オブジェクト・ポート識別子（またはオブジェクトＨＢＡ識別子）のみがリクエストに含まれている必要がある。

２つの識別子を含まない命令の場合には、クライアント１０２は一般的に、リクエストを所望のオブジェクト・ポート（またはオブジェクトＨＢＡ）に送って、プロキシ・ポー
ト識別子（またはプロキシＨＢＡ識別子）を０に設定する。しかしクライアント１０２が、リクエストをプロキシ・ポート（またはＨＢＡ）へ送ることを選んだ場合には、クライアント１０２は、有効なノン・ゼロ・プロキシ・ポート識別子（またはプロキシＨＢＡ識別子）を与えることになる。

リクエストＣＴ＿ＩＵでは、各ポート識別子（またはＨＢＡ識別子）は、存在する場合には、８バイトＷＷＰＮであっても良い。

クライアント／サーバＨＢＡ識別子
ファイル転送プロトコルの場合には、何らかのメカニズムを用いて個々のリクエストにタグをつけても良い。リクエストＣＴ＿ＩＵでは、それぞれのＨＢＡ識別子は、存在する場合には、８バイトＷＷＰＮであっても良い。

受領ＣＴ＿ＩＵ
サーバ１１０がＣＴリクエストの完了を成功させることができる場合には、サーバ１１０は、応答して、受領ＣＴ＿ＩＵをクライアント１０２に送る。応答データは、受領ＣＴ＿ＩＵ追加情報フィールドにおいて伝えても良い。ＣＴ受領を説明する目的で、このフィールドをさらに２つの部分に分割しても良い。すなわち、応答ブロックおよび応答データ・フィールドである。ＣＴ受領ブロックは、以下の原理に従ってデザインしても良い。

応答ブロックは、長さが１〜８ワードであっても良い。

ロングワード境界よりも良好にアライメントされる要素がなくても良い。

応答ブロックは、それらの対応する命令ブロックを反映していなくても良い。

すべての応答ブロックにおいて、ベンダＯＵＩが第１のワード（ワード０）に含まれていても良い。

公称応答ブロックが、ベンダ＿ＯＵＩのみから構成されていても良い。

拒絶ＣＴ＿ＩＵ
標準拒絶コード
サーバ１１０が、要求された動作を行なうことができない場合には、サーバ１１０は、拒絶ＣＴ＿ＩＵをクライアント１０２へ送る。すべての標準ＦＣ−ＧＳ−３理由コードを、サポートしても良い。これらの理由コードのほとんどを、プロトコルまたは物理的なエラーに対して用いる。たとえば論理エラー、無効なＣＴ＿ＩＵサイズ、論理ビジー、およびプロトコル・エラーである。他の理由コードには、以下のものが含まれる。

理由コードのコード記述
０ｘ０１無効命令コード
命令コードが有効なベンダ・ユニークな管理命令でない場合には、戻される。

０ｘ０９命令リクエストを行なうことができない
サポートされた命令コードを処理するエラーがある場合には、戻す。説明フィールドは、以下の通りである。

理由コード説明のコード記述
０ｘ００追加説明なし
０ｘ１０無効なＨＢＡ識別子
０ｘ１１ＨＢＡ属性ブロックには、同じタイプの複数の属性が含まれる
０ｘ１２無効なＨＢＡ属性ブロック長さ
０ｘ１３無効なＨＢＡ属性
０ｘ２０無効なポート識別子
０ｘ２１ポート属性ブロックには同じタイプの複数属性が含まれる
０ｘ２２無効なポート属性ブロック長さ
０ｘ２３無効なポート属性
０ｘ３０無効なホスト識別子
０ｘ３１サーバ属性ブロックには、同じタイプの複数属性が含まれる
０ｘ３２無効なサーバ属性ブロック長さ
０ｘ３３無効なサーバ属性
０ｘ０Ｂサポートされていない命令
ベンダ・ユニークな拒絶コード
サーバ１１０が、本明細書で説明したベンダ・ユニークな拒絶コードの１つを生成する場合には、サーバ１１０は、理由コードを０ｘＦＦに設定し（ベンダ・ユニークなエラーを意味する）、理由コード説明を０に設定し（追加説明がないことを意味する）、およびベンダー・ユニーク・フィールドを適切な値に設定する。

図２８には、ＣＴベンダ・ユニークな拒絶理由コードの例がリストされている。

局所的なＨＢＡ１０３または遠隔ＨＢＡ１１０上のいずれかにおけるハードウェア・エラーのせいで、すべての遠隔ＣＴ動作が失敗する可能性はある。加えて、ある特定の命令は、他の命令特有のエラー・コードを有する。

図２９Ａ〜２９Ｂには、命令特有のエラーに対するＣＴベンダ・ユニークな理由コードの例がリストされている。

メールボックス・エラー・ステータス
ある場合には、メールボックス（ＭＢＸ）命令が、サーバ１１０上で機能しなくなり、クライアント１０２に良く知られており、ＭＢＸ応答が必要となることがある。一例は、ＲＵＮ−ＢＩＵ−ＤＩＡＧサブ・コードを有するＨＢＡ診断実行命令である。これらの場合には、拒絶理由コードはＭＢＸＥＲＲであっても良い。実際のＭＢＸ応答データは、拒絶追加情報フィールド内に配置しても良い。

他の場合には、サーバ１１０が、ＭＢＸエラーを評価することができ、またクライアント１０２に、その下にあるＭＢＸ命令とは切り離されたステータス（拒絶理由コード）を戻すことができることがある。拒絶理由コードによって、クライアント１０２に、十分な情報が与えられても良い。例としては、フラッシュ・プログラミング動作の場合に可能性のある多数のＭＢＸエラー・コードが挙げられる。たとえば、クライアント１０２は、ＭＢＸ命令がロード＿ＳＭもしくはダウンロードだったかどうか、またはＭＢＸステータス消去がフラッシュ障害もしくはプログラム・フラッシュ障害だったかどうかについて、注意しなくても良い。拒絶理由コードは、フラッシュ＿エラーである。しかし、このような場合には、実際のＭＢＸ応答データを、以下に規定されるフォーマットに従って拒絶追加情報フィールドに配置しても良い。エラーの全詳細は、クライアント１０２にとって入手可能であり、アプリケーションまたはシステム・アドミニストレータが詳細を必要とする場合に備えている。

拒絶追加情報
ある特定のベンダ・ユニークな拒絶コードでは、より多くの情報をクライアント１０２に戻すために、拒絶追加情報フィールドを必要としても良い。

図３０に、ＣＴ拒絶追加情報フィールドの一実施形態を示す。追加情報タイプのフィールドでは、拒絶追加情報のタイプが一意に同定される。

タイプ 説明
０ｘ０００１ メールボックス応答
その他 未使用
追加情報フィールド長さのフィールドでは、追加情報フィールドの全長をバイトで示す。全長は、４バイトの倍数であっても良く、タイプ、長さ、およびデータ・フィールドを含んでいる。

データ・フィールドには、追加の情報ペイロードが含まれる。データ・フィールドは、長さが少なくとも４バイトであり、長さは４の倍数であっても良い。最大長さは、２５６バイトであっても良い。必要に応じて、フィル・バイトを加えても良い。

拒絶追加情報：メールボックス応答
ＭＢＸ命令が遠隔サーバ１１０上で機能しなくなったときには、ＭＢＸ応答を、拒絶ＣＴ＿ＩＵ追加情報フィールド内に配置する（図３１に示す）。

追加情報タイプ：０ｘ０００１
追加情報フィールド長さのフィールドでは、追加情報フィールドの全長をバイトで示す。全長は、４バイトの倍数であっても良く、タイプ、長さ、およびデータ・フィールドを含んでいる。

データ・フィールドには、ＭＢＸ応答が含まれる。

ポート統計
ＦＤＭＩは、ポート統計の取り出しをアドレス指定しない。ＦＣＲＭＡＰＩ３２５Ｂには、ポート統計を取り扱うためのベンダ・ユニークな方法があっても良い。

クライアントの観点からすると、ポート統計に適用可能な操作は２つだけであっても良い。すなわち取り出しおよびリセットである。特定のＦＣ−ＣＴ命令が、統計のリセットに対して設けられている。すなわち、ポート統計リセット（ＲＰＳＴ）である。

取り出す際には、属性に良く似たポート統計を扱うのが便利である。以下の説明では、ポート統計に適用可能なデータ構造の概要を述べる。

図３２に、すべてのポート統計に対して用いても良い一般的なフォーマットの一実施形態を示す。

ポート統計エントリ・タイプのフィールドでは、それぞれの個々の統計が一意に同定される。

ポート統計エントリ長さのフィールドでは、ポート統計エントリの全長がバイトで示される。全長は、４バイトの倍数であっても良く、タイプ、長さ、および値フィールドを含んでいる。

ポート統計エントリ値のフィールドでは、統計値が指定される。統計値は、バイナリ・タイプであっても良く、および長さが４または８バイトであっても良い。

図３３に、ポート統計ブロック・エントリの一実施形態を示す。ポート統計ブロックは、固定サイズの存在であっても良いし、可変サイズの存在であっても良い。これらを、ポート属性ブロックと同様に構築しても良い。ポート統計ブロックには、以下の統計の何れかまたは全てが、任意の順序で含まれていても良い。

多くのポート統計エントリのフィールドによって、ブロックに含まれるポート統計エントリの数が指定される。値０は有効であり、この値は、ポート統計エントリがブロックに含まれていないことを示す。この場合、ブロックの長さは４バイトとする。

各ポート統計エントリによって、ブロックに付随する特定の統計が指定される。各ポート統計エントリは、図３２に指定された一般的なポート統計エントリ・フォーマットに従う。

ソフトウェア・リソース記述子（ＳＲＤ）
複数のＣＴ命令タイプによって、遠隔サーバ１１０上のソフトウェア・リソース（ファイル）を操作しても良い。たとえば、ソフトウェア＿リソース＿送信によって、ファイルをクライアント１０２からサーバ１１０へ送る。ソフトウェア＿リソース＿名前変更によって、遠隔サーバ１１０上の既存のファイル名を変える。遠隔＿リソース＿リスト＿取得によって、遠隔サーバ１１０上で利用可能なすべてのリソースの記述子を取り出す。

ＣＴ命令が異なると、動作するソフトウェア・リソースの数が異なる。３つの同じ例を用いて、ソフトウェア＿リソース＿送信は、正確に１つのファイル上で動作しても良く、ソフトウェア＿リソース＿名前変更は、正確に１つファイル上で動作しても良いが２つの記述子を必要とし、遠隔＿リソース＿リスト＿取得は、記述子を取り出すリソースの数を変えられる。これらの考慮によって示されることは、ソフトウェア・リソース記述子のデザインが、属性に対して用いたものと同様であるということである。

図３４に、ソフトウェア・リソース記述子（ＳＲＤ）の一実施形態を示す。ＳＲＤタイプのフィールドでは、ＳＲＤのタイプが同定される。ＳＲＤ長さのフィールドでは、５つのすべてのフィールドを含むＳＲＤの全長をバイトで示している。ソフトウェア・リソース属性のフィールドには、ソフトウェア・リソース属性が含まれる。ソフトウェア・リソース属性には、リソースを適格なものにするビット・マスクが含まれる。ソフトウェア・リソース・バージョンのフィールドには、ソフトウェア・リソース・バージョンが含まれる。ソフトウェア・リソース・バージョンは、ヌル・ターミネートされたＡＳＣＩＩ文字列であり、必要に応じて、２０バイトの長さまでパディングしても良い。ソフトウェア・リソース名のフィールドには、ソフトウェア・リソース名が含まれる。ソフトウェア・リソース名のフィールドは、ヌル・ターミネートされたＡＳＣＩＩ文字列であっても良く、最大サイズは２５６バイトである。

図３５に、ソフトウェア・リソース・ブロック（ＳＲＢ）の一実施形態を示す。多くのＳＲＤのフィールドによって、ＳＲＢに含まれるＳＲＤの数が指定される。値０は違法であっても良く、エラーであるとみなしても良い。最大の数は、可変であり、実施によって限定されても良い。本明細書によって課される限定はない。

ＳＲＤｎ：各ＳＲＤが、正確に１つのソフトウェア・リソースを記述しても良い。

ソフトウェア・リソース属性は、リソースのソフトウェアおよびハードウェアのタイプを同定する６４ビットのフィールドであっても良い。ソフトウェア・リソース属性は、特定のリソースを記述するために用いられるときには、リソースのソフトウェア・リソース・ブロック（ＳＲＢ）の一部である。これに関連して、ソフトウェア・リソース属性は、
複数のＣＴ命令、たとえばソフトウェア＿リソース＿送信および遠隔＿リソース＿削除において現れる。

ソフトウェア・リソース属性は、リソースの組を記述するために用いられるときには、遠隔リソース・リスト取得の場合と同様に、ＣＴ命令自体におけるパラメータとして現れる。

命令（リクエスト）および応答（受領）詳細
後述する命令および応答ブロックでは、追加情報フィールドが示され、基本プリアンブルおよび拡張プリアンブルは図示されていない。本明細書では、用語「命令」および「応答」は、リクエストＣＴ＿ＩＵ追加情報フィールド、および受領ＣＴ＿ＩＵ追加情報フィールドを意味するために用いられる。誤った応答に対しては、受領ＣＴ＿ＩＵではなくて、拒絶ＣＴ＿ＩＵを戻す。

また、すべての命令および応答ブロックには、ベンダ＿ＯＵＩ（ＩＥＥＥ組織的にユニークな識別子）が、第１のワード（ワード０）に含まれている。このセクションでは、ベンダＯＵＩを、命令および応答ブロックにおいて示す。

属性取得命令
サーバ属性取得（ＧＳＡＴ）
図３６Ａ〜３６Ｂに、サーバ属性取得命令およびサーバ属性取得応答の例を示す。サーバ属性取得命令は、サーバ１１０に、そのサーバ属性ブロック（図１６Ａ〜１６Ｂ）をクライアント１０２に戻すように指示を出す。ＧＳＡＴ命令は、ＨＢＡ特有でもポート特有でもなくても良い。そのため、ＧＳＡＴ命令はプロキシ識別子を必要としなくても良い。

ＧＳＡＴ命令は、パラメータを必要としなくても良い。命令には、公称命令ブロックが含まれる。

ＧＳＡＴ応答には、公称応答ブロックと、続いてサーバ属性ブロックとが含まれていても良い。一般的には、しかし必ずしもそうでなくても良いが、戻されるブロックには、適用可能な属性がすべて含まれる。

ＨＢＡ属性取得（ＧＨＡＴ）
図３７Ａ〜３７Ｂに、ＨＢＡ属性取得命令およびＨＢＡ属性取得応答の例を示す。ＨＢＡ属性取得命令は、サーバ１１０に、オブジェクトＨＢＡのＨＢＡ属性ブロック（図１７Ａ〜１７Ｂを参照）をクライアント１０２に戻すように指示を出す。

ＧＨＡＴ命令はＨＢＡ特有であっても良い。そのため、ＧＨＡＴ命令には、オブジェクトＨＢＡ識別子およびプロキシＨＢＡ識別子が含まれていても良い。ＧＨＡＴ命令には、２つのパラメータが含まれる。すなわち、オブジェクトＨＢＡ識別子、およびプロキシＨＢＡ識別子である。

ＧＨＡＴ応答には、公称応答ブロックと、続いてＨＢＡ属性ブロックとが含まれる。一般的には、しかし必ずしもそうでなくても良いが、戻されるブロックには、適用可能な属性がすべて含まれる。

ポート属性取得（ＧＰＡＴ）
図３８Ａ〜３８Ｂに、ポート属性取得命令およびポート属性取得応答の例を示す。

ポート属性取得命令は、オブジェクト・サーバ１１０に、オブジェクト・ポートのポー
ト属性ブロック（図１８参照）をクライアント１０２に戻すように指示を出す。

ＧＰＡＴ命令はポート特有であっても良い。そのため、ＧＰＡＴ命令には、オブジェクト・ポート識別子およびプロキシ・ポート識別子が含まれる。ＧＰＡＴ命令には、２つのパラメータが含まれる。すなわち、オブジェクト・ポート識別子、およびプロキシ・ポート識別子である。

ＧＰＡＴ応答には、公称応答ブロックと、続いてポート属性ブロックとが含まれる。一般的には、しかし必ずしもそうでなくても良いが、戻されるブロックには、適用可能な属性がすべて含まれる。

ドライバ属性取得（ＧＤＡＴ）
図３９Ａ〜３９Ｂに、ドライバ属性取得命令およびドライバ属性取得応答の例を示す。ドライバ属性取得命令は、オブジェクト・サーバ１１０に、ドライバ属性ブロック（図示せず）をクライアント１１２に戻すように指示を出す。ＧＤＡＴ命令は、ＨＢＡ特有でもポート特有でもなくても良い。そのため、ＧＤＡＴ命令はプロキシ識別子を必要としない。ＧＤＡＴ命令は、パラメータを必要としなくても良い。リクエストには、公称命令ブロックが含まれていても良い。

ＧＤＡＴ応答には、公称応答ブロックと、続いてドライバ属性ブロックとが含まれていても良い。一般的に、しかし必ずしもそうでなくても良いが、戻されるブロックには、適用可能な属性がすべて含まれている。

ポート統計取得（ＧＰＳＴ）
図４０Ａ〜４０Ｂに、ポート統計取得命令およびポート統計取得応答の例を示す。ポート統計取得命令は、オブジェクト・サーバ１１０に、オブジェクト・ポートのポート統計ブロックをクライアント１０２に戻すように指示を出す。ＧＰＳＴ命令はポート特定であっても良い。そのため、ＧＰＳＴ命令には、オブジェクト・ポート識別子およびプロキシ・ポート識別子が含まれていても良い。ＧＰＳＴ命令には２つのパラメータが含まれていても良い。すなわち、オブジェクト・ポート識別子、およびプロキシ・ポート識別子である。

ＧＰＳＴ応答には、公称応答ブロックと、続いてポート統計ブロックとが含まれていても良い。一般的に、しかし必ずしもそうでなくても良いが、戻されるブロックには、適用可能な統計のすべてが含まれる。

サーバ属性設定（ＳＳＡＴ）
図４１Ａ〜４１Ｂに、サーバ属性設定命令およびサーバ属性設定応答の例を示す。サーバ属性設定命令は、オブジェクト・サーバ１１０に、サーバ属性ブロックに含まれる属性を登録するように指示を出すＳＳＡＴ命令は、ＨＢＡ特有でもポート特有でもなくても良い。そのため、ＳＳＡＴ命令はプロキシ識別子を必要としなくても良い。

ＳＳＡＴ命令には、サーバ属性ブロックが含まれる。これは、登録すべき属性を指定するものである。１つまたは複数の属性を、属性ブロック内で指定して、単一の命令に登録しても良い。ブロック内のゼロ属性は、エラーであっても良い。

ＳＳＡＴ応答は、公称応答ブロックから構成される。

ＨＢＡ属性設定（ＳＨＡＴ）
図４２Ａ〜４２Ｂに、ＨＢＡ属性設定命令およびＨＢＡ属性設定応答の例を示す。ＨＢ
Ａ属性設定命令は、オブジェクト・サーバ１１０に、ＨＢＡ属性ブロックに含まれる属性を登録するように指示を出す。

ＳＨＡＴ命令はＨＢＡ特有であっても良い。そのため、ＳＨＡＴ命令には、オブジェクトＨＢＡ識別子およびプロキシＨＢＡ識別子が含まれる。ＳＨＡＴ命令には、ＨＢＡ属性ブロックが含まれる。これは、登録すべき属性を指定するものである。１つまたは複数の属性を、属性ブロック内で指定して、単一の命令に登録しても良い。ブロック内のゼロ属性は、エラーであっても良い。

ＳＨＡＴ応答には、公称応答ブロックが含まれる。

ポート属性設定（ＳＰＡＴ）
図４３Ａ〜４３Ｂに、ポート属性設定命令およびポート属性設定応答の例を示す。ポート属性設定命令は、オブジェクト・サーバ１１０に、ポート属性ブロックに含まれる属性を登録するように指示を出す。ＳＰＡＴ命令はポート特有であっても良い。そのため、ＳＰＡＴ命令には、オブジェクト・ポート識別子およびプロキシ・ポート識別子が含まれる。ＳＰＡＴ命令には、ポート属性ブロックが含まれる。これは、登録すべき属性を指定するものである。１つまたは複数の属性を、属性ブロック内で指定して、単一の命令に登録しても良い。ブロック内のゼロ属性は、エラーであっても良い。

ＳＰＡＴ応答には、公称応答ブロックが含まれる。

ドライバ属性設定（ＳＤＡＴ）
図４４Ａ〜４４Ｂに、ドライバ属性設定命令およびドライバ属性設定応答の例を示す。ドライバ属性設定命令は、オブジェクト・サーバ１１０に、ドライバ属性ブロックに含まれる属性を登録するように指示を出す。ＳＤＡＴ命令はＨＢＡ特有でもポート特有でもなくても良い。そのため、ＳＤＡＴ命令は、プロキシ識別子を必要としなくても良い。ＳＤＡＴ命令には、ドライバ属性ブロックが含まれる。これは、登録すべき属性を指定するものである。１つまたは複数の属性を、属性ブロック内で指定して、単一の命令に登録しても良い。ブロック内のゼロ属性は、エラーであっても良い。

ＳＤＡＴ応答には、公称応答ブロックが含まれていても良い。

ポート統計リセット（ＲＰＳＴ）
図４５Ａ〜４５Ｂに、ポート統計リセット命令およびポート統計リセット応答の例を示す。ポート統計リセット命令は、オブジェクト・サーバ１１０に、オブジェクト・ポートの統計を再初期化するように指示を出す。ＲＰＳＴ命令はポート特有であっても良い。そのため、ＲＰＳＴ命令には、オブジェクト・ポート識別子およびプロキシ・ポート識別子が含まれていても良い。ＲＰＳＴ命令には、２つのパラメータが含まれる。すなわち、オブジェクト・ポート識別子、およびプロキシ・ポート識別子である。

ＲＰＳＴ応答には、公称応答ブロックが含まれていても良い。

ファームウェア確認（ＶＦＷ）
図４６Ａ〜４６Ｂに、ファームウェア確認命令およびファームウェア確認応答の例を示す。ファームウェア確認命令は、オブジェクト・サーバ１１０に、以下のことを確認するように指示を出す。すなわち、指定されたファームウェア画像リソースが存在すること、ファームウェア画像リソースが指定されたＨＢＡに対する正しいタイプであること、およびファームウェア画像リソースが、有効な内部フォーマットを有すること、である。

ＶＦＷ命令は、ＨＢＡ特有であっても良い。そのため、ＶＦＷ命令には、オブジェクトＨＢＡ識別子およびプロキシＨＢＡ識別子が含まれる。ＶＦＷ命令には、以下のパラメータが含まれていても良い。オブジェクトＨＢＡ識別子、プロキシＨＢＡ識別子、および遠隔ファームウェア・リソースＳＲＤである。

ＶＦＷ応答には、公称応答ブロックが含まれる。誤り状態を、拒絶ＣＴ＿ＩＵによって報告する。

ファームウェア・ダウンロード（ＤＦＷ）
図４７Ａ〜４７Ｂに、ファームウェア・ダウンロード命令およびファームウェア・ダウンロード応答の例を示す。ファームウェア・ダウンロード命令は、オブジェクト・サーバ１１０に、指定されるファームウェア画像リソースを、指定されるＨＢＡ１１２内へダウンロードするように指示する。ＤＦＷ命令は、ＨＢＡ特有であっても良い。そのため、ＤＦＷ命令には、オブジェクトＨＢＡ識別子およびプロキシＨＢＡ識別子が含まれる。ＤＦＷ命令には、以下のパラメータが含まれる。命令制御ワード、オブジェクトＨＢＡ識別子、プロキシＨＢＡ識別子、および遠隔ファームウェア・リソースＳＲＤである。

ＤＦＷ応答には、公称応答ブロックが含まれる。誤り状態を、拒絶ＣＴ＿ＩＵによって報告する。

ファームウェア・ダウンロード（ＤＦＷ）命令では、ワード１、ビット（０）の記述は、（命令制御ワード）であるダウンロード後リセットであっても良い。具体的には、ダウンロードが成功した後に、ポートを通常モードでリセットして、ドライバを再初期化する。

ファームウェア・アップグレード（ＵＦＷ）
図４８Ａ〜４８Ｂに、ファームウェア・アップグレード命令およびファームウェア・アップグレード応答の例を示す。ファームウェア・アップグレード命令は、クライアント・アプリケーション１０２に対して単一の命令メカニズムを与えて、特定のサーバ１０３または１１０上のファームウェア画像リソースを、（潜在的に異なる）特定のサーバ１１０上の特定のＨＢＡ１１２内にダウンロードさせる。

２つのサーバは、必ずしも同じサーバである必要はない。ファームウェア・アップグレード命令は、クライアント・アプリケーション１０２によって、必要なファームウェア画像リソースを含むサーバ１０３または１１０に送信される。このサーバ１０３または１１０は、リソース・サーバと呼ばれる。次にリソース・サーバ１０３または１１０は、リソースを、ソフトウェア・リソース送信命令を介して、アップグレードすべきＨＢＡ１１２を含むサーバ１１０に送信する。このサーバ１１０は、オブジェクト・サーバと呼ばれる。最後に、リソース・サーバ１０３または１１０は、ファームウェア・ダウンロード命令を、オブジェクト・サーバ１１０に送信する。

リソース・サーバ１０３または１１０とオブジェクト・サーバ１１０とが同じサーバである場合には、すでに概説した追加ステップを省く。この場合、ファームウェア・アップグレード命令は、ファームウェア・ダウンロード命令のように機能する。

その下にあるＤＦＷ命令は、ＨＢＡ特有であっても良く、オブジェクトＨＢＡ識別子とプロキシＨＢＡ識別子とを用いるため、これら２つの識別子が、ＵＦＷ命令内に要求される。ＵＦＷ命令自体はＨＢＡ特有ではないため、ＵＦＷ命令はプロキシを必要としない。したがってＵＦＷ命令には、３つのＨＢＡ識別子が含まれる。すなわち、リソース・サーバＨＢＡ識別子、オブジェクト・サーバ・オブジェクトＨＢＡ識別子、およびオブジェク
ト・サーバ・プロキシＨＢＡ識別子である。

加えて、ＵＦＷ命令には、命令制御ワードとファームウェア・リソースＳＲＤとが含まれていても良い。

ＵＦＷ応答には、公称応答ブロックが含まれる。誤り状態を、拒絶ＣＴ＿ＩＵによって報告する。

ファームウェア・ダウンロード（ＤＦＷ）命令の場合、ワード１、ビット（０）は、（命令制御ワード）であるダウンロード後リセットを有していても良い。ダウンロードが成功した後に、ポートを通常モードでリセットして、ドライバを再初期化する。

ＨＢＡリセット（ＲＥＳ）
図４９Ａ〜４９Ｃに、ＨＢＡリセット命令、ＨＢＡリセット応答、およびＨＢＡリセット命令詳細の例を示す。ＨＢＡリセット命令は、オブジェクト・サーバ１１０に、示されたリセット動作を指定されるＨＢＡ１１２上で行なうように指示を出す。ＲＥＳ命令はＨＢＡ特有であっても良い。そのため、ＲＥＳ命令には、オブジェクトＨＢＡ識別子およびプロキシＨＢＡ識別子が含まれる。ＲＥＳ命令には、以下のパラメータが含まれる。命令制御ワード、オブジェクトＨＢＡ識別子、およびプロキシＨＢＡ識別子である。

ＲＥＳ応答には、公称応答ブロックが含まれる。誤り状態を、拒絶ＣＴ＿ＩＵによって報告する。

ＨＢＡ診断実行（ＲＨＤ）
図５０Ａ〜５０Ｃに、ＨＢＡ診断実行命令、ＨＢＡ診断実行応答、およびＨＢＡ診断実行命令詳細の例を示す。ＨＢＡ診断実行命令は、オブジェクト・サーバ１１０に、示された診断をオブジェクトＨＢＡ１１２上で行なうように指示を出す。ＲＨＤ命令はＨＢＡ特有であっても良い。そのため、ＲＨＤ命令には、オブジェクトＨＢＡ識別子およびプロキシＨＢＡ識別子が含まれる。ＲＨＤ命令には、以下のパラメータが含まれる。命令制御ワード、オブジェクトＨＢＡ識別子、およびプロキシＨＢＡ識別子である。

ＲＨＤ応答には、公称応答ブロックが含まれる。誤り状態を、拒絶ＣＴ＿ＩＵによって報告する。

遠隔リソース・リスト取得（ＧＲＲＬ）
図５１Ａ〜５１Ｃに、遠隔リソース・リスト取得命令、遠隔リソース・リスト取得応答、および遠隔リソース・リスト取得命令詳細の例を示す。遠隔リソース・リスト取得命令は、命令内の仕様にマッチングするすべての遠隔リソースに対するソフトウェア・リソース記述子（ＳＲＤ）を戻すために用いられる。ＧＲＲＬ命令は、ＨＢＡ特有でもポート特有でもなくても良い。そのため、ＧＲＲＬ命令は、プロキシ識別子を必要としなくても良い。ＧＲＲＬ命令には、２つのパラメータが含まれる。命令制御ワードおよびソフトウェア・リソース属性である。

ＧＲＲＬ応答には、公称応答ブロックと、続いて可変長ＳＲＤリストとが含まれる。

遠隔リソース情報取得（ＧＲＲＩ）
図５２Ａ〜５２Ｂに、遠隔リソース情報取得命令および遠隔リソース情報取得応答の例を示す。遠隔リソース情報取得命令は、命令内で命名されたリソースに対するソフトウェア・リソース記述子（ＳＲＤ）を戻すために用いられる。ＧＲＲＩ命令は、ＨＢＡ特有でもポート特有でもなくても良い。そのため、ＧＲＲＩ命令は、プロキシ識別子を必要とし
なくても良い。

一構成においては、ＧＲＲＩ命令には、１つのＳＲＤが含まれる。このＳＲＤは、不完全であってソフトウェア・リソース名のみを含んでいても良いし、または完全であって名前およびタイプの両方を含んでいても良い。ＳＲＤが不完全である場合には、サーバ１１０は、名前のみにマッチングするリソースを検索する。ＳＲＤが完全である場合には、サーバ１１０は、名前およびタイプの両方にマッチングするリソースを検索する。どちらの場合でも、マッチングするリソースが見つかったら、その完全なＳＲＤを戻す。

ＧＲＲＩ応答には、公称応答ブロックと、続いて可変長ＳＲＤとが含まれる。

ソフトウェア・リソース送信（ＳＳＲ）
図５３Ａ〜５３Ｃに、ソフトウェア・リソース送信命令、ソフトウェア・リソース送信応答、およびソフトウェア・リソース送信命令詳細の例を示す。ソフトウェア・リソース送信命令は、ソフトウェア・リソース（ファイル）を、クライアント・システム１０３からサーバ・システム１１０へコピーするために用いられる。ＳＳＲ命令は、ＨＢＡ特有でもポート特有でもなくても良い。そのため、ＳＲＲ命令は、プロキシ識別子を必要としなくても良い。

宛先リソース・ファイル名が、ＣＴリクエスト内で指定される。それは、ＳＳＲデータ・フィールド内に含まれるソフトウェア・リソース記述子（ＳＲＤ）に含まれる。宛先リソース・パス名は、適切なサーバ属性によって指定され、ＣＴリクエストに含まれていなくても良い。

管理命令送信システムは、Ｉ／Ｏサイズが最大であっても良い。Ｉ／Ｏサイズは、現在のところ、６４Ｋｂであると予想される。ファームウェア・ファイルは、これよりもはるかに大きい。したがってクライアント１０２が、ファイルをバラバラにして断片で送っても良く、サーバ１１０がファイルを再び集めても良い。このタスクは、同期モードＣＴのみを用いれば、ある程度単純になり得るが、クライアント１０２およびエージェント１０４は、単純なフラグメント・レベル・プロトコルを実施しても良い。

メカニズムによっては、個々のＳＳＲリクエストにタグを付けても良い。その結果、サーバ１１０は、複数のファイルをサーバ１１０に同時に送る複数のクライアント１０２を扱うことができる。クライアントおよびサーバＨＢＡ識別子は、ＳＳＲリクエストに、このメカニズムの一部として含まれる。

このメカニズムを完成させるのは、ファイル転送タグおよびフラグメント数である。これらのパラメータは、命令ブロック内の命令特有のパラメータ・ワードに含まれる。

またＳＳＲ命令は、命令特定の命令制御ワードを用いても良い。ＣＣＷ内の制御ビットによって、ＳＳＲデータ・フィールドに含まれるのがＳＲＤなのかリソース・フラグメントなのかが示される。このデザインから２つの意味合いが生じる。第１に、任意の特定のＳＳＲリクエストによって、ＳＲＤまたはリソース・フラグメントが送信されるが、両方ではない。第２に、最小限の２つのＳＳＲリクエストが、ソフトウェア・リソースを送信するために要求される。１つは、ＳＲＤを送信するために、および少なくとも１つは、リソース・フラグメントを送信するためである。

ＳＳＲ応答には、公称応答ブロックが含まれる。

遠隔リソース削除（ＤＲＲ）
図５４Ａ〜５４Ｃに、遠隔リソース削除命令、遠隔リソース削除応答、および遠隔リソース削除命令詳細の例を示す。遠隔リソース削除命令は、ソフトウェア・リソース（ファイル）を遠隔サーバ１１０から移動させるために用いられる。ＤＲＲ命令は、ＨＢＡ特有でもポート特有でもなくても良い。そのため、ＤＲＲコマンは、プロキシ識別子を必要としなくても良い。

リソース・ファイル名は、ＣＴリクエスト内で指定される。リソース・ファイル名は、ＤＲＲデータ・フィールド内に含まれるソフトウェア・リソース記述子（ＳＲＤ）内に含まれる。この命令の場合には、ＳＲＤにヌル・ソフトウェア・リソース属性フィールドが含まれることが推奨される。どんな場合にも、ＳＲＡフィールドは無視される。

リソース・パス名は、適切なサーバ属性によって指定され、ＣＴリクエスト内には含まれない。

ＤＲＲ応答には、公称応答ブロックが含まれる。

遠隔リソース名変更（ＲＲＲ）
図５５Ａ〜５５Ｃに示すのは、遠隔リソース名変更命令、遠隔リソース名変更応答および遠隔リソース名変更命令詳細の例である。遠隔リソース名変更命令は、遠隔サーバ１１０上のソフトウェア・リソース（ファイル）の名前を変更するために用いられる。ＲＲＲ命令は、ＨＢＡ特有でもポート特有でもなくても良い。そのため、ＲＲＲ命令は、プロキシ識別子を必要としなくても良い。

現在のおよび新しいリソース・ファイル名は、ＣＴリクエスト内で指定される。それらは、ＲＲＲリクエスト内に含まれる２つのソフトウェア・リソース記述子（ＳＲＤ）内に含まれる。この命令の場合、各ＳＲＤにはヌル・ソフトウェア・リソース属性のフィールドが含まれることが推奨される。どんな場合でも、各ＳＲＡフィールドは無視される。

ＲＲＲ応答には、公称応答ブロックが含まれる。

送信および受信テスト（テスト）
図５６Ａおよび５６Ｂに示すのは、送信および受信テスト命令、ならびに送信および受信テスト応答の例である。テスト命令によって、遠隔管理命令／応答システムおよびデータ経路をテストするメカニズムが得られる。

ベンダＯＵＩに加えて、テスト命令ブロックには、要求されるＣＴ命令バイト・カウント、要求されるＣＴ応答バイト・カウント、テスト命令参照番号、およびデータ・フィールドが含まれる。命令がサーバ１１０によって処理されると、サーバ１１０は、補足されたデータ・フィールドを含む応答を形成して送信する。命令バイト・カウントおよび応答バイト・カウントについては、等しいことが要求されないことに注意されたい。応答が、クライアント・アプリケーション１０２によって処理されると、データ・フィールドを、データ整合性に関してチェックすることができる。

ＨＢＡ照会（ＨＢＡ）
図５７Ａ〜５７Ｃに示すのは、ＨＢＡ照会応答詳細、ＨＢＡ照会命令、およびＨＢＡ照会応答の例である。ＨＢＡ照会命令は、２つの目的に対して用いても良い。第１に、ＨＢＡ照会命令を用いて、遠隔ＨＢＡ１１２が管理可能であるかどうか、すなわちＨＢＡ１１２が、遠隔管理エージェント１０４および／またはクライアント１０２を実行しているサーバ１１０内にインストールされているかどうかを、判定しても良い。第２に、ＨＢＡ照会命令を用いて、ファームウェア・ダウンロードまたはＨＢＡリセット命令のステータス
を決定しても良い。

ＱＨＢＡ命令は、ＨＢＡ特有であっても良い。そのため、ＱＨＢＡ命令には、オブジェクトＨＢＡ識別子およびプロキシＨＢＡ識別子が含まれていても良い。ＱＨＡＢ命令は、パラメータを必要としなくても良い。リクエストには、公称命令ブロックが含まれていても良い。

ＱＨＢＡ応答には、公称応答ブロックと、続いてステータス・ワードとが含まれていても良い。

遠隔ＨＢＡ１１２が管理可能であるかどうかを判定する場合、ステータス・ワードは適用できなくても良い。応答が存在するかしないかは、以下のように適用することができる。応答がタイム・アウト時間内に到着したら、遠隔ＨＢＡ１１２は管理可能である。応答がタイム・アウト時間内に到着しなかったら、遠隔ＨＢＡ１１２は管理可能ではない。

ファームウェア・ダウンロードまたはＨＢＡリセット命令のステータスをチェックする場合、ステータス・ワードは、以下のように規定される。「完全な」ビットは、成功を意味する。動作上のエラーがある場合、照会命令は拒絶を受け、受領されない。

多くの実施形態について説明してきた。それでもなお、種々の変更を行なっても良いことが理解される。たとえば、ＳＡＮ５０内に複数の遠隔管理者１０３があっても良い。したがって他の実施形態が、以下の請求項の範囲内である。

Claims (17)

1. ファイバ・チャネル・ネットワークの第１のポートに結合されるファイバ・チャネル・ホスト・バス・アダプタおよびｉＳＣＳＩネットワークの第２のポートに結合されるｉＳＣＳＩホスト・バス・アダプタを少なくとも含む複数のホスト・バス・アダプタと、
   前記ファイバ・チャネル・ネットワークと前記ｉＳＣＳＩネットワークとに接続される遠隔管理モジュールであって、前記遠隔管理モジュールは、共通トランスポート・パケットで前記ファイバ・チャネル・ネットワークを介して前記ファイバ・チャネル・ホスト・バス・アダプタに第１の命令を送信することによって、前記ファイバ・チャネル・ホスト・バス・アダプタを管理するように動作可能であり、前記遠隔管理モジュールは、前記ｉＳＣＳＩネットワークを介して前記ｉＳＣＳＩホスト・バス・アダプタに第２の命令を送信することによって、前記ｉＳＣＳＩホスト・バス・アダプタを管理するようにも動作可能である、遠隔管理モジュールと
   を含む、システム。
2. 前記ファイバ・チャネル・ホスト・バス・アダプタおよび前記ｉＳＣＳＩホスト・バス・アダプタのうちの少なくとも１つが、サーバ内にインストールされる、請求項１に記載のシステム。
3. 前記サーバ内にインストールされる第３のホスト・バス・アダプタをさらに含み、前記第３のホスト・バス・アダプタは第３のファイバ・チャネル・ポートに結合され、前記第１の命令は、前記ファイバ・チャネル・ホスト・バス・アダプタに対するオブジェクト・ポート・アドレス、および前記第３のホスト・バス・アダプタに対するプロキシ・ポート・アドレスを指定する、請求項２に記載のシステム。
4. 前記ファイバ・チャネル・ホスト・バス・アダプタが、前記ファイバ・チャネル・ホスト・バス・アダプタがインストールされるサーバのオペレーティング・システムを伴うことなく、前記第１の命令を実行するように動作可能である、請求項１に記載のシステム。
5. 前記遠隔管理モジュールが、第３の命令を前記ｉＳＣＳＩホスト・バス・アダプタに送信するように動作可能であり、前記ｉＳＣＳＩホスト・バス・アダプタが、前記第３の命令に応答するように動作可能である、請求項１に記載のシステム。
6. 前記第１の命令が、前記ファイバ・チャネル・ホスト・バス・アダプタによって前記第１の命令に応答して戻されるデータが記憶されるべきメモリ・バッファのアドレスを指定する、請求項１に記載のシステム。
7. 前記第１の命令が、前記ファイバ・チャネル・ホスト・バス・アダプタからのホスト・バス・アダプタ属性をリクエストする、請求項１に記載のシステム。
8. 前記第１の命令が、前記ファイバ・チャネル・ホスト・バス・アダプタの属性を変更する、請求項１に記載のシステム。
9. 前記第１の命令が、ファイルをリポジトリにコピーし、前記リポジトリは前記遠隔管理モジュールによってアクセス可能である、請求項１に記載のシステム。
10. 前記第１の命令が、前記ファイバ・チャネル・ホスト・バス・アダプタへのファームウェア・ファイルのダウンロードが成功できたかどうかを確認する、請求項１に記載のシステム。
11. 前記第１の命令が、前記遠隔管理モジュールの第１のリポジトリ内のファイルを、前記ファイバ・チャネル・ホスト・バス・アダプタに関連付けられた第２のリポジトリに送信する、請求項１に記載のシステム。
12. 前記第１の命令が、前記ファイバ・チャネル・ホスト・バス・アダプタに、前記ファイバ・チャネル・ホスト・バス・アダプタのリポジトリ内のファームウェアをダウンロードするように指示を出し、前記ファームウェアは前記遠隔管理モジュールからロードされる、請求項１に記載のシステム。
13. 前記第１の命令が、
    ファームウェア・ファイルを第１のリポジトリへコピーすることと、
    前記ファイバ・チャネル・ホスト・バス・アダプタへの前記ファームウェア・ファイルのダウンロードが成功できたかどうかを確かめることと、
    前記遠隔管理モジュールの前記第１のリポジトリ内の前記ファームウェア・ファイルを、前記ファイバ・チャネル・ホスト・バス・アダプタの第２のリポジトリに送信することと、
    前記ファイバ・チャネル・ホスト・バス・アダプタに、前記ファイバ・チャネル・ホスト・バス・アダプタの前記第２のリポジトリ内のファームウェアをダウンロードするように指示を出すことと
    を含み、前記第１のレポジトリは前記遠隔管理モジュールによってアクセス可能である、請求項１に記載のシステム。
14. 前記第１の命令が、ファイバ・チャネル・プロトコル（ＦＣＰ）ターゲットと小さなコンピュータ・システム・インターフェース（ＳＣＳＩ）情報との間のマッピングを取り出す、請求項１に記載のシステム。
15. 前記第１の命令が、前記ファイバ・チャネル・ホスト・バス・アダプタのドライバの属性を取り出す、請求項１に記載のシステム。
16. 前記第１の命令が、前記ファイバ・チャネル・ホスト・バス・アダプタのドライバの属性を変更する、請求項１に記載のシステム。
17. 前記第１の命令が、前記ファイバ・チャネル・ネットワーク上のノードの論理デバイスと物理的なデバイスとの間の永続的な結合を管理する、請求項１に記載のシステム。

Images