JP4068715B2

JP4068715B2 - ファイバ・チャネル環境におけるデータ転送システム及び方法

Info

Publication number: JP4068715B2
Application number: JP08349798A
Authority: JP
Inventors: ジェームズ・エフ・マッカーティ
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1997-03-31
Filing date: 1998-03-30
Publication date: 2008-03-26
Anticipated expiration: 2018-03-30
Also published as: JPH10303936A; EP0869642A3; DE69831827D1; DE69831827T2; US6356944B1; EP0869642B1; EP0869642A2

Description

【０００１】
【発明の属する技術分野】
本発明は、チャネルおよびネットワーク通信システム並びに通信方法に関し、更に特定すれば、ファイバ・チャネル（ＦＣ）環境において、書き込み機能を向上させることができるシステムおよび方法に関するものである。
【０００２】
【従来の技術】
デバイス通信には、チャネルとネットワークという２種類のプロトコルがある。チャネルは、マスタ・ホスト・コンピュータおよびスレーブ周辺デバイス間において、一旦データ通信が開始したなら、ソフトウエアのオーバーヘッドがほとんどなく比較的短い距離において超高速で大量のデータを搬送するように設計されている。チャネルは、通常、ハードウエア集約的であり、マスタおよびスレーブ間に直接接続即ち切替式二点間接続を提供する。一方、ネットワークは、中距離ないし長距離において複数のホストおよびシステム・リソースを共有する多くのユーザにインターフェースし、多くのトランザクションに対応するように設計されている。ネットワークに関しては、高い接続性が得られる限り、通常オーバーヘッドの増大は容認することができるものである。
【０００３】
ファイバ・チャネル・プロトコル（「ＦＣＰ：Fiber Channel Protocol」）は、これら２つの異種通信方法の最良点を組み合わせて、単一のオープン・システム・インターフェース状（ＯＳＩ状）のスタック・アーキテクチャとする、新世代のプロトコルである。本質的に、ファイバ・チャネル（「ＦＣ：Fiber Channel」）は、マルチ・トポロジ(multi-topology)の多層スタックであり、物理的搬送特性を制御する下位レイヤ・プロトコル（「ＬＬＰ：lower-layer-protocol」）、およびオペレーティング・システムと互換性のある上位ソフトウエア構造との間でＬＬＰ通信のマッピングを行う上位レイヤ・プロトコル（「ＵＬＰ：upper-layer-protocol)を備えている。これらのＵＬＰは、チャネル・プロトコルおよびネットワーク・プロトコルの双方を含み、例えば、インテリジェント周辺インターフェース（ＩＰＩ：Intelligent Peripheral Interface）、スモール・コンピュータ・システム・インターフェース（「ＳＣＳＩ：Small Computer System Interface）、およびインターネット・プロトコル（「ＩＰ：Internet Protocol」）のようなプロトコルを含んでいる。
【０００４】
チャネル通信またはネットワーク通信のいずれかに関与するデバイスは、「イニシエータ」または「ターゲット」、あるいはこれらの双方として分類されることは公知である。いくつかの特定の機能がイニシエータまたはターゲットのいずれかに割り当てられる。すなわち、（ｉ）イニシエータは、通信経路の調停（アービトレーション）を行い、ターゲットを選択することができる。（ｉｉ）ターゲットは、コマンド、データ、ステータス、またはその他の情報のイニシエータへの転送、若しくはイニシエータからの転送を要求することができる。（ｉｉｉ）場合によっては、ターゲットが通信経路の調停を行い、トランザクションを継続するためにイニシエータを選択し直すことも可能である。
【０００５】
ファイバ・チャネル・プロトコルと共に動作可能なデバイスでは、イニシエータ機能を有するデバイスのみが、当技術ではリンク・サービス要求(Link Service Request)または拡張リンク・サービス要求(Extended Link Service Request)として知られている要求を開始することができる。リンク・サービス・コマンドは、ファイバ・チャネル・イニシエータに、ノード発見、要求中止、および通信フレーム拒絶というようなタスクを実行する能力を与える。ファイバ・チャネル・ターゲットが開始できる唯一のリンク・サービス・コマンドは、コマンド／フレームの拒絶（「ＬＳ＿ＲＪＴ」）である。
【０００６】
一般に、単一のイニシエータＦＣ環境では、イニシエータ・デバイスは、必要とされるリンク・サービス・コマンドを送出し、それに応答してターゲットから送られてくるリンク・サービス承認（「ＬＳ＿ＡＣＫ」）フレームまたはリンク・サービス拒絶フレーム（ＬＳ＿ＲＪＴ）の受信を待機する。以降、これらのＬＳ＿ＡＣＫおよびＬＳ＿ＲＪＴフレームのことを、総称して、「応答」フレーム又はレスポンス・フレームと呼ぶことにする。一方、マルチ・イニシエータ環境(multi-initiator environment)では、イニシエータは、リンク・サービス・コマンドの受信側および送出側の双方として動作する。これら二重の役割のために、かかるイニシエータは、応答フレームの受信側および送出側の双方として動作する。
【０００７】
【発明が解決しようとする課題】
通信システムの技術分野において、高速での効果的データ転送は、極めて重要なファクタである。さらに、このような転送速度は、通信経路のレイテンシ、デバイスの全体数、及び多数のイニシエータの存在に大きく依存している。今日のＦＣコンパチブル・システムは、通常１つのイニシエータを含んでいるものであるが、該システムにおいては、データの書き込みは、送信側から受信側にコマンド・フレームとデータ・フレームとを別々に送信することによって、連続的に実行されている。
【０００９】
このような連続的なフレーム転送によると、不都合な書き込み状態が生じてしまう場合があり、特に、通信経路が長くてレイテンシ期間が増大している場合に生じてしまう。したがって、ＦＣ環境において、効率的な書き込みメカニズムを提供することが待望されていることが明らかであろう。
連続的書き込みが可能な多数の単一イニシエータＦＣシステムが存在しているものの、上記した問題点を解決し、以下に説明する本発明の新規な特徴及び作用効果をすべて備えたＦＣ通信システムは、未だ開発されていない。
【００１０】
【課題を解決するための手段】
本発明は、上記下問題点及び他の問題点ならびに技術的に不完全な点を解決するために、以下の方法及びシステムを提供するものである。
本発明の方法は、少なくとも１つのオリジネータと少なくとも１つのレスポンダとを含むファイバ・チャネル（ＦＣ）通信環境において、オリジネータからレスポンダにデータを転送するための方法であって、オリジネータからレスポンダへ、書き込みコマンドと少なくとも１つのデータ・フレームとを一緒に送信する送信ステップと、該送信ステップが完了したときに、レスポンダからオリジネータへステータス・フレームを送信するするステータス・フレーム送信ステップとからなることを特徴としている。
好適な実施例においては、該方法は更に、複数のレスポンダ交換識別子（ＲＸＩｄ）を含み、レスポンダに関連するレスポンダ交換識別（ＲＸＩＤ）インデックスの選択された部分であって、オリジネータを一意的に識別する選択された部分を割り当てるステップと、選択された部分に関連する情報をオリジネータに送信するステップであって、レスポンダからのアクノリッジ（受信確認）・フレームのぺイロードの部分によって情報を送信するステップとを含んでいる。
【００１１】
本発明はまた、ファイバ・チャネル（ＦＣ）通信環境においてデータを転送するシステムを提供し、該システムは、データの送信を行うオリジネータと、データを受信するレスポンダとからなり、レスポンダは、オリジネータがレスポンダに対してコマンドとデータ・フレームとを一緒に送ることができるように、データの転送に従って、オリジネータの排他的使用のために、複数のレスポンダ交換識別子の選択された部分を割り当てることを特徴としている。
【００１２】
【発明の実施の形態】
これより図面を参照して説明するが、図面全体にわたって同様または類似する要素には同一の参照番号を付している。また、種々の要素は必ずしも同一の拡縮率で描かれている訳ではない。
図１には、本発明を実施可能な、一例のコンピュータ・システム２００のブロック図が示されている。当業者には明らかであろうが、コンピュータ・システム２００は、ここではその機能的なブロックとして表されている。オペレーティング・システム（「ＯＳ」）２１０が、コンピュータ・システム２００内に設けられ、それに関連する情報の流れを制御する。ＯＳ２１０は、ディスク・オペレーティング・システム（「ＤＯＳ：Disk Operating System」）、あるいは、コンピュータ・システム２００をネットワーク環境内に配置するか否かに応じて、例えば、Windows NT（登録商標）またはNetWare（登録商標）のような、適切なネットワーク・オペレーティング・システム（「ＮＯＳ：Network Operating System」）とすることができる。
【００１３】
更に、ＯＳ２１０は、例えばＳＣＳＩ規格のような、少なくとも１つの従来からのチャネル通信インターエースと共に動作可能である。例示のＯＳ２１０には、更に、例えば、Internet Protocol（「ＩＰ」）のような、従来のネットワーク通信プロトコルとの相互動作を可能にするような機能構造を設けることも可能である。
【００１４】
引き続き図１を参照すると、例示のＯＳ２１０は、上位通信経路２３０を通じて、ＯＳ互換チャネルまたはネットワーク通信プロトコル／インターフェース２１５と通信を行う。例示のコンピュータ・システム２００の機能ブロック図において、上位通信経路２３０は、例えば、ＳＣＳＩプロトコル・ドライバまたはＩＰプロトコル・ドライバといった、通信プロトコル・ドライバのようなＯＳソフトウエア構造を含んでいる。例示のＯＳ２１０およびＯＳコンパチブル（互換）インターフェース／プロトコル２１５は、コンピュータ・システム２００において一体となっており、、これ以降、ＯＳ環境２５０と呼ぶことにする。参照番号２２０は、ファイバ・チャネル（「ＦＣ」）環境を示し、以下で更に詳しく説明する公知のファイバ・チャネル・プロトコル（「ＦＣＰ」）アーキテクチャに加えて、本発明の教示にしたがって動作可能な複数のＦＣデバイスを含んでいる。
【００１５】
更に図１を参照すると、例えば、ＯＳ２１０を含む殆どのオペレーティング・システムには、ＦＣ環境２２０内に配置されているデバイスと「直接」通信する機能が備えられていないことが明らかであろう。したがって、例示のコンピュータ・システム２００において、ＦＣ環境２２０の利点を奏するように構成し利用するために、ＦＣ環境２２０およびＯＳ互換通信インターフェース２１５の間に、リンク経路２２５を設けている。
【００１６】
次に図２を参照すると、図２には、ＦＣＰスタック・アーキテクチャ３００の模式図が示されている。容易に認めることができようが、ＦＣＰアーキテクチャは、オープン・システム・インターフェース（「ＯＳＩ」）スタックと全く同様に、プロトコル・レイヤの階層的集合として構成されている。ＦＣスタックの下位３レイヤ（ＦＣ−０〜ＦＣ−２で示すレイヤ３１０〜レイヤ３２０）が、ファイバ・チャネル物理規格（「ＦＣ−ＰＨ：Fiber Channel Physical Standard」）として知られている物理規格を形成する。この規格は、例えば、ＦＣ環境２２０（図１に示した）を含む、ファイバ・チャネル環境の物理的伝送特性全てを規定するものである。残りのレイヤ（ＦＣ−３で示すレイヤ３２５、およびＦＣ−４で示すレイヤ３３０）は、他のネットワーク・プロトコルおよびアプリケーションとのインターフェースを処理する。イーサネットやトークン・リングのような既存のローカル・エリア・ネットワーク（「ＬＡＮ：Local Area Network」）とは異なり、ＦＣは、スタック３００の種々の機能レイヤを、物理的に分離して保持している。この物理的な分離によって、いくつかのスタック機能をハードウエアで実施し、その他の機能をソフトウエアまたはファームウエアで実施することが可能となることは明らかであろう。
【００１７】
レイヤ３１０、即ちＦＣ−０は、ＦＣアーキテクチャの最下位の機能レイヤであり、ＦＣ環境２２０（図１に示す）に配置された複数のＦＣデバイス間のリンク接続の物理的特性を記述する。ＦＣ−０は、１３３Ｍｂａｕｄ（ボー）の基準速度、最も一般的に使用されている速度である２６６Ｍｂａｕｄ、ならびに５３１Ｍｂａｕｄおよび１．０６２Ｇｂａｕｄに対応する。しかしながら、リンク接続を確立し維持する際に伴うオーバーヘッドのために、実際のデータ・スループットはいくらか低く、１３３Ｍｂａｕｄでは１００Ｍｂｉｔ／ｓ、２６６Ｍｂａｕｄでは２００Ｍｂｉｔ／ｓ、５３１Ｍｂａｕｄでは４００Ｍｂｉｔ／ｓ、そして１．０６２Ｇｂａｕｄでは８００Ｍｂｉｔ／ｓとなる。更に、ＦＣ−０は、単一モードまたはマルチモードの光ファイバ・ケーブル、同軸ケーブル、およびシールド・ツイスト線対（「ＳＴＰ：shielded twisted pair」）媒体を含む、広範囲の物理的ケーブルに対応する。これらのケーブル要素の各々は、ある範囲のデータ速度に対応し、特定の距離制限を賦課するが、ＦＣは，図２に示したＦＣ環境２２０のような同一ＦＣ環境内において、これらの全てを混合することができる。例えば、単一モードの光ファイバを１０ｋｍまでの距離に使用することができ、２００Ｍｂｉｔ／ｓのマルチモード・ファイバを２ｋｍまでの距離に使用することができ、１００Ｍｂｉｔ／ｓに対応するＳＴＰを５０メートルまでの距離に使用するようにしてもよい。
【００１８】
レイヤ３１５、すなわちＦＣ−１は、直列エンコード（符号化）およびデコード（複合化）規則、特殊特性、ならびにエラー制御を含む、伝送プロトコルを定義する。ＦＣ−１は、８Ｂ／１０Ｂブロック・コードを用い、８データ・ビット毎に、ディスパリティ制御(disparity control)として知られている、エラー検出および訂正のための２つの余分なビットを付け加え、１０ビット群として送信する。８Ｂ／１０Ｂ方式は、十分なエラー検出および訂正機能を与えるので、低コストのトランシーバを用いることができ、タイミング復元方法を用いて、無線周波数干渉の危険性を低下させると共に、均衡の取れた同期送信を確保することができる。
【００１９】
ＦＣ−ＰＨの第３レイヤ３２０、即ちＦＣ−２は、ＦＣデバイス間でデータがどのように転送されるかについて記述し、各ＦＣデバイスは「ノード」に配置され、フレーム・フォーマット、フレーム・シーケンス、通信プロトコル、およびサービス・クラスの定義を含む。ファイバ・チャネルにおけるデータ送信の基本単位は、可変サイズのフレームである。フレームの長さは、２，１４８バイトまでとすることができ、２，０４８バイトまでのペイロード、フレーミング(framing)、送信元（ソース）および宛先ポート・アドレシング、サービス・タイプ、ならびにエラー検出情報を与える３６バイトのオーバーヘッド、ならびにユーザ・データ、即ち、ペイロードについてのその他の種々雑多な情報のための６４バイトの付加的な任意のオーバーヘッドから成る。単一の上位レイヤ（即ち、スタック３００における上位レイヤ）のプロトコル・メッセージは、フレームのペイロード容量よりも大きくすることができ、その場合、メッセージは、シーケンスと呼ばれる、一連の関連付けられたフレームに分割される。ＦＣ通信フレームに関しては、以下にさらに説明する。
【００２０】
引き続き図２を参照すると、ＦＣ−２レイヤは、ＦＣＰスタック３００の主要な「ワークホース(workhorse)」であり、ＦＣ−０レイヤを通じた送信のために、上位レイヤ（レイヤ３２５，３３０）からのデータをフレーム化して、連続的に送り出す。また、ＦＣ−０レイヤからの送信を受け入れ、上位レイヤ３２５，３３０による使用のために、必要であれば、それらを再度フレーム化し、そして再度連続的に送り出す。２つのノード間の全二重送信経路を定義することに加え、ＦＣ−２レイヤは、フロー制御、リンク管理、バッファ・メモリ管理、ならびにエラー検出および訂正を含む、必須のトラフィック管理機能も提供する。
【００２１】
ＦＣＰスタック３００の重要な特徴の１つは、ＦＣ−２レイヤが４つのサービス・クラスを定義し、種々の通信の要望に答えることである。クラス１サービスは、専用の無中断通信リンクである、ハード・ワイヤ、即ち、回路切替型接続を定義する。このサービスは、その期間の間、接続の排他的使用（時として「利己的接続」と呼ばれる）を提供する。クラス１サービスは、２台のスーパーコンピュータ間のように、時間に厳しく「バーストを発生させない」専用リンクのために設計されたものである。クラス２サービスは、配信を保証し、トラフィックの受信を確認する、無接続フレーム交換送信である。フレーム・リレーのような従来のパケット交換技術と同様、クラス２の交換は、接続上ではなく、ＦＣデータ・フレーム上で行われる。ノード間には専用接続は確立されず、各フレームは、使用可能なルート上でその宛先まで送られる。クラス２トラフィックにおいて輻輳（congestion）が発生した場合、その宛先に首尾良く到達するまで、フレームを再送信する。クラス３サービスは、１対多数の無接続フレーム交換サービスを定義し、配信保証や確認機構がないことを除いて、クラス２サービスと同様である。クラス３の送信は、確認を待たないので、クラス２の送信よりも高速である。しかしながら、送信がその宛先に到達しない場合、クラス３のサービスは再送信を行わない。このサービスは、承認を待つことができないがクラス１サービスを保証する程に時間に厳しくない、リアル・タイム・ブロードキャストに最も多く使用されている。また、フレームの損失が許されるアプリケーションにも使用されている。クラス４サービスは、接続を基本とするサービスであり、部分的帯域(fractional bandwidth)の保証およびレイテンシ・レベルの保証を提供する。
【００２２】
ＦＣ−３レイヤ、即ち、レイヤ３２５は、ＦＣ−ＰＨレベルより高い上位レイヤ・プロトコルの通信サービスの共通集合を提供する。これらの追加サービスは、例えば、マルチキャスト(multicast)およびブロードキャストのデータ配信機構、１つ以上のターゲット・ノードが所与のイニシエータ・ノードに応答可能な「ハント(hunt)」群、ならびに多数の上位レイヤ・プロトコルおよびＦＣ−ＰＨの多重化を含むことができる。
【００２３】
ＦＣＰスタック３００の最上位レイヤであるレイヤ３３０は、ＦＣ−４レイヤである。これは、例えば、図２に示したＦＣ環境２２０のようなＦＣインフラストラクチャ上で動作可能な上位レイヤの用途を定義する。ＦＣ−４レイヤは、既存のチャネルおよびネットワーク・プロトコルを、ファイバ・チャネル上で、これらのプロトコルを変更することなく利用する方法を提供する。したがって、ＦＣ−４レイヤは、プロトコル収束レイヤ(protocol convergence layer)のように作用するので、ＦＣノードは、上位レイヤのチャネルまたはネットワーク・プロトコルが要求する正確な下位レイヤ搬送サービスを提供するように見える。この収束機能は、ＦＣ−４レイヤが、バッファ記憶、同期、またはデータの優先順序付けのような、追加のサービスを提供することを、要求する。ＦＣ−４の機能は、図１に示した例示のコンピュータ・システム２００の、ＦＣ環境２２０およびＯＳ互換インターフェース２１５間に配されたリンク経路２２５に含まれる。
【００２４】
引き続き図２を参照すると、種々のＦＣ−４レベル・マッピングが、多数の上位レイヤ・チャネルおよびネットワーク通信プロトコルのために指定されている。その中には、インテリジェント周辺インターフェース（「ＩＰＩ」）、ＳＣＳＩ、高性能並列インターフェース（「ＨＩＰＰＩ：High-Performance Parallel Interface）、単一バイト・コマンド・コード・セット（「ＳＢＣＣＳ：Single Byte Commnad Code Set）、論理リンク制御（「ＬＬＣ：Logical Link Control」）、ＩＰ、および非同期転送モード（「ＡＴＭ：Asynchronous Transfer Mode」）アダプテーション・レイヤ（「ＡＡＬ：Adaptation Layer」）が含まれる。
【００２５】
ファイバ・チャネル・プロトコルと共に動作可能なデバイスは、それらがイニシエータであるか、あるいはターゲットであるかには無関係に、ＦＣＰスタック３００の中間レイヤのいくつかの機能を具体化するコントローラ（以降「ＦＣコントローラ」と呼ぶ）を通常含んでいる。例えば、現在のＦＣコントローラは、一般に、レイヤ３１５，３２０（ＦＣ−１，ＦＣ−２）の機能を具体化する。一方、図１に示した例示コンピュータ・システム２００のようなホスト・コンピュータは、上位レイヤ（ＦＣ−３，ＦＣ−４）を担当する。例えば、ギガバイト・リンク・モジュール（「ＧＬＭ：Gigabit Link Module」）のような物理的リンク・モジュール（「ＰＬＭ：Physical Link Module」）が、最下位レイヤ３１０（ＦＣ−０）を実現する。
【００２６】
２つのＦＣデバイスの間の情報交換を調整するための中央メカニズムは、ＦＣアーキテクチャにおける最高位レベルで動作可能なプロセスであり、この分野において、一般に交換又はエックスチェンジ(exchange)と呼ばれている。交換は、１つ又は複数の関連するシーケンス、すなわち、１つのＦＣデバイスから他のＦＣデバイスに転送される１つ又は複数のデータ・フレームで成り立っている。２つのＦＣデバイス間に多数の交換が存在するが、通常はただ１つのシーケンスだけが交換においてアクティブス状態となる。交換に関しては、ＦＣマスタ・デバイス及びステーブ・デバイスは、通常、オリジネータ及びレスポンダとそれぞれ呼ばれている。シーケンスに関しては、マスタ・デバイス及びスレーブ・デバイスは、イニシエータ及びレシピアント(受取人)とそれぞれ呼ばれている。
【００２７】
種々の長さによって特徴付けられているフレームは、一般的に、開始デリミタ(フレームの開始（ＳＯＦ）デリミタ)、フレーム・ヘッダ、あるぺーロード、周期的冗長性チェック（ＣＲＣ）、及び終了デリミタ（フレームの終了（ＥＯＦ）デリミタ）を含んでいる。ＳＯＦ及びＥＯＦは、ＦＣ仕様特殊キャラクタ（FC-specific Special Character）を含んでおり、該キャラクタは、フレームの開始点及び終了点を表すために用いられるものである。ＦＣ仕様特殊キャラクタは、１０ビットの送信キャラクタであり、対応する８ビット値（上記したような、８ビット／１０ビットブロック符号化）を有するものではないが、有効であると考えられている。
【００２８】
ＦＣプロファイルは、相互動作可能仕様であり、多数のＦＣ−４レベルＵＬＰマッピングのために１組の実施ガイドラインとして工業的に用いられている。該プロファイルは、システム製造業、システム組み立て業、部品製造業、ユーザ募集のためのルールの骨格として提供され、相互動作可能なＦＣ周辺要素、ホスト、及び要素を設計し選択することができるようにする。各プロファイルは、上記したファイバ・チャネルの物理的、リンク・レベル、及びＵＬＰオプションの設定が、相互動作可能な使用として選択されるべきものであることを、特定する。基本的には、１つのＦＣプロファイルは、ＦＣオプション空間を介する仮想スライスとして考えられる。以下の表１は、ＦＣ−ＳＣＳＩプロファイルで動作可能なフレーム・ヘッダの内容を概略的に示している。
【表１】

【００２９】
表1の多数のフレーム・ヘッダ・フィールドを以下に説明する。ＲＣＴＬフィールドは、ＦＣプロトコル動作の部分としてフレームを識別し、かつ、情報のカテゴリを識別する。ＤＩＤフィールドは、フレームの宛先を識別する。交換オリジネータから送信されたＤＩＤは、ＳＣＳＩ規格のターゲット識別子である。ＳＩＤフィールドは、フレームの送信元すなわちフレーム・ソースを識別し、交換オリジネータからのＳＩＤは、ＳＣＳＩ規格のイニシエータ識別子である。タイプ（ＴＹＰＥ）・フィールドは、データ・フレームに関するフレーム内容のプロトコルを識別する。ＳＣＳＩ−ＦＣＰに関しては、このフィールドの値は、0ｘ08である。
【００３０】
表1のＦＣＴＬフィールドは、シーケンス及びエックスチェンジの開始、及び通常終了又は非通常終了を管理するものである。ＳＥＱＩＤは、特定のエックスチェンジ・オリジネータと特定の値を持つ交換レスポンダとの間の各シーケンスを特定する。ＤＦＣＴＬは、存在するオプションのヘッダを特定する。なお、これらのヘッダは、必ずしも必要なものではない。ＳＥＱＣＥＴフィールドは、シーケンス内のフレームの順番を表すものである。ＯＸＩＤフィールドは、フレームを一意的に特定するために交換のオリジネータ識別子であり、これらフレームは、特定の交換の部分を構成している。ＲＸＩＤフィールドは、特定の交換の部分を構成するフレームを特定するための交換のレスポンダ識別子である。以下の説明から明らかなように、オリジネータからのフレーム中のＲＸＩＤフィールドは、本発明の技術思想によって採用されたものであり、これにより、コマンド・フレームとデータ・フレームとが一緒に送信される、効果的な書き込み動作を実行することができる。
【００３１】
ＲＬＴＶＯＦＦフィールドは、情報カテゴリのベース・アドレスに関しての、フレームの各ペイロードの最初のビットの相対的変位を表している。ＦＣＳＣＳＩプロファイルに関しては、相対的オフセットは、ＳＣＳＩ規格アプリケーションのクライアント・バッファ・オフセットであり、ベース・アドレスは、該アプリケーションのクライアント・バッファの開始アドレスである。
オリジネータは通常、ある限定数のオープン交換を処理する。各交換は、オリジネータ中のリソース、例えば、メモリ部分、フレーム、フレーム・ヘッダ、等のリソースを提供し、これにより、選択されたレスポンダと交換プロセスを実行する。これらのリソース部分は、オリジネータが利用可能なＯＸＩＤによってインデックスされることが好ましい。
レスポンダは、該レスポンダ中のリソース部分に関連するオープン交換だけではあるが、同様に処理できる。これらのリソース部分は、レスポンダが利用可能なＲＸＩＤによってインデックスされる。明らかなように、オリジネータ及びレスポンダはそれぞれ、多数のオープン交換を有することが可能である。
【００３２】
次に図３のＡ〜Ｃを参照すると、３種類のトポロジ構成例が、全体的に４９０，４９１，４９２でそれぞれ示されており、その中にＦＣノードを配置することができる。ノードとは、ＵＬＰ、ＦＣ−３、およびＦＣ−２機能のいくつかを処理する能力を有するエンティティ、システム、またはデバイスのことである。ノードは、１つ以上のポートを含むことができ、これらは一般的にノード・ポートすなわちＮ＿ＰＯＲＴとして知られている。Ｎ＿ＰＯＲＴは、ＦＣ−ＰＨを支援するノード内のハードウエア実体である。これは、送信元（即ち、イニシエータ）、応答側（即ち、ターゲット）、または双方として動作することができる。以降、ノード、デバイス、およびポートという用語は、相互交換可能に用いることにする。
【００３３】
図３のＡの４９０は２点間トポロジを示し、双方向通信リンク４１０Ａ，４１０Ｂを利用して、任意の２つのＦＣノード（ここではＮ＿ＰＯＲＴ４００Ａ，４００Ｂで示す）の間に全二重送信経路を提供する。この接続トポロジは、介在するデバイス／ノードがないので、可能な最大帯域および最低のレイテンシを提供する。
図３のＣの参照番号４９２は切替ファイバ・トポロジであり、各ＦＣデバイス即ちノード（Ｎ＿ＰＯＲＴ）が、ファブリック、例えば、ファブリック４３０の一部であるＦ＿ＰＯＲＴに接続され、このファブリック上の他のいずれかの接続への無遮断データ経路を受ける。Ｆ＿ＰＯＲＴとは、物理的に他のノードに接続するためのファブリックのアクセス点である。ファブリック４３０は、スイッチまたは一連のスイッチとすればよく、ノード間のルーティング、エラー検出および訂正、ならびにフロー制御を担当する。ファブリック４３０の動作は、上位レイヤの通信プロトコルとは独立しており、専ら距離には無関係であり、いずれの技術を基準にしてもよい。
【００３４】
通信経路、例えば、経路４３９は、ノード、Ｎ＿ＰＯＲＴ４４０、およびファブリックのポート（Ｆ＿ＰＯＲＴ）４３６間に双方向接続を提供する。切替ファブリック・トポロジ４９２は、３種類のＦＣトポロジ全ての内、最大の接続能力および総計スループットを与える。切替ファブリック・トポロジ４９２は、多数のシステムを相互接続し、高帯域に対する要求を支持し、異なる速度の接続間でデータ速度を一致させ、異なるケーブル要素の整合を取る機能を提供する。
図３のＢの４９１は、ＦＣ−ＡＬ規格と呼ばれる接続規格に準拠し、調停ループ（「ＡＬ」）として当技術では知られている、ループ・トポロジを示している。ループ・トポロジ４９１は、例えば、Ｌ＿ＰＯＲＴ４２０Ａ〜４２０Ｄのような複数のＦＣデバイス即ちノード（ループ・ポート即ちＬ＿ＰＯＲＴとして示す）を、単一方向リンク、例えば、リンク４２５Ａ〜４２５Ｄを通じて相互接続する。したがって、この接続構成は、各デバイスがループ・トポロジ４９１を、送出側および受信側間において二点間接続として使用することを可能にするものである。その際、それらの間にどのようなデバイスが介在しても無関係であり、それらは単に「リピータ（中継器）」として作用するに過ぎない。
【００３５】
仲裁（調停）されたループ４９１は、ハブまたはスイッチを必要とせずに、多数のデバイスを取り付ける低コストの手段を提供する。図３のＢには４つのＬ＿ＰＯＲＴのみを示すが、このループは１２７個までのＬ＿ＰＯＲＴの共有帯域を提供する。各Ｌ＿ＰＯＲＴは、他のポートと通信する必要がある場合に、ループの使用を要求する。ループが未使用ステータス・の場合、要求元のポートは宛先ポートとの双方向接続を設定する。ループ・プロトコルによって、Ｌ＿ＰＯＲＴは、連続的に送信媒体に対するアクセスのアービトレーション（調停）を行い、他のＬ＿ＰＯＲＴに送信することが可能となる。フェアネス・アルゴリズム(fairness algorithm)によって、ループへのアクセスが阻止されるＬ＿ＰＯＲＴが生じないことを保証する。一旦接続が確立されると、次に、２つのＬ＿ＰＯＲＴ間のトラフィックに適したいずれかのサービス・クラスで、配信が可能となる。
【００３６】
当技術では公知のように、一度に通信可能なＬ＿ＰＯＲＴは１対のみである。これらのＬ＿ＰＯＲＴがループの制御を放棄した場合、他の２つのＬ＿ＰＯＲＴ間の二点間接続を確立することができる。更に、ループ全体は、ＦＬ＿ＰＯＲＴとして知られているものを通じてＦＣ交換ファブリック・ポートに、またはＮＬ＿ＰＯＲＴを通じて直接単一のホスト・システムに、交互に取り付けることも可能である。
本発明の現時点における好適な例示実施例は、ループ・トポロジ４９１のようなＦＣ−ＡＬトポロジを含み、このノード構成の全体的な動作について、以下で更に詳細に説明する。
【００３７】
ＦＣ−ＡＬ規格は、各ＦＣデバイスが、ループ初期化プロセスにおいて、調停されたループ物理アドレス（ＡＬ＿ＰＡ：Arbitrated Loop Physical Address）について取り決めることを許しており、これは知られていることである。調停されたループに参加している間、ＦＣデバイスは、ループ・トランザクションを開始する前に、互いにログインしなければならない。ログイン手順は、全ての通信ノードが実行し、サービス・パラメータや共通動作環境を確立するための初期手順である。サービス・パラメータの例の１つに、「クレジット」限度がある。これは、受信側ポートにおいてバッファ記憶の溢れ(overrun)を発生させることなく、ポートが送信可能な未決フレームの最大数を表す。クレジットとは、各送信元ポート送出可能なフレーム数を限定することによって、リンクのトラフィックを絞るフロー制御機構であることは自明であろう。従来のＦＣコントローラでは、バッファ対バッファ・クレジット（「ＢＢ＿Ｃｒｅｄｉｔ：buffer-to-buffer credit」）および端末（エンド）対端末クレジット（「ＥＥ＿Ｃｒｅｄｉｔ：end-to-end credit」）という２種類のクレジットが一般に用いられている。
【００３８】
あるデバイスが他のデバイスにログインしない場合、ログインするまで、当該デバイスから受信したあらゆるフレームをディスカード（破棄）する。イニシエータまたはドライバがそれが通信しているターゲット・デバイスを管理することができなければならないので、イニシエータは、当該ターゲット・デバイスに対するＦＣ−特定識別トリプレット(identity triplet)を追跡する。このＦＣ特定ＩＤトリプレットは、ターゲットのノード名、そのポート名、およびそのＡＬ＿ＰＡから成る。ＡＬ＿ＰＡはループ・リセット時に動的に割り当てられるが、ノード名およびポート名は、装置の一意のワールド・ワイド名(World_Wide_Name)から形成される。
【００３９】
リセット時に、デバイスが調停されたループ上に上った場合、デバイスは、ループ初期化ステップにおいて３つの方法の１つでデバイスのＡＬ＿ＰＡを環境設定する。ソフト・アドレス方式(Soft Address scheme)では、デバイスは、どのＡＬ＿ＰＡがそれに割り当てられるかには注意しない。むしろ、最初の未使用ＡＬ＿ＰＡで入手可能なものを単純に受け入れる。好適アドレス方式(Preferred Address scheme)では、ＦＣデバイスは、特定のＡＬ＿ＰＡが割り当てられることを望む。しかしながら、何らかの理由で所望のＡＬ＿ＰＡが利用できない場合、未使用でありかつ利用可能ないずれかのＡＬ＿ＰＡを受け入れる。例えば、ＯＳのロードに続く「全体的な」システムの初期化時に、デバイスに特定のＡＬ＿ＰＡが最初に割り当てられた後、このデバイスは、後続のループ・リセット時に、当該ＡＬ＿ＰＡを要求し続ける。しかしながら、一旦このデバイスが調停されたループから外れたなら、そのＡＬ＿ＡＰを「選択」する能力は失われ、利用可能な最初の未使用ＡＬ＿ＰＡを受け入れことに甘んじなければならない。
【００４０】
第３に、ハード・アドレス方式(Hard Address scheme)では、ＦＣデバイスは、特定のＡＬ＿ＰＡでのみ動作することができる。ＡＬ＿ＡＰの環境設定を扱うＦＣ−ＡＬ規格におけるループ初期化プロトコル（「ＬＩＰ」）によれば、このアドレス構成方法は、最初の２つの方法、即ち、ソフト・アドレス方式および好適アドレス方式に勝るものである。
イニシエータＦＣデバイスは、全てのＡＬ＿ＰＡ割り当て問題が解決した後に、リンク・サービス・コマンド／フレームを開始することができる。リンク・サービス・フレームは、「要求」フレームおよび「応答」フレームの双方を含む。要求フレームは、受信側デバイスに、応答フレームを返送するように要求するリンク・サービス・フレームであり、例えば、ログイン・リンク・サービス・フレーム（「ＰＬＯＧＩ：Login Link Service Frames」）、ログアウト・フレーム（「ＰＬＯＧＯ：Logout Frames」）、Ｎ＿ポートサービス・パラメータ発見フレーム（「ＰＤＩＳＣ：Discover N_Port Service Parameters」）、アドレス発見フレーム（「ＡＤＩＳＣ：Discover Address Frames」）、プロセス・ログイン・フレーム（「ＰＲＬＩ：Process Login Frames」）、プロセス・ログアウト・フレーム（「ＰＲＬＯ：Process Logout Frames」）、および復位復元資格フレーム（「ＲＲＱ：Reinstate Recovery Qualifier Frame」）を含んでいる。
【００４１】
単一イニシエータ環境では、イニシエータ・デバイスは、必要に応じて、リンク・サービス・フレームを送出し、それに応答して、アクノレッジ（承認）・フレーム（ＬＳ＿ＡＣＣ）または拒絶フレーム（ＬＳ＿ＲＪＴ）を期待する。更に、イニシエータ・デバイスは、未決リンク・サービス・アレイと呼ばれる記憶アレイ内に、各リンク・サービス・フレームに対するタイプ情報（以降、「タイプ情報要素」と呼ぶ）を記憶するこにより、送出されるリンク・サービス・フレームのタイプを追跡する。この未決リンク・サービス・アレイは、複数の記憶位置から成り、その各々が受信側デバイスのＡＬ＿ＰＡに対応する。更に、典型的な実施例では、全てのリンク・サービス・フレーム・タイプは、それらが送出される際に、各受信側に記憶される。
【００４２】
イニシエータ・デバイスによる初期ポート発見プロセスは、それが１つ以上のイニシエータを含んでいるか否かには無関係に、ＦＣ−ＡＬ環境では二段階プロセスである。最初に、イニシエータが既に受信側デバイスにログインしている場合、ＰＤＩＳＣフレームが送信される。その他の場合、ＰＬＯＧＩフレームが送信される。第２に、ＰＬＯＧＩフレームに応答してＬＳ＿ＡＣＣフレームが返送され受信された場合、イニシエータは、当該応答側にＰＲＬＩフレームを送る。一方、ＰＤＩＳＣフレームに応答して、ＬＳ＿ＡＣＣフレームが返送され受信された場合、他のフレームを当該応答側に送る必要はない。
【００４３】
図4のＡは、イニシエータ４１０からターゲット４１５にデータを効果的に転送するための従来例方法のスキームを示している。このスキームにおいては、ＦＣイニシエータ410が最初に、ＦＣプロファイルで使用可能な、例えばＦＣＳＣＳＩプロファイル等の書き込みコマンド４００を送信する。これは、図4のＡにおいては、矢印４０５により示されている。イニシエータ４１０は、ターゲット４１５に返送すべき転送レディ（準備完了）・フレーム４２０を待機する。制御のためのループ仲裁が成功した後、ターゲット４１５は、このフレーム４２０をイニシエータ４１０に送り、これにより、イニシエータが送信したいすべての又は部分的なデータの受信準備を完了したことを示す。このステップは、図４のＡにおいて矢印４２５で示されている。
【００４４】
この後、仲裁によりループ・コントロールを得ることにより、矢印４３５で示すように、イニシエータ４１０は、１つ又は複数のデータ・フレーム４３０をターゲット４１５に送信すなわち書き込みを行うことができる。ターゲット４１５がデータを受信すると、該ターゲットは、ステータス・フレーム４４０をイニシエータ４１０に返送して、書き込みコマンドが完了したことを示す。
【００４５】
明らかなように、上記したような従来例のファイバ・チャネル書き込み技術は、書き込みコマンドを完了させるために少なくとも４つのループ仲裁を必要としており、従って、実用的ではない。この技術分野で知られているように、ループ仲裁は、時間がかかってしまい、また、１つのコマンド実行サイクル当たりの仲裁の総数が増大すると、それに連れてシステム機能が降下する。さらに、ループ・テクノロジが多数のイニシエータを含んでいる場合、または、多数のデバイスが追加されたことによりループ距離が増大した場合は、書き込み機能は反対に低下してしまう。
【００４６】
図４のＢには、本発明の技術思想に係る、ファイバ・チャネル機能を増大させるための方式が開示されている。イニシエータ４１０は、書き込みコマンド及びデータ・フレームの両方（高速書き込み送信４５５）を、１つの仲裁において、このようなフレームを受信する能力を有するターゲット４１５に転送することができる能力を有している。これは、図４のＢにおいては、矢印４６０として示されている。ターゲット４１５において適切にデータが受信されると、矢印４６５によって示されているように、ステータス・フレーム４４０がイニシエータ４１０に返送され、これにより、高速書き込み送信４５５の完了を表すことができる。明らかなように、この方式により、ターゲット４１５にとって、仲裁してから転送レディ・フレームを送信する必要がなくなる。原則的には、必要とする仲裁の総数は、本発明の高速書き込みのアプローチによって低減することができ、それにより、システム機能が著しく増大する。
【００４７】
図５には、本発明の技術思想に係る、上記したファイバ・チャネル環境において高速書き込みを行うための、通信フレーム５０１が示されている。通信フレーム５０１は、例えば、イニシエータからのＰＬＯＧＩ等の要求フレームであるか、または、ＬＳＡＣＫ等の応答フレームである。該フレーム５０１のペイロードは、送信側のＦＣデバイスの製造者／ベンダに一意的なベンダ・レベルの情報を提供するための、１６バイトの部分５０５を備えていることが好ましい。該１６バイトの部分５０５は、第１のサブ部分５０６及び第２のサブ部分５０７により構成されている。これらの２つのサブ部分の各々は、８バイトであり、第１のサブ部分５０６は、ベンダ特定情報として用いられるＢ０〜Ｂ７で構成されている。
【００４８】
図５において、本発明により提供されたターゲット／レスポンダ・デバイスは、高速書き込み動作を実行するために必要な多数のコントロール・パラメータを識別するための第１のサブ部分５０６を使用している。この好適な実施例においては、第１のサブ部分５０６の８バイトが、レスポンダのフレームにおいて、以下のように用いられる。最初の４バイト、すなわちＢ０〜Ｂ３は、書き込み込コマンドとともに転送されるデータの最大量を示している。次に２バイト、すなわちＢ４及びＢ５は、以下に詳細に説明するが、有効な第１のＲＸＩＤであり、これは、高速書き込みが可能なイニシエータ又はオリジネータが高速書き込みのために用いることができる。最後の２バイト、すなわちＢ６及びＢ７は、高速書き込みを行うためにオリジネータによって排他的に使用されるために、レスポンダによって選択されたＲＸＩＤが幾つあるかをオリジネータに示すためのものである。好適な実施例においては、これらの選択されたＲＸＩＤの使用を管理するために、オリジネータの管理に任せることが好ましい。
【００４９】
更に図５を参照する。本発明の技術思想によって提供されたオリジネータは、通信フレーム５０１の第１のサブ部分５０６を少なくとも利用する。好適な実施例においては、最初のバイトＢ０は、送信側のオリジネータが高速書き込み通信を行うレスポンダに示すようにエンコードされている。
【００５０】
次に図６を参照すると、オリジネータ交換識別子構造、すなわちＯＸＩＤインデックス６０５及びレスポンダ交換識別子構造、すなわちＲＸＩＤインデックス６１０が示されている。ＲＸＩＤインデックス６１０は、レスポンダに備えられ、所定数の交換識別子ＲＸＩＤ1〜Ｍを含んでいる。これらの総数は、レスポンダが処理できるオープン交換の数に制限される。ＲＸＩＤインデックス６１０の部分、例えば、部分６２０は、ＲＸＩＤの所定範囲で構成されており、本発明の技術思想に応じて、特定のオリジネータに、高速書き込みトランザクションを実行するために割り当てられている。参照番号６２１は、高速書き込みのために該オリジネータが使用する有効な第１のＲＸＩＤを表している。参照番号６２９は、同様に、該オリジネータに割り当てられている最後のＲＸＩＤを示している。図には示してないが、インデックス６１０の各ＲＸＩＤは、レスポンダのリソース部分に関連していることが好ましい。
【００５１】
ＯＸＩＤインデックス６０５は、オリジネータに備えられており、所定数のＯＸＩＤ１〜Ｍを含んでいる。これらのＯＸＩＤは、オリジネータが処理できるオープン交換の総数に制限されている。ＯＸＩＤインデックス６０５の各ＯＸＩＤは、オリジネータのリソース部分に関連していることが好ましい。さらに、ＯＸＩＤインデックス６０５の部分６１５は、関連付マッピング６５０により、ＲＸＩＤインデックスの部分６２０と関連付けられていることが好ましい。この機能は、部分６２０中の割り当てられたＲＸＩＤをマッピングするために、オリジネータに備えられる。なお、他の方法のマッピングを採用できることは言うまでもない。
【００５２】
図７には、本発明の動作のフローチャートが示されている。上記したように、ＦＣデバイスへログするプロセスは、まったくのシーケンシャルなタスクである。したがって、高速書き込み（ＦＷ）可能なレスポンダは、ログするオリジネータ（ＦＷ可能または不可能）が幾つＦＣチャネル仲裁ループに存在するのかが分かっていない。多数のオリジネータが存在する環境においては、すべてのＦＷ可能なオリジネータが、ＦＷ可能でベンダ・コンパチブルなレスポンダのそれぞれによってオリジネータに割り当てられた適切な数のＲＸＩＤを保有することを、確実にする必要がある。
【００５３】
図７のブロック７０１においてスタート／リセットが行われた後、ブロック７０２において、ＦＣデバイスは、ＡＬＰＡを環境設定するためにループ初期化を行う。次に、ブロック７０３において、オリジネータはログイン・プロセスを実行するが、ＦＷ可能デバイスのＰＬＯＧＩフレームは、ＦＷ可能な特性をレスポンダに示すために埋め込まれた情報を含んでおり、該フレームをログインする。次にブロック７１０において、本発明の技術思想に係る高速書き込みが可能なレスポンダは、特定のＦＷオリジネータを排他的に使用するために、ＲＸＩＤインデックスから所定数選択されたＲＸＩＤを割り当てる。このクリティカル（臨界的）情報は、レスポンダからオリジネータへ送信されるＬＳＡＣＫフレームのベンダ特定部分に埋め込まれている。
ＦＷ可能なレスポンダからクリティカル情報を受信すると、オリジネータは、それらの使用をマッピングするために、レスポンダからの割り当てられたＲＸＩＤに、オリジネータのＯＸＩＤインデックス中の一部分を関連付ける。これは、ブロック７１５に示されている。
【００５４】
レスポンダは、ループ初期化ステップ（ブロック７０２）を、ある条件に基づいて開始することが可能である。例えば、あるオリジネータが他のオリジネータの開始の前にコンパチブル・レスポンダにログインすると、該オリジネータは、高速書き込みをサポートするＲＸＩＤのすべてを割り当てられる。それから所定時間経過後に他のオリジネータがそのレスポンダにログインする場合には、返送されたＬＳＡＣＫフレームは、ＦＷ可能なＲＸＩＤが利用不可能であることを表している。このような状態において、レスポンダは、仲裁ループにログインしている１又は複数のオリジネータが存在していることを検出する。レスポンダがこのような状態を検出すると、該レスポンダは、すべてのオリジネータが該レスポンダにログバックするよう、初期化ステップを開始することができる。レスポンダは幾つのオリジネータがループに存在するかについての知識を有しており、そのＲＸＩＤインデックスの部分を割り当てることが可能となる。
【００５５】
更に図７を参照する。高速書き込みにしたがってコマンド及びデータ・フレームがレスポンダによって受信された後、オリジネータに、コマンドが完了したことを表すステータス・フレームが返送されたかどうか、判定ブロック７２０において、判定する。返送されている場合は、ブロック７２５において、高速書き込みコマンドに関して用いられたＲＸＩＤをリリース（開放）し、そして、該ＲＸＩＤを将来使用するために再度の関連付けを行う。
本発明の技術思想に係るオリジネータがコマンド／データ・フレームよりも長いデータの書き込みを実行したい場合、または、オリジネータがその割り当てられたＦＷ可能なＲＸＩＤ以外のものに進んだ場合は、書き込みコマンドの発生をデフォルトして、通常のプロセスに戻るために転送レディ・フレームを待機するだけでよい。これと同一のデフォルト・オプションを、ベンダ特定のＦＷ可能なオリジネータであって、異なるベンダからレスポンダへデータを転送したいオリジネータのために、備えることができる。
【００５６】
当業者には、本発明により、ファイバ・チャネル環境において用いられている従来例のデータ転送技術の問題点を十分に解消できることが、明らかであろう。本発明によれば、受信側デバイスへのデータの書き込みを極めて効果的に実行できる。このような改善された機能により、多数のイニシエータが存在しかつループ・レイテンシが大きい大規模ループにおいて、顕著に特性が向上する。
以上の説明から、本発明により、ＦＣ環境において多数のイニシエータの制御および管理を行う画期的な機構を提供することによって、従来技術の問題を首尾良く解決することができることは、当業者に明らかであろう。本発明のいくつかの実施例のみを添付図面に示し前述の詳細な説明に記載したが、本発明は開示した実施例に限定される訳ではなく、特許請求の範囲に記載しそれによって規定される本発明の精神から逸脱することなく、多数の再構成、変更および交換が可能である。
【図面の簡単な説明】
【図１】本発明を実施可能な、コンピュータ・システムの一例を示すブロック図である。
【図２】ファイバ・チャネル（ＦＣ）プロトコル・スタックを示す模式図である。
【図３】ファイバ・チャネル・ノードに使用可能な３種類のトポロジ構成を示すブロック図である。
【図４】（Ａ）は、ファイバ・チャネル環境において、イニシエータからターゲットへデータを転送するための、従来例の方式を説明するための図である。（Ｂ）は、ファイバ・チャネル環境において、イニシエータからターゲットへデータを転送するための、本発明の方式を説明するための図である。
【図５】本発明の技術思想に係る通信フレームの一部分を説明するための概念図である。
【図６】本発明の技術思想に係るファイバ・チャネル・デバイス用の交換識別子構造を説明するための概念図である。
【図７】本発明の技術思想に係る、オリジネータとレスポンダとの間でデータ書き込みを効果的に実行するためのプロセスを示すフローチャートである。

Claims

ファイバ・チャネル仲裁ループにおける書き込み機能を向上させるための方法において、
ターゲットにおける複数のレスポンダ交換識別子の所定の部分を、２以上のイニシエータの排他的使用のために割り当てるステップと、
前記複数のレスポンダ交換識別子に関連する情報を、前記２以上のイニシエータに送信するステップと、
前記２以上のイニシエータから前記ターゲットに、コマンドと前記所定の部分に含まれる１つのレスポンダ交換識別子が付加されているデータ・フレームとを一緒に送るコマンド送信ステップと、
前記コマンド送信ステップの完了を示すステータス・フレームを、前記ターゲットから前記２以上のイニシエータに送信するステップと
からなることを特徴とする方法。
請求項１記載の方法において、該方法は更に、前記２以上のイニシエータ中の複数のオリジネータ交換識別子の一部分を、前記複数のレスポンダ交換識別子の前記所定の部分に関連付けるステップを備えていることを特徴とする方法。
請求項１記載の方法において、該方法は更に、前記２以上のイニシエータによって、前記複数のレスポンダ交換識別子の前記所定の部分の使用を管理するステップを備えていることを特徴とする方法。