(57)【特許請求の範囲】
【請求項１】
複数のホストコンピュータと複数のストレージデバイスとを接続するストレージエリアネットワークにおけるストレージサーバであって、
該ストレージサーバは、
該複数のホストコンピュータと該複数のストレージデバイスとに関連付けられている複数のストレージプロセッサであって、該複数のストレージプロセッサのそれぞれは、マイクロエンジンを含み、該複数のストレージプロセッサのうちの第１のストレージプロセッサは、コマンドパケットと複数のデータパケットとを受信する、複数のストレージプロセッサと、
該複数のストレージプロセッサを接続するスイッチング回路と
を備え、
該第１のストレージプロセッサの該マイクロエンジンは、該コマンドパケットを受信すると、該受信されたコマンドパケットに基づいて、該複数のストレージプロセッサのうちの第２のストレージプロセッサを該コマンドパケットの目的地として識別するように構成されており、
該複数のデータパケットのうちのそれぞれ１つのデータパケットについて、
該第１のストレージプロセッサの該マイクロエンジンは、該１つのデータパケットの全体を受信する前に、該１つのデータパケットのヘッダを受信し、該１つのデータパケットの該ヘッダ以外の残りの部分を受信することと並行して、該コマンドパケットの目的地である該第２のストレージプロセッサを該１つのデータパケットの目的地として定義するように該ヘッダを改変し、該１つのデータパケットの全体の受信が完了した後に、該改変されたヘッダを有する該１つのデータパケットを該スイッチング回路に送信するように構成されており、
該スイッチング回路は、該第１のストレージプロセッサから送信された該１つのデータパケットを受信し、該受信された１つのデータパケットの該改変されたヘッダに基づいて、該受信された１つのデータパケットの目的地が該第２のストレージプロセッサであると決定し、該受信された１つのデータパケットを該第２のストレージプロセッサに送信するように構成されている、ストレージサーバ。
【請求項２】
前記第１のストレージプロセッサは、１つ以上の物理的なストレージデバイスへのアクセスを仮想化し、該１つ以上の物理的なストレージデバイスのそれぞれの少なくとも一部は、物理的なユニット番号（ＰＬＵＮ）によって表現されており、該第１のストレージプロセッサは、１つ以上の仮想的な論理ユニット番号（ＶＬＵＮ）とルックアップテーブルとを用いることによってアクセスを仮想化し、該ルックアップテーブルは、少なくとも１つのＶＬＵＮと１つ以上のＰＬＵＮとを関連付け、各ＶＬＵＮによって提供される仮想化されたストレージインタフェースを介して、該ＰＬＵＮの下にあるストレージへのアクセスを提供する、請求項１に記載のストレージサーバ。
【請求項３】
前記マイクロエンジンは、前記複数のストレージプロセッサのうちの１つのコンポーネントである、請求項１に記載のストレージサーバ。
【請求項４】
前記複数のストレージプロセッサのそれぞれは、複数のマイクロエンジンをさらに含む、請求項１に記載のストレージサーバ。
【請求項５】
前記複数のデータパケットは、前記複数のホストコンピュータのうちの１つから受信される、請求項１に記載のストレージサーバ。
【請求項６】
前記複数のデータパケットは、前記複数のストレージデバイスのうちの１つから受信される、請求項１に記載のストレージサーバ。
【請求項７】
前記複数のデータパケットは、前記複数のストレージデバイスのうちの１より多くのストレージデバイスから受信される、請求項１に記載のストレージサーバ。
【請求項８】
前記第２のストレージプロセッサは、前記複数のデータパケットを前記複数のホストコンピュータのうちの１つに送信する、請求項１に記載のストレージサーバ。
【請求項９】
前記第２のストレージプロセッサは、前記複数のデータパケットを前記複数のストレージデバイスのうちの１つに送信する、請求項１に記載のストレージサーバ。
【請求項１０】
前記第２のストレージプロセッサは、前記複数のデータパケットを前記複数のストレージデバイスのうちの１より多くのストレージデバイスに送信する、請求項１に記載のストレージサーバ。
【請求項１１】
前記第１のストレージプロセッサは、前記複数のホストコンピュータのうちの１つから前記コマンドパケットを受信する、請求項１に記載のストレージサーバ。
【請求項１２】
前記第１のストレージプロセッサは、前記複数のストレージプロセッサのうちの１つから前記コマンドパケットを受信する、請求項１に記載のストレージサーバ。
【請求項１３】
メモリをさらに備え、
前記コマンドパケットは、該メモリ内のホスト論理ユニット（ＨＬＵ）への参照であるコマンドハンドルを含み、前記第１のストレージプロセッサは、該コマンドハンドルを用いて、該メモリ内の該ホスト論理ユニット（ＨＬＵ）を求めてサーチを実行する、請求項１に記載のストレージサーバ。
【請求項１４】
メモリをさらに備え、
前記コマンドパケットは、該メモリ内のＩ／Ｏ制御ブロック構造への参照であるハンドルを含み、前記第１のストレージプロセッサは、該コマンドパケットを前記スイッチング回路を介して前記第２のストレージプロセッサに送信する、請求項１に記載のストレージサーバ。
【請求項１５】
前記第１のストレージプロセッサおよび前記第２のストレージプロセッサは、単一のストレージプロセッサである、請求項１に記載のストレージサーバ。
【請求項１６】
前記第１のストレージプロセッサの前記マイクロエンジンは、前記１つのデータパケットの前記ヘッダに埋め込まれたルーティングタグに従って該１つのデータパケットの該ヘッダを改変する、請求項１に記載のストレージサーバ。
【請求項１７】
構成コマンドを介して前記複数のストレージプロセッサのうちの１つにおいてルックアップテーブルをプログラムするように構成されている仮想サーバコントローラをさらに備え、
該ルックアップテーブルは、１つ以上の仮想的な倫理ユニット番号（ＶＬＵＮ）を１つ以上の物理的なユニット番号（ＰＬＵＮ）に関連付け、前記複数のストレージデバイスのそれぞれの少なくとも一部は、ＰＬＵＮによって表現されている、請求項１に記載のストレージサーバ。
【請求項１８】
複数のホストコンピュータと複数のストレージデバイスとの間にストレージサーバを有するストレージエリアネットワークにおいてデータをルーティングする方法であって、該ストレージサーバは、複数のストレージプロセッサと、該複数のストレージプロセッサを接続するスイッチング回路とを有し、該複数のストレージプロセッサのうちの第１のストレージプロセッサは、コマンドパケットと複数のデータパケットとを受信し、
該方法は、
該第１のストレージプロセッサが、該コマンドパケットを受信し、該受信されたコマンドパケットに基づいて、該複数のストレージプロセッサのうちの第２のストレージプロセッサを該コマンドパケットの目的地として識別することと、
該複数のデータパケットのうちのそれぞれ１つのデータパケットについて、
該第１のストレージプロセッサが、該１つのデータパケットの全体を受信する前に、該１つのデータパケットのヘッダを受信し、該１つのデータパケットの該ヘッダ以外の残りの部分を受信することと並行して、該コマンドパケットの目的地である該第２のストレージプロセッサを該１つのデータパケットの目的地として定義するように該ヘッダを改変し、該１つのデータパケットの全体の受信が完了した後に、該改変されたヘッダを有する該１つのデータパケットを該スイッチング回路に送信することと、
該スイッチング回路が、該第１のストレージプロセッサから送信された該１つのデータパケットを受信し、該受信された１つのデータパケットの該改変されたヘッダに基づいて、該受信された１つのデータパケットの目的地が該第２のストレージプロセッサであると決定し、該受信された１つのデータパケットを該第２のストレージプロセッサに送信することと
を包含する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本出願は、「Ｖｉｒｔｕａｌ  Ｓｔｏｒａｇｅ  Ｓｙｓｔｅｍｓ」と題された、２００１年２月１３日に出願された米国仮出願第６０／２６８，６９４号に対する優先権を主張し、この出願を本明細書中で参考として援用する。
【０００２】
（連邦政府によって支援された研究または開発下でなされた発明に関する権利についての記載）
該当なし
（「シーケンスリスト」、テーブル、またはコンパクトディスクで提出されたコンピュータプログラムリスト添付物への参照）
該当なし
（発明の背景）
本発明は、ストレージエリアネットワーク（ＳＡＮ）システムに関する。
【背景技術】
【０００３】
ストレージエリアネットワークすなわちＳＡＮは、サーバに接続されたストレージサブシステムのネットワークである。ＳＡＮの目的は、異なるオペレーティングシステム（Ｕｎｉｘ（Ｒ）、ＮＴ）の複数のサーバが１つの大きいデータレポジトリをそれぞれ「見る」ことを可能にすることである。ＳＡＮは、直接取り付けられたストレージによって４つの重要な利点を提供する。その利点は、ローカルエリアネットワークの利用の減少（帯域幅の増加）、信頼性の増加、管理可能性、および拡張性である。
【０００４】
ＳＡＮの現在のトレンドは、ストレージ仮想化である。ストレージ仮想化は、単一のセットの特性を有する単一のストレージプールとして複数の別個の物理ストレージデバイスをユーザに提示するプロセスを説明する。例えば、ホストコンピュータをストレージデバイスに接続するストレージエリアネットワークにおいて、ユーザは、規定された信頼性を有するディスク空間（例えば、ＲＡＩＤ１において１００ＧＢ）の単一のブロックを認識するが、データが単一のＲＡＩＤ１ディスクアレイに格納されるか、または複数の別個のディスクを介して分割されるかどうかにかかわらず、ＲＡＩＤ１において１００ＧＢが提供されるように、ユーザのホストコンピュータがストレージデバイスにアクセスするように構成される。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ＳＡＮを仮想化するために今日市場において利用可能なほとんどのソリューションは、ソフトウエアベースである。ホストベース、ストレージベース、およびＳＡＮベースのソリューションが存在する。ホストベースのソリューションに対して、各ホストコンピュータは、ストレージエリアネットワークに接続されたストレージデバイスに気付かなければならない。なぜなら、各ホストコンピュータは、そのユーザに提示されるストレージ仮想化を管理するためである。ストレージエリアネットワークに接続されたストレージデバイスが改変される場合（新しいデバイスが追加されるか、または既存のデバイスが除去される等）、各ホストコンピュータは、この改変に適応するように再構成されなければならない。このような再構成は、ネットワークアドミニストレータによる作業を含み、エラーの傾向がある。このストレージベースのソリューションは、同様の問題を有する。このＳＡＮベースのソリューションは、ホストおよびストレージベースのソリューションより良好であるが、拡張性および性能が欠如している。
【０００６】
本発明は、この領域および他の領域における改良に関する。
【課題を解決するための手段】
【０００７】
（発明の簡単な要旨）
本発明の一実施形態によると、ストレージエリアネットワークにおけるストレージサーバは、ホストコンピュータおよびストレージデバイスを接続する。このストレージサーバは、スイッチング回路によって相互接続されるストレージプロセッサを含む。ストレージサーバはまた、コマンドパケットに基づく２つのストレージプロセッサ間のパスを構成するプロセッサを含む。次いで、データは、多くの既存のシステムにおいてより迅速にパス上にルーティングされる。一実施形態では、ルーティングタグは、データパケットに関連付けられ、ストレージプロセッサは、全体のデータパケットが受信されるまで待つことなくルーティングタグを調査し、１つのストレージプロセッサは、全体のデータパケットを調査または受け取らせることなく、ルーティングタグに従って、データパケットを別のストレージプロセッサにルーティングする。
【０００８】
本発明のより十分な理解は、以下の図面およびそれに関連して詳説された図面を参照することによって得られ得る。
【発明を実施するための最良の形態】
【０００９】
（発明の詳細な説明）
詳細な説明は以下のように体系化される。第１に、概観が本発明をインプリメントする全体のシステムに与えられる。第２に、本発明の特徴の高レベルな説明が提供される。最後に、本発明の特徴をさらに詳説する低レベルな詳細の支援が提供される。
【００１０】
（概観）
図１は、本発明の実施形態によるストレージサーバ１００を示す。この図はまた、ストレージエリアネットワーク（ＳＡＮ）１０２、複数の物理ストレージデバイス１０４、および複数のホストコンピュータ１０６を示す。
【００１１】
ストレージサーバ１００はまた、Ｖｉｒｔｕａｌ  Ｓｔｏｒａｇｅ  Ｅｘｃｈａｎｇｅ（ＶＳＸ）またはＣｏｎｆｌｕｅｎｃｅ  Ｖｉｒｔｕａｌ  Ｓｔｏｒａｇｅ  Ｓｅｒｖｅｒ（ＣＶＳＳ）と呼ばれ、図２Ａにおいてさらに詳説される。このストレージサーバ１００は、同種のおよび異種の環境においてサーバにストレージ仮想化を提供し、ネットワークストレージの領域における大規模データセンター（ＩＳＰ、ＳＳＰ、およびＡＳＰ）にソリューションを提供する。
【００１２】
ＳＡＮ１０２は、コンピュータネットワークの任意のタイプであり得る。本出願では、ＳＡＮ１０２は、ストレージエリアネットワークと呼ばれる。なぜなら、本発明の実施形態に関する関連機能であるためである。本発明の実施形態では、ＳＡＮ１０２は、ファイバチャンネルネットワークであり、ホストコンピュータ１０６およびストレージデバイス１０２は、ファイバチャンネルネットワークと通信するように構成され、そしてストレージサーバ１００はまた、ファイバチャンネルネットワークと通信するように構成される。従って、ストレージサーバ１００は、既存のＳＡＮに容易に追加され得る。
【００１３】
物理ストレージデバイス１０４は、テープドライブ、ディスクアレイ、ＪＢＯＤ（「ｊｕｓｔ  ａ  ｂｕｎｃｈ  ｏｆ  ｄｉｓｋｓ」）、またはデータストレージデバイスの他のタイプを含む。物理ストレージデバイス１０４は、ＳＡＮ１０２を介してホストコンピュータ１０６に直接的に接続されてもよいし、ＳＡＮ１０２およびストレージサーバ１００を介してホストコンピュータ１０６に間接的に接続されてもよい。発明の背景で上述したように、ストレージ仮想化の管理は、ストレージデバイス１０４がＳＡＮ１０２を介してホストコンピュータ１０６に直接的に接続される場合には、面倒になる。本発明は、ストレージサーバ１００を用いて、ストレージデバイス１０４をホストコンピュータ１０６に間接的に接続することによってストレージ仮想化の管理を改善する。
【００１４】
ホストコンピュータ１０６は、サーバであってもよいし、スタンドアロン型コンピュータであってもよい。このホストコンピュータ１０６は、ＳＡＮ１０２に直接接続されてもよいし、スイッチ、ルータ、または他の通信リンクを介して間接的に接続されてもよい。
【００１５】
図２Ａは、本発明の実施形態に関連するハードウエアコンポーネントを示すストレージサーバ１００のブロック図であり、このストレージサーバは、ストレージプロセッサ１１０、ラインカード１１２、仮想サーバカード１１４、およびスイッチファブリック１１６を含む。
【００１６】
ストレージサーバ１００は、１つ以上のストレージプロセッサ１１０を含み得る。このストレージプロセッサ１１０は、情報がホストコンピュータ１０６とストレージデバイス１０４との間を流れる場合、格納されるストレージデータコマンドおよびデータを処理する。１つ以上のストレージプロセッサ１１０は、各ラインカード１１２に含まれ得る。このストレージサーバ１００は、多数のラインカード１１２のためのスペースを含むことにより、ストレージサーバ１００の能力は、より多くのラインカード１１２またはより多くのプロセッサ１１０を追加することによってモジュラー式に増加され得る。各ストレージプロセッサ１１０は、ストレージサーバ１００の１つ以上のポートに関連付けられる。
【００１７】
ストレージサーバ１００は、１つ以上の仮想サーバカード１１４を含み得る。仮想サーバカードは、ストレージサーバ１００の動作を制御し、ラインカード１１２を制御し、ラインカード１１２は、コマンドおよびデータの転送の実際の作業を実行する。
【００１８】
スイッチファブリック１１６は、ストレージプロセッサ１１０を接続する。このスイッチファブリックは、１つのポートにおいて受信された情報をストレージサーバ１００の別のポートに切り替える。例えば、ホストコンピュータ１０６がストレージエリアネットワーク１０２上に格納されたデータを読み出すことを望む場合、そのリクエストは、ホストコンピュータ１０６に関連付けられたポートに関連付けられたストレージプロセッサ１１０によって処理される。このストレージプロセッサ１１０は、上流ストレージプロセッサ１１０と呼ばれる。この上流ストレージプロセッサ１１０は、ストレージデバイス１０４に関連付けられたポートに関連付けられた下流ストレージプロセッサ１１０と通信して、スイッチファブリック１１６を介して読み出されるべきデータを格納する。次いで、スイッチファブリック１１６は、下流および上流ストレージプロセッサ１１０を介して、ストレージデバイスから読み出されたデータをホストコンピュータ１０６に転送する。
【００１９】
図２Ｂは、本発明の実施形態に関する機能性を示すストレージサーバ１００のブロック図である。ストレージサーバ１００の機能は、１つ以上のコンピュータプログラム、マイクロコードセグメント、ハードウエア構造、またはこれらの組み合わせに従って処理を実行する１つ以上のプロセッサによってインプリメントされ得る。本発明に関する機能は、メディアユニット（ＭＵ）マネージャ１２０、仮想論理ユニット数（仮想ＬＵＮまたはＶＬＵＮ）マネージャ１２２、物理論理ユニット数（物理ＬＵＮまたはＰＬＵＮ）マネージャ１２４である。ストレージサーバ１００のさらなる詳細は、本発明の譲受人に譲受され、２００２年２月１３日に出願された、上記仮出願第６０／２６８，６９４号からの利益を主張する他の出願において提供され、本明細書中で参考として援用する。この他の出願は、「Ｓｔｏｒａｇｅ  Ｖｉｒｔｕａｌｉｚａｔｉｏｎ  ａｎｄ  Ｓｔｏｒａｇｅ  Ｍａｎａｇｅｍｅｎｔ  ｔｏ  Ｐｒｏｖｉｄｅ  Ｈｉｇｈｅｒ  Ｌｅｖｅｌ  Ｓｔｏｒａｇｅ  Ｓｅｒｖｉｃｅ」と題された代理人事件番号第２０９４９Ｐ−０００３００ＵＳ、「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｉｄｅｎｔｉｆｉｎｇ  Ｓｔｏｒａｇｅ  Ｄｅｖｉｃｅ」と題された代理人事件番号第２０９４９Ｐ−０００５００ＵＳ、
「Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｐｏｌｉｃｙ  Ｂａｓｅｄ  Ｓｔｏｒａｇｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ  ａｎｄ  Ｍａｎａｇｅｍｅｎｔ」と題された代理人事件番号第２０９４９Ｐ−０００６００ＵＳ、「Ｖｉｒｔｕａｌ  Ｄａｔａ  Ｃｅｎｔｅｒ」と題された代理人事件番号第２０９４９Ｐ−０００７００ＵＳ、「Ｆａｉｌｏｖｅｒ  Ｐｒｏｃｅｓｓｉｎｇ  ｉｎ  ａ  Ｓｔｏｒａｇｅ  Ｓｙｓｔｅｍ」と題された代理人事件番号第２０９４９Ｐ−０００８００ＵＳ、「ＲＡＩＤ  ａｔ  Ｗｉｒｅ  Ｓｐｅｅｄ」と題された代理人事件番号第２０９４９Ｐ−０００９００ＵＳ、および「Ｍｅｔｈｏｄ  ｆｏｒ  Ｄｅｖｉｃｅ  Ｓｅｃｕｒｉｔｙ  ｉｎ  ａ  Ｈｅｔｅｒｏｇｅｎｅｏｕｓ  Ｓｔｏｒａｇｅ  Ｎｅｔｗｏｒｋ  Ｅｎｖｉｒｏｎｍｅｎｔ」と題された代理人事件番号第２０９４９Ｐ−００１０００ＵＳである。
【００２０】
ＰＬＵＮマネージャ１２４は、ストレージデバイス１０４におよびストレージデバイス１０４からデータおよびコマンド転送を管理する。各ストレージデバイス１０４は、各特定のストレージデバイス１０４を識別するために使用されるＰＬＵＮをそのデバイスに関連付け得る。
【００２１】
ＶＬＵＮマネージャ１２２は、ホストコンピュータ１０６におよびホストコンピュータ１０６からデータおよびコマンド転送を管理する。各ホストコンピュータ１０６は、１つ以上のＶＬＵＮに関連付けられ得る。各ＶＬＵＮは、仮想アドレス空間（例えば、ストレージのギガバイト）を定義された属性（例えば、性能パラメータ、信頼性レベル等）を用いて表す。このように、各ホストコンピュータ１０６は、特定のＶＬＵＮを参照して、データおよびコマンドをストレージサーバ１００と交換する。
【００２２】
ＭＵマネージャ１２０は、基本的にＶＬＵＮとＰＬＵＮとの間で移動する。ＭＵマネージャ１２０は、ストレージサーバ１００に接続されたストレージデバイス１０４（物理ＬＵＮ）の全てのアドレス空間を管理することに責任がある。ＭＵマネージャ１２０はまた、ストレージサーバ１００内部で構築されたストレージ構成のアドレス空間を管理し、ＭＵマネージャは、スライス、連結、ＲＡＩＤ０（ストライプ）、およびＲＡＩＤ１（ミラー）を含む。
【００２３】
ＭＵマネージャ１２０は、下にあるストレージ構成または物理ＬＵＮにもかかわらず、アドレス空間が論理的な態様で処理されることを可能にする抽出ブロックストレージアドレシング技術を使用する。これらの論理アドレス空間は、より複雑かつ特徴的なストレージ構成と共に結合され得る。これらの論理アドレス空間はまた、抽出ブロックストレージアドレス空間として簡単に処理される。
【００２４】
仮想ＬＵＮと共に使用されることによって、これらの論理アドレス空間は、マルチポートストレージデバイス上にＬＵＮとして現れるように構成され得る。仮想デバイス上の論理アドレス空間として物理ＬＵＮを提示させるこのプロセスは、ストレージ仮想化と呼ばれる。
【００２５】
抽出ブロックストレージアドレシングは、メディアユニット（ＭＵ）として公知のデータ構造を介して達成される。
【００２６】
図３は、物理メディアユニットと他のサービスとの間の関係を示す。ＰＬＵＮマネージャ１２４はＰＬＵＮを管理し、ＭＵマネージャ１２０は、メディアユニットを管理し、そしてＶＬＵＮマネージャ１２２は、ＶＬＵＮを管理する。
【００２７】
さらに、図３は、ＰＬＵＮ、メディアユニット、およびＶＬＵＮとの間の関係を示す。一般的に、ＰＬＵＮは、ストレージデバイス（ディスクまたはディスクアレイ等）に直接対応する。このような直接的一対一は、概して以下の図に示された関係である。しかし、ＰＬＵＮはまた、ストレージデバイスの一部に関連付けられ得る。多重ＰＬＵＮは、単一のストレージデバイスの異なる部分に関連付けられ得る。
【００２８】
各物理メディアユニット（第１レベルのメディアユニット）は、概して単一の各ＰＬＵＮに直接的に対応する。
【００２９】
各ＶＬＵＮは、概して単一の各メディアユニットに関連付けられる。
【００３０】
以下のセクションは、本発明のいくつかの局面をさらに説明する。
【００３１】
（高レベルな説明）
一実施形態によると、ストレージエリアネットワークは、ファイバチャンネルネットワークであり、ストレージサーバ１００は、ストレージサーバ１００による内部処理のための第２のフォーマットにファイバチャンネルフレームを変換する複数のファイバチャンネルＡＳＩＣを含む。これらのファイバチャンネルＡＳＩＣは、仮出願第６０／３１７，８１７においてさらに説明される。
【００３２】
図４は、上流および下流ストレージプロセッサ１１０およびファイバチャンネルＡＳＩＣ１４０を示すブロック図である。用語、「上流」は、ホストコンピュータ１０６に最も近いコンポーネントを指すために使用され、用語「下流」は、ストレージデバイス１０４に最も近いコンポーネントを指すために使用される。一実施形態によると、各ストレージプロセッサ１１０は、４つの１ＧＢ／ｓファイバチャンネルポートを接続するためにファイバチャンネルＡＳＩＣを使用する。
【００３３】
図５は、本発明の実施形態による読み出しプロセス２００のフローチャートである。概して、読み出しおよび書き込みトラフィックは、ストレージプロセッサ１１０によって処理される。ストレージプロセッサにおける専用ハードウエア（マイクロエンジンと呼ばれる）は、これらの処理ステップをインプリメントするために使用され得る。これらのストレージプロセッサは、一般的に仮想化エンジンと呼ばれる。読み出し／書き込みでないコマンドは、埋め込まれたＣＰＵによって処理され得る。
【００３４】
ステップ２０２では、ホストコンピュータ１０６は、ストレージエリアネットワーク１０２を介してストレージサーバ１００に読み出しコマンドを送信する。この読み出しコマンドは、コマンドパケットの形態であり得る（コマンドフレームとも呼ばれる）。この読み出しコマンドは、ストレージサーバ１００に到達し、上流ファイバチャンネルＡＳＩＣによって処理される。
【００３５】
ステップ２０４では、コマンドは上流ストレージプロセッサに到達する。このコマンドは、コマンド処理として参照されるものを含む。この上流ストレージプロセッサは、ツリー検索エンジンを用いてコマンド処理からホストＬＵを検索する。ホストＬＵから、上流ストレージプロセッサは、仮想ユニットを見出し、このリクエストを物理ユニットに分解することを開始する。
【００３６】
ツリー検索エンジンは、ルックアップテーブルにおけるホストＬＵを参照する。このルックアップテーブルは、仮想情報を含む。すなわちこの情報は、仮想ストレージ空間（ホストコンピュータが参照する）を物理ストレージ空間（複数の物理ディスクによって提供され得る）に関連付ける情報である。このルックアップテーブルは、構成コマンドを用いてＶＳＣ１１４（図２Ａ参照）によってプログラムされる。
【００３７】
ステップ２０６では、上流ストレージプロセッサは、話す（ｔａｌｋ）ためのデバイスを識別するために、スイッチング回路を介してハンドルを下流ストレージプロセッサに送る。
【００３８】
ステップ２０８では、ハンドルは下流ストレージプロセッサに到達する。
【００３９】
ステップ２１０では、下流ストレージプロセッサは、送られたハンドルからコマンドを正しい物理ディスクに送信する。下流ストレージプロセッサは、ルーティングタグおよびストレージプロセッサコマンドハンドルと共にコマンドを送信する。このルーティングタグおよびＳＰコマンドハンドルは、データフレーム（またはデータパケット）が戻る場合に使用される。上記ステップ２０６〜２１０は、結局上流ストレージプロセッサと下流ストレージプロセッサとの間のパスを構成する。
【００４０】
ステップ２１２では、物理ディスクは、ストレージエリアネットワークを介してデータフレーム（データパケット）をストレージサーバ１００に戻すように送信する。
【００４１】
ステップ２１４では、下流ファイバチャンネルＡＳＩＣは、データフレームを受信する。下流ファイバチャンルＡＳＩＣは、交換管理を実行し、コマンドコンテクストを参照する。
【００４２】
ステップ２１６では、下流ファイバチャンネルＡＳＩＣは、ルーティングタグおよびＳＰコマンドハンドルと共にデータフレームを送信する。
【００４３】
ステップ２１８では、下流ストレージプロセッサは、データフレームを受信する。このルーティングタグは、全パケットが到着する前であっても、下流ストレージプロセッサが
フレームを上流ストレージプロセッサに（スイッチング回路を介して）ルーティングすることを可能にする。一実施形態によると、最初の６４バイトのデータフレームは、全体のペイロードが到着する前に検査される。
【００４４】
ステップ２２０では、データパケットは、上流ストレージプロセッサに到着する（スイッチング回路を介して）。上流ストレージプロセッサは、データコンテクストを参照し、データフレームがコマンドコンテクストを獲得することを可能にするように、対応するファイバチャンネルＡＳＩＣコマンドハンドルと共にデータフレームを外部に送信する。
【００４５】
ステップ２２２では、上流ファイバチャンネルＡＳＩＣは、交換管理（コマンドハンドルを用いて）を実行し、ストレージエリアネットワーク１０２を介してデータフレームをホストコンピュータ１０６に送信する。
【００４６】
特に図４は、読み出しプロセスに関するが、書き込みプロセスは同様のステップを含む。
【００４７】
別の実施形態によると、ストレージサーバ１００は、コマンドを内部に生成し得る。データが１つのストレージデバイスから別のデバイスに転送される場合、またはデータが第２のストレージデバイス上で複製または再構成される場合、コマンドが内部で生成され得る。
【００４８】
別の実施形態によると、ホストコンピュータおよびストレージデバイスは、同じストレージプロセッサに接続され得る。このような場合、上流および下流ストレージプロセッサは、同じストレージプロセッサである。
【００４９】
これらの処理のより拡張的な詳細を以下に示す。
【００５０】
（低レベルな詳細）
上述のように、ストレージサーバ１００はまた、Ｖｉｒｔｕａｌ  Ｓｔｏｒａｇｅ  Ｅｘｃｈａｎｇｅ（ＶＳＸ）と呼ばれ、これは、冗長スイッチング回路によって内部接続された多重ストレージプロセッサ（ＳＰ）を含む。このＶＳＸはまたこれらのＳＰの構成および管理のために少なくとも１つのＣＰＵを有する。このＣＰＵはまた、より高いレベルのストレージサービスを提供する。
【００５１】
ＳＣＳＩ処理はＳＰによって処理される。各ＳＰは、以下のコンポーネントを有する。
【００５２】
１．読み出し／書き込みコマンドを処理する１６マイクロエンジン
２．エラー復元を含む非読み出し／書き込みコマンドの全てを処理する埋め込まれたＣＰＵ
３．フレームタイプを識別するハードウエアクラシファイア（Ｃｌａｓｓｉｆｉｅｒ）
４．マイクロエンジンにおいて実行している正しいマイクロコードハンドラに対するフレームにキューを入れるためのディスパッチユニット
５．所与のパターンのためのリーフエントリを見出すためのツリー検索エンジン
６．統計収集（一実施形態では４Ｍカウンタまで）を可能にするコプロセッサであるカウンターエンジン
７．スイッチング回路（スイッチファブリックとも呼ばれる）にＳＰを接続させるスイッチインターフェース
読み出し／書き込みコマンドは、マイクロエンジンによって処理される。ＲＤ／ＷＲコマンド処理は、以下にさらに説明される。
【００５３】
コマンドが上流ＳＰにおいて受信され、上流ＳＰは、ほとんどのコマンドの処理を行う。上流ＳＰは、コマンド／アクセス制御を認証し、コマンドを運ぶ場所を決定し、新しい開始論理ブロックアドレス（ＬＢＡ）およびリクエストブロックを計算し、新しいコマンドデータブロック（ＣＤＢ）を構築し、そしてそれを下流ＳＰに運ぶ。ターゲットデバイスに到達する１つのみのパスが存在する場合、上流ＳＰは完全なコマンドを構築し、次いで、下流ＳＰおよびＦＣ−ＡＳＩＣを介してターゲットデバイスに転送される。下流ＳＰがターゲットデバイスに到達するいくつかのパスを有する場合、上流ＳＰは、アクセス経路を選択するために下流デバイスまで離れる。この場合、下流ＳＰは、アクセスパスに関する適切な情報で満たし、その情報をターゲットデバイスにＦＣ−ＡＳＩＣを介して転送する。
【００５４】
コマンドフレームがＳＰに入る場合、入来コマンドハンドラ（マイクロエンジンにおいて実行している）が呼び出される。このコマンドハンドラー（ＣｍｄＨａｎｄｌｅｒ）は、ＩＯ制御ブロック（ＩｏＣＢ）構造を割り当て、コマンドコンテクストを格納し、コマンドのステータスを追跡する。コマンド情報から、ＣｍｄＨａｎｄｌｅｒは、ＳＰポート、ＦＣ−ＡＳＩＣデバイスハンドル、およびＦＣ  ＬＵＮ（論理ユニット数）を含む検索キーを構成する。この検索キーは、ＳＰツリー検索エンジン（ＴＳＥ）に送られ、このコマンドに関連付けられたハードウエアＬＵＮ（ＨＬＵＮ）を検索する。この検索が失敗する場合、コマンドは存在しないＬＵＮにより拒絶され、他の場合にはコマンド処理が継続する。ＨＬＵＮはサーバおよび仮想ＬＵＮ（ＶＬＵＮ）を結合する構造であり、それにより関連付けられたＶＬＵＮ構造は、ＨＬＵＮ情報を介して取り出され得る。
【００５５】
受信されたコマンドおよびＶＬＵＮ情報においてリクエストされたブロックの開始ＬＢＡ／数に基づいて、ＣｍｄＨａｎｄｌｅｒは、受信されたコマンドを物理コマンドのセットに分解する（このセットは上記情報に依存する１つ以上のコマンドであり得る）。１つより多い物理コマンド（ｐＣｍｄ）が分解される場合、各ｐＣｍｄは、ｐＣｍｄ自体のコマンドコンテクストを格納するために使用されるｐＣｍｄ自体のＩｏＣＢ（子ＩｏＣＢまたはｃＩｏＣＢと呼ばれる）を有する。これらのｃＩｏＣＢは、元のＩｏＣＢ（マスターＩｏＣＢまたはｍＩｏＣＢと呼ばれる）にリンクされる。以後、ＣｍｄＨａｎｄｌｅｒは、物理ターゲットデバイスにマッピングされる物理開始ＬＢＡおよび複数のブロックを用いるこれらのコマンドを構築する。次いでこれらのコマンドは、ターゲットデバイスに直接接続する下流ＳＰに送信される。ＩｏＣＢに対する参照はまた、このコマンドに関連付けられたＩｏＣＢを位置決定するために使用されるコマンドハンドル（上流コマンドハンドルおよび下流コマンドハンドル）として、上流ＳＰと下流ＳＰとの間に送られる。
【００５６】
上述したように、下流ＳＰは、ターゲットデバイスへの１つより多くのアクセスパスを有し得る。単一のアクセスパスが存在する場合、ｐＤｅｖＰａｔｈキーが上流ＳＰから下流ＳＰに送られる。他の場合、ｐＬＵＮキーが送られる。マルチパスシナリオでは、下流ＣｍｄＨａｎｄｌｅｒは、物理ＬＵＮ（ＰＬＵＮ）を検索し、アクセスパス（ｐＤｅｖＰａｔｈ）を選択する。これは別の検索を導く。単一のパスシナリオでは、下流ＣｍｄＨａｎｄｌｅｒは、ターゲットデバイスにアクセスするための重要な情報を得るために直接ｐＤｅｖＰａｔｈを検索する。
【００５７】
図６は、読み出し／書き込みコマンド処理の高レベルなフローチャートを示す。上流パスでは、ツリー検索エンジン（ＴＳＥ）は、ＨＬＵＮ、ＶＬＵＮ、ＰＬＵＮｎｐ、およびｐＤｅｖＰａｔｈを示す。
【００５８】
下流パスでは、第１に、ＭＰＡＴＨ＿ＢＩＴがチェックされる。ＭＰＡＴＨ＿ＢＩＴが明らかである場合、下流ＰＬＵＮは多重パスを有さない。次いでこの下流ＳＰは、ｐＤｅｖＰａｔｈテーブルへの検索を発行する。ＭＰＡＴＨ＿ＢＩＴが設定される場合、検索は、ＰＬＵＮテーブル上でなされる。このＰＬＵＮリーフは、ストレージへの可能な経路の全てを有する。
【００５９】
図７は、本発明の実施形態によるルーティング情報３１０（図８および図９も参照）のデータ図を示す。このルーティング情報３１０は、ＦＣ  ＡＳＩＣとＳＰとの間で使用される。
【００６０】
コマンドを受信すると、コマンドハンドラは、適切なアクセスパスを決定するために、コマンド情報およびプログラムされたＶＬＵＮ情報に基づく。一旦、アクセスパスが決定されると、全ての以後のフレーム（転送準備中、データ、およびステータス）が同じパス上に転送される。すなわち、マイクロコードは、フレームルーティングプロセスをスピードアップするために使用されるルーティング情報フィールドを加える。このルーティング情報は、フレーム内に埋め込まれる。これは、ＳＰマイクロコードがＩｏＣＢ構造を最初に参照することなしで、受信されたフレームから直接ルーティング情報を獲得することを可能にする。ルーティング情報がフレームの最初の６４バイト内にあるために、ピココード（ｐｉｃｏｃｏｄｅ）がどのようにしてフレームをルーティングするかを調べることを開始し得る。これは、性能を改善する。
【００６１】
ルーティング情報は、以下のアイテムを含む。
【００６２】
１．ブレード数：ターゲットＳＰスイッチブレード数
２．ＱＩＤ：フレームをＳＰスポットにルーティングするためのＳＰ  ＥＮＱコプロセッサによって使用される暗号化された値
３．ＦＣＡポート：ＦＣ  ＡＳＩＣポート数
４．ＤＭＵ：フレームをＳＰポートにルーティングするためにＳＰ  ＥＮＱコプロセッサによって使用されるデータムーバユニット
５．ＤＳＵ：フレームをＳＰポートにルーティングするためにＳＰ  ＥＮＱコプロセッサによって使用されるデータ格納ユニット
ルーティング情報フィールドはＤＳＴおよびＳＲＣの２つの部分からなる。ＦＣ  ＡＳＩＣはこのルーティング情報を与え、ＦＣ  ＡＳＩＣがデータ、ステータス、または制御フレームを送信する場合、この情報を改変されていないＳＰに戻す。
【００６３】
ＳＰは、ＤＳＴルーティング情報フィールドを調べて、フレームをルーティングするためにＦＣＢページレジスタをプログラムする。
【００６４】
ルーティング情報におけるフィールドのための省略は以下に示される。
【００６５】
１．ＴＢがターゲットブレードを識別する。これは、入来ＦＣＢページレジスタにプログラムされる。
【００６６】
２．ＱＩＤが出力（Ｅｇｒｅｓｓ）ＦＣＢページＱＩＤフィールドを満たす場合、ＱＩＤがターゲットＳＰにおいて使用される。
【００６７】
３．ＦＣＡポートは、ターゲットＳＰにおけるＦＣＡＳＩＣポート識別子である。
【００６８】
４．ＤＭＵは、ターゲットＤＭＵを識別する。これは、入来ＦＣＢページレジスタにプログラムされる。
【００６９】
５．ＤＳＵは、使用するためにターゲットＤＳＵを識別する。これは、入来ＦＣＢページレジスタにプログラムされる。
【００７０】
コマンドが上流ＳＰに入る場合、ＳＲＣルーティング情報フィールドが満たされる。次いでこのコマンドは、下流ＳＰに運ばれる。下流ＳＰは、ＤＳＴルーティング情報フィールドで満たす。コマンドをＦＣＡＳＩＣに運ぶ前に、ＳＲＣおよびＤＳＴルーティング情報フィールドが交換される。
【００７１】
ＦＣＡＳＩＣがデータ、制御、またはステータスと共に戻る場合、ルーティング情報は、このままで戻される。ＳＰは、ＤＳＴルーティング情報を調べる。ＳＲＣおよびＤＳＴが以前のステップで交換されるために、ＤＳＴルーティング情報は、ここで、上流ＳＰを識別する。このフレームは、上流ＳＰに直接ルーティングされ得る。
【００７２】
上流ＳＰにおいて、ＤＳＴルーティング情報からのフィールドは、フレームを外部に直接送信するために使用される。フレームを外部に送信する前に、ＳＲＣおよびＤＳＴルーティング情報フィールドが交換される。
【００７３】
このストレージプロセッサは、ピココードと呼ばれるプログラミングコードに従って動作する。以下の図および関連した説明は、ピココードおよび関連した本発明の実施形態を詳説する。
【００７４】
図８は、ＰＰＰフォーマットで封入されたコマンドフレーム３００を示す。これは、ピココードによって利用された一般的なフレームフォーマットである。ＳＰを入力するＦＣフレームは、イーサネット（Ｒ）フレーム内に封入される。ＳＰハードウエアクラシファイアは、どのルーチンを呼び出すかを決定するためにＰＲＯＴＯＣＯＬフィールドを調べる。このサブタイプは、ＰＯＳフレームタイプをさらに区別するためにマイクロコードによって使用される。
【００７５】
図９は、ＴＡＧＳフィールド３０２のフォーマットを示す。コマンドフレーム３００におけるＴＡＧＳヘッダー３０２が、コマンドコンテクストを獲得するためにＳＰ間の固有の識別子を運ぶために使用される。このＴＡＧフィールド３０２は、以下のデータフィールドを含む。
【００７６】
ＦＣハンドル３０４は、そのコマンドハンドルを獲得するためにＦＣ  ＡＳＩＣによって使用されたハンドルである。
【００７７】
ＳＰクオリファイア３０６およびＳＰハンドル３０８は、ＦＣ  ＡＳＩＣによって単一のハンドルとして解釈される。ＳＰハンドル３０８は、そのコマンドコンテクストを獲得するためにＳＰによって使用される。
【００７８】
ｒｏｕｔｅｉｎｆｏフィールド３１０は、ＳＰによってＲＤＹ／ＡＣＫフレームにおけるＦＣ  ＡＳＩＣに送信される。ＦＣ  ＡＳＩＣは、好ましくは、最新のフィールドを送信する。
【００７９】
ｃｔｒｌフィールド３１２は、汎用フィールドである。
【００８０】
ｆｒａｍｅｌｄ３１４は、連続的に増加する数である。その使用は、単一のシーケンスにおけるＳＥＱ＿ＣＮＴと同様である。
【００８１】
ポート３１６は、ポートを識別する。
【００８２】
ｐｌＳｚＦｉｌｌＢｓｔ（ペイロードサイズ／充填ビット）３１８は、ＦＣ  ＡＳＩＣによって挿入される。フィールドは、フレームタイプに依存する異なる意味を有する。フレームを受信するために、このフィールドは、ペイロードの全バイトカウントを示す。フレームを送信するために、このフィールドは、どれくらいの数のビットが最後のデータワードに満たされたかを示す。
【００８３】
ｒｅｌＯｆｆｓｅｔ３２０は、データペイロードに対して相対的なオフセットを示す。受信フレーム（ＳＰの観点では）において有効であるのみである。
【００８４】
ポートハンドル３２２は、ＳＰがコマンド記述子を下流に（ｄｏｗｎ）送信する場合、ＳＰが話すことを望むデバイスを識別するために使用される。
【００８５】
ＤｅｖＨａｎｄｌｅ３２４は、デバイスハンドルを格納するために使用される。これは、コマンドを特定のデバイスにマッピングするためにＦＣ  ＡＳＩＣによって使用される。その利用は、Ｓ＿ＩＤおよびＤ＿ＩＤと同様である。
【００８６】
ｒｓｖｄフィールド３２６は使用されない。
【００８７】
本発明の実施形態によると、３つのタイプのデータフレーム（ＣＯＭＭＡＮＤ、ＤＡＴＡ、およびＳＴＡＵＳ）がある。イーサネット（Ｒ）ヘッダにおけるタイプフィールドは、３つのタイプを区別するために特別に定義されたコードに設定される。ＳＰにおけるこのハードウエアクラシファイアは、正確なエントリポイントを呼び出すためにこのフィールドを使用する。
【００８８】
ＳＰピココードは、仮想化されたデバイスに対するＲＤおよびＷＲコマンドタイプを処理する。他のコマンドは、処理するためにＳＰに送信される。ネイティブデバイスの場合、ＳＰピココードは、保存、放出コマンドを除いたデバイスに全てのコマンド／フレームを転送する。ピココードによって処理されたコマンドタイプの数は小さいが、トラフィックの大部分はＲＤ／ＷＲコマンドである。
【００８９】
図４を参照して上述されたように、本明細書は、用語上流および下流を使用する。上流は、サーバに接続されるＳＰを説明するために使用される。これは、コマンドを参照するＳＰである。下流が、ターゲットデバイスに接続されるＳＰを説明するために使用される。上流ＳＰデバイスは、コマンドを受け取り、それを処理し、そしてそれを下流ＳＰに送信する。この下流ＳＰは、コマンドを受け取り、それをターゲットデバイスに送信する。
【００９０】
上流ＳＰは、コマンドのほとんどの処理を行う。上流ＳＰは、コマンドを運ぶ場所を決定し、新しい開始論理ブロックアドレス（ＬＢＡ）およびリクエストされたブロックを計算し、新しいＣＤＢを構築し、それを下流ＳＰに運ぶ。下流ＳＰは、ＦＣヘッダーに注意を払い、どのポートがコマンドフレームを外部に送信するかを決定し、そしてターゲットデバイスへの順序管理を処理する。
【００９１】
上流のコマンドフレームは、以下のように処理される。
【００９２】
コマンドフレームがＳＰを入力する場合、入力コマンドハンドラが呼び出される。コマンドフレームは、新しいＦＣ交換の一部である。ＩｏＣＢ構造は、新しいコマンドに割り当てられる。ＩｏＣＢ構造は、新しいコマンドの状態を追跡するために使用される。コマンドフレームのセクションは、順序管理を実行するためにＩｏＣＢに保存される。本発明の一実施形態によると、コマンドフレームは、典型的には８２バイトである。
【００９３】
ＦＣＰＭソフトウエアモジュールは、ＩｏＣＢ割り当ておよびコマンドの保存を実行する。これはより多くのデータをＩ−ＤＳから読み出す。なぜなら、６４バイトのみがもたらされるためである。一旦これが行われると、コマンドの処理が開始され得る。
【００９４】
ＳＭソフトウエアモジュールが次に呼び出される。このモジュールは、コマンドのためのＨＬＵＮが存在するかどうかを決定する。ＨＬＵＮは、サーバおよびＶＬＵＮを結合する構造である。このＨＬＵＮは、サーバおよびＶＬＵＮを結合する構造である。このＳＭは、ＦＣＢページ構造、ＦＣＬＵＮ、およびメッセージヘッダからのＤｅｖＨａｎｄｌｅからソースポートを抽出し、これをツリー検索エンジン（ＴＳＥ）に供給する。ＴＳＥがリーフを生成しない場合、ＨＬＵＮが存在せず、コマンドが拒絶される。ＨＬＵＮが存在する場合、コマンドの処理が継続する。このモジュールはまた、コマンドタイプを見積もる。ＲＤ／ＷＲコマンドではない場合、このモジュールはフレームを処理のためにＳＰに送信する。ＳＭは、開始ＬＢＡおよびＣＤＢからのブロックの数を抽出し、物理開始ＬＢＡ、複数のブロック、およびコマンドの物理的宛先を見積もるＬＭソフトウエアコンポーネントへの呼び出しを行う。
【００９５】
ＬＭは、ＴＳＲメモリにおけるＨＬＵＮ検索結果を用いて呼び出される。ＨＬＵＮから、ＬＭはＶＬＵＮを検索する。ＶＬＵＮを表す物理デバイスは、ＬＢＡ０で開始しないかもしれないくつかのディスクであり得る。ＶＬＵＮの後方にある各物理デバイスはスライスと呼ばれる。ＬＭがスライスに進み、このＩＯリクエストのためにどのスライスが呼び出されているかを見積り、新しい開始ＬＢＡおよびリクエストされたブロックを計算する。リクエストがスライス境界を交差し得る。この場合、ＬＭは子ＩｏＣＢを割り当て、それらをマスターリクエストにリンクする。この計算が行われた後、ＬＭは、ターゲット物理デバイスを検索する。ＬＭは、ＦＣＢページにおいて宛先ＳＰ数、ターゲットＤＭＵ／ＤＳＵで満たし、イーサネット（Ｒ）ヘッダにおいて、ターゲットデバイスを検索するために下流ＳＰによって使用されたｐｌＨａｎｄｌｅで満たす。ＬＭは、ＳＭ、物理ターゲットのＦＣＬＵＮ、開始ＬＢＡ、および複数のフロックに再度戻す。
【００９６】
この情報からのＳＭは、ＦＣＰコマンドペイロードを構築し、ＦＣＰＭに再度戻す。このＦＣＰＭは、データプールからのフレームを再度書き込み、スイッチモジュールに対するフレームにキューを入れ、上流ＳＰ上のコマンド処理を終了する。
【００９７】
下流のコマンドフレームは以下のように処理される。
【００９８】
上流ＳＰからのコマンドフレーム下流に送信されるようになる。イーサネット（Ｒ）封入ヘッダーでは、ＬＬＣフィールドは、２つの部分の重要な情報（上流ハンドルおよびｐＨａｎｄｌｅ）を含む。
【００９９】
コマンドフレームを受信した後のＦＣＰＭモジュールは、コマンドに対するＩｏＣＢを割り当てる。下流ＳＰが上流ＳＰデータまたはそのコマンドに関連するステータスフレームを送信する必要がある場合、上流ハンドルが使用される。上流ハンドルは、データまたはステータスフレームと共に送信されることにより、上流ＳＰは、フレームに対するコンテクストを見出すことを可能にする。このコマンドを受信した後、下流ＳＰは、上流ＳＰに下流ハンドルを含むＡＣＫ／ＲＤＹフレームを送信する。上流および下流ＳＰの両方のこの方法は、互いのハンドルを有する。各側がフレームのコマンドコンテクストを獲得することができるように、ピアハンドルが送信される。
【０１００】
送られたこのｐＨａｎｄｌｅは、ＰＬＵＮまたはｐＤｅｖｐａｔｈルックアップのいずれかであり得る。これは、ｐＨａｎｄｌｅ  ＭＣＡＳＴビットに依存する。ＭＣＡＳＴビットが設定される場合、これは、デバイスへの多重パスが存在し得ることを意味する。クリアである場合、単一パスのみが存在する。ＰＬＵＮがリーフから参照される場合、ＬＭは、どのパスが取られるかを決定する。これは、ｐＤｅｖｐａｔｈの別の検索を導く。単一パスでは、ｐＤｅｖｐａｔｈが直接参照される。ＬＭはｍａｘＲｘｄａｔａサイズおよびターゲットポートを抽出する。この情報は、ＦＣＰＭに戻される。ＦＣＰＭは、ＬＭに戻された情報から新しいＦＣヘッダーを構成し、フレームを外部に運ぶ。
【０１０１】
上流データフレームは、以下の態様で処理される。
【０１０２】
上流データフレームは、複数の環境で発生し得る。例えば、サーバが書き込みデータを送信する場合、データフレームは、入力側で現れる。下流ＳＰが読み出しデータに応答する場合、データフレームは、出力側で現れる。
【０１０３】
サーバ送信データの場合、ＦＣＰＭは、メッセージヘッダにおける戻されたＳＰＨａｎｄｌｅ（ＩＯＣＢアドレス）を用いてＩｏＣＢを参照する。ＩｏＣＢから、ＳＰは、データフレームを運ぶべき場所を知っている。
【０１０４】
データフレームが出力側にある場合、ＦＣＰＭは、イーサネット（Ｒ）ＬＬＣフィールドを介して送られたハンドルを用いてＩｏＣＢを検索する。これは、ＩｏＣＢアドレスである。ＩｏＣＢから、ＦＣＰＭは、データをサーバに運ぶかどうか、またはより多くのデータを待たなければならないかを決定する。これは、ストライピング（データ無秩序に来得る）の場合に発生し得る。
【０１０５】
下流データフレームは、以下の態様で処理される。
【０１０６】
下流のデータフレームは、複数の環境で発生し得る。例えば、デバイスが読み出しデータに応答する場合、これらのフレームは、入力側で現れる。上流ＳＰが書き込みデータを送信する場合、これらのフレームは、出力側で現れる。ＳＰがＩｏＣＢを参照する態様は、上述と同じである。
【０１０７】
下流のステータスフレームは、以下の態様で処理される。
【０１０８】
下流のステータスフレームは、ターゲットデバイスから来る。リクエストされた動作が終了する場合または例外が発生する場合に、これが発生する。ステータスデータは、ステータスフレームと共に来る。
【０１０９】
ＦＣＰＭは、メッセージヘッダにおいて戻されたＳＰＨａｎｄｌｅ（ＩＯＣＢアドレス）を用いてＩｏＣＢを検索する。上流コマンドハンドルは、イーサネット（Ｒ）封入ヘッダーに挿入される。ステータスフレームは、上流に運ばれ、ＩｏＣＢが分解される。デバイスへの複数のパスが存在する場合、他のパスが試みられ得る。
【０１１０】
上流ステータスフレームは、以下の態様で処理される。
【０１１１】
上流ステータスフレームは、下流ＳＰから来る。ＦＣＰＭは、イーサネット（Ｒ）封入ヘッダーに送られたコマンドハンドルからＩｏＣＢを検索する。ＳＭサブシステムが呼び出され、ステータスフレームが必要な場合に生成される。このステータスフレームは、仮想デバイスに関するリクエストのためにある。戻りステータスは、物理デバイスに由来し、同じコンテクストを有さなくてもよいし。従って、ＳＭは、ステータスフレームを再生成し得る。ＦＣＰＭが最終的に、フレームを再度サーバに転送するように呼び出される。これが発生した後、ＩｏＣＢが分解される。
【０１１２】
図１０は、読み出しコマンドにおける処理ステップのフローチャートである。読み出しデータフローは、上述の同じコマンド、データおよびステータスフェーズに進む。読み出しコマンドが受け取られる場合、ＳＰは、仮想リクエストを物理リクエストに分解する。
【０１１３】
ＦＣＰプロトコルは、コマンドに対して必要とされた全てのバッファ空間が既にサーバ側に割り当てられたことを想定する。ＳＰは、ＸＦＥＲ＿ＲＤＹを待つことなくサーバにデータを再度自由に送信する。フロー制御は、ＦＣ側上のＢＢクレジットメカニズムおよび」ＧｂＥ側上のＰＡＵＳＥフレームを用いてＦＣポートＡＳＩＣによって処理される。
【０１１４】
リクエストが単一の物理デバイスにマッピングする簡単な場合では、再順序付け（ｒｅｏｒｄｅｒｉｎｇ）は必要ではない。デバイスへのパスが選ばれ、物理リクエストがデバイスに取り付けられたＳＰに送信される。ミラーリングの場合、上流ＳＰは、どのメンバーが読み出されるかを決定する。連結またはストライプの場合、ＳＰは、元のＳＰからさらなるリクエストを生成し得る。データが下流ＳＰから再度来る場合、ＮＰＳＩＭ分解の後でサーバに再度データを送信する前に、上流ＳＰは順番にデータを再構築する。
【０１１５】
図１１は、書き込みコマンドにおける処理ステップのフローチャートである。書き込みコマンドがサーバから受信される場合、ＳＰは、物理デバイスへのパスを見積もる。ＸＦＥＲ＿ＲＤＹフレームがサーバに送信されるべきであるので、書き込みコマンドがより複雑化される。
【０１１６】
上流ＳＰは、好ましくは、上流ＳＰが下流ＳＰから再度ハンドルを獲得するまでサーバにＸＦＥＲ＿ＲＤＹを送信しない。下流ＳＰは、好ましくは、下流ＳＰがデバイスから再度ＸＦＥＲ＿ＲＤＹ応答を獲得するまでハンドルを再送信しない。
【０１１７】
次いで上流ＳＰは、下流ＳＰから示された同じバイトカウントを有するサーバにＸＦＥＲ＿ＲＤＹを送信することにより、サーバからデータフローを開始する。
【０１１８】
ＸＦＥＲ＿ＲＤＹは、データフレームがディスク境界を介して分割される必要がないことを確実にするためにさらに調整される。この改変は、上流ＳＰによってなされ、プロセスは、リクエストが終了するまで継続する。
【０１１９】
最適化として、下流ＳＰは、作成されたＸＦＥＲ＿ＲＤＹを用いて上流ＳＰに応答し得る。このレポートされたバイトカウントは、ＰＬＯＧＩプロセスの間に交渉される、デバイスが受信し得る最大受信サイズに設定される。上流ＳＰは、ＸＦＥＲ＿ＲＦＹをサーバに送信する。これは、サーバからデータフローを開始する。
【０１２０】
ターゲットデバイスがＸＦＥＲ＿ＲＤＹを用いて応答する場合、下流ＳＰは、上流ＳＰに調整されたバイトカウントを再度送信する。上流ＳＰは、新しく調整されたバイトカウント値を用いてサーバにＸＦＥＲ＿ＲＤＹを送信する。この方法が最適化され、以後考慮される。
【０１２１】
図１２は、ピココードソフトウエアスタックを示す。正確な入力機能を呼び出すために、ハードウエアクラシファイアと共に動作させることによって、メッセージング層は、イーサネット（Ｒ）封入を解釈するために動作する。ファイバチャンネルプロトコル（ＦＣＰ）マネージャは、シーケンス管理およびＩｏＣＢ割り当て／分解を追跡する。このＳＣＳＩマネージャ（ＳＭ）層は、ＦＣＰ層の内側のＳＣＳＩコマンドを解釈する。ＬＵＮマネージャ（ＬＭ）層は、サーバから入る仮想リクエストを取り、その仮想リクエストを物理リクエストに分解する。このユーティリティ層は、ＩｏＣＢの割り当て／分解するための機能を有する。
【０１２２】
このセクションは、ピココードサブシステム（図１２参照）におけるＦＣＰマネージャコンポーネントを説明する。このピココードソフトウエアスタックでは、ＦＣＰは、ピココードサブシステムのフロントエンドとして考慮され得る。言い換えると、ＦＣＰマネージャは、全ての入来フレームを解釈するように設定される。ＳＰハードウエアクラシファイア（ＨＣ）は、ＳＰ  ＨＣ構成セクションにおいて議論されるディスパッチインジケータに基づいて適切なフレームハンドラへの入来フレームをディスパッチするように構成される。
【０１２３】
異なるフレームハンドラは、タスクを満たすために異なるセットのアクションを実行する。これらのハンドラーによって実行されたアクションの過程は、ＦＣＰパブリックインターフェースセクションにおいて説明される。
【０１２４】
ＳＰハードウエアクラシファイア構成は、以下のようである。入来フレームのＳＰの到着側に依存して、ＳＰハードウエアクラシファイア（ＨＣ）は、フレームをディスパッチするように異なるフィールドに鍵をかける。入力側上において、ＨＣは、入来フレームをディスパッチするためにＥタイプに基づく。さらに、それは、出力入来フレームをディスパッチするためにＵＣ／ＭＣ、ＦＨＥＦ、およびＶＳＨＦに基づく。
【０１２５】
ＦＣ  ＡＳＩＣおよびＳＰは、図８に示されるように、コマンド記述子（ＣＤ）フレーム３００を介して通信する。ＦＣ  ＡＳＩＣおよびＳＰの両方がＣＤフレームヘッダー（これは、図８におけるフィールドＡＤＤＲ、ＣＴＲＬ、ＰＲＯＴＯＣＯＬ、およびＴＡＧＳ３０２を含む）を調整する場合に確実にする必要がある所定の要求が存在する一方で、このセクションは、２つの主要なＩＯパス、読み出しおよび書き込みに関するＣＤフレームヘッダー操作を要約する。
【０１２６】
図１３は、読み出しコマンド上のＣＤフレームヘッダー操作を表す。図１４は、書き込みコマンドに関するＣＤフレームヘッダー操作を表す。
【０１２７】
ピココードの一部としてのＦＣＰインターフェース（図１２参照）は以下のものを含む。すなわち、入力コマンドハンドラ、出力コマンドハンドラ、入力データハンドラ、出力データハンドラ、入力ステータスハンドラ、出力ステータスハンドラ、入力Ｘｆｅｒレディハンドラ、出力Ｘｆｅｒレディハンドラ、入力送信コマンドハンドラ、出力送信良好ステータスハンドラ、出力送信不良ステータスハンドラ、出力送信新ステータスハンドラ、および放棄Ｉフレームハンドラである。
【０１２８】
入力コマンドハンドラ機能は、サーバからＳＰ入力に送信されたコマンドフレームを処理するために使用される。エントリポイントは、ｆｃｐ＿ｃｍｄ＿ｉであり、パスは、ＵＰＳＴＲＥＡＭ−ＩＮＧＲＥＳＳ−ＣＯＭＭＡＮＤである。ハードウエアクラシファイアは、この機能に基づくＶＳＸプログラム可能なＥタイプ（ＣＭＤ−１）を促進する。入力は、データプール（６４バイト）におけるコマンドフレームの一部を含む。
【０１２９】
入力コマンドハンドラの機能は、ＩＯＣＢ＿ｐｏｏｌからのＩＯＣＢ（ｕｔｉｌ＿ｉｏｃｂ＿ａｌｌｏｃ）をｗ２０において送られるべき割り当てられたＩＯＣＢのＩＤに割り当てること、およびＩＯＣＢコンテンツをＳｃｒａｔｃｈＭｅｍｌ（４ＱＷｓ）に読み出すことを含む。入力コマンドハンドラはまた、入来フレームのフレームＩＤをチェックし、予測されたインバウンド、アウトバウンド、内部フレームＩＤを初期化し、ＦＣフレームからの重要な情報を抽出し、ＩＯＣＢ（ＳＰ；ＦＣ＿Ｈａｎｄｌｅ）に格納する。
【０１３０】
入力コマンドハンドラの他の機能は、ＳＰ＿ＨａｎｄｌｅおよびＳＰ＿Ｑｕａｌｉｆｉｅｒをフレームタグに設定すること、ＦＣコマンドフレームをＩＯＣＢのステージング領域にコピーすること、ＩＯＣＢ情報を含む第２のＩ−ＤＳバッファの識別をｗ２２に格納すること、それ自体のハンドルをコマンドフレームに満たすことを含む。
【０１３１】
入力コマンドハンドラのさらなる機能は、ＩＯＣＢを格納し、領域アドレスをｗ２８およびｗ３０それぞれにステージング（ｓｔａｇｉｎｇ）すること、ＳＣＳＩコマンド（ｓｍ＿ｃｍｄ＿ｉ）を処理するためにＳＣＳＩマネージャを呼び出すことを含む。ＳｃｒａｔｃｈＭｅｍ１におけるＩＯＣＢ画像が更新されるが、実際のＩＯＣＢのコンテンツではない（更新された情報がその機能から戻った後に流されるべきである）。
【０１３２】
送り情報は、データプール（９６バイト）におけるコマンドフレーム、ｗ２８におけるＩＯＣＢアドレス、ｗ３０におけるＩＯＣＢステージング領域アドレス、ＳｃｒａｔｃｈＭｅｍ１におけるＩＯＣＢのコンテンツ（６４バイト−４ＱＷ）を含む。次いで、入力コマンドハンドラが終了し得る。
【０１３３】
出力コマンドハンドラ機能は、Ｉｎｉｔｉａｔｏｒ−ＲａｉｎｉｅｒからＳＰ−出力に送信されたコマンドフレームを処理するために使用される。このエントリポイントは、ｆｃｐ＿ｃｍｄ＿ｅであり、パスは、ＤＯＷＮＳＴＲＥＡＭ−ＥＧＲＥＳＳ−ＣＯＭＭＡＮＤである。
【０１３４】
ハードウエアクラシファイアは、｛ｉＵＣｎＭＣ，ＦＨＥ，およびＦＨＦ｝に基づいてこの機能を促進する。入力は、データプール（６４バイト）におけるコマンドフレームの一部を含み、Ｒ０は、フレームヘッダーの最初のバイトへのオフセットを含む。
【０１３５】
バッファサイズミスマッチにより、ＸＦＲ＿ＲＤＹがターゲットデバイスから受け取られるまで、「ローカルコマンドハンドル」を再度Ｉｎｉｔｉａｔｏｒ  Ｒａｉｎｉｅｒに送信しない。
【０１３６】
出力コマンドハンドラの機能は、入来Ｅ＿ｆｒａｍｅ（ｆｃｐ＿ｆｉｌｔｅｒ＿ｆｃｐ＿ｅｆｒｍ）を確証することおよび割り当てられたＩＯＣＢのＩＤがｗ２０内にあることを確実にするＩＯＣＢ＿Ａｌｌｏｃ機能を有するＩＯＣＢをＩＯＣＢ＿ｐｏｏｌ（ｕｔｉｌ＿ｉｏｃｂ＿ａｌｌｏｃ）からＴＯＣＢを割り当てることを含む。
【０１３７】
さらに、出力コマンドハンドラは、ＩＯＣＢコンテンツをＳｃｒａｔｃｈＭｅｍ１（４ＱＷ）に読み出し、ＩＯＣＢおよびステージ領域アドレスをｗ２８およびｗ３０にそれぞれ格納し、そして入来フレームのフレームＩＤをチェックし得る。出力コマンドハンドラの他の機能は、予測されたインバウンド、アウトバウンド、内部フレームＩｄｓを初期化すること、ｐｅｅｒ＿Ｈａｎｄｌｅおよびｐｅｅｒ＿ＱｕａｌｉｆｉｅｒをＩＯＣＢに保存すること、ならびにＦＣ＿Ｈａｎｄｌｅを０ｘＦＦＦＦに初期化すること、制御フィールドをゼロ設定に初期化するこを含む。
【０１３８】
出力コマンドハンドラはまた、ｐＬｕｎルックアップを実行するためにＬＭを呼び出す（ｌｍ＿ｃｍｄ＿ｅ）。このｌｍ＿ｃｍｄ＿ｅ機能は、ＩＯＣＢにおけるターゲットポートおよびＩＯＣＢにおけるＭａｘＲｘＤａｔａを確実にする。
【０１３９】
出力コマンドハンドラは、コマンドフレームをターゲットデバイスに送信するためにＦＣＰをさらに呼び出し（ｆｃｐ＿ｓｎｄ＿ｃｍｄ＿ｅ）、ＩＯＣＢをポートアクティブキューにキューを入れる。次いでこの出力コマンドハンドラは、ＳｃｒａｔｃｈＭｅｍ１からＥ−ＤＳに、更新されたＩＯＣＢ情報を放流し得、次いで終了する。
【０１４０】
入力データハンドラ機能は、サーバからＳＰ−入力に送信されたデータフレームを処理するために使用される。エントリポイントは、ｆｃｐ＿ｄａｔａ＿ｉであり、パスは、ＵＰＳＴＲＥＡＭ／ＤＯＷＮＳＴＲＥＡＭ−ＩＮＧＲＥＳＳ−ＤＡＴＡである。ハードウエアクラシファイアは、ＶＳＸプログラマブルＥ−タイプ（ＤＡＴＡ−Ｉ）に基づくこの機能を促進する。入力は、データプール（３２バイト）におけるコマンドフレームの一部を含む。
【０１４１】
入力データハンドラの機能は、ＩＯＣＢアドレスを確証すること（受信されたフレームにおいて戻されたＳＰ＿Ｈａｎｄｌｅ）、ＩＯＣＢコンテンツをＳｃｒａｔｃｈＭｅｍ１（８ＱＷ）に読み出すことを含む。この入力データハンドラは、以下のフィールドをチェックすることによってフレームコンテンツをＩＯＣＢコンテンツに整合し得る。そのフィールドは、ＳＰ＿Ｑｕａｌｉｆｉｅｒ、Ｆｒａｍｅ＿ＩＤ、ＦＣ＿Ｈａｎｄｌｅ（これが最初のデータフレームではない場合）、およびルーティング情報（ｆｃｐ＿ｖａｌ＿ｒｉ＿ｉ）である。
【０１４２】
この入力データハンドラはまた、ＦＣ＿ＨａｎｄｌｅをＩＯＣＢに保存し（最初のデータフレーム上）、フレームＩＤ、ｐｅｅｒ＿Ｈａｎｄｌｅ、およびｐｅｅｒ＿Ｑｕａｌｉｆｉｅｒを更新し、そしてデータフレームを他のＲａｉｎｉｅｒ（Ｉｎｉｔｉａｔｏｒ／Ｔａｇｅｔ−Ｒａｉｎｉｅｒ）に送信するためにＦＣＰを呼び出し得る（ｆｃｐ＿ｓｎｄ＿ｄａｔａ＿ｉ）。この入力データハンドラは、ＳｃｒａｔｃｈＭｅｍ１からＥ−ＤＳに更新されたＩＯＣＢ情報をさらに放流し得、次いで終了する。
【０１４３】
出力データハンドラ機能は、Ｉｎｉｔｉａｔｏｒ／Ｔａｇｅｔ−ＲａｉｎｉｅｒからＳＰ−出力に送信されたデータフレームを処理するために使用される。このエントリポイントは、ｆｃｐ＿ｄａｔａ＿ｅであり、パスは、ＵＰＳＴＲＥＡＭ／ＤＯＷＮＳＴＲＥＡＭ−ＥＧＲＥＳＳ−ＤＡＴＡである。
【０１４４】
ハードウエアクラシファイアは、｛ｉＵＣｎＭＣ，ＦＨＥ，およびＦＨＦ）に基づいてこの機能を促進する。入力は、データプール（３２バイト）におけるデータフレームの一部を含む。
【０１４５】
出力データハンドラによって実行された機能は、ＩＯＣＢアドレスを確証すること（受信されたフレームへの送りｐｅｅｒＯｒＰＨａｎｄｌｅ）、およびＩＯＣＢコンテンツのＳｃｒａｔｃｈＭｅｍ１（８ＱＷ）に読み出すことを含む。出力データハンドラはまた、以下のフィールドをチェックすることによってフレームコンテンツをＩＯＣＢコンテンツに整合し得る。そのフィールドは、Ｏｗｎ＿Ｑｕａｌｉｆｉｅｒ、Ｆｒａｍｅ＿ＩＤ、Ｐｅｅｒ＿Ｈａｎｄｌｅ、およびＰｅｅｒ＿Ｑｕａｌｉｆｉｅｒ（これが最初のデータフレームではない場合）、およびルーティング情報（ｆｃｐ＿ｖａｌ＿ｒｉ＿ｅ）（これが最初のデータフレームではない場合）である。
【０１４６】
この出力データハンドラはまた、Ｐｅｅｒ＿Ｈａｎｄｌｅ、Ｐｅｅｒ＿Ｑｕａｌｉｆｉｅｒ、および終了したルーティング情報をＩＯＣＢに保存し（最初のデータフレーム上に）、ソースおよび宛先ルーティング情報を交換し、そしてＦＣ＿Ｈａｎｄｌｅ、ＳＰ＿Ｈａｎｄｌｅ、ＳＰ＿Ｑｕａｌｉｆｉｅｒ、ｆｒａｍｅ＿ＩＤ、ｐｏｒｔ＿Ｈａｎｄｌｅ、およびｐｏｒｔ＿Ｎｕｍｂｅｒ、およびフレーム制御フィールドを更新し得る。
【０１４７】
この出力データハンドラは、データフレームを他の宛先デバイス（Ｉｎｉｔｉａｔｏｒ／Ｔａｇｅｔ−Ｒａｉｎｉｅｒ）に送信するためにＦＣＰを呼び出し（ｆｃｐ＿ｓｎｄ＿ｄａｔａ＿ｅ）、ＩＯＣＢにおける実行バイトカウントフィールドを更新し、ＳｃｒａｔｃｈＭｅｍ１からＥ−ＤＳに、更新されたＩＯＣＢ情報を放流し得、次いで終了する。
【０１４８】
入力ステータスハンドラの機能は、ターゲットデバイスからＳＰ−入力に送信されたステータスフレームを処理するために使用される。エントリポイントは、ｆｃｐ＿ｓｔａｔｕｓ＿ｉであり、パスは、ＤＯＷＮＳＴＲＥＡＭ−ＩＮＧＲＥＳＳ−ＳＴＡＴＵＳである。このハードウエアクラシファイアは、ＶＳＸプログラム可能なＥタイプ（ＳＴＳ−Ｉ）に基づいてこの機能を促進する。入力は、データプール（６４バイト）におけるコマンドフレームの一部を含む。
【０１４９】
入力ステータスハンドラによって実行された機能は、ＩＯＣＢアドレスを確証すること（受信されたフレームにおいて戻されたＳＰ＿Ｈａｎｄｌｅ）、およびＩＯＣＢコンテンツをＳｃｒａｔｃｈＭｅｍ１（８ＱＷ）に読み出すことを含む。フレームコンテンツは、以下のフィールドをチェックすることによってＩＯＣＢコンテンツに整合される。そのフィールドは、ＳＰ＿Ｑｕａｌｉｆｉｅｒ、Ｆｒａｍｅ＿ＩＤ、ＦＣ＿Ｈａｎｄｌｅ（これが最初のデータフレームではない場合）、およびルーティング情報（ｆｃｐ＿ｖａｌ＿ｒｉ＿ｉ）である。
【０１５０】
この入力ステータスハンドラは、ＦＣ＿ＨａｎｄｌｅをＩＯＣＢにさらに保存し（最初のデータフレーム上に）、フレームＩＤ、ｐｅｅｒ＿Ｈａｎｄｌｅ、およびｐｅｅｒ＿Ｑｕａｌｉｆｉｅｒを更新し、そしてステータスフレームをＩｎｉｔｉａｔｏｒ−Ｒａｉｎｉｅｒに送信するためにＦＣＰを呼び出す（ｆｃｐ＿ｓｎｄ＿ｓｔｓ＿ｉ）。入力ステータスハンドラはまた、ＩＯＣＢをポートアクティブキューから分解し（ｕｔｉｌ＿ｒｅｍｏｖｅ＿ｔｈｉｓ）、ＩＯＣＢをフリーなＩＯＣＢプールに戻し、次いで終了する。
【０１５１】
出力ステータスハンドラの機能は、Ｉｎｉｔｉａｔｏｒ−Ｒａｉｎｉｅｒからホストに送信されたステータスフレームを処理するために使用される。このエントリポイントは、ｆｃｐ＿ｓｔａｔｕｓ＿ｅであり、パスは、ＵＰＳＴＲＥＡＭ−ＥＧＲＥＳＳ−ＳＴＡＴＵＳである。
【０１５２】
ハードウエアクラシファイアは、｛ｉＵＣｎＭＣ，ＦＨＥ，およびＦＨＦ）に基づいてこの機能を促進する。入力は、データプール（３２バイト）におけるコマンドフレームの一部を含む。ＳＭは、ステータスペイロードを構築することに対して責任があることが想定される。
【０１５３】
出力ステータスハンドラの機能は、ＩＯＣＢアドレスを確証すること（受信されたフレームへの送りｐｅｅｒＯｒＰＨａｎｄｌｅ）、およびＩＯＣＢコンテンツをＳｃｒａｔｃｈＭｅｍ１（８ＱＷ）に読み出すことを含む。このフレームコンテンツは、以下のフィールドをチェックすることによってＩＯＣＢコンテンツに整合され得る。そのフィールドは、ｏｗｎ＿Ｑｕａｌｉｆｉｅｒ、Ｆｒａｍｅ＿ＩＤ、Ｐｅｅｒ＿Ｈａｎｄｌｅ、Ｐｅｅｒ＿Ｑｕａｌｉｆｉｅｒ（これが最初のデータフレームではない場合）、およびルーティング情報（ｆｃｐ＿ｖａｌ＿ｒｉ＿ｅ）（これが最初のデータフレームではない場合）である。
【０１５４】
出力ステータスハンドラの他の機能は、ｐｅｅｒ＿Ｈａｎｄｌｅ、ｐｅｅｒ＿Ｑｕａｌｉｆｉｅｒ、およびＩＯＣＢへの終了されたルーティング情報を保存することを含む（最初のフレーム上で）。他の機能は、ソースおよび宛先ルーティング情報を交換すること、ＩＯＣＢアドレスをｗ２８に格納すること、およびＩＯステータスをログを取るようにＳＣＳＩ管理を呼び出す（ｓｍ＿ｓｔａｔｕｓ＿ｅ）ことを含む。
【０１５５】
送り情報は、データプール（３２バイト）内のデータフレーム、ｗ２８におけるＩＯＣＢアドレス、およびＳｃｒａｔｃｈＭｅｍ１におけるＩＯＣＢのコンテンツ（８ＱＷ）を含む。次いで、この出力ステータスハンドラが終了する。
【０１５６】
入力Ｘｆｅｒレディハンドラ機能は、ターゲットデバイスからＳＰ−入力に送信されたｘｆｅｒＲｄｙフレームを処理するために使用される。エントリポイントは、ｆｃｐ＿ｘｆｒ＿ｒｄｙ＿ｉであり、パスは、ＤＯＷＮＳＴＲＥＡＭ−ＩＮＧＲＥＳＳ−ＸＦＥＲ＿ＲＥＡＤＹである。この機能は、ターゲットデバイスからＳＰ−入力に送信されたｘｆｅｒＲｄｙフレームを処理するために使用される。
【０１５７】
ハードウエアクラシファイアは、ＶＳＸプログラム可能なＥタイプ（ＸＦＲＲＤＹ−Ｉ）に基づいてこの機能を促進する。入力は、データプール（６４バイト）におけるコマンドフレームの一部を含む。
【０１５８】
入力Ｘｆｅｒレディハンドラ機能は、ＩＯＣＢアドレスを確証すること（受信されたフレームにおいて戻されたＳＰ＿Ｈａｎｄｌｅ）、およびＩＯＣＢコンテンツをＳｃｒａｔｃｈＭｅｍ１（８ＱＷ）に読み出すために機能する。フレームコンテンツは、以下のフィールドをチェックすることによってＩＯＣＢコンテンツに整合される。そのフィールドは、ＳＰ＿Ｑｕａｌｉｆｉｅｒ、Ｆｒａｍｅ＿ＩＤ、ＦＣ＿Ｈａｎｄｌｅ（これが最初のデータフレームではない場合）、およびルーティング情報（ｆｃｐ＿ｖａｌ＿ｒｉ＿ｉ）である。
【０１５９】
入力Ｘｆｅｒレディハンドラは、Ｄａｔａ＿ＲＯ（ＸｆｒＲｄｙペイロードにおける）が、ＩＯＣＢ  ｒｕｎｎｎｉｎｇ−ｂｙｔｅ−ｃｎｔと同じであり、他の場合では、ＦＣＰエラーハンドラ（ｆｃｐ＿ｉｎｖａｌｉｄ＿ｘｆｒｄｙ）を呼び出すことをさらに確認する。入力Ｘｆｅｒレディハンドラはまた、ＦＣ＿ＨａｎｄｌｅをＩＯＣＢに保存し（最初のデータフレーム上に）、ＩＯＣＢ  ｘｆｒｄｙをＢＵＲＳＴ＿ＬＥＮ（ＸｆｒＲｄｙペイロードにおける）を用いて更新し、そしてフレームＩＤ、ｐｅｅｒ＿Ｈａｎｄｌｅ、およびｐｅｅｒ＿Ｑｕａｌｉｆｉｅｒを更新する。入力Ｘｆｅｒレディハンドラは、ｘｆｅｒＲｄｙフレームを他のＲａｉｎｉｅｒ（Ｉｎｉｔｉａｔｏｒ−Ｒａｉｎｉｅｒ）に送信するためにＦＣＰを呼び出し（ｆｃｐ＿ｓｎｄ＿ｘｆｒ＿ｒｄｙ＿ｉ）、ＳｃｒａｔｃｈＭｅｍ１からＥ−ＤＳに、更新されたＩＯＣＢ情報を放流し得、次いで終了する。
【０１６０】
出力Ｘｆｅｒレディハンドラの機能は、ターゲットＲａｉｎｉｅｒからＳＰ−入力に送信されたｘｆｅｒＲｄｙフレームを処理するために使用される。エントリポイントは、ｆｃｐ＿ｘｆｒ＿ｒｄｙ＿ｅであり、パスは、ＵＰＳＴＲＥＡＭ−ＥＧＲＥＳＳ−ＸＦＥＲ＿ＲＥＡＤＹである。このハードウエアクラシファイアは、｛ｉＵＣｎＭＣ，ＦＨＥ，およびＦＨＦ）に基づいたこの機能を促進する。入力は、データプール（３２バイト）におけるデータフレームの一部を含む。
【０１６１】
出力Ｘｆｅｒレディハンドラによって実行された機能は、ＩＯＣＢアドレスを確証すること（受信されたフレームにおける送られるｐｅｅｒＯｒＰＨａｎｄｌｅ）、およびＩＯＣＢコンテンツをＳｃｒａｔｃｈＭｅｍ１（８ＱＷ）に読み出すことを含む。このフレームコンテンツは、以下のフィールドをチェックすることによってＩＯＣＢコンテンツに整合される。そのフィールドは、Ｏｗｎ＿Ｑｕａｌｉｆｉｅｒ、Ｆｒａｍｅ＿ＩＤ、Ｐｅｅｒ＿ＨａｎｄｌｅおよびＰｅｅｒ＿Ｑｕａｌｉｆｉｅｒ（これが最初のデータフレームではない場合）、およびルーティング情報（これが最初のデータフレームではない場合）（ｆｃｐ＿ｖａｌ＿ｒｉ＿ｅ）である。
【０１６２】
出力Ｘｆｅｒレディハンドラはまた、Ｐｅｅｒ＿Ｈａｎｄｌｅ、Ｐｅｅｒ＿Ｑｕａｌｉｆｉｅｒ、およびＩＯＣＢへのソースルーティング情報（最初のデータフレーム上に）を保存し、ソースおよび宛先ルーティング情報を交換し、Ｄａｔａ＿ＲＯ（ＸｆｒＲｄｙペイロードにおける）は、ＩＯＣＢ  ｒｕｎｎｎｉｎｇ−ｂｙｔｅ−ｃｎｔと同じであり、他の場合では、ＦＣＰエラーハンドラ（ｆｃｐ＿ｉｎｖａｌｉｄ＿ｘｆｒｄｙ）を呼び出すことを確認する。出力Ｘｆｅｒレディハンドラは、ＩＯＣＢ  ｘｆｒｄｙをＢＵＲＳＴ＿ＬＥＮ（ＸｆｒＲｄｙペイロードにおける）を用いて更新し、そしてＦＣ＿Ｈａｎｄｌｅ、ＳＰ＿Ｈａｎｄｌｅ、ＳＰ＿Ｑｕａｌｉｆｉｅｒ、ｆｒａｍｅ＿ＩＤ、Ｐｏｒｔ＿Ｈａｎｄｌｅ、Ｐｏｒｔ＿Ｎｕｍｂｅｒ、およびフレーム制御フィールドを更新する。この出力Ｘｆｅｒレディハンドラは、ｘｆｅｒＲｄｙフレームを初期化デバイスに送信するためにＦＣＰを呼び出し（ｆｃｐ＿ｓｎｄ＿ｘｆｒ＿ｒｄｙ＿ｅ）、ＳｃｒａｔｃｈＭｅｍ１からＥ−ＤＳに、更新されたＩＯＣＢ情報を放流し、次いで終了する。
【０１６３】
入力送信コマンドハンドラの機能は、更新されたフレームおよびＩＯＣＢのコンテンツをＩ−ＤＳおよびＥ−ＤＳそれぞれに放流するために使用される。次いで、Ｉ−ＥＤＳに対するこのフレームにキューを入れる。このエントリポイントは、ｆｃｐ＿ｓｎｄ＿ｃｍｄ＿ｉであり、そのパスは、ＵＰＳＴＲＥＡＭ−ＩＮＧＲＥＳＳ−ＣＯＭＭＡＮＤである。呼び出し側は、ＳＭである。
【０１６４】
入力は、データプール（有効な情報を含むＱＷの量は、予め定義されかつ補償されるべきである）におけるフレームのコンテンツ、ＳｃｒａｔｃｈＭｅｍ１における更新されたＩＯＣＢのコンテンツ（有効な情報を含むＱＷの量は、予め定義されかつ補償されるべきである）を含み、構築されたＥタイプ、コマンドペイロード、宛先情報を含む。他の入力は、ＩＯＣＢを含む。ＴＢ０は、ｗ２８に格納され、ｗ２２に格納されたコマンドフレームを含む第２のＩ−ＤＳバッファの識別は、ｗ２２に格納される。
【０１６５】
入力送信コマンドハンドラによって実行される機能は、データプールからＩ−ＤＳへの更新された情報を放流すること、およびＦＣＢページ｛ｉＵＣｎＭＣ，ＦＨＦ，ＦＨＥ｝を設定し、Ｉ−ＥＤＳに対するフレームにキューを入れるターゲットへのフレームを送信することを含む。この入力送信コマンドハンドラはまた、ＳｃｒａｔｃｈＭｅｍ１からＥ−ＤＳに、更新されたＩＯＣＢ情報を放流する。
【０１６６】
出力送信良好ステータスハンドラ機能は、更新されたフレームをＥ−ＤＳに放流し、Ｅ−ＥＤＳに対するフレームにキューを入れるために使用される。このエントリポイントは、ｆｃｐ＿ｓｎｄ＿ｇｄｓｔｓ＿ｅであり、そのパスは、ＵＰＳＴＲＥＡＭ−ＥＧＲＥＳＳ−ＳＴＡＲＵＳである。呼び出し側は、ＳＭである。入力はデータプール内のフレームのコンテンツを含み、そのステータスペイロードおよび宛先情報が構築されている。
【０１６７】
出力送信良好ステータスハンドラの機能は、ＦＣフレーム（ＦＣ＿Ｈａｎｄｌｅ、ＳＰ＿Ｈａｎｄｌｅ、ＳＰ＿Ｑｕａｌｉｆｉｅｒ、ｆｒａｍｅ＿ＩＤ、ＦＣ＿Ｐｏｒｔ＿Ｈａｎｄｌｅ、およびＰｏｒｔ＿Ｎｕｍｂｅｒ）の改変を含む。この機能は、ルーティング情報を交換する必要はない。なぜなら、ｆｃｐ＿ｖａｌ＿ｒｉ＿ｅ（）は、それをすでに行ったためである。出力送信良好ステータスハンドラはまた、更新された情報を、データプールからＥ−ＤＳに放流する（データプールにおける第２のＱＷから開始する３ＱＷ）。このフレームは、ＦＣＢページ｛ＱＩＤ｝を設定し、Ｅ−ＥＤＳに対するフレームにキューを入れるためにＩｎｉｔｉａｔｏｒ／Ｈｏｓｔに送信される。
【０１６８】
出力送信不良ステータスハンドラ機能は、更新されたフレームをＥ−ＤＳに放流するために使用され、Ｅ−ＥＤＳに対するフレームにキューを入れる。エントリポイントは、ｆｃｐ＿ｓｎｄ＿ｂａｄｓｔｓ＿ｅであり、パスは、ＵＰＳＴＲＥＡＭ−ＥＧＲＥＳＳ−ＳＴＡＲＵＳである。呼び出し側は、ＳＭである。入力はデータプール内のフレームのコンテンツを含み、そのステータスペイロードおよび宛先情報が構築され、そしてバイトにおける応答ペイロードのサイズはｗ２０を介して送られる。
【０１６９】
出力送信不良ステータスハンドラの機能は、ＦＣフレーム（ＦＣ＿Ｈａｎｄｌｅ、ＳＰ＿Ｈａｎｄｌｅ、ＳＰ＿Ｑｕａｌｉｆｉｅｒ、ｆｒａｍｅ＿ＩＤ、ＦＣ＿Ｐｏｒｔ＿Ｈａｎｄｌｅ、およびＰｏｒｔ  Ｎｕｍｂｅｒ）を改変することを含む。この機能が、ルーティング情報を交換する必要はない。なぜなら、ｆｃｐ＿ｖａｌ＿ｒｉ＿ｅ（）は、それをすでに行ったためである。更新された情報は、データプールからＥ−ＤＳに放流される（データプールからＥ−ＤＳに放流される必要があるＱＷの数を計算するために、ＳＭによって送られた応答ペイロードのサイズに基づく）。フレームは、ＦＣＢページ｛ＱＩＤ｝を設定し、Ｅ−ＥＤＳに対するフレームにキューを入れるためにＩｎｉｔｉａｔｏｒ／Ｈｏｓｔに送信される。
【０１７０】
出力送信新ステータスハンドラ機能は、新しいステータスフレームを構築するため、およびホストに送信するために使用される。エントリポイントは、ｆｃｐ＿ｓｎｄ＿ｎｅｗ＿ｓｔｓ＿ｅであり、パスは、ＵＰＳＴＲＥＡＭ−ＥＧＲＥＳＳ−ＳＴＡＲＵＳである。呼び出し側は、ＳＭである。
【０１７１】
入力は、データプール（有効な情報を含むＱＷの量は、予め定義されかつ補償されるべきである）におけるフレームのコンテンツを含み、そのステータスペイロードおよび宛先情報が構築され、バイトでの応答ペイロードのバイトのサイズがｗ２０を介して送られる。
【０１７２】
出力送信新ステータスハンドラの機能は、ＦＣフレーム（ＰＯＳ＿Ｈｅａｄｅｒ、プロトコル、ＦＣ＿Ｈａｎｄｌｅ、ＳＰ＿Ｈａｎｄｌｅ、ＳＰ＿Ｑｕａｌｉｆｉｅｒ、ｆｒａｍｅ＿ＩＤ、ＦＣ＿Ｐｏｒｔ＿Ｈａｎｄｌｅ、およびＰｏｒｔ  Ｎｕｍｂｅｒ）を改変すること、制御情報を設定すること、およびＰＯＳトレーラを設定することを含む。他の機能は、ステータスフレームコンテンツを格納するために、新しいツインバッファを割り当ること、重要な情報を有する新ＦＣＢページを構築すること、およびデータプールからＥ−ＤＳへの更新された情報を放流すること（データプールからＥ−ＤＳに放流される必要があるＱＷの数を計算するために、ＳＭによって送られた応答ペイロードのサイズに基づく）を含む。このフレームは、ＦＣＢページ｛ＱＩＤ｝を設定し、Ｅ−ＥＤＳに対するフレームにキューを入れるためにＩｎｉｔｉａｔｏｒ／Ｈｏｓｔに送信される。
【０１７３】
放棄されたＩ−フレームハンドラ機能は、入力入来フレームを放棄するために使用される。このエントリポイントは、ｆｃｐ＿ｄｉｓｃａｒｄ＿ｉであり、パスは、ＸＸＸ−ＩＮＧＲＥＳＳ−ＸＸＸである。呼び出し側は、ＳＭである。放棄されたフレーム情報は、アクティブＦＣＢページに格納されることが想定される。放棄Ｉ−フレームハンドラの機能は、フレームに入力放棄キュー（すなわち、Ｉ−ＤＤＱ）に対するキューを入れることである。
【０１７４】
放棄Ｅ−フレームハンドラ機能は、出力入来フレームを放棄するために使用される。このエントリポイントは、ｆｃｐ＿ｄｉｓｃａｒｄ＿ｅであり、パスは、ＸＸＸ−ＥＧＲＥＳＳ−ＸＸＸである。呼び出し側は、ＦＣＰである。放棄されたフレーム情報は、アクティブＦＣＢページに格納されることが想定される。放棄Ｅ−フレームハンドラは、フレームに入力出力放棄キュー（すなわち、Ｅ−ＤＤＱ）に対するキューを入れるために機能することである。
【０１７５】
以下は、ピココード（図１２参照）によって実行されたＦＣＰ秘密インターフェースのリストである。これは、出力送信コマンドハンドラ、入力送信データハンドラ、出力送信データハンドラ、入力送信ステータスハンドラ、入力送信転送レディハンドラ、出力送信転送レディハンドラ、入力送信ハンドル応答、出力フィルタＦＣフレーム、出力無効チェックサム、入力有効フレームルーティング情報、出力有効フレームルーティング情報、入力無効ＦＣフレーム情報、出力無効ＦＣフレーム情報、および放棄Ｅ−フレームハンドラである。
【０１７６】
出力送信コマンドハンドラエントリポイント機能は、更新されたフレームをＥ−ＤＳに放流し、Ｅ−ＥＤＳに対するフレームにキューを入れるために使用される。このエントリポイントは、ｆｃｐ＿ｓｎｄ＿ｃｍｄ＿ｅであり、そのパスは、ＤＯＷＮＳＴＲＥＡＭ−ＥＧＲＥＳＳ−ＣＯＭＭＡＮＤである。呼び出し側は、ＦＣＰである。
【０１７７】
入力は、データプールにおいてフレームのコンテンツを含み、コマンドペイロードおよび宛先情報が構築される。ＬＭがＦＣＢページ、フレームルーティング情報、およびポートハンドルを準備することに対して責任があることが想定される。
【０１７８】
出力送信コマンドハンドラエントリポイントの機能は、ソースおよび宛先ルーティング情報を交換すること、出力フレームにおけるポート数を設定すること、およびデータプールからＥ−ＥＤＳに更新された情報を放流することを含む。このフレームは、ＦＣＢページ｛ＱＩＤ｝を設定し、フレームをＥ−ＥＤＳにキューを入れるためにターゲットデバイスに送信される。
【０１７９】
入力送信データハンドラ機能は、更新されたフレームをＩ−ＤＳに放流し、Ｉ−ＥＤＳに対するフレームにキューを入れるために使用される。エントリポイントは、ｆｃｐ＿ｓｎｄ＿ｄａｔａ＿ｉであり、そのエントリパスは、ＵＰＳＴＲＥＡＭ／ＤＯＷＮＳＴＲＥＡＭ−ＩＮＧＲＥＳＳ−ＤＡＴＡである。呼び出し側は、ＦＣＰである。入力は、データプールにおけるフレームのコンテンツを含み、データペイロードおよび宛先情報が構築される。
【０１８０】
入力送信データハンドラの機能は、データプールからＩ−ＤＳに更新された情報を放流すること、ＦＣＢページ｛ｉＵＣＭＣ，ＦＨＦ，ＦＨＥ，ＴＢ，ＴＤＭＵ，ｉＤＳＵ）を設定するため、およびＩ−ＥＤＳに対する更新されたフレームにキューを入れるために他のＲａｉｎｉｅｒへのフレームを送信することを含む。
【０１８１】
出力送信データハンドラ機能は、Ｅ−ＤＳに更新されたフレームを放流し、Ｅ−ＥＤＳに対するフレームにキューを入れるために使用される。エントリポイントは、ｆｃｐ＿ｓｎｄ＿ｄａｔａ＿ｅであり、パスは、ＵＰＳＴＲＥＡＭ／ＤＯＷＮＳＴＲＥＡＭ−ＥＧＲＥＳＳ−ＤＡＴＡである。呼び出し側は、ＦＣＰである。
【０１８２】
入力は、データプールにおいてフレームのコンテンツを含み、データペイロードおよび宛先情報が構築される。出力送信データハンドラの機能は、データプールからＥ−ＤＳに更新された情報を放流すること、およびＦＣＢページ｛ＱＩＤ｝を設定するため、およびＥ−ＥＤＳに対するフレームにキューを入れるためにＩｎｔｉａｔｏｒ−Ｒａｉｎｉｅｒへのフレームの送信とを含む。
【０１８３】
入力送信ステータスハンドラ機能は、Ｉ−ＤＳに更新されたフレームを放流し、Ｉ−ＥＤＳに対するフレームにキューを入れるために使用される。エントリポイントは、ｆｃｐ＿ｓｎｄ＿ｓｔｓ＿ｉであり、パスは、ＤＯＷＮＳＴＲＥＡＭ−ＩＮＧＲＥＳＳ−ＳＴＡＴＵＳである。呼び出し側は、ＦＣＰである。
【０１８４】
入力は、データプールにおいてフレームのコンテンツを含み、ステータスペイロードおよび宛先情報が構築される。入力送信ステータスハンドラの機能は、データプールからＩ−ＤＳに更新された情報を放流し、ＦＣＢページ｛ｉＵＣＭＣ，ＦＨＦ，ＦＨＥ，ＴＢ，ＴＤＭＵ，ｉＤＳＵ｝を設定し、およびＩ−ＥＤＳに対するフレームにキューを入れるために、Ｉｎｔｉａｔｏｒ−Ｒａｉｎｉｅｒへのフレームを送信することを含む。
【０１８５】
入力送信転送レディハンドラ機能は、更新されたフレームをＩ−ＤＳ放流するために使用され、Ｉ−ＥＤＳに対するフレームにキューを入れる。エントリポイントは、ｆｃｐ＿ｓｎｄ＿ｘｆｒ＿ｒｄｙ＿ｉであり、パスは、ＤＯＷＮＳＴＲＥＡＭ−ＩＮＧＲＥＳＳ−ＸＦＥＲ  ＲＥＡＤＹである。呼び出し側は、ＦＣＰである。入力は、データプールにおけるフレームのコンテンツである。入力送信転送レディハンドラは、データプールからＩ−ＤＳに更新された情報を放流し、ＦＣＢページ｛ｉＵＣＭＣ，ＦＨＦ，ＦＨＥ，ＴＢ，ＴＤＭＵ，ｉＤＳＵ｝を送信し、Ｉ−ＥＤＳに対するフレームにキューを入れるために機能する。
【０１８６】
出力送信転送レディハンドラ機能は、更新されたフレームをＥ−ＤＳに放流し、Ｅ−ＥＤＳに対するフレームにキューを入れるために使用される。このエントリポイントは、ｆｃｐ＿ｓｎｄ＿ｘｆｒ＿ｒｄｙ＿ｅであり、そのパスは、ＵＰＳＴＲＥＡＭ−ＩＮＧＲＥＳＳ−ＸＦＥＲ  ＲＥＡＤＹである。呼び出し側は、ＦＣＰである。入力は、データプールにおけるフレームのコンテンツである。出力送信転送レディハンドラの機能は、データプールからＥ−ＤＳに更新された情報の放流、およびＦＣＢページ｛ＱＩＤ｝を設定し、Ｅ−ＥＤＳに対するフレームにキューを入れるために、Ｉｎｔｉａｔｏｒ−Ｒａｉｎｉｅｒへのフレームの送信を含む。
【０１８７】
入力送信ハンドル応答機能は、再度Ｉｎｔｉａｔｏｒ  Ｒａｉｎｉｅｒにコマンドハンドルを送るためにターゲットＲａｉｎｉｅｒによって使用される。このエントリポイントは、ｆｃｐ＿ｓｎｄ＿ｈｎｄｌ＿ｒｅｓｐ＿ｉであり、そのパスは、ＤＯＷＮＳＴＲＥＡＭ−ＩＮＧＲＥＳＳ−ＣＯＭＭＡＮＤである。呼び出し側は、ＦＣＰである。入力は、データプールにおけるフレームのコンテンツである（６ワード）。
【０１８８】
入力送信ハンドル応答の機能は、Ｉ−ＤＳバッファをリースすること、ハンドル応答フレームを構築すること、およびＦＣＢページ２｛ｉＵＣＭＣ，ＦＨＦ，ＦＨＥ，ＴＢ，ＴＤＭＵ，ＷＢＣ｝を設定し、Ｉ−ＥＤＳに対するフレームにキューを入れるために、Ｉｎｔｉａｔｏｒ−Ｒａｉｎｉｅｒへのフレームの送信を含む。
【０１８９】
出力フィルタＦＣ−フレーム機能は、出力入来フレームを有効にするために使用される。このエントリポイントは、ｆｃｐ＿ｆｉｌｔｅｒ＿ｆｃｐ＿ｅｆｒｍであり、そのパスは、ＸＸＸ−ＥＧＲＥＳＳ−ＸＸＸである。呼び出し側は、ＦＣＰである。この入力は、データプール（コマンドフレームに対して６ＱＷ／他のものに対して４ＱＷ）におけるフレームのコンテンツである。出力フィルタＦＣフレームの機能は、チェックサムを実行することを含み、全てがオーケーである場合呼び出し側に戻し、他の場合では、エラーイベントハンドラーを呼び出す（ｆｃｐＩｎｖａｌＣｈｅｃｋＳｕｍＥｆｒｍ）。
【０１９０】
出力無効チェックサム機能は、任意の出力フレーム上のチェックサムエラーを処理するために使用される。エントリポイントは、ｆｃｐＩｎｖａｌＣｈｅｃｋＳｕｍＥＦｒｍである。呼び出し側はＦＣＰである。出力無効チェックサムの機能は、エラーをログすること、およびフレームを放棄することを含む（すなわち、Ｅ−ＤＤＱに対するフレームにキューを入れる）。
【０１９１】
入力有効フレームルーティング情報機能は、フレームルーティング情報を有効にするために使用される。エントリポイントは、ｆｃｐ＿ｖａｌ＿ｒｉ＿ｉである。呼び出し側は、ＦＣＰである。入力は、データプールにおけるフレームのコンテンツおよびＳｃｒａｔｃｈＭｅｍｌにおけるＩＯＣＢのコンテンツを含む。機能は、ＩＯＣＢおよび入来フレーム内のルーティング情報を比較すること、ミスマッチがある場合、エラーを処理するためにｃｐＩｎｖａｌｌＦｒｍＩｎｆｏを呼び出すことを含む。
【０１９２】
出力有効フレームルーティング情報機能は、フレームルーティング情報を有効にするために使用される。エントリポイントは、ｆｃｐ＿ｖａｌ＿ｒｉ＿ｅである。呼び出し側は、ＦＣＰである。入力は、データプールにおけるフレームのコンテンツおよびＳｃｒａｔｃｈＭｅｍｌ内のＩＯＣＢのコンテンツを含む。機能は、ＩＯＣＢおよび入来フレームにおけるルーティング情報を比較すること、ミスマッチがある場合には、エラーを処理するためにｆｃｐＩｎｖａｌＥＦｒｍＩｎｆｏの呼び出しと、他の場合は、フレームのルーティング情報を交換することを含む。
【０１９３】
入力無効ＦＣフレーム情報機能は、ＩＯＣＢとフレームコンテンツとの間のミスマッチ情報を処理するために使用される。エントリポイントは、ｆｃｐＩｎｖａｌｌＦｒｍＩｎｆｏであり、呼び出し側は、ＦＣＰである。機能は、エラーのログを取ることおよびフレームを放棄すること（すなわち、Ｅ−ＤＤＱに対するフレームをキューに入れる）を含む。
【０１９４】
出力無効ＦＣフレーム情報機能は、ＩＯＣＢとフレームコンテンツとの間のミスマッチ情報を処理するために使用される。このエントリポイントは、ｆｃｐＩｎｖａｌｌＦｒｍＩｎｆｏであり、呼び出し側は、ＦＣＰである。機能は、エラーのログを取ることおよびフレームを放棄すること（すなわち、Ｉ−ＤＤＱに対するフレームをキューに入れる）を含む。
【０１９５】
放棄Ｅ−フレームハンドラ機能は、出力入来フレームを放棄するために使用される。その機能は、入力放棄キュー（すなわち、Ｅ−ＤＤＱ）に対するフレームにキューを入れることを含む。
【０１９６】
このセクションは、ピココードサブシステムにおけるＳＣＳＩマネージャコンポーネント（ＳＭ）を説明する（図１２参照）。ＳＭの主な責任は、フレームからのＳＣＳＩ特有情報を処理することである。サーバから入ってくる各コマンドフレームに対して、ＳＭは、ＨＬＵＮが存在するかどうかを決定する。キーを構築し、それをツリー検索エンジンに送信するために、ＦＣ−ＬＵＮ、ＤｅｖＨａｎｄｌｅ、およびＳＰにおけるエントリポートを使用する。その検索が成功する場合、その結果を開始ＬＢＡおよびブロック数と共にＬＭに送る。他の場合は、コマンドを拒絶するか、またはそのコマンドを処理するためにＳＰにそのコマンドを送信するかのいずれかを試みる。
【０１９７】
ＬＭは、パス、物理ターゲット、ＬＢＡを選択し、それらを再度送る。次いで、ＳＭは、ＣＤＢにおけるＬＢＡを改変し、コマンドをターゲットＳＰに送信するようにＦＣＰにコマンドを送信する。
【０１９８】
ＳＭは、動作コードクラシファイアテーブルを使用して、ＳＣＳＩコマンド上でどのように動作するかを決定する。この動作コードクラシファイアテーブルは、制御ストアメモリから割り当てられる２５６エレメントのアレイである。各エレメントは、複数のフラグを含む。
【０１９９】
これらのフラグは以下のようである。Ｉｓ−Ｒｅａｄ−Ｏｐｃｐｄｅは、設定された場合、動作コードが読み出すことを識別する（すなわちＲｅａｄ１０）。Ｉｓ−Ｗｒｉｔｅ−Ｏｐｃｐｄｅは、設定された場合、動作コードが書き込むことを識別する（すなわちＷｒｉｔｅ１０）。Ｉｓ−Ｒｅｓｅｒｖｅ−Ｏｐｃｐｄｅは、設定された場合、動作コードガ保存すること識別する（すなわちＲｅｓｅｒｖｅ６）。Ｉｓ−Ｒｅｌｅａｓｅ−Ｏｐｃｐｄｅは、設定された場合、動作コードが分解することを識別する（すなわちＲｅｌｅａｓｅ６）。Ｏｐｃｏｄｅ−Ｉｓ−Ａｌｌｏｗｅｄ−Ｗｉｔｈｏｕｔ−ＨＬＵＮは、設定された場合、動作コードＬＵＮが存在するかどうかを可能にされるかどうかを識別する（すなわちＲｅｐｏｒｔ  ＬＵＮＳ）。Ｏｐｃｏｄｅ−Ｉｓ−Ａｌｌｏｗｅｄ−Ｗｉｔｈ−ＵＡ−Ｓｅｔは、設定された場合、動作コードがＬＵＮ上のユニット集中条件が設定されることを可能にすることを識別する（すなわちＩｎｑｕｒｙ）。Ｏｐｃｏｄｅ−Ｉｓ−Ｎｏｔ−Ａｆｆｅｃｔｅｄ−Ｂｙ−Ｒｅｓｅｒｖａｔｉｏｎは、設定された場合、動作コードが保存衝突によって影響されないを識別する（すなわちＲｅａｄ  Ｂｌｏｃｋ  Ｌｉｍｉｔｓ）。
【０２００】
各エレメントにおけるフラグは、テーブル内のその位置に従って初期化される。ＳＭは、このテーブルにインデックス付けするためにコマンドフレームからのＳＣＳＩ動作コードを使用する。テーブルからのフラグに基づいて、ＳＭは、どのコードパスを取るかを決定し得る。動作コードクラシファイアを参照する場合、以下の式が使用される。
【０２０１】
クラシファイアアドレス＝クラシファイア−テーブル−アドレス＋ＳＣＳＩ−動作コード
ＳＭは、複数のパブリックインターフェースを特徴とする。１つは、上流入力コマンド（Ｅ−タイプ＝ＣＭＤ−Ｉ）である。エントリポイントは、入力側を介してサーバから入るコマンドフレームを処理する。エントリポイントは、Ｓｍ＿ｃｍｄ＿ｉであり、ＦＣＰによって呼び出される。このパブリックインターフェースは、データプール（９６バイト）におけるコマンドフレーム、ｗ２８におけるＩＯＣＢアドレス、ｗ３０におけるＩＯＣＢステージング領域アドレス、およびＳｃｒａｔｃｈ１におけるＩＯＣＢを期待する。このパブリックインターフェースはまた、コマンドフレーム（上流ハンドル）において満たされるべき自己ハンドル、ならびにＩＯＣＢにおいて保存される自己およびピアＦＣ−ＩＤを期待する。
【０２０２】
上流入力コマンドによって取られたステップは、ｈｌｕｎ（ＤｅｖＨａｎｄｌｅ、ＦＣＬＵＮ、Ｐｏｒｔ）の検索を開始およびコマンドフレームからの情報を翻訳することを含み、必要ならば、ＬＢＡ、複数のブロック数、全体のバイトカウント、およびデータ方向を含むＩＯＣＢにこれらの情報を保存する。他のステップは、実行バイトカウントを初期化すること、検索結果（ＴＳＲ０において予測された）を獲得すること、ｈｌｕｎが存在しない場合、ｓｍ＿ｎｏ＿ｈｌｕｎ＿ｈａｎｄｌｅｒを呼び出すこと、動作コードが読み出されず、または書き込まれない場合、ｓｍ＿ｎｏ＿ｒｄｗｒ＿ｈａｎｄｌｅｒを呼び出すことを含む。ＬＭに送られた値は、ｗ２４におけるＶｌｕｎ  ＬＢＡ、ｗ１６におけるＲ２０  ０＝ＣｏｍｍａｎｄがＲｅａｄ／Ｗｒｉｔｅではないブロックの数、およびＴＳＲ０における検索結果を含む。
【０２０３】
選択された別のステップは、ｌｍ＿ｃｍｄ＿ｉを含む。ＬＭからの予測された戻り値は、ｗ２４におけるＰｌｕｎ  ＬＢＡ、ｗ２６におけるブロックの数、ｒ２０におけるステータスコード、ｒ１８におけるネイティブデバイス（０＝ネイティブデバイス）フラグ、ｒ２１におけるターゲットデバイスＦＣ−ＬＵＮ、ＦＣＢページおよびＩＯＣＢにおいて満たされたターゲットブレード、ならびにコマンドフレームにおいて満たされたＰｌｕｎＨａｎｄｌｅを含む。
【０２０４】
ネイティブデバイスでない場合、ＬＢＡ、およびＣＤＢにおけるブロックの数（データプールメモリ）が改変される。他のステップは、コマンドフレームにおいてターゲットデバイスＦＣ−ＬＵＮで満たすこと、ｅタイプをＣＭＤ−Ｅに設定すること、ポートアクティブキューに対するＩＯＣＢにキューを入れること、そしてターゲットＳＰにコマンドを送信するためにｆｃｐ＿ｓｎｄ＿ｃｍｄ＿ｉを呼び出すことを含む。ＦＣＰは、データプールをＩ−ＤＳに、およびスクラッチ１をＣＳに更新する。
【０２０５】
別のパブリックインターフェースは、下流ＳＰを介して出力側から入るターゲットデバイスからステータスフレームを処理する上流出力ステータス（Ｅ−Ｔｙｐｅ−Ｓｔａｔ−Ｅ）である。このエントリポイントは、Ｓｍ＿ｓｔａｔｕｓ＿ｅであり、呼び出し側はＦＣＰである。
【０２０６】
このインターフェースは、データプール（６４バイト）におけるＦＣ応答フレーム、ｗ２８におけるＩＯＣＢアドレス、スクラッチ１におけるＩＯＣＢを予測する。選択されたステップは、ｆｃｐ＿ｄｉｓｃａｒｄ＿ｅを呼び出し、ステータスが最後の子に由来しない場合に戻り、必要な場合、データプールにおいて応答コードを改変し、ポートアクティブキューからＩＯＣＢをキューから外し、サーバにステータスフレームを送信するためにｆｃｐ＿ｓｎｄ＿ｓｔｓ＿ｅを呼び出し、ＩＯＣＢをフリープールに戻すことを含む。
【０２０７】
以下のパブリックインターフェースは、ＳＭを含まない。すなわち、下流出力コマンド（Ｅ−Ｔｙｐｅ＝ＣＭＤ−Ｅ）、下流入力データ（Ｅ−Ｔｙｐｅ＝Ｄａｔａ−Ｉ）、上流出力データ（Ｅ−Ｔｙｐｅ＝Ｄａｔａ−Ｅ）、および下流入力読み出しステータス（Ｅ−Ｔｙｐｅ＝Ｓｔａｔ−Ｉ）である。
【０２０８】
ＳＣＳＩマネージャは、２つの内部インターフェースを有する。すなわち、ｓｍ＿ｎｏ＿ｈｌｕｎ＿ｈａｎｄｌｅｒおよびｓｍ＿ｎｏ＿ｒｄｗｒ＿ｈａｎｄｌｅｒである。
【０２０９】
ｓｍ＿ｎｏ＿ｈｌｕｎ＿ｈａｎｄｌｅｒエントリポイントは、現存しないｈｌｕｎを目標とするコマンドフレームを処理し、これはＳＭによって呼び出される。このインターフェースは、データプール（９６バイト）におけるコマンドフレーム、ｗ２８におけるＩＯＣＢアドレス、ｗ３０におけるＩＯＣＢステージング領域アドレス、およびスクラッチ１におけるＩＯＣＢを予測する。
【０２１０】
選択されたステップは、動作コードがＥ４０５によって処理される必要がある場合（すなわち、照会、レポートＬＵＮ）、ｓｍ＿ｎｏ＿ｒｄｗｒ＿ｈａｎｄｌｅｒを呼び出すこと、Ｉ−ＤＳバッファを放棄するためのｆｃｐ＿ｄｉｓｃａｒｄ＿ｉを呼び出すこと、データプールにおけるステータスペイロードを構築すること、そしてｆｃｐ＿ｓｎｄ＿ｎｅｗ＿ｓｔｓ＿ｅを呼び出すことを含む。なお、ＦＣＰは、新しいツインバッファを割り当て、新しいＦＣＢページを構築し、そしてフレームをサーバに送信する。
【０２１１】
ｓｍ＿ｎｏ＿ｒｄｗｒ＿ｈａｎｄｌｅｒエントリポイントは、読み出しまたは書き込み以外のコマンドフレームを処理し、ＳＭによって呼び出される。このインターフェースは、データプール（９６バイト）におけるコマンドフレーム、ｗ２８におけるＩＯＣＢアドレス、ｗ３０におけるＩＯＣＢステージング領域アドレス、およびスクラッチ１におけるＩＯＣＢを予測する。
【０２１２】
選択されたステップは、Ｉ−ＤＳバッファを放棄するためにｆｃｐ＿ｄｉｓｃａｒｄ＿ｉを呼び出すこと、ポートアクティブキューのためにＩＯＣＢにキューを入れること、およびコマンドを処理するためにＳＰに送信することを含む。
【０２１３】
このセクションは、ピココードシステム（図１２を参照）におけるＬｕｎ  Ｍａｎａｇｅｒコンポーネントを説明する。ＬＭサブシステムは、仮想リクエストを物理リクエストに分解することを担っている。ＬＭサブシステムは、サーバからのリクエストにおける開始ＬＢＡおよびブロックの数を参照し、デバイスがネイティブデバイスかまたは仮想デバイスかどうかを決定する。
【０２１４】
ＬＭサブシステムはまた、開始ＬＢＡおよび物理リクエストのブロックの数を識別し、必要な場合、仮想リクエストをいくつかの物理ＩＯに分解する。このＬＭサブシステムは、新しい物理リクエストが送信されるべき場所を決定する。
【０２１５】
ｅ４０５／Ｉｃ４４０（仮想サーバカード）上のテーブルに保持された情報は、ＳＰ上でその全体において複製される必要はない。なぜならＳＰは、コマンドの小さいサブセットを処理するだけであり、ＴＳＥ上のリーフサイズ制限のためである。多くのバイトフィールドおよびハーフワードフィールドは、このツリー検索メモリにアクセスする場合、サイクルを保存するために、３２ビットワードにマージされている。次いで、このワードフィールドは、ピココードによって分解されなければならない。これは高速である。なぜなら、各パイコスレッドは、その自己レジスタセットを有するためである。ＴＳメモリを用いると、他のスレッドからの競合が存在する。
【０２１６】
ＨＬＵＮ構造は、サーバとＶＬＵＮを結合する。このＨＬＵＮエントリは、ＶＬＵＮｋｅｙ、ＳＥＲＶＥＲｋｅｙを含む。ツリー検索ルックアップがリーフを生成しない場合、
これは、このサーバがリクエストされたＬＵＮを見るように割り当てられないことを意味する。ＨＬＵＮを生成するためにＴＳＥに供給されたキーは、コマンドのソースポート、ＦＣＬＵＮ、およびメッセージヘッダからのＤｅｖＨａｎｄｌｅである。
【０２１７】
ＨＬＵＮはサーバＬＵＮとＶＳＸ  ＶＬＵＮとの間の結合である。サーバｐｄｅｖｐａｔｈのためのキーは、サーバ構造を参照するために使用される。ＶＬＵＮのためのキーは、ＶＬＵＮ構造を参照するために使用される。
【０２１８】
ＨＬＵＮリーフ構造は、以下のように示される。
【０２１９】
【数１】
0004457185.tif 000002
上記で示された構造は、ＳＰツリーメモリにおけるリーフデータとして格納されるものである。このリーフは、ＤｅｖＨａｎｄｌｅの検索、コマンドＦＣＬＵＮ、およびポート数を介して見出される。ｖｌｕｎＫｅｙフィールドは、ＶＬＵＮリーフを検索するためのキーとして使用される。ｉｎｉｔｉａｔｏｒＫｅｙフィールドは、イニシエータＰＤＥＶＰＡＴＨリーフを検索するためのキーとして使用される。フラグフィールドの意図が使用され、保存、ゾーニング、およびｕａ２９を示すために使用される。ｆｃａＰｏｒｔＮｐＰｏｒｔフィールドは、リクエストが来た場所のソースＦＣＡＳＩＣポート識別子（上部２ビット）およびソースＳＰポート（ＤＤｐｐｐｐにおける下部６ビット）フォーマットである。
【０２２０】
ＶＬＵＮリーフは、その構成と共にＶＬＵＮに関する情報を含む。ＶＬＵＮは、ＰＬＵＮのセクションから構成され得る。このセクションは、スライスとして公知である。
【０２２１】
ＶＬＵＮは、ＶＬＵＮが構成されるものを説明する構造である。このＶＬＵＮは、以下の特徴を含む。ＬＵＮタイプは、仮想ＶＳＸデバイスであってもよいしネイティブデバイスであってもよい。状態は、ＶＬＵＮの状態を示す。全体のブロックは、ＶＬＵＮに関する複数のブロックの数を示す。ブロックサイズは、バイト／ブロックの数を示す。
【０２２２】
ＶＬＵＮはまた、そのスライスに関する情報を含む。ＶＬＵＮは、多くのＰＬＵＮを含み得る。各コンポーネントはスライスと呼ばれる。この保持されたスライス情報は、以下のものを含む。ＳＬＩＣＥ＿ＥＮＤは、ＶＬＵＮに関するスライスの末端である。ＳＬＩＣＥ＿ＯＦＦＳＥＴは、ＰＬＵＮ内部のオフセットである。ＳＬＩＣＥ＿ＢＬＫＳは、スライス内部のブロックの数である。ＰＬＩＮ＿ＫＥＹは、ＰＬＵＮを検索するためのキーである。このキーは、スライスに関する。
【０２２３】
スライスは、ＶＬＵＮ構造の一部として保持される。このピココードは、ＩＯがどのＰＬＵＮに行くのかを決定するためにスライスを介して移動する。これに関して、３つまでのスライスのみの余地があり得る。
【０２２４】
一旦、ＶＬＵＮリーフがツリー検索から生成されると、ピココードが、どのスライスがリクエストに含まれるかを見るためにスライスを移動させる。一旦正確なスライスが識別されると、ＬＭは、リクエストの新しい開始ＬＢＡを計算し、ｗｋｓを更新するために、ｓｌｉｃｅＯｆｆｓｅｔを使用する。スライス境界を横切るリクエストが処理され得、ＬＭはまた、リクエストされたブロックを計算し得る。
【０２２５】
同時に、ＰＬＵＮに対する検索は、スライスにおけるｐＬｕｎＫｅｙを使用して開始される。これは、ＰＬＵＮリーフを生成する。
【０２２６】
ＶＬＵＮからスライスを分離するために、ローピングを有するＬＰＭ検索機構が使用され得る。スライスへの検索は、スライステーブルにおいてリーフを生成する、コマンド開始ブロックアドレスを有するＶＬＵＮキーを使用する。次いでピココードは、ローピングサービスによって提供されるリンクしながら、リーフ内の次のエレメントのアドレスを移動させることによって次のスライスに行き、リンクはローピングサービスにおいて提供される。
【０２２７】
ＶＬＵＮリーフ構造は以下のとおりである。
【０２２８】
【数２】
0004457185.tif 000003
上記で示された構造は、ＳＰツリー検索メモリにおけるリーフデータとして格納されるものである。このリーフは、ＨＬＵＮに見出されたｖｌｕｎＫｅｙから見出される。ｖＴｙｐｅフィールドは、ＶＬＵＮが、ネイティブデバイス、連結、区分、ミラーまたはストライプであるかどうかを識別する。ｓｃｓｉＤｅｖＴｙｐｅは、デバイスがＤＩＳＫ、ＴＡＰＥ、ＳＡＣＬ等であるかどうかを識別する。状態フィールドは、ＶＬＵＮの状態を示し、０値は、それが動作的であることを識別する。ｔｏｔａｌＢｌｋｓフィールドは、ＶＬＵＮの全体の能力を特定し、このフィールドは、リクエストの束縛（ｂｏｕｎｄ）をチェックするためにピココードによって使用される。このｂｌｋＳｉｚｅフィールドは、ＶＬＵＮに対してバイト／ブロックであり、リクエストバイト数を計算するために使用され得る。
【０２２９】
ＶＬＵＮにおいて３つのスライスが存在し、ＶＬＵＮが３つの物理デバイスから構成されることを可能にする。単一のスライスにおけるフィールドは、以下のように示される。
【０２３０】
ｓｌｉｃｅＥｎｄフィールドは、スライスにおけるＶＬＵＮのブロック数を終了することである。ｓｌｉｃｅＯｆｆｓｅｔフィールドは、スライス中のＰＬＵＮへのオフセットである。ｓｌｉｃｅＢｌｋｓフィールドは、スライス中のブロックの数である。ｐｌｕｎＫｅｙフィールドは、そのスライスが関連付けられるＰＬＵＮを検索するために使用される。
【０２３１】
ＰＬＵＮｕｐテーブルは、ＰＬＵＮを検索するために上流ＳＰ上で使用される。下流ＳＰによって使用されたＰＬＵＮｄｏｗｎテーブルが存在する。このＰＬＵＮｄｏｗｎテーブルは、より小さいリーフサイズを含む。
【０２３２】
ＰＬＵＮリーフは、以下の情報を含む。ＬｕｎＮｕｍｂｅｒは、物理的ｌｕｎ数である。このブロックサイズは、物理ＬＵＮのためのバイト／ブロックである。ターゲットＤＭＵは、どのＤＭＵにこのリクエストを下流に送信するか、２つの出力データ格納が存在するために重要であるかを特定するフィールドである。ＤＳ０／１に関する限り、ＤＳ０は、ＤＭＵ  Ａ／Ｂに接続され、ＤＳ１は、ＤＭＵ  Ｃ／Ｄに接続される。このターゲットＤＳフィールドは、出力側上のどのＤＳにリクエストを送信するかを特定する。このターゲットブレードフィールドは、リクエストのターゲットブレード数を特定する。
【０２３３】
ＰＬＵＮリーフはまた、キーがＰＬＵＮまたはＰＤＥＶＰＡＴＨの検索のために使用されるかどうかを特定する下流ＬＩＤを含む。下流ＬＩＤは、ＰＬＵＮまたはＰＤＥＶＰＡＴＨを検索するために下流ＳＰにより用いられるキーである。ＭＳＢは、キーがＰＬＵＮまたはＰＤＥＶＰＡＴＨを検索するために使用されるかどうかを特定する。下流ＳＰは、デバイスに対する複数のパスを有する場合、このキーはＰＬＵＮを検索するために使用され、他の場合は、ＰＤＥＶＰＡＴＨを検索するために使用される。
【０２３４】
ＬＭは、ＶＬＵＮリーフにおけるｐｌｕｎＫｅｙを用いてＰＬＵＮリーフを検索する。このリーフから、ＬＭは、物理ｆｃｌｕｎフィールドを用いてレジスタを更新し、パスを選択した後、ＦＣＢページＴＢフィールドを更新し、ＦＣＢページターゲットＤＭＵ／ＤＳＵフィールドを更新し、そしてＰａｔｈＬＩＤを用いてイーサネット（Ｒ）封入ヘッダーを更新し得る。
【０２３５】
ＰＬＵＮリーフ構造は、以下のようである。
【０２３６】
【数３】
0004457185.tif 000004
0004457185.tif 000005
ｌｕｎＮｕｍフィールドは、ポートの後ろにあるＬＵのＬＵ数である。ｔｏｔａｌＢｌｋｓは、ＬＵにおける全体のブロックである。ｂｌｋＳｉｚｅは、ＬＵのブロックサイズである。ｐｒｅｆＰａｔｈフィールドは、どのパスを使用するかについてのインジケータであり、静的パスの選択である。パスが変更されることを必要とする場合、ＳＭＳは、フィールドを更新する。ｐａｔｈＳｔフィールドは、パスの状態を示すために使用される。ｐａｔｈＰｏｒｔＤｍｕＤｓｕは、ターゲットブレードＤＭＵおよびＤＳＵを示すために使用され、ＦＣＢページレジスタをプログラムする場合に使用される。
【０２３７】
ｂｌａｄｅＱｉｄフィールドは、ターゲットブレードおよびソースＱＩＤの連結である。ＱＩＤは、ソースルーティング情報にプログラムされ、応答が出力側に戻る場合にＦＣＢページにプログラムするために使用され得る。
【０２３８】
ｐａｔｈＬｉｄフィールドは、下流ＳＰの検索として使用される。ｐａｔｈＬｉｄにおいて、ＭＳｂｉｔは、デバイス下流に対する複数のパスが存在するかどうかを示す。ＭＳｂｉｔがクリアである場合、単一パスのみが存在する。次いでこのｐａｔｈＬｉｄは、ｐｄｅｖｐａｔｈ下流を検索するために使用される。ＭＤｂｉｔが設定される場合、ルックアップは、ＰＬＵＮを検索する。
【０２３９】
上流側では、ＬＭは、イーサネット（Ｒ）封入ヘッダーのＬＬＣフィールドを調べ、ＬＩＤを抽出する。このＬＩＤは、ＰＬＵＮｄｏｗｎリーフまたはｐＤｅｖｐａｔｈリーフのいずれかを直接検索するために使用され得る。下流ＳＰ上でＰＬＵＮに対する多重パスが存在する場合、ＬＩＤは、ＭＰＡＴＨビットセットを有する。次いでこのＬＩＤは、リーフに対するＰＬＵＮｄｏｗｎツリーを検索するためにＴＳＥに対するキーとして使用される。ＭＰＡＴＨビットがクリアである場合、単一パスのみが存在し、ＬＩＤは、ｐＤｅｖＰａｔｈツリーを直接検索するために使用される。
【０２４０】
ＰＬＵＮｄｏｗｎリーフは、以下を含む。ｐｒｅｆＰａｔｈは、使用するのに好ましいパスである。ｐａｔｈＳｔａｔｅは、特定のパスの状態である。ｐａｔｈＫｅｙは、ｐＤｅｖＰａｔｈリーフを検索するために使用される。ＬＭは、ｐｒｅｆＰａｔｈおよびｐａｔｈＳｔａｔｅフィールドを用いてパスを選択し、ｐＤｅｖＰａｔｈツリー上の検索を開始する。
【０２４１】
ＰＬＵＮｄｏｗｎ構造は、以下のようである。
【０２４２】
【数４】
0004457185.tif 000006
ＰＬＵＮｄｏｗｎ構造は、下流側上で使用される。ｐｒｅｆＰａｔｈ構造は、ＰＬＵＮに対する３つの可能なパスを選択するために使用される。ｐａｔｈＳｔａｔｅフィールドは、パスの状態を示す。ｐａｔｈＫｅｙは、ｐＤｅｖｐａｔｈリーフを検索するためのキーとして使用される。
【０２４３】
ｐｄｅｖｐａｔｈは、ストレージまたはサーバへの物理接続を表し得る構造であるが、物理ストレージの後ろのＬＵＮを表さない。ｐｄｅｖｐａｔｈは、以下のものを含む。
【０２４４】
ＦＣ＿ＩＤは、サーバまたはストレージＦＣ  ｉｄである。ＭａｘＲｘＤａｔａフィールドは、ストレージ／サーバが受信し得る最大フレームサイズを示す。Ｂｂｃｒｅｄｉｔフィールドは、サーバ／ストレージがＬＯＧＩＮプロセスの間に与えられたＢＢクレジットの数である。ポートは、サーバ／ストレージが取り付けられるＳＰ上のポート数である。
【０２４５】
ｐＤｅｖＰａｔｈリーフは、ストレージデバイスに対するサーバまたはパスを表し得る。サーバｐＤｅｖＰａｔｈに対するキーは、ＨＬＵＮリーフにおけるフィールドから来る。デバイスｐＤｅｖＰａｔｈに対するキーは、下流ＳＰ上のイーサネット（Ｒ）封入ヘッダーにおけるＬＩＤから来る。
【０２４６】
ｐＤｅｖＰａｔｈリーフ構造は以下のようである。
【０２４７】
【数５】
0004457185.tif 000007
ｐｏｒｔＨａｎｄｌｅフィールドは、ＦＣＡＳＩＣに対して公知である物理デバイスへのハンドルである。ピココードが物理デバイスに対するＩＯを実行する場合、そのハンドルがデバイスを識別するためにＦＣＡＳＩＣにこのハンドルを送る。このポートフィールドは、ＤＤｐｐｐｐフォーマットにおけるＳＰポート数である。ｆｃａＰｏｒｔフィールドは、ＦＣ  ＡＳＩＣポートアイデンティティである。
【０２４８】
ポート構造は、それら自身のＳＰポートに関する情報を含む。ポート構造は、ＦＣＰコードによって使用されるＦＣＩＤ等の情報を含む。このポート構造は、ツリー検索メモリ内にある。ＳＰ上に少数のポートしかないために、参照は、ポートＣＢアドレスを見出すためのアレイへのインデックスを用いてなされる。これは、ＴＳエンジンを用いるよりもより高速であるべきである。
【０２４９】
以下の段落は、どのようにしてＴＳＥ内部にあるＬＭテーブルが集められるかを示す。
【０２５０】
ＴＳＥにおけるＬＭテーブルは、仮想サーバカードにおけるＬＭから集められるようになる。ＶＳＣにおけるＬＭは、ピココードによって使用された構造にと類似の構造を有する。これらの間の差は、ピココード構造がよりコンパクトかつ集積されていることである。
【０２５１】
ＰＤｅｖＰａｔｈリーフ（以下の構造を参照）は、ＳＰ上の物理デバイスのために存在し、そのデバイス上にそれが取り付けられることにより、ｐＤｅｖＰａｔｈリーフは、ストレージデバイスまたはイニシエータが取り付けられるＳＰ上にプログラムされる。
【０２５２】
リーフにおけるｐＤｅｖＰａｔｈフィールドは、ＶＳＣにおけるＰＤＥＶＰＡＴＨ構造から全体的に満たされる。
【０２５３】
【数６】
0004457185.tif 000008
ｆｃａＤｅｖＨａｎｄｌｅは、ＶＳＣ（ｅ４０５とも呼ばれる）ｐｄｅｖｐａｔｈ．ｆｃａＤｅｖＨａｎｄｌｅから満たされる。このフィールドは、新しいデバイスがＦＣ  ＡＳＩＣによって見出された場合ｅ４０５に与えられ、ＦＣ  ＡＳＩＣによって使用されたデバイスへのハンドルである。
【０２５４】
ｎｐＰｏｒｔは、ｅ４０５ｐｄｅｖｐａｔｈ．ｎｐＰｏｒｔから満たされる。このフィールドは、２つのエレメント（ポートおよびＤＭＵ）を有し、新しいデバイスが見出された場合、ｅ４０５に与えられた。このｎｐＰｏｒｔフィールドは、どのＤＭＵにデバイスが取り付けられるかを示す。ＳＰがＰＯＳフォーマットで動作しているため、ポート数は０である。
【０２５５】
ｆｃａＰｏｒｔＩｄは、ｅ４０５ｐｄｅｖｐａｔｈ．ｆｃＰｏｒｔＩｄから満たされる。デバイスが発見されたＦＣＡＳＩＣポートのアイデンティティであり、「新しいデバイスレポート」が送信される場合、ｅ４０５に与えられる。ｐｄｅｖｐａｔｈリーフをプログラムするために使用されたキーは、ｐｄｅｖｐａｔｈ．ｐｄＨａｎｄｌｅである。
【０２５６】
ＳＰ上のＰＬＵＮＵＰリーフ（以下の構造を参照）はＳＰ上に存在し、ＳＰ上には、ホストに送信されたＶＬＵＮが存在し、フレームを下流に運ぶ場所を発見するためにＳＰによって使用される。ｌｕｎＮｕｍは、ｅ４０５ｐｌｕｎ．ｂｌｕｋＣｏｕｎｔフィールドから直接的に満たされ、物理デバイスの後方にＬＵ数がある。このｔｏｔａｌｂｌｋＳｉｚｅは、ｅ４０５ｐｌｕｎ．ｂｌｋＣｏｕｎｔフィールドから満たされる。このｂｌｋＳｉｚｅは、ｅ４０５ｐｌｕｎ．ｂｌｋＳｉｚｅから満たされる。
【０２５７】
ＰＬＵＮＵＰリーフは、下流ＳＰへの３つのパスを含み、ｅ４０５ＰＬＵＮ構造におけるｐｄｅｖｐａｔｈポインタのアレイと同様である。このｐｒｅｆＰａｔｈフィールドは、特定のパスを使用するようにピココードに命令する。この構成ｓｗは、リーフ内に正確なインデックスで満たすためにｐｌｕｎ．ｐｒｅｆｅｒｒｅｄパスを調べる。
【０２５８】
ｐａｔｈＳｔフィールドは、パスの状態を示すために使用される。ｅ４０５ｐｌｕｎ．ｐａｔｈ．状態フィールドから満たされる。ｅ４０５は、このフィールドを獲得するためにＰＬＵＮからｐｄｅｖｐａｔｈ構造を向かわせる。
【０２５９】
ｐａｔｈＰｏｒｔＤｍｕＤｓｕは、下流ＦＣＡＳＩＣ  ｐｏｒｔＩｄ、ターゲット下流ＤＭＵ、およびＤＳＵの組み合わせであり、ｐｌｕｎ．ｐａｔｈ．ｆｃａＰｏｒｔＩｄおよびｐｌｕｎ．ｐａｔｈ．ｂｌａｄｅＰｏｒｔフィールドから満たされる。構成ソフトウエアは、ｐｌｕｎ．ｐａｔｈ．ｂｌａｄｅＰｏｒｔフィールドからＤＳＵを決定し得る。このＤＭＵ／ＤＳＵフィールドは前もって決定されなければならない。なぜなら、ＦＣＢページは、これらのターゲットパラメータで満たされるためである。
【０２６０】
ｂｌａｄｅＱｉｄフィールドは、ターゲット下流ブレード数およびＱＩＤパラメータの組み合わせである。このＱＩＤパラメータはスケジューラのためにあり、ｐｌｕｎ．ｐａｔｈ．ｂｌａｄｅＩｄから満たされる。このｂｌａｄｅＬｉｄフィールドは、ＰＬＵＮＤｏｗｎまたはＰＤＥＶＰＡＴＨリーフのいずれかを見出すために下流ＳＰ上のルックアップとして使用され、ｐｌｕｎ．ｐａｔｈ．ｂｌａｄｅＬｄフィールドから満たされる。
【０２６１】
このリーフをプログラムするために使用されたキーは、ｐｌｕｎ．ｐｌＨａｎｄｌｅである。
【０２６２】
【数７】
0004457185.tif 000009
ＶＬＵＮリーフ（以下の構造を参照）は、ＳＰにプログラムされ、そこでは、エクスポートされたＶＬＵＮを有するホストが存在する。ｖｔｙｐｅフィールドは、ｅ４０５ｖｌｕｎ．ｄｅｖｔｙｐｅフィールドから満たされる。この状態は、ｅ４０５ｖｌｕｎ．ｓｔａｔｅフィールドから満たされる。ｔｏｔａｌＢｌｋｓおよびｂｌｋＳｉｚｅは、ｅ４０５ｖｌｕｎ．ｔｏｔａｌＢｌｋｓおよびｖｌｕｎ．ｂｌｋＳｉｚｅフィールドから満たされる。
【０２６３】
ｖｌｕｎは、３スライスの範囲外から作成され得る。このｓｌｉｃｅＥｎｄフィールドは、スライスにおける終了仮想ブロックであり、ｅ４０５ｖｌｕｎ．ｓｌｉｃｅ．ｖｌｕｎＥｎｄから満たされる。ｓｌｉｃｅＯｆｆｓｅｔフィールドはＰＬＵＮへのオフセットであり、ｅ４０５ｖｌｕｎ．ｓｌｉｃｅ．ｐｌｕｎＯｆｆｓｅｔから満たされる。ｓｌｉｃｅＢｌｋｓフィールドは、スライス内部のブロックの数であり、ｅ４０５ｖｌｕｎ．ｓｌｉｃｅ．ｂｌｋＣｏｕｎｔから満たされる。ｐｌｕｎＫｅｙフィールドは、ＰＬＵＮを検索するためのキーとして使用され、ｅ４０５ｖｌｕｎ．ｓｌｉｃｅ．ｄｅｖ．ｈａｎｄｌｅから満たされる。
【０２６４】
このリーフをプログラムするために使用されたキーは、ｖｌｕｎ．ｈａｎｄｌｅである。
【０２６５】
【数８】
0004457185.tif 000010
ＨＬＵＮリーフ（以下の構造を参照）は、ＳＰにプログラムされ、そこでは、ホストにエクスポートされたＶＬＵＮが存在する。ｖｌｕｎＫｅｙは、ＶＬＵＮリーフを参照するために使用され、ｅ４０５ｈｌｕｎ．ｖＬｕｎ．ｈａｎｄｌｅフィールドから満たされる。ｉｎｉｔｉａｔｏｒＫｅｙは、ホストｐｄｅｖｐａｔｈリーフを参照するために使用され、ｅ４０５ｈｌｕｎ．ｓｒｃ．ｐｄＨａｎｄｌｅフィールドから満たされる。
【０２６６】
ｆｃａＰｏｒｔＤｍｕＤｓｕは、ソースｆｃａＰｏｒｔ、ＤＭＵおよびＤＳＵフィールドとして使用され、ＤＭＵを示すｈｌｕｎ．ｓｒｃ．ｆｃａＰｏｒｔＩｄおよびｈｌｕｎ．ｎｐＰｏｒｔから取られる。このＤＳＵフィールドは、ＤＭＵから見積もられる。
【０２６７】
ｅＨａｎｄｌｅフィールドは、ｅ４０５ＨＬＵＮへのハンドルであり、プロキシコマンドがＨＬＵＮ構造に高速参照を提供するために入る場合、ｅ４０５に再度送る。
【０２６８】
リーフをプログラムするために使用されたキーは、ＦＣＡＰＯＲＴＩＤ、ＤｅｖＨａｎｄｌｅ、およびＦＣＬＵＮに基づく。
【０２６９】
【数９】
0004457185.tif 000011
ＰＬＵＮＤｏｗｎリーフ（以下の構造を参照）は、ＳＰにプログラムされ、そこでは、ストレージデバイスが接続される。ｐｒｅｆＰａｔｈフィールドは、フレームを外部に送信する場合にどのパスインデックスを使用するかを示すために使用され、ｐｌｕｎ．ｐｒｅｆｆｅｒｅｄＰａｔｈフィールドから満たされる。
【０２７０】
選択するために３つのパスが存在する。ｐａｔｈＳｔａｔｅフィールドは、パスの状態を示すために使用される。これは、ｅ４０５ｐｌｕｎ．ｐａｔｈ．ｓｔａｔｅから満たされる。ｐａｔｈＫｅｙは、ｅ４０５ｐｌｕｎ．ｐａｔｈ．ｐｄＨａｎｄｌｅから満たされる。
【０２７１】
【数１０】
0004457185.tif 000012
ストレージサーバ１００は、ｌｍ＿ｃｍｄ＿ｉおよびｌｍ＿ｃｍｄ＿ｅを以下のように含む種々のパブリックインターフェースをインプリメントする。
【０２７２】
ｌｍ＿ｃｍｄ＿ｉは、新しい開始ＬＢＡおよびリクエストのためのブロックの数を計算するためにＶＬＵＮ構造を移動させる。ＰＬＵＮが複数のパスを介して接続される場合のパスを選択する。このパスはＵＰＳＴＲＥＡＭ  ＩＮＧＲＥＳＳ  ＣＯＭＭＡＮＤであり、それは、ＨＬＵＮの存在をチェックするためにそのコマンドがＴＳＥで開始した後、ＳＭ上流によって呼び出される。
【０２７３】
以下のデータが使用される。ＩｏＣＢは、スクラッチ１に共有されたメモリであるべきである。ＨＬＵＮに対するツリー検索結果は、ＴＳＲ０領域にあるべきである。フレームはデータプールにあるべきである。Ｗ２４は、ＬＢＡを有するべきであり、ｗ２６は、ブロックの数を有するべきである。
【０２７４】
Ｒ２０は、ＲＤＷＲフラグ、すなわち０＝ＲＤＷＲ、１＝ＮＯＴ  ＲＤＷＲコマンドである。ＲＤＷＲコマンドでない場合、ＬＭは、ｓｔａｒｔＬＢＡおよびｒｅｑＢｌｋｓを修正しない。
【０２７５】
以下のデータが修正される。Ｉｏｃｂ．ｈｐＬｕｎは、ｈｌｕｍのリーフアドレスを有する。ＰｌｕｎＨａｎｄｌｅは、下流のために使用され、参照がＴＡＧＳに挿入され、ポートハンドルフィールドｗ２４は、物理ＬＢＡを有し、そしてＷ２６は、ブロックの物理的な数を有する。ＦＣＢページＴＤＭＵレジスタが更新される。ＦＣＢページＤＳＵレジスタが更新される。
【０２７６】
ＦＣＢページＴＢレジスタがターゲットブレードを用いて更新される。ＴＡＧＳ．ｓｒｃ．ＴＢは、このＳＰのＴＢを用いて改変される。ＴＡＧＳ．ｓｒｃ．ＱＩＤは、上流側でキューを入れるために使用されたターゲットポートを用いて改変される。ＴＡＧＳ．ｓｒｃ．ＦＣＡｐｏｒｔは、上流ＦＣＡＳＩＣポート識別子を用いて改変される。ＴＡＧＳ．ｓｒｃ．ＤＭＵは、データをイニシエータに戻すために使用された上流ＤＭＵを用いて修正される。ＴＡＧＳ．ｓｒｃ．ＤＭＵは、データをイニシエータに戻すために使用された上流ターゲットＤＳユニットを用いて修正される。
【０２７７】
ＩｏＣＢ．ｒｉＴｂｌａｄｅは、ターゲットブレードで満たされる。ＩｏＣＢ．ｒｉＴｑｉｄは、ターゲットＯＩＤで満たされる。ＩｏＣＢ．ｒｉＰｏｒｔＤｍｕＤｓｕは、ターゲットポート、ＤＭＵ、ＤＳＵで満たされる。
【０２７８】
復帰データは以下のようである。Ｒ２０−ｖｓｘｓｔａｔ．ｉｎｃにおいて定義されたようなステータス、Ｒ２１−ＦＣＬＵＮ、Ｒ１８−ＶＬＵＮがネイティブである場合０、ＶＬＵＮがＮＯＴネイティブである場合１、Ｗ２４−新しいｓｔａｒｔＬＢＡ、およびＷ２６−新しいＲｅｑＢｌｋｓである。
【０２７９】
パケットＬＬＣフィールドにおいて送られたｐｌｕｎＨａｎｄｌｅからなされる場合、ｌｍ＿ｃｍｄ＿ｅは、物理デバイスへのパスを選択するために使用される。パスは、ＤＯＷＮＳＴＲＥＡＭ  ＥＧＲＥＳＳ  ＣＯＭＭＡＮＤであり、コマンドパケットを受信した後にＦＣＰ下流によって呼び出される。このコマンドは、スクラッチ１によって共有されたメモリに格納されたＩｏＣＢを含む種々の入力を使用する。
【０２８０】
修正されたデータは、宛先ターゲットブレードを用いて改変されたＴＡＧＳ．ｄｓｔ．ＴＢ、知られている場合、下流側でキューを入れるために使用されたターゲットポートを用いて改変されたＴＡＧＳ．ｄｓｔ．ＱＩＤを含む。他の改変されたデータは、下流ＦＣＡＳＩＣポート識別子を用いて改変されたＴＡＧＳ．ｄｓｔ．ＦＣＡｐｏｒｔ、公知の場合、宛先ターゲットＤＳＵを用いて修正されたＴＡＧＳ．ｄｓｔ．ＤＭＵ、宛先ターゲットＤＳＵを用いて改変されたＴＡＧＳ．ｄｓｔ．ＤＳＵを含み、ＩｏＣＢ．ｔｇｔＰｏｒｔは、デバイスに接続されたＳＰポート数を有する。
【０２８１】
さらに改変されたデータは、ＩｏＣＢ．ｍａｘＲｘＤａｔａを含み、ＩｏＣＢ．ｍａｘＲｘＤａｔａは、デバイスが受信し得る最大データを有し、ＩｏＣＢ．ｈｐＬｕｎは、ｐｌｕｎのリーフアドレスを有し、そしてＩｏＣＢ．ｐｒｅｆＰａｔｈは、選択された好適なパスを有する。
【０２８２】
復帰データは、Ｒ２０−ｖｓｘｓｔａｔ．ｉｎｃにおいて定義されたようなステータス、Ｒ２１−デバイスのｍａｘＲｘｄａｔａ、およびＲ１５［１］−出力ポートを含む。
【０２８３】
動作中では、コードは、イーサネット（Ｒ）ＬＬＣヘッダーフィールドにおける上流ＳＰから送られたハンドルを抽出する。このハンドルがマルチパスビットセットを有する場合、ハンドルは、ＰＬＵＮツリー内で検索するために使用される。ＰＬＵＮリーフからパスが選択される。ＰＬＵＮリーフ内の各パスはキーを有する。このキーは、ＰＤＥＶＰＡＴＨテーブルを介して検索するために使用される。このＰＤＥＶＰＡＴＨリーフは、デバイス情報を有する。ＰＤＥＶＰＡＴＨ内部では、ポートは、別のＰＤＥＶＰＡＴＨリーフであるＦＣＰＯＲＴ構造を検索するために使用される。
【０２８４】
マルチパスビットがＮＯＴセットである場合に、デバイスへの単一のパスのみが存在する。このキーは、ＰＤＥＶＰＡＴＨテーブルを直接調べるために使用される。これは、デバイスＰＤＥＶＰＡＴＨリーフを提供する。ＦＣＰＯＲＴ構造の検索がさらに実行される。
【０２８５】
上記説明が特定の実施形態に集中されてきたが、種々の代替および均等物が当業者の理解の範囲内にある。従って、本発明は、以下の特許請求の範囲およびその均等物に関して規定される。
【図面の簡単な説明】
【０２８６】
【図１】図１は、本発明の実施形態によるストレージサーバを含むストレージエリアネットワークのブロック図である。
【図２Ａ】図２Ａは、本発明の実施形態によるストレージサーバにおけるハードウエアコンポーネントのブロック図である。
【図２Ｂ】図２Ｂは、本発明の実施形態によるストレージサーバにおける管理機能のブロック図である。
【図３】図３は、本発明の実施形態による、ＰＬＵＮ、メディアユニット、およびＶＬＵＮ間の関係を示す図である。
【図４】図４は、本発明の実施形態による上流および下流コンポーネントを示すブロック図である。
【図５】図５は、本発明の実施形態によるコマンドおよびデータ処理を示すフローチャートである。
【図６】図６は、本発明の実施形態によるツリー検索エンジンの処理を示すフローチャートである。
【図７】図７は、本発明の実施形態によるルーティング情報のデータ図である。
【図８】図８は、本発明の実施形態によるコマンドフレームのデータ図である。
【図９】図９は、本発明の実施形態によるコマンドフレームのタグフィールドのデータ図である。
【図１０】図１０は、本発明の実施形態による読み出しコマンド処理のフローチャートである。
【図１１】図１１は、本発明の実施形態による書き込みコマンド処理のフローチャートである。
【図１２】図１２は、本発明の実施形態によるピココードにおけるモジュールのブロック図である。
【図１３】図１３は、本発明の実施形態による読み出し動作におけるコマンドフレームヘッダー操作のフローチャートである。
【図１４】図１４は、本発明の実施形態による書き込み動作におけるコマンドフレームヘッダー操作のフローチャートである。
【図１】
0004457185.tif 000013
【図２Ａ】
0004457185.tif 000014
【図２Ｂ】
0004457185.tif 000015
【図３】
0004457185.tif 000016
【図４】
0004457185.tif 000017
【図５】
0004457185.tif 000018
【図６】
0004457185.tif 000019
【図７】
0004457185.tif 000020
【図８】
0004457185.tif 000021
【図９】
0004457185.tif 000022
【図１０】
0004457185.tif 000023
【図１１】
0004457185.tif 000024
【図１２】
0004457185.tif 000025
【図１３】
0004457185.tif 000026
【図１４】
0004457185.tif 000027