データ転送装置及びデータ転送システム
【課題】前後のデータの関係から同期ヘッダを正しい値に訂正する。
【解決手段】フレームが分割されたデータに第２の所定ビットの同期ヘッダを付加することによって生成されるブロックを転送するデータ転送装置であって、前記ブロックは、連続して順に転送される第１のブロック、第２のブロック及び第３のブロックを含み、前記データ転送装置は、前記第１のブロックに含まれる第１の同期ヘッダ、前記第２のブロックに含まれる第２の同期ヘッダ及び前記第３のブロックに含まれる第３の同期ヘッダを取得し、前記第２の同期ヘッダが正しい値でない場合、前記第２のブロックが前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを、前記第１の同期ヘッダと前記第３の同期ヘッダとに基づいて推測できるか否かの第１の判定をし、前記推測された値に前記第２の同期ヘッダを訂正する。
【解決手段】フレームが分割されたデータに第２の所定ビットの同期ヘッダを付加することによって生成されるブロックを転送するデータ転送装置であって、前記ブロックは、連続して順に転送される第１のブロック、第２のブロック及び第３のブロックを含み、前記データ転送装置は、前記第１のブロックに含まれる第１の同期ヘッダ、前記第２のブロックに含まれる第２の同期ヘッダ及び前記第３のブロックに含まれる第３の同期ヘッダを取得し、前記第２の同期ヘッダが正しい値でない場合、前記第２のブロックが前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを、前記第１の同期ヘッダと前記第３の同期ヘッダとに基づいて推測できるか否かの第１の判定をし、前記推測された値に前記第２の同期ヘッダを訂正する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ転送装置に関し、特に、物理層においてデータを転送するために用いられるデータ（例えば、同期ヘッダ）を修復する技術に関する。
【背景技術】
【０００２】
ネットワークノード間のデータ転送において、データ同期のための同期ヘッダ（SyncHeader）が、所定の間隔で挿入されるプロトコルがある。例えば、１０ギガビットイーサネット（「イーサネット」は登録商標。以下同じ。）において、６４Ｂ／６６Ｂ符号化を用いて、６６ビットのブロック毎にデータを伝送する（例えば、特許文献１参照。）。この６６ビットのブロックは、２ビットの同期ヘッダ（”０１”又は”１０”）と、６４ビットのペイロードとによって構成される。すなわち、２ビットの同期ヘッダが６６ビット毎に挿入される。
【０００３】
このため、送信側ノードは、６４ビットのデータに２ビットの同期ヘッダを付けて６６ビットに符号化する。受信側ノードは、６６ビット毎に到着する２ビットの同期ヘッダを見つけ、同期ヘッダの後の６４ビットのデータを復号する。また、同期ヘッダの値が”０１”の場合は、同期ヘッダの後の６４ビットデータはユーザデータであり、同期ヘッダの値が”１０”の場合は、同期ヘッダの後の６４ビットデータは制御コードを含むデータである（例えば、非特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−７２７１４号公報
【非特許文献】
【０００５】
【非特許文献１】IEEE 802.3ae
【発明の概要】
【発明が解決しようとする課題】
【０００６】
電気信号又は光信号によってネットワークを転送されるデータは、ノイズの影響等によって書き換わることがある。このような物理層におけるデータの誤りは、上位層（データリンク層、ネットワーク層等）における誤り訂正によって修復することはできない。
【０００７】
例えば、伝送路上のノイズ等により同期ヘッダが破損し、”００”又は”１１”に書き換わった場合、受信側ノードは、ペイロードがユーザデータなのか制御コードを含むデータなのかを判定することができず、受信したデータを正しくデコードできないことから、６４ビットのペイロードは廃棄されてしまう。
【０００８】
本発明は、同期ヘッダが破損したブロックを受信した場合でも、前後のデータの関係から正しい同期ヘッダの値を推測し、同期ヘッダを訂正することによって、廃棄されていたデータを適正に処理することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の代表的な一例を示せば以下の通りである。すなわち、フレームを第１の所定ビットのデータに分割し、前記分割されたデータに第２の所定ビットの同期ヘッダを付加することによって生成されるブロックを転送するデータ転送装置であって、前記データ転送装置の動作を処理するロジックと、転送されるブロックを格納するバッファと、前記データ転送装置へのデータを入出力するインターフェースとを備え、前記ブロックは、連続して順に転送される第１のブロック、第２のブロック及び第３のブロックを含み、前記ロジックは、前記第１のブロックに含まれる第１の同期ヘッダ、前記第２のブロックに含まれる第２の同期ヘッダ及び前記第３のブロックに含まれる第３の同期ヘッダを取得し、前記第２の同期ヘッダが正しい値でない場合、前記第２のブロックが前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを、前記第１の同期ヘッダと前記第３の同期ヘッダとに基づいて推測できるか否かの第１の判定をし、前記推測された値に前記第２の同期ヘッダを訂正する。
【発明の効果】
【００１０】
本発明によると、破損した同期ヘッダを訂正することができ、ブロックの廃棄による有効データの欠損、転送効率の低下を抑えることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１の実施の形態のシステムの構成を表す図である。
【図２】本発明の第１の実施の形態のネットワークノードの構成を表すブロック図で ある。
【図３Ａ】本発明の第１実施形態のＸＧＭＩＩ上のイーサフレームと１０Ｇｂイーサ ネット上のデータ列との変換を説明する図である。
【図３Ｂ】本発明の第１実施形態のエンコーダによるエンコードの例を説明する図で ある。
【図４】本発明の第１の実施の形態のエラー訂正処理のフローチャートである。
【図５】本発明の第１の実施形態において同期ヘッダが訂正される状態を説明する図 である。
【図６】本発明の第２の実施の形態のエラー訂正処理のフローチャートである。
【図７】本発明の第２の実施の形態のエラー訂正処理の詳細を示すフローチャートで ある。
【図８】本発明の第２の実施形態において同期ヘッダが訂正される状態を説明する図 である。
【図９】本発明の第２の実施形態において同期ヘッダが訂正される状態を説明する図 である。
【図１０】本発明の第２の実施形態において同期ヘッダの訂正が失敗する状態を説明する図である。
【図１１】本発明の第２の実施の形態のエラー訂正テーブルを説明する図である。
【図１２】本発明が適用されたＭＰＬＳネットワークの説明図である。
【発明を実施するための形態】
【００１２】
＜実施形態１＞
図１は、本発明の第１の実施の形態のシステムの構成を表す図である。
【００１３】
第１の実施の形態のシステムは、クライアント端末１０１、１０５、ネットワークノード１０２、１０４及びネットワーク１０３を備える。
【００１４】
クライアント端末１０１及び１０５は、ネットワーク１０３を経由してデータを送受信する計算機であり、プロセッサ、メモリ及びネットワークインターフェースを備える。ネットワークノード１０２及び１０４は、クライアントと他のノードとの間、及びノード間でデータを転送するデータ転送装置で、ネットワーク１０３によって接続されている。なお、ネットワークノード１０２及び１０４の詳細な構成は、図２を用いて後述する。
【００１５】
ネットワーク１０３は、複数のネットワークノードによって、指定された宛先アドレスにデータを転送するものである。なお、図１に示すネットワーク１０３は、２台のネットワークノード１０２及び１０４を備えるが、さらに複数のネットワークノードを備えてもよい。ネットワーク１０３は、いわゆる１０ギガビットイーサネットであり、６４Ｂ／６６Ｂ符号によって符号化されたデータを伝送する。すなわち、ネットワーク１０３の物理層において、６６ビットのブロック毎にデータが転送され、この６６ビットのブロックは、２ビットの同期ヘッダ（ＳｙｎｃＨｅａｄｅｒ）と、６４ビットのペイロードとによって構成されている。
【００１６】
なお、本発明は、転送されるブロックに含まれるデータの属性を表し、誤り訂正によって訂正不可能なデータを、ブロック中に含む場合に適用可能であるため、ネットワーク１０３は、同期ヘッダを含むブロックを転送する１０ギガビットイーサネットでなくてもよい。
【００１７】
図２は、第１の実施の形態のネットワークノード１０４の構成を表すブロック図である。
【００１８】
ネットワークノード１０４は、ブロック同期部１１１、デ・スクランブラ１１２、エラー訂正部１１３、デコーダ１１７、エンコーダ１１８及びスクランブラ１１９を備える。
【００１９】
ブロック同期部１１１は、ネットワーク側から送信されるシリアルデータ列に６６ビット毎に含まれる同期ヘッダの”０１”又は”１０”パターンを見つけて、ブロックの同期を確立する。
【００２０】
デ・スクランブラ１１２は、ブロックの６４ビットのペイロードにデスクランブル処理を行う。
【００２１】
エラー訂正部１１３は、ブロックの同期ヘッダが破損している場合、正しい同期ヘッダの値を推測し、同期ヘッダを訂正する。
【００２２】
具体的には、エラー訂正部１１３は、ブロックの同期ヘッダが破損している場合、前後のブロックの同期ヘッダが、中間ブロックの同期ヘッダを訂正可能な条件を満たしているかを判定する。そして、訂正可能な条件を満たした場合、前後のブロックの同期ヘッダの値を参照することによって、当該中間ブロックの正しい同期ヘッダの値を推測し、当該中間ブロックの同期ヘッダを推測された値に訂正する。
【００２３】
このため、エラー訂正部１１３は、少なくとも前後のブロックを一次的に記憶するバッファ１１４、前後のブロックの同期ヘッダが、中間ブロックの同期ヘッダを訂正可能な条件を満たすかを判定する判定部１１５、及び、前後のブロックの同期ヘッダから推測された値に、中間ブロックの同期ヘッダを訂正する訂正部１１６を備える。なお、エラー訂正部１１３によって実行される処理の詳細は、図４を用いて後述する。
【００２４】
デコーダ１１７は、ブロックからペイロードを抽出し、６４ビット（８バイト）データへ復号化する。
【００２５】
エンコーダ１１８は、６４ビット（８バイト）データに、同期ヘッダを付加し、６６ビットのブロックへ符号化する。
【００２６】
スクランブラ１１９は、ブロックのペイロードデータにスクランブル処理を行う。このスクランブル処理によって、転送されるデータのディスパリティが０になるように、データが調整される。
【００２７】
ネットワークノード１０４は、データを送受信するインターフェース（ポート）、データを出力するポートを決定するルーティング部、ネットワークノードの動作を制御するプロセッサ、及び、プロセッサで実行されるプログラム及び当該プログラムの実行に必要なデータを格納するメモリを備える。
【００２８】
以上、ネットワークノード１０４について説明したが、ネットワークノード１０２も同じ構成及び機能である。
【００２９】
図３Ａは、ＸＧＭＩＩ上のイーサフレームと１０ギガビットイーサネット上のデータ列との変換を説明する図である。
【００３０】
１０ギガビットイーサネット上のデータ列３０５は、ＸＧＭＩＩ（10 Gigabit Media Independent Interface）上の所定長のイーサフレーム３０１を８バイト毎に分割して、分割されたデータに２ビットの同期ヘッダを付加することによって、１０ギガビットイーサネット上を転送される６６ビットのブロックを生成する。
【００３１】
具体的には、ＸＧＭＩＩ上のイーサフレーム３０１は、その先頭に８ビットの開始コード（Ｓ）が設けられ、その末尾に８ビットの末尾コード（Ｔ）が設けられ、開始コードと末尾コードとの間にデータ領域が設けられる。また、フレーム間にはインターフレームギャップ（ＩＦＧ）が設けられる。
【００３２】
エンコーダ１１８は、このイーサフレーム３０１を、８バイト毎に分割したデータを生成する（３０２）。このとき、開始コードは８バイト中の１番目又は５番目のバイトだけに割り当て可能である。すなわち、開始コードを含む８バイトのデータは、「ＳＤＤＤＤＤＤＤ」又は「ＩＩＩＩＳＤＤＤ」となる。
【００３３】
そして、分割された８バイトのデータを所定のルールに従ってエンコードし、その後、２ビットの同期ヘッダを付与する（３０３）。８バイトのデータはユーザデータである場合、同期ヘッダ”０１”が付与され、８バイトのデータは制御コードを含むデータである場合、同期ヘッダ”１０”が付与される。
【００３４】
その後、同期ヘッダを除くペイロードのデータをスクランブルして、１０ギガビットイーサネット上のデータ列３０５が生成される。
【００３５】
一方、１０ギガビットイーサネット上のデータ列３０５は、デスクランブル処理によって、エンコードされた状態のデータが復元される。その後、同期ヘッダが破損しているか否かが判定され、破損している同期ヘッダが修復される（３０４、３０３）。この同期ヘッダの訂正処理は、図４、図５を用いて後述する。この同期ヘッダの訂正処理は、論理回路によるロジックによって実装されてもよく、プロセッサがメモリに格納されたプログラムを実行することによるロジックによって実装されてもよい。
【００３６】
同期ヘッダが修復されたデータは、同期ヘッダを外して、８バイトのデータを生成し、８バイト毎にデコードされる（３０２）。その後、デコードされたデータ結合してパケットを組み立て、イーサフレーム３０１を再構成する。
【００３７】
図３Ｂは、エンコーダ１１８によるエンコードの例を説明する図である。
【００３８】
前述したように、８バイトのペイロードにユーザデータ（Ｄ）のみが含まれる場合、このブロックはデータブロックであり、同期ヘッダは”０１”となる。一方、８バイトのペイロードに制御コード（Ｓ、Ｔ、Ｉ等）が含まれる場合、このブロックはコントロールブロックであり、同期ヘッダは”１０”となる。
【００３９】
コントロールブロックの場合、ペイロードの先頭（すなわち、同期ヘッダの直後）に８ビットの、ＢｌｏｃｋＴｙｐｅＦｉｅｌｄが設けられる。このＢｌｏｃｋＴｙｐｅＦｉｅｌｄは、ブロックに含まれるユーザデータ（Ｄ）のエンコードの方法を示す。すなわち、ＢｌｏｃｋＴｙｐｅＦｉｅｌｄの値によって、ブロックに含まれる制御コードの種類、数、及び位置が決まる。
【００４０】
図４は、第１の実施の形態のエラー訂正処理のフローチャートであり、このエラー訂正処理はエラー訂正部１１３によって実行される。なお、エラー訂正部１１３は、論理回路によって機能するものであっても、ネットワークノードに備わるプロセッサがメモリに格納されたプログラムを実行することによって機能するものであってもよい。また、このエラー訂正処理は、ブロック同期部１１１によるブロックの同期、デスクランブラ１１２によるデスクランブルが確立した後に実行される。
【００４１】
まず、同期ヘッダの値によって、同期ヘッダが破損しているか否かを判定する（Ｓ１０１）。具体的には、正しい同期ヘッダは”０１”又は”１０”であるため、同期ヘッダが、”００”又は”１１”であれば、同期ヘッダが破損していると判定できる。
【００４２】
次に、バッファ１１４に格納されている前後のブロックから同期ヘッダを抽出して、抽出された同期ヘッダから、中間ブロックの同期ヘッダの値を推測可能か否かを判定する（Ｓ１０２）。すなわち、前後のブロックの同期ヘッダが、中間ブロックの同期ヘッダを訂正可能な条件を満たすか否かを判定する。具体的には、前ブロックの同期ヘッダが”０１”であり、かつ、後ブロックの同期ヘッダが”０１”である場合、中間ブロックの同期ヘッダを訂正可能な条件を満たし、その中間ブロックの同期ヘッダの値を推測して訂正することができる。
【００４３】
判定の結果、この条件を満たした場合、中間ブロックの同期ヘッダの値は”０１”であると推測し、この中間ブロックの同期ヘッダを”０１”に訂正する（Ｓ１０３）。
【００４４】
これは、図４に示すように、一つのブロックが、パケットの開始を示すコード”Ｓ”とパケットの終了を示すコード”Ｔ”との両方を含むことはない。また、ブロックの同期ヘッダが”０１”である場合、そのブロックは、ペイロードにユーザデータのみを含むデータブロックである。よって、この中間ブロックはデータブロックであると推測することができ、中間ブロックの同期ヘッダを”０１”に訂正することができる。
【００４５】
一方、前後のブロックの同期ヘッダのいずれかが”０１”でない場合、同期ヘッダの値を推測することはできないので、この中間ブロックの同期ヘッダを訂正しない（Ｓ１０４）。なお、破損した同期ヘッダが訂正されない場合、そのブロックのデータを含むイーサフレームを正しく組み立てることができない。このため、上位層（データリンク層、ネットワーク層等）において、この中間ブロックを含むイーサフレームが再送されるように、制御される。
【００４６】
次に、図５を用いて、中間ブロックの同期ヘッダの訂正について説明する。
【００４７】
処理対象である中間ブロックの同期ヘッダ５０２が”００”であるので、Ｓ１０１において、この同期ヘッダ５０２は誤っていると判定される。そこで、バッファに格納されている前後のブロックの同期ヘッダ５０１及び５０３を参照する。この場合、前後のブロックの同期ヘッダ５０１及び５０３は共に”０１”なので、前後のブロックの同期ヘッダ５０１及び５０３から、中間ブロックの同期ヘッダが”０１”であることを推測可能である。
【００４８】
すなわち、本実施の形態では、所定長のイーサネットフレームを分割して生成された６６ビットのブロックを、ネットワークノード間で転送するので、転送されるブロックは分割前のイーサネットフレームの性質（前後のブロックのデータとの連続性）をそのまま引き継いでいる。このため、ブロックに含まれるデータ、特に、制御コードの並びには規則性がある。本発明の実施の形態では、この規則性に着目して、ブロックがデータブロックであるか、コントロールブロックであるかを判定して、破損した同期ヘッダを訂正する。
【００４９】
このようにして、第１の実施の形態では、中間ブロックの同期ヘッダ５０２を”０１”に訂正することができる。
【００５０】
以上説明したように、本発明の第１の実施に形態によると、中間ブロックの同期ヘッダが正しい値でない場合、前後のブロックの同期ヘッダに基づいて、中間ブロックの同期ヘッダの値を推測可能かを判定する。そして、中間ブロックの同期ヘッダの値を推測できる条件を満たす場合、前後のブロックと中間ブロックとが整合するように、中間ブロックの同期ヘッダを訂正する。このため、同期ヘッダが破損したブロックの破棄が減少し、パケットの再送回数を減少することができる。また、パケットの再送信が減るので、伝送路上のトラフィックの増加を抑制することができる。さらに、トラフィックの増加を抑制することによって、ネットワークノードの消費電力を低減することができる。
【００５１】
＜実施形態２＞
次に、本発明の第２の実施の形態について説明する。
【００５２】
前述した第１の実施の形態では、中間ブロックの同期ヘッダを訂正するために、前後のブロックの同期ヘッダを用いたが、第２の実施の形態では、前後のブロックの同期ヘッダ及びブロックタイプフィールドを用いる。さらに、予備的に、中間ブロックのブロックタイプフィールドを用いてもよい。
【００５３】
なお、第２の実施の形態のシステムの構成及びネットワークノードのハードウェア構成は、前述した第１の実施の形態と同じである。なお、第２の実施の形態において、前述した第１の実施の形態と同じ構成、処理には同じ符号を付し、それらの説明は省略する。
【００５４】
第２の実施の形態のネットワークノードは、前述した第１の実施の形態のネットワークノードと比較し、エラー訂正部１１３の機能が異なる。
【００５５】
すなわち、第２の実施の形態のエラー訂正部１１３は、ブロックの同期ヘッダが破損している場合に、当該ブロックと前後のブロックの同期ヘッダ及びブロックタイプフィールドの値を参照することによって、当該中間ブロックの正しい同期ヘッダの値を推測し、同期ヘッダを訂正する。
【００５６】
具体的には、エラー訂正部１１３は、ブロックの同期ヘッダが破損している場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドが、中間ブロックの同期ヘッダを訂正可能な条件を満たすかを判定する。そして、訂正可能な条件を満たした場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドから推測された値に、中間ブロックの同期ヘッダを訂正する。
【００５７】
ここで、ブロックタイプフィールドとは、ブロックに含まれるデータの種別を表す情報であって、転送される６６ビットのブロックがコントロールブロックである場合、ペーロードの最初の８ビット（同期ヘッダの直後の１バイト）に割り当てられるデータ領域であり、図３Ｂに示すように、転送されるデータに含まれるユーザデータのバイト数及び位置、制御コードの内容、数及び位置を表す。すなわち、同期ヘッダが”１０"である場合、同期ヘッダの直後の８ビットのデータによって、コントロールブロックに含まれる制御コードを知ることができる。
【００５８】
また、第２の実施の形態において、判定部１１５は、前後のブロックの同期ヘッダ及びブロックタイプフィールドが、中間ブロックの同期ヘッダを訂正可能な条件を満たすかを判定する。訂正部１１６は、前後のブロックの同期ヘッダ及びブロックタイプフィールドから推測された値に、中間ブロックの同期ヘッダを訂正する。
【００５９】
図６は、第２の実施の形態のエラー訂正処理のフローチャートであり、このエラー訂正処理はエラー訂正部１１３によって実行される。なお、前述した第１の実施の形態と同じく、エラー訂正部１１３は、論理回路によって機能するものであっても、ネットワークノードに備わるプロセッサがメモリに格納されたプログラムを実行することによって機能するものであってもよい。また、このエラー訂正処理は、ブロック同期部１１１によるブロックの同期、スクランブラ１１２によるデスクランブルが確立した後に実行される。
【００６０】
まず、前述した第１の実施の形態と同様に、同期ヘッダが破損しているか否かを判定し（Ｓ１０１）、前後のブロックの同期ヘッダから、当該ブロックの同期ヘッダを推測可能か否かを判定し（Ｓ１０２）、中間ブロックの同期ヘッダを、推測された値に訂正する（Ｓ１０３）。
【００６１】
一方、Ｓ１０２において、前後のブロックの同期ヘッダが中間ブロックの同期ヘッダを訂正できる条件に一致しないと判定された場合、前後のブロックのブロックタイプフィールドを参照し（Ｓ１１１）、前後のブロックのブロックタイプフィールドから、中間ブロックの同期ヘッダの値を推測可能か、すなわち、前後のブロックの同期ヘッダ及びブロックタイプフィールドが中間ブロックの同期ヘッダを訂正できる条件に一致するか否かを判定する（Ｓ１１２）。その結果、中間ブロックの同期ヘッダの値を推測可能である場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドから、中間ブロックの同期ヘッダの値を推測し、中間ブロックのＳｙｎｃＨｅａｄｅｒを推測された値に訂正する（Ｓ１１３）。
【００６２】
なお、Ｓ１１２〜Ｓ１１３の処理の具体的内容は、図７及び図１１を用いて説明する。この同期ヘッダの訂正処理は、論理回路によるロジックによって実装されてもよく、前述した第１の実施の形態と同じく、プロセッサがメモリに格納されたプログラムを実行することによるロジックによって実装されてもよい。
【００６３】
一方、Ｓ１１２において、中間ブロックの同期ヘッダを訂正可能な条件を満たさないと判定された場合、この中間ブロックの同期ヘッダを訂正しない（Ｓ１０４）。この場合、前述した第１の実施の形態と同様に、そのブロックのデータを含むイーサフレームを正しく組み立てることができないので、この中間ブロックを含むイーサフレームの再送制御がされる。
【００６４】
図７は、第２の実施の形態のエラー訂正処理（図６のＳ１１２〜Ｓ１１３）の詳細を示すフローチャートである。
【００６５】
第２の実施の形態のエラー訂正処理（図６）において、前後のブロックの同期ヘッダによって中間ブロックの同期ヘッダを訂正できないと判定された場合、前後のブロックのブロックタイプフィールドを参照する（Ｓ１１１）。
【００６６】
その後、前ブロックの同期ヘッダが”０１”であり、かつ、後ブロックの同期ヘッダが”１０”であるかを判定する（Ｓ１２１）。前ブロックの同期ヘッダが”０１”であり、かつ、後ブロックの同期ヘッダが”１０”である場合、さらに、後ブロックのブロックタイプフィールドが”０ｘ３３”であるかを判定する（Ｓ１２２）。
【００６７】
その結果、前ブロックの同期ヘッダが”０１”であり、後ブロックの同期ヘッダが”１０”であり、かつ、後ブロックのブロックタイプフィールドが”０ｘ３３”である場合、中間ブロックの同期ヘッダを訂正することができる条件を満たす。すなわち、この場合、後ブロックはフレーム先頭（開始コードＳ）を含むので、処理対象の中間ブロックはフレーム末尾（末尾コードＴ）を含み、コントロールブロックであると推測できる。よって、中間ブロックの同期ヘッダを訂正するためにＳ１２７に進む。
【００６８】
一方、前ブロックの同期ヘッダが”０１”でなく、又は、後ブロックの同期ヘッダが”１０”でない場合、他の条件を満たすかを探索するために、Ｓ１２５に進む。
【００６９】
Ｓ１２５において、前ブロックの同期ヘッダが”１０”であり、後ブロックの同期ヘッダが”１０”であり、さらに、前ブロックのブロックタイプフィールドが”０ｘ８７”であり、かつ、後ブロックのブロックタイプフィールドが”０ｘ１ｅ”であるかを判定する（Ｓ１２５、Ｓ１２６）。
【００７０】
その結果、前ブロックの同期ヘッダが”１０”であり、後ブロックの同期ヘッダが”１０”であり、前ブロックのブロックタイプフィールドが”０ｘ８７”であり、かつ、後ブロックのブロックタイプフィールドが”０ｘ１ｅ”である場合、中間ブロックの同期ヘッダを訂正することができる条件を満たす。この場合、この前ブロックはフレーム末尾（末尾コードＴ）を含み、後ブロックはＩＦＧを含む。処理対象の中間ブロックは、前後をＩＦＧに挟まれていることから、ＩＦＧを含み、コントロールブロックであると推測できる。よって、中間ブロックの同期ヘッダを訂正するためにＳ１２７に進む。
【００７１】
Ｓ１２７では、処理対象の中間ブロックのブロックタイプフィールドを参照して、中間ブロックの同期ヘッダを訂正するか否かを判定する。すなわち、前後のブロックの同期ヘッダ及びブロックタイプフィールドから推測された中間ヘッダの同期ヘッダが、中間ブロックのブロックタイプフィールドと整合するか否かを判定する。これは、同期ヘッダが”１０”である場合、ブロックタイプフィールドは所定の値しか取り得ないからである。
【００７２】
その結果、推測された中間ヘッダの同期ヘッダが、中間ブロックのブロックタイプフィールドと整合する場合、推測された中間ヘッダの同期ヘッダの値が正しいことが確認されたので、Ｓ１２８に進み、中間ブロックの同期ヘッダを”１０”に訂正する。
【００７３】
一方、推測された中間ヘッダの同期ヘッダが、中間ブロックのブロックタイプフィールドと整合しない場合、推測された中間ヘッダの同期ヘッダの値か、ブロックタイプフィールドの値が誤っている可能性がある。この場合、以下の二つの処理が考えられる。
【００７４】
（１）同期ヘッダを訂正する。推測された中間ヘッダの同期ヘッダが、中間ブロックのブロックタイプフィールドと整合しない場合、同期ヘッダの訂正が正しい確率が低い。しかし、ブロックを正しくデコードできる確率を高め、パケット廃棄率を低減するためには、同期ヘッダの訂正が正しい可能性が低くても、同期ヘッダを訂正するとよい。
【００７５】
（２）同期ヘッダを訂正しない。推測された中間ヘッダの同期ヘッダが、中間ブロックのブロックタイプフィールドと整合しない場合、同期ヘッダの訂正が正しい確率が低いので、データの誤りを防止するためには、同期ヘッダを訂正せず、上位層においてフレームを再送するように制御した方がよい。すなわち、データの正確性を優先するためには、この場合に同期ヘッダを訂正しない方がよい。
【００７６】
この二つの処理は、転送されるデータの品質、すなわち、データ転送速度を優先するか、データの正確性を優先するかによって変えるとよい。また、この二つの処理は、中間ブロックの同期ヘッダが訂正可能であると判定される、前後のブロックの同期ヘッダ及びブロックタイプフィールドの組み合わせ毎に選択可能に設定されてもよい。
【００７７】
なお、Ｓ１２７の処理は任意のステップであり、中間ブロックのブロックタイプフィールドを参照して、中間ブロックの同期ヘッダを訂正するかを判定しなくてもよい。
【００７８】
その後、同期ヘッダを訂正する場合、処理対象の中間ブロックの同期ヘッダを”１０”に訂正する（Ｓ１２８）。
【００７９】
一方、前後のブロックの同期ヘッダ及びブロックタイプフィールドの値が何れのエントリとも一致しない場合、同期ヘッダの訂正候補が得られないので、判定対象の中間ブロックの同期ヘッダは訂正不可と判定する。具体的には、Ｓ１２２でＮｏと判定された場合、Ｓ１２５でＮｏと判定された場合、Ｓ１２６でＮｏと判定された場合、Ｓ１０４に進み、処理対象の中間ブロックの同期ヘッダを訂正しない。
【００８０】
次に、図８〜図１０を用いて、中間ブロックの同期ヘッダの訂正について、前後のブロックの同期ヘッダ及びブロックタイプフィールドから、中間ブロックの同期ヘッダの値を推測可能な場合（図８、図９）、及び、中間ブロックの同期ヘッダの値を推測不可能な場合（図１０）について説明する。
【００８１】
図８に示す場合、処理対象である中間ブロックの同期ヘッダ５１２が”００”であるので、Ｓ１０１において、この同期ヘッダ５１２は誤っていると判定される。そこで、バッファに格納されている前後のブロックの同期ヘッダ５１１及び５１３を参照する。前ブロックの同期ヘッダ５１１は”０１”で、後ブロックの同期ヘッダ５１３は”１０”なので、前後のブロックの同期ヘッダ５１１及び５１３から中間ブロックの同期ヘッダの値を推測できない（Ｓ１０２、Ｓ１２１）。そこで、後ブロックのブロックタイプフィールド５１５を参照する。なお、図８に示す場合は、前ブロックは、その同期ヘッダが”０１”である、データブロックであるため、ブロックタイプフィールドが格納されるべき箇所には、ユーザデータが格納されている。
【００８２】
その結果、後ブロックのブロックタイプフィールド５１５が”０ｘ３３”であることから、この後ブロックはフレーム先頭（開始コードＳ）を含むことが分かる（Ｓ１２２）。このため、処理対象の中間ブロックはフレーム末尾（末尾コードＴ）を含み、コントロールブロックであると推測できる。このため、中間ブロックの同期ヘッダ５１２を”１０”に訂正することができる。
【００８３】
図８に示す場合、中間ブロックのブロックタイプフィールドは”０ｘ８７”であれば、同期ヘッダの値の推測結果は正しいので、同期ヘッダが訂正される。一方、中間ブロックのブロックタイプフィールドが”０ｘ８７”でなくても、同期ヘッダを訂正する又は訂正しない、の何れかの処理が選択的に実行される（Ｓ１２７）。
【００８４】
図９に示す場合、処理対象である中間ブロックの同期ヘッダ５２２が”１１”であるので、Ｓ１０１において、この同期ヘッダ５２２は誤っていると判定される。そこで、バッファに格納されている前後のブロックの同期ヘッダ５２１及び５２３を参照する。前ブロックの同期ヘッダ５２１は”０１”で、後ブロックの同期ヘッダ５２３は”１０”なので、前後のブロックの同期ヘッダ５２１及び５２３から、中間ブロックの同期ヘッダの値を推測できない（Ｓ１０２、Ｓ１２５）。そこで、前後のブロックのブロックタイプフィールド５２４、５２６を参照する。
【００８５】
その結果、前ブロックのブロックタイプフィールド５２４が”０ｘ８７”であることから、この前ブロックはフレーム末尾（末尾コードＴ）及びＩＦＧを含むことが分かる。また、後ブロックのブロックタイプフィールド５２６が”０ｘ１ｅ”であることから、この後ブロックはＩＦＧを含むことが分かる。このため、処理対象の中間ブロックは前後をＩＦＧに挟まれていることから、ＩＦＧを含み、コントロールブロックであると推測できる。このため、中間ブロックの同期ヘッダ５２２を”１０”に訂正することができる。
【００８６】
図９に示す場合、中間ブロックのブロックタイプフィールドは”０ｘ１ｅ”であれば、同期ヘッダの値の推測結果は正しいが、もし中間ブロックのブロックタイプフィールドが”０ｘ１ｅ”でなくても、同期ヘッダを訂正する又は訂正しない、の何れかの処理が選択的に実行される（Ｓ１２７）。
【００８７】
図１０に示す場合、処理対象である中間ブロックの同期ヘッダ５３２が”００”であるので、Ｓ１０１において、この同期ヘッダ５２２は誤っていると判定される。そこで、バッファに格納されている前後のブロックの同期ヘッダ５３１及び５３３を参照する。前ブロックの同期ヘッダ５３１は”１０”で、後ブロックの同期ヘッダ５３３は”１０”なので、前後のブロックの同期ヘッダ５３１及び５３３から、中間ブロックの同期ヘッダの値を推測可能な条件を満たさない（Ｓ１０２、Ｓ１２５）。そこで、前後のブロックのブロックタイプフィールド５３４、５３６を参照する。
【００８８】
その結果、後ブロックのブロックタイプフィールド５３６が”０ｘ３３”であることから、この後ブロックはフレーム先頭（開始コードＳ）を含むことが分かる。また、前ブロックのブロックタイプフィールド５３４が”０ｘ３３”であることから、この前ブロックはフレーム先頭（開始コードＳ）を含むことが分かる（Ｓ１２６）。
【００８９】
このとき、開始コード（Ｓ）を含む二つのブロックの間には、末端コード（Ｔ）を含むブロックがあるべきである。しかし、当該中間ブロックのブロックタイプフィールドを参照した結果の値が、例えば０ｘ３３であり、当該中間ブロックは開始コード（Ｓ）を含むので、当該中間ブロックの同期ヘッダを訂正しても、前後のブロックとの整合性がとれない。よって、中間ブロックの同期ヘッダ５３２を訂正しない（Ｓ１２７）。
【００９０】
＜変形例＞
第２の実施の形態のエラー訂正処理は、図７に示すロジックではなく、前後のブロックの同期ヘッダ及びブロックタイプフィールドから、特定組み合わせを見つけることによって、中間ブロックの同期ヘッダの訂正可否を判定することもできる。次に、この変形例について説明する。
【００９１】
図１１は、第２の実施の形態のエラー訂正テーブル２００を説明する図である。
【００９２】
第２の実施の形態のエラー訂正テーブル２００は、前ブロックの同期ヘッダ２０１、前ブロックのブロックタイプフィールド２０２、後ブロックの同期ヘッダ２０３、後ブロックのブロックタイプフィールド２０４、中間ブロックのブロックタイプフィールド２０５及び同期ヘッダの訂正候補２０６を含む。エラー訂正テーブル２００は、ネットワークノードのメモリに格納されており、判定部１１５によって参照される。なお、後述するように、エラー訂正テーブル２００は、中間ブロックのブロックタイプフィールド２０５を含まなくてもよい。
【００９３】
前ブロックの同期ヘッダ２０１は、処理対象の中間ブロックの前に受信したブロックの同期ヘッダの値である。前ブロックのブロックタイプフィールド２０２は、処理対象の中間ブロックの前に受信したブロックのブロックタイプフィールドの値である。後ブロックの同期ヘッダ２０３は、処理対象の中間ブロックの後に受信したブロックの同期ヘッダの値である。後ブロックのブロックタイプフィールド２０４は、処理対象の中間ブロックの後に受信したブロックのブロックタイプフィールドの値である。中間ブロックのブロックタイプフィールド２０５は、処理対象の中間ブロックのブロックタイプフィールドの値である。同期ヘッダの訂正候補２０６は、処理対象の中間ブロックの同期ヘッダの訂正候補である。なお、各欄において”−”はその欄はどの値でも条件を満たすことを意味する。
【００９４】
本実施の形態では、処理対象の中間ブロックの同期ヘッダが破損している場合、バッファに格納されている前ブロックの同期ヘッダ及びブロックタイプフィールド、後ブロックの同期ヘッダ及びブロックタイプフィールドが、各々、前ブロックの同期ヘッダ２０１、前ブロックのブロックタイプフィールド２０２、後ブロックの同期ヘッダ２０３及び後ブロックのブロックタイプフィールド２０４と一致するかを判定する。
【００９５】
前後のブロックの同期ヘッダ及びブロックタイプフィールドの値が何れかのエントリと一致した場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドによって、中間ブロックの同期ヘッダの値を推測できる条件を満たし、当該中間ブロックの同期ヘッダは、このエントリの同期ヘッダの訂正候補２０６であると推測されるので、エラー訂正テーブル２００から同期ヘッダの訂正候補２０６を取得し、この同期ヘッダの訂正候補２０６によって中間ブロックの同期ヘッダを訂正する。
【００９６】
この場合、中間ブロックのブロックタイプフィールド２０５を参照してもよい。前後のブロックの同期ヘッダ及びブロックタイプフィールドがエントリと一致し、かつ、中間ブロックのブロックタイプフィールドがエントリと一致しない場合、中間ブロックの同期ヘッダを正しく訂正できる可能性が低いが、同期ヘッダを訂正しても、同期ヘッダを訂正しなくてもよい。
【００９７】
一方、前後のブロックの同期ヘッダ及びブロックタイプフィールドの値が何れのエントリとも一致しない場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドによって、中間ブロックの同期ヘッダの値を推測できる条件を満たさず、同期ヘッダの訂正候補が得られないので、判定対象の中間ブロックの同期ヘッダは訂正不可と判定する。
【００９８】
なお、エントリ２１１は、ブロックタイプフィールドによらず、前後のブロックの同期ヘッダのみによって中間ブロックの同期ヘッダを訂正可否を判定する処理（図６のＳ１０１〜Ｓ１０３）に対応するエントリである。すなわち、前後のブロックのブロックタイプフィールドの値によって判定をする場合だけでなく、前後のブロックの同期ヘッダのみによって判定をする場合にも、エラー訂正テーブル２００を用いることができる。
【００９９】
具体的には、エントリ２２１は、図５に示すように、前後のブロックの同期ヘッダが、共に”０１”である場合、中間ブロックの同期ヘッダの訂正候補を”０１”に決めることができる。
【０１００】
また、エントリ２１２は、図８に示すように、前ブロックの同期ヘッダが”０１”であり、後ブロックの同期ヘッダが”１０”であり、後ブロックのブロックタイプフィールドが”０ｘ３３”である場合、中間ブロックの同期ヘッダの訂正候補は”１０”に決めることができる。この場合、中間ブロックのブロックタイプフィールドは”０ｘ８７”であれば、同期ヘッダの値の推測結果は正しいが、もし中間ブロックのブロックタイプフィールドが”０ｘ８７”でなくても、同期ヘッダを訂正する又は訂正しない、の何れかの処理が選択的に実行される。
【０１０１】
また、エントリ２１３は、図９に示すように、前ブロックの同期ヘッダが”１０”であり、前ブロックのブロックタイプフィールドが”０ｘ８７”であり、後ブロックの同期ヘッダが”１０”であり、後ブロックのブロックタイプフィールドが”０ｘ１ｅ”である場合、中間ブロックの同期ヘッダの訂正候補を”１０”に決めることができる。この場合、中間ブロックのブロックタイプフィールドは”０ｘ１ｅ”であれば、同期ヘッダの値の推測結果は正しいが、もし中間ブロックのブロックタイプフィールドが”０ｘ１ｅ”でなくても、同期ヘッダを訂正する又は訂正しない、の何れかの処理が選択的に実行される。
【０１０２】
また、エラー訂正テーブル２００に、中間ブロックのブロックタイプフィールドが正しくない場合、同期ヘッダを訂正する又は訂正しないを決定するためのフラグを設け、エントリ毎に、同期ヘッダを訂正するか否かを制御してもよい。この場合、このフラグは、管理者によって設定可能にしてもよい。
【０１０３】
なお、図７〜図１１に示した前後のブロックの同期ヘッダ及びブロックタイプフィールドの組み合わせは例示であり、本願発明者の研究によると、数十種類の組み合わせにおいて、中間ブロックの同期ヘッダの値を推測できる条件を満たし、中間ブロックの同期ヘッダの値を推測することができる。
【０１０４】
以上説明したように、本発明の第２の実施に形態によると、中間ブロックの同期ヘッダが正しい値でない場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドに基づいて、中間ブロックの値を推測可能かを判定する。そして、中間ブロックの値を推測できる条件を満たす場合、前後のブロックと中間ブロックとが整合するように、中間ブロックの同期ヘッダを訂正する。このため、前述した第１の実施の形態の効果に加え、第１の実施の形態より多くの場合に中間ブロックの同期ヘッダを訂正することができる。
【０１０５】
＜ＭＰＬＳネットワークへの実装＞
図１２は、本発明が適用されたＭＰＬＳネットワークの説明図である。
【０１０６】
ユーザデータをクライアント装置１−１からクライアント装置２−１へ転送する場合、クライアント装置１−１から送信されたイーサフレームを、ＭＰＬＳエッジ装置１１にてオーバーヘッド（ＯＨ）を終端し、ユーザデータを抽出し、宛先クライアント装置２−１が接続されたＭＰＬＳエッジ装置１２を特定する。ＯＨには、宛先であるクライアント装置２−１のアドレス（ＩＰアドレスやディスティネーションアドレスなど）を含む。なお、図１２ではユーザデータはＳＤＨ／ＳＯＮＥＴ信号を例に説明するが、イーサネット信号など様々な信号でも同じである。
【０１０７】
そして、特定されたエッジノードを表すＭＰＬＳラベル（ＴＬＳＰ）を、抽出されたユーザデータに付して、ユーザデータをカプセル化する。ＴＬＳＰを用いたカプセル化によって、ＭＰＬＳネットワーク内のＭＰＬＳコア装置２１〜２３は、クライアント装置２−１の宛先を見ることなく、ＭＰＬＳネットワークワーク内でエンド・ツー・エンドでパケットを転送（以下、ラベルスイッチと呼ぶ）できる。
【０１０８】
このとき、ＭＰＬＳエッジ装置１１は、６４Ｂ／６６Ｂ符号化を用いて、クライアント装置１−１１から受信したユーザデータをカプセル化した後、６６ビットのブロックに変換し、ＭＰＬＳコア装置２１に転送する。ＭＰＬＳコア装置２１〜２ｎは、前段のＭＰＬＳ装置から送信された６６ビットのブロックからイーサフレームを再構築し、ＭＰＬＳラベルによって、次のＭＰＬＳ装置を特定し、再構築されたイーサフレームを６６ビットのブロックに変換して、次段のＭＰＬＳ装置に送る。
【０１０９】
ＭＰＬＳエッジ装置１２は、前段のＭＰＬＳコア装置から送信された６６ビットのブロックからイーサフレームを再構築し、ＴＬＳＰを終端して、クライアント装置２−１へユーザデータを転送する。
【０１１０】
このように、ＭＰＬＳネットワークに備わるＭＰＬＳ装置は、前段のＭＰＬＳ装置から送信された６６ビットのブロックからイーサフレームを再構築する際に、６６ビットのブロックの破損している同期ヘッダを、前後のブロックからが破損している同期ヘッダを訂正する。
【符号の説明】
【０１１１】
１０１、１０５ クライアント端末
１０２、１０４ ネットワークノード
１０３ ネットワーク
１１１ ブロック同期部
１１２ デ・スクランブラ
１１３ エラー訂正部
１１４ バッファ
１１５ 判定部
１１６ 訂正部
１１７ デコーダ
１１８ エンコーダ
１１９ スクランブラ
【技術分野】
【０００１】
本発明は、データ転送装置に関し、特に、物理層においてデータを転送するために用いられるデータ（例えば、同期ヘッダ）を修復する技術に関する。
【背景技術】
【０００２】
ネットワークノード間のデータ転送において、データ同期のための同期ヘッダ（SyncHeader）が、所定の間隔で挿入されるプロトコルがある。例えば、１０ギガビットイーサネット（「イーサネット」は登録商標。以下同じ。）において、６４Ｂ／６６Ｂ符号化を用いて、６６ビットのブロック毎にデータを伝送する（例えば、特許文献１参照。）。この６６ビットのブロックは、２ビットの同期ヘッダ（”０１”又は”１０”）と、６４ビットのペイロードとによって構成される。すなわち、２ビットの同期ヘッダが６６ビット毎に挿入される。
【０００３】
このため、送信側ノードは、６４ビットのデータに２ビットの同期ヘッダを付けて６６ビットに符号化する。受信側ノードは、６６ビット毎に到着する２ビットの同期ヘッダを見つけ、同期ヘッダの後の６４ビットのデータを復号する。また、同期ヘッダの値が”０１”の場合は、同期ヘッダの後の６４ビットデータはユーザデータであり、同期ヘッダの値が”１０”の場合は、同期ヘッダの後の６４ビットデータは制御コードを含むデータである（例えば、非特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−７２７１４号公報
【非特許文献】
【０００５】
【非特許文献１】IEEE 802.3ae
【発明の概要】
【発明が解決しようとする課題】
【０００６】
電気信号又は光信号によってネットワークを転送されるデータは、ノイズの影響等によって書き換わることがある。このような物理層におけるデータの誤りは、上位層（データリンク層、ネットワーク層等）における誤り訂正によって修復することはできない。
【０００７】
例えば、伝送路上のノイズ等により同期ヘッダが破損し、”００”又は”１１”に書き換わった場合、受信側ノードは、ペイロードがユーザデータなのか制御コードを含むデータなのかを判定することができず、受信したデータを正しくデコードできないことから、６４ビットのペイロードは廃棄されてしまう。
【０００８】
本発明は、同期ヘッダが破損したブロックを受信した場合でも、前後のデータの関係から正しい同期ヘッダの値を推測し、同期ヘッダを訂正することによって、廃棄されていたデータを適正に処理することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の代表的な一例を示せば以下の通りである。すなわち、フレームを第１の所定ビットのデータに分割し、前記分割されたデータに第２の所定ビットの同期ヘッダを付加することによって生成されるブロックを転送するデータ転送装置であって、前記データ転送装置の動作を処理するロジックと、転送されるブロックを格納するバッファと、前記データ転送装置へのデータを入出力するインターフェースとを備え、前記ブロックは、連続して順に転送される第１のブロック、第２のブロック及び第３のブロックを含み、前記ロジックは、前記第１のブロックに含まれる第１の同期ヘッダ、前記第２のブロックに含まれる第２の同期ヘッダ及び前記第３のブロックに含まれる第３の同期ヘッダを取得し、前記第２の同期ヘッダが正しい値でない場合、前記第２のブロックが前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを、前記第１の同期ヘッダと前記第３の同期ヘッダとに基づいて推測できるか否かの第１の判定をし、前記推測された値に前記第２の同期ヘッダを訂正する。
【発明の効果】
【００１０】
本発明によると、破損した同期ヘッダを訂正することができ、ブロックの廃棄による有効データの欠損、転送効率の低下を抑えることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１の実施の形態のシステムの構成を表す図である。
【図２】本発明の第１の実施の形態のネットワークノードの構成を表すブロック図で ある。
【図３Ａ】本発明の第１実施形態のＸＧＭＩＩ上のイーサフレームと１０Ｇｂイーサ ネット上のデータ列との変換を説明する図である。
【図３Ｂ】本発明の第１実施形態のエンコーダによるエンコードの例を説明する図で ある。
【図４】本発明の第１の実施の形態のエラー訂正処理のフローチャートである。
【図５】本発明の第１の実施形態において同期ヘッダが訂正される状態を説明する図 である。
【図６】本発明の第２の実施の形態のエラー訂正処理のフローチャートである。
【図７】本発明の第２の実施の形態のエラー訂正処理の詳細を示すフローチャートで ある。
【図８】本発明の第２の実施形態において同期ヘッダが訂正される状態を説明する図 である。
【図９】本発明の第２の実施形態において同期ヘッダが訂正される状態を説明する図 である。
【図１０】本発明の第２の実施形態において同期ヘッダの訂正が失敗する状態を説明する図である。
【図１１】本発明の第２の実施の形態のエラー訂正テーブルを説明する図である。
【図１２】本発明が適用されたＭＰＬＳネットワークの説明図である。
【発明を実施するための形態】
【００１２】
＜実施形態１＞
図１は、本発明の第１の実施の形態のシステムの構成を表す図である。
【００１３】
第１の実施の形態のシステムは、クライアント端末１０１、１０５、ネットワークノード１０２、１０４及びネットワーク１０３を備える。
【００１４】
クライアント端末１０１及び１０５は、ネットワーク１０３を経由してデータを送受信する計算機であり、プロセッサ、メモリ及びネットワークインターフェースを備える。ネットワークノード１０２及び１０４は、クライアントと他のノードとの間、及びノード間でデータを転送するデータ転送装置で、ネットワーク１０３によって接続されている。なお、ネットワークノード１０２及び１０４の詳細な構成は、図２を用いて後述する。
【００１５】
ネットワーク１０３は、複数のネットワークノードによって、指定された宛先アドレスにデータを転送するものである。なお、図１に示すネットワーク１０３は、２台のネットワークノード１０２及び１０４を備えるが、さらに複数のネットワークノードを備えてもよい。ネットワーク１０３は、いわゆる１０ギガビットイーサネットであり、６４Ｂ／６６Ｂ符号によって符号化されたデータを伝送する。すなわち、ネットワーク１０３の物理層において、６６ビットのブロック毎にデータが転送され、この６６ビットのブロックは、２ビットの同期ヘッダ（ＳｙｎｃＨｅａｄｅｒ）と、６４ビットのペイロードとによって構成されている。
【００１６】
なお、本発明は、転送されるブロックに含まれるデータの属性を表し、誤り訂正によって訂正不可能なデータを、ブロック中に含む場合に適用可能であるため、ネットワーク１０３は、同期ヘッダを含むブロックを転送する１０ギガビットイーサネットでなくてもよい。
【００１７】
図２は、第１の実施の形態のネットワークノード１０４の構成を表すブロック図である。
【００１８】
ネットワークノード１０４は、ブロック同期部１１１、デ・スクランブラ１１２、エラー訂正部１１３、デコーダ１１７、エンコーダ１１８及びスクランブラ１１９を備える。
【００１９】
ブロック同期部１１１は、ネットワーク側から送信されるシリアルデータ列に６６ビット毎に含まれる同期ヘッダの”０１”又は”１０”パターンを見つけて、ブロックの同期を確立する。
【００２０】
デ・スクランブラ１１２は、ブロックの６４ビットのペイロードにデスクランブル処理を行う。
【００２１】
エラー訂正部１１３は、ブロックの同期ヘッダが破損している場合、正しい同期ヘッダの値を推測し、同期ヘッダを訂正する。
【００２２】
具体的には、エラー訂正部１１３は、ブロックの同期ヘッダが破損している場合、前後のブロックの同期ヘッダが、中間ブロックの同期ヘッダを訂正可能な条件を満たしているかを判定する。そして、訂正可能な条件を満たした場合、前後のブロックの同期ヘッダの値を参照することによって、当該中間ブロックの正しい同期ヘッダの値を推測し、当該中間ブロックの同期ヘッダを推測された値に訂正する。
【００２３】
このため、エラー訂正部１１３は、少なくとも前後のブロックを一次的に記憶するバッファ１１４、前後のブロックの同期ヘッダが、中間ブロックの同期ヘッダを訂正可能な条件を満たすかを判定する判定部１１５、及び、前後のブロックの同期ヘッダから推測された値に、中間ブロックの同期ヘッダを訂正する訂正部１１６を備える。なお、エラー訂正部１１３によって実行される処理の詳細は、図４を用いて後述する。
【００２４】
デコーダ１１７は、ブロックからペイロードを抽出し、６４ビット（８バイト）データへ復号化する。
【００２５】
エンコーダ１１８は、６４ビット（８バイト）データに、同期ヘッダを付加し、６６ビットのブロックへ符号化する。
【００２６】
スクランブラ１１９は、ブロックのペイロードデータにスクランブル処理を行う。このスクランブル処理によって、転送されるデータのディスパリティが０になるように、データが調整される。
【００２７】
ネットワークノード１０４は、データを送受信するインターフェース（ポート）、データを出力するポートを決定するルーティング部、ネットワークノードの動作を制御するプロセッサ、及び、プロセッサで実行されるプログラム及び当該プログラムの実行に必要なデータを格納するメモリを備える。
【００２８】
以上、ネットワークノード１０４について説明したが、ネットワークノード１０２も同じ構成及び機能である。
【００２９】
図３Ａは、ＸＧＭＩＩ上のイーサフレームと１０ギガビットイーサネット上のデータ列との変換を説明する図である。
【００３０】
１０ギガビットイーサネット上のデータ列３０５は、ＸＧＭＩＩ（10 Gigabit Media Independent Interface）上の所定長のイーサフレーム３０１を８バイト毎に分割して、分割されたデータに２ビットの同期ヘッダを付加することによって、１０ギガビットイーサネット上を転送される６６ビットのブロックを生成する。
【００３１】
具体的には、ＸＧＭＩＩ上のイーサフレーム３０１は、その先頭に８ビットの開始コード（Ｓ）が設けられ、その末尾に８ビットの末尾コード（Ｔ）が設けられ、開始コードと末尾コードとの間にデータ領域が設けられる。また、フレーム間にはインターフレームギャップ（ＩＦＧ）が設けられる。
【００３２】
エンコーダ１１８は、このイーサフレーム３０１を、８バイト毎に分割したデータを生成する（３０２）。このとき、開始コードは８バイト中の１番目又は５番目のバイトだけに割り当て可能である。すなわち、開始コードを含む８バイトのデータは、「ＳＤＤＤＤＤＤＤ」又は「ＩＩＩＩＳＤＤＤ」となる。
【００３３】
そして、分割された８バイトのデータを所定のルールに従ってエンコードし、その後、２ビットの同期ヘッダを付与する（３０３）。８バイトのデータはユーザデータである場合、同期ヘッダ”０１”が付与され、８バイトのデータは制御コードを含むデータである場合、同期ヘッダ”１０”が付与される。
【００３４】
その後、同期ヘッダを除くペイロードのデータをスクランブルして、１０ギガビットイーサネット上のデータ列３０５が生成される。
【００３５】
一方、１０ギガビットイーサネット上のデータ列３０５は、デスクランブル処理によって、エンコードされた状態のデータが復元される。その後、同期ヘッダが破損しているか否かが判定され、破損している同期ヘッダが修復される（３０４、３０３）。この同期ヘッダの訂正処理は、図４、図５を用いて後述する。この同期ヘッダの訂正処理は、論理回路によるロジックによって実装されてもよく、プロセッサがメモリに格納されたプログラムを実行することによるロジックによって実装されてもよい。
【００３６】
同期ヘッダが修復されたデータは、同期ヘッダを外して、８バイトのデータを生成し、８バイト毎にデコードされる（３０２）。その後、デコードされたデータ結合してパケットを組み立て、イーサフレーム３０１を再構成する。
【００３７】
図３Ｂは、エンコーダ１１８によるエンコードの例を説明する図である。
【００３８】
前述したように、８バイトのペイロードにユーザデータ（Ｄ）のみが含まれる場合、このブロックはデータブロックであり、同期ヘッダは”０１”となる。一方、８バイトのペイロードに制御コード（Ｓ、Ｔ、Ｉ等）が含まれる場合、このブロックはコントロールブロックであり、同期ヘッダは”１０”となる。
【００３９】
コントロールブロックの場合、ペイロードの先頭（すなわち、同期ヘッダの直後）に８ビットの、ＢｌｏｃｋＴｙｐｅＦｉｅｌｄが設けられる。このＢｌｏｃｋＴｙｐｅＦｉｅｌｄは、ブロックに含まれるユーザデータ（Ｄ）のエンコードの方法を示す。すなわち、ＢｌｏｃｋＴｙｐｅＦｉｅｌｄの値によって、ブロックに含まれる制御コードの種類、数、及び位置が決まる。
【００４０】
図４は、第１の実施の形態のエラー訂正処理のフローチャートであり、このエラー訂正処理はエラー訂正部１１３によって実行される。なお、エラー訂正部１１３は、論理回路によって機能するものであっても、ネットワークノードに備わるプロセッサがメモリに格納されたプログラムを実行することによって機能するものであってもよい。また、このエラー訂正処理は、ブロック同期部１１１によるブロックの同期、デスクランブラ１１２によるデスクランブルが確立した後に実行される。
【００４１】
まず、同期ヘッダの値によって、同期ヘッダが破損しているか否かを判定する（Ｓ１０１）。具体的には、正しい同期ヘッダは”０１”又は”１０”であるため、同期ヘッダが、”００”又は”１１”であれば、同期ヘッダが破損していると判定できる。
【００４２】
次に、バッファ１１４に格納されている前後のブロックから同期ヘッダを抽出して、抽出された同期ヘッダから、中間ブロックの同期ヘッダの値を推測可能か否かを判定する（Ｓ１０２）。すなわち、前後のブロックの同期ヘッダが、中間ブロックの同期ヘッダを訂正可能な条件を満たすか否かを判定する。具体的には、前ブロックの同期ヘッダが”０１”であり、かつ、後ブロックの同期ヘッダが”０１”である場合、中間ブロックの同期ヘッダを訂正可能な条件を満たし、その中間ブロックの同期ヘッダの値を推測して訂正することができる。
【００４３】
判定の結果、この条件を満たした場合、中間ブロックの同期ヘッダの値は”０１”であると推測し、この中間ブロックの同期ヘッダを”０１”に訂正する（Ｓ１０３）。
【００４４】
これは、図４に示すように、一つのブロックが、パケットの開始を示すコード”Ｓ”とパケットの終了を示すコード”Ｔ”との両方を含むことはない。また、ブロックの同期ヘッダが”０１”である場合、そのブロックは、ペイロードにユーザデータのみを含むデータブロックである。よって、この中間ブロックはデータブロックであると推測することができ、中間ブロックの同期ヘッダを”０１”に訂正することができる。
【００４５】
一方、前後のブロックの同期ヘッダのいずれかが”０１”でない場合、同期ヘッダの値を推測することはできないので、この中間ブロックの同期ヘッダを訂正しない（Ｓ１０４）。なお、破損した同期ヘッダが訂正されない場合、そのブロックのデータを含むイーサフレームを正しく組み立てることができない。このため、上位層（データリンク層、ネットワーク層等）において、この中間ブロックを含むイーサフレームが再送されるように、制御される。
【００４６】
次に、図５を用いて、中間ブロックの同期ヘッダの訂正について説明する。
【００４７】
処理対象である中間ブロックの同期ヘッダ５０２が”００”であるので、Ｓ１０１において、この同期ヘッダ５０２は誤っていると判定される。そこで、バッファに格納されている前後のブロックの同期ヘッダ５０１及び５０３を参照する。この場合、前後のブロックの同期ヘッダ５０１及び５０３は共に”０１”なので、前後のブロックの同期ヘッダ５０１及び５０３から、中間ブロックの同期ヘッダが”０１”であることを推測可能である。
【００４８】
すなわち、本実施の形態では、所定長のイーサネットフレームを分割して生成された６６ビットのブロックを、ネットワークノード間で転送するので、転送されるブロックは分割前のイーサネットフレームの性質（前後のブロックのデータとの連続性）をそのまま引き継いでいる。このため、ブロックに含まれるデータ、特に、制御コードの並びには規則性がある。本発明の実施の形態では、この規則性に着目して、ブロックがデータブロックであるか、コントロールブロックであるかを判定して、破損した同期ヘッダを訂正する。
【００４９】
このようにして、第１の実施の形態では、中間ブロックの同期ヘッダ５０２を”０１”に訂正することができる。
【００５０】
以上説明したように、本発明の第１の実施に形態によると、中間ブロックの同期ヘッダが正しい値でない場合、前後のブロックの同期ヘッダに基づいて、中間ブロックの同期ヘッダの値を推測可能かを判定する。そして、中間ブロックの同期ヘッダの値を推測できる条件を満たす場合、前後のブロックと中間ブロックとが整合するように、中間ブロックの同期ヘッダを訂正する。このため、同期ヘッダが破損したブロックの破棄が減少し、パケットの再送回数を減少することができる。また、パケットの再送信が減るので、伝送路上のトラフィックの増加を抑制することができる。さらに、トラフィックの増加を抑制することによって、ネットワークノードの消費電力を低減することができる。
【００５１】
＜実施形態２＞
次に、本発明の第２の実施の形態について説明する。
【００５２】
前述した第１の実施の形態では、中間ブロックの同期ヘッダを訂正するために、前後のブロックの同期ヘッダを用いたが、第２の実施の形態では、前後のブロックの同期ヘッダ及びブロックタイプフィールドを用いる。さらに、予備的に、中間ブロックのブロックタイプフィールドを用いてもよい。
【００５３】
なお、第２の実施の形態のシステムの構成及びネットワークノードのハードウェア構成は、前述した第１の実施の形態と同じである。なお、第２の実施の形態において、前述した第１の実施の形態と同じ構成、処理には同じ符号を付し、それらの説明は省略する。
【００５４】
第２の実施の形態のネットワークノードは、前述した第１の実施の形態のネットワークノードと比較し、エラー訂正部１１３の機能が異なる。
【００５５】
すなわち、第２の実施の形態のエラー訂正部１１３は、ブロックの同期ヘッダが破損している場合に、当該ブロックと前後のブロックの同期ヘッダ及びブロックタイプフィールドの値を参照することによって、当該中間ブロックの正しい同期ヘッダの値を推測し、同期ヘッダを訂正する。
【００５６】
具体的には、エラー訂正部１１３は、ブロックの同期ヘッダが破損している場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドが、中間ブロックの同期ヘッダを訂正可能な条件を満たすかを判定する。そして、訂正可能な条件を満たした場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドから推測された値に、中間ブロックの同期ヘッダを訂正する。
【００５７】
ここで、ブロックタイプフィールドとは、ブロックに含まれるデータの種別を表す情報であって、転送される６６ビットのブロックがコントロールブロックである場合、ペーロードの最初の８ビット（同期ヘッダの直後の１バイト）に割り当てられるデータ領域であり、図３Ｂに示すように、転送されるデータに含まれるユーザデータのバイト数及び位置、制御コードの内容、数及び位置を表す。すなわち、同期ヘッダが”１０"である場合、同期ヘッダの直後の８ビットのデータによって、コントロールブロックに含まれる制御コードを知ることができる。
【００５８】
また、第２の実施の形態において、判定部１１５は、前後のブロックの同期ヘッダ及びブロックタイプフィールドが、中間ブロックの同期ヘッダを訂正可能な条件を満たすかを判定する。訂正部１１６は、前後のブロックの同期ヘッダ及びブロックタイプフィールドから推測された値に、中間ブロックの同期ヘッダを訂正する。
【００５９】
図６は、第２の実施の形態のエラー訂正処理のフローチャートであり、このエラー訂正処理はエラー訂正部１１３によって実行される。なお、前述した第１の実施の形態と同じく、エラー訂正部１１３は、論理回路によって機能するものであっても、ネットワークノードに備わるプロセッサがメモリに格納されたプログラムを実行することによって機能するものであってもよい。また、このエラー訂正処理は、ブロック同期部１１１によるブロックの同期、スクランブラ１１２によるデスクランブルが確立した後に実行される。
【００６０】
まず、前述した第１の実施の形態と同様に、同期ヘッダが破損しているか否かを判定し（Ｓ１０１）、前後のブロックの同期ヘッダから、当該ブロックの同期ヘッダを推測可能か否かを判定し（Ｓ１０２）、中間ブロックの同期ヘッダを、推測された値に訂正する（Ｓ１０３）。
【００６１】
一方、Ｓ１０２において、前後のブロックの同期ヘッダが中間ブロックの同期ヘッダを訂正できる条件に一致しないと判定された場合、前後のブロックのブロックタイプフィールドを参照し（Ｓ１１１）、前後のブロックのブロックタイプフィールドから、中間ブロックの同期ヘッダの値を推測可能か、すなわち、前後のブロックの同期ヘッダ及びブロックタイプフィールドが中間ブロックの同期ヘッダを訂正できる条件に一致するか否かを判定する（Ｓ１１２）。その結果、中間ブロックの同期ヘッダの値を推測可能である場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドから、中間ブロックの同期ヘッダの値を推測し、中間ブロックのＳｙｎｃＨｅａｄｅｒを推測された値に訂正する（Ｓ１１３）。
【００６２】
なお、Ｓ１１２〜Ｓ１１３の処理の具体的内容は、図７及び図１１を用いて説明する。この同期ヘッダの訂正処理は、論理回路によるロジックによって実装されてもよく、前述した第１の実施の形態と同じく、プロセッサがメモリに格納されたプログラムを実行することによるロジックによって実装されてもよい。
【００６３】
一方、Ｓ１１２において、中間ブロックの同期ヘッダを訂正可能な条件を満たさないと判定された場合、この中間ブロックの同期ヘッダを訂正しない（Ｓ１０４）。この場合、前述した第１の実施の形態と同様に、そのブロックのデータを含むイーサフレームを正しく組み立てることができないので、この中間ブロックを含むイーサフレームの再送制御がされる。
【００６４】
図７は、第２の実施の形態のエラー訂正処理（図６のＳ１１２〜Ｓ１１３）の詳細を示すフローチャートである。
【００６５】
第２の実施の形態のエラー訂正処理（図６）において、前後のブロックの同期ヘッダによって中間ブロックの同期ヘッダを訂正できないと判定された場合、前後のブロックのブロックタイプフィールドを参照する（Ｓ１１１）。
【００６６】
その後、前ブロックの同期ヘッダが”０１”であり、かつ、後ブロックの同期ヘッダが”１０”であるかを判定する（Ｓ１２１）。前ブロックの同期ヘッダが”０１”であり、かつ、後ブロックの同期ヘッダが”１０”である場合、さらに、後ブロックのブロックタイプフィールドが”０ｘ３３”であるかを判定する（Ｓ１２２）。
【００６７】
その結果、前ブロックの同期ヘッダが”０１”であり、後ブロックの同期ヘッダが”１０”であり、かつ、後ブロックのブロックタイプフィールドが”０ｘ３３”である場合、中間ブロックの同期ヘッダを訂正することができる条件を満たす。すなわち、この場合、後ブロックはフレーム先頭（開始コードＳ）を含むので、処理対象の中間ブロックはフレーム末尾（末尾コードＴ）を含み、コントロールブロックであると推測できる。よって、中間ブロックの同期ヘッダを訂正するためにＳ１２７に進む。
【００６８】
一方、前ブロックの同期ヘッダが”０１”でなく、又は、後ブロックの同期ヘッダが”１０”でない場合、他の条件を満たすかを探索するために、Ｓ１２５に進む。
【００６９】
Ｓ１２５において、前ブロックの同期ヘッダが”１０”であり、後ブロックの同期ヘッダが”１０”であり、さらに、前ブロックのブロックタイプフィールドが”０ｘ８７”であり、かつ、後ブロックのブロックタイプフィールドが”０ｘ１ｅ”であるかを判定する（Ｓ１２５、Ｓ１２６）。
【００７０】
その結果、前ブロックの同期ヘッダが”１０”であり、後ブロックの同期ヘッダが”１０”であり、前ブロックのブロックタイプフィールドが”０ｘ８７”であり、かつ、後ブロックのブロックタイプフィールドが”０ｘ１ｅ”である場合、中間ブロックの同期ヘッダを訂正することができる条件を満たす。この場合、この前ブロックはフレーム末尾（末尾コードＴ）を含み、後ブロックはＩＦＧを含む。処理対象の中間ブロックは、前後をＩＦＧに挟まれていることから、ＩＦＧを含み、コントロールブロックであると推測できる。よって、中間ブロックの同期ヘッダを訂正するためにＳ１２７に進む。
【００７１】
Ｓ１２７では、処理対象の中間ブロックのブロックタイプフィールドを参照して、中間ブロックの同期ヘッダを訂正するか否かを判定する。すなわち、前後のブロックの同期ヘッダ及びブロックタイプフィールドから推測された中間ヘッダの同期ヘッダが、中間ブロックのブロックタイプフィールドと整合するか否かを判定する。これは、同期ヘッダが”１０”である場合、ブロックタイプフィールドは所定の値しか取り得ないからである。
【００７２】
その結果、推測された中間ヘッダの同期ヘッダが、中間ブロックのブロックタイプフィールドと整合する場合、推測された中間ヘッダの同期ヘッダの値が正しいことが確認されたので、Ｓ１２８に進み、中間ブロックの同期ヘッダを”１０”に訂正する。
【００７３】
一方、推測された中間ヘッダの同期ヘッダが、中間ブロックのブロックタイプフィールドと整合しない場合、推測された中間ヘッダの同期ヘッダの値か、ブロックタイプフィールドの値が誤っている可能性がある。この場合、以下の二つの処理が考えられる。
【００７４】
（１）同期ヘッダを訂正する。推測された中間ヘッダの同期ヘッダが、中間ブロックのブロックタイプフィールドと整合しない場合、同期ヘッダの訂正が正しい確率が低い。しかし、ブロックを正しくデコードできる確率を高め、パケット廃棄率を低減するためには、同期ヘッダの訂正が正しい可能性が低くても、同期ヘッダを訂正するとよい。
【００７５】
（２）同期ヘッダを訂正しない。推測された中間ヘッダの同期ヘッダが、中間ブロックのブロックタイプフィールドと整合しない場合、同期ヘッダの訂正が正しい確率が低いので、データの誤りを防止するためには、同期ヘッダを訂正せず、上位層においてフレームを再送するように制御した方がよい。すなわち、データの正確性を優先するためには、この場合に同期ヘッダを訂正しない方がよい。
【００７６】
この二つの処理は、転送されるデータの品質、すなわち、データ転送速度を優先するか、データの正確性を優先するかによって変えるとよい。また、この二つの処理は、中間ブロックの同期ヘッダが訂正可能であると判定される、前後のブロックの同期ヘッダ及びブロックタイプフィールドの組み合わせ毎に選択可能に設定されてもよい。
【００７７】
なお、Ｓ１２７の処理は任意のステップであり、中間ブロックのブロックタイプフィールドを参照して、中間ブロックの同期ヘッダを訂正するかを判定しなくてもよい。
【００７８】
その後、同期ヘッダを訂正する場合、処理対象の中間ブロックの同期ヘッダを”１０”に訂正する（Ｓ１２８）。
【００７９】
一方、前後のブロックの同期ヘッダ及びブロックタイプフィールドの値が何れのエントリとも一致しない場合、同期ヘッダの訂正候補が得られないので、判定対象の中間ブロックの同期ヘッダは訂正不可と判定する。具体的には、Ｓ１２２でＮｏと判定された場合、Ｓ１２５でＮｏと判定された場合、Ｓ１２６でＮｏと判定された場合、Ｓ１０４に進み、処理対象の中間ブロックの同期ヘッダを訂正しない。
【００８０】
次に、図８〜図１０を用いて、中間ブロックの同期ヘッダの訂正について、前後のブロックの同期ヘッダ及びブロックタイプフィールドから、中間ブロックの同期ヘッダの値を推測可能な場合（図８、図９）、及び、中間ブロックの同期ヘッダの値を推測不可能な場合（図１０）について説明する。
【００８１】
図８に示す場合、処理対象である中間ブロックの同期ヘッダ５１２が”００”であるので、Ｓ１０１において、この同期ヘッダ５１２は誤っていると判定される。そこで、バッファに格納されている前後のブロックの同期ヘッダ５１１及び５１３を参照する。前ブロックの同期ヘッダ５１１は”０１”で、後ブロックの同期ヘッダ５１３は”１０”なので、前後のブロックの同期ヘッダ５１１及び５１３から中間ブロックの同期ヘッダの値を推測できない（Ｓ１０２、Ｓ１２１）。そこで、後ブロックのブロックタイプフィールド５１５を参照する。なお、図８に示す場合は、前ブロックは、その同期ヘッダが”０１”である、データブロックであるため、ブロックタイプフィールドが格納されるべき箇所には、ユーザデータが格納されている。
【００８２】
その結果、後ブロックのブロックタイプフィールド５１５が”０ｘ３３”であることから、この後ブロックはフレーム先頭（開始コードＳ）を含むことが分かる（Ｓ１２２）。このため、処理対象の中間ブロックはフレーム末尾（末尾コードＴ）を含み、コントロールブロックであると推測できる。このため、中間ブロックの同期ヘッダ５１２を”１０”に訂正することができる。
【００８３】
図８に示す場合、中間ブロックのブロックタイプフィールドは”０ｘ８７”であれば、同期ヘッダの値の推測結果は正しいので、同期ヘッダが訂正される。一方、中間ブロックのブロックタイプフィールドが”０ｘ８７”でなくても、同期ヘッダを訂正する又は訂正しない、の何れかの処理が選択的に実行される（Ｓ１２７）。
【００８４】
図９に示す場合、処理対象である中間ブロックの同期ヘッダ５２２が”１１”であるので、Ｓ１０１において、この同期ヘッダ５２２は誤っていると判定される。そこで、バッファに格納されている前後のブロックの同期ヘッダ５２１及び５２３を参照する。前ブロックの同期ヘッダ５２１は”０１”で、後ブロックの同期ヘッダ５２３は”１０”なので、前後のブロックの同期ヘッダ５２１及び５２３から、中間ブロックの同期ヘッダの値を推測できない（Ｓ１０２、Ｓ１２５）。そこで、前後のブロックのブロックタイプフィールド５２４、５２６を参照する。
【００８５】
その結果、前ブロックのブロックタイプフィールド５２４が”０ｘ８７”であることから、この前ブロックはフレーム末尾（末尾コードＴ）及びＩＦＧを含むことが分かる。また、後ブロックのブロックタイプフィールド５２６が”０ｘ１ｅ”であることから、この後ブロックはＩＦＧを含むことが分かる。このため、処理対象の中間ブロックは前後をＩＦＧに挟まれていることから、ＩＦＧを含み、コントロールブロックであると推測できる。このため、中間ブロックの同期ヘッダ５２２を”１０”に訂正することができる。
【００８６】
図９に示す場合、中間ブロックのブロックタイプフィールドは”０ｘ１ｅ”であれば、同期ヘッダの値の推測結果は正しいが、もし中間ブロックのブロックタイプフィールドが”０ｘ１ｅ”でなくても、同期ヘッダを訂正する又は訂正しない、の何れかの処理が選択的に実行される（Ｓ１２７）。
【００８７】
図１０に示す場合、処理対象である中間ブロックの同期ヘッダ５３２が”００”であるので、Ｓ１０１において、この同期ヘッダ５２２は誤っていると判定される。そこで、バッファに格納されている前後のブロックの同期ヘッダ５３１及び５３３を参照する。前ブロックの同期ヘッダ５３１は”１０”で、後ブロックの同期ヘッダ５３３は”１０”なので、前後のブロックの同期ヘッダ５３１及び５３３から、中間ブロックの同期ヘッダの値を推測可能な条件を満たさない（Ｓ１０２、Ｓ１２５）。そこで、前後のブロックのブロックタイプフィールド５３４、５３６を参照する。
【００８８】
その結果、後ブロックのブロックタイプフィールド５３６が”０ｘ３３”であることから、この後ブロックはフレーム先頭（開始コードＳ）を含むことが分かる。また、前ブロックのブロックタイプフィールド５３４が”０ｘ３３”であることから、この前ブロックはフレーム先頭（開始コードＳ）を含むことが分かる（Ｓ１２６）。
【００８９】
このとき、開始コード（Ｓ）を含む二つのブロックの間には、末端コード（Ｔ）を含むブロックがあるべきである。しかし、当該中間ブロックのブロックタイプフィールドを参照した結果の値が、例えば０ｘ３３であり、当該中間ブロックは開始コード（Ｓ）を含むので、当該中間ブロックの同期ヘッダを訂正しても、前後のブロックとの整合性がとれない。よって、中間ブロックの同期ヘッダ５３２を訂正しない（Ｓ１２７）。
【００９０】
＜変形例＞
第２の実施の形態のエラー訂正処理は、図７に示すロジックではなく、前後のブロックの同期ヘッダ及びブロックタイプフィールドから、特定組み合わせを見つけることによって、中間ブロックの同期ヘッダの訂正可否を判定することもできる。次に、この変形例について説明する。
【００９１】
図１１は、第２の実施の形態のエラー訂正テーブル２００を説明する図である。
【００９２】
第２の実施の形態のエラー訂正テーブル２００は、前ブロックの同期ヘッダ２０１、前ブロックのブロックタイプフィールド２０２、後ブロックの同期ヘッダ２０３、後ブロックのブロックタイプフィールド２０４、中間ブロックのブロックタイプフィールド２０５及び同期ヘッダの訂正候補２０６を含む。エラー訂正テーブル２００は、ネットワークノードのメモリに格納されており、判定部１１５によって参照される。なお、後述するように、エラー訂正テーブル２００は、中間ブロックのブロックタイプフィールド２０５を含まなくてもよい。
【００９３】
前ブロックの同期ヘッダ２０１は、処理対象の中間ブロックの前に受信したブロックの同期ヘッダの値である。前ブロックのブロックタイプフィールド２０２は、処理対象の中間ブロックの前に受信したブロックのブロックタイプフィールドの値である。後ブロックの同期ヘッダ２０３は、処理対象の中間ブロックの後に受信したブロックの同期ヘッダの値である。後ブロックのブロックタイプフィールド２０４は、処理対象の中間ブロックの後に受信したブロックのブロックタイプフィールドの値である。中間ブロックのブロックタイプフィールド２０５は、処理対象の中間ブロックのブロックタイプフィールドの値である。同期ヘッダの訂正候補２０６は、処理対象の中間ブロックの同期ヘッダの訂正候補である。なお、各欄において”−”はその欄はどの値でも条件を満たすことを意味する。
【００９４】
本実施の形態では、処理対象の中間ブロックの同期ヘッダが破損している場合、バッファに格納されている前ブロックの同期ヘッダ及びブロックタイプフィールド、後ブロックの同期ヘッダ及びブロックタイプフィールドが、各々、前ブロックの同期ヘッダ２０１、前ブロックのブロックタイプフィールド２０２、後ブロックの同期ヘッダ２０３及び後ブロックのブロックタイプフィールド２０４と一致するかを判定する。
【００９５】
前後のブロックの同期ヘッダ及びブロックタイプフィールドの値が何れかのエントリと一致した場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドによって、中間ブロックの同期ヘッダの値を推測できる条件を満たし、当該中間ブロックの同期ヘッダは、このエントリの同期ヘッダの訂正候補２０６であると推測されるので、エラー訂正テーブル２００から同期ヘッダの訂正候補２０６を取得し、この同期ヘッダの訂正候補２０６によって中間ブロックの同期ヘッダを訂正する。
【００９６】
この場合、中間ブロックのブロックタイプフィールド２０５を参照してもよい。前後のブロックの同期ヘッダ及びブロックタイプフィールドがエントリと一致し、かつ、中間ブロックのブロックタイプフィールドがエントリと一致しない場合、中間ブロックの同期ヘッダを正しく訂正できる可能性が低いが、同期ヘッダを訂正しても、同期ヘッダを訂正しなくてもよい。
【００９７】
一方、前後のブロックの同期ヘッダ及びブロックタイプフィールドの値が何れのエントリとも一致しない場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドによって、中間ブロックの同期ヘッダの値を推測できる条件を満たさず、同期ヘッダの訂正候補が得られないので、判定対象の中間ブロックの同期ヘッダは訂正不可と判定する。
【００９８】
なお、エントリ２１１は、ブロックタイプフィールドによらず、前後のブロックの同期ヘッダのみによって中間ブロックの同期ヘッダを訂正可否を判定する処理（図６のＳ１０１〜Ｓ１０３）に対応するエントリである。すなわち、前後のブロックのブロックタイプフィールドの値によって判定をする場合だけでなく、前後のブロックの同期ヘッダのみによって判定をする場合にも、エラー訂正テーブル２００を用いることができる。
【００９９】
具体的には、エントリ２２１は、図５に示すように、前後のブロックの同期ヘッダが、共に”０１”である場合、中間ブロックの同期ヘッダの訂正候補を”０１”に決めることができる。
【０１００】
また、エントリ２１２は、図８に示すように、前ブロックの同期ヘッダが”０１”であり、後ブロックの同期ヘッダが”１０”であり、後ブロックのブロックタイプフィールドが”０ｘ３３”である場合、中間ブロックの同期ヘッダの訂正候補は”１０”に決めることができる。この場合、中間ブロックのブロックタイプフィールドは”０ｘ８７”であれば、同期ヘッダの値の推測結果は正しいが、もし中間ブロックのブロックタイプフィールドが”０ｘ８７”でなくても、同期ヘッダを訂正する又は訂正しない、の何れかの処理が選択的に実行される。
【０１０１】
また、エントリ２１３は、図９に示すように、前ブロックの同期ヘッダが”１０”であり、前ブロックのブロックタイプフィールドが”０ｘ８７”であり、後ブロックの同期ヘッダが”１０”であり、後ブロックのブロックタイプフィールドが”０ｘ１ｅ”である場合、中間ブロックの同期ヘッダの訂正候補を”１０”に決めることができる。この場合、中間ブロックのブロックタイプフィールドは”０ｘ１ｅ”であれば、同期ヘッダの値の推測結果は正しいが、もし中間ブロックのブロックタイプフィールドが”０ｘ１ｅ”でなくても、同期ヘッダを訂正する又は訂正しない、の何れかの処理が選択的に実行される。
【０１０２】
また、エラー訂正テーブル２００に、中間ブロックのブロックタイプフィールドが正しくない場合、同期ヘッダを訂正する又は訂正しないを決定するためのフラグを設け、エントリ毎に、同期ヘッダを訂正するか否かを制御してもよい。この場合、このフラグは、管理者によって設定可能にしてもよい。
【０１０３】
なお、図７〜図１１に示した前後のブロックの同期ヘッダ及びブロックタイプフィールドの組み合わせは例示であり、本願発明者の研究によると、数十種類の組み合わせにおいて、中間ブロックの同期ヘッダの値を推測できる条件を満たし、中間ブロックの同期ヘッダの値を推測することができる。
【０１０４】
以上説明したように、本発明の第２の実施に形態によると、中間ブロックの同期ヘッダが正しい値でない場合、前後のブロックの同期ヘッダ及びブロックタイプフィールドに基づいて、中間ブロックの値を推測可能かを判定する。そして、中間ブロックの値を推測できる条件を満たす場合、前後のブロックと中間ブロックとが整合するように、中間ブロックの同期ヘッダを訂正する。このため、前述した第１の実施の形態の効果に加え、第１の実施の形態より多くの場合に中間ブロックの同期ヘッダを訂正することができる。
【０１０５】
＜ＭＰＬＳネットワークへの実装＞
図１２は、本発明が適用されたＭＰＬＳネットワークの説明図である。
【０１０６】
ユーザデータをクライアント装置１−１からクライアント装置２−１へ転送する場合、クライアント装置１−１から送信されたイーサフレームを、ＭＰＬＳエッジ装置１１にてオーバーヘッド（ＯＨ）を終端し、ユーザデータを抽出し、宛先クライアント装置２−１が接続されたＭＰＬＳエッジ装置１２を特定する。ＯＨには、宛先であるクライアント装置２−１のアドレス（ＩＰアドレスやディスティネーションアドレスなど）を含む。なお、図１２ではユーザデータはＳＤＨ／ＳＯＮＥＴ信号を例に説明するが、イーサネット信号など様々な信号でも同じである。
【０１０７】
そして、特定されたエッジノードを表すＭＰＬＳラベル（ＴＬＳＰ）を、抽出されたユーザデータに付して、ユーザデータをカプセル化する。ＴＬＳＰを用いたカプセル化によって、ＭＰＬＳネットワーク内のＭＰＬＳコア装置２１〜２３は、クライアント装置２−１の宛先を見ることなく、ＭＰＬＳネットワークワーク内でエンド・ツー・エンドでパケットを転送（以下、ラベルスイッチと呼ぶ）できる。
【０１０８】
このとき、ＭＰＬＳエッジ装置１１は、６４Ｂ／６６Ｂ符号化を用いて、クライアント装置１−１１から受信したユーザデータをカプセル化した後、６６ビットのブロックに変換し、ＭＰＬＳコア装置２１に転送する。ＭＰＬＳコア装置２１〜２ｎは、前段のＭＰＬＳ装置から送信された６６ビットのブロックからイーサフレームを再構築し、ＭＰＬＳラベルによって、次のＭＰＬＳ装置を特定し、再構築されたイーサフレームを６６ビットのブロックに変換して、次段のＭＰＬＳ装置に送る。
【０１０９】
ＭＰＬＳエッジ装置１２は、前段のＭＰＬＳコア装置から送信された６６ビットのブロックからイーサフレームを再構築し、ＴＬＳＰを終端して、クライアント装置２−１へユーザデータを転送する。
【０１１０】
このように、ＭＰＬＳネットワークに備わるＭＰＬＳ装置は、前段のＭＰＬＳ装置から送信された６６ビットのブロックからイーサフレームを再構築する際に、６６ビットのブロックの破損している同期ヘッダを、前後のブロックからが破損している同期ヘッダを訂正する。
【符号の説明】
【０１１１】
１０１、１０５ クライアント端末
１０２、１０４ ネットワークノード
１０３ ネットワーク
１１１ ブロック同期部
１１２ デ・スクランブラ
１１３ エラー訂正部
１１４ バッファ
１１５ 判定部
１１６ 訂正部
１１７ デコーダ
１１８ エンコーダ
１１９ スクランブラ
【特許請求の範囲】
【請求項１】
フレームを第１の所定ビットのデータに分割し、前記分割されたデータに第２の所定ビットの同期ヘッダを付加することによって生成されるブロックを転送するデータ転送装置であって、
前記データ転送装置の動作を処理するロジックと、転送されるブロックを格納するバッファと、前記データ転送装置へのデータを入出力するインターフェースとを備え、
前記ブロックは、連続して順に転送される第１のブロック、第２のブロック及び第３のブロックを含み、
前記ロジックは、
前記第１のブロックに含まれる第１の同期ヘッダ、前記第２のブロックに含まれる第２の同期ヘッダ及び前記第３のブロックに含まれる第３の同期ヘッダを取得し、
前記第２の同期ヘッダが正しい値でない場合、前記第２のブロックが前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを、前記第１の同期ヘッダと前記第３の同期ヘッダとに基づいて推測できるか否かの第１の判定をし、
前記推測された値に前記第２の同期ヘッダを訂正することを特徴とするデータ転送装置。
【請求項２】
前記各ブロックは、当該ブロックに含まれるデータの種別を表す情報を含み、
前記ロジックは、
前記第１の判定において、前記第２の同期ヘッダを推測できないと判定された場合、
前記第１のブロックに含まれる前記情報と前記第３のブロックに含まれる前記情報とに基づいて、前記第２の同期ヘッダを推測できるか否かの第２の判定をし、
前記第２の判定の結果に基づいて、前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを訂正することを特徴とする請求項１に記載のデータ転送装置。
【請求項３】
前記データの種別を表す情報は、前記ブロックのデータ部の最先の位置に配置されることを特徴とする請求項２に記載のデータ転送装置。
【請求項４】
前記データ転送装置は、
ＭＰＬＳラベルを用いてカプセル化されたフレームを転送するものであって、
ＭＰＬＳネットワークの入口エッジに設けられた場合、前記ＭＰＬＳラベルをフレームに付加した後、前記ブロックを生成し、
ＭＰＬＳネットワークの出口エッジに設けられた場合、前記同期ヘッダの訂正を試みた後、受信したフレームから前記ＭＰＬＳラベルを外すことを特徴とする請求項１から３のいずれか一つに記載のデータ転送装置。
【請求項５】
前記ロジックは、前記第１の同期ヘッダが、前記第１のブロックにユーザデータのみが含まれていることを示し、かつ、前記第３の同期ヘッダが、前記第３のブロックにユーザデータのみが含まれていることを示す場合、前記第２のブロックにユーザデータのみが含まれていることを示す値に、前記第２の同期ヘッダを訂正することを特徴とする請求項１に記載のデータ転送装置。
【請求項６】
少なくとも２台のノード間でデータを転送するデータ転送システムであって、
前記各ノードは、
前記ノードの動作を処理するロジックと、転送されるブロックを格納するバッファと、前記ノードへのデータを入出力するインターフェースとを備え、
フレームを第１の所定ビットのデータに分割し、前記分割されたデータに第２の所定ビットの同期ヘッダを付加することによって生成されるブロックを転送し、
前記ブロックは、連続して順に転送される第１のブロック、第２のブロック及び第３のブロックを含み、
前記各ノードは、
前記第１のブロックに含まれる第１の同期ヘッダ、前記第２のブロックに含まれる第２の同期ヘッダ及び前記第３のブロックに含まれる第３の同期ヘッダを取得し、
前記第２の同期ヘッダが正しい値でない場合、前記第２のブロックが前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを、前記第１の同期ヘッダと前記第３の同期ヘッダとに基づいて推測できるか否かの第１の判定をし、
前記推測された値に前記第２の同期ヘッダを訂正することを特徴とするデータ転送システム。
【請求項７】
前記各ブロックは、当該ブロックに含まれるデータの種別を表す情報を含み、
前記各ノードは、
前記第１の判定において、前記第２の同期ヘッダを推測できないと判定された場合、
前記第１のブロックに含まれる前記情報と前記第３のブロックに含まれる前記情報とに基づいて、前記第２の同期ヘッダを推測できるか否かの第２の判定をし、
前記第２の判定の結果に基づいて、前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを訂正することを特徴とする請求項６に記載のデータ転送システム。
【請求項８】
前記データの種別を表す情報は、前記ブロックのデータ部の最先の位置に配置されることを特徴とする請求項７に記載のデータ転送システム。
【請求項９】
前記データ転送システムは、ＭＰＬＳラベルを用いてカプセル化されたフレームを転送するＭＰＬＳネットワークであって、
前記ノードは、
前記データ転送システムの入口エッジに設けられた場合、前記ＭＰＬＳラベルをフレームに付加した後、前記ブロックを生成し、
前記データ転送システムの出口エッジに設けられた場合、前記同期ヘッダの訂正を試みた後、受信したフレームから前記ＭＰＬＳラベルを外すことを特徴とする請求項６から８のいずれか一つに記載のデータ転送システム。
【請求項１０】
前記各ノードは、前記第１の同期ヘッダが、前記第１のブロックにユーザデータのみが含まれていることを示し、かつ、前記第３の同期ヘッダが、前記第３のブロックにユーザデータのみが含まれていることを示す場合、前記第２のブロックにユーザデータのみが含まれていることを示す値に、前記第２の同期ヘッダを訂正することを特徴とする請求項６に記載のデータ転送システム。
【請求項１】
フレームを第１の所定ビットのデータに分割し、前記分割されたデータに第２の所定ビットの同期ヘッダを付加することによって生成されるブロックを転送するデータ転送装置であって、
前記データ転送装置の動作を処理するロジックと、転送されるブロックを格納するバッファと、前記データ転送装置へのデータを入出力するインターフェースとを備え、
前記ブロックは、連続して順に転送される第１のブロック、第２のブロック及び第３のブロックを含み、
前記ロジックは、
前記第１のブロックに含まれる第１の同期ヘッダ、前記第２のブロックに含まれる第２の同期ヘッダ及び前記第３のブロックに含まれる第３の同期ヘッダを取得し、
前記第２の同期ヘッダが正しい値でない場合、前記第２のブロックが前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを、前記第１の同期ヘッダと前記第３の同期ヘッダとに基づいて推測できるか否かの第１の判定をし、
前記推測された値に前記第２の同期ヘッダを訂正することを特徴とするデータ転送装置。
【請求項２】
前記各ブロックは、当該ブロックに含まれるデータの種別を表す情報を含み、
前記ロジックは、
前記第１の判定において、前記第２の同期ヘッダを推測できないと判定された場合、
前記第１のブロックに含まれる前記情報と前記第３のブロックに含まれる前記情報とに基づいて、前記第２の同期ヘッダを推測できるか否かの第２の判定をし、
前記第２の判定の結果に基づいて、前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを訂正することを特徴とする請求項１に記載のデータ転送装置。
【請求項３】
前記データの種別を表す情報は、前記ブロックのデータ部の最先の位置に配置されることを特徴とする請求項２に記載のデータ転送装置。
【請求項４】
前記データ転送装置は、
ＭＰＬＳラベルを用いてカプセル化されたフレームを転送するものであって、
ＭＰＬＳネットワークの入口エッジに設けられた場合、前記ＭＰＬＳラベルをフレームに付加した後、前記ブロックを生成し、
ＭＰＬＳネットワークの出口エッジに設けられた場合、前記同期ヘッダの訂正を試みた後、受信したフレームから前記ＭＰＬＳラベルを外すことを特徴とする請求項１から３のいずれか一つに記載のデータ転送装置。
【請求項５】
前記ロジックは、前記第１の同期ヘッダが、前記第１のブロックにユーザデータのみが含まれていることを示し、かつ、前記第３の同期ヘッダが、前記第３のブロックにユーザデータのみが含まれていることを示す場合、前記第２のブロックにユーザデータのみが含まれていることを示す値に、前記第２の同期ヘッダを訂正することを特徴とする請求項１に記載のデータ転送装置。
【請求項６】
少なくとも２台のノード間でデータを転送するデータ転送システムであって、
前記各ノードは、
前記ノードの動作を処理するロジックと、転送されるブロックを格納するバッファと、前記ノードへのデータを入出力するインターフェースとを備え、
フレームを第１の所定ビットのデータに分割し、前記分割されたデータに第２の所定ビットの同期ヘッダを付加することによって生成されるブロックを転送し、
前記ブロックは、連続して順に転送される第１のブロック、第２のブロック及び第３のブロックを含み、
前記各ノードは、
前記第１のブロックに含まれる第１の同期ヘッダ、前記第２のブロックに含まれる第２の同期ヘッダ及び前記第３のブロックに含まれる第３の同期ヘッダを取得し、
前記第２の同期ヘッダが正しい値でない場合、前記第２のブロックが前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを、前記第１の同期ヘッダと前記第３の同期ヘッダとに基づいて推測できるか否かの第１の判定をし、
前記推測された値に前記第２の同期ヘッダを訂正することを特徴とするデータ転送システム。
【請求項７】
前記各ブロックは、当該ブロックに含まれるデータの種別を表す情報を含み、
前記各ノードは、
前記第１の判定において、前記第２の同期ヘッダを推測できないと判定された場合、
前記第１のブロックに含まれる前記情報と前記第３のブロックに含まれる前記情報とに基づいて、前記第２の同期ヘッダを推測できるか否かの第２の判定をし、
前記第２の判定の結果に基づいて、前記第１のブロック及び前記第３のブロックと整合するように、前記第２の同期ヘッダを訂正することを特徴とする請求項６に記載のデータ転送システム。
【請求項８】
前記データの種別を表す情報は、前記ブロックのデータ部の最先の位置に配置されることを特徴とする請求項７に記載のデータ転送システム。
【請求項９】
前記データ転送システムは、ＭＰＬＳラベルを用いてカプセル化されたフレームを転送するＭＰＬＳネットワークであって、
前記ノードは、
前記データ転送システムの入口エッジに設けられた場合、前記ＭＰＬＳラベルをフレームに付加した後、前記ブロックを生成し、
前記データ転送システムの出口エッジに設けられた場合、前記同期ヘッダの訂正を試みた後、受信したフレームから前記ＭＰＬＳラベルを外すことを特徴とする請求項６から８のいずれか一つに記載のデータ転送システム。
【請求項１０】
前記各ノードは、前記第１の同期ヘッダが、前記第１のブロックにユーザデータのみが含まれていることを示し、かつ、前記第３の同期ヘッダが、前記第３のブロックにユーザデータのみが含まれていることを示す場合、前記第２のブロックにユーザデータのみが含まれていることを示す値に、前記第２の同期ヘッダを訂正することを特徴とする請求項６に記載のデータ転送システム。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３Ａ】
【図３Ｂ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１１−１８２２８７（Ｐ２０１１−１８２２８７Ａ）
【公開日】平成２３年９月１５日（２０１１．９．１５）
【国際特許分類】
【出願番号】特願２０１０−４６２６４（Ｐ２０１０−４６２６４）
【出願日】平成２２年３月３日（２０１０．３．３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２３年９月１５日（２０１１．９．１５）
【国際特許分類】
【出願日】平成２２年３月３日（２０１０．３．３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]