JP2004503122A

JP2004503122A - Method and apparatus for transferring data between different network devices via an IP network

Info

Publication number: JP2004503122A
Application number: JP2001559174A
Authority: JP
Inventors: ラティフ，　アーマー; ミュレンドール，　ロドニー　エヌ．; ホワイト，　ジョセフ　エル．; ユチーノ，　ブライアン　ワイ．
Original assignee: ニシャン　システムズ，　インコーポレイテッド
Priority date: 2000-02-08
Filing date: 2000-03-09
Publication date: 2004-01-29
Also published as: AU2000238787A1; WO2001059966A1; EP1256198A1

Abstract

ＩＰデバイス（１１５）およびＳＣＳＩ（１０５）またはファイバチャンネルＦＣ（１１０）デバイスの間でのデータ転送をＩＰネットワーク（１６０）を介して行うための方法および装置。上記デバイスのインターフェースは、ＳＣＳＩインターフェース、ＦＣインターフェースまたはＩＰインターフェース（例えば、ギガビットイーサネット（Ｒ））のいずれかであり得る。ＳＣＳＩおよびＩＰの間、ＦＣおよびＩＰの間、またはＳＣＳＩおよびＦＣの間でデータスイッチを行なう。ＳＣＳＩからＳＣＳＩへ、ＩＰからＩＰへ、またはＦＣからＦＣへとデータスイッチを行うこともできる。ポートのインターフェースにより、入力フレームフォーマットから内部フレームフォーマットへの変換が可能となり、変換結果は、上記装置内でルーティング可能である。
【選択図】図４A method and apparatus for transferring data between an IP device (115) and a SCSI (105) or Fiber Channel FC (110) device over an IP network (160). The interface of the device may be any of a SCSI interface, an FC interface, or an IP interface (eg, Gigabit Ethernet®). Data switching is performed between SCSI and IP, between FC and IP, or between SCSI and FC. Data switching can also be performed from SCSI to SCSI, from IP to IP, or from FC to FC. The port interface allows conversion from the input frame format to the internal frame format, and the conversion result is routable within the device.
[Selection diagram] FIG.

Description

【０００１】
（関連出願との相互参照）
本願は、１９９９年３月１０日に出願された「ＭＥＴＨＯＤ　ＡＮＤ　ＡＰＰＡＲＡＴＵＳ　ＦＯＲ　ＴＲＡＮＳＦＥＲＲＩＮＧ　ＤＡＴＡ　ＢＥＴＷＥＥＮ　ＩＰ　ＮＥＴＷＯＲＫ　ＤＥＶＩＣＥＳ　ＡＮＤ　ＳＣＳＩ　ＡＮＤ　ＦＩＢＲＥ　ＣＨＡＮＮＥＬ　ＤＥＶＩＣＥＳ　ＯＶＥＲ　ＡＮ　ＩＰ　ＮＥＴＷＯＲＫ」という名称の米国仮特許出願第６０／１２３，６０６号（代理人番号０１９６７８−０００１００）に関する。同文献の開示はその全体が本明細書において参考として援用される。
【０００２】
（発明の背景）
本発明は、パケットスイッチング方式の通信システムを介した、ストレージデバイスとネットワークとの間での情報転送に関する。詳細には、本発明は、ＳＣＳＩ（小型コンピューターシステムインターフェイス）、ファイバチャンネルおよびイーサネット（Ｒ）デバイスの間で、柔軟でプログラム可能な様態でデータパケットを受信、変換およびルーティングする方法および装置に関する。
【０００３】
企業のコンピューティング環境において、複数のサーバが高い帯域幅のデータ転送、システム拡張、モジュラリティ、構成の柔軟性およびリソースの最適化をサポートするように、複数のストレージデバイスに直接アクセスできることが望ましく、かつ有益である。従来のコンピューティング環境において、このようなアクセスは通常、ストレージに直接的に接続した場合の数分の１で動作する、ファイルシステムレベルのローカルエリアネットワーク（ＬＡＮ）接続を介して提供される。したがって、ストレージシステムへのアクセスはボトルネックに非常に陥りやすい。
【０００４】
このストレージへのアクセスのボトルネックの問題を解決する１つの方法としてストレージエリアネットワーク（ＳＡＮ）が提案されてきた。このネットワーキングのパラダイムをストレージデバイスに適用することによって、ＳＡＮは増加した接続性および帯域幅、リソースの共有ならびに構成の柔軟性を可能にする。現在のＳＡＮのパラダイムは、ネットワーク全体がファイバチャンネルスイッチを用いて構築されていることを仮定している。したがって、ＳＡＮに関するほとんどの解決策は、１つは通常のＬＡＮをサポートし、１つはＳＡＮをサポートする、別々のネットワークの実現を必要とする。ストレージデバイスレベル（ファイバチャンネルインターフェース）、ホスト／サーバレベル（ファイバチャンネルアダプタカード）およびトランスポートレベル（ファイバチャンネルハブ、スイッチおよびルータ）における新しい機器などの新しい機器および技術を、ミッションクリティカルな企業のコンピューティング環境に導入することは、これがネットワークインフラストラクチュアの複製、新しい技術（すなわち、ファイバチャンネル）および職員の新しい研修を含むため、データセンタマネジャーにとってあまり好ましくないものとして記載され得る。ほとんどの会社は、有意な量の金額をすでに投資して、（例えば、イーサネット（Ｒ）および／またはＡＴＭに基づいた）自身のネットワークを構築し、維持している。異なる技術に基づいて第２の高速のネットワークを構築することは、ＳＡＮが普及する際の著しい障害となっている。したがって、ストレージデバイスに複数のホストによってアクセスする問題を緩和し、同時に、現在の機器およびネットワークインフラストラクチュアを保持し、そしてデータセンタの職員の新しい研修の必要性を最小限に抑え得る方法および装置の必要性が存在する。
【０００５】
通常、大多数のストレージデバイスは現在、「パラレル」のＳＣＳＩまたはファイバチャンネルのデータ転送プロトコルを用い、ほとんどのＬＡＮはギガビットのイーサネット（Ｒ）などのイーサネット（Ｒ）プロトコルを用いる。ＳＣＳＩ、ファイバチャンネルおよびイーサネット（Ｒ）はデータ転送のプロトコルであり、それぞれ、異なる個別のフォーマットを用いてデータ転送を行う。例えば、ＳＣＳＩ命令は、パラレルのバスアーキテクチャを介して実現されるように設計されており、したがって、パケット化されない。イーサネット（Ｒ）と同様、ファイバチャンネルは、パケットで転送されるデータとのシリアルインターフェースを用いる。しかし、ファイバチャンネルとイーサネット（Ｒ）との間の物理インターフェースおよびフレームフォーマットは互換性を有さない。ギガビットのイーサネット（Ｒ）は、既存のイーサネット（Ｒ）のインフラストラクチュアと互換性を有するように設計されていたため、イーサネット（Ｒ）パケットのアーキテクチャに基づく。これらの差異があるため、これらのプロトコル間で効率的な通信を可能にする新しい方法および装置の必要性がある。
【０００６】
（発明の要旨）
本発明は、ストレージデバイスインターフェースとネットワークインターフェースとの間でデータを転送する方法および装置を提供することによって上述および他の問題を解決し、これにより、有用な最新技術を進化させる。具体的には、本発明は、高価なファイバチャンネルスイッチおよびハブを設置せずに、インターネットプロトコル（ＩＰ）デバイスがＩＰネットワークを介してＳＣＳＩおよびファイバチャンネルデバイスと透明に通信する手段を提供することによって、高度なＳＡＮの機能を既存の企業のコンピューティング構成に導入する。本発明は、ファイバチャンネルプロトコル（ＦＣＰ）、ファイバチャンネルネットワーク上でのＳＣＳＩ命令の実現用に開発された産業規格を用いてこれを達成する。本発明により、上記ストレージデバイスが標準のＳＣＳＩおよびファイバチャンネルストレージインターフェースの使用を保持し、そして会社の既存のネットワークインフラストラクチャを用いてＳＡＮを構築することが可能になる。したがって、ホストハブアダプタ（ＨＢＡ）またはストレージデバイス（例えば、ディスクドライブ、テープドライブなど）内で必要な変更はない。
【０００７】
本発明によれば、ＩＰデバイス（ギガビットのイーサネット（Ｒ）デバイスを含む（但し、これに限定されない））とＳＣＳＩまたはファイバチャンネルデバイスとの間でデータを転送する方法および装置が提供される。上記デバイスのインターフェースは、ＳＣＳＩ、ファイバチャンネルまたはギガビットのイーサネット（Ｒ）などのＩＰインターフェースのいずれかであり得る。データはＳＣＳＩとＩＰとの間、ファイバチャンネルとＩＰとの間、またはＳＣＳＩとファイバチャンネルとの間でスイッチングされる。データはさらに、ＳＣＳＩからＳＣＳＩに、ファイバチャンネルからファイバチャンネルに、そしてＩＰからＩＰにもスイッチングされ得る。上記ポートインターフェースは、上記入力フレームフォーマットから内部フレームフォーマットへの変換を提供し、上記内部フレームフォーマットは上記装置内でルーティングされ得る。上記装置はすべてのポートを任意の数だけ含み得る。各ポートインターフェースによって実行される処理量は上記インターフェースの種類に依存する。本発明の上記処理能力により、複数のインターフェース間での情報パケットの迅速な転送が、ストレージプロトコルの厳しい要件を満たす待ち時間レベルで可能になる。構成制御はスイッチ上の各ポート、次いで、ネットワーク上の各スイッチにＳＮＭＰまたはウェブベースのインターフェースを介して適用され得て、柔軟でプログラム可能な制御を装置に提供する。
【０００８】
本発明の一局面によれば、ＳＡＮなどのネットワーク内のスイッチデバイス内でデータパケットをルーティングする方法が提供される。上記方法は通常、第１のネットワークデバイスからパケットを上記スイッチデバイスの第１のポートのインターフェースにおいて受信する工程であって、上記パケットはＳＣＳＩ方式でフォーマットされたパケット（すなわち、パケットに変換されたＳＣＳＩ方式のフォーマットデータストリーム）、ファイバチャンネル（ＦＣ）方式でフォーマットされたパケット、およびインターネットプロトコル（ＩＰ）方式でフォーマットされたパケットのうちの１つであり、上記第１のポートインターフェースは上記第１のネットワークデバイスに通信可能に結合されている、工程と、上記受信したパケットを内部フォーマットを有するパケットに変換する工程とを含む。上記方法は通常さらに、上記内部フォーマットのパケットを上記スイッチデバイスの第２のポートインターフェースにルーティングする工程、上記内部フォーマットのパケットをＳＣＳＩ方式でフォーマットされたパケット、ＦＣ方式でフォーマットされたパケットまたはＩＰ方式でフォーマットされたパケットの１つに再変換する工程、および上記再変換したパケットを上記第２のポートインターフェースに通信可能に結合された第２のネットワークデバイスに伝達する工程を含む。
【０００９】
本発明の別の局面によれば、通常、第１のポートインターフェースを含むネットワークスイッチデバイスが提供される。上記第１のポートインターフェースは、ネットワークデバイスからデータパケットを受信する手段であって、上記受信手段は、第１のネットワークデバイスからＳＣＳＩ方式でフォーマットされたパケットおよびファイバチャンネル（ＦＣ）方式でフォーマットされたパケットのうちの１つを受信する手段と、受信したパケットを内部フォーマットを有するパケットに変換する手段であって、上記受信したデータパケットは上記内部フォーマットを有する第１のパケットに変換される、手段とを含む。上記スイッチデバイスは通常さらに、第２のポートインターフェースを含む。上記第２のポートインターフェースは、パケットを上記内部フォーマットからＩＰフォーマットに再変換する手段であって、上記第１のパケットはＩＰフォーマットを有するパケットに変換される、手段と、ＩＰパケットをネットワークに伝達する手段であって、上記ＩＰ方式でフォーマットされたパケットはＩＰネットワークに伝達される、手段とを含む。上記第１のパケットを上記第２のポートインターフェースにルーティングする手段がさらに提供される。
【００１０】
本発明のさらに別の局面によれば、通常、第１のポートインターフェースを含むネットワークスイッチデバイスが提供される。上記第１のポートインターフェースは、ＩＰネットワークからデータパケットを受信する手段であって、上記第１のインターフェース手段はＩＰフォーマットのパケットを受信する、手段と、受信したパケットを内部フォーマットを有するパケットに変換する手段であって、上記受信したパケットは内部フォーマットを有する第１のパケットに変換される、手段とを有する。上記スイッチデバイスは通常さらに、第２のポートインターフェースを含む。上記第２のポートインターフェースは、上記内部フォーマットを有するパケットを上記ＳＣＳＩフォーマットを有するパケットに再変換する手段と、変換したパケットをＳＣＳＩネットワークデバイスに伝達する手段とを含む。上記スイッチデバイスは通常さらに、第３のポートインターフェースを含む。上記第３のポートインターフェースは、上記内部フォーマットを有するパケットを上記ＦＣフォーマットを有するパケットに再変換する手段と、再変換したパケットをＦＣネットワークデバイスに伝達する手段とを含む。上記第１のポートインターフェースと、上記第２のポートインターフェースおよび上記第３のポートインターフェースとの間でパケットをルーティングする手段が通常さらに提供される。動作の間、上記第１のパケットが上記第２のポートインターフェースにルーティングされると、上記第１のパケットは上記ＳＣＳＩフォーマットに変換され、そして上記ＳＣＳＩネットワークデバイスに伝達される。上記第１のパケットが上記第３のポートインターフェースにルーティングされると、上記第１のパケットは上記ＦＣフォーマットに変換され、そして上記ＦＣネットワークデバイスに伝達される。
【００１１】
本発明のさらなる局面によれば、ストレージエリアネットワーク（ＳＡＮ）で使用されるネットワークスイッチデバイスが提供される。上記スイッチデバイスは通常、ＳＣＳＩデバイスに通信可能に結合された第１のポートインターフェースを含み、上記第１のポートインターフェースは、上記ＳＣＳＩデバイスから受信したＳＣＳＩ方式のフォーマットデータパケットを内部フォーマットを有するデータパケットに変換し、上記第１のポートインターフェースは上記内部フォーマットを有するデータパケットをＳＣＳＩ方式のフォーマットデータパケットに変換する。上記スイッチデバイスは通常さらに、ＦＣデバイスに通信可能に結合された第２のポートインターフェースを含み、上記第２のポートインターフェースは、上記ＦＣデバイスから受信したＦＣ方式のフォーマットデータパケットを内部フォーマットを有するデータパケットに変換し、上記第２のポートインターフェースは上記内部フォーマットを有するデータパケットをＦＣ方式のフォーマットデータパケットに変換する。上記スイッチデバイスは通常さらに、ＩＰデバイスに通信可能に結合された第３のポートインターフェースであって、上記ＩＰデバイスから受信したＩＰ方式のフォーマットデータパケットを内部フォーマットを有するデータパケットに変換し、上記内部フォーマットを有するデータパケットをＩＰ方式のフォーマットデータパケットに変換する、上記第３のポートインターフェースと、上記第１のポートインターフェースと、上記第２のポートインターフェースおよび上記第３のポートインターフェースとの間で上記内部フォーマットを有するデータパケットをルーティングするスイッチファブリックとを含む。通常の動作において、ＳＣＳＩデバイス、ＦＣデバイスおよびＩＰデバイスのうちの第１のデバイスは、第１のデータパケットを上記ＳＣＳＩデバイス、上記ＦＣデバイスおよび上記ＩＰデバイスのうちの１つである第２のデバイスに送信すると、上記第１のデバイスに結合された上記ポートインターフェースは上記第１のデータパケットを上記内部フォーマットを有するパケットに変換し、そして上記内部フォーマットのパケットを上記スイッチファブリックを介して上記第２のデバイスに結合された上記ポートインターフェースにルーティングする。上記第２のデバイスに結合された上記ポートインターフェースは、上記内部フォーマットのパケットを上記第２のデバイスに関連付けられたフォーマットに再変換し、上記再変換したパケットを上記第２のデバイスに送信する。
【００１２】
本発明のさらなる局面によれば、ストレージエリアネットワーク（ＳＡＮ）で使用されるネットワークスイッチデバイスが提供される。上記スイッチは、ファイバチャンネル、ＳＣＳＩ、イーサネット（Ｒ）およびインフィニバンドポートの任意の組み合わせを含み得、そしてすべてのポートを任意の数だけ含み得る。上記スイッチデバイスは通常、ＳＣＳＩデバイス（単数または複数）、ＦＣデバイスまたはＩＰデバイスのうちの１つに通信可能に結合された第１のポートインターフェースと、第２のポートインターフェースであって、ＦＣデバイスまたはイーサネット（Ｒ）デバイスのいずれかと通信するように構成可能である、第２のポートインターフェースと、上記第１のポートインターフェースと上記第２のポートインターフェースとの間で上記内部フォーマットを有するデータパケットをルーティングするスイッチファブリックとを含む。通常の動作において、上記第２のポートインターフェースがＦＣデバイスと通信するように構成されると、上記第２のポートインターフェースは上記ＦＣデバイスから受信したＦＣ方式のフォーマットデータパケットを内部フォーマットを有するデータパケットに変換し、上記第２のポートインターフェースは上記スイッチファブリックから受信した上記内部フォーマットを有するデータパケットをＦＣ方式のフォーマットデータパケットに変換する。上記第２のポートインターフェースがイーサネット（Ｒ）デバイスと通信するように構成されると、上記第２のポートインターフェースは上記イーサネット（Ｒ）デバイスから受信したイーサネット（Ｒ）方式のフォーマットデータパケットを内部フォーマットを有するデータパケットに変換し、上記第２のポートインターフェースは上記スイッチファブリックから受信した上記内部フォーマットを有するデータパケットをイーサネット（Ｒ）方式のフォーマットデータパケットに変換する。上記第２のポートインターフェースは自己構成（ｓｅｌｆ−ｃｏｎｆｉｇｕｒａｂｌｅ）されてもよいし、またはユーザによって構成（ｕｓｅｒ　ｃｏｎｆｉｇｕｒａｂｌｅ）されてもよい。
【００１３】
図面および特許請求の範囲を含む本明細書の残りの部分を参照すると、本発明の他の特徴および利点が理解される。本発明のさらなる特徴および利点、ならびに本発明の種々の実施形態の構造および動作を、添付の図面を参照して以下に詳細に説明する。図面において、同様の参照符号は同一または機能的に同様の要素を示す。
【００１４】
（特定の実施形態の説明）
図１は、本発明の一実施形態によるストレージエリアネットワーク（ＳＡＮ）１０の一例を示す。図示するように、ネットワーク１０は、テープライブラリ１５、ＲＡＩＤドライブ２０および光ドライブ２５（例えば、ＣＤ、ＤＶＤなど）ならびにサーバ３０などの多数のストレージデバイスを含む。ストレージデバイスは、ストレージターゲット（例えば、テープライブラリ１５、ＲＡＩＤドライブ２０など）またはイニシエーター（例えば、サーバ３０）のいずれかであり得る。デバイスはイニシエーターおよびターゲットの両方でもよいことに留意されたい。好適な実施形態において、本発明は、ネットワーク１０内のスイッチングデバイス３５内に実現される。例えば、図１に示すように、各スイッチングデバイス３５は、「端部」スイッチであり、ノード（すなわち、１つ以上のストレージデバイス）とネットワーク４０との間に接続を提供する。すなわち、スイッチはデバイスが配置されているネットワークの「端部」に存在する。各端部スイッチ３５により、接続されたストレージ素子が端部スイッチを介して通信する（トラフィックはネットワーク４０に送信されない）ことが可能になる。各端部スイッチ３５によりさらに、異なる端部スイッチに接続されたストレージ素子がネットワーク４０を介して相互と通信することが可能になる。好適な実施形態において、ネットワーク４０はイーサネット（Ｒ）ネットワークであるが、非同期転送モード（ＡＴＭ）ベースのネットワークまたはＦＤＤＩベースのネットワークなどの他のネットワークを用いてもよい。
【００１５】
一実施形態において、図２に示すように、スイッチングデバイス３５はＳｏＩＰ（インターネットプロトコルを介したストレージ）のストレージエリアネットワーク（ＳＡＮ）内に実現される。本発明によれば、ＳｏＩＰは、ＩＰネットワークを介して、ＩＰネットワーク化されたストレージデバイス間での通信用のＳＣＳＩのファイバチャンネルプロトコル（ＦＣＰ）を用いて、ＳＣＳＩ命令およびデータをトランスポートするフレームワークである。大多数のストレージデバイスは現在、「パラレル」のＳＣＳＩバスまたはファイバチャンネルのシリアルインターフェースのいずれかを用いて通信する。ＦＣＰは、「シリアル」のＳＣＳＩネットワークを形成するファイバチャンネルネットワークを介して、ＳＣＳＩ命令およびデータを送信するＦＣ−４上層プロトコルである。ＳｏＩＰフレームワークは、ＳｏＩＰプロトコルを定義することによってＩＰネットワーク上で用いられるＦＣＰをイネーブルにする。ストレージデバイスおよびＳｏＩＰプロトコルを動作するホストバスアダプタは、ＩＰネットワーク上に直接、ストレージエリアネットワーク（ＳＡＮ）を形成する。このフレームワークは、ＳＡＮの設置および効用の点でずば抜けた利点を提供する。
【００１６】
図２に示すように、各ＳｏＩＰデバイス５０は、ＳＣＳＩ命令およびデータをＦＣＰブロック５２内のＦＣＰデータフレームに変換する。次いで、ＳｏＩＰプロトコル層のブロック５４は、ユーザデータグラムプロトコル（ＵＤＰ）またはトランスポート制御プロトコル（ＴＣＰ）のいずれかを用いて、これらのＦＣＰフレームを複数のＩＰパケットにカプセル化する。ＩＰポート５６はパケットをＩＰネットワーク６０に転送し、ＩＰネットワーク６０は、デバイス５０間、またはスイッチ３５へとＩＰパケットをルーティングする。ネットワーク６０は好適には、イーサネット（Ｒ）ネットワークであるが、ＡＴＭ、ＦＤＤＩおよびＳＯＮＥＴなどを含む任意のＩＰと互換性を有する媒体に基づき得る。ストレージネームサーバ６５は、デバイスが自身の情報を保存し、そしてＳｏＩＰネットワーク内の他のデバイスに関する情報を取り出すデータベースとして機能する。ＳｏＩＰプロキシ７０は、ＵＤＰに基づいたＳｏＩＰとＴＣＰに基づいたＳｏＩＰとの間のプロトコル変換を実行する。
【００１７】
大多数のストレージデバイスは現在「パラレル」のＳＣＳＩまたはファイバチャンネルプロトコルを用いるため、このような「レガシー（ｌｅｇａｃｙ）」のデバイスがＳｏＩＰネットワークに接続され得ない限り、ＳｏＩＰベースのＳＡＮへの移行が阻まれ得る。これらの「レガシー」のデバイスに関して、図３に示すスイッチがＳｏＩＰ　ＳＡＮへの接続用に提供される。
【００１８】
図３は、本発明の一実施形態による、スイッチ１３５を用いたストレージデバイス間でのデータスイッチングを示す。この実施形態において、スイッチ１３５は、それぞれが異なるデータまたはフレームフォーマットを有する、異なるインターフェースからデータを受信するように構成されている。ＳＣＳＩデバイス１０５は、「パラレル」のＳＣＳＩインターフェース１０６を用いてデータを伝達し、ファイバチャンネル（ＦＣ）デバイス１１０はファイバチャンネルインターフェース１１１を用いてデータを伝達し、そしてイーサネット（Ｒ）デバイス１１５はイーサネット（Ｒ）インターフェース１１６を用いてデータを伝達する。スイッチ１３５は、ソースポートから受信した、３つの異なるフォーマットのうちの１つフォーマットのデータを、内部フォーマットに変換し、そしてこの内部フォーマットのデータをスイッチファブリック１４０を介して宛先ポートに転送する。宛先ポートは、宛先ポートへの接続に適切な固有のフォーマットにデータを変換する。
【００１９】
この実施形態において、ＳＣＳＩデバイス１０５、ＦＣデバイス１１０、イーサネット（Ｒ）デバイス１１５またはジェネリック（ｇｅｎｅｒｉｃ）ＩＰデバイス１２０（例えば、ディスクドライブ、テープドライブ、サーバ）などの各デバイスは、ＳＣＳＩ命令セットに基づいてストレージ動作を実行する。ファイバチャンネルデバイス１１０に関して、ＳＣＳＩ命令およびデータはＦＣＰに変換されて、そしてファイバチャンネルインターフェース１１１を用いて伝達される。ＳＣＳＩデバイス１０５に関して、ＳＣＳＩ命令およびデータは「パラレル」のバス１０６を用いて直接転送される。この実施形態において、ＳＣＳＩのポートがスイッチファブリック１４０の観点からＦＣポートのように見えるように、スイッチ１３５のＳＣＳＩのポートインターフェース１２５はＦＣブリッジへのＳＣＳＩのように動作する。図示するように、ＳＣＳＩデータは好適には、ＦＣＰに変換され、そしてファイバチャンネルインターフェースを用いて実際には伝達されない。イーサネット（Ｒ）デバイス１１５に関して、ＳＣＳＩ命令およびデータはＦＣＰに変換され、そしてＵＤＰまたはＴＣＰを用いてＩＰパケット内にカプセル化される。次いで、ＩＰパケットはイーサネット（Ｒ）のフレーム内にカプセル化されて、イーサネット（Ｒ）インターフェース１１６を用いて伝達される。用語「ＳＣＳＩデバイス」が「パラレルのＳＣＳＩバス」を備えたデバイスを示唆し、用語「ファイバチャンネルデバイス」がファイバチャンネルインターフェースを備えたデバイスを示唆することに留意されたい。両方のデバイスは命令レベルにおいてＳＣＳＩデバイスとして動作する。ＳＣＳＩデバイス１０５がＳＣＳＩ命令およびデータをＦＣＰフォーマットに変換しないことに留意されたい。したがって、ＦＣデバイス１１０とＳＣＳＩデバイス１０５との間で直接データを転送することは可能でない。図３に示すように、スイッチファブリック１４０内のすべてのインターフェースのデータフォーマットがＦＣＰと互換性のあるフレームであるため、スイッチ１３５に接続されたすべてのデバイスがデータフレームをスイッチングすることが可能である。さらに、ファイバチャンネルを別のインターフェースに置き換えることが可能であることに留意されたい。例えば、図３は、デバイスがＦＣを用いて構築されたのと同じ様態で、イーサネット（Ｒ）を用いて構築されたストレージデバイスを示す。イーサネット（Ｒ）は、ファイバチャンネルをトランスポート媒体として単に置き換えた。インフィニバンドも、例えば、ジェネリックＩＰデバイス１２０内に実現され得る。周知であるように、インフィニバンドはＮＧＩＯ（次世代Ｉ／Ｏ）および未来のＩ／Ｏの機能が組み合わされたＩ／Ｏインターフェースである。
【００２０】
図４は、本発明の一実施形態による、スイッチ装置１３５内のファイバチャンネル、ＳＣＳＩおよびＩＰデバイス間のデータスイッチングを示す。図４の例はイーサネット（Ｒ）ベースのＩＰネットワーク１６０のものであるが、ＡＴＭ、ＦＤＤＩなどの他のプロトコルに基づいた任意の他のＩＰネットワークを用いてもよい。図３の実施形態と同様、図４は各デバイスに対して行われるプロトコル変換を示す。ＳＣＳＩデバイス１０５は、データまたは命令をデータフレーム内にカプセル化すること無く、ＳＣＳＩ命令を直接用いることによって、スイッチ１３５と通信する。ＦＣデバイス１１０はＦＣＰプロトコルを用いて、ＳＣＳＩ命令およびデータをスイッチ１３５に送信する。スイッチ１３５は、受信したデータをＦＣＰに基づく共通のプロトコルに変換して、デバイスが相互に通信することを可能にする。さらに、以下により詳細に説明するように、スイッチ１３５は、ファイバチャンネルとＳＣＳＩアドレス指定方式との間のアドレス変換をＩＰアドレス指定方法に対して実行する。これは、ファイバチャンネルデバイス１１０またはＳＣＳＩデバイス１０５内、あるいは任意のホストバスアダプタ、ドライバソフトウェアまたはアプリケーションソフトウェア内で変更が必要でないように透明に行われる。
【００２１】
図５は、本発明の一実施形態による、物理的なスイッチ装置２３５の基本アーキテクチャの概略を示すハイレベルのスイッチ図である。この実施形態において、スイッチ２３５は３つの主な素子：スイッチファブリック２４０、管理プロセッサ２５０およびポートインターフェース２７０を含む。スイッチファブリック２４０は、種々のポートインターフェース２７０間、およびポートインターフェース２７０と管理プロセッサ２５０との間でのデータ転送を行う高い帯域幅のメカニズムを提供する。管理プロセッサ２５０は、スイッチ２３５の管理関連機能（例えば、スイッチの初期化、環境設定、ＳＮＭＰ、ファイバチャンネルサービスなど）を、主に管理バス２５５を介して実行する。
【００２２】
ポートインターフェース２７０は、データパケットを入力フレームフォーマット（例えば、パラレルのＳＣＳＩ、ＦＣまたはイーサネット（Ｒ））から内部フレームフォーマットに変換する。次いで、内部フレームフォーマットデータパケットは、スイッチファブリック２４０内で適切な宛先ポートインターフェースにルーティングされる。ポートインターフェース２７０はさらに、パケットがスイッチ内でいかにルーティングされるかを決定する。各ポートインターフェース２７０によって実行される処理量はインターフェースの種類に依存する。ＳＣＳＩのポート２７０_１および２７０_２は、ＳＣＳＩインターフェースが半二重であり、そしてフレーム志向でないため、ほとんどの処理を提供する。ＳＣＳＩのポートインターフェース２７０_１および２７０_２はさらに、ＳＣＳＩのホストおよび／またはターゲットの機能をエミュレートする。ファイバチャンネルポート２７０_３および２７０_４は、内部フレームフォーマットがファイバチャンネルと最も互換性があるため、最も少ない量の処理しか必要としない。基本的に、ＩＰポート２７０_５および２７０_６（例えば、イーサネット（Ｒ）のポート）ならびにＳＣＳＩのポート２７０_１および２７０_２は、スイッチファブリック２４０を介してパケットを送信する前に、受信したデータを内部フレームフォーマットに変換する。
【００２３】
ＦＣＰフレームは、ファイバチャンネルインターフェースと互換性を有する場合、イーサネット（Ｒ）インターフェースと直接互換性を有さないため、イーサネット（Ｒ）インターフェース上のＦＣＰパケットの伝達は、図６ａに示すようにＦＣＰフレームがイーサネット（Ｒ）のフレーム内でカプセル化されることを必要とする。
【００２４】
図６ａは、本発明の一実施形態による、イーサネット（Ｒ）のフレームを介して搬送される、ＩＰフレーム内にカプセル化されたＦＣＰパケットを示す。図６ａのフィールド定義は以下を含む。
【００２５】
ＤＡ：イーサネット（Ｒ）宛先アドレス（６バイト）
ＳＡ：イーサネット（Ｒ）ソースアドレス（６バイト）
タイプ：イーサネット（Ｒ）パケットタイプ
チェックサムパッド：すべてのコンテンツが知られる前にデータフレームが伝達を開始する場合に、ＵＤＰチェックサムが正しいことを保証するために用いられ得るオプションの２バイトのフィールド。ＳｏＩＰヘッダ内のチェックサムパッドのビットはこのフィールドが存在するか否かを示す。
【００２６】
イーサネット（Ｒ）ＣＲＣ：巡回冗長検査（４バイト）
図６ａに示すように、ＳｏＩＰのヘッダフィールドは以下のパラメータを含む。
【００２７】
分類：この４ビットのフィールドはサービス分類を示す。一実施形態において、２または３の値のみが用いられる。
【００２８】
ＶＥＲＳ：この４ビットのフィールドはＳｏＩＰのプロトコルバージョンを示す。
【００２９】
ＳｏＩＰフラグ：この８ビットのフィールドは図６Ｂに示すデータフレームの種々のパラメータを示すビットを含む。
【００３０】
図６ａにおいて、ユーザデータグラムプロトコル（ＵＤＰ）のヘッダは、ＩＰパケット内で用いられるプロトコルである。ＴＣＰを用いてもよい。ＲＦＣ７６８に定義されるＵＤＰヘッダは、長さが８バイトであり、この８バイトは図６ｃに示す、以下のフィールド定義を有する、４つの１６ビットのフィールドからなる。
【００３１】
ソースポート：オプションのフィールド。意味がある場合には、これは、送信プロセスのポートを示し、そして他の情報が無い場合に応答がアドレス指定されるべき対象のポートであると仮定され得る。用いられない場合には、０の値が挿入される。
【００３２】
宛先ポート：特定のインターネットの宛先アドレスのコンテキスト内に意味を有する。
【００３３】
長さ：ＵＤＰヘッダおよびデータを含むユーザデータグラムのバイトでの長さ（したがって、データグラム内にデータがない場合には、長さは８である）。カプセル化されたＦＣＰパケットに関して、ＵＤＰの長さはＵＤＰヘッダの長さ、ＦＣＰヘッダの長さおよびＦＣＰペイロードの長さならびに必要に応じてチェックサムパッドの合計である。
【００３４】
チェックサム：情報の擬似ヘッダの１の補数の合計のうちの１６ビットの１の補数。この情報とは、（必要な場合には）端部を０のバイトでパディングして２バイトの数倍にした、ＩＰヘッダ、ＵＤＰヘッダ、およびデータである。
【００３５】
一実施形態において、スイッチ２３５はＦＣパケットをＦＣ情報の周囲の「ラッパー」を用いてイーサネット（Ｒ）のフレーム内にカプセル化する。最大のＦＣＰデータフレームのサイズが２１３６バイト（２４バイトのヘッダ＋２１１２バイトのペイロード）であり、イーサネット（Ｒ）のパケットは最大サイズが１５１８バイトであるため、ＦＣＰデータフレームをイーサネット（Ｒ）パケット内にカプセル化するには、ＦＣＰデータフレームのサイズを制限する必要があり得る。イーサネット（Ｒ）のジャンボフレーム（これは９Ｋバイトまでのパケットサイズが用いられることを可能にする）を用いると、ファイバチャンネルのフレームサイズを制限する必要性が排除される。しかし、イーサネット（Ｒ）のジャンボフレームのサポートは既存のネットワークインフラストラクチュア内に制限される。したがって、ＦＣＰデータフレームを制限する必要があり、そうでない場合には、大きいＦＣＰデータフレームを２つの別々のイーサネット（Ｒ）のフレームに「分割」する必要があり得る。ファイバチャンネル規格に規定されるログイン手順により、デバイスがスイッチファブリック２４０と最大のペイロードを交渉することが可能になる。したがって、スイッチファブリック２４０は、最大のペイロードサイズ（例えば、１０２４バイト）よりも小さいペイロードサイズでログインに応答し得る。スイッチ２３５はこの点を利用して、ＦＣパケットをイーサネット（Ｒ）パケット内にカプセル化し得るサイズに制限して、ＦＣパケットを分割する必要性を排除する。一実施形態によれば、ノードの最大の受信データのフィールドサイズは、「ファブリックログイン」の間にはスイッチファブリック２４０に、そして「ポートログイン」の間にはそれぞれの宛先ノードに提供される。「ログイン」状態のファブリックまたはノードは、受信することが可能なデータフレームの最大受信データフィールドサイズを示すログイン応答を生成する。これらの値が同じでない場合があることに留意されたい。例えば、ファブリックは２１１２バイトの最大許容サイズを有し得るが、ノード（例えば、ヒューレットパッカードのＴａｃｈｙｏｎ−Ｌｉｔｅ　Ｆｉｂｒｅ　Ｃｈａｎｎｅｌ　Ｃｏｎｔｒｏｌｌｅｒ）は最大サイズを１０２４バイトに制限し得る。ソースノードは、ログイン応答に対して決められた最大フレームサイズより大きいデータフレームを伝達し得ない。
【００３６】
カプセル化されたＦＣＰデータフレームが最大のイーサネット（Ｒ）のパケットサイズより長くなり得ないため、デバイスによるログインの間に、フレームのペイロードサイズに上限が課せられる。一実施形態によれば、最大のＩＰデータグラムサイズを決定または検索し、そして種々のヘッダおよびトレーラの割合を占める６０バイトを減算することによって、上限値を設定する。例えば、イーサネット（Ｒ）のフレームの場合、上限値は１４４０バイトに等しい。すなわち、ＦＣＰフレームのペイロードはサイズが１４４０バイトを越え得ない。ＩＰネットワークを介してトランスポートされるＦＣＰフレームが分割され得ないため、この制限が確立される。ＩＰデータグラムを分割可能にすると、ネットワークの性能が下がるため、ほとんどのネットワークは分割されることがほとんどない。ＩＰヘッダの分割禁止フラグ（Ｄｏ　Ｎｏｔ　Ｆｒａｇｍｅｎｔ　Ｆｌａｇ）は、ＩＰ層がデータグラムを分割することを阻止するために用いられ得る。ＦＣＰペイロードに適切なサイズを設定するノードのログインがあっても、このビットは確実に分割が生じないように設定される。一実施形態によれば、ペイロードは４バイトの数倍になるようにパディングされて、レガシーのＦＣデバイスに送信されるフレームに変換しやすくなる。
【００３７】
各スイッチ２３５は好適には、バッファツーバッファ受信データフィールドサイズ（Ｂｕｆｆｅｒ　ｔｏ　Ｂｕｆｆｅｒ　Ｒｅｃｅｉｖｅ　Ｄａｔａ　Ｆｉｅｌｄ　ｓｉｚｅ）を利用して、端部ノードにイーサネット（Ｒ）リンクを介して搬送されるＩＰパケット内に適合するデータフレームと通信させる。本発明の一実施形態によれば、最大フレームサイズを強化する１つの方法は、ノードのログインおよび管理プロセッサ２５０にリダイレクトされるノード応答フレームを傍受することである。管理プロセッサ２５０は、必要に応じて、フレーム内のバッファツーバッファ受信データフィールドサイズを調整し、そして次いで、修正したパケットを元の宛先にルーティングする。
【００３８】
ファブリックのログインに続いて、デバイスはネームサーバ６５にログインする。ネームサーバ６５へのログインを行うと、デバイスとネームサーバ６５との間の通信に用いられるパラメータ（例えば、最大ペイロードサイズ）が確立する。ネームサーバ６５を備えたデバイス「レジスタ」はデータベースに情報を提供し、データベースはネットワーク上のデバイスのパラメータを記述する。次いで、イニシエータはデータベースにクエリして、システム内のデバイスに関する情報を決定し、これにより、システムを「プローブ」して、どのデバイスが存在しているかを判定する必要性が排除され得る。ネットワークのプローブは、１６万のファイバチャンネルのアドレスがあるため実行可能でない。ネームサーバ６５は好適には、ネットワークに取り付けられたノードであるが、スイッチ内で実現され得、そして冗長性および速いアクセスを保証するためにファブリックにわたって分散され得る。
【００３９】
図７は、本発明の一実施形態による、ＳｏＩＰネットワークに接続されたファイバチャンネルデバイスの「セッション」初期化の一例を示すフローチャートである。ファブリックログインの間、スイッチ２３５はスイッチ２３５に割り当てられたＩＰアドレスのブロックからのＩＰアドレスをデバイスに割り当てる。
【００４０】
スイッチ２３５は、パケットがＩＰと互換性のあるポートに伝達されるか、またはこのポートから受信される場合に、ＦＣデバイスに割り当てられるＩＰアドレスを用いる。ＦＣデバイスはここで、ＳｏＩＰネットワークによって割り当てられた２つのアドレス：ＦＣアドレスおよびＩＰアドレスを有する。ＦＣアドレスはＦＣデバイスがローカルのファイバチャンネル「アイランド」で通信する場合に用いられ、一方、ＩＰアドレスはデバイスがＩＰネットワークを介して通信する場合に用いられる。
【００４１】
図８および図９は、本発明の一実施形態による、スイッチ１のＦＣポートＡによって開始し、そしてスイッチ１から離れて設けられているスイッチ２のＦＣポートＢまでのノードのログインのデータフレームの流れを示す。ログインリクエストのデータフレームはＦＣポートＡによってスイッチ１の管理プロセッサにリダイレクトされる。管理プロセッサは、バッファツーバッファ受信データフィールドサイズのパラメータで必要とされる任意の変更を行い、次いで、パケットを元の宛先ポートに転送する。宛先スイッチ（スイッチ２）において、ログインリクエストのパケットのリダイレクトはない。図９に示すように、ＦＣポートＢからのログイン応答フレームはスイッチ２の管理プロセッサにリダイレクトされる。管理プロセッサは、必要な場合には、応答内のバッファツーバッファ受信データフィールドサイズを変更する。
【００４２】
一実施形態において、各管理プロセッサは、そのバッファツーバッファ受信データフィールドサイズをＦＣＰデータフレームがＩＰパケット内に適合することを可能にする値に調整する。ＩＰパケットは分割されることなくイーサネット（Ｒ）ネットワークを介して伝達され得る。したがって、各管理プロセッサは、ＭＴＵ（最大伝達単位（Ｍａｘｉｍｕｍ　Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｕｎｉｔ）の検索を実行して、ネットワーク内でのＩＰパケットの分割を生じないサイズを決定する必要があり得る。
【００４３】
ＦＣポートがローカルの（すなわち、同じスイッチに接続された）ＦＣポートを用いてポートのログインを実行する場合、ログインのリクエストまたは応答のバッファツーバッファ受信データフィールドサイズを変更する必要はない。これは、一実施形態において、スイッチが（同じスイッチ上の）ＦＣポート間で転送される最大フレームサイズをサポートするからである。しかし、ＦＣポートのインターフェース論理はポートログインパケットをスイッチの管理プロセッサに常にリダイレクトして、ポートのインターフェース論理を簡略化する。したがって、この実施形態において、スイッチはスイッチに接続された任意のＦＣデバイスの観点から、ＦＣスイッチのように見え、そして動作する。ローカルのＦＣポートのポートのログインのリクエストフレームおよび応答フレームのルーティングの一例を図１０に示す。
【００４４】
一実施形態によれば、ＦＣポートのログインリクエスト／応答のパケットを管理プロセッサにルーティングすると、ＳＣＳＩのポートのログインを管理プロセッサによって処理することが可能になる。管理プロセッサはＳＣＳＩのログインを常に処理する。
【００４５】
一実施形態によれば、ＳｏＩＰデバイスは２つのパラメータ：ＩＰアドレスおよびＳｏＩＰソケット番号を用いて一意的に識別される。したがって、１つのデバイスが一意的なＩＰアドレスを有するか、または複数のデバイスが１つのＩＰアドレスを共有することが可能である。例えば、ファイバチャンネルの調停されたループ上のデバイスはすべてＩＰアドレスを共有し得、サーバのホストバスアダプタは専用のＩＰアドレスを有し得る。一実施形態において、ＳｏＩＰソケット番号を割り当てるには２つの可能なモード：ローカルまたはグローバルがある。
【００４６】
ＩＰネットワークに直接接続された１つのＳｏＩＰデバイスは一意的なＩＰアドレスを有して、ネットワークがデータフレームをデバイスにルーティングすることが可能である必要がある。ＩＰネットワークはＳｏＩＰソケット番号に基づいてトラフィックをルーティングしない。しかし、データフレームをスイッチングする場合に、スイッチがＩＰアドレスおよびＳｏＩＰソケット番号の両方を用いると、スイッチ（例えば、スイッチ２３５）に接続されたデバイスはＩＰアドレスを共有し得る。
【００４７】
本発明によれば、「レガシー」のファイバチャンネルデバイスが取り付けられたＳｏＩＰネットワークＳＡＮは、２つの異なるアドレス方法：ＩＰおよびファイバチャンネルが用いられるため、異なるアドレスドメインを有する。図１１は、本発明の一実施形態による、ネットワーク内に存在するアドレスドメインの一例を示す。ＳｏＩＰデバイスはＩＰアドレスおよびＳｏＩＰソケット番号を用いて通信し、ファイバチャンネルデバイス（ＳＣＳＩデバイスはスイッチによってファイバチャンネルデバイスとして扱われる）はファイバチャンネルのアドレスを用いる。各スイッチ２３５はＩＰアドレスドメインとファイバチャンネルのアドレスドメインとの間でアドレス変換を実行する。スイッチ２３５_１はＩＰアドレスドメインとＦＣアドレスドメイン１との間でアドレス変換を実行し、そしてスイッチ２３５_２はＩＰアドレスドメインとＦＣアドレスドメイン２との間でアドレス変換を実行する。各スイッチ２３５は、デバイスがファブリックログインを実行すると、ＩＰアドレス、ＳｏＩＰソケット番号およびファイバチャンネルのアドレスを各ファイバチャンネルデバイスに割り当てる。ファイバチャンネルデバイスはその割り当てられたファイバチャンネルのアドレスに関してのみを得る。割り当てられたＩＰアドレス、ＳｏＩＰソケット番号およびファイバチャンネルのアドレスは、スイッチ内の変換テーブル（図示せず）内で維持される。パラレルのＳＣＳＩデバイスは、ＳＣＳＩのポートの初期化中に、スイッチによってそれぞれのアドレスが割り当てられる。ファイバチャンネルポートはファイバチャンネルデバイスによってすべてのネームサーバリクエストを処理用に管理プロセッサに方向付ける。
【００４８】
本発明の一実施形態によれば、管理プロセッサはファイバチャンネルネームサーバのリクエストをＳｏＩＰネームサーバリクエストに変換して、次いでこれは、ＳｏＩＰネームサーバ（例えば、サーバ２８０で実現される）に転送される。一実施形態において、ＳｏＩＰネームサーバの機能は分散されて、したがって、管理プロセッサによって直接処理される。ネームサーバからの応答は管理プロセッサに返されて、管理プロセッサにおいて、この応答は、ネームサーバリクエストを元々作成したポートに転送される前に、ファイバチャンネルネームサーバの応答に変換される。ファイバチャンネルデバイスがデータフレームをそのファイバチャンネルのアドレスドメイン内に配置されていないデバイスに送信すると、スイッチ２３５はパケットをＳｏＩＰと互換性のあるパケットに変換する。上述したように、変換はＦＣＰデータフレームをＩＰデータフレーム内にカプセル化する。戻って図６ａを参照すると、一実施形態において、ＩＰアドレスおよびＳｏＩＰソケット番号は、ファイバチャンネルソースアドレス（Ｓ＿ＩＤ）および宛先アドレス（Ｄ＿ＩＤ）をネームサーバ上のＩＰ／ファイバチャンネルのアドレス変換テーブルへの「鍵」として用いることによって取得される。ファイバチャンネルのアドレスフィールドは、ファイバチャンネルのデータフレームをＳｏＩＰのデータフレームに変換する場合に、ＳｏＩＰソケット番号によって置き換えられる。次いで、パケットは、ＩＰネットワーク上で伝達されて、そして宛先ＩＰアドレスを用いてルーティングされる。宛先デバイスがＳｏＩＰと互換性のあるデバイスである場合、パケットは宛先デバイスによって直接、処理される（すなわち、カプセル化解除（ｄｅ−ｅｎｃａｐｓｕｌａｔｅｄ）が実行されて、ＦＣＰパケットとして処理される）。しかし、宛先がファイバチャンネル（または、パラレルのＳＣＳＩ）デバイスである場合、パケットはスイッチ２３５にルーティングされる。スイッチ２３５はパケットを受信し、ＳｏＩＰパケットのカプセル化解除を実行し、そしてＳｏＩＰソケット番号を、ソースおよび宛先ＩＰアドレスならびにＳｏＩＰソケット番号に基づいて適切なソースおよび宛先ファイバチャンネルのアドレスに置き換える。
【００４９】
一実施形態によれば、ローカルの割り当ては、ＳｏＩＰソケット番号を割り当てる好適な方法である。この実施形態において、固有のＳｏＩＰデバイスは自身のＳｏＩＰソケット番号を選択し、一方ＳｏＩＰスイッチ（例えば、スイッチ２３５）はスイッチに取り付けられたファイバチャンネルおよびＳＣＳＩデバイスにＳｏＩＰソケット番号を割り当てる。ＳｏＩＰソケット番号がローカルに割り当てられた場合、選択された値は一意的なＩＰアドレス／ＳｏＩＰソケット番号の組み合わせとなる任意の値であり得る。ＩＰアドレスを共有するデバイスは、一意的なＳｏＩＰソケット番号が割り当てられ、一意的なＩＰアドレス／ＳｏＩＰソケット番号のペアを作成する必要がある。一意的なＩＰアドレスを有するデバイスは、任意の所望されるＳｏＩＰソケット番号を有し得る。一実施形態において、ＳｏＩＰスイッチは、受信したデータフレームのルーティングを簡略化するようにＳｏＩＰソケット番号を割り当てる。スイッチはさらに、ローカルに有意なファイバチャンネルのアドレスを、「リモート」のデバイスをアドレス指定する際にローカルなデバイスによって用いられるそれぞれの「リモート」のデバイスに割り当て得る必要もある。これらのローカルに割り当てられたアドレスは、そのファイバチャンネルのアドレスドメイン内のスイッチによってのみ知られる。したがって、各スイッチは１セットのローカルに割り当てられたファイバチャンネルのアドレスを維持し、このアドレスはＳｏＩＰネームサーバ内に規定されたグローバルに知られるＩＰアドレス／ＳｏＩＰポート番号のペアに対応する。
【００５０】
一実施形態によれば、アドレスドメインが異なることに起因して、各スイッチ２３５は、ペイロード内に組み込まれたファイバチャンネルのアドレス情報を有するファイバチャンネル拡張リンクサービスのリクエストおよび応答を傍受する。拡張リンクサービスのリクエストおよび応答はたまにしか生成されない。したがって、拡張リンクサービスのリクエストをデータフレームへの任意の必要な変更を行うスイッチの管理プロセッサにリダイレクトすることが好ましい。拡張リンクサービスのリクエスト／応答がペイロード内に組み込まれたアドレス指定情報を有さない場合、管理プロセッサは修正することなくパケットを単に再伝達する。
【００５１】
ファイバチャンネルまたはＳＣＳＩデバイスに割り当てられたＩＰアドレスおよびＳｏＩＰソケット番号はスイッチによって決定される。これらのアドレスの割り当ては実行次第である。好適な実施形態において、ＳｏＩＰソケット番号はデバイスのローカルのファイバチャンネルのアドレスが割り当てられる。この実施形態において、スイッチは受信したデータフレームから直接、ローカルファイバチャンネルのアドレスを取得する。あるいは、ＳｏＩＰソケット番号の割り当てはアドレステーブルへのインデックスとして用いられ得る増加しゆく番号に基づく。
【００５２】
一実施形態において、各デバイスに一意に定まるＩＰアドレスを割り当てる。しかし、この種類の割当てを行うと、多数のＩＰアドレスが使用されることになり得る。各デバイスについて単一のＩＰアドレスを用いると、ＩＰネットワーク内のルーティングの含意関係（ｉｍｐｌｉｃａｔｉｏｎｓ）が複数になる。そのため、好適な実施形態において、ＩＰアドレスへの割当てを、１つのスイッチに取り付けられたデバイスのうち少なくとも１つの部分集合が１つのＩＰアドレスを共有するように行う。例えば、１つのＩＰアドレスを各スイッチポートに割り当てることができる。その後、そのスイッチポートに割り当てられた各デバイスは、そのポートのＩＰアドレスを共有する。そのため、取り付けられたファイバチャンネルＮ＿ポートは一意に定まるＩＰアドレスを１つ有する一方、ファイバチャンネルＮ＿ポートに取り付けられたファイバチャンネルの調停ループ上のデバイスは、１つのＩＰアドレスを共有する。
【００５３】
一実施形態によれば、ファイバチャンネルのアドレスをグローバルに割り当てる。ファイバチャンネルのアドレスをグローバルに割り当てると、「レガシーの」ファイバチャンネルデバイスに対する適合性を最大にすることができる。この実施形態において、ＳｏＩＰネームサーバは、グローバルファイバチャンネルのアドレスの割振りの管理を行う役割を担う。場合によってはファイバチャンネルのアドレスは「サードパーティの」ＳＣＳＩコマンド内に埋め込まれる場合があるため、グローバルファイバチャンネルのアドレススペースをサポートする必要があり得る。このようなサードパーティコマンドの一例としてＣＯＰＹがある。このＣＯＰＹコマンドは、別のデバイスにデータをコピーするよう命令する。「サードパーティの」コマンドが用いられることは滅多に無いが、「サードパーティの」コマンドが用いられる場合、コマンドをアドレス適合性に合わせて変更するか、または、ファイバチャンネルのアドレスをグローバルに割り当てる必要が出てくる。
【００５４】
図１２ａに示すＳｏＩＰネットワークを参照して、例示的なサードパーティＣＯＰＹコマンドを用いて、ローカルに割り当てられるファイバチャンネルのアドレスおよびサードパーティコマンドに発生する問題について説明する。この実施例において、ローカルに割り当てられたファイバチャンネルのアドレスをＳｏＩＰソケット番号としても用いる。この実施例において、各デバイスは一意に定まるＩＰアドレスを有する。
【００５５】
図１２ｂは、各デバイスがネームサーバに公示したＩＰアドレスおよびＳｏＩＰソケット番号を示す。ネームサーバは、デバイスがＳｏＩＰネットワーク内においてアドレス指定される様式を識別する。各デバイスは、ＩＰアドレスおよびＳｏＩＰソケット番号の組み合わせにより一意に定まる様式で識別される。スイッチ２３５_３および２３５_４ならびにテープライブラリＣは、システム内の各デバイスを認識しているものと仮定する。この場合、テープライブラリＣは、ネームサーバのアドレステーブルと同じアドレステーブルを有する。スイッチ２３５_３および２３５_４は、ローカルファイバチャンネルのアドレスを各デバイス割り当てている。図１２ｃは、スイッチ２３５_３にストレージされるアドレステーブルを示し、図１２ｄは、スイッチ２３５_４にストレージされるアドレステーブルを示す。ファイバチャンネルのアドレスの割り当てはローカルに行われるため、アドレス割当ては完全に任意に行われる。
【００５６】
データをＲＡＩＤドライブＢからテープライブラリＢ（これらはどちらともローカルドメイン３内任意の配置される）へとコピーせよとの旨のＣＯＰＹコマンドを、ローカルドメイン１内のサーバＡがローカルドメイン３内のサーバＢに送るものと仮定する。このＣＯＰＹコマンドはサーバＡ側から見たアドレスを含む。そのため、図１２ｃを参照して、サーバＢによって受信されたコマンドは、ファイバチャンネルデバイス０００５００（ＲＡＩＤドライブＢ）からファイバチャンネルデバイス０００６００（テープライブラリＢ）へのＣＯＰＹである。しかし、サーバＢは、スイッチ２３５_４（図１２ｄ）のアドレステーブルを用いてＣＯＰＹコマンドを解釈し、ＲＡＩＤドライブＡからのデータをテープライブラリＡにコピーすべきであるとみなし、ＲＡＩＤドライブＢからのデータはテープライブラリＢにコピーすべきではないとみなす。そのため、誤った動作が行われることとなる。別の例として、サーバＢがＲＡＩＤドライブＡからのデータをテープライブラリＣにコピーすべきであるとのコマンドをサーバＡに送ると仮定する。このコマンドはファイバチャンネルのアドレス０００５００から００９９００（これらのアドレスは、スイッチ２３５_４側からみたアドレスである）へとＣＯＰＹされる。スイッチ２３５_４のアドレステーブル中に００９９００は存在しないため、サーバＡは、このコマンドはＲＡＩＤドライブＢからのデータを存在しないデバイスにコピーするよう命令しているものであるとみなす。
【００５７】
一実施形態によれば、スイッチは、各サードパーティコマンドを傍受し、埋め込まれたファイバチャンネルのアドレスを宛先デバイスと適合するように変更することにより、この問題を回避する。しかし、上記の傍受および変更を行うには、宛先スイッチ内におけるローカルアドレスの割当て状態がソーススイッチに分かっていなければならない。スイッチによってサードパーティコマンドを変換することは可能であるが、別の方法が好適である。
【００５８】
別の方法によれば、サードパーティコマンド中のファイバチャンネルのアドレスによって参照されるデバイスについて、ファイバチャンネルのアドレスをグローバルに割り当てる。ファイバチャンネルのアドレスをグローバルに用いると、サードパーティコマンドを変更なしに用いることが可能となるが、ＳｏＩＰネットワークにおいて可能なデバイスの総数と、ファイバチャンネルネットワークとしてのデバイスの数の最大数とが同じになる。ＳｏＩＰネットワーク内の全てのデバイスへのアドレス割り当てをグローバルに行うことが可能であるが、グローバルアドレスを必要とするのは、サードパーティコマンドとして参照されるデバイスだけである。
【００５９】
グローバルに割り当てられたファイバチャンネルのアドレスは、デバイスのＳｏＩＰソケット番号として用いると好ましい。その結果、「レガシー」のファイバチャンネルデータフレームをＳｏＩＰとの適合性を有するデータフレームに変換する作業が簡単になる。そのため、ファイバチャンネルのアドレスをグローバルに割り当てる作業は、ＳｏＩＰソケット番号をグローバルに割り当てる作業に対応する。
【００６０】
ＳｏＩＰソケット番号をグローバルに割り振る作業は、ＳｏＩＰネームサーバによって管理される。このＳｏＩＰネームサーバは、グローバルなＳｏＩＰソケット番号をフリーのソケット番号のプールからのリクエスト通りに割り当て、ソケット番号がもはや用いられていない場合、それらのソケット番号を割り当て解除する（すなわち、ソケット番号ををフリーのプールに返送する）。ＳｏＩＰネットワーク内の全デバイスについてグローバルＳｏＩＰソケット番号を割り当てる方法は、グローバルＳｏＩＰソケット番号を必要とするデバイスの部分集合（あるいは、ローカルのＳｏＩＰソケット番号を用いることが可能なデバイス）を指定しなくてもよいため、管理の観点から見て最も簡単な解決法である。
【００６１】
そのため、ＳｏＩＰネットワーク内の全デバイスは、ＳｏＩＰソケット番号をローカルに割り当てるか、または、ＳｏＩＰソケット番号をグローバルに割り当てている。ＳｏＩＰに適合するデバイスおよびスイッチは全て、上記モードの両方をサポートする。各デバイスまたはスイッチは、ネットワークにログインする際、サポートすべきモードをＳｏＩＰネームサーバから判定する。ＳｏＩＰネームサーバのコンフィギュレーションパラメータは、ＳｏＩＰソケット番号の割振りモードを示す。
【００６２】
ファイバチャンネルのアドレスの代わりにワールドワイドネームをコマンドに埋め込む新規形態のサードパーティコマンドフォーマットによってグローバルのＳｏＩＰソケット番号は不要となるため、ローカルのＳｏＩＰソケット番号およびグローバルのＳｏＩＰソケット番号の両方をサポートする環境は不要である。ワールドワイドネームは一意に定まるため、コマンドを受信したデバイスは、自身の視点から使用に適切なアドレス（単数または複数）を判定することができる。この新規サードパーティコマンドの１つのインプリメンテーションがＥＸＴＥＮＤＥＤ　ＣＯＰＹコマンドである。ネイティブのＳｏＩＰデバイスは、ＳｏＩＰソケット番号がローカルに割り当てられる際にワールドワイドネームをコマンドに埋め込むサードパーティコマンドのバージョンを用いると好ましい。
【００６３】
一実施形態において、ＳｏＩＰソケット番号をグローバルに割り当てる際、ｔｈｅリクエスト元は、最小数のリクエストされたソケット番号と、境界を規定する２４ビットのマスクとを示す。例えば、１６ポートスイッチは、４０９６のソケット番号と、ＦＦＦ０００（ｈｅｘ）のビットマスクとをリクエストして、これらのソケット番号を下位（ｌｏｗｅｒ）１２ビットが０となる境界に割り当てるべきであることを示す。その後、スイッチは、２５６ソケット番号を（調停ループのサポートのために）各ポートに割り当てる。指定された境界上でソケット番号を割り振ると、ポート番号に直接相関するソケット番号をスイッチによって割り当てることが可能となる。上記の例において、ビット１１：８はポートを識別する。ネイティブのＳｏＩＰデバイスは、ＳｏＩＰネームサーバからのグローバルＳｏＩＰソケット番号を１つだけ割り当てると好ましい。
【００６４】
一実施形態において、ＳｏＩＰネームサーバは、「最大ファイバチャンネル適合性」モードを選択するコンフィギュレーションパラメータも含む。この「最大ファイバチャンネル適合性」モードは、ＳｏＩＰソケット番号のグローバル割当てについての意味のみを有する。デバイスは、ネームサーバにこのパラメータの値について問い合わせすることができる。このモードは、イネーブルされると、グローバルＳｏＩＰソケット番号をスイッチに対して６５５３６のブロック（６５５３６の境界上）に割り当てるべきとの旨を指定する。このモードは、（下位８ビットによってデバイスを識別し、中間８ビットによってポートを識別し、上位８ビットによってスイッチを識別する）既存のファイバチャンネルモードのアドレスの割振りと適合する。ＳｏＩＰスイッチはこのモードを確認し、イネーブルされると、グローバルＳｏＩＰソケット番号をリクエストする際に６５５３６ソケット番号をリクエストする。このモードにおいて、ネイティブのＳｏＩＰデバイスは、ＳｏＩＰネームサーバからグローバルＳｏＩＰソケット番号を１つだけ割り振ると好ましい。
【００６５】
一実施形態によれば、（例えば、ＩＰルータの無い）層２のネットワークにおいて動作を行う場合、フレームフォーマットを変更して、カプセル化論理を簡略化する。層２のネットワークには、ＩＰヘッダまたはＵＤＰヘッダは不要である。全フレームを物理的アドレス（例えば、イーサネット（Ｒ）ＭＡＣアドレス）を用いて転送する。その後、スイッチは、層２の物理的アドレス（例えば、イーサネット（Ｒ）ＭＡＣアドレス）とＳｏＩＰソケット番号との組み合わせに基づいて、内部でフレームをルーティングする。実質的には、層２の物理的アドレスは、一意に定まる様式でＳｏＩＰデバイスを識別する様態のパラメータとしてのＩＰアドレスを取り替える。図１３は、イーサネット（Ｒ）上で送信されたＦＣＰフレーム用のフレームフォーマットを示す。イーサネット（Ｒ）タイプ値２９０をＳｏＩＰについて固有に規定して、当該フレームを受け取るステーションが当該フレームと他のフレームタイプ（例えば、ＩＰ）とを区別できるようにする。ＩＰヘッダおよびＵＤＰヘッダを除去して、フレームのオーバーヘッドを低減する。これによって得られる利点は、ＵＤＰヘッダ中の長さフィールドおよびチェックサムフィールドを生成する必要が無くなる点である。ＩＰヘッダおよびＵＤＰヘッダを生成すると、フレームの開始部分に長さおよびチェックサムが配置されるため、フレーム送信の待ち時間がさらに増加する。そのため、フレーム全体をバッファリングして長さおよびチェックサムを判定し、判定された長さおよびチェックサムをヘッダに書き込む作業が必要となる。イーサネット（Ｒ）層２のＳｏＩＰフレームの場合、フレームの終端部分に追加すべきパディングがある場合はその量を判定するだけでよい。ＰＡＤバイトの数はＳｏＩＰヘッダ内に含まれていなければならないため、受信側のステーションにおいてＰＡＤバイトを除去することができる。パディングが必要となるのは６４バイトのイーサネット（Ｒ）フレームの最小サイズを満足する際のみであるため、６４バイトのフレーム（またはフレーム全体）が受信されてからヘッダの生成を完了することが可能である。
【００６６】
層２のフレームフォーマットは、図６を参照して上述したＬａｙｅｒ３フレームフォーマットＳｏＩＰフレーム変換と類似しており、両者は以下の点において異なる：
ａ．ＩＰヘッダおよびＵＤＰヘッダがもはや存在しないこと。
【００６７】
ｂ．イーサネット（Ｒ）のタイプ値が異なること。
【００６８】
ｃ．ＣＨＥＫＳＵＭ　ＰＡＤフィールドの代わりにＦＣ　ＣＲＣフィールドを用いること。ＦＣ　ＣＲＣフィールドは、４バイトのフィールドであり、ＦＣＰヘッダおよびペイロードについて計算されるファイバチャンネルＣＲＣを含む。ファイバチャンネルデータフレームのカプセル化が変更なしに行われる場合、このフィールドはソースによって挿入され得る。そのため、フレームと共に受信されたＣＲＣは未だ有効である。
【００６９】
ｄ．ＣＨＥＣＫＳＵＭ　ＰＡＤフラグの代わりにＦＣ　ＣＲＣＰＲＥＳＥＮＴフラグを用いる。このビットはフレーム中のＦＣ　ＣＲＣフィールドの有無を示す。ＵＤＰチェックサムを計算する必要はないため、このＣＨＥＣＫＳＵＭ　ＰＡＤフィールドは意味を持たない点に留意されたい。
【００７０】
ｅ．カプセル化されたフレーム長さは最小６４のイーサネット（Ｒ）未満であり得るため、ＦＲＡＭＥ　ＰＡＤ　ＬＥＮＧＴＨはゼロ以外の値を有し得る。
【００７１】
ＵＤＰ　ヘッダは、宛先ポートフィールドおよびソースポートフィールドを含む。これらのフィールドの通常の用途は、ソフトウェアアプリケーションのうち相互通信を行っているものを識別することである。アプリケーションは、ＵＤＰ「データグラム」を送るときに用いられるポート番号をリクエストする。このポート番号は、アプリケーションによって送られる各ＵＤＰデータグラム用のソースポート番号となる。ＵＤＰデータグラムが受信されると、ＵＤＰ層はこの宛先ポート番号を用いて、当該データグラムの転送先となるアプリケーションを判定する。図１４ａは、当該分野において頻繁に用いられるＵＤＰデータグラムの「デマルチプレクス化」を示す。
【００７２】
図１４ｂおよび図１４ｃは、本発明の実施形態によるＳｏＩＰ層の追加方法を示す。図１４ｂは、全ＳｏＩＰデバイスに割り当てられた単一のポート番号が１つしかない場合のフレームのデマルチプレクス化を示す。その後、ＳｏＩＰソケット番号を用いてデマルチプレクス化をさらに行い、デバイスを判定する。その後、ＦＣＰヘッダ内に配置されたＦＣＰ交換番号に基づいて、アプリケーションに対してルーティングデータフレームを行う。図１４ｃは、上記に類似するがＳｏＩＰデバイスに割り当てられたＵＤＰポート番号が別個の番号になっている図を示す。この場合、ＵＤＰデータグラムを転送するためにＳｏＩＰソケット番号を調査する必要は無い。（ＳｏＩＰソケット番号およびＩＰアドレスは、それでもデバイスの識別を一意に定まる様式で行う）。各ＳｏＩＰデバイスについて単一のＵＤＰポート番号を用いるかあるいは全デバイスについて１つのＵＤＰポート番号を用いるかについての選択は、インプリメンテーションに依存する。
【００７３】
図１４ｂおよび１４ｃに示すＵＤＰのデマルチプレクス化の例は、１つ以上のホストバスアダプタ（ここで、これらのホストバスアダプタはＳｏＩＰデバイスである）を備えるサーバに方向付けられる。スイッチは、データフレームをエンドデバイスに転送し、アプリケーション層を処理する必要がない点において複雑性が低い場合が多い。
【００７４】
上記のアドレス指定メカニズムを用いると、ソフトウェアアプリケーションを異なるアドレスを用いたネームサーバと共に登録することにより、ソフトウェアアプリケーションをＳｏＩＰデバイスとして出現させることが可能となる。その結果、あるアプリケーションに、ネームサーバにおいて当該アプリケーションが他のアプリケーションによって利用されることを公示させる可能性が開かれる。その一例として、より高レベルのバックアップアプリケーションによって用いられ得るＣＯＰＹマネージャがある。
【００７５】
一実施形態によれば、各ストレージデバイスは、ネームサーバと共に登録を行う際、データフレームをデバイスに送る際に用いられるＵＤＰポート番号を含まなければならない。通常のＵＤＰアプリケーションにおいて、宛先ポートは、返答を送る際に用いられるソースポート番号を保存する。しかし、このメカニズムは、「レガシーの」ＦＣスイッチと用いられる場合、ソースポート番号と交換ＩＤとを相関付けるスイッチが必要となるため、実行不可能である。ストレージデバイスに常時同じＵＤＰポート番号を用いるように要求した方がずっと簡単である。
【００７６】
その結果、この実施形態によれば、ストレージデバイスは、ネームサーバデータベース中の３つのパラメータ（すなわち、ＩＰアドレス、ＵＤＰポート番号、およびＳｏＩＰソケット番号）によって識別される。さらに必要となるパラメータとして、ＩＰネットワークの場合に通常の様式で決定される物理的アドレス（例えば、イーサネット（Ｒ）ＭＡＣアドレス）がある。ＡＲＰ（アドレス解決プロトコル）は好適には、ＩＰアドレスについて用いられる物理的アドレスを知る際に用いられる。用いられる物理的アドレスは、デバイスからフレームが受信された場合にも認知可能である。例えば、ポートログインに関するリクエストが受信されると、物理的アドレスを認知することができる。この物理的アドレスは、実施のデバイスの物理的アドレスではなく、ＩＰルータの実施のデバイスのである。
【００７７】
ＳｏＩＰネームサーバ（ＳＮＳ）は、ＳｏＩＰネットワーク内の全ＳｏＩＰデバイスによって認知されたＵＤＰポート番号を持たなければならない。その理由は、ポート番号は別のソースからは分からないためである。これは、「周知の」ポート番号であるかまたは登録済みのポート番号であり得る。このアプローチは、周知のポート番号５３を有するドメインネームサーバ（ＤＮＳ）に類似する。「周知の」ポート番号の割当ては、ＩＡＮＡ（Ｉｎｔｅｒｎｅｔ　Ａｓｓｉｇｎｅｄ　Ｎｕｍｂｅｒｓ　Ａｕｔｈｏｒｉｔｙ）によって行われる。
【００７８】
ＩＰネットワーク内におけるルーティングは、アドレス指定モードの選択結果によって影響を受け、アドレス指定モードの選択結果は、スイッチおよびルータの「会話」の構成内容を判定する能力に影響を与える。１つの会話は、関連しかつ順番に到着する一連のデータフレームである。しかし、会話は順序付けられた関係は持たないものと仮定する。言い換えると、異なる会話からのフレームの順序付けは、何の影響も無く変更を行うことが可能である。例えば、３つの会話（Ａ、ＢおよびＣ）に関するフレームを以下の順序で送信すると仮定する（先ず最初にＡ１が送られる）：
【００７９】
【数１】

フレームの受信を以下のシーケンスのうち任意のシーケンスで行うことが可能となる（受容可能なシーケンスは他にも多数ある点に留意されたい）：
【００８０】
【数２】

上記シーケンスそれぞれにおいて、特定の会話に関するフレームは互いに順序付けられた状態で到着するが、他の会話からのフレームは互いに順序が無い状態で到着する。異なる会話を識別する能力により、トラフィックのルーティングを会話ベースで行うことを可能にすることにより、負荷のバランス調整を行うことが可能となる。スイッチおよびルータは、データフレーム内の複数のパラメータ（例えば、宛先／ソースアドレス、ＩＰプロトコル、ＵＤＰ／ＴＣＰポート番号など）に基づいて、会話を判定することができる。実際に用いられるパラメータは、スイッチ／ルータインプリメンテーションに依存する。
【００８１】
同一の２つのデバイス間のストレージトラフィックは、単一の会話として取り扱わなければならない。ストレージコマンド間には関係が存在し得る（例えば、待ち行列の順序付け）ため、ストレージコマンドを順序が乱れた状態で受信することは受容不可能である。したがって、スイッチ／ルータに対して一意に定まるデバイスが得られ、かつ、コマンドを区別しようとしないアドレス指定メカニズムを選択すると好ましい。この方法は全スイッチおよびルータと共に機能したため、異なるＩＰアドレスを選択すると、デバイスを区別する際に最適である。ＩＰアドレスが共有される場合、ＵＤＰポート番号をＩＰアドレスを共有するデバイスに対して一意に定まるようにすると好適である。そのため、ＩＰアドレスを共有するデバイスは、会話の分類をＵＤＰポート番号に基づいて行うスイッチおよびルータによって別個に取り扱われる可能性がある。ＳｏＩＰがＵＤＰの代わりにＴＣＰを用いてＳｏＩＰＳｏがインプリメントされた際にＵＤＰポート番号についての上記の議論はＴＣＰヘッダポート番号に適用されることが理解される。
【００８２】
図１５は、本発明の実施形態によるファイバチャンネルおよびギガビットイーサネット（Ｒ）の両方をサポートするスイッチポートの基本的アーキテクチャを示す高レベルブロック図である。このファイバチャンネルおよびギガビットイーサネット（Ｒ）ポートが用いる符号化／復号化法（８Ｂ／１０Ｂ）が同じであり、各ポートには、高速シリアルインターフェースとの変換を行うためのシリアライザ／デシリアライザ（ＳＥＲＤＥＳ）ブロックが必要となる。そのため、この実施形態において、これらの２つのインターフェースは、図１５に示すように８Ｂ／１０Ｂブロック３１０およびＳＥＲＤＥＳブロック３１５を共有する。これらの２つのインターフェースタイプは、ファイバチャンネルが１０６２．５ＭＨｚで動作し、ギガビットイーサネット（Ｒ）が１２５０ＭＨｚで動作しているときのクロック速度について異なる。これらのインターフェースのうち高速バージョンのインターフェースも開発中であり、異なるクロック速度を有する。そのため、マルチプレクサ３４５は、論理によって用いられるクロックをポートタイプに基づいて選択する。さらに、これらの２つのインターフェースは、スイッチファブリック（管理インターフェースを含む）とインターフェースをとるスイッチファブリックインターフェース論理ブロック３２０を共有する。ＭＡＣブロック（ブロック３２５および３３０）は、インターフェース（ファイバチャンネルまたはギガビットイーサネット（Ｒ））用の適切なプロトコル状態マシンをインプリメントする。ＭＡＣブロック３２５および３３０は、受信したデータをフレームに変換し、変換されたフレームは、ルーティング論理ブロック３３５および３４０にそれぞれ転送される。ＭＡＣブロック３２５および３３０はまた、ルーティング論理ブロック３３５および３４０それぞれからデータフレームも受信し、その後、これらのデータフレームは、インターフェースの（ファイバチャンネルまたはギガビットイーサネット（Ｒ）の）プロトコルに応じて送信される。ルーティング論理ブロック３３５および３４０は、受信された各フレームのルーティング先をフレーム内のアドレス指定情報に基づいて決定する。ルーティング論理ブロック３３５および３４０はまた、フレームに必要な任意の変更も行う。例えば、ルーティング論理ブロックは、ファイバチャンネルポートに転送中のフレームからＳｏＩＰカプセル化を除去する。その後、ルーティング論理ブロックは、フレームを宛先出力ポートの表示物と共にスイッチファブリックに送る。退出（Ｅｇｒｅｓｓ）データフレーム（スイッチファブリックから出力ポートへのフレーム）は、ルーティング論理ブロックによって受信され、関連付けられたＭＡＣに転送される。ＭＡＣがフレームを受信する前に、ルーティング論理ブロックによってフレームにさらに処理を行ってもよい。例えば、イーサネット（Ｒ）ポートルーティング論理ブロック３４０は、ファイバチャンネルフレームをＳｏＩＰフレームに変換し得る。
【００８３】
図１６に示す本発明の別の実施形態によれば、図１５の２つのルーティングブロックを組み合わせて単一のルーティング論理ブロック３５０にする。このような最適化が可能なのは、これらの２つのインターフェースが用いるルーティング論理は極めて類似性が高いからである。一実施形態において、ルーティング論理ブロック３５０は、ポートタイプに依存する論理ブロックと、双方のポートタイプに共通する他のブロックとを含む。この最適化により、ＡＳＩＣ上に必要な論理ゲートの数が低減する。ルーティングブロック３５０は、フレームのルーティング先をデータフレーム内のアドレス指定情報に基づいて決定する。この機能はアドレス解決として知られ、ファイバチャンネルおよびギガビットイーサネット（Ｒ）データフレームの両方に行われる。そのため、ルーティング論理の際にポートタイプに基づいて異なるデータを選択しなければならないものの、アドレス解決論理をこれらの２つのポートインターフェースによって共有することが可能となる。ルーティング論理ブロック３５０内の論理は、ハードコード化論理としてもインプリメント可能であり、あるいは、ネットワークプロセッサを用いたプログラム可能な方法（この方法は、パケット処理専用に設計され、ファイバチャンネルフレームまたはイーサネット（Ｒ）フレームのいずれかをルーティングするようにプログラムすることが可能である）としてもインプリメント可能である。そのため、異なるネットワークプロセッサソフトウェアを用いることにより、ルーティング論理ハードウェアを共有することができる。一実施形態において、ルーティング論理ブロック３５０はまた、２つのポートインターフェースによって共有される入力／出力ＦＩＦＯメモリも含む。共有可能なさらなる論理として、統計レジスタおよび制御レジスタがある。統計レジスタを用いて、受信されたフレームと、送信されたフレームと、受信されたバイトと、送信されたバイトとの数などをカウントする。共通する一連の統計レジスタを用いることが可能である。これらのレジスタは、各ＭＡＣからの制御信号によって変更される。制御レジスタは、各ＭＡＣの動作モードを決定する。共通する一連の統計レジスタおよび制御レジスタにより、レジスタのインプリメントおよび外部の制御ソース（例えば、スイッチ管理ＣＰＵ）とのインターフェースに必要な論理が低減する。
【００８４】
図１７に示すような別の実施形態において、低レベルのポートインターフェース論理（例えば、ＦＣ　ＭＡＣブロック３２５およびイーサネット（Ｒ）ＭＡＣブロック３３０）を組み合わせて、単一のＭＡＣブロック３６０にする。しかし、このアプローチの場合、これらの２つの論理ブロック間の共通点が少ないという問題がある。さらに、ギガビットイーサネット（Ｒ）ＭＡＣおよびファイバチャンネルポートインターフェース論理をインプリメントする所有ブロックを購入することが可能である。これらの２つのブロックを組み合わせると、これらの所有ブロックの使用は極度に妨害される。
【００８５】
図１８に示す本発明別の実施形態よれば、現場でプログラム可能なゲートアレイ（ＦＰＧＡ）３７０を用いて、ポートによってサポートされるインターフェースプロトコルを選択する。ロードされるＦＰＧＡのコンフィギュレーションは、サポートタイプに基づく。この実施形態において、ファイバチャンネルインターフェースおよびギガビットイーサネット（Ｒ）インターフェースについて別個のＦＰＧＡコードを展開する。そのため、ＦＰＧＡ論理を特定のインターフェースに合わせて最適化することができる。単一のハードウェア設計により双方のインターフェースをサポートし、ソフトウェアにより、ポートタイプに基づいてＦＰＧＡコードをダウンロードすることを決定する。
【００８６】
共通ポートは、ＡＳＩＣの外部にある物理的インターフェースも取り扱わなければならない。周知のように、このようなインターフェースを挙げると、例えば、銅（Ｃｏｐｐｅｒ）、マルチモードファイバインターフェースまたは単モードファイバインターフェースがある。また、これらのコンポーネントは、ファイバチャンネルおよびイーサネット（Ｒ）間において必ずしも同一でなくてもよい。図１９に示す本発明の実施形態によれば、ギガビットインターフェース変換器（ＧＢＩＣ）３８０を提供して、ユーザが所望の物理的インターフェースを選択できるようにする。ＧＢＩＣは、共通形態要素および電気インターフェースを有する標準化モジュールであり、上記の多くの物理的インターフェースのうち任意のものを取り付けることを可能にする。ＧＢＩＣモジュールは、多くの供給業者（例えば、ＨＰ、ＡＭＰ、Ｍｏｌｅｘなど）から市販されており、標準ファイバチャンネルインターフェースおよびギガビットイーサネット（Ｒ）物理的インターフェースを全てサポートする。図１４は、共通ＦＣ／ギガビットイーサネット（Ｒ）ポートインターフェース（例えば、図１５、１６、１７および１８に示すようなもの）がこの実施形態によるＧＢＩＣインターフェースと組み合わされた様子のブロック図を示す。ＡＳＩＣは、ユーザがＧＢＩＣモジュールを変更することを可能にするＧＢＩＣコネクタ３８５に接続する。そのため、ユーザは、適切なＧＢＩＣ３８０を取り付けることにより、メディアタイプを選択することができる。
【００８７】
ＧＢＩＣモジュールは典型的にはシリアルＥＥＲＯＭを含み、このシリアルＥＥＲＯＭの内容を読み出して、モジュールタイプ（例えば、ファイバチャンネル、ギガビットイーサネット（Ｒ）、インフィニバンド、銅、マルチモード、単一の−モードなど）を判定することができる。したがって、ＧＢＩＣは、使用するインターフェースのタイプ（例えば、ＦＣもしくはＧＥまたはインフィニバンド）を示すことができる。しかし、ＧＢＩＣが複数のインターフェース（例えばＦＣおよびＧＥの両方）をサポートすることも可能である。したがって、一実施形態において、ポートインターフェースタイプはユーザによるスイッチ／構成が可能であり、別の実施形態において、リンクインターフェースのタイプを、さらなるインテリジェンス（例えば、「ハンドシェーク」）を通じて自動的に決定する。
【００８８】
本発明の別の実施形態によれば、ＳｏＩＰインテリジェントネットワークインターフェースカード（ＮＩＣ）４００を図２０に示すように設ける。ＮＩＣカード４００は、ＩＰトラフィックおよびＳｏＩＰトラフィック両方を送信および受信することができる。いずれの場合においても、ＮＩＣカード４００は、トラフィックのタイプを決定し、決定結果に応じて当該トラフィックを方向付けるインテリジェンスを有する。
【００８９】
ホスト４１０は、ストレージコマンドおよびネットワークコマンドをＰＣＩインターフェース４２０を通じてＮＩＣカード４００に発行することができる。これらのコマンドは、コマンドを直接経路またはストレージトラフィックエンジンのいずれかに方向付ける際に用いられる指定アドレスと共に送られる。ストレージコマンドは、ＳＣＳＩコマンドセットを介して発行され、ネットワークコマンドは、ウィンソックおよび／またはＴＣＰ／ＩＰを介して発行される。
【００９０】
ＮＩＣカード４００は、上記指定アドレスに基づいてストレージコマンドをストレージトラフィックエンジン４３０に方向付ける。ストレージトラフィックエンジン４３０は、ＳＣＳＩが動作する間の交換の管理およびのシーケンス管理を取り扱う。その後、ＳＣＳＩの動作はＳｏＩＰを介して実行され、メディアアクセスコントローラ（ＭＡＣ）ブロック４５０（これは、一実施形態において、ギガビットイーサネット（Ｒ）ＭＡＣである）を介してネットワーク４７０に送信される。ＮＩＣカード４００は、指定アドレスに基づいて非ＳｏＩＰトラフィックを直接経路４４０に方向付ける。この直接経路４４０はこれらのコマンドを処理し、指定パケットをブロック４５０を介してネットワーク４７０に送信する。ネットワーク４７０からのデータをＭＡＣ４５０を介して受信する際、ＮＩＣ４００は、トラフィックをデマルチプレクスし、デマルチプレクスに結果に応じてそのトラフィックを方向付ける。ＳｏＩＰとして受信されたストレージトラフィックは、ストレージトラフィックブロック４３０に送られる。非ＳｏＩＰトラフィックは、直接経路４４０を介してホストに直接送られる。
【００９１】
マルチプレクサブロック４６０が出力経路について調停を取り扱うのは、直接経路４４０およびストレージトラフィックエンジン４３０の両方が同時にトラフィックをＭＡＣ４５０送ったときである。ネットワーク４７０からＭＡＣ４５０へと受信されたトラフィックの場合、Ｍｕｘブロック４６０は、そのトラフィックをデマルチプレクスし、デマルチプレクス結果に応じてそのトラフィックを直接経路４４０またはストレージトラフィックエンジン４３０のいずれかに送る。
【００９２】
例示目的のためにそして特定の実施形態を用いて本発明について説明してきたが、本発明はこれらの開示された実施形態に限定されないことが理解される。それどころか、当業者にとって明らかなように、本発明は、様々な変更および類似の構成を含むものとして意図される。従って、本明細書中の特許請求の範囲は、このような変更および類似の構成を包含するものとして、最大範囲に解釈されるべきである。
【図面の簡単な説明】
【図１】
図１は、本発明によって構築されたＳＡＮの一例を示す。
【図２】
図２は、インターネットプロトコル（ＳｏＩＰ）上に実現されるストレージの概略のブロック図である。
【図３】
図３は、本発明の一実施形態による、装置内のファイバチャンネル、ＳＣＳＩおよびＩＰデバイスとスイッチファブリックとの間で必要なプロトコル変換の工程を示す。
【図４】
図４は、本発明の機能が達成されるレガシーのストレージプロトコル変換方法の概略である。
【図５】
図５は、本発明の一実施形態による、物理的な装置の基本アーキテクチャを概略するハイレベルなスイッチ図である。
【図６ａ】
図６ａは、本発明の一実施形態による、ＦＣＰパケットのカプセル化を示す。
【図６ｂ】
図６ｂは、本発明の一実施形態による、ＦＣＰパケットのカプセル化を示す。
【図６ｃ】
図６ｃは、本発明の一実施形態による、ＦＣＰパケットのカプセル化を示す。
【図７】
図７は、ＳｏＩＰネットワークに接続されたファイバチャンネルデバイスの「セッション」初期化フレームの流れを示す。
【図８】
図８は、本発明の一実施形態による、スイッチ１のＦＣポートＡによって開始し、そして離れて設けられているスイッチ２のＦＣポートＢまでのノードのログインのデータフレームの流れを示す。
【図９】
図９は、本発明の一実施形態による、スイッチ１のＦＣポートＡによって開始し、そして離れて設けられているスイッチ２のＦＣポートＢまでのノードのログインのデータフレームの流れを示す。
【図１０】
図１０は、本発明の一実施形態による、ローカルのＦＣポートのポートのログインのリクエストフレームおよび応答フレームのルーティングを示す。
【図１１】
図１１は、本発明の一実施形態による、ネットワーク内に存在するアドレスドメインの一例を示す。
【図１２ａ】
図１２ａは、サードパーティのコマンド例のネットワークアーキテクチャおよびアドレステーブルを示す。
【図１２ｂ】
図１２ｂは、サードパーティのコマンド例のネットワークアーキテクチャおよびアドレステーブルを示す。
【図１２ｃ】
図１２ｃは、サードパーティのコマンド例のネットワークアーキテクチャおよびアドレステーブルを示す。
【図１２ｄ】
図１２ｄは、サードパーティのコマンド例のネットワークアーキテクチャおよびアドレステーブルを示す。
【図１３】
図１３は、本発明の一実施形態による、層２のＦＣＰパケットのカプセル化を示す。
【図１４ａ】
図１４ａは、本発明の実施形態による、ＵＤＰフレームの多重分離の例を示す。
【図１４ｂ】
図１４ｂは、本発明の実施形態による、ＵＤＰフレームの多重分離の例を示す。
【図１４ｃ】
図１４ｃは、本発明の実施形態による、ＵＤＰフレームの多重分離の例を示す。
【図１５】
図１５は、本発明の一実施形態による、ファイバチャンネルおよびイーサネット（Ｒ）の両方をサポートするスイッチポートの基本アーキテクチャを示すハイレベルなブロック図である。
【図１６】
図１６は、本発明の一実施形態による、ファイバチャンネルおよびイーサネット（Ｒ）の両方をサポートするスイッチポートの基本アーキテクチャを示すハイレベルなブロック図であり、２つのルーティングブロックは、１つのブロックに組み合わされている。
【図１７】
図１７は、本発明の一実施形態による、ファイバチャンネルおよびイーサネット（Ｒ）の両方をサポートするスイッチポートの基本アーキテクチャを示すハイレベルなブロック図であり、ローレベルのポートのインターフェース論理のブロックは組み合わされている。
【図１８】
図１８は、本発明の一実施形態による、ファイバチャンネルおよびイーサネット（Ｒ）の両方を、フィールドプログラム可能なゲートアレー（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）（ＦＰＧＡ）を用いてサポートするスイッチポートの基本アーキテクチャを示すハイレベルなブロック図である。
【図１９】
図１９は、本発明の一実施形態による、ＧＢＩＣインターフェースと組み合わされた共通のＦＣ／ギガビットのイーサネット（Ｒ）のポートのブロック図を示す。
【図２０】
図２０は、本発明の一実施形態による、インテリジェントネットワークのインターフェースカード（ＮＩＣ）のアーキテクチャを示す。[0001]
(Cross reference with related applications)
This application is filed on March 10, 1999, entitled "METHOD AND APPARATUS FOR TRANSFERRING DATA BETWEEN IP NETWORK DEVICES AND SCSI AND FIBER CHANNEL DEVICES OVER ANIPK 60, US Provisional Patent No. 60, US Provisional Patent No. 60, US Provisional. Attorney No. 019678-000100). The disclosure of this document is incorporated herein by reference in its entirety.
[0002]
(Background of the Invention)
The present invention relates to information transfer between a storage device and a network via a packet switching communication system. In particular, the present invention relates to a method and apparatus for receiving, translating and routing data packets between SCSI (compact computer system interface), Fiber Channel and Ethernet devices in a flexible and programmable manner.
[0003]
In an enterprise computing environment, it is desirable that multiple servers have direct access to multiple storage devices to support high-bandwidth data transfer, system expansion, modularity, configuration flexibility and resource optimization, and It is useful. In a traditional computing environment, such access is typically provided via a file system level local area network (LAN) connection, which operates a fraction of the time when connected directly to storage. Therefore, access to the storage system is very likely to be a bottleneck.
[0004]
A storage area network (SAN) has been proposed as one method for solving the bottleneck of access to storage. By applying this networking paradigm to storage devices, SANs enable increased connectivity and bandwidth, resource sharing and configuration flexibility. The current SAN paradigm assumes that the entire network is built using Fiber Channel switches. Thus, most solutions for SANs require the implementation of separate networks, one supporting a regular LAN and one supporting a SAN. New equipment and technologies, including new equipment at the storage device level (Fibre Channel interface), host / server level (Fibre Channel adapter card) and transport level (Fibre Channel hubs, switches and routers), are used in mission-critical enterprise computing Introducing into the environment may be described as less favorable for data center managers as this involves duplication of network infrastructure, new technologies (ie Fiber Channel) and new training of staff. Most companies have already invested a significant amount of money to build and maintain their own networks (eg, based on Ethernet and / or ATM). Building a second high-speed network based on different technologies has been a significant obstacle to the widespread use of SANs. Thus, a method and apparatus that alleviates the problem of accessing storage devices by multiple hosts, while maintaining current equipment and network infrastructure, and minimizing the need for new training of data center personnel. There is a need.
[0005]
Typically, the majority of storage devices currently use "parallel" SCSI or Fiber Channel data transfer protocols, and most LANs use Ethernet protocols, such as Gigabit Ethernet. SCSI, Fiber Channel, and Ethernet (R) are data transfer protocols, each of which performs data transfer using a different individual format. For example, SCSI instructions are designed to be implemented via a parallel bus architecture and are therefore not packetized. Like Ethernet®, Fiber Channel uses a serial interface with data transferred in packets. However, the physical interface and frame format between Fiber Channel and Ethernet® are not compatible. Gigabit Ethernet is based on the Ethernet packet architecture because it was designed to be compatible with existing Ethernet infrastructure. Because of these differences, there is a need for new methods and devices that allow for efficient communication between these protocols.
[0006]
(Summary of the Invention)
The present invention solves the above and other problems by providing a method and apparatus for transferring data between a storage device interface and a network interface, thereby evolving useful state of the art. Specifically, the present invention provides a means for Internet Protocol (IP) devices to transparently communicate with SCSI and Fiber Channel devices over an IP network without installing expensive Fiber Channel switches and hubs. Introduce advanced SAN capabilities into existing enterprise computing configurations. The present invention accomplishes this using Fiber Channel Protocol (FCP), an industry standard developed for the implementation of SCSI commands over Fiber Channel networks. The present invention allows the storage device to maintain use of standard SCSI and Fiber Channel storage interfaces, and to build a SAN using the company's existing network infrastructure. Therefore, no changes are required within the host hub adapter (HBA) or storage device (eg, disk drive, tape drive, etc.).
[0007]
In accordance with the present invention, there is provided a method and apparatus for transferring data between an IP device (including, but not limited to, a gigabit Ethernet device) and a SCSI or Fiber Channel device. The interface of the device can be any of an IP interface such as SCSI, Fiber Channel or Gigabit Ethernet. Data is switched between SCSI and IP, between Fiber Channel and IP, or between SCSI and Fiber Channel. Data can also be switched from SCSI to SCSI, from Fiber Channel to Fiber Channel, and from IP to IP. The port interface provides a conversion from the input frame format to an internal frame format, and the internal frame format may be routed within the device. The device may include any number of all ports. The amount of processing performed by each port interface depends on the type of the interface. The above processing capabilities of the present invention allow for the rapid transfer of information packets between multiple interfaces at latency levels that meet the stringent requirements of storage protocols. Configuration control can be applied to each port on the switch, and then to each switch on the network via SNMP or a web-based interface, providing flexible and programmable control to the device.
[0008]
According to one aspect of the present invention, a method is provided for routing data packets within a switching device in a network such as a SAN. The method typically comprises receiving a packet from a first network device at an interface of a first port of the switch device, wherein the packet is a SCSI formatted packet (ie, a SCSI converted packet). Format data stream), a packet formatted in a Fiber Channel (FC) format, and a packet formatted in an Internet Protocol (IP) format, wherein the first port interface is the first port interface. Communicatively coupled to a network device, and converting the received packet to a packet having an internal format. The method typically further comprises routing the packet in the internal format to a second port interface of the switch device, wherein the packet in the internal format is a SCSI formatted packet, a FC formatted packet or an IP format. Re-converting the packet into one of the packets formatted in the above, and communicating the re-converted packet to a second network device communicatively coupled to the second port interface.
[0009]
According to another aspect of the present invention, there is provided a network switch device typically including a first port interface. The first port interface is means for receiving a data packet from a network device, wherein the receiving means is a SCSI formatted packet and a Fiber Channel (FC) formatted packet from the first network device. Means for receiving one of the packets, and means for converting the received packet to a packet having an internal format, wherein the received data packet is converted to a first packet having the internal format. And The switch device typically further includes a second port interface. The second port interface is means for reconverting a packet from the internal format to the IP format, wherein the first packet is converted to a packet having the IP format, and transmitting the IP packet to the network. Means for transmitting a packet formatted in the IP system to an IP network. Means are further provided for routing the first packet to the second port interface.
[0010]
According to yet another aspect of the present invention, there is provided a network switch device that typically includes a first port interface. The first port interface is means for receiving a data packet from an IP network, the first interface means receiving a packet in an IP format, and converting the received packet into a packet having an internal format. Means for converting the received packet into a first packet having an internal format. The switch device typically further includes a second port interface. The second port interface includes means for re-converting the packet having the internal format into a packet having the SCSI format, and transmitting the converted packet to a SCSI network device. The switch device typically further includes a third port interface. The third port interface includes means for re-converting the packet having the internal format into a packet having the FC format, and transmitting the re-converted packet to an FC network device. Means for routing packets between the first port interface and the second and third port interfaces are typically further provided. During operation, when the first packet is routed to the second port interface, the first packet is converted to the SCSI format and communicated to the SCSI network device. When the first packet is routed to the third port interface, the first packet is converted to the FC format and transmitted to the FC network device.
[0011]
According to a further aspect of the present invention, there is provided a network switch device for use in a storage area network (SAN). The switch device typically includes a first port interface communicatively coupled to a SCSI device, wherein the first port interface converts a SCSI formatted data packet received from the SCSI device into a data packet having an internal format. The first port interface converts the data packet having the internal format into a SCSI format data packet. The switch device typically further includes a second port interface communicatively coupled to the FC device, wherein the second port interface converts an FC format data packet received from the FC device into data having an internal format. The second port interface converts the data packet having the internal format into an FC format data packet. The switch device is further typically a third port interface communicatively coupled to the IP device, the switch device converting an IP format data packet received from the IP device into a data packet having an internal format, The third port interface, the first port interface, the second port interface, and the third port interface for converting a data packet having a format into an IP format data packet. A switch fabric for routing data packets having an internal format. In normal operation, a first of the SCSI device, the FC device, and the IP device transmits a first data packet to a second device that is one of the SCSI device, the FC device, and the IP device. The port interface coupled to the first device converts the first data packet to a packet having the internal format, and converts the internal format packet through the switch fabric to the second data packet. To the port interface coupled to the device. The port interface coupled to the second device re-converts the packet in the internal format to a format associated with the second device and sends the re-converted packet to the second device.
[0012]
According to a further aspect of the present invention, there is provided a network switch device for use in a storage area network (SAN). The switch may include any combination of Fiber Channel, SCSI, Ethernet, and InfiniBand ports, and may include any number of all ports. The switch device is typically a first port interface communicatively coupled to one of the SCSI device (s), FC device or IP device, and a second port interface, wherein the FC device or A second port interface configurable to communicate with any of the Ethernet devices, and routing data packets having the internal format between the first port interface and the second port interface. Switch fabric. In normal operation, when the second port interface is configured to communicate with an FC device, the second port interface converts an FC format data packet received from the FC device into a data packet having an internal format. The second port interface converts the data packet having the internal format received from the switch fabric into an FC format data packet. When the second port interface is configured to communicate with an Ethernet device, the second port interface converts an Ethernet format data packet received from the Ethernet device into an internal format. The second port interface converts the data packet having the internal format received from the switch fabric into an Ethernet® format data packet. The second port interface may be self-configurable, or may be user configurable.
[0013]
Reference to the remaining portions of the specification, including the drawings and claims, will realize other features and advantages of the present invention. Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.
[0014]
(Description of a specific embodiment)
FIG. 1 shows an example of a storage area network (SAN) 10 according to an embodiment of the present invention. As shown, the network 10 includes a tape library 15, a RAID drive 20, and an optical drive 25 (eg, CD, DVD, etc.) and a number of storage devices such as a server 30. The storage device may be either a storage target (eg, tape library 15, RAID drive 20, etc.) or an initiator (eg, server 30). Note that a device may be both an initiator and a target. In a preferred embodiment, the present invention is implemented in switching device 35 in network 10. For example, as shown in FIG. 1, each switching device 35 is an “edge” switch, providing a connection between a node (ie, one or more storage devices) and a network 40. That is, the switch is at the "edge" of the network where the device is located. Each end switch 35 allows the connected storage elements to communicate via the end switch (no traffic is sent to the network 40). Each end switch 35 further allows storage elements connected to different end switches to communicate with each other via the network 40. In the preferred embodiment, network 40 is an Ethernet network, but other networks such as Asynchronous Transfer Mode (ATM) based networks or FDDI based networks may be used.
[0015]
In one embodiment, as shown in FIG. 2, the switching device 35 is implemented in a storage area network (SAN) of SoIP (Storage via Internet Protocol). According to the present invention, SoIP is a framework for transporting SCSI commands and data using the SCSI Fiber Channel Protocol (FCP) for communication between IP networked storage devices over an IP network. It is. Most storage devices currently communicate using either a "parallel" SCSI bus or a Fiber Channel serial interface. FCP is an FC-4 upper layer protocol that sends SCSI commands and data over a Fiber Channel network forming a "serial" SCSI network. The SoIP framework enables FCP used on IP networks by defining the SoIP protocol. The storage device and the host bus adapter running the SoIP protocol form a storage area network (SAN) directly on the IP network. This framework offers outstanding advantages in terms of SAN installation and utility.
[0016]
As shown in FIG. 2, each SoIP device 50 converts SCSI commands and data into FCP data frames in FCP block 52. Block 54 of the SoIP protocol layer then encapsulates these FCP frames into multiple IP packets using either the User Datagram Protocol (UDP) or the Transport Control Protocol (TCP). IP port 56 forwards the packet to IP network 60, which routes the IP packet between devices 50 or to switch 35. Network 60 is preferably an Ethernet network, but may be based on any IP compatible medium, including ATM, FDDI, SONET, and the like. The storage name server 65 functions as a database where devices store their information and retrieve information about other devices in the SoIP network. The SoIP proxy 70 performs a protocol conversion between UDP-based SoIP and TCP-based SoIP.
[0017]
Since most storage devices currently use "parallel" SCSI or Fiber Channel protocols, the transition to a SoIP-based SAN is hampered unless such "legacy" devices can be connected to a SoIP network. Can be rare. For these "legacy" devices, the switches shown in FIG. 3 are provided for connection to a SIP SAN.
[0018]
FIG. 3 illustrates data switching between storage devices using a switch 135, according to one embodiment of the present invention. In this embodiment, switch 135 is configured to receive data from different interfaces, each having a different data or frame format. SCSI device 105 communicates data using a "parallel" SCSI interface 106, Fiber Channel (FC) device 110 communicates data using Fiber Channel interface 111, and Ethernet device 115 communicates with Ethernet ( R) Transmit data using interface 116. The switch 135 converts data in one of three different formats received from the source port into an internal format, and forwards the data in the internal format to the destination port via the switch fabric 140. The destination port converts the data into a native format suitable for connecting to the destination port.
[0019]
In this embodiment, each device such as SCSI device 105, FC device 110, Ethernet device 115 or generic IP device 120 (eg, disk drive, tape drive, server) is based on a SCSI instruction set. Perform storage operations. For Fiber Channel device 110, SCSI commands and data are converted to FCP and communicated using Fiber Channel interface 111. With respect to SCSI device 105, SCSI instructions and data are transferred directly using "parallel" bus 106. In this embodiment, the SCSI port interface 125 of the switch 135 behaves like SCSI to an FC bridge, such that the SCSI ports look like FC ports from the perspective of the switch fabric 140. As shown, the SCSI data is preferably converted to FCP and not actually communicated using the Fiber Channel interface. For Ethernet devices 115, SCSI commands and data are converted to FCP and encapsulated in IP packets using UDP or TCP. Next, the IP packet is encapsulated in an Ethernet frame and transmitted using the Ethernet interface 116. Note that the term "SCSI device" implies a device with a "parallel SCSI bus" and the term "fiber channel device" implies a device with a fiber channel interface. Both devices operate as SCSI devices at the instruction level. Note that SCSI device 105 does not convert SCSI instructions and data to FCP format. Therefore, it is not possible to directly transfer data between the FC device 110 and the SCSI device 105. As shown in FIG. 3, since the data format of all interfaces in the switch fabric 140 is a frame compatible with FCP, all devices connected to the switch 135 can switch the data frame. . Note further that the Fiber Channel can be replaced with another interface. For example, FIG. 3 shows a storage device built using Ethernet in the same manner as the device was built using FC. Ethernet has simply replaced Fiber Channel as the transport medium. InfiniBand may also be implemented, for example, in generic IP device 120. As is well known, InfiniBand is an I / O interface that combines the functions of NGIO (Next Generation I / O) and future I / O.
[0020]
FIG. 4 illustrates data switching between Fiber Channel, SCSI, and IP devices in a switch device 135 according to one embodiment of the present invention. Although the example of FIG. 4 is for an Ethernet-based IP network 160, any other IP network based on other protocols, such as ATM, FDDI, etc., may be used. Like the embodiment of FIG. 3, FIG. 4 shows the protocol conversion performed on each device. The SCSI device 105 communicates with the switch 135 by directly using the SCSI instructions without encapsulating the data or instructions in a data frame. The FC device 110 sends SCSI commands and data to the switch 135 using the FCP protocol. The switch 135 converts the received data into a common protocol based on FCP, allowing the devices to communicate with each other. Further, as described in more detail below, switch 135 performs address translation between Fiber Channel and SCSI addressing schemes for IP addressing schemes. This is done transparently so that no changes are needed in the Fiber Channel device 110 or SCSI device 105 or in any host bus adapter, driver software or application software.
[0021]
FIG. 5 is a high-level switch diagram outlining the basic architecture of the physical switch device 235, according to one embodiment of the present invention. In this embodiment, switch 235 includes three main elements: switch fabric 240, management processor 250, and port interface 270. Switch fabric 240 provides a high bandwidth mechanism for transferring data between various port interfaces 270 and between port interface 270 and management processor 250. The management processor 250 mainly performs management-related functions of the switch 235 (for example, switch initialization, environment setting, SNMP, fiber channel service, etc.) via the management bus 255.
[0022]
Port interface 270 converts data packets from an input frame format (eg, parallel SCSI, FC or Ethernet) to an internal frame format. The internal frame format data packet is then routed within switch fabric 240 to the appropriate destination port interface. Port interface 270 also determines how packets are routed within the switch. The amount of processing performed by each port interface 270 depends on the type of interface. SCSI port 270 ₁ And 270 ₂ Provides most processing because the SCSI interface is half-duplex and not frame-oriented. SCSI port interface 270 ₁ And 270 ₂ Further emulates SCSI host and / or target functionality. Fiber Channel port 270 ₃ And 270 ₄ Requires the least amount of processing because the internal frame format is most compatible with Fiber Channel. Basically, IP port 270 ₅ And 270 ₆ (Eg, Ethernet port) and SCSI port 270 ₁ And 270 ₂ Converts the received data into an internal frame format before transmitting the packet through the switch fabric 240.
[0023]
If the FCP frame is compatible with the Fiber Channel interface, it is not directly compatible with the Ethernet interface. Therefore, the transmission of the FCP packet on the Ethernet interface requires the FCP frame as shown in FIG. Need to be encapsulated within an Ethernet frame.
[0024]
FIG. 6a shows an FCP packet encapsulated in an IP frame, carried over an Ethernet frame, according to one embodiment of the present invention. The field definitions in FIG. 6a include:
[0025]
DA: Ethernet (R) destination address (6 bytes)
SA: Ethernet (R) source address (6 bytes)
Type: Ethernet (R) packet type
Checksum pad: An optional 2-byte field that can be used to ensure that the UDP checksum is correct if the data frame starts transmitting before all content is known. The checksum pad bit in the SoIP header indicates whether this field is present.
[0026]
Ethernet (R) CRC: Cyclic Redundancy Check (4 bytes)
As shown in FIG. 6a, the SoIP header field includes the following parameters.
[0027]
Classification: This 4-bit field indicates a service classification. In one embodiment, only two or three values are used.
[0028]
VERS: This 4-bit field indicates the protocol version of the SIP.
[0029]
SoIP flag: This 8-bit field contains bits indicating various parameters of the data frame shown in FIG. 6B.
[0030]
In FIG. 6a, the User Datagram Protocol (UDP) header is the protocol used in the IP packet. TCP may be used. The UDP header defined in RFC768 is 8 bytes long, which consists of four 16-bit fields with the following field definitions, shown in FIG. 6c.
[0031]
Source Port: Optional field. If meaningful, this indicates the port of the sending process, and in the absence of other information it can be assumed that the response is the port to be addressed. If not used, a value of 0 is inserted.
[0032]
Destination port: meaningful within the context of a particular Internet destination address.
[0033]
Length: The length in bytes of the user datagram including the UDP header and data (hence, if there is no data in the datagram, the length is 8). For an encapsulated FCP packet, the UDP length is the sum of the UDP header length, the FCP header length and the FCP payload length, and optionally the checksum pad.
[0034]
Checksum: 16-bit one's complement of the one's complement sum of the pseudo header of the information. This information is the IP header, UDP header, and data padded at the end with zero bytes (if necessary) to a multiple of two bytes.
[0035]
In one embodiment, switch 235 encapsulates the FC packet in an Ethernet frame using a "wrapper" around the FC information. Since the maximum FCP data frame size is 2136 bytes (24-byte header + 2112 byte payload) and the maximum size of an Ethernet packet is 1518 bytes, the FCP data frame is included in the Ethernet packet. For encapsulation, it may be necessary to limit the size of the FCP data frame. Using Ethernet jumbo frames, which allows packet sizes up to 9 Kbytes to be used, eliminates the need to limit the frame size of Fiber Channel. However, support for Ethernet jumbo frames is limited within the existing network infrastructure. Thus, FCP data frames need to be restricted, otherwise, large FCP data frames may need to be “split” into two separate Ethernet frames. The login procedure specified in the Fiber Channel standard allows the device to negotiate a maximum payload with the switch fabric 240. Accordingly, switch fabric 240 may respond to the login with a payload size smaller than the maximum payload size (eg, 1024 bytes). Switch 235 takes advantage of this to limit FC packets to a size that can be encapsulated in Ethernet packets, eliminating the need to split FC packets. According to one embodiment, the field size of the node's largest received data is provided to the switch fabric 240 during "fabric login" and to each destination node during "port login". A fabric or node in the "logged-in" state generates a login response indicating the maximum received data field size of a data frame that can be received. Note that these values may not be the same. For example, a fabric may have a maximum allowed size of 2112 bytes, while a node (eg, Hewlett-Packard's Tachyon-Lite Fiber Channel Controller) may limit the maximum size to 1024 bytes. The source node cannot transmit a data frame larger than the maximum frame size determined for the login response.
[0036]
Because the encapsulated FCP data frame cannot be longer than the maximum Ethernet packet size, an upper limit is imposed on the payload size of the frame during login by the device. According to one embodiment, the upper limit is set by determining or retrieving the maximum IP datagram size and subtracting 60 bytes that account for the various header and trailer percentages. For example, for Ethernet frames, the upper limit is equal to 1440 bytes. That is, the payload of the FCP frame cannot exceed 1440 bytes in size. This restriction is established because FCP frames transported over an IP network cannot be split. If an IP datagram can be divided, most networks are hardly divided because the performance of the network is reduced. The Do Not Fragment Flag of the IP header may be used to prevent the IP layer from splitting the datagram. This bit is set to ensure that splitting does not occur, even if there is a node login that sets the proper size in the FCP payload. According to one embodiment, the payload is padded to a multiple of 4 bytes to facilitate conversion into frames to be sent to legacy FC devices.
[0037]
Each switch 235 preferably utilizes a Buffer to Buffer Receive Data Field size to fit within the IP packet carried over the Ethernet link to the end node. Communicate with data frames. According to one embodiment of the present invention, one way to increase the maximum frame size is to intercept node response frames that are redirected to the node's login and management processor 250. The management processor 250 adjusts the buffer-to-buffer received data field size in the frame as needed, and then routes the modified packet to its original destination.
[0038]
Following the fabric login, the device logs into the name server 65. When the user logs in to the name server 65, a parameter (for example, a maximum payload size) used for communication between the device and the name server 65 is established. A device "register" with name server 65 provides information to a database, which describes the parameters of the device on the network. The initiator may then query a database to determine information about the devices in the system, thereby eliminating the need to "probe" the system to determine which devices are present. Network probing is not feasible due to 160,000 Fiber Channel addresses. The name server 65 is preferably a node attached to the network, but can be implemented in a switch and distributed across the fabric to ensure redundancy and fast access.
[0039]
FIG. 7 is a flowchart illustrating an example of “session” initialization of a Fiber Channel device connected to a SIP network according to an embodiment of the present invention. During fabric login, switch 235 assigns an IP address from the block of IP addresses assigned to switch 235 to the device.
[0040]
The switch 235 uses the IP address assigned to the FC device when the packet is delivered to or received from an IP compatible port. The FC device now has two addresses assigned by the SoIP network: FC address and IP address. FC addresses are used when FC devices communicate over a local Fiber Channel "island", while IP addresses are used when devices communicate over an IP network.
[0041]
8 and 9 show data frames of a login of a node starting with FC port A of switch 1 and logging up to FC port B of switch 2 provided away from switch 1 according to an embodiment of the present invention. Show the flow. The data frame of the login request is redirected to the management processor of the switch 1 by the FC port A. The management processor makes any changes required in the buffer-to-buffer receive data field size parameter, and then forwards the packet to the original destination port. In the destination switch (switch 2), there is no redirect of the packet of the login request. As shown in FIG. 9, the login response frame from the FC port B is redirected to the management processor of the switch 2. The management processor changes the buffer-to-buffer receive data field size in the response if necessary.
[0042]
In one embodiment, each management processor adjusts its buffer-to-buffer receive data field size to a value that allows the FCP data frame to fit within an IP packet. IP packets can be transmitted over an Ethernet network without fragmentation. Accordingly, each management processor may need to perform a search for an MTU (Maximum Transmission Unit) to determine a size that does not cause fragmentation of IP packets in the network.
[0043]
If the FC port performs a port login using a local (ie, connected to the same switch) FC port, there is no need to change the buffer-to-buffer receive data field size of the login request or response. This is because, in one embodiment, the switch supports the maximum frame size transferred between FC ports (on the same switch). However, the interface logic of the FC port always redirects the port login packet to the management processor of the switch, simplifying the interface logic of the port. Thus, in this embodiment, the switch looks and operates like an FC switch from the perspective of any FC device connected to the switch. FIG. 10 shows an example of the routing of the request frame and the response frame of the login of the port of the local FC port.
[0044]
According to one embodiment, routing the FC port login request / response packet to the management processor allows the SCSI port login to be handled by the management processor. The management processor always handles SCSI logins.
[0045]
According to one embodiment, a SoIP device is uniquely identified using two parameters: an IP address and a SoIP socket number. Thus, one device can have a unique IP address, or multiple devices can share one IP address. For example, all devices on the arbitrated loop of the Fiber Channel may share an IP address, and the server's host bus adapter may have a dedicated IP address. In one embodiment, there are two possible modes for assigning a SIP socket number: local or global.
[0046]
One SoIP device directly connected to the IP network needs to have a unique IP address so that the network can route data frames to the device. IP networks do not route traffic based on SIP socket numbers. However, if the switch uses both the IP address and the SoIP socket number when switching data frames, devices connected to the switch (eg, switch 235) may share the IP address.
[0047]
In accordance with the present invention, a SOIP network SAN with "legacy" Fiber Channel devices attached has different address domains because two different addressing methods are used: IP and Fiber Channel. FIG. 11 illustrates an example of an address domain existing in a network according to an embodiment of the present invention. A SoIP device communicates using an IP address and a SoIP socket number, and a Fiber Channel device (a SCSI device is treated as a Fiber Channel device by a switch) uses a Fiber Channel address. Each switch 235 performs address translation between the IP address domain and the Fiber Channel address domain. Switch 235 ₁ Performs address translation between the IP address domain and FC address domain 1 and switches 235 ₂ Performs address translation between the IP address domain and the FC address domain 2. Each switch 235 allocates an IP address, a SoIP socket number, and a Fiber Channel address to each Fiber Channel device when the device performs fabric login. The Fiber Channel device only gets information about its assigned Fiber Channel address. The assigned IP address, SoIP socket number and Fiber Channel address are maintained in a translation table (not shown) in the switch. Parallel SCSI devices are assigned respective addresses by the switch during SCSI port initialization. The Fiber Channel port directs all name server requests by the Fiber Channel device to the management processor for processing.
[0048]
According to one embodiment of the invention, the management processor translates the Fiber Channel name server request into a SoP name server request, which is then forwarded to the SoIP name server (e.g., implemented on server 280). . In one embodiment, the functionality of the SoIP name server is decentralized, and is therefore handled directly by the management processor. The response from the name server is returned to the management processor, where the response is converted to a fiber channel name server response before being forwarded to the port that created the name server request. When a Fiber Channel device sends a data frame to a device that is not located within the Fiber Channel address domain, the switch 235 converts the packet to a SoIP compatible packet. As mentioned above, the transformation encapsulates the FCP data frame within the IP data frame. Referring back to FIG. 6a, in one embodiment, the IP address and the SoIP socket number are used to translate the Fiber Channel source address (S_ID) and destination address (D_ID) into an IP / Fibre Channel address translation table on a name server. It is obtained by using it as a "key." The Fiber Channel address field is replaced by the SoIP socket number when converting a Fiber Channel data frame to a SoIP data frame. The packet is then conveyed over the IP network and routed using the destination IP address. If the destination device is a SoIP compatible device, the packet is processed directly by the destination device (ie, de-encapsulated and processed as an FCP packet). However, if the destination is a Fiber Channel (or parallel SCSI) device, the packet is routed to switch 235. Switch 235 receives the packet, performs decapsulation of the SoIP packet, and replaces the SoIP socket number with the appropriate source and destination Fiber Channel addresses based on the source and destination IP addresses and the SoIP socket number.
[0049]
According to one embodiment, local assignment is the preferred method of assigning a SoIP socket number. In this embodiment, the unique SOIP device selects its own SOIP socket number, while the SoIP switch (eg, switch 235) assigns the SOIP socket number to the Fiber Channel and SCSI devices attached to the switch. If the SoIP socket number is assigned locally, the selected value can be any value that results in a unique IP address / SoIP socket number combination. Devices that share an IP address are assigned a unique SoIP socket number and need to create a unique IP address / SoIP socket number pair. A device with a unique IP address may have any desired SoIP socket number. In one embodiment, the SoIP switch assigns a SoIP socket number to simplify the routing of received data frames. The switch also needs to be able to assign a locally significant Fiber Channel address to each "remote" device used by the local device in addressing the "remote" device. These locally assigned addresses are known only by switches in the Fiber Channel address domain. Thus, each switch maintains a set of locally assigned Fiber Channel addresses, which correspond to globally known IP address / SoIP port number pairs defined in the SoIP name server.
[0050]
According to one embodiment, due to the different address domains, each switch 235 intercepts Fiber Channel Extended Link Service requests and responses that have Fiber Channel address information embedded in the payload. Extended link service requests and responses are generated only occasionally. Therefore, it is preferable to redirect the request for the extended link service to the management processor of the switch making any necessary changes to the data frame. If the extended link service request / response does not have the addressing information embedded in the payload, the management processor simply retransmits the packet without modification.
[0051]
The IP address and the SoIP socket number assigned to the Fiber Channel or SCSI device are determined by the switch. The assignment of these addresses is up to you. In a preferred embodiment, the SoIP socket number is assigned a device local Fiber Channel address. In this embodiment, the switch obtains the local Fiber Channel address directly from the received data frame. Alternatively, the assignment of the SoIP socket number is based on an increasing number that can be used as an index into the address table.
[0052]
In one embodiment, a unique IP address is assigned to each device. However, making this type of assignment can result in the use of multiple IP addresses. Using a single IP address for each device results in multiple routing implications within the IP network. Therefore, in a preferred embodiment, the assignment to the IP address is performed such that at least one subset of the devices attached to one switch shares one IP address. For example, one IP address can be assigned to each switch port. Thereafter, each device assigned to that switch port shares the IP address of that port. Therefore, the attached Fiber Channel N_Port has one uniquely determined IP address, while the devices on the Fiber Channel arbitration loop attached to the Fiber Channel N_Port share one IP address.
[0053]
According to one embodiment, Fiber Channel addresses are assigned globally. Globally assigning Fiber Channel addresses can maximize suitability for "legacy" Fiber Channel devices. In this embodiment, the SoIP name server is responsible for managing the allocation of global fiber channel addresses. In some cases, Fiber Channel addresses may be embedded within "third-party" SCSI commands, so it may be necessary to support the global Fiber Channel address space. An example of such a third party command is COPY. This COPY command instructs another device to copy the data. "Third-party" commands are rarely used, but if "third-party" commands are used, the commands need to be modified for address compatibility or Fiber Channel addresses must be assigned globally Comes out.
[0054]
With reference to the SoIP network shown in FIG. 12a, an example third-party COPY command will be used to describe the locally assigned Fiber Channel addresses and the problems encountered with third-party commands. In this embodiment, the locally assigned Fiber Channel address is also used as the SoIP socket number. In this embodiment, each device has a uniquely determined IP address.
[0055]
FIG. 12b shows the IP address and the SIP socket number that each device has announced to the name server. The name server identifies the manner in which devices are addressed in the SoIP network. Each device is identified in a manner uniquely determined by a combination of the IP address and the SoIP socket number. Switch 235 ₃ And 235 ₄ Assume that the tape library C recognizes each device in the system. In this case, the tape library C has the same address table as the address table of the name server. Switch 235 ₃ And 235 ₄ Assigns a local fiber channel address to each device. FIG. 12c shows the switch 235 ₃ 12d shows the address table stored in the switch 235. ₄ Shows an address table stored in the address table. Since the assignment of Fiber Channel addresses is performed locally, the address assignment is completely arbitrarily performed.
[0056]
The server A in the local domain 1 issues a COPY command to copy data from the RAID drive B to the tape library B (both of which are arbitrarily located in the local domain 3). Suppose to send to B. This COPY command includes the address viewed from the server A side. Therefore, referring to FIG. 12c, the command received by server B is a COPY from fiber channel device 000500 (RAID drive B) to fiber channel device 000600 (tape library B). However, server B does not ₄ The COPY command is interpreted using the address table shown in FIG. 12D, the data from the RAID drive A should be considered to be copied to the tape library A, and the data from the RAID drive B should be copied to the tape library B. Assume not. Therefore, an erroneous operation is performed. As another example, assume that server B sends a command to server A that data from RAID drive A should be copied to tape library C. This command is for the Fiber Channel addresses 000500 to 009900 (these addresses are ₄ (The address is viewed from the side). Switch 235 ₄ Does not exist in the address table, the server A regards this command as instructing to copy data from the RAID drive B to a non-existent device.
[0057]
According to one embodiment, the switch avoids this problem by intercepting each third-party command and changing the embedded Fiber Channel address to be compatible with the destination device. However, in order to perform the above-mentioned interception and modification, the assignment state of the local address in the destination switch must be known to the source switch. Although it is possible for the switch to translate third-party commands, other methods are preferred.
[0058]
According to another method, a Fiber Channel address is globally assigned for a device referenced by a Fiber Channel address in a third party command. Global use of Fiber Channel addresses allows third party commands to be used without modification, but the total number of devices possible in a SoIP network and the maximum number of devices as a Fiber Channel network are the same. Become. Although it is possible to globally assign addresses to all devices in a SoIP network, only devices referred to as third party commands need global addresses.
[0059]
The globally assigned Fiber Channel address is preferably used as the device's SIP socket number. As a result, the task of converting "legacy" Fiber Channel data frames to data frames that are compatible with SoIP is simplified. Therefore, the task of globally assigning Fiber Channel addresses corresponds to the task of globally assigning SoIP socket numbers.
[0060]
The task of globally assigning a SoIP socket number is managed by a SoIP name server. This SoIP name server allocates global SoIP socket numbers as requested from the pool of free socket numbers, and deallocates those socket numbers if they are no longer used (ie, deallocates the socket numbers). Return to free pool). The method of allocating a global SoIP socket number for all devices in a SoIP network can be performed without specifying a subset of devices that require a global SoIP socket number (or a device that can use a local SoIP socket number). Good and the easiest solution from a management point of view.
[0061]
Therefore, all devices in the SoIP network assign a SoIP socket number locally or assign a SoIP socket number globally. All devices and switches that are compliant with SoIP support both of the above modes. When logging in to the network, each device or switch determines a mode to be supported from the SoIP name server. The configuration parameter of the SoIP name server indicates an allocation mode of the SoIP socket number.
[0062]
An environment that supports both local and global SoIP socket numbers because a new form of third-party command format that embeds World Wide Names in commands instead of Fiber Channel addresses eliminates the need for global SoIP socket numbers. Is unnecessary. Since the world wide name is uniquely determined, the device receiving the command can determine an appropriate address or addresses from its own point of view. One implementation of this new third-party command is the EXTENDED COPY command. The native SoIP device preferably uses a version of a third party command that embeds the world wide name in the command when the SoIP socket number is assigned locally.
[0063]
In one embodiment, when globally assigning a SoIP socket number, the requestor indicates the minimum number of requested socket numbers and a 24-bit mask that defines the boundary. For example, a 16-port switch requests a socket number of 4096 and a bitmask of FFF000 (hex) to indicate that these socket numbers should be assigned to the boundary where the lower 12 bits are zero. . The switch then assigns a 256 socket number to each port (for arbitrated loop support). Assigning a socket number on a specified boundary allows the switch to assign a socket number that directly correlates to the port number. In the above example, bits 11: 8 identify the port. Preferably, a native SoIP device assigns only one global SoIP socket number from a SoIP name server.
[0064]
In one embodiment, the SoIP name server also includes a configuration parameter that selects a "maximum fiber channel compatibility" mode. This "maximum fiber channel compatibility" mode only has meaning for the global assignment of the SoIP socket numbers. The device can query the name server for the value of this parameter. This mode, when enabled, specifies that a global SoIP socket number should be assigned to the switch in 65536 blocks (on the 65536 boundary). This mode is compatible with the existing Fiber Channel mode address allocation (identifying the device by the lower 8 bits, identifying the port by the middle 8 bits, and identifying the switch by the upper 8 bits). The SoIP switch recognizes this mode and, when enabled, requests a 65536 socket number when requesting a global SoIP socket number. In this mode, the native SoP device preferably allocates only one global SoP socket number from the SoP name server.
[0065]
According to one embodiment, when operating in a layer 2 network (eg, without an IP router), the frame format is changed to simplify the encapsulation logic. No IP header or UDP header is required for layer 2 networks. All frames are transferred using physical addresses (eg, Ethernet MAC addresses). The switch then internally routes the frame based on a combination of the layer 2 physical address (eg, Ethernet MAC address) and the SIP socket number. In effect, the physical address of layer 2 replaces the IP address as a parameter in a manner that identifies the SoIP device in a uniquely defined manner. FIG. 13 shows a frame format for an FCP frame transmitted on Ethernet (R). An Ethernet type value 290 is uniquely defined for SoIP so that stations receiving the frame can distinguish the frame from other frame types (eg, IP). Eliminate IP and UDP headers to reduce frame overhead. The advantage gained by this is that the length and checksum fields in the UDP header do not have to be generated. Generating the IP and UDP headers further increases the latency of frame transmission because the length and checksum are placed at the beginning of the frame. Therefore, it is necessary to buffer the entire frame, determine the length and checksum, and write the determined length and checksum into the header. In the case of the Ethernet (R) layer 2 SoIP frame, if there is padding to be added at the end of the frame, it is only necessary to determine the amount of padding. Since the number of PAD bytes must be included in the SoIP header, the PAD bytes can be removed at the receiving station. Padding is only required to satisfy the minimum size of a 64-byte Ethernet frame, so header generation can be completed after a 64-byte frame (or the entire frame) is received. It is.
[0066]
The layer 2 frame format is similar to the Layer 3 frame format SoIP frame conversion described above with reference to FIG. 6, and they differ in the following respects:
a. IP header and UDP header no longer exist.
[0067]
b. Ethernet (R) type values are different.
[0068]
c. Use the FC CRC field instead of the CHEKSUM PAD field. The FC CRC field is a 4-byte field and contains the Fiber Channel CRC calculated on the FCP header and payload. This field can be inserted by the source if the encapsulation of the Fiber Channel data frame is done without change. Therefore, the CRC received with the frame is still valid.
[0069]
d. The FC_CRCPRESENT flag is used instead of the CHECKSUM PAD flag. This bit indicates the presence or absence of the FC CRC field in the frame. Note that this CHECKSUM PAD field has no meaning since it is not necessary to calculate the UDP checksum.
[0070]
e. FRAME PAD LENGTH may have a non-zero value since the encapsulated frame length may be less than a minimum of 64 Ethernet (R).
[0071]
The UDP header includes a destination port field and a source port field. A common use of these fields is to identify which software applications are interacting. The application requests a port number to be used when sending UDP "datagrams". This port number will be the source port number for each UDP datagram sent by the application. When a UDP datagram is received, the UDP layer uses the destination port number to determine an application to which the datagram is forwarded. FIG. 14a shows the "demultiplexing" of a UDP datagram frequently used in the art.
[0072]
14b and 14c illustrate a method for adding a SoIP layer according to an embodiment of the present invention. FIG. 14b shows the demultiplexing of a frame when there is only one single port number assigned to all SoIP devices. Thereafter, demultiplexing is further performed using the SoIP socket number, and a device is determined. Thereafter, a routing data frame is performed for the application based on the FCP exchange number arranged in the FCP header. FIG. 14c shows a diagram similar to the above but with the UDP port numbers assigned to the SoIP devices being distinct numbers. In this case, there is no need to check the SoIP socket number to transfer the UDP datagram. (SoIP socket numbers and IP addresses still identify the device in a uniquely defined manner). The choice between using a single UDP port number for each SoIP device or one UDP port number for all devices is implementation dependent.
[0073]
The example of demultiplexing UDP shown in FIGS. 14b and 14c is directed to a server with one or more host bus adapters, where these host bus adapters are SoIP devices. Switches often have low complexity in that they forward data frames to end devices and do not need to process the application layer.
[0074]
Using the above addressing mechanism, it is possible to make a software application appear as a SoIP device by registering the software application with a name server using a different address. As a result, a possibility is opened for an application to advertise in a name server that the application will be used by another application. One example is a COPY manager that can be used by higher-level backup applications.
[0075]
According to one embodiment, when registering with the name server, each storage device must include a UDP port number used to send data frames to the device. In a normal UDP application, the destination port stores the source port number used when sending a reply. However, this mechanism is not feasible when used with "legacy" FC switches, as it requires a switch to correlate the source port number with the exchange ID. It is much easier to require the storage device to always use the same UDP port number.
[0076]
As a result, according to this embodiment, the storage device is identified by three parameters in the name server database (ie, IP address, UDP port number, and SoIP socket number). Further required parameters are physical addresses (eg, Ethernet MAC addresses) that are determined in the usual manner for IP networks. ARP (Address Resolution Protocol) is preferably used to know the physical address used for the IP address. The physical address used is also recognizable when a frame is received from the device. For example, when a request for port login is received, the physical address can be known. This physical address is not the physical address of the implementing device, but of the implementing device of the IP router.
[0077]
The SoIP name server (SNS) must have a UDP port number recognized by all SoIP devices in the SoIP network. The reason is that the port number is not known from another source. This can be a "well-known" port number or a registered port number. This approach is similar to a domain name server (DNS) with the well-known port number 53. The assignment of "well-known" port numbers is performed by IANA (Internet Assigned Numbers Authority).
[0078]
Routing within an IP network is affected by the result of selecting an addressing mode, which in turn affects the ability of switches and routers to determine the "talk" composition. A conversation is a series of related and sequentially arriving data frames. However, it is assumed that the conversations do not have an ordered relationship. In other words, the ordering of frames from different conversations can be changed without any effect. For example, assume that frames for three conversations (A, B, and C) are transmitted in the following order (A1 is sent first):
[0079]
(Equation 1)

The frame can be received in any of the following sequences (note that there are many other acceptable sequences):
[0080]
(Equation 2)

In each of the above sequences, frames for a particular conversation arrive out of order with each other, while frames from other conversations arrive out of order with each other. The ability to identify different conversations allows for load balancing by allowing traffic to be routed on a conversation basis. Switches and routers can determine the conversation based on multiple parameters in the data frame (eg, destination / source address, IP protocol, UDP / TCP port number, etc.). The parameters actually used depend on the switch / router implementation.
[0081]
Storage traffic between the same two devices must be treated as a single conversation. Receiving storage commands out of order is unacceptable because relationships may exist between storage commands (eg, queue ordering). Therefore, it is preferable to select an addressing mechanism that provides a device that is uniquely determined for the switch / router and does not attempt to distinguish commands. Since this method worked with all switches and routers, choosing a different IP address is best for distinguishing devices. When the IP address is shared, it is preferable that the UDP port number is uniquely determined for the device sharing the IP address. Therefore, devices sharing an IP address may be handled separately by switches and routers that classify conversations based on UDP port numbers. It will be understood that the above discussion of UDP port numbers applies to TCP header port numbers when SoIPSo is implemented using TCP instead of UDP.
[0082]
FIG. 15 is a high-level block diagram illustrating the basic architecture of a switch port that supports both Fiber Channel and Gigabit Ethernet in accordance with embodiments of the present invention. The encoding / decoding method (8B / 10B) used by the Fiber Channel and Gigabit Ethernet (R) ports is the same, and each port has a serializer / deserializer (SERDES) block for performing conversion with a high-speed serial interface. Is required. Thus, in this embodiment, these two interfaces share an 8B / 10B block 310 and a SERDES block 315 as shown in FIG. These two interface types differ in clock speed when Fiber Channel operates at 1062.5 MHz and Gigabit Ethernet operates at 1250 MHz. High speed versions of these interfaces are also under development and have different clock speeds. Thus, multiplexer 345 selects the clock used by the logic based on the port type. Further, these two interfaces share a switch fabric interface logic block 320 that interfaces with the switch fabric (including the management interface). The MAC blocks (blocks 325 and 330) implement the appropriate protocol state machine for the interface (Fibre Channel or Gigabit Ethernet). MAC blocks 325 and 330 convert the received data into frames, and the converted frames are forwarded to routing logic blocks 335 and 340, respectively. MAC blocks 325 and 330 also receive data frames from routing logic blocks 335 and 340, respectively, after which these data frames are transmitted depending on the interface's (Fibre Channel or Gigabit Ethernet) protocol. . Routing logic blocks 335 and 340 determine the destination of each received frame based on the addressing information in the frame. Routing logic blocks 335 and 340 also make any necessary changes to the frame. For example, the routing logic block removes the SoIP encapsulation from the frame being forwarded to the Fiber Channel port. Thereafter, the routing logic block sends the frame to the switch fabric with an indication of the destination output port. Egress data frames (frames from the switch fabric to the output port) are received by the routing logic block and forwarded to the associated MAC. Before the MAC receives the frame, the frame may be further processed by the routing logic block. For example, the Ethernet (R) port routing logic block 340 may convert a Fiber Channel frame into a SoIP frame.
[0083]
According to another embodiment of the invention shown in FIG. 16, the two routing blocks of FIG. 15 are combined into a single routing logic block 350. Such optimization is possible because the routing logic used by these two interfaces is very similar. In one embodiment, the routing logic block 350 includes a logic block that depends on the port type and other blocks that are common to both port types. This optimization reduces the number of logic gates needed on the ASIC. The routing block 350 determines the destination of the frame based on the addressing information in the data frame. This function is known as address resolution and is performed on both Fiber Channel and Gigabit Ethernet data frames. Thus, although different data must be selected based on the port type during the routing logic, the address resolution logic can be shared by these two port interfaces. The logic in routing logic block 350 can be implemented as hard-coded logic, or it can be implemented in a programmable manner using a network processor (this method is designed specifically for packet processing and can be implemented in a Fiber Channel frame or Ethernet (R) ) Can be programmed to route any of the frames). Thus, routing logic hardware can be shared by using different network processor software. In one embodiment, routing logic block 350 also includes an input / output FIFO memory shared by the two port interfaces. Additional logic that can be shared includes statistics registers and control registers. The statistics register is used to count the number of received frames, transmitted frames, received bytes, transmitted bytes, and the like. It is possible to use a common set of statistics registers. These registers are changed by control signals from each MAC. The control register determines the operation mode of each MAC. A common set of statistics and control registers reduces the logic required to implement the registers and interface with external control sources (eg, a switch management CPU).
[0084]
In another embodiment, as shown in FIG. 17, low level port interface logic (eg, FC MAC block 325 and Ethernet MAC block 330) is combined into a single MAC block 360. However, this approach has a problem that there is little commonality between these two logical blocks. In addition, it is possible to purchase a proprietary block that implements Gigabit Ethernet MAC and Fiber Channel port interface logic. Combining these two blocks would severely hinder the use of these owned blocks.
[0085]
According to another embodiment of the present invention shown in FIG. 18, a field programmable gate array (FPGA) 370 is used to select an interface protocol supported by the port. The configuration of the FPGA to be loaded is based on the support type. In this embodiment, separate FPGA codes are deployed for the Fiber Channel interface and the Gigabit Ethernet interface. Thus, the FPGA logic can be optimized for a particular interface. A single hardware design supports both interfaces, and software decides to download FPGA code based on port type.
[0086]
The common port must also handle physical interfaces external to the ASIC. As is well known, such interfaces include, for example, copper, multimode fiber interfaces or single mode fiber interfaces. Also, these components need not be identical between Fiber Channel and Ethernet. According to the embodiment of the present invention shown in FIG. 19, a gigabit interface converter (GBIC) 380 is provided to allow a user to select a desired physical interface. The GBIC is a standardized module with common features and electrical interfaces, allowing any of the many physical interfaces described above to be installed. GBIC modules are commercially available from a number of suppliers (eg, HP, AMP, Molex, etc.) and support all standard Fiber Channel and Gigabit Ethernet physical interfaces. FIG. 14 shows a block diagram of how a common FC / Gigabit Ethernet port interface (eg, as shown in FIGS. 15, 16, 17 and 18) is combined with a GBIC interface according to this embodiment. The ASIC connects to a GBIC connector 385 that allows the user to change the GBIC module. Therefore, the user can select a media type by attaching an appropriate GBIC 380.
[0087]
The GBIC module typically includes a serial EEPROM and reads the contents of the serial EEPROM to determine the module type (eg, Fiber Channel, Gigabit Ethernet, InfiniBand, Copper, Multi-mode, Single-mode, etc.). Can be determined. Thus, the GBIC can indicate the type of interface used (eg, FC or GE or InfiniBand). However, it is also possible for the GBIC to support multiple interfaces (eg, both FC and GE). Thus, in one embodiment, the port interface type is switchable / configurable by the user, and in another embodiment, the type of the link interface is automatically determined through additional intelligence (eg, "handshake").
[0088]
According to another embodiment of the present invention, a SIP intelligent network interface card (NIC) 400 is provided as shown in FIG. The NIC card 400 can send and receive both IP traffic and SoIP traffic. In any case, the NIC card 400 has the intelligence to determine the type of traffic and direct that traffic according to the determination.
[0089]
The host 410 can issue a storage command and a network command to the NIC card 400 through the PCI interface 420. These commands are sent with the designated address used in directing the commands to either the direct path or the storage traffic engine. Storage commands are issued via the SCSI command set, and network commands are issued via Winsock and / or TCP / IP.
[0090]
The NIC card 400 directs the storage command to the storage traffic engine 430 based on the specified address. The storage traffic engine 430 handles management of exchanges and sequence management during operation of the SCSI. Thereafter, SCSI operations are performed over the SoIP and transmitted to the network 470 via a media access controller (MAC) block 450 (which in one embodiment is a Gigabit Ethernet MAC). NIC card 400 directs non-SoIP traffic directly to path 440 based on the designated address. The direct path 440 processes these commands and sends the designated packet to the network 470 via block 450. When receiving data from network 470 via MAC 450, NIC 400 demultiplexes the traffic and directs the demultiplexed traffic accordingly. Storage traffic received as SoIP is sent to the storage traffic block 430. Non-SoIP traffic is sent directly to the host via direct path 440.
[0091]
Multiplexer block 460 handles arbitration for the output path when both direct path 440 and storage traffic engine 430 have sent traffic at the same time to MAC 450. For traffic received from the network 470 to the MAC 450, the Mux block 460 demultiplexes the traffic and sends the traffic to either the direct path 440 or the storage traffic engine 430 depending on the demultiplex result.
[0092]
While the invention has been described by way of example and using particular embodiments, it is to be understood that the invention is not limited to these disclosed embodiments. On the contrary, as will be apparent to those skilled in the art, the invention is intended to include various modifications and similar arrangements. Therefore, the claims hereof should be interpreted to the fullest extent to encompass such modifications and similar arrangements.
[Brief description of the drawings]
FIG.
FIG. 1 shows an example of a SAN constructed according to the present invention.
FIG. 2
FIG. 2 is a schematic block diagram of a storage realized on the Internet Protocol (SoIP).
FIG. 3
FIG. 3 illustrates the steps of the necessary protocol conversion between the Fiber Channel, SCSI and IP devices in the device and the switch fabric, according to one embodiment of the present invention.
FIG. 4
FIG. 4 is a schematic diagram of a legacy storage protocol conversion method that achieves the functions of the present invention.
FIG. 5
FIG. 5 is a high-level switch diagram outlining the basic architecture of a physical device, according to one embodiment of the present invention.
FIG. 6a
FIG. 6a illustrates FCP packet encapsulation, according to one embodiment of the present invention.
FIG. 6b
FIG. 6b illustrates the encapsulation of FCP packets according to one embodiment of the present invention.
FIG. 6c
FIG. 6c illustrates FCP packet encapsulation, according to one embodiment of the present invention.
FIG. 7
FIG. 7 shows the flow of a “session” initialization frame of a Fiber Channel device connected to a SoIP network.
FIG. 8
FIG. 8 illustrates a data frame flow for a node login starting at FC port A of switch 1 and ending at FC port B of switch 2 located remotely, according to one embodiment of the present invention.
FIG. 9
FIG. 9 illustrates a data frame flow for a node login starting at FC port A of switch 1 and ending at FC port B of switch 2 located remotely, according to one embodiment of the present invention.
FIG. 10
FIG. 10 illustrates the routing of request and response frames for port login of a local FC port according to one embodiment of the present invention.
FIG. 11
FIG. 11 illustrates an example of an address domain existing in a network according to an embodiment of the present invention.
FIG. 12a
FIG. 12a shows the network architecture and address table of a third-party example command.
FIG. 12b
FIG. 12b shows the network architecture and address table of a third-party example command.
FIG. 12c
FIG. 12c shows the network architecture and address table of a third-party example command.
FIG. 12d
FIG. 12d shows the network architecture and address table of a third-party example command.
FIG. 13
FIG. 13 illustrates layer 2 FCP packet encapsulation according to one embodiment of the present invention.
FIG. 14a
FIG. 14a illustrates an example of demultiplexing a UDP frame according to an embodiment of the present invention.
FIG. 14b
FIG. 14b illustrates an example of demultiplexing a UDP frame according to an embodiment of the present invention.
FIG. 14c
FIG. 14c shows an example of demultiplexing of a UDP frame according to an embodiment of the present invention.
FIG.
FIG. 15 is a high-level block diagram illustrating the basic architecture of a switch port that supports both Fiber Channel and Ethernet in accordance with one embodiment of the present invention.
FIG.
FIG. 16 is a high-level block diagram illustrating the basic architecture of a switch port that supports both Fiber Channel and Ethernet, according to one embodiment of the present invention, where two routing blocks are combined into one block. Have been.
FIG.
FIG. 17 is a high-level block diagram illustrating the basic architecture of a switch port that supports both Fiber Channel and Ethernet in accordance with one embodiment of the present invention, where the low-level port interface logic blocks are combined. Have been.
FIG.
FIG. 18 illustrates a basic architecture of a switch port supporting both Fiber Channel and Ethernet using a Field Programmable Gate Array (FPGA), according to one embodiment of the present invention. It is a high level block diagram.
FIG.
FIG. 19 shows a block diagram of a common FC / Gigabit Ethernet port combined with a GBIC interface, according to one embodiment of the present invention.
FIG.
FIG. 20 illustrates the architecture of an intelligent network interface card (NIC) according to one embodiment of the present invention.

Claims

A method for routing data packets in a switching device in a network, comprising:
Receiving a packet from a first network device at a first port interface of the switch device, wherein the packet is a SCSI formatted packet, a Fiber Channel (FC) formatted packet, and Any of Internet Protocol (IP) formatted packets, wherein the first port interface is communicatively coupled to the first network device;
Converting the received packet into a packet having an internal format;
Routing the packet in the internal format to a second port interface of the switch device;
Re-converting the internal format packet into one of a SCSI formatted packet, an FC formatted packet and an IP formatted packet;
Transmitting the reconverted packet to a second network device communicatively coupled to the second port interface;
A method comprising:

The method of claim 1, wherein the IP formatted packets are transferred via any of Ethernet® and ATM protocols and FDDI protocols.

The second port interface couples the switch device to a network, and the transmitting comprises sending the reconverted packet to the second network device over the network. The method of claim 1, wherein the translated packet is in the IP format.

The network is an Ethernet network, the IP format is an Ethernet format, and the step of re-converting includes encapsulating the internal format packet in an Ethernet frame. The method of claim 3.

The first port interface couples the switch device to a network, wherein the receiving step receives a packet from the first network device over the network, wherein the received packet is in the IP format. . The method of claim 1.

The method according to claim 5, wherein the network is an Ethernet network and the IP format is an Ethernet format.

The method of claim 1, wherein the retransformed packet is in a different format than the received packet.

The method according to claim 1, wherein the first network device is one of a server and a storage device, and the second network device is one of a server and a storage device.

The method of claim 1, wherein the internal format is an FCP-based format.

a) means for receiving a data packet from a network device, wherein the data packet is received from a first network device from one of a SCSI formatted packet and a Fiber Channel (FC) formatted packet; Means,
Means for converting a received packet to a packet having an internal format, wherein the received data packet is converted to a first packet having the internal format;
A first port interface comprising:
b) means for reconverting a packet from the internal format to an IP format, wherein the first packet is converted to a packet with an IP format;
Means for transmitting an IP packet to a network, wherein the packet formatted in the IP scheme is transmitted to an IP network;
A second port interface comprising:
c) means for routing the first packet to the second port interface;
A network switch device comprising:

The switch device according to claim 10, wherein the IP network is an Ethernet network, and the packet formatted in the IP scheme is encapsulated in an Ethernet frame.

The switch device according to claim 10, wherein the internal format is an FCP-based format.

a) means for receiving a data packet from an IP network, wherein the first interface means receives a packet in IP format;
Means for converting a received packet to a packet having an internal format, wherein the received packet is converted to a first packet having an internal format;
A first port interface comprising:
b) means for reconverting the packet having the internal format into a packet with a SCSI format;
Means for transmitting the retranslated packet to a SCSI network device;
A second port interface comprising:
c) means for re-converting the packet having the internal format into a packet with an FC format;
Means for transmitting the reconverted packet to the FC network device;
A third port interface comprising:
d) means for routing a packet between a first port interface, a second port interface, and a third port interface, wherein the first packet comprises the second port interface and the second port interface. Means routed to any of the three port interfaces;
With
When the first packet is routed to the second port interface, the first packet is converted to the SCSI format and sent to the SCSI network device, and the first packet is transmitted to the third port. When routed to an interface, the first packet is converted to the FC format and sent to the FC network device.
Network switch device.

14. The switch device according to claim 13, wherein the IP network is an Ethernet network, and wherein the IP format is an Ethernet format.

14. The switch device according to claim 13, wherein the internal format is one of an FCP-based format and an IP format.

A SCSI device capable of receiving and transmitting data packets formatted in a SCSI format;
An FC device capable of receiving and transmitting data packets formatted by a Fiber Channel (FC) method;
An IP device capable of receiving and transmitting data packets formatted in the IP system;
A switch device,
A first port interface communicably coupled to the SCSI device, wherein the first port interface converts a SCSI formatted data packet received from the SCSI device into a data packet having an internal format, and converts the internal format to A first port interface for converting a data packet having the data packet into a data packet formatted in a SCSI system;
A second port interface communicably coupled to the FC device, wherein the second port interface converts a data packet formatted in the FC format received from the FC device into a data packet having the internal format, A second port interface for converting a data packet having the following into a data packet formatted in the FC system;
A third port interface communicatively coupled to the IP device, wherein the third port interface converts a data packet formatted in the IP format received from the IP device into a data packet having the internal format, A third port interface for converting a data packet having the following into a data packet formatted in the IP system;
A switch fabric for routing data packets having the internal format between the first port interface and the second port interface and the third port interface;
A switch device comprising:
With
When the first device of the SCSI device, the FC device and the IP device sends a first data packet to the second device of the SCSI device, the FC device and the IP device, the first data packet is transmitted to the first device. A port interface coupled to the first device converts the first data packet to a packet having the internal format and routes the internal format packet to the port interface coupled to the second device through the switch fabric. And a port interface coupled to the second device reconverts the packet in the internal format to a format associated with the second device and sends the reconverted packet to the second device. ,
Storage Area Network (SAN).

The data packet formatted by the IP system is a data packet formatted by the Ethernet (R) system, a data packet formatted by the ATM system, a data packet formatted by the FDDI system, and a data packet formatted by the FDDI system. 17. The SAN of claim 16, wherein the SAN comprises any of the following data packets.

17. The SAN of claim 16, wherein the internal format is an FCP-based format.

17. The SAN of claim 16, further comprising an IP network coupling the IP device to the third port interface.

A first port interface communicatively coupled to a SCSI device, wherein the first port interface converts a SCSI formatted data packet received from the SCSI device into a data packet having an internal format, and having the internal format. A first port interface for converting a data packet into a SCSI formatted data packet;
A second port interface communicably coupled to the FC device, wherein the second port interface converts a data packet formatted in the FC format received from the FC device into a data packet having the internal format, and A second port interface for converting the data packet having the data packet into a data packet formatted in the FC system;
A third port interface communicably coupled to the IP device, wherein the third port interface converts a data packet formatted in the IP format received from the IP device into a data packet having the internal format, and A third port interface for converting the data packet having the data packet into a data packet formatted in the IP system;
A switch fabric for routing data packets having the internal format between the first port interface and the second port interface and the third port interface;
With
When the first device of the SCSI device, the FC device and the IP device sends a first data packet to the second device of the SCSI device, the FC device and the IP device, the first data packet is transmitted to the first device. A port interface coupled to the first device converts the first data packet to a packet having the internal format and routes the internal format packet to the port interface coupled to the second device through the switch fabric. And a port interface coupled to the second device reconverts the packet in the internal format to a format associated with the second device and sends the reconverted packet to the second device. ,
A network switch device used in a storage area network (SAN).

The switch device according to claim 20, wherein the internal format is an FCP-based format.

17. The switch device according to claim 16, wherein said IP device is coupled to said third port interface by an IP network.

A first port interface communicatively coupled to one of a SCSI device, an FC device, and an IP device;
A second port interface that can be configured to communicate with either an FC device or an Ethernet device;
A switch fabric for routing data packets having the internal format between a first port interface and a second port interface;
With
If the second port interface is configured to communicate with an FC device, the second port interface converts the FC formatted data packet received from the FC device into a data packet having an internal format. Converting the second port interface converts the data packet having the internal format received from the switch fabric into a data packet formatted in an FC format, wherein the second port interface communicates with the Ethernet device. When configured to communicate, the second port interface converts an Ethernet-formatted data packet received from the Ethernet device into a data packet having the internal format. , The second port interface converts the data packet having the internal format received from the switch fabric formatted data packets on the Ethernet (R) system,
A network switch device used in a storage area network (SAN).

24. The switch device according to claim 23, wherein the second port interface is auto-configurable based on whether an FC device or an Ethernet device is coupled to the second port interface.

The switch device of claim 24, wherein the second port interface comprises means for determining whether the attached device is an FC device or an Ethernet device.

24. The switch device according to claim 23, wherein the second port interface is configured by a user to communicate with one of an FC device and an Ethernet device.

The switch device according to claim 23, wherein the internal format is an FCP format.