JP2013511857A

JP2013511857A - 性能監視を使用するマルチパスネットワーク常用冗長性

Info

Publication number: JP2013511857A
Application number: JP2012531038A
Authority: JP
Inventors: ミッチェルコッホ，ローラン; スチュアートセクリスト，ウィリアム; ベイリーヒラナンダイ，ダニエル
Original assignee: Aerovironment Inc
Current assignee: Aerovironment Inc
Priority date: 2009-09-23
Filing date: 2010-09-23
Publication date: 2013-04-04
Also published as: WO2011038153A1; CN102598590B; KR20120093225A; US20110096682A1; CN102598590A; US8867381B2; EP2481189A4; EP2481189A1; US9203783B2; US20160191426A1; CA2789898A1; US9787610B2; AU2010298158A1; US20150163174A1; CN106130933A

Abstract

送信ネットワークノード（２３０）からの初期送信の時間が異なる受信パケットから選択するように構成され、初期送信時間に基づいて、選択されたパケットをアプリケーション層（７４０）に送信することを許容する受信ネットワークノード（２１０）。（ａ）受信パケットメッセージのシーケンス番号及び送信元識別子を読み取り（８１０）、（ｂ）送信元識別子に関連付けられた記憶されている最も高いシーケンス番号を、受信したパケットシーケンス番号と比較し（８２０）、（ｃ）受信したパケットシーケンス番号が、送信元識別子に関連付けられた記憶されている最も高いシーケンス番号以下である場合、受信パケットを破棄し（８４０）、（ｄ）受信したパケットシーケンス番号が、送信元識別子に関連付けられた記憶されている最も高いシーケンス番号よりも大きい場合、上位プロトコルに基づいて、受信パケットのメッセージをアプリケーションに送る（８６０）ように構成された相互接続ネットワークのプロセッサノード。
【選択図】図８

Description

関連出願の相互参照
本願は、２００９年９月２３日に出願された米国仮特許出願第６１／２４５，１７０号の利益を主張すると共に、２０１０年３月３１日に出願された米国仮特許出願第６１／３１９，３６３号の利益を主張するものであり、これら出願の開示は参照により本明細書に援用される。

実施形態は、冗長メッセージ処理に関し、より詳細には、同じ送信元ノードから始まり、異なるＩＰアドレスを有する冗長メッセージのメッセージ層処理に関する。

図１は、開放型システム相互接続（ＯＳＩ）モデルの表形式のリストである。ＯＳＩモデルは、ビット、フレーム、及びパケットのデータ単位を有する媒体層並びにデータ及びデータセグメントを有するホスト層として表し得る。層は、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、及びアプリケーション層としてさらに細分化し得る。ユーザデータグラムプロトコル（ＵＤＰ）は、限られたサービスを提供する通信プロトコル、すなわち、インターネットプロトコル（ＩＰ）を使用するネットワーク内のコンピュータ間でメッセージを交換するための軽量プロトコルである。ＵＤＰは、ＩＰを使用してデータ単位、すなわち、データグラムをあるコンピュータ／ノードから別のコンピュータ／ノードに運ぶ。特に、ＵＤＰは、パケットの到着の順序付けを提供しない。

実施形態は、プロセッサと、アドレス指定可能なメモリとを含む相互接続ネットワーク内のノードを含み得、プロセッサは、（ａ）メッセージを有する受信パケットのシーケンス番号及び送信元識別子を読み取り、（ｂ）送信元識別子に関連付けられた記憶されている最も高いシーケンス番号を、受信パケットのシーケンス番号と比較し、（ｃ）受信パケットのシーケンス番号が、送信元識別子に関連付けられた記憶されている最も高いシーケンス番号以下である場合、受信パケットを破棄し、（ｄ）受信パケットのシーケンス番号が、送信元識別子に関連付けられた記憶されている最も高いシーケンス番号よりも大きい場合、上位層プロトコルに基づいて受信パケットのメッセージをアプリケーションに送るように構成される。ノードは、任意選択的に、２つ以上のパスから同じ送信元識別子を有するパケットを受信するように構成し得る。送信元は、準リアルタイムコントローラを備えることができ、ノードは、ゲートウェイと、（１）受信フレームのペイロード情報に応答するエフェクタ、（２）無線周波数送信器、（３）無線周波数受信器、及び（４）センサのうちの少なくとも１つとを備え得る。

例えば、実施形態は、冗長メッセージ処理の方法であって、（ａ）送信元ノードのプロセッサが、（ｉ）フレームシーケンス番号を第１のパケットのフレームに割り当て、（ｉｉ）送信元識別番号を第１のパケットのフレームに割り当て、（ｉｉｉ）フレームシーケンス番号を第２のパケットのフレームに割り当て、（ｉｖ）送信元識別番号を第２のパケットのフレームに割り当てるステップと、（ｂ）宛先ノードのプロセッサが、第１のパケット及び第２のパケットを含む組のうちの第１の受信パケットのフレームシーケンス番号及び送信元番号を記録するステップと、（ｃ）宛先ノードのプロセッサが、記録されたフレームシーケンス番号及び記録された送信元番号を有する第２の受信パケットを破棄するステップとを含む、方法でもあり得る。方法のいくつかの実施形態は、破棄するステップの前に、宛先ノードのプロセッサが、第２の受信パケットのフレームシーケンス番号と第１の受信パケットの記録されたフレームシーケンス番号との差が、上限閾値を上回るか、又は下限閾値を下回る場合、第１の受信パケットの記録された送信元番号を有する第２の受信パケットのフレームシーケンス番号及び送信元番号を記録することをさらに含み得る。方法のいくつかの実施形態は、送信元ノードが、第１のネットワークインタフェース回路を介して第１のパケットを送信すると共に、第２のネットワークインタフェース回路を介して第２のパケットを送信することをさらに含み得る。

方法の実施形態は、ネットワークノード健康評価の方法であって、（ａ）健康要求をネットワークの複数のネットワークノードにマルチキャストするステップと、（ｂ）複数のネットワークノードのうちの少なくとも１つから健康要求応答メッセージを受信するステップであって、受信する健康要求応答メッセージは、応答ノードのイーサネットＭＡＣアドレスを含むステップと、（ｃ）タイムスタンプを受信した健康要求応答メッセージに関連付けるステップと、（ｄ）応答ノードの受信したイーサネットＭＡＣアドレス及び関連付けられたタイムスタンプを記憶するステップと、（ｅ）２つ以上のネットワークインタフェース回路（ＮＩＣ）のイーサネットドライバに、１つ又は複数のノードへの同一の出力メッセージを、１つ又は複数のノードの受信され記憶されたイーサネットＭＡＣアドレスに基づいて提供するステップとを含む、方法も含む。例示的な方法の実施形態は、１つ又は複数のノードの受信され記憶されたイーサネットＭＡＣアドレスの１つ又は複数のタイムスタンプに基づいて、ネットワークの変更を評価することも含み得る。例示的な方法の実施形態は、１つ又は複数のノードの受信され記憶されたイーサネットＭＡＣアドレスの１つ又は複数のタイムスタンプに基づいて、ネットワークの健康を評価することも含み得る。例示的な方法の実施形態は、２つ以上のＮＩＣパスを介して送信されたパケットを、２つ以上のＮＩＣパスを介して受信されたパケットと比較するステップと、２つ以上のＮＩＣパスのそれぞれの損失パケットの数量を特定するステップとをも含み得る。

実施形態は、添付図面の図に限定ではなく例として示される。

図１は、開放型システム相互接続モデルの表形式のリストである。図２は、例示的な最上位システム図である。図３は、実施形態の例示的な層を示す。図４は、最上位関係インタフェースチャートを示す。図５は、関係インタフェースチャートを示す。図６は、例示的なフレームヘッダ内容構成及びメッセージ内容構成を示す。図７は、例示的なシーケンスフィルタリング及びｐｉｎｇ要求処理を示す最上位フローチャートである。図８は、例示的なシーケンスフィルタリング実施形態を示すフローチャートである。図９は、健康評価のためのデータを収集する例示的なイーサネットに基づく通信フローを示す機能ブロック図である。図１０は、ＧｏＣｏｍＭｕｘ流れ図として例示的なアルゴリズム構造を示す。

例示的な実施形態を示す図を参照する。図２は、例示的な最上位システム図２００である。プロセッサは、本明細書では、中央演算処理装置（ＣＰＵ）と、アドレス指定可能なメモリとを有するコンピュータ又は計算装置として定義され、計算装置は、実行可能な機械可読命令、回路、又はこれら両方の組み合わせにより構成されて、特別な計算装置として機能し得る。ネットワークは、プロセッサを備えた送信元ノードと、プロセッサを備えた宛先ノードと、ノード間に配置されるネットワークリンクとを備え得る。送信元ノードは、宛先ノードへのコマンド等のメッセージを生成し得る。例示的なメッセージは、複数のネットワークインタフェースカードにより準備し送信し得る。図２の例示的な図では、送信元ノード２１０は、ネットワークインタフェースカード（ＮＩＣ）であり得る２つのネットワークインタフェース装置２１５、２２０又はコンピュータ回路基板を介してネットワークとインタフェースする。次に、各ＮＩＣは、ルーティングスイッチ２３１〜２３４、例えば、ポートルーティングを指示するテーブルを有するスイッチに接続し得る。図２の例示的なネットワークでは、第１のＮＩＣは、第１のスイッチ（ＳＷ＿１）２３１に送信し得、第１のスイッチは第２のスイッチ（ＳＷ＿２）２３２に送信し得る。図２の例示的なネットワークでは、第２のＮＩＣ２２０も、第１のＮＩＣ２１５と同じメッセージを第４のスイッチ（ＳＷ＿４）２３４に送信し得、第４のスイッチ２３４は第３のスイッチ（ＳＷ＿３）２３３に送信し得る。第２のスイッチ２３２及び第３のスイッチ２３３は、パケット／データグラムを宛先ノード２３０に送信し得る。したがって、宛先ノード２３０は、１つの送信元ノード２１０から、例えば、２つ以上のチャネルを介して冗長メッセージを受信し得る。

図３は、物理層３１０からＵＤＰ／ＩＰ３２０、ショートメッセージプロトコル３３０、そしてアプリケーション層３４０までの実施形態の例示的な層３００を示す。図３には、大きなデータストリーム３５０、ソケットラッパー３６０、及びネットワーク制御スタック３７０も示される。図４は、ソケット層４２０とアプリケーション層４３０との間に配置されたメッセージ処理層４１０を示す最上位関係インタフェースチャート４００である。この例のソケット層４２０は、ソケットの開閉を管理し、ＵＤＰパケットの送受信を処理し、ＵＤＰデータグラムのユニキャスト及びマルチキャストの両方をサポートする。この例のメッセージ処理層４１０は、ｐｉｎｇメッセージに応答し、埋め込まれたシーケンスを使用してメッセージをフィルタリングし、リアルタイムオペレーティングシステム（ＲＴＯＳ）ノードと動作可能な場合、新しいメッセージがあるときにアプリケーション層４３０を呼び出し得る。図５は、例示的なアプリケーションインタフェース５１０を示す関係インタフェースチャート５００である。この図は、アプリケーション層とのメッセージのやりとりの例示的な流れを示す。

図６は、例示的なフレームヘッダ内容構成及びメッセージ内容構成６００を示す。フレームヘッダ６１０は、シーケンス番号６１５及び送信元識別情報（ＩＤ）６２５を有して示される。アプリケーションレベルでの連続性を達成するために、シーケンス番号６１５を送信元ＩＤ６２５と併せて参照し得る。シーケンス番号６１５は、特定の送信元により送信される１６ビットの整数カウントであり得る。各送信元ノードは、２つ以上のＮＩＣを有し得、各ＮＩＣは異なるＩＰアドレスを有する。送信元ＩＤ６２５は、フレームの送信元であるノードを一意に識別する８ビットの整数であり得る。ノードＩＤヘッダファイルを使用して、ノード番号のリストを捕捉し得る。

図７は、シーケンスフィルタリング７１０及びｐｉｎｇ要求処理７２０の例示的なプロセスを示す最上位フローチャート７００である。２つ以上の送信元がフレーム内にメッセージを提供し得、メッセージは同一であり、シーケンス番号は同一である。メッセージ処理層７３０は、最も新しく受信したシーケンス番号を記憶し、その番号を受信フレームのシーケンス番号と比較し得る。ネットワークコントローラノードが、埋め込まれたシーケンス番号を使用してメッセージをフィルタリングし、新しいメッセージがある場合にアプリケーション層７４０を呼び出し、ｐｉｎｇメッセージをすべてのノードに送信することにより、ネットワーク接続及び／又は健康を特定し、各応答を処理し得る。ネットワークコントローラノードは、周期的なｐｉｎｇメッセージからの応答の有無に基づいてネットワーク接続マップ７５０又は関係テーブルを構築し、接続情報を取得するためのアプリケーション層７４０のコールバックを提供し得る。

図８は、本発明の例示的なシーケンスフィルタリング実施形態を示すフローチャート８００である。例示的な受信実施形態は、パケットを受信して読み出すと（ステップ８１０）、新たに受信したパケットのシーケンス番号を、同じ送信元ＩＤを有する最も新しい以前に受信したパケットと比較し得る８２０。新たに受信したパケットのシーケンス番号が、既に記録された番号以下である場合（ステップ８３０）、新たに受信したパケットを破棄し得る（ステップ８４０）。いくつかの実施形態では、受信ノードのメッセージ処理層は、既に記録された番号のシーケンス番号と新たに受信したパケットのシーケンス番号との差の大きさを比較し得る。次に、受信側は、新しいシーケンス番号にリセットされ、シーケンスロールオーバーイベントを記録し、それに従って新たに受信したパケットを処理のために保持し得る（ステップ８６０）。

例示的な実施形態は、航空機の飛行ネットワーク内の２つ以上の飛行制御コンピュータ（ＦＣＣ）を有する航空機のシステム内であり得る。各ＦＣＣは２つのネットワークインタフェース回路又はネットワークインタフェースカード（ＮＩＣ）を有し、ネットワークインタフェース回路又はネットワークインタフェースカード（ＮＩＣ）は、それに従って、２つのアクセスポイントを航空機の飛行ネットワークに提供する。上述したように、上述したネットワークの例示的なアーキテクチャは、各ＮＩＣが、ネットワークセグメントを介して重複しない接続を各サブシステムに提供し得るようなものである。すなわち、特定のＦＣＣの第１のＮＩＣから任意の特定のサブシステムへのパスは、特定のＦＣＣの第２のＮＩＣからそのサブシステムへのパスと共通する物理層ネットワーク接続を有さない。例示的な耐故障性ネットワークの実施形態は、部分的に、ＦＣＣが各ＮＩＣからの冗長メッセージを生成するように構成されることに基づく。ＦＣＣで使用し得るネットワークスタックは、特定のＮＩＣへの直接のユニキャストトラフィックの方向付けをサポートしない場合がある。この実施形態でのスタックは、任意の特定のサブネットに１つの接続があり、したがって、トラフィックを自動的に適切なＮＩＣにルーティングするという仮定に従って動作する。特に、スタックにより保持されるアドレス解決プロトコル（ＡＲＰ）テーブルは、同じサブネット上に２つのＮＩＣを予想せず、したがって、サブシステムへの冗長ユニキャストの送信からネットワークスタックを除外し得る。代替の一実施形態は、ネットワークスタックにより、特定のＮＩＣへのマルチキャストの方向付けが期待するように動作していると判断する場合、ユニキャストを使用しなくてもよい。

例示的な実施形態は、例えば、通常のＶｘＷｏｋｒｓスタックと組み合わせて動作するＶｘＷｏｒｋｓｍｕｘＬｉｂインタフェースを使用することにより、二重冗長イーサネットパケットを２つのＮＩＣに直接送信することを含む。二重冗長イーサネットパケットを２つのＮＩＣに直接送信することにより、一般に、ユニキャストを２つの接続があるサブネットに送信しようとする場合に直面するユニキャストルーティング及びＡＲＰテーブル参照呼び掛けが回避される。

ＩＰデータグラムがマルチホームホストから送信される場合、ＩＰデータグラムを、宛先への最も明白なルートを有するインタフェースに渡し得る。したがって、データグラムは、マルチホームホスト内の１つのインタフェースの送信元ＩＰアドレスを含むが、それでもやはり異なるインタフェースにより媒体上に配置し得る。フレーム上の送信元媒体アクセス制御アドレスは、フレームを媒体に実際に送信したインタフェースのものであり、送信元ＩＰアドレスは、送信元の送信側アプリケーションのものであり、必ずしも、ネットワーク接続ＵＩ内の送信側インタフェースに関連付けられたＩＰアドレスのうちの１つであるわけではない。アドレスがインタフェースではなくホストを参照するいわゆる「弱エンドモデル（ｗｅａｋｅｎｄｍｏｄｅｌ）」のシステムは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）を含むいくつかのオペレーティングシステム内に含まれる。この「弱エンドモデル」は、パケットがマルチホームシステム上のインタフェースのうちの１つに到着した場合、宛先アドレスがアドレスのうちの１つのアドレスに一致する限り、ネットワークスタックにより捕捉されることを意味する。他方、いわゆる「強エンドモデル（ｓｔｒｏｎｇｅｎｄｍｏｄｅｌ）」システムでは、パケットの宛先アドレスが、パケットが到着する基礎となるインタフェースアドレスに一致することが必要とされる。パケットの送信と同様に、弱エンドシステムは、パケットの送信元ＩＰアドレスに一致しないインタフェースからパケットを送信し、その一方で、強エンドシステムは、パケットの送信元ＩＰアドレスに一致しないインタフェースからパケットを送信しない。

一般に、例示的なシステムアーキテクチャに関して、図９を参照し、図９では、ＦＣＣアプリケーション９００が、カーネル空間９１０とリアルタイムプロセス（ＲＴＰ）９７０とに分割される。カーネル９１０はドライバインタフェースを処理し、ＲＴＰ９７０は、航空機実施形態でのメッセージング及び飛行制御機能を処理する。標準のＩＰＵＤＰイーサネットフレームのペイロードの一部として、「ｇｏＣｏｍ」層９１１と呼ばれる層を含めて、以下の容易化を行い得る：（ａ）ｇｏＦｒａｍｅヘッダ内のシーケンス番号の重複に基づく冗長受信メッセージの破棄及び（ｂ）複製メッセージの統計生成。収集されたデータを参照し、使用して、任意及びすべての冗長パスの健康を監視し得る。例示的な実施形態では、ＶｘＷｏｒｋｓは、ｍｕｘＬｉｂインタフェース９１２を提供して、ネットワークインタフェース上で受信されるイーサネットパケットへのアクセスを提供する。ｍｕｘＬｉｂは、特定のネットワークインタフェースからイーサネットメッセージを送出するためにも使用される。

パケットを受信した場合、アプリケーションにインストールされているコールバックを、受信割り込みの状況で実行し得る。受信パケットを含むバッファへのポインタが、ｍｕｘインタフェースにより提供される。パケットは、一連のフィルタにより検査して、有効な「ｇｏＣｏｍ」フレームであることを確立し得る。メッセージが、ネットワーク、例えば、センサノード、エフェクタノード、及び／又は送受信器ノードの航空機ネットワーク上のサブシステムからのものである場合、サブシステムのイーサネットアドレスを、サブシステムＩＰアドレスにより索引付けられたテーブル９１３に記憶し得る。したがって、索引付けられたサブシステムイーサネットアドレスのテーブルを参照して、ユニキャストメッセージを、記憶されたアドレスに対応するサブシステムに返信し得る。例示的なテーブルは、部分的に、ＡＲＰが航空機二重ネットワークパス実施形態において一貫して機能しない場合があるため、ＡＲＰの代わりに動作し得る−単独実施形態メカニズム。したがって、ＦＣＣがＦＣＣにまだメッセージを送信していない任意のサブシステムにメッセージを送信できないことに留意する−ＦＣＣがサブシステムのイーサネットＭＡＣアドレスにアクセス又は学習し得るのは、索引付きテーブルによってであるため。テーブルに先を見越して入力するために、例示的な実施形態は、ネットワーク上のすべてのノードに、マルチキャストされた「健康要求」に応答するように要求する。この健康要求は、システムの典型的又は通常の機能から選択し得る。すなわち、利用可能な健康要求への調整又は変更は、必ずしも、二重ユニキャスト耐故障ネットワーク設計のサポートに必要であるわけではない。したがって、サブシステムが、健康応答メッセージで健康要求に応答する場合、ＦＣＣは即座に、ネットワーク上のあらゆるノードのイーサネットＭＡＣアドレスを学習する。パケットがサブシステムからいつ受信されたかのタイムスタンプもテーブルに記憶される。これにより、パス毎の最近の接続に基づいてネットワークの健康を評価することができる。いくつのパケットがいずれかのパスで失われたかについての統計も収集される。そのような統計の収集により、信号パケット損失であっても高感度の検出が可能である。高レベル感度の検出は、ネットワーク問題を早期に検出して切り離す潜在性を提供する。

ＲＴＰからカーネルへのメッセージチャネルインタフェースを使用して、両方のＮＩＣから冗長的に送信すべきユニキャストメッセージを通信し得る。例示的な実施形態は、システムが生成すると予期される、サポートされる最大のイーサネットパケット又は媒体転送単位（ＭＴＵ）を含むのに十分な大きさの固定サイズのバッファを有するメッセージチャネルを有する。例示的な実施形態は、１５３６バイトサイズのＭＴＵを有し得る。メッセージチャネル９２０インタフェースは柔軟であるように構成し得、広範囲のユニキャストをネットワークの任意のサブシステムに送信することができる。メッセージバッファの冒頭にあるメタデータを参照して、メッセージの送信が意図されるＩＰアドレス及びポートを識別し得る。

カーネル９１０は、特定のサブシステムに送信すべきメッセージをＲＴＰ９７０から受信すると、まず、サブシステムの有効なイーサネットアドレスがイーサネットテーブル９１３に記憶されているか否かをチェックして判断し得る。記憶されていない場合、メッセージを静かに破棄し得る。すなわち、ネットワークの他の要素及びＦＣＣアプリケーションＲＴＰに通知せずにメッセージを破棄し得る。イーサネットアドレスがサブシステムに提供される場合、２つのパケットが、メッセージ９２０に基づいて形成される９３０。２つのメッセージは、送信元であるＮＩＣ以外は同一である。特に、同じシーケンス番号が両方のパケットに使用される。次に、パケットは２つのＮＩＣ、特に、各ＮＩＣのイーサネットドライバ９５１、９５２に送信され、ｍｕｘＬｉｂインタフェース９１２を介して送信される。

ＶｘＷｏｒｋｓカーネルとして実施されるカーネル９１０には、共有データライブラリサポート、例えば、ｓｄＬｉｂサポートを構築して、統計をパケット受信ハンドラから、ネットワーク統計を使用してｇｏＣｏｍメッセージを生成するＲＴＰ符号に渡す効率的なメカニズムを提供し得る。カーネルの実施形態は、ネットワークスタックが使用する標準インタフェースとしてｍｕｘＬｉｂを有する。

不揮発性記憶装置、例えば、フラッシュメモリ又はＮＶＲＡＭを使用して、受信したイーサネットパケットにタイムスタンプを付与するために使用される飛行時間、すなわち、経過時間を記憶し得る。比較的高速であるが、ＮＶＲＡＭアクセスはＲＡＭアクセスよりも遅く、あらゆる受信パケットにタイムスタンプが付与されるため、読み出し性能が考慮事項である。ＮＶＲＡＭは、３２ビットアクセス装置であり得るＲＡＭとは対照的に、８ビットアクセス装置であり得る。８ビットアクセスは、秒カウンタの長たらしい４バイトにわたってデータの一貫性判断を行うが、３２ビットアクセスは本質的に原子的である。したがって、飛行秒カウンタがＲＡＭ並びにＮＶＲＡＭに記憶され、１秒の割り込み処理の一環として両位置で更新することができる。

ＶｘＷｏｒｋｓ標準ＲＡＭマップ等の標準ＲＡＭマップを使用し得、ブートローダは、アプリケーションを低いメモリにロードする間、高いメモリを使用する。起動時、アプリケーションは、ＳＹＳＭＥＭＴＯＰで始まる高いメモリを使用して、スタックを構築する。スタックはビルドダウンされる。ＯＳ又はコンパイラにより管理されないあらゆる固定メモリ割り振りも、ＳＹＳＴＥＭＴＯＰよりも上に配置し得る。カーネルアプリケーションは、ｓｄＬｉｂを使用して、カーネルにより管理される名前付きの共有データ領域を作成する。次に、名前付き領域は、ＲＴＰアプリケーションにより開かれ、イーサネットパケット統計性を読み出し得る。

ＶｘＷｏｒｋｓ用のＣｕｒｔｉｓＷｒｉｇｈｔのＢＳＰを使用して、イーサネットドライバを提供し得る。したがって、ｍｕｘＬｉｂイーサネットドライバインタフェースは、ＭＵＸ＿ＰＲＯＴＯ＿ＳＮＡＲＦモードで動作するように構成し得る。この構成では、すべての受信パケットを無差別に検査することができる。次に、パケットは、任意選択的に、ｍｕｘＬｉｂに戻されて、通常処理のために標準のネットワークスタックに送信される。

例示的なアルゴリズム構造が、図１０のＧｏＣｏｍＭｕｘ流れ図に示される。アプリケーション層は、ｇｏＣｏｍＭｕｘモジュール１０１０の手続きを初期化又は生成し得る。モジュールが初期化されると１０２０、ｇｏＣｏｍＭｕｘモジュールは、第１のＮＩＣをバインドする１０３０と共に、第２のＮＩＣをバインドし得１０４０、それにより、送信元であるＮＩＣの特定が可能になる。メッセージ送信を初期化する手続き１０５０を実行し得、カーネルは、ドライバインタフェースを処理し、ＲＴＰメッセージ、例えば、パケット／データグラムをカーネル送信チャネルに読み出し得る１０６０。ＧｏＣｏｍＭｕｘモジュールは、フレーム１０７０をＦＣＣアプリケーションＲＴＰ９７０に送信可能であり得る。ＧｏＣｏｍＭｕｘモジュールは、第１のＮＩＣ１０８０及び第２のＮＩＣ１０８５の割り込みを受け入れ、ＭｕｘＬｉｂからのパケットを受信する手続き１０９０を呼び出し得る。

上記実施形態の特定の特徴及び態様の様々な組み合わせ及び／又は下位組み合わせを行うことが可能であり、それでも本発明の範囲内にあることが意図される。したがって、開示される実施形態の様々な特徴及び態様を互いに結合又は置換して、開示される本発明の変形モードを形成し得ることを理解されたい。さらに、本明細書において例として開示される本発明の範囲を、開示される上述した特定の実施形態によって限定されるべきではないことが意図される。

Claims

相互接続ネットワーク内のノードであって、
プロセッサと、アドレス指定可能なメモリとを備え、前記プロセッサは、
送信元からのメッセージを有する受信パケットのシーケンス番号及び送信元識別子を読み取るステップと、
前記送信元識別子に関連付けられた記憶されている最も高いシーケンス番号を前記受信パケットの前記シーケンス番号と比較するステップと、
前記受信パケットの前記シーケンス番号が、前記送信元識別子に関連付けられた記憶されている最も高いシーケンス番号以下である場合、前記受信パケットを破棄するステップと、
前記受信パケットの前記シーケンス番号が、前記送信元識別子に関連付けられた記憶されている最も高いシーケンス番号よりも大きい場合、上位プロトコルに基づいて前記受信パケットの前記メッセージをアプリケーションに送るステップと
を行うように構成されることを特徴とする、ノード。
請求項１に記載のノードにおいて、２つ以上のパスから同じ送信元識別子を有するパケットを受信するようにさらに構成されることを特徴とする、ノード。
請求項１に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、前記受信フレームのペイロード情報に応答するエフェクタとを備えることを特徴とする、ノード。
請求項１に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、無線周波数送信器とを備えることを特徴とする、ノード。
請求項１に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、無線周波数受信器とを備えることを特徴とする、ノード。
請求項１に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、センサとを備えることを特徴とする、ノード。
冗長メッセージ処理の方法であって、
送信元ノードのプロセッサが、
フレームシーケンス番号を第１のパケットのフレームに割り当て、
送信元識別番号を前記第１のパケットの前記フレームに割り当て、
前記フレームシーケンス番号を第２のパケットのフレームに割り当て、
送信元識別番号を前記第２のパケットの前記フレームに割り当てるステップと、
宛先ノードのプロセッサが、前記第１のパケット及び前記第２のパケットを含む組のうちの第１の受信パケットの前記フレームシーケンス番号及び前記送信元番号を記録するステップと、
前記宛先ノードの前記プロセッサが、前記記録されたフレームシーケンス番号及び前記記録された送信元番号を有する第２の受信パケットを破棄するステップと
を含むことを特徴とする、方法。
請求項７に記載の方法において、
前記破棄するステップの前に、
前記宛先ノードの前記プロセッサが、前記第２の受信パケットの前記フレームシーケンス番号と前記第１の受信パケットの前記記録されたフレームシーケンス番号との差が、上限閾値を上回るか、又は下限閾値を下回る場合、前記第１の受信パケットの前記記録された送信元番号を有する第２の受信パケットのフレームシーケンス番号及び送信元番号を記録することをさらに含むことを特徴とする、方法。
請求項７に記載の方法において、前記送信元ノードが、第１のネットワークインタフェース回路を介して前記第１のパケットを送信し、第２のネットワークインタフェース回路を介して送前記第２のパケットを送信することをさらに含むことを特徴とする、方法。
ネットワークノード健康評価の方法であって、
ネットワークの複数のネットワークノードに健康要求をマルチキャスト又はブロードキャストするステップと、
前記複数のネットワークノードのうちの少なくとも１つから健康要求応答を受信するステップであって、前記受信する健康要求応答メッセージは、前記応答ノードのイーサネットＭＡＣアドレスを含むステップと、
タイムスタンプを前記受信した健康要求応答メッセージに関連付けるステップと、
前記応答ノードの前記受信したイーサネットＭＡＣアドレス及び関連付けられたタイムスタンプを記憶するステップと、
２つ以上のネットワークインタフェース回路（ＮＩＣ）のイーサネットドライバに、１つ又は複数のノードへの同一の出力メッセージを、前記１つ又は複数のノードの受信され記憶されたイーサネットＭＡＣアドレスに基づいて提供するステップと
を含むことを特徴とする、方法。
請求項１０に記載の方法において、前記１つ又は複数のノードの受信され記憶されたイーサネットＭＡＣアドレスの１つ又は複数のタイムスタンプに基づいて、ネットワーク健康を評価することをさらに含むことを特徴とする、方法。
請求項１０に記載の方法において、
２つ以上のＮＩＣパスを介して送信されたパケットを、２つ以上のＮＩＣパスを介して受信されたパケットと比較するステップと、
前記２つ以上のＮＩＣパスのそれぞれの損失パケット数量を特定するステップと
をさらに含むことを特徴とする、方法。