特許 6087158 アビオニクス全二重交換イーサネットネットワーク

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6087158

(24)【登録日】2017年2月10日

(45)【発行日】2017年3月1日

(54)【発明の名称】アビオニクス全二重交換イーサネットネットワーク

(51)【国際特許分類】

   H04L 12/28 20060101AFI20170220BHJP

【ＦＩ】

   H04L12/28 200Z

【請求項の数】14

【外国語出願】

【全頁数】21

(21)【出願番号】特願2013-16282(P2013-16282)

(22)【出願日】2013年1月31日

(65)【公開番号】特開2013-179583(P2013-179583A)

(43)【公開日】2013年9月9日

【審査請求日】2016年1月25日

(31)【優先権主張番号】13/397,071

(32)【優先日】2012年2月15日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】506388923

【氏名又は名称】ジーイー・アビエイション・システムズ・エルエルシー

(74)【代理人】

【識別番号】100137545

【弁理士】

【氏名又は名称】荒川 聡志

(74)【代理人】

【識別番号】100105588

【弁理士】

【氏名又は名称】小倉 博

(74)【代理人】

【識別番号】100129779

【弁理士】

【氏名又は名称】黒川 俊久

(74)【代理人】

【識別番号】100113974

【弁理士】

【氏名又は名称】田中 拓人

(72)【発明者】

【氏名】パブロ・ボブレック

【審査官】 速水 雄太

(56)【参考文献】

【文献】 特表２００９−５４０７１３（ＪＰ，Ａ）

【文献】 国際公開第２０１１／１２３８７７（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１２／００２７０２２（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２００５／０２２００２９（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／２８

(57)【特許請求の範囲】

【請求項1】

それぞれのホストが少なくとも１つの通信ポートを有する複数のホストと、
前記複数のホストから物理的に離れている少なくとも１つの仮想エンドシステム（ＶＥＳ）と、
前記複数のホストのうちの１つの前記通信ポートのうちの少なくとも１つから、他の複数のホストのうちの１つまたは複数の、１つまたは複数の通信ポートへと延びる、複数の仮想リンクを集合的に規定する前記複数のホストのうちの少なくともいくつかを有する仮想リンクとを備え、
前記仮想リンクが前記ＶＥＳを通過する、アビオニクス全二重交換イーサネットデータネットワーク（ＡＦＤＸ）。

【請求項2】

前記複数のホストのうちの少なくともいくつかを接続して、前記仮想リンクの一部を形成するスイッチをさらに備える、請求項１記載のＡＦＤＸ。

【請求項3】

前記ＶＥＳが前記スイッチ内に物理的に位置する、請求項２記載のＡＦＤＸ。

【請求項4】

前記複数のホストと前記ＶＥＳとの間に高速データリンクをさらに備える、請求項１記載のＡＦＤＸ。

【請求項5】

前記ＶＥＳが、前記複数のホストで前記ＶＥＳを共有できるようにするための通信プロトコルを備える、請求項１記載のＡＦＤＸ。

【請求項6】

前記通信プロトコルが、ホスト通信ポートのセット、ＶＥＳ通信ポートのセット、および前記ＶＥＳ通信ポートを介する前記ホスト通信ポート間のデータ転送を確立するための接続マップを確立し、それが前記仮想リンクの一部を形成する、請求項５記載のＡＦＤＸ。

【請求項7】

前記通信プロトコルが、書込み通信ポートと読出し通信ポートのうちの少なくとも１つを識別するための第１フィールドを備えるヘッダを有するフレームデータ構造をさらに備える、請求項６記載のＡＦＤＸ。

【請求項8】

前記ヘッダが、シーケンス番号を有する第２フィールドをさらに備える、請求項７記載のＡＦＤＸ。

【請求項9】

前記ヘッダが、ＣＲＣチェックサムを有する第３フィールドをさらに備える、請求項８記載のＡＦＤＸ。

【請求項10】

前記ヘッダが、セキュリティタグを有する第４フィールドをさらに備える、請求項９記載のＡＦＤＸ。

【請求項11】

前記セキュリティタグが、前記通信ポートに特有であり、前記フレームとともに送信されない、請求項１０記載のＡＦＤＸ。

【請求項12】

前記ヘッダが、タイムタグを有する第５フィールドをさらに備える、請求項１０記載のＡＦＤＸ。

【請求項13】

前記ヘッダが、特定の通信ポートに特有である前記セキュリティタグの値と等しくするために、前記ホストとＶＥＳとの間のインターフェースにとってローカルである前記プロトコルヘッダの前記部分的ＣＲＣチェックサムを変換し、前記ホスト通信ポートから前記ＶＥＳ通信ポートに前記フレームを送信するために処理されるデータ語を有する第６フィールドをさらに備える、請求項１２記載のＡＦＤＸ。

【請求項14】

前記ＶＥＳが、ＥＤＥ、ＩＥＤＥ、および標準的なＡＲＩＮＣ ６６４ ｐａｒｔ ７完全性プロトコルのうちの少なくとも１つを使用するホスト間で、仮想リンクを介する通信ができるようにするためにプロトコル変換を提供する、請求項６記載のＡＦＤＸ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、アビオニクス全二重交換イーサネットデータネットワークに関する。

【背景技術】

【0002】

ＡＲＩＮＣ ６６４ ｐａｒｔ ７は、アビオニクス全二重交換イーサネット(商標）（ＡＦＤＸ）ネットワークなどのアビオニクスネットワークで使用するための、スイッチおよびエンドシステムの機能を規定する。ＡＲＩＮＣ ６６４ ｐａｒｔ ７ ＡＦＤＸネットワークでは、それぞれのエンドシステム（ＥＳ）または端末ノードは、ホストプロセッサを共有する複数のアプリケーションによって書込みおよび読取りされるメッセージのための通信ポート（ＣＯＭポート）を維持できる、ネットワークインターフェースコントローラ（ＮＩＣ）の役割を仮定する。これらのＣＯＭポートは、ホストが通信するＡＦＤＸネットワークへのホストプロセッサインターフェースの役割を果たす。ＣＯＭポートは、メモリ、キュー、およびネットワークを介するデータ転送に使用されるインターフェースの帯域幅の所定の部分的な割当てを含む、データ構造および物理的リソースで構成される。ＣＯＭポートに書き込まれるデータメッセージは、トラフィックが、一定の時間間隔内で転送されるバイトの最大数について規定されている帯域幅割当てギャップ（ＢＡＧ）を超えないよう形成される仮想リンク（ＶＬ）を使用して、ネットワークを通じて送信される。

【0003】

ホストプロセッサから物理的に離れているコンポーネントである、現在の既存のエンドシステムは、ＰＣＩバスなどの短い基板内接続に合うように、ホストインターフェースで設計されている。したがって、エンドシステムはホストの近傍に位置しており、エンドシステムによって提供される送信サービスを、アビオニクスネットワークにわたって分散されたホスト間で共有することはできない。ＡＲＩＮＣ ６６４ ｐａｒｔ ７のセクション３．３．１．１．２（２００５年６月２７日に発行）に指定されるように、短距離であれば、ＡＲＩＮＣ ６５３のようなタイムスライスオペレーティングシステムで実行しているホストアプリケーションに割り当てられた時間内に、エンドシステムのホストインターフェースの帯域幅はＣＯＭポートメッセージの転送を８キロバイトまでサポートできる。現在、ＡＲＩＮＣ ６６４ ｐａｒｔ ７が指定しているのは、最大フレームサイズが１５１８バイトであるネットワークへの１０メガビット／秒および１００メガビット／秒リンクの使用だけである。したがって、エンドシステムは、ホストプロセッサからサイズが８１９２バイトまでのＣＯＭポートメッセージを受諾してキューに入れて、これらをＵＤＰデータグラムにカプセル化して、必要に応じて大容量メッセージを断片化して、ＡＦＤＸネットワークを介して送信するためにそれらを割り当てられた最大フレームサイズにカプセル化できなければならない。転送レイテンシ、およびフレーム間の時間ジッタについてのネットワーク設計制約に合わせるために、エンドシステムは、アプリケーションの最大帯域幅割当てに見合ったトラフィックシェーピングを実行して、レイテンシおよびフレーム間ジッタの要件に見合ったネットワークリンクを介して複数のアプリケーションからフレームを多重化する。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】米国特許出願公開第２０１０／０２６２７１５号明細書

【発明の概要】

【0005】

一実施形態では、アビオニクス全二重交換イーサネットデータネットワーク（ＡＦＤＸ）は、それぞれのホストが少なくとも１つの通信ポートを有する複数のホストと、ホストから物理的に離れている少なくとも１つのＶＥＳと、ホストのうちの１つの通信ポートのうちの少なくとも１つから、他のホストのうちの１つまたは複数の、１つまたは複数の通信ポートへと延びる、複数の仮想リンクを集合的に規定する複数のホストのうちの少なくともいくつかを有する仮想リンクとを含み、仮想リンクはＶＥＳを通過する。

【図面の簡単な説明】

【0006】

【図1】本発明の一実施形態によって動作するように構成されたアビオニクス通信ネットワークのトポロジの概略図である。図１の実施形態では、仮想エンドシステム（ＶＥＳ）は、供給するために接続している１つまたは複数のホストから離れて配置でき、それぞれのホストは異なるネットワークとインターフェースするために複数のＶＥＳと接続しうる。これによってホストは、可用性を向上するために、別の冗長ネットワーク上で重要なデータを複製できるようになる。

【図2】本発明の他の実施形態によって動作するように構成されたアビオニクス通信ネットワークのトポロジの概略図である。

【図3】図１および図２のホストプロセッサと仮想エンドシステムとの間で送信される、通信メッセージの概略図である。

【図4】ホストとＶＥＳとの間のリンクが、イーサネットジャンボフレームを使用してＣＯＭポートメッセージが搬送されるギガビットイーサネットリンクであるように選択される、図３と一致するプロトコルの実施形態の一例の図である。

【図5】米国特許第５１７０４０１号に例が説明されている、ロックウェルコリンズエンドシステム内に実装されるものなどのエラー検出符号化スキームを使用するレガシー受信エンドシステムと相互作用する機能を含む、ＶＥＳ送信処理の実施形態の図である。これは、たとえば７２０で示される方法によって計算されるように、３０６、４０６、および６２８などのＣＲＣトランスレータに依存し、優れたエラー検出を実現するために必要な処理がはるかに少ない、よりシンプルな、好ましいエラー検出符号化スキームも含む。

【図6】ＣＯＭポート識別子を含むＣＯＭポートメッセージが、ローカルプロトコルヘッダおよびＣＲＣトランスレータを有するホストによってジャンボフレームにカプセル化される方法を示す図である。ＣＲＣトランスレータにより、ローカルプロトコルヘッダを有するジャンボフレームのＣＲＣチェックサムは、ＣＲＣを計算するためにローカルプロトコルヘッダの代わりにＣＯＭポート識別子が使用されていたら生じたＣＲＣと確実に同じになる。一旦ＶＥＳが、ローカルプロトコルヘッダおよびＣＲＣトランスレータを有する図４のジャンボフレームを受信すると、ＶＥＳはジャンボフレームヘッダおよびＣＲＣトランスレータを除去して、メッセージをＵＤＰ／ＩＰデータグラム内にカプセル化して、メッセージを断片化して、ＡＦＤＸネットワークを介して送信するためにＭＡＣカプセル化を実行する。ネットワークの遠端で、受信者はＣＯＭポート識別子の値が分かり、メッセージの完全性を確認するために（送信ホストによって調達された、元のローカルプロトコルヘッダなしで）、また、受信ホストに送信されたＣＯＭポートジャンボフレームメッセージのための異なるローカルプロトコルヘッダを生成するために使用できる。

【図7】ＣＲＣ計算においてローカルプロトコルヘッダの代わりにセキュリティタグが使用されていたら生じていた部分的なＣＲＣリマインダと等しくするために、ローカルプロトコルヘッダの部分的なＣＲＣリマインダを変換するトランスレータ語（ｔｒａｎｓｌａｔｏｒ ｗｏｒｄ）、たとえば３０６または４０６を生成する手段の一実施形態の図である。この実施形態では、ＣＯＭポート識別子６２６は、受信ＡＦＤＸエンドシステムによってその値が知られており、有効なＣＲＣチェックサム結果を取得するためにメッセージヘッダとして挿入されなければならないセキュリティタグの役割を果たす。７００で、ローカルプロトコルヘッダの全体についての部分的なＣＲＣチェックサムが、まず計算される。次いで、７２０で、この部分的なＣＲＣチェックサムおよびＡＦＤＸ ＣＯＭポート識別子６２６を使用して、ＣＲＣトランスレータ語の値が計算される。

【図8】データフレーム完全性チェック、およびＣＯＭポート識別子決定を実行する信頼性の高い方法を示す図である。これとはわずかに異なる実施形態が、ネットワークへの入口フレームとネットワークから受信する出口フレームとの両方のために使用される。違いは、データおよびフレーム完全性をチェックするために、およびＣＯＭポート識別子を決定するために使用される方法に関連する。

【図9】ＡＲＩＮＣ ６６４ ｐａｒｔ ７に指定されるように、ＡＦＤＮネットワークを介して送信するためのＣＯＭポートメッセージをカプセル化して、適宜、断片化する方法を示す図である。

【図10】ロックウェルコリンズエンドシステムなどのレガシーエラー検出符号化（ＥＤＥ）か、本発明の改良されたエラー検出符号化（ＩＥＤＥ）か、ＡＲＩＮＣ ６６４ ｐａｒｔ ７において概説される通常の完全性方法のいずれかを使用して送信されたフレームを受信できる、ＶＥＳ受信処理を示す図である。

【図11】ＩＰデフラグのための処理の実施形態を示す図である。

【発明を実施するための形態】

【0007】

以下の記述では、説明の目的で、本明細書に記載の技術の完全な理解を提供するために多くの特定の詳細を説明する。しかし、これらの特定の詳細なしに例示的実施形態を実施できることが、当業者には明らかであろう。他の例では、例示的実施形態の説明を簡略化するために、構造およびデバイスは図の形式で示される。

【0008】

以下で、図面を参照して例示的実施形態を説明する。これらの図面は、本明細書に記載のモジュール、方法、およびコンピュータプログラム製品を実装する特定の実施形態のいくつかの詳細を説明するものである。しかし、図面は、図面内に存在しうる何らかの制限を課すものと見なされるべきではない。方法およびコンピュータプログラム製品は、それらの動作を実現するために任意の機械可読メディア上で提供されうる。実施形態は、既存のコンピュータプロセッサを使用して、あるいはこの目的または他の目的のために組み込まれた専用コンピュータプロセッサによって、あるいはハードワイヤードシステムによって実装されうる。

【0009】

上述のように、本明細書に記載の実施形態は、搬送するための機械可読メディアを備える、または機械実行可能命令またはデータ構造を格納したコンピュータプログラム製品を含む。このような機械可読メディアは、汎用または専用コンピュータ、あるいはプロセッサを備えた他の機械によってアクセスできる、任意の利用可能なメディアでよい。例として、このような機械可読メディアには、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、あるいは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは所望のプログラムコードを機械実行可能命令またはデータ構造の形式で搬送または格納するために使用でき、汎用または専用コンピュータ、あるいはプロセッサを備えた他の機械によってアクセスできる他の任意のメディアが挙げられる。ネットワークまたは他の通信接続（ハードワイヤード、無線、あるいはハードワイヤードまたは無線の組合せのいずれか）を介して情報が機械に転送または提供されると、機械はその接続を機械可読メディアとして適切に見なす。したがって、このような任意の接続は適切に機械可読メディアと呼ばれる。上記の組合せも、機械可読メディアの範囲内に含まれる。機械実行可能命令は、たとえば、汎用コンピュータ、専用コンピュータ、または専用処理マシンに、特定の機能または機能のグループを実行させる命令およびデータを含む。

【0010】

実施形態は、たとえばネットワーク環境における機械によって実行されるプログラムモジュールの形式で、プログラムコードなどの機械実行可能命令を含むプログラム製品によって一実施形態に実装されうる方法ステップの一般的な文脈で説明される。通常、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データタイプを実装する、ルーティン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。機械実行可能命令、関連データ構造、およびプログラムモジュールは、本明細書に開示した方法のステップを実行するためのプログラムコードの例を表す。このような実行可能命令または関連データ構造の特定のシーケンスは、このようなステップに記述される機能を実装するための対応する動作の例を表す。

【0011】

実施形態は、プロセッサを有する１つまたは複数の遠隔コンピュータへの論理接続を使用してネットワーク環境において実施されうる。論理接続は、限定するためではなく例として本明細書で提示される、ローカルエリアネットワーク（ＬＡＮ）およびワイドエリアネットワーク（ＷＡＮ）を含みうる。このようなネットワーク環境は、オフィス規模、または企業規模のコンピュータネットワーク、イントラネットおよびインターネットで一般的であり、様々な異なる通信プロトコルを使用できる。当業者は、このようなネットワークコンピューティング環境は、一般的に、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、および同様のものを含む、多くのタイプのコンピュータシステム構成を包含することが理解できるであろう。

【0012】

実施形態は、通信ネットワークを通じてリンクしている（ハードワイヤードリンク、無線リンク、あるいはハードワイヤードまたは無線リンクの組合せのいずれかによって）ローカルおよび遠隔処理デバイスによってタスクが実行される、分散コンピューティング環境においても実施されうる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよび遠隔メモリストレージデバイスの両方に位置しうる。

【0013】

例示的実施形態の全体または一部を実装するための例示的システムは、処理ユニット、システムメモリ、およびシステムメモリを含む様々なシステムコンポーネントを処理ユニットに結合するシステムバスを含む、コンピュータの形式の汎用コンピューティングデバイスを含みうる。システムメモリは、読出し専用メモリ（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ）を含みうる。コンピュータは、磁気ハードディスクから読み出し、またそこに書き込むための磁気ハードディスクドライブ、リムーバブル磁気ディスクから読み出し、またそこに書き込むための磁気ディスクドライブ、およびＣＤ−ＲＯＭまたは他の光メディアなどのリムーバブル光ディスクから読み出し、またそこに書き込むための光ディスクドライブも含みうる。ドライブおよびそれらの関連する機械可読メディアは、機械実行可能命令、データ構造、プログラムモジュール、および他のデータの不揮発性ストレージをコンピュータに提供する。

【0014】

図１は、３つのアビオニクスホストプロセッサ１００、１０２、および１０４が、離れて配置された２つの仮想エンドシステム１１８および１２０を共有する、本発明の一実施形態を示している。それぞれの仮想エンドシステム（ＶＥＳ）への３つのホスト接続は、例として示されているにすぎない。向上された可用性を提供するために、ネットワーク障害の場合には、アビオニクスシステムが同じメッセージが通信される冗長ネットワークを有することが一般的な方法である。図１は、リンク１２２を使用してネットワークＡを介して通信するＶＥＳ１１８と、リンク１２４を使用してネットワークＢを介して通信するＶＥＳ１２０との、２つの冗長ＡＲＩＮＣ ６６４ ｐａｒｔ ７ネットワークがあると仮定する。リンク１２２および１２４を介する通信は、ＡＲＩＮＣ ６６４標準において指定された、物理的、電気的、およびプロトコルに準拠する。それぞれのホストは、高速シリアルリンク１１６を使用してそれぞれのネットワーク上のエンドシステムと通信し、そのデータレートは、ネットワークリンク１２２および１２４のデータレートを著しく超えるので、ホストは、フレームサイズがＡＲＩＮＣ ６６４ネットワーク上のＣＯＭポートの仮想リンクのために構成されたフレームサイズ以上であるＣＯＭポートメッセージを転送できる。それぞれのホストおよびＶＥＳは、物理層デバイス（ＰＨＹ）を通じてシリアルリンクを介してデータメッセージを送受信し、たとえば、ホスト１００およびＶＥＳ１１８は、ＰＨＹペア１０６を使用して両者間のリンクを介して通信する。

【0015】

ホストが複数のネットワーク上のＶＥＳと通信すること、および機能が重要ではないホストが１つのネットワークを介して１つのＶＥＳと通信できることは、本発明の実施形態の要件ではない。たとえば、アプリケーションのニーズに応じて、二重メッセージを識別または廃棄できるようにするために、あるいは一連のメッセージ内のあるメッセージが失われたことを示すために、複数のネットワークを介して送受信された二重メッセージ、または、１つのネットワークを介する一連のメッセージ内の失われたメッセージの受信を把握することが望ましい。この目的のために、それぞれのホスト１００、１０２、および１０４は、それぞれシーケンシング機能１０１、１０３、および１０５を有し、それぞれのＣＯＭポートに属する送信されたメッセージにシーケンス番号で印をつけて、そのＣＯＭポートについてのシーケンス番号の履歴に対して受信されたメッセージのシーケンス番号をチェックする。この発明の態様は、ホスト１００、１０２、および１０４が、同じカード上または同じシャーシ内に位置しても位置しなくてもよく、さらに、ＶＥＳ１１８および１２０が、ホスト１００、１０２、および１０４のいずれかと同じシャーシ内の異なるカード上に位置してもよく、異なるシャーシまたはスタンドアロンユニット内に離れて位置してもよい点に留意されたい。

【0016】

次に図２を参照すると、３つのアビオニクスホストプロセッサ２００、２０２、および２０４が、それぞれＡＦＤＸスイッチ２２２および２２４内に物理的に常駐する、離れて配置された２つの仮想エンドシステム２１８および２２０を共有する、本発明の代替実施形態が示されている。それぞれの仮想エンドシステム（ＶＥＳ）への３つのホスト接続は、例として示されているにすぎない。仮想エンドシステム（ＶＥＳ）は、３つのホストへのサービスの提供に限定されず、任意の数のホストに対応できることが理解されよう。アビオニクスシステムが同じメッセージが通信される冗長ネットワークを有することが一般的な方法であり、図１は、リンク２２６を使用してネットワークＡを介してスイッチ２２２が通信するＶＥＳ２１８と、リンク２２８を使用してネットワークＢを介してスイッチ２２４が通信するＶＥＳ２２０との２つの冗長ＡＲＩＮＣ ６６４ ｐａｒｔ ７ネットワークがあると仮定する。

【0017】

図２では、それぞれのスイッチは例として４つのネットワークリンクを示しているが、それぞれのスイッチはそれぞれのネットワークへの任意の数のリンク有してよいことが理解されよう。リンク２２６および２２８を介する通信は、ＡＲＩＮＣ ６６４標準において指定された、物理的、電気的、およびプロトコルに準拠する。それぞれのホストは、高速シリアルリンク２１６を使用してそれぞれのネットワーク上のエンドシステムと通信し、そのデータレートは、ネットワークリンク２２６および２２８のデータレートを著しく超えるので、ホストは、フレームサイズがＡＲＩＮＣ ６６４ネットワーク上のＣＯＭポートの仮想リンクのために構成されたフレームサイズ以上であるＣＯＭポートメッセージを転送できる。それぞれのホストおよびＶＥＳは、物理層デバイス（ＰＨＹ）を通じてシリアルリンクを介してデータメッセージを送受信し、たとえば、ホスト２００およびＶＥＳ２１８は、ＰＨＹペア２０６を使用して両者間のリンクを介して通信する。ホストが複数のネットワーク上のＶＥＳと通信すること、および機能がセーフティクリティカルではないホストが１つのネットワークにサービスする１つのスイッチ内の１つのＶＥＳと通信できることは、この発明の要件ではない。たとえば、アプリケーションのニーズに応じて、二重メッセージを識別または廃棄できるようにするために、あるいは一連のメッセージ内のあるメッセージが失われたことを示すために、複数のネットワークを介して送受信された二重メッセージ、または、１つのネットワークを介する一連のメッセージ内の失われたメッセージの受信を把握することが望ましい。この目的のために、それぞれのホスト２００、２０２、および２０４は、それぞれシーケンシング機能２０１、２０３、および２０５を有し、それぞれのＣＯＭポートに属する送信されたメッセージにシーケンス番号で印をつけて、そのＣＯＭポートについてのシーケンス番号の履歴に対して受信されたメッセージのシーケンス番号をチェックする。この発明の態様は、ホスト２００、２０２、および２０４が、同じカード上または同じシャーシ内に位置しても位置しなくてもよく、さらに、ＶＥＳ２１８を有するスイッチ２２２、およびＶＥＳ２２０を有するスイッチ２２４が、ホスト２００、２０２、および２０４のいずれかと同じシャーシ内の異なるカード上に位置してもよく、異なるシャーシまたはスタンドアロンユニット内に離れて位置してもよい点に留意されたい。

【0018】

図３は、ホストとＶＥＳとの間でＣＯＭポートメッセージを通信するための、プロトコルフレームデータ構造３００の一実施形態を示している。任意の特定の実施形態で使用される特定のプロトコルフレームデータ構造は、リンク１１６または２１６を介して送受信するために使用される特定の高速物理層デバイスに依存する。たとえば、図１のＰＨＹペア１０６または図２のＰＨＹペア２０６などの特定の物理層デバイス（ＰＨＹ）は、ローカルリンクプロトコルヘッダ３０２特定のフィールドのコンテンツを規定でき、たとえばＣＯＭポートメッセージと、それに割り当てられた特定のメモリとを、またはメッセージのコンテンツが通信されるべきＡＲＩＮＣ ６６４仮想リンクとを関連付けるために制御情報も通信する。図３は、プロトコルヘッダ３０２を引き継いだ部分的なＣＲＣリマインダを特定の値に強制するために使用される、ヘッダＣＲＣトランスレータ３０６の使用を示している。これにより、メッセージの受信者は、複数語ヘッダ３０２の代わりに、特定のＣＯＭポートに関連付けられる、知られている単一語セキュリティタグを代用できるようになり、受信者がトランスミッタでプロトコルヘッダ３０２の即時コンテンツを知る必要なしに、エンドツーエンドＣＯＭポートメッセージの完全性を保証して、送信元偽装から保護するために役立つ。シーケンス番号３１２はホストのシーケンシング機能、たとえば、図１に関して説明したシーケンシング機能１０１、１０３、および１０５、または図２に関して説明したシーケンシング機能２０１、２０３、および２０５によって追加される。タイムスタンプ３１４がメッセージに追加されるので、受信者はそのメッセージの古さを決定できる。ＣＲＣは、ヘッダ３０２全体、トランスレータ３０６、シーケンス番号３１２、タイムスタンプ３１４、およびペイロード３０４を介して計算される。受信者は、メッセージのバランスのためにトランスレータ３０６によってＣＲＣシード値として強制されたＣＲＣ部分的リマインダを知っているので、ローカルリンクプロトコルヘッダ３０２を受信する必要がない。

【0019】

次に図４を参照すると、例として、ホストとＶＥＳとの間でＣＯＭポートメッセージを移送するためにジャンボフレームがギガビットイーサネットを介して送信される場合に使用されうる、ローカルプロトコルフレーム４００の一実施形態が示されている。この実施形態では、４０２はローカルリンクプロトコルおよびエンドシステム制御ヘッダである。このヘッダは、ローカルプロトコルヘッダであるＩＥＥＥ ８０２．３（またはイーサネット）ヘッダ４１６で構成され、エンドシステム制御は、ＩＰヘッダ４１８、ならびにＵＤＰ送信元ポート４２０、ＵＤＰ宛先ポート４２２、ＵＤＰメッセージ長４２４、およびＵＤＰチェックサム４２６で構成され、そのＣＯＭポートのためにデータを格納するために割り当てられたメモリ、移送するためにＡＦＤＸフォーマットされたデータが置かれるサブＶＬキュー、ならびにＡＦＤＸネットワークを介して移送するために使用されるＡＦＤＸ ＵＤＰ、ＩＰ、およびＭＡＣヘッダを共に識別する。図４の実施形態では、フレーム４００全体を介してＣＲＣ４０８が計算される。イーサネットジャンボフレームを使用することにより、メッセージペイロード４０４は８１９２バイトの最大ＣＯＭポートメッセージ長に対応できるようになる。ＣＲＣ４０８によって使用される多項式は、ＩＥＥＥ ８０２．３によって使用するために指定されるＣＲＣ−３２であり、ホストとＶＥＳとをリンクするギガビットイーサネットＰＨＹデバイスによって好都合に計算できるようにする。

【0020】

次に図５を参照すると、フレーム３００または４００を受信して、ＡＦＤＸネットワークを介して送信する準備をするために使用される、送信処理５００の実施形態が示されている。この実施形態では、ホストポート集信装置５０２により、たとえばギガビットイーサネットリンクなどの高速データリンクを介して、複数のホストからフレームを同時に受信できるようになる。集信装置５０２は、先着順または優先順位ベースで、処理の残りにフレームの通過を命令するように構成されうる。次いで、集信装置のデータフレーム出力が、出力８６４および８６６上の確認されたＣＯＭポートメッセージフレームの同じコピー、ならびにＣＯＭポート識別子８６８および８７２の同じコピーを出力する、データおよびフレーム完全性チェックならびにＣＯＭポート識別子決定論理８００によって処理される。実施形態５００は、たとえば図３の３１２または図４の４１２のシーケンス番号、ならびに、たとえば図３の３１４および図４の４１４のタイムスタンプとともに、たとえば図３の３０４または図４の４０４の、ＣＯＭポートメッセージのエラー検出符号化の２つの異なる手段を提供する。どのエラー検出符号化スキームが使用されるかという選択は、処理８００から受信したＣＯＭポート識別子８６８および８７２の検査に基づいて、処理５０８によって行われる。エラー検出符号化の１つの手段は、たとえば図３の３０６または図４の４０６のＣＲＣトランスレータ、および、たとえば図３の３０８または図４の４０８の、送信元ホストによって計算された３２ビットＣＲＣの使用に依存する。エラー検出符号化のこの方法が使用されると、処理５００は、処理５０４によって使用されるべき処理８００の単一のＣＯＭポートメッセージフレーム出力８６４を使用でき、たとえば図３の３０２または図４の４０２のローカルプロトコルヘッダを除去して、たとえば図３の３０６または図４の４０６のＣＲＣトランスレータを除去する。これにより、処理５０４の出力５４２上のフレーム構造５５２という結果になり、５５０によってＡＲＩＮＣ ６６４ ｐａｒｔ ７、ＵＤＰ／ＩＰヘッダ挿入、断片化、トラフィックシェーピング、シーケンシング、およびＭＡＣフレームカプセル化処理９００への入力５６０になるよう選択される。さらに、ＣＯＭポート識別子８６８および８７２のエラー検出符号化されたコピー５６２が、処理９００にとって利用可能になる。

【0021】

この実施形態によってサポートされるエラー検出符号化の代替の異なる手段を説明するために、図５に示されるＶＥＳ送信処理の実施形態を再び参照する。これは、ロックウェルコリンズエンドシステムに実装されたレガシーエラー検出符号化（ＥＤＥ）であり、その例は米国特許第５１７０４０１号に記述されている。ＣＯＭポート識別子自体が十分にエラー検出符号化されているか、コピー８６８および８７２の両方が十分にエラー検出符号化されている場合、好ましいエラー検出符号化が使用されるか、またはレガシーエラー検出符号化が使用されるかは、ＣＯＭポート識別子の１つのコピー８６８の検査によって決定される。処理５０８は、たとえばエラー検出符号化がある場合はそのチェックによって、または８６８と８７２を直接比較することによって、ＣＯＭポート識別子にエラーがないことを決定する。ＣＯＭポート識別子内にエラーがある場合、そのフレームは廃棄される。ＣＯＭポート識別子内にエラーがない場合、処理５０８は、現在のメッセージが所属するＣＯＭポートが好ましいエラー検出符号化を使用するように構成されているか、またはロックウェルコリンズエンドシステムによって使用されるレガシーエラー検出符号化（ＥＤＥ）を使用するように構成されているかを決定する。レガシーＥＤＥ符号化を実現するために、処理５００は、ＣＯＭポートメッセージフレーム８６４と８６６との両方のコピーを使用する。まず、処理５０４および５０６によって、たとえば図３の３０２および３０６、または図４の４０２および４０６の、ローカルプロトコルヘッダおよびＣＲＣトランスレータが除去される。次に、処理５０４および５０６が、それぞれ８６８および８７２で受信したそれらのＣＯＭポート識別子のコピーを、それぞれ５０４および５０６から受信した結果として得られるＣＯＭポートメッセージフレームの始めに挿入して、除去されたローカルプロトコルヘッダおよびＣＲＣトランスレータと置換する。処理５０４および５０６は、ＣＯＭポートメッセージフレームの終わりから、たとえば図３の３０８および図４の４０８の３２ビットＣＲＣも除去する。結果として得られる、ＣＯＭポート識別子で始まるが３２ビットＣＲＣがないフレームは、単一の障害に対するレガシーＥＤＥ符号化耐性を作成するためにハードウェアの異なる部分に実装された４つの異なるＣＲＣジェネレータ５２２、５２４、５２６、および５２８を通過する。これは、ホストから受信した元のフレームを保護する３２ビットＣＲＣが除去および置換されるので、賢明である。レガシーＥＤＥ符号化の一部として、ＣＲＣ計算において５２２、５２４、５２６、および５２８によって使用されるＣＯＭポート識別子が、処理５２０によって除去される。処理５３０が、同じデータの異なるコピー上で５２４および５２６によって計算された３２ビットＣＲＣは同じであると決定すると、処理５３２は２つの１６ビットＣＲＣを、処理５２０の出力５３４上のフレームに追加する。具体的には、処理５３２は、処理５２２の出力５３６から取得した１６ビットＣＲＣｘのコピーを追加し、処理５３２は、処理５２８の出力５３８から取得した１６ビットＣＲＣｙのコピーも追加する。処理５３２の出力５４４は、５５０によってＡＲＩＮＣ ６６４ ｐａｒｔ ７、ＵＤＰ／ＩＰヘッダ挿入、断片化、トラフィックシェーピング、シーケンシング、およびＭＡＣフレームカプセル化処理９００への入力５６０になるよう選択される、フレーム構造５５４を有する。さらに、ＣＯＭポート識別子８６８および８７２のエラー検出符号化されたコピー５６２が、処理９００にとって利用可能になる。

【0022】

次に図６を参照すると、上から下へ時間順に、図４の８キロバイトのフレーム４００への図５の処理５００のシーケンスの結果が示されている。ホストは、フレームを有するＣＯＭポート識別子６２６を含み、それをフレームの転送に使用されるＣＯＭポートのために予約されたメモリ位置に書き込む。ホスト内の他のハードウェアまたはソフトウェア処理は、ＣＯＭポート識別子を使用して、フレームの冒頭に挿入されるたとえば図３の３０２および図４の４０２のローカルプロトコルヘッダ６１４を選択し、たとえば図３の３０６および図４の４０６のＣＲＣトランスレータ６２８を計算し、たとえば、それぞれ図３の３１２および３１４、ならびに図４の４１２および４１４のＣＯＭポートメッセージシーケンス番号およびタイムスタンプ６３０を増分および挿入し、たとえば図３の３０８および図４の４０８のＣＲＣチェックサム６２４を計算および追加する。メッセージ６０２はＶＥＳによって受信される。正確な受信およびＣＯＭポート識別を確認すると、ローカルプロトコルヘッダ６１４およびＣＲＣトランスレータ６２８が除去されて、図５の処理９００でＣＯＭポートのために選択されたＵＤＰ／ＩＰヘッダ６１８に置換される。ある実施形態では、元のＣＲＣチェックサム６２４は、エンドツーエンドＣＯＭポートメッセージ移送完全性を保証するために、フレームとともに残る。あるいは、レガシーエラー検出符号化（ＥＤＥ）で動作するように構成されたロックウェルコリンズエンドシステムなどのレガシーエンドシステムと相互作用するために、フレームフォーマット５５４内に示されるように、３２ビットＣＲＣ６２４は、２つの１６ビットＣＲＣチェックサム、ＣＲＣｘ ５３６およびＣＲＣｙ ５３８と置換されうる。ＡＦＤＸ ＣＯＭポートメッセージ６０４は、処理９０２によってＣＯＭポートバッファ９１０のうちの１つに格納され、処理９２０によるＩＰ断片化の間に断片が抽出される。例として、図６は、第１のＩＰメッセージ断片６０８、第２のＩＰメッセージ断片６１０、および最後のＩＰメッセージ断片６１２を示しており、第２のメッセージ断片６１０と最後のメッセージ断片６１２との間に複数のメッセージ断片があってよいことが理解されよう。さらに、メッセージ６０４がより短い場合、１つのメッセージ断片か、２つのメッセージ断片しかない場合があることが理解されよう。断片処理９２０によって出力されたメッセージ断片は、それらに関連付けられるＡＦＤＸ ＣＯＭポートに割り当てられたサブＶＬキュー９３０のうちの１つに置かれる。断片は処理９４０によってキューから読み出され、関連ＶＬを介して送信するためにサブＶＬキューがラウンドロビン方式で読み出されることを保証して、ＶＬフレームの送信の間の時間がその構成されたＢＡＧ以上であることをさらに保証する。処理９５０は、ＶＬ指定ＭＡＣヘッダ６１４、ＶＬシーケンス番号バイト６１６、および３２ビットＣＲＣチェックサム６３８を追加する。例として、第１のフレーム断片６０８のＭＡＣフレーム６２０へのＭＡＣカプセル化が図６に示されている。さらなる例として、最後のフレーム断片６１２のＭＡＣフレーム６２２へのＭＡＣカプセル化が図６に示されており、第１のＭＡＣフレーム６２０と最後のＭＡＣフレーム６２２との間に複数のフレーム断片があり得ることが理解されよう。ＣＯＭポートメッセージ６０４が十分に短い場合、単一のフレーム断片がカプセル化され、単一のＭＡＣフレームを使用してメッセージ６０４全体がネットワークに送信されうることがさらに理解されよう。

【0023】

図７は、ＣＲＣトランスレータ語の値を決定するためのいくつかの処理を示している。ＣＲＣトランスレータ語の目的は、受信機で、ＣＯＭポート識別子（またはセキュリティタグ）によってローカルプロトコルヘッダを代用できるようにすること、およびローカルプロトコルヘッダを使用して計算された元のＣＲＣを、ローカルプロトコルヘッダで代用されたＣＯＭポート識別子６２６で計算されたＣＲＣと等しくすることである。たとえば、ＣＲＣトランスレータは、図３のプロトコルヘッダ３０２およびＣＲＣトランスレータ３０６、または図４のプロトコルヘッダ４０２およびＣＲＣトランスレータ４０６を除去して、ホストでローカルプロトコルヘッダを使用して計算された元のＣＲＣを無効にせずに送信機と受信機の両方に知られているＣＯＭポート識別子で置換できるようにする。さらに、ハードウェア故障から保護するために、ＣＯＭポート識別子自体は、データパスの任意の時点で、エラー検出および訂正符号でエラー保護されうる。図７に示される実施形態では、２つの別の処理７００および７２０がある。処理７００は、ローカルプロトコルヘッダの部分的ＣＲＣリマインダを計算する。処理７００で、ＣＲＣは、シフトレジスタの遅延タップ７０４を選択することによってＣＲＣ多項式が符号化される線形帰還シフトレジスタ（ＬＦＳＲ）７０２を使用して計算され、モジュロ−２加算回路７０６で加算され、さらに他のモジュロ−２加算器７０８で入力データビットを加算される。処理７００は、ＬＦＳＲ７０２を知られている値、たとえば全てゼロに初期化して、ローカルプロトコルヘッダ全体を、出力がモジュロ−２加算器７０８に接続される他のシフトレジスタ７１０に配置することによって開始される。次に、シフトレジスタ７０２および７１０の両方が、プロトコルヘッダの最後のビットが７０８によって追加されるまで同じシフトクロック７１２でクロックされて、シフトクロック７１２が終了する時間にＬＳＦＲ７０２にシフトされる。ＬＦＳＲ７０２で結果として得られる値は、ローカルプロトコルヘッダによって生成された部分的ＣＲＣリマインダである。次に、処理７２０が実行される。処理７２０では、ローカルプロトコルヘッダ全体と長さが等しいシフトレジスタ７１０が３２ビットシフトレジスタ７３０に置換される。さらに、処理７２０で、ＬＦＳＲ７２２のタップ７２４は処理７００のＬＦＳＲ７０２のタップ７０４と同じである。しかし、処理７００とは異なり、処理７２０では、シフトレジスタ７３０の出力はＬＦＳＲ７２２の入力を直接与える。さらに、シフトレジスタ７３０の出力は、タップ７２４のモジュロ−２合計７３６をシフトレジスタ７３０の出力に加算するモジュロ−２加算器７２８に与え、モジュロ−２合計７２８の出力が３２ビットシフトレジスタ７３０にシフトされる。処理７２０は、処理７００によって計算された部分的ＣＲＣをＬＦＳＲ７２２にコピーすることによって、および特定のＣＯＭポートに割り当てられた３２ビットＣＯＭポート識別子値で初期化されている３２ビットシフトレジスタ７３０で開始する。次に、シフトクロック７３４が、ＣＯＭポート識別子の最後のビットがシフトレジスタ７３０からＬＦＳＲ７２２に転送されるまで、３２クロックサイクルのために活性化され。処理７２０が完了する。シフトレジスタ７３０は現在ＣＲＣトランスレータ語を含む。

【0024】

次に図８を参照すると、一般的なデータおよびフレーム完全性チェックの一実施形態、およびＣＯＭポート識別子決定処理８００が示されている。データフレームおよび完全性チェック処理８１０および８１２について、およびＣＯＭポート識別子決定８３０および８３２について異なる論理を使用して、処理８００の異なるインスタンスを入口フレーム処理と出口フレーム処理の両方のために使用できるようにする。したがって、処理８００のパラダイムは、本発明のＶＥＳ送信および受信処理の両方の記述に含まれる。図８に示される実施形態では、単一の故障に対する耐性を強化するために、受信フレーム８０１が、バッファ８０２および８０６をそれぞれ使用して、２つの物理的に離れたデータパス８０４および８０８に複製される。それぞれのパス８０４および８０８は、データフレームおよび完全性チェック処理８１０および８１２、ならびにＣＯＭポート識別子決定８３０および８３２の、同じ複製された論理への入力の役割を果たす。データおよびフレーム完全性処理８１０および８１２、ならびにＣＯＭポート決定処理８３０および８３２が進行している間、複製された論理による同じ結果の確認まで、フレームの複製コピーが別のバッファ８６０および８６２に格納される。データおよびフレーム完全性チェック８１０および８１２が８２０をパスして、ＣＯＭポート識別子決定８３０および８３２が同じ結果８４０をもたらすと、ＡＮＤゲート８５０が、８６０および８６２に格納されたフレーム、ならびにＣＯＭポート識別子８３４および８３６を、スイッチ８５４、８５６、８５８、および８７０を通じて、後続の処理にとって利用可能にする。あるいは、フレームが廃棄される。この実施形態では、複製データパス８０４および８０８、複製データバッファ８６０および８６２、ならびに複製された完全性チェック８１０および８１２、複製ＣＯＭポートＩＤ決定８３０および８３２が、データパス、論理、およびメモリ障害を検出できるようにするために提供される。同様に、そのフレームが属するＣＯＭポートの誤認を検出するために、データ障害を検出してＣＯＭポート識別子出力８６８および８７２を複製することを後続の処理が使用可能となる機会を、複製データ出力８６４および８６６が、後続の処理に提供する。たとえば、複製されたデータ出力８６４および８６６、ならびに複製されたＣＯＭポート識別子出力８６８および８７２は、すべて処理５００によって使用される。代替実施形態は、それぞれ８０６、８０８、８１２、８３２、８６２、８５６、８７０、８６６、および８７２による８０２、８０４、８１０、８３０、８６０、８５４、８５８、８６４、および８６８の１つまたは複数の複製を防ぐために、データおよびＣＯＭポート識別子の所望の保護程度を実現するために、たとえば図３の３０２または図４の４０２の、フレームのローカルプロトコルヘッダにおいてＣＯＭポート識別子のために使用されるフレームのエラー検出符号化およびビットのエラー検出符号化を使用できる。たとえば、ＣＯＭポート識別子がローカルプロトコルヘッダ４０２におけるエラー検出符号化の場合、ＣＯＭポート識別子決定論理８３０の出力８３４もエラー検出符号化であり、ＣＯＭポート識別子８６８の１つのコピーがエラーから十分保護されるようにすることができるので、後続の処理、たとえば処理１１００によって必要とされるＣＯＭポート識別子のコピーは１つだけである。

【0025】

次に図９を参照すると、標準的なＡＲＩＮＣ ６６４ ｐａｒｔ ７、ＵＤＰ／ＩＰヘッダ挿入、断片化、トラフィックシェーピング、シーケンシング、およびＭＡＣフレームカプセル化処理９００の実施形態が示されている。エラー検出符号化ＣＯＭポート識別子５６２は、５６０で受信したＣＯＭポートメッセージについてのＵＤＰヘッダおよびＣＯＭポートバッファアドレスを取得するために使用される。処理９０２は、ＡＦＤＸ ＣＯＭポートバッファ９１０のセット内の、予約されたＡＦＤＸ ＣＯＭポートバッファへのＵＤＰヘッダ挿入およびＣＯＭポートメッセージの書込みを実行する。スケジューラ９４０はＣＯＭポートバッファ９１０からのＩＰ断片の読取り、適切なＩＰヘッダ９２０のそれぞれの断片への挿入、およびＩＰヘッダを有する断片の割り当てられたサブＶＬキューへの転送を制御する。それぞれのＶＬは最大４つのサブＶＬキューを有する。４つのサブＶＬキューのいずれかが非空であり、ＶＬごとのフレーム間帯域幅割当てギャップ時間を超えた場合はいつでも、スケジューラ９４０はＶＬに属するサブＶＬキューから利用可能なフレームを送信できる。同じＶＬ上で送信するための準備ができているフレームを有する複数のサブＶＬキューがある場合、これらはラウンドロビン方式であるが、異なるサブＶＬキューからのフレームの送信間の時間が、それらが属するＶＬについてのフレーム間ＢＡＧ間隔を超えない方法で選択される。

【0026】

次に図１０を参照すると、図５の処理５００によって送信されたフレームを受信するように設計された受信処理１０００が示されている。図２に示されるように、ＡＦＤＸスイッチにＶＥＳが組み込まれている場合、ＡＦＤＸスイッチ２２２または２２４は、それぞれリンク２２６および２２８を介してネットワークから受信したトラフィックを集めるネットワークポート集信機能１００２を提供する。あるいは、図１の１１８および１２０に示されるように、ＶＥＳがスタンドアロン機能の場合、それぞれのネットワークへそれぞれ単一のリンク１１２および１２４だけがあれば、集信機能１００２は存在しない。ネットワーク集信装置１００２は、先着順または優先順位ベースで、処理の残りにフレームの通過を命令するように構成されうる。ネットワーク集信装置は、データおよびフレーム完全性チェックならびにＣＯＭポート識別子決定処理８００を通じてフレームを通過させる。これは、図８に示される回路の例であり、データフレームおよび完全性チェッカー８１０および８１２の論理が、ＡＲＩＮＣ ６６４ ｐａｒｔ ７によって定められるように、特定のＶＬを介して受信したフレームが連続的なシーケンス番号６１６を有するという確認を含むように修正される。図８の８００の論理は、たとえば図３の３０２または図４の４０２のローカルプロトコルヘッダを使用してホストから受信したフレームのために使用されうる手段とは異なる、たとえば６１４および６１８のネットワークのフレームヘッダからＣＯＭポート識別子を決定する手段が可能になるようにさらに修正される。さらに、図１０の８００のＣＯＭポート識別子出力８６８はエラー検出符号化と仮定される。一旦処理８００によって完全性が確認されると、受信したＭＡＣフレーム８６４および８６６の２つのコピーがＩＰデフラグ処理１１００に渡される。デフラグが完了すると、制御情報１１１２および１１２２が処理１１００から処理１０１０に渡されて、特定の受信ＣＯＭポート内のメッセージフレームのデフラグの完了を示し、処理５００によってフレームを構築する際に好ましい、またはレガシーエラー検出符号化が使用されたかどうか、さらに、３２ビットＣＲＣを計算して、ローカルプロトコルヘッダを使用してホストに送信されるべきメッセージフレームのコピーに追加する必要があるかどうかを示す。フレームへの３２ビットＣＲＣの挿入は、ネットワークを渡る送信の際にレガシーＥＤＥが使用されたか、何らかのさらなるエラー検出符号化の向上なしにＡＲＩＮＣ ６６４ ｐａｒｔ ７の通常の完全性方法を使用してフレームが送信された場合に必要である。

【0027】

図１０で、処理１１００からデフラグされたフレーム出力１１４０の１つのコピーが、ＣＲＣｘ１０２２の多項式を使用するＣＲＣチェックを通じて渡されて、デフラグされたフレーム１１５０の異なるコピーが、ＣＲＣｙ１０２４の多項式を使用するＣＲＣチェックを通じて渡される。処理１１００は、フレーム１１４０および１１５０の冒頭に、ＣＲＣｘおよびＣＲＣｙが適切に確認されるために必要なＣＯＭポート識別子を含んでいる。レガシーＥＤＥを使用してフレームが送信されなかった場合、それに関わらず、処理１０１０の出力１０１６は、フレームへのさらなる処理が継続できるように、ＣＲＣｘおよびＣＲＣｙの結果１０２０が、出力１０２６上で有効に見えるようにチェックを強制することになる。一方、レガシーＥＤＥが使用された場合、出力１０２６がＣＲＣｘ１０２２およびＣＲＣｙのチェックについての真の結果を反映する。ＣＲＣｘチェック１０２２およびＣＲＣｙチェック１０２４に続いて、処理１１００から１１４０および１１５０で受信したフレームの冒頭にＣＯＭポート識別子を使用して、ローカルプロトコルヘッダおよびＣＲＣトランスレータは、処理１０３２および１０３４によってフレームのそれぞれのコピー内のＣＯＭポート識別子を置換する。３２ビットＣＲＣ計算の後に、処理１０４２および１０４４が続く。３２ビットＣＲＣチェックが同じである場合、および処理１０２０の出力１０２６がＣＲＣｘおよびＣＲＣｙが正確であるか使用されないことを示す場合、フレームはスイッチ１０６２を有効にすることによるホストへの送信に適格である。そうではない場合、フレームは廃棄される。処理１０００によって実行されたデフラグされたフレームのＣＲＣチェックまで、処理１１００によって挿入されたＣＯＭポートＩＤを置換するローカルプロトコルヘッダを有するフレームは、保持用バッファ１０５０に転送される。処理１０１２は、フレームの最後に３２ビットＣＲＣを挿入する必要があるかどうかの決定を行う。何らかのエラー検出の向上なしにＡＲＩＮＣ ６６４ ｐａｒｔ ７の通常の完全性を使用したリモートホストによってフレームが送信された場合、または送信ホストが３２ビットＣＲＣによるＣＲＣｘおよびＣＲＣｙの置換を必要とするレガシーＥＤＥを使用した場合、３２ビットＣＲＣが挿入される。処理１０４４は３２ビットＣＲＣの挿入を実行し、処理１０１２はそれが使用されるべきか、フレームの終わりに挿入されるべきか、あるいはＣＲＣｘおよびＣＲＣｙを置換するために使用されるべきかどうかを決定する。エラーがない場合、処理１０００によって再フォーマットされた、ネットワークから受信したフレームは、フレームを受信するように構成されたホストにそのフレームを送信する、ホストポートディストリビュータ１０７０にとって利用可能になる。

【0028】

次に図１１を参照すると、ＩＰデフラグ処理１１００が示されている。処理１１００は、冗長デフラグバッファ１１１６および１１２６において送信されたＣＯＭポートメッセージを再構築するために使用されるべき処理８００から、エラー検出符号化ＣＯＭポートＩＤ８６８および受信したＭＡＣフレーム８６４および８６６の二重コピーを受信する。処理１１０２、１１１０、および１１２０は、いくつかのＣＯＭポートメッセージのデフラグについての状態情報を同時に維持し、それぞれのＣＯＭポートメッセージは再構築バッファの自身のプライベートペアをセット１１１６および１１２６で割り当てられている。再構築バッファのアドレスは処理１１０２によって維持され、処理１１１０および１１２０はＭＡＣ、ＵＤＰ、およびＩＰヘッダを除去し、ＣＯＭポートＩＤをＣＯＭポートメッセージの第１の断片の冒頭に挿入し、断片が書き込まれるべきバッファ内のオフセットアドレスを把握して、それぞれの断片が予約された再構築バッファに適切に分散されることを保証する。一旦ＣＯＭポートメッセージのデフラグが無事に完了すると、これは制御ライン１１１２および１１２２上の処理１０００に示される。制御ライン１１１２および１１２２は、ＡＲＩＮＣ ６６４ ｐａｒｔ ７の通常の完全性、本発明の好ましいエラー検出符号化方法、またはロックウェルコリンズエンドシステムによって使用されるレガシーＥＤＥを使用してＣＯＭポートメッセージが送信されたかどうかも示す。二重再構築バッファおよび論理を維持する理由は、ＩＰデフラグに使用される論理およびメモリ回路内の故障検出を可能にするためである。

【0029】

ＡＲＩＮＣ ６６４ ｐａｒｔ ７に指定された通常の完全性モードでフレームを受信するように構成されたレガシーエンドシステムは、たとえば図３の３０８、３１２、および３１４、ならびに図４の４１４の、完全性を向上するために使用される受信された単語が、通常の完全性受信器によって単に冗長データ語として扱うことができるので、向上された完全性フレームを処理する能力なしに、５００でサポートされた向上された完全性送信処理のいずれかによって生成されたフレームを依然として受信できる点に留意されたい。あるいは、ＶＥＳは、通常の完全性フレームを唯一受信できるレガシーエンドシステムに送信する前に、たとえば図３の３０８、３１２、および３１４、ならびに図４の４０８、４１２、および４１４の、高い完全性移送に使用する単語を抽出するように構成されうる。

【0030】

送信するためのＣＯＭポートメッセージを符号化するために好ましいエラー検出符号化が使用されるか、またはロックウェルコリンズによって使用されるレガシーＥＤＥが使用されるかどうか、あるいは、何らかの追加エラー検出符号化なしに、ＡＲＩＮＣ ６６４ ｐａｒｔ ７によって指定された通常の完全性が使用されるかどうかは、ホストと仮想エンドシステムとの間で使用されるローカルプロトコルフレームフォーマットにとって透過的なままである。たとえば、図１のリンク１１６または図２のリンク２１６を介して送信されたフレームは、送信処理５００によって生成されたフレームを受信するための受信処理１０００が一致する限り、同じである。

【0031】

上述の実施形態の技術効果は、ホストから離れてエンドシステムを配置する機能を含み、ネットワークを介して通信している複数のホストプロセッサ間のエンドシステムの機能およびサービスの共有をさらに提供する。ホストから離れてエンドシステムを配置すること、および複数のホスト間でエンドシステムを共有することの１つの利点は、それぞれのホストが自身のエンドシステムをもはや必要とせず、そのため電力、冷却要求、およびそれぞれのホストの重量が減少することである。アビオニクスサブシステムは、通常、航空機上の特定の位置に割り当てられる電力、重力、および冷却に制約されている。したがって、仮想エンドシステムによって可能になった、離れて配置されるホストの電力、冷却、および重量における減少は、航空機の環境において非常に有益である。

【0032】

エンドシステムの共有は、エンドシステムを共有するホストの数によって不十分な帯域幅をもたらす可能性がある。幸い、データ転送帯域幅が１Ｇｂｐｓ以上であり、１００メートル以上の転送距離をサポートするＡＲＩＮＣ ６６４ ｐａｒｔ ７標準の開発以来、物理層技術の数は増加している。このようなリンク帯域幅によって、レガシーエンドシステムＰＣＩバスホストインターフェースと匹敵する時間内に、ホストと、離れて配置される仮想エンドシステムとの間のデータ転送が可能になる。増加した処理能力およびネットワークリンク帯域幅によって、相互に物理的に近接である必要がない複数の分散ホストを有するＡＲＩＮＣ ６６４ ｐａｒｔ ７エンドシステムのリソースの共有が実現可能となる。これは、空間、重量、および電力消費を減少させるためにさらに役立つ。

【0033】

エンドシステムをホストから離れて配置することには、いくつかの利点および態様がある。たとえば、離れて配置することによって、アビオニクスネットワークの電力消費のより慎重な利用および分散が可能になる。本発明の実施形態によって、離れて配置されたＡＲＩＮＣ ６６４ ｐａｒｔ ７エンドシステムのサービスを、ホストツーエンドシステムインターフェースの論理的詳細を抽象化することによって、複数のホストによって共有することが可能になる。ホスト−エンドシステムデータ構造およびリソースの遠隔操作は、構成、ステータス、およびネットワークデータ転送を提供する信頼性の高いプロトコルを使用して実現される。このような、離れて配置されるエンドシステムは、ＣＯＭポートサービスが物理的位置または実装詳細に関係なくアクセスされるので、本明細書では仮想エンドシステム（ＶＥＳ）と呼ばれる。

【0034】

本発明の実施形態は、ホストＣＯＭポートからエンドシステムＣＯＭポートへの接続を仮想化するために役立つ、任意のプロトコルおよび関連データ構造を含むように考案される。

【0035】

このエンドシステム機能はＡＳＩＣ、ＦＰＧＡ、汎用ＣＰＵ、またはエンドシステム機能を実行するソフトウェアを実行しているネットワークインターフェースを有するこれらの任意の組合せでよい。この離れて配置されるエンドシステムは仮想エンドシステム（ＶＥＳ）と呼ばれる。ＶＥＳ機能はＡＦＤＸスイッチ内に物理的に配置される。高速データリンクは、ホストプロセッサと、ＣＯＭポートメッセージのサイズ（たとえば、現在８キロバイト）に見合う大容量データフレームの転送をサポートするＶＥＳとの間にあってよい。

【0036】

さらに、処理およびデータ構造のセットは、ホストプロセッサとＡＲＩＮＣ ６６４ ｐａｒｔ ７ エンドシステムとの間のデータの転送を調整するためのプロトコルを確立しうる。これらの処理およびデータ構造によって、複数のホストプロセッサ間でエンドシステムリソースを共有し、エンドシステムリソースを離れて配置することができるようになる。ホスト側からは、これらの処理のセットは、ホストＣＯＭポートのセット、エンドシステムＣＯＭポートの対応するセット、およびそれらの間のデータ転送のための接続マップを構成するための手段を確立するために役立つ。さらに、この処理のセットは、ホストをエンドシステムに接続するリンクにわたってエンドシステムを完全に構成するために必要な全ての情報を転送する機能を含む。

【0037】

ヘッダフィールドは、ホストとＶＥＳとの間の転送の間に、どのＣＯＭポートにメッセージが書き込まれているか、または読み出されているかを識別できる。メッセージシーケンス番号によって、ホストは、可用性を向上させるために、冗長ネットワーク上でＶＥＳと同時にインターフェースできるようになる。これによって、ホストは冗長ＣＯＭポートメッセージをそれぞれのネットワーク上のＶＥＳに送信して、冗長ネットワークから受信した冗長ＣＯＭポートメッセージを管理または廃棄できるようになる。ＣＯＭポートメッセージのＣＲＣチェックによって、受信ＣＯＭポートは、メッセージの完全性を有効にすることができるようになる。ＣＯＭポートに特有で、メッセージとともに送信されないが受信ＣＯＭポートで知られていて再生されるべきセキュリティタグの使用は、ＣＲＣチェックを使用するメッセージの完全性の確認に役立つ。タイムタグは、受信するホストがデータの古さを確認できるように、ＣＯＭポートメッセージの一部として含まれうる。

【0038】

データ語はローカルプロトコルヘッダに追加されて、ホストからＶＥＳにＣＯＭポートメッセージを送信するために使用でき、ローカルプロトコルヘッダのＣＲＣ値を、ＣＯＭポートに特有のセキュリティタグ値と等しくなるように変換する。これによって、送信する間に特定のローカルプロトコルヘッダを除去して、受信ＣＯＭポートでセキュリティタグと置換できるようになり、結果として得られるフレームは依然としてＣＲＣチェックをパスする。これにより、受信ＣＯＭポート論理は、メッセージが最終ＣＲＣチェックをパスするためにセキュリティタグの値を知っていることになるので、エンドツーエンドセキュリティが向上する。

【0039】

さらに、いくつかの相互作用処理は、他のホストをＡＲＩＮＣ ６６４ ｐａｒｔ ７ネットワークに接続しうるレガシーエンドシステムにとってＶＥＳの存在を透過にして、ＶＥＳを使用しているホストにとってレガシーエンドシステムとの通信を透過にすることができる。相互作用処理は、時間管理およびデータ完全性プロトコルを、通信が発生するレガシーエンドシステムと互換性を持つようにすることを含む。

【0040】

この明細書は、最良の形態を含む例を用いて本発明を開示し、さらに、あらゆる当業者が任意のデバイスまたはシステムの作成および使用すること、ならびに任意の包含された方法を実行することを含む、本発明を実施することを可能にする。本発明の特許保護される範囲は、特許請求の範囲によって規定され、当業者であれば想起される他の例を含むことができる。このような他の実施例は、請求項の文言と差違のない構造要素を有する場合、あるいは、請求項の文言と僅かな差違を有する均等な構造要素を含む場合には、特許請求の範囲内にあるものとする。

【符号の説明】

【0041】

１００ ホストプロセッサ
１０１ シーケンシング機能
１０２ ホストプロセッサ
１０３ シーケンシング機能
１０４ ホストプロセッサ
１０５ シーケンシング機能
１０６ 物理層デバイス（ＰＨＹ）
１１６ 高速シリアルリンク
１１８ 仮想エンドシステム（ＶＥＳ）
１２０ 仮想エンドシステム（ＶＥＳ）
１２２ リンク
１２４ リンク
２００ ホストプロセッサ
２０１ シーケンシング機能
２０２ ホストプロセッサ
２０３ シーケンシング機能
２０４ ホストプロセッサ
２０５ シーケンシング機能
２０６ 物理層デバイス（ＰＨＹ）
２１６ 高速シリアルリンク
２１８ 仮想エンドシステム（ＶＥＳ）
２２０ 仮想エンドシステム（ＶＥＳ）
２２２ ＡＦＤＸスイッチ
２２４ ＡＦＤＸスイッチ
２２６ リンク
２２８ リンク
３００ プロトコルフレームデータ構造
３０２ ローカルリンクプロトコルヘッダ
３０４ ペイロード
３０６ ヘッダＣＲＣトランスレータ
３０８ 送信元ホスト
３１２ シーケンス番号
３１４ タイムスタンプ
４００ ローカルプロトコルフレーム
４０２ プロトコルヘッダ
４０４ メッセージペイロード
４０６ ＣＲＣトランスレータ
４０８ 送信元ホスト
４１２ タイムスタンプ
４１４ タイムスタンプ
４１６ ヘッダ
４１８ ＩＰヘッダ
４２０ ＵＤＰ送信元ポート
４２２ ＵＤＰ宛先ポート
４２４ ＵＤＰメッセージ長
４２６ ＵＤＰチェックサム
５００ 処理
５０２ ホストポート集信装置
５０４ 処理
５０６ 処理
５０８ 処理
５２０ 処理
５２２ ＣＲＣジェネレータ
５２４ ＣＲＣジェネレータ
５２６ ＣＲＣジェネレータ
５２８ ＣＲＣジェネレータ
５３０ 処理
５３２ 処理
５３４ 出力
５３６ 出力
５３８ 出力
５４２ 出力
５４４ 出力
５５０ 入力選択
５５２ フレーム構造
５５４ フレーム構造
５６０ 入力
５６２ エラー検出符号化コピー
６０２ メッセージ
６０４ ポートメッセージ
６０８ 第１のＩＰメッセージ断片
６１０ 第２のＩＰメッセージ断片
６１２ 最後のメッセージ断片
６１４ ローカルプロトコルヘッダ
６１６ シーケンス番号バイト
６１８ ＵＤＰ／ＩＰヘッダ
６２０ フレーム
６２２ ＭＡＣフレーム
６２４ ＣＲＣチェックサム
６２６ ＣＯＭポート識別子
６２８ ＣＲＣトランスレータ
６３０ タイムスタンプ
６３８ ＣＲＣチェックサム
７００ 処理
７０２ 線形帰還シフトレジスタ（ＬＦＳＲ）
７０４ タップ
７０６ モジュロ−２加算回路
７０８ モジュロ−２加算器
７１０ シフトレジスタ
７１２ シフトクロック
７２０ 処理
７２２ ＬＦＳＲ
７２４ タップ
７２８ モジュロ−２加算器
７３０ ３２ビットシフトレジスタ
７３４ シフトクロック
７３６ モジュロ−２合計
８００ ＣＯＭポート識別子決定処理
８０１ フレーム
８０２ バッファ
８０４ データパス
８０６ バッファ
８０８ データパス
８１０ 完全性チェック処理
８１２ 完全性チェック処理
８３０ ＣＯＭポート識別子決定
８３２ ＣＯＭポート識別子決定
８３４ ＣＯＭポート識別子
８３６ ＣＯＭポート識別子
８５４ スイッチ
８５６ スイッチ
８５８ スイッチ
８６０ バッファ
８６２ バッファ
８６４ ＣＯＭポートメッセージフレーム
８６６ ＣＯＭポートメッセージフレーム
８６８ ＣＯＭポート識別子
８７０ スイッチ
８７２ ＣＯＭポート識別子
９００ ＭＡＣフレームカプセル化処理
９０２ 処理
９１０ ポートバッファ
９２０ ＩＰヘッダ
９３０ サブＶＬキュー
９４０ スケジューラ
９５０ 処理
１０００ 処理
１００２ ネットワークポート集信機能
１０１０ 処理
１０１２ 処理
１０１６ 出力
１０２０ 処理
１０２２ ＣＲＣｘチェック
１０２４ ＣＲＣｙチェック
１０２６ 出力
１０３２ 処理
１０３４ 処理
１０４２ 処理
１０４４ 処理
１０５０ 保持用バッファ
１０６２ スイッチ
１０７０ ホストポートディストリビュータ
１１００ 処理
１１０２ 処理
１１１０ 処理
１１１２ 制御情報
１１１６ 冗長デフラグバッファ
１１２０ 処理
１１２２ 制御情報
１１２６ 冗長デフラグバッファ
１１４０ デフラグされたフレーム出力
１１５０ デフラグされたフレーム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】