データ伝送システム
【課題】複数のデータ・フレーミング・プロトコルおよび／または複数のデータ伝送速度をサポートしうるデータ・フレーマを実現する。
【解決手段】送信元データ・ストリームに潜在する少なくとも２つの異なるデータ・フレーミング・プロトコルをサポートしうるデータ・フレーマは少なくとも２つのフレーミング回路および該フレーミング回路に接続されたコントローラを備えている。フレーミング回路の各々は前記各フレーミング回路に付随する異なるデータ・フレーミング・プロトコルに従って前記送信元データ・ストリームからユーザ・データを抽出するように構成されている。前記コントローラは適切に、(i) 前記送信元データ・ストリームを受信して少なくとも２つのデータ・フレーミング・プロトコルのうちのどちらが前記送信元データ・ストリームに対応しているかを自動的に判断し、(ii)前記送信元データ・ストリームの前記判断したデータ・フレーミング・プロトコルと前記第１のデータ・フレーミング・プロトコルおよび前記第２のデータ・フレーミング・プロトコルのうちの一方との間の一致に応答して、前記送信元データ・ストリームを前記第１のフレーミング回路および前記第２のフレーミング回路のうちの一方に転送する。
【解決手段】送信元データ・ストリームに潜在する少なくとも２つの異なるデータ・フレーミング・プロトコルをサポートしうるデータ・フレーマは少なくとも２つのフレーミング回路および該フレーミング回路に接続されたコントローラを備えている。フレーミング回路の各々は前記各フレーミング回路に付随する異なるデータ・フレーミング・プロトコルに従って前記送信元データ・ストリームからユーザ・データを抽出するように構成されている。前記コントローラは適切に、(i) 前記送信元データ・ストリームを受信して少なくとも２つのデータ・フレーミング・プロトコルのうちのどちらが前記送信元データ・ストリームに対応しているかを自動的に判断し、(ii)前記送信元データ・ストリームの前記判断したデータ・フレーミング・プロトコルと前記第１のデータ・フレーミング・プロトコルおよび前記第２のデータ・フレーミング・プロトコルのうちの一方との間の一致に応答して、前記送信元データ・ストリームを前記第１のフレーミング回路および前記第２のフレーミング回路のうちの一方に転送する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にデータ伝送システムに関し、特に少なくとも２つのデータ・フレーミング・プロトコルを自動的にサポートしうるデータ・フレーマに関する。
【背景技術】
【０００２】
よく知られていることだが、通信ネットワークを介して送信元と送信先との間で情報を転送するのに依拠するデータ通信プロトコルは通常、送信元と送信先との間でデータを同期させるためにフレーミング・アーキテクチャを用いている。データ・フレームは様々なセクション、たとえばメッセージ・セクションと当該メッセージ・セクションに付随する情報セクション（たとえばフレーミング・データ）とに分割することができる。情報セクションはたとえばフレーム境界を特定したり、通信ネットワーク経路を維持したりするために使用する。情報セクションは通常、データ・フレームのヘッダ部および／またはトレーラ部に存在する。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす。）データ通信プロトコルが異なると、通信ネットワークを介してデータを送信するのに異なるフレーム構成を使用する場合が多い。
【０００３】
データ・フレーマは一般にデータ伝送システムのデータ・リンク層で機能する装置である。システムの受信側で使用する場合、フレーマは入来するデータ・ストリームから事前設定のフォーマットまたはプロトコルのデータ・フレームを検索する。事前設定のプロトコルを用いてフレーム境界を特定したら、引き続く処理段において有効なユーザ・データをフレーム内で突き止める。送信側では、フレーマはユーザ・データを事前設定のプロトコルに対応するフレームに構成して、通信ネットワークを介した伝送の用に供する。
【０００４】
既存のフレーマは一般に単一のフレーミング・プロトコルしか処理することができない。既存のフレーマは特定のプロトコル用の機能をすべて実行するから、当該特定のプロトコルに適合しない受信データ・ストリームは有効であると確認されない。同様に、送信データは単一の所定プロトコルに従ってしかフレーミングされない。また、所定のプロトコルには様々なデータ伝送速度に応じて変種が存在する場合が多い。フレーマは一般に目標データ伝送速度用に最適化されている。したがって、データ伝送速度が変わると通常、所望のデータ伝送速度の所定プロトコルに対応するようにフレーマの設定を手動で変更しなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
したがって、複数のフレーミング・プロトコルおよび／または複数のデータ伝送速度をサポートしうるフレーマを実現することは好都合である。
【課題を解決するための手段】
【０００６】
本発明はたとえばデータ伝送システムにおいて使用するマルチ・プロトコル・フレーマ（以下、単にフレーマともいう）を形成する手法を提供するものである。前記マルチ・プロトコル・フレーマは伝送媒体（たとえば光ファイバ・ネットワーク）から受信した入力データ・ストリームの特定のデータ伝送プロトコルを自動的に検出することができる。前記フレーマは、該フレーマが特定のプロトコルを検出したら、前記検出したプロトコルに従って、前記入力データ・ストリームから有効なデータを抽出し、および／または有効なデータをフレーミングして前記伝送媒体を介した伝送の用に供するように構成されている。したがって、本発明に係る手法を用いると、複数のデータ伝送プロトコルを自動的に処理しうるだけでなく、当該プロトコルを先験的に知っている必要を無くすことのできるデータ・フレーマを実現することができる。
【０００７】
本発明の一側面によると、送信元データ・ストリームに潜在する少なくとも２つの異なるデータ・フレーミング・プロトコルをサポートしうるデータ・フレーマは少なくとも２つのフレーミング回路および該フレーミング回路に接続されたコントローラを備えている。フレーミング回路の各々は前記各フレーミング回路に付随する異なるデータ・フレーミング・プロトコルに従って前記送信元データ・ストリームからユーザ・データを抽出するように構成されている。前記コントローラは適切に、(i) 前記送信元データ・ストリームを受信して少なくとも２つのデータ・フレーミング・プロトコルのうちのどちらが前記送信元データ・ストリームに対応しているかを自動的に判断し、(ii)前記送信元データ・ストリームの前記判断したデータ・フレーミング・プロトコルと前記第１のデータ・フレーミング・プロトコルおよび前記第２のデータ・フレーミング・プロトコルのうちの一方との間の一致に応答して、前記送信元データ・ストリームを前記第１のフレーミング回路および前記第２のフレーミング回路のうちの一方に転送する。
【発明を実施するための最良の形態】
【０００８】
本発明はマルチ・プロトコル・フレーマを形成する手法を提供するものである。ここでは、光ファイバ・ネットワークを介してデータを伝送するための次に示すプロトコル群を特に参照してマルチ・プロトコル・フレーマを説明する。すなわち、ＳＯＮＥＴ（synchronous optical network:光同期伝送網）／ＳＤＨ（synchronous digital hierarchy:同期ディジタル・ハイアラーキ）プロトコル、イーサネット(R)ＷＡＮ（wide area network)プロトコル、イーサネット(R)ＬＡＮ（local area network）プロトコル、ファイバ・チャネルＷＡＮプロトコル、およびファイバ・チャネルＬＡＮプロトコルである。しかしながら認識すべき点を挙げると、本発明はこれらの、またはすべての特定のデータ伝送プロトコルおよび／または通信媒体に限定されない。
【０００９】
ＳＯＮＥＴ標準の詳細はたとえばＡＮＳＩ（American National Standards Institute:米国規格協会）文書Ｔ１．１０５−１９９５、Ｔ１．１０５．０２−１９９５、Ｔ１．１０５．０４−１９９５、およびＴ１．１０５．０９−１９９６に記載されている。ＷＡＮ同期標準はたとえばＡＮＳＩ Ｔ１ＴＲ３ＧＰＰ ２７．１０３−３００に記載されている。同様に、ＬＡＮプロトコル標準の概要はたとえばＩＳＯ（International Organization for Standardization: 国際標準化機構）／ＩＥＣ（International Electrical Commission:国際電気標準会議）文書ＴＲ ８８０２−１：２００１、ＩＳＯ／ＩＥＣ １００３８−１９９３、ＩＥＥＥ（Institute of Electrical and Electronics Engineers:米国電気電子技術者協会）文書８０２．７−１９８９およびＩＥＥＥ ８０２．１ｑ−１９９８に記載されている。ファイバ・チャネル標準はたとえば「ファイバ・チャネル−物理的および信号的インタフェース（Fibre Channel - Physical and Signaling Interface) 」（ＡＮＳＩ Ｘ３．２３０−１９９４）に記載されている。したがって、ここでは既存のデータ伝送プロトコルの詳細な説明は提示しない。
【００１０】
フレーマを含むデータ伝送システムにおいて、送信元と送信先との間でデータを伝送するのに使用するフレーミング・フォーマットを決める１つの方法は、フレーマの外部からデータ伝送プロトコルを手動で設定することである。しかし、これには従来、送信元が使用しているプロトコルを先験的に知っている必要があった。また、入来するデータ・ストリームのプロトコルが変化したときには常に、入来するデータが有効であることを確認するために、フレーマに関連付けられた設定を入来するプロトコルに対応するように手動で変更する必要もある。
【００１１】
手動による介入なしに、そして送信元が使用しているデータ・フレーミング・プロトコルを先験的に知る必要なしにプロトコルを変更することを可能にするために、本発明は受信したデータ・ストリームのプロトコルを自動的に検出し、そのプロトコルが使用しているフレーミング・アーキテクチャを自動的に追跡する手法を提供する。フレーマの受信側でプロトコルを検出したら、その検出したプロトコルに対応するようにフレーマの送信側を自動的に設定することができる。このように、本発明に従って形成したフレーマは手動による介入なしに自身の動作を自動的に決定することができるから好都合である。また、本発明に係るデータ・フレーマはデータ・フレーミング・プロトコルをユーザ選択可能な制御信号に応じて変更する能力も備えている。
【００１２】
図１は本発明に従って形成した典型的なデータ伝送システムを示す図である。図示したデータ伝送システム１００はＣＤＲ（clock and data recovery:クロックとデータの復元）回路１０２、一対のマルチ・プロトコル高速フレーマ１０４、１０６、一対の媒体アクセス制御（media access controller:ＭＡＣ）１１２、１１４、およびスイッチャ／ルータ１１６を備えているのが望ましい。ＣＤＲ回路１０２は伝送媒体、たとえばデータを伝送する光ファイバ・ネットワーク１１８に接続されている。ＣＤＲ回路１０２は入来するデータ・ストリームまたは外出するデータ・ストリームをそれぞれ少なくとも部分的に、適切に直列化し、および／または非直列化する。システムの受信側では、一方のフレーマ１０４がＣＤＲ回路１０２から入力データ・ストリーム１２０を受信するように適切に構成されている。入力データ・ストリーム１２０は複数の未決プロトコルのうちの１つのデータ・フレームから成る。システムの送信側では、他方のフレーマ１０６がＣＤＲ回路１０２へ出力データ・ストリーム１２２を送信するように適切に構成されている。入力データ・ストリーム１２０と同様に、出力データ・ストリーム１２２は複数のプロトコルのうちの１つのデータ・フレームから成り、入力データ・ストリームのプロトコルと一致しているのが望ましい。
【００１３】
受信側では、マルチ・プロトコル・フレーマ１０４は入力データ・ストリーム１２０のプロトコルを自動的に検出し、そこから有効なデータを抽出するように構成されているのが望ましい。プロトコルが確認できたら、検出したプロトコルに対応する所定のフレーム内で、有効なデータを容易に突き止めることができる。フレーマ１０４はＳＯＮＥＴ／ＳＤＨ型のデータをスイッチャ／ルータ１１６に供給して伝送の用に供する第１の出力１２４を備えているのが望ましい。また、フレーマ１０４はイーサネット(R)／ファイバ・チャネル型のデータをＭＡＣ（媒体アクセス制御）１１２に供給する第２の出力１３０も備えているのが望ましい。ＭＡＣ１１２はスイッチャ／ルータ１１６に適切に接続されている。ＭＡＣ１１２はシステム内のスイッチ・ルーティングを評価するように少なくとも部分的に機能する。
【００１４】
送信側では、マルチ・プロトコル・フレーマ１０６はスイッチャ／ルータ１１６からＳＯＮＥＴ／ＳＤＨ型データ１２６を直接に、またはＭＡＣ１１４を介してスイッチャ／ルータ１１６からイーサネット(R)／ファイバ・チャネル型データ１２８を受信するように構成されているのが望ましい。いずれの場合でも、スイッチャ／ルータ１１６から受信するデータは、受信側のマルチ・プロトコル・フレーマ１０４が検出したプロトコルを用いて送信側のマルチ・プロトコル・フレーマ１０６がフレーミングしたものであるのが望ましい。次いで、フレーミングしたデータは出力データ・ストリーム１２２としてＣＤＲ回路１０２に送り、光ファイバ・ネットワーク１１８を介して送信先へ伝送する。
【００１５】
次に、図２を参照する。図２は本発明の一側面に従い受信側のオペレーション用に構成されたマルチ・プロトコルの高速フレーマを示す図である。説明を容易するために、マルチ・プロトコル・フレーマ２００はいくつかの機能ブロック、たとえばプロトコル追跡・フレーム同期エンジン２０２、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４、およびイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８で構成されているのが望ましい。認識すべき点を挙げると、これらの機能ブロックの各々はそれに対応する個別回路、たとえばＤＳＰ（digital signal processor）または等価の処理装置で実現することができる。あるいは、単一の回路を用いて複数の機能ブロックを実現することもできる。また、当業者が理解しうるように、本発明によれば、フレーマに付随する少なくとも１つの機能ブロックをプロセッサで実行するソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせで実現することも考えられる。
【００１６】
プロトコル追跡・フレーム同期エンジン２０２はたとえば光ファイバ・ネットワークからそれに提供される入力データ・ストリーム２２６を受信し、その入力データ・ストリーム中にフレーム同期パターンがないか検索するのが望ましい。たとえば、ＷＡＮプロトコルの場合、データ・ストリームは同期トランスポート信号（ＳＴＳ）の開始を示すフレーミング・バイトＡ１、Ａ２を含んでいる。あるいは、ＬＡＮプロトコルの場合、データ・ストリームはＬＡＮ型データ・フレームの開始を示す６６ビットごとの０１／１０ビット・シーケンスを含んでいる。プロトコル追跡・フレーム同期エンジン２０２は複数のステート・マシン２１０、２１２を備えているのが望ましい。ステート・マシン２１０、２１２の各々は入力データ・ストリーム２２６から異なる所定のプロトコルを適切に検出するように構成されている。本発明によれば、プロトコル追跡・フレーム同期エンジン２０２に追加のステート・マシン（図示せず）を付加して、それに対応する追加のデータ伝送プロトコルを検出するようにすることも考えられる。これにより、フレーマのプロトコル検出機能が拡大する。
【００１７】
ステート・マシン２１０、２１２は各々、入力データ・ストリーム２２６を受信し、実質的に並列に動作し、入力データ・ストリームを実質的に走査し、それに付随する所定のプロトコル標準に従うデータ・フレームを検出するのが望ましい。並列に動作することにより、ステート・マシン２１０、２１２は入力データ・ストリームから未決のプロトコルをより迅速に検出することが可能になる。したがって、本発明に従って形成したデータ・フレーマの速度は顕著に改善されている。ステート・マシンの一方がその構成されたプロトコルに対応する特定のデータ・フレームを検出したら（当該ステート・マシンは「インフレーム（in-frame）」状態または「追跡（lock）」状態にあると言われる）、このインフレーム状態が終了するまで、他方のステート・マシンは無効にする、あるいはシャットオフする。不使用のステート・マシンを無効にすることにより、フレーマの消費電力を低減することができる。
【００１８】
プロトコル追跡・フレーム同期エンジン２０２がＷＡＮ型プロトコルの入力データ・ストリームを特定したら、ステート・マシン２１０（これはこの例ではデータ・ストリーム２２６からＷＡＮ型プロトコルを検出するのに使用している）は自身がインフレーム状態にあることを示す制御信号を生成するのが望ましい。ステート・マシン２１０が生成したインフレーム制御信号はステート・マシン２１２を適切に無効にし、および／または入力データ・ストリームをステート・マシン２１０に付随する引き続く処理回路に適切に転送するのに使用する。入力データ・ストリームのプロトコルを特定したら、インフレームのステート・マシン（たとえば２１０）は継続して入力データ・ストリーム２２６を定期的にモニタしインフレーム状態が継続しているか否かを判断するのが望ましい。認識すべき点を挙げると、ステート・マシンがインフレーム状態になり、データ伝送プロトコルが既知であることを示すと、検出したプロトコルに対応するフレーム境界は容易に判定することができる。したがって、当業者が理解しうるように、インフレーム状態が継続しているか否かを判断するには、ステート・マシンは予期するフレーム境界がないか入力データ・ストリームをモニタするだけでよい。
【００１９】
ステート・マシン２１０は以前にＷＡＮ型プロトコルとして特定された入力データ・ストリームを線２１４を介してＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４へ転送する。ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４は入来するデータ・ストリームがＳＯＮＥＴ／ＳＤＨプロトコルであるかＷＩＳ（WAN interface sublayer: ＷＡＮインタフェース副層）プロトコルであるかを判断する。これらは当業者に知られているように、それぞれＳＯＮＥＴ／ＳＤＨ標準とＷＩＳ標準（たとえばＡＮＳＩ Ｔ１．４１６−１９９９）によって規定されている。これを行うために、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４は入力データ・ストリーム中の少なくとも１つの所定バイト位置を検出するように構成されている。たとえば、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４は、ＳＯＮＥＴ／ＳＤＨプロトコルでは使用されているがＷＩＳプロトコルでは不使用で特定の論理レベル、たとえば論理“０”に設定されているいくつかのオーバーヘッド・バイトを適切に検出する。認識すへき点を挙げると、本発明によれば、特定のプロトコルを特定する、あるいは少なくとも２つのプロトコルを分別するのに別の手法を用いることもできる。
【００２０】
ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４に入来するデータ・ストリーム２１４が純粋のＳＯＮＥＴ／ＳＤＨプロトコルであると判断したら、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４は当該データ・ストリームをたとえば線２２２を介して引き続く処理回路（たとえば図１のスイッチャ／ルータ１１６）に転送するのが望ましい。あるいは、データ・ストリーム２１４がＳＯＮＥＴ／ＳＤＨプロトコルとして認識されない場合には、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４に含まれるＷＩＳブロック２２８が当該データ・ストリームを線２１８を介してステート・マシン２１２に転送し、さらなる処理の用に供する。ＷＩＳフレームは実質的に複数のイーサネット(R)／ファイバ・チャネル・フレームを含んでいるから、ＷＩＳデータ・ストリーム２１８はＬＡＮ型プロトコルに従ってさらに処理することができる。
【００２１】
プロトコル追跡・フレーム同期エンジン２０２が入力データ・ストリームがＬＡＮ型プロトコルであると特定したら、ステート・マシン２１２はインフレーム制御信号を生成するのが望ましい。ステート・マシン２１２が生成したインフレーム制御信号は上述したようにステート・マシン２１０と同一の方法で使用して、ステート・マシン２１０およびそれに付随するすべての不使用の回路（たとえばＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４）を適切に無効にし、および／または、データ・ストリームをステート・マシン２１２に付随する引き続く回路に転送する。上述したように、入力データ・ストリーム２２６のプロトコルを特定したら、インフレームのステート・マシン（たとえば２１２）は継続して定期的にデータ・ストリームをモニタしてインフレーム状態を継続しているか否かを判断するのが望ましい。
【００２２】
ステート・マシン２１２はＬＡＮ型プロトコルであるとすでに判断されたデータ・ストリームをイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に含まれるスクランブラ／デスクランブラ２０６に適切に転送する。スクランブラ／デスクランブラ２０６は、データ・ストリームにおいて十分なビット遷移（たとえば“０”から“１”へまたは“１”から“０”へ）を実現するために以前にスクランブルされた入来するフレームからペイロード・フィールドとオーバーヘッド・フィールドを抽出するように構成されているのが望ましい。当業者が理解しうるように、受信器フェーズ・ロック・ループを用いた光ファイバ・システムでは、受信器フェーズ・ロック・ループがジッタの少ない受信データからクロック信号を復元しうるように、データ・ストリームは一般に所定数のビット遷移を含むようにエンコードする必要がある。上述したように、ＷＩＳフレームは実質的に複数のイーサネット(R)／ファイバ・チャネル・フレームを含んでいるから、ＷＩＳデータ・ストリーム２１８はイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８によってさらに処理することができる。また、スクランブラ／デスクランブラ２０６はエラー検出および／またはエラー訂正のためにデータをエンコード／デコードする機能も備えている。たとえば、ＬＡＮ型プロトコルでは、受信データの６６ビットごとに実データは６４ビットしかない。したがって、デスクランブラは６６ビットのデータ・ストリーム２１６を６４ビットのデータ・ストリーム２２４に（たとえば６６ビット／６４ビット・デコーダを用いて）変換するように構成されているのが望ましい。
【００２３】
イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８は入来するデータ・ストリーム２１６がイーサネット(R)標準とファイバ・チャネル標準でそれぞれ規定されているイーサネット(R)・プロトコルであるのかファイバ・チャネル・プロトコルであるのかを判断するのが望ましい。イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８は次に示す様々な手法を用いてイーサネット(R)・プロトコルとファイバ・チャネル・プロトコルとを分別するように構成することができる。すなわち、順序付セット信号方式（ordered set signaling)、ＳＯＦ（start-of-file:ファイル開始）・ＥＯＦ（end-of-file:ファイル終了）認識方式、ＯＦＣ（open fiber control: 開放ファイバ制御）信号方式などである。これらについては下で詳述する。また、本発明で使用するのに好適な別の分別手法も同様に考えられる。
【００２４】
当業者が理解しうるように、ファイバ・チャネル・プロトコルの文脈における順序付セット（ordered set)はデータと第１の伝送キャラクタとしての特別キャラクタとを含む４バイトの伝送ワードである。順序付セットはたとえばフレーム・デリミタ、基本信号、基本シーケンスなどである。順序付セットを少なくとも部分的に使用すると、ファイバ・チャネル制御情報とデータとを区別しうるとともに、ビットとワードの同期をとる機能（これはワード境界の位置合わせの確立も行う）を実現することができる。ＩＥＥＥ標準８０２．３ａｅに従うフレーム信号方式（ＦＳＩＧ）は、ファイバ・チャネル・コードの順序付セットを送るのに使用されるとともに、常に特別なキャラクタＫ２８．２で開始する。順序付セットのバイト０の位置に存在するこの特別なキャラクタＫ２８．２は常にファイバ・チャネルの順序付セット・データ（たとえばＫ２８．２−Ｄｘ１．ｙ１−Ｄｘ２．ｙ２−Ｄｘ３．ｙ３）を示し、次いで適切なファイバ・チャネルの順序付セット（たとえばＫ２８．５−Ｄｘ１．ｙ１−Ｄｘ２．ｙ２−Ｄｘ３．ｙ３）に逆変換される。
【００２５】
イーサネット(R)・プロトコルとファイバ・チャネル・プロトコルとを区別する別の手法がＳＯＦ・ＥＯＦ認識方式である。フレーム・デリミタのＳＯＦとＥＯＦは所定フレームの内容の直前と直後にそれぞれ付される。ＳＯＦとＥＯＦはイーサネット(R)とファイバ・チャネルでは扱いが異なる。たとえば、ファイバ・チャネルでは、ＳＯＦおよびＥＯＦの双方用に特定の順序付セットを使用する。これに対して、イーサネット(R)では、ＳＯＦおよびＥＯＦ用に単一の制御キャラクタしか使用しない。また、ファイバ・チャネル・プロトコルでは４バイトの順序付セットを使用しているから、デリミタＳＯＦおよびＥＯＦ用の制御キャラクタは常に同じバイト位置に存在する。しかし、イーサネット(R)・プロトコルでは、同じバイト位置に存在するのはＳＯＦキャラクタのみであり、ＥＯＦキャラクタは任意のバイト位置に存在しうる。これらの相違点は、たとえば１０ギガヘンツ（ＧＨｚ）ファイバ・チャネル標準文書第１．０版第１４節第５３頁以降（２００１年３月１０日）、および１０ＧＨｚイーサネット(R)標準文書ＩＥＥＥ ８０２．３ａｅドラフト２．３第４８．３節第２９６頁以降に記載されている。
【００２６】
特に、イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に存在する６６ビット／６４ビット・デコーダ（図示せず）を出たバイトと、イーサネット(R)・プロトコルおよびファイバ・チャネル・プロトコルに固有の予期されるＳＯＦキャラクタおよびＥＯＦキャラクタとを実質的に同時に比較するのが望ましい。ＳＯＦ制御キャラクタとＥＯＦ制御キャラクタを適切に位置合わせしたファイバ・チャネルの順序付セットおよび／または順序付シーケンスを検出したら、イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に含まれるステート・マシンはＳＯＦ終端処理とＥＯＦ終端処理を適切に行ったデータ・パケットをカウントし始め、ユーザ設定可能なカウント値までカウントして偽ファイバ・チャネルを検出しえないようにするのが望ましい。ファイバ・チャネルのセットを検出しない場合、あるいはデータ・ストリーム中でファイバ・チャネル・プロトコル用とは違ったバイト位置すなわち予期しないバイト位置でＥＯＦ制御キャラクタを検出した場合、イーサネット(R)・データであると推定する。この例では、イーサネット(R)に固有のステート・マシンが、ＳＯＦキャラクタが適切なバイト位置にないか検索したのち、適切にフォーマットされたイーサネット(R)・パケットをユーザ設定可能な最大値までカウントし始めるのが望ましい。
【００２７】
本発明では、データ・ストリーム中の単一のパケット・エラーに起因する「グリッチ（glitch: 瞬間的な異常）」および／または他の異常の影響をフレーマがあまり受けないように、上述した最大カウント値を使用してプロトコル決定プロセスにヒステリシスを実現するのが望ましい。本発明によれば、このようなヒステリシスの実現に様々な手法を用いることができる。たとえば、イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に「有効パケット」カウンタ（図示せず）を備える。この有効パケット・カウンタは所定のカウント値に初期化する。ある期間経過後、イーサネット(R)またはファイバ・チャネルのＳＯＦおよび／またはＥＯＦのフォーマットがエラーであることが分かった場合、有効パケット・カウンタに付随するカウント値を１だけインクリメントまたはデクリメントして、単一のパケット・エラーではイーサネット(R)／ファイバ・チャネル決定プロセスが不所望に「グリッチ」する、すなわち別のプロトコルを使用するように切り替えることがないようにする。また、当業者が理解しうるように、有効パケット・カウンタとともに比較器（図示せず）を用いてカウンタの値と所定のカウント値とを比較して、プロトコルを変更する必要があるか否か（たとえば許容できない個数のパケット・エラーが検出されたか否か）を判断してもよい。さらに本発明によれば、エラー・レートが十分に低いプロトコルが見つからない場合、フレーマは特定のプロトコルに付随する標準によって決められた方法またはユーザが決めた方法で、ＬＯＬ（loss of link: リンク損失）を表示する。
【００２８】
認識すべき点を挙げると、上述したものの他に本発明のプロトコル決定機能およびプロトコル切り替え機能を実現するために使用しうる様々な方法が存在する。たとえば、本発明の別の側面によれば、イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８ははじめにファイバ・チャネル・プロトコルを探索するのではなく、はじめにイーサネット(R)・プロトコルを探索してもよい。こうするためには、イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８をＥＯＦ制御キャラクタの変動しうる位置を検出しうるように構成する。あるいは、ＳＯＦとイーサネット(R)のプリアンブル・キャラクタとを用いて、ファイバ・チャネル・プロトコルに対応するＳＯＦの順序付セットの定義とは異なる独自の疑似順序付セット（pseudo-ordered set）を規定してもよい。
【００２９】
また上述したように、本発明によれば、ＯＦＣ信号手法を用いてイーサネット(R)・プロトコルとファイバ・チャネル・プロトコルとを分別してもよい。ＯＦＣ信号手法はデータ伝送システム１００のＣＤＲ回路（図１参照）で使用するが、単一のファイバを介して複数のデータ・ストリームを伝送する８５０ナノメートル（ｎｍ）の波長分割多重（ＷＤＭ）型ファイバ・チャネル・リンクを構築する際に使用するＯＦＣに依存している。たとえばＯＦＣ機能の場合、ファイバ・チャネル・リンクは、高速フロント・エンド回路が生成しＣＤＲ回路１０２のＯＦＣ回路が処理する信号を用いてレーザ対応信号（たとえばＬａｓｅｒ＿Ｅｎ）を生成する。当業者が理解しうるように、このレーザ対応信号は高速フロント・エンド回路が信号を検出するときには“Ｈ”論理レベルである。イーサネット(R)・プロトコルもＳＯＮＥＴプロトコルもこの信号を使用していないから、レーザ対応信号が“Ｈ”論理レベルになるリンクはすべて自動的にファイバ・チャネル・リンクであると考えられる。
【００３０】
例示のみを目的として、図３は本発明により、入来するデータ・ストリームのプロトコルを判断するために図２のマルチ・プロトコル・フレーマが用いる判定ツリー３００を示す図である。上述したように、入来するデータ・ストリームがＷＡＮ型プロトコルであるかＬＡＮ型プロトコルであるかをノード３０２で判断する。ＷＡＮ型プロトコルを検出したら，フレーマはそのＷＡＮ型プロトコルのデータ・ストリーム３２０をノード３０４へ転送する。ノード３０４では、データ・ストリーム３２０がＳＯＮＥＴ／ＳＤＨプロトコルであるかＷＩＳプロトコルであるかを判断する。ＳＯＮＥＴ／ＳＤＨプロトコルを検出したら、ＳＯＮＥＴ／ＳＤＨ型データ・ストリーム３１０を所定の送信先へ転送する。同様に、ノード３０４で、データ・ストリーム３２０がＷＩＳプロトコルであると判断したら、ＷＩＳプロトコル型データ・ストリーム３２４をノード３０８へ転送し、さらなる処理の用に供する。ノード３０８では、データ・ストリーム３２４がイーサネット(R)・プロトコルであるかファイバ・チャネル・プロトコルであるかを適切に判断する。ノード３０８で受信するデータ・ストリームは以前にＷＡＮ型プロトコルであると判断されているから、ノード３０８はイーサネット(R)ＷＡＮプロトコル型データ・ストリーム３１６、またはファイバ・チャネルＷＡＮプロトコル型データ・ストリーム３１８を各所定の送信先へ出力する。
【００３１】
ノード３０２で入来するデータ・ストリームがＬＡＮ型プロトコルであると判断したら、そのＬＡＮ型プロトコルのデータ・ストリーム３２２をノード３０６へ転送してさらなる処理の用に供する。ノード３０６では、データ・ストリーム３２２がイーサネット(R)・プロトコルであるかファイバ・チャネル・プロトコルであるかを判断する。ノード３０６で受信するデータ・ストリームは以前にＬＡＮ型プロトコルであると判断されているから、ノード３０６はイーサネット(R)ＬＡＮプロトコル型データ・ストリーム３１２、またはファイバ・チャネルＬＡＮプロトコル型データ・ストリーム３１４を各所定の送信先へ出力する。認識すべき点を挙げると、ノード３０６と３０８は各々、所定のデータ・ストリームに対してイーサネット(R)・プロトコルとファイバ・チャネル・プロトコルとを分別するように少なくとも部分的に機能する。したがって、ノード３０６と３０８は同じまたは同様の機能ブロック（たとえば図２のブロック２０８）で実現することができる。
【００３２】
本発明に係るマルチ・プロトコル・フレーマが処理するプロトコルの個数と種別が変化すると、それに合わせて判定ツリー３００も変化する。また、当業者が理解しうるように、図示した判定ツリー３００と同じように送信側オペレーション用に構成した判定ツリーもマルチ・プロトコル・フレーマ用に規定することができる。
【００３３】
次に、図４を参照する。図４は送信側オペレーション用に構成した本発明によるマルチ・プロトコル高速フレーマ４００を示す図である。マルチ・プロトコル・フレーマ４００は図２に示した受信側のマルチ・プロトコル・フレーマと同様に、プロトコル追跡・フレーム同期エンジン２０２、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４、およびイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８を備えている。認識すべき点を挙げると、これらの機能ブロックの各々はそれに対応する個別回路、たとえばＤＳＰ（digital signal processor）などで実現することができる。あるいは、単一の回路を用いて複数の機能ブロックを実現することもできる。また当業者が理解しうるように、本発明によれば、フレーマに付随する少なくとも１つの機能ブロックを、プロセッサ上で実行するソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせで実現することができる。
【００３４】
送信オペレーションの間、マルチ・プロトコル・フレーマ４００はＳＯＮＥＴ／ＳＤＨ型の送信元に由来する第１のデータ・ストリーム４０２とイーサネット(R)／ファイバ・チャネル型の送信元に由来する第２のデータ・ストリーム４０４とを（必ずしも同時並行的ではなく）受信する。第１のデータ・ストリーム４０２はＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４に転送する。ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４は受信したデータを適切に処理してＳＯＮＥＴ／ＳＤＨプロトコル型出力データ・ストリーム４０８を生成する。プロトコル追跡・フレーム同期エンジン２０２に含まれている第１のステート・マシン２１０はＷＡＮ型プロトコルに従ってデータを処理するように構成されているのが望ましい。ステート・マシン２１０はＳＯＮＥＴ／ＳＤＨプロトコル型データ・ストリーム４０８を受信しＷＡＮ型プロトコルのフレームを生成して光ファイバ・ネットワーク４１４（または別の通信媒体）を介した所定送信先への送信の用に供する。
【００３５】
イーサネット(R)／ファイバ・チャネル型の送信元に由来するデータ・ストリーム４０４はイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に転送する。イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８は受信したデータを適切に処理してイーサネット(R)／ファイバ・チャネル・プロトコル型の出力データ・ストリーム４０６を生成する。イーサネット(R)／ファイバ・チャネル・プロトコル型データ・ストリーム４０６はイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に含まれているスクランブラ／デスクランブラ２０６でエンコードして、当該データ・ストリーム中に十分なビット遷移（たとえば“０”から“１”へまたは“１”から“０”へ）を実現するのが望ましい。このプロセスは「スクランブル」と呼ばれている。上述したように、受信器フェーズ・ロック・ループを用いた光ファイバ・システムでは、データ・ストリームは一般に所定数のビット遷移を含むようにエンコードし、受信器フェーズ・ロック・ループがジッタの少ない受信データからクロック信号を復元しうるようにする必要がある。
【００３６】
（たとえば受信側フレーマまたは送信元データ・ストリーム自身が判断した結果）送信元データ・ストリーム４０４の送信先プロトコルがＷＡＮ型プロトコルである場合、スクランブラ／デスクランブラ２０６はエンコード済みイーサネット(R)／ファイバ・チャネル・プロトコル型データ・ストリームを生成する。このデータ・ストリームはプロトコル追跡・フレーム同期エンジン２０２に含まれる第２のステート・マシン２１２を通じてＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４に含まれるＷＩＳブロック２２８に転送するのが望ましい。ＷＩＳブロック２２８は受信したデータ・ストリーム４１０をＷＩＳプロトコルに従って処理する。そして、ＳＯＮＥＴ／ＳＤＨブロック２０４がさらに処理してＳＯＮＥＴ／ＳＤＨプロトコル型の出力データ・ストリーム４０８を生成する。このＳＯＮＥＴ／ＳＤＨプロトコル型データ・ストリーム４０８はステート・マシン２１０が受信し、ＷＡＮ型プロトコルのフレームを生成して光ファイバ・ネットワーク４１４を介した所定送信先への伝送の用に供する。ステート・マシン２１２が出力したデータ・ストリームを光ファイバ・ネットワーク４１４またはＷＩＳブロック２２８へ選択的に転送しうるように、フレーマ４００にはマルチプレクサ（ＭＵＸ）４１２が設けられている。また、（たとえばステート・マシン２１２が出す）ＬＡＮ型データ・ストリームまたは（たとえばステート・マシン２１０が出す）ＷＩＳ型データ・ストリームを光ファイバ・ネットワーク４１４へ選択的に転送しうるように第２のＭＵＸ４１６も設けられている。
【００３７】
送信元データ・ストリーム４０４がＬＡＮ型プロトコルである場合、スクランブラ／デスクランブラ２０６はエンコード済みイーサネット(R)／ファイバ・チャネル・プロトコル型データ・ストリーム４０６を生成する。このデータ・ストリーム４０６はプロトコル追跡・フレーム同期エンジン２０２に含まれる第２のステート・マシン２１２に転送する。第２のステート・マシン２１２はＬＡＮ型プロトコルでデータを処理するのが望ましい。第２のステート・マシン２１２はエンコード済みイーサネット(R)／ファイバ・チャネル・プロトコル型データ・ストリーム４０６を受信して適切なＬＡＮ型プロトコルのフレームを生成し、光ファイバ・ネットワーク４１４を介した所定送信先への伝送の用に供する。この例では、出力データ・ストリームはＷＩＳブロック２２８を通過してさらなる処理を受けることはない。
【００３８】
認識すへき点を挙げると、上述したように、送信オペレーションの間に出力すべきプロトコルは受信側フレーマに付随するステート・マシンが生成する制御信号（たとえばインフレーム制御信号）または他の手段によって決まる。あるいは当業者が理解しうるように、本発明によれば、送信先プロトコルに関する情報はフレーマ４００が受信する入来データ・ストリーム中にエンコードすることも考えられる。また、送信側フレーマ４００が使用するプロトコルはユーザ選択可能である。
【００３９】
図面ではマルチ・プロトコル・フレーマが特定のプロトコルに対応する、プロトコル固有の機能ブロックを備えているものとして示したが、これらのブロックのうちの少なくとも１つを複数のプロトコルが共用してもよい。たとえば、スクランブラ／デスクランブラはプロトコルに無関係であるのが望ましいから、受信した各プロトコル用に使用することができる。同様に、エンコーダ／デコーダ機能は（たとえばファイバ・チャネル・プロトコルにおける）マッピング制御順序付セットや（たとえばイーサネット(R)・プロトコルにおける）マッピング制御キャラクタなどの小さな変更を除いて実質的に同一である。したがって、これらのプロトコルのデコードおよび／またはエンコードは僅かな変更を加えた同じハードウェアを用いて行うことができる。
【００４０】
また、入来するデータ・ストリームのプロトコルが分かったら、不使用プロトコルに付随する機能ブロックはパワーダウンするか、無効にできる点が好都合である。これにより、フレーマの全消費電力を顕著に低減することができる。たとえば、ＷＩＳフレームのオーバーヘッドはＳＯＮＥＴ／ＳＤＨのオーバーヘッドの一部である。したがって、イーサネット(R)／ファイバ・チャネルＷＡＮ型データ・ストリームを受信している間、ＳＯＮＥＴ／ＳＤＨ機能ブロックの少なくとも一部を無効にすることができる。
【００４１】
受信したデータ・ストリームのプロトコルに関する情報は（たとえばデータ・リンク層における）引き続くデータ処理に使用できるから、本発明の別の側面によるマルチ・プロトコル・フレーマは検出したプロトコルに付随する情報を、たとえばさらなるプロトコル固有の処理を可能にするように提示するように構成されているのが望ましい。これはたとえばシリアル管理インタフェース（たとえばＭＤＩＯ（multiplexed data input/output)／ＭＤＣ（multiplexed data clock）インタフェース）を介して、あるいはインタフェースにおいて、コード済みのデータを使用している場合にはインバンド（in-band)を介して実現することができる。すべてのデータをＩＰ（Internet Protocol)フォーマットで伝送する場合には、送信側を適切な出力フォーマットにスイッチすることができる。様々なプロトコルが出すＩＰデータを１つのスイッチに適切に供給することができるのは、スイッチ入力にＦＩＦＯ（first-in first-out）バッファ（または等価のバッファ装置）が備わっている場合である。バッファリングすることにより、データ・フレーマは入来するデータ・ストリームのデータ伝送速度の小さな偏差を処理することが可能になる。当業者が理解しうるように、所定のプロトコルのデータ伝送速度の許容できる偏差はたとえば特定のプロトコルに対応する標準に記載されている。
【００４２】
図１とともに上述したＣＤＲ回路について。光ファイバ・ネットワークに由来するデータをフレーマが受信する前に、入来するデータ・ストリームのクロックとデータを復元する必要がある。下の表１に示すように、ここで述べた様々なプロトコルのデータ伝送速度は異なるが、本発明に係るマルチ・プロトコル・フレーマはそれらを復元することができる。
【００４３】
【表１】
【００４４】
表１において、「ＸＡＵＩ」なる用語は１０ギガビット・アタッチメント・ユニット・インタフェースのことである。また、すべてのデータ伝送速度の単位はギガビット毎秒（Ｇｂｓ）である。フレーマが適切に機能するように、ＣＤＲ回路はこの範囲内のすべての周波数を追跡しうるように構成する必要がある。また、マルチ・プロトコル・フレーマに追加のプロトコルおよび／またはデータ伝送速度を含める場合には、ＣＤＲ回路はそれら追加の周波数もカバーするように構成する必要がある。
【００４５】
ＣＤＲ回路が問題の周波数範囲で動作しうることを保証するために用いうる様々な方法がある。１つの手法はたとえばＰＬＬ（phase lock loop)回路を備えることにより入来する周波数を自動的に追跡しうるようにＣＤＲ回路を構成することである。別の実施形態では、選定する周波数範囲として狭い帯域幅を複数備えるようにＣＤＲ回路を構成してもよい。当業者が理解しうるように、マルチ・プロトコル・フレーマがＣＤＲ回路から受信するデータ・ストリームに有用な情報が何もない場合には、ＣＤＲ回路における周波数帯域幅の変更を指令してＣＤＲ回路が入来する周波数を追跡しうるように本発明に係るフレーマを構成してもよい。この手順はフレーマがデータ・ストリーム中に、サポートされているプロトコル群のうちの１つに対する有効なフレーミング・シーケンスを検出するまで繰り返すことができる。
【００４６】
図５に示すように、ここで説明した本発明に係るマルチ・プロトコル高速フレーマはコントローラまたはプロセッサ５０２、メモリ５０４、およびユーザ・インタフェース５０６を備えた処理装置５００によって全体的にあるいは部分的に実現することができる。認識すべき点を挙げると、ここで使用している「プロセッサ」なる用語はすべての処理装置、たとえば中央処理装置（ＣＰＵ）および／または処理回路（たとえばＤＳＰ（digital signal processor）、マイクロプロセッサ、コントローラなど）を備えたものを意味している。また、理解すべき点を挙げると、「プロセッサ」なる用語は複数の処理装置を指し、１つの処理装置に付随する様々な構成要素を他の処理装置が共用してもよい。ここで使用する「メモリ」なる用語はプロセッサ（すなわちＣＰＵ）に付随するメモリおよび他のコンピュータ読み取り可能な媒体、たとえばＲＡＭ（random access memory）、ＲＯＭ（read only memory）、固定記憶媒体（たとえばハード・ディスク駆動装置）、着脱可能記憶媒体（たとえばディスケット）、フラッシュ・メモリなどを含むことを意図している。さらに、ここで使用する「ユーザ・インタフェース」なる用語はたとえばプロセッサにデータを入力する少なくとも１つの入力装置（たとえばキーボード、マウスなど）および／またはプロセッサに付随する結果を表示する少なくとも１つの出力装置（たとえばモニタなど）を含むことを意図している。
【００４７】
したがって、本発明に係る方法を実行する命令またはコードを含むアプリケーション・プログラム（またはそのソフトウェア・コンポーネント）は付随する少なくとも１つの記憶媒体（たとえばＲＯＭ、固定記憶装置、着脱可能記憶装置など）に格納することができ、使用すべきときには（たとえばＲＡＭに）全体的または部分的にロードし、プロセッサ５０２によって実行することができる。いずれにしても、認識すべき点を挙げると、図１と図２に示した構成要素のうちの少なくとも１つは様々な形態のハードウェア、ソフトウェア、またはそれらの組み合わせ、たとえば付随するメモリ、ＡＳＩＣ（application-specific integrated circuit)、機能回路などを備えた少なくとも１つのＤＳＰ（digital signal processor）として実現することができる。
【００４８】
以上、図面を参照して本発明の実施形態を説明したが、理解すべき点を挙げると、本発明はそれら正確な実施形態に限定されず、特許請求の範囲の範囲の内で当業者は様々な他の変形と変更をなしうる。
【図面の簡単な説明】
【００４９】
【図１】本発明に係るマルチ・プロトコル高速フレーマのシステム構成を示すブロック図である。
【図２】本発明の一側面に従って形成した受信側マルチ・プロトコル・フレーマを示すブロック図である。
【図３】本発明により、入来するデータ・ストリームのプロトコルを判断する、図２に示すマルチ・プロトコル・フレーマが使用する典型的な判定ツリーを示すブロック図である。
【図４】本発明に従って形成した送信側マルチ・プロトコル・フレーマを示すブロック図である。
【図５】本発明に係る方法を実現する一般化したデータ処理システムを示すブロック図である。
【符号の説明】
【００５０】
１００ データ伝送システム
１０２ ＣＤＲ回路
１０４ マルチ・プロトコル高速フレーマ
１０６ マルチ・プロトコル高速フレーマ
１１２ 媒体アクセス制御（ＭＡＣ）
１１４ 媒体アクセス制御（ＭＡＣ）
１１６ スイッチャ／ルータ
１１８ 光ファイバ・ネットワーク
１２０ 入力データ・ストリーム
１２２ 出力データ・ストリーム
１２４ 第１の出力
１２６ ＳＯＮＥＴ／ＳＤＨ型データ
１２８ イーサネット(R)／ファイバ・チャネル型データ
１３０ 第２の出力
２００ マルチ・プロトコル・フレーマ
２０２ プロトコル追跡・フレーム同期エンジン
２０４ ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック
２０６ スクランブラ／デスクランブラ
２０８ イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック
２１０ ステート・マシン
２１２ ステート・マシン
２１４ 入力データ・ストリーム
２１６ データ・ストリーム
２１８ データ・ストリーム
２２４ データ・ストリーム
２２８ ＷＩＳ
３１０ ＳＯＮＥＴ／ＳＤＨ型データ・ストリーム
３１２ イーサネット(R)ＬＡＮプロトコル型データ・ストリーム
３１４ ファイバ・チャネルＬＡＮプロトコル型データ・ストリーム
３１６ イーサネット(R)ＷＡＮプロトコル型データ・ストリーム
３１８ ファイバ・チャネルＷＡＮプロトコル型データ・ストリーム
３２０ ＷＡＮ型プロトコルのデータ・ストリーム
３２２ ＬＡＮ型プロトコルのデータ・ストリーム
３２４ ＷＩＳプロトコル型データ・ストリーム
４００ マルチ・プロトコル・フレーマ
４０２ 第１のデータ・ストリーム
４０４ 第２のデータ・ストリーム
４０６ イーサネット(R)／ファイバ・チャネル・プロトコル型出力データ・ストリーム
４０８ ＳＯＮＥＴ／ＳＤＨプロトコル型出力データ・ストリーム
４１０ データ・ストリーム
４１２ マルチプレクサ（ＭＵＸ）
４１４ 光ファイバ・ネットワーク
４１６ マルチプレクサ（ＭＵＸ）
５００ 処理装置
５０２ コントローラまたはプロセッサ
５０４ メモリ
５０６ ユーザ・インタフェース
【技術分野】
【０００１】
本発明は一般にデータ伝送システムに関し、特に少なくとも２つのデータ・フレーミング・プロトコルを自動的にサポートしうるデータ・フレーマに関する。
【背景技術】
【０００２】
よく知られていることだが、通信ネットワークを介して送信元と送信先との間で情報を転送するのに依拠するデータ通信プロトコルは通常、送信元と送信先との間でデータを同期させるためにフレーミング・アーキテクチャを用いている。データ・フレームは様々なセクション、たとえばメッセージ・セクションと当該メッセージ・セクションに付随する情報セクション（たとえばフレーミング・データ）とに分割することができる。情報セクションはたとえばフレーム境界を特定したり、通信ネットワーク経路を維持したりするために使用する。情報セクションは通常、データ・フレームのヘッダ部および／またはトレーラ部に存在する。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす。）データ通信プロトコルが異なると、通信ネットワークを介してデータを送信するのに異なるフレーム構成を使用する場合が多い。
【０００３】
データ・フレーマは一般にデータ伝送システムのデータ・リンク層で機能する装置である。システムの受信側で使用する場合、フレーマは入来するデータ・ストリームから事前設定のフォーマットまたはプロトコルのデータ・フレームを検索する。事前設定のプロトコルを用いてフレーム境界を特定したら、引き続く処理段において有効なユーザ・データをフレーム内で突き止める。送信側では、フレーマはユーザ・データを事前設定のプロトコルに対応するフレームに構成して、通信ネットワークを介した伝送の用に供する。
【０００４】
既存のフレーマは一般に単一のフレーミング・プロトコルしか処理することができない。既存のフレーマは特定のプロトコル用の機能をすべて実行するから、当該特定のプロトコルに適合しない受信データ・ストリームは有効であると確認されない。同様に、送信データは単一の所定プロトコルに従ってしかフレーミングされない。また、所定のプロトコルには様々なデータ伝送速度に応じて変種が存在する場合が多い。フレーマは一般に目標データ伝送速度用に最適化されている。したがって、データ伝送速度が変わると通常、所望のデータ伝送速度の所定プロトコルに対応するようにフレーマの設定を手動で変更しなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
したがって、複数のフレーミング・プロトコルおよび／または複数のデータ伝送速度をサポートしうるフレーマを実現することは好都合である。
【課題を解決するための手段】
【０００６】
本発明はたとえばデータ伝送システムにおいて使用するマルチ・プロトコル・フレーマ（以下、単にフレーマともいう）を形成する手法を提供するものである。前記マルチ・プロトコル・フレーマは伝送媒体（たとえば光ファイバ・ネットワーク）から受信した入力データ・ストリームの特定のデータ伝送プロトコルを自動的に検出することができる。前記フレーマは、該フレーマが特定のプロトコルを検出したら、前記検出したプロトコルに従って、前記入力データ・ストリームから有効なデータを抽出し、および／または有効なデータをフレーミングして前記伝送媒体を介した伝送の用に供するように構成されている。したがって、本発明に係る手法を用いると、複数のデータ伝送プロトコルを自動的に処理しうるだけでなく、当該プロトコルを先験的に知っている必要を無くすことのできるデータ・フレーマを実現することができる。
【０００７】
本発明の一側面によると、送信元データ・ストリームに潜在する少なくとも２つの異なるデータ・フレーミング・プロトコルをサポートしうるデータ・フレーマは少なくとも２つのフレーミング回路および該フレーミング回路に接続されたコントローラを備えている。フレーミング回路の各々は前記各フレーミング回路に付随する異なるデータ・フレーミング・プロトコルに従って前記送信元データ・ストリームからユーザ・データを抽出するように構成されている。前記コントローラは適切に、(i) 前記送信元データ・ストリームを受信して少なくとも２つのデータ・フレーミング・プロトコルのうちのどちらが前記送信元データ・ストリームに対応しているかを自動的に判断し、(ii)前記送信元データ・ストリームの前記判断したデータ・フレーミング・プロトコルと前記第１のデータ・フレーミング・プロトコルおよび前記第２のデータ・フレーミング・プロトコルのうちの一方との間の一致に応答して、前記送信元データ・ストリームを前記第１のフレーミング回路および前記第２のフレーミング回路のうちの一方に転送する。
【発明を実施するための最良の形態】
【０００８】
本発明はマルチ・プロトコル・フレーマを形成する手法を提供するものである。ここでは、光ファイバ・ネットワークを介してデータを伝送するための次に示すプロトコル群を特に参照してマルチ・プロトコル・フレーマを説明する。すなわち、ＳＯＮＥＴ（synchronous optical network:光同期伝送網）／ＳＤＨ（synchronous digital hierarchy:同期ディジタル・ハイアラーキ）プロトコル、イーサネット(R)ＷＡＮ（wide area network)プロトコル、イーサネット(R)ＬＡＮ（local area network）プロトコル、ファイバ・チャネルＷＡＮプロトコル、およびファイバ・チャネルＬＡＮプロトコルである。しかしながら認識すべき点を挙げると、本発明はこれらの、またはすべての特定のデータ伝送プロトコルおよび／または通信媒体に限定されない。
【０００９】
ＳＯＮＥＴ標準の詳細はたとえばＡＮＳＩ（American National Standards Institute:米国規格協会）文書Ｔ１．１０５−１９９５、Ｔ１．１０５．０２−１９９５、Ｔ１．１０５．０４−１９９５、およびＴ１．１０５．０９−１９９６に記載されている。ＷＡＮ同期標準はたとえばＡＮＳＩ Ｔ１ＴＲ３ＧＰＰ ２７．１０３−３００に記載されている。同様に、ＬＡＮプロトコル標準の概要はたとえばＩＳＯ（International Organization for Standardization: 国際標準化機構）／ＩＥＣ（International Electrical Commission:国際電気標準会議）文書ＴＲ ８８０２−１：２００１、ＩＳＯ／ＩＥＣ １００３８−１９９３、ＩＥＥＥ（Institute of Electrical and Electronics Engineers:米国電気電子技術者協会）文書８０２．７−１９８９およびＩＥＥＥ ８０２．１ｑ−１９９８に記載されている。ファイバ・チャネル標準はたとえば「ファイバ・チャネル−物理的および信号的インタフェース（Fibre Channel - Physical and Signaling Interface) 」（ＡＮＳＩ Ｘ３．２３０−１９９４）に記載されている。したがって、ここでは既存のデータ伝送プロトコルの詳細な説明は提示しない。
【００１０】
フレーマを含むデータ伝送システムにおいて、送信元と送信先との間でデータを伝送するのに使用するフレーミング・フォーマットを決める１つの方法は、フレーマの外部からデータ伝送プロトコルを手動で設定することである。しかし、これには従来、送信元が使用しているプロトコルを先験的に知っている必要があった。また、入来するデータ・ストリームのプロトコルが変化したときには常に、入来するデータが有効であることを確認するために、フレーマに関連付けられた設定を入来するプロトコルに対応するように手動で変更する必要もある。
【００１１】
手動による介入なしに、そして送信元が使用しているデータ・フレーミング・プロトコルを先験的に知る必要なしにプロトコルを変更することを可能にするために、本発明は受信したデータ・ストリームのプロトコルを自動的に検出し、そのプロトコルが使用しているフレーミング・アーキテクチャを自動的に追跡する手法を提供する。フレーマの受信側でプロトコルを検出したら、その検出したプロトコルに対応するようにフレーマの送信側を自動的に設定することができる。このように、本発明に従って形成したフレーマは手動による介入なしに自身の動作を自動的に決定することができるから好都合である。また、本発明に係るデータ・フレーマはデータ・フレーミング・プロトコルをユーザ選択可能な制御信号に応じて変更する能力も備えている。
【００１２】
図１は本発明に従って形成した典型的なデータ伝送システムを示す図である。図示したデータ伝送システム１００はＣＤＲ（clock and data recovery:クロックとデータの復元）回路１０２、一対のマルチ・プロトコル高速フレーマ１０４、１０６、一対の媒体アクセス制御（media access controller:ＭＡＣ）１１２、１１４、およびスイッチャ／ルータ１１６を備えているのが望ましい。ＣＤＲ回路１０２は伝送媒体、たとえばデータを伝送する光ファイバ・ネットワーク１１８に接続されている。ＣＤＲ回路１０２は入来するデータ・ストリームまたは外出するデータ・ストリームをそれぞれ少なくとも部分的に、適切に直列化し、および／または非直列化する。システムの受信側では、一方のフレーマ１０４がＣＤＲ回路１０２から入力データ・ストリーム１２０を受信するように適切に構成されている。入力データ・ストリーム１２０は複数の未決プロトコルのうちの１つのデータ・フレームから成る。システムの送信側では、他方のフレーマ１０６がＣＤＲ回路１０２へ出力データ・ストリーム１２２を送信するように適切に構成されている。入力データ・ストリーム１２０と同様に、出力データ・ストリーム１２２は複数のプロトコルのうちの１つのデータ・フレームから成り、入力データ・ストリームのプロトコルと一致しているのが望ましい。
【００１３】
受信側では、マルチ・プロトコル・フレーマ１０４は入力データ・ストリーム１２０のプロトコルを自動的に検出し、そこから有効なデータを抽出するように構成されているのが望ましい。プロトコルが確認できたら、検出したプロトコルに対応する所定のフレーム内で、有効なデータを容易に突き止めることができる。フレーマ１０４はＳＯＮＥＴ／ＳＤＨ型のデータをスイッチャ／ルータ１１６に供給して伝送の用に供する第１の出力１２４を備えているのが望ましい。また、フレーマ１０４はイーサネット(R)／ファイバ・チャネル型のデータをＭＡＣ（媒体アクセス制御）１１２に供給する第２の出力１３０も備えているのが望ましい。ＭＡＣ１１２はスイッチャ／ルータ１１６に適切に接続されている。ＭＡＣ１１２はシステム内のスイッチ・ルーティングを評価するように少なくとも部分的に機能する。
【００１４】
送信側では、マルチ・プロトコル・フレーマ１０６はスイッチャ／ルータ１１６からＳＯＮＥＴ／ＳＤＨ型データ１２６を直接に、またはＭＡＣ１１４を介してスイッチャ／ルータ１１６からイーサネット(R)／ファイバ・チャネル型データ１２８を受信するように構成されているのが望ましい。いずれの場合でも、スイッチャ／ルータ１１６から受信するデータは、受信側のマルチ・プロトコル・フレーマ１０４が検出したプロトコルを用いて送信側のマルチ・プロトコル・フレーマ１０６がフレーミングしたものであるのが望ましい。次いで、フレーミングしたデータは出力データ・ストリーム１２２としてＣＤＲ回路１０２に送り、光ファイバ・ネットワーク１１８を介して送信先へ伝送する。
【００１５】
次に、図２を参照する。図２は本発明の一側面に従い受信側のオペレーション用に構成されたマルチ・プロトコルの高速フレーマを示す図である。説明を容易するために、マルチ・プロトコル・フレーマ２００はいくつかの機能ブロック、たとえばプロトコル追跡・フレーム同期エンジン２０２、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４、およびイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８で構成されているのが望ましい。認識すべき点を挙げると、これらの機能ブロックの各々はそれに対応する個別回路、たとえばＤＳＰ（digital signal processor）または等価の処理装置で実現することができる。あるいは、単一の回路を用いて複数の機能ブロックを実現することもできる。また、当業者が理解しうるように、本発明によれば、フレーマに付随する少なくとも１つの機能ブロックをプロセッサで実行するソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせで実現することも考えられる。
【００１６】
プロトコル追跡・フレーム同期エンジン２０２はたとえば光ファイバ・ネットワークからそれに提供される入力データ・ストリーム２２６を受信し、その入力データ・ストリーム中にフレーム同期パターンがないか検索するのが望ましい。たとえば、ＷＡＮプロトコルの場合、データ・ストリームは同期トランスポート信号（ＳＴＳ）の開始を示すフレーミング・バイトＡ１、Ａ２を含んでいる。あるいは、ＬＡＮプロトコルの場合、データ・ストリームはＬＡＮ型データ・フレームの開始を示す６６ビットごとの０１／１０ビット・シーケンスを含んでいる。プロトコル追跡・フレーム同期エンジン２０２は複数のステート・マシン２１０、２１２を備えているのが望ましい。ステート・マシン２１０、２１２の各々は入力データ・ストリーム２２６から異なる所定のプロトコルを適切に検出するように構成されている。本発明によれば、プロトコル追跡・フレーム同期エンジン２０２に追加のステート・マシン（図示せず）を付加して、それに対応する追加のデータ伝送プロトコルを検出するようにすることも考えられる。これにより、フレーマのプロトコル検出機能が拡大する。
【００１７】
ステート・マシン２１０、２１２は各々、入力データ・ストリーム２２６を受信し、実質的に並列に動作し、入力データ・ストリームを実質的に走査し、それに付随する所定のプロトコル標準に従うデータ・フレームを検出するのが望ましい。並列に動作することにより、ステート・マシン２１０、２１２は入力データ・ストリームから未決のプロトコルをより迅速に検出することが可能になる。したがって、本発明に従って形成したデータ・フレーマの速度は顕著に改善されている。ステート・マシンの一方がその構成されたプロトコルに対応する特定のデータ・フレームを検出したら（当該ステート・マシンは「インフレーム（in-frame）」状態または「追跡（lock）」状態にあると言われる）、このインフレーム状態が終了するまで、他方のステート・マシンは無効にする、あるいはシャットオフする。不使用のステート・マシンを無効にすることにより、フレーマの消費電力を低減することができる。
【００１８】
プロトコル追跡・フレーム同期エンジン２０２がＷＡＮ型プロトコルの入力データ・ストリームを特定したら、ステート・マシン２１０（これはこの例ではデータ・ストリーム２２６からＷＡＮ型プロトコルを検出するのに使用している）は自身がインフレーム状態にあることを示す制御信号を生成するのが望ましい。ステート・マシン２１０が生成したインフレーム制御信号はステート・マシン２１２を適切に無効にし、および／または入力データ・ストリームをステート・マシン２１０に付随する引き続く処理回路に適切に転送するのに使用する。入力データ・ストリームのプロトコルを特定したら、インフレームのステート・マシン（たとえば２１０）は継続して入力データ・ストリーム２２６を定期的にモニタしインフレーム状態が継続しているか否かを判断するのが望ましい。認識すべき点を挙げると、ステート・マシンがインフレーム状態になり、データ伝送プロトコルが既知であることを示すと、検出したプロトコルに対応するフレーム境界は容易に判定することができる。したがって、当業者が理解しうるように、インフレーム状態が継続しているか否かを判断するには、ステート・マシンは予期するフレーム境界がないか入力データ・ストリームをモニタするだけでよい。
【００１９】
ステート・マシン２１０は以前にＷＡＮ型プロトコルとして特定された入力データ・ストリームを線２１４を介してＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４へ転送する。ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４は入来するデータ・ストリームがＳＯＮＥＴ／ＳＤＨプロトコルであるかＷＩＳ（WAN interface sublayer: ＷＡＮインタフェース副層）プロトコルであるかを判断する。これらは当業者に知られているように、それぞれＳＯＮＥＴ／ＳＤＨ標準とＷＩＳ標準（たとえばＡＮＳＩ Ｔ１．４１６−１９９９）によって規定されている。これを行うために、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４は入力データ・ストリーム中の少なくとも１つの所定バイト位置を検出するように構成されている。たとえば、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４は、ＳＯＮＥＴ／ＳＤＨプロトコルでは使用されているがＷＩＳプロトコルでは不使用で特定の論理レベル、たとえば論理“０”に設定されているいくつかのオーバーヘッド・バイトを適切に検出する。認識すへき点を挙げると、本発明によれば、特定のプロトコルを特定する、あるいは少なくとも２つのプロトコルを分別するのに別の手法を用いることもできる。
【００２０】
ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４に入来するデータ・ストリーム２１４が純粋のＳＯＮＥＴ／ＳＤＨプロトコルであると判断したら、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４は当該データ・ストリームをたとえば線２２２を介して引き続く処理回路（たとえば図１のスイッチャ／ルータ１１６）に転送するのが望ましい。あるいは、データ・ストリーム２１４がＳＯＮＥＴ／ＳＤＨプロトコルとして認識されない場合には、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４に含まれるＷＩＳブロック２２８が当該データ・ストリームを線２１８を介してステート・マシン２１２に転送し、さらなる処理の用に供する。ＷＩＳフレームは実質的に複数のイーサネット(R)／ファイバ・チャネル・フレームを含んでいるから、ＷＩＳデータ・ストリーム２１８はＬＡＮ型プロトコルに従ってさらに処理することができる。
【００２１】
プロトコル追跡・フレーム同期エンジン２０２が入力データ・ストリームがＬＡＮ型プロトコルであると特定したら、ステート・マシン２１２はインフレーム制御信号を生成するのが望ましい。ステート・マシン２１２が生成したインフレーム制御信号は上述したようにステート・マシン２１０と同一の方法で使用して、ステート・マシン２１０およびそれに付随するすべての不使用の回路（たとえばＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４）を適切に無効にし、および／または、データ・ストリームをステート・マシン２１２に付随する引き続く回路に転送する。上述したように、入力データ・ストリーム２２６のプロトコルを特定したら、インフレームのステート・マシン（たとえば２１２）は継続して定期的にデータ・ストリームをモニタしてインフレーム状態を継続しているか否かを判断するのが望ましい。
【００２２】
ステート・マシン２１２はＬＡＮ型プロトコルであるとすでに判断されたデータ・ストリームをイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に含まれるスクランブラ／デスクランブラ２０６に適切に転送する。スクランブラ／デスクランブラ２０６は、データ・ストリームにおいて十分なビット遷移（たとえば“０”から“１”へまたは“１”から“０”へ）を実現するために以前にスクランブルされた入来するフレームからペイロード・フィールドとオーバーヘッド・フィールドを抽出するように構成されているのが望ましい。当業者が理解しうるように、受信器フェーズ・ロック・ループを用いた光ファイバ・システムでは、受信器フェーズ・ロック・ループがジッタの少ない受信データからクロック信号を復元しうるように、データ・ストリームは一般に所定数のビット遷移を含むようにエンコードする必要がある。上述したように、ＷＩＳフレームは実質的に複数のイーサネット(R)／ファイバ・チャネル・フレームを含んでいるから、ＷＩＳデータ・ストリーム２１８はイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８によってさらに処理することができる。また、スクランブラ／デスクランブラ２０６はエラー検出および／またはエラー訂正のためにデータをエンコード／デコードする機能も備えている。たとえば、ＬＡＮ型プロトコルでは、受信データの６６ビットごとに実データは６４ビットしかない。したがって、デスクランブラは６６ビットのデータ・ストリーム２１６を６４ビットのデータ・ストリーム２２４に（たとえば６６ビット／６４ビット・デコーダを用いて）変換するように構成されているのが望ましい。
【００２３】
イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８は入来するデータ・ストリーム２１６がイーサネット(R)標準とファイバ・チャネル標準でそれぞれ規定されているイーサネット(R)・プロトコルであるのかファイバ・チャネル・プロトコルであるのかを判断するのが望ましい。イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８は次に示す様々な手法を用いてイーサネット(R)・プロトコルとファイバ・チャネル・プロトコルとを分別するように構成することができる。すなわち、順序付セット信号方式（ordered set signaling)、ＳＯＦ（start-of-file:ファイル開始）・ＥＯＦ（end-of-file:ファイル終了）認識方式、ＯＦＣ（open fiber control: 開放ファイバ制御）信号方式などである。これらについては下で詳述する。また、本発明で使用するのに好適な別の分別手法も同様に考えられる。
【００２４】
当業者が理解しうるように、ファイバ・チャネル・プロトコルの文脈における順序付セット（ordered set)はデータと第１の伝送キャラクタとしての特別キャラクタとを含む４バイトの伝送ワードである。順序付セットはたとえばフレーム・デリミタ、基本信号、基本シーケンスなどである。順序付セットを少なくとも部分的に使用すると、ファイバ・チャネル制御情報とデータとを区別しうるとともに、ビットとワードの同期をとる機能（これはワード境界の位置合わせの確立も行う）を実現することができる。ＩＥＥＥ標準８０２．３ａｅに従うフレーム信号方式（ＦＳＩＧ）は、ファイバ・チャネル・コードの順序付セットを送るのに使用されるとともに、常に特別なキャラクタＫ２８．２で開始する。順序付セットのバイト０の位置に存在するこの特別なキャラクタＫ２８．２は常にファイバ・チャネルの順序付セット・データ（たとえばＫ２８．２−Ｄｘ１．ｙ１−Ｄｘ２．ｙ２−Ｄｘ３．ｙ３）を示し、次いで適切なファイバ・チャネルの順序付セット（たとえばＫ２８．５−Ｄｘ１．ｙ１−Ｄｘ２．ｙ２−Ｄｘ３．ｙ３）に逆変換される。
【００２５】
イーサネット(R)・プロトコルとファイバ・チャネル・プロトコルとを区別する別の手法がＳＯＦ・ＥＯＦ認識方式である。フレーム・デリミタのＳＯＦとＥＯＦは所定フレームの内容の直前と直後にそれぞれ付される。ＳＯＦとＥＯＦはイーサネット(R)とファイバ・チャネルでは扱いが異なる。たとえば、ファイバ・チャネルでは、ＳＯＦおよびＥＯＦの双方用に特定の順序付セットを使用する。これに対して、イーサネット(R)では、ＳＯＦおよびＥＯＦ用に単一の制御キャラクタしか使用しない。また、ファイバ・チャネル・プロトコルでは４バイトの順序付セットを使用しているから、デリミタＳＯＦおよびＥＯＦ用の制御キャラクタは常に同じバイト位置に存在する。しかし、イーサネット(R)・プロトコルでは、同じバイト位置に存在するのはＳＯＦキャラクタのみであり、ＥＯＦキャラクタは任意のバイト位置に存在しうる。これらの相違点は、たとえば１０ギガヘンツ（ＧＨｚ）ファイバ・チャネル標準文書第１．０版第１４節第５３頁以降（２００１年３月１０日）、および１０ＧＨｚイーサネット(R)標準文書ＩＥＥＥ ８０２．３ａｅドラフト２．３第４８．３節第２９６頁以降に記載されている。
【００２６】
特に、イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に存在する６６ビット／６４ビット・デコーダ（図示せず）を出たバイトと、イーサネット(R)・プロトコルおよびファイバ・チャネル・プロトコルに固有の予期されるＳＯＦキャラクタおよびＥＯＦキャラクタとを実質的に同時に比較するのが望ましい。ＳＯＦ制御キャラクタとＥＯＦ制御キャラクタを適切に位置合わせしたファイバ・チャネルの順序付セットおよび／または順序付シーケンスを検出したら、イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に含まれるステート・マシンはＳＯＦ終端処理とＥＯＦ終端処理を適切に行ったデータ・パケットをカウントし始め、ユーザ設定可能なカウント値までカウントして偽ファイバ・チャネルを検出しえないようにするのが望ましい。ファイバ・チャネルのセットを検出しない場合、あるいはデータ・ストリーム中でファイバ・チャネル・プロトコル用とは違ったバイト位置すなわち予期しないバイト位置でＥＯＦ制御キャラクタを検出した場合、イーサネット(R)・データであると推定する。この例では、イーサネット(R)に固有のステート・マシンが、ＳＯＦキャラクタが適切なバイト位置にないか検索したのち、適切にフォーマットされたイーサネット(R)・パケットをユーザ設定可能な最大値までカウントし始めるのが望ましい。
【００２７】
本発明では、データ・ストリーム中の単一のパケット・エラーに起因する「グリッチ（glitch: 瞬間的な異常）」および／または他の異常の影響をフレーマがあまり受けないように、上述した最大カウント値を使用してプロトコル決定プロセスにヒステリシスを実現するのが望ましい。本発明によれば、このようなヒステリシスの実現に様々な手法を用いることができる。たとえば、イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に「有効パケット」カウンタ（図示せず）を備える。この有効パケット・カウンタは所定のカウント値に初期化する。ある期間経過後、イーサネット(R)またはファイバ・チャネルのＳＯＦおよび／またはＥＯＦのフォーマットがエラーであることが分かった場合、有効パケット・カウンタに付随するカウント値を１だけインクリメントまたはデクリメントして、単一のパケット・エラーではイーサネット(R)／ファイバ・チャネル決定プロセスが不所望に「グリッチ」する、すなわち別のプロトコルを使用するように切り替えることがないようにする。また、当業者が理解しうるように、有効パケット・カウンタとともに比較器（図示せず）を用いてカウンタの値と所定のカウント値とを比較して、プロトコルを変更する必要があるか否か（たとえば許容できない個数のパケット・エラーが検出されたか否か）を判断してもよい。さらに本発明によれば、エラー・レートが十分に低いプロトコルが見つからない場合、フレーマは特定のプロトコルに付随する標準によって決められた方法またはユーザが決めた方法で、ＬＯＬ（loss of link: リンク損失）を表示する。
【００２８】
認識すべき点を挙げると、上述したものの他に本発明のプロトコル決定機能およびプロトコル切り替え機能を実現するために使用しうる様々な方法が存在する。たとえば、本発明の別の側面によれば、イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８ははじめにファイバ・チャネル・プロトコルを探索するのではなく、はじめにイーサネット(R)・プロトコルを探索してもよい。こうするためには、イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８をＥＯＦ制御キャラクタの変動しうる位置を検出しうるように構成する。あるいは、ＳＯＦとイーサネット(R)のプリアンブル・キャラクタとを用いて、ファイバ・チャネル・プロトコルに対応するＳＯＦの順序付セットの定義とは異なる独自の疑似順序付セット（pseudo-ordered set）を規定してもよい。
【００２９】
また上述したように、本発明によれば、ＯＦＣ信号手法を用いてイーサネット(R)・プロトコルとファイバ・チャネル・プロトコルとを分別してもよい。ＯＦＣ信号手法はデータ伝送システム１００のＣＤＲ回路（図１参照）で使用するが、単一のファイバを介して複数のデータ・ストリームを伝送する８５０ナノメートル（ｎｍ）の波長分割多重（ＷＤＭ）型ファイバ・チャネル・リンクを構築する際に使用するＯＦＣに依存している。たとえばＯＦＣ機能の場合、ファイバ・チャネル・リンクは、高速フロント・エンド回路が生成しＣＤＲ回路１０２のＯＦＣ回路が処理する信号を用いてレーザ対応信号（たとえばＬａｓｅｒ＿Ｅｎ）を生成する。当業者が理解しうるように、このレーザ対応信号は高速フロント・エンド回路が信号を検出するときには“Ｈ”論理レベルである。イーサネット(R)・プロトコルもＳＯＮＥＴプロトコルもこの信号を使用していないから、レーザ対応信号が“Ｈ”論理レベルになるリンクはすべて自動的にファイバ・チャネル・リンクであると考えられる。
【００３０】
例示のみを目的として、図３は本発明により、入来するデータ・ストリームのプロトコルを判断するために図２のマルチ・プロトコル・フレーマが用いる判定ツリー３００を示す図である。上述したように、入来するデータ・ストリームがＷＡＮ型プロトコルであるかＬＡＮ型プロトコルであるかをノード３０２で判断する。ＷＡＮ型プロトコルを検出したら，フレーマはそのＷＡＮ型プロトコルのデータ・ストリーム３２０をノード３０４へ転送する。ノード３０４では、データ・ストリーム３２０がＳＯＮＥＴ／ＳＤＨプロトコルであるかＷＩＳプロトコルであるかを判断する。ＳＯＮＥＴ／ＳＤＨプロトコルを検出したら、ＳＯＮＥＴ／ＳＤＨ型データ・ストリーム３１０を所定の送信先へ転送する。同様に、ノード３０４で、データ・ストリーム３２０がＷＩＳプロトコルであると判断したら、ＷＩＳプロトコル型データ・ストリーム３２４をノード３０８へ転送し、さらなる処理の用に供する。ノード３０８では、データ・ストリーム３２４がイーサネット(R)・プロトコルであるかファイバ・チャネル・プロトコルであるかを適切に判断する。ノード３０８で受信するデータ・ストリームは以前にＷＡＮ型プロトコルであると判断されているから、ノード３０８はイーサネット(R)ＷＡＮプロトコル型データ・ストリーム３１６、またはファイバ・チャネルＷＡＮプロトコル型データ・ストリーム３１８を各所定の送信先へ出力する。
【００３１】
ノード３０２で入来するデータ・ストリームがＬＡＮ型プロトコルであると判断したら、そのＬＡＮ型プロトコルのデータ・ストリーム３２２をノード３０６へ転送してさらなる処理の用に供する。ノード３０６では、データ・ストリーム３２２がイーサネット(R)・プロトコルであるかファイバ・チャネル・プロトコルであるかを判断する。ノード３０６で受信するデータ・ストリームは以前にＬＡＮ型プロトコルであると判断されているから、ノード３０６はイーサネット(R)ＬＡＮプロトコル型データ・ストリーム３１２、またはファイバ・チャネルＬＡＮプロトコル型データ・ストリーム３１４を各所定の送信先へ出力する。認識すべき点を挙げると、ノード３０６と３０８は各々、所定のデータ・ストリームに対してイーサネット(R)・プロトコルとファイバ・チャネル・プロトコルとを分別するように少なくとも部分的に機能する。したがって、ノード３０６と３０８は同じまたは同様の機能ブロック（たとえば図２のブロック２０８）で実現することができる。
【００３２】
本発明に係るマルチ・プロトコル・フレーマが処理するプロトコルの個数と種別が変化すると、それに合わせて判定ツリー３００も変化する。また、当業者が理解しうるように、図示した判定ツリー３００と同じように送信側オペレーション用に構成した判定ツリーもマルチ・プロトコル・フレーマ用に規定することができる。
【００３３】
次に、図４を参照する。図４は送信側オペレーション用に構成した本発明によるマルチ・プロトコル高速フレーマ４００を示す図である。マルチ・プロトコル・フレーマ４００は図２に示した受信側のマルチ・プロトコル・フレーマと同様に、プロトコル追跡・フレーム同期エンジン２０２、ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４、およびイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８を備えている。認識すべき点を挙げると、これらの機能ブロックの各々はそれに対応する個別回路、たとえばＤＳＰ（digital signal processor）などで実現することができる。あるいは、単一の回路を用いて複数の機能ブロックを実現することもできる。また当業者が理解しうるように、本発明によれば、フレーマに付随する少なくとも１つの機能ブロックを、プロセッサ上で実行するソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせで実現することができる。
【００３４】
送信オペレーションの間、マルチ・プロトコル・フレーマ４００はＳＯＮＥＴ／ＳＤＨ型の送信元に由来する第１のデータ・ストリーム４０２とイーサネット(R)／ファイバ・チャネル型の送信元に由来する第２のデータ・ストリーム４０４とを（必ずしも同時並行的ではなく）受信する。第１のデータ・ストリーム４０２はＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４に転送する。ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４は受信したデータを適切に処理してＳＯＮＥＴ／ＳＤＨプロトコル型出力データ・ストリーム４０８を生成する。プロトコル追跡・フレーム同期エンジン２０２に含まれている第１のステート・マシン２１０はＷＡＮ型プロトコルに従ってデータを処理するように構成されているのが望ましい。ステート・マシン２１０はＳＯＮＥＴ／ＳＤＨプロトコル型データ・ストリーム４０８を受信しＷＡＮ型プロトコルのフレームを生成して光ファイバ・ネットワーク４１４（または別の通信媒体）を介した所定送信先への送信の用に供する。
【００３５】
イーサネット(R)／ファイバ・チャネル型の送信元に由来するデータ・ストリーム４０４はイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に転送する。イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８は受信したデータを適切に処理してイーサネット(R)／ファイバ・チャネル・プロトコル型の出力データ・ストリーム４０６を生成する。イーサネット(R)／ファイバ・チャネル・プロトコル型データ・ストリーム４０６はイーサネット(R)／ファイバ・チャネル・フレーミング・ブロック２０８に含まれているスクランブラ／デスクランブラ２０６でエンコードして、当該データ・ストリーム中に十分なビット遷移（たとえば“０”から“１”へまたは“１”から“０”へ）を実現するのが望ましい。このプロセスは「スクランブル」と呼ばれている。上述したように、受信器フェーズ・ロック・ループを用いた光ファイバ・システムでは、データ・ストリームは一般に所定数のビット遷移を含むようにエンコードし、受信器フェーズ・ロック・ループがジッタの少ない受信データからクロック信号を復元しうるようにする必要がある。
【００３６】
（たとえば受信側フレーマまたは送信元データ・ストリーム自身が判断した結果）送信元データ・ストリーム４０４の送信先プロトコルがＷＡＮ型プロトコルである場合、スクランブラ／デスクランブラ２０６はエンコード済みイーサネット(R)／ファイバ・チャネル・プロトコル型データ・ストリームを生成する。このデータ・ストリームはプロトコル追跡・フレーム同期エンジン２０２に含まれる第２のステート・マシン２１２を通じてＳＯＮＥＴ／ＳＤＨフレーミング・ブロック２０４に含まれるＷＩＳブロック２２８に転送するのが望ましい。ＷＩＳブロック２２８は受信したデータ・ストリーム４１０をＷＩＳプロトコルに従って処理する。そして、ＳＯＮＥＴ／ＳＤＨブロック２０４がさらに処理してＳＯＮＥＴ／ＳＤＨプロトコル型の出力データ・ストリーム４０８を生成する。このＳＯＮＥＴ／ＳＤＨプロトコル型データ・ストリーム４０８はステート・マシン２１０が受信し、ＷＡＮ型プロトコルのフレームを生成して光ファイバ・ネットワーク４１４を介した所定送信先への伝送の用に供する。ステート・マシン２１２が出力したデータ・ストリームを光ファイバ・ネットワーク４１４またはＷＩＳブロック２２８へ選択的に転送しうるように、フレーマ４００にはマルチプレクサ（ＭＵＸ）４１２が設けられている。また、（たとえばステート・マシン２１２が出す）ＬＡＮ型データ・ストリームまたは（たとえばステート・マシン２１０が出す）ＷＩＳ型データ・ストリームを光ファイバ・ネットワーク４１４へ選択的に転送しうるように第２のＭＵＸ４１６も設けられている。
【００３７】
送信元データ・ストリーム４０４がＬＡＮ型プロトコルである場合、スクランブラ／デスクランブラ２０６はエンコード済みイーサネット(R)／ファイバ・チャネル・プロトコル型データ・ストリーム４０６を生成する。このデータ・ストリーム４０６はプロトコル追跡・フレーム同期エンジン２０２に含まれる第２のステート・マシン２１２に転送する。第２のステート・マシン２１２はＬＡＮ型プロトコルでデータを処理するのが望ましい。第２のステート・マシン２１２はエンコード済みイーサネット(R)／ファイバ・チャネル・プロトコル型データ・ストリーム４０６を受信して適切なＬＡＮ型プロトコルのフレームを生成し、光ファイバ・ネットワーク４１４を介した所定送信先への伝送の用に供する。この例では、出力データ・ストリームはＷＩＳブロック２２８を通過してさらなる処理を受けることはない。
【００３８】
認識すへき点を挙げると、上述したように、送信オペレーションの間に出力すべきプロトコルは受信側フレーマに付随するステート・マシンが生成する制御信号（たとえばインフレーム制御信号）または他の手段によって決まる。あるいは当業者が理解しうるように、本発明によれば、送信先プロトコルに関する情報はフレーマ４００が受信する入来データ・ストリーム中にエンコードすることも考えられる。また、送信側フレーマ４００が使用するプロトコルはユーザ選択可能である。
【００３９】
図面ではマルチ・プロトコル・フレーマが特定のプロトコルに対応する、プロトコル固有の機能ブロックを備えているものとして示したが、これらのブロックのうちの少なくとも１つを複数のプロトコルが共用してもよい。たとえば、スクランブラ／デスクランブラはプロトコルに無関係であるのが望ましいから、受信した各プロトコル用に使用することができる。同様に、エンコーダ／デコーダ機能は（たとえばファイバ・チャネル・プロトコルにおける）マッピング制御順序付セットや（たとえばイーサネット(R)・プロトコルにおける）マッピング制御キャラクタなどの小さな変更を除いて実質的に同一である。したがって、これらのプロトコルのデコードおよび／またはエンコードは僅かな変更を加えた同じハードウェアを用いて行うことができる。
【００４０】
また、入来するデータ・ストリームのプロトコルが分かったら、不使用プロトコルに付随する機能ブロックはパワーダウンするか、無効にできる点が好都合である。これにより、フレーマの全消費電力を顕著に低減することができる。たとえば、ＷＩＳフレームのオーバーヘッドはＳＯＮＥＴ／ＳＤＨのオーバーヘッドの一部である。したがって、イーサネット(R)／ファイバ・チャネルＷＡＮ型データ・ストリームを受信している間、ＳＯＮＥＴ／ＳＤＨ機能ブロックの少なくとも一部を無効にすることができる。
【００４１】
受信したデータ・ストリームのプロトコルに関する情報は（たとえばデータ・リンク層における）引き続くデータ処理に使用できるから、本発明の別の側面によるマルチ・プロトコル・フレーマは検出したプロトコルに付随する情報を、たとえばさらなるプロトコル固有の処理を可能にするように提示するように構成されているのが望ましい。これはたとえばシリアル管理インタフェース（たとえばＭＤＩＯ（multiplexed data input/output)／ＭＤＣ（multiplexed data clock）インタフェース）を介して、あるいはインタフェースにおいて、コード済みのデータを使用している場合にはインバンド（in-band)を介して実現することができる。すべてのデータをＩＰ（Internet Protocol)フォーマットで伝送する場合には、送信側を適切な出力フォーマットにスイッチすることができる。様々なプロトコルが出すＩＰデータを１つのスイッチに適切に供給することができるのは、スイッチ入力にＦＩＦＯ（first-in first-out）バッファ（または等価のバッファ装置）が備わっている場合である。バッファリングすることにより、データ・フレーマは入来するデータ・ストリームのデータ伝送速度の小さな偏差を処理することが可能になる。当業者が理解しうるように、所定のプロトコルのデータ伝送速度の許容できる偏差はたとえば特定のプロトコルに対応する標準に記載されている。
【００４２】
図１とともに上述したＣＤＲ回路について。光ファイバ・ネットワークに由来するデータをフレーマが受信する前に、入来するデータ・ストリームのクロックとデータを復元する必要がある。下の表１に示すように、ここで述べた様々なプロトコルのデータ伝送速度は異なるが、本発明に係るマルチ・プロトコル・フレーマはそれらを復元することができる。
【００４３】
【表１】
【００４４】
表１において、「ＸＡＵＩ」なる用語は１０ギガビット・アタッチメント・ユニット・インタフェースのことである。また、すべてのデータ伝送速度の単位はギガビット毎秒（Ｇｂｓ）である。フレーマが適切に機能するように、ＣＤＲ回路はこの範囲内のすべての周波数を追跡しうるように構成する必要がある。また、マルチ・プロトコル・フレーマに追加のプロトコルおよび／またはデータ伝送速度を含める場合には、ＣＤＲ回路はそれら追加の周波数もカバーするように構成する必要がある。
【００４５】
ＣＤＲ回路が問題の周波数範囲で動作しうることを保証するために用いうる様々な方法がある。１つの手法はたとえばＰＬＬ（phase lock loop)回路を備えることにより入来する周波数を自動的に追跡しうるようにＣＤＲ回路を構成することである。別の実施形態では、選定する周波数範囲として狭い帯域幅を複数備えるようにＣＤＲ回路を構成してもよい。当業者が理解しうるように、マルチ・プロトコル・フレーマがＣＤＲ回路から受信するデータ・ストリームに有用な情報が何もない場合には、ＣＤＲ回路における周波数帯域幅の変更を指令してＣＤＲ回路が入来する周波数を追跡しうるように本発明に係るフレーマを構成してもよい。この手順はフレーマがデータ・ストリーム中に、サポートされているプロトコル群のうちの１つに対する有効なフレーミング・シーケンスを検出するまで繰り返すことができる。
【００４６】
図５に示すように、ここで説明した本発明に係るマルチ・プロトコル高速フレーマはコントローラまたはプロセッサ５０２、メモリ５０４、およびユーザ・インタフェース５０６を備えた処理装置５００によって全体的にあるいは部分的に実現することができる。認識すべき点を挙げると、ここで使用している「プロセッサ」なる用語はすべての処理装置、たとえば中央処理装置（ＣＰＵ）および／または処理回路（たとえばＤＳＰ（digital signal processor）、マイクロプロセッサ、コントローラなど）を備えたものを意味している。また、理解すべき点を挙げると、「プロセッサ」なる用語は複数の処理装置を指し、１つの処理装置に付随する様々な構成要素を他の処理装置が共用してもよい。ここで使用する「メモリ」なる用語はプロセッサ（すなわちＣＰＵ）に付随するメモリおよび他のコンピュータ読み取り可能な媒体、たとえばＲＡＭ（random access memory）、ＲＯＭ（read only memory）、固定記憶媒体（たとえばハード・ディスク駆動装置）、着脱可能記憶媒体（たとえばディスケット）、フラッシュ・メモリなどを含むことを意図している。さらに、ここで使用する「ユーザ・インタフェース」なる用語はたとえばプロセッサにデータを入力する少なくとも１つの入力装置（たとえばキーボード、マウスなど）および／またはプロセッサに付随する結果を表示する少なくとも１つの出力装置（たとえばモニタなど）を含むことを意図している。
【００４７】
したがって、本発明に係る方法を実行する命令またはコードを含むアプリケーション・プログラム（またはそのソフトウェア・コンポーネント）は付随する少なくとも１つの記憶媒体（たとえばＲＯＭ、固定記憶装置、着脱可能記憶装置など）に格納することができ、使用すべきときには（たとえばＲＡＭに）全体的または部分的にロードし、プロセッサ５０２によって実行することができる。いずれにしても、認識すべき点を挙げると、図１と図２に示した構成要素のうちの少なくとも１つは様々な形態のハードウェア、ソフトウェア、またはそれらの組み合わせ、たとえば付随するメモリ、ＡＳＩＣ（application-specific integrated circuit)、機能回路などを備えた少なくとも１つのＤＳＰ（digital signal processor）として実現することができる。
【００４８】
以上、図面を参照して本発明の実施形態を説明したが、理解すべき点を挙げると、本発明はそれら正確な実施形態に限定されず、特許請求の範囲の範囲の内で当業者は様々な他の変形と変更をなしうる。
【図面の簡単な説明】
【００４９】
【図１】本発明に係るマルチ・プロトコル高速フレーマのシステム構成を示すブロック図である。
【図２】本発明の一側面に従って形成した受信側マルチ・プロトコル・フレーマを示すブロック図である。
【図３】本発明により、入来するデータ・ストリームのプロトコルを判断する、図２に示すマルチ・プロトコル・フレーマが使用する典型的な判定ツリーを示すブロック図である。
【図４】本発明に従って形成した送信側マルチ・プロトコル・フレーマを示すブロック図である。
【図５】本発明に係る方法を実現する一般化したデータ処理システムを示すブロック図である。
【符号の説明】
【００５０】
１００ データ伝送システム
１０２ ＣＤＲ回路
１０４ マルチ・プロトコル高速フレーマ
１０６ マルチ・プロトコル高速フレーマ
１１２ 媒体アクセス制御（ＭＡＣ）
１１４ 媒体アクセス制御（ＭＡＣ）
１１６ スイッチャ／ルータ
１１８ 光ファイバ・ネットワーク
１２０ 入力データ・ストリーム
１２２ 出力データ・ストリーム
１２４ 第１の出力
１２６ ＳＯＮＥＴ／ＳＤＨ型データ
１２８ イーサネット(R)／ファイバ・チャネル型データ
１３０ 第２の出力
２００ マルチ・プロトコル・フレーマ
２０２ プロトコル追跡・フレーム同期エンジン
２０４ ＳＯＮＥＴ／ＳＤＨフレーミング・ブロック
２０６ スクランブラ／デスクランブラ
２０８ イーサネット(R)／ファイバ・チャネル・フレーミング・ブロック
２１０ ステート・マシン
２１２ ステート・マシン
２１４ 入力データ・ストリーム
２１６ データ・ストリーム
２１８ データ・ストリーム
２２４ データ・ストリーム
２２８ ＷＩＳ
３１０ ＳＯＮＥＴ／ＳＤＨ型データ・ストリーム
３１２ イーサネット(R)ＬＡＮプロトコル型データ・ストリーム
３１４ ファイバ・チャネルＬＡＮプロトコル型データ・ストリーム
３１６ イーサネット(R)ＷＡＮプロトコル型データ・ストリーム
３１８ ファイバ・チャネルＷＡＮプロトコル型データ・ストリーム
３２０ ＷＡＮ型プロトコルのデータ・ストリーム
３２２ ＬＡＮ型プロトコルのデータ・ストリーム
３２４ ＷＩＳプロトコル型データ・ストリーム
４００ マルチ・プロトコル・フレーマ
４０２ 第１のデータ・ストリーム
４０４ 第２のデータ・ストリーム
４０６ イーサネット(R)／ファイバ・チャネル・プロトコル型出力データ・ストリーム
４０８ ＳＯＮＥＴ／ＳＤＨプロトコル型出力データ・ストリーム
４１０ データ・ストリーム
４１２ マルチプレクサ（ＭＵＸ）
４１４ 光ファイバ・ネットワーク
４１６ マルチプレクサ（ＭＵＸ）
５００ 処理装置
５０２ コントローラまたはプロセッサ
５０４ メモリ
５０６ ユーザ・インタフェース
【特許請求の範囲】
【請求項１】
送信元データ・ストリームに潜在する少なくとも２つの異なるデータ・フレーミング・プロトコルをサポートしうるデータ・フレーマであって、
前記少なくとも２つのデータ・フレーミング・プロトコルのうちの第１のものに従って前記送信元データ・ストリームからユーザ・データを選択的に抽出するように構成された第１のフレーミング回路と、
前記少なくとも２つのデータ・フレーミング・プロトコルのうちの第２のものに従って前記送信元データ・ストリームからユーザ・データを選択的に抽出するように構成された第２のフレーミング回路と、
前記第１のフレーミング回路、少なくとも第２のフレーミング回路、および少なくとも１つのコントローラに接続されたコントローラであって、前記第１のフレーミング回路および前記第２のフレーミング回路が、（i)前記送信元データ・ストリームを受信して前記少なくとも２つの異なるデータ・フレーミング・プロトコルのうちのどれが前記送信元データ・ストリームに対応するかを自動的に判断し、（ii) 前記送信元データ・ストリームの前記判断したデータ・フレーミング・プロトコルと前記第１のデータ・フレーミング・プロトコルおよび前記第２のデータ・フレーミング・プロトコルのうちの一方との一致に応答して、前記送信元データ・ストリームを前記第１のフレーミング回路および前記第２のフレーミング回路のうちの一方に転送する、コントローラと
を備えた
データ・フレーマ。
【請求項２】
前記フレーミング回路の各々が少なくとも１つのステート・マシンを備え、
前記少なくとも１つのステート・マシンが、前記送信元データ・ストリームに対応するデータ・フレーミング・プロトコルがそれに付随するデータ・フレーミング・プロトコルと実質的に一致するか否かを判断し、
前記少なくとも１つのステート・マシンの各々がそれに対応する異なる個別のデータ・フレーミング・プロトコルを備えている、
請求項１に記載のデータ・フレーマ。
【請求項３】
前記フレーミング回路に付随する前記ステート・マシンの各々が、前記送信元データ・ストリームに対応するデータ・フレーミング・プロトコルを実質的に同時並行的に確認する、
請求項２に記載のデータ・フレーマ。
【請求項４】
前記コントローラが、前記送信元データ・ストリームに対応する判断済みデータ・プロトコルと一致しないデータ・フレーミング・プロトコルに付随する少なくとも１つのステート・マシンを適切に無効にするように構成されている、
請求項２に記載のデータ・フレーマ。
【請求項５】
前記第１のデータ・フレーミング・プロトコルがＷＡＮ型プロトコルであり、
前記第２のデータ・フレーミング・プロトコルがＬＡＮ型プロトコルである、
請求項１に記載のデータ・フレーマ。
【請求項６】
前記第１のデータ・フレーミング・プロトコルがＳＯＮＥＴ／ＳＤＨ型プロトコルであり、
前記第２のデータ・フレーミング・プロトコルがイーサネット(R)型プロトコルおよびファイバ・チャネル型プロトコルのうちの一方である、
請求項１に記載のデータ・フレーマ。
【請求項７】
さらに、
前記コントローラと前記第１のフレーミング回路および前記第２のフレーミング回路のうちの少なくとも一方との間に適切に接続されたスクランブラ／デスクランブラを備え、
前記スクランブラ／デスクランブラが、
第１のモードのオペレーションにおいて、送信先データ・ストリームに所定のビット遷移を選択的に挿入するように構成されており、
第２のモードのオペレーションにおいて、前記送信元データ・ストリームから所定のビット遷移を選択的に除去するように構成されている、
請求項１に記載のデータ・フレーマ。
【請求項８】
前記コントローラがさらに適切に、
（iii)前記フレーミング回路のうちの少なくとも１つのものの状態を検出し、前記少なくとも１つのフレーミング回路が、前記送信元データ・ストリームの前記判断したデータ・フレーミング・プロトコルに対応し予期されるフレーム境界がないか前記送信元データ・ストリームをモニタし、
（iv) 前記予期されるフレーム境界が、前記モニタした送信元データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記送信元データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定める、
請求項１に記載のデータ・フレーマ。
【請求項９】
前記コントローラがさらに適切に、
（iii)前記フレーミング回路のうちの少なくとも１つのものの状態を検出し、前記少なくとも１つのフレーミング回路が、前記送信元データ・ストリームの前記判断したデータ・フレーミング・プロトコルに対応し予期されるフレーム境界がないか前記送信元データ・ストリームをモニタし、
（iv) 前記予期されるフレーム境界が、前記送信元データ・ストリームの所定数の連続フレームに対して、前記モニタした送信元データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記送信元データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定める、
請求項１に記載のデータ・フレーマ。
【請求項１０】
前記コントローラがさらに、前記データ・フレーマに提示されるユーザ選択可能な制御信号に応答して、前記データ・フレーマのデータ・フレーミング・プロトコルを変更するように構成されている、
請求項１に記載のデータ・フレーマ。
【請求項１１】
送信元と送信先との間でデータを伝送する方法であって、
前記送信元から入力データ・ストリームを受信するステップと、
前記入力データ・ストリームに潜在する少なくとも２つのデータ・フレーミング・プロトコルから前記入力データ・ストリームに対応するデータ・フレーミング・プロトコルを自動的に決定するステップと、
第１のモードのオペレーションにおいて、前記入力データ・ストリームに対応する前記決定したデータ・フレーミング・プロトコルに従ってデータを抽出するステップと、
第２のモードのオペレーションにおいて、前記入力データ・ストリームに対応する前記決定したデータ・フレーミング・プロトコルに従ってデータをフレーミングするステップと
を備えた
方法。
【請求項１２】
さらに、
前記入力データ・ストリームの前記決定したデータ・フレーミング・プロトコルに対応する予期されるフレーム境界がないか前記入力データ・ストリームをモニタするステップと、
前記予期されるフレーム境界が、前記モニタした入力データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記入力データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定めるステップと
を備えた、
請求項１１に記載の方法。
【請求項１３】
さらに、
前記入力データ・ストリームの前記決定したデータ・フレーミング・プロトコルに対応する予期されるフレーム境界がないか前記入力データ・ストリームをモニタするステップと、
前記予期されるフレーム境界が、前記入力データ・ストリームの所定数の連続フレームに対して、前記モニタした入力データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記入力データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定めるステップと
を備えた、
請求項１１に記載の方法。
【請求項１４】
前記データ・フレーミング・プロトコルのうちの第１のものがＷＡＮ型プロトコルであり、
前記データ・フレーミング・プロトコルのうちの第２のものがＬＡＮ型プロトコルである、
請求項１１に記載の方法。
【請求項１５】
前記データ・フレーミング・プロトコルのうちの第１のものがＳＯＮＥＴ／ＳＤＨ型プロトコルであり、
前記データ・フレーミング・プロトコルのうちの第２のものがイーサネット(R)型プロトコルおよびファイバ・チャネル型プロトコルのうちの一方である、
請求項１１に記載の方法。
【請求項１６】
さらに、
第１のモードのオペレーションにおいて、出力データ・ストリームに少なくとも１つの所定のビット遷移を選択的に挿入するステップと、
第２のモードのオペレーションにおいて、前記入力データ・ストリームから少なくとも１つの所定のビット遷移を選択的に除去するステップと
を備えた、
請求項１１に記載の方法。
【請求項１７】
送信元と送信先との間でデータを伝送する装置であって、前記装置は送信元データ・ストリームに潜在する少なくとも２つの異なるデータ・フレーミング・プロトコルをサポートすることができ、
適切に、
（i)前記送信元データ・ストリームを受信し、
（ii) 前記送信元データ・ストリームに対応するデータ・フレーミング・プロトコルを自動的に決定し、
(iii)第１のモードのオペレーションにおいて、前記送信元データ・ストリームに対応する前記決定したデータ・フレーミング・プロトコルに従ってデータを抽出し、
(iv) 第２のモードのオペレーションにおいて、前記送信元データ・ストリームに対応する前記決定したデータ・フレーミング・プロトコルに従ってデータをフレーミングする
少なくとも１つのプロセッサを備えている
装置。
【請求項１８】
前記少なくとも１つのプロセッサがさらに適切に、
(v) 前記送信元データ・ストリームの前記決定したデータ・フレーミング・プロトコルに対応し予期されるフレーム境界がないか前記送信元データ・ストリームをモニタし、
(vi)前記予期されるフレーム境界が、前記モニタした送信元データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記送信元データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定める、
請求項１７に記載の装置。
【請求項１９】
前記少なくとも１つのプロセッサがさらに適切に、
(v) 前記送信元データ・ストリームの前記決定したデータ・フレーミング・プロトコルに対応し予期されるフレーム境界がないか前記送信元データ・ストリームをモニタし、
(vi)前記予期されるフレーム境界が、前記送信元データ・ストリームの所定数の連続フレームに対して、前記モニタした送信元データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記送信元データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定める、
請求項１７に記載の装置。
【請求項２０】
前記少なくとも１つのプロセッサがさらに適切に、
(v) 第１のモードのオペレーションにおいて、送信先データ・ストリームに少なくとも１つの所定のビット遷移を選択的に挿入し、
(vi)第２のモードのオペレーションにおいて、前記送信元データ・ストリームから少なくとも１つの所定のビット遷移を選択的に除去する、
請求項１７に記載の装置。
【請求項１】
送信元データ・ストリームに潜在する少なくとも２つの異なるデータ・フレーミング・プロトコルをサポートしうるデータ・フレーマであって、
前記少なくとも２つのデータ・フレーミング・プロトコルのうちの第１のものに従って前記送信元データ・ストリームからユーザ・データを選択的に抽出するように構成された第１のフレーミング回路と、
前記少なくとも２つのデータ・フレーミング・プロトコルのうちの第２のものに従って前記送信元データ・ストリームからユーザ・データを選択的に抽出するように構成された第２のフレーミング回路と、
前記第１のフレーミング回路、少なくとも第２のフレーミング回路、および少なくとも１つのコントローラに接続されたコントローラであって、前記第１のフレーミング回路および前記第２のフレーミング回路が、（i)前記送信元データ・ストリームを受信して前記少なくとも２つの異なるデータ・フレーミング・プロトコルのうちのどれが前記送信元データ・ストリームに対応するかを自動的に判断し、（ii) 前記送信元データ・ストリームの前記判断したデータ・フレーミング・プロトコルと前記第１のデータ・フレーミング・プロトコルおよび前記第２のデータ・フレーミング・プロトコルのうちの一方との一致に応答して、前記送信元データ・ストリームを前記第１のフレーミング回路および前記第２のフレーミング回路のうちの一方に転送する、コントローラと
を備えた
データ・フレーマ。
【請求項２】
前記フレーミング回路の各々が少なくとも１つのステート・マシンを備え、
前記少なくとも１つのステート・マシンが、前記送信元データ・ストリームに対応するデータ・フレーミング・プロトコルがそれに付随するデータ・フレーミング・プロトコルと実質的に一致するか否かを判断し、
前記少なくとも１つのステート・マシンの各々がそれに対応する異なる個別のデータ・フレーミング・プロトコルを備えている、
請求項１に記載のデータ・フレーマ。
【請求項３】
前記フレーミング回路に付随する前記ステート・マシンの各々が、前記送信元データ・ストリームに対応するデータ・フレーミング・プロトコルを実質的に同時並行的に確認する、
請求項２に記載のデータ・フレーマ。
【請求項４】
前記コントローラが、前記送信元データ・ストリームに対応する判断済みデータ・プロトコルと一致しないデータ・フレーミング・プロトコルに付随する少なくとも１つのステート・マシンを適切に無効にするように構成されている、
請求項２に記載のデータ・フレーマ。
【請求項５】
前記第１のデータ・フレーミング・プロトコルがＷＡＮ型プロトコルであり、
前記第２のデータ・フレーミング・プロトコルがＬＡＮ型プロトコルである、
請求項１に記載のデータ・フレーマ。
【請求項６】
前記第１のデータ・フレーミング・プロトコルがＳＯＮＥＴ／ＳＤＨ型プロトコルであり、
前記第２のデータ・フレーミング・プロトコルがイーサネット(R)型プロトコルおよびファイバ・チャネル型プロトコルのうちの一方である、
請求項１に記載のデータ・フレーマ。
【請求項７】
さらに、
前記コントローラと前記第１のフレーミング回路および前記第２のフレーミング回路のうちの少なくとも一方との間に適切に接続されたスクランブラ／デスクランブラを備え、
前記スクランブラ／デスクランブラが、
第１のモードのオペレーションにおいて、送信先データ・ストリームに所定のビット遷移を選択的に挿入するように構成されており、
第２のモードのオペレーションにおいて、前記送信元データ・ストリームから所定のビット遷移を選択的に除去するように構成されている、
請求項１に記載のデータ・フレーマ。
【請求項８】
前記コントローラがさらに適切に、
（iii)前記フレーミング回路のうちの少なくとも１つのものの状態を検出し、前記少なくとも１つのフレーミング回路が、前記送信元データ・ストリームの前記判断したデータ・フレーミング・プロトコルに対応し予期されるフレーム境界がないか前記送信元データ・ストリームをモニタし、
（iv) 前記予期されるフレーム境界が、前記モニタした送信元データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記送信元データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定める、
請求項１に記載のデータ・フレーマ。
【請求項９】
前記コントローラがさらに適切に、
（iii)前記フレーミング回路のうちの少なくとも１つのものの状態を検出し、前記少なくとも１つのフレーミング回路が、前記送信元データ・ストリームの前記判断したデータ・フレーミング・プロトコルに対応し予期されるフレーム境界がないか前記送信元データ・ストリームをモニタし、
（iv) 前記予期されるフレーム境界が、前記送信元データ・ストリームの所定数の連続フレームに対して、前記モニタした送信元データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記送信元データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定める、
請求項１に記載のデータ・フレーマ。
【請求項１０】
前記コントローラがさらに、前記データ・フレーマに提示されるユーザ選択可能な制御信号に応答して、前記データ・フレーマのデータ・フレーミング・プロトコルを変更するように構成されている、
請求項１に記載のデータ・フレーマ。
【請求項１１】
送信元と送信先との間でデータを伝送する方法であって、
前記送信元から入力データ・ストリームを受信するステップと、
前記入力データ・ストリームに潜在する少なくとも２つのデータ・フレーミング・プロトコルから前記入力データ・ストリームに対応するデータ・フレーミング・プロトコルを自動的に決定するステップと、
第１のモードのオペレーションにおいて、前記入力データ・ストリームに対応する前記決定したデータ・フレーミング・プロトコルに従ってデータを抽出するステップと、
第２のモードのオペレーションにおいて、前記入力データ・ストリームに対応する前記決定したデータ・フレーミング・プロトコルに従ってデータをフレーミングするステップと
を備えた
方法。
【請求項１２】
さらに、
前記入力データ・ストリームの前記決定したデータ・フレーミング・プロトコルに対応する予期されるフレーム境界がないか前記入力データ・ストリームをモニタするステップと、
前記予期されるフレーム境界が、前記モニタした入力データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記入力データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定めるステップと
を備えた、
請求項１１に記載の方法。
【請求項１３】
さらに、
前記入力データ・ストリームの前記決定したデータ・フレーミング・プロトコルに対応する予期されるフレーム境界がないか前記入力データ・ストリームをモニタするステップと、
前記予期されるフレーム境界が、前記入力データ・ストリームの所定数の連続フレームに対して、前記モニタした入力データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記入力データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定めるステップと
を備えた、
請求項１１に記載の方法。
【請求項１４】
前記データ・フレーミング・プロトコルのうちの第１のものがＷＡＮ型プロトコルであり、
前記データ・フレーミング・プロトコルのうちの第２のものがＬＡＮ型プロトコルである、
請求項１１に記載の方法。
【請求項１５】
前記データ・フレーミング・プロトコルのうちの第１のものがＳＯＮＥＴ／ＳＤＨ型プロトコルであり、
前記データ・フレーミング・プロトコルのうちの第２のものがイーサネット(R)型プロトコルおよびファイバ・チャネル型プロトコルのうちの一方である、
請求項１１に記載の方法。
【請求項１６】
さらに、
第１のモードのオペレーションにおいて、出力データ・ストリームに少なくとも１つの所定のビット遷移を選択的に挿入するステップと、
第２のモードのオペレーションにおいて、前記入力データ・ストリームから少なくとも１つの所定のビット遷移を選択的に除去するステップと
を備えた、
請求項１１に記載の方法。
【請求項１７】
送信元と送信先との間でデータを伝送する装置であって、前記装置は送信元データ・ストリームに潜在する少なくとも２つの異なるデータ・フレーミング・プロトコルをサポートすることができ、
適切に、
（i)前記送信元データ・ストリームを受信し、
（ii) 前記送信元データ・ストリームに対応するデータ・フレーミング・プロトコルを自動的に決定し、
(iii)第１のモードのオペレーションにおいて、前記送信元データ・ストリームに対応する前記決定したデータ・フレーミング・プロトコルに従ってデータを抽出し、
(iv) 第２のモードのオペレーションにおいて、前記送信元データ・ストリームに対応する前記決定したデータ・フレーミング・プロトコルに従ってデータをフレーミングする
少なくとも１つのプロセッサを備えている
装置。
【請求項１８】
前記少なくとも１つのプロセッサがさらに適切に、
(v) 前記送信元データ・ストリームの前記決定したデータ・フレーミング・プロトコルに対応し予期されるフレーム境界がないか前記送信元データ・ストリームをモニタし、
(vi)前記予期されるフレーム境界が、前記モニタした送信元データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記送信元データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定める、
請求項１７に記載の装置。
【請求項１９】
前記少なくとも１つのプロセッサがさらに適切に、
(v) 前記送信元データ・ストリームの前記決定したデータ・フレーミング・プロトコルに対応し予期されるフレーム境界がないか前記送信元データ・ストリームをモニタし、
(vi)前記予期されるフレーム境界が、前記送信元データ・ストリームの所定数の連続フレームに対して、前記モニタした送信元データ・ストリームに対応するフレーム境界と実質的に一致しない場合、前記送信元データ・ストリームに対応する新たなデータ・フレーミング・プロトコルを自動的に定める、
請求項１７に記載の装置。
【請求項２０】
前記少なくとも１つのプロセッサがさらに適切に、
(v) 第１のモードのオペレーションにおいて、送信先データ・ストリームに少なくとも１つの所定のビット遷移を選択的に挿入し、
(vi)第２のモードのオペレーションにおいて、前記送信元データ・ストリームから少なくとも１つの所定のビット遷移を選択的に除去する、
請求項１７に記載の装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２００５−５０８１０６（Ｐ２００５−５０８１０６Ａ）
【公表日】平成１７年３月２４日（２００５．３．２４）
【国際特許分類】
【出願番号】特願２００３−５０１１０７（Ｐ２００３−５０１１０７）
【出願日】平成１４年５月２８日（２００２．５．２８）
【国際出願番号】ＰＣＴ／ＵＳ２００２／０１６９５２
【国際公開番号】ＷＯ２００２／０９８０３５
【国際公開日】平成１４年１２月５日（２００２．１２．５）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成１７年３月２４日（２００５．３．２４）
【国際特許分類】
【出願日】平成１４年５月２８日（２００２．５．２８）
【国際出願番号】ＰＣＴ／ＵＳ２００２／０１６９５２
【国際公開番号】ＷＯ２００２／０９８０３５
【国際公開日】平成１４年１２月５日（２００２．１２．５）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]